[Design of EJB 3.0] - Re: Classloading problem in proxy factories
by bstansberry@jboss.com
Re: closing EJBTHREE-1471: I think there's still something to be understood here. For sure to get this to work you had to catch LinkageError, and that tells us there's two different classloaders in place. The concern I have is if the TCL is longer-lasting than the EJB CL, the business interface class it loads leaks.
Ah, of course the classloader leak tests pass -- they test for the EJB CL leaking, not the business interface class loaded via a different CL. In this case the classloader associated with the remoting connector.
OK, I think I'm clear on this now. :) EJBTHREE-1471 doesn't leak to EJB CL. It does pollute the proxy cache associated with the remoting connector's CL with a proxy associated with version A of the business interface. If you redeploy the EJB, the remoting CL's proxy cache is now corrupt. Your LinkageError catch makes the proxy creation usable, but you've still got a corrupt proxy cache. Maybe that's acceptable, but if something like the the check I suggested a few posts back can be added, it would be cleaner. May be a bit slower (or a bit faster) before a redeploy, but faster after, since it avoids trying to create a proxy that's just going to fail w/ LinkageError.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4173110#4173110
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4173110
16 years
[Design of JBoss Transaction Services] - Re: TransactionManager and AS' ServiceBindingManager
by bstansberry@jboss.com
Yes and no. There is an overloaded constructor with 4 params; the third is the host name and accepts null:
| <constructor>
| <parameter>TransactionManager</parameter>
| <parameter>socketProcessId</parameter>
| <parameter><null/></parameter>
| <parameter>10001</parameter>
| </constructor>
|
ServiceBinding actually exposes two getters related to the hostname passed to the constructor:
String getHostName() -- simple getter
InetAddress getBindAddress() -- derived from hostname
The first is a simple getter of what's passed in; the second is derived from hostname:
this.bindAddress = InetAddress.getByName(hostName);
InetAddress.getByName() will return the loopback address if passed null; so in your case calling getBindAddress() will return the loopback address, not null.
That could probably be changed to return null; I didn't think about it much when I rewrote SBM; just left in place the existing behavior.
Of course, what getBindAddress() returns only matters if someone invokes on SBM asking for it, which I imagine JBossTS won't be doing. :-)
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4173097#4173097
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4173097
16 years
[Design of EJB 3.0] - Annotation processing without top-level annotation
by emuckenhuber
It seems that we are missing one use case of annotation processing.
e.g. if you specify a stateful bean in the ejb-jar.xml and have a bean without a top-level annotation like:
| public class RemoveBean
| {
| @Remove
| public void remove()
| {
| }
| }
|
As it is now the Stateful annotation processor requires a top-level @Stateful annotation to be able to create the metadata.
Therefore the annotation deployer only looks for those top-level annotations - which makes sense, as this annotation is required to create the correct metaData with ejbName and ejbClass.
To work around this problem we would need to skip this top-level processing and create the metaData based on the xml metaData.
So in more detail what needs to be added to the JBoss50Creator is something like:
| public JBoss50MetaData create(Collection<Class<?>> classes)
| {
| // Create meta data
| JBoss50MetaData metaData = create();
|
| for(EnterpriseBeanMetaData bean : ejbJarMetaData.getEnterpriseBeans())
| {
| Class<?> ejbClass = classLoader.loadClass(bean.getEjbClass());
| if(! classes.contains(ejbClass))
| {
| if(bean.isSession())
| {
| SessionBeanMetaData sb = (SessionBeanMetaData) bean;
| JBossSessionBeanMetaData sessionBean = new JBossSessionBeanMetaData();
| sessionBean.setEjbName(sb.getEjbName());
| sessionBean.setEjbClass(sb.getEjbClass());
| if(sb.isStateful())
| {
| StatefulProcessor processor = new StatefulProcessor(finder);
| sessionBean.setSessionType(SessionType.Stateful);
| processor.process(sessionBean, ejbClass);
| metaData.getEnterpriseBeans().add(sessionBean);
| }
| else
| {
| sessionBean.setSessionType(SessionType.Stateless);
| // ...
| }
| }
| else if(bean.isMessageDriven())
| {
| // ...
| }
| }
| }
|
| processMetaData(classes, metaData);
| return metaData;
| }
|
This (not compiled prototype) basically processes every class defined in the xml if not already picked up by the annotationDeployer.
I think this should be handled differently in future, but i would consider that as last minute workaround :)
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4173076#4173076
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4173076
16 years