ejb3 persistence.xml problems


D

Donkey Hottie

We used to have lots of trouble trying to make our ejb2-application
portable across platforms.

I have converted the app to EJB3 now, and trying to get it to run on
several Application Servers without much modifications.

=== 1 ===

The biggest problem is in the persistence.xml. There is lots of stuff in
it that can be left out.

My current persistence.xml is as follows

---

<?xml version="1.0" encoding="UTF-8"?>
<persistence version="1.0"
xmlns="http://java.sun.com/xml/ns/persistence"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/persistence
http://java.sun.com/xml/ns/persistence/persistence_1_0.xsd">
<persistence-unit name="Mydata" transaction-type="JTA">
<!-- <jta-data-source>java:/MyDataSourceDS</jta-data-source> -->
<jta-data-source>jdbc/MyDataSource</jta-data-source>
<properties>
</properties>
</persistence-unit>
</persistence>


---

Everything else but the jta-data-source can be left off. But the problem
is in the data source. I can use "jdbc/MyDataSource" with many
Application Servers, if not all... except JBoss. It requires
java:/MyDataSource

How to make persistence.xml portable? I have not managed to use an ENC
name for a datasource in persistence.xml with JBoss.

=== 2 ===

My application has several ejb-modules (jar-files) in it, and currently
the persistence.xml had been copied into each of them.

I tried to put persistence.xml to the EAR META-INF -folder, but it did
not work.

I remember having read that persistence.xml does not have to reside in
the ejb-jar. Where could I have it, so that it would work in a portable
way?

=== 3 ===

So far I have managed to run this app under JBoss 4.x and JBoss 5.x and
GlassFish V2 (with different persistence.xml between the brands).
Dependendy Injection seem not to work at all, but I have a Factory
pattern, which does several JNDI lookups and eventually finds the session
beans. Weblogic 10 is a disaster, it does not even deploy this, can't
find classes from other modules (jars) of mine, no matter how I tune the
classpaths in the jar manifests. The EAR running happily in JBoss or
GlassFish does not deploy on Weblogic!

Websphere 6.1 will be tested tomorrow.

Any ideas?
 
Ad

Advertisements

A

Arved Sandstrom

Donkey Hottie said:
We used to have lots of trouble trying to make our ejb2-application
portable across platforms.

I have converted the app to EJB3 now, and trying to get it to run on
several Application Servers without much modifications.
[ snip ]
=== 2 ===

My application has several ejb-modules (jar-files) in it, and currently
the persistence.xml had been copied into each of them.

I tried to put persistence.xml to the EAR META-INF -folder, but it did
not work.

I remember having read that persistence.xml does not have to reside in
the ejb-jar. Where could I have it, so that it would work in a portable
way?

Section 6.2 of the EJB 3 (persistence) spec is your friend. Referencing
that, you can legally stick persistence units in EARs, EJB-JARs, or WARs
(WEB-INF/lib). In all cases the persistence.xml is inside a META-INF. In the
case of an EAR it's either at the top-level or inside the lib directory. By
definition all of these locations are portable.

Naturally enough you're not going to have the same persistence.xml in
multiple locations - they will be defining different PUs.
=== 3 ===

So far I have managed to run this app under JBoss 4.x and JBoss 5.x and
GlassFish V2 (with different persistence.xml between the brands).
Dependendy Injection seem not to work at all, but I have a Factory
pattern, which does several JNDI lookups and eventually finds the session
beans. Weblogic 10 is a disaster, it does not even deploy this, can't
find classes from other modules (jars) of mine, no matter how I tune the
classpaths in the jar manifests. The EAR running happily in JBoss or
GlassFish does not deploy on Weblogic!

Websphere 6.1 will be tested tomorrow.

Any ideas?

As pertains to the JBoss <jta-data-source> issue, the spec does say:

"These elements [my note: the global JNDI names] name the data source in the
local environment; the format of these names and the ability to specify the
names are product speci?c."

So not much you can do about that. You could leave them out of the
persistence.xml - the spec says that in this case the deployer specified the
JTA data source, or the container provides one. Any way you end up doing it
I myself don't see this as onerous - there aren't too many real-world 100%
portable EARs out there, so there is always tweaking.

If I understand you correctly, you're saying that @PersistenceUnit does not
work for you in JBoss or Glassfish?

AHS
 
D

Donkey Hottie

If I understand you correctly, you're saying that @PersistenceUnit
does not work for you in JBoss or Glassfish?

AHS

@PersistenceUnit???

I have not used that. @PersistenceContext( unitName = 'MyPersistence' )
works fine, and the EntitytManager gets declared.

Only thing not working as supposed is

@EJB
private static MyInterface mySessionBean ;

I have to find the bean with jndi-lookups, which are different from AS to
AS.
 
D

Donkey Hottie

Section 6.2 of the EJB 3 (persistence) spec is your friend.
Referencing that, you can legally stick persistence units in EARs,
EJB-JARs, or WARs (WEB-INF/lib). In all cases the persistence.xml is
inside a META-INF. In the case of an EAR it's either at the top-level
or inside the lib directory. By definition all of these locations are
portable.

Naturally enough you're not going to have the same persistence.xml in
multiple locations - they will be defining different PUs.

I have tried EAR's META-INF/persistence.xml but it did not work. Have to
try again...

Everything works at least in JBoss and GlassFish when I put the very same
persistence.xml in every ejb-jar.jar META-INF. Same PU name.
 
D

Donkey Hottie

I have tried EAR's META-INF/persistence.xml but it did not work. Have
to try again...

Everything works at least in JBoss and GlassFish when I put the very
same persistence.xml in every ejb-jar.jar META-INF. Same PU name.

Does not work, that EAR: META-INF/persistence.xml

But I got it working by putting the persistence.xml to META-INF or a dummy
persistence.jar in the root of the EAR.

Great!
 
Ad

Advertisements

D

Donkey Hottie

We used to have lots of trouble trying to make our ejb2-application
portable across platforms.

I have converted the app to EJB3 now, and trying to get it to run on
several Application Servers without much modifications.

=== 1 ===

The biggest problem is in the persistence.xml. There is lots of stuff
in it that can be left out.

My current persistence.xml is as follows

---

<?xml version="1.0" encoding="UTF-8"?>
<persistence version="1.0"
xmlns="http://java.sun.com/xml/ns/persistence"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/persistence
http://java.sun.com/xml/ns/persistence/persistence_1_0.xsd">
<persistence-unit name="Mydata" transaction-type="JTA">
<!-- <jta-data-source>java:/MyDataSourceDS</jta-data-source> -->
<jta-data-source>jdbc/MyDataSource</jta-data-source>
<properties>
</properties>
</persistence-unit>
</persistence>


---

Everything else but the jta-data-source can be left off. But the
problem is in the data source. I can use "jdbc/MyDataSource" with many
Application Servers, if not all... except JBoss. It requires
java:/MyDataSource

How to make persistence.xml portable? I have not managed to use an ENC
name for a datasource in persistence.xml with JBoss.


FinallyI figured it out. jdbc/MyDatasource works in JBoss 4+ too, when
declaring the data source as follows

<datasources>
<local-tx-datasource>
<jndi-name>jdbc/Distal</jndi-name>
<use-java-context>false</use-java-context>
<connection-url>jdbc:mysql://localhost:3306/distal3</connection-url>


The key here is the use-java-context setting, which is a new feature in
JBoss4.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Top