cant it be done with mapped name? - Romain
2012/7/3 David Blevins <david.blev...@gmail.com> > > On Jul 1, 2012, at 5:11 PM, exabrial wrote: > > > Hey sorry to wake a dead thread... > > Preferred actually. Saves the time of having to dig for the old thread. > > > but I just thought of something: Does > > OpenEJB has a jndi-link feature? > > > > I don't think it does, but I know GlassFish and Resin can do it.... > > http://www.caucho.com/resin-3.0/config/env.xtp#jndi-link > > > > Would writing a custom ObjectFactory be the correct way to do this? > > > > In my frontend JSF application, in a servlet, say I had: > > > > @EJB > > MyService myService; > > > > If I wanted to link that EJB to an external context, I would put > something > > in TomEE.xml like this: > > > > <JndiProvider id="shoe" type="javax.naming.InitialContext"> > > java.naming.provider.url = ejbd://localhost:3201 > > java.naming.factory.initial = > > org.apache.openejb.client.RemoteInitialContextFactory > > </JndiProvider> > > > > <Resource id="MyService" > > type="org.apache.openejb.xxx.OpenEJBExternalJndiLink"> > > externalContext = "shoe" > > externalName="MyDeploymentId/MyService.Remote" > > </JndiProvider> > > Ignoring the <Resource> part for a moment, the best fit would likely be > something that allows you to describe the external EJB. > > The trick is when you use `@EJB` like shown above, the matching EJB is > resolved by type. The pseudo <Resource> declaration doesn't have the type > `MyService` in it anywhere and therefore wouldn't work. You'd be stuck > matching by string (id) and then what I mention before about needing to > change all your `@EJB` references to use `name` as in > `@EJB(name="MyService")` would still apply. > > So something that allows you to say, "I have an EJB of type X that you can > lookup via Y jndi name using Z <JndiProvider>" would be the most terse and > common-case solution. > > Being able to optionally specify the "ejb-name" so you could also match > with `@EJB(beanName="fooService")` would be nice. The `beanName` attribute > is used as a tie-breaker when there is more than one bean that could > satisfy an `@EJB` ref by type (e.g. say you have two beans that implement > the same @Remote interface, `@EJB` will no longer work unless you specify > `beanName`. > > Theoretically that could look something like: > > <ExternalEjb> > <interface>org.superbiz.MyService</interface> > <interface>org.superbiz.Foo</interface> > <bean-name>fooService</bean-name> > <jndi-name>FooService.Remote</jndi-name> > <jndi-provider>shoe</jndi-provider> > </ExternalEjb> > > Not crazy about the ExternalEjb element name, but that's the basic idea. > To recap: > > - @EJB is resolved by either `type` or `beanName` > - if we can provide a way to tie either a type or a bean-name to an > external ejb, we're good. > > So what we'd do is take these ExternalEjb refs and add them into the mix > when we run our "find the matching EJB for this @EJB ref" logic. > > Since we allow you to declare the actual server info in <JndiProvider>, > you could potentially do all this in code if we were to create an > equivalent annotation. Maybe something like: > > public @interface ExternalEjb { > Class[] interfaces() default {}; > String beanName() default ""; > String jndiName() default ""; > String jndiProvider() default ""; > } > > We could maybe allow you to specify that on a class or something. Or > perhaps even more clever: > > @ExternalEjb(jndiName = "FooService.Remote", jndiProvider = "shoe") > public abstract class FooService implements MyService, Foo {} > > At this point you have far less XML to maintain and having 1 to 100+ of > these external ejbs would be pretty easy as you'd only need to keep a > single `<JndiProvider id="shoe">` entry up-to-date. > > Thoughts? > > > -David > >
