[Design of EJB 3.0] - Re: Non-deterministic Default JNDI Name
by ALRubinger
"jaikiran" wrote : Any specific reason why we need to know the "default" jndiname?
Turns out: I don't think so. I ran into this while going through out @RemoteBinding handling to ensure all the bindings were made, and thought this might turn into a hitch of some type.
"jaikiran" wrote : Aren't we going to treat all jndi names equally?
Not all. :)
That example makes for two bindings for the "Default Remote Business Interface using the default interceptor stack and remoting to the default Connector". So it turns out we can pick either for the "Default JNDI Name".
But some explicit @RemoteBindings will have different properties.
Further, there's the interface-specific bindings which may be invoked upon to get SessionContext.getInvokedBusinessInterface(). The intention is not to look these up directly, but they're the injection targets for the ENC of each component.
S,
ALR
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4182067#4182067
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4182067
16 years, 3 months
[Design of POJO Server] - [jboss-metadata] Additional post-merge processing
by ALRubinger
Much like the ValidatorChain I've just introduced (JBMETA-118), we need to allow for a chain of post-processors upon metadata to arbitrarily muck around. I've got two use cases:
1) @LocalBinding.jndiBinding value should be set to JBossSessionBeanMetaData.localJndiName. Currently this is done directly in LocalBindingProcessor, but this bypasses a LocalBindingMetaData object view entirely (JBMETA-119). A better solution would be for LocalBindingProcessor to create the full object model, and have the local jndi name set to the proper value as a post-processing task.
2) "EJB3 Core Spec 4.6.6" wrote : If bean class implements a single interface, that interface is assumed to be the business interface of the bean. This business interface will be a local interface unless the
| interface is designated as a remote business interface by use of the Remote annotation on the bean class or interface or by means of the deployment descriptor.
The current implementation has a problem: the first pass is done on annotation-based metadata, which will default the local business interface if none is explicitly marked. However, it may be XML that's marking as @Remote, in which case we end up with both a local and remote business interface of the same type, which is a violation of spec:
"EJB3 Core Spec 4.6.6" wrote : The same business interface cannot be both a local and a remote business interface of the bean.
So I'm going to look into adding a PostProcessingChain to run on fully parsed and merged metadata, much like ValidatorChain does now. I'm thinking also that Validation is a specific type of processing, and that the two might be combined for simplicity's sake. I'll head that route if I can get the APIs to remain friendly for both purposes.
S,
ALR
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4182064#4182064
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4182064
16 years, 3 months