geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject [jira] Closed: (GERONIMO-131) Remove nullification of DD's locations when the standard DD doesn't exist
Date Sun, 01 Aug 2004 20:25:40 GMT

   The following issue has been closed.

   Resolver: David Jencks
       Date: Sun, 1 Aug 2004 1:24 PM

There is now completely different code looking for the deployment descriptors, and it tries
to generate a default geronimo dd if none is supplied (except for ra, where it doesn't make
sense IMO).
View the issue:

Here is an overview of the issue:
        Key: GERONIMO-131
    Summary: Remove nullification of DD's locations when the standard DD doesn't exist
       Type: Improvement

     Status: Closed
   Priority: Minor
 Resolution: FIXED

    Project: Apache Geronimo

   Assignee: David Jencks
   Reporter: Jacek Laskowski

    Created: Sun, 14 Dec 2003 5:03 PM
    Updated: Sun, 1 Aug 2004 1:24 PM

I spent the whole weekend to eventually find out that Geronimo deploys a deployment unit only
when it contains *two* required files: one that's mandated by the appropriate spec and the
other one - Geronimo-specific. So, when a EJB bean is deployed two files must exist - /META-INF/ejb-jar.xml
and /META-INF/geronimo-ejb-jar.xml, otherwise it won't be deployed at all (and unfortunatelly
no message is printed out about it on the console). What caused me to think about having only
one? Just take a look at org.openejb.nova.deployment.EJBModuleDeploymentPlanner that checks
whether geronimo-ejb-jar.xml exists and also a few lines below is the comment: "currently
everything is in the geronimo-ejb-jar.xml". 

However, o.a.g.kernel.deployment.DeploymentHelper always returns null upon being asked about
standard or geronimo DD when the standard DD is not available (see one of the constructor).
Therefore, DeploymentHelper decides if a module is deployable or not. I think it is not in
charge of giving the answer. The right of answering the question belongs to a planner, thus
the change.

I also change a bit the class's javadoc. 

This message is automatically generated by JIRA.

If you think it was sent incorrectly contact one of the administrators:

If you want more information on JIRA, or have a bug to report see:

View raw message