Issue Details (XML | Word | Printable)

Key: GLASSFISH-3317
Type: Bug Bug
Status: Open Open
Priority: Minor Minor
Assignee: Jagadish
Reporter: nityad
Votes: 3
Watchers: 4
Operations

If you were logged in you would be able to see more operations.
glassfish

Deploying a EJB Module containing persistence.xml and sun-resources.xml fails

Created: 10/Jul/07 04:30 PM   Updated: 06/Mar/12 09:58 PM
Component/s: jca
Affects Version/s: 9.1pe
Fix Version/s: not determined

Time Tracking:
Not Specified

File Attachments: 1. Zip Archive CustomerCMP-ejb.zip (42 kB) 11/Jul/07 09:20 AM - nityad
2. Zip Archive CustomerCMP-ejb.zip (24 kB) 10/Jul/07 04:34 PM - nityad
3. Zip Archive CustomerCMP-ejbWOPersistence.zip (40 kB) 11/Jul/07 09:20 AM - nityad
4. Text File CustomerCMP-ejbWOPersistence.zip (22 kB) 10/Jul/07 04:35 PM - nityad
5. Text File server.log (4 kB) 10/Jul/07 04:36 PM - nityad

Environment:

Operating System: All
Platform: All


Issuezilla Id: 3,317
Tags:
Participants: gfbugbridge, Hong Zhang, Jagadish, kshitiz_saxena, marina vatkina, nityad, pjiricka, Tom Mueller, vince kraemer and vladperl


 Description  « Hide

Win XP
GlassFish b54

Deploying an ejb project from NetBeans that contains both persistence.xml and
sun-resources.xml
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
com.sun.enterprise.deployment.backend.IASDeploymentException:
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
registered.
Attached project : CustomerCMP-ejbWOPersistence

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



nityad added a comment - 10/Jul/07 04:34 PM

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


nityad added a comment - 10/Jul/07 04:35 PM

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


nityad added a comment - 10/Jul/07 04:36 PM

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


Hong Zhang added a comment - 10/Jul/07 04:53 PM

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


gfbugbridge added a comment - 10/Jul/07 05:01 PM

<BT6579009>


marina vatkina added a comment - 10/Jul/07 05:40 PM

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


vince kraemer added a comment - 10/Jul/07 05:58 PM

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


marina vatkina added a comment - 10/Jul/07 07:34 PM

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:
<properties>
<property name="toplink.ddl-generation" value="drop-and-create-tables"/>
</properties>

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


vince kraemer added a comment - 10/Jul/07 09:49 PM

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


marina vatkina added a comment - 10/Jul/07 10:19 PM

Can bug submitter check that?


kshitiz_saxena added a comment - 10/Jul/07 11:24 PM

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.


Hong Zhang added a comment - 11/Jul/07 07:58 AM

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.


nityad added a comment - 11/Jul/07 09:20 AM

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


nityad added a comment - 11/Jul/07 09:20 AM

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


Hong Zhang added a comment - 11/Jul/07 10:18 AM

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.
<properties>
<property name="toplink.ddl-generation" value="drop-and-create-tables"/>
</properties>
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.


nityad added a comment - 11/Jul/07 11:03 AM

Hong, Your analysis is spot on. The app does deploy when the persistence.xml
does not have <property name="toplink.ddl-generation"
value="drop-and-create-tables"/>

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.


Hong Zhang added a comment - 11/Jul/07 11:14 AM

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


Hong Zhang added a comment - 13/Jul/07 07:26 AM

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.


Hong Zhang added a comment - 16/Jul/07 07:11 AM
      • Issue 3351 has been marked as a duplicate of this issue. ***

Hong Zhang added a comment - 20/Jul/07 03:16 PM

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.


pjiricka added a comment - 24/Jul/07 12:20 PM

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


vladperl added a comment - 26/Jul/07 10:50 AM

add to cc


Hong Zhang added a comment - 17/Oct/11 05:05 PM

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


Tom Mueller added a comment - 06/Mar/12 09:58 PM

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