Remote EJB Lookup returns a RelativeContext tha...| JBoss.org Content Archive (Read Only)

15. Re: Remote EJB Lookup returns a RelativeContext that can't be cast to the EJB

dmlloyd May 16, 2018 3:15 PM (in response to ftg314159)

This is what caught my eye:

Absent Code attribute in method that is not native or abstract in class file javax/ejb/EJBException      java.lang.ClassFormatError: Absent Code attribute in method that is not native or abstract in class file javax/ejb/EJBException          at java.lang.ClassLoader.defineClass1(Native Method)

This indicates that the class file that it has loaded "javax/ejb/EJBException.class" from actually is not a complete class file (the code attributes were dropped). This kind of "stubbing" may be common for IDE-provided specification JARs and that sort of thing, but these JARs are (obviously) not suited for production (since they have no actual code in them, just the API "shapes"). They're meant only to compile against, and to allow for things like code highlighting, tab completion, and so forth.

16. Re: Remote EJB Lookup returns a RelativeContext that can't be cast to the EJB

ftg314159 May 16, 2018 3:15 PM (in response to dmlloyd)

David, what's confusing me is the sudden requirement to include a JAR name and a "!" suffix in the lookup string for an old-style remote JNDI lookup. That was never needed before (JBoss 6.0.0). It would make sense to have to provide information like this if the client wasn't interacting with the server for the lookup, since I guess the fake proxy would need info that a legacy lookup would have obtained from the server.

17. Re: Remote EJB Lookup returns a RelativeContext that can't be cast to the EJB

dmlloyd May 16, 2018 4:28 PM (in response to ftg314159)

ftg314159 wrote:

David, what's confusing me is the sudden requirement to include a JAR name and a "!" suffix in the lookup string for an old-style remote JNDI lookup. That was never needed before (JBoss 6.0.0). It would make sense to have to provide information like this if the client wasn't interacting with the server for the lookup, since I guess the fake proxy would need info that a legacy lookup would have obtained from the server.

Ah, I suppose if your idea of "new" is "after JBoss 6.0", it might be a bit of a shock.

You can also bind your EJBs to any additional name that you wish using the Resource annotation or the appropriate deployment descriptors in the standard Java EE manner. Any name bound under the "java:jboss/exported/" context will be visible from remote clients. So if you don't care for the long names, you need not use them.

18. Re: Remote EJB Lookup returns a RelativeContext that can't be cast to the EJB

ftg314159 May 16, 2018 5:20 PM (in response to dmlloyd)

Hi David,

I did some additional testing, backing off from using "ejb:" to variations of the original lookup string I had been using, which got me the NamingExceptions I had seen previously. I incrementally added the JAR name to the lookup string, and then the "!" plus full class name, and at that point got the same "Absent code attribute" error.

So, it looks like this does come down to a classpath issue. I have several layers of Maven EJB projects designed to provide only dependencies needed to compile code for any AS at the upper levels, and eventually at the lowest parent level provide the AS-specific stuff. The upper levels include javaee-api dependencies, but what I think you're telling me is that javaee-api should only be included at the AS-level if needed at all, and if an AS like WildFly includes such stuff on its own, then the app project should pick it up from there at that level. I'll go through the hierarchy and purge any unneeded references in the generic projects; my original intent was to migrate anything needed by generic AS apps to the highest level possible, but I may have been too aggressive.

19. Re: Remote EJB Lookup returns a RelativeContext that can't be cast to the EJB

mayerw01 May 17, 2018 6:11 AM (in response to ftg314159)

I've made some more tests using the example from GitHub - wildfly/quickstart: Holds all versioned WildFly quickstarts

It now looks to me that there are 2 versions:

old version:

Context.INITIAL_CONTEXT_FACTORY: org.jboss.naming.remote.client.InitialContextFactory

Context.PROVIDER_URL: http-remoting://localhost:8080

lookup: /wildfly-ejb-remote-server-side-10.0.0-SNAPSHOT/CalculatorBean!org.jboss.as.quickstarts.ejb.remote.stateless.RemoteCalculator

(this apparently does not work using java above 8)

new version:

Context.INITIAL_CONTEXT_FACTORY: org.wildfly.naming.client.WildFlyInitialContextFactory

Context.PROVIDER_URL: remote+http://localhost:8080

lookup: ejb:/ejb-remote-server-side-13.0.0-SNAPSHOT/CalculatorBean!org.jboss.as.quickstarts.ejb.remote.stateless.RemoteCalculator

20. Re: Remote EJB Lookup returns a RelativeContext that can't be cast to the EJB

dmlloyd May 17, 2018 9:16 AM (in response to mayerw01)

mayerw01 wrote:

I've made some more tests using the example from GitHub - wildfly/quickstart: Holds all versioned WildFly quickstarts
It now looks to me that there are 2 versions:

old version:
Context.INITIAL_CONTEXT_FACTORY: org.jboss.naming.remote.client.InitialContextFactory
Context.PROVIDER_URL: http-remoting://localhost:8080
lookup: /wildfly-ejb-remote-server-side-10.0.0-SNAPSHOT/CalculatorBean!org.jboss.as.quickstarts.ejb.remote.stateless.RemoteCalculator

(this apparently does not work using java above 8)

new version:
Context.INITIAL_CONTEXT_FACTORY: org.wildfly.naming.client.WildFlyInitialContextFactory
Context.PROVIDER_URL: remote+http://localhost:8080
lookup: ejb:/ejb-remote-server-side-13.0.0-SNAPSHOT/CalculatorBean!org.jboss.as.quickstarts.ejb.remote.stateless.RemoteCalculator

Again this is a bit of a misunderstanding. Under WildFly 10 and earlier, only the "org.jboss.naming.remote.client.InitialContextFactory" class worked, however both "ejb:" style lookups and "exported"/unqualified remote JNDI lookups have worked since JBoss AS 7.1 IIRC. Under WildFly 11 and later, both "org.jboss.naming.remote.client.InitialContextFactory" and "org.wildfly.naming.client.WildFlyInitialContextFactory" are supported (the former being deprecated). The version of Java supported is dependent solely on the version of WildFly whose client libraries are in use.

The "remoting", "http-remoting", and "https-remoting" URI schemas continue to be allowed even on the latest WildFly releases, however in general it is recommended to use "remote", "remote+http", "remote+https", and "remote+tls" instead.

21. Re: Remote EJB Lookup returns a RelativeContext that can't be cast to the EJB

ftg314159 May 17, 2018 3:01 PM (in response to dmlloyd)

The classpath was it. One of the ancestor projects had a dependency for javaee-api and Maven assembly jar-with-dependencies was pulling those in instead of the WildFly ones. I switched the WildFly template project to wildfly-client-all and deleted the javaee-api dependency, and all now works.

Thanks to everyone for helping out here !