Issue with ICAT and glassfish 4.1

[brian.ritchie1312]

There may be a problem with glassfish 4.1 (which was released in September and is now the current version) that prevents ICAT from working.

When installing ICAT on a CentOS VM, I downloaded the current version of Glassfish, which turned out to be 4.1.  However, testicat failed with:

  ICAT version
  Traceback (most recent call last):
    File "/home/br54/bin/testicat", line 35, in <module>
      print "ICAT version", service.getApiVersion()
    File "/usr/lib/python2.6/site-packages/suds/client.py", line 542, in __call__
      return client.invoke(args, kwargs)
    File "/usr/lib/python2.6/site-packages/suds/client.py", line 602, in invoke
      result = self.send(soapenv)
    File "/usr/lib/python2.6/site-packages/suds/client.py", line 657, in send
      result = self.failed(binding, e)
    File "/usr/lib/python2.6/site-packages/suds/client.py", line 712, in failed
      r, p = binding.get_fault(reply)
    File "/usr/lib/python2.6/site-packages/suds/bindings/binding.py", line 265, in get_fault
      raise WebFault(p, faultroot)
  suds.WebFault: Server raised fault: 'javax.ejb.EJBException: javax.ejb.CreateException: Could not create stateless EJB'

The glassfish server.log goes on to say:

  Caused by: A MultiException has 1 exceptions.  They are:
  1. java.lang.IllegalStateException: Could not find an implementation of ClassAnalyzer with name CdiInjecteeSkippingClassAnalyzer

I see reports that suggest that there may be a bug with CDI in glassfish 4.1, e.g. <https://java.net/jira/browse/GLASSFISH-21114>.

I replaced glassfish 4.1 with 4.0 (and re-ran the installation scripts); this time testicat worked OK.

I haven't tried 4.1 with any other ICAT components.

On this basis, I recommend not using glassfish 4.1 for ICAT, though as this is based on a single example, your experience may vary.
If anyone has succeeded with glassfish 4.1, it would be good to know (especially if they found the same problem and resolved it).

Regards,
  Brian

[Christian F]

I just would like to confirm that I have the same problems on a fresh install of icat-server-4.4.0 on a glass fish server 4.1 (java_ee_sdk-7u1).

[2015-02-09T10:11:39.535+0100] [glassfish 4.1] [SEVERE] [] [com.sun.xml.ws.server.sei.TieHandler] [tid: _ThreadID=47 _ThreadName=jk-connector(1)] [timeMillis: 1423473099535] [levelValue: 1000] [[

  javax.ejb.EJBException: javax.ejb.CreateException: Could not create stateless EJB

javax.ejb.EJBException: javax.ejb.EJBException: javax.ejb.CreateException: Could not create stateless EJB

at com.sun.ejb.containers.StatelessSessionContainer._getContext(StatelessSessionContainer.java:435)

at com.sun.ejb.containers.BaseContainer.getContext(BaseContainer.java:2579)

at com.sun.ejb.containers.WebServiceInvocationHandler.invoke(WebServiceInvocationHandler.java:179)

at com.sun.proxy.$Proxy265.getApiVersion(Unknown Source)

at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)

at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)

at java.lang.reflect.Method.invoke(Method.java:606)

at org.glassfish.webservices.InvokerImpl.invoke(InvokerImpl.java:82)

at org.glassfish.webservices.EjbInvokerImpl.invoke(EjbInvokerImpl.java:82)

at com.sun.xml.ws.server.InvokerTube$2.invoke(InvokerTube.java:149)

at com.sun.xml.ws.server.sei.SEIInvokerTube.processRequest(SEIInvokerTube.java:88)

at com.sun.xml.ws.api.pipe.Fiber.__doRun(Fiber.java:1136)

at com.sun.xml.ws.api.pipe.Fiber._doRun(Fiber.java:1050)

at com.sun.xml.ws.api.pipe.Fiber.doRun(Fiber.java:1019)

at com.sun.xml.ws.api.pipe.Fiber.runSync(Fiber.java:877)

at com.sun.xml.ws.api.pipe.helper.AbstractTubeImpl.process(AbstractTubeImpl.java:136)

at org.glassfish.webservices.MonitoringPipe.process(MonitoringPipe.java:142)

at com.sun.xml.ws.api.pipe.helper.PipeAdapter.processRequest(PipeAdapter.java:119)

at com.sun.xml.ws.api.pipe.Fiber.__doRun(Fiber.java:1136)

at com.sun.xml.ws.api.pipe.Fiber._doRun(Fiber.java:1050)

at com.sun.xml.ws.api.pipe.Fiber.doRun(Fiber.java:1019)

at com.sun.xml.ws.api.pipe.Fiber.runSync(Fiber.java:877)

at com.sun.xml.ws.api.pipe.helper.AbstractTubeImpl.process(AbstractTubeImpl.java:136)

at com.sun.enterprise.security.webservices.CommonServerSecurityPipe.processRequest(CommonServerSecurityPipe.java:209)

at com.sun.enterprise.security.webservices.CommonServerSecurityPipe.process(CommonServerSecurityPipe.java:141)

at com.sun.xml.ws.api.pipe.helper.PipeAdapter.processRequest(PipeAdapter.java:119)

at com.sun.xml.ws.api.pipe.Fiber.__doRun(Fiber.java:1136)

at com.sun.xml.ws.api.pipe.Fiber._doRun(Fiber.java:1050)

at com.sun.xml.ws.api.pipe.Fiber.doRun(Fiber.java:1019)

at com.sun.xml.ws.api.pipe.Fiber.runSync(Fiber.java:877)

at com.sun.xml.ws.server.WSEndpointImpl$2.process(WSEndpointImpl.java:419)

at com.sun.xml.ws.transport.http.HttpAdapter$HttpToolkit.handle(HttpAdapter.java:868)

at com.sun.xml.ws.transport.http.HttpAdapter.handle(HttpAdapter.java:422)

at com.sun.xml.ws.transport.http.servlet.ServletAdapter.handle(ServletAdapter.java:169)

at org.glassfish.webservices.Ejb3MessageDispatcher.handlePost(Ejb3MessageDispatcher.java:110)

at org.glassfish.webservices.Ejb3MessageDispatcher.invoke(Ejb3MessageDispatcher.java:80)

at org.glassfish.webservices.EjbWebServiceServlet.dispatchToEjbEndpoint(EjbWebServiceServlet.java:210)

at org.glassfish.webservices.EjbWebServiceServlet.service(EjbWebServiceServlet.java:153)

at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)

at org.glassfish.grizzly.servlet.ServletHandler.doServletService(ServletHandler.java:223)

at org.glassfish.grizzly.servlet.ServletHandler.service(ServletHandler.java:174)

at com.sun.enterprise.v3.services.impl.ContainerMapper$HttpHandlerCallable.call(ContainerMapper.java:459)

at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:167)

at org.glassfish.grizzly.http.server.HttpHandler.runService(HttpHandler.java:201)

at org.glassfish.grizzly.http.server.HttpHandler.doHandle(HttpHandler.java:175)

at org.glassfish.grizzly.http.server.HttpServerFilter.handleRead(HttpServerFilter.java:235)

at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119)

at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:284)

at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:201)

at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:133)

at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:112)

at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77)

at org.glassfish.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(TCPNIOTransport.java:561)

at org.glassfish.grizzly.strategies.AbstractIOStrategy.fireIOEvent(AbstractIOStrategy.java:112)

at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.run0(WorkerThreadIOStrategy.java:117)

at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.access$100(WorkerThreadIOStrategy.java:56)

at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy$WorkerThreadRunnable.run(WorkerThreadIOStrategy.java:137)

at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:565)

at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:545)

at java.lang.Thread.run(Thread.java:745)

Caused by: javax.ejb.EJBException: javax.ejb.CreateException: Could not create stateless EJB

at com.sun.ejb.containers.StatelessSessionContainer$SessionContextFactory.create(StatelessSessionContainer.java:700)

at com.sun.ejb.containers.util.pool.NonBlockingPool.getObject(NonBlockingPool.java:246)

at com.sun.ejb.containers.StatelessSessionContainer._getContext(StatelessSessionContainer.java:430)

... 60 more

Caused by: javax.ejb.CreateException: Could not create stateless EJB

at com.sun.ejb.containers.StatelessSessionContainer.createStatelessEJB(StatelessSessionContainer.java:514)

at com.sun.ejb.containers.StatelessSessionContainer.access$000(StatelessSessionContainer.java:97)

at com.sun.ejb.containers.StatelessSessionContainer$SessionContextFactory.create(StatelessSessionContainer.java:698)

... 62 more

Caused by: A MultiException has 1 exceptions.  They are:

1. java.lang.IllegalStateException: Could not find an implementation of ClassAnalyzer with name CdiInjecteeSkippingClassAnalyzer

at org.jvnet.hk2.internal.Collector.throwIfErrors(Collector.java:88)

at org.jvnet.hk2.internal.Utilities.justInject(Utilities.java:928)

at org.jvnet.hk2.internal.ServiceLocatorImpl.inject(ServiceLocatorImpl.java:902)

at org.glassfish.jersey.gf.ejb.internal.EjbComponentInterceptor.inject(EjbComponentInterceptor.java:71)

at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)

at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)

at java.lang.reflect.Method.invoke(Method.java:606)

at com.sun.ejb.containers.interceptors.SystemInterceptorProxy.doCall(SystemInterceptorProxy.java:153)

at com.sun.ejb.containers.interceptors.SystemInterceptorProxy.init(SystemInterceptorProxy.java:125)

at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)

at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)

at java.lang.reflect.Method.invoke(Method.java:606)

at com.sun.ejb.containers.interceptors.CallbackInterceptor.intercept(InterceptorManager.java:986)

at com.sun.ejb.containers.interceptors.CallbackChainImpl.invokeNext(CallbackChainImpl.java:72)

at com.sun.ejb.containers.interceptors.InterceptorManager.intercept(InterceptorManager.java:412)

at com.sun.ejb.containers.interceptors.InterceptorManager.intercept(InterceptorManager.java:375)

at com.sun.ejb.containers.BaseContainer.intercept(BaseContainer.java:2014)

at com.sun.ejb.containers.StatelessSessionContainer.createStatelessEJB(StatelessSessionContainer.java:507)

... 64 more

Caused by: java.lang.IllegalStateException: Could not find an implementation of ClassAnalyzer with name CdiInjecteeSkippingClassAnalyzer

at org.jvnet.hk2.internal.ServiceLocatorImpl.getAnalyzer(ServiceLocatorImpl.java:2249)

at org.jvnet.hk2.internal.Utilities.getClassAnalyzer(Utilities.java:172)

at org.jvnet.hk2.internal.Utilities.justInject(Utilities.java:927)

... 82 more

]]

[Steve Fisher]

That is why it says in the installation instructions: http://icatproject.org/installation/glassfish/ 

"Glassfish 4.0 should be used for new installations. Version 4.1 does not work properly with ICAT; this is not yet understood."

It would be good to understand what the problem is with 4.1 if anybody would like to follow it up.

Steve 

[Steve Fisher]

I have just tried the Payara server (a commercially supported Glassfish 4.1) and see the same problem. The reports I have seen say that it is a timing bug in glassfish. I will report it to Payara in the hope that they will look into it.

Steve

[Steve Fisher]

While trying to build a simple example to show up the bug. I found that our setup script for glassfish servers includes:

asadmin set configs.config.server-config.cdi-service.enable-implicit-cdi=false

This line was inserted in the script some years ago to fix some other problem which I don't remember. Removing this line allows us to run with payara41, glassfish 4.1.1 and glassfish 4.0.

I have not closed the bug because there is still the question of why it works on glassfish 4.0 but not in 4.1 and derived works. However I would not be unhappy if you choose to close it.

I have updated the version of the script downloadable from the web

I propose to continue development (and testing) on payara41 and will probably recommend its use as the preferred container. The version of setup_utils.py packaged with each of our components does not work with Payara because of some code which interprets the version string incorrectly. This will take some time to replace everywhere. In the meanwhile you could use glassfish 4.1.1 with the latest setup_glassfish.py

Steve

[Rolf Krahl]

Steve,

Am Donnerstag, 3. November 2016, 09:03:27 schrieb Steve Fisher:
>
> While trying to build a simple example to show up the bug. I found that our
> setup script for glassfish servers includes:
>
> asadmin set
> configs.config.server-config.cdi-service.enable-implicit-cdi=false
>
> This line was inserted in the script some years ago to fix some other
> problem which I don't remember. Removing this line allows us to run with
> payara41, glassfish 4.1.1 and glassfish 4.0.
>
> I have not closed the bug because there is still the question of why it
> works on glassfish 4.0 but not in 4.1 and derived works. However I would
> not be unhappy if you choose to close it.

Just to get this explicit: for the moment, you recommend dropping the
"configs...enable-implicit-cdi=false" line from the setup and then to
use GlassFish 4.1.1. Did I got that right?

Rolf

--
Rolf Krahl <rolf....@helmholtz-berlin.de>
Helmholtz-Zentrum Berlin für Materialien und Energie (HZB)
Albert-Einstein-Str. 15, 12489 Berlin
Tel.: +49 30 8062 12122

[Steve Fisher]

I have not tried all our components with the new glassfish-setup.py script but just deployed 4 authenticators and the icat.server. This works fine on Glassfish 4.0, Glassfish 4.1.1 and payara41. If the ids and topcat also work properly - I will test in a few minutes then I would recommend glassfish 4.1.1 as it is the latest glassfish. Once I get a new release of everything with the new (currently unreleased setup_utils.py) then I would expect to recommend payara as this is the free version of a commercially supported product. So I suggest waiting till I have tested ids and topcat installations before changing.

Steve

On 4 November 2016 at 08:04, Rolf Krahl <rolf....@helmholtz-berlin.de> wrote:

Steve,

Am Donnerstag, 3. November 2016, 09:03:27 schrieb Steve Fisher:
>
> While trying to build a simple example to show up the bug. I found that our
> setup script for glassfish servers includes:
>
> asadmin set
> configs.config.server-config.cdi-service.enable-implicit-cdi=false
>
> This line was inserted in the script some years ago to fix some other
> problem which I don't remember. Removing this line allows us to run with
> payara41, glassfish 4.1.1 and glassfish 4.0.
>
> I have not closed the bug because there is still the question of why it
> works on glassfish 4.0 but not in 4.1 and derived works. However I would
> not be unhappy if you choose to close it.

Just to get this explicit: for the moment, you recommend dropping the
"configs...enable-implicit-cdi=false" line from the setup and then to
use GlassFish 4.1.1.  Did I got that right?

Rolf

--
Rolf Krahl <rolf.krahl@helmholtz-berlin.de>

Helmholtz-Zentrum Berlin für Materialien und Energie (HZB)
Albert-Einstein-Str. 15, 12489 Berlin
Tel.: +49 30 8062 12122

--
You received this message because you are subscribed to the Google Groups "icatgroup" group.
To unsubscribe from this group and stop receiving emails from it, send an email to icatgroup+unsubscribe@googlegroups.com.
To post to this group, send email to icat...@googlegroups.com.
Visit this group at https://groups.google.com/group/icatgroup.
For more options, visit https://groups.google.com/d/optout.

[Steve Fisher]

I have now tried four authenticators, icat, ids and topcat. The conclusion is:

All works fine with Glassfish 4.0

All works fine except for TopCAT with Glassfish 4.1.1

All works fine with Payara

Jody may be able to fix the TopCAT/Glassfish 4.1.1 problem when he is back next week.

So my current recommendation is:

for servers without topcat : Glassfish 4.1.1

for servers with topcat    : Glasssfish 4.0

When all components you wish to use have setup_utils.py >= 4.15.1, I expect to recommend Payara.

Steve