[JBoss Web Services] - JBoss WS and setting own trustmanager
by Tomasz Dźwigaj
Tomasz Dźwigaj [http://community.jboss.org/people/zlytomek] created the discussion
"JBoss WS and setting own trustmanager"
To view the discussion, visit: http://community.jboss.org/message/546832#546832
--------------------------------------------------------------
Hi.
My main goal is to have a trustmanager filled with certificates retrieved from a database for a secure WebService client connections with JBoss Ws.
I've created my own implementation of trustmanager which implements javax.net.ssl.X509TrustManager, and it's basically getting certs from a database and loads them into keystore. I'm setting it for my HTTPSConnections like this:
...
TrustManager[] myTMs = new TrustManager [] {
myTrustManager };
final SSLContext sslContext = SSLContext.getInstance( "TLS" );
sslContext.init( null, myTMs, null );
HttpsURLConnection.setDefaultSSLSocketFactory( sslContext.getSocketFactory() );
Althought it works fine (the webservice is call is made properly) at every connection it messes with my head with:
java.io.IOException: Error initializing socket factory SSL context: Can not find truststore url.
at org.jboss.remoting.security.SSLSocketBuilder.initializeSocketFactorySSLContext(SSLSocketBuilder.java:1340)
at org.jboss.remoting.security.SSLSocketBuilder.createCustomSocketFactory(SSLSocketBuilder.java:451)
at org.jboss.remoting.security.SSLSocketBuilder.createSSLSocketFactory(SSLSocketBuilder.java:431)
at org.jboss.remoting.security.SSLSocketBuilder.createSSLSocketFactory(SSLSocketBuilder.java:381)
at org.jboss.remoting.transport.http.ssl.HTTPSClientInvoker.createSocketFactory(HTTPSClientInvoker.java:140)
at org.jboss.remoting.RemoteClientInvoker.<init>(RemoteClientInvoker.java:46)
at org.jboss.remoting.transport.http.HTTPClientInvoker.<init>(HTTPClientInvoker.java:105)
at org.jboss.remoting.transport.http.ssl.HTTPSClientInvoker.<init>(HTTPSClientInvoker.java:63)
at org.jboss.remoting.transport.https.TransportClientFactory.createClientInvoker(TransportClientFactory.java:39)
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:597)
at org.jboss.remoting.InvokerRegistry.loadClientInvoker(InvokerRegistry.java:419)
at org.jboss.remoting.InvokerRegistry.createClientInvoker(InvokerRegistry.java:320)
at org.jboss.remoting.Client.connect(Client.java:459)
at org.jboss.ws.core.client.RemotingConnectionImpl.createRemotingClient(RemotingConnectionImpl.java:247)
at org.jboss.ws.core.client.RemotingConnectionImpl.invoke(RemotingConnectionImpl.java:165)
at org.jboss.ws.core.client.SOAPRemotingConnection.invoke(SOAPRemotingConnection.java:77)
at org.jboss.ws.core.CommonClient.invoke(CommonClient.java:337)
at org.jboss.ws.core.jaxws.client.ClientImpl.invoke(ClientImpl.java:243)
at org.jboss.ws.core.jaxws.client.ClientProxy.invoke(ClientProxy.java:164)
at org.jboss.ws.core.jaxws.client.ClientProxy.invoke(ClientProxy.java:150)
So i've tried to set a java system property javax.net.ssl.trustStore to an empty keystore and althought it worked fine on a windows server (the annoying exception was gone) on a linux server, after setting this property this empty keystore was used as a truststore which only gave me another nightmane - what if in other part of code of large application i'm dealing with - somebody is setting this property for his reasons?
Maybe anyone found some solution for this problem?
I'm using I'm using Jboss 4.2.2
Regards
zlytomek
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/546832#546832]
Start a new discussion in JBoss Web Services at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
15 years, 10 months
Re: [jboss-user] [JBoss Microcontainer Development] - Wildcard support in Dynamic-imports
by Adrian Brock
Adrian Brock [http://community.jboss.org/people/warjort] replied to the discussion
"Wildcard support in Dynamic-imports"
To view the discussion, visit: http://community.jboss.org/message/546816#546816
--------------------------------------------------------------
Looks kind of ok. But...
1) You should use the delegate you just created NOT the module.
The operations on the module don't respect export restrictions, they can see private stuff.
Like I said before, you shouldn't be using those module operations. They are for debug purposes on the management console.
i.e. the request starts from that module which is not the case here.
You want the operation to go through the delegate to the other policy with whatever export/import restrictions apply.
*protected* DelegateLoader resolve(String pckg)
{
Requirement requirement = *new* PackageRequirement(pckg, range);
// TODO -- add this DI to module? new DI impl to remove delegate from policy when resolved module goes away?
RequirementDependencyItem item = *new* RequirementDependencyItem(module, requirement, module.getClassLoaderState(), ControllerState.INSTALLED);
*if* (item.resolve(controller))
{
ClassLoaderPolicy policy = getPolicy();
// TODO -- add delegate to policy
return delegate;
}
*return* null;
}
2) I think you should return null for failures, I didn't check but I remember trying to write the internal handling of "not found" to not throw
ClassNotFoundExceptions all over the place. Throwing the RuntimeException would likely mean it doesn't go onto the next delegate?
3) You don't show how you are handling the undeploy of the dynamically resolved module when it is not shutdownPolicy=GarbageCollection.
It will move your ClassLoaderPolicy back to DESCRIBED since one of the dependencies has been removed. But I think you should also
remove the dynamic wildcard dependency items you will be adding in the first TODO shown above.
For shutdownPolicy=GarbageCollection you still need to do something in the Module to make the refreshPackages() stuff work properly.
For the GC policy used by OSGi, the dependsOnMe are tracked inside the Module rather than the DependencyInfo.
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/546816#546816]
Start a new discussion in JBoss Microcontainer Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
15 years, 10 months