[GLASSFISH-3317] Deploying a EJB Module containing persistence.xml and sun-resources.xml fails Created: 10/Jul/07  Updated: 06/Mar/12

Status: Open
Project: glassfish
Component/s: jca
Affects Version/s: 9.1pe
Fix Version/s: not determined

Type: Bug Priority: Minor
Reporter: nityad Assignee: Jagadish
Resolution: Unresolved Votes: 3
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Operating System: All
Platform: All

Attachments: Zip Archive CustomerCMP-ejb.zip     Zip Archive CustomerCMP-ejb.zip     Zip Archive CustomerCMP-ejbWOPersistence.zip     Text File CustomerCMP-ejbWOPersistence.zip     Text File server.log    
Issuezilla Id: 3,317


Win XP
GlassFish b54

Deploying an ejb project from NetBeans that contains both persistence.xml and
containing the required resources fails with following exception,

TopLink, version: Oracle TopLink Essentials - 2.0 (Build b52-rc (06/20/2007))
Server: unknown
RAR7010: Pool not reachable.
RAR5114 : Error allocating connection : [This pool is not registered with the
runtime environment]
Exception occured in J2EEC Phase
Internal Exception: java.sql.SQLException: This pool is not registered with the
runtime environment

Complete stacktrace is attached.

It appears that the persistence.xml is loaded/executed before the
sun-resources.xml is loaded and hence required resources are not found.

Deploying the app containing persistence.xml but without the sun-resources.xml
succeeds if resources are pre-registered on the server.
Attached project : CustomerCMP-ejb

Deploying the app containing sun-resources.xml but without the persistence.xml
succeeds and the resources defined in the sun-resources.xml are successfully
Attached project : CustomerCMP-ejbWOPersistence

Associated NetBeans issue : http://www.netbeans.org/issues/show_bug.cgi?id=106980

Comment by nityad [ 10/Jul/07 ]

Created an attachment (id=1016)
CustomerCMP with persistence.xml

Comment by nityad [ 10/Jul/07 ]

Created an attachment (id=1017)
CustomerCMP without persistence.xml

Comment by nityad [ 10/Jul/07 ]

Created an attachment (id=1018)
server.log - stack trace

Comment by Hong Zhang [ 10/Jul/07 ]

Downgrade the bug to P2 as there is the workaround of pre-registering resources.
Will look into this problem right away.

Comment by gfbugbridge [ 10/Jul/07 ]


Comment by marina vatkina [ 10/Jul/07 ]

Is this a regression? If yes, when did it stop working?

Comment by vince kraemer [ 10/Jul/07 ]

I doubt this use-case has ever been tested... so it has probably always been broken.

Comment by marina vatkina [ 10/Jul/07 ]

I suspect that it's not co-existance of persistence.xml and sun-resource.xml,
but ddl generation properties in the persistence.xml that cause the problem - I
see these lines in the persistence.xml:
<property name="toplink.ddl-generation" value="drop-and-create-tables"/>

Was the support ever designed to auto-install resources for deployment?

Comment by vince kraemer [ 10/Jul/07 ]

that may be. could you test it and report back?

Comment by marina vatkina [ 10/Jul/07 ]

Can bug submitter check that?

Comment by kshitiz_saxena [ 10/Jul/07 ]

More clarification on pre-registering resources - It means that you create all
resources that are needed manually using CLI(asadmin command) or GUI.

Once these resources are created, they should not be part of sun-resources.xml.
Because in that case, deployment will fail as it will detect conflicting resources.

Comment by Hong Zhang [ 11/Jul/07 ]

When attaching the nb project, could you please also include the packaged
application (the jar/ear) inside the project? Also please make sure you attach
the zip as binary format. Thanks.

Comment by nityad [ 11/Jul/07 ]

Created an attachment (id=1020)
updated zip with archive

Comment by nityad [ 11/Jul/07 ]

Created an attachment (id=1021)
updated zip with archive

Comment by Hong Zhang [ 11/Jul/07 ]

Summary of the discussions so far:
1. The cause of the problem has been identified. It is related to the
drop/create table property in the persistence.xml as Marina pointed out.
<property name="toplink.ddl-generation" value="drop-and-create-tables"/>
I have verified the application deploys successfully when this property is
removed from persistence.xml.

2. When this property is specified, the java2db tool will be triggered to
generate necessary artifacts (DDL etc) and create the tables during J2EECPhase
of the deployment. J2EECPhase is the initial phase of the deployment where it
processes the deployment descriptor and generates necessary artifacts.

3. The resource installation/creation happens at the beginning of the StartPhase
where the application is being loaded to the container. This happens after the
java2db tool's execution.

4. For the users to fully take advantage of the java2db tool (so the users don't
need to create tables themselves manually), the resource installation needs to
be happen before java2db tool's execution.

Comment by nityad [ 11/Jul/07 ]

Hong, Your analysis is spot on. The app does deploy when the persistence.xml
does not have <property name="toplink.ddl-generation"

But execution fails because necessary tables are not present.

So the persistence.xml needs to have this property defined and the resources
should be registered before the java2db tool starts.

Comment by Hong Zhang [ 11/Jul/07 ]

Yes, the tables need to be there for the application to run. That was just to
verify the cause and not recommended as the fix

Comment by Hong Zhang [ 13/Jul/07 ]

Updates of my further investigation on possible fixes from the deployment side.

There were two possible fixes to this problem and neither of them worked out well:
1. Move the resource creation earlier in time, so resources are ready before the
java2db tool is invoked. This approach will affect any archive which has
sun-resources.xml bundled.
Java2db tool invocation happens inside J2EECPhase, so we need to move the
PreResCreationPhase before the J2EECPhase.
Further investigation shows this would not work as before J2EECPhase is
executed, the archive is not expanded and the deployment descriptors are not
parsed. The PreResCreationPhase relies on the archive expanded to parse the
sun-resources.xml and the deployment descriptors loaded to calculate the
expected sun-resources.xml paths.

2. Move the java2db execution later in time, so the resources are ready when the
java2db tool is invoked. The approach will affect any archive which uses
java2db tool.
The cmp code trigger java2db tool upon receiving various deployment events
sent from J2EECPhase, so the events need to be sent later at the beginning of
the ApplicationStartPhase.
Further investigation shows this would not work for the redeployment
scenario. In redeployment sceanrio, the deployment code sends a PRE_DEPLOY event
for the cmp code to drop old tables. At that point, the old application bits are
still in the respoistory and the new bits haven't been expanded. If we move the
PRE_DEPLOY event later around application loading time, the resource will be
available, but the old bits in the repository are already replaced by new bits,
and we cannot retrieve the old DDLs to drop tables.

Any other possible fixes would involve major changes in the deployment, for
example, insert the resource creation logic to the already crowded J2EECPhase.
They are just too risky at this point.

Will discuss with connector team who is driving this sun-resources.xml effort
to evaluate other options and decide the strategy for 9.1.

Comment by Hong Zhang [ 16/Jul/07 ]
      • Issue 3351 has been marked as a duplicate of this issue. ***
Comment by Hong Zhang [ 20/Jul/07 ]

Based on the discussions with various teams (connector team, cmp team, netbeans
team, JCAPS team), the netbeans 6 plug in will go back to the old resource
handling mechanism instead of the sun-resources.xml mechanism.

Downgrade the bug to P4 and revisit in the future release.

Comment by pjiricka [ 24/Jul/07 ]

cc myself (java.net requires me to add a comment to do that)

Comment by vladperl [ 26/Jul/07 ]

add to cc

Comment by Hong Zhang [ 17/Oct/11 ]

I think this is no longer a problem with our latest glassfish-resources.xml support, assigned to jagadish to confirm and close the issue.

Comment by Tom Mueller [ 06/Mar/12 ]

Bulk update to change fix version to "not determined" for all issues still open but with a fix version for a released version.

Generated at Sat Oct 10 10:10:30 UTC 2015 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.