glassfish
  1. glassfish
  2. GLASSFISH-3317

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

    Details

    • Type: Bug Bug
    • Status: Open
    • Priority: Minor Minor
    • Resolution: Unresolved
    • Affects Version/s: 9.1pe
    • Fix Version/s: not determined
    • Component/s: jca
    • Labels:
      None
    • Environment:

      Operating System: All
      Platform: All

    • Issuezilla Id:
      3,317

      Description

      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

      1. CustomerCMP-ejbWOPersistence.zip
        22 kB
        nityad
      2. server.log
        4 kB
        nityad

        Activity

        Hide
        nityad added a comment -

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

        Show
        nityad added a comment - Created an attachment (id=1016) CustomerCMP with persistence.xml
        Hide
        nityad added a comment -

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

        Show
        nityad added a comment - Created an attachment (id=1017) CustomerCMP without persistence.xml
        Hide
        nityad added a comment -

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

        Show
        nityad added a comment - Created an attachment (id=1018) server.log - stack trace
        Hide
        Hong Zhang added a comment -

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

        Show
        Hong Zhang added a comment - Downgrade the bug to P2 as there is the workaround of pre-registering resources. Will look into this problem right away.
        Hide
        gfbugbridge added a comment -

        <BT6579009>

        Show
        gfbugbridge added a comment - <BT6579009>
        Hide
        marina vatkina added a comment -

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

        Show
        marina vatkina added a comment - Is this a regression? If yes, when did it stop working?
        Hide
        vince kraemer added a comment -

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

        Show
        vince kraemer added a comment - I doubt this use-case has ever been tested... so it has probably always been broken.
        Hide
        marina vatkina added a comment -

        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?

        Show
        marina vatkina added a comment - 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?
        Hide
        vince kraemer added a comment -

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

        Show
        vince kraemer added a comment - that may be. could you test it and report back?
        Hide
        marina vatkina added a comment -

        Can bug submitter check that?

        Show
        marina vatkina added a comment - Can bug submitter check that?
        Hide
        kshitiz_saxena added a comment -

        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.

        Show
        kshitiz_saxena added a comment - 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.
        Hide
        Hong Zhang added a comment -

        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.

        Show
        Hong Zhang added a comment - 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.
        Hide
        nityad added a comment -

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

        Show
        nityad added a comment - Created an attachment (id=1020) updated zip with archive
        Hide
        nityad added a comment -

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

        Show
        nityad added a comment - Created an attachment (id=1021) updated zip with archive
        Hide
        Hong Zhang added a comment -

        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.

        Show
        Hong Zhang added a comment - 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.
        Hide
        nityad added a comment -

        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.

        Show
        nityad added a comment - 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.
        Hide
        Hong Zhang added a comment -

        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

        Show
        Hong Zhang added a comment - 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
        Hide
        Hong Zhang added a comment -

        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.

        Show
        Hong Zhang added a comment - 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.
        Hide
        Hong Zhang added a comment -
            • Issue 3351 has been marked as a duplicate of this issue. ***
        Show
        Hong Zhang added a comment - Issue 3351 has been marked as a duplicate of this issue. ***
        Hide
        Hong Zhang added a comment -

        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.

        Show
        Hong Zhang added a comment - 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.
        Hide
        pjiricka added a comment -

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

        Show
        pjiricka added a comment - cc myself (java.net requires me to add a comment to do that)
        Hide
        vladperl added a comment -

        add to cc

        Show
        vladperl added a comment - add to cc
        Hide
        Hong Zhang added a comment -

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

        Show
        Hong Zhang added a comment - I think this is no longer a problem with our latest glassfish-resources.xml support, assigned to jagadish to confirm and close the issue.
        Hide
        Tom Mueller added a comment -

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

        Show
        Tom Mueller added a comment - Bulk update to change fix version to "not determined" for all issues still open but with a fix version for a released version.

          People

          • Assignee:
            Jagadish
            Reporter:
            nityad
          • Votes:
            3 Vote for this issue
            Watchers:
            4 Start watching this issue

            Dates

            • Created:
              Updated: