JBossDeveloper

In the current implementation, the InjectionHandler.addJNDIDependency(InjectionContainer container, String jndiName) needs to pass down the container.getClassLoader for use in the lookup as the thread context class loader. I'm looking at validating this fixes the current problem.

In terms of your example of multiple sources of a class, this has to be resolved based on what the deployments import/export. The deployments that source X will have to declare the class/version it exports. The deployment which consumes X will have an import statement that is matched up to a source. In the absence of an import that more specifically matches the A.jar export of X, the X found in the B.ear class loading domain should be resolved as the matching source.

Using the container class loader sounds like a solid solution.

Ah misunderstanding. I was talking about EJB business interfaces, not Java interfaces. EJB A doesn't define an import for a specific version. It only defines that it wants to use business interface X.

Looking at this in more detail, a KernelRegistryPlugin does not seem the correct way to handle this. The JNDIKernelRegistryPlugin is shared instance getting called by the kernel to resolve a name for a DemandDependency, but the registry value is not just a function of the name. Its a function of the name and the dependee's class loader. Two ejb deployments can have a reference to the same jndi name, but will have different values on lookup due to deserialization of the value using different class loaders.

There needs to be a custom DemandMetaData implementation that has a DependencyItem implementation that combines the jndi name and class loader to use for resolution during lookup. I'll see if I can get this working.

With a change to the MCDependencyPolicy to include the

 public void addJNDIName(String name, ClassLoader loader)
...
 public void addDependency(DemandMetaData dependency)
 {
 dependencies.add(dependency);
 }

public class JBoss5DependencyPolicy extends MCDependencyPolicy
{
...
 @Override
 public void addJNDIName(String name, ClassLoader loader)
 {
 this.addDependency(new JndiDemandMetaData(name, loader));
 }

I had thought JBCTS-645 was causing also the appclient/assembly failures because the produced error is the same but I just tested it and don't see any improvement.

Scott can you please look e.g. at com/sun/ts/tests/appclient/deploy/compat14_50/Client.java, do you want a separate JIRA case?

The java:comp environment for the standard ejb-management.jar modujle is not even accessible by the list operation on JNDIView:

Ejb 2.1 Module: "ejb-management.jar"
java:comp namespace of the MEJB bean:
Failed on lookup, javax.naming.NameNotFoundException: comp not boundjavax.naming.NameNotFoundException: comp not bound
 at org.jnp.server.NamingServer.getBinding(NamingServer.java:542)
 at org.jnp.server.NamingServer.getBinding(NamingServer.java:550)
 at org.jnp.server.NamingServer.getObject(NamingServer.java:556)
 at org.jnp.server.NamingServer.lookup(NamingServer.java:296)
 at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:669)
 at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:629)
 at org.jboss.naming.JNDIView.list(JNDIView.java:182)
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
 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:157)
 at org.jboss.mx.server.Invocation.dispatch(Invocation.java:96)
 at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:138)
 at org.jboss.mx.server.Invocation.invoke(Invocation.java:90)
 at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:140)
 at org.jboss.mx.server.Invocation.invoke(Invocation.java:90)
 at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
 at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:668)
 at org.jboss.jmx.adaptor.control.Server.invokeOpByName(Server.java:258)
 at org.jboss.jmx.adaptor.control.Server.invokeOp(Server.java:223)
 at org.jboss.jmx.adaptor.html.HtmlAdaptorServlet.invokeOp(HtmlAdaptorServlet.java:262)
 at org.jboss.jmx.adaptor.html.HtmlAdaptorServlet.processRequest(HtmlAdaptorServlet.java:100)
 at org.jboss.jmx.adaptor.html.HtmlAdaptorServlet.doPost(HtmlAdaptorServlet.java:82)
 at javax.servlet.http.HttpServlet.service(HttpServlet.java:710)
 at javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
 at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
 at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
 at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
 at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
 at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
 at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
 at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
 at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:177)
 at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:105)
 at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
 at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
 at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:157)
 at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
 at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:286)
 at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844)
 at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583)
 at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
 at java.lang.Thread.run(Thread.java:595)

"dimitris@jboss.org" wrote:
I had thought JBCTS-645 was causing also the appclient/assembly failures because the produced error is the same but I just tested it and don't see any improvement.

Scott can you please look e.g. at com/sun/ts/tests/appclient/deploy/compat14_50/Client.java, do you want a separate JIRA case?

Where in the ejb3 deployer code are the jndi binding created?

I can see an ejb3 ejb being deployed, but the jndi link uses the short name of the bean (which is wrong) and not the full name:

 +- appclient_dep_compat14_50_client (class: org.jnp.interfaces.NamingContext)
 | +- ejb (class: org.jnp.interfaces.NamingContext)
 | | +- TestBean[link -> TestBean] (class: javax.naming.LinkRef)

 +- appclient_deploy_compat14_50_TestBeanHome
 (proxy: $Proxy58 implements interface
 com.sun.ts.tests.appclient.deploy.compat14_50.TestBeanHome)
 +- appclient_deploy_compat14_50_TestBean
 (proxy: $Proxy56 implements interface
 com.sun.ts.tests.appclient.deploy.compat14_50.TestBean,interface
 org.jboss.ejb3.JBossProxy,interface javax.ejb.EJBObject)

"dimitris@jboss.org" wrote:
Where in the ejb3 deployer code are the jndi binding created?

I can see an ejb3 ejb being deployed, but the jndi link uses the short name of the bean (which is wrong) and not the full name:

 +- appclient_dep_compat14_50_client (class: org.jnp.interfaces.NamingContext)
 | +- ejb (class: org.jnp.interfaces.NamingContext)
 | | +- TestBean[link -> TestBean] (class: javax.naming.LinkRef)

 +- appclient_deploy_compat14_50_TestBeanHome
 (proxy: $Proxy58 implements interface
 com.sun.ts.tests.appclient.deploy.compat14_50.TestBeanHome)
 +- appclient_deploy_compat14_50_TestBean
 (proxy: $Proxy56 implements interface
 com.sun.ts.tests.appclient.deploy.compat14_50.TestBean,interface
 org.jboss.ejb3.JBossProxy,interface javax.ejb.EJBObject)

The env lookup the client is doing is not even used so I dropped that. The issue is the invalid links. This appears to be an issue with the org.jboss.ejb.EjbUtil50 logic being out of synch with the ejb3 binding logic as the ejbName is being resolved there.

For this particular test it seems appclient_dep_compat14_50_ejb.jar.sun-ejb-jar.xml is also wrong,

<jndi-name>appclient_deploy_compat12_13_TestBean</jndi-name>

<jndi-name>appclient_deploy_compat14_50_TestBean</jndi-name>

The sun-ejb-jar.xml/jndi-name should not matter. Both the jboss-client.xml jndi-name and application-client display-name are appclient_dep_compat14_50_client.

The problem is the logic for resolving an ejb-ref from a 1.4 appclient knows nothing about the ejb3 deployment types. The issue is:
http://jira.jboss.com/jira/browse/JBCTS-654