Invoking EJB 3 deployed on GlassFish 3.1 from Servlet on JBoss AS 7.1.1 - ejb-3.0

I have a simple session EJB (3.0 spec) deployed on GlassFish 3.1 with a remote interface. Here is the log snippet showing deployment:
INFO: Portable JNDI names for EJB RandomNumber2Bean : [java:global/RandomNumberEJB/RandomNumber2Bean, java:global/RandomNumberEJB/RandomNumber2Bean!beans.RandomNumber2]
INFO: Glassfish-specific (Non-portable) JNDI names for EJB RandomNumber2Bean : [RandomNumber2, RandomNumber2#beans.RandomNumber2]
I am trying to invoke it from a Servlet deployed on a JBoss AS 7.1.1 instance on the same machine. Here is the relevant code from the servlet:
Properties props = new Properties();
props.setProperty("java.naming.factory.initial", "com.sun.enterprise.naming.impl.SerialInitContextFactory");
props.setProperty("java.naming.factory.url.pkgs", "com.sun.enterprise.naming");
props.setProperty("java.naming.factory.state", "com.sun.corba.ee.impl.presentation.rmi.JNDIStateFactoryImpl");
InitialContext initialContext = new javax.naming.InitialContext(props);
RandomNumber2 randomNumber2 = (RandomNumber2) initialContext.lookup("RandomNumber2");
However, whenever I try to get the InitialContext from the servlet to look up the bean, I get the following error:
javax.naming.NamingException: JBAS011843: Failed instantiate InitialContextFactory com.sun.enterprise.naming.SerialInitContextFactory from classloader ModuleClassLoader for Module "deployment.RandomNumberTesterGlassfish.war:main" from Service Module Loader
at org.jboss.as.naming.InitialContextFactoryBuilder.createInitialContextFactory(InitialContextFactoryBuilder.java:64)
at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:681)
at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:307)
at javax.naming.InitialContext.init(InitialContext.java:242)
at javax.naming.InitialContext.<init>(InitialContext.java:216)
at test.RandomNumberServlet.doGet(RandomNumberServlet.java:32)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:734)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:847)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:329)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:248)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:275)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:161)
at org.jboss.as.web.security.SecurityContextAssociationValve.invoke(SecurityContextAssociationValve.java:153)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:155)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:368)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:877)
at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:671)
at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:930)
at java.lang.Thread.run(Thread.java:722)
I have added the client jars appserv-rt.jar and gf-client.jar from GlassFish into the build path of the client Servlet application (I am using Eclipse Juno to deploy it) and to the %JBOSS_HOME%\standalone\lib\ext directory.
I cannot find anything on the web that even mentions invoking EJB's deployed on GlassFish 3.1 from JBoss AS 7.1.1. I am totally at a loss at this point. I am able to invoke the EJB's deployed on GlassFish with a standalone client and I am able to invoke the same EJB's deployed on JBoss both from a standalone client and from GlassFish.

It is written in the log: "Glassfish-specific (Non-portable) JNDI names". So, it probably won't work from JBoss. Try this one instead:
RandomNumber2 randomNumber2 = (RandomNumber2) initialContext.lookup("java:global/RandomNumberEJB/RandomNumber2Bean");

I think you can not load the GlassFish native libraries in Jboss AppServer.
I test the props.setProperty("java.naming.factory.initial", "com.sun.enterprise.naming.impl.SerialInitContextFactory"); config in three AppServers: GlassFish 3, Jboss 7 and WebSphere 8.
The only application server that run the application properly was Glassfish. (because of com.sun.enterprise.naming.impl.SerialInitContextFactory )
You should run your application in GlassFish.
here is the full configuration:
Properties props = new Properties();
props.setProperty("java.naming.factory.initial",
"com.sun.enterprise.naming.SerialInitContextFactory");
props.setProperty("java.naming.factory.url.pkgs",
"com.sun.enterprise.naming");
props.setProperty("java.naming.factory.state",
"com.sun.corba.ee.impl.presentation.rmi.JNDIStateFactoryImpl");
props.setProperty("org.omg.CORBA.ORBInitialHost", "IP");
props.setProperty("org.omg.CORBA.ORBInitialPort", "3700");
InitialContext context = new InitialContext(props);
RandomNumber2 randomNumber2 =(RandomNumber2)context.lookup("RandomNumber2");

Can you try setting the below properties too
props.setProperty("org.omg.CORBA.ORBInitialHost", "localhost");
props.setProperty("org.omg.CORBA.ORBInitialPort", "3700");

Related

Problem when deploying project with web socket on Jetty 9.2.13.v20150730

I've experienced a problem while migrating an app from PrimeFaces 5.2 to 10.
This problem is related to migration of web socket implementation from Primefaces to Omnifaces.
The versions I'm using:
PF: 10.0.0
PF extensions: 10.0.6
Omnifaces 2.7.7
CDI 1.1
JSF 2.2
I don't have anything fancy, just a simple PushBean which sends a message.
I've tried downgrading to PF8, but, as expected, the result is the same.
The configuration is made as requested in the documentation, in my web.xml file having this flag enabled:
<context-param>
<param-name>org.omnifaces.SOCKET_ENDPOINT_ENABLED</param-name>
<param-value>true</param-value>
</context-param>
However, when I try to deploy my app to jetty, I'm receiving the following error:
java.lang.IllegalStateException: OmniFaces failed to initialize! Report an issue to OmniFaces.
at org.omnifaces.ApplicationListener.contextInitialized(ApplicationListener.java:88)
at org.eclipse.jetty.server.handler.ContextHandler.callContextInitialized(ContextHandler.java:800)
at org.eclipse.jetty.servlet.ServletContextHandler.callContextInitialized(ServletContextHandler.java:444)
.
.
.
Caused by: java.lang.RuntimeException: Cannot load platform configurator
at javax.websocket.server.ServerEndpointConfig$Configurator.fetchContainerDefaultConfigurator(ServerEndpointConfig.java:123)
at javax.websocket.server.DefaultServerEndpointConfig.<init>(DefaultServerEndpointConfig.java:85)
at javax.websocket.server.ServerEndpointConfig$Builder.build(ServerEndpointConfig.java:301)
at org.omnifaces.cdi.push.Socket.registerEndpointIfNecessary(Socket.java:1114)
at org.omnifaces.ApplicationListener.contextInitialized(ApplicationListener.java:85)
at org.eclipse.jetty.server.handler.ContextHandler.callContextInitialized(ContextHandler.java:800)
at org.eclipse.jetty.servlet.ServletContextHandler.callContextInitialized(ServletContextHandler.java:444)
at org.eclipse.jetty.server.handler.ContextHandler.startContext(ContextHandler.java:791)
at org.eclipse.jetty.servlet.ServletContextHandler.startContext(ServletContextHandler.java:294)
I'm guessing that there is something that I'm not doing right, but, I don't know exactly what is it.
Can you please, give a little hand?
Thanks in advance!
The stacktrace / exception ...
Caused by: java.lang.RuntimeException: Cannot load platform configurator
at javax.websocket.server.ServerEndpointConfig$Configurator.fetchContainerDefaultConfigurator(ServerEndpointConfig.java:123)
at javax.websocket.server.DefaultServerEndpointConfig.<init>(DefaultServerEndpointConfig.java:85)
at javax.websocket.server.ServerEndpointConfig$Builder.build(ServerEndpointConfig.java:301)
This is coming from the javax.websocket API jar, when it attempts to find the Server Container Default Configuration (in other words, the implementation specific defaults, which would be Jetty)
If you are running Jetty, you need to be including the jetty support jar for javax.websocket.server in your classpath.
Which on Jetty 9.2.x would be the javax-websocket-server-impl-<ver>.jar file (and associated dependencies).
Per #BalusC, omnifaces is just a web-fragment deployed in your WAR's WEB-INF/lib.
That means you have to enable support for websocket on the Jetty server side.
For standalone (using ${jetty.base} and ${jetty.home} split) this means enabling the correct module for your version of Jetty.
Jetty ver
WebSocket spec
Module
Jetty 8.x and older
n/a
n/a
Jetty 9.0.x
n/a
n/a
Jetty 9.1.x
javax.websocket (beta)
websocket
Jetty 9.2.x - 9.4.x
javax.websocket 1.0
websocket
Jetty 10.0.x
javax.websocket 1.1
websocket-javax
Jetty 11.0.x
jakarta.websocket 2.0
websocket-jakarta
To do that you'll use the command line.
Jetty 9.x
[~]$ cd /path/to/my-jetty-base
[my-jetty-base]$ java -jar /path/to/jetty-home/start.jar
--add-to-start=websocket
Jetty 10+
[~]$ cd /path/to/my-jetty-base
[my-jetty-base]$ java -jar /path/to/jetty-home/start.jar
--add-module=websocket-javax

Websphere 8.5.5 - spring boot error: SpringServletContainerInitializer not a subtype

I have a spring boot application that works fine on Tomcat 8. When I try to deploy it on Websphere 8.5.5 with "Class loader order" set to "Classes loaded with local class loader first (parent last)" the application fails to start with the following exception:
... 73 more
Caused by: java.util.ServiceConfigurationError: javax.servlet.ServletContainerInitializer: Provider org.springframework.web.SpringServletContainerInitializer not a subtype
at java.util.ServiceLoader.fail(ServiceLoader.java:242)
at java.util.ServiceLoader.access$300(ServiceLoader.java:192)
at java.util.ServiceLoader$LazyIterator.next(ServiceLoader.java:380)
at java.util.ServiceLoader$1.next(ServiceLoader.java:456)
at com.ibm.ws.webcontainer.webapp.WebAppImpl.initializeServletContainerInitializers(WebAppImpl.java:537)
at com.ibm.ws.webcontainer.webapp.WebAppImpl.initialize(WebAppImpl.java:410)
at com.ibm.ws.webcontainer.webapp.WebGroupImpl.addWebApplication(WebGroupImpl.java:88)
at com.ibm.ws.webcontainer.VirtualHostImpl.addWebApplication(VirtualHostImpl.java:171)
... 74 more
Just adding my experience with this problem, looking around on the various answers to similar problems I found out that the problem could be caused by some javax-servlet related jar in the classpath. After some trial and error I noticed that the spring-boot-starter-web dependency has an inherited spring-boot-starter-tomcat dependency. Excludung this jar from the application classpath when deploying on Websphere 8.5.5 solved the problem.

Jersey 2.10 in IBM WebSphere

I am setting up project with Jersey 2.10, JavaSE 1.7 in Websphere 8.5.5.2 (websphere 7.1 SDK)
When i deploy the project, i get this error
com.ibm.ws.webcontainer.webapp.WebApp commonInitializationFinally SRVE0266E: Error occured while initializing servlets: {0}
javax.servlet.ServletException: SRVE0207E: Uncaught initialization exception created by servlet
at com.ibm.ws.webcontainer.servlet.ServletWrapper.init(ServletWrapper.java:404)
at com.ibm.ws.webcontainer.servlet.ServletWrapperImpl.init(ServletWrapperImpl.java:168)
I tried to delete the jersey libraries after deploying the project and map it to shared library (same jersey libraries) on websphere. The shared library is mapped to project now, but get other error when i run the application like below.
com.ibm.ws.webcontainer.webapp.WebApp logServletError SRVE0293E: [Servlet Error]-[RESTSrv01]: com.ibm.ws.webcontainer.webapp.WebAppErrorReport: Internal Server Error
at com.ibm.ws.webcontainer.webapp.WebAppDispatcherContext.sendError(WebAppDispatcherContext.java:626)
at com.ibm.ws.webcontainer.webapp.WebAppDispatcherContext.sendError(WebAppDispatcherContext.java:656)
at com.ibm.ws.webcontainer.srt.SRTServletResponse.sendError(SRTServletResponse.java:1301)
at org.glassfish.jersey.servlet.internal.ResponseWriter.commit(ResponseWriter.java:199)
at org.glassfish.jersey.server.ContainerResponse.close(ContainerResponse.java:412)
Any suggestion what could be the problem?

Tomcat pool DataSource not found on tomcat 7.0.26

When I try to deploy a webapp in tomcat 7.0.26 I get the following exception:
ClassNotFoundException: org.apache.tomcat.jdbc.pool.DataSource
But as far as I have read, this class was introduced on tomcat 7.0.19.
Any ideas?

Spring 3.1 not able to load Configuration Class:

I am working on project that has Rest Service with Spring 3.1.0. Release.
I am using Config class to load beans.
As suggested, using cglib 2.2 and asm-3.3 jars.
This fails in websphere 8.5 with following exception. But works in Apache Tomcat 7.0.
[12/19/12 12:47:26:439 EST] 00000062 webapp E com.ibm.ws.webcontainer.webapp.WebApp logServletError SRVE0293E: [Servlet Error]-[dispatcher]: java.lang.IllegalStateException: Cannot load configuration class: com.hps.config.ApplicationConfig
at org.springframework.context.annotation.ConfigurationClassPostProcessor.enhanceConfigurationClasses(ConfigurationClassPostProcessor.java:313)
at org.springframework.context.annotation.ConfigurationClassPostProcessor.postProcessBeanFactory(ConfigurationClassPostProcessor.java:197)
at org.springframework.context.support.AbstractApplicationContext.invokeBeanFactoryPostProcessors(AbstractApplicationContext.java:681)
at org.springframework.context.support.AbstractApplicationContext.invokeBeanFactoryPostProcessors(AbstractApplicationContext.java:620)
at org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:446)
at org.springframework.web.context.ContextLoader.configureAndRefreshWebApplicationContext(ContextLoader.java:384)
at org.springframework.web.context.ContextLoader.initWebApplicationContext(ContextLoader.java:283)
at org.springframework.web.context.ContextLoaderListener.contextInitialized(ContextLoaderListener.java:111)
at com.ibm.ws.webcontainer.webapp.WebApp.notifyServletContextCreated(WebApp.java:1651)
at com.ibm.ws.webcontainer.webapp.WebAppImpl.initialize(WebAppImpl.java:414)
at com.ibm.ws.webcontainer.webapp.WebGroupImpl.addWebApplication(WebGroupImpl.java:88)
at com.ibm.ws.webcontainer.VirtualHostImpl.addWebApplication(VirtualHostImpl.java:169)
at com.ibm.ws.webcontainer.WSWebContainer.addWebApp(WSWebContainer.java:746)
at com.ibm.ws.webcontainer.WSWebContainer.addWebApplication(WSWebContainer.java:634)
at com.ibm.ws.webcontainer.component.WebContainerImpl.install(WebContainerImpl.java:426)
at com.ibm.ws.webcontainer.component.WebContainerImpl.start(WebContainerImpl.java:718)
at com.ibm.ws.runtime.component.ApplicationMgrImpl.start(ApplicationMgrImpl.java:1170)
at com.ibm.ws.runtime.component.DeployedApplicationImpl.fireDeployedObjectStart(DeployedApplicationImpl.java:1370)
at com.ibm.ws.runtime.component.DeployedModuleImpl.start(DeployedModuleImpl.java:638)
at com.ibm.ws.runtime.component.DeployedApplicationImpl.start(DeployedApplicationImpl.java:968)
at com.ibm.ws.runtime.component.ApplicationMgrImpl.startApplication(ApplicationMgrImpl.java:769)
at com.ibm.ws.runtime.component.ApplicationMgrImpl.startApplicationDynamically(ApplicationMgrImpl.java:1364)
at com.ibm.ws.runtime.component.ApplicationMgrImpl.start(ApplicationMgrImpl.java:2169)
Caused by: java.lang.VerifyError: JVMVRFY007 final method overridden; class=net/sf/cglib/core/DebuggingClassWriter, method=visit(IILjava/lang/String;Ljava/lang/String;Ljava/lang/String;[Ljava/lang/String;)V
at java.lang.ClassLoader.defineClassImpl(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:262)
at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:69)
at com.ibm.ws.classloader.CompoundClassLoader._defineClass(CompoundClassLoader.java:852)
at com.ibm.ws.classloader.CompoundClassLoader.localFindClass(CompoundClassLoader.java:762)
at com.ibm.ws.classloader.CompoundClassLoader.loadClass(CompoundClassLoader.java:585)
at java.lang.ClassLoader.loadClass(ClassLoader.java:627)
at java.lang.J9VMInternals.verifyImpl(Native Method)
at java.lang.J9VMInternals.verify(J9VMInternals.java:85)
at java.lang.J9VMInternals.initialize(J9VMInternals.java:162)
at net.sf.cglib.core.AbstractClassGenerator.<init>(AbstractClassGenerator.java:38)
at net.sf.cglib.core.KeyFactory$Generator.<init>(KeyFactory.java:127)
at net.sf.cglib.core.KeyFactory.create(KeyFactory.java:112)
at net.sf.cglib.core.KeyFactory.create(KeyFactory.java:108)
at net.sf.cglib.core.KeyFactory.create(KeyFactory.java:104)
at net.sf.cglib.proxy.Enhancer.<clinit>(Enhancer.java:69)
at java.lang.J9VMInternals.initializeImpl(Native Method)
at java.lang.J9VMInternals.initialize(J9VMInternals.java:228)
at org.springframework.context.annotation.ConfigurationClassEnhancer.newEnhancer(ConfigurationClassEnhancer.java:136)
at org.springframework.context.annotation.ConfigurationClassEnhancer.enhance(ConfigurationClassEnhancer.java:109)
at org.springframework.context.annotation.ConfigurationClassPostProcessor.enhanceConfigurationClasses(ConfigurationClassPostProcessor.java:303)
... 109 more
Any suggestion on how to fix this issue.
Tried with different versions of cglib and asm jars, but no luck..
Make sure all the dependent JAR files are stored in WEB-INF/lib directory of your WAR file including Sam-3.3. If your using Maven then make sure you don't exclude this JAR or inadvertently set its scope as provided.
Now you you deploy the application in WebSphere make sure you set the application class loading before to application first (parent last). To do this in WebSphere you need to find the link Manage Modules and locate class loading link, don't really remember what it was in WebSphere however should be easy to find. This should resolve your issues.
Update: just noticed the link you provided already suggests using parent last. In WebSphere I find this is a must otherwise you will hit many of these issues and furthermore upgrades become much easier!
I am able to resolve this issue..
Issue is with Websphere 8.5
It has own version of asm4.0 jars. And spring3.1 uses cglib2.2 jar that is only compatible with asm3.3. asm4.0 jar of websphere is the culprit..
workaround is to use cglib-nodep jar instead of cglib2.2 jar
http://www.ibm.com/developerworks/forums/thread.jspa?messageID=14880673
It seems that this was a bug (PM71336) in Websphere 8.5
The bug has been fixed in the Websphere V8.5 Fix Pack 2
http://www-01.ibm.com/support/docview.wss?uid=swg24034672
Use cglib-nodep jar instead of cglib2.2 jar. Also, don't forget to remove asm3.3 jar from your lib. Initially I wasn't removing asm3.3 jar which was still causing the problem.

Resources