Details
-
Bug
-
Resolution: Done
-
Major
-
JBossAS-4.0.0 Final, JBossAS-4.0.1RC1, JBossAS-4.0.1 Final, JBossAS-4.0.1 SP1, JBossAS-4.0.2RC1, JBossAS-4.0.2 Final, JBossAS-4.0.3RC1, JBossAS-4.0.3RC2, JBossAS-4.0.3 Final, JBossAS-4.0.3 SP1, JBossAS-4.0.4RC1
-
None
Description
JBoss features a rather subtle bug it its remoting subsystem. The problem can be reproduced under the following circumstances.
1. Suppose a number of enterprise beans residing in different J2EE applications (each represented by an .ear file) share the same remote component interface that has a method with this signature:
public boolean isConstraintSupported(Class klass) throws RemoteException;
2. Suppose further that proxies implementing remote home interfaces are registered in the container's JNDI tree under a well-known context.
3. Then imagine that an arbitrary EJB invokes the isConstraintSupported method of all enterprise beans it finds under the well-known JNDI context supplying a Class object as an argument. The Class supplied is not found in all the J2EE applications but only in some, so the bean provider is prepared to handle java.rmi.UnmarshalExceptions thrown by attempts to invoke isConstraintSupported of those enterprise beans that do not define the same Class. If, however, JBoss is configured to use scoped class loading behavior for .ear files, such a scenario will result in a RemoteException wrapping a NullPointerException instead:
com.compuware.alturadev.ejb.ConstraintHandler.isConstraintSupported(java.lang.Class)
throws java.rmi.RemoteException, causedBy:
java.lang.NullPointerException
at
org.jboss.ejb.plugins.CallValidationInterceptor.validateArguments(CallValidationInterceptor.java:58)
at
org.jboss.ejb.plugins.CallValidationInterceptor.invoke(CallValidationInterceptor.java:47)
at
org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext(AbstractTxInterceptor.java:105)
at
org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterceptorCMT.java:335)
at org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:166)
at
org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.java:139)
at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:192)
at
org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invoke(ProxyFactoryFinderInterceptor.java:122)
at org.jboss.ejb.SessionContainer.internalInvoke(SessionContainer.java:624)
at org.jboss.ejb.Container.invoke(Container.java:873)
at sun.reflect.GeneratedMethodAccessor160.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at
org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:141)
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:80)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:72)
at
org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:249)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:644)
at
org.jboss.invocation.local.LocalInvoker$MBeanServerAction.invoke(LocalInvoker.java:155)
at org.jboss.invocation.local.LocalInvoker.invoke(LocalInvoker.java:104)
at
org.jboss.invocation.InvokerInterceptor.invokeMarshalled(InvokerInterceptor.java:201)
at
org.jboss.invocation.MarshallingInvokerInterceptor.invoke(MarshallingInvokerInterceptor.java:35)
at
org.jboss.proxy.TransactionInterceptor.invoke(TransactionInterceptor.java:46)
at org.jboss.proxy.SecurityInterceptor.invoke(SecurityInterceptor.java:55)
at
org.jboss.proxy.ejb.StatelessSessionInterceptor.invoke(StatelessSessionInterceptor.java:97)
at org.jboss.proxy.ClientContainer.invoke(ClientContainer.java:86)
at $Proxy112.isConstraintSupported(Unknown Source)
at
com.compuware.alturadev.ejb.EJBUtils.queryConstraintHandlers(EJBUtils.java:177)
at cab.application.business.logic.ClassCBean.ejbRemove(ClassCBean.java:578)
Whereas it should've thrown a java.rmi.UnmarshalException. This can easily be corrected by reworking the MarshalledValue class.
I will create a support call requesting that effort be put into fixing it.