Forgot to say, I am using JBoss 4.0.1
What exactly are you trying to do? Deploying two ears on an application server is not a problem. If they are the same ear then you need to resolve any global resource conflicts they might introduce (such as global JNDI lookup names). Only if you suspect you need to use different class versions in the ears should you need to look at classloader isolation.
I have the same problem with 4.0.2 version. However 4.0.0 and 3.2.4 works fine.
Can anyone from JBoss explain why?
We have the same problem (Invalid Invocation ...) on calling a home.create() on a SLSB in another ear :( (JBoss 4.0.1)
BTW: We want to develop components independently within several ears and connect them through JNDI. We expected this should be simplest task for a J2EE server....But we are new to J2EE/JBoss and looking for the wrong solution?
Has anybody an idea?
ejensen, does your problem beeing solved?
I'm realy stumped...
We're having the same problem in 4.0.2. We need to use remote invocation between ears because the ears may or may not be deployed in the same JBoss instance at a customer site.
I don't want to use external references in the ejb-jar.xml, because we read our configuration in and prefer to dynamically construct the JNDI lookup at runtime.
The code is the same as that used by one of our standalone Java apps that connects successfully, as well as another ear-to-ear case that works.
The difference here is that the client is an MDB. The Ear it's invoking containing a stateless session bean is isolated. If the MDB's ear is not isolated, it produces the Invalid invocation. If the ear with the MDB is isolated, it produces:
18:14:22,897 WARN [verifier] EJB spec violation: Bean : SubscriberBatchBean Section: 15.7.4 Warning: The message driven bean must declare one onMessage() method. 18:14:22,897 ERROR [MainDeployer] could not create deployment: file:/C:/Programs/JBoss/jboss-4.0.2_n ewtest/server/default/tmp/deploy/tmp209594Subscriber.ear-contents/ejb-rdbms.jar org.jboss.deployment.DeploymentException: Verification of Enterprise Beans failed, see above for err or messages. at org.jboss.ejb.EJBDeployer.create(EJBDeployer.java:553) at org.jboss.deployment.MainDeployer.create(MainDeployer.java:918) at org.jboss.deployment.MainDeployer.create(MainDeployer.java:910) at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:774) at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:738) at sun.reflect.GeneratedMethodAccessor47.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.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:121) at org.jboss.mx.server.Invocation.invoke(Invocation.java:74) at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterce ptor.java:127) at org.jboss.mx.server.Invocation.invoke(Invocation.java:74) at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:249) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:644) at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:177) at $Proxy8.deploy(Unknown Source) at org.jboss.deployment.scanner.URLDeploymentScanner.deploy(URLDeploymentScanner.java:325) at org.jboss.deployment.scanner.URLDeploymentScanner.scan(URLDeploymentScanner.java:501) at org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.doScan(AbstractDeplo ymentScanner.java:204) at org.jboss.deployment.scanner.AbstractDeploymentScanner.startService(AbstractDeploymentSca nner.java:277) at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanSupport.java:272) at org.jboss.system.ServiceMBeanSupport.jbossInternalLifecycle(ServiceMBeanSupport.java:222) ...
It's worth noting that we're using the prefix deployment sorter, which is not the default. This shouldn't matter, but it's possible that it invokes different code. You can see that it's part of the stacktrace above.