3 Replies Latest reply on Jul 20, 2006 3:15 PM by kristoffer sjögren

    application-defined resources for MDBs

    kristoffer sjögren Newbie

      Hi all,

      I have a problem understanding how (assembled and tested) ejb-archives containing MDBs can be deployed in multiple applications without avoiding resource conflicts. To my knowledge, queues are bound (either by xml or annotations) when assembling the module (EJB) and not when assembling the application (EAR)...?

      Servlet context can be bound on application level, global JNDI names for SLSBs can be generated on application level (referencing them with ENC). persitence.xml file can be application-defined which isolate datasources from eachother and overcome conflicts for reused entity beans.

      But, for MDBs i have not found any similar way of lately bind a MDB to application-defined queues?


        • 1. Re: application-defined resources for MDBs
          kristoffer sjögren Newbie

          Am i making any sense? ill try to rephrase a bit...

          This is my interpretation: most application servers uses a server specific deployment descriptor (or annotation) element that maps the logical JNDI name as used by the module (EJB,WAR) to the deployment environment JNDI name. This descriptor is defined and packaged in the module, not in the application (EAR).

          Let's assume I have packaged and tested a set of modules which will be exposed as reusable modules from (for example) a maven repository. I pick appropriate modules to be assembled in applications. I have a hard time understanding how modules containing MDBs can be packaged in multiple applications (deployed in the same server) and still avoid "deployment environment jndi name" conflicts.

          Servlet context can be bound using application.xml. Deployment environment JNDI names for SLSBs can be generated depending on what application it was deployed in (JBoss works this way?). I think persitence.xml can be packaged in the application and modules can use logical names to reference "application-defined" datasources? All of these approches avoid conflicts by binding the logical name when assembling the application, not when assembling the module.

          But, for MDBs i have not found any similar way of "lately" bind the logical name of a queue to the deployment environment JNDI name?

          • 2. Re: application-defined resources for MDBs
            kristoffer sjögren Newbie

            If it is true that there could occur conflicts, then i guess the following documentation is not valid:

            Reading from "Development Roles" http://java.sun.com/j2ee/1.4/docs/tutorial/doc/Overview6.html :

            "For example, in the application component development phase, an enterprise bean software developer delivers EJB JAR files. In the application assembly role, another developer combines these EJB JAR files into a J2EE application and saves it in an EAR file. In the application deployment role, a system administrator at the customer site uses the EAR file to install the J2EE application into a J2EE server."

            Because there is no way for the "application assembly role" to _freely_ pick EJB JAR files from the "enterprise bean software developer". He will be getting global conflicts if an EJB JAR is assembled inside two EARs and deployed in the same server.

            Do you see my point? Reusing EJB modules accross applications is not possible. Or have I misunderstood something obvious?


            • 3. Re: application-defined resources for MDBs
              kristoffer sjögren Newbie

              I guess I continue my monolog :-)

              Let's take an example: A large organization uses ejb's to provide an infrastructure layer (messaging, persistence) to all of its products. Products which are realized as appliction ears. They might choose a buildning tool like Maven. Maven lets each project produce at most one artifact (good practice?), which could be an ejb, war, ear, jar etc. Artifacts are uploaded to a repository to be used by other projects.

              How can this infrastructure layer ever be realized if the specifics are bound to the module itself? Also, applications might have diffrent requirements on the infrastructure.

              Why not make it possible to let the application worry about assign global resources to logical names instead?

              Keep the comments coming :-)