[JBoss JIRA] (WFLY-88) Recovery not fully triggered when distributed transaction falls down at prepare phase of 2PC
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-88?page=com.atlassian.jira.plugin.sy... ]
RH Bugzilla Integration commented on WFLY-88:
---------------------------------------------
Rostislav Svoboda <rsvoboda(a)redhat.com> made a comment on [bug 952746|https://bugzilla.redhat.com/show_bug.cgi?id=952746]
Jaikiran, thank you for update.
> Recovery not fully triggered when distributed transaction falls down at prepare phase of 2PC
> --------------------------------------------------------------------------------------------
>
> Key: WFLY-88
> URL: https://issues.jboss.org/browse/WFLY-88
> Project: WildFly
> Issue Type: Bug
> Components: EJB, Remoting
> Reporter: Ivo Studensky
> Assignee: jaikiran pai
> Fix For: 8.0.0.Alpha1
>
> Attachments: logs_prepareHaltClient.tgz
>
>
> It looks like recovery process is not fully triggered on a distributed transaction when the transaction falls down at prepare phase of 2PC. In the new crash recovery tests over propagated transactions only one of two servers recovers from the crash, but the other keeps an unfinished tx in its tx log.
> It corresponds to prepareHaltClient and prepareHaltServer test methods of org.jboss.as.test.jbossts.crashrec.txpropagation.TxPropagationCrashRecoveryTestCase, see JBQA-2604 for general description of the new tests. The prepareHaltClient test crashes the server which initiated the transaction, while as the prepareHaltServer test crashes the second server.
> The tests are written against EAP6.x branch, so for reproducing this it is needed a built server from the 7.1 branch of AS7.
> Steps to reproduce.
> 1. git clone -b as7 git://git.app.eng.bos.redhat.com/jbossqe/eap-tests-transactions.git
> 2. cd eap-tests-transactions
> 3. git checkout tx_propag_crashrec_tests
> 4a. mvn clean verify -Dtest=TxPropagationCrashRecoveryTestCase#prepareHaltClient -Djboss.dist=<path to jboss-as-7.1.3.Final-SNAPSHOT>
> or
> 4b. mvn clean verify -Dtest=TxPropagationCrashRecoveryTestCase#prepareHaltServer -Djboss.dist=<path to jboss-as-7.1.3.Final-SNAPSHOT>
> The logs of prepareHaltClient run attached to this jira.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 10 months
[JBoss JIRA] (WFLY-1924) An EJB on a WildFly server can't call another bean on a second server with remoting and SSL
by Bernd Koecke (JIRA)
[ https://issues.jboss.org/browse/WFLY-1924?page=com.atlassian.jira.plugin.... ]
Bernd Koecke commented on WFLY-1924:
------------------------------------
Hello Jaikiran
I did a quick check and it works! I started with an unchanged configuration and the SSL connection stopped, as expected. After setting SSL_STARTTLS to false in the options of the outbound connection, the SSL connection worked and I was able to do a call from one WildFly server to another with SSL.
Thanks a lot for your help!
Best regards
Bernd
> An EJB on a WildFly server can't call another bean on a second server with remoting and SSL
> -------------------------------------------------------------------------------------------
>
> Key: WFLY-1924
> URL: https://issues.jboss.org/browse/WFLY-1924
> Project: WildFly
> Issue Type: Bug
> Components: EJB, Remoting, Security
> Affects Versions: 8.0.0.Alpha4
> Environment: WildFly 8.0.0.Beta1-SNAPSHOT from Do 22. Aug 2013, 07:48 UTC
> on Linux with Java 1.7.0_25-b15
> Reporter: Bernd Koecke
> Assignee: jaikiran pai
> Fix For: 8.0.0.Beta1
>
>
> I configured two WildFly server, one is the service provider (server), the other one the consumer (client). An EJB on the consumer server tries to call an EJB on the provider server and the remoting connection is secured by SSL. But it doesn't work. I can see the negotiation of the cipher suites and then the communication stops. I get a
> {{javax.net.ssl.SSLException: Unrecognized SSL message, plaintext connection?}}
> on the provider side. A JavaSE client can call the service provider, but only when SSL_SARTTLS is not set. My current setup is:
> subsystem undertow, default-server:
> {code:xml}
> <https-listener name="defaults" socket-binding="https" security-realm="HttpsRealm"/>
> {code}
> subsystem ejb3:
> {code:xml}
> <remote connector-ref="https-remoting-connector" thread-pool-name="default"/>
> {code}
> Output on the service provider side when the communication stops:
> {noformat}
> [stdout] (default I/O-3) Using SSLEngineImpl.
> [stdout] (default I/O-3) Ignoring unavailable cipher suite: ...
> *** 13 lines more ***
> [stdout] (default I/O-3) Allow unsafe renegotiation: false
> [stdout] (default I/O-3) Allow legacy hello messages: true
> [stdout] (default I/O-3) Is initial handshake: true
> [stdout] (default I/O-3) Is secure renegotiation: false
> [stdout] (default I/O-3) default I/O-3, fatal error: 80: problem unwrapping net record
> [stdout] (default I/O-3) javax.net.ssl.SSLException: Unrecognized SSL message, plaintext connection?
> [stdout] (default I/O-3) default I/O-3, SEND TLSv1 ALERT: fatal, description = internal_error
> [stdout] (default I/O-3) default I/O-3, WRITE: TLSv1 Alert, length = 2
> [stdout] (default I/O-3) default I/O-3, called closeOutbound()
> [stdout] (default I/O-3) default I/O-3, closeOutboundInternal()
> [stdout] (default I/O-3) [Raw write]: length = 7
> [stdout] (default I/O-3) 0000: 15 03 01 00 02 02 50 ......P
> {noformat}
> WildFly consumer config
> subsystem remoting, outbound connections:
> {code:xml}
> <remote-outbound-connection name="provider-one-connection" outbound-socket-binding-ref="provider-ejb" security-realm="ProviderOneRealm" protocol="https-remoting">
> <properties>
> <property name="SASL_POLICY_NOANONYMOUS" value="false"/>
> </properties>
> </remote-outbound-connection>
> {code}
> The realms contain the key- and truststores and all passwords are configured.
> The reason for the communication problem comes from the following code.
> The service consumer (or client) WildFly has a remote-outbound-connection in the remoting subsystem config which results in an {{org.jboss.as.remoting.RemoteOutboundConnectionService}}. There is a {{connect()}} method which contains the lines:
> {code:java}
> OptionMap.Builder builder = OptionMap.builder();
> builder.addAll(this.connectionCreationOptions);
> builder.set(SASL_POLICY_NOANONYMOUS, Boolean.FALSE);
> builder.set(SASL_POLICY_NOPLAINTEXT, Boolean.FALSE);
> builder.set(Options.SASL_DISALLOWED_MECHANISMS, Sequence.of(JBOSS_LOCAL_USER));
> builder.set(Options.SSL_ENABLED, true);
> builder.set(Options.SSL_STARTTLS, true);
> return endpoint.connect(uri, builder.getMap(), callbackHandler, sslContext);
> {code}
> My configuration comes from {{this.connectionOptions}} and is overwritten by the defaults. The service consumer will open the connection with {{SSL_STARTTLS==true}}.
> The service provider (or server) WildFly uses an https-listener from the undertow subsystem. Which generates an {{org.wildfly.extension.undertow.HttpsListenerService}}. Method {{startListening(XnioWorker worker,...)}} has the following code:
> {code:java}
> protected void startListening(XnioWorker worker, InetSocketAddress socketAddress, ChannelListener<AcceptingChannel<StreamConnection>> acceptListener) throws IOException {
> SSLContext sslContext = securityRealm.getValue().getSSLContext();
> Builder builder = OptionMap.builder().addAll(SERVER_OPTIONS);
> builder.set(UndertowOptions.MAX_ENTITY_SIZE, maxUploadSize);
> if (securityRealm.getValue().getSupportedAuthenticationMechanisms().contains(AuthMechanism.CLIENT_CERT)) {
> builder.set(SSL_CLIENT_AUTH_MODE, REQUESTED);
> }
> builder.set(Options.USE_DIRECT_BUFFERS,true);
> OptionMap combined = builder.getMap();
> XnioSsl xnioSsl = new JsseXnioSsl(worker.getXnio(), combined, sslContext);
> sslServer = xnioSsl.createSslConnectionServer(worker, socketAddress, (ChannelListener) acceptListener, combined);
> sslServer.resumeAccepts();
> UndertowLogger.ROOT_LOGGER.listenerStarted("HTTPS", getName(), socketAddress);
> }
> {code}
> The OptionMap {{combined}} is used for the {{JsseXnioSsl}} and I can't see a way how to add my own configuration options. The result is that {{SSL_STARTTLS}} is undefined and in {{JsseXnioSsl}} has a method {{connectSsl}} which calls {{openSslConnection}}. There is an event handler build which calls:
> {code:java}
> new JsseSslStreamConnection(connection, JsseSslUtils.createSSLEngine(sslContext, optionMap, destination), socketBufferPool, applicationBufferPool, optionMap.get(Options.SSL_STARTTLS, false));
> {code}
> This sets the flag {{startTls}} of the constructor to false and the member variable {{tls}} in {{org.xnio.ssl.JsseSslStreamConnection}} to true. And when I understand it right, will then the consumer start unencrypted and will only switch to TLS when it is told todo so. But the service provider expectes, because of {{tls==true}}, an encrypted connection right from the beginning. And this generates the above error message/exception. I can reproduce this by using a JavaSE client to call the service provider. This works well when I don't set {{SSL_STARTTLS}} on the client side. But when I set it to {{true}} I get the same behavior like when the client is another WildFly instance.
> [~ctomc] said that on the consumer side in the {{connect()}} method the {{builder.addAll(...)}} should be moved to the end after setting the defaults. Thats the reason for this issue.
> With this solution I can switch off {{SSL_STARTTLS}} on the consumer(client) side.
> Another additional possibility could be to make the provider (server) side configurable that the hard coded options can be overwritten. But I don't know if this fits in the original design.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 10 months
[JBoss JIRA] (WFLY-1968) Connection factory isn't activated in generic-jms-ra.rar resource adapter after server reload with jts transactions mode set.
by Vladimir Rastseluev (JIRA)
Vladimir Rastseluev created WFLY-1968:
-----------------------------------------
Summary: Connection factory isn't activated in generic-jms-ra.rar resource adapter after server reload with jts transactions mode set.
Key: WFLY-1968
URL: https://issues.jboss.org/browse/WFLY-1968
Project: WildFly
Issue Type: Bug
Affects Versions: 8.0.0.Alpha4
Reporter: Vladimir Rastseluev
Assignee: Stefano Maestri
Description of problem:
Start server with configured resource adapter and deployed generic-jms-ra.rar. After server started we can see registered and bound connection factory.
Then we add some changes to the server to set up jts transactions mode by CLI utility. Reload the server. Connection factory isn't registered.
Version-Release number of selected component (if applicable):
EAP 6.1.1.ER4
generic resource adapter: https://github.com/jbertram/generic-jms-ra
How reproducible:
easy
Steps to Reproduce:
1. add applied generic-jms-ra.rar file to the $JBOSS_HOME/standalone/deployments directory
2. unpack applied module and add it to $JBOSS_HOME/modules directory
3. update module.xml file from org.jboss.as.ee module, adding a new dependency:
"<module name="com.tibco.tibjms"/>"
4. update $JBOSS_HOME/standalone/configuration/standalone.xml, adding global modules to <subsystem xmlns="urn:jboss:domain:ee:1.1">:
<global-modules>
<module name="com.tibco.tibjms" slot="main"/>
<module name="org.jboss.common-core" slot="main"/>
</global-modules>
5.configure resource-adapters subsystem this way:
<subsystem xmlns="urn:jboss:domain:resource-adapters:1.1">
<resource-adapters>
<resource-adapter id="generic-jms-ra.rar">
<archive>
generic-jms-ra.rar
</archive>
<transaction-support>XATransaction</transaction-support>
<connection-definitions>
<connection-definition class-name="org.jboss.resource.adapter.jms.JmsManagedConnectionFactory" jndi-name="java:/jms/QueueConnectionFactory" pool-name="CF" use-java-context="false">
<config-property name="JndiParameters">
java.naming.factory.initial=com.tibco.tibjms.naming.TibjmsInitialContextFactory;java.naming.provider.url=tcp://tibco01.mw.lab.eng.bos.redhat.com:7222
</config-property>
<config-property name="ConnectionFactory">
XAQCF
</config-property>
<security>
<application/>
</security>
<recovery>
<recover-credential>
<user-name>tibco</user-name>
<password>tibco</password>
</recover-credential>
</recovery>
</connection-definition>
</connection-definitions>
</resource-adapter>
</resource-adapters>
</subsystem>
6. run server $JBOSS_HOME/bin/standalone.sh
see - java:/jms/QueueConnectionFactory is registered
7. run $JBOSS_HOME/bin/cli.sh
8. execute commands in cli:
-->/subsystem=jacorb/:write-attribute(name=transactions,value=on)
-->/subsystem=transactions/:write-attribute(name=recovery-listener,value=true)
-->/subsystem=transactions/:write-attribute(name=jts,value=true)
-->:reload
Actual results:
connection factory java:/jms/QueueConnectionFactory isn't registered
Expected results:
connection factory java:/jms/QueueConnectionFactory is registered
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 10 months
[JBoss JIRA] (WFLY-1968) Connection factory isn't activated in generic-jms-ra.rar resource adapter after server reload with jts transactions mode set.
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-1968?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration updated WFLY-1968:
------------------------------------------
Bugzilla Update: Perform
Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=991389
> Connection factory isn't activated in generic-jms-ra.rar resource adapter after server reload with jts transactions mode set.
> ------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-1968
> URL: https://issues.jboss.org/browse/WFLY-1968
> Project: WildFly
> Issue Type: Bug
> Affects Versions: 8.0.0.Alpha4
> Reporter: Vladimir Rastseluev
> Assignee: Stefano Maestri
>
> Description of problem:
> Start server with configured resource adapter and deployed generic-jms-ra.rar. After server started we can see registered and bound connection factory.
> Then we add some changes to the server to set up jts transactions mode by CLI utility. Reload the server. Connection factory isn't registered.
> Version-Release number of selected component (if applicable):
> EAP 6.1.1.ER4
> generic resource adapter: https://github.com/jbertram/generic-jms-ra
> How reproducible:
> easy
> Steps to Reproduce:
> 1. add applied generic-jms-ra.rar file to the $JBOSS_HOME/standalone/deployments directory
> 2. unpack applied module and add it to $JBOSS_HOME/modules directory
> 3. update module.xml file from org.jboss.as.ee module, adding a new dependency:
> "<module name="com.tibco.tibjms"/>"
> 4. update $JBOSS_HOME/standalone/configuration/standalone.xml, adding global modules to <subsystem xmlns="urn:jboss:domain:ee:1.1">:
> <global-modules>
> <module name="com.tibco.tibjms" slot="main"/>
> <module name="org.jboss.common-core" slot="main"/>
> </global-modules>
> 5.configure resource-adapters subsystem this way:
> <subsystem xmlns="urn:jboss:domain:resource-adapters:1.1">
> <resource-adapters>
> <resource-adapter id="generic-jms-ra.rar">
> <archive>
> generic-jms-ra.rar
> </archive>
> <transaction-support>XATransaction</transaction-support>
> <connection-definitions>
> <connection-definition class-name="org.jboss.resource.adapter.jms.JmsManagedConnectionFactory" jndi-name="java:/jms/QueueConnectionFactory" pool-name="CF" use-java-context="false">
> <config-property name="JndiParameters">
> java.naming.factory.initial=com.tibco.tibjms.naming.TibjmsInitialContextFactory;java.naming.provider.url=tcp://tibco01.mw.lab.eng.bos.redhat.com:7222
> </config-property>
> <config-property name="ConnectionFactory">
> XAQCF
> </config-property>
> <security>
> <application/>
> </security>
> <recovery>
> <recover-credential>
> <user-name>tibco</user-name>
> <password>tibco</password>
> </recover-credential>
> </recovery>
> </connection-definition>
> </connection-definitions>
> </resource-adapter>
> </resource-adapters>
> </subsystem>
> 6. run server $JBOSS_HOME/bin/standalone.sh
> see - java:/jms/QueueConnectionFactory is registered
> 7. run $JBOSS_HOME/bin/cli.sh
> 8. execute commands in cli:
> -->/subsystem=jacorb/:write-attribute(name=transactions,value=on)
> -->/subsystem=transactions/:write-attribute(name=recovery-listener,value=true)
> -->/subsystem=transactions/:write-attribute(name=jts,value=true)
> -->:reload
> Actual results:
> connection factory java:/jms/QueueConnectionFactory isn't registered
> Expected results:
> connection factory java:/jms/QueueConnectionFactory is registered
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 10 months
[JBoss JIRA] (WFLY-1924) An EJB on a WildFly server can't call another bean on a second server with remoting and SSL
by Bernd Koecke (JIRA)
[ https://issues.jboss.org/browse/WFLY-1924?page=com.atlassian.jira.plugin.... ]
Bernd Koecke commented on WFLY-1924:
------------------------------------
Jaikiran, yes for sure, I will try it. I'm not in the office this week, but I will try to test it on my laptop.
> An EJB on a WildFly server can't call another bean on a second server with remoting and SSL
> -------------------------------------------------------------------------------------------
>
> Key: WFLY-1924
> URL: https://issues.jboss.org/browse/WFLY-1924
> Project: WildFly
> Issue Type: Bug
> Components: EJB, Remoting, Security
> Affects Versions: 8.0.0.Alpha4
> Environment: WildFly 8.0.0.Beta1-SNAPSHOT from Do 22. Aug 2013, 07:48 UTC
> on Linux with Java 1.7.0_25-b15
> Reporter: Bernd Koecke
> Assignee: jaikiran pai
> Fix For: 8.0.0.Beta1
>
>
> I configured two WildFly server, one is the service provider (server), the other one the consumer (client). An EJB on the consumer server tries to call an EJB on the provider server and the remoting connection is secured by SSL. But it doesn't work. I can see the negotiation of the cipher suites and then the communication stops. I get a
> {{javax.net.ssl.SSLException: Unrecognized SSL message, plaintext connection?}}
> on the provider side. A JavaSE client can call the service provider, but only when SSL_SARTTLS is not set. My current setup is:
> subsystem undertow, default-server:
> {code:xml}
> <https-listener name="defaults" socket-binding="https" security-realm="HttpsRealm"/>
> {code}
> subsystem ejb3:
> {code:xml}
> <remote connector-ref="https-remoting-connector" thread-pool-name="default"/>
> {code}
> Output on the service provider side when the communication stops:
> {noformat}
> [stdout] (default I/O-3) Using SSLEngineImpl.
> [stdout] (default I/O-3) Ignoring unavailable cipher suite: ...
> *** 13 lines more ***
> [stdout] (default I/O-3) Allow unsafe renegotiation: false
> [stdout] (default I/O-3) Allow legacy hello messages: true
> [stdout] (default I/O-3) Is initial handshake: true
> [stdout] (default I/O-3) Is secure renegotiation: false
> [stdout] (default I/O-3) default I/O-3, fatal error: 80: problem unwrapping net record
> [stdout] (default I/O-3) javax.net.ssl.SSLException: Unrecognized SSL message, plaintext connection?
> [stdout] (default I/O-3) default I/O-3, SEND TLSv1 ALERT: fatal, description = internal_error
> [stdout] (default I/O-3) default I/O-3, WRITE: TLSv1 Alert, length = 2
> [stdout] (default I/O-3) default I/O-3, called closeOutbound()
> [stdout] (default I/O-3) default I/O-3, closeOutboundInternal()
> [stdout] (default I/O-3) [Raw write]: length = 7
> [stdout] (default I/O-3) 0000: 15 03 01 00 02 02 50 ......P
> {noformat}
> WildFly consumer config
> subsystem remoting, outbound connections:
> {code:xml}
> <remote-outbound-connection name="provider-one-connection" outbound-socket-binding-ref="provider-ejb" security-realm="ProviderOneRealm" protocol="https-remoting">
> <properties>
> <property name="SASL_POLICY_NOANONYMOUS" value="false"/>
> </properties>
> </remote-outbound-connection>
> {code}
> The realms contain the key- and truststores and all passwords are configured.
> The reason for the communication problem comes from the following code.
> The service consumer (or client) WildFly has a remote-outbound-connection in the remoting subsystem config which results in an {{org.jboss.as.remoting.RemoteOutboundConnectionService}}. There is a {{connect()}} method which contains the lines:
> {code:java}
> OptionMap.Builder builder = OptionMap.builder();
> builder.addAll(this.connectionCreationOptions);
> builder.set(SASL_POLICY_NOANONYMOUS, Boolean.FALSE);
> builder.set(SASL_POLICY_NOPLAINTEXT, Boolean.FALSE);
> builder.set(Options.SASL_DISALLOWED_MECHANISMS, Sequence.of(JBOSS_LOCAL_USER));
> builder.set(Options.SSL_ENABLED, true);
> builder.set(Options.SSL_STARTTLS, true);
> return endpoint.connect(uri, builder.getMap(), callbackHandler, sslContext);
> {code}
> My configuration comes from {{this.connectionOptions}} and is overwritten by the defaults. The service consumer will open the connection with {{SSL_STARTTLS==true}}.
> The service provider (or server) WildFly uses an https-listener from the undertow subsystem. Which generates an {{org.wildfly.extension.undertow.HttpsListenerService}}. Method {{startListening(XnioWorker worker,...)}} has the following code:
> {code:java}
> protected void startListening(XnioWorker worker, InetSocketAddress socketAddress, ChannelListener<AcceptingChannel<StreamConnection>> acceptListener) throws IOException {
> SSLContext sslContext = securityRealm.getValue().getSSLContext();
> Builder builder = OptionMap.builder().addAll(SERVER_OPTIONS);
> builder.set(UndertowOptions.MAX_ENTITY_SIZE, maxUploadSize);
> if (securityRealm.getValue().getSupportedAuthenticationMechanisms().contains(AuthMechanism.CLIENT_CERT)) {
> builder.set(SSL_CLIENT_AUTH_MODE, REQUESTED);
> }
> builder.set(Options.USE_DIRECT_BUFFERS,true);
> OptionMap combined = builder.getMap();
> XnioSsl xnioSsl = new JsseXnioSsl(worker.getXnio(), combined, sslContext);
> sslServer = xnioSsl.createSslConnectionServer(worker, socketAddress, (ChannelListener) acceptListener, combined);
> sslServer.resumeAccepts();
> UndertowLogger.ROOT_LOGGER.listenerStarted("HTTPS", getName(), socketAddress);
> }
> {code}
> The OptionMap {{combined}} is used for the {{JsseXnioSsl}} and I can't see a way how to add my own configuration options. The result is that {{SSL_STARTTLS}} is undefined and in {{JsseXnioSsl}} has a method {{connectSsl}} which calls {{openSslConnection}}. There is an event handler build which calls:
> {code:java}
> new JsseSslStreamConnection(connection, JsseSslUtils.createSSLEngine(sslContext, optionMap, destination), socketBufferPool, applicationBufferPool, optionMap.get(Options.SSL_STARTTLS, false));
> {code}
> This sets the flag {{startTls}} of the constructor to false and the member variable {{tls}} in {{org.xnio.ssl.JsseSslStreamConnection}} to true. And when I understand it right, will then the consumer start unencrypted and will only switch to TLS when it is told todo so. But the service provider expectes, because of {{tls==true}}, an encrypted connection right from the beginning. And this generates the above error message/exception. I can reproduce this by using a JavaSE client to call the service provider. This works well when I don't set {{SSL_STARTTLS}} on the client side. But when I set it to {{true}} I get the same behavior like when the client is another WildFly instance.
> [~ctomc] said that on the consumer side in the {{connect()}} method the {{builder.addAll(...)}} should be moved to the end after setting the defaults. Thats the reason for this issue.
> With this solution I can switch off {{SSL_STARTTLS}} on the consumer(client) side.
> Another additional possibility could be to make the provider (server) side configurable that the hard coded options can be overwritten. But I don't know if this fits in the original design.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 10 months