[JBoss JIRA] (WFLY-687) .deployed sticks around
by Emanuel Muckenhuber (JIRA)
[ https://issues.jboss.org/browse/WFLY-687?page=com.atlassian.jira.plugin.s... ]
Emanuel Muckenhuber resolved WFLY-687.
--------------------------------------
Assignee: Emanuel Muckenhuber
Fix Version/s: (was: Awaiting Volunteers)
Resolution: Out of Date
This does not seem to be relevant any longer.
> .deployed sticks around
> -----------------------
>
> Key: WFLY-687
> URL: https://issues.jboss.org/browse/WFLY-687
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Domain Management
> Reporter: Jesper Pedersen
> Assignee: Emanuel Muckenhuber
>
> Steps:
> 1) cp successful.rar /path/to/jbossas7/standalone/deployments
> 2) touch /path/to/jbossas7/standalone/deployments/successful.rar.dodeploy
> .rar deploys with issues => .deployed
> 3) Ctrl+C
> The .deployed file is still there
--
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
11 years, 2 months
[JBoss JIRA] (WFLY-1939) Can not *switch* from an attribute to an alternative
by Emanuel Muckenhuber (JIRA)
[ https://issues.jboss.org/browse/WFLY-1939?page=com.atlassian.jira.plugin.... ]
Emanuel Muckenhuber resolved WFLY-1939.
---------------------------------------
Assignee: Emanuel Muckenhuber (was: Brian Stansberry)
Resolution: Out of Date
This seems to be resolved in upstream.
> Can not *switch* from an attribute to an alternative
> ----------------------------------------------------
>
> Key: WFLY-1939
> URL: https://issues.jboss.org/browse/WFLY-1939
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Domain Management
> Affects Versions: 8.0.0.Alpha4
> Reporter: Jeff Mesnil
> Assignee: Emanuel Muckenhuber
>
> use case:
> a resource defines 2 attributes that are alternative of each other. Only 1 attribute can be defined for the resource. The write attribute (and undefine) handler ensures that the model respects this constraint.
> The user wants to *switch* to an attribute A to its alternative B using the CLI.
> I proposed to use the batch command to create a composite operation which:
> 1. undefine the attribute A
> 2. write the attribute value for B
> I was expecting this to succeeds but it fails.
> For example, the htt-interface resource defines 2 attributes interface and socket-binding that are alternatives and checks this constraint in org.jboss.as.server.operations.HttpManagementWriteAttributeHandler#execute
> by adding a operation handler during the MODEL stage.
> If I run a batch, it fails:
> {noformat}
> [standalone@localhost:9990 / #] list-batch
> #1 /core-service=management/management-interface=http-interface:undefine-attribute(name=socket-binding)
> #2 /core-service=management/management-interface=http-interface:write-attribute(name=interface, value=management)
> [standalone@localhost:9990 / #] run-batch
> Failed to perform operation: java.util.concurrent.ExecutionException: Operation failed
> {noformat}
> On the server side:
> {noformat}
> 11:14:58,763 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-1) MSC000001: Failed to start service jboss."remoting ".remoting-http-upgrade-service.http-management: org.jboss.msc.service.StartException in service jboss."remoting ".remoting-http-upgrade-service.http-management: Failed to start service
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1900) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_21]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_21]
> at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_21]
> Caused by: java.lang.NullPointerException
> at org.jboss.as.remoting.RemotingHttpUpgradeService.start(RemotingHttpUpgradeService.java:107)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1944) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1877) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
> ... 3 more
> 11:14:58,763 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 4) JBAS014612: Operation ("write-attribute") failed - address: ([
> ("core-service" => "management"),
> ("management-interface" => "http-interface")
> ]): java.util.concurrent.CancellationException: JBAS014770: Service install was cancelled
> at org.jboss.as.controller.OperationContextImpl$ContextServiceBuilder.install(OperationContextImpl.java:1362) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> at org.jboss.as.server.operations.HttpManagementAddHandler.installHttpManagementConnector(HttpManagementAddHandler.java:257) [wildfly-server-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> at org.jboss.as.server.operations.HttpManagementWriteAttributeHandler.updateHttpManagementService(HttpManagementWriteAttributeHandler.java:106) [wildfly-server-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> at org.jboss.as.server.operations.HttpManagementWriteAttributeHandler.applyUpdateToRuntime(HttpManagementWriteAttributeHandler.java:86) [wildfly-server-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> at org.jboss.as.controller.AbstractWriteAttributeHandler$1.execute(AbstractWriteAttributeHandler.java:101) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:608) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:486) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:275) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:270) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:251) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:138) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:205) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$300(ModelControllerClientOperationHandler.java:110) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$2.run(ModelControllerClientOperationHandler.java:157) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$2.run(ModelControllerClientOperationHandler.java:153) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.7.0_21]
> at javax.security.auth.Subject.doAs(Subject.java:415) [rt.jar:1.7.0_21]
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:153) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> at org.jboss.as.protocol.mgmt.AbstractMessageHandler$2$1.doExecute(AbstractMessageHandler.java:296) [wildfly-protocol-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:518) [wildfly-protocol-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_21]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_21]
> at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_21]
> at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.0.Final.jar:2.1.0.Final]
> 11:14:58,777 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 4) JBAS014603: caught exception attempting to revert operation undefine-attribute at address [
> ("core-service" => "management"),
> ("management-interface" => "http-interface")
> ]: org.jboss.as.controller.OperationFailedException: JBAS015819: interface is not allowed when [socket-binding, secure-socket-binding] are present [ "JBAS015819: interface is not allowed when [socket-binding, secure-socket-binding] are present" ]
> at org.jboss.as.server.operations.HttpManagementAddHandler.validateResolvedModel(HttpManagementAddHandler.java:142)
> at org.jboss.as.server.operations.HttpManagementAddHandler.installHttpManagementConnector(HttpManagementAddHandler.java:168)
> at org.jboss.as.server.operations.HttpManagementWriteAttributeHandler.updateHttpManagementService(HttpManagementWriteAttributeHandler.java:106)
> at org.jboss.as.server.operations.HttpManagementWriteAttributeHandler.revertUpdateToRuntime(HttpManagementWriteAttributeHandler.java:99)
> at org.jboss.as.server.operations.HttpManagementWriteAttributeHandler.revertUpdateToRuntime(HttpManagementWriteAttributeHandler.java:43)
> at org.jboss.as.controller.AbstractWriteAttributeHandler$1$1.handleRollback(AbstractWriteAttributeHandler.java:111) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> at org.jboss.as.controller.AbstractOperationContext$RollbackDelegatingResultHandler.handleResult(AbstractOperationContext.java:1012) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> at org.jboss.as.controller.AbstractOperationContext$Step.handleRollback(AbstractOperationContext.java:981) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> at org.jboss.as.controller.AbstractOperationContext$Step.finalizeInternal(AbstractOperationContext.java:939) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> at org.jboss.as.controller.AbstractOperationContext$Step.finalizeStep(AbstractOperationContext.java:914) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> at org.jboss.as.controller.AbstractOperationContext$Step.access$300(AbstractOperationContext.java:866) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> at org.jboss.as.controller.AbstractOperationContext.finishStep(AbstractOperationContext.java:719) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:675) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:486) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:275) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:270) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:251) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:138) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:205) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$300(ModelControllerClientOperationHandler.java:110) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$2.run(ModelControllerClientOperationHandler.java:157) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$2.run(ModelControllerClientOperationHandler.java:153) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.7.0_21]
> at javax.security.auth.Subject.doAs(Subject.java:415) [rt.jar:1.7.0_21]
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:153) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> at org.jboss.as.protocol.mgmt.AbstractMessageHandler$2$1.doExecute(AbstractMessageHandler.java:296) [wildfly-protocol-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:518) [wildfly-protocol-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_21]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_21]
> at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_21]
> at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.0.Final.jar:2.1.0.Final]
> {noformat}
--
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
11 years, 2 months
[JBoss JIRA] (JGRP-1737) TP: ignore DONT_BUNDLE flag for sending of messages
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1737?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-1737:
--------------------------------
The question is whether it makes sense to handle messages in a batch which are tagged as {{DONT_BUNDLE}} but *not* as {{OOB}}.
For example, if we have {{1 (reg) 2 (reg) 3 (reg | dont_bundle) 4 (reg) 5(reg)}}, then it doesn't make any sense to deliver 3 on its separate thread (because dont_bundle is set), as it will get delivered only *after* 1 and 2 have been delivered.
We should therefore perhaps only 'unbundle' messages marked as {{OOB | DONT_BUNDLE}}, and deliver them via the OOB thread pool (or the INTERNAL thread pool if the INTERNAL flag is also set).
> TP: ignore DONT_BUNDLE flag for sending of messages
> ---------------------------------------------------
>
> Key: JGRP-1737
> URL: https://issues.jboss.org/browse/JGRP-1737
> Project: JGroups
> Issue Type: Enhancement
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 3.5
>
>
> Currently, messages tagged with DONT_BUNDLE are sent separately, not as a message bundle through a bundler. On the receiver, they are passed up as single messages, ie. on a separate thread.
> Sending a lot of single (possibly small) messages is inefficient; it would be better to bundle *all* message on the sender side. This requires a bundler which sends single messages immediately when no other messages are available to be sent.
> SOLUTION (sender):
> * If the bundler is *not* "old", ignore the DONT_BUNDLE flag and send the message through the bundler
> * Else, same as now; send the message immediately as single message
> SOLUTION (receiver):
> * When reading the message list and creating the 4 batches (regular, oob, oob+internal, internal), if a message has DONT_BUNDLE set, pass it as single message to the corresponding thread pool and don't add it to the batch
> This has the advantage that we have a more efficient way of sending messages (as message bundles), yet the behavior (and performance) at the receiver is the same as now
--
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
11 years, 2 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:
-----------------------------------------------
Ladislav Thon <lthon(a)redhat.com> changed the Status of [bug 1025319|https://bugzilla.redhat.com/show_bug.cgi?id=1025319] from ON_QA to VERIFIED
> 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
11 years, 2 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:
-----------------------------------------------
Ladislav Thon <lthon(a)redhat.com> made a comment on [bug 1025319|https://bugzilla.redhat.com/show_bug.cgi?id=1025319]
This issue was verified using the 6.2.0.CR1 preview bits.
> 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
11 years, 2 months
[JBoss JIRA] (DROOLS-64) Traits do not comply with type inheritance on "modify"
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/DROOLS-64?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on DROOLS-64:
-----------------------------------------------
Mario Fusco <mfusco(a)redhat.com> made a comment on [bug 1029399|https://bugzilla.redhat.com/show_bug.cgi?id=1029399]
Modifying a traited object does not refresh its traits. For example, if a Person is traited as a Worker, modifying the core Person won't cause the rules for Worker to be reevaluated.
The dynamic types should be consolidated internally
Modifications should be propagated
Refraction should be used to prevent duplicate activations
> Traits do not comply with type inheritance on "modify"
> ------------------------------------------------------
>
> Key: DROOLS-64
> URL: https://issues.jboss.org/browse/DROOLS-64
> Project: Drools
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 5.5.0.Final
> Reporter: Davide Sottara
> Assignee: Mario Fusco
> Priority: Blocker
> Fix For: 5.5.1.Final, 6.0.0.CR1
>
>
> Modifying a traited object does not refresh its traits. For example, if a Person is traited as a Worker, modifying the core Person won't cause the rules for Worker to be reevaluated.
> The dynamic types should be consolidated internally
> Modifications should be propagated
> Refraction should be used to prevent duplicate activations
--
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
11 years, 2 months
[JBoss JIRA] (WFLY-959) Allow more flexibility in the way EJB authentication is handled with regards to remoting and security-realms
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFLY-959?page=com.atlassian.jira.plugin.s... ]
Darran Lofthouse commented on WFLY-959:
---------------------------------------
The design is currently being worked on - but no we don't want to automatically require two sets of credentials.
> Allow more flexibility in the way EJB authentication is handled with regards to remoting and security-realms
> ------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-959
> URL: https://issues.jboss.org/browse/WFLY-959
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: EJB
> Reporter: Derek Horton
> Assignee: David Lloyd
>
> My confusion is around the remoting/security-realm setup in the use case
> where multiple EJBs are deployed that use different security-domains and
> the EJBs will be invoked by remote standalone clients. For example,
> ejbX needs to be in the sec-domain-X security-domain, while ejbY needs to
> be in the sec-domain-Y security-domain.
> In this situation, the authentication checks are going to be handled by
> the security-realm that is associated with the remote connector that is
> configured to be used by the EJB subsystem.
> It looks like the security-realm can either handle the authentication
> checks directly (properties file, ldap, etc) or it can defer to the
> jaas security-domain. In both of those situations, it seems that the
> EJBs are limited to a single authentication point. The EJB
> authentication is either going to be handled by a single security-realm
> or the security-realm will defer to a single security-domain.
> I could configure the security-domain to have multiple login modules. I
> assume the same thing could be done with the security-realm.
> Basically the problem that I am trying to solve boils down to this: the
> authentication checks for remote EJBs appear to be checked by either a
> single security-realm or a single security-domain. Is there a way to
> change this?
> One idea I had was to add another remote connector to the EJB subsystem.
> Unfortunately, this does not appear to be possible.
--
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
11 years, 2 months