geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Blevins <david.blev...@visi.com>
Subject Re: [DISCUSS] G 2.0.2 Release plan
Date Fri, 28 Sep 2007 02:14:17 GMT

On Sep 26, 2007, at 4:01 PM, Kevan Miller wrote:

>
> On Sep 25, 2007, at 6:40 PM, David Blevins wrote:
>
>>
>> On Sep 25, 2007, at 7:38 AM, Kevan Miller wrote:
>>
>>> One thing I've noticed -- the default JNDI name for EJB's has  
>>> been changed in OpenEJB. So, there is a compatibility issue with  
>>> 2.0.1. We might be able to configure how OpenEJB generates this  
>>> default to maintain backward compatibility. Better, IMO, to go  
>>> ahead and match OpenEJB's behavior.
>>
>> There are no compatibility issues as it was explicitly set in  
>> Geronimo 2.0.1 to be essentially {moduleId}/{ejbName}/ 
>> {interfaceClass}  (actually it's {deploymentId}/{interfaceClass}  
>> and deploymentId will be {moduleId}/{ejbName}).  It'll still be  
>> the same in Geronimo 2.0.2, just now it can be changed to  
>> something shorter.
>
> Well, that's encouraging. However, something has changed between  
> 2.0.1 and 2.0.2. Can you help explain the following?
>
> INFO log during 2.0.1 deploy:
>
> 18:45:13,785 INFO  [config] Configuring app: GeneralEJB.jar
> 18:45:13,849 INFO  [OpenEJB] Auto-deploying ejb My: EjbDeployment 
> (deployment-id=GeneralEJB.jar/My, container-id=null)
> 18:45:14,066 INFO  [config] Loaded Module: GeneralEJB.jar
> 18:45:16,653 INFO  [Enhance] You have enabled runtime enhancement,  
> but have not specified the set of persistent classes.  OpenJPA must  
> look for metadata for every loaded class, which might increase  
> class load times significantly.
> 18:45:17,021 INFO  [startup] Assembling app: /geronimo-jetty6- 
> jee5-2.0.1/var/temp/geronimo-deploymentUtil24358.jar
> 18:45:17,375 INFO  [startup] Jndi(name=GeneralEJB.jar/My/ejbs.My)
> 18:45:17,375 INFO  [startup] Created Ejb(deployment- 
> id=GeneralEJB.jar/My, ejb-name=My, container=Default Stateless  
> Container)
>
> INFO log during 2.0.2-SNAPSHOT deploy:
>
> 18:52:08,701 INFO  [config] Configuring app: sibc/ejb/7.0.0/ear
> 18:52:08,936 INFO  [OpenEJB] Auto-deploying ejb My: EjbDeployment 
> (deployment-id=GeneralEJB.jar/My)
> 18:52:09,281 INFO  [config] Loaded Module: sibc/ejb/7.0.0/ear
> 18:52:11,467 INFO  [Enhance] You have enabled runtime enhancement,  
> but have not specified the set of persistent classes.  OpenJPA must  
> look for metadata for every loaded class, which might increase  
> class load times significantly.
> 18:52:11,977 INFO  [startup] Assembling app: /Users/kevan/geronimo/ 
> server/branches/2.0/target/geronimo-jetty6-jee5-2.0.2-SNAPSHOT/var/ 
> temp/geronimo-deploymentUtil14898.jar
> 18:52:12,440 INFO  [startup] Jndi(name=GeneralEJB.jar/My/ 
> ejbs.MyHome) --> Ejb(deployment-id=GeneralEJB.jar/My)
> 18:52:12,447 INFO  [startup] Created Ejb(deployment- 
> id=GeneralEJB.jar/My, ejb-name=My, container=Default Stateless  
> Container)
>
> Note the different JNDI names...

Looks like there's a change there (value of interfaceClass) I had  
thought went in before 2.0.1 was shipped.  The interfaceClass  
variable now refers to the interface you get when you do a lookup, so  
the EJBHome, EJBLocalHome or business interface such that if you set  
your jndiname format to simply "{interfaceClass}" and did something  
like this in code:

     MyHome home = (MyHome) ctx.lookup(MyHome.class.getName());

It would work.  Or if you wanted to implement a java generic service- 
locator in you could set your jndiname format to something like  
"{ejbName}/{interfaceClass}" you could do:

     public <T> T getComponent(String ejbName, Class<T> type) {
         return (T)ctx.lookup(ejbName+"/"+type.getName());
     }

     MyHome home = getComponent("FooBean", MyHome.class);

You get the idea.

Anyway, it's up to us how we want to deal with this in Geronimo.   
It's actually possible for us to replace this part of the system and  
plugin in something that does whatever we like.  We could go with the  
change now and warn users, we could grab a copy of the old formatter  
and plug it in replacing the updated formatter and use it till 2.0.x  
is done (or longer i guess), or provide some other custom option.

(fyi, all of this is doable with trunk or 3.0-beta-1)

Anyone have any preferences or thoughts?

-David



Mime
View raw message