I'm trying to setup a specific jetty SSL context factory inside Karaf (in fact, Fabric8 (www.fabric8.io)).
I do this directly into the jetty.xml file:
<New id="sslContextFactory" class="fr.maatg.pandora.sl.jetty.GridSslContextFactory">
...
</New>
When I start the container, Pax Web generate an exception ( full exception https://gist.github.com/jrevillard/adb8e0bc0b1e9b568a67):
Caused by: java.lang.ClassNotFoundException: fr.maatg.pandora.sl.jetty.GridSslContextFactory not found by org.ops4j.pax.web.pax-web-jetty [100]
at org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1532)
at org.apache.felix.framework.BundleWiringImpl.access$400(BundleWiringImpl.java:75)
at org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:1955)
at java.lang.ClassLoader.loadClass(ClassLoader.java:358)[:1.7.0_51]
at org.eclipse.jetty.util.Loader.loadClass(Loader.java:100)
at org.eclipse.jetty.xml.XmlConfiguration$JettyXmlConfiguration.nodeClass(XmlConfiguration.java:366)
at org.eclipse.jetty.xml.XmlConfiguration$JettyXmlConfiguration.newObj(XmlConfiguration.java:767)
at org.eclipse.jetty.xml.XmlConfiguration$JettyXmlConfiguration.configure(XmlConfiguration.java:404)
at org.eclipse.jetty.xml.XmlConfiguration$JettyXmlConfiguration.configure(XmlConfiguration.java:334)
at org.eclipse.jetty.xml.XmlConfiguration.configure(XmlConfiguration.java:281)
... 16 more
Could someone tell me how I can use my specific factory ?
Jerome
As the pax-web-jetty bundle doesn't support a dynamic import of "third-party" packages you'll need to create an extra fragment bundle that contains this class and attach it to the pax-web-jetty bundle. A working sample on how to add this to pax-web-jetty can be found at the pax web samples
In short the fragment bundle manifest needs to contain a Fragment host. With the felix-bundle-plugin it needs to look like this:
<Fragment-Host>org.ops4j.pax.web.pax-web-jetty</Fragment-Host>
Related
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.
I created a fragment host for org.ops4j.pax.web.pax-web-jetty which contains a jetty.xml file which is perfectly picked up inside Karaf.
This jetty.xml file contains a line like this:
<Set name="host"><Property name="jetty.ssl.host" deprecated="jetty.host" /></Set>
Could you tell me where to set jetty.ssl.host so that I can set a value please ?
Best,
Jerome
Afaik, it's not possible in the current version of pax-web.
In the source, the XmlConfiguration doesn't have any property set :
XmlConfiguration configuration = new XmlConfiguration(jettyResource);
// configuration.configure(m_server);
Method method = XmlConfiguration.class.getMethod("configure", Object.class);
method.invoke(configuration, server);
This kind of property (<Property ../>) is normally set using the XmlConfiguration.getProperties() method, which isn't used here.
You should probably use another way to provide an external configuration (like systemProperty for example, or creating your own bean in this jetty.xml file).
We have a situation where a Liberty application accesses a custom resource adapter through a JNDI lookup to a connection factory, defined in the server.xml. The combination of the connectionFactory, resourceAdapter, and enterpriseApplication nodes in the server.xml appears to make it impossible to bundle the rar inside the ear and push an ear as a single entity without major app refactoring, which is a non-starter.
I see two options for getting around this right now:
Push the rar/ear combo as a bundled server package, or
Modify the Liberty buildpack to pull in the rar at push time, generating the expected nodes in the server.xml
Am I missing a third option?
Thanks, Tom
The third option would be to embed the RAR in your app, but I didn't understand your comment about why that would require extensive app refactoring. In theory, the app shouldn't change, just the config...
See the IBM Knowledge Center topic http://www-01.ibm.com/support/knowledgecenter/SSEQTP_8.5.5/com.ibm.websphere.wlp.doc/ae/twlp_jca_config_resadapters.html?lang=en for details on configuring a connection factory for use with an embedded resource adapter.
For the standalone resource adapter, I assume you had something like this in server.xml:
<connectionFactory jndiName="eis/NAME" type="javax.resource.cci.ConnectionFactory">
<properties.rarName dataStoreName="name" hostName="otherName"/>
</connectionFactory>
<resourceAdapter id="rarName" location="rarName.rar"/>
when you embed the rar in the ear, as you noted, that resourceAdapter node goes away and instead you would use something like this:
<application location="C:/applications/app1.ear"/>
<connectionFactory jndiName="eis/NAME” type='javax.resource.cci.ConnectionFactory’>
<properties.app1.rarName dataStoreName="name" hostName="otherName"/>
</connectionFactory>
Note that for an embedded resource adapter, the properties element must now also include the application name (in this case “app1”) in the name of the element.
As indicated in the Knowledge Center topic, if you wanted to override the default name of the resource adapter, you could instead do:
<application location="C:/applications/app1.ear”>
<resourceAdapter id=“rarName" alias="MyEmbeddedRA"/>
</application>
<connectionFactory jndiName="eis/NAME" type="javax.resource.cci.ConnectionFactory">
<properties.app1.MyEmbeddedRA dataStoreName="name" hostName="otherName"/>
</connectionFactory>
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
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