[manemannen]

Java version;

java version "1.6.0_06"
Java(TM) SE Runtime Environment (build 1.6.0_06-b02)
Java HotSpot(TM) Server VM (build 10.0-b22, mixed mode)

and I am using Eclipse which handles the deploy. I will test your suggestion with Java 1.5 and deploy manually.

[manemannen]

I tried java 1.5 instead and I deployed it manually on my other jboss installation....same problem ;)

I know that this is a common problem for many newbies like myself and one would think that there should be some examples on how to handle it. Although I can't seem to find them.

[jaikiran]

At this point, this looks like a bean deployment problem rather than a classloader issue. The JNDI tree output suggests that the bean proxies are bound correctly. So let's remove the WAR file from the picture and just try deploying the EAR file containing the EJB jar. Try this:

- Remove the WAR file from the deploy folder
- Copy the EAR (containing the ejb jar) to the deploy folder
- Start JBoss
- Post the deployment logs from the server.log file. Please ensure that you post the logs only from the point when your application deployment starts. The server.log is too verbose and posting the entire logs here wont be useful :-)
- Also please access the JNDI tree again after the deployment is done and post the output here again. Just want to see how the JNDI contents for this bean look like when the WAR is not in picture.

[manemannen]

Thanks for all the help Jaikiran!

War file removed and the EAR is deployed. Below is the new JNDI tree (I removed the local interface for the bean to narrow it down even more). It seems i'm still stuck with the wierd "remote" treeitem.

Global JNDI Namespace

+- TopicConnectionFactory (class: org.jboss.naming.LinkRefPair)
 +- jmx (class: org.jnp.interfaces.NamingContext)
 | +- invoker (class: org.jnp.interfaces.NamingContext)
 | | +- RMIAdaptor (proxy: $Proxy47 implements interface org.jboss.jmx.adaptor.rmi.RMIAdaptor,interface org.jboss.jmx.adaptor.rmi.RMIAdaptorExt)
 | +- rmi (class: org.jnp.interfaces.NamingContext)
 | | +- RMIAdaptor[link -> jmx/invoker/RMIAdaptor] (class: javax.naming.LinkRef)
 +- HTTPXAConnectionFactory (class: org.jboss.mq.SpyXAConnectionFactory)
 +- ConnectionFactory (class: org.jboss.mq.SpyConnectionFactory)
 +- UserTransactionSessionFactory (proxy: $Proxy15 implements interface org.jboss.tm.usertx.interfaces.UserTransactionSessionFactory)
 +- HTTPConnectionFactory (class: org.jboss.mq.SpyConnectionFactory)
 +- simpleserver (class: org.jnp.interfaces.NamingContext)
 | +- SimpleStatefulBean (class: org.jnp.interfaces.NamingContext)
 | | +- remote (class: java.lang.Object)
 | | +- remoteStatefulProxyFactory (proxy: $Proxy65 implements interface org.jboss.ejb3.ProxyFactory)
 +- XAConnectionFactory (class: org.jboss.mq.SpyXAConnectionFactory)
 +- TransactionSynchronizationRegistry (class: com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionSynchronizationRegistryImple)
 +- UserTransaction (class: org.jboss.tm.usertx.client.ClientUserTransaction)
.
.
.

The log is pretty massive even if i'm only pasting the stuff about simple-ejb. I removed the time stamps to improve readability....

[org.jboss.deployment.EARDeployer] Extracted deployable content: simple-ejb.jar
[org.jboss.deployment.EARDeployer] Deployment Info: org.jboss.deployment.DeploymentInfo@fb542263 { url=file:/home/magnus/Desktop/jboss-4.2.3.GA-jdk6/jboss-4.2.3.GA/server/default/tmp/deploy/tmp17014simpleserver.ear-contents/simple-ejb.jar }
 deployer: null
 status: null
 state: CONSTRUCTED
 watch: file:/home/magnus/Desktop/jboss-4.2.3.GA-jdk6/jboss-4.2.3.GA/server/default/tmp/deploy/tmp17014simpleserver.ear-contents/simple-ejb.jar
 altDD: null
 lastDeployed: 0
 lastModified: 0
 mbeans:
, isDirectory: false
[org.jboss.mx.loading.RepositoryClassLoader] setRepository, repository=org.jboss.mx.loading.HeirarchicalLoaderRepository3@1a21389, cl=org.jboss.mx.loading.UnifiedClassLoader3@1b0bf9a{ url=null ,addedOrder=0}
[org.jboss.deployment.DeploymentInfo] createLoaderRepository from config: LoaderRepositoryConfig(repositoryName: com.test:archive=simpleserver.ear, repositoryClassName: org.jboss.mx.loading.HeirarchicalLoaderRepository3, configParserClassName: null, repositoryConfig: null)
[org.jboss.mx.loading.RepositoryClassLoader] setRepository, repository=org.jboss.mx.loading.HeirarchicalLoaderRepository3@1a21389, cl=org.jboss.mx.loading.UnifiedClassLoader3@f32dde{ url=file:/home/magnus/Desktop/jboss-4.2.3.GA-jdk6/jboss-4.2.3.GA/server/default/tmp/deploy/tmp17014simpleserver.ear ,addedOrder=0}
[org.jboss.mx.loading.RepositoryClassLoader] setRepository, repository=org.jboss.mx.loading.HeirarchicalLoaderRepository3@1a21389, cl=org.jboss.mx.loading.UnifiedClassLoader3@f32dde{ url=file:/home/magnus/Desktop/jboss-4.2.3.GA-jdk6/jboss-4.2.3.GA/server/default/tmp/deploy/tmp17014simpleserver.ear ,addedOrder=0}
[org.jboss.mx.loading.UnifiedLoaderRepository3] Adding org.jboss.mx.loading.UnifiedClassLoader3@f32dde{ url=file:/home/magnus/Desktop/jboss-4.2.3.GA-jdk6/jboss-4.2.3.GA/server/default/tmp/deploy/tmp17014simpleserver.ear ,addedOrder=0}
[org.jboss.deployment.MainDeployer] found 1 subpackages of file:/home/magnus/Desktop/jboss-4.2.3.GA-jdk6/jboss-4.2.3.GA/server/default/deploy/simpleserver.ear
[org.jboss.deployment.MainDeployer] Starting deployment (init step) of package at: file:/home/magnus/Desktop/jboss-4.2.3.GA-jdk6/jboss-4.2.3.GA/server/default/tmp/deploy/tmp17014simpleserver.ear-contents/simple-ejb.jar
[org.jboss.deployment.MainDeployer] using deployer MBeanProxyExt[jboss.ejb3:service=EJB3Deployer]
[org.jboss.ejb3.EJB3Deployer] looking for nested deployments in : file:/home/magnus/Desktop/jboss-4.2.3.GA-jdk6/jboss-4.2.3.GA/server/default/tmp/deploy/tmp17014simpleserver.ear-contents/simple-ejb.jar
[org.jboss.mx.loading.RepositoryClassLoader] Added url: file:/home/magnus/Desktop/jboss-4.2.3.GA-jdk6/jboss-4.2.3.GA/server/default/tmp/deploy/tmp17014simpleserver.ear-contents/simple-ejb.jar, to ucl: org.jboss.mx.loading.UnifiedClassLoader3@f32dde{ url=file:/home/magnus/Desktop/jboss-4.2.3.GA-jdk6/jboss-4.2.3.GA/server/default/tmp/deploy/tmp17014simpleserver.ear ,addedOrder=43}
[org.jboss.deployment.MainDeployer] resolveLibraries:
[org.jboss.deployment.MainDeployer] found 0 subpackages of file:/home/magnus/Desktop/jboss-4.2.3.GA-jdk6/jboss-4.2.3.GA/server/default/tmp/deploy/tmp17014simpleserver.ear-contents/simple-ejb.jar
[org.jboss.deployment.MainDeployer] Watching new file: file:/home/magnus/Desktop/jboss-4.2.3.GA-jdk6/jboss-4.2.3.GA/server/default/deploy/simpleserver.ear
[org.jboss.deployment.MainDeployer] create step for deployment file:/home/magnus/Desktop/jboss-4.2.3.GA-jdk6/jboss-4.2.3.GA/server/default/deploy/simpleserver.ear
[org.jboss.deployment.MainDeployer] create step for deployment file:/home/magnus/Desktop/jboss-4.2.3.GA-jdk6/jboss-4.2.3.GA/server/default/tmp/deploy/tmp17014simpleserver.ear-contents/simple-ejb.jar
[org.jboss.ejb3.EJB3Deployer] create, simple-ejb.jar
[org.jboss.ejb3.EJB3Deployer] Deploying: file:/home/magnus/Desktop/jboss-4.2.3.GA-jdk6/jboss-4.2.3.GA/server/default/tmp/deploy/tmp17014simpleserver.ear-contents/simple-ejb.jar
[org.jboss.system.ServiceController] Creating service jboss.j2ee:service=EJB3,module=simple-ejb.jar
[org.jboss.ejb3.Ejb3Module] Creating jboss.j2ee:service=EJB3,module=simple-ejb.jar
[org.jboss.mx.loading.RepositoryClassLoader] setRepository, repository=org.jboss.mx.loading.HeirarchicalLoaderRepository3@1a21389, cl=org.jboss.mx.loading.HeirarchicalLoaderRepository3$CacheClassLoader@1d761d0{ url=null ,addedOrder=0}
[org.jboss.mx.loading.RepositoryClassLoader] setRepository, repository=org.jboss.mx.loading.HeirarchicalLoaderRepository3@1a21389, cl=org.jboss.mx.loading.HeirarchicalLoaderRepository3$CacheClassLoader@1423820{ url=null ,addedOrder=0}
[org.jboss.ejb3.Ejb3AnnotationHandler] found EJB3: ejbName=SimpleStatefulBean, class=com.test.SimpleStatefulBean, type=STATEFUL
[org.jboss.mx.loading.RepositoryClassLoader] setRepository, repository=org.jboss.mx.loading.HeirarchicalLoaderRepository3@1a21389, cl=org.jboss.mx.loading.HeirarchicalLoaderRepository3$CacheClassLoader@1eb8f6d{ url=null ,addedOrder=0}
[org.jboss.mx.loading.RepositoryClassLoader] setRepository, repository=org.jboss.mx.loading.HeirarchicalLoaderRepository3@1a21389, cl=org.jboss.mx.loading.HeirarchicalLoaderRepository3$CacheClassLoader@d3f189{ url=null ,addedOrder=0}
[org.jboss.ejb3.Ejb3Deployment] EJB3 deployment time took: 101
[org.jboss.ejb3.Ejb3Module] Created jboss.j2ee:service=EJB3,module=simple-ejb.jar
[org.jboss.system.ServiceController] Creating dependent components for: jboss.j2ee:service=EJB3,module=simple-ejb.jar dependents are: []
[org.jboss.deployment.MainDeployer] Done with create step of deploying simple-ejb.jar
[org.jboss.system.ServiceController] Creating service jboss.j2ee:service=EARDeployment,url='simpleserver.ear'
[org.jboss.deployment.EARDeployment] Creating jboss.j2ee:service=EARDeployment,url='simpleserver.ear'
[org.jboss.deployment.EARDeployment] Created jboss.j2ee:service=EARDeployment,url='simpleserver.ear'
[org.jboss.system.ServiceController] Creating dependent components for: jboss.j2ee:service=EARDeployment,url='simpleserver.ear' dependents are: []
[org.jboss.deployment.MainDeployer] Done with create step of deploying simpleserver.ear
[org.jboss.deployment.MainDeployer] Begin deployment start file:/home/magnus/Desktop/jboss-4.2.3.GA-jdk6/jboss-4.2.3.GA/server/default/deploy/simpleserver.ear
[org.jboss.deployment.MainDeployer] Begin deployment start file:/home/magnus/Desktop/jboss-4.2.3.GA-jdk6/jboss-4.2.3.GA/server/default/tmp/deploy/tmp17014simpleserver.ear-contents/simple-ejb.jar
[org.jboss.ejb3.EJB3Deployer] start application, deploymentInfo: org.jboss.deployment.DeploymentInfo@fb542263 { url=file:/home/magnus/Desktop/jboss-4.2.3.GA-jdk6/jboss-4.2.3.GA/server/default/tmp/deploy/tmp17014simpleserver.ear-contents/simple-ejb.jar }
 deployer: MBeanProxyExt[jboss.ejb3:service=EJB3Deployer]
 status: Starting
 state: START_DEPLOYER
 watch: file:/home/magnus/Desktop/jboss-4.2.3.GA-jdk6/jboss-4.2.3.GA/server/default/tmp/deploy/tmp17014simpleserver.ear-contents/simple-ejb.jar
 altDD: null
 lastDeployed: 1227186113255
 lastModified: 1227186113000
 mbeans:
, short name: simple-ejb.jar, parent short name: simpleserver.ear
[org.jboss.system.ServiceController] starting service jboss.j2ee:service=EJB3,module=simple-ejb.jar
[org.jboss.ejb3.Ejb3Module] Starting jboss.j2ee:service=EJB3,module=simple-ejb.jar
[org.jboss.mx.loading.RepositoryClassLoader] setRepository, repository=org.jboss.mx.loading.HeirarchicalLoaderRepository3@1a21389, cl=org.jboss.mx.loading.HeirarchicalLoaderRepository3$CacheClassLoader@9576fd{ url=null ,addedOrder=0}
[org.jboss.mx.loading.RepositoryClassLoader] setRepository, repository=org.jboss.mx.loading.HeirarchicalLoaderRepository3@1a21389, cl=org.jboss.mx.loading.HeirarchicalLoaderRepository3$CacheClassLoader@b6e385{ url=null ,addedOrder=0}
[org.jboss.mx.loading.RepositoryClassLoader] setRepository, repository=org.jboss.mx.loading.HeirarchicalLoaderRepository3@1a21389, cl=org.jboss.mx.loading.HeirarchicalLoaderRepository3$CacheClassLoader@9fa12f{ url=null ,addedOrder=0}
[org.jboss.ejb3.EJBContainer] Initialising interceptors for SimpleStatefulBean...
[org.jboss.ejb3.EJBContainer] Default interceptors: null
[org.jboss.ejb3.EJBContainer] Class interceptors: []
[org.jboss.ejb3.EJBContainer] All applicable interceptor classes: []
[org.jboss.ejb3.interceptor.EJB3InterceptorsFactory] Bound interceptors for joinpoint: public boolean com.test.SimpleStatefulBean.isSimple() - [Lorg.jboss.ejb3.interceptor.InterceptorInfo;@1a896a4
[org.jboss.ejb3.JmxKernelAbstraction] creating wrapper delegate for: org.jboss.ejb3.stateful.StatefulContainer
[org.jboss.ejb3.JmxKernelAbstraction] installing MBean: jboss.j2ee:ear=simpleserver.ear,jar=simple-ejb.jar,name=SimpleStatefulBean,service=EJB3 with dependencies:
[org.jboss.system.ServiceController] Creating service jboss.j2ee:ear=simpleserver.ear,jar=simple-ejb.jar,name=SimpleStatefulBean,service=EJB3
[org.jboss.system.ServiceController] adding depends in ServiceController.register: []
[org.jboss.ejb3.stateful.StatefulDelegateWrapper] Creating jboss.j2ee:ear=simpleserver.ear,jar=simple-ejb.jar,name=SimpleStatefulBean,service=EJB3
[org.jboss.ejb3.ProxyDeployer] no declared remote bindings for : SimpleStatefulBean
[org.jboss.ejb3.ProxyDeployer] there is remote interfaces for SimpleStatefulBean
[org.jboss.ejb3.ProxyDeployer] default remote binding has jndiName of simpleserver/SimpleStatefulBean/remote
[org.jboss.ejb3.stateful.StatefulDelegateWrapper] Created jboss.j2ee:ear=simpleserver.ear,jar=simple-ejb.jar,name=SimpleStatefulBean,service=EJB3
[org.jboss.system.ServiceController] Creating dependent components for: jboss.j2ee:ear=simpleserver.ear,jar=simple-ejb.jar,name=SimpleStatefulBean,service=EJB3 dependents are: []
[org.jboss.system.ServiceController] starting service jboss.j2ee:ear=simpleserver.ear,jar=simple-ejb.jar,name=SimpleStatefulBean,service=EJB3
[org.jboss.ejb3.stateful.StatefulDelegateWrapper] Starting jboss.j2ee:ear=simpleserver.ear,jar=simple-ejb.jar,name=SimpleStatefulBean,service=EJB3
[org.jboss.ejb3.tx.UserTransactionImpl] new UserTx: org.jboss.ejb3.tx.UserTransactionImpl@1be513c
[org.jboss.ejb3.interceptor.EJB3InterceptorsFactory] Bound interceptors for joinpoint: public boolean com.test.SimpleStatefulBean.isSimple() - [Lorg.jboss.ejb3.interceptor.InterceptorInfo;@b245dc
[org.jboss.ejb3.EJBContainer] STARTED EJB: com.test.SimpleStatefulBean ejbName: SimpleStatefulBean

[jaikiran]

+- simpleserver (class: org.jnp.interfaces.NamingContext)
 | +- SimpleStatefulBean (class: org.jnp.interfaces.NamingContext)
 | | +- remote (class: java.lang.Object)

I setup a simple stateful session bean in a EAR on my local 4.2.3 GA setup and my JNDI tree too looked the same. I then looked up simpleserver/SimpleStatefulBean/remote through my code and casted it to my stateful remote interface. It worked. So i guess the JNDI tree output isn't something that we should be worried about.

The reason i was surprised when i saw this earlier was because the object bound at simpleserver/SimpleStatefulBean/remote does not show the interface types the proxy implements (unlike the stateless session beans). I guess its as per design.

Now let me try to introduce a separate WAR file into picture and try and get the classcast issue reproduced.

[jaikiran]

I could reproduce this on my setup. Here's how my ear and war (which are deployed separately) look like:

EAR

myapp.ear
|
|
|--- myejb.jar
| |
| |--- <interfaces and bean implementation>

WAR

mywebapp.war
|
|
|--- lib
| |
| |--- myejb.jar (copy of the same that is present in myapp.ear)
| | |
| | |--- <bean interfaces>

When i try to lookup the bean from the WAR i run into ClassCastException when casting the returned object to my remote interface of the bean (irrespective of whether its SLSB or SFSB):

InitialContext ctx = new InitialContext();
UserManagerRemote usr = (UserManagerRemote) ctx.lookup("RemoteUserManagerBean");

19:59:27,704 INFO [STDOUT] Caught exception
19:59:27,704 ERROR [STDERR] java.lang.ClassCastException: $Proxy119
19:59:27,704 ERROR [STDERR] at org.apache.jsp.test_jsp._jspService(test_jsp.java:75)
19:59:27,704 ERROR [STDERR] at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70)
19:59:27,704 ERROR [STDERR] at javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
19:59:27,704 ERROR [STDERR] at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:373)
19:59:27,704 ERROR [STDERR] at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:336)
19:59:27,704 ERROR [STDERR] at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:265)
19:59:27,704 ERROR [STDERR] at javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
19:59:27,704 ERROR [STDERR] at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
19:59:27,704 ERROR [STDERR] at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
19:59:27,704 ERROR [STDERR] at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
19:59:27,704 ERROR [STDERR] at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
19:59:27,704 ERROR [STDERR] at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
19:59:27,704 ERROR [STDERR] at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:230)
19:59:27,704 ERROR [STDERR] at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
19:59:27,704 ERROR [STDERR] at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:182)
19:59:27,704 ERROR [STDERR] at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:84)
19:59:27,704 ERROR [STDERR] at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
19:59:27,704 ERROR [STDERR] at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
19:59:27,704 ERROR [STDERR] at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:157)
19:59:27,704 ERROR [STDERR] at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
19:59:27,704 ERROR [STDERR] at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:262)
19:59:27,704 ERROR [STDERR] at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844)
19:59:27,704 ERROR [STDERR] at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583)
19:59:27,704 ERROR [STDERR] at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:446)
19:59:27,704 ERROR [STDERR] at java.lang.Thread.run(Thread.java:595)

Here's what happening -

* The bean gets deployed as part of the EAR deployment. The bean and its interfaces are loaded by the JBoss Unified Classloader (or the scoped classloader of the EAR, if configured). Lets call this Classloader-A
* The WAR is then deployed in its own isolated classloader. Using the isolated classloader for each WAR file is configured by default. Let's call this ClassLoader-B
* When the lookup is done from the WAR file and the object cast to the bean interface, the bean interface in now loaded by Classloader-B. As a result, the ClassCastException.


Here's what you have to do:

1) Remove the jboss-app.xml and jboss-web.xml which we had added while debugging this issue. The intention now is to not isolate the classloaders and instead use a single classloader for both the applications.
2) In the %JBOSS_HOME%/server/< serverName>/deploy/jboss-web.deployer/META-INF/jboss-service.xml file, change the value of UseJBossWebLoader to true (by default its false):

<!-- A flag indicating if the JBoss Loader should be used. This loader
 uses a unified class loader as the class loader rather than the tomcat
 specific class loader.
 The default is false to ensure that wars have isolated class loading
 for duplicate jars and jsp files.
 -->
 <attribute name="UseJBossWebLoader">true</attribute>

As mentioned in this comments, if this attribute is set to false, isolated classloader will be used for the WAR. Since we want to avoid this, we will set it to true.


P.S: The changes to this file will affect all web applications on the server.

[manemannen]

Awesome, that did it. Now it works as intended! Thank you very much.

[alrubinger]

Guys:

The simpler solution would be to simply not duplicate the EJB module in both the EAR and the WAR. :)

S,
ALR

[jaikiran]

"ALRubinger" wrote:
Guys:

The simpler solution would be to simply not duplicate the EJB module in both the EAR and the WAR. :)

May not always be possible, if the two applications are meant to be self-contained but deployed separately :-) The WAR needs the bean interfaces to be self-contained.

[manemannen]

The purpose here was to have self contained war client. I want to run the enterprise application on one jboss server and access it from various other applications located elsewhere.

A little off topic but one thing that is bugging me is all the examples I have reviewed during the search for the remote IF solution is that when people lookup the remote interface they do this on basis on the actual bean name. I also did it in my test since it was easiest and didn't really matter since it was an example to pinpoint the problem (I also included the bean in the jar file which I included in the war). This would not happen in a real case.

Example:

SimpleStatefulBeanRemote o = (SimpleStatefulBeanRemote) ctx.lookup("simpleserver/" + SimpleStatefulBean.class.getSimpleName() + "/remote");

I have seen many examples of this and it introduces a dependency from the client to the actual implementation and obsoletes the purpose of interfaces - weird

opinions?

[jaikiran]

"manemannen" wrote:

SimpleStatefulBeanRemote o = (SimpleStatefulBeanRemote) ctx.lookup("simpleserver/" + SimpleStatefulBean.class.getSimpleName() + "/remote");

I have seen many examples of this and it introduces a dependency from the client to the actual implementation and obsoletes the purpose of interfaces - weird

opinions?

That's the "default" JNDI naming scheme. You can change the jndi name to any name of your choice. See this for an example http://www.jboss.com/index.html?module=bb&op=viewtopic&t=142976

[alrubinger]

"manemannen" wrote:

SimpleStatefulBeanRemote o = (SimpleStatefulBeanRemote) ctx.lookup("simpleserver/" + SimpleStatefulBean.class.getSimpleName() + "/remote");

I have seen many examples of this and it introduces a dependency from the client to the actual implementation and obsoletes the purpose of interfaces - weird

It's actually just that the default JNDI name uses the ejb-name, which in turn is "BeanImplementationClass.class.getSimpleName()". If you manually say @Stateless.name == "whatever", then the JNDI name is "appName/whatever/remote". So there's not *really* an impl dependency. ;)

S,
ALR

[jpaga]

jaikiran

First thanks for the posting. Yes that's a long time ago, but it helped us understand our current problem.

However one question is still there... Why does such a classcast succeeds from an J2SE application client.

So the Jboss has it's classloader and the SE app has it's classloader. Both loading the same bytecode. Sure if there would be a classcast exception on the client, the remote thing wouldn't make sense, but I'd like to understand the magic behind that.