On Oct 16, 2008, at 7:23 AM, Alex Grönholm wrote:
In order to achieve compliancy with the EJB 3.1 global JNDI
namespace requirements, the "app-name" of an application (.ear
packaged) must be made available to
org.apache.openejb.assembler.classic.JndiBuilder. In my opinion,
this would be best achieved by setting applicationID (a new
property) in DeploymentInfo (and as a consequence,
CoreDeploymentInfo).
I will also add a new JNDI template parameter, applicationId.
That's a good start. We'll need to also add an "appId" field to the
AppInfo object and fill it with the data from AppModule.getModuleId().
The tricky part is that there always will be an applicationId as we
generate an AppInfo for everything that's deployed regardless of it's
structure (ear, collapsed ear, plain ejb jar, etc.). So implementing
the rule where there's a different global jndi name based on if the
ejbjar is in an ear or not will be less straightforward. That said,
the whole concept of having two sets of rules for in ear and out of
ear is being disputed in the Expert Group so I'm not sure we should
spend any time adding it now. I think for the first revision we
should just always apply the applicationId to the jndi name.
I'm still trying to locate the part in
org.apache.openejb.assembler.classic.Assembler that deploys an .ear
package.
This method: createApplication(AppInfo appInfo, ClassLoader
classLoader, boolean start)
The basic flow is:
File jarFile = ...
AppInfo appInfo = configurationFactory.configureApplication(jarFile);
assembler.createApplication(appInfo);
Here's an overview of the split:
http://openejb.apache.org/configuration-and-assembly.html
I just have to say that this class (among some others) is a mess.
It's a mish-mash of fields and methods here and there with little to
no documentation or organization. I think some kind of mutually
agreed coding standards would certainly help hold this project
together and decrease the learning curve for newbies (such as myself).
You're definitely welcome to do some reformatting. We have a general
guideline on the project of not including functional changes with
major reformatting as it makes it really really hard to spot the real
change amongst the other more cosmetic changes. So if you feel like
doing any reformatting, definitely submit that as a separate patch.
-David
