November 2013 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-2410) composite operation containing a host op does not get rolled out to all hosts

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-2410?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-2410: ----------------------------------------------- Brian Stansberry <brian.stansberry(a)redhat.com> changed the Status of [bug 1015098|https://bugzilla.redhat.com/show_bug.cgi?id=1015098] from POST to MODIFIED > composite operation containing a host op does not get rolled out to all hosts > ----------------------------------------------------------------------------- > > Key: WFLY-2410 > URL: https://issues.jboss.org/browse/WFLY-2410 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Domain Management > Affects Versions: 8.0.0.Beta1 > Reporter: Emanuel Muckenhuber > Assignee: Emanuel Muckenhuber > Fix For: 8.0.0.CR1 > > > If a composite operation contains an operation targeting the domain as well as a single host, it will only get rolled out to the host specified rather than to the complete domain. -- 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

1
0
0 / 0

[JBoss JIRA] (WFLY-2428) MDBs should use the full identifier of the resource adapter

by Jesper Pedersen (JIRA)

[ https://issues.jboss.org/browse/WFLY-2428?page=com.atlassian.jira.plugin.... ] Jesper Pedersen reassigned WFLY-2428: ------------------------------------- Assignee: Stefano Maestri (was: Jesper Pedersen) > MDBs should use the full identifier of the resource adapter > ----------------------------------------------------------- > > Key: WFLY-2428 > URL: https://issues.jboss.org/browse/WFLY-2428 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: EJB > Affects Versions: 8.0.0.CR1 > Reporter: Jesper Pedersen > Assignee: Stefano Maestri > Fix For: 8.0.0.CR1 > > > The .rar suffix shouldn't be stripped anymore, as the resource adapters are registered under their full name. -- 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

1
0
0 / 0

[JBoss JIRA] (JBJCA-1112) @Resource injection of Datasource on clustered SFSB fails with serialization error

by Jesper Pedersen (JIRA)

[ https://issues.jboss.org/browse/JBJCA-1112?page=com.atlassian.jira.plugin... ] Jesper Pedersen moved WFLY-30 to JBJCA-1112: -------------------------------------------- Project: IronJacamar (was: WildFly) Key: JBJCA-1112 (was: WFLY-30) Workflow: classic default workflow (was: GIT Pull Request workflow ) Component/s: Deployer JDBC (was: JCA) Security: (was: Public) Fix Version/s: 1.0.22.Final 1.1.2.Final (was: 8.0.0.CR1) > @Resource injection of Datasource on clustered SFSB fails with serialization error > ---------------------------------------------------------------------------------- > > Key: JBJCA-1112 > URL: https://issues.jboss.org/browse/JBJCA-1112 > Project: IronJacamar > Issue Type: Bug > Components: Deployer, JDBC > Reporter: Paul Ferraro > Assignee: Jesper Pedersen > Priority: Critical > Fix For: 1.0.22.Final, 1.1.2.Final > > > See JBPAPP6-1762 for details. -- 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

1
0
0 / 0

[JBoss JIRA] (JBJCA-1112) DataSource marked as Serializable

by Jesper Pedersen (JIRA)

[ https://issues.jboss.org/browse/JBJCA-1112?page=com.atlassian.jira.plugin... ] Jesper Pedersen updated JBJCA-1112: ----------------------------------- Summary: DataSource marked as Serializable (was: @Resource injection of Datasource on clustered SFSB fails with serialization error) Affects Version/s: 1.1.1.Final 1.0.21.Final > DataSource marked as Serializable > --------------------------------- > > Key: JBJCA-1112 > URL: https://issues.jboss.org/browse/JBJCA-1112 > Project: IronJacamar > Issue Type: Bug > Components: Deployer, JDBC > Affects Versions: 1.0.21.Final, 1.1.1.Final > Reporter: Paul Ferraro > Assignee: Jesper Pedersen > Priority: Critical > Fix For: 1.0.22.Final, 1.1.2.Final > > > See JBPAPP6-1762 for details. -- 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

1
0
0 / 0

[JBoss JIRA] (JBJCA-1111) Throwable instantiation on TxConnectionListener.TransactionSynchronization

by Jesper Pedersen (JIRA)

[ https://issues.jboss.org/browse/JBJCA-1111?page=com.atlassian.jira.plugin... ] Jesper Pedersen closed JBJCA-1111. ---------------------------------- Resolution: Rejected http://www.ironjacamar.org/doc/userguide/1.1/en-US/html/ch14.html#ithinki... > Throwable instantiation on TxConnectionListener.TransactionSynchronization > -------------------------------------------------------------------------- > > Key: JBJCA-1111 > URL: https://issues.jboss.org/browse/JBJCA-1111 > Project: IronJacamar > Issue Type: Task > Reporter: Luis Barreiro > Assignee: Jesper Pedersen > > In org.jboss.jca.core.connectionmanager.listener.TxConnectionListener.TransactionSynchronization there is a Throwable that is always instantiated during the creation of the object, but in most cases it's never thrown. > There is a performance penalty associated with filling the stack trace of every exception, even if it's not thrown. -- 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

1
0
0 / 0

[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: ----------------------------------------------- Brian Stansberry <brian.stansberry(a)redhat.com> changed the Status of [bug 1025319|https://bugzilla.redhat.com/show_bug.cgi?id=1025319] from POST to MODIFIED > 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

1
0
0 / 0

[JBoss JIRA] (WFLY-1982) NPE in ModelControllerLock

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-1982?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-1982: ----------------------------------------------- Brian Stansberry <brian.stansberry(a)redhat.com> changed the Status of [bug 1024862|https://bugzilla.redhat.com/show_bug.cgi?id=1024862] from POST to MODIFIED > NPE in ModelControllerLock > -------------------------- > > Key: WFLY-1982 > URL: https://issues.jboss.org/browse/WFLY-1982 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Domain Management > Reporter: Brian Stansberry > Assignee: Emanuel Muckenhuber > Fix For: 8.0.0.CR1 > > > Just noticed this in the host-controller.log while looking into a non-progressing RespawnTestCase: > 22:23:50,552 ERROR [org.jboss.as.controller.management-operation] (proxy-threads - 1) JBAS014612: Operation ("register-server") failed - address: ([]): java.lang.NullPointerException > at org.jboss.as.controller.ModelControllerLock$Sync.tryAcquire(ModelControllerLock.java:75) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT] > at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireInterruptibly(AbstractQueuedSynchronizer.java:1220) [rt.jar:1.7.0_15] > at org.jboss.as.controller.ModelControllerLock.lockInterruptibly(ModelControllerLock.java:48) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT] > at org.jboss.as.controller.ModelControllerImpl.acquireLock(ModelControllerImpl.java:582) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT] > at org.jboss.as.controller.OperationContextImpl.takeWriteLock(OperationContextImpl.java:403) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT] > at org.jboss.as.controller.OperationContextImpl.acquireControllerLock(OperationContextImpl.java:700) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT] > at org.jboss.as.host.controller.mgmt.ServerToHostProtocolHandler$ServerReconnectRequestHandler$1$1.execute(ServerToHostProtocolHandler.java:268) > at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:610) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT] > at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:488) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT] > at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:277) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT] > at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:272) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT] > at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:257) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT] > at org.jboss.as.controller.AbstractControllerService.internalExecute(AbstractControllerService.java:292) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT] > at org.jboss.as.host.controller.DomainModelControllerService.access$600(DomainModelControllerService.java:148) > at org.jboss.as.host.controller.DomainModelControllerService$InternalExecutor.execute(DomainModelControllerService.java:899) > at org.jboss.as.host.controller.mgmt.ServerToHostProtocolHandler$ServerReconnectRequestHandler$1.execute(ServerToHostProtocolHandler.java:282) > 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_15] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_15] > at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_15] > at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.0.Final.jar:2.1.0.Final] -- 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

1
0
0 / 0

[JBoss JIRA] (WFLY-2425) Use forked version of slf4j to fix concurrency issue with static binding

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-2425?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-2425: ----------------------------------------------- Brian Stansberry <brian.stansberry(a)redhat.com> changed the Status of [bug 1011821|https://bugzilla.redhat.com/show_bug.cgi?id=1011821] from POST to MODIFIED > Use forked version of slf4j to fix concurrency issue with static binding > ------------------------------------------------------------------------ > > Key: WFLY-2425 > URL: https://issues.jboss.org/browse/WFLY-2425 > Project: WildFly > Issue Type: Component Upgrade > Security Level: Public(Everyone can see) > Components: Logging > Reporter: James Perkins > Assignee: James Perkins > Priority: Minor > > The slf4j-api static binding is not thread safe. A fork of slf4j-api was needed for EAP so we might as well patch WildFly too. The slf4j bugzilla is http://bugzilla.slf4j.org/show_bug.cgi?id=176. The patch used in the fork is attached to the bz. -- 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

1
0
0 / 0

[JBoss JIRA] (WFLY-2352) Domain controller fails to restart due to an inconsistent rollback of a redeploy

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-2352?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-2352: ----------------------------------------------- Brian Stansberry <brian.stansberry(a)redhat.com> changed the Status of [bug 1021763|https://bugzilla.redhat.com/show_bug.cgi?id=1021763] from POST to MODIFIED > Domain controller fails to restart due to an inconsistent rollback of a redeploy > -------------------------------------------------------------------------------- > > Key: WFLY-2352 > URL: https://issues.jboss.org/browse/WFLY-2352 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Domain Management > Affects Versions: 8.0.0.Alpha4 > Reporter: Osamu Nagano > Assignee: Brian Stansberry > > When you try to redeploy (or deploy with --force option) the same application which has the same contents hash, and a necessary dependency like a datasource beeing injected in the application is lost by some reason, the redeploy operation will delete the contents under $JBOSS_HOME/domain/data/content directory but won't delete entries in domain.xml. Then the domain controller fails to start up because no contents found in the directory. This likely happens when you frequently changes settings during other servers shutting down. > The domain controller fails to restart with the following log messages. > {code} > 12:04:10,623 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) JBAS014613: Operation ("add") failed - address: ([("deployment" => "exampleapp.war")]) - failure description: "JBAS010876: No deployment content with hash c1306bc4855f4ed9914c9616f2b999c5c62a79d3 is available in the deployment content repository for deployment 'exampleapp.war'. This is a fatal boot error. To correct the problem, either restart with the --admin-only switch set and use the CLI to install the missing content or remove it from the configuration, or remove the deployment from the xml configuraiton file and restart." > 12:04:10,628 FATAL [org.jboss.as.host.controller] (Controller Boot Thread) JBAS010933: Host Controller boot has failed in an unrecoverable manner; exiting. See previous messages for details. > {code} > The domain controller should be independent from such a server specific issue and there should be a way to fix this via CLI or Console, not by a manual editing of domain.xml. -- 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

1
0
0 / 0

[JBoss JIRA] (WFLY-2421) PatchInfoUnitTestCase should be skipped in case that patching module is not enabled

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-2421?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-2421: ----------------------------------------------- Brian Stansberry <brian.stansberry(a)redhat.com> changed the Status of [bug 1020315|https://bugzilla.redhat.com/show_bug.cgi?id=1020315] from POST to MODIFIED > PatchInfoUnitTestCase should be skipped in case that patching module is not enabled > ------------------------------------------------------------------------------------ > > Key: WFLY-2421 > URL: https://issues.jboss.org/browse/WFLY-2421 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Patching > Reporter: Jan Martiska > Assignee: Jan Martiska > Fix For: 8.0.0.CR1 > > > PatchInfoUnitTestCase should be skipped (rather than report a fail) in case that patching module is not enabled. -- 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

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira November 2013