I have created sample sso wso2 program with help of existing code which I have downloaded from wso2 website and follow the same steps. But when I am executing my programm I am getting error
SEVERE: Exception starting filter SSOFilter
java.lang.NullPointerException at
org.wso2.carbon.identity.sso.agent.util.SSOAgentConfigs.isSAMLSSOLoginEnabled(SSOAgentConfigs.java:345)
at
org.wso2.carbon.identity.sso.agent.util.SSOAgentConfigs.initCheck(SSOAgentConfigs.java:222)
at
org.wso2.carbon.identity.sso.agent.SSOAgentFilter.init(SSOAgentFilter.java:53)
at
org.apache.catalina.core.ApplicationFilterConfig.initFilter(ApplicationFilterConfig.java:279)
at
org.apache.catalina.core.ApplicationFilterConfig.getFilter(ApplicationFilterConfig.java:260)
at
org.apache.catalina.core.ApplicationFilterConfig.(ApplicationFilterConfig.java:105)
at
org.apache.catalina.core.StandardContext.filterStart(StandardContext.java:4854)
at
org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5546)
at
org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
at
org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1575)
at
org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1565)
at java.util.concurrent.FutureTask.run(FutureTask.java:262) at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Thre
As per the source I referred, there isn't way of throwing NPE from that line since it have following code,
public static boolean isSAMLSSOLoginEnabled() {
return samlSSOLoginEnabled;
}
And I found this matching lines in older v1.2.0 of org.wso2.carbon.identity.sso.agent component [1].
So in order to resolve the issue, you need to find the correct source of the relevant jar, debug the flow and need to check exactly which variable it use a null reference to access something.
If you find difficulty finding a source of a relevant component, raise a separate question mentioning the versions you are looking for.
[1] https://svn.wso2.org/repos/wso2/carbon/platform/branches/turing/components/identity/org.wso2.carbon.identity.sso.agent/1.2.0/src/main/java/org/wso2/carbon/identity/sso/agent/util/SSOAgentConfigs.java
HTH,
DarRay
Related
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.
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'm currently working on WSO2 DSS 3.5.0, trying to follow this example:
https://itsmeisuru.wordpress.com/2013/11/29/wso2-dss-scheduled-task-example/
I've created the JAR file of a simple java class that implement "DataTask".
It put this JAR in the repository DSS_HOME/repository/components/lib like it's said in step 2 of the example.
Then, when I create the schedule task like in the step 6.
I have the following error in my server console:
INFO {org.quartz.core.JobRunShell} - Job
TENANT_-1234_TYPE_DATA_SERVICE_TASK.ScheduleTest threw a
JobExecutionException: org.quartz.JobExecutionException: Error in
executing task: Error in initializing Data Task: sample.Test cannot be
found by org.wso2.carbon.dataservices.task_4.3.4 [See nested
exception: java.lang.RuntimeException: Error in initializing Data
Task: sample.Test cannot be found by
org.wso2.carbon.dataservices.task_4.3.4] at
org.wso2.carbon.ntask.core.impl.TaskQuartzJobAdapter.execute(TaskQuartzJobAdapter.java:74)
at org.quartz.core.JobRunShell.run(JobRunShell.java:213) at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.run(FutureTask.java:266) 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) Caused by:
java.lang.RuntimeException: Error in initializing Data Task:
sample.Test cannot be found by org.wso2.carbon.dataservices.task_4.3.4
at
org.wso2.carbon.dataservices.task.DSTaskExt.init(DSTaskExt.java:42)
at
org.wso2.carbon.ntask.core.impl.TaskQuartzJobAdapter.execute(TaskQuartzJobAdapter.java:66)
... 6 more Caused by: java.lang.ClassNotFoundException: sample.Test
cannot be found by org.wso2.carbon.dataservices.task_4.3.4 at
org.eclipse.osgi.internal.loader.BundleLoader.findClassInternal(BundleLoader.java:501)
at
org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:421)
at
org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:412)
at
org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.loadClass(DefaultClassLoader.java:107)
at java.lang.ClassLoader.loadClass(ClassLoader.java:357) at
java.lang.Class.forName0(Native Method) at
java.lang.Class.forName(Class.java:264) at
org.wso2.carbon.dataservices.task.DSTaskExt.init(DSTaskExt.java:36)
... 7 more
Note that my package name is "sample" and the name of my java class is "Test".
It looks like the scheduled task doesn't retrieve the class I indicate in the field "DataService Task Class".
Has anybody already had the same problem?
I also tried to used the JAR generated in the example as it's provided in the step 2. Then I follow the very same other steps. Finally I have the same problem:
[classpath] cannot be found by org.wso2.carbon.dataservices.task_4.3.4
This is a known issue in DSS 3.5.0. The related JIRA can be found from here. This is fixed and the fix will be available in the upcoming release 3.5.1. The planned date for the 3.5.1 release is mid of July 2016. Please note that this can be changed due to certain circumstances.
i was actual trying this tutorial: http://wso2.com/library/tutorials/2012/12/providing-xacml-fine-grained-authorization-webapps/
on the authentication with admin:admin on localhost:9763/Entitlement_Sample_WebApp/protected.jsp i encountered an error:
exception
org.wso2.carbon.identity.entitlement.filter.exception.EntitlementFilterException: Exception while making the decision : java.lang.NullPointerException
org.wso2.carbon.identity.entitlement.filter.EntitlementFilter.doFilter(EntitlementFilter.java:191)
My WSO2 IS PDP receives the request and responds also correctly with a XACML Response : Permit
so where could be the problem ??
thank you
The problem caused by an error of EntitlementFilter, so I could solve this by correcting the source file EntitlementFilter.java (line 191)
like below:
simpleDecision = decisionElement.getFirstChildWithName(new QName("Result")).getFirstChildWithName(new QName("Decision")).getText();
rewrite it:
simpleDecision = decisionElement.getFirstChildWithName(new QName(“urn:oasis:names:tc:xacml:3.0:core:schema:wd-17″,”Result”)).
getFirstChildWithName(new QName(“urn:oasis:names:tc:xacml:3.0:core:schema:wd-17″,”Decision”)).getText();
It ommitted namespace in QName method
The detail is here (https://nparkstar.wordpress.com/2015/01/27/wso2-as-sample-authorization-%EC%98%A4%EB%A5%98-%EC%88%98%EC%A0%95/).
Sorry, it is written in Korean, but I wish it could helpful.
It could be anywhere starting from this line : pepProxy.getDecision(userName, resource, action, env)
It could be in your pepProxy code, where they are getting back the result, or might be in the other lines after this call in that try catch.
One thing is sure PDP is not at all culprit.
Please paste your full exception here if you want to know precise problem + Solution.
:)
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.