Hi all,

we have a spring application with message-driven-channel-adapter where the JMS provider is weblogic.
The application is packaged as a jar.
There is no issue when the message-driven-channel-adapter consumes messages from weblogic using t3 protocol, we faced instead some problems using t3s.

At the beginning the JMS resource definitions were defined in the spring context file as below:

Code:
    <jee:jndi-lookup id="connectionFactory" jndi-name="WL.mb0_sb_signbook.CF" expose-access-context="true">
        <jee:environment>
            java.naming.factory.initial=weblogic.jndi.WLInitialContextFactory
            java.naming.provider.url=t3s://...:7842
            java.naming.security.principal=...
            java.naming.security.credentials=...
            weblogic.security.SSL.ignoreHostnameVerification=true
            weblogic.security.TrustKeyStore=CustomTrust
            weblogic.security.CustomTrustKeyStoreFileName=.../keystore.jks
            weblogic.security.CustomTrustKeyStoreType=JKS
        </jee:environment>
    </jee:jndi-lookup>

    <jee:jndi-lookup id="queue" jndi-name="WL.mb0_sb_signbook">
        <jee:environment>
            java.naming.factory.initial=weblogic.jndi.WLInitialContextFactory
            java.naming.provider.url=t3s://...:7842
            java.naming.security.principal=...
            java.naming.security.credentials=...
            weblogic.security.SSL.ignoreHostnameVerification=true
            weblogic.security.TrustKeyStore=CustomTrust
            weblogic.security.CustomTrustKeyStoreFileName=.../keystore.jks
            weblogic.security.CustomTrustKeyStoreType=JKS
        </jee:environment>
    </jee:jndi-lookup>
but when we run the listener from command line we got a misleading error:

Code:
19.Jun.2012 16:22:04,912 - (LISTENER SERVICE) (main) [ERROR ]- Error creating bean with name 'org.springframework.jms.listener.DefaultMessageListenerContainer#0': 
Cannot resolve reference to bean 'connectionFactory' while setting bean property 'connectionFactory'; 
nested exception is org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'connectionFactory': 
Invocation of init method failed; nested exception is javax.naming.CommunicationException [Root exception is java.net.ConnectException: 
t3s://...:7842: Destination unreachable; nested exception is:
javax.net.ssl.SSLKeyException: [Security:090542]Certificate chain received from ... was not trusted causing SSL handshake failure
...
The second step we did was removing from the spring context xml file EACH weblogic.* entry, having ONLY java.naming.* entries:

Code:
    <jee:jndi-lookup id="connectionFactory" jndi-name="WL.mb0_sb_signbook.CF" expose-access-context="true">
        <jee:environment>
            java.naming.factory.initial=weblogic.jndi.WLInitialContextFactory
            java.naming.provider.url=t3s://...:7842
            java.naming.security.principal=...
            java.naming.security.credentials=...
        </jee:environment>
    </jee:jndi-lookup>

    <jee:jndi-lookup id="queue" jndi-name="WL.mb0_sb_signbook">
        <jee:environment>
            java.naming.factory.initial=weblogic.jndi.WLInitialContextFactory
            java.naming.provider.url=t3s://...:7842
            java.naming.security.principal=...
            java.naming.security.credentials=...
        </jee:environment>
    </jee:jndi-lookup>
and we added ALL the other weblogic.* entries to our windows script for starting the spring app:

Code:
...
set SSL_FLAGS=
-Dssl.debug=true
-Dweblogic.StdoutDebugEnabled=true
-Dweblogic.security.SSL.ignoreHostnameVerification=true
-Dweblogic.security.TrustKeyStore=CustomTrust
-Dweblogic.security.CustomTrustKeyStoreType=JKS
-Dweblogic.security.CustomTrustKeyStoreFileName=C:\.....\keystore.jks

java %SSL_FLAGS% -classpath %CLASSPATH% -Dlistener.Name=LSTN %CLASSNAME%
--> and now the spring application is able to connect to WLS using t3s !

So the real issue is how to define properly within the spring context file those SSL weblogic.* entries instead to pass them directly to the JVM using -D

Did anyone get a similar problem ?

Thanks and regards
nuvola