On Aug 3, 2010, at 10:58 PM, David Jencks wrote:

> On Aug 3, 2010, at 1:16 PM, David Blevins wrote:
> 
>> 
>> On Jul 15, 2010, at 5:42 PM, David Jencks wrote:
>> 
>>> I'm taking a look at implementing the ejb 3.1 jndi support for 
>>> global/app/module contexts and binding ejbs in at standard names.  I think 
>>> it might go pretty quickly since I already implemented a lot of this over 
>>> in geronimo.
>> 
>> Looks good, David.
>> 
>> I wonder if we can put back in the part where App id is equal to the 
>> standalone module id.  I assume this was done for the goofy portable EJB 
>> JNDI name syntax that cuts out part of the name if it is a standalone module 
>> vs in an ear.  I was keenly aware at spec development time that that was 
>> directly against this:
>> 
>> http://openejb.apache.org/3.0/jndi-names.html
>> 
>> Which does not handle conditionally changing the format.  Truth be told I'm 
>> not a terrible fan of dynamically changing the format of the portable name 
>> as someone on the external consuming side has no way to inquire if said EJB 
>> is in a standalone module or not and which format to use to look it up.  
>> Doing something as simple as writing a method that iterates over global JNDI 
>> listing all the EJBs suddenly becomes complicated as you have to deal with 
>> two different formats.
>> 
>> Anyway, maybe for the purposes of the portable & shrinkable syntax, we can 
>> add a boolean to AppModule/AppInfo/AppContext that communicates that it is a 
>> generated module (i.e. wrapper for a standalone module).  Maybe something 
>> like appInfo.generated=true.
>> 
> 
> I'm tired but don't understand what you want to end up with.
> 
> If you specify the appName in the javax.ejb.embeddable.appName property as 
> equal to the module name would you get the effect you want?
> 
> Could you show the jndi names you want to end up with for a couple of 
> examples?

Fixed this in this commit:  
http://svn.apache.org/viewvc?view=revision&revision=989853

Basically added a boolean to AppModule/AppInfo/AppContext so that we can track 
if the module was really part of an ear or simply wrapping a module that would 
otherwise be a standalone module.  Then in the JndiBuilder we can use the 
boolean to figure out which format to use: 
java:global/<appName>/<moduleName>/<beanName> or 
java:global/<moduleName>/<beanName>

I also switched it so that the simple name 
'java:global/<appName>/<moduleName>/<beanName>' that does not contain a 
"!<interface>" is always present.  If there are multiple views, this is the 
order of preference:

  1. LocalBean
  2. Local Business interfaces
  3. Remote Business interfaces
  4. Local Home
  5. Remote Home

The simple name is a first-come-first serve basis which is consistent with how 
the openejb.jndiname.format is treated which an also contain a format that is 
more "narrow" than the possible number of JNDI names that would be required for 
all possible views (especially if you take the spec perspective that each 
interface is its own view).


-David

Reply via email to