we are using a custom login and custom security realm for authentication. It all works fine. But every time when we launch the app, and we logout, we could see the below exception in logs.
Kindly advice on how this can be avoided.
00001336 com.ibm.ws.webcontainer.util.ApplicationErrorUtils E SRVE0777E: Exception thrown by application class 'com.worklight.core.auth.impl.AuthenticationContext.checkAuthentication:570'
com.worklight.server.auth.api.WorkLightAuthenticationException
at com.worklight.core.auth.impl.AuthenticationContext.checkAuthentication(AuthenticationContext.java:570)
at com.worklight.core.auth.impl.AuthenticationContext.processRealms(AuthenticationContext.java:435)
at com.worklight.core.auth.impl.AuthenticationContext.pushCurrentResource(AuthenticationContext.java:409)
at com.worklight.core.auth.impl.AuthenticationServiceBean.accessResource(AuthenticationServiceBean.java:75)
at com.worklight.integration.services.impl.DataAccessServiceImpl.invokeProcedureInternal(DataAccessServiceImpl.java:408)
at com.worklight.integration.services.impl.DataAccessServiceImpl.invokeProcedure(DataAccessServiceImpl.java:115)
at com.worklight.gadgets.serving.handler.BackendQueryHandler.getContent(BackendQueryHandler.java:110)
at com.worklight.gadgets.serving.handler.BackendQueryHandler.doPost(BackendQueryHandler.java:64)
at com.worklight.gadgets.serving.GadgetAPIServlet.doGetOrPost(GadgetAPIServlet.java:144)
at com.worklight.gadgets.serving.GadgetAPIServlet.doPost(GadgetAPIServlet.java:107)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:595)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:668)
at com.ibm.ws.webcontainer.servlet.ServletWrapper.service(ServletWrapper.java:1240)
at com.ibm.ws.webcontainer.servlet.ServletWrapper.handleRequest(ServletWrapper.java:760)
at com.ibm.ws.webcontainer.servlet.ServletWrapper.handleRequest(ServletWrapper.java:443)
at com.ibm.ws.webcontainer.filter.WebAppFilterChain.invokeTarget(WebAppFilterChain.java:127)
at com.ibm.ws.webcontainer.filter.WebAppFilterChain.doFilter(WebAppFilterChain.java:88)
at com.worklight.core.auth.impl.AuthenticationFilter$1.execute(AuthenticationFilter.java:204)
at com.worklight.core.auth.impl.AuthenticationServiceBean.accessResource(AuthenticationServiceBean.java:76)
at com.worklight.core.auth.impl.AuthenticationFilter.doFilter(AuthenticationFilter.java:208)
at com.ibm.ws.webcontainer.filter.FilterInstanceWrapper.doFilter(FilterInstanceWrapper.java:194)
at com.ibm.ws.webcontainer.filter.WebAppFilterChain.doFilter(WebAppFilterChain.java:85)
at com.ibm.ws.webcontainer.filter.WebAppFilterManager.doFilter(WebAppFilterManager.java:949)
at com.ibm.ws.webcontainer.filter.WebAppFilterManager.invokeFilters(WebAppFilterManager.java:1029)
at com.ibm.ws.webcontainer.servlet.CacheServletWrapper.handleRequest(CacheServletWrapper.java:78)
at com.ibm.ws.webcontainer.WebContainer.handleRequest(WebContainer.java:885)
at com.ibm.ws.webcontainer.osgi.DynamicVirtualHost$2.run(DynamicVirtualHost.java:252)
at com.ibm.ws.http.dispatcher.internal.channel.HttpDispatcherLink$TaskWrapper.run(HttpDispatcherLink.java:584)
at com.ibm.ws.threading.internal.Worker.executeWork(Worker.java:439)
at com.ibm.ws.threading.internal.Worker.run(Worker.java:421)
at java.lang.Thread.run(Thread.java:745)
This is very normal, worklight will throw Authentication Exception every time you try to access protected resources(like invoking procedures in adapter with security test).
You can simply just ignore it.
While this is typically a benign exception, on WAS 7 it actually was causing us 500 exceptions and failures to authenticate while trying to use a custom challenge handler. To fix, we had to patch to WAS 7 FP27, and apply the setting documented above and here:
http://www-01.ibm.com/support/docview.wss?uid=swg1PM74090
ensure that a special web container flag is on:
for example: in Liberty Profile:
< webContainer com.ibm.ws.webcontainer.suppressLoggingServiceRuntimeExcep="true"/>
Related
My Setup
I am using WSO2EI version 6.4.0 to host my Rest API.
My Client --> WSO2EI --> Outside SOAP Calls
I do not have set up any mutual auth/keys etc. between WSO2EI and the outside servers.
What I am doing
When my client calls me(WSO2EI), I(WSO2EI) call other SOAP endpoints (different domains) and I(WSO2EI) am a client of these endpoints.
The Issue
A call from client(postman) --> WSO2EI --> OUT_SIDE_SOAP_END_POINT_1
whereas
another call from client(postman) --> WSO2EI --> OUT_SIDE_SOAP_END_POINT_2 does not.
However, a direct call from client(postman) --> OUT_SIDE_SOAP_END_POINT_2 works
The Exception Stack
[PassThroughMessageProcessor-1] INFO {org.apache.axis2.transport.http.HTTPSender} - Unable to sendViaPost to url[https://vsb.nrt.unabdev.sprint.com/services/CloudService]
javax.net.ssl.SSLPeerUnverifiedException: SSL peer failed hostname validation for name: null
at org.opensaml.ws.soap.client.http.TLSProtocolSocketFactory.verifyHostname(TLSProtocolSocketFactory.java:233)
at org.opensaml.ws.soap.client.http.TLSProtocolSocketFactory.createSocket(TLSProtocolSocketFactory.java:194)
at org.apache.commons.httpclient.HttpConnection.open(HttpConnection.java:707)
at org.apache.commons.httpclient.MultiThreadedHttpConnectionManager$HttpConnectionAdapter.open(MultiThreadedHttpConnectionManager.java:1361)
at org.apache.commons.httpclient.HttpMethodDirector.executeWithRetry(HttpMethodDirector.java:387)
at org.apache.commons.httpclient.HttpMethodDirector.executeMethod(HttpMethodDirector.java:171)
at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:397)
at org.apache.axis2.transport.http.AbstractHTTPSender.executeMethod(AbstractHTTPSender.java:704)
at org.apache.axis2.transport.http.HTTPSender.sendViaPost(HTTPSender.java:199)
at org.apache.axis2.transport.http.HTTPSender.send(HTTPSender.java:81)
at org.apache.axis2.transport.http.CommonsHTTPTransportSender.writeMessageWithCommons(CommonsHTTPTransportSender.java:459)
at org.apache.axis2.transport.http.CommonsHTTPTransportSender.invoke(CommonsHTTPTransportSender.java:286)
at org.apache.axis2.engine.AxisEngine.send(AxisEngine.java:442)
at org.apache.axis2.description.OutInAxisOperationClient.send(OutInAxisOperation.java:442)
at org.apache.axis2.description.OutInAxisOperationClient.executeImpl(OutInAxisOperation.java:228)
at org.apache.axis2.client.OperationClient.execute(OperationClient.java:149)
at org.apache.synapse.message.senders.blocking.BlockingMsgSender.sendReceive(BlockingMsgSender.java:493)
at org.apache.synapse.message.senders.blocking.BlockingMsgSender.send(BlockingMsgSender.java:385)
at org.apache.synapse.core.axis2.Axis2FlexibleMEPClient.send(Axis2FlexibleMEPClient.java:90)
#
at org.apache.synapse.core.axis2.Axis2Sender.sendOn(Axis2Sender.java:85)
at org.apache.synapse.core.axis2.Axis2SynapseEnvironment.send(Axis2SynapseEnvironment.java:547)
at org.apache.synapse.endpoints.AbstractEndpoint.send(AbstractEndpoint.java:384)
at org.apache.synapse.endpoints.DefaultEndpoint.send(DefaultEndpoint.java:77)
at org.apache.synapse.mediators.builtin.CallMediator.handleBlockingCall(CallMediator.java:164)
at org.apache.synapse.mediators.builtin.CallMediator.mediate(CallMediator.java:119)
at org.apache.synapse.mediators.AbstractListMediator.mediate(AbstractListMediator.java:108)
at org.apache.synapse.mediators.AbstractListMediator.mediate(AbstractListMediator.java:70)
at org.apache.synapse.mediators.template.TemplateMediator.mediate(TemplateMediator.java:104)
at org.apache.synapse.mediators.template.InvokeMediator.mediate(InvokeMediator.java:148)
at org.apache.synapse.mediators.template.InvokeMediator.mediate(InvokeMediator.java:84)
at org.apache.synapse.mediators.AbstractListMediator.mediate(AbstractListMediator.java:108)
at org.apache.synapse.mediators.AbstractListMediator.mediate(AbstractListMediator.java:70)
at org.apache.synapse.config.xml.AnonymousListMediator.mediate(AnonymousListMediator.java:37)
at org.apache.synapse.mediators.filters.FilterMediator.mediate(FilterMediator.java:203)
at org.apache.synapse.mediators.AbstractListMediator.mediate(AbstractListMediator.java:108)
at org.apache.synapse.mediators.AbstractListMediator.mediate(AbstractListMediator.java:70)
at org.apache.synapse.mediators.base.SequenceMediator.mediate(SequenceMediator.java:158)
at org.apache.synapse.mediators.base.SequenceMediator.mediate(SequenceMediator.java:214)
at org.apache.synapse.mediators.AbstractListMediator.mediate(AbstractListMediator.java:108)
at org.apache.synapse.mediators.AbstractListMediator.mediate(AbstractListMediator.java:70)
at org.apache.synapse.mediators.base.SequenceMediator.mediate(SequenceMediator.java:158)
at org.apache.synapse.rest.Resource.process(Resource.java:358)
at org.apache.synapse.rest.API.process(API.java:426)
at org.apache.synapse.rest.RESTRequestHandler.apiProcess(RESTRequestHandler.java:135)
at org.apache.synapse.rest.RESTRequestHandler.dispatchToAPI(RESTRequestHandler.java:113)
at org.apache.synapse.rest.RESTRequestHandler.process(RESTRequestHandler.java:71)
at org.apache.synapse.core.axis2.Axis2SynapseEnvironment.injectMessage(Axis2SynapseEnvironment.java:303)
at org.apache.synapse.core.axis2.SynapseMessageReceiver.receive(SynapseMessageReceiver.java:98)
at org.apache.axis2.engine.AxisEngine.receive(AxisEngine.java:180)
at org.apache.synapse.transport.passthru.ServerWorker.processNonEntityEnclosingRESTHandler(ServerWorker.java:337)
at org.apache.synapse.transport.passthru.ServerWorker.processEntityEnclosingRequest(ServerWorker.java:383)
at org.apache.synapse.transport.passthru.ServerWorker.run(ServerWorker.java:151)
at org.apache.axis2.transport.base.threads.NativeWorkerPool$1.run(NativeWorkerPool.java:172)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
What I have done and how they have faired
Setting System Property[ignoreHostnameVerification] on integrator.sh
-Dorg.wso2.ignoreHostnameVerification=true Same Exception
Setting System Property[hostnameVerifier & disableHostnameVerification] on integrator.sh
-Dhttpclient.hostnameVerifier=AllowAll \
-Dorg.opensaml.httpclient.https.disableHostnameVerification=true \
This did not work either.
Since the direct call from pos tman to OUT_SIDE_SOAP_END_POINT_2 works, I think OUT_SIDE_SOAP_END_POINT_2 is open and I should not have to do any settings on my WSO2EI instance.
Any thoughts and pointers are highly appreciated.
Thank you.
From your stacktrace, you seem to be using a Call mediator in blocking mode. There seems to an issue already reported with regards to Blocking transport. https://github.com/wso2/product-ei/issues/1501
Can you try out the workaround suggested in the issue?
As a workaround for this, we can disable switching to opensaml http
client by setting rampart.axiom.parser.pool=false in a server start
up. So removing from the backlog
The following combination worked. This allowed for the Apache HTTP client to take over from SAML. However, then I had to add the certificate into the client trust store.
-Dorg.wso2.ignoreHostnameVerification=true \
-Dorg.opensaml.httpclient.https.disableHostnameVerification=true \
This solve this particular problem.
I created a MobileFirst Adapter with security enabled. I generated token and when I try to call the API, I get 403 Forbidden error. The same works well when on localhost but gives this error when deployed on Server. I have attached the screenshot from REST Client below.
I'm using MFP 7.0.0 version
403 Error from REST Client
Log file:
[11/2/15 5:24:57:786 CST] 000049b7 com.ibm.ws.webcontainer.util.ApplicationErrorUtils E SRVE0777E: Exception thrown by application class 'org.apache.wink.server.internal.RequestProcessor.handleRequest:195'
javax.servlet.ServletException: java.lang.NoClassDefFoundError: com.sun.org.apache.xerces.internal.impl.xpath.regex.ParseException
at org.apache.wink.server.internal.RequestProcessor.handleRequest(RequestProcessor.java:195)
at org.apache.wink.server.internal.servlet.RestServlet.service(RestServlet.java:119)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:668)
at com.worklight.adapters.rest.JAXRSSandbox$2.doFilter(JAXRSSandbox.java:377)
at com.worklight.adapters.rest.FilterChainImpl.doFilter(FilterChainImpl.java:84)
at com.worklight.adapters.rest.JAXRSSandbox.handleRequest(JAXRSSandbox.java:382)
at com.worklight.adapters.rest.RESTAdaptersServiceServlet.doService(RESTAdaptersServiceServlet.java:69)
at com.worklight.adapters.rest.RESTAdaptersServlet.service(RESTAdaptersServlet.java:64)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:668)
at com.ibm.ws.webcontainer.servlet.ServletWrapper.service(ServletWrapper.java:1285)
at com.ibm.ws.webcontainer.servlet.ServletWrapper.handleRequest(ServletWrapper.java:776)
at com.ibm.ws.webcontainer.servlet.ServletWrapper.handleRequest(ServletWrapper.java:473)
at com.ibm.ws.webcontainer.filter.WebAppFilterChain.invokeTarget(WebAppFilterChain.java:135)
at com.ibm.ws.webcontainer.filter.WebAppFilterChain.doFilter(WebAppFilterChain.java:74)
at com.ibm.ws.webcontainer.filter.WebAppFilterManager.doFilter(WebAppFilterManager.java:978)
at com.ibm.ws.webcontainer.filter.WebAppFilterManager.invokeFilters(WebAppFilterManager.java:1100)
at com.ibm.ws.webcontainer.servlet.CacheServletWrapper.handleRequest(CacheServletWrapper.java:81)
at com.ibm.ws.webcontainer.WebContainer.handleRequest(WebContainer.java:912)
at com.ibm.ws.webcontainer.osgi.DynamicVirtualHost$2.run(DynamicVirtualHost.java:262)
at com.ibm.ws.http.dispatcher.internal.channel.HttpDispatcherLink$TaskWrapper.run(HttpDispatcherLink.java:955)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1157)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:627)
at java.lang.Thread.run(Thread.java:863)
Caused by: java.lang.NoClassDefFoundError: com.sun.org.apache.xerces.internal.impl.xpath.regex.ParseException
at java.lang.Class.forNameImpl(Native Method)
at java.lang.Class.forName(Class.java:253)
I have investigated this issue intensively , as our needs was to call new java adapter (JAX-RS implementation ) that is protected with #OuathSecurity via REST Clients.
But i will need to ask you few questions to give you better answer:
Is this the scenario you need ?
Did you generate token using this documentation
https://www-01.ibm.com/support/knowledgecenter/SSHS8R_7.1.0/com.ibm.worklight.dev.doc/dev/c_non_mobile_to_mobile_services.html?lang=en
Or you are using the test token end point ?
We are facing an issue on our PROD environment where it shows the following error message:
The home page shows that the runtime contains the project files:
There error on the WAS is:
[5/1/15 12:38:29:901 EDT] 0000009f ApplicationMa E
com.worklight.mgmt.impl.ApplicationManagementImpl getApplicationRuntimeInformation FWLSE0023E: application 'MobileBanking' not found, please redeploy. [project MobileBanking]
[5/1/15 12:38:29:947 EDT] 0000009f DMAdapter I com.ibm.ws.ffdc.impl.DMAdapter getAnalysisEngine FFDC1009I: Analysis Engine using data base: /wl62/profiles/node1/properties/logbr/ffdc/adv/ffdcdb.xml
[5/1/15 12:38:30:069 EDT] 0000009f FfdcProvider W com.ibm.ws.ffdc.impl.FfdcProvider logIncident FFDC1003I: FFDC Incident emitted on /wl62/profiles/node1/logs/ffdc/server11_wl_3e94673b_15.05.01_12.38.29.9336586937544274552029.txt com.ibm.ws.management.AdminServiceImpl.invoke 693
[5/1/15 12:38:30:573 EDT] 00000100 ApplicationSe E FWLSE3000E: A server error was detected.
java.lang.IllegalArgumentException: FWLSE0023E: application 'MobileBanking' not found, please redeploy. [project MobileBanking]
at com.worklight.mgmt.impl.ApplicationManagementImpl.getApplicationRuntimeInformation(ApplicationManagementImpl.java:165)
at com.worklight.core.jmx.ProjectManagementMXBeanImpl.getApplicationRuntimeInformation(ProjectManagementMXBeanImpl.java:673)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:76)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:607)
at sun.reflect.misc.Trampoline.invoke(MethodUtil.java:75)
at sun.reflect.GeneratedMethodAccessor42.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:607)
at sun.reflect.misc.MethodUtil.invoke(MethodUtil.java:279)
at com.sun.jmx.mbeanserver.ConvertingMethod.invokeWithOpenReturn(ConvertingMethod.java:193)
at com.sun.jmx.mbeanserver.ConvertingMethod.invokeWithOpenReturn(ConvertingMethod.java:175)
at com.sun.jmx.mbeanserver.MXBeanIntrospector.invokeM2(MXBeanIntrospector.java:117)
at com.sun.jmx.mbeanserver.MXBeanIntrospector.invokeM2(MXBeanIntrospector.java:54)
at com.sun.jmx.mbeanserver.MBeanIntrospector.invokeM(MBeanIntrospector.java:237)
at com.sun.jmx.mbeanserver.PerInterface.invoke(PerInterface.java:138)
at com.sun.jmx.mbeanserver.MBeanSupport.invoke(MBeanSupport.java:252)
at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:819)
at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:801)
at com.ibm.ws.management.AdminServiceImpl$1.run(AdminServiceImpl.java:1335)
at com.ibm.ws.security.util.AccessController.doPrivileged(AccessController.java:118)
at com.ibm.ws.management.AdminServiceImpl.invoke(AdminServiceImpl.java:1228)
at com.ibm.ws.management.connector.AdminServiceDelegator.invoke(AdminServiceDelegator.java:181)
at com.ibm.ws.management.connector.ipc.CallRouter.route(CallRouter.java:247)
at com.ibm.ws.management.connector.ipc.IPCConnectorInboundLink.doWork(IPCConnectorInboundLink.java:360)
at com.ibm.ws.management.connector.ipc.IPCConnectorInboundLink$IPCConnectorReadCallback.complete(IPCConnectorInboundLink.java:602)
at com.ibm.ws.ssl.channel.impl.SSLReadServiceContext$SSLReadCompletedCallback.complete(SSLReadServiceContext.java:1784)
at com.ibm.ws.tcp.channel.impl.AioReadCompletionListener.futureCompleted(AioReadCompletionListener.java:175)
at com.ibm.io.async.AbstractAsyncFuture.invokeCallback(AbstractAsyncFuture.java:217)
at com.ibm.io.async.AsyncChannelFuture.fireCompletionActions(AsyncChannelFuture.java:161)
at com.ibm.io.async.AsyncFuture.completed(AsyncFuture.java:138)
at com.ibm.io.async.ResultHandler.complete(ResultHandler.java:204)
at com.ibm.io.async.ResultHandler.runEventProcessingLoop(ResultHandler.java:775)
at com.ibm.io.async.ResultHandler$2.run(ResultHandler.java:905)
at com.ibm.ws.util.ThreadPool$Worker.run(ThreadPool.java:1862)
We have reinstalled the runtime more than once, and it says successful, we also recycled the dmgr, node, cluser, server and the runtimes and all shows green arrows with successful start up message.
Same WAR file is used on our Dev, QAT and UAT and they all running up with no issues.
Worklight Version 6.2.0.1
WAS version 8.5.5.1
Any help to resolve it, thanks.
We were able to resolve both the application issues and the Worklight service issue. There were multiple pieces that needed to be fixed. For the most part, these issues were a result of having the complexity of the how Worklight implements security. All the environment is up and running now.
Steps we followed to resolve the issue:
Make sure the exact same configuration are running on both Nodes.
Make sure that the JVM configuration are matching.
Review the security configuration on each node (SSL certificate - SLL alias and SSL keystore).
I am new to OpenAM and trying to learn by setting up an authentication solution involving a SAML2 service provider, SAML2 IdP Server, SAML2 IdP proxy.
I am able to set up a service provider, an identity provider and currently at the stage of setting up the IdP proxy "Step3: Configuring the Identity Provider Proxy (machineb)" in the guide SAMLv2 IDP Proxy Part 1. Setting up a simple Proxy scenario.
I am able to complete till "Step 3: b" and when I try "Step 3: c", I am getting the Null Pointer Exception.
My set-up is slightly different and I can map it like this:
machinea.sp.com is http://sp1.sp.com:8080 : The machine that will function as a SAML2 Service Provider (SP)
machineb.idpproxy.com is http://openam.idam.com:8080/OpenAM-11.0.0 : The machine that will work as the SAML2 IdP Proxy
machinec.idp.com is http://idp1.idp.com:8080/OpenAM-11.0.0: The machine that will assume the role of a SAML2 IdP.
Each of these are set up as a Virtual box VMs on my Mac OS X.
My circle of trust is spcot instead of cot and realm is /sprealm.
The stack trace I get on the web page after submitting the changes is:
HTTP Status 500 -
type Exception report
message
description The server encountered an internal error () that prevented it from fulfilling this request.
exception
javax.servlet.ServletException: AMSetupFilter.doFilter
com.sun.identity.setup.AMSetupFilter.doFilter(AMSetupFilter.java:134)
root cause
org.apache.jasper.JasperException: java.lang.NullPointerException
org.apache.jasper.servlet.JspServletWrapper.handleJspException(JspServletWrapper.java:549)
org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:470)
org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:390)
org.apache.jasper.servlet.JspServlet.service(JspServlet.java:334)
javax.servlet.http.HttpServlet.service(HttpServlet.java:722)
org.forgerock.openam.validation.ResponseValidationFilter.doFilter(ResponseValidationFilter.java:44)
com.sun.identity.setup.AMSetupFilter.doFilter(AMSetupFilter.java:98)
root cause
java.lang.NullPointerException
com.sun.identity.federation.cli.CreateMetaDataTemplate.buildConfigTemplate(CreateMetaDataTemplate.java:573)
com.sun.identity.federation.cli.CreateMetaDataTemplate.handleSAML2Request(CreateMetaDataTemplate.java:154)
com.sun.identity.federation.cli.CreateMetaDataTemplate.handleRequest(CreateMetaDataTemplate.java:127)
com.sun.identity.cli.SubCommand.execute(SubCommand.java:291)
com.sun.identity.cli.CLIRequest.process(CLIRequest.java:212)
com.sun.identity.cli.CLIRequest.process(CLIRequest.java:134)
com.sun.identity.cli.CommandManager.serviceRequestQueue(CommandManager.java:573)
com.sun.identity.cli.WebCLIHelper.processRequest(WebCLIHelper.java:151)
com.sun.identity.cli.WebCLIHelper.getHTML(WebCLIHelper.java:92)
org.apache.jsp.ssoadm_jsp._jspService(ssoadm_jsp.java:148)
org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70)
javax.servlet.http.HttpServlet.service(HttpServlet.java:722)
org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:432)
org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:390)
org.apache.jasper.servlet.JspServlet.service(JspServlet.java:334)
javax.servlet.http.HttpServlet.service(HttpServlet.java:722)
org.forgerock.openam.validation.ResponseValidationFilter.doFilter(ResponseValidationFilter.java:44)
com.sun.identity.setup.AMSetupFilter.doFilter(AMSetupFilter.java:98)
note The full stack trace of the root cause is available in the Apache Tomcat/7.0.26 logs.
Apache Tomcat/7.0.26
The stack-trace in catalina.out is:
org.apache.jasper.JasperException: java.lang.NullPointerException
at org.apache.jasper.servlet.JspServletWrapper.handleJspException(JspServletWrapper.java:549)
at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:470)
at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:390)
at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:334)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:722)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:305)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
at org.forgerock.openam.validation.ResponseValidationFilter.doFilter(ResponseValidationFilter.java:44)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
at com.sun.identity.setup.AMSetupFilter.doFilter(AMSetupFilter.java:98)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:224)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:169)
at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:472)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:168)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:98)
at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:927)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:407)
at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:987)
at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:579)
at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:307)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:745)
Caused by: java.lang.NullPointerException
at com.sun.identity.federation.cli.CreateMetaDataTemplate.buildConfigTemplate(CreateMetaDataTemplate.java:573)
at com.sun.identity.federation.cli.CreateMetaDataTemplate.handleSAML2Request(CreateMetaDataTemplate.java:154)
at com.sun.identity.federation.cli.CreateMetaDataTemplate.handleRequest(CreateMetaDataTemplate.java:127)
at com.sun.identity.cli.SubCommand.execute(SubCommand.java:291)
at com.sun.identity.cli.CLIRequest.process(CLIRequest.java:212)
at com.sun.identity.cli.CLIRequest.process(CLIRequest.java:134)
at com.sun.identity.cli.CommandManager.serviceRequestQueue(CommandManager.java:573)
at com.sun.identity.cli.WebCLIHelper.processRequest(WebCLIHelper.java:151)
at com.sun.identity.cli.WebCLIHelper.getHTML(WebCLIHelper.java:92)
at org.apache.jsp.ssoadm_jsp._jspService(ssoadm_jsp.java:148)
at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:722)
at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:432)
... 25 more
Please help me with this problem. Thank you.
This is due to a bug in OpenAM 11.0.0.
Upgraded to 11.0.2 and it is working fine now.
I have an application that I'm trying to migrate from seam 2.1 to 2.3, and deploy to Jboss 7.1.1. I have managed to resolve many issues that I faced while doing so. The issue that I'm here to ask about is pertaining to coexistence of seam 2.3 and the built-in Weld module in Jboss.
Are there issues with deploying a seam 2.3 application with the Weld module that's an implicit dependency in Jboss 7.1? In my jboss logs I'm seeing the following message "Starting weld service for deployment" which tells me that Weld is being triggered. This is expected according to the Jboss class loading documentation.
The reason that I'm investigating this is that although my application seems to deploy correctly, I'm getting the following exception when I try to access any of its pages:
01:36:51,605 SEVERE [javax.faces.webapp] (http--127.0.0.1-8080-5) org.jboss.weld.context.NonexistentConversationException caught during beforePhase() processing of RESTORE_VIEW 1 : UIComponent-ClientId=, Message=WELD-000321 No conversation found to restore for id 1
01:36:51,606 SEVERE [javax.faces.webapp] (http--127.0.0.1-8080-5) WELD-000321 No conversation found to restore for id 1: org.jboss.weld.context.NonexistentConversationException: WELD-000321 No conversation found to restore for id 1
at org.jboss.weld.context.AbstractConversationContext.activate(AbstractConversationContext.java:221) [weld-core-1.1.5.AS71.Final.jar:2012-02-10 15:31]
at org.jboss.weld.jsf.WeldPhaseListener.activateConversations(WeldPhaseListener.java:108) [weld-core-1.1.5.AS71.Final.jar:2012-02-10 15:31]
at org.jboss.weld.jsf.WeldPhaseListener.beforePhase(WeldPhaseListener.java:85) [weld-core-1.1.5.AS71.Final.jar:2012-02-10 15:31]
at com.sun.faces.lifecycle.Phase.handleBeforePhase(Phase.java:228) [jsf-impl-2.1.7-jbossorg-2.jar:]
at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:99) [jsf-impl-2.1.7-jbossorg-2.jar:]
at com.sun.faces.lifecycle.RestoreViewPhase.doPhase(RestoreViewPhase.java:116) [jsf-impl-2.1.7-jbossorg-2.jar:]
at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:118) [jsf-impl-2.1.7-jbossorg-2.jar:]
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:593) [jboss-jsf-api_2.1_spec-2.0.1.Final.jar:2.0.1.Final]
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:329) [jbossweb-7.0.13.Final.jar:]
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:248) [jbossweb-7.0.13.Final.jar:]
at org.apache.myfaces.webapp.filter.ExtensionsFilter.doFilter(ExtensionsFilter.java:357) [tomahawk21-1.1.14.jar:1.1.14]
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:280) [jbossweb-7.0.13.Final.jar:]
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:248) [jbossweb-7.0.13.Final.jar:]
Which makes me wonder, as to how does Weld play with seam 2.3 DI, and if that's causing the exception.
I tried a number of things to disable the JBoss module but the closest I got to doing so is by having this in my jboss-deployment-structure.xml:
<exclusions>
<module name="org.jboss.as.weld"/>
</exclusions>
That resulted in this stack trace when trying to deploy my app.
ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[default-host].[/myapp]] (MSC service thread 1-1) Error configuring application listener of class org.jboss.as.weld.webtier.jsp.JspInitializationListener: java.lang.ClassNotFoundException: org.jboss.as.weld.webtier.jsp.JspInitializationListener from [Module "deployment.myapp.ear.myapp-web.war:main" from Service Module Loader]
at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:190)
at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:468)
at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:456)
at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:398)
at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:120)
at org.jboss.as.web.deployment.WebInjectionContainer.newInstance(WebInjectionContainer.java:72) [jboss-as-web-7.1.1.Final.jar:7.1.1.Final]
at org.apache.catalina.core.StandardContext.contextListenerStart(StandardContext.java:3342) [jbossweb-7.0.13.Final.jar:]
at org.apache.catalina.core.StandardContext.start(StandardContext.java:3850) [jbossweb-7.0.13.Final.jar:]
at org.jboss.as.web.deployment.WebDeploymentService.start(WebDeploymentService.java:90) [jboss-as-web-7.1.1.Final.jar:7.1.1.Final]
at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1811)
at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1746)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_17]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_17]
at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_17]
Which indicates that some other part of Jboss, perhaps, depends on Weld for its operation.
So my other question is, what is the best way to get rid of Weld and relay on Seam's DI functionality instead?
This seems like a reasonable question to ask, that I thought it would be easy to find an answer to, but so far all my attempts at finding one have failed.
Thanks for all your help :)
It turns out that I had mistakenly added a beans.xml file to my WEB-INF/beans.xml which was causing an implicit jboss weld dependency to be added. The second issue that I think could have caused weld to be activated at deployment is a dependency on cdi-api that the jboss maven project archetype has added. I figured this out by deploying the seam 2.3 booking example and observing that weld doesn't show in the logs and comparing the poms between it and my project.