Details
-
Bug
-
Status: Closed
-
Minor
-
Resolution: Fixed
-
1.7.1
-
None
-
Windows 7, 64 bit, JDK 7 Sun Hotspot
Description
Hi,
I am trying to experiement running an application of relative large size on tomcat ee. The application deploys both to Glassfish 3.1.2.X and weblogic 12.1.2. - Just to have a reference point as to application compatibility.
When deploying to tomee plume version 1.7.1 one of the problems I have encountered has to do with the JNDI Naming contexts visible to the application during deployment.
Namely, the persistence.xml will be telling eclipse link to manage the generation of new entity sequence numbers using a non JTA data source.
For example,
<persistence-unit name="MY_PU" transaction-type="JTA">
<provider>org.eclipse.persistence.jpa.PersistenceProvider</provider>
<jta-data-source>jdbc/JTA_DS</jta-data-source>
<jar-file>../some.jar</jar-file> <------- this is the first problem. Was forced to have the ../ added to the jar file
<exclude-unlisted-classes>false</exclude-unlisted-classes>
<shared-cache-mode>DISABLE_SELECTIVE</shared-cache-mode>
<properties>
<property name="eclipselink.logging.level" value="INFO" />
<property name="eclipselink.logging.level.sql" value="INFO" />
<property name="eclipselink.logging.parameters" value="true" />
<property name="eclipselink.jdbc.sequence-connection-pool" value="true" />
<property name="eclipselink.jdbc.sequence-connection-pool.non-jta-data-source" value="jdbc/NON_JTA_DS" /> <------------- Eclipse link will get a naming exception here
</properties>
</persistence-unit>
Ok.
Now with the above "sample" persistence.xml in mind, what happens is the following.
PROBLEM 1:
The <jar-file> defitnition on the persistence.xml was forced to be tuned with ../ - whereas in weblogic and glassfish this was not necessary.
The application is bundled in a War file that in the lib/ folder contians all the WAR dependencies (ejbs and such). One of these jar files - let us call it my-main.jar is the one that in the classes/META-INF/persistence.xml holds the persistence.xml referring to all other jars interesting in the /lib/ of the war file.
Under Tomee this the search for the mentioned jar files that are relevant to the persistence unit seems to bugy. Since tomee is blowing up with file not found exception:
my-main.jar/some.jar
And of course he is right. The path he built to find the JAR was not correct and therefore he could not fild the <jar-file>.
Therefore, here I was forced to put in the <jar-file>../some.jar<jar-file>
to overcome the file not found exception.
PROBLEM 2:
Now the second problem, this is a bit more important, is in the JNDI naming context themsevels.
Using:
tomee-webaccess-1.7.1/scripting
And the following script:
var pairs = ctx.lookup('java:openejb/Resource/jdbc').list(''); <----- This is key.
while(pairs.hasMore()) {
println('[entry] ' + pairs.next().getName());
}
var user = ctx.lookup('java:comp/EJBContext').getCallerPrincipal().getName();
println("Logged user: '" + user + "'");
I am able to verify that the two data sources I defined in the tomee.xml are part of the openejb Resource naming context.
Which is OK.
So the list of names under jdbc/ shows me both the JTA_DS and the NON_JTA_DS.
And indeed the @PersistenceContext inject for the JTA_DS seems to be working fine.
But eclipse link will blow up when it tries to the JNDI lookup for jdbc/NON_JTA_DS as listed in the following exception snippet.
Internal Exception: javax.naming.NameNotFoundException: Name [jdbc/NON_JTA_DS] is not bound in this Context. Unable to find [jdbc].
at org.eclipse.persistence.exceptions.EntityManagerSetupException.deployFailed(EntityManagerSetupException.java:229)
... 58 more
Caused by: Exception [EclipseLink-7060] (Eclipse Persistence Services - 2.4.2.v20130514-5956486): org.eclipse.persistence.exceptions.ValidationException
Exception Description: Cannot acquire data source [jdbc/NON_JTA_DS].
Internal Exception: javax.naming.NameNotFoundException: Name [jdbc/NON_JTA_DS] is not bound in this Context. Unable to find [jdbc].
at org.eclipse.persistence.exceptions.ValidationException.cannotAcquireDataSource(ValidationException.java:502)
at org.eclipse.persistence.sessions.JNDIConnector.connect(JNDIConnector.java:109)
at org.eclipse.persistence.sessions.DatasourceLogin.connectToDatasource(DatasourceLogin.java:162)
at org.eclipse.persistence.internal.databaseaccess.DatasourceAccessor.connectInternal(DatasourceAccessor.java:330)
at org.eclipse.persistence.internal.databaseaccess.DatabaseAccessor.connectInternal(DatabaseAccessor.java:295)
at org.eclipse.persistence.internal.databaseaccess.DatasourceAccessor.connect(DatasourceAccessor.java:418)
at org.eclipse.persistence.sessions.server.ConnectionPool.buildConnection(ConnectionPool.java:216)
at org.eclipse.persistence.sessions.server.ExternalConnectionPool.startUp(ExternalConnectionPool.java:146)
at org.eclipse.persistence.internal.sequencing.ServerSessionConnectionHandler.onConnect(ServerSessionConnectionHandler.java:27)
at org.eclipse.persistence.internal.sequencing.SequencingManager.onConnectInternal(SequencingManager.java:770)
at org.eclipse.persistence.internal.sequencing.SequencingManager.onConnect(SequencingManager.java:700)
at org.eclipse.persistence.internal.sessions.DatabaseSessionImpl.initializeSequencing(DatabaseSessionImpl.java:189)
at org.eclipse.persistence.internal.sessions.DatabaseSessionImpl.initializeDescriptors(DatabaseSessionImpl.java:583)
at org.eclipse.persistence.internal.sessions.DatabaseSessionImpl.initializeDescriptors(DatabaseSessionImpl.java:579)
at org.eclipse.persistence.internal.sessions.DatabaseSessionImpl.initializeDescriptors(DatabaseSessionImpl.java:534)
at org.eclipse.persistence.internal.sessions.DatabaseSessionImpl.postConnectDatasource(DatabaseSessionImpl.java:782)
at org.eclipse.persistence.internal.sessions.DatabaseSessionImpl.loginAndDetectDatasource(DatabaseSessionImpl.java:727)
at org.eclipse.persistence.internal.jpa.EntityManagerFactoryProvider.login(EntityManagerFactoryProvider.java:215)
at org.eclipse.persistence.internal.jpa.EntityManagerSetupImpl.deploy(EntityManagerSetupImpl.java:554)
... 56 more
Caused by: javax.naming.NameNotFoundException: Name [jdbc/NON_JTA_DS] is not bound in this Context. Unable to find [jdbc]. <---------------- OK so eclipse link is operating in some sort of container context that does no see the JDBC name
at org.apache.naming.NamingContext.lookup(NamingContext.java:819)
at org.apache.naming.NamingContext.lookup(NamingContext.java:153)
at org.apache.naming.SelectorContext.lookup(SelectorContext.java:133)
at javax.naming.InitialContext.lookup(InitialContext.java:415)
at org.eclipse.persistence.sessions.JNDIConnector.connect(JNDIConnector.java:103)
... 73 more
To me this looks like a serious bug, but you will know better than me the standard itself and the expectations that an application is allowed to have on the available naming contexts in the container.
But I was under the impression that regardless of the application module, the jdbc name should always be visible at the root of the initial naming context.
I am not sure if it will succeed or not, but for the time being I will try to work around this issue by using the following JNDI name:
java:openejb/Resource/jdbc/NON_JTA_DS
Since i can use the scripting tool the validate that this name can bee lookedup.
I am not satisfied with the solution - i think of it is a hammer pattern approach and injection using the easy name : jdbc/NON_JTA_DS should just work.
It works for weblogic and glassfish 3.1.2 at least so I would assume it should work as well for tomee.
Kindest regards,
And thanks for the support.