I am trying to frontend a glassfish server with Apache so that pages requested on port 80 go to the glassfish server for a certain application.I am using mod_jk to do this. When I call my url in the browser the mod_jk.log contains a 'bad request' response from glassfish.
The glassfish server log has the following error
[#|2011-07-10T15:02:39.491+0100|SEVERE|glassfish3.0.1|org.apache.jk.common.HandlerRequest|_ThreadID=25;_ThreadName=Thread-1;|Error decoding request
java.lang.NullPointerException
at java.util.concurrent.ConcurrentHashMap.put(Unknown Source)
at com.sun.grizzly.tcp.Request.setAttribute(Request.java:446)
at org.apache.jk.common.HandlerRequest.decodeAttributes(HandlerRequest.java:501)
at org.apache.jk.common.HandlerRequest.decodeRequest(HandlerRequest.java:451)
at org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:303)
at org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:814)
at org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket.java:743)
at org.apache.jk.common.ChannelSocket$SocketConnection.runIt(ChannelSocket.java:936)
at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:682)
at java.lang.Thread.run(Unknown Source)
|#]
Any ideas on this greatly appreciated!
Probably too late but...
I believe you are hitting a bug in GlassFish 3.1 (and I think it's in 3.1.1 as well) which is described here: http://java.net/jira/browse/GLASSFISH-17068. There is a patch in the bug available in report until 3.1.2 is release..
Related
Server code running in Google App Engine cloud environment is throwing an exception related to GWT-RPC serialization / deserialization. It looks like the root cause is:
Caused by: java.lang.ClassNotFoundException: https:
at java.net.URLClassLoader.findClass(URLClassLoader.java:381)
at com.google.apphosting.runtime.ApplicationClassLoader.findClass(ApplicationClassLoader.java:135)
at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:349)
at com.google.gwt.user.server.rpc.impl.ServerSerializationStreamReader.deserialize(ServerSerializationStreamReader.java:543)
I believe this started occurring after we upgraded to Java 8 and version 2.8.1 of com.google.gwt libraries.
Our code used to work with an older version of GWT.
The data types being sent between client and server
are Serializable.
The ClassNotFoundException: https: is a mystery so far.
It turns out the issue was an incompatibility between gwt-servlet 2.4.0 and GWT 2.8.1
Switch to use gwt-servlet 2.8.1 made the issue go away
I saw someone else had the same issue, reported here:
https://github.com/gwtproject/gwt/issues/9224
and I verified it with our project also.
Any specific reason why abruptly connection to MSSQL server is lost. I am running web application on the same machine so network connectivity issues are out of question. My application uses Jackrabbit configured to store content with MSSQL. Application is running on Wildfly v9 with JAVA_HOME set to jdk1.8 and I have verified that wildfly is picking it up as well. Also, sqljdbc4-3.0.jar is available to wildfly modules with proper driver configuration in standalone. I am baffled as to why jdk7 adapter would be called to manage connection. However, interesting observation is that this does not occur with Wildfly 10.
standalone.xml
<driver name="sqlserver" module="com.microsoft.sqlserver">
<driver-class>com.microsoft.sqlserver.jdbc.SQLServerDriver</driver-class>
<xa-datasource-class>com.microsoft.sqlserver.jdbc.SQLServerXADataSource</xa-datasource-class>
</driver>
exception:
ERROR 21-07 16:41:13,636 (DbUtility.java:logException:92) failed to close ResultSet
ERROR 21-07 16:41:13,637 (DbUtility.java:logException:94) Reason: IJ031040: Connection is not associated with a managed connection: org.jboss.jca.adapters.jdbc.jdk7.WrappedConnectionJDK7#386eff84
ERROR 21-07 16:41:13,639 (DbUtility.java:logException:95) State/Code: null/0
I am self learning SAML. I am learning using picket link quick starts: https://github.com/jboss-developer/jboss-picketlink-quickstarts.
I deployed picketlink-federation-saml-idp-basic-wildfly.war in wildfly 9.0.2 running in port 9080 and picketlink-federation-saml-sp-post-basic-wildfly.war deployed in wildfly 9.0.2 running in port 8080. I also updated standalone.xml to update security domain for IDP and SP.
The only change I had todo in sample, was to update dependency of picketlink-jbas7, since the version in sample 2.8.0.Beta1-SNAPSHOT cannot to resolved. The maven dependency I am using in IDP is:
<dependency>
<groupId>org.picketlink.distribution</groupId>
<artifactId>picketlink-jbas7</artifactId>
<version>2.7.0.Final</version>
<scope>provided</scope>
</dependency>
The issue I am facing is, when I login to IDP and click on the SP link I get following exception in SP logs:
23:05:55,833 ERROR [org.picketlink.common] (default task-5) Service Provider could not handle the request.: java.lang.NullPointerException
at org.picketlink.identity.federation.web.handlers.saml2.SAML2IssuerTrustHandler$SPTrustHandler.handleStatusResponseType(SAML2IssuerTrustHandler.java:143)
at org.picketlink.identity.federation.web.handlers.saml2.SAML2IssuerTrustHandler.handleStatusResponseType(SAML2IssuerTrustHandler.java:70)
at org.picketlink.identity.federation.web.process.SAMLHandlerChainProcessor.callHandlerChain(SAMLHandlerChainProcessor.java:67)
at org.picketlink.identity.federation.web.process.ServiceProviderSAMLResponseProcessor.processHandlersChain(ServiceProviderSAMLResponseProcessor.java:106)
at org.picketlink.identity.federation.web.process.ServiceProviderSAMLResponseProcessor.process(ServiceProviderSAMLResponseProcessor.java:88)
at org.picketlink.identity.federation.bindings.wildfly.sp.SPFormAuthenticationMechanism.handleSAML2Response(SPFormAuthenticationMechanism.java:516)
at org.picketlink.identity.federation.bindings.wildfly.sp.SPFormAuthenticationMechanism.handleSAMLResponse(SPFormAuthenticationMechanism.java:306)
at org.picketlink.identity.federation.bindings.wildfly.sp.SPFormAuthenticationMechanism.authenticate(SPFormAuthenticationMechanism.java:268)
at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.transition(SecurityContextImpl.java:339)
at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.transition(SecurityContextImpl.java:356)
at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.access$100(SecurityContextImpl.java:325)
at io.undertow.security.impl.SecurityContextImpl.attemptAuthentication(SecurityContextImpl.java:138)
at io.undertow.security.impl.SecurityContextImpl.authTransition(SecurityContextImpl.java:113)
at io.undertow.security.impl.SecurityContextImpl.authenticate(SecurityContextImpl.java:106)
at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:55)
at io.undertow.server.handlers.DisableCacheHandler.handleRequest(DisableCacheHandler.java:33)
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:51)
at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
at io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:56)
at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58)
at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:72)
at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)
at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76)
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:282)
at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:261)
at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:80)
at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:172)
at io.undertow.server.Connectors.executeRootHandler(Connectors.java:199)
at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:774)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
Please let me know what I am doing wrong.
Thanks
I faced the same issue learning from picketbox quickstarts. I am working with wildfly 10.1.0.Final.
The first thing I noticed was that in order to get the "Basic" working is necessary (https://github.com/jboss-developer/jboss-picketlink-quickstarts):
IDP: picketlink-federation-saml-idp-basic
SP(s): picketlink-federation-saml-sp-post-basic and picketlink-federation-saml-sp-redirect-basic
I deployed all generated .war in one container for simplicity.
There were two things that helped me find what was going on:
enable TRACE debug
version of picketlink is 2.5.5.SP2 in Wildfly 10 and SAML2LoginModule was not found in that package in picketlink-wildfly8-2.5.5.SP2.jar.
In particular I had a problem with login module getting this error:
Class org.picketlink.identity.federation.bindings.wildfly.SAML2LoginModule not found from Module "deployment.picketlink-federation-saml-sp-post-basic-wildfly.war:main" from Service Module Loader
Login failure: javax.security.auth.login.LoginException: unable to find LoginModule class: org.picketlink.identity.federation.bindings.wildfly.SAML2LoginModule
What I did was change login module to: org.picketlink.identity.federation.bindings.jboss.auth.SAML2LoginModule and the quickstart started working.
I gave up on picketlink.
I used openSAML, and I was able to develop IDP initiated and SP initiated flows with no issues.
References:
https://wiki.shibboleth.net/confluence/display/OpenSAML/OSTwoUserManual#
https://github.com/rasmusson/webprofile-ref-project
We are using Apache CXF 2.5.2 for webservice client proxies. We use weblogic 10.3.4. To override the CXF logger we use the following option:
-Dorg.apache.cxf.Logger=org.apache.cxf.common.logging.Slf4jLogger
For the org.apache.cxf.common.logging.Slf4jLogger, we've included the cxf-common-utilities-2.5.2 in our build.
When we try to deploy to weblogic we get the following exception:
[ERROR] Target state: deploy failed on Server AdminServer
[ERROR] java.lang.NoClassDefFoundError: weblogic/wsee/jaxws/spi/WLSProvider
According to documentation, your WebService client should have wseeclient.jar as it's runtime dependency. If the problems is still there, then include wlfullclient.jar (see Creating a wlfullclient.jar for JDK 1.6 client applications ).
I have Apache SOLR working with ColdFusion on my local machine, however, when I tried to make the move to production (environments are different), I keep getting the HTTP 500 message below. Production environment is using Ubuntu Lucid, Apache, ColdFusion 9.0.1. Using the version of SOLR installed with ColdFusion.
The path for solrconfig.xml in the error message, "/opt/jrun4/servers/prod-autofeed1/cfusion.ear/cfusion.war/WEB-INF/cfusion/collections/autofeed/conf/" is correct.
Any suggestions? Thank you.
HTTP ERROR: 500
Severe errors in solr configuration.
Check your log files for more detailed information on what may be wrong.
If you want solr to continue after configuration errors, change:
<abortOnConfigurationError>false</abortOnConfigurationError>
in solr.xml
-------------------------------------------------------------
java.lang.RuntimeException: Can't find resource 'solrconfig.xml' in classpath or '/opt/jrun4/servers/prod-autofeed1/cfusion.ear/cfusion.war/WEB-INF/cfusion/collections/autofeed/conf/', cwd=/opt/jrun4/servers/cfusion/cfusion-ear/cfusion-war/WEB-INF/cfusion/solr
at org.apache.solr.core.SolrResourceLoader.openResource(SolrResourceLoader.java:260)
at org.apache.solr.core.SolrResourceLoader.openConfig(SolrResourceLoader.java:228)
at org.apache.solr.core.Config.<init>(Config.java:101)
at org.apache.solr.core.SolrConfig.<init>(SolrConfig.java:130)
at org.apache.solr.core.CoreContainer.create(CoreContainer.java:405)
at org.apache.solr.core.CoreContainer.load(CoreContainer.java:278)
at org.apache.solr.core.CoreContainer$Initializer.initialize(CoreContainer.java:117)
at org.apache.solr.servlet.SolrDispatchFilter.init(SolrDispatchFilter.java:83)
at org.mortbay.jetty.servlet.FilterHolder.doStart(FilterHolder.java:99)
at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:40)
at org.mortbay.jetty.servlet.ServletHandler.initialize(ServletHandler.java:594)
at org.mortbay.jetty.servlet.Context.startContext(Context.java:139)
at org.mortbay.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1218)
at org.mortbay.jetty.handler.ContextHandler.doStart(ContextHandler.java:500)
at org.mortbay.jetty.webapp.WebAppContext.doStart(WebAppContext.java:448)
at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:40)
at org.mortbay.jetty.handler.HandlerCollection.doStart(HandlerCollection.java:147)
at org.mortbay.jetty.handler.ContextHandlerCollection.doStart(ContextHandlerCollection.java:161)
at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:40)
at org.mortbay.jetty.handler.HandlerCollection.doStart(HandlerCollection.java:147)
at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:40)
at org.mortbay.jetty.handler.HandlerWrapper.doStart(HandlerWrapper.java:117)
at org.mortbay.jetty.Server.doStart(Server.java:210)
at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:40)
at org.mortbay.xml.XmlConfiguration.main(XmlConfiguration.java:929)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at org.mortbay.start.Main.invokeMain(Main.java:183)
at org.mortbay.start.Main.start(Main.java:497)
at org.mortbay.start.Main.main(Main.java:115)
RequestURI=/solr/
Powered by Jetty://
Double check permissions on the directory /opt/jrun4/servers/prod-autofeed1/cfusion.ear/cfusion.war/WEB-INF/cfusion/collections/autofeed/conf and the file /opt/jrun4/servers/prod-autofeed1/cfusion.ear/cfusion.war/WEB-INF/cfusion/collections/autofeed/conf/solrconfig.xml. If the user solr is run under can't read the dir/file, that'd do it. To test, you might even su to the user in question and simply try to cat the config file.