Vaadin Flow Exception on Application call - VaadinSession cannot be cast to VaadinSession - jetty

We're currently developing a new Vaadin Web Application based on a Vaadin Flow Starter pack. It runs with a jetty server, that is started through a maven call. Lately an error has been popping off quite often that prevents me from accessing the application in the browser, resulting in just an exception stacktrace (in the browser as well as in the backend) that says com.vaadin.flow.server.VaadinSession cannot be cast to com.vaadin.flow.server.VaadinSession. Here's the full stacktrace.
javax.servlet.ServletException: javax.servlet.ServletException: com.vaadin.flow.server.ServiceException: java.lang.ClassCastException: com.vaadin.flow.server.VaadinSession cannot be cast to com.vaadin.flow.server.VaadinSession
at org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:146)
at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)
at org.eclipse.jetty.server.Server.handle(Server.java:531)
at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:352)
at org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:260)
at org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:281)
at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:102)
at org.eclipse.jetty.io.ChannelEndPoint$2.run(ChannelEndPoint.java:118)
at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.runTask(EatWhatYouKill.java:333)
at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:310)
at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.tryProduce(EatWhatYouKill.java:168)
at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.run(EatWhatYouKill.java:126)
at org.eclipse.jetty.util.thread.ReservedThreadExecutor$ReservedThread.run(ReservedThreadExecutor.java:366)
at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:762)
at org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(QueuedThreadPool.java:680)
at java.lang.Thread.run(Thread.java:748)
Caused by: javax.servlet.ServletException: com.vaadin.flow.server.ServiceException: java.lang.ClassCastException: com.vaadin.flow.server.VaadinSession cannot be cast to com.vaadin.flow.server.VaadinSession
at com.vaadin.flow.server.VaadinServlet.service(VaadinServlet.java:302)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:857)
at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:535)
at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:146)
at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548)
at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)
at org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:257)
at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1595)
at org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:255)
at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1317)
at org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:203)
at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:473)
at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1564)
at org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:201)
at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1219)
at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:144)
at org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:219)
at org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:126)
... 15 more
Caused by: com.vaadin.flow.server.ServiceException: java.lang.ClassCastException: com.vaadin.flow.server.VaadinSession cannot be cast to com.vaadin.flow.server.VaadinSession
at com.vaadin.flow.server.VaadinService.handleExceptionDuringRequest(VaadinService.java:1535)
at com.vaadin.flow.server.VaadinService.handleRequest(VaadinService.java:1498)
at com.vaadin.flow.server.VaadinServlet.service(VaadinServlet.java:300)
... 33 more
Caused by: java.lang.ClassCastException: com.vaadin.flow.server.VaadinSession cannot be cast to com.vaadin.flow.server.VaadinSession
at com.vaadin.flow.server.VaadinService.readFromHttpSession(VaadinService.java:2071)
at com.vaadin.flow.server.VaadinService.loadSession(VaadinService.java:2051)
at com.vaadin.flow.server.VaadinService.getExistingSession(VaadinService.java:942)
at com.vaadin.flow.server.VaadinService.doFindOrCreateVaadinSession(VaadinService.java:791)
at com.vaadin.flow.server.VaadinService.findOrCreateVaadinSession(VaadinService.java:766)
at com.vaadin.flow.server.VaadinService.findVaadinSession(VaadinService.java:624)
at com.vaadin.flow.server.VaadinService.handleRequest(VaadinService.java:1480)
... 34 more
Now the stacktrace itself is one of a kind and I have not seen something like it before, because it says it can't cast the VaadinSession to a VaadinSession, which is unfortunate. I'm pretty sure this stuff is handled from Vaadin itself and I'm just using it as a blackbox, so right now I don't really know where this errors comes from and how I can fix it.
I am extending a VaadinServlet to hook into servlet and session initialization, the code is pretty straight forward though (although I have to say that I'm not a master in session initaliziation, so I just ripped it off some other tutorial). I'm not sure if this may have something to do with it, here's the code anyways.
#Override
protected void servletInitialized() throws ServletException {
super.servletInitialized();
getService().addSessionInitListener(this);
getService().addSessionDestroyListener(this);
logger.info("servlet initialized");
}
#Override
public void sessionInit(SessionInitEvent event) throws ServiceException {
// Do session start stuff here
logger.info("session initialized");
SessionBean sessionBean = new SessionBean();
sessionBean.setPlant(Config.getInstance().getPlant());
// TODO Berechtigungen aus dem Nutzer auslesen
sessionBean.setAuthorizations(AUTHS);
event.getSession().setAttribute(SessionBean.class, sessionBean);
event.getSession().setAttribute(BPService.class, new BPService());
}
#Override
public void sessionDestroy(SessionDestroyEvent event) {
event.getSession().setAttribute(SessionBean.class, null);
event.getSession().setAttribute(BPService.class, null);
}
The error occurs on hot deploys as well as fresh starts. A restart of the application server does not necessarily resolve the problem. As soon as the error occurs in a page call (does not matter which browser, I had these errors in Chrome, Opera, Firefox and IE) it is repeated over and over again if I refresh this particular page or try to call it from a new window of the same browser. If I switch to an incognito window or switch the browser, it will not occur in the new window, but still keeps popping off in the old one.
Current configuration
Vaadin 12.0.0 (happened with 11.0.2 too)
mvn jetty:run with a jetty 9.4.11.v20180605
java 1.8
I think I'm currently using the full Vaadin Flow stuff, I'm not sure how it handels the dependencies, but this is my only dependecy for Vaadin right now:
<dependency>
<groupId>com.vaadin</groupId>
<artifactId>vaadin-bom</artifactId>
<version>${vaadin.version}</version>
<type>pom</type>
<scope>import</scope>
</dependency>
I tried switching the jetty server to a different version with no success. Updating Vaadin to 12 from 11 also had no impact on the error.

Related

Error in Web Services java (jsp) StandardWrapperValve[]:... threw exception java.nio.channels.ClosedByInterruptException

I'm developing the web service and in it weka use, weka query the data stored in the database (sql server 2008), to generate clustering models, from the weka gui takes in creating the models 19 minutes and there does not occur any Problem , But when I try in the test netbeans call the service that performs this , happens the following error.
Advertencia: StandardWrapperValve[NameWS]: Servlet.service() for servlet NameWS threw exception
java.nio.channels.ClosedByInterruptException
at java.nio.channels.spi.AbstractInterruptibleChannel.end(AbstractInterruptibleChannel.java:202)
Can anybody help me please
Grave: Trying to add database driver (JDBC): com.microsoft.jdbc.sqlserver.jdbc.SQLServerDriver - Error, not in CLASSPATH?
Advertencia: StandardWrapperValve[ModuloIntegenciaNegociosWS]: Servlet.service() for servlet ModuloIntegenciaNegociosWS threw exception
java.nio.channels.ClosedByInterruptException
at java.nio.channels.spi.AbstractInterruptibleChannel.end(AbstractInterruptibleChannel.java:202)
at sun.nio.ch.SocketChannelImpl.write(SocketChannelImpl.java:477)
at org.glassfish.grizzly.nio.transport.TCPNIOUtils.flushByteBuffer(TCPNIOUtils.java:149)
at org.glassfish.grizzly.nio.transport.TCPNIOUtils.writeCompositeBuffer(TCPNIOUtils.java:87)
at org.glassfish.grizzly.nio.transport.TCPNIOAsyncQueueWriter.write0(TCPNIOAsyncQueueWriter.java:129)
at org.glassfish.grizzly.nio.transport.TCPNIOAsyncQueueWriter.write0(TCPNIOAsyncQueueWriter.java:106)
at org.glassfish.grizzly.nio.AbstractNIOAsyncQueueWriter.write(AbstractNIOAsyncQueueWriter.java:260)
at org.glassfish.grizzly.nio.AbstractNIOAsyncQueueWriter.write(AbstractNIOAsyncQueueWriter.java:169)
at org.glassfish.grizzly.nio.AbstractNIOAsyncQueueWriter.write(AbstractNIOAsyncQueueWriter.java:71)
at org.glassfish.grizzly.nio.transport.TCPNIOTransportFilter.handleWrite(TCPNIOTransportFilter.java:126)
at org.glassfish.grizzly.filterchain.TransportFilter.handleWrite(TransportFilter.java:191)
at org.glassfish.grizzly.filterchain.ExecutorResolver$8.execute(ExecutorResolver.java:111)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:283)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:200)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:132)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:111)
at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77)
at org.glassfish.grizzly.filterchain.FilterChainContext.write(FilterChainContext.java:890)
at org.glassfish.grizzly.filterchain.FilterChainContext.write(FilterChainContext.java:858)
at org.glassfish.grizzly.http.io.OutputBuffer.flushBuffer(OutputBuffer.java:1029)
at org.glassfish.grizzly.http.io.OutputBuffer.flushBinaryBuffers(OutputBuffer.java:1016)
at org.glassfish.grizzly.http.io.OutputBuffer.flushAllBuffers(OutputBuffer.java:987)
at org.glassfish.grizzly.http.io.OutputBuffer.flush(OutputBuffer.java:738)
at org.apache.catalina.connector.OutputBuffer.doFlush(OutputBuffer.java:291)
at org.apache.catalina.connector.OutputBuffer.flush(OutputBuffer.java:275)
at org.apache.catalina.connector.CoyoteOutputStream.flush(CoyoteOutputStream.java:175)
at java.io.FilterOutputStream.flush(FilterOutputStream.java:140)
at com.ctc.wstx.io.UTF8Writer.flush(UTF8Writer.java:103)
at com.ctc.wstx.sw.BufferingXmlWriter.flush(BufferingXmlWriter.java:225)
at com.ctc.wstx.sw.BaseStreamWriter.flush(BaseStreamWriter.java:259)
at com.sun.xml.ws.util.xml.XMLStreamWriterFilter.flush(XMLStreamWriterFilter.java:71)
at com.sun.xml.ws.streaming.XMLStreamWriterUtil.getOutputStream(XMLStreamWriterUtil.java:103)
at com.sun.xml.ws.message.jaxb.JAXBMessage.writePayloadTo(JAXBMessage.java:403)
at com.sun.xml.ws.message.AbstractMessageImpl.writeTo(AbstractMessageImpl.java:192)
at com.sun.xml.ws.api.message.MessageWrapper.writeTo(MessageWrapper.java:226)
at com.sun.xml.ws.encoding.StreamSOAPCodec.encode(StreamSOAPCodec.java:144)
at com.sun.xml.ws.encoding.SOAPBindingCodec.encode(SOAPBindingCodec.java:242)
at com.sun.xml.ws.transport.http.HttpAdapter.encodePacket(HttpAdapter.java:636)
at com.sun.xml.ws.transport.http.HttpAdapter.access$100(HttpAdapter.java:108)
at com.sun.xml.ws.transport.http.HttpAdapter$HttpToolkit.handle(HttpAdapter.java:878)
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.JAXWSServlet.doPost(JAXWSServlet.java:169)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:707)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
at org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1682)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:318)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:160)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:734)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:673)
at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:99)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:174)
at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:416)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:283)
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:206)
at org.glassfish.grizzly.http.server.HttpHandler.doHandle(HttpHandler.java:180)
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:283)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:200)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:132)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:111)
at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77)
at org.glassfish.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(TCPNIOTransport.java:536)
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:591)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:571)
at java.lang.Thread.run(Thread.java:745)
Grave: Trying to add database driver (JDBC): com.microsoft.jdbc.sqlserver.jdbc.SQLServerDriver - Advertencia:
I think you didn't specify classpath.
Add SQLServer dependency and add the name of this driver to your dataSource connection.
How to add look here

Equinox Jetty: ClassNotFound when trying use JDBCSessionManager

I am getting a ClassNotFoundException from Jetty (Equninox embedded) when trying to use JDBCSessionManager and JDBCSessionIdManager.
Exception:
2017-01-06 10:37:02.620:WARN:oejss.JDBCSessionManager:qtp1215746443-29: Unable to load session 192168178229yf02ln7ut25phh97b49003w
java.lang.ClassNotFoundException: org.eclipse.equinox.http.servlet.internal.servlet.HttpSessionAdaptor$ParentSessionListener cannot be found by org.eclipse.jetty.util_9.3.9.v20160517
at org.eclipse.osgi.internal.loader.BundleLoader.findClassInternal(BundleLoader.java:439)
at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:352)
at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:344)
at org.eclipse.osgi.internal.loader.ModuleClassLoader.loadClass(ModuleClassLoader.java:160)
at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:348)
at java.io.ObjectInputStream.resolveClass(ObjectInputStream.java:628)
at org.eclipse.jetty.util.ClassLoadingObjectInputStream.resolveClass(ClassLoadingObjectInputStream.java:59)
at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1620)
at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1521)
at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1781)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1353)
at java.io.ObjectInputStream.readObject(ObjectInputStream.java:373)
at java.util.HashMap.readObject(HashMap.java:1404)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:1058)
at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1909)
at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1808)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1353)
at java.io.ObjectInputStream.readObject(ObjectInputStream.java:373)
at org.eclipse.jetty.server.session.JDBCSessionManager$1.run(JDBCSessionManager.java:970)
at org.eclipse.jetty.server.handler.ContextHandler.handle(ContextHandler.java:1262)
at org.eclipse.jetty.server.session.JDBCSessionManager.loadSession(JDBCSessionManager.java:992)
at org.eclipse.jetty.server.session.JDBCSessionManager.getSession(JDBCSessionManager.java:502)
at org.eclipse.jetty.server.session.JDBCSessionManager.getSession(JDBCSessionManager.java:75)
at org.eclipse.jetty.server.session.AbstractSessionManager.getHttpSession(AbstractSessionManager.java:331)
at org.eclipse.jetty.server.session.SessionHandler.checkRequestedSessionId(SessionHandler.java:275)
at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:151)
at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1106)
at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:134)
at org.eclipse.jetty.server.Server.handle(Server.java:524)
at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:319)
at org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:253)
at org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:273)
at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:95)
at org.eclipse.jetty.io.SelectChannelEndPoint$2.run(SelectChannelEndPoint.java:93)
at org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.executeProduceConsume(ExecuteProduceConsume.java:303)
at org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.produceConsume(ExecuteProduceConsume.java:148)
at org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.run(ExecuteProduceConsume.java:136)
at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:671)
at org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(QueuedThreadPool.java:589)
at java.lang.Thread.run(Thread.java:745)
I am using a JettyCustomizer to hook into the Jetty startup to change the default HashSessionManager with the JDBCSessionManager. The JettyCustomizer is located in a Fragment Bundle which belongs to
Fragment-Host: org.eclipse.equinox.http.jetty
I got this idea from https://wiki.eclipse.org/RAP/FAQ#How_can_I_use_Jetty_basic_authentication_in_my_application.3F
This setup works ok, and JDBCSessionManager places a session in the Database. The session is Serialized to a Byte-BLOB and stored in the DB. I can see it there.
But it seems the serialization is done by org.equinox.http and it places class reference like org.eclipse.equinox.http.servlet.internal.servlet.HttpSessionAdaptor$ParentSessionListener into the BLOB.
Note, that internal.servlet.HttpSessionAdaptor is an internal class which is not exported to other bundles.
Now when the session information is read again from the database (e.g. when I access the webpage again later with the same sessionCookie) I run into this problem when org.eclipse.jetty.util.ClassLoadingObjectInputStream.resolveClass(ClassLoadingObjectInputStream.java:59) tries to load the classHttpSessionAdaptor$ParentSessionListener but cannot see it (because it is a) internal and / or b) in another bundle.
org.eclipse.jetty.util.ClassLoadingObjectInputStream lives in bundle org.eclipse.jetty.util but org.eclipse.equinox.http.servlet.internal.servlet.HttpSessionAdaptor$ParentSessionListener lives in bundle org.eclipse.equinox.http.servlet.
org.eclipse.jetty.util.ClassLoadingObjectInputStream seems to do the following:
#Override
public Class<?> resolveClass (java.io.ObjectStreamClass cl) throws IOException, ClassNotFoundException
{
try
{
return Class.forName(cl.getName(), false, Thread.currentThread().getContextClassLoader());
}
catch (ClassNotFoundException e)
{
return super.resolveClass(cl);
}
}
Is there anybody from the OSGI experts with an ideas?
I would describe the problem as that Session byte-BLOB contains Class References to internal classes which cannot be seen by org.eclipse.jetty.util.ClassLoadingObjectInputStream.resolveClass
Does that seem like a bug? Or is the approach with the FragmentBundle with the the wrong approach? (IMO it is the only way I found to exchange the SessionManager)
The issue is probably because ClassLoadingObjectInputStream is using the TCCL for class resolution, which - in Equinox - by default is the org.eclipse.osgi.internal.framework.ContextFinder. It is finding the first bundle on the call stack. This is likely the Jetty bundle, which does not see any of the Equinox classes.
As far as the Equinox HTTP Service is concerned, the fragment approach is the right one for hooking into Jetty. If I'm reading the code path right, you could try the following things.
(1) Set class loader on ContextHandler
In your JettyCustomizer.customizeContext you should inspect the context. It should be a ServletContextHandler. Use its setClassLoader method to give it a class loader that knows about the Equinox classes (which any fragment of org.eclipse.equinox.http.jetty should know anyway) and any other classes of your own custom code.
(2) Fork/patch JDBCSessionManager
If approach 1 does not work then you likely need to create your own fork of JDBCSessionManager. Extending might not work because of visibility issues (some methods are private). You need to override/patch/reimplement the JDBCSessionManager.loadSession method to use the correct class loader for loading. In the original implementation you can see why approach 1 should work (in theory). The code of your implementation can be much simpler, though.
If your fragment also imports the packages of your code, then simple use your fragment class loader. Otherwise you can create a custom one that delegates to the correct bundles for resolution.

Exception using weld CDI with Jetty: Singleton not set for STATIC_INSTANCE

I am trying to configure Jetty with JSF and Weld CDI. After following this manual, I stumble upon the following stacktrace:
Caused by: java.lang.IllegalStateException: Singleton not set for STATIC_INSTANCE => []
at org.jboss.weld.bootstrap.api.helpers.RegistrySingletonProvider$RegistrySingleton.get(RegistrySingletonProvider.java:28)
at org.jboss.weld.Container.instance(Container.java:55)
at org.jboss.weld.SimpleCDI.<init>(SimpleCDI.java:77)
at org.jboss.weld.environment.WeldProvider$EnvironmentCDI.<init>(WeldProvider.java:45)
at org.jboss.weld.environment.WeldProvider.getCDI(WeldProvider.java:61)
at javax.enterprise.inject.spi.CDI.current(CDI.java:60)
at org.jboss.weld.servlet.WeldInitialListener.contextInitialized(WeldInitialListener.java:94)
at org.jboss.weld.servlet.api.helpers.ForwardingServletListener.contextInitialized(ForwardingServletListener.java:34)
at org.jboss.weld.environment.servlet.EnhancedListener.onStartup(EnhancedListener.java:65)
at org.eclipse.jetty.plus.annotation.ContainerInitializer.callStartup(ContainerInitializer.java:140)
at org.eclipse.jetty.annotations.ServletContainerInitializersStarter.doStart(ServletContainerInitializersStarter.java:63)
... 50 more
Does someone see what is going wrong here?
This error appears if you forget the beans.xml file or, as in my case, you have put it in the wrong place. Your beans.xml can have only the root element but must exist.
For a Maven project remember that:
context.xml shoud stay in src/main/webapp/META-INF/
beans.xml should stay in src/main/resources/META-INF/
I had this problem when I moved an application developed using Glassfish (that doesn't need these files) to Tomcat 7.
The problem is that you're using both weld-servlet and weld-servlet-core in your pom. This is causing duplicate class entries as weld-servlet is an aggregate of weld-servlet-core. Removing the weld-servlet-core dependency fixed the singleton not set error.
Now, when I did that, I received errors about JSF but that may be other configuration issues.

Has glassfish 2.1.1 a bug handling http request and handle them twice?

I'm using glassfish 2.1.1. I've watched a mysterious http/webservice-call handling. It seams an http request is handled by two different threads.
After http basic authentication the first thread is faster. Persisting some data end, but writing response fails in glassfish internal.
The second thread fails, because it tries to persist identical data and there are (unique) constrain failures. The response (the failure) of second thread was delivered to client.
I don't won't discuss the behavior with the unique constrain failure. I've improve the webservice, so it can handle this better, because it could be happen anytime, that the client send the ws call a second time.
But I think, glassfish 2.1.1 has an bug handling http request. Is there any known issue? Have I done an mistake?
[#|2010-03-22T10:40:54.150+0000|INFO|sun-appserver2.1|javax.enterprise.system.core|_ThreadID=10;_ThreadName=main;|Starting Sun GlassFish Enterprise Server v2.1.1 ((v2.1 Patch06)(9.1_02 Patch12)) (build b31g-fcs) ...|#]
...
[#|2010-03-22T11:18:44.220+0000|FINE|sun-appserver2.1|mypackage.module.security.auth.realm.YaJdbcRealm|_ThreadID=26;_ThreadName=httpSSLWorkerThread-8080-1;ClassName=mypackage.module.security.auth.realm.YaJdbcRealm;MethodName=authenticate;_RequestID=4d8f23e9-5106-4d64-b865-1638d7075bde;|JDBC authenticate successful for: 8002 groups:[roleUser]|#]
[#|2010-03-22T11:18:44.220+0000|FINE|sun-appserver2.1|mypackage.module.security.auth.login.YaJdbcLoginModule|_ThreadID=26;_ThreadName=httpSSLWorkerThread-8080-1;ClassName=mypackage.module.security.auth.login.YaJdbcLoginModule;MethodName=authenticate;_RequestID=4d8f23e9-5106-4d64-b865-1638d7075bde;|JDBC login succeeded for: 8002 groups:[roleUser]|#]
[#|2010-03-22T11:18:44.220+0000|FINE|sun-appserver2.1|mypackage.module.security.auth.realm.YaJdbcRealm|_ThreadID=39;_ThreadName=httpSSLWorkerThread-8080-2;ClassName=mypackage.module.security.auth.realm.YaJdbcRealm;MethodName=authenticate;_RequestID=4ca7e3e5-5ab7-41ec-b3c9-d9260b1164c9;|JDBC authenticate successful for: 8002 groups:[roleUser]|#]
[#|2010-03-22T11:18:44.220+0000|FINE|sun-appserver2.1|mypackage.module.security.auth.login.YaJdbcLoginModule|_ThreadID=39;_ThreadName=httpSSLWorkerThread-8080-2;ClassName=mypackage.module.security.auth.login.YaJdbcLoginModule;MethodName=authenticate;_RequestID=4ca7e3e5-5ab7-41ec-b3c9-d9260b1164c9;|JDBC login succeeded for: 8002 groups:[roleUser]|#]
[#|2010-03-22T11:18:44.220+0000|FINE|sun-appserver2.1|mypackage.MyWebService|_ThreadID=26;_ThreadName=httpSSLWorkerThread-8080-1;ClassName=mypackage.MyWebService;MethodName=enqueue;_RequestID=4d8f23e9-5106-4d64-b865-1638d7075bde;|Received WebService call to enqueue() from client 59|#]
[#|2010-03-22T11:18:44.220+0000|FINE|sun-appserver2.1|mypackage.MyWebService|_ThreadID=39;_ThreadName=httpSSLWorkerThread-8080-2;ClassName=mypackage.MyWebService;MethodName=enqueue;_RequestID=4ca7e3e5-5ab7-41ec-b3c9-d9260b1164c9;|Received WebService call to enqueue() from client 59|#]
...
[#|2010-03-22T11:18:44.267+0000|FINE|sun-appserver2.1|mypackage.MyWebService|_ThreadID=26;_ThreadName=httpSSLWorkerThread-8080-1;ClassName=mypackage.MyWebService;MethodName=enqueue;_RequestID=4d8f23e9-5106-4d64-b865-1638d7075bde;|Successfully finished WebService call to enqueue() from client 59|#]
[#|2010-03-22T11:18:44.329+0000|WARNING|sun-appserver2.1|javax.enterprise.system.container.ejb|_ThreadID=26;_ThreadName=httpSSLWorkerThread-8080-1;_RequestID=4d8f23e9-5106-4d64-b865-1638d7075bde;|invocation error on ejb endpoint MyWebService at /MyWebserviceService/MyWebservice : com.sun.xml.stream.XMLStreamException2
javax.xml.ws.WebServiceException: com.sun.xml.stream.XMLStreamException2
at com.sun.xml.ws.encoding.StreamSOAPCodec.encode(StreamSOAPCodec.java:111)
at com.sun.xml.ws.encoding.SOAPBindingCodec.encode(SOAPBindingCodec.java:281)
at com.sun.xml.ws.transport.http.HttpAdapter.encodePacket(HttpAdapter.java:320)
at com.sun.xml.ws.transport.http.HttpAdapter.access$100(HttpAdapter.java:93)
at com.sun.xml.ws.transport.http.HttpAdapter$HttpToolkit.handle(HttpAdapter.java:454)
at com.sun.xml.ws.transport.http.HttpAdapter.handle(HttpAdapter.java:244)
at com.sun.xml.ws.transport.http.servlet.ServletAdapter.handle(ServletAdapter.java:135)
at com.sun.enterprise.webservice.Ejb3MessageDispatcher.handlePost(Ejb3MessageDispatcher.java:113)
at com.sun.enterprise.webservice.Ejb3MessageDispatcher.invoke(Ejb3MessageDispatcher.java:87)
at com.sun.enterprise.webservice.EjbWebServiceServlet.dispatchToEjbEndpoint(EjbWebServiceServlet.java:231)
at com.sun.enterprise.webservice.EjbWebServiceServlet.service(EjbWebServiceServlet.java:157)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:847)
at com.sun.enterprise.web.AdHocContextValve.invoke(AdHocContextValve.java:114)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:648)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:593)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:587)
at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:87)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:222)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:648)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:593)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:587)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:1093)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:166)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:648)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:593)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:587)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:1093)
at org.apache.coyote.tomcat5.CoyoteAdapter.service(CoyoteAdapter.java:291)
at com.sun.enterprise.web.connector.grizzly.DefaultProcessorTask.invokeAdapter(DefaultProcessorTask.java:666)
at com.sun.enterprise.web.connector.grizzly.comet.CometEngine.executeServlet(CometEngine.java:616)
at com.sun.enterprise.web.connector.grizzly.comet.CometEngine.handle(CometEngine.java:362)
at com.sun.enterprise.web.connector.grizzly.comet.CometAsyncFilter.doFilter(CometAsyncFilter.java:84)
at com.sun.enterprise.web.connector.grizzly.async.DefaultAsyncExecutor.invokeFilters(DefaultAsyncExecutor.java:189)
at com.sun.enterprise.web.connector.grizzly.async.DefaultAsyncExecutor.interrupt(DefaultAsyncExecutor.java:164)
at com.sun.enterprise.web.connector.grizzly.async.AsyncProcessorTask.doTask(AsyncProcessorTask.java:92)
at com.sun.enterprise.web.connector.grizzly.TaskBase.run(TaskBase.java:264)
at com.sun.enterprise.web.connector.grizzly.ssl.SSLWorkerThread.run(SSLWorkerThread.java:106)
Caused by: com.sun.xml.stream.XMLStreamException2
at com.sun.xml.stream.writers.XMLStreamWriterImpl.flush(XMLStreamWriterImpl.java:416)
at com.sun.xml.ws.encoding.StreamSOAPCodec.encode(StreamSOAPCodec.java:109)
... 36 more
Caused by: ClientAbortException: java.nio.channels.ClosedChannelException
at org.apache.coyote.tomcat5.OutputBuffer.doFlush(OutputBuffer.java:385)
at org.apache.coyote.tomcat5.OutputBuffer.flush(OutputBuffer.java:351)
at org.apache.coyote.tomcat5.CoyoteOutputStream.flush(CoyoteOutputStream.java:176)
at com.sun.xml.stream.writers.UTF8OutputStreamWriter.flush(UTF8OutputStreamWriter.java:153)
at com.sun.xml.stream.writers.XMLStreamWriterImpl.flush(XMLStreamWriterImpl.java:414)
... 37 more
Caused by: java.nio.channels.ClosedChannelException
at sun.nio.ch.SocketChannelImpl.ensureWriteOpen(SocketChannelImpl.java:126)
at sun.nio.ch.SocketChannelImpl.write(SocketChannelImpl.java:324)
at com.sun.enterprise.web.connector.grizzly.OutputWriter.flushChannel(OutputWriter.java:91)
at com.sun.enterprise.web.connector.grizzly.OutputWriter.flushChannel(OutputWriter.java:66)
at com.sun.enterprise.web.connector.grizzly.SocketChannelOutputBuffer.flushChannel(SocketChannelOutputBuffer.java:172)
at com.sun.enterprise.web.connector.grizzly.async.AsynchronousOutputBuffer.flushChannel(AsynchronousOutputBuffer.java:81)
at com.sun.enterprise.web.connector.grizzly.SocketChannelOutputBuffer.flushBuffer(SocketChannelOutputBuffer.java:205)
at com.sun.enterprise.web.connector.grizzly.async.AsynchronousOutputBuffer.flushBuffer(AsynchronousOutputBuffer.java:114)
at com.sun.enterprise.web.connector.grizzly.SocketChannelOutputBuffer.flush(SocketChannelOutputBuffer.java:183)
at com.sun.enterprise.web.connector.grizzly.async.AsynchronousOutputBuffer.flush(AsynchronousOutputBuffer.java:104)
at com.sun.enterprise.web.connector.grizzly.DefaultProcessorTask.action(DefaultProcessorTask.java:1100)
at org.apache.coyote.Response.action(Response.java:237)
at org.apache.coyote.tomcat5.OutputBuffer.doFlush(OutputBuffer.java:381)
... 41 more
|#]
[#|2010-03-22T11:18:44.376+0000|WARNING|sun-appserver2.1|oracle.toplink.essentials.session.file:/mygf-211/domains/mydomain/applications/j2ee-apps/myear/myjar-myPu|_ThreadID=39;_ThreadName=httpSSLWorkerThread-8080-2;_RequestID=4ca7e3e5-5ab7-41ec-b3c9-d9260b1164c9;|
Local Exception Stack:
Exception [TOPLINK-4002] (Oracle TopLink Essentials - 2.1 (Build b31g-fcs (10/19/2009))): oracle.toplink.essentials.exceptions.DatabaseException
Internal Exception: com.microsoft.sqlserver.jdbc.SQLServerException: Eine Zeile mit doppeltem Schlüssel kann in das 'dbo.MY_TABLE'-Objekt mit dem eindeutigen 'MY_INDEX'-Index nicht eingefügt werden.
I did a quick search at https://glassfish.dev.java.net/issues/query.cgi and did not see a report that looked like a duplicate of the situation that you are encountering here... though I may have missed it.
You should probably report this issue to the GlassFish developers, via their issue tracker: https://glassfish.dev.java.net/servlets/ProjectIssues.
You may have misread the log or done something wrong in your code, but this is really hard to tell given the limited amount of info that you have given in this question... But, SO doesn't really work as an issue analysis/resolution system. The GF issue tracker is a better choice for that.

LinkageError: loader constraints violated when linking javax/xml/namespace/QName in Websphere6.1 using resteasy

I am getting this error when making a web services call. I couldn't figure out a workround for this. ANy help is greatly appreciated.
related library I have is:
axis-1.3.jar
axis-jaxrpc-1.3.jar
axis-saaj-1.3.jar
axis-wsdl4j-1.5.1.jar
jaxb-api-2.1.jar
jaxb-impl-2.1.8.jar
jaxen-1.1-beta-9.jar
jaxrs-api-1.0-beta-9.jar
In websphere 61 admin setting is the following:
Enterprise Application
-> WAR Classloader Mode : PARENT_LAST
* Web Module :
-> ClassLoader Mode : application_FIRST
Caused by: java.lang.LinkageError: loader constraints violated when linking javax/xml/namespace/QName class
at com.sun.xml.bind.v2.model.impl.RuntimeBuiltinLeafInfoImpl.(RuntimeBuiltinLeafInfoImpl.java:224)
at com.sun.xml.bind.v2.model.impl.RuntimeTypeInfoSetImpl.(RuntimeTypeInfoSetImpl.java:61)
at com.sun.xml.bind.v2.model.impl.RuntimeModelBuilder.createTypeInfoSet(RuntimeModelBuilder.java:127)
at com.sun.xml.bind.v2.model.impl.RuntimeModelBuilder.createTypeInfoSet(RuntimeModelBuilder.java:79)
at com.sun.xml.bind.v2.model.impl.ModelBuilder.(ModelBuilder.java:152)
at com.sun.xml.bind.v2.model.impl.RuntimeModelBuilder.(RuntimeModelBuilder.java:87)
at com.sun.xml.bind.v2.runtime.JAXBContextImpl.getTypeInfoSet(JAXBContextImpl.java:432)
at com.sun.xml.bind.v2.runtime.JAXBContextImpl.(JAXBContextImpl.java:297)
at com.sun.xml.bind.v2.ContextFactory.createContext(ContextFactory.java:139)
at com.sun.xml.bind.v2.ContextFactory.createContext(ContextFactory.java:117)
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 javax.xml.bind.ContextFinder.newInstance(ContextFinder.java:211)
at javax.xml.bind.ContextFinder.find(ContextFinder.java:372)
at javax.xml.bind.JAXBContext.newInstance(JAXBContext.java:574)
at org.jboss.resteasy.plugins.providers.jaxb.JAXBContextWrapper.(JAXBContextWrapper.java:74)
at org.jboss.resteasy.plugins.providers.jaxb.JAXBContextWrapper.(JAXBContextWrapper.java:99)
at org.jboss.resteasy.plugins.providers.jaxb.XmlJAXBContextFinder.createContextObject(XmlJAXBContextFinder.java:48)
at org.jboss.resteasy.plugins.providers.jaxb.AbstractJAXBContextFinder.createContext(AbstractJAXBContextFinder.java:114)
at org.jboss.resteasy.plugins.providers.jaxb.XmlJAXBContextFinder.findCachedContext(XmlJAXBContextFinder.java:39)
at org.jboss.resteasy.plugins.providers.jaxb.AbstractJAXBProvider.findJAXBContext(AbstractJAXBProvider.java:49)
at org.jboss.resteasy.plugins.providers.jaxb.AbstractJAXBProvider.getMarshaller(AbstractJAXBProvider.java:112)
at org.jboss.resteasy.plugins.providers.jaxb.AbstractJAXBProvider.writeTo(AbstractJAXBProvider.java:88)
at org.jboss.resteasy.client.core.MessageBodyParameterMarshaller$ClientRequestEntity.(MessageBodyParameterMarshaller.java:88)
at org.jboss.resteasy.client.core.MessageBodyParameterMarshaller.buildRequest(MessageBodyParameterMarshaller.java:51)
at org.jboss.resteasy.client.core.ClientInvoker.invoke(ClientInvoker.java:197)
at org.jboss.resteasy.client.core.ClientProxy.invoke(ClientProxy.java:46)
at $Proxy51.updateAccount(Unknown Source)
at com.amg.brides.wedsimple.client.WedSimpleClientImpl.updateAccount(WedSimpleClientImpl.java:72)
at com.amg.brides.wedsimple.web.WedSimpleUpdateAccountEvent.invokeClient(WedSimpleUpdateAccountEvent.java:24)
at com.amg.brides.wedsimple.web.AbstractWedSimpleAccountEvent.execute(AbstractWedSimpleAccountEvent.java:35)
at com.amg.brides.util.WebEventProcessor.processEvents(WebEventProcessor.java:29)
The basic problem is that you're loading one or more class files related to xml from an incorrect jar. Your application server does not permit you to change these libraries, because it has already loaded most of the parser from a different implementation. I tried to inspect the content of the jar files looking for javax/xml/namespace but stopped halfway. If you find it there's a good chance you can get one without the offending classes. People have been known to manually remove such files from external jars.
You can probably turn on som vm options to log classloading while the container is running. This is the java -verbose:class option.
I'm sorry I cant pinpoint the exact problem ;)
Possible solution (worked for me)
In Websphere 7 I have the same problem with axis 1.3 and 1.4
I have resolved removing QName.class from axis-jaxrpc-1.3.jar in WEB_INF\lib
This because QName.class was already present in other jar file.