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.
Related
In the following project
https://github.com/Crash1hd/MultipleTestTesting
I am getting the following error
java.lang.IllegalStateException: Illegal connection pointer 1. Current pointers for thread Thread[DefaultDispatcher-worker-1 #coroutine#3,5,SDK 28] []
at org.robolectric.shadows.ShadowSQLiteConnection$Connections.getConnection(ShadowSQLiteConnection.java:367)
at org.robolectric.shadows.ShadowSQLiteConnection$Connections.prepareStatement(ShadowSQLiteConnection.java:416)
at org.robolectric.shadows.ShadowSQLiteConnection.nativePrepareStatement(ShadowSQLiteConnection.java:89)
at android.database.sqlite.SQLiteConnection.nativePrepareStatement(SQLiteConnection.java)
at android.database.sqlite.SQLiteConnection.acquirePreparedStatement(SQLiteConnection.java:903)
at android.database.sqlite.SQLiteConnection.execute(SQLiteConnection.java:562)
at android.database.sqlite.SQLiteSession.beginTransactionUnchecked(SQLiteSession.java:323)
at android.database.sqlite.SQLiteSession.beginTransaction(SQLiteSession.java:298)
at android.database.sqlite.SQLiteDatabase.beginTransaction(SQLiteDatabase.java:549)
at android.database.sqlite.SQLiteDatabase.beginTransaction(SQLiteDatabase.java:460)
at androidx.sqlite.db.framework.FrameworkSQLiteDatabase.beginTransaction(FrameworkSQLiteDatabase.java:69)
at androidx.room.RoomDatabase.beginTransaction(RoomDatabase.java:277)
at com.mycomp.roomwordsample.data.db.WordDao_Impl.deleteAll(WordDao_Impl.java:81)
at com.mycomp.roomwordsample.data.db.WordRepository$deleteAllLogsOlderThan$2.invokeSuspend(WordRepository.kt:28)
at |b|b|b(Coroutine boundary.|b(|b)
at com.mycomp.roomwordsample.ui.WordViewModel$deleteAllLogsOlderThanA$1.invokeSuspend(WordViewModel.kt:36)
Caused by: java.lang.IllegalStateException: Illegal connection pointer 1. Current pointers for thread Thread[DefaultDispatcher-worker-1 #coroutine#3,5,SDK 28] []
at org.robolectric.shadows.ShadowSQLiteConnection$Connections.getConnection(ShadowSQLiteConnection.java:367)
at org.robolectric.shadows.ShadowSQLiteConnection$Connections.prepareStatement(ShadowSQLiteConnection.java:416)
at org.robolectric.shadows.ShadowSQLiteConnection.nativePrepareStatement(ShadowSQLiteConnection.java:89)
at android.database.sqlite.SQLiteConnection.nativePrepareStatement(SQLiteConnection.java)
at android.database.sqlite.SQLiteConnection.acquirePreparedStatement(SQLiteConnection.java:903)
at android.database.sqlite.SQLiteConnection.execute(SQLiteConnection.java:562)
at android.database.sqlite.SQLiteSession.beginTransactionUnchecked(SQLiteSession.java:323)
at android.database.sqlite.SQLiteSession.beginTransaction(SQLiteSession.java:298)
at android.database.sqlite.SQLiteDatabase.beginTransaction(SQLiteDatabase.java:549)
at android.database.sqlite.SQLiteDatabase.beginTransaction(SQLiteDatabase.java:460)
at androidx.sqlite.db.framework.FrameworkSQLiteDatabase.beginTransaction(FrameworkSQLiteDatabase.java:69)
at androidx.room.RoomDatabase.beginTransaction(RoomDatabase.java:277)
at com.mycomp.roomwordsample.data.db.WordDao_Impl.deleteAll(WordDao_Impl.java:81)
at com.mycomp.roomwordsample.data.db.WordRepository$deleteAllLogsOlderThan$2.invokeSuspend(WordRepository.kt:28)
at kotlin.coroutines.jvm.internal.BaseContinuationImpl.resumeWith(ContinuationImpl.kt:32)
at kotlinx.coroutines.DispatchedTask.run(Dispatched.kt:233)
at kotlinx.coroutines.scheduling.CoroutineScheduler.runSafely(CoroutineScheduler.kt:594)
at kotlinx.coroutines.scheduling.CoroutineScheduler.access$runSafely(CoroutineScheduler.kt:60)
at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.run(CoroutineScheduler.kt:742)
When I run this set of tests
https://github.com/Crash1hd/MultipleTestTesting/blob/master/app/src/test/java/com/mycomp/roomwordsample/WordDaoTestA.kt
It seems to have to do with the function that I am calling in initializationLogging in WordApplication
https://github.com/Crash1hd/MultipleTestTesting/blob/master/app/src/main/java/com/mycomp/roomwordsample/WordApplication.kt
Commenting out LogA.purgeOldLogsGreaterThan(7) this line all the tests pass.
I am at a loss as to why it is failing? each test is exactly the same and they all work (just not all at once).
I am wondering if it has to do with how I am calling the WordViewModel in application...
Ok So I came across this blog post
https://artemzin.com/blog/how-to-mock-dependencies-in-unit-integration-and-functional-tests-dagger-robolectric-instrumentation/
and in the comments, there is this comment by Krzysiek Bielicki
You can just create Application class prefixed with 'Test'. Robolectric will automatically use it as Application for all tests.
So I tried that created class TestWordApplication added everything that was in WordApplication (but excluded the call to initializationLogging() and now all the test pass as its no longer trying to access and purge the actual database.
I found this also on the Robolectric website confirming
http://robolectric.org/custom-test-runner/
Thanks. and a very special thank you to Krzysiek Bielicki (whomever you are) as you just made my night :)
I'm getting some error with some connection to our web server.
I saw that a bug causing this was solved in Jetty 7.6. Yes we get this error on our application running under Jetty 7.5.4 but we also get this with another apps running on a newer version 9.
Do you have any idea what this can be?
We are getting this error randomly:
java.lang.IllegalStateException: zip file closed
at java.util.zip.ZipFile.ensureOpen(ZipFile.java:632)
at java.util.zip.ZipFile.access$200(ZipFile.java:56)
at java.util.zip.ZipFile$1.hasMoreElements(ZipFile.java:485)
at java.util.jar.JarFile$1.hasMoreElements(JarFile.java:239)
at org.eclipse.jetty.util.resource.JarFileResource.exists(JarFileResource.java:163)
at org.eclipse.jetty.webapp.WebAppContext$Context.getResource(WebAppContext.java:1223)
at org.eclipse.jetty.servlet.DefaultServlet.getResource(DefaultServlet.java:366)
at org.eclipse.jetty.server.ResourceCache.lookup(ResourceCache.java:188)
at org.eclipse.jetty.servlet.DefaultServlet.doGet(DefaultServlet.java:445)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:707)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:820)
at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:547)
at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:480)
at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:119)
at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:483)
at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:227)
at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:941)
at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:409)
at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:186)
at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:875)
at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:117)
at org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:219)
at org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:149)
at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:110)
at org.eclipse.jetty.server.Server.handle(Server.java:345)
at org.eclipse.jetty.server.HttpConnection.handleRequest(HttpConnection.java:441)
at org.eclipse.jetty.server.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:919)
at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:582)
at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:218)
at org.eclipse.jetty.server.AsyncHttpConnection.handle(AsyncHttpConnection.java:51)
at org.eclipse.jetty.io.nio.SelectChannelEndPoint.handle(SelectChannelEndPoint.java:586)
at org.eclipse.jetty.io.nio.SelectChannelEndPoint$1.run(SelectChannelEndPoint.java:44)
at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:598)
at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:533)
at java.lang.Thread.run(Thread.java:722)
There are 2 main causes for this.
A bad/corrupt JAR file in your classpath.
The JVM built-in URL caching getting in the way.
For a bad/corrupt JAR file, you'll have to isolate that on your own, figure out which one it is. Maybe by just unjaring all of them one by one till you find the problematic one.
As for the JVM URL caching, this seems to cause problems with dynamic classloaders like OSGi or hot-deploy scenarios the most.
For this scenario, you can tell jetty to set the URLConnection.setUseCaches(boolean) for each URLConnection attempt of its own.
To disable the JVM caches, add the following snippet of XML to your etc/jetty.xml
<Set class="org.eclipse.jetty.util.resource.Resource"
name="defaultUseCaches">false</Set>
You don't need to test all files to ensure the correctness of them. Just put a break point at java.util.zip.ZipFile.ensureOpen(ZipFile.java:632) and check the name field in ZipFile class: private final String name
I had the same problem after deploying jenkins war; all I had to do was to restart the server after the deploy.
Hope it helps.
This issue can also occur if you are doing any of your own reflection in that code path.
I was having the same issue because of the actual WAR being corrupt. Try rerunning mvn clean install and redeploy.
I had the same problem, after deleting all .jar files and build the path to all .jar file once again. Now it's working properly
A weird case is happening in my application, some code that is in a Guice EagerSingleton is being run twice. I printed a stack trace (Below) and it shows that the public static main of jetty is being called twice. Where could I have miss-configured it?
//Stack trace (Is printing in logs twice)
at com.ea.wsop.GraphiteReporterConfig.<init>(GraphiteReporterConfig.java:50)
at com.ea.wsop.GraphiteReporterConfig$$FastClassByGuice$$22005e5b.newInstance(<generated>)
at com.google.inject.internal.cglib.reflect.$FastConstructor.newInstance(FastConstructor.java:40)
...
at org.eclipse.jetty.start.Main.invokeMain(Main.java:477)
at org.eclipse.jetty.start.Main.start(Main.java:623)
at org.eclipse.jetty.start.Main.parseCommandLine(Main.java:273)
at org.eclipse.jetty.start.Main.main(Main.java:81)
I am running Jetty 7.2.2 & Guice Version 3.0, Please comment on which other config files would be useful to post here.
or you can use either the webapp provider or the context provider but not both in this case
I am a fan of just using contexts personally, more nimble.
just remove the jetty-webapps.xml line in your start.ini
Figured it out,
I was setting up the web app in /home/j2play/j2play/jetty/contexts/app.xml and it was in the standard Jetty/webapps directory so jetty was scanning and starting it automatically too. I moved my war outside the standard location and it works fine.
I am attempting to use Metro web services in place of the default Weblogic webservices stack contained in weblogic.jar.
The problem comes when trying to get WebLogic to use the metro stack before its own.
The steps I have taken so far is to reference the webservices-rt.jar in the project. So far I am getting this error while deploying the ear file....
Caused By: java.lang.LinkageError: loader constraint violation: when resolving field "DATETIME" the class loader (instance of weblogic/utils/classloaders/ChangeAwareClassLoader) of the referring class, javax/xml/datatype/DatatypeConstants, and the class loader (instance of ) for the field's resolved type, javax/xml/namespace/QName, have different Class objects for that type
UPDATES:
Most Recent Error is: "class javax.xml.namespace.QName has neither #WebSerivce nor #WebServiceProvider" Strange that it is looking for #Webservice on a QName object:
Contents of Application-Weblogic.xml
<wls:prefer-application-packages>
<wls:package-name>com.ctc.</wls:package-name>
<wls:package-name>com.sun.xml.</wls:package-name>
<wls:package-name>com.sun.istack.</wls:package-name>
<wls:package-name>com.sun.msv.datatype.</wls:package-name>
<wls:package-name>com.sun.msv.driver.</wls:package-name>
<wls:package-name>com.sun.msv.grammar.</wls:package-name>
<wls:package-name>com.sun.msv.reader.</wls:package-name>
<wls:package-name>com.sun.msv.relaxns.</wls:package-name>
<wls:package-name>com.sun.msv.scanner.</wls:package-name>
<wls:package-name>com.sun.msv.util.</wls:package-name>
<wls:package-name>com.sun.msv.verifier.</wls:package-name>
<wls:package-name>com.sun.msv.writer.</wls:package-name>
<wls:package-name>com.sun.org.apache.xml.internal.</wls:package-name>
<wls:package-name>com.sun.wsit.</wls:package-name>
<wls:package-name>javax.jws.</wls:package-name>
<wls:package-name>javax.xml.bind.</wls:package-name>
<wls:package-name>javax.xml.soap.</wls:package-name>
<wls:package-name>javax.xml.stream.</wls:package-name>
<wls:package-name>javax.xml.ws.</wls:package-name>
<wls:package-name>javax.xml.activation.</wls:package-name>
<wls:package-name>javax.xml.annotation.</wls:package-name>
<wls:package-name>javax.xml.mail.</wls:package-name>
<wls:package-name>javax.xml.security.</wls:package-name>
<wls:package-name>javax.xml.registry.</wls:package-name>
<wls:package-name>javax.xml.rpc.</wls:package-name>
<wls:package-name>javax.xml.crypto.</wls:package-name>
<wls:package-name>javanet.staxutils.</wls:package-name>
<wls:package-name>jp.gr.xml.</wls:package-name>
<wls:package-name>org.codehaus.stax2.</wls:package-name>
<wls:package-name>org.glassfish.gmbal.</wls:package-name>
<wls:package-name>org.iso_relax.</wls:package-name>
<wls:package-name>org.jcp.xml.dsig.</wls:package-name>
<wls:package-name>org.jvnet.</wls:package-name>
<wls:package-name>org.relaxng.</wls:package-name>
<wls:package-name>antlr.</wls:package-name>
<wls:package-name>org.apache.commons.lang.</wls:package-name>
</wls:prefer-application-packages>
Take a look at using the FilteringClassLoader which is configured in weblogic-application.xml deployment descriptor. You can instruct WebLogic to load classes from the application in favor of the libraries that are included with WebLogic. The descriptor element is and you specify the Java packages you want to load from the application.
If you are using WebLogic 10.3.4 you can use the ClassLoader Analysis to analyze the packages that are in conflict.
Check out my presentation here: SlideShare.net and my demo of the CAT here: YouTube
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.