[JBoss JIRA] (WFLY-2422) Simplify the remote-outbound connections
by jaikiran pai (JIRA)
[ https://issues.jboss.org/browse/WFLY-2422?page=com.atlassian.jira.plugin.... ]
jaikiran pai commented on WFLY-2422:
------------------------------------
David, to add a bit more context to this, this is the same requirement we discussed where the user application can just point to a logical name of outbound connection(s) group. And that group can have N number of connections which can be dynamically updated via management APIs and the user application doesn't have to be bothered to updated its deployment descriptor to take into account the new nodes that possibly get added.
IMO, this is a valid requirement.
> Simplify the remote-outbound connections
> ----------------------------------------
>
> Key: WFLY-2422
> URL: https://issues.jboss.org/browse/WFLY-2422
> Project: WildFly
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: EJB, Remoting
> Affects Versions: 8.0.0.Beta1
> Reporter: Wolf-Dieter Fink
> Assignee: David Lloyd
>
> At the moment the application need to reference each outbound connection with a remote-ejb-receiver element in the jboss-ejb-client.xml.
> But from an application perspective it is not relevant whether the server environment provide one or many receivers or whether the ejb-receiver is a cluster.
> It should be possible to add many outbound-socket-binding-ref elements and related properties to the remote-outbound-connection element of the server configuration.
> In this case it is possible to keep the application deployment independent from the server environment.
--
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, 8 months
[JBoss JIRA] (JGRP-1726) Bundler: send message batch of 1 as single message
by Bela Ban (JIRA)
Bela Ban created JGRP-1726:
------------------------------
Summary: Bundler: send message batch of 1 as single message
Key: JGRP-1726
URL: https://issues.jboss.org/browse/JGRP-1726
Project: JGroups
Issue Type: Enhancement
Reporter: Bela Ban
Assignee: Bela Ban
Fix For: 3.5
When the TransferQueueBundler ("new" / default) sends bundled messages, if there is only a single message in the list, the message is still sent as a *batch* (of 1).
Currently, parsing of single messages is done in a separate thread (JGRP-1716) whereas parsing of message batches is done in the thread which received the messages from the socket.
If we therefore send a batch of 1 as a single message, we might get better perf (to be verified).
--
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, 8 months
[JBoss JIRA] (WFLY-1816) StringIndexOutOfBoundsException in JSF web-app after commit for WFLY-476
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-1816?page=com.atlassian.jira.plugin.... ]
Stuart Douglas resolved WFLY-1816.
----------------------------------
Resolution: Cannot Reproduce Bug
We can't reproduce this, so there is not really any way for us to determine what is going on. If you can make a reproducer feel free to re-open.
> StringIndexOutOfBoundsException in JSF web-app after commit for WFLY-476
> ------------------------------------------------------------------------
>
> Key: WFLY-1816
> URL: https://issues.jboss.org/browse/WFLY-1816
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: CDI / Weld
> Affects Versions: 8.0.0.Alpha4
> Reporter: Frank Langelage
> Assignee: Stuart Douglas
>
> The commit c1959b31c0f5320d3ee7992e8a545ba497433162 breaks my web-app.
> With
> git pull && git reset --hard 861a9ceaa80274edaf32f705887f0bb38068b68d
> my web-app works fine.
> But with
> git pull && git reset --hard c1959b31c0f5320d3ee7992e8a545ba497433162
> my web-app starts, index.xhtml renders. But when clicking one of the links the navigation fails.
--
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, 8 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 RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-1924?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration updated WFLY-1924:
------------------------------------------
Bugzilla Update: Perform
Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1025319
> 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
> Security Level: Public(Everyone can see)
> 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, 8 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 RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-1924?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-1924:
-----------------------------------------------
wfink(a)redhat.com made a comment on [bug 1025319|https://bugzilla.redhat.com/show_bug.cgi?id=1025319]
If the remote-outbound-connection disable SSL or add SSL properties that might fail if there are different SSL related properties are overridden by default ones where it should be vice versa.
The analysis will be difficult as in EAP6 the failure messages are swallowed. They are only visible in org.jboss.as.ejb3 DEBUG mode.
> 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
> Security Level: Public(Everyone can see)
> 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, 8 months
[JBoss JIRA] (WFLY-2362) Support CDI interception of all EE components
by Jozef Hartinger (JIRA)
[ https://issues.jboss.org/browse/WFLY-2362?page=com.atlassian.jira.plugin.... ]
Jozef Hartinger updated WFLY-2362:
----------------------------------
Description:
As required by EE 7 Table EE.5-1.
||Component||CDI Injection||CDI Interception||
|Servlets|WFLY-2375|WFLY-2375|
|Filters|WFLY-2375|WFLY-2375|
|Listeners|WFLY-2375|WFLY-2375|
|HTTP upgrade handlers|UNDERTOW-118|UNDERTOW-118|
|tag handlers|?|?|
|tag library event listeners|?|?|
|JSF managed classes|?|?|
|JAX-WS|OK|OK|
|JAX-RS|OK|OK|
|WebSocket|WFLY-2375|WFLY-2375|
|EJB|OK|OK|
|JPA|WFLY-2387|WELD-1541|
|ManagedBeans|OK|https://github.com/wildfly/wildfly/pull/5388|
|login callback handler|?|?|
was:
As required by EE 7 Table EE.5-1.
||Component||CDI Injection||CDI Interception||
|Servlets|WFLY-2375|WFLY-2375|
|Filters|WFLY-2375|WFLY-2375|
|Listeners|WFLY-2375|WFLY-2375|
|HTTP upgrade handlers|UNDERTOW-118|UNDERTOW-118|
|tag handlers|?|?|
|tag library event listeners|?|?|
|JSF managed classes|?|?|
|JAX-WS|OK|OK|
|JAX-RS|OK|OK|
|WebSocket|WFLY-2375|WFLY-2375|
|EJB|OK|OK|
|JPA|WFLY-2387|WELD-1541|
|ManagedBeans|OK|In progress|
|login callback handler|?|?|
> Support CDI interception of all EE components
> ---------------------------------------------
>
> Key: WFLY-2362
> URL: https://issues.jboss.org/browse/WFLY-2362
> Project: WildFly
> Issue Type: Task
> Security Level: Public(Everyone can see)
> Components: CDI / Weld
> Reporter: Jozef Hartinger
> Assignee: Jozef Hartinger
> Priority: Blocker
> Fix For: 8.0.0.CR1
>
>
> As required by EE 7 Table EE.5-1.
> ||Component||CDI Injection||CDI Interception||
> |Servlets|WFLY-2375|WFLY-2375|
> |Filters|WFLY-2375|WFLY-2375|
> |Listeners|WFLY-2375|WFLY-2375|
> |HTTP upgrade handlers|UNDERTOW-118|UNDERTOW-118|
> |tag handlers|?|?|
> |tag library event listeners|?|?|
> |JSF managed classes|?|?|
> |JAX-WS|OK|OK|
> |JAX-RS|OK|OK|
> |WebSocket|WFLY-2375|WFLY-2375|
> |EJB|OK|OK|
> |JPA|WFLY-2387|WELD-1541|
> |ManagedBeans|OK|https://github.com/wildfly/wildfly/pull/5388|
> |login callback handler|?|?|
--
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, 8 months