From issues at jboss.org  Sat Mar  1 03:49:48 2014
From: issues at jboss.org (John O'Hara (JIRA))
Date: Sat, 1 Mar 2014 03:49:48 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JBWEB-290) Optimize string literals
 inside jsp expressions
In-Reply-To: <JIRA.12533522.1393516764000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12533522.1393516764000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12533522.1393516764000.30748.1393663788129@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JBWEB-290?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12949174#comment-12949174 ] 

John O'Hara commented on JBWEB-290:
-----------------------------------

Thinking about this in more generalized terms, it occurs when the string concat operator + is used within expressions.  When parsing the jsp page, if we can remove string literals from inside expressions and treat them as standard TemplateText nodes in the parser, we can eliminate string concatenation within expressions and corresponding pressure placed on the heap by StringBuilder
                
> Optimize string literals inside jsp expressions 
> ------------------------------------------------
>
>                 Key: JBWEB-290
>                 URL: https://issues.jboss.org/browse/JBWEB-290
>             Project: JBoss Web
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Tomcat
>    Affects Versions: JBossWeb-3.0.0.Final
>            Reporter: John O'Hara
>            Assignee: Remy Maucherat
>
> After setting genStringAsCharArray=true, we continue to see StringBuilder concatenating string literals for each jsp request for some of our jsp pages; instead of creating a static char[].
> This occurs when a string literal is included in a jsp expression, e.g.;
> <%="<INPUT type=\"hidden\" name=\"name\" value=\"" + obj.getName() + "\">"%>
> Is it possible to identify string literals inside expressions during the tokenization phase of parsing jsp pages in apache jasper and treat them as text nodes so that the apache jasper generator can apply the same optimizations as string literals outside the jsp expression?

--
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

From issues at jboss.org  Sat Mar  1 04:47:48 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Sat, 1 Mar 2014 04:47:48 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1271) Infinispan remote-store
 requires remote-servers but not marked as required in mgmt model
In-Reply-To: <JIRA.12490391.1366787482000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12490391.1366787482000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12490391.1366787482000.30754.1393667268046@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1271?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12949175#comment-12949175 ] 

RH Bugzilla Integration commented on WFLY-1271:
-----------------------------------------------

Kabir Khan <kkhan at redhat.com> changed the Status of [bug 956904|https://bugzilla.redhat.com/show_bug.cgi?id=956904] from POST to MODIFIED
                
> Infinispan remote-store requires remote-servers but not marked as required in mgmt model
> ----------------------------------------------------------------------------------------
>
>                 Key: WFLY-1271
>                 URL: https://issues.jboss.org/browse/WFLY-1271
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Clustering
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Takayoshi Kimura
>            Assignee: Richard Achmatowicz
>             Fix For: 8.0.0.CR1
>
>
> Affect version is actually 8.0.0.Alpha1-SNAPSHOT (before 8.0.0.Alpha1, we don't have such selection).
> Command remote-store=REMOTE_STORE:add fails with this exception:
> {quote}
> 15:58:05,112 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 3) JBAS014607: Failed to persist configuration change: org.jboss.as.controller.persistence.ConfigurationPersistenceException: JBAS014675: Failed to marshal configuration
> 	at org.jboss.as.controller.persistence.AbstractFilePersistenceResource.<init>(AbstractFilePersistenceResource.java:50) [jboss-as-controller-8.0.0.Alpha1-SNAPSHOT.jar:8.0.0.Alpha1-SNAPSHOT]
> 	at org.jboss.as.controller.persistence.ConfigurationFilePersistenceResource.<init>(ConfigurationFilePersistenceResource.java:45) [jboss-as-controller-8.0.0.Alpha1-SNAPSHOT.jar:8.0.0.Alpha1-SNAPSHOT]
> 	at org.jboss.as.controller.persistence.BackupXmlConfigurationPersister.store(BackupXmlConfigurationPersister.java:80) [jboss-as-controller-8.0.0.Alpha1-SNAPSHOT.jar:8.0.0.Alpha1-SNAPSHOT]
> 	at org.jboss.as.controller.ModelControllerImpl.writeModel(ModelControllerImpl.java:522) [jboss-as-controller-8.0.0.Alpha1-SNAPSHOT.jar:8.0.0.Alpha1-SNAPSHOT]
> 	at org.jboss.as.controller.OperationContextImpl.createPersistenceResource(OperationContextImpl.java:178) [jboss-as-controller-8.0.0.Alpha1-SNAPSHOT.jar:8.0.0.Alpha1-SNAPSHOT]
> 	at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:359) [jboss-as-controller-8.0.0.Alpha1-SNAPSHOT.jar:8.0.0.Alpha1-SNAPSHOT]
> 	at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:228) [jboss-as-controller-8.0.0.Alpha1-SNAPSHOT.jar:8.0.0.Alpha1-SNAPSHOT]
> 	at org.jboss.as.controller.AbstractOperationContext.finishStep(AbstractOperationContext.java:513) [jboss-as-controller-8.0.0.Alpha1-SNAPSHOT.jar:8.0.0.Alpha1-SNAPSHOT]
> 	at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:499) [jboss-as-controller-8.0.0.Alpha1-SNAPSHOT.jar:8.0.0.Alpha1-SNAPSHOT]
> 	at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:321) [jboss-as-controller-8.0.0.Alpha1-SNAPSHOT.jar:8.0.0.Alpha1-SNAPSHOT]
> 	at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:228) [jboss-as-controller-8.0.0.Alpha1-SNAPSHOT.jar:8.0.0.Alpha1-SNAPSHOT]
> 	at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:223) [jboss-as-controller-8.0.0.Alpha1-SNAPSHOT.jar:8.0.0.Alpha1-SNAPSHOT]
> 	at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:235) [jboss-as-controller-8.0.0.Alpha1-SNAPSHOT.jar:8.0.0.Alpha1-SNAPSHOT]
> 	at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:124) [jboss-as-controller-8.0.0.Alpha1-SNAPSHOT.jar:8.0.0.Alpha1-SNAPSHOT]
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:148) [jboss-as-controller-8.0.0.Alpha1-SNAPSHOT.jar:8.0.0.Alpha1-SNAPSHOT]
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$300(ModelControllerClientOperationHandler.java:97) [jboss-as-controller-8.0.0.Alpha1-SNAPSHOT.jar:8.0.0.Alpha1-SNAPSHOT]
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:114) [jboss-as-controller-8.0.0.Alpha1-SNAPSHOT.jar:8.0.0.Alpha1-SNAPSHOT]
> 	at org.jboss.as.protocol.mgmt.AbstractMessageHandler$2$1.doExecute(AbstractMessageHandler.java:296) [jboss-as-protocol-8.0.0.Alpha1-SNAPSHOT.jar:8.0.0.Alpha1-SNAPSHOT]
> 	at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:518) [jboss-as-protocol-8.0.0.Alpha1-SNAPSHOT.jar:8.0.0.Alpha1-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]
> Caused by: org.jboss.as.controller.persistence.ConfigurationPersistenceException: JBAS014680: Failed to write configuration
> 	at org.jboss.as.controller.persistence.AbstractConfigurationPersister.marshallAsXml(AbstractConfigurationPersister.java:123) [jboss-as-controller-8.0.0.Alpha1-SNAPSHOT.jar:8.0.0.Alpha1-SNAPSHOT]
> 	at org.jboss.as.controller.persistence.AbstractFilePersistenceResource.<init>(AbstractFilePersistenceResource.java:43) [jboss-as-controller-8.0.0.Alpha1-SNAPSHOT.jar:8.0.0.Alpha1-SNAPSHOT]
> 	... 22 more
> Caused by: java.lang.IllegalArgumentException
> 	at org.jboss.dmr.ModelValue.asList(ModelValue.java:128) [jboss-dmr-1.1.6.Final.jar:1.1.6.Final]
> 	at org.jboss.dmr.ModelNode.asList(ModelNode.java:1205) [jboss-dmr-1.1.6.Final.jar:1.1.6.Final]
> 	at org.jboss.as.clustering.infinispan.subsystem.InfinispanSubsystemXMLWriter.processCommonCacheAttributesElements(InfinispanSubsystemXMLWriter.java:282)
> 	at org.jboss.as.clustering.infinispan.subsystem.InfinispanSubsystemXMLWriter.writeContent(InfinispanSubsystemXMLWriter.java:124)
> 	at org.jboss.as.clustering.infinispan.subsystem.InfinispanSubsystemXMLWriter.writeContent(InfinispanSubsystemXMLWriter.java:42)
> 	at org.jboss.as.server.parsing.StandaloneXml.writeServerProfile(StandaloneXml.java:1191) [jboss-as-server-8.0.0.Alpha1-SNAPSHOT.jar:8.0.0.Alpha1-SNAPSHOT]
> 	at org.jboss.as.server.parsing.StandaloneXml.writeContent(StandaloneXml.java:1108) [jboss-as-server-8.0.0.Alpha1-SNAPSHOT.jar:8.0.0.Alpha1-SNAPSHOT]
> 	at org.jboss.as.server.parsing.StandaloneXml.writeContent(StandaloneXml.java:103) [jboss-as-server-8.0.0.Alpha1-SNAPSHOT.jar:8.0.0.Alpha1-SNAPSHOT]
> 	at org.jboss.staxmapper.XMLMapperImpl.doDeparse(XMLMapperImpl.java:88) [staxmapper-1.1.0.Final.jar:1.1.0.Final]
> 	at org.jboss.staxmapper.XMLMapperImpl.deparseDocument(XMLMapperImpl.java:83) [staxmapper-1.1.0.Final.jar:1.1.0.Final]
> 	at org.jboss.as.controller.persistence.AbstractConfigurationPersister.marshallAsXml(AbstractConfigurationPersister.java:117) [jboss-as-controller-8.0.0.Alpha1-SNAPSHOT.jar:8.0.0.Alpha1-SNAPSHOT]
> 	... 23 more
> {quote}
> Reproduce steps:
> {quote}
> [standalone at localhost:9999 /] /subsystem=infinispan/cache-container=web/replicated-cache=repl/file-store=FILE_STORE:remove
> {
>     "outcome" => "success",
>     "response-headers" => {
>         "operation-requires-reload" => true,
>         "process-state" => "reload-required"
>     }
> }
> [standalone at localhost:9999 /] /subsystem=infinispan/cache-container=web/replicated-cache=repl/remote-store=REMOTE_STORE:add
> {
>     "outcome" => "failed",
>     "failure-description" => "JBAS014677: Failed to persist configuration change: JBAS014675: Failed to marshal configuration",
>     "rolled-back" => true,
>     "response-headers" => {"process-state" => "reload-required"}
> }
> [standalone at localhost:9999 /] /subsystem=infinispan/cache-container=web/replicated-cache=repl/remote-store=REMOTE_STORE:add(remote-servers=[])
> {
>     "outcome" => "success",
>     "response-headers" => {"process-state" => "reload-required"}
> }
> {quote}
> In $JBOSS_HOME/docs/schema/jboss-as-infinispan_1_3.xsd, it looks like the remote-server is required as it's defined as minOccurs="1":
> {quote}
> <xs:element name="remote-server" type="tns:remote-server" minOccurs="1" maxOccurs="unbounded"/>
> {quote}

--
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

From issues at jboss.org  Sat Mar  1 07:55:47 2014
From: issues at jboss.org (Stan Silvert (JIRA))
Date: Sat, 1 Mar 2014 07:55:47 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3044) Mojarra's @ViewScoped
 implementation is not cluster-aware resulting in NotSerializableException
In-Reply-To: <JIRA.12533615.1393599715000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12533615.1393599715000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12533615.1393599715000.30771.1393678547678@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-3044?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stan Silvert reassigned WFLY-3044:
----------------------------------

    Assignee: Farah Juma  (was: Stan Silvert)

    
> Mojarra's @ViewScoped implementation is not cluster-aware resulting in NotSerializableException
> -----------------------------------------------------------------------------------------------
>
>                 Key: WFLY-3044
>                 URL: https://issues.jboss.org/browse/WFLY-3044
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JSF
>    Affects Versions: 8.0.0.Final
>            Reporter: Radoslav Husar
>            Assignee: Farah Juma
>            Priority: Critical
>             Fix For: 8.0.1.Final
>
>
> The problem is in ViewScopeContextManager, namely 
> {code}
>             getContextMap(facesContext).put(contextual, new ViewScopeContextObject(contextual, creational, name));
> {code}
> probably it needs an artificial ID generated to serve as a key.
> Also the ViewScopeContextObject needs to be serializable as well among other things
> {code}
> class ViewScopeContextObject {
> {code}
> Issue manifests as
> {noformat}[Server:server-one] 19:22:41,564 ERROR [org.infinispan.interceptors.InvocationContextInterceptor] (default task-15) ISPN000136: Execution error: org.infinispan.commons.CacheException: java.lang.RuntimeException: Failure to marshal argument(s)  
> [Server:server-one] at org.infinispan.commons.util.Util.rewrapAsCacheException(Util.java:581)  
> ...  
> [Server:server-one] at org.infinispan.transaction.tm.DummyTransaction.notifyAfterCompletion(DummyTransaction.java:263)  
> [Server:server-one] at org.infinispan.transaction.tm.DummyTransaction.runCommitTx(DummyTransaction.java:312)  
> [Server:server-one] at org.infinispan.transaction.tm.DummyTransaction.commit(DummyTransaction.java:69)  
> [Server:server-one] at org.infinispan.transaction.tm.DummyBaseTransactionManager.commit(DummyBaseTransactionManager.java:80)  
> [Server:server-one] at org.infinispan.batch.BatchContainer.resolveTransaction(BatchContainer.java:101)  
> [Server:server-one] at org.infinispan.batch.BatchContainer.endBatch(BatchContainer.java:83)  
> [Server:server-one] at org.infinispan.batch.BatchContainer.endBatch(BatchContainer.java:64)  
> [Server:server-one] at org.infinispan.CacheImpl.endBatch(CacheImpl.java:777)  
> [Server:server-one] at org.infinispan.AbstractDelegatingCache.endBatch(AbstractDelegatingCache.java:53)  
> [Server:server-one] at org.wildfly.clustering.web.infinispan.InfinispanBatcher$1.end(InfinispanBatcher.java:56)  
> [Server:server-one] at org.wildfly.clustering.web.infinispan.InfinispanBatcher$1.close(InfinispanBatcher.java:46)  
> [Server:server-one] at org.wildfly.clustering.web.undertow.session.DistributableSession.requestDone(DistributableSession.java:72)  
> [Server:server-one] at io.undertow.servlet.spec.ServletContextImpl.updateSessionAccessTime(ServletContextImpl.java:704) [undertow-servlet-1.0.0.Final.jar:1.0.0.Final]  
> [Server:server-one] at io.undertow.servlet.spec.HttpServletResponseImpl.responseDone(HttpServletResponseImpl.java:522) [undertow-servlet-1.0.0.Final.jar:1.0.0.Final]  
> [Server:server-one] at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:287) [undertow-servlet-1.0.0.Final.jar:1.0.0.Final]  
> [Server:server-one] at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:227) [undertow-servlet-1.0.0.Final.jar:1.0.0.Final]  
> [Server:server-one] at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:73) [undertow-servlet-1.0.0.Final.jar:1.0.0.Final]  
> [Server:server-one] at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:146) [undertow-servlet-1.0.0.Final.jar:1.0.0.Final]  
> [Server:server-one] at io.undertow.server.Connectors.executeRootHandler(Connectors.java:168) [undertow-core-1.0.0.Final.jar:1.0.0.Final]  
> [Server:server-one] at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:687) [undertow-core-1.0.0.Final.jar:1.0.0.Final]  
> [Server:server-one] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_51]  
> [Server:server-one] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_51]  
> [Server:server-one] at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_51]  
> [Server:server-one] Caused by: java.lang.RuntimeException: Failure to marshal argument(s)  
> [Server:server-one] at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.marshallCall(CommandAwareRpcDispatcher.java:333)  
> [Server:server-one] at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.processSingleCall(CommandAwareRpcDispatcher.java:352)  
> [Server:server-one] at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.invokeRemoteCommand(CommandAwareRpcDispatcher.java:167)  
> [Server:server-one] ... 76 more  
> [Server:server-one] Caused by: org.infinispan.commons.marshall.NotSerializableException: org.jboss.weld.bean.ManagedBean  
> [Server:server-one] Caused by: an exception which occurred:  
> [Server:server-one] in object java.util.HashMap at b37422bb  
> [Server:server-one] in object org.jboss.as.clustering.marshalling.SimpleMarshalledValue at b37422bb  
> [Server:server-one] in object org.infinispan.commands.write.PutKeyValueCommand at db517a36  
> [Server:server-one] in object org.infinispan.commands.tx.PrepareCommand at 6fa34718  
> {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

From issues at jboss.org  Sat Mar  1 12:33:47 2014
From: issues at jboss.org (David Lloyd (JIRA))
Date: Sat, 1 Mar 2014 12:33:47 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1568) Cannot reliably reinstall
 service with same name
In-Reply-To: <JIRA.12494816.1371799050000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12494816.1371799050000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12494816.1371799050000.30797.1393695227692@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-1568?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

David Lloyd resolved WFLY-1568.
-------------------------------

    Fix Version/s:     (was: 9.0.0.CR1)
       Resolution: Rejected


Actually it is theoretically possible for the CPU to schedule all actions for a REMOVE before the install runs.  But in the real world, yes, this code construct will probably never work.  A service can presently only be replaced by employing a service listener, unfortunately.  A simpler service replacement API is something we can look into for MSC 2 though.
                
> Cannot reliably reinstall service with same name
> ------------------------------------------------
>
>                 Key: WFLY-1568
>                 URL: https://issues.jboss.org/browse/WFLY-1568
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: MSC
>            Reporter: Thomas Diesler
>            Assignee: David Lloyd
>
> There seems to be an undefined "cleanup period" needed, before a service with the same name can be installed successfully. If you do the below in the same thread it will always fail (I believe). 
> {code}
> controller.setMode(Mode.REMOVE)
> serviceTarget.addService(controller.getName(), service).install()
> {code}

--
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

From issues at jboss.org  Sat Mar  1 18:07:47 2014
From: issues at jboss.org (=?UTF-8?Q?Thomas_Fr=C3=BChbeck_=28JIRA=29?=)
Date: Sat, 1 Mar 2014 18:07:47 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3001) JSF WindowId: NPE in Weld
 HTTP BeanStore inhibits application access
In-Reply-To: <JIRA.12533035.1393184294000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12533035.1393184294000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12533035.1393184294000.30803.1393715267658@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-3001?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12949185#comment-12949185 ] 

Thomas Fr?hbeck commented on WFLY-3001:
---------------------------------------

could not reproduce it in Wildfly 8.0.0.Final, please close issue.
Regards,
Thomas
                
> JSF WindowId: NPE in Weld HTTP BeanStore inhibits application access 
> ---------------------------------------------------------------------
>
>                 Key: WFLY-3001
>                 URL: https://issues.jboss.org/browse/WFLY-3001
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: CDI / Weld, JSF
>    Affects Versions: 8.0.0.CR1
>            Reporter: Thomas Fr?hbeck
>            Assignee: Stuart Douglas
>              Labels: cdi, npe, session, weld
>
> Web session has been established, after _very_ long time (>> session timeout) browser refresh, URL refresh leads to NPE in weld beanstore on access to SessionScoped deltaspike DefaultClientWindowConfig bean.
> From that point on the _only_ possibility to access the application is clean of session cookies.
> Stacktrace:
> 2014-02-23 16:59:13,319 ERROR [io.undertow.request] (default task-36) Servlet request failed HttpServerExchange{ GET /mssms2/faces/csms/groupManagement.xhtml}: java.lang.NullPoi
> nterException
>         at org.jboss.weld.context.beanstore.http.AbstractSessionBeanStore.getLockStore(AbstractSessionBeanStore.java:113) [weld-core-impl-2.1.0.CR1.jar:2013-09-26 16:53]
>         at org.jboss.weld.context.beanstore.AttributeBeanStore.lock(AttributeBeanStore.java:210) [weld-core-impl-2.1.0.CR1.jar:2013-09-26 16:53]
>         at org.jboss.weld.context.AbstractContext.get(AbstractContext.java:88) [weld-core-impl-2.1.0.CR1.jar:2013-09-26 16:53]
>         at org.jboss.weld.context.PassivatingContextWrapper$AbstractPassivatingContextWrapper.get(PassivatingContextWrapper.java:76) [weld-core-impl-2.1.0.CR1.jar:2013-09-26 16:
> 53]
>         at org.jboss.weld.bean.proxy.ContextBeanInstance.getInstance(ContextBeanInstance.java:98) [weld-core-impl-2.1.0.CR1.jar:2013-09-26 16:53]
>         at org.jboss.weld.bean.proxy.ProxyMethodHandler.invoke(ProxyMethodHandler.java:78) [weld-core-impl-2.1.0.CR1.jar:2013-09-26 16:53]
>         at org.apache.deltaspike.jsf.spi.scope.window.DefaultClientWindowConfig$Proxy$_$$_WeldClientProxy.getClientWindowRenderMode(Unknown Source) [deltaspike-jsf-module-api-0.
> 6-SNAPSHOT.jar:0.6-SNAPSHOT]
>         at org.apache.deltaspike.jsf.impl.scope.window.DefaultClientWindow.getWindowId(DefaultClientWindow.java:119) [deltaspike-jsf-module-impl-0.6-SNAPSHOT.jar:0.6-SNAPSHOT]
>         at org.apache.deltaspike.jsf.impl.scope.window.DefaultClientWindow$Proxy$_$$_WeldClientProxy.getWindowId(Unknown Source) [deltaspike-jsf-module-impl-0.6-SNAPSHOT.jar:0.6
> -SNAPSHOT]
>         at org.apache.deltaspike.jsf.impl.listener.request.DeltaSpikeLifecycleWrapper.execute(DeltaSpikeLifecycleWrapper.java:78) [deltaspike-jsf-module-impl-0.6-SNAPSHOT.jar:0.
> 6-SNAPSHOT]

--
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


From issues at jboss.org  Sat Mar  1 19:07:48 2014
From: issues at jboss.org (Tomaz Cerar (JIRA))
Date: Sat, 1 Mar 2014 19:07:48 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3001) JSF WindowId: NPE in Weld
 HTTP BeanStore inhibits application access
In-Reply-To: <JIRA.12533035.1393184294000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12533035.1393184294000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12533035.1393184294000.30808.1393718868301@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-3001?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tomaz Cerar resolved WFLY-3001.
-------------------------------

    Fix Version/s: 8.0.0.Final
       Resolution: Done

    
> JSF WindowId: NPE in Weld HTTP BeanStore inhibits application access 
> ---------------------------------------------------------------------
>
>                 Key: WFLY-3001
>                 URL: https://issues.jboss.org/browse/WFLY-3001
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: CDI / Weld, JSF
>    Affects Versions: 8.0.0.CR1
>            Reporter: Thomas Fr?hbeck
>            Assignee: Stuart Douglas
>              Labels: cdi, npe, session, weld
>             Fix For: 8.0.0.Final
>
>
> Web session has been established, after _very_ long time (>> session timeout) browser refresh, URL refresh leads to NPE in weld beanstore on access to SessionScoped deltaspike DefaultClientWindowConfig bean.
> From that point on the _only_ possibility to access the application is clean of session cookies.
> Stacktrace:
> 2014-02-23 16:59:13,319 ERROR [io.undertow.request] (default task-36) Servlet request failed HttpServerExchange{ GET /mssms2/faces/csms/groupManagement.xhtml}: java.lang.NullPoi
> nterException
>         at org.jboss.weld.context.beanstore.http.AbstractSessionBeanStore.getLockStore(AbstractSessionBeanStore.java:113) [weld-core-impl-2.1.0.CR1.jar:2013-09-26 16:53]
>         at org.jboss.weld.context.beanstore.AttributeBeanStore.lock(AttributeBeanStore.java:210) [weld-core-impl-2.1.0.CR1.jar:2013-09-26 16:53]
>         at org.jboss.weld.context.AbstractContext.get(AbstractContext.java:88) [weld-core-impl-2.1.0.CR1.jar:2013-09-26 16:53]
>         at org.jboss.weld.context.PassivatingContextWrapper$AbstractPassivatingContextWrapper.get(PassivatingContextWrapper.java:76) [weld-core-impl-2.1.0.CR1.jar:2013-09-26 16:
> 53]
>         at org.jboss.weld.bean.proxy.ContextBeanInstance.getInstance(ContextBeanInstance.java:98) [weld-core-impl-2.1.0.CR1.jar:2013-09-26 16:53]
>         at org.jboss.weld.bean.proxy.ProxyMethodHandler.invoke(ProxyMethodHandler.java:78) [weld-core-impl-2.1.0.CR1.jar:2013-09-26 16:53]
>         at org.apache.deltaspike.jsf.spi.scope.window.DefaultClientWindowConfig$Proxy$_$$_WeldClientProxy.getClientWindowRenderMode(Unknown Source) [deltaspike-jsf-module-api-0.
> 6-SNAPSHOT.jar:0.6-SNAPSHOT]
>         at org.apache.deltaspike.jsf.impl.scope.window.DefaultClientWindow.getWindowId(DefaultClientWindow.java:119) [deltaspike-jsf-module-impl-0.6-SNAPSHOT.jar:0.6-SNAPSHOT]
>         at org.apache.deltaspike.jsf.impl.scope.window.DefaultClientWindow$Proxy$_$$_WeldClientProxy.getWindowId(Unknown Source) [deltaspike-jsf-module-impl-0.6-SNAPSHOT.jar:0.6
> -SNAPSHOT]
>         at org.apache.deltaspike.jsf.impl.listener.request.DeltaSpikeLifecycleWrapper.execute(DeltaSpikeLifecycleWrapper.java:78) [deltaspike-jsf-module-impl-0.6-SNAPSHOT.jar:0.
> 6-SNAPSHOT]

--
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


From issues at jboss.org  Sun Mar  2 08:26:47 2014
From: issues at jboss.org (roy mizrachi (JIRA))
Date: Sun, 2 Mar 2014 08:26:47 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3050) '=' character removed from
	request cookie
In-Reply-To: <JIRA.12533682.1393766769608@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12533682.1393766769608@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12533682.1393766769608.30834.1393766807703@jira02.app.mwc.hst.phx2.redhat.com>

roy mizrachi created WFLY-3050:
----------------------------------

             Summary: '=' character removed from request cookie 
                 Key: WFLY-3050
                 URL: https://issues.jboss.org/browse/WFLY-3050
             Project: WildFly
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Web (Undertow)
    Affects Versions: 8.0.0.Final
         Environment: windows 7
            Reporter: roy mizrachi
            Assignee: Stuart Douglas


I'm saving encrypted user token in session cookie:
Cookie: JCORESESSIONID=aes256$/tew4VVsfdJ32iUX1AOqBGRb717TJC9KkejjAPl6BIAG6kCP4beSraL51eQG2iu5bV9uT3OsubXUcjO+sG2lYNWbu5NliQd361oUz2Yl4LQ=

The problem is that in the server i see that the '=' character is removed hence i cannot decrypt it.

 

--
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

From issues at jboss.org  Sun Mar  2 14:54:47 2014
From: issues at jboss.org (Davide Sottara (JIRA))
Date: Sun, 2 Mar 2014 14:54:47 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-446) Literals may be ambiguously
 resolved as classes on case insensitive filesystems
In-Reply-To: <JIRA.12533712.1393789987954@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12533712.1393789987954@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12533712.1393789987954.30939.1393790087556@jira02.app.mwc.hst.phx2.redhat.com>

Davide Sottara created DROOLS-446:
-------------------------------------

             Summary: Literals may be ambiguously resolved as classes on case insensitive filesystems
                 Key: DROOLS-446
                 URL: https://issues.jboss.org/browse/DROOLS-446
             Project: Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions: 6.0.1.Final, 6.0.0.Final, 5.6.0.Final, 5.5.0.Final
            Reporter: Davide Sottara
            Assignee: Mark Proctor
             Fix For: 6.1.0.CR1


When a candidate class literal is analyzed, e.g. : 
{code}
declare Foo
  f1 : Bar = new Bar()
  f2 : boolean = false 
end
{code}

"Bar" is tentatively resolved (twice) and its f.q.n. is substituted as needed.
However, even "false" is tentatively resolved as well.

On a case insensitive filesytems, the presence of a class named False will cause the literal to be resolved erroneously.
The same will happen to "true" and "null"

--
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

From issues at jboss.org  Sun Mar  2 16:44:49 2014
From: issues at jboss.org (Stuart Douglas (JIRA))
Date: Sun, 2 Mar 2014 16:44:49 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3050) '=' character removed from
	request cookie
In-Reply-To: <JIRA.12533682.1393766769000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12533682.1393766769000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12533682.1393766769000.30970.1393796689048@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-3050?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12949203#comment-12949203 ] 

Stuart Douglas commented on WFLY-3050:
--------------------------------------

This related to UNDERTOW-49, it looks like we missed adding a configuration option for this to Wildfly. 
                
> '=' character removed from request cookie 
> ------------------------------------------
>
>                 Key: WFLY-3050
>                 URL: https://issues.jboss.org/browse/WFLY-3050
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web (Undertow)
>    Affects Versions: 8.0.0.Final
>         Environment: windows 7
>            Reporter: roy mizrachi
>            Assignee: Stuart Douglas
>
> I'm saving encrypted user token in session cookie:
> Cookie: JCORESESSIONID=aes256$/tew4VVsfdJ32iUX1AOqBGRb717TJC9KkejjAPl6BIAG6kCP4beSraL51eQG2iu5bV9uT3OsubXUcjO+sG2lYNWbu5NliQd361oUz2Yl4LQ=
> The problem is that in the server i see that the '=' character is removed hence i cannot decrypt it.
>  

--
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

From issues at jboss.org  Sun Mar  2 16:46:49 2014
From: issues at jboss.org (Stuart Douglas (JIRA))
Date: Sun, 2 Mar 2014 16:46:49 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3033) Better SSO configuration
In-Reply-To: <JIRA.12533478.1393493687000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12533478.1393493687000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12533478.1393493687000.30991.1393796809269@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-3033?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stuart Douglas reassigned WFLY-3033:
------------------------------------

    Assignee: Tomaz Cerar  (was: Stuart Douglas)

    
> Better SSO configuration
> ------------------------
>
>                 Key: WFLY-3033
>                 URL: https://issues.jboss.org/browse/WFLY-3033
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Web (Undertow)
>    Affects Versions: 8.0.0.Final
>            Reporter: Tin Tvrtkovic
>            Assignee: Tomaz Cerar
>            Priority: Critical
>              Labels: single-sign-on, undertow
>             Fix For: 8.0.1.Final
>
>
> When enabling Undertow SSO in standalone.xml, the only option to tweak is the cookie domain.
> My life would be made easier by two changes:
> 1) If the domain is not specified, the SSO cookie should have no domain set. This will make the browser apply the domain from the URL being requested. Currently the cookie domain gets populated with a value from the enclosing XML element.
> 2) There's no way of setting the cookie path, which makes this less useful for services on different URLs. I propose adding a path attribute to the SSO XML element, which would set the cookie path. For example:
> <single-sign-on path="/" />
> Right now my workaround is to use my reverse proxy (Apache) to edit response headers and modify the cookie, removing the domain and adding the path. If anyone else needs the workaround:
> Header edit Set-Cookie "^JSESSIONIDSSO=([^; ]+).+" "JSESSIONIDSSO=$1; path=/"

--
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

From issues at jboss.org  Sun Mar  2 17:52:47 2014
From: issues at jboss.org (James Livingston (JIRA))
Date: Sun, 2 Mar 2014 17:52:47 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (LOGMGR-99) Infinite recursion when
 exception stack frame class lookup fails
In-Reply-To: <JIRA.12533713.1393800685435@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12533713.1393800685435@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12533713.1393800685435.31020.1393800767638@jira02.app.mwc.hst.phx2.redhat.com>

James Livingston created LOGMGR-99:
--------------------------------------

             Summary: Infinite recursion when exception stack frame class lookup fails
                 Key: LOGMGR-99
                 URL: https://issues.jboss.org/browse/LOGMGR-99
             Project: JBoss Log Manager
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions: 1.5.1.Final
            Reporter: James Livingston
            Assignee: David Lloyd
            Priority: Critical


To print out the jar information in exception stack traces, the log manager needs to resolve the class name from StackTraceElement to the Class object. Since the log manager cannot know which classloader was used, guessClass() tries the TCCL, the logmanager's classloader and finally the system classloader.

It is possible that the TCCL contains a class of the same name as the one in the stack frame, but it not the same class. This can easily happen if the application packages a jar that is also used by the container. In this situation, the class may not be able to be loaded, such as if the application-packages class is missing it's dependencies.

If Class.forName() would throw a NoClassDefFoundError or similar, JBoss Modules (or other classloader implementation) may attempt to log this using java.util.logging API. This can result in infinite recursion, for example

       ...
       at org.jboss.logmanager.Logger.log(Logger.java:367)
       at org.jboss.modules.log.JDKModuleLogger.doLog(JDKModuleLogger.java:109)
       at org.jboss.modules.log.JDKModuleLogger.classDefineFailed(JDKModuleLogger.java:194)
       at org.jboss.modules.ModuleClassLoader.defineClass(ModuleClassLoader.java:401)
       at org.jboss.modules.ModuleClassLoader.loadClassLocal(ModuleClassLoader.java:243)
       at org.jboss.modules.ModuleClassLoader$1.loadClassLocal(ModuleClassLoader.java:73)
       at org.jboss.modules.Module.loadModuleClass(Module.java:527)
       at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:182)
       at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:468)
       at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:456)
       at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:398)
       at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:120)
       at java.lang.Class.forName0(Native Method)
       at java.lang.Class.forName(Class.java:266)
       at org.jboss.logmanager.formatters.Formatters$12.guessClass(Formatters.java:578)
       at org.jboss.logmanager.formatters.Formatters$12.renderExtended(Formatters.java:421)
       at org.jboss.logmanager.formatters.Formatters$12.renderRaw(Formatters.java:388)
       at org.jboss.logmanager.formatters.Formatters$JustifyingFormatStep.render(Formatters.java:150)
       at org.jboss.logmanager.formatters.MultistepFormatter.format(MultistepFormatter.java:86)
       at org.jboss.logmanager.ExtFormatter.format(ExtFormatter.java:35)
       at org.jboss.logmanager.handlers.WriterHandler.doPublish(WriterHandler.java:49)
       at org.jboss.logmanager.ExtHandler.publish(ExtHandler.java:76)
       at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:290)
       at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:298)
       at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:298)
       at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:298)
       at org.jboss.logmanager.Logger.logRaw(Logger.java:721)
       at org.jboss.logmanager.Logger.logRaw(Logger.java:731)
       at org.jboss.logmanager.Logger.log(Logger.java:367)
       ...

--
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

From issues at jboss.org  Sun Mar  2 17:52:47 2014
From: issues at jboss.org (James Livingston (JIRA))
Date: Sun, 2 Mar 2014 17:52:47 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (LOGMGR-99) Infinite recursion when
 exception stack frame class lookup fails
In-Reply-To: <JIRA.12533713.1393800685000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12533713.1393800685000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12533713.1393800685000.31022.1393800767776@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/LOGMGR-99?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

James Livingston updated LOGMGR-99:
-----------------------------------

        Workaround Description: Use %e in the formatter rather than %E

    
> Infinite recursion when exception stack frame class lookup fails
> ----------------------------------------------------------------
>
>                 Key: LOGMGR-99
>                 URL: https://issues.jboss.org/browse/LOGMGR-99
>             Project: JBoss Log Manager
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 1.5.1.Final
>            Reporter: James Livingston
>            Assignee: David Lloyd
>            Priority: Critical
>
> To print out the jar information in exception stack traces, the log manager needs to resolve the class name from StackTraceElement to the Class object. Since the log manager cannot know which classloader was used, guessClass() tries the TCCL, the logmanager's classloader and finally the system classloader.
> It is possible that the TCCL contains a class of the same name as the one in the stack frame, but it not the same class. This can easily happen if the application packages a jar that is also used by the container. In this situation, the class may not be able to be loaded, such as if the application-packages class is missing it's dependencies.
> If Class.forName() would throw a NoClassDefFoundError or similar, JBoss Modules (or other classloader implementation) may attempt to log this using java.util.logging API. This can result in infinite recursion, for example
>        ...
>        at org.jboss.logmanager.Logger.log(Logger.java:367)
>        at org.jboss.modules.log.JDKModuleLogger.doLog(JDKModuleLogger.java:109)
>        at org.jboss.modules.log.JDKModuleLogger.classDefineFailed(JDKModuleLogger.java:194)
>        at org.jboss.modules.ModuleClassLoader.defineClass(ModuleClassLoader.java:401)
>        at org.jboss.modules.ModuleClassLoader.loadClassLocal(ModuleClassLoader.java:243)
>        at org.jboss.modules.ModuleClassLoader$1.loadClassLocal(ModuleClassLoader.java:73)
>        at org.jboss.modules.Module.loadModuleClass(Module.java:527)
>        at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:182)
>        at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:468)
>        at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:456)
>        at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:398)
>        at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:120)
>        at java.lang.Class.forName0(Native Method)
>        at java.lang.Class.forName(Class.java:266)
>        at org.jboss.logmanager.formatters.Formatters$12.guessClass(Formatters.java:578)
>        at org.jboss.logmanager.formatters.Formatters$12.renderExtended(Formatters.java:421)
>        at org.jboss.logmanager.formatters.Formatters$12.renderRaw(Formatters.java:388)
>        at org.jboss.logmanager.formatters.Formatters$JustifyingFormatStep.render(Formatters.java:150)
>        at org.jboss.logmanager.formatters.MultistepFormatter.format(MultistepFormatter.java:86)
>        at org.jboss.logmanager.ExtFormatter.format(ExtFormatter.java:35)
>        at org.jboss.logmanager.handlers.WriterHandler.doPublish(WriterHandler.java:49)
>        at org.jboss.logmanager.ExtHandler.publish(ExtHandler.java:76)
>        at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:290)
>        at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:298)
>        at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:298)
>        at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:298)
>        at org.jboss.logmanager.Logger.logRaw(Logger.java:721)
>        at org.jboss.logmanager.Logger.logRaw(Logger.java:731)
>        at org.jboss.logmanager.Logger.log(Logger.java:367)
>        ...

--
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

From issues at jboss.org  Sun Mar  2 18:32:47 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Sun, 2 Mar 2014 18:32:47 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (LOGMGR-99) Infinite recursion when
 exception stack frame class lookup fails
In-Reply-To: <JIRA.12533713.1393800685000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12533713.1393800685000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12533713.1393800685000.31047.1393803167605@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/LOGMGR-99?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated LOGMGR-99:
------------------------------------------

        Bugzilla Update: Perform
    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1071695

    
> Infinite recursion when exception stack frame class lookup fails
> ----------------------------------------------------------------
>
>                 Key: LOGMGR-99
>                 URL: https://issues.jboss.org/browse/LOGMGR-99
>             Project: JBoss Log Manager
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 1.5.1.Final
>            Reporter: James Livingston
>            Assignee: David Lloyd
>            Priority: Critical
>
> To print out the jar information in exception stack traces, the log manager needs to resolve the class name from StackTraceElement to the Class object. Since the log manager cannot know which classloader was used, guessClass() tries the TCCL, the logmanager's classloader and finally the system classloader.
> It is possible that the TCCL contains a class of the same name as the one in the stack frame, but it not the same class. This can easily happen if the application packages a jar that is also used by the container. In this situation, the class may not be able to be loaded, such as if the application-packages class is missing it's dependencies.
> If Class.forName() would throw a NoClassDefFoundError or similar, JBoss Modules (or other classloader implementation) may attempt to log this using java.util.logging API. This can result in infinite recursion, for example
>        ...
>        at org.jboss.logmanager.Logger.log(Logger.java:367)
>        at org.jboss.modules.log.JDKModuleLogger.doLog(JDKModuleLogger.java:109)
>        at org.jboss.modules.log.JDKModuleLogger.classDefineFailed(JDKModuleLogger.java:194)
>        at org.jboss.modules.ModuleClassLoader.defineClass(ModuleClassLoader.java:401)
>        at org.jboss.modules.ModuleClassLoader.loadClassLocal(ModuleClassLoader.java:243)
>        at org.jboss.modules.ModuleClassLoader$1.loadClassLocal(ModuleClassLoader.java:73)
>        at org.jboss.modules.Module.loadModuleClass(Module.java:527)
>        at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:182)
>        at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:468)
>        at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:456)
>        at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:398)
>        at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:120)
>        at java.lang.Class.forName0(Native Method)
>        at java.lang.Class.forName(Class.java:266)
>        at org.jboss.logmanager.formatters.Formatters$12.guessClass(Formatters.java:578)
>        at org.jboss.logmanager.formatters.Formatters$12.renderExtended(Formatters.java:421)
>        at org.jboss.logmanager.formatters.Formatters$12.renderRaw(Formatters.java:388)
>        at org.jboss.logmanager.formatters.Formatters$JustifyingFormatStep.render(Formatters.java:150)
>        at org.jboss.logmanager.formatters.MultistepFormatter.format(MultistepFormatter.java:86)
>        at org.jboss.logmanager.ExtFormatter.format(ExtFormatter.java:35)
>        at org.jboss.logmanager.handlers.WriterHandler.doPublish(WriterHandler.java:49)
>        at org.jboss.logmanager.ExtHandler.publish(ExtHandler.java:76)
>        at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:290)
>        at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:298)
>        at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:298)
>        at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:298)
>        at org.jboss.logmanager.Logger.logRaw(Logger.java:721)
>        at org.jboss.logmanager.Logger.logRaw(Logger.java:731)
>        at org.jboss.logmanager.Logger.log(Logger.java:367)
>        ...

--
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

From issues at jboss.org  Sun Mar  2 19:58:48 2014
From: issues at jboss.org (James Livingston (JIRA))
Date: Sun, 2 Mar 2014 19:58:48 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (LOGMGR-99) Infinite recursion when
 exception stack frame class lookup fails
In-Reply-To: <JIRA.12533713.1393800685000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12533713.1393800685000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12533713.1393800685000.31071.1393808328855@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/LOGMGR-99?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

James Livingston updated LOGMGR-99:
-----------------------------------

    Attachment: logmgr99.war


This is a simple reproducer (works on both JBoss EAP and WildFly). It contains a simple servlet which logs a RuntimeException, and two fake class files (org.wildfly.extension.undertow.deployment.UndertowDeploymentService and org.jboss.threads.JBossThread) which contain text not a class.

When guessClass() tried to load the class Modules will attempt to log the fact and triggers the recursion.
                
> Infinite recursion when exception stack frame class lookup fails
> ----------------------------------------------------------------
>
>                 Key: LOGMGR-99
>                 URL: https://issues.jboss.org/browse/LOGMGR-99
>             Project: JBoss Log Manager
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 1.5.1.Final
>            Reporter: James Livingston
>            Assignee: David Lloyd
>            Priority: Critical
>         Attachments: logmgr99.war
>
>
> To print out the jar information in exception stack traces, the log manager needs to resolve the class name from StackTraceElement to the Class object. Since the log manager cannot know which classloader was used, guessClass() tries the TCCL, the logmanager's classloader and finally the system classloader.
> It is possible that the TCCL contains a class of the same name as the one in the stack frame, but it not the same class. This can easily happen if the application packages a jar that is also used by the container. In this situation, the class may not be able to be loaded, such as if the application-packages class is missing it's dependencies.
> If Class.forName() would throw a NoClassDefFoundError or similar, JBoss Modules (or other classloader implementation) may attempt to log this using java.util.logging API. This can result in infinite recursion, for example
>        ...
>        at org.jboss.logmanager.Logger.log(Logger.java:367)
>        at org.jboss.modules.log.JDKModuleLogger.doLog(JDKModuleLogger.java:109)
>        at org.jboss.modules.log.JDKModuleLogger.classDefineFailed(JDKModuleLogger.java:194)
>        at org.jboss.modules.ModuleClassLoader.defineClass(ModuleClassLoader.java:401)
>        at org.jboss.modules.ModuleClassLoader.loadClassLocal(ModuleClassLoader.java:243)
>        at org.jboss.modules.ModuleClassLoader$1.loadClassLocal(ModuleClassLoader.java:73)
>        at org.jboss.modules.Module.loadModuleClass(Module.java:527)
>        at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:182)
>        at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:468)
>        at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:456)
>        at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:398)
>        at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:120)
>        at java.lang.Class.forName0(Native Method)
>        at java.lang.Class.forName(Class.java:266)
>        at org.jboss.logmanager.formatters.Formatters$12.guessClass(Formatters.java:578)
>        at org.jboss.logmanager.formatters.Formatters$12.renderExtended(Formatters.java:421)
>        at org.jboss.logmanager.formatters.Formatters$12.renderRaw(Formatters.java:388)
>        at org.jboss.logmanager.formatters.Formatters$JustifyingFormatStep.render(Formatters.java:150)
>        at org.jboss.logmanager.formatters.MultistepFormatter.format(MultistepFormatter.java:86)
>        at org.jboss.logmanager.ExtFormatter.format(ExtFormatter.java:35)
>        at org.jboss.logmanager.handlers.WriterHandler.doPublish(WriterHandler.java:49)
>        at org.jboss.logmanager.ExtHandler.publish(ExtHandler.java:76)
>        at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:290)
>        at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:298)
>        at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:298)
>        at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:298)
>        at org.jboss.logmanager.Logger.logRaw(Logger.java:721)
>        at org.jboss.logmanager.Logger.logRaw(Logger.java:731)
>        at org.jboss.logmanager.Logger.log(Logger.java:367)
>        ...

--
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

From issues at jboss.org  Sun Mar  2 20:06:47 2014
From: issues at jboss.org (James Livingston (JIRA))
Date: Sun, 2 Mar 2014 20:06:47 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (LOGMGR-99) Infinite recursion when
 exception stack frame class lookup fails
In-Reply-To: <JIRA.12533713.1393800685000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12533713.1393800685000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12533713.1393800685000.31077.1393808807675@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/LOGMGR-99?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12949214#comment-12949214 ] 

James Livingston commented on LOGMGR-99:
----------------------------------------

guessClass()'s TCCL lookup and system CL lookup pass false for the second parameter so that the class is not initialised. The second forName() call which will use the log manager CL uses the single argument version which results in true being passed. It is not very likely that a log manager class would fail to initialise, but it may be worth changing "Class.forName(name)" to "Class.forName(name, false, Formatters.class.getClassLoader()" to be consistent although that wouldn't prevent this issue.

A naive solution would be set a (thread-local?) marker when performing the logging and abort if it attempts to log while logging. That would not however deal with Async loggers, which would make solving it more complex.
                
> Infinite recursion when exception stack frame class lookup fails
> ----------------------------------------------------------------
>
>                 Key: LOGMGR-99
>                 URL: https://issues.jboss.org/browse/LOGMGR-99
>             Project: JBoss Log Manager
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 1.5.1.Final
>            Reporter: James Livingston
>            Assignee: David Lloyd
>            Priority: Critical
>         Attachments: logmgr99.war
>
>
> To print out the jar information in exception stack traces, the log manager needs to resolve the class name from StackTraceElement to the Class object. Since the log manager cannot know which classloader was used, guessClass() tries the TCCL, the logmanager's classloader and finally the system classloader.
> It is possible that the TCCL contains a class of the same name as the one in the stack frame, but it not the same class. This can easily happen if the application packages a jar that is also used by the container. In this situation, the class may not be able to be loaded, such as if the application-packages class is missing it's dependencies.
> If Class.forName() would throw a NoClassDefFoundError or similar, JBoss Modules (or other classloader implementation) may attempt to log this using java.util.logging API. This can result in infinite recursion, for example
>        ...
>        at org.jboss.logmanager.Logger.log(Logger.java:367)
>        at org.jboss.modules.log.JDKModuleLogger.doLog(JDKModuleLogger.java:109)
>        at org.jboss.modules.log.JDKModuleLogger.classDefineFailed(JDKModuleLogger.java:194)
>        at org.jboss.modules.ModuleClassLoader.defineClass(ModuleClassLoader.java:401)
>        at org.jboss.modules.ModuleClassLoader.loadClassLocal(ModuleClassLoader.java:243)
>        at org.jboss.modules.ModuleClassLoader$1.loadClassLocal(ModuleClassLoader.java:73)
>        at org.jboss.modules.Module.loadModuleClass(Module.java:527)
>        at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:182)
>        at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:468)
>        at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:456)
>        at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:398)
>        at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:120)
>        at java.lang.Class.forName0(Native Method)
>        at java.lang.Class.forName(Class.java:266)
>        at org.jboss.logmanager.formatters.Formatters$12.guessClass(Formatters.java:578)
>        at org.jboss.logmanager.formatters.Formatters$12.renderExtended(Formatters.java:421)
>        at org.jboss.logmanager.formatters.Formatters$12.renderRaw(Formatters.java:388)
>        at org.jboss.logmanager.formatters.Formatters$JustifyingFormatStep.render(Formatters.java:150)
>        at org.jboss.logmanager.formatters.MultistepFormatter.format(MultistepFormatter.java:86)
>        at org.jboss.logmanager.ExtFormatter.format(ExtFormatter.java:35)
>        at org.jboss.logmanager.handlers.WriterHandler.doPublish(WriterHandler.java:49)
>        at org.jboss.logmanager.ExtHandler.publish(ExtHandler.java:76)
>        at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:290)
>        at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:298)
>        at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:298)
>        at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:298)
>        at org.jboss.logmanager.Logger.logRaw(Logger.java:721)
>        at org.jboss.logmanager.Logger.logRaw(Logger.java:731)
>        at org.jboss.logmanager.Logger.log(Logger.java:367)
>        ...

--
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

From issues at jboss.org  Mon Mar  3 00:42:47 2014
From: issues at jboss.org (Rituraj Sinha (JIRA))
Date: Mon, 3 Mar 2014 00:42:47 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3051) JMX connection to remote
 server-instances is not happening in wildfly 8.0.0.Final in domain mode
In-Reply-To: <JIRA.12533723.1393825342453@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12533723.1393825342453@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12533723.1393825342453.31209.1393825367599@jira02.app.mwc.hst.phx2.redhat.com>

Rituraj Sinha created WFLY-3051:
-----------------------------------

             Summary: JMX connection to remote server-instances is not happening in wildfly 8.0.0.Final in domain mode
                 Key: WFLY-3051
                 URL: https://issues.jboss.org/browse/WFLY-3051
             Project: WildFly
          Issue Type: Task
      Security Level: Public (Everyone can see)
          Components: JMX, Remoting
            Reporter: Rituraj Sinha
            Assignee: Kabir Khan
            Priority: Critical


i have gone through the below link for JMX subsystem for wildfly 8 as
https://docs.jboss.org/author/display/WFLY8/JMX+subsystem+configuration
 
but unable to connect to server-instances running remotely ...i have posted my question there as well and pasting it here now ...
can someone please give us the steps to configure JMX through jconsole...?

changes done on the domain.xml are the same as stated above

<subsystem xmlns="urn:jboss:domain:jmx:1.3">
                <expose-resolved-model/>
                <expose-expression-model/>
                <remoting-connector use-management-endpoint="false"/>
            </subsystem>
<subsystem xmlns="urn:jboss:domain:jmx:1.3">
                <expose-resolved-model/>
                <expose-expression-model/>
                <remoting-connector use-management-endpoint="false"/>
            </subsystem>
as per the jboss-as-jmx_1_3.xsd  its like
<xs:attribute name="use-management-endpoint" type="xs:boolean" default="true" use="optional" >
            <xs:annotation>
                <xs:documentation>
                    If true then this connector will use the management endpoint, otherwise it will use the
                    remoting subsystem endpoint.
                </xs:documentation>
            </xs:annotation>
        </xs:attribute>
now if we are making it false then it should be using the remoting endpoint ...now remoting subsystem by default uses ApplicatoinRealm
i have created application-user and password for the same but when i am trying to connect to remote server-instances its not connecting it....
below is what i am able to connect to 
service:jmx:http-remoting-jmx://remote_hostA:9990 --

Unknown macro: {host A is where my domain_controller is running}
how can i access the server-instances running on domain_controller

Unknown macro: {there are three server_instanaces running on HostA with a port offset of 100 each}
i am trying to connect with the below url as 
service:jmx:http-remoting-jmx://lremote_hostA:8180

let me know if something is missing from my side...
Thanks

--
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

From issues at jboss.org  Mon Mar  3 02:50:48 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 3 Mar 2014 02:50:48 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2920) StackOverflowError when
 org.jboss.as.jacorb.rmi.InterfaceAnalysis is analyzing javax.ejb.EJBObject
In-Reply-To: <JIRA.12532007.1392269121000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12532007.1392269121000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12532007.1392269121000.31319.1393833048352@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2920?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12949241#comment-12949241 ] 

RH Bugzilla Integration commented on WFLY-2920:
-----------------------------------------------

Osamu Nagano <onagano at redhat.com> changed the Status of [bug 1064644|https://bugzilla.redhat.com/show_bug.cgi?id=1064644] from NEW to ASSIGNED
                
> StackOverflowError when org.jboss.as.jacorb.rmi.InterfaceAnalysis is analyzing javax.ejb.EJBObject
> --------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2920
>                 URL: https://issues.jboss.org/browse/WFLY-2920
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: IIOP
>    Affects Versions: 8.0.0.Final
>            Reporter: Osamu Nagano
>            Assignee: Stefan Guilhen
>         Attachments: td.dump
>
>
> Depending on when a thread context switch happens, an IIOP enabled EJB fails to be deployed by throwing {{java.lang.StackOverflowError}}.  Here is the stack trace from the attached thread dump.
> {code}
> "MSC service thread 1-7" prio=10 tid=0x00007f52e8001800 nid=0x4d12 at breakpoint[0x00007f534093f000]
>    java.lang.Thread.State: RUNNABLE
>         at org.jboss.as.jacorb.rmi.WorkCacheManager.getAnalysis(WorkCacheManager.java:105)
>         at org.jboss.as.jacorb.rmi.InterfaceAnalysis.getInterfaceAnalysis(InterfaceAnalysis.java:53)
>         at org.jboss.as.jacorb.rmi.Util.getTypeIDLName(Util.java:104)
>         at org.jboss.as.jacorb.rmi.ParameterAnalysis.<init>(ParameterAnalysis.java:50)
>         at org.jboss.as.jacorb.rmi.OperationAnalysis.<init>(OperationAnalysis.java:91)
>         at org.jboss.as.jacorb.rmi.InterfaceAnalysis.analyzeOperations(InterfaceAnalysis.java:116)
>         at org.jboss.as.jacorb.rmi.ContainerAnalysis.doAnalyze(ContainerAnalysis.java:186)
>         at org.jboss.as.jacorb.rmi.InterfaceAnalysis.doAnalyze(InterfaceAnalysis.java:62)
>         at sun.reflect.GeneratedMethodAccessor3.invoke(Unknown Source)
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>         at java.lang.reflect.Method.invoke(Method.java:606)
>         at org.jboss.as.jacorb.rmi.WorkCacheManager.doTheWork(WorkCacheManager.java:177)
>         at org.jboss.as.jacorb.rmi.WorkCacheManager.getAnalysis(WorkCacheManager.java:105)
>         at org.jboss.as.jacorb.rmi.InterfaceAnalysis.getInterfaceAnalysis(InterfaceAnalysis.java:53)
>         at org.jboss.as.jacorb.rmi.Util.getTypeIDLName(Util.java:104)
>         at org.jboss.as.jacorb.rmi.ParameterAnalysis.<init>(ParameterAnalysis.java:50)
>         at org.jboss.as.jacorb.rmi.OperationAnalysis.<init>(OperationAnalysis.java:91)
>         at org.jboss.as.jacorb.rmi.InterfaceAnalysis.analyzeOperations(InterfaceAnalysis.java:116)
>         at org.jboss.as.jacorb.rmi.ContainerAnalysis.doAnalyze(ContainerAnalysis.java:186)
>         at org.jboss.as.jacorb.rmi.InterfaceAnalysis.doAnalyze(InterfaceAnalysis.java:62)
>         at sun.reflect.GeneratedMethodAccessor3.invoke(Unknown Source)
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>         at java.lang.reflect.Method.invoke(Method.java:606)
>         ...
>         at org.jboss.as.jacorb.rmi.WorkCacheManager.doTheWork(WorkCacheManager.java:177)
>         at org.jboss.as.jacorb.rmi.WorkCacheManager.getAnalysis(WorkCacheManager.java:105)
>         at org.jboss.as.jacorb.rmi.InterfaceAnalysis.getInterfaceAnalysis(InterfaceAnalysis.java:53)
>         at org.jboss.as.jacorb.rmi.Util.getTypeIDLName(Util.java:104)
>         at org.jboss.as.jacorb.rmi.ParameterAnalysis.<init>(ParameterAnalysis.java:50)
>    Locked ownable synchronizers:
>         - <0x00000000f9698790> (a java.util.concurrent.ThreadPoolExecutor$Worker)
> {code}
> The last part including {{Util.getTypeIDLName}} has been repeated as many as possible and the bottom of the stack has been lost.  The same stack has been appeared in a different MSC service thread which is also executing an IIOP enabled EJB deployment.
> The customer identified an improper synchronization in {{org.jboss.as.jacorb.rmi.WorkCacheManager#getAnalysis()}}.  It is reproducible by manually controlling a thread context switch using a debugger.

--
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

From issues at jboss.org  Mon Mar  3 03:52:47 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 3 Mar 2014 03:52:47 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2920) StackOverflowError when
 org.jboss.as.jacorb.rmi.InterfaceAnalysis is analyzing javax.ejb.EJBObject
In-Reply-To: <JIRA.12532007.1392269121000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12532007.1392269121000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12532007.1392269121000.31396.1393836767833@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2920?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12949255#comment-12949255 ] 

RH Bugzilla Integration commented on WFLY-2920:
-----------------------------------------------

Osamu Nagano <onagano at redhat.com> changed the Status of [bug 1064644|https://bugzilla.redhat.com/show_bug.cgi?id=1064644] from ASSIGNED to POST
                
> StackOverflowError when org.jboss.as.jacorb.rmi.InterfaceAnalysis is analyzing javax.ejb.EJBObject
> --------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2920
>                 URL: https://issues.jboss.org/browse/WFLY-2920
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: IIOP
>    Affects Versions: 8.0.0.Final
>            Reporter: Osamu Nagano
>            Assignee: Stefan Guilhen
>         Attachments: td.dump
>
>
> Depending on when a thread context switch happens, an IIOP enabled EJB fails to be deployed by throwing {{java.lang.StackOverflowError}}.  Here is the stack trace from the attached thread dump.
> {code}
> "MSC service thread 1-7" prio=10 tid=0x00007f52e8001800 nid=0x4d12 at breakpoint[0x00007f534093f000]
>    java.lang.Thread.State: RUNNABLE
>         at org.jboss.as.jacorb.rmi.WorkCacheManager.getAnalysis(WorkCacheManager.java:105)
>         at org.jboss.as.jacorb.rmi.InterfaceAnalysis.getInterfaceAnalysis(InterfaceAnalysis.java:53)
>         at org.jboss.as.jacorb.rmi.Util.getTypeIDLName(Util.java:104)
>         at org.jboss.as.jacorb.rmi.ParameterAnalysis.<init>(ParameterAnalysis.java:50)
>         at org.jboss.as.jacorb.rmi.OperationAnalysis.<init>(OperationAnalysis.java:91)
>         at org.jboss.as.jacorb.rmi.InterfaceAnalysis.analyzeOperations(InterfaceAnalysis.java:116)
>         at org.jboss.as.jacorb.rmi.ContainerAnalysis.doAnalyze(ContainerAnalysis.java:186)
>         at org.jboss.as.jacorb.rmi.InterfaceAnalysis.doAnalyze(InterfaceAnalysis.java:62)
>         at sun.reflect.GeneratedMethodAccessor3.invoke(Unknown Source)
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>         at java.lang.reflect.Method.invoke(Method.java:606)
>         at org.jboss.as.jacorb.rmi.WorkCacheManager.doTheWork(WorkCacheManager.java:177)
>         at org.jboss.as.jacorb.rmi.WorkCacheManager.getAnalysis(WorkCacheManager.java:105)
>         at org.jboss.as.jacorb.rmi.InterfaceAnalysis.getInterfaceAnalysis(InterfaceAnalysis.java:53)
>         at org.jboss.as.jacorb.rmi.Util.getTypeIDLName(Util.java:104)
>         at org.jboss.as.jacorb.rmi.ParameterAnalysis.<init>(ParameterAnalysis.java:50)
>         at org.jboss.as.jacorb.rmi.OperationAnalysis.<init>(OperationAnalysis.java:91)
>         at org.jboss.as.jacorb.rmi.InterfaceAnalysis.analyzeOperations(InterfaceAnalysis.java:116)
>         at org.jboss.as.jacorb.rmi.ContainerAnalysis.doAnalyze(ContainerAnalysis.java:186)
>         at org.jboss.as.jacorb.rmi.InterfaceAnalysis.doAnalyze(InterfaceAnalysis.java:62)
>         at sun.reflect.GeneratedMethodAccessor3.invoke(Unknown Source)
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>         at java.lang.reflect.Method.invoke(Method.java:606)
>         ...
>         at org.jboss.as.jacorb.rmi.WorkCacheManager.doTheWork(WorkCacheManager.java:177)
>         at org.jboss.as.jacorb.rmi.WorkCacheManager.getAnalysis(WorkCacheManager.java:105)
>         at org.jboss.as.jacorb.rmi.InterfaceAnalysis.getInterfaceAnalysis(InterfaceAnalysis.java:53)
>         at org.jboss.as.jacorb.rmi.Util.getTypeIDLName(Util.java:104)
>         at org.jboss.as.jacorb.rmi.ParameterAnalysis.<init>(ParameterAnalysis.java:50)
>    Locked ownable synchronizers:
>         - <0x00000000f9698790> (a java.util.concurrent.ThreadPoolExecutor$Worker)
> {code}
> The last part including {{Util.getTypeIDLName}} has been repeated as many as possible and the bottom of the stack has been lost.  The same stack has been appeared in a different MSC service thread which is also executing an IIOP enabled EJB deployment.
> The customer identified an improper synchronization in {{org.jboss.as.jacorb.rmi.WorkCacheManager#getAnalysis()}}.  It is reproducible by manually controlling a thread context switch using a debugger.

--
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

From issues at jboss.org  Mon Mar  3 04:12:47 2014
From: issues at jboss.org (Remy Maucherat (JIRA))
Date: Mon, 3 Mar 2014 04:12:47 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JBWEB-290) Optimize string literals
 inside jsp expressions
In-Reply-To: <JIRA.12533522.1393516764000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12533522.1393516764000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12533522.1393516764000.31440.1393837967870@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JBWEB-290?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12949260#comment-12949260 ] 

Remy Maucherat commented on JBWEB-290:
--------------------------------------

This is not going to get fixed or looked at as this is scriplet = a Java code fragment. It is equivalent to writing the same Java code in a Servlet.
                
> Optimize string literals inside jsp expressions 
> ------------------------------------------------
>
>                 Key: JBWEB-290
>                 URL: https://issues.jboss.org/browse/JBWEB-290
>             Project: JBoss Web
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Tomcat
>    Affects Versions: JBossWeb-3.0.0.Final
>            Reporter: John O'Hara
>            Assignee: Remy Maucherat
>
> After setting genStringAsCharArray=true, we continue to see StringBuilder concatenating string literals for each jsp request for some of our jsp pages; instead of creating a static char[].
> This occurs when a string literal is included in a jsp expression, e.g.;
> <%="<INPUT type=\"hidden\" name=\"name\" value=\"" + obj.getName() + "\">"%>
> Is it possible to identify string literals inside expressions during the tokenization phase of parsing jsp pages in apache jasper and treat them as text nodes so that the apache jasper generator can apply the same optimizations as string literals outside the jsp expression?

--
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

From issues at jboss.org  Mon Mar  3 05:10:47 2014
From: issues at jboss.org (Hardy Ferentschik (JIRA))
Date: Mon, 3 Mar 2014 05:10:47 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3052) Upgrade Hibernate Validator
	to 5.1.0.Final
In-Reply-To: <JIRA.12533744.1393841342000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12533744.1393841342000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12533744.1393841342000.31570.1393841447880@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-3052?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Hardy Ferentschik updated WFLY-3052:
------------------------------------

    Description: Hibernate Validator 5.1.0.Final contains several performance improvements as well as a lower memory footprint. It also fixes a {{NullPointerException}} during server shutdown ([HV-865|https://hibernate.atlassian.net/browse/HV-865]).  (was: Hibernate Validator 5.1.0.Final contains several performance improvements as well as a lower memory footprint. It also fixes a {{NullPointerException}} during server shutdown ([HV-865|https://hibernate.atlassian.net/browse/HV-865])

    
> Upgrade Hibernate Validator to 5.1.0.Final
> ------------------------------------------
>
>                 Key: WFLY-3052
>                 URL: https://issues.jboss.org/browse/WFLY-3052
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>            Reporter: Hardy Ferentschik
>            Assignee: Hardy Ferentschik
>             Fix For: 8.0.1.Final
>
>
> Hibernate Validator 5.1.0.Final contains several performance improvements as well as a lower memory footprint. It also fixes a {{NullPointerException}} during server shutdown ([HV-865|https://hibernate.atlassian.net/browse/HV-865]).

--
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

From issues at jboss.org  Mon Mar  3 05:10:47 2014
From: issues at jboss.org (Hardy Ferentschik (JIRA))
Date: Mon, 3 Mar 2014 05:10:47 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3052) Upgrade Hibernate Validator
	to 5.1.0.Final
In-Reply-To: <JIRA.12533744.1393841342404@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12533744.1393841342404@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12533744.1393841342404.31568.1393841447756@jira02.app.mwc.hst.phx2.redhat.com>

Hardy Ferentschik created WFLY-3052:
---------------------------------------

             Summary: Upgrade Hibernate Validator to 5.1.0.Final
                 Key: WFLY-3052
                 URL: https://issues.jboss.org/browse/WFLY-3052
             Project: WildFly
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
            Reporter: Hardy Ferentschik
            Assignee: Hardy Ferentschik
             Fix For: 8.0.1.Final


Hibernate Validator 5.1.0.Final contains several performance improvements as well as a lower memory footprint. It also fixes a {{NullPointerException}} during server shutdown ([HV-865|https://hibernate.atlassian.net/browse/HV-865]

--
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

From issues at jboss.org  Mon Mar  3 05:18:47 2014
From: issues at jboss.org (Tom Jenkinson (JIRA))
Date: Mon, 3 Mar 2014 05:18:47 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3042) There should be a warning
 logged if the default value of node identifier has not been changed.
In-Reply-To: <JIRA.12533608.1393595350000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12533608.1393595350000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12533608.1393595350000.31587.1393841927831@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-3042?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12949279#comment-12949279 ] 

Tom Jenkinson commented on WFLY-3042:
-------------------------------------

What I meant, is that we _want_ to support different servers assuming the identity. There is a concept with Narayana that you can run the transaction manager on any machine and point it at an object store (e.g. jdbc one) and give it an identifier to take over from an old server.

Narayana itself is pluggable, i.e. it exposes a setXaNodeName method that clients (e.g. subsystem) are free to pass in what they like. The subsystem itself is currently only pluggable in so much as it supports a single implementation that obtains the value to use from the standalone.xml. It would be possible to alter the subsystem to use the IP address etc but as I say, when it boots up on a different machine it will have a different node name so wouldn't take over from the old server.

Happy to alter the subsystem but I am not really sure its a good idea to use the IP/port as the ID for the reason I mentioned above. In terms of the alternative (a uuid), I mentioned the reason I was worried to use something random is in case it is lost.

Suggestions?
                
> There should be a warning logged if the default value of node identifier has not been changed.  
> ------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-3042
>                 URL: https://issues.jboss.org/browse/WFLY-3042
>             Project: WildFly
>          Issue Type: Enhancement
>      Security Level: Public(Everyone can see) 
>          Components: Transactions
>    Affects Versions: 8.0.0.Final
>         Environment: JBoss EAP 6.x
>            Reporter: Tom Ross
>            Assignee: Gytis Trikleris
>
> JBoss EAP instance is using the value of node identifier  to identify XA transactions that belong to it. By default this value is set to 1. Now days in most environments there will be multiple JBoss instances sharing XA resources there for it is necessary to set the value of node identifier to a unique value for each instance. This is something that most end users fail to perform. Therefor it would be helpful if  a warning  message was logged at startup telling the user to do it.

--
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

From issues at jboss.org  Mon Mar  3 05:28:49 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 3 Mar 2014 05:28:49 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-421) EvaluatorWrapper does not
 resolve the right handle correctly
In-Reply-To: <JIRA.12531077.1391475908000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12531077.1391475908000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12531077.1391475908000.31616.1393842529789@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/DROOLS-421?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12949286#comment-12949286 ] 

RH Bugzilla Integration commented on DROOLS-421:
------------------------------------------------

Ryan Zhang <rzhang at redhat.com> changed the Status of [bug 1063809|https://bugzilla.redhat.com/show_bug.cgi?id=1063809] from MODIFIED to ON_QA
                
> EvaluatorWrapper does not resolve the right handle correctly
> ------------------------------------------------------------
>
>                 Key: DROOLS-421
>                 URL: https://issues.jboss.org/browse/DROOLS-421
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.5.1.Final, 6.0.0.Final, 6.0.1.Final, 6.1.0.Beta1
>            Reporter: Davide Sottara
>            Assignee: Mario Fusco
>            Priority: Critical
>             Fix For: 6.1.0.Beta1
>
>
> The EvaluatorWrapper tries to look up the right handle from the WM, but there may be cases (e.g. when the right input comes from a FROM node)
> where the handle is not in the WM, causing a NPE. This causes the right handle to be null, or to be resolved incorrectly. Evaluations are then inconsistent.

--
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

From issues at jboss.org  Mon Mar  3 05:28:50 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 3 Mar 2014 05:28:50 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-416) Queries do not work with
	events
In-Reply-To: <JIRA.12530363.1390784899000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530363.1390784899000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530363.1390784899000.31620.1393842530086@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/DROOLS-416?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12949287#comment-12949287 ] 

RH Bugzilla Integration commented on DROOLS-416:
------------------------------------------------

Ryan Zhang <rzhang at redhat.com> changed the Status of [bug 1063805|https://bugzilla.redhat.com/show_bug.cgi?id=1063805] from MODIFIED to ON_QA
                
> Queries do not work with events
> -------------------------------
>
>                 Key: DROOLS-416
>                 URL: https://issues.jboss.org/browse/DROOLS-416
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 6.0.0.Final
>            Reporter: Davide Sottara
>            Assignee: Mario Fusco
>            Priority: Critical
>             Fix For: 6.1.0.Beta1
>
>


--
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

From issues at jboss.org  Mon Mar  3 05:28:50 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 3 Mar 2014 05:28:50 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-393) Trait Hierarchy is not
 rebuilt correctly when merging packages
In-Reply-To: <JIRA.12528619.1388831451000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528619.1388831451000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528619.1388831451000.31624.1393842530351@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/DROOLS-393?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12949288#comment-12949288 ] 

RH Bugzilla Integration commented on DROOLS-393:
------------------------------------------------

Ryan Zhang <rzhang at redhat.com> changed the Status of [bug 1063803|https://bugzilla.redhat.com/show_bug.cgi?id=1063803] from MODIFIED to ON_QA
                
> Trait Hierarchy is not rebuilt correctly when merging packages
> --------------------------------------------------------------
>
>                 Key: DROOLS-393
>                 URL: https://issues.jboss.org/browse/DROOLS-393
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.5.0.Final, 6.0.0.Final, 6.0.1.Final
>            Reporter: Davide Sottara
>            Assignee: Mario Fusco
>            Priority: Critical
>             Fix For: 5.5.1.Final, 6.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

From issues at jboss.org  Mon Mar  3 05:30:48 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 3 Mar 2014 05:30:48 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-430) Fails to parse DSL variable
 definition with single dot regex
In-Reply-To: <JIRA.12532345.1392621213000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12532345.1392621213000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12532345.1392621213000.31632.1393842648231@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/DROOLS-430?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12949291#comment-12949291 ] 

RH Bugzilla Integration commented on DROOLS-430:
------------------------------------------------

Ryan Zhang <rzhang at redhat.com> changed the Status of [bug 1065868|https://bugzilla.redhat.com/show_bug.cgi?id=1065868] from MODIFIED to ON_QA
                
> Fails to parse DSL variable definition with single dot regex
> ------------------------------------------------------------
>
>                 Key: DROOLS-430
>                 URL: https://issues.jboss.org/browse/DROOLS-430
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 6.0.1.Final
>            Reporter: Toshiya Kobayashi
>            Assignee: Edson Tirelli
>             Fix For: 6.1.0.Beta1
>
>
> Drools fails to parse DSL variable definition with single dot regex, where I want one any character.
> {noformat}
> [then]Log {message:.}=list.add(\"{message}\");
> {noformat}
> Error message:
> {noformat}
> [1,19]: DSL parser error
> {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

From issues at jboss.org  Mon Mar  3 05:30:48 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 3 Mar 2014 05:30:48 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-426) Globals can't be used with
 temporal operators
In-Reply-To: <JIRA.12531807.1392151630000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12531807.1392151630000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12531807.1392151630000.31636.1393842648486@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/DROOLS-426?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12949292#comment-12949292 ] 

RH Bugzilla Integration commented on DROOLS-426:
------------------------------------------------

Ryan Zhang <rzhang at redhat.com> changed the Status of [bug 1064224|https://bugzilla.redhat.com/show_bug.cgi?id=1064224] from MODIFIED to ON_QA
                
> Globals can't be used with temporal operators
> ---------------------------------------------
>
>                 Key: DROOLS-426
>                 URL: https://issues.jboss.org/browse/DROOLS-426
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Davide Sottara
>            Assignee: Mario Fusco
>            Priority: Critical
>             Fix For: 6.1.0.Beta1
>
>
> Assuming:
> global Date now;
> The pattern "Foo( this before now )" will generate various errors.
> The reason is that the Global[X]Extractors (X = {"","Date","Number"}
> are erroneously declared as self-referential extractors.
> If Foo is not an @event, a CCE will arise since the operators will use
> "this" rather than the global. Otherwise, the result will be inconsistent

--
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

From issues at jboss.org  Mon Mar  3 05:30:48 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 3 Mar 2014 05:30:48 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-364) ClasspathKieProject fails
 vfs: path for jar deployments and exploded ear
In-Reply-To: <JIRA.12527146.1386272749000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12527146.1386272749000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12527146.1386272749000.31641.1393842648811@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/DROOLS-364?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12949293#comment-12949293 ] 

RH Bugzilla Integration commented on DROOLS-364:
------------------------------------------------

Ryan Zhang <rzhang at redhat.com> changed the Status of [bug 1058254|https://bugzilla.redhat.com/show_bug.cgi?id=1058254] from MODIFIED to ON_QA
                
> ClasspathKieProject fails vfs: path for jar deployments and exploded ear
> ------------------------------------------------------------------------
>
>                 Key: DROOLS-364
>                 URL: https://issues.jboss.org/browse/DROOLS-364
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 6.0.0.Final
>         Environment: JBoss AS 7.1.1
>            Reporter: Nicolas-Xavier Vanderlinden
>            Assignee: Mario Fusco
>             Fix For: 6.1.0.Beta1
>
>         Attachments: jbossas-deploy-reproducer.zip, windows-jboss-as-deploy-server.log
>
>
> Drools is not able to load kmodule.xml from an exploded ear.
> 17:24:45,116 WARN  Unable to load pom.properties tried recursing down from\Project\Geline\jboss-as-7.1.1.Final\standalone\deployments\geline.ear\service-impl-1.4.0-SNAPcontent
> null
> 17:24:45,116 ERROR Unable to build index of kmodule.xml url=vfs:/E:/Project/Geline/jboss-as-7.1.1.Final/standalone/deployments/geline.ear/service-impl-1.4.0-SNAPSHOT.jar/META-INF/kmodule.xml
> null

--
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

From issues at jboss.org  Mon Mar  3 05:30:49 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 3 Mar 2014 05:30:49 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-417) Turn on Kie-Ci into an OSGI
	Bundle
In-Reply-To: <JIRA.12530385.1390823961000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530385.1390823961000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530385.1390823961000.31650.1393842649622@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/DROOLS-417?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12949296#comment-12949296 ] 

RH Bugzilla Integration commented on DROOLS-417:
------------------------------------------------

Ryan Zhang <rzhang at redhat.com> changed the Status of [bug 1067867|https://bugzilla.redhat.com/show_bug.cgi?id=1067867] from MODIFIED to ON_QA
                
> Turn on Kie-Ci into an OSGI Bundle
> ----------------------------------
>
>                 Key: DROOLS-417
>                 URL: https://issues.jboss.org/browse/DROOLS-417
>             Project: Drools
>          Issue Type: Enhancement
>      Security Level: Public(Everyone can see) 
>            Reporter: Charles Moulliard
>            Assignee: Mark Proctor
>


--
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

From issues at jboss.org  Mon Mar  3 05:30:49 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 3 Mar 2014 05:30:49 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-391) Support class literals with
 complex constraints and custom evaluators
In-Reply-To: <JIRA.12528582.1388747122000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528582.1388747122000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528582.1388747122000.31654.1393842649949@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/DROOLS-391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12949297#comment-12949297 ] 

RH Bugzilla Integration commented on DROOLS-391:
------------------------------------------------

Ryan Zhang <rzhang at redhat.com> changed the Status of [bug 1063795|https://bugzilla.redhat.com/show_bug.cgi?id=1063795] from MODIFIED to ON_QA
                
> Support class literals with complex constraints and custom evaluators
> ---------------------------------------------------------------------
>
>                 Key: DROOLS-391
>                 URL: https://issues.jboss.org/browse/DROOLS-391
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.5.1.Final, 6.0.0.Final
>            Reporter: Davide Sottara
>            Assignee: Mario Fusco
>             Fix For: 6.1.0.Beta1
>
>
> The following is supported, when A is a class name:
> {code} Pattern( this op A ) {code}
> But the following fails with a CCE
> {code} Pattern( this op A || this op B ) {code}
> when it tries to resolve A as a field of the class Pattern

--
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

From issues at jboss.org  Mon Mar  3 06:08:48 2014
From: issues at jboss.org (Peter Hinds (JIRA))
Date: Mon, 3 Mar 2014 06:08:48 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (AS7-1899) HornetQ deletes all JMS
 messages after shutdown
In-Reply-To: <JIRA.12447568.1316679449000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12447568.1316679449000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12447568.1316679449000.31712.1393844928653@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/AS7-1899?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12949307#comment-12949307 ] 

Peter Hinds commented on AS7-1899:
----------------------------------

I thought I would just add the following as a comment in case it helps anybody else who has searched this problem.

I found that my messages were disappearing after a shutdown even though I was using JBoss AS 7.3.0. I couldn't understand why I was still seeing the described problem when the version I was using should have included the fix.

In the end I was able to work out that my problem was that I was placing messages on the JMS queue using Hermes (www.hermesjms.com) and it uses non-persistent by default. To switch Hermes to persistent mode, click the icon in the tool bar that shows a tooltip of 'Toggle persistent message send'.
                
> HornetQ deletes all JMS messages after shutdown
> -----------------------------------------------
>
>                 Key: AS7-1899
>                 URL: https://issues.jboss.org/browse/AS7-1899
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: JMS
>    Affects Versions: 7.0.1.Final
>            Reporter: Fabrizio Benedetti
>            Assignee: Andy Taylor
>             Fix For: 7.1.0.Beta1
>
>
> After sending a persistent JMS message to a queue, and the message is not consumed, after reboot the message is deleted. Also, after the reboot, jboss reset persistence-enabled to false in standalone.xml, or sometimes the entire element is deleted.
> Following messaging subsystem configuration:
> {code:xml}
> <subsystem xmlns="urn:jboss:domain:messaging:1.0">
>     <journal-file-size>102400</journal-file-size>
>     <journal-min-files>2</journal-min-files>
>     <journal-type>NIO</journal-type>
>     <persistence-enabled>true</persistence-enabled>
>     <acceptors>
>         <netty-acceptor name="netty" socket-binding="messaging"/>
>         <netty-acceptor name="netty-throughput" socket-binding="messaging-throughput">
>             <param key="batch-delay" value="50"/>
>             <param key="direct-deliver" value="false"/>
>         </netty-acceptor>
>         <in-vm-acceptor name="in-vm" server-id="0"/>
>     </acceptors>
>     <address-settings>
>         <address-setting match="#">
>             <dead-letter-address>
>                 jms.queue.DLQ
>             </dead-letter-address>
>             <expiry-address>
>                 jms.queue.ExpiryQueue
>             </expiry-address>
>             <redelivery-delay>
>                 0
>             </redelivery-delay>
>             <max-size-bytes>
>                 10485760
>             </max-size-bytes>
>             <message-counter-history-day-limit>
>                 10
>             </message-counter-history-day-limit>
>             <address-full-policy>
>                 BLOCK
>             </address-full-policy>
>         </address-setting>
>     </address-settings>
>     <connectors>
>         <netty-connector name="netty" socket-binding="messaging"/>
>         <netty-connector name="netty-throughput" socket-binding="messaging-throughput">
>             <param key="batch-delay" value="50"/>
>         </netty-connector>
>         <in-vm-connector name="in-vm" server-id="0"/>
>     </connectors>
>     <security-settings>
>         <security-setting match="#">
>             <permission type="send" roles="guest"/>
>             <permission type="consume" roles="guest"/>
>             <permission type="createNonDurableQueue" roles="guest"/>
>             <permission type="deleteNonDurableQueue" roles="guest"/>
>         </security-setting>
>     </security-settings>
>     <jms-connection-factories>
>         <connection-factory name="InVmConnectionFactory">
>             <connectors>
>                 <connector-ref connector-name="in-vm"/>
>             </connectors>
>             <entries>
>                 <entry name="java:/ConnectionFactory"/>
>             </entries>
>         </connection-factory>
>         <connection-factory name="RemoteConnectionFactory">
>             <connectors>
>                 <connector-ref connector-name="netty"/>
>             </connectors>
>             <entries>
>                 <entry name="RemoteConnectionFactory"/>
>             </entries>
>         </connection-factory>
>         <pooled-connection-factory name="hornetq-ra">
>             <connectors>
>                 <connector-ref connector-name="in-vm"/>
>             </connectors>
>             <entries>
>                 <entry name="java:/JmsXA"/>
>             </entries>
>             <transaction mode="xa"/>
>         </pooled-connection-factory>
>     </jms-connection-factories>
>     <jms-destinations>
>         <jms-queue name="MyQueue">
>             <entry name="queue/MyQueue"/>
>         </jms-queue>
>     </jms-destinations>
> </subsystem>
> {code} 

--
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

From issues at jboss.org  Mon Mar  3 06:28:47 2014
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Mon, 3 Mar 2014 06:28:47 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3048) "Local" authentication fails
 when LDAP is used for ManagementRealm
In-Reply-To: <JIRA.12533664.1393614114000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12533664.1393614114000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12533664.1393614114000.31763.1393846127832@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-3048?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated WFLY-3048:
-----------------------------------

    Fix Version/s: 8.0.1.Final

    
> "Local" authentication fails when LDAP is used for ManagementRealm
> ------------------------------------------------------------------
>
>                 Key: WFLY-3048
>                 URL: https://issues.jboss.org/browse/WFLY-3048
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Security
>    Affects Versions: 8.0.0.Final
>         Environment: Ubuntu 13.04, Xeon-based VPS
>            Reporter: Matt Jensen
>            Assignee: Darran Lofthouse
>             Fix For: 8.0.1.Final
>
>
> When LDAP is used for authentication in ManagementRealm, "local" authentication, which is enabled in configuration for the realm, appears to stop working.
> I have configured my ManagementRealm to use LDAP for authentication of remote clients.  However, I also need to allow local authentication without a username and password, for when jboss-cli is invoked from the command line on the server.  This is needed in order for the wildfly-init-debian.sh script to shut down the server.  I have configured the ManagementRealm as follows:
> <security-realm name="ManagementRealm">
>         <authentication>
>             <local default-user="$local" />
>             <ldap connection="..." base-dn="ou=accounts,dc=..." recursive="false">
>                 ...
>             </ldap>
>         </authentication>
>         <authorization map-groups-to-roles="false">
>             <ldap connection="...">
>                 ...
>             </ldap>
>         </authorization>
>     </security-realm>
> I left out most of the LDAP configuration because I don't think it is important for this issue.  LDAP authentication works fine for remote clients.  In fact, it works fine for local clients as well--when I invoke jboss-cli with LDAP authentication enabled, it prompts for a username and password; if I enter a valid combination from the LDAP directory, jboss-cli connects successfully and executes its command.
> The problem is that I need it to NOT prompt for a username and password when jboss-cli is invoked locally.  Which, I believe, is how things are supposed to work when "local" authentication is also enabled; it just doesn't work that way when LDAP is enabled for the same realm.
> If I comment out the <ldap .../> element in <authentication> for the realm, local authentication starts working again.  I can invoke jboss-cli locally and the command is carried out without a username and password prompt.  Re-enable LDAP, with no other configuration changes, and again it flips back to requiring a username and password.
> I have tried replacing "$local" in the @default-user element of the <local> element with a valid name from the LDAP directory, both as a simple username and as a full DN, and jboss-cli still prompts for a username and password.
> The modification date on the [tmp/auth] directory changes when I run jboss-cli with LDAP in place and get the username/password prompt, so it appears that the client is putting a token in there to try to use local authentication.  The server just never picks it up.
> The documentation specifically mentions that <local/> should work along with <ldap/> here:
> https://docs.jboss.org/author/display/WFLY8/Security+Realms

--
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

From issues at jboss.org  Mon Mar  3 06:56:47 2014
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Mon, 3 Mar 2014 06:56:47 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3051) JMX connection to remote
 server-instances is not happening in wildfly 8.0.0.Final in domain mode
In-Reply-To: <JIRA.12533723.1393825342000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12533723.1393825342000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12533723.1393825342000.31803.1393847807939@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-3051?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse reassigned WFLY-3051:
--------------------------------------

    Assignee: Darran Lofthouse  (was: Kabir Khan)

    
> JMX connection to remote server-instances is not happening in wildfly 8.0.0.Final in domain mode
> ------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-3051
>                 URL: https://issues.jboss.org/browse/WFLY-3051
>             Project: WildFly
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: JMX, Remoting
>            Reporter: Rituraj Sinha
>            Assignee: Darran Lofthouse
>            Priority: Critical
>
> i have gone through the below link for JMX subsystem for wildfly 8 as
> https://docs.jboss.org/author/display/WFLY8/JMX+subsystem+configuration
>  
> but unable to connect to server-instances running remotely ...i have posted my question there as well and pasting it here now ...
> can someone please give us the steps to configure JMX through jconsole...?
> changes done on the domain.xml are the same as stated above
> <subsystem xmlns="urn:jboss:domain:jmx:1.3">
>                 <expose-resolved-model/>
>                 <expose-expression-model/>
>                 <remoting-connector use-management-endpoint="false"/>
>             </subsystem>
> <subsystem xmlns="urn:jboss:domain:jmx:1.3">
>                 <expose-resolved-model/>
>                 <expose-expression-model/>
>                 <remoting-connector use-management-endpoint="false"/>
>             </subsystem>
> as per the jboss-as-jmx_1_3.xsd  its like
> <xs:attribute name="use-management-endpoint" type="xs:boolean" default="true" use="optional" >
>             <xs:annotation>
>                 <xs:documentation>
>                     If true then this connector will use the management endpoint, otherwise it will use the
>                     remoting subsystem endpoint.
>                 </xs:documentation>
>             </xs:annotation>
>         </xs:attribute>
> now if we are making it false then it should be using the remoting endpoint ...now remoting subsystem by default uses ApplicatoinRealm
> i have created application-user and password for the same but when i am trying to connect to remote server-instances its not connecting it....
> below is what i am able to connect to 
> service:jmx:http-remoting-jmx://remote_hostA:9990 --
> Unknown macro: {host A is where my domain_controller is running}
> how can i access the server-instances running on domain_controller
> Unknown macro: {there are three server_instanaces running on HostA with a port offset of 100 each}
> i am trying to connect with the below url as 
> service:jmx:http-remoting-jmx://lremote_hostA:8180
> let me know if something is missing from my side...
> Thanks

--
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

From issues at jboss.org  Mon Mar  3 06:56:48 2014
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Mon, 3 Mar 2014 06:56:48 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3051) JMX connection to remote
 server-instances is not happening in wildfly 8.0.0.Final in domain mode
In-Reply-To: <JIRA.12533723.1393825342000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12533723.1393825342000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12533723.1393825342000.31807.1393847808156@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-3051?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated WFLY-3051:
-----------------------------------

    Priority: Major  (was: Critical)

    
> JMX connection to remote server-instances is not happening in wildfly 8.0.0.Final in domain mode
> ------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-3051
>                 URL: https://issues.jboss.org/browse/WFLY-3051
>             Project: WildFly
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: JMX, Remoting
>            Reporter: Rituraj Sinha
>            Assignee: Darran Lofthouse
>
> i have gone through the below link for JMX subsystem for wildfly 8 as
> https://docs.jboss.org/author/display/WFLY8/JMX+subsystem+configuration
>  
> but unable to connect to server-instances running remotely ...i have posted my question there as well and pasting it here now ...
> can someone please give us the steps to configure JMX through jconsole...?
> changes done on the domain.xml are the same as stated above
> <subsystem xmlns="urn:jboss:domain:jmx:1.3">
>                 <expose-resolved-model/>
>                 <expose-expression-model/>
>                 <remoting-connector use-management-endpoint="false"/>
>             </subsystem>
> <subsystem xmlns="urn:jboss:domain:jmx:1.3">
>                 <expose-resolved-model/>
>                 <expose-expression-model/>
>                 <remoting-connector use-management-endpoint="false"/>
>             </subsystem>
> as per the jboss-as-jmx_1_3.xsd  its like
> <xs:attribute name="use-management-endpoint" type="xs:boolean" default="true" use="optional" >
>             <xs:annotation>
>                 <xs:documentation>
>                     If true then this connector will use the management endpoint, otherwise it will use the
>                     remoting subsystem endpoint.
>                 </xs:documentation>
>             </xs:annotation>
>         </xs:attribute>
> now if we are making it false then it should be using the remoting endpoint ...now remoting subsystem by default uses ApplicatoinRealm
> i have created application-user and password for the same but when i am trying to connect to remote server-instances its not connecting it....
> below is what i am able to connect to 
> service:jmx:http-remoting-jmx://remote_hostA:9990 --
> Unknown macro: {host A is where my domain_controller is running}
> how can i access the server-instances running on domain_controller
> Unknown macro: {there are three server_instanaces running on HostA with a port offset of 100 each}
> i am trying to connect with the below url as 
> service:jmx:http-remoting-jmx://lremote_hostA:8180
> let me know if something is missing from my side...
> Thanks

--
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

From issues at jboss.org  Mon Mar  3 06:56:48 2014
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Mon, 3 Mar 2014 06:56:48 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3051) JMX connection to remote
 server-instances is not happening in wildfly 8.0.0.Final in domain mode
In-Reply-To: <JIRA.12533723.1393825342000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12533723.1393825342000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12533723.1393825342000.31811.1393847808368@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-3051?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated WFLY-3051:
-----------------------------------

    Affects Version/s: 8.0.0.Final

    
> JMX connection to remote server-instances is not happening in wildfly 8.0.0.Final in domain mode
> ------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-3051
>                 URL: https://issues.jboss.org/browse/WFLY-3051
>             Project: WildFly
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: JMX, Remoting
>    Affects Versions: 8.0.0.Final
>            Reporter: Rituraj Sinha
>            Assignee: Darran Lofthouse
>
> i have gone through the below link for JMX subsystem for wildfly 8 as
> https://docs.jboss.org/author/display/WFLY8/JMX+subsystem+configuration
>  
> but unable to connect to server-instances running remotely ...i have posted my question there as well and pasting it here now ...
> can someone please give us the steps to configure JMX through jconsole...?
> changes done on the domain.xml are the same as stated above
> <subsystem xmlns="urn:jboss:domain:jmx:1.3">
>                 <expose-resolved-model/>
>                 <expose-expression-model/>
>                 <remoting-connector use-management-endpoint="false"/>
>             </subsystem>
> <subsystem xmlns="urn:jboss:domain:jmx:1.3">
>                 <expose-resolved-model/>
>                 <expose-expression-model/>
>                 <remoting-connector use-management-endpoint="false"/>
>             </subsystem>
> as per the jboss-as-jmx_1_3.xsd  its like
> <xs:attribute name="use-management-endpoint" type="xs:boolean" default="true" use="optional" >
>             <xs:annotation>
>                 <xs:documentation>
>                     If true then this connector will use the management endpoint, otherwise it will use the
>                     remoting subsystem endpoint.
>                 </xs:documentation>
>             </xs:annotation>
>         </xs:attribute>
> now if we are making it false then it should be using the remoting endpoint ...now remoting subsystem by default uses ApplicatoinRealm
> i have created application-user and password for the same but when i am trying to connect to remote server-instances its not connecting it....
> below is what i am able to connect to 
> service:jmx:http-remoting-jmx://remote_hostA:9990 --
> Unknown macro: {host A is where my domain_controller is running}
> how can i access the server-instances running on domain_controller
> Unknown macro: {there are three server_instanaces running on HostA with a port offset of 100 each}
> i am trying to connect with the below url as 
> service:jmx:http-remoting-jmx://lremote_hostA:8180
> let me know if something is missing from my side...
> Thanks

--
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

From issues at jboss.org  Mon Mar  3 06:56:48 2014
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Mon, 3 Mar 2014 06:56:48 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3051) JMX connection to remote
 server-instances is not happening in wildfly 8.0.0.Final in domain mode
In-Reply-To: <JIRA.12533723.1393825342000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12533723.1393825342000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12533723.1393825342000.31814.1393847808565@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-3051?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated WFLY-3051:
-----------------------------------

    Fix Version/s: 8.0.1.Final

    
> JMX connection to remote server-instances is not happening in wildfly 8.0.0.Final in domain mode
> ------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-3051
>                 URL: https://issues.jboss.org/browse/WFLY-3051
>             Project: WildFly
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: JMX, Remoting
>    Affects Versions: 8.0.0.Final
>            Reporter: Rituraj Sinha
>            Assignee: Darran Lofthouse
>             Fix For: 8.0.1.Final
>
>
> i have gone through the below link for JMX subsystem for wildfly 8 as
> https://docs.jboss.org/author/display/WFLY8/JMX+subsystem+configuration
>  
> but unable to connect to server-instances running remotely ...i have posted my question there as well and pasting it here now ...
> can someone please give us the steps to configure JMX through jconsole...?
> changes done on the domain.xml are the same as stated above
> <subsystem xmlns="urn:jboss:domain:jmx:1.3">
>                 <expose-resolved-model/>
>                 <expose-expression-model/>
>                 <remoting-connector use-management-endpoint="false"/>
>             </subsystem>
> <subsystem xmlns="urn:jboss:domain:jmx:1.3">
>                 <expose-resolved-model/>
>                 <expose-expression-model/>
>                 <remoting-connector use-management-endpoint="false"/>
>             </subsystem>
> as per the jboss-as-jmx_1_3.xsd  its like
> <xs:attribute name="use-management-endpoint" type="xs:boolean" default="true" use="optional" >
>             <xs:annotation>
>                 <xs:documentation>
>                     If true then this connector will use the management endpoint, otherwise it will use the
>                     remoting subsystem endpoint.
>                 </xs:documentation>
>             </xs:annotation>
>         </xs:attribute>
> now if we are making it false then it should be using the remoting endpoint ...now remoting subsystem by default uses ApplicatoinRealm
> i have created application-user and password for the same but when i am trying to connect to remote server-instances its not connecting it....
> below is what i am able to connect to 
> service:jmx:http-remoting-jmx://remote_hostA:9990 --
> Unknown macro: {host A is where my domain_controller is running}
> how can i access the server-instances running on domain_controller
> Unknown macro: {there are three server_instanaces running on HostA with a port offset of 100 each}
> i am trying to connect with the below url as 
> service:jmx:http-remoting-jmx://lremote_hostA:8180
> let me know if something is missing from my side...
> Thanks

--
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

From issues at jboss.org  Mon Mar  3 07:10:49 2014
From: issues at jboss.org (Rituraj Sinha (JIRA))
Date: Mon, 3 Mar 2014 07:10:49 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3051) JMX connection to remote
 server-instances is not happening in wildfly 8.0.0.Final in domain mode
In-Reply-To: <JIRA.12533723.1393825342000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12533723.1393825342000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12533723.1393825342000.31837.1393848649041@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-3051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12949312#comment-12949312 ] 

Rituraj Sinha commented on WFLY-3051:
-------------------------------------

HI Darran,

Let me know if you need any info from my side ....

Thanks
RIturaj 
                
> JMX connection to remote server-instances is not happening in wildfly 8.0.0.Final in domain mode
> ------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-3051
>                 URL: https://issues.jboss.org/browse/WFLY-3051
>             Project: WildFly
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: JMX, Remoting
>    Affects Versions: 8.0.0.Final
>            Reporter: Rituraj Sinha
>            Assignee: Darran Lofthouse
>             Fix For: 8.0.1.Final
>
>
> i have gone through the below link for JMX subsystem for wildfly 8 as
> https://docs.jboss.org/author/display/WFLY8/JMX+subsystem+configuration
>  
> but unable to connect to server-instances running remotely ...i have posted my question there as well and pasting it here now ...
> can someone please give us the steps to configure JMX through jconsole...?
> changes done on the domain.xml are the same as stated above
> <subsystem xmlns="urn:jboss:domain:jmx:1.3">
>                 <expose-resolved-model/>
>                 <expose-expression-model/>
>                 <remoting-connector use-management-endpoint="false"/>
>             </subsystem>
> <subsystem xmlns="urn:jboss:domain:jmx:1.3">
>                 <expose-resolved-model/>
>                 <expose-expression-model/>
>                 <remoting-connector use-management-endpoint="false"/>
>             </subsystem>
> as per the jboss-as-jmx_1_3.xsd  its like
> <xs:attribute name="use-management-endpoint" type="xs:boolean" default="true" use="optional" >
>             <xs:annotation>
>                 <xs:documentation>
>                     If true then this connector will use the management endpoint, otherwise it will use the
>                     remoting subsystem endpoint.
>                 </xs:documentation>
>             </xs:annotation>
>         </xs:attribute>
> now if we are making it false then it should be using the remoting endpoint ...now remoting subsystem by default uses ApplicatoinRealm
> i have created application-user and password for the same but when i am trying to connect to remote server-instances its not connecting it....
> below is what i am able to connect to 
> service:jmx:http-remoting-jmx://remote_hostA:9990 --
> Unknown macro: {host A is where my domain_controller is running}
> how can i access the server-instances running on domain_controller
> Unknown macro: {there are three server_instanaces running on HostA with a port offset of 100 each}
> i am trying to connect with the below url as 
> service:jmx:http-remoting-jmx://lremote_hostA:8180
> let me know if something is missing from my side...
> Thanks

--
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

From issues at jboss.org  Mon Mar  3 07:20:47 2014
From: issues at jboss.org (Rituraj Sinha (JIRA))
Date: Mon, 3 Mar 2014 07:20:47 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3051) JMX connection to remote
 server-instances is not happening in wildfly 8.0.0.Final in domain mode
In-Reply-To: <JIRA.12533723.1393825342000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12533723.1393825342000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12533723.1393825342000.31883.1393849247700@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-3051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12949318#comment-12949318 ] 

Rituraj Sinha commented on WFLY-3051:
-------------------------------------

Hi Darran,

let me know if you need any info from my side ...

Thanks for looking into the issue...

-Rituraj
                
> JMX connection to remote server-instances is not happening in wildfly 8.0.0.Final in domain mode
> ------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-3051
>                 URL: https://issues.jboss.org/browse/WFLY-3051
>             Project: WildFly
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: JMX, Remoting
>    Affects Versions: 8.0.0.Final
>            Reporter: Rituraj Sinha
>            Assignee: Darran Lofthouse
>             Fix For: 8.0.1.Final
>
>
> i have gone through the below link for JMX subsystem for wildfly 8 as
> https://docs.jboss.org/author/display/WFLY8/JMX+subsystem+configuration
>  
> but unable to connect to server-instances running remotely ...i have posted my question there as well and pasting it here now ...
> can someone please give us the steps to configure JMX through jconsole...?
> changes done on the domain.xml are the same as stated above
> <subsystem xmlns="urn:jboss:domain:jmx:1.3">
>                 <expose-resolved-model/>
>                 <expose-expression-model/>
>                 <remoting-connector use-management-endpoint="false"/>
>             </subsystem>
> <subsystem xmlns="urn:jboss:domain:jmx:1.3">
>                 <expose-resolved-model/>
>                 <expose-expression-model/>
>                 <remoting-connector use-management-endpoint="false"/>
>             </subsystem>
> as per the jboss-as-jmx_1_3.xsd  its like
> <xs:attribute name="use-management-endpoint" type="xs:boolean" default="true" use="optional" >
>             <xs:annotation>
>                 <xs:documentation>
>                     If true then this connector will use the management endpoint, otherwise it will use the
>                     remoting subsystem endpoint.
>                 </xs:documentation>
>             </xs:annotation>
>         </xs:attribute>
> now if we are making it false then it should be using the remoting endpoint ...now remoting subsystem by default uses ApplicatoinRealm
> i have created application-user and password for the same but when i am trying to connect to remote server-instances its not connecting it....
> below is what i am able to connect to 
> service:jmx:http-remoting-jmx://remote_hostA:9990 --
> Unknown macro: {host A is where my domain_controller is running}
> how can i access the server-instances running on domain_controller
> Unknown macro: {there are three server_instanaces running on HostA with a port offset of 100 each}
> i am trying to connect with the below url as 
> service:jmx:http-remoting-jmx://lremote_hostA:8180
> let me know if something is missing from my side...
> Thanks

--
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

From issues at jboss.org  Mon Mar  3 07:44:49 2014
From: issues at jboss.org (Rituraj Sinha (JIRA))
Date: Mon, 3 Mar 2014 07:44:49 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3051) JMX connection to remote
 server-instances is not happening in wildfly 8.0.0.Final in domain mode
In-Reply-To: <JIRA.12533723.1393825342000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12533723.1393825342000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12533723.1393825342000.31897.1393850689072@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-3051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12949320#comment-12949320 ] 

Rituraj Sinha commented on WFLY-3051:
-------------------------------------

Hi Darran,

Thanks for looking into the issue ....i am not 
Able to comment on Jira ....may be perms required ...

So is this going to be resolved in 

Sent from my iPhone


                
> JMX connection to remote server-instances is not happening in wildfly 8.0.0.Final in domain mode
> ------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-3051
>                 URL: https://issues.jboss.org/browse/WFLY-3051
>             Project: WildFly
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: JMX, Remoting
>    Affects Versions: 8.0.0.Final
>            Reporter: Rituraj Sinha
>            Assignee: Darran Lofthouse
>             Fix For: 8.0.1.Final
>
>
> i have gone through the below link for JMX subsystem for wildfly 8 as
> https://docs.jboss.org/author/display/WFLY8/JMX+subsystem+configuration
>  
> but unable to connect to server-instances running remotely ...i have posted my question there as well and pasting it here now ...
> can someone please give us the steps to configure JMX through jconsole...?
> changes done on the domain.xml are the same as stated above
> <subsystem xmlns="urn:jboss:domain:jmx:1.3">
>                 <expose-resolved-model/>
>                 <expose-expression-model/>
>                 <remoting-connector use-management-endpoint="false"/>
>             </subsystem>
> <subsystem xmlns="urn:jboss:domain:jmx:1.3">
>                 <expose-resolved-model/>
>                 <expose-expression-model/>
>                 <remoting-connector use-management-endpoint="false"/>
>             </subsystem>
> as per the jboss-as-jmx_1_3.xsd  its like
> <xs:attribute name="use-management-endpoint" type="xs:boolean" default="true" use="optional" >
>             <xs:annotation>
>                 <xs:documentation>
>                     If true then this connector will use the management endpoint, otherwise it will use the
>                     remoting subsystem endpoint.
>                 </xs:documentation>
>             </xs:annotation>
>         </xs:attribute>
> now if we are making it false then it should be using the remoting endpoint ...now remoting subsystem by default uses ApplicatoinRealm
> i have created application-user and password for the same but when i am trying to connect to remote server-instances its not connecting it....
> below is what i am able to connect to 
> service:jmx:http-remoting-jmx://remote_hostA:9990 --
> Unknown macro: {host A is where my domain_controller is running}
> how can i access the server-instances running on domain_controller
> Unknown macro: {there are three server_instanaces running on HostA with a port offset of 100 each}
> i am trying to connect with the below url as 
> service:jmx:http-remoting-jmx://lremote_hostA:8180
> let me know if something is missing from my side...
> Thanks

--
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

From issues at jboss.org  Mon Mar  3 08:24:48 2014
From: issues at jboss.org (Jesper Pedersen (JIRA))
Date: Mon, 3 Mar 2014 08:24:48 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JBJCA-1146) Optimize removal in
 TransactionSynchronizer
In-Reply-To: <JIRA.12533762.1393853035674@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12533762.1393853035674@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12533762.1393853035674.31966.1393853088372@jira02.app.mwc.hst.phx2.redhat.com>

Jesper Pedersen created JBJCA-1146:
--------------------------------------

             Summary: Optimize removal in TransactionSynchronizer
                 Key: JBJCA-1146
                 URL: https://issues.jboss.org/browse/JBJCA-1146
             Project: IronJacamar
          Issue Type: Task
          Components: Core
            Reporter: Jesper Pedersen
            Assignee: Jesper Pedersen
             Fix For: 1.0.24.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

From issues at jboss.org  Mon Mar  3 08:28:48 2014
From: issues at jboss.org (Radoslav Husar (JIRA))
Date: Mon, 3 Mar 2014 08:28:48 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2519) Useless mod_cluster drained
 context logging (...UndertowContext@3abb2fbc)
In-Reply-To: <JIRA.12525341.1384536214000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12525341.1384536214000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12525341.1384536214000.31983.1393853328004@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2519?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Radoslav Husar closed WFLY-2519.
--------------------------------


    
> Useless mod_cluster drained context logging (...UndertowContext at 3abb2fbc)
> -------------------------------------------------------------------------
>
>                 Key: WFLY-2519
>                 URL: https://issues.jboss.org/browse/WFLY-2519
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Clustering
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Radoslav Husar
>            Assignee: Radoslav Husar
>            Priority: Minor
>             Fix For: 8.0.0.CR1
>
>
> {noformat}18:21:17,409 INFO  [org.jboss.modcluster] (MSC service thread 1-8) MODCLUSTER000021: All pending requests drained from default-host:org.wildfly.mod_cluster.undertow.UndertowContext at 3abb2fbc in 0.0 seconds
> {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

From issues at jboss.org  Mon Mar  3 08:28:48 2014
From: issues at jboss.org (Radoslav Husar (JIRA))
Date: Mon, 3 Mar 2014 08:28:48 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2171) Use deployment unit
 processors to register mod_cluster metrics
In-Reply-To: <JIRA.12501718.1380276630000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501718.1380276630000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501718.1380276630000.31988.1393853328253@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2171?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Radoslav Husar closed WFLY-2171.
--------------------------------


    
> Use deployment unit processors to register mod_cluster metrics
> --------------------------------------------------------------
>
>                 Key: WFLY-2171
>                 URL: https://issues.jboss.org/browse/WFLY-2171
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Clustering
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Radoslav Husar
>            Assignee: Radoslav Husar
>            Priority: Blocker
>             Fix For: 8.0.0.Final
>
>
> Remove static dependency and make it runtime using DUPs.

--
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

From issues at jboss.org  Mon Mar  3 08:30:48 2014
From: issues at jboss.org (Jesper Pedersen (JIRA))
Date: Mon, 3 Mar 2014 08:30:48 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JBJCA-1146) Optimize removal in
 TransactionSynchronizer
In-Reply-To: <JIRA.12533762.1393853035000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12533762.1393853035000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12533762.1393853035000.31999.1393853448009@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBJCA-1146?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jesper Pedersen resolved JBJCA-1146.
------------------------------------

    Resolution: Done

    
> Optimize removal in TransactionSynchronizer
> -------------------------------------------
>
>                 Key: JBJCA-1146
>                 URL: https://issues.jboss.org/browse/JBJCA-1146
>             Project: IronJacamar
>          Issue Type: Task
>          Components: Core
>            Reporter: Jesper Pedersen
>            Assignee: Jesper Pedersen
>             Fix For: 1.0.24.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

From issues at jboss.org  Mon Mar  3 08:34:47 2014
From: issues at jboss.org (Jesper Pedersen (JIRA))
Date: Mon, 3 Mar 2014 08:34:47 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JBJCA-1141) Allow 'connectable' to be
 configured per deployment
In-Reply-To: <JIRA.12533504.1393511459000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12533504.1393511459000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12533504.1393511459000.32004.1393853687660@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBJCA-1141?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jesper Pedersen resolved JBJCA-1141.
------------------------------------

    Resolution: Done

    
> Allow 'connectable' to be configured per deployment
> ---------------------------------------------------
>
>                 Key: JBJCA-1141
>                 URL: https://issues.jboss.org/browse/JBJCA-1141
>             Project: IronJacamar
>          Issue Type: Task
>          Components: Common, Core, Deployer
>            Reporter: Jesper Pedersen
>            Assignee: Jesper Pedersen
>             Fix For: 1.0.24.Final, 1.2.0.Beta1
>
>


--
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

From issues at jboss.org  Mon Mar  3 08:38:47 2014
From: issues at jboss.org (Jesper Pedersen (JIRA))
Date: Mon, 3 Mar 2014 08:38:47 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JBJCA-1147) Modify permits under lock
In-Reply-To: <JIRA.12533764.1393853823560@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12533764.1393853823560@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12533764.1393853823560.32009.1393853927835@jira02.app.mwc.hst.phx2.redhat.com>

Jesper Pedersen created JBJCA-1147:
--------------------------------------

             Summary: Modify permits under lock
                 Key: JBJCA-1147
                 URL: https://issues.jboss.org/browse/JBJCA-1147
             Project: IronJacamar
          Issue Type: Bug
          Components: Core
    Affects Versions: 1.1.3.Final
            Reporter: Jesper Pedersen
            Assignee: Jesper Pedersen
            Priority: Critical
             Fix For: 1.1.4.Final, 1.2.0.Beta1


The permits needs to be locked when releasing a permit in SemaphoreArrayListManagedConnectionPool

--
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

From issues at jboss.org  Mon Mar  3 08:38:48 2014
From: issues at jboss.org (Richard Achmatowicz (JIRA))
Date: Mon, 3 Mar 2014 08:38:48 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1801) DuplicateTest fails when
 testing OOB multicast to all three senders
In-Reply-To: <JIRA.12533765.1393853856000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12533765.1393853856000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12533765.1393853856000.32015.1393853928870@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JGRP-1801?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Richard Achmatowicz updated JGRP-1801:
--------------------------------------

    Description: 
DuplicateTest does the following:
- creates three channels containing the DUPL layer called c1, c2, c3
- DUPL is used to duplicate messages sent
- channel receiver for channel each keeps a map of messages received from each sender
- channels send messages: regular, OOB, or mixed
- the test checks that the messages received  by each channel are correct in number and in order

The test testOOBMuloticastToAll3Senders is failing regularly on multple platforms. The test makes each of the channels send OOB multicast messages to the group, but only two of three members ever end up receiving the multicast messages. Al example of the failure:

{noformat}
Error Message
expected size=3, msgs: [C2, C1]

Stacktrace
java.lang.AssertionError 
at org.jgroups.tests.DuplicateTest.check(DuplicateTest.java:217) 
at org.jgroups.tests.DuplicateTest.testOOBMulticastToAll3Senders(DuplicateTest.java:123) 
{noformat} 


  was:
DuplicateTest does the following:
- creates three channels containing the DUPL layer called c1, c2, c3 (DUPL is used to duplicate messages sent)
- channel receiver for each keeps a map of messages received from each sender
- channels send messages: regular, OOB, or mixed
- the test checks that the messages received  by each channel are correct in number and in order

The test testOOBMuloticastToAll3Senders is failing regularly on multple platforms. The test makes each of the channels send OOB multicast messages to the group, but only two of three members ever end up receiving the multicast messages. Al example of the failure:

{noformat}
Error Message
expected size=3, msgs: [C2, C1]

Stacktrace
java.lang.AssertionError 
at org.jgroups.tests.DuplicateTest.check(DuplicateTest.java:217) 
at org.jgroups.tests.DuplicateTest.testOOBMulticastToAll3Senders(DuplicateTest.java:123) 
{noformat} 



    
> DuplicateTest fails when testing OOB multicast to all three senders
> -------------------------------------------------------------------
>
>                 Key: JGRP-1801
>                 URL: https://issues.jboss.org/browse/JGRP-1801
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.2.13
>         Environment: Windows (18), Solaris (2), RHEL(1) where (x) is the number of failures seen
>            Reporter: Richard Achmatowicz
>            Assignee: Bela Ban
>             Fix For: 3.2.13
>
>
> DuplicateTest does the following:
> - creates three channels containing the DUPL layer called c1, c2, c3
> - DUPL is used to duplicate messages sent
> - channel receiver for channel each keeps a map of messages received from each sender
> - channels send messages: regular, OOB, or mixed
> - the test checks that the messages received  by each channel are correct in number and in order
> The test testOOBMuloticastToAll3Senders is failing regularly on multple platforms. The test makes each of the channels send OOB multicast messages to the group, but only two of three members ever end up receiving the multicast messages. Al example of the failure:
> {noformat}
> Error Message
> expected size=3, msgs: [C2, C1]
> Stacktrace
> java.lang.AssertionError 
> at org.jgroups.tests.DuplicateTest.check(DuplicateTest.java:217) 
> at org.jgroups.tests.DuplicateTest.testOOBMulticastToAll3Senders(DuplicateTest.java:123) 
> {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

From issues at jboss.org  Mon Mar  3 08:38:48 2014
From: issues at jboss.org (Richard Achmatowicz (JIRA))
Date: Mon, 3 Mar 2014 08:38:48 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1801) DuplicateTest fails when
 testing OOB multicast to all three senders
In-Reply-To: <JIRA.12533765.1393853856493@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12533765.1393853856493@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12533765.1393853856493.32012.1393853928407@jira02.app.mwc.hst.phx2.redhat.com>

Richard Achmatowicz created JGRP-1801:
-----------------------------------------

             Summary: DuplicateTest fails when testing OOB multicast to all three senders
                 Key: JGRP-1801
                 URL: https://issues.jboss.org/browse/JGRP-1801
             Project: JGroups
          Issue Type: Bug
    Affects Versions: 3.2.13
         Environment: Windows (18), Solaris (2), RHEL(1) where (x) is the number of failures seen
            Reporter: Richard Achmatowicz
            Assignee: Bela Ban
             Fix For: 3.2.13


DuplicateTest does the following:
- creates three channels containing the DUPL layer called c1, c2, c3 (DUPL is used to duplicate messages sent)
- channel receiver for each keeps a map of messages received from each sender
- channels send messages: regular, OOB, or mixed
- the test checks that the messages received  by each channel are correct in number and in order

The test testOOBMuloticastToAll3Senders is failing regularly on multple platforms. The test makes each of the channels send OOB multicast messages to the group, but only two of three members ever end up receiving the multicast messages. Al example of the failure:

{noformat}
Error Message
expected size=3, msgs: [C2, C1]

Stacktrace
java.lang.AssertionError 
at org.jgroups.tests.DuplicateTest.check(DuplicateTest.java:217) 
at org.jgroups.tests.DuplicateTest.testOOBMulticastToAll3Senders(DuplicateTest.java:123) 
{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

From issues at jboss.org  Mon Mar  3 08:40:47 2014
From: issues at jboss.org (Richard Achmatowicz (JIRA))
Date: Mon, 3 Mar 2014 08:40:47 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1801) DuplicateTest fails when
 testing OOB multicast to all three senders
In-Reply-To: <JIRA.12533765.1393853856000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12533765.1393853856000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12533765.1393853856000.32019.1393854047692@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JGRP-1801?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12949334#comment-12949334 ] 

Richard Achmatowicz commented on JGRP-1801:
-------------------------------------------

For an example of the failure: https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/EAP6/view/EAP6-JGroups/job/jgroups-Win-matrix-branch-3_2/
                
> DuplicateTest fails when testing OOB multicast to all three senders
> -------------------------------------------------------------------
>
>                 Key: JGRP-1801
>                 URL: https://issues.jboss.org/browse/JGRP-1801
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.2.13
>         Environment: Windows (18), Solaris (2), RHEL(1) where (x) is the number of failures seen
>            Reporter: Richard Achmatowicz
>            Assignee: Bela Ban
>             Fix For: 3.2.13
>
>
> DuplicateTest does the following:
> - creates three channels containing the DUPL layer called c1, c2, c3
> - DUPL is used to duplicate messages sent
> - channel receiver for channel each keeps a map of messages received from each sender
> - channels send messages: regular, OOB, or mixed
> - the test checks that the messages received  by each channel are correct in number and in order
> The test testOOBMuloticastToAll3Senders is failing regularly on multple platforms. The test makes each of the channels send OOB multicast messages to the group, but only two of three members ever end up receiving the multicast messages. Al example of the failure:
> {noformat}
> Error Message
> expected size=3, msgs: [C2, C1]
> Stacktrace
> java.lang.AssertionError 
> at org.jgroups.tests.DuplicateTest.check(DuplicateTest.java:217) 
> at org.jgroups.tests.DuplicateTest.testOOBMulticastToAll3Senders(DuplicateTest.java:123) 
> {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

From issues at jboss.org  Mon Mar  3 08:46:49 2014
From: issues at jboss.org (Jesper Pedersen (JIRA))
Date: Mon, 3 Mar 2014 08:46:49 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JBJCA-1147) Modify permits under lock
In-Reply-To: <JIRA.12533764.1393853823000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12533764.1393853823000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12533764.1393853823000.32027.1393854409152@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBJCA-1147?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jesper Pedersen resolved JBJCA-1147.
------------------------------------

    Resolution: Done

    
> Modify permits under lock
> -------------------------
>
>                 Key: JBJCA-1147
>                 URL: https://issues.jboss.org/browse/JBJCA-1147
>             Project: IronJacamar
>          Issue Type: Bug
>          Components: Core
>    Affects Versions: 1.1.3.Final
>            Reporter: Jesper Pedersen
>            Assignee: Jesper Pedersen
>            Priority: Critical
>             Fix For: 1.1.4.Final, 1.2.0.Beta1
>
>
> The permits needs to be locked when releasing a permit in SemaphoreArrayListManagedConnectionPool

--
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

From issues at jboss.org  Mon Mar  3 08:50:49 2014
From: issues at jboss.org (Rituraj Sinha (JIRA))
Date: Mon, 3 Mar 2014 08:50:49 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3051) JMX connection to remote
 server-instances is not happening in wildfly 8.0.0.Final in domain mode
In-Reply-To: <JIRA.12533723.1393825342000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12533723.1393825342000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12533723.1393825342000.32042.1393854649471@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-3051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12949320#comment-12949320 ] 

Rituraj Sinha edited comment on WFLY-3051 at 3/3/14 8:50 AM:
-------------------------------------------------------------

Hi Darran,

it looks like this issue is going to be there in willdfly 8.0.0.Final....do we have any workaround for this ...??

Thanks
Rituraj


                
      was (Author: rituraj):
    Hi Darran,

Thanks for looking into the issue ....i am not 
Able to comment on Jira ....may be perms required ...

So is this going to be resolved in 

Sent from my iPhone


                  
> JMX connection to remote server-instances is not happening in wildfly 8.0.0.Final in domain mode
> ------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-3051
>                 URL: https://issues.jboss.org/browse/WFLY-3051
>             Project: WildFly
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: JMX, Remoting
>    Affects Versions: 8.0.0.Final
>            Reporter: Rituraj Sinha
>            Assignee: Darran Lofthouse
>             Fix For: 8.0.1.Final
>
>
> i have gone through the below link for JMX subsystem for wildfly 8 as
> https://docs.jboss.org/author/display/WFLY8/JMX+subsystem+configuration
>  
> but unable to connect to server-instances running remotely ...i have posted my question there as well and pasting it here now ...
> can someone please give us the steps to configure JMX through jconsole...?
> changes done on the domain.xml are the same as stated above
> <subsystem xmlns="urn:jboss:domain:jmx:1.3">
>                 <expose-resolved-model/>
>                 <expose-expression-model/>
>                 <remoting-connector use-management-endpoint="false"/>
>             </subsystem>
> <subsystem xmlns="urn:jboss:domain:jmx:1.3">
>                 <expose-resolved-model/>
>                 <expose-expression-model/>
>                 <remoting-connector use-management-endpoint="false"/>
>             </subsystem>
> as per the jboss-as-jmx_1_3.xsd  its like
> <xs:attribute name="use-management-endpoint" type="xs:boolean" default="true" use="optional" >
>             <xs:annotation>
>                 <xs:documentation>
>                     If true then this connector will use the management endpoint, otherwise it will use the
>                     remoting subsystem endpoint.
>                 </xs:documentation>
>             </xs:annotation>
>         </xs:attribute>
> now if we are making it false then it should be using the remoting endpoint ...now remoting subsystem by default uses ApplicatoinRealm
> i have created application-user and password for the same but when i am trying to connect to remote server-instances its not connecting it....
> below is what i am able to connect to 
> service:jmx:http-remoting-jmx://remote_hostA:9990 --
> Unknown macro: {host A is where my domain_controller is running}
> how can i access the server-instances running on domain_controller
> Unknown macro: {there are three server_instanaces running on HostA with a port offset of 100 each}
> i am trying to connect with the below url as 
> service:jmx:http-remoting-jmx://lremote_hostA:8180
> let me know if something is missing from my side...
> Thanks

--
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

From issues at jboss.org  Mon Mar  3 08:50:49 2014
From: issues at jboss.org (Bela Ban (JIRA))
Date: Mon, 3 Mar 2014 08:50:49 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1801) DuplicateTest fails when
 testing OOB multicast to all three senders
In-Reply-To: <JIRA.12533765.1393853856000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12533765.1393853856000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12533765.1393853856000.32047.1393854649858@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JGRP-1801?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban updated JGRP-1801:
---------------------------

    Fix Version/s: 3.5

    
> DuplicateTest fails when testing OOB multicast to all three senders
> -------------------------------------------------------------------
>
>                 Key: JGRP-1801
>                 URL: https://issues.jboss.org/browse/JGRP-1801
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.2.13
>         Environment: Windows (18), Solaris (2), RHEL(1) where (x) is the number of failures seen
>            Reporter: Richard Achmatowicz
>            Assignee: Bela Ban
>             Fix For: 3.2.13, 3.5
>
>
> DuplicateTest does the following:
> - creates three channels containing the DUPL layer called c1, c2, c3
> - DUPL is used to duplicate messages sent
> - channel receiver for channel each keeps a map of messages received from each sender
> - channels send messages: regular, OOB, or mixed
> - the test checks that the messages received  by each channel are correct in number and in order
> The test testOOBMuloticastToAll3Senders is failing regularly on multple platforms. The test makes each of the channels send OOB multicast messages to the group, but only two of three members ever end up receiving the multicast messages. Al example of the failure:
> {noformat}
> Error Message
> expected size=3, msgs: [C2, C1]
> Stacktrace
> java.lang.AssertionError 
> at org.jgroups.tests.DuplicateTest.check(DuplicateTest.java:217) 
> at org.jgroups.tests.DuplicateTest.testOOBMulticastToAll3Senders(DuplicateTest.java:123) 
> {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

From issues at jboss.org  Mon Mar  3 08:52:47 2014
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Mon, 3 Mar 2014 08:52:47 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3051) JMX connection to remote
 server-instances is not happening in wildfly 8.0.0.Final in domain mode
In-Reply-To: <JIRA.12533723.1393825342000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12533723.1393825342000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12533723.1393825342000.32051.1393854767647@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-3051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12949340#comment-12949340 ] 

Darran Lofthouse commented on WFLY-3051:
----------------------------------------

I have scheduled this issue so that I can investigate it further, at this point I have no further information.
                
> JMX connection to remote server-instances is not happening in wildfly 8.0.0.Final in domain mode
> ------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-3051
>                 URL: https://issues.jboss.org/browse/WFLY-3051
>             Project: WildFly
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: JMX, Remoting
>    Affects Versions: 8.0.0.Final
>            Reporter: Rituraj Sinha
>            Assignee: Darran Lofthouse
>             Fix For: 8.0.1.Final
>
>
> i have gone through the below link for JMX subsystem for wildfly 8 as
> https://docs.jboss.org/author/display/WFLY8/JMX+subsystem+configuration
>  
> but unable to connect to server-instances running remotely ...i have posted my question there as well and pasting it here now ...
> can someone please give us the steps to configure JMX through jconsole...?
> changes done on the domain.xml are the same as stated above
> <subsystem xmlns="urn:jboss:domain:jmx:1.3">
>                 <expose-resolved-model/>
>                 <expose-expression-model/>
>                 <remoting-connector use-management-endpoint="false"/>
>             </subsystem>
> <subsystem xmlns="urn:jboss:domain:jmx:1.3">
>                 <expose-resolved-model/>
>                 <expose-expression-model/>
>                 <remoting-connector use-management-endpoint="false"/>
>             </subsystem>
> as per the jboss-as-jmx_1_3.xsd  its like
> <xs:attribute name="use-management-endpoint" type="xs:boolean" default="true" use="optional" >
>             <xs:annotation>
>                 <xs:documentation>
>                     If true then this connector will use the management endpoint, otherwise it will use the
>                     remoting subsystem endpoint.
>                 </xs:documentation>
>             </xs:annotation>
>         </xs:attribute>
> now if we are making it false then it should be using the remoting endpoint ...now remoting subsystem by default uses ApplicatoinRealm
> i have created application-user and password for the same but when i am trying to connect to remote server-instances its not connecting it....
> below is what i am able to connect to 
> service:jmx:http-remoting-jmx://remote_hostA:9990 --
> Unknown macro: {host A is where my domain_controller is running}
> how can i access the server-instances running on domain_controller
> Unknown macro: {there are three server_instanaces running on HostA with a port offset of 100 each}
> i am trying to connect with the below url as 
> service:jmx:http-remoting-jmx://lremote_hostA:8180
> let me know if something is missing from my side...
> Thanks

--
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

From issues at jboss.org  Mon Mar  3 09:02:48 2014
From: issues at jboss.org (Mircea Markus (JIRA))
Date: Mon, 3 Mar 2014 09:02:48 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1752) Concurrent message headers
 modification causes that message is never sent
In-Reply-To: <JIRA.12526753.1386075180000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12526753.1386075180000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12526753.1386075180000.32099.1393855368280@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JGRP-1752?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mircea Markus updated JGRP-1752:
--------------------------------

    Labels: 621  (was: )

    
> Concurrent message headers modification causes that message is never sent
> -------------------------------------------------------------------------
>
>                 Key: JGRP-1752
>                 URL: https://issues.jboss.org/browse/JGRP-1752
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.4.1
>            Reporter: Radim Vansa
>            Assignee: Bela Ban
>              Labels: 621
>             Fix For: 3.4.2, 3.5
>
>
> Under some circumstances the TP protocol may try to add the TP header to message twice concurrently.
> This happens for example when the stable message triggers retransmission while the message has been sent right now.
> This may result in ArrayOutOfBoundException in Headers._putHeader and/or subsequent NullPointerException in Headers.size(). The retransmission attempt always fails, the message is never delivered. Moreover, keeping this (and possibly following) messages in the transmission table can lead to OOME.

--
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

From issues at jboss.org  Mon Mar  3 09:04:50 2014
From: issues at jboss.org (Rituraj Sinha (JIRA))
Date: Mon, 3 Mar 2014 09:04:50 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3051) JMX connection to remote
 server-instances is not happening in wildfly 8.0.0.Final in domain mode
In-Reply-To: <JIRA.12533723.1393825342000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12533723.1393825342000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12533723.1393825342000.32102.1393855490880@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-3051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12949344#comment-12949344 ] 

Rituraj Sinha commented on WFLY-3051:
-------------------------------------

Thanks for replying Darran ...will wait for your response ...

                
> JMX connection to remote server-instances is not happening in wildfly 8.0.0.Final in domain mode
> ------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-3051
>                 URL: https://issues.jboss.org/browse/WFLY-3051
>             Project: WildFly
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: JMX, Remoting
>    Affects Versions: 8.0.0.Final
>            Reporter: Rituraj Sinha
>            Assignee: Darran Lofthouse
>             Fix For: 8.0.1.Final
>
>
> i have gone through the below link for JMX subsystem for wildfly 8 as
> https://docs.jboss.org/author/display/WFLY8/JMX+subsystem+configuration
>  
> but unable to connect to server-instances running remotely ...i have posted my question there as well and pasting it here now ...
> can someone please give us the steps to configure JMX through jconsole...?
> changes done on the domain.xml are the same as stated above
> <subsystem xmlns="urn:jboss:domain:jmx:1.3">
>                 <expose-resolved-model/>
>                 <expose-expression-model/>
>                 <remoting-connector use-management-endpoint="false"/>
>             </subsystem>
> <subsystem xmlns="urn:jboss:domain:jmx:1.3">
>                 <expose-resolved-model/>
>                 <expose-expression-model/>
>                 <remoting-connector use-management-endpoint="false"/>
>             </subsystem>
> as per the jboss-as-jmx_1_3.xsd  its like
> <xs:attribute name="use-management-endpoint" type="xs:boolean" default="true" use="optional" >
>             <xs:annotation>
>                 <xs:documentation>
>                     If true then this connector will use the management endpoint, otherwise it will use the
>                     remoting subsystem endpoint.
>                 </xs:documentation>
>             </xs:annotation>
>         </xs:attribute>
> now if we are making it false then it should be using the remoting endpoint ...now remoting subsystem by default uses ApplicatoinRealm
> i have created application-user and password for the same but when i am trying to connect to remote server-instances its not connecting it....
> below is what i am able to connect to 
> service:jmx:http-remoting-jmx://remote_hostA:9990 --
> Unknown macro: {host A is where my domain_controller is running}
> how can i access the server-instances running on domain_controller
> Unknown macro: {there are three server_instanaces running on HostA with a port offset of 100 each}
> i am trying to connect with the below url as 
> service:jmx:http-remoting-jmx://lremote_hostA:8180
> let me know if something is missing from my side...
> Thanks

--
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

From issues at jboss.org  Mon Mar  3 09:06:50 2014
From: issues at jboss.org (David Lloyd (JIRA))
Date: Mon, 3 Mar 2014 09:06:50 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3053) BootstrapImpl#bootstrap
 result is inherently racy
In-Reply-To: <JIRA.12533770.1393855564382@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12533770.1393855564382@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12533770.1393855564382.32111.1393855610368@jira02.app.mwc.hst.phx2.redhat.com>

David Lloyd created WFLY-3053:
---------------------------------

             Summary: BootstrapImpl#bootstrap result is inherently racy
                 Key: WFLY-3053
                 URL: https://issues.jboss.org/browse/WFLY-3053
             Project: WildFly
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Server
            Reporter: David Lloyd
            Assignee: Jason Greene
             Fix For: 8.0.1.Final


The boostrap code presently installs a stability monitor and awaits stability before returning.  It then probes the state of the root service.  There is a window of time in which the root service may be stopped or removed, resulting in big exception traces being logged.  To atomically get the result of the operation, the service container must somehow be frozen until the root service is completely read.


--
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

From issues at jboss.org  Mon Mar  3 09:08:47 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 3 Mar 2014 09:08:47 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3053) BootstrapImpl#bootstrap
 result is inherently racy
In-Reply-To: <JIRA.12533770.1393855564000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12533770.1393855564000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12533770.1393855564000.32117.1393855727882@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-3053?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated WFLY-3053:
------------------------------------------

        Bugzilla Update: Perform
    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1071934

    
> BootstrapImpl#bootstrap result is inherently racy
> -------------------------------------------------
>
>                 Key: WFLY-3053
>                 URL: https://issues.jboss.org/browse/WFLY-3053
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Server
>            Reporter: David Lloyd
>            Assignee: Jason Greene
>             Fix For: 8.0.1.Final
>
>
> The boostrap code presently installs a stability monitor and awaits stability before returning.  It then probes the state of the root service.  There is a window of time in which the root service may be stopped or removed, resulting in big exception traces being logged.  To atomically get the result of the operation, the service container must somehow be frozen until the root service is completely read.

--
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

From issues at jboss.org  Mon Mar  3 09:24:48 2014
From: issues at jboss.org (Richard Achmatowicz (JIRA))
Date: Mon, 3 Mar 2014 09:24:48 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1802) OverlappingUnicastMergeTest
In-Reply-To: <JIRA.12533772.1393856602890@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12533772.1393856602890@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12533772.1393856602890.32163.1393856688053@jira02.app.mwc.hst.phx2.redhat.com>

Richard Achmatowicz created JGRP-1802:
-----------------------------------------

             Summary: OverlappingUnicastMergeTest
                 Key: JGRP-1802
                 URL: https://issues.jboss.org/browse/JGRP-1802
             Project: JGroups
          Issue Type: Bug
    Affects Versions: 3.2.13
         Environment: Solaris, RHEL
            Reporter: Richard Achmatowicz
            Assignee: Bela Ban
             Fix For: 3.2.13


OverlappingUnicastMergeTest does the following:

- set up three channels a,b,c with the layers MERGE2, VERIFY_SUSPECT and FC removed
- the receiver of each channel will look at all incoming messages: if mcast, ignore it; if unicast, add to the list of messages received
- inject some new view into the channels which represents a view configuration which should be recovered from
- send messages to the channels and check that the messages are received, despite the  injected view

OverlappingUnicastMergeTest this test is failing in a number of ways (i.e. many of the test methods are failing within the test class on multiple platforms. 

--
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

From issues at jboss.org  Mon Mar  3 09:24:48 2014
From: issues at jboss.org (Richard Achmatowicz (JIRA))
Date: Mon, 3 Mar 2014 09:24:48 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1802) OverlappingUnicastMergeTest
In-Reply-To: <JIRA.12533772.1393856602000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12533772.1393856602000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12533772.1393856602000.32165.1393856688190@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JGRP-1802?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12949352#comment-12949352 ] 

Richard Achmatowicz commented on JGRP-1802:
-------------------------------------------

Here are links to some of the example failures:
https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/EAP6/view/EAP6-JGroups/job/jgroups-rhel-matrix-branch-3_2/
                
> OverlappingUnicastMergeTest
> ---------------------------
>
>                 Key: JGRP-1802
>                 URL: https://issues.jboss.org/browse/JGRP-1802
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.2.13
>         Environment: Solaris, RHEL
>            Reporter: Richard Achmatowicz
>            Assignee: Bela Ban
>             Fix For: 3.2.13
>
>
> OverlappingUnicastMergeTest does the following:
> - set up three channels a,b,c with the layers MERGE2, VERIFY_SUSPECT and FC removed
> - the receiver of each channel will look at all incoming messages: if mcast, ignore it; if unicast, add to the list of messages received
> - inject some new view into the channels which represents a view configuration which should be recovered from
> - send messages to the channels and check that the messages are received, despite the  injected view
> OverlappingUnicastMergeTest this test is failing in a number of ways (i.e. many of the test methods are failing within the test class on multiple platforms. 

--
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

From issues at jboss.org  Mon Mar  3 09:28:49 2014
From: issues at jboss.org (Jesper Pedersen (JIRA))
Date: Mon, 3 Mar 2014 09:28:49 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JBJCA-1148) IronJacamar 1.0.24.Final
In-Reply-To: <JIRA.12533774.1393856887277@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12533774.1393856887277@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12533774.1393856887277.32209.1393856929011@jira02.app.mwc.hst.phx2.redhat.com>

Jesper Pedersen created JBJCA-1148:
--------------------------------------

             Summary: IronJacamar 1.0.24.Final
                 Key: JBJCA-1148
                 URL: https://issues.jboss.org/browse/JBJCA-1148
             Project: IronJacamar
          Issue Type: Release
          Components: Build
            Reporter: Jesper Pedersen
            Assignee: Jesper Pedersen
             Fix For: 1.0.24.Final


Release notes: https://issues.jboss.org/secure/ReleaseNote.jspa?projectId=12310691&version=12323788

--
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

From issues at jboss.org  Mon Mar  3 09:28:49 2014
From: issues at jboss.org (Jesper Pedersen (JIRA))
Date: Mon, 3 Mar 2014 09:28:49 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JBJCA-1138) TransactionSynchronizer
 leaks memory and causes deadlocks in jacorb
In-Reply-To: <JIRA.12531584.1392035273000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12531584.1392035273000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12531584.1392035273000.32221.1393856929975@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBJCA-1138?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jesper Pedersen updated JBJCA-1138:
-----------------------------------

    Fix Version/s:     (was: 1.0.24.Final)
         Priority: Major  (was: Blocker)

    
> TransactionSynchronizer leaks memory and causes deadlocks in jacorb
> -------------------------------------------------------------------
>
>                 Key: JBJCA-1138
>                 URL: https://issues.jboss.org/browse/JBJCA-1138
>             Project: IronJacamar
>          Issue Type: Bug
>          Components: Core
>    Affects Versions: 1.0.23.Final
>            Reporter: Andrey Smirnov
>            Assignee: Jesper Pedersen
>
> Seems like TransactionSynchronizer has been rolled back to state it was in August. I think this was caused by little typo in commit 469b4c303dd0d5c39f3476a5972556d8b9537b44
> 296: Record record = records.get(tx); 
> But 'records' map uses TransactionKey as key and above line should be written as
> 296:TransactionKey key = new TransactionKey(tx);
> 297: Record record = records.get(key);
> I've checked 1.0.22 containing applied fix and mem-leaks and deadlocks are all gone

--
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

From issues at jboss.org  Mon Mar  3 09:30:48 2014
From: issues at jboss.org (Jesper Pedersen (JIRA))
Date: Mon, 3 Mar 2014 09:30:48 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JBJCA-1148) IronJacamar 1.0.24.Final
In-Reply-To: <JIRA.12533774.1393856887000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12533774.1393856887000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12533774.1393856887000.32226.1393857048471@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBJCA-1148?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jesper Pedersen resolved JBJCA-1148.
------------------------------------

    Resolution: Done

    
> IronJacamar 1.0.24.Final
> ------------------------
>
>                 Key: JBJCA-1148
>                 URL: https://issues.jboss.org/browse/JBJCA-1148
>             Project: IronJacamar
>          Issue Type: Release
>          Components: Build
>            Reporter: Jesper Pedersen
>            Assignee: Jesper Pedersen
>             Fix For: 1.0.24.Final
>
>
> Release notes: https://issues.jboss.org/secure/ReleaseNote.jspa?projectId=12310691&version=12323788

--
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

From issues at jboss.org  Mon Mar  3 09:32:48 2014
From: issues at jboss.org (Richard Achmatowicz (JIRA))
Date: Mon, 3 Mar 2014 09:32:48 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1802) OverlappingUnicastMergeTest
In-Reply-To: <JIRA.12533772.1393856602000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12533772.1393856602000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12533772.1393856602000.32233.1393857168250@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JGRP-1802?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12949357#comment-12949357 ] 

Richard Achmatowicz commented on JGRP-1802:
-------------------------------------------

Looking over the code in checkReceivedMessages, it seems there is a mixup in which receivers are used to check message arrival. 
In the setup for the test, you define three receivers ra, rb, rc. But in checkReceivedMessages(), you send the messages and then create three receivers which are used to check message receipt: 
{noformat}
    private void sendAndCheckMessages(int num_msgs, JChannel ... channels) throws Exception {
        ra.clear(); rb.clear(); rc.clear();
        // 1. send unicast messages
        Set<Address> mbrs=new HashSet<Address>(channels.length);
        for(JChannel ch: channels)
            mbrs.add(ch.getAddress());

        for(JChannel ch: channels) {
            Address addr=ch.getAddress();
            for(Address dest: mbrs) {
                for(int i=1; i <= num_msgs; i++) {
                    ch.send(dest, "unicast msg #" + i + " from " + addr);
                }
            }
        }
        int total_msgs=num_msgs * channels.length;
        MyReceiver[] receivers=new MyReceiver[channels.length];
        for(int i=0; i < channels.length; i++)
            receivers[i]=(MyReceiver)channels[i].getReceiver();
        checkReceivedMessages(total_msgs, receivers);
    }
{noformat}

Isn't it possible that messages will be received by channels before these receivers are installed?
Would this not be safer?
{noformat}
    private void sendAndCheckMessages(int num_msgs, JChannel ... channels) throws Exception {
        ra.clear(); rb.clear(); rc.clear();

        // send unicast messages
        Set<Address> mbrs=new HashSet<Address>(channels.length);
        for(JChannel ch: channels)
            mbrs.add(ch.getAddress());

        for(JChannel ch: channels) {
            Address addr=ch.getAddress();
            for(Address dest: mbrs) {
                for(int i=1; i <= num_msgs; i++) {
                    ch.send(dest, "unicast msg #" + i + " from " + addr);
                }
            }
        }
        // check unicast message arrival
        int total_msgs=num_msgs * channels.length;
        checkReceivedMessages(total_msgs, ra,rb,rc);
    }
{noformat}


                
> OverlappingUnicastMergeTest
> ---------------------------
>
>                 Key: JGRP-1802
>                 URL: https://issues.jboss.org/browse/JGRP-1802
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.2.13
>         Environment: Solaris, RHEL
>            Reporter: Richard Achmatowicz
>            Assignee: Bela Ban
>             Fix For: 3.2.13
>
>
> OverlappingUnicastMergeTest does the following:
> - set up three channels a,b,c with the layers MERGE2, VERIFY_SUSPECT and FC removed
> - the receiver of each channel will look at all incoming messages: if mcast, ignore it; if unicast, add to the list of messages received
> - inject some new view into the channels which represents a view configuration which should be recovered from
> - send messages to the channels and check that the messages are received, despite the  injected view
> OverlappingUnicastMergeTest this test is failing in a number of ways (i.e. many of the test methods are failing within the test class on multiple platforms. 

--
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

From issues at jboss.org  Mon Mar  3 09:36:48 2014
From: issues at jboss.org (Richard Achmatowicz (JIRA))
Date: Mon, 3 Mar 2014 09:36:48 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1802) OverlappingUnicastMergeTest
In-Reply-To: <JIRA.12533772.1393856602000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12533772.1393856602000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12533772.1393856602000.32243.1393857408052@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JGRP-1802?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12949359#comment-12949359 ] 

Richard Achmatowicz commented on JGRP-1802:
-------------------------------------------

In the test setup, it would also be safer to use Util.waitUntilAllChannelHaveSameSize() rather than an immediate check on view formation.
                
> OverlappingUnicastMergeTest
> ---------------------------
>
>                 Key: JGRP-1802
>                 URL: https://issues.jboss.org/browse/JGRP-1802
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.2.13
>         Environment: Solaris, RHEL
>            Reporter: Richard Achmatowicz
>            Assignee: Bela Ban
>             Fix For: 3.2.13
>
>
> OverlappingUnicastMergeTest does the following:
> - set up three channels a,b,c with the layers MERGE2, VERIFY_SUSPECT and FC removed
> - the receiver of each channel will look at all incoming messages: if mcast, ignore it; if unicast, add to the list of messages received
> - inject some new view into the channels which represents a view configuration which should be recovered from
> - send messages to the channels and check that the messages are received, despite the  injected view
> OverlappingUnicastMergeTest this test is failing in a number of ways (i.e. many of the test methods are failing within the test class on multiple platforms. 

--
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

From issues at jboss.org  Mon Mar  3 09:42:47 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 3 Mar 2014 09:42:47 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1712) Erroneous name attribute on
 root-logger after add-handler operation
In-Reply-To: <JIRA.12496729.1374094060000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12496729.1374094060000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12496729.1374094060000.32252.1393857767649@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1712?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12949362#comment-12949362 ] 

RH Bugzilla Integration commented on WFLY-1712:
-----------------------------------------------

mark yarborough <myarboro at redhat.com> changed the Status of [bug 1032627|https://bugzilla.redhat.com/show_bug.cgi?id=1032627] from MODIFIED to ON_QA
                
> Erroneous name attribute on root-logger after add-handler operation 
> --------------------------------------------------------------------
>
>                 Key: WFLY-1712
>                 URL: https://issues.jboss.org/browse/WFLY-1712
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Logging
>            Reporter: James Perkins
>            Assignee: James Perkins
>            Priority: Minor
>
> Execution of the {{add-handler}} operation adds a name attribute with the handlers name to the root-logger model.
> {code}
> "root-logger" => {"ROOT" => {
>             "filter" => undefined,
>             "filter-spec" => undefined,
>             "handlers" => [
>                 "FILE",
>                 "CONSOLE"
>             ],
>             "level" => "INFO",
>             "name" => "CONSOLE"
>         }}
> {code}

--
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

From issues at jboss.org  Mon Mar  3 09:42:48 2014
From: issues at jboss.org (Bela Ban (JIRA))
Date: Mon, 3 Mar 2014 09:42:48 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1802) OverlappingUnicastMergeTest
In-Reply-To: <JIRA.12533772.1393856602000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12533772.1393856602000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12533772.1393856602000.32260.1393857768091@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JGRP-1802?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban updated JGRP-1802:
---------------------------

    Fix Version/s: 3.5

    
> OverlappingUnicastMergeTest
> ---------------------------
>
>                 Key: JGRP-1802
>                 URL: https://issues.jboss.org/browse/JGRP-1802
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.2.13
>         Environment: Solaris, RHEL
>            Reporter: Richard Achmatowicz
>            Assignee: Bela Ban
>             Fix For: 3.2.13, 3.5
>
>
> OverlappingUnicastMergeTest does the following:
> - set up three channels a,b,c with the layers MERGE2, VERIFY_SUSPECT and FC removed
> - the receiver of each channel will look at all incoming messages: if mcast, ignore it; if unicast, add to the list of messages received
> - inject some new view into the channels which represents a view configuration which should be recovered from
> - send messages to the channels and check that the messages are received, despite the  injected view
> OverlappingUnicastMergeTest this test is failing in a number of ways (i.e. many of the test methods are failing within the test class on multiple platforms. 

--
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

From issues at jboss.org  Mon Mar  3 09:46:48 2014
From: issues at jboss.org (Jesper Pedersen (JIRA))
Date: Mon, 3 Mar 2014 09:46:48 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JBJCA-1146) Optimize removal in
 TransactionSynchronizer
In-Reply-To: <JIRA.12533762.1393853035000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12533762.1393853035000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12533762.1393853035000.32268.1393858008054@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBJCA-1146?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jesper Pedersen closed JBJCA-1146.
----------------------------------


    
> Optimize removal in TransactionSynchronizer
> -------------------------------------------
>
>                 Key: JBJCA-1146
>                 URL: https://issues.jboss.org/browse/JBJCA-1146
>             Project: IronJacamar
>          Issue Type: Task
>          Components: Core
>            Reporter: Jesper Pedersen
>            Assignee: Jesper Pedersen
>             Fix For: 1.0.24.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

From issues at jboss.org  Mon Mar  3 09:46:48 2014
From: issues at jboss.org (Jesper Pedersen (JIRA))
Date: Mon, 3 Mar 2014 09:46:48 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JBJCA-1141) Allow 'connectable' to be
 configured per deployment
In-Reply-To: <JIRA.12533504.1393511459000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12533504.1393511459000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12533504.1393511459000.32271.1393858008321@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBJCA-1141?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jesper Pedersen closed JBJCA-1141.
----------------------------------


    
> Allow 'connectable' to be configured per deployment
> ---------------------------------------------------
>
>                 Key: JBJCA-1141
>                 URL: https://issues.jboss.org/browse/JBJCA-1141
>             Project: IronJacamar
>          Issue Type: Task
>          Components: Common, Core, Deployer
>            Reporter: Jesper Pedersen
>            Assignee: Jesper Pedersen
>             Fix For: 1.0.24.Final, 1.2.0.Beta1
>
>


--
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

From issues at jboss.org  Mon Mar  3 09:46:48 2014
From: issues at jboss.org (Jesper Pedersen (JIRA))
Date: Mon, 3 Mar 2014 09:46:48 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JBJCA-1148) IronJacamar 1.0.24.Final
In-Reply-To: <JIRA.12533774.1393856887000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12533774.1393856887000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12533774.1393856887000.32273.1393858008494@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBJCA-1148?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jesper Pedersen closed JBJCA-1148.
----------------------------------


    
> IronJacamar 1.0.24.Final
> ------------------------
>
>                 Key: JBJCA-1148
>                 URL: https://issues.jboss.org/browse/JBJCA-1148
>             Project: IronJacamar
>          Issue Type: Release
>          Components: Build
>            Reporter: Jesper Pedersen
>            Assignee: Jesper Pedersen
>             Fix For: 1.0.24.Final
>
>
> Release notes: https://issues.jboss.org/secure/ReleaseNote.jspa?projectId=12310691&version=12323788

--
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

From issues at jboss.org  Mon Mar  3 09:48:47 2014
From: issues at jboss.org (Jesper Pedersen (JIRA))
Date: Mon, 3 Mar 2014 09:48:47 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JBJCA-1142) Track component updates
In-Reply-To: <JIRA.12533505.1393511728000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12533505.1393511728000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12533505.1393511728000.32277.1393858127762@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBJCA-1142?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jesper Pedersen closed JBJCA-1142.
----------------------------------


    
> Track component updates
> -----------------------
>
>                 Key: JBJCA-1142
>                 URL: https://issues.jboss.org/browse/JBJCA-1142
>             Project: IronJacamar
>          Issue Type: Task
>          Components: Build
>            Reporter: Jesper Pedersen
>            Assignee: Jesper Pedersen
>             Fix For: 1.0.24.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

From issues at jboss.org  Mon Mar  3 09:48:47 2014
From: issues at jboss.org (Jesper Pedersen (JIRA))
Date: Mon, 3 Mar 2014 09:48:47 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JBJCA-1143) Narayana 4.17.17
In-Reply-To: <JIRA.12533506.1393511771000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12533506.1393511771000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12533506.1393511771000.32279.1393858127867@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBJCA-1143?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jesper Pedersen closed JBJCA-1143.
----------------------------------


    
> Narayana 4.17.17
> ----------------
>
>                 Key: JBJCA-1143
>                 URL: https://issues.jboss.org/browse/JBJCA-1143
>             Project: IronJacamar
>          Issue Type: Component Upgrade
>          Components: Build
>            Reporter: Jesper Pedersen
>            Assignee: Jesper Pedersen
>             Fix For: 1.0.24.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

From issues at jboss.org  Mon Mar  3 10:02:48 2014
From: issues at jboss.org (Bela Ban (JIRA))
Date: Mon, 3 Mar 2014 10:02:48 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1803) S3_PING: incorrect format for
 presigned URLs
In-Reply-To: <JIRA.12533780.1393858901488@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12533780.1393858901488@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12533780.1393858901488.32299.1393858968068@jira02.app.mwc.hst.phx2.redhat.com>

Bela Ban created JGRP-1803:
------------------------------

             Summary: S3_PING: incorrect format for presigned URLs
                 Key: JGRP-1803
                 URL: https://issues.jboss.org/browse/JGRP-1803
             Project: JGroups
          Issue Type: Bug
            Reporter: Bela Ban
            Assignee: Bela Ban
             Fix For: 3.5


AWS changed the format for presigned URLs, so S3_PING doesn't work anymore with presigned URLs. 
All pre-signed URLs must include the bucket name in the hostname now. This updates the S3_PING code to both generate the new style URLs as well as be able to parse and use them.

--
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

From issues at jboss.org  Mon Mar  3 10:04:47 2014
From: issues at jboss.org (Bela Ban (JIRA))
Date: Mon, 3 Mar 2014 10:04:47 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1803) S3_PING: incorrect format for
 presigned URLs
In-Reply-To: <JIRA.12533780.1393858901000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12533780.1393858901000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12533780.1393858901000.32302.1393859087739@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JGRP-1803?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban updated JGRP-1803:
---------------------------

    Git Pull Request: https://github.com/belaban/JGroups/pull/123

    
> S3_PING: incorrect format for presigned URLs
> --------------------------------------------
>
>                 Key: JGRP-1803
>                 URL: https://issues.jboss.org/browse/JGRP-1803
>             Project: JGroups
>          Issue Type: Bug
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 3.5
>
>
> AWS changed the format for presigned URLs, so S3_PING doesn't work anymore with presigned URLs. 
> All pre-signed URLs must include the bucket name in the hostname now. This updates the S3_PING code to both generate the new style URLs as well as be able to parse and use them.

--
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

From issues at jboss.org  Mon Mar  3 10:04:47 2014
From: issues at jboss.org (Richard Achmatowicz (JIRA))
Date: Mon, 3 Mar 2014 10:04:47 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1802) OverlappingUnicastMergeTest
In-Reply-To: <JIRA.12533772.1393856602000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12533772.1393856602000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12533772.1393856602000.32305.1393859087877@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JGRP-1802?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12949367#comment-12949367 ] 

Richard Achmatowicz commented on JGRP-1802:
-------------------------------------------

I also noticed that the test description you provided in the javadoc for testWithViewBC() is no longer carried out in the test.
In the javadoc description, you:
- send messages
- inject a new view and then 
- send more messages
whereas in the actual test, you just inject a view and then send messages). 
Any reason for the change? The first test seems more realistic.

 
                
> OverlappingUnicastMergeTest
> ---------------------------
>
>                 Key: JGRP-1802
>                 URL: https://issues.jboss.org/browse/JGRP-1802
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.2.13
>         Environment: Solaris, RHEL
>            Reporter: Richard Achmatowicz
>            Assignee: Bela Ban
>             Fix For: 3.2.13, 3.5
>
>
> OverlappingUnicastMergeTest does the following:
> - set up three channels a,b,c with the layers MERGE2, VERIFY_SUSPECT and FC removed
> - the receiver of each channel will look at all incoming messages: if mcast, ignore it; if unicast, add to the list of messages received
> - inject some new view into the channels which represents a view configuration which should be recovered from
> - send messages to the channels and check that the messages are received, despite the  injected view
> OverlappingUnicastMergeTest this test is failing in a number of ways (i.e. many of the test methods are failing within the test class on multiple platforms. 

--
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

From issues at jboss.org  Mon Mar  3 10:04:48 2014
From: issues at jboss.org (Richard Achmatowicz (JIRA))
Date: Mon, 3 Mar 2014 10:04:48 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1802) OverlappingUnicastMergeTest
In-Reply-To: <JIRA.12533772.1393856602000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12533772.1393856602000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12533772.1393856602000.32308.1393859088041@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JGRP-1802?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12949367#comment-12949367 ] 

Richard Achmatowicz edited comment on JGRP-1802 at 3/3/14 10:03 AM:
--------------------------------------------------------------------

I also noticed that the test description you provided in the javadoc for testWithViewBC() is no longer carried out in the test.
In the javadoc description, you:
- send messages
- inject a new view and then 
- send more messages
whereas in the actual test, you just inject a view and then send messages). 


Any reason for the change? The first test seems more realistic.

 
                
      was (Author: rachmato):
    I also noticed that the test description you provided in the javadoc for testWithViewBC() is no longer carried out in the test.
In the javadoc description, you:
- send messages
- inject a new view and then 
- send more messages
whereas in the actual test, you just inject a view and then send messages). 
Any reason for the change? The first test seems more realistic.

 
                  
> OverlappingUnicastMergeTest
> ---------------------------
>
>                 Key: JGRP-1802
>                 URL: https://issues.jboss.org/browse/JGRP-1802
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.2.13
>         Environment: Solaris, RHEL
>            Reporter: Richard Achmatowicz
>            Assignee: Bela Ban
>             Fix For: 3.2.13, 3.5
>
>
> OverlappingUnicastMergeTest does the following:
> - set up three channels a,b,c with the layers MERGE2, VERIFY_SUSPECT and FC removed
> - the receiver of each channel will look at all incoming messages: if mcast, ignore it; if unicast, add to the list of messages received
> - inject some new view into the channels which represents a view configuration which should be recovered from
> - send messages to the channels and check that the messages are received, despite the  injected view
> OverlappingUnicastMergeTest this test is failing in a number of ways (i.e. many of the test methods are failing within the test class on multiple platforms. 

--
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

From issues at jboss.org  Mon Mar  3 10:06:50 2014
From: issues at jboss.org (Bela Ban (JIRA))
Date: Mon, 3 Mar 2014 10:06:50 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1803) S3_PING: incorrect format for
 presigned URLs
In-Reply-To: <JIRA.12533780.1393858901000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12533780.1393858901000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12533780.1393858901000.32313.1393859210678@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JGRP-1803?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban updated JGRP-1803:
---------------------------

    Fix Version/s: 3.4.3

    
> S3_PING: incorrect format for presigned URLs
> --------------------------------------------
>
>                 Key: JGRP-1803
>                 URL: https://issues.jboss.org/browse/JGRP-1803
>             Project: JGroups
>          Issue Type: Bug
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 3.4.3, 3.5
>
>
> AWS changed the format for presigned URLs, so S3_PING doesn't work anymore with presigned URLs. 
> All pre-signed URLs must include the bucket name in the hostname now. This updates the S3_PING code to both generate the new style URLs as well as be able to parse and use them.

--
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

From issues at jboss.org  Mon Mar  3 10:12:55 2014
From: issues at jboss.org (Bela Ban (JIRA))
Date: Mon, 3 Mar 2014 10:12:55 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1803) S3_PING: incorrect format for
 presigned URLs
In-Reply-To: <JIRA.12533780.1393858901000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12533780.1393858901000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12533780.1393858901000.32340.1393859575139@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JGRP-1803?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban resolved JGRP-1803.
----------------------------

    Resolution: Done


Backported to 3.4.3
                
> S3_PING: incorrect format for presigned URLs
> --------------------------------------------
>
>                 Key: JGRP-1803
>                 URL: https://issues.jboss.org/browse/JGRP-1803
>             Project: JGroups
>          Issue Type: Bug
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 3.4.3, 3.5
>
>
> AWS changed the format for presigned URLs, so S3_PING doesn't work anymore with presigned URLs. 
> All pre-signed URLs must include the bucket name in the hostname now. This updates the S3_PING code to both generate the new style URLs as well as be able to parse and use them.

--
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

From issues at jboss.org  Mon Mar  3 10:16:50 2014
From: issues at jboss.org (Richard Achmatowicz (JIRA))
Date: Mon, 3 Mar 2014 10:16:50 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1802) OverlappingUnicastMergeTest
In-Reply-To: <JIRA.12533772.1393856602000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12533772.1393856602000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12533772.1393856602000.32359.1393859810471@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JGRP-1802?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12949376#comment-12949376 ] 

Richard Achmatowicz commented on JGRP-1802:
-------------------------------------------

Also, here you install a view by sending a VIEW_CHANGE event up the stack and down the stack, whereas in OverlappingMergeTest, you install a view my calling GMS.installView(newView).
Are these equivalent?

                
> OverlappingUnicastMergeTest
> ---------------------------
>
>                 Key: JGRP-1802
>                 URL: https://issues.jboss.org/browse/JGRP-1802
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.2.13
>         Environment: Solaris, RHEL
>            Reporter: Richard Achmatowicz
>            Assignee: Bela Ban
>             Fix For: 3.2.13, 3.5
>
>
> OverlappingUnicastMergeTest does the following:
> - set up three channels a,b,c with the layers MERGE2, VERIFY_SUSPECT and FC removed
> - the receiver of each channel will look at all incoming messages: if mcast, ignore it; if unicast, add to the list of messages received
> - inject some new view into the channels which represents a view configuration which should be recovered from
> - send messages to the channels and check that the messages are received, despite the  injected view
> OverlappingUnicastMergeTest this test is failing in a number of ways (i.e. many of the test methods are failing within the test class on multiple platforms. 

--
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

From issues at jboss.org  Mon Mar  3 11:18:37 2014
From: issues at jboss.org (Pedro Ruivo (JIRA))
Date: Mon, 3 Mar 2014 11:18:37 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1785) TOA,
	inconsistent message delivery
In-Reply-To: <JIRA.12530413.1390836354000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530413.1390836354000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530413.1390836354000.57.1393863517666@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JGRP-1785?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12949415#comment-12949415 ] 

Pedro Ruivo commented on JGRP-1785:
-----------------------------------

I don't know if I don't have permissions or something similar, but I'm not seeing the pull request link button...

pull request made: https://github.com/belaban/JGroups/pull/126
                
> TOA, inconsistent message delivery
> ----------------------------------
>
>                 Key: JGRP-1785
>                 URL: https://issues.jboss.org/browse/JGRP-1785
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.5
>         Environment: Fedora release 17 (Beefy Miracle)
>            Reporter: Ryan Emerson
>            Assignee: Pedro Ruivo
>             Fix For: 3.5
>
>
> When sending total order messages between two nodes, for a prolonged period of time, an inconsistency is encountered when comparing each node's total order of messages.  
> I believe this issue is related to how sequence numbers are handled in the implementation, not the protocol itself.  I appreciate that TOA is designed for environments where the subset of destinations in the network varies, however I have been unable to reproduce this error when the total number of nodes is > 2.  It is still possible that this inconsistency may occur after a large amount of time when the number of nodes is > 2.  

--
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

From issues at jboss.org  Mon Mar  3 11:32:37 2014
From: issues at jboss.org (Bela Ban (JIRA))
Date: Mon, 3 Mar 2014 11:32:37 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1785) TOA,
	inconsistent message delivery
In-Reply-To: <JIRA.12530413.1390836354000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530413.1390836354000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530413.1390836354000.76.1393864357275@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JGRP-1785?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12949417#comment-12949417 ] 

Bela Ban commented on JGRP-1785:
--------------------------------

Thanks, applied your PR. Ryan, can you confirm this fixes your problem and then resolve the issue ?
Cheers,
                
> TOA, inconsistent message delivery
> ----------------------------------
>
>                 Key: JGRP-1785
>                 URL: https://issues.jboss.org/browse/JGRP-1785
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.5
>         Environment: Fedora release 17 (Beefy Miracle)
>            Reporter: Ryan Emerson
>            Assignee: Pedro Ruivo
>             Fix For: 3.5
>
>
> When sending total order messages between two nodes, for a prolonged period of time, an inconsistency is encountered when comparing each node's total order of messages.  
> I believe this issue is related to how sequence numbers are handled in the implementation, not the protocol itself.  I appreciate that TOA is designed for environments where the subset of destinations in the network varies, however I have been unable to reproduce this error when the total number of nodes is > 2.  It is still possible that this inconsistency may occur after a large amount of time when the number of nodes is > 2.  

--
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

From issues at jboss.org  Mon Mar  3 11:40:37 2014
From: issues at jboss.org (dpocock (JIRA))
Date: Mon, 3 Mar 2014 11:40:37 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3054) getPlatformMBeanServer
 behaves badly when called from premain class such as jmxetric
In-Reply-To: <JIRA.12533815.1393864749290@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12533815.1393864749290@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12533815.1393864749290.102.1393864837245@jira02.app.mwc.hst.phx2.redhat.com>

dpocock created WFLY-3054:
-----------------------------

             Summary: getPlatformMBeanServer behaves badly when called from premain class such as jmxetric
                 Key: WFLY-3054
                 URL: https://issues.jboss.org/browse/WFLY-3054
             Project: WildFly
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: JMX
    Affects Versions: JBoss AS7 7.1.1.Final
            Reporter: dpocock
            Assignee: Kabir Khan


JMXetric is a management agent JAR loaded using the JVM argument 

java -javaagent:$JARLIBS/jmxetric-1.0.2.jar .....

In the premain method (executed before JBoss main() is invoked), jmxetric calls the static method:

   ManagementFactory.getPlatformMBeanServer()

This puts JMX into a bad state and the jboss.as tree is completely missing when browsed with jconsole

As a workaround, jmxetric will defer the call to ManagementFactory.getPlatformMBeanServer() using the "initialdelay" parameter set to a value such as 20 seconds.

However, it would be good if JBoss could act more cleanly in this situation, for example, throwing an exception if ManagementFactory.getPlatformMBeanServer() is called too early, or finding a way to add the "jboss.as" stuff later.

The 1.0.6 release of jmxetric will include the workaround by default.  The bug can be reproduced by setting initialdelay="0" in the sample jmxetric.xml or using jmxetric 1.0.5

jmxetric versions before 1.0.5 suffer from issues with the jboss logger as discussed in WFLY-895, so this issue was only discovered after removing the logging statements from jmxetric.

Also covered in jmxetric github:

https://github.com/ganglia/jmxetric/issues/9

--
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

From issues at jboss.org  Mon Mar  3 11:40:37 2014
From: issues at jboss.org (Tomaz Cerar (JIRA))
Date: Mon, 3 Mar 2014 11:40:37 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3054) getPlatformMBeanServer
 behaves badly when called from premain class such as jmxetric
In-Reply-To: <JIRA.12533815.1393864749000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12533815.1393864749000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12533815.1393864749000.109.1393864837709@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-3054?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tomaz Cerar updated WFLY-3054:
------------------------------

    Issue Type: Enhancement  (was: Bug)

    
> getPlatformMBeanServer behaves badly when called from premain class such as jmxetric
> ------------------------------------------------------------------------------------
>
>                 Key: WFLY-3054
>                 URL: https://issues.jboss.org/browse/WFLY-3054
>             Project: WildFly
>          Issue Type: Enhancement
>      Security Level: Public(Everyone can see) 
>          Components: JMX
>    Affects Versions: JBoss AS7 7.1.1.Final
>            Reporter: dpocock
>            Assignee: Kabir Khan
>              Labels: jboss
>
> JMXetric is a management agent JAR loaded using the JVM argument 
> java -javaagent:$JARLIBS/jmxetric-1.0.2.jar .....
> In the premain method (executed before JBoss main() is invoked), jmxetric calls the static method:
>    ManagementFactory.getPlatformMBeanServer()
> This puts JMX into a bad state and the jboss.as tree is completely missing when browsed with jconsole
> As a workaround, jmxetric will defer the call to ManagementFactory.getPlatformMBeanServer() using the "initialdelay" parameter set to a value such as 20 seconds.
> However, it would be good if JBoss could act more cleanly in this situation, for example, throwing an exception if ManagementFactory.getPlatformMBeanServer() is called too early, or finding a way to add the "jboss.as" stuff later.
> The 1.0.6 release of jmxetric will include the workaround by default.  The bug can be reproduced by setting initialdelay="0" in the sample jmxetric.xml or using jmxetric 1.0.5
> jmxetric versions before 1.0.5 suffer from issues with the jboss logger as discussed in WFLY-895, so this issue was only discovered after removing the logging statements from jmxetric.
> Also covered in jmxetric github:
> https://github.com/ganglia/jmxetric/issues/9

--
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

From issues at jboss.org  Mon Mar  3 11:40:37 2014
From: issues at jboss.org (Tomaz Cerar (JIRA))
Date: Mon, 3 Mar 2014 11:40:37 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3054) getPlatformMBeanServer
 behaves badly when called from premain class such as jmxetric
In-Reply-To: <JIRA.12533815.1393864749000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12533815.1393864749000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12533815.1393864749000.112.1393864837845@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-3054?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12949426#comment-12949426 ] 

Tomaz Cerar commented on WFLY-3054:
-----------------------------------

Can you reproduce the same problem on WildFly 8?
                
> getPlatformMBeanServer behaves badly when called from premain class such as jmxetric
> ------------------------------------------------------------------------------------
>
>                 Key: WFLY-3054
>                 URL: https://issues.jboss.org/browse/WFLY-3054
>             Project: WildFly
>          Issue Type: Enhancement
>      Security Level: Public(Everyone can see) 
>          Components: JMX
>    Affects Versions: JBoss AS7 7.1.1.Final
>            Reporter: dpocock
>            Assignee: Kabir Khan
>              Labels: jboss
>
> JMXetric is a management agent JAR loaded using the JVM argument 
> java -javaagent:$JARLIBS/jmxetric-1.0.2.jar .....
> In the premain method (executed before JBoss main() is invoked), jmxetric calls the static method:
>    ManagementFactory.getPlatformMBeanServer()
> This puts JMX into a bad state and the jboss.as tree is completely missing when browsed with jconsole
> As a workaround, jmxetric will defer the call to ManagementFactory.getPlatformMBeanServer() using the "initialdelay" parameter set to a value such as 20 seconds.
> However, it would be good if JBoss could act more cleanly in this situation, for example, throwing an exception if ManagementFactory.getPlatformMBeanServer() is called too early, or finding a way to add the "jboss.as" stuff later.
> The 1.0.6 release of jmxetric will include the workaround by default.  The bug can be reproduced by setting initialdelay="0" in the sample jmxetric.xml or using jmxetric 1.0.5
> jmxetric versions before 1.0.5 suffer from issues with the jboss logger as discussed in WFLY-895, so this issue was only discovered after removing the logging statements from jmxetric.
> Also covered in jmxetric github:
> https://github.com/ganglia/jmxetric/issues/9

--
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

From issues at jboss.org  Mon Mar  3 13:06:37 2014
From: issues at jboss.org (Paul Ferraro (JIRA))
Date: Mon, 3 Mar 2014 13:06:37 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-342) Reenable
 ClusteredSingleSignOnTestCase test to work with Undertow
In-Reply-To: <JIRA.12471898.1344331018000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12471898.1344331018000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12471898.1344331018000.267.1393869997691@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-342?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Paul Ferraro closed WFLY-342.
-----------------------------

    Fix Version/s: 8.0.0.Final
                       (was: 9.0.0.CR1)
       Resolution: Done

    
> Reenable ClusteredSingleSignOnTestCase test to work with Undertow 
> ------------------------------------------------------------------
>
>                 Key: WFLY-342
>                 URL: https://issues.jboss.org/browse/WFLY-342
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Clustering
>            Reporter: Kabir Khan
>            Assignee: Paul Ferraro
>            Priority: Critical
>             Fix For: 8.0.0.Final
>
>         Attachments: ClusteredSingleSignOnTestCase1.html, ClusteredSingleSignOnTestCase2.html, ClusteredSingleSignOnTestCase3.html
>
>
> Test have been @Ignored until Undertow implements SSO.

--
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

From issues at jboss.org  Mon Mar  3 13:24:37 2014
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Mon, 3 Mar 2014 13:24:37 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3055) Ability to configure a prefix
 to the domain server launch command
In-Reply-To: <JIRA.12533819.1393870966822@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12533819.1393870966822@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12533819.1393870966822.296.1393871077591@jira02.app.mwc.hst.phx2.redhat.com>

Brian Stansberry created WFLY-3055:
--------------------------------------

             Summary: Ability to configure a prefix to the domain server launch command
                 Key: WFLY-3055
                 URL: https://issues.jboss.org/browse/WFLY-3055
             Project: WildFly
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: Domain Management
            Reporter: Brian Stansberry
            Assignee: John O'Hara
             Fix For: 9.0.0.CR1


Ability to configure a prefix to the 'java' command used to launch a domain server. This would be a general purpose feature but some intended uses we'd want to make sure work include:

1) NUMA settings, e.g.

numactl --membind 0 --cpubind 0

2) Having the server process run under a different user, e.g.

sudo joe

--
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

From issues at jboss.org  Mon Mar  3 13:36:38 2014
From: issues at jboss.org (David Lloyd (JIRA))
Date: Mon, 3 Mar 2014 13:36:38 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3055) Ability to configure a prefix
 to the domain server launch command
In-Reply-To: <JIRA.12533819.1393870966000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12533819.1393870966000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12533819.1393870966000.313.1393871798005@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-3055?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12949529#comment-12949529 ] 

David Lloyd commented on WFLY-3055:
-----------------------------------

* Locking a process to a core or cores: {{taskset 0x0030 ...}}
* Managing process priority: {{nice -n -5 ...}}

It would be nice if we could do it close to the way I originally suggested back 3-4 years ago or whatever it was, and have knowledge of how to control various JVMs and various OSes to accomplish common tasks in a platform-independent way, but at least having a generic capability is something.
                
> Ability to configure a prefix to the domain server launch command
> -----------------------------------------------------------------
>
>                 Key: WFLY-3055
>                 URL: https://issues.jboss.org/browse/WFLY-3055
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>            Reporter: Brian Stansberry
>            Assignee: John O'Hara
>             Fix For: 9.0.0.CR1
>
>
> Ability to configure a prefix to the 'java' command used to launch a domain server. This would be a general purpose feature but some intended uses we'd want to make sure work include:
> 1) NUMA settings, e.g.
> numactl --membind 0 --cpubind 0
> 2) Having the server process run under a different user, e.g.
> sudo joe

--
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

From issues at jboss.org  Mon Mar  3 13:38:36 2014
From: issues at jboss.org (Scott Marlow (JIRA))
Date: Mon, 3 Mar 2014 13:38:36 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3056) component upgrade to
 Hibernate ORM 4.3.4.Final
In-Reply-To: <JIRA.12533821.1393871837205@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12533821.1393871837205@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12533821.1393871837205.317.1393871916942@jira02.app.mwc.hst.phx2.redhat.com>

Scott Marlow created WFLY-3056:
----------------------------------

             Summary: component upgrade to Hibernate ORM 4.3.4.Final
                 Key: WFLY-3056
                 URL: https://issues.jboss.org/browse/WFLY-3056
             Project: WildFly
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: JPA / Hibernate
            Reporter: Scott Marlow
            Assignee: Scott Marlow
             Fix For: 8.0.1.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

From issues at jboss.org  Mon Mar  3 13:58:37 2014
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Mon, 3 Mar 2014 13:58:37 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3057) Add proper ResourceDefinition
 hooks for setting runtime only, adding aliases
In-Reply-To: <JIRA.12533822.1393873038257@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12533822.1393873038257@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12533822.1393873038257.387.1393873117282@jira02.app.mwc.hst.phx2.redhat.com>

Brian Stansberry created WFLY-3057:
--------------------------------------

             Summary: Add proper ResourceDefinition hooks for setting runtime only, adding aliases 
                 Key: WFLY-3057
                 URL: https://issues.jboss.org/browse/WFLY-3057
             Project: WildFly
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: Domain Management
            Reporter: Brian Stansberry
            Assignee: Brian Stansberry
             Fix For: 9.0.0.CR1


If a resource is runtime only or has alias registrations, there's no proper API for configuring these. ResourceDefinition impls are forced to hack this in via the registerAttributes/Operations/Children callbacks.

--
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

From issues at jboss.org  Mon Mar  3 13:58:37 2014
From: issues at jboss.org (David Lloyd (JIRA))
Date: Mon, 3 Mar 2014 13:58:37 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-781) urn:jboss:pojo:7.0 is a subset
 of *-jboss-beans.xml, application-policy is not available
In-Reply-To: <JIRA.12446792.1315896241000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12446792.1315896241000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12446792.1315896241000.396.1393873117742@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-781?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

David Lloyd resolved WFLY-781.
------------------------------

    Resolution: Rejected


It is extremely unlikely that this functionality will be forward ported unfortunately.
                
> urn:jboss:pojo:7.0 is a subset of *-jboss-beans.xml, application-policy is not available
> ----------------------------------------------------------------------------------------
>
>                 Key: WFLY-781
>                 URL: https://issues.jboss.org/browse/WFLY-781
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: POJO
>         Environment: AS 7.1.0-Alpha1-SNAPSHOT - commit 335c262c7449e4f6667b5339838bfdf0a65f5263
>            Reporter: Karel Piwko
>            Assignee: Ales Justin
>
> I'm migrating an application which has security domain defined in *-jboss-beans.xml from AS 5 to AS 7.
> {code:xml}
> <?xml version="1.0" encoding="UTF-8"?>
> <deployment xmlns="urn:jboss:pojo:7.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:jboss:pojo:7.0 jboss-pojo_7_0.xsd">
>     <application-policy name="security-preauth">
>         <authentication>
>             <login-module code="org.jboss.security.auth.spi.UsersRolesLoginModule" flag="required">
>                 <module-option name="usersProperties" value="security-preauth-users.properties" />
>                 <module-option name="rolesProperties" value="security-preauth-roles.properties" />
>             </login-module>
>         </authentication>
>     </application-policy>
> </deployment>
> {code}
> This security domain is specified in jboss-web.xml, as:
> {code:xml}
> <?xml version="1.0" encoding="UTF-8"?>
> <jboss-web>
>     <security-domain>security-preauth</security-domain>
>     <context-root>spring-preauth</context-root>
> </jboss-web>
> {code}
> Here's corresponding configuration in web.xml
> {code:xml}
> <login-config>
>         <auth-method>BASIC</auth-method>
>         <realm-name>security-preauth</realm-name>
>     </login-config>
>     <security-role>
>         <role-name>ROLE_USER</role-name>
>     </security-role>
>     <security-role>
>         <role-name>ROLE_SUPERVISOR</role-name>
>     </security-role>
>     <security-constraint>
>         <web-resource-collection>
>             <web-resource-name>All areas</web-resource-name>
>             <url-pattern>/*</url-pattern>
>         </web-resource-collection>
>         <auth-constraint>
>             <role-name>ROLE_USER</role-name>
>         </auth-constraint>
>     </security-constraint>
> {code}
> This is not correctly loaded by JBoss AS, failing with (after TRACE logging is enabled):
> {code}
> 16:46:44,287 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-3) MSC00001: Failed to start service jboss.deployment.unit."spring-preauth.war".PARSE: org.jboss.msc.service.StartException in service jboss.deployment.unit."spring-preauth.war".PARSE: Failed to process phase PARSE of deployment "spring-preauth.war"
>         at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:121) [jboss-as-server-7.1.0.Alpha1-SNAPSHOT.jar:7.1.0.Alpha1-SNAPSHOT]
>         at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1824) [jboss-msc-1.0.1.GA.jar:1.0.1.GA]
>         at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1759) [jboss-msc-1.0.1.GA.jar:1.0.1.GA]
>         at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [:1.6.0_24]
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [:1.6.0_24]
>         at java.lang.Thread.run(Thread.java:662) [:1.6.0_24]
> Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: Failed to parse POJO xml ["/content/spring-preauth.war/META-INF/security-preauth-jboss-beans.xml"]
>         at org.jboss.as.pojo.KernelDeploymentParsingProcessor.parseDescriptor(KernelDeploymentParsingProcessor.java:130)
>         at org.jboss.as.pojo.KernelDeploymentParsingProcessor.parseDescriptors(KernelDeploymentParsingProcessor.java:104)
>         at org.jboss.as.pojo.KernelDeploymentParsingProcessor.deploy(KernelDeploymentParsingProcessor.java:73)
>         at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:115) [jboss-as-server-7.1.0.Alpha1-SNAPSHOT.jar:7.1.0.Alpha1-SNAPSHOT]
>         ... 5 more
> Caused by: javax.xml.stream.XMLStreamException: ParseError at [row,col]:[5,5]
> Message: Unexpected element '{urn:jboss:pojo:7.0}application-policy' encountered
>         at org.jboss.as.controller.parsing.ParseUtils.unexpectedElement(ParseUtils.java:65)
>         at org.jboss.as.pojo.descriptor.KernelDeploymentXmlDescriptorParser.readElement(KernelDeploymentXmlDescriptorParser.java:174)
>         at org.jboss.as.pojo.descriptor.KernelDeploymentXmlDescriptorParser.readElement(KernelDeploymentXmlDescriptorParser.java:50)
>         at org.jboss.staxmapper.XMLMapperImpl.processNested(XMLMapperImpl.java:100)
>         at org.jboss.staxmapper.XMLMapperImpl.parseDocument(XMLMapperImpl.java:59)
>         at org.jboss.as.pojo.KernelDeploymentParsingProcessor.parseDescriptor(KernelDeploymentParsingProcessor.java:123)
>         ... 8 more
> {code}
> Note: With AS 7.0.1 this is not working at all, *-jboss-beans.xml is ignored.
> Workaround is modify standalone.xml and add the security domain there, but it's not a feasible solution as it makes automated testing much more difficult.

--
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

From issues at jboss.org  Mon Mar  3 14:06:38 2014
From: issues at jboss.org (Paul Ferraro (JIRA))
Date: Mon, 3 Mar 2014 14:06:38 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3033) Better SSO configuration
In-Reply-To: <JIRA.12533478.1393493687000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12533478.1393493687000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12533478.1393493687000.413.1393873598003@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-3033?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12949537#comment-12949537 ] 

Paul Ferraro commented on WFLY-3033:
------------------------------------

Would it make sense to default the cookie path to the web application context path?
                
> Better SSO configuration
> ------------------------
>
>                 Key: WFLY-3033
>                 URL: https://issues.jboss.org/browse/WFLY-3033
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Web (Undertow)
>    Affects Versions: 8.0.0.Final
>            Reporter: Tin Tvrtkovic
>            Assignee: Tomaz Cerar
>            Priority: Critical
>              Labels: single-sign-on, undertow
>             Fix For: 8.0.1.Final
>
>
> When enabling Undertow SSO in standalone.xml, the only option to tweak is the cookie domain.
> My life would be made easier by two changes:
> 1) If the domain is not specified, the SSO cookie should have no domain set. This will make the browser apply the domain from the URL being requested. Currently the cookie domain gets populated with a value from the enclosing XML element.
> 2) There's no way of setting the cookie path, which makes this less useful for services on different URLs. I propose adding a path attribute to the SSO XML element, which would set the cookie path. For example:
> <single-sign-on path="/" />
> Right now my workaround is to use my reverse proxy (Apache) to edit response headers and modify the cookie, removing the domain and adding the path. If anyone else needs the workaround:
> Header edit Set-Cookie "^JSESSIONIDSSO=([^; ]+).+" "JSESSIONIDSSO=$1; path=/"

--
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

From issues at jboss.org  Mon Mar  3 14:34:37 2014
From: issues at jboss.org (Radoslav Husar (JIRA))
Date: Mon, 3 Mar 2014 14:34:37 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3033) Better SSO configuration
In-Reply-To: <JIRA.12533478.1393493687000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12533478.1393493687000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12533478.1393493687000.460.1393875277926@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-3033?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12949542#comment-12949542 ] 

Radoslav Husar commented on WFLY-3033:
--------------------------------------

Makes sense to me.
                
> Better SSO configuration
> ------------------------
>
>                 Key: WFLY-3033
>                 URL: https://issues.jboss.org/browse/WFLY-3033
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Web (Undertow)
>    Affects Versions: 8.0.0.Final
>            Reporter: Tin Tvrtkovic
>            Assignee: Tomaz Cerar
>            Priority: Critical
>              Labels: single-sign-on, undertow
>             Fix For: 8.0.1.Final
>
>
> When enabling Undertow SSO in standalone.xml, the only option to tweak is the cookie domain.
> My life would be made easier by two changes:
> 1) If the domain is not specified, the SSO cookie should have no domain set. This will make the browser apply the domain from the URL being requested. Currently the cookie domain gets populated with a value from the enclosing XML element.
> 2) There's no way of setting the cookie path, which makes this less useful for services on different URLs. I propose adding a path attribute to the SSO XML element, which would set the cookie path. For example:
> <single-sign-on path="/" />
> Right now my workaround is to use my reverse proxy (Apache) to edit response headers and modify the cookie, removing the domain and adding the path. If anyone else needs the workaround:
> Header edit Set-Cookie "^JSESSIONIDSSO=([^; ]+).+" "JSESSIONIDSSO=$1; path=/"

--
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

From issues at jboss.org  Mon Mar  3 14:58:37 2014
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Mon, 3 Mar 2014 14:58:37 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3058) Expose data on actively
 executing management ops, with an op to cancel
In-Reply-To: <JIRA.12533829.1393876616146@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12533829.1393876616146@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12533829.1393876616146.478.1393876717025@jira02.app.mwc.hst.phx2.redhat.com>

Brian Stansberry created WFLY-3058:
--------------------------------------

             Summary: Expose data on actively executing management ops, with an op to cancel
                 Key: WFLY-3058
                 URL: https://issues.jboss.org/browse/WFLY-3058
             Project: WildFly
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: Domain Management
            Reporter: Brian Stansberry
            Assignee: Brian Stansberry
             Fix For: 9.0.0.CR1


Track the management ops actively being executed by the ModelController and expose them as management resources. Include a 'cancel' op to let admins terminate a non-progressing op.

A ModelControllerClient already allows cancelling an op by using its async API and canceling the returned Future. But that's not a particularly user-friendly way of dealing with the issue -- not helpful for HTTP users, requires some sort of CLI changes and unintuitive workflows to make it accessible to CLI users, etc.

--
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

From issues at jboss.org  Mon Mar  3 15:00:38 2014
From: issues at jboss.org (Tomaz Cerar (JIRA))
Date: Mon, 3 Mar 2014 15:00:38 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3033) Better SSO configuration
In-Reply-To: <JIRA.12533478.1393493687000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12533478.1393493687000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12533478.1393493687000.482.1393876838284@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-3033?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12949549#comment-12949549 ] 

Tomaz Cerar commented on WFLY-3033:
-----------------------------------

It makes *no* sense to default it to web application context path.

it is SSO, which main point of existence is to work across different applications.
If cookie is by default set to application context path, it would only be accessible to said application and noting else effectively render SSO useless by default.
                
> Better SSO configuration
> ------------------------
>
>                 Key: WFLY-3033
>                 URL: https://issues.jboss.org/browse/WFLY-3033
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Web (Undertow)
>    Affects Versions: 8.0.0.Final
>            Reporter: Tin Tvrtkovic
>            Assignee: Tomaz Cerar
>            Priority: Critical
>              Labels: single-sign-on, undertow
>             Fix For: 8.0.1.Final
>
>
> When enabling Undertow SSO in standalone.xml, the only option to tweak is the cookie domain.
> My life would be made easier by two changes:
> 1) If the domain is not specified, the SSO cookie should have no domain set. This will make the browser apply the domain from the URL being requested. Currently the cookie domain gets populated with a value from the enclosing XML element.
> 2) There's no way of setting the cookie path, which makes this less useful for services on different URLs. I propose adding a path attribute to the SSO XML element, which would set the cookie path. For example:
> <single-sign-on path="/" />
> Right now my workaround is to use my reverse proxy (Apache) to edit response headers and modify the cookie, removing the domain and adding the path. If anyone else needs the workaround:
> Header edit Set-Cookie "^JSESSIONIDSSO=([^; ]+).+" "JSESSIONIDSSO=$1; path=/"

--
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

From issues at jboss.org  Mon Mar  3 15:46:37 2014
From: issues at jboss.org (Paul Ferraro (JIRA))
Date: Mon, 3 Mar 2014 15:46:37 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3033) Better SSO configuration
In-Reply-To: <JIRA.12533478.1393493687000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12533478.1393493687000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12533478.1393493687000.545.1393879597086@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-3033?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12949558#comment-12949558 ] 

Paul Ferraro commented on WFLY-3033:
------------------------------------

Of course.  I dunno what I was thinking.

                
> Better SSO configuration
> ------------------------
>
>                 Key: WFLY-3033
>                 URL: https://issues.jboss.org/browse/WFLY-3033
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Web (Undertow)
>    Affects Versions: 8.0.0.Final
>            Reporter: Tin Tvrtkovic
>            Assignee: Tomaz Cerar
>            Priority: Critical
>              Labels: single-sign-on, undertow
>             Fix For: 8.0.1.Final
>
>
> When enabling Undertow SSO in standalone.xml, the only option to tweak is the cookie domain.
> My life would be made easier by two changes:
> 1) If the domain is not specified, the SSO cookie should have no domain set. This will make the browser apply the domain from the URL being requested. Currently the cookie domain gets populated with a value from the enclosing XML element.
> 2) There's no way of setting the cookie path, which makes this less useful for services on different URLs. I propose adding a path attribute to the SSO XML element, which would set the cookie path. For example:
> <single-sign-on path="/" />
> Right now my workaround is to use my reverse proxy (Apache) to edit response headers and modify the cookie, removing the domain and adding the path. If anyone else needs the workaround:
> Header edit Set-Cookie "^JSESSIONIDSSO=([^; ]+).+" "JSESSIONIDSSO=$1; path=/"

--
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

From issues at jboss.org  Mon Mar  3 16:44:37 2014
From: issues at jboss.org (James Perkins (JIRA))
Date: Mon, 3 Mar 2014 16:44:37 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (LOGMGR-99) Infinite recursion when
 exception stack frame class lookup fails
In-Reply-To: <JIRA.12533713.1393800685000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12533713.1393800685000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12533713.1393800685000.621.1393883077318@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/LOGMGR-99?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

James Perkins updated LOGMGR-99:
--------------------------------

    Description: 
To print out the jar information in exception stack traces, the log manager needs to resolve the class name from StackTraceElement to the Class object. Since the log manager cannot know which classloader was used, guessClass() tries the TCCL, the logmanager's classloader and finally the system classloader.

It is possible that the TCCL contains a class of the same name as the one in the stack frame, but it not the same class. This can easily happen if the application packages a jar that is also used by the container. In this situation, the class may not be able to be loaded, such as if the application-packages class is missing it's dependencies.

If Class.forName() would throw a NoClassDefFoundError or similar, JBoss Modules (or other classloader implementation) may attempt to log this using java.util.logging API. This can result in infinite recursion, for example

{code}
       ...
       at org.jboss.logmanager.Logger.log(Logger.java:367)
       at org.jboss.modules.log.JDKModuleLogger.doLog(JDKModuleLogger.java:109)
       at org.jboss.modules.log.JDKModuleLogger.classDefineFailed(JDKModuleLogger.java:194)
       at org.jboss.modules.ModuleClassLoader.defineClass(ModuleClassLoader.java:401)
       at org.jboss.modules.ModuleClassLoader.loadClassLocal(ModuleClassLoader.java:243)
       at org.jboss.modules.ModuleClassLoader$1.loadClassLocal(ModuleClassLoader.java:73)
       at org.jboss.modules.Module.loadModuleClass(Module.java:527)
       at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:182)
       at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:468)
       at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:456)
       at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:398)
       at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:120)
       at java.lang.Class.forName0(Native Method)
       at java.lang.Class.forName(Class.java:266)
       at org.jboss.logmanager.formatters.Formatters$12.guessClass(Formatters.java:578)
       at org.jboss.logmanager.formatters.Formatters$12.renderExtended(Formatters.java:421)
       at org.jboss.logmanager.formatters.Formatters$12.renderRaw(Formatters.java:388)
       at org.jboss.logmanager.formatters.Formatters$JustifyingFormatStep.render(Formatters.java:150)
       at org.jboss.logmanager.formatters.MultistepFormatter.format(MultistepFormatter.java:86)
       at org.jboss.logmanager.ExtFormatter.format(ExtFormatter.java:35)
       at org.jboss.logmanager.handlers.WriterHandler.doPublish(WriterHandler.java:49)
       at org.jboss.logmanager.ExtHandler.publish(ExtHandler.java:76)
       at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:290)
       at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:298)
       at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:298)
       at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:298)
       at org.jboss.logmanager.Logger.logRaw(Logger.java:721)
       at org.jboss.logmanager.Logger.logRaw(Logger.java:731)
       at org.jboss.logmanager.Logger.log(Logger.java:367)
       ...
{code}

  was:
To print out the jar information in exception stack traces, the log manager needs to resolve the class name from StackTraceElement to the Class object. Since the log manager cannot know which classloader was used, guessClass() tries the TCCL, the logmanager's classloader and finally the system classloader.

It is possible that the TCCL contains a class of the same name as the one in the stack frame, but it not the same class. This can easily happen if the application packages a jar that is also used by the container. In this situation, the class may not be able to be loaded, such as if the application-packages class is missing it's dependencies.

If Class.forName() would throw a NoClassDefFoundError or similar, JBoss Modules (or other classloader implementation) may attempt to log this using java.util.logging API. This can result in infinite recursion, for example

       ...
       at org.jboss.logmanager.Logger.log(Logger.java:367)
       at org.jboss.modules.log.JDKModuleLogger.doLog(JDKModuleLogger.java:109)
       at org.jboss.modules.log.JDKModuleLogger.classDefineFailed(JDKModuleLogger.java:194)
       at org.jboss.modules.ModuleClassLoader.defineClass(ModuleClassLoader.java:401)
       at org.jboss.modules.ModuleClassLoader.loadClassLocal(ModuleClassLoader.java:243)
       at org.jboss.modules.ModuleClassLoader$1.loadClassLocal(ModuleClassLoader.java:73)
       at org.jboss.modules.Module.loadModuleClass(Module.java:527)
       at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:182)
       at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:468)
       at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:456)
       at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:398)
       at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:120)
       at java.lang.Class.forName0(Native Method)
       at java.lang.Class.forName(Class.java:266)
       at org.jboss.logmanager.formatters.Formatters$12.guessClass(Formatters.java:578)
       at org.jboss.logmanager.formatters.Formatters$12.renderExtended(Formatters.java:421)
       at org.jboss.logmanager.formatters.Formatters$12.renderRaw(Formatters.java:388)
       at org.jboss.logmanager.formatters.Formatters$JustifyingFormatStep.render(Formatters.java:150)
       at org.jboss.logmanager.formatters.MultistepFormatter.format(MultistepFormatter.java:86)
       at org.jboss.logmanager.ExtFormatter.format(ExtFormatter.java:35)
       at org.jboss.logmanager.handlers.WriterHandler.doPublish(WriterHandler.java:49)
       at org.jboss.logmanager.ExtHandler.publish(ExtHandler.java:76)
       at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:290)
       at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:298)
       at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:298)
       at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:298)
       at org.jboss.logmanager.Logger.logRaw(Logger.java:721)
       at org.jboss.logmanager.Logger.logRaw(Logger.java:731)
       at org.jboss.logmanager.Logger.log(Logger.java:367)
       ...


    
> Infinite recursion when exception stack frame class lookup fails
> ----------------------------------------------------------------
>
>                 Key: LOGMGR-99
>                 URL: https://issues.jboss.org/browse/LOGMGR-99
>             Project: JBoss Log Manager
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 1.5.1.Final
>            Reporter: James Livingston
>            Assignee: David Lloyd
>            Priority: Critical
>         Attachments: logmgr99.war
>
>
> To print out the jar information in exception stack traces, the log manager needs to resolve the class name from StackTraceElement to the Class object. Since the log manager cannot know which classloader was used, guessClass() tries the TCCL, the logmanager's classloader and finally the system classloader.
> It is possible that the TCCL contains a class of the same name as the one in the stack frame, but it not the same class. This can easily happen if the application packages a jar that is also used by the container. In this situation, the class may not be able to be loaded, such as if the application-packages class is missing it's dependencies.
> If Class.forName() would throw a NoClassDefFoundError or similar, JBoss Modules (or other classloader implementation) may attempt to log this using java.util.logging API. This can result in infinite recursion, for example
> {code}
>        ...
>        at org.jboss.logmanager.Logger.log(Logger.java:367)
>        at org.jboss.modules.log.JDKModuleLogger.doLog(JDKModuleLogger.java:109)
>        at org.jboss.modules.log.JDKModuleLogger.classDefineFailed(JDKModuleLogger.java:194)
>        at org.jboss.modules.ModuleClassLoader.defineClass(ModuleClassLoader.java:401)
>        at org.jboss.modules.ModuleClassLoader.loadClassLocal(ModuleClassLoader.java:243)
>        at org.jboss.modules.ModuleClassLoader$1.loadClassLocal(ModuleClassLoader.java:73)
>        at org.jboss.modules.Module.loadModuleClass(Module.java:527)
>        at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:182)
>        at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:468)
>        at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:456)
>        at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:398)
>        at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:120)
>        at java.lang.Class.forName0(Native Method)
>        at java.lang.Class.forName(Class.java:266)
>        at org.jboss.logmanager.formatters.Formatters$12.guessClass(Formatters.java:578)
>        at org.jboss.logmanager.formatters.Formatters$12.renderExtended(Formatters.java:421)
>        at org.jboss.logmanager.formatters.Formatters$12.renderRaw(Formatters.java:388)
>        at org.jboss.logmanager.formatters.Formatters$JustifyingFormatStep.render(Formatters.java:150)
>        at org.jboss.logmanager.formatters.MultistepFormatter.format(MultistepFormatter.java:86)
>        at org.jboss.logmanager.ExtFormatter.format(ExtFormatter.java:35)
>        at org.jboss.logmanager.handlers.WriterHandler.doPublish(WriterHandler.java:49)
>        at org.jboss.logmanager.ExtHandler.publish(ExtHandler.java:76)
>        at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:290)
>        at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:298)
>        at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:298)
>        at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:298)
>        at org.jboss.logmanager.Logger.logRaw(Logger.java:721)
>        at org.jboss.logmanager.Logger.logRaw(Logger.java:731)
>        at org.jboss.logmanager.Logger.log(Logger.java:367)
>        ...
> {code}

--
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

From issues at jboss.org  Mon Mar  3 17:14:37 2014
From: issues at jboss.org (Stuart Douglas (JIRA))
Date: Mon, 3 Mar 2014 17:14:37 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3059) Merge JPA into a single maven
	module
In-Reply-To: <JIRA.12533838.1393884764954@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12533838.1393884764954@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12533838.1393884764954.628.1393884877082@jira02.app.mwc.hst.phx2.redhat.com>

Stuart Douglas created WFLY-3059:
------------------------------------

             Summary: Merge JPA into a single maven module
                 Key: WFLY-3059
                 URL: https://issues.jboss.org/browse/WFLY-3059
             Project: WildFly
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: JPA / Hibernate
            Reporter: Stuart Douglas
            Assignee: Scott Marlow


Now that most of the code has been moved into jipajpa there is no need for multiple maven modules.

--
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

From issues at jboss.org  Mon Mar  3 17:14:37 2014
From: issues at jboss.org (Stuart Douglas (JIRA))
Date: Mon, 3 Mar 2014 17:14:37 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3059) Merge JPA into a single maven
	module
In-Reply-To: <JIRA.12533838.1393884764000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12533838.1393884764000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12533838.1393884764000.631.1393884877264@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-3059?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stuart Douglas updated WFLY-3059:
---------------------------------

           Issue Type: Task  (was: Feature Request)
        Fix Version/s: 8.0.1.Final
    Affects Version/s: 8.0.0.Final

    
> Merge JPA into a single maven module
> ------------------------------------
>
>                 Key: WFLY-3059
>                 URL: https://issues.jboss.org/browse/WFLY-3059
>             Project: WildFly
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: JPA / Hibernate
>    Affects Versions: 8.0.0.Final
>            Reporter: Stuart Douglas
>            Assignee: Scott Marlow
>             Fix For: 8.0.1.Final
>
>
> Now that most of the code has been moved into jipajpa there is no need for multiple maven modules.

--
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

From issues at jboss.org  Mon Mar  3 18:02:37 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 3 Mar 2014 18:02:37 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2920) StackOverflowError when
 org.jboss.as.jacorb.rmi.InterfaceAnalysis is analyzing javax.ejb.EJBObject
In-Reply-To: <JIRA.12532007.1392269121000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12532007.1392269121000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12532007.1392269121000.653.1393887757084@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2920?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12949569#comment-12949569 ] 

RH Bugzilla Integration commented on WFLY-2920:
-----------------------------------------------

Kabir Khan <kkhan at redhat.com> changed the Status of [bug 1064644|https://bugzilla.redhat.com/show_bug.cgi?id=1064644] from POST to MODIFIED
                
> StackOverflowError when org.jboss.as.jacorb.rmi.InterfaceAnalysis is analyzing javax.ejb.EJBObject
> --------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2920
>                 URL: https://issues.jboss.org/browse/WFLY-2920
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: IIOP
>    Affects Versions: 8.0.0.Final
>            Reporter: Osamu Nagano
>            Assignee: Stefan Guilhen
>         Attachments: td.dump
>
>
> Depending on when a thread context switch happens, an IIOP enabled EJB fails to be deployed by throwing {{java.lang.StackOverflowError}}.  Here is the stack trace from the attached thread dump.
> {code}
> "MSC service thread 1-7" prio=10 tid=0x00007f52e8001800 nid=0x4d12 at breakpoint[0x00007f534093f000]
>    java.lang.Thread.State: RUNNABLE
>         at org.jboss.as.jacorb.rmi.WorkCacheManager.getAnalysis(WorkCacheManager.java:105)
>         at org.jboss.as.jacorb.rmi.InterfaceAnalysis.getInterfaceAnalysis(InterfaceAnalysis.java:53)
>         at org.jboss.as.jacorb.rmi.Util.getTypeIDLName(Util.java:104)
>         at org.jboss.as.jacorb.rmi.ParameterAnalysis.<init>(ParameterAnalysis.java:50)
>         at org.jboss.as.jacorb.rmi.OperationAnalysis.<init>(OperationAnalysis.java:91)
>         at org.jboss.as.jacorb.rmi.InterfaceAnalysis.analyzeOperations(InterfaceAnalysis.java:116)
>         at org.jboss.as.jacorb.rmi.ContainerAnalysis.doAnalyze(ContainerAnalysis.java:186)
>         at org.jboss.as.jacorb.rmi.InterfaceAnalysis.doAnalyze(InterfaceAnalysis.java:62)
>         at sun.reflect.GeneratedMethodAccessor3.invoke(Unknown Source)
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>         at java.lang.reflect.Method.invoke(Method.java:606)
>         at org.jboss.as.jacorb.rmi.WorkCacheManager.doTheWork(WorkCacheManager.java:177)
>         at org.jboss.as.jacorb.rmi.WorkCacheManager.getAnalysis(WorkCacheManager.java:105)
>         at org.jboss.as.jacorb.rmi.InterfaceAnalysis.getInterfaceAnalysis(InterfaceAnalysis.java:53)
>         at org.jboss.as.jacorb.rmi.Util.getTypeIDLName(Util.java:104)
>         at org.jboss.as.jacorb.rmi.ParameterAnalysis.<init>(ParameterAnalysis.java:50)
>         at org.jboss.as.jacorb.rmi.OperationAnalysis.<init>(OperationAnalysis.java:91)
>         at org.jboss.as.jacorb.rmi.InterfaceAnalysis.analyzeOperations(InterfaceAnalysis.java:116)
>         at org.jboss.as.jacorb.rmi.ContainerAnalysis.doAnalyze(ContainerAnalysis.java:186)
>         at org.jboss.as.jacorb.rmi.InterfaceAnalysis.doAnalyze(InterfaceAnalysis.java:62)
>         at sun.reflect.GeneratedMethodAccessor3.invoke(Unknown Source)
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>         at java.lang.reflect.Method.invoke(Method.java:606)
>         ...
>         at org.jboss.as.jacorb.rmi.WorkCacheManager.doTheWork(WorkCacheManager.java:177)
>         at org.jboss.as.jacorb.rmi.WorkCacheManager.getAnalysis(WorkCacheManager.java:105)
>         at org.jboss.as.jacorb.rmi.InterfaceAnalysis.getInterfaceAnalysis(InterfaceAnalysis.java:53)
>         at org.jboss.as.jacorb.rmi.Util.getTypeIDLName(Util.java:104)
>         at org.jboss.as.jacorb.rmi.ParameterAnalysis.<init>(ParameterAnalysis.java:50)
>    Locked ownable synchronizers:
>         - <0x00000000f9698790> (a java.util.concurrent.ThreadPoolExecutor$Worker)
> {code}
> The last part including {{Util.getTypeIDLName}} has been repeated as many as possible and the bottom of the stack has been lost.  The same stack has been appeared in a different MSC service thread which is also executing an IIOP enabled EJB deployment.
> The customer identified an improper synchronization in {{org.jboss.as.jacorb.rmi.WorkCacheManager#getAnalysis()}}.  It is reproducible by manually controlling a thread context switch using a debugger.

--
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

From issues at jboss.org  Tue Mar  4 00:18:37 2014
From: issues at jboss.org (niraj gupta (JIRA))
Date: Tue, 4 Mar 2014 00:18:37 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-441) drools-guvnor 5.5,
 declarative model, create more than one fact type,
 BPMN process does not load
In-Reply-To: <JIRA.12533209.1393317312000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12533209.1393317312000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12533209.1393317312000.760.1393910317536@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/DROOLS-441?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12949592#comment-12949592 ] 

niraj gupta commented on DROOLS-441:
------------------------------------

Hi Davide,
              Is that my question clear enough to under stand the issue. I am trying with more details to explain this problem. If i am doing something wrong step, please correct me. 

Please help me, i need this fix asap.

How reproducible:


Steps to Reproduce:
1. login to guvnor and create a package in the knowledge base
2. now create a declarative model like this.
View Source: DecModel1
1. | declare MEmp
2. | eid: Integer
3. | ename: String
4. | end
5. |
6. | declare EBank
7. | bid: Integer
8. | end

3. save this
4. now create a simple process like  Proc1 
Start --> script task (System.out.println("AAAAA");) -- End
5. Save, validate, build package, create snapshot etc...
6. login to jbpm-console and execute the Proc1.
7. console will print AAAAAA
8. go back to drool-guvnor (Oryx Edit designer for BPMN2.0). change script task from System.out.println("AAAAA"); to System.out.println("BBBBB");
9.Save, validate, build package, create snapshot etc...
10. login to jbpm-console and execute the Proc1.
11. console is printing AAAAAA not BBBBBB

Actual results:
console output AAAAAA 

Expected results:
console output BBBBBB

Additional info:   no exceptions in any log file.
version=5.5.0.Final
groupId=org.drools
artifactId=guvnor-webapp-drools

version=2.4.0.Final
groupId=org.jboss.drools
artifactId=jbpm-designer

version=2.4.3.Final
groupId=org.jboss.bpm
artifactId=gwt-console-server

version=5.4.0.Final
groupId=org.jbpm
artifactId=jbpm-gwt-console-server

version=2.4.3.Final
groupId=org.jboss.bpm
artifactId=gwt-console

version=5.4.0.Final
groupId=org.jbpm
artifactId=jbpm-gwt-console

                
> drools-guvnor 5.5, declarative model, create more than one fact type, BPMN process does not load
> ------------------------------------------------------------------------------------------------
>
>                 Key: DROOLS-441
>                 URL: https://issues.jboss.org/browse/DROOLS-441
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.5.0.Final
>         Environment: Tomcat 6.0.35, jBPM 5.5.Final
>            Reporter: niraj gupta
>            Assignee: Mark Proctor
>              Labels: drools-guvnor
>
>  I am using ?drools-guvnor 5.5.0.Final? open source tool for designing the business process (BPMN2). I end up in an issue and looking for help. Following is the scenario
> I created a package then process then after build, deploy execute successfully. Now I came back to guvnor and made few changes in the process. Then after same build, deploy execute successfully. But now this time I am creating a declarative model having 2 facts, also modifying business process. Then after same build, deploy execute successfully. This time modified/latest business process doesn?t load into console. This is my problem.  However I trouble shoot and google following are my observations:
> ?	I am running this application in tomcat 6.0.35
> ?	It works perfectly with POJO Model Jar approach.
> ?	It works perfectly with declarative model but having single fact.
> ?	I am not seeing any exceptions either in UI or console logs

--
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


From issues at jboss.org  Tue Mar  4 01:47:34 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 4 Mar 2014 01:47:34 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-296) Drools date coercion and
	conditional OR
In-Reply-To: <JIRA.12502748.1381472788000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502748.1381472788000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502748.1381472788000.4.1393915654637@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-296?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated DROOLS-296:
-------------------------------------------

    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1029908, https://bugzilla.redhat.com/show_bug.cgi?id=1072217  (was: https://bugzilla.redhat.com/show_bug.cgi?id=1029908)

    
> Drools date coercion and conditional OR
> ---------------------------------------
>
>                 Key: DROOLS-296
>                 URL: https://issues.jboss.org/browse/DROOLS-296
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.5.0.Final
>         Environment: Windows 7
>            Reporter: Madhura Jayaratne
>            Assignee: Mario Fusco
>             Fix For: 6.0.1.Final
>
>
> If I try a simple Drools rule with conditions on date type and uses conditional OR (||) I get the following error. If I change || to && it works fine.
> Condition
> $container: DateContainer( date >= "15-Oct-2013" || date <= "01-Oct-2013"  )
> Error
> Unable to Analyse Expression date >= "15-Oct-2013" || date <= "01-Oct-2013":
> [Error: Comparison operation requires compatible types. Found class java.util.Date and class java.lang.String]
> [Near : {... date >= "15-Oct-2013" || date <= "01-Oct-2013" ....}]
>                                               ^
> [Line: 9, Column: 1] : [Rule name='Test rule']

--
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

From issues at jboss.org  Tue Mar  4 02:01:33 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 4 Mar 2014 02:01:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2899) Help and error messages in
 Main classes should be printed raw
In-Reply-To: <JIRA.12531680.1392076590000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12531680.1392076590000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12531680.1392076590000.16.1393916493690@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2899?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated WFLY-2899:
------------------------------------------

        Bugzilla Update: Perform
    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1069514, https://bugzilla.redhat.com/show_bug.cgi?id=1072224  (was: https://bugzilla.redhat.com/show_bug.cgi?id=1069514)

    
> Help and error messages in Main classes should be printed raw
> -------------------------------------------------------------
>
>                 Key: WFLY-2899
>                 URL: https://issues.jboss.org/browse/WFLY-2899
>             Project: WildFly
>          Issue Type: Enhancement
>      Security Level: Public(Everyone can see) 
>          Components: Logging
>            Reporter: James Perkins
>            Assignee: James Perkins
>            Priority: Minor
>             Fix For: 8.0.1.Final
>
>
> The help in standalone and host-controller main methods gets printed after {{System.out}} and {{System.err}} have been captured by jboss-stdio. This leads the help and errors being printed in a log manager format rather than just the raw text.
> Example output:
> {code}
> [jperkins at jperkins-rh wildfly]$ ./build/target/wildfly-8.0.0.Final-SNAPSHOT/bin/standalone.sh -help
> =========================================================================
>   JBoss Bootstrap Environment
>   JBOSS_HOME: /home/jperkins/projects/jboss/as/wildfly/build/target/wildfly-8.0.0.Final-SNAPSHOT
>   JAVA: java
>   JAVA_OPTS:  -server -XX:+UseCompressedOops -Xms64m -Xmx512m -XX:MaxPermSize=256m -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true
> =========================================================================
> 15:31:43,895 INFO  [org.jboss.modules] (main) JBoss Modules version 1.3.0.Final
> 15:31:44,918 INFO  [stdout] (main) 
> 15:31:44,918 INFO  [stdout] (main) Usage: standalone.sh [args...]
> 15:31:44,918 INFO  [stdout] (main) where args include:
> 15:31:44,918 INFO  [stdout] (main)     --admin-only                        Set the server's running type to 
> 15:31:44,919 INFO  [stdout] (main)                                         ADMIN_ONLY causing it to open 
> 15:31:44,919 INFO  [stdout] (main)                                         administrative interfaces and accept 
> 15:31:44,919 INFO  [stdout] (main)                                         management requests but not start other 
> 15:31:44,920 INFO  [stdout] (main)                                         runtime services or accept end user 
> 15:31:44,920 INFO  [stdout] (main)                                         requests.
> 15:31:44,920 INFO  [stdout] (main) 
> 15:31:44,920 INFO  [stdout] (main) 
> 15:31:44,921 INFO  [stdout] (main)     -b <value>, -b=<value>              Set system property jboss.bind.address 
> 15:31:44,921 INFO  [stdout] (main)                                         to the given value
> 15:31:44,921 INFO  [stdout] (main) 
> 15:31:44,921 INFO  [stdout] (main) 
> 15:31:44,922 INFO  [stdout] (main)     -b<interface>=<value>               Set system property 
> 15:31:44,922 INFO  [stdout] (main)                                         jboss.bind.address.<interface> to the 
> 15:31:44,922 INFO  [stdout] (main)                                         given value
> 15:31:44,922 INFO  [stdout] (main) 
> 15:31:44,923 INFO  [stdout] (main) 
> 15:31:44,923 INFO  [stdout] (main)     -c <config>, -c=<config>            Name of the server configuration file 
> 15:31:44,923 INFO  [stdout] (main)                                         to use (default is "standalone.xml") 
> 15:31:44,923 INFO  [stdout] (main)                                         (Same as --server-config)
> 15:31:44,924 INFO  [stdout] (main) 
> 15:31:44,924 INFO  [stdout] (main) 
> 15:31:44,924 INFO  [stdout] (main)     --debug [<port>]                    Activate debug mode with an optional 
> 15:31:44,924 INFO  [stdout] (main)                                         argument to specify the port. Only 
> 15:31:44,925 INFO  [stdout] (main)                                         works if the launch script supports it.
> 15:31:44,925 INFO  [stdout] (main) 
> 15:31:44,925 INFO  [stdout] (main) 
> 15:31:44,925 INFO  [stdout] (main)     -D<name>[=<value>]                  Set a system property
> 15:31:44,926 INFO  [stdout] (main) 
> 15:31:44,926 INFO  [stdout] (main) 
> 15:31:44,926 INFO  [stdout] (main)     -h, --help                          Display this message and exit
> 15:31:44,927 INFO  [stdout] (main) 
> 15:31:44,927 INFO  [stdout] (main) 
> 15:31:44,927 INFO  [stdout] (main)     --read-only-server-config=<config>  Name of the server configuration file 
> 15:31:44,927 INFO  [stdout] (main)                                         to use. This differs from 
> 15:31:44,928 INFO  [stdout] (main)                                         '--server-config' and '-c' in that the 
> 15:31:44,928 INFO  [stdout] (main)                                         original file is never overwritten.
> 15:31:44,928 INFO  [stdout] (main) 
> 15:31:44,928 INFO  [stdout] (main) 
> 15:31:44,929 INFO  [stdout] (main)     -P <url>, -P=<url>,                 Load system properties from the given 
> 15:31:44,929 INFO  [stdout] (main)          --properties=<url>             url
> 15:31:44,929 INFO  [stdout] (main) 
> 15:31:44,929 INFO  [stdout] (main) 
> 15:31:44,930 INFO  [stdout] (main)     -S<name>[=<value>]                  Set a security property
> 15:31:44,930 INFO  [stdout] (main) 
> 15:31:44,930 INFO  [stdout] (main) 
> 15:31:44,930 INFO  [stdout] (main)     --server-config=<config>            Name of the server configuration file 
> 15:31:44,931 INFO  [stdout] (main)                                         to use (default is "standalone.xml") 
> 15:31:44,931 INFO  [stdout] (main)                                         (Same as -c)
> 15:31:44,931 INFO  [stdout] (main) 
> 15:31:44,931 INFO  [stdout] (main) 
> 15:31:44,932 INFO  [stdout] (main)     -u <value>, -u=<value>              Set system property 
> 15:31:44,932 INFO  [stdout] (main)                                         jboss.default.multicast.address to the 
> 15:31:44,932 INFO  [stdout] (main)                                         given value
> 15:31:44,933 INFO  [stdout] (main) 
> 15:31:44,933 INFO  [stdout] (main) 
> 15:31:44,933 INFO  [stdout] (main)     -v, -V, --version                   Print version and exit
> 15:31:44,934 INFO  [stdout] (main) 
> 15:31:44,934 INFO  [stdout] (main)
> {code}

--
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

From issues at jboss.org  Tue Mar  4 02:03:33 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 4 Mar 2014 02:03:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2261) standalone.sh --debug without
 port number not working
In-Reply-To: <JIRA.12502486.1381251288000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502486.1381251288000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502486.1381251288000.24.1393916613484@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2261?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated WFLY-2261:
------------------------------------------

        Bugzilla Update: Perform
    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1063289, https://bugzilla.redhat.com/show_bug.cgi?id=1072227  (was: https://bugzilla.redhat.com/show_bug.cgi?id=1063289)

    
> standalone.sh --debug without port number not working 
> ------------------------------------------------------
>
>                 Key: WFLY-2261
>                 URL: https://issues.jboss.org/browse/WFLY-2261
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Scripts
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Cheng Fang
>            Assignee: Jeff Mesnil
>             Fix For: 8.0.1.Final
>
>
> ./standalone.sh --debug port-num works, but it failed when omitting port number.
> sh -x standalone.sh --debug  (expecting the default port 8787 to be used)
> {noformat}
> + eval '"/Library/Java/JavaVirtualMachines/jdk1.7.0_40.jdk/Contents/Home/bin/java"' '-D"[Standalone]"' -server -XX:+UseCompressedOops -Xms64m -Xmx512m -XX:MaxPermSize=256m -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true -agentlib:jdwp=transport=dt_socket,address=8787,server=y,suspend=n '"-Dorg.jboss.boot.log.file=/Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT/standalone/log/server.log"' '"-Dlogging.configuration=file:/Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT/standalone/configuration/logging.properties"' -jar '"/Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT/jboss-modules.jar"' -mp '"/Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT/modules"' org.jboss.as.standalone '-Djboss.home.dir="/Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT"' '-Djboss.server.base.dir="/Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT/standalone"' ' ""'
> ++ /Library/Java/JavaVirtualMachines/jdk1.7.0_40.jdk/Contents/Home/bin/java '-D[Standalone]' -server -XX:+UseCompressedOops -Xms64m -Xmx512m -XX:MaxPermSize=256m -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true -agentlib:jdwp=transport=dt_socket,address=8787,server=y,suspend=n -Dorg.jboss.boot.log.file=/Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT/standalone/log/server.log -Dlogging.configuration=file:/Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT/standalone/configuration/logging.properties -jar /Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT/jboss-modules.jar -mp /Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT/modules org.jboss.as.standalone -Djboss.home.dir=/Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT -Djboss.server.base.dir=/Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT/standalone ''
> Listening for transport dt_socket at address: 8787
> 12:19:36,715 INFO  [org.jboss.modules] (main) JBoss Modules version 1.3.0.Final
> 12:19:36,886 ERROR [stderr] (main) JBAS015801: Invalid option ''
> 12:19:36,893 INFO  [stdout] (main)
> 12:19:36,893 INFO  [stdout] (main) Usage: standalone.sh [args...]
> {noformat}
> sh -x standalone.sh --debug 8787 (the working command)
> {noformat}
> + eval '"/Library/Java/JavaVirtualMachines/jdk1.7.0_40.jdk/Contents/Home/bin/java"' '-D"[Standalone]"' -server -XX:+UseCompressedOops -Xms64m -Xmx512m -XX:MaxPermSize=256m -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true -agentlib:jdwp=transport=dt_socket,address=8787,server=y,suspend=n '"-Dorg.jboss.boot.log.file=/Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT/standalone/log/server.log"' '"-Dlogging.configuration=file:/Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT/standalone/configuration/logging.properties"' -jar '"/Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT/jboss-modules.jar"' -mp '"/Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT/modules"' org.jboss.as.standalone '-Djboss.home.dir="/Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT"' '-Djboss.server.base.dir="/Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT/standalone"' ''
> ++ /Library/Java/JavaVirtualMachines/jdk1.7.0_40.jdk/Contents/Home/bin/java '-D[Standalone]' -server -XX:+UseCompressedOops -Xms64m -Xmx512m -XX:MaxPermSize=256m -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true -agentlib:jdwp=transport=dt_socket,address=8787,server=y,suspend=n -Dorg.jboss.boot.log.file=/Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT/standalone/log/server.log -Dlogging.configuration=file:/Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT/standalone/configuration/logging.properties -jar /Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT/jboss-modules.jar -mp /Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT/modules org.jboss.as.standalone -Djboss.home.dir=/Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT -Djboss.server.base.dir=/Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT/standalone
> Listening for transport dt_socket at address: 8787
> 12:20:39,251 INFO  [org.jboss.modules] (main) JBoss Modules version 1.3.0.Final
> 12:20:39,626 INFO  [org.jboss.msc] (main) JBoss MSC version 1.2.0.Beta2
> {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


From issues at jboss.org  Tue Mar  4 02:43:33 2014
From: issues at jboss.org (lokesh tarley (JIRA))
Date: Tue, 4 Mar 2014 02:43:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3051) JMX connection to remote
 server-instances is not happening in wildfly 8.0.0.Final in domain mode
In-Reply-To: <JIRA.12533723.1393825342000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12533723.1393825342000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12533723.1393825342000.47.1393919013270@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-3051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12949618#comment-12949618 ] 

lokesh tarley commented on WFLY-3051:
-------------------------------------

Yep, i am also facing the same issue, that will be great if provide some way for the same..

Thanks
-Lokesh
                
> JMX connection to remote server-instances is not happening in wildfly 8.0.0.Final in domain mode
> ------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-3051
>                 URL: https://issues.jboss.org/browse/WFLY-3051
>             Project: WildFly
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: JMX, Remoting
>    Affects Versions: 8.0.0.Final
>            Reporter: Rituraj Sinha
>            Assignee: Darran Lofthouse
>             Fix For: 8.0.1.Final
>
>
> i have gone through the below link for JMX subsystem for wildfly 8 as
> https://docs.jboss.org/author/display/WFLY8/JMX+subsystem+configuration
>  
> but unable to connect to server-instances running remotely ...i have posted my question there as well and pasting it here now ...
> can someone please give us the steps to configure JMX through jconsole...?
> changes done on the domain.xml are the same as stated above
> <subsystem xmlns="urn:jboss:domain:jmx:1.3">
>                 <expose-resolved-model/>
>                 <expose-expression-model/>
>                 <remoting-connector use-management-endpoint="false"/>
>             </subsystem>
> <subsystem xmlns="urn:jboss:domain:jmx:1.3">
>                 <expose-resolved-model/>
>                 <expose-expression-model/>
>                 <remoting-connector use-management-endpoint="false"/>
>             </subsystem>
> as per the jboss-as-jmx_1_3.xsd  its like
> <xs:attribute name="use-management-endpoint" type="xs:boolean" default="true" use="optional" >
>             <xs:annotation>
>                 <xs:documentation>
>                     If true then this connector will use the management endpoint, otherwise it will use the
>                     remoting subsystem endpoint.
>                 </xs:documentation>
>             </xs:annotation>
>         </xs:attribute>
> now if we are making it false then it should be using the remoting endpoint ...now remoting subsystem by default uses ApplicatoinRealm
> i have created application-user and password for the same but when i am trying to connect to remote server-instances its not connecting it....
> below is what i am able to connect to 
> service:jmx:http-remoting-jmx://remote_hostA:9990 --
> Unknown macro: {host A is where my domain_controller is running}
> how can i access the server-instances running on domain_controller
> Unknown macro: {there are three server_instanaces running on HostA with a port offset of 100 each}
> i am trying to connect with the below url as 
> service:jmx:http-remoting-jmx://lremote_hostA:8180
> let me know if something is missing from my side...
> Thanks

--
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

From issues at jboss.org  Tue Mar  4 02:57:33 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 4 Mar 2014 02:57:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (SECURITY-795) AdvancedLdap login module
 does not handle a user that has a slash character in the uid
In-Reply-To: <JIRA.12532238.1392392424000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12532238.1392392424000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12532238.1392392424000.62.1393919853659@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/SECURITY-795?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12949621#comment-12949621 ] 

RH Bugzilla Integration commented on SECURITY-795:
--------------------------------------------------

Ondrej Lukas <olukas at redhat.com> changed the Status of [bug 1065513|https://bugzilla.redhat.com/show_bug.cgi?id=1065513] from ON_QA to VERIFIED
                
> AdvancedLdap login module does not handle a user that has a slash character in the uid
> --------------------------------------------------------------------------------------
>
>                 Key: SECURITY-795
>                 URL: https://issues.jboss.org/browse/SECURITY-795
>             Project: PicketBox 
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Negotiation
>    Affects Versions: Negotiation_2_2_5
>            Reporter: Derek Horton
>            Assignee: Derek Horton
>             Fix For: Negotiation_2_2_7
>
>         Attachments: SECURITY-795.patch
>
>
> AdvancedLdap login module does not handle a user that has a slash character in the uid.
> For example, JBoss will fail to authenticate the following user correctly:
> dn: uid=weird/user,ou=Users,dc=my-domain,dc=com
> uid: weird/user
> cn: Weird User

--
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

From issues at jboss.org  Tue Mar  4 03:23:35 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 4 Mar 2014 03:23:35 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1712) Erroneous name attribute on
 root-logger after add-handler operation
In-Reply-To: <JIRA.12496729.1374094060000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12496729.1374094060000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12496729.1374094060000.102.1393921415261@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1712?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12949628#comment-12949628 ] 

RH Bugzilla Integration commented on WFLY-1712:
-----------------------------------------------

Nikoleta Ziakova <nziakova at redhat.com> changed the Status of [bug 1032627|https://bugzilla.redhat.com/show_bug.cgi?id=1032627] from ON_QA to VERIFIED
                
> Erroneous name attribute on root-logger after add-handler operation 
> --------------------------------------------------------------------
>
>                 Key: WFLY-1712
>                 URL: https://issues.jboss.org/browse/WFLY-1712
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Logging
>            Reporter: James Perkins
>            Assignee: James Perkins
>            Priority: Minor
>
> Execution of the {{add-handler}} operation adds a name attribute with the handlers name to the root-logger model.
> {code}
> "root-logger" => {"ROOT" => {
>             "filter" => undefined,
>             "filter-spec" => undefined,
>             "handlers" => [
>                 "FILE",
>                 "CONSOLE"
>             ],
>             "level" => "INFO",
>             "name" => "CONSOLE"
>         }}
> {code}

--
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

From issues at jboss.org  Tue Mar  4 03:37:34 2014
From: issues at jboss.org (dpocock (JIRA))
Date: Tue, 4 Mar 2014 03:37:34 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3054) getPlatformMBeanServer
 behaves badly when called from premain class such as jmxetric
In-Reply-To: <JIRA.12533815.1393864749000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12533815.1393864749000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12533815.1393864749000.121.1393922254354@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-3054?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12949631#comment-12949631 ] 

dpocock commented on WFLY-3054:
-------------------------------

Just downloaded wildfly-8.0.0.Final.tar.gz to test

Using jmxetric 1.0.5 (which has the workaround for unfixed WFLY-895, jmxetric no longer makes calls to the logger) and I get the stack below:

$ bin/standalone.sh 
=========================================================================

  JBoss Bootstrap Environment

  JBOSS_HOME: /home/daniel/opt/wildfly-8.0.0.Final

  JAVA: /opt/jdk1.7/bin/java

  JAVA_OPTS:  -server -XX:+UseCompressedOops -Xms64m -Xmx512m -XX:MaxPermSize=256m -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true    -Xbootclasspath/a:/usr/share/java/oncrpc.jar   -Xbootclasspath/a:/usr/share/java/gmetric4j-1.0.6.jar   -javaagent:/usr/share/java/jmxetric-1.0.5.jar=host=239.2.11.71,mode=multicast,port=8649,wireformat31x=true,config=/home/daniel/opt/wildfly-8.0.0.Final/bin/jmxetric.xml

=========================================================================

JMXetricAgent instrumented JVM, see https://github.com/ganglia/jmxetric
WARNING: Failed to load the specified log manager class org.jboss.logmanager.LogManager
Mar 04, 2014 9:21:02 AM org.jboss.msc.service.ServiceContainerImpl <clinit>
INFO: JBoss MSC version 1.2.0.Final
Mar 04, 2014 9:21:02 AM org.jboss.as.server.ApplicationServerService start
INFO: JBAS015899: WildFly 8.0.0.Final "WildFly" starting
Mar 04, 2014 9:21:03 AM org.jboss.as.controller.AbstractOperationContext executeStep
ERROR: JBAS014612: Operation ("parallel-extension-add") failed - address: ([])
java.lang.RuntimeException: JBAS014670: Failed initializing module org.jboss.as.logging
	at org.jboss.as.controller.extension.ParallelExtensionAddHandler$1.execute(ParallelExtensionAddHandler.java:99)
	at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:591)
	at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:469)
	at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:273)
	at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:268)
	at org.jboss.as.controller.ModelControllerImpl.boot(ModelControllerImpl.java:314)
	at org.jboss.as.controller.AbstractControllerService.boot(AbstractControllerService.java:294)
	at org.jboss.as.server.ServerService.boot(ServerService.java:356)
	at org.jboss.as.server.ServerService.boot(ServerService.java:331)
	at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:256)
	at java.lang.Thread.run(Thread.java:722)
Caused by: java.util.concurrent.ExecutionException: java.lang.IllegalStateException: JBAS011592: The logging subsystem requires the log manager to be org.jboss.logmanager.LogManager. The subsystem has not be initialized and cannot be used. To use JBoss Log Manager you must add the system property "java.util.logging.manager" and set it to "org.jboss.logmanager.LogManager"
	at java.util.concurrent.FutureTask$Sync.innerGet(FutureTask.java:252)
	at java.util.concurrent.FutureTask.get(FutureTask.java:111)
	at org.jboss.as.controller.extension.ParallelExtensionAddHandler$1.execute(ParallelExtensionAddHandler.java:91)
	... 10 more
Caused by: java.lang.IllegalStateException: JBAS011592: The logging subsystem requires the log manager to be org.jboss.logmanager.LogManager. The subsystem has not be initialized and cannot be used. To use JBoss Log Manager you must add the system property "java.util.logging.manager" and set it to "org.jboss.logmanager.LogManager"
	at org.jboss.as.logging.LoggingExtension.initialize(LoggingExtension.java:103)
	at org.jboss.as.controller.extension.ExtensionAddHandler.initializeExtension(ExtensionAddHandler.java:98)
	at org.jboss.as.controller.extension.ParallelExtensionAddHandler$ExtensionInitializeTask.call(ParallelExtensionAddHandler.java:127)
	at org.jboss.as.controller.extension.ParallelExtensionAddHandler$ExtensionInitializeTask.call(ParallelExtensionAddHandler.java:113)
	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
	at java.util.concurrent.FutureTask.run(FutureTask.java:166)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
	at java.lang.Thread.run(Thread.java:722)
	at org.jboss.threads.JBossThread.run(JBossThread.java:122)

Mar 04, 2014 9:21:03 AM org.jboss.as.server.ServerService boot
FATAL: JBAS015957: Server boot has failed in an unrecoverable manner; exiting. See previous messages for details.



This may be happening because the call to getPlatformMBeanServer(), which was invoked from premain() in jmxetric, has initialized the logger in a bad way and the rest of JBoss can't cope and fails to start.



Anyhow, I then tried the latest version, jmxetric 1.0.6.  It delays the call to getPlatformMBeanServer(), by the amount specified by the initialdelay in jmxetric.xml.  I set it to 20 seconds to test.  With that setting, Wildfly starts OK.  Therefore, this is a workaround for me and for other users who have control over the behavior of their profiling tool (jmxetric is open source) but it may not help everybody.

Ideally, Wildfly should be stable even if some of there are calls to getPlatformMBeanServer() or logging calls from premain()


                
> getPlatformMBeanServer behaves badly when called from premain class such as jmxetric
> ------------------------------------------------------------------------------------
>
>                 Key: WFLY-3054
>                 URL: https://issues.jboss.org/browse/WFLY-3054
>             Project: WildFly
>          Issue Type: Enhancement
>      Security Level: Public(Everyone can see) 
>          Components: JMX
>    Affects Versions: JBoss AS7 7.1.1.Final
>            Reporter: dpocock
>            Assignee: Kabir Khan
>              Labels: jboss
>
> JMXetric is a management agent JAR loaded using the JVM argument 
> java -javaagent:$JARLIBS/jmxetric-1.0.2.jar .....
> In the premain method (executed before JBoss main() is invoked), jmxetric calls the static method:
>    ManagementFactory.getPlatformMBeanServer()
> This puts JMX into a bad state and the jboss.as tree is completely missing when browsed with jconsole
> As a workaround, jmxetric will defer the call to ManagementFactory.getPlatformMBeanServer() using the "initialdelay" parameter set to a value such as 20 seconds.
> However, it would be good if JBoss could act more cleanly in this situation, for example, throwing an exception if ManagementFactory.getPlatformMBeanServer() is called too early, or finding a way to add the "jboss.as" stuff later.
> The 1.0.6 release of jmxetric will include the workaround by default.  The bug can be reproduced by setting initialdelay="0" in the sample jmxetric.xml or using jmxetric 1.0.5
> jmxetric versions before 1.0.5 suffer from issues with the jboss logger as discussed in WFLY-895, so this issue was only discovered after removing the logging statements from jmxetric.
> Also covered in jmxetric github:
> https://github.com/ganglia/jmxetric/issues/9

--
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

From issues at jboss.org  Tue Mar  4 03:39:33 2014
From: issues at jboss.org (dpocock (JIRA))
Date: Tue, 4 Mar 2014 03:39:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-895) JBoss crashes when run with
 AspectJ java agent
In-Reply-To: <JIRA.12458681.1328740621000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12458681.1328740621000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12458681.1328740621000.131.1393922373991@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-895?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12949633#comment-12949633 ] 

dpocock commented on WFLY-895:
------------------------------

There are some related issues in WFLY-3054


                
> JBoss crashes when run with AspectJ java agent
> ----------------------------------------------
>
>                 Key: WFLY-895
>                 URL: https://issues.jboss.org/browse/WFLY-895
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Server
>         Environment: OS X 10.7.2, Ubuntu 11.10
>            Reporter: Jack Lund
>            Assignee: David Lloyd
>              Labels: aspectj, load_time_weaving
>
> When trying to start JBoss with the AspectJ java agent (-javaagent:/path/aspectjweaver.jar) to enable load-time weaving, JBoss crashes with the following stack trace in the logs:
> =========================================================================
>   JBoss Bootstrap Environment
>   JBOSS_HOME: /home/jack/jboss-as-7.1.0.CR1b
>   JAVA: java
>   JAVA_OPTS: -server -javaagent:/home/jack/aspectjweaver.jar -Xms64m -Xmx512m -XX:MaxPermSize=256m -Djava.net.preferIPv4Stack=true -Dorg.jboss.resolver.warning=true -Dsun.rmi.dgc.client.gcInterval=3600000 -Dsun.rmi.dgc.server.gcInterval=3600000 -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true
> =========================================================================
> WARNING: Failed to load the specified logmodule org.jboss.logmanager:main
> Exception in thread "main" java.lang.ExceptionInInitializerError
> 	at org.jboss.as.server.Main.main(Main.java:92)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:616)
> 	at org.jboss.modules.Module.run(Module.java:248)
> 	at org.jboss.modules.Main.main(Main.java:313)
> Caused by: java.lang.IllegalStateException: The LogManager was not properly installed (you must set the "java.util.logging.manager" system property to "org.jboss.logmanager.LogManager")
> 	at org.jboss.logmanager.Logger.getLogger(Logger.java:60)
> 	at org.jboss.logmanager.log4j.BridgeRepositorySelector.<clinit>(BridgeRepositorySelector.java:42)
> 	... 7 more

--
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

From issues at jboss.org  Tue Mar  4 04:03:38 2014
From: issues at jboss.org (dpocock (JIRA))
Date: Tue, 4 Mar 2014 04:03:38 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-895) JBoss crashes when run with
 AspectJ java agent
In-Reply-To: <JIRA.12458681.1328740621000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12458681.1328740621000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12458681.1328740621000.211.1393923818541@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-895?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12949637#comment-12949637 ] 

dpocock commented on WFLY-895:
------------------------------


Here is a full diff of the workaround involving logging settings on the JVM command line, as used to get jmxetric versions before 1.0.5 to work with JBoss:


--- bin/standalone.conf
+++ ../jboss-as-7.1.0.Final.for-jmxetric/bin/standalone.conf
@@ -4,6 +4,7 @@
 ##                                                                          ##
 ##############################################################################
 
+JBOSS_MODULES_SYSTEM_PKGS="org.jboss.logmanager"
 #
 # This file is optional; it may be removed if not needed.
 #
@@ -48,6 +49,8 @@
 #
 if [ "x$JAVA_OPTS" = "x" ]; then
    JAVA_OPTS="-Xms64m -Xmx512m -XX:MaxPermSize=256m -Djava.net.preferIPv4Stack=true -Dorg.jboss.resolver.warning=true -Dsun.rmi.dgc.client.gcInterval=3600000 -Dsun.rmi.dgc.server.gcInterval=3600000"
+   JAVA_OPTS="$JAVA_OPTS -Djava.util.logging.manager=org.jboss.logmanager.LogManager -Xbootclasspath/p:$JBOSS_HOME/modules/org/jboss/logmanager/main/jboss-logmanager-1.2.2.GA.jar -Xbootclasspath/p:$JBOSS_HOME/modules/org/jboss/logmanager/log4j/main/jboss-logmanager-log4j-1.0.0.GA.jar -Xbootclasspath/p:$JBOSS_HOME/modules/org/apache/log4j/main/log4j-1.2.16.jar"
+   JAVA_OPTS="$JAVA_OPTS -javaagent:$HOME/opt/ganglia/jmxetric/jmxetric-1.0.2.jar=host=jboss-host.example.org,port=8649,wireformat31x=true,config=$HOME/opt/ganglia/jmxetric/etc/jmxetric-jboss.xml"
    JAVA_OPTS="$JAVA_OPTS -Djboss.modules.system.pkgs=$JBOSS_MODULES_SYSTEM_PKGS -Djava.awt.headless=true"
    JAVA_OPTS="$JAVA_OPTS -Djboss.server.default.config=standalone.xml"
 else

                
> JBoss crashes when run with AspectJ java agent
> ----------------------------------------------
>
>                 Key: WFLY-895
>                 URL: https://issues.jboss.org/browse/WFLY-895
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Server
>         Environment: OS X 10.7.2, Ubuntu 11.10
>            Reporter: Jack Lund
>            Assignee: David Lloyd
>              Labels: aspectj, load_time_weaving
>
> When trying to start JBoss with the AspectJ java agent (-javaagent:/path/aspectjweaver.jar) to enable load-time weaving, JBoss crashes with the following stack trace in the logs:
> =========================================================================
>   JBoss Bootstrap Environment
>   JBOSS_HOME: /home/jack/jboss-as-7.1.0.CR1b
>   JAVA: java
>   JAVA_OPTS: -server -javaagent:/home/jack/aspectjweaver.jar -Xms64m -Xmx512m -XX:MaxPermSize=256m -Djava.net.preferIPv4Stack=true -Dorg.jboss.resolver.warning=true -Dsun.rmi.dgc.client.gcInterval=3600000 -Dsun.rmi.dgc.server.gcInterval=3600000 -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true
> =========================================================================
> WARNING: Failed to load the specified logmodule org.jboss.logmanager:main
> Exception in thread "main" java.lang.ExceptionInInitializerError
> 	at org.jboss.as.server.Main.main(Main.java:92)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:616)
> 	at org.jboss.modules.Module.run(Module.java:248)
> 	at org.jboss.modules.Main.main(Main.java:313)
> Caused by: java.lang.IllegalStateException: The LogManager was not properly installed (you must set the "java.util.logging.manager" system property to "org.jboss.logmanager.LogManager")
> 	at org.jboss.logmanager.Logger.getLogger(Logger.java:60)
> 	at org.jboss.logmanager.log4j.BridgeRepositorySelector.<clinit>(BridgeRepositorySelector.java:42)
> 	... 7 more

--
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

From issues at jboss.org  Tue Mar  4 04:03:40 2014
From: issues at jboss.org (dpocock (JIRA))
Date: Tue, 4 Mar 2014 04:03:40 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-895) JBoss crashes when run with
 AspectJ java agent
In-Reply-To: <JIRA.12458681.1328740621000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12458681.1328740621000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12458681.1328740621000.229.1393923820591@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-895?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12949638#comment-12949638 ] 

dpocock commented on WFLY-895:
------------------------------

It looks like Jira has messaged up the formatting of that diff
                
> JBoss crashes when run with AspectJ java agent
> ----------------------------------------------
>
>                 Key: WFLY-895
>                 URL: https://issues.jboss.org/browse/WFLY-895
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Server
>         Environment: OS X 10.7.2, Ubuntu 11.10
>            Reporter: Jack Lund
>            Assignee: David Lloyd
>              Labels: aspectj, load_time_weaving
>
> When trying to start JBoss with the AspectJ java agent (-javaagent:/path/aspectjweaver.jar) to enable load-time weaving, JBoss crashes with the following stack trace in the logs:
> =========================================================================
>   JBoss Bootstrap Environment
>   JBOSS_HOME: /home/jack/jboss-as-7.1.0.CR1b
>   JAVA: java
>   JAVA_OPTS: -server -javaagent:/home/jack/aspectjweaver.jar -Xms64m -Xmx512m -XX:MaxPermSize=256m -Djava.net.preferIPv4Stack=true -Dorg.jboss.resolver.warning=true -Dsun.rmi.dgc.client.gcInterval=3600000 -Dsun.rmi.dgc.server.gcInterval=3600000 -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true
> =========================================================================
> WARNING: Failed to load the specified logmodule org.jboss.logmanager:main
> Exception in thread "main" java.lang.ExceptionInInitializerError
> 	at org.jboss.as.server.Main.main(Main.java:92)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:616)
> 	at org.jboss.modules.Module.run(Module.java:248)
> 	at org.jboss.modules.Main.main(Main.java:313)
> Caused by: java.lang.IllegalStateException: The LogManager was not properly installed (you must set the "java.util.logging.manager" system property to "org.jboss.logmanager.LogManager")
> 	at org.jboss.logmanager.Logger.getLogger(Logger.java:60)
> 	at org.jboss.logmanager.log4j.BridgeRepositorySelector.<clinit>(BridgeRepositorySelector.java:42)
> 	... 7 more

--
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

From issues at jboss.org  Tue Mar  4 04:51:34 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 4 Mar 2014 04:51:34 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2773) ClientConfigurationImpl
 should not translate IP address to host name
In-Reply-To: <JIRA.12529691.1389963183000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529691.1389963183000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529691.1389963183000.418.1393926694631@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2773?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12949657#comment-12949657 ] 

RH Bugzilla Integration commented on WFLY-2773:
-----------------------------------------------

Petr Kremensky <pkremens at redhat.com> changed the Status of [bug 1054776|https://bugzilla.redhat.com/show_bug.cgi?id=1054776] from ON_QA to VERIFIED
                
> ClientConfigurationImpl should not translate IP address to host name
> --------------------------------------------------------------------
>
>                 Key: WFLY-2773
>                 URL: https://issues.jboss.org/browse/WFLY-2773
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>    Affects Versions: 8.0.0.CR1
>            Reporter: Jan Martiska
>            Assignee: Jan Martiska
>
> When creating a ModelControllerClient and passing in an IP address, ClientConfigurationImpl internally translates it to a host name, like here:
> {noformat}
> public static ModelControllerClientConfiguration create(final InetAddress address, final int port) {
>         return new ClientConfigurationImpl(address.getHostName(), port, null, null, null, createDefaultExecutor(), true, null);
>     }
> {noformat}
> Later on, when the client connects, it is translated via DNS back to an IP address. This is not only unnecessary, but in some situations, it is wrong.
> Consider a Windows machine having two IP addresses ,A and B, on one network interface, where only A is pointed at by a DNS record. 
> - Run AS testsuite and pass it the address B as the node0 property, AS will bind itself to this address.
> - Now when a test creates a ModelControllerClient using IP address B, the address B will get translated to the host name, even though B is not in the DNS. The resolving works this way on a Windows machine.
> - During the connection, the host name will get resolved by DNS to address A and the test will try to connect through address A. The connection will be refused, or worse, might connect to another instance on the same machine.

--
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

From issues at jboss.org  Tue Mar  4 04:53:33 2014
From: issues at jboss.org (Dominik Pospisil (JIRA))
Date: Tue, 4 Mar 2014 04:53:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3060) Rare KrbException: Request is
 a replay issue in negotiation tests
In-Reply-To: <JIRA.12533921.1393926730596@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12533921.1393926730596@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12533921.1393926730596.424.1393926813748@jira02.app.mwc.hst.phx2.redhat.com>

Dominik Pospisil created WFLY-3060:
--------------------------------------

             Summary: Rare KrbException: Request is a replay issue in negotiation tests
                 Key: WFLY-3060
                 URL: https://issues.jboss.org/browse/WFLY-3060
             Project: WildFly
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Test Suite
    Affects Versions: 8.0.0.Final
            Reporter: Dominik Pospisil
            Assignee: Ondrej Zizka




--
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

From issues at jboss.org  Tue Mar  4 04:55:33 2014
From: issues at jboss.org (Dominik Pospisil (JIRA))
Date: Tue, 4 Mar 2014 04:55:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3060) Rare KrbException: Request is
 a replay issue in negotiation tests
In-Reply-To: <JIRA.12533921.1393926730000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12533921.1393926730000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12533921.1393926730000.432.1393926933514@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-3060?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Dominik Pospisil updated WFLY-3060:
-----------------------------------

    Description: 
The failures happend while sending second TGS-REQ ticket from client to kerberos KDC server.
The cause seems to be a limitation of ApacheDS kerberos server used in the test case. The ApacheDS employs simple replay detection mechanism based on in-memory ticket cache service. The cache stores client and server credentials and ticket timestamp. Specificaly, the cache do not store ticket content.
During GSS SecContext establishment, there are 2 TGS-REQ tickets sent from the client (sun.security.jgss.krb5.GSSContextSpi). First to acquire service credentials ticket and second to get SecContext ticket. The second ticket is being send immediatelly after the fisrt one. If the second (valid) ticket is sent with the same timestamp as the first one, the ApacheDS treats the second one as a false positive and throw Request is a replay kerberos exception.

    
> Rare KrbException: Request is a replay issue in negotiation tests
> -----------------------------------------------------------------
>
>                 Key: WFLY-3060
>                 URL: https://issues.jboss.org/browse/WFLY-3060
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite
>    Affects Versions: 8.0.0.Final
>            Reporter: Dominik Pospisil
>            Assignee: Ondrej Zizka
>
> The failures happend while sending second TGS-REQ ticket from client to kerberos KDC server.
> The cause seems to be a limitation of ApacheDS kerberos server used in the test case. The ApacheDS employs simple replay detection mechanism based on in-memory ticket cache service. The cache stores client and server credentials and ticket timestamp. Specificaly, the cache do not store ticket content.
> During GSS SecContext establishment, there are 2 TGS-REQ tickets sent from the client (sun.security.jgss.krb5.GSSContextSpi). First to acquire service credentials ticket and second to get SecContext ticket. The second ticket is being send immediatelly after the fisrt one. If the second (valid) ticket is sent with the same timestamp as the first one, the ApacheDS treats the second one as a false positive and throw Request is a replay kerberos exception.

--
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

From issues at jboss.org  Tue Mar  4 05:21:33 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 4 Mar 2014 05:21:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (SECURITY-795) AdvancedLdap login module
 does not handle a user that has a slash character in the uid
In-Reply-To: <JIRA.12532238.1392392424000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12532238.1392392424000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12532238.1392392424000.486.1393928493495@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/SECURITY-795?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12949662#comment-12949662 ] 

RH Bugzilla Integration commented on SECURITY-795:
--------------------------------------------------

Ondrej Lukas <olukas at redhat.com> changed the Status of [bug 1065515|https://bugzilla.redhat.com/show_bug.cgi?id=1065515] from ON_QA to VERIFIED
                
> AdvancedLdap login module does not handle a user that has a slash character in the uid
> --------------------------------------------------------------------------------------
>
>                 Key: SECURITY-795
>                 URL: https://issues.jboss.org/browse/SECURITY-795
>             Project: PicketBox 
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Negotiation
>    Affects Versions: Negotiation_2_2_5
>            Reporter: Derek Horton
>            Assignee: Derek Horton
>             Fix For: Negotiation_2_2_7
>
>         Attachments: SECURITY-795.patch
>
>
> AdvancedLdap login module does not handle a user that has a slash character in the uid.
> For example, JBoss will fail to authenticate the following user correctly:
> dn: uid=weird/user,ou=Users,dc=my-domain,dc=com
> uid: weird/user
> cn: Weird User

--
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

From issues at jboss.org  Tue Mar  4 05:29:34 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 4 Mar 2014 05:29:34 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-314) EE subsystem global modules
 should support annotation flag
In-Reply-To: <JIRA.12475698.1348784035000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12475698.1348784035000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12475698.1348784035000.535.1393928974801@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-314?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12949670#comment-12949670 ] 

RH Bugzilla Integration commented on WFLY-314:
----------------------------------------------

Jan Martiska <jmartisk at redhat.com> changed the Status of [bug 1009166|https://bugzilla.redhat.com/show_bug.cgi?id=1009166] from ON_QA to VERIFIED
                
> EE subsystem global modules should support annotation flag
> ----------------------------------------------------------
>
>                 Key: WFLY-314
>                 URL: https://issues.jboss.org/browse/WFLY-314
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: EE
>            Reporter: James Livingston
>            Assignee: Stuart Douglas
>             Fix For: 8.0.0.Alpha1
>
>
> Annotation indexes aren't imported with modules by default, but you can specify the annotation flag in the manifest Dependencies line or the annotation attribute in jboss-deployment-structure.xml.
> The EE subsystem's global modules section does not let you specify that option, which means you can't define EJB interceptors and similar things in global modules. It should let you do that.

--
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

From issues at jboss.org  Tue Mar  4 05:31:33 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 4 Mar 2014 05:31:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (SECURITY-796) LdapExtended login module
 does not handle a user that has a slash character in the uid
In-Reply-To: <JIRA.12532239.1392392477000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12532239.1392392477000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12532239.1392392477000.540.1393929093458@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/SECURITY-796?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12949671#comment-12949671 ] 

RH Bugzilla Integration commented on SECURITY-796:
--------------------------------------------------

Ondrej Lukas <olukas at redhat.com> changed the Status of [bug 1067599|https://bugzilla.redhat.com/show_bug.cgi?id=1067599] from ON_QA to VERIFIED
                
> LdapExtended login module does not handle a user that has a slash character in the uid
> --------------------------------------------------------------------------------------
>
>                 Key: SECURITY-796
>                 URL: https://issues.jboss.org/browse/SECURITY-796
>             Project: PicketBox 
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: PicketBox
>    Affects Versions: PicketBox_4_0_20.Final
>            Reporter: Derek Horton
>            Assignee: Stefan Guilhen
>         Attachments: SECURITY-796.patch
>
>
> LdapExtended login module does not handle a user that has a slash character in the uid.
> For example, JBoss will fail to authenticate the following user correctly:
> dn: uid=weird/user,ou=Users,dc=my-domain,dc=com
> uid: weird/user
> cn: Weird User

--
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

From issues at jboss.org  Tue Mar  4 05:31:34 2014
From: issues at jboss.org (Ryan Emerson (JIRA))
Date: Tue, 4 Mar 2014 05:31:34 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1785) TOA,
	inconsistent message delivery
In-Reply-To: <JIRA.12530413.1390836354000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530413.1390836354000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530413.1390836354000.551.1393929094181@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JGRP-1785?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ryan Emerson resolved JGRP-1785.
--------------------------------

    Resolution: Done


Issue resolved, thanks.
                
> TOA, inconsistent message delivery
> ----------------------------------
>
>                 Key: JGRP-1785
>                 URL: https://issues.jboss.org/browse/JGRP-1785
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.5
>         Environment: Fedora release 17 (Beefy Miracle)
>            Reporter: Ryan Emerson
>            Assignee: Pedro Ruivo
>             Fix For: 3.5
>
>
> When sending total order messages between two nodes, for a prolonged period of time, an inconsistency is encountered when comparing each node's total order of messages.  
> I believe this issue is related to how sequence numbers are handled in the implementation, not the protocol itself.  I appreciate that TOA is designed for environments where the subset of destinations in the network varies, however I have been unable to reproduce this error when the total number of nodes is > 2.  It is still possible that this inconsistency may occur after a large amount of time when the number of nodes is > 2.  

--
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

From issues at jboss.org  Tue Mar  4 05:35:37 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 4 Mar 2014 05:35:37 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2995) Using a log4j appender as a
 custom-handler should invoke the activateOptions if required
In-Reply-To: <JIRA.12531830.1392162970000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12531830.1392162970000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12531830.1392162970000.567.1393929337152@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2995?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12949676#comment-12949676 ] 

RH Bugzilla Integration commented on WFLY-2995:
-----------------------------------------------

Michal Babacek <mbabacek at redhat.com> changed the Status of [bug 1066606|https://bugzilla.redhat.com/show_bug.cgi?id=1066606] from ON_QA to VERIFIED
                
> Using a log4j appender as a custom-handler should invoke the activateOptions if required
> ----------------------------------------------------------------------------------------
>
>                 Key: WFLY-2995
>                 URL: https://issues.jboss.org/browse/WFLY-2995
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: James Perkins
>            Assignee: James Perkins
>             Fix For: 8.0.1.Final
>
>
> Currently the {{OptionHandler.activateOptions}} is only invoked during construction of a log4j appender. This invocation should happen if any property is updated or added. The invocation of this method should also only happen once. Multiple invocation could result in errors or leave the appender in an invalid state.

--
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

From issues at jboss.org  Tue Mar  4 05:35:38 2014
From: issues at jboss.org (Gytis Trikleris (JIRA))
Date: Tue, 4 Mar 2014 05:35:38 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3042) There should be a warning
 logged if the default value of node identifier has not been changed.
In-Reply-To: <JIRA.12533608.1393595350000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12533608.1393595350000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12533608.1393595350000.574.1393929338513@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-3042?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12949677#comment-12949677 ] 

Gytis Trikleris commented on WFLY-3042:
---------------------------------------

[~raggz], is it enough to raise a PR for this on Wildfly, or should I raise one for EAP 6.x as well?
                
> There should be a warning logged if the default value of node identifier has not been changed.  
> ------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-3042
>                 URL: https://issues.jboss.org/browse/WFLY-3042
>             Project: WildFly
>          Issue Type: Enhancement
>      Security Level: Public(Everyone can see) 
>          Components: Transactions
>    Affects Versions: 8.0.0.Final
>         Environment: JBoss EAP 6.x
>            Reporter: Tom Ross
>            Assignee: Gytis Trikleris
>
> JBoss EAP instance is using the value of node identifier  to identify XA transactions that belong to it. By default this value is set to 1. Now days in most environments there will be multiple JBoss instances sharing XA resources there for it is necessary to set the value of node identifier to a unique value for each instance. This is something that most end users fail to perform. Therefor it would be helpful if  a warning  message was logged at startup telling the user to do it.

--
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

From issues at jboss.org  Tue Mar  4 05:45:34 2014
From: issues at jboss.org (Gytis Trikleris (JIRA))
Date: Tue, 4 Mar 2014 05:45:34 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3042) There should be a warning
 logged if the default value of node identifier has not been changed.
In-Reply-To: <JIRA.12533608.1393595350000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12533608.1393595350000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12533608.1393595350000.596.1393929934208@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-3042?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Gytis Trikleris updated WFLY-3042:
----------------------------------

    Git Pull Request: https://github.com/wildfly/wildfly/pull/5976  (was: https://github.com/wildfly/wildfly/pull/5976, https://github.com/jbossas/jboss-eap/pull/997)

    
> There should be a warning logged if the default value of node identifier has not been changed.  
> ------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-3042
>                 URL: https://issues.jboss.org/browse/WFLY-3042
>             Project: WildFly
>          Issue Type: Enhancement
>      Security Level: Public(Everyone can see) 
>          Components: Transactions
>    Affects Versions: 8.0.0.Final
>         Environment: JBoss EAP 6.x
>            Reporter: Tom Ross
>            Assignee: Gytis Trikleris
>
> JBoss EAP instance is using the value of node identifier  to identify XA transactions that belong to it. By default this value is set to 1. Now days in most environments there will be multiple JBoss instances sharing XA resources there for it is necessary to set the value of node identifier to a unique value for each instance. This is something that most end users fail to perform. Therefor it would be helpful if  a warning  message was logged at startup telling the user to do it.

--
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

From issues at jboss.org  Tue Mar  4 06:01:35 2014
From: issues at jboss.org (Gytis Trikleris (JIRA))
Date: Tue, 4 Mar 2014 06:01:35 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3042) There should be a warning
 logged if the default value of node identifier has not been changed.
In-Reply-To: <JIRA.12533608.1393595350000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12533608.1393595350000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12533608.1393595350000.675.1393930895546@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-3042?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Gytis Trikleris reopened WFLY-3042:
-----------------------------------


    
> There should be a warning logged if the default value of node identifier has not been changed.  
> ------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-3042
>                 URL: https://issues.jboss.org/browse/WFLY-3042
>             Project: WildFly
>          Issue Type: Enhancement
>      Security Level: Public(Everyone can see) 
>          Components: Transactions
>    Affects Versions: 8.0.0.Final
>         Environment: JBoss EAP 6.x
>            Reporter: Tom Ross
>            Assignee: Gytis Trikleris
>
> JBoss EAP instance is using the value of node identifier  to identify XA transactions that belong to it. By default this value is set to 1. Now days in most environments there will be multiple JBoss instances sharing XA resources there for it is necessary to set the value of node identifier to a unique value for each instance. This is something that most end users fail to perform. Therefor it would be helpful if  a warning  message was logged at startup telling the user to do it.

--
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

From issues at jboss.org  Tue Mar  4 06:11:34 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 4 Mar 2014 06:11:34 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3042) There should be a warning
 logged if the default value of node identifier has not been changed.
In-Reply-To: <JIRA.12533608.1393595350000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12533608.1393595350000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12533608.1393595350000.719.1393931494245@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-3042?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated WFLY-3042:
------------------------------------------

        Bugzilla Update: Perform
    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1072312

    
> There should be a warning logged if the default value of node identifier has not been changed.  
> ------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-3042
>                 URL: https://issues.jboss.org/browse/WFLY-3042
>             Project: WildFly
>          Issue Type: Enhancement
>      Security Level: Public(Everyone can see) 
>          Components: Transactions
>    Affects Versions: 8.0.0.Final
>         Environment: JBoss EAP 6.x
>            Reporter: Tom Ross
>            Assignee: Gytis Trikleris
>
> JBoss EAP instance is using the value of node identifier  to identify XA transactions that belong to it. By default this value is set to 1. Now days in most environments there will be multiple JBoss instances sharing XA resources there for it is necessary to set the value of node identifier to a unique value for each instance. This is something that most end users fail to perform. Therefor it would be helpful if  a warning  message was logged at startup telling the user to do it.

--
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

From issues at jboss.org  Tue Mar  4 06:23:33 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 4 Mar 2014 06:23:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2995) Using a log4j appender as a
 custom-handler should invoke the activateOptions if required
In-Reply-To: <JIRA.12531830.1392162970000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12531830.1392162970000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12531830.1392162970000.741.1393932213843@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2995?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12949702#comment-12949702 ] 

RH Bugzilla Integration commented on WFLY-2995:
-----------------------------------------------

Petr Kremensky <pkremens at redhat.com> changed the Status of [bug 1066607|https://bugzilla.redhat.com/show_bug.cgi?id=1066607] from ON_QA to VERIFIED
                
> Using a log4j appender as a custom-handler should invoke the activateOptions if required
> ----------------------------------------------------------------------------------------
>
>                 Key: WFLY-2995
>                 URL: https://issues.jboss.org/browse/WFLY-2995
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: James Perkins
>            Assignee: James Perkins
>             Fix For: 8.0.1.Final
>
>
> Currently the {{OptionHandler.activateOptions}} is only invoked during construction of a log4j appender. This invocation should happen if any property is updated or added. The invocation of this method should also only happen once. Multiple invocation could result in errors or leave the appender in an invalid state.

--
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

From issues at jboss.org  Tue Mar  4 06:27:33 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 4 Mar 2014 06:27:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2266) Deployment Overlay feature is
 not able to replace the application libraries.
In-Reply-To: <JIRA.12502513.1381301201000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502513.1381301201000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502513.1381301201000.751.1393932453279@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2266?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12949704#comment-12949704 ] 

RH Bugzilla Integration commented on WFLY-2266:
-----------------------------------------------

Jan Martiska <jmartisk at redhat.com> changed the Status of [bug 1016995|https://bugzilla.redhat.com/show_bug.cgi?id=1016995] from ON_QA to VERIFIED
                
> Deployment Overlay feature is not able to replace the application libraries.
> ----------------------------------------------------------------------------
>
>                 Key: WFLY-2266
>                 URL: https://issues.jboss.org/browse/WFLY-2266
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>    Affects Versions: 8.0.0.Beta1
>         Environment: All Operating Systems
>            Reporter: Jay Kumar SenSharma
>            Assignee: Stuart Douglas
>              Labels: deployment
>             Fix For: 8.0.0.CR1
>
>
> -----------------------
>    According to the documentation: [1] the deployment overlay feature is applicable for "swapping out deployment descriptors, modifying static web resources to change the branding of an application, or even replacing jar libraries with different versions."   
>    Here it talks about "replacing jar libraries" which is not working as expected and causes  the following error.
> [1] https://docs.jboss.org/author/display/AS72/Deployment+Overlays
> Follow the below sequence of deployment and overlay:
> Steps to Reproduce:
> ------------------
> *Step-1).* Undeploy if any existing application is deployed  and then freshly deploy the application.
> {quote}
> [standalone at localhost:9999 /] undeploy DeploymentOverlayDemo.war 
> [standalone at localhost:9999 /] deploy /home/jaysensharma/TestApp/build/DeploymentOverlayDemo.war
> {quote}
> *Step-2).* Make some changes in java code _"Hello.java"_ . Create a new JAR  Hello.jar which we want to replace at _(/WEB-INF/lib/Hello.jar)_ using deployment-overlay feature.  In the attached ant based Demo just do _"ant compile"_  to create a new Jar _"${project.dir}/tmp/Hello.jar"_
> *Step-3).* Use the following command in order to replace the "/WEB-INF/lib/Hello.jar" with the newly created Hello.jar using deployment overlay feature as following:
> {quote}
> [standalone at localhost:9999 /] deployment-overlay add --name=myOverLay_1 --content=/WEB-INF/lib/Hello.jar=/home/jaysensharma/TestApp/tmp/Hello.jar --deployments=DeploymentOverlayDemo.war --redeploy-affected
> {quote}
>   
>    Above causes the following Exception:
> {quote}
> 12:09:59,736 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-2) JBAS018224: Unregister web context: /DeploymentOverlayDemo
> 12:09:59,760 WARN  [org.wildfly.extension.undertow] (MSC service thread 1-2) JBAS017530: Could not delete servlet temp file /NotBackedUp/SVN_16_Jan/WildFly/build_Apps/wildfly-8.0.0.Beta2-SNAPSHOT/standalone/tmp/DeploymentOverlayDemo.war/org/apache/jsp
> 12:09:59,761 WARN  [org.wildfly.extension.undertow] (MSC service thread 1-2) JBAS017530: Could not delete servlet temp file /NotBackedUp/SVN_16_Jan/WildFly/build_Apps/wildfly-8.0.0.Beta2-SNAPSHOT/standalone/tmp/DeploymentOverlayDemo.war/org/apache
> 12:09:59,761 WARN  [org.wildfly.extension.undertow] (MSC service thread 1-2) JBAS017530: Could not delete servlet temp file /NotBackedUp/SVN_16_Jan/WildFly/build_Apps/wildfly-8.0.0.Beta2-SNAPSHOT/standalone/tmp/DeploymentOverlayDemo.war/org
> 12:09:59,762 WARN  [org.wildfly.extension.undertow] (MSC service thread 1-2) JBAS017530: Could not delete servlet temp file /NotBackedUp/SVN_16_Jan/WildFly/build_Apps/wildfly-8.0.0.Beta2-SNAPSHOT/standalone/tmp/DeploymentOverlayDemo.war
> 12:09:59,787 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-5) JBAS015877: Stopped deployment DeploymentOverlayDemo.war (runtime-name: DeploymentOverlayDemo.war) in 56ms
> 12:09:59,789 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-8) JBAS015876: Starting deployment of "DeploymentOverlayDemo.war" (runtime-name: "DeploymentOverlayDemo.war")
> 12:09:59,799 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-8) MSC000001: Failed to start service jboss.deployment.unit."DeploymentOverlayDemo.war".STRUCTURE: org.jboss.msc.service.StartException in service jboss.deployment.unit."DeploymentOverlayDemo.war".STRUCTURE: JBAS018733: Failed to process phase STRUCTURE of deployment "DeploymentOverlayDemo.war"
> 	at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:166) [wildfly-server-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> 	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]
> 	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: org.jboss.as.server.deployment.DeploymentUnitProcessingException: JBAS018776: Failed to get content for deployment overlay myOverLay_1 at /WEB-INF/lib/Hello.jar
> 	at org.jboss.as.server.deployment.ContentOverrideDeploymentUnitProcessor.deploy(ContentOverrideDeploymentUnitProcessor.java:70) [wildfly-server-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> 	at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:159) [wildfly-server-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> 	... 5 more
> Caused by: java.io.IOException: VFS000017: Filesystem already mounted at mount point ""/content/DeploymentOverlayDemo.war/WEB-INF/lib/Hello.jar""
> 	at org.jboss.vfs.VFS.mount(VFS.java:127) [jboss-vfs-3.2.2.Final.jar:3.2.2.Final]
> 	at org.jboss.vfs.VFS.doMount(VFS.java:336) [jboss-vfs-3.2.2.Final.jar:3.2.2.Final]
> 	at org.jboss.vfs.VFS.mountReal(VFS.java:423) [jboss-vfs-3.2.2.Final.jar:3.2.2.Final]
> 	at org.jboss.as.server.deployment.ContentOverrideDeploymentUnitProcessor.deploy(ContentOverrideDeploymentUnitProcessor.java:67) [wildfly-server-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> 	... 6 more
> 12:09:59,805 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 3) JBAS014613: Operation ("redeploy") failed - address: ([("deployment" => "DeploymentOverlayDemo.war")]) - failure description: {"JBAS014671: Failed services" => {"jboss.deployment.unit.\"DeploymentOverlayDemo.war\".STRUCTURE" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.\"DeploymentOverlayDemo.war\".STRUCTURE: JBAS018733: Failed to process phase STRUCTURE of deployment \"DeploymentOverlayDemo.war\"
>     Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: JBAS018776: Failed to get content for deployment overlay myOverLay_1 at /WEB-INF/lib/Hello.jar
>     Caused by: java.io.IOException: VFS000017: Filesystem already mounted at mount point \"\"/content/DeploymentOverlayDemo.war/WEB-INF/lib/Hello.jar\"\""}}
> 12:09:59,809 ERROR [org.jboss.as.server] (management-handler-thread - 3) JBAS015860: Redeploy of deployment "DeploymentOverlayDemo.war" was rolled back with the following failure message: 
> {"JBAS014671: Failed services" => {"jboss.deployment.unit.\"DeploymentOverlayDemo.war\".STRUCTURE" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.\"DeploymentOverlayDemo.war\".STRUCTURE: JBAS018733: Failed to process phase STRUCTURE of deployment \"DeploymentOverlayDemo.war\"
>     Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: JBAS018776: Failed to get content for deployment overlay myOverLay_1 at /WEB-INF/lib/Hello.jar
>     Caused by: java.io.IOException: VFS000017: Filesystem already mounted at mount point \"\"/content/DeploymentOverlayDemo.war/WEB-INF/lib/Hello.jar\"\""}}
> 12:09:59,814 INFO  [org.jboss.as.controller] (management-handler-thread - 3) JBAS014774: Service status report
> JBAS014777:   Services which failed to start:      service jboss.deployment.unit."DeploymentOverlayDemo.war".STRUCTURE: org.jboss.msc.service.StartException in service jboss.deployment.unit."DeploymentOverlayDemo.war".STRUCTURE: JBAS018733: Failed to process phase STRUCTURE of deployment "DeploymentOverlayDemo.war"
> {quote}

--
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

From issues at jboss.org  Tue Mar  4 06:35:34 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 4 Mar 2014 06:35:34 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3042) There should be a warning
 logged if the default value of node identifier has not been changed.
In-Reply-To: <JIRA.12533608.1393595350000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12533608.1393595350000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12533608.1393595350000.795.1393932934651@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-3042?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12949711#comment-12949711 ] 

RH Bugzilla Integration commented on WFLY-3042:
-----------------------------------------------

Kabir Khan <kkhan at redhat.com> changed the Status of [bug 1072312|https://bugzilla.redhat.com/show_bug.cgi?id=1072312] from NEW to POST
                
> There should be a warning logged if the default value of node identifier has not been changed.  
> ------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-3042
>                 URL: https://issues.jboss.org/browse/WFLY-3042
>             Project: WildFly
>          Issue Type: Enhancement
>      Security Level: Public(Everyone can see) 
>          Components: Transactions
>    Affects Versions: 8.0.0.Final
>         Environment: JBoss EAP 6.x
>            Reporter: Tom Ross
>            Assignee: Gytis Trikleris
>
> JBoss EAP instance is using the value of node identifier  to identify XA transactions that belong to it. By default this value is set to 1. Now days in most environments there will be multiple JBoss instances sharing XA resources there for it is necessary to set the value of node identifier to a unique value for each instance. This is something that most end users fail to perform. Therefor it would be helpful if  a warning  message was logged at startup telling the user to do it.

--
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

From issues at jboss.org  Tue Mar  4 06:51:33 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 4 Mar 2014 06:51:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2536) NPE in cli is thrown when
 using preserve, override without parameter
In-Reply-To: <JIRA.12525558.1384866491000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12525558.1384866491000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12525558.1384866491000.867.1393933893961@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12949721#comment-12949721 ] 

RH Bugzilla Integration commented on WFLY-2536:
-----------------------------------------------

Kabir Khan <kkhan at redhat.com> changed the Status of [bug 1032041|https://bugzilla.redhat.com/show_bug.cgi?id=1032041] from ON_QA to MODIFIED
                
> NPE in cli is thrown when using preserve, override without parameter
> --------------------------------------------------------------------
>
>                 Key: WFLY-2536
>                 URL: https://issues.jboss.org/browse/WFLY-2536
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Patching
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Emanuel Muckenhuber
>            Assignee: Alexey Loubyansky
>            Priority: Minor
>             Fix For: 8.0.0.CR1
>
>


--
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

From issues at jboss.org  Tue Mar  4 06:57:33 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 4 Mar 2014 06:57:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1594) Domain Management logout
 'feature' not working for HTTP BASIC authentication.
In-Reply-To: <JIRA.12495179.1372271000000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12495179.1372271000000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12495179.1372271000000.905.1393934253122@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1594?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12949728#comment-12949728 ] 

RH Bugzilla Integration commented on WFLY-1594:
-----------------------------------------------

Ondrej Lukas <olukas at redhat.com> changed the Status of [bug 976917|https://bugzilla.redhat.com/show_bug.cgi?id=976917] from ON_QA to VERIFIED
                
> Domain Management logout 'feature' not working for HTTP BASIC authentication.
> -----------------------------------------------------------------------------
>
>                 Key: WFLY-1594
>                 URL: https://issues.jboss.org/browse/WFLY-1594
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management, Security
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 8.0.0.Final
>
>
> The logout capability assumes Digest authentication, where we have used LDAP for authentication we only use BASIC authentication.

--
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

From issues at jboss.org  Tue Mar  4 07:01:33 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 4 Mar 2014 07:01:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2370) NPE in
	DelegatingServerInventory
In-Reply-To: <JIRA.12508635.1382579451000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508635.1382579451000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508635.1382579451000.914.1393934493665@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2370?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12949729#comment-12949729 ] 

RH Bugzilla Integration commented on WFLY-2370:
-----------------------------------------------

Petr Kremensky <pkremens at redhat.com> changed the Status of [bug 1024109|https://bugzilla.redhat.com/show_bug.cgi?id=1024109] from ON_QA to VERIFIED
                
> NPE in DelegatingServerInventory
> --------------------------------
>
>                 Key: WFLY-2370
>                 URL: https://issues.jboss.org/browse/WFLY-2370
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Brian Stansberry
>            Assignee: Brian Stansberry
>             Fix For: 8.0.0.CR1
>
>
> http://brontes.lab.eng.brq.redhat.com/viewLog.html?buildId=4738&tab=buildResultsDiv&buildTypeId=WF_MasterIgnoreWindowsDomainOnly
> Test failure:
> java.lang.AssertionError
>     at org.junit.Assert.fail(Assert.java:86)
>     at org.junit.Assert.assertTrue(Assert.java:41)
>     at org.junit.Assert.assertTrue(Assert.java:52)
>     at org.jboss.as.test.integration.domain.DomainControllerMigrationTestCase.testDCFailover(DomainControllerMigrationTestCase.java:223)
> This appears in the log:
> [Host Controller] 03:26:38,028 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 4) JBAS014612: Operation ("read-attribute") failed - address: ([
> [Host Controller]     ("host" => "failover-h1"),
> [Host Controller]     ("server-config" => "failover-one")
> [Host Controller] ]): java.lang.NullPointerException
> [Host Controller]     at org.jboss.as.host.controller.DomainModelControllerService$DelegatingServerInventory.determineServerStatus(DomainModelControllerService.java:788)
> [Host Controller]     at org.jboss.as.host.controller.operations.ServerStatusHandler.execute(ServerStatusHandler.java:66)
> [Host Controller]     at org.jboss.as.controller.operations.global.ReadAttributeHandler.doExecuteInternal(ReadAttributeHandler.java:177) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller]     at org.jboss.as.controller.operations.global.ReadAttributeHandler.doExecute(ReadAttributeHandler.java:97) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller]     at org.jboss.as.controller.operations.global.GlobalOperationHandlers$AbstractMultiTargetHandler.execute(GlobalOperationHandlers.java:151) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]

--
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

From issues at jboss.org  Tue Mar  4 07:15:36 2014
From: issues at jboss.org (Davide Sottara (JIRA))
Date: Tue, 4 Mar 2014 07:15:36 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-441) drools-guvnor 5.5,
 declarative model, create more than one fact type,
 BPMN process does not load
In-Reply-To: <JIRA.12533209.1393317312000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12533209.1393317312000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12533209.1393317312000.945.1393935336147@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/DROOLS-441?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12949734#comment-12949734 ] 

Davide Sottara commented on DROOLS-441:
---------------------------------------

I haven't had the time to reproduce it, but I suspect that when the package is reloaded, the (re)declaration of the beans is prohibited. There were some issues with redeclarations that have been fixed in later versions. If this was the case, the second build of the package would fail and the new process would not be loaded.
Can you try to declare the beans in a separate package and see what happens?
Thanks

                
> drools-guvnor 5.5, declarative model, create more than one fact type, BPMN process does not load
> ------------------------------------------------------------------------------------------------
>
>                 Key: DROOLS-441
>                 URL: https://issues.jboss.org/browse/DROOLS-441
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.5.0.Final
>         Environment: Tomcat 6.0.35, jBPM 5.5.Final
>            Reporter: niraj gupta
>            Assignee: Mark Proctor
>              Labels: drools-guvnor
>
>  I am using ?drools-guvnor 5.5.0.Final? open source tool for designing the business process (BPMN2). I end up in an issue and looking for help. Following is the scenario
> I created a package then process then after build, deploy execute successfully. Now I came back to guvnor and made few changes in the process. Then after same build, deploy execute successfully. But now this time I am creating a declarative model having 2 facts, also modifying business process. Then after same build, deploy execute successfully. This time modified/latest business process doesn?t load into console. This is my problem.  However I trouble shoot and google following are my observations:
> ?	I am running this application in tomcat 6.0.35
> ?	It works perfectly with POJO Model Jar approach.
> ?	It works perfectly with declarative model but having single fact.
> ?	I am not seeing any exceptions either in UI or console logs

--
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


From issues at jboss.org  Tue Mar  4 07:47:34 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 4 Mar 2014 07:47:34 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (SECURITY-795) AdvancedLdap login module
 does not handle a user that has a slash character in the uid
In-Reply-To: <JIRA.12532238.1392392424000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12532238.1392392424000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12532238.1392392424000.1005.1393937254237@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/SECURITY-795?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12949741#comment-12949741 ] 

RH Bugzilla Integration commented on SECURITY-795:
--------------------------------------------------

FIlip Bogyai <fbogyai at redhat.com> changed the Status of [bug 1039955|https://bugzilla.redhat.com/show_bug.cgi?id=1039955] from ON_QA to VERIFIED
                
> AdvancedLdap login module does not handle a user that has a slash character in the uid
> --------------------------------------------------------------------------------------
>
>                 Key: SECURITY-795
>                 URL: https://issues.jboss.org/browse/SECURITY-795
>             Project: PicketBox 
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Negotiation
>    Affects Versions: Negotiation_2_2_5
>            Reporter: Derek Horton
>            Assignee: Derek Horton
>             Fix For: Negotiation_2_2_7
>
>         Attachments: SECURITY-795.patch
>
>
> AdvancedLdap login module does not handle a user that has a slash character in the uid.
> For example, JBoss will fail to authenticate the following user correctly:
> dn: uid=weird/user,ou=Users,dc=my-domain,dc=com
> uid: weird/user
> cn: Weird User

--
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

From issues at jboss.org  Tue Mar  4 07:47:34 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 4 Mar 2014 07:47:34 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (SECURITY-772) SPNEGOLoginModule does not
 always respect removeRealmFromPrincipal
In-Reply-To: <JIRA.12527439.1386675431000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12527439.1386675431000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12527439.1386675431000.1007.1393937254330@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/SECURITY-772?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12949742#comment-12949742 ] 

RH Bugzilla Integration commented on SECURITY-772:
--------------------------------------------------

FIlip Bogyai <fbogyai at redhat.com> changed the Status of [bug 1039955|https://bugzilla.redhat.com/show_bug.cgi?id=1039955] from ON_QA to VERIFIED
                
> SPNEGOLoginModule does not always respect removeRealmFromPrincipal
> ------------------------------------------------------------------
>
>                 Key: SECURITY-772
>                 URL: https://issues.jboss.org/browse/SECURITY-772
>             Project: PicketBox 
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Negotiation
>    Affects Versions: Negotiation_2_2_6
>            Reporter: Tom Fonteyne
>            Assignee: Tom Fonteyne
>            Priority: Minor
>             Fix For: Negotiation_2_2_7
>
>
> org.jboss.security.negotiation.spnego.SPNEGOLoginModule
> private class AcceptSecContext:
>  if (gssContext.isEstablished())
>  {
>      log.warn("Authentication was performed despite already being authenticated!");
>      // TODO - Refactor to only do this once.
>     setIdentity(new KerberosPrincipal(gssContext.getSrcName().toString()));
> The last line should obey the "removeRealmFromPrincipal" flag similarly as a bit further down:
>  setIdentity(createIdentity(gssContext.getSrcName().toString()));

--
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

From issues at jboss.org  Tue Mar  4 07:53:33 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 4 Mar 2014 07:53:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-822) MBean created via
 EAR/META-INF/jboss-service.xml from class defined in JBoss module gets
 wrong TCCL
In-Reply-To: <JIRA.12475332.1348586276000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12475332.1348586276000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12475332.1348586276000.1012.1393937613693@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-822?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12949743#comment-12949743 ] 

RH Bugzilla Integration commented on WFLY-822:
----------------------------------------------

Jan Martiska <jmartisk at redhat.com> changed the Status of [bug 1054972|https://bugzilla.redhat.com/show_bug.cgi?id=1054972] from ON_QA to VERIFIED
                
> MBean created via EAR/META-INF/jboss-service.xml from class defined in JBoss module gets wrong TCCL
> ---------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-822
>                 URL: https://issues.jboss.org/browse/WFLY-822
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Class Loading, Server
>         Environment: Java 6u31
>            Reporter: Zachary Bedell
>            Assignee: jaikiran pai
>              Labels: classloader, mbean, modules
>             Fix For: 8.0.0.Alpha3
>
>         Attachments: SarTcclTst.tbz
>
>
> When an MBean is loaded from jboss-service.xml within an EAR, the TCCL should point to the EAR deployment so that config files and other resources can be classloaded from the EAR.  Under JBoss 7.1.1.Final, the TCCL in a module loaded MBean's start() method is the module's ClassLoader.  No reference to the EAR deployment's classloader is available, thus EAR resources are not available within the MBean.
> It appears that org.jboss.as.service.AbstractService::invokeLifecycleMethod() incorrectly sets the TCCL to the module's defining classloader rather than the EAR's:
> {{{
> protected void invokeLifecycleMethod(final Method method) throws InvocationTargetException, IllegalAccessException {
>         if (method != null) {
>             final ClassLoader old = SecurityActions.setThreadContextClassLoader(mBeanInstance.getClass().getClassLoader());
>             try {
>                 method.invoke(mBeanInstance);
>             } finally {
>                 SecurityActions.resetThreadContextClassLoader(old);
>             }
>         }
>     }
> }}}

--
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

From issues at jboss.org  Tue Mar  4 08:13:34 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 4 Mar 2014 08:13:34 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2840) @Schedule EJB Timer not using
 timezone when calculating next timeout
In-Reply-To: <JIRA.12530696.1391054454000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530696.1391054454000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530696.1391054454000.1124.1393938814668@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2840?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12949751#comment-12949751 ] 

RH Bugzilla Integration commented on WFLY-2840:
-----------------------------------------------

Jan Martiska <jmartisk at redhat.com> changed the Status of [bug 1059914|https://bugzilla.redhat.com/show_bug.cgi?id=1059914] from ON_QA to VERIFIED
                
> @Schedule EJB Timer not using timezone when calculating next timeout
> --------------------------------------------------------------------
>
>                 Key: WFLY-2840
>                 URL: https://issues.jboss.org/browse/WFLY-2840
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: EJB
>    Affects Versions: 8.0.0.CR1
>            Reporter: Brad Maxwell
>            Assignee: Brad Maxwell
>             Fix For: 8.0.0.Final
>
>
> With a system running in Central Timezone, if it uses the annotation below specifying the timezone as Eastern timezone, with the hour set to the current hour.
> The timer will fire once, and it will calculate the next timeout to be in the next hour CST, where as it should take in consideration the timezone specified on @Schedule which is Eastern.  If it did, then the timer should continue to fire every minute.
> {code}
>   @Schedule(persistent = false, timezone = "America/New_York", dayOfMonth = "*", dayOfWeek = "*", month = "*", hour = "22", minute = "*", second = "0", year = "*")
> {code}
> 21:53:00,006 INFO  [stdout] (EJB default - 1) ScheduleTest: nextTimeout:Wed Jan 29 22:00:00 CST 2014
> {code}
> import javax.ejb.Schedule;
> import javax.ejb.Singleton;
> import javax.ejb.Startup;
> @Startup
> @Singleton
> public class ScheduleTest {
>   @Schedule(persistent = false, timezone = "America/New_York", dayOfMonth = "*", dayOfWeek = "*", month = "*", hour = "22", minute = "*", second = "0", year = "*")
>   public void helloWorld(Timer time) {
>     System.out.println("ScheduleTest: timer:" + time.getClass().getName() + " " + time.getNextTimeout() + " " + time.getInfo());
>   }
> }
> {code}

--
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

From issues at jboss.org  Tue Mar  4 08:25:34 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 4 Mar 2014 08:25:34 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-822) MBean created via
 EAR/META-INF/jboss-service.xml from class defined in JBoss module gets
 wrong TCCL
In-Reply-To: <JIRA.12475332.1348586276000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12475332.1348586276000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12475332.1348586276000.1162.1393939534505@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-822?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12949757#comment-12949757 ] 

RH Bugzilla Integration commented on WFLY-822:
----------------------------------------------

Jan Martiska <jmartisk at redhat.com> changed the Status of [bug 1054984|https://bugzilla.redhat.com/show_bug.cgi?id=1054984] from ON_QA to VERIFIED
                
> MBean created via EAR/META-INF/jboss-service.xml from class defined in JBoss module gets wrong TCCL
> ---------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-822
>                 URL: https://issues.jboss.org/browse/WFLY-822
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Class Loading, Server
>         Environment: Java 6u31
>            Reporter: Zachary Bedell
>            Assignee: jaikiran pai
>              Labels: classloader, mbean, modules
>             Fix For: 8.0.0.Alpha3
>
>         Attachments: SarTcclTst.tbz
>
>
> When an MBean is loaded from jboss-service.xml within an EAR, the TCCL should point to the EAR deployment so that config files and other resources can be classloaded from the EAR.  Under JBoss 7.1.1.Final, the TCCL in a module loaded MBean's start() method is the module's ClassLoader.  No reference to the EAR deployment's classloader is available, thus EAR resources are not available within the MBean.
> It appears that org.jboss.as.service.AbstractService::invokeLifecycleMethod() incorrectly sets the TCCL to the module's defining classloader rather than the EAR's:
> {{{
> protected void invokeLifecycleMethod(final Method method) throws InvocationTargetException, IllegalAccessException {
>         if (method != null) {
>             final ClassLoader old = SecurityActions.setThreadContextClassLoader(mBeanInstance.getClass().getClassLoader());
>             try {
>                 method.invoke(mBeanInstance);
>             } finally {
>                 SecurityActions.resetThreadContextClassLoader(old);
>             }
>         }
>     }
> }}}

--
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

From issues at jboss.org  Tue Mar  4 09:03:35 2014
From: issues at jboss.org (David Lloyd (JIRA))
Date: Tue, 4 Mar 2014 09:03:35 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-895) JBoss crashes when run with
 AspectJ java agent
In-Reply-To: <JIRA.12458681.1328740621000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12458681.1328740621000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12458681.1328740621000.1375.1393941815352@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-895?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12949637#comment-12949637 ] 

David Lloyd edited comment on WFLY-895 at 3/4/14 9:02 AM:
----------------------------------------------------------

Here is a full diff of the workaround involving logging settings on the JVM command line, as used to get jmxetric versions before 1.0.5 to work with JBoss:

{noformat}
--- bin/standalone.conf
+++ ../jboss-as-7.1.0.Final.for-jmxetric/bin/standalone.conf
@@ -4,6 +4,7 @@
 ##                                                                          ##
 ##############################################################################
 
+JBOSS_MODULES_SYSTEM_PKGS="org.jboss.logmanager"
 #
 # This file is optional; it may be removed if not needed.
 #
@@ -48,6 +49,8 @@
 #
 if [ "x$JAVA_OPTS" = "x" ]; then
    JAVA_OPTS="-Xms64m -Xmx512m -XX:MaxPermSize=256m -Djava.net.preferIPv4Stack=true -Dorg.jboss.resolver.warning=true -Dsun.rmi.dgc.client.gcInterval=3600000 -Dsun.rmi.dgc.server.gcInterval=3600000"
+   JAVA_OPTS="$JAVA_OPTS -Djava.util.logging.manager=org.jboss.logmanager.LogManager -Xbootclasspath/p:$JBOSS_HOME/modules/org/jboss/logmanager/main/jboss-logmanager-1.2.2.GA.jar -Xbootclasspath/p:$JBOSS_HOME/modules/org/jboss/logmanager/log4j/main/jboss-logmanager-log4j-1.0.0.GA.jar -Xbootclasspath/p:$JBOSS_HOME/modules/org/apache/log4j/main/log4j-1.2.16.jar"
+   JAVA_OPTS="$JAVA_OPTS -javaagent:$HOME/opt/ganglia/jmxetric/jmxetric-1.0.2.jar=host=jboss-host.example.org,port=8649,wireformat31x=true,config=$HOME/opt/ganglia/jmxetric/etc/jmxetric-jboss.xml"
    JAVA_OPTS="$JAVA_OPTS -Djboss.modules.system.pkgs=$JBOSS_MODULES_SYSTEM_PKGS -Djava.awt.headless=true"
    JAVA_OPTS="$JAVA_OPTS -Djboss.server.default.config=standalone.xml"
 else
{noformat}
                
      was (Author: dpocock):
    
Here is a full diff of the workaround involving logging settings on the JVM command line, as used to get jmxetric versions before 1.0.5 to work with JBoss:


--- bin/standalone.conf
+++ ../jboss-as-7.1.0.Final.for-jmxetric/bin/standalone.conf
@@ -4,6 +4,7 @@
 ##                                                                          ##
 ##############################################################################
 
+JBOSS_MODULES_SYSTEM_PKGS="org.jboss.logmanager"
 #
 # This file is optional; it may be removed if not needed.
 #
@@ -48,6 +49,8 @@
 #
 if [ "x$JAVA_OPTS" = "x" ]; then
    JAVA_OPTS="-Xms64m -Xmx512m -XX:MaxPermSize=256m -Djava.net.preferIPv4Stack=true -Dorg.jboss.resolver.warning=true -Dsun.rmi.dgc.client.gcInterval=3600000 -Dsun.rmi.dgc.server.gcInterval=3600000"
+   JAVA_OPTS="$JAVA_OPTS -Djava.util.logging.manager=org.jboss.logmanager.LogManager -Xbootclasspath/p:$JBOSS_HOME/modules/org/jboss/logmanager/main/jboss-logmanager-1.2.2.GA.jar -Xbootclasspath/p:$JBOSS_HOME/modules/org/jboss/logmanager/log4j/main/jboss-logmanager-log4j-1.0.0.GA.jar -Xbootclasspath/p:$JBOSS_HOME/modules/org/apache/log4j/main/log4j-1.2.16.jar"
+   JAVA_OPTS="$JAVA_OPTS -javaagent:$HOME/opt/ganglia/jmxetric/jmxetric-1.0.2.jar=host=jboss-host.example.org,port=8649,wireformat31x=true,config=$HOME/opt/ganglia/jmxetric/etc/jmxetric-jboss.xml"
    JAVA_OPTS="$JAVA_OPTS -Djboss.modules.system.pkgs=$JBOSS_MODULES_SYSTEM_PKGS -Djava.awt.headless=true"
    JAVA_OPTS="$JAVA_OPTS -Djboss.server.default.config=standalone.xml"
 else

                  
> JBoss crashes when run with AspectJ java agent
> ----------------------------------------------
>
>                 Key: WFLY-895
>                 URL: https://issues.jboss.org/browse/WFLY-895
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Server
>         Environment: OS X 10.7.2, Ubuntu 11.10
>            Reporter: Jack Lund
>            Assignee: David Lloyd
>              Labels: aspectj, load_time_weaving
>
> When trying to start JBoss with the AspectJ java agent (-javaagent:/path/aspectjweaver.jar) to enable load-time weaving, JBoss crashes with the following stack trace in the logs:
> =========================================================================
>   JBoss Bootstrap Environment
>   JBOSS_HOME: /home/jack/jboss-as-7.1.0.CR1b
>   JAVA: java
>   JAVA_OPTS: -server -javaagent:/home/jack/aspectjweaver.jar -Xms64m -Xmx512m -XX:MaxPermSize=256m -Djava.net.preferIPv4Stack=true -Dorg.jboss.resolver.warning=true -Dsun.rmi.dgc.client.gcInterval=3600000 -Dsun.rmi.dgc.server.gcInterval=3600000 -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true
> =========================================================================
> WARNING: Failed to load the specified logmodule org.jboss.logmanager:main
> Exception in thread "main" java.lang.ExceptionInInitializerError
> 	at org.jboss.as.server.Main.main(Main.java:92)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:616)
> 	at org.jboss.modules.Module.run(Module.java:248)
> 	at org.jboss.modules.Main.main(Main.java:313)
> Caused by: java.lang.IllegalStateException: The LogManager was not properly installed (you must set the "java.util.logging.manager" system property to "org.jboss.logmanager.LogManager")
> 	at org.jboss.logmanager.Logger.getLogger(Logger.java:60)
> 	at org.jboss.logmanager.log4j.BridgeRepositorySelector.<clinit>(BridgeRepositorySelector.java:42)
> 	... 7 more

--
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

From issues at jboss.org  Tue Mar  4 09:03:37 2014
From: issues at jboss.org (David Lloyd (JIRA))
Date: Tue, 4 Mar 2014 09:03:37 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-895) JBoss crashes when run with
 AspectJ java agent
In-Reply-To: <JIRA.12458681.1328740621000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12458681.1328740621000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12458681.1328740621000.1409.1393941817113@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-895?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12949787#comment-12949787 ] 

David Lloyd commented on WFLY-895:
----------------------------------

Fixed that up for you :)
                
> JBoss crashes when run with AspectJ java agent
> ----------------------------------------------
>
>                 Key: WFLY-895
>                 URL: https://issues.jboss.org/browse/WFLY-895
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Server
>         Environment: OS X 10.7.2, Ubuntu 11.10
>            Reporter: Jack Lund
>            Assignee: David Lloyd
>              Labels: aspectj, load_time_weaving
>
> When trying to start JBoss with the AspectJ java agent (-javaagent:/path/aspectjweaver.jar) to enable load-time weaving, JBoss crashes with the following stack trace in the logs:
> =========================================================================
>   JBoss Bootstrap Environment
>   JBOSS_HOME: /home/jack/jboss-as-7.1.0.CR1b
>   JAVA: java
>   JAVA_OPTS: -server -javaagent:/home/jack/aspectjweaver.jar -Xms64m -Xmx512m -XX:MaxPermSize=256m -Djava.net.preferIPv4Stack=true -Dorg.jboss.resolver.warning=true -Dsun.rmi.dgc.client.gcInterval=3600000 -Dsun.rmi.dgc.server.gcInterval=3600000 -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true
> =========================================================================
> WARNING: Failed to load the specified logmodule org.jboss.logmanager:main
> Exception in thread "main" java.lang.ExceptionInInitializerError
> 	at org.jboss.as.server.Main.main(Main.java:92)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:616)
> 	at org.jboss.modules.Module.run(Module.java:248)
> 	at org.jboss.modules.Main.main(Main.java:313)
> Caused by: java.lang.IllegalStateException: The LogManager was not properly installed (you must set the "java.util.logging.manager" system property to "org.jboss.logmanager.LogManager")
> 	at org.jboss.logmanager.Logger.getLogger(Logger.java:60)
> 	at org.jboss.logmanager.log4j.BridgeRepositorySelector.<clinit>(BridgeRepositorySelector.java:42)
> 	... 7 more

--
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

From issues at jboss.org  Tue Mar  4 09:03:37 2014
From: issues at jboss.org (David Lloyd (JIRA))
Date: Tue, 4 Mar 2014 09:03:37 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-895) JBoss crashes when run with
 AspectJ java agent
In-Reply-To: <JIRA.12458681.1328740621000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12458681.1328740621000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12458681.1328740621000.1412.1393941817240@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-895?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

David Lloyd updated WFLY-895:
-----------------------------

    Description: 
When trying to start JBoss with the AspectJ java agent (-javaagent:/path/aspectjweaver.jar) to enable load-time weaving, JBoss crashes with the following stack trace in the logs:

{noformat}
=========================================================================

  JBoss Bootstrap Environment

  JBOSS_HOME: /home/jack/jboss-as-7.1.0.CR1b

  JAVA: java

  JAVA_OPTS: -server -javaagent:/home/jack/aspectjweaver.jar -Xms64m -Xmx512m -XX:MaxPermSize=256m -Djava.net.preferIPv4Stack=true -Dorg.jboss.resolver.warning=true -Dsun.rmi.dgc.client.gcInterval=3600000 -Dsun.rmi.dgc.server.gcInterval=3600000 -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true

=========================================================================

WARNING: Failed to load the specified logmodule org.jboss.logmanager:main
Exception in thread "main" java.lang.ExceptionInInitializerError
	at org.jboss.as.server.Main.main(Main.java:92)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:616)
	at org.jboss.modules.Module.run(Module.java:248)
	at org.jboss.modules.Main.main(Main.java:313)
Caused by: java.lang.IllegalStateException: The LogManager was not properly installed (you must set the "java.util.logging.manager" system property to "org.jboss.logmanager.LogManager")
	at org.jboss.logmanager.Logger.getLogger(Logger.java:60)
	at org.jboss.logmanager.log4j.BridgeRepositorySelector.<clinit>(BridgeRepositorySelector.java:42)
	... 7 more
{noformat}

  was:
When trying to start JBoss with the AspectJ java agent (-javaagent:/path/aspectjweaver.jar) to enable load-time weaving, JBoss crashes with the following stack trace in the logs:


=========================================================================

  JBoss Bootstrap Environment

  JBOSS_HOME: /home/jack/jboss-as-7.1.0.CR1b

  JAVA: java

  JAVA_OPTS: -server -javaagent:/home/jack/aspectjweaver.jar -Xms64m -Xmx512m -XX:MaxPermSize=256m -Djava.net.preferIPv4Stack=true -Dorg.jboss.resolver.warning=true -Dsun.rmi.dgc.client.gcInterval=3600000 -Dsun.rmi.dgc.server.gcInterval=3600000 -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true

=========================================================================

WARNING: Failed to load the specified logmodule org.jboss.logmanager:main
Exception in thread "main" java.lang.ExceptionInInitializerError
	at org.jboss.as.server.Main.main(Main.java:92)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:616)
	at org.jboss.modules.Module.run(Module.java:248)
	at org.jboss.modules.Main.main(Main.java:313)
Caused by: java.lang.IllegalStateException: The LogManager was not properly installed (you must set the "java.util.logging.manager" system property to "org.jboss.logmanager.LogManager")
	at org.jboss.logmanager.Logger.getLogger(Logger.java:60)
	at org.jboss.logmanager.log4j.BridgeRepositorySelector.<clinit>(BridgeRepositorySelector.java:42)
	... 7 more



    
> JBoss crashes when run with AspectJ java agent
> ----------------------------------------------
>
>                 Key: WFLY-895
>                 URL: https://issues.jboss.org/browse/WFLY-895
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Server
>         Environment: OS X 10.7.2, Ubuntu 11.10
>            Reporter: Jack Lund
>            Assignee: David Lloyd
>              Labels: aspectj, load_time_weaving
>
> When trying to start JBoss with the AspectJ java agent (-javaagent:/path/aspectjweaver.jar) to enable load-time weaving, JBoss crashes with the following stack trace in the logs:
> {noformat}
> =========================================================================
>   JBoss Bootstrap Environment
>   JBOSS_HOME: /home/jack/jboss-as-7.1.0.CR1b
>   JAVA: java
>   JAVA_OPTS: -server -javaagent:/home/jack/aspectjweaver.jar -Xms64m -Xmx512m -XX:MaxPermSize=256m -Djava.net.preferIPv4Stack=true -Dorg.jboss.resolver.warning=true -Dsun.rmi.dgc.client.gcInterval=3600000 -Dsun.rmi.dgc.server.gcInterval=3600000 -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true
> =========================================================================
> WARNING: Failed to load the specified logmodule org.jboss.logmanager:main
> Exception in thread "main" java.lang.ExceptionInInitializerError
> 	at org.jboss.as.server.Main.main(Main.java:92)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:616)
> 	at org.jboss.modules.Module.run(Module.java:248)
> 	at org.jboss.modules.Main.main(Main.java:313)
> Caused by: java.lang.IllegalStateException: The LogManager was not properly installed (you must set the "java.util.logging.manager" system property to "org.jboss.logmanager.LogManager")
> 	at org.jboss.logmanager.Logger.getLogger(Logger.java:60)
> 	at org.jboss.logmanager.log4j.BridgeRepositorySelector.<clinit>(BridgeRepositorySelector.java:42)
> 	... 7 more
> {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

From issues at jboss.org  Tue Mar  4 09:05:41 2014
From: issues at jboss.org (David Lloyd (JIRA))
Date: Tue, 4 Mar 2014 09:05:41 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-895) JBoss crashes when run with
 AspectJ java agent
In-Reply-To: <JIRA.12458681.1328740621000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12458681.1328740621000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12458681.1328740621000.1447.1393941941275@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-895?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12949788#comment-12949788 ] 

David Lloyd commented on WFLY-895:
----------------------------------

Anyway, this is probably caused by AspectJ setting up logging in its agent before the application does.
                
> JBoss crashes when run with AspectJ java agent
> ----------------------------------------------
>
>                 Key: WFLY-895
>                 URL: https://issues.jboss.org/browse/WFLY-895
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Server
>         Environment: OS X 10.7.2, Ubuntu 11.10
>            Reporter: Jack Lund
>            Assignee: David Lloyd
>              Labels: aspectj, load_time_weaving
>
> When trying to start JBoss with the AspectJ java agent (-javaagent:/path/aspectjweaver.jar) to enable load-time weaving, JBoss crashes with the following stack trace in the logs:
> {noformat}
> =========================================================================
>   JBoss Bootstrap Environment
>   JBOSS_HOME: /home/jack/jboss-as-7.1.0.CR1b
>   JAVA: java
>   JAVA_OPTS: -server -javaagent:/home/jack/aspectjweaver.jar -Xms64m -Xmx512m -XX:MaxPermSize=256m -Djava.net.preferIPv4Stack=true -Dorg.jboss.resolver.warning=true -Dsun.rmi.dgc.client.gcInterval=3600000 -Dsun.rmi.dgc.server.gcInterval=3600000 -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true
> =========================================================================
> WARNING: Failed to load the specified logmodule org.jboss.logmanager:main
> Exception in thread "main" java.lang.ExceptionInInitializerError
> 	at org.jboss.as.server.Main.main(Main.java:92)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:616)
> 	at org.jboss.modules.Module.run(Module.java:248)
> 	at org.jboss.modules.Main.main(Main.java:313)
> Caused by: java.lang.IllegalStateException: The LogManager was not properly installed (you must set the "java.util.logging.manager" system property to "org.jboss.logmanager.LogManager")
> 	at org.jboss.logmanager.Logger.getLogger(Logger.java:60)
> 	at org.jboss.logmanager.log4j.BridgeRepositorySelector.<clinit>(BridgeRepositorySelector.java:42)
> 	... 7 more
> {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

From issues at jboss.org  Tue Mar  4 09:11:35 2014
From: issues at jboss.org (David Lloyd (JIRA))
Date: Tue, 4 Mar 2014 09:11:35 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-895) JBoss crashes when run with
 AspectJ java agent
In-Reply-To: <JIRA.12458681.1328740621000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12458681.1328740621000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12458681.1328740621000.1486.1393942295182@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-895?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12949797#comment-12949797 ] 

David Lloyd commented on WFLY-895:
----------------------------------

And the JARs you've boot on the boot classpath only prove that out - you definitely do not want to do that as you'll end up with duplicate JARs and all kinds of other problems.
                
> JBoss crashes when run with AspectJ java agent
> ----------------------------------------------
>
>                 Key: WFLY-895
>                 URL: https://issues.jboss.org/browse/WFLY-895
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Server
>         Environment: OS X 10.7.2, Ubuntu 11.10
>            Reporter: Jack Lund
>            Assignee: David Lloyd
>              Labels: aspectj, load_time_weaving
>
> When trying to start JBoss with the AspectJ java agent (-javaagent:/path/aspectjweaver.jar) to enable load-time weaving, JBoss crashes with the following stack trace in the logs:
> {noformat}
> =========================================================================
>   JBoss Bootstrap Environment
>   JBOSS_HOME: /home/jack/jboss-as-7.1.0.CR1b
>   JAVA: java
>   JAVA_OPTS: -server -javaagent:/home/jack/aspectjweaver.jar -Xms64m -Xmx512m -XX:MaxPermSize=256m -Djava.net.preferIPv4Stack=true -Dorg.jboss.resolver.warning=true -Dsun.rmi.dgc.client.gcInterval=3600000 -Dsun.rmi.dgc.server.gcInterval=3600000 -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true
> =========================================================================
> WARNING: Failed to load the specified logmodule org.jboss.logmanager:main
> Exception in thread "main" java.lang.ExceptionInInitializerError
> 	at org.jboss.as.server.Main.main(Main.java:92)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:616)
> 	at org.jboss.modules.Module.run(Module.java:248)
> 	at org.jboss.modules.Main.main(Main.java:313)
> Caused by: java.lang.IllegalStateException: The LogManager was not properly installed (you must set the "java.util.logging.manager" system property to "org.jboss.logmanager.LogManager")
> 	at org.jboss.logmanager.Logger.getLogger(Logger.java:60)
> 	at org.jboss.logmanager.log4j.BridgeRepositorySelector.<clinit>(BridgeRepositorySelector.java:42)
> 	... 7 more
> {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

From issues at jboss.org  Tue Mar  4 09:19:34 2014
From: issues at jboss.org (dpocock (JIRA))
Date: Tue, 4 Mar 2014 09:19:34 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-895) JBoss crashes when run with
 AspectJ java agent
In-Reply-To: <JIRA.12458681.1328740621000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12458681.1328740621000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12458681.1328740621000.1547.1393942774605@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-895?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12949801#comment-12949801 ] 

dpocock commented on WFLY-895:
------------------------------

Understood - jmxetric no longer does any logging, it just gives one line on stdout to confirm it has loaded.

That is not the full story though - when the agent wants to interact with JMX, that causes the JBoss JMX code to be invoked before it is really ready.  Not only does that cause JMX problems later (as in WFLY-3054), but the JBoss JMX code also tried to access the logger at this early stage in the boot process, it can't find it on the classpath and so startup fails.

The bootclasspath stuff helps the JBoss JMX code to survive the startup process but I agree this is not a desirable way to go about it.


                
> JBoss crashes when run with AspectJ java agent
> ----------------------------------------------
>
>                 Key: WFLY-895
>                 URL: https://issues.jboss.org/browse/WFLY-895
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Server
>         Environment: OS X 10.7.2, Ubuntu 11.10
>            Reporter: Jack Lund
>            Assignee: David Lloyd
>              Labels: aspectj, load_time_weaving
>
> When trying to start JBoss with the AspectJ java agent (-javaagent:/path/aspectjweaver.jar) to enable load-time weaving, JBoss crashes with the following stack trace in the logs:
> {noformat}
> =========================================================================
>   JBoss Bootstrap Environment
>   JBOSS_HOME: /home/jack/jboss-as-7.1.0.CR1b
>   JAVA: java
>   JAVA_OPTS: -server -javaagent:/home/jack/aspectjweaver.jar -Xms64m -Xmx512m -XX:MaxPermSize=256m -Djava.net.preferIPv4Stack=true -Dorg.jboss.resolver.warning=true -Dsun.rmi.dgc.client.gcInterval=3600000 -Dsun.rmi.dgc.server.gcInterval=3600000 -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true
> =========================================================================
> WARNING: Failed to load the specified logmodule org.jboss.logmanager:main
> Exception in thread "main" java.lang.ExceptionInInitializerError
> 	at org.jboss.as.server.Main.main(Main.java:92)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:616)
> 	at org.jboss.modules.Module.run(Module.java:248)
> 	at org.jboss.modules.Main.main(Main.java:313)
> Caused by: java.lang.IllegalStateException: The LogManager was not properly installed (you must set the "java.util.logging.manager" system property to "org.jboss.logmanager.LogManager")
> 	at org.jboss.logmanager.Logger.getLogger(Logger.java:60)
> 	at org.jboss.logmanager.log4j.BridgeRepositorySelector.<clinit>(BridgeRepositorySelector.java:42)
> 	... 7 more
> {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

From issues at jboss.org  Tue Mar  4 09:21:33 2014
From: issues at jboss.org (David Lloyd (JIRA))
Date: Tue, 4 Mar 2014 09:21:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-895) JBoss crashes when run with
 AspectJ java agent
In-Reply-To: <JIRA.12458681.1328740621000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12458681.1328740621000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12458681.1328740621000.1552.1393942893897@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-895?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12732771#comment-12732771 ] 

David Lloyd edited comment on WFLY-895 at 3/4/14 9:20 AM:
----------------------------------------------------------

Hi,

I have done the same things, mine is a Windows install so I updated the standalone.conf.bat with the details mentioned, but still get error;

JAVA_OPTS is
{noformat}
Calling "D:\jboss-as-7.1.1.Final\bin\standalone.conf.bat"
===============================================================================

  JBoss Bootstrap Environment

  JBOSS_HOME: D:\jboss-as-7.1.1.Final

  JAVA: C:\Program Files\Java\jdk1.7.0_09\bin\java

  JAVA_OPTS: -XX:+TieredCompilation -Xms64M -Xmx512M -XX:MaxPermSize=256M -Dsun.
rmi.dgc.client.gcInterval=3600000 -Dsun.rmi.dgc.server.gcInterval=3600000 -Djava
.net.preferIPv4Stack=true -Dorg.jboss.resolver.warning=true -Djboss.modules.syst
em.pkgs=org.jboss.byteman -Djboss.server.default.config=standalone.xml -Djava.rm
i.server.hostname=10.206.18.194 -Dcom.sun.management.jmxremote.port=8686 -Dcom.s
un.management.jmxremote.password.file="D:\jmxremote\jmxremote.password" -Djava.u
til.logging.manager=org.jboss.logmanager.LogManager -Xbootclasspath/p:JBOSS_HOME
/modules/org/jboss/logmanager/main/jboss-logmanager-1.2.2.GA.jar

===============================================================================

Could not load Logmanager "org.jboss.logmanager.LogManager"
java.lang.ClassNotFoundException: org.jboss.logmanager.LogManager
        at java.net.URLClassLoader$1.run(URLClassLoader.java:366)
        at java.net.URLClassLoader$1.run(URLClassLoader.java:355)
        at java.security.AccessController.doPrivileged(Native Method)
        at java.net.URLClassLoader.findClass(URLClassLoader.java:354)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:423)
        at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:356)
        at java.util.logging.LogManager$1.run(LogManager.java:185)
        at java.security.AccessController.doPrivileged(Native Method)
        at java.util.logging.LogManager.<clinit>(LogManager.java:175)
        at java.util.logging.Logger.getLogger(Logger.java:327)
        at com.sun.jmx.remote.util.ClassLogger.<init>(ClassLogger.java:55)
        at sun.management.jmxremote.ConnectorBootstrap.<clinit>(ConnectorBootstr
ap.java:823)
        at sun.management.Agent.startAgent(Agent.java:244)
        at sun.management.Agent.startAgent(Agent.java:369)
WARNING: Failed to load the specified log manager class org.jboss.logmanager.Log
Manager
Exception in thread "main" java.lang.ExceptionInInitializerError
        at org.jboss.as.server.Main.main(Main.java:73)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.
java:57)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
sorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:601)
        at org.jboss.modules.Module.run(Module.java:260)
        at org.jboss.modules.Main.main(Main.java:291)
Caused by: java.lang.IllegalStateException: The LogManager was not properly inst
alled (you must set the "java.util.logging.manager" system property to "org.jbos
s.logmanager.LogManager")
        at org.jboss.logmanager.Logger.getLogger(Logger.java:60)
        at org.jboss.logmanager.log4j.BridgeRepositorySelector.<clinit>(BridgeRe
positorySelector.java:42)
        ... 7 more
Press any key to continue . . .
{noformat}

Here is my standalone.conf.bat;

{noformat}
rem ### -*- batch file -*- ######################################################
rem #                                                                          ##
rem #  JBoss Bootstrap Script Configuration                                    ##
rem #                                                                          ##
rem #############################################################################
rem #
rem #
rem # Added by Derek Nkansah - 7th November 2012
rem #     set JBOSS_MODULES_SYSTEM_PKGS="org.jboss.logmanager"
rem #
rem #
rem # $Id: run.conf.bat 88820 2009-05-13 15:25:44Z dimitris at jboss.org $

rem #
rem # This batch file is executed by run.bat to initialize the environment
rem # variables that run.bat uses. It is recommended to use this file to
rem # configure these variables, rather than modifying run.bat itself.
rem #
rem # Logging params added 8/11/2012
set JBOSS_MODULES_SYSTEM_PKGS="org.jboss.logmanager"

rem Uncomment the following line to disable manipulation of JAVA_OPTS (JVM parameters)
rem set PRESERVE_JAVA_OPTS=true

if not "x%JAVA_OPTS%" == "x" (
  echo "JAVA_OPTS already set in environment; overriding default settings with values: %JAVA_OPTS%"
  goto JAVA_OPTS_SET
)

rem #
rem # Specify the JBoss Profiler configuration file to load.
rem #
rem # Default is to not load a JBoss Profiler configuration file.
rem #
rem set "PROFILER=%JBOSS_HOME%\bin\jboss-profiler.properties"

rem #
rem # Specify the location of the Java home directory (it is recommended that
rem # this always be set). If set, then "%JAVA_HOME%\bin\java" will be used as
rem # the Java VM executable; otherwise, "%JAVA%" will be used (see below).
rem #
set "JAVA_HOME=C:\Program Files\Java\jdk1.7.0_09"
 
rem #
rem # Specify the exact Java VM executable to use - only used if JAVA_HOME is
rem # not set. Default is "java".
rem #
rem set "JAVA=C:\opt\jdk1.6.0_23\bin\java"

rem #
rem # Specify options to pass to the Java VM. Note, there are some additional
rem # options that are always passed by run.bat.
rem #

rem # JVM memory allocation pool parameters - modify as appropriate.
set "JAVA_OPTS=-Xms64M -Xmx512M -XX:MaxPermSize=256M"

rem # Reduce the RMI GCs to once per hour for Sun JVMs.
set "JAVA_OPTS=%JAVA_OPTS% -Dsun.rmi.dgc.client.gcInterval=3600000 -Dsun.rmi.dgc.server.gcInterval=3600000 -Djava.net.preferIPv4Stack=true"

rem # Warn when resolving remote XML DTDs or schemas.
set "JAVA_OPTS=%JAVA_OPTS% -Dorg.jboss.resolver.warning=true"

rem # Make Byteman classes visible in all module loaders
rem # This is necessary to inject Byteman rules into AS7 deployments
set "JAVA_OPTS=%JAVA_OPTS% -Djboss.modules.system.pkgs=org.jboss.byteman"
rem set "JAVA_OPTS=%JAVA_OPTS% -Djboss.modules.system.pkgs=org.jboss.logmanager"


rem # Set the default configuration file to use if -c or --server-config are not used
set "JAVA_OPTS=%JAVA_OPTS% -Djboss.server.default.config=standalone.xml"

rem # Sample JPDA settings for remote socket debugging
rem set "JAVA_OPTS=%JAVA_OPTS% -Xrunjdwp:transport=dt_socket,address=8787,server=y,suspend=n"

rem # Sample JPDA settings for shared memory debugging
rem set "JAVA_OPTS=%JAVA_OPTS% -Xrunjdwp:transport=dt_shmem,address=jboss,server=y,suspend=n"

rem # Use JBoss Modules lockless mode
rem set "JAVA_OPTS=%JAVA_OPTS% -Djboss.modules.lockless=true"

rem # jmxremote operations added by Delboy - 7th November 2012
set "JAVA_OPTS=%JAVA_OPTS% -Djava.rmi.server.hostname=10.206.18.194 -Dcom.sun.management.jmxremote.port=8686 -Dcom.sun.management.jmxremote.password.file="D:\jmxremote\jmxremote.password""
 
rem # Logging - Added 8/11/2012
 set "JAVA_OPTS=%JAVA_OPTS% -Djava.util.logging.manager=org.jboss.logmanager.LogManager"

:JAVA_OPTS_SET
set "JAVA_OPTS=%JAVA_OPTS% -Xbootclasspath/p:%JBOSS_HOME/modules/org/jboss/logmanager/main/jboss-logmanager-1.2.2.GA.jar"


Here is a copy of my standalone.bat;

@echo off
rem -------------------------------------------------------------------------
rem JBoss Bootstrap Script for Windows
rem -------------------------------------------------------------------------

echo JAVA_OPTS is %JAVA_OPT%

rem $Id$

@if not "%ECHO%" == ""  echo %ECHO%
@if "%OS%" == "Windows_NT" setlocal

if "%OS%" == "Windows_NT" (
  set "DIRNAME=%~dp0%"
) else (
  set DIRNAME=.\
)

rem Read an optional configuration file.
if "x%STANDALONE_CONF%" == "x" (
   set "STANDALONE_CONF=%DIRNAME%standalone.conf.bat"
)
if exist "%STANDALONE_CONF%" (
   echo Calling "%STANDALONE_CONF%"
   call "%STANDALONE_CONF%" %*
) else (
   echo Config file not found "%STANDALONE_CONF%"
)

pushd %DIRNAME%..
set "RESOLVED_JBOSS_HOME=%CD%"
popd

if "x%JBOSS_HOME%" == "x" (
  set "JBOSS_HOME=%RESOLVED_JBOSS_HOME%"
)

pushd "%JBOSS_HOME%"
set "SANITIZED_JBOSS_HOME=%CD%"
popd

if "%RESOLVED_JBOSS_HOME%" NEQ "%SANITIZED_JBOSS_HOME%" (
    echo WARNING JBOSS_HOME may be pointing to a different installation - unpredictable results may occur.
)

set DIRNAME=

if "%OS%" == "Windows_NT" (
  set "PROGNAME=%~nx0%"
) else (
  set "PROGNAME=standalone.bat"
)

rem Added by Derek Nkansah as per recommendations from SolarWinds
 rem set "JAVA_OPTS=%JAVA_OPTS% -Dcom.sun.management.snmp.port=1161"
 rem set "JAVA_OPTS=%JAVA_OPTS% -Dcom.sun.management.snmp.interface=0.0.0.0"


rem Setup JBoss specific properties
rem set JAVA_OPTS=-Dprogram.name=%PROGNAME% %JAVA_OPTS%
rem set JAVA_OPTS=-Dprogram.name=%PROGNAME% %JAVA_OPTS%
rem set "JAVA_OPTS=%JAVA_OPTS% -Dcom.sun.management.snmp.port=1161"
rem set "JAVA_OPTS=%JAVA_OPTS% -Dcom.sun.management.snmp.interface=0.0.0.0"
rem set "JAVA_OPTS=%JAVA_OPTS% -Dcom.sun.management.snmp.acl=false


if "x%JAVA_HOME%" == "x" (
  set  JAVA=java
  echo JAVA_HOME is not set. Unexpected results may occur.
  echo Set JAVA_HOME to the directory of your local JDK to avoid this message.
) else (
  set "JAVA=%JAVA_HOME%\bin\java"
)

if not "%PRESERVE_JAVA_OPTS%" == "true" (
  rem Add -client to the JVM options, if supported (32 bit VM), and not overriden
  echo "%JAVA_OPTS%" | findstr /I \-server > nul
  if errorlevel == 1 (
    "%JAVA%" -client -version 2>&1 | findstr /I /C:"Client VM" > nul
    if not errorlevel == 1 (
      set "JAVA_OPTS=-client %JAVA_OPTS%"
    )
  )

  rem Add compressed oops, if supported (64 bit VM), and not overriden
  echo "%JAVA_OPTS%" | findstr /I "\-XX:\-UseCompressedOops \-client" > nul
  if errorlevel == 1 (
    "%JAVA%" -XX:+UseCompressedOops -version > nul 2>&1
    if not errorlevel == 1 (
      set "JAVA_OPTS=-XX:+UseCompressedOops %JAVA_OPTS%"
    )
  )

  rem Add tiered compilation, if supported (64 bit VM), and not overriden
  echo "%JAVA_OPTS%" | findstr /I "\-XX:\-TieredCompilation \-client" > nul
  if errorlevel == 1 (
    "%JAVA%" -XX:+TieredCompilation -version > nul 2>&1
    if not errorlevel == 1 (
      set "JAVA_OPTS=-XX:+TieredCompilation %JAVA_OPTS%"
    )
  )
)

rem Find jboss-modules.jar, or we can't continue
if exist "%JBOSS_HOME%\jboss-modules.jar" (
    set "RUNJAR=%JBOSS_HOME%\jboss-modules.jar"
) else (
  echo Could not locate "%JBOSS_HOME%\jboss-modules.jar".
  echo Please check that you are in the bin directory when running this script.
  goto END
)

rem Setup JBoss specific properties

rem Setup the java endorsed dirs
set JBOSS_ENDORSED_DIRS=%JBOSS_HOME%\lib\endorsed

rem Set default module root paths
if "x%JBOSS_MODULEPATH%" == "x" (
  set  "JBOSS_MODULEPATH=%JBOSS_HOME%\modules"
)

rem Set the standalone base dir
if "x%JBOSS_BASE_DIR%" == "x" (
  set  "JBOSS_BASE_DIR=%JBOSS_HOME%\standalone"
)
rem Set the standalone log dir
if "x%JBOSS_LOG_DIR%" == "x" (
  set  "JBOSS_LOG_DIR=%JBOSS_BASE_DIR%\log"
)
rem Set the standalone configuration dir
if "x%JBOSS_CONFIG_DIR%" == "x" (
  set  "JBOSS_CONFIG_DIR=%JBOSS_BASE_DIR%/configuration"
)



echo ===============================================================================
echo.
echo   JBoss Bootstrap Environment
echo.
echo   JBOSS_HOME: %JBOSS_HOME%
echo.
echo   JAVA: %JAVA%
echo.
echo   JAVA_OPTS: %JAVA_OPTS%
echo.
echo ===============================================================================
echo.

:RESTART
"%JAVA%" %JAVA_OPTS% ^
 "-Dorg.jboss.boot.log.file=%JBOSS_LOG_DIR%\boot.log" ^
 "-Dlogging.configuration=file:%JBOSS_CONFIG_DIR%/logging.properties" ^
    -jar "%JBOSS_HOME%\jboss-modules.jar" ^
    -mp "%JBOSS_MODULEPATH%" ^
    -jaxpmodule "javax.xml.jaxp-provider" ^
     org.jboss.as.standalone ^
    -Djboss.home.dir="%JBOSS_HOME%" ^
    -Djavax.management.builder.initial=org.jboss.system.server.jmx.MBeanServerBuilderImpl"
     %*

if ERRORLEVEL 10 goto RESTART

:END
if "x%NOPAUSE%" == "x" pause

:END_NO_PAUSE
{noformat}

Can you help?


Many thanks,

Derek

                
      was (Author: knkansah):
    Hi,

I have done the same things, mine is a Windows install so I updated the standalone.conf.bat with the details mentioned, but still get error;

JAVA_OPTS is
Calling "D:\jboss-as-7.1.1.Final\bin\standalone.conf.bat"
===============================================================================

  JBoss Bootstrap Environment

  JBOSS_HOME: D:\jboss-as-7.1.1.Final

  JAVA: C:\Program Files\Java\jdk1.7.0_09\bin\java

  JAVA_OPTS: -XX:+TieredCompilation -Xms64M -Xmx512M -XX:MaxPermSize=256M -Dsun.
rmi.dgc.client.gcInterval=3600000 -Dsun.rmi.dgc.server.gcInterval=3600000 -Djava
.net.preferIPv4Stack=true -Dorg.jboss.resolver.warning=true -Djboss.modules.syst
em.pkgs=org.jboss.byteman -Djboss.server.default.config=standalone.xml -Djava.rm
i.server.hostname=10.206.18.194 -Dcom.sun.management.jmxremote.port=8686 -Dcom.s
un.management.jmxremote.password.file="D:\jmxremote\jmxremote.password" -Djava.u
til.logging.manager=org.jboss.logmanager.LogManager -Xbootclasspath/p:JBOSS_HOME
/modules/org/jboss/logmanager/main/jboss-logmanager-1.2.2.GA.jar

===============================================================================

Could not load Logmanager "org.jboss.logmanager.LogManager"
java.lang.ClassNotFoundException: org.jboss.logmanager.LogManager
        at java.net.URLClassLoader$1.run(URLClassLoader.java:366)
        at java.net.URLClassLoader$1.run(URLClassLoader.java:355)
        at java.security.AccessController.doPrivileged(Native Method)
        at java.net.URLClassLoader.findClass(URLClassLoader.java:354)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:423)
        at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:356)
        at java.util.logging.LogManager$1.run(LogManager.java:185)
        at java.security.AccessController.doPrivileged(Native Method)
        at java.util.logging.LogManager.<clinit>(LogManager.java:175)
        at java.util.logging.Logger.getLogger(Logger.java:327)
        at com.sun.jmx.remote.util.ClassLogger.<init>(ClassLogger.java:55)
        at sun.management.jmxremote.ConnectorBootstrap.<clinit>(ConnectorBootstr
ap.java:823)
        at sun.management.Agent.startAgent(Agent.java:244)
        at sun.management.Agent.startAgent(Agent.java:369)
WARNING: Failed to load the specified log manager class org.jboss.logmanager.Log
Manager
Exception in thread "main" java.lang.ExceptionInInitializerError
        at org.jboss.as.server.Main.main(Main.java:73)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.
java:57)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
sorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:601)
        at org.jboss.modules.Module.run(Module.java:260)
        at org.jboss.modules.Main.main(Main.java:291)
Caused by: java.lang.IllegalStateException: The LogManager was not properly inst
alled (you must set the "java.util.logging.manager" system property to "org.jbos
s.logmanager.LogManager")
        at org.jboss.logmanager.Logger.getLogger(Logger.java:60)
        at org.jboss.logmanager.log4j.BridgeRepositorySelector.<clinit>(BridgeRe
positorySelector.java:42)
        ... 7 more
Press any key to continue . . .


Here is my standalone.conf.bat;

rem ### -*- batch file -*- ######################################################
rem #                                                                          ##
rem #  JBoss Bootstrap Script Configuration                                    ##
rem #                                                                          ##
rem #############################################################################
rem #
rem #
rem # Added by Derek Nkansah - 7th November 2012
rem #     set JBOSS_MODULES_SYSTEM_PKGS="org.jboss.logmanager"
rem #
rem #
rem # $Id: run.conf.bat 88820 2009-05-13 15:25:44Z dimitris at jboss.org $

rem #
rem # This batch file is executed by run.bat to initialize the environment
rem # variables that run.bat uses. It is recommended to use this file to
rem # configure these variables, rather than modifying run.bat itself.
rem #
rem # Logging params added 8/11/2012
set JBOSS_MODULES_SYSTEM_PKGS="org.jboss.logmanager"

rem Uncomment the following line to disable manipulation of JAVA_OPTS (JVM parameters)
rem set PRESERVE_JAVA_OPTS=true

if not "x%JAVA_OPTS%" == "x" (
  echo "JAVA_OPTS already set in environment; overriding default settings with values: %JAVA_OPTS%"
  goto JAVA_OPTS_SET
)

rem #
rem # Specify the JBoss Profiler configuration file to load.
rem #
rem # Default is to not load a JBoss Profiler configuration file.
rem #
rem set "PROFILER=%JBOSS_HOME%\bin\jboss-profiler.properties"

rem #
rem # Specify the location of the Java home directory (it is recommended that
rem # this always be set). If set, then "%JAVA_HOME%\bin\java" will be used as
rem # the Java VM executable; otherwise, "%JAVA%" will be used (see below).
rem #
set "JAVA_HOME=C:\Program Files\Java\jdk1.7.0_09"
 
rem #
rem # Specify the exact Java VM executable to use - only used if JAVA_HOME is
rem # not set. Default is "java".
rem #
rem set "JAVA=C:\opt\jdk1.6.0_23\bin\java"

rem #
rem # Specify options to pass to the Java VM. Note, there are some additional
rem # options that are always passed by run.bat.
rem #

rem # JVM memory allocation pool parameters - modify as appropriate.
set "JAVA_OPTS=-Xms64M -Xmx512M -XX:MaxPermSize=256M"

rem # Reduce the RMI GCs to once per hour for Sun JVMs.
set "JAVA_OPTS=%JAVA_OPTS% -Dsun.rmi.dgc.client.gcInterval=3600000 -Dsun.rmi.dgc.server.gcInterval=3600000 -Djava.net.preferIPv4Stack=true"

rem # Warn when resolving remote XML DTDs or schemas.
set "JAVA_OPTS=%JAVA_OPTS% -Dorg.jboss.resolver.warning=true"

rem # Make Byteman classes visible in all module loaders
rem # This is necessary to inject Byteman rules into AS7 deployments
set "JAVA_OPTS=%JAVA_OPTS% -Djboss.modules.system.pkgs=org.jboss.byteman"
rem set "JAVA_OPTS=%JAVA_OPTS% -Djboss.modules.system.pkgs=org.jboss.logmanager"


rem # Set the default configuration file to use if -c or --server-config are not used
set "JAVA_OPTS=%JAVA_OPTS% -Djboss.server.default.config=standalone.xml"

rem # Sample JPDA settings for remote socket debugging
rem set "JAVA_OPTS=%JAVA_OPTS% -Xrunjdwp:transport=dt_socket,address=8787,server=y,suspend=n"

rem # Sample JPDA settings for shared memory debugging
rem set "JAVA_OPTS=%JAVA_OPTS% -Xrunjdwp:transport=dt_shmem,address=jboss,server=y,suspend=n"

rem # Use JBoss Modules lockless mode
rem set "JAVA_OPTS=%JAVA_OPTS% -Djboss.modules.lockless=true"

rem # jmxremote operations added by Delboy - 7th November 2012
set "JAVA_OPTS=%JAVA_OPTS% -Djava.rmi.server.hostname=10.206.18.194 -Dcom.sun.management.jmxremote.port=8686 -Dcom.sun.management.jmxremote.password.file="D:\jmxremote\jmxremote.password""
 
rem # Logging - Added 8/11/2012
 set "JAVA_OPTS=%JAVA_OPTS% -Djava.util.logging.manager=org.jboss.logmanager.LogManager"

:JAVA_OPTS_SET
set "JAVA_OPTS=%JAVA_OPTS% -Xbootclasspath/p:%JBOSS_HOME/modules/org/jboss/logmanager/main/jboss-logmanager-1.2.2.GA.jar"


Here is a copy of my standalone.bat;

@echo off
rem -------------------------------------------------------------------------
rem JBoss Bootstrap Script for Windows
rem -------------------------------------------------------------------------

echo JAVA_OPTS is %JAVA_OPT%

rem $Id$

@if not "%ECHO%" == ""  echo %ECHO%
@if "%OS%" == "Windows_NT" setlocal

if "%OS%" == "Windows_NT" (
  set "DIRNAME=%~dp0%"
) else (
  set DIRNAME=.\
)

rem Read an optional configuration file.
if "x%STANDALONE_CONF%" == "x" (
   set "STANDALONE_CONF=%DIRNAME%standalone.conf.bat"
)
if exist "%STANDALONE_CONF%" (
   echo Calling "%STANDALONE_CONF%"
   call "%STANDALONE_CONF%" %*
) else (
   echo Config file not found "%STANDALONE_CONF%"
)

pushd %DIRNAME%..
set "RESOLVED_JBOSS_HOME=%CD%"
popd

if "x%JBOSS_HOME%" == "x" (
  set "JBOSS_HOME=%RESOLVED_JBOSS_HOME%"
)

pushd "%JBOSS_HOME%"
set "SANITIZED_JBOSS_HOME=%CD%"
popd

if "%RESOLVED_JBOSS_HOME%" NEQ "%SANITIZED_JBOSS_HOME%" (
    echo WARNING JBOSS_HOME may be pointing to a different installation - unpredictable results may occur.
)

set DIRNAME=

if "%OS%" == "Windows_NT" (
  set "PROGNAME=%~nx0%"
) else (
  set "PROGNAME=standalone.bat"
)

rem Added by Derek Nkansah as per recommendations from SolarWinds
 rem set "JAVA_OPTS=%JAVA_OPTS% -Dcom.sun.management.snmp.port=1161"
 rem set "JAVA_OPTS=%JAVA_OPTS% -Dcom.sun.management.snmp.interface=0.0.0.0"


rem Setup JBoss specific properties
rem set JAVA_OPTS=-Dprogram.name=%PROGNAME% %JAVA_OPTS%
rem set JAVA_OPTS=-Dprogram.name=%PROGNAME% %JAVA_OPTS%
rem set "JAVA_OPTS=%JAVA_OPTS% -Dcom.sun.management.snmp.port=1161"
rem set "JAVA_OPTS=%JAVA_OPTS% -Dcom.sun.management.snmp.interface=0.0.0.0"
rem set "JAVA_OPTS=%JAVA_OPTS% -Dcom.sun.management.snmp.acl=false


if "x%JAVA_HOME%" == "x" (
  set  JAVA=java
  echo JAVA_HOME is not set. Unexpected results may occur.
  echo Set JAVA_HOME to the directory of your local JDK to avoid this message.
) else (
  set "JAVA=%JAVA_HOME%\bin\java"
)

if not "%PRESERVE_JAVA_OPTS%" == "true" (
  rem Add -client to the JVM options, if supported (32 bit VM), and not overriden
  echo "%JAVA_OPTS%" | findstr /I \-server > nul
  if errorlevel == 1 (
    "%JAVA%" -client -version 2>&1 | findstr /I /C:"Client VM" > nul
    if not errorlevel == 1 (
      set "JAVA_OPTS=-client %JAVA_OPTS%"
    )
  )

  rem Add compressed oops, if supported (64 bit VM), and not overriden
  echo "%JAVA_OPTS%" | findstr /I "\-XX:\-UseCompressedOops \-client" > nul
  if errorlevel == 1 (
    "%JAVA%" -XX:+UseCompressedOops -version > nul 2>&1
    if not errorlevel == 1 (
      set "JAVA_OPTS=-XX:+UseCompressedOops %JAVA_OPTS%"
    )
  )

  rem Add tiered compilation, if supported (64 bit VM), and not overriden
  echo "%JAVA_OPTS%" | findstr /I "\-XX:\-TieredCompilation \-client" > nul
  if errorlevel == 1 (
    "%JAVA%" -XX:+TieredCompilation -version > nul 2>&1
    if not errorlevel == 1 (
      set "JAVA_OPTS=-XX:+TieredCompilation %JAVA_OPTS%"
    )
  )
)

rem Find jboss-modules.jar, or we can't continue
if exist "%JBOSS_HOME%\jboss-modules.jar" (
    set "RUNJAR=%JBOSS_HOME%\jboss-modules.jar"
) else (
  echo Could not locate "%JBOSS_HOME%\jboss-modules.jar".
  echo Please check that you are in the bin directory when running this script.
  goto END
)

rem Setup JBoss specific properties

rem Setup the java endorsed dirs
set JBOSS_ENDORSED_DIRS=%JBOSS_HOME%\lib\endorsed

rem Set default module root paths
if "x%JBOSS_MODULEPATH%" == "x" (
  set  "JBOSS_MODULEPATH=%JBOSS_HOME%\modules"
)

rem Set the standalone base dir
if "x%JBOSS_BASE_DIR%" == "x" (
  set  "JBOSS_BASE_DIR=%JBOSS_HOME%\standalone"
)
rem Set the standalone log dir
if "x%JBOSS_LOG_DIR%" == "x" (
  set  "JBOSS_LOG_DIR=%JBOSS_BASE_DIR%\log"
)
rem Set the standalone configuration dir
if "x%JBOSS_CONFIG_DIR%" == "x" (
  set  "JBOSS_CONFIG_DIR=%JBOSS_BASE_DIR%/configuration"
)



echo ===============================================================================
echo.
echo   JBoss Bootstrap Environment
echo.
echo   JBOSS_HOME: %JBOSS_HOME%
echo.
echo   JAVA: %JAVA%
echo.
echo   JAVA_OPTS: %JAVA_OPTS%
echo.
echo ===============================================================================
echo.

:RESTART
"%JAVA%" %JAVA_OPTS% ^
 "-Dorg.jboss.boot.log.file=%JBOSS_LOG_DIR%\boot.log" ^
 "-Dlogging.configuration=file:%JBOSS_CONFIG_DIR%/logging.properties" ^
    -jar "%JBOSS_HOME%\jboss-modules.jar" ^
    -mp "%JBOSS_MODULEPATH%" ^
    -jaxpmodule "javax.xml.jaxp-provider" ^
     org.jboss.as.standalone ^
    -Djboss.home.dir="%JBOSS_HOME%" ^
    -Djavax.management.builder.initial=org.jboss.system.server.jmx.MBeanServerBuilderImpl"
     %*

if ERRORLEVEL 10 goto RESTART

:END
if "x%NOPAUSE%" == "x" pause

:END_NO_PAUSE


Can you help?


Many thanks,

Derek

                  
> JBoss crashes when run with AspectJ java agent
> ----------------------------------------------
>
>                 Key: WFLY-895
>                 URL: https://issues.jboss.org/browse/WFLY-895
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Server
>         Environment: OS X 10.7.2, Ubuntu 11.10
>            Reporter: Jack Lund
>            Assignee: David Lloyd
>              Labels: aspectj, load_time_weaving
>
> When trying to start JBoss with the AspectJ java agent (-javaagent:/path/aspectjweaver.jar) to enable load-time weaving, JBoss crashes with the following stack trace in the logs:
> {noformat}
> =========================================================================
>   JBoss Bootstrap Environment
>   JBOSS_HOME: /home/jack/jboss-as-7.1.0.CR1b
>   JAVA: java
>   JAVA_OPTS: -server -javaagent:/home/jack/aspectjweaver.jar -Xms64m -Xmx512m -XX:MaxPermSize=256m -Djava.net.preferIPv4Stack=true -Dorg.jboss.resolver.warning=true -Dsun.rmi.dgc.client.gcInterval=3600000 -Dsun.rmi.dgc.server.gcInterval=3600000 -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true
> =========================================================================
> WARNING: Failed to load the specified logmodule org.jboss.logmanager:main
> Exception in thread "main" java.lang.ExceptionInInitializerError
> 	at org.jboss.as.server.Main.main(Main.java:92)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:616)
> 	at org.jboss.modules.Module.run(Module.java:248)
> 	at org.jboss.modules.Main.main(Main.java:313)
> Caused by: java.lang.IllegalStateException: The LogManager was not properly installed (you must set the "java.util.logging.manager" system property to "org.jboss.logmanager.LogManager")
> 	at org.jboss.logmanager.Logger.getLogger(Logger.java:60)
> 	at org.jboss.logmanager.log4j.BridgeRepositorySelector.<clinit>(BridgeRepositorySelector.java:42)
> 	... 7 more
> {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

From issues at jboss.org  Tue Mar  4 09:21:35 2014
From: issues at jboss.org (David Lloyd (JIRA))
Date: Tue, 4 Mar 2014 09:21:35 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-895) JBoss crashes when run with
 AspectJ java agent
In-Reply-To: <JIRA.12458681.1328740621000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12458681.1328740621000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12458681.1328740621000.1570.1393942895177@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-895?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12694208#comment-12694208 ] 

David Lloyd edited comment on WFLY-895 at 3/4/14 9:20 AM:
----------------------------------------------------------

I did everything what you just wrote, but AS 7.1.1 just didnt start and give me the next exception

{noformat}
 JBOSS_HOME: C:\jboss\jboss-as-7.1.1.Final

 JAVA: C:\Program Files\Java\jdk1.7.0_03\bin\java

 JAVA_OPTS: -XX:+TieredCompilation -Dprogram.name=standalone.bat -Xms64M -Xmx512M -XX:MaxPermSize=256M -Dsun.rmi.dgc.client.gcInterval=
.jboss.logging.Logger.pluginClass=org.jboss.logging.logmanager.LoggerPluginImpl  -javaagent:aspectjweaver.jar -Djboss.boot.server.log.d
efault.config=standalone.xml

==============================================================================

ould not load Logmanager "org.jboss.logmanager.LogManager"
ava.lang.ClassNotFoundException: org.jboss.logmanager.LogManager
       at java.net.URLClassLoader$1.run(URLClassLoader.java:366)
       at java.net.URLClassLoader$1.run(URLClassLoader.java:355)
       at java.security.AccessController.doPrivileged(Native Method)
       at java.net.URLClassLoader.findClass(URLClassLoader.java:354)
       at java.lang.ClassLoader.loadClass(ClassLoader.java:423)
       at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308)
       at java.lang.ClassLoader.loadClass(ClassLoader.java:356)
       at java.util.logging.LogManager$1.run(LogManager.java:185)
       at java.security.AccessController.doPrivileged(Native Method)
       at java.util.logging.LogManager.<clinit>(LogManager.java:175)
       at java.util.logging.Logger.getLogger(Logger.java:327)
       at org.aspectj.weaver.tools.Jdk14Trace.<init>(Jdk14Trace.java:26)
       at org.aspectj.weaver.tools.Jdk14TraceFactory.getTrace(Jdk14TraceFactory.java:17)
       at org.aspectj.weaver.loadtime.Aj.<clinit>(Aj.java:46)
       at org.aspectj.weaver.loadtime.ClassPreProcessorAgentAdapter.<clinit>(ClassPreProcessorAgentAdapter.java:32)
       at org.aspectj.weaver.loadtime.Agent.<clinit>(Agent.java:33)
       at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
       at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
       at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
       at java.lang.reflect.Method.invoke(Method.java:601)
       at sun.instrument.InstrumentationImpl.loadClassAndStartAgent(InstrumentationImpl.java:382)
       at sun.instrument.InstrumentationImpl.loadClassAndCallPremain(InstrumentationImpl.java:397)
ARNING: Failed to load the specified log manager class org.jboss.logmanager.LogManager
xception in thread "main" java.lang.ExceptionInInitializerError
       at org.jboss.as.server.Main.main(Main.java:73)
       at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
       at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
       at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
       at java.lang.reflect.Method.invoke(Method.java:601)
       at org.jboss.modules.Module.run(Module.java:260)
       at org.jboss.modules.Main.main(Main.java:291)
aused by: java.lang.IllegalStateException: The LogManager was not properly installed (you must set the "java.util.logging.manager" syst
       at org.jboss.logmanager.Logger.getLogger(Logger.java:60)
       at org.jboss.logmanager.log4j.BridgeRepositorySelector.<clinit>(BridgeRepositorySelector.java:42)
       ... 7 more
ress any key to continue . . .
{noformat}


































































































































































                
      was (Author: als):
    I did everything what you just wrote, but AS 7.1.1 just didnt start and give me the next exception


 JBOSS_HOME: C:\jboss\jboss-as-7.1.1.Final

 JAVA: C:\Program Files\Java\jdk1.7.0_03\bin\java

 JAVA_OPTS: -XX:+TieredCompilation -Dprogram.name=standalone.bat -Xms64M -Xmx512M -XX:MaxPermSize=256M -Dsun.rmi.dgc.client.gcInterval=
.jboss.logging.Logger.pluginClass=org.jboss.logging.logmanager.LoggerPluginImpl  -javaagent:aspectjweaver.jar -Djboss.boot.server.log.d
efault.config=standalone.xml

==============================================================================

ould not load Logmanager "org.jboss.logmanager.LogManager"
ava.lang.ClassNotFoundException: org.jboss.logmanager.LogManager
       at java.net.URLClassLoader$1.run(URLClassLoader.java:366)
       at java.net.URLClassLoader$1.run(URLClassLoader.java:355)
       at java.security.AccessController.doPrivileged(Native Method)
       at java.net.URLClassLoader.findClass(URLClassLoader.java:354)
       at java.lang.ClassLoader.loadClass(ClassLoader.java:423)
       at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308)
       at java.lang.ClassLoader.loadClass(ClassLoader.java:356)
       at java.util.logging.LogManager$1.run(LogManager.java:185)
       at java.security.AccessController.doPrivileged(Native Method)
       at java.util.logging.LogManager.<clinit>(LogManager.java:175)
       at java.util.logging.Logger.getLogger(Logger.java:327)
       at org.aspectj.weaver.tools.Jdk14Trace.<init>(Jdk14Trace.java:26)
       at org.aspectj.weaver.tools.Jdk14TraceFactory.getTrace(Jdk14TraceFactory.java:17)
       at org.aspectj.weaver.loadtime.Aj.<clinit>(Aj.java:46)
       at org.aspectj.weaver.loadtime.ClassPreProcessorAgentAdapter.<clinit>(ClassPreProcessorAgentAdapter.java:32)
       at org.aspectj.weaver.loadtime.Agent.<clinit>(Agent.java:33)
       at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
       at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
       at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
       at java.lang.reflect.Method.invoke(Method.java:601)
       at sun.instrument.InstrumentationImpl.loadClassAndStartAgent(InstrumentationImpl.java:382)
       at sun.instrument.InstrumentationImpl.loadClassAndCallPremain(InstrumentationImpl.java:397)
ARNING: Failed to load the specified log manager class org.jboss.logmanager.LogManager
xception in thread "main" java.lang.ExceptionInInitializerError
       at org.jboss.as.server.Main.main(Main.java:73)
       at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
       at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
       at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
       at java.lang.reflect.Method.invoke(Method.java:601)
       at org.jboss.modules.Module.run(Module.java:260)
       at org.jboss.modules.Main.main(Main.java:291)
aused by: java.lang.IllegalStateException: The LogManager was not properly installed (you must set the "java.util.logging.manager" syst
       at org.jboss.logmanager.Logger.getLogger(Logger.java:60)
       at org.jboss.logmanager.log4j.BridgeRepositorySelector.<clinit>(BridgeRepositorySelector.java:42)
       ... 7 more
ress any key to continue . . .



































































































































































                  
> JBoss crashes when run with AspectJ java agent
> ----------------------------------------------
>
>                 Key: WFLY-895
>                 URL: https://issues.jboss.org/browse/WFLY-895
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Server
>         Environment: OS X 10.7.2, Ubuntu 11.10
>            Reporter: Jack Lund
>            Assignee: David Lloyd
>              Labels: aspectj, load_time_weaving
>
> When trying to start JBoss with the AspectJ java agent (-javaagent:/path/aspectjweaver.jar) to enable load-time weaving, JBoss crashes with the following stack trace in the logs:
> {noformat}
> =========================================================================
>   JBoss Bootstrap Environment
>   JBOSS_HOME: /home/jack/jboss-as-7.1.0.CR1b
>   JAVA: java
>   JAVA_OPTS: -server -javaagent:/home/jack/aspectjweaver.jar -Xms64m -Xmx512m -XX:MaxPermSize=256m -Djava.net.preferIPv4Stack=true -Dorg.jboss.resolver.warning=true -Dsun.rmi.dgc.client.gcInterval=3600000 -Dsun.rmi.dgc.server.gcInterval=3600000 -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true
> =========================================================================
> WARNING: Failed to load the specified logmodule org.jboss.logmanager:main
> Exception in thread "main" java.lang.ExceptionInInitializerError
> 	at org.jboss.as.server.Main.main(Main.java:92)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:616)
> 	at org.jboss.modules.Module.run(Module.java:248)
> 	at org.jboss.modules.Main.main(Main.java:313)
> Caused by: java.lang.IllegalStateException: The LogManager was not properly installed (you must set the "java.util.logging.manager" system property to "org.jboss.logmanager.LogManager")
> 	at org.jboss.logmanager.Logger.getLogger(Logger.java:60)
> 	at org.jboss.logmanager.log4j.BridgeRepositorySelector.<clinit>(BridgeRepositorySelector.java:42)
> 	... 7 more
> {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

From issues at jboss.org  Tue Mar  4 09:23:34 2014
From: issues at jboss.org (David Lloyd (JIRA))
Date: Tue, 4 Mar 2014 09:23:34 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-895) JBoss crashes when run with
 AspectJ java agent
In-Reply-To: <JIRA.12458681.1328740621000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12458681.1328740621000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12458681.1328740621000.1590.1393943014435@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-895?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12675220#comment-12675220 ] 

David Lloyd edited comment on WFLY-895 at 3/4/14 9:21 AM:
----------------------------------------------------------

Facing the similar issue while working with JBoss Profiler ... 

 Java agent : jboss-profiler-2.0.0.Beta5
 OS : windows 7 professional 

{noformat}
 ===============================================================================

  JBoss Bootstrap Environment

  JBOSS_HOME: jboss-as-7.1.0.Final

  JAVA: jdk1.6.0_31\bin\java

  JAVA_OPTS: -XX:+TieredCompilation -Dprogram.name=standalone.bat -Xms64M -Xmx51
2M -XX:MaxPermSize=256M -Dsun.rmi.dgc.client.gcInterval=3600000 -Dsun.rmi.dgc.se
rver.gcInterval=3600000 -Djava.net.preferIPv4Stack=true -Dorg.jboss.resolver.war
ning=true -Djboss.modules.system.pkgs=org.jboss.byteman -Djboss.server.default.c
onfig=standalone.xml -javaagent:jboss-profiler-2.0.0.Beta5/jboss-profiler.jar 
-Djboss-profiler.properties=jboss-profiler-2.0.0.Beta5/jboss-profiler.properties

===============================================================================

starting
JBoss Profiler 2.0.0.Beta5 (Sun Microsystems Inc. 1.6.0_31)
log4j:WARN No appenders could be found for logger (org.jboss.remoting.ServerInvo
ker).
log4j:WARN Please initialize the log4j system properly.
JBoss Profiler: Socket=localhost:5400
WARNING: Failed to load the specified log manager class org.jboss.logmanager.Log
Manager
Exception in thread "main" java.lang.ExceptionInInitializerError
        at org.jboss.as.server.Main.main(Main.java:73)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.
java:39)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
sorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:597)
        at org.jboss.modules.Module.run(Module.java:260)
        at org.jboss.modules.Main.main(Main.java:291)
Caused by: java.lang.IllegalStateException: The LogManager was not properly inst
alled (you must set the "java.util.logging.manager" system property to "org.jbos
s.logmanager.LogManager")
        at org.jboss.logmanager.Logger.getLogger(Logger.java:60)
        at org.jboss.logmanager.log4j.BridgeRepositorySelector.<clinit>(BridgeRe
positorySelector.java:42)
 ... 7 more
{noformat}
                
      was (Author: murthyr):
    Facing the similar issue while working with JBoss Profiler ... 

 Java agent : jboss-profiler-2.0.0.Beta5
 OS : windows 7 professional 

 ===============================================================================

  JBoss Bootstrap Environment

  JBOSS_HOME: jboss-as-7.1.0.Final

  JAVA: jdk1.6.0_31\bin\java

  JAVA_OPTS: -XX:+TieredCompilation -Dprogram.name=standalone.bat -Xms64M -Xmx51
2M -XX:MaxPermSize=256M -Dsun.rmi.dgc.client.gcInterval=3600000 -Dsun.rmi.dgc.se
rver.gcInterval=3600000 -Djava.net.preferIPv4Stack=true -Dorg.jboss.resolver.war
ning=true -Djboss.modules.system.pkgs=org.jboss.byteman -Djboss.server.default.c
onfig=standalone.xml -javaagent:jboss-profiler-2.0.0.Beta5/jboss-profiler.jar 
-Djboss-profiler.properties=jboss-profiler-2.0.0.Beta5/jboss-profiler.properties

===============================================================================

starting
JBoss Profiler 2.0.0.Beta5 (Sun Microsystems Inc. 1.6.0_31)
log4j:WARN No appenders could be found for logger (org.jboss.remoting.ServerInvo
ker).
log4j:WARN Please initialize the log4j system properly.
JBoss Profiler: Socket=localhost:5400
WARNING: Failed to load the specified log manager class org.jboss.logmanager.Log
Manager
Exception in thread "main" java.lang.ExceptionInInitializerError
        at org.jboss.as.server.Main.main(Main.java:73)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.
java:39)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
sorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:597)
        at org.jboss.modules.Module.run(Module.java:260)
        at org.jboss.modules.Main.main(Main.java:291)
Caused by: java.lang.IllegalStateException: The LogManager was not properly inst
alled (you must set the "java.util.logging.manager" system property to "org.jbos
s.logmanager.LogManager")
        at org.jboss.logmanager.Logger.getLogger(Logger.java:60)
        at org.jboss.logmanager.log4j.BridgeRepositorySelector.<clinit>(BridgeRe
positorySelector.java:42)
 ... 7 more

                  
> JBoss crashes when run with AspectJ java agent
> ----------------------------------------------
>
>                 Key: WFLY-895
>                 URL: https://issues.jboss.org/browse/WFLY-895
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Server
>         Environment: OS X 10.7.2, Ubuntu 11.10
>            Reporter: Jack Lund
>            Assignee: David Lloyd
>              Labels: aspectj, load_time_weaving
>
> When trying to start JBoss with the AspectJ java agent (-javaagent:/path/aspectjweaver.jar) to enable load-time weaving, JBoss crashes with the following stack trace in the logs:
> {noformat}
> =========================================================================
>   JBoss Bootstrap Environment
>   JBOSS_HOME: /home/jack/jboss-as-7.1.0.CR1b
>   JAVA: java
>   JAVA_OPTS: -server -javaagent:/home/jack/aspectjweaver.jar -Xms64m -Xmx512m -XX:MaxPermSize=256m -Djava.net.preferIPv4Stack=true -Dorg.jboss.resolver.warning=true -Dsun.rmi.dgc.client.gcInterval=3600000 -Dsun.rmi.dgc.server.gcInterval=3600000 -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true
> =========================================================================
> WARNING: Failed to load the specified logmodule org.jboss.logmanager:main
> Exception in thread "main" java.lang.ExceptionInInitializerError
> 	at org.jboss.as.server.Main.main(Main.java:92)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:616)
> 	at org.jboss.modules.Module.run(Module.java:248)
> 	at org.jboss.modules.Main.main(Main.java:313)
> Caused by: java.lang.IllegalStateException: The LogManager was not properly installed (you must set the "java.util.logging.manager" system property to "org.jboss.logmanager.LogManager")
> 	at org.jboss.logmanager.Logger.getLogger(Logger.java:60)
> 	at org.jboss.logmanager.log4j.BridgeRepositorySelector.<clinit>(BridgeRepositorySelector.java:42)
> 	... 7 more
> {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

From issues at jboss.org  Tue Mar  4 09:25:34 2014
From: issues at jboss.org (Bela Ban (JIRA))
Date: Tue, 4 Mar 2014 09:25:34 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1722) Improve performance of
	ENCRYPT protocol
In-Reply-To: <JIRA.12508426.1382426974000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508426.1382426974000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508426.1382426974000.1636.1393943134222@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JGRP-1722?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12949021#comment-12949021 ] 

Bela Ban edited comment on JGRP-1722 at 3/4/14 9:23 AM:
--------------------------------------------------------

Cipher pooling doesn't help: all messages of a batch are decrypted sequentially (using the same cipher though), replaced with the decrypted message, and then the batch is passed up.
Parallel decryption of the messages in a batch would probably help here, e.g. using the fork-join framework.
                
      was (Author: belaban):
    Parallelization doesn't help with message batches: all messages of a batch are decrypted sequentially (using the same cipher though), replaced with the decrypted message, and then the batch is passed up.
Parallel decryption of the messages in a batch would probably help here, e.g. using the fork-join framework.
                  
> Improve performance of ENCRYPT protocol
> ---------------------------------------
>
>                 Key: JGRP-1722
>                 URL: https://issues.jboss.org/browse/JGRP-1722
>             Project: JGroups
>          Issue Type: Enhancement
>    Affects Versions: 3.4
>            Reporter: Martin Gencur
>            Assignee: Bela Ban
>             Fix For: 3.5
>
>
> A stress tests with the following setup showed that performance (reads and writes/sec) is halved when ENCRYPT protocol is enabled:
> Infinispan had distributed sync cache with 2 owners on 4 nodes, no transactions. The stress test used 10 threads on each node accessing 1024 byte entries, no conflicts on keys, 20 % writes, 80 % reads. 
> It would be great if we could improve the performance of ENCRYPT protocol.

--
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

From issues at jboss.org  Tue Mar  4 09:27:35 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 4 Mar 2014 09:27:35 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (SECURITY-797) Authentication attempts
 will fail if the DatabaseRolesMappingProvider's rolesQuery returns an empty
 set
In-Reply-To: <JIRA.12532578.1392754125000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12532578.1392754125000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12532578.1392754125000.1643.1393943255658@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/SECURITY-797?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12949807#comment-12949807 ] 

RH Bugzilla Integration commented on SECURITY-797:
--------------------------------------------------

Ondrej Lukas <olukas at redhat.com> changed the Status of [bug 1067612|https://bugzilla.redhat.com/show_bug.cgi?id=1067612] from ON_QA to VERIFIED
                
> Authentication attempts will fail if the DatabaseRolesMappingProvider's rolesQuery returns an empty set
> -------------------------------------------------------------------------------------------------------
>
>                 Key: SECURITY-797
>                 URL: https://issues.jboss.org/browse/SECURITY-797
>             Project: PicketBox 
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JBossSX
>    Affects Versions: PicketBox_4_0_19.Final
>            Reporter: Derek Horton
>            Assignee: Stefan Guilhen
>         Attachments: SECURITY-797.patch
>
>
> If the DatabaseRolesMappingProvider's rolesQuery returns an empty set, then the authentication attempts will fail.  Seems like it should not cause the authentication attempt to fail, since this is about mapping/adding roles.
> It looks like the code detects that the result set is empty, but then it tries to get the role from the empty set.  This causes an exception which in turn causes the authentication attempt to fail.

--
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

From issues at jboss.org  Tue Mar  4 09:31:35 2014
From: issues at jboss.org (Bela Ban (JIRA))
Date: Tue, 4 Mar 2014 09:31:35 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1722) Improve performance of
	ENCRYPT protocol
In-Reply-To: <JIRA.12508426.1382426974000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508426.1382426974000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508426.1382426974000.1662.1393943495313@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JGRP-1722?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12949811#comment-12949811 ] 

Bela Ban commented on JGRP-1722:
--------------------------------

I tried the following:
# Decryption of the messages of a batch in parallel, using a thread pool. If the decryption cost of a message (assuming similar-sized messages) is 2ms, then decrypting a batch of 10 messages would take 20ms if done sequentially, while it would take ~2ms if done in parallel. Of course, we're assuming here that we have 10 threads available and the cost of context switching is negligible
# Use of the asynchronous invocation API to dispatch requests. Every request is handled by a thread from a thread pool (in UPerf) and sending the response as well. The response sending includes encryption of the response, so this cost is amortized by doing this in parallel

I tested performance on my local box, my (fast) mac and the lab cluster (8 UPerf instances), and it wasn't better than the sequential algorithm. Possible causes: only half of the messages are actually message batches, the average batch size is small (I verified that they avg is ~ 3.5), and the additional thread context switching caused by the pools diminishes the returns gained by parallelization
                
> Improve performance of ENCRYPT protocol
> ---------------------------------------
>
>                 Key: JGRP-1722
>                 URL: https://issues.jboss.org/browse/JGRP-1722
>             Project: JGroups
>          Issue Type: Enhancement
>    Affects Versions: 3.4
>            Reporter: Martin Gencur
>            Assignee: Bela Ban
>             Fix For: 3.5
>
>
> A stress tests with the following setup showed that performance (reads and writes/sec) is halved when ENCRYPT protocol is enabled:
> Infinispan had distributed sync cache with 2 owners on 4 nodes, no transactions. The stress test used 10 threads on each node accessing 1024 byte entries, no conflicts on keys, 20 % writes, 80 % reads. 
> It would be great if we could improve the performance of ENCRYPT protocol.

--
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

From issues at jboss.org  Tue Mar  4 09:41:36 2014
From: issues at jboss.org (Jeff Mesnil (JIRA))
Date: Tue, 4 Mar 2014 09:41:36 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1156) add ability to configure
 local address and port on messaging subsystems connectors
In-Reply-To: <JIRA.12484849.1360771235000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12484849.1360771235000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12484849.1360771235000.1744.1393944096273@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-1156?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jeff Mesnil updated WFLY-1156:
------------------------------

    Affects Version/s: 8.0.0.Final

    
> add ability to configure local address and port on messaging subsystems connectors
> ----------------------------------------------------------------------------------
>
>                 Key: WFLY-1156
>                 URL: https://issues.jboss.org/browse/WFLY-1156
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: JMS
>    Affects Versions: 8.0.0.Final
>            Reporter: Andy Taylor
>            Assignee: Jeff Mesnil
>


--
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

From issues at jboss.org  Tue Mar  4 09:41:36 2014
From: issues at jboss.org (Jeff Mesnil (JIRA))
Date: Tue, 4 Mar 2014 09:41:36 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1156) add ability to configure
 local address and port on messaging subsystems connectors
In-Reply-To: <JIRA.12484849.1360771235000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12484849.1360771235000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12484849.1360771235000.1747.1393944096442@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-1156?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jeff Mesnil updated WFLY-1156:
------------------------------

    Fix Version/s: 8.0.1.Final

    
> add ability to configure local address and port on messaging subsystems connectors
> ----------------------------------------------------------------------------------
>
>                 Key: WFLY-1156
>                 URL: https://issues.jboss.org/browse/WFLY-1156
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: JMS
>    Affects Versions: 8.0.0.Final
>            Reporter: Andy Taylor
>            Assignee: Jeff Mesnil
>             Fix For: 8.0.1.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

From issues at jboss.org  Tue Mar  4 09:49:36 2014
From: issues at jboss.org (niraj gupta (JIRA))
Date: Tue, 4 Mar 2014 09:49:36 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-441) drools-guvnor 5.5,
 declarative model, create more than one fact type,
 BPMN process does not load
In-Reply-To: <JIRA.12533209.1393317312000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12533209.1393317312000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12533209.1393317312000.1873.1393944576640@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/DROOLS-441?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12949823#comment-12949823 ] 

niraj gupta commented on DROOLS-441:
------------------------------------

Thanks for update and  appreciate your suggestions. 
      I also have the same doubt that rebuilding/reloading of the package having some problem. But i am not getting exact location of the code for the fix. I tried the steps you suggested.

 I created 1st package like pkg1, then only one process proc1 and then build deploy.
 Now i created another 2nd package like pkg2, then only one declarative model like 
1.	|			declare Mod1
2.	|			    mid: Integer
3.	|			    mname: String
4.	|			end
5.	|			
6.	|			declare Mod2
7.	|			    bid: Integer
8.	|			end

and save this model. but not build. 

now running the process execute perfectly, even modify multiple time the same process.

But as soon as build the pkg2, and then update the process, it doesn't reflect new  changes in the console.
I am not seeing any exception, as you are telling 2nd build failure case. 

Also if you could help me to which build is having this fix, it would be great.

Actually this fix is very important to us. 

Regards,
Niraj



                
> drools-guvnor 5.5, declarative model, create more than one fact type, BPMN process does not load
> ------------------------------------------------------------------------------------------------
>
>                 Key: DROOLS-441
>                 URL: https://issues.jboss.org/browse/DROOLS-441
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.5.0.Final
>         Environment: Tomcat 6.0.35, jBPM 5.5.Final
>            Reporter: niraj gupta
>            Assignee: Mark Proctor
>              Labels: drools-guvnor
>
>  I am using ?drools-guvnor 5.5.0.Final? open source tool for designing the business process (BPMN2). I end up in an issue and looking for help. Following is the scenario
> I created a package then process then after build, deploy execute successfully. Now I came back to guvnor and made few changes in the process. Then after same build, deploy execute successfully. But now this time I am creating a declarative model having 2 facts, also modifying business process. Then after same build, deploy execute successfully. This time modified/latest business process doesn?t load into console. This is my problem.  However I trouble shoot and google following are my observations:
> ?	I am running this application in tomcat 6.0.35
> ?	It works perfectly with POJO Model Jar approach.
> ?	It works perfectly with declarative model but having single fact.
> ?	I am not seeing any exceptions either in UI or console logs

--
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


From issues at jboss.org  Tue Mar  4 10:01:38 2014
From: issues at jboss.org (Jeff Mesnil (JIRA))
Date: Tue, 4 Mar 2014 10:01:38 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1917) Support socket-binding
 attribute "client-mapping" in messaging subsystem
In-Reply-To: <JIRA.12499094.1377095661000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499094.1377095661000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499094.1377095661000.1932.1393945298302@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-1917?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jeff Mesnil resolved WFLY-1917.
-------------------------------

    Resolution: Rejected


Preferred way to configure the messaging remote-connector is using outbound-socket-binding that allows to define the address that the client must use to connect to the server.


                
> Support socket-binding attribute "client-mapping" in messaging subsystem
> ------------------------------------------------------------------------
>
>                 Key: WFLY-1917
>                 URL: https://issues.jboss.org/browse/WFLY-1917
>             Project: WildFly
>          Issue Type: Enhancement
>      Security Level: Public(Everyone can see) 
>          Components: JMS
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Justin Bertram
>            Assignee: Jeff Mesnil
>
> The messaging subsystem doesn't take into account the "client-mapping" attribute of the <socket-binding> when creating a <netty-connector>.  This forces the user to manually configure a <connector> to support the desired behavior.

--
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

From issues at jboss.org  Tue Mar  4 10:39:34 2014
From: issues at jboss.org (Bela Ban (JIRA))
Date: Tue, 4 Mar 2014 10:39:34 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1804) UDP: sending of multicasts
 fails after an ifdown / ifup cycle
In-Reply-To: <JIRA.12533967.1393947510960@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12533967.1393947510960@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12533967.1393947510960.2089.1393947574426@jira02.app.mwc.hst.phx2.redhat.com>

Bela Ban created JGRP-1804:
------------------------------

             Summary: UDP: sending of multicasts fails after an ifdown / ifup cycle
                 Key: JGRP-1804
                 URL: https://issues.jboss.org/browse/JGRP-1804
             Project: JGroups
          Issue Type: Bug
            Reporter: Bela Ban
            Assignee: Bela Ban
             Fix For: 3.5


After an ifdown / if up cycle, sending of multicast messages over mcast_sock fails with an IOException (no such device). Sending unicast datagram packets works.

SOLUTION:
Catch the IOException on the send and set the interface again ({{MulticastSocket.setInterface()}}). This was confirmed to work.

--
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

From issues at jboss.org  Tue Mar  4 10:39:34 2014
From: issues at jboss.org (Bela Ban (JIRA))
Date: Tue, 4 Mar 2014 10:39:34 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1804) UDP: sending of multicasts
 fails after an ifdown / ifup cycle
In-Reply-To: <JIRA.12533967.1393947510000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12533967.1393947510000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12533967.1393947510000.2091.1393947574516@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JGRP-1804?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban updated JGRP-1804:
---------------------------

    Forum Reference: https://sourceforge.net/p/javagroups/mailman/message/32034144/  (was: https://sourceforge.net/p/javagroups/mailman/message/32058114/)

    
> UDP: sending of multicasts fails after an ifdown / ifup cycle
> -------------------------------------------------------------
>
>                 Key: JGRP-1804
>                 URL: https://issues.jboss.org/browse/JGRP-1804
>             Project: JGroups
>          Issue Type: Bug
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 3.5
>
>
> After an ifdown / if up cycle, sending of multicast messages over mcast_sock fails with an IOException (no such device). Sending unicast datagram packets works.
> SOLUTION:
> Catch the IOException on the send and set the interface again ({{MulticastSocket.setInterface()}}). This was confirmed to work.

--
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

From issues at jboss.org  Tue Mar  4 10:41:34 2014
From: issues at jboss.org (Alessio Soldano (JIRA))
Date: Tue, 4 Mar 2014 10:41:34 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3061) Replace deprecated OPTIONAL
 dependency to MBean server in WS ServerConfigService
In-Reply-To: <JIRA.12533968.1393947587925@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12533968.1393947587925@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12533968.1393947587925.2095.1393947694921@jira02.app.mwc.hst.phx2.redhat.com>

Alessio Soldano created WFLY-3061:
-------------------------------------

             Summary: Replace deprecated OPTIONAL dependency to MBean server in WS ServerConfigService
                 Key: WFLY-3061
                 URL: https://issues.jboss.org/browse/WFLY-3061
             Project: WildFly
          Issue Type: Task
      Security Level: Public (Everyone can see)
          Components: Web Services
            Reporter: Alessio Soldano
            Assignee: Alessio Soldano
             Fix For: 8.0.1.Final


{noformat}
builder.addDependency(DependencyType.OPTIONAL, MBEAN_SERVER_NAME, MBeanServer.class, serverConfig.getMBeanServerInjector());
{noformat}
in org.jboss.as.webservices.service.ServerConfigService needs to be replaced.

--
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

From issues at jboss.org  Tue Mar  4 10:41:35 2014
From: issues at jboss.org (Bela Ban (JIRA))
Date: Tue, 4 Mar 2014 10:41:35 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1804) UDP: sending of multicasts
 fails after an ifdown / ifup cycle
In-Reply-To: <JIRA.12533967.1393947510000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12533967.1393947510000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12533967.1393947510000.2098.1393947695046@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JGRP-1804?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban updated JGRP-1804:
---------------------------

    Description: 
After an ifdown / if up cycle, sending of multicast messages over mcast_sock fails with an IOException (no such device). Sending unicast datagram packets works.

SOLUTION:
Catch the IOException on the send and set the interface again ({{MulticastSocket.setInterface()}}). This was confirmed to work.
Perhaps count the number of failures and only reset the interface when the count exceeds a threshold

  was:
After an ifdown / if up cycle, sending of multicast messages over mcast_sock fails with an IOException (no such device). Sending unicast datagram packets works.

SOLUTION:
Catch the IOException on the send and set the interface again ({{MulticastSocket.setInterface()}}). This was confirmed to work.


    
> UDP: sending of multicasts fails after an ifdown / ifup cycle
> -------------------------------------------------------------
>
>                 Key: JGRP-1804
>                 URL: https://issues.jboss.org/browse/JGRP-1804
>             Project: JGroups
>          Issue Type: Bug
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 3.5
>
>
> After an ifdown / if up cycle, sending of multicast messages over mcast_sock fails with an IOException (no such device). Sending unicast datagram packets works.
> SOLUTION:
> Catch the IOException on the send and set the interface again ({{MulticastSocket.setInterface()}}). This was confirmed to work.
> Perhaps count the number of failures and only reset the interface when the count exceeds a threshold

--
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

From issues at jboss.org  Tue Mar  4 10:41:35 2014
From: issues at jboss.org (Bela Ban (JIRA))
Date: Tue, 4 Mar 2014 10:41:35 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1804) UDP: sending of multicasts
 fails after an ifdown / ifup cycle
In-Reply-To: <JIRA.12533967.1393947510000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12533967.1393947510000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12533967.1393947510000.2113.1393947695841@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JGRP-1804?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban updated JGRP-1804:
---------------------------

    Description: 
After an ifdown / if up cycle, sending / receiving of multicast messages over mcast_sock fails with an IOException (no such device). Sending / receiving unicast datagram packets works.

SOLUTION:
Catch the IOException on the send/receive and set the interface again ({{MulticastSocket.setInterface()}}). This was confirmed to work.
Perhaps count the number of failures and only reset the interface when the count exceeds a threshold

  was:
After an ifdown / if up cycle, sending of multicast messages over mcast_sock fails with an IOException (no such device). Sending unicast datagram packets works.

SOLUTION:
Catch the IOException on the send and set the interface again ({{MulticastSocket.setInterface()}}). This was confirmed to work.
Perhaps count the number of failures and only reset the interface when the count exceeds a threshold


    
> UDP: sending of multicasts fails after an ifdown / ifup cycle
> -------------------------------------------------------------
>
>                 Key: JGRP-1804
>                 URL: https://issues.jboss.org/browse/JGRP-1804
>             Project: JGroups
>          Issue Type: Bug
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 3.5
>
>
> After an ifdown / if up cycle, sending / receiving of multicast messages over mcast_sock fails with an IOException (no such device). Sending / receiving unicast datagram packets works.
> SOLUTION:
> Catch the IOException on the send/receive and set the interface again ({{MulticastSocket.setInterface()}}). This was confirmed to work.
> Perhaps count the number of failures and only reset the interface when the count exceeds a threshold

--
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

From issues at jboss.org  Tue Mar  4 10:45:35 2014
From: issues at jboss.org (Mario Fusco (JIRA))
Date: Tue, 4 Mar 2014 10:45:35 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-444) NOT conditional element is
 broken when used with subnetworks
In-Reply-To: <JIRA.12533569.1393544376000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12533569.1393544376000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12533569.1393544376000.2131.1393947935828@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-444?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mario Fusco reassigned DROOLS-444:
----------------------------------

    Assignee: Mario Fusco  (was: Mark Proctor)

    
> NOT conditional element is broken when used with subnetworks
> ------------------------------------------------------------
>
>                 Key: DROOLS-444
>                 URL: https://issues.jboss.org/browse/DROOLS-444
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 6.0.0.Final, 6.0.1.Final
>            Reporter: Davide Sottara
>            Assignee: Mario Fusco
>            Priority: Critical
>


--
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

From issues at jboss.org  Tue Mar  4 10:53:33 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 4 Mar 2014 10:53:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-444) NOT conditional element is
 broken when used with subnetworks
In-Reply-To: <JIRA.12533569.1393544376000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12533569.1393544376000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12533569.1393544376000.2179.1393948413693@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-444?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated DROOLS-444:
-------------------------------------------

        Bugzilla Update: Perform
    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1072462

    
> NOT conditional element is broken when used with subnetworks
> ------------------------------------------------------------
>
>                 Key: DROOLS-444
>                 URL: https://issues.jboss.org/browse/DROOLS-444
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 6.0.0.Final, 6.0.1.Final
>            Reporter: Davide Sottara
>            Assignee: Mario Fusco
>            Priority: Critical
>


--
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

From issues at jboss.org  Tue Mar  4 10:55:33 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 4 Mar 2014 10:55:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-444) NOT conditional element is
 broken when used with subnetworks
In-Reply-To: <JIRA.12533569.1393544376000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12533569.1393544376000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12533569.1393544376000.2184.1393948533376@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/DROOLS-444?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12949870#comment-12949870 ] 

RH Bugzilla Integration commented on DROOLS-444:
------------------------------------------------

Mario Fusco <mfusco at redhat.com> changed the Status of [bug 1072462|https://bugzilla.redhat.com/show_bug.cgi?id=1072462] from NEW to ASSIGNED
                
> NOT conditional element is broken when used with subnetworks
> ------------------------------------------------------------
>
>                 Key: DROOLS-444
>                 URL: https://issues.jboss.org/browse/DROOLS-444
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 6.0.0.Final, 6.0.1.Final
>            Reporter: Davide Sottara
>            Assignee: Mario Fusco
>            Priority: Critical
>


--
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

From issues at jboss.org  Tue Mar  4 11:13:33 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 4 Mar 2014 11:13:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-444) NOT conditional element is
 broken when used with subnetworks
In-Reply-To: <JIRA.12533569.1393544376000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12533569.1393544376000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12533569.1393544376000.2200.1393949613210@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-444?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated DROOLS-444:
-------------------------------------------

    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1072462, https://bugzilla.redhat.com/show_bug.cgi?id=1072463  (was: https://bugzilla.redhat.com/show_bug.cgi?id=1072462)

    
> NOT conditional element is broken when used with subnetworks
> ------------------------------------------------------------
>
>                 Key: DROOLS-444
>                 URL: https://issues.jboss.org/browse/DROOLS-444
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 6.0.0.Final, 6.0.1.Final
>            Reporter: Davide Sottara
>            Assignee: Mario Fusco
>            Priority: Critical
>


--
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

From issues at jboss.org  Tue Mar  4 11:15:34 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 4 Mar 2014 11:15:34 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-444) NOT conditional element is
 broken when used with subnetworks
In-Reply-To: <JIRA.12533569.1393544376000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12533569.1393544376000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12533569.1393544376000.2207.1393949734312@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-444?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated DROOLS-444:
-------------------------------------------

    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1072462  (was: https://bugzilla.redhat.com/show_bug.cgi?id=1072462, https://bugzilla.redhat.com/show_bug.cgi?id=1072463)

    
> NOT conditional element is broken when used with subnetworks
> ------------------------------------------------------------
>
>                 Key: DROOLS-444
>                 URL: https://issues.jboss.org/browse/DROOLS-444
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 6.0.0.Final, 6.0.1.Final
>            Reporter: Davide Sottara
>            Assignee: Mario Fusco
>            Priority: Critical
>


--
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

From issues at jboss.org  Tue Mar  4 11:17:34 2014
From: issues at jboss.org (Harald Pehl (JIRA))
Date: Tue, 4 Mar 2014 11:17:34 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3062) Update to HAL 2.2.0.Beta3
In-Reply-To: <JIRA.12533974.1393949746399@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12533974.1393949746399@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12533974.1393949746399.2212.1393949854146@jira02.app.mwc.hst.phx2.redhat.com>

Harald Pehl created WFLY-3062:
---------------------------------

             Summary: Update to HAL 2.2.0.Beta3
                 Key: WFLY-3062
                 URL: https://issues.jboss.org/browse/WFLY-3062
             Project: WildFly
          Issue Type: Component  Upgrade
      Security Level: Public (Everyone can see)
          Components: Web Console
            Reporter: Harald Pehl
            Assignee: Harald Pehl
            Priority: Blocker
             Fix For: 8.0.1.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

From issues at jboss.org  Tue Mar  4 11:53:33 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 4 Mar 2014 11:53:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-444) NOT conditional element is
 broken when used with subnetworks
In-Reply-To: <JIRA.12533569.1393544376000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12533569.1393544376000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12533569.1393544376000.2286.1393952013924@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/DROOLS-444?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12949888#comment-12949888 ] 

RH Bugzilla Integration commented on DROOLS-444:
------------------------------------------------

Mario Fusco <mfusco at redhat.com> changed the Status of [bug 1072462|https://bugzilla.redhat.com/show_bug.cgi?id=1072462] from ASSIGNED to MODIFIED
                
> NOT conditional element is broken when used with subnetworks
> ------------------------------------------------------------
>
>                 Key: DROOLS-444
>                 URL: https://issues.jboss.org/browse/DROOLS-444
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 6.0.0.Final, 6.0.1.Final
>            Reporter: Davide Sottara
>            Assignee: Mario Fusco
>            Priority: Critical
>


--
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

From issues at jboss.org  Tue Mar  4 12:21:33 2014
From: issues at jboss.org (Rituraj Sinha (JIRA))
Date: Tue, 4 Mar 2014 12:21:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3051) JMX connection to remote
 server-instances is not happening in wildfly 8.0.0.Final in domain mode
In-Reply-To: <JIRA.12533723.1393825342000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12533723.1393825342000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12533723.1393825342000.2374.1393953693120@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-3051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12949904#comment-12949904 ] 

Rituraj Sinha commented on WFLY-3051:
-------------------------------------

Hi Darran,

is there any progress related to the issue ...?

Thanks
                
> JMX connection to remote server-instances is not happening in wildfly 8.0.0.Final in domain mode
> ------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-3051
>                 URL: https://issues.jboss.org/browse/WFLY-3051
>             Project: WildFly
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: JMX, Remoting
>    Affects Versions: 8.0.0.Final
>            Reporter: Rituraj Sinha
>            Assignee: Darran Lofthouse
>             Fix For: 8.0.1.Final
>
>
> i have gone through the below link for JMX subsystem for wildfly 8 as
> https://docs.jboss.org/author/display/WFLY8/JMX+subsystem+configuration
>  
> but unable to connect to server-instances running remotely ...i have posted my question there as well and pasting it here now ...
> can someone please give us the steps to configure JMX through jconsole...?
> changes done on the domain.xml are the same as stated above
> <subsystem xmlns="urn:jboss:domain:jmx:1.3">
>                 <expose-resolved-model/>
>                 <expose-expression-model/>
>                 <remoting-connector use-management-endpoint="false"/>
>             </subsystem>
> <subsystem xmlns="urn:jboss:domain:jmx:1.3">
>                 <expose-resolved-model/>
>                 <expose-expression-model/>
>                 <remoting-connector use-management-endpoint="false"/>
>             </subsystem>
> as per the jboss-as-jmx_1_3.xsd  its like
> <xs:attribute name="use-management-endpoint" type="xs:boolean" default="true" use="optional" >
>             <xs:annotation>
>                 <xs:documentation>
>                     If true then this connector will use the management endpoint, otherwise it will use the
>                     remoting subsystem endpoint.
>                 </xs:documentation>
>             </xs:annotation>
>         </xs:attribute>
> now if we are making it false then it should be using the remoting endpoint ...now remoting subsystem by default uses ApplicatoinRealm
> i have created application-user and password for the same but when i am trying to connect to remote server-instances its not connecting it....
> below is what i am able to connect to 
> service:jmx:http-remoting-jmx://remote_hostA:9990 --
> Unknown macro: {host A is where my domain_controller is running}
> how can i access the server-instances running on domain_controller
> Unknown macro: {there are three server_instanaces running on HostA with a port offset of 100 each}
> i am trying to connect with the below url as 
> service:jmx:http-remoting-jmx://lremote_hostA:8180
> let me know if something is missing from my side...
> Thanks

--
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

From issues at jboss.org  Tue Mar  4 12:23:34 2014
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 4 Mar 2014 12:23:34 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3051) JMX connection to remote
 server-instances is not happening in wildfly 8.0.0.Final in domain mode
In-Reply-To: <JIRA.12533723.1393825342000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12533723.1393825342000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12533723.1393825342000.2388.1393953814058@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-3051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12949906#comment-12949906 ] 

Darran Lofthouse commented on WFLY-3051:
----------------------------------------

I have scheduled this issue so that I can investigate it further, at this point I have no further information.
                
> JMX connection to remote server-instances is not happening in wildfly 8.0.0.Final in domain mode
> ------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-3051
>                 URL: https://issues.jboss.org/browse/WFLY-3051
>             Project: WildFly
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: JMX, Remoting
>    Affects Versions: 8.0.0.Final
>            Reporter: Rituraj Sinha
>            Assignee: Darran Lofthouse
>             Fix For: 8.0.1.Final
>
>
> i have gone through the below link for JMX subsystem for wildfly 8 as
> https://docs.jboss.org/author/display/WFLY8/JMX+subsystem+configuration
>  
> but unable to connect to server-instances running remotely ...i have posted my question there as well and pasting it here now ...
> can someone please give us the steps to configure JMX through jconsole...?
> changes done on the domain.xml are the same as stated above
> <subsystem xmlns="urn:jboss:domain:jmx:1.3">
>                 <expose-resolved-model/>
>                 <expose-expression-model/>
>                 <remoting-connector use-management-endpoint="false"/>
>             </subsystem>
> <subsystem xmlns="urn:jboss:domain:jmx:1.3">
>                 <expose-resolved-model/>
>                 <expose-expression-model/>
>                 <remoting-connector use-management-endpoint="false"/>
>             </subsystem>
> as per the jboss-as-jmx_1_3.xsd  its like
> <xs:attribute name="use-management-endpoint" type="xs:boolean" default="true" use="optional" >
>             <xs:annotation>
>                 <xs:documentation>
>                     If true then this connector will use the management endpoint, otherwise it will use the
>                     remoting subsystem endpoint.
>                 </xs:documentation>
>             </xs:annotation>
>         </xs:attribute>
> now if we are making it false then it should be using the remoting endpoint ...now remoting subsystem by default uses ApplicatoinRealm
> i have created application-user and password for the same but when i am trying to connect to remote server-instances its not connecting it....
> below is what i am able to connect to 
> service:jmx:http-remoting-jmx://remote_hostA:9990 --
> Unknown macro: {host A is where my domain_controller is running}
> how can i access the server-instances running on domain_controller
> Unknown macro: {there are three server_instanaces running on HostA with a port offset of 100 each}
> i am trying to connect with the below url as 
> service:jmx:http-remoting-jmx://lremote_hostA:8180
> let me know if something is missing from my side...
> Thanks

--
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

From issues at jboss.org  Tue Mar  4 12:33:33 2014
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 4 Mar 2014 12:33:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3063) Duplicate existing test that
 replicates ejb-security-interceptors quickstart so we can use new API
In-Reply-To: <JIRA.12533992.1393954373484@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12533992.1393954373484@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12533992.1393954373484.2507.1393954413164@jira02.app.mwc.hst.phx2.redhat.com>

Darran Lofthouse created WFLY-3063:
--------------------------------------

             Summary: Duplicate existing test that replicates ejb-security-interceptors quickstart so we can use new API
                 Key: WFLY-3063
                 URL: https://issues.jboss.org/browse/WFLY-3063
             Project: WildFly
          Issue Type: Sub-task
      Security Level: Public (Everyone can see)
          Components: Test Suite
            Reporter: Darran Lofthouse
            Assignee: Darran Lofthouse
             Fix For: 8.0.1.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

From issues at jboss.org  Tue Mar  4 12:53:33 2014
From: issues at jboss.org (John Patton (JIRA))
Date: Tue, 4 Mar 2014 12:53:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3051) JMX connection to remote
 server-instances is not happening in wildfly 8.0.0.Final in domain mode
In-Reply-To: <JIRA.12533723.1393825342000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12533723.1393825342000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12533723.1393825342000.2522.1393955613786@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-3051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12949910#comment-12949910 ] 

John Patton commented on WFLY-3051:
-----------------------------------

Stuck on this, as well.  Thanks for looking into it.
                
> JMX connection to remote server-instances is not happening in wildfly 8.0.0.Final in domain mode
> ------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-3051
>                 URL: https://issues.jboss.org/browse/WFLY-3051
>             Project: WildFly
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: JMX, Remoting
>    Affects Versions: 8.0.0.Final
>            Reporter: Rituraj Sinha
>            Assignee: Darran Lofthouse
>             Fix For: 8.0.1.Final
>
>
> i have gone through the below link for JMX subsystem for wildfly 8 as
> https://docs.jboss.org/author/display/WFLY8/JMX+subsystem+configuration
>  
> but unable to connect to server-instances running remotely ...i have posted my question there as well and pasting it here now ...
> can someone please give us the steps to configure JMX through jconsole...?
> changes done on the domain.xml are the same as stated above
> <subsystem xmlns="urn:jboss:domain:jmx:1.3">
>                 <expose-resolved-model/>
>                 <expose-expression-model/>
>                 <remoting-connector use-management-endpoint="false"/>
>             </subsystem>
> <subsystem xmlns="urn:jboss:domain:jmx:1.3">
>                 <expose-resolved-model/>
>                 <expose-expression-model/>
>                 <remoting-connector use-management-endpoint="false"/>
>             </subsystem>
> as per the jboss-as-jmx_1_3.xsd  its like
> <xs:attribute name="use-management-endpoint" type="xs:boolean" default="true" use="optional" >
>             <xs:annotation>
>                 <xs:documentation>
>                     If true then this connector will use the management endpoint, otherwise it will use the
>                     remoting subsystem endpoint.
>                 </xs:documentation>
>             </xs:annotation>
>         </xs:attribute>
> now if we are making it false then it should be using the remoting endpoint ...now remoting subsystem by default uses ApplicatoinRealm
> i have created application-user and password for the same but when i am trying to connect to remote server-instances its not connecting it....
> below is what i am able to connect to 
> service:jmx:http-remoting-jmx://remote_hostA:9990 --
> Unknown macro: {host A is where my domain_controller is running}
> how can i access the server-instances running on domain_controller
> Unknown macro: {there are three server_instanaces running on HostA with a port offset of 100 each}
> i am trying to connect with the below url as 
> service:jmx:http-remoting-jmx://lremote_hostA:8180
> let me know if something is missing from my side...
> Thanks

--
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

From issues at jboss.org  Tue Mar  4 13:41:33 2014
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 4 Mar 2014 13:41:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3064) Remove
 org.jboss.as.test.integration.ejb.container.interceptor.security.SwitchIdentityTestCase
 test case.
In-Reply-To: <JIRA.12534003.1393958385371@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534003.1393958385371@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534003.1393958385371.2599.1393958493662@jira02.app.mwc.hst.phx2.redhat.com>

Darran Lofthouse created WFLY-3064:
--------------------------------------

             Summary: Remove org.jboss.as.test.integration.ejb.container.interceptor.security.SwitchIdentityTestCase test case.
                 Key: WFLY-3064
                 URL: https://issues.jboss.org/browse/WFLY-3064
             Project: WildFly
          Issue Type: Sub-task
      Security Level: Public (Everyone can see)
          Components: Test Suite
            Reporter: Darran Lofthouse
            Assignee: Darran Lofthouse
             Fix For: 9.0.0.CR1


A new test case was added under WFLY-3063 that demonstrates the correct way to do this so now remove the original way that depended on internal APIs.

--
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

From issues at jboss.org  Tue Mar  4 14:05:33 2014
From: issues at jboss.org (Peter Skopek (JIRA))
Date: Tue, 4 Mar 2014 14:05:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3065) org.picketlink.common module
 is missing dependencies
In-Reply-To: <JIRA.12534008.1393959899214@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534008.1393959899214@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534008.1393959899214.2664.1393959933949@jira02.app.mwc.hst.phx2.redhat.com>

Peter Skopek created WFLY-3065:
----------------------------------

             Summary: org.picketlink.common module is missing dependencies
                 Key: WFLY-3065
                 URL: https://issues.jboss.org/browse/WFLY-3065
             Project: WildFly
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions: 8.0.0.Final
            Reporter: Peter Skopek
            Assignee: Peter Skopek


Module org.picketlink.common is missing dependencies for javax.xml.bind.api and javax.xml.ws.api.

--
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

From issues at jboss.org  Tue Mar  4 14:07:33 2014
From: issues at jboss.org (Peter Skopek (JIRA))
Date: Tue, 4 Mar 2014 14:07:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3065) org.picketlink.common module
 is missing dependencies
In-Reply-To: <JIRA.12534008.1393959899000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534008.1393959899000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534008.1393959899000.2677.1393960053229@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-3065?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12949940#comment-12949940 ] 

Peter Skopek commented on WFLY-3065:
------------------------------------

Original issue is: https://bugzilla.redhat.com/show_bug.cgi?id=1064405
                
> org.picketlink.common module is missing dependencies
> ----------------------------------------------------
>
>                 Key: WFLY-3065
>                 URL: https://issues.jboss.org/browse/WFLY-3065
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 8.0.0.Final
>            Reporter: Peter Skopek
>            Assignee: Peter Skopek
>
> Module org.picketlink.common is missing dependencies for javax.xml.bind.api and javax.xml.ws.api.

--
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

From issues at jboss.org  Tue Mar  4 14:51:33 2014
From: issues at jboss.org (Richard Achmatowicz (JIRA))
Date: Tue, 4 Mar 2014 14:51:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1805) OverlappingMergeTest
 testMergeWithDifferentPartitions fails to create correct merged view
In-Reply-To: <JIRA.12534032.1393962618439@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534032.1393962618439@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534032.1393962618439.2821.1393962693546@jira02.app.mwc.hst.phx2.redhat.com>

Richard Achmatowicz created JGRP-1805:
-----------------------------------------

             Summary: OverlappingMergeTest testMergeWithDifferentPartitions fails to create correct merged view
                 Key: JGRP-1805
                 URL: https://issues.jboss.org/browse/JGRP-1805
             Project: JGroups
          Issue Type: Bug
    Affects Versions: 3.2.13
         Environment: RHEL
            Reporter: Richard Achmatowicz
            Assignee: Bela Ban
             Fix For: 3.2.13


This test does the following:
- creates four channels a,b,c,d
- injects views A: {A,C,B}, B:{A,C,B}, C:{A,C,B} and D: {B,A,C,D}
- injects a merge event in each of channels A,B,C,D representing these four views
- checks that all channels have the final view of size 4

The test fails intermittently on RHEL, with the same failure each time:

{noformat}
181595 [DEBUG] GMS: - A: installing view [A|2] [A]
   [testng] 181596 [TRACE] GMS: - A: received all 1 ACKs from members for view [A|2]
   [testng] 181866 [TRACE] GMS: - view [A|3] [] is empty: will not multicast it (last view)
   [testng] 
   [testng] -------------------------------------------------------------------
   [testng] GMS: address=A, cluster=OverlappingMergeTest, physical address=10.16.94.42:27199
   [testng] -------------------------------------------------------------------
   [testng] 184954 [TRACE] GMS: - A: no initial members discovered: creating group as first member
   [testng] 184954 [DEBUG] GMS: - A: installing view [A|0] [A]
   [testng] 184955 [DEBUG] GMS: - created group (first member). My view is [A|0], impl is org.jgroups.protocols.pbcast.CoordGmsImpl
   [testng] 
   [testng] -------------------------------------------------------------------
   [testng] GMS: address=B, cluster=OverlappingMergeTest, physical address=10.16.94.42:27200
   [testng] -------------------------------------------------------------------
   [testng] 184961 [TRACE] GMS: - B: initial_mbrs are A 
   [testng] 184961 [DEBUG] GMS: - election results: {A=1}
   [testng] 184961 [DEBUG] GMS: - sending JOIN(B) to A
   [testng] 185013 [TRACE] GMS: - A: new members=[B], suspected=[], leaving=[], new view: [A|1] [A, B]
   [testng] 185014 [TRACE] GMS: - A: mcasting view [A|1] [A, B] (2 mbrs)
   [testng] 
   [testng] 185025 [DEBUG] GMS: - A: installing view [A|1] [A, B]
   [testng] 185026 [TRACE] GMS: - A: received all 1 ACKs from members for view [A|1]
   [testng] 185055 [TRACE] GMS: - B: JOIN-RSP=[A|1] [A, B] [size=2]
   [testng] 
   [testng] 
   [testng] 185055 [DEBUG] GMS: - B: installing view [A|1] [A, B]
   [testng] 185057 [TRACE] GMS: - A: received all ACKs (1) from joiners for view [A|1]
   [testng] 
   [testng] -------------------------------------------------------------------
   [testng] GMS: address=C, cluster=OverlappingMergeTest, physical address=10.16.94.42:27201
   [testng] -------------------------------------------------------------------
   [testng] 185064 [TRACE] GMS: - C: initial_mbrs are B A 
   [testng] 185064 [DEBUG] GMS: - election results: {A=2}
   [testng] 185064 [DEBUG] GMS: - sending JOIN(C) to A
   [testng] 185108 [TRACE] GMS: - A: new members=[C], suspected=[], leaving=[], new view: [A|2] [A, B, C]
   [testng] 185108 [TRACE] GMS: - A: mcasting view [A|2] [A, B, C] (3 mbrs)
   [testng] 
   [testng] 185117 [DEBUG] GMS: - A: installing view [A|2] [A, B, C]
   [testng] 185118 [DEBUG] GMS: - B: installing view [A|2] [A, B, C]
   [testng] 185119 [TRACE] GMS: - A: received all 2 ACKs from members for view [A|2]
   [testng] 185148 [TRACE] GMS: - C: JOIN-RSP=[A|2] [A, B, C] [size=3]
   [testng] 
   [testng] 
   [testng] 185149 [DEBUG] GMS: - C: installing view [A|2] [A, B, C]
   [testng] 185151 [TRACE] GMS: - A: received all ACKs (1) from joiners for view [A|2]
   [testng] 
   [testng] -------------------------------------------------------------------
   [testng] GMS: address=D, cluster=OverlappingMergeTest, physical address=10.16.94.42:27202
   [testng] -------------------------------------------------------------------
   [testng] 185164 [TRACE] GMS: - D: initial_mbrs are B C A 
   [testng] 185164 [DEBUG] GMS: - election results: {A=3}
   [testng] 185164 [DEBUG] GMS: - sending JOIN(D) to A
   [testng] 185203 [TRACE] GMS: - A: new members=[D], suspected=[], leaving=[], new view: [A|3] [A, B, C, D]
   [testng] 185203 [TRACE] GMS: - A: mcasting view [A|3] [A, B, C, D] (4 mbrs)
   [testng] 
   [testng] 185210 [DEBUG] GMS: - A: installing view [A|3] [A, B, C, D]
   [testng] 185211 [DEBUG] GMS: - B: installing view [A|3] [A, B, C, D]
   [testng] 185211 [DEBUG] GMS: - C: installing view [A|3] [A, B, C, D]
   [testng] 185213 [TRACE] GMS: - A: received all 3 ACKs from members for view [A|3]
   [testng] 185242 [TRACE] GMS: - D: JOIN-RSP=[A|3] [A, B, C, D] [size=4]
   [testng] 
   [testng] 
   [testng] 185242 [DEBUG] GMS: - D: installing view [A|3] [A, B, C, D]
   [testng] 185242 [TRACE] GMS: - A: received all ACKs (1) from joiners for view [A|3]
   [testng] 
   [testng]  ==== Injecting view [A|4] [A, C, B] into A, B and C ====
   [testng] 185243 [DEBUG] GMS: - A: installing view [A|4] [A, C, B]
   [testng] 185243 [DEBUG] GMS: - B: installing view [A|4] [A, C, B]
   [testng] 185244 [DEBUG] GMS: - C: installing view [A|4] [A, C, B]
   [testng] 
   [testng]  ==== Injecting view [B|4] [B, A, C, D] into D ====
   [testng] 
   [testng] 185245 [DEBUG] GMS: - D: installing view [B|4] [B, A, C, D]
   [testng] A: [A|4] [A, C, B]
   [testng] B: [A|4] [A, C, B]
   [testng] C: [A|4] [A, C, B]
   [testng] D: [B|4] [B, A, C, D]
   [testng] 
   [testng] ==== Injecting a merge event into A, B, C and D====
   [testng] 185251 [TRACE] GMS: - A: got merge response from A, merge_id=A::3, merge data is sender=A, view=[A|4] [A, C, B], digest=C: [0 (0)], B: [0 (0)], A: [4 (4)]
   [testng] 185253 [TRACE] GMS: - B: queue is suspended; request MERGE(4 views) is discarded
   [testng] 185255 [TRACE] GMS: - C: queue is suspended; request MERGE(4 views) is discarded
   [testng] 185255 [TRACE] GMS: - A: got merge response from B, merge_id=A::3, merge data is sender=B, view=[A|4] [A, C, B], digest=C: [0 (0)], B: [0 (1)], A: [4 (4)]
   [testng] 190286 [TRACE] GMS: - A: mcasting view MergeView::[A|5] [A, B, C], subgroups=[A|4] [A, C, B], [A|4] [A, C, B] (3 mbrs)
   [testng] 
   [testng] 190286 [TRACE] GMS: - B: mcasting view MergeView::[A|5] [A, B, C], subgroups=[A|4] [A, C, B], [A|4] [A, C, B] (3 mbrs)
   [testng] 
   [testng] 190317 [DEBUG] GMS: - A: installing view MergeView::[A|5] [A, B, C], subgroups=[A|4] [A, C, B], [A|4] [A, C, B]
   [testng] 190318 [DEBUG] GMS: - B: installing view MergeView::[A|5] [A, B, C], subgroups=[A|4] [A, C, B], [A|4] [A, C, B]
   [testng] 190318 [DEBUG] GMS: - C: installing view MergeView::[A|5] [A, B, C], subgroups=[A|4] [A, C, B], [A|4] [A, C, B]
   [testng] 190320 [TRACE] GMS: - A: received all 3 ACKs from members for view [A|5]
   [testng] 190320 [TRACE] GMS: - B: received all 3 ACKs from members for view [A|5]
   [testng] A: [A|5] [A, B, C] (coord=true)
   [testng] B: [A|5] [A, B, C] (coord=false)
   [testng] C: [A|5] [A, B, C] (coord=false)
   [testng] D: [B|4] [B, A, C, D] (coord=false)
   [testng] 195277 [DEBUG] GMS: - D: sending LEAVE request to B
   [testng] FAIL: [1] org.jgroups.tests.OverlappingMergeTest.testMergeWithDifferentPartitions()
{noformat}

 Whenever this test fails, I see that the queues are suspended.

--
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

From issues at jboss.org  Tue Mar  4 14:51:33 2014
From: issues at jboss.org (Richard Achmatowicz (JIRA))
Date: Tue, 4 Mar 2014 14:51:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1805) OverlappingMergeTest
 testMergeWithDifferentPartitions fails to create correct merged view
In-Reply-To: <JIRA.12534032.1393962618000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534032.1393962618000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534032.1393962618000.2824.1393962693740@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JGRP-1805?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Richard Achmatowicz updated JGRP-1805:
--------------------------------------

    Description: 
This test does the following:
- creates four channels a,b,c,d
- injects views A: {A,C,B}, B:{A,C,B}, C:{A,C,B} and D: {B,A,C,D}
- injects a merge event in each of channels A,B,C,D representing these four views
- checks that all channels have the final view of size 4

The test fails intermittently on RHEL, with the same failure each time:

{noformat}
181595 [DEBUG] GMS: - A: installing view [A|2] [A]
   [testng] 181596 [TRACE] GMS: - A: received all 1 ACKs from members for view [A|2]
   [testng] 181866 [TRACE] GMS: - view [A|3] [] is empty: will not multicast it (last view)
   [testng] 
   [testng] -------------------------------------------------------------------
   [testng] GMS: address=A, cluster=OverlappingMergeTest, physical address=10.16.94.42:27199
   [testng] -------------------------------------------------------------------
   [testng] 184954 [TRACE] GMS: - A: no initial members discovered: creating group as first member
   [testng] 184954 [DEBUG] GMS: - A: installing view [A|0] [A]
   [testng] 184955 [DEBUG] GMS: - created group (first member). My view is [A|0], impl is org.jgroups.protocols.pbcast.CoordGmsImpl
   [testng] 
   [testng] -------------------------------------------------------------------
   [testng] GMS: address=B, cluster=OverlappingMergeTest, physical address=10.16.94.42:27200
   [testng] -------------------------------------------------------------------
   [testng] 184961 [TRACE] GMS: - B: initial_mbrs are A 
   [testng] 184961 [DEBUG] GMS: - election results: {A=1}
   [testng] 184961 [DEBUG] GMS: - sending JOIN(B) to A
   [testng] 185013 [TRACE] GMS: - A: new members=[B], suspected=[], leaving=[], new view: [A|1] [A, B]
   [testng] 185014 [TRACE] GMS: - A: mcasting view [A|1] [A, B] (2 mbrs)
   [testng] 
   [testng] 185025 [DEBUG] GMS: - A: installing view [A|1] [A, B]
   [testng] 185026 [TRACE] GMS: - A: received all 1 ACKs from members for view [A|1]
   [testng] 185055 [TRACE] GMS: - B: JOIN-RSP=[A|1] [A, B] [size=2]
   [testng] 
   [testng] 
   [testng] 185055 [DEBUG] GMS: - B: installing view [A|1] [A, B]
   [testng] 185057 [TRACE] GMS: - A: received all ACKs (1) from joiners for view [A|1]
   [testng] 
   [testng] -------------------------------------------------------------------
   [testng] GMS: address=C, cluster=OverlappingMergeTest, physical address=10.16.94.42:27201
   [testng] -------------------------------------------------------------------
   [testng] 185064 [TRACE] GMS: - C: initial_mbrs are B A 
   [testng] 185064 [DEBUG] GMS: - election results: {A=2}
   [testng] 185064 [DEBUG] GMS: - sending JOIN(C) to A
   [testng] 185108 [TRACE] GMS: - A: new members=[C], suspected=[], leaving=[], new view: [A|2] [A, B, C]
   [testng] 185108 [TRACE] GMS: - A: mcasting view [A|2] [A, B, C] (3 mbrs)
   [testng] 
   [testng] 185117 [DEBUG] GMS: - A: installing view [A|2] [A, B, C]
   [testng] 185118 [DEBUG] GMS: - B: installing view [A|2] [A, B, C]
   [testng] 185119 [TRACE] GMS: - A: received all 2 ACKs from members for view [A|2]
   [testng] 185148 [TRACE] GMS: - C: JOIN-RSP=[A|2] [A, B, C] [size=3]
   [testng] 
   [testng] 
   [testng] 185149 [DEBUG] GMS: - C: installing view [A|2] [A, B, C]
   [testng] 185151 [TRACE] GMS: - A: received all ACKs (1) from joiners for view [A|2]
   [testng] 
   [testng] -------------------------------------------------------------------
   [testng] GMS: address=D, cluster=OverlappingMergeTest, physical address=10.16.94.42:27202
   [testng] -------------------------------------------------------------------
   [testng] 185164 [TRACE] GMS: - D: initial_mbrs are B C A 
   [testng] 185164 [DEBUG] GMS: - election results: {A=3}
   [testng] 185164 [DEBUG] GMS: - sending JOIN(D) to A
   [testng] 185203 [TRACE] GMS: - A: new members=[D], suspected=[], leaving=[], new view: [A|3] [A, B, C, D]
   [testng] 185203 [TRACE] GMS: - A: mcasting view [A|3] [A, B, C, D] (4 mbrs)
   [testng] 
   [testng] 185210 [DEBUG] GMS: - A: installing view [A|3] [A, B, C, D]
   [testng] 185211 [DEBUG] GMS: - B: installing view [A|3] [A, B, C, D]
   [testng] 185211 [DEBUG] GMS: - C: installing view [A|3] [A, B, C, D]
   [testng] 185213 [TRACE] GMS: - A: received all 3 ACKs from members for view [A|3]
   [testng] 185242 [TRACE] GMS: - D: JOIN-RSP=[A|3] [A, B, C, D] [size=4]
   [testng] 
   [testng] 
   [testng] 185242 [DEBUG] GMS: - D: installing view [A|3] [A, B, C, D]
   [testng] 185242 [TRACE] GMS: - A: received all ACKs (1) from joiners for view [A|3]
   [testng] 
   [testng]  ==== Injecting view [A|4] [A, C, B] into A, B and C ====
   [testng] 185243 [DEBUG] GMS: - A: installing view [A|4] [A, C, B]
   [testng] 185243 [DEBUG] GMS: - B: installing view [A|4] [A, C, B]
   [testng] 185244 [DEBUG] GMS: - C: installing view [A|4] [A, C, B]
   [testng] 
   [testng]  ==== Injecting view [B|4] [B, A, C, D] into D ====
   [testng] 
   [testng] 185245 [DEBUG] GMS: - D: installing view [B|4] [B, A, C, D]
   [testng] A: [A|4] [A, C, B]
   [testng] B: [A|4] [A, C, B]
   [testng] C: [A|4] [A, C, B]
   [testng] D: [B|4] [B, A, C, D]
   [testng] 
   [testng] ==== Injecting a merge event into A, B, C and D====
   [testng] 185251 [TRACE] GMS: - A: got merge response from A, merge_id=A::3, merge data is sender=A, view=[A|4] [A, C, B], digest=C: [0 (0)], B: [0 (0)], A: [4 (4)]
   [testng] 185253 [TRACE] GMS: - B: queue is suspended; request MERGE(4 views) is discarded
   [testng] 185255 [TRACE] GMS: - C: queue is suspended; request MERGE(4 views) is discarded
   [testng] 185255 [TRACE] GMS: - A: got merge response from B, merge_id=A::3, merge data is sender=B, view=[A|4] [A, C, B], digest=C: [0 (0)], B: [0 (1)], A: [4 (4)]
   [testng] 190286 [TRACE] GMS: - A: mcasting view MergeView::[A|5] [A, B, C], subgroups=[A|4] [A, C, B], [A|4] [A, C, B] (3 mbrs)
   [testng] 
   [testng] 190286 [TRACE] GMS: - B: mcasting view MergeView::[A|5] [A, B, C], subgroups=[A|4] [A, C, B], [A|4] [A, C, B] (3 mbrs)
   [testng] 
   [testng] 190317 [DEBUG] GMS: - A: installing view MergeView::[A|5] [A, B, C], subgroups=[A|4] [A, C, B], [A|4] [A, C, B]
   [testng] 190318 [DEBUG] GMS: - B: installing view MergeView::[A|5] [A, B, C], subgroups=[A|4] [A, C, B], [A|4] [A, C, B]
   [testng] 190318 [DEBUG] GMS: - C: installing view MergeView::[A|5] [A, B, C], subgroups=[A|4] [A, C, B], [A|4] [A, C, B]
   [testng] 190320 [TRACE] GMS: - A: received all 3 ACKs from members for view [A|5]
   [testng] 190320 [TRACE] GMS: - B: received all 3 ACKs from members for view [A|5]
   [testng] A: [A|5] [A, B, C] (coord=true)
   [testng] B: [A|5] [A, B, C] (coord=false)
   [testng] C: [A|5] [A, B, C] (coord=false)
   [testng] D: [B|4] [B, A, C, D] (coord=false)
   [testng] 195277 [DEBUG] GMS: - D: sending LEAVE request to B
   [testng] FAIL: [1] org.jgroups.tests.OverlappingMergeTest.testMergeWithDifferentPartitions()
{noformat}

 Whenever this test fails, I see that the queues are suspended on the initial merge attempt.

  was:
This test does the following:
- creates four channels a,b,c,d
- injects views A: {A,C,B}, B:{A,C,B}, C:{A,C,B} and D: {B,A,C,D}
- injects a merge event in each of channels A,B,C,D representing these four views
- checks that all channels have the final view of size 4

The test fails intermittently on RHEL, with the same failure each time:

{noformat}
181595 [DEBUG] GMS: - A: installing view [A|2] [A]
   [testng] 181596 [TRACE] GMS: - A: received all 1 ACKs from members for view [A|2]
   [testng] 181866 [TRACE] GMS: - view [A|3] [] is empty: will not multicast it (last view)
   [testng] 
   [testng] -------------------------------------------------------------------
   [testng] GMS: address=A, cluster=OverlappingMergeTest, physical address=10.16.94.42:27199
   [testng] -------------------------------------------------------------------
   [testng] 184954 [TRACE] GMS: - A: no initial members discovered: creating group as first member
   [testng] 184954 [DEBUG] GMS: - A: installing view [A|0] [A]
   [testng] 184955 [DEBUG] GMS: - created group (first member). My view is [A|0], impl is org.jgroups.protocols.pbcast.CoordGmsImpl
   [testng] 
   [testng] -------------------------------------------------------------------
   [testng] GMS: address=B, cluster=OverlappingMergeTest, physical address=10.16.94.42:27200
   [testng] -------------------------------------------------------------------
   [testng] 184961 [TRACE] GMS: - B: initial_mbrs are A 
   [testng] 184961 [DEBUG] GMS: - election results: {A=1}
   [testng] 184961 [DEBUG] GMS: - sending JOIN(B) to A
   [testng] 185013 [TRACE] GMS: - A: new members=[B], suspected=[], leaving=[], new view: [A|1] [A, B]
   [testng] 185014 [TRACE] GMS: - A: mcasting view [A|1] [A, B] (2 mbrs)
   [testng] 
   [testng] 185025 [DEBUG] GMS: - A: installing view [A|1] [A, B]
   [testng] 185026 [TRACE] GMS: - A: received all 1 ACKs from members for view [A|1]
   [testng] 185055 [TRACE] GMS: - B: JOIN-RSP=[A|1] [A, B] [size=2]
   [testng] 
   [testng] 
   [testng] 185055 [DEBUG] GMS: - B: installing view [A|1] [A, B]
   [testng] 185057 [TRACE] GMS: - A: received all ACKs (1) from joiners for view [A|1]
   [testng] 
   [testng] -------------------------------------------------------------------
   [testng] GMS: address=C, cluster=OverlappingMergeTest, physical address=10.16.94.42:27201
   [testng] -------------------------------------------------------------------
   [testng] 185064 [TRACE] GMS: - C: initial_mbrs are B A 
   [testng] 185064 [DEBUG] GMS: - election results: {A=2}
   [testng] 185064 [DEBUG] GMS: - sending JOIN(C) to A
   [testng] 185108 [TRACE] GMS: - A: new members=[C], suspected=[], leaving=[], new view: [A|2] [A, B, C]
   [testng] 185108 [TRACE] GMS: - A: mcasting view [A|2] [A, B, C] (3 mbrs)
   [testng] 
   [testng] 185117 [DEBUG] GMS: - A: installing view [A|2] [A, B, C]
   [testng] 185118 [DEBUG] GMS: - B: installing view [A|2] [A, B, C]
   [testng] 185119 [TRACE] GMS: - A: received all 2 ACKs from members for view [A|2]
   [testng] 185148 [TRACE] GMS: - C: JOIN-RSP=[A|2] [A, B, C] [size=3]
   [testng] 
   [testng] 
   [testng] 185149 [DEBUG] GMS: - C: installing view [A|2] [A, B, C]
   [testng] 185151 [TRACE] GMS: - A: received all ACKs (1) from joiners for view [A|2]
   [testng] 
   [testng] -------------------------------------------------------------------
   [testng] GMS: address=D, cluster=OverlappingMergeTest, physical address=10.16.94.42:27202
   [testng] -------------------------------------------------------------------
   [testng] 185164 [TRACE] GMS: - D: initial_mbrs are B C A 
   [testng] 185164 [DEBUG] GMS: - election results: {A=3}
   [testng] 185164 [DEBUG] GMS: - sending JOIN(D) to A
   [testng] 185203 [TRACE] GMS: - A: new members=[D], suspected=[], leaving=[], new view: [A|3] [A, B, C, D]
   [testng] 185203 [TRACE] GMS: - A: mcasting view [A|3] [A, B, C, D] (4 mbrs)
   [testng] 
   [testng] 185210 [DEBUG] GMS: - A: installing view [A|3] [A, B, C, D]
   [testng] 185211 [DEBUG] GMS: - B: installing view [A|3] [A, B, C, D]
   [testng] 185211 [DEBUG] GMS: - C: installing view [A|3] [A, B, C, D]
   [testng] 185213 [TRACE] GMS: - A: received all 3 ACKs from members for view [A|3]
   [testng] 185242 [TRACE] GMS: - D: JOIN-RSP=[A|3] [A, B, C, D] [size=4]
   [testng] 
   [testng] 
   [testng] 185242 [DEBUG] GMS: - D: installing view [A|3] [A, B, C, D]
   [testng] 185242 [TRACE] GMS: - A: received all ACKs (1) from joiners for view [A|3]
   [testng] 
   [testng]  ==== Injecting view [A|4] [A, C, B] into A, B and C ====
   [testng] 185243 [DEBUG] GMS: - A: installing view [A|4] [A, C, B]
   [testng] 185243 [DEBUG] GMS: - B: installing view [A|4] [A, C, B]
   [testng] 185244 [DEBUG] GMS: - C: installing view [A|4] [A, C, B]
   [testng] 
   [testng]  ==== Injecting view [B|4] [B, A, C, D] into D ====
   [testng] 
   [testng] 185245 [DEBUG] GMS: - D: installing view [B|4] [B, A, C, D]
   [testng] A: [A|4] [A, C, B]
   [testng] B: [A|4] [A, C, B]
   [testng] C: [A|4] [A, C, B]
   [testng] D: [B|4] [B, A, C, D]
   [testng] 
   [testng] ==== Injecting a merge event into A, B, C and D====
   [testng] 185251 [TRACE] GMS: - A: got merge response from A, merge_id=A::3, merge data is sender=A, view=[A|4] [A, C, B], digest=C: [0 (0)], B: [0 (0)], A: [4 (4)]
   [testng] 185253 [TRACE] GMS: - B: queue is suspended; request MERGE(4 views) is discarded
   [testng] 185255 [TRACE] GMS: - C: queue is suspended; request MERGE(4 views) is discarded
   [testng] 185255 [TRACE] GMS: - A: got merge response from B, merge_id=A::3, merge data is sender=B, view=[A|4] [A, C, B], digest=C: [0 (0)], B: [0 (1)], A: [4 (4)]
   [testng] 190286 [TRACE] GMS: - A: mcasting view MergeView::[A|5] [A, B, C], subgroups=[A|4] [A, C, B], [A|4] [A, C, B] (3 mbrs)
   [testng] 
   [testng] 190286 [TRACE] GMS: - B: mcasting view MergeView::[A|5] [A, B, C], subgroups=[A|4] [A, C, B], [A|4] [A, C, B] (3 mbrs)
   [testng] 
   [testng] 190317 [DEBUG] GMS: - A: installing view MergeView::[A|5] [A, B, C], subgroups=[A|4] [A, C, B], [A|4] [A, C, B]
   [testng] 190318 [DEBUG] GMS: - B: installing view MergeView::[A|5] [A, B, C], subgroups=[A|4] [A, C, B], [A|4] [A, C, B]
   [testng] 190318 [DEBUG] GMS: - C: installing view MergeView::[A|5] [A, B, C], subgroups=[A|4] [A, C, B], [A|4] [A, C, B]
   [testng] 190320 [TRACE] GMS: - A: received all 3 ACKs from members for view [A|5]
   [testng] 190320 [TRACE] GMS: - B: received all 3 ACKs from members for view [A|5]
   [testng] A: [A|5] [A, B, C] (coord=true)
   [testng] B: [A|5] [A, B, C] (coord=false)
   [testng] C: [A|5] [A, B, C] (coord=false)
   [testng] D: [B|4] [B, A, C, D] (coord=false)
   [testng] 195277 [DEBUG] GMS: - D: sending LEAVE request to B
   [testng] FAIL: [1] org.jgroups.tests.OverlappingMergeTest.testMergeWithDifferentPartitions()
{noformat}

 Whenever this test fails, I see that the queues are suspended.


    
> OverlappingMergeTest testMergeWithDifferentPartitions fails to create correct merged view
> -----------------------------------------------------------------------------------------
>
>                 Key: JGRP-1805
>                 URL: https://issues.jboss.org/browse/JGRP-1805
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.2.13
>         Environment: RHEL
>            Reporter: Richard Achmatowicz
>            Assignee: Bela Ban
>             Fix For: 3.2.13
>
>
> This test does the following:
> - creates four channels a,b,c,d
> - injects views A: {A,C,B}, B:{A,C,B}, C:{A,C,B} and D: {B,A,C,D}
> - injects a merge event in each of channels A,B,C,D representing these four views
> - checks that all channels have the final view of size 4
> The test fails intermittently on RHEL, with the same failure each time:
> {noformat}
> 181595 [DEBUG] GMS: - A: installing view [A|2] [A]
>    [testng] 181596 [TRACE] GMS: - A: received all 1 ACKs from members for view [A|2]
>    [testng] 181866 [TRACE] GMS: - view [A|3] [] is empty: will not multicast it (last view)
>    [testng] 
>    [testng] -------------------------------------------------------------------
>    [testng] GMS: address=A, cluster=OverlappingMergeTest, physical address=10.16.94.42:27199
>    [testng] -------------------------------------------------------------------
>    [testng] 184954 [TRACE] GMS: - A: no initial members discovered: creating group as first member
>    [testng] 184954 [DEBUG] GMS: - A: installing view [A|0] [A]
>    [testng] 184955 [DEBUG] GMS: - created group (first member). My view is [A|0], impl is org.jgroups.protocols.pbcast.CoordGmsImpl
>    [testng] 
>    [testng] -------------------------------------------------------------------
>    [testng] GMS: address=B, cluster=OverlappingMergeTest, physical address=10.16.94.42:27200
>    [testng] -------------------------------------------------------------------
>    [testng] 184961 [TRACE] GMS: - B: initial_mbrs are A 
>    [testng] 184961 [DEBUG] GMS: - election results: {A=1}
>    [testng] 184961 [DEBUG] GMS: - sending JOIN(B) to A
>    [testng] 185013 [TRACE] GMS: - A: new members=[B], suspected=[], leaving=[], new view: [A|1] [A, B]
>    [testng] 185014 [TRACE] GMS: - A: mcasting view [A|1] [A, B] (2 mbrs)
>    [testng] 
>    [testng] 185025 [DEBUG] GMS: - A: installing view [A|1] [A, B]
>    [testng] 185026 [TRACE] GMS: - A: received all 1 ACKs from members for view [A|1]
>    [testng] 185055 [TRACE] GMS: - B: JOIN-RSP=[A|1] [A, B] [size=2]
>    [testng] 
>    [testng] 
>    [testng] 185055 [DEBUG] GMS: - B: installing view [A|1] [A, B]
>    [testng] 185057 [TRACE] GMS: - A: received all ACKs (1) from joiners for view [A|1]
>    [testng] 
>    [testng] -------------------------------------------------------------------
>    [testng] GMS: address=C, cluster=OverlappingMergeTest, physical address=10.16.94.42:27201
>    [testng] -------------------------------------------------------------------
>    [testng] 185064 [TRACE] GMS: - C: initial_mbrs are B A 
>    [testng] 185064 [DEBUG] GMS: - election results: {A=2}
>    [testng] 185064 [DEBUG] GMS: - sending JOIN(C) to A
>    [testng] 185108 [TRACE] GMS: - A: new members=[C], suspected=[], leaving=[], new view: [A|2] [A, B, C]
>    [testng] 185108 [TRACE] GMS: - A: mcasting view [A|2] [A, B, C] (3 mbrs)
>    [testng] 
>    [testng] 185117 [DEBUG] GMS: - A: installing view [A|2] [A, B, C]
>    [testng] 185118 [DEBUG] GMS: - B: installing view [A|2] [A, B, C]
>    [testng] 185119 [TRACE] GMS: - A: received all 2 ACKs from members for view [A|2]
>    [testng] 185148 [TRACE] GMS: - C: JOIN-RSP=[A|2] [A, B, C] [size=3]
>    [testng] 
>    [testng] 
>    [testng] 185149 [DEBUG] GMS: - C: installing view [A|2] [A, B, C]
>    [testng] 185151 [TRACE] GMS: - A: received all ACKs (1) from joiners for view [A|2]
>    [testng] 
>    [testng] -------------------------------------------------------------------
>    [testng] GMS: address=D, cluster=OverlappingMergeTest, physical address=10.16.94.42:27202
>    [testng] -------------------------------------------------------------------
>    [testng] 185164 [TRACE] GMS: - D: initial_mbrs are B C A 
>    [testng] 185164 [DEBUG] GMS: - election results: {A=3}
>    [testng] 185164 [DEBUG] GMS: - sending JOIN(D) to A
>    [testng] 185203 [TRACE] GMS: - A: new members=[D], suspected=[], leaving=[], new view: [A|3] [A, B, C, D]
>    [testng] 185203 [TRACE] GMS: - A: mcasting view [A|3] [A, B, C, D] (4 mbrs)
>    [testng] 
>    [testng] 185210 [DEBUG] GMS: - A: installing view [A|3] [A, B, C, D]
>    [testng] 185211 [DEBUG] GMS: - B: installing view [A|3] [A, B, C, D]
>    [testng] 185211 [DEBUG] GMS: - C: installing view [A|3] [A, B, C, D]
>    [testng] 185213 [TRACE] GMS: - A: received all 3 ACKs from members for view [A|3]
>    [testng] 185242 [TRACE] GMS: - D: JOIN-RSP=[A|3] [A, B, C, D] [size=4]
>    [testng] 
>    [testng] 
>    [testng] 185242 [DEBUG] GMS: - D: installing view [A|3] [A, B, C, D]
>    [testng] 185242 [TRACE] GMS: - A: received all ACKs (1) from joiners for view [A|3]
>    [testng] 
>    [testng]  ==== Injecting view [A|4] [A, C, B] into A, B and C ====
>    [testng] 185243 [DEBUG] GMS: - A: installing view [A|4] [A, C, B]
>    [testng] 185243 [DEBUG] GMS: - B: installing view [A|4] [A, C, B]
>    [testng] 185244 [DEBUG] GMS: - C: installing view [A|4] [A, C, B]
>    [testng] 
>    [testng]  ==== Injecting view [B|4] [B, A, C, D] into D ====
>    [testng] 
>    [testng] 185245 [DEBUG] GMS: - D: installing view [B|4] [B, A, C, D]
>    [testng] A: [A|4] [A, C, B]
>    [testng] B: [A|4] [A, C, B]
>    [testng] C: [A|4] [A, C, B]
>    [testng] D: [B|4] [B, A, C, D]
>    [testng] 
>    [testng] ==== Injecting a merge event into A, B, C and D====
>    [testng] 185251 [TRACE] GMS: - A: got merge response from A, merge_id=A::3, merge data is sender=A, view=[A|4] [A, C, B], digest=C: [0 (0)], B: [0 (0)], A: [4 (4)]
>    [testng] 185253 [TRACE] GMS: - B: queue is suspended; request MERGE(4 views) is discarded
>    [testng] 185255 [TRACE] GMS: - C: queue is suspended; request MERGE(4 views) is discarded
>    [testng] 185255 [TRACE] GMS: - A: got merge response from B, merge_id=A::3, merge data is sender=B, view=[A|4] [A, C, B], digest=C: [0 (0)], B: [0 (1)], A: [4 (4)]
>    [testng] 190286 [TRACE] GMS: - A: mcasting view MergeView::[A|5] [A, B, C], subgroups=[A|4] [A, C, B], [A|4] [A, C, B] (3 mbrs)
>    [testng] 
>    [testng] 190286 [TRACE] GMS: - B: mcasting view MergeView::[A|5] [A, B, C], subgroups=[A|4] [A, C, B], [A|4] [A, C, B] (3 mbrs)
>    [testng] 
>    [testng] 190317 [DEBUG] GMS: - A: installing view MergeView::[A|5] [A, B, C], subgroups=[A|4] [A, C, B], [A|4] [A, C, B]
>    [testng] 190318 [DEBUG] GMS: - B: installing view MergeView::[A|5] [A, B, C], subgroups=[A|4] [A, C, B], [A|4] [A, C, B]
>    [testng] 190318 [DEBUG] GMS: - C: installing view MergeView::[A|5] [A, B, C], subgroups=[A|4] [A, C, B], [A|4] [A, C, B]
>    [testng] 190320 [TRACE] GMS: - A: received all 3 ACKs from members for view [A|5]
>    [testng] 190320 [TRACE] GMS: - B: received all 3 ACKs from members for view [A|5]
>    [testng] A: [A|5] [A, B, C] (coord=true)
>    [testng] B: [A|5] [A, B, C] (coord=false)
>    [testng] C: [A|5] [A, B, C] (coord=false)
>    [testng] D: [B|4] [B, A, C, D] (coord=false)
>    [testng] 195277 [DEBUG] GMS: - D: sending LEAVE request to B
>    [testng] FAIL: [1] org.jgroups.tests.OverlappingMergeTest.testMergeWithDifferentPartitions()
> {noformat}
>  Whenever this test fails, I see that the queues are suspended on the initial merge attempt.

--
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

From issues at jboss.org  Tue Mar  4 15:17:33 2014
From: issues at jboss.org (Davide Sottara (JIRA))
Date: Tue, 4 Mar 2014 15:17:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-447) Deadlock when marshalling
 session using WM listeners and fireUntilHalt
In-Reply-To: <JIRA.12534037.1393964199787@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534037.1393964199787@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534037.1393964199787.2888.1393964253848@jira02.app.mwc.hst.phx2.redhat.com>

Davide Sottara created DROOLS-447:
-------------------------------------

             Summary: Deadlock when marshalling session using WM listeners and fireUntilHalt
                 Key: DROOLS-447
                 URL: https://issues.jboss.org/browse/DROOLS-447
             Project: Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions: 6.0.1.Final, 6.1.0.Beta1
            Reporter: Davide Sottara
            Assignee: Edson Tirelli
             Fix For: 6.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

From issues at jboss.org  Tue Mar  4 17:05:34 2014
From: issues at jboss.org (James Perkins (JIRA))
Date: Tue, 4 Mar 2014 17:05:34 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3066) Logging elements should have
 a default value in the schema
In-Reply-To: <JIRA.12534049.1393970688528@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534049.1393970688528@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534049.1393970688528.3129.1393970734371@jira02.app.mwc.hst.phx2.redhat.com>

James Perkins created WFLY-3066:
-----------------------------------

             Summary: Logging elements should have a default value in the schema
                 Key: WFLY-3066
                 URL: https://issues.jboss.org/browse/WFLY-3066
             Project: WildFly
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Logging
            Reporter: James Perkins
            Assignee: James Perkins
            Priority: Minor


The elements {{add-logging-api-dependencies}} and {{use-deployment-logging-config}} should have a default of {{true}} in the schema.

--
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

From issues at jboss.org  Tue Mar  4 20:07:33 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 4 Mar 2014 20:07:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-444) NOT conditional element is
 broken when used with subnetworks
In-Reply-To: <JIRA.12533569.1393544376000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12533569.1393544376000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12533569.1393544376000.3311.1393981653718@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/DROOLS-444?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12950010#comment-12950010 ] 

RH Bugzilla Integration commented on DROOLS-444:
------------------------------------------------

Ryan Zhang <rzhang at redhat.com> changed the Status of [bug 1072462|https://bugzilla.redhat.com/show_bug.cgi?id=1072462] from MODIFIED to ON_QA
                
> NOT conditional element is broken when used with subnetworks
> ------------------------------------------------------------
>
>                 Key: DROOLS-444
>                 URL: https://issues.jboss.org/browse/DROOLS-444
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 6.0.0.Final, 6.0.1.Final
>            Reporter: Davide Sottara
>            Assignee: Mario Fusco
>            Priority: Critical
>


--
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

From issues at jboss.org  Tue Mar  4 21:41:33 2014
From: issues at jboss.org (Kyle Lape (JIRA))
Date: Tue, 4 Mar 2014 21:41:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3067) Annotations from .ear/lib are
 not visible to DUPs when processing subdeployments
In-Reply-To: <JIRA.12534077.1393987223030@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534077.1393987223030@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534077.1393987223030.3412.1393987293673@jira02.app.mwc.hst.phx2.redhat.com>

Kyle Lape created WFLY-3067:
-------------------------------

             Summary: Annotations from .ear/lib are not visible to DUPs when processing subdeployments
                 Key: WFLY-3067
                 URL: https://issues.jboss.org/browse/WFLY-3067
             Project: WildFly
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Class Loading
    Affects Versions: 8.0.0.Final
            Reporter: Kyle Lape
            Assignee: David Lloyd


Sample use case:  You have a .war in an .ear, and the .war has a web.xml with a {{<servlet-class>}} that refers to a JAX-WS endpoint, so the class is annotated with {{@WebService}}.  If that class is packaged in a jar found in the ear's lib directory, the JBossWS DUP won't pick it up, and then Undertow will throw an error like this:

{noformat}
UT010009: Servlet ClientEndpoint of type class com.redhat.gss.jaxws.ClientEndpoint does not implement javax.servlet.Servlet
{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

From issues at jboss.org  Wed Mar  5 01:17:33 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 5 Mar 2014 01:17:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2920) StackOverflowError when
 org.jboss.as.jacorb.rmi.InterfaceAnalysis is analyzing javax.ejb.EJBObject
In-Reply-To: <JIRA.12532007.1392269121000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12532007.1392269121000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12532007.1392269121000.3578.1394000253829@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2920?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated WFLY-2920:
------------------------------------------

    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1064644, https://bugzilla.redhat.com/show_bug.cgi?id=1065196, https://bugzilla.redhat.com/show_bug.cgi?id=1072747  (was: https://bugzilla.redhat.com/show_bug.cgi?id=1064644, https://bugzilla.redhat.com/show_bug.cgi?id=1065196)

    
> StackOverflowError when org.jboss.as.jacorb.rmi.InterfaceAnalysis is analyzing javax.ejb.EJBObject
> --------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2920
>                 URL: https://issues.jboss.org/browse/WFLY-2920
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: IIOP
>    Affects Versions: 8.0.0.Final
>            Reporter: Osamu Nagano
>            Assignee: Stefan Guilhen
>         Attachments: td.dump
>
>
> Depending on when a thread context switch happens, an IIOP enabled EJB fails to be deployed by throwing {{java.lang.StackOverflowError}}.  Here is the stack trace from the attached thread dump.
> {code}
> "MSC service thread 1-7" prio=10 tid=0x00007f52e8001800 nid=0x4d12 at breakpoint[0x00007f534093f000]
>    java.lang.Thread.State: RUNNABLE
>         at org.jboss.as.jacorb.rmi.WorkCacheManager.getAnalysis(WorkCacheManager.java:105)
>         at org.jboss.as.jacorb.rmi.InterfaceAnalysis.getInterfaceAnalysis(InterfaceAnalysis.java:53)
>         at org.jboss.as.jacorb.rmi.Util.getTypeIDLName(Util.java:104)
>         at org.jboss.as.jacorb.rmi.ParameterAnalysis.<init>(ParameterAnalysis.java:50)
>         at org.jboss.as.jacorb.rmi.OperationAnalysis.<init>(OperationAnalysis.java:91)
>         at org.jboss.as.jacorb.rmi.InterfaceAnalysis.analyzeOperations(InterfaceAnalysis.java:116)
>         at org.jboss.as.jacorb.rmi.ContainerAnalysis.doAnalyze(ContainerAnalysis.java:186)
>         at org.jboss.as.jacorb.rmi.InterfaceAnalysis.doAnalyze(InterfaceAnalysis.java:62)
>         at sun.reflect.GeneratedMethodAccessor3.invoke(Unknown Source)
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>         at java.lang.reflect.Method.invoke(Method.java:606)
>         at org.jboss.as.jacorb.rmi.WorkCacheManager.doTheWork(WorkCacheManager.java:177)
>         at org.jboss.as.jacorb.rmi.WorkCacheManager.getAnalysis(WorkCacheManager.java:105)
>         at org.jboss.as.jacorb.rmi.InterfaceAnalysis.getInterfaceAnalysis(InterfaceAnalysis.java:53)
>         at org.jboss.as.jacorb.rmi.Util.getTypeIDLName(Util.java:104)
>         at org.jboss.as.jacorb.rmi.ParameterAnalysis.<init>(ParameterAnalysis.java:50)
>         at org.jboss.as.jacorb.rmi.OperationAnalysis.<init>(OperationAnalysis.java:91)
>         at org.jboss.as.jacorb.rmi.InterfaceAnalysis.analyzeOperations(InterfaceAnalysis.java:116)
>         at org.jboss.as.jacorb.rmi.ContainerAnalysis.doAnalyze(ContainerAnalysis.java:186)
>         at org.jboss.as.jacorb.rmi.InterfaceAnalysis.doAnalyze(InterfaceAnalysis.java:62)
>         at sun.reflect.GeneratedMethodAccessor3.invoke(Unknown Source)
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>         at java.lang.reflect.Method.invoke(Method.java:606)
>         ...
>         at org.jboss.as.jacorb.rmi.WorkCacheManager.doTheWork(WorkCacheManager.java:177)
>         at org.jboss.as.jacorb.rmi.WorkCacheManager.getAnalysis(WorkCacheManager.java:105)
>         at org.jboss.as.jacorb.rmi.InterfaceAnalysis.getInterfaceAnalysis(InterfaceAnalysis.java:53)
>         at org.jboss.as.jacorb.rmi.Util.getTypeIDLName(Util.java:104)
>         at org.jboss.as.jacorb.rmi.ParameterAnalysis.<init>(ParameterAnalysis.java:50)
>    Locked ownable synchronizers:
>         - <0x00000000f9698790> (a java.util.concurrent.ThreadPoolExecutor$Worker)
> {code}
> The last part including {{Util.getTypeIDLName}} has been repeated as many as possible and the bottom of the stack has been lost.  The same stack has been appeared in a different MSC service thread which is also executing an IIOP enabled EJB deployment.
> The customer identified an improper synchronization in {{org.jboss.as.jacorb.rmi.WorkCacheManager#getAnalysis()}}.  It is reproducible by manually controlling a thread context switch using a debugger.

--
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

From issues at jboss.org  Wed Mar  5 01:25:33 2014
From: issues at jboss.org (Bela Ban (JIRA))
Date: Wed, 5 Mar 2014 01:25:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1805) OverlappingMergeTest
 testMergeWithDifferentPartitions fails to create correct merged view
In-Reply-To: <JIRA.12534032.1393962618000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534032.1393962618000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534032.1393962618000.3583.1394000733454@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JGRP-1805?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban updated JGRP-1805:
---------------------------

    Fix Version/s: 3.5

    
> OverlappingMergeTest testMergeWithDifferentPartitions fails to create correct merged view
> -----------------------------------------------------------------------------------------
>
>                 Key: JGRP-1805
>                 URL: https://issues.jboss.org/browse/JGRP-1805
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.2.13
>         Environment: RHEL
>            Reporter: Richard Achmatowicz
>            Assignee: Bela Ban
>             Fix For: 3.2.13, 3.5
>
>
> This test does the following:
> - creates four channels a,b,c,d
> - injects views A: {A,C,B}, B:{A,C,B}, C:{A,C,B} and D: {B,A,C,D}
> - injects a merge event in each of channels A,B,C,D representing these four views
> - checks that all channels have the final view of size 4
> The test fails intermittently on RHEL, with the same failure each time:
> {noformat}
> 181595 [DEBUG] GMS: - A: installing view [A|2] [A]
>    [testng] 181596 [TRACE] GMS: - A: received all 1 ACKs from members for view [A|2]
>    [testng] 181866 [TRACE] GMS: - view [A|3] [] is empty: will not multicast it (last view)
>    [testng] 
>    [testng] -------------------------------------------------------------------
>    [testng] GMS: address=A, cluster=OverlappingMergeTest, physical address=10.16.94.42:27199
>    [testng] -------------------------------------------------------------------
>    [testng] 184954 [TRACE] GMS: - A: no initial members discovered: creating group as first member
>    [testng] 184954 [DEBUG] GMS: - A: installing view [A|0] [A]
>    [testng] 184955 [DEBUG] GMS: - created group (first member). My view is [A|0], impl is org.jgroups.protocols.pbcast.CoordGmsImpl
>    [testng] 
>    [testng] -------------------------------------------------------------------
>    [testng] GMS: address=B, cluster=OverlappingMergeTest, physical address=10.16.94.42:27200
>    [testng] -------------------------------------------------------------------
>    [testng] 184961 [TRACE] GMS: - B: initial_mbrs are A 
>    [testng] 184961 [DEBUG] GMS: - election results: {A=1}
>    [testng] 184961 [DEBUG] GMS: - sending JOIN(B) to A
>    [testng] 185013 [TRACE] GMS: - A: new members=[B], suspected=[], leaving=[], new view: [A|1] [A, B]
>    [testng] 185014 [TRACE] GMS: - A: mcasting view [A|1] [A, B] (2 mbrs)
>    [testng] 
>    [testng] 185025 [DEBUG] GMS: - A: installing view [A|1] [A, B]
>    [testng] 185026 [TRACE] GMS: - A: received all 1 ACKs from members for view [A|1]
>    [testng] 185055 [TRACE] GMS: - B: JOIN-RSP=[A|1] [A, B] [size=2]
>    [testng] 
>    [testng] 
>    [testng] 185055 [DEBUG] GMS: - B: installing view [A|1] [A, B]
>    [testng] 185057 [TRACE] GMS: - A: received all ACKs (1) from joiners for view [A|1]
>    [testng] 
>    [testng] -------------------------------------------------------------------
>    [testng] GMS: address=C, cluster=OverlappingMergeTest, physical address=10.16.94.42:27201
>    [testng] -------------------------------------------------------------------
>    [testng] 185064 [TRACE] GMS: - C: initial_mbrs are B A 
>    [testng] 185064 [DEBUG] GMS: - election results: {A=2}
>    [testng] 185064 [DEBUG] GMS: - sending JOIN(C) to A
>    [testng] 185108 [TRACE] GMS: - A: new members=[C], suspected=[], leaving=[], new view: [A|2] [A, B, C]
>    [testng] 185108 [TRACE] GMS: - A: mcasting view [A|2] [A, B, C] (3 mbrs)
>    [testng] 
>    [testng] 185117 [DEBUG] GMS: - A: installing view [A|2] [A, B, C]
>    [testng] 185118 [DEBUG] GMS: - B: installing view [A|2] [A, B, C]
>    [testng] 185119 [TRACE] GMS: - A: received all 2 ACKs from members for view [A|2]
>    [testng] 185148 [TRACE] GMS: - C: JOIN-RSP=[A|2] [A, B, C] [size=3]
>    [testng] 
>    [testng] 
>    [testng] 185149 [DEBUG] GMS: - C: installing view [A|2] [A, B, C]
>    [testng] 185151 [TRACE] GMS: - A: received all ACKs (1) from joiners for view [A|2]
>    [testng] 
>    [testng] -------------------------------------------------------------------
>    [testng] GMS: address=D, cluster=OverlappingMergeTest, physical address=10.16.94.42:27202
>    [testng] -------------------------------------------------------------------
>    [testng] 185164 [TRACE] GMS: - D: initial_mbrs are B C A 
>    [testng] 185164 [DEBUG] GMS: - election results: {A=3}
>    [testng] 185164 [DEBUG] GMS: - sending JOIN(D) to A
>    [testng] 185203 [TRACE] GMS: - A: new members=[D], suspected=[], leaving=[], new view: [A|3] [A, B, C, D]
>    [testng] 185203 [TRACE] GMS: - A: mcasting view [A|3] [A, B, C, D] (4 mbrs)
>    [testng] 
>    [testng] 185210 [DEBUG] GMS: - A: installing view [A|3] [A, B, C, D]
>    [testng] 185211 [DEBUG] GMS: - B: installing view [A|3] [A, B, C, D]
>    [testng] 185211 [DEBUG] GMS: - C: installing view [A|3] [A, B, C, D]
>    [testng] 185213 [TRACE] GMS: - A: received all 3 ACKs from members for view [A|3]
>    [testng] 185242 [TRACE] GMS: - D: JOIN-RSP=[A|3] [A, B, C, D] [size=4]
>    [testng] 
>    [testng] 
>    [testng] 185242 [DEBUG] GMS: - D: installing view [A|3] [A, B, C, D]
>    [testng] 185242 [TRACE] GMS: - A: received all ACKs (1) from joiners for view [A|3]
>    [testng] 
>    [testng]  ==== Injecting view [A|4] [A, C, B] into A, B and C ====
>    [testng] 185243 [DEBUG] GMS: - A: installing view [A|4] [A, C, B]
>    [testng] 185243 [DEBUG] GMS: - B: installing view [A|4] [A, C, B]
>    [testng] 185244 [DEBUG] GMS: - C: installing view [A|4] [A, C, B]
>    [testng] 
>    [testng]  ==== Injecting view [B|4] [B, A, C, D] into D ====
>    [testng] 
>    [testng] 185245 [DEBUG] GMS: - D: installing view [B|4] [B, A, C, D]
>    [testng] A: [A|4] [A, C, B]
>    [testng] B: [A|4] [A, C, B]
>    [testng] C: [A|4] [A, C, B]
>    [testng] D: [B|4] [B, A, C, D]
>    [testng] 
>    [testng] ==== Injecting a merge event into A, B, C and D====
>    [testng] 185251 [TRACE] GMS: - A: got merge response from A, merge_id=A::3, merge data is sender=A, view=[A|4] [A, C, B], digest=C: [0 (0)], B: [0 (0)], A: [4 (4)]
>    [testng] 185253 [TRACE] GMS: - B: queue is suspended; request MERGE(4 views) is discarded
>    [testng] 185255 [TRACE] GMS: - C: queue is suspended; request MERGE(4 views) is discarded
>    [testng] 185255 [TRACE] GMS: - A: got merge response from B, merge_id=A::3, merge data is sender=B, view=[A|4] [A, C, B], digest=C: [0 (0)], B: [0 (1)], A: [4 (4)]
>    [testng] 190286 [TRACE] GMS: - A: mcasting view MergeView::[A|5] [A, B, C], subgroups=[A|4] [A, C, B], [A|4] [A, C, B] (3 mbrs)
>    [testng] 
>    [testng] 190286 [TRACE] GMS: - B: mcasting view MergeView::[A|5] [A, B, C], subgroups=[A|4] [A, C, B], [A|4] [A, C, B] (3 mbrs)
>    [testng] 
>    [testng] 190317 [DEBUG] GMS: - A: installing view MergeView::[A|5] [A, B, C], subgroups=[A|4] [A, C, B], [A|4] [A, C, B]
>    [testng] 190318 [DEBUG] GMS: - B: installing view MergeView::[A|5] [A, B, C], subgroups=[A|4] [A, C, B], [A|4] [A, C, B]
>    [testng] 190318 [DEBUG] GMS: - C: installing view MergeView::[A|5] [A, B, C], subgroups=[A|4] [A, C, B], [A|4] [A, C, B]
>    [testng] 190320 [TRACE] GMS: - A: received all 3 ACKs from members for view [A|5]
>    [testng] 190320 [TRACE] GMS: - B: received all 3 ACKs from members for view [A|5]
>    [testng] A: [A|5] [A, B, C] (coord=true)
>    [testng] B: [A|5] [A, B, C] (coord=false)
>    [testng] C: [A|5] [A, B, C] (coord=false)
>    [testng] D: [B|4] [B, A, C, D] (coord=false)
>    [testng] 195277 [DEBUG] GMS: - D: sending LEAVE request to B
>    [testng] FAIL: [1] org.jgroups.tests.OverlappingMergeTest.testMergeWithDifferentPartitions()
> {noformat}
>  Whenever this test fails, I see that the queues are suspended on the initial merge attempt.

--
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

From issues at jboss.org  Wed Mar  5 01:41:33 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 5 Mar 2014 01:41:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2920) StackOverflowError when
 org.jboss.as.jacorb.rmi.InterfaceAnalysis is analyzing javax.ejb.EJBObject
In-Reply-To: <JIRA.12532007.1392269121000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12532007.1392269121000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12532007.1392269121000.3623.1394001693715@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2920?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12950037#comment-12950037 ] 

RH Bugzilla Integration commented on WFLY-2920:
-----------------------------------------------

Osamu Nagano <onagano at redhat.com> changed the Status of [bug 1072747|https://bugzilla.redhat.com/show_bug.cgi?id=1072747] from NEW to POST
                
> StackOverflowError when org.jboss.as.jacorb.rmi.InterfaceAnalysis is analyzing javax.ejb.EJBObject
> --------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2920
>                 URL: https://issues.jboss.org/browse/WFLY-2920
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: IIOP
>    Affects Versions: 8.0.0.Final
>            Reporter: Osamu Nagano
>            Assignee: Stefan Guilhen
>         Attachments: td.dump
>
>
> Depending on when a thread context switch happens, an IIOP enabled EJB fails to be deployed by throwing {{java.lang.StackOverflowError}}.  Here is the stack trace from the attached thread dump.
> {code}
> "MSC service thread 1-7" prio=10 tid=0x00007f52e8001800 nid=0x4d12 at breakpoint[0x00007f534093f000]
>    java.lang.Thread.State: RUNNABLE
>         at org.jboss.as.jacorb.rmi.WorkCacheManager.getAnalysis(WorkCacheManager.java:105)
>         at org.jboss.as.jacorb.rmi.InterfaceAnalysis.getInterfaceAnalysis(InterfaceAnalysis.java:53)
>         at org.jboss.as.jacorb.rmi.Util.getTypeIDLName(Util.java:104)
>         at org.jboss.as.jacorb.rmi.ParameterAnalysis.<init>(ParameterAnalysis.java:50)
>         at org.jboss.as.jacorb.rmi.OperationAnalysis.<init>(OperationAnalysis.java:91)
>         at org.jboss.as.jacorb.rmi.InterfaceAnalysis.analyzeOperations(InterfaceAnalysis.java:116)
>         at org.jboss.as.jacorb.rmi.ContainerAnalysis.doAnalyze(ContainerAnalysis.java:186)
>         at org.jboss.as.jacorb.rmi.InterfaceAnalysis.doAnalyze(InterfaceAnalysis.java:62)
>         at sun.reflect.GeneratedMethodAccessor3.invoke(Unknown Source)
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>         at java.lang.reflect.Method.invoke(Method.java:606)
>         at org.jboss.as.jacorb.rmi.WorkCacheManager.doTheWork(WorkCacheManager.java:177)
>         at org.jboss.as.jacorb.rmi.WorkCacheManager.getAnalysis(WorkCacheManager.java:105)
>         at org.jboss.as.jacorb.rmi.InterfaceAnalysis.getInterfaceAnalysis(InterfaceAnalysis.java:53)
>         at org.jboss.as.jacorb.rmi.Util.getTypeIDLName(Util.java:104)
>         at org.jboss.as.jacorb.rmi.ParameterAnalysis.<init>(ParameterAnalysis.java:50)
>         at org.jboss.as.jacorb.rmi.OperationAnalysis.<init>(OperationAnalysis.java:91)
>         at org.jboss.as.jacorb.rmi.InterfaceAnalysis.analyzeOperations(InterfaceAnalysis.java:116)
>         at org.jboss.as.jacorb.rmi.ContainerAnalysis.doAnalyze(ContainerAnalysis.java:186)
>         at org.jboss.as.jacorb.rmi.InterfaceAnalysis.doAnalyze(InterfaceAnalysis.java:62)
>         at sun.reflect.GeneratedMethodAccessor3.invoke(Unknown Source)
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>         at java.lang.reflect.Method.invoke(Method.java:606)
>         ...
>         at org.jboss.as.jacorb.rmi.WorkCacheManager.doTheWork(WorkCacheManager.java:177)
>         at org.jboss.as.jacorb.rmi.WorkCacheManager.getAnalysis(WorkCacheManager.java:105)
>         at org.jboss.as.jacorb.rmi.InterfaceAnalysis.getInterfaceAnalysis(InterfaceAnalysis.java:53)
>         at org.jboss.as.jacorb.rmi.Util.getTypeIDLName(Util.java:104)
>         at org.jboss.as.jacorb.rmi.ParameterAnalysis.<init>(ParameterAnalysis.java:50)
>    Locked ownable synchronizers:
>         - <0x00000000f9698790> (a java.util.concurrent.ThreadPoolExecutor$Worker)
> {code}
> The last part including {{Util.getTypeIDLName}} has been repeated as many as possible and the bottom of the stack has been lost.  The same stack has been appeared in a different MSC service thread which is also executing an IIOP enabled EJB deployment.
> The customer identified an improper synchronization in {{org.jboss.as.jacorb.rmi.WorkCacheManager#getAnalysis()}}.  It is reproducible by manually controlling a thread context switch using a debugger.

--
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

From issues at jboss.org  Wed Mar  5 02:43:33 2014
From: issues at jboss.org (Chris Roberts (JIRA))
Date: Wed, 5 Mar 2014 02:43:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2959) Downgrade Jackson dependency
In-Reply-To: <JIRA.12532567.1392747430000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12532567.1392747430000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12532567.1392747430000.3652.1394005413269@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2959?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12950044#comment-12950044 ] 

Chris Roberts commented on WFLY-2959:
-------------------------------------

I think the downgrade to 2.2.3 is not ideal.
jackson-datatype-hibernate4:2.2.3 (used to work around lazy init exceptions easily with Jackson) does not support hibernate 4.3 as far as I can see only hibernate4.1.
jackson-datatype-hibernate4:2.3+ does but depends on jackson 2.3.0.

Jackson 2.3.2 is supposed to have put these APIs back as deprecated, but so far I've had no success upgrading my wildfly module version of jackson-jaxrs with the new 2.3.2 modules.

Here is a link to the relevant issue on the Jackson side which is supposed to solve the issue (but doesn't seem to work for me):
https://github.com/FasterXML/jackson-jaxrs-providers/issues/41
It would seem ideal that RestEasy support Jackson 2.3+  but I'm not sure how far away that is, or the deprecated APIs on the Jackson side are working.

                
> Downgrade Jackson dependency
> ----------------------------
>
>                 Key: WFLY-2959
>                 URL: https://issues.jboss.org/browse/WFLY-2959
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: REST
>    Affects Versions: 8.0.0.Final
>            Reporter: James Perkins
>            Assignee: James Perkins
>             Fix For: 8.0.1.Final
>
>
> Jackson was upgraded to 2.3.0 which contains a [bug|https://github.com/FasterXML/jackson-jaxrs-providers/commit/bafb6fb64bc15482c7bfc56784169204d6c4b1f2#commitcomment-5224156] that breaks RESTEasy. RESTEasy currently uses 2.2.1. Downgrading to at least 2.2.3, which is what CR1 is at, seems to resolve this issue.
> We should likely keep the version aligned with RESTEasy, but since CR1 was using 2.2.3 with no issues, I think reverting back to that should be fine.

--
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

From issues at jboss.org  Wed Mar  5 02:49:33 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 5 Mar 2014 02:49:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2319) LDAP Search containing URL -
 InvalidNameException: ldap:: [LDAP: error code 34 - Invalid root Dn given
In-Reply-To: <JIRA.12503254.1381931058000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12503254.1381931058000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12503254.1381931058000.3676.1394005773538@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2319?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12950049#comment-12950049 ] 

RH Bugzilla Integration commented on WFLY-2319:
-----------------------------------------------

Ondrej Lukas <olukas at redhat.com> changed the Status of [bug 1014911|https://bugzilla.redhat.com/show_bug.cgi?id=1014911] from ON_QA to VERIFIED
                
> LDAP Search containing URL - InvalidNameException: ldap:: [LDAP: error code 34 - Invalid root Dn given
> ------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2319
>                 URL: https://issues.jboss.org/browse/WFLY-2319
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Naming
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Darran Lofthouse
>            Assignee: Eduardo Martins
>             Fix For: 8.0.0.Final
>
>         Attachments: LdapSearching.tgz
>
>
> The following code: -
> {code}
>         Hashtable env = new Hashtable();
>         env.put("java.naming.factory.initial", "com.sun.jndi.ldap.LdapCtxFactory");
>         env.put("java.naming.security.authentication", "simple");
>         env.put("java.naming.provider.url", "ldap://localhost:10389");
>         env.put(InitialDirContext.SECURITY_PRINCIPAL, "uid=admin,ou=system");
>         env.put(InitialDirContext.SECURITY_CREDENTIALS, "secret");
>         SearchControls ctl = null;
>         String attrArr[] = new String[1];
>         attrArr[0] = "sn";
>         ctl = new SearchControls(2, 0L, 0, attrArr, false, false);
>         String base = "ldap://localhost:10389/dc=simple,dc=wildfly,dc=org";
>         String filter = "(uid=UserOne)";
>         NamingEnumeration nenum = null;
>         DirContext ictx = null;
>             ictx = new InitialDirContext(env);
>             nenum = ictx.search(base, filter, ctl);
> {code}
> Results in the following exception: -
> {noquote}
> 13:03:45,598 ERROR [stderr] (default task-1) javax.naming.InvalidNameException: ldap:: [LDAP: error code 34 - Invalid root Dn given : ldap: (0x6C 0x64 0x61 0x70 0x3A ) is invalid]; remaining name 'ldap://localhost:10389/dc=simple,dc=wildfly,dc=org'
> 13:03:45,599 ERROR [stderr] (default task-1) 	at com.sun.jndi.ldap.LdapCtx.processReturnCode(LdapCtx.java:3025)
> 13:03:45,600 ERROR [stderr] (default task-1) 	at com.sun.jndi.ldap.LdapCtx.processReturnCode(LdapCtx.java:2840)
> 13:03:45,600 ERROR [stderr] (default task-1) 	at com.sun.jndi.ldap.LdapCtx.c_lookup(LdapCtx.java:1034)
> {noquote}
> Switching to a base that does not begin with a URL and the search works, executing this code outside of WildFly also works.
> The underlying issue is that the default InitialContext implementation contains the following method: -
> {code}
>     protected Context getURLOrDefaultInitCtx(String name)
>         throws NamingException {
>         if (NamingManager.hasInitialContextFactoryBuilder()) {
>             return getDefaultInitCtx();
>         }
>         String scheme = getURLScheme(name);
>         if (scheme != null) {
>             Context ctx = NamingManager.getURLContext(scheme, myProps);
>             if (ctx != null) {
>                 return ctx;
>             }
>         }
>         return getDefaultInitCtx();
>     }
> {code}
> As the naming subsystem has registered a InitialContextFactoryBuilder this code will never fall down to the scheme specific section.

--
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

From issues at jboss.org  Wed Mar  5 03:47:33 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 5 Mar 2014 03:47:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2319) LDAP Search containing URL -
 InvalidNameException: ldap:: [LDAP: error code 34 - Invalid root Dn given
In-Reply-To: <JIRA.12503254.1381931058000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12503254.1381931058000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12503254.1381931058000.3797.1394009253753@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2319?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12950071#comment-12950071 ] 

RH Bugzilla Integration commented on WFLY-2319:
-----------------------------------------------

Ondrej Lukas <olukas at redhat.com> changed the Status of [bug 1060275|https://bugzilla.redhat.com/show_bug.cgi?id=1060275] from ON_QA to VERIFIED
                
> LDAP Search containing URL - InvalidNameException: ldap:: [LDAP: error code 34 - Invalid root Dn given
> ------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2319
>                 URL: https://issues.jboss.org/browse/WFLY-2319
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Naming
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Darran Lofthouse
>            Assignee: Eduardo Martins
>             Fix For: 8.0.0.Final
>
>         Attachments: LdapSearching.tgz
>
>
> The following code: -
> {code}
>         Hashtable env = new Hashtable();
>         env.put("java.naming.factory.initial", "com.sun.jndi.ldap.LdapCtxFactory");
>         env.put("java.naming.security.authentication", "simple");
>         env.put("java.naming.provider.url", "ldap://localhost:10389");
>         env.put(InitialDirContext.SECURITY_PRINCIPAL, "uid=admin,ou=system");
>         env.put(InitialDirContext.SECURITY_CREDENTIALS, "secret");
>         SearchControls ctl = null;
>         String attrArr[] = new String[1];
>         attrArr[0] = "sn";
>         ctl = new SearchControls(2, 0L, 0, attrArr, false, false);
>         String base = "ldap://localhost:10389/dc=simple,dc=wildfly,dc=org";
>         String filter = "(uid=UserOne)";
>         NamingEnumeration nenum = null;
>         DirContext ictx = null;
>             ictx = new InitialDirContext(env);
>             nenum = ictx.search(base, filter, ctl);
> {code}
> Results in the following exception: -
> {noquote}
> 13:03:45,598 ERROR [stderr] (default task-1) javax.naming.InvalidNameException: ldap:: [LDAP: error code 34 - Invalid root Dn given : ldap: (0x6C 0x64 0x61 0x70 0x3A ) is invalid]; remaining name 'ldap://localhost:10389/dc=simple,dc=wildfly,dc=org'
> 13:03:45,599 ERROR [stderr] (default task-1) 	at com.sun.jndi.ldap.LdapCtx.processReturnCode(LdapCtx.java:3025)
> 13:03:45,600 ERROR [stderr] (default task-1) 	at com.sun.jndi.ldap.LdapCtx.processReturnCode(LdapCtx.java:2840)
> 13:03:45,600 ERROR [stderr] (default task-1) 	at com.sun.jndi.ldap.LdapCtx.c_lookup(LdapCtx.java:1034)
> {noquote}
> Switching to a base that does not begin with a URL and the search works, executing this code outside of WildFly also works.
> The underlying issue is that the default InitialContext implementation contains the following method: -
> {code}
>     protected Context getURLOrDefaultInitCtx(String name)
>         throws NamingException {
>         if (NamingManager.hasInitialContextFactoryBuilder()) {
>             return getDefaultInitCtx();
>         }
>         String scheme = getURLScheme(name);
>         if (scheme != null) {
>             Context ctx = NamingManager.getURLContext(scheme, myProps);
>             if (ctx != null) {
>                 return ctx;
>             }
>         }
>         return getDefaultInitCtx();
>     }
> {code}
> As the naming subsystem has registered a InitialContextFactoryBuilder this code will never fall down to the scheme specific section.

--
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

From issues at jboss.org  Wed Mar  5 03:57:33 2014
From: issues at jboss.org (dpocock (JIRA))
Date: Wed, 5 Mar 2014 03:57:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3068) could fail more gracefully
 when wrong Java version used
In-Reply-To: <JIRA.12534103.1394009736374@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534103.1394009736374@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534103.1394009736374.3836.1394009853155@jira02.app.mwc.hst.phx2.redhat.com>

dpocock created WFLY-3068:
-----------------------------

             Summary: could fail more gracefully when wrong Java version used
                 Key: WFLY-3068
                 URL: https://issues.jboss.org/browse/WFLY-3068
             Project: WildFly
          Issue Type: Bug
      Security Level: Public (Everyone can see)
            Reporter: dpocock




--
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

From issues at jboss.org  Wed Mar  5 04:01:36 2014
From: issues at jboss.org (dpocock (JIRA))
Date: Wed, 5 Mar 2014 04:01:36 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3068) could fail more gracefully
 when wrong Java version used
In-Reply-To: <JIRA.12534103.1394009736000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534103.1394009736000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534103.1394009736000.3838.1394010096147@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-3068?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

dpocock updated WFLY-3068:
--------------------------

          Description: 

If I try to start Wildfly with Java 6 (which is no longer support of course) it just fails with a stack:

09:51:00,536 INFO  [org.jboss.modules] (main) JBoss Modules version 1.3.0.Final
09:51:00,543 WARN  [org.jboss.modules] (main) Failed to define class org.jboss.as.jmx.PluggableMBeanServerBuilder in Module "org.jboss.as.jmx:main" from local module loader @36b60b93 (finder: local module finder @69b1fbf4 ()): java.lang.UnsupportedClassVersionError: org/jboss/as/jmx/PluggableMBeanServerBuilder : Unsupported major.minor version 51.0
	at java.lang.ClassLoader.defineClass1(Native Method) [rt.jar:1.6.0_26]
	at java.lang.ClassLoader.defineClassCond(ClassLoader.java:631) [rt.jar:1.6.0_26]
	at java.lang.ClassLoader.defineClass(ClassLoader.java:615) [rt.jar:1.6.0_26]
	at org.jboss.modules.ModuleClassLoader.doDefineOrLoadClass(ModuleClassLoader.java:345) [jboss-modules.jar:1.3.0.Final]
	at org.jboss.modules.ModuleClassLoader.defineClass(ModuleClassLoader.java:423) [jboss-modules.jar:1.3.0.Final]
	at org.jboss.modules.ModuleClassLoader.loadClassLocal(ModuleClassLoader.java:261) [jboss-modules.jar:1.3.0.Final]
	at org.jboss.modules.ModuleClassLoader$1.loadClassLocal(ModuleClassLoader.java:76) [jboss-modules.jar:1.3.0.Final]
	at org.jboss.modules.Module.loadModuleClass(Module.java:548) [jboss-modules.jar:1.3.0.Final]
	at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:189) [jboss-modules.jar:1.3.0.Final]
	at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:443) [jboss-modules.jar:1.3.0.Final]
	at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:431) [jboss-modules.jar:1.3.0.Final]
	at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:373) [jboss-modules.jar:1.3.0.Final]
	at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:118) [jboss-modules.jar:1.3.0.Final]
	at javax.management.MBeanServerFactory.loadBuilderClass(MBeanServerFactory.java:423) [rt.jar:1.6.0_26]
	at javax.management.MBeanServerFactory.checkMBeanServerBuilder(MBeanServerFactory.java:465) [rt.jar:1.6.0_26]
	at javax.management.MBeanServerFactory.getNewMBeanServerBuilder(MBeanServerFactory.java:511) [rt.jar:1.6.0_26]
	at javax.management.MBeanServerFactory.newMBeanServer(MBeanServerFactory.java:298) [rt.jar:1.6.0_26]
	at javax.management.MBeanServerFactory.createMBeanServer(MBeanServerFactory.java:213) [rt.jar:1.6.0_26]
	at javax.management.MBeanServerFactory.createMBeanServer(MBeanServerFactory.java:174) [rt.jar:1.6.0_26]
	at sun.management.ManagementFactory.createPlatformMBeanServer(ManagementFactory.java:302) [rt.jar:1.6.0_26]
	at java.lang.management.ManagementFactory.getPlatformMBeanServer(ManagementFactory.java:504) [rt.jar:1.6.0_26]
	at org.jboss.modules.Main.main(Main.java:449) [jboss-modules.jar:1.3.0.Final]

Exception in thread "main" java.lang.UnsupportedClassVersionError: org/jboss/as/jmx/PluggableMBeanServerBuilder : Unsupported major.minor version 51.0
	at java.lang.ClassLoader.defineClass1(Native Method)
	at java.lang.ClassLoader.defineClassCond(ClassLoader.java:631)
	at java.lang.ClassLoader.defineClass(ClassLoader.java:615)
	at org.jboss.modules.ModuleClassLoader.doDefineOrLoadClass(ModuleClassLoader.java:345)
	at org.jboss.modules.ModuleClassLoader.defineClass(ModuleClassLoader.java:423)
	at org.jboss.modules.ModuleClassLoader.loadClassLocal(ModuleClassLoader.java:261)
	at org.jboss.modules.ModuleClassLoader$1.loadClassLocal(ModuleClassLoader.java:76)
	at org.jboss.modules.Module.loadModuleClass(Module.java:548)
	at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:189)
	at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:443)
	at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:431)
	at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:373)
	at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:118)
	at javax.management.MBeanServerFactory.loadBuilderClass(MBeanServerFactory.java:423)
	at javax.management.MBeanServerFactory.checkMBeanServerBuilder(MBeanServerFactory.java:465)
	at javax.management.MBeanServerFactory.getNewMBeanServerBuilder(MBeanServerFactory.java:511)
	at javax.management.MBeanServerFactory.newMBeanServer(MBeanServerFactory.java:298)
	at javax.management.MBeanServerFactory.createMBeanServer(MBeanServerFactory.java:213)
	at javax.management.MBeanServerFactory.createMBeanServer(MBeanServerFactory.java:174)
	at sun.management.ManagementFactory.createPlatformMBeanServer(ManagementFactory.java:302)
	at java.lang.management.ManagementFactory.getPlatformMBeanServer(ManagementFactory.java:504)
	at org.jboss.modules.Main.main(Main.java:449)




It would be more friendly if it checked the Java version in the main() function and stopped gracefully.  The stack trace is not hard to understand but may not be obvious to everybody.

             Priority: Minor  (was: Major)
    Affects Version/s: 8.0.0.Final
          Environment: Java version < 7
          Component/s: Server

    
> could fail more gracefully when wrong Java version used
> -------------------------------------------------------
>
>                 Key: WFLY-3068
>                 URL: https://issues.jboss.org/browse/WFLY-3068
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Server
>    Affects Versions: 8.0.0.Final
>         Environment: Java version < 7
>            Reporter: dpocock
>            Priority: Minor
>
> If I try to start Wildfly with Java 6 (which is no longer support of course) it just fails with a stack:
> 09:51:00,536 INFO  [org.jboss.modules] (main) JBoss Modules version 1.3.0.Final
> 09:51:00,543 WARN  [org.jboss.modules] (main) Failed to define class org.jboss.as.jmx.PluggableMBeanServerBuilder in Module "org.jboss.as.jmx:main" from local module loader @36b60b93 (finder: local module finder @69b1fbf4 ()): java.lang.UnsupportedClassVersionError: org/jboss/as/jmx/PluggableMBeanServerBuilder : Unsupported major.minor version 51.0
> 	at java.lang.ClassLoader.defineClass1(Native Method) [rt.jar:1.6.0_26]
> 	at java.lang.ClassLoader.defineClassCond(ClassLoader.java:631) [rt.jar:1.6.0_26]
> 	at java.lang.ClassLoader.defineClass(ClassLoader.java:615) [rt.jar:1.6.0_26]
> 	at org.jboss.modules.ModuleClassLoader.doDefineOrLoadClass(ModuleClassLoader.java:345) [jboss-modules.jar:1.3.0.Final]
> 	at org.jboss.modules.ModuleClassLoader.defineClass(ModuleClassLoader.java:423) [jboss-modules.jar:1.3.0.Final]
> 	at org.jboss.modules.ModuleClassLoader.loadClassLocal(ModuleClassLoader.java:261) [jboss-modules.jar:1.3.0.Final]
> 	at org.jboss.modules.ModuleClassLoader$1.loadClassLocal(ModuleClassLoader.java:76) [jboss-modules.jar:1.3.0.Final]
> 	at org.jboss.modules.Module.loadModuleClass(Module.java:548) [jboss-modules.jar:1.3.0.Final]
> 	at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:189) [jboss-modules.jar:1.3.0.Final]
> 	at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:443) [jboss-modules.jar:1.3.0.Final]
> 	at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:431) [jboss-modules.jar:1.3.0.Final]
> 	at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:373) [jboss-modules.jar:1.3.0.Final]
> 	at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:118) [jboss-modules.jar:1.3.0.Final]
> 	at javax.management.MBeanServerFactory.loadBuilderClass(MBeanServerFactory.java:423) [rt.jar:1.6.0_26]
> 	at javax.management.MBeanServerFactory.checkMBeanServerBuilder(MBeanServerFactory.java:465) [rt.jar:1.6.0_26]
> 	at javax.management.MBeanServerFactory.getNewMBeanServerBuilder(MBeanServerFactory.java:511) [rt.jar:1.6.0_26]
> 	at javax.management.MBeanServerFactory.newMBeanServer(MBeanServerFactory.java:298) [rt.jar:1.6.0_26]
> 	at javax.management.MBeanServerFactory.createMBeanServer(MBeanServerFactory.java:213) [rt.jar:1.6.0_26]
> 	at javax.management.MBeanServerFactory.createMBeanServer(MBeanServerFactory.java:174) [rt.jar:1.6.0_26]
> 	at sun.management.ManagementFactory.createPlatformMBeanServer(ManagementFactory.java:302) [rt.jar:1.6.0_26]
> 	at java.lang.management.ManagementFactory.getPlatformMBeanServer(ManagementFactory.java:504) [rt.jar:1.6.0_26]
> 	at org.jboss.modules.Main.main(Main.java:449) [jboss-modules.jar:1.3.0.Final]
> Exception in thread "main" java.lang.UnsupportedClassVersionError: org/jboss/as/jmx/PluggableMBeanServerBuilder : Unsupported major.minor version 51.0
> 	at java.lang.ClassLoader.defineClass1(Native Method)
> 	at java.lang.ClassLoader.defineClassCond(ClassLoader.java:631)
> 	at java.lang.ClassLoader.defineClass(ClassLoader.java:615)
> 	at org.jboss.modules.ModuleClassLoader.doDefineOrLoadClass(ModuleClassLoader.java:345)
> 	at org.jboss.modules.ModuleClassLoader.defineClass(ModuleClassLoader.java:423)
> 	at org.jboss.modules.ModuleClassLoader.loadClassLocal(ModuleClassLoader.java:261)
> 	at org.jboss.modules.ModuleClassLoader$1.loadClassLocal(ModuleClassLoader.java:76)
> 	at org.jboss.modules.Module.loadModuleClass(Module.java:548)
> 	at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:189)
> 	at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:443)
> 	at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:431)
> 	at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:373)
> 	at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:118)
> 	at javax.management.MBeanServerFactory.loadBuilderClass(MBeanServerFactory.java:423)
> 	at javax.management.MBeanServerFactory.checkMBeanServerBuilder(MBeanServerFactory.java:465)
> 	at javax.management.MBeanServerFactory.getNewMBeanServerBuilder(MBeanServerFactory.java:511)
> 	at javax.management.MBeanServerFactory.newMBeanServer(MBeanServerFactory.java:298)
> 	at javax.management.MBeanServerFactory.createMBeanServer(MBeanServerFactory.java:213)
> 	at javax.management.MBeanServerFactory.createMBeanServer(MBeanServerFactory.java:174)
> 	at sun.management.ManagementFactory.createPlatformMBeanServer(ManagementFactory.java:302)
> 	at java.lang.management.ManagementFactory.getPlatformMBeanServer(ManagementFactory.java:504)
> 	at org.jboss.modules.Main.main(Main.java:449)
> It would be more friendly if it checked the Java version in the main() function and stopped gracefully.  The stack trace is not hard to understand but may not be obvious to everybody.

--
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

From issues at jboss.org  Wed Mar  5 05:30:33 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 5 Mar 2014 05:30:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2261) standalone.sh --debug without
 port number not working
In-Reply-To: <JIRA.12502486.1381251288000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502486.1381251288000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502486.1381251288000.4223.1394015433757@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2261?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12950120#comment-12950120 ] 

RH Bugzilla Integration commented on WFLY-2261:
-----------------------------------------------

Jeff Mesnil <jmesnil at redhat.com> changed the Status of [bug 1072227|https://bugzilla.redhat.com/show_bug.cgi?id=1072227] from NEW to POST
                
> standalone.sh --debug without port number not working 
> ------------------------------------------------------
>
>                 Key: WFLY-2261
>                 URL: https://issues.jboss.org/browse/WFLY-2261
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Scripts
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Cheng Fang
>            Assignee: Jeff Mesnil
>             Fix For: 8.0.1.Final
>
>
> ./standalone.sh --debug port-num works, but it failed when omitting port number.
> sh -x standalone.sh --debug  (expecting the default port 8787 to be used)
> {noformat}
> + eval '"/Library/Java/JavaVirtualMachines/jdk1.7.0_40.jdk/Contents/Home/bin/java"' '-D"[Standalone]"' -server -XX:+UseCompressedOops -Xms64m -Xmx512m -XX:MaxPermSize=256m -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true -agentlib:jdwp=transport=dt_socket,address=8787,server=y,suspend=n '"-Dorg.jboss.boot.log.file=/Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT/standalone/log/server.log"' '"-Dlogging.configuration=file:/Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT/standalone/configuration/logging.properties"' -jar '"/Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT/jboss-modules.jar"' -mp '"/Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT/modules"' org.jboss.as.standalone '-Djboss.home.dir="/Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT"' '-Djboss.server.base.dir="/Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT/standalone"' ' ""'
> ++ /Library/Java/JavaVirtualMachines/jdk1.7.0_40.jdk/Contents/Home/bin/java '-D[Standalone]' -server -XX:+UseCompressedOops -Xms64m -Xmx512m -XX:MaxPermSize=256m -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true -agentlib:jdwp=transport=dt_socket,address=8787,server=y,suspend=n -Dorg.jboss.boot.log.file=/Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT/standalone/log/server.log -Dlogging.configuration=file:/Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT/standalone/configuration/logging.properties -jar /Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT/jboss-modules.jar -mp /Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT/modules org.jboss.as.standalone -Djboss.home.dir=/Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT -Djboss.server.base.dir=/Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT/standalone ''
> Listening for transport dt_socket at address: 8787
> 12:19:36,715 INFO  [org.jboss.modules] (main) JBoss Modules version 1.3.0.Final
> 12:19:36,886 ERROR [stderr] (main) JBAS015801: Invalid option ''
> 12:19:36,893 INFO  [stdout] (main)
> 12:19:36,893 INFO  [stdout] (main) Usage: standalone.sh [args...]
> {noformat}
> sh -x standalone.sh --debug 8787 (the working command)
> {noformat}
> + eval '"/Library/Java/JavaVirtualMachines/jdk1.7.0_40.jdk/Contents/Home/bin/java"' '-D"[Standalone]"' -server -XX:+UseCompressedOops -Xms64m -Xmx512m -XX:MaxPermSize=256m -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true -agentlib:jdwp=transport=dt_socket,address=8787,server=y,suspend=n '"-Dorg.jboss.boot.log.file=/Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT/standalone/log/server.log"' '"-Dlogging.configuration=file:/Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT/standalone/configuration/logging.properties"' -jar '"/Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT/jboss-modules.jar"' -mp '"/Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT/modules"' org.jboss.as.standalone '-Djboss.home.dir="/Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT"' '-Djboss.server.base.dir="/Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT/standalone"' ''
> ++ /Library/Java/JavaVirtualMachines/jdk1.7.0_40.jdk/Contents/Home/bin/java '-D[Standalone]' -server -XX:+UseCompressedOops -Xms64m -Xmx512m -XX:MaxPermSize=256m -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true -agentlib:jdwp=transport=dt_socket,address=8787,server=y,suspend=n -Dorg.jboss.boot.log.file=/Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT/standalone/log/server.log -Dlogging.configuration=file:/Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT/standalone/configuration/logging.properties -jar /Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT/jboss-modules.jar -mp /Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT/modules org.jboss.as.standalone -Djboss.home.dir=/Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT -Djboss.server.base.dir=/Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT/standalone
> Listening for transport dt_socket at address: 8787
> 12:20:39,251 INFO  [org.jboss.modules] (main) JBoss Modules version 1.3.0.Final
> 12:20:39,626 INFO  [org.jboss.msc] (main) JBoss MSC version 1.2.0.Beta2
> {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


From issues at jboss.org  Wed Mar  5 06:56:33 2014
From: issues at jboss.org (Tom Fonteyne (JIRA))
Date: Wed, 5 Mar 2014 06:56:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3069) slaves cannot reconnect to a
 restarted master if RBAC is enabled
In-Reply-To: <JIRA.12534143.1394020494258@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534143.1394020494258@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534143.1394020494258.4518.1394020593701@jira02.app.mwc.hst.phx2.redhat.com>

Tom Fonteyne created WFLY-3069:
----------------------------------

             Summary: slaves cannot reconnect to a restarted master if RBAC is enabled
                 Key: WFLY-3069
                 URL: https://issues.jboss.org/browse/WFLY-3069
             Project: WildFly
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Domain Management
    Affects Versions: 8.0.0.Final
            Reporter: Tom Fonteyne
            Assignee: Brian Stansberry
            Priority: Critical


Enable RBAC in an Wilfly domain setup. "reload --host=master" and the slaves will no longer be connected to the master




--
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

From issues at jboss.org  Wed Mar  5 06:58:33 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 5 Mar 2014 06:58:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3069) slaves cannot reconnect to a
 restarted master if RBAC is enabled
In-Reply-To: <JIRA.12534143.1394020494000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534143.1394020494000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534143.1394020494000.4535.1394020713973@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-3069?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated WFLY-3069:
------------------------------------------

        Bugzilla Update: Perform
    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1072915

    
> slaves cannot reconnect to a restarted master if RBAC is enabled
> ----------------------------------------------------------------
>
>                 Key: WFLY-3069
>                 URL: https://issues.jboss.org/browse/WFLY-3069
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>    Affects Versions: 8.0.0.Final
>            Reporter: Tom Fonteyne
>            Assignee: Brian Stansberry
>            Priority: Critical
>
> Enable RBAC in an Wilfly domain setup. "reload --host=master" and the slaves will no longer be connected to the master

--
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

From issues at jboss.org  Wed Mar  5 07:29:33 2014
From: issues at jboss.org (Bela Ban (JIRA))
Date: Wed, 5 Mar 2014 07:29:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1722) Improve performance of
	ENCRYPT protocol
In-Reply-To: <JIRA.12508426.1382426974000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508426.1382426974000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508426.1382426974000.4685.1394022573363@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JGRP-1722?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12950170#comment-12950170 ] 

Bela Ban commented on JGRP-1722:
--------------------------------

When a sync RPC is invoked, the following encrypt/decrypt phases are done:
# The request is sent and *encrypted* on the way down
# The request is received and *decrypted* on the way up, either as a single message or as part of a batch
# The response is sent and *encrypted* on the way down
# The response is received and *descrypted* on the way up, either as a single message or as part of a batch

That's a total of 2 encryptions and 2 decryptions for invoking a single sync RPC. I measure the avg cost of encryption and decryption and the total of 1 encrypt/decrypt is ca. 25 us, which means an RPC uses roughly 50us for encryption and decryption. That's a theoretical total of 20'000 max RPCs / sec, but of course this doesn't take the other protocols and processing of the request at the receipient and the response at the caller into account.

*Without* encryption, I get (on the same box) ca. 16'000 RPCs/node avg, *with* encryption I get ca. 8'500. I've come to the conclusion that this is the cost of encryption that has to be paid. If we could make encryption faster, e.g. by picking smaller key sizes, perhaps this could be improved, but parallelization (see above) didn't help.

Note that the numbers for UPerf and higher on cluster01-08 (8 nodes): ca. 20'000 sync RPCs/sec with encryption and 38'000 without.
                
> Improve performance of ENCRYPT protocol
> ---------------------------------------
>
>                 Key: JGRP-1722
>                 URL: https://issues.jboss.org/browse/JGRP-1722
>             Project: JGroups
>          Issue Type: Enhancement
>    Affects Versions: 3.4
>            Reporter: Martin Gencur
>            Assignee: Bela Ban
>             Fix For: 3.5
>
>
> A stress tests with the following setup showed that performance (reads and writes/sec) is halved when ENCRYPT protocol is enabled:
> Infinispan had distributed sync cache with 2 owners on 4 nodes, no transactions. The stress test used 10 threads on each node accessing 1024 byte entries, no conflicts on keys, 20 % writes, 80 % reads. 
> It would be great if we could improve the performance of ENCRYPT protocol.

--
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

From issues at jboss.org  Wed Mar  5 07:35:33 2014
From: issues at jboss.org (Bela Ban (JIRA))
Date: Wed, 5 Mar 2014 07:35:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1722) Improve performance of
	ENCRYPT protocol
In-Reply-To: <JIRA.12508426.1382426974000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508426.1382426974000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508426.1382426974000.4703.1394022933378@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JGRP-1722?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12950170#comment-12950170 ] 

Bela Ban edited comment on JGRP-1722 at 3/5/14 7:35 AM:
--------------------------------------------------------

When a sync RPC is invoked, the following encrypt/decrypt phases are done:
# The request is sent and *encrypted* on the way down
# The request is received and *decrypted* on the way up, either as a single message or as part of a batch
# The response is sent and *encrypted* on the way down
# The response is received and *descrypted* on the way up, either as a single message or as part of a batch

That's a total of 2 encryptions and 2 decryptions for invoking a single sync RPC. I measure the avg cost of encryption and decryption and the total of 1 encrypt/decrypt is ca. 25 us, which means an RPC uses roughly 50us for encryption and decryption. That's a theoretical total of 20'000 max RPCs / sec, but of course this doesn't take the other protocols and processing of the request at the receipient and the response at the caller into account.

*Without* encryption, I get (on the same box) ca. 16'000 RPCs/node avg, *with* encryption I get ca. 8'500. I've come to the conclusion that this is the cost of encryption that has to be paid. If we could make encryption faster, e.g. by picking smaller key sizes, perhaps this could be improved, but parallelization (see above) didn't help.

Note that the numbers for UPerf and higher on cluster01-08 (8 nodes): ca. 21'000 sync RPCs/sec with encryption and 41'000 without.
                
      was (Author: belaban):
    When a sync RPC is invoked, the following encrypt/decrypt phases are done:
# The request is sent and *encrypted* on the way down
# The request is received and *decrypted* on the way up, either as a single message or as part of a batch
# The response is sent and *encrypted* on the way down
# The response is received and *descrypted* on the way up, either as a single message or as part of a batch

That's a total of 2 encryptions and 2 decryptions for invoking a single sync RPC. I measure the avg cost of encryption and decryption and the total of 1 encrypt/decrypt is ca. 25 us, which means an RPC uses roughly 50us for encryption and decryption. That's a theoretical total of 20'000 max RPCs / sec, but of course this doesn't take the other protocols and processing of the request at the receipient and the response at the caller into account.

*Without* encryption, I get (on the same box) ca. 16'000 RPCs/node avg, *with* encryption I get ca. 8'500. I've come to the conclusion that this is the cost of encryption that has to be paid. If we could make encryption faster, e.g. by picking smaller key sizes, perhaps this could be improved, but parallelization (see above) didn't help.

Note that the numbers for UPerf and higher on cluster01-08 (8 nodes): ca. 20'000 sync RPCs/sec with encryption and 38'000 without.
                  
> Improve performance of ENCRYPT protocol
> ---------------------------------------
>
>                 Key: JGRP-1722
>                 URL: https://issues.jboss.org/browse/JGRP-1722
>             Project: JGroups
>          Issue Type: Enhancement
>    Affects Versions: 3.4
>            Reporter: Martin Gencur
>            Assignee: Bela Ban
>             Fix For: 3.5
>
>
> A stress tests with the following setup showed that performance (reads and writes/sec) is halved when ENCRYPT protocol is enabled:
> Infinispan had distributed sync cache with 2 owners on 4 nodes, no transactions. The stress test used 10 threads on each node accessing 1024 byte entries, no conflicts on keys, 20 % writes, 80 % reads. 
> It would be great if we could improve the performance of ENCRYPT protocol.

--
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

From issues at jboss.org  Wed Mar  5 07:37:33 2014
From: issues at jboss.org (Bela Ban (JIRA))
Date: Wed, 5 Mar 2014 07:37:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1722) Improve performance of
	ENCRYPT protocol
In-Reply-To: <JIRA.12508426.1382426974000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508426.1382426974000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508426.1382426974000.4708.1394023053365@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JGRP-1722?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12950170#comment-12950170 ] 

Bela Ban edited comment on JGRP-1722 at 3/5/14 7:35 AM:
--------------------------------------------------------

When a sync RPC is invoked, the following encrypt/decrypt phases are done:
# The request is sent and *encrypted* on the way down
# The request is received and *decrypted* on the way up, either as a single message or as part of a batch
# The response is sent and *encrypted* on the way down
# The response is received and *descrypted* on the way up, either as a single message or as part of a batch

That's a total of 2 encryptions and 2 decryptions for invoking a single sync RPC. I measure the avg cost of encryption and decryption and the total of 1 encrypt/decrypt is ca. 25 us, which means an RPC uses roughly 50us for encryption and decryption. That's a theoretical total of 20'000 max RPCs / sec, but of course this doesn't take the other protocols and processing of the request at the receipient and the response at the caller into account.

*Without* encryption, I get (on the same box) ca. 16'000 RPCs/node avg, *with* encryption I get ca. 8'500. I've come to the conclusion that this is the cost of encryption that has to be paid. If we could make encryption faster, e.g. by picking smaller key sizes, perhaps this could be improved, but parallelization (see above) didn't help.

Note that the numbers for UPerf are higher on cluster01-08 (8 nodes): ca. 21'000 sync RPCs/sec with encryption and 41'000 without.
                
      was (Author: belaban):
    When a sync RPC is invoked, the following encrypt/decrypt phases are done:
# The request is sent and *encrypted* on the way down
# The request is received and *decrypted* on the way up, either as a single message or as part of a batch
# The response is sent and *encrypted* on the way down
# The response is received and *descrypted* on the way up, either as a single message or as part of a batch

That's a total of 2 encryptions and 2 decryptions for invoking a single sync RPC. I measure the avg cost of encryption and decryption and the total of 1 encrypt/decrypt is ca. 25 us, which means an RPC uses roughly 50us for encryption and decryption. That's a theoretical total of 20'000 max RPCs / sec, but of course this doesn't take the other protocols and processing of the request at the receipient and the response at the caller into account.

*Without* encryption, I get (on the same box) ca. 16'000 RPCs/node avg, *with* encryption I get ca. 8'500. I've come to the conclusion that this is the cost of encryption that has to be paid. If we could make encryption faster, e.g. by picking smaller key sizes, perhaps this could be improved, but parallelization (see above) didn't help.

Note that the numbers for UPerf and higher on cluster01-08 (8 nodes): ca. 21'000 sync RPCs/sec with encryption and 41'000 without.
                  
> Improve performance of ENCRYPT protocol
> ---------------------------------------
>
>                 Key: JGRP-1722
>                 URL: https://issues.jboss.org/browse/JGRP-1722
>             Project: JGroups
>          Issue Type: Enhancement
>    Affects Versions: 3.4
>            Reporter: Martin Gencur
>            Assignee: Bela Ban
>             Fix For: 3.5
>
>
> A stress tests with the following setup showed that performance (reads and writes/sec) is halved when ENCRYPT protocol is enabled:
> Infinispan had distributed sync cache with 2 owners on 4 nodes, no transactions. The stress test used 10 threads on each node accessing 1024 byte entries, no conflicts on keys, 20 % writes, 80 % reads. 
> It would be great if we could improve the performance of ENCRYPT protocol.

--
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

From issues at jboss.org  Wed Mar  5 07:55:33 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 5 Mar 2014 07:55:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2672) Additional debug logging for
 LDAP based group loading.
In-Reply-To: <JIRA.12528256.1387475787000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528256.1387475787000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528256.1387475787000.4731.1394024133455@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2672?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12950183#comment-12950183 ] 

RH Bugzilla Integration commented on WFLY-2672:
-----------------------------------------------

Ondrej Lukas <olukas at redhat.com> changed the Status of [bug 1044772|https://bugzilla.redhat.com/show_bug.cgi?id=1044772] from ON_QA to VERIFIED
                
> Additional debug logging for LDAP based group loading.
> ------------------------------------------------------
>
>                 Key: WFLY-2672
>                 URL: https://issues.jboss.org/browse/WFLY-2672
>             Project: WildFly
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management, Security
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 8.0.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

From issues at jboss.org  Wed Mar  5 08:03:33 2014
From: issues at jboss.org (Richard Achmatowicz (JIRA))
Date: Wed, 5 Mar 2014 08:03:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1805) OverlappingMergeTest
 testMergeWithDifferentPartitions fails to create correct merged view
In-Reply-To: <JIRA.12534032.1393962618000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534032.1393962618000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534032.1393962618000.4750.1394024613282@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JGRP-1805?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12950187#comment-12950187 ] 

Richard Achmatowicz commented on JGRP-1805:
-------------------------------------------

I'm putting together a PR which adds more TRACE logging to these merge tests while the merge is happening. Diagnosing merge problems would benefit from GMS, MERGE2 and PING/TCPPING trace logging, when these protocols are present in the stack.
                
> OverlappingMergeTest testMergeWithDifferentPartitions fails to create correct merged view
> -----------------------------------------------------------------------------------------
>
>                 Key: JGRP-1805
>                 URL: https://issues.jboss.org/browse/JGRP-1805
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.2.13
>         Environment: RHEL
>            Reporter: Richard Achmatowicz
>            Assignee: Bela Ban
>             Fix For: 3.2.13, 3.5
>
>
> This test does the following:
> - creates four channels a,b,c,d
> - injects views A: {A,C,B}, B:{A,C,B}, C:{A,C,B} and D: {B,A,C,D}
> - injects a merge event in each of channels A,B,C,D representing these four views
> - checks that all channels have the final view of size 4
> The test fails intermittently on RHEL, with the same failure each time:
> {noformat}
> 181595 [DEBUG] GMS: - A: installing view [A|2] [A]
>    [testng] 181596 [TRACE] GMS: - A: received all 1 ACKs from members for view [A|2]
>    [testng] 181866 [TRACE] GMS: - view [A|3] [] is empty: will not multicast it (last view)
>    [testng] 
>    [testng] -------------------------------------------------------------------
>    [testng] GMS: address=A, cluster=OverlappingMergeTest, physical address=10.16.94.42:27199
>    [testng] -------------------------------------------------------------------
>    [testng] 184954 [TRACE] GMS: - A: no initial members discovered: creating group as first member
>    [testng] 184954 [DEBUG] GMS: - A: installing view [A|0] [A]
>    [testng] 184955 [DEBUG] GMS: - created group (first member). My view is [A|0], impl is org.jgroups.protocols.pbcast.CoordGmsImpl
>    [testng] 
>    [testng] -------------------------------------------------------------------
>    [testng] GMS: address=B, cluster=OverlappingMergeTest, physical address=10.16.94.42:27200
>    [testng] -------------------------------------------------------------------
>    [testng] 184961 [TRACE] GMS: - B: initial_mbrs are A 
>    [testng] 184961 [DEBUG] GMS: - election results: {A=1}
>    [testng] 184961 [DEBUG] GMS: - sending JOIN(B) to A
>    [testng] 185013 [TRACE] GMS: - A: new members=[B], suspected=[], leaving=[], new view: [A|1] [A, B]
>    [testng] 185014 [TRACE] GMS: - A: mcasting view [A|1] [A, B] (2 mbrs)
>    [testng] 
>    [testng] 185025 [DEBUG] GMS: - A: installing view [A|1] [A, B]
>    [testng] 185026 [TRACE] GMS: - A: received all 1 ACKs from members for view [A|1]
>    [testng] 185055 [TRACE] GMS: - B: JOIN-RSP=[A|1] [A, B] [size=2]
>    [testng] 
>    [testng] 
>    [testng] 185055 [DEBUG] GMS: - B: installing view [A|1] [A, B]
>    [testng] 185057 [TRACE] GMS: - A: received all ACKs (1) from joiners for view [A|1]
>    [testng] 
>    [testng] -------------------------------------------------------------------
>    [testng] GMS: address=C, cluster=OverlappingMergeTest, physical address=10.16.94.42:27201
>    [testng] -------------------------------------------------------------------
>    [testng] 185064 [TRACE] GMS: - C: initial_mbrs are B A 
>    [testng] 185064 [DEBUG] GMS: - election results: {A=2}
>    [testng] 185064 [DEBUG] GMS: - sending JOIN(C) to A
>    [testng] 185108 [TRACE] GMS: - A: new members=[C], suspected=[], leaving=[], new view: [A|2] [A, B, C]
>    [testng] 185108 [TRACE] GMS: - A: mcasting view [A|2] [A, B, C] (3 mbrs)
>    [testng] 
>    [testng] 185117 [DEBUG] GMS: - A: installing view [A|2] [A, B, C]
>    [testng] 185118 [DEBUG] GMS: - B: installing view [A|2] [A, B, C]
>    [testng] 185119 [TRACE] GMS: - A: received all 2 ACKs from members for view [A|2]
>    [testng] 185148 [TRACE] GMS: - C: JOIN-RSP=[A|2] [A, B, C] [size=3]
>    [testng] 
>    [testng] 
>    [testng] 185149 [DEBUG] GMS: - C: installing view [A|2] [A, B, C]
>    [testng] 185151 [TRACE] GMS: - A: received all ACKs (1) from joiners for view [A|2]
>    [testng] 
>    [testng] -------------------------------------------------------------------
>    [testng] GMS: address=D, cluster=OverlappingMergeTest, physical address=10.16.94.42:27202
>    [testng] -------------------------------------------------------------------
>    [testng] 185164 [TRACE] GMS: - D: initial_mbrs are B C A 
>    [testng] 185164 [DEBUG] GMS: - election results: {A=3}
>    [testng] 185164 [DEBUG] GMS: - sending JOIN(D) to A
>    [testng] 185203 [TRACE] GMS: - A: new members=[D], suspected=[], leaving=[], new view: [A|3] [A, B, C, D]
>    [testng] 185203 [TRACE] GMS: - A: mcasting view [A|3] [A, B, C, D] (4 mbrs)
>    [testng] 
>    [testng] 185210 [DEBUG] GMS: - A: installing view [A|3] [A, B, C, D]
>    [testng] 185211 [DEBUG] GMS: - B: installing view [A|3] [A, B, C, D]
>    [testng] 185211 [DEBUG] GMS: - C: installing view [A|3] [A, B, C, D]
>    [testng] 185213 [TRACE] GMS: - A: received all 3 ACKs from members for view [A|3]
>    [testng] 185242 [TRACE] GMS: - D: JOIN-RSP=[A|3] [A, B, C, D] [size=4]
>    [testng] 
>    [testng] 
>    [testng] 185242 [DEBUG] GMS: - D: installing view [A|3] [A, B, C, D]
>    [testng] 185242 [TRACE] GMS: - A: received all ACKs (1) from joiners for view [A|3]
>    [testng] 
>    [testng]  ==== Injecting view [A|4] [A, C, B] into A, B and C ====
>    [testng] 185243 [DEBUG] GMS: - A: installing view [A|4] [A, C, B]
>    [testng] 185243 [DEBUG] GMS: - B: installing view [A|4] [A, C, B]
>    [testng] 185244 [DEBUG] GMS: - C: installing view [A|4] [A, C, B]
>    [testng] 
>    [testng]  ==== Injecting view [B|4] [B, A, C, D] into D ====
>    [testng] 
>    [testng] 185245 [DEBUG] GMS: - D: installing view [B|4] [B, A, C, D]
>    [testng] A: [A|4] [A, C, B]
>    [testng] B: [A|4] [A, C, B]
>    [testng] C: [A|4] [A, C, B]
>    [testng] D: [B|4] [B, A, C, D]
>    [testng] 
>    [testng] ==== Injecting a merge event into A, B, C and D====
>    [testng] 185251 [TRACE] GMS: - A: got merge response from A, merge_id=A::3, merge data is sender=A, view=[A|4] [A, C, B], digest=C: [0 (0)], B: [0 (0)], A: [4 (4)]
>    [testng] 185253 [TRACE] GMS: - B: queue is suspended; request MERGE(4 views) is discarded
>    [testng] 185255 [TRACE] GMS: - C: queue is suspended; request MERGE(4 views) is discarded
>    [testng] 185255 [TRACE] GMS: - A: got merge response from B, merge_id=A::3, merge data is sender=B, view=[A|4] [A, C, B], digest=C: [0 (0)], B: [0 (1)], A: [4 (4)]
>    [testng] 190286 [TRACE] GMS: - A: mcasting view MergeView::[A|5] [A, B, C], subgroups=[A|4] [A, C, B], [A|4] [A, C, B] (3 mbrs)
>    [testng] 
>    [testng] 190286 [TRACE] GMS: - B: mcasting view MergeView::[A|5] [A, B, C], subgroups=[A|4] [A, C, B], [A|4] [A, C, B] (3 mbrs)
>    [testng] 
>    [testng] 190317 [DEBUG] GMS: - A: installing view MergeView::[A|5] [A, B, C], subgroups=[A|4] [A, C, B], [A|4] [A, C, B]
>    [testng] 190318 [DEBUG] GMS: - B: installing view MergeView::[A|5] [A, B, C], subgroups=[A|4] [A, C, B], [A|4] [A, C, B]
>    [testng] 190318 [DEBUG] GMS: - C: installing view MergeView::[A|5] [A, B, C], subgroups=[A|4] [A, C, B], [A|4] [A, C, B]
>    [testng] 190320 [TRACE] GMS: - A: received all 3 ACKs from members for view [A|5]
>    [testng] 190320 [TRACE] GMS: - B: received all 3 ACKs from members for view [A|5]
>    [testng] A: [A|5] [A, B, C] (coord=true)
>    [testng] B: [A|5] [A, B, C] (coord=false)
>    [testng] C: [A|5] [A, B, C] (coord=false)
>    [testng] D: [B|4] [B, A, C, D] (coord=false)
>    [testng] 195277 [DEBUG] GMS: - D: sending LEAVE request to B
>    [testng] FAIL: [1] org.jgroups.tests.OverlappingMergeTest.testMergeWithDifferentPartitions()
> {noformat}
>  Whenever this test fails, I see that the queues are suspended on the initial merge attempt.

--
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

From issues at jboss.org  Wed Mar  5 08:35:33 2014
From: issues at jboss.org (Mario Fusco (JIRA))
Date: Wed, 5 Mar 2014 08:35:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-444) NOT conditional element is
 broken when used with subnetworks
In-Reply-To: <JIRA.12533569.1393544376000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12533569.1393544376000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12533569.1393544376000.4865.1394026533560@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-444?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mario Fusco resolved DROOLS-444.
--------------------------------

    Fix Version/s: 6.1.0.Beta1
       Resolution: Done

    
> NOT conditional element is broken when used with subnetworks
> ------------------------------------------------------------
>
>                 Key: DROOLS-444
>                 URL: https://issues.jboss.org/browse/DROOLS-444
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 6.0.0.Final, 6.0.1.Final
>            Reporter: Davide Sottara
>            Assignee: Mario Fusco
>            Priority: Critical
>             Fix For: 6.1.0.Beta1
>
>


--
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

From issues at jboss.org  Wed Mar  5 08:55:35 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 5 Mar 2014 08:55:35 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2198) Remote Naming throws the same
 exception for different causes
In-Reply-To: <JIRA.12501957.1380669681000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501957.1380669681000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501957.1380669681000.5011.1394027735106@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2198?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12950216#comment-12950216 ] 

RH Bugzilla Integration commented on WFLY-2198:
-----------------------------------------------

Jan Martiska <jmartisk at redhat.com> changed the Status of [bug 1053426|https://bugzilla.redhat.com/show_bug.cgi?id=1053426] from ON_QA to VERIFIED
                
> Remote Naming throws the same exception for different causes
> ------------------------------------------------------------
>
>                 Key: WFLY-2198
>                 URL: https://issues.jboss.org/browse/WFLY-2198
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Naming
>            Reporter: Brad Maxwell
>            Assignee: Brad Maxwell
>
> A generic NamingException are thrown if all of the servers specified are unreachable as well as if the user/pass are invalid and a security exception is thrown up, they both are converted into a RuntimeException and a message listing the servers it was unable to call is reported.
> We should be throwing a different exception in the cases we know the cause, such as connection timeout or authentication exception. 
> If all the the servers specified are not not running:
> --------------------------------------------------------------------------------------------
> javax.naming.NamingException: Failed to connect to any server. Servers tried: [remote://localhost:4447]
>   at org.jboss.naming.remote.client.HaRemoteNamingStore.failOverSequence(HaRemoteNamingStore.java:213)
> If one of the servers is running, but the client's username/password are incorrect
> --------------------------------------------------------------------------------------------
> javax.naming.NamingException: Failed to connect to any server. Servers tried: [remote://localhost:4447]
>   at org.jboss.naming.remote.client.HaRemoteNamingStore.failOverSequence(HaRemoteNamingStore.java:213)

--
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

From issues at jboss.org  Wed Mar  5 09:09:34 2014
From: issues at jboss.org (Mario Fusco (JIRA))
Date: Wed, 5 Mar 2014 09:09:34 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-446) Literals may be ambiguously
 resolved as classes on case insensitive filesystems
In-Reply-To: <JIRA.12533712.1393789987000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12533712.1393789987000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12533712.1393789987000.5098.1394028574015@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-446?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mario Fusco reassigned DROOLS-446:
----------------------------------

    Assignee: Mario Fusco  (was: Mark Proctor)

    
> Literals may be ambiguously resolved as classes on case insensitive filesystems
> -------------------------------------------------------------------------------
>
>                 Key: DROOLS-446
>                 URL: https://issues.jboss.org/browse/DROOLS-446
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.5.0.Final, 5.6.0.Final, 6.0.0.Final, 6.0.1.Final
>            Reporter: Davide Sottara
>            Assignee: Mario Fusco
>             Fix For: 6.1.0.CR1
>
>
> When a candidate class literal is analyzed, e.g. : 
> {code}
> declare Foo
>   f1 : Bar = new Bar()
>   f2 : boolean = false 
> end
> {code}
> "Bar" is tentatively resolved (twice) and its f.q.n. is substituted as needed.
> However, even "false" is tentatively resolved as well.
> On a case insensitive filesytems, the presence of a class named False will cause the literal to be resolved erroneously.
> The same will happen to "true" and "null"

--
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

From issues at jboss.org  Wed Mar  5 09:09:34 2014
From: issues at jboss.org (Mario Fusco (JIRA))
Date: Wed, 5 Mar 2014 09:09:34 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-446) Literals may be ambiguously
 resolved as classes on case insensitive filesystems
In-Reply-To: <JIRA.12533712.1393789987000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12533712.1393789987000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12533712.1393789987000.5102.1394028574240@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-446?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mario Fusco resolved DROOLS-446.
--------------------------------

    Resolution: Done

    
> Literals may be ambiguously resolved as classes on case insensitive filesystems
> -------------------------------------------------------------------------------
>
>                 Key: DROOLS-446
>                 URL: https://issues.jboss.org/browse/DROOLS-446
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.5.0.Final, 5.6.0.Final, 6.0.0.Final, 6.0.1.Final
>            Reporter: Davide Sottara
>            Assignee: Mario Fusco
>             Fix For: 6.1.0.CR1
>
>
> When a candidate class literal is analyzed, e.g. : 
> {code}
> declare Foo
>   f1 : Bar = new Bar()
>   f2 : boolean = false 
> end
> {code}
> "Bar" is tentatively resolved (twice) and its f.q.n. is substituted as needed.
> However, even "false" is tentatively resolved as well.
> On a case insensitive filesytems, the presence of a class named False will cause the literal to be resolved erroneously.
> The same will happen to "true" and "null"

--
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

From issues at jboss.org  Wed Mar  5 09:15:57 2014
From: issues at jboss.org (Karel Piwko (JIRA))
Date: Wed, 5 Mar 2014 09:15:57 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3070) The download link for Wildfly
 at http://www.jboss.org/projects is broken
In-Reply-To: <JIRA.12534167.1394028866000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534167.1394028866000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534167.1394028866000.5125.1394028957688@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-3070?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Karel Piwko moved ORG-1946 to WFLY-3070:
----------------------------------------

     Project: WildFly  (was: jboss.org)
         Key: WFLY-3070  (was: ORG-1946)
    Workflow: GIT Pull Request workflow   (was: JBoss Community Team workflow)

    
> The download link for Wildfly at http://www.jboss.org/projects is broken
> ------------------------------------------------------------------------
>
>                 Key: WFLY-3070
>                 URL: https://issues.jboss.org/browse/WFLY-3070
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Karel Piwko
>            Assignee: David Hladky
>
> The link currently points to http://www.wildfly.org/download/, however should actually be http://wildfly.org/downloads/.

--
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

From issues at jboss.org  Wed Mar  5 09:15:57 2014
From: issues at jboss.org (Karel Piwko (JIRA))
Date: Wed, 5 Mar 2014 09:15:57 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3070) The download link for Wildfly
 at http://www.jboss.org/projects is broken
In-Reply-To: <JIRA.12534167.1394028866000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534167.1394028866000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534167.1394028866000.5128.1394028957831@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-3070?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Karel Piwko updated WFLY-3070:
------------------------------

    Assignee:     (was: David Hladky)

    
> The download link for Wildfly at http://www.jboss.org/projects is broken
> ------------------------------------------------------------------------
>
>                 Key: WFLY-3070
>                 URL: https://issues.jboss.org/browse/WFLY-3070
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Karel Piwko
>
> The link currently points to http://www.wildfly.org/download/, however should actually be http://wildfly.org/downloads/.

--
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

From issues at jboss.org  Wed Mar  5 09:21:36 2014
From: issues at jboss.org (David Hladky (JIRA))
Date: Wed, 5 Mar 2014 09:21:36 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3070) The download link for Wildfly
 at http://www.jboss.org/projects is broken
In-Reply-To: <JIRA.12534167.1394028866000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534167.1394028866000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534167.1394028866000.5145.1394029296556@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-3070?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12950233#comment-12950233 ] 

David Hladky commented on WFLY-3070:
------------------------------------

Hi, http://wildfly.org/project.properties needs to be fixed. Magnolia updates the project matrix once a day from this source. 
                
> The download link for Wildfly at http://www.jboss.org/projects is broken
> ------------------------------------------------------------------------
>
>                 Key: WFLY-3070
>                 URL: https://issues.jboss.org/browse/WFLY-3070
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Karel Piwko
>
> The link currently points to http://www.wildfly.org/download/, however should actually be http://wildfly.org/downloads/.

--
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

From issues at jboss.org  Wed Mar  5 09:27:33 2014
From: issues at jboss.org (Richard Achmatowicz (JIRA))
Date: Wed, 5 Mar 2014 09:27:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1805) OverlappingMergeTest
 testMergeWithDifferentPartitions fails to create correct merged view
In-Reply-To: <JIRA.12534032.1393962618000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534032.1393962618000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534032.1393962618000.5160.1394029653461@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JGRP-1805?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12950238#comment-12950238 ] 

Richard Achmatowicz commented on JGRP-1805:
-------------------------------------------

https://github.com/belaban/JGroups/pull/127
                
> OverlappingMergeTest testMergeWithDifferentPartitions fails to create correct merged view
> -----------------------------------------------------------------------------------------
>
>                 Key: JGRP-1805
>                 URL: https://issues.jboss.org/browse/JGRP-1805
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.2.13
>         Environment: RHEL
>            Reporter: Richard Achmatowicz
>            Assignee: Bela Ban
>             Fix For: 3.2.13, 3.5
>
>
> This test does the following:
> - creates four channels a,b,c,d
> - injects views A: {A,C,B}, B:{A,C,B}, C:{A,C,B} and D: {B,A,C,D}
> - injects a merge event in each of channels A,B,C,D representing these four views
> - checks that all channels have the final view of size 4
> The test fails intermittently on RHEL, with the same failure each time:
> {noformat}
> 181595 [DEBUG] GMS: - A: installing view [A|2] [A]
>    [testng] 181596 [TRACE] GMS: - A: received all 1 ACKs from members for view [A|2]
>    [testng] 181866 [TRACE] GMS: - view [A|3] [] is empty: will not multicast it (last view)
>    [testng] 
>    [testng] -------------------------------------------------------------------
>    [testng] GMS: address=A, cluster=OverlappingMergeTest, physical address=10.16.94.42:27199
>    [testng] -------------------------------------------------------------------
>    [testng] 184954 [TRACE] GMS: - A: no initial members discovered: creating group as first member
>    [testng] 184954 [DEBUG] GMS: - A: installing view [A|0] [A]
>    [testng] 184955 [DEBUG] GMS: - created group (first member). My view is [A|0], impl is org.jgroups.protocols.pbcast.CoordGmsImpl
>    [testng] 
>    [testng] -------------------------------------------------------------------
>    [testng] GMS: address=B, cluster=OverlappingMergeTest, physical address=10.16.94.42:27200
>    [testng] -------------------------------------------------------------------
>    [testng] 184961 [TRACE] GMS: - B: initial_mbrs are A 
>    [testng] 184961 [DEBUG] GMS: - election results: {A=1}
>    [testng] 184961 [DEBUG] GMS: - sending JOIN(B) to A
>    [testng] 185013 [TRACE] GMS: - A: new members=[B], suspected=[], leaving=[], new view: [A|1] [A, B]
>    [testng] 185014 [TRACE] GMS: - A: mcasting view [A|1] [A, B] (2 mbrs)
>    [testng] 
>    [testng] 185025 [DEBUG] GMS: - A: installing view [A|1] [A, B]
>    [testng] 185026 [TRACE] GMS: - A: received all 1 ACKs from members for view [A|1]
>    [testng] 185055 [TRACE] GMS: - B: JOIN-RSP=[A|1] [A, B] [size=2]
>    [testng] 
>    [testng] 
>    [testng] 185055 [DEBUG] GMS: - B: installing view [A|1] [A, B]
>    [testng] 185057 [TRACE] GMS: - A: received all ACKs (1) from joiners for view [A|1]
>    [testng] 
>    [testng] -------------------------------------------------------------------
>    [testng] GMS: address=C, cluster=OverlappingMergeTest, physical address=10.16.94.42:27201
>    [testng] -------------------------------------------------------------------
>    [testng] 185064 [TRACE] GMS: - C: initial_mbrs are B A 
>    [testng] 185064 [DEBUG] GMS: - election results: {A=2}
>    [testng] 185064 [DEBUG] GMS: - sending JOIN(C) to A
>    [testng] 185108 [TRACE] GMS: - A: new members=[C], suspected=[], leaving=[], new view: [A|2] [A, B, C]
>    [testng] 185108 [TRACE] GMS: - A: mcasting view [A|2] [A, B, C] (3 mbrs)
>    [testng] 
>    [testng] 185117 [DEBUG] GMS: - A: installing view [A|2] [A, B, C]
>    [testng] 185118 [DEBUG] GMS: - B: installing view [A|2] [A, B, C]
>    [testng] 185119 [TRACE] GMS: - A: received all 2 ACKs from members for view [A|2]
>    [testng] 185148 [TRACE] GMS: - C: JOIN-RSP=[A|2] [A, B, C] [size=3]
>    [testng] 
>    [testng] 
>    [testng] 185149 [DEBUG] GMS: - C: installing view [A|2] [A, B, C]
>    [testng] 185151 [TRACE] GMS: - A: received all ACKs (1) from joiners for view [A|2]
>    [testng] 
>    [testng] -------------------------------------------------------------------
>    [testng] GMS: address=D, cluster=OverlappingMergeTest, physical address=10.16.94.42:27202
>    [testng] -------------------------------------------------------------------
>    [testng] 185164 [TRACE] GMS: - D: initial_mbrs are B C A 
>    [testng] 185164 [DEBUG] GMS: - election results: {A=3}
>    [testng] 185164 [DEBUG] GMS: - sending JOIN(D) to A
>    [testng] 185203 [TRACE] GMS: - A: new members=[D], suspected=[], leaving=[], new view: [A|3] [A, B, C, D]
>    [testng] 185203 [TRACE] GMS: - A: mcasting view [A|3] [A, B, C, D] (4 mbrs)
>    [testng] 
>    [testng] 185210 [DEBUG] GMS: - A: installing view [A|3] [A, B, C, D]
>    [testng] 185211 [DEBUG] GMS: - B: installing view [A|3] [A, B, C, D]
>    [testng] 185211 [DEBUG] GMS: - C: installing view [A|3] [A, B, C, D]
>    [testng] 185213 [TRACE] GMS: - A: received all 3 ACKs from members for view [A|3]
>    [testng] 185242 [TRACE] GMS: - D: JOIN-RSP=[A|3] [A, B, C, D] [size=4]
>    [testng] 
>    [testng] 
>    [testng] 185242 [DEBUG] GMS: - D: installing view [A|3] [A, B, C, D]
>    [testng] 185242 [TRACE] GMS: - A: received all ACKs (1) from joiners for view [A|3]
>    [testng] 
>    [testng]  ==== Injecting view [A|4] [A, C, B] into A, B and C ====
>    [testng] 185243 [DEBUG] GMS: - A: installing view [A|4] [A, C, B]
>    [testng] 185243 [DEBUG] GMS: - B: installing view [A|4] [A, C, B]
>    [testng] 185244 [DEBUG] GMS: - C: installing view [A|4] [A, C, B]
>    [testng] 
>    [testng]  ==== Injecting view [B|4] [B, A, C, D] into D ====
>    [testng] 
>    [testng] 185245 [DEBUG] GMS: - D: installing view [B|4] [B, A, C, D]
>    [testng] A: [A|4] [A, C, B]
>    [testng] B: [A|4] [A, C, B]
>    [testng] C: [A|4] [A, C, B]
>    [testng] D: [B|4] [B, A, C, D]
>    [testng] 
>    [testng] ==== Injecting a merge event into A, B, C and D====
>    [testng] 185251 [TRACE] GMS: - A: got merge response from A, merge_id=A::3, merge data is sender=A, view=[A|4] [A, C, B], digest=C: [0 (0)], B: [0 (0)], A: [4 (4)]
>    [testng] 185253 [TRACE] GMS: - B: queue is suspended; request MERGE(4 views) is discarded
>    [testng] 185255 [TRACE] GMS: - C: queue is suspended; request MERGE(4 views) is discarded
>    [testng] 185255 [TRACE] GMS: - A: got merge response from B, merge_id=A::3, merge data is sender=B, view=[A|4] [A, C, B], digest=C: [0 (0)], B: [0 (1)], A: [4 (4)]
>    [testng] 190286 [TRACE] GMS: - A: mcasting view MergeView::[A|5] [A, B, C], subgroups=[A|4] [A, C, B], [A|4] [A, C, B] (3 mbrs)
>    [testng] 
>    [testng] 190286 [TRACE] GMS: - B: mcasting view MergeView::[A|5] [A, B, C], subgroups=[A|4] [A, C, B], [A|4] [A, C, B] (3 mbrs)
>    [testng] 
>    [testng] 190317 [DEBUG] GMS: - A: installing view MergeView::[A|5] [A, B, C], subgroups=[A|4] [A, C, B], [A|4] [A, C, B]
>    [testng] 190318 [DEBUG] GMS: - B: installing view MergeView::[A|5] [A, B, C], subgroups=[A|4] [A, C, B], [A|4] [A, C, B]
>    [testng] 190318 [DEBUG] GMS: - C: installing view MergeView::[A|5] [A, B, C], subgroups=[A|4] [A, C, B], [A|4] [A, C, B]
>    [testng] 190320 [TRACE] GMS: - A: received all 3 ACKs from members for view [A|5]
>    [testng] 190320 [TRACE] GMS: - B: received all 3 ACKs from members for view [A|5]
>    [testng] A: [A|5] [A, B, C] (coord=true)
>    [testng] B: [A|5] [A, B, C] (coord=false)
>    [testng] C: [A|5] [A, B, C] (coord=false)
>    [testng] D: [B|4] [B, A, C, D] (coord=false)
>    [testng] 195277 [DEBUG] GMS: - D: sending LEAVE request to B
>    [testng] FAIL: [1] org.jgroups.tests.OverlappingMergeTest.testMergeWithDifferentPartitions()
> {noformat}
>  Whenever this test fails, I see that the queues are suspended on the initial merge attempt.

--
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

From issues at jboss.org  Wed Mar  5 09:34:01 2014
From: issues at jboss.org (Jeff Mesnil (JIRA))
Date: Wed, 5 Mar 2014 09:34:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3071) upgrade Generic JMS RA to
	1.0.2.Final
In-Reply-To: <JIRA.12534174.1394029950848@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534174.1394029950848@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534174.1394029950848.5199.1394030041900@jira02.app.mwc.hst.phx2.redhat.com>

Jeff Mesnil created WFLY-3071:
---------------------------------

             Summary: upgrade Generic JMS RA to 1.0.2.Final
                 Key: WFLY-3071
                 URL: https://issues.jboss.org/browse/WFLY-3071
             Project: WildFly
          Issue Type: Component  Upgrade
      Security Level: Public (Everyone can see)
          Components: JCA
    Affects Versions: 8.0.0.Final
            Reporter: Jeff Mesnil
            Assignee: Jeff Mesnil
             Fix For: 8.0.1.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

From issues at jboss.org  Wed Mar  5 09:41:34 2014
From: issues at jboss.org (Richard Achmatowicz (JIRA))
Date: Wed, 5 Mar 2014 09:41:34 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1802) OverlappingUnicastMergeTest
In-Reply-To: <JIRA.12533772.1393856602000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12533772.1393856602000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12533772.1393856602000.5233.1394030494228@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JGRP-1802?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Richard Achmatowicz updated JGRP-1802:
--------------------------------------

    Comment: was deleted

(was: I also noticed that the test description you provided in the javadoc for testWithViewBC() is no longer carried out in the test.
In the javadoc description, you:
- send messages
- inject a new view and then 
- send more messages
whereas in the actual test, you just inject a view and then send messages). 


Any reason for the change? The first test seems more realistic.

 )

    
> OverlappingUnicastMergeTest
> ---------------------------
>
>                 Key: JGRP-1802
>                 URL: https://issues.jboss.org/browse/JGRP-1802
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.2.13
>         Environment: Solaris, RHEL
>            Reporter: Richard Achmatowicz
>            Assignee: Bela Ban
>             Fix For: 3.2.13, 3.5
>
>
> OverlappingUnicastMergeTest does the following:
> - set up three channels a,b,c with the layers MERGE2, VERIFY_SUSPECT and FC removed
> - the receiver of each channel will look at all incoming messages: if mcast, ignore it; if unicast, add to the list of messages received
> - inject some new view into the channels which represents a view configuration which should be recovered from
> - send messages to the channels and check that the messages are received, despite the  injected view
> OverlappingUnicastMergeTest this test is failing in a number of ways (i.e. many of the test methods are failing within the test class on multiple platforms. 

--
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

From issues at jboss.org  Wed Mar  5 09:43:34 2014
From: issues at jboss.org (Richard Achmatowicz (JIRA))
Date: Wed, 5 Mar 2014 09:43:34 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1802) OverlappingUnicastMergeTest
In-Reply-To: <JIRA.12533772.1393856602000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12533772.1393856602000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12533772.1393856602000.5237.1394030614934@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JGRP-1802?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12950249#comment-12950249 ] 

Richard Achmatowicz commented on JGRP-1802:
-------------------------------------------

Of course, the comment above concerning receivers is incorrect - you are just calling ch.getReceiver() to pick up ra, rb and rc.

                
> OverlappingUnicastMergeTest
> ---------------------------
>
>                 Key: JGRP-1802
>                 URL: https://issues.jboss.org/browse/JGRP-1802
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.2.13
>         Environment: Solaris, RHEL
>            Reporter: Richard Achmatowicz
>            Assignee: Bela Ban
>             Fix For: 3.2.13, 3.5
>
>
> OverlappingUnicastMergeTest does the following:
> - set up three channels a,b,c with the layers MERGE2, VERIFY_SUSPECT and FC removed
> - the receiver of each channel will look at all incoming messages: if mcast, ignore it; if unicast, add to the list of messages received
> - inject some new view into the channels which represents a view configuration which should be recovered from
> - send messages to the channels and check that the messages are received, despite the  injected view
> OverlappingUnicastMergeTest this test is failing in a number of ways (i.e. many of the test methods are failing within the test class on multiple platforms. 

--
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

From issues at jboss.org  Wed Mar  5 09:45:49 2014
From: issues at jboss.org (Jesper Pedersen (JIRA))
Date: Wed, 5 Mar 2014 09:45:49 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JBJCA-1149) Recovery connection not
	closed correctly
In-Reply-To: <JIRA.12534177.1394030678976@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534177.1394030678976@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534177.1394030678976.5260.1394030749253@jira02.app.mwc.hst.phx2.redhat.com>

Jesper Pedersen created JBJCA-1149:
--------------------------------------

             Summary: Recovery connection not closed correctly
                 Key: JBJCA-1149
                 URL: https://issues.jboss.org/browse/JBJCA-1149
             Project: IronJacamar
          Issue Type: Bug
          Components: Core
    Affects Versions: 1.1.3.Final, 1.0.24.Final
            Reporter: Jesper Pedersen
            Assignee: Jesper Pedersen
            Priority: Critical
             Fix For: 1.2.0.Beta1




--
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

From issues at jboss.org  Wed Mar  5 09:53:34 2014
From: issues at jboss.org (Radoslav Husar (JIRA))
Date: Wed, 5 Mar 2014 09:53:34 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3044) Mojarra's @ViewScoped
 implementation is not cluster-aware resulting in NotSerializableException
In-Reply-To: <JIRA.12533615.1393599715000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12533615.1393599715000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12533615.1393599715000.5325.1394031214287@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-3044?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12950256#comment-12950256 ] 

Radoslav Husar commented on WFLY-3044:
--------------------------------------

Upstream: https://java.net/jira/browse/JAVASERVERFACES-3191
                
> Mojarra's @ViewScoped implementation is not cluster-aware resulting in NotSerializableException
> -----------------------------------------------------------------------------------------------
>
>                 Key: WFLY-3044
>                 URL: https://issues.jboss.org/browse/WFLY-3044
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JSF
>    Affects Versions: 8.0.0.Final
>            Reporter: Radoslav Husar
>            Assignee: Farah Juma
>            Priority: Critical
>             Fix For: 8.0.1.Final
>
>
> The problem is in ViewScopeContextManager, namely 
> {code}
>             getContextMap(facesContext).put(contextual, new ViewScopeContextObject(contextual, creational, name));
> {code}
> probably it needs an artificial ID generated to serve as a key.
> Also the ViewScopeContextObject needs to be serializable as well among other things
> {code}
> class ViewScopeContextObject {
> {code}
> Issue manifests as
> {noformat}[Server:server-one] 19:22:41,564 ERROR [org.infinispan.interceptors.InvocationContextInterceptor] (default task-15) ISPN000136: Execution error: org.infinispan.commons.CacheException: java.lang.RuntimeException: Failure to marshal argument(s)  
> [Server:server-one] at org.infinispan.commons.util.Util.rewrapAsCacheException(Util.java:581)  
> ...  
> [Server:server-one] at org.infinispan.transaction.tm.DummyTransaction.notifyAfterCompletion(DummyTransaction.java:263)  
> [Server:server-one] at org.infinispan.transaction.tm.DummyTransaction.runCommitTx(DummyTransaction.java:312)  
> [Server:server-one] at org.infinispan.transaction.tm.DummyTransaction.commit(DummyTransaction.java:69)  
> [Server:server-one] at org.infinispan.transaction.tm.DummyBaseTransactionManager.commit(DummyBaseTransactionManager.java:80)  
> [Server:server-one] at org.infinispan.batch.BatchContainer.resolveTransaction(BatchContainer.java:101)  
> [Server:server-one] at org.infinispan.batch.BatchContainer.endBatch(BatchContainer.java:83)  
> [Server:server-one] at org.infinispan.batch.BatchContainer.endBatch(BatchContainer.java:64)  
> [Server:server-one] at org.infinispan.CacheImpl.endBatch(CacheImpl.java:777)  
> [Server:server-one] at org.infinispan.AbstractDelegatingCache.endBatch(AbstractDelegatingCache.java:53)  
> [Server:server-one] at org.wildfly.clustering.web.infinispan.InfinispanBatcher$1.end(InfinispanBatcher.java:56)  
> [Server:server-one] at org.wildfly.clustering.web.infinispan.InfinispanBatcher$1.close(InfinispanBatcher.java:46)  
> [Server:server-one] at org.wildfly.clustering.web.undertow.session.DistributableSession.requestDone(DistributableSession.java:72)  
> [Server:server-one] at io.undertow.servlet.spec.ServletContextImpl.updateSessionAccessTime(ServletContextImpl.java:704) [undertow-servlet-1.0.0.Final.jar:1.0.0.Final]  
> [Server:server-one] at io.undertow.servlet.spec.HttpServletResponseImpl.responseDone(HttpServletResponseImpl.java:522) [undertow-servlet-1.0.0.Final.jar:1.0.0.Final]  
> [Server:server-one] at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:287) [undertow-servlet-1.0.0.Final.jar:1.0.0.Final]  
> [Server:server-one] at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:227) [undertow-servlet-1.0.0.Final.jar:1.0.0.Final]  
> [Server:server-one] at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:73) [undertow-servlet-1.0.0.Final.jar:1.0.0.Final]  
> [Server:server-one] at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:146) [undertow-servlet-1.0.0.Final.jar:1.0.0.Final]  
> [Server:server-one] at io.undertow.server.Connectors.executeRootHandler(Connectors.java:168) [undertow-core-1.0.0.Final.jar:1.0.0.Final]  
> [Server:server-one] at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:687) [undertow-core-1.0.0.Final.jar:1.0.0.Final]  
> [Server:server-one] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_51]  
> [Server:server-one] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_51]  
> [Server:server-one] at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_51]  
> [Server:server-one] Caused by: java.lang.RuntimeException: Failure to marshal argument(s)  
> [Server:server-one] at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.marshallCall(CommandAwareRpcDispatcher.java:333)  
> [Server:server-one] at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.processSingleCall(CommandAwareRpcDispatcher.java:352)  
> [Server:server-one] at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.invokeRemoteCommand(CommandAwareRpcDispatcher.java:167)  
> [Server:server-one] ... 76 more  
> [Server:server-one] Caused by: org.infinispan.commons.marshall.NotSerializableException: org.jboss.weld.bean.ManagedBean  
> [Server:server-one] Caused by: an exception which occurred:  
> [Server:server-one] in object java.util.HashMap at b37422bb  
> [Server:server-one] in object org.jboss.as.clustering.marshalling.SimpleMarshalledValue at b37422bb  
> [Server:server-one] in object org.infinispan.commands.write.PutKeyValueCommand at db517a36  
> [Server:server-one] in object org.infinispan.commands.tx.PrepareCommand at 6fa34718  
> {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

From issues at jboss.org  Wed Mar  5 09:55:37 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 5 Mar 2014 09:55:37 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2839) Remote Naming communication
 exception should be thrown on ConnectException
In-Reply-To: <JIRA.12530687.1391029853000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530687.1391029853000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530687.1391029853000.5362.1394031337512@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2839?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12950261#comment-12950261 ] 

RH Bugzilla Integration commented on WFLY-2839:
-----------------------------------------------

Jan Martiska <jmartisk at redhat.com> changed the Status of [bug 1059837|https://bugzilla.redhat.com/show_bug.cgi?id=1059837] from ON_QA to VERIFIED
                
> Remote Naming communication exception should be thrown on ConnectException
> --------------------------------------------------------------------------
>
>                 Key: WFLY-2839
>                 URL: https://issues.jboss.org/browse/WFLY-2839
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Naming
>    Affects Versions: 8.0.0.CR1
>            Reporter: Brad Maxwell
>            Assignee: Brad Maxwell
>
> Remote Naming communication exception should be thrown on ConnectException, a remoting bug fix showed that a ConnectException can be thrown to remoting and we should throw this as a CommunicationException instead of generic NamingException.  This is related to WFLY-2198

--
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

From issues at jboss.org  Wed Mar  5 10:15:35 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 5 Mar 2014 10:15:35 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2047) testConnection should account
 for deployment classloader
In-Reply-To: <JIRA.12500491.1378898552000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500491.1378898552000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500491.1378898552000.5554.1394032535527@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2047?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12950280#comment-12950280 ] 

RH Bugzilla Integration commented on WFLY-2047:
-----------------------------------------------

Jan Martiska <jmartisk at redhat.com> changed the Status of [bug 1007181|https://bugzilla.redhat.com/show_bug.cgi?id=1007181] from ON_QA to VERIFIED
                
> testConnection should account for deployment classloader
> --------------------------------------------------------
>
>                 Key: WFLY-2047
>                 URL: https://issues.jboss.org/browse/WFLY-2047
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JCA
>    Affects Versions: 8.0.0.Alpha4
>         Environment: All 
>            Reporter: Jay Kumar SenSharma
>            Assignee: Stefano Maestri
>             Fix For: 9.0.0.CR1
>
>
> If a DataSource is created as following:
> ++++++++++++++++
> 	<datasource jndi-name="java:jboss/datasources/test_pool" pool-name="test_pool" enabled="true" use-java-context="true">
>                <connection-url>jdbc:oracle:thin:@ldap://example.com:3060/test,cn=OracleA,dc=worldA</connection-url>
>                <driver>oracle</driver>
>                <pool>
>                      <min-pool-size>1</min-pool-size>
>                      <max-pool-size>15</max-pool-size>
>                </pool>
>                <security>
>                    <user-name>Test</user-name>
>                    <password>testPassword</password>
>               </security>
>        </datasource>
>        <drivers>
>              <driver name="oracle" module="com.oracle.jdbc6">
>                <driver-class>oracle.jdbc.driver.OracleDriver</driver-class>
>              </driver>
>              <driver name="h2" module="com.h2database.h2">
>                <xa-datasource-class>org.h2.jdbcx.JdbcDataSource</xa-datasource-class>
>              </driver>
>        </drivers>
> ++++++++++++++++
> Then while testing the DataSource the Wildfly throws the following Exception:
> +++++++++++++++++++++
> 16:47:10,498 WARN  [org.jboss.jca.core.connectionmanager.pool.strategy.OnePool] (management-handler-thread - 3) IJ000604: Throwable while attempting to get a new connection: null: javax.resource.ResourceException: Could not create connection
> 	at org.jboss.jca.adapters.jdbc.local.LocalManagedConnectionFactory.getLocalManagedConnection(LocalManagedConnectionFactory.java:282) [ironjacamar-jdbc-1.0.17.Final.jar:1.0.17.Final]
> 	at org.jboss.jca.adapters.jdbc.local.LocalManagedConnectionFactory.createManagedConnection(LocalManagedConnectionFactory.java:240) [ironjacamar-jdbc-1.0.17.Final.jar:1.0.17.Final]
> 	at org.jboss.jca.core.connectionmanager.pool.mcp.SemaphoreArrayListManagedConnectionPool.createConnectionEventListener(SemaphoreArrayListManagedConnectionPool.java:781) [ironjacamar-core-impl-1.0.17.Final.jar:1.0.17.Final]
> 	at org.jboss.jca.core.connectionmanager.pool.mcp.SemaphoreArrayListManagedConnectionPool.getConnection(SemaphoreArrayListManagedConnectionPool.java:344) [ironjacamar-core-impl-1.0.17.Final.jar:1.0.17.Final]
> 	at org.jboss.jca.core.connectionmanager.pool.AbstractPool.getSimpleConnection(AbstractPool.java:397) [ironjacamar-core-impl-1.0.17.Final.jar:1.0.17.Final]
> 	at org.jboss.jca.core.connectionmanager.pool.AbstractPool.getConnection(AbstractPool.java:365) [ironjacamar-core-impl-1.0.17.Final.jar:1.0.17.Final]
> 	at org.jboss.jca.core.connectionmanager.pool.AbstractPool.internalTestConnection(AbstractPool.java:627) [ironjacamar-core-impl-1.0.17.Final.jar:1.0.17.Final]
> 	at org.jboss.jca.core.connectionmanager.pool.strategy.OnePool.testConnection(OnePool.java:89) [ironjacamar-core-impl-1.0.17.Final.jar:1.0.17.Final]
> 	at org.jboss.as.connector.subsystems.common.pool.PoolOperations$TestConnectionInPool.invokeCommandOn(PoolOperations.java:143) [jboss-as-connector-7.3.0.Final-redhat-X-SNAPSHOT.jar:7.3.0.Final-redhat-X-SNAPSHOT]
> 	at org.jboss.as.connector.subsystems.common.pool.PoolOperations$1.execute(PoolOperations.java:82) [jboss-as-connector-7.3.0.Final-redhat-X-SNAPSHOT.jar:7.3.0.Final-redhat-X-SNAPSHOT]
> 	at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:440) [jboss-as-controller-7.3.0.Final-redhat-X-SNAPSHOT.jar:7.3.0.Final-redhat-X-SNAPSHOT]
> 	at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:322) [jboss-as-controller-7.3.0.Final-redhat-X-SNAPSHOT.jar:7.3.0.Final-redhat-X-SNAPSHOT]
> 	at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:229) [jboss-as-controller-7.3.0.Final-redhat-X-SNAPSHOT.jar:7.3.0.Final-redhat-X-SNAPSHOT]
> 	at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:224) [jboss-as-controller-7.3.0.Final-redhat-X-SNAPSHOT.jar:7.3.0.Final-redhat-X-SNAPSHOT]
> 	at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:194) [jboss-as-controller-7.3.0.Final-redhat-X-SNAPSHOT.jar:7.3.0.Final-redhat-X-SNAPSHOT]
> 	at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:115) [jboss-as-controller-7.3.0.Final-redhat-X-SNAPSHOT.jar:7.3.0.Final-redhat-X-SNAPSHOT]
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:139) [jboss-as-controller-7.3.0.Final-redhat-X-SNAPSHOT.jar:7.3.0.Final-redhat-X-SNAPSHOT]
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:108) [jboss-as-controller-7.3.0.Final-redhat-X-SNAPSHOT.jar:7.3.0.Final-redhat-X-SNAPSHOT]
> 	at org.jboss.as.protocol.mgmt.AbstractMessageHandler$2$1.doExecute(AbstractMessageHandler.java:296)
> 	at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:518)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_21]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_21]
> 	at java.lang.Thread.run(Thread.java:619) [rt.jar:1.6.0_21]
> 	at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.0.Final.jar:2.1.0.Final]
> Caused by: java.sql.SQLRecoverableException: Io exception: JNDI Package failurejavax.naming.NamingException: JBAS011843: Failed instantiate InitialContextFactory com.sun.jndi.ldap.LdapCtxFactory from classloader ModuleClassLoader for Module "org.jboss.as.connector:main" from local module loader @571a75a2 (finder: local module finder @a210b5b (roots: /home/jsensharma/NotBackedUp/SVN_16_Jan/EAP6_Main/build_wildfly/jboss-as-7.3.0.Final-redhat-X-SNAPSHOT/modules,/home/jsensharma/NotBackedUp/SVN_16_Jan/EAP6_Main/build_wildfly/jboss-as-7.3.0.Final-redhat-X-SNAPSHOT/modules/system/layers/base))
> 	at oracle.jdbc.driver.SQLStateMapping.newSQLException(SQLStateMapping.java:101)
> 	at oracle.jdbc.driver.DatabaseError.newSQLException(DatabaseError.java:112)
> 	at oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:173)
> 	at oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:229)
> 	at oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:458)
> 	at oracle.jdbc.driver.T4CConnection.logon(T4CConnection.java:411)
> 	at oracle.jdbc.driver.PhysicalConnection.<init>(PhysicalConnection.java:490)
> 	at oracle.jdbc.driver.T4CConnection.<init>(T4CConnection.java:202)
> 	at oracle.jdbc.driver.T4CDriverExtension.getConnection(T4CDriverExtension.java:33)
> 	at oracle.jdbc.driver.OracleDriver.connect(OracleDriver.java:474)
> 	at org.jboss.jca.adapters.jdbc.local.LocalManagedConnectionFactory.getLocalManagedConnection(LocalManagedConnectionFactory.java:254) [ironjacamar-jdbc-1.0.17.Final.jar:1.0.17.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

From issues at jboss.org  Wed Mar  5 10:37:35 2014
From: issues at jboss.org (Jesper Pedersen (JIRA))
Date: Wed, 5 Mar 2014 10:37:35 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JBJCA-1149) Recovery connection not
	closed correctly
In-Reply-To: <JIRA.12534177.1394030678000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534177.1394030678000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534177.1394030678000.5708.1394033855322@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBJCA-1149?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jesper Pedersen resolved JBJCA-1149.
------------------------------------

    Resolution: Done

    
> Recovery connection not closed correctly
> ----------------------------------------
>
>                 Key: JBJCA-1149
>                 URL: https://issues.jboss.org/browse/JBJCA-1149
>             Project: IronJacamar
>          Issue Type: Bug
>          Components: Core
>    Affects Versions: 1.0.24.Final, 1.1.3.Final
>            Reporter: Jesper Pedersen
>            Assignee: Jesper Pedersen
>            Priority: Critical
>             Fix For: 1.2.0.Beta1
>
>


--
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

From issues at jboss.org  Wed Mar  5 11:03:33 2014
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Wed, 5 Mar 2014 11:03:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3069) slaves cannot reconnect to a
 restarted master if RBAC is enabled
In-Reply-To: <JIRA.12534143.1394020494000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534143.1394020494000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534143.1394020494000.5912.1394035413496@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-3069?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFLY-3069:
-----------------------------------

    Assignee: Emanuel Muckenhuber  (was: Brian Stansberry)

    
> slaves cannot reconnect to a restarted master if RBAC is enabled
> ----------------------------------------------------------------
>
>                 Key: WFLY-3069
>                 URL: https://issues.jboss.org/browse/WFLY-3069
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>    Affects Versions: 8.0.0.Final
>            Reporter: Tom Fonteyne
>            Assignee: Emanuel Muckenhuber
>            Priority: Critical
>
> Enable RBAC in an Wilfly domain setup. "reload --host=master" and the slaves will no longer be connected to the master

--
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

From issues at jboss.org  Wed Mar  5 11:03:34 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 5 Mar 2014 11:03:34 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3069) slaves cannot reconnect to a
 restarted master if RBAC is enabled
In-Reply-To: <JIRA.12534143.1394020494000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534143.1394020494000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534143.1394020494000.5927.1394035414181@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-3069?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12950315#comment-12950315 ] 

RH Bugzilla Integration commented on WFLY-3069:
-----------------------------------------------

Brian Stansberry <brian.stansberry at redhat.com> changed the Status of [bug 1072915|https://bugzilla.redhat.com/show_bug.cgi?id=1072915] from NEW to ASSIGNED
                
> slaves cannot reconnect to a restarted master if RBAC is enabled
> ----------------------------------------------------------------
>
>                 Key: WFLY-3069
>                 URL: https://issues.jboss.org/browse/WFLY-3069
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>    Affects Versions: 8.0.0.Final
>            Reporter: Tom Fonteyne
>            Assignee: Emanuel Muckenhuber
>            Priority: Critical
>
> Enable RBAC in an Wilfly domain setup. "reload --host=master" and the slaves will no longer be connected to the master

--
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

From issues at jboss.org  Wed Mar  5 11:07:34 2014
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Wed, 5 Mar 2014 11:07:34 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3008) System property substitution
 does not work in subnet-match
In-Reply-To: <JIRA.12533143.1393263668000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12533143.1393263668000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12533143.1393263668000.5955.1394035654809@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-3008?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFLY-3008:
-----------------------------------

    Assignee: Emanuel Muckenhuber  (was: Brian Stansberry)

    
> System property substitution does not work in subnet-match
> ----------------------------------------------------------
>
>                 Key: WFLY-3008
>                 URL: https://issues.jboss.org/browse/WFLY-3008
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>    Affects Versions: 8.0.0.Final
>            Reporter: Rich DiCroce
>            Assignee: Emanuel Muckenhuber
>            Priority: Minor
>             Fix For: 8.0.1.Final
>
>
> Specifying a system property in subnet-match when defining an interface causes an exception on startup. Example:
> {code:xml}
> <property name="subnet" value="192.168.0.0/16"/>
> ...
> <interface name="public">
>     <subnet-match value="${subnet}"/>
> </interface>
> {code}
> Causes:
> {code}
> 12:36:13,457 ERROR [org.jboss.as.server] (Controller Boot Thread) JBAS015956: Caught exception during boot: org.jboss.as.controller.persistence.ConfigurationPersistenceException: JBAS014676: Failed to parse configuration
> 	at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:112) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final]
> 	at org.jboss.as.server.ServerService.boot(ServerService.java:331) [wildfly-server-8.0.0.Final.jar:8.0.0.Final]
> 	at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:256) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final]
> 	at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_45]
> Caused by: javax.xml.stream.XMLStreamException: ParseError at [row,col]:[311,46]
> Message: JBAS014693: Invalid 'value' ${subnet} -- must be of the form address/mask
> 	at org.jboss.as.server.parsing.CommonXml.validateAddressMask(CommonXml.java:605) [wildfly-server-8.0.0.Final.jar:8.0.0.Final]
> 	at org.jboss.as.server.parsing.CommonXml.parseSimpleInterfaceCriterion(CommonXml.java:587) [wildfly-server-8.0.0.Final.jar:8.0.0.Final]
> 	at org.jboss.as.server.parsing.CommonXml.parseInterfaceCriteria(CommonXml.java:467) [wildfly-server-8.0.0.Final.jar:8.0.0.Final]
> 	at org.jboss.as.server.parsing.CommonXml.parseInterfaces(CommonXml.java:644) [wildfly-server-8.0.0.Final.jar:8.0.0.Final]
> 	at org.jboss.as.server.parsing.StandaloneXml.readServerElement_1_4(StandaloneXml.java:465) [wildfly-server-8.0.0.Final.jar:8.0.0.Final]
> 	at org.jboss.as.server.parsing.StandaloneXml.readElement(StandaloneXml.java:145) [wildfly-server-8.0.0.Final.jar:8.0.0.Final]
> 	at org.jboss.as.server.parsing.StandaloneXml.readElement(StandaloneXml.java:107) [wildfly-server-8.0.0.Final.jar:8.0.0.Final]
> 	at org.jboss.staxmapper.XMLMapperImpl.processNested(XMLMapperImpl.java:110) [staxmapper-1.1.0.Final.jar:1.1.0.Final]
> 	at org.jboss.staxmapper.XMLMapperImpl.parseDocument(XMLMapperImpl.java:69) [staxmapper-1.1.0.Final.jar:1.1.0.Final]
> 	at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:104) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final]
> 	... 3 more
> {code}

--
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

From issues at jboss.org  Wed Mar  5 11:07:35 2014
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Wed, 5 Mar 2014 11:07:35 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3000) Incorrect 'Content-Type'
 response set after executing an erroneous command
In-Reply-To: <JIRA.12533034.1393178127000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12533034.1393178127000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12533034.1393178127000.5959.1394035655021@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-3000?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFLY-3000:
-----------------------------------

    Assignee: Emanuel Muckenhuber  (was: Brian Stansberry)

    
> Incorrect 'Content-Type' response set after executing an erroneous command
> --------------------------------------------------------------------------
>
>                 Key: WFLY-3000
>                 URL: https://issues.jboss.org/browse/WFLY-3000
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>    Affects Versions: 8.0.0.Final
>            Reporter: Christos Vasilakis
>            Assignee: Emanuel Muckenhuber
>             Fix For: 8.0.1.Final
>
>
> The http management interface, upon error, returns an incorrect 'Content-Type' of 
> {noformat}
> 'Content-Type: text/plain; charset=utf-8' 
> {noformat}
> although JSON response is returned.
> To reproduce, issue from the command line a simple 'read' operation
> {noformat}
> curl --digest -D - http://localhost:9990/management --header "Content-Type: application/json" -d '{"operation":"read-attribute", "name":"foo"}' -u <username>:<password>
> ..
> Content-Type: text/plain; charset=utf-8
> Content-Length: 119
> Date: Sun, 23 Feb 2014 17:27:10 GMT
> {
>     "outcome" : "failed",
>     "failure-description" : "JBAS014792: Unknown attribute foo",
>     "rolled-back" : true
> }
> {noformat}
> The 'Content-Type' should have been set to *'application/json'* instead of *'text/plain'*
> Note: On JBoss AS 7.1.1.Final, the correct type of *'application/json'* is returned for the same operation.

--
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

From issues at jboss.org  Wed Mar  5 11:09:33 2014
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Wed, 5 Mar 2014 11:09:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2479) Security subsystem
 transformers for 1.1.0 do not reject expressions, or test for it
In-Reply-To: <JIRA.12524657.1383936941000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12524657.1383936941000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12524657.1383936941000.5974.1394035773588@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2479?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFLY-2479:
-----------------------------------

    Assignee: Emanuel Muckenhuber  (was: Brian Stansberry)

    
> Security subsystem transformers for 1.1.0 do not reject expressions, or test for it
> -----------------------------------------------------------------------------------
>
>                 Key: WFLY-2479
>                 URL: https://issues.jboss.org/browse/WFLY-2479
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Kabir Khan
>            Assignee: Emanuel Muckenhuber
>             Fix For: 8.0.1.Final
>
>
> Getting it to test for it is going to be a bit different than the usual RejectExpressionsConfig. The add handler transformers (correctly from what I can tell) use the existing child xxx-module resource to create the transformed add operation.
> However, I think with the ModelTestUtils.checkFailedTransformedBootOperations() stuff set up the way it is the child resource/model used to populate the ops. A possible solution is to override the RejectExpressionsConfig to correct the main model as part of correcting the ops.

--
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

From issues at jboss.org  Wed Mar  5 11:09:34 2014
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Wed, 5 Mar 2014 11:09:34 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1895) Provide a "default" role for
 management users with no other role specified
In-Reply-To: <JIRA.12498830.1376775776000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12498830.1376775776000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12498830.1376775776000.5984.1394035774303@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-1895?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFLY-1895:
-----------------------------------

    Assignee: Emanuel Muckenhuber  (was: Brian Stansberry)

    
> Provide a "default" role for management users with no other role specified
> --------------------------------------------------------------------------
>
>                 Key: WFLY-1895
>                 URL: https://issues.jboss.org/browse/WFLY-1895
>             Project: WildFly
>          Issue Type: Enhancement
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management, Security
>            Reporter: Jakub Cechacek
>            Assignee: Emanuel Muckenhuber
>              Labels: rbac-filed-by-qa
>             Fix For: 8.0.1.Final
>
>
> Currently it seems that when using RBAC provider users with no defined role are unable to read domain model at all.  Consequently logging into Admin Console leads to 500 error page. Similar errors in CLI. 
> In relation to this, it should be considered what is the expected behavior of unsecured management interface. 

--
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

From issues at jboss.org  Wed Mar  5 11:17:33 2014
From: issues at jboss.org (James Perkins (JIRA))
Date: Wed, 5 Mar 2014 11:17:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2959) Downgrade Jackson dependency
In-Reply-To: <JIRA.12532567.1392747430000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12532567.1392747430000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12532567.1392747430000.6014.1394036253851@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2959?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12950323#comment-12950323 ] 

James Perkins commented on WFLY-2959:
-------------------------------------

The main issue was if you wanted to use Jackson 2 with RESTEasy, the application would fail to deploy. Is that the same issue with jackson-datatype-hibernate too?

I know it's a lot to ask, but if anyone could attach simple example apps that show the behavior of 1 where it fails on RESTEasy with 2.3.x and 2 where it fails on 2.2.x with Hibernate. I will check to see if 2.3.2 fixes both issues. It wasn't released when I did the downgrade.
                
> Downgrade Jackson dependency
> ----------------------------
>
>                 Key: WFLY-2959
>                 URL: https://issues.jboss.org/browse/WFLY-2959
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: REST
>    Affects Versions: 8.0.0.Final
>            Reporter: James Perkins
>            Assignee: James Perkins
>             Fix For: 8.0.1.Final
>
>
> Jackson was upgraded to 2.3.0 which contains a [bug|https://github.com/FasterXML/jackson-jaxrs-providers/commit/bafb6fb64bc15482c7bfc56784169204d6c4b1f2#commitcomment-5224156] that breaks RESTEasy. RESTEasy currently uses 2.2.1. Downgrading to at least 2.2.3, which is what CR1 is at, seems to resolve this issue.
> We should likely keep the version aligned with RESTEasy, but since CR1 was using 2.2.3 with no issues, I think reverting back to that should be fine.

--
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

From issues at jboss.org  Wed Mar  5 11:29:33 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 5 Mar 2014 11:29:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-72) Potential memory leak in
 StatelessKnowledgeSessionImpl#execute when fireAllRules throwing
 RuntimeException
In-Reply-To: <JIRA.12486763.1362705976000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12486763.1362705976000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12486763.1362705976000.6082.1394036973278@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/DROOLS-72?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12950336#comment-12950336 ] 

RH Bugzilla Integration commented on DROOLS-72:
-----------------------------------------------

Rick Wagner <rwagner at redhat.com> changed the Status of [bug 1036126|https://bugzilla.redhat.com/show_bug.cgi?id=1036126] from NEW to ASSIGNED
                
> Potential memory leak in StatelessKnowledgeSessionImpl#execute when fireAllRules throwing RuntimeException
> ----------------------------------------------------------------------------------------------------------
>
>                 Key: DROOLS-72
>                 URL: https://issues.jboss.org/browse/DROOLS-72
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.5.0.Final
>            Reporter: Trung Nguyen
>            Assignee: Mario Fusco
>             Fix For: 5.5.1.Final, 6.0.0.Alpha9
>
>
> when {{ksession.fireAllRules()}} throws RuntimeException, it cause {{ksession}} never gets released. 
> {code:lang=java} 
> public void execute(Object object) {
>         StatefulKnowledgeSession ksession = newWorkingMemory();
>         ksession.insert( object );
>         ksession.fireAllRules( );
>         ksession.dispose();
>     }
>     public void execute(Iterable objects) {
>         StatefulKnowledgeSession ksession = newWorkingMemory();
>         for ( Object object : objects ) {
>             ksession.insert( object );
>         }
>         ksession.fireAllRules( );
>         ksession.dispose();
>     }
> {code}

--
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

From issues at jboss.org  Wed Mar  5 11:33:33 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 5 Mar 2014 11:33:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-195) Rule Engine Crashes when
 used Slide Window constraints and kAgent is configured as incremental
 processing
In-Reply-To: <JIRA.12496944.1374271678000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12496944.1374271678000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12496944.1374271678000.6101.1394037213382@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/DROOLS-195?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12950339#comment-12950339 ] 

RH Bugzilla Integration commented on DROOLS-195:
------------------------------------------------

Rick Wagner <rwagner at redhat.com> changed the Status of [bug 1031099|https://bugzilla.redhat.com/show_bug.cgi?id=1031099] from NEW to ASSIGNED
                
> Rule Engine Crashes when used Slide Window constraints and kAgent is configured as incremental processing
> ---------------------------------------------------------------------------------------------------------
>
>                 Key: DROOLS-195
>                 URL: https://issues.jboss.org/browse/DROOLS-195
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Alessandro Lazarotti
>            Assignee: Mario Fusco
>         Attachments: LoopTest.java
>
>
> When there is a Slide Window constraint and the kbase is configured to receive incremental changes from the kagent (drools.agent.newInstance as false) - the engine crashes
> Attached unit test
> Version: 5.3.0

--
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

From issues at jboss.org  Wed Mar  5 12:33:33 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 5 Mar 2014 12:33:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2908) The formatter attribute is
 changed every time it's processed
In-Reply-To: <JIRA.12531828.1392161269000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12531828.1392161269000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12531828.1392161269000.6274.1394040813179@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2908?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12950371#comment-12950371 ] 

RH Bugzilla Integration commented on WFLY-2908:
-----------------------------------------------

James Perkins <jperkins at redhat.com> changed the Status of [bug 1066597|https://bugzilla.redhat.com/show_bug.cgi?id=1066597] from NEW to CLOSED
                
> The formatter attribute is changed every time it's processed
> ------------------------------------------------------------
>
>                 Key: WFLY-2908
>                 URL: https://issues.jboss.org/browse/WFLY-2908
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Logging
>            Reporter: James Perkins
>            Assignee: James Perkins
>            Priority: Minor
>             Fix For: 8.0.1.Final
>
>
> The {{HandlerOperations.equalValue()}} method uses the incorrect property name when comparing values resulting in the method always returning {{false}}.
> This does not harm anything, but just changes the format pattern each time a resource is processed.

--
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

From issues at jboss.org  Wed Mar  5 12:39:33 2014
From: issues at jboss.org (Chris Roberts (JIRA))
Date: Wed, 5 Mar 2014 12:39:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2959) Downgrade Jackson dependency
In-Reply-To: <JIRA.12532567.1392747430000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12532567.1392747430000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12532567.1392747430000.6285.1394041173860@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2959?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12950375#comment-12950375 ] 

Chris Roberts commented on WFLY-2959:
-------------------------------------

I'll try and put a simple test app together, will take me a bit.
jackson-datatype-hibernate4:2.2.3 with hibernate 4.3.0 is a silent failure (it just fails to lazy initialise and triggers a lazy initialisation exception).
jackson:2.3.0/2.3.1 will exception whenever you include resteasy-jackson2-provider and exclude jettison/jackson1 in jboss-deployment-structure.xml and try and write with any simple JAXRS/JAXB resource with APPLICATION_JSON.
                
> Downgrade Jackson dependency
> ----------------------------
>
>                 Key: WFLY-2959
>                 URL: https://issues.jboss.org/browse/WFLY-2959
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: REST
>    Affects Versions: 8.0.0.Final
>            Reporter: James Perkins
>            Assignee: James Perkins
>             Fix For: 8.0.1.Final
>
>
> Jackson was upgraded to 2.3.0 which contains a [bug|https://github.com/FasterXML/jackson-jaxrs-providers/commit/bafb6fb64bc15482c7bfc56784169204d6c4b1f2#commitcomment-5224156] that breaks RESTEasy. RESTEasy currently uses 2.2.1. Downgrading to at least 2.2.3, which is what CR1 is at, seems to resolve this issue.
> We should likely keep the version aligned with RESTEasy, but since CR1 was using 2.2.3 with no issues, I think reverting back to that should be fine.

--
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

From issues at jboss.org  Wed Mar  5 12:45:33 2014
From: issues at jboss.org (James Perkins (JIRA))
Date: Wed, 5 Mar 2014 12:45:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2959) Downgrade Jackson dependency
In-Reply-To: <JIRA.12532567.1392747430000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12532567.1392747430000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12532567.1392747430000.6291.1394041533806@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2959?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12950377#comment-12950377 ] 

James Perkins commented on WFLY-2959:
-------------------------------------

Thanks! If I get some time I might try and create something too. I could use a refresher anyway on how to do some of this stuff :)
                
> Downgrade Jackson dependency
> ----------------------------
>
>                 Key: WFLY-2959
>                 URL: https://issues.jboss.org/browse/WFLY-2959
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: REST
>    Affects Versions: 8.0.0.Final
>            Reporter: James Perkins
>            Assignee: James Perkins
>             Fix For: 8.0.1.Final
>
>
> Jackson was upgraded to 2.3.0 which contains a [bug|https://github.com/FasterXML/jackson-jaxrs-providers/commit/bafb6fb64bc15482c7bfc56784169204d6c4b1f2#commitcomment-5224156] that breaks RESTEasy. RESTEasy currently uses 2.2.1. Downgrading to at least 2.2.3, which is what CR1 is at, seems to resolve this issue.
> We should likely keep the version aligned with RESTEasy, but since CR1 was using 2.2.3 with no issues, I think reverting back to that should be fine.

--
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

From issues at jboss.org  Wed Mar  5 12:59:33 2014
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Wed, 5 Mar 2014 12:59:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3072) Support Referrals for
 security realms using LDAP for authentication or group loading.
In-Reply-To: <JIRA.12534214.1394042303616@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534214.1394042303616@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534214.1394042303616.6301.1394042373506@jira02.app.mwc.hst.phx2.redhat.com>

Darran Lofthouse created WFLY-3072:
--------------------------------------

             Summary: Support Referrals for security realms using LDAP for authentication or group loading.
                 Key: WFLY-3072
                 URL: https://issues.jboss.org/browse/WFLY-3072
             Project: WildFly
          Issue Type: Task
      Security Level: Public (Everyone can see)
          Components: Domain Management, Security
            Reporter: Darran Lofthouse
            Assignee: Darran Lofthouse
             Fix For: 8.0.1.Final


This also needs to take into account compatibility with caching.

--
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

From issues at jboss.org  Wed Mar  5 12:59:33 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 5 Mar 2014 12:59:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3072) Support Referrals for
 security realms using LDAP for authentication or group loading.
In-Reply-To: <JIRA.12534214.1394042303000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534214.1394042303000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534214.1394042303000.6303.1394042373600@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-3072?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated WFLY-3072:
------------------------------------------

        Bugzilla Update: Perform
    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1066488

    
> Support Referrals for security realms using LDAP for authentication or group loading.
> -------------------------------------------------------------------------------------
>
>                 Key: WFLY-3072
>                 URL: https://issues.jboss.org/browse/WFLY-3072
>             Project: WildFly
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management, Security
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 8.0.1.Final
>
>
> This also needs to take into account compatibility with caching.

--
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

From issues at jboss.org  Wed Mar  5 13:03:33 2014
From: issues at jboss.org (Radoslav Husar (JIRA))
Date: Wed, 5 Mar 2014 13:03:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3044) Mojarra's @ViewScoped
 implementation is not cluster-aware resulting in NotSerializableException
In-Reply-To: <JIRA.12533615.1393599715000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12533615.1393599715000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12533615.1393599715000.6311.1394042613333@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-3044?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Radoslav Husar reassigned WFLY-3044:
------------------------------------

    Assignee: Radoslav Husar  (was: Farah Juma)

    
> Mojarra's @ViewScoped implementation is not cluster-aware resulting in NotSerializableException
> -----------------------------------------------------------------------------------------------
>
>                 Key: WFLY-3044
>                 URL: https://issues.jboss.org/browse/WFLY-3044
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JSF
>    Affects Versions: 8.0.0.Final
>            Reporter: Radoslav Husar
>            Assignee: Radoslav Husar
>            Priority: Critical
>             Fix For: 8.0.1.Final
>
>
> The problem is in ViewScopeContextManager, namely 
> {code}
>             getContextMap(facesContext).put(contextual, new ViewScopeContextObject(contextual, creational, name));
> {code}
> probably it needs an artificial ID generated to serve as a key.
> Also the ViewScopeContextObject needs to be serializable as well among other things
> {code}
> class ViewScopeContextObject {
> {code}
> Issue manifests as
> {noformat}[Server:server-one] 19:22:41,564 ERROR [org.infinispan.interceptors.InvocationContextInterceptor] (default task-15) ISPN000136: Execution error: org.infinispan.commons.CacheException: java.lang.RuntimeException: Failure to marshal argument(s)  
> [Server:server-one] at org.infinispan.commons.util.Util.rewrapAsCacheException(Util.java:581)  
> ...  
> [Server:server-one] at org.infinispan.transaction.tm.DummyTransaction.notifyAfterCompletion(DummyTransaction.java:263)  
> [Server:server-one] at org.infinispan.transaction.tm.DummyTransaction.runCommitTx(DummyTransaction.java:312)  
> [Server:server-one] at org.infinispan.transaction.tm.DummyTransaction.commit(DummyTransaction.java:69)  
> [Server:server-one] at org.infinispan.transaction.tm.DummyBaseTransactionManager.commit(DummyBaseTransactionManager.java:80)  
> [Server:server-one] at org.infinispan.batch.BatchContainer.resolveTransaction(BatchContainer.java:101)  
> [Server:server-one] at org.infinispan.batch.BatchContainer.endBatch(BatchContainer.java:83)  
> [Server:server-one] at org.infinispan.batch.BatchContainer.endBatch(BatchContainer.java:64)  
> [Server:server-one] at org.infinispan.CacheImpl.endBatch(CacheImpl.java:777)  
> [Server:server-one] at org.infinispan.AbstractDelegatingCache.endBatch(AbstractDelegatingCache.java:53)  
> [Server:server-one] at org.wildfly.clustering.web.infinispan.InfinispanBatcher$1.end(InfinispanBatcher.java:56)  
> [Server:server-one] at org.wildfly.clustering.web.infinispan.InfinispanBatcher$1.close(InfinispanBatcher.java:46)  
> [Server:server-one] at org.wildfly.clustering.web.undertow.session.DistributableSession.requestDone(DistributableSession.java:72)  
> [Server:server-one] at io.undertow.servlet.spec.ServletContextImpl.updateSessionAccessTime(ServletContextImpl.java:704) [undertow-servlet-1.0.0.Final.jar:1.0.0.Final]  
> [Server:server-one] at io.undertow.servlet.spec.HttpServletResponseImpl.responseDone(HttpServletResponseImpl.java:522) [undertow-servlet-1.0.0.Final.jar:1.0.0.Final]  
> [Server:server-one] at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:287) [undertow-servlet-1.0.0.Final.jar:1.0.0.Final]  
> [Server:server-one] at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:227) [undertow-servlet-1.0.0.Final.jar:1.0.0.Final]  
> [Server:server-one] at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:73) [undertow-servlet-1.0.0.Final.jar:1.0.0.Final]  
> [Server:server-one] at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:146) [undertow-servlet-1.0.0.Final.jar:1.0.0.Final]  
> [Server:server-one] at io.undertow.server.Connectors.executeRootHandler(Connectors.java:168) [undertow-core-1.0.0.Final.jar:1.0.0.Final]  
> [Server:server-one] at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:687) [undertow-core-1.0.0.Final.jar:1.0.0.Final]  
> [Server:server-one] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_51]  
> [Server:server-one] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_51]  
> [Server:server-one] at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_51]  
> [Server:server-one] Caused by: java.lang.RuntimeException: Failure to marshal argument(s)  
> [Server:server-one] at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.marshallCall(CommandAwareRpcDispatcher.java:333)  
> [Server:server-one] at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.processSingleCall(CommandAwareRpcDispatcher.java:352)  
> [Server:server-one] at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.invokeRemoteCommand(CommandAwareRpcDispatcher.java:167)  
> [Server:server-one] ... 76 more  
> [Server:server-one] Caused by: org.infinispan.commons.marshall.NotSerializableException: org.jboss.weld.bean.ManagedBean  
> [Server:server-one] Caused by: an exception which occurred:  
> [Server:server-one] in object java.util.HashMap at b37422bb  
> [Server:server-one] in object org.jboss.as.clustering.marshalling.SimpleMarshalledValue at b37422bb  
> [Server:server-one] in object org.infinispan.commands.write.PutKeyValueCommand at db517a36  
> [Server:server-one] in object org.infinispan.commands.tx.PrepareCommand at 6fa34718  
> {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

From issues at jboss.org  Wed Mar  5 14:15:34 2014
From: issues at jboss.org (Jesper Pedersen (JIRA))
Date: Wed, 5 Mar 2014 14:15:34 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JBJCA-1150) The TransactionIntegration
 module should provide a unique identifier for a transaction
In-Reply-To: <JIRA.12534218.1394046878174@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534218.1394046878174@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534218.1394046878174.6551.1394046934527@jira02.app.mwc.hst.phx2.redhat.com>

Jesper Pedersen created JBJCA-1150:
--------------------------------------

             Summary: The TransactionIntegration module should provide a unique identifier for a transaction
                 Key: JBJCA-1150
                 URL: https://issues.jboss.org/browse/JBJCA-1150
             Project: IronJacamar
          Issue Type: Task
          Components: Core
            Reporter: Jesper Pedersen
            Assignee: Jesper Pedersen
             Fix For: 1.2.0.Beta1


The identifier needs to be stable for the entire transaction lifecycle

--
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

From issues at jboss.org  Wed Mar  5 14:21:33 2014
From: issues at jboss.org (Richard Achmatowicz (JIRA))
Date: Wed, 5 Mar 2014 14:21:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1802) OverlappingUnicastMergeTest
In-Reply-To: <JIRA.12533772.1393856602000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12533772.1393856602000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12533772.1393856602000.6578.1394047293522@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JGRP-1802?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Richard Achmatowicz updated JGRP-1802:
--------------------------------------

    Description: 
OverlappingUnicastMergeTest does the following:

- set up three channels a,b,c with the layers MERGE2, VERIFY_SUSPECT and FC removed
- the receiver of each channel will look at all incoming messages: if mcast, ignore it; if unicast, add to the list of messages received
- inject some new view into the channels which represents a view configuration which should be recovered from
- send messages to the channels and check that the messages are received, despite the  injected view

OverlappingUnicastMergeTest this test is failing in a number of ways (i.e. many of the test methods are failing within the test class on multiple platforms. 

For example, in testWithViewBC, channel A should receive messages #1 through #5 from channels A, B and C, but it does not receive #1 through #3 from channel C. 

  was:
OverlappingUnicastMergeTest does the following:

- set up three channels a,b,c with the layers MERGE2, VERIFY_SUSPECT and FC removed
- the receiver of each channel will look at all incoming messages: if mcast, ignore it; if unicast, add to the list of messages received
- inject some new view into the channels which represents a view configuration which should be recovered from
- send messages to the channels and check that the messages are received, despite the  injected view

OverlappingUnicastMergeTest this test is failing in a number of ways (i.e. many of the test methods are failing within the test class on multiple platforms. 


    
> OverlappingUnicastMergeTest
> ---------------------------
>
>                 Key: JGRP-1802
>                 URL: https://issues.jboss.org/browse/JGRP-1802
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.2.13
>         Environment: Solaris, RHEL
>            Reporter: Richard Achmatowicz
>            Assignee: Bela Ban
>             Fix For: 3.2.13, 3.5
>
>
> OverlappingUnicastMergeTest does the following:
> - set up three channels a,b,c with the layers MERGE2, VERIFY_SUSPECT and FC removed
> - the receiver of each channel will look at all incoming messages: if mcast, ignore it; if unicast, add to the list of messages received
> - inject some new view into the channels which represents a view configuration which should be recovered from
> - send messages to the channels and check that the messages are received, despite the  injected view
> OverlappingUnicastMergeTest this test is failing in a number of ways (i.e. many of the test methods are failing within the test class on multiple platforms. 
> For example, in testWithViewBC, channel A should receive messages #1 through #5 from channels A, B and C, but it does not receive #1 through #3 from channel C. 

--
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

From issues at jboss.org  Wed Mar  5 14:21:33 2014
From: issues at jboss.org (Ben Software Engineer (JIRA))
Date: Wed, 5 Mar 2014 14:21:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2936) "Only session and
 message-driven beans with bean-managed transaction demarcation are allowed
 to access UserTransaction" error in migrated seam 2.2.2 application
In-Reply-To: <JIRA.12532176.1392367721000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12532176.1392367721000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12532176.1392367721000.6581.1394047293680@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2936?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12950410#comment-12950410 ] 

Ben Software Engineer commented on WFLY-2936:
---------------------------------------------

Hi Eduardo - thanks for the thoughts and comments.  We are also in the middle of a Seam 2.1 Jboss 5 upgrade to Seam 2.3 and (hopefully) wildfly.  This appears to not be an issue with JBoss 7.1.1.final, but I realize wildfly has evolved from that on many fronts.  This is a major blocker for anyone trying to use Seam I think and would be nice if some alternative config can be set in wildfly module to allow this, perhaps registering the calling class only or some means of limiting who can bypass this security check.  Can you explain as to what specifically the security check is about?  Also can someone open up a JIRA on seam side, as I do not seen this critical blocker listed here:
https://issues.jboss.org/browse/JBSEAM/fixforversion/12321763

Thank you.
                
> "Only session and message-driven beans with bean-managed transaction demarcation are allowed to access UserTransaction" error in migrated seam 2.2.2 application
> ----------------------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2936
>                 URL: https://issues.jboss.org/browse/WFLY-2936
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 8.0.0.Final
>         Environment: Windows 7 64bit
> Java 1.7.0_51
> WildFly 8.0.0.Final
> JBoss Seam 2.2.2.Final
>            Reporter: Dimitris Keramidas
>            Assignee: Eduardo Martins
>         Attachments: Auth.java, Authenticator.java, components.xml, jboss-deployment-structure.xml, server.log
>
>
> The error is fired when attempting to call a transaction-enabled EJB method, from a seam component. Specifically the authentication component.
> In order to get to this position, the project's deployment descriptors had to be migrated. Furthermore, mojarra version 1.2_15 was deployed to WildFly, as described by this link: https://community.jboss.org/wiki/DesignOfWildFlyMulti-JSFFeature
> Please see attached logs and descriptors.

--
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

From issues at jboss.org  Wed Mar  5 14:23:33 2014
From: issues at jboss.org (Ben Software Engineer (JIRA))
Date: Wed, 5 Mar 2014 14:23:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2936) "Only session and
 message-driven beans with bean-managed transaction demarcation are allowed
 to access UserTransaction" error in migrated seam 2.2.2 application
In-Reply-To: <JIRA.12532176.1392367721000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12532176.1392367721000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12532176.1392367721000.6598.1394047413669@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2936?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12950410#comment-12950410 ] 

Ben Software Engineer edited comment on WFLY-2936 at 3/5/14 2:23 PM:
---------------------------------------------------------------------

Hi Eduardo - thanks for the thoughts and comments.  We are also in the middle of a Seam 2.1 Jboss 5 upgrade to Seam 2.3 and (hopefully) wildfly.  This appears to not be an issue with JBoss 7.1.1.final, but I realize wildfly has evolved from that on many fronts.  This is a major blocker for anyone trying to use Seam I think and would be nice if some alternative config can be set in wildfly module to allow this, perhaps registering the calling class only or some means of limiting who can bypass this security check.  Can you explain as to what specifically the security check is about?  Also can someone open up a JIRA on seam side, as I do not see this critical blocker listed here:
https://issues.jboss.org/browse/JBSEAM/fixforversion/12321763

Thank you.
                
      was (Author: ben.maisano):
    Hi Eduardo - thanks for the thoughts and comments.  We are also in the middle of a Seam 2.1 Jboss 5 upgrade to Seam 2.3 and (hopefully) wildfly.  This appears to not be an issue with JBoss 7.1.1.final, but I realize wildfly has evolved from that on many fronts.  This is a major blocker for anyone trying to use Seam I think and would be nice if some alternative config can be set in wildfly module to allow this, perhaps registering the calling class only or some means of limiting who can bypass this security check.  Can you explain as to what specifically the security check is about?  Also can someone open up a JIRA on seam side, as I do not seen this critical blocker listed here:
https://issues.jboss.org/browse/JBSEAM/fixforversion/12321763

Thank you.
                  
> "Only session and message-driven beans with bean-managed transaction demarcation are allowed to access UserTransaction" error in migrated seam 2.2.2 application
> ----------------------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2936
>                 URL: https://issues.jboss.org/browse/WFLY-2936
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 8.0.0.Final
>         Environment: Windows 7 64bit
> Java 1.7.0_51
> WildFly 8.0.0.Final
> JBoss Seam 2.2.2.Final
>            Reporter: Dimitris Keramidas
>            Assignee: Eduardo Martins
>         Attachments: Auth.java, Authenticator.java, components.xml, jboss-deployment-structure.xml, server.log
>
>
> The error is fired when attempting to call a transaction-enabled EJB method, from a seam component. Specifically the authentication component.
> In order to get to this position, the project's deployment descriptors had to be migrated. Furthermore, mojarra version 1.2_15 was deployed to WildFly, as described by this link: https://community.jboss.org/wiki/DesignOfWildFlyMulti-JSFFeature
> Please see attached logs and descriptors.

--
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

From issues at jboss.org  Wed Mar  5 14:25:33 2014
From: issues at jboss.org (Jassem Eldroubi (JIRA))
Date: Wed, 5 Mar 2014 14:25:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JBAS-9559) Jboss AS 5.1.0GA - Cannot
 bind to URL [rmi://0.0.0.0:1090/jmxconnector]:
 javax.naming.ServiceUnavailableException
In-Reply-To: <JIRA.12534221.1394047449440@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534221.1394047449440@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534221.1394047449440.6601.1394047533213@jira02.app.mwc.hst.phx2.redhat.com>

Jassem Eldroubi created JBAS-9559:
-------------------------------------

             Summary: Jboss AS 5.1.0GA - Cannot bind to URL [rmi://0.0.0.0:1090/jmxconnector]: javax.naming.ServiceUnavailableException
                 Key: JBAS-9559
                 URL: https://issues.jboss.org/browse/JBAS-9559
             Project: Application Server 3  4  5 and 6
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: JMX
    Affects Versions: JBossAS-5.1.0.GA
         Environment: Mac OS X Mavericks, JDK 1.6.0_65 (6)
            Reporter: Jassem Eldroubi


After upgrading from OS X 10.8 to OS X 10.9, the bindAddress flag "-b 0.0.0.0" no longer works on Jboss startup. I see a similar issue at https://issues.jboss.org/browse/ENTESB-1077 that's marked as resolved, but I don't see the solution on the issue page. I get the following errors:

10:38:02,343 ERROR [AbstractKernelController] Error installing to Start: name=jboss.remoting:protocol=rmi,service=JMXConnectorServer state=Create mode=Manual requiredState=Installed
java.io.IOException: Cannot bind to URL [rmi://DCjeldro15917:1090/jmxconnector]: javax.naming.ServiceUnavailableException [Root exception is java.rmi.ConnectException: Connection refused to host: DCjeldro15917; nested  exception is: 
java.net.ConnectException: Operation timed out]
at javax.management.remote.rmi.RMIConnectorServer.newIOException(RMIConnectorServer.java:804)
at javax.management.remote.rmi.RMIConnectorServer.start(RMIConnectorServer.java:417)
at org.jboss.mx.remoting.service.JMXConnectorServerService.start(JMXConnectorServerService.java:131)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:157)
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:96)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:668)
at org.jboss.system.microcontainer.ServiceProxy.invoke(ServiceProxy.java:206)
at com.sun.proxy.$Proxy38.start(Unknown Source)
at org.jboss.system.microcontainer.StartStopLifecycleAction.installAction(StartStopLifecycleAction.java:42)
at org.jboss.system.microcontainer.StartStopLifecycleAction.installAction(StartStopLifecycleAction.java:37)
at org.jboss.dependency.plugins.action.SimpleControllerContextAction.simpleInstallAction(SimpleControllerContextAction.java:62)
at org.jboss.dependency.plugins.action.AccessControllerContextAction.install(AccessControllerContextAction.java:71)
at org.jboss.dependency.plugins.AbstractControllerContextActions.install(AbstractControllerContextActions.java:51)
at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
at org.jboss.system.microcontainer.ServiceControllerContext.install(ServiceControllerContext.java:286)
at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1631)
at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:934)
at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1082)
at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:984)
at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:822)
at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
at org.jboss.system.ServiceController.doChange(ServiceController.java:688)
at org.jboss.system.ServiceController.start(ServiceController.java:460)
at org.jboss.system.deployers.ServiceDeployer.start(ServiceDeployer.java:163)
at org.jboss.system.deployers.ServiceDeployer.deploy(ServiceDeployer.java:99)
at org.jboss.system.deployers.ServiceDeployer.deploy(ServiceDeployer.java:46)
at org.jboss.deployers.spi.deployer.helpers.AbstractSimpleRealDeployer.internalDeploy(AbstractSimpleRealDeployer.java:62)
at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployer.deploy(AbstractRealDeployer.java:50)
at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:171)
at org.jboss.deployers.plugins.deployers.DeployersImpl.doDeploy(DeployersImpl.java:1439)
at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1157)
at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1178)
at org.jboss.deployers.plugins.deployers.DeployersImpl.install(DeployersImpl.java:1098)
at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1631)
at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:934)
at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1082)
at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:984)
at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:822)
at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
at org.jboss.deployers.plugins.deployers.DeployersImpl.process(DeployersImpl.java:781)
at org.jboss.deployers.plugins.main.MainDeployerImpl.process(MainDeployerImpl.java:702)
at org.jboss.system.server.profileservice.repository.MainDeployerAdapter.process(MainDeployerAdapter.java:117)
at org.jboss.system.server.profileservice.repository.ProfileDeployAction.install(ProfileDeployAction.java:70)
at org.jboss.system.server.profileservice.repository.AbstractProfileAction.install(AbstractProfileAction.java:53)
at org.jboss.system.server.profileservice.repository.AbstractProfileService.install(AbstractProfileService.java:361)
at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1631)
at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:934)
at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1082)
at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:984)
at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:822)
at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
at org.jboss.system.server.profileservice.repository.AbstractProfileService.activateProfile(AbstractProfileService.java:306)
at org.jboss.system.server.profileservice.ProfileServiceBootstrap.start(ProfileServiceBootstrap.java:271)
at org.jboss.bootstrap.AbstractServerImpl.start(AbstractServerImpl.java:461)
at org.jboss.Main.boot(Main.java:221)
at org.jboss.Main$1.run(Main.java:556)
at java.lang.Thread.run(Thread.java:695)
Caused by: javax.naming.ServiceUnavailableException [Root exception is java.rmi.ConnectException: Connection refused to host: DCjeldro15917; nested exception is: 
java.net.ConnectException: Operation timed out]
at com.sun.jndi.rmi.registry.RegistryContext.bind(RegistryContext.java:126)
at com.sun.jndi.toolkit.url.GenericURLContext.bind(GenericURLContext.java:208)
at javax.naming.InitialContext.bind(InitialContext.java:400)
at javax.management.remote.rmi.RMIConnectorServer.bind(RMIConnectorServer.java:625)
at javax.management.remote.rmi.RMIConnectorServer.start(RMIConnectorServer.java:412)
... 63 more
Caused by: java.rmi.ConnectException: Connection refused to host: DCjeldro15917; nested exception is: 
java.net.ConnectException: Operation timed out
at sun.rmi.transport.tcp.TCPEndpoint.newSocket(TCPEndpoint.java:601)
at sun.rmi.transport.tcp.TCPChannel.createConnection(TCPChannel.java:198)
at sun.rmi.transport.tcp.TCPChannel.newConnection(TCPChannel.java:184)
at sun.rmi.server.UnicastRef.newCall(UnicastRef.java:322)
at sun.rmi.registry.RegistryImpl_Stub.bind(Unknown Source)
at com.sun.jndi.rmi.registry.RegistryContext.bind(RegistryContext.java:120)
... 67 more
Caused by: java.net.ConnectException: Operation timed out
at java.net.PlainSocketImpl.socketConnect(Native Method)
at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:382)
at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:241)
at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:228)
at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:431)
at java.net.Socket.connect(Socket.java:527)
at java.net.Socket.connect(Socket.java:476)
at java.net.Socket.<init>(Socket.java:373)
at java.net.Socket.<init>(Socket.java:187)
at sun.rmi.transport.proxy.RMIDirectSocketFactory.createSocket(RMIDirectSocketFactory.java:22)
at sun.rmi.transport.proxy.RMIMasterSocketFactory.createSocket(RMIMasterSocketFactory.java:128)
at sun.rmi.transport.tcp.TCPEndpoint.newSocket(TCPEndpoint.java:595)
... 72 more
10:38:02,412 ERROR [AbstractKernelController] Error installing to Real: name=vfsfile:/Users/jeldro/Documents/Development/jboss-5.1.0.GA/server/default/deploy/jmx-remoting.sar/ state=PreReal mode=Manual requiredState=Real
org.jboss.deployers.spi.DeploymentException: Error deploying: jboss.remoting:service=JMXConnectorServer,protocol=rmi
at org.jboss.deployers.spi.DeploymentException.rethrowAsDeploymentException(DeploymentException.java:49)
at org.jboss.system.deployers.ServiceDeployer.deploy(ServiceDeployer.java:118)
at org.jboss.system.deployers.ServiceDeployer.deploy(ServiceDeployer.java:46)
at org.jboss.deployers.spi.deployer.helpers.AbstractSimpleRealDeployer.internalDeploy(AbstractSimpleRealDeployer.java:62)
at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployer.deploy(AbstractRealDeployer.java:50)
at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:171)
at org.jboss.deployers.plugins.deployers.DeployersImpl.doDeploy(DeployersImpl.java:1439)
at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1157)
at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1178)
at org.jboss.deployers.plugins.deployers.DeployersImpl.install(DeployersImpl.java:1098)
at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1631)
at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:934)
at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1082)
at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:984)
at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:822)
at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
at org.jboss.deployers.plugins.deployers.DeployersImpl.process(DeployersImpl.java:781)
at org.jboss.deployers.plugins.main.MainDeployerImpl.process(MainDeployerImpl.java:702)
at org.jboss.system.server.profileservice.repository.MainDeployerAdapter.process(MainDeployerAdapter.java:117)
at org.jboss.system.server.profileservice.repository.ProfileDeployAction.install(ProfileDeployAction.java:70)
at org.jboss.system.server.profileservice.repository.AbstractProfileAction.install(AbstractProfileAction.java:53)
at org.jboss.system.server.profileservice.repository.AbstractProfileService.install(AbstractProfileService.java:361)
at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1631)
at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:934)
at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1082)
at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:984)
at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:822)
at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
at org.jboss.system.server.profileservice.repository.AbstractProfileService.activateProfile(AbstractProfileService.java:306)
at org.jboss.system.server.profileservice.ProfileServiceBootstrap.start(ProfileServiceBootstrap.java:271)
at org.jboss.bootstrap.AbstractServerImpl.start(AbstractServerImpl.java:461)
at org.jboss.Main.boot(Main.java:221)
at org.jboss.Main$1.run(Main.java:556)
at java.lang.Thread.run(Thread.java:695)
Caused by: java.io.IOException: Cannot bind to URL [rmi://DCjeldro15917:1090/jmxconnector]: javax.naming.ServiceUnavailableException [Root exception is java.rmi.ConnectException: Connection refused to host: DCjeldro15917; nested exception is: 
java.net.ConnectException: Operation timed out]
at javax.management.remote.rmi.RMIConnectorServer.newIOException(RMIConnectorServer.java:804)
at javax.management.remote.rmi.RMIConnectorServer.start(RMIConnectorServer.java:417)
at org.jboss.mx.remoting.service.JMXConnectorServerService.start(JMXConnectorServerService.java:131)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:157)
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:96)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:668)
at org.jboss.system.microcontainer.ServiceProxy.invoke(ServiceProxy.java:206)
at com.sun.proxy.$Proxy38.start(Unknown Source)
at org.jboss.system.microcontainer.StartStopLifecycleAction.installAction(StartStopLifecycleAction.java:42)
at org.jboss.system.microcontainer.StartStopLifecycleAction.installAction(StartStopLifecycleAction.java:37)
at org.jboss.dependency.plugins.action.SimpleControllerContextAction.simpleInstallAction(SimpleControllerContextAction.java:62)
at org.jboss.dependency.plugins.action.AccessControllerContextAction.install(AccessControllerContextAction.java:71)
at org.jboss.dependency.plugins.AbstractControllerContextActions.install(AbstractControllerContextActions.java:51)
at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
at org.jboss.system.microcontainer.ServiceControllerContext.install(ServiceControllerContext.java:286)
at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1631)
at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:934)
at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1082)
at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:984)
at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:822)
at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
at org.jboss.system.ServiceController.doChange(ServiceController.java:688)
at org.jboss.system.ServiceController.start(ServiceController.java:460)
at org.jboss.system.deployers.ServiceDeployer.start(ServiceDeployer.java:163)
at org.jboss.system.deployers.ServiceDeployer.deploy(ServiceDeployer.java:99)
... 34 more
Caused by: javax.naming.ServiceUnavailableException [Root exception is java.rmi.ConnectException: Connection refused to host: DCjeldro15917; nested exception is: 
java.net.ConnectException: Operation timed out]
at com.sun.jndi.rmi.registry.RegistryContext.bind(RegistryContext.java:126)
at com.sun.jndi.toolkit.url.GenericURLContext.bind(GenericURLContext.java:208)
at javax.naming.InitialContext.bind(InitialContext.java:400)
at javax.management.remote.rmi.RMIConnectorServer.bind(RMIConnectorServer.java:625)
at javax.management.remote.rmi.RMIConnectorServer.start(RMIConnectorServer.java:412)
... 63 more
Caused by: java.rmi.ConnectException: Connection refused to host: DCjeldro15917; nested exception is: 
java.net.ConnectException: Operation timed out
at sun.rmi.transport.tcp.TCPEndpoint.newSocket(TCPEndpoint.java:601)
at sun.rmi.transport.tcp.TCPChannel.createConnection(TCPChannel.java:198)
at sun.rmi.transport.tcp.TCPChannel.newConnection(TCPChannel.java:184)
at sun.rmi.server.UnicastRef.newCall(UnicastRef.java:322)
at sun.rmi.registry.RegistryImpl_Stub.bind(Unknown Source)
at com.sun.jndi.rmi.registry.RegistryContext.bind(RegistryContext.java:120)
... 67 more
Caused by: java.net.ConnectException: Operation timed out
at java.net.PlainSocketImpl.socketConnect(Native Method)
at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:382)
at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:241)
at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:228)
at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:431)
at java.net.Socket.connect(Socket.java:527)
at java.net.Socket.connect(Socket.java:476)
at java.net.Socket.<init>(Socket.java:373)
at java.net.Socket.<init>(Socket.java:187)
at sun.rmi.transport.proxy.RMIDirectSocketFactory.createSocket(RMIDirectSocketFactory.java:22)
at sun.rmi.transport.proxy.RMIMasterSocketFactory.createSocket(RMIMasterSocketFactory.java:128)
at sun.rmi.transport.tcp.TCPEndpoint.newSocket(TCPEndpoint.java:595)
... 72 more
10:38:02,866 INFO  [MailService] Mail Service bound to java:/Mail
10:38:03,682 INFO  [SystemPropertiesService] Loaded system properties from: file:/Users/jeldro/Documents/Development/jboss-5.1.0.GA/server/default/conf/bmiss-dashboard.properties
10:38:03,692 INFO  [SystemPropertiesService] Loaded system properties from: file:/Users/jeldro/Documents/Development/jboss-5.1.0.GA/server/default/conf/bmiss-extranet.properties
10:38:03,695 INFO  [SystemPropertiesService] Loaded system properties from: file:/Users/jeldro/Documents/Development/jboss-5.1.0.GA/server/default/conf/bmiss-intranet.properties
10:38:03,698 INFO  [SystemPropertiesService] Loaded system properties from: file:/Users/jeldro/Documents/Development/jboss-5.1.0.GA/server/default/conf/bmiss-external.properties
10:38:06,659 WARN  [JBossASSecurityMetadataStore] WARNING! POTENTIAL SECURITY RISK. It has been detected that the MessageSucker component which sucks messages from one node to another has not had its password changed from the installation default. Please see the JBoss Messaging user guide for instructions on how to do this.
10:38:06,667 WARN  [AnnotationCreator] No ClassLoader provided, using TCCL: org.jboss.managed.api.annotation.ManagementComponent
10:38:06,790 WARN  [AnnotationCreator] No ClassLoader provided, using TCCL: org.jboss.managed.api.annotation.ManagementComponent
10:38:07,010 INFO  [TransactionManagerService] JBossTS Transaction Service (JTA version - tag:JBOSSTS_4_6_1_GA) - JBoss Inc.

After trying netstat -a | grep 1090, I don't see any processes bound to port 1090.

Any ideas?
Thanks!

--
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

From issues at jboss.org  Wed Mar  5 14:37:33 2014
From: issues at jboss.org (Chris Roberts (JIRA))
Date: Wed, 5 Mar 2014 14:37:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2959) Downgrade Jackson dependency
In-Reply-To: <JIRA.12532567.1392747430000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12532567.1392747430000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12532567.1392747430000.6664.1394048253300@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2959?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Chris Roberts updated WFLY-2959:
--------------------------------

    Attachment: org.jboss.test.test-jackson.tar.gz


Simple Test Project which recreates the issue
                
> Downgrade Jackson dependency
> ----------------------------
>
>                 Key: WFLY-2959
>                 URL: https://issues.jboss.org/browse/WFLY-2959
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: REST
>    Affects Versions: 8.0.0.Final
>            Reporter: James Perkins
>            Assignee: James Perkins
>             Fix For: 8.0.1.Final
>
>         Attachments: org.jboss.test.test-jackson.tar.gz
>
>
> Jackson was upgraded to 2.3.0 which contains a [bug|https://github.com/FasterXML/jackson-jaxrs-providers/commit/bafb6fb64bc15482c7bfc56784169204d6c4b1f2#commitcomment-5224156] that breaks RESTEasy. RESTEasy currently uses 2.2.1. Downgrading to at least 2.2.3, which is what CR1 is at, seems to resolve this issue.
> We should likely keep the version aligned with RESTEasy, but since CR1 was using 2.2.3 with no issues, I think reverting back to that should be fine.

--
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

From issues at jboss.org  Wed Mar  5 14:43:33 2014
From: issues at jboss.org (Chris Roberts (JIRA))
Date: Wed, 5 Mar 2014 14:43:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2959) Downgrade Jackson dependency
In-Reply-To: <JIRA.12532567.1392747430000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12532567.1392747430000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12532567.1392747430000.6672.1394048613347@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2959?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12950420#comment-12950420 ] 

Chris Roberts commented on WFLY-2959:
-------------------------------------

I believe the attached test project is the simplest recreation of the issues. Sorry, I'm not a king of writing test cases, so it's just a project with the issues, I don't know how to right unit tests for JAX-RS resources :-) You can test it after deployment with:
curl http://localhost:8080/org.jboss.test.test-jackson/rest/person/

- Uses Jackson2 (per POM and jboss-deployment-structure.xml)
- Uses jackson-datatype-hibernate4 (currently 2.3.0 as per jackson-core in wildfly 8 final) with a OneToMany entity

As it stands it gives the _configForWriter issue (with wildfly 8 final).
With wildfly 8 CR1 (change jackson-datatype-hibernate4 version to 2.2.3 in the pom.xml to match wildfly 8 cr1 jackson version), it will give a lazy initialisation exception I think.

Ideally this project should not give lazy initialisation exceptions and should work and return json in wildlfly 8.

                
> Downgrade Jackson dependency
> ----------------------------
>
>                 Key: WFLY-2959
>                 URL: https://issues.jboss.org/browse/WFLY-2959
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: REST
>    Affects Versions: 8.0.0.Final
>            Reporter: James Perkins
>            Assignee: James Perkins
>             Fix For: 8.0.1.Final
>
>         Attachments: org.jboss.test.test-jackson.tar.gz
>
>
> Jackson was upgraded to 2.3.0 which contains a [bug|https://github.com/FasterXML/jackson-jaxrs-providers/commit/bafb6fb64bc15482c7bfc56784169204d6c4b1f2#commitcomment-5224156] that breaks RESTEasy. RESTEasy currently uses 2.2.1. Downgrading to at least 2.2.3, which is what CR1 is at, seems to resolve this issue.
> We should likely keep the version aligned with RESTEasy, but since CR1 was using 2.2.3 with no issues, I think reverting back to that should be fine.

--
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

From issues at jboss.org  Wed Mar  5 14:43:33 2014
From: issues at jboss.org (Chris Roberts (JIRA))
Date: Wed, 5 Mar 2014 14:43:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2959) Downgrade Jackson dependency
In-Reply-To: <JIRA.12532567.1392747430000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12532567.1392747430000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12532567.1392747430000.6674.1394048613430@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2959?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12950420#comment-12950420 ] 

Chris Roberts edited comment on WFLY-2959 at 3/5/14 2:42 PM:
-------------------------------------------------------------

I believe the attached test project is the simplest recreation of the issues. Sorry, I'm not a king of writing test cases, so it's just a project with the issues, I don't know how to write unit tests for JAX-RS resources :-) You can test it after deployment with:
curl http://localhost:8080/org.jboss.test.test-jackson/rest/person/

- Uses Jackson2 (per POM and jboss-deployment-structure.xml)
- Uses jackson-datatype-hibernate4 (currently 2.3.0 as per jackson-core in wildfly 8 final) with a OneToMany entity

As it stands it gives the _configForWriter issue (with wildfly 8 final).
With wildfly 8 CR1 (change jackson-datatype-hibernate4 version to 2.2.3 in the pom.xml to match wildfly 8 cr1 jackson version), it will give a lazy initialisation exception I think.

Ideally this project should not give lazy initialisation exceptions and should work and return json in wildlfly 8.

                
      was (Author: night199uk):
    I believe the attached test project is the simplest recreation of the issues. Sorry, I'm not a king of writing test cases, so it's just a project with the issues, I don't know how to right unit tests for JAX-RS resources :-) You can test it after deployment with:
curl http://localhost:8080/org.jboss.test.test-jackson/rest/person/

- Uses Jackson2 (per POM and jboss-deployment-structure.xml)
- Uses jackson-datatype-hibernate4 (currently 2.3.0 as per jackson-core in wildfly 8 final) with a OneToMany entity

As it stands it gives the _configForWriter issue (with wildfly 8 final).
With wildfly 8 CR1 (change jackson-datatype-hibernate4 version to 2.2.3 in the pom.xml to match wildfly 8 cr1 jackson version), it will give a lazy initialisation exception I think.

Ideally this project should not give lazy initialisation exceptions and should work and return json in wildlfly 8.

                  
> Downgrade Jackson dependency
> ----------------------------
>
>                 Key: WFLY-2959
>                 URL: https://issues.jboss.org/browse/WFLY-2959
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: REST
>    Affects Versions: 8.0.0.Final
>            Reporter: James Perkins
>            Assignee: James Perkins
>             Fix For: 8.0.1.Final
>
>         Attachments: org.jboss.test.test-jackson.tar.gz
>
>
> Jackson was upgraded to 2.3.0 which contains a [bug|https://github.com/FasterXML/jackson-jaxrs-providers/commit/bafb6fb64bc15482c7bfc56784169204d6c4b1f2#commitcomment-5224156] that breaks RESTEasy. RESTEasy currently uses 2.2.1. Downgrading to at least 2.2.3, which is what CR1 is at, seems to resolve this issue.
> We should likely keep the version aligned with RESTEasy, but since CR1 was using 2.2.3 with no issues, I think reverting back to that should be fine.

--
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

From issues at jboss.org  Wed Mar  5 14:49:34 2014
From: issues at jboss.org (James Perkins (JIRA))
Date: Wed, 5 Mar 2014 14:49:34 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2959) Downgrade Jackson dependency
In-Reply-To: <JIRA.12532567.1392747430000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12532567.1392747430000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12532567.1392747430000.6692.1394048974145@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2959?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12950423#comment-12950423 ] 

James Perkins commented on WFLY-2959:
-------------------------------------

Looks perfect. That's exactly what I was looking for :)
                
> Downgrade Jackson dependency
> ----------------------------
>
>                 Key: WFLY-2959
>                 URL: https://issues.jboss.org/browse/WFLY-2959
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: REST
>    Affects Versions: 8.0.0.Final
>            Reporter: James Perkins
>            Assignee: James Perkins
>             Fix For: 8.0.1.Final
>
>         Attachments: org.jboss.test.test-jackson.tar.gz
>
>
> Jackson was upgraded to 2.3.0 which contains a [bug|https://github.com/FasterXML/jackson-jaxrs-providers/commit/bafb6fb64bc15482c7bfc56784169204d6c4b1f2#commitcomment-5224156] that breaks RESTEasy. RESTEasy currently uses 2.2.1. Downgrading to at least 2.2.3, which is what CR1 is at, seems to resolve this issue.
> We should likely keep the version aligned with RESTEasy, but since CR1 was using 2.2.3 with no issues, I think reverting back to that should be fine.

--
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

From issues at jboss.org  Wed Mar  5 14:53:33 2014
From: issues at jboss.org (Chris Roberts (JIRA))
Date: Wed, 5 Mar 2014 14:53:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2959) Downgrade Jackson dependency
In-Reply-To: <JIRA.12532567.1392747430000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12532567.1392747430000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12532567.1392747430000.6722.1394049213480@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2959?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Chris Roberts updated WFLY-2959:
--------------------------------

    Attachment: org.jboss.test.test-jackson.tar.gz

    
> Downgrade Jackson dependency
> ----------------------------
>
>                 Key: WFLY-2959
>                 URL: https://issues.jboss.org/browse/WFLY-2959
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: REST
>    Affects Versions: 8.0.0.Final
>            Reporter: James Perkins
>            Assignee: James Perkins
>             Fix For: 8.0.1.Final
>
>         Attachments: org.jboss.test.test-jackson.tar.gz, org.jboss.test.test-jackson.tar.gz
>
>
> Jackson was upgraded to 2.3.0 which contains a [bug|https://github.com/FasterXML/jackson-jaxrs-providers/commit/bafb6fb64bc15482c7bfc56784169204d6c4b1f2#commitcomment-5224156] that breaks RESTEasy. RESTEasy currently uses 2.2.1. Downgrading to at least 2.2.3, which is what CR1 is at, seems to resolve this issue.
> We should likely keep the version aligned with RESTEasy, but since CR1 was using 2.2.3 with no issues, I think reverting back to that should be fine.

--
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

From issues at jboss.org  Wed Mar  5 14:53:33 2014
From: issues at jboss.org (Chris Roberts (JIRA))
Date: Wed, 5 Mar 2014 14:53:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2959) Downgrade Jackson dependency
In-Reply-To: <JIRA.12532567.1392747430000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12532567.1392747430000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12532567.1392747430000.6724.1394049213558@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2959?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12950427#comment-12950427 ] 

Chris Roberts commented on WFLY-2959:
-------------------------------------

Try #2, I forgot a couple of classes to initialise jackson-datatype-hibernate4.
Should be right now. I hope.
                
> Downgrade Jackson dependency
> ----------------------------
>
>                 Key: WFLY-2959
>                 URL: https://issues.jboss.org/browse/WFLY-2959
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: REST
>    Affects Versions: 8.0.0.Final
>            Reporter: James Perkins
>            Assignee: James Perkins
>             Fix For: 8.0.1.Final
>
>         Attachments: org.jboss.test.test-jackson.tar.gz, org.jboss.test.test-jackson.tar.gz
>
>
> Jackson was upgraded to 2.3.0 which contains a [bug|https://github.com/FasterXML/jackson-jaxrs-providers/commit/bafb6fb64bc15482c7bfc56784169204d6c4b1f2#commitcomment-5224156] that breaks RESTEasy. RESTEasy currently uses 2.2.1. Downgrading to at least 2.2.3, which is what CR1 is at, seems to resolve this issue.
> We should likely keep the version aligned with RESTEasy, but since CR1 was using 2.2.3 with no issues, I think reverting back to that should be fine.

--
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

From issues at jboss.org  Wed Mar  5 15:17:34 2014
From: issues at jboss.org (Bela Ban (JIRA))
Date: Wed, 5 Mar 2014 15:17:34 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1802) OverlappingUnicastMergeTest
In-Reply-To: <JIRA.12533772.1393856602000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12533772.1393856602000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12533772.1393856602000.6755.1394050654056@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JGRP-1802?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban updated JGRP-1802:
---------------------------

    Fix Version/s:     (was: 3.5)


I removed the 3.5 target. Should the issue get fixed in 3.2.x, we can still forward-port it to master (3.5) if it exists in master.
                
> OverlappingUnicastMergeTest
> ---------------------------
>
>                 Key: JGRP-1802
>                 URL: https://issues.jboss.org/browse/JGRP-1802
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.2.13
>         Environment: Solaris, RHEL
>            Reporter: Richard Achmatowicz
>            Assignee: Bela Ban
>             Fix For: 3.2.13
>
>
> OverlappingUnicastMergeTest does the following:
> - set up three channels a,b,c with the layers MERGE2, VERIFY_SUSPECT and FC removed
> - the receiver of each channel will look at all incoming messages: if mcast, ignore it; if unicast, add to the list of messages received
> - inject some new view into the channels which represents a view configuration which should be recovered from
> - send messages to the channels and check that the messages are received, despite the  injected view
> OverlappingUnicastMergeTest this test is failing in a number of ways (i.e. many of the test methods are failing within the test class on multiple platforms. 
> For example, in testWithViewBC, channel A should receive messages #1 through #5 from channels A, B and C, but it does not receive #1 through #3 from channel C. 

--
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

From issues at jboss.org  Wed Mar  5 15:19:33 2014
From: issues at jboss.org (Bela Ban (JIRA))
Date: Wed, 5 Mar 2014 15:19:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1805) OverlappingMergeTest
 testMergeWithDifferentPartitions fails to create correct merged view
In-Reply-To: <JIRA.12534032.1393962618000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534032.1393962618000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534032.1393962618000.6759.1394050773702@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JGRP-1805?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban updated JGRP-1805:
---------------------------

    Fix Version/s:     (was: 3.5)


I removed the 3.5 target. Should the issue get fixed in 3.2.x, we can still forward-port it to master (3.5) if it exists in master.
                
> OverlappingMergeTest testMergeWithDifferentPartitions fails to create correct merged view
> -----------------------------------------------------------------------------------------
>
>                 Key: JGRP-1805
>                 URL: https://issues.jboss.org/browse/JGRP-1805
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.2.13
>         Environment: RHEL
>            Reporter: Richard Achmatowicz
>            Assignee: Bela Ban
>             Fix For: 3.2.13
>
>
> This test does the following:
> - creates four channels a,b,c,d
> - injects views A: {A,C,B}, B:{A,C,B}, C:{A,C,B} and D: {B,A,C,D}
> - injects a merge event in each of channels A,B,C,D representing these four views
> - checks that all channels have the final view of size 4
> The test fails intermittently on RHEL, with the same failure each time:
> {noformat}
> 181595 [DEBUG] GMS: - A: installing view [A|2] [A]
>    [testng] 181596 [TRACE] GMS: - A: received all 1 ACKs from members for view [A|2]
>    [testng] 181866 [TRACE] GMS: - view [A|3] [] is empty: will not multicast it (last view)
>    [testng] 
>    [testng] -------------------------------------------------------------------
>    [testng] GMS: address=A, cluster=OverlappingMergeTest, physical address=10.16.94.42:27199
>    [testng] -------------------------------------------------------------------
>    [testng] 184954 [TRACE] GMS: - A: no initial members discovered: creating group as first member
>    [testng] 184954 [DEBUG] GMS: - A: installing view [A|0] [A]
>    [testng] 184955 [DEBUG] GMS: - created group (first member). My view is [A|0], impl is org.jgroups.protocols.pbcast.CoordGmsImpl
>    [testng] 
>    [testng] -------------------------------------------------------------------
>    [testng] GMS: address=B, cluster=OverlappingMergeTest, physical address=10.16.94.42:27200
>    [testng] -------------------------------------------------------------------
>    [testng] 184961 [TRACE] GMS: - B: initial_mbrs are A 
>    [testng] 184961 [DEBUG] GMS: - election results: {A=1}
>    [testng] 184961 [DEBUG] GMS: - sending JOIN(B) to A
>    [testng] 185013 [TRACE] GMS: - A: new members=[B], suspected=[], leaving=[], new view: [A|1] [A, B]
>    [testng] 185014 [TRACE] GMS: - A: mcasting view [A|1] [A, B] (2 mbrs)
>    [testng] 
>    [testng] 185025 [DEBUG] GMS: - A: installing view [A|1] [A, B]
>    [testng] 185026 [TRACE] GMS: - A: received all 1 ACKs from members for view [A|1]
>    [testng] 185055 [TRACE] GMS: - B: JOIN-RSP=[A|1] [A, B] [size=2]
>    [testng] 
>    [testng] 
>    [testng] 185055 [DEBUG] GMS: - B: installing view [A|1] [A, B]
>    [testng] 185057 [TRACE] GMS: - A: received all ACKs (1) from joiners for view [A|1]
>    [testng] 
>    [testng] -------------------------------------------------------------------
>    [testng] GMS: address=C, cluster=OverlappingMergeTest, physical address=10.16.94.42:27201
>    [testng] -------------------------------------------------------------------
>    [testng] 185064 [TRACE] GMS: - C: initial_mbrs are B A 
>    [testng] 185064 [DEBUG] GMS: - election results: {A=2}
>    [testng] 185064 [DEBUG] GMS: - sending JOIN(C) to A
>    [testng] 185108 [TRACE] GMS: - A: new members=[C], suspected=[], leaving=[], new view: [A|2] [A, B, C]
>    [testng] 185108 [TRACE] GMS: - A: mcasting view [A|2] [A, B, C] (3 mbrs)
>    [testng] 
>    [testng] 185117 [DEBUG] GMS: - A: installing view [A|2] [A, B, C]
>    [testng] 185118 [DEBUG] GMS: - B: installing view [A|2] [A, B, C]
>    [testng] 185119 [TRACE] GMS: - A: received all 2 ACKs from members for view [A|2]
>    [testng] 185148 [TRACE] GMS: - C: JOIN-RSP=[A|2] [A, B, C] [size=3]
>    [testng] 
>    [testng] 
>    [testng] 185149 [DEBUG] GMS: - C: installing view [A|2] [A, B, C]
>    [testng] 185151 [TRACE] GMS: - A: received all ACKs (1) from joiners for view [A|2]
>    [testng] 
>    [testng] -------------------------------------------------------------------
>    [testng] GMS: address=D, cluster=OverlappingMergeTest, physical address=10.16.94.42:27202
>    [testng] -------------------------------------------------------------------
>    [testng] 185164 [TRACE] GMS: - D: initial_mbrs are B C A 
>    [testng] 185164 [DEBUG] GMS: - election results: {A=3}
>    [testng] 185164 [DEBUG] GMS: - sending JOIN(D) to A
>    [testng] 185203 [TRACE] GMS: - A: new members=[D], suspected=[], leaving=[], new view: [A|3] [A, B, C, D]
>    [testng] 185203 [TRACE] GMS: - A: mcasting view [A|3] [A, B, C, D] (4 mbrs)
>    [testng] 
>    [testng] 185210 [DEBUG] GMS: - A: installing view [A|3] [A, B, C, D]
>    [testng] 185211 [DEBUG] GMS: - B: installing view [A|3] [A, B, C, D]
>    [testng] 185211 [DEBUG] GMS: - C: installing view [A|3] [A, B, C, D]
>    [testng] 185213 [TRACE] GMS: - A: received all 3 ACKs from members for view [A|3]
>    [testng] 185242 [TRACE] GMS: - D: JOIN-RSP=[A|3] [A, B, C, D] [size=4]
>    [testng] 
>    [testng] 
>    [testng] 185242 [DEBUG] GMS: - D: installing view [A|3] [A, B, C, D]
>    [testng] 185242 [TRACE] GMS: - A: received all ACKs (1) from joiners for view [A|3]
>    [testng] 
>    [testng]  ==== Injecting view [A|4] [A, C, B] into A, B and C ====
>    [testng] 185243 [DEBUG] GMS: - A: installing view [A|4] [A, C, B]
>    [testng] 185243 [DEBUG] GMS: - B: installing view [A|4] [A, C, B]
>    [testng] 185244 [DEBUG] GMS: - C: installing view [A|4] [A, C, B]
>    [testng] 
>    [testng]  ==== Injecting view [B|4] [B, A, C, D] into D ====
>    [testng] 
>    [testng] 185245 [DEBUG] GMS: - D: installing view [B|4] [B, A, C, D]
>    [testng] A: [A|4] [A, C, B]
>    [testng] B: [A|4] [A, C, B]
>    [testng] C: [A|4] [A, C, B]
>    [testng] D: [B|4] [B, A, C, D]
>    [testng] 
>    [testng] ==== Injecting a merge event into A, B, C and D====
>    [testng] 185251 [TRACE] GMS: - A: got merge response from A, merge_id=A::3, merge data is sender=A, view=[A|4] [A, C, B], digest=C: [0 (0)], B: [0 (0)], A: [4 (4)]
>    [testng] 185253 [TRACE] GMS: - B: queue is suspended; request MERGE(4 views) is discarded
>    [testng] 185255 [TRACE] GMS: - C: queue is suspended; request MERGE(4 views) is discarded
>    [testng] 185255 [TRACE] GMS: - A: got merge response from B, merge_id=A::3, merge data is sender=B, view=[A|4] [A, C, B], digest=C: [0 (0)], B: [0 (1)], A: [4 (4)]
>    [testng] 190286 [TRACE] GMS: - A: mcasting view MergeView::[A|5] [A, B, C], subgroups=[A|4] [A, C, B], [A|4] [A, C, B] (3 mbrs)
>    [testng] 
>    [testng] 190286 [TRACE] GMS: - B: mcasting view MergeView::[A|5] [A, B, C], subgroups=[A|4] [A, C, B], [A|4] [A, C, B] (3 mbrs)
>    [testng] 
>    [testng] 190317 [DEBUG] GMS: - A: installing view MergeView::[A|5] [A, B, C], subgroups=[A|4] [A, C, B], [A|4] [A, C, B]
>    [testng] 190318 [DEBUG] GMS: - B: installing view MergeView::[A|5] [A, B, C], subgroups=[A|4] [A, C, B], [A|4] [A, C, B]
>    [testng] 190318 [DEBUG] GMS: - C: installing view MergeView::[A|5] [A, B, C], subgroups=[A|4] [A, C, B], [A|4] [A, C, B]
>    [testng] 190320 [TRACE] GMS: - A: received all 3 ACKs from members for view [A|5]
>    [testng] 190320 [TRACE] GMS: - B: received all 3 ACKs from members for view [A|5]
>    [testng] A: [A|5] [A, B, C] (coord=true)
>    [testng] B: [A|5] [A, B, C] (coord=false)
>    [testng] C: [A|5] [A, B, C] (coord=false)
>    [testng] D: [B|4] [B, A, C, D] (coord=false)
>    [testng] 195277 [DEBUG] GMS: - D: sending LEAVE request to B
>    [testng] FAIL: [1] org.jgroups.tests.OverlappingMergeTest.testMergeWithDifferentPartitions()
> {noformat}
>  Whenever this test fails, I see that the queues are suspended on the initial merge attempt.

--
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

From issues at jboss.org  Wed Mar  5 15:19:33 2014
From: issues at jboss.org (Bela Ban (JIRA))
Date: Wed, 5 Mar 2014 15:19:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1801) DuplicateTest fails when
 testing OOB multicast to all three senders
In-Reply-To: <JIRA.12533765.1393853856000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12533765.1393853856000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12533765.1393853856000.6762.1394050773835@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JGRP-1801?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban updated JGRP-1801:
---------------------------

    Fix Version/s:     (was: 3.5)


I removed the 3.5 target. Should the issue get fixed in 3.2.x, we can still forward-port it to master (3.5) if it exists in master.
                
> DuplicateTest fails when testing OOB multicast to all three senders
> -------------------------------------------------------------------
>
>                 Key: JGRP-1801
>                 URL: https://issues.jboss.org/browse/JGRP-1801
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.2.13
>         Environment: Windows (18), Solaris (2), RHEL(1) where (x) is the number of failures seen
>            Reporter: Richard Achmatowicz
>            Assignee: Bela Ban
>             Fix For: 3.2.13
>
>
> DuplicateTest does the following:
> - creates three channels containing the DUPL layer called c1, c2, c3
> - DUPL is used to duplicate messages sent
> - channel receiver for channel each keeps a map of messages received from each sender
> - channels send messages: regular, OOB, or mixed
> - the test checks that the messages received  by each channel are correct in number and in order
> The test testOOBMuloticastToAll3Senders is failing regularly on multple platforms. The test makes each of the channels send OOB multicast messages to the group, but only two of three members ever end up receiving the multicast messages. Al example of the failure:
> {noformat}
> Error Message
> expected size=3, msgs: [C2, C1]
> Stacktrace
> java.lang.AssertionError 
> at org.jgroups.tests.DuplicateTest.check(DuplicateTest.java:217) 
> at org.jgroups.tests.DuplicateTest.testOOBMulticastToAll3Senders(DuplicateTest.java:123) 
> {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

From issues at jboss.org  Wed Mar  5 15:29:33 2014
From: issues at jboss.org (Stuart Douglas (JIRA))
Date: Wed, 5 Mar 2014 15:29:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3073) MBeanServer.createMBean
 methods that take a classloader don't work
In-Reply-To: <JIRA.12534226.1394051286942@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534226.1394051286942@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534226.1394051286942.6774.1394051373202@jira02.app.mwc.hst.phx2.redhat.com>

Stuart Douglas created WFLY-3073:
------------------------------------

             Summary: MBeanServer.createMBean methods that take a classloader don't work
                 Key: WFLY-3073
                 URL: https://issues.jboss.org/browse/WFLY-3073
             Project: WildFly
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: JMX
    Affects Versions: 8.0.0.Final
            Reporter: Stuart Douglas
            Assignee: Kabir Khan
             Fix For: 8.0.1.Final


The MBeanServer.createMBean methods that take an "ObjectName loaderName" argument are completely broken in EAP 6.

These methods call findDelegate to make sure there is already an existing MBean registered with the given name passed in for the new MBean, or else it throws an exception.
This is obviously wrong, as there'd be no point in calling createMBean if it already existed.

javax.management.InstanceNotFoundException: test:service=Test
at org.jboss.as.jmx.PluggableMBeanServerImpl.findDelegate(PluggableMBeanServerImpl.java:1083)
at org.jboss.as.jmx.PluggableMBeanServerImpl.createMBean(PluggableMBeanServerImpl.java:253)

--
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

From issues at jboss.org  Wed Mar  5 15:31:33 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 5 Mar 2014 15:31:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3073) MBeanServer.createMBean
 methods that take a classloader don't work
In-Reply-To: <JIRA.12534226.1394051286000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534226.1394051286000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534226.1394051286000.6777.1394051493167@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-3073?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated WFLY-3073:
------------------------------------------

        Bugzilla Update: Perform
    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1073106

    
> MBeanServer.createMBean methods that take a classloader don't work
> ------------------------------------------------------------------
>
>                 Key: WFLY-3073
>                 URL: https://issues.jboss.org/browse/WFLY-3073
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JMX
>    Affects Versions: 8.0.0.Final
>            Reporter: Stuart Douglas
>            Assignee: Kabir Khan
>             Fix For: 8.0.1.Final
>
>
> The MBeanServer.createMBean methods that take an "ObjectName loaderName" argument are completely broken in EAP 6.
> These methods call findDelegate to make sure there is already an existing MBean registered with the given name passed in for the new MBean, or else it throws an exception.
> This is obviously wrong, as there'd be no point in calling createMBean if it already existed.
> javax.management.InstanceNotFoundException: test:service=Test
> at org.jboss.as.jmx.PluggableMBeanServerImpl.findDelegate(PluggableMBeanServerImpl.java:1083)
> at org.jboss.as.jmx.PluggableMBeanServerImpl.createMBean(PluggableMBeanServerImpl.java:253)

--
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

From issues at jboss.org  Wed Mar  5 15:55:33 2014
From: issues at jboss.org (Stuart Douglas (JIRA))
Date: Wed, 5 Mar 2014 15:55:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3067) Annotations from .ear/lib are
 not visible to DUPs when processing subdeployments
In-Reply-To: <JIRA.12534077.1393987223000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534077.1393987223000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534077.1393987223000.6831.1394052933295@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-3067?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12950447#comment-12950447 ] 

Stuart Douglas commented on WFLY-3067:
--------------------------------------

This should be fixed by changing the webservices subsystem to use EEModuleClassDescription.
                
> Annotations from .ear/lib are not visible to DUPs when processing subdeployments
> --------------------------------------------------------------------------------
>
>                 Key: WFLY-3067
>                 URL: https://issues.jboss.org/browse/WFLY-3067
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Class Loading
>    Affects Versions: 8.0.0.Final
>            Reporter: Kyle Lape
>            Assignee: David Lloyd
>
> Sample use case:  You have a .war in an .ear, and the .war has a web.xml with a {{<servlet-class>}} that refers to a JAX-WS endpoint, so the class is annotated with {{@WebService}}.  If that class is packaged in a jar found in the ear's lib directory, the JBossWS DUP won't pick it up, and then Undertow will throw an error like this:
> {noformat}
> UT010009: Servlet ClientEndpoint of type class com.redhat.gss.jaxws.ClientEndpoint does not implement javax.servlet.Servlet
> {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

From issues at jboss.org  Wed Mar  5 16:17:33 2014
From: issues at jboss.org (Ron Sigal (JIRA))
Date: Wed, 5 Mar 2014 16:17:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JBWEB-291) Add
 org.apache.catalina.connector.Request.asyncTimeout parameter
In-Reply-To: <JIRA.12534227.1394054245340@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534227.1394054245340@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534227.1394054245340.6848.1394054253527@jira02.app.mwc.hst.phx2.redhat.com>

Ron Sigal created JBWEB-291:
-------------------------------

             Summary: Add org.apache.catalina.connector.Request.asyncTimeout parameter
                 Key: JBWEB-291
                 URL: https://issues.jboss.org/browse/JBWEB-291
             Project: JBoss Web
          Issue Type: Enhancement
      Security Level: Public (Everyone can see)
            Reporter: Ron Sigal
            Assignee: Remy Maucherat
            Priority: Minor


Resteasy has a @Suspend parameter that gives an asynchronous timeout value when it has a parameter, e.g., @Suspend(10000).  If it has no parameter, then the default asynchronous timeout of the container is used.  For example, Jetty 8 has a default value of 30000.  But JBoss Web has a default value of -1, so that an asynchronous request never times out.  

I've set the priority of this issue to Minor, since it affects only one of our test cases.  Someone else might need it for a real application, though.

--
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

From issues at jboss.org  Wed Mar  5 16:23:33 2014
From: issues at jboss.org (Scott Marlow (JIRA))
Date: Wed, 5 Mar 2014 16:23:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3074) Hibernate 3.x static module
	cannot be used
In-Reply-To: <JIRA.12534228.1394054554984@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534228.1394054554984@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534228.1394054554984.6865.1394054613162@jira02.app.mwc.hst.phx2.redhat.com>

Scott Marlow created WFLY-3074:
----------------------------------

             Summary: Hibernate 3.x static module cannot be used
                 Key: WFLY-3074
                 URL: https://issues.jboss.org/browse/WFLY-3074
             Project: WildFly
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: JPA / Hibernate
    Affects Versions: 8.0.0.Final
            Reporter: Scott Marlow
            Assignee: Scott Marlow
             Fix For: 8.0.1.Final


See forum reference for details.  Workaround is to bundle Hibernate 3 jars with application.

--
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

From issues at jboss.org  Wed Mar  5 16:29:33 2014
From: issues at jboss.org (Stuart Douglas (JIRA))
Date: Wed, 5 Mar 2014 16:29:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3036) Forwarded POST request
 becomes a GET request
In-Reply-To: <JIRA.12533536.1393522682000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12533536.1393522682000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12533536.1393522682000.6885.1394054973483@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-3036?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stuart Douglas resolved WFLY-3036.
----------------------------------

    Fix Version/s: 8.0.1.Final
       Resolution: Done

    
> Forwarded POST request becomes a GET request
> --------------------------------------------
>
>                 Key: WFLY-3036
>                 URL: https://issues.jboss.org/browse/WFLY-3036
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web (Undertow)
>    Affects Versions: 8.0.0.Final
>            Reporter: Matti Tahvonen
>            Assignee: Stuart Douglas
>             Fix For: 8.0.1.Final
>
>
> POST requests that get forwarded (at least due to <security-constraint> rule) are reported as GET requests when the request arrives to the destination.
> Now e.g. Vaadin login UI that sends POST request (XHR) to the "original" address dies as Vaadin servlet returns html instead of JSON. 
> The same setup works in JBoss 7.1 and Glassfish.
> The issue (and workaround) is describe in the github project:
> https://github.com/mstahv/vaadin-cdi-jaas-jbossas-example/

--
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

From issues at jboss.org  Wed Mar  5 16:29:33 2014
From: issues at jboss.org (Stuart Douglas (JIRA))
Date: Wed, 5 Mar 2014 16:29:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2969) WildFly 8/Undertow 1 handles
 URL fragments differently than JBoss EAP 6.2/Apache-Coyote/1.1
In-Reply-To: <JIRA.12532713.1392830330000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12532713.1392830330000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12532713.1392830330000.6887.1394054973584@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2969?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stuart Douglas resolved WFLY-2969.
----------------------------------

    Fix Version/s: 8.0.1.Final
       Resolution: Done

    
> WildFly 8/Undertow 1 handles URL fragments differently than JBoss EAP 6.2/Apache-Coyote/1.1
> -------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2969
>                 URL: https://issues.jboss.org/browse/WFLY-2969
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web (Undertow)
>    Affects Versions: 8.0.0.Final
>            Reporter: Michal Babacek
>            Assignee: Stuart Douglas
>            Priority: Minor
>             Fix For: 8.0.1.Final
>
>
> I have a bunch of URL tests, executed against EAP 6.2.0 directly and then proxied through mod_cluster 1.2.6. These all pass.
> I tried to run the same with {{Wildfly-8.0.1.Final-SNAPSHOT, HEAD:be3a13e6}} with a surprising result of seeing some differences in how are various Request attributes reported from within the servlet:
> Here we go,{{8080}} is where either EAP or WFLY listens:
> || ||{{curl 'http://10.16.88.19:8080/clusterbench/requestinfo//?;?=44&test=OK;devil=3&&&&&&&&&&&&&&&&&&&&&&&&&&&&777=666'}}||
> |EAP|Parameters map: {test=OK;devil=3, 777=666, ;?=44}|
> |WFY|Parameters map: {=, 777=666, test=OK;devil=3, ;?=44}|
> *Note:* {{Parameters map: \{key=value, key=value, ..., ...\}}}, so there is like an empty key and and empty value for WFLY....
> This is the [CommonRequestInfoServlet.java|https://github.com/Karm/clusterbench/blob/simplified-and-pure/clusterbench-common/src/main/java/org/jboss/test/clusterbench/common/jvmroute/CommonRequestInfoServlet.java] that produced the output.
> {code}
>     Map params = request.getParameterMap();
>     Iterator i = params.keySet().iterator();
>     while (i.hasNext()) {
>       String key = (String) i.next();
>       String value = ((String[]) params.get(key))[0];
>       responseText.append(key);
>       responseText.append("=");
>       responseText.append(value);
>       if (i.hasNext()) responseText.append(", ");
>     }
> {code}
> It is, indeed, possible that these mangled URLs are slipping through the cracks of [RFC|http://tools.ietf.org/html/rfc3986] and should be either "fixed" or URL encoded, yet I find the different interpretations disturbing.

--
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

From issues at jboss.org  Wed Mar  5 16:35:33 2014
From: issues at jboss.org (James Perkins (JIRA))
Date: Wed, 5 Mar 2014 16:35:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2959) Downgrade Jackson dependency
In-Reply-To: <JIRA.12532567.1392747430000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12532567.1392747430000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12532567.1392747430000.6895.1394055333316@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2959?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12950456#comment-12950456 ] 

James Perkins commented on WFLY-2959:
-------------------------------------

I got this to work with 2.2.3. I noticed that for some reason {{com.fasterxml.jackson.datatype:jackson-datatype-hibernate4:2.2.3}} has a dependency on 2.3.x versions of {{com.fasterxml.jackson.core:jackson-core}} and {{com.fasterxml.jackson.core:jackson-databind}}.

I changed the version in the POM and added some exclusions and new dependencies and it worked.

{code:xml}
        <dependency>
            <groupId>com.fasterxml.jackson.core</groupId>
            <artifactId>jackson-core</artifactId>
            <scope>provided</scope>
        </dependency>
        <dependency>
            <groupId>com.fasterxml.jackson.core</groupId>
            <artifactId>jackson-databind</artifactId>
            <scope>provided</scope>
        </dependency>
        <dependency>
            <groupId>com.fasterxml.jackson.core</groupId>
            <artifactId>jackson-annotations</artifactId>
            <scope>provided</scope>
        </dependency>

        <dependency>
            <groupId>com.fasterxml.jackson.datatype</groupId>
            <artifactId>jackson-datatype-hibernate4</artifactId>
            <version>2.2.3</version>
            <scope>compile</scope>
            <exclusions>
                <exclusion>
                    <groupId>com.fasterxml.jackson.core</groupId>
                    <artifactId>jackson-core</artifactId>
                </exclusion>
                <exclusion>
                    <groupId>com.fasterxml.jackson.core</groupId>
                    <artifactId>jackson-databind</artifactId>
                </exclusion>
                <exclusion>
                    <groupId>com.fasterxml.jackson.core</groupId>
                    <artifactId>jackson-annotations</artifactId>
                </exclusion>
            </exclusions>
        </dependency>
{code}
                
> Downgrade Jackson dependency
> ----------------------------
>
>                 Key: WFLY-2959
>                 URL: https://issues.jboss.org/browse/WFLY-2959
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: REST
>    Affects Versions: 8.0.0.Final
>            Reporter: James Perkins
>            Assignee: James Perkins
>             Fix For: 8.0.1.Final
>
>         Attachments: org.jboss.test.test-jackson.tar.gz, org.jboss.test.test-jackson.tar.gz
>
>
> Jackson was upgraded to 2.3.0 which contains a [bug|https://github.com/FasterXML/jackson-jaxrs-providers/commit/bafb6fb64bc15482c7bfc56784169204d6c4b1f2#commitcomment-5224156] that breaks RESTEasy. RESTEasy currently uses 2.2.1. Downgrading to at least 2.2.3, which is what CR1 is at, seems to resolve this issue.
> We should likely keep the version aligned with RESTEasy, but since CR1 was using 2.2.3 with no issues, I think reverting back to that should be fine.

--
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

From issues at jboss.org  Wed Mar  5 16:37:33 2014
From: issues at jboss.org (James Perkins (JIRA))
Date: Wed, 5 Mar 2014 16:37:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2959) Downgrade Jackson dependency
In-Reply-To: <JIRA.12532567.1392747430000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12532567.1392747430000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12532567.1392747430000.6899.1394055453247@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2959?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12950456#comment-12950456 ] 

James Perkins edited comment on WFLY-2959 at 3/5/14 4:35 PM:
-------------------------------------------------------------

I got this to work with 2.2.3. I noticed that for some reason {{com.fasterxml.jackson.datatype:jackson-datatype-hibernate4:2.2.3}} has a dependency on 2.3.x versions of {{com.fasterxml.jackson.core:jackson-core}} and {{com.fasterxml.jackson.core:jackson-databind}}.

I changed the version in the POM and added some exclusions and new dependencies and it worked.

{code:xml}
        <dependency>
            <groupId>com.fasterxml.jackson.core</groupId>
            <artifactId>jackson-core</artifactId>
            <scope>provided</scope>
        </dependency>
        <dependency>
            <groupId>com.fasterxml.jackson.core</groupId>
            <artifactId>jackson-databind</artifactId>
            <scope>provided</scope>
        </dependency>
        <dependency>
            <groupId>com.fasterxml.jackson.core</groupId>
            <artifactId>jackson-annotations</artifactId>
            <scope>provided</scope>
        </dependency>

        <dependency>
            <groupId>com.fasterxml.jackson.datatype</groupId>
            <artifactId>jackson-datatype-hibernate4</artifactId>
            <version>2.2.3</version>
            <scope>compile</scope>
            <exclusions>
                <exclusion>
                    <groupId>com.fasterxml.jackson.core</groupId>
                    <artifactId>jackson-core</artifactId>
                </exclusion>
                <exclusion>
                    <groupId>com.fasterxml.jackson.core</groupId>
                    <artifactId>jackson-databind</artifactId>
                </exclusion>
                <exclusion>
                    <groupId>com.fasterxml.jackson.core</groupId>
                    <artifactId>jackson-annotations</artifactId>
                </exclusion>
            </exclusions>
        </dependency>
{code}

The result was
{code}
[
    {
        personId: "df53104a-d5fa-42ff-a15d-d69900e27dfa",
        personFirstName: "Bob",
        personLastName: "Bob",
        personAddresses: null
    }
]
{code}
                
      was (Author: jamezp):
    I got this to work with 2.2.3. I noticed that for some reason {{com.fasterxml.jackson.datatype:jackson-datatype-hibernate4:2.2.3}} has a dependency on 2.3.x versions of {{com.fasterxml.jackson.core:jackson-core}} and {{com.fasterxml.jackson.core:jackson-databind}}.

I changed the version in the POM and added some exclusions and new dependencies and it worked.

{code:xml}
        <dependency>
            <groupId>com.fasterxml.jackson.core</groupId>
            <artifactId>jackson-core</artifactId>
            <scope>provided</scope>
        </dependency>
        <dependency>
            <groupId>com.fasterxml.jackson.core</groupId>
            <artifactId>jackson-databind</artifactId>
            <scope>provided</scope>
        </dependency>
        <dependency>
            <groupId>com.fasterxml.jackson.core</groupId>
            <artifactId>jackson-annotations</artifactId>
            <scope>provided</scope>
        </dependency>

        <dependency>
            <groupId>com.fasterxml.jackson.datatype</groupId>
            <artifactId>jackson-datatype-hibernate4</artifactId>
            <version>2.2.3</version>
            <scope>compile</scope>
            <exclusions>
                <exclusion>
                    <groupId>com.fasterxml.jackson.core</groupId>
                    <artifactId>jackson-core</artifactId>
                </exclusion>
                <exclusion>
                    <groupId>com.fasterxml.jackson.core</groupId>
                    <artifactId>jackson-databind</artifactId>
                </exclusion>
                <exclusion>
                    <groupId>com.fasterxml.jackson.core</groupId>
                    <artifactId>jackson-annotations</artifactId>
                </exclusion>
            </exclusions>
        </dependency>
{code}
                  
> Downgrade Jackson dependency
> ----------------------------
>
>                 Key: WFLY-2959
>                 URL: https://issues.jboss.org/browse/WFLY-2959
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: REST
>    Affects Versions: 8.0.0.Final
>            Reporter: James Perkins
>            Assignee: James Perkins
>             Fix For: 8.0.1.Final
>
>         Attachments: org.jboss.test.test-jackson.tar.gz, org.jboss.test.test-jackson.tar.gz
>
>
> Jackson was upgraded to 2.3.0 which contains a [bug|https://github.com/FasterXML/jackson-jaxrs-providers/commit/bafb6fb64bc15482c7bfc56784169204d6c4b1f2#commitcomment-5224156] that breaks RESTEasy. RESTEasy currently uses 2.2.1. Downgrading to at least 2.2.3, which is what CR1 is at, seems to resolve this issue.
> We should likely keep the version aligned with RESTEasy, but since CR1 was using 2.2.3 with no issues, I think reverting back to that should be fine.

--
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

From issues at jboss.org  Wed Mar  5 16:39:33 2014
From: issues at jboss.org (James Perkins (JIRA))
Date: Wed, 5 Mar 2014 16:39:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2959) Downgrade Jackson dependency
In-Reply-To: <JIRA.12532567.1392747430000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12532567.1392747430000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12532567.1392747430000.6905.1394055573284@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2959?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12950457#comment-12950457 ] 

James Perkins commented on WFLY-2959:
-------------------------------------

Also I had no luck getting 2.3.2 working. I still get a {{NoSuchMethodError}} from RESTEasy/Jackson2.
                
> Downgrade Jackson dependency
> ----------------------------
>
>                 Key: WFLY-2959
>                 URL: https://issues.jboss.org/browse/WFLY-2959
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: REST
>    Affects Versions: 8.0.0.Final
>            Reporter: James Perkins
>            Assignee: James Perkins
>             Fix For: 8.0.1.Final
>
>         Attachments: org.jboss.test.test-jackson.tar.gz, org.jboss.test.test-jackson.tar.gz
>
>
> Jackson was upgraded to 2.3.0 which contains a [bug|https://github.com/FasterXML/jackson-jaxrs-providers/commit/bafb6fb64bc15482c7bfc56784169204d6c4b1f2#commitcomment-5224156] that breaks RESTEasy. RESTEasy currently uses 2.2.1. Downgrading to at least 2.2.3, which is what CR1 is at, seems to resolve this issue.
> We should likely keep the version aligned with RESTEasy, but since CR1 was using 2.2.3 with no issues, I think reverting back to that should be fine.

--
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

From issues at jboss.org  Wed Mar  5 16:53:33 2014
From: issues at jboss.org (Richard Achmatowicz (JIRA))
Date: Wed, 5 Mar 2014 16:53:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1799) RpcDispatcher test fails when
 working with large values
In-Reply-To: <JIRA.12533122.1393254868000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12533122.1393254868000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12533122.1393254868000.6914.1394056413196@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JGRP-1799?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12950460#comment-12950460 ] 

Richard Achmatowicz commented on JGRP-1799:
-------------------------------------------

One reason why the test is failing is that with ever larger values, the RPC call times out:

{noformat}
testing with 10000 bytes
test took: 23 ms
rsps:
10000 bytes from B
10000 bytes from A
10000 bytes from C

testing with 20000 bytes
test took: 30 ms
rsps:
20000 bytes from B
20000 bytes from A
20000 bytes from C

testing with 40000 bytes
test took: 31 ms
rsps:
40000 bytes from B
40000 bytes from A
40000 bytes from C

testing with 80000 bytes
test took: 33 ms
rsps:
80000 bytes from B
80000 bytes from A
80000 bytes from C

testing with 100000 bytes
test took: 804 ms
rsps:
100000 bytes from B
100000 bytes from A
100000 bytes from C

testing with 200000 bytes
test took: 1001 ms
rsps:
200000 bytes from B
200000 bytes from A
200000 bytes from C

testing with 400000 bytes
test took: 1001 ms
rsps:
400000 bytes from B
400000 bytes from A
400000 bytes from C

testing with 800000 bytes
test took: 1793 ms
rsps:
800000 bytes from B
800000 bytes from A
800000 bytes from C

testing with 1000000 bytes
test took: 67 ms
rsps:
1000000 bytes from B
1000000 bytes from A
1000000 bytes from C

testing with 2000000 bytes
test took: 1944 ms
rsps:
2000000 bytes from B
2000000 bytes from A
2000000 bytes from C

testing with 5000000 bytes
test took: 1247 ms
rsps:
5000000 bytes from B
5000000 bytes from A
5000000 bytes from C

testing with 10000000 bytes
test took: 7970 ms
rsps:
10000000 bytes from B
10000000 bytes from A
10000000 bytes from C

testing with 20000000 bytes
test took: 12262 ms
rsps:
20000000 bytes from B
20000000 bytes from A
20000000 bytes from C

testing with 50000000 bytes
test took: 20001 ms
rsps:
50000000 bytes from B
50000000 bytes from A
java.lang.AssertionError
	at org.jgroups.blocks.RpcDispatcherTest._testLargeValue(RpcDispatcherTest.java:548)
	at org.jgroups.blocks.RpcDispatcherTest.testLargeReturnValue(RpcDispatcherTest.java:443)
{noformat}

I can quite easily reproduce this on my machine. The RPC call times out partway through processing and leaves an incomplete result. When I extend the timeout from 20 seconds to 30 seconds, the test passes.

We can probably eliminate these errors by extending the timeout from 20 seconds to 30 seconds to take account of slow machines.
I have also added in count of how many ms each RPC call takes, which helps to see why it may have failed (i.e. tool too long).

Bela, is extending the timeout something you would consider? 
                
> RpcDispatcher test fails when working with large values
> -------------------------------------------------------
>
>                 Key: JGRP-1799
>                 URL: https://issues.jboss.org/browse/JGRP-1799
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.2.13
>         Environment: RHEL, Win, Solaris
>            Reporter: Richard Achmatowicz
>            Assignee: Bela Ban
>             Fix For: 3.2.13
>
>
> The two tests:
> * testLargeReturnValue
> * testLargeReturnValueUnicastCall
> make RPC calls with values which are increasingly large. 
> The values used are in this range:
> {noformat}
> SIZES={10000, 20000, 40000, 80000, 100000, 200000, 400000, 800000,1000000, 2000000, 5000000}
> {noformat}
> The tests have been see to fail with the values 1000000, 2000000 and 5000000, always with the same error in each case. 
> In the case of testLargeReturnValue, the test fails because one of the returned values from the RPC is null.
> In the case of testLargeReturnValueUnicastCall, the test fails due to a timeout while sending the RPC.
>  

--
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

From issues at jboss.org  Wed Mar  5 17:03:33 2014
From: issues at jboss.org (Davide Sottara (JIRA))
Date: Wed, 5 Mar 2014 17:03:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-441) drools-guvnor 5.5,
 declarative model, create more than one fact type,
 BPMN process does not load
In-Reply-To: <JIRA.12533209.1393317312000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12533209.1393317312000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12533209.1393317312000.6928.1394057013762@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/DROOLS-441?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12950463#comment-12950463 ] 

Davide Sottara commented on DROOLS-441:
---------------------------------------

Is the process using the classes from pkg2?
                
> drools-guvnor 5.5, declarative model, create more than one fact type, BPMN process does not load
> ------------------------------------------------------------------------------------------------
>
>                 Key: DROOLS-441
>                 URL: https://issues.jboss.org/browse/DROOLS-441
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.5.0.Final
>         Environment: Tomcat 6.0.35, jBPM 5.5.Final
>            Reporter: niraj gupta
>            Assignee: Mark Proctor
>              Labels: drools-guvnor
>
>  I am using ?drools-guvnor 5.5.0.Final? open source tool for designing the business process (BPMN2). I end up in an issue and looking for help. Following is the scenario
> I created a package then process then after build, deploy execute successfully. Now I came back to guvnor and made few changes in the process. Then after same build, deploy execute successfully. But now this time I am creating a declarative model having 2 facts, also modifying business process. Then after same build, deploy execute successfully. This time modified/latest business process doesn?t load into console. This is my problem.  However I trouble shoot and google following are my observations:
> ?	I am running this application in tomcat 6.0.35
> ?	It works perfectly with POJO Model Jar approach.
> ?	It works perfectly with declarative model but having single fact.
> ?	I am not seeing any exceptions either in UI or console logs

--
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


From issues at jboss.org  Wed Mar  5 17:05:33 2014
From: issues at jboss.org (Richard Achmatowicz (JIRA))
Date: Wed, 5 Mar 2014 17:05:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1799) RpcDispatcher test fails when
 working with large values
In-Reply-To: <JIRA.12533122.1393254868000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12533122.1393254868000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12533122.1393254868000.6940.1394057133583@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JGRP-1799?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Richard Achmatowicz updated JGRP-1799:
--------------------------------------

    Git Pull Request: https://github.com/belaban/JGroups/pull/128

    
> RpcDispatcher test fails when working with large values
> -------------------------------------------------------
>
>                 Key: JGRP-1799
>                 URL: https://issues.jboss.org/browse/JGRP-1799
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.2.13
>         Environment: RHEL, Win, Solaris
>            Reporter: Richard Achmatowicz
>            Assignee: Bela Ban
>             Fix For: 3.2.13
>
>
> The two tests:
> * testLargeReturnValue
> * testLargeReturnValueUnicastCall
> make RPC calls with values which are increasingly large. 
> The values used are in this range:
> {noformat}
> SIZES={10000, 20000, 40000, 80000, 100000, 200000, 400000, 800000,1000000, 2000000, 5000000}
> {noformat}
> The tests have been see to fail with the values 1000000, 2000000 and 5000000, always with the same error in each case. 
> In the case of testLargeReturnValue, the test fails because one of the returned values from the RPC is null.
> In the case of testLargeReturnValueUnicastCall, the test fails due to a timeout while sending the RPC.
>  

--
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

From issues at jboss.org  Wed Mar  5 17:05:33 2014
From: issues at jboss.org (Stuart Douglas (JIRA))
Date: Wed, 5 Mar 2014 17:05:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2935) WebSocket Session misses the
 UserProperties
In-Reply-To: <JIRA.12532175.1392367408000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12532175.1392367408000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12532175.1392367408000.6943.1394057133743@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2935?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stuart Douglas resolved WFLY-2935.
----------------------------------

    Fix Version/s: 8.0.1.Final
       Resolution: Done

    
> WebSocket Session misses the UserProperties
> -------------------------------------------
>
>                 Key: WFLY-2935
>                 URL: https://issues.jboss.org/browse/WFLY-2935
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web (Undertow)
>    Affects Versions: 8.0.0.Final
>            Reporter: Martin Grigorov
>            Assignee: Stuart Douglas
>            Priority: Minor
>             Fix For: 8.0.1.Final
>
>
> My application uses custom javax.websocket.server.ServerEndpointConfig to setup custom javax.websocket.server.ServerEndpointConfig.Configurator that collects some information from the HandshakeRequest in the session's UserProperties.
> With WFLY-2844 some problems have been fixed.
> But now I see that the UserProperties are not available (i.e. it is 'null') from Session#getUserProperties() in javax.websocket.Endpoint#onOpen(Session, EndpointConfig)

--
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

From issues at jboss.org  Wed Mar  5 18:09:33 2014
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Wed, 5 Mar 2014 18:09:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3031) Management audit logging logs
 parallel boot ops in separate records
In-Reply-To: <JIRA.12533452.1393460407000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12533452.1393460407000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12533452.1393460407000.6973.1394060973203@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-3031?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFLY-3031:
-----------------------------------

    Fix Version/s: 8.0.1.Final
                       (was: 9.0.0.CR1)

    
> Management audit logging logs parallel boot ops in separate records
> -------------------------------------------------------------------
>
>                 Key: WFLY-3031
>                 URL: https://issues.jboss.org/browse/WFLY-3031
>             Project: WildFly
>          Issue Type: Enhancement
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>    Affects Versions: 8.0.0.Final
>            Reporter: Brian Stansberry
>            Assignee: Brian Stansberry
>             Fix For: 8.0.1.Final
>
>
> The parallel boot ops (i.e. the subsystem stuff) are logged in separate log records from the other stuff.
> This is questionable because they are actually all part of the same execution. The main execution blocks for the parallel ops.

--
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

From issues at jboss.org  Wed Mar  5 18:11:39 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 5 Mar 2014 18:11:39 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2415) Add configuration option to
 enable/disable Infinispan statistics
In-Reply-To: <JIRA.12509131.1383157408000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12509131.1383157408000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12509131.1383157408000.6993.1394061099480@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2415?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12950476#comment-12950476 ] 

RH Bugzilla Integration commented on WFLY-2415:
-----------------------------------------------

Paul Gier <pgier at redhat.com> changed the Status of [bug 1025023|https://bugzilla.redhat.com/show_bug.cgi?id=1025023] from MODIFIED to ON_QA
                
> Add configuration option to enable/disable Infinispan statistics
> ----------------------------------------------------------------
>
>                 Key: WFLY-2415
>                 URL: https://issues.jboss.org/browse/WFLY-2415
>             Project: WildFly
>          Issue Type: Enhancement
>      Security Level: Public(Everyone can see) 
>          Components: Clustering
>            Reporter: Scott Marlow
>            Assignee: Paul Ferraro
>             Fix For: 8.0.0.CR1
>
>
> When the Infinispan MBean is enabled, Infinispan statistics are enabled by default.  Could we allow Infinispan statistics to be enabled/disabled via a WF configuration setting?

--
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

From issues at jboss.org  Wed Mar  5 18:11:39 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 5 Mar 2014 18:11:39 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2949) Cannot get exception as
	pass-by-reference
In-Reply-To: <JIRA.12532450.1392708507000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12532450.1392708507000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12532450.1392708507000.7000.1394061099804@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2949?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12950477#comment-12950477 ] 

RH Bugzilla Integration commented on WFLY-2949:
-----------------------------------------------

Paul Gier <pgier at redhat.com> changed the Status of [bug 1055896|https://bugzilla.redhat.com/show_bug.cgi?id=1055896] from MODIFIED to ON_QA
                
> Cannot get exception as pass-by-reference
> -----------------------------------------
>
>                 Key: WFLY-2949
>                 URL: https://issues.jboss.org/browse/WFLY-2949
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: EJB
>    Affects Versions: 8.0.0.Final
>            Reporter: Osamu Nagano
>            Assignee: David Lloyd
>             Fix For: 8.0.1.Final
>
>
> Despite of {{<in-vm-remote-interface-invocation pass-by-value="false"/>}}, an exception is not thrown by reference, which results in {{java.io.NotSerializableException}} if the exception doesn't implement {{Serializable}}.  This is a blocker of a large migration project from WebLogic because it throws by reference even if that doesn't implement {{Serializable}}.

--
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

From issues at jboss.org  Wed Mar  5 18:11:40 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 5 Mar 2014 18:11:40 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2899) Help and error messages in
 Main classes should be printed raw
In-Reply-To: <JIRA.12531680.1392076590000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12531680.1392076590000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12531680.1392076590000.7013.1394061100381@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2899?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12950480#comment-12950480 ] 

RH Bugzilla Integration commented on WFLY-2899:
-----------------------------------------------

Paul Gier <pgier at redhat.com> changed the Status of [bug 1069514|https://bugzilla.redhat.com/show_bug.cgi?id=1069514] from MODIFIED to ON_QA
                
> Help and error messages in Main classes should be printed raw
> -------------------------------------------------------------
>
>                 Key: WFLY-2899
>                 URL: https://issues.jboss.org/browse/WFLY-2899
>             Project: WildFly
>          Issue Type: Enhancement
>      Security Level: Public(Everyone can see) 
>          Components: Logging
>            Reporter: James Perkins
>            Assignee: James Perkins
>            Priority: Minor
>             Fix For: 8.0.1.Final
>
>
> The help in standalone and host-controller main methods gets printed after {{System.out}} and {{System.err}} have been captured by jboss-stdio. This leads the help and errors being printed in a log manager format rather than just the raw text.
> Example output:
> {code}
> [jperkins at jperkins-rh wildfly]$ ./build/target/wildfly-8.0.0.Final-SNAPSHOT/bin/standalone.sh -help
> =========================================================================
>   JBoss Bootstrap Environment
>   JBOSS_HOME: /home/jperkins/projects/jboss/as/wildfly/build/target/wildfly-8.0.0.Final-SNAPSHOT
>   JAVA: java
>   JAVA_OPTS:  -server -XX:+UseCompressedOops -Xms64m -Xmx512m -XX:MaxPermSize=256m -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true
> =========================================================================
> 15:31:43,895 INFO  [org.jboss.modules] (main) JBoss Modules version 1.3.0.Final
> 15:31:44,918 INFO  [stdout] (main) 
> 15:31:44,918 INFO  [stdout] (main) Usage: standalone.sh [args...]
> 15:31:44,918 INFO  [stdout] (main) where args include:
> 15:31:44,918 INFO  [stdout] (main)     --admin-only                        Set the server's running type to 
> 15:31:44,919 INFO  [stdout] (main)                                         ADMIN_ONLY causing it to open 
> 15:31:44,919 INFO  [stdout] (main)                                         administrative interfaces and accept 
> 15:31:44,919 INFO  [stdout] (main)                                         management requests but not start other 
> 15:31:44,920 INFO  [stdout] (main)                                         runtime services or accept end user 
> 15:31:44,920 INFO  [stdout] (main)                                         requests.
> 15:31:44,920 INFO  [stdout] (main) 
> 15:31:44,920 INFO  [stdout] (main) 
> 15:31:44,921 INFO  [stdout] (main)     -b <value>, -b=<value>              Set system property jboss.bind.address 
> 15:31:44,921 INFO  [stdout] (main)                                         to the given value
> 15:31:44,921 INFO  [stdout] (main) 
> 15:31:44,921 INFO  [stdout] (main) 
> 15:31:44,922 INFO  [stdout] (main)     -b<interface>=<value>               Set system property 
> 15:31:44,922 INFO  [stdout] (main)                                         jboss.bind.address.<interface> to the 
> 15:31:44,922 INFO  [stdout] (main)                                         given value
> 15:31:44,922 INFO  [stdout] (main) 
> 15:31:44,923 INFO  [stdout] (main) 
> 15:31:44,923 INFO  [stdout] (main)     -c <config>, -c=<config>            Name of the server configuration file 
> 15:31:44,923 INFO  [stdout] (main)                                         to use (default is "standalone.xml") 
> 15:31:44,923 INFO  [stdout] (main)                                         (Same as --server-config)
> 15:31:44,924 INFO  [stdout] (main) 
> 15:31:44,924 INFO  [stdout] (main) 
> 15:31:44,924 INFO  [stdout] (main)     --debug [<port>]                    Activate debug mode with an optional 
> 15:31:44,924 INFO  [stdout] (main)                                         argument to specify the port. Only 
> 15:31:44,925 INFO  [stdout] (main)                                         works if the launch script supports it.
> 15:31:44,925 INFO  [stdout] (main) 
> 15:31:44,925 INFO  [stdout] (main) 
> 15:31:44,925 INFO  [stdout] (main)     -D<name>[=<value>]                  Set a system property
> 15:31:44,926 INFO  [stdout] (main) 
> 15:31:44,926 INFO  [stdout] (main) 
> 15:31:44,926 INFO  [stdout] (main)     -h, --help                          Display this message and exit
> 15:31:44,927 INFO  [stdout] (main) 
> 15:31:44,927 INFO  [stdout] (main) 
> 15:31:44,927 INFO  [stdout] (main)     --read-only-server-config=<config>  Name of the server configuration file 
> 15:31:44,927 INFO  [stdout] (main)                                         to use. This differs from 
> 15:31:44,928 INFO  [stdout] (main)                                         '--server-config' and '-c' in that the 
> 15:31:44,928 INFO  [stdout] (main)                                         original file is never overwritten.
> 15:31:44,928 INFO  [stdout] (main) 
> 15:31:44,928 INFO  [stdout] (main) 
> 15:31:44,929 INFO  [stdout] (main)     -P <url>, -P=<url>,                 Load system properties from the given 
> 15:31:44,929 INFO  [stdout] (main)          --properties=<url>             url
> 15:31:44,929 INFO  [stdout] (main) 
> 15:31:44,929 INFO  [stdout] (main) 
> 15:31:44,930 INFO  [stdout] (main)     -S<name>[=<value>]                  Set a security property
> 15:31:44,930 INFO  [stdout] (main) 
> 15:31:44,930 INFO  [stdout] (main) 
> 15:31:44,930 INFO  [stdout] (main)     --server-config=<config>            Name of the server configuration file 
> 15:31:44,931 INFO  [stdout] (main)                                         to use (default is "standalone.xml") 
> 15:31:44,931 INFO  [stdout] (main)                                         (Same as -c)
> 15:31:44,931 INFO  [stdout] (main) 
> 15:31:44,931 INFO  [stdout] (main) 
> 15:31:44,932 INFO  [stdout] (main)     -u <value>, -u=<value>              Set system property 
> 15:31:44,932 INFO  [stdout] (main)                                         jboss.default.multicast.address to the 
> 15:31:44,932 INFO  [stdout] (main)                                         given value
> 15:31:44,933 INFO  [stdout] (main) 
> 15:31:44,933 INFO  [stdout] (main) 
> 15:31:44,933 INFO  [stdout] (main)     -v, -V, --version                   Print version and exit
> 15:31:44,934 INFO  [stdout] (main) 
> 15:31:44,934 INFO  [stdout] (main)
> {code}

--
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

From issues at jboss.org  Wed Mar  5 18:11:40 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 5 Mar 2014 18:11:40 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1188) allow custom-formatter
	configuration
In-Reply-To: <JIRA.12479264.1352969098000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12479264.1352969098000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12479264.1352969098000.7018.1394061100579@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12950481#comment-12950481 ] 

RH Bugzilla Integration commented on WFLY-1188:
-----------------------------------------------

Paul Gier <pgier at redhat.com> changed the Status of [bug 994661|https://bugzilla.redhat.com/show_bug.cgi?id=994661] from MODIFIED to ON_QA
                
> allow custom-formatter configuration
> ------------------------------------
>
>                 Key: WFLY-1188
>                 URL: https://issues.jboss.org/browse/WFLY-1188
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Logging
>            Reporter: Aleksandar Kostadinov
>            Assignee: James Perkins
>              Labels: as7, formatting, logging
>             Fix For: 8.0.0.CR1
>
>
> Currently only *org.jboss.logmanager.formatters.PatternFormatter* is supported in JBoss AS7 configuration. It would be very useful to allow specifying a custom-formatter (e.g *java.util.logging.XMLFormatter*).
> At the moment one can specify another formatter in logging.properties but once the logging subsystem is initialized, the settings in logging.properties get overridden.
> A workaround would be to disable logging subsystem but that has drawbacks.

--
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

From issues at jboss.org  Wed Mar  5 18:11:42 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 5 Mar 2014 18:11:42 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2204) runtime exceptions thrown
 during parsing crash cli sessions
In-Reply-To: <JIRA.12502024.1380726912000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502024.1380726912000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502024.1380726912000.7056.1394061102151@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2204?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12950486#comment-12950486 ] 

RH Bugzilla Integration commented on WFLY-2204:
-----------------------------------------------

Paul Gier <pgier at redhat.com> changed the Status of [bug 997584|https://bugzilla.redhat.com/show_bug.cgi?id=997584] from MODIFIED to ON_QA
                
> runtime exceptions thrown during parsing crash cli sessions
> -----------------------------------------------------------
>
>                 Key: WFLY-2204
>                 URL: https://issues.jboss.org/browse/WFLY-2204
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: CLI
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Alexey Loubyansky
>            Assignee: Alexey Loubyansky
>             Fix For: 8.0.0.CR1
>
>
> Runtime exceptions thrown during command line parsing crash CLI sessions.

--
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

From issues at jboss.org  Wed Mar  5 18:11:43 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 5 Mar 2014 18:11:43 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2261) standalone.sh --debug without
 port number not working
In-Reply-To: <JIRA.12502486.1381251288000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502486.1381251288000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502486.1381251288000.7077.1394061103031@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2261?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12950490#comment-12950490 ] 

RH Bugzilla Integration commented on WFLY-2261:
-----------------------------------------------

Paul Gier <pgier at redhat.com> changed the Status of [bug 1063289|https://bugzilla.redhat.com/show_bug.cgi?id=1063289] from MODIFIED to ON_QA
                
> standalone.sh --debug without port number not working 
> ------------------------------------------------------
>
>                 Key: WFLY-2261
>                 URL: https://issues.jboss.org/browse/WFLY-2261
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Scripts
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Cheng Fang
>            Assignee: Jeff Mesnil
>             Fix For: 8.0.1.Final
>
>
> ./standalone.sh --debug port-num works, but it failed when omitting port number.
> sh -x standalone.sh --debug  (expecting the default port 8787 to be used)
> {noformat}
> + eval '"/Library/Java/JavaVirtualMachines/jdk1.7.0_40.jdk/Contents/Home/bin/java"' '-D"[Standalone]"' -server -XX:+UseCompressedOops -Xms64m -Xmx512m -XX:MaxPermSize=256m -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true -agentlib:jdwp=transport=dt_socket,address=8787,server=y,suspend=n '"-Dorg.jboss.boot.log.file=/Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT/standalone/log/server.log"' '"-Dlogging.configuration=file:/Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT/standalone/configuration/logging.properties"' -jar '"/Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT/jboss-modules.jar"' -mp '"/Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT/modules"' org.jboss.as.standalone '-Djboss.home.dir="/Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT"' '-Djboss.server.base.dir="/Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT/standalone"' ' ""'
> ++ /Library/Java/JavaVirtualMachines/jdk1.7.0_40.jdk/Contents/Home/bin/java '-D[Standalone]' -server -XX:+UseCompressedOops -Xms64m -Xmx512m -XX:MaxPermSize=256m -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true -agentlib:jdwp=transport=dt_socket,address=8787,server=y,suspend=n -Dorg.jboss.boot.log.file=/Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT/standalone/log/server.log -Dlogging.configuration=file:/Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT/standalone/configuration/logging.properties -jar /Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT/jboss-modules.jar -mp /Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT/modules org.jboss.as.standalone -Djboss.home.dir=/Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT -Djboss.server.base.dir=/Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT/standalone ''
> Listening for transport dt_socket at address: 8787
> 12:19:36,715 INFO  [org.jboss.modules] (main) JBoss Modules version 1.3.0.Final
> 12:19:36,886 ERROR [stderr] (main) JBAS015801: Invalid option ''
> 12:19:36,893 INFO  [stdout] (main)
> 12:19:36,893 INFO  [stdout] (main) Usage: standalone.sh [args...]
> {noformat}
> sh -x standalone.sh --debug 8787 (the working command)
> {noformat}
> + eval '"/Library/Java/JavaVirtualMachines/jdk1.7.0_40.jdk/Contents/Home/bin/java"' '-D"[Standalone]"' -server -XX:+UseCompressedOops -Xms64m -Xmx512m -XX:MaxPermSize=256m -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true -agentlib:jdwp=transport=dt_socket,address=8787,server=y,suspend=n '"-Dorg.jboss.boot.log.file=/Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT/standalone/log/server.log"' '"-Dlogging.configuration=file:/Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT/standalone/configuration/logging.properties"' -jar '"/Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT/jboss-modules.jar"' -mp '"/Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT/modules"' org.jboss.as.standalone '-Djboss.home.dir="/Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT"' '-Djboss.server.base.dir="/Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT/standalone"' ''
> ++ /Library/Java/JavaVirtualMachines/jdk1.7.0_40.jdk/Contents/Home/bin/java '-D[Standalone]' -server -XX:+UseCompressedOops -Xms64m -Xmx512m -XX:MaxPermSize=256m -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true -agentlib:jdwp=transport=dt_socket,address=8787,server=y,suspend=n -Dorg.jboss.boot.log.file=/Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT/standalone/log/server.log -Dlogging.configuration=file:/Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT/standalone/configuration/logging.properties -jar /Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT/jboss-modules.jar -mp /Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT/modules org.jboss.as.standalone -Djboss.home.dir=/Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT -Djboss.server.base.dir=/Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT/standalone
> Listening for transport dt_socket at address: 8787
> 12:20:39,251 INFO  [org.jboss.modules] (main) JBoss Modules version 1.3.0.Final
> 12:20:39,626 INFO  [org.jboss.msc] (main) JBoss MSC version 1.2.0.Beta2
> {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


From issues at jboss.org  Wed Mar  5 18:11:42 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 5 Mar 2014 18:11:42 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2536) NPE in cli is thrown when
 using preserve, override without parameter
In-Reply-To: <JIRA.12525558.1384866491000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12525558.1384866491000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12525558.1384866491000.7073.1394061102856@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12950489#comment-12950489 ] 

RH Bugzilla Integration commented on WFLY-2536:
-----------------------------------------------

Paul Gier <pgier at redhat.com> changed the Status of [bug 1032041|https://bugzilla.redhat.com/show_bug.cgi?id=1032041] from MODIFIED to ON_QA
                
> NPE in cli is thrown when using preserve, override without parameter
> --------------------------------------------------------------------
>
>                 Key: WFLY-2536
>                 URL: https://issues.jboss.org/browse/WFLY-2536
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Patching
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Emanuel Muckenhuber
>            Assignee: Alexey Loubyansky
>            Priority: Minor
>             Fix For: 8.0.0.CR1
>
>


--
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

From issues at jboss.org  Wed Mar  5 18:11:43 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 5 Mar 2014 18:11:43 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2498) Logout of secured (ssl) admin
 console setup redirects to http address
In-Reply-To: <JIRA.12524948.1384302668000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12524948.1384302668000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12524948.1384302668000.7089.1394061103520@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2498?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12950492#comment-12950492 ] 

RH Bugzilla Integration commented on WFLY-2498:
-----------------------------------------------

Paul Gier <pgier at redhat.com> changed the Status of [bug 1029687|https://bugzilla.redhat.com/show_bug.cgi?id=1029687] from MODIFIED to ON_QA
                
>  Logout of secured (ssl) admin console setup redirects to http address
> ----------------------------------------------------------------------
>
>                 Key: WFLY-2498
>                 URL: https://issues.jboss.org/browse/WFLY-2498
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management, Web Console
>            Reporter: Chris Dolphy
>            Assignee: Darran Lofthouse
>             Fix For: 8.0.0.Final
>
>
> Description of problem:
> Logging out of an admin console secured with SSL (on port 9443) redirects to http address (e.g. http://localhost:9443/logout?logout) which leads to a Page Not Found error.

--
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

From issues at jboss.org  Wed Mar  5 18:11:44 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 5 Mar 2014 18:11:44 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2920) StackOverflowError when
 org.jboss.as.jacorb.rmi.InterfaceAnalysis is analyzing javax.ejb.EJBObject
In-Reply-To: <JIRA.12532007.1392269121000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12532007.1392269121000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12532007.1392269121000.7108.1394061104494@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2920?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12950498#comment-12950498 ] 

RH Bugzilla Integration commented on WFLY-2920:
-----------------------------------------------

Paul Gier <pgier at redhat.com> changed the Status of [bug 1064644|https://bugzilla.redhat.com/show_bug.cgi?id=1064644] from MODIFIED to ON_QA
                
> StackOverflowError when org.jboss.as.jacorb.rmi.InterfaceAnalysis is analyzing javax.ejb.EJBObject
> --------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2920
>                 URL: https://issues.jboss.org/browse/WFLY-2920
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: IIOP
>    Affects Versions: 8.0.0.Final
>            Reporter: Osamu Nagano
>            Assignee: Stefan Guilhen
>         Attachments: td.dump
>
>
> Depending on when a thread context switch happens, an IIOP enabled EJB fails to be deployed by throwing {{java.lang.StackOverflowError}}.  Here is the stack trace from the attached thread dump.
> {code}
> "MSC service thread 1-7" prio=10 tid=0x00007f52e8001800 nid=0x4d12 at breakpoint[0x00007f534093f000]
>    java.lang.Thread.State: RUNNABLE
>         at org.jboss.as.jacorb.rmi.WorkCacheManager.getAnalysis(WorkCacheManager.java:105)
>         at org.jboss.as.jacorb.rmi.InterfaceAnalysis.getInterfaceAnalysis(InterfaceAnalysis.java:53)
>         at org.jboss.as.jacorb.rmi.Util.getTypeIDLName(Util.java:104)
>         at org.jboss.as.jacorb.rmi.ParameterAnalysis.<init>(ParameterAnalysis.java:50)
>         at org.jboss.as.jacorb.rmi.OperationAnalysis.<init>(OperationAnalysis.java:91)
>         at org.jboss.as.jacorb.rmi.InterfaceAnalysis.analyzeOperations(InterfaceAnalysis.java:116)
>         at org.jboss.as.jacorb.rmi.ContainerAnalysis.doAnalyze(ContainerAnalysis.java:186)
>         at org.jboss.as.jacorb.rmi.InterfaceAnalysis.doAnalyze(InterfaceAnalysis.java:62)
>         at sun.reflect.GeneratedMethodAccessor3.invoke(Unknown Source)
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>         at java.lang.reflect.Method.invoke(Method.java:606)
>         at org.jboss.as.jacorb.rmi.WorkCacheManager.doTheWork(WorkCacheManager.java:177)
>         at org.jboss.as.jacorb.rmi.WorkCacheManager.getAnalysis(WorkCacheManager.java:105)
>         at org.jboss.as.jacorb.rmi.InterfaceAnalysis.getInterfaceAnalysis(InterfaceAnalysis.java:53)
>         at org.jboss.as.jacorb.rmi.Util.getTypeIDLName(Util.java:104)
>         at org.jboss.as.jacorb.rmi.ParameterAnalysis.<init>(ParameterAnalysis.java:50)
>         at org.jboss.as.jacorb.rmi.OperationAnalysis.<init>(OperationAnalysis.java:91)
>         at org.jboss.as.jacorb.rmi.InterfaceAnalysis.analyzeOperations(InterfaceAnalysis.java:116)
>         at org.jboss.as.jacorb.rmi.ContainerAnalysis.doAnalyze(ContainerAnalysis.java:186)
>         at org.jboss.as.jacorb.rmi.InterfaceAnalysis.doAnalyze(InterfaceAnalysis.java:62)
>         at sun.reflect.GeneratedMethodAccessor3.invoke(Unknown Source)
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>         at java.lang.reflect.Method.invoke(Method.java:606)
>         ...
>         at org.jboss.as.jacorb.rmi.WorkCacheManager.doTheWork(WorkCacheManager.java:177)
>         at org.jboss.as.jacorb.rmi.WorkCacheManager.getAnalysis(WorkCacheManager.java:105)
>         at org.jboss.as.jacorb.rmi.InterfaceAnalysis.getInterfaceAnalysis(InterfaceAnalysis.java:53)
>         at org.jboss.as.jacorb.rmi.Util.getTypeIDLName(Util.java:104)
>         at org.jboss.as.jacorb.rmi.ParameterAnalysis.<init>(ParameterAnalysis.java:50)
>    Locked ownable synchronizers:
>         - <0x00000000f9698790> (a java.util.concurrent.ThreadPoolExecutor$Worker)
> {code}
> The last part including {{Util.getTypeIDLName}} has been repeated as many as possible and the bottom of the stack has been lost.  The same stack has been appeared in a different MSC service thread which is also executing an IIOP enabled EJB deployment.
> The customer identified an improper synchronization in {{org.jboss.as.jacorb.rmi.WorkCacheManager#getAnalysis()}}.  It is reproducible by manually controlling a thread context switch using a debugger.

--
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

From issues at jboss.org  Wed Mar  5 18:11:44 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 5 Mar 2014 18:11:44 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2987)
 RemoteDestinationOutboundSocketBindingService is not stopped when the
 resource is removed
In-Reply-To: <JIRA.12532915.1392980383000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12532915.1392980383000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12532915.1392980383000.7115.1394061104787@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2987?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12950500#comment-12950500 ] 

RH Bugzilla Integration commented on WFLY-2987:
-----------------------------------------------

Paul Gier <pgier at redhat.com> changed the Status of [bug 1038465|https://bugzilla.redhat.com/show_bug.cgi?id=1038465] from MODIFIED to ON_QA
                
> RemoteDestinationOutboundSocketBindingService is not stopped when the resource is removed
> -----------------------------------------------------------------------------------------
>
>                 Key: WFLY-2987
>                 URL: https://issues.jboss.org/browse/WFLY-2987
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Server
>    Affects Versions: 8.0.0.Final
>            Reporter: Jeff Mesnil
>            Assignee: Jeff Mesnil
>             Fix For: 8.0.1.Final
>
>
> Steps to Reproduce:
> 1. add remote-destination-outbound-socket-binding
> ./jboss-cli.sh -c "/socket-binding-group=standard-sockets/remote-destination-outbound-socket-binding=remote-connection-war-ejb-1:add(host=localhost, port=4447)"
> result is {"outcome" => "success"}
> 3. remove remote-destination-outbound-socket-binding
> ./bin/jboss-cli.sh -c "/socket-binding-group=standard-sockets/remote-destination-outbound-socket-binding=remote-connection-war-ejb-1:remove"
> result is {"outcome" => "success"}
> 4. add remote-destination-outbound-socket-binding
> ./jboss-cli.sh -c "/socket-binding-group=standard-sockets/remote-destination-outbound-socket-binding=remote-connection-war-ejb-1:add(host=localhost, port=4447)"
> result is
> {
>     "outcome" => "failed",
>     "failure-description" => "JBAS014749: Operation handler failed: Service jboss.outbound-socket-binding.remote-connection-war-ejb-1 is already registered",
>     "rolled-back" => true
> }
> Expected results:
> {"outcome" => "success"}
> Step 3 should either report reload required or should be fixed

--
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

From issues at jboss.org  Wed Mar  5 18:11:45 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 5 Mar 2014 18:11:45 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2051) CLI write attribute dialog
 for string value should enclose value in generated command to double quotes
In-Reply-To: <JIRA.12500587.1378980513000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500587.1378980513000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500587.1378980513000.7121.1394061105027@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12950501#comment-12950501 ] 

RH Bugzilla Integration commented on WFLY-2051:
-----------------------------------------------

Paul Gier <pgier at redhat.com> changed the Status of [bug 988283|https://bugzilla.redhat.com/show_bug.cgi?id=988283] from MODIFIED to ON_QA
                
> CLI write attribute dialog for string value should enclose value in generated command to double quotes
> ------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2051
>                 URL: https://issues.jboss.org/browse/WFLY-2051
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: CLI
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Chao Wang
>            Assignee: Alexey Loubyansky
>             Fix For: 8.0.0.CR1
>
>
> {noformat}
> Wildfly issue for https://bugzilla.redhat.com/show_bug.cgi?id=988283
> String value entered in write attribute dialog is written to command without double quotes, which is wrong in many cases
> Eg. when user enteres in dialog value ${jboss.bind.address:127.0.0.1}
> following command is generated:
> /subsystem=webservices/:write-attribute(name=wsdl-host,value=${jboss.bind.address:127.0.0.1})
> Correctly should be generated command 
> /subsystem=webservices/:write-attribute(name=wsdl-host,value="${jboss.bind.address:127.0.0.1}")
> 1. start AS
>   ./bin/standalone.sh
> 2. start CLI GUI 
>   ./bin/jboss-cli.sh --gui &
> 3. click on node subsystem=webservices of /
> 4. right click on wsdl-host and select write-attribute
> 5. enter value ${jboss.bind.address:127.0.0.1} and click OK
> 6. submit generated command
> 7. reload node
>   click on node subsystem=webservices of / (close node)
>   click on node subsystem=webservices of / (open node)
> Result is wsdl-host=$ instead of wsdl-host=${jboss.bind.address:127.0.0.1}
> Workaround: in dialog box enclose the value in double quotes
> {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

From issues at jboss.org  Wed Mar  5 18:11:45 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 5 Mar 2014 18:11:45 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3016) Prevent NullPointerException
 in JDR CommandLineMain
In-Reply-To: <JIRA.12533291.1393354434000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12533291.1393354434000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12533291.1393354434000.7124.1394061105176@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-3016?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12950502#comment-12950502 ] 

RH Bugzilla Integration commented on WFLY-3016:
-----------------------------------------------

Paul Gier <pgier at redhat.com> changed the Status of [bug 1069850|https://bugzilla.redhat.com/show_bug.cgi?id=1069850] from MODIFIED to ON_QA
                
> Prevent NullPointerException in JDR CommandLineMain
> ---------------------------------------------------
>
>                 Key: WFLY-3016
>                 URL: https://issues.jboss.org/browse/WFLY-3016
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JDR
>    Affects Versions: 8.0.0.Final
>            Reporter: Brad Maxwell
>            Assignee: Brad Maxwell
>


--
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

From issues at jboss.org  Wed Mar  5 18:11:45 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 5 Mar 2014 18:11:45 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1271) Infinispan remote-store
 requires remote-servers but not marked as required in mgmt model
In-Reply-To: <JIRA.12490391.1366787482000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12490391.1366787482000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12490391.1366787482000.7140.1394061105895@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1271?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12950506#comment-12950506 ] 

RH Bugzilla Integration commented on WFLY-1271:
-----------------------------------------------

Paul Gier <pgier at redhat.com> changed the Status of [bug 956904|https://bugzilla.redhat.com/show_bug.cgi?id=956904] from MODIFIED to ON_QA
                
> Infinispan remote-store requires remote-servers but not marked as required in mgmt model
> ----------------------------------------------------------------------------------------
>
>                 Key: WFLY-1271
>                 URL: https://issues.jboss.org/browse/WFLY-1271
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Clustering
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Takayoshi Kimura
>            Assignee: Richard Achmatowicz
>             Fix For: 8.0.0.CR1
>
>
> Affect version is actually 8.0.0.Alpha1-SNAPSHOT (before 8.0.0.Alpha1, we don't have such selection).
> Command remote-store=REMOTE_STORE:add fails with this exception:
> {quote}
> 15:58:05,112 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 3) JBAS014607: Failed to persist configuration change: org.jboss.as.controller.persistence.ConfigurationPersistenceException: JBAS014675: Failed to marshal configuration
> 	at org.jboss.as.controller.persistence.AbstractFilePersistenceResource.<init>(AbstractFilePersistenceResource.java:50) [jboss-as-controller-8.0.0.Alpha1-SNAPSHOT.jar:8.0.0.Alpha1-SNAPSHOT]
> 	at org.jboss.as.controller.persistence.ConfigurationFilePersistenceResource.<init>(ConfigurationFilePersistenceResource.java:45) [jboss-as-controller-8.0.0.Alpha1-SNAPSHOT.jar:8.0.0.Alpha1-SNAPSHOT]
> 	at org.jboss.as.controller.persistence.BackupXmlConfigurationPersister.store(BackupXmlConfigurationPersister.java:80) [jboss-as-controller-8.0.0.Alpha1-SNAPSHOT.jar:8.0.0.Alpha1-SNAPSHOT]
> 	at org.jboss.as.controller.ModelControllerImpl.writeModel(ModelControllerImpl.java:522) [jboss-as-controller-8.0.0.Alpha1-SNAPSHOT.jar:8.0.0.Alpha1-SNAPSHOT]
> 	at org.jboss.as.controller.OperationContextImpl.createPersistenceResource(OperationContextImpl.java:178) [jboss-as-controller-8.0.0.Alpha1-SNAPSHOT.jar:8.0.0.Alpha1-SNAPSHOT]
> 	at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:359) [jboss-as-controller-8.0.0.Alpha1-SNAPSHOT.jar:8.0.0.Alpha1-SNAPSHOT]
> 	at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:228) [jboss-as-controller-8.0.0.Alpha1-SNAPSHOT.jar:8.0.0.Alpha1-SNAPSHOT]
> 	at org.jboss.as.controller.AbstractOperationContext.finishStep(AbstractOperationContext.java:513) [jboss-as-controller-8.0.0.Alpha1-SNAPSHOT.jar:8.0.0.Alpha1-SNAPSHOT]
> 	at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:499) [jboss-as-controller-8.0.0.Alpha1-SNAPSHOT.jar:8.0.0.Alpha1-SNAPSHOT]
> 	at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:321) [jboss-as-controller-8.0.0.Alpha1-SNAPSHOT.jar:8.0.0.Alpha1-SNAPSHOT]
> 	at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:228) [jboss-as-controller-8.0.0.Alpha1-SNAPSHOT.jar:8.0.0.Alpha1-SNAPSHOT]
> 	at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:223) [jboss-as-controller-8.0.0.Alpha1-SNAPSHOT.jar:8.0.0.Alpha1-SNAPSHOT]
> 	at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:235) [jboss-as-controller-8.0.0.Alpha1-SNAPSHOT.jar:8.0.0.Alpha1-SNAPSHOT]
> 	at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:124) [jboss-as-controller-8.0.0.Alpha1-SNAPSHOT.jar:8.0.0.Alpha1-SNAPSHOT]
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:148) [jboss-as-controller-8.0.0.Alpha1-SNAPSHOT.jar:8.0.0.Alpha1-SNAPSHOT]
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$300(ModelControllerClientOperationHandler.java:97) [jboss-as-controller-8.0.0.Alpha1-SNAPSHOT.jar:8.0.0.Alpha1-SNAPSHOT]
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:114) [jboss-as-controller-8.0.0.Alpha1-SNAPSHOT.jar:8.0.0.Alpha1-SNAPSHOT]
> 	at org.jboss.as.protocol.mgmt.AbstractMessageHandler$2$1.doExecute(AbstractMessageHandler.java:296) [jboss-as-protocol-8.0.0.Alpha1-SNAPSHOT.jar:8.0.0.Alpha1-SNAPSHOT]
> 	at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:518) [jboss-as-protocol-8.0.0.Alpha1-SNAPSHOT.jar:8.0.0.Alpha1-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]
> Caused by: org.jboss.as.controller.persistence.ConfigurationPersistenceException: JBAS014680: Failed to write configuration
> 	at org.jboss.as.controller.persistence.AbstractConfigurationPersister.marshallAsXml(AbstractConfigurationPersister.java:123) [jboss-as-controller-8.0.0.Alpha1-SNAPSHOT.jar:8.0.0.Alpha1-SNAPSHOT]
> 	at org.jboss.as.controller.persistence.AbstractFilePersistenceResource.<init>(AbstractFilePersistenceResource.java:43) [jboss-as-controller-8.0.0.Alpha1-SNAPSHOT.jar:8.0.0.Alpha1-SNAPSHOT]
> 	... 22 more
> Caused by: java.lang.IllegalArgumentException
> 	at org.jboss.dmr.ModelValue.asList(ModelValue.java:128) [jboss-dmr-1.1.6.Final.jar:1.1.6.Final]
> 	at org.jboss.dmr.ModelNode.asList(ModelNode.java:1205) [jboss-dmr-1.1.6.Final.jar:1.1.6.Final]
> 	at org.jboss.as.clustering.infinispan.subsystem.InfinispanSubsystemXMLWriter.processCommonCacheAttributesElements(InfinispanSubsystemXMLWriter.java:282)
> 	at org.jboss.as.clustering.infinispan.subsystem.InfinispanSubsystemXMLWriter.writeContent(InfinispanSubsystemXMLWriter.java:124)
> 	at org.jboss.as.clustering.infinispan.subsystem.InfinispanSubsystemXMLWriter.writeContent(InfinispanSubsystemXMLWriter.java:42)
> 	at org.jboss.as.server.parsing.StandaloneXml.writeServerProfile(StandaloneXml.java:1191) [jboss-as-server-8.0.0.Alpha1-SNAPSHOT.jar:8.0.0.Alpha1-SNAPSHOT]
> 	at org.jboss.as.server.parsing.StandaloneXml.writeContent(StandaloneXml.java:1108) [jboss-as-server-8.0.0.Alpha1-SNAPSHOT.jar:8.0.0.Alpha1-SNAPSHOT]
> 	at org.jboss.as.server.parsing.StandaloneXml.writeContent(StandaloneXml.java:103) [jboss-as-server-8.0.0.Alpha1-SNAPSHOT.jar:8.0.0.Alpha1-SNAPSHOT]
> 	at org.jboss.staxmapper.XMLMapperImpl.doDeparse(XMLMapperImpl.java:88) [staxmapper-1.1.0.Final.jar:1.1.0.Final]
> 	at org.jboss.staxmapper.XMLMapperImpl.deparseDocument(XMLMapperImpl.java:83) [staxmapper-1.1.0.Final.jar:1.1.0.Final]
> 	at org.jboss.as.controller.persistence.AbstractConfigurationPersister.marshallAsXml(AbstractConfigurationPersister.java:117) [jboss-as-controller-8.0.0.Alpha1-SNAPSHOT.jar:8.0.0.Alpha1-SNAPSHOT]
> 	... 23 more
> {quote}
> Reproduce steps:
> {quote}
> [standalone at localhost:9999 /] /subsystem=infinispan/cache-container=web/replicated-cache=repl/file-store=FILE_STORE:remove
> {
>     "outcome" => "success",
>     "response-headers" => {
>         "operation-requires-reload" => true,
>         "process-state" => "reload-required"
>     }
> }
> [standalone at localhost:9999 /] /subsystem=infinispan/cache-container=web/replicated-cache=repl/remote-store=REMOTE_STORE:add
> {
>     "outcome" => "failed",
>     "failure-description" => "JBAS014677: Failed to persist configuration change: JBAS014675: Failed to marshal configuration",
>     "rolled-back" => true,
>     "response-headers" => {"process-state" => "reload-required"}
> }
> [standalone at localhost:9999 /] /subsystem=infinispan/cache-container=web/replicated-cache=repl/remote-store=REMOTE_STORE:add(remote-servers=[])
> {
>     "outcome" => "success",
>     "response-headers" => {"process-state" => "reload-required"}
> }
> {quote}
> In $JBOSS_HOME/docs/schema/jboss-as-infinispan_1_3.xsd, it looks like the remote-server is required as it's defined as minOccurs="1":
> {quote}
> <xs:element name="remote-server" type="tns:remote-server" minOccurs="1" maxOccurs="unbounded"/>
> {quote}

--
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

From issues at jboss.org  Wed Mar  5 18:13:33 2014
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Wed, 5 Mar 2014 18:13:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2824) Remove
 https://issues.apache.org/jira/browse/DIRAPI-125 workaround
In-Reply-To: <JIRA.12530511.1390926661000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530511.1390926661000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530511.1390926661000.7168.1394061213286@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2824?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFLY-2824:
-----------------------------------

    Fix Version/s: 9.0.0.CR1
                       (was: 8.0.1.Final)

    
> Remove https://issues.apache.org/jira/browse/DIRAPI-125 workaround 
> -------------------------------------------------------------------
>
>                 Key: WFLY-2824
>                 URL: https://issues.jboss.org/browse/WFLY-2824
>             Project: WildFly
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite
>    Affects Versions: 8.0.0.CR1
>            Reporter: Brian Stansberry
>            Assignee: Brian Stansberry
>             Fix For: 9.0.0.CR1
>
>
> As a workaround for an Apache DS bug we forked their LdapUrl class in the testsuite/integration/basic module. This JIRA is a reminder to check if the upstream bug is fixed and the fix is in the release WF uses; if so remove the workaround.

--
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

From issues at jboss.org  Wed Mar  5 23:09:33 2014
From: issues at jboss.org (Stuart Douglas (JIRA))
Date: Wed, 5 Mar 2014 23:09:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3045) Expose JAXRS deployments via
 the management API
In-Reply-To: <JIRA.12533624.1393602042000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12533624.1393602042000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12533624.1393602042000.7353.1394078973338@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-3045?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stuart Douglas updated WFLY-3045:
---------------------------------

    Fix Version/s: Awaiting Volunteers
         Assignee:     (was: Stuart Douglas)

    
> Expose JAXRS deployments via the management API
> -----------------------------------------------
>
>                 Key: WFLY-3045
>                 URL: https://issues.jboss.org/browse/WFLY-3045
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management, REST
>    Affects Versions: 8.0.0.Final
>            Reporter: Emmanuel Hugonnet
>             Fix For: Awaiting Volunteers
>
>
> Currently WildFly expose webapps and ejbs deployments through the management API. I think we should also expose in a similar manner the other deployments such as REST resources

--
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

From issues at jboss.org  Wed Mar  5 23:19:33 2014
From: issues at jboss.org (Chris Roberts (JIRA))
Date: Wed, 5 Mar 2014 23:19:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2959) Downgrade Jackson dependency
In-Reply-To: <JIRA.12532567.1392747430000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12532567.1392747430000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12532567.1392747430000.7359.1394079573317@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2959?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12950526#comment-12950526 ] 

Chris Roberts commented on WFLY-2959:
-------------------------------------

Of course, you're right. I'm an idiot. jackson-datatype-hibernate4 wasn't working the way I thought it was, thanks to some debugging code I'd added earlier and later taken out.  2.2.3 works exactly the way it's supposed to work. Thanks for looking.
                
> Downgrade Jackson dependency
> ----------------------------
>
>                 Key: WFLY-2959
>                 URL: https://issues.jboss.org/browse/WFLY-2959
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: REST
>    Affects Versions: 8.0.0.Final
>            Reporter: James Perkins
>            Assignee: James Perkins
>             Fix For: 8.0.1.Final
>
>         Attachments: org.jboss.test.test-jackson.tar.gz, org.jboss.test.test-jackson.tar.gz
>
>
> Jackson was upgraded to 2.3.0 which contains a [bug|https://github.com/FasterXML/jackson-jaxrs-providers/commit/bafb6fb64bc15482c7bfc56784169204d6c4b1f2#commitcomment-5224156] that breaks RESTEasy. RESTEasy currently uses 2.2.1. Downgrading to at least 2.2.3, which is what CR1 is at, seems to resolve this issue.
> We should likely keep the version aligned with RESTEasy, but since CR1 was using 2.2.3 with no issues, I think reverting back to that should be fine.

--
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

From issues at jboss.org  Wed Mar  5 23:59:33 2014
From: issues at jboss.org (Kyle Shanahan (JIRA))
Date: Wed, 5 Mar 2014 23:59:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (LOGMGR-100) SyslogHandler.findPid()
 omitted the last digit of pid
In-Reply-To: <JIRA.12534237.1394081909479@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534237.1394081909479@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534237.1394081909479.7422.1394081973701@jira02.app.mwc.hst.phx2.redhat.com>

Kyle Shanahan created LOGMGR-100:
------------------------------------

             Summary: SyslogHandler.findPid() omitted the last digit of pid
                 Key: LOGMGR-100
                 URL: https://issues.jboss.org/browse/LOGMGR-100
             Project: JBoss Log Manager
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: core
    Affects Versions: 1.5.2.Final
         Environment: WildFly 8.0.0.Final
Oracle JDK7u51
            Reporter: Kyle Shanahan
            Assignee: David Lloyd
            Priority: Minor


The last digit of the pid omitted.
seems to usage mistake of substring().

--
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

From issues at jboss.org  Thu Mar  6 01:29:33 2014
From: issues at jboss.org (Bela Ban (JIRA))
Date: Thu, 6 Mar 2014 01:29:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1799) RpcDispatcher test fails when
 working with large values
In-Reply-To: <JIRA.12533122.1393254868000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12533122.1393254868000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12533122.1393254868000.7527.1394087373216@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JGRP-1799?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12950536#comment-12950536 ] 

Bela Ban commented on JGRP-1799:
--------------------------------

Absolutely. Perhaps we could use a base timeout and then factor in the size of the state to be transferred, e.g. the timeout is defined as 5s for 100'000 bytes, 50s for 1MB, 500s for 10MB and so on. Just an example...
                
> RpcDispatcher test fails when working with large values
> -------------------------------------------------------
>
>                 Key: JGRP-1799
>                 URL: https://issues.jboss.org/browse/JGRP-1799
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.2.13
>         Environment: RHEL, Win, Solaris
>            Reporter: Richard Achmatowicz
>            Assignee: Bela Ban
>             Fix For: 3.2.13
>
>
> The two tests:
> * testLargeReturnValue
> * testLargeReturnValueUnicastCall
> make RPC calls with values which are increasingly large. 
> The values used are in this range:
> {noformat}
> SIZES={10000, 20000, 40000, 80000, 100000, 200000, 400000, 800000,1000000, 2000000, 5000000}
> {noformat}
> The tests have been see to fail with the values 1000000, 2000000 and 5000000, always with the same error in each case. 
> In the case of testLargeReturnValue, the test fails because one of the returned values from the RPC is null.
> In the case of testLargeReturnValueUnicastCall, the test fails due to a timeout while sending the RPC.
>  

--
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

From issues at jboss.org  Thu Mar  6 01:31:33 2014
From: issues at jboss.org (Bela Ban (JIRA))
Date: Thu, 6 Mar 2014 01:31:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1799) RpcDispatcher test fails when
 working with large values
In-Reply-To: <JIRA.12533122.1393254868000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12533122.1393254868000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12533122.1393254868000.7530.1394087493164@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JGRP-1799?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12950537#comment-12950537 ] 

Bela Ban commented on JGRP-1799:
--------------------------------

Even better: we measure the actual time it takes for smaller messages, then 'predict' the time (by extrapolation) for larger messages. We can actually adjust the prediction as we go by the real values.
                
> RpcDispatcher test fails when working with large values
> -------------------------------------------------------
>
>                 Key: JGRP-1799
>                 URL: https://issues.jboss.org/browse/JGRP-1799
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.2.13
>         Environment: RHEL, Win, Solaris
>            Reporter: Richard Achmatowicz
>            Assignee: Bela Ban
>             Fix For: 3.2.13
>
>
> The two tests:
> * testLargeReturnValue
> * testLargeReturnValueUnicastCall
> make RPC calls with values which are increasingly large. 
> The values used are in this range:
> {noformat}
> SIZES={10000, 20000, 40000, 80000, 100000, 200000, 400000, 800000,1000000, 2000000, 5000000}
> {noformat}
> The tests have been see to fail with the values 1000000, 2000000 and 5000000, always with the same error in each case. 
> In the case of testLargeReturnValue, the test fails because one of the returned values from the RPC is null.
> In the case of testLargeReturnValueUnicastCall, the test fails due to a timeout while sending the RPC.
>  

--
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

From issues at jboss.org  Thu Mar  6 01:37:33 2014
From: issues at jboss.org (niraj gupta (JIRA))
Date: Thu, 6 Mar 2014 01:37:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-441) drools-guvnor 5.5,
 declarative model, create more than one fact type,
 BPMN process does not load
In-Reply-To: <JIRA.12533209.1393317312000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12533209.1393317312000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12533209.1393317312000.7552.1394087853424@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/DROOLS-441?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12950538#comment-12950538 ] 

niraj gupta commented on DROOLS-441:
------------------------------------

No!

 Pkg1 & Pkg2 both are independent. I am not using classes from pkg2 in my process. Actually this declarative type fact i am using guvnor side itself for some other purpose, i don't need declarative type bean in console.

I found the code which is creating problem. loadDeclaredTypesToBuilder(); api call into setUpPackage  in PackageAssemblerBase.java class.

It is trying to put declarative type into class path with the help of BRMSPackageBuilder. But i don't not have fix for it yet. do you have any suggestions.

Regards,
Niraj
                
> drools-guvnor 5.5, declarative model, create more than one fact type, BPMN process does not load
> ------------------------------------------------------------------------------------------------
>
>                 Key: DROOLS-441
>                 URL: https://issues.jboss.org/browse/DROOLS-441
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.5.0.Final
>         Environment: Tomcat 6.0.35, jBPM 5.5.Final
>            Reporter: niraj gupta
>            Assignee: Mark Proctor
>              Labels: drools-guvnor
>
>  I am using ?drools-guvnor 5.5.0.Final? open source tool for designing the business process (BPMN2). I end up in an issue and looking for help. Following is the scenario
> I created a package then process then after build, deploy execute successfully. Now I came back to guvnor and made few changes in the process. Then after same build, deploy execute successfully. But now this time I am creating a declarative model having 2 facts, also modifying business process. Then after same build, deploy execute successfully. This time modified/latest business process doesn?t load into console. This is my problem.  However I trouble shoot and google following are my observations:
> ?	I am running this application in tomcat 6.0.35
> ?	It works perfectly with POJO Model Jar approach.
> ?	It works perfectly with declarative model but having single fact.
> ?	I am not seeing any exceptions either in UI or console logs

--
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


From issues at jboss.org  Thu Mar  6 02:43:33 2014
From: issues at jboss.org (Bela Ban (JIRA))
Date: Thu, 6 Mar 2014 02:43:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1765) TP: enable loopback by
 default and discard own multicasts
In-Reply-To: <JIRA.12528488.1388489261000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528488.1388489261000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528488.1388489261000.7601.1394091813494@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JGRP-1765?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12950543#comment-12950543 ] 

Bela Ban commented on JGRP-1765:
--------------------------------

Perhaps we can get rid of the copy of the message when looping it back up. However, we need to take care of concurrent access to the headers, e.g. when the message is sent down on the original thread, headers may get added, but the newly spawned thread looping the message back up might access the headers at the same time. The headers (Headers) are not synchronized.
                
> TP: enable loopback by default and discard own multicasts
> ---------------------------------------------------------
>
>                 Key: JGRP-1765
>                 URL: https://issues.jboss.org/browse/JGRP-1765
>             Project: JGroups
>          Issue Type: Enhancement
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 3.5
>
>
> Enable {{TP.looback}} by default (deprecate and ignore prop): all messages sent by self are passed right to a thread pool to send them up again.
> When a multicast message sent by self is received, it is currently passed to a thread pool, de-serialized and only then discarded if loopback=true. This means that we create an unneeded buffer for de-serializationand perform de-serialization.
> SOLUTION: discard the multicast from self immediately when receiving it, in {{TP.receive()}}

--
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

From issues at jboss.org  Thu Mar  6 04:23:33 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 6 Mar 2014 04:23:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3071) upgrade Generic JMS RA to
	1.0.2.Final
In-Reply-To: <JIRA.12534174.1394029950000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534174.1394029950000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534174.1394029950000.7885.1394097813259@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-3071?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated WFLY-3071:
------------------------------------------

        Bugzilla Update: Perform
    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1073354

    
> upgrade Generic JMS RA to 1.0.2.Final
> -------------------------------------
>
>                 Key: WFLY-3071
>                 URL: https://issues.jboss.org/browse/WFLY-3071
>             Project: WildFly
>          Issue Type: Component  Upgrade
>      Security Level: Public(Everyone can see) 
>          Components: JCA
>    Affects Versions: 8.0.0.Final
>            Reporter: Jeff Mesnil
>            Assignee: Jeff Mesnil
>             Fix For: 8.0.1.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

From issues at jboss.org  Thu Mar  6 04:33:33 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 6 Mar 2014 04:33:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3071) upgrade Generic JMS RA to
	1.0.2.Final
In-Reply-To: <JIRA.12534174.1394029950000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534174.1394029950000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534174.1394029950000.7920.1394098413202@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-3071?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12950586#comment-12950586 ] 

RH Bugzilla Integration commented on WFLY-3071:
-----------------------------------------------

Jeff Mesnil <jmesnil at redhat.com> changed the Status of [bug 1073354|https://bugzilla.redhat.com/show_bug.cgi?id=1073354] from NEW to POST
                
> upgrade Generic JMS RA to 1.0.2.Final
> -------------------------------------
>
>                 Key: WFLY-3071
>                 URL: https://issues.jboss.org/browse/WFLY-3071
>             Project: WildFly
>          Issue Type: Component  Upgrade
>      Security Level: Public(Everyone can see) 
>          Components: JCA
>    Affects Versions: 8.0.0.Final
>            Reporter: Jeff Mesnil
>            Assignee: Jeff Mesnil
>             Fix For: 8.0.1.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

From issues at jboss.org  Thu Mar  6 04:41:33 2014
From: issues at jboss.org (Marek Schmidt (JIRA))
Date: Thu, 6 Mar 2014 04:41:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2911) @Stateful @RequestScoped
 @Path() does not behave like request-scoped
In-Reply-To: <JIRA.12531880.1392204972000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12531880.1392204972000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12531880.1392204972000.7941.1394098893291@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2911?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12950590#comment-12950590 ] 

Marek Schmidt commented on WFLY-2911:
-------------------------------------

JAX-RS spec doesn't say anything about @Stateful root resource classes (it only says that "In a product that also supports EJB, an implementation MUST support use of stateless and singleton session beans as root resource classes, providers and Application subclasses.")

The container should log a warning in such cases, as the resulting behavior is unexpected.
                
> @Stateful @RequestScoped @Path() does not behave like request-scoped
> --------------------------------------------------------------------
>
>                 Key: WFLY-2911
>                 URL: https://issues.jboss.org/browse/WFLY-2911
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: EE
>    Affects Versions: 8.0.0.Final
>         Environment: Wildfly 8.0.0.Final, also EAP 6.2 and 6.1.1 and possibly others.
>            Reporter: Marek Schmidt
>            Assignee: Stuart Douglas
>         Attachments: jboss-as-kitchensink-html5-mobile.war
>
>
> having a JAX-RS @RequestScoped and @Stasteful
> {code}
> @Path("/members")
> @RequestScoped
> @Stateful
> public class MemberService
> {code}
> doesn't seem to be acting as request-scoped. Specifically, an exception thrown out of this makes the service unusable with every subsequent request causes:
> {code}
> 12:32:47,296 ERROR [org.jboss.as.ejb3.invocation] (default task-4) JBAS014134: EJB Invocation failed on component MemberService for method public org.jboss.as.quickstarts.html5_mobile.model.Member org.jboss.as.quickstarts.html5_mobile.rest.MemberService.lookupMemberById(long): javax.ejb.NoSuchEJBException: JBAS014300: Could not find EJB with id {[59, -10, 2, 63, 90, 28, 72, -49, -112, -90, 12, 30, -11, -1, -105, -104]}
> 	at org.jboss.as.ejb3.component.stateful.StatefulComponentInstanceInterceptor.processInvocation(StatefulComponentInstanceInterceptor.java:62) [wildfly-ejb3-8.0.0.Final.jar:8.0.0.Final]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:273) [wildfly-ejb3-8.0.0.Final.jar:8.0.0.Final]
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:340) [wildfly-ejb3-8.0.0.Final.jar:8.0.0.Final]
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:239) [wildfly-ejb3-8.0.0.Final.jar:8.0.0.Final]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> 	at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41) [wildfly-ejb3-8.0.0.Final.jar:8.0.0.Final]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> 	at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:43) [wildfly-ejb3-8.0.0.Final.jar:8.0.0.Final]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> 	at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:95) [wildfly-ejb3-8.0.0.Final.jar:8.0.0.Final]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> 	at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64) [wildfly-ejb3-8.0.0.Final.jar:8.0.0.Final]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> 	at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:59) [wildfly-ejb3-8.0.0.Final.jar:8.0.0.Final]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> 	at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> 	at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:55) [wildfly-ejb3-8.0.0.Final.jar:8.0.0.Final]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> 	at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> 	at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:326)
> 	at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:448)
> 	at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> 	at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:326)
> 	at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:185)
> 	at org.jboss.as.ee.component.ViewDescription$1.processInvocation(ViewDescription.java:182)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocationHandler.java:73)
> 	at org.jboss.as.quickstarts.html5_mobile.rest.MemberService$$$view2.lookupMemberById(Unknown Source) [classes:]
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_51]
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_51]
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_51]
> 	at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_51]
> 	at org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:137) [resteasy-jaxrs-3.0.6.Final.jar:]
> 	at org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget(ResourceMethodInvoker.java:280) [resteasy-jaxrs-3.0.6.Final.jar:]
> 	at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:234) [resteasy-jaxrs-3.0.6.Final.jar:]
> 	at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:221) [resteasy-jaxrs-3.0.6.Final.jar:]
> 	at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:356) [resteasy-jaxrs-3.0.6.Final.jar:]
> 	at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:179) [resteasy-jaxrs-3.0.6.Final.jar:]
> 	at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:220) [resteasy-jaxrs-3.0.6.Final.jar:]
> 	at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56) [resteasy-jaxrs-3.0.6.Final.jar:]
> 	at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51) [resteasy-jaxrs-3.0.6.Final.jar:]
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) [jboss-servlet-api_3.1_spec-1.0.0.Final.jar:1.0.0.Final]
> 	at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85) [undertow-servlet-1.0.0.Final.jar:1.0.0.Final]
> 	at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:130) [undertow-servlet-1.0.0.Final.jar:1.0.0.Final]
> 	at org.jboss.as.quickstarts.html5_mobile.util.JSONPRequestFilter.doFilter(JSONPRequestFilter.java:80) [classes:]
> 	at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:56) [undertow-servlet-1.0.0.Final.jar:1.0.0.Final]
> 	at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132) [undertow-servlet-1.0.0.Final.jar:1.0.0.Final]
> 	at io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:85) [undertow-servlet-1.0.0.Final.jar:1.0.0.Final]
> 	at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:61) [undertow-servlet-1.0.0.Final.jar:1.0.0.Final]
> 	at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.0.0.Final.jar:1.0.0.Final]
> 	at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Final.jar:1.0.0.Final]
> 	at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:113) [undertow-servlet-1.0.0.Final.jar:1.0.0.Final]
> 	at io.undertow.security.handlers.AuthenticationCallHandler.handleRequest(AuthenticationCallHandler.java:52) [undertow-core-1.0.0.Final.jar:1.0.0.Final]
> 	at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) [undertow-core-1.0.0.Final.jar:1.0.0.Final]
> 	at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:61) [undertow-servlet-1.0.0.Final.jar:1.0.0.Final]
> 	at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:70) [undertow-servlet-1.0.0.Final.jar:1.0.0.Final]
> 	at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76) [undertow-core-1.0.0.Final.jar:1.0.0.Final]
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Final.jar:1.0.0.Final]
> 	at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Final.jar:1.0.0.Final]
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Final.jar:1.0.0.Final]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:240) [undertow-servlet-1.0.0.Final.jar:1.0.0.Final]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:227) [undertow-servlet-1.0.0.Final.jar:1.0.0.Final]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:73) [undertow-servlet-1.0.0.Final.jar:1.0.0.Final]
> 	at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:146) [undertow-servlet-1.0.0.Final.jar:1.0.0.Final]
> 	at io.undertow.server.Connectors.executeRootHandler(Connectors.java:168) [undertow-core-1.0.0.Final.jar:1.0.0.Final]
> 	at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:687) [undertow-core-1.0.0.Final.jar:1.0.0.Final]
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_51]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_51]
> 	at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_51]
> {code}

--
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

From issues at jboss.org  Thu Mar  6 04:51:38 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 6 Mar 2014 04:51:38 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2498) Logout of secured (ssl) admin
 console setup redirects to http address
In-Reply-To: <JIRA.12524948.1384302668000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12524948.1384302668000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12524948.1384302668000.8034.1394099498405@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2498?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12950598#comment-12950598 ] 

RH Bugzilla Integration commented on WFLY-2498:
-----------------------------------------------

FIlip Bogyai <fbogyai at redhat.com> changed the Status of [bug 1029687|https://bugzilla.redhat.com/show_bug.cgi?id=1029687] from ON_QA to VERIFIED
                
>  Logout of secured (ssl) admin console setup redirects to http address
> ----------------------------------------------------------------------
>
>                 Key: WFLY-2498
>                 URL: https://issues.jboss.org/browse/WFLY-2498
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management, Web Console
>            Reporter: Chris Dolphy
>            Assignee: Darran Lofthouse
>             Fix For: 8.0.0.Final
>
>
> Description of problem:
> Logging out of an admin console secured with SSL (on port 9443) redirects to http address (e.g. http://localhost:9443/logout?logout) which leads to a Page Not Found error.

--
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

From issues at jboss.org  Thu Mar  6 05:51:33 2014
From: issues at jboss.org (Raj Haque (JIRA))
Date: Thu, 6 Mar 2014 05:51:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JBDEPLOY-280) ContextClassLoader is not
 working when war is zipped in Jboss as-7.1.1
In-Reply-To: <JIRA.12534260.1394103073946@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534260.1394103073946@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534260.1394103073946.8189.1394103093132@jira02.app.mwc.hst.phx2.redhat.com>

Raj Haque created JBDEPLOY-280:
----------------------------------

             Summary: ContextClassLoader is not working when war is zipped in Jboss as-7.1.1
                 Key: JBDEPLOY-280
                 URL: https://issues.jboss.org/browse/JBDEPLOY-280
             Project: JBoss Deployers
          Issue Type: Bug
          Components: classloading, deployer, release
         Environment: mac osx,  eclipse kepler ,Apache Maven 3.0.4, java 1.7_0_45 and JBoss Application Server 7.1.1
            Reporter: Raj Haque


I have some resources(reports and native sql) on my class path. When I unzip the war I can see them under  the classes folder.
 
I have been using
Thread.currentThread().getContextClassLoader(). getResource(".........................");
 
This works fine when war is exploded but not when zipped. Hence I can not use JBoss maven deployments.
I also have some more resources under jar files (jars inside the war file) . It is the same . I can not access them any more.

I know this issue have been discussed in several post e.g.

https://community.jboss.org/thread/202208

https://community.jboss.org/message/761846#761846

But none of them answers correctly.
 
Any help will be much appreciated.
 
Thanks In advance.


--
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

From issues at jboss.org  Thu Mar  6 06:05:34 2014
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Thu, 6 Mar 2014 06:05:34 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3073) MBeanServer.createMBean
 methods that take a classloader don't work
In-Reply-To: <JIRA.12534226.1394051286000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534226.1394051286000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534226.1394051286000.8221.1394103934246@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-3073?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12950632#comment-12950632 ] 

Kabir Khan commented on WFLY-3073:
----------------------------------

These should probably pass in the loaderName rather than the name of the mbean to create to findDelegate()?
                
> MBeanServer.createMBean methods that take a classloader don't work
> ------------------------------------------------------------------
>
>                 Key: WFLY-3073
>                 URL: https://issues.jboss.org/browse/WFLY-3073
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JMX
>    Affects Versions: 8.0.0.Final
>            Reporter: Stuart Douglas
>            Assignee: Kabir Khan
>             Fix For: 8.0.1.Final
>
>
> The MBeanServer.createMBean methods that take an "ObjectName loaderName" argument are completely broken in EAP 6.
> These methods call findDelegate to make sure there is already an existing MBean registered with the given name passed in for the new MBean, or else it throws an exception.
> This is obviously wrong, as there'd be no point in calling createMBean if it already existed.
> javax.management.InstanceNotFoundException: test:service=Test
> at org.jboss.as.jmx.PluggableMBeanServerImpl.findDelegate(PluggableMBeanServerImpl.java:1083)
> at org.jboss.as.jmx.PluggableMBeanServerImpl.createMBean(PluggableMBeanServerImpl.java:253)

--
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

From issues at jboss.org  Thu Mar  6 06:11:33 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 6 Mar 2014 06:11:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2660) LDAP Group Loading - Should
 Not Fail for Non-existent User.
In-Reply-To: <JIRA.12528037.1387216541000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528037.1387216541000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528037.1387216541000.8230.1394104293358@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2660?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12950634#comment-12950634 ] 

RH Bugzilla Integration commented on WFLY-2660:
-----------------------------------------------

Ondrej Lukas <olukas at redhat.com> changed the Status of [bug 1043667|https://bugzilla.redhat.com/show_bug.cgi?id=1043667] from ON_QA to ASSIGNED
                
> LDAP Group Loading - Should Not Fail for Non-existent User.
> -----------------------------------------------------------
>
>                 Key: WFLY-2660
>                 URL: https://issues.jboss.org/browse/WFLY-2660
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management, Security
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>            Priority: Critical
>             Fix For: 8.0.0.Final
>
>
> Where a security realm is configured to load groups from LDAP it should not cause an authentication failure if the user is not found in LDAP.
> One example is local authentication where the user may not exist.
> Another is domain mode servers where the servers have a custom name and generated password that they use to connect back to the local host controller.

--
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

From issues at jboss.org  Thu Mar  6 06:21:33 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 6 Mar 2014 06:21:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2536) NPE in cli is thrown when
 using preserve, override without parameter
In-Reply-To: <JIRA.12525558.1384866491000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12525558.1384866491000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12525558.1384866491000.8246.1394104893556@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12950637#comment-12950637 ] 

RH Bugzilla Integration commented on WFLY-2536:
-----------------------------------------------

Jan Martiska <jmartisk at redhat.com> changed the Status of [bug 1032041|https://bugzilla.redhat.com/show_bug.cgi?id=1032041] from ON_QA to VERIFIED
                
> NPE in cli is thrown when using preserve, override without parameter
> --------------------------------------------------------------------
>
>                 Key: WFLY-2536
>                 URL: https://issues.jboss.org/browse/WFLY-2536
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Patching
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Emanuel Muckenhuber
>            Assignee: Alexey Loubyansky
>            Priority: Minor
>             Fix For: 8.0.0.CR1
>
>


--
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

From issues at jboss.org  Thu Mar  6 07:05:33 2014
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 6 Mar 2014 07:05:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2581) Provide API for use by
 ejb-security-interceptors quick start.
In-Reply-To: <JIRA.12526186.1385483434000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12526186.1385483434000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12526186.1385483434000.8409.1394107533437@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2581?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12950657#comment-12950657 ] 

Darran Lofthouse commented on WFLY-2581:
----------------------------------------

Pull request to also update the quickstarts: -
  https://github.com/wildfly/quickstart/pull/20
                
> Provide API for use by ejb-security-interceptors quick start.
> -------------------------------------------------------------
>
>                 Key: WFLY-2581
>                 URL: https://issues.jboss.org/browse/WFLY-2581
>             Project: WildFly
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Security
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 8.0.1.Final
>
>
> The quick start accesses the currently authenticated user, unfortunately this representation is with a bunch of internal implementation classes.
> ? org.jboss.as.domain.management.security.RealmUser.
> ? org.jboss.as.security.remoting.RemotingContext.
> ? org.jboss.as.controller.security.SubjectUserInfo
> The first problem is the RemotingContext, we use it internally to associate the remoting connection with the thread processing the request, the only reason we really use it is to obtain the identity of the user associated with the connection, we may be better simplifying this down to just associate a simple ConnectionSecurityContext with the thread instead.
> Secondly once we have used the identity associated with the connection we clear the association, this is probably the wrong way round and instead we should be setting something to say we have used the identity.
> The SubjectUserInfo is essentially the ConnectionSecurityContext I mention above, we need a simple representation of this that can be used.
> Finally there is RealmUser, we should also add RealmGroup - these two classes just need to be in their own public module or inherit from something that is.
> As a closing point should these be marked as deprecated?  Security services are being re-worked in WildFly and this whole quick start is just an alternative solution to the new services.

--
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


From issues at jboss.org  Thu Mar  6 07:11:33 2014
From: issues at jboss.org (Rituraj Sinha (JIRA))
Date: Thu, 6 Mar 2014 07:11:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3051) JMX connection to remote
 server-instances is not happening in wildfly 8.0.0.Final in domain mode
In-Reply-To: <JIRA.12533723.1393825342000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12533723.1393825342000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12533723.1393825342000.8437.1394107893875@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-3051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12950661#comment-12950661 ] 

Rituraj Sinha commented on WFLY-3051:
-------------------------------------

Hi Darran 

can we get some information as how much time it is going to take ...thanks for looking into it...

Thanks

                
> JMX connection to remote server-instances is not happening in wildfly 8.0.0.Final in domain mode
> ------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-3051
>                 URL: https://issues.jboss.org/browse/WFLY-3051
>             Project: WildFly
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: JMX, Remoting
>    Affects Versions: 8.0.0.Final
>            Reporter: Rituraj Sinha
>            Assignee: Darran Lofthouse
>             Fix For: 8.0.1.Final
>
>
> i have gone through the below link for JMX subsystem for wildfly 8 as
> https://docs.jboss.org/author/display/WFLY8/JMX+subsystem+configuration
>  
> but unable to connect to server-instances running remotely ...i have posted my question there as well and pasting it here now ...
> can someone please give us the steps to configure JMX through jconsole...?
> changes done on the domain.xml are the same as stated above
> <subsystem xmlns="urn:jboss:domain:jmx:1.3">
>                 <expose-resolved-model/>
>                 <expose-expression-model/>
>                 <remoting-connector use-management-endpoint="false"/>
>             </subsystem>
> <subsystem xmlns="urn:jboss:domain:jmx:1.3">
>                 <expose-resolved-model/>
>                 <expose-expression-model/>
>                 <remoting-connector use-management-endpoint="false"/>
>             </subsystem>
> as per the jboss-as-jmx_1_3.xsd  its like
> <xs:attribute name="use-management-endpoint" type="xs:boolean" default="true" use="optional" >
>             <xs:annotation>
>                 <xs:documentation>
>                     If true then this connector will use the management endpoint, otherwise it will use the
>                     remoting subsystem endpoint.
>                 </xs:documentation>
>             </xs:annotation>
>         </xs:attribute>
> now if we are making it false then it should be using the remoting endpoint ...now remoting subsystem by default uses ApplicatoinRealm
> i have created application-user and password for the same but when i am trying to connect to remote server-instances its not connecting it....
> below is what i am able to connect to 
> service:jmx:http-remoting-jmx://remote_hostA:9990 --
> Unknown macro: {host A is where my domain_controller is running}
> how can i access the server-instances running on domain_controller
> Unknown macro: {there are three server_instanaces running on HostA with a port offset of 100 each}
> i am trying to connect with the below url as 
> service:jmx:http-remoting-jmx://lremote_hostA:8180
> let me know if something is missing from my side...
> Thanks

--
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

From issues at jboss.org  Thu Mar  6 07:15:34 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 6 Mar 2014 07:15:34 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2949) Cannot get exception as
	pass-by-reference
In-Reply-To: <JIRA.12532450.1392708507000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12532450.1392708507000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12532450.1392708507000.8452.1394108134436@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2949?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12950664#comment-12950664 ] 

RH Bugzilla Integration commented on WFLY-2949:
-----------------------------------------------

Jan Martiska <jmartisk at redhat.com> changed the Status of [bug 1055896|https://bugzilla.redhat.com/show_bug.cgi?id=1055896] from ON_QA to VERIFIED
                
> Cannot get exception as pass-by-reference
> -----------------------------------------
>
>                 Key: WFLY-2949
>                 URL: https://issues.jboss.org/browse/WFLY-2949
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: EJB
>    Affects Versions: 8.0.0.Final
>            Reporter: Osamu Nagano
>            Assignee: David Lloyd
>             Fix For: 8.0.1.Final
>
>
> Despite of {{<in-vm-remote-interface-invocation pass-by-value="false"/>}}, an exception is not thrown by reference, which results in {{java.io.NotSerializableException}} if the exception doesn't implement {{Serializable}}.  This is a blocker of a large migration project from WebLogic because it throws by reference even if that doesn't implement {{Serializable}}.

--
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

From issues at jboss.org  Thu Mar  6 07:25:33 2014
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Thu, 6 Mar 2014 07:25:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3073) MBeanServer.createMBean
 methods that take a classloader don't work
In-Reply-To: <JIRA.12534226.1394051286000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534226.1394051286000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534226.1394051286000.8465.1394108733580@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-3073?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12950666#comment-12950666 ] 

Kabir Khan commented on WFLY-3073:
----------------------------------

Never mind, your fix looks fine
                
> MBeanServer.createMBean methods that take a classloader don't work
> ------------------------------------------------------------------
>
>                 Key: WFLY-3073
>                 URL: https://issues.jboss.org/browse/WFLY-3073
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JMX
>    Affects Versions: 8.0.0.Final
>            Reporter: Stuart Douglas
>            Assignee: Kabir Khan
>             Fix For: 8.0.1.Final
>
>
> The MBeanServer.createMBean methods that take an "ObjectName loaderName" argument are completely broken in EAP 6.
> These methods call findDelegate to make sure there is already an existing MBean registered with the given name passed in for the new MBean, or else it throws an exception.
> This is obviously wrong, as there'd be no point in calling createMBean if it already existed.
> javax.management.InstanceNotFoundException: test:service=Test
> at org.jboss.as.jmx.PluggableMBeanServerImpl.findDelegate(PluggableMBeanServerImpl.java:1083)
> at org.jboss.as.jmx.PluggableMBeanServerImpl.createMBean(PluggableMBeanServerImpl.java:253)

--
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

From issues at jboss.org  Thu Mar  6 07:39:33 2014
From: issues at jboss.org (Michal Babacek (JIRA))
Date: Thu, 6 Mar 2014 07:39:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JBWEB-292) Http11Nio loaded even with
 native="false", JBWEB002081: No cipher match
In-Reply-To: <JIRA.12534270.1394109559317@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534270.1394109559317@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534270.1394109559317.8500.1394109573409@jira02.app.mwc.hst.phx2.redhat.com>

Michal Babacek created JBWEB-292:
------------------------------------

             Summary: Http11Nio loaded even with native="false", JBWEB002081: No cipher match
                 Key: JBWEB-292
                 URL: https://issues.jboss.org/browse/JBWEB-292
             Project: JBoss Web
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
    Affects Versions: JBossWeb-7.4.0.GA
            Reporter: Michal Babacek
            Assignee: Remy Maucherat
            Priority: Critical
             Fix For: JBossWeb-7.4.0.GA


Hi guys,

I have an SSL test that sets up the web subsystem with HTTPS connector only and uses HTTPS with mod_cluster.

{code}
        <subsystem xmlns="urn:jboss:domain:modcluster:1.2">
            <mod-cluster-config advertise-socket="modcluster" connector="https">
                <dynamic-load-provider>
                    <load-metric type="busyness"/>
                </dynamic-load-provider>
                <ssl key-alias="javaclient" 
                     password="tomcat" 
                     certificate-key-file="/tmp/ews-eap6/client-cert-key.jks" 
                     cipher-suite="AES128-SHA:ALL:!ADH:!LOW:!MD5:!SSLV2:!NULL" 
                     ca-certificate-file="/tmp/ews-eap6/ca-cert.jks"
                />
            </mod-cluster-config>
        </subsystem>

        <subsystem xmlns="urn:jboss:domain:web:1.5" native="false">
            <connector name="https" protocol="HTTP/1.1" scheme="https" socket-binding="https" secure="true" enabled="true">
                <ssl name="https" 
                    key-alias="javaclient" 
                    password="tomcat" 
                    certificate-key-file="/tmp/ews-eap6/client-cert-key.jks" 
                    cipher-suite="AES128-SHA:ALL:!ADH:!LOW:!MD5:!SSLV2:!NULL" 
                    protocol="TLS" verify-client="false" 
                    certificate-file="/tmp/ews-eap6/client-cert-key.jks" 
                    ca-certificate-file="/tmp/ews-eap6/ca-cert.jks"/>
            </connector>
            <virtual-server name="default-host" enable-welcome-root="true">
                <alias name="localhost"/>
                <alias name="example.com"/>
            </virtual-server>
        </subsystem>
{code}

Notice that while EAP 6.3.0.DR1 with *jbossweb-7.3.0.Final* uses {{org.apache.coyote.http11}}, even if natives are unpacked in {{modules/system/layers/base/org/jboss/as/web/main/lib/linux-x86_64/libtcnative-1.so}}, because there is {{native="false"}} in the web subsystem configuration,  EAP 6.3.0.DR2 with *jbossweb-7.4.0.Beta4* tries to start {{org.apache.coyote.http11.Http11NioProtocol}} despite having {{native="false"}}. 

This causes cipher suite errors, because the native implementation doesn't know what to do with it...

* EAP 6.3.0.DR1 with jbossweb-7.3.0.Final passes this test with no exceptions thrown.
* EAP 6.3.0.DR2 with jbossweb-7.4.0.Beta4 causes:

{noformat}
06:18:26,649 ERROR [org.apache.coyote.http11.Http11NioProtocol] (MSC service thread 1-17) JBWEB003043: Error initializing endpoint: java.io.IOException: JBWEB002081: No cipher match
    at org.apache.tomcat.util.net.jsse.NioJSSESocketChannelFactory.init(NioJSSESocketChannelFactory.java:315) [jbossweb-7.4.0.Beta4.jar:7.4.0.Beta4]
    at org.apache.tomcat.util.net.NioEndpoint.init(NioEndpoint.java:205) [jbossweb-7.4.0.Beta4.jar:7.4.0.Beta4]
    at org.apache.coyote.http11.Http11NioProtocol.init(Http11NioProtocol.java:113) [jbossweb-7.4.0.Beta4.jar:7.4.0.Beta4]
    at org.apache.catalina.connector.Connector.init(Connector.java:983) [jbossweb-7.4.0.Beta4.jar:7.4.0.Beta4]
    at org.jboss.as.web.WebConnectorService.start(WebConnectorService.java:304) [jboss-as-web-7.4.0.Final-redhat-2.jar:7.4.0.Final-redhat-2]
    at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1980) [jboss-msc-1.1.5.Final.jar:1.1.5.Final]
    at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1913) [jboss-msc-1.1.5.Final.jar:1.1.5.Final]
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_51]
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_51]
    at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_51]
Caused by: java.io.IOException: JBWEB002081: No cipher match
    at org.apache.tomcat.util.net.jsse.NioJSSESocketChannelFactory.getEnabledCiphers(NioJSSESocketChannelFactory.java:399) [jbossweb-7.4.0.Beta4.jar:7.4.0.Beta4]
    at org.apache.tomcat.util.net.jsse.NioJSSESocketChannelFactory.init(NioJSSESocketChannelFactory.java:305) [jbossweb-7.4.0.Beta4.jar:7.4.0.Beta4]
    ... 9 more

06:18:26,663 INFO  [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-39) JBAS010400: Bound data source [java:jboss/datasources/ExampleDS]
06:18:26,672 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-17) MSC000001: Failed to start service jboss.web.connector.https: org.jboss.msc.service.StartException in service jboss.web.connector.https: JBAS018007: Error starting web connector
    at org.jboss.as.web.WebConnectorService.start(WebConnectorService.java:362)
    at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1980) [jboss-msc-1.1.5.Final.jar:1.1.5.Final]
    at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1913) [jboss-msc-1.1.5.Final.jar:1.1.5.Final]
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_51]
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_51]
    at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_51]
Caused by: LifecycleException:  JBWEB000023: Protocol handler initialization failed
    at org.apache.catalina.connector.Connector.init(Connector.java:985)
    at org.jboss.as.web.WebConnectorService.start(WebConnectorService.java:304)
    ... 5 more
{noformat}

Any ideas?

--
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

From issues at jboss.org  Thu Mar  6 07:43:33 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 6 Mar 2014 07:43:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JBWEB-292) Http11Nio loaded even with
 native="false", JBWEB002081: No cipher match
In-Reply-To: <JIRA.12534270.1394109559000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534270.1394109559000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534270.1394109559000.8510.1394109813605@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBWEB-292?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated JBWEB-292:
------------------------------------------

        Bugzilla Update: Perform
    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1073430

    
> Http11Nio loaded even with native="false", JBWEB002081: No cipher match
> -----------------------------------------------------------------------
>
>                 Key: JBWEB-292
>                 URL: https://issues.jboss.org/browse/JBWEB-292
>             Project: JBoss Web
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>    Affects Versions: JBossWeb-7.4.0.GA
>            Reporter: Michal Babacek
>            Assignee: Remy Maucherat
>            Priority: Critical
>             Fix For: JBossWeb-7.4.0.GA
>
>
> Hi guys,
> I have an SSL test that sets up the web subsystem with HTTPS connector only and uses HTTPS with mod_cluster.
> {code}
>         <subsystem xmlns="urn:jboss:domain:modcluster:1.2">
>             <mod-cluster-config advertise-socket="modcluster" connector="https">
>                 <dynamic-load-provider>
>                     <load-metric type="busyness"/>
>                 </dynamic-load-provider>
>                 <ssl key-alias="javaclient" 
>                      password="tomcat" 
>                      certificate-key-file="/tmp/ews-eap6/client-cert-key.jks" 
>                      cipher-suite="AES128-SHA:ALL:!ADH:!LOW:!MD5:!SSLV2:!NULL" 
>                      ca-certificate-file="/tmp/ews-eap6/ca-cert.jks"
>                 />
>             </mod-cluster-config>
>         </subsystem>
>         <subsystem xmlns="urn:jboss:domain:web:1.5" native="false">
>             <connector name="https" protocol="HTTP/1.1" scheme="https" socket-binding="https" secure="true" enabled="true">
>                 <ssl name="https" 
>                     key-alias="javaclient" 
>                     password="tomcat" 
>                     certificate-key-file="/tmp/ews-eap6/client-cert-key.jks" 
>                     cipher-suite="AES128-SHA:ALL:!ADH:!LOW:!MD5:!SSLV2:!NULL" 
>                     protocol="TLS" verify-client="false" 
>                     certificate-file="/tmp/ews-eap6/client-cert-key.jks" 
>                     ca-certificate-file="/tmp/ews-eap6/ca-cert.jks"/>
>             </connector>
>             <virtual-server name="default-host" enable-welcome-root="true">
>                 <alias name="localhost"/>
>                 <alias name="example.com"/>
>             </virtual-server>
>         </subsystem>
> {code}
> Notice that while EAP 6.3.0.DR1 with *jbossweb-7.3.0.Final* uses {{org.apache.coyote.http11}}, even if natives are unpacked in {{modules/system/layers/base/org/jboss/as/web/main/lib/linux-x86_64/libtcnative-1.so}}, because there is {{native="false"}} in the web subsystem configuration,  EAP 6.3.0.DR2 with *jbossweb-7.4.0.Beta4* tries to start {{org.apache.coyote.http11.Http11NioProtocol}} despite having {{native="false"}}. 
> This causes cipher suite errors, because the native implementation doesn't know what to do with it...
> * EAP 6.3.0.DR1 with jbossweb-7.3.0.Final passes this test with no exceptions thrown.
> * EAP 6.3.0.DR2 with jbossweb-7.4.0.Beta4 causes:
> {noformat}
> 06:18:26,649 ERROR [org.apache.coyote.http11.Http11NioProtocol] (MSC service thread 1-17) JBWEB003043: Error initializing endpoint: java.io.IOException: JBWEB002081: No cipher match
>     at org.apache.tomcat.util.net.jsse.NioJSSESocketChannelFactory.init(NioJSSESocketChannelFactory.java:315) [jbossweb-7.4.0.Beta4.jar:7.4.0.Beta4]
>     at org.apache.tomcat.util.net.NioEndpoint.init(NioEndpoint.java:205) [jbossweb-7.4.0.Beta4.jar:7.4.0.Beta4]
>     at org.apache.coyote.http11.Http11NioProtocol.init(Http11NioProtocol.java:113) [jbossweb-7.4.0.Beta4.jar:7.4.0.Beta4]
>     at org.apache.catalina.connector.Connector.init(Connector.java:983) [jbossweb-7.4.0.Beta4.jar:7.4.0.Beta4]
>     at org.jboss.as.web.WebConnectorService.start(WebConnectorService.java:304) [jboss-as-web-7.4.0.Final-redhat-2.jar:7.4.0.Final-redhat-2]
>     at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1980) [jboss-msc-1.1.5.Final.jar:1.1.5.Final]
>     at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1913) [jboss-msc-1.1.5.Final.jar:1.1.5.Final]
>     at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_51]
>     at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_51]
>     at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_51]
> Caused by: java.io.IOException: JBWEB002081: No cipher match
>     at org.apache.tomcat.util.net.jsse.NioJSSESocketChannelFactory.getEnabledCiphers(NioJSSESocketChannelFactory.java:399) [jbossweb-7.4.0.Beta4.jar:7.4.0.Beta4]
>     at org.apache.tomcat.util.net.jsse.NioJSSESocketChannelFactory.init(NioJSSESocketChannelFactory.java:305) [jbossweb-7.4.0.Beta4.jar:7.4.0.Beta4]
>     ... 9 more
> 06:18:26,663 INFO  [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-39) JBAS010400: Bound data source [java:jboss/datasources/ExampleDS]
> 06:18:26,672 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-17) MSC000001: Failed to start service jboss.web.connector.https: org.jboss.msc.service.StartException in service jboss.web.connector.https: JBAS018007: Error starting web connector
>     at org.jboss.as.web.WebConnectorService.start(WebConnectorService.java:362)
>     at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1980) [jboss-msc-1.1.5.Final.jar:1.1.5.Final]
>     at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1913) [jboss-msc-1.1.5.Final.jar:1.1.5.Final]
>     at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_51]
>     at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_51]
>     at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_51]
> Caused by: LifecycleException:  JBWEB000023: Protocol handler initialization failed
>     at org.apache.catalina.connector.Connector.init(Connector.java:985)
>     at org.jboss.as.web.WebConnectorService.start(WebConnectorService.java:304)
>     ... 5 more
> {noformat}
> Any ideas?

--
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

From issues at jboss.org  Thu Mar  6 08:07:33 2014
From: issues at jboss.org (Michal Babacek (JIRA))
Date: Thu, 6 Mar 2014 08:07:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JBWEB-292) Http11Nio loaded,
 JBWEB002081: No cipher match
In-Reply-To: <JIRA.12534270.1394109559000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534270.1394109559000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534270.1394109559000.8554.1394111253675@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBWEB-292?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Michal Babacek updated JBWEB-292:
---------------------------------

    Summary: Http11Nio loaded, JBWEB002081: No cipher match  (was: Http11Nio loaded even with native="false", JBWEB002081: No cipher match)

    
> Http11Nio loaded, JBWEB002081: No cipher match
> ----------------------------------------------
>
>                 Key: JBWEB-292
>                 URL: https://issues.jboss.org/browse/JBWEB-292
>             Project: JBoss Web
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>    Affects Versions: JBossWeb-7.4.0.GA
>            Reporter: Michal Babacek
>            Assignee: Remy Maucherat
>            Priority: Critical
>             Fix For: JBossWeb-7.4.0.GA
>
>
> Hi guys,
> I have an SSL test that sets up the web subsystem with HTTPS connector only and uses HTTPS with mod_cluster.
> {code}
>         <subsystem xmlns="urn:jboss:domain:modcluster:1.2">
>             <mod-cluster-config advertise-socket="modcluster" connector="https">
>                 <dynamic-load-provider>
>                     <load-metric type="busyness"/>
>                 </dynamic-load-provider>
>                 <ssl key-alias="javaclient" 
>                      password="tomcat" 
>                      certificate-key-file="/tmp/ews-eap6/client-cert-key.jks" 
>                      cipher-suite="AES128-SHA:ALL:!ADH:!LOW:!MD5:!SSLV2:!NULL" 
>                      ca-certificate-file="/tmp/ews-eap6/ca-cert.jks"
>                 />
>             </mod-cluster-config>
>         </subsystem>
>         <subsystem xmlns="urn:jboss:domain:web:1.5" native="false">
>             <connector name="https" protocol="HTTP/1.1" scheme="https" socket-binding="https" secure="true" enabled="true">
>                 <ssl name="https" 
>                     key-alias="javaclient" 
>                     password="tomcat" 
>                     certificate-key-file="/tmp/ews-eap6/client-cert-key.jks" 
>                     cipher-suite="AES128-SHA:ALL:!ADH:!LOW:!MD5:!SSLV2:!NULL" 
>                     protocol="TLS" verify-client="false" 
>                     certificate-file="/tmp/ews-eap6/client-cert-key.jks" 
>                     ca-certificate-file="/tmp/ews-eap6/ca-cert.jks"/>
>             </connector>
>             <virtual-server name="default-host" enable-welcome-root="true">
>                 <alias name="localhost"/>
>                 <alias name="example.com"/>
>             </virtual-server>
>         </subsystem>
> {code}
> Notice that while EAP 6.3.0.DR1 with *jbossweb-7.3.0.Final* uses {{org.apache.coyote.http11}}, even if natives are unpacked in {{modules/system/layers/base/org/jboss/as/web/main/lib/linux-x86_64/libtcnative-1.so}}, because there is {{native="false"}} in the web subsystem configuration,  EAP 6.3.0.DR2 with *jbossweb-7.4.0.Beta4* tries to start {{org.apache.coyote.http11.Http11NioProtocol}} despite having {{native="false"}}. 
> This causes cipher suite errors, because the native implementation doesn't know what to do with it...
> * EAP 6.3.0.DR1 with jbossweb-7.3.0.Final passes this test with no exceptions thrown.
> * EAP 6.3.0.DR2 with jbossweb-7.4.0.Beta4 causes:
> {noformat}
> 06:18:26,649 ERROR [org.apache.coyote.http11.Http11NioProtocol] (MSC service thread 1-17) JBWEB003043: Error initializing endpoint: java.io.IOException: JBWEB002081: No cipher match
>     at org.apache.tomcat.util.net.jsse.NioJSSESocketChannelFactory.init(NioJSSESocketChannelFactory.java:315) [jbossweb-7.4.0.Beta4.jar:7.4.0.Beta4]
>     at org.apache.tomcat.util.net.NioEndpoint.init(NioEndpoint.java:205) [jbossweb-7.4.0.Beta4.jar:7.4.0.Beta4]
>     at org.apache.coyote.http11.Http11NioProtocol.init(Http11NioProtocol.java:113) [jbossweb-7.4.0.Beta4.jar:7.4.0.Beta4]
>     at org.apache.catalina.connector.Connector.init(Connector.java:983) [jbossweb-7.4.0.Beta4.jar:7.4.0.Beta4]
>     at org.jboss.as.web.WebConnectorService.start(WebConnectorService.java:304) [jboss-as-web-7.4.0.Final-redhat-2.jar:7.4.0.Final-redhat-2]
>     at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1980) [jboss-msc-1.1.5.Final.jar:1.1.5.Final]
>     at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1913) [jboss-msc-1.1.5.Final.jar:1.1.5.Final]
>     at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_51]
>     at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_51]
>     at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_51]
> Caused by: java.io.IOException: JBWEB002081: No cipher match
>     at org.apache.tomcat.util.net.jsse.NioJSSESocketChannelFactory.getEnabledCiphers(NioJSSESocketChannelFactory.java:399) [jbossweb-7.4.0.Beta4.jar:7.4.0.Beta4]
>     at org.apache.tomcat.util.net.jsse.NioJSSESocketChannelFactory.init(NioJSSESocketChannelFactory.java:305) [jbossweb-7.4.0.Beta4.jar:7.4.0.Beta4]
>     ... 9 more
> 06:18:26,663 INFO  [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-39) JBAS010400: Bound data source [java:jboss/datasources/ExampleDS]
> 06:18:26,672 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-17) MSC000001: Failed to start service jboss.web.connector.https: org.jboss.msc.service.StartException in service jboss.web.connector.https: JBAS018007: Error starting web connector
>     at org.jboss.as.web.WebConnectorService.start(WebConnectorService.java:362)
>     at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1980) [jboss-msc-1.1.5.Final.jar:1.1.5.Final]
>     at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1913) [jboss-msc-1.1.5.Final.jar:1.1.5.Final]
>     at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_51]
>     at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_51]
>     at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_51]
> Caused by: LifecycleException:  JBWEB000023: Protocol handler initialization failed
>     at org.apache.catalina.connector.Connector.init(Connector.java:985)
>     at org.jboss.as.web.WebConnectorService.start(WebConnectorService.java:304)
>     ... 5 more
> {noformat}
> Any ideas?

--
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

From issues at jboss.org  Thu Mar  6 08:11:33 2014
From: issues at jboss.org (Michal Babacek (JIRA))
Date: Thu, 6 Mar 2014 08:11:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JBWEB-292) Http11Nio loaded,
 JBWEB002081: No cipher match
In-Reply-To: <JIRA.12534270.1394109559000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534270.1394109559000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534270.1394109559000.8591.1394111493830@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBWEB-292?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Michal Babacek updated JBWEB-292:
---------------------------------

    Description: 
Hi guys,

I have an SSL test that sets up the web subsystem with HTTPS connector only and uses HTTPS with mod_cluster.

{code}
        <subsystem xmlns="urn:jboss:domain:modcluster:1.2">
            <mod-cluster-config advertise-socket="modcluster" connector="https">
                <dynamic-load-provider>
                    <load-metric type="busyness"/>
                </dynamic-load-provider>
                <ssl key-alias="javaclient" 
                     password="tomcat" 
                     certificate-key-file="/tmp/ews-eap6/client-cert-key.jks" 
                     cipher-suite="AES128-SHA:ALL:!ADH:!LOW:!MD5:!SSLV2:!NULL" 
                     ca-certificate-file="/tmp/ews-eap6/ca-cert.jks"
                />
            </mod-cluster-config>
        </subsystem>

        <subsystem xmlns="urn:jboss:domain:web:1.5" native="false">
            <connector name="https" protocol="HTTP/1.1" scheme="https" socket-binding="https" secure="true" enabled="true">
                <ssl name="https" 
                    key-alias="javaclient" 
                    password="tomcat" 
                    certificate-key-file="/tmp/ews-eap6/client-cert-key.jks" 
                    cipher-suite="AES128-SHA:ALL:!ADH:!LOW:!MD5:!SSLV2:!NULL" 
                    protocol="TLS" verify-client="false" 
                    certificate-file="/tmp/ews-eap6/client-cert-key.jks" 
                    ca-certificate-file="/tmp/ews-eap6/ca-cert.jks"/>
            </connector>
            <virtual-server name="default-host" enable-welcome-root="true">
                <alias name="localhost"/>
                <alias name="example.com"/>
            </virtual-server>
        </subsystem>
{code}

Notice that while EAP 6.3.0.DR1 with *jbossweb-7.3.0.Final* uses {{org.apache.coyote.http11}}, EAP 6.3.0.DR2 with *jbossweb-7.4.0.Beta4* tries to start {{org.apache.coyote.http11.Http11NioProtocol}}. 

This causes cipher suite errors.

* EAP 6.3.0.DR1 with jbossweb-7.3.0.Final passes this test with no exceptions thrown.
* EAP 6.3.0.DR2 with jbossweb-7.4.0.Beta4 causes:

{noformat}
06:18:26,649 ERROR [org.apache.coyote.http11.Http11NioProtocol] (MSC service thread 1-17) JBWEB003043: Error initializing endpoint: java.io.IOException: JBWEB002081: No cipher match
    at org.apache.tomcat.util.net.jsse.NioJSSESocketChannelFactory.init(NioJSSESocketChannelFactory.java:315) [jbossweb-7.4.0.Beta4.jar:7.4.0.Beta4]
    at org.apache.tomcat.util.net.NioEndpoint.init(NioEndpoint.java:205) [jbossweb-7.4.0.Beta4.jar:7.4.0.Beta4]
    at org.apache.coyote.http11.Http11NioProtocol.init(Http11NioProtocol.java:113) [jbossweb-7.4.0.Beta4.jar:7.4.0.Beta4]
    at org.apache.catalina.connector.Connector.init(Connector.java:983) [jbossweb-7.4.0.Beta4.jar:7.4.0.Beta4]
    at org.jboss.as.web.WebConnectorService.start(WebConnectorService.java:304) [jboss-as-web-7.4.0.Final-redhat-2.jar:7.4.0.Final-redhat-2]
    at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1980) [jboss-msc-1.1.5.Final.jar:1.1.5.Final]
    at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1913) [jboss-msc-1.1.5.Final.jar:1.1.5.Final]
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_51]
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_51]
    at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_51]
Caused by: java.io.IOException: JBWEB002081: No cipher match
    at org.apache.tomcat.util.net.jsse.NioJSSESocketChannelFactory.getEnabledCiphers(NioJSSESocketChannelFactory.java:399) [jbossweb-7.4.0.Beta4.jar:7.4.0.Beta4]
    at org.apache.tomcat.util.net.jsse.NioJSSESocketChannelFactory.init(NioJSSESocketChannelFactory.java:305) [jbossweb-7.4.0.Beta4.jar:7.4.0.Beta4]
    ... 9 more

06:18:26,663 INFO  [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-39) JBAS010400: Bound data source [java:jboss/datasources/ExampleDS]
06:18:26,672 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-17) MSC000001: Failed to start service jboss.web.connector.https: org.jboss.msc.service.StartException in service jboss.web.connector.https: JBAS018007: Error starting web connector
    at org.jboss.as.web.WebConnectorService.start(WebConnectorService.java:362)
    at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1980) [jboss-msc-1.1.5.Final.jar:1.1.5.Final]
    at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1913) [jboss-msc-1.1.5.Final.jar:1.1.5.Final]
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_51]
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_51]
    at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_51]
Caused by: LifecycleException:  JBWEB000023: Protocol handler initialization failed
    at org.apache.catalina.connector.Connector.init(Connector.java:985)
    at org.jboss.as.web.WebConnectorService.start(WebConnectorService.java:304)
    ... 5 more
{noformat}

Any ideas?

  was:
Hi guys,

I have an SSL test that sets up the web subsystem with HTTPS connector only and uses HTTPS with mod_cluster.

{code}
        <subsystem xmlns="urn:jboss:domain:modcluster:1.2">
            <mod-cluster-config advertise-socket="modcluster" connector="https">
                <dynamic-load-provider>
                    <load-metric type="busyness"/>
                </dynamic-load-provider>
                <ssl key-alias="javaclient" 
                     password="tomcat" 
                     certificate-key-file="/tmp/ews-eap6/client-cert-key.jks" 
                     cipher-suite="AES128-SHA:ALL:!ADH:!LOW:!MD5:!SSLV2:!NULL" 
                     ca-certificate-file="/tmp/ews-eap6/ca-cert.jks"
                />
            </mod-cluster-config>
        </subsystem>

        <subsystem xmlns="urn:jboss:domain:web:1.5" native="false">
            <connector name="https" protocol="HTTP/1.1" scheme="https" socket-binding="https" secure="true" enabled="true">
                <ssl name="https" 
                    key-alias="javaclient" 
                    password="tomcat" 
                    certificate-key-file="/tmp/ews-eap6/client-cert-key.jks" 
                    cipher-suite="AES128-SHA:ALL:!ADH:!LOW:!MD5:!SSLV2:!NULL" 
                    protocol="TLS" verify-client="false" 
                    certificate-file="/tmp/ews-eap6/client-cert-key.jks" 
                    ca-certificate-file="/tmp/ews-eap6/ca-cert.jks"/>
            </connector>
            <virtual-server name="default-host" enable-welcome-root="true">
                <alias name="localhost"/>
                <alias name="example.com"/>
            </virtual-server>
        </subsystem>
{code}

Notice that while EAP 6.3.0.DR1 with *jbossweb-7.3.0.Final* uses {{org.apache.coyote.http11}}, even if natives are unpacked in {{modules/system/layers/base/org/jboss/as/web/main/lib/linux-x86_64/libtcnative-1.so}}, because there is {{native="false"}} in the web subsystem configuration,  EAP 6.3.0.DR2 with *jbossweb-7.4.0.Beta4* tries to start {{org.apache.coyote.http11.Http11NioProtocol}} despite having {{native="false"}}. 

This causes cipher suite errors, because the native implementation doesn't know what to do with it...

* EAP 6.3.0.DR1 with jbossweb-7.3.0.Final passes this test with no exceptions thrown.
* EAP 6.3.0.DR2 with jbossweb-7.4.0.Beta4 causes:

{noformat}
06:18:26,649 ERROR [org.apache.coyote.http11.Http11NioProtocol] (MSC service thread 1-17) JBWEB003043: Error initializing endpoint: java.io.IOException: JBWEB002081: No cipher match
    at org.apache.tomcat.util.net.jsse.NioJSSESocketChannelFactory.init(NioJSSESocketChannelFactory.java:315) [jbossweb-7.4.0.Beta4.jar:7.4.0.Beta4]
    at org.apache.tomcat.util.net.NioEndpoint.init(NioEndpoint.java:205) [jbossweb-7.4.0.Beta4.jar:7.4.0.Beta4]
    at org.apache.coyote.http11.Http11NioProtocol.init(Http11NioProtocol.java:113) [jbossweb-7.4.0.Beta4.jar:7.4.0.Beta4]
    at org.apache.catalina.connector.Connector.init(Connector.java:983) [jbossweb-7.4.0.Beta4.jar:7.4.0.Beta4]
    at org.jboss.as.web.WebConnectorService.start(WebConnectorService.java:304) [jboss-as-web-7.4.0.Final-redhat-2.jar:7.4.0.Final-redhat-2]
    at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1980) [jboss-msc-1.1.5.Final.jar:1.1.5.Final]
    at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1913) [jboss-msc-1.1.5.Final.jar:1.1.5.Final]
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_51]
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_51]
    at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_51]
Caused by: java.io.IOException: JBWEB002081: No cipher match
    at org.apache.tomcat.util.net.jsse.NioJSSESocketChannelFactory.getEnabledCiphers(NioJSSESocketChannelFactory.java:399) [jbossweb-7.4.0.Beta4.jar:7.4.0.Beta4]
    at org.apache.tomcat.util.net.jsse.NioJSSESocketChannelFactory.init(NioJSSESocketChannelFactory.java:305) [jbossweb-7.4.0.Beta4.jar:7.4.0.Beta4]
    ... 9 more

06:18:26,663 INFO  [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-39) JBAS010400: Bound data source [java:jboss/datasources/ExampleDS]
06:18:26,672 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-17) MSC000001: Failed to start service jboss.web.connector.https: org.jboss.msc.service.StartException in service jboss.web.connector.https: JBAS018007: Error starting web connector
    at org.jboss.as.web.WebConnectorService.start(WebConnectorService.java:362)
    at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1980) [jboss-msc-1.1.5.Final.jar:1.1.5.Final]
    at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1913) [jboss-msc-1.1.5.Final.jar:1.1.5.Final]
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_51]
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_51]
    at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_51]
Caused by: LifecycleException:  JBWEB000023: Protocol handler initialization failed
    at org.apache.catalina.connector.Connector.init(Connector.java:985)
    at org.jboss.as.web.WebConnectorService.start(WebConnectorService.java:304)
    ... 5 more
{noformat}

Any ideas?


    
> Http11Nio loaded, JBWEB002081: No cipher match
> ----------------------------------------------
>
>                 Key: JBWEB-292
>                 URL: https://issues.jboss.org/browse/JBWEB-292
>             Project: JBoss Web
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>    Affects Versions: JBossWeb-7.4.0.GA
>            Reporter: Michal Babacek
>            Assignee: Remy Maucherat
>            Priority: Critical
>             Fix For: JBossWeb-7.4.0.GA
>
>
> Hi guys,
> I have an SSL test that sets up the web subsystem with HTTPS connector only and uses HTTPS with mod_cluster.
> {code}
>         <subsystem xmlns="urn:jboss:domain:modcluster:1.2">
>             <mod-cluster-config advertise-socket="modcluster" connector="https">
>                 <dynamic-load-provider>
>                     <load-metric type="busyness"/>
>                 </dynamic-load-provider>
>                 <ssl key-alias="javaclient" 
>                      password="tomcat" 
>                      certificate-key-file="/tmp/ews-eap6/client-cert-key.jks" 
>                      cipher-suite="AES128-SHA:ALL:!ADH:!LOW:!MD5:!SSLV2:!NULL" 
>                      ca-certificate-file="/tmp/ews-eap6/ca-cert.jks"
>                 />
>             </mod-cluster-config>
>         </subsystem>
>         <subsystem xmlns="urn:jboss:domain:web:1.5" native="false">
>             <connector name="https" protocol="HTTP/1.1" scheme="https" socket-binding="https" secure="true" enabled="true">
>                 <ssl name="https" 
>                     key-alias="javaclient" 
>                     password="tomcat" 
>                     certificate-key-file="/tmp/ews-eap6/client-cert-key.jks" 
>                     cipher-suite="AES128-SHA:ALL:!ADH:!LOW:!MD5:!SSLV2:!NULL" 
>                     protocol="TLS" verify-client="false" 
>                     certificate-file="/tmp/ews-eap6/client-cert-key.jks" 
>                     ca-certificate-file="/tmp/ews-eap6/ca-cert.jks"/>
>             </connector>
>             <virtual-server name="default-host" enable-welcome-root="true">
>                 <alias name="localhost"/>
>                 <alias name="example.com"/>
>             </virtual-server>
>         </subsystem>
> {code}
> Notice that while EAP 6.3.0.DR1 with *jbossweb-7.3.0.Final* uses {{org.apache.coyote.http11}}, EAP 6.3.0.DR2 with *jbossweb-7.4.0.Beta4* tries to start {{org.apache.coyote.http11.Http11NioProtocol}}. 
> This causes cipher suite errors.
> * EAP 6.3.0.DR1 with jbossweb-7.3.0.Final passes this test with no exceptions thrown.
> * EAP 6.3.0.DR2 with jbossweb-7.4.0.Beta4 causes:
> {noformat}
> 06:18:26,649 ERROR [org.apache.coyote.http11.Http11NioProtocol] (MSC service thread 1-17) JBWEB003043: Error initializing endpoint: java.io.IOException: JBWEB002081: No cipher match
>     at org.apache.tomcat.util.net.jsse.NioJSSESocketChannelFactory.init(NioJSSESocketChannelFactory.java:315) [jbossweb-7.4.0.Beta4.jar:7.4.0.Beta4]
>     at org.apache.tomcat.util.net.NioEndpoint.init(NioEndpoint.java:205) [jbossweb-7.4.0.Beta4.jar:7.4.0.Beta4]
>     at org.apache.coyote.http11.Http11NioProtocol.init(Http11NioProtocol.java:113) [jbossweb-7.4.0.Beta4.jar:7.4.0.Beta4]
>     at org.apache.catalina.connector.Connector.init(Connector.java:983) [jbossweb-7.4.0.Beta4.jar:7.4.0.Beta4]
>     at org.jboss.as.web.WebConnectorService.start(WebConnectorService.java:304) [jboss-as-web-7.4.0.Final-redhat-2.jar:7.4.0.Final-redhat-2]
>     at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1980) [jboss-msc-1.1.5.Final.jar:1.1.5.Final]
>     at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1913) [jboss-msc-1.1.5.Final.jar:1.1.5.Final]
>     at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_51]
>     at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_51]
>     at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_51]
> Caused by: java.io.IOException: JBWEB002081: No cipher match
>     at org.apache.tomcat.util.net.jsse.NioJSSESocketChannelFactory.getEnabledCiphers(NioJSSESocketChannelFactory.java:399) [jbossweb-7.4.0.Beta4.jar:7.4.0.Beta4]
>     at org.apache.tomcat.util.net.jsse.NioJSSESocketChannelFactory.init(NioJSSESocketChannelFactory.java:305) [jbossweb-7.4.0.Beta4.jar:7.4.0.Beta4]
>     ... 9 more
> 06:18:26,663 INFO  [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-39) JBAS010400: Bound data source [java:jboss/datasources/ExampleDS]
> 06:18:26,672 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-17) MSC000001: Failed to start service jboss.web.connector.https: org.jboss.msc.service.StartException in service jboss.web.connector.https: JBAS018007: Error starting web connector
>     at org.jboss.as.web.WebConnectorService.start(WebConnectorService.java:362)
>     at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1980) [jboss-msc-1.1.5.Final.jar:1.1.5.Final]
>     at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1913) [jboss-msc-1.1.5.Final.jar:1.1.5.Final]
>     at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_51]
>     at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_51]
>     at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_51]
> Caused by: LifecycleException:  JBWEB000023: Protocol handler initialization failed
>     at org.apache.catalina.connector.Connector.init(Connector.java:985)
>     at org.jboss.as.web.WebConnectorService.start(WebConnectorService.java:304)
>     ... 5 more
> {noformat}
> Any ideas?

--
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

From issues at jboss.org  Thu Mar  6 08:13:33 2014
From: issues at jboss.org (Michal Babacek (JIRA))
Date: Thu, 6 Mar 2014 08:13:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JBWEB-292) Http11Nio loaded,
 JBWEB002081: No cipher match
In-Reply-To: <JIRA.12534270.1394109559000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534270.1394109559000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534270.1394109559000.8606.1394111613367@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JBWEB-292?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12950685#comment-12950685 ] 

Michal Babacek commented on JBWEB-292:
--------------------------------------

I amended the description, the issue has nothing to do with native libraries. It's present even if I deleted them all. Perhaps, Http11Nio does not support all these aforementioned cipher suites?
                
> Http11Nio loaded, JBWEB002081: No cipher match
> ----------------------------------------------
>
>                 Key: JBWEB-292
>                 URL: https://issues.jboss.org/browse/JBWEB-292
>             Project: JBoss Web
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>    Affects Versions: JBossWeb-7.4.0.GA
>            Reporter: Michal Babacek
>            Assignee: Remy Maucherat
>            Priority: Critical
>             Fix For: JBossWeb-7.4.0.GA
>
>
> Hi guys,
> I have an SSL test that sets up the web subsystem with HTTPS connector only and uses HTTPS with mod_cluster.
> {code}
>         <subsystem xmlns="urn:jboss:domain:modcluster:1.2">
>             <mod-cluster-config advertise-socket="modcluster" connector="https">
>                 <dynamic-load-provider>
>                     <load-metric type="busyness"/>
>                 </dynamic-load-provider>
>                 <ssl key-alias="javaclient" 
>                      password="tomcat" 
>                      certificate-key-file="/tmp/ews-eap6/client-cert-key.jks" 
>                      cipher-suite="AES128-SHA:ALL:!ADH:!LOW:!MD5:!SSLV2:!NULL" 
>                      ca-certificate-file="/tmp/ews-eap6/ca-cert.jks"
>                 />
>             </mod-cluster-config>
>         </subsystem>
>         <subsystem xmlns="urn:jboss:domain:web:1.5" native="false">
>             <connector name="https" protocol="HTTP/1.1" scheme="https" socket-binding="https" secure="true" enabled="true">
>                 <ssl name="https" 
>                     key-alias="javaclient" 
>                     password="tomcat" 
>                     certificate-key-file="/tmp/ews-eap6/client-cert-key.jks" 
>                     cipher-suite="AES128-SHA:ALL:!ADH:!LOW:!MD5:!SSLV2:!NULL" 
>                     protocol="TLS" verify-client="false" 
>                     certificate-file="/tmp/ews-eap6/client-cert-key.jks" 
>                     ca-certificate-file="/tmp/ews-eap6/ca-cert.jks"/>
>             </connector>
>             <virtual-server name="default-host" enable-welcome-root="true">
>                 <alias name="localhost"/>
>                 <alias name="example.com"/>
>             </virtual-server>
>         </subsystem>
> {code}
> Notice that while EAP 6.3.0.DR1 with *jbossweb-7.3.0.Final* uses {{org.apache.coyote.http11}}, EAP 6.3.0.DR2 with *jbossweb-7.4.0.Beta4* tries to start {{org.apache.coyote.http11.Http11NioProtocol}}. 
> This causes cipher suite errors.
> * EAP 6.3.0.DR1 with jbossweb-7.3.0.Final passes this test with no exceptions thrown.
> * EAP 6.3.0.DR2 with jbossweb-7.4.0.Beta4 causes:
> {noformat}
> 06:18:26,649 ERROR [org.apache.coyote.http11.Http11NioProtocol] (MSC service thread 1-17) JBWEB003043: Error initializing endpoint: java.io.IOException: JBWEB002081: No cipher match
>     at org.apache.tomcat.util.net.jsse.NioJSSESocketChannelFactory.init(NioJSSESocketChannelFactory.java:315) [jbossweb-7.4.0.Beta4.jar:7.4.0.Beta4]
>     at org.apache.tomcat.util.net.NioEndpoint.init(NioEndpoint.java:205) [jbossweb-7.4.0.Beta4.jar:7.4.0.Beta4]
>     at org.apache.coyote.http11.Http11NioProtocol.init(Http11NioProtocol.java:113) [jbossweb-7.4.0.Beta4.jar:7.4.0.Beta4]
>     at org.apache.catalina.connector.Connector.init(Connector.java:983) [jbossweb-7.4.0.Beta4.jar:7.4.0.Beta4]
>     at org.jboss.as.web.WebConnectorService.start(WebConnectorService.java:304) [jboss-as-web-7.4.0.Final-redhat-2.jar:7.4.0.Final-redhat-2]
>     at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1980) [jboss-msc-1.1.5.Final.jar:1.1.5.Final]
>     at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1913) [jboss-msc-1.1.5.Final.jar:1.1.5.Final]
>     at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_51]
>     at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_51]
>     at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_51]
> Caused by: java.io.IOException: JBWEB002081: No cipher match
>     at org.apache.tomcat.util.net.jsse.NioJSSESocketChannelFactory.getEnabledCiphers(NioJSSESocketChannelFactory.java:399) [jbossweb-7.4.0.Beta4.jar:7.4.0.Beta4]
>     at org.apache.tomcat.util.net.jsse.NioJSSESocketChannelFactory.init(NioJSSESocketChannelFactory.java:305) [jbossweb-7.4.0.Beta4.jar:7.4.0.Beta4]
>     ... 9 more
> 06:18:26,663 INFO  [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-39) JBAS010400: Bound data source [java:jboss/datasources/ExampleDS]
> 06:18:26,672 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-17) MSC000001: Failed to start service jboss.web.connector.https: org.jboss.msc.service.StartException in service jboss.web.connector.https: JBAS018007: Error starting web connector
>     at org.jboss.as.web.WebConnectorService.start(WebConnectorService.java:362)
>     at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1980) [jboss-msc-1.1.5.Final.jar:1.1.5.Final]
>     at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1913) [jboss-msc-1.1.5.Final.jar:1.1.5.Final]
>     at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_51]
>     at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_51]
>     at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_51]
> Caused by: LifecycleException:  JBWEB000023: Protocol handler initialization failed
>     at org.apache.catalina.connector.Connector.init(Connector.java:985)
>     at org.jboss.as.web.WebConnectorService.start(WebConnectorService.java:304)
>     ... 5 more
> {noformat}
> Any ideas?

--
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

From issues at jboss.org  Thu Mar  6 08:17:33 2014
From: issues at jboss.org (Remy Maucherat (JIRA))
Date: Thu, 6 Mar 2014 08:17:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JBWEB-292) Http11Nio loaded,
 JBWEB002081: No cipher match
In-Reply-To: <JIRA.12534270.1394109559000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534270.1394109559000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534270.1394109559000.8623.1394111853349@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JBWEB-292?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12950688#comment-12950688 ] 

Remy Maucherat commented on JBWEB-292:
--------------------------------------

The right syntax uses ',' as a separator, not ':'.
                
> Http11Nio loaded, JBWEB002081: No cipher match
> ----------------------------------------------
>
>                 Key: JBWEB-292
>                 URL: https://issues.jboss.org/browse/JBWEB-292
>             Project: JBoss Web
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>    Affects Versions: JBossWeb-7.4.0.GA
>            Reporter: Michal Babacek
>            Assignee: Remy Maucherat
>            Priority: Critical
>             Fix For: JBossWeb-7.4.0.GA
>
>
> Hi guys,
> I have an SSL test that sets up the web subsystem with HTTPS connector only and uses HTTPS with mod_cluster.
> {code}
>         <subsystem xmlns="urn:jboss:domain:modcluster:1.2">
>             <mod-cluster-config advertise-socket="modcluster" connector="https">
>                 <dynamic-load-provider>
>                     <load-metric type="busyness"/>
>                 </dynamic-load-provider>
>                 <ssl key-alias="javaclient" 
>                      password="tomcat" 
>                      certificate-key-file="/tmp/ews-eap6/client-cert-key.jks" 
>                      cipher-suite="AES128-SHA:ALL:!ADH:!LOW:!MD5:!SSLV2:!NULL" 
>                      ca-certificate-file="/tmp/ews-eap6/ca-cert.jks"
>                 />
>             </mod-cluster-config>
>         </subsystem>
>         <subsystem xmlns="urn:jboss:domain:web:1.5" native="false">
>             <connector name="https" protocol="HTTP/1.1" scheme="https" socket-binding="https" secure="true" enabled="true">
>                 <ssl name="https" 
>                     key-alias="javaclient" 
>                     password="tomcat" 
>                     certificate-key-file="/tmp/ews-eap6/client-cert-key.jks" 
>                     cipher-suite="AES128-SHA:ALL:!ADH:!LOW:!MD5:!SSLV2:!NULL" 
>                     protocol="TLS" verify-client="false" 
>                     certificate-file="/tmp/ews-eap6/client-cert-key.jks" 
>                     ca-certificate-file="/tmp/ews-eap6/ca-cert.jks"/>
>             </connector>
>             <virtual-server name="default-host" enable-welcome-root="true">
>                 <alias name="localhost"/>
>                 <alias name="example.com"/>
>             </virtual-server>
>         </subsystem>
> {code}
> Notice that while EAP 6.3.0.DR1 with *jbossweb-7.3.0.Final* uses {{org.apache.coyote.http11}}, EAP 6.3.0.DR2 with *jbossweb-7.4.0.Beta4* tries to start {{org.apache.coyote.http11.Http11NioProtocol}}. 
> This causes cipher suite errors.
> * EAP 6.3.0.DR1 with jbossweb-7.3.0.Final passes this test with no exceptions thrown.
> * EAP 6.3.0.DR2 with jbossweb-7.4.0.Beta4 causes:
> {noformat}
> 06:18:26,649 ERROR [org.apache.coyote.http11.Http11NioProtocol] (MSC service thread 1-17) JBWEB003043: Error initializing endpoint: java.io.IOException: JBWEB002081: No cipher match
>     at org.apache.tomcat.util.net.jsse.NioJSSESocketChannelFactory.init(NioJSSESocketChannelFactory.java:315) [jbossweb-7.4.0.Beta4.jar:7.4.0.Beta4]
>     at org.apache.tomcat.util.net.NioEndpoint.init(NioEndpoint.java:205) [jbossweb-7.4.0.Beta4.jar:7.4.0.Beta4]
>     at org.apache.coyote.http11.Http11NioProtocol.init(Http11NioProtocol.java:113) [jbossweb-7.4.0.Beta4.jar:7.4.0.Beta4]
>     at org.apache.catalina.connector.Connector.init(Connector.java:983) [jbossweb-7.4.0.Beta4.jar:7.4.0.Beta4]
>     at org.jboss.as.web.WebConnectorService.start(WebConnectorService.java:304) [jboss-as-web-7.4.0.Final-redhat-2.jar:7.4.0.Final-redhat-2]
>     at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1980) [jboss-msc-1.1.5.Final.jar:1.1.5.Final]
>     at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1913) [jboss-msc-1.1.5.Final.jar:1.1.5.Final]
>     at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_51]
>     at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_51]
>     at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_51]
> Caused by: java.io.IOException: JBWEB002081: No cipher match
>     at org.apache.tomcat.util.net.jsse.NioJSSESocketChannelFactory.getEnabledCiphers(NioJSSESocketChannelFactory.java:399) [jbossweb-7.4.0.Beta4.jar:7.4.0.Beta4]
>     at org.apache.tomcat.util.net.jsse.NioJSSESocketChannelFactory.init(NioJSSESocketChannelFactory.java:305) [jbossweb-7.4.0.Beta4.jar:7.4.0.Beta4]
>     ... 9 more
> 06:18:26,663 INFO  [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-39) JBAS010400: Bound data source [java:jboss/datasources/ExampleDS]
> 06:18:26,672 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-17) MSC000001: Failed to start service jboss.web.connector.https: org.jboss.msc.service.StartException in service jboss.web.connector.https: JBAS018007: Error starting web connector
>     at org.jboss.as.web.WebConnectorService.start(WebConnectorService.java:362)
>     at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1980) [jboss-msc-1.1.5.Final.jar:1.1.5.Final]
>     at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1913) [jboss-msc-1.1.5.Final.jar:1.1.5.Final]
>     at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_51]
>     at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_51]
>     at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_51]
> Caused by: LifecycleException:  JBWEB000023: Protocol handler initialization failed
>     at org.apache.catalina.connector.Connector.init(Connector.java:985)
>     at org.jboss.as.web.WebConnectorService.start(WebConnectorService.java:304)
>     ... 5 more
> {noformat}
> Any ideas?

--
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

From issues at jboss.org  Thu Mar  6 09:13:34 2014
From: issues at jboss.org (Michal Babacek (JIRA))
Date: Thu, 6 Mar 2014 09:13:34 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JBWEB-292) Http11Nio loaded,
 JBWEB002081: No cipher match
In-Reply-To: <JIRA.12534270.1394109559000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534270.1394109559000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534270.1394109559000.8938.1394115214877@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JBWEB-292?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12950712#comment-12950712 ] 

Michal Babacek commented on JBWEB-292:
--------------------------------------

Thanks for the hint Remy, I can see it now in the docs on [cipher-suite|http://docs.jboss.org/jbossweb/7.0.x/config/ssl.html].
Does it mean that the configuration syntax changed between {{jbossweb-7.3.0.Final}} and {{jbossweb-7.4.0.Beta4}} or that it has been so all along and the colon-delimited cypher-suite was simply ignored in {{jbossweb-7.3.0.Final}}?

Anyhow, I tried it with: {{cipher-suite="AES128-SHA,ALL,!ADH,!LOW,!MD5,!SSLV2,!NULL"}} and I must say that the error persists: {{JBWEB002081: No cipher match}}.
                
> Http11Nio loaded, JBWEB002081: No cipher match
> ----------------------------------------------
>
>                 Key: JBWEB-292
>                 URL: https://issues.jboss.org/browse/JBWEB-292
>             Project: JBoss Web
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>    Affects Versions: JBossWeb-7.4.0.GA
>            Reporter: Michal Babacek
>            Assignee: Remy Maucherat
>            Priority: Critical
>             Fix For: JBossWeb-7.4.0.GA
>
>
> Hi guys,
> I have an SSL test that sets up the web subsystem with HTTPS connector only and uses HTTPS with mod_cluster.
> {code}
>         <subsystem xmlns="urn:jboss:domain:modcluster:1.2">
>             <mod-cluster-config advertise-socket="modcluster" connector="https">
>                 <dynamic-load-provider>
>                     <load-metric type="busyness"/>
>                 </dynamic-load-provider>
>                 <ssl key-alias="javaclient" 
>                      password="tomcat" 
>                      certificate-key-file="/tmp/ews-eap6/client-cert-key.jks" 
>                      cipher-suite="AES128-SHA:ALL:!ADH:!LOW:!MD5:!SSLV2:!NULL" 
>                      ca-certificate-file="/tmp/ews-eap6/ca-cert.jks"
>                 />
>             </mod-cluster-config>
>         </subsystem>
>         <subsystem xmlns="urn:jboss:domain:web:1.5" native="false">
>             <connector name="https" protocol="HTTP/1.1" scheme="https" socket-binding="https" secure="true" enabled="true">
>                 <ssl name="https" 
>                     key-alias="javaclient" 
>                     password="tomcat" 
>                     certificate-key-file="/tmp/ews-eap6/client-cert-key.jks" 
>                     cipher-suite="AES128-SHA:ALL:!ADH:!LOW:!MD5:!SSLV2:!NULL" 
>                     protocol="TLS" verify-client="false" 
>                     certificate-file="/tmp/ews-eap6/client-cert-key.jks" 
>                     ca-certificate-file="/tmp/ews-eap6/ca-cert.jks"/>
>             </connector>
>             <virtual-server name="default-host" enable-welcome-root="true">
>                 <alias name="localhost"/>
>                 <alias name="example.com"/>
>             </virtual-server>
>         </subsystem>
> {code}
> Notice that while EAP 6.3.0.DR1 with *jbossweb-7.3.0.Final* uses {{org.apache.coyote.http11}}, EAP 6.3.0.DR2 with *jbossweb-7.4.0.Beta4* tries to start {{org.apache.coyote.http11.Http11NioProtocol}}. 
> This causes cipher suite errors.
> * EAP 6.3.0.DR1 with jbossweb-7.3.0.Final passes this test with no exceptions thrown.
> * EAP 6.3.0.DR2 with jbossweb-7.4.0.Beta4 causes:
> {noformat}
> 06:18:26,649 ERROR [org.apache.coyote.http11.Http11NioProtocol] (MSC service thread 1-17) JBWEB003043: Error initializing endpoint: java.io.IOException: JBWEB002081: No cipher match
>     at org.apache.tomcat.util.net.jsse.NioJSSESocketChannelFactory.init(NioJSSESocketChannelFactory.java:315) [jbossweb-7.4.0.Beta4.jar:7.4.0.Beta4]
>     at org.apache.tomcat.util.net.NioEndpoint.init(NioEndpoint.java:205) [jbossweb-7.4.0.Beta4.jar:7.4.0.Beta4]
>     at org.apache.coyote.http11.Http11NioProtocol.init(Http11NioProtocol.java:113) [jbossweb-7.4.0.Beta4.jar:7.4.0.Beta4]
>     at org.apache.catalina.connector.Connector.init(Connector.java:983) [jbossweb-7.4.0.Beta4.jar:7.4.0.Beta4]
>     at org.jboss.as.web.WebConnectorService.start(WebConnectorService.java:304) [jboss-as-web-7.4.0.Final-redhat-2.jar:7.4.0.Final-redhat-2]
>     at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1980) [jboss-msc-1.1.5.Final.jar:1.1.5.Final]
>     at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1913) [jboss-msc-1.1.5.Final.jar:1.1.5.Final]
>     at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_51]
>     at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_51]
>     at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_51]
> Caused by: java.io.IOException: JBWEB002081: No cipher match
>     at org.apache.tomcat.util.net.jsse.NioJSSESocketChannelFactory.getEnabledCiphers(NioJSSESocketChannelFactory.java:399) [jbossweb-7.4.0.Beta4.jar:7.4.0.Beta4]
>     at org.apache.tomcat.util.net.jsse.NioJSSESocketChannelFactory.init(NioJSSESocketChannelFactory.java:305) [jbossweb-7.4.0.Beta4.jar:7.4.0.Beta4]
>     ... 9 more
> 06:18:26,663 INFO  [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-39) JBAS010400: Bound data source [java:jboss/datasources/ExampleDS]
> 06:18:26,672 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-17) MSC000001: Failed to start service jboss.web.connector.https: org.jboss.msc.service.StartException in service jboss.web.connector.https: JBAS018007: Error starting web connector
>     at org.jboss.as.web.WebConnectorService.start(WebConnectorService.java:362)
>     at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1980) [jboss-msc-1.1.5.Final.jar:1.1.5.Final]
>     at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1913) [jboss-msc-1.1.5.Final.jar:1.1.5.Final]
>     at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_51]
>     at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_51]
>     at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_51]
> Caused by: LifecycleException:  JBWEB000023: Protocol handler initialization failed
>     at org.apache.catalina.connector.Connector.init(Connector.java:985)
>     at org.jboss.as.web.WebConnectorService.start(WebConnectorService.java:304)
>     ... 5 more
> {noformat}
> Any ideas?

--
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

From issues at jboss.org  Thu Mar  6 09:21:34 2014
From: issues at jboss.org (Jesper Pedersen (JIRA))
Date: Thu, 6 Mar 2014 09:21:34 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JBJCA-1151) Allow testConnection()
 without statistics enabled
In-Reply-To: <JIRA.12534290.1394115585343@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534290.1394115585343@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534290.1394115585343.8986.1394115694380@jira02.app.mwc.hst.phx2.redhat.com>

Jesper Pedersen created JBJCA-1151:
--------------------------------------

             Summary: Allow testConnection() without statistics enabled
                 Key: JBJCA-1151
                 URL: https://issues.jboss.org/browse/JBJCA-1151
             Project: IronJacamar
          Issue Type: Task
          Components: Core
    Affects Versions: 1.0.24.Final
            Reporter: Jesper Pedersen
            Assignee: Jesper Pedersen
             Fix For: 1.0.25.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

From issues at jboss.org  Thu Mar  6 09:41:33 2014
From: issues at jboss.org (Jesper Pedersen (JIRA))
Date: Thu, 6 Mar 2014 09:41:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JBJCA-1151) Allow testConnection()
 without statistics enabled
In-Reply-To: <JIRA.12534290.1394115585000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534290.1394115585000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534290.1394115585000.9118.1394116893326@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBJCA-1151?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jesper Pedersen resolved JBJCA-1151.
------------------------------------

    Resolution: Done

    
> Allow testConnection() without statistics enabled
> -------------------------------------------------
>
>                 Key: JBJCA-1151
>                 URL: https://issues.jboss.org/browse/JBJCA-1151
>             Project: IronJacamar
>          Issue Type: Task
>          Components: Core
>    Affects Versions: 1.0.24.Final
>            Reporter: Jesper Pedersen
>            Assignee: Jesper Pedersen
>             Fix For: 1.0.25.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

From issues at jboss.org  Thu Mar  6 09:41:33 2014
From: issues at jboss.org (Jesper Pedersen (JIRA))
Date: Thu, 6 Mar 2014 09:41:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JBJCA-1150) The TransactionIntegration
 module should provide a unique identifier for a transaction
In-Reply-To: <JIRA.12534218.1394046878000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534218.1394046878000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534218.1394046878000.9120.1394116893409@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBJCA-1150?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jesper Pedersen resolved JBJCA-1150.
------------------------------------

    Resolution: Done

    
> The TransactionIntegration module should provide a unique identifier for a transaction
> --------------------------------------------------------------------------------------
>
>                 Key: JBJCA-1150
>                 URL: https://issues.jboss.org/browse/JBJCA-1150
>             Project: IronJacamar
>          Issue Type: Task
>          Components: Core
>            Reporter: Jesper Pedersen
>            Assignee: Jesper Pedersen
>             Fix For: 1.2.0.Beta1
>
>
> The identifier needs to be stable for the entire transaction lifecycle

--
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

From issues at jboss.org  Thu Mar  6 09:45:34 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 6 Mar 2014 09:45:34 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JBMETA-371) DefaultPropertyReplacer +
 PropertyResolver is broken for vault expressions
In-Reply-To: <JIRA.12530165.1390432775000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530165.1390432775000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530165.1390432775000.9150.1394117134061@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JBMETA-371?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12950745#comment-12950745 ] 

RH Bugzilla Integration commented on JBMETA-371:
------------------------------------------------

Katerina Novotna <kanovotn at redhat.com> changed the Status of [bug 1058959|https://bugzilla.redhat.com/show_bug.cgi?id=1058959] from ON_QA to VERIFIED
                
> DefaultPropertyReplacer + PropertyResolver is broken for vault expressions
> --------------------------------------------------------------------------
>
>                 Key: JBMETA-371
>                 URL: https://issues.jboss.org/browse/JBMETA-371
>             Project: JBoss Metadata
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: common
>    Affects Versions: 7.0.4.Final
>            Reporter: Brian Stansberry
>            Assignee: Brian Stansberry
>             Fix For: 8.0.0.Final
>
>
> The DefaultPropertyReplacer + PropertyResolver algorithm is broken for vault expressions. It's based on the assumption that the contents of the expression string between "${" and "}" have a fixed format a la the old JBoss AS system properties (e.g. propertyname[: default value]) and then the PropertyResolver tries to resolve "propertyname".
> This is incorrect in the case of vault expressions, which do not follow this format. In particular the ":" char appears multiple places in a vault expression and does not serve as a delimiter between "propertyname" and "default value".

--
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

From issues at jboss.org  Thu Mar  6 09:49:34 2014
From: issues at jboss.org (Jean-Frederic Clere (JIRA))
Date: Thu, 6 Mar 2014 09:49:34 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JBWEB-292) Http11Nio loaded,
 JBWEB002081: No cipher match
In-Reply-To: <JIRA.12534270.1394109559000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534270.1394109559000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534270.1394109559000.9166.1394117374042@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JBWEB-292?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12950748#comment-12950748 ] 

Jean-Frederic Clere commented on JBWEB-292:
-------------------------------------------

I think you use the OpenSSL names you need the JSSE ones.
AES128-SHA isn't in the supported list etc...
                
> Http11Nio loaded, JBWEB002081: No cipher match
> ----------------------------------------------
>
>                 Key: JBWEB-292
>                 URL: https://issues.jboss.org/browse/JBWEB-292
>             Project: JBoss Web
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>    Affects Versions: JBossWeb-7.4.0.GA
>            Reporter: Michal Babacek
>            Assignee: Remy Maucherat
>            Priority: Critical
>             Fix For: JBossWeb-7.4.0.GA
>
>
> Hi guys,
> I have an SSL test that sets up the web subsystem with HTTPS connector only and uses HTTPS with mod_cluster.
> {code}
>         <subsystem xmlns="urn:jboss:domain:modcluster:1.2">
>             <mod-cluster-config advertise-socket="modcluster" connector="https">
>                 <dynamic-load-provider>
>                     <load-metric type="busyness"/>
>                 </dynamic-load-provider>
>                 <ssl key-alias="javaclient" 
>                      password="tomcat" 
>                      certificate-key-file="/tmp/ews-eap6/client-cert-key.jks" 
>                      cipher-suite="AES128-SHA:ALL:!ADH:!LOW:!MD5:!SSLV2:!NULL" 
>                      ca-certificate-file="/tmp/ews-eap6/ca-cert.jks"
>                 />
>             </mod-cluster-config>
>         </subsystem>
>         <subsystem xmlns="urn:jboss:domain:web:1.5" native="false">
>             <connector name="https" protocol="HTTP/1.1" scheme="https" socket-binding="https" secure="true" enabled="true">
>                 <ssl name="https" 
>                     key-alias="javaclient" 
>                     password="tomcat" 
>                     certificate-key-file="/tmp/ews-eap6/client-cert-key.jks" 
>                     cipher-suite="AES128-SHA:ALL:!ADH:!LOW:!MD5:!SSLV2:!NULL" 
>                     protocol="TLS" verify-client="false" 
>                     certificate-file="/tmp/ews-eap6/client-cert-key.jks" 
>                     ca-certificate-file="/tmp/ews-eap6/ca-cert.jks"/>
>             </connector>
>             <virtual-server name="default-host" enable-welcome-root="true">
>                 <alias name="localhost"/>
>                 <alias name="example.com"/>
>             </virtual-server>
>         </subsystem>
> {code}
> Notice that while EAP 6.3.0.DR1 with *jbossweb-7.3.0.Final* uses {{org.apache.coyote.http11}}, EAP 6.3.0.DR2 with *jbossweb-7.4.0.Beta4* tries to start {{org.apache.coyote.http11.Http11NioProtocol}}. 
> This causes cipher suite errors.
> * EAP 6.3.0.DR1 with jbossweb-7.3.0.Final passes this test with no exceptions thrown.
> * EAP 6.3.0.DR2 with jbossweb-7.4.0.Beta4 causes:
> {noformat}
> 06:18:26,649 ERROR [org.apache.coyote.http11.Http11NioProtocol] (MSC service thread 1-17) JBWEB003043: Error initializing endpoint: java.io.IOException: JBWEB002081: No cipher match
>     at org.apache.tomcat.util.net.jsse.NioJSSESocketChannelFactory.init(NioJSSESocketChannelFactory.java:315) [jbossweb-7.4.0.Beta4.jar:7.4.0.Beta4]
>     at org.apache.tomcat.util.net.NioEndpoint.init(NioEndpoint.java:205) [jbossweb-7.4.0.Beta4.jar:7.4.0.Beta4]
>     at org.apache.coyote.http11.Http11NioProtocol.init(Http11NioProtocol.java:113) [jbossweb-7.4.0.Beta4.jar:7.4.0.Beta4]
>     at org.apache.catalina.connector.Connector.init(Connector.java:983) [jbossweb-7.4.0.Beta4.jar:7.4.0.Beta4]
>     at org.jboss.as.web.WebConnectorService.start(WebConnectorService.java:304) [jboss-as-web-7.4.0.Final-redhat-2.jar:7.4.0.Final-redhat-2]
>     at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1980) [jboss-msc-1.1.5.Final.jar:1.1.5.Final]
>     at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1913) [jboss-msc-1.1.5.Final.jar:1.1.5.Final]
>     at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_51]
>     at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_51]
>     at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_51]
> Caused by: java.io.IOException: JBWEB002081: No cipher match
>     at org.apache.tomcat.util.net.jsse.NioJSSESocketChannelFactory.getEnabledCiphers(NioJSSESocketChannelFactory.java:399) [jbossweb-7.4.0.Beta4.jar:7.4.0.Beta4]
>     at org.apache.tomcat.util.net.jsse.NioJSSESocketChannelFactory.init(NioJSSESocketChannelFactory.java:305) [jbossweb-7.4.0.Beta4.jar:7.4.0.Beta4]
>     ... 9 more
> 06:18:26,663 INFO  [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-39) JBAS010400: Bound data source [java:jboss/datasources/ExampleDS]
> 06:18:26,672 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-17) MSC000001: Failed to start service jboss.web.connector.https: org.jboss.msc.service.StartException in service jboss.web.connector.https: JBAS018007: Error starting web connector
>     at org.jboss.as.web.WebConnectorService.start(WebConnectorService.java:362)
>     at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1980) [jboss-msc-1.1.5.Final.jar:1.1.5.Final]
>     at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1913) [jboss-msc-1.1.5.Final.jar:1.1.5.Final]
>     at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_51]
>     at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_51]
>     at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_51]
> Caused by: LifecycleException:  JBWEB000023: Protocol handler initialization failed
>     at org.apache.catalina.connector.Connector.init(Connector.java:985)
>     at org.jboss.as.web.WebConnectorService.start(WebConnectorService.java:304)
>     ... 5 more
> {noformat}
> Any ideas?

--
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

From issues at jboss.org  Thu Mar  6 10:36:35 2014
From: issues at jboss.org (Vijay Kumar (JIRA))
Date: Thu, 6 Mar 2014 10:36:35 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2936) "Only session and
 message-driven beans with bean-managed transaction demarcation are allowed
 to access UserTransaction" error in migrated seam 2.2.2 application
In-Reply-To: <JIRA.12532176.1392367721000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12532176.1392367721000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12532176.1392367721000.9330.1394120195976@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2936?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12950766#comment-12950766 ] 

Vijay Kumar commented on WFLY-2936:
-----------------------------------

This is a major blocker for Seam 2.3 applications in WildFly. Same application runs find in AS 7.1.1.Final. Is there a way to configure EJB subsystem to allow this?

Thanks. 

                
> "Only session and message-driven beans with bean-managed transaction demarcation are allowed to access UserTransaction" error in migrated seam 2.2.2 application
> ----------------------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2936
>                 URL: https://issues.jboss.org/browse/WFLY-2936
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 8.0.0.Final
>         Environment: Windows 7 64bit
> Java 1.7.0_51
> WildFly 8.0.0.Final
> JBoss Seam 2.2.2.Final
>            Reporter: Dimitris Keramidas
>            Assignee: Eduardo Martins
>         Attachments: Auth.java, Authenticator.java, components.xml, jboss-deployment-structure.xml, server.log
>
>
> The error is fired when attempting to call a transaction-enabled EJB method, from a seam component. Specifically the authentication component.
> In order to get to this position, the project's deployment descriptors had to be migrated. Furthermore, mojarra version 1.2_15 was deployed to WildFly, as described by this link: https://community.jboss.org/wiki/DesignOfWildFlyMulti-JSFFeature
> Please see attached logs and descriptors.

--
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

From issues at jboss.org  Thu Mar  6 10:38:34 2014
From: issues at jboss.org (Ken H (JIRA))
Date: Thu, 6 Mar 2014 10:38:34 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2936) "Only session and
 message-driven beans with bean-managed transaction demarcation are allowed
 to access UserTransaction" error in migrated seam 2.2.2 application
In-Reply-To: <JIRA.12532176.1392367721000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12532176.1392367721000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12532176.1392367721000.9343.1394120314353@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2936?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12950769#comment-12950769 ] 

Ken H commented on WFLY-2936:
-----------------------------

FYI, if it helps anyone, I have resolved this in my fork of the Seam 3 Transaction module. The Seam project is abandoned so I don't expect any changes to happen in either version.

https://github.com/steeltomato/transaction/commit/79c269ca89b23ed64137bc7448c0465d721052e6
                
> "Only session and message-driven beans with bean-managed transaction demarcation are allowed to access UserTransaction" error in migrated seam 2.2.2 application
> ----------------------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2936
>                 URL: https://issues.jboss.org/browse/WFLY-2936
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 8.0.0.Final
>         Environment: Windows 7 64bit
> Java 1.7.0_51
> WildFly 8.0.0.Final
> JBoss Seam 2.2.2.Final
>            Reporter: Dimitris Keramidas
>            Assignee: Eduardo Martins
>         Attachments: Auth.java, Authenticator.java, components.xml, jboss-deployment-structure.xml, server.log
>
>
> The error is fired when attempting to call a transaction-enabled EJB method, from a seam component. Specifically the authentication component.
> In order to get to this position, the project's deployment descriptors had to be migrated. Furthermore, mojarra version 1.2_15 was deployed to WildFly, as described by this link: https://community.jboss.org/wiki/DesignOfWildFlyMulti-JSFFeature
> Please see attached logs and descriptors.

--
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

From issues at jboss.org  Thu Mar  6 10:42:34 2014
From: issues at jboss.org (Vijay Kumar (JIRA))
Date: Thu, 6 Mar 2014 10:42:34 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2936) "Only session and
 message-driven beans with bean-managed transaction demarcation are allowed
 to access UserTransaction" error in migrated seam 2.2.2 application
In-Reply-To: <JIRA.12532176.1392367721000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12532176.1392367721000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12532176.1392367721000.9363.1394120554087@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2936?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12950766#comment-12950766 ] 

Vijay Kumar edited comment on WFLY-2936 at 3/6/14 10:40 AM:
------------------------------------------------------------

This is a major blocker for Seam 2.3 applications in WildFly. Same application runs fine in AS 7.1.1.Final. Is there a way to configure EJB subsystem to allow this?

Thanks. 

                
      was (Author: vij2ee):
    This is a major blocker for Seam 2.3 applications in WildFly. Same application runs find in AS 7.1.1.Final. Is there a way to configure EJB subsystem to allow this?

Thanks. 

                  
> "Only session and message-driven beans with bean-managed transaction demarcation are allowed to access UserTransaction" error in migrated seam 2.2.2 application
> ----------------------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2936
>                 URL: https://issues.jboss.org/browse/WFLY-2936
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 8.0.0.Final
>         Environment: Windows 7 64bit
> Java 1.7.0_51
> WildFly 8.0.0.Final
> JBoss Seam 2.2.2.Final
>            Reporter: Dimitris Keramidas
>            Assignee: Eduardo Martins
>         Attachments: Auth.java, Authenticator.java, components.xml, jboss-deployment-structure.xml, server.log
>
>
> The error is fired when attempting to call a transaction-enabled EJB method, from a seam component. Specifically the authentication component.
> In order to get to this position, the project's deployment descriptors had to be migrated. Furthermore, mojarra version 1.2_15 was deployed to WildFly, as described by this link: https://community.jboss.org/wiki/DesignOfWildFlyMulti-JSFFeature
> Please see attached logs and descriptors.

--
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

From issues at jboss.org  Thu Mar  6 11:15:34 2014
From: issues at jboss.org (Jeff Mesnil (JIRA))
Date: Thu, 6 Mar 2014 11:15:34 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3075) add supplement to
 socket-bindings in template assembly
In-Reply-To: <JIRA.12534311.1394122466124@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534311.1394122466124@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534311.1394122466124.9478.1394122534138@jira02.app.mwc.hst.phx2.redhat.com>

Jeff Mesnil created WFLY-3075:
---------------------------------

             Summary: add supplement to socket-bindings in template assembly
                 Key: WFLY-3075
                 URL: https://issues.jboss.org/browse/WFLY-3075
             Project: WildFly
          Issue Type: Enhancement
      Security Level: Public (Everyone can see)
          Components: Build System
    Affects Versions: 8.0.0.Final
            Reporter: Jeff Mesnil
            Assignee: Paul Gier
             Fix For: 9.0.0.CR1


The messaging.xml subsystem configuration defines a "ha" supplement used to build the standalone-full-ha.xml.

This supplement requires to have a socket-binding for multicast:

   <socket-binding name="messaging-group" port="0" multicast-address="${jboss.messaging.group.address:231.7.7.7}" multicast-port="${jboss.messaging.group.port:9876}"/>

However, this socket-binding is *always* added even when the "ha" supplement is not used.
We end up with a standalone-full.xml configuration with the regular messaging subsystem (no ha parts) *and* the messaging-group socket binding.

Ideally, this socket-binding should only be added when the ha supplement is used.
One way to achieve this would be to allow <socket-binding> definitions inside the <supplement>/<replacement> elements.



--
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

From issues at jboss.org  Thu Mar  6 11:15:34 2014
From: issues at jboss.org (Jeff Mesnil (JIRA))
Date: Thu, 6 Mar 2014 11:15:34 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3075) add supplement to
 socket-bindings in template assembly
In-Reply-To: <JIRA.12534311.1394122466000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534311.1394122466000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534311.1394122466000.9481.1394122534306@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-3075?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jeff Mesnil updated WFLY-3075:
------------------------------

    Description: 
The messaging.xml subsystem configuration defines a "ha" supplement used to build the standalone-full-ha.xml.

This supplement requires to have a socket-binding for multicast:

{noformat}
   <socket-binding name="messaging-group" port="0" multicast-address="${jboss.messaging.group.address:231.7.7.7}" multicast-port="${jboss.messaging.group.port:9876}"/>
{noformat}

However, this socket-binding is *always* added even when the "ha" supplement is not used.
We end up with a standalone-full.xml configuration with the regular messaging subsystem (no ha parts) *and* the messaging-group socket binding.

Ideally, this socket-binding should only be added when the ha supplement is used.
One way to achieve this would be to allow <socket-binding> definitions inside the <supplement>/<replacement> elements.



  was:
The messaging.xml subsystem configuration defines a "ha" supplement used to build the standalone-full-ha.xml.

This supplement requires to have a socket-binding for multicast:

   <socket-binding name="messaging-group" port="0" multicast-address="${jboss.messaging.group.address:231.7.7.7}" multicast-port="${jboss.messaging.group.port:9876}"/>

However, this socket-binding is *always* added even when the "ha" supplement is not used.
We end up with a standalone-full.xml configuration with the regular messaging subsystem (no ha parts) *and* the messaging-group socket binding.

Ideally, this socket-binding should only be added when the ha supplement is used.
One way to achieve this would be to allow <socket-binding> definitions inside the <supplement>/<replacement> elements.




    
> add supplement to socket-bindings in template assembly
> ------------------------------------------------------
>
>                 Key: WFLY-3075
>                 URL: https://issues.jboss.org/browse/WFLY-3075
>             Project: WildFly
>          Issue Type: Enhancement
>      Security Level: Public(Everyone can see) 
>          Components: Build System
>    Affects Versions: 8.0.0.Final
>            Reporter: Jeff Mesnil
>            Assignee: Paul Gier
>             Fix For: 9.0.0.CR1
>
>
> The messaging.xml subsystem configuration defines a "ha" supplement used to build the standalone-full-ha.xml.
> This supplement requires to have a socket-binding for multicast:
> {noformat}
>    <socket-binding name="messaging-group" port="0" multicast-address="${jboss.messaging.group.address:231.7.7.7}" multicast-port="${jboss.messaging.group.port:9876}"/>
> {noformat}
> However, this socket-binding is *always* added even when the "ha" supplement is not used.
> We end up with a standalone-full.xml configuration with the regular messaging subsystem (no ha parts) *and* the messaging-group socket binding.
> Ideally, this socket-binding should only be added when the ha supplement is used.
> One way to achieve this would be to allow <socket-binding> definitions inside the <supplement>/<replacement> elements.

--
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

From issues at jboss.org  Thu Mar  6 11:17:33 2014
From: issues at jboss.org (Tomaz Cerar (JIRA))
Date: Thu, 6 Mar 2014 11:17:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3075) add supplement to
 socket-bindings in template assembly
In-Reply-To: <JIRA.12534311.1394122466000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534311.1394122466000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534311.1394122466000.9496.1394122653458@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-3075?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tomaz Cerar reassigned WFLY-3075:
---------------------------------

    Assignee: Tomaz Cerar  (was: Paul Gier)

    
> add supplement to socket-bindings in template assembly
> ------------------------------------------------------
>
>                 Key: WFLY-3075
>                 URL: https://issues.jboss.org/browse/WFLY-3075
>             Project: WildFly
>          Issue Type: Enhancement
>      Security Level: Public(Everyone can see) 
>          Components: Build System
>    Affects Versions: 8.0.0.Final
>            Reporter: Jeff Mesnil
>            Assignee: Tomaz Cerar
>             Fix For: 9.0.0.CR1
>
>
> The messaging.xml subsystem configuration defines a "ha" supplement used to build the standalone-full-ha.xml.
> This supplement requires to have a socket-binding for multicast:
> {noformat}
>    <socket-binding name="messaging-group" port="0" multicast-address="${jboss.messaging.group.address:231.7.7.7}" multicast-port="${jboss.messaging.group.port:9876}"/>
> {noformat}
> However, this socket-binding is *always* added even when the "ha" supplement is not used.
> We end up with a standalone-full.xml configuration with the regular messaging subsystem (no ha parts) *and* the messaging-group socket binding.
> Ideally, this socket-binding should only be added when the ha supplement is used.
> One way to achieve this would be to allow <socket-binding> definitions inside the <supplement>/<replacement> elements.

--
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

From issues at jboss.org  Thu Mar  6 11:19:33 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 6 Mar 2014 11:19:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2920) StackOverflowError when
 org.jboss.as.jacorb.rmi.InterfaceAnalysis is analyzing javax.ejb.EJBObject
In-Reply-To: <JIRA.12532007.1392269121000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12532007.1392269121000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12532007.1392269121000.9507.1394122773469@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2920?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12950792#comment-12950792 ] 

RH Bugzilla Integration commented on WFLY-2920:
-----------------------------------------------

Kabir Khan <kkhan at redhat.com> changed the Status of [bug 1064644|https://bugzilla.redhat.com/show_bug.cgi?id=1064644] from ON_QA to MODIFIED
                
> StackOverflowError when org.jboss.as.jacorb.rmi.InterfaceAnalysis is analyzing javax.ejb.EJBObject
> --------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2920
>                 URL: https://issues.jboss.org/browse/WFLY-2920
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: IIOP
>    Affects Versions: 8.0.0.Final
>            Reporter: Osamu Nagano
>            Assignee: Stefan Guilhen
>         Attachments: td.dump
>
>
> Depending on when a thread context switch happens, an IIOP enabled EJB fails to be deployed by throwing {{java.lang.StackOverflowError}}.  Here is the stack trace from the attached thread dump.
> {code}
> "MSC service thread 1-7" prio=10 tid=0x00007f52e8001800 nid=0x4d12 at breakpoint[0x00007f534093f000]
>    java.lang.Thread.State: RUNNABLE
>         at org.jboss.as.jacorb.rmi.WorkCacheManager.getAnalysis(WorkCacheManager.java:105)
>         at org.jboss.as.jacorb.rmi.InterfaceAnalysis.getInterfaceAnalysis(InterfaceAnalysis.java:53)
>         at org.jboss.as.jacorb.rmi.Util.getTypeIDLName(Util.java:104)
>         at org.jboss.as.jacorb.rmi.ParameterAnalysis.<init>(ParameterAnalysis.java:50)
>         at org.jboss.as.jacorb.rmi.OperationAnalysis.<init>(OperationAnalysis.java:91)
>         at org.jboss.as.jacorb.rmi.InterfaceAnalysis.analyzeOperations(InterfaceAnalysis.java:116)
>         at org.jboss.as.jacorb.rmi.ContainerAnalysis.doAnalyze(ContainerAnalysis.java:186)
>         at org.jboss.as.jacorb.rmi.InterfaceAnalysis.doAnalyze(InterfaceAnalysis.java:62)
>         at sun.reflect.GeneratedMethodAccessor3.invoke(Unknown Source)
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>         at java.lang.reflect.Method.invoke(Method.java:606)
>         at org.jboss.as.jacorb.rmi.WorkCacheManager.doTheWork(WorkCacheManager.java:177)
>         at org.jboss.as.jacorb.rmi.WorkCacheManager.getAnalysis(WorkCacheManager.java:105)
>         at org.jboss.as.jacorb.rmi.InterfaceAnalysis.getInterfaceAnalysis(InterfaceAnalysis.java:53)
>         at org.jboss.as.jacorb.rmi.Util.getTypeIDLName(Util.java:104)
>         at org.jboss.as.jacorb.rmi.ParameterAnalysis.<init>(ParameterAnalysis.java:50)
>         at org.jboss.as.jacorb.rmi.OperationAnalysis.<init>(OperationAnalysis.java:91)
>         at org.jboss.as.jacorb.rmi.InterfaceAnalysis.analyzeOperations(InterfaceAnalysis.java:116)
>         at org.jboss.as.jacorb.rmi.ContainerAnalysis.doAnalyze(ContainerAnalysis.java:186)
>         at org.jboss.as.jacorb.rmi.InterfaceAnalysis.doAnalyze(InterfaceAnalysis.java:62)
>         at sun.reflect.GeneratedMethodAccessor3.invoke(Unknown Source)
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>         at java.lang.reflect.Method.invoke(Method.java:606)
>         ...
>         at org.jboss.as.jacorb.rmi.WorkCacheManager.doTheWork(WorkCacheManager.java:177)
>         at org.jboss.as.jacorb.rmi.WorkCacheManager.getAnalysis(WorkCacheManager.java:105)
>         at org.jboss.as.jacorb.rmi.InterfaceAnalysis.getInterfaceAnalysis(InterfaceAnalysis.java:53)
>         at org.jboss.as.jacorb.rmi.Util.getTypeIDLName(Util.java:104)
>         at org.jboss.as.jacorb.rmi.ParameterAnalysis.<init>(ParameterAnalysis.java:50)
>    Locked ownable synchronizers:
>         - <0x00000000f9698790> (a java.util.concurrent.ThreadPoolExecutor$Worker)
> {code}
> The last part including {{Util.getTypeIDLName}} has been repeated as many as possible and the bottom of the stack has been lost.  The same stack has been appeared in a different MSC service thread which is also executing an IIOP enabled EJB deployment.
> The customer identified an improper synchronization in {{org.jboss.as.jacorb.rmi.WorkCacheManager#getAnalysis()}}.  It is reproducible by manually controlling a thread context switch using a debugger.

--
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

From issues at jboss.org  Thu Mar  6 11:21:34 2014
From: issues at jboss.org (Bela Ban (JIRA))
Date: Thu, 6 Mar 2014 11:21:34 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1722) Improve performance of
	ENCRYPT protocol
In-Reply-To: <JIRA.12508426.1382426974000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508426.1382426974000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508426.1382426974000.9518.1394122894041@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JGRP-1722?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12950795#comment-12950795 ] 

Bela Ban commented on JGRP-1722:
--------------------------------

According to the docs on {{javax.crypto.Cipher}}, method {{doFinal()}} should be able to write its encrypted / decrypted message right back into the *input buffer* without overwriting the input. Change the code to use this method, so we have 1 less buffer to create for encryption and decryption.
                
> Improve performance of ENCRYPT protocol
> ---------------------------------------
>
>                 Key: JGRP-1722
>                 URL: https://issues.jboss.org/browse/JGRP-1722
>             Project: JGroups
>          Issue Type: Enhancement
>    Affects Versions: 3.4
>            Reporter: Martin Gencur
>            Assignee: Bela Ban
>             Fix For: 3.5
>
>
> A stress tests with the following setup showed that performance (reads and writes/sec) is halved when ENCRYPT protocol is enabled:
> Infinispan had distributed sync cache with 2 owners on 4 nodes, no transactions. The stress test used 10 threads on each node accessing 1024 byte entries, no conflicts on keys, 20 % writes, 80 % reads. 
> It would be great if we could improve the performance of ENCRYPT protocol.

--
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

From issues at jboss.org  Thu Mar  6 11:27:34 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 6 Mar 2014 11:27:34 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3042) There should be a warning
 logged if the default value of node identifier has not been changed.
In-Reply-To: <JIRA.12533608.1393595350000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12533608.1393595350000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12533608.1393595350000.9541.1394123254296@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-3042?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12950798#comment-12950798 ] 

RH Bugzilla Integration commented on WFLY-3042:
-----------------------------------------------

Kabir Khan <kkhan at redhat.com> changed the Status of [bug 1072312|https://bugzilla.redhat.com/show_bug.cgi?id=1072312] from POST to MODIFIED
                
> There should be a warning logged if the default value of node identifier has not been changed.  
> ------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-3042
>                 URL: https://issues.jboss.org/browse/WFLY-3042
>             Project: WildFly
>          Issue Type: Enhancement
>      Security Level: Public(Everyone can see) 
>          Components: Transactions
>    Affects Versions: 8.0.0.Final
>         Environment: JBoss EAP 6.x
>            Reporter: Tom Ross
>            Assignee: Gytis Trikleris
>
> JBoss EAP instance is using the value of node identifier  to identify XA transactions that belong to it. By default this value is set to 1. Now days in most environments there will be multiple JBoss instances sharing XA resources there for it is necessary to set the value of node identifier to a unique value for each instance. This is something that most end users fail to perform. Therefor it would be helpful if  a warning  message was logged at startup telling the user to do it.

--
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

From issues at jboss.org  Thu Mar  6 11:43:33 2014
From: issues at jboss.org (Richard Achmatowicz (JIRA))
Date: Thu, 6 Mar 2014 11:43:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1806) UnicastLoopbackTest fails to
 receive all messages in the allotted time
In-Reply-To: <JIRA.12534313.1394124154379@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534313.1394124154379@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534313.1394124154379.9636.1394124213903@jira02.app.mwc.hst.phx2.redhat.com>

Richard Achmatowicz created JGRP-1806:
-----------------------------------------

             Summary: UnicastLoopbackTest fails to receive all messages in the allotted time
                 Key: JGRP-1806
                 URL: https://issues.jboss.org/browse/JGRP-1806
             Project: JGroups
          Issue Type: Bug
    Affects Versions: 3.2.13
         Environment: RHEL, Windows, Solaris
            Reporter: Richard Achmatowicz
            Assignee: Bela Ban
             Fix For: 3.2.13


UnicastLoopbackTest.testUnicastMessagesWithLoopback() is failing with the following error:
{noformat}
Error Message

Test timed out before all messages were received
Stacktrace

java.lang.AssertionError 
at org.testng.Assert.fail(Assert.java:94) 
at org.jgroups.tests.UnicastLoopbackTest.testUnicastMsgsWithLoopback(UnicastLoopbackTest.java:78) 
{noformat}

The test does the following:
- creates one channel with loopback enabled in the transport
- the channel is assigned a receiver which collects the messages received and sets a Boolean valued Promise when all messages have been received 
- sends 1000 messages in a burst to the channel
- waits 20 seconds for the promise to be set to true

The test fails because the messages do not arrive within the allotted 20 seconds.


--
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

From issues at jboss.org  Thu Mar  6 11:45:33 2014
From: issues at jboss.org (Richard Achmatowicz (JIRA))
Date: Thu, 6 Mar 2014 11:45:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1806) UnicastLoopbackTest fails to
 receive all messages in the allotted time
In-Reply-To: <JIRA.12534313.1394124154000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534313.1394124154000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534313.1394124154000.9639.1394124333372@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JGRP-1806?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Richard Achmatowicz updated JGRP-1806:
--------------------------------------

    Description: 
UnicastLoopbackTest.testUnicastMessagesWithLoopback() is failing with the following error:
{noformat}
Error Message

Test timed out before all messages were received
Stacktrace

java.lang.AssertionError 
at org.testng.Assert.fail(Assert.java:94) 
at org.jgroups.tests.UnicastLoopbackTest.testUnicastMsgsWithLoopback(UnicastLoopbackTest.java:78) 
{noformat}

The test does the following:
- creates one channel with loopback enabled in the transport
- the channel is assigned a receiver which collects the messages received and sets a Boolean valued Promise when all messages have been received 
- the channel sends 1000 messages to itself in a burst
- waits 20 seconds for the promise to be set to true

The test fails because the messages do not arrive within the allotted 20 seconds.


  was:
UnicastLoopbackTest.testUnicastMessagesWithLoopback() is failing with the following error:
{noformat}
Error Message

Test timed out before all messages were received
Stacktrace

java.lang.AssertionError 
at org.testng.Assert.fail(Assert.java:94) 
at org.jgroups.tests.UnicastLoopbackTest.testUnicastMsgsWithLoopback(UnicastLoopbackTest.java:78) 
{noformat}

The test does the following:
- creates one channel with loopback enabled in the transport
- the channel is assigned a receiver which collects the messages received and sets a Boolean valued Promise when all messages have been received 
- sends 1000 messages in a burst to the channel
- waits 20 seconds for the promise to be set to true

The test fails because the messages do not arrive within the allotted 20 seconds.



    
> UnicastLoopbackTest fails to receive all messages in the allotted time
> ----------------------------------------------------------------------
>
>                 Key: JGRP-1806
>                 URL: https://issues.jboss.org/browse/JGRP-1806
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.2.13
>         Environment: RHEL, Windows, Solaris
>            Reporter: Richard Achmatowicz
>            Assignee: Bela Ban
>             Fix For: 3.2.13
>
>
> UnicastLoopbackTest.testUnicastMessagesWithLoopback() is failing with the following error:
> {noformat}
> Error Message
> Test timed out before all messages were received
> Stacktrace
> java.lang.AssertionError 
> at org.testng.Assert.fail(Assert.java:94) 
> at org.jgroups.tests.UnicastLoopbackTest.testUnicastMsgsWithLoopback(UnicastLoopbackTest.java:78) 
> {noformat}
> The test does the following:
> - creates one channel with loopback enabled in the transport
> - the channel is assigned a receiver which collects the messages received and sets a Boolean valued Promise when all messages have been received 
> - the channel sends 1000 messages to itself in a burst
> - waits 20 seconds for the promise to be set to true
> The test fails because the messages do not arrive within the allotted 20 seconds.

--
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

From issues at jboss.org  Thu Mar  6 11:49:35 2014
From: issues at jboss.org (Richard Achmatowicz (JIRA))
Date: Thu, 6 Mar 2014 11:49:35 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1806) UnicastLoopbackTest fails to
 receive all messages in the allotted time
In-Reply-To: <JIRA.12534313.1394124154000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534313.1394124154000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534313.1394124154000.9733.1394124575994@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JGRP-1806?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12950802#comment-12950802 ] 

Richard Achmatowicz commented on JGRP-1806:
-------------------------------------------

Because the channel has loopback defined, messages do not go into the network, but rather are sent directly back up the stack
A thread pool is used to queue these calls up the stack, and this is one place where delays to processing might occur.
Adding trace logging to TP shows the state of the thread pool after each message send:

{noformat}
144526 [TRACE] UDP: - received [dst: lenovo-50183, src: lenovo-50183 (2 headers), size=5 bytes], headers are UNICAST: DATA, seqno=932, UDP: [channel_name=demo-group]
144526 [TRACE] UDP: - sending msg to lenovo-50183, src=lenovo-50183, headers are UNICAST: ACK, seqno=932, UDP: [channel_name=demo-group]
144526 [TRACE] UDP: - looping back message [dst: lenovo-50183, src: lenovo-50183 (2 headers), size=0 bytes]
144526 [TRACE] UDP: - thread pool state: active tasks = 2, queued tasks = 257
{noformat}
 
Although the pool queue does grow in size, this is expected.
                
> UnicastLoopbackTest fails to receive all messages in the allotted time
> ----------------------------------------------------------------------
>
>                 Key: JGRP-1806
>                 URL: https://issues.jboss.org/browse/JGRP-1806
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.2.13
>         Environment: RHEL, Windows, Solaris
>            Reporter: Richard Achmatowicz
>            Assignee: Bela Ban
>             Fix For: 3.2.13
>
>
> UnicastLoopbackTest.testUnicastMessagesWithLoopback() is failing with the following error:
> {noformat}
> Error Message
> Test timed out before all messages were received
> Stacktrace
> java.lang.AssertionError 
> at org.testng.Assert.fail(Assert.java:94) 
> at org.jgroups.tests.UnicastLoopbackTest.testUnicastMsgsWithLoopback(UnicastLoopbackTest.java:78) 
> {noformat}
> The test does the following:
> - creates one channel with loopback enabled in the transport
> - the channel is assigned a receiver which collects the messages received and sets a Boolean valued Promise when all messages have been received 
> - the channel sends 1000 messages to itself in a burst
> - waits 20 seconds for the promise to be set to true
> The test fails because the messages do not arrive within the allotted 20 seconds.

--
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

From issues at jboss.org  Thu Mar  6 11:51:36 2014
From: issues at jboss.org (Richard Achmatowicz (JIRA))
Date: Thu, 6 Mar 2014 11:51:36 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1806) UnicastLoopbackTest fails to
 receive all messages in the allotted time
In-Reply-To: <JIRA.12534313.1394124154000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534313.1394124154000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534313.1394124154000.9783.1394124696099@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JGRP-1806?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12950803#comment-12950803 ] 

Richard Achmatowicz commented on JGRP-1806:
-------------------------------------------

After discussion, agreed with Bela to extend the timeout from 20 seconds to 60 seconds, to account for execution on slow machines. The timeout for this test is only relevant for ensuring that the test does not hang. As long as all messages are received *eventually*, the test passes.
                
> UnicastLoopbackTest fails to receive all messages in the allotted time
> ----------------------------------------------------------------------
>
>                 Key: JGRP-1806
>                 URL: https://issues.jboss.org/browse/JGRP-1806
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.2.13
>         Environment: RHEL, Windows, Solaris
>            Reporter: Richard Achmatowicz
>            Assignee: Bela Ban
>             Fix For: 3.2.13
>
>
> UnicastLoopbackTest.testUnicastMessagesWithLoopback() is failing with the following error:
> {noformat}
> Error Message
> Test timed out before all messages were received
> Stacktrace
> java.lang.AssertionError 
> at org.testng.Assert.fail(Assert.java:94) 
> at org.jgroups.tests.UnicastLoopbackTest.testUnicastMsgsWithLoopback(UnicastLoopbackTest.java:78) 
> {noformat}
> The test does the following:
> - creates one channel with loopback enabled in the transport
> - the channel is assigned a receiver which collects the messages received and sets a Boolean valued Promise when all messages have been received 
> - the channel sends 1000 messages to itself in a burst
> - waits 20 seconds for the promise to be set to true
> The test fails because the messages do not arrive within the allotted 20 seconds.

--
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

From issues at jboss.org  Thu Mar  6 11:57:33 2014
From: issues at jboss.org (James Perkins (JIRA))
Date: Thu, 6 Mar 2014 11:57:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (LOGMGR-101) Allow SyslogHandler to
 automatically try a reconnect
In-Reply-To: <JIRA.12534314.1394124957744@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534314.1394124957744@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534314.1394124957744.9824.1394125053243@jira02.app.mwc.hst.phx2.redhat.com>

James Perkins created LOGMGR-101:
------------------------------------

             Summary: Allow SyslogHandler to automatically try a reconnect
                 Key: LOGMGR-101
                 URL: https://issues.jboss.org/browse/LOGMGR-101
             Project: JBoss Log Manager
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
            Reporter: James Perkins
            Assignee: James Perkins


Currently the {{SyslogHandler}} does not attempt to reconnect if the connection is dropped. Some logic around trying a reconnect should be added.

--
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

From issues at jboss.org  Thu Mar  6 12:03:33 2014
From: issues at jboss.org (Richard Achmatowicz (JIRA))
Date: Thu, 6 Mar 2014 12:03:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1806) UnicastLoopbackTest fails to
 receive all messages in the allotted time
In-Reply-To: <JIRA.12534313.1394124154000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534313.1394124154000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534313.1394124154000.9832.1394125413216@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JGRP-1806?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12950806#comment-12950806 ] 

Richard Achmatowicz commented on JGRP-1806:
-------------------------------------------

Commit hash on Branch_JGroups_3_2: 9a40fbe

                
> UnicastLoopbackTest fails to receive all messages in the allotted time
> ----------------------------------------------------------------------
>
>                 Key: JGRP-1806
>                 URL: https://issues.jboss.org/browse/JGRP-1806
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.2.13
>         Environment: RHEL, Windows, Solaris
>            Reporter: Richard Achmatowicz
>            Assignee: Bela Ban
>             Fix For: 3.2.13
>
>
> UnicastLoopbackTest.testUnicastMessagesWithLoopback() is failing with the following error:
> {noformat}
> Error Message
> Test timed out before all messages were received
> Stacktrace
> java.lang.AssertionError 
> at org.testng.Assert.fail(Assert.java:94) 
> at org.jgroups.tests.UnicastLoopbackTest.testUnicastMsgsWithLoopback(UnicastLoopbackTest.java:78) 
> {noformat}
> The test does the following:
> - creates one channel with loopback enabled in the transport
> - the channel is assigned a receiver which collects the messages received and sets a Boolean valued Promise when all messages have been received 
> - the channel sends 1000 messages to itself in a burst
> - waits 20 seconds for the promise to be set to true
> The test fails because the messages do not arrive within the allotted 20 seconds.

--
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

From issues at jboss.org  Thu Mar  6 12:16:34 2014
From: issues at jboss.org (Bela Ban (JIRA))
Date: Thu, 6 Mar 2014 12:16:34 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1722) Improve performance of
	ENCRYPT protocol
In-Reply-To: <JIRA.12508426.1382426974000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508426.1382426974000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508426.1382426974000.9882.1394126194514@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JGRP-1722?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12950813#comment-12950813 ] 

Bela Ban commented on JGRP-1722:
--------------------------------

Hmm, the previous comment doesn't make much sense: as encrypted message are almost always bigger then their unencrypted input, the output buffer would have to be created anyway...
                
> Improve performance of ENCRYPT protocol
> ---------------------------------------
>
>                 Key: JGRP-1722
>                 URL: https://issues.jboss.org/browse/JGRP-1722
>             Project: JGroups
>          Issue Type: Enhancement
>    Affects Versions: 3.4
>            Reporter: Martin Gencur
>            Assignee: Bela Ban
>             Fix For: 3.5
>
>
> A stress tests with the following setup showed that performance (reads and writes/sec) is halved when ENCRYPT protocol is enabled:
> Infinispan had distributed sync cache with 2 owners on 4 nodes, no transactions. The stress test used 10 threads on each node accessing 1024 byte entries, no conflicts on keys, 20 % writes, 80 % reads. 
> It would be great if we could improve the performance of ENCRYPT protocol.

--
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

From issues at jboss.org  Thu Mar  6 12:24:33 2014
From: issues at jboss.org (Eduardo Martins (JIRA))
Date: Thu, 6 Mar 2014 12:24:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2936) "Only session and
 message-driven beans with bean-managed transaction demarcation are allowed
 to access UserTransaction" error in migrated seam 2.2.2 application
In-Reply-To: <JIRA.12532176.1392367721000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12532176.1392367721000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12532176.1392367721000.9936.1394126673824@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2936?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12950815#comment-12950815 ] 

Eduardo Martins commented on WFLY-2936:
---------------------------------------

The issue should be fixed in latest builds, which you may find at 

https://ci.jboss.org/hudson/job/WildFly-latest-master/lastBuild

If the issue persist please reopen.
                
> "Only session and message-driven beans with bean-managed transaction demarcation are allowed to access UserTransaction" error in migrated seam 2.2.2 application
> ----------------------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2936
>                 URL: https://issues.jboss.org/browse/WFLY-2936
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 8.0.0.Final
>         Environment: Windows 7 64bit
> Java 1.7.0_51
> WildFly 8.0.0.Final
> JBoss Seam 2.2.2.Final
>            Reporter: Dimitris Keramidas
>            Assignee: Eduardo Martins
>             Fix For: 8.0.1.Final
>
>         Attachments: Auth.java, Authenticator.java, components.xml, jboss-deployment-structure.xml, server.log
>
>
> The error is fired when attempting to call a transaction-enabled EJB method, from a seam component. Specifically the authentication component.
> In order to get to this position, the project's deployment descriptors had to be migrated. Furthermore, mojarra version 1.2_15 was deployed to WildFly, as described by this link: https://community.jboss.org/wiki/DesignOfWildFlyMulti-JSFFeature
> Please see attached logs and descriptors.

--
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

From issues at jboss.org  Thu Mar  6 12:26:34 2014
From: issues at jboss.org (Eduardo Martins (JIRA))
Date: Thu, 6 Mar 2014 12:26:34 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2936) "Only session and
 message-driven beans with bean-managed transaction demarcation are allowed
 to access UserTransaction" error in migrated seam 2.2.2 application
In-Reply-To: <JIRA.12532176.1392367721000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12532176.1392367721000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12532176.1392367721000.9947.1394126794002@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2936?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12950816#comment-12950816 ] 

Eduardo Martins commented on WFLY-2936:
---------------------------------------

[~steeltomato] you should not need to change anything in Seam, unless of course, if you want to use instead the released WildFly 8.0.0.Final 
                
> "Only session and message-driven beans with bean-managed transaction demarcation are allowed to access UserTransaction" error in migrated seam 2.2.2 application
> ----------------------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2936
>                 URL: https://issues.jboss.org/browse/WFLY-2936
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 8.0.0.Final
>         Environment: Windows 7 64bit
> Java 1.7.0_51
> WildFly 8.0.0.Final
> JBoss Seam 2.2.2.Final
>            Reporter: Dimitris Keramidas
>            Assignee: Eduardo Martins
>             Fix For: 8.0.1.Final
>
>         Attachments: Auth.java, Authenticator.java, components.xml, jboss-deployment-structure.xml, server.log
>
>
> The error is fired when attempting to call a transaction-enabled EJB method, from a seam component. Specifically the authentication component.
> In order to get to this position, the project's deployment descriptors had to be migrated. Furthermore, mojarra version 1.2_15 was deployed to WildFly, as described by this link: https://community.jboss.org/wiki/DesignOfWildFlyMulti-JSFFeature
> Please see attached logs and descriptors.

--
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

From issues at jboss.org  Thu Mar  6 12:38:33 2014
From: issues at jboss.org (Tomaz Cerar (JIRA))
Date: Thu, 6 Mar 2014 12:38:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3028) It should be possible to
 initialize Filters on deployment rather than on first use
In-Reply-To: <JIRA.12533361.1393420415000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12533361.1393420415000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12533361.1393420415000.9978.1394127513700@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-3028?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tomaz Cerar updated WFLY-3028:
------------------------------

    Fix Version/s: 8.0.1.Final

    
> It should be possible to initialize Filters on deployment rather than on first use
> ----------------------------------------------------------------------------------
>
>                 Key: WFLY-3028
>                 URL: https://issues.jboss.org/browse/WFLY-3028
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Web (Undertow)
>    Affects Versions: 8.0.0.CR1
>         Environment: Ubuntu 12.04.1 LTS 32b | JVM 1.7 | 
>            Reporter: Nicolas Barrera
>            Assignee: Tomaz Cerar
>              Labels: servletfilter
>             Fix For: 8.0.1.Final
>
>
> As I see it Wildfly ?Lazy-Inits? Filters, and that's causing some problems in my project, here is my case:
> It happens that I have a filter chain declared in web.xml
> FilterA -> FilterB
> so that when a new request arrives FilterA is executed first and FilterB second.
> My problem is that FilterA needs FilterB to be initialized before it's filter method is executed.
> When using other web containers (tomcat/jetty) I had no problem with this scenario because filters' init method is called on server startup. 
> With wildfly the init method of a Filter is not called until it receives the first request so the methods would be called in this order:
> FilterA.init, FilterA.filter, FilterB.init, FilterB.filter
> and FilterA.filter will fail because FilterB.init wasn't called earlier.
> Maybe it's ok to have certain mode where Filters are initialized lazily but I 'd like to have some configuration option that let me initialize filters on startup.
> I 've asked on stackoverflow about this problem and after a while only one person showed up and recommended me to raise a JIRA, so I assumed this was not possible in Wildfly 8.

--
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


From issues at jboss.org  Thu Mar  6 12:40:33 2014
From: issues at jboss.org (Rituraj Sinha (JIRA))
Date: Thu, 6 Mar 2014 12:40:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3051) JMX connection to remote
 server-instances is not happening in wildfly 8.0.0.Final in domain mode
In-Reply-To: <JIRA.12533723.1393825342000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12533723.1393825342000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12533723.1393825342000.9985.1394127633404@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-3051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12950822#comment-12950822 ] 

Rituraj Sinha commented on WFLY-3051:
-------------------------------------

Thanks Darran ..for changing the status ....
just a thought...is it possible to use the remoting port like 4447 to connect to JMX ....as we were able to do in jboss 7.2.0 ...i was able to connect to remote instances there ...if yes then what are the changes needed to be done ...
                
> JMX connection to remote server-instances is not happening in wildfly 8.0.0.Final in domain mode
> ------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-3051
>                 URL: https://issues.jboss.org/browse/WFLY-3051
>             Project: WildFly
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: JMX, Remoting
>    Affects Versions: 8.0.0.Final
>            Reporter: Rituraj Sinha
>            Assignee: Darran Lofthouse
>             Fix For: 8.0.1.Final
>
>
> i have gone through the below link for JMX subsystem for wildfly 8 as
> https://docs.jboss.org/author/display/WFLY8/JMX+subsystem+configuration
>  
> but unable to connect to server-instances running remotely ...i have posted my question there as well and pasting it here now ...
> can someone please give us the steps to configure JMX through jconsole...?
> changes done on the domain.xml are the same as stated above
> <subsystem xmlns="urn:jboss:domain:jmx:1.3">
>                 <expose-resolved-model/>
>                 <expose-expression-model/>
>                 <remoting-connector use-management-endpoint="false"/>
>             </subsystem>
> <subsystem xmlns="urn:jboss:domain:jmx:1.3">
>                 <expose-resolved-model/>
>                 <expose-expression-model/>
>                 <remoting-connector use-management-endpoint="false"/>
>             </subsystem>
> as per the jboss-as-jmx_1_3.xsd  its like
> <xs:attribute name="use-management-endpoint" type="xs:boolean" default="true" use="optional" >
>             <xs:annotation>
>                 <xs:documentation>
>                     If true then this connector will use the management endpoint, otherwise it will use the
>                     remoting subsystem endpoint.
>                 </xs:documentation>
>             </xs:annotation>
>         </xs:attribute>
> now if we are making it false then it should be using the remoting endpoint ...now remoting subsystem by default uses ApplicatoinRealm
> i have created application-user and password for the same but when i am trying to connect to remote server-instances its not connecting it....
> below is what i am able to connect to 
> service:jmx:http-remoting-jmx://remote_hostA:9990 --
> Unknown macro: {host A is where my domain_controller is running}
> how can i access the server-instances running on domain_controller
> Unknown macro: {there are three server_instanaces running on HostA with a port offset of 100 each}
> i am trying to connect with the below url as 
> service:jmx:http-remoting-jmx://lremote_hostA:8180
> let me know if something is missing from my side...
> Thanks

--
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

From issues at jboss.org  Thu Mar  6 12:46:33 2014
From: issues at jboss.org (John Patton (JIRA))
Date: Thu, 6 Mar 2014 12:46:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3051) JMX connection to remote
 server-instances is not happening in wildfly 8.0.0.Final in domain mode
In-Reply-To: <JIRA.12533723.1393825342000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12533723.1393825342000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12533723.1393825342000.10010.1394127993480@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-3051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12950826#comment-12950826 ] 

John Patton commented on WFLY-3051:
-----------------------------------

I think a remoting port would work for us, as well.  Any ideas on a workaround like that?
                
> JMX connection to remote server-instances is not happening in wildfly 8.0.0.Final in domain mode
> ------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-3051
>                 URL: https://issues.jboss.org/browse/WFLY-3051
>             Project: WildFly
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: JMX, Remoting
>    Affects Versions: 8.0.0.Final
>            Reporter: Rituraj Sinha
>            Assignee: Darran Lofthouse
>             Fix For: 8.0.1.Final
>
>
> i have gone through the below link for JMX subsystem for wildfly 8 as
> https://docs.jboss.org/author/display/WFLY8/JMX+subsystem+configuration
>  
> but unable to connect to server-instances running remotely ...i have posted my question there as well and pasting it here now ...
> can someone please give us the steps to configure JMX through jconsole...?
> changes done on the domain.xml are the same as stated above
> <subsystem xmlns="urn:jboss:domain:jmx:1.3">
>                 <expose-resolved-model/>
>                 <expose-expression-model/>
>                 <remoting-connector use-management-endpoint="false"/>
>             </subsystem>
> <subsystem xmlns="urn:jboss:domain:jmx:1.3">
>                 <expose-resolved-model/>
>                 <expose-expression-model/>
>                 <remoting-connector use-management-endpoint="false"/>
>             </subsystem>
> as per the jboss-as-jmx_1_3.xsd  its like
> <xs:attribute name="use-management-endpoint" type="xs:boolean" default="true" use="optional" >
>             <xs:annotation>
>                 <xs:documentation>
>                     If true then this connector will use the management endpoint, otherwise it will use the
>                     remoting subsystem endpoint.
>                 </xs:documentation>
>             </xs:annotation>
>         </xs:attribute>
> now if we are making it false then it should be using the remoting endpoint ...now remoting subsystem by default uses ApplicatoinRealm
> i have created application-user and password for the same but when i am trying to connect to remote server-instances its not connecting it....
> below is what i am able to connect to 
> service:jmx:http-remoting-jmx://remote_hostA:9990 --
> Unknown macro: {host A is where my domain_controller is running}
> how can i access the server-instances running on domain_controller
> Unknown macro: {there are three server_instanaces running on HostA with a port offset of 100 each}
> i am trying to connect with the below url as 
> service:jmx:http-remoting-jmx://lremote_hostA:8180
> let me know if something is missing from my side...
> Thanks

--
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

From issues at jboss.org  Thu Mar  6 12:56:33 2014
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 6 Mar 2014 12:56:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3051) JMX connection to remote
 server-instances is not happening in wildfly 8.0.0.Final in domain mode
In-Reply-To: <JIRA.12533723.1393825342000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12533723.1393825342000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12533723.1393825342000.10030.1394128593963@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-3051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12950831#comment-12950831 ] 

Darran Lofthouse commented on WFLY-3051:
----------------------------------------

For workarounds I suggest you start a forum discussion for that, overall you would be re-introducing the configuration that was removed just before WildFly 8.0.0.Final was tagged,

For this issue.

  1 - This issue has been raised against domain mode, is this working for everyone in standalone mode or is that also affected?
  2 - Are error messages being experienced in the client or on the server?


                
> JMX connection to remote server-instances is not happening in wildfly 8.0.0.Final in domain mode
> ------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-3051
>                 URL: https://issues.jboss.org/browse/WFLY-3051
>             Project: WildFly
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: JMX, Remoting
>    Affects Versions: 8.0.0.Final
>            Reporter: Rituraj Sinha
>            Assignee: Darran Lofthouse
>             Fix For: 8.0.1.Final
>
>
> i have gone through the below link for JMX subsystem for wildfly 8 as
> https://docs.jboss.org/author/display/WFLY8/JMX+subsystem+configuration
>  
> but unable to connect to server-instances running remotely ...i have posted my question there as well and pasting it here now ...
> can someone please give us the steps to configure JMX through jconsole...?
> changes done on the domain.xml are the same as stated above
> <subsystem xmlns="urn:jboss:domain:jmx:1.3">
>                 <expose-resolved-model/>
>                 <expose-expression-model/>
>                 <remoting-connector use-management-endpoint="false"/>
>             </subsystem>
> <subsystem xmlns="urn:jboss:domain:jmx:1.3">
>                 <expose-resolved-model/>
>                 <expose-expression-model/>
>                 <remoting-connector use-management-endpoint="false"/>
>             </subsystem>
> as per the jboss-as-jmx_1_3.xsd  its like
> <xs:attribute name="use-management-endpoint" type="xs:boolean" default="true" use="optional" >
>             <xs:annotation>
>                 <xs:documentation>
>                     If true then this connector will use the management endpoint, otherwise it will use the
>                     remoting subsystem endpoint.
>                 </xs:documentation>
>             </xs:annotation>
>         </xs:attribute>
> now if we are making it false then it should be using the remoting endpoint ...now remoting subsystem by default uses ApplicatoinRealm
> i have created application-user and password for the same but when i am trying to connect to remote server-instances its not connecting it....
> below is what i am able to connect to 
> service:jmx:http-remoting-jmx://remote_hostA:9990 --
> Unknown macro: {host A is where my domain_controller is running}
> how can i access the server-instances running on domain_controller
> Unknown macro: {there are three server_instanaces running on HostA with a port offset of 100 each}
> i am trying to connect with the below url as 
> service:jmx:http-remoting-jmx://lremote_hostA:8180
> let me know if something is missing from my side...
> Thanks

--
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

From issues at jboss.org  Thu Mar  6 13:11:33 2014
From: issues at jboss.org (John Patton (JIRA))
Date: Thu, 6 Mar 2014 13:11:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3051) JMX connection to remote
 server-instances is not happening in wildfly 8.0.0.Final in domain mode
In-Reply-To: <JIRA.12533723.1393825342000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12533723.1393825342000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12533723.1393825342000.10066.1394129493744@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-3051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12950836#comment-12950836 ] 

John Patton commented on WFLY-3051:
-----------------------------------

1. Haven't tried against standalone myself, but I'd presume the same issue exists.  I can give this a try and get back to you. 
2. When i connect locally with jconsole or visualvm to locally running wildfly instance, I can see host controller and app server instance mbeans.  When I connect remotely, i can only see the host controller mbeans when the host controller runs on port 9990.  Errors are occurring in the connection between jconsole/visualvm and wildfly... so I presume the client in the form of JMX connection errors?
                
> JMX connection to remote server-instances is not happening in wildfly 8.0.0.Final in domain mode
> ------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-3051
>                 URL: https://issues.jboss.org/browse/WFLY-3051
>             Project: WildFly
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: JMX, Remoting
>    Affects Versions: 8.0.0.Final
>            Reporter: Rituraj Sinha
>            Assignee: Darran Lofthouse
>             Fix For: 8.0.1.Final
>
>
> i have gone through the below link for JMX subsystem for wildfly 8 as
> https://docs.jboss.org/author/display/WFLY8/JMX+subsystem+configuration
>  
> but unable to connect to server-instances running remotely ...i have posted my question there as well and pasting it here now ...
> can someone please give us the steps to configure JMX through jconsole...?
> changes done on the domain.xml are the same as stated above
> <subsystem xmlns="urn:jboss:domain:jmx:1.3">
>                 <expose-resolved-model/>
>                 <expose-expression-model/>
>                 <remoting-connector use-management-endpoint="false"/>
>             </subsystem>
> <subsystem xmlns="urn:jboss:domain:jmx:1.3">
>                 <expose-resolved-model/>
>                 <expose-expression-model/>
>                 <remoting-connector use-management-endpoint="false"/>
>             </subsystem>
> as per the jboss-as-jmx_1_3.xsd  its like
> <xs:attribute name="use-management-endpoint" type="xs:boolean" default="true" use="optional" >
>             <xs:annotation>
>                 <xs:documentation>
>                     If true then this connector will use the management endpoint, otherwise it will use the
>                     remoting subsystem endpoint.
>                 </xs:documentation>
>             </xs:annotation>
>         </xs:attribute>
> now if we are making it false then it should be using the remoting endpoint ...now remoting subsystem by default uses ApplicatoinRealm
> i have created application-user and password for the same but when i am trying to connect to remote server-instances its not connecting it....
> below is what i am able to connect to 
> service:jmx:http-remoting-jmx://remote_hostA:9990 --
> Unknown macro: {host A is where my domain_controller is running}
> how can i access the server-instances running on domain_controller
> Unknown macro: {there are three server_instanaces running on HostA with a port offset of 100 each}
> i am trying to connect with the below url as 
> service:jmx:http-remoting-jmx://lremote_hostA:8180
> let me know if something is missing from my side...
> Thanks

--
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

From issues at jboss.org  Thu Mar  6 13:19:35 2014
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 6 Mar 2014 13:19:35 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3051) JMX connection to remote
 server-instances is not happening in wildfly 8.0.0.Final in domain mode
In-Reply-To: <JIRA.12533723.1393825342000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12533723.1393825342000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12533723.1393825342000.10139.1394129975066@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-3051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12950845#comment-12950845 ] 

Darran Lofthouse commented on WFLY-3051:
----------------------------------------

All - FYI there is a risk here that although everyone thinks this is a single common issue that in fact you may all be experiencing something different.

For now if we can lets consider this in terms of jconsole, that is the one I have easiest to hand.

[~johnhpatton] When you are talking about connecting locally and remotely are you using a service URL in all cases or is this a case of sometimes you are selecting the local process and the other times using a service URL?

Apart from the connection errors the difference in MBeans actually visible does sound correct i.e. when you connect to port 9990 i.e. the host controller it is correct you would only see the MBeans of that host controller - as specified in the original description you would need to add the remoting-connector element to the JMX subsystem and connect over the port of the web server to see the MBeans of the individual AS instances.

I do have a pending task to review proxying these requests through the host controller to the AS instance but that is currently a low priority.  Feel free to get votes in to WFLY-421 ;-)

                
> JMX connection to remote server-instances is not happening in wildfly 8.0.0.Final in domain mode
> ------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-3051
>                 URL: https://issues.jboss.org/browse/WFLY-3051
>             Project: WildFly
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: JMX, Remoting
>    Affects Versions: 8.0.0.Final
>            Reporter: Rituraj Sinha
>            Assignee: Darran Lofthouse
>             Fix For: 8.0.1.Final
>
>
> i have gone through the below link for JMX subsystem for wildfly 8 as
> https://docs.jboss.org/author/display/WFLY8/JMX+subsystem+configuration
>  
> but unable to connect to server-instances running remotely ...i have posted my question there as well and pasting it here now ...
> can someone please give us the steps to configure JMX through jconsole...?
> changes done on the domain.xml are the same as stated above
> <subsystem xmlns="urn:jboss:domain:jmx:1.3">
>                 <expose-resolved-model/>
>                 <expose-expression-model/>
>                 <remoting-connector use-management-endpoint="false"/>
>             </subsystem>
> <subsystem xmlns="urn:jboss:domain:jmx:1.3">
>                 <expose-resolved-model/>
>                 <expose-expression-model/>
>                 <remoting-connector use-management-endpoint="false"/>
>             </subsystem>
> as per the jboss-as-jmx_1_3.xsd  its like
> <xs:attribute name="use-management-endpoint" type="xs:boolean" default="true" use="optional" >
>             <xs:annotation>
>                 <xs:documentation>
>                     If true then this connector will use the management endpoint, otherwise it will use the
>                     remoting subsystem endpoint.
>                 </xs:documentation>
>             </xs:annotation>
>         </xs:attribute>
> now if we are making it false then it should be using the remoting endpoint ...now remoting subsystem by default uses ApplicatoinRealm
> i have created application-user and password for the same but when i am trying to connect to remote server-instances its not connecting it....
> below is what i am able to connect to 
> service:jmx:http-remoting-jmx://remote_hostA:9990 --
> Unknown macro: {host A is where my domain_controller is running}
> how can i access the server-instances running on domain_controller
> Unknown macro: {there are three server_instanaces running on HostA with a port offset of 100 each}
> i am trying to connect with the below url as 
> service:jmx:http-remoting-jmx://lremote_hostA:8180
> let me know if something is missing from my side...
> Thanks

--
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

From issues at jboss.org  Thu Mar  6 13:23:33 2014
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 6 Mar 2014 13:23:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3051) JMX connection to remote
 server-instances is not happening in wildfly 8.0.0.Final in domain mode
In-Reply-To: <JIRA.12533723.1393825342000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12533723.1393825342000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12533723.1393825342000.10152.1394130213631@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-3051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12950847#comment-12950847 ] 

Darran Lofthouse commented on WFLY-3051:
----------------------------------------

Regarding jconsole I can reproduce one error in standalone mode and domain mode if I attempt to connect over the web server, I need to debug further but jconsole is reporting: -

  Connection Failed SSL1
  Connection Failed SSL2

Let me know if this is the error you are seeing so I know I am on the right track.
                
> JMX connection to remote server-instances is not happening in wildfly 8.0.0.Final in domain mode
> ------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-3051
>                 URL: https://issues.jboss.org/browse/WFLY-3051
>             Project: WildFly
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: JMX, Remoting
>    Affects Versions: 8.0.0.Final
>            Reporter: Rituraj Sinha
>            Assignee: Darran Lofthouse
>             Fix For: 8.0.1.Final
>
>
> i have gone through the below link for JMX subsystem for wildfly 8 as
> https://docs.jboss.org/author/display/WFLY8/JMX+subsystem+configuration
>  
> but unable to connect to server-instances running remotely ...i have posted my question there as well and pasting it here now ...
> can someone please give us the steps to configure JMX through jconsole...?
> changes done on the domain.xml are the same as stated above
> <subsystem xmlns="urn:jboss:domain:jmx:1.3">
>                 <expose-resolved-model/>
>                 <expose-expression-model/>
>                 <remoting-connector use-management-endpoint="false"/>
>             </subsystem>
> <subsystem xmlns="urn:jboss:domain:jmx:1.3">
>                 <expose-resolved-model/>
>                 <expose-expression-model/>
>                 <remoting-connector use-management-endpoint="false"/>
>             </subsystem>
> as per the jboss-as-jmx_1_3.xsd  its like
> <xs:attribute name="use-management-endpoint" type="xs:boolean" default="true" use="optional" >
>             <xs:annotation>
>                 <xs:documentation>
>                     If true then this connector will use the management endpoint, otherwise it will use the
>                     remoting subsystem endpoint.
>                 </xs:documentation>
>             </xs:annotation>
>         </xs:attribute>
> now if we are making it false then it should be using the remoting endpoint ...now remoting subsystem by default uses ApplicatoinRealm
> i have created application-user and password for the same but when i am trying to connect to remote server-instances its not connecting it....
> below is what i am able to connect to 
> service:jmx:http-remoting-jmx://remote_hostA:9990 --
> Unknown macro: {host A is where my domain_controller is running}
> how can i access the server-instances running on domain_controller
> Unknown macro: {there are three server_instanaces running on HostA with a port offset of 100 each}
> i am trying to connect with the below url as 
> service:jmx:http-remoting-jmx://lremote_hostA:8180
> let me know if something is missing from my side...
> Thanks

--
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

From issues at jboss.org  Thu Mar  6 14:07:33 2014
From: issues at jboss.org (Davide Sottara (JIRA))
Date: Thu, 6 Mar 2014 14:07:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-441) drools-guvnor 5.5,
 declarative model, create more than one fact type,
 BPMN process does not load
In-Reply-To: <JIRA.12533209.1393317312000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12533209.1393317312000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12533209.1393317312000.10240.1394132853700@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/DROOLS-441?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12950854#comment-12950854 ] 

Davide Sottara commented on DROOLS-441:
---------------------------------------

Since you've been able to isolate it, could you please describe what happens exactly in loadDeclaredTypesToBuilder() that causes the problem?
An error log or an exception stack trace would be useful, if available
Thanks
                
> drools-guvnor 5.5, declarative model, create more than one fact type, BPMN process does not load
> ------------------------------------------------------------------------------------------------
>
>                 Key: DROOLS-441
>                 URL: https://issues.jboss.org/browse/DROOLS-441
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.5.0.Final
>         Environment: Tomcat 6.0.35, jBPM 5.5.Final
>            Reporter: niraj gupta
>            Assignee: Mark Proctor
>              Labels: drools-guvnor
>
>  I am using ?drools-guvnor 5.5.0.Final? open source tool for designing the business process (BPMN2). I end up in an issue and looking for help. Following is the scenario
> I created a package then process then after build, deploy execute successfully. Now I came back to guvnor and made few changes in the process. Then after same build, deploy execute successfully. But now this time I am creating a declarative model having 2 facts, also modifying business process. Then after same build, deploy execute successfully. This time modified/latest business process doesn?t load into console. This is my problem.  However I trouble shoot and google following are my observations:
> ?	I am running this application in tomcat 6.0.35
> ?	It works perfectly with POJO Model Jar approach.
> ?	It works perfectly with declarative model but having single fact.
> ?	I am not seeing any exceptions either in UI or console logs

--
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


From issues at jboss.org  Thu Mar  6 14:11:33 2014
From: issues at jboss.org (Ron Sigal (JIRA))
Date: Thu, 6 Mar 2014 14:11:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JBREM-1325) Release 2.5.4.SP5
In-Reply-To: <JIRA.12517942.1383579431000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12517942.1383579431000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12517942.1383579431000.10242.1394133093273@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JBREM-1325?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12950855#comment-12950855 ] 

Ron Sigal commented on JBREM-1325:
----------------------------------

Tagged: https://svn.jboss.org/repos/jbossremoting/remoting2/tags/2.5.4.SP5

Announced: http://www.jboss.org/jbossremoting
                
> Release 2.5.4.SP5
> -----------------
>
>                 Key: JBREM-1325
>                 URL: https://issues.jboss.org/browse/JBREM-1325
>             Project: JBoss Remoting
>          Issue Type: Release
>      Security Level: Public(Everyone can see) 
>            Reporter: Ron Sigal
>            Assignee: Ron Sigal
>             Fix For: 2.5.4.SP5
>
>


--
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

From issues at jboss.org  Thu Mar  6 14:11:33 2014
From: issues at jboss.org (Ron Sigal (JIRA))
Date: Thu, 6 Mar 2014 14:11:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JBREM-1325) Release 2.5.4.SP5
In-Reply-To: <JIRA.12517942.1383579431000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12517942.1383579431000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12517942.1383579431000.10245.1394133093426@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBREM-1325?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ron Sigal resolved JBREM-1325.
------------------------------

    Resolution: Done

    
> Release 2.5.4.SP5
> -----------------
>
>                 Key: JBREM-1325
>                 URL: https://issues.jboss.org/browse/JBREM-1325
>             Project: JBoss Remoting
>          Issue Type: Release
>      Security Level: Public(Everyone can see) 
>            Reporter: Ron Sigal
>            Assignee: Ron Sigal
>             Fix For: 2.5.4.SP5
>
>


--
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

From issues at jboss.org  Thu Mar  6 14:11:33 2014
From: issues at jboss.org (Ron Sigal (JIRA))
Date: Thu, 6 Mar 2014 14:11:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JBREM-1325) Release 2.5.4.SP5
In-Reply-To: <JIRA.12517942.1383579431000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12517942.1383579431000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12517942.1383579431000.10249.1394133093629@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBREM-1325?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ron Sigal closed JBREM-1325.
----------------------------


    
> Release 2.5.4.SP5
> -----------------
>
>                 Key: JBREM-1325
>                 URL: https://issues.jboss.org/browse/JBREM-1325
>             Project: JBoss Remoting
>          Issue Type: Release
>      Security Level: Public(Everyone can see) 
>            Reporter: Ron Sigal
>            Assignee: Ron Sigal
>             Fix For: 2.5.4.SP5
>
>


--
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

From issues at jboss.org  Thu Mar  6 15:09:33 2014
From: issues at jboss.org (Stuart Douglas (JIRA))
Date: Thu, 6 Mar 2014 15:09:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1359) Make deployment overlays work
 when adding resource roots
In-Reply-To: <JIRA.12492021.1368773242000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12492021.1368773242000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12492021.1368773242000.10314.1394136573415@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-1359?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stuart Douglas resolved WFLY-1359.
----------------------------------

    Fix Version/s: 8.0.1.Final
       Resolution: Done

    
> Make deployment overlays work when adding resource roots
> --------------------------------------------------------
>
>                 Key: WFLY-1359
>                 URL: https://issues.jboss.org/browse/WFLY-1359
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Server
>            Reporter: Stuart Douglas
>            Assignee: Stuart Douglas
>             Fix For: 8.0.1.Final
>
>
> It would be nice to be able add or override complete jars using the deployment overlay mechanism. 

--
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

From issues at jboss.org  Thu Mar  6 15:37:33 2014
From: issues at jboss.org (Stuart Douglas (JIRA))
Date: Thu, 6 Mar 2014 15:37:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2748) Review use of
	CurrentServiceContainer
In-Reply-To: <JIRA.12529190.1389611902000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529190.1389611902000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529190.1389611902000.10354.1394138253865@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2748?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stuart Douglas resolved WFLY-2748.
----------------------------------

    Resolution: Out of Date

    
> Review use of CurrentServiceContainer
> -------------------------------------
>
>                 Key: WFLY-2748
>                 URL: https://issues.jboss.org/browse/WFLY-2748
>             Project: WildFly
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>            Reporter: Stuart Douglas
>            Assignee: Stuart Douglas
>
> It looks like this is being used in some places where there is other options available. 

--
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

From issues at jboss.org  Thu Mar  6 15:55:35 2014
From: issues at jboss.org (Vijay Kumar (JIRA))
Date: Thu, 6 Mar 2014 15:55:35 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2936) "Only session and
 message-driven beans with bean-managed transaction demarcation are allowed
 to access UserTransaction" error in migrated seam 2.2.2 application
In-Reply-To: <JIRA.12532176.1392367721000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12532176.1392367721000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12532176.1392367721000.10403.1394139335793@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2936?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12950876#comment-12950876 ] 

Vijay Kumar commented on WFLY-2936:
-----------------------------------

Hi Eduardo, fix (build 991) is good. I don't see this error anymore. 

Thanks a lot for quick fix. 
Vijay 
                
> "Only session and message-driven beans with bean-managed transaction demarcation are allowed to access UserTransaction" error in migrated seam 2.2.2 application
> ----------------------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2936
>                 URL: https://issues.jboss.org/browse/WFLY-2936
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 8.0.0.Final
>         Environment: Windows 7 64bit
> Java 1.7.0_51
> WildFly 8.0.0.Final
> JBoss Seam 2.2.2.Final
>            Reporter: Dimitris Keramidas
>            Assignee: Eduardo Martins
>             Fix For: 8.0.1.Final
>
>         Attachments: Auth.java, Authenticator.java, components.xml, jboss-deployment-structure.xml, server.log
>
>
> The error is fired when attempting to call a transaction-enabled EJB method, from a seam component. Specifically the authentication component.
> In order to get to this position, the project's deployment descriptors had to be migrated. Furthermore, mojarra version 1.2_15 was deployed to WildFly, as described by this link: https://community.jboss.org/wiki/DesignOfWildFlyMulti-JSFFeature
> Please see attached logs and descriptors.

--
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

From issues at jboss.org  Thu Mar  6 16:07:34 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 6 Mar 2014 16:07:34 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (SECURITY-803) SecureIdentityLoginModule
 (and ConfiguredIdentityLoginModule) results are not cached by the JAAS
 cache
In-Reply-To: <JIRA.12533296.1393360112000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12533296.1393360112000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12533296.1393360112000.10463.1394140054316@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/SECURITY-803?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated SECURITY-803:
---------------------------------------------

    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1069885, https://bugzilla.redhat.com/show_bug.cgi?id=1069886, https://bugzilla.redhat.com/show_bug.cgi?id=1073646  (was: https://bugzilla.redhat.com/show_bug.cgi?id=1069885, https://bugzilla.redhat.com/show_bug.cgi?id=1069886)

    
> SecureIdentityLoginModule (and ConfiguredIdentityLoginModule) results are not cached by the JAAS cache
> ------------------------------------------------------------------------------------------------------
>
>                 Key: SECURITY-803
>                 URL: https://issues.jboss.org/browse/SECURITY-803
>             Project: PicketBox 
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: PicketBox
>    Affects Versions: PicketBox_4_0_19.Final
>            Reporter: Derek Horton
>            Assignee: Stefan Guilhen
>         Attachments: SECURITY-803.patch
>
>
> In EAP 6, when using the SecureIdentityLoginModule to encrypt datasource passwords, the results are not cached by the JAAS cache.  In EAP 5, the results are cached.  This can lead to a performance issue.
> The root cause appears to be that the EAP 6 JAAS cache does not allow for a JAAS cache key to be null.
> The issue only occurs when the application that uses the datasource is not secured.  In this situation, the principal is null when isValid() and updateCache() are called.  When the application is secured, the results are cached.  I think it is working because the result of the SecureIdentityLoginModule are cached using the authenticated user's principal as the cache key.
> Workaround:
> Use vault for encrypting the database password.  This does not use a JAAS login module so the JAAS cache and login module are completely avoided.

--
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

From issues at jboss.org  Thu Mar  6 17:45:34 2014
From: issues at jboss.org (Derek Horton (JIRA))
Date: Thu, 6 Mar 2014 17:45:34 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (SECURITY-803) SecureIdentityLoginModule
 (and ConfiguredIdentityLoginModule) results are not cached by the JAAS
 cache
In-Reply-To: <JIRA.12533296.1393360112000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12533296.1393360112000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12533296.1393360112000.10622.1394145934711@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/SECURITY-803?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12950920#comment-12950920 ] 

Derek Horton commented on SECURITY-803:
---------------------------------------

Patch has been committed to trunk:
https://svn.jboss.org/repos/picketbox/trunk
                
> SecureIdentityLoginModule (and ConfiguredIdentityLoginModule) results are not cached by the JAAS cache
> ------------------------------------------------------------------------------------------------------
>
>                 Key: SECURITY-803
>                 URL: https://issues.jboss.org/browse/SECURITY-803
>             Project: PicketBox 
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: PicketBox
>    Affects Versions: PicketBox_4_0_19.Final
>            Reporter: Derek Horton
>            Assignee: Stefan Guilhen
>         Attachments: SECURITY-803.patch
>
>
> In EAP 6, when using the SecureIdentityLoginModule to encrypt datasource passwords, the results are not cached by the JAAS cache.  In EAP 5, the results are cached.  This can lead to a performance issue.
> The root cause appears to be that the EAP 6 JAAS cache does not allow for a JAAS cache key to be null.
> The issue only occurs when the application that uses the datasource is not secured.  In this situation, the principal is null when isValid() and updateCache() are called.  When the application is secured, the results are cached.  I think it is working because the result of the SecureIdentityLoginModule are cached using the authenticated user's principal as the cache key.
> Workaround:
> Use vault for encrypting the database password.  This does not use a JAAS login module so the JAAS cache and login module are completely avoided.

--
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

From issues at jboss.org  Thu Mar  6 17:45:34 2014
From: issues at jboss.org (Derek Horton (JIRA))
Date: Thu, 6 Mar 2014 17:45:34 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (SECURITY-803) SecureIdentityLoginModule
 (and ConfiguredIdentityLoginModule) results are not cached by the JAAS
 cache
In-Reply-To: <JIRA.12533296.1393360112000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12533296.1393360112000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12533296.1393360112000.10625.1394145934855@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/SECURITY-803?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Derek Horton resolved SECURITY-803.
-----------------------------------

    Resolution: Done

    
> SecureIdentityLoginModule (and ConfiguredIdentityLoginModule) results are not cached by the JAAS cache
> ------------------------------------------------------------------------------------------------------
>
>                 Key: SECURITY-803
>                 URL: https://issues.jboss.org/browse/SECURITY-803
>             Project: PicketBox 
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: PicketBox
>    Affects Versions: PicketBox_4_0_19.Final
>            Reporter: Derek Horton
>            Assignee: Stefan Guilhen
>         Attachments: SECURITY-803.patch
>
>
> In EAP 6, when using the SecureIdentityLoginModule to encrypt datasource passwords, the results are not cached by the JAAS cache.  In EAP 5, the results are cached.  This can lead to a performance issue.
> The root cause appears to be that the EAP 6 JAAS cache does not allow for a JAAS cache key to be null.
> The issue only occurs when the application that uses the datasource is not secured.  In this situation, the principal is null when isValid() and updateCache() are called.  When the application is secured, the results are cached.  I think it is working because the result of the SecureIdentityLoginModule are cached using the authenticated user's principal as the cache key.
> Workaround:
> Use vault for encrypting the database password.  This does not use a JAAS login module so the JAAS cache and login module are completely avoided.

--
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

From issues at jboss.org  Thu Mar  6 17:59:33 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 6 Mar 2014 17:59:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3071) upgrade Generic JMS RA to
	1.0.2.Final
In-Reply-To: <JIRA.12534174.1394029950000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534174.1394029950000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534174.1394029950000.10645.1394146773761@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-3071?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12950926#comment-12950926 ] 

RH Bugzilla Integration commented on WFLY-3071:
-----------------------------------------------

Kabir Khan <kkhan at redhat.com> changed the Status of [bug 1073354|https://bugzilla.redhat.com/show_bug.cgi?id=1073354] from POST to MODIFIED
                
> upgrade Generic JMS RA to 1.0.2.Final
> -------------------------------------
>
>                 Key: WFLY-3071
>                 URL: https://issues.jboss.org/browse/WFLY-3071
>             Project: WildFly
>          Issue Type: Component  Upgrade
>      Security Level: Public(Everyone can see) 
>          Components: JCA
>    Affects Versions: 8.0.0.Final
>            Reporter: Jeff Mesnil
>            Assignee: Jeff Mesnil
>             Fix For: 8.0.1.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

From issues at jboss.org  Thu Mar  6 17:59:33 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 6 Mar 2014 17:59:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3073) MBeanServer.createMBean
 methods that take a classloader don't work
In-Reply-To: <JIRA.12534226.1394051286000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534226.1394051286000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534226.1394051286000.10649.1394146773940@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-3073?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12950927#comment-12950927 ] 

RH Bugzilla Integration commented on WFLY-3073:
-----------------------------------------------

Kabir Khan <kkhan at redhat.com> changed the Status of [bug 1073106|https://bugzilla.redhat.com/show_bug.cgi?id=1073106] from NEW to MODIFIED
                
> MBeanServer.createMBean methods that take a classloader don't work
> ------------------------------------------------------------------
>
>                 Key: WFLY-3073
>                 URL: https://issues.jboss.org/browse/WFLY-3073
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JMX
>    Affects Versions: 8.0.0.Final
>            Reporter: Stuart Douglas
>            Assignee: Kabir Khan
>             Fix For: 8.0.1.Final
>
>
> The MBeanServer.createMBean methods that take an "ObjectName loaderName" argument are completely broken in EAP 6.
> These methods call findDelegate to make sure there is already an existing MBean registered with the given name passed in for the new MBean, or else it throws an exception.
> This is obviously wrong, as there'd be no point in calling createMBean if it already existed.
> javax.management.InstanceNotFoundException: test:service=Test
> at org.jboss.as.jmx.PluggableMBeanServerImpl.findDelegate(PluggableMBeanServerImpl.java:1083)
> at org.jboss.as.jmx.PluggableMBeanServerImpl.createMBean(PluggableMBeanServerImpl.java:253)

--
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

From issues at jboss.org  Thu Mar  6 18:14:33 2014
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Thu, 6 Mar 2014 18:14:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3076) ModelControllerMBeanHelper
 constructor invokes unnecessary management op
In-Reply-To: <JIRA.12534343.1394147601945@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534343.1394147601945@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534343.1394147601945.10670.1394147673108@jira02.app.mwc.hst.phx2.redhat.com>

Brian Stansberry created WFLY-3076:
--------------------------------------

             Summary: ModelControllerMBeanHelper constructor invokes unnecessary management op
                 Key: WFLY-3076
                 URL: https://issues.jboss.org/browse/WFLY-3076
             Project: WildFly
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Domain Management, JMX
    Affects Versions: 8.0.0.Final
            Reporter: Brian Stansberry
            Assignee: Brian Stansberry
             Fix For: 8.0.1.Final


ModelControllerMBeanHelper is invoking a read-attribute management op in its constructor to find out of the process is a standalone server. This is not necessary -- JmxSubsystemAdd can find this out from the OperationContext and pass this information through to the ModelControllerMBeanHelper it indirectly creates.

--
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

From issues at jboss.org  Thu Mar  6 18:16:34 2014
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Thu, 6 Mar 2014 18:16:34 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3076) ModelControllerMBeanHelper
 constructor invokes unnecessary management op
In-Reply-To: <JIRA.12534343.1394147601000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534343.1394147601000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534343.1394147601000.10672.1394147794254@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-3076?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12950933#comment-12950933 ] 

Brian Stansberry commented on WFLY-3076:
----------------------------------------

This, BTW is the cause of the test failure at http://brontes.lab.eng.brq.redhat.com/viewLog.html?buildId=11936. The read-attribute call is ending up in the log and the test doesn't expect that.
                
> ModelControllerMBeanHelper constructor invokes unnecessary management op
> ------------------------------------------------------------------------
>
>                 Key: WFLY-3076
>                 URL: https://issues.jboss.org/browse/WFLY-3076
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management, JMX
>    Affects Versions: 8.0.0.Final
>            Reporter: Brian Stansberry
>            Assignee: Brian Stansberry
>             Fix For: 8.0.1.Final
>
>
> ModelControllerMBeanHelper is invoking a read-attribute management op in its constructor to find out of the process is a standalone server. This is not necessary -- JmxSubsystemAdd can find this out from the OperationContext and pass this information through to the ModelControllerMBeanHelper it indirectly creates.

--
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

From issues at jboss.org  Thu Mar  6 20:23:33 2014
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Thu, 6 Mar 2014 20:23:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3077) Convert command line IPv6 URL
 literals to address literals
In-Reply-To: <JIRA.12534346.1394155395195@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534346.1394155395195@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534346.1394155395195.10727.1394155413122@jira02.app.mwc.hst.phx2.redhat.com>

Brian Stansberry created WFLY-3077:
--------------------------------------

             Summary: Convert command line IPv6 URL literals to address literals
                 Key: WFLY-3077
                 URL: https://issues.jboss.org/browse/WFLY-3077
             Project: WildFly
          Issue Type: Enhancement
      Security Level: Public (Everyone can see)
    Affects Versions: 8.0.0.Final
            Reporter: Brian Stansberry
            Assignee: Brian Stansberry
            Priority: Minor
             Fix For: 8.0.1.Final


When people provide URL-style values like [::1] for command line args like -b, convert them to address values (i.e. strip the enclosing brackets.)

--
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

From issues at jboss.org  Thu Mar  6 20:25:33 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 6 Mar 2014 20:25:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3077) Convert command line IPv6 URL
 literals to address literals
In-Reply-To: <JIRA.12534346.1394155395000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534346.1394155395000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534346.1394155395000.10730.1394155533860@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-3077?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated WFLY-3077:
------------------------------------------

        Bugzilla Update: Perform
    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1064771

    
> Convert command line IPv6 URL literals to address literals
> ----------------------------------------------------------
>
>                 Key: WFLY-3077
>                 URL: https://issues.jboss.org/browse/WFLY-3077
>             Project: WildFly
>          Issue Type: Enhancement
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 8.0.0.Final
>            Reporter: Brian Stansberry
>            Assignee: Brian Stansberry
>            Priority: Minor
>             Fix For: 8.0.1.Final
>
>
> When people provide URL-style values like [::1] for command line args like -b, convert them to address values (i.e. strip the enclosing brackets.)

--
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

From issues at jboss.org  Thu Mar  6 20:25:33 2014
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Thu, 6 Mar 2014 20:25:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3077) Convert command line IPv6 URL
 literals to address literals
In-Reply-To: <JIRA.12534346.1394155395000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534346.1394155395000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534346.1394155395000.10731.1394155533899@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-3077?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFLY-3077:
-----------------------------------

    Bugzilla Update:   (was: Perform)

    
> Convert command line IPv6 URL literals to address literals
> ----------------------------------------------------------
>
>                 Key: WFLY-3077
>                 URL: https://issues.jboss.org/browse/WFLY-3077
>             Project: WildFly
>          Issue Type: Enhancement
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 8.0.0.Final
>            Reporter: Brian Stansberry
>            Assignee: Brian Stansberry
>            Priority: Minor
>             Fix For: 8.0.1.Final
>
>
> When people provide URL-style values like [::1] for command line args like -b, convert them to address values (i.e. strip the enclosing brackets.)

--
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

From issues at jboss.org  Thu Mar  6 21:39:33 2014
From: issues at jboss.org (Jay Kumar SenSharma (JIRA))
Date: Thu, 6 Mar 2014 21:39:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3078) directory-grouping
 configuration is not getting persisted via CLI when no servers defined
In-Reply-To: <JIRA.12534347.1394159920283@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534347.1394159920283@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534347.1394159920283.10746.1394159973234@jira02.app.mwc.hst.phx2.redhat.com>

Jay Kumar SenSharma created WFLY-3078:
-----------------------------------------

             Summary: directory-grouping configuration is not getting persisted via CLI when no servers defined
                 Key: WFLY-3078
                 URL: https://issues.jboss.org/browse/WFLY-3078
             Project: WildFly
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: CLI
    Affects Versions: 8.0.0.Final
         Environment: All Operating System
            Reporter: Jay Kumar SenSharma
            Assignee: Alexey Loubyansky


- If none of the servers are defined in "host.xml" (means <servers></servers> empty tag is present) and if the user tries to run the following CLI command to change the "directory-grouping" to  "by-type"  then the value is not persisted in the configuration file (host.xml) and the <servers></servers>  tag is also removed from the host.xml
{code}
/host=master/:write-attribute(name=directory-grouping,value=by-type)
{code}

- The value of "directory-grouping" is stored "in memory" so this change does not survive the host restart.


--
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

From issues at jboss.org  Thu Mar  6 21:41:33 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 6 Mar 2014 21:41:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3078) directory-grouping
 configuration is not getting persisted via CLI when no servers defined
In-Reply-To: <JIRA.12534347.1394159920000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534347.1394159920000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534347.1394159920000.10749.1394160093443@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-3078?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated WFLY-3078:
------------------------------------------

        Bugzilla Update: Perform
    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1073715

    
> directory-grouping configuration is not getting persisted via CLI when no servers defined
> -----------------------------------------------------------------------------------------
>
>                 Key: WFLY-3078
>                 URL: https://issues.jboss.org/browse/WFLY-3078
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: CLI
>    Affects Versions: 8.0.0.Final
>         Environment: All Operating System
>            Reporter: Jay Kumar SenSharma
>            Assignee: Alexey Loubyansky
>
> - If none of the servers are defined in "host.xml" (means <servers></servers> empty tag is present) and if the user tries to run the following CLI command to change the "directory-grouping" to  "by-type"  then the value is not persisted in the configuration file (host.xml) and the <servers></servers>  tag is also removed from the host.xml
> {code}
> /host=master/:write-attribute(name=directory-grouping,value=by-type)
> {code}
> - The value of "directory-grouping" is stored "in memory" so this change does not survive the host restart.

--
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

From issues at jboss.org  Thu Mar  6 21:53:33 2014
From: issues at jboss.org (Edison Melo (JIRA))
Date: Thu, 6 Mar 2014 21:53:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2608) MDB not receiving messages
	from JMS queue.
In-Reply-To: <JIRA.12526998.1386191721000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12526998.1386191721000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12526998.1386191721000.10756.1394160813400@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2608?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12950951#comment-12950951 ] 

Edison Melo commented on WFLY-2608:
-----------------------------------

If it helps, you can try to reproduce this advancing your machine clock.  I have a similar problem in EC2 with a virtual instance that "loose time" to fast, so NTP synchronization advance the system clock 20~30 seconds "in the future" and produce a very similar error. 
                
> MDB not receiving messages from JMS queue.
> ------------------------------------------
>
>                 Key: WFLY-2608
>                 URL: https://issues.jboss.org/browse/WFLY-2608
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JMS
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Corey Puffalt
>            Assignee: Jeff Mesnil
>
> We've run into a situation where MDBs stopped receiving messages from a JMS queue although the JMS queue itself was continuing to receive new messages from an EJB.  The forum thread referenced below has more background information but basically at some point we see the following in our server logs:
> {code}
> 00:50:28,915 WARN  [org.hornetq.core.protocol.core.impl.RemotingConnectionImpl] (hornetq-failure-check-thread) Connection failure has been detected: Did not receive data from invm:0. It is likely the client has exited or crashed without closing its connection, or the network between the server and client has failed. You also might have configured connection-ttl and client-failure-check-period incorrectly. Please check user manual for more information. The connection will now be closed. [code=3]
> 00:50:29,208 WARN  [org.hornetq.core.server.impl.ServerSessionImpl] (hornetq-failure-check-thread) Client connection failed, clearing up resources for session e33d5fe6-caf3-11e2-bc0f-3d92824f2653
> 00:50:29,235 WARN  [org.hornetq.core.server.impl.ServerSessionImpl] (hornetq-failure-check-thread) Cleared up resources for session e33d5fe6-caf3-11e2-bc0f-3d92824f2653
> [the above two messages are repeated a number of times in rapid succession...and then finally we get...]
> 00:50:30,187 WARN  [org.hornetq.jms.server.recovery.RecoveryDiscovery] (Thread-18647 (HornetQ-client-global-threads-2106576636)) Notified of connection failure in xa discovery, we will retry on the next recovery: HornetQException[errorCode=2 message=Channel disconnected]
>         at org.hornetq.core.client.impl.ClientSessionFactoryImpl.connectionDestroyed(ClientSessionFactoryImpl.java:381) [hornetq-core-2.2.16.Final.jar:2.2.16.Final (HQ_2_2_16_FINAL, 122)]
>         at org.hornetq.core.remoting.impl.invm.InVMConnector$Listener$1.run(InVMConnector.java:203) [hornetq-core-2.2.16.Final.jar:2.2.16.Final (HQ_2_2_16_FINAL, 122)]
>         at org.hornetq.utils.OrderedExecutorFactory$OrderedExecutor$1.run(OrderedExecutorFactory.java:100) [hornetq-core-2.2.16.Final.jar:2.2.16.Final (HQ_2_2_16_FINAL, 122)]
>         at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) [rt.jar:1.7.0_07]
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) [rt.jar:1.7.0_07]
>         at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_07]
> 00:50:29,240 WARN  [org.hornetq.jms.server.recovery.HornetQXAResourceWrapper] (Thread-18651 (HornetQ-client-global-threads-2106576636)) Notified of connection failure in xa recovery connectionFactory for provider ClientSessionFactoryImpl [serverLocator=ServerLocatorImpl [initialConnectors=[org-hornetq-core-remoting-impl-invm-InVMConnectorFactory?server-id=0], discoveryGroupConfiguration=null], connectorConfig=org-hornetq-core-remoting-impl-invm-InVMConnectorFactory?server-id=0, backupConfig=null] will attempt reconnect on next pass: HornetQException[errorCode=2 message=Channel disconnected]
>         at org.hornetq.core.client.impl.ClientSessionFactoryImpl.connectionDestroyed(ClientSessionFactoryImpl.java:381) [hornetq-core-2.2.16.Final.jar:2.2.16.Final (HQ_2_2_16_FINAL, 122)]
>         at org.hornetq.core.remoting.impl.invm.InVMConnector$Listener$1.run(InVMConnector.java:203) [hornetq-core-2.2.16.Final.jar:2.2.16.Final (HQ_2_2_16_FINAL, 122)]
>         at org.hornetq.utils.OrderedExecutorFactory$OrderedExecutor$1.run(OrderedExecutorFactory.java:100) [hornetq-core-2.2.16.Final.jar:2.2.16.Final (HQ_2_2_16_FINAL, 122)]
>         at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) [rt.jar:1.7.0_07]
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) [rt.jar:1.7.0_07]
>         at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_07]
> 00:50:38,633 INFO  [org.hornetq.jms.server.recovery.RecoveryDiscovery] (HornetQ Recovery Discovery Reinitialization) Starting RecoveryDiscovery on XARecoveryConfig [transportConfiguration = [org-hornetq-core-remoting-impl-invm-InVMConnectorFactory?server-id=0], discoveryConfiguration = null, username=null, password=null]
> 00:50:38,636 INFO  [org.hornetq.jms.server.recovery.RecoveryDiscovery] (HornetQ Recovery Discovery Reinitialization) RecoveryDiscovery started fine on XARecoveryConfig [transportConfiguration = [org-hornetq-core-remoting-impl-invm-InVMConnectorFactory?server-id=0], discoveryConfiguration = null, username=null, password=null]
> {code}
> After this our MDB never receives any further messages until a server restart.  HornetQ should be recovering from this situation (whatever the cause).

--
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

From issues at jboss.org  Thu Mar  6 21:55:34 2014
From: issues at jboss.org (Edison Melo (JIRA))
Date: Thu, 6 Mar 2014 21:55:34 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2608) MDB not receiving messages
	from JMS queue.
In-Reply-To: <JIRA.12526998.1386191721000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12526998.1386191721000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12526998.1386191721000.10759.1394160934004@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2608?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12950951#comment-12950951 ] 

Edison Melo edited comment on WFLY-2608 at 3/6/14 9:55 PM:
-----------------------------------------------------------

If it helps, you can try to reproduce this advancing your machine clock.  I have a similar problem in EC2 with a virtual instance that "loose time" to fast, so NTP synchronization advance the system clock 20~30 seconds "into the future" and produce a very similar error. 
                
      was (Author: roko98):
    If it helps, you can try to reproduce this advancing your machine clock.  I have a similar problem in EC2 with a virtual instance that "loose time" to fast, so NTP synchronization advance the system clock 20~30 seconds "in the future" and produce a very similar error. 
                  
> MDB not receiving messages from JMS queue.
> ------------------------------------------
>
>                 Key: WFLY-2608
>                 URL: https://issues.jboss.org/browse/WFLY-2608
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JMS
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Corey Puffalt
>            Assignee: Jeff Mesnil
>
> We've run into a situation where MDBs stopped receiving messages from a JMS queue although the JMS queue itself was continuing to receive new messages from an EJB.  The forum thread referenced below has more background information but basically at some point we see the following in our server logs:
> {code}
> 00:50:28,915 WARN  [org.hornetq.core.protocol.core.impl.RemotingConnectionImpl] (hornetq-failure-check-thread) Connection failure has been detected: Did not receive data from invm:0. It is likely the client has exited or crashed without closing its connection, or the network between the server and client has failed. You also might have configured connection-ttl and client-failure-check-period incorrectly. Please check user manual for more information. The connection will now be closed. [code=3]
> 00:50:29,208 WARN  [org.hornetq.core.server.impl.ServerSessionImpl] (hornetq-failure-check-thread) Client connection failed, clearing up resources for session e33d5fe6-caf3-11e2-bc0f-3d92824f2653
> 00:50:29,235 WARN  [org.hornetq.core.server.impl.ServerSessionImpl] (hornetq-failure-check-thread) Cleared up resources for session e33d5fe6-caf3-11e2-bc0f-3d92824f2653
> [the above two messages are repeated a number of times in rapid succession...and then finally we get...]
> 00:50:30,187 WARN  [org.hornetq.jms.server.recovery.RecoveryDiscovery] (Thread-18647 (HornetQ-client-global-threads-2106576636)) Notified of connection failure in xa discovery, we will retry on the next recovery: HornetQException[errorCode=2 message=Channel disconnected]
>         at org.hornetq.core.client.impl.ClientSessionFactoryImpl.connectionDestroyed(ClientSessionFactoryImpl.java:381) [hornetq-core-2.2.16.Final.jar:2.2.16.Final (HQ_2_2_16_FINAL, 122)]
>         at org.hornetq.core.remoting.impl.invm.InVMConnector$Listener$1.run(InVMConnector.java:203) [hornetq-core-2.2.16.Final.jar:2.2.16.Final (HQ_2_2_16_FINAL, 122)]
>         at org.hornetq.utils.OrderedExecutorFactory$OrderedExecutor$1.run(OrderedExecutorFactory.java:100) [hornetq-core-2.2.16.Final.jar:2.2.16.Final (HQ_2_2_16_FINAL, 122)]
>         at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) [rt.jar:1.7.0_07]
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) [rt.jar:1.7.0_07]
>         at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_07]
> 00:50:29,240 WARN  [org.hornetq.jms.server.recovery.HornetQXAResourceWrapper] (Thread-18651 (HornetQ-client-global-threads-2106576636)) Notified of connection failure in xa recovery connectionFactory for provider ClientSessionFactoryImpl [serverLocator=ServerLocatorImpl [initialConnectors=[org-hornetq-core-remoting-impl-invm-InVMConnectorFactory?server-id=0], discoveryGroupConfiguration=null], connectorConfig=org-hornetq-core-remoting-impl-invm-InVMConnectorFactory?server-id=0, backupConfig=null] will attempt reconnect on next pass: HornetQException[errorCode=2 message=Channel disconnected]
>         at org.hornetq.core.client.impl.ClientSessionFactoryImpl.connectionDestroyed(ClientSessionFactoryImpl.java:381) [hornetq-core-2.2.16.Final.jar:2.2.16.Final (HQ_2_2_16_FINAL, 122)]
>         at org.hornetq.core.remoting.impl.invm.InVMConnector$Listener$1.run(InVMConnector.java:203) [hornetq-core-2.2.16.Final.jar:2.2.16.Final (HQ_2_2_16_FINAL, 122)]
>         at org.hornetq.utils.OrderedExecutorFactory$OrderedExecutor$1.run(OrderedExecutorFactory.java:100) [hornetq-core-2.2.16.Final.jar:2.2.16.Final (HQ_2_2_16_FINAL, 122)]
>         at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) [rt.jar:1.7.0_07]
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) [rt.jar:1.7.0_07]
>         at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_07]
> 00:50:38,633 INFO  [org.hornetq.jms.server.recovery.RecoveryDiscovery] (HornetQ Recovery Discovery Reinitialization) Starting RecoveryDiscovery on XARecoveryConfig [transportConfiguration = [org-hornetq-core-remoting-impl-invm-InVMConnectorFactory?server-id=0], discoveryConfiguration = null, username=null, password=null]
> 00:50:38,636 INFO  [org.hornetq.jms.server.recovery.RecoveryDiscovery] (HornetQ Recovery Discovery Reinitialization) RecoveryDiscovery started fine on XARecoveryConfig [transportConfiguration = [org-hornetq-core-remoting-impl-invm-InVMConnectorFactory?server-id=0], discoveryConfiguration = null, username=null, password=null]
> {code}
> After this our MDB never receives any further messages until a server restart.  HornetQ should be recovering from this situation (whatever the cause).

--
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

From issues at jboss.org  Thu Mar  6 21:57:33 2014
From: issues at jboss.org (Edison Melo (JIRA))
Date: Thu, 6 Mar 2014 21:57:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2608) MDB not receiving messages
	from JMS queue.
In-Reply-To: <JIRA.12526998.1386191721000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12526998.1386191721000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12526998.1386191721000.10765.1394161053186@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2608?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12950951#comment-12950951 ] 

Edison Melo edited comment on WFLY-2608 at 3/6/14 9:55 PM:
-----------------------------------------------------------

If it helps, you can try to reproduce this advancing your machine clock.  I had a similar problem in EC2 with a virtual instance that "loose time" to fast, so NTP synchronization advance the system clock 20~30 seconds "into the future" and produce a very similar error. 
                
      was (Author: roko98):
    If it helps, you can try to reproduce this advancing your machine clock.  I have a similar problem in EC2 with a virtual instance that "loose time" to fast, so NTP synchronization advance the system clock 20~30 seconds "into the future" and produce a very similar error. 
                  
> MDB not receiving messages from JMS queue.
> ------------------------------------------
>
>                 Key: WFLY-2608
>                 URL: https://issues.jboss.org/browse/WFLY-2608
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JMS
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Corey Puffalt
>            Assignee: Jeff Mesnil
>
> We've run into a situation where MDBs stopped receiving messages from a JMS queue although the JMS queue itself was continuing to receive new messages from an EJB.  The forum thread referenced below has more background information but basically at some point we see the following in our server logs:
> {code}
> 00:50:28,915 WARN  [org.hornetq.core.protocol.core.impl.RemotingConnectionImpl] (hornetq-failure-check-thread) Connection failure has been detected: Did not receive data from invm:0. It is likely the client has exited or crashed without closing its connection, or the network between the server and client has failed. You also might have configured connection-ttl and client-failure-check-period incorrectly. Please check user manual for more information. The connection will now be closed. [code=3]
> 00:50:29,208 WARN  [org.hornetq.core.server.impl.ServerSessionImpl] (hornetq-failure-check-thread) Client connection failed, clearing up resources for session e33d5fe6-caf3-11e2-bc0f-3d92824f2653
> 00:50:29,235 WARN  [org.hornetq.core.server.impl.ServerSessionImpl] (hornetq-failure-check-thread) Cleared up resources for session e33d5fe6-caf3-11e2-bc0f-3d92824f2653
> [the above two messages are repeated a number of times in rapid succession...and then finally we get...]
> 00:50:30,187 WARN  [org.hornetq.jms.server.recovery.RecoveryDiscovery] (Thread-18647 (HornetQ-client-global-threads-2106576636)) Notified of connection failure in xa discovery, we will retry on the next recovery: HornetQException[errorCode=2 message=Channel disconnected]
>         at org.hornetq.core.client.impl.ClientSessionFactoryImpl.connectionDestroyed(ClientSessionFactoryImpl.java:381) [hornetq-core-2.2.16.Final.jar:2.2.16.Final (HQ_2_2_16_FINAL, 122)]
>         at org.hornetq.core.remoting.impl.invm.InVMConnector$Listener$1.run(InVMConnector.java:203) [hornetq-core-2.2.16.Final.jar:2.2.16.Final (HQ_2_2_16_FINAL, 122)]
>         at org.hornetq.utils.OrderedExecutorFactory$OrderedExecutor$1.run(OrderedExecutorFactory.java:100) [hornetq-core-2.2.16.Final.jar:2.2.16.Final (HQ_2_2_16_FINAL, 122)]
>         at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) [rt.jar:1.7.0_07]
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) [rt.jar:1.7.0_07]
>         at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_07]
> 00:50:29,240 WARN  [org.hornetq.jms.server.recovery.HornetQXAResourceWrapper] (Thread-18651 (HornetQ-client-global-threads-2106576636)) Notified of connection failure in xa recovery connectionFactory for provider ClientSessionFactoryImpl [serverLocator=ServerLocatorImpl [initialConnectors=[org-hornetq-core-remoting-impl-invm-InVMConnectorFactory?server-id=0], discoveryGroupConfiguration=null], connectorConfig=org-hornetq-core-remoting-impl-invm-InVMConnectorFactory?server-id=0, backupConfig=null] will attempt reconnect on next pass: HornetQException[errorCode=2 message=Channel disconnected]
>         at org.hornetq.core.client.impl.ClientSessionFactoryImpl.connectionDestroyed(ClientSessionFactoryImpl.java:381) [hornetq-core-2.2.16.Final.jar:2.2.16.Final (HQ_2_2_16_FINAL, 122)]
>         at org.hornetq.core.remoting.impl.invm.InVMConnector$Listener$1.run(InVMConnector.java:203) [hornetq-core-2.2.16.Final.jar:2.2.16.Final (HQ_2_2_16_FINAL, 122)]
>         at org.hornetq.utils.OrderedExecutorFactory$OrderedExecutor$1.run(OrderedExecutorFactory.java:100) [hornetq-core-2.2.16.Final.jar:2.2.16.Final (HQ_2_2_16_FINAL, 122)]
>         at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) [rt.jar:1.7.0_07]
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) [rt.jar:1.7.0_07]
>         at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_07]
> 00:50:38,633 INFO  [org.hornetq.jms.server.recovery.RecoveryDiscovery] (HornetQ Recovery Discovery Reinitialization) Starting RecoveryDiscovery on XARecoveryConfig [transportConfiguration = [org-hornetq-core-remoting-impl-invm-InVMConnectorFactory?server-id=0], discoveryConfiguration = null, username=null, password=null]
> 00:50:38,636 INFO  [org.hornetq.jms.server.recovery.RecoveryDiscovery] (HornetQ Recovery Discovery Reinitialization) RecoveryDiscovery started fine on XARecoveryConfig [transportConfiguration = [org-hornetq-core-remoting-impl-invm-InVMConnectorFactory?server-id=0], discoveryConfiguration = null, username=null, password=null]
> {code}
> After this our MDB never receives any further messages until a server restart.  HornetQ should be recovering from this situation (whatever the cause).

--
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

From issues at jboss.org  Thu Mar  6 22:38:33 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 6 Mar 2014 22:38:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3077) Convert command line IPv6 URL
 literals to address literals
In-Reply-To: <JIRA.12534346.1394155395000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534346.1394155395000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534346.1394155395000.10788.1394163513275@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-3077?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12950955#comment-12950955 ] 

RH Bugzilla Integration commented on WFLY-3077:
-----------------------------------------------

Brian Stansberry <brian.stansberry at redhat.com> changed the Status of [bug 1064771|https://bugzilla.redhat.com/show_bug.cgi?id=1064771] from NEW to POST
                
> Convert command line IPv6 URL literals to address literals
> ----------------------------------------------------------
>
>                 Key: WFLY-3077
>                 URL: https://issues.jboss.org/browse/WFLY-3077
>             Project: WildFly
>          Issue Type: Enhancement
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 8.0.0.Final
>            Reporter: Brian Stansberry
>            Assignee: Brian Stansberry
>            Priority: Minor
>             Fix For: 8.0.1.Final
>
>
> When people provide URL-style values like [::1] for command line args like -b, convert them to address values (i.e. strip the enclosing brackets.)

--
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

From issues at jboss.org  Fri Mar  7 00:56:33 2014
From: issues at jboss.org (Rituraj Sinha (JIRA))
Date: Fri, 7 Mar 2014 00:56:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3051) JMX connection to remote
 server-instances is not happening in wildfly 8.0.0.Final in domain mode
In-Reply-To: <JIRA.12533723.1393825342000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12533723.1393825342000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12533723.1393825342000.10865.1394171793607@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-3051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12950964#comment-12950964 ] 

Rituraj Sinha commented on WFLY-3051:
-------------------------------------

Hi Darran ..thanks for replying and looking into it ....
i am using the domain configuration in wildfly 8.0.0.Final....and also using HA profile to be specific...below are the steps i have performed so far 
1) created an application user and management user from the add-user script 
2) in domain.xml i have added the below line as <remoting-connector use-management-endpoint="false"/>
also updated my host.xml with in management and application realm  respectively...
                <server-identities>
                    <secret value="base64password"/>
                </server-identities>

3) downloaded wildfly 8.0.0.Final on my laptop  ....i have set the JAVA_HOME and JBOSS_HOME ...started jconsole from the path $JBOSS_HOME/bin/jconsole.bat
4) provided the service URL as service:jmx:http-remoting-jmx://remote_host_A:9990  and given management user_id and password  i am able to connect to the host controller running remotely ...
5) also on the  remote host i have 3 server instances running as server-one/two/three with a port offset of 100 that is there http ports are 8180 , 8280 and 8380
6) when i tried to connect to the server instance by providing the service urls as
service:jmx:http-remoting-jmx://remote_host_A:8180 or 8280/8380 ...i am not able to connect and i am getting an error as 
"secure connection failed . retry insecurely?
the connection to wildflyuser at service:jmx:http-remoting-jmx://remote_host_A:8180 could not be made using SSL
would you like to try without SSL?"
here wildflyuser is an application user i have created from the add-user.sh command...
even on trying insecurely it doesn't  connects ....

Just a note : I was able to connect with the above changes in jboss-7.2.0 but there was a remoting port there ...in wildfly8 this is not present and undertow is mutiplexing the ports as i know ...let me know if i am missing any configuration here ...as this one includes undertow as well...

Thanks
RIturaj
                
> JMX connection to remote server-instances is not happening in wildfly 8.0.0.Final in domain mode
> ------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-3051
>                 URL: https://issues.jboss.org/browse/WFLY-3051
>             Project: WildFly
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: JMX, Remoting
>    Affects Versions: 8.0.0.Final
>            Reporter: Rituraj Sinha
>            Assignee: Darran Lofthouse
>             Fix For: 8.0.1.Final
>
>
> i have gone through the below link for JMX subsystem for wildfly 8 as
> https://docs.jboss.org/author/display/WFLY8/JMX+subsystem+configuration
>  
> but unable to connect to server-instances running remotely ...i have posted my question there as well and pasting it here now ...
> can someone please give us the steps to configure JMX through jconsole...?
> changes done on the domain.xml are the same as stated above
> <subsystem xmlns="urn:jboss:domain:jmx:1.3">
>                 <expose-resolved-model/>
>                 <expose-expression-model/>
>                 <remoting-connector use-management-endpoint="false"/>
>             </subsystem>
> <subsystem xmlns="urn:jboss:domain:jmx:1.3">
>                 <expose-resolved-model/>
>                 <expose-expression-model/>
>                 <remoting-connector use-management-endpoint="false"/>
>             </subsystem>
> as per the jboss-as-jmx_1_3.xsd  its like
> <xs:attribute name="use-management-endpoint" type="xs:boolean" default="true" use="optional" >
>             <xs:annotation>
>                 <xs:documentation>
>                     If true then this connector will use the management endpoint, otherwise it will use the
>                     remoting subsystem endpoint.
>                 </xs:documentation>
>             </xs:annotation>
>         </xs:attribute>
> now if we are making it false then it should be using the remoting endpoint ...now remoting subsystem by default uses ApplicatoinRealm
> i have created application-user and password for the same but when i am trying to connect to remote server-instances its not connecting it....
> below is what i am able to connect to 
> service:jmx:http-remoting-jmx://remote_hostA:9990 --
> Unknown macro: {host A is where my domain_controller is running}
> how can i access the server-instances running on domain_controller
> Unknown macro: {there are three server_instanaces running on HostA with a port offset of 100 each}
> i am trying to connect with the below url as 
> service:jmx:http-remoting-jmx://lremote_hostA:8180
> let me know if something is missing from my side...
> Thanks

--
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

From issues at jboss.org  Fri Mar  7 01:04:33 2014
From: issues at jboss.org (=?UTF-8?Q?Ot=C3=A1vio_Garcia_=28JIRA=29?=)
Date: Fri, 7 Mar 2014 01:04:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3079) Wildfly JDK 8
In-Reply-To: <JIRA.12534354.1394172251696@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534354.1394172251696@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534354.1394172251696.10867.1394172273354@jira02.app.mwc.hst.phx2.redhat.com>

Ot?vio Garcia created WFLY-3079:
-----------------------------------

             Summary: Wildfly JDK 8
                 Key: WFLY-3079
                 URL: https://issues.jboss.org/browse/WFLY-3079
             Project: WildFly
          Issue Type: Bug
      Security Level: Public (Everyone can see)
            Reporter: Ot?vio Garcia


Steps to reproduce:

Download lastest JDK from https://jdk8.java.net/download.html. Bellow my java -version:

java version "1.8.0"
Java(TM) SE Runtime Environment (build 1.8.0-b129)
Java HotSpot(TM) 64-Bit Server VM (build 25.0-b69, mixed mode)

Wildfly version: 8.0.0-Final

When I start wildfly in standalone mode I got this error.

02:55:28,938 ERROR [org.xnio.listener] (XNIO-1 I/O-2) XNIO001007: A channel event listener threw an exception: java.lang.NoClassDefFoundError: Could not initialize class sun.security.ec.CurveDB
	at sun.security.ec.SunECEntries.putEntries(SunECEntries.java:72)
	at sun.security.ec.SunEC.<init>(SunEC.java:76)
	at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) [rt.jar:1.8.0]
	at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) [rt.jar:1.8.0]
	at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) [rt.jar:1.8.0]
	at java.lang.reflect.Constructor.newInstance(Constructor.java:408) [rt.jar:1.8.0]
	at java.lang.Class.newInstance(Class.java:433) [rt.jar:1.8.0]
	at sun.security.jca.ProviderConfig$2.run(ProviderConfig.java:221) [rt.jar:1.8.0]
	at sun.security.jca.ProviderConfig$2.run(ProviderConfig.java:206) [rt.jar:1.8.0]
	at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.8.0]
	at sun.security.jca.ProviderConfig.doLoadProvider(ProviderConfig.java:206) [rt.jar:1.8.0]
	at sun.security.jca.ProviderConfig.getProvider(ProviderConfig.java:187) [rt.jar:1.8.0]
	at sun.security.jca.ProviderList.loadAll(ProviderList.java:282) [rt.jar:1.8.0]
	at sun.security.jca.ProviderList.removeInvalid(ProviderList.java:299) [rt.jar:1.8.0]
	at sun.security.jca.Providers.getFullProviderList(Providers.java:173) [rt.jar:1.8.0]
	at java.security.Security.getProviders(Security.java:452) [rt.jar:1.8.0]
	at org.xnio.sasl.SaslUtils.getFactories(SaslUtils.java:121) [xnio-api-3.2.0.Final.jar:3.2.0.Final]
	at org.xnio.sasl.SaslUtils.getSaslServerFactories(SaslUtils.java:75) [xnio-api-3.2.0.Final.jar:3.2.0.Final]
	at org.jboss.remoting3.remote.ServerConnectionOpenListener$Initial.initialiseCapabilities(ServerConnectionOpenListener.java:165) [jboss-remoting-4.0.0.Final.jar:4.0.0.Final]
	at org.jboss.remoting3.remote.ServerConnectionOpenListener$Initial.sendCapabilities(ServerConnectionOpenListener.java:413) [jboss-remoting-4.0.0.Final.jar:4.0.0.Final]
	at org.jboss.remoting3.remote.ServerConnectionOpenListener$Initial.handleEvent(ServerConnectionOpenListener.java:260) [jboss-remoting-4.0.0.Final.jar:4.0.0.Final]
	at org.jboss.remoting3.remote.ServerConnectionOpenListener$Initial.handleEvent(ServerConnectionOpenListener.java:139) [jboss-remoting-4.0.0.Final.jar:4.0.0.Final]
	at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) [xnio-api-3.2.0.Final.jar:3.2.0.Final]
	at org.xnio.channels.TranslatingSuspendableChannel.handleReadable(TranslatingSuspendableChannel.java:196) [xnio-api-3.2.0.Final.jar:3.2.0.Final]
	at org.xnio.channels.TranslatingSuspendableChannel$1.handleEvent(TranslatingSuspendableChannel.java:110) [xnio-api-3.2.0.Final.jar:3.2.0.Final]
	at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) [xnio-api-3.2.0.Final.jar:3.2.0.Final]
	at org.xnio.ChannelListeners$DelegatingChannelListener.handleEvent(ChannelListeners.java:1092) [xnio-api-3.2.0.Final.jar:3.2.0.Final]
	at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) [xnio-api-3.2.0.Final.jar:3.2.0.Final]
	at org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66) [xnio-api-3.2.0.Final.jar:3.2.0.Final]
	at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:87)
	at org.xnio.nio.WorkerThread.run(WorkerThread.java:531)

02:55:34,171 ERROR [org.xnio.listener] (XNIO-1 I/O-1) XNIO001007: A channel event listener threw an exception: java.lang.NoClassDefFoundError: Could not initialize class sun.security.ec.CurveDB
	at sun.security.ec.SunECEntries.putEntries(SunECEntries.java:72)
	at sun.security.ec.SunEC.<init>(SunEC.java:76)
	at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) [rt.jar:1.8.0]
	at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) [rt.jar:1.8.0]
	at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) [rt.jar:1.8.0]
	at java.lang.reflect.Constructor.newInstance(Constructor.java:408) [rt.jar:1.8.0]
	at java.lang.Class.newInstance(Class.java:433) [rt.jar:1.8.0]
	at sun.security.jca.ProviderConfig$2.run(ProviderConfig.java:221) [rt.jar:1.8.0]
	at sun.security.jca.ProviderConfig$2.run(ProviderConfig.java:206) [rt.jar:1.8.0]
	at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.8.0]
	at sun.security.jca.ProviderConfig.doLoadProvider(ProviderConfig.java:206) [rt.jar:1.8.0]
	at sun.security.jca.ProviderConfig.getProvider(ProviderConfig.java:187) [rt.jar:1.8.0]
	at sun.security.jca.ProviderList.loadAll(ProviderList.java:282) [rt.jar:1.8.0]
	at sun.security.jca.ProviderList.removeInvalid(ProviderList.java:299) [rt.jar:1.8.0]
	at sun.security.jca.Providers.getFullProviderList(Providers.java:173) [rt.jar:1.8.0]
	at java.security.Security.getProviders(Security.java:452) [rt.jar:1.8.0]
	at org.xnio.sasl.SaslUtils.getFactories(SaslUtils.java:121) [xnio-api-3.2.0.Final.jar:3.2.0.Final]
	at org.xnio.sasl.SaslUtils.getSaslServerFactories(SaslUtils.java:75) [xnio-api-3.2.0.Final.jar:3.2.0.Final]
	at org.jboss.remoting3.remote.ServerConnectionOpenListener$Initial.initialiseCapabilities(ServerConnectionOpenListener.java:165) [jboss-remoting-4.0.0.Final.jar:4.0.0.Final]
	at org.jboss.remoting3.remote.ServerConnectionOpenListener$Initial.sendCapabilities(ServerConnectionOpenListener.java:413) [jboss-remoting-4.0.0.Final.jar:4.0.0.Final]
	at org.jboss.remoting3.remote.ServerConnectionOpenListener$Initial.handleEvent(ServerConnectionOpenListener.java:260) [jboss-remoting-4.0.0.Final.jar:4.0.0.Final]
	at org.jboss.remoting3.remote.ServerConnectionOpenListener$Initial.handleEvent(ServerConnectionOpenListener.java:139) [jboss-remoting-4.0.0.Final.jar:4.0.0.Final]
	at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) [xnio-api-3.2.0.Final.jar:3.2.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


From issues at jboss.org  Fri Mar  7 01:08:33 2014
From: issues at jboss.org (=?UTF-8?Q?Ot=C3=A1vio_Garcia_=28JIRA=29?=)
Date: Fri, 7 Mar 2014 01:08:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3079) Wildfly JDK 8
In-Reply-To: <JIRA.12534354.1394172251000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534354.1394172251000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534354.1394172251000.10869.1394172513154@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-3079?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ot?vio Garcia updated WFLY-3079:
--------------------------------

           Description: 
When I start wildfly in standalone mode I got this error.

02:55:28,938 ERROR [org.xnio.listener] (XNIO-1 I/O-2) XNIO001007: A channel event listener threw an exception: java.lang.NoClassDefFoundError: Could not initialize class sun.security.ec.CurveDB
	at sun.security.ec.SunECEntries.putEntries(SunECEntries.java:72)
	at sun.security.ec.SunEC.<init>(SunEC.java:76)
	at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) [rt.jar:1.8.0]
	at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) [rt.jar:1.8.0]
	at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) [rt.jar:1.8.0]
	at java.lang.reflect.Constructor.newInstance(Constructor.java:408) [rt.jar:1.8.0]
	at java.lang.Class.newInstance(Class.java:433) [rt.jar:1.8.0]
	at sun.security.jca.ProviderConfig$2.run(ProviderConfig.java:221) [rt.jar:1.8.0]
	at sun.security.jca.ProviderConfig$2.run(ProviderConfig.java:206) [rt.jar:1.8.0]
	at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.8.0]
	at sun.security.jca.ProviderConfig.doLoadProvider(ProviderConfig.java:206) [rt.jar:1.8.0]
	at sun.security.jca.ProviderConfig.getProvider(ProviderConfig.java:187) [rt.jar:1.8.0]
	at sun.security.jca.ProviderList.loadAll(ProviderList.java:282) [rt.jar:1.8.0]
	at sun.security.jca.ProviderList.removeInvalid(ProviderList.java:299) [rt.jar:1.8.0]
	at sun.security.jca.Providers.getFullProviderList(Providers.java:173) [rt.jar:1.8.0]
	at java.security.Security.getProviders(Security.java:452) [rt.jar:1.8.0]
	at org.xnio.sasl.SaslUtils.getFactories(SaslUtils.java:121) [xnio-api-3.2.0.Final.jar:3.2.0.Final]
	at org.xnio.sasl.SaslUtils.getSaslServerFactories(SaslUtils.java:75) [xnio-api-3.2.0.Final.jar:3.2.0.Final]
	at org.jboss.remoting3.remote.ServerConnectionOpenListener$Initial.initialiseCapabilities(ServerConnectionOpenListener.java:165) [jboss-remoting-4.0.0.Final.jar:4.0.0.Final]
	at org.jboss.remoting3.remote.ServerConnectionOpenListener$Initial.sendCapabilities(ServerConnectionOpenListener.java:413) [jboss-remoting-4.0.0.Final.jar:4.0.0.Final]
	at org.jboss.remoting3.remote.ServerConnectionOpenListener$Initial.handleEvent(ServerConnectionOpenListener.java:260) [jboss-remoting-4.0.0.Final.jar:4.0.0.Final]
	at org.jboss.remoting3.remote.ServerConnectionOpenListener$Initial.handleEvent(ServerConnectionOpenListener.java:139) [jboss-remoting-4.0.0.Final.jar:4.0.0.Final]
	at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) [xnio-api-3.2.0.Final.jar:3.2.0.Final]
	at org.xnio.channels.TranslatingSuspendableChannel.handleReadable(TranslatingSuspendableChannel.java:196) [xnio-api-3.2.0.Final.jar:3.2.0.Final]
	at org.xnio.channels.TranslatingSuspendableChannel$1.handleEvent(TranslatingSuspendableChannel.java:110) [xnio-api-3.2.0.Final.jar:3.2.0.Final]
	at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) [xnio-api-3.2.0.Final.jar:3.2.0.Final]
	at org.xnio.ChannelListeners$DelegatingChannelListener.handleEvent(ChannelListeners.java:1092) [xnio-api-3.2.0.Final.jar:3.2.0.Final]
	at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) [xnio-api-3.2.0.Final.jar:3.2.0.Final]
	at org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66) [xnio-api-3.2.0.Final.jar:3.2.0.Final]
	at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:87)
	at org.xnio.nio.WorkerThread.run(WorkerThread.java:531)

02:55:34,171 ERROR [org.xnio.listener] (XNIO-1 I/O-1) XNIO001007: A channel event listener threw an exception: java.lang.NoClassDefFoundError: Could not initialize class sun.security.ec.CurveDB
	at sun.security.ec.SunECEntries.putEntries(SunECEntries.java:72)
	at sun.security.ec.SunEC.<init>(SunEC.java:76)
	at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) [rt.jar:1.8.0]
	at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) [rt.jar:1.8.0]
	at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) [rt.jar:1.8.0]
	at java.lang.reflect.Constructor.newInstance(Constructor.java:408) [rt.jar:1.8.0]
	at java.lang.Class.newInstance(Class.java:433) [rt.jar:1.8.0]
	at sun.security.jca.ProviderConfig$2.run(ProviderConfig.java:221) [rt.jar:1.8.0]
	at sun.security.jca.ProviderConfig$2.run(ProviderConfig.java:206) [rt.jar:1.8.0]
	at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.8.0]
	at sun.security.jca.ProviderConfig.doLoadProvider(ProviderConfig.java:206) [rt.jar:1.8.0]
	at sun.security.jca.ProviderConfig.getProvider(ProviderConfig.java:187) [rt.jar:1.8.0]
	at sun.security.jca.ProviderList.loadAll(ProviderList.java:282) [rt.jar:1.8.0]
	at sun.security.jca.ProviderList.removeInvalid(ProviderList.java:299) [rt.jar:1.8.0]
	at sun.security.jca.Providers.getFullProviderList(Providers.java:173) [rt.jar:1.8.0]
	at java.security.Security.getProviders(Security.java:452) [rt.jar:1.8.0]
	at org.xnio.sasl.SaslUtils.getFactories(SaslUtils.java:121) [xnio-api-3.2.0.Final.jar:3.2.0.Final]
	at org.xnio.sasl.SaslUtils.getSaslServerFactories(SaslUtils.java:75) [xnio-api-3.2.0.Final.jar:3.2.0.Final]
	at org.jboss.remoting3.remote.ServerConnectionOpenListener$Initial.initialiseCapabilities(ServerConnectionOpenListener.java:165) [jboss-remoting-4.0.0.Final.jar:4.0.0.Final]
	at org.jboss.remoting3.remote.ServerConnectionOpenListener$Initial.sendCapabilities(ServerConnectionOpenListener.java:413) [jboss-remoting-4.0.0.Final.jar:4.0.0.Final]
	at org.jboss.remoting3.remote.ServerConnectionOpenListener$Initial.handleEvent(ServerConnectionOpenListener.java:260) [jboss-remoting-4.0.0.Final.jar:4.0.0.Final]
	at org.jboss.remoting3.remote.ServerConnectionOpenListener$Initial.handleEvent(ServerConnectionOpenListener.java:139) [jboss-remoting-4.0.0.Final.jar:4.0.0.Final]
	at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) [xnio-api-3.2.0.Final.jar:3.2.0.Final]


  was:
Steps to reproduce:

Download lastest JDK from https://jdk8.java.net/download.html. Bellow my java -version:

java version "1.8.0"
Java(TM) SE Runtime Environment (build 1.8.0-b129)
Java HotSpot(TM) 64-Bit Server VM (build 25.0-b69, mixed mode)

Wildfly version: 8.0.0-Final

When I start wildfly in standalone mode I got this error.

02:55:28,938 ERROR [org.xnio.listener] (XNIO-1 I/O-2) XNIO001007: A channel event listener threw an exception: java.lang.NoClassDefFoundError: Could not initialize class sun.security.ec.CurveDB
	at sun.security.ec.SunECEntries.putEntries(SunECEntries.java:72)
	at sun.security.ec.SunEC.<init>(SunEC.java:76)
	at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) [rt.jar:1.8.0]
	at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) [rt.jar:1.8.0]
	at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) [rt.jar:1.8.0]
	at java.lang.reflect.Constructor.newInstance(Constructor.java:408) [rt.jar:1.8.0]
	at java.lang.Class.newInstance(Class.java:433) [rt.jar:1.8.0]
	at sun.security.jca.ProviderConfig$2.run(ProviderConfig.java:221) [rt.jar:1.8.0]
	at sun.security.jca.ProviderConfig$2.run(ProviderConfig.java:206) [rt.jar:1.8.0]
	at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.8.0]
	at sun.security.jca.ProviderConfig.doLoadProvider(ProviderConfig.java:206) [rt.jar:1.8.0]
	at sun.security.jca.ProviderConfig.getProvider(ProviderConfig.java:187) [rt.jar:1.8.0]
	at sun.security.jca.ProviderList.loadAll(ProviderList.java:282) [rt.jar:1.8.0]
	at sun.security.jca.ProviderList.removeInvalid(ProviderList.java:299) [rt.jar:1.8.0]
	at sun.security.jca.Providers.getFullProviderList(Providers.java:173) [rt.jar:1.8.0]
	at java.security.Security.getProviders(Security.java:452) [rt.jar:1.8.0]
	at org.xnio.sasl.SaslUtils.getFactories(SaslUtils.java:121) [xnio-api-3.2.0.Final.jar:3.2.0.Final]
	at org.xnio.sasl.SaslUtils.getSaslServerFactories(SaslUtils.java:75) [xnio-api-3.2.0.Final.jar:3.2.0.Final]
	at org.jboss.remoting3.remote.ServerConnectionOpenListener$Initial.initialiseCapabilities(ServerConnectionOpenListener.java:165) [jboss-remoting-4.0.0.Final.jar:4.0.0.Final]
	at org.jboss.remoting3.remote.ServerConnectionOpenListener$Initial.sendCapabilities(ServerConnectionOpenListener.java:413) [jboss-remoting-4.0.0.Final.jar:4.0.0.Final]
	at org.jboss.remoting3.remote.ServerConnectionOpenListener$Initial.handleEvent(ServerConnectionOpenListener.java:260) [jboss-remoting-4.0.0.Final.jar:4.0.0.Final]
	at org.jboss.remoting3.remote.ServerConnectionOpenListener$Initial.handleEvent(ServerConnectionOpenListener.java:139) [jboss-remoting-4.0.0.Final.jar:4.0.0.Final]
	at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) [xnio-api-3.2.0.Final.jar:3.2.0.Final]
	at org.xnio.channels.TranslatingSuspendableChannel.handleReadable(TranslatingSuspendableChannel.java:196) [xnio-api-3.2.0.Final.jar:3.2.0.Final]
	at org.xnio.channels.TranslatingSuspendableChannel$1.handleEvent(TranslatingSuspendableChannel.java:110) [xnio-api-3.2.0.Final.jar:3.2.0.Final]
	at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) [xnio-api-3.2.0.Final.jar:3.2.0.Final]
	at org.xnio.ChannelListeners$DelegatingChannelListener.handleEvent(ChannelListeners.java:1092) [xnio-api-3.2.0.Final.jar:3.2.0.Final]
	at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) [xnio-api-3.2.0.Final.jar:3.2.0.Final]
	at org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66) [xnio-api-3.2.0.Final.jar:3.2.0.Final]
	at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:87)
	at org.xnio.nio.WorkerThread.run(WorkerThread.java:531)

02:55:34,171 ERROR [org.xnio.listener] (XNIO-1 I/O-1) XNIO001007: A channel event listener threw an exception: java.lang.NoClassDefFoundError: Could not initialize class sun.security.ec.CurveDB
	at sun.security.ec.SunECEntries.putEntries(SunECEntries.java:72)
	at sun.security.ec.SunEC.<init>(SunEC.java:76)
	at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) [rt.jar:1.8.0]
	at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) [rt.jar:1.8.0]
	at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) [rt.jar:1.8.0]
	at java.lang.reflect.Constructor.newInstance(Constructor.java:408) [rt.jar:1.8.0]
	at java.lang.Class.newInstance(Class.java:433) [rt.jar:1.8.0]
	at sun.security.jca.ProviderConfig$2.run(ProviderConfig.java:221) [rt.jar:1.8.0]
	at sun.security.jca.ProviderConfig$2.run(ProviderConfig.java:206) [rt.jar:1.8.0]
	at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.8.0]
	at sun.security.jca.ProviderConfig.doLoadProvider(ProviderConfig.java:206) [rt.jar:1.8.0]
	at sun.security.jca.ProviderConfig.getProvider(ProviderConfig.java:187) [rt.jar:1.8.0]
	at sun.security.jca.ProviderList.loadAll(ProviderList.java:282) [rt.jar:1.8.0]
	at sun.security.jca.ProviderList.removeInvalid(ProviderList.java:299) [rt.jar:1.8.0]
	at sun.security.jca.Providers.getFullProviderList(Providers.java:173) [rt.jar:1.8.0]
	at java.security.Security.getProviders(Security.java:452) [rt.jar:1.8.0]
	at org.xnio.sasl.SaslUtils.getFactories(SaslUtils.java:121) [xnio-api-3.2.0.Final.jar:3.2.0.Final]
	at org.xnio.sasl.SaslUtils.getSaslServerFactories(SaslUtils.java:75) [xnio-api-3.2.0.Final.jar:3.2.0.Final]
	at org.jboss.remoting3.remote.ServerConnectionOpenListener$Initial.initialiseCapabilities(ServerConnectionOpenListener.java:165) [jboss-remoting-4.0.0.Final.jar:4.0.0.Final]
	at org.jboss.remoting3.remote.ServerConnectionOpenListener$Initial.sendCapabilities(ServerConnectionOpenListener.java:413) [jboss-remoting-4.0.0.Final.jar:4.0.0.Final]
	at org.jboss.remoting3.remote.ServerConnectionOpenListener$Initial.handleEvent(ServerConnectionOpenListener.java:260) [jboss-remoting-4.0.0.Final.jar:4.0.0.Final]
	at org.jboss.remoting3.remote.ServerConnectionOpenListener$Initial.handleEvent(ServerConnectionOpenListener.java:139) [jboss-remoting-4.0.0.Final.jar:4.0.0.Final]
	at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) [xnio-api-3.2.0.Final.jar:3.2.0.Final]


    Steps to Reproduce: 
Download lastest JDK from https://jdk8.java.net/download.html. Bellow my java -version:

java version "1.8.0"
Java(TM) SE Runtime Environment (build 1.8.0-b129)
Java HotSpot(TM) 64-Bit Server VM (build 25.0-b69, mixed mode)

Wildfly version: 8.0.0-Final

                Labels: jdk8 wildfly  (was: )

    
> Wildfly JDK 8
> -------------
>
>                 Key: WFLY-3079
>                 URL: https://issues.jboss.org/browse/WFLY-3079
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Ot?vio Garcia
>              Labels: jdk8, wildfly
>
> When I start wildfly in standalone mode I got this error.
> 02:55:28,938 ERROR [org.xnio.listener] (XNIO-1 I/O-2) XNIO001007: A channel event listener threw an exception: java.lang.NoClassDefFoundError: Could not initialize class sun.security.ec.CurveDB
> 	at sun.security.ec.SunECEntries.putEntries(SunECEntries.java:72)
> 	at sun.security.ec.SunEC.<init>(SunEC.java:76)
> 	at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) [rt.jar:1.8.0]
> 	at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) [rt.jar:1.8.0]
> 	at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) [rt.jar:1.8.0]
> 	at java.lang.reflect.Constructor.newInstance(Constructor.java:408) [rt.jar:1.8.0]
> 	at java.lang.Class.newInstance(Class.java:433) [rt.jar:1.8.0]
> 	at sun.security.jca.ProviderConfig$2.run(ProviderConfig.java:221) [rt.jar:1.8.0]
> 	at sun.security.jca.ProviderConfig$2.run(ProviderConfig.java:206) [rt.jar:1.8.0]
> 	at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.8.0]
> 	at sun.security.jca.ProviderConfig.doLoadProvider(ProviderConfig.java:206) [rt.jar:1.8.0]
> 	at sun.security.jca.ProviderConfig.getProvider(ProviderConfig.java:187) [rt.jar:1.8.0]
> 	at sun.security.jca.ProviderList.loadAll(ProviderList.java:282) [rt.jar:1.8.0]
> 	at sun.security.jca.ProviderList.removeInvalid(ProviderList.java:299) [rt.jar:1.8.0]
> 	at sun.security.jca.Providers.getFullProviderList(Providers.java:173) [rt.jar:1.8.0]
> 	at java.security.Security.getProviders(Security.java:452) [rt.jar:1.8.0]
> 	at org.xnio.sasl.SaslUtils.getFactories(SaslUtils.java:121) [xnio-api-3.2.0.Final.jar:3.2.0.Final]
> 	at org.xnio.sasl.SaslUtils.getSaslServerFactories(SaslUtils.java:75) [xnio-api-3.2.0.Final.jar:3.2.0.Final]
> 	at org.jboss.remoting3.remote.ServerConnectionOpenListener$Initial.initialiseCapabilities(ServerConnectionOpenListener.java:165) [jboss-remoting-4.0.0.Final.jar:4.0.0.Final]
> 	at org.jboss.remoting3.remote.ServerConnectionOpenListener$Initial.sendCapabilities(ServerConnectionOpenListener.java:413) [jboss-remoting-4.0.0.Final.jar:4.0.0.Final]
> 	at org.jboss.remoting3.remote.ServerConnectionOpenListener$Initial.handleEvent(ServerConnectionOpenListener.java:260) [jboss-remoting-4.0.0.Final.jar:4.0.0.Final]
> 	at org.jboss.remoting3.remote.ServerConnectionOpenListener$Initial.handleEvent(ServerConnectionOpenListener.java:139) [jboss-remoting-4.0.0.Final.jar:4.0.0.Final]
> 	at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) [xnio-api-3.2.0.Final.jar:3.2.0.Final]
> 	at org.xnio.channels.TranslatingSuspendableChannel.handleReadable(TranslatingSuspendableChannel.java:196) [xnio-api-3.2.0.Final.jar:3.2.0.Final]
> 	at org.xnio.channels.TranslatingSuspendableChannel$1.handleEvent(TranslatingSuspendableChannel.java:110) [xnio-api-3.2.0.Final.jar:3.2.0.Final]
> 	at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) [xnio-api-3.2.0.Final.jar:3.2.0.Final]
> 	at org.xnio.ChannelListeners$DelegatingChannelListener.handleEvent(ChannelListeners.java:1092) [xnio-api-3.2.0.Final.jar:3.2.0.Final]
> 	at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) [xnio-api-3.2.0.Final.jar:3.2.0.Final]
> 	at org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66) [xnio-api-3.2.0.Final.jar:3.2.0.Final]
> 	at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:87)
> 	at org.xnio.nio.WorkerThread.run(WorkerThread.java:531)
> 02:55:34,171 ERROR [org.xnio.listener] (XNIO-1 I/O-1) XNIO001007: A channel event listener threw an exception: java.lang.NoClassDefFoundError: Could not initialize class sun.security.ec.CurveDB
> 	at sun.security.ec.SunECEntries.putEntries(SunECEntries.java:72)
> 	at sun.security.ec.SunEC.<init>(SunEC.java:76)
> 	at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) [rt.jar:1.8.0]
> 	at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) [rt.jar:1.8.0]
> 	at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) [rt.jar:1.8.0]
> 	at java.lang.reflect.Constructor.newInstance(Constructor.java:408) [rt.jar:1.8.0]
> 	at java.lang.Class.newInstance(Class.java:433) [rt.jar:1.8.0]
> 	at sun.security.jca.ProviderConfig$2.run(ProviderConfig.java:221) [rt.jar:1.8.0]
> 	at sun.security.jca.ProviderConfig$2.run(ProviderConfig.java:206) [rt.jar:1.8.0]
> 	at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.8.0]
> 	at sun.security.jca.ProviderConfig.doLoadProvider(ProviderConfig.java:206) [rt.jar:1.8.0]
> 	at sun.security.jca.ProviderConfig.getProvider(ProviderConfig.java:187) [rt.jar:1.8.0]
> 	at sun.security.jca.ProviderList.loadAll(ProviderList.java:282) [rt.jar:1.8.0]
> 	at sun.security.jca.ProviderList.removeInvalid(ProviderList.java:299) [rt.jar:1.8.0]
> 	at sun.security.jca.Providers.getFullProviderList(Providers.java:173) [rt.jar:1.8.0]
> 	at java.security.Security.getProviders(Security.java:452) [rt.jar:1.8.0]
> 	at org.xnio.sasl.SaslUtils.getFactories(SaslUtils.java:121) [xnio-api-3.2.0.Final.jar:3.2.0.Final]
> 	at org.xnio.sasl.SaslUtils.getSaslServerFactories(SaslUtils.java:75) [xnio-api-3.2.0.Final.jar:3.2.0.Final]
> 	at org.jboss.remoting3.remote.ServerConnectionOpenListener$Initial.initialiseCapabilities(ServerConnectionOpenListener.java:165) [jboss-remoting-4.0.0.Final.jar:4.0.0.Final]
> 	at org.jboss.remoting3.remote.ServerConnectionOpenListener$Initial.sendCapabilities(ServerConnectionOpenListener.java:413) [jboss-remoting-4.0.0.Final.jar:4.0.0.Final]
> 	at org.jboss.remoting3.remote.ServerConnectionOpenListener$Initial.handleEvent(ServerConnectionOpenListener.java:260) [jboss-remoting-4.0.0.Final.jar:4.0.0.Final]
> 	at org.jboss.remoting3.remote.ServerConnectionOpenListener$Initial.handleEvent(ServerConnectionOpenListener.java:139) [jboss-remoting-4.0.0.Final.jar:4.0.0.Final]
> 	at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) [xnio-api-3.2.0.Final.jar:3.2.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


From issues at jboss.org  Fri Mar  7 01:57:33 2014
From: issues at jboss.org (Rituraj Sinha (JIRA))
Date: Fri, 7 Mar 2014 01:57:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3051) JMX connection to remote
 server-instances is not happening in wildfly 8.0.0.Final in domain mode
In-Reply-To: <JIRA.12533723.1393825342000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12533723.1393825342000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12533723.1393825342000.10909.1394175453652@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-3051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12950964#comment-12950964 ] 

Rituraj Sinha edited comment on WFLY-3051 at 3/7/14 1:56 AM:
-------------------------------------------------------------

Hi Darran ..thanks for replying and looking into it ....
i am using the domain configuration in wildfly 8.0.0.Final....and also using HA profile to be specific...below are the steps i have performed so far 
1) created an application user and management user from the add-user script 
2) in domain.xml i have added the below line as <remoting-connector use-management-endpoint="false"/> in the jmx subsystem
also updated my host.xml with in management and application realm  respectively...
                <server-identities>
                    <secret value="base64password"/>
                </server-identities>

3) downloaded wildfly 8.0.0.Final on my laptop  ....i have set the JAVA_HOME and JBOSS_HOME ...started jconsole from the path $JBOSS_HOME/bin/jconsole.bat
4) provided the service URL as service:jmx:http-remoting-jmx://remote_host_A:9990  and given management user_id and password  i am able to connect to the host controller running remotely ...
5) also on the  remote host i have 3 server instances running as server-one/two/three with a port offset of 100 that is there http ports are 8180 , 8280 and 8380
6) when i tried to connect to the server instance by providing the service urls as
service:jmx:http-remoting-jmx://remote_host_A:8180 or 8280/8380 ...i am not able to connect and i am getting an error as 
"secure connection failed . retry insecurely?
the connection to wildflyuser at service:jmx:http-remoting-jmx://remote_host_A:8180 could not be made using SSL
would you like to try without SSL?"
here wildflyuser is an application user i have created from the add-user.sh command...
even on trying insecurely it doesn't  connects ....

Just a note : I was able to connect with the above changes in jboss-7.2.0 but there was a remoting port there ...in wildfly8 this is not present and undertow is mutiplexing the ports as i know ...let me know if i am missing any configuration here ...as this one includes undertow as well...

Thanks
RIturaj
                
      was (Author: rituraj):
    Hi Darran ..thanks for replying and looking into it ....
i am using the domain configuration in wildfly 8.0.0.Final....and also using HA profile to be specific...below are the steps i have performed so far 
1) created an application user and management user from the add-user script 
2) in domain.xml i have added the below line as <remoting-connector use-management-endpoint="false"/>
also updated my host.xml with in management and application realm  respectively...
                <server-identities>
                    <secret value="base64password"/>
                </server-identities>

3) downloaded wildfly 8.0.0.Final on my laptop  ....i have set the JAVA_HOME and JBOSS_HOME ...started jconsole from the path $JBOSS_HOME/bin/jconsole.bat
4) provided the service URL as service:jmx:http-remoting-jmx://remote_host_A:9990  and given management user_id and password  i am able to connect to the host controller running remotely ...
5) also on the  remote host i have 3 server instances running as server-one/two/three with a port offset of 100 that is there http ports are 8180 , 8280 and 8380
6) when i tried to connect to the server instance by providing the service urls as
service:jmx:http-remoting-jmx://remote_host_A:8180 or 8280/8380 ...i am not able to connect and i am getting an error as 
"secure connection failed . retry insecurely?
the connection to wildflyuser at service:jmx:http-remoting-jmx://remote_host_A:8180 could not be made using SSL
would you like to try without SSL?"
here wildflyuser is an application user i have created from the add-user.sh command...
even on trying insecurely it doesn't  connects ....

Just a note : I was able to connect with the above changes in jboss-7.2.0 but there was a remoting port there ...in wildfly8 this is not present and undertow is mutiplexing the ports as i know ...let me know if i am missing any configuration here ...as this one includes undertow as well...

Thanks
RIturaj
                  
> JMX connection to remote server-instances is not happening in wildfly 8.0.0.Final in domain mode
> ------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-3051
>                 URL: https://issues.jboss.org/browse/WFLY-3051
>             Project: WildFly
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: JMX, Remoting
>    Affects Versions: 8.0.0.Final
>            Reporter: Rituraj Sinha
>            Assignee: Darran Lofthouse
>             Fix For: 8.0.1.Final
>
>
> i have gone through the below link for JMX subsystem for wildfly 8 as
> https://docs.jboss.org/author/display/WFLY8/JMX+subsystem+configuration
>  
> but unable to connect to server-instances running remotely ...i have posted my question there as well and pasting it here now ...
> can someone please give us the steps to configure JMX through jconsole...?
> changes done on the domain.xml are the same as stated above
> <subsystem xmlns="urn:jboss:domain:jmx:1.3">
>                 <expose-resolved-model/>
>                 <expose-expression-model/>
>                 <remoting-connector use-management-endpoint="false"/>
>             </subsystem>
> <subsystem xmlns="urn:jboss:domain:jmx:1.3">
>                 <expose-resolved-model/>
>                 <expose-expression-model/>
>                 <remoting-connector use-management-endpoint="false"/>
>             </subsystem>
> as per the jboss-as-jmx_1_3.xsd  its like
> <xs:attribute name="use-management-endpoint" type="xs:boolean" default="true" use="optional" >
>             <xs:annotation>
>                 <xs:documentation>
>                     If true then this connector will use the management endpoint, otherwise it will use the
>                     remoting subsystem endpoint.
>                 </xs:documentation>
>             </xs:annotation>
>         </xs:attribute>
> now if we are making it false then it should be using the remoting endpoint ...now remoting subsystem by default uses ApplicatoinRealm
> i have created application-user and password for the same but when i am trying to connect to remote server-instances its not connecting it....
> below is what i am able to connect to 
> service:jmx:http-remoting-jmx://remote_hostA:9990 --
> Unknown macro: {host A is where my domain_controller is running}
> how can i access the server-instances running on domain_controller
> Unknown macro: {there are three server_instanaces running on HostA with a port offset of 100 each}
> i am trying to connect with the below url as 
> service:jmx:http-remoting-jmx://lremote_hostA:8180
> let me know if something is missing from my side...
> Thanks

--
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

From issues at jboss.org  Fri Mar  7 01:57:33 2014
From: issues at jboss.org (Rituraj Sinha (JIRA))
Date: Fri, 7 Mar 2014 01:57:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3051) JMX connection to remote
 server-instances is not happening in wildfly 8.0.0.Final in domain mode
In-Reply-To: <JIRA.12533723.1393825342000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12533723.1393825342000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12533723.1393825342000.10911.1394175453772@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-3051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12950964#comment-12950964 ] 

Rituraj Sinha edited comment on WFLY-3051 at 3/7/14 1:56 AM:
-------------------------------------------------------------

Hi Darran ..thanks for replying and looking into it ....
i am using the domain configuration in wildfly 8.0.0.Final....and also using HA profile to be specific...below are the steps i have performed so far 
1) created an application user and management user from the add-user script 
2) in domain.xml i have added the below line as <remoting-connector use-management-endpoint="false"/> in the jmx subsystem
also updated my host.xml with the below in management and application realm  respectively...
                <server-identities>
                    <secret value="base64password"/>
                </server-identities>

3) downloaded wildfly 8.0.0.Final on my laptop  ....i have set the JAVA_HOME and JBOSS_HOME ...started jconsole from the path $JBOSS_HOME/bin/jconsole.bat
4) provided the service URL as service:jmx:http-remoting-jmx://remote_host_A:9990  and given management user_id and password  i am able to connect to the host controller running remotely ...
5) also on the  remote host i have 3 server instances running as server-one/two/three with a port offset of 100 that is there http ports are 8180 , 8280 and 8380
6) when i tried to connect to the server instance by providing the service urls as
service:jmx:http-remoting-jmx://remote_host_A:8180 or 8280/8380 ...i am not able to connect and i am getting an error as 
"secure connection failed . retry insecurely?
the connection to wildflyuser at service:jmx:http-remoting-jmx://remote_host_A:8180 could not be made using SSL
would you like to try without SSL?"
here wildflyuser is an application user i have created from the add-user.sh command...
even on trying insecurely it doesn't  connects ....

Just a note : I was able to connect with the above changes in jboss-7.2.0 but there was a remoting port there ...in wildfly8 this is not present and undertow is mutiplexing the ports as i know ...let me know if i am missing any configuration here ...as this one includes undertow as well...

Thanks
RIturaj
                
      was (Author: rituraj):
    Hi Darran ..thanks for replying and looking into it ....
i am using the domain configuration in wildfly 8.0.0.Final....and also using HA profile to be specific...below are the steps i have performed so far 
1) created an application user and management user from the add-user script 
2) in domain.xml i have added the below line as <remoting-connector use-management-endpoint="false"/> in the jmx subsystem
also updated my host.xml with in management and application realm  respectively...
                <server-identities>
                    <secret value="base64password"/>
                </server-identities>

3) downloaded wildfly 8.0.0.Final on my laptop  ....i have set the JAVA_HOME and JBOSS_HOME ...started jconsole from the path $JBOSS_HOME/bin/jconsole.bat
4) provided the service URL as service:jmx:http-remoting-jmx://remote_host_A:9990  and given management user_id and password  i am able to connect to the host controller running remotely ...
5) also on the  remote host i have 3 server instances running as server-one/two/three with a port offset of 100 that is there http ports are 8180 , 8280 and 8380
6) when i tried to connect to the server instance by providing the service urls as
service:jmx:http-remoting-jmx://remote_host_A:8180 or 8280/8380 ...i am not able to connect and i am getting an error as 
"secure connection failed . retry insecurely?
the connection to wildflyuser at service:jmx:http-remoting-jmx://remote_host_A:8180 could not be made using SSL
would you like to try without SSL?"
here wildflyuser is an application user i have created from the add-user.sh command...
even on trying insecurely it doesn't  connects ....

Just a note : I was able to connect with the above changes in jboss-7.2.0 but there was a remoting port there ...in wildfly8 this is not present and undertow is mutiplexing the ports as i know ...let me know if i am missing any configuration here ...as this one includes undertow as well...

Thanks
RIturaj
                  
> JMX connection to remote server-instances is not happening in wildfly 8.0.0.Final in domain mode
> ------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-3051
>                 URL: https://issues.jboss.org/browse/WFLY-3051
>             Project: WildFly
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: JMX, Remoting
>    Affects Versions: 8.0.0.Final
>            Reporter: Rituraj Sinha
>            Assignee: Darran Lofthouse
>             Fix For: 8.0.1.Final
>
>
> i have gone through the below link for JMX subsystem for wildfly 8 as
> https://docs.jboss.org/author/display/WFLY8/JMX+subsystem+configuration
>  
> but unable to connect to server-instances running remotely ...i have posted my question there as well and pasting it here now ...
> can someone please give us the steps to configure JMX through jconsole...?
> changes done on the domain.xml are the same as stated above
> <subsystem xmlns="urn:jboss:domain:jmx:1.3">
>                 <expose-resolved-model/>
>                 <expose-expression-model/>
>                 <remoting-connector use-management-endpoint="false"/>
>             </subsystem>
> <subsystem xmlns="urn:jboss:domain:jmx:1.3">
>                 <expose-resolved-model/>
>                 <expose-expression-model/>
>                 <remoting-connector use-management-endpoint="false"/>
>             </subsystem>
> as per the jboss-as-jmx_1_3.xsd  its like
> <xs:attribute name="use-management-endpoint" type="xs:boolean" default="true" use="optional" >
>             <xs:annotation>
>                 <xs:documentation>
>                     If true then this connector will use the management endpoint, otherwise it will use the
>                     remoting subsystem endpoint.
>                 </xs:documentation>
>             </xs:annotation>
>         </xs:attribute>
> now if we are making it false then it should be using the remoting endpoint ...now remoting subsystem by default uses ApplicatoinRealm
> i have created application-user and password for the same but when i am trying to connect to remote server-instances its not connecting it....
> below is what i am able to connect to 
> service:jmx:http-remoting-jmx://remote_hostA:9990 --
> Unknown macro: {host A is where my domain_controller is running}
> how can i access the server-instances running on domain_controller
> Unknown macro: {there are three server_instanaces running on HostA with a port offset of 100 each}
> i am trying to connect with the below url as 
> service:jmx:http-remoting-jmx://lremote_hostA:8180
> let me know if something is missing from my side...
> Thanks

--
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

From issues at jboss.org  Fri Mar  7 02:01:34 2014
From: issues at jboss.org (Rituraj Sinha (JIRA))
Date: Fri, 7 Mar 2014 02:01:34 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3051) JMX connection to remote
 server-instances is not happening in wildfly 8.0.0.Final in domain mode
In-Reply-To: <JIRA.12533723.1393825342000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12533723.1393825342000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12533723.1393825342000.10933.1394175694821@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-3051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12950964#comment-12950964 ] 

Rituraj Sinha edited comment on WFLY-3051 at 3/7/14 2:01 AM:
-------------------------------------------------------------

Hi Darran ..thanks for replying and looking into it ....
i am using the domain configuration in wildfly 8.0.0.Final....and also using HA profile to be specific...below are the steps i have performed so far 
1) created an application user and management user from the add-user script 
2) in domain.xml i have added the below line as <remoting-connector use-management-endpoint="false"/> in the jmx subsystem
also updated my host.xml with the below in management and application realm  respectively...
                <server-identities>
                    <secret value="base64password"/>
                </server-identities>

3) downloaded wildfly 8.0.0.Final on my laptop  ....i have set the JAVA_HOME and JBOSS_HOME ...started jconsole from the path $JBOSS_HOME/bin/jconsole.bat
4) provided the service URL as service:jmx:http-remoting-jmx://remote_host_A:9990  and given management user_id and password  i am able to connect to the host controller running remotely ...
5) also on the  remote host i have 3 server instances running as server-one/two/three with a port offset of 100 that is there http ports are 8180 , 8280 and 8380
6) when i tried to connect to the server instance by providing the service urls as
service:jmx:http-remoting-jmx://remote_host_A:8180 or 8280/8380 ...i am not able to connect
and i have provided the application user and password here...
 and i am getting an error as 
"secure connection failed . retry insecurely?
the connection to wildflyuser at service:jmx:http-remoting-jmx://remote_host_A:8180 could not be made using SSL
would you like to try without SSL?"
here wildflyuser is an application user i have created from the add-user.sh command...
even on trying insecurely it doesn't  connects ....

Just a note : I was able to connect with the above changes in jboss-7.2.0 but there was a remoting port there ...in wildfly8 this is not present and undertow is mutiplexing the ports as i know ...let me know if i am missing any configuration here ...as this one includes undertow as well...

Thanks
RIturaj
                
      was (Author: rituraj):
    Hi Darran ..thanks for replying and looking into it ....
i am using the domain configuration in wildfly 8.0.0.Final....and also using HA profile to be specific...below are the steps i have performed so far 
1) created an application user and management user from the add-user script 
2) in domain.xml i have added the below line as <remoting-connector use-management-endpoint="false"/> in the jmx subsystem
also updated my host.xml with the below in management and application realm  respectively...
                <server-identities>
                    <secret value="base64password"/>
                </server-identities>

3) downloaded wildfly 8.0.0.Final on my laptop  ....i have set the JAVA_HOME and JBOSS_HOME ...started jconsole from the path $JBOSS_HOME/bin/jconsole.bat
4) provided the service URL as service:jmx:http-remoting-jmx://remote_host_A:9990  and given management user_id and password  i am able to connect to the host controller running remotely ...
5) also on the  remote host i have 3 server instances running as server-one/two/three with a port offset of 100 that is there http ports are 8180 , 8280 and 8380
6) when i tried to connect to the server instance by providing the service urls as
service:jmx:http-remoting-jmx://remote_host_A:8180 or 8280/8380 ...i am not able to connect and i am getting an error as 
"secure connection failed . retry insecurely?
the connection to wildflyuser at service:jmx:http-remoting-jmx://remote_host_A:8180 could not be made using SSL
would you like to try without SSL?"
here wildflyuser is an application user i have created from the add-user.sh command...
even on trying insecurely it doesn't  connects ....

Just a note : I was able to connect with the above changes in jboss-7.2.0 but there was a remoting port there ...in wildfly8 this is not present and undertow is mutiplexing the ports as i know ...let me know if i am missing any configuration here ...as this one includes undertow as well...

Thanks
RIturaj
                  
> JMX connection to remote server-instances is not happening in wildfly 8.0.0.Final in domain mode
> ------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-3051
>                 URL: https://issues.jboss.org/browse/WFLY-3051
>             Project: WildFly
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: JMX, Remoting
>    Affects Versions: 8.0.0.Final
>            Reporter: Rituraj Sinha
>            Assignee: Darran Lofthouse
>             Fix For: 8.0.1.Final
>
>
> i have gone through the below link for JMX subsystem for wildfly 8 as
> https://docs.jboss.org/author/display/WFLY8/JMX+subsystem+configuration
>  
> but unable to connect to server-instances running remotely ...i have posted my question there as well and pasting it here now ...
> can someone please give us the steps to configure JMX through jconsole...?
> changes done on the domain.xml are the same as stated above
> <subsystem xmlns="urn:jboss:domain:jmx:1.3">
>                 <expose-resolved-model/>
>                 <expose-expression-model/>
>                 <remoting-connector use-management-endpoint="false"/>
>             </subsystem>
> <subsystem xmlns="urn:jboss:domain:jmx:1.3">
>                 <expose-resolved-model/>
>                 <expose-expression-model/>
>                 <remoting-connector use-management-endpoint="false"/>
>             </subsystem>
> as per the jboss-as-jmx_1_3.xsd  its like
> <xs:attribute name="use-management-endpoint" type="xs:boolean" default="true" use="optional" >
>             <xs:annotation>
>                 <xs:documentation>
>                     If true then this connector will use the management endpoint, otherwise it will use the
>                     remoting subsystem endpoint.
>                 </xs:documentation>
>             </xs:annotation>
>         </xs:attribute>
> now if we are making it false then it should be using the remoting endpoint ...now remoting subsystem by default uses ApplicatoinRealm
> i have created application-user and password for the same but when i am trying to connect to remote server-instances its not connecting it....
> below is what i am able to connect to 
> service:jmx:http-remoting-jmx://remote_hostA:9990 --
> Unknown macro: {host A is where my domain_controller is running}
> how can i access the server-instances running on domain_controller
> Unknown macro: {there are three server_instanaces running on HostA with a port offset of 100 each}
> i am trying to connect with the below url as 
> service:jmx:http-remoting-jmx://lremote_hostA:8180
> let me know if something is missing from my side...
> Thanks

--
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

From issues at jboss.org  Fri Mar  7 02:13:33 2014
From: issues at jboss.org (Alexey Loubyansky (JIRA))
Date: Fri, 7 Mar 2014 02:13:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3078) directory-grouping
 configuration is not getting persisted via CLI when no servers defined
In-Reply-To: <JIRA.12534347.1394159920000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534347.1394159920000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534347.1394159920000.10939.1394176413762@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-3078?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Alexey Loubyansky updated WFLY-3078:
------------------------------------

    Component/s: Domain Management
                     (was: CLI)

    
> directory-grouping configuration is not getting persisted via CLI when no servers defined
> -----------------------------------------------------------------------------------------
>
>                 Key: WFLY-3078
>                 URL: https://issues.jboss.org/browse/WFLY-3078
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>    Affects Versions: 8.0.0.Final
>         Environment: All Operating System
>            Reporter: Jay Kumar SenSharma
>            Assignee: Alexey Loubyansky
>
> - If none of the servers are defined in "host.xml" (means <servers></servers> empty tag is present) and if the user tries to run the following CLI command to change the "directory-grouping" to  "by-type"  then the value is not persisted in the configuration file (host.xml) and the <servers></servers>  tag is also removed from the host.xml
> {code}
> /host=master/:write-attribute(name=directory-grouping,value=by-type)
> {code}
> - The value of "directory-grouping" is stored "in memory" so this change does not survive the host restart.

--
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

From issues at jboss.org  Fri Mar  7 02:13:34 2014
From: issues at jboss.org (Alexey Loubyansky (JIRA))
Date: Fri, 7 Mar 2014 02:13:34 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3078) directory-grouping
 configuration is not getting persisted via CLI when no servers defined
In-Reply-To: <JIRA.12534347.1394159920000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534347.1394159920000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534347.1394159920000.10950.1394176414322@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-3078?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Alexey Loubyansky updated WFLY-3078:
------------------------------------

    Assignee: Brian Stansberry  (was: Alexey Loubyansky)

    
> directory-grouping configuration is not getting persisted via CLI when no servers defined
> -----------------------------------------------------------------------------------------
>
>                 Key: WFLY-3078
>                 URL: https://issues.jboss.org/browse/WFLY-3078
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>    Affects Versions: 8.0.0.Final
>         Environment: All Operating System
>            Reporter: Jay Kumar SenSharma
>            Assignee: Brian Stansberry
>
> - If none of the servers are defined in "host.xml" (means <servers></servers> empty tag is present) and if the user tries to run the following CLI command to change the "directory-grouping" to  "by-type"  then the value is not persisted in the configuration file (host.xml) and the <servers></servers>  tag is also removed from the host.xml
> {code}
> /host=master/:write-attribute(name=directory-grouping,value=by-type)
> {code}
> - The value of "directory-grouping" is stored "in memory" so this change does not survive the host restart.

--
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

From issues at jboss.org  Fri Mar  7 02:15:35 2014
From: issues at jboss.org (Rituraj Sinha (JIRA))
Date: Fri, 7 Mar 2014 02:15:35 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3051) JMX connection to remote
 server-instances is not happening in wildfly 8.0.0.Final in domain mode
In-Reply-To: <JIRA.12533723.1393825342000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12533723.1393825342000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12533723.1393825342000.10966.1394176535488@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-3051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12950964#comment-12950964 ] 

Rituraj Sinha edited comment on WFLY-3051 at 3/7/14 2:15 AM:
-------------------------------------------------------------

Hi Darran ..thanks for replying and looking into it ....
i am using the domain configuration in wildfly 8.0.0.Final....and also using HA profile to be specific...below are the steps i have performed so far 
1) created an application user and management user from the add-user script 
2) in domain.xml i have added the below line as <remoting-connector use-management-endpoint="false"/> in the jmx subsystem
also updated my host.xml with the below in management and application realm  respectively...
                <server-identities>
                    <secret value="base64password"/>
                </server-identities>

3) downloaded wildfly 8.0.0.Final on my laptop  ....i have set the JAVA_HOME and JBOSS_HOME ...started jconsole from the path $JBOSS_HOME/bin/jconsole.bat
4) provided the service URL as service:jmx:http-remoting-jmx://remote_host_A:9990  and given management user_id and password  i am able to connect to the host controller running remote server..
5) also on the  remote host i have 3 server instances running as server-one/two/three with a port offset of 100 that is there http ports are 8180 , 8280 and 8380
6) when i tried to connect to the server instance by providing the service urls as
service:jmx:http-remoting-jmx://remote_host_A:8180 or 8280/8380 ...i am not able to connect
and i have provided the application user and password here...
 and i am getting an error as 
"secure connection failed . retry insecurely?
the connection to wildflyuser at service:jmx:http-remoting-jmx://remote_host_A:8180 could not be made using SSL
would you like to try without SSL?"
here wildflyuser is an application user i have created from the add-user.sh command...
even on trying insecurely it doesn't  connects ....

Just a note : I was able to connect with the above changes in jboss-7.2.0 but there was a remoting port there ...in wildfly8 this is not present and undertow is mutiplexing the ports as i know ...let me know if i am missing any configuration here ...as this one includes undertow as well...

Thanks
RIturaj
                
      was (Author: rituraj):
    Hi Darran ..thanks for replying and looking into it ....
i am using the domain configuration in wildfly 8.0.0.Final....and also using HA profile to be specific...below are the steps i have performed so far 
1) created an application user and management user from the add-user script 
2) in domain.xml i have added the below line as <remoting-connector use-management-endpoint="false"/> in the jmx subsystem
also updated my host.xml with the below in management and application realm  respectively...
                <server-identities>
                    <secret value="base64password"/>
                </server-identities>

3) downloaded wildfly 8.0.0.Final on my laptop  ....i have set the JAVA_HOME and JBOSS_HOME ...started jconsole from the path $JBOSS_HOME/bin/jconsole.bat
4) provided the service URL as service:jmx:http-remoting-jmx://remote_host_A:9990  and given management user_id and password  i am able to connect to the host controller running remotely ...
5) also on the  remote host i have 3 server instances running as server-one/two/three with a port offset of 100 that is there http ports are 8180 , 8280 and 8380
6) when i tried to connect to the server instance by providing the service urls as
service:jmx:http-remoting-jmx://remote_host_A:8180 or 8280/8380 ...i am not able to connect
and i have provided the application user and password here...
 and i am getting an error as 
"secure connection failed . retry insecurely?
the connection to wildflyuser at service:jmx:http-remoting-jmx://remote_host_A:8180 could not be made using SSL
would you like to try without SSL?"
here wildflyuser is an application user i have created from the add-user.sh command...
even on trying insecurely it doesn't  connects ....

Just a note : I was able to connect with the above changes in jboss-7.2.0 but there was a remoting port there ...in wildfly8 this is not present and undertow is mutiplexing the ports as i know ...let me know if i am missing any configuration here ...as this one includes undertow as well...

Thanks
RIturaj
                  
> JMX connection to remote server-instances is not happening in wildfly 8.0.0.Final in domain mode
> ------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-3051
>                 URL: https://issues.jboss.org/browse/WFLY-3051
>             Project: WildFly
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: JMX, Remoting
>    Affects Versions: 8.0.0.Final
>            Reporter: Rituraj Sinha
>            Assignee: Darran Lofthouse
>             Fix For: 8.0.1.Final
>
>
> i have gone through the below link for JMX subsystem for wildfly 8 as
> https://docs.jboss.org/author/display/WFLY8/JMX+subsystem+configuration
>  
> but unable to connect to server-instances running remotely ...i have posted my question there as well and pasting it here now ...
> can someone please give us the steps to configure JMX through jconsole...?
> changes done on the domain.xml are the same as stated above
> <subsystem xmlns="urn:jboss:domain:jmx:1.3">
>                 <expose-resolved-model/>
>                 <expose-expression-model/>
>                 <remoting-connector use-management-endpoint="false"/>
>             </subsystem>
> <subsystem xmlns="urn:jboss:domain:jmx:1.3">
>                 <expose-resolved-model/>
>                 <expose-expression-model/>
>                 <remoting-connector use-management-endpoint="false"/>
>             </subsystem>
> as per the jboss-as-jmx_1_3.xsd  its like
> <xs:attribute name="use-management-endpoint" type="xs:boolean" default="true" use="optional" >
>             <xs:annotation>
>                 <xs:documentation>
>                     If true then this connector will use the management endpoint, otherwise it will use the
>                     remoting subsystem endpoint.
>                 </xs:documentation>
>             </xs:annotation>
>         </xs:attribute>
> now if we are making it false then it should be using the remoting endpoint ...now remoting subsystem by default uses ApplicatoinRealm
> i have created application-user and password for the same but when i am trying to connect to remote server-instances its not connecting it....
> below is what i am able to connect to 
> service:jmx:http-remoting-jmx://remote_hostA:9990 --
> Unknown macro: {host A is where my domain_controller is running}
> how can i access the server-instances running on domain_controller
> Unknown macro: {there are three server_instanaces running on HostA with a port offset of 100 each}
> i am trying to connect with the below url as 
> service:jmx:http-remoting-jmx://lremote_hostA:8180
> let me know if something is missing from my side...
> Thanks

--
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

From issues at jboss.org  Fri Mar  7 02:19:33 2014
From: issues at jboss.org (niraj gupta (JIRA))
Date: Fri, 7 Mar 2014 02:19:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-441) drools-guvnor 5.5,
 declarative model, create more than one fact type,
 BPMN process does not load
In-Reply-To: <JIRA.12533209.1393317312000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12533209.1393317312000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12533209.1393317312000.10976.1394176773717@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/DROOLS-441?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12950973#comment-12950973 ] 

niraj gupta commented on DROOLS-441:
------------------------------------

Actually this method add model.drl asset into org.drools.guvnor.server.builder.BRMSPackageBuilder Package builder. My suspect is that this builder is not able to put declarative model into class path. Since this class is just a wrapper and all logic is been written in PackageBuilder, which is part of drool-compiler, a 3rd Party jar. I didn't trouble shoot this jar as such since commenting of this API solve my problem. However in future if we face any further problem related to this, we may  need fix. 
I am not seeing any exception though i inspect through out the call.

Thanks,
Niraj
                
> drools-guvnor 5.5, declarative model, create more than one fact type, BPMN process does not load
> ------------------------------------------------------------------------------------------------
>
>                 Key: DROOLS-441
>                 URL: https://issues.jboss.org/browse/DROOLS-441
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.5.0.Final
>         Environment: Tomcat 6.0.35, jBPM 5.5.Final
>            Reporter: niraj gupta
>            Assignee: Mark Proctor
>              Labels: drools-guvnor
>
>  I am using ?drools-guvnor 5.5.0.Final? open source tool for designing the business process (BPMN2). I end up in an issue and looking for help. Following is the scenario
> I created a package then process then after build, deploy execute successfully. Now I came back to guvnor and made few changes in the process. Then after same build, deploy execute successfully. But now this time I am creating a declarative model having 2 facts, also modifying business process. Then after same build, deploy execute successfully. This time modified/latest business process doesn?t load into console. This is my problem.  However I trouble shoot and google following are my observations:
> ?	I am running this application in tomcat 6.0.35
> ?	It works perfectly with POJO Model Jar approach.
> ?	It works perfectly with declarative model but having single fact.
> ?	I am not seeing any exceptions either in UI or console logs

--
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


From issues at jboss.org  Fri Mar  7 02:40:33 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 7 Mar 2014 02:40:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2261) standalone.sh --debug without
 port number not working
In-Reply-To: <JIRA.12502486.1381251288000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502486.1381251288000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502486.1381251288000.11008.1394178033329@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2261?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12950977#comment-12950977 ] 

RH Bugzilla Integration commented on WFLY-2261:
-----------------------------------------------

Petr Kremensky <pkremens at redhat.com> changed the Status of [bug 1063289|https://bugzilla.redhat.com/show_bug.cgi?id=1063289] from ON_QA to ASSIGNED
                
> standalone.sh --debug without port number not working 
> ------------------------------------------------------
>
>                 Key: WFLY-2261
>                 URL: https://issues.jboss.org/browse/WFLY-2261
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Scripts
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Cheng Fang
>            Assignee: Jeff Mesnil
>             Fix For: 8.0.1.Final
>
>
> ./standalone.sh --debug port-num works, but it failed when omitting port number.
> sh -x standalone.sh --debug  (expecting the default port 8787 to be used)
> {noformat}
> + eval '"/Library/Java/JavaVirtualMachines/jdk1.7.0_40.jdk/Contents/Home/bin/java"' '-D"[Standalone]"' -server -XX:+UseCompressedOops -Xms64m -Xmx512m -XX:MaxPermSize=256m -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true -agentlib:jdwp=transport=dt_socket,address=8787,server=y,suspend=n '"-Dorg.jboss.boot.log.file=/Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT/standalone/log/server.log"' '"-Dlogging.configuration=file:/Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT/standalone/configuration/logging.properties"' -jar '"/Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT/jboss-modules.jar"' -mp '"/Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT/modules"' org.jboss.as.standalone '-Djboss.home.dir="/Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT"' '-Djboss.server.base.dir="/Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT/standalone"' ' ""'
> ++ /Library/Java/JavaVirtualMachines/jdk1.7.0_40.jdk/Contents/Home/bin/java '-D[Standalone]' -server -XX:+UseCompressedOops -Xms64m -Xmx512m -XX:MaxPermSize=256m -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true -agentlib:jdwp=transport=dt_socket,address=8787,server=y,suspend=n -Dorg.jboss.boot.log.file=/Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT/standalone/log/server.log -Dlogging.configuration=file:/Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT/standalone/configuration/logging.properties -jar /Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT/jboss-modules.jar -mp /Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT/modules org.jboss.as.standalone -Djboss.home.dir=/Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT -Djboss.server.base.dir=/Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT/standalone ''
> Listening for transport dt_socket at address: 8787
> 12:19:36,715 INFO  [org.jboss.modules] (main) JBoss Modules version 1.3.0.Final
> 12:19:36,886 ERROR [stderr] (main) JBAS015801: Invalid option ''
> 12:19:36,893 INFO  [stdout] (main)
> 12:19:36,893 INFO  [stdout] (main) Usage: standalone.sh [args...]
> {noformat}
> sh -x standalone.sh --debug 8787 (the working command)
> {noformat}
> + eval '"/Library/Java/JavaVirtualMachines/jdk1.7.0_40.jdk/Contents/Home/bin/java"' '-D"[Standalone]"' -server -XX:+UseCompressedOops -Xms64m -Xmx512m -XX:MaxPermSize=256m -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true -agentlib:jdwp=transport=dt_socket,address=8787,server=y,suspend=n '"-Dorg.jboss.boot.log.file=/Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT/standalone/log/server.log"' '"-Dlogging.configuration=file:/Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT/standalone/configuration/logging.properties"' -jar '"/Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT/jboss-modules.jar"' -mp '"/Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT/modules"' org.jboss.as.standalone '-Djboss.home.dir="/Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT"' '-Djboss.server.base.dir="/Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT/standalone"' ''
> ++ /Library/Java/JavaVirtualMachines/jdk1.7.0_40.jdk/Contents/Home/bin/java '-D[Standalone]' -server -XX:+UseCompressedOops -Xms64m -Xmx512m -XX:MaxPermSize=256m -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true -agentlib:jdwp=transport=dt_socket,address=8787,server=y,suspend=n -Dorg.jboss.boot.log.file=/Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT/standalone/log/server.log -Dlogging.configuration=file:/Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT/standalone/configuration/logging.properties -jar /Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT/jboss-modules.jar -mp /Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT/modules org.jboss.as.standalone -Djboss.home.dir=/Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT -Djboss.server.base.dir=/Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT/standalone
> Listening for transport dt_socket at address: 8787
> 12:20:39,251 INFO  [org.jboss.modules] (main) JBoss Modules version 1.3.0.Final
> 12:20:39,626 INFO  [org.jboss.msc] (main) JBoss MSC version 1.2.0.Beta2
> {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


From issues at jboss.org  Fri Mar  7 02:52:33 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 7 Mar 2014 02:52:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2204) runtime exceptions thrown
 during parsing crash cli sessions
In-Reply-To: <JIRA.12502024.1380726912000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502024.1380726912000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502024.1380726912000.11054.1394178753441@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2204?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12950981#comment-12950981 ] 

RH Bugzilla Integration commented on WFLY-2204:
-----------------------------------------------

Petr Kremensky <pkremens at redhat.com> changed the Status of [bug 997584|https://bugzilla.redhat.com/show_bug.cgi?id=997584] from ON_QA to ASSIGNED
                
> runtime exceptions thrown during parsing crash cli sessions
> -----------------------------------------------------------
>
>                 Key: WFLY-2204
>                 URL: https://issues.jboss.org/browse/WFLY-2204
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: CLI
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Alexey Loubyansky
>            Assignee: Alexey Loubyansky
>             Fix For: 8.0.0.CR1
>
>
> Runtime exceptions thrown during command line parsing crash CLI sessions.

--
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

From issues at jboss.org  Fri Mar  7 03:10:34 2014
From: issues at jboss.org (Takayuki Konishi (JIRA))
Date: Fri, 7 Mar 2014 03:10:34 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1158) add "remove vault entry"
 option to vault tool
In-Reply-To: <JIRA.12471159.1343221728000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12471159.1343221728000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12471159.1343221728000.11098.1394179834974@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-1158?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Takayuki Konishi updated WFLY-1158:
-----------------------------------


    
> add "remove vault entry" option to vault tool 
> ----------------------------------------------
>
>                 Key: WFLY-1158
>                 URL: https://issues.jboss.org/browse/WFLY-1158
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Security
>            Reporter: Gernot P
>            Assignee: Peter Skopek
>         Attachments: patch.diff
>
>
> You cannot remove an entry form vault with the vault tool. You can choose only amog following options "0: Store a password  1: Check whether password exists  2: Exit"
> Pleas add "remove password" option to vault tool (vault.sh)

--
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

From issues at jboss.org  Fri Mar  7 03:51:33 2014
From: issues at jboss.org (Davide Sottara (JIRA))
Date: Fri, 7 Mar 2014 03:51:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-441) drools-guvnor 5.5,
 declarative model, create more than one fact type,
 BPMN process does not load
In-Reply-To: <JIRA.12533209.1393317312000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12533209.1393317312000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12533209.1393317312000.11210.1394182293415@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/DROOLS-441?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12950995#comment-12950995 ] 

Davide Sottara commented on DROOLS-441:
---------------------------------------

I'm afraid that commenting out the method call will prevent you from using declared classes altogether. Since you are working with the source code, 
could you add a line and check the result?

{code}
// PackageAssemblerBase
private void addDrl(String drl) throws IOException,
                                   DroolsParserException {
        if ( isEmpty( drl ) ) {
            return;
        }

        builder.addPackageFromDrl( new StringReader( drl ) );
        // --> check and log the result of this call:  
        builder.getErrors();
    }
{code}

Thanks!
                
> drools-guvnor 5.5, declarative model, create more than one fact type, BPMN process does not load
> ------------------------------------------------------------------------------------------------
>
>                 Key: DROOLS-441
>                 URL: https://issues.jboss.org/browse/DROOLS-441
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.5.0.Final
>         Environment: Tomcat 6.0.35, jBPM 5.5.Final
>            Reporter: niraj gupta
>            Assignee: Mark Proctor
>              Labels: drools-guvnor
>
>  I am using ?drools-guvnor 5.5.0.Final? open source tool for designing the business process (BPMN2). I end up in an issue and looking for help. Following is the scenario
> I created a package then process then after build, deploy execute successfully. Now I came back to guvnor and made few changes in the process. Then after same build, deploy execute successfully. But now this time I am creating a declarative model having 2 facts, also modifying business process. Then after same build, deploy execute successfully. This time modified/latest business process doesn?t load into console. This is my problem.  However I trouble shoot and google following are my observations:
> ?	I am running this application in tomcat 6.0.35
> ?	It works perfectly with POJO Model Jar approach.
> ?	It works perfectly with declarative model but having single fact.
> ?	I am not seeing any exceptions either in UI or console logs

--
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


From issues at jboss.org  Fri Mar  7 03:59:33 2014
From: issues at jboss.org (Chao Wang (JIRA))
Date: Fri, 7 Mar 2014 03:59:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JBWEB-293) NPE if method
 getClassLoader() returns null to represent the bootstrap class loader
In-Reply-To: <JIRA.12534367.1394182683166@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534367.1394182683166@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534367.1394182683166.11220.1394182773165@jira02.app.mwc.hst.phx2.redhat.com>

Chao Wang created JBWEB-293:
-------------------------------

             Summary: NPE if method getClassLoader() returns null to represent the bootstrap class loader
                 Key: JBWEB-293
                 URL: https://issues.jboss.org/browse/JBWEB-293
             Project: JBoss Web
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions: JBossWeb-2.1.14.GA
            Reporter: Chao Wang
            Assignee: Chao Wang


from the scenario in [JBPAPP-11027|https://issues.jboss.org/browse/JBPAPP-11027] , and java code in java/javax/el/BeanELResolver.java :

{code:title=BeanELResolver.java|borderStyle=solid}
        Iterator<Class<?>> iter = cache.keySet().iterator();
        while (iter.hasNext()) {
            Class<?> key = iter.next();
            BeanProperties bp = cache.get(key);
            if(bp.getType().getClassLoader().equals(classloader)){
                iter.remove();
            }
        }
{code}

Here, when key is "class java.lang.Class" and bp's type is "class java.lang.Class", method getClassLoader() returns null to represent the bootstrap class loader, then NPE as described is threw during stopping service jboss.web

{noformat}
cache content:

class org.jboss.on.embedded.bean.ResourceListItem=javax.el.BeanELResolver$BeanProperties at 36d4423d, 
class org.jboss.on.embedded.ui.NavigationAction_$$_javassist_seam_9=javax.el.BeanELResolver$BeanProperties at 2948ceea, 
class org.jboss.on.embedded.ui.ResourceAction_$$_javassist_seam_12=javax.el.BeanELResolver$BeanProperties at 6b0879d2, 
class org.jboss.on.embedded.ui.nav.SubCategoryTreeNode=javax.el.BeanELResolver$BeanProperties at 797600e3, 
class org.jboss.on.embedded.ui.nav.PlatformResourceTreeNode=javax.el.BeanELResolver$BeanProperties at 32347561, 
class java.lang.Class=javax.el.BeanELResolver$BeanProperties at 12064d07, 
class org.jboss.on.embedded.ui.nav.SingletonResourceTypeTreeNode=javax.el.BeanELResolver$BeanProperties at 5bab0fcf, 
class org.jboss.on.embedded.ui.nav.ResourceTreeNode=javax.el.BeanELResolver$BeanProperties at 3b9b0e0d, 
class org.jboss.on.embedded.ui.nav.NonSingletonResourceTypeTreeNode=javax.el.BeanELResolver$BeanProperties at 40b7960d, 
class org.rhq.core.domain.measurement.MeasurementDefinition=javax.el.BeanELResolver$BeanProperties at 54dc50ac, 
class org.rhq.core.domain.resource.Resource=javax.el.BeanELResolver$BeanProperties at 4c3477ba, 
class org.rhq.core.domain.measurement.MeasurementDataTrait=javax.el.BeanELResolver$BeanProperties at 8a07b6c, 
class org.jboss.seam.security.Identity=javax.el.BeanELResolver$BeanProperties at 6006f3e0, 
class org.jboss.on.embedded.bean.MeasurementDisplay=javax.el.BeanELResolver$BeanProperties at 68752860}
{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

From issues at jboss.org  Fri Mar  7 04:01:34 2014
From: issues at jboss.org (Chao Wang (JIRA))
Date: Fri, 7 Mar 2014 04:01:34 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JBWEB-293) NPE if method
 getClassLoader() returns null to represent the bootstrap class loader
In-Reply-To: <JIRA.12534367.1394182683000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534367.1394182683000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534367.1394182683000.11222.1394182894099@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBWEB-293?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Chao Wang updated JBWEB-293:
----------------------------

    Attachment: JBWEB-293.patch

    
> NPE if method getClassLoader() returns null to represent the bootstrap class loader
> -----------------------------------------------------------------------------------
>
>                 Key: JBWEB-293
>                 URL: https://issues.jboss.org/browse/JBWEB-293
>             Project: JBoss Web
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: JBossWeb-2.1.14.GA
>            Reporter: Chao Wang
>            Assignee: Chao Wang
>         Attachments: JBWEB-293.patch
>
>
> from the scenario in [JBPAPP-11027|https://issues.jboss.org/browse/JBPAPP-11027] , and java code in java/javax/el/BeanELResolver.java :
> {code:title=BeanELResolver.java|borderStyle=solid}
>         Iterator<Class<?>> iter = cache.keySet().iterator();
>         while (iter.hasNext()) {
>             Class<?> key = iter.next();
>             BeanProperties bp = cache.get(key);
>             if(bp.getType().getClassLoader().equals(classloader)){
>                 iter.remove();
>             }
>         }
> {code}
> Here, when key is "class java.lang.Class" and bp's type is "class java.lang.Class", method getClassLoader() returns null to represent the bootstrap class loader, then NPE as described is threw during stopping service jboss.web
> {noformat}
> cache content:
> class org.jboss.on.embedded.bean.ResourceListItem=javax.el.BeanELResolver$BeanProperties at 36d4423d, 
> class org.jboss.on.embedded.ui.NavigationAction_$$_javassist_seam_9=javax.el.BeanELResolver$BeanProperties at 2948ceea, 
> class org.jboss.on.embedded.ui.ResourceAction_$$_javassist_seam_12=javax.el.BeanELResolver$BeanProperties at 6b0879d2, 
> class org.jboss.on.embedded.ui.nav.SubCategoryTreeNode=javax.el.BeanELResolver$BeanProperties at 797600e3, 
> class org.jboss.on.embedded.ui.nav.PlatformResourceTreeNode=javax.el.BeanELResolver$BeanProperties at 32347561, 
> class java.lang.Class=javax.el.BeanELResolver$BeanProperties at 12064d07, 
> class org.jboss.on.embedded.ui.nav.SingletonResourceTypeTreeNode=javax.el.BeanELResolver$BeanProperties at 5bab0fcf, 
> class org.jboss.on.embedded.ui.nav.ResourceTreeNode=javax.el.BeanELResolver$BeanProperties at 3b9b0e0d, 
> class org.jboss.on.embedded.ui.nav.NonSingletonResourceTypeTreeNode=javax.el.BeanELResolver$BeanProperties at 40b7960d, 
> class org.rhq.core.domain.measurement.MeasurementDefinition=javax.el.BeanELResolver$BeanProperties at 54dc50ac, 
> class org.rhq.core.domain.resource.Resource=javax.el.BeanELResolver$BeanProperties at 4c3477ba, 
> class org.rhq.core.domain.measurement.MeasurementDataTrait=javax.el.BeanELResolver$BeanProperties at 8a07b6c, 
> class org.jboss.seam.security.Identity=javax.el.BeanELResolver$BeanProperties at 6006f3e0, 
> class org.jboss.on.embedded.bean.MeasurementDisplay=javax.el.BeanELResolver$BeanProperties at 68752860}
> {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

From issues at jboss.org  Fri Mar  7 04:05:33 2014
From: issues at jboss.org (Remy Maucherat (JIRA))
Date: Fri, 7 Mar 2014 04:05:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JBEE-149) Patch Taglibs Bug 33934
In-Reply-To: <JIRA.12533663.1393614039000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12533663.1393614039000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12533663.1393614039000.11228.1394183133235@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JBEE-149?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12950999#comment-12950999 ] 

Remy Maucherat commented on JBEE-149:
-------------------------------------

Looks ok. Trunk is now slightly different though.
                
> Patch Taglibs Bug 33934
> -----------------------
>
>                 Key: JBEE-149
>                 URL: https://issues.jboss.org/browse/JBEE-149
>             Project: JBoss JavaEE Spec APIs
>          Issue Type: Bug
>          Components: jboss-jstl-api
>    Affects Versions: jboss-jstl-api_1.2_spec-1.0.5.Final
>            Reporter: Kevin Formsma
>            Assignee: Shelly McGowan
>
> Taglibs fixed a bug where SetTag would retain references to the target object, causing pooled SetTag instances to have much higher memory usage when the target object is large. When using many web threads in JBoss 7.2.2, our heap grows due to these objects being associated to pooled SetTags.
> https://issues.apache.org/bugzilla/show_bug.cgi?id=33934
> Can this patch be fixed in the jboss fork of taglibs as well?

--
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

From issues at jboss.org  Fri Mar  7 04:07:34 2014
From: issues at jboss.org (Remy Maucherat (JIRA))
Date: Fri, 7 Mar 2014 04:07:34 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JBEE-148) Unbounded ELEvaluator cache
	can cause OOMEs
In-Reply-To: <JIRA.12533643.1393604030000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12533643.1393604030000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12533643.1393604030000.11238.1394183254023@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JBEE-148?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12951001#comment-12951001 ] 

Remy Maucherat commented on JBEE-148:
-------------------------------------

Looks ok. Trunk includes the patch.
IMO, it wouldn't hurt to rebase on a newer release, the specification didn't change.
                
> Unbounded ELEvaluator cache can cause OOMEs
> -------------------------------------------
>
>                 Key: JBEE-148
>                 URL: https://issues.jboss.org/browse/JBEE-148
>             Project: JBoss JavaEE Spec APIs
>          Issue Type: Bug
>          Components: jboss-jstl-api
>    Affects Versions: jboss-jstl-api_1.2_spec-1.0.5.Final, jboss-jstl-api_1.2_spec-1.1.0.Final
>            Reporter: Aaron Ogburn
>            Assignee: Shelly McGowan
>         Attachments: diff.out
>
>
> Unbounded jstl ELEvaluator cache can cause OOMEs.
> Related community issue:
> https://issues.apache.org/bugzilla/show_bug.cgi?id=31789
> This was fixed in 1.0 and 1.1 but never got added to 1.2 so we missed this here too.

--
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

From issues at jboss.org  Fri Mar  7 04:17:33 2014
From: issues at jboss.org (Chao Wang (JIRA))
Date: Fri, 7 Mar 2014 04:17:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JBWEB-293) NPE if method
 getClassLoader() returns null to represent the bootstrap class loader
In-Reply-To: <JIRA.12534367.1394182683000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534367.1394182683000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534367.1394182683000.11258.1394183853572@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBWEB-293?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Chao Wang updated JBWEB-293:
----------------------------

    Attachment: JBWEB-293.patch

    
> NPE if method getClassLoader() returns null to represent the bootstrap class loader
> -----------------------------------------------------------------------------------
>
>                 Key: JBWEB-293
>                 URL: https://issues.jboss.org/browse/JBWEB-293
>             Project: JBoss Web
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: JBossWeb-2.1.14.GA
>            Reporter: Chao Wang
>            Assignee: Chao Wang
>         Attachments: JBWEB-293.patch
>
>
> from the scenario in [JBPAPP-11027|https://issues.jboss.org/browse/JBPAPP-11027] , and java code in java/javax/el/BeanELResolver.java :
> {code:title=BeanELResolver.java|borderStyle=solid}
>         Iterator<Class<?>> iter = cache.keySet().iterator();
>         while (iter.hasNext()) {
>             Class<?> key = iter.next();
>             BeanProperties bp = cache.get(key);
>             if(bp.getType().getClassLoader().equals(classloader)){
>                 iter.remove();
>             }
>         }
> {code}
> Here, when key is "class java.lang.Class" and bp's type is "class java.lang.Class", method getClassLoader() returns null to represent the bootstrap class loader, then NPE as described is threw during stopping service jboss.web
> {noformat}
> cache content:
> class org.jboss.on.embedded.bean.ResourceListItem=javax.el.BeanELResolver$BeanProperties at 36d4423d, 
> class org.jboss.on.embedded.ui.NavigationAction_$$_javassist_seam_9=javax.el.BeanELResolver$BeanProperties at 2948ceea, 
> class org.jboss.on.embedded.ui.ResourceAction_$$_javassist_seam_12=javax.el.BeanELResolver$BeanProperties at 6b0879d2, 
> class org.jboss.on.embedded.ui.nav.SubCategoryTreeNode=javax.el.BeanELResolver$BeanProperties at 797600e3, 
> class org.jboss.on.embedded.ui.nav.PlatformResourceTreeNode=javax.el.BeanELResolver$BeanProperties at 32347561, 
> class java.lang.Class=javax.el.BeanELResolver$BeanProperties at 12064d07, 
> class org.jboss.on.embedded.ui.nav.SingletonResourceTypeTreeNode=javax.el.BeanELResolver$BeanProperties at 5bab0fcf, 
> class org.jboss.on.embedded.ui.nav.ResourceTreeNode=javax.el.BeanELResolver$BeanProperties at 3b9b0e0d, 
> class org.jboss.on.embedded.ui.nav.NonSingletonResourceTypeTreeNode=javax.el.BeanELResolver$BeanProperties at 40b7960d, 
> class org.rhq.core.domain.measurement.MeasurementDefinition=javax.el.BeanELResolver$BeanProperties at 54dc50ac, 
> class org.rhq.core.domain.resource.Resource=javax.el.BeanELResolver$BeanProperties at 4c3477ba, 
> class org.rhq.core.domain.measurement.MeasurementDataTrait=javax.el.BeanELResolver$BeanProperties at 8a07b6c, 
> class org.jboss.seam.security.Identity=javax.el.BeanELResolver$BeanProperties at 6006f3e0, 
> class org.jboss.on.embedded.bean.MeasurementDisplay=javax.el.BeanELResolver$BeanProperties at 68752860}
> {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

From issues at jboss.org  Fri Mar  7 04:17:33 2014
From: issues at jboss.org (Chao Wang (JIRA))
Date: Fri, 7 Mar 2014 04:17:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JBWEB-293) NPE if method
 getClassLoader() returns null to represent the bootstrap class loader
In-Reply-To: <JIRA.12534367.1394182683000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534367.1394182683000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534367.1394182683000.11259.1394183853615@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBWEB-293?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Chao Wang updated JBWEB-293:
----------------------------

    Attachment:     (was: JBWEB-293.patch)

    
> NPE if method getClassLoader() returns null to represent the bootstrap class loader
> -----------------------------------------------------------------------------------
>
>                 Key: JBWEB-293
>                 URL: https://issues.jboss.org/browse/JBWEB-293
>             Project: JBoss Web
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: JBossWeb-2.1.14.GA
>            Reporter: Chao Wang
>            Assignee: Chao Wang
>         Attachments: JBWEB-293.patch
>
>
> from the scenario in [JBPAPP-11027|https://issues.jboss.org/browse/JBPAPP-11027] , and java code in java/javax/el/BeanELResolver.java :
> {code:title=BeanELResolver.java|borderStyle=solid}
>         Iterator<Class<?>> iter = cache.keySet().iterator();
>         while (iter.hasNext()) {
>             Class<?> key = iter.next();
>             BeanProperties bp = cache.get(key);
>             if(bp.getType().getClassLoader().equals(classloader)){
>                 iter.remove();
>             }
>         }
> {code}
> Here, when key is "class java.lang.Class" and bp's type is "class java.lang.Class", method getClassLoader() returns null to represent the bootstrap class loader, then NPE as described is threw during stopping service jboss.web
> {noformat}
> cache content:
> class org.jboss.on.embedded.bean.ResourceListItem=javax.el.BeanELResolver$BeanProperties at 36d4423d, 
> class org.jboss.on.embedded.ui.NavigationAction_$$_javassist_seam_9=javax.el.BeanELResolver$BeanProperties at 2948ceea, 
> class org.jboss.on.embedded.ui.ResourceAction_$$_javassist_seam_12=javax.el.BeanELResolver$BeanProperties at 6b0879d2, 
> class org.jboss.on.embedded.ui.nav.SubCategoryTreeNode=javax.el.BeanELResolver$BeanProperties at 797600e3, 
> class org.jboss.on.embedded.ui.nav.PlatformResourceTreeNode=javax.el.BeanELResolver$BeanProperties at 32347561, 
> class java.lang.Class=javax.el.BeanELResolver$BeanProperties at 12064d07, 
> class org.jboss.on.embedded.ui.nav.SingletonResourceTypeTreeNode=javax.el.BeanELResolver$BeanProperties at 5bab0fcf, 
> class org.jboss.on.embedded.ui.nav.ResourceTreeNode=javax.el.BeanELResolver$BeanProperties at 3b9b0e0d, 
> class org.jboss.on.embedded.ui.nav.NonSingletonResourceTypeTreeNode=javax.el.BeanELResolver$BeanProperties at 40b7960d, 
> class org.rhq.core.domain.measurement.MeasurementDefinition=javax.el.BeanELResolver$BeanProperties at 54dc50ac, 
> class org.rhq.core.domain.resource.Resource=javax.el.BeanELResolver$BeanProperties at 4c3477ba, 
> class org.rhq.core.domain.measurement.MeasurementDataTrait=javax.el.BeanELResolver$BeanProperties at 8a07b6c, 
> class org.jboss.seam.security.Identity=javax.el.BeanELResolver$BeanProperties at 6006f3e0, 
> class org.jboss.on.embedded.bean.MeasurementDisplay=javax.el.BeanELResolver$BeanProperties at 68752860}
> {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

From issues at jboss.org  Fri Mar  7 04:31:37 2014
From: issues at jboss.org (David Schneider (JIRA))
Date: Fri, 7 Mar 2014 04:31:37 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3080) Cygwin createUsers.sh still
 error "JBAS015232"
In-Reply-To: <JIRA.12534372.1394184687274@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534372.1394184687274@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534372.1394184687274.11365.1394184697974@jira02.app.mwc.hst.phx2.redhat.com>

David Schneider created WFLY-3080:
-------------------------------------

             Summary: Cygwin createUsers.sh still error "JBAS015232"
                 Key: WFLY-3080
                 URL: https://issues.jboss.org/browse/WFLY-3080
             Project: WildFly
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions: 8.0.0.Final
         Environment: Windows 7 64-Bit
            Reporter: David Schneider
            Priority: Minor


There is still a bug with the "createUsers.sh" script. You need to enable silent mode within the script. 




--
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

From issues at jboss.org  Fri Mar  7 04:37:33 2014
From: issues at jboss.org (niraj gupta (JIRA))
Date: Fri, 7 Mar 2014 04:37:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-441) drools-guvnor 5.5,
 declarative model, create more than one fact type,
 BPMN process does not load
In-Reply-To: <JIRA.12533209.1393317312000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12533209.1393317312000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12533209.1393317312000.11393.1394185053798@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/DROOLS-441?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12951023#comment-12951023 ] 

niraj gupta commented on DROOLS-441:
------------------------------------

I tried the below code and it showing zero error size.

        builder.addPackageFromDrl( new StringReader( drl ) );
        
        PackageBuilderErrors error = builder.getErrors();
        
        System.out.println(error.getErrors().length);

Regards,
Niraj
                
> drools-guvnor 5.5, declarative model, create more than one fact type, BPMN process does not load
> ------------------------------------------------------------------------------------------------
>
>                 Key: DROOLS-441
>                 URL: https://issues.jboss.org/browse/DROOLS-441
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.5.0.Final
>         Environment: Tomcat 6.0.35, jBPM 5.5.Final
>            Reporter: niraj gupta
>            Assignee: Mark Proctor
>              Labels: drools-guvnor
>
>  I am using ?drools-guvnor 5.5.0.Final? open source tool for designing the business process (BPMN2). I end up in an issue and looking for help. Following is the scenario
> I created a package then process then after build, deploy execute successfully. Now I came back to guvnor and made few changes in the process. Then after same build, deploy execute successfully. But now this time I am creating a declarative model having 2 facts, also modifying business process. Then after same build, deploy execute successfully. This time modified/latest business process doesn?t load into console. This is my problem.  However I trouble shoot and google following are my observations:
> ?	I am running this application in tomcat 6.0.35
> ?	It works perfectly with POJO Model Jar approach.
> ?	It works perfectly with declarative model but having single fact.
> ?	I am not seeing any exceptions either in UI or console logs

--
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


From issues at jboss.org  Fri Mar  7 04:39:33 2014
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Fri, 7 Mar 2014 04:39:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3051) JMX connection to remote
 server-instances is not happening in wildfly 8.0.0.Final in domain mode
In-Reply-To: <JIRA.12533723.1393825342000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12533723.1393825342000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12533723.1393825342000.11397.1394185173586@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-3051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12951024#comment-12951024 ] 

Darran Lofthouse commented on WFLY-3051:
----------------------------------------

Thanks [~rituraj] that does seem to describe the problem I can also reproduce, continuing to investigate.
                
> JMX connection to remote server-instances is not happening in wildfly 8.0.0.Final in domain mode
> ------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-3051
>                 URL: https://issues.jboss.org/browse/WFLY-3051
>             Project: WildFly
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: JMX, Remoting
>    Affects Versions: 8.0.0.Final
>            Reporter: Rituraj Sinha
>            Assignee: Darran Lofthouse
>             Fix For: 8.0.1.Final
>
>
> i have gone through the below link for JMX subsystem for wildfly 8 as
> https://docs.jboss.org/author/display/WFLY8/JMX+subsystem+configuration
>  
> but unable to connect to server-instances running remotely ...i have posted my question there as well and pasting it here now ...
> can someone please give us the steps to configure JMX through jconsole...?
> changes done on the domain.xml are the same as stated above
> <subsystem xmlns="urn:jboss:domain:jmx:1.3">
>                 <expose-resolved-model/>
>                 <expose-expression-model/>
>                 <remoting-connector use-management-endpoint="false"/>
>             </subsystem>
> <subsystem xmlns="urn:jboss:domain:jmx:1.3">
>                 <expose-resolved-model/>
>                 <expose-expression-model/>
>                 <remoting-connector use-management-endpoint="false"/>
>             </subsystem>
> as per the jboss-as-jmx_1_3.xsd  its like
> <xs:attribute name="use-management-endpoint" type="xs:boolean" default="true" use="optional" >
>             <xs:annotation>
>                 <xs:documentation>
>                     If true then this connector will use the management endpoint, otherwise it will use the
>                     remoting subsystem endpoint.
>                 </xs:documentation>
>             </xs:annotation>
>         </xs:attribute>
> now if we are making it false then it should be using the remoting endpoint ...now remoting subsystem by default uses ApplicatoinRealm
> i have created application-user and password for the same but when i am trying to connect to remote server-instances its not connecting it....
> below is what i am able to connect to 
> service:jmx:http-remoting-jmx://remote_hostA:9990 --
> Unknown macro: {host A is where my domain_controller is running}
> how can i access the server-instances running on domain_controller
> Unknown macro: {there are three server_instanaces running on HostA with a port offset of 100 each}
> i am trying to connect with the below url as 
> service:jmx:http-remoting-jmx://lremote_hostA:8180
> let me know if something is missing from my side...
> Thanks

--
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

From issues at jboss.org  Fri Mar  7 04:49:34 2014
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Fri, 7 Mar 2014 04:49:34 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3051) JMX connection to remote
 server-instances is not happening in wildfly 8.0.0.Final in domain mode
In-Reply-To: <JIRA.12533723.1393825342000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12533723.1393825342000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12533723.1393825342000.11443.1394185774020@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-3051?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated WFLY-3051:
-----------------------------------

    Priority: Critical  (was: Major)

    
> JMX connection to remote server-instances is not happening in wildfly 8.0.0.Final in domain mode
> ------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-3051
>                 URL: https://issues.jboss.org/browse/WFLY-3051
>             Project: WildFly
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: JMX, Remoting
>    Affects Versions: 8.0.0.Final
>            Reporter: Rituraj Sinha
>            Assignee: Darran Lofthouse
>            Priority: Critical
>             Fix For: 8.0.1.Final
>
>
> i have gone through the below link for JMX subsystem for wildfly 8 as
> https://docs.jboss.org/author/display/WFLY8/JMX+subsystem+configuration
>  
> but unable to connect to server-instances running remotely ...i have posted my question there as well and pasting it here now ...
> can someone please give us the steps to configure JMX through jconsole...?
> changes done on the domain.xml are the same as stated above
> <subsystem xmlns="urn:jboss:domain:jmx:1.3">
>                 <expose-resolved-model/>
>                 <expose-expression-model/>
>                 <remoting-connector use-management-endpoint="false"/>
>             </subsystem>
> <subsystem xmlns="urn:jboss:domain:jmx:1.3">
>                 <expose-resolved-model/>
>                 <expose-expression-model/>
>                 <remoting-connector use-management-endpoint="false"/>
>             </subsystem>
> as per the jboss-as-jmx_1_3.xsd  its like
> <xs:attribute name="use-management-endpoint" type="xs:boolean" default="true" use="optional" >
>             <xs:annotation>
>                 <xs:documentation>
>                     If true then this connector will use the management endpoint, otherwise it will use the
>                     remoting subsystem endpoint.
>                 </xs:documentation>
>             </xs:annotation>
>         </xs:attribute>
> now if we are making it false then it should be using the remoting endpoint ...now remoting subsystem by default uses ApplicatoinRealm
> i have created application-user and password for the same but when i am trying to connect to remote server-instances its not connecting it....
> below is what i am able to connect to 
> service:jmx:http-remoting-jmx://remote_hostA:9990 --
> Unknown macro: {host A is where my domain_controller is running}
> how can i access the server-instances running on domain_controller
> Unknown macro: {there are three server_instanaces running on HostA with a port offset of 100 each}
> i am trying to connect with the below url as 
> service:jmx:http-remoting-jmx://lremote_hostA:8180
> let me know if something is missing from my side...
> Thanks

--
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

From issues at jboss.org  Fri Mar  7 04:51:34 2014
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Fri, 7 Mar 2014 04:51:34 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3051) http-remoting-jmx connection
 failure connecting to Undertow subsystem instead of Undertow management
In-Reply-To: <JIRA.12533723.1393825342000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12533723.1393825342000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12533723.1393825342000.11451.1394185894260@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-3051?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated WFLY-3051:
-----------------------------------

    Summary: http-remoting-jmx connection failure connecting to Undertow subsystem instead of Undertow management  (was: JMX connection to remote server-instances is not happening in wildfly 8.0.0.Final in domain mode)

    
> http-remoting-jmx connection failure connecting to Undertow subsystem instead of Undertow management
> ----------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-3051
>                 URL: https://issues.jboss.org/browse/WFLY-3051
>             Project: WildFly
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: JMX, Remoting
>    Affects Versions: 8.0.0.Final
>            Reporter: Rituraj Sinha
>            Assignee: Darran Lofthouse
>            Priority: Critical
>             Fix For: 8.0.1.Final
>
>
> i have gone through the below link for JMX subsystem for wildfly 8 as
> https://docs.jboss.org/author/display/WFLY8/JMX+subsystem+configuration
>  
> but unable to connect to server-instances running remotely ...i have posted my question there as well and pasting it here now ...
> can someone please give us the steps to configure JMX through jconsole...?
> changes done on the domain.xml are the same as stated above
> <subsystem xmlns="urn:jboss:domain:jmx:1.3">
>                 <expose-resolved-model/>
>                 <expose-expression-model/>
>                 <remoting-connector use-management-endpoint="false"/>
>             </subsystem>
> <subsystem xmlns="urn:jboss:domain:jmx:1.3">
>                 <expose-resolved-model/>
>                 <expose-expression-model/>
>                 <remoting-connector use-management-endpoint="false"/>
>             </subsystem>
> as per the jboss-as-jmx_1_3.xsd  its like
> <xs:attribute name="use-management-endpoint" type="xs:boolean" default="true" use="optional" >
>             <xs:annotation>
>                 <xs:documentation>
>                     If true then this connector will use the management endpoint, otherwise it will use the
>                     remoting subsystem endpoint.
>                 </xs:documentation>
>             </xs:annotation>
>         </xs:attribute>
> now if we are making it false then it should be using the remoting endpoint ...now remoting subsystem by default uses ApplicatoinRealm
> i have created application-user and password for the same but when i am trying to connect to remote server-instances its not connecting it....
> below is what i am able to connect to 
> service:jmx:http-remoting-jmx://remote_hostA:9990 --
> Unknown macro: {host A is where my domain_controller is running}
> how can i access the server-instances running on domain_controller
> Unknown macro: {there are three server_instanaces running on HostA with a port offset of 100 each}
> i am trying to connect with the below url as 
> service:jmx:http-remoting-jmx://lremote_hostA:8180
> let me know if something is missing from my side...
> Thanks

--
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

From issues at jboss.org  Fri Mar  7 05:21:33 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 7 Mar 2014 05:21:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1070) Add a redirect-socket
 configuration to the web connector config
In-Reply-To: <JIRA.12462483.1332792004000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12462483.1332792004000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12462483.1332792004000.11549.1394187693995@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1070?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12951034#comment-12951034 ] 

RH Bugzilla Integration commented on WFLY-1070:
-----------------------------------------------

Carlo de Wolf <cdewolf at redhat.com> changed the Status of [bug 900786|https://bugzilla.redhat.com/show_bug.cgi?id=900786] from NEW to ASSIGNED
                
> Add a redirect-socket configuration to the web connector config
> ---------------------------------------------------------------
>
>                 Key: WFLY-1070
>                 URL: https://issues.jboss.org/browse/WFLY-1070
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Web (Undertow)
>            Reporter: Brian Stansberry
>            Assignee: Tomaz Cerar
>             Fix For: 8.0.0.CR1
>
>
> Support configuring a connector on the http socket and then redirect to the https socket without having to specify the actual port number outside of the socket-binding-group.
> The referenced forum thread has an example that uses "redirect-port" for this, but a new attribute would be needed, since changing the meaning of "redirect-port" would be incompatible.
>  

--
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

From issues at jboss.org  Fri Mar  7 05:29:33 2014
From: issues at jboss.org (Rituraj Sinha (JIRA))
Date: Fri, 7 Mar 2014 05:29:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3051) http-remoting-jmx connection
 failure connecting to Undertow subsystem instead of Undertow management
In-Reply-To: <JIRA.12533723.1393825342000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12533723.1393825342000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12533723.1393825342000.11585.1394188173710@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-3051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12951037#comment-12951037 ] 

Rituraj Sinha commented on WFLY-3051:
-------------------------------------

Thanks Darran ...i glad that i made it clear to you....let us know when you get some progress ....
                
> http-remoting-jmx connection failure connecting to Undertow subsystem instead of Undertow management
> ----------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-3051
>                 URL: https://issues.jboss.org/browse/WFLY-3051
>             Project: WildFly
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: JMX, Remoting
>    Affects Versions: 8.0.0.Final
>            Reporter: Rituraj Sinha
>            Assignee: Darran Lofthouse
>            Priority: Critical
>             Fix For: 8.0.1.Final
>
>
> i have gone through the below link for JMX subsystem for wildfly 8 as
> https://docs.jboss.org/author/display/WFLY8/JMX+subsystem+configuration
>  
> but unable to connect to server-instances running remotely ...i have posted my question there as well and pasting it here now ...
> can someone please give us the steps to configure JMX through jconsole...?
> changes done on the domain.xml are the same as stated above
> <subsystem xmlns="urn:jboss:domain:jmx:1.3">
>                 <expose-resolved-model/>
>                 <expose-expression-model/>
>                 <remoting-connector use-management-endpoint="false"/>
>             </subsystem>
> <subsystem xmlns="urn:jboss:domain:jmx:1.3">
>                 <expose-resolved-model/>
>                 <expose-expression-model/>
>                 <remoting-connector use-management-endpoint="false"/>
>             </subsystem>
> as per the jboss-as-jmx_1_3.xsd  its like
> <xs:attribute name="use-management-endpoint" type="xs:boolean" default="true" use="optional" >
>             <xs:annotation>
>                 <xs:documentation>
>                     If true then this connector will use the management endpoint, otherwise it will use the
>                     remoting subsystem endpoint.
>                 </xs:documentation>
>             </xs:annotation>
>         </xs:attribute>
> now if we are making it false then it should be using the remoting endpoint ...now remoting subsystem by default uses ApplicatoinRealm
> i have created application-user and password for the same but when i am trying to connect to remote server-instances its not connecting it....
> below is what i am able to connect to 
> service:jmx:http-remoting-jmx://remote_hostA:9990 --
> Unknown macro: {host A is where my domain_controller is running}
> how can i access the server-instances running on domain_controller
> Unknown macro: {there are three server_instanaces running on HostA with a port offset of 100 each}
> i am trying to connect with the below url as 
> service:jmx:http-remoting-jmx://lremote_hostA:8180
> let me know if something is missing from my side...
> Thanks

--
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

From issues at jboss.org  Fri Mar  7 05:39:34 2014
From: issues at jboss.org (lokesh tarley (JIRA))
Date: Fri, 7 Mar 2014 05:39:34 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3051) http-remoting-jmx connection
 failure connecting to Undertow subsystem instead of Undertow management
In-Reply-To: <JIRA.12533723.1393825342000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12533723.1393825342000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12533723.1393825342000.11603.1394188774013@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-3051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12951041#comment-12951041 ] 

lokesh tarley commented on WFLY-3051:
-------------------------------------

Thanks Darran, for your reply,
when i connect to the remote server AS instances through Jconsole, i got the mention messages
  /path/to /wildfly-8.0.0.Final/bin/jconsole.sh 

Connection Failed Retry ?
The connection to 
<username>@service:jmx:http-remoting-jmx://ip:8180(remote server ip : remote instance port)
did not succeed
would you like to try again ?
-lokesh



                
> http-remoting-jmx connection failure connecting to Undertow subsystem instead of Undertow management
> ----------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-3051
>                 URL: https://issues.jboss.org/browse/WFLY-3051
>             Project: WildFly
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: JMX, Remoting
>    Affects Versions: 8.0.0.Final
>            Reporter: Rituraj Sinha
>            Assignee: Darran Lofthouse
>            Priority: Critical
>             Fix For: 8.0.1.Final
>
>
> i have gone through the below link for JMX subsystem for wildfly 8 as
> https://docs.jboss.org/author/display/WFLY8/JMX+subsystem+configuration
>  
> but unable to connect to server-instances running remotely ...i have posted my question there as well and pasting it here now ...
> can someone please give us the steps to configure JMX through jconsole...?
> changes done on the domain.xml are the same as stated above
> <subsystem xmlns="urn:jboss:domain:jmx:1.3">
>                 <expose-resolved-model/>
>                 <expose-expression-model/>
>                 <remoting-connector use-management-endpoint="false"/>
>             </subsystem>
> <subsystem xmlns="urn:jboss:domain:jmx:1.3">
>                 <expose-resolved-model/>
>                 <expose-expression-model/>
>                 <remoting-connector use-management-endpoint="false"/>
>             </subsystem>
> as per the jboss-as-jmx_1_3.xsd  its like
> <xs:attribute name="use-management-endpoint" type="xs:boolean" default="true" use="optional" >
>             <xs:annotation>
>                 <xs:documentation>
>                     If true then this connector will use the management endpoint, otherwise it will use the
>                     remoting subsystem endpoint.
>                 </xs:documentation>
>             </xs:annotation>
>         </xs:attribute>
> now if we are making it false then it should be using the remoting endpoint ...now remoting subsystem by default uses ApplicatoinRealm
> i have created application-user and password for the same but when i am trying to connect to remote server-instances its not connecting it....
> below is what i am able to connect to 
> service:jmx:http-remoting-jmx://remote_hostA:9990 --
> Unknown macro: {host A is where my domain_controller is running}
> how can i access the server-instances running on domain_controller
> Unknown macro: {there are three server_instanaces running on HostA with a port offset of 100 each}
> i am trying to connect with the below url as 
> service:jmx:http-remoting-jmx://lremote_hostA:8180
> let me know if something is missing from my side...
> Thanks

--
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

From issues at jboss.org  Fri Mar  7 05:51:33 2014
From: issues at jboss.org (Emmanuel Hugonnet (JIRA))
Date: Fri, 7 Mar 2014 05:51:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3081) Redirect Forward port web
 subsystem1.6 xsd and parser from EAP 6.3
In-Reply-To: <JIRA.12534374.1394189470754@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534374.1394189470754@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534374.1394189470754.11630.1394189493688@jira02.app.mwc.hst.phx2.redhat.com>

Emmanuel Hugonnet created WFLY-3081:
---------------------------------------

             Summary: Redirect Forward port web subsystem1.6 xsd and parser from EAP 6.3
                 Key: WFLY-3081
                 URL: https://issues.jboss.org/browse/WFLY-3081
             Project: WildFly
          Issue Type: Task
      Security Level: Public (Everyone can see)
          Components: Web (JBoss Web)
    Affects Versions: 8.0.0.Final
            Reporter: Emmanuel Hugonnet
            Assignee: Emmanuel Hugonnet




--
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

From issues at jboss.org  Fri Mar  7 05:51:34 2014
From: issues at jboss.org (Rituraj Sinha (JIRA))
Date: Fri, 7 Mar 2014 05:51:34 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3051) http-remoting-jmx connection
 failure connecting to Undertow subsystem instead of Undertow management
In-Reply-To: <JIRA.12533723.1393825342000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12533723.1393825342000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12533723.1393825342000.11637.1394189494056@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-3051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12951037#comment-12951037 ] 

Rituraj Sinha edited comment on WFLY-3051 at 3/7/14 5:51 AM:
-------------------------------------------------------------

Thanks Darran ...i am glad that i made it clear to you....let us know when you get some progress ....
                
      was (Author: rituraj):
    Thanks Darran ...i glad that i made it clear to you....let us know when you get some progress ....
                  
> http-remoting-jmx connection failure connecting to Undertow subsystem instead of Undertow management
> ----------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-3051
>                 URL: https://issues.jboss.org/browse/WFLY-3051
>             Project: WildFly
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: JMX, Remoting
>    Affects Versions: 8.0.0.Final
>            Reporter: Rituraj Sinha
>            Assignee: Darran Lofthouse
>            Priority: Critical
>             Fix For: 8.0.1.Final
>
>
> i have gone through the below link for JMX subsystem for wildfly 8 as
> https://docs.jboss.org/author/display/WFLY8/JMX+subsystem+configuration
>  
> but unable to connect to server-instances running remotely ...i have posted my question there as well and pasting it here now ...
> can someone please give us the steps to configure JMX through jconsole...?
> changes done on the domain.xml are the same as stated above
> <subsystem xmlns="urn:jboss:domain:jmx:1.3">
>                 <expose-resolved-model/>
>                 <expose-expression-model/>
>                 <remoting-connector use-management-endpoint="false"/>
>             </subsystem>
> <subsystem xmlns="urn:jboss:domain:jmx:1.3">
>                 <expose-resolved-model/>
>                 <expose-expression-model/>
>                 <remoting-connector use-management-endpoint="false"/>
>             </subsystem>
> as per the jboss-as-jmx_1_3.xsd  its like
> <xs:attribute name="use-management-endpoint" type="xs:boolean" default="true" use="optional" >
>             <xs:annotation>
>                 <xs:documentation>
>                     If true then this connector will use the management endpoint, otherwise it will use the
>                     remoting subsystem endpoint.
>                 </xs:documentation>
>             </xs:annotation>
>         </xs:attribute>
> now if we are making it false then it should be using the remoting endpoint ...now remoting subsystem by default uses ApplicatoinRealm
> i have created application-user and password for the same but when i am trying to connect to remote server-instances its not connecting it....
> below is what i am able to connect to 
> service:jmx:http-remoting-jmx://remote_hostA:9990 --
> Unknown macro: {host A is where my domain_controller is running}
> how can i access the server-instances running on domain_controller
> Unknown macro: {there are three server_instanaces running on HostA with a port offset of 100 each}
> i am trying to connect with the below url as 
> service:jmx:http-remoting-jmx://lremote_hostA:8180
> let me know if something is missing from my side...
> Thanks

--
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

From issues at jboss.org  Fri Mar  7 05:53:33 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 7 Mar 2014 05:53:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3081) Redirect Forward port web
 subsystem1.6 xsd and parser from EAP 6.3
In-Reply-To: <JIRA.12534374.1394189470000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534374.1394189470000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534374.1394189470000.11641.1394189613656@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-3081?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated WFLY-3081:
------------------------------------------

    Bugzilla Update:   (was: Perform)

    
> Redirect Forward port web subsystem1.6 xsd and parser from EAP 6.3
> ------------------------------------------------------------------
>
>                 Key: WFLY-3081
>                 URL: https://issues.jboss.org/browse/WFLY-3081
>             Project: WildFly
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Web (JBoss Web)
>    Affects Versions: 8.0.0.Final
>            Reporter: Emmanuel Hugonnet
>            Assignee: Emmanuel Hugonnet
>


--
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

From issues at jboss.org  Fri Mar  7 05:53:33 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 7 Mar 2014 05:53:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3081) Redirect Forward port web
 subsystem1.6 xsd and parser from EAP 6.3
In-Reply-To: <JIRA.12534374.1394189470000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534374.1394189470000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534374.1394189470000.11644.1394189613784@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-3081?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated WFLY-3081:
------------------------------------------

        Bugzilla Update: Perform
    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=900786

    
> Redirect Forward port web subsystem1.6 xsd and parser from EAP 6.3
> ------------------------------------------------------------------
>
>                 Key: WFLY-3081
>                 URL: https://issues.jboss.org/browse/WFLY-3081
>             Project: WildFly
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Web (JBoss Web)
>    Affects Versions: 8.0.0.Final
>            Reporter: Emmanuel Hugonnet
>            Assignee: Emmanuel Hugonnet
>


--
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

From issues at jboss.org  Fri Mar  7 05:55:33 2014
From: issues at jboss.org (Emmanuel Hugonnet (JIRA))
Date: Fri, 7 Mar 2014 05:55:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3081) Redirect Forward port web
 subsystem1.6 xsd and parser from EAP 6.3
In-Reply-To: <JIRA.12534374.1394189470000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534374.1394189470000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534374.1394189470000.11652.1394189733619@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-3081?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Emmanuel Hugonnet updated WFLY-3081:
------------------------------------

    Description: 
Support configuring a connector on the http socket and then redirect to the https socket without having to specify the actual port number outside of the socket-binding-group.
Support for configuring proxy port and proxy name using socket-binding also.


    
> Redirect Forward port web subsystem1.6 xsd and parser from EAP 6.3
> ------------------------------------------------------------------
>
>                 Key: WFLY-3081
>                 URL: https://issues.jboss.org/browse/WFLY-3081
>             Project: WildFly
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Web (JBoss Web)
>    Affects Versions: 8.0.0.Final
>            Reporter: Emmanuel Hugonnet
>            Assignee: Emmanuel Hugonnet
>
> Support configuring a connector on the http socket and then redirect to the https socket without having to specify the actual port number outside of the socket-binding-group.
> Support for configuring proxy port and proxy name using socket-binding also.

--
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

From issues at jboss.org  Fri Mar  7 06:03:33 2014
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Fri, 7 Mar 2014 06:03:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (REMJMX-81) Add http-remoting-jmx testing
In-Reply-To: <JIRA.12534377.1394190190225@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534377.1394190190225@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534377.1394190190225.11663.1394190213620@jira02.app.mwc.hst.phx2.redhat.com>

Darran Lofthouse created REMJMX-81:
--------------------------------------

             Summary: Add http-remoting-jmx testing
                 Key: REMJMX-81
                 URL: https://issues.jboss.org/browse/REMJMX-81
             Project: Remoting JMX
          Issue Type: Task
          Components: Tests
            Reporter: Darran Lofthouse
            Assignee: Darran Lofthouse
             Fix For: 2.0.1.CR1


Connecting over HTTP is now the default mode for WildFly yet we have no testing of this within the Remoting JMX project itself.

--
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

From issues at jboss.org  Fri Mar  7 06:30:33 2014
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Fri, 7 Mar 2014 06:30:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3051) http-remoting-jmx connection
 failure connecting to Undertow subsystem instead of Undertow management
In-Reply-To: <JIRA.12533723.1393825342000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12533723.1393825342000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12533723.1393825342000.11743.1394191833777@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-3051?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated WFLY-3051:
-----------------------------------

    Issue Type: Bug  (was: Task)

    
> http-remoting-jmx connection failure connecting to Undertow subsystem instead of Undertow management
> ----------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-3051
>                 URL: https://issues.jboss.org/browse/WFLY-3051
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JMX, Remoting
>    Affects Versions: 8.0.0.Final
>            Reporter: Rituraj Sinha
>            Assignee: Darran Lofthouse
>            Priority: Critical
>             Fix For: 8.0.1.Final
>
>
> i have gone through the below link for JMX subsystem for wildfly 8 as
> https://docs.jboss.org/author/display/WFLY8/JMX+subsystem+configuration
>  
> but unable to connect to server-instances running remotely ...i have posted my question there as well and pasting it here now ...
> can someone please give us the steps to configure JMX through jconsole...?
> changes done on the domain.xml are the same as stated above
> <subsystem xmlns="urn:jboss:domain:jmx:1.3">
>                 <expose-resolved-model/>
>                 <expose-expression-model/>
>                 <remoting-connector use-management-endpoint="false"/>
>             </subsystem>
> <subsystem xmlns="urn:jboss:domain:jmx:1.3">
>                 <expose-resolved-model/>
>                 <expose-expression-model/>
>                 <remoting-connector use-management-endpoint="false"/>
>             </subsystem>
> as per the jboss-as-jmx_1_3.xsd  its like
> <xs:attribute name="use-management-endpoint" type="xs:boolean" default="true" use="optional" >
>             <xs:annotation>
>                 <xs:documentation>
>                     If true then this connector will use the management endpoint, otherwise it will use the
>                     remoting subsystem endpoint.
>                 </xs:documentation>
>             </xs:annotation>
>         </xs:attribute>
> now if we are making it false then it should be using the remoting endpoint ...now remoting subsystem by default uses ApplicatoinRealm
> i have created application-user and password for the same but when i am trying to connect to remote server-instances its not connecting it....
> below is what i am able to connect to 
> service:jmx:http-remoting-jmx://remote_hostA:9990 --
> Unknown macro: {host A is where my domain_controller is running}
> how can i access the server-instances running on domain_controller
> Unknown macro: {there are three server_instanaces running on HostA with a port offset of 100 each}
> i am trying to connect with the below url as 
> service:jmx:http-remoting-jmx://lremote_hostA:8180
> let me know if something is missing from my side...
> Thanks

--
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

From issues at jboss.org  Fri Mar  7 06:30:34 2014
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Fri, 7 Mar 2014 06:30:34 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3051) http-remoting-jmx connection
 failure connecting to Undertow subsystem instead of Undertow management
In-Reply-To: <JIRA.12533723.1393825342000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12533723.1393825342000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12533723.1393825342000.11751.1394191834196@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-3051?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated WFLY-3051:
-----------------------------------

    Workaround Description: 
Edit the module definition for 'org.wildfly.extension.io' and add the following dependency: -

{code}
        <module name="javax.api"/>
{code}
                Workaround: Workaround Exists

    
> http-remoting-jmx connection failure connecting to Undertow subsystem instead of Undertow management
> ----------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-3051
>                 URL: https://issues.jboss.org/browse/WFLY-3051
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JMX, Remoting
>    Affects Versions: 8.0.0.Final
>            Reporter: Rituraj Sinha
>            Assignee: Darran Lofthouse
>            Priority: Critical
>             Fix For: 8.0.1.Final
>
>
> i have gone through the below link for JMX subsystem for wildfly 8 as
> https://docs.jboss.org/author/display/WFLY8/JMX+subsystem+configuration
>  
> but unable to connect to server-instances running remotely ...i have posted my question there as well and pasting it here now ...
> can someone please give us the steps to configure JMX through jconsole...?
> changes done on the domain.xml are the same as stated above
> <subsystem xmlns="urn:jboss:domain:jmx:1.3">
>                 <expose-resolved-model/>
>                 <expose-expression-model/>
>                 <remoting-connector use-management-endpoint="false"/>
>             </subsystem>
> <subsystem xmlns="urn:jboss:domain:jmx:1.3">
>                 <expose-resolved-model/>
>                 <expose-expression-model/>
>                 <remoting-connector use-management-endpoint="false"/>
>             </subsystem>
> as per the jboss-as-jmx_1_3.xsd  its like
> <xs:attribute name="use-management-endpoint" type="xs:boolean" default="true" use="optional" >
>             <xs:annotation>
>                 <xs:documentation>
>                     If true then this connector will use the management endpoint, otherwise it will use the
>                     remoting subsystem endpoint.
>                 </xs:documentation>
>             </xs:annotation>
>         </xs:attribute>
> now if we are making it false then it should be using the remoting endpoint ...now remoting subsystem by default uses ApplicatoinRealm
> i have created application-user and password for the same but when i am trying to connect to remote server-instances its not connecting it....
> below is what i am able to connect to 
> service:jmx:http-remoting-jmx://remote_hostA:9990 --
> Unknown macro: {host A is where my domain_controller is running}
> how can i access the server-instances running on domain_controller
> Unknown macro: {there are three server_instanaces running on HostA with a port offset of 100 each}
> i am trying to connect with the below url as 
> service:jmx:http-remoting-jmx://lremote_hostA:8180
> let me know if something is missing from my side...
> Thanks

--
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

From issues at jboss.org  Fri Mar  7 06:44:33 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 7 Mar 2014 06:44:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2051) CLI write attribute dialog
 for string value should enclose value in generated command to double quotes
In-Reply-To: <JIRA.12500587.1378980513000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500587.1378980513000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500587.1378980513000.11776.1394192673412@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12951059#comment-12951059 ] 

RH Bugzilla Integration commented on WFLY-2051:
-----------------------------------------------

Petr Kremensky <pkremens at redhat.com> changed the Status of [bug 988283|https://bugzilla.redhat.com/show_bug.cgi?id=988283] from ON_QA to VERIFIED
                
> CLI write attribute dialog for string value should enclose value in generated command to double quotes
> ------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2051
>                 URL: https://issues.jboss.org/browse/WFLY-2051
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: CLI
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Chao Wang
>            Assignee: Alexey Loubyansky
>             Fix For: 8.0.0.CR1
>
>
> {noformat}
> Wildfly issue for https://bugzilla.redhat.com/show_bug.cgi?id=988283
> String value entered in write attribute dialog is written to command without double quotes, which is wrong in many cases
> Eg. when user enteres in dialog value ${jboss.bind.address:127.0.0.1}
> following command is generated:
> /subsystem=webservices/:write-attribute(name=wsdl-host,value=${jboss.bind.address:127.0.0.1})
> Correctly should be generated command 
> /subsystem=webservices/:write-attribute(name=wsdl-host,value="${jboss.bind.address:127.0.0.1}")
> 1. start AS
>   ./bin/standalone.sh
> 2. start CLI GUI 
>   ./bin/jboss-cli.sh --gui &
> 3. click on node subsystem=webservices of /
> 4. right click on wsdl-host and select write-attribute
> 5. enter value ${jboss.bind.address:127.0.0.1} and click OK
> 6. submit generated command
> 7. reload node
>   click on node subsystem=webservices of / (close node)
>   click on node subsystem=webservices of / (open node)
> Result is wsdl-host=$ instead of wsdl-host=${jboss.bind.address:127.0.0.1}
> Workaround: in dialog box enclose the value in double quotes
> {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

From issues at jboss.org  Fri Mar  7 06:52:34 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 7 Mar 2014 06:52:34 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3081) Redirect Forward port web
 subsystem1.6 xsd and parser from EAP 6.3
In-Reply-To: <JIRA.12534374.1394189470000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534374.1394189470000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534374.1394189470000.11794.1394193154099@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-3081?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12951062#comment-12951062 ] 

RH Bugzilla Integration commented on WFLY-3081:
-----------------------------------------------

Emmanuel Hugonnet (ehsavoie) <ehugonne at redhat.com> changed the Status of [bug 900786|https://bugzilla.redhat.com/show_bug.cgi?id=900786] from ASSIGNED to POST
                
> Redirect Forward port web subsystem1.6 xsd and parser from EAP 6.3
> ------------------------------------------------------------------
>
>                 Key: WFLY-3081
>                 URL: https://issues.jboss.org/browse/WFLY-3081
>             Project: WildFly
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Web (JBoss Web)
>    Affects Versions: 8.0.0.Final
>            Reporter: Emmanuel Hugonnet
>            Assignee: Emmanuel Hugonnet
>
> Support configuring a connector on the http socket and then redirect to the https socket without having to specify the actual port number outside of the socket-binding-group.
> Support for configuring proxy port and proxy name using socket-binding also.

--
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

From issues at jboss.org  Fri Mar  7 06:52:34 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 7 Mar 2014 06:52:34 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1070) Add a redirect-socket
 configuration to the web connector config
In-Reply-To: <JIRA.12462483.1332792004000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12462483.1332792004000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12462483.1332792004000.11807.1394193154637@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1070?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12951064#comment-12951064 ] 

RH Bugzilla Integration commented on WFLY-1070:
-----------------------------------------------

Emmanuel Hugonnet (ehsavoie) <ehugonne at redhat.com> changed the Status of [bug 900786|https://bugzilla.redhat.com/show_bug.cgi?id=900786] from ASSIGNED to POST
                
> Add a redirect-socket configuration to the web connector config
> ---------------------------------------------------------------
>
>                 Key: WFLY-1070
>                 URL: https://issues.jboss.org/browse/WFLY-1070
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Web (Undertow)
>            Reporter: Brian Stansberry
>            Assignee: Tomaz Cerar
>             Fix For: 8.0.0.CR1
>
>
> Support configuring a connector on the http socket and then redirect to the https socket without having to specify the actual port number outside of the socket-binding-group.
> The referenced forum thread has an example that uses "redirect-port" for this, but a new attribute would be needed, since changing the meaning of "redirect-port" would be incompatible.
>  

--
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

From issues at jboss.org  Fri Mar  7 06:56:33 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 7 Mar 2014 06:56:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2987)
 RemoteDestinationOutboundSocketBindingService is not stopped when the
 resource is removed
In-Reply-To: <JIRA.12532915.1392980383000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12532915.1392980383000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12532915.1392980383000.11832.1394193393438@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2987?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12951068#comment-12951068 ] 

RH Bugzilla Integration commented on WFLY-2987:
-----------------------------------------------

Petr Kremensky <pkremens at redhat.com> changed the Status of [bug 1038465|https://bugzilla.redhat.com/show_bug.cgi?id=1038465] from ON_QA to VERIFIED
                
> RemoteDestinationOutboundSocketBindingService is not stopped when the resource is removed
> -----------------------------------------------------------------------------------------
>
>                 Key: WFLY-2987
>                 URL: https://issues.jboss.org/browse/WFLY-2987
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Server
>    Affects Versions: 8.0.0.Final
>            Reporter: Jeff Mesnil
>            Assignee: Jeff Mesnil
>             Fix For: 8.0.1.Final
>
>
> Steps to Reproduce:
> 1. add remote-destination-outbound-socket-binding
> ./jboss-cli.sh -c "/socket-binding-group=standard-sockets/remote-destination-outbound-socket-binding=remote-connection-war-ejb-1:add(host=localhost, port=4447)"
> result is {"outcome" => "success"}
> 3. remove remote-destination-outbound-socket-binding
> ./bin/jboss-cli.sh -c "/socket-binding-group=standard-sockets/remote-destination-outbound-socket-binding=remote-connection-war-ejb-1:remove"
> result is {"outcome" => "success"}
> 4. add remote-destination-outbound-socket-binding
> ./jboss-cli.sh -c "/socket-binding-group=standard-sockets/remote-destination-outbound-socket-binding=remote-connection-war-ejb-1:add(host=localhost, port=4447)"
> result is
> {
>     "outcome" => "failed",
>     "failure-description" => "JBAS014749: Operation handler failed: Service jboss.outbound-socket-binding.remote-connection-war-ejb-1 is already registered",
>     "rolled-back" => true
> }
> Expected results:
> {"outcome" => "success"}
> Step 3 should either report reload required or should be fixed

--
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

From issues at jboss.org  Fri Mar  7 07:06:33 2014
From: issues at jboss.org (Rituraj Sinha (JIRA))
Date: Fri, 7 Mar 2014 07:06:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3051) http-remoting-jmx connection
 failure connecting to Undertow subsystem instead of Undertow management
In-Reply-To: <JIRA.12533723.1393825342000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12533723.1393825342000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12533723.1393825342000.11895.1394193993353@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-3051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12951079#comment-12951079 ] 

Rituraj Sinha commented on WFLY-3051:
-------------------------------------

wow it worked ...i am able to connect to 8180 port ....

Thanks a lot Darran!!!
                
> http-remoting-jmx connection failure connecting to Undertow subsystem instead of Undertow management
> ----------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-3051
>                 URL: https://issues.jboss.org/browse/WFLY-3051
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JMX, Remoting
>    Affects Versions: 8.0.0.Final
>            Reporter: Rituraj Sinha
>            Assignee: Darran Lofthouse
>            Priority: Critical
>             Fix For: 8.0.1.Final
>
>
> i have gone through the below link for JMX subsystem for wildfly 8 as
> https://docs.jboss.org/author/display/WFLY8/JMX+subsystem+configuration
>  
> but unable to connect to server-instances running remotely ...i have posted my question there as well and pasting it here now ...
> can someone please give us the steps to configure JMX through jconsole...?
> changes done on the domain.xml are the same as stated above
> <subsystem xmlns="urn:jboss:domain:jmx:1.3">
>                 <expose-resolved-model/>
>                 <expose-expression-model/>
>                 <remoting-connector use-management-endpoint="false"/>
>             </subsystem>
> <subsystem xmlns="urn:jboss:domain:jmx:1.3">
>                 <expose-resolved-model/>
>                 <expose-expression-model/>
>                 <remoting-connector use-management-endpoint="false"/>
>             </subsystem>
> as per the jboss-as-jmx_1_3.xsd  its like
> <xs:attribute name="use-management-endpoint" type="xs:boolean" default="true" use="optional" >
>             <xs:annotation>
>                 <xs:documentation>
>                     If true then this connector will use the management endpoint, otherwise it will use the
>                     remoting subsystem endpoint.
>                 </xs:documentation>
>             </xs:annotation>
>         </xs:attribute>
> now if we are making it false then it should be using the remoting endpoint ...now remoting subsystem by default uses ApplicatoinRealm
> i have created application-user and password for the same but when i am trying to connect to remote server-instances its not connecting it....
> below is what i am able to connect to 
> service:jmx:http-remoting-jmx://remote_hostA:9990 --
> Unknown macro: {host A is where my domain_controller is running}
> how can i access the server-instances running on domain_controller
> Unknown macro: {there are three server_instanaces running on HostA with a port offset of 100 each}
> i am trying to connect with the below url as 
> service:jmx:http-remoting-jmx://lremote_hostA:8180
> let me know if something is missing from my side...
> Thanks

--
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

From issues at jboss.org  Fri Mar  7 07:10:34 2014
From: issues at jboss.org (lokesh tarley (JIRA))
Date: Fri, 7 Mar 2014 07:10:34 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3051) http-remoting-jmx connection
 failure connecting to Undertow subsystem instead of Undertow management
In-Reply-To: <JIRA.12533723.1393825342000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12533723.1393825342000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12533723.1393825342000.11935.1394194234798@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-3051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12951084#comment-12951084 ] 

lokesh tarley commented on WFLY-3051:
-------------------------------------

Thanks a LOT Darran, it works , i added the "<module name="javax.api"/> as per your descreption...and the remote AS instances are now connected with the application username and password....

<dependencies>
        <module name="sun.jdk"/>
        <module name="org.jboss.staxmapper"/>
        <module name="org.jboss.as.controller"/>
        <module name="org.wildfly.security.manager"/>
        <module name="org.jboss.as.server"/>
        <module name="org.jboss.as.security" optional="true"/>
        <module name="org.jboss.msc"/>
        <module name="org.jboss.logging"/>
        <module name="org.jboss.xnio"/>
        <module name="org.jboss.xnio.nio" services="import"/>
        <module name="org.picketbox" optional="true"/>
        <module name="org.jboss.remoting"export="true"/>
        <module name="org.jboss.remoting-jmx" export="true"/>
        <module name="javax.api"/>
    </dependencies>
Again thanks for the Quick response and the accurate solution/workaround.....

-Lokesh
                
> http-remoting-jmx connection failure connecting to Undertow subsystem instead of Undertow management
> ----------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-3051
>                 URL: https://issues.jboss.org/browse/WFLY-3051
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JMX, Remoting
>    Affects Versions: 8.0.0.Final
>            Reporter: Rituraj Sinha
>            Assignee: Darran Lofthouse
>            Priority: Critical
>             Fix For: 8.0.1.Final
>
>
> i have gone through the below link for JMX subsystem for wildfly 8 as
> https://docs.jboss.org/author/display/WFLY8/JMX+subsystem+configuration
>  
> but unable to connect to server-instances running remotely ...i have posted my question there as well and pasting it here now ...
> can someone please give us the steps to configure JMX through jconsole...?
> changes done on the domain.xml are the same as stated above
> <subsystem xmlns="urn:jboss:domain:jmx:1.3">
>                 <expose-resolved-model/>
>                 <expose-expression-model/>
>                 <remoting-connector use-management-endpoint="false"/>
>             </subsystem>
> <subsystem xmlns="urn:jboss:domain:jmx:1.3">
>                 <expose-resolved-model/>
>                 <expose-expression-model/>
>                 <remoting-connector use-management-endpoint="false"/>
>             </subsystem>
> as per the jboss-as-jmx_1_3.xsd  its like
> <xs:attribute name="use-management-endpoint" type="xs:boolean" default="true" use="optional" >
>             <xs:annotation>
>                 <xs:documentation>
>                     If true then this connector will use the management endpoint, otherwise it will use the
>                     remoting subsystem endpoint.
>                 </xs:documentation>
>             </xs:annotation>
>         </xs:attribute>
> now if we are making it false then it should be using the remoting endpoint ...now remoting subsystem by default uses ApplicatoinRealm
> i have created application-user and password for the same but when i am trying to connect to remote server-instances its not connecting it....
> below is what i am able to connect to 
> service:jmx:http-remoting-jmx://remote_hostA:9990 --
> Unknown macro: {host A is where my domain_controller is running}
> how can i access the server-instances running on domain_controller
> Unknown macro: {there are three server_instanaces running on HostA with a port offset of 100 each}
> i am trying to connect with the below url as 
> service:jmx:http-remoting-jmx://lremote_hostA:8180
> let me know if something is missing from my side...
> Thanks

--
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

From issues at jboss.org  Fri Mar  7 07:24:33 2014
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Fri, 7 Mar 2014 07:24:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3054) getPlatformMBeanServer
 behaves badly when called from premain class such as jmxetric
In-Reply-To: <JIRA.12533815.1393864749000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12533815.1393864749000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12533815.1393864749000.11993.1394195073731@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-3054?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12951092#comment-12951092 ] 

Kabir Khan commented on WFLY-3054:
----------------------------------

I believe that the platform mbean server can only be swapped out on the initial call to ManagementFactory.getPlatformMBeanServer(), and jboss-modules needs to set that, unless you can figure out how to do that the same way from your code.

Alternatively, perhaps an alternative premain method which waits for the actual class passed in to jboss-modules as the main, before calling getPlatformMBeanServer() could work. By that stage jboss-modules should have set the platform mbean server. In the case of a standalone server the name of the main class is 'org.jboss.as.server.Main'. Apart from that I don't really think there is a lot we can do.


                
> getPlatformMBeanServer behaves badly when called from premain class such as jmxetric
> ------------------------------------------------------------------------------------
>
>                 Key: WFLY-3054
>                 URL: https://issues.jboss.org/browse/WFLY-3054
>             Project: WildFly
>          Issue Type: Enhancement
>      Security Level: Public(Everyone can see) 
>          Components: JMX
>    Affects Versions: JBoss AS7 7.1.1.Final
>            Reporter: dpocock
>            Assignee: Kabir Khan
>              Labels: jboss
>
> JMXetric is a management agent JAR loaded using the JVM argument 
> java -javaagent:$JARLIBS/jmxetric-1.0.2.jar .....
> In the premain method (executed before JBoss main() is invoked), jmxetric calls the static method:
>    ManagementFactory.getPlatformMBeanServer()
> This puts JMX into a bad state and the jboss.as tree is completely missing when browsed with jconsole
> As a workaround, jmxetric will defer the call to ManagementFactory.getPlatformMBeanServer() using the "initialdelay" parameter set to a value such as 20 seconds.
> However, it would be good if JBoss could act more cleanly in this situation, for example, throwing an exception if ManagementFactory.getPlatformMBeanServer() is called too early, or finding a way to add the "jboss.as" stuff later.
> The 1.0.6 release of jmxetric will include the workaround by default.  The bug can be reproduced by setting initialdelay="0" in the sample jmxetric.xml or using jmxetric 1.0.5
> jmxetric versions before 1.0.5 suffer from issues with the jboss logger as discussed in WFLY-895, so this issue was only discovered after removing the logging statements from jmxetric.
> Also covered in jmxetric github:
> https://github.com/ganglia/jmxetric/issues/9

--
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

From issues at jboss.org  Fri Mar  7 07:47:33 2014
From: issues at jboss.org (Richard Achmatowicz (JIRA))
Date: Fri, 7 Mar 2014 07:47:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1799) RpcDispatcher test fails when
 working with large values
In-Reply-To: <JIRA.12533122.1393254868000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12533122.1393254868000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12533122.1393254868000.12092.1394196453878@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JGRP-1799?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12951102#comment-12951102 ] 

Richard Achmatowicz commented on JGRP-1799:
-------------------------------------------

Bela, there are still failures of this test at the highest size which take more than 30 seconds on slow machines.
Can we increase this timeout to 60 seconds, from 30 seconds, as it is another case of a test which should eventually return a value and not within any specific time bound.


                
> RpcDispatcher test fails when working with large values
> -------------------------------------------------------
>
>                 Key: JGRP-1799
>                 URL: https://issues.jboss.org/browse/JGRP-1799
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.2.13
>         Environment: RHEL, Win, Solaris
>            Reporter: Richard Achmatowicz
>            Assignee: Bela Ban
>             Fix For: 3.2.13
>
>
> The two tests:
> * testLargeReturnValue
> * testLargeReturnValueUnicastCall
> make RPC calls with values which are increasingly large. 
> The values used are in this range:
> {noformat}
> SIZES={10000, 20000, 40000, 80000, 100000, 200000, 400000, 800000,1000000, 2000000, 5000000}
> {noformat}
> The tests have been see to fail with the values 1000000, 2000000 and 5000000, always with the same error in each case. 
> In the case of testLargeReturnValue, the test fails because one of the returned values from the RPC is null.
> In the case of testLargeReturnValueUnicastCall, the test fails due to a timeout while sending the RPC.
>  

--
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

From issues at jboss.org  Fri Mar  7 07:53:33 2014
From: issues at jboss.org (Richard Achmatowicz (JIRA))
Date: Fri, 7 Mar 2014 07:53:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1799) RpcDispatcher test fails when
 working with large values
In-Reply-To: <JIRA.12533122.1393254868000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12533122.1393254868000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12533122.1393254868000.12106.1394196813497@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JGRP-1799?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12951102#comment-12951102 ] 

Richard Achmatowicz edited comment on JGRP-1799 at 3/7/14 7:52 AM:
-------------------------------------------------------------------

Bela, there are still failures of this test at the highest size which take more than 30 seconds on slow machines.
Can we increase this timeout to 60 seconds, from 30 seconds, as it is another case of a test which should eventually return a value and not within any specific time bound.

For example, on Windows 2008:
{noformat}
------------- testLargeReturnValue -----------

testing with 10000 bytes
test took: 34 ms
rsps:
10000 bytes from A
10000 bytes from B
10000 bytes from C

testing with 20000 bytes
test took: 33 ms
rsps:
20000 bytes from A
20000 bytes from B
20000 bytes from C

testing with 40000 bytes
test took: 35 ms
rsps:
40000 bytes from A
40000 bytes from B
40000 bytes from C

testing with 80000 bytes
test took: 880 ms
rsps:
80000 bytes from A
80000 bytes from B
80000 bytes from C

testing with 100000 bytes
test took: 3574 ms
rsps:
100000 bytes from A
100000 bytes from B
100000 bytes from C

testing with 200000 bytes
test took: 5448 ms
rsps:
200000 bytes from A
200000 bytes from B
200000 bytes from C

testing with 400000 bytes
test took: 9975 ms
rsps:
400000 bytes from A
400000 bytes from B
400000 bytes from C

testing with 800000 bytes
test took: 18045 ms
rsps:
800000 bytes from A
800000 bytes from B
800000 bytes from C

testing with 1000000 bytes
test took: 22037 ms
rsps:
1000000 bytes from A
1000000 bytes from B
1000000 bytes from C

testing with 2000000 bytes
test took: 30074 ms
rsps:
{noformat}
                
      was (Author: rachmato):
    Bela, there are still failures of this test at the highest size which take more than 30 seconds on slow machines.
Can we increase this timeout to 60 seconds, from 30 seconds, as it is another case of a test which should eventually return a value and not within any specific time bound.


                  
> RpcDispatcher test fails when working with large values
> -------------------------------------------------------
>
>                 Key: JGRP-1799
>                 URL: https://issues.jboss.org/browse/JGRP-1799
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.2.13
>         Environment: RHEL, Win, Solaris
>            Reporter: Richard Achmatowicz
>            Assignee: Bela Ban
>             Fix For: 3.2.13
>
>
> The two tests:
> * testLargeReturnValue
> * testLargeReturnValueUnicastCall
> make RPC calls with values which are increasingly large. 
> The values used are in this range:
> {noformat}
> SIZES={10000, 20000, 40000, 80000, 100000, 200000, 400000, 800000,1000000, 2000000, 5000000}
> {noformat}
> The tests have been see to fail with the values 1000000, 2000000 and 5000000, always with the same error in each case. 
> In the case of testLargeReturnValue, the test fails because one of the returned values from the RPC is null.
> In the case of testLargeReturnValueUnicastCall, the test fails due to a timeout while sending the RPC.
>  

--
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

From issues at jboss.org  Fri Mar  7 07:53:34 2014
From: issues at jboss.org (Richard Achmatowicz (JIRA))
Date: Fri, 7 Mar 2014 07:53:34 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1799) RpcDispatcher test fails when
 working with large values
In-Reply-To: <JIRA.12533122.1393254868000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12533122.1393254868000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12533122.1393254868000.12117.1394196814220@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JGRP-1799?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12951102#comment-12951102 ] 

Richard Achmatowicz edited comment on JGRP-1799 at 3/7/14 7:53 AM:
-------------------------------------------------------------------

Bela, there are still failures of this test at the highest size which take more than 30 seconds on slow machines.
Can we increase this timeout to 60 seconds, from 30 seconds, as it is another case of a test which should eventually return a value and not within any specific time bound.

For example, on Windows 2008:
{noformat}
------------- testLargeReturnValue -----------

testing with 10000 bytes
test took: 34 ms
rsps:
10000 bytes from A
10000 bytes from B
10000 bytes from C

testing with 20000 bytes
test took: 33 ms
rsps:
20000 bytes from A
20000 bytes from B
20000 bytes from C

testing with 40000 bytes
test took: 35 ms
rsps:
40000 bytes from A
40000 bytes from B
40000 bytes from C

testing with 80000 bytes
test took: 880 ms
rsps:
80000 bytes from A
80000 bytes from B
80000 bytes from C

testing with 100000 bytes
test took: 3574 ms
rsps:
100000 bytes from A
100000 bytes from B
100000 bytes from C

testing with 200000 bytes
test took: 5448 ms
rsps:
200000 bytes from A
200000 bytes from B
200000 bytes from C

testing with 400000 bytes
test took: 9975 ms
rsps:
400000 bytes from A
400000 bytes from B
400000 bytes from C

testing with 800000 bytes
test took: 18045 ms
rsps:
800000 bytes from A
800000 bytes from B
800000 bytes from C

testing with 1000000 bytes
test took: 22037 ms
rsps:
1000000 bytes from A
1000000 bytes from B
1000000 bytes from C

testing with 2000000 bytes
test took: 30074 ms
rsps:
{noformat}

There may also be GC activity in play here.
                
      was (Author: rachmato):
    Bela, there are still failures of this test at the highest size which take more than 30 seconds on slow machines.
Can we increase this timeout to 60 seconds, from 30 seconds, as it is another case of a test which should eventually return a value and not within any specific time bound.

For example, on Windows 2008:
{noformat}
------------- testLargeReturnValue -----------

testing with 10000 bytes
test took: 34 ms
rsps:
10000 bytes from A
10000 bytes from B
10000 bytes from C

testing with 20000 bytes
test took: 33 ms
rsps:
20000 bytes from A
20000 bytes from B
20000 bytes from C

testing with 40000 bytes
test took: 35 ms
rsps:
40000 bytes from A
40000 bytes from B
40000 bytes from C

testing with 80000 bytes
test took: 880 ms
rsps:
80000 bytes from A
80000 bytes from B
80000 bytes from C

testing with 100000 bytes
test took: 3574 ms
rsps:
100000 bytes from A
100000 bytes from B
100000 bytes from C

testing with 200000 bytes
test took: 5448 ms
rsps:
200000 bytes from A
200000 bytes from B
200000 bytes from C

testing with 400000 bytes
test took: 9975 ms
rsps:
400000 bytes from A
400000 bytes from B
400000 bytes from C

testing with 800000 bytes
test took: 18045 ms
rsps:
800000 bytes from A
800000 bytes from B
800000 bytes from C

testing with 1000000 bytes
test took: 22037 ms
rsps:
1000000 bytes from A
1000000 bytes from B
1000000 bytes from C

testing with 2000000 bytes
test took: 30074 ms
rsps:
{noformat}
                  
> RpcDispatcher test fails when working with large values
> -------------------------------------------------------
>
>                 Key: JGRP-1799
>                 URL: https://issues.jboss.org/browse/JGRP-1799
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.2.13
>         Environment: RHEL, Win, Solaris
>            Reporter: Richard Achmatowicz
>            Assignee: Bela Ban
>             Fix For: 3.2.13
>
>
> The two tests:
> * testLargeReturnValue
> * testLargeReturnValueUnicastCall
> make RPC calls with values which are increasingly large. 
> The values used are in this range:
> {noformat}
> SIZES={10000, 20000, 40000, 80000, 100000, 200000, 400000, 800000,1000000, 2000000, 5000000}
> {noformat}
> The tests have been see to fail with the values 1000000, 2000000 and 5000000, always with the same error in each case. 
> In the case of testLargeReturnValue, the test fails because one of the returned values from the RPC is null.
> In the case of testLargeReturnValueUnicastCall, the test fails due to a timeout while sending the RPC.
>  

--
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

From issues at jboss.org  Fri Mar  7 09:02:33 2014
From: issues at jboss.org (Radoslav Husar (JIRA))
Date: Fri, 7 Mar 2014 09:02:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3082) Option to provide a default
 cache configuration instead of repeating each cache definition
In-Reply-To: <JIRA.12534406.1394200911340@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534406.1394200911340@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534406.1394200911340.12286.1394200953242@jira02.app.mwc.hst.phx2.redhat.com>

Radoslav Husar created WFLY-3082:
------------------------------------

             Summary: Option to provide a default cache configuration instead of repeating each cache definition
                 Key: WFLY-3082
                 URL: https://issues.jboss.org/browse/WFLY-3082
             Project: WildFly
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: Clustering
    Affects Versions: 8.0.0.Final
            Reporter: Radoslav Husar
            Assignee: Paul Ferraro
            Priority: Optional
             Fix For: Awaiting Volunteers


Wishlist item from the forum: https://community.jboss.org/message/861180#861180

Really just a syntactic sugar to allow templating for caches. Seems like too much complexity for a small benefit.

--
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

From issues at jboss.org  Fri Mar  7 09:06:33 2014
From: issues at jboss.org (Harald Pehl (JIRA))
Date: Fri, 7 Mar 2014 09:06:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3083) Update to HAL 2.2.0.Beta4
In-Reply-To: <JIRA.12534407.1394201158256@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534407.1394201158256@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534407.1394201158256.12292.1394201193181@jira02.app.mwc.hst.phx2.redhat.com>

Harald Pehl created WFLY-3083:
---------------------------------

             Summary: Update to HAL 2.2.0.Beta4
                 Key: WFLY-3083
                 URL: https://issues.jboss.org/browse/WFLY-3083
             Project: WildFly
          Issue Type: Component  Upgrade
      Security Level: Public (Everyone can see)
          Components: Web Console
            Reporter: Harald Pehl
            Assignee: Harald Pehl
            Priority: Blocker
             Fix For: 8.0.1.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

From issues at jboss.org  Fri Mar  7 09:10:34 2014
From: issues at jboss.org (Richard Achmatowicz (JIRA))
Date: Fri, 7 Mar 2014 09:10:34 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1802) OverlappingUnicastMergeTest
In-Reply-To: <JIRA.12533772.1393856602000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12533772.1393856602000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12533772.1393856602000.12317.1394201434216@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JGRP-1802?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Richard Achmatowicz updated JGRP-1802:
--------------------------------------

    Description: 
OverlappingUnicastMergeTest does the following:

- set up three channels a,b,c with the layers MERGE2, VERIFY_SUSPECT and FC removed
- the receiver of each channel will look at all incoming messages: if mcast, ignore it; if unicast, add to the list of messages received
- inject some new view into the channels which represents a view configuration which should be recovered from
- send messages to the channels and check that the messages are received, despite the  injected view

OverlappingUnicastMergeTest this test is failing in a number of ways (i.e. many of the test methods are failing within the test class on multiple platforms. 

What we expect to see is:
{noformat}
receiver A: ucasts=15
receiver B: ucasts=15
receiver C: ucasts=15
{noformat}

What we instead see is:
{noformat}
receiver A: ucasts=15
receiver B: ucasts=11

ucasts for B: 
B: unicast msg #1 from B B: unicast msg #2 from B B: unicast msg #3 from B B: unicast msg #4 from B B: unicast msg #5 from B 
A: unicast msg #1 from A C: unicast msg #2 from C C: unicast msg #3 from C A: unicast msg #4 from A C: unicast msg #4 from C C: unicast msg #5 from C 
{noformat}

For example, in testWithViewBC, channel A should receive messages #1 through #5 from channels A, B and C, but it does not receive #1 from channel C. 

  was:
OverlappingUnicastMergeTest does the following:

- set up three channels a,b,c with the layers MERGE2, VERIFY_SUSPECT and FC removed
- the receiver of each channel will look at all incoming messages: if mcast, ignore it; if unicast, add to the list of messages received
- inject some new view into the channels which represents a view configuration which should be recovered from
- send messages to the channels and check that the messages are received, despite the  injected view

OverlappingUnicastMergeTest this test is failing in a number of ways (i.e. many of the test methods are failing within the test class on multiple platforms. 

For example, in testWithViewBC, channel A should receive messages #1 through #5 from channels A, B and C, but it does not receive #1 through #3 from channel C. 


    
> OverlappingUnicastMergeTest
> ---------------------------
>
>                 Key: JGRP-1802
>                 URL: https://issues.jboss.org/browse/JGRP-1802
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.2.13
>         Environment: Solaris, RHEL
>            Reporter: Richard Achmatowicz
>            Assignee: Bela Ban
>             Fix For: 3.2.13
>
>
> OverlappingUnicastMergeTest does the following:
> - set up three channels a,b,c with the layers MERGE2, VERIFY_SUSPECT and FC removed
> - the receiver of each channel will look at all incoming messages: if mcast, ignore it; if unicast, add to the list of messages received
> - inject some new view into the channels which represents a view configuration which should be recovered from
> - send messages to the channels and check that the messages are received, despite the  injected view
> OverlappingUnicastMergeTest this test is failing in a number of ways (i.e. many of the test methods are failing within the test class on multiple platforms. 
> What we expect to see is:
> {noformat}
> receiver A: ucasts=15
> receiver B: ucasts=15
> receiver C: ucasts=15
> {noformat}
> What we instead see is:
> {noformat}
> receiver A: ucasts=15
> receiver B: ucasts=11
> ucasts for B: 
> B: unicast msg #1 from B B: unicast msg #2 from B B: unicast msg #3 from B B: unicast msg #4 from B B: unicast msg #5 from B 
> A: unicast msg #1 from A C: unicast msg #2 from C C: unicast msg #3 from C A: unicast msg #4 from A C: unicast msg #4 from C C: unicast msg #5 from C 
> {noformat}
> For example, in testWithViewBC, channel A should receive messages #1 through #5 from channels A, B and C, but it does not receive #1 from channel C. 

--
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

From issues at jboss.org  Fri Mar  7 09:14:33 2014
From: issues at jboss.org (Richard Achmatowicz (JIRA))
Date: Fri, 7 Mar 2014 09:14:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1802) OverlappingUnicastMergeTest
In-Reply-To: <JIRA.12533772.1393856602000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12533772.1393856602000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12533772.1393856602000.12338.1394201673383@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JGRP-1802?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Richard Achmatowicz updated JGRP-1802:
--------------------------------------

    Description: 
OverlappingUnicastMergeTest does the following:

- set up three channels a,b,c with the layers MERGE2, VERIFY_SUSPECT and FC removed
- the receiver of each channel will look at all incoming messages: if mcast, ignore it; if unicast, add to the list of messages received
- inject some new view into the channels which represents a view configuration which should be recovered from
- send messages to the channels and check that the messages are received, despite the  injected view

OverlappingUnicastMergeTest this test is failing in a number of ways (i.e. many of the test methods are failing within the test class on multiple platforms. 

What we expect to see is:
{noformat}
receiver A: ucasts=15
receiver B: ucasts=15
receiver C: ucasts=15
{noformat}

What we instead see is:
{noformat}
receiver A: ucasts=15
receiver B: ucasts=11

ucasts for B: 
B: unicast msg #1 from B B: unicast msg #2 from B B: unicast msg #3 from B B: unicast msg #4 from B B: unicast msg #5 from B  A: unicast msg #1 from A C: unicast msg #2 from C C: unicast msg #3 from C A: unicast msg #4 from A C: unicast msg #4 from C C: unicast msg #5 from C 
{noformat}

The order here is the order in which the unicasts were received from all three senders by the single receiver. For example, in the above, in testWithViewBC, channel A should receive messages #1 through #5 from channels A, B and C, but it does not receive #1 from channel C. 

  was:
OverlappingUnicastMergeTest does the following:

- set up three channels a,b,c with the layers MERGE2, VERIFY_SUSPECT and FC removed
- the receiver of each channel will look at all incoming messages: if mcast, ignore it; if unicast, add to the list of messages received
- inject some new view into the channels which represents a view configuration which should be recovered from
- send messages to the channels and check that the messages are received, despite the  injected view

OverlappingUnicastMergeTest this test is failing in a number of ways (i.e. many of the test methods are failing within the test class on multiple platforms. 

What we expect to see is:
{noformat}
receiver A: ucasts=15
receiver B: ucasts=15
receiver C: ucasts=15
{noformat}

What we instead see is:
{noformat}
receiver A: ucasts=15
receiver B: ucasts=11

ucasts for B: 
B: unicast msg #1 from B B: unicast msg #2 from B B: unicast msg #3 from B B: unicast msg #4 from B B: unicast msg #5 from B 
A: unicast msg #1 from A C: unicast msg #2 from C C: unicast msg #3 from C A: unicast msg #4 from A C: unicast msg #4 from C C: unicast msg #5 from C 
{noformat}

For example, in testWithViewBC, channel A should receive messages #1 through #5 from channels A, B and C, but it does not receive #1 from channel C. 


    
> OverlappingUnicastMergeTest
> ---------------------------
>
>                 Key: JGRP-1802
>                 URL: https://issues.jboss.org/browse/JGRP-1802
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.2.13
>         Environment: Solaris, RHEL
>            Reporter: Richard Achmatowicz
>            Assignee: Bela Ban
>             Fix For: 3.2.13
>
>
> OverlappingUnicastMergeTest does the following:
> - set up three channels a,b,c with the layers MERGE2, VERIFY_SUSPECT and FC removed
> - the receiver of each channel will look at all incoming messages: if mcast, ignore it; if unicast, add to the list of messages received
> - inject some new view into the channels which represents a view configuration which should be recovered from
> - send messages to the channels and check that the messages are received, despite the  injected view
> OverlappingUnicastMergeTest this test is failing in a number of ways (i.e. many of the test methods are failing within the test class on multiple platforms. 
> What we expect to see is:
> {noformat}
> receiver A: ucasts=15
> receiver B: ucasts=15
> receiver C: ucasts=15
> {noformat}
> What we instead see is:
> {noformat}
> receiver A: ucasts=15
> receiver B: ucasts=11
> ucasts for B: 
> B: unicast msg #1 from B B: unicast msg #2 from B B: unicast msg #3 from B B: unicast msg #4 from B B: unicast msg #5 from B  A: unicast msg #1 from A C: unicast msg #2 from C C: unicast msg #3 from C A: unicast msg #4 from A C: unicast msg #4 from C C: unicast msg #5 from C 
> {noformat}
> The order here is the order in which the unicasts were received from all three senders by the single receiver. For example, in the above, in testWithViewBC, channel A should receive messages #1 through #5 from channels A, B and C, but it does not receive #1 from channel C. 

--
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

From issues at jboss.org  Fri Mar  7 09:16:35 2014
From: issues at jboss.org (Stefano Maestri (JIRA))
Date: Fri, 7 Mar 2014 09:16:35 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3084) make statistics-enabled for
 pool and jdbc stats in DataSources model attribute
In-Reply-To: <JIRA.12534409.1394201771767@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534409.1394201771767@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534409.1394201771767.12340.1394201795096@jira02.app.mwc.hst.phx2.redhat.com>

Stefano Maestri created WFLY-3084:
-------------------------------------

             Summary: make statistics-enabled for pool and jdbc stats in DataSources model attribute
                 Key: WFLY-3084
                 URL: https://issues.jboss.org/browse/WFLY-3084
             Project: WildFly
          Issue Type: Task
      Security Level: Public (Everyone can see)
          Components: JCA
            Reporter: Stefano Maestri
            Assignee: Stefano Maestri
             Fix For: 9.0.0.CR1


Pulling up this statsistics-enabled attributes to specific Model attributes fro DataSource will make them marshallable and so will permit to keep statististics-enabled configuration set after server reload

--
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

From issues at jboss.org  Fri Mar  7 09:18:33 2014
From: issues at jboss.org (Richard Achmatowicz (JIRA))
Date: Fri, 7 Mar 2014 09:18:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1802) OverlappingUnicastMergeTest
In-Reply-To: <JIRA.12533772.1393856602000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12533772.1393856602000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12533772.1393856602000.12345.1394201913183@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JGRP-1802?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12951142#comment-12951142 ] 

Richard Achmatowicz commented on JGRP-1802:
-------------------------------------------

Looking at the example above, it seems that message #1 from C is lost even though the message delivery should be FIFO.
Could this be a problem with the receiver code being accessed by multiple threads at the same time? Or is this an example of FIFO delivery being broken?

                
> OverlappingUnicastMergeTest
> ---------------------------
>
>                 Key: JGRP-1802
>                 URL: https://issues.jboss.org/browse/JGRP-1802
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.2.13
>         Environment: Solaris, RHEL
>            Reporter: Richard Achmatowicz
>            Assignee: Bela Ban
>             Fix For: 3.2.13
>
>
> OverlappingUnicastMergeTest does the following:
> - set up three channels a,b,c with the layers MERGE2, VERIFY_SUSPECT and FC removed
> - the receiver of each channel will look at all incoming messages: if mcast, ignore it; if unicast, add to the list of messages received
> - inject some new view into the channels which represents a view configuration which should be recovered from
> - send messages to the channels and check that the messages are received, despite the  injected view
> OverlappingUnicastMergeTest this test is failing in a number of ways (i.e. many of the test methods are failing within the test class on multiple platforms. 
> What we expect to see is:
> {noformat}
> receiver A: ucasts=15
> receiver B: ucasts=15
> receiver C: ucasts=15
> {noformat}
> What we instead see is:
> {noformat}
> receiver A: ucasts=15
> receiver B: ucasts=11
> ucasts for B: 
> B: unicast msg #1 from B B: unicast msg #2 from B B: unicast msg #3 from B B: unicast msg #4 from B B: unicast msg #5 from B  A: unicast msg #1 from A C: unicast msg #2 from C C: unicast msg #3 from C A: unicast msg #4 from A C: unicast msg #4 from C C: unicast msg #5 from C 
> {noformat}
> The order here is the order in which the unicasts were received from all three senders by the single receiver. For example, in the above, in testWithViewBC, channel A should receive messages #1 through #5 from channels A, B and C, but it does not receive #1 from channel C. 

--
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

From issues at jboss.org  Fri Mar  7 09:22:33 2014
From: issues at jboss.org (John Patton (JIRA))
Date: Fri, 7 Mar 2014 09:22:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3051) http-remoting-jmx connection
 failure connecting to Undertow subsystem instead of Undertow management
In-Reply-To: <JIRA.12533723.1393825342000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12533723.1393825342000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12533723.1393825342000.12357.1394202153429@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-3051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12951144#comment-12951144 ] 

John Patton commented on WFLY-3051:
-----------------------------------

I tried the method outlined here, seems to work for me, also!  Any chance this can get added to the documentation?  It wasn't very obvious to configure. :)

Thanks for the help!
                
> http-remoting-jmx connection failure connecting to Undertow subsystem instead of Undertow management
> ----------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-3051
>                 URL: https://issues.jboss.org/browse/WFLY-3051
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JMX, Remoting
>    Affects Versions: 8.0.0.Final
>            Reporter: Rituraj Sinha
>            Assignee: Darran Lofthouse
>            Priority: Critical
>             Fix For: 8.0.1.Final
>
>
> i have gone through the below link for JMX subsystem for wildfly 8 as
> https://docs.jboss.org/author/display/WFLY8/JMX+subsystem+configuration
>  
> but unable to connect to server-instances running remotely ...i have posted my question there as well and pasting it here now ...
> can someone please give us the steps to configure JMX through jconsole...?
> changes done on the domain.xml are the same as stated above
> <subsystem xmlns="urn:jboss:domain:jmx:1.3">
>                 <expose-resolved-model/>
>                 <expose-expression-model/>
>                 <remoting-connector use-management-endpoint="false"/>
>             </subsystem>
> <subsystem xmlns="urn:jboss:domain:jmx:1.3">
>                 <expose-resolved-model/>
>                 <expose-expression-model/>
>                 <remoting-connector use-management-endpoint="false"/>
>             </subsystem>
> as per the jboss-as-jmx_1_3.xsd  its like
> <xs:attribute name="use-management-endpoint" type="xs:boolean" default="true" use="optional" >
>             <xs:annotation>
>                 <xs:documentation>
>                     If true then this connector will use the management endpoint, otherwise it will use the
>                     remoting subsystem endpoint.
>                 </xs:documentation>
>             </xs:annotation>
>         </xs:attribute>
> now if we are making it false then it should be using the remoting endpoint ...now remoting subsystem by default uses ApplicatoinRealm
> i have created application-user and password for the same but when i am trying to connect to remote server-instances its not connecting it....
> below is what i am able to connect to 
> service:jmx:http-remoting-jmx://remote_hostA:9990 --
> Unknown macro: {host A is where my domain_controller is running}
> how can i access the server-instances running on domain_controller
> Unknown macro: {there are three server_instanaces running on HostA with a port offset of 100 each}
> i am trying to connect with the below url as 
> service:jmx:http-remoting-jmx://lremote_hostA:8180
> let me know if something is missing from my side...
> Thanks

--
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

From issues at jboss.org  Fri Mar  7 09:24:34 2014
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Fri, 7 Mar 2014 09:24:34 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3051) http-remoting-jmx connection
 failure connecting to Undertow subsystem instead of Undertow management
In-Reply-To: <JIRA.12533723.1393825342000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12533723.1393825342000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12533723.1393825342000.12374.1394202274436@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-3051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12951145#comment-12951145 ] 

Darran Lofthouse commented on WFLY-3051:
----------------------------------------

Hi [~johnhpatton], this is not a documentation issue it is a bug, a pull request has now been sent to correct the codebase.

In the meantime this issue contains the workaround description for those still hitting this.

                
> http-remoting-jmx connection failure connecting to Undertow subsystem instead of Undertow management
> ----------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-3051
>                 URL: https://issues.jboss.org/browse/WFLY-3051
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JMX, Remoting
>    Affects Versions: 8.0.0.Final
>            Reporter: Rituraj Sinha
>            Assignee: Darran Lofthouse
>            Priority: Critical
>             Fix For: 8.0.1.Final
>
>
> i have gone through the below link for JMX subsystem for wildfly 8 as
> https://docs.jboss.org/author/display/WFLY8/JMX+subsystem+configuration
>  
> but unable to connect to server-instances running remotely ...i have posted my question there as well and pasting it here now ...
> can someone please give us the steps to configure JMX through jconsole...?
> changes done on the domain.xml are the same as stated above
> <subsystem xmlns="urn:jboss:domain:jmx:1.3">
>                 <expose-resolved-model/>
>                 <expose-expression-model/>
>                 <remoting-connector use-management-endpoint="false"/>
>             </subsystem>
> <subsystem xmlns="urn:jboss:domain:jmx:1.3">
>                 <expose-resolved-model/>
>                 <expose-expression-model/>
>                 <remoting-connector use-management-endpoint="false"/>
>             </subsystem>
> as per the jboss-as-jmx_1_3.xsd  its like
> <xs:attribute name="use-management-endpoint" type="xs:boolean" default="true" use="optional" >
>             <xs:annotation>
>                 <xs:documentation>
>                     If true then this connector will use the management endpoint, otherwise it will use the
>                     remoting subsystem endpoint.
>                 </xs:documentation>
>             </xs:annotation>
>         </xs:attribute>
> now if we are making it false then it should be using the remoting endpoint ...now remoting subsystem by default uses ApplicatoinRealm
> i have created application-user and password for the same but when i am trying to connect to remote server-instances its not connecting it....
> below is what i am able to connect to 
> service:jmx:http-remoting-jmx://remote_hostA:9990 --
> Unknown macro: {host A is where my domain_controller is running}
> how can i access the server-instances running on domain_controller
> Unknown macro: {there are three server_instanaces running on HostA with a port offset of 100 each}
> i am trying to connect with the below url as 
> service:jmx:http-remoting-jmx://lremote_hostA:8180
> let me know if something is missing from my side...
> Thanks

--
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

From issues at jboss.org  Fri Mar  7 09:26:33 2014
From: issues at jboss.org (Bela Ban (JIRA))
Date: Fri, 7 Mar 2014 09:26:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1802) OverlappingUnicastMergeTest
In-Reply-To: <JIRA.12533772.1393856602000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12533772.1393856602000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12533772.1393856602000.12377.1394202393195@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JGRP-1802?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12951146#comment-12951146 ] 

Bela Ban commented on JGRP-1802:
--------------------------------

I don't think FIFO delivery is broken: it has worked for a long time and we'd notice this in other tests. But you're right, if a receiver gets messages from multiple senders concurrently, perhaps the receiver ({{receive(Message)}}) screwed it up. This could be similar to NakackTest where the receiver used an unsync'ed array list, which caused some messages to get dropped...
                
> OverlappingUnicastMergeTest
> ---------------------------
>
>                 Key: JGRP-1802
>                 URL: https://issues.jboss.org/browse/JGRP-1802
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.2.13
>         Environment: Solaris, RHEL
>            Reporter: Richard Achmatowicz
>            Assignee: Bela Ban
>             Fix For: 3.2.13
>
>
> OverlappingUnicastMergeTest does the following:
> - set up three channels a,b,c with the layers MERGE2, VERIFY_SUSPECT and FC removed
> - the receiver of each channel will look at all incoming messages: if mcast, ignore it; if unicast, add to the list of messages received
> - inject some new view into the channels which represents a view configuration which should be recovered from
> - send messages to the channels and check that the messages are received, despite the  injected view
> OverlappingUnicastMergeTest this test is failing in a number of ways (i.e. many of the test methods are failing within the test class on multiple platforms. 
> What we expect to see is:
> {noformat}
> receiver A: ucasts=15
> receiver B: ucasts=15
> receiver C: ucasts=15
> {noformat}
> What we instead see is:
> {noformat}
> receiver A: ucasts=15
> receiver B: ucasts=11
> ucasts for B: 
> B: unicast msg #1 from B B: unicast msg #2 from B B: unicast msg #3 from B B: unicast msg #4 from B B: unicast msg #5 from B  A: unicast msg #1 from A C: unicast msg #2 from C C: unicast msg #3 from C A: unicast msg #4 from A C: unicast msg #4 from C C: unicast msg #5 from C 
> {noformat}
> The order here is the order in which the unicasts were received from all three senders by the single receiver. For example, in the above, in testWithViewBC, channel A should receive messages #1 through #5 from channels A, B and C, but it does not receive #1 from channel C. 

--
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

From issues at jboss.org  Fri Mar  7 09:45:34 2014
From: issues at jboss.org (John Patton (JIRA))
Date: Fri, 7 Mar 2014 09:45:34 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3051) http-remoting-jmx connection
 failure connecting to Undertow subsystem instead of Undertow management
In-Reply-To: <JIRA.12533723.1393825342000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12533723.1393825342000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12533723.1393825342000.12431.1394203534343@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-3051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12951154#comment-12951154 ] 

John Patton commented on WFLY-3051:
-----------------------------------

Oh, this is just a workaround... not the recommended approach.  Thanks for working through this!
                
> http-remoting-jmx connection failure connecting to Undertow subsystem instead of Undertow management
> ----------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-3051
>                 URL: https://issues.jboss.org/browse/WFLY-3051
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JMX, Remoting
>    Affects Versions: 8.0.0.Final
>            Reporter: Rituraj Sinha
>            Assignee: Darran Lofthouse
>            Priority: Critical
>             Fix For: 8.0.1.Final
>
>
> i have gone through the below link for JMX subsystem for wildfly 8 as
> https://docs.jboss.org/author/display/WFLY8/JMX+subsystem+configuration
>  
> but unable to connect to server-instances running remotely ...i have posted my question there as well and pasting it here now ...
> can someone please give us the steps to configure JMX through jconsole...?
> changes done on the domain.xml are the same as stated above
> <subsystem xmlns="urn:jboss:domain:jmx:1.3">
>                 <expose-resolved-model/>
>                 <expose-expression-model/>
>                 <remoting-connector use-management-endpoint="false"/>
>             </subsystem>
> <subsystem xmlns="urn:jboss:domain:jmx:1.3">
>                 <expose-resolved-model/>
>                 <expose-expression-model/>
>                 <remoting-connector use-management-endpoint="false"/>
>             </subsystem>
> as per the jboss-as-jmx_1_3.xsd  its like
> <xs:attribute name="use-management-endpoint" type="xs:boolean" default="true" use="optional" >
>             <xs:annotation>
>                 <xs:documentation>
>                     If true then this connector will use the management endpoint, otherwise it will use the
>                     remoting subsystem endpoint.
>                 </xs:documentation>
>             </xs:annotation>
>         </xs:attribute>
> now if we are making it false then it should be using the remoting endpoint ...now remoting subsystem by default uses ApplicatoinRealm
> i have created application-user and password for the same but when i am trying to connect to remote server-instances its not connecting it....
> below is what i am able to connect to 
> service:jmx:http-remoting-jmx://remote_hostA:9990 --
> Unknown macro: {host A is where my domain_controller is running}
> how can i access the server-instances running on domain_controller
> Unknown macro: {there are three server_instanaces running on HostA with a port offset of 100 each}
> i am trying to connect with the below url as 
> service:jmx:http-remoting-jmx://lremote_hostA:8180
> let me know if something is missing from my side...
> Thanks

--
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

From issues at jboss.org  Fri Mar  7 09:51:33 2014
From: issues at jboss.org (Jesper Pedersen (JIRA))
Date: Fri, 7 Mar 2014 09:51:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JBJCA-1152) AllocationRetry is double
	than defined
In-Reply-To: <JIRA.12534415.1394203826692@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534415.1394203826692@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534415.1394203826692.12435.1394203893309@jira02.app.mwc.hst.phx2.redhat.com>

Jesper Pedersen created JBJCA-1152:
--------------------------------------

             Summary: AllocationRetry is double than defined
                 Key: JBJCA-1152
                 URL: https://issues.jboss.org/browse/JBJCA-1152
             Project: IronJacamar
          Issue Type: Bug
          Components: Core
    Affects Versions: 1.1.3.Final
            Reporter: Jesper Pedersen
            Assignee: Jesper Pedersen
             Fix For: 1.1.4.Final, 1.2.0.Beta1




--
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

From issues at jboss.org  Fri Mar  7 10:07:34 2014
From: issues at jboss.org (Jesper Pedersen (JIRA))
Date: Fri, 7 Mar 2014 10:07:34 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JBJCA-1152) AllocationRetry is double
	than defined
In-Reply-To: <JIRA.12534415.1394203826000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534415.1394203826000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534415.1394203826000.12480.1394204854476@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBJCA-1152?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jesper Pedersen resolved JBJCA-1152.
------------------------------------

    Resolution: Done

    
> AllocationRetry is double than defined
> --------------------------------------
>
>                 Key: JBJCA-1152
>                 URL: https://issues.jboss.org/browse/JBJCA-1152
>             Project: IronJacamar
>          Issue Type: Bug
>          Components: Core
>    Affects Versions: 1.1.3.Final
>            Reporter: Jesper Pedersen
>            Assignee: Jesper Pedersen
>             Fix For: 1.1.4.Final, 1.2.0.Beta1
>
>


--
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

From issues at jboss.org  Fri Mar  7 10:23:33 2014
From: issues at jboss.org (Alexey Loubyansky (JIRA))
Date: Fri, 7 Mar 2014 10:23:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3085) updating non existing and
 adding existing misc content with override on
In-Reply-To: <JIRA.12534425.1394205773844@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534425.1394205773844@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534425.1394205773844.12601.1394205813707@jira02.app.mwc.hst.phx2.redhat.com>

Alexey Loubyansky created WFLY-3085:
---------------------------------------

             Summary: updating non existing and adding existing misc content with override on
                 Key: WFLY-3085
                 URL: https://issues.jboss.org/browse/WFLY-3085
             Project: WildFly
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Patching
            Reporter: Alexey Loubyansky
            Assignee: Alexey Loubyansky


Rolling back a patch applied with override on which had an instruction to add a misc content that had existed before will fail because the opposite rolling back action for ADD is assumed to be REMOVE while in this case it has to be MODIFY to rollback to the previous version of the misc content.

A similar scenario will fail for the file update task. I.e. rolling back a patch applied with override on which had an instruction to modify a non-existing misc content will fail.

--
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

From issues at jboss.org  Fri Mar  7 10:54:33 2014
From: issues at jboss.org (Richard Achmatowicz (JIRA))
Date: Fri, 7 Mar 2014 10:54:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1802) OverlappingUnicastMergeTest
In-Reply-To: <JIRA.12533772.1393856602000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12533772.1393856602000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12533772.1393856602000.12796.1394207673509@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JGRP-1802?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Richard Achmatowicz updated JGRP-1802:
--------------------------------------

    Git Pull Request: https://github.com/belaban/JGroups/pull/129

    
> OverlappingUnicastMergeTest
> ---------------------------
>
>                 Key: JGRP-1802
>                 URL: https://issues.jboss.org/browse/JGRP-1802
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.2.13
>         Environment: Solaris, RHEL
>            Reporter: Richard Achmatowicz
>            Assignee: Bela Ban
>             Fix For: 3.2.13
>
>
> OverlappingUnicastMergeTest does the following:
> - set up three channels a,b,c with the layers MERGE2, VERIFY_SUSPECT and FC removed
> - the receiver of each channel will look at all incoming messages: if mcast, ignore it; if unicast, add to the list of messages received
> - inject some new view into the channels which represents a view configuration which should be recovered from
> - send messages to the channels and check that the messages are received, despite the  injected view
> OverlappingUnicastMergeTest this test is failing in a number of ways (i.e. many of the test methods are failing within the test class on multiple platforms. 
> What we expect to see is:
> {noformat}
> receiver A: ucasts=15
> receiver B: ucasts=15
> receiver C: ucasts=15
> {noformat}
> What we instead see is:
> {noformat}
> receiver A: ucasts=15
> receiver B: ucasts=11
> ucasts for B: 
> B: unicast msg #1 from B B: unicast msg #2 from B B: unicast msg #3 from B B: unicast msg #4 from B B: unicast msg #5 from B  A: unicast msg #1 from A C: unicast msg #2 from C C: unicast msg #3 from C A: unicast msg #4 from A C: unicast msg #4 from C C: unicast msg #5 from C 
> {noformat}
> The order here is the order in which the unicasts were received from all three senders by the single receiver. For example, in the above, in testWithViewBC, channel A should receive messages #1 through #5 from channels A, B and C, but it does not receive #1 from channel C. 

--
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

From issues at jboss.org  Fri Mar  7 10:54:33 2014
From: issues at jboss.org (Richard Achmatowicz (JIRA))
Date: Fri, 7 Mar 2014 10:54:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1802) OverlappingUnicastMergeTest
 fails to receive all messages
In-Reply-To: <JIRA.12533772.1393856602000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12533772.1393856602000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12533772.1393856602000.12801.1394207673743@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JGRP-1802?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Richard Achmatowicz updated JGRP-1802:
--------------------------------------

    Summary: OverlappingUnicastMergeTest fails to receive all messages  (was: OverlappingUnicastMergeTest)

    
> OverlappingUnicastMergeTest fails to receive all messages
> ---------------------------------------------------------
>
>                 Key: JGRP-1802
>                 URL: https://issues.jboss.org/browse/JGRP-1802
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.2.13
>         Environment: Solaris, RHEL
>            Reporter: Richard Achmatowicz
>            Assignee: Bela Ban
>             Fix For: 3.2.13
>
>
> OverlappingUnicastMergeTest does the following:
> - set up three channels a,b,c with the layers MERGE2, VERIFY_SUSPECT and FC removed
> - the receiver of each channel will look at all incoming messages: if mcast, ignore it; if unicast, add to the list of messages received
> - inject some new view into the channels which represents a view configuration which should be recovered from
> - send messages to the channels and check that the messages are received, despite the  injected view
> OverlappingUnicastMergeTest this test is failing in a number of ways (i.e. many of the test methods are failing within the test class on multiple platforms. 
> What we expect to see is:
> {noformat}
> receiver A: ucasts=15
> receiver B: ucasts=15
> receiver C: ucasts=15
> {noformat}
> What we instead see is:
> {noformat}
> receiver A: ucasts=15
> receiver B: ucasts=11
> ucasts for B: 
> B: unicast msg #1 from B B: unicast msg #2 from B B: unicast msg #3 from B B: unicast msg #4 from B B: unicast msg #5 from B  A: unicast msg #1 from A C: unicast msg #2 from C C: unicast msg #3 from C A: unicast msg #4 from A C: unicast msg #4 from C C: unicast msg #5 from C 
> {noformat}
> The order here is the order in which the unicasts were received from all three senders by the single receiver. For example, in the above, in testWithViewBC, channel A should receive messages #1 through #5 from channels A, B and C, but it does not receive #1 from channel C. 

--
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

From issues at jboss.org  Fri Mar  7 11:45:33 2014
From: issues at jboss.org (Bela Ban (JIRA))
Date: Fri, 7 Mar 2014 11:45:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1722) Improve performance of
	ENCRYPT protocol
In-Reply-To: <JIRA.12508426.1382426974000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508426.1382426974000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508426.1382426974000.12915.1394210733363@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JGRP-1722?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12951228#comment-12951228 ] 

Bela Ban commented on JGRP-1722:
--------------------------------

Somewhat disappointing, but it looks as if the perf of ENCRYPT is largely a function of the speed of encryption and decryption. Adding a cipher pool didn't really improve performance for regular messages, but should improve it for {{OOB | DONT_BUNDLE}} messages.
Parallelization (e.g. concurrent decryption of all messages of a message batch) didn't help, either. The reason is that introducing yet another thread pool probably cancelled out the gains made, through increased context switching. I'll revisit this when baselining JGroups on JDK 7 where a shared fork-join thread pool can be used.
Also, uisng the asynchronous invocation API of JGroups would help as the encryption of the response would not have to be done on the same thread as the request, speeding of processing of message batches.
I'm resolving this for now, but I'm having a chat with Tristan to see if we can use a faster cipher...
                
> Improve performance of ENCRYPT protocol
> ---------------------------------------
>
>                 Key: JGRP-1722
>                 URL: https://issues.jboss.org/browse/JGRP-1722
>             Project: JGroups
>          Issue Type: Enhancement
>    Affects Versions: 3.4
>            Reporter: Martin Gencur
>            Assignee: Bela Ban
>             Fix For: 3.5
>
>
> A stress tests with the following setup showed that performance (reads and writes/sec) is halved when ENCRYPT protocol is enabled:
> Infinispan had distributed sync cache with 2 owners on 4 nodes, no transactions. The stress test used 10 threads on each node accessing 1024 byte entries, no conflicts on keys, 20 % writes, 80 % reads. 
> It would be great if we could improve the performance of ENCRYPT protocol.

--
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

From issues at jboss.org  Fri Mar  7 11:47:42 2014
From: issues at jboss.org (Bela Ban (JIRA))
Date: Fri, 7 Mar 2014 11:47:42 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1722) Improve performance of
	ENCRYPT protocol
In-Reply-To: <JIRA.12508426.1382426974000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508426.1382426974000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508426.1382426974000.12921.1394210862340@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JGRP-1722?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban resolved JGRP-1722.
----------------------------

    Resolution: Done

    
> Improve performance of ENCRYPT protocol
> ---------------------------------------
>
>                 Key: JGRP-1722
>                 URL: https://issues.jboss.org/browse/JGRP-1722
>             Project: JGroups
>          Issue Type: Enhancement
>    Affects Versions: 3.4
>            Reporter: Martin Gencur
>            Assignee: Bela Ban
>             Fix For: 3.5
>
>
> A stress tests with the following setup showed that performance (reads and writes/sec) is halved when ENCRYPT protocol is enabled:
> Infinispan had distributed sync cache with 2 owners on 4 nodes, no transactions. The stress test used 10 threads on each node accessing 1024 byte entries, no conflicts on keys, 20 % writes, 80 % reads. 
> It would be great if we could improve the performance of ENCRYPT protocol.

--
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

From issues at jboss.org  Fri Mar  7 12:01:35 2014
From: issues at jboss.org (Alessio Soldano (JIRA))
Date: Fri, 7 Mar 2014 12:01:35 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3086) Upgrade to JBossWS 4.3.0.CR2
In-Reply-To: <JIRA.12534444.1394211603945@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534444.1394211603945@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534444.1394211603945.12948.1394211695110@jira02.app.mwc.hst.phx2.redhat.com>

Alessio Soldano created WFLY-3086:
-------------------------------------

             Summary: Upgrade to JBossWS 4.3.0.CR2
                 Key: WFLY-3086
                 URL: https://issues.jboss.org/browse/WFLY-3086
             Project: WildFly
          Issue Type: Component  Upgrade
      Security Level: Public (Everyone can see)
          Components: Web Services
            Reporter: Alessio Soldano
            Assignee: Alessio Soldano
             Fix For: 9.0.0.CR1




--
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

From issues at jboss.org  Fri Mar  7 12:09:33 2014
From: issues at jboss.org (John O'Hara (JIRA))
Date: Fri, 7 Mar 2014 12:09:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3055) Ability to configure a prefix
 to the domain server launch command
In-Reply-To: <JIRA.12533819.1393870966000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12533819.1393870966000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12533819.1393870966000.12963.1394212173503@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-3055?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12951240#comment-12951240 ] 

John O'Hara commented on WFLY-3055:
-----------------------------------

Feature implemented in: https://github.com/johnaoahra80/wildfly/tree/WFLY-3055

Waiting for confirmation of optimal location in schema to define the launch command prefix before submitting PR
                
> Ability to configure a prefix to the domain server launch command
> -----------------------------------------------------------------
>
>                 Key: WFLY-3055
>                 URL: https://issues.jboss.org/browse/WFLY-3055
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>            Reporter: Brian Stansberry
>            Assignee: John O'Hara
>             Fix For: 9.0.0.CR1
>
>
> Ability to configure a prefix to the 'java' command used to launch a domain server. This would be a general purpose feature but some intended uses we'd want to make sure work include:
> 1) NUMA settings, e.g.
> numactl --membind 0 --cpubind 0
> 2) Having the server process run under a different user, e.g.
> sudo joe

--
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

From issues at jboss.org  Fri Mar  7 12:42:33 2014
From: issues at jboss.org (Bela Ban (JIRA))
Date: Fri, 7 Mar 2014 12:42:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1804) UDP: sending of multicasts
 fails after an ifdown / ifup cycle
In-Reply-To: <JIRA.12533967.1393947510000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12533967.1393947510000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12533967.1393947510000.13192.1394214153743@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JGRP-1804?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban resolved JGRP-1804.
----------------------------

    Resolution: Done

    
> UDP: sending of multicasts fails after an ifdown / ifup cycle
> -------------------------------------------------------------
>
>                 Key: JGRP-1804
>                 URL: https://issues.jboss.org/browse/JGRP-1804
>             Project: JGroups
>          Issue Type: Bug
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 3.5
>
>
> After an ifdown / if up cycle, sending / receiving of multicast messages over mcast_sock fails with an IOException (no such device). Sending / receiving unicast datagram packets works.
> SOLUTION:
> Catch the IOException on the send/receive and set the interface again ({{MulticastSocket.setInterface()}}). This was confirmed to work.
> Perhaps count the number of failures and only reset the interface when the count exceeds a threshold

--
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

From issues at jboss.org  Fri Mar  7 13:02:33 2014
From: issues at jboss.org (Admin FlirtyMob (JIRA))
Date: Fri, 7 Mar 2014 13:02:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3087) Websocket
 NullPointerException on
 io.undertow.websockets.jsr.annotated.AnnotatedEndpoint$AnnotatedEndpointFrameHandler.handleBinaryMessage(AnnotatedEndpoint.java:373)
In-Reply-To: <JIRA.12534452.1394215322949@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534452.1394215322949@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534452.1394215322949.13240.1394215353953@jira02.app.mwc.hst.phx2.redhat.com>

Admin FlirtyMob created WFLY-3087:
-------------------------------------

             Summary: Websocket NullPointerException on io.undertow.websockets.jsr.annotated.AnnotatedEndpoint$AnnotatedEndpointFrameHandler.handleBinaryMessage(AnnotatedEndpoint.java:373)
                 Key: WFLY-3087
                 URL: https://issues.jboss.org/browse/WFLY-3087
             Project: WildFly
          Issue Type: Bug
      Security Level: Public (Everyone can see)
         Environment: windows server 2008
            Reporter: Admin FlirtyMob


2014-03-07 17:10:49,208 ERROR [org.xnio.listener] (default I/O-1) XNIO001007: A channel event listener threw an exception: java.lang.NullPointerException
at io.undertow.websockets.jsr.annotated.AnnotatedEndpoint$AnnotatedEndpointFrameHandler.handleBinaryMessage(AnnotatedEndpoint.java:373)
at io.undertow.websockets.jsr.annotated.AnnotatedEndpoint$AnnotatedEndpointFrameHandler.access$1100(AnnotatedEndpoint.java:126)
at io.undertow.websockets.jsr.annotated.AnnotatedEndpoint$AnnotatedEndpointFrameHandler$6.complete(AnnotatedEndpoint.java:332)
at io.undertow.websockets.jsr.annotated.AnnotatedEndpoint$AnnotatedEndpointFrameHandler$6.complete(AnnotatedEndpoint.java:329)
at io.undertow.websockets.core.BufferedBinaryMessage.read(BufferedBinaryMessage.java:76)
at io.undertow.websockets.jsr.annotated.AnnotatedEndpoint$AnnotatedEndpointFrameHandler.onBinary(AnnotatedEndpoint.java:329)
at io.undertow.websockets.core.AbstractReceiveListener.handleEvent(AbstractReceiveListener.java:24)
at io.undertow.websockets.core.AbstractReceiveListener.handleEvent(AbstractReceiveListener.java:15)
at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) [xnio-api-3.2.0.Beta4.jar:3.2.0.Beta4]
at io.undertow.server.protocol.framed.AbstractFramedChannel$FrameReadListener.handleEvent(AbstractFramedChannel.java:615)
at io.undertow.server.protocol.framed.AbstractFramedChannel$FrameReadListener.handleEvent(AbstractFramedChannel.java:601)
at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) [xnio-api-3.2.0.Beta4.jar:3.2.0.Beta4]
at org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66) [xnio-api-3.2.0.Beta4.jar:3.2.0.Beta4]
at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:87) [xnio-nio-3.2.0.Beta4.jar:3.2.0.Beta4]
at org.xnio.nio.WorkerThread.run(WorkerThread.java:531) [xnio-nio-3.2.0.Beta4.jar:3.2.0.Beta4]

--
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

From issues at jboss.org  Fri Mar  7 13:10:33 2014
From: issues at jboss.org (Admin FlirtyMob (JIRA))
Date: Fri, 7 Mar 2014 13:10:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3087) Websocket
 NullPointerException on
 io.undertow.websockets.jsr.annotated.AnnotatedEndpoint$AnnotatedEndpointFrameHandler.handleBinaryMessage(AnnotatedEndpoint.java:373)
In-Reply-To: <JIRA.12534452.1394215322000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534452.1394215322000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534452.1394215322000.13263.1394215833122@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-3087?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12951262#comment-12951262 ] 

Admin FlirtyMob commented on WFLY-3087:
---------------------------------------

We get this issue systematically trying to use websockets over a given 3G connection. Works well when we are over wifi. The carrier network probably alters the message but the server should fail gracefully or send a warning
                
> Websocket NullPointerException on io.undertow.websockets.jsr.annotated.AnnotatedEndpoint$AnnotatedEndpointFrameHandler.handleBinaryMessage(AnnotatedEndpoint.java:373)
> ----------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-3087
>                 URL: https://issues.jboss.org/browse/WFLY-3087
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>         Environment: windows server 2008
>            Reporter: Admin FlirtyMob
>
> 2014-03-07 17:10:49,208 ERROR [org.xnio.listener] (default I/O-1) XNIO001007: A channel event listener threw an exception: java.lang.NullPointerException
> at io.undertow.websockets.jsr.annotated.AnnotatedEndpoint$AnnotatedEndpointFrameHandler.handleBinaryMessage(AnnotatedEndpoint.java:373)
> at io.undertow.websockets.jsr.annotated.AnnotatedEndpoint$AnnotatedEndpointFrameHandler.access$1100(AnnotatedEndpoint.java:126)
> at io.undertow.websockets.jsr.annotated.AnnotatedEndpoint$AnnotatedEndpointFrameHandler$6.complete(AnnotatedEndpoint.java:332)
> at io.undertow.websockets.jsr.annotated.AnnotatedEndpoint$AnnotatedEndpointFrameHandler$6.complete(AnnotatedEndpoint.java:329)
> at io.undertow.websockets.core.BufferedBinaryMessage.read(BufferedBinaryMessage.java:76)
> at io.undertow.websockets.jsr.annotated.AnnotatedEndpoint$AnnotatedEndpointFrameHandler.onBinary(AnnotatedEndpoint.java:329)
> at io.undertow.websockets.core.AbstractReceiveListener.handleEvent(AbstractReceiveListener.java:24)
> at io.undertow.websockets.core.AbstractReceiveListener.handleEvent(AbstractReceiveListener.java:15)
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) [xnio-api-3.2.0.Beta4.jar:3.2.0.Beta4]
> at io.undertow.server.protocol.framed.AbstractFramedChannel$FrameReadListener.handleEvent(AbstractFramedChannel.java:615)
> at io.undertow.server.protocol.framed.AbstractFramedChannel$FrameReadListener.handleEvent(AbstractFramedChannel.java:601)
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) [xnio-api-3.2.0.Beta4.jar:3.2.0.Beta4]
> at org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66) [xnio-api-3.2.0.Beta4.jar:3.2.0.Beta4]
> at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:87) [xnio-nio-3.2.0.Beta4.jar:3.2.0.Beta4]
> at org.xnio.nio.WorkerThread.run(WorkerThread.java:531) [xnio-nio-3.2.0.Beta4.jar:3.2.0.Beta4]

--
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

From issues at jboss.org  Fri Mar  7 13:28:33 2014
From: issues at jboss.org (Tomaz Cerar (JIRA))
Date: Fri, 7 Mar 2014 13:28:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3087) Websocket
 NullPointerException on
 io.undertow.websockets.jsr.annotated.AnnotatedEndpoint$AnnotatedEndpointFrameHandler.handleBinaryMessage(AnnotatedEndpoint.java:373)
In-Reply-To: <JIRA.12534452.1394215322000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534452.1394215322000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534452.1394215322000.13270.1394216913445@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-3087?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12951264#comment-12951264 ] 

Tomaz Cerar commented on WFLY-3087:
-----------------------------------

Can you try to reproduce this on WildFly 8.0.0.Final?
                
> Websocket NullPointerException on io.undertow.websockets.jsr.annotated.AnnotatedEndpoint$AnnotatedEndpointFrameHandler.handleBinaryMessage(AnnotatedEndpoint.java:373)
> ----------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-3087
>                 URL: https://issues.jboss.org/browse/WFLY-3087
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>         Environment: windows server 2008
>            Reporter: Admin FlirtyMob
>
> 2014-03-07 17:10:49,208 ERROR [org.xnio.listener] (default I/O-1) XNIO001007: A channel event listener threw an exception: java.lang.NullPointerException
> at io.undertow.websockets.jsr.annotated.AnnotatedEndpoint$AnnotatedEndpointFrameHandler.handleBinaryMessage(AnnotatedEndpoint.java:373)
> at io.undertow.websockets.jsr.annotated.AnnotatedEndpoint$AnnotatedEndpointFrameHandler.access$1100(AnnotatedEndpoint.java:126)
> at io.undertow.websockets.jsr.annotated.AnnotatedEndpoint$AnnotatedEndpointFrameHandler$6.complete(AnnotatedEndpoint.java:332)
> at io.undertow.websockets.jsr.annotated.AnnotatedEndpoint$AnnotatedEndpointFrameHandler$6.complete(AnnotatedEndpoint.java:329)
> at io.undertow.websockets.core.BufferedBinaryMessage.read(BufferedBinaryMessage.java:76)
> at io.undertow.websockets.jsr.annotated.AnnotatedEndpoint$AnnotatedEndpointFrameHandler.onBinary(AnnotatedEndpoint.java:329)
> at io.undertow.websockets.core.AbstractReceiveListener.handleEvent(AbstractReceiveListener.java:24)
> at io.undertow.websockets.core.AbstractReceiveListener.handleEvent(AbstractReceiveListener.java:15)
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) [xnio-api-3.2.0.Beta4.jar:3.2.0.Beta4]
> at io.undertow.server.protocol.framed.AbstractFramedChannel$FrameReadListener.handleEvent(AbstractFramedChannel.java:615)
> at io.undertow.server.protocol.framed.AbstractFramedChannel$FrameReadListener.handleEvent(AbstractFramedChannel.java:601)
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) [xnio-api-3.2.0.Beta4.jar:3.2.0.Beta4]
> at org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66) [xnio-api-3.2.0.Beta4.jar:3.2.0.Beta4]
> at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:87) [xnio-nio-3.2.0.Beta4.jar:3.2.0.Beta4]
> at org.xnio.nio.WorkerThread.run(WorkerThread.java:531) [xnio-nio-3.2.0.Beta4.jar:3.2.0.Beta4]

--
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

From issues at jboss.org  Fri Mar  7 13:28:33 2014
From: issues at jboss.org (Tomaz Cerar (JIRA))
Date: Fri, 7 Mar 2014 13:28:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3087) Websocket
 NullPointerException on
 io.undertow.websockets.jsr.annotated.AnnotatedEndpoint$AnnotatedEndpointFrameHandler.handleBinaryMessage(AnnotatedEndpoint.java:373)
In-Reply-To: <JIRA.12534452.1394215322000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534452.1394215322000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534452.1394215322000.13272.1394216913536@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-3087?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tomaz Cerar updated WFLY-3087:
------------------------------

    Component/s: Web (Undertow)

    
> Websocket NullPointerException on io.undertow.websockets.jsr.annotated.AnnotatedEndpoint$AnnotatedEndpointFrameHandler.handleBinaryMessage(AnnotatedEndpoint.java:373)
> ----------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-3087
>                 URL: https://issues.jboss.org/browse/WFLY-3087
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web (Undertow)
>         Environment: windows server 2008
>            Reporter: Admin FlirtyMob
>
> 2014-03-07 17:10:49,208 ERROR [org.xnio.listener] (default I/O-1) XNIO001007: A channel event listener threw an exception: java.lang.NullPointerException
> at io.undertow.websockets.jsr.annotated.AnnotatedEndpoint$AnnotatedEndpointFrameHandler.handleBinaryMessage(AnnotatedEndpoint.java:373)
> at io.undertow.websockets.jsr.annotated.AnnotatedEndpoint$AnnotatedEndpointFrameHandler.access$1100(AnnotatedEndpoint.java:126)
> at io.undertow.websockets.jsr.annotated.AnnotatedEndpoint$AnnotatedEndpointFrameHandler$6.complete(AnnotatedEndpoint.java:332)
> at io.undertow.websockets.jsr.annotated.AnnotatedEndpoint$AnnotatedEndpointFrameHandler$6.complete(AnnotatedEndpoint.java:329)
> at io.undertow.websockets.core.BufferedBinaryMessage.read(BufferedBinaryMessage.java:76)
> at io.undertow.websockets.jsr.annotated.AnnotatedEndpoint$AnnotatedEndpointFrameHandler.onBinary(AnnotatedEndpoint.java:329)
> at io.undertow.websockets.core.AbstractReceiveListener.handleEvent(AbstractReceiveListener.java:24)
> at io.undertow.websockets.core.AbstractReceiveListener.handleEvent(AbstractReceiveListener.java:15)
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) [xnio-api-3.2.0.Beta4.jar:3.2.0.Beta4]
> at io.undertow.server.protocol.framed.AbstractFramedChannel$FrameReadListener.handleEvent(AbstractFramedChannel.java:615)
> at io.undertow.server.protocol.framed.AbstractFramedChannel$FrameReadListener.handleEvent(AbstractFramedChannel.java:601)
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) [xnio-api-3.2.0.Beta4.jar:3.2.0.Beta4]
> at org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66) [xnio-api-3.2.0.Beta4.jar:3.2.0.Beta4]
> at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:87) [xnio-nio-3.2.0.Beta4.jar:3.2.0.Beta4]
> at org.xnio.nio.WorkerThread.run(WorkerThread.java:531) [xnio-nio-3.2.0.Beta4.jar:3.2.0.Beta4]

--
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

From issues at jboss.org  Fri Mar  7 13:28:33 2014
From: issues at jboss.org (Tomaz Cerar (JIRA))
Date: Fri, 7 Mar 2014 13:28:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3087) Websocket
 NullPointerException on
 io.undertow.websockets.jsr.annotated.AnnotatedEndpoint$AnnotatedEndpointFrameHandler.handleBinaryMessage(AnnotatedEndpoint.java:373)
In-Reply-To: <JIRA.12534452.1394215322000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534452.1394215322000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534452.1394215322000.13278.1394216913765@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-3087?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tomaz Cerar updated WFLY-3087:
------------------------------

    Affects Version/s: 8.0.0.CR1

    
> Websocket NullPointerException on io.undertow.websockets.jsr.annotated.AnnotatedEndpoint$AnnotatedEndpointFrameHandler.handleBinaryMessage(AnnotatedEndpoint.java:373)
> ----------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-3087
>                 URL: https://issues.jboss.org/browse/WFLY-3087
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web (Undertow)
>    Affects Versions: 8.0.0.CR1
>         Environment: windows server 2008
>            Reporter: Admin FlirtyMob
>
> 2014-03-07 17:10:49,208 ERROR [org.xnio.listener] (default I/O-1) XNIO001007: A channel event listener threw an exception: java.lang.NullPointerException
> at io.undertow.websockets.jsr.annotated.AnnotatedEndpoint$AnnotatedEndpointFrameHandler.handleBinaryMessage(AnnotatedEndpoint.java:373)
> at io.undertow.websockets.jsr.annotated.AnnotatedEndpoint$AnnotatedEndpointFrameHandler.access$1100(AnnotatedEndpoint.java:126)
> at io.undertow.websockets.jsr.annotated.AnnotatedEndpoint$AnnotatedEndpointFrameHandler$6.complete(AnnotatedEndpoint.java:332)
> at io.undertow.websockets.jsr.annotated.AnnotatedEndpoint$AnnotatedEndpointFrameHandler$6.complete(AnnotatedEndpoint.java:329)
> at io.undertow.websockets.core.BufferedBinaryMessage.read(BufferedBinaryMessage.java:76)
> at io.undertow.websockets.jsr.annotated.AnnotatedEndpoint$AnnotatedEndpointFrameHandler.onBinary(AnnotatedEndpoint.java:329)
> at io.undertow.websockets.core.AbstractReceiveListener.handleEvent(AbstractReceiveListener.java:24)
> at io.undertow.websockets.core.AbstractReceiveListener.handleEvent(AbstractReceiveListener.java:15)
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) [xnio-api-3.2.0.Beta4.jar:3.2.0.Beta4]
> at io.undertow.server.protocol.framed.AbstractFramedChannel$FrameReadListener.handleEvent(AbstractFramedChannel.java:615)
> at io.undertow.server.protocol.framed.AbstractFramedChannel$FrameReadListener.handleEvent(AbstractFramedChannel.java:601)
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) [xnio-api-3.2.0.Beta4.jar:3.2.0.Beta4]
> at org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66) [xnio-api-3.2.0.Beta4.jar:3.2.0.Beta4]
> at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:87) [xnio-nio-3.2.0.Beta4.jar:3.2.0.Beta4]
> at org.xnio.nio.WorkerThread.run(WorkerThread.java:531) [xnio-nio-3.2.0.Beta4.jar:3.2.0.Beta4]

--
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

From issues at jboss.org  Fri Mar  7 13:28:33 2014
From: issues at jboss.org (Tomaz Cerar (JIRA))
Date: Fri, 7 Mar 2014 13:28:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3087) Websocket
 NullPointerException on
 io.undertow.websockets.jsr.annotated.AnnotatedEndpoint$AnnotatedEndpointFrameHandler.handleBinaryMessage(AnnotatedEndpoint.java:373)
In-Reply-To: <JIRA.12534452.1394215322000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534452.1394215322000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534452.1394215322000.13281.1394216913907@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-3087?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tomaz Cerar reassigned WFLY-3087:
---------------------------------

    Assignee: Tomaz Cerar

    
> Websocket NullPointerException on io.undertow.websockets.jsr.annotated.AnnotatedEndpoint$AnnotatedEndpointFrameHandler.handleBinaryMessage(AnnotatedEndpoint.java:373)
> ----------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-3087
>                 URL: https://issues.jboss.org/browse/WFLY-3087
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web (Undertow)
>    Affects Versions: 8.0.0.CR1
>         Environment: windows server 2008
>            Reporter: Admin FlirtyMob
>            Assignee: Tomaz Cerar
>
> 2014-03-07 17:10:49,208 ERROR [org.xnio.listener] (default I/O-1) XNIO001007: A channel event listener threw an exception: java.lang.NullPointerException
> at io.undertow.websockets.jsr.annotated.AnnotatedEndpoint$AnnotatedEndpointFrameHandler.handleBinaryMessage(AnnotatedEndpoint.java:373)
> at io.undertow.websockets.jsr.annotated.AnnotatedEndpoint$AnnotatedEndpointFrameHandler.access$1100(AnnotatedEndpoint.java:126)
> at io.undertow.websockets.jsr.annotated.AnnotatedEndpoint$AnnotatedEndpointFrameHandler$6.complete(AnnotatedEndpoint.java:332)
> at io.undertow.websockets.jsr.annotated.AnnotatedEndpoint$AnnotatedEndpointFrameHandler$6.complete(AnnotatedEndpoint.java:329)
> at io.undertow.websockets.core.BufferedBinaryMessage.read(BufferedBinaryMessage.java:76)
> at io.undertow.websockets.jsr.annotated.AnnotatedEndpoint$AnnotatedEndpointFrameHandler.onBinary(AnnotatedEndpoint.java:329)
> at io.undertow.websockets.core.AbstractReceiveListener.handleEvent(AbstractReceiveListener.java:24)
> at io.undertow.websockets.core.AbstractReceiveListener.handleEvent(AbstractReceiveListener.java:15)
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) [xnio-api-3.2.0.Beta4.jar:3.2.0.Beta4]
> at io.undertow.server.protocol.framed.AbstractFramedChannel$FrameReadListener.handleEvent(AbstractFramedChannel.java:615)
> at io.undertow.server.protocol.framed.AbstractFramedChannel$FrameReadListener.handleEvent(AbstractFramedChannel.java:601)
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) [xnio-api-3.2.0.Beta4.jar:3.2.0.Beta4]
> at org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66) [xnio-api-3.2.0.Beta4.jar:3.2.0.Beta4]
> at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:87) [xnio-nio-3.2.0.Beta4.jar:3.2.0.Beta4]
> at org.xnio.nio.WorkerThread.run(WorkerThread.java:531) [xnio-nio-3.2.0.Beta4.jar:3.2.0.Beta4]

--
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

From issues at jboss.org  Fri Mar  7 13:28:34 2014
From: issues at jboss.org (Tomaz Cerar (JIRA))
Date: Fri, 7 Mar 2014 13:28:34 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3087) Websocket
 NullPointerException on
 io.undertow.websockets.jsr.annotated.AnnotatedEndpoint$AnnotatedEndpointFrameHandler.handleBinaryMessage(AnnotatedEndpoint.java:373)
In-Reply-To: <JIRA.12534452.1394215322000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534452.1394215322000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534452.1394215322000.13287.1394216914154@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-3087?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tomaz Cerar reassigned WFLY-3087:
---------------------------------

    Assignee: Stuart Douglas  (was: Tomaz Cerar)

    
> Websocket NullPointerException on io.undertow.websockets.jsr.annotated.AnnotatedEndpoint$AnnotatedEndpointFrameHandler.handleBinaryMessage(AnnotatedEndpoint.java:373)
> ----------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-3087
>                 URL: https://issues.jboss.org/browse/WFLY-3087
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web (Undertow)
>    Affects Versions: 8.0.0.CR1
>         Environment: windows server 2008
>            Reporter: Admin FlirtyMob
>            Assignee: Stuart Douglas
>
> 2014-03-07 17:10:49,208 ERROR [org.xnio.listener] (default I/O-1) XNIO001007: A channel event listener threw an exception: java.lang.NullPointerException
> at io.undertow.websockets.jsr.annotated.AnnotatedEndpoint$AnnotatedEndpointFrameHandler.handleBinaryMessage(AnnotatedEndpoint.java:373)
> at io.undertow.websockets.jsr.annotated.AnnotatedEndpoint$AnnotatedEndpointFrameHandler.access$1100(AnnotatedEndpoint.java:126)
> at io.undertow.websockets.jsr.annotated.AnnotatedEndpoint$AnnotatedEndpointFrameHandler$6.complete(AnnotatedEndpoint.java:332)
> at io.undertow.websockets.jsr.annotated.AnnotatedEndpoint$AnnotatedEndpointFrameHandler$6.complete(AnnotatedEndpoint.java:329)
> at io.undertow.websockets.core.BufferedBinaryMessage.read(BufferedBinaryMessage.java:76)
> at io.undertow.websockets.jsr.annotated.AnnotatedEndpoint$AnnotatedEndpointFrameHandler.onBinary(AnnotatedEndpoint.java:329)
> at io.undertow.websockets.core.AbstractReceiveListener.handleEvent(AbstractReceiveListener.java:24)
> at io.undertow.websockets.core.AbstractReceiveListener.handleEvent(AbstractReceiveListener.java:15)
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) [xnio-api-3.2.0.Beta4.jar:3.2.0.Beta4]
> at io.undertow.server.protocol.framed.AbstractFramedChannel$FrameReadListener.handleEvent(AbstractFramedChannel.java:615)
> at io.undertow.server.protocol.framed.AbstractFramedChannel$FrameReadListener.handleEvent(AbstractFramedChannel.java:601)
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) [xnio-api-3.2.0.Beta4.jar:3.2.0.Beta4]
> at org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66) [xnio-api-3.2.0.Beta4.jar:3.2.0.Beta4]
> at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:87) [xnio-nio-3.2.0.Beta4.jar:3.2.0.Beta4]
> at org.xnio.nio.WorkerThread.run(WorkerThread.java:531) [xnio-nio-3.2.0.Beta4.jar:3.2.0.Beta4]

--
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

From issues at jboss.org  Fri Mar  7 13:36:33 2014
From: issues at jboss.org (Michal Babacek (JIRA))
Date: Fri, 7 Mar 2014 13:36:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JBWEB-292) Http11Nio loaded,
 JBWEB002081: No cipher match
In-Reply-To: <JIRA.12534270.1394109559000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534270.1394109559000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534270.1394109559000.13303.1394217393788@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JBWEB-292?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12951269#comment-12951269 ] 

Michal Babacek commented on JBWEB-292:
--------------------------------------

Yes, JSSE names did it, this works:
{code}
<subsystem xmlns="urn:jboss:domain:web:1.5" native="false">
<connector name="https" protocol="HTTP/1.1" socket-binding="https" scheme="https" enabled="true" secure="true">
<ssl name="https" ca-certificate-file="/proper/ca-cert.jks" certificate-key-file="/proper/client-cert-key.jks" certificate-file="/proper/client-cert-key.jks" password="tomcat" verify-client="false" key-alias="javaclient" cipher-suite="TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384,!TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,!TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,!TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256,!TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256,TLS_DHE_RSA_WITH_AES_256_GCM_SHA384,!TLS_DHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA,TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384,TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384,TLS_ECDH_RSA_WITH_AES_256_CBC_SHA,TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA,TLS_DHE_RSA_WITH_AES_256_CBC_SHA256,TLS_DHE_RSA_WITH_AES_256_CBC_SHA,!TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256,!TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256,!TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,!TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA,!TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256,!TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256,!TLS_ECDH_RSA_WITH_AES_128_CBC_SHA,!TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA,!TLS_DHE_RSA_WITH_AES_128_CBC_SHA256,!TLS_DHE_RSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA,TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA,TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA,TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA,TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA,TLS_RSA_WITH_AES_256_GCM_SHA384,TLS_RSA_WITH_AES_256_CBC_SHA256,TLS_RSA_WITH_AES_256_CBC_SHA,!TLS_RSA_WITH_AES_128_GCM_SHA256,!TLS_RSA_WITH_AES_128_CBC_SHA256,!TLS_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_3DES_EDE_CBC_SHA" protocol="TLS"/>
</connector>
<virtual-server name="default-host" enable-welcome-root="true">
<alias name="localhost"/>
<alias name="example.com"/>
</virtual-server>
</subsystem>
{code}

So, is this just a documentation issue then?
                
> Http11Nio loaded, JBWEB002081: No cipher match
> ----------------------------------------------
>
>                 Key: JBWEB-292
>                 URL: https://issues.jboss.org/browse/JBWEB-292
>             Project: JBoss Web
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>    Affects Versions: JBossWeb-7.4.0.GA
>            Reporter: Michal Babacek
>            Assignee: Remy Maucherat
>            Priority: Critical
>             Fix For: JBossWeb-7.4.0.GA
>
>
> Hi guys,
> I have an SSL test that sets up the web subsystem with HTTPS connector only and uses HTTPS with mod_cluster.
> {code}
>         <subsystem xmlns="urn:jboss:domain:modcluster:1.2">
>             <mod-cluster-config advertise-socket="modcluster" connector="https">
>                 <dynamic-load-provider>
>                     <load-metric type="busyness"/>
>                 </dynamic-load-provider>
>                 <ssl key-alias="javaclient" 
>                      password="tomcat" 
>                      certificate-key-file="/tmp/ews-eap6/client-cert-key.jks" 
>                      cipher-suite="AES128-SHA:ALL:!ADH:!LOW:!MD5:!SSLV2:!NULL" 
>                      ca-certificate-file="/tmp/ews-eap6/ca-cert.jks"
>                 />
>             </mod-cluster-config>
>         </subsystem>
>         <subsystem xmlns="urn:jboss:domain:web:1.5" native="false">
>             <connector name="https" protocol="HTTP/1.1" scheme="https" socket-binding="https" secure="true" enabled="true">
>                 <ssl name="https" 
>                     key-alias="javaclient" 
>                     password="tomcat" 
>                     certificate-key-file="/tmp/ews-eap6/client-cert-key.jks" 
>                     cipher-suite="AES128-SHA:ALL:!ADH:!LOW:!MD5:!SSLV2:!NULL" 
>                     protocol="TLS" verify-client="false" 
>                     certificate-file="/tmp/ews-eap6/client-cert-key.jks" 
>                     ca-certificate-file="/tmp/ews-eap6/ca-cert.jks"/>
>             </connector>
>             <virtual-server name="default-host" enable-welcome-root="true">
>                 <alias name="localhost"/>
>                 <alias name="example.com"/>
>             </virtual-server>
>         </subsystem>
> {code}
> Notice that while EAP 6.3.0.DR1 with *jbossweb-7.3.0.Final* uses {{org.apache.coyote.http11}}, EAP 6.3.0.DR2 with *jbossweb-7.4.0.Beta4* tries to start {{org.apache.coyote.http11.Http11NioProtocol}}. 
> This causes cipher suite errors.
> * EAP 6.3.0.DR1 with jbossweb-7.3.0.Final passes this test with no exceptions thrown.
> * EAP 6.3.0.DR2 with jbossweb-7.4.0.Beta4 causes:
> {noformat}
> 06:18:26,649 ERROR [org.apache.coyote.http11.Http11NioProtocol] (MSC service thread 1-17) JBWEB003043: Error initializing endpoint: java.io.IOException: JBWEB002081: No cipher match
>     at org.apache.tomcat.util.net.jsse.NioJSSESocketChannelFactory.init(NioJSSESocketChannelFactory.java:315) [jbossweb-7.4.0.Beta4.jar:7.4.0.Beta4]
>     at org.apache.tomcat.util.net.NioEndpoint.init(NioEndpoint.java:205) [jbossweb-7.4.0.Beta4.jar:7.4.0.Beta4]
>     at org.apache.coyote.http11.Http11NioProtocol.init(Http11NioProtocol.java:113) [jbossweb-7.4.0.Beta4.jar:7.4.0.Beta4]
>     at org.apache.catalina.connector.Connector.init(Connector.java:983) [jbossweb-7.4.0.Beta4.jar:7.4.0.Beta4]
>     at org.jboss.as.web.WebConnectorService.start(WebConnectorService.java:304) [jboss-as-web-7.4.0.Final-redhat-2.jar:7.4.0.Final-redhat-2]
>     at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1980) [jboss-msc-1.1.5.Final.jar:1.1.5.Final]
>     at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1913) [jboss-msc-1.1.5.Final.jar:1.1.5.Final]
>     at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_51]
>     at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_51]
>     at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_51]
> Caused by: java.io.IOException: JBWEB002081: No cipher match
>     at org.apache.tomcat.util.net.jsse.NioJSSESocketChannelFactory.getEnabledCiphers(NioJSSESocketChannelFactory.java:399) [jbossweb-7.4.0.Beta4.jar:7.4.0.Beta4]
>     at org.apache.tomcat.util.net.jsse.NioJSSESocketChannelFactory.init(NioJSSESocketChannelFactory.java:305) [jbossweb-7.4.0.Beta4.jar:7.4.0.Beta4]
>     ... 9 more
> 06:18:26,663 INFO  [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-39) JBAS010400: Bound data source [java:jboss/datasources/ExampleDS]
> 06:18:26,672 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-17) MSC000001: Failed to start service jboss.web.connector.https: org.jboss.msc.service.StartException in service jboss.web.connector.https: JBAS018007: Error starting web connector
>     at org.jboss.as.web.WebConnectorService.start(WebConnectorService.java:362)
>     at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1980) [jboss-msc-1.1.5.Final.jar:1.1.5.Final]
>     at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1913) [jboss-msc-1.1.5.Final.jar:1.1.5.Final]
>     at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_51]
>     at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_51]
>     at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_51]
> Caused by: LifecycleException:  JBWEB000023: Protocol handler initialization failed
>     at org.apache.catalina.connector.Connector.init(Connector.java:985)
>     at org.jboss.as.web.WebConnectorService.start(WebConnectorService.java:304)
>     ... 5 more
> {noformat}
> Any ideas?

--
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


From issues at jboss.org  Fri Mar  7 13:42:34 2014
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Fri, 7 Mar 2014 13:42:34 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3078) directory-grouping
 configuration is not getting persisted via CLI when no servers defined
In-Reply-To: <JIRA.12534347.1394159920000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534347.1394159920000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534347.1394159920000.13316.1394217754095@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-3078?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFLY-3078:
-----------------------------------

    Assignee: Emanuel Muckenhuber  (was: Brian Stansberry)

    
> directory-grouping configuration is not getting persisted via CLI when no servers defined
> -----------------------------------------------------------------------------------------
>
>                 Key: WFLY-3078
>                 URL: https://issues.jboss.org/browse/WFLY-3078
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>    Affects Versions: 8.0.0.Final
>         Environment: All Operating System
>            Reporter: Jay Kumar SenSharma
>            Assignee: Emanuel Muckenhuber
>
> - If none of the servers are defined in "host.xml" (means <servers></servers> empty tag is present) and if the user tries to run the following CLI command to change the "directory-grouping" to  "by-type"  then the value is not persisted in the configuration file (host.xml) and the <servers></servers>  tag is also removed from the host.xml
> {code}
> /host=master/:write-attribute(name=directory-grouping,value=by-type)
> {code}
> - The value of "directory-grouping" is stored "in memory" so this change does not survive the host restart.

--
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

From issues at jboss.org  Fri Mar  7 13:42:34 2014
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Fri, 7 Mar 2014 13:42:34 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3078) directory-grouping
 configuration is not getting persisted via CLI when no servers defined
In-Reply-To: <JIRA.12534347.1394159920000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534347.1394159920000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534347.1394159920000.13321.1394217754363@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-3078?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFLY-3078:
-----------------------------------

    Fix Version/s: 8.0.1.Final

    
> directory-grouping configuration is not getting persisted via CLI when no servers defined
> -----------------------------------------------------------------------------------------
>
>                 Key: WFLY-3078
>                 URL: https://issues.jboss.org/browse/WFLY-3078
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>    Affects Versions: 8.0.0.Final
>         Environment: All Operating System
>            Reporter: Jay Kumar SenSharma
>            Assignee: Emanuel Muckenhuber
>             Fix For: 8.0.1.Final
>
>
> - If none of the servers are defined in "host.xml" (means <servers></servers> empty tag is present) and if the user tries to run the following CLI command to change the "directory-grouping" to  "by-type"  then the value is not persisted in the configuration file (host.xml) and the <servers></servers>  tag is also removed from the host.xml
> {code}
> /host=master/:write-attribute(name=directory-grouping,value=by-type)
> {code}
> - The value of "directory-grouping" is stored "in memory" so this change does not survive the host restart.

--
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

From issues at jboss.org  Fri Mar  7 13:58:33 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 7 Mar 2014 13:58:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3007) Ipv6 addresses may not be
 canonized properly
In-Reply-To: <JIRA.12533139.1393261818000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12533139.1393261818000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12533139.1393261818000.13353.1394218713713@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-3007?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12951275#comment-12951275 ] 

RH Bugzilla Integration commented on WFLY-3007:
-----------------------------------------------

Emmanuel Hugonnet (ehsavoie) <ehugonne at redhat.com> changed the Status of [bug 1067348|https://bugzilla.redhat.com/show_bug.cgi?id=1067348] from NEW to POST
                
> Ipv6 addresses may not be canonized properly
> --------------------------------------------
>
>                 Key: WFLY-3007
>                 URL: https://issues.jboss.org/browse/WFLY-3007
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 8.0.0.Final
>            Reporter: Emmanuel Hugonnet
>            Assignee: Emmanuel Hugonnet
>
> On an ipv6 environment we may obtain IP addresses that are not properly canonized which may lead to strange issue with http proxies since the JDK ProxySelector relies on char per char matching.
> All call to InetAddress.getHostName() may produce such an uncanonized address.

--
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

From issues at jboss.org  Fri Mar  7 15:10:33 2014
From: issues at jboss.org (Farah Juma (JIRA))
Date: Fri, 7 Mar 2014 15:10:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2669)
 ConcurrentModificationException releasing JSF factories
In-Reply-To: <JIRA.12528215.1387454353000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528215.1387454353000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528215.1387454353000.13454.1394223033274@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2669?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12951291#comment-12951291 ] 

Farah Juma commented on WFLY-2669:
----------------------------------

I've created this upstream issue:

https://java.net/jira/browse/JAVASERVERFACES-3202
                
> ConcurrentModificationException releasing JSF factories
> -------------------------------------------------------
>
>                 Key: WFLY-2669
>                 URL: https://issues.jboss.org/browse/WFLY-2669
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JSF
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Jozef Hartinger
>            Assignee: Farah Juma
>
> Saw this happen once. Probably a thread-safety problem in JSF API:
> {code}
> 5:04:37,876 ERROR [io.undertow.servlet.request] (MSC service thread 1-4) UT015005: Error invoking method contextDestroyed on listener class com.sun.faces.config.ConfigureListener: java.util.ConcurrentModificationException
>         at java.util.HashMap$HashIterator.nextEntry(HashMap.java:926) [rt.jar:1.7.0_45]
>         at java.util.HashMap$ValueIterator.next(HashMap.java:954) [rt.jar:1.7.0_45]
>         at javax.faces.FactoryFinder.releaseFactories(FactoryFinder.java:440) [jboss-jsf-api_2.2_spec-2.2.4.jar:2.2.4]
>         at com.sun.faces.config.ConfigManager.releaseFactories(ConfigManager.java:808) [jsf-impl-2.2.4-jbossorg-1.jar:]
>         at com.sun.faces.config.ConfigManager.destroy(ConfigManager.java:474) [jsf-impl-2.2.4-jbossorg-1.jar:]
>         at com.sun.faces.config.ConfigureListener.contextDestroyed(ConfigureListener.java:329) [jsf-impl-2.2.4-jbossorg-1.jar:]
>         at io.undertow.servlet.core.ApplicationListeners.contextDestroyed(ApplicationListeners.java:185) [undertow-servlet-1.0.0.Beta27.jar:1.0.0.Beta27]
>         at io.undertow.servlet.core.DeploymentImpl.destroy(DeploymentImpl.java:216) [undertow-servlet-1.0.0.Beta27.jar:1.0.0.Beta27]
>         at io.undertow.servlet.core.DeploymentManagerImpl.undeploy(DeploymentManagerImpl.java:523) [undertow-servlet-1.0.0.Beta27.jar:1.0.0.Beta27]
>         at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.stopContext(UndertowDeploymentService.java:117)
>         at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.stop(UndertowDeploymentService.java:100)
>         at org.jboss.msc.service.ServiceControllerImpl$StopTask.stopService(ServiceControllerImpl.java:2056)
>         at org.jboss.msc.service.ServiceControllerImpl$StopTask.run(ServiceControllerImpl.java:2017)
>         at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_45]
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_45]
>         at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_45]
> {code}

--
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

From issues at jboss.org  Fri Mar  7 15:26:33 2014
From: issues at jboss.org (Sat B (JIRA))
Date: Fri, 7 Mar 2014 15:26:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3088) Cannot Inject Validator using
	@Inject
In-Reply-To: <JIRA.12534463.1394223939148@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534463.1394223939148@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534463.1394223939148.13480.1394223993360@jira02.app.mwc.hst.phx2.redhat.com>

Sat B created WFLY-3088:
---------------------------

             Summary: Cannot Inject Validator using @Inject
                 Key: WFLY-3088
                 URL: https://issues.jboss.org/browse/WFLY-3088
             Project: WildFly
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: CDI / Weld
    Affects Versions: 8.0.0.Final
            Reporter: Sat B
            Assignee: Stuart Douglas


I have a very simple bean and I am trying to inject the Validator using the @Inject annotation. But I am ending up getting a null when I try to use the Validator. I have the beans.xml defined to bean-discovery-mode="all". Below is the code

--------

import javax.inject.Inject;
import javax.validation.ConstraintViolation;
import javax.validation.Validation;
import javax.validation.Validator;
import javax.validation.ValidatorFactory;
import javax.validation.constraints.*;
import java.util.Map;
import java.util.Set;

public class SimpleCommand {
    @Inject
    private Validator validator;
   
    @Email
    private String email;
    

    public SimpleCommand(){

    }

    public SimpleCommand(Map<String, String[]> params){
        this.email = params.get("email")!=null ? params.get("email")[0] : null;
    }

    public void validate(){
        //USING VALIDATOR THAT IS INJECTED IS NULL HERE
        //USING THE BELOW METHOD WORKS
        ValidatorFactory factory = Validation.buildDefaultValidatorFactory();
        Validator validator1 = factory.getValidator();
        Set<ConstraintViolation<SimpleCommand>> contstraintViolations = validator1.validate(this); //USING INJECTED VALIDATOR WILL THROW NULL POINTER EXCEPTION
        for (ConstraintViolation<SimpleCommand> violation : contstraintViolations){
            System.out.println(violation.getMessage());
        }
    }
}

--------

Then, from a JAX-RS controller, I call this validator

------

SimpleCommand cmd = new SimpleCommand(req.getParameterMap());
        cmd.validate();
-----

--
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

From issues at jboss.org  Fri Mar  7 18:05:33 2014
From: issues at jboss.org (Kyle Lape (JIRA))
Date: Fri, 7 Mar 2014 18:05:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3089) Batching logging profile
 creation CLI commands can cause errors
In-Reply-To: <JIRA.12534475.1394233459831@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534475.1394233459831@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534475.1394233459831.13572.1394233533205@jira02.app.mwc.hst.phx2.redhat.com>

Kyle Lape created WFLY-3089:
-------------------------------

             Summary: Batching logging profile creation CLI commands can cause errors
                 Key: WFLY-3089
                 URL: https://issues.jboss.org/browse/WFLY-3089
             Project: WildFly
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Logging
    Affects Versions: 8.0.0.Final
            Reporter: Kyle Lape
            Assignee: James Perkins


Given these set of commands:

{noformat}
/subsystem=logging/logging-profile=myLoggingProfile:add
/subsystem=logging/logging-profile=myLoggingProfile/file-handler=myHandler:add(level=ALL,file={"relative-to" => "jboss.server.log.dir","path" => "myapp.log"})
/subsystem=logging/logging-profile=myLoggingProfile/root-logger=ROOT:add
/subsystem=logging/logging-profile=myLoggingProfile/root-logger=ROOT:add-handler(name=myHandler)
/subsystem=logging/logging-profile=myLoggingProfile/root-logger=ROOT:change-root-log-level(level=INFO)
{noformat}

If I run those in a batch, I get an error:

{noformat}13:32:52,478 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 4) JBAS014613: Operation ("add-handler") failed - address: ([
    ("subsystem" => "logging"),
    ("logging-profile" => "myLoggingProfile"),
    ("root-logger" => "ROOT")
]) - failure description: "JBAS011536: Handler myHandler is already assigned."
{noformat}

If I run each one individually, I get no error.

--
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

From issues at jboss.org  Fri Mar  7 18:11:33 2014
From: issues at jboss.org (Kyle Lape (JIRA))
Date: Fri, 7 Mar 2014 18:11:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3089) Batching logging profile
 creation CLI commands can cause errors
In-Reply-To: <JIRA.12534475.1394233459000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534475.1394233459000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534475.1394233459000.13579.1394233893266@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-3089?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kyle Lape updated WFLY-3089:
----------------------------

    Workaround Description: 
Combine command #3 and #4:

{noformat}
/subsystem=logging/logging-profile=myLoggingProfile/root-logger=ROOT:add(handlers=[handler=myHandler])
{noformat}

    
> Batching logging profile creation CLI commands can cause errors
> ---------------------------------------------------------------
>
>                 Key: WFLY-3089
>                 URL: https://issues.jboss.org/browse/WFLY-3089
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Logging
>    Affects Versions: 8.0.0.Final
>            Reporter: Kyle Lape
>            Assignee: James Perkins
>
> Given these set of commands:
> {noformat}
> /subsystem=logging/logging-profile=myLoggingProfile:add
> /subsystem=logging/logging-profile=myLoggingProfile/file-handler=myHandler:add(level=ALL,file={"relative-to" => "jboss.server.log.dir","path" => "myapp.log"})
> /subsystem=logging/logging-profile=myLoggingProfile/root-logger=ROOT:add
> /subsystem=logging/logging-profile=myLoggingProfile/root-logger=ROOT:add-handler(name=myHandler)
> /subsystem=logging/logging-profile=myLoggingProfile/root-logger=ROOT:change-root-log-level(level=INFO)
> {noformat}
> If I run those in a batch, I get an error:
> {noformat}13:32:52,478 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 4) JBAS014613: Operation ("add-handler") failed - address: ([
>     ("subsystem" => "logging"),
>     ("logging-profile" => "myLoggingProfile"),
>     ("root-logger" => "ROOT")
> ]) - failure description: "JBAS011536: Handler myHandler is already assigned."
> {noformat}
> If I run each one individually, I get no error.

--
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

From issues at jboss.org  Fri Mar  7 18:54:33 2014
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Fri, 7 Mar 2014 18:54:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3090) Administrative cancellation
 of management ops results in closed connections
In-Reply-To: <JIRA.12534477.1394236430203@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534477.1394236430203@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534477.1394236430203.13592.1394236473848@jira02.app.mwc.hst.phx2.redhat.com>

Brian Stansberry created WFLY-3090:
--------------------------------------

             Summary: Administrative cancellation of management ops results in closed connections
                 Key: WFLY-3090
                 URL: https://issues.jboss.org/browse/WFLY-3090
             Project: WildFly
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Domain Management
    Affects Versions: 8.0.0.Final
            Reporter: Brian Stansberry
            Assignee: Brian Stansberry
             Fix For: 8.0.1.Final


Administrative cancellation of management ops is implemented by the thread that is handling the cancellation interrupting the thread that is executing the op. This works, but the thread executing the op can't readily distinguish between interruption do to admin action and cancellation for other reasons such as server shutdown. The OperationContext code detects interruption but restores the interrupted state to the thread, which is valid for the shutdown case. For the administrative cancellation case, it has the negative side effect of producing InterruptedExceptions later on; e.g. when the thread attempts to send data to the remote caller.

This is particularly an issue in domain mode where the "caller" is a controlling process (HC). The InterruptedException has the effect of terminating the connection from the callee to the controlling process.

The operation execution code needs to be able to distinguish between administrative cancellation and other causes of interruption.

--
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

From issues at jboss.org  Fri Mar  7 20:24:34 2014
From: issues at jboss.org (James Perkins (JIRA))
Date: Fri, 7 Mar 2014 20:24:34 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3089) Batching logging profile
 creation CLI commands can cause errors
In-Reply-To: <JIRA.12534475.1394233459000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534475.1394233459000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534475.1394233459000.13611.1394241874475@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-3089?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12951315#comment-12951315 ] 

James Perkins commented on WFLY-3089:
-------------------------------------

I thought I had fixed that with WFLY-1712. Clearly I didn't :(
                
> Batching logging profile creation CLI commands can cause errors
> ---------------------------------------------------------------
>
>                 Key: WFLY-3089
>                 URL: https://issues.jboss.org/browse/WFLY-3089
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Logging
>    Affects Versions: 8.0.0.Final
>            Reporter: Kyle Lape
>            Assignee: James Perkins
>
> Given these set of commands:
> {noformat}
> /subsystem=logging/logging-profile=myLoggingProfile:add
> /subsystem=logging/logging-profile=myLoggingProfile/file-handler=myHandler:add(level=ALL,file={"relative-to" => "jboss.server.log.dir","path" => "myapp.log"})
> /subsystem=logging/logging-profile=myLoggingProfile/root-logger=ROOT:add
> /subsystem=logging/logging-profile=myLoggingProfile/root-logger=ROOT:add-handler(name=myHandler)
> /subsystem=logging/logging-profile=myLoggingProfile/root-logger=ROOT:change-root-log-level(level=INFO)
> {noformat}
> If I run those in a batch, I get an error:
> {noformat}13:32:52,478 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 4) JBAS014613: Operation ("add-handler") failed - address: ([
>     ("subsystem" => "logging"),
>     ("logging-profile" => "myLoggingProfile"),
>     ("root-logger" => "ROOT")
> ]) - failure description: "JBAS011536: Handler myHandler is already assigned."
> {noformat}
> If I run each one individually, I get no error.

--
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

From issues at jboss.org  Sat Mar  8 03:55:33 2014
From: issues at jboss.org (Kyle Shanahan (JIRA))
Date: Sat, 8 Mar 2014 03:55:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (LOGMGR-104) SyslogHandler doesn't handle
 multi-byte characters correctly
In-Reply-To: <JIRA.12534488.1394268821983@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534488.1394268821983@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534488.1394268821983.13649.1394268933265@jira02.app.mwc.hst.phx2.redhat.com>

Kyle Shanahan created LOGMGR-104:
------------------------------------

             Summary: SyslogHandler doesn't handle multi-byte characters correctly
                 Key: LOGMGR-104
                 URL: https://issues.jboss.org/browse/LOGMGR-104
             Project: JBoss Log Manager
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: core
    Affects Versions: 1.5.2.Final
         Environment: - WildFly 8.0.0.Final
- Oracle JDK7u51
- OS X 10.9.2
            Reporter: Kyle Shanahan
            Assignee: David Lloyd


SyslogHandler doesn't handle multi-byte characters correctly.

I tried to log multi-byte message with both of org.jboss.logmanager.handlers.SyslogHandler and org.apache.log4j.net.SyslogAppender for same message, only SyslogHandler output were corrupted.

Step to reproduce: 

1. define a facility local1 at localhost and make syslog accept UDP packets.
2. define a logger:
{noformat}
/subsystem=logging/logger=utf8mb4log:add(level=INFO)
{noformat}
3. define a SyslogHandler:
{noformat}
/subsystem=logging/custom-handler=TEST_SH:add(class="org.jboss.logmanager.handlers.SyslogHandler", module="org.jboss.logmanager", formatter="SyslogHandler: %s%e", level=INFO, properties={serverHostname="localhost:514", facility="LOCAL_USE_1", truncate=false, maxLength=1024, syslogType="RFC3164" })
/subsystem=logging/logger=utf8mb4log:assign-handler(name=TEST_SH)
{noformat}
4. define a SyslogAppender:
{noformat}
/subsystem=logging/custom-handler=TEST_LOG4J:add(class="org.apache.log4j.net.SyslogAppender", module="org.apache.log4j", formatter="log4j: %s%e", level=INFO, properties={syslogHost="localhost:514", facility="local1"})
/subsystem=logging/logger=utf8mb4log:assign-handler(name=TEST_LOG4J)
{noformat}
5. get and run example project at https://github.com/lbtc-xxx/utf8mb4log

And you will get like this: (I can't put 4 byte UTF-8 characters here... because  database error occured):
{noformat}
Mar  8 17:29:09 UNKNOWN_HOSTNAME java[9896]: SyslogHandler: ????????????
{noformat}

I would send a pull request later.

--
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

From issues at jboss.org  Sat Mar  8 04:07:33 2014
From: issues at jboss.org (Kyle Shanahan (JIRA))
Date: Sat, 8 Mar 2014 04:07:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (LOGMGR-104) SyslogHandler doesn't handle
 multi-byte characters correctly
In-Reply-To: <JIRA.12534488.1394268821000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534488.1394268821000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534488.1394268821000.13652.1394269653428@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/LOGMGR-104?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kyle Shanahan updated LOGMGR-104:
---------------------------------

    Description: 
SyslogHandler doesn't handle multi-byte characters correctly.

I tried to log multi-byte message with both of org.jboss.logmanager.handlers.SyslogHandler and org.apache.log4j.net.SyslogAppender for same message, only SyslogHandler output were corrupted.

Step to reproduce: 

1. define a facility local1 at localhost and make syslog accept UDP packets.
2. define a logger:
{noformat}
/subsystem=logging/logger=utf8mb4log:add(level=INFO)
{noformat}
3. define a SyslogHandler:
{noformat}
/subsystem=logging/custom-handler=TEST_SH:add(class="org.jboss.logmanager.handlers.SyslogHandler", module="org.jboss.logmanager", formatter="SyslogHandler: %s%e", level=INFO, properties={serverHostname="localhost:514", facility="LOCAL_USE_1", truncate=false, maxLength=1024, syslogType="RFC3164" })
/subsystem=logging/logger=utf8mb4log:assign-handler(name=TEST_SH)
{noformat}
4. define a SyslogAppender:
{noformat}
/subsystem=logging/custom-handler=TEST_LOG4J:add(class="org.apache.log4j.net.SyslogAppender", module="org.apache.log4j", formatter="log4j: %s%e", level=INFO, properties={syslogHost="localhost:514", facility="local1"})
/subsystem=logging/logger=utf8mb4log:assign-handler(name=TEST_LOG4J)
{noformat}
5. get and deploy example project at https://github.com/lbtc-xxx/utf8mb4log
6. Access the servlet http://localhost:8080/utf8mb4log/

And you will get like this: (I can't put 4 byte UTF-8 characters here... because  database error occured):
{noformat}
Mar  8 17:29:09 UNKNOWN_HOSTNAME java[9896]: SyslogHandler: ????????????
{noformat}

I would send a pull request later.

  was:
SyslogHandler doesn't handle multi-byte characters correctly.

I tried to log multi-byte message with both of org.jboss.logmanager.handlers.SyslogHandler and org.apache.log4j.net.SyslogAppender for same message, only SyslogHandler output were corrupted.

Step to reproduce: 

1. define a facility local1 at localhost and make syslog accept UDP packets.
2. define a logger:
{noformat}
/subsystem=logging/logger=utf8mb4log:add(level=INFO)
{noformat}
3. define a SyslogHandler:
{noformat}
/subsystem=logging/custom-handler=TEST_SH:add(class="org.jboss.logmanager.handlers.SyslogHandler", module="org.jboss.logmanager", formatter="SyslogHandler: %s%e", level=INFO, properties={serverHostname="localhost:514", facility="LOCAL_USE_1", truncate=false, maxLength=1024, syslogType="RFC3164" })
/subsystem=logging/logger=utf8mb4log:assign-handler(name=TEST_SH)
{noformat}
4. define a SyslogAppender:
{noformat}
/subsystem=logging/custom-handler=TEST_LOG4J:add(class="org.apache.log4j.net.SyslogAppender", module="org.apache.log4j", formatter="log4j: %s%e", level=INFO, properties={syslogHost="localhost:514", facility="local1"})
/subsystem=logging/logger=utf8mb4log:assign-handler(name=TEST_LOG4J)
{noformat}
5. get and run example project at https://github.com/lbtc-xxx/utf8mb4log

And you will get like this: (I can't put 4 byte UTF-8 characters here... because  database error occured):
{noformat}
Mar  8 17:29:09 UNKNOWN_HOSTNAME java[9896]: SyslogHandler: ????????????
{noformat}

I would send a pull request later.


    
> SyslogHandler doesn't handle multi-byte characters correctly
> ------------------------------------------------------------
>
>                 Key: LOGMGR-104
>                 URL: https://issues.jboss.org/browse/LOGMGR-104
>             Project: JBoss Log Manager
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: core
>    Affects Versions: 1.5.2.Final
>         Environment: - WildFly 8.0.0.Final
> - Oracle JDK7u51
> - OS X 10.9.2
>            Reporter: Kyle Shanahan
>            Assignee: David Lloyd
>
> SyslogHandler doesn't handle multi-byte characters correctly.
> I tried to log multi-byte message with both of org.jboss.logmanager.handlers.SyslogHandler and org.apache.log4j.net.SyslogAppender for same message, only SyslogHandler output were corrupted.
> Step to reproduce: 
> 1. define a facility local1 at localhost and make syslog accept UDP packets.
> 2. define a logger:
> {noformat}
> /subsystem=logging/logger=utf8mb4log:add(level=INFO)
> {noformat}
> 3. define a SyslogHandler:
> {noformat}
> /subsystem=logging/custom-handler=TEST_SH:add(class="org.jboss.logmanager.handlers.SyslogHandler", module="org.jboss.logmanager", formatter="SyslogHandler: %s%e", level=INFO, properties={serverHostname="localhost:514", facility="LOCAL_USE_1", truncate=false, maxLength=1024, syslogType="RFC3164" })
> /subsystem=logging/logger=utf8mb4log:assign-handler(name=TEST_SH)
> {noformat}
> 4. define a SyslogAppender:
> {noformat}
> /subsystem=logging/custom-handler=TEST_LOG4J:add(class="org.apache.log4j.net.SyslogAppender", module="org.apache.log4j", formatter="log4j: %s%e", level=INFO, properties={syslogHost="localhost:514", facility="local1"})
> /subsystem=logging/logger=utf8mb4log:assign-handler(name=TEST_LOG4J)
> {noformat}
> 5. get and deploy example project at https://github.com/lbtc-xxx/utf8mb4log
> 6. Access the servlet http://localhost:8080/utf8mb4log/
> And you will get like this: (I can't put 4 byte UTF-8 characters here... because  database error occured):
> {noformat}
> Mar  8 17:29:09 UNKNOWN_HOSTNAME java[9896]: SyslogHandler: ????????????
> {noformat}
> I would send a pull request later.

--
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

From issues at jboss.org  Sat Mar  8 05:30:33 2014
From: issues at jboss.org (Kyle Shanahan (JIRA))
Date: Sat, 8 Mar 2014 05:30:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (LOGMGR-104) SyslogHandler doesn't handle
 multi-byte characters correctly
In-Reply-To: <JIRA.12534488.1394268821000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534488.1394268821000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534488.1394268821000.13674.1394274633653@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/LOGMGR-104?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kyle Shanahan updated LOGMGR-104:
---------------------------------

          Issue Type: Bug  (was: Feature Request)
    Git Pull Request: https://github.com/jboss-logging/jboss-logmanager/pull/49

    
> SyslogHandler doesn't handle multi-byte characters correctly
> ------------------------------------------------------------
>
>                 Key: LOGMGR-104
>                 URL: https://issues.jboss.org/browse/LOGMGR-104
>             Project: JBoss Log Manager
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: core
>    Affects Versions: 1.5.2.Final
>         Environment: - WildFly 8.0.0.Final
> - Oracle JDK7u51
> - OS X 10.9.2
>            Reporter: Kyle Shanahan
>            Assignee: David Lloyd
>
> SyslogHandler doesn't handle multi-byte characters correctly.
> I tried to log multi-byte message with both of org.jboss.logmanager.handlers.SyslogHandler and org.apache.log4j.net.SyslogAppender for same message, only SyslogHandler output were corrupted.
> Step to reproduce: 
> 1. define a facility local1 at localhost and make syslog accept UDP packets.
> 2. define a logger:
> {noformat}
> /subsystem=logging/logger=utf8mb4log:add(level=INFO)
> {noformat}
> 3. define a SyslogHandler:
> {noformat}
> /subsystem=logging/custom-handler=TEST_SH:add(class="org.jboss.logmanager.handlers.SyslogHandler", module="org.jboss.logmanager", formatter="SyslogHandler: %s%e", level=INFO, properties={serverHostname="localhost:514", facility="LOCAL_USE_1", truncate=false, maxLength=1024, syslogType="RFC3164" })
> /subsystem=logging/logger=utf8mb4log:assign-handler(name=TEST_SH)
> {noformat}
> 4. define a SyslogAppender:
> {noformat}
> /subsystem=logging/custom-handler=TEST_LOG4J:add(class="org.apache.log4j.net.SyslogAppender", module="org.apache.log4j", formatter="log4j: %s%e", level=INFO, properties={syslogHost="localhost:514", facility="local1"})
> /subsystem=logging/logger=utf8mb4log:assign-handler(name=TEST_LOG4J)
> {noformat}
> 5. get and deploy example project at https://github.com/lbtc-xxx/utf8mb4log
> 6. Access the servlet http://localhost:8080/utf8mb4log/
> And you will get like this: (I can't put 4 byte UTF-8 characters here... because  database error occured):
> {noformat}
> Mar  8 17:29:09 UNKNOWN_HOSTNAME java[9896]: SyslogHandler: ????????????
> {noformat}
> I would send a pull request later.

--
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

From issues at jboss.org  Sat Mar  8 05:36:33 2014
From: issues at jboss.org (Kyle Shanahan (JIRA))
Date: Sat, 8 Mar 2014 05:36:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (LOGMGR-104) SyslogHandler doesn't handle
 multi-byte characters correctly
In-Reply-To: <JIRA.12534488.1394268821000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534488.1394268821000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534488.1394268821000.13677.1394274993657@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/LOGMGR-104?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kyle Shanahan updated LOGMGR-104:
---------------------------------

    Git Pull Request:   (was: https://github.com/jboss-logging/jboss-logmanager/pull/49)

    
> SyslogHandler doesn't handle multi-byte characters correctly
> ------------------------------------------------------------
>
>                 Key: LOGMGR-104
>                 URL: https://issues.jboss.org/browse/LOGMGR-104
>             Project: JBoss Log Manager
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: core
>    Affects Versions: 1.5.2.Final
>         Environment: - WildFly 8.0.0.Final
> - Oracle JDK7u51
> - OS X 10.9.2
>            Reporter: Kyle Shanahan
>            Assignee: David Lloyd
>
> SyslogHandler doesn't handle multi-byte characters correctly.
> I tried to log multi-byte message with both of org.jboss.logmanager.handlers.SyslogHandler and org.apache.log4j.net.SyslogAppender for same message, only SyslogHandler output were corrupted.
> Step to reproduce: 
> 1. define a facility local1 at localhost and make syslog accept UDP packets.
> 2. define a logger:
> {noformat}
> /subsystem=logging/logger=utf8mb4log:add(level=INFO)
> {noformat}
> 3. define a SyslogHandler:
> {noformat}
> /subsystem=logging/custom-handler=TEST_SH:add(class="org.jboss.logmanager.handlers.SyslogHandler", module="org.jboss.logmanager", formatter="SyslogHandler: %s%e", level=INFO, properties={serverHostname="localhost:514", facility="LOCAL_USE_1", truncate=false, maxLength=1024, syslogType="RFC3164" })
> /subsystem=logging/logger=utf8mb4log:assign-handler(name=TEST_SH)
> {noformat}
> 4. define a SyslogAppender:
> {noformat}
> /subsystem=logging/custom-handler=TEST_LOG4J:add(class="org.apache.log4j.net.SyslogAppender", module="org.apache.log4j", formatter="log4j: %s%e", level=INFO, properties={syslogHost="localhost:514", facility="local1"})
> /subsystem=logging/logger=utf8mb4log:assign-handler(name=TEST_LOG4J)
> {noformat}
> 5. get and deploy example project at https://github.com/lbtc-xxx/utf8mb4log
> 6. Access the servlet http://localhost:8080/utf8mb4log/
> And you will get like this: (I can't put 4 byte UTF-8 characters here... because  database error occured):
> {noformat}
> Mar  8 17:29:09 UNKNOWN_HOSTNAME java[9896]: SyslogHandler: ????????????
> {noformat}
> I would send a pull request later.

--
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

From issues at jboss.org  Sat Mar  8 05:46:33 2014
From: issues at jboss.org (Jean-Frederic Clere (JIRA))
Date: Sat, 8 Mar 2014 05:46:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JBWEB-292) Http11Nio loaded,
 JBWEB002081: No cipher match
In-Reply-To: <JIRA.12534270.1394109559000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534270.1394109559000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534270.1394109559000.13681.1394275593760@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBWEB-292?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jean-Frederic Clere closed JBWEB-292.
-------------------------------------

    Resolution: Rejected


If you find in the doc that you can use the OpenSSL cipher-suite in JSSE, that could be a minor doc issue.
                
> Http11Nio loaded, JBWEB002081: No cipher match
> ----------------------------------------------
>
>                 Key: JBWEB-292
>                 URL: https://issues.jboss.org/browse/JBWEB-292
>             Project: JBoss Web
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>    Affects Versions: JBossWeb-7.4.0.GA
>            Reporter: Michal Babacek
>            Assignee: Remy Maucherat
>            Priority: Critical
>             Fix For: JBossWeb-7.4.0.GA
>
>
> Hi guys,
> I have an SSL test that sets up the web subsystem with HTTPS connector only and uses HTTPS with mod_cluster.
> {code}
>         <subsystem xmlns="urn:jboss:domain:modcluster:1.2">
>             <mod-cluster-config advertise-socket="modcluster" connector="https">
>                 <dynamic-load-provider>
>                     <load-metric type="busyness"/>
>                 </dynamic-load-provider>
>                 <ssl key-alias="javaclient" 
>                      password="tomcat" 
>                      certificate-key-file="/tmp/ews-eap6/client-cert-key.jks" 
>                      cipher-suite="AES128-SHA:ALL:!ADH:!LOW:!MD5:!SSLV2:!NULL" 
>                      ca-certificate-file="/tmp/ews-eap6/ca-cert.jks"
>                 />
>             </mod-cluster-config>
>         </subsystem>
>         <subsystem xmlns="urn:jboss:domain:web:1.5" native="false">
>             <connector name="https" protocol="HTTP/1.1" scheme="https" socket-binding="https" secure="true" enabled="true">
>                 <ssl name="https" 
>                     key-alias="javaclient" 
>                     password="tomcat" 
>                     certificate-key-file="/tmp/ews-eap6/client-cert-key.jks" 
>                     cipher-suite="AES128-SHA:ALL:!ADH:!LOW:!MD5:!SSLV2:!NULL" 
>                     protocol="TLS" verify-client="false" 
>                     certificate-file="/tmp/ews-eap6/client-cert-key.jks" 
>                     ca-certificate-file="/tmp/ews-eap6/ca-cert.jks"/>
>             </connector>
>             <virtual-server name="default-host" enable-welcome-root="true">
>                 <alias name="localhost"/>
>                 <alias name="example.com"/>
>             </virtual-server>
>         </subsystem>
> {code}
> Notice that while EAP 6.3.0.DR1 with *jbossweb-7.3.0.Final* uses {{org.apache.coyote.http11}}, EAP 6.3.0.DR2 with *jbossweb-7.4.0.Beta4* tries to start {{org.apache.coyote.http11.Http11NioProtocol}}. 
> This causes cipher suite errors.
> * EAP 6.3.0.DR1 with jbossweb-7.3.0.Final passes this test with no exceptions thrown.
> * EAP 6.3.0.DR2 with jbossweb-7.4.0.Beta4 causes:
> {noformat}
> 06:18:26,649 ERROR [org.apache.coyote.http11.Http11NioProtocol] (MSC service thread 1-17) JBWEB003043: Error initializing endpoint: java.io.IOException: JBWEB002081: No cipher match
>     at org.apache.tomcat.util.net.jsse.NioJSSESocketChannelFactory.init(NioJSSESocketChannelFactory.java:315) [jbossweb-7.4.0.Beta4.jar:7.4.0.Beta4]
>     at org.apache.tomcat.util.net.NioEndpoint.init(NioEndpoint.java:205) [jbossweb-7.4.0.Beta4.jar:7.4.0.Beta4]
>     at org.apache.coyote.http11.Http11NioProtocol.init(Http11NioProtocol.java:113) [jbossweb-7.4.0.Beta4.jar:7.4.0.Beta4]
>     at org.apache.catalina.connector.Connector.init(Connector.java:983) [jbossweb-7.4.0.Beta4.jar:7.4.0.Beta4]
>     at org.jboss.as.web.WebConnectorService.start(WebConnectorService.java:304) [jboss-as-web-7.4.0.Final-redhat-2.jar:7.4.0.Final-redhat-2]
>     at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1980) [jboss-msc-1.1.5.Final.jar:1.1.5.Final]
>     at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1913) [jboss-msc-1.1.5.Final.jar:1.1.5.Final]
>     at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_51]
>     at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_51]
>     at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_51]
> Caused by: java.io.IOException: JBWEB002081: No cipher match
>     at org.apache.tomcat.util.net.jsse.NioJSSESocketChannelFactory.getEnabledCiphers(NioJSSESocketChannelFactory.java:399) [jbossweb-7.4.0.Beta4.jar:7.4.0.Beta4]
>     at org.apache.tomcat.util.net.jsse.NioJSSESocketChannelFactory.init(NioJSSESocketChannelFactory.java:305) [jbossweb-7.4.0.Beta4.jar:7.4.0.Beta4]
>     ... 9 more
> 06:18:26,663 INFO  [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-39) JBAS010400: Bound data source [java:jboss/datasources/ExampleDS]
> 06:18:26,672 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-17) MSC000001: Failed to start service jboss.web.connector.https: org.jboss.msc.service.StartException in service jboss.web.connector.https: JBAS018007: Error starting web connector
>     at org.jboss.as.web.WebConnectorService.start(WebConnectorService.java:362)
>     at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1980) [jboss-msc-1.1.5.Final.jar:1.1.5.Final]
>     at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1913) [jboss-msc-1.1.5.Final.jar:1.1.5.Final]
>     at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_51]
>     at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_51]
>     at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_51]
> Caused by: LifecycleException:  JBWEB000023: Protocol handler initialization failed
>     at org.apache.catalina.connector.Connector.init(Connector.java:985)
>     at org.jboss.as.web.WebConnectorService.start(WebConnectorService.java:304)
>     ... 5 more
> {noformat}
> Any ideas?

--
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

From issues at jboss.org  Sat Mar  8 06:17:33 2014
From: issues at jboss.org (Rituraj Sinha (JIRA))
Date: Sat, 8 Mar 2014 06:17:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3051) http-remoting-jmx connection
 failure connecting to Undertow subsystem instead of Undertow management
In-Reply-To: <JIRA.12533723.1393825342000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12533723.1393825342000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12533723.1393825342000.13693.1394277453529@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-3051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12951326#comment-12951326 ] 

Rituraj Sinha commented on WFLY-3051:
-------------------------------------

Hi Darran,

we have a situation where we want to secure our JMX console as well...on the basis of roles ...there is a requirement where team wants to have access to JMX but it should only be Read Only...

As wildfly supports RBAC(i feel its only for management tasks) ...i have created a application user and password assigned a Monitoring group to it ...is it possible that it can take one of the roles predefined in RBAC and when it logs in with these credentials they can only monitor the stuff as it there on the web_management condole...?

can the user craeted in the application realm also get the privilege of predefined Roles (like Monitor) and access associated with it to connect to JMX..so that they can get the access but cant do anything there...?

Thanks
Rituraj
  
                
> http-remoting-jmx connection failure connecting to Undertow subsystem instead of Undertow management
> ----------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-3051
>                 URL: https://issues.jboss.org/browse/WFLY-3051
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JMX, Remoting
>    Affects Versions: 8.0.0.Final
>            Reporter: Rituraj Sinha
>            Assignee: Darran Lofthouse
>            Priority: Critical
>             Fix For: 8.0.1.Final
>
>
> i have gone through the below link for JMX subsystem for wildfly 8 as
> https://docs.jboss.org/author/display/WFLY8/JMX+subsystem+configuration
>  
> but unable to connect to server-instances running remotely ...i have posted my question there as well and pasting it here now ...
> can someone please give us the steps to configure JMX through jconsole...?
> changes done on the domain.xml are the same as stated above
> <subsystem xmlns="urn:jboss:domain:jmx:1.3">
>                 <expose-resolved-model/>
>                 <expose-expression-model/>
>                 <remoting-connector use-management-endpoint="false"/>
>             </subsystem>
> <subsystem xmlns="urn:jboss:domain:jmx:1.3">
>                 <expose-resolved-model/>
>                 <expose-expression-model/>
>                 <remoting-connector use-management-endpoint="false"/>
>             </subsystem>
> as per the jboss-as-jmx_1_3.xsd  its like
> <xs:attribute name="use-management-endpoint" type="xs:boolean" default="true" use="optional" >
>             <xs:annotation>
>                 <xs:documentation>
>                     If true then this connector will use the management endpoint, otherwise it will use the
>                     remoting subsystem endpoint.
>                 </xs:documentation>
>             </xs:annotation>
>         </xs:attribute>
> now if we are making it false then it should be using the remoting endpoint ...now remoting subsystem by default uses ApplicatoinRealm
> i have created application-user and password for the same but when i am trying to connect to remote server-instances its not connecting it....
> below is what i am able to connect to 
> service:jmx:http-remoting-jmx://remote_hostA:9990 --
> Unknown macro: {host A is where my domain_controller is running}
> how can i access the server-instances running on domain_controller
> Unknown macro: {there are three server_instanaces running on HostA with a port offset of 100 each}
> i am trying to connect with the below url as 
> service:jmx:http-remoting-jmx://lremote_hostA:8180
> let me know if something is missing from my side...
> Thanks

--
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

From issues at jboss.org  Sat Mar  8 06:17:34 2014
From: issues at jboss.org (Rituraj Sinha (JIRA))
Date: Sat, 8 Mar 2014 06:17:34 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3051) http-remoting-jmx connection
 failure connecting to Undertow subsystem instead of Undertow management
In-Reply-To: <JIRA.12533723.1393825342000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12533723.1393825342000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12533723.1393825342000.13701.1394277454032@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-3051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12951326#comment-12951326 ] 

Rituraj Sinha edited comment on WFLY-3051 at 3/8/14 6:17 AM:
-------------------------------------------------------------

Hi Darran,

we have a situation where we want to secure our JMX console as well...on the basis of roles ...there is a requirement where team wants to have access to JMX but it should only be Read Only...

As wildfly supports RBAC(i feel its only for management tasks) ...i have created a application user and password assigned a Monitoring group to it ...is it possible that it can take one of the roles predefined in RBAC and when it logs in with these credentials they can only monitor the stuff as it there on the web_management condole...?

can the user created in the application realm also get the privilege of predefined Roles (like Monitor) and access associated with it to connect to JMX..so that they can get the access but cant do anything there...?

Thanks
Rituraj
  
                
      was (Author: rituraj):
    Hi Darran,

we have a situation where we want to secure our JMX console as well...on the basis of roles ...there is a requirement where team wants to have access to JMX but it should only be Read Only...

As wildfly supports RBAC(i feel its only for management tasks) ...i have created a application user and password assigned a Monitoring group to it ...is it possible that it can take one of the roles predefined in RBAC and when it logs in with these credentials they can only monitor the stuff as it there on the web_management condole...?

can the user craeted in the application realm also get the privilege of predefined Roles (like Monitor) and access associated with it to connect to JMX..so that they can get the access but cant do anything there...?

Thanks
Rituraj
  
                  
> http-remoting-jmx connection failure connecting to Undertow subsystem instead of Undertow management
> ----------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-3051
>                 URL: https://issues.jboss.org/browse/WFLY-3051
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JMX, Remoting
>    Affects Versions: 8.0.0.Final
>            Reporter: Rituraj Sinha
>            Assignee: Darran Lofthouse
>            Priority: Critical
>             Fix For: 8.0.1.Final
>
>
> i have gone through the below link for JMX subsystem for wildfly 8 as
> https://docs.jboss.org/author/display/WFLY8/JMX+subsystem+configuration
>  
> but unable to connect to server-instances running remotely ...i have posted my question there as well and pasting it here now ...
> can someone please give us the steps to configure JMX through jconsole...?
> changes done on the domain.xml are the same as stated above
> <subsystem xmlns="urn:jboss:domain:jmx:1.3">
>                 <expose-resolved-model/>
>                 <expose-expression-model/>
>                 <remoting-connector use-management-endpoint="false"/>
>             </subsystem>
> <subsystem xmlns="urn:jboss:domain:jmx:1.3">
>                 <expose-resolved-model/>
>                 <expose-expression-model/>
>                 <remoting-connector use-management-endpoint="false"/>
>             </subsystem>
> as per the jboss-as-jmx_1_3.xsd  its like
> <xs:attribute name="use-management-endpoint" type="xs:boolean" default="true" use="optional" >
>             <xs:annotation>
>                 <xs:documentation>
>                     If true then this connector will use the management endpoint, otherwise it will use the
>                     remoting subsystem endpoint.
>                 </xs:documentation>
>             </xs:annotation>
>         </xs:attribute>
> now if we are making it false then it should be using the remoting endpoint ...now remoting subsystem by default uses ApplicatoinRealm
> i have created application-user and password for the same but when i am trying to connect to remote server-instances its not connecting it....
> below is what i am able to connect to 
> service:jmx:http-remoting-jmx://remote_hostA:9990 --
> Unknown macro: {host A is where my domain_controller is running}
> how can i access the server-instances running on domain_controller
> Unknown macro: {there are three server_instanaces running on HostA with a port offset of 100 each}
> i am trying to connect with the below url as 
> service:jmx:http-remoting-jmx://lremote_hostA:8180
> let me know if something is missing from my side...
> Thanks

--
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

From issues at jboss.org  Sat Mar  8 06:56:33 2014
From: issues at jboss.org (Kyle Shanahan (JIRA))
Date: Sat, 8 Mar 2014 06:56:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (LOGMGR-104) SyslogHandler doesn't handle
 multi-byte characters correctly
In-Reply-To: <JIRA.12534488.1394268821000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534488.1394268821000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534488.1394268821000.13712.1394279793206@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/LOGMGR-104?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kyle Shanahan updated LOGMGR-104:
---------------------------------

         Description: 
SyslogHandler doesn't handle multi-byte characters correctly.

I tried to log multi-byte message with both of org.jboss.logmanager.handlers.SyslogHandler and org.apache.log4j.net.SyslogAppender for same message, only SyslogHandler output were corrupted.

Step to reproduce (It might need to define -Dfile.encoding=UTF-8 in _JAVA_OPTS): 

1. define a facility local1 at localhost and make syslog accept UDP packets.
2. define a logger:
{noformat}
/subsystem=logging/logger=utf8mb4log:add(level=INFO)
{noformat}
3. define a SyslogHandler:
{noformat}
/subsystem=logging/custom-handler=TEST_SH:add(class="org.jboss.logmanager.handlers.SyslogHandler", module="org.jboss.logmanager", formatter="SyslogHandler: %s%e", level=INFO, properties={serverHostname="localhost:514", facility="LOCAL_USE_1", truncate=false, maxLength=1024, syslogType="RFC3164" })
/subsystem=logging/logger=utf8mb4log:assign-handler(name=TEST_SH)
{noformat}
4. define a SyslogAppender:
{noformat}
/subsystem=logging/custom-handler=TEST_LOG4J:add(class="org.apache.log4j.net.SyslogAppender", module="org.apache.log4j", formatter="log4j: %s%e", level=INFO, properties={syslogHost="localhost:514", facility="local1"})
/subsystem=logging/logger=utf8mb4log:assign-handler(name=TEST_LOG4J)
{noformat}
5. get and deploy example project at https://github.com/lbtc-xxx/utf8mb4log
6. Access the servlet http://localhost:8080/utf8mb4log/

And you will get like this: (I can't put 4 byte UTF-8 characters here... because  database error occured):
{noformat}
Mar  8 17:29:09 UNKNOWN_HOSTNAME java[9896]: SyslogHandler: ????????????
{noformat}

I would send a pull request later.

  was:
SyslogHandler doesn't handle multi-byte characters correctly.

I tried to log multi-byte message with both of org.jboss.logmanager.handlers.SyslogHandler and org.apache.log4j.net.SyslogAppender for same message, only SyslogHandler output were corrupted.

Step to reproduce: 

1. define a facility local1 at localhost and make syslog accept UDP packets.
2. define a logger:
{noformat}
/subsystem=logging/logger=utf8mb4log:add(level=INFO)
{noformat}
3. define a SyslogHandler:
{noformat}
/subsystem=logging/custom-handler=TEST_SH:add(class="org.jboss.logmanager.handlers.SyslogHandler", module="org.jboss.logmanager", formatter="SyslogHandler: %s%e", level=INFO, properties={serverHostname="localhost:514", facility="LOCAL_USE_1", truncate=false, maxLength=1024, syslogType="RFC3164" })
/subsystem=logging/logger=utf8mb4log:assign-handler(name=TEST_SH)
{noformat}
4. define a SyslogAppender:
{noformat}
/subsystem=logging/custom-handler=TEST_LOG4J:add(class="org.apache.log4j.net.SyslogAppender", module="org.apache.log4j", formatter="log4j: %s%e", level=INFO, properties={syslogHost="localhost:514", facility="local1"})
/subsystem=logging/logger=utf8mb4log:assign-handler(name=TEST_LOG4J)
{noformat}
5. get and deploy example project at https://github.com/lbtc-xxx/utf8mb4log
6. Access the servlet http://localhost:8080/utf8mb4log/

And you will get like this: (I can't put 4 byte UTF-8 characters here... because  database error occured):
{noformat}
Mar  8 17:29:09 UNKNOWN_HOSTNAME java[9896]: SyslogHandler: ????????????
{noformat}

I would send a pull request later.

    Git Pull Request: https://github.com/jboss-logging/jboss-logmanager/pull/50

    
> SyslogHandler doesn't handle multi-byte characters correctly
> ------------------------------------------------------------
>
>                 Key: LOGMGR-104
>                 URL: https://issues.jboss.org/browse/LOGMGR-104
>             Project: JBoss Log Manager
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: core
>    Affects Versions: 1.5.2.Final
>         Environment: - WildFly 8.0.0.Final
> - Oracle JDK7u51
> - OS X 10.9.2
>            Reporter: Kyle Shanahan
>            Assignee: David Lloyd
>
> SyslogHandler doesn't handle multi-byte characters correctly.
> I tried to log multi-byte message with both of org.jboss.logmanager.handlers.SyslogHandler and org.apache.log4j.net.SyslogAppender for same message, only SyslogHandler output were corrupted.
> Step to reproduce (It might need to define -Dfile.encoding=UTF-8 in _JAVA_OPTS): 
> 1. define a facility local1 at localhost and make syslog accept UDP packets.
> 2. define a logger:
> {noformat}
> /subsystem=logging/logger=utf8mb4log:add(level=INFO)
> {noformat}
> 3. define a SyslogHandler:
> {noformat}
> /subsystem=logging/custom-handler=TEST_SH:add(class="org.jboss.logmanager.handlers.SyslogHandler", module="org.jboss.logmanager", formatter="SyslogHandler: %s%e", level=INFO, properties={serverHostname="localhost:514", facility="LOCAL_USE_1", truncate=false, maxLength=1024, syslogType="RFC3164" })
> /subsystem=logging/logger=utf8mb4log:assign-handler(name=TEST_SH)
> {noformat}
> 4. define a SyslogAppender:
> {noformat}
> /subsystem=logging/custom-handler=TEST_LOG4J:add(class="org.apache.log4j.net.SyslogAppender", module="org.apache.log4j", formatter="log4j: %s%e", level=INFO, properties={syslogHost="localhost:514", facility="local1"})
> /subsystem=logging/logger=utf8mb4log:assign-handler(name=TEST_LOG4J)
> {noformat}
> 5. get and deploy example project at https://github.com/lbtc-xxx/utf8mb4log
> 6. Access the servlet http://localhost:8080/utf8mb4log/
> And you will get like this: (I can't put 4 byte UTF-8 characters here... because  database error occured):
> {noformat}
> Mar  8 17:29:09 UNKNOWN_HOSTNAME java[9896]: SyslogHandler: ????????????
> {noformat}
> I would send a pull request later.

--
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

From issues at jboss.org  Sat Mar  8 06:58:33 2014
From: issues at jboss.org (Kyle Shanahan (JIRA))
Date: Sat, 8 Mar 2014 06:58:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (LOGMGR-104) SyslogHandler doesn't handle
 multi-byte characters correctly
In-Reply-To: <JIRA.12534488.1394268821000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534488.1394268821000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534488.1394268821000.13715.1394279913165@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/LOGMGR-104?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kyle Shanahan updated LOGMGR-104:
---------------------------------

    Description: 
SyslogHandler doesn't handle multi-byte characters correctly.

I tried to log multi-byte message with both of org.jboss.logmanager.handlers.SyslogHandler and org.apache.log4j.net.SyslogAppender for same message, only SyslogHandler output were corrupted.

Step to reproduce (It might need to define -Dfile.encoding=UTF-8 in _JAVA_OPTIONS): 

1. define a facility local1 at localhost and make syslog accept UDP packets.
2. define a logger:
{noformat}
/subsystem=logging/logger=utf8mb4log:add(level=INFO)
{noformat}
3. define a SyslogHandler:
{noformat}
/subsystem=logging/custom-handler=TEST_SH:add(class="org.jboss.logmanager.handlers.SyslogHandler", module="org.jboss.logmanager", formatter="SyslogHandler: %s%e", level=INFO, properties={serverHostname="localhost:514", facility="LOCAL_USE_1", truncate=false, maxLength=1024, syslogType="RFC3164" })
/subsystem=logging/logger=utf8mb4log:assign-handler(name=TEST_SH)
{noformat}
4. define a SyslogAppender:
{noformat}
/subsystem=logging/custom-handler=TEST_LOG4J:add(class="org.apache.log4j.net.SyslogAppender", module="org.apache.log4j", formatter="log4j: %s%e", level=INFO, properties={syslogHost="localhost:514", facility="local1"})
/subsystem=logging/logger=utf8mb4log:assign-handler(name=TEST_LOG4J)
{noformat}
5. get and deploy example project at https://github.com/lbtc-xxx/utf8mb4log
6. Access the servlet http://localhost:8080/utf8mb4log/

And you will get like this: (I can't put 4 byte UTF-8 characters here... because  database error occured):
{noformat}
Mar  8 17:29:09 UNKNOWN_HOSTNAME java[9896]: SyslogHandler: ????????????
{noformat}

I would send a pull request later.

  was:
SyslogHandler doesn't handle multi-byte characters correctly.

I tried to log multi-byte message with both of org.jboss.logmanager.handlers.SyslogHandler and org.apache.log4j.net.SyslogAppender for same message, only SyslogHandler output were corrupted.

Step to reproduce (It might need to define -Dfile.encoding=UTF-8 in _JAVA_OPTS): 

1. define a facility local1 at localhost and make syslog accept UDP packets.
2. define a logger:
{noformat}
/subsystem=logging/logger=utf8mb4log:add(level=INFO)
{noformat}
3. define a SyslogHandler:
{noformat}
/subsystem=logging/custom-handler=TEST_SH:add(class="org.jboss.logmanager.handlers.SyslogHandler", module="org.jboss.logmanager", formatter="SyslogHandler: %s%e", level=INFO, properties={serverHostname="localhost:514", facility="LOCAL_USE_1", truncate=false, maxLength=1024, syslogType="RFC3164" })
/subsystem=logging/logger=utf8mb4log:assign-handler(name=TEST_SH)
{noformat}
4. define a SyslogAppender:
{noformat}
/subsystem=logging/custom-handler=TEST_LOG4J:add(class="org.apache.log4j.net.SyslogAppender", module="org.apache.log4j", formatter="log4j: %s%e", level=INFO, properties={syslogHost="localhost:514", facility="local1"})
/subsystem=logging/logger=utf8mb4log:assign-handler(name=TEST_LOG4J)
{noformat}
5. get and deploy example project at https://github.com/lbtc-xxx/utf8mb4log
6. Access the servlet http://localhost:8080/utf8mb4log/

And you will get like this: (I can't put 4 byte UTF-8 characters here... because  database error occured):
{noformat}
Mar  8 17:29:09 UNKNOWN_HOSTNAME java[9896]: SyslogHandler: ????????????
{noformat}

I would send a pull request later.


    
> SyslogHandler doesn't handle multi-byte characters correctly
> ------------------------------------------------------------
>
>                 Key: LOGMGR-104
>                 URL: https://issues.jboss.org/browse/LOGMGR-104
>             Project: JBoss Log Manager
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: core
>    Affects Versions: 1.5.2.Final
>         Environment: - WildFly 8.0.0.Final
> - Oracle JDK7u51
> - OS X 10.9.2
>            Reporter: Kyle Shanahan
>            Assignee: David Lloyd
>
> SyslogHandler doesn't handle multi-byte characters correctly.
> I tried to log multi-byte message with both of org.jboss.logmanager.handlers.SyslogHandler and org.apache.log4j.net.SyslogAppender for same message, only SyslogHandler output were corrupted.
> Step to reproduce (It might need to define -Dfile.encoding=UTF-8 in _JAVA_OPTIONS): 
> 1. define a facility local1 at localhost and make syslog accept UDP packets.
> 2. define a logger:
> {noformat}
> /subsystem=logging/logger=utf8mb4log:add(level=INFO)
> {noformat}
> 3. define a SyslogHandler:
> {noformat}
> /subsystem=logging/custom-handler=TEST_SH:add(class="org.jboss.logmanager.handlers.SyslogHandler", module="org.jboss.logmanager", formatter="SyslogHandler: %s%e", level=INFO, properties={serverHostname="localhost:514", facility="LOCAL_USE_1", truncate=false, maxLength=1024, syslogType="RFC3164" })
> /subsystem=logging/logger=utf8mb4log:assign-handler(name=TEST_SH)
> {noformat}
> 4. define a SyslogAppender:
> {noformat}
> /subsystem=logging/custom-handler=TEST_LOG4J:add(class="org.apache.log4j.net.SyslogAppender", module="org.apache.log4j", formatter="log4j: %s%e", level=INFO, properties={syslogHost="localhost:514", facility="local1"})
> /subsystem=logging/logger=utf8mb4log:assign-handler(name=TEST_LOG4J)
> {noformat}
> 5. get and deploy example project at https://github.com/lbtc-xxx/utf8mb4log
> 6. Access the servlet http://localhost:8080/utf8mb4log/
> And you will get like this: (I can't put 4 byte UTF-8 characters here... because  database error occured):
> {noformat}
> Mar  8 17:29:09 UNKNOWN_HOSTNAME java[9896]: SyslogHandler: ????????????
> {noformat}
> I would send a pull request later.

--
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

From issues at jboss.org  Sat Mar  8 09:20:33 2014
From: issues at jboss.org (Eduardo Martins (JIRA))
Date: Sat, 8 Mar 2014 09:20:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2977) Nullpointer when Checking
 role for anonymous caller
In-Reply-To: <JIRA.12532803.1392898889000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12532803.1392898889000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12532803.1392898889000.13728.1394288433487@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2977?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Eduardo Martins reassigned WFLY-2977:
-------------------------------------

    Assignee: Eduardo Martins  (was: David Lloyd)

    
> Nullpointer when Checking role for anonymous caller
> ---------------------------------------------------
>
>                 Key: WFLY-2977
>                 URL: https://issues.jboss.org/browse/WFLY-2977
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: EJB
>    Affects Versions: 8.0.0.Final
>            Reporter: Markus D
>            Assignee: Eduardo Martins
>
> When calling a rest service without authentication i receive a nullpointer when doing:
> 	@Resource
> 	private SessionContext ctx;
> This is enough to produce a nullpointer as guest:
> ctx.isCallerInRole("ADMIN_ROLE")
> Should return false imho.
> greetings,
> m
> {noformat}
> 13:16:23,714 ERROR [org.jboss.as.ejb3.invocation] (default task-2) JBAS014134: EJB Invocation failed on component PlayerFacade for method public net.dice.dto.player.PlayerResponseDTO net.dice.facade.PlayerFacade.createIncognitoPlayer(net.dice.lang.Language): javax.ejb.EJBException: java.lang.NullPointerException
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.handleExceptionInOurTx(CMTTxInterceptor.java:190) [wildfly-ejb3-8.0.0.Final.jar:8.0.0.Final]
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:275) [wildfly-ejb3-8.0.0.Final.jar:8.0.0.Final]
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:340) [wildfly-ejb3-8.0.0.Final.jar:8.0.0.Final]
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:239) [wildfly-ejb3-8.0.0.Final.jar:8.0.0.Final]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> 	at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41) [wildfly-ejb3-8.0.0.Final.jar:8.0.0.Final]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> 	at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:43) [wildfly-ejb3-8.0.0.Final.jar:8.0.0.Final]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> 	at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64) [wildfly-ejb3-8.0.0.Final.jar:8.0.0.Final]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> 	at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:59) [wildfly-ejb3-8.0.0.Final.jar:8.0.0.Final]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> 	at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> 	at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:55) [wildfly-ejb3-8.0.0.Final.jar:8.0.0.Final]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> 	at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> 	at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:326)
> 	at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:448)
> 	at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> 	at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:326)
> 	at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:185)
> 	at org.jboss.as.ee.component.ViewDescription$1.processInvocation(ViewDescription.java:182)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocationHandler.java:73)
> 	at net.dice.facade.PlayerFacade$$$view3.createIncognitoPlayer(Unknown Source) [classes:]
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_51]
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_51]
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_51]
> 	at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_51]
> 	at org.jboss.weld.util.reflection.Reflections.invokeAndUnwrap(Reflections.java:401) [weld-core-impl-2.1.2.Final.jar:2014-01-09 09:23]
> 	at org.jboss.weld.bean.proxy.EnterpriseBeanProxyMethodHandler.invoke(EnterpriseBeanProxyMethodHandler.java:99) [weld-core-impl-2.1.2.Final.jar:2014-01-09 09:23]
> 	at org.jboss.weld.bean.proxy.EnterpriseTargetBeanInstance.invoke(EnterpriseTargetBeanInstance.java:56) [weld-core-impl-2.1.2.Final.jar:2014-01-09 09:23]
> 	at org.jboss.weld.bean.proxy.InjectionPointPropagatingEnterpriseTargetBeanInstance.invoke(InjectionPointPropagatingEnterpriseTargetBeanInstance.java:65) [weld-core-impl-2.1.2.Final.jar:2014-01-09 09:23]
> 	at org.jboss.weld.bean.proxy.ProxyMethodHandler.invoke(ProxyMethodHandler.java:100) [weld-core-impl-2.1.2.Final.jar:2014-01-09 09:23]
> 	at net.dice.facade.PlayerFacade$Proxy$_$$_Weld$EnterpriseProxy$.createIncognitoPlayer(Unknown Source) [classes:]
> 	at net.dice.facade.TestResource.test(TestResource.java:17) [classes:]
> 	at net.dice.facade.TestResource$Proxy$_$$_WeldClientProxy.test(Unknown Source) [classes:]
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_51]
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_51]
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_51]
> 	at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_51]
> 	at org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:137) [resteasy-jaxrs-3.0.6.Final.jar:]
> 	at org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget(ResourceMethodInvoker.java:280) [resteasy-jaxrs-3.0.6.Final.jar:]
> 	at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:234) [resteasy-jaxrs-3.0.6.Final.jar:]
> 	at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:221) [resteasy-jaxrs-3.0.6.Final.jar:]
> 	at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:356) [resteasy-jaxrs-3.0.6.Final.jar:]
> 	at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:179) [resteasy-jaxrs-3.0.6.Final.jar:]
> 	at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:220) [resteasy-jaxrs-3.0.6.Final.jar:]
> 	at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56) [resteasy-jaxrs-3.0.6.Final.jar:]
> 	at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51) [resteasy-jaxrs-3.0.6.Final.jar:]
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) [jboss-servlet-api_3.1_spec-1.0.0.Final.jar:1.0.0.Final]
> 	at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85) [undertow-servlet-1.0.0.Final.jar:1.0.0.Final]
> 	at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:130) [undertow-servlet-1.0.0.Final.jar:1.0.0.Final]
> 	at net.dice.auth.BasicAuthFilter.doFilter(BasicAuthFilter.java:76) [classes:]
> 	at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:56) [undertow-servlet-1.0.0.Final.jar:1.0.0.Final]
> 	at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132) [undertow-servlet-1.0.0.Final.jar:1.0.0.Final]
> 	at net.dice.filter.DiceFilter.doFilter(DiceFilter.java:48) [classes:]
> 	at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:56) [undertow-servlet-1.0.0.Final.jar:1.0.0.Final]
> 	at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132) [undertow-servlet-1.0.0.Final.jar:1.0.0.Final]
> 	at io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:85) [undertow-servlet-1.0.0.Final.jar:1.0.0.Final]
> 	at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:61) [undertow-servlet-1.0.0.Final.jar:1.0.0.Final]
> 	at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.0.0.Final.jar:1.0.0.Final]
> 	at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Final.jar:1.0.0.Final]
> 	at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:113) [undertow-servlet-1.0.0.Final.jar:1.0.0.Final]
> 	at io.undertow.security.handlers.AuthenticationCallHandler.handleRequest(AuthenticationCallHandler.java:52) [undertow-core-1.0.0.Final.jar:1.0.0.Final]
> 	at io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:51) [undertow-core-1.0.0.Final.jar:1.0.0.Final]
> 	at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) [undertow-core-1.0.0.Final.jar:1.0.0.Final]
> 	at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:61) [undertow-servlet-1.0.0.Final.jar:1.0.0.Final]
> 	at io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:56) [undertow-servlet-1.0.0.Final.jar:1.0.0.Final]
> 	at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58) [undertow-core-1.0.0.Final.jar:1.0.0.Final]
> 	at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:70) [undertow-servlet-1.0.0.Final.jar:1.0.0.Final]
> 	at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76) [undertow-core-1.0.0.Final.jar:1.0.0.Final]
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Final.jar:1.0.0.Final]
> 	at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Final.jar:1.0.0.Final]
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Final.jar:1.0.0.Final]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:240) [undertow-servlet-1.0.0.Final.jar:1.0.0.Final]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:227) [undertow-servlet-1.0.0.Final.jar:1.0.0.Final]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:73) [undertow-servlet-1.0.0.Final.jar:1.0.0.Final]
> 	at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:146) [undertow-servlet-1.0.0.Final.jar:1.0.0.Final]
> 	at io.undertow.server.Connectors.executeRootHandler(Connectors.java:168) [undertow-core-1.0.0.Final.jar:1.0.0.Final]
> 	at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:687) [undertow-core-1.0.0.Final.jar:1.0.0.Final]
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_51]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_51]
> 	at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_51]
> Caused by: java.lang.NullPointerException
> 	at org.jboss.as.security.service.SimpleSecurityManager.isCallerInRole(SimpleSecurityManager.java:209) [wildfly-security-8.0.0.Final.jar:8.0.0.Final]
> 	at org.jboss.as.ejb3.component.EJBComponent.isCallerInRole(EJBComponent.java:373) [wildfly-ejb3-8.0.0.Final.jar:8.0.0.Final]
> 	at org.jboss.as.ejb3.context.EJBContextImpl.isCallerInRole(EJBContextImpl.java:114) [wildfly-ejb3-8.0.0.Final.jar:8.0.0.Final]
> 	at net.dice.facade.PlayerFacade.createIncognitoPlayer(PlayerFacade.java:122) [classes:]
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_51]
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_51]
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_51]
> 	at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_51]
> 	at org.jboss.as.ee.component.ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptor.java:52)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> 	at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53)
> 	at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> 	at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:407)
> 	at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:82) [wildfly-weld-8.0.0.Final.jar:8.0.0.Final]
> 	at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:93) [wildfly-weld-8.0.0.Final.jar:8.0.0.Final]
> 	at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> 	at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53)
> 	at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> 	at org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43) [wildfly-ejb3-8.0.0.Final.jar:8.0.0.Final]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> 	at org.jboss.as.jpa.interceptor.SBInvocationInterceptor.processInvocation(SBInvocationInterceptor.java:47) [wildfly-jpa-8.0.0.Final.jar:8.0.0.Final]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> 	at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:407)
> 	at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:46) [weld-core-impl-2.1.2.Final.jar:2014-01-09 09:23]
> 	at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:83) [wildfly-weld-8.0.0.Final.jar:8.0.0.Final]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> 	at org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45) [wildfly-ee-8.0.0.Final.jar:8.0.0.Final]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> 	at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:53)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> 	at org.jboss.as.ejb3.component.interceptors.NonPooledEJBComponentInstanceAssociatingInterceptor.processInvocation(NonPooledEJBComponentInstanceAssociatingInterceptor.java:59) [wildfly-ejb3-8.0.0.Final.jar:8.0.0.Final]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:273) [wildfly-ejb3-8.0.0.Final.jar:8.0.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

From issues at jboss.org  Sat Mar  8 09:24:33 2014
From: issues at jboss.org (Eduardo Martins (JIRA))
Date: Sat, 8 Mar 2014 09:24:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3088) Cannot Inject Validator using
	@Inject
In-Reply-To: <JIRA.12534463.1394223939000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534463.1394223939000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534463.1394223939000.13739.1394288673987@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-3088?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Eduardo Martins reassigned WFLY-3088:
-------------------------------------

    Assignee: Eduardo Martins  (was: Stuart Douglas)

    
> Cannot Inject Validator using @Inject
> -------------------------------------
>
>                 Key: WFLY-3088
>                 URL: https://issues.jboss.org/browse/WFLY-3088
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: CDI / Weld
>    Affects Versions: 8.0.0.Final
>            Reporter: Sat B
>            Assignee: Eduardo Martins
>
> I have a very simple bean and I am trying to inject the Validator using the @Inject annotation. But I am ending up getting a null when I try to use the Validator. I have the beans.xml defined to bean-discovery-mode="all". Below is the code
> --------
> import javax.inject.Inject;
> import javax.validation.ConstraintViolation;
> import javax.validation.Validation;
> import javax.validation.Validator;
> import javax.validation.ValidatorFactory;
> import javax.validation.constraints.*;
> import java.util.Map;
> import java.util.Set;
> public class SimpleCommand {
>     @Inject
>     private Validator validator;
>    
>     @Email
>     private String email;
>     
>     public SimpleCommand(){
>     }
>     public SimpleCommand(Map<String, String[]> params){
>         this.email = params.get("email")!=null ? params.get("email")[0] : null;
>     }
>     public void validate(){
>         //USING VALIDATOR THAT IS INJECTED IS NULL HERE
>         //USING THE BELOW METHOD WORKS
>         ValidatorFactory factory = Validation.buildDefaultValidatorFactory();
>         Validator validator1 = factory.getValidator();
>         Set<ConstraintViolation<SimpleCommand>> contstraintViolations = validator1.validate(this); //USING INJECTED VALIDATOR WILL THROW NULL POINTER EXCEPTION
>         for (ConstraintViolation<SimpleCommand> violation : contstraintViolations){
>             System.out.println(violation.getMessage());
>         }
>     }
> }
> --------
> Then, from a JAX-RS controller, I call this validator
> ------
> SimpleCommand cmd = new SimpleCommand(req.getParameterMap());
>         cmd.validate();
> -----

--
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

From issues at jboss.org  Sat Mar  8 09:30:33 2014
From: issues at jboss.org (Eduardo Martins (JIRA))
Date: Sat, 8 Mar 2014 09:30:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3088) Cannot Inject Validator using
	@Inject
In-Reply-To: <JIRA.12534463.1394223939000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534463.1394223939000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534463.1394223939000.13741.1394289033819@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-3088?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12951330#comment-12951330 ] 

Eduardo Martins commented on WFLY-3088:
---------------------------------------

Please attach the server.log.

Also, it would be great if you could attach the deployments that would allow us to replicate the issue.
                
> Cannot Inject Validator using @Inject
> -------------------------------------
>
>                 Key: WFLY-3088
>                 URL: https://issues.jboss.org/browse/WFLY-3088
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: CDI / Weld
>    Affects Versions: 8.0.0.Final
>            Reporter: Sat B
>            Assignee: Eduardo Martins
>
> I have a very simple bean and I am trying to inject the Validator using the @Inject annotation. But I am ending up getting a null when I try to use the Validator. I have the beans.xml defined to bean-discovery-mode="all". Below is the code
> --------
> import javax.inject.Inject;
> import javax.validation.ConstraintViolation;
> import javax.validation.Validation;
> import javax.validation.Validator;
> import javax.validation.ValidatorFactory;
> import javax.validation.constraints.*;
> import java.util.Map;
> import java.util.Set;
> public class SimpleCommand {
>     @Inject
>     private Validator validator;
>    
>     @Email
>     private String email;
>     
>     public SimpleCommand(){
>     }
>     public SimpleCommand(Map<String, String[]> params){
>         this.email = params.get("email")!=null ? params.get("email")[0] : null;
>     }
>     public void validate(){
>         //USING VALIDATOR THAT IS INJECTED IS NULL HERE
>         //USING THE BELOW METHOD WORKS
>         ValidatorFactory factory = Validation.buildDefaultValidatorFactory();
>         Validator validator1 = factory.getValidator();
>         Set<ConstraintViolation<SimpleCommand>> contstraintViolations = validator1.validate(this); //USING INJECTED VALIDATOR WILL THROW NULL POINTER EXCEPTION
>         for (ConstraintViolation<SimpleCommand> violation : contstraintViolations){
>             System.out.println(violation.getMessage());
>         }
>     }
> }
> --------
> Then, from a JAX-RS controller, I call this validator
> ------
> SimpleCommand cmd = new SimpleCommand(req.getParameterMap());
>         cmd.validate();
> -----

--
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

From issues at jboss.org  Sat Mar  8 18:55:33 2014
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Sat, 8 Mar 2014 18:55:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3091) Cancellation of management
 ops does not properly propagate to server update tasks
In-Reply-To: <JIRA.12534498.1394322863870@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534498.1394322863870@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534498.1394322863870.13829.1394322933478@jira02.app.mwc.hst.phx2.redhat.com>

Brian Stansberry created WFLY-3091:
--------------------------------------

             Summary: Cancellation of management ops does not properly propagate to server update tasks
                 Key: WFLY-3091
                 URL: https://issues.jboss.org/browse/WFLY-3091
             Project: WildFly
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Domain Management
    Affects Versions: 8.0.0.Final
            Reporter: Brian Stansberry
            Assignee: Brian Stansberry
             Fix For: 8.0.1.Final


When an op is cancelled on a managed domain after the domain rollout has begun, the server update tasks are not properly cancelled / cleaned up.

--
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

From issues at jboss.org  Sat Mar  8 18:57:33 2014
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Sat, 8 Mar 2014 18:57:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3092) ServerUpdateResultHandler
	does nothing
In-Reply-To: <JIRA.12534499.1394322985397@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534499.1394322985397@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534499.1394322985397.13832.1394323053324@jira02.app.mwc.hst.phx2.redhat.com>

Brian Stansberry created WFLY-3092:
--------------------------------------

             Summary: ServerUpdateResultHandler does nothing
                 Key: WFLY-3092
                 URL: https://issues.jboss.org/browse/WFLY-3092
             Project: WildFly
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Domain Management
    Affects Versions: 8.0.0.Final
            Reporter: Brian Stansberry
            Assignee: Brian Stansberry
             Fix For: 8.0.1.Final


The domain op rollout logic's AbstractServerUpdateTask.ServerUpdateResultHandler interface is serving no purpose and should be removed. It's cruft left from earlier implementations.

The only impl stores data in a map that never gets read. 

--
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

From issues at jboss.org  Sun Mar  9 11:10:33 2014
From: issues at jboss.org (Juergen Zimmermann (JIRA))
Date: Sun, 9 Mar 2014 11:10:33 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3093) Undertow doesn't show the
 correct error page (401)
In-Reply-To: <JIRA.12534502.1394377769457@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534502.1394377769457@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534502.1394377769457.13892.1394377833342@jira02.app.mwc.hst.phx2.redhat.com>

Juergen Zimmermann created WFLY-3093:
----------------------------------------

             Summary: Undertow doesn't show the correct error page (401)
                 Key: WFLY-3093
                 URL: https://issues.jboss.org/browse/WFLY-3093
             Project: WildFly
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Web (Undertow)
    Affects Versions: 8.0.0.Final
            Reporter: Juergen Zimmermann
            Assignee: Stuart Douglas


I'm using the WildFly snapshot from last Thursday with Undertow 1.0.1.
When I try to invoke a protected web page, I'm getting an almost blank web page with just the contents "401 - Unauthorized".
However, in WEB-INF/web.xml I'm having this declaration:
{code}
<error-page>
    <error-code>401</error-code>
    <location>/rf/error/accessDenied.jsf</location>
</error-page>
{code}

--
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

From issues at jboss.org  Sun Mar  9 11:14:33 2014
From: issues at jboss.org (Juergen Zimmermann (JIRA))
Date: Sun, 9 Mar 2014 11:14:33 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3093) Undertow doesn't show the
 correct error page (401)
In-Reply-To: <JIRA.12534502.1394377769000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534502.1394377769000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534502.1394377769000.13896.1394378073237@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-3093?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12951353#comment-12951353 ] 

Juergen Zimmermann commented on WFLY-3093:
------------------------------------------

To reproduce:
1) Deploy a web app with BASIC authentication
2) Invoke a protected page in a webbrowser
3) Ignore the browser's dialog box for BASIC authentication
4) The page with "401 - Unauthorized" appears.
                
> Undertow doesn't show the correct error page (401)
> --------------------------------------------------
>
>                 Key: WFLY-3093
>                 URL: https://issues.jboss.org/browse/WFLY-3093
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web (Undertow)
>    Affects Versions: 8.0.0.Final
>            Reporter: Juergen Zimmermann
>            Assignee: Stuart Douglas
>
> I'm using the WildFly snapshot from last Thursday with Undertow 1.0.1.
> When I try to invoke a protected web page, I'm getting an almost blank web page with just the contents "401 - Unauthorized".
> However, in WEB-INF/web.xml I'm having this declaration:
> {code}
> <error-page>
>     <error-code>401</error-code>
>     <location>/rf/error/accessDenied.jsf</location>
> </error-page>
> {code}

--
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

From issues at jboss.org  Sun Mar  9 12:38:33 2014
From: issues at jboss.org (David Lloyd (JIRA))
Date: Sun, 9 Mar 2014 12:38:33 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (LOGMGR-104) SyslogHandler doesn't handle
 multi-byte characters correctly
In-Reply-To: <JIRA.12534488.1394268821000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534488.1394268821000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534488.1394268821000.13900.1394383113410@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/LOGMGR-104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12951354#comment-12951354 ] 

David Lloyd commented on LOGMGR-104:
------------------------------------

I'm thinking the issue isn't multi-byte characters, it's surrogate pairs.
                
> SyslogHandler doesn't handle multi-byte characters correctly
> ------------------------------------------------------------
>
>                 Key: LOGMGR-104
>                 URL: https://issues.jboss.org/browse/LOGMGR-104
>             Project: JBoss Log Manager
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: core
>    Affects Versions: 1.5.2.Final
>         Environment: - WildFly 8.0.0.Final
> - Oracle JDK7u51
> - OS X 10.9.2
>            Reporter: Kyle Shanahan
>            Assignee: David Lloyd
>
> SyslogHandler doesn't handle multi-byte characters correctly.
> I tried to log multi-byte message with both of org.jboss.logmanager.handlers.SyslogHandler and org.apache.log4j.net.SyslogAppender for same message, only SyslogHandler output were corrupted.
> Step to reproduce (It might need to define -Dfile.encoding=UTF-8 in _JAVA_OPTIONS): 
> 1. define a facility local1 at localhost and make syslog accept UDP packets.
> 2. define a logger:
> {noformat}
> /subsystem=logging/logger=utf8mb4log:add(level=INFO)
> {noformat}
> 3. define a SyslogHandler:
> {noformat}
> /subsystem=logging/custom-handler=TEST_SH:add(class="org.jboss.logmanager.handlers.SyslogHandler", module="org.jboss.logmanager", formatter="SyslogHandler: %s%e", level=INFO, properties={serverHostname="localhost:514", facility="LOCAL_USE_1", truncate=false, maxLength=1024, syslogType="RFC3164" })
> /subsystem=logging/logger=utf8mb4log:assign-handler(name=TEST_SH)
> {noformat}
> 4. define a SyslogAppender:
> {noformat}
> /subsystem=logging/custom-handler=TEST_LOG4J:add(class="org.apache.log4j.net.SyslogAppender", module="org.apache.log4j", formatter="log4j: %s%e", level=INFO, properties={syslogHost="localhost:514", facility="local1"})
> /subsystem=logging/logger=utf8mb4log:assign-handler(name=TEST_LOG4J)
> {noformat}
> 5. get and deploy example project at https://github.com/lbtc-xxx/utf8mb4log
> 6. Access the servlet http://localhost:8080/utf8mb4log/
> And you will get like this: (I can't put 4 byte UTF-8 characters here... because  database error occured):
> {noformat}
> Mar  8 17:29:09 UNKNOWN_HOSTNAME java[9896]: SyslogHandler: ????????????
> {noformat}
> I would send a pull request later.

--
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

From issues at jboss.org  Sun Mar  9 15:38:33 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Sun, 9 Mar 2014 15:38:33 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3077) Convert command line IPv6 URL
 literals to address literals
In-Reply-To: <JIRA.12534346.1394155395000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534346.1394155395000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534346.1394155395000.13943.1394393913511@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-3077?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12951363#comment-12951363 ] 

RH Bugzilla Integration commented on WFLY-3077:
-----------------------------------------------

Kabir Khan <kkhan at redhat.com> changed the Status of [bug 1064771|https://bugzilla.redhat.com/show_bug.cgi?id=1064771] from POST to MODIFIED
                
> Convert command line IPv6 URL literals to address literals
> ----------------------------------------------------------
>
>                 Key: WFLY-3077
>                 URL: https://issues.jboss.org/browse/WFLY-3077
>             Project: WildFly
>          Issue Type: Enhancement
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 8.0.0.Final
>            Reporter: Brian Stansberry
>            Assignee: Brian Stansberry
>            Priority: Minor
>             Fix For: 8.0.1.Final
>
>
> When people provide URL-style values like [::1] for command line args like -b, convert them to address values (i.e. strip the enclosing brackets.)

--
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

From issues at jboss.org  Sun Mar  9 15:42:33 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Sun, 9 Mar 2014 15:42:33 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3007) Ipv6 addresses may not be
 canonized properly
In-Reply-To: <JIRA.12533139.1393261818000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12533139.1393261818000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12533139.1393261818000.13950.1394394153725@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-3007?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12951365#comment-12951365 ] 

RH Bugzilla Integration commented on WFLY-3007:
-----------------------------------------------

Kabir Khan <kkhan at redhat.com> changed the Status of [bug 1067348|https://bugzilla.redhat.com/show_bug.cgi?id=1067348] from POST to MODIFIED
                
> Ipv6 addresses may not be canonized properly
> --------------------------------------------
>
>                 Key: WFLY-3007
>                 URL: https://issues.jboss.org/browse/WFLY-3007
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 8.0.0.Final
>            Reporter: Emmanuel Hugonnet
>            Assignee: Emmanuel Hugonnet
>
> On an ipv6 environment we may obtain IP addresses that are not properly canonized which may lead to strange issue with http proxies since the JDK ProxySelector relies on char per char matching.
> All call to InetAddress.getHostName() may produce such an uncanonized address.

--
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

From issues at jboss.org  Sun Mar  9 16:04:33 2014
From: issues at jboss.org (Rituraj Sinha (JIRA))
Date: Sun, 9 Mar 2014 16:04:33 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3051) http-remoting-jmx connection
 failure connecting to Undertow subsystem instead of Undertow management
In-Reply-To: <JIRA.12533723.1393825342000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12533723.1393825342000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12533723.1393825342000.13960.1394395473483@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-3051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12951366#comment-12951366 ] 

Rituraj Sinha commented on WFLY-3051:
-------------------------------------

I have created a seperate discussion for it as well....
https://community.jboss.org/message/861415#861415

Thanks 
Rituraj
                
> http-remoting-jmx connection failure connecting to Undertow subsystem instead of Undertow management
> ----------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-3051
>                 URL: https://issues.jboss.org/browse/WFLY-3051
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JMX, Remoting
>    Affects Versions: 8.0.0.Final
>            Reporter: Rituraj Sinha
>            Assignee: Darran Lofthouse
>            Priority: Critical
>             Fix For: 8.0.1.Final
>
>
> i have gone through the below link for JMX subsystem for wildfly 8 as
> https://docs.jboss.org/author/display/WFLY8/JMX+subsystem+configuration
>  
> but unable to connect to server-instances running remotely ...i have posted my question there as well and pasting it here now ...
> can someone please give us the steps to configure JMX through jconsole...?
> changes done on the domain.xml are the same as stated above
> <subsystem xmlns="urn:jboss:domain:jmx:1.3">
>                 <expose-resolved-model/>
>                 <expose-expression-model/>
>                 <remoting-connector use-management-endpoint="false"/>
>             </subsystem>
> <subsystem xmlns="urn:jboss:domain:jmx:1.3">
>                 <expose-resolved-model/>
>                 <expose-expression-model/>
>                 <remoting-connector use-management-endpoint="false"/>
>             </subsystem>
> as per the jboss-as-jmx_1_3.xsd  its like
> <xs:attribute name="use-management-endpoint" type="xs:boolean" default="true" use="optional" >
>             <xs:annotation>
>                 <xs:documentation>
>                     If true then this connector will use the management endpoint, otherwise it will use the
>                     remoting subsystem endpoint.
>                 </xs:documentation>
>             </xs:annotation>
>         </xs:attribute>
> now if we are making it false then it should be using the remoting endpoint ...now remoting subsystem by default uses ApplicatoinRealm
> i have created application-user and password for the same but when i am trying to connect to remote server-instances its not connecting it....
> below is what i am able to connect to 
> service:jmx:http-remoting-jmx://remote_hostA:9990 --
> Unknown macro: {host A is where my domain_controller is running}
> how can i access the server-instances running on domain_controller
> Unknown macro: {there are three server_instanaces running on HostA with a port offset of 100 each}
> i am trying to connect with the below url as 
> service:jmx:http-remoting-jmx://lremote_hostA:8180
> let me know if something is missing from my side...
> Thanks

--
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

From issues at jboss.org  Sun Mar  9 18:11:33 2014
From: issues at jboss.org (Kyle Shanahan (JIRA))
Date: Sun, 9 Mar 2014 18:11:33 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (LOGMGR-104) SyslogHandler doesn't handle
 multi-byte characters correctly
In-Reply-To: <JIRA.12534488.1394268821000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534488.1394268821000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534488.1394268821000.13975.1394403093225@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/LOGMGR-104?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kyle Shanahan updated LOGMGR-104:
---------------------------------

    Attachment: corrupted.png
                corrupted2.png
                corrupted3.png


Sorry, my examples doesn't have enough patterns.
Well, let's see some examples:

- Logging code !corrupted.png!
                
> SyslogHandler doesn't handle multi-byte characters correctly
> ------------------------------------------------------------
>
>                 Key: LOGMGR-104
>                 URL: https://issues.jboss.org/browse/LOGMGR-104
>             Project: JBoss Log Manager
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: core
>    Affects Versions: 1.5.2.Final
>         Environment: - WildFly 8.0.0.Final
> - Oracle JDK7u51
> - OS X 10.9.2
>            Reporter: Kyle Shanahan
>            Assignee: David Lloyd
>         Attachments: corrupted.png, corrupted2.png, corrupted3.png
>
>
> SyslogHandler doesn't handle multi-byte characters correctly.
> I tried to log multi-byte message with both of org.jboss.logmanager.handlers.SyslogHandler and org.apache.log4j.net.SyslogAppender for same message, only SyslogHandler output were corrupted.
> Step to reproduce (It might need to define -Dfile.encoding=UTF-8 in _JAVA_OPTIONS): 
> 1. define a facility local1 at localhost and make syslog accept UDP packets.
> 2. define a logger:
> {noformat}
> /subsystem=logging/logger=utf8mb4log:add(level=INFO)
> {noformat}
> 3. define a SyslogHandler:
> {noformat}
> /subsystem=logging/custom-handler=TEST_SH:add(class="org.jboss.logmanager.handlers.SyslogHandler", module="org.jboss.logmanager", formatter="SyslogHandler: %s%e", level=INFO, properties={serverHostname="localhost:514", facility="LOCAL_USE_1", truncate=false, maxLength=1024, syslogType="RFC3164" })
> /subsystem=logging/logger=utf8mb4log:assign-handler(name=TEST_SH)
> {noformat}
> 4. define a SyslogAppender:
> {noformat}
> /subsystem=logging/custom-handler=TEST_LOG4J:add(class="org.apache.log4j.net.SyslogAppender", module="org.apache.log4j", formatter="log4j: %s%e", level=INFO, properties={syslogHost="localhost:514", facility="local1"})
> /subsystem=logging/logger=utf8mb4log:assign-handler(name=TEST_LOG4J)
> {noformat}
> 5. get and deploy example project at https://github.com/lbtc-xxx/utf8mb4log
> 6. Access the servlet http://localhost:8080/utf8mb4log/
> And you will get like this: (I can't put 4 byte UTF-8 characters here... because  database error occured):
> {noformat}
> Mar  8 17:29:09 UNKNOWN_HOSTNAME java[9896]: SyslogHandler: ????????????
> {noformat}
> I would send a pull request later.

--
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

From issues at jboss.org  Sun Mar  9 18:17:33 2014
From: issues at jboss.org (Kyle Shanahan (JIRA))
Date: Sun, 9 Mar 2014 18:17:33 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (LOGMGR-104) SyslogHandler doesn't handle
 multi-byte characters correctly
In-Reply-To: <JIRA.12534488.1394268821000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534488.1394268821000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534488.1394268821000.13978.1394403453213@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/LOGMGR-104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12951368#comment-12951368 ] 

Kyle Shanahan edited comment on LOGMGR-104 at 3/9/14 6:15 PM:
--------------------------------------------------------------

Sorry, my examples doesn't have enough patterns. Well, let's see some examples:

- Logging code
!corrupted2.png!

- Output
!corrupted.png!

You can see that 2byte UTF8 characters are not corrupted, and 3byte and 4byte (with surrogate pairs) characters are corrupted.

Also, 2byte characters are not corrupted because I'm using UTF-8, but current implementation is UTF-8 dependent, so I guess it's might better to change to encoding independent implementation. my pull request has this fix too.

I would update my example project later.
                
      was (Author: xkylex):
    Sorry, my examples doesn't have enough patterns.
Well, let's see some examples:

- Logging code !corrupted.png!
                  
> SyslogHandler doesn't handle multi-byte characters correctly
> ------------------------------------------------------------
>
>                 Key: LOGMGR-104
>                 URL: https://issues.jboss.org/browse/LOGMGR-104
>             Project: JBoss Log Manager
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: core
>    Affects Versions: 1.5.2.Final
>         Environment: - WildFly 8.0.0.Final
> - Oracle JDK7u51
> - OS X 10.9.2
>            Reporter: Kyle Shanahan
>            Assignee: David Lloyd
>         Attachments: corrupted.png, corrupted2.png, corrupted3.png
>
>
> SyslogHandler doesn't handle multi-byte characters correctly.
> I tried to log multi-byte message with both of org.jboss.logmanager.handlers.SyslogHandler and org.apache.log4j.net.SyslogAppender for same message, only SyslogHandler output were corrupted.
> Step to reproduce (It might need to define -Dfile.encoding=UTF-8 in _JAVA_OPTIONS): 
> 1. define a facility local1 at localhost and make syslog accept UDP packets.
> 2. define a logger:
> {noformat}
> /subsystem=logging/logger=utf8mb4log:add(level=INFO)
> {noformat}
> 3. define a SyslogHandler:
> {noformat}
> /subsystem=logging/custom-handler=TEST_SH:add(class="org.jboss.logmanager.handlers.SyslogHandler", module="org.jboss.logmanager", formatter="SyslogHandler: %s%e", level=INFO, properties={serverHostname="localhost:514", facility="LOCAL_USE_1", truncate=false, maxLength=1024, syslogType="RFC3164" })
> /subsystem=logging/logger=utf8mb4log:assign-handler(name=TEST_SH)
> {noformat}
> 4. define a SyslogAppender:
> {noformat}
> /subsystem=logging/custom-handler=TEST_LOG4J:add(class="org.apache.log4j.net.SyslogAppender", module="org.apache.log4j", formatter="log4j: %s%e", level=INFO, properties={syslogHost="localhost:514", facility="local1"})
> /subsystem=logging/logger=utf8mb4log:assign-handler(name=TEST_LOG4J)
> {noformat}
> 5. get and deploy example project at https://github.com/lbtc-xxx/utf8mb4log
> 6. Access the servlet http://localhost:8080/utf8mb4log/
> And you will get like this: (I can't put 4 byte UTF-8 characters here... because  database error occured):
> {noformat}
> Mar  8 17:29:09 UNKNOWN_HOSTNAME java[9896]: SyslogHandler: ????????????
> {noformat}
> I would send a pull request later.

--
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

From issues at jboss.org  Sun Mar  9 18:26:33 2014
From: issues at jboss.org (Kyle Shanahan (JIRA))
Date: Sun, 9 Mar 2014 18:26:33 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (LOGMGR-104) SyslogHandler doesn't handle
 multi-byte characters correctly
In-Reply-To: <JIRA.12534488.1394268821000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534488.1394268821000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534488.1394268821000.13981.1394403993214@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/LOGMGR-104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12951368#comment-12951368 ] 

Kyle Shanahan edited comment on LOGMGR-104 at 3/9/14 6:25 PM:
--------------------------------------------------------------

Sorry, my examples doesn't have enough patterns. Well, let's see some examples:

- Logging code
!corrupted2.png!

- Output
!corrupted.png!

You can see that 2byte UTF8 characters are not corrupted, and 3byte (no surrogate pairs) and 4byte (with surrogate pairs) characters are corrupted.

Also, 2byte characters are not corrupted because I'm using UTF-8, but current implementation is UTF-8 dependent, so I guess it's might better to change to encoding independent implementation. my pull request has this fix too.

I would update my example project later.
                
      was (Author: xkylex):
    Sorry, my examples doesn't have enough patterns. Well, let's see some examples:

- Logging code
!corrupted2.png!

- Output
!corrupted.png!

You can see that 2byte UTF8 characters are not corrupted, and 3byte and 4byte (with surrogate pairs) characters are corrupted.

Also, 2byte characters are not corrupted because I'm using UTF-8, but current implementation is UTF-8 dependent, so I guess it's might better to change to encoding independent implementation. my pull request has this fix too.

I would update my example project later.
                  
> SyslogHandler doesn't handle multi-byte characters correctly
> ------------------------------------------------------------
>
>                 Key: LOGMGR-104
>                 URL: https://issues.jboss.org/browse/LOGMGR-104
>             Project: JBoss Log Manager
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: core
>    Affects Versions: 1.5.2.Final
>         Environment: - WildFly 8.0.0.Final
> - Oracle JDK7u51
> - OS X 10.9.2
>            Reporter: Kyle Shanahan
>            Assignee: David Lloyd
>         Attachments: corrupted.png, corrupted2.png, corrupted3.png
>
>
> SyslogHandler doesn't handle multi-byte characters correctly.
> I tried to log multi-byte message with both of org.jboss.logmanager.handlers.SyslogHandler and org.apache.log4j.net.SyslogAppender for same message, only SyslogHandler output were corrupted.
> Step to reproduce (It might need to define -Dfile.encoding=UTF-8 in _JAVA_OPTIONS): 
> 1. define a facility local1 at localhost and make syslog accept UDP packets.
> 2. define a logger:
> {noformat}
> /subsystem=logging/logger=utf8mb4log:add(level=INFO)
> {noformat}
> 3. define a SyslogHandler:
> {noformat}
> /subsystem=logging/custom-handler=TEST_SH:add(class="org.jboss.logmanager.handlers.SyslogHandler", module="org.jboss.logmanager", formatter="SyslogHandler: %s%e", level=INFO, properties={serverHostname="localhost:514", facility="LOCAL_USE_1", truncate=false, maxLength=1024, syslogType="RFC3164" })
> /subsystem=logging/logger=utf8mb4log:assign-handler(name=TEST_SH)
> {noformat}
> 4. define a SyslogAppender:
> {noformat}
> /subsystem=logging/custom-handler=TEST_LOG4J:add(class="org.apache.log4j.net.SyslogAppender", module="org.apache.log4j", formatter="log4j: %s%e", level=INFO, properties={syslogHost="localhost:514", facility="local1"})
> /subsystem=logging/logger=utf8mb4log:assign-handler(name=TEST_LOG4J)
> {noformat}
> 5. get and deploy example project at https://github.com/lbtc-xxx/utf8mb4log
> 6. Access the servlet http://localhost:8080/utf8mb4log/
> And you will get like this: (I can't put 4 byte UTF-8 characters here... because  database error occured):
> {noformat}
> Mar  8 17:29:09 UNKNOWN_HOSTNAME java[9896]: SyslogHandler: ????????????
> {noformat}
> I would send a pull request later.

--
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

From issues at jboss.org  Sun Mar  9 18:32:33 2014
From: issues at jboss.org (Kyle Shanahan (JIRA))
Date: Sun, 9 Mar 2014 18:32:33 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (LOGMGR-104) SyslogHandler doesn't handle
 multi-byte characters correctly
In-Reply-To: <JIRA.12534488.1394268821000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534488.1394268821000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534488.1394268821000.14001.1394404353653@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/LOGMGR-104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12951368#comment-12951368 ] 

Kyle Shanahan edited comment on LOGMGR-104 at 3/9/14 6:32 PM:
--------------------------------------------------------------

Sorry, my examples doesn't have enough patterns. Well, let's see some examples:

- Logging code
!corrupted2.png!

- Output
!corrupted.png!

You can see that 2byte UTF8 characters are not corrupted, and 3byte (no surrogate pairs) and 4byte (with surrogate pairs) characters are corrupted.

Also, 2byte characters are not corrupted because I'm using UTF-8, but current implementation is UTF-8 dependent, so I guess it's might better to change to encoding independent implementation. my pull request has this fix too.

I updated my example project at GitHub.
                
      was (Author: xkylex):
    Sorry, my examples doesn't have enough patterns. Well, let's see some examples:

- Logging code
!corrupted2.png!

- Output
!corrupted.png!

You can see that 2byte UTF8 characters are not corrupted, and 3byte (no surrogate pairs) and 4byte (with surrogate pairs) characters are corrupted.

Also, 2byte characters are not corrupted because I'm using UTF-8, but current implementation is UTF-8 dependent, so I guess it's might better to change to encoding independent implementation. my pull request has this fix too.

I would update my example project later.
                  
> SyslogHandler doesn't handle multi-byte characters correctly
> ------------------------------------------------------------
>
>                 Key: LOGMGR-104
>                 URL: https://issues.jboss.org/browse/LOGMGR-104
>             Project: JBoss Log Manager
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: core
>    Affects Versions: 1.5.2.Final
>         Environment: - WildFly 8.0.0.Final
> - Oracle JDK7u51
> - OS X 10.9.2
>            Reporter: Kyle Shanahan
>            Assignee: David Lloyd
>         Attachments: corrupted.png, corrupted2.png, corrupted3.png
>
>
> SyslogHandler doesn't handle multi-byte characters correctly.
> I tried to log multi-byte message with both of org.jboss.logmanager.handlers.SyslogHandler and org.apache.log4j.net.SyslogAppender for same message, only SyslogHandler output were corrupted.
> Step to reproduce (It might need to define -Dfile.encoding=UTF-8 in _JAVA_OPTIONS): 
> 1. define a facility local1 at localhost and make syslog accept UDP packets.
> 2. define a logger:
> {noformat}
> /subsystem=logging/logger=utf8mb4log:add(level=INFO)
> {noformat}
> 3. define a SyslogHandler:
> {noformat}
> /subsystem=logging/custom-handler=TEST_SH:add(class="org.jboss.logmanager.handlers.SyslogHandler", module="org.jboss.logmanager", formatter="SyslogHandler: %s%e", level=INFO, properties={serverHostname="localhost:514", facility="LOCAL_USE_1", truncate=false, maxLength=1024, syslogType="RFC3164" })
> /subsystem=logging/logger=utf8mb4log:assign-handler(name=TEST_SH)
> {noformat}
> 4. define a SyslogAppender:
> {noformat}
> /subsystem=logging/custom-handler=TEST_LOG4J:add(class="org.apache.log4j.net.SyslogAppender", module="org.apache.log4j", formatter="log4j: %s%e", level=INFO, properties={syslogHost="localhost:514", facility="local1"})
> /subsystem=logging/logger=utf8mb4log:assign-handler(name=TEST_LOG4J)
> {noformat}
> 5. get and deploy example project at https://github.com/lbtc-xxx/utf8mb4log
> 6. Access the servlet http://localhost:8080/utf8mb4log/
> And you will get like this: (I can't put 4 byte UTF-8 characters here... because  database error occured):
> {noformat}
> Mar  8 17:29:09 UNKNOWN_HOSTNAME java[9896]: SyslogHandler: ????????????
> {noformat}
> I would send a pull request later.

--
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

From issues at jboss.org  Sun Mar  9 23:08:33 2014
From: issues at jboss.org (Kyle Lape (JIRA))
Date: Sun, 9 Mar 2014 23:08:33 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3067) Webservices DUP is not
 scanning all visible classes for @WebService annotation
In-Reply-To: <JIRA.12534077.1393987223000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534077.1393987223000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534077.1393987223000.14265.1394420913705@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-3067?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kyle Lape updated WFLY-3067:
----------------------------

    Summary: Webservices DUP is not scanning all visible classes for @WebService annotation  (was: Annotations from .ear/lib are not visible to DUPs when processing subdeployments)

    
> Webservices DUP is not scanning all visible classes for @WebService annotation
> ------------------------------------------------------------------------------
>
>                 Key: WFLY-3067
>                 URL: https://issues.jboss.org/browse/WFLY-3067
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Class Loading
>    Affects Versions: 8.0.0.Final
>            Reporter: Kyle Lape
>            Assignee: David Lloyd
>
> Sample use case:  You have a .war in an .ear, and the .war has a web.xml with a {{<servlet-class>}} that refers to a JAX-WS endpoint, so the class is annotated with {{@WebService}}.  If that class is packaged in a jar found in the ear's lib directory, the JBossWS DUP won't pick it up, and then Undertow will throw an error like this:
> {noformat}
> UT010009: Servlet ClientEndpoint of type class com.redhat.gss.jaxws.ClientEndpoint does not implement javax.servlet.Servlet
> {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

From issues at jboss.org  Sun Mar  9 23:08:34 2014
From: issues at jboss.org (Kyle Lape (JIRA))
Date: Sun, 9 Mar 2014 23:08:34 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3067) Webservices DUP is not
 scanning all visible classes for @WebService annotation
In-Reply-To: <JIRA.12534077.1393987223000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534077.1393987223000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534077.1393987223000.14272.1394420914026@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-3067?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kyle Lape updated WFLY-3067:
----------------------------

    Assignee: Alessio Soldano  (was: David Lloyd)

    
> Webservices DUP is not scanning all visible classes for @WebService annotation
> ------------------------------------------------------------------------------
>
>                 Key: WFLY-3067
>                 URL: https://issues.jboss.org/browse/WFLY-3067
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Class Loading
>    Affects Versions: 8.0.0.Final
>            Reporter: Kyle Lape
>            Assignee: Alessio Soldano
>
> Sample use case:  You have a .war in an .ear, and the .war has a web.xml with a {{<servlet-class>}} that refers to a JAX-WS endpoint, so the class is annotated with {{@WebService}}.  If that class is packaged in a jar found in the ear's lib directory, the JBossWS DUP won't pick it up, and then Undertow will throw an error like this:
> {noformat}
> UT010009: Servlet ClientEndpoint of type class com.redhat.gss.jaxws.ClientEndpoint does not implement javax.servlet.Servlet
> {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

From issues at jboss.org  Sun Mar  9 23:08:34 2014
From: issues at jboss.org (Kyle Lape (JIRA))
Date: Sun, 9 Mar 2014 23:08:34 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3067) Webservices DUP is not
 scanning all visible classes for @WebService annotation
In-Reply-To: <JIRA.12534077.1393987223000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534077.1393987223000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534077.1393987223000.14278.1394420914311@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-3067?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kyle Lape updated WFLY-3067:
----------------------------

    Component/s: Web Services
                     (was: Class Loading)

    
> Webservices DUP is not scanning all visible classes for @WebService annotation
> ------------------------------------------------------------------------------
>
>                 Key: WFLY-3067
>                 URL: https://issues.jboss.org/browse/WFLY-3067
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web Services
>    Affects Versions: 8.0.0.Final
>            Reporter: Kyle Lape
>            Assignee: Alessio Soldano
>
> Sample use case:  You have a .war in an .ear, and the .war has a web.xml with a {{<servlet-class>}} that refers to a JAX-WS endpoint, so the class is annotated with {{@WebService}}.  If that class is packaged in a jar found in the ear's lib directory, the JBossWS DUP won't pick it up, and then Undertow will throw an error like this:
> {noformat}
> UT010009: Servlet ClientEndpoint of type class com.redhat.gss.jaxws.ClientEndpoint does not implement javax.servlet.Servlet
> {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

From issues at jboss.org  Mon Mar 10 04:33:10 2014
From: issues at jboss.org (Alessio Soldano (JIRA))
Date: Mon, 10 Mar 2014 04:33:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3067) Webservices DUP is not
 scanning all visible classes for @WebService annotation
In-Reply-To: <JIRA.12534077.1393987223000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534077.1393987223000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534077.1393987223000.128.1394440390991@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-3067?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Alessio Soldano updated WFLY-3067:
----------------------------------

    Fix Version/s: 8.0.1.Final

    
> Webservices DUP is not scanning all visible classes for @WebService annotation
> ------------------------------------------------------------------------------
>
>                 Key: WFLY-3067
>                 URL: https://issues.jboss.org/browse/WFLY-3067
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web Services
>    Affects Versions: 8.0.0.Final
>            Reporter: Kyle Lape
>            Assignee: Alessio Soldano
>             Fix For: 8.0.1.Final
>
>
> Sample use case:  You have a .war in an .ear, and the .war has a web.xml with a {{<servlet-class>}} that refers to a JAX-WS endpoint, so the class is annotated with {{@WebService}}.  If that class is packaged in a jar found in the ear's lib directory, the JBossWS DUP won't pick it up, and then Undertow will throw an error like this:
> {noformat}
> UT010009: Servlet ClientEndpoint of type class com.redhat.gss.jaxws.ClientEndpoint does not implement javax.servlet.Servlet
> {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

From issues at jboss.org  Mon Mar 10 04:47:12 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 10 Mar 2014 04:47:12 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBWEB-292) Http11Nio loaded,
 JBWEB002081: No cipher match
In-Reply-To: <JIRA.12534270.1394109559000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534270.1394109559000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534270.1394109559000.146.1394441232141@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JBWEB-292?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12951428#comment-12951428 ] 

RH Bugzilla Integration commented on JBWEB-292:
-----------------------------------------------

Michal Babacek <mbabacek at redhat.com> changed the Status of [bug 1073430|https://bugzilla.redhat.com/show_bug.cgi?id=1073430] from NEW to CLOSED
                
> Http11Nio loaded, JBWEB002081: No cipher match
> ----------------------------------------------
>
>                 Key: JBWEB-292
>                 URL: https://issues.jboss.org/browse/JBWEB-292
>             Project: JBoss Web
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>    Affects Versions: JBossWeb-7.4.0.GA
>            Reporter: Michal Babacek
>            Assignee: Remy Maucherat
>            Priority: Critical
>             Fix For: JBossWeb-7.4.0.GA
>
>
> Hi guys,
> I have an SSL test that sets up the web subsystem with HTTPS connector only and uses HTTPS with mod_cluster.
> {code}
>         <subsystem xmlns="urn:jboss:domain:modcluster:1.2">
>             <mod-cluster-config advertise-socket="modcluster" connector="https">
>                 <dynamic-load-provider>
>                     <load-metric type="busyness"/>
>                 </dynamic-load-provider>
>                 <ssl key-alias="javaclient" 
>                      password="tomcat" 
>                      certificate-key-file="/tmp/ews-eap6/client-cert-key.jks" 
>                      cipher-suite="AES128-SHA:ALL:!ADH:!LOW:!MD5:!SSLV2:!NULL" 
>                      ca-certificate-file="/tmp/ews-eap6/ca-cert.jks"
>                 />
>             </mod-cluster-config>
>         </subsystem>
>         <subsystem xmlns="urn:jboss:domain:web:1.5" native="false">
>             <connector name="https" protocol="HTTP/1.1" scheme="https" socket-binding="https" secure="true" enabled="true">
>                 <ssl name="https" 
>                     key-alias="javaclient" 
>                     password="tomcat" 
>                     certificate-key-file="/tmp/ews-eap6/client-cert-key.jks" 
>                     cipher-suite="AES128-SHA:ALL:!ADH:!LOW:!MD5:!SSLV2:!NULL" 
>                     protocol="TLS" verify-client="false" 
>                     certificate-file="/tmp/ews-eap6/client-cert-key.jks" 
>                     ca-certificate-file="/tmp/ews-eap6/ca-cert.jks"/>
>             </connector>
>             <virtual-server name="default-host" enable-welcome-root="true">
>                 <alias name="localhost"/>
>                 <alias name="example.com"/>
>             </virtual-server>
>         </subsystem>
> {code}
> Notice that while EAP 6.3.0.DR1 with *jbossweb-7.3.0.Final* uses {{org.apache.coyote.http11}}, EAP 6.3.0.DR2 with *jbossweb-7.4.0.Beta4* tries to start {{org.apache.coyote.http11.Http11NioProtocol}}. 
> This causes cipher suite errors.
> * EAP 6.3.0.DR1 with jbossweb-7.3.0.Final passes this test with no exceptions thrown.
> * EAP 6.3.0.DR2 with jbossweb-7.4.0.Beta4 causes:
> {noformat}
> 06:18:26,649 ERROR [org.apache.coyote.http11.Http11NioProtocol] (MSC service thread 1-17) JBWEB003043: Error initializing endpoint: java.io.IOException: JBWEB002081: No cipher match
>     at org.apache.tomcat.util.net.jsse.NioJSSESocketChannelFactory.init(NioJSSESocketChannelFactory.java:315) [jbossweb-7.4.0.Beta4.jar:7.4.0.Beta4]
>     at org.apache.tomcat.util.net.NioEndpoint.init(NioEndpoint.java:205) [jbossweb-7.4.0.Beta4.jar:7.4.0.Beta4]
>     at org.apache.coyote.http11.Http11NioProtocol.init(Http11NioProtocol.java:113) [jbossweb-7.4.0.Beta4.jar:7.4.0.Beta4]
>     at org.apache.catalina.connector.Connector.init(Connector.java:983) [jbossweb-7.4.0.Beta4.jar:7.4.0.Beta4]
>     at org.jboss.as.web.WebConnectorService.start(WebConnectorService.java:304) [jboss-as-web-7.4.0.Final-redhat-2.jar:7.4.0.Final-redhat-2]
>     at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1980) [jboss-msc-1.1.5.Final.jar:1.1.5.Final]
>     at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1913) [jboss-msc-1.1.5.Final.jar:1.1.5.Final]
>     at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_51]
>     at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_51]
>     at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_51]
> Caused by: java.io.IOException: JBWEB002081: No cipher match
>     at org.apache.tomcat.util.net.jsse.NioJSSESocketChannelFactory.getEnabledCiphers(NioJSSESocketChannelFactory.java:399) [jbossweb-7.4.0.Beta4.jar:7.4.0.Beta4]
>     at org.apache.tomcat.util.net.jsse.NioJSSESocketChannelFactory.init(NioJSSESocketChannelFactory.java:305) [jbossweb-7.4.0.Beta4.jar:7.4.0.Beta4]
>     ... 9 more
> 06:18:26,663 INFO  [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-39) JBAS010400: Bound data source [java:jboss/datasources/ExampleDS]
> 06:18:26,672 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-17) MSC000001: Failed to start service jboss.web.connector.https: org.jboss.msc.service.StartException in service jboss.web.connector.https: JBAS018007: Error starting web connector
>     at org.jboss.as.web.WebConnectorService.start(WebConnectorService.java:362)
>     at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1980) [jboss-msc-1.1.5.Final.jar:1.1.5.Final]
>     at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1913) [jboss-msc-1.1.5.Final.jar:1.1.5.Final]
>     at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_51]
>     at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_51]
>     at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_51]
> Caused by: LifecycleException:  JBWEB000023: Protocol handler initialization failed
>     at org.apache.catalina.connector.Connector.init(Connector.java:985)
>     at org.jboss.as.web.WebConnectorService.start(WebConnectorService.java:304)
>     ... 5 more
> {noformat}
> Any ideas?

--
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

From issues at jboss.org  Mon Mar 10 04:55:13 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 10 Mar 2014 04:55:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2899) Help and error messages in
 Main classes should be printed raw
In-Reply-To: <JIRA.12531680.1392076590000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12531680.1392076590000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12531680.1392076590000.214.1394441713428@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2899?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12951433#comment-12951433 ] 

RH Bugzilla Integration commented on WFLY-2899:
-----------------------------------------------

Petr Kremensky <pkremens at redhat.com> changed the Status of [bug 1069514|https://bugzilla.redhat.com/show_bug.cgi?id=1069514] from ON_QA to VERIFIED
                
> Help and error messages in Main classes should be printed raw
> -------------------------------------------------------------
>
>                 Key: WFLY-2899
>                 URL: https://issues.jboss.org/browse/WFLY-2899
>             Project: WildFly
>          Issue Type: Enhancement
>      Security Level: Public(Everyone can see) 
>          Components: Logging
>            Reporter: James Perkins
>            Assignee: James Perkins
>            Priority: Minor
>             Fix For: 8.0.1.Final
>
>
> The help in standalone and host-controller main methods gets printed after {{System.out}} and {{System.err}} have been captured by jboss-stdio. This leads the help and errors being printed in a log manager format rather than just the raw text.
> Example output:
> {code}
> [jperkins at jperkins-rh wildfly]$ ./build/target/wildfly-8.0.0.Final-SNAPSHOT/bin/standalone.sh -help
> =========================================================================
>   JBoss Bootstrap Environment
>   JBOSS_HOME: /home/jperkins/projects/jboss/as/wildfly/build/target/wildfly-8.0.0.Final-SNAPSHOT
>   JAVA: java
>   JAVA_OPTS:  -server -XX:+UseCompressedOops -Xms64m -Xmx512m -XX:MaxPermSize=256m -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true
> =========================================================================
> 15:31:43,895 INFO  [org.jboss.modules] (main) JBoss Modules version 1.3.0.Final
> 15:31:44,918 INFO  [stdout] (main) 
> 15:31:44,918 INFO  [stdout] (main) Usage: standalone.sh [args...]
> 15:31:44,918 INFO  [stdout] (main) where args include:
> 15:31:44,918 INFO  [stdout] (main)     --admin-only                        Set the server's running type to 
> 15:31:44,919 INFO  [stdout] (main)                                         ADMIN_ONLY causing it to open 
> 15:31:44,919 INFO  [stdout] (main)                                         administrative interfaces and accept 
> 15:31:44,919 INFO  [stdout] (main)                                         management requests but not start other 
> 15:31:44,920 INFO  [stdout] (main)                                         runtime services or accept end user 
> 15:31:44,920 INFO  [stdout] (main)                                         requests.
> 15:31:44,920 INFO  [stdout] (main) 
> 15:31:44,920 INFO  [stdout] (main) 
> 15:31:44,921 INFO  [stdout] (main)     -b <value>, -b=<value>              Set system property jboss.bind.address 
> 15:31:44,921 INFO  [stdout] (main)                                         to the given value
> 15:31:44,921 INFO  [stdout] (main) 
> 15:31:44,921 INFO  [stdout] (main) 
> 15:31:44,922 INFO  [stdout] (main)     -b<interface>=<value>               Set system property 
> 15:31:44,922 INFO  [stdout] (main)                                         jboss.bind.address.<interface> to the 
> 15:31:44,922 INFO  [stdout] (main)                                         given value
> 15:31:44,922 INFO  [stdout] (main) 
> 15:31:44,923 INFO  [stdout] (main) 
> 15:31:44,923 INFO  [stdout] (main)     -c <config>, -c=<config>            Name of the server configuration file 
> 15:31:44,923 INFO  [stdout] (main)                                         to use (default is "standalone.xml") 
> 15:31:44,923 INFO  [stdout] (main)                                         (Same as --server-config)
> 15:31:44,924 INFO  [stdout] (main) 
> 15:31:44,924 INFO  [stdout] (main) 
> 15:31:44,924 INFO  [stdout] (main)     --debug [<port>]                    Activate debug mode with an optional 
> 15:31:44,924 INFO  [stdout] (main)                                         argument to specify the port. Only 
> 15:31:44,925 INFO  [stdout] (main)                                         works if the launch script supports it.
> 15:31:44,925 INFO  [stdout] (main) 
> 15:31:44,925 INFO  [stdout] (main) 
> 15:31:44,925 INFO  [stdout] (main)     -D<name>[=<value>]                  Set a system property
> 15:31:44,926 INFO  [stdout] (main) 
> 15:31:44,926 INFO  [stdout] (main) 
> 15:31:44,926 INFO  [stdout] (main)     -h, --help                          Display this message and exit
> 15:31:44,927 INFO  [stdout] (main) 
> 15:31:44,927 INFO  [stdout] (main) 
> 15:31:44,927 INFO  [stdout] (main)     --read-only-server-config=<config>  Name of the server configuration file 
> 15:31:44,927 INFO  [stdout] (main)                                         to use. This differs from 
> 15:31:44,928 INFO  [stdout] (main)                                         '--server-config' and '-c' in that the 
> 15:31:44,928 INFO  [stdout] (main)                                         original file is never overwritten.
> 15:31:44,928 INFO  [stdout] (main) 
> 15:31:44,928 INFO  [stdout] (main) 
> 15:31:44,929 INFO  [stdout] (main)     -P <url>, -P=<url>,                 Load system properties from the given 
> 15:31:44,929 INFO  [stdout] (main)          --properties=<url>             url
> 15:31:44,929 INFO  [stdout] (main) 
> 15:31:44,929 INFO  [stdout] (main) 
> 15:31:44,930 INFO  [stdout] (main)     -S<name>[=<value>]                  Set a security property
> 15:31:44,930 INFO  [stdout] (main) 
> 15:31:44,930 INFO  [stdout] (main) 
> 15:31:44,930 INFO  [stdout] (main)     --server-config=<config>            Name of the server configuration file 
> 15:31:44,931 INFO  [stdout] (main)                                         to use (default is "standalone.xml") 
> 15:31:44,931 INFO  [stdout] (main)                                         (Same as -c)
> 15:31:44,931 INFO  [stdout] (main) 
> 15:31:44,931 INFO  [stdout] (main) 
> 15:31:44,932 INFO  [stdout] (main)     -u <value>, -u=<value>              Set system property 
> 15:31:44,932 INFO  [stdout] (main)                                         jboss.default.multicast.address to the 
> 15:31:44,932 INFO  [stdout] (main)                                         given value
> 15:31:44,933 INFO  [stdout] (main) 
> 15:31:44,933 INFO  [stdout] (main) 
> 15:31:44,933 INFO  [stdout] (main)     -v, -V, --version                   Print version and exit
> 15:31:44,934 INFO  [stdout] (main) 
> 15:31:44,934 INFO  [stdout] (main)
> {code}

--
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

From issues at jboss.org  Mon Mar 10 05:15:12 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 10 Mar 2014 05:15:12 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3016) Prevent NullPointerException
 in JDR CommandLineMain
In-Reply-To: <JIRA.12533291.1393354434000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12533291.1393354434000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12533291.1393354434000.308.1394442912628@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-3016?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12951447#comment-12951447 ] 

RH Bugzilla Integration commented on WFLY-3016:
-----------------------------------------------

Petr Kremensky <pkremens at redhat.com> changed the Status of [bug 1069850|https://bugzilla.redhat.com/show_bug.cgi?id=1069850] from ON_QA to VERIFIED
                
> Prevent NullPointerException in JDR CommandLineMain
> ---------------------------------------------------
>
>                 Key: WFLY-3016
>                 URL: https://issues.jboss.org/browse/WFLY-3016
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JDR
>    Affects Versions: 8.0.0.Final
>            Reporter: Brad Maxwell
>            Assignee: Brad Maxwell
>


--
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

From issues at jboss.org  Mon Mar 10 06:39:11 2014
From: issues at jboss.org (Michael Biarnes Kiefer (JIRA))
Date: Mon, 10 Mar 2014 06:39:11 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-432) Types declared in a foreign
 package are processed one at a time
In-Reply-To: <JIRA.12532408.1392652292000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12532408.1392652292000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12532408.1392652292000.497.1394447951554@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-432?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Michael Biarnes Kiefer updated DROOLS-432:
------------------------------------------

    Fix Version/s: 6.1.0.Beta2
                       (was: 6.1.0.Beta1)

    
> Types declared in a foreign package are processed one at a time
> ---------------------------------------------------------------
>
>                 Key: DROOLS-432
>                 URL: https://issues.jboss.org/browse/DROOLS-432
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.5.0.Final, 5.6.0.Final, 6.0.1.Final
>            Reporter: Davide Sottara
>            Assignee: Mark Proctor
>             Fix For: 6.1.0.Beta2
>
>
> The following snippet has two issues
> {code}
> package a;
> declare b.X  field : b.Y end
> declare b.Y end
> {code}
> While processing package a, the packageBuilder will infer the existence of package b and create the appropriate typeDeclarations.
> However, a partial, independent package b is created for X and Y:
> - it is inefficient
> - internal dependencies cannot be resolved : b.X does not (yet) see b.Y

--
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

From issues at jboss.org  Mon Mar 10 06:39:11 2014
From: issues at jboss.org (Michael Biarnes Kiefer (JIRA))
Date: Mon, 10 Mar 2014 06:39:11 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-332) Space Invaders and Number
	Guess Game
In-Reply-To: <JIRA.12524724.1384112235000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12524724.1384112235000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12524724.1384112235000.501.1394447951931@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-332?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Michael Biarnes Kiefer updated DROOLS-332:
------------------------------------------

    Fix Version/s: 6.1.0.Beta2
                       (was: 6.1.0.Beta1)

    
> Space Invaders and Number Guess Game
> ------------------------------------
>
>                 Key: DROOLS-332
>                 URL: https://issues.jboss.org/browse/DROOLS-332
>             Project: Drools
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>            Reporter: Mark Proctor
>            Assignee: Mark Proctor
>             Fix For: 6.1.0.Beta2
>
>


--
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

From issues at jboss.org  Mon Mar 10 06:39:12 2014
From: issues at jboss.org (Michael Biarnes Kiefer (JIRA))
Date: Mon, 10 Mar 2014 06:39:12 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-316) Arbitrary Conflict
 Resolution can be confusing use LoadOrder
In-Reply-To: <JIRA.12510987.1383384744000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12510987.1383384744000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12510987.1383384744000.504.1394447952115@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-316?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Michael Biarnes Kiefer updated DROOLS-316:
------------------------------------------

    Fix Version/s: 6.1.0.Beta2
                       (was: 6.1.0.Beta1)

    
> Arbitrary Conflict Resolution can be confusing use LoadOrder
> ------------------------------------------------------------
>
>                 Key: DROOLS-316
>                 URL: https://issues.jboss.org/browse/DROOLS-316
>             Project: Drools
>          Issue Type: Enhancement
>      Security Level: Public(Everyone can see) 
>            Reporter: Mark Proctor
>            Assignee: Mark Proctor
>             Fix For: 6.1.0.Beta2
>
>


--
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

From issues at jboss.org  Mon Mar 10 06:39:12 2014
From: issues at jboss.org (Michael Biarnes Kiefer (JIRA))
Date: Mon, 10 Mar 2014 06:39:12 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-201) Improve Rule Removal
In-Reply-To: <JIRA.12497212.1374649467000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12497212.1374649467000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12497212.1374649467000.507.1394447952308@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-201?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Michael Biarnes Kiefer updated DROOLS-201:
------------------------------------------

    Fix Version/s: 6.1.0.Beta2
                       (was: 6.1.0.Beta1)

    
> Improve Rule Removal
> --------------------
>
>                 Key: DROOLS-201
>                 URL: https://issues.jboss.org/browse/DROOLS-201
>             Project: Drools
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>            Reporter: Mark Proctor
>            Assignee: Mark Proctor
>             Fix For: 6.1.0.Beta2
>
>


--
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

From issues at jboss.org  Mon Mar 10 06:39:12 2014
From: issues at jboss.org (Michael Biarnes Kiefer (JIRA))
Date: Mon, 10 Mar 2014 06:39:12 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-115) Add support for strong
	negation
In-Reply-To: <JIRA.12474560.1347671752000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12474560.1347671752000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12474560.1347671752000.512.1394447952638@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-115?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Michael Biarnes Kiefer updated DROOLS-115:
------------------------------------------

    Fix Version/s: 6.1.0.Beta2
                       (was: 6.1.0.Beta1)

    
> Add support for strong negation
> -------------------------------
>
>                 Key: DROOLS-115
>                 URL: https://issues.jboss.org/browse/DROOLS-115
>             Project: Drools
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>            Reporter: Davide Sottara
>            Assignee: Davide Sottara
>            Priority: Minor
>             Fix For: 6.1.0.Beta2
>
>
> Drools "not" operator implements a type of "negation by failure", i.e. not X() behaves as the negation of "exists" or, in other words, translates as "it is NOT asserted that ...".
> However, another form of stronger negation is needed to express conditionals such as "it is asserted that NOT ..."
> It should be possible, then, to assert facts both in a "positive" and "negative" way, to assert THAT and THAT NOT. 
> The language should also support a "neg" CE to create "negative" patterns which will match with negative facts. I.e. it should be possible to write rules such as:
> when $p : Person() and Car( owner == $p ) then
> // a positive, matching Car is present in the WM
> when $p : Person() and neg Car( owner == $p ) then
> // a negative, matching Car is present in the WM
> when $p : Person() and not Car( owner == $p ) then
> // neither a positive nor a negative fact exists in the WM
> For a more detailed description and motivation see e.g.:
> https://oxygen.informatik.tu-cottbus.de/publications/wagner/WebRules2Neg.pdf

--
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

From issues at jboss.org  Mon Mar 10 06:39:12 2014
From: issues at jboss.org (Michael Biarnes Kiefer (JIRA))
Date: Mon, 10 Mar 2014 06:39:12 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-112) Allow join constraints in
	sliding windows
In-Reply-To: <JIRA.12490647.1367027208000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12490647.1367027208000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12490647.1367027208000.518.1394447952928@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-112?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Michael Biarnes Kiefer updated DROOLS-112:
------------------------------------------

    Fix Version/s: 6.1.0.Beta2
                       (was: 6.1.0.Beta1)

    
> Allow join constraints in sliding windows
> -----------------------------------------
>
>                 Key: DROOLS-112
>                 URL: https://issues.jboss.org/browse/DROOLS-112
>             Project: Drools
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.5.0.Final, 6.0.0.Alpha9, 6.0.0.Beta1
>            Reporter: Davide Sottara
>            Assignee: Mark Proctor
>            Priority: Critical
>             Fix For: 6.1.0.Beta2
>
>
> When using a sliding window, alpha constraints are evaluated before the window is considered, but beta (join) constraints are evaluated afterwards.
> While it does not usually make a difference when time windows are concerned,
> it DOES make a difference with length windows.
> Imho, a clear warning should be added in the documentation to clarify
> the current behavior.

--
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

From issues at jboss.org  Mon Mar 10 06:39:13 2014
From: issues at jboss.org (Michael Biarnes Kiefer (JIRA))
Date: Mon, 10 Mar 2014 06:39:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-88) Support generics in declared
	types' fields
In-Reply-To: <JIRA.12487865.1364200178000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12487865.1364200178000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12487865.1364200178000.521.1394447953112@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-88?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Michael Biarnes Kiefer updated DROOLS-88:
-----------------------------------------

    Fix Version/s: 6.1.0.Beta2
                       (was: 6.1.0.Beta1)

    
> Support generics in declared types' fields
> ------------------------------------------
>
>                 Key: DROOLS-88
>                 URL: https://issues.jboss.org/browse/DROOLS-88
>             Project: Drools
>          Issue Type: Enhancement
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.5.0.Final
>            Reporter: Davide Sottara
>            Assignee: Davide Sottara
>            Priority: Minor
>             Fix For: 5.5.1.Final, 6.1.0.Beta2
>
>
> It should be possible to write:
> declare Foo
>   list : List<String>
> end
> While not supported in rules using the mvel dialect, it makes declared types much more readable, and adds some type-safety to java rules.
> Notice that this ticket is NOT related to the possibility of declaring generic classes, such as Foo<T>.

--
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

From issues at jboss.org  Mon Mar 10 06:39:12 2014
From: issues at jboss.org (Michael Biarnes Kiefer (JIRA))
Date: Mon, 10 Mar 2014 06:39:12 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-198) Separate Rete and Phreak
In-Reply-To: <JIRA.12496969.1374456180000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12496969.1374456180000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12496969.1374456180000.510.1394447952496@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-198?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Michael Biarnes Kiefer updated DROOLS-198:
------------------------------------------

    Fix Version/s: 6.1.0.Beta2
                       (was: 6.1.0.Beta1)

    
> Separate Rete and Phreak
> ------------------------
>
>                 Key: DROOLS-198
>                 URL: https://issues.jboss.org/browse/DROOLS-198
>             Project: Drools
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>            Reporter: Mark Proctor
>            Assignee: Mark Proctor
>             Fix For: 6.1.0.Beta2
>
>


--
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

From issues at jboss.org  Mon Mar 10 06:41:10 2014
From: issues at jboss.org (Bela Ban (JIRA))
Date: Mon, 10 Mar 2014 06:41:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1765) TP: enable loopback by
 default and discard own multicasts
In-Reply-To: <JIRA.12528488.1388489261000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528488.1388489261000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528488.1388489261000.525.1394448070674@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JGRP-1765?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12951474#comment-12951474 ] 

Bela Ban commented on JGRP-1765:
--------------------------------

[~ammous] I don't see why this is needed; after all the same message is received in the same ordered sequence at all receivers. If a message arrives at at the sender a few ms earlier, then so be it. You can always write a protocol which delivers messages at the same (wall clock) time, e.g. using time synchronization.
                
> TP: enable loopback by default and discard own multicasts
> ---------------------------------------------------------
>
>                 Key: JGRP-1765
>                 URL: https://issues.jboss.org/browse/JGRP-1765
>             Project: JGroups
>          Issue Type: Enhancement
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 3.5
>
>
> Enable {{TP.looback}} by default (deprecate and ignore prop): all messages sent by self are passed right to a thread pool to send them up again.
> When a multicast message sent by self is received, it is currently passed to a thread pool, de-serialized and only then discarded if loopback=true. This means that we create an unneeded buffer for de-serializationand perform de-serialization.
> SOLUTION: discard the multicast from self immediately when receiving it, in {{TP.receive()}}

--
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

From issues at jboss.org  Mon Mar 10 06:45:11 2014
From: issues at jboss.org (Tomaz Cerar (JIRA))
Date: Mon, 10 Mar 2014 06:45:11 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3081) Redirect Forward port web
 subsystem1.6 xsd and parser from EAP 6.3
In-Reply-To: <JIRA.12534374.1394189470000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534374.1394189470000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534374.1394189470000.546.1394448311362@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-3081?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tomaz Cerar updated WFLY-3081:
------------------------------

    Description: 
Support configuring a connector on the http socket and then redirect to the https socket without having to specify the actual port number outside of the socket-binding-group.
Support for configuring proxy port and proxy name using socket-binding also.
+ add transformers


  was:
Support configuring a connector on the http socket and then redirect to the https socket without having to specify the actual port number outside of the socket-binding-group.
Support for configuring proxy port and proxy name using socket-binding also.



    
> Redirect Forward port web subsystem1.6 xsd and parser from EAP 6.3
> ------------------------------------------------------------------
>
>                 Key: WFLY-3081
>                 URL: https://issues.jboss.org/browse/WFLY-3081
>             Project: WildFly
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Web (JBoss Web)
>    Affects Versions: 8.0.0.Final
>            Reporter: Emmanuel Hugonnet
>            Assignee: Emmanuel Hugonnet
>
> Support configuring a connector on the http socket and then redirect to the https socket without having to specify the actual port number outside of the socket-binding-group.
> Support for configuring proxy port and proxy name using socket-binding also.
> + add transformers

--
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

From issues at jboss.org  Mon Mar 10 07:21:10 2014
From: issues at jboss.org (Jeff Mesnil (JIRA))
Date: Mon, 10 Mar 2014 07:21:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3094) Warn if there is no resource
 bound for address-settings expiry and dead-letter addresses
In-Reply-To: <JIRA.12534528.1394450392909@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534528.1394450392909@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534528.1394450392909.632.1394450470562@jira02.app.mwc.hst.phx2.redhat.com>

Jeff Mesnil created WFLY-3094:
---------------------------------

             Summary: Warn if there is no resource bound for address-settings expiry and dead-letter addresses
                 Key: WFLY-3094
                 URL: https://issues.jboss.org/browse/WFLY-3094
             Project: WildFly
          Issue Type: Enhancement
      Security Level: Public (Everyone can see)
          Components: JMS
    Affects Versions: 8.0.0.Final
            Reporter: Jeff Mesnil
            Assignee: Jeff Mesnil
             Fix For: 8.0.1.Final


Warns the user if a address-setting has defined an expiry-address or a dead-letter-address with no queue bound for them as this will result in unintended message loss.

WildFly default full configuration specifies an expiry address (jms.queue.ExpiryQueue) and dead-letter-addres (jms.queue.DLQ) for the # address settings (i.e. matching all addresses).
To have a consistent configuration, we must also define 2 queues that will be bound to these settings.


--
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

From issues at jboss.org  Mon Mar 10 07:31:11 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 10 Mar 2014 07:31:11 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3094) Warn if there is no resource
 bound for address-settings expiry and dead-letter addresses
In-Reply-To: <JIRA.12534528.1394450392000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534528.1394450392000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534528.1394450392000.662.1394451071025@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-3094?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated WFLY-3094:
------------------------------------------

        Bugzilla Update: Perform
    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1014099

    
> Warn if there is no resource bound for address-settings expiry and dead-letter addresses
> ----------------------------------------------------------------------------------------
>
>                 Key: WFLY-3094
>                 URL: https://issues.jboss.org/browse/WFLY-3094
>             Project: WildFly
>          Issue Type: Enhancement
>      Security Level: Public(Everyone can see) 
>          Components: JMS
>    Affects Versions: 8.0.0.Final
>            Reporter: Jeff Mesnil
>            Assignee: Jeff Mesnil
>             Fix For: 8.0.1.Final
>
>
> Warns the user if a address-setting has defined an expiry-address or a dead-letter-address with no queue bound for them as this will result in unintended message loss.
> WildFly default full configuration specifies an expiry address (jms.queue.ExpiryQueue) and dead-letter-addres (jms.queue.DLQ) for the # address settings (i.e. matching all addresses).
> To have a consistent configuration, we must also define 2 queues that will be bound to these settings.

--
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

From issues at jboss.org  Mon Mar 10 07:43:11 2014
From: issues at jboss.org (Bela Ban (JIRA))
Date: Mon, 10 Mar 2014 07:43:11 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1765) TP: enable loopback by
 default and discard own multicasts
In-Reply-To: <JIRA.12528488.1388489261000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528488.1388489261000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528488.1388489261000.700.1394451791016@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JGRP-1765?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12951495#comment-12951495 ] 

Bela Ban commented on JGRP-1765:
--------------------------------

To avoid having to deserialize a message or message batch sent by self, only to discard it later, the sender's address should be read first. (We cannot use the sender's physical address, as a multicast to local:7500 would not reveal the sender's local port).

E.g if P multicasts 100 messages, the current algorithm works as follows:
* The byte buffer representing the 100 messages is received
* We parse the messages and create one or more batches
* All batches sent from P are discarded (if loopback is true)
--> The deserialization and creation of memory to hold the batch was not needed as it was discarded anyway
                
> TP: enable loopback by default and discard own multicasts
> ---------------------------------------------------------
>
>                 Key: JGRP-1765
>                 URL: https://issues.jboss.org/browse/JGRP-1765
>             Project: JGroups
>          Issue Type: Enhancement
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 3.5
>
>
> Enable {{TP.looback}} by default (deprecate and ignore prop): all messages sent by self are passed right to a thread pool to send them up again.
> When a multicast message sent by self is received, it is currently passed to a thread pool, de-serialized and only then discarded if loopback=true. This means that we create an unneeded buffer for de-serializationand perform de-serialization.
> SOLUTION: discard the multicast from self immediately when receiving it, in {{TP.receive()}}

--
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

From issues at jboss.org  Mon Mar 10 08:17:11 2014
From: issues at jboss.org (Miroslav Novak (JIRA))
Date: Mon, 10 Mar 2014 08:17:11 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBMESSAGING-1941) Messaging deadlocks on
 AspectManager
In-Reply-To: <JIRA.12484258.1360189635000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12484258.1360189635000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12484258.1360189635000.841.1394453831987@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JBMESSAGING-1941?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12951510#comment-12951510 ] 

Miroslav Novak commented on JBMESSAGING-1941:
---------------------------------------------

[~aogburn]
Can you merge this fix to JBM dev branch so Howard can create new tag of JBM with this fix for EAP 5.3.0.x, please?
                
> Messaging deadlocks on AspectManager
> ------------------------------------
>
>                 Key: JBMESSAGING-1941
>                 URL: https://issues.jboss.org/browse/JBMESSAGING-1941
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 1.4.8.SP9
>         Environment: -JBoss Enterprise Application Platform (EAP) 5
>            Reporter: Aaron Ogburn
>         Attachments: 00779442testpatch.diff
>
>
> Messaging can stall JBoss at start up.  The hang occurs as the main thread blocks in different locations in JMS trying to acquire the AspectManager instance lock:
> {noformat} 
> "main" prio=10 tid=0x00007fe69c1e1000 nid=0x3613 waiting for monitor entry [0x00007fe6828e5000]
>    java.lang.Thread.State: BLOCKED (on object monitor)
>         at org.jboss.aop.AspectManager.getAdvisor(AspectManager.java:728)
>         - waiting to lock <0x00000000a5e43e50> (a org.jboss.aop.AspectManager)
>         at org.jboss.jms.server.endpoint.advised.SessionAdvised.<clinit>(SessionAdvised.java)
>         at org.jboss.jms.server.endpoint.ServerConnectionEndpoint.createSessionDelegate(ServerConnectionEndpoint.java:273)
>         - locked <0x00000000a5600f48> (a org.jboss.aop.asintegration.jboss5.ScopedVFSClassLoaderDomain)
>         at org.jboss.jms.server.endpoint.ServerConnectionEndpoint.createSessionDelegate(ServerConnectionEndpoint.java:229)
> {noformat} 
> Since the main thread is stalled, so too is start up.  This lock is always held by another making a similar call like so:
> {noformat} 
> "WorkManager(2)-1" daemon prio=10 tid=0x00007fe62dd96000 nid=0x363e in
> Object.wait() [0x00007fe68029a000]
>    java.lang.Thread.State: RUNNABLE
>         at org.jboss.jms.server.endpoint.ServerConnectionEndpoint.createSessionDelegate(ServerConnectionEndpoint.java:273)
>         - locked <0x00000000a5e43e50> (a org.jboss.aop.AspectManager)
>         at org.jboss.jms.server.endpoint.ServerConnectionEndpoint.createSessionDelegate(ServerConnectionEndpoint.java:229)
> {noformat} 
> The code there at line 273 is simple enough and shouldn't cause a long stall:
> {code:title=org.jboss.jms.server.endpoint.ServerConnectionEndpoint.java|borderStyle=solid}
>          synchronized (AspectManager.instance())
>          {
>             advised = new SessionAdvised(ep);     // line 273
>          }
> {code}
> Nonetheless, it does clearly hang at this line as WorkManager(2)-1 never progresses.  There's no GC/CPU issues or anything of that nature, but we get a slight in the thread dump as WorkManager(2)-1 is shown to be in Object.wait().  Checking the thread through pstack, we can see the issue.  It is waiting in native/JDK level operations required to initialize the SessionAdvised class:
> {noformat}
> Thread 2 (Thread 0x7fe68029d700 (LWP 13886)):
> #0  0x0000003b3e40b43c in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
> #1  0x00007fe6a12d447e in os:latformEvent:ark() () from /opt/app/jvm/jdk1.6.0_38/jre/lib/amd64/server/libjvm.so
> #2  0x00007fe6a12c54fa in ObjectMonitor::wait(long, bool, Thread*) () from /opt/app/jvm/jdk1.6.0_38/jre/lib/amd64/server/libjvm.so
> #3  0x00007fe6a13ab5f0 in ObjectSynchronizer::waitUninterruptibly(Handle, long, Thread*) () from /opt/app/jvm/jdk1.6.0_38/jre/lib/amd64/server/libjvm.so
> #4  0x00007fe6a107115b in instanceKlass::initialize_impl(instanceKlassHandle, Thread*) () from /opt/app/jvm/jdk1.6.0_38/jre/lib/amd64/server/libjvm.so
> #5  0x00007fe6a107077a in instanceKlass::initialize(Thread*) () from /opt/app/jvm/jdk1.6.0_38/jre/lib/amd64/server/libjvm.so
> #6  0x00007fe6a1097c5c in InterpreterRuntime::_new(JavaThread*, constantPoolOopDesc*, int) () from /opt/app/jvm/jdk1.6.0_38/jre/lib/amd64/server/libjvm.so
> {noformat}
> These calls are naturally synchronized internally in the JVM so only one thread can proceed through initialization of a class at a given time.  Checking for any threads in process of initializing SessionAdvised, we can see only the main thread is.  But the main thread is still blocked for the AspectManager lock.
> So we have a deadlock here.  The main thread holds the initialization lock while waiting for the AspectManager lock, while the WorkManager(2)-1 thread holds the AspectManager lock while waiting for the initialization lock.
> The initialization of SessionAdvised is wrapped in the synchronized block so the main thread should not have been able to proceed into the initialization at all without already possessing the AspectManager lock.  It locks the ScopedVFSClassLoaderDomain, which extends the AspectManager.  This is different from the actual AspectManager though that main tries to lock in the clinit call and that it deadlocks on.

--
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

From issues at jboss.org  Mon Mar 10 08:27:11 2014
From: issues at jboss.org (Miroslav Novak (JIRA))
Date: Mon, 10 Mar 2014 08:27:11 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBMESSAGING-1941) Messaging deadlocks on
 AspectManager
In-Reply-To: <JIRA.12484258.1360189635000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12484258.1360189635000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12484258.1360189635000.908.1394454431002@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JBMESSAGING-1941?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12951518#comment-12951518 ] 

Miroslav Novak commented on JBMESSAGING-1941:
---------------------------------------------

You should have commit rights at this moment to JBM dev branch, If not then write to hgao at redhat.com for help. 
                
> Messaging deadlocks on AspectManager
> ------------------------------------
>
>                 Key: JBMESSAGING-1941
>                 URL: https://issues.jboss.org/browse/JBMESSAGING-1941
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 1.4.8.SP9
>         Environment: -JBoss Enterprise Application Platform (EAP) 5
>            Reporter: Aaron Ogburn
>         Attachments: 00779442testpatch.diff
>
>
> Messaging can stall JBoss at start up.  The hang occurs as the main thread blocks in different locations in JMS trying to acquire the AspectManager instance lock:
> {noformat} 
> "main" prio=10 tid=0x00007fe69c1e1000 nid=0x3613 waiting for monitor entry [0x00007fe6828e5000]
>    java.lang.Thread.State: BLOCKED (on object monitor)
>         at org.jboss.aop.AspectManager.getAdvisor(AspectManager.java:728)
>         - waiting to lock <0x00000000a5e43e50> (a org.jboss.aop.AspectManager)
>         at org.jboss.jms.server.endpoint.advised.SessionAdvised.<clinit>(SessionAdvised.java)
>         at org.jboss.jms.server.endpoint.ServerConnectionEndpoint.createSessionDelegate(ServerConnectionEndpoint.java:273)
>         - locked <0x00000000a5600f48> (a org.jboss.aop.asintegration.jboss5.ScopedVFSClassLoaderDomain)
>         at org.jboss.jms.server.endpoint.ServerConnectionEndpoint.createSessionDelegate(ServerConnectionEndpoint.java:229)
> {noformat} 
> Since the main thread is stalled, so too is start up.  This lock is always held by another making a similar call like so:
> {noformat} 
> "WorkManager(2)-1" daemon prio=10 tid=0x00007fe62dd96000 nid=0x363e in
> Object.wait() [0x00007fe68029a000]
>    java.lang.Thread.State: RUNNABLE
>         at org.jboss.jms.server.endpoint.ServerConnectionEndpoint.createSessionDelegate(ServerConnectionEndpoint.java:273)
>         - locked <0x00000000a5e43e50> (a org.jboss.aop.AspectManager)
>         at org.jboss.jms.server.endpoint.ServerConnectionEndpoint.createSessionDelegate(ServerConnectionEndpoint.java:229)
> {noformat} 
> The code there at line 273 is simple enough and shouldn't cause a long stall:
> {code:title=org.jboss.jms.server.endpoint.ServerConnectionEndpoint.java|borderStyle=solid}
>          synchronized (AspectManager.instance())
>          {
>             advised = new SessionAdvised(ep);     // line 273
>          }
> {code}
> Nonetheless, it does clearly hang at this line as WorkManager(2)-1 never progresses.  There's no GC/CPU issues or anything of that nature, but we get a slight in the thread dump as WorkManager(2)-1 is shown to be in Object.wait().  Checking the thread through pstack, we can see the issue.  It is waiting in native/JDK level operations required to initialize the SessionAdvised class:
> {noformat}
> Thread 2 (Thread 0x7fe68029d700 (LWP 13886)):
> #0  0x0000003b3e40b43c in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
> #1  0x00007fe6a12d447e in os:latformEvent:ark() () from /opt/app/jvm/jdk1.6.0_38/jre/lib/amd64/server/libjvm.so
> #2  0x00007fe6a12c54fa in ObjectMonitor::wait(long, bool, Thread*) () from /opt/app/jvm/jdk1.6.0_38/jre/lib/amd64/server/libjvm.so
> #3  0x00007fe6a13ab5f0 in ObjectSynchronizer::waitUninterruptibly(Handle, long, Thread*) () from /opt/app/jvm/jdk1.6.0_38/jre/lib/amd64/server/libjvm.so
> #4  0x00007fe6a107115b in instanceKlass::initialize_impl(instanceKlassHandle, Thread*) () from /opt/app/jvm/jdk1.6.0_38/jre/lib/amd64/server/libjvm.so
> #5  0x00007fe6a107077a in instanceKlass::initialize(Thread*) () from /opt/app/jvm/jdk1.6.0_38/jre/lib/amd64/server/libjvm.so
> #6  0x00007fe6a1097c5c in InterpreterRuntime::_new(JavaThread*, constantPoolOopDesc*, int) () from /opt/app/jvm/jdk1.6.0_38/jre/lib/amd64/server/libjvm.so
> {noformat}
> These calls are naturally synchronized internally in the JVM so only one thread can proceed through initialization of a class at a given time.  Checking for any threads in process of initializing SessionAdvised, we can see only the main thread is.  But the main thread is still blocked for the AspectManager lock.
> So we have a deadlock here.  The main thread holds the initialization lock while waiting for the AspectManager lock, while the WorkManager(2)-1 thread holds the AspectManager lock while waiting for the initialization lock.
> The initialization of SessionAdvised is wrapped in the synchronized block so the main thread should not have been able to proceed into the initialization at all without already possessing the AspectManager lock.  It locks the ScopedVFSClassLoaderDomain, which extends the AspectManager.  This is different from the actual AspectManager though that main tries to lock in the clinit call and that it deadlocks on.

--
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

From issues at jboss.org  Mon Mar 10 09:43:10 2014
From: issues at jboss.org (Bela Ban (JIRA))
Date: Mon, 10 Mar 2014 09:43:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1765) TP: enable loopback by
 default and discard own multicasts
In-Reply-To: <JIRA.12528488.1388489261000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528488.1388489261000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528488.1388489261000.1420.1394458990784@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JGRP-1765?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12951571#comment-12951571 ] 

Bela Ban commented on JGRP-1765:
--------------------------------

Actually, we *can* use the sender's physical address: in UDP, we're now sending multicasts via the DatagramSocket and *not* the MulticastSocket (only used for receiving mcasts). This allows us to get the sender's address and (real, not mcast) port and thus we can discard messages from ourself.
                
> TP: enable loopback by default and discard own multicasts
> ---------------------------------------------------------
>
>                 Key: JGRP-1765
>                 URL: https://issues.jboss.org/browse/JGRP-1765
>             Project: JGroups
>          Issue Type: Enhancement
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 3.5
>
>
> Enable {{TP.looback}} by default (deprecate and ignore prop): all messages sent by self are passed right to a thread pool to send them up again.
> When a multicast message sent by self is received, it is currently passed to a thread pool, de-serialized and only then discarded if loopback=true. This means that we create an unneeded buffer for de-serializationand perform de-serialization.
> SOLUTION: discard the multicast from self immediately when receiving it, in {{TP.receive()}}

--
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

From issues at jboss.org  Mon Mar 10 09:45:10 2014
From: issues at jboss.org (Bela Ban (JIRA))
Date: Mon, 10 Mar 2014 09:45:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1765) TP: enable loopback by
 default and discard own multicasts
In-Reply-To: <JIRA.12528488.1388489261000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528488.1388489261000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528488.1388489261000.1431.1394459110680@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JGRP-1765?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12951575#comment-12951575 ] 

Bela Ban commented on JGRP-1765:
--------------------------------

The advantage over loopback=true is that now we discard the message or message batch without having to parse it. This means (1) we don't have the parsing costs for our own messages and (2) we don't use the thread pool to handle our own messages.
                
> TP: enable loopback by default and discard own multicasts
> ---------------------------------------------------------
>
>                 Key: JGRP-1765
>                 URL: https://issues.jboss.org/browse/JGRP-1765
>             Project: JGroups
>          Issue Type: Enhancement
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 3.5
>
>
> Enable {{TP.looback}} by default (deprecate and ignore prop): all messages sent by self are passed right to a thread pool to send them up again.
> When a multicast message sent by self is received, it is currently passed to a thread pool, de-serialized and only then discarded if loopback=true. This means that we create an unneeded buffer for de-serializationand perform de-serialization.
> SOLUTION: discard the multicast from self immediately when receiving it, in {{TP.receive()}}

--
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

From issues at jboss.org  Mon Mar 10 09:51:11 2014
From: issues at jboss.org (Tomaz Cerar (JIRA))
Date: Mon, 10 Mar 2014 09:51:11 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3095) Weld subsystem exposes way
 too much dependancies to user deployment
In-Reply-To: <JIRA.12534548.1394459414206@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534548.1394459414206@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534548.1394459414206.1485.1394459471253@jira02.app.mwc.hst.phx2.redhat.com>

Tomaz Cerar created WFLY-3095:
---------------------------------

             Summary: Weld subsystem exposes way too much dependancies to user deployment
                 Key: WFLY-3095
                 URL: https://issues.jboss.org/browse/WFLY-3095
             Project: WildFly
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: CDI / Weld
    Affects Versions: 8.0.0.Final
            Reporter: Tomaz Cerar
            Assignee: Stuart Douglas
            Priority: Critical


module org.jboss.as.weld should not be added as dependency to user deployment.
It has way too much dependencies and some of them export their dependencies which than end up in user deployment.

We should probably have extra module for stuff that is exposed to deployment.
Also lots of dependencies that weld subsystem has should be optional as we shouldn't be required to have dependency to almost every single subsystem we have as required.

--
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

From issues at jboss.org  Mon Mar 10 10:09:55 2014
From: issues at jboss.org (Tomaz Cerar (JIRA))
Date: Mon, 10 Mar 2014 10:09:55 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3095) Weld subsystem exposes way
 too much dependancies to user deployment
In-Reply-To: <JIRA.12534548.1394459414000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534548.1394459414000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534548.1394459414000.1608.1394460595975@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-3095?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tomaz Cerar reassigned WFLY-3095:
---------------------------------

    Assignee: Jozef Hartinger  (was: Stuart Douglas)


You ware already working on this, but was reverted later
https://github.com/wildfly/wildfly/pull/5739

We should fix this some how, maybe by introducing extra module that will be added to deployments instead of subsystem one.
                
> Weld subsystem exposes way too much dependancies to user deployment
> -------------------------------------------------------------------
>
>                 Key: WFLY-3095
>                 URL: https://issues.jboss.org/browse/WFLY-3095
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: CDI / Weld
>    Affects Versions: 8.0.0.Final
>            Reporter: Tomaz Cerar
>            Assignee: Jozef Hartinger
>            Priority: Critical
>
> module org.jboss.as.weld should not be added as dependency to user deployment.
> It has way too much dependencies and some of them export their dependencies which than end up in user deployment.
> We should probably have extra module for stuff that is exposed to deployment.
> Also lots of dependencies that weld subsystem has should be optional as we shouldn't be required to have dependency to almost every single subsystem we have as required.

--
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

From issues at jboss.org  Mon Mar 10 10:21:11 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 10 Mar 2014 10:21:11 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3069) slaves cannot reconnect to a
 restarted master if RBAC is enabled
In-Reply-To: <JIRA.12534143.1394020494000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534143.1394020494000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534143.1394020494000.1660.1394461271316@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-3069?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12951601#comment-12951601 ] 

RH Bugzilla Integration commented on WFLY-3069:
-----------------------------------------------

Emanuel Muckenhuber <emuckenh at redhat.com> changed the Status of [bug 1072915|https://bugzilla.redhat.com/show_bug.cgi?id=1072915] from ASSIGNED to POST
                
> slaves cannot reconnect to a restarted master if RBAC is enabled
> ----------------------------------------------------------------
>
>                 Key: WFLY-3069
>                 URL: https://issues.jboss.org/browse/WFLY-3069
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>    Affects Versions: 8.0.0.Final
>            Reporter: Tom Fonteyne
>            Assignee: Emanuel Muckenhuber
>            Priority: Critical
>             Fix For: 8.0.1.Final
>
>
> Enable RBAC in an Wilfly domain setup. "reload --host=master" and the slaves will no longer be connected to the master

--
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

From issues at jboss.org  Mon Mar 10 10:25:10 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 10 Mar 2014 10:25:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3078) directory-grouping
 configuration is not getting persisted via CLI when no servers defined
In-Reply-To: <JIRA.12534347.1394159920000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534347.1394159920000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534347.1394159920000.1683.1394461510840@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-3078?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12951607#comment-12951607 ] 

RH Bugzilla Integration commented on WFLY-3078:
-----------------------------------------------

Emanuel Muckenhuber <emuckenh at redhat.com> changed the Status of [bug 1073715|https://bugzilla.redhat.com/show_bug.cgi?id=1073715] from NEW to POST
                
> directory-grouping configuration is not getting persisted via CLI when no servers defined
> -----------------------------------------------------------------------------------------
>
>                 Key: WFLY-3078
>                 URL: https://issues.jboss.org/browse/WFLY-3078
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>    Affects Versions: 8.0.0.Final
>         Environment: All Operating System
>            Reporter: Jay Kumar SenSharma
>            Assignee: Emanuel Muckenhuber
>             Fix For: 8.0.1.Final
>
>
> - If none of the servers are defined in "host.xml" (means <servers></servers> empty tag is present) and if the user tries to run the following CLI command to change the "directory-grouping" to  "by-type"  then the value is not persisted in the configuration file (host.xml) and the <servers></servers>  tag is also removed from the host.xml
> {code}
> /host=master/:write-attribute(name=directory-grouping,value=by-type)
> {code}
> - The value of "directory-grouping" is stored "in memory" so this change does not survive the host restart.

--
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

From issues at jboss.org  Mon Mar 10 10:51:12 2014
From: issues at jboss.org (Harald Wellmann (JIRA))
Date: Mon, 10 Mar 2014 10:51:12 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBASMP-64) undeploy-artifact fails with
 misleading error message
In-Reply-To: <JIRA.12534560.1394463069994@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534560.1394463069994@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534560.1394463069994.1871.1394463072279@jira02.app.mwc.hst.phx2.redhat.com>

Harald Wellmann created JBASMP-64:
-------------------------------------

             Summary: undeploy-artifact fails with misleading error message
                 Key: JBASMP-64
                 URL: https://issues.jboss.org/browse/JBASMP-64
             Project: JBoss AS Maven Plugins
          Issue Type: Bug
         Environment: wildfly-maven-plugin 1.0.1.Final
WildFly 8.0.0.Final, Oracle Java 1.7.0_51, Ubuntu 13.10 64-bit
            Reporter: Harald Wellmann
            Assignee: James Perkins


undeploy-artifact fails with the following exception (mvn -X):

{noformat}
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.wildfly.plugins:wildfly-maven-plugin:1.0.1.Final:undeploy-artifact (undeploy) on project deployment: com.example.myapp
	at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:213)
	at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
	at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
	at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
	at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
	at org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
	at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
	at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:320)
	at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
	at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537)
	at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)
	at org.apache.maven.cli.MavenCli.main(MavenCli.java:141)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:606)
	at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
	at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
	at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409)
	at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352)
Caused by: org.wildfly.plugin.common.DeploymentFailureException: com.example.myapp
	at org.wildfly.plugin.deployment.UndeployArtifactMojo.validate(UndeployArtifactMojo.java:92)
	at org.wildfly.plugin.deployment.AbstractDeployment.doExecute(AbstractDeployment.java:136)
	at org.wildfly.plugin.deployment.AbstractDeployment.execute(AbstractDeployment.java:111)
	at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
	at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
	... 19 more

{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

From issues at jboss.org  Mon Mar 10 10:57:10 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 10 Mar 2014 10:57:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2912) Generic JMS adapter does not
 deploy correctly in domain mode.
In-Reply-To: <JIRA.12531873.1392202779000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12531873.1392202779000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12531873.1392202779000.1880.1394463430759@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2912?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated WFLY-2912:
------------------------------------------

    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1064299, https://bugzilla.redhat.com/show_bug.cgi?id=1070106, https://bugzilla.redhat.com/show_bug.cgi?id=1074569  (was: https://bugzilla.redhat.com/show_bug.cgi?id=1064299, https://bugzilla.redhat.com/show_bug.cgi?id=1070106)

    
> Generic JMS adapter does not deploy correctly in domain mode.
> -------------------------------------------------------------
>
>                 Key: WFLY-2912
>                 URL: https://issues.jboss.org/browse/WFLY-2912
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JCA
>    Affects Versions: 8.0.0.Final
>            Reporter: Tom Ross
>            Assignee: Stefano Maestri
>             Fix For: 8.0.1.Final
>
>
> When trying to use generic resource adapter with third part JMS providers like TIBCO it is necessary to use generic RA provided in JBoss EAP 6.2. Unfortunately it would appear that when trying to use in domain mode the RA does not get deployed full, though it works perfectly in standalone mode.

--
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

From issues at jboss.org  Mon Mar 10 11:09:10 2014
From: issues at jboss.org (Harald Wellmann (JIRA))
Date: Mon, 10 Mar 2014 11:09:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBASMP-64) undeploy-artifact fails with
 misleading error message
In-Reply-To: <JIRA.12534560.1394463069000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534560.1394463069000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534560.1394463069000.1954.1394464150661@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBASMP-64?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Harald Wellmann updated JBASMP-64:
----------------------------------

    Git Pull Request: https://github.com/wildfly/wildfly-maven-plugin/pull/11

    
> undeploy-artifact fails with misleading error message
> -----------------------------------------------------
>
>                 Key: JBASMP-64
>                 URL: https://issues.jboss.org/browse/JBASMP-64
>             Project: JBoss AS Maven Plugins
>          Issue Type: Bug
>         Environment: wildfly-maven-plugin 1.0.1.Final
> WildFly 8.0.0.Final, Oracle Java 1.7.0_51, Ubuntu 13.10 64-bit
>            Reporter: Harald Wellmann
>            Assignee: James Perkins
>
> undeploy-artifact fails with the following exception (mvn -X):
> {noformat}
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.wildfly.plugins:wildfly-maven-plugin:1.0.1.Final:undeploy-artifact (undeploy) on project deployment: com.example.myapp
> 	at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:213)
> 	at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
> 	at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
> 	at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
> 	at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
> 	at org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
> 	at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
> 	at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:320)
> 	at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
> 	at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537)
> 	at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)
> 	at org.apache.maven.cli.MavenCli.main(MavenCli.java:141)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:606)
> 	at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
> 	at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
> 	at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409)
> 	at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352)
> Caused by: org.wildfly.plugin.common.DeploymentFailureException: com.example.myapp
> 	at org.wildfly.plugin.deployment.UndeployArtifactMojo.validate(UndeployArtifactMojo.java:92)
> 	at org.wildfly.plugin.deployment.AbstractDeployment.doExecute(AbstractDeployment.java:136)
> 	at org.wildfly.plugin.deployment.AbstractDeployment.execute(AbstractDeployment.java:111)
> 	at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
> 	at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
> 	... 19 more
> {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

From issues at jboss.org  Mon Mar 10 12:03:11 2014
From: issues at jboss.org (Paul Ferraro (JIRA))
Date: Mon, 10 Mar 2014 12:03:11 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2679) Jdbc cache store couldn't
 read databaseType property
In-Reply-To: <JIRA.12527992.1387184087000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12527992.1387184087000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12527992.1387184087000.2242.1394467391254@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2679?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Paul Ferraro closed WFLY-2679.
------------------------------

    Fix Version/s: 8.0.0.Final
                       (was: 8.0.1.Final)
       Resolution: Done


We already expose a dialect attribute, which allows you to configure the databaseType of the cache store.  If you want a fix for infinispan-cachestore-jdbc, then file a separate jira with infinispan.
                
> Jdbc cache store couldn't read databaseType property
> ----------------------------------------------------
>
>                 Key: WFLY-2679
>                 URL: https://issues.jboss.org/browse/WFLY-2679
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Clustering
>    Affects Versions: 8.0.0.CR1
>         Environment: WildFly 8.0.0.Final-SNAPSHOT from 2014-01-17
>            Reporter: Tomas Remes
>            Assignee: Paul Ferraro
>             Fix For: 8.0.0.Final
>
>
> If you want use some driver, which  type is not recognizable by Infinispan (e.g. jtds driver), then you are asked to specify your DB type via "databaseType" property in your cache store configuration. But when you specify it, you'll get following exception:
> {noformat}
> org.infinispan.commons.CacheConfigurationException: Couldn't find a setter named [setDatabaseType] which takes a single parameter, for parameter databaseType on class [class org.infinispan.persistence.jdbc.configuration.JdbcBinaryStoreConfigurationBuilder]
> 	at org.infinispan.configuration.parsing.XmlConfigHelper.setValues(XmlConfigHelper.java:450)
> 	at org.infinispan.configuration.cache.AbstractStoreConfigurationBuilder.withProperties(AbstractStoreConfigurationBuilder.java:91)
> 	at org.infinispan.configuration.cache.AbstractStoreConfigurationBuilder.withProperties(AbstractStoreConfigurationBuilder.java:9)
> 	at org.jboss.as.clustering.infinispan.subsystem.CacheAdd.processModelNode(CacheAdd.java:542)
> 	at org.jboss.as.clustering.infinispan.subsystem.ClusteredCacheAdd.processModelNode(ClusteredCacheAdd.java:69)
> 	at org.jboss.as.clustering.infinispan.subsystem.SharedStateCacheAdd.processModelNode(SharedStateCacheAdd.java:50)
> 	at org.jboss.as.clustering.infinispan.subsystem.DistributedCacheAdd.processModelNode(DistributedCacheAdd.java:90)
> 	at org.jboss.as.clustering.infinispan.subsystem.CacheAdd.installRuntimeServices(CacheAdd.java:205)
> 	at org.jboss.as.clustering.infinispan.subsystem.CacheAdd.performRuntime(CacheAdd.java:179)
> 	at org.jboss.as.controller.AbstractAddStepHandler$1.execute(AbstractAddStepHandler.java:75) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> 	at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:591) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> 	at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:469) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> 	at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:273) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> 	at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:268) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> 	at org.jboss.as.controller.ParallelBootOperationStepHandler$ParallelBootTask.run(ParallelBootOperationStepHandler.java:343) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_45]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_45]
> 	at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_45]
> 	at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.1.Final.jar:2.1.1.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

From issues at jboss.org  Mon Mar 10 12:07:10 2014
From: issues at jboss.org (Paul Ferraro (JIRA))
Date: Mon, 10 Mar 2014 12:07:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2965) IllegalArgumentException:
 JBAS014577: Unsupported marshalling version: 1 on shutdown
In-Reply-To: <JIRA.12532706.1392826557000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12532706.1392826557000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12532706.1392826557000.2255.1394467630667@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2965?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12951651#comment-12951651 ] 

Paul Ferraro commented on WFLY-2965:
------------------------------------

The service providing the infinispan cache for the EJB deployment is missing a dependency on the service that provides the marshalling configuration.
                
> IllegalArgumentException: JBAS014577: Unsupported marshalling version: 1 on shutdown
> ------------------------------------------------------------------------------------
>
>                 Key: WFLY-2965
>                 URL: https://issues.jboss.org/browse/WFLY-2965
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Clustering
>    Affects Versions: 8.0.0.Final
>         Environment: jdk8
>            Reporter: Radoslav Husar
>            Assignee: Paul Ferraro
>
> {noformat}
> ^C17:12:20,850 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-4) JBAS017535: Unregistered web context: /clusterbench-passivating
> 17:12:20,852 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-8) JBAS017535: Unregistered web context: /clusterbench-granular
> 17:12:20,852 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-2) JBAS017535: Unregistered web context: /clusterbench
> 17:12:20,859 INFO  [org.jboss.modcluster] (ServerService Thread Pool -- 66) MODCLUSTER000002: Initiating mod_cluster shutdown
> 17:12:20,870 SEVERE [javax.faces] (MSC service thread 1-8) Unable to obtain InjectionProvider from init time FacesContext. Does this container implement the Mojarra Injection SPI?
> 17:12:20,872 SEVERE [javax.faces] (MSC service thread 1-8) Unable to call @PreDestroy annotated methods because no InjectionProvider can be found. Does this container implement the Mojarra Injection SPI?
> 17:12:20,872 SEVERE [javax.faces] (MSC service thread 1-8) Unable to obtain InjectionProvider from init time FacesContext. Does this container implement the Mojarra Injection SPI?
> 17:12:20,872 SEVERE [javax.faces] (MSC service thread 1-8) Unable to call @PreDestroy annotated methods because no InjectionProvider can be found. Does this container implement the Mojarra Injection SPI?
> 17:12:20,884 INFO  [org.infinispan.eviction.PassivationManagerImpl] (ServerService Thread Pool -- 68) ISPN000029: Passivating all entries to disk
> 17:12:20,885 INFO  [org.infinispan.eviction.PassivationManagerImpl] (ServerService Thread Pool -- 68) ISPN000030: Passivated 0 entries in 0 milliseconds
> 17:12:20,890 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-1) JBAS017532: Host default-host stopping
> 17:12:20,873 INFO  [org.infinispan.eviction.PassivationManagerImpl] (ServerService Thread Pool -- 66) ISPN000029: Passivating all entries to disk
> 17:12:20,896 INFO  [org.infinispan.eviction.PassivationManagerImpl] (ServerService Thread Pool -- 65) ISPN000029: Passivating all entries to disk
> 17:12:20,896 INFO  [org.infinispan.eviction.PassivationManagerImpl] (ServerService Thread Pool -- 78) ISPN000029: Passivating all entries to disk
> 17:12:20,897 INFO  [org.infinispan.eviction.PassivationManagerImpl] (ServerService Thread Pool -- 65) ISPN000030: Passivated 0 entries in 0 milliseconds
> 17:12:20,912 INFO  [org.jboss.weld.deployer] (MSC service thread 1-6) JBAS016009: Stopping weld service for deployment clusterbench-ee7.ear
> 17:12:20,917 INFO  [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-3) JBAS010409: Unbound data source [java:jboss/datasources/ExampleDS]
> 17:12:20,930 INFO  [org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-7) JBAS010418: Stopped Driver service with driver-name = h2
> 17:12:20,930 INFO  [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 68) JBAS010282: Stopped default-host/clusterbench-passivating cache from web container
> 17:12:20,932 INFO  [org.infinispan.eviction.PassivationManagerImpl] (ServerService Thread Pool -- 77) ISPN000029: Passivating all entries to disk
> 17:12:20,934 INFO  [org.infinispan.eviction.PassivationManagerImpl] (ServerService Thread Pool -- 78) ISPN000030: Passivated 2 entries in 37 milliseconds
> 17:12:20,950 INFO  [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 65) JBAS010282: Stopped default-host/clusterbench-granular cache from web container
> 17:12:20,950 INFO  [org.infinispan.eviction.PassivationManagerImpl] (ServerService Thread Pool -- 77) ISPN000030: Passivated 1 entries in 18 milliseconds
> 17:12:20,963 INFO  [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 78) JBAS010282: Stopped default-host/clusterbench cache from web container
> 17:12:20,981 INFO  [org.infinispan.eviction.PassivationManagerImpl] (ServerService Thread Pool -- 78) ISPN000029: Passivating all entries to disk
> 17:12:20,982 INFO  [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 77) JBAS010282: Stopped dist cache from web container
> 17:12:20,942 WARN  [org.infinispan.factories.ComponentRegistry] (ServerService Thread Pool -- 66) ISPN000189: While stopping a cache or cache manager, one of its components failed to stop: org.infinispan.commons.CacheException: Unable to invoke method public void org.infinispan.eviction.PassivationManagerImpl.passivateAll() throws org.infinispan.persistence.spi.PersistenceException on object of type PassivationManagerImpl
> 	at org.infinispan.commons.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:185)
> 	at org.infinispan.factories.AbstractComponentRegistry$PrioritizedMethod.invoke(AbstractComponentRegistry.java:869)
> 	at org.infinispan.factories.AbstractComponentRegistry.internalStop(AbstractComponentRegistry.java:674)
> 	at org.infinispan.factories.AbstractComponentRegistry.stop(AbstractComponentRegistry.java:552)
> 	at org.infinispan.factories.ComponentRegistry.stop(ComponentRegistry.java:241)
> 	at org.infinispan.CacheImpl.stop(CacheImpl.java:697)
> 	at org.infinispan.CacheImpl.stop(CacheImpl.java:692)
> 	at org.infinispan.AbstractDelegatingCache.stop(AbstractDelegatingCache.java:316)
> 	at org.jboss.as.clustering.infinispan.subsystem.CacheService.stop(CacheService.java:96)
> 	at org.jboss.as.clustering.msc.AsynchronousService$2.run(AsynchronousService.java:114) [wildfly-clustering-common-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0]
> 	at java.lang.Thread.run(Thread.java:744) [rt.jar:1.8.0]
> 	at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.1.Final.jar:2.1.1.Final]
> Caused by: org.infinispan.persistence.spi.PersistenceException: org.infinispan.persistence.spi.PersistenceException: java.lang.IllegalArgumentException: JBAS014577: Unsupported marshalling version: 1
> 	at org.infinispan.persistence.file.SingleFileStore.write(SingleFileStore.java:317)
> 	at org.infinispan.persistence.manager.PersistenceManagerImpl.writeToAllStores(PersistenceManagerImpl.java:457)
> 	at org.infinispan.eviction.PassivationManagerImpl.passivateAll(PassivationManagerImpl.java:94)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.8.0]
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) [rt.jar:1.8.0]
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.8.0]
> 	at java.lang.reflect.Method.invoke(Method.java:483) [rt.jar:1.8.0]
> 	at org.infinispan.commons.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:183)
> 	... 13 more
> Caused by: org.infinispan.persistence.spi.PersistenceException: java.lang.IllegalArgumentException: JBAS014577: Unsupported marshalling version: 1
> 	at org.infinispan.marshall.core.MarshalledEntryImpl.marshall(MarshalledEntryImpl.java:107)
> 	at org.infinispan.marshall.core.MarshalledEntryImpl.getValueBytes(MarshalledEntryImpl.java:88)
> 	at org.infinispan.persistence.file.SingleFileStore.write(SingleFileStore.java:275)
> 	... 20 more
> Caused by: java.lang.IllegalArgumentException: JBAS014577: Unsupported marshalling version: 1
> 	at org.jboss.as.ejb3.component.stateful.VersionedMarshallingConfigurationService.getMarshallingConfiguration(VersionedMarshallingConfigurationService.java:88)
> 	at org.jboss.as.clustering.marshalling.SimpleMarshallingContext.getMarshallingConfiguration(SimpleMarshallingContext.java:69) [wildfly-clustering-common-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> 	at org.jboss.as.clustering.marshalling.SimpleMarshallingContext.createMarshaller(SimpleMarshallingContext.java:65) [wildfly-clustering-common-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> 	at org.jboss.as.clustering.marshalling.SimpleMarshalledValue.getBytes(SimpleMarshalledValue.java:75) [wildfly-clustering-common-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> 	at org.jboss.as.clustering.marshalling.SimpleMarshalledValue.writeExternal(SimpleMarshalledValue.java:150) [wildfly-clustering-common-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> 	at org.jboss.marshalling.river.RiverMarshaller.doWriteObject(RiverMarshaller.java:876)
> 	at org.jboss.marshalling.AbstractObjectOutput.writeObject(AbstractObjectOutput.java:62) [jboss-marshalling-1.4.3.Final.jar:1.4.3.Final]
> 	at org.jboss.marshalling.AbstractMarshaller.writeObject(AbstractMarshaller.java:115) [jboss-marshalling-1.4.3.Final.jar:1.4.3.Final]
> 	at org.wildfly.clustering.ejb.infinispan.group.InfinispanBeanGroupEntryExternalizer.writeObject(InfinispanBeanGroupEntryExternalizer.java:50)
> 	at org.wildfly.clustering.ejb.infinispan.group.InfinispanBeanGroupEntryExternalizer.writeObject(InfinispanBeanGroupEntryExternalizer.java:36)
> 	at org.infinispan.marshall.core.ExternalizerTable$ForeignExternalizerAdapter.writeObject(ExternalizerTable.java:444)
> 	at org.jboss.marshalling.river.RiverMarshaller.doWriteObject(RiverMarshaller.java:148)
> 	at org.jboss.marshalling.AbstractObjectOutput.writeObject(AbstractObjectOutput.java:62) [jboss-marshalling-1.4.3.Final.jar:1.4.3.Final]
> 	at org.jboss.marshalling.AbstractMarshaller.writeObject(AbstractMarshaller.java:115) [jboss-marshalling-1.4.3.Final.jar:1.4.3.Final]
> 	at org.infinispan.commons.marshall.jboss.AbstractJBossMarshaller.objectToObjectStream(AbstractJBossMarshaller.java:74)
> 	at org.infinispan.marshall.core.VersionAwareMarshaller.objectToBuffer(VersionAwareMarshaller.java:77)
> 	at org.infinispan.commons.marshall.AbstractMarshaller.objectToBuffer(AbstractMarshaller.java:41)
> 	at org.infinispan.commons.marshall.AbstractDelegatingMarshaller.objectToBuffer(AbstractDelegatingMarshaller.java:85)
> 	at org.infinispan.marshall.core.MarshalledEntryImpl.marshall(MarshalledEntryImpl.java:105)
> 	... 22 more
> Caused by: an exception which occurred:
> 	in object org.jboss.as.clustering.marshalling.SimpleMarshalledValue at d8dbecb5
> 	in object org.wildfly.clustering.ejb.infinispan.group.InfinispanBeanGroupEntry at 2fb506a3
> 17:12:20,988 INFO  [org.infinispan.eviction.PassivationManagerImpl] (ServerService Thread Pool -- 78) ISPN000030: Passivated 1 entries in 6 milliseconds
> 17:12:21,009 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-2) ISPN000080: Disconnecting JGroups Channel
> 17:12:21,022 INFO  [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 78) JBAS010282: Stopped dist cache from ejb container
> 17:12:21,023 INFO  [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 66) JBAS010282: Stopped clusterbench-ee7.ear/clusterbench-ee7-ejb-1.1.0-SNAPSHOT.jar cache from ejb container
> 17:12:21,026 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-6) ISPN000080: Disconnecting JGroups Channel
> 17:12:21,027 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-3) JBAS017521: Undertow HTTP listener default suspending
> 17:12:21,028 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-3) JBAS017520: Undertow HTTP listener default stopped, was bound to /127.0.0.1:8080
> 17:12:21,027 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-7) JBAS017521: Undertow AJP listener ajp suspending
> 17:12:21,034 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-7) JBAS017520: Undertow AJP listener ajp stopped, was bound to /127.0.0.1:8009
> 17:12:21,038 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-8) JBAS015877: Stopped deployment null (runtime-name: clusterbench-ee7-web-1.1.0-SNAPSHOT-granular.war) in 202ms
> 17:12:21,041 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-4) JBAS015877: Stopped deployment null (runtime-name: clusterbench-ee7-web-1.1.0-SNAPSHOT-default.war) in 209ms
> 17:12:21,035 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-3) JBAS015877: Stopped deployment null (runtime-name: clusterbench-ee7-ejb-1.1.0-SNAPSHOT.jar) in 200ms
> 17:12:21,035 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-1) JBAS015877: Stopped deployment null (runtime-name: clusterbench-ee7-web-1.1.0-SNAPSHOT-passivating.war) in 203ms
> 17:12:21,041 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-8) JBAS017506: Undertow 1.0.0.Final stopping
> 17:12:21,042 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-1) JBAS015877: Stopped deployment clusterbench-ee7.ear (runtime-name: clusterbench-ee7.ear) in 211ms
> 17:12:21,390 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-6) ISPN000082: Stopping the RpcDispatcher
> 17:12:21,392 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-2) ISPN000082: Stopping the RpcDispatcher
> 17:12:21,400 INFO  [org.jboss.as] (MSC service thread 1-1) JBAS015950: WildFly 8.0.1.Final-SNAPSHOT "WildFly" stopped in 565ms
> {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

From issues at jboss.org  Mon Mar 10 12:09:11 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 10 Mar 2014 12:09:11 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1806) UnicastLoopbackTest fails to
 receive all messages in the allotted time
In-Reply-To: <JIRA.12534313.1394124154000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534313.1394124154000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534313.1394124154000.2263.1394467751272@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JGRP-1806?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated JGRP-1806:
------------------------------------------

        Bugzilla Update: Perform
    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=927921

    
> UnicastLoopbackTest fails to receive all messages in the allotted time
> ----------------------------------------------------------------------
>
>                 Key: JGRP-1806
>                 URL: https://issues.jboss.org/browse/JGRP-1806
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.2.13
>         Environment: RHEL, Windows, Solaris
>            Reporter: Richard Achmatowicz
>            Assignee: Bela Ban
>             Fix For: 3.2.13
>
>
> UnicastLoopbackTest.testUnicastMessagesWithLoopback() is failing with the following error:
> {noformat}
> Error Message
> Test timed out before all messages were received
> Stacktrace
> java.lang.AssertionError 
> at org.testng.Assert.fail(Assert.java:94) 
> at org.jgroups.tests.UnicastLoopbackTest.testUnicastMsgsWithLoopback(UnicastLoopbackTest.java:78) 
> {noformat}
> The test does the following:
> - creates one channel with loopback enabled in the transport
> - the channel is assigned a receiver which collects the messages received and sets a Boolean valued Promise when all messages have been received 
> - the channel sends 1000 messages to itself in a burst
> - waits 20 seconds for the promise to be set to true
> The test fails because the messages do not arrive within the allotted 20 seconds.

--
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

From issues at jboss.org  Mon Mar 10 12:09:11 2014
From: issues at jboss.org (Richard Achmatowicz (JIRA))
Date: Mon, 10 Mar 2014 12:09:11 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1806) UnicastLoopbackTest fails to
 receive all messages in the allotted time
In-Reply-To: <JIRA.12534313.1394124154000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534313.1394124154000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534313.1394124154000.2268.1394467751490@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JGRP-1806?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Richard Achmatowicz updated JGRP-1806:
--------------------------------------

    Bugzilla Update:   (was: Perform)

    
> UnicastLoopbackTest fails to receive all messages in the allotted time
> ----------------------------------------------------------------------
>
>                 Key: JGRP-1806
>                 URL: https://issues.jboss.org/browse/JGRP-1806
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.2.13
>         Environment: RHEL, Windows, Solaris
>            Reporter: Richard Achmatowicz
>            Assignee: Bela Ban
>             Fix For: 3.2.13
>
>
> UnicastLoopbackTest.testUnicastMessagesWithLoopback() is failing with the following error:
> {noformat}
> Error Message
> Test timed out before all messages were received
> Stacktrace
> java.lang.AssertionError 
> at org.testng.Assert.fail(Assert.java:94) 
> at org.jgroups.tests.UnicastLoopbackTest.testUnicastMsgsWithLoopback(UnicastLoopbackTest.java:78) 
> {noformat}
> The test does the following:
> - creates one channel with loopback enabled in the transport
> - the channel is assigned a receiver which collects the messages received and sets a Boolean valued Promise when all messages have been received 
> - the channel sends 1000 messages to itself in a burst
> - waits 20 seconds for the promise to be set to true
> The test fails because the messages do not arrive within the allotted 20 seconds.

--
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

From issues at jboss.org  Mon Mar 10 12:13:11 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 10 Mar 2014 12:13:11 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1794) OOBTest method
 testNonBlockingUnicastOOBMessage fails to correctly receive all OOB mssages
In-Reply-To: <JIRA.12532999.1393010892000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12532999.1393010892000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12532999.1393010892000.2289.1394467991365@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JGRP-1794?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated JGRP-1794:
------------------------------------------

        Bugzilla Update: Perform
    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=910773

    
> OOBTest method testNonBlockingUnicastOOBMessage  fails to correctly receive all OOB mssages
> -------------------------------------------------------------------------------------------
>
>                 Key: JGRP-1794
>                 URL: https://issues.jboss.org/browse/JGRP-1794
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.2.13
>         Environment: Solaris, RHEL, Windows, HPUX
> tcp stack only
>            Reporter: Richard Achmatowicz
>            Assignee: Bela Ban
>             Fix For: 3.2.13
>
>
> This test fails regularly on multiple platforms. It doesn't fail all the time, but perhaps on 5/10 platform executions.
> The test consists of a sender and a receiver. The receiver B will receive OOB messages but blocks on a latch for 25 seconds when it receives a non-OOB message. After 25 seconds, it unblocks and continues receiving
> The test does this:
> - send 1 regular message from A -> B
> - send 9 OOB meesages from A -> B
> - wait 20 seconds for messages to arrive
> - check that all 9 OOB messages have arrived
> - unblock the latch
> - check that all 10 message have arrived
> The test failures all involve the first 9 OOB messages not arriving completely. For example, sample lists of received messages before the first 20 second interval are:
> [3,2,6,8,9,10,4]
> [2,3,4,8,9,5]
> [2,3,4,8,7,9]
> [2,3,5,4,6]
> So, it appears that either the messages are slow to arrive or not arriving at all.
> A correct result looks like this:
> {noformat}
> list = [2, 4, 3, 7, 8, 9, 10, 5, 6]
> [main]: releasing latch
> list = [2, 4, 3, 7, 8, 9, 10, 5, 6, 1]
> {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

From issues at jboss.org  Mon Mar 10 12:19:10 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 10 Mar 2014 12:19:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1802) OverlappingUnicastMergeTest
 fails to receive all messages
In-Reply-To: <JIRA.12533772.1393856602000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12533772.1393856602000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12533772.1393856602000.2298.1394468350723@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JGRP-1802?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated JGRP-1802:
------------------------------------------

        Bugzilla Update: Perform
    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=920741

    
> OverlappingUnicastMergeTest fails to receive all messages
> ---------------------------------------------------------
>
>                 Key: JGRP-1802
>                 URL: https://issues.jboss.org/browse/JGRP-1802
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.2.13
>         Environment: Solaris, RHEL
>            Reporter: Richard Achmatowicz
>            Assignee: Bela Ban
>             Fix For: 3.2.13
>
>
> OverlappingUnicastMergeTest does the following:
> - set up three channels a,b,c with the layers MERGE2, VERIFY_SUSPECT and FC removed
> - the receiver of each channel will look at all incoming messages: if mcast, ignore it; if unicast, add to the list of messages received
> - inject some new view into the channels which represents a view configuration which should be recovered from
> - send messages to the channels and check that the messages are received, despite the  injected view
> OverlappingUnicastMergeTest this test is failing in a number of ways (i.e. many of the test methods are failing within the test class on multiple platforms. 
> What we expect to see is:
> {noformat}
> receiver A: ucasts=15
> receiver B: ucasts=15
> receiver C: ucasts=15
> {noformat}
> What we instead see is:
> {noformat}
> receiver A: ucasts=15
> receiver B: ucasts=11
> ucasts for B: 
> B: unicast msg #1 from B B: unicast msg #2 from B B: unicast msg #3 from B B: unicast msg #4 from B B: unicast msg #5 from B  A: unicast msg #1 from A C: unicast msg #2 from C C: unicast msg #3 from C A: unicast msg #4 from A C: unicast msg #4 from C C: unicast msg #5 from C 
> {noformat}
> The order here is the order in which the unicasts were received from all three senders by the single receiver. For example, in the above, in testWithViewBC, channel A should receive messages #1 through #5 from channels A, B and C, but it does not receive #1 from channel C. 

--
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

From issues at jboss.org  Mon Mar 10 12:19:10 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 10 Mar 2014 12:19:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1805) OverlappingMergeTest
 testMergeWithDifferentPartitions fails to create correct merged view
In-Reply-To: <JIRA.12534032.1393962618000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534032.1393962618000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534032.1393962618000.2302.1394468350893@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JGRP-1805?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated JGRP-1805:
------------------------------------------

        Bugzilla Update: Perform
    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=920741

    
> OverlappingMergeTest testMergeWithDifferentPartitions fails to create correct merged view
> -----------------------------------------------------------------------------------------
>
>                 Key: JGRP-1805
>                 URL: https://issues.jboss.org/browse/JGRP-1805
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.2.13
>         Environment: RHEL
>            Reporter: Richard Achmatowicz
>            Assignee: Bela Ban
>             Fix For: 3.2.13
>
>
> This test does the following:
> - creates four channels a,b,c,d
> - injects views A: {A,C,B}, B:{A,C,B}, C:{A,C,B} and D: {B,A,C,D}
> - injects a merge event in each of channels A,B,C,D representing these four views
> - checks that all channels have the final view of size 4
> The test fails intermittently on RHEL, with the same failure each time:
> {noformat}
> 181595 [DEBUG] GMS: - A: installing view [A|2] [A]
>    [testng] 181596 [TRACE] GMS: - A: received all 1 ACKs from members for view [A|2]
>    [testng] 181866 [TRACE] GMS: - view [A|3] [] is empty: will not multicast it (last view)
>    [testng] 
>    [testng] -------------------------------------------------------------------
>    [testng] GMS: address=A, cluster=OverlappingMergeTest, physical address=10.16.94.42:27199
>    [testng] -------------------------------------------------------------------
>    [testng] 184954 [TRACE] GMS: - A: no initial members discovered: creating group as first member
>    [testng] 184954 [DEBUG] GMS: - A: installing view [A|0] [A]
>    [testng] 184955 [DEBUG] GMS: - created group (first member). My view is [A|0], impl is org.jgroups.protocols.pbcast.CoordGmsImpl
>    [testng] 
>    [testng] -------------------------------------------------------------------
>    [testng] GMS: address=B, cluster=OverlappingMergeTest, physical address=10.16.94.42:27200
>    [testng] -------------------------------------------------------------------
>    [testng] 184961 [TRACE] GMS: - B: initial_mbrs are A 
>    [testng] 184961 [DEBUG] GMS: - election results: {A=1}
>    [testng] 184961 [DEBUG] GMS: - sending JOIN(B) to A
>    [testng] 185013 [TRACE] GMS: - A: new members=[B], suspected=[], leaving=[], new view: [A|1] [A, B]
>    [testng] 185014 [TRACE] GMS: - A: mcasting view [A|1] [A, B] (2 mbrs)
>    [testng] 
>    [testng] 185025 [DEBUG] GMS: - A: installing view [A|1] [A, B]
>    [testng] 185026 [TRACE] GMS: - A: received all 1 ACKs from members for view [A|1]
>    [testng] 185055 [TRACE] GMS: - B: JOIN-RSP=[A|1] [A, B] [size=2]
>    [testng] 
>    [testng] 
>    [testng] 185055 [DEBUG] GMS: - B: installing view [A|1] [A, B]
>    [testng] 185057 [TRACE] GMS: - A: received all ACKs (1) from joiners for view [A|1]
>    [testng] 
>    [testng] -------------------------------------------------------------------
>    [testng] GMS: address=C, cluster=OverlappingMergeTest, physical address=10.16.94.42:27201
>    [testng] -------------------------------------------------------------------
>    [testng] 185064 [TRACE] GMS: - C: initial_mbrs are B A 
>    [testng] 185064 [DEBUG] GMS: - election results: {A=2}
>    [testng] 185064 [DEBUG] GMS: - sending JOIN(C) to A
>    [testng] 185108 [TRACE] GMS: - A: new members=[C], suspected=[], leaving=[], new view: [A|2] [A, B, C]
>    [testng] 185108 [TRACE] GMS: - A: mcasting view [A|2] [A, B, C] (3 mbrs)
>    [testng] 
>    [testng] 185117 [DEBUG] GMS: - A: installing view [A|2] [A, B, C]
>    [testng] 185118 [DEBUG] GMS: - B: installing view [A|2] [A, B, C]
>    [testng] 185119 [TRACE] GMS: - A: received all 2 ACKs from members for view [A|2]
>    [testng] 185148 [TRACE] GMS: - C: JOIN-RSP=[A|2] [A, B, C] [size=3]
>    [testng] 
>    [testng] 
>    [testng] 185149 [DEBUG] GMS: - C: installing view [A|2] [A, B, C]
>    [testng] 185151 [TRACE] GMS: - A: received all ACKs (1) from joiners for view [A|2]
>    [testng] 
>    [testng] -------------------------------------------------------------------
>    [testng] GMS: address=D, cluster=OverlappingMergeTest, physical address=10.16.94.42:27202
>    [testng] -------------------------------------------------------------------
>    [testng] 185164 [TRACE] GMS: - D: initial_mbrs are B C A 
>    [testng] 185164 [DEBUG] GMS: - election results: {A=3}
>    [testng] 185164 [DEBUG] GMS: - sending JOIN(D) to A
>    [testng] 185203 [TRACE] GMS: - A: new members=[D], suspected=[], leaving=[], new view: [A|3] [A, B, C, D]
>    [testng] 185203 [TRACE] GMS: - A: mcasting view [A|3] [A, B, C, D] (4 mbrs)
>    [testng] 
>    [testng] 185210 [DEBUG] GMS: - A: installing view [A|3] [A, B, C, D]
>    [testng] 185211 [DEBUG] GMS: - B: installing view [A|3] [A, B, C, D]
>    [testng] 185211 [DEBUG] GMS: - C: installing view [A|3] [A, B, C, D]
>    [testng] 185213 [TRACE] GMS: - A: received all 3 ACKs from members for view [A|3]
>    [testng] 185242 [TRACE] GMS: - D: JOIN-RSP=[A|3] [A, B, C, D] [size=4]
>    [testng] 
>    [testng] 
>    [testng] 185242 [DEBUG] GMS: - D: installing view [A|3] [A, B, C, D]
>    [testng] 185242 [TRACE] GMS: - A: received all ACKs (1) from joiners for view [A|3]
>    [testng] 
>    [testng]  ==== Injecting view [A|4] [A, C, B] into A, B and C ====
>    [testng] 185243 [DEBUG] GMS: - A: installing view [A|4] [A, C, B]
>    [testng] 185243 [DEBUG] GMS: - B: installing view [A|4] [A, C, B]
>    [testng] 185244 [DEBUG] GMS: - C: installing view [A|4] [A, C, B]
>    [testng] 
>    [testng]  ==== Injecting view [B|4] [B, A, C, D] into D ====
>    [testng] 
>    [testng] 185245 [DEBUG] GMS: - D: installing view [B|4] [B, A, C, D]
>    [testng] A: [A|4] [A, C, B]
>    [testng] B: [A|4] [A, C, B]
>    [testng] C: [A|4] [A, C, B]
>    [testng] D: [B|4] [B, A, C, D]
>    [testng] 
>    [testng] ==== Injecting a merge event into A, B, C and D====
>    [testng] 185251 [TRACE] GMS: - A: got merge response from A, merge_id=A::3, merge data is sender=A, view=[A|4] [A, C, B], digest=C: [0 (0)], B: [0 (0)], A: [4 (4)]
>    [testng] 185253 [TRACE] GMS: - B: queue is suspended; request MERGE(4 views) is discarded
>    [testng] 185255 [TRACE] GMS: - C: queue is suspended; request MERGE(4 views) is discarded
>    [testng] 185255 [TRACE] GMS: - A: got merge response from B, merge_id=A::3, merge data is sender=B, view=[A|4] [A, C, B], digest=C: [0 (0)], B: [0 (1)], A: [4 (4)]
>    [testng] 190286 [TRACE] GMS: - A: mcasting view MergeView::[A|5] [A, B, C], subgroups=[A|4] [A, C, B], [A|4] [A, C, B] (3 mbrs)
>    [testng] 
>    [testng] 190286 [TRACE] GMS: - B: mcasting view MergeView::[A|5] [A, B, C], subgroups=[A|4] [A, C, B], [A|4] [A, C, B] (3 mbrs)
>    [testng] 
>    [testng] 190317 [DEBUG] GMS: - A: installing view MergeView::[A|5] [A, B, C], subgroups=[A|4] [A, C, B], [A|4] [A, C, B]
>    [testng] 190318 [DEBUG] GMS: - B: installing view MergeView::[A|5] [A, B, C], subgroups=[A|4] [A, C, B], [A|4] [A, C, B]
>    [testng] 190318 [DEBUG] GMS: - C: installing view MergeView::[A|5] [A, B, C], subgroups=[A|4] [A, C, B], [A|4] [A, C, B]
>    [testng] 190320 [TRACE] GMS: - A: received all 3 ACKs from members for view [A|5]
>    [testng] 190320 [TRACE] GMS: - B: received all 3 ACKs from members for view [A|5]
>    [testng] A: [A|5] [A, B, C] (coord=true)
>    [testng] B: [A|5] [A, B, C] (coord=false)
>    [testng] C: [A|5] [A, B, C] (coord=false)
>    [testng] D: [B|4] [B, A, C, D] (coord=false)
>    [testng] 195277 [DEBUG] GMS: - D: sending LEAVE request to B
>    [testng] FAIL: [1] org.jgroups.tests.OverlappingMergeTest.testMergeWithDifferentPartitions()
> {noformat}
>  Whenever this test fails, I see that the queues are suspended on the initial merge attempt.

--
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

From issues at jboss.org  Mon Mar 10 12:21:11 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 10 Mar 2014 12:21:11 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1797) NakackTest
 testReceptionOfAllMessages fails to receive all messages
In-Reply-To: <JIRA.12533037.1393192228000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12533037.1393192228000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12533037.1393192228000.2336.1394468471638@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JGRP-1797?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated JGRP-1797:
------------------------------------------

        Bugzilla Update: Perform
    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=927966

    
> NakackTest testReceptionOfAllMessages fails to receive all messages
> -------------------------------------------------------------------
>
>                 Key: JGRP-1797
>                 URL: https://issues.jboss.org/browse/JGRP-1797
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.2.13
>         Environment: RHEL (5/24), Solaris (6/24), HPUX (1/2) where x/y means x failures over y test executions.
>            Reporter: Richard Achmatowicz
>            Assignee: Bela Ban
>             Fix For: 3.2.13
>
>         Attachments: stdout.txt
>
>
> This test does the following:
> - involves channels A, B, and C where only B and C are senders and all are receivers
> - B and C send 1000 multicast messages
> - checks that all messages are received and in the correct order
> This test is failing intermittently but quite often.

--
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

From issues at jboss.org  Mon Mar 10 12:27:11 2014
From: issues at jboss.org (Paul Ferraro (JIRA))
Date: Mon, 10 Mar 2014 12:27:11 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1720) Ensure
 HttpServletRequest.logout() does not invalidate sessions when SSO is used
In-Reply-To: <JIRA.12496844.1374181571000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12496844.1374181571000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12496844.1374181571000.2345.1394468831136@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-1720?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Paul Ferraro closed WFLY-1720.
------------------------------

    Resolution: Rejected


This is not an issue in the SSO implementation in WildFly.
                
> Ensure HttpServletRequest.logout() does not invalidate sessions when SSO is used
> --------------------------------------------------------------------------------
>
>                 Key: WFLY-1720
>                 URL: https://issues.jboss.org/browse/WFLY-1720
>             Project: WildFly
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Clustering, Web (Undertow)
>    Affects Versions: 8.0.0.Alpha3
>            Reporter: Aaron Ogburn
>            Assignee: Paul Ferraro
>
> EAP 6/JBossWeb had a bug that resulted in sessions being improperly invalidated on logout when SSO (clustered or unclustered) were used:
> https://bugzilla.redhat.com/show_bug.cgi?id=958252
> We need to ensure any new SSO offerings on Wildfly incorporated with undertow do not do the same

--
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

From issues at jboss.org  Mon Mar 10 12:53:10 2014
From: issues at jboss.org (Jesper Pedersen (JIRA))
Date: Mon, 10 Mar 2014 12:53:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBJCA-1153) Implicit enable
 validate-on-match if possible
In-Reply-To: <JIRA.12534590.1394470313024@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534590.1394470313024@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534590.1394470313024.2377.1394470390798@jira02.app.mwc.hst.phx2.redhat.com>

Jesper Pedersen created JBJCA-1153:
--------------------------------------

             Summary: Implicit enable validate-on-match if possible
                 Key: JBJCA-1153
                 URL: https://issues.jboss.org/browse/JBJCA-1153
             Project: IronJacamar
          Issue Type: Task
          Components: Common, Deployer, JDBC
            Reporter: Jesper Pedersen
            Assignee: Jesper Pedersen
             Fix For: 1.2.0.Beta1




--
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

From issues at jboss.org  Mon Mar 10 12:59:10 2014
From: issues at jboss.org (Tomaz Cerar (JIRA))
Date: Mon, 10 Mar 2014 12:59:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2532) @Transactional and
 TransactionPhase does not work
In-Reply-To: <JIRA.12525497.1384801691000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12525497.1384801691000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12525497.1384801691000.2385.1394470750625@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2532?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tomaz Cerar updated WFLY-2532:
------------------------------

    Fix Version/s: 8.0.0.CR1

    
> @Transactional and TransactionPhase does not work
> -------------------------------------------------
>
>                 Key: WFLY-2532
>                 URL: https://issues.jboss.org/browse/WFLY-2532
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: CDI / Weld, Transactions
>    Affects Versions: 8.0.0.CR1
>            Reporter: Jens Schumann
>            Assignee: Jozef Hartinger
>             Fix For: 8.0.0.CR1
>
>
> This issue is related to the current 8.0.0Beta2-SNAPSHOT, downloaded today. I have been using this snapshot because @Transactional won't work otherwise.
> If you use within an @Transactional TX an Transactional observer - e.g. @Observes(during=TransactionPhase.AFTER_COMPLETION) - it will fail with an "UserTransaction is not available within the scope of a bean or method annotated with @Transactional and a Transactional.TxType other than NOT_SUPPORTED or NEVER". Look's like an CMT access limitation issue here. Does work with Enterprise JavaBeans though.
> Full Stacktrace.
> javax.faces.el.EvaluationException: java.lang.IllegalStateException: UserTransaction is not available within the scope of a bean or method annotated with @Transactional and a Transactional.TxType other than NOT_SUPPORTED or NEVER
> 	at javax.faces.component.MethodBindingMethodExpressionAdapter.invoke(MethodBindingMethodExpressionAdapter.java:101)
> 	at com.sun.faces.application.ActionListenerImpl.processAction(ActionListenerImpl.java:102)
> 	at javax.faces.component.UICommand.broadcast(UICommand.java:315)
> 	at javax.faces.component.UIViewRoot.broadcastEvents(UIViewRoot.java:790)
> 	at javax.faces.component.UIViewRoot.processApplication(UIViewRoot.java:1282)
> 	at com.sun.faces.lifecycle.InvokeApplicationPhase.execute(InvokeApplicationPhase.java:81)
> 	at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101)
> 	at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:198)
> 	at javax.faces.webapp.FacesServlet.service(FacesServlet.java:646)
> 	at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:87)
> 	at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:130)
> 	at de.openknowledge.fullstack.jeecrm.presentation.common.NonCachingFilter.doFilter(NonCachingFilter.java:35)
> 	at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:56)
> 	at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132)
> 	at io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:85)
> 	at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:59)
> 	at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
> 	at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:81)
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25)
> 	at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:113)
> 	at io.undertow.security.handlers.AuthenticationCallHandler.handleRequest(AuthenticationCallHandler.java:52)
> 	at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45)
> 	at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:65)
> 	at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:70)
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25)
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25)
> 	at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:239)
> 	at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:226)
> 	at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:72)
> 	at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:145)
> 	at io.undertow.server.Connectors.executeRootHandler(Connectors.java:139)
> 	at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:637)
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
> 	at java.lang.Thread.run(Thread.java:722)
> Caused by: java.lang.IllegalStateException: UserTransaction is not available within the scope of a bean or method annotated with @Transactional and a Transactional.TxType other than NOT_SUPPORTED or NEVER
> 	at org.jboss.tm.usertx.client.ServerVMClientUserTransaction.testAvailability(ServerVMClientUserTransaction.java:232)
> 	at org.jboss.tm.usertx.client.ServerVMClientUserTransaction.getStatus(ServerVMClientUserTransaction.java:196)
> 	at org.jboss.as.weld.services.bootstrap.WeldTransactionServices.isTransactionActive(WeldTransactionServices.java:63)
> 	at org.jboss.weld.event.TransactionalObserverNotifier.immediateDispatch(TransactionalObserverNotifier.java:53)
> 	at org.jboss.weld.event.TransactionalObserverNotifier.notifyObserver(TransactionalObserverNotifier.java:45)
> 	at org.jboss.weld.event.ObserverNotifier.notifyObservers(ObserverNotifier.java:119)
> 	at org.jboss.weld.event.ObserverNotifier.fireEvent(ObserverNotifier.java:112)
> 	at org.jboss.weld.event.EventImpl.fire(EventImpl.java:83)
> 	at xxx.CustomerServiceBean.addCustomer(CustomerServiceBean.java:63)
> 	at xxx.CustomerServiceBean$Proxy$_$$_WeldClientProxy.addCustomer(Unknown Source)
> 	at xxx.CreateCustomerBean.addCustomer(CreateCustomerBean.java:43)
> 	at xxx.CreateCustomerBean$Proxy$_$$_WeldSubclass.addCustomer(Unknown Source)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:601)
> 	at org.jboss.weld.interceptor.proxy.SimpleInterceptionChain.interceptorChainCompleted(SimpleInterceptionChain.java:47)
> 	at org.jboss.weld.interceptor.chain.AbstractInterceptionChain.invokeNextInterceptor(AbstractInterceptionChain.java:77)
> 	at org.jboss.weld.interceptor.proxy.InterceptorInvocationContext.proceed(InterceptorInvocationContext.java:146)
> 	at com.arjuna.ats.jta.cdi.transactional.TransactionalInterceptorBase.invokeInOurTx(TransactionalInterceptorBase.java:71)
> 	at com.arjuna.ats.jta.cdi.transactional.TransactionalInterceptorRequired.intercept(TransactionalInterceptorRequired.java:52)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:601)
> 	at org.jboss.weld.interceptor.proxy.SimpleMethodInvocation.invoke(SimpleMethodInvocation.java:30)
> 	at org.jboss.weld.interceptor.chain.AbstractInterceptionChain.invokeNext(AbstractInterceptionChain.java:90)
> 	at org.jboss.weld.interceptor.chain.AbstractInterceptionChain.invokeNextInterceptor(AbstractInterceptionChain.java:75)
> 	at org.jboss.weld.interceptor.proxy.InterceptorMethodHandler.executeInterception(InterceptorMethodHandler.java:48)
> 	at org.jboss.weld.interceptor.proxy.InterceptorMethodHandler.invoke(InterceptorMethodHandler.java:41)
> 	at org.jboss.weld.bean.proxy.CombinedInterceptorAndDecoratorStackMethodHandler.invoke(CombinedInterceptorAndDecoratorStackMethodHandler.java:53)
> 	at xxxx.CreateCustomerBean$Proxy$_$$_WeldSubclass.addCustomer(Unknown Source)
> 	at xxxx.CreateCustomerBean$Proxy$_$$_WeldClientProxy.addCustomer(Unknown Source)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:601)
> 	at javax.el.ELUtil.invokeMethod(ELUtil.java:326)
> 	at javax.el.BeanELResolver.invoke(BeanELResolver.java:536)
> 	at javax.el.CompositeELResolver.invoke(CompositeELResolver.java:256)
> 	at com.sun.el.parser.AstValue.invoke(AstValue.java:269)
> 	at com.sun.el.MethodExpressionImpl.invoke(MethodExpressionImpl.java:304)
> 	at org.jboss.weld.util.el.ForwardingMethodExpression.invoke(ForwardingMethodExpression.java:40)
> 	at org.jboss.weld.el.WeldMethodExpression.invoke(WeldMethodExpression.java:50)
> 	at org.jboss.weld.util.el.ForwardingMethodExpression.invoke(ForwardingMethodExpression.java:40)
> 	at org.jboss.weld.el.WeldMethodExpression.invoke(WeldMethodExpression.java:50)
> 	at com.sun.faces.facelets.el.TagMethodExpression.invoke(TagMethodExpression.java:105)
> 	at javax.faces.component.MethodBindingMethodExpressionAdapter.invoke(MethodBindingMethodExpressionAdapter.java:87)
> 	... 34 more

--
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

From issues at jboss.org  Mon Mar 10 13:07:11 2014
From: issues at jboss.org (Jesper Pedersen (JIRA))
Date: Mon, 10 Mar 2014 13:07:11 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBJCA-1153) Implicit enable
 validate-on-match if possible
In-Reply-To: <JIRA.12534590.1394470313000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534590.1394470313000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534590.1394470313000.2424.1394471231129@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBJCA-1153?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jesper Pedersen resolved JBJCA-1153.
------------------------------------

    Resolution: Done

    
> Implicit enable validate-on-match if possible
> ---------------------------------------------
>
>                 Key: JBJCA-1153
>                 URL: https://issues.jboss.org/browse/JBJCA-1153
>             Project: IronJacamar
>          Issue Type: Task
>          Components: Common, Deployer, JDBC
>            Reporter: Jesper Pedersen
>            Assignee: Jesper Pedersen
>             Fix For: 1.2.0.Beta1
>
>


--
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

From issues at jboss.org  Mon Mar 10 13:33:10 2014
From: issues at jboss.org (Jeff Mesnil (JIRA))
Date: Mon, 10 Mar 2014 13:33:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3043) Clean up messaging subsystem
 XML configuration
In-Reply-To: <JIRA.12533611.1393595927000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12533611.1393595927000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12533611.1393595927000.2509.1394472790780@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-3043?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jeff Mesnil resolved WFLY-3043.
-------------------------------

    Fix Version/s: 8.0.1.Final
                       (was: 9.0.0.CR1)
       Resolution: Done


PR merged in master branch
                
> Clean up messaging subsystem XML configuration
> ----------------------------------------------
>
>                 Key: WFLY-3043
>                 URL: https://issues.jboss.org/browse/WFLY-3043
>             Project: WildFly
>          Issue Type: Enhancement
>      Security Level: Public(Everyone can see) 
>          Components: JMS
>    Affects Versions: 8.0.0.Final
>            Reporter: Jeff Mesnil
>            Assignee: Jeff Mesnil
>             Fix For: 8.0.1.Final
>
>
> The messaging subsystem XML configuration defines several elements whose values correspond to the management model default values.
> There is no benefit to configure the default values in the XML beside showing that the configuration exists. Now that the XSD is properly annotated, the XML configuration we ship should only define values that diverges from the default ones.

--
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

From issues at jboss.org  Mon Mar 10 14:01:12 2014
From: issues at jboss.org (Bryan Galvin (JIRA))
Date: Mon, 10 Mar 2014 14:01:12 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBASMP-58) jboss-as-maven-plugin freezes
 on authentication
In-Reply-To: <JIRA.12508946.1383048331000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508946.1383048331000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508946.1383048331000.2638.1394474472560@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JBASMP-58?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12951683#comment-12951683 ] 

Bryan Galvin commented on JBASMP-58:
------------------------------------

We are also seeing this issue.
                
> jboss-as-maven-plugin freezes on authentication
> -----------------------------------------------
>
>                 Key: JBASMP-58
>                 URL: https://issues.jboss.org/browse/JBASMP-58
>             Project: JBoss AS Maven Plugins
>          Issue Type: Bug
>          Components: deploy
>    Affects Versions: 7.5.Final
>         Environment: mac os x 10.8.5 & mac os x 10.9
> mvn 3.1.1
>            Reporter: Julien Derveeuw
>            Assignee: James Perkins
>            Priority: Critical
>
> I have jboss 7.1.1 in standalone mode running on machine A (linux).
> I want to deploy remotely to it using client machine B @ mac os X 10.8.5 / JDK 1.7.0_45-b18.
> If I connect from B to A using {{jboss-cli}}, everything works fine, I am able to login.
> If I try to deploy from maven with this :
> {code:xml}
>                 <groupId>org.jboss.as.plugins</groupId>
>                 <artifactId>jboss-as-maven-plugin</artifactId>
>                 <version>7.5.Final</version>
>                 <configuration>
>                     <hostname>${deploy.jboss.host}</hostname>
>                     <port>${deploy.jboss.port}</port>
>                     <username>${deploy.jboss.user}</username>
>                     <password>${deploy.jboss.password}</password>
>                 </configuration>
>                 <executions>
>                     <execution>
>                         <phase>install</phase>
>                         <goals>
>                             <goal>deploy</goal>
>                         </goals>
>                     </execution>
>                 </executions>
> {code}
> plugin freezes indefinitely on 
> {{Authenticating against security realm: ManagementRealm}}
> No more details are available with {{mvn -X}}
> If I remove the password or username from pom, it fails correctly with :
> {{The connection failed: Authentication failed: all available authentication mechanisms failed}}
> so it seems that the plugin somehow manages to connect to machine A.
> After digging on google, I ended up adding {{-Djava.nio.channels.spi.SelectorProvider=sun.nio.ch.KQueueSelectorProvider}} to mvn runner options because NIOs on jdk7 at macosx is said to be buggy but it didn't help.
> More details :
> {code:title=mvn 3.1.1 output|borderStyle=solid}Nov 7, 2013 10:40:09 PM org.xnio.Xnio <clinit>
> INFO: XNIO Version 3.0.3.GA
> Nov 7, 2013 10:40:09 PM org.xnio.nio.NioXnio <clinit>
> INFO: XNIO NIO Implementation Version 3.0.3.GA
> Nov 7, 2013 10:40:09 PM org.jboss.remoting3.EndpointImpl <clinit>
> INFO: JBoss Remoting version 3.2.3.GA
> Authenticating against security realm: ManagementRealm
> {code}
> {code:title=jstack 7.1.1.Final|borderStyle=solid}
> "main" prio=5 tid=7f86d6800800 nid=0x1060f0000 in Object.wait() [1060ee000]
>    java.lang.Thread.State: WAITING (on object monitor)
> 	at java.lang.Object.wait(Native Method)
> 	- waiting on <7f4102a20> (a org.jboss.as.protocol.mgmt.ActiveOperationSupport$ActiveOperationImpl)
> 	at java.lang.Object.wait(Object.java:485)
> 	at org.jboss.threads.AsyncFutureTask.await(AsyncFutureTask.java:192)
> 	- locked <7f4102a20> (a org.jboss.as.protocol.mgmt.ActiveOperationSupport$ActiveOperationImpl)
> 	at org.jboss.threads.AsyncFutureTask.get(AsyncFutureTask.java:266)
> 	- locked <7f4102a20> (a org.jboss.as.protocol.mgmt.ActiveOperationSupport$ActiveOperationImpl)
> 	at org.jboss.as.controller.client.impl.AbstractModelControllerClient$DelegatingCancellableAsyncFuture.get(AbstractModelControllerClient.java:363)
> 	at org.jboss.as.controller.client.impl.AbstractModelControllerClient$DelegatingCancellableAsyncFuture.get(AbstractModelControllerClient.java:317)
> 	at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeForResult(AbstractModelControllerClient.java:137)
> 	at org.jboss.as.controller.client.impl.AbstractModelControllerClient.execute(AbstractModelControllerClient.java:81)
> 	at org.jboss.as.plugin.deployment.standalone.StandaloneDeployment.exists(StandaloneDeployment.java:175)
> 	at org.jboss.as.plugin.deployment.standalone.StandaloneDeployment.createPlan(StandaloneDeployment.java:108)
> 	at org.jboss.as.plugin.deployment.standalone.StandaloneDeployment.execute(StandaloneDeployment.java:133)
> 	at org.jboss.as.plugin.deployment.AbstractDeployment.execute(AbstractDeployment.java:138)
> 	at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:106)
> 	at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
> 	at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
> 	at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
> 	at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
> 	at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
> 	at org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
> 	at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
> 	at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:317)
> 	at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:152)
> 	at org.apache.maven.cli.MavenCli.execute(MavenCli.java:555)
> 	at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:214)
> 	at org.apache.maven.cli.MavenCli.main(MavenCli.java:158)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
> 	at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
> 	at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
> 	at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
> {code}
> {code:title=jstack 7.5.Final|borderStyle=solid}
> "main" prio=5 tid=7fceea001000 nid=0x10d4d0000 in Object.wait() [10d4ce000]
>    java.lang.Thread.State: WAITING (on object monitor)
> 	at java.lang.Object.wait(Native Method)
> 	- waiting on <7f42f2150> (a org.jboss.as.protocol.mgmt.ActiveOperationSupport$ActiveOperationImpl)
> 	at java.lang.Object.wait(Object.java:485)
> 	at org.jboss.threads.AsyncFutureTask.await(AsyncFutureTask.java:192)
> 	- locked <7f42f2150> (a org.jboss.as.protocol.mgmt.ActiveOperationSupport$ActiveOperationImpl)
> 	at org.jboss.threads.AsyncFutureTask.get(AsyncFutureTask.java:266)
> 	- locked <7f42f2150> (a org.jboss.as.protocol.mgmt.ActiveOperationSupport$ActiveOperationImpl)
> 	at org.jboss.as.controller.client.impl.AbstractDelegatingAsyncFuture.get(AbstractDelegatingAsyncFuture.java:100)
> 	at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeForResult(AbstractModelControllerClient.java:127)
> 	at org.jboss.as.controller.client.impl.AbstractModelControllerClient.execute(AbstractModelControllerClient.java:71)
> 	at org.jboss.as.plugin.common.AbstractServerConnection.isDomainServer(AbstractServerConnection.java:234)
> 	at org.jboss.as.plugin.common.AbstractServerConnection.getClient(AbstractServerConnection.java:156)
> 	- locked <7f42f2230> (a java.lang.Object)
> 	at org.jboss.as.plugin.common.AbstractServerConnection.isDomainServer(AbstractServerConnection.java:133)
> 	- locked <7f42f2230> (a java.lang.Object)
> 	at org.jboss.as.plugin.deployment.AbstractDeployment.validate(AbstractDeployment.java:192)
> 	at org.jboss.as.plugin.deployment.AbstractDeployment.doExecute(AbstractDeployment.java:136)
> 	- locked <7f42f2230> (a java.lang.Object)
> 	at org.jboss.as.plugin.deployment.AbstractAppDeployment.doExecute(AbstractAppDeployment.java:70)
> 	at org.jboss.as.plugin.deployment.AbstractDeployment.execute(AbstractDeployment.java:111)
> 	at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:106)
> 	at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
> 	at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
> 	at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
> 	at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
> 	at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
> 	at org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
> 	at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
> 	at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:317)
> 	at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:152)
> 	at org.apache.maven.cli.MavenCli.execute(MavenCli.java:555)
> 	at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:214)
> 	at org.apache.maven.cli.MavenCli.main(MavenCli.java:158)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
> 	at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
> 	at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
> 	at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
> {code}

--
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

From issues at jboss.org  Mon Mar 10 16:23:11 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 10 Mar 2014 16:23:11 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3094) Warn if there is no resource
 bound for address-settings expiry and dead-letter addresses
In-Reply-To: <JIRA.12534528.1394450392000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534528.1394450392000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534528.1394450392000.3154.1394482991169@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-3094?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12951750#comment-12951750 ] 

RH Bugzilla Integration commented on WFLY-3094:
-----------------------------------------------

Clebert Suconic <csuconic at redhat.com> changed the Status of [bug 1014099|https://bugzilla.redhat.com/show_bug.cgi?id=1014099] from NEW to POST
                
> Warn if there is no resource bound for address-settings expiry and dead-letter addresses
> ----------------------------------------------------------------------------------------
>
>                 Key: WFLY-3094
>                 URL: https://issues.jboss.org/browse/WFLY-3094
>             Project: WildFly
>          Issue Type: Enhancement
>      Security Level: Public(Everyone can see) 
>          Components: JMS
>    Affects Versions: 8.0.0.Final
>            Reporter: Jeff Mesnil
>            Assignee: Jeff Mesnil
>             Fix For: 8.0.1.Final
>
>
> Warns the user if a address-setting has defined an expiry-address or a dead-letter-address with no queue bound for them as this will result in unintended message loss.
> WildFly default full configuration specifies an expiry address (jms.queue.ExpiryQueue) and dead-letter-addres (jms.queue.DLQ) for the # address settings (i.e. matching all addresses).
> To have a consistent configuration, we must also define 2 queues that will be bound to these settings.

--
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

From issues at jboss.org  Mon Mar 10 16:25:11 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 10 Mar 2014 16:25:11 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3094) Warn if there is no resource
 bound for address-settings expiry and dead-letter addresses
In-Reply-To: <JIRA.12534528.1394450392000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534528.1394450392000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534528.1394450392000.3174.1394483111574@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-3094?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12951752#comment-12951752 ] 

RH Bugzilla Integration commented on WFLY-3094:
-----------------------------------------------

Clebert Suconic <csuconic at redhat.com> changed the Status of [bug 1014099|https://bugzilla.redhat.com/show_bug.cgi?id=1014099] from POST to NEW
                
> Warn if there is no resource bound for address-settings expiry and dead-letter addresses
> ----------------------------------------------------------------------------------------
>
>                 Key: WFLY-3094
>                 URL: https://issues.jboss.org/browse/WFLY-3094
>             Project: WildFly
>          Issue Type: Enhancement
>      Security Level: Public(Everyone can see) 
>          Components: JMS
>    Affects Versions: 8.0.0.Final
>            Reporter: Jeff Mesnil
>            Assignee: Jeff Mesnil
>             Fix For: 8.0.1.Final
>
>
> Warns the user if a address-setting has defined an expiry-address or a dead-letter-address with no queue bound for them as this will result in unintended message loss.
> WildFly default full configuration specifies an expiry address (jms.queue.ExpiryQueue) and dead-letter-addres (jms.queue.DLQ) for the # address settings (i.e. matching all addresses).
> To have a consistent configuration, we must also define 2 queues that will be bound to these settings.

--
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

From issues at jboss.org  Mon Mar 10 16:33:10 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 10 Mar 2014 16:33:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (AS7-5768) Support resource adapter
 deployments via modules
In-Reply-To: <JIRA.12477219.1350477165000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12477219.1350477165000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12477219.1350477165000.3276.1394483590982@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/AS7-5768?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12951762#comment-12951762 ] 

RH Bugzilla Integration commented on AS7-5768:
----------------------------------------------

Van Halbert <vhalbert at redhat.com> changed the Status of [bug 868964|https://bugzilla.redhat.com/show_bug.cgi?id=868964] from VERIFIED to CLOSED
                
> Support resource adapter deployments via modules
> ------------------------------------------------
>
>                 Key: AS7-5768
>                 URL: https://issues.jboss.org/browse/AS7-5768
>             Project: Application Server 7
>          Issue Type: Task
>          Components: JCA
>            Reporter: Jesper Pedersen
>            Assignee: Stefano Maestri
>             Fix For: EAP 6.1.0.Alpha (7.2.0.Final)
>
>         Attachments: AS7-5768-example.tgz
>
>
> Add a new minor revision of the :resource-adapters: subsystem where the user has a choice of using
> {code}
> <archive>foo.rar</archive>
> {code}
> or
> {code}
> <module id="com.eis" slot="main"/>
> {code}
> where the latter contains the resource adapter in its unpacked form.

--
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

From issues at jboss.org  Mon Mar 10 16:35:10 2014
From: issues at jboss.org (Edson Tirelli (JIRA))
Date: Mon, 10 Mar 2014 16:35:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-440) Add JMX management beans for
 the Kie Scanner
In-Reply-To: <JIRA.12533201.1393299252000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12533201.1393299252000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12533201.1393299252000.3282.1394483710784@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-440?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Edson Tirelli resolved DROOLS-440.
----------------------------------

    Resolution: Done


This is done to the extent of the functionality that the underlying scanner exposes. 

To enable scanner mbeans, for now, we are using a system property: kie.scanner.mbeans = enabled .

We need to improve this in the future when we add support to a configuration framework.
                
> Add JMX management beans for the Kie Scanner
> --------------------------------------------
>
>                 Key: DROOLS-440
>                 URL: https://issues.jboss.org/browse/DROOLS-440
>             Project: Drools
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 6.1.0.Beta1
>            Reporter: Edson Tirelli
>            Assignee: Edson Tirelli
>             Fix For: 6.1.0.Beta2
>
>
> ==== from Mario ====
> Edson,
> I added some of the requested features with this commit: https://github.com/droolsjbpm/drools/commit/d90c02ee3
> In particular:
>  
> 1) list all deployed KieScanners
> I added a KieScannersRegistry so you can obtain this list by invoking KieScannersRegistry.getAllKieScanners()
>  
> 2) Display the GAV (ReleaseID) the KieScanner was created from. The V should be editable. Changing forces the KieScanner to update to the resulting effective version.
> InternalKieScanner.getScannerReleaseId()
> I don't think that allowing to change the ReleaseId would be a good idea. Actually that RelaseId doesn't belong to the KieScanner but to the KieContainer for which the KieScanner has been created. This implies that I should change it on the KieContainer and I am not sure this is correct. Moreover what happens if you set a version that actually doesn't exist on the maven repo?
>  
> 3) Display the effective GAV. i.e. if they say 1.0-SNAPSHOT for 2) this one would show which snapshot was used. Same for version ranges.
> InternalKieScanner.getCurrentReleaseId()
>  
> 4) allow ?scanNow? to be invoked.
> KieScanner.scanNow()
>  
> 5) allow the interval to be edited, including turning off.
> KieScanner.stop()
> KieScanner.start(long pollingInterval)
> Note that if you want to change the pollingInterval you have to first invoke stop and then do a restart with the new pollingInterval.
>  
> 6) Display the status, such as ?starting, updating, running? (not quite sure we can do this now)
> InternalKieScanner.getStatus() 
>  
> I am using the following Status defined in InternalKieScanner (I hope they makes sense but in case you want to change something about them let me know)
>     public enum Status {
>         STARTING, SCANNING, UPDATING, RUNNING, STOPPED;
>     }

--
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


From issues at jboss.org  Mon Mar 10 16:35:10 2014
From: issues at jboss.org (Edson Tirelli (JIRA))
Date: Mon, 10 Mar 2014 16:35:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-440) Add JMX management beans for
 the Kie Scanner
In-Reply-To: <JIRA.12533201.1393299252000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12533201.1393299252000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12533201.1393299252000.3284.1394483710867@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-440?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Edson Tirelli closed DROOLS-440.
--------------------------------


    
> Add JMX management beans for the Kie Scanner
> --------------------------------------------
>
>                 Key: DROOLS-440
>                 URL: https://issues.jboss.org/browse/DROOLS-440
>             Project: Drools
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 6.1.0.Beta1
>            Reporter: Edson Tirelli
>            Assignee: Edson Tirelli
>             Fix For: 6.1.0.Beta2
>
>
> ==== from Mario ====
> Edson,
> I added some of the requested features with this commit: https://github.com/droolsjbpm/drools/commit/d90c02ee3
> In particular:
>  
> 1) list all deployed KieScanners
> I added a KieScannersRegistry so you can obtain this list by invoking KieScannersRegistry.getAllKieScanners()
>  
> 2) Display the GAV (ReleaseID) the KieScanner was created from. The V should be editable. Changing forces the KieScanner to update to the resulting effective version.
> InternalKieScanner.getScannerReleaseId()
> I don't think that allowing to change the ReleaseId would be a good idea. Actually that RelaseId doesn't belong to the KieScanner but to the KieContainer for which the KieScanner has been created. This implies that I should change it on the KieContainer and I am not sure this is correct. Moreover what happens if you set a version that actually doesn't exist on the maven repo?
>  
> 3) Display the effective GAV. i.e. if they say 1.0-SNAPSHOT for 2) this one would show which snapshot was used. Same for version ranges.
> InternalKieScanner.getCurrentReleaseId()
>  
> 4) allow ?scanNow? to be invoked.
> KieScanner.scanNow()
>  
> 5) allow the interval to be edited, including turning off.
> KieScanner.stop()
> KieScanner.start(long pollingInterval)
> Note that if you want to change the pollingInterval you have to first invoke stop and then do a restart with the new pollingInterval.
>  
> 6) Display the status, such as ?starting, updating, running? (not quite sure we can do this now)
> InternalKieScanner.getStatus() 
>  
> I am using the following Status defined in InternalKieScanner (I hope they makes sense but in case you want to change something about them let me know)
>     public enum Status {
>         STARTING, SCANNING, UPDATING, RUNNING, STOPPED;
>     }

--
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


From issues at jboss.org  Mon Mar 10 17:49:11 2014
From: issues at jboss.org (Paul Ferraro (JIRA))
Date: Mon, 10 Mar 2014 17:49:11 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3096) Upgrade JGroups to 3.4.3.Final
In-Reply-To: <JIRA.12534613.1394488130718@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534613.1394488130718@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534613.1394488130718.3432.1394488151113@jira02.app.mwc.hst.phx2.redhat.com>

Paul Ferraro created WFLY-3096:
----------------------------------

             Summary: Upgrade JGroups to 3.4.3.Final
                 Key: WFLY-3096
                 URL: https://issues.jboss.org/browse/WFLY-3096
             Project: WildFly
          Issue Type: Component  Upgrade
      Security Level: Public (Everyone can see)
          Components: Clustering
    Affects Versions: 8.0.0.Final
            Reporter: Paul Ferraro
            Assignee: Paul Ferraro
             Fix For: 8.0.1.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

From issues at jboss.org  Mon Mar 10 18:25:10 2014
From: issues at jboss.org (TedGoddard (JIRA))
Date: Mon, 10 Mar 2014 18:25:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2533) Add ability to set default
 character encoding on a subsystem level
In-Reply-To: <JIRA.12525501.1384804327000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12525501.1384804327000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12525501.1384804327000.3475.1394490310820@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2533?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12951798#comment-12951798 ] 

TedGoddard commented on WFLY-2533:
----------------------------------

Should this setting affect decoding of unicode characters in HTTP multipart uploads (such as localized filenames obtained from javax.servlet.http.Part.getHeader("content-disposition") ?
                
> Add ability to set default character encoding on a subsystem level
> ------------------------------------------------------------------
>
>                 Key: WFLY-2533
>                 URL: https://issues.jboss.org/browse/WFLY-2533
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Web (Undertow)
>            Reporter: Stuart Douglas
>            Assignee: Tomaz Cerar
>             Fix For: 8.0.0.CR1
>
>
> Stuart: the charset one should be pretty simple, just an attribute on <servlet-container?
> Stuart: ideally we would also have it in jboss-web.xml as well
> Stuart: I should also add an option to use the connector encoding
> Stuart: as connectors have their own encoding set
> Stuart: that is used to decode the URL
> Stuart: we should have an option to use the connector encoding as the default encoding

--
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

From issues at jboss.org  Mon Mar 10 19:55:10 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 10 Mar 2014 19:55:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2899) Help and error messages in
 Main classes should be printed raw
In-Reply-To: <JIRA.12531680.1392076590000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12531680.1392076590000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12531680.1392076590000.3560.1394495710554@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2899?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12951804#comment-12951804 ] 

RH Bugzilla Integration commented on WFLY-2899:
-----------------------------------------------

James Perkins <jperkins at redhat.com> changed the Status of [bug 1072224|https://bugzilla.redhat.com/show_bug.cgi?id=1072224] from NEW to POST
                
> Help and error messages in Main classes should be printed raw
> -------------------------------------------------------------
>
>                 Key: WFLY-2899
>                 URL: https://issues.jboss.org/browse/WFLY-2899
>             Project: WildFly
>          Issue Type: Enhancement
>      Security Level: Public(Everyone can see) 
>          Components: Logging
>            Reporter: James Perkins
>            Assignee: James Perkins
>            Priority: Minor
>             Fix For: 8.0.1.Final
>
>
> The help in standalone and host-controller main methods gets printed after {{System.out}} and {{System.err}} have been captured by jboss-stdio. This leads the help and errors being printed in a log manager format rather than just the raw text.
> Example output:
> {code}
> [jperkins at jperkins-rh wildfly]$ ./build/target/wildfly-8.0.0.Final-SNAPSHOT/bin/standalone.sh -help
> =========================================================================
>   JBoss Bootstrap Environment
>   JBOSS_HOME: /home/jperkins/projects/jboss/as/wildfly/build/target/wildfly-8.0.0.Final-SNAPSHOT
>   JAVA: java
>   JAVA_OPTS:  -server -XX:+UseCompressedOops -Xms64m -Xmx512m -XX:MaxPermSize=256m -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true
> =========================================================================
> 15:31:43,895 INFO  [org.jboss.modules] (main) JBoss Modules version 1.3.0.Final
> 15:31:44,918 INFO  [stdout] (main) 
> 15:31:44,918 INFO  [stdout] (main) Usage: standalone.sh [args...]
> 15:31:44,918 INFO  [stdout] (main) where args include:
> 15:31:44,918 INFO  [stdout] (main)     --admin-only                        Set the server's running type to 
> 15:31:44,919 INFO  [stdout] (main)                                         ADMIN_ONLY causing it to open 
> 15:31:44,919 INFO  [stdout] (main)                                         administrative interfaces and accept 
> 15:31:44,919 INFO  [stdout] (main)                                         management requests but not start other 
> 15:31:44,920 INFO  [stdout] (main)                                         runtime services or accept end user 
> 15:31:44,920 INFO  [stdout] (main)                                         requests.
> 15:31:44,920 INFO  [stdout] (main) 
> 15:31:44,920 INFO  [stdout] (main) 
> 15:31:44,921 INFO  [stdout] (main)     -b <value>, -b=<value>              Set system property jboss.bind.address 
> 15:31:44,921 INFO  [stdout] (main)                                         to the given value
> 15:31:44,921 INFO  [stdout] (main) 
> 15:31:44,921 INFO  [stdout] (main) 
> 15:31:44,922 INFO  [stdout] (main)     -b<interface>=<value>               Set system property 
> 15:31:44,922 INFO  [stdout] (main)                                         jboss.bind.address.<interface> to the 
> 15:31:44,922 INFO  [stdout] (main)                                         given value
> 15:31:44,922 INFO  [stdout] (main) 
> 15:31:44,923 INFO  [stdout] (main) 
> 15:31:44,923 INFO  [stdout] (main)     -c <config>, -c=<config>            Name of the server configuration file 
> 15:31:44,923 INFO  [stdout] (main)                                         to use (default is "standalone.xml") 
> 15:31:44,923 INFO  [stdout] (main)                                         (Same as --server-config)
> 15:31:44,924 INFO  [stdout] (main) 
> 15:31:44,924 INFO  [stdout] (main) 
> 15:31:44,924 INFO  [stdout] (main)     --debug [<port>]                    Activate debug mode with an optional 
> 15:31:44,924 INFO  [stdout] (main)                                         argument to specify the port. Only 
> 15:31:44,925 INFO  [stdout] (main)                                         works if the launch script supports it.
> 15:31:44,925 INFO  [stdout] (main) 
> 15:31:44,925 INFO  [stdout] (main) 
> 15:31:44,925 INFO  [stdout] (main)     -D<name>[=<value>]                  Set a system property
> 15:31:44,926 INFO  [stdout] (main) 
> 15:31:44,926 INFO  [stdout] (main) 
> 15:31:44,926 INFO  [stdout] (main)     -h, --help                          Display this message and exit
> 15:31:44,927 INFO  [stdout] (main) 
> 15:31:44,927 INFO  [stdout] (main) 
> 15:31:44,927 INFO  [stdout] (main)     --read-only-server-config=<config>  Name of the server configuration file 
> 15:31:44,927 INFO  [stdout] (main)                                         to use. This differs from 
> 15:31:44,928 INFO  [stdout] (main)                                         '--server-config' and '-c' in that the 
> 15:31:44,928 INFO  [stdout] (main)                                         original file is never overwritten.
> 15:31:44,928 INFO  [stdout] (main) 
> 15:31:44,928 INFO  [stdout] (main) 
> 15:31:44,929 INFO  [stdout] (main)     -P <url>, -P=<url>,                 Load system properties from the given 
> 15:31:44,929 INFO  [stdout] (main)          --properties=<url>             url
> 15:31:44,929 INFO  [stdout] (main) 
> 15:31:44,929 INFO  [stdout] (main) 
> 15:31:44,930 INFO  [stdout] (main)     -S<name>[=<value>]                  Set a security property
> 15:31:44,930 INFO  [stdout] (main) 
> 15:31:44,930 INFO  [stdout] (main) 
> 15:31:44,930 INFO  [stdout] (main)     --server-config=<config>            Name of the server configuration file 
> 15:31:44,931 INFO  [stdout] (main)                                         to use (default is "standalone.xml") 
> 15:31:44,931 INFO  [stdout] (main)                                         (Same as -c)
> 15:31:44,931 INFO  [stdout] (main) 
> 15:31:44,931 INFO  [stdout] (main) 
> 15:31:44,932 INFO  [stdout] (main)     -u <value>, -u=<value>              Set system property 
> 15:31:44,932 INFO  [stdout] (main)                                         jboss.default.multicast.address to the 
> 15:31:44,932 INFO  [stdout] (main)                                         given value
> 15:31:44,933 INFO  [stdout] (main) 
> 15:31:44,933 INFO  [stdout] (main) 
> 15:31:44,933 INFO  [stdout] (main)     -v, -V, --version                   Print version and exit
> 15:31:44,934 INFO  [stdout] (main) 
> 15:31:44,934 INFO  [stdout] (main)
> {code}

--
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

From issues at jboss.org  Mon Mar 10 20:01:11 2014
From: issues at jboss.org (Davide Sottara (JIRA))
Date: Mon, 10 Mar 2014 20:01:11 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-448) Traiting non-declared POJOS
 prevents the execution of WM actions from outside the WM
In-Reply-To: <JIRA.12534616.1394496002843@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534616.1394496002843@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534616.1394496002843.3565.1394496071312@jira02.app.mwc.hst.phx2.redhat.com>

Davide Sottara created DROOLS-448:
-------------------------------------

             Summary: Traiting non-declared POJOS prevents the execution of WM actions from outside the WM
                 Key: DROOLS-448
                 URL: https://issues.jboss.org/browse/DROOLS-448
             Project: Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions: 6.1.0.Beta1, 6.0.1.Final, 6.0.0.Final, 5.6.0.Final
            Reporter: Davide Sottara
            Assignee: Mark Proctor
            Priority: Critical
             Fix For: 6.1.0.Final


When a trait is applied to non-declared bean, a transparent proxy is created and the handle is updated accordingly. However, this prevents the lookup of the handle using the original object as a key. 

The proxy creation should be avoided.

See also PLANNER-229

--
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

From issues at jboss.org  Mon Mar 10 20:01:11 2014
From: issues at jboss.org (Davide Sottara (JIRA))
Date: Mon, 10 Mar 2014 20:01:11 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-448) Traiting non-declared POJOS
 prevents the execution of WM actions from outside the WM
In-Reply-To: <JIRA.12534616.1394496002000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534616.1394496002000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534616.1394496002000.3567.1394496071434@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-448?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Davide Sottara reassigned DROOLS-448:
-------------------------------------

    Assignee: Davide Sottara  (was: Mark Proctor)

    
> Traiting non-declared POJOS prevents the execution of WM actions from outside the WM
> ------------------------------------------------------------------------------------
>
>                 Key: DROOLS-448
>                 URL: https://issues.jboss.org/browse/DROOLS-448
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.6.0.Final, 6.0.0.Final, 6.0.1.Final, 6.1.0.Beta1
>            Reporter: Davide Sottara
>            Assignee: Davide Sottara
>            Priority: Critical
>             Fix For: 6.1.0.Final
>
>
> When a trait is applied to non-declared bean, a transparent proxy is created and the handle is updated accordingly. However, this prevents the lookup of the handle using the original object as a key. 
> The proxy creation should be avoided.
> See also PLANNER-229

--
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

From issues at jboss.org  Mon Mar 10 21:49:11 2014
From: issues at jboss.org (James Livingston (JIRA))
Date: Mon, 10 Mar 2014 21:49:11 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3097) Allow user configuration of
 omitted log files
In-Reply-To: <JIRA.12534621.1394502485635@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534621.1394502485635@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534621.1394502485635.3600.1394502551112@jira02.app.mwc.hst.phx2.redhat.com>

James Livingston created WFLY-3097:
--------------------------------------

             Summary: Allow user configuration of omitted log files
                 Key: WFLY-3097
                 URL: https://issues.jboss.org/browse/WFLY-3097
             Project: WildFly
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: JDR
    Affects Versions: 8.0.0.Final
            Reporter: James Livingston
            Assignee: Jesse Jaggars


AS7Plugin gathers all *.log files and does not currently provide a way of omitting them. It would be useful to be able to provide a list that were skipped, if they contain sensitive application information.

--
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

From issues at jboss.org  Mon Mar 10 21:49:11 2014
From: issues at jboss.org (James Livingston (JIRA))
Date: Mon, 10 Mar 2014 21:49:11 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3097) Allow user configuration of
 log files for JDR to omit
In-Reply-To: <JIRA.12534621.1394502485000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534621.1394502485000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534621.1394502485000.3603.1394502551225@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-3097?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

James Livingston updated WFLY-3097:
-----------------------------------

    Summary: Allow user configuration of log files for JDR to omit  (was: Allow user configuration of omitted log files)

    
> Allow user configuration of log files for JDR to omit
> -----------------------------------------------------
>
>                 Key: WFLY-3097
>                 URL: https://issues.jboss.org/browse/WFLY-3097
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: JDR
>    Affects Versions: 8.0.0.Final
>            Reporter: James Livingston
>            Assignee: Jesse Jaggars
>
> AS7Plugin gathers all *.log files and does not currently provide a way of omitting them. It would be useful to be able to provide a list that were skipped, if they contain sensitive application information.

--
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

From issues at jboss.org  Tue Mar 11 03:59:10 2014
From: issues at jboss.org (Bela Ban (JIRA))
Date: Tue, 11 Mar 2014 03:59:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1254) Fix NoRouteToHost exception
	in UDP._send()
In-Reply-To: <JIRA.12424702.1290687438000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12424702.1290687438000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12424702.1290687438000.3888.1394524750721@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JGRP-1254?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12951820#comment-12951820 ] 

Bela Ban commented on JGRP-1254:
--------------------------------

The code for catching IOExceptions has been removed in JGRP-1765 as we're now using the DatagramSocket to send multicasts
                
> Fix NoRouteToHost exception in UDP._send()
> ------------------------------------------
>
>                 Key: JGRP-1254
>                 URL: https://issues.jboss.org/browse/JGRP-1254
>             Project: JGroups
>          Issue Type: Bug
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 2.6.18, 2.11.1, 2.12
>
>
> We did the same test with Weblogic and it is able to reconnect after a network failure.
> I had a quick look at the code of JGroups and I think that we can override this limit by a minor modification. It is not necessary to recreate a socket in case of the raise of an NoRouteToHostException, we can bind the socket to the interface. I've modified the code to catch the NoRouteToHostException and now my cluster works well and JBoss and reconnect properly.
> I've modified the _send method of UDP class like this :
> org.jgroups.protocols.UDP._send :
> private void _send(InetAddress dest, int port, boolean mcast, byte[] data, int offset, int length) throws Exception {
>         DatagramPacket packet=new DatagramPacket(data, offset, length, dest, port);
>         try {
>             if(mcast) {
>                 if(mcast_send_sockets != null) {
>                     MulticastSocket s;
>                     for(int i=0; i < mcast_send_sockets.length; i++) {
>                         s=mcast_send_sockets[i];
>                         try {
>                             s.send(packet);
>                         }
>                         // solve reconnection issue with Windows
>                         catch(NoRouteToHostException e){
>                             log.warn(e.getMessage() +", reset interface");
>                             s.setInterface(s.getInterface());
>                         }
>                         catch(Exception e) {
>                             log.error("failed sending packet on socket " + s);
>                         }
>                     }
>                 }
>                 else { // DEFAULT path
>                     if(mcast_sock != null) {
>                         try {
>                             mcast_sock.send(packet);
>                         }
>                         // solve reconnection issue with Windows
>                         catch(NoRouteToHostException e){
>                             log.warn(e.getMessage() +", reset interface");
>                             mcast_sock.setInterface(mcast_sock.getInterface());
>                         }
>                     }
>                 }
>             }
>             else {
>                 if(sock != null)
>                     sock.send(packet);
>             }
>         }
>         catch(Exception ex) {
>             throw new Exception("dest=" + dest + ":" + port + " (" + length + " bytes)", ex);
>         }
>     }

--
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

From issues at jboss.org  Tue Mar 11 04:19:10 2014
From: issues at jboss.org (Dominik Pospisil (JIRA))
Date: Tue, 11 Mar 2014 04:19:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3060) Rare KrbException: Request is
 a replay issue in negotiation tests
In-Reply-To: <JIRA.12533921.1393926730000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12533921.1393926730000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12533921.1393926730000.3905.1394525950562@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-3060?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Dominik Pospisil closed WFLY-3060.
----------------------------------

    Resolution: Done

    
> Rare KrbException: Request is a replay issue in negotiation tests
> -----------------------------------------------------------------
>
>                 Key: WFLY-3060
>                 URL: https://issues.jboss.org/browse/WFLY-3060
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite
>    Affects Versions: 8.0.0.Final
>            Reporter: Dominik Pospisil
>            Assignee: Ondrej Zizka
>
> The failures happend while sending second TGS-REQ ticket from client to kerberos KDC server.
> The cause seems to be a limitation of ApacheDS kerberos server used in the test case. The ApacheDS employs simple replay detection mechanism based on in-memory ticket cache service. The cache stores client and server credentials and ticket timestamp. Specificaly, the cache do not store ticket content.
> During GSS SecContext establishment, there are 2 TGS-REQ tickets sent from the client (sun.security.jgss.krb5.GSSContextSpi). First to acquire service credentials ticket and second to get SecContext ticket. The second ticket is being send immediatelly after the fisrt one. If the second (valid) ticket is sent with the same timestamp as the first one, the ApacheDS treats the second one as a false positive and throw Request is a replay kerberos exception.

--
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

From issues at jboss.org  Tue Mar 11 05:27:11 2014
From: issues at jboss.org (Rituraj Sinha (JIRA))
Date: Tue, 11 Mar 2014 05:27:11 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3051) http-remoting-jmx connection
 failure connecting to Undertow subsystem instead of Undertow management
In-Reply-To: <JIRA.12533723.1393825342000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12533723.1393825342000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12533723.1393825342000.4114.1394530031382@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-3051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12951843#comment-12951843 ] 

Rituraj Sinha commented on WFLY-3051:
-------------------------------------

Hi Darran,

can you give us some idea how can we proceed with it ...

Thanks
Rituraj
                
> http-remoting-jmx connection failure connecting to Undertow subsystem instead of Undertow management
> ----------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-3051
>                 URL: https://issues.jboss.org/browse/WFLY-3051
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JMX, Remoting
>    Affects Versions: 8.0.0.Final
>            Reporter: Rituraj Sinha
>            Assignee: Darran Lofthouse
>            Priority: Critical
>             Fix For: 8.0.1.Final
>
>
> i have gone through the below link for JMX subsystem for wildfly 8 as
> https://docs.jboss.org/author/display/WFLY8/JMX+subsystem+configuration
>  
> but unable to connect to server-instances running remotely ...i have posted my question there as well and pasting it here now ...
> can someone please give us the steps to configure JMX through jconsole...?
> changes done on the domain.xml are the same as stated above
> <subsystem xmlns="urn:jboss:domain:jmx:1.3">
>                 <expose-resolved-model/>
>                 <expose-expression-model/>
>                 <remoting-connector use-management-endpoint="false"/>
>             </subsystem>
> <subsystem xmlns="urn:jboss:domain:jmx:1.3">
>                 <expose-resolved-model/>
>                 <expose-expression-model/>
>                 <remoting-connector use-management-endpoint="false"/>
>             </subsystem>
> as per the jboss-as-jmx_1_3.xsd  its like
> <xs:attribute name="use-management-endpoint" type="xs:boolean" default="true" use="optional" >
>             <xs:annotation>
>                 <xs:documentation>
>                     If true then this connector will use the management endpoint, otherwise it will use the
>                     remoting subsystem endpoint.
>                 </xs:documentation>
>             </xs:annotation>
>         </xs:attribute>
> now if we are making it false then it should be using the remoting endpoint ...now remoting subsystem by default uses ApplicatoinRealm
> i have created application-user and password for the same but when i am trying to connect to remote server-instances its not connecting it....
> below is what i am able to connect to 
> service:jmx:http-remoting-jmx://remote_hostA:9990 --
> Unknown macro: {host A is where my domain_controller is running}
> how can i access the server-instances running on domain_controller
> Unknown macro: {there are three server_instanaces running on HostA with a port offset of 100 each}
> i am trying to connect with the below url as 
> service:jmx:http-remoting-jmx://lremote_hostA:8180
> let me know if something is missing from my side...
> Thanks

--
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

From issues at jboss.org  Tue Mar 11 05:39:10 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 11 Mar 2014 05:39:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3078) directory-grouping
 configuration is not getting persisted via CLI when no servers defined
In-Reply-To: <JIRA.12534347.1394159920000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534347.1394159920000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534347.1394159920000.4150.1394530750728@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-3078?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12951846#comment-12951846 ] 

RH Bugzilla Integration commented on WFLY-3078:
-----------------------------------------------

Kabir Khan <kkhan at redhat.com> changed the Status of [bug 1073715|https://bugzilla.redhat.com/show_bug.cgi?id=1073715] from POST to MODIFIED
                
> directory-grouping configuration is not getting persisted via CLI when no servers defined
> -----------------------------------------------------------------------------------------
>
>                 Key: WFLY-3078
>                 URL: https://issues.jboss.org/browse/WFLY-3078
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>    Affects Versions: 8.0.0.Final
>         Environment: All Operating System
>            Reporter: Jay Kumar SenSharma
>            Assignee: Emanuel Muckenhuber
>             Fix For: 8.0.1.Final
>
>
> - If none of the servers are defined in "host.xml" (means <servers></servers> empty tag is present) and if the user tries to run the following CLI command to change the "directory-grouping" to  "by-type"  then the value is not persisted in the configuration file (host.xml) and the <servers></servers>  tag is also removed from the host.xml
> {code}
> /host=master/:write-attribute(name=directory-grouping,value=by-type)
> {code}
> - The value of "directory-grouping" is stored "in memory" so this change does not survive the host restart.

--
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

From issues at jboss.org  Tue Mar 11 05:43:11 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 11 Mar 2014 05:43:11 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3069) slaves cannot reconnect to a
 restarted master if RBAC is enabled
In-Reply-To: <JIRA.12534143.1394020494000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534143.1394020494000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534143.1394020494000.4183.1394530991255@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-3069?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12951849#comment-12951849 ] 

RH Bugzilla Integration commented on WFLY-3069:
-----------------------------------------------

Kabir Khan <kkhan at redhat.com> changed the Status of [bug 1072915|https://bugzilla.redhat.com/show_bug.cgi?id=1072915] from POST to MODIFIED
                
> slaves cannot reconnect to a restarted master if RBAC is enabled
> ----------------------------------------------------------------
>
>                 Key: WFLY-3069
>                 URL: https://issues.jboss.org/browse/WFLY-3069
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>    Affects Versions: 8.0.0.Final
>            Reporter: Tom Fonteyne
>            Assignee: Emanuel Muckenhuber
>            Priority: Critical
>             Fix For: 8.0.1.Final
>
>
> Enable RBAC in an Wilfly domain setup. "reload --host=master" and the slaves will no longer be connected to the master

--
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

From issues at jboss.org  Tue Mar 11 06:07:11 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 11 Mar 2014 06:07:11 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-364) ClasspathKieProject fails
 vfs: path for jar deployments and exploded ear
In-Reply-To: <JIRA.12527146.1386272749000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12527146.1386272749000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12527146.1386272749000.4298.1394532431708@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/DROOLS-364?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12951859#comment-12951859 ] 

RH Bugzilla Integration commented on DROOLS-364:
------------------------------------------------

Ivo Bek <ibek at redhat.com> changed the Status of [bug 1058254|https://bugzilla.redhat.com/show_bug.cgi?id=1058254] from ON_QA to VERIFIED
                
> ClasspathKieProject fails vfs: path for jar deployments and exploded ear
> ------------------------------------------------------------------------
>
>                 Key: DROOLS-364
>                 URL: https://issues.jboss.org/browse/DROOLS-364
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 6.0.0.Final
>         Environment: JBoss AS 7.1.1
>            Reporter: Nicolas-Xavier Vanderlinden
>            Assignee: Mario Fusco
>             Fix For: 6.1.0.Beta1
>
>         Attachments: jbossas-deploy-reproducer.zip, windows-jboss-as-deploy-server.log
>
>
> Drools is not able to load kmodule.xml from an exploded ear.
> 17:24:45,116 WARN  Unable to load pom.properties tried recursing down from\Project\Geline\jboss-as-7.1.1.Final\standalone\deployments\geline.ear\service-impl-1.4.0-SNAPcontent
> null
> 17:24:45,116 ERROR Unable to build index of kmodule.xml url=vfs:/E:/Project/Geline/jboss-as-7.1.1.Final/standalone/deployments/geline.ear/service-impl-1.4.0-SNAPSHOT.jar/META-INF/kmodule.xml
> null

--
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

From issues at jboss.org  Tue Mar 11 06:15:11 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 11 Mar 2014 06:15:11 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3094) Warn if there is no resource
 bound for address-settings expiry and dead-letter addresses
In-Reply-To: <JIRA.12534528.1394450392000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534528.1394450392000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534528.1394450392000.4327.1394532911907@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-3094?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12951860#comment-12951860 ] 

RH Bugzilla Integration commented on WFLY-3094:
-----------------------------------------------

Jeff Mesnil <jmesnil at redhat.com> changed the Status of [bug 1014099|https://bugzilla.redhat.com/show_bug.cgi?id=1014099] from NEW to POST
                
> Warn if there is no resource bound for address-settings expiry and dead-letter addresses
> ----------------------------------------------------------------------------------------
>
>                 Key: WFLY-3094
>                 URL: https://issues.jboss.org/browse/WFLY-3094
>             Project: WildFly
>          Issue Type: Enhancement
>      Security Level: Public(Everyone can see) 
>          Components: JMS
>    Affects Versions: 8.0.0.Final
>            Reporter: Jeff Mesnil
>            Assignee: Jeff Mesnil
>             Fix For: 8.0.1.Final
>
>
> Warns the user if a address-setting has defined an expiry-address or a dead-letter-address with no queue bound for them as this will result in unintended message loss.
> WildFly default full configuration specifies an expiry address (jms.queue.ExpiryQueue) and dead-letter-addres (jms.queue.DLQ) for the # address settings (i.e. matching all addresses).
> To have a consistent configuration, we must also define 2 queues that will be bound to these settings.

--
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

From issues at jboss.org  Tue Mar 11 06:19:11 2014
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 11 Mar 2014 06:19:11 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3051) http-remoting-jmx connection
 failure connecting to Undertow subsystem instead of Undertow management
In-Reply-To: <JIRA.12533723.1393825342000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12533723.1393825342000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12533723.1393825342000.4363.1394533151694@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-3051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12951863#comment-12951863 ] 

Darran Lofthouse commented on WFLY-3051:
----------------------------------------

Hello [~rituraj], at this point the forum topic you have started is going to be the best place to discuss this.
                
> http-remoting-jmx connection failure connecting to Undertow subsystem instead of Undertow management
> ----------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-3051
>                 URL: https://issues.jboss.org/browse/WFLY-3051
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JMX, Remoting
>    Affects Versions: 8.0.0.Final
>            Reporter: Rituraj Sinha
>            Assignee: Darran Lofthouse
>            Priority: Critical
>             Fix For: 8.0.1.Final
>
>
> i have gone through the below link for JMX subsystem for wildfly 8 as
> https://docs.jboss.org/author/display/WFLY8/JMX+subsystem+configuration
>  
> but unable to connect to server-instances running remotely ...i have posted my question there as well and pasting it here now ...
> can someone please give us the steps to configure JMX through jconsole...?
> changes done on the domain.xml are the same as stated above
> <subsystem xmlns="urn:jboss:domain:jmx:1.3">
>                 <expose-resolved-model/>
>                 <expose-expression-model/>
>                 <remoting-connector use-management-endpoint="false"/>
>             </subsystem>
> <subsystem xmlns="urn:jboss:domain:jmx:1.3">
>                 <expose-resolved-model/>
>                 <expose-expression-model/>
>                 <remoting-connector use-management-endpoint="false"/>
>             </subsystem>
> as per the jboss-as-jmx_1_3.xsd  its like
> <xs:attribute name="use-management-endpoint" type="xs:boolean" default="true" use="optional" >
>             <xs:annotation>
>                 <xs:documentation>
>                     If true then this connector will use the management endpoint, otherwise it will use the
>                     remoting subsystem endpoint.
>                 </xs:documentation>
>             </xs:annotation>
>         </xs:attribute>
> now if we are making it false then it should be using the remoting endpoint ...now remoting subsystem by default uses ApplicatoinRealm
> i have created application-user and password for the same but when i am trying to connect to remote server-instances its not connecting it....
> below is what i am able to connect to 
> service:jmx:http-remoting-jmx://remote_hostA:9990 --
> Unknown macro: {host A is where my domain_controller is running}
> how can i access the server-instances running on domain_controller
> Unknown macro: {there are three server_instanaces running on HostA with a port offset of 100 each}
> i am trying to connect with the below url as 
> service:jmx:http-remoting-jmx://lremote_hostA:8180
> let me know if something is missing from my side...
> Thanks

--
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

From issues at jboss.org  Tue Mar 11 06:47:10 2014
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 11 Mar 2014 06:47:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3098) Complete Undertow to JAAS
 Digest Integration
In-Reply-To: <JIRA.12534643.1394534824382@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534643.1394534824382@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534643.1394534824382.4401.1394534830737@jira02.app.mwc.hst.phx2.redhat.com>

Darran Lofthouse created WFLY-3098:
--------------------------------------

             Summary: Complete Undertow to JAAS Digest Integration
                 Key: WFLY-3098
                 URL: https://issues.jboss.org/browse/WFLY-3098
             Project: WildFly
          Issue Type: Enhancement
      Security Level: Public (Everyone can see)
          Components: Security, Web (Undertow)
            Reporter: Darran Lofthouse
            Assignee: Darran Lofthouse
             Fix For: 8.0.1.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

From issues at jboss.org  Tue Mar 11 07:35:11 2014
From: issues at jboss.org (Rituraj Sinha (JIRA))
Date: Tue, 11 Mar 2014 07:35:11 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3051) http-remoting-jmx connection
 failure connecting to Undertow subsystem instead of Undertow management
In-Reply-To: <JIRA.12533723.1393825342000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12533723.1393825342000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12533723.1393825342000.4577.1394537711224@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-3051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12951889#comment-12951889 ] 

Rituraj Sinha commented on WFLY-3051:
-------------------------------------

Thanks Darran for the response ...will look forward if someone replies in the discussion ...thanks for all your help and time ...
                
> http-remoting-jmx connection failure connecting to Undertow subsystem instead of Undertow management
> ----------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-3051
>                 URL: https://issues.jboss.org/browse/WFLY-3051
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JMX, Remoting
>    Affects Versions: 8.0.0.Final
>            Reporter: Rituraj Sinha
>            Assignee: Darran Lofthouse
>            Priority: Critical
>             Fix For: 8.0.1.Final
>
>
> i have gone through the below link for JMX subsystem for wildfly 8 as
> https://docs.jboss.org/author/display/WFLY8/JMX+subsystem+configuration
>  
> but unable to connect to server-instances running remotely ...i have posted my question there as well and pasting it here now ...
> can someone please give us the steps to configure JMX through jconsole...?
> changes done on the domain.xml are the same as stated above
> <subsystem xmlns="urn:jboss:domain:jmx:1.3">
>                 <expose-resolved-model/>
>                 <expose-expression-model/>
>                 <remoting-connector use-management-endpoint="false"/>
>             </subsystem>
> <subsystem xmlns="urn:jboss:domain:jmx:1.3">
>                 <expose-resolved-model/>
>                 <expose-expression-model/>
>                 <remoting-connector use-management-endpoint="false"/>
>             </subsystem>
> as per the jboss-as-jmx_1_3.xsd  its like
> <xs:attribute name="use-management-endpoint" type="xs:boolean" default="true" use="optional" >
>             <xs:annotation>
>                 <xs:documentation>
>                     If true then this connector will use the management endpoint, otherwise it will use the
>                     remoting subsystem endpoint.
>                 </xs:documentation>
>             </xs:annotation>
>         </xs:attribute>
> now if we are making it false then it should be using the remoting endpoint ...now remoting subsystem by default uses ApplicatoinRealm
> i have created application-user and password for the same but when i am trying to connect to remote server-instances its not connecting it....
> below is what i am able to connect to 
> service:jmx:http-remoting-jmx://remote_hostA:9990 --
> Unknown macro: {host A is where my domain_controller is running}
> how can i access the server-instances running on domain_controller
> Unknown macro: {there are three server_instanaces running on HostA with a port offset of 100 each}
> i am trying to connect with the below url as 
> service:jmx:http-remoting-jmx://lremote_hostA:8180
> let me know if something is missing from my side...
> Thanks

--
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

From issues at jboss.org  Tue Mar 11 07:43:10 2014
From: issues at jboss.org (Tom Fonteyne (JIRA))
Date: Tue, 11 Mar 2014 07:43:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3099) management authorization
 throws an exception when an LDAP group contains a slash/backslash character
In-Reply-To: <JIRA.12534652.1394538171073@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534652.1394538171073@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534652.1394538171073.4616.1394538190870@jira02.app.mwc.hst.phx2.redhat.com>

Tom Fonteyne created WFLY-3099:
----------------------------------

             Summary: management authorization throws an exception when an LDAP group contains a slash/backslash character
                 Key: WFLY-3099
                 URL: https://issues.jboss.org/browse/WFLY-3099
             Project: WildFly
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Domain Management
    Affects Versions: 8.0.0.Final
            Reporter: Tom Fonteyne
            Assignee: Tom Fonteyne


management authorization throws an exception when an LDAP group contains a slash/backslash character

--
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

From issues at jboss.org  Tue Mar 11 07:55:10 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 11 Mar 2014 07:55:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3099) management authorization
 throws an exception when an LDAP group contains a slash/backslash character
In-Reply-To: <JIRA.12534652.1394538171000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534652.1394538171000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534652.1394538171000.4649.1394538910635@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-3099?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated WFLY-3099:
------------------------------------------

        Bugzilla Update: Perform
    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1074560

    
> management authorization throws an exception when an LDAP group contains a slash/backslash character
> ----------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-3099
>                 URL: https://issues.jboss.org/browse/WFLY-3099
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>    Affects Versions: 8.0.0.Final
>            Reporter: Tom Fonteyne
>            Assignee: Tom Fonteyne
>
> management authorization throws an exception when an LDAP group contains a slash/backslash character

--
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

From issues at jboss.org  Tue Mar 11 08:01:14 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 11 Mar 2014 08:01:14 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2415) Add configuration option to
 enable/disable Infinispan statistics
In-Reply-To: <JIRA.12509131.1383157408000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12509131.1383157408000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12509131.1383157408000.4665.1394539273997@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2415?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12951902#comment-12951902 ] 

RH Bugzilla Integration commented on WFLY-2415:
-----------------------------------------------

Richard Jan?k <rjanik at redhat.com> changed the Status of [bug 1025023|https://bugzilla.redhat.com/show_bug.cgi?id=1025023] from ON_QA to ASSIGNED
                
> Add configuration option to enable/disable Infinispan statistics
> ----------------------------------------------------------------
>
>                 Key: WFLY-2415
>                 URL: https://issues.jboss.org/browse/WFLY-2415
>             Project: WildFly
>          Issue Type: Enhancement
>      Security Level: Public(Everyone can see) 
>          Components: Clustering
>            Reporter: Scott Marlow
>            Assignee: Paul Ferraro
>             Fix For: 8.0.0.CR1
>
>
> When the Infinispan MBean is enabled, Infinispan statistics are enabled by default.  Could we allow Infinispan statistics to be enabled/disabled via a WF configuration setting?

--
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


From issues at jboss.org  Tue Mar 11 08:07:10 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 11 Mar 2014 08:07:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1188) allow custom-formatter
	configuration
In-Reply-To: <JIRA.12479264.1352969098000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12479264.1352969098000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12479264.1352969098000.4676.1394539630643@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12951904#comment-12951904 ] 

RH Bugzilla Integration commented on WFLY-1188:
-----------------------------------------------

Petr Kremensky <pkremens at redhat.com> changed the Status of [bug 994661|https://bugzilla.redhat.com/show_bug.cgi?id=994661] from ON_QA to VERIFIED
                
> allow custom-formatter configuration
> ------------------------------------
>
>                 Key: WFLY-1188
>                 URL: https://issues.jboss.org/browse/WFLY-1188
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Logging
>            Reporter: Aleksandar Kostadinov
>            Assignee: James Perkins
>              Labels: as7, formatting, logging
>             Fix For: 8.0.0.CR1
>
>
> Currently only *org.jboss.logmanager.formatters.PatternFormatter* is supported in JBoss AS7 configuration. It would be very useful to allow specifying a custom-formatter (e.g *java.util.logging.XMLFormatter*).
> At the moment one can specify another formatter in logging.properties but once the logging subsystem is initialized, the settings in logging.properties get overridden.
> A workaround would be to disable logging subsystem but that has drawbacks.

--
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

From issues at jboss.org  Tue Mar 11 08:31:58 2014
From: issues at jboss.org (Tomas Repel (JIRA))
Date: Tue, 11 Mar 2014 08:31:58 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBBUILD-734) The jboss-jstl-api_1.2_spec
 artifact depends on xalan artifact that is not present in Maven Central
In-Reply-To: <JIRA.12534656.1394540996228@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534656.1394540996228@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534656.1394540996228.4751.1394541118097@jira02.app.mwc.hst.phx2.redhat.com>

Tomas Repel created JBBUILD-734:
-----------------------------------

             Summary: The jboss-jstl-api_1.2_spec artifact depends on xalan artifact that is not present in Maven Central
                 Key: JBBUILD-734
                 URL: https://issues.jboss.org/browse/JBBUILD-734
             Project: JBoss Build System
          Issue Type: Bug
            Reporter: Tomas Repel
            Assignee: Paul Gier


The org.jboss.spec.javax.servlet.jstl:jboss-jstl-api_1.2_spec:1.1.0.Final depends on xalan:xalan:2.7.1.jbossorg-2 artifact, this one is not present in Maven Central.

--
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

From issues at jboss.org  Tue Mar 11 09:01:12 2014
From: issues at jboss.org (=?UTF-8?Q?Rog=C3=A9rio_Disciolli_=28JIRA=29?=)
Date: Tue, 11 Mar 2014 09:01:12 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-449) Does not download the
 artifacts with Firefox.
In-Reply-To: <JIRA.12534660.1394542779903@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534660.1394542779903@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534660.1394542779903.4887.1394542872649@jira02.app.mwc.hst.phx2.redhat.com>

Rog?rio Disciolli created DROOLS-449:
----------------------------------------

             Summary: Does not download the artifacts with Firefox. 
                 Key: DROOLS-449
                 URL: https://issues.jboss.org/browse/DROOLS-449
             Project: Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions: 6.1.0.Beta1, 6.0.1.Final
         Environment: Windows 7 Professional 64 bits
JDK 1.7.45
Firefox 25.0.1
            Reporter: Rog?rio Disciolli
            Assignee: Mark Proctor


When try download an Artifact from repository with browser Firefox nothing does.

--
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


From issues at jboss.org  Tue Mar 11 09:03:11 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 11 Mar 2014 09:03:11 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3099) management authorization
 throws an exception when an LDAP group contains a slash/backslash character
In-Reply-To: <JIRA.12534652.1394538171000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534652.1394538171000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534652.1394538171000.4906.1394542991011@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-3099?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12951932#comment-12951932 ] 

RH Bugzilla Integration commented on WFLY-3099:
-----------------------------------------------

Tom Fonteyne <tfonteyn at redhat.com> changed the Status of [bug 1074560|https://bugzilla.redhat.com/show_bug.cgi?id=1074560] from ASSIGNED to MODIFIED
                
> management authorization throws an exception when an LDAP group contains a slash/backslash character
> ----------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-3099
>                 URL: https://issues.jboss.org/browse/WFLY-3099
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>    Affects Versions: 8.0.0.Final
>            Reporter: Tom Fonteyne
>            Assignee: Tom Fonteyne
>
> management authorization throws an exception when an LDAP group contains a slash/backslash character

--
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

From issues at jboss.org  Tue Mar 11 09:07:10 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 11 Mar 2014 09:07:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3099) management authorization
 throws an exception when an LDAP group contains a slash/backslash character
In-Reply-To: <JIRA.12534652.1394538171000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534652.1394538171000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534652.1394538171000.4925.1394543230755@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-3099?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated WFLY-3099:
------------------------------------------

    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1074560, https://bugzilla.redhat.com/show_bug.cgi?id=1075082  (was: https://bugzilla.redhat.com/show_bug.cgi?id=1074560)

    
> management authorization throws an exception when an LDAP group contains a slash/backslash character
> ----------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-3099
>                 URL: https://issues.jboss.org/browse/WFLY-3099
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>    Affects Versions: 8.0.0.Final
>            Reporter: Tom Fonteyne
>            Assignee: Tom Fonteyne
>
> management authorization throws an exception when an LDAP group contains a slash/backslash character

--
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

From issues at jboss.org  Tue Mar 11 09:23:10 2014
From: issues at jboss.org (abhishek vijra (JIRA))
Date: Tue, 11 Mar 2014 09:23:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3100) ClassCastException in JSPs
 where spring-web tags and jstl tags are used
In-Reply-To: <JIRA.12534665.1394544099688@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534665.1394544099688@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534665.1394544099688.4985.1394544190790@jira02.app.mwc.hst.phx2.redhat.com>

abhishek vijra created WFLY-3100:
------------------------------------

             Summary: ClassCastException in JSPs where spring-web tags and jstl tags are used
                 Key: WFLY-3100
                 URL: https://issues.jboss.org/browse/WFLY-3100
             Project: WildFly
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: EE
    Affects Versions: 8.0.0.Final
            Reporter: abhishek vijra
            Assignee: David Lloyd


Following JSP with spring tags 

<%@ page contentType="text/html;charset=UTF-8" language="java" %>

<%@ taglib prefix="c" uri="http://java.sun.com/jstl/core" %>
<%@ taglib prefix="spring" uri="http://www.springframework.org/tags" %>

<html>
  <head><title>Simple jsp page</title></head>
  <body>
  
  <c:set var="hasError" value="${param.hasError}" />
  <c:set var="msg" value="${param.msg}" />
  
  <c:if test="${param.hasError=='true'}">
    Message: <spring:message text="${param.msg}"/>
  </c:if>
  
  </body>
</html>
breaks following error 
 ERROR [org.springframework.web.servlet.tags.MessageTag] (default task-1) org.apache.taglibs.standard.lang.jstl.ImplicitObjects cannot be cast to javax.servlet.jsp.el.ImplicitObjectELResolver$ImplicitObjects: java.lang.ClassCastException: org.apache.taglibs.standard.lang.jstl.ImplicitObjects cannot be cast to javax.servlet.jsp.el.ImplicitObjectELResolver$ImplicitObjects
	at javax.servlet.jsp.el.ImplicitObjectELResolver$ImplicitObjects.getImplicitObjects(ImplicitObjectELResolver.java:608) [jboss-jsp-api_2.3_spec-1.0.0.Final.jar:1.0.0.Final]
	at javax.servlet.jsp.el.ImplicitObjectELResolver.getValue(ImplicitObjectELResolver.java:169) [jboss-jsp-api_2.3_spec-1.0.0.Final.jar:1.0.0.Final]
	at org.apache.jasper.el.JasperELResolver.getValue(JasperELResolver.java:95) [jastow-1.0.0.Final.jar:1.0.0.Final]
	at org.apache.jasper.el.VariableResolverImpl.resolveVariable(VariableResolverImpl.java:32) [jastow-1.0.0.Final.jar:1.0.0.Final]
	at org.apache.jasper.el.ELResolverImpl.getValue(ELResolverImpl.java:78) [jastow-1.0.0.Final.jar:1.0.0.Final]
	at com.sun.el.parser.AstIdentifier.getValue(AstIdentifier.java:116) [javax.el-3.0.0.jar:3.0.0]
	at com.sun.el.parser.AstValue.getBase(AstValue.java:151) [javax.el-3.0.0.jar:3.0.0]
	at com.sun.el.parser.AstValue.getValue(AstValue.java:200) [javax.el-3.0.0.jar:3.0.0]

There are two jars (jboss-jsp-api_2.3_spec-1.0.0.Final.jar and jboss-jstl-api_1.2_spec-1.0.4.Final.jar) that are incompatible with each other due to a bug -- both are storing an object in the same place, but the objects are not compatible.

The result is that a jsp page cannot contain both JSTL and Spring tags, or it will get that error.


--
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

From issues at jboss.org  Tue Mar 11 09:25:12 2014
From: issues at jboss.org (abhishek vijra (JIRA))
Date: Tue, 11 Mar 2014 09:25:12 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3100) ClassCastException in JSPs
 where spring-web tags and jstl tags are used
In-Reply-To: <JIRA.12534665.1394544099000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534665.1394544099000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534665.1394544099000.4999.1394544312169@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-3100?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

abhishek vijra updated WFLY-3100:
---------------------------------

    Attachment: spring-fun.war

    
> ClassCastException in JSPs where spring-web tags and jstl tags are used
> -----------------------------------------------------------------------
>
>                 Key: WFLY-3100
>                 URL: https://issues.jboss.org/browse/WFLY-3100
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: EE
>    Affects Versions: 8.0.0.Final
>            Reporter: abhishek vijra
>            Assignee: David Lloyd
>              Labels: jsp, jstl
>         Attachments: spring-fun.war
>
>
> Following JSP with spring tags 
> <%@ page contentType="text/html;charset=UTF-8" language="java" %>
> <%@ taglib prefix="c" uri="http://java.sun.com/jstl/core" %>
> <%@ taglib prefix="spring" uri="http://www.springframework.org/tags" %>
> <html>
>   <head><title>Simple jsp page</title></head>
>   <body>
>   
>   <c:set var="hasError" value="${param.hasError}" />
>   <c:set var="msg" value="${param.msg}" />
>   
>   <c:if test="${param.hasError=='true'}">
>     Message: <spring:message text="${param.msg}"/>
>   </c:if>
>   
>   </body>
> </html>
> breaks following error 
>  ERROR [org.springframework.web.servlet.tags.MessageTag] (default task-1) org.apache.taglibs.standard.lang.jstl.ImplicitObjects cannot be cast to javax.servlet.jsp.el.ImplicitObjectELResolver$ImplicitObjects: java.lang.ClassCastException: org.apache.taglibs.standard.lang.jstl.ImplicitObjects cannot be cast to javax.servlet.jsp.el.ImplicitObjectELResolver$ImplicitObjects
> 	at javax.servlet.jsp.el.ImplicitObjectELResolver$ImplicitObjects.getImplicitObjects(ImplicitObjectELResolver.java:608) [jboss-jsp-api_2.3_spec-1.0.0.Final.jar:1.0.0.Final]
> 	at javax.servlet.jsp.el.ImplicitObjectELResolver.getValue(ImplicitObjectELResolver.java:169) [jboss-jsp-api_2.3_spec-1.0.0.Final.jar:1.0.0.Final]
> 	at org.apache.jasper.el.JasperELResolver.getValue(JasperELResolver.java:95) [jastow-1.0.0.Final.jar:1.0.0.Final]
> 	at org.apache.jasper.el.VariableResolverImpl.resolveVariable(VariableResolverImpl.java:32) [jastow-1.0.0.Final.jar:1.0.0.Final]
> 	at org.apache.jasper.el.ELResolverImpl.getValue(ELResolverImpl.java:78) [jastow-1.0.0.Final.jar:1.0.0.Final]
> 	at com.sun.el.parser.AstIdentifier.getValue(AstIdentifier.java:116) [javax.el-3.0.0.jar:3.0.0]
> 	at com.sun.el.parser.AstValue.getBase(AstValue.java:151) [javax.el-3.0.0.jar:3.0.0]
> 	at com.sun.el.parser.AstValue.getValue(AstValue.java:200) [javax.el-3.0.0.jar:3.0.0]
> There are two jars (jboss-jsp-api_2.3_spec-1.0.0.Final.jar and jboss-jstl-api_1.2_spec-1.0.4.Final.jar) that are incompatible with each other due to a bug -- both are storing an object in the same place, but the objects are not compatible.
> The result is that a jsp page cannot contain both JSTL and Spring tags, or it will get that error.

--
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

From issues at jboss.org  Tue Mar 11 09:29:11 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 11 Mar 2014 09:29:11 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3099) management authorization
 throws an exception when an LDAP group contains a slash/backslash character
In-Reply-To: <JIRA.12534652.1394538171000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534652.1394538171000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534652.1394538171000.5019.1394544551559@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-3099?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12951966#comment-12951966 ] 

RH Bugzilla Integration commented on WFLY-3099:
-----------------------------------------------

Tom Fonteyne <tfonteyn at redhat.com> changed the Status of [bug 1075082|https://bugzilla.redhat.com/show_bug.cgi?id=1075082] from NEW to MODIFIED
                
> management authorization throws an exception when an LDAP group contains a slash/backslash character
> ----------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-3099
>                 URL: https://issues.jboss.org/browse/WFLY-3099
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>    Affects Versions: 8.0.0.Final
>            Reporter: Tom Fonteyne
>            Assignee: Tom Fonteyne
>
> management authorization throws an exception when an LDAP group contains a slash/backslash character

--
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

From issues at jboss.org  Tue Mar 11 09:31:11 2014
From: issues at jboss.org (abhishek vijra (JIRA))
Date: Tue, 11 Mar 2014 09:31:11 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3100) ClassCastException in JSPs
 where spring-web tags and jstl tags are used
In-Reply-To: <JIRA.12534665.1394544099000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534665.1394544099000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534665.1394544099000.5072.1394544671124@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-3100?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

abhishek vijra updated WFLY-3100:
---------------------------------

    Git Pull Request: https://github.com/avijra/jboss-jsp-api_spec/commit/61428553e4958fe17298cfb16f230201a4b1816d

    
> ClassCastException in JSPs where spring-web tags and jstl tags are used
> -----------------------------------------------------------------------
>
>                 Key: WFLY-3100
>                 URL: https://issues.jboss.org/browse/WFLY-3100
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: EE
>    Affects Versions: 8.0.0.Final
>            Reporter: abhishek vijra
>            Assignee: David Lloyd
>              Labels: jsp, jstl
>         Attachments: spring-fun.war
>
>
> Following JSP with spring tags 
> <%@ page contentType="text/html;charset=UTF-8" language="java" %>
> <%@ taglib prefix="c" uri="http://java.sun.com/jstl/core" %>
> <%@ taglib prefix="spring" uri="http://www.springframework.org/tags" %>
> <html>
>   <head><title>Simple jsp page</title></head>
>   <body>
>   
>   <c:set var="hasError" value="${param.hasError}" />
>   <c:set var="msg" value="${param.msg}" />
>   
>   <c:if test="${param.hasError=='true'}">
>     Message: <spring:message text="${param.msg}"/>
>   </c:if>
>   
>   </body>
> </html>
> breaks following error 
>  ERROR [org.springframework.web.servlet.tags.MessageTag] (default task-1) org.apache.taglibs.standard.lang.jstl.ImplicitObjects cannot be cast to javax.servlet.jsp.el.ImplicitObjectELResolver$ImplicitObjects: java.lang.ClassCastException: org.apache.taglibs.standard.lang.jstl.ImplicitObjects cannot be cast to javax.servlet.jsp.el.ImplicitObjectELResolver$ImplicitObjects
> 	at javax.servlet.jsp.el.ImplicitObjectELResolver$ImplicitObjects.getImplicitObjects(ImplicitObjectELResolver.java:608) [jboss-jsp-api_2.3_spec-1.0.0.Final.jar:1.0.0.Final]
> 	at javax.servlet.jsp.el.ImplicitObjectELResolver.getValue(ImplicitObjectELResolver.java:169) [jboss-jsp-api_2.3_spec-1.0.0.Final.jar:1.0.0.Final]
> 	at org.apache.jasper.el.JasperELResolver.getValue(JasperELResolver.java:95) [jastow-1.0.0.Final.jar:1.0.0.Final]
> 	at org.apache.jasper.el.VariableResolverImpl.resolveVariable(VariableResolverImpl.java:32) [jastow-1.0.0.Final.jar:1.0.0.Final]
> 	at org.apache.jasper.el.ELResolverImpl.getValue(ELResolverImpl.java:78) [jastow-1.0.0.Final.jar:1.0.0.Final]
> 	at com.sun.el.parser.AstIdentifier.getValue(AstIdentifier.java:116) [javax.el-3.0.0.jar:3.0.0]
> 	at com.sun.el.parser.AstValue.getBase(AstValue.java:151) [javax.el-3.0.0.jar:3.0.0]
> 	at com.sun.el.parser.AstValue.getValue(AstValue.java:200) [javax.el-3.0.0.jar:3.0.0]
> There are two jars (jboss-jsp-api_2.3_spec-1.0.0.Final.jar and jboss-jstl-api_1.2_spec-1.0.4.Final.jar) that are incompatible with each other due to a bug -- both are storing an object in the same place, but the objects are not compatible.
> The result is that a jsp page cannot contain both JSTL and Spring tags, or it will get that error.

--
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

From issues at jboss.org  Tue Mar 11 09:37:10 2014
From: issues at jboss.org (Tomaz Cerar (JIRA))
Date: Tue, 11 Mar 2014 09:37:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3100) ClassCastException in JSPs
 where spring-web tags and jstl tags are used
In-Reply-To: <JIRA.12534665.1394544099000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534665.1394544099000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534665.1394544099000.5106.1394545030893@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-3100?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tomaz Cerar reassigned WFLY-3100:
---------------------------------

    Assignee: Tomaz Cerar  (was: David Lloyd)

    
> ClassCastException in JSPs where spring-web tags and jstl tags are used
> -----------------------------------------------------------------------
>
>                 Key: WFLY-3100
>                 URL: https://issues.jboss.org/browse/WFLY-3100
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: EE
>    Affects Versions: 8.0.0.Final
>            Reporter: abhishek vijra
>            Assignee: Tomaz Cerar
>              Labels: jsp, jstl
>         Attachments: spring-fun.war
>
>
> Following JSP with spring tags 
> <%@ page contentType="text/html;charset=UTF-8" language="java" %>
> <%@ taglib prefix="c" uri="http://java.sun.com/jstl/core" %>
> <%@ taglib prefix="spring" uri="http://www.springframework.org/tags" %>
> <html>
>   <head><title>Simple jsp page</title></head>
>   <body>
>   
>   <c:set var="hasError" value="${param.hasError}" />
>   <c:set var="msg" value="${param.msg}" />
>   
>   <c:if test="${param.hasError=='true'}">
>     Message: <spring:message text="${param.msg}"/>
>   </c:if>
>   
>   </body>
> </html>
> breaks following error 
>  ERROR [org.springframework.web.servlet.tags.MessageTag] (default task-1) org.apache.taglibs.standard.lang.jstl.ImplicitObjects cannot be cast to javax.servlet.jsp.el.ImplicitObjectELResolver$ImplicitObjects: java.lang.ClassCastException: org.apache.taglibs.standard.lang.jstl.ImplicitObjects cannot be cast to javax.servlet.jsp.el.ImplicitObjectELResolver$ImplicitObjects
> 	at javax.servlet.jsp.el.ImplicitObjectELResolver$ImplicitObjects.getImplicitObjects(ImplicitObjectELResolver.java:608) [jboss-jsp-api_2.3_spec-1.0.0.Final.jar:1.0.0.Final]
> 	at javax.servlet.jsp.el.ImplicitObjectELResolver.getValue(ImplicitObjectELResolver.java:169) [jboss-jsp-api_2.3_spec-1.0.0.Final.jar:1.0.0.Final]
> 	at org.apache.jasper.el.JasperELResolver.getValue(JasperELResolver.java:95) [jastow-1.0.0.Final.jar:1.0.0.Final]
> 	at org.apache.jasper.el.VariableResolverImpl.resolveVariable(VariableResolverImpl.java:32) [jastow-1.0.0.Final.jar:1.0.0.Final]
> 	at org.apache.jasper.el.ELResolverImpl.getValue(ELResolverImpl.java:78) [jastow-1.0.0.Final.jar:1.0.0.Final]
> 	at com.sun.el.parser.AstIdentifier.getValue(AstIdentifier.java:116) [javax.el-3.0.0.jar:3.0.0]
> 	at com.sun.el.parser.AstValue.getBase(AstValue.java:151) [javax.el-3.0.0.jar:3.0.0]
> 	at com.sun.el.parser.AstValue.getValue(AstValue.java:200) [javax.el-3.0.0.jar:3.0.0]
> There are two jars (jboss-jsp-api_2.3_spec-1.0.0.Final.jar and jboss-jstl-api_1.2_spec-1.0.4.Final.jar) that are incompatible with each other due to a bug -- both are storing an object in the same place, but the objects are not compatible.
> The result is that a jsp page cannot contain both JSTL and Spring tags, or it will get that error.

--
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

From issues at jboss.org  Tue Mar 11 09:37:11 2014
From: issues at jboss.org (Tomaz Cerar (JIRA))
Date: Tue, 11 Mar 2014 09:37:11 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3100) ClassCastException in JSPs
 where spring-web tags and jstl tags are used
In-Reply-To: <JIRA.12534665.1394544099000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534665.1394544099000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534665.1394544099000.5110.1394545031082@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-3100?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tomaz Cerar updated WFLY-3100:
------------------------------

    Component/s: Web (Undertow)

    
> ClassCastException in JSPs where spring-web tags and jstl tags are used
> -----------------------------------------------------------------------
>
>                 Key: WFLY-3100
>                 URL: https://issues.jboss.org/browse/WFLY-3100
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: EE, Web (Undertow)
>    Affects Versions: 8.0.0.Final
>            Reporter: abhishek vijra
>            Assignee: Tomaz Cerar
>              Labels: jsp, jstl
>         Attachments: spring-fun.war
>
>
> Following JSP with spring tags 
> <%@ page contentType="text/html;charset=UTF-8" language="java" %>
> <%@ taglib prefix="c" uri="http://java.sun.com/jstl/core" %>
> <%@ taglib prefix="spring" uri="http://www.springframework.org/tags" %>
> <html>
>   <head><title>Simple jsp page</title></head>
>   <body>
>   
>   <c:set var="hasError" value="${param.hasError}" />
>   <c:set var="msg" value="${param.msg}" />
>   
>   <c:if test="${param.hasError=='true'}">
>     Message: <spring:message text="${param.msg}"/>
>   </c:if>
>   
>   </body>
> </html>
> breaks following error 
>  ERROR [org.springframework.web.servlet.tags.MessageTag] (default task-1) org.apache.taglibs.standard.lang.jstl.ImplicitObjects cannot be cast to javax.servlet.jsp.el.ImplicitObjectELResolver$ImplicitObjects: java.lang.ClassCastException: org.apache.taglibs.standard.lang.jstl.ImplicitObjects cannot be cast to javax.servlet.jsp.el.ImplicitObjectELResolver$ImplicitObjects
> 	at javax.servlet.jsp.el.ImplicitObjectELResolver$ImplicitObjects.getImplicitObjects(ImplicitObjectELResolver.java:608) [jboss-jsp-api_2.3_spec-1.0.0.Final.jar:1.0.0.Final]
> 	at javax.servlet.jsp.el.ImplicitObjectELResolver.getValue(ImplicitObjectELResolver.java:169) [jboss-jsp-api_2.3_spec-1.0.0.Final.jar:1.0.0.Final]
> 	at org.apache.jasper.el.JasperELResolver.getValue(JasperELResolver.java:95) [jastow-1.0.0.Final.jar:1.0.0.Final]
> 	at org.apache.jasper.el.VariableResolverImpl.resolveVariable(VariableResolverImpl.java:32) [jastow-1.0.0.Final.jar:1.0.0.Final]
> 	at org.apache.jasper.el.ELResolverImpl.getValue(ELResolverImpl.java:78) [jastow-1.0.0.Final.jar:1.0.0.Final]
> 	at com.sun.el.parser.AstIdentifier.getValue(AstIdentifier.java:116) [javax.el-3.0.0.jar:3.0.0]
> 	at com.sun.el.parser.AstValue.getBase(AstValue.java:151) [javax.el-3.0.0.jar:3.0.0]
> 	at com.sun.el.parser.AstValue.getValue(AstValue.java:200) [javax.el-3.0.0.jar:3.0.0]
> There are two jars (jboss-jsp-api_2.3_spec-1.0.0.Final.jar and jboss-jstl-api_1.2_spec-1.0.4.Final.jar) that are incompatible with each other due to a bug -- both are storing an object in the same place, but the objects are not compatible.
> The result is that a jsp page cannot contain both JSTL and Spring tags, or it will get that error.

--
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

From issues at jboss.org  Tue Mar 11 09:41:10 2014
From: issues at jboss.org (Alexey Loubyansky (JIRA))
Date: Tue, 11 Mar 2014 09:41:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3101) CLI: hide stacktraces for
 exceptions w/o messages when logging errors
In-Reply-To: <JIRA.12534667.1394545185044@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534667.1394545185044@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534667.1394545185044.5120.1394545270876@jira02.app.mwc.hst.phx2.redhat.com>

Alexey Loubyansky created WFLY-3101:
---------------------------------------

             Summary: CLI: hide stacktraces for exceptions w/o messages when logging errors
                 Key: WFLY-3101
                 URL: https://issues.jboss.org/browse/WFLY-3101
             Project: WildFly
          Issue Type: Task
      Security Level: Public (Everyone can see)
          Components: CLI
    Affects Versions: 8.0.0.Final
            Reporter: Alexey Loubyansky
            Assignee: Alexey Loubyansky
             Fix For: 8.0.1.Final


CommandContextImpl contains the following logic

    public void handleSafe(String line) {
        exitCode = 0;
        try {
            handle(line);
        } catch(Throwable t) {
            final StringBuilder buf = new StringBuilder();
            buf.append(t.getLocalizedMessage());
            Throwable t1 = t.getCause();
            while(t1 != null) {
                if(t1.getLocalizedMessage() != null) {
                    buf.append(": ").append(t1.getLocalizedMessage());
                } else {
                    t1.printStackTrace();
                }
                t1 = t1.getCause();
            }
            error(buf.toString());
        }
    }

When an exception does not contain any message, e.g. in some cases IllegalArgumentException, etc, the full stacktraces are logged that are useful for debugging but not nice from the user interface point of view. It was suggested to hide them.

--
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

From issues at jboss.org  Tue Mar 11 09:43:11 2014
From: issues at jboss.org (Alexey Loubyansky (JIRA))
Date: Tue, 11 Mar 2014 09:43:11 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3101) CLI: hide stacktraces for
 exceptions w/o messages when logging errors
In-Reply-To: <JIRA.12534667.1394545185000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534667.1394545185000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534667.1394545185000.5149.1394545391969@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-3101?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Alexey Loubyansky updated WFLY-3101:
------------------------------------

    Git Pull Request: https://github.com/wildfly/wildfly/pull/6023

    
> CLI: hide stacktraces for exceptions w/o messages when logging errors
> ---------------------------------------------------------------------
>
>                 Key: WFLY-3101
>                 URL: https://issues.jboss.org/browse/WFLY-3101
>             Project: WildFly
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: CLI
>    Affects Versions: 8.0.0.Final
>            Reporter: Alexey Loubyansky
>            Assignee: Alexey Loubyansky
>             Fix For: 8.0.1.Final
>
>
> CommandContextImpl contains the following logic
>     public void handleSafe(String line) {
>         exitCode = 0;
>         try {
>             handle(line);
>         } catch(Throwable t) {
>             final StringBuilder buf = new StringBuilder();
>             buf.append(t.getLocalizedMessage());
>             Throwable t1 = t.getCause();
>             while(t1 != null) {
>                 if(t1.getLocalizedMessage() != null) {
>                     buf.append(": ").append(t1.getLocalizedMessage());
>                 } else {
>                     t1.printStackTrace();
>                 }
>                 t1 = t1.getCause();
>             }
>             error(buf.toString());
>         }
>     }
> When an exception does not contain any message, e.g. in some cases IllegalArgumentException, etc, the full stacktraces are logged that are useful for debugging but not nice from the user interface point of view. It was suggested to hide them.

--
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

From issues at jboss.org  Tue Mar 11 09:45:12 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 11 Mar 2014 09:45:12 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3101) CLI: hide stacktraces for
 exceptions w/o messages when logging errors
In-Reply-To: <JIRA.12534667.1394545185000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534667.1394545185000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534667.1394545185000.5173.1394545512108@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-3101?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated WFLY-3101:
------------------------------------------

        Bugzilla Update: Perform
    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=997584

    
> CLI: hide stacktraces for exceptions w/o messages when logging errors
> ---------------------------------------------------------------------
>
>                 Key: WFLY-3101
>                 URL: https://issues.jboss.org/browse/WFLY-3101
>             Project: WildFly
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: CLI
>    Affects Versions: 8.0.0.Final
>            Reporter: Alexey Loubyansky
>            Assignee: Alexey Loubyansky
>             Fix For: 8.0.1.Final
>
>
> CommandContextImpl contains the following logic
>     public void handleSafe(String line) {
>         exitCode = 0;
>         try {
>             handle(line);
>         } catch(Throwable t) {
>             final StringBuilder buf = new StringBuilder();
>             buf.append(t.getLocalizedMessage());
>             Throwable t1 = t.getCause();
>             while(t1 != null) {
>                 if(t1.getLocalizedMessage() != null) {
>                     buf.append(": ").append(t1.getLocalizedMessage());
>                 } else {
>                     t1.printStackTrace();
>                 }
>                 t1 = t1.getCause();
>             }
>             error(buf.toString());
>         }
>     }
> When an exception does not contain any message, e.g. in some cases IllegalArgumentException, etc, the full stacktraces are logged that are useful for debugging but not nice from the user interface point of view. It was suggested to hide them.

--
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

From issues at jboss.org  Tue Mar 11 09:49:11 2014
From: issues at jboss.org (abhishek vijra (JIRA))
Date: Tue, 11 Mar 2014 09:49:11 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3100) ClassCastException in JSPs
 where spring-web tags and jstl tags are used
In-Reply-To: <JIRA.12534665.1394544099000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534665.1394544099000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534665.1394544099000.5191.1394545751105@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-3100?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

abhishek vijra updated WFLY-3100:
---------------------------------

    Git Pull Request: https://github.com/avijra/jboss-jsp-api_spec/commit/165b497a2ea9ea8d4e5e45f289df31973e303f59  (was: https://github.com/avijra/jboss-jsp-api_spec/commit/61428553e4958fe17298cfb16f230201a4b1816d)

    
> ClassCastException in JSPs where spring-web tags and jstl tags are used
> -----------------------------------------------------------------------
>
>                 Key: WFLY-3100
>                 URL: https://issues.jboss.org/browse/WFLY-3100
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: EE, Web (Undertow)
>    Affects Versions: 8.0.0.Final
>            Reporter: abhishek vijra
>            Assignee: Tomaz Cerar
>              Labels: jsp, jstl
>         Attachments: spring-fun.war
>
>
> Following JSP with spring tags 
> <%@ page contentType="text/html;charset=UTF-8" language="java" %>
> <%@ taglib prefix="c" uri="http://java.sun.com/jstl/core" %>
> <%@ taglib prefix="spring" uri="http://www.springframework.org/tags" %>
> <html>
>   <head><title>Simple jsp page</title></head>
>   <body>
>   
>   <c:set var="hasError" value="${param.hasError}" />
>   <c:set var="msg" value="${param.msg}" />
>   
>   <c:if test="${param.hasError=='true'}">
>     Message: <spring:message text="${param.msg}"/>
>   </c:if>
>   
>   </body>
> </html>
> breaks following error 
>  ERROR [org.springframework.web.servlet.tags.MessageTag] (default task-1) org.apache.taglibs.standard.lang.jstl.ImplicitObjects cannot be cast to javax.servlet.jsp.el.ImplicitObjectELResolver$ImplicitObjects: java.lang.ClassCastException: org.apache.taglibs.standard.lang.jstl.ImplicitObjects cannot be cast to javax.servlet.jsp.el.ImplicitObjectELResolver$ImplicitObjects
> 	at javax.servlet.jsp.el.ImplicitObjectELResolver$ImplicitObjects.getImplicitObjects(ImplicitObjectELResolver.java:608) [jboss-jsp-api_2.3_spec-1.0.0.Final.jar:1.0.0.Final]
> 	at javax.servlet.jsp.el.ImplicitObjectELResolver.getValue(ImplicitObjectELResolver.java:169) [jboss-jsp-api_2.3_spec-1.0.0.Final.jar:1.0.0.Final]
> 	at org.apache.jasper.el.JasperELResolver.getValue(JasperELResolver.java:95) [jastow-1.0.0.Final.jar:1.0.0.Final]
> 	at org.apache.jasper.el.VariableResolverImpl.resolveVariable(VariableResolverImpl.java:32) [jastow-1.0.0.Final.jar:1.0.0.Final]
> 	at org.apache.jasper.el.ELResolverImpl.getValue(ELResolverImpl.java:78) [jastow-1.0.0.Final.jar:1.0.0.Final]
> 	at com.sun.el.parser.AstIdentifier.getValue(AstIdentifier.java:116) [javax.el-3.0.0.jar:3.0.0]
> 	at com.sun.el.parser.AstValue.getBase(AstValue.java:151) [javax.el-3.0.0.jar:3.0.0]
> 	at com.sun.el.parser.AstValue.getValue(AstValue.java:200) [javax.el-3.0.0.jar:3.0.0]
> There are two jars (jboss-jsp-api_2.3_spec-1.0.0.Final.jar and jboss-jstl-api_1.2_spec-1.0.4.Final.jar) that are incompatible with each other due to a bug -- both are storing an object in the same place, but the objects are not compatible.
> The result is that a jsp page cannot contain both JSTL and Spring tags, or it will get that error.

--
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

From issues at jboss.org  Tue Mar 11 10:03:11 2014
From: issues at jboss.org (Tomaz Cerar (JIRA))
Date: Tue, 11 Mar 2014 10:03:11 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3100) ClassCastException in JSPs
 where spring-web tags and jstl tags are used
In-Reply-To: <JIRA.12534665.1394544099000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534665.1394544099000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534665.1394544099000.5309.1394546591366@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-3100?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tomaz Cerar reassigned WFLY-3100:
---------------------------------

    Assignee: Remy Maucherat  (was: Tomaz Cerar)


Remy, can you verify that suggested change https://github.com/avijra/jboss-jsp-api_spec/commit/165b497a2ea9ea8d4e5e45f289df31973e303f59  is ok and wont break anything?
                
> ClassCastException in JSPs where spring-web tags and jstl tags are used
> -----------------------------------------------------------------------
>
>                 Key: WFLY-3100
>                 URL: https://issues.jboss.org/browse/WFLY-3100
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: EE, Web (Undertow)
>    Affects Versions: 8.0.0.Final
>            Reporter: abhishek vijra
>            Assignee: Remy Maucherat
>              Labels: jsp, jstl
>         Attachments: spring-fun.war
>
>
> Following JSP with spring tags 
> <%@ page contentType="text/html;charset=UTF-8" language="java" %>
> <%@ taglib prefix="c" uri="http://java.sun.com/jstl/core" %>
> <%@ taglib prefix="spring" uri="http://www.springframework.org/tags" %>
> <html>
>   <head><title>Simple jsp page</title></head>
>   <body>
>   
>   <c:set var="hasError" value="${param.hasError}" />
>   <c:set var="msg" value="${param.msg}" />
>   
>   <c:if test="${param.hasError=='true'}">
>     Message: <spring:message text="${param.msg}"/>
>   </c:if>
>   
>   </body>
> </html>
> breaks following error 
>  ERROR [org.springframework.web.servlet.tags.MessageTag] (default task-1) org.apache.taglibs.standard.lang.jstl.ImplicitObjects cannot be cast to javax.servlet.jsp.el.ImplicitObjectELResolver$ImplicitObjects: java.lang.ClassCastException: org.apache.taglibs.standard.lang.jstl.ImplicitObjects cannot be cast to javax.servlet.jsp.el.ImplicitObjectELResolver$ImplicitObjects
> 	at javax.servlet.jsp.el.ImplicitObjectELResolver$ImplicitObjects.getImplicitObjects(ImplicitObjectELResolver.java:608) [jboss-jsp-api_2.3_spec-1.0.0.Final.jar:1.0.0.Final]
> 	at javax.servlet.jsp.el.ImplicitObjectELResolver.getValue(ImplicitObjectELResolver.java:169) [jboss-jsp-api_2.3_spec-1.0.0.Final.jar:1.0.0.Final]
> 	at org.apache.jasper.el.JasperELResolver.getValue(JasperELResolver.java:95) [jastow-1.0.0.Final.jar:1.0.0.Final]
> 	at org.apache.jasper.el.VariableResolverImpl.resolveVariable(VariableResolverImpl.java:32) [jastow-1.0.0.Final.jar:1.0.0.Final]
> 	at org.apache.jasper.el.ELResolverImpl.getValue(ELResolverImpl.java:78) [jastow-1.0.0.Final.jar:1.0.0.Final]
> 	at com.sun.el.parser.AstIdentifier.getValue(AstIdentifier.java:116) [javax.el-3.0.0.jar:3.0.0]
> 	at com.sun.el.parser.AstValue.getBase(AstValue.java:151) [javax.el-3.0.0.jar:3.0.0]
> 	at com.sun.el.parser.AstValue.getValue(AstValue.java:200) [javax.el-3.0.0.jar:3.0.0]
> There are two jars (jboss-jsp-api_2.3_spec-1.0.0.Final.jar and jboss-jstl-api_1.2_spec-1.0.4.Final.jar) that are incompatible with each other due to a bug -- both are storing an object in the same place, but the objects are not compatible.
> The result is that a jsp page cannot contain both JSTL and Spring tags, or it will get that error.

--
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

From issues at jboss.org  Tue Mar 11 11:31:10 2014
From: issues at jboss.org (Aaron Ogburn (JIRA))
Date: Tue, 11 Mar 2014 11:31:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBMESSAGING-1941) Messaging deadlocks on
 AspectManager
In-Reply-To: <JIRA.12484258.1360189635000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12484258.1360189635000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12484258.1360189635000.6045.1394551870808@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBMESSAGING-1941?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Aaron Ogburn updated JBMESSAGING-1941:
--------------------------------------

    Attachment: JBMESSAGING-1941.diff

    
> Messaging deadlocks on AspectManager
> ------------------------------------
>
>                 Key: JBMESSAGING-1941
>                 URL: https://issues.jboss.org/browse/JBMESSAGING-1941
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 1.4.8.SP9
>         Environment: -JBoss Enterprise Application Platform (EAP) 5
>            Reporter: Aaron Ogburn
>         Attachments: 00779442testpatch.diff, JBMESSAGING-1941.diff
>
>
> Messaging can stall JBoss at start up.  The hang occurs as the main thread blocks in different locations in JMS trying to acquire the AspectManager instance lock:
> {noformat} 
> "main" prio=10 tid=0x00007fe69c1e1000 nid=0x3613 waiting for monitor entry [0x00007fe6828e5000]
>    java.lang.Thread.State: BLOCKED (on object monitor)
>         at org.jboss.aop.AspectManager.getAdvisor(AspectManager.java:728)
>         - waiting to lock <0x00000000a5e43e50> (a org.jboss.aop.AspectManager)
>         at org.jboss.jms.server.endpoint.advised.SessionAdvised.<clinit>(SessionAdvised.java)
>         at org.jboss.jms.server.endpoint.ServerConnectionEndpoint.createSessionDelegate(ServerConnectionEndpoint.java:273)
>         - locked <0x00000000a5600f48> (a org.jboss.aop.asintegration.jboss5.ScopedVFSClassLoaderDomain)
>         at org.jboss.jms.server.endpoint.ServerConnectionEndpoint.createSessionDelegate(ServerConnectionEndpoint.java:229)
> {noformat} 
> Since the main thread is stalled, so too is start up.  This lock is always held by another making a similar call like so:
> {noformat} 
> "WorkManager(2)-1" daemon prio=10 tid=0x00007fe62dd96000 nid=0x363e in
> Object.wait() [0x00007fe68029a000]
>    java.lang.Thread.State: RUNNABLE
>         at org.jboss.jms.server.endpoint.ServerConnectionEndpoint.createSessionDelegate(ServerConnectionEndpoint.java:273)
>         - locked <0x00000000a5e43e50> (a org.jboss.aop.AspectManager)
>         at org.jboss.jms.server.endpoint.ServerConnectionEndpoint.createSessionDelegate(ServerConnectionEndpoint.java:229)
> {noformat} 
> The code there at line 273 is simple enough and shouldn't cause a long stall:
> {code:title=org.jboss.jms.server.endpoint.ServerConnectionEndpoint.java|borderStyle=solid}
>          synchronized (AspectManager.instance())
>          {
>             advised = new SessionAdvised(ep);     // line 273
>          }
> {code}
> Nonetheless, it does clearly hang at this line as WorkManager(2)-1 never progresses.  There's no GC/CPU issues or anything of that nature, but we get a slight in the thread dump as WorkManager(2)-1 is shown to be in Object.wait().  Checking the thread through pstack, we can see the issue.  It is waiting in native/JDK level operations required to initialize the SessionAdvised class:
> {noformat}
> Thread 2 (Thread 0x7fe68029d700 (LWP 13886)):
> #0  0x0000003b3e40b43c in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
> #1  0x00007fe6a12d447e in os:latformEvent:ark() () from /opt/app/jvm/jdk1.6.0_38/jre/lib/amd64/server/libjvm.so
> #2  0x00007fe6a12c54fa in ObjectMonitor::wait(long, bool, Thread*) () from /opt/app/jvm/jdk1.6.0_38/jre/lib/amd64/server/libjvm.so
> #3  0x00007fe6a13ab5f0 in ObjectSynchronizer::waitUninterruptibly(Handle, long, Thread*) () from /opt/app/jvm/jdk1.6.0_38/jre/lib/amd64/server/libjvm.so
> #4  0x00007fe6a107115b in instanceKlass::initialize_impl(instanceKlassHandle, Thread*) () from /opt/app/jvm/jdk1.6.0_38/jre/lib/amd64/server/libjvm.so
> #5  0x00007fe6a107077a in instanceKlass::initialize(Thread*) () from /opt/app/jvm/jdk1.6.0_38/jre/lib/amd64/server/libjvm.so
> #6  0x00007fe6a1097c5c in InterpreterRuntime::_new(JavaThread*, constantPoolOopDesc*, int) () from /opt/app/jvm/jdk1.6.0_38/jre/lib/amd64/server/libjvm.so
> {noformat}
> These calls are naturally synchronized internally in the JVM so only one thread can proceed through initialization of a class at a given time.  Checking for any threads in process of initializing SessionAdvised, we can see only the main thread is.  But the main thread is still blocked for the AspectManager lock.
> So we have a deadlock here.  The main thread holds the initialization lock while waiting for the AspectManager lock, while the WorkManager(2)-1 thread holds the AspectManager lock while waiting for the initialization lock.
> The initialization of SessionAdvised is wrapped in the synchronized block so the main thread should not have been able to proceed into the initialization at all without already possessing the AspectManager lock.  It locks the ScopedVFSClassLoaderDomain, which extends the AspectManager.  This is different from the actual AspectManager though that main tries to lock in the clinit call and that it deadlocks on.

--
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

From issues at jboss.org  Tue Mar 11 11:31:11 2014
From: issues at jboss.org (Aaron Ogburn (JIRA))
Date: Tue, 11 Mar 2014 11:31:11 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBMESSAGING-1941) Messaging deadlocks on
 AspectManager
In-Reply-To: <JIRA.12484258.1360189635000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12484258.1360189635000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12484258.1360189635000.6054.1394551871252@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JBMESSAGING-1941?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12952026#comment-12952026 ] 

Aaron Ogburn commented on JBMESSAGING-1941:
-------------------------------------------

I couldn't commit to Branch_1_4.  I attached a diff of the fix that can be applied to it though.  I'll reach out to Howard.

Thanks,
Aaron
                
> Messaging deadlocks on AspectManager
> ------------------------------------
>
>                 Key: JBMESSAGING-1941
>                 URL: https://issues.jboss.org/browse/JBMESSAGING-1941
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 1.4.8.SP9
>         Environment: -JBoss Enterprise Application Platform (EAP) 5
>            Reporter: Aaron Ogburn
>         Attachments: 00779442testpatch.diff, JBMESSAGING-1941.diff
>
>
> Messaging can stall JBoss at start up.  The hang occurs as the main thread blocks in different locations in JMS trying to acquire the AspectManager instance lock:
> {noformat} 
> "main" prio=10 tid=0x00007fe69c1e1000 nid=0x3613 waiting for monitor entry [0x00007fe6828e5000]
>    java.lang.Thread.State: BLOCKED (on object monitor)
>         at org.jboss.aop.AspectManager.getAdvisor(AspectManager.java:728)
>         - waiting to lock <0x00000000a5e43e50> (a org.jboss.aop.AspectManager)
>         at org.jboss.jms.server.endpoint.advised.SessionAdvised.<clinit>(SessionAdvised.java)
>         at org.jboss.jms.server.endpoint.ServerConnectionEndpoint.createSessionDelegate(ServerConnectionEndpoint.java:273)
>         - locked <0x00000000a5600f48> (a org.jboss.aop.asintegration.jboss5.ScopedVFSClassLoaderDomain)
>         at org.jboss.jms.server.endpoint.ServerConnectionEndpoint.createSessionDelegate(ServerConnectionEndpoint.java:229)
> {noformat} 
> Since the main thread is stalled, so too is start up.  This lock is always held by another making a similar call like so:
> {noformat} 
> "WorkManager(2)-1" daemon prio=10 tid=0x00007fe62dd96000 nid=0x363e in
> Object.wait() [0x00007fe68029a000]
>    java.lang.Thread.State: RUNNABLE
>         at org.jboss.jms.server.endpoint.ServerConnectionEndpoint.createSessionDelegate(ServerConnectionEndpoint.java:273)
>         - locked <0x00000000a5e43e50> (a org.jboss.aop.AspectManager)
>         at org.jboss.jms.server.endpoint.ServerConnectionEndpoint.createSessionDelegate(ServerConnectionEndpoint.java:229)
> {noformat} 
> The code there at line 273 is simple enough and shouldn't cause a long stall:
> {code:title=org.jboss.jms.server.endpoint.ServerConnectionEndpoint.java|borderStyle=solid}
>          synchronized (AspectManager.instance())
>          {
>             advised = new SessionAdvised(ep);     // line 273
>          }
> {code}
> Nonetheless, it does clearly hang at this line as WorkManager(2)-1 never progresses.  There's no GC/CPU issues or anything of that nature, but we get a slight in the thread dump as WorkManager(2)-1 is shown to be in Object.wait().  Checking the thread through pstack, we can see the issue.  It is waiting in native/JDK level operations required to initialize the SessionAdvised class:
> {noformat}
> Thread 2 (Thread 0x7fe68029d700 (LWP 13886)):
> #0  0x0000003b3e40b43c in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
> #1  0x00007fe6a12d447e in os:latformEvent:ark() () from /opt/app/jvm/jdk1.6.0_38/jre/lib/amd64/server/libjvm.so
> #2  0x00007fe6a12c54fa in ObjectMonitor::wait(long, bool, Thread*) () from /opt/app/jvm/jdk1.6.0_38/jre/lib/amd64/server/libjvm.so
> #3  0x00007fe6a13ab5f0 in ObjectSynchronizer::waitUninterruptibly(Handle, long, Thread*) () from /opt/app/jvm/jdk1.6.0_38/jre/lib/amd64/server/libjvm.so
> #4  0x00007fe6a107115b in instanceKlass::initialize_impl(instanceKlassHandle, Thread*) () from /opt/app/jvm/jdk1.6.0_38/jre/lib/amd64/server/libjvm.so
> #5  0x00007fe6a107077a in instanceKlass::initialize(Thread*) () from /opt/app/jvm/jdk1.6.0_38/jre/lib/amd64/server/libjvm.so
> #6  0x00007fe6a1097c5c in InterpreterRuntime::_new(JavaThread*, constantPoolOopDesc*, int) () from /opt/app/jvm/jdk1.6.0_38/jre/lib/amd64/server/libjvm.so
> {noformat}
> These calls are naturally synchronized internally in the JVM so only one thread can proceed through initialization of a class at a given time.  Checking for any threads in process of initializing SessionAdvised, we can see only the main thread is.  But the main thread is still blocked for the AspectManager lock.
> So we have a deadlock here.  The main thread holds the initialization lock while waiting for the AspectManager lock, while the WorkManager(2)-1 thread holds the AspectManager lock while waiting for the initialization lock.
> The initialization of SessionAdvised is wrapped in the synchronized block so the main thread should not have been able to proceed into the initialization at all without already possessing the AspectManager lock.  It locks the ScopedVFSClassLoaderDomain, which extends the AspectManager.  This is different from the actual AspectManager though that main tries to lock in the clinit call and that it deadlocks on.

--
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

From issues at jboss.org  Tue Mar 11 11:53:11 2014
From: issues at jboss.org (Paul Gier (JIRA))
Date: Tue, 11 Mar 2014 11:53:11 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBEE-150) The jboss-jstl-api_1.2_spec
 artifact depends on xalan artifact that is not present in Maven Central
In-Reply-To: <JIRA.12534656.1394540996000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534656.1394540996000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534656.1394540996000.6154.1394553191409@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBEE-150?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Paul Gier moved JBBUILD-734 to JBEE-150:
----------------------------------------

    Project: JBoss JavaEE Spec APIs  (was: JBoss Build System)
        Key: JBEE-150  (was: JBBUILD-734)

    
> The jboss-jstl-api_1.2_spec artifact depends on xalan artifact that is not present in Maven Central
> ---------------------------------------------------------------------------------------------------
>
>                 Key: JBEE-150
>                 URL: https://issues.jboss.org/browse/JBEE-150
>             Project: JBoss JavaEE Spec APIs
>          Issue Type: Bug
>            Reporter: Tomas Repel
>            Assignee: Paul Gier
>
> The org.jboss.spec.javax.servlet.jstl:jboss-jstl-api_1.2_spec:1.1.0.Final depends on xalan:xalan:2.7.1.jbossorg-2 artifact, this one is not present in Maven Central.

--
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

From issues at jboss.org  Tue Mar 11 11:53:11 2014
From: issues at jboss.org (Paul Gier (JIRA))
Date: Tue, 11 Mar 2014 11:53:11 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBEE-150) The jboss-jstl-api_1.2_spec
 artifact depends on xalan artifact that is not present in Maven Central
In-Reply-To: <JIRA.12534656.1394540996000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534656.1394540996000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534656.1394540996000.6159.1394553191674@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBEE-150?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Paul Gier updated JBEE-150:
---------------------------

    Assignee: Shelly McGowan  (was: Paul Gier)

    
> The jboss-jstl-api_1.2_spec artifact depends on xalan artifact that is not present in Maven Central
> ---------------------------------------------------------------------------------------------------
>
>                 Key: JBEE-150
>                 URL: https://issues.jboss.org/browse/JBEE-150
>             Project: JBoss JavaEE Spec APIs
>          Issue Type: Bug
>            Reporter: Tomas Repel
>            Assignee: Shelly McGowan
>
> The org.jboss.spec.javax.servlet.jstl:jboss-jstl-api_1.2_spec:1.1.0.Final depends on xalan:xalan:2.7.1.jbossorg-2 artifact, this one is not present in Maven Central.

--
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

From issues at jboss.org  Tue Mar 11 12:17:10 2014
From: issues at jboss.org (Rich DiCroce (JIRA))
Date: Tue, 11 Mar 2014 12:17:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JASSIST-218) Class referenced in generic
 method parameter not listed in getRefClasses()
In-Reply-To: <JIRA.12534700.1394554561967@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534700.1394554561967@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534700.1394554561967.6229.1394554630600@jira02.app.mwc.hst.phx2.redhat.com>

Rich DiCroce created JASSIST-218:
------------------------------------

             Summary: Class referenced in generic method parameter not listed in getRefClasses()
                 Key: JASSIST-218
                 URL: https://issues.jboss.org/browse/JASSIST-218
             Project: Javassist
          Issue Type: Bug
    Affects Versions: 3.18.1-GA
            Reporter: Rich DiCroce
            Assignee: Shigeru Chiba


Consider the following class, assuming that SomeEnum is an Enum in the same package:
{code}
package test;

import java.util.Map;

import javassist.ClassPool;

public class Test {

	public static void main(String[] args) throws Exception {
		for (Object clazz : ClassPool.getDefault().get(Test.class.getName()).getRefClasses()) {
			System.out.println(clazz);
		}
	}
	
	public void foo(Map<SomeEnum, String> someParam) {
		
	}
	
}
{code}

SomeEnum will not be listed in the console output, despite the fact that the method foo references it as a generic parameter to Map for someParam.

--
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

From issues at jboss.org  Tue Mar 11 12:36:01 2014
From: issues at jboss.org (Richard Achmatowicz (JIRA))
Date: Tue, 11 Mar 2014 12:36:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1797) NakackTest
 testReceptionOfAllMessages fails to receive all messages
In-Reply-To: <JIRA.12533037.1393192228000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12533037.1393192228000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12533037.1393192228000.6297.1394555761793@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JGRP-1797?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12952058#comment-12952058 ] 

Richard Achmatowicz commented on JGRP-1797:
-------------------------------------------

I reproduced this error on my local machine by artificially bumping up the number of messages sent from 1000 to 3000 while keeping the wait timeout the same. With some additional debugging thrown in, I get results like this:

{noformat}
log4j:WARN No appenders could be found for logger (org.jgroups.conf.ClassConfigurator).
log4j:WARN Please initialize the log4j system properly.
C: received msg #1500 from C
A: received msg #1500 from C
B: received msg #1500 from C
B: received msg #1500 from B
C: received msg #1500 from B
A: received msg #1500 from B
C: received msg #3000 from C
Channel C: all messages sent in 718 ms
A: received msg #3000 from C
B: received msg #3000 from C
Channel B: all messages sent in 758 ms
B: received msg #3000 from B
A: received msg #3000 from B
C: received msg #3000 from B
java.lang.AssertionError: Incorrect number of messages received by the receiver thread: A: 5950 messages,B: 5886 messages,C: 5994 messages 
Expected :true
Actual   :false
{noformat}

This indicated that there may be some possible interference in updating the message counts in the receivers. Changing the receiver method to synchronized fixes the problem.
                
> NakackTest testReceptionOfAllMessages fails to receive all messages
> -------------------------------------------------------------------
>
>                 Key: JGRP-1797
>                 URL: https://issues.jboss.org/browse/JGRP-1797
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.2.13
>         Environment: RHEL (5/24), Solaris (6/24), HPUX (1/2) where x/y means x failures over y test executions.
>            Reporter: Richard Achmatowicz
>            Assignee: Bela Ban
>             Fix For: 3.2.13
>
>         Attachments: stdout.txt
>
>
> This test does the following:
> - involves channels A, B, and C where only B and C are senders and all are receivers
> - B and C send 1000 multicast messages
> - checks that all messages are received and in the correct order
> This test is failing intermittently but quite often.

--
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

From issues at jboss.org  Tue Mar 11 12:43:11 2014
From: issues at jboss.org (Richard Achmatowicz (JIRA))
Date: Tue, 11 Mar 2014 12:43:11 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1797) NakackTest
 testReceptionOfAllMessages fails to receive all messages
In-Reply-To: <JIRA.12533037.1393192228000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12533037.1393192228000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12533037.1393192228000.6331.1394556191189@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JGRP-1797?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12952060#comment-12952060 ] 

Richard Achmatowicz commented on JGRP-1797:
-------------------------------------------

I guess even though messages are delivered in order, once they start processing of the receive() method, they can get context switched out of order by other later threads. 
 
                
> NakackTest testReceptionOfAllMessages fails to receive all messages
> -------------------------------------------------------------------
>
>                 Key: JGRP-1797
>                 URL: https://issues.jboss.org/browse/JGRP-1797
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.2.13
>         Environment: RHEL (5/24), Solaris (6/24), HPUX (1/2) where x/y means x failures over y test executions.
>            Reporter: Richard Achmatowicz
>            Assignee: Bela Ban
>             Fix For: 3.2.13
>
>         Attachments: stdout.txt
>
>
> This test does the following:
> - involves channels A, B, and C where only B and C are senders and all are receivers
> - B and C send 1000 multicast messages
> - checks that all messages are received and in the correct order
> This test is failing intermittently but quite often.

--
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

From issues at jboss.org  Tue Mar 11 12:53:10 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 11 Mar 2014 12:53:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3094) Warn if there is no resource
 bound for address-settings expiry and dead-letter addresses
In-Reply-To: <JIRA.12534528.1394450392000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534528.1394450392000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534528.1394450392000.6412.1394556790545@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-3094?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12952066#comment-12952066 ] 

RH Bugzilla Integration commented on WFLY-3094:
-----------------------------------------------

Kabir Khan <kkhan at redhat.com> changed the Status of [bug 1014099|https://bugzilla.redhat.com/show_bug.cgi?id=1014099] from POST to MODIFIED
                
> Warn if there is no resource bound for address-settings expiry and dead-letter addresses
> ----------------------------------------------------------------------------------------
>
>                 Key: WFLY-3094
>                 URL: https://issues.jboss.org/browse/WFLY-3094
>             Project: WildFly
>          Issue Type: Enhancement
>      Security Level: Public(Everyone can see) 
>          Components: JMS
>    Affects Versions: 8.0.0.Final
>            Reporter: Jeff Mesnil
>            Assignee: Jeff Mesnil
>             Fix For: 8.0.1.Final
>
>
> Warns the user if a address-setting has defined an expiry-address or a dead-letter-address with no queue bound for them as this will result in unintended message loss.
> WildFly default full configuration specifies an expiry address (jms.queue.ExpiryQueue) and dead-letter-addres (jms.queue.DLQ) for the # address settings (i.e. matching all addresses).
> To have a consistent configuration, we must also define 2 queues that will be bound to these settings.

--
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

From issues at jboss.org  Tue Mar 11 13:01:11 2014
From: issues at jboss.org (Maxime Falaize (JIRA))
Date: Tue, 11 Mar 2014 13:01:11 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-450) Cannot use decimal
 formatters for integers in an excel decision table
In-Reply-To: <JIRA.12534705.1394557254855@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534705.1394557254855@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534705.1394557254855.6463.1394557271517@jira02.app.mwc.hst.phx2.redhat.com>

Maxime Falaize created DROOLS-450:
-------------------------------------

             Summary: Cannot use decimal formatters for integers in an excel decision table
                 Key: DROOLS-450
                 URL: https://issues.jboss.org/browse/DROOLS-450
             Project: Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions: 6.0.1.Final
            Reporter: Maxime Falaize
            Assignee: Mark Proctor
            Priority: Minor


When I use decimal formatter in an excel action column for numbers that are in fact integers, I am getting this exception :

{noformat}
Exception in thread "main" java.lang.RuntimeException: Error while creating KieBase[Message [id=1, level=ERROR, path=com/sample/my_decision_table.xls, line=5, column=0
   text=Rule Compilation error The method setParameter(double) in the type MyObject is not applicable for the arguments (int, int)]]
	at org.drools.compiler.kie.builder.impl.KieContainerImpl.getKieBase(KieContainerImpl.java:260)
	at org.drools.compiler.kie.builder.impl.KieContainerImpl.newKieSession(KieContainerImpl.java:400)
	at org.drools.compiler.kie.builder.impl.KieContainerImpl.newKieSession(KieContainerImpl.java:375)
{noformat}

This is causing by the line 174 in org.drools.decisiontable.parser.xls.ExcelParser :

{code:java}
if ( num - Math.round( num ) != 0 )
{code}

The end users should have the possibility to keep the same formatter for the same column, with integers or not.

--
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

From issues at jboss.org  Tue Mar 11 13:03:10 2014
From: issues at jboss.org (Maxime Falaize (JIRA))
Date: Tue, 11 Mar 2014 13:03:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-450) Cannot use decimal
 formatters for integers in an excel decision table
In-Reply-To: <JIRA.12534705.1394557254000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534705.1394557254000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534705.1394557254000.6466.1394557390745@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-450?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Maxime Falaize updated DROOLS-450:
----------------------------------

    Attachment: issue_example.png


The picture of my column
                
> Cannot use decimal formatters for integers in an excel decision table
> ---------------------------------------------------------------------
>
>                 Key: DROOLS-450
>                 URL: https://issues.jboss.org/browse/DROOLS-450
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 6.0.1.Final
>            Reporter: Maxime Falaize
>            Assignee: Mark Proctor
>            Priority: Minor
>         Attachments: issue_example.png
>
>
> When I use decimal formatter in an excel action column for numbers that are in fact integers, I am getting this exception :
> {noformat}
> Exception in thread "main" java.lang.RuntimeException: Error while creating KieBase[Message [id=1, level=ERROR, path=com/sample/my_decision_table.xls, line=5, column=0
>    text=Rule Compilation error The method setParameter(double) in the type MyObject is not applicable for the arguments (int, int)]]
> 	at org.drools.compiler.kie.builder.impl.KieContainerImpl.getKieBase(KieContainerImpl.java:260)
> 	at org.drools.compiler.kie.builder.impl.KieContainerImpl.newKieSession(KieContainerImpl.java:400)
> 	at org.drools.compiler.kie.builder.impl.KieContainerImpl.newKieSession(KieContainerImpl.java:375)
> {noformat}
> This is causing by the line 174 in org.drools.decisiontable.parser.xls.ExcelParser :
> {code:java}
> if ( num - Math.round( num ) != 0 )
> {code}
> The end users should have the possibility to keep the same formatter for the same column, with integers or not.

--
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

From issues at jboss.org  Tue Mar 11 13:07:11 2014
From: issues at jboss.org (Maxime Falaize (JIRA))
Date: Tue, 11 Mar 2014 13:07:11 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-450) Cannot use decimal
 formatters for integers in an excel decision table
In-Reply-To: <JIRA.12534705.1394557254000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534705.1394557254000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534705.1394557254000.6481.1394557631269@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-450?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Maxime Falaize updated DROOLS-450:
----------------------------------

    Description: 
When I use decimal formatter in an excel action column for numbers that are in fact integers, I am getting this exception :

{noformat}
Exception in thread "main" java.lang.RuntimeException: Error while creating KieBase[Message [id=1, level=ERROR, path=com/sample/my_decision_table.xls, line=5, column=0
   text=Rule Compilation error The method setParameter(double) in the type MyObject is not applicable for the arguments (int, int)]]
	at org.drools.compiler.kie.builder.impl.KieContainerImpl.getKieBase(KieContainerImpl.java:260)
	at org.drools.compiler.kie.builder.impl.KieContainerImpl.newKieSession(KieContainerImpl.java:400)
	at org.drools.compiler.kie.builder.impl.KieContainerImpl.newKieSession(KieContainerImpl.java:375)
{noformat}

Actually, the system uses the format number "1,00000" (with comma in french) instead of "1.00000" like it should use.

This is causing by the line 174 in org.drools.decisiontable.parser.xls.ExcelParser :

{code:java}
if ( num - Math.round( num ) != 0 )
{code}

The end users should have the possibility to keep the same formatter for the same column, with integers or not.

  was:
When I use decimal formatter in an excel action column for numbers that are in fact integers, I am getting this exception :

{noformat}
Exception in thread "main" java.lang.RuntimeException: Error while creating KieBase[Message [id=1, level=ERROR, path=com/sample/my_decision_table.xls, line=5, column=0
   text=Rule Compilation error The method setParameter(double) in the type MyObject is not applicable for the arguments (int, int)]]
	at org.drools.compiler.kie.builder.impl.KieContainerImpl.getKieBase(KieContainerImpl.java:260)
	at org.drools.compiler.kie.builder.impl.KieContainerImpl.newKieSession(KieContainerImpl.java:400)
	at org.drools.compiler.kie.builder.impl.KieContainerImpl.newKieSession(KieContainerImpl.java:375)
{noformat}

This is causing by the line 174 in org.drools.decisiontable.parser.xls.ExcelParser :

{code:java}
if ( num - Math.round( num ) != 0 )
{code}

The end users should have the possibility to keep the same formatter for the same column, with integers or not.


    
> Cannot use decimal formatters for integers in an excel decision table
> ---------------------------------------------------------------------
>
>                 Key: DROOLS-450
>                 URL: https://issues.jboss.org/browse/DROOLS-450
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 6.0.1.Final
>            Reporter: Maxime Falaize
>            Assignee: Mark Proctor
>            Priority: Minor
>         Attachments: issue_example.png
>
>
> When I use decimal formatter in an excel action column for numbers that are in fact integers, I am getting this exception :
> {noformat}
> Exception in thread "main" java.lang.RuntimeException: Error while creating KieBase[Message [id=1, level=ERROR, path=com/sample/my_decision_table.xls, line=5, column=0
>    text=Rule Compilation error The method setParameter(double) in the type MyObject is not applicable for the arguments (int, int)]]
> 	at org.drools.compiler.kie.builder.impl.KieContainerImpl.getKieBase(KieContainerImpl.java:260)
> 	at org.drools.compiler.kie.builder.impl.KieContainerImpl.newKieSession(KieContainerImpl.java:400)
> 	at org.drools.compiler.kie.builder.impl.KieContainerImpl.newKieSession(KieContainerImpl.java:375)
> {noformat}
> Actually, the system uses the format number "1,00000" (with comma in french) instead of "1.00000" like it should use.
> This is causing by the line 174 in org.drools.decisiontable.parser.xls.ExcelParser :
> {code:java}
> if ( num - Math.round( num ) != 0 )
> {code}
> The end users should have the possibility to keep the same formatter for the same column, with integers or not.

--
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

From issues at jboss.org  Tue Mar 11 13:13:10 2014
From: issues at jboss.org (Maxime Falaize (JIRA))
Date: Tue, 11 Mar 2014 13:13:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-450) Cannot use decimal
 formatters for integers in an excel decision table
In-Reply-To: <JIRA.12534705.1394557254000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534705.1394557254000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534705.1394557254000.6518.1394557990701@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-450?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Maxime Falaize updated DROOLS-450:
----------------------------------

    Description: 
When I use decimal formatter in an excel action column for numbers that are in fact integers, I am getting this exception :

{noformat}
Exception in thread "main" java.lang.RuntimeException: Error while creating KieBase[Message [id=1, level=ERROR, path=com/sample/my_decision_table.xls, line=5, column=0
   text=Rule Compilation error The method setParameter(double) in the type MyObject is not applicable for the arguments (int, int)]]
	at org.drools.compiler.kie.builder.impl.KieContainerImpl.getKieBase(KieContainerImpl.java:260)
	at org.drools.compiler.kie.builder.impl.KieContainerImpl.newKieSession(KieContainerImpl.java:400)
	at org.drools.compiler.kie.builder.impl.KieContainerImpl.newKieSession(KieContainerImpl.java:375)
{noformat}

Actually, the system uses the format number "1,00000" (with comma in french) instead of "1.00000" like it should use.

This is causing by the line 174 in org.drools.decisiontable.parser.xls.ExcelParser :

{code:java}
if ( num - Math.round( num ) != 0 )
{code}

I don't understand why we use the formatted value when this test is not passed.

I think the end users should have the possibility to keep the same formatter for the same column, with integers or not.

  was:
When I use decimal formatter in an excel action column for numbers that are in fact integers, I am getting this exception :

{noformat}
Exception in thread "main" java.lang.RuntimeException: Error while creating KieBase[Message [id=1, level=ERROR, path=com/sample/my_decision_table.xls, line=5, column=0
   text=Rule Compilation error The method setParameter(double) in the type MyObject is not applicable for the arguments (int, int)]]
	at org.drools.compiler.kie.builder.impl.KieContainerImpl.getKieBase(KieContainerImpl.java:260)
	at org.drools.compiler.kie.builder.impl.KieContainerImpl.newKieSession(KieContainerImpl.java:400)
	at org.drools.compiler.kie.builder.impl.KieContainerImpl.newKieSession(KieContainerImpl.java:375)
{noformat}

Actually, the system uses the format number "1,00000" (with comma in french) instead of "1.00000" like it should use.

This is causing by the line 174 in org.drools.decisiontable.parser.xls.ExcelParser :

{code:java}
if ( num - Math.round( num ) != 0 )
{code}

The end users should have the possibility to keep the same formatter for the same column, with integers or not.


    
> Cannot use decimal formatters for integers in an excel decision table
> ---------------------------------------------------------------------
>
>                 Key: DROOLS-450
>                 URL: https://issues.jboss.org/browse/DROOLS-450
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 6.0.1.Final
>            Reporter: Maxime Falaize
>            Assignee: Mark Proctor
>            Priority: Minor
>         Attachments: issue_example.png
>
>
> When I use decimal formatter in an excel action column for numbers that are in fact integers, I am getting this exception :
> {noformat}
> Exception in thread "main" java.lang.RuntimeException: Error while creating KieBase[Message [id=1, level=ERROR, path=com/sample/my_decision_table.xls, line=5, column=0
>    text=Rule Compilation error The method setParameter(double) in the type MyObject is not applicable for the arguments (int, int)]]
> 	at org.drools.compiler.kie.builder.impl.KieContainerImpl.getKieBase(KieContainerImpl.java:260)
> 	at org.drools.compiler.kie.builder.impl.KieContainerImpl.newKieSession(KieContainerImpl.java:400)
> 	at org.drools.compiler.kie.builder.impl.KieContainerImpl.newKieSession(KieContainerImpl.java:375)
> {noformat}
> Actually, the system uses the format number "1,00000" (with comma in french) instead of "1.00000" like it should use.
> This is causing by the line 174 in org.drools.decisiontable.parser.xls.ExcelParser :
> {code:java}
> if ( num - Math.round( num ) != 0 )
> {code}
> I don't understand why we use the formatted value when this test is not passed.
> I think the end users should have the possibility to keep the same formatter for the same column, with integers or not.

--
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

From issues at jboss.org  Tue Mar 11 13:33:11 2014
From: issues at jboss.org (Richard Achmatowicz (JIRA))
Date: Tue, 11 Mar 2014 13:33:11 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1797) NakackTest
 testReceptionOfAllMessages fails to receive all messages
In-Reply-To: <JIRA.12533037.1393192228000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12533037.1393192228000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12533037.1393192228000.6552.1394559191590@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JGRP-1797?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12952060#comment-12952060 ] 

Richard Achmatowicz edited comment on JGRP-1797 at 3/11/14 1:31 PM:
--------------------------------------------------------------------

I guess even though messages are delivered in order, once they start processing of the receive() method, they can get context switched out of order by other later threads. I did a quick check and there are often two threads in the receiver code at any one time.
 
                
      was (Author: rachmato):
    I guess even though messages are delivered in order, once they start processing of the receive() method, they can get context switched out of order by other later threads. 
 
                  
> NakackTest testReceptionOfAllMessages fails to receive all messages
> -------------------------------------------------------------------
>
>                 Key: JGRP-1797
>                 URL: https://issues.jboss.org/browse/JGRP-1797
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.2.13
>         Environment: RHEL (5/24), Solaris (6/24), HPUX (1/2) where x/y means x failures over y test executions.
>            Reporter: Richard Achmatowicz
>            Assignee: Bela Ban
>             Fix For: 3.2.13
>
>         Attachments: stdout.txt
>
>
> This test does the following:
> - involves channels A, B, and C where only B and C are senders and all are receivers
> - B and C send 1000 multicast messages
> - checks that all messages are received and in the correct order
> This test is failing intermittently but quite often.

--
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

From issues at jboss.org  Tue Mar 11 13:57:11 2014
From: issues at jboss.org (Richard Achmatowicz (JIRA))
Date: Tue, 11 Mar 2014 13:57:11 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1797) NakackTest
 testReceptionOfAllMessages fails to receive all messages
In-Reply-To: <JIRA.12533037.1393192228000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12533037.1393192228000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12533037.1393192228000.6602.1394560631399@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JGRP-1797?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Richard Achmatowicz updated JGRP-1797:
--------------------------------------

    Git Pull Request: https://github.com/belaban/JGroups/pull/134

    
> NakackTest testReceptionOfAllMessages fails to receive all messages
> -------------------------------------------------------------------
>
>                 Key: JGRP-1797
>                 URL: https://issues.jboss.org/browse/JGRP-1797
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.2.13
>         Environment: RHEL (5/24), Solaris (6/24), HPUX (1/2) where x/y means x failures over y test executions.
>            Reporter: Richard Achmatowicz
>            Assignee: Bela Ban
>             Fix For: 3.2.13
>
>         Attachments: stdout.txt
>
>
> This test does the following:
> - involves channels A, B, and C where only B and C are senders and all are receivers
> - B and C send 1000 multicast messages
> - checks that all messages are received and in the correct order
> This test is failing intermittently but quite often.

--
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

From issues at jboss.org  Tue Mar 11 13:59:10 2014
From: issues at jboss.org (Matteo Mortari (JIRA))
Date: Tue, 11 Mar 2014 13:59:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-451) Timed rules, different name,
 same timer, same LHS, different RHS, one mask the other
In-Reply-To: <JIRA.12534708.1394560632506@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534708.1394560632506@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534708.1394560632506.6625.1394560750828@jira02.app.mwc.hst.phx2.redhat.com>

Matteo Mortari created DROOLS-451:
-------------------------------------

             Summary: Timed rules, different name, same timer, same LHS, different RHS, one mask the other
                 Key: DROOLS-451
                 URL: https://issues.jboss.org/browse/DROOLS-451
             Project: Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions: 6.0.1.Final
            Reporter: Matteo Mortari
            Assignee: Mark Proctor
         Attachments: 2014-03-11_18-52-25.png, 20140311.drools6test.timerrulessamelhs.zip

Consider the following KB:
{code}
rule "Dummy timer rule 1"
timer (cron: 0 0 0 * * ?)
when
	Integer()
then
	insert("Dummy timer rule 1");
	System.out.println("Dummy timer rule 1");
end

rule "Dummy timer rule 2"
timer (cron: 0 0 0 * * ?)
when
	Integer()
then
	insert("Dummy timer rule 2");
	System.out.println("Dummy timer rule 2");
end
{code}

Then consider the following steps:
# insert new Integer
# advance clock by +1 day

*Expected result:* 3 facts in the working memory, the original Integer, and two String.

*Actual results:* 2 facts in the working memory, the original Integer, and only 1 String, from the former of the two rules.

I hope this is not another duplicate report, I've done search on Jira before submitting, but kindly excuse me if I didn't found an already open bug which is a greater case of this one =)

I will attach relevant source code to replicate the issue, and related material

--
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

From issues at jboss.org  Tue Mar 11 13:59:11 2014
From: issues at jboss.org (Richard Achmatowicz (JIRA))
Date: Tue, 11 Mar 2014 13:59:11 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1797) NakackTest
 testReceptionOfAllMessages fails to receive all messages
In-Reply-To: <JIRA.12533037.1393192228000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12533037.1393192228000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12533037.1393192228000.6632.1394560751268@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JGRP-1797?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12952094#comment-12952094 ] 

Richard Achmatowicz commented on JGRP-1797:
-------------------------------------------

The PR makes the receiver thread synchronized. This should have no impact on the test because we are simply testing that all messages are received and in the correct order (i.e.not allowing concurrent processing of message receipt is not relevant).

Also added a little more debugging info on the assertion.
 
                
> NakackTest testReceptionOfAllMessages fails to receive all messages
> -------------------------------------------------------------------
>
>                 Key: JGRP-1797
>                 URL: https://issues.jboss.org/browse/JGRP-1797
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.2.13
>         Environment: RHEL (5/24), Solaris (6/24), HPUX (1/2) where x/y means x failures over y test executions.
>            Reporter: Richard Achmatowicz
>            Assignee: Bela Ban
>             Fix For: 3.2.13
>
>         Attachments: stdout.txt
>
>
> This test does the following:
> - involves channels A, B, and C where only B and C are senders and all are receivers
> - B and C send 1000 multicast messages
> - checks that all messages are received and in the correct order
> This test is failing intermittently but quite often.

--
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

From issues at jboss.org  Tue Mar 11 13:59:11 2014
From: issues at jboss.org (Matteo Mortari (JIRA))
Date: Tue, 11 Mar 2014 13:59:11 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-451) Timed rules, different name,
 same timer, same LHS, different RHS, one mask the other
In-Reply-To: <JIRA.12534708.1394560632000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534708.1394560632000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534708.1394560632000.6634.1394560751402@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-451?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Matteo Mortari updated DROOLS-451:
----------------------------------

    Attachment: 2014-03-11_18-52-25.png
                20140311.drools6test.timerrulessamelhs.zip


Screenshot of rete/phreak looking promising but apparently not working, but also Java code to reproduce the failure.
                
> Timed rules, different name, same timer, same LHS, different RHS, one mask the other
> ------------------------------------------------------------------------------------
>
>                 Key: DROOLS-451
>                 URL: https://issues.jboss.org/browse/DROOLS-451
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 6.0.1.Final
>            Reporter: Matteo Mortari
>            Assignee: Mark Proctor
>         Attachments: 2014-03-11_18-52-25.png, 20140311.drools6test.timerrulessamelhs.zip
>
>
> Consider the following KB:
> {code}
> rule "Dummy timer rule 1"
> timer (cron: 0 0 0 * * ?)
> when
> 	Integer()
> then
> 	insert("Dummy timer rule 1");
> 	System.out.println("Dummy timer rule 1");
> end
> rule "Dummy timer rule 2"
> timer (cron: 0 0 0 * * ?)
> when
> 	Integer()
> then
> 	insert("Dummy timer rule 2");
> 	System.out.println("Dummy timer rule 2");
> end
> {code}
> Then consider the following steps:
> # insert new Integer
> # advance clock by +1 day
> *Expected result:* 3 facts in the working memory, the original Integer, and two String.
> *Actual results:* 2 facts in the working memory, the original Integer, and only 1 String, from the former of the two rules.
> I hope this is not another duplicate report, I've done search on Jira before submitting, but kindly excuse me if I didn't found an already open bug which is a greater case of this one =)
> I will attach relevant source code to replicate the issue, and related material

--
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

From issues at jboss.org  Tue Mar 11 14:19:10 2014
From: issues at jboss.org (Bryan Galvin (JIRA))
Date: Tue, 11 Mar 2014 14:19:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBASMP-58) jboss-as-maven-plugin freezes
 on authentication
In-Reply-To: <JIRA.12508946.1383048331000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508946.1383048331000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508946.1383048331000.6667.1394561950705@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JBASMP-58?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12952099#comment-12952099 ] 

Bryan Galvin commented on JBASMP-58:
------------------------------------

We upgraded to jboss-as-maven-plugin version=7.4.Final, today. We have not experienced the 'freeze' issue since the upgrade.
                
> jboss-as-maven-plugin freezes on authentication
> -----------------------------------------------
>
>                 Key: JBASMP-58
>                 URL: https://issues.jboss.org/browse/JBASMP-58
>             Project: JBoss AS Maven Plugins
>          Issue Type: Bug
>          Components: deploy
>    Affects Versions: 7.5.Final
>         Environment: mac os x 10.8.5 & mac os x 10.9
> mvn 3.1.1
>            Reporter: Julien Derveeuw
>            Assignee: James Perkins
>            Priority: Critical
>
> I have jboss 7.1.1 in standalone mode running on machine A (linux).
> I want to deploy remotely to it using client machine B @ mac os X 10.8.5 / JDK 1.7.0_45-b18.
> If I connect from B to A using {{jboss-cli}}, everything works fine, I am able to login.
> If I try to deploy from maven with this :
> {code:xml}
>                 <groupId>org.jboss.as.plugins</groupId>
>                 <artifactId>jboss-as-maven-plugin</artifactId>
>                 <version>7.5.Final</version>
>                 <configuration>
>                     <hostname>${deploy.jboss.host}</hostname>
>                     <port>${deploy.jboss.port}</port>
>                     <username>${deploy.jboss.user}</username>
>                     <password>${deploy.jboss.password}</password>
>                 </configuration>
>                 <executions>
>                     <execution>
>                         <phase>install</phase>
>                         <goals>
>                             <goal>deploy</goal>
>                         </goals>
>                     </execution>
>                 </executions>
> {code}
> plugin freezes indefinitely on 
> {{Authenticating against security realm: ManagementRealm}}
> No more details are available with {{mvn -X}}
> If I remove the password or username from pom, it fails correctly with :
> {{The connection failed: Authentication failed: all available authentication mechanisms failed}}
> so it seems that the plugin somehow manages to connect to machine A.
> After digging on google, I ended up adding {{-Djava.nio.channels.spi.SelectorProvider=sun.nio.ch.KQueueSelectorProvider}} to mvn runner options because NIOs on jdk7 at macosx is said to be buggy but it didn't help.
> More details :
> {code:title=mvn 3.1.1 output|borderStyle=solid}Nov 7, 2013 10:40:09 PM org.xnio.Xnio <clinit>
> INFO: XNIO Version 3.0.3.GA
> Nov 7, 2013 10:40:09 PM org.xnio.nio.NioXnio <clinit>
> INFO: XNIO NIO Implementation Version 3.0.3.GA
> Nov 7, 2013 10:40:09 PM org.jboss.remoting3.EndpointImpl <clinit>
> INFO: JBoss Remoting version 3.2.3.GA
> Authenticating against security realm: ManagementRealm
> {code}
> {code:title=jstack 7.1.1.Final|borderStyle=solid}
> "main" prio=5 tid=7f86d6800800 nid=0x1060f0000 in Object.wait() [1060ee000]
>    java.lang.Thread.State: WAITING (on object monitor)
> 	at java.lang.Object.wait(Native Method)
> 	- waiting on <7f4102a20> (a org.jboss.as.protocol.mgmt.ActiveOperationSupport$ActiveOperationImpl)
> 	at java.lang.Object.wait(Object.java:485)
> 	at org.jboss.threads.AsyncFutureTask.await(AsyncFutureTask.java:192)
> 	- locked <7f4102a20> (a org.jboss.as.protocol.mgmt.ActiveOperationSupport$ActiveOperationImpl)
> 	at org.jboss.threads.AsyncFutureTask.get(AsyncFutureTask.java:266)
> 	- locked <7f4102a20> (a org.jboss.as.protocol.mgmt.ActiveOperationSupport$ActiveOperationImpl)
> 	at org.jboss.as.controller.client.impl.AbstractModelControllerClient$DelegatingCancellableAsyncFuture.get(AbstractModelControllerClient.java:363)
> 	at org.jboss.as.controller.client.impl.AbstractModelControllerClient$DelegatingCancellableAsyncFuture.get(AbstractModelControllerClient.java:317)
> 	at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeForResult(AbstractModelControllerClient.java:137)
> 	at org.jboss.as.controller.client.impl.AbstractModelControllerClient.execute(AbstractModelControllerClient.java:81)
> 	at org.jboss.as.plugin.deployment.standalone.StandaloneDeployment.exists(StandaloneDeployment.java:175)
> 	at org.jboss.as.plugin.deployment.standalone.StandaloneDeployment.createPlan(StandaloneDeployment.java:108)
> 	at org.jboss.as.plugin.deployment.standalone.StandaloneDeployment.execute(StandaloneDeployment.java:133)
> 	at org.jboss.as.plugin.deployment.AbstractDeployment.execute(AbstractDeployment.java:138)
> 	at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:106)
> 	at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
> 	at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
> 	at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
> 	at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
> 	at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
> 	at org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
> 	at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
> 	at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:317)
> 	at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:152)
> 	at org.apache.maven.cli.MavenCli.execute(MavenCli.java:555)
> 	at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:214)
> 	at org.apache.maven.cli.MavenCli.main(MavenCli.java:158)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
> 	at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
> 	at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
> 	at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
> {code}
> {code:title=jstack 7.5.Final|borderStyle=solid}
> "main" prio=5 tid=7fceea001000 nid=0x10d4d0000 in Object.wait() [10d4ce000]
>    java.lang.Thread.State: WAITING (on object monitor)
> 	at java.lang.Object.wait(Native Method)
> 	- waiting on <7f42f2150> (a org.jboss.as.protocol.mgmt.ActiveOperationSupport$ActiveOperationImpl)
> 	at java.lang.Object.wait(Object.java:485)
> 	at org.jboss.threads.AsyncFutureTask.await(AsyncFutureTask.java:192)
> 	- locked <7f42f2150> (a org.jboss.as.protocol.mgmt.ActiveOperationSupport$ActiveOperationImpl)
> 	at org.jboss.threads.AsyncFutureTask.get(AsyncFutureTask.java:266)
> 	- locked <7f42f2150> (a org.jboss.as.protocol.mgmt.ActiveOperationSupport$ActiveOperationImpl)
> 	at org.jboss.as.controller.client.impl.AbstractDelegatingAsyncFuture.get(AbstractDelegatingAsyncFuture.java:100)
> 	at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeForResult(AbstractModelControllerClient.java:127)
> 	at org.jboss.as.controller.client.impl.AbstractModelControllerClient.execute(AbstractModelControllerClient.java:71)
> 	at org.jboss.as.plugin.common.AbstractServerConnection.isDomainServer(AbstractServerConnection.java:234)
> 	at org.jboss.as.plugin.common.AbstractServerConnection.getClient(AbstractServerConnection.java:156)
> 	- locked <7f42f2230> (a java.lang.Object)
> 	at org.jboss.as.plugin.common.AbstractServerConnection.isDomainServer(AbstractServerConnection.java:133)
> 	- locked <7f42f2230> (a java.lang.Object)
> 	at org.jboss.as.plugin.deployment.AbstractDeployment.validate(AbstractDeployment.java:192)
> 	at org.jboss.as.plugin.deployment.AbstractDeployment.doExecute(AbstractDeployment.java:136)
> 	- locked <7f42f2230> (a java.lang.Object)
> 	at org.jboss.as.plugin.deployment.AbstractAppDeployment.doExecute(AbstractAppDeployment.java:70)
> 	at org.jboss.as.plugin.deployment.AbstractDeployment.execute(AbstractDeployment.java:111)
> 	at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:106)
> 	at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
> 	at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
> 	at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
> 	at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
> 	at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
> 	at org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
> 	at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
> 	at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:317)
> 	at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:152)
> 	at org.apache.maven.cli.MavenCli.execute(MavenCli.java:555)
> 	at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:214)
> 	at org.apache.maven.cli.MavenCli.main(MavenCli.java:158)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
> 	at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
> 	at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
> 	at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
> {code}

--
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

From issues at jboss.org  Tue Mar 11 14:45:11 2014
From: issues at jboss.org (Carlo de Wolf (JIRA))
Date: Tue, 11 Mar 2014 14:45:11 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBEE-151) Missing doPrivileged block(s)
 around getContextClassLoader
In-Reply-To: <JIRA.12534710.1394563445352@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534710.1394563445352@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534710.1394563445352.6697.1394563511230@jira02.app.mwc.hst.phx2.redhat.com>

Carlo de Wolf created JBEE-151:
----------------------------------

             Summary:  Missing doPrivileged block(s) around getContextClassLoader
                 Key: JBEE-151
                 URL: https://issues.jboss.org/browse/JBEE-151
             Project: JBoss JavaEE Spec APIs
          Issue Type: Bug
          Components: general
            Reporter: Carlo de Wolf
            Assignee: Shelly McGowan


jboss-el-api_2.2_spec-1.0.2.Final-redhat-1.jar:1.0.2.Final-redhat-1

{code}
12:56:34,897 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[default-host].[/read-props].[jsp]] (http-/127.0.0.1:8080-4) JBWEB000236: Servlet.service() for servlet jsp threw exception: java.security.AccessControlException: access denied ("java.lang.RuntimePermission" "getClassLoader")
	at java.security.AccessControlContext.checkPermission(AccessControlContext.java:372) [rt.jar:1.7.0_45]
	at java.security.AccessController.checkPermission(AccessController.java:559) [rt.jar:1.7.0_45]
	at java.lang.SecurityManager.checkPermission(SecurityManager.java:549) [rt.jar:1.7.0_45]
	at java.lang.ClassLoader.checkClassLoaderPermission(ClassLoader.java:1561) [rt.jar:1.7.0_45]
	at java.lang.Thread.getContextClassLoader(Thread.java:1472) [rt.jar:1.7.0_45]
	at javax.el.FactoryFinder.find(FactoryFinder.java:130) [jboss-el-api_2.2_spec-1.0.2.Final-redhat-1.jar:1.0.2.Final-redhat-1]
	at javax.el.ExpressionFactory.newInstance(ExpressionFactory.java:185) [jboss-el-api_2.2_spec-1.0.2.Final-redhat-1.jar:1.0.2.Final-redhat-1]
	at javax.el.ExpressionFactory.newInstance(ExpressionFactory.java:156) [jboss-el-api_2.2_spec-1.0.2.Final-redhat-1.jar:1.0.2.Final-redhat-1]
	at org.apache.jasper.runtime.JspApplicationContextImpl.<init>(JspApplicationContextImpl.java:48) [jbossweb-7.4.0.Beta4.jar:7.4.0.Beta4]
{code}

--
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

From issues at jboss.org  Tue Mar 11 14:47:11 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 11 Mar 2014 14:47:11 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBEE-151) Missing doPrivileged block(s)
 around getContextClassLoader
In-Reply-To: <JIRA.12534710.1394563445000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534710.1394563445000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534710.1394563445000.6701.1394563631023@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBEE-151?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated JBEE-151:
-----------------------------------------

        Bugzilla Update: Perform
    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1075045

    
>  Missing doPrivileged block(s) around getContextClassLoader
> -----------------------------------------------------------
>
>                 Key: JBEE-151
>                 URL: https://issues.jboss.org/browse/JBEE-151
>             Project: JBoss JavaEE Spec APIs
>          Issue Type: Bug
>          Components: general
>            Reporter: Carlo de Wolf
>            Assignee: Shelly McGowan
>
> jboss-el-api_2.2_spec-1.0.2.Final-redhat-1.jar:1.0.2.Final-redhat-1
> {code}
> 12:56:34,897 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[default-host].[/read-props].[jsp]] (http-/127.0.0.1:8080-4) JBWEB000236: Servlet.service() for servlet jsp threw exception: java.security.AccessControlException: access denied ("java.lang.RuntimePermission" "getClassLoader")
> 	at java.security.AccessControlContext.checkPermission(AccessControlContext.java:372) [rt.jar:1.7.0_45]
> 	at java.security.AccessController.checkPermission(AccessController.java:559) [rt.jar:1.7.0_45]
> 	at java.lang.SecurityManager.checkPermission(SecurityManager.java:549) [rt.jar:1.7.0_45]
> 	at java.lang.ClassLoader.checkClassLoaderPermission(ClassLoader.java:1561) [rt.jar:1.7.0_45]
> 	at java.lang.Thread.getContextClassLoader(Thread.java:1472) [rt.jar:1.7.0_45]
> 	at javax.el.FactoryFinder.find(FactoryFinder.java:130) [jboss-el-api_2.2_spec-1.0.2.Final-redhat-1.jar:1.0.2.Final-redhat-1]
> 	at javax.el.ExpressionFactory.newInstance(ExpressionFactory.java:185) [jboss-el-api_2.2_spec-1.0.2.Final-redhat-1.jar:1.0.2.Final-redhat-1]
> 	at javax.el.ExpressionFactory.newInstance(ExpressionFactory.java:156) [jboss-el-api_2.2_spec-1.0.2.Final-redhat-1.jar:1.0.2.Final-redhat-1]
> 	at org.apache.jasper.runtime.JspApplicationContextImpl.<init>(JspApplicationContextImpl.java:48) [jbossweb-7.4.0.Beta4.jar:7.4.0.Beta4]
> {code}

--
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

From issues at jboss.org  Tue Mar 11 17:57:10 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 11 Mar 2014 17:57:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3007) Ipv6 addresses may not be
 canonized properly
In-Reply-To: <JIRA.12533139.1393261818000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12533139.1393261818000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12533139.1393261818000.7767.1394575030892@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-3007?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12952138#comment-12952138 ] 

RH Bugzilla Integration commented on WFLY-3007:
-----------------------------------------------

Paul Gier <pgier at redhat.com> changed the Status of [bug 1067348|https://bugzilla.redhat.com/show_bug.cgi?id=1067348] from MODIFIED to ON_QA
                
> Ipv6 addresses may not be canonized properly
> --------------------------------------------
>
>                 Key: WFLY-3007
>                 URL: https://issues.jboss.org/browse/WFLY-3007
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 8.0.0.Final
>            Reporter: Emmanuel Hugonnet
>            Assignee: Emmanuel Hugonnet
>
> On an ipv6 environment we may obtain IP addresses that are not properly canonized which may lead to strange issue with http proxies since the JDK ProxySelector relies on char per char matching.
> All call to InetAddress.getHostName() may produce such an uncanonized address.

--
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

From issues at jboss.org  Tue Mar 11 17:57:11 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 11 Mar 2014 17:57:11 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3071) upgrade Generic JMS RA to
	1.0.2.Final
In-Reply-To: <JIRA.12534174.1394029950000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534174.1394029950000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534174.1394029950000.7770.1394575031009@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-3071?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12952139#comment-12952139 ] 

RH Bugzilla Integration commented on WFLY-3071:
-----------------------------------------------

Paul Gier <pgier at redhat.com> changed the Status of [bug 1073354|https://bugzilla.redhat.com/show_bug.cgi?id=1073354] from MODIFIED to ON_QA
                
> upgrade Generic JMS RA to 1.0.2.Final
> -------------------------------------
>
>                 Key: WFLY-3071
>                 URL: https://issues.jboss.org/browse/WFLY-3071
>             Project: WildFly
>          Issue Type: Component  Upgrade
>      Security Level: Public(Everyone can see) 
>          Components: JCA
>    Affects Versions: 8.0.0.Final
>            Reporter: Jeff Mesnil
>            Assignee: Jeff Mesnil
>             Fix For: 8.0.1.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

From issues at jboss.org  Tue Mar 11 17:57:11 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 11 Mar 2014 17:57:11 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3077) Convert command line IPv6 URL
 literals to address literals
In-Reply-To: <JIRA.12534346.1394155395000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534346.1394155395000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534346.1394155395000.7773.1394575031202@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-3077?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12952140#comment-12952140 ] 

RH Bugzilla Integration commented on WFLY-3077:
-----------------------------------------------

Paul Gier <pgier at redhat.com> changed the Status of [bug 1064771|https://bugzilla.redhat.com/show_bug.cgi?id=1064771] from MODIFIED to ON_QA
                
> Convert command line IPv6 URL literals to address literals
> ----------------------------------------------------------
>
>                 Key: WFLY-3077
>                 URL: https://issues.jboss.org/browse/WFLY-3077
>             Project: WildFly
>          Issue Type: Enhancement
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 8.0.0.Final
>            Reporter: Brian Stansberry
>            Assignee: Brian Stansberry
>            Priority: Minor
>             Fix For: 8.0.1.Final
>
>
> When people provide URL-style values like [::1] for command line args like -b, convert them to address values (i.e. strip the enclosing brackets.)

--
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

From issues at jboss.org  Tue Mar 11 17:57:11 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 11 Mar 2014 17:57:11 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3078) directory-grouping
 configuration is not getting persisted via CLI when no servers defined
In-Reply-To: <JIRA.12534347.1394159920000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534347.1394159920000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534347.1394159920000.7783.1394575031631@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-3078?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12952142#comment-12952142 ] 

RH Bugzilla Integration commented on WFLY-3078:
-----------------------------------------------

Paul Gier <pgier at redhat.com> changed the Status of [bug 1073715|https://bugzilla.redhat.com/show_bug.cgi?id=1073715] from MODIFIED to ON_QA
                
> directory-grouping configuration is not getting persisted via CLI when no servers defined
> -----------------------------------------------------------------------------------------
>
>                 Key: WFLY-3078
>                 URL: https://issues.jboss.org/browse/WFLY-3078
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>    Affects Versions: 8.0.0.Final
>         Environment: All Operating System
>            Reporter: Jay Kumar SenSharma
>            Assignee: Emanuel Muckenhuber
>             Fix For: 8.0.1.Final
>
>
> - If none of the servers are defined in "host.xml" (means <servers></servers> empty tag is present) and if the user tries to run the following CLI command to change the "directory-grouping" to  "by-type"  then the value is not persisted in the configuration file (host.xml) and the <servers></servers>  tag is also removed from the host.xml
> {code}
> /host=master/:write-attribute(name=directory-grouping,value=by-type)
> {code}
> - The value of "directory-grouping" is stored "in memory" so this change does not survive the host restart.

--
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

From issues at jboss.org  Tue Mar 11 17:57:11 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 11 Mar 2014 17:57:11 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3042) There should be a warning
 logged if the default value of node identifier has not been changed.
In-Reply-To: <JIRA.12533608.1393595350000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12533608.1393595350000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12533608.1393595350000.7789.1394575031900@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-3042?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12952143#comment-12952143 ] 

RH Bugzilla Integration commented on WFLY-3042:
-----------------------------------------------

Paul Gier <pgier at redhat.com> changed the Status of [bug 1072312|https://bugzilla.redhat.com/show_bug.cgi?id=1072312] from MODIFIED to ON_QA
                
> There should be a warning logged if the default value of node identifier has not been changed.  
> ------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-3042
>                 URL: https://issues.jboss.org/browse/WFLY-3042
>             Project: WildFly
>          Issue Type: Enhancement
>      Security Level: Public(Everyone can see) 
>          Components: Transactions
>    Affects Versions: 8.0.0.Final
>         Environment: JBoss EAP 6.x
>            Reporter: Tom Ross
>            Assignee: Gytis Trikleris
>
> JBoss EAP instance is using the value of node identifier  to identify XA transactions that belong to it. By default this value is set to 1. Now days in most environments there will be multiple JBoss instances sharing XA resources there for it is necessary to set the value of node identifier to a unique value for each instance. This is something that most end users fail to perform. Therefor it would be helpful if  a warning  message was logged at startup telling the user to do it.

--
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

From issues at jboss.org  Tue Mar 11 17:57:12 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 11 Mar 2014 17:57:12 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3094) Warn if there is no resource
 bound for address-settings expiry and dead-letter addresses
In-Reply-To: <JIRA.12534528.1394450392000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534528.1394450392000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534528.1394450392000.7798.1394575032284@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-3094?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12952145#comment-12952145 ] 

RH Bugzilla Integration commented on WFLY-3094:
-----------------------------------------------

Paul Gier <pgier at redhat.com> changed the Status of [bug 1014099|https://bugzilla.redhat.com/show_bug.cgi?id=1014099] from MODIFIED to ON_QA
                
> Warn if there is no resource bound for address-settings expiry and dead-letter addresses
> ----------------------------------------------------------------------------------------
>
>                 Key: WFLY-3094
>                 URL: https://issues.jboss.org/browse/WFLY-3094
>             Project: WildFly
>          Issue Type: Enhancement
>      Security Level: Public(Everyone can see) 
>          Components: JMS
>    Affects Versions: 8.0.0.Final
>            Reporter: Jeff Mesnil
>            Assignee: Jeff Mesnil
>             Fix For: 8.0.1.Final
>
>
> Warns the user if a address-setting has defined an expiry-address or a dead-letter-address with no queue bound for them as this will result in unintended message loss.
> WildFly default full configuration specifies an expiry address (jms.queue.ExpiryQueue) and dead-letter-addres (jms.queue.DLQ) for the # address settings (i.e. matching all addresses).
> To have a consistent configuration, we must also define 2 queues that will be bound to these settings.

--
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

From issues at jboss.org  Tue Mar 11 17:57:12 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 11 Mar 2014 17:57:12 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3073) MBeanServer.createMBean
 methods that take a classloader don't work
In-Reply-To: <JIRA.12534226.1394051286000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534226.1394051286000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534226.1394051286000.7802.1394575032454@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-3073?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12952146#comment-12952146 ] 

RH Bugzilla Integration commented on WFLY-3073:
-----------------------------------------------

Paul Gier <pgier at redhat.com> changed the Status of [bug 1073106|https://bugzilla.redhat.com/show_bug.cgi?id=1073106] from MODIFIED to ON_QA
                
> MBeanServer.createMBean methods that take a classloader don't work
> ------------------------------------------------------------------
>
>                 Key: WFLY-3073
>                 URL: https://issues.jboss.org/browse/WFLY-3073
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JMX
>    Affects Versions: 8.0.0.Final
>            Reporter: Stuart Douglas
>            Assignee: Kabir Khan
>             Fix For: 8.0.1.Final
>
>
> The MBeanServer.createMBean methods that take an "ObjectName loaderName" argument are completely broken in EAP 6.
> These methods call findDelegate to make sure there is already an existing MBean registered with the given name passed in for the new MBean, or else it throws an exception.
> This is obviously wrong, as there'd be no point in calling createMBean if it already existed.
> javax.management.InstanceNotFoundException: test:service=Test
> at org.jboss.as.jmx.PluggableMBeanServerImpl.findDelegate(PluggableMBeanServerImpl.java:1083)
> at org.jboss.as.jmx.PluggableMBeanServerImpl.createMBean(PluggableMBeanServerImpl.java:253)

--
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

From issues at jboss.org  Tue Mar 11 17:57:12 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 11 Mar 2014 17:57:12 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3069) slaves cannot reconnect to a
 restarted master if RBAC is enabled
In-Reply-To: <JIRA.12534143.1394020494000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534143.1394020494000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534143.1394020494000.7808.1394575032694@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-3069?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12952147#comment-12952147 ] 

RH Bugzilla Integration commented on WFLY-3069:
-----------------------------------------------

Paul Gier <pgier at redhat.com> changed the Status of [bug 1072915|https://bugzilla.redhat.com/show_bug.cgi?id=1072915] from MODIFIED to ON_QA
                
> slaves cannot reconnect to a restarted master if RBAC is enabled
> ----------------------------------------------------------------
>
>                 Key: WFLY-3069
>                 URL: https://issues.jboss.org/browse/WFLY-3069
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>    Affects Versions: 8.0.0.Final
>            Reporter: Tom Fonteyne
>            Assignee: Emanuel Muckenhuber
>            Priority: Critical
>             Fix For: 8.0.1.Final
>
>
> Enable RBAC in an Wilfly domain setup. "reload --host=master" and the slaves will no longer be connected to the master

--
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

From issues at jboss.org  Tue Mar 11 17:57:13 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 11 Mar 2014 17:57:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2920) StackOverflowError when
 org.jboss.as.jacorb.rmi.InterfaceAnalysis is analyzing javax.ejb.EJBObject
In-Reply-To: <JIRA.12532007.1392269121000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12532007.1392269121000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12532007.1392269121000.7822.1394575033297@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2920?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12952149#comment-12952149 ] 

RH Bugzilla Integration commented on WFLY-2920:
-----------------------------------------------

Paul Gier <pgier at redhat.com> changed the Status of [bug 1064644|https://bugzilla.redhat.com/show_bug.cgi?id=1064644] from MODIFIED to ON_QA
                
> StackOverflowError when org.jboss.as.jacorb.rmi.InterfaceAnalysis is analyzing javax.ejb.EJBObject
> --------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2920
>                 URL: https://issues.jboss.org/browse/WFLY-2920
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: IIOP
>    Affects Versions: 8.0.0.Final
>            Reporter: Osamu Nagano
>            Assignee: Stefan Guilhen
>         Attachments: td.dump
>
>
> Depending on when a thread context switch happens, an IIOP enabled EJB fails to be deployed by throwing {{java.lang.StackOverflowError}}.  Here is the stack trace from the attached thread dump.
> {code}
> "MSC service thread 1-7" prio=10 tid=0x00007f52e8001800 nid=0x4d12 at breakpoint[0x00007f534093f000]
>    java.lang.Thread.State: RUNNABLE
>         at org.jboss.as.jacorb.rmi.WorkCacheManager.getAnalysis(WorkCacheManager.java:105)
>         at org.jboss.as.jacorb.rmi.InterfaceAnalysis.getInterfaceAnalysis(InterfaceAnalysis.java:53)
>         at org.jboss.as.jacorb.rmi.Util.getTypeIDLName(Util.java:104)
>         at org.jboss.as.jacorb.rmi.ParameterAnalysis.<init>(ParameterAnalysis.java:50)
>         at org.jboss.as.jacorb.rmi.OperationAnalysis.<init>(OperationAnalysis.java:91)
>         at org.jboss.as.jacorb.rmi.InterfaceAnalysis.analyzeOperations(InterfaceAnalysis.java:116)
>         at org.jboss.as.jacorb.rmi.ContainerAnalysis.doAnalyze(ContainerAnalysis.java:186)
>         at org.jboss.as.jacorb.rmi.InterfaceAnalysis.doAnalyze(InterfaceAnalysis.java:62)
>         at sun.reflect.GeneratedMethodAccessor3.invoke(Unknown Source)
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>         at java.lang.reflect.Method.invoke(Method.java:606)
>         at org.jboss.as.jacorb.rmi.WorkCacheManager.doTheWork(WorkCacheManager.java:177)
>         at org.jboss.as.jacorb.rmi.WorkCacheManager.getAnalysis(WorkCacheManager.java:105)
>         at org.jboss.as.jacorb.rmi.InterfaceAnalysis.getInterfaceAnalysis(InterfaceAnalysis.java:53)
>         at org.jboss.as.jacorb.rmi.Util.getTypeIDLName(Util.java:104)
>         at org.jboss.as.jacorb.rmi.ParameterAnalysis.<init>(ParameterAnalysis.java:50)
>         at org.jboss.as.jacorb.rmi.OperationAnalysis.<init>(OperationAnalysis.java:91)
>         at org.jboss.as.jacorb.rmi.InterfaceAnalysis.analyzeOperations(InterfaceAnalysis.java:116)
>         at org.jboss.as.jacorb.rmi.ContainerAnalysis.doAnalyze(ContainerAnalysis.java:186)
>         at org.jboss.as.jacorb.rmi.InterfaceAnalysis.doAnalyze(InterfaceAnalysis.java:62)
>         at sun.reflect.GeneratedMethodAccessor3.invoke(Unknown Source)
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>         at java.lang.reflect.Method.invoke(Method.java:606)
>         ...
>         at org.jboss.as.jacorb.rmi.WorkCacheManager.doTheWork(WorkCacheManager.java:177)
>         at org.jboss.as.jacorb.rmi.WorkCacheManager.getAnalysis(WorkCacheManager.java:105)
>         at org.jboss.as.jacorb.rmi.InterfaceAnalysis.getInterfaceAnalysis(InterfaceAnalysis.java:53)
>         at org.jboss.as.jacorb.rmi.Util.getTypeIDLName(Util.java:104)
>         at org.jboss.as.jacorb.rmi.ParameterAnalysis.<init>(ParameterAnalysis.java:50)
>    Locked ownable synchronizers:
>         - <0x00000000f9698790> (a java.util.concurrent.ThreadPoolExecutor$Worker)
> {code}
> The last part including {{Util.getTypeIDLName}} has been repeated as many as possible and the bottom of the stack has been lost.  The same stack has been appeared in a different MSC service thread which is also executing an IIOP enabled EJB deployment.
> The customer identified an improper synchronization in {{org.jboss.as.jacorb.rmi.WorkCacheManager#getAnalysis()}}.  It is reproducible by manually controlling a thread context switch using a debugger.

--
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

From issues at jboss.org  Tue Mar 11 18:01:11 2014
From: issues at jboss.org (Bill Burke (JIRA))
Date: Tue, 11 Mar 2014 18:01:11 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3102) EJB in WAR should inherit
 WAR's security domain
In-Reply-To: <JIRA.12534724.1394575248114@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534724.1394575248114@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534724.1394575248114.7827.1394575271561@jira02.app.mwc.hst.phx2.redhat.com>

Bill Burke created WFLY-3102:
--------------------------------

             Summary: EJB in WAR should inherit WAR's security domain
                 Key: WFLY-3102
                 URL: https://issues.jboss.org/browse/WFLY-3102
             Project: WildFly
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: Web (Undertow)
    Affects Versions: 8.0.0.Final
            Reporter: Bill Burke
            Assignee: Stuart Douglas


If you define an EJB within WEB-INF/classes it does not inherit the security domain from the WAR file and defaults to "other".  Counter-intuitive, IMO.  Not sure if it is easily fixable though

--
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

From issues at jboss.org  Tue Mar 11 18:05:10 2014
From: issues at jboss.org (Stuart Douglas (JIRA))
Date: Tue, 11 Mar 2014 18:05:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3102) EJB in WAR should inherit
 WAR's security domain
In-Reply-To: <JIRA.12534724.1394575248000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534724.1394575248000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534724.1394575248000.7840.1394575510572@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-3102?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12952151#comment-12952151 ] 

Stuart Douglas commented on WFLY-3102:
--------------------------------------

The big problem would be that this change would break backwards compatibility, although I am not sure how much of an issue it would be in practice. 

>From a technical point of view this is not a difficult change.
                
> EJB in WAR should inherit WAR's security domain
> -----------------------------------------------
>
>                 Key: WFLY-3102
>                 URL: https://issues.jboss.org/browse/WFLY-3102
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Web (Undertow)
>    Affects Versions: 8.0.0.Final
>            Reporter: Bill Burke
>            Assignee: Stuart Douglas
>
> If you define an EJB within WEB-INF/classes it does not inherit the security domain from the WAR file and defaults to "other".  Counter-intuitive, IMO.  Not sure if it is easily fixable though

--
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

From issues at jboss.org  Tue Mar 11 19:05:10 2014
From: issues at jboss.org (James Perkins (JIRA))
Date: Tue, 11 Mar 2014 19:05:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2004) Formatter "COLOR-PATTERN" is
	not found
In-Reply-To: <JIRA.12500018.1378366639000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500018.1378366639000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500018.1378366639000.7855.1394579110731@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2004?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

James Perkins closed WFLY-2004.
-------------------------------

    Fix Version/s:     (was: 8.0.1.Final)
       Resolution: Cannot Reproduce Bug


I can't seem to reproduce this. If it's still an issue, please reopen.
                
> Formatter "COLOR-PATTERN" is not found
> --------------------------------------
>
>                 Key: WFLY-2004
>                 URL: https://issues.jboss.org/browse/WFLY-2004
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management, Logging
>            Reporter: Heiko Braun
>            Assignee: James Perkins
>         Attachments: domain.xml, host.xml
>
>
> Failed to start a server on a second host:
> {noformat}
> [Host Controller] INFO  [org.jboss.as.host.controller] JBAS010919: Registering server stage1
> [Server:stage1] ERROR [org.jboss.as.controller.management-operation] JBAS014612: Operation ("add") failed - address: ([
> [Server:stage1]     ("subsystem" => "logging"),
> [Server:stage1]     ("console-handler" => "CONSOLE")
> [Server:stage1] ]): java.lang.IllegalArgumentException: Formatter "COLOR-PATTERN" is not found
> [Server:stage1] 	at org.jboss.logmanager.config.HandlerConfigurationImpl$1.validate(HandlerConfigurationImpl.java:83) [jboss-logmanager-1.5.0.Final.jar:1.5.0.Final]
> [Server:stage1] 	at org.jboss.logmanager.config.HandlerConfigurationImpl$1.validate(HandlerConfigurationImpl.java:80) [jboss-logmanager-1.5.0.Final.jar:1.5.0.Final]
> [Server:stage1] 	at org.jboss.logmanager.config.LogContextConfigurationImpl.doPrepare(LogContextConfigurationImpl.java:338) [jboss-logmanager-1.5.0.Final.jar:1.5.0.Final]
> [Server:stage1] 	at org.jboss.logmanager.config.LogContextConfigurationImpl.prepare(LogContextConfigurationImpl.java:291) [jboss-logmanager-1.5.0.Final.jar:1.5.0.Final]
> [Server:stage1] 	at org.jboss.as.logging.logmanager.ConfigurationPersistence.prepare(ConfigurationPersistence.java:303)
> [Server:stage1] 	at org.jboss.as.logging.LoggingOperations$CommitOperationStepHandler.execute(LoggingOperations.java:97)
> [Server:stage1] 	at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:610) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> [Server:stage1] 	at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:488) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> [Server:stage1] 	at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:277) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> [Server:stage1] 	at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:272) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> [Server:stage1] 	at org.jboss.as.controller.ModelControllerImpl.boot(ModelControllerImpl.java:320) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> [Server:stage1] 	at org.jboss.as.controller.AbstractControllerService.boot(AbstractControllerService.java:288) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> [Server:stage1] 	at org.jboss.as.server.ServerService.boot(ServerService.java:356) [wildfly-server-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> {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

From issues at jboss.org  Tue Mar 11 19:55:10 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 11 Mar 2014 19:55:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3099) management authorization
 throws an exception when an LDAP group contains a slash/backslash character
In-Reply-To: <JIRA.12534652.1394538171000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534652.1394538171000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534652.1394538171000.7865.1394582110662@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-3099?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12952156#comment-12952156 ] 

RH Bugzilla Integration commented on WFLY-3099:
-----------------------------------------------

Kabir Khan <kkhan at redhat.com> changed the Status of [bug 1074560|https://bugzilla.redhat.com/show_bug.cgi?id=1074560] from MODIFIED to POST
                
> management authorization throws an exception when an LDAP group contains a slash/backslash character
> ----------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-3099
>                 URL: https://issues.jboss.org/browse/WFLY-3099
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>    Affects Versions: 8.0.0.Final
>            Reporter: Tom Fonteyne
>            Assignee: Tom Fonteyne
>
> management authorization throws an exception when an LDAP group contains a slash/backslash character

--
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

From issues at jboss.org  Tue Mar 11 21:17:10 2014
From: issues at jboss.org (Shelly McGowan (JIRA))
Date: Tue, 11 Mar 2014 21:17:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBEE-150) The jboss-jstl-api_1.2_spec
 artifact depends on xalan artifact that is not present in Maven Central
In-Reply-To: <JIRA.12534656.1394540996000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534656.1394540996000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534656.1394540996000.7879.1394587030847@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JBEE-150?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12952159#comment-12952159 ] 

Shelly McGowan commented on JBEE-150:
-------------------------------------

[~trepel] Does it help your situation if include the Java EE API BOM for full or web profile as the artifcat to your maven project instead of just jboss-jstl-api_1.2_spec.
Full Profile APIs:
https://repository.jboss.org/nexus/content/groups/public/org/jboss/spec/jboss-javaee-7.0/1.0.0.Final/
or Web Profile APIs only:
https://repository.jboss.org/nexus/content/groups/public/org/jboss/spec/jboss-javaee-web-7.0/1.0.0.Final/
I thought I had resolve that problem with exclusions using the BOMS (see also:  JBEE-97, JBEE-112, JBEE-118)
                
> The jboss-jstl-api_1.2_spec artifact depends on xalan artifact that is not present in Maven Central
> ---------------------------------------------------------------------------------------------------
>
>                 Key: JBEE-150
>                 URL: https://issues.jboss.org/browse/JBEE-150
>             Project: JBoss JavaEE Spec APIs
>          Issue Type: Bug
>            Reporter: Tomas Repel
>            Assignee: Shelly McGowan
>
> The org.jboss.spec.javax.servlet.jstl:jboss-jstl-api_1.2_spec:1.1.0.Final depends on xalan:xalan:2.7.1.jbossorg-2 artifact, this one is not present in Maven Central.

--
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

From issues at jboss.org  Tue Mar 11 21:17:10 2014
From: issues at jboss.org (Shelly McGowan (JIRA))
Date: Tue, 11 Mar 2014 21:17:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBEE-150) The jboss-jstl-api_1.2_spec
 artifact depends on xalan artifact that is not present in Maven Central
In-Reply-To: <JIRA.12534656.1394540996000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534656.1394540996000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534656.1394540996000.7882.1394587030995@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JBEE-150?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12952159#comment-12952159 ] 

Shelly McGowan edited comment on JBEE-150 at 3/11/14 9:16 PM:
--------------------------------------------------------------

[~trepel] Does it help your situation if include the Java EE API BOM for full or web profile as the artifact to your maven project instead of just jboss-jstl-api_1.2_spec.
Full Profile APIs:
https://repository.jboss.org/nexus/content/groups/public/org/jboss/spec/jboss-javaee-7.0/1.0.0.Final/
or Web Profile APIs only:
https://repository.jboss.org/nexus/content/groups/public/org/jboss/spec/jboss-javaee-web-7.0/1.0.0.Final/
I thought I had resolve that problem with exclusions using the BOMS (see also:  JBEE-97, JBEE-112, JBEE-118)
                
      was (Author: shelly.mcgowan):
    [~trepel] Does it help your situation if include the Java EE API BOM for full or web profile as the artifcat to your maven project instead of just jboss-jstl-api_1.2_spec.
Full Profile APIs:
https://repository.jboss.org/nexus/content/groups/public/org/jboss/spec/jboss-javaee-7.0/1.0.0.Final/
or Web Profile APIs only:
https://repository.jboss.org/nexus/content/groups/public/org/jboss/spec/jboss-javaee-web-7.0/1.0.0.Final/
I thought I had resolve that problem with exclusions using the BOMS (see also:  JBEE-97, JBEE-112, JBEE-118)
                  
> The jboss-jstl-api_1.2_spec artifact depends on xalan artifact that is not present in Maven Central
> ---------------------------------------------------------------------------------------------------
>
>                 Key: JBEE-150
>                 URL: https://issues.jboss.org/browse/JBEE-150
>             Project: JBoss JavaEE Spec APIs
>          Issue Type: Bug
>            Reporter: Tomas Repel
>            Assignee: Shelly McGowan
>
> The org.jboss.spec.javax.servlet.jstl:jboss-jstl-api_1.2_spec:1.1.0.Final depends on xalan:xalan:2.7.1.jbossorg-2 artifact, this one is not present in Maven Central.

--
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

From issues at jboss.org  Tue Mar 11 23:09:10 2014
From: issues at jboss.org (San chi (JIRA))
Date: Tue, 11 Mar 2014 23:09:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (AS7-5645) Jboss 7.0.2, 7.1 does not call
 ServletContextListener.contextDestroyed(ServletContextEvent event) on
 shutdown.
In-Reply-To: <JIRA.12475617.1348748148000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12475617.1348748148000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12475617.1348748148000.7939.1394593750570@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/AS7-5645?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12952167#comment-12952167 ] 

San chi commented on AS7-5645:
------------------------------

I am seeing the same exact issue of contextDestroyd not being called on Windows (64 bit) with JBoss 7.1.1 Final version.  Is there a workaround for this issue? 
                
> Jboss 7.0.2, 7.1 does not call ServletContextListener.contextDestroyed(ServletContextEvent event) on shutdown.
> --------------------------------------------------------------------------------------------------------------
>
>                 Key: AS7-5645
>                 URL: https://issues.jboss.org/browse/AS7-5645
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Server
>    Affects Versions: 7.0.2.Final, 7.1.0.Final, 7.1.1.Final
>         Environment: Windows 7 64 bit
>            Reporter: Alexey Alexey
>            Assignee: Jason Greene
>              Labels: ServletContext, Servlet_Context
>
> Jboss 7.0.2, 7.1 (standalone) does not call ServletContextListener .contextDestroyed(ServletContextEvent event) on shutdown. Shutdown was performed with Ctrl^C and also with command 
> jboss-admin.bat --connect command=:shutdown
> I had the same result - jboss does not call destroying.
> This listener was successfully initialized on startup with ServletContextListener.contextInitialized(ServletContextEvent event).
> This listener is registered in web.xml in standart way:
> <?xml version="1.0" encoding="UTF-8"?>
> <web-app id="WebApp_ID" version="2.4"
> 		xmlns="http://java.sun.com/xml/ns/j2ee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> 		xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd">
> ....
> <listener>
> 		<listener-class>Full_classname_of_listener</listener-class>
> 	</listener>
> </web-app>

--
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

From issues at jboss.org  Tue Mar 11 23:13:10 2014
From: issues at jboss.org (San chi (JIRA))
Date: Tue, 11 Mar 2014 23:13:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (AS7-5645) Jboss 7.0.2, 7.1 does not call
 ServletContextListener.contextDestroyed(ServletContextEvent event) on
 shutdown.
In-Reply-To: <JIRA.12475617.1348748148000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12475617.1348748148000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12475617.1348748148000.7945.1394593990755@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/AS7-5645?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12952167#comment-12952167 ] 

San chi edited comment on AS7-5645 at 3/11/14 11:12 PM:
--------------------------------------------------------

Alex,
I am seeing the same exact issue of contextDestroyed not being called on Windows (64 bit) with JBoss 7.1.1 Final version.  Is there a workaround for this issue? 
Alexey,
How did you resolve it? Why do you say it is not a Jboss issue? 
                
      was (Author: chinivar):
    I am seeing the same exact issue of contextDestroyd not being called on Windows (64 bit) with JBoss 7.1.1 Final version.  Is there a workaround for this issue? 
                  
> Jboss 7.0.2, 7.1 does not call ServletContextListener.contextDestroyed(ServletContextEvent event) on shutdown.
> --------------------------------------------------------------------------------------------------------------
>
>                 Key: AS7-5645
>                 URL: https://issues.jboss.org/browse/AS7-5645
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Server
>    Affects Versions: 7.0.2.Final, 7.1.0.Final, 7.1.1.Final
>         Environment: Windows 7 64 bit
>            Reporter: Alexey Alexey
>            Assignee: Jason Greene
>              Labels: ServletContext, Servlet_Context
>
> Jboss 7.0.2, 7.1 (standalone) does not call ServletContextListener .contextDestroyed(ServletContextEvent event) on shutdown. Shutdown was performed with Ctrl^C and also with command 
> jboss-admin.bat --connect command=:shutdown
> I had the same result - jboss does not call destroying.
> This listener was successfully initialized on startup with ServletContextListener.contextInitialized(ServletContextEvent event).
> This listener is registered in web.xml in standart way:
> <?xml version="1.0" encoding="UTF-8"?>
> <web-app id="WebApp_ID" version="2.4"
> 		xmlns="http://java.sun.com/xml/ns/j2ee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> 		xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd">
> ....
> <listener>
> 		<listener-class>Full_classname_of_listener</listener-class>
> 	</listener>
> </web-app>

--
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

From issues at jboss.org  Tue Mar 11 23:13:11 2014
From: issues at jboss.org (San chi (JIRA))
Date: Tue, 11 Mar 2014 23:13:11 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (AS7-5645) Jboss 7.0.2, 7.1 does not call
 ServletContextListener.contextDestroyed(ServletContextEvent event) on
 shutdown.
In-Reply-To: <JIRA.12475617.1348748148000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12475617.1348748148000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12475617.1348748148000.7951.1394593991081@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/AS7-5645?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12952167#comment-12952167 ] 

San chi edited comment on AS7-5645 at 3/11/14 11:12 PM:
--------------------------------------------------------

I am seeing the same exact issue of contextDestroyed not being called on Windows (64 bit) with JBoss 7.1.1 Final version.  Is there a workaround for this issue? 
Alexey,
How did you resolve it? Why do you say it is not a Jboss issue? 
                
      was (Author: chinivar):
    Alex,
I am seeing the same exact issue of contextDestroyed not being called on Windows (64 bit) with JBoss 7.1.1 Final version.  Is there a workaround for this issue? 
Alexey,
How did you resolve it? Why do you say it is not a Jboss issue? 
                  
> Jboss 7.0.2, 7.1 does not call ServletContextListener.contextDestroyed(ServletContextEvent event) on shutdown.
> --------------------------------------------------------------------------------------------------------------
>
>                 Key: AS7-5645
>                 URL: https://issues.jboss.org/browse/AS7-5645
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Server
>    Affects Versions: 7.0.2.Final, 7.1.0.Final, 7.1.1.Final
>         Environment: Windows 7 64 bit
>            Reporter: Alexey Alexey
>            Assignee: Jason Greene
>              Labels: ServletContext, Servlet_Context
>
> Jboss 7.0.2, 7.1 (standalone) does not call ServletContextListener .contextDestroyed(ServletContextEvent event) on shutdown. Shutdown was performed with Ctrl^C and also with command 
> jboss-admin.bat --connect command=:shutdown
> I had the same result - jboss does not call destroying.
> This listener was successfully initialized on startup with ServletContextListener.contextInitialized(ServletContextEvent event).
> This listener is registered in web.xml in standart way:
> <?xml version="1.0" encoding="UTF-8"?>
> <web-app id="WebApp_ID" version="2.4"
> 		xmlns="http://java.sun.com/xml/ns/j2ee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> 		xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd">
> ....
> <listener>
> 		<listener-class>Full_classname_of_listener</listener-class>
> 	</listener>
> </web-app>

--
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

From issues at jboss.org  Wed Mar 12 00:25:10 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 12 Mar 2014 00:25:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3100) ClassCastException in JSPs
 where spring-web tags and jstl tags are used
In-Reply-To: <JIRA.12534665.1394544099000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534665.1394544099000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534665.1394544099000.7977.1394598310754@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-3100?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated WFLY-3100:
------------------------------------------

        Bugzilla Update: Perform
    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1075353

    
> ClassCastException in JSPs where spring-web tags and jstl tags are used
> -----------------------------------------------------------------------
>
>                 Key: WFLY-3100
>                 URL: https://issues.jboss.org/browse/WFLY-3100
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: EE, Web (Undertow)
>    Affects Versions: 8.0.0.Final
>            Reporter: abhishek vijra
>            Assignee: Remy Maucherat
>              Labels: jsp, jstl
>         Attachments: spring-fun.war
>
>
> Following JSP with spring tags 
> <%@ page contentType="text/html;charset=UTF-8" language="java" %>
> <%@ taglib prefix="c" uri="http://java.sun.com/jstl/core" %>
> <%@ taglib prefix="spring" uri="http://www.springframework.org/tags" %>
> <html>
>   <head><title>Simple jsp page</title></head>
>   <body>
>   
>   <c:set var="hasError" value="${param.hasError}" />
>   <c:set var="msg" value="${param.msg}" />
>   
>   <c:if test="${param.hasError=='true'}">
>     Message: <spring:message text="${param.msg}"/>
>   </c:if>
>   
>   </body>
> </html>
> breaks following error 
>  ERROR [org.springframework.web.servlet.tags.MessageTag] (default task-1) org.apache.taglibs.standard.lang.jstl.ImplicitObjects cannot be cast to javax.servlet.jsp.el.ImplicitObjectELResolver$ImplicitObjects: java.lang.ClassCastException: org.apache.taglibs.standard.lang.jstl.ImplicitObjects cannot be cast to javax.servlet.jsp.el.ImplicitObjectELResolver$ImplicitObjects
> 	at javax.servlet.jsp.el.ImplicitObjectELResolver$ImplicitObjects.getImplicitObjects(ImplicitObjectELResolver.java:608) [jboss-jsp-api_2.3_spec-1.0.0.Final.jar:1.0.0.Final]
> 	at javax.servlet.jsp.el.ImplicitObjectELResolver.getValue(ImplicitObjectELResolver.java:169) [jboss-jsp-api_2.3_spec-1.0.0.Final.jar:1.0.0.Final]
> 	at org.apache.jasper.el.JasperELResolver.getValue(JasperELResolver.java:95) [jastow-1.0.0.Final.jar:1.0.0.Final]
> 	at org.apache.jasper.el.VariableResolverImpl.resolveVariable(VariableResolverImpl.java:32) [jastow-1.0.0.Final.jar:1.0.0.Final]
> 	at org.apache.jasper.el.ELResolverImpl.getValue(ELResolverImpl.java:78) [jastow-1.0.0.Final.jar:1.0.0.Final]
> 	at com.sun.el.parser.AstIdentifier.getValue(AstIdentifier.java:116) [javax.el-3.0.0.jar:3.0.0]
> 	at com.sun.el.parser.AstValue.getBase(AstValue.java:151) [javax.el-3.0.0.jar:3.0.0]
> 	at com.sun.el.parser.AstValue.getValue(AstValue.java:200) [javax.el-3.0.0.jar:3.0.0]
> There are two jars (jboss-jsp-api_2.3_spec-1.0.0.Final.jar and jboss-jstl-api_1.2_spec-1.0.4.Final.jar) that are incompatible with each other due to a bug -- both are storing an object in the same place, but the objects are not compatible.
> The result is that a jsp page cannot contain both JSTL and Spring tags, or it will get that error.

--
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

From issues at jboss.org  Wed Mar 12 01:55:10 2014
From: issues at jboss.org (Bela Ban (JIRA))
Date: Wed, 12 Mar 2014 01:55:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1807) UNICAST: skipping of seqnos
In-Reply-To: <JIRA.12534731.1394603645595@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534731.1394603645595@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534731.1394603645595.7983.1394603710672@jira02.app.mwc.hst.phx2.redhat.com>

Bela Ban created JGRP-1807:
------------------------------

             Summary: UNICAST: skipping of seqnos
                 Key: JGRP-1807
                 URL: https://issues.jboss.org/browse/JGRP-1807
             Project: JGroups
          Issue Type: Bug
            Reporter: Bela Ban
            Assignee: Bela Ban
             Fix For: 3.2.13, 3.5


{noformat}
The log starts with:
10-Mar-2014 13:21:47 WARN  [org.jgroups.protocols.UNICAST2] (OOB-105,shared=tcp) AS_DR_IBE03/web: (requester=AS_DR_IBE06/web) message AS_DR_IBE06/web::1511786 not found in retransmission table of AS_DR_IBE06/web:
[1511785 | 1511785 | 1511857] (53 elements, 19 missing)

The numbers are 1511786-1511804  for "not found in retransmission...."

And end:
10-Mar-2014 14:48:26 WARN  [org.jgroups.protocols.UNICAST2] (OOB-118,shared=tcp) AS_DR_IBE03/web: (requester=AS_DR_IBE06/web) message AS_DR_IBE06/web::1511804 not found in retransmission table of AS_DR_IBE06/web:
[1511785 | 1511785 | 1514802] (2998 elements, 19 missing) 
{noformat}

It seems that 03  is missing messages 1511785-1511804 which it sent to 06. Since a null message cannot be added to the sender table (due to the {{msg.isFlagSet()}} which would throw an NPE), I asume we're skipping a seqno:

In {{UNICAST}}, {{UNICAST2}} and {{UNICAST3}} {{down()}}, if a seqno is skipped, we get endless retransmissions. Example: 
* We get the next seqno 1, add the message to the table and send it
* We get the next seqno 2. However, if {{running}} is false, we don't add the message
* We get the next seqno 3. Now {{running}} is true, and we add 3 to the table
--> Now we have a missing message 2 which will always be null as it hasn't been added to the table

This is highly unlikely, as I haven't been able to find a scenario where running flips from true to false to true quickly. If it flips from true to false, this is because {{stop()}} has been called. Also, in {{down()}}, we actually check {{running}} and return if false.
In this scenario, the connections are all removed, so seqno is reset to 1.
Anyway, I'm going to replace the {{while(running)}} loop with a {{do while(running)}} loop, so we always add the message to the table, even if running=false.

[1] https://github.com/belaban/JGroups/blob/Branch_JGroups_3_2/src/org/jgroups/protocols/UNICAST2.java#L490

--
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

From issues at jboss.org  Wed Mar 12 02:17:10 2014
From: issues at jboss.org (Bela Ban (JIRA))
Date: Wed, 12 Mar 2014 02:17:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1807) UNICAST: skipping of seqnos
In-Reply-To: <JIRA.12534731.1394603645000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534731.1394603645000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534731.1394603645000.7989.1394605030548@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JGRP-1807?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12952170#comment-12952170 ] 

Bela Ban commented on JGRP-1807:
--------------------------------

Same change for NAKACK2
                
> UNICAST: skipping of seqnos
> ---------------------------
>
>                 Key: JGRP-1807
>                 URL: https://issues.jboss.org/browse/JGRP-1807
>             Project: JGroups
>          Issue Type: Bug
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 3.2.13, 3.5
>
>
> {noformat}
> The log starts with:
> 10-Mar-2014 13:21:47 WARN  [org.jgroups.protocols.UNICAST2] (OOB-105,shared=tcp) AS_DR_IBE03/web: (requester=AS_DR_IBE06/web) message AS_DR_IBE06/web::1511786 not found in retransmission table of AS_DR_IBE06/web:
> [1511785 | 1511785 | 1511857] (53 elements, 19 missing)
> The numbers are 1511786-1511804  for "not found in retransmission...."
> And end:
> 10-Mar-2014 14:48:26 WARN  [org.jgroups.protocols.UNICAST2] (OOB-118,shared=tcp) AS_DR_IBE03/web: (requester=AS_DR_IBE06/web) message AS_DR_IBE06/web::1511804 not found in retransmission table of AS_DR_IBE06/web:
> [1511785 | 1511785 | 1514802] (2998 elements, 19 missing) 
> {noformat}
> It seems that 03  is missing messages 1511785-1511804 which it sent to 06. Since a null message cannot be added to the sender table (due to the {{msg.isFlagSet()}} which would throw an NPE), I asume we're skipping a seqno:
> In {{UNICAST}}, {{UNICAST2}} and {{UNICAST3}} {{down()}}, if a seqno is skipped, we get endless retransmissions. Example: 
> * We get the next seqno 1, add the message to the table and send it
> * We get the next seqno 2. However, if {{running}} is false, we don't add the message
> * We get the next seqno 3. Now {{running}} is true, and we add 3 to the table
> --> Now we have a missing message 2 which will always be null as it hasn't been added to the table
> This is highly unlikely, as I haven't been able to find a scenario where running flips from true to false to true quickly. If it flips from true to false, this is because {{stop()}} has been called. Also, in {{down()}}, we actually check {{running}} and return if false.
> In this scenario, the connections are all removed, so seqno is reset to 1.
> Anyway, I'm going to replace the {{while(running)}} loop with a {{do while(running)}} loop, so we always add the message to the table, even if running=false.
> [1] https://github.com/belaban/JGroups/blob/Branch_JGroups_3_2/src/org/jgroups/protocols/UNICAST2.java#L490

--
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

From issues at jboss.org  Wed Mar 12 03:57:10 2014
From: issues at jboss.org (Elis Edlund (JIRA))
Date: Wed, 12 Mar 2014 03:57:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JASSIST-219) Generic signature is lost
 after using ProxyFactory to enchant another class.
In-Reply-To: <JIRA.12534732.1394610938889@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534732.1394610938889@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534732.1394610938889.8026.1394611030605@jira02.app.mwc.hst.phx2.redhat.com>

Elis Edlund created JASSIST-219:
-----------------------------------

             Summary: Generic signature is lost after using ProxyFactory to enchant another class.
                 Key: JASSIST-219
                 URL: https://issues.jboss.org/browse/JASSIST-219
             Project: Javassist
          Issue Type: Bug
    Affects Versions: 3.18.1-GA, 3.18.0-GA, 3.17.1-GA, 3.16.1-GA
         Environment: Windows 7 
java 1.5    1.6     1.7
            Reporter: Elis Edlund
            Assignee: Shigeru Chiba


Its not possible to get any generic information out of a  class that have been 'enchanted' with ProxyFactory.

example output before and after an 'enchantment' (produced with method.toGenericString())
------Enchant Object------
stringMethod sigature enchantedObject: public final java.util.List IssueMissingGenericTypeInfoForEnchantedClassTest$MyObject_$$_javassist_0.getStringList()
numberMethod sigature enchantedObject: public final java.util.List IssueMissingGenericTypeInfoForEnchantedClassTest$MyObject_$$_javassist_0.getNumberList()
stringMethod sigature myObject       : public java.util.List<java.lang.String> IssueMissingGenericTypeInfoForEnchantedClassTest$MyObject.getStringList()
numberMethod sigature myObject       : public java.util.List<? extends java.lang.Number> IssueMissingGenericTypeInfoForEnchantedClassTest$MyObject.getNumberList()
------Enchant Interface------
stringMethod sigature enchantedInterface: public final java.util.List IssueMissingGenericTypeInfoForEnchantedClassTest$MyInterface_$$_javassist_1.getStringList()
numberMethod sigature enchantedInterface: public final java.util.List IssueMissingGenericTypeInfoForEnchantedClassTest$MyInterface_$$_javassist_1.getNumberList()
stringMethod sigature myInterface       : public abstract java.util.List<java.lang.String> IssueMissingGenericTypeInfoForEnchantedClassTest$MyInterface.getStringList()
numberMethod sigature myInterface       : public abstract java.util.List<? extends java.lang.Number> IssueMissingGenericTypeInfoForEnchantedClassTest$MyInterface.getNumberList()

--
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

From issues at jboss.org  Wed Mar 12 03:59:10 2014
From: issues at jboss.org (Elis Edlund (JIRA))
Date: Wed, 12 Mar 2014 03:59:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JASSIST-219) Generic signature is lost
 after using ProxyFactory to enchant another class.
In-Reply-To: <JIRA.12534732.1394610938000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534732.1394610938000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534732.1394610938000.8029.1394611150604@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JASSIST-219?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Elis Edlund updated JASSIST-219:
--------------------------------

    Attachment: IssueMissingGenericTypeInfoForEnchantedClassTest.java


really simple class to reproduce the problem.
                
> Generic signature is lost after using ProxyFactory to enchant another class.
> ----------------------------------------------------------------------------
>
>                 Key: JASSIST-219
>                 URL: https://issues.jboss.org/browse/JASSIST-219
>             Project: Javassist
>          Issue Type: Bug
>    Affects Versions: 3.16.1-GA, 3.17.1-GA, 3.18.0-GA, 3.18.1-GA
>         Environment: Windows 7 
> java 1.5    1.6     1.7
>            Reporter: Elis Edlund
>            Assignee: Shigeru Chiba
>              Labels: generics, missing
>         Attachments: IssueMissingGenericTypeInfoForEnchantedClassTest.java
>
>
> Its not possible to get any generic information out of a  class that have been 'enchanted' with ProxyFactory.
> example output before and after an 'enchantment' (produced with method.toGenericString())
> ------Enchant Object------
> stringMethod sigature enchantedObject: public final java.util.List IssueMissingGenericTypeInfoForEnchantedClassTest$MyObject_$$_javassist_0.getStringList()
> numberMethod sigature enchantedObject: public final java.util.List IssueMissingGenericTypeInfoForEnchantedClassTest$MyObject_$$_javassist_0.getNumberList()
> stringMethod sigature myObject       : public java.util.List<java.lang.String> IssueMissingGenericTypeInfoForEnchantedClassTest$MyObject.getStringList()
> numberMethod sigature myObject       : public java.util.List<? extends java.lang.Number> IssueMissingGenericTypeInfoForEnchantedClassTest$MyObject.getNumberList()
> ------Enchant Interface------
> stringMethod sigature enchantedInterface: public final java.util.List IssueMissingGenericTypeInfoForEnchantedClassTest$MyInterface_$$_javassist_1.getStringList()
> numberMethod sigature enchantedInterface: public final java.util.List IssueMissingGenericTypeInfoForEnchantedClassTest$MyInterface_$$_javassist_1.getNumberList()
> stringMethod sigature myInterface       : public abstract java.util.List<java.lang.String> IssueMissingGenericTypeInfoForEnchantedClassTest$MyInterface.getStringList()
> numberMethod sigature myInterface       : public abstract java.util.List<? extends java.lang.Number> IssueMissingGenericTypeInfoForEnchantedClassTest$MyInterface.getNumberList()

--
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

From issues at jboss.org  Wed Mar 12 04:27:10 2014
From: issues at jboss.org (Bela Ban (JIRA))
Date: Wed, 12 Mar 2014 04:27:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1792) "No buffer space available"
 when sending on Mac OS
In-Reply-To: <JIRA.12532823.1392906372000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12532823.1392906372000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12532823.1392906372000.8039.1394612830603@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JGRP-1792?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban resolved JGRP-1792.
----------------------------

    Resolution: Done


Doesn't occur anymore with JGRP-1765 in place, probably because we now use the DatagramSocket to send multicasts, not the MulticastSocket.
                
> "No buffer space available" when sending on Mac OS
> --------------------------------------------------
>
>                 Key: JGRP-1792
>                 URL: https://issues.jboss.org/browse/JGRP-1792
>             Project: JGroups
>          Issue Type: Bug
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>            Priority: Minor
>             Fix For: 3.5
>
>
> When sending multicast messages (with MPerf & fast.xml), the following message appears:
> {noformat}
> 8981 [ERROR] UDP: JGRP000029: A: failed sending message to cluster (1053 bytes): java.io.IOException: No buffer space available, 
> headers: MPerf: DATA999, NAKACK2: [MSG, seqno=1003], UDP: [cluster_name=mperf]
> {noformat}
> The messages *are* received, but the error message occurs on almost every message (1 sender thread sending 1000 messages).
> With {{UdpPerf}} (also shipped with JGroups), which also multicasts messages, the error doesn't happen.
> With {{UPerf}}, which uses unicasts, the error doesn't occur either.
> Todo: compare UdpPerf to MPerf (UDP protocol) to see what the diff is.

--
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

From issues at jboss.org  Wed Mar 12 04:29:10 2014
From: issues at jboss.org (Tomas Repel (JIRA))
Date: Wed, 12 Mar 2014 04:29:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBEE-150) The jboss-jstl-api_1.2_spec
 artifact depends on xalan artifact that is not present in Maven Central
In-Reply-To: <JIRA.12534656.1394540996000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534656.1394540996000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534656.1394540996000.8041.1394612950581@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JBEE-150?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12952181#comment-12952181 ] 

Tomas Repel commented on JBEE-150:
----------------------------------

[~shelly.mcgowan] Thanks for pointing me to that issues. Using that BOMs will probably help (I didn't try), but still if we push something to Maven Central, that something should depend on stuff that is available on Maven Central as well. But this issue is clearly duplicate of https://issues.jboss.org/browse/JBEE-118 (sorry for that, I haven't noticed), you can mark it so.
                
> The jboss-jstl-api_1.2_spec artifact depends on xalan artifact that is not present in Maven Central
> ---------------------------------------------------------------------------------------------------
>
>                 Key: JBEE-150
>                 URL: https://issues.jboss.org/browse/JBEE-150
>             Project: JBoss JavaEE Spec APIs
>          Issue Type: Bug
>            Reporter: Tomas Repel
>            Assignee: Shelly McGowan
>
> The org.jboss.spec.javax.servlet.jstl:jboss-jstl-api_1.2_spec:1.1.0.Final depends on xalan:xalan:2.7.1.jbossorg-2 artifact, this one is not present in Maven Central.

--
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

From issues at jboss.org  Wed Mar 12 04:31:10 2014
From: issues at jboss.org (Bela Ban (JIRA))
Date: Wed, 12 Mar 2014 04:31:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1807) UNICAST: skipping of seqnos
In-Reply-To: <JIRA.12534731.1394603645000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534731.1394603645000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534731.1394603645000.8045.1394613070589@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JGRP-1807?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban resolved JGRP-1807.
----------------------------

    Resolution: Done

    
> UNICAST: skipping of seqnos
> ---------------------------
>
>                 Key: JGRP-1807
>                 URL: https://issues.jboss.org/browse/JGRP-1807
>             Project: JGroups
>          Issue Type: Bug
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 3.2.13, 3.5
>
>
> {noformat}
> The log starts with:
> 10-Mar-2014 13:21:47 WARN  [org.jgroups.protocols.UNICAST2] (OOB-105,shared=tcp) AS_DR_IBE03/web: (requester=AS_DR_IBE06/web) message AS_DR_IBE06/web::1511786 not found in retransmission table of AS_DR_IBE06/web:
> [1511785 | 1511785 | 1511857] (53 elements, 19 missing)
> The numbers are 1511786-1511804  for "not found in retransmission...."
> And end:
> 10-Mar-2014 14:48:26 WARN  [org.jgroups.protocols.UNICAST2] (OOB-118,shared=tcp) AS_DR_IBE03/web: (requester=AS_DR_IBE06/web) message AS_DR_IBE06/web::1511804 not found in retransmission table of AS_DR_IBE06/web:
> [1511785 | 1511785 | 1514802] (2998 elements, 19 missing) 
> {noformat}
> It seems that 03  is missing messages 1511785-1511804 which it sent to 06. Since a null message cannot be added to the sender table (due to the {{msg.isFlagSet()}} which would throw an NPE), I asume we're skipping a seqno:
> In {{UNICAST}}, {{UNICAST2}} and {{UNICAST3}} {{down()}}, if a seqno is skipped, we get endless retransmissions. Example: 
> * We get the next seqno 1, add the message to the table and send it
> * We get the next seqno 2. However, if {{running}} is false, we don't add the message
> * We get the next seqno 3. Now {{running}} is true, and we add 3 to the table
> --> Now we have a missing message 2 which will always be null as it hasn't been added to the table
> This is highly unlikely, as I haven't been able to find a scenario where running flips from true to false to true quickly. If it flips from true to false, this is because {{stop()}} has been called. Also, in {{down()}}, we actually check {{running}} and return if false.
> In this scenario, the connections are all removed, so seqno is reset to 1.
> Anyway, I'm going to replace the {{while(running)}} loop with a {{do while(running)}} loop, so we always add the message to the table, even if running=false.
> [1] https://github.com/belaban/JGroups/blob/Branch_JGroups_3_2/src/org/jgroups/protocols/UNICAST2.java#L490

--
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

From issues at jboss.org  Wed Mar 12 04:37:10 2014
From: issues at jboss.org (Bela Ban (JIRA))
Date: Wed, 12 Mar 2014 04:37:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1808) Mac OS: no multicast route
	for 127.0.0.1
In-Reply-To: <JIRA.12534736.1394613370883@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534736.1394613370883@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534736.1394613370883.8051.1394613430643@jira02.app.mwc.hst.phx2.redhat.com>

Bela Ban created JGRP-1808:
------------------------------

             Summary: Mac OS: no multicast route for 127.0.0.1
                 Key: JGRP-1808
                 URL: https://issues.jboss.org/browse/JGRP-1808
             Project: JGroups
          Issue Type: Task
            Reporter: Bela Ban
            Assignee: Bela Ban
             Fix For: 3.5


On Mac OS (Mavericks), there is no multicast route in the routing table. So the default route is used (say 192.168.1.1). However, this doesn't work for nodes bound to 127.0.0.1 (don't know why).
So for loopback, an mcast route has to be added, e.g.
{noformat}
sudo route add -net 224.0.0.0/4 127.0.0.1
{noformat}
This adds a default route to all class D (multicast) addresses via loopback. However, this doesn't work if the node is bound to 192.168.1.x !
TODO:
* See if we can get a default multicast route through 192.168.1.1 and make nodes bound to 127.0.0.1 use it
* If this doesn't work, define multiple mcast routes for different mcast addresses, e.g.
{noformat}
sudo route add -net 224.0.0.0/4 127.0.0.1
sudo route add -net 230.0.0.0/8 192.168.1.0
{noformat}
This adds loopback as default mcast route, but uses en0 if a multicast address starts with 230.x.x.x.

--
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

From issues at jboss.org  Wed Mar 12 04:37:10 2014
From: issues at jboss.org (Bela Ban (JIRA))
Date: Wed, 12 Mar 2014 04:37:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1808) Mac OS: no multicast route
	for 127.0.0.1
In-Reply-To: <JIRA.12534736.1394613370000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534736.1394613370000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534736.1394613370000.8053.1394613430831@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JGRP-1808?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban updated JGRP-1808:
---------------------------

    Priority: Minor  (was: Major)

    
> Mac OS: no multicast route for 127.0.0.1
> ----------------------------------------
>
>                 Key: JGRP-1808
>                 URL: https://issues.jboss.org/browse/JGRP-1808
>             Project: JGroups
>          Issue Type: Task
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>            Priority: Minor
>             Fix For: 3.5
>
>
> On Mac OS (Mavericks), there is no multicast route in the routing table. So the default route is used (say 192.168.1.1). However, this doesn't work for nodes bound to 127.0.0.1 (don't know why).
> So for loopback, an mcast route has to be added, e.g.
> {noformat}
> sudo route add -net 224.0.0.0/4 127.0.0.1
> {noformat}
> This adds a default route to all class D (multicast) addresses via loopback. However, this doesn't work if the node is bound to 192.168.1.x !
> TODO:
> * See if we can get a default multicast route through 192.168.1.1 and make nodes bound to 127.0.0.1 use it
> * If this doesn't work, define multiple mcast routes for different mcast addresses, e.g.
> {noformat}
> sudo route add -net 224.0.0.0/4 127.0.0.1
> sudo route add -net 230.0.0.0/8 192.168.1.0
> {noformat}
> This adds loopback as default mcast route, but uses en0 if a multicast address starts with 230.x.x.x.

--
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

From issues at jboss.org  Wed Mar 12 05:27:11 2014
From: issues at jboss.org (Davide Sottara (JIRA))
Date: Wed, 12 Mar 2014 05:27:11 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-449) Does not download the
 artifacts with Firefox.
In-Reply-To: <JIRA.12534660.1394542779000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534660.1394542779000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534660.1394542779000.8177.1394616431346@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/DROOLS-449?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12952202#comment-12952202 ] 

Davide Sottara commented on DROOLS-449:
---------------------------------------

Could you please specify which artifact(s) and which repository?
Thanks

                
> Does not download the artifacts with Firefox. 
> ----------------------------------------------
>
>                 Key: DROOLS-449
>                 URL: https://issues.jboss.org/browse/DROOLS-449
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 6.0.1.Final, 6.1.0.Beta1
>         Environment: Windows 7 Professional 64 bits
> JDK 1.7.45
> Firefox 25.0.1
>            Reporter: Rog?rio Disciolli
>            Assignee: Mark Proctor
>              Labels: Firefox, artifact, download
>
> When try download an Artifact from repository with browser Firefox nothing does.

--
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


From issues at jboss.org  Wed Mar 12 05:31:10 2014
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Wed, 12 Mar 2014 05:31:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2972) Load vault impls from modules
 other than org.jboss.security
In-Reply-To: <JIRA.12532742.1392846992000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12532742.1392846992000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12532742.1392846992000.8189.1394616670559@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2972?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry resolved WFLY-2972.
------------------------------------

    Resolution: Duplicate Issue

    
> Load vault impls from modules other than org.jboss.security
> -----------------------------------------------------------
>
>                 Key: WFLY-2972
>                 URL: https://issues.jboss.org/browse/WFLY-2972
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Security
>    Affects Versions: 8.0.0.Final
>            Reporter: Brian Stansberry
>            Assignee: Anil Saldhana
>
> The vault resources in our management model have a "code" attribute that specifies the classname of a custom Vault impl. But there is no "module" attribute to specify the name of the module to load that class from. This means users would have to modify the org.jboss.security module's module.xml to statically declare their module as a dependency.
> There should be a "module" attribute and org.jboss.security.vault.SecurityVaultFactory should expose a "get" variant that takes a ClassLoader so the appropriate module classloader can be used.
> I only looked at the core model but I suspect the security subsystem has the same issue.

--
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

From issues at jboss.org  Wed Mar 12 05:39:10 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 12 Mar 2014 05:39:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2644) Java heap space exceeded
 looping connect/disconnect cycle
In-Reply-To: <JIRA.12527822.1386863108000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12527822.1386863108000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12527822.1386863108000.8205.1394617150776@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2644?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12952206#comment-12952206 ] 

RH Bugzilla Integration commented on WFLY-2644:
-----------------------------------------------

Kabir Khan <kkhan at redhat.com> changed the Status of [bug 1037574|https://bugzilla.redhat.com/show_bug.cgi?id=1037574] from NEW to POST
                
> Java heap space exceeded looping connect/disconnect cycle
> ---------------------------------------------------------
>
>                 Key: WFLY-2644
>                 URL: https://issues.jboss.org/browse/WFLY-2644
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: CLI
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Alexey Loubyansky
>            Assignee: Alexey Loubyansky
>             Fix For: 8.0.0.Final
>
>
> CLIModelControllerClient implementation is not cleaning up something related to connection handling which leads to OOME repeating a cycle of ensureConnected(...) and close(). On my laptop it happens after around 1400 iterations.

--
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

From issues at jboss.org  Wed Mar 12 05:59:11 2014
From: issues at jboss.org (Jim Ma (JIRA))
Date: Wed, 12 Mar 2014 05:59:11 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3067) Webservices DUP is not
 scanning all visible classes for @WebService annotation
In-Reply-To: <JIRA.12534077.1393987223000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534077.1393987223000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534077.1393987223000.8267.1394618351114@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-3067?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jim Ma reassigned WFLY-3067:
----------------------------

    Assignee: Jim Ma  (was: Alessio Soldano)

    
> Webservices DUP is not scanning all visible classes for @WebService annotation
> ------------------------------------------------------------------------------
>
>                 Key: WFLY-3067
>                 URL: https://issues.jboss.org/browse/WFLY-3067
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web Services
>    Affects Versions: 8.0.0.Final
>            Reporter: Kyle Lape
>            Assignee: Jim Ma
>             Fix For: 8.0.1.Final
>
>
> Sample use case:  You have a .war in an .ear, and the .war has a web.xml with a {{<servlet-class>}} that refers to a JAX-WS endpoint, so the class is annotated with {{@WebService}}.  If that class is packaged in a jar found in the ear's lib directory, the JBossWS DUP won't pick it up, and then Undertow will throw an error like this:
> {noformat}
> UT010009: Servlet ClientEndpoint of type class com.redhat.gss.jaxws.ClientEndpoint does not implement javax.servlet.Servlet
> {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

From issues at jboss.org  Wed Mar 12 06:07:10 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 12 Mar 2014 06:07:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3099) management authorization
 throws an exception when an LDAP group contains a slash/backslash character
In-Reply-To: <JIRA.12534652.1394538171000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534652.1394538171000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534652.1394538171000.8280.1394618830556@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-3099?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12952218#comment-12952218 ] 

RH Bugzilla Integration commented on WFLY-3099:
-----------------------------------------------

Carlo de Wolf <cdewolf at redhat.com> changed the Status of [bug 1075082|https://bugzilla.redhat.com/show_bug.cgi?id=1075082] from MODIFIED to ASSIGNED
                
> management authorization throws an exception when an LDAP group contains a slash/backslash character
> ----------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-3099
>                 URL: https://issues.jboss.org/browse/WFLY-3099
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>    Affects Versions: 8.0.0.Final
>            Reporter: Tom Fonteyne
>            Assignee: Tom Fonteyne
>
> management authorization throws an exception when an LDAP group contains a slash/backslash character

--
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

From issues at jboss.org  Wed Mar 12 06:53:11 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 12 Mar 2014 06:53:11 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2644) Java heap space exceeded
 looping connect/disconnect cycle
In-Reply-To: <JIRA.12527822.1386863108000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12527822.1386863108000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12527822.1386863108000.8482.1394621591705@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2644?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12952247#comment-12952247 ] 

RH Bugzilla Integration commented on WFLY-2644:
-----------------------------------------------

Kabir Khan <kkhan at redhat.com> changed the Status of [bug 1037574|https://bugzilla.redhat.com/show_bug.cgi?id=1037574] from POST to MODIFIED
                
> Java heap space exceeded looping connect/disconnect cycle
> ---------------------------------------------------------
>
>                 Key: WFLY-2644
>                 URL: https://issues.jboss.org/browse/WFLY-2644
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: CLI
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Alexey Loubyansky
>            Assignee: Alexey Loubyansky
>             Fix For: 8.0.0.Final
>
>
> CLIModelControllerClient implementation is not cleaning up something related to connection handling which leads to OOME repeating a cycle of ensureConnected(...) and close(). On my laptop it happens after around 1400 iterations.

--
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

From issues at jboss.org  Wed Mar 12 06:55:10 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 12 Mar 2014 06:55:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3099) management authorization
 throws an exception when an LDAP group contains a slash/backslash character
In-Reply-To: <JIRA.12534652.1394538171000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534652.1394538171000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534652.1394538171000.8488.1394621710538@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-3099?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12952248#comment-12952248 ] 

RH Bugzilla Integration commented on WFLY-3099:
-----------------------------------------------

Kabir Khan <kkhan at redhat.com> changed the Status of [bug 1074560|https://bugzilla.redhat.com/show_bug.cgi?id=1074560] from POST to MODIFIED
                
> management authorization throws an exception when an LDAP group contains a slash/backslash character
> ----------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-3099
>                 URL: https://issues.jboss.org/browse/WFLY-3099
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>    Affects Versions: 8.0.0.Final
>            Reporter: Tom Fonteyne
>            Assignee: Tom Fonteyne
>
> management authorization throws an exception when an LDAP group contains a slash/backslash character

--
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

From issues at jboss.org  Wed Mar 12 09:05:10 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 12 Mar 2014 09:05:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3078) directory-grouping
 configuration is not getting persisted via CLI when no servers defined
In-Reply-To: <JIRA.12534347.1394159920000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534347.1394159920000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534347.1394159920000.8807.1394629510812@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-3078?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12952281#comment-12952281 ] 

RH Bugzilla Integration commented on WFLY-3078:
-----------------------------------------------

Petr Kremensky <pkremens at redhat.com> changed the Status of [bug 1073715|https://bugzilla.redhat.com/show_bug.cgi?id=1073715] from ON_QA to MODIFIED
                
> directory-grouping configuration is not getting persisted via CLI when no servers defined
> -----------------------------------------------------------------------------------------
>
>                 Key: WFLY-3078
>                 URL: https://issues.jboss.org/browse/WFLY-3078
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>    Affects Versions: 8.0.0.Final
>         Environment: All Operating System
>            Reporter: Jay Kumar SenSharma
>            Assignee: Emanuel Muckenhuber
>             Fix For: 8.0.1.Final
>
>
> - If none of the servers are defined in "host.xml" (means <servers></servers> empty tag is present) and if the user tries to run the following CLI command to change the "directory-grouping" to  "by-type"  then the value is not persisted in the configuration file (host.xml) and the <servers></servers>  tag is also removed from the host.xml
> {code}
> /host=master/:write-attribute(name=directory-grouping,value=by-type)
> {code}
> - The value of "directory-grouping" is stored "in memory" so this change does not survive the host restart.

--
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

From issues at jboss.org  Wed Mar 12 09:47:10 2014
From: issues at jboss.org (=?UTF-8?Q?Rog=C3=A9rio_Disciolli_=28JIRA=29?=)
Date: Wed, 12 Mar 2014 09:47:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-449) Does not download the
 artifacts with Firefox.
In-Reply-To: <JIRA.12534660.1394542779000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534660.1394542779000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534660.1394542779000.8941.1394632030609@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/DROOLS-449?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12952302#comment-12952302 ] 

Rog?rio Disciolli commented on DROOLS-449:
------------------------------------------

Hi Davide.

After I compile and deploy default project "mortgages-0.0.1.jar". 
When I access the artifact repository "http://localhost:8080/kie-wb/org.kie.workbench.drools.KIEDroolsWebapp/KIEDroolsWebapp.html?#org.kie.guvnor.Problems" and try download and does not do. Not work with Firefox 25.0.1 and too not work with IE9. 
I can download only with Chrome 33.

Thank you for your attention.
                
> Does not download the artifacts with Firefox. 
> ----------------------------------------------
>
>                 Key: DROOLS-449
>                 URL: https://issues.jboss.org/browse/DROOLS-449
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 6.0.1.Final, 6.1.0.Beta1
>         Environment: Windows 7 Professional 64 bits
> JDK 1.7.45
> Firefox 25.0.1
>            Reporter: Rog?rio Disciolli
>            Assignee: Mark Proctor
>              Labels: Firefox, artifact, download
>
> When try download an Artifact from repository with browser Firefox nothing does.

--
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


From issues at jboss.org  Wed Mar 12 09:51:11 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 12 Mar 2014 09:51:11 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBJCA-1151) Allow testConnection()
 without statistics enabled
In-Reply-To: <JIRA.12534290.1394115585000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534290.1394115585000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534290.1394115585000.8958.1394632271034@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBJCA-1151?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated JBJCA-1151:
-------------------------------------------

        Bugzilla Update: Perform
    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1075638

    
> Allow testConnection() without statistics enabled
> -------------------------------------------------
>
>                 Key: JBJCA-1151
>                 URL: https://issues.jboss.org/browse/JBJCA-1151
>             Project: IronJacamar
>          Issue Type: Task
>          Components: Core
>    Affects Versions: 1.0.24.Final
>            Reporter: Jesper Pedersen
>            Assignee: Jesper Pedersen
>             Fix For: 1.0.25.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

From issues at jboss.org  Wed Mar 12 09:57:11 2014
From: issues at jboss.org (Davide Sottara (JIRA))
Date: Wed, 12 Mar 2014 09:57:11 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-449) Does not download the
 artifacts with Firefox.
In-Reply-To: <JIRA.12534660.1394542779000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534660.1394542779000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534660.1394542779000.8976.1394632630989@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-449?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Davide Sottara reassigned DROOLS-449:
-------------------------------------

    Assignee: Michael Anstis  (was: Mark Proctor)


Reassigned as a WB issue
                
> Does not download the artifacts with Firefox. 
> ----------------------------------------------
>
>                 Key: DROOLS-449
>                 URL: https://issues.jboss.org/browse/DROOLS-449
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 6.0.1.Final, 6.1.0.Beta1
>         Environment: Windows 7 Professional 64 bits
> JDK 1.7.45
> Firefox 25.0.1
>            Reporter: Rog?rio Disciolli
>            Assignee: Michael Anstis
>              Labels: Firefox, artifact, download
>
> When try download an Artifact from repository with browser Firefox nothing does.

--
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


From issues at jboss.org  Wed Mar 12 10:00:04 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 12 Mar 2014 10:00:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1271) Infinispan remote-store
 requires remote-servers but not marked as required in mgmt model
In-Reply-To: <JIRA.12490391.1366787482000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12490391.1366787482000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12490391.1366787482000.8983.1394632804322@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1271?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12952310#comment-12952310 ] 

RH Bugzilla Integration commented on WFLY-1271:
-----------------------------------------------

Richard Jan?k <rjanik at redhat.com> changed the Status of [bug 956904|https://bugzilla.redhat.com/show_bug.cgi?id=956904] from ON_QA to VERIFIED
                
> Infinispan remote-store requires remote-servers but not marked as required in mgmt model
> ----------------------------------------------------------------------------------------
>
>                 Key: WFLY-1271
>                 URL: https://issues.jboss.org/browse/WFLY-1271
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Clustering
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Takayoshi Kimura
>            Assignee: Richard Achmatowicz
>             Fix For: 8.0.0.CR1
>
>
> Affect version is actually 8.0.0.Alpha1-SNAPSHOT (before 8.0.0.Alpha1, we don't have such selection).
> Command remote-store=REMOTE_STORE:add fails with this exception:
> {quote}
> 15:58:05,112 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 3) JBAS014607: Failed to persist configuration change: org.jboss.as.controller.persistence.ConfigurationPersistenceException: JBAS014675: Failed to marshal configuration
> 	at org.jboss.as.controller.persistence.AbstractFilePersistenceResource.<init>(AbstractFilePersistenceResource.java:50) [jboss-as-controller-8.0.0.Alpha1-SNAPSHOT.jar:8.0.0.Alpha1-SNAPSHOT]
> 	at org.jboss.as.controller.persistence.ConfigurationFilePersistenceResource.<init>(ConfigurationFilePersistenceResource.java:45) [jboss-as-controller-8.0.0.Alpha1-SNAPSHOT.jar:8.0.0.Alpha1-SNAPSHOT]
> 	at org.jboss.as.controller.persistence.BackupXmlConfigurationPersister.store(BackupXmlConfigurationPersister.java:80) [jboss-as-controller-8.0.0.Alpha1-SNAPSHOT.jar:8.0.0.Alpha1-SNAPSHOT]
> 	at org.jboss.as.controller.ModelControllerImpl.writeModel(ModelControllerImpl.java:522) [jboss-as-controller-8.0.0.Alpha1-SNAPSHOT.jar:8.0.0.Alpha1-SNAPSHOT]
> 	at org.jboss.as.controller.OperationContextImpl.createPersistenceResource(OperationContextImpl.java:178) [jboss-as-controller-8.0.0.Alpha1-SNAPSHOT.jar:8.0.0.Alpha1-SNAPSHOT]
> 	at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:359) [jboss-as-controller-8.0.0.Alpha1-SNAPSHOT.jar:8.0.0.Alpha1-SNAPSHOT]
> 	at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:228) [jboss-as-controller-8.0.0.Alpha1-SNAPSHOT.jar:8.0.0.Alpha1-SNAPSHOT]
> 	at org.jboss.as.controller.AbstractOperationContext.finishStep(AbstractOperationContext.java:513) [jboss-as-controller-8.0.0.Alpha1-SNAPSHOT.jar:8.0.0.Alpha1-SNAPSHOT]
> 	at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:499) [jboss-as-controller-8.0.0.Alpha1-SNAPSHOT.jar:8.0.0.Alpha1-SNAPSHOT]
> 	at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:321) [jboss-as-controller-8.0.0.Alpha1-SNAPSHOT.jar:8.0.0.Alpha1-SNAPSHOT]
> 	at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:228) [jboss-as-controller-8.0.0.Alpha1-SNAPSHOT.jar:8.0.0.Alpha1-SNAPSHOT]
> 	at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:223) [jboss-as-controller-8.0.0.Alpha1-SNAPSHOT.jar:8.0.0.Alpha1-SNAPSHOT]
> 	at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:235) [jboss-as-controller-8.0.0.Alpha1-SNAPSHOT.jar:8.0.0.Alpha1-SNAPSHOT]
> 	at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:124) [jboss-as-controller-8.0.0.Alpha1-SNAPSHOT.jar:8.0.0.Alpha1-SNAPSHOT]
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:148) [jboss-as-controller-8.0.0.Alpha1-SNAPSHOT.jar:8.0.0.Alpha1-SNAPSHOT]
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$300(ModelControllerClientOperationHandler.java:97) [jboss-as-controller-8.0.0.Alpha1-SNAPSHOT.jar:8.0.0.Alpha1-SNAPSHOT]
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:114) [jboss-as-controller-8.0.0.Alpha1-SNAPSHOT.jar:8.0.0.Alpha1-SNAPSHOT]
> 	at org.jboss.as.protocol.mgmt.AbstractMessageHandler$2$1.doExecute(AbstractMessageHandler.java:296) [jboss-as-protocol-8.0.0.Alpha1-SNAPSHOT.jar:8.0.0.Alpha1-SNAPSHOT]
> 	at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:518) [jboss-as-protocol-8.0.0.Alpha1-SNAPSHOT.jar:8.0.0.Alpha1-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]
> Caused by: org.jboss.as.controller.persistence.ConfigurationPersistenceException: JBAS014680: Failed to write configuration
> 	at org.jboss.as.controller.persistence.AbstractConfigurationPersister.marshallAsXml(AbstractConfigurationPersister.java:123) [jboss-as-controller-8.0.0.Alpha1-SNAPSHOT.jar:8.0.0.Alpha1-SNAPSHOT]
> 	at org.jboss.as.controller.persistence.AbstractFilePersistenceResource.<init>(AbstractFilePersistenceResource.java:43) [jboss-as-controller-8.0.0.Alpha1-SNAPSHOT.jar:8.0.0.Alpha1-SNAPSHOT]
> 	... 22 more
> Caused by: java.lang.IllegalArgumentException
> 	at org.jboss.dmr.ModelValue.asList(ModelValue.java:128) [jboss-dmr-1.1.6.Final.jar:1.1.6.Final]
> 	at org.jboss.dmr.ModelNode.asList(ModelNode.java:1205) [jboss-dmr-1.1.6.Final.jar:1.1.6.Final]
> 	at org.jboss.as.clustering.infinispan.subsystem.InfinispanSubsystemXMLWriter.processCommonCacheAttributesElements(InfinispanSubsystemXMLWriter.java:282)
> 	at org.jboss.as.clustering.infinispan.subsystem.InfinispanSubsystemXMLWriter.writeContent(InfinispanSubsystemXMLWriter.java:124)
> 	at org.jboss.as.clustering.infinispan.subsystem.InfinispanSubsystemXMLWriter.writeContent(InfinispanSubsystemXMLWriter.java:42)
> 	at org.jboss.as.server.parsing.StandaloneXml.writeServerProfile(StandaloneXml.java:1191) [jboss-as-server-8.0.0.Alpha1-SNAPSHOT.jar:8.0.0.Alpha1-SNAPSHOT]
> 	at org.jboss.as.server.parsing.StandaloneXml.writeContent(StandaloneXml.java:1108) [jboss-as-server-8.0.0.Alpha1-SNAPSHOT.jar:8.0.0.Alpha1-SNAPSHOT]
> 	at org.jboss.as.server.parsing.StandaloneXml.writeContent(StandaloneXml.java:103) [jboss-as-server-8.0.0.Alpha1-SNAPSHOT.jar:8.0.0.Alpha1-SNAPSHOT]
> 	at org.jboss.staxmapper.XMLMapperImpl.doDeparse(XMLMapperImpl.java:88) [staxmapper-1.1.0.Final.jar:1.1.0.Final]
> 	at org.jboss.staxmapper.XMLMapperImpl.deparseDocument(XMLMapperImpl.java:83) [staxmapper-1.1.0.Final.jar:1.1.0.Final]
> 	at org.jboss.as.controller.persistence.AbstractConfigurationPersister.marshallAsXml(AbstractConfigurationPersister.java:117) [jboss-as-controller-8.0.0.Alpha1-SNAPSHOT.jar:8.0.0.Alpha1-SNAPSHOT]
> 	... 23 more
> {quote}
> Reproduce steps:
> {quote}
> [standalone at localhost:9999 /] /subsystem=infinispan/cache-container=web/replicated-cache=repl/file-store=FILE_STORE:remove
> {
>     "outcome" => "success",
>     "response-headers" => {
>         "operation-requires-reload" => true,
>         "process-state" => "reload-required"
>     }
> }
> [standalone at localhost:9999 /] /subsystem=infinispan/cache-container=web/replicated-cache=repl/remote-store=REMOTE_STORE:add
> {
>     "outcome" => "failed",
>     "failure-description" => "JBAS014677: Failed to persist configuration change: JBAS014675: Failed to marshal configuration",
>     "rolled-back" => true,
>     "response-headers" => {"process-state" => "reload-required"}
> }
> [standalone at localhost:9999 /] /subsystem=infinispan/cache-container=web/replicated-cache=repl/remote-store=REMOTE_STORE:add(remote-servers=[])
> {
>     "outcome" => "success",
>     "response-headers" => {"process-state" => "reload-required"}
> }
> {quote}
> In $JBOSS_HOME/docs/schema/jboss-as-infinispan_1_3.xsd, it looks like the remote-server is required as it's defined as minOccurs="1":
> {quote}
> <xs:element name="remote-server" type="tns:remote-server" minOccurs="1" maxOccurs="unbounded"/>
> {quote}

--
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


From issues at jboss.org  Wed Mar 12 10:41:10 2014
From: issues at jboss.org (Jeff Mesnil (JIRA))
Date: Wed, 12 Mar 2014 10:41:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3103)
 PrimitiveListAttributeDefinition.Builder does not preserve the validator
In-Reply-To: <JIRA.12534784.1394635208882@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534784.1394635208882@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534784.1394635208882.9127.1394635270850@jira02.app.mwc.hst.phx2.redhat.com>

Jeff Mesnil created WFLY-3103:
---------------------------------

             Summary: PrimitiveListAttributeDefinition.Builder does not preserve the validator
                 Key: WFLY-3103
                 URL: https://issues.jboss.org/browse/WFLY-3103
             Project: WildFly
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Server
    Affects Versions: 8.0.0.Final
            Reporter: Jeff Mesnil
            Assignee: Jeff Mesnil
             Fix For: 8.0.1.Final


Using PrimitiveListAttributeDefinition.Builder#Builder(PrimitiveListAttributeDefinition)
to build an new attribute definition from a basis does not preserve the basis' elementValidator and the valid operation can not be validated against the copied definition.


--
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

From issues at jboss.org  Wed Mar 12 10:41:10 2014
From: issues at jboss.org (Davide Sottara (JIRA))
Date: Wed, 12 Mar 2014 10:41:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-452) MVEL validates illegal
 expressions using ":"
In-Reply-To: <JIRA.12534785.1394635237943@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534785.1394635237943@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534785.1394635237943.9128.1394635270900@jira02.app.mwc.hst.phx2.redhat.com>

Davide Sottara created DROOLS-452:
-------------------------------------

             Summary: MVEL validates illegal expressions using ":"
                 Key: DROOLS-452
                 URL: https://issues.jboss.org/browse/DROOLS-452
             Project: Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
            Reporter: Davide Sottara
            Assignee: Mario Fusco
            Priority: Minor


A rule like this

{code}
rule "Typo"
dialect "mvel"
when
  ...
then
  // Notice the ":" in place of ";". There is also a \n at the end of the line
  System.out.println( "Hello" ):  
  // more statements here
end
{code}

MVEL will validate the RHS at compile time. 
At runtime, the printout (actually any statement ending with ":") will be
executed, but MVEL will fail silently thereafter. The rest of the conclusion
will not be evaluated.

--
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

From issues at jboss.org  Wed Mar 12 10:45:11 2014
From: issues at jboss.org (Richard Achmatowicz (JIRA))
Date: Wed, 12 Mar 2014 10:45:11 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3003) Dropping unicast message to
 wrong destination warn after cluster node rejoin
In-Reply-To: <JIRA.12533083.1393242652000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12533083.1393242652000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12533083.1393242652000.9143.1394635511713@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-3003?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Richard Achmatowicz reassigned WFLY-3003:
-----------------------------------------

    Assignee: Richard Achmatowicz  (was: Paul Ferraro)

    
> Dropping unicast message to wrong destination warn after cluster node rejoin
> ----------------------------------------------------------------------------
>
>                 Key: WFLY-3003
>                 URL: https://issues.jboss.org/browse/WFLY-3003
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Clustering
>            Reporter: Eduardo Martins
>            Assignee: Richard Achmatowicz
>
> There is a never ending warn log message printed after a cluster node rejoins, after a shutdown:
> 03:43:15,831 WARN  [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/server: dropping unicast message to wrong destination a1fdbb88-a500-483d-7405-70c93a8ab740
> 03:43:15,831 WARN  [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/ejb: dropping unicast message to wrong destination f567dfca-cdad-2555-0e3b-22c8ebded75b
> 03:43:15,887 INFO  [org.jboss.as.server] (Controller Boot Thread) JBAS018559: Deployed "wildfly-cluster-ha-singleton-service.jar" (runtime-name : "wildfly-cluster-ha-singleton-service.jar")
> 03:43:15,895 INFO  [org.jboss.as] (Controller Boot Thread) JBAS015961: Http management interface listening on http://127.0.0.1:10090/management
> 03:43:15,895 INFO  [org.jboss.as] (Controller Boot Thread) JBAS015951: Admin console listening on http://127.0.0.1:10090
> 03:43:15,896 INFO  [org.jboss.as] (Controller Boot Thread) JBAS015874: WildFly 8.0.1.Final-SNAPSHOT "WildFly" started in 4855ms - Started 345 of 437 services (171 services are lazy, passive or on-demand)
> 03:43:16,332 WARN  [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/server: dropping unicast message to wrong destination a1fdbb88-a500-483d-7405-70c93a8ab740
> 03:43:16,332 WARN  [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/ejb: dropping unicast message to wrong destination f567dfca-cdad-2555-0e3b-22c8ebded75b
> 03:43:16,833 WARN  [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/server: dropping unicast message to wrong destination a1fdbb88-a500-483d-7405-70c93a8ab740
> 03:43:16,834 WARN  [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/ejb: dropping unicast message to wrong destination f567dfca-cdad-2555-0e3b-22c8ebded75b
> 03:43:17,335 WARN  [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/server: dropping unicast message to wrong destination a1fdbb88-a500-483d-7405-70c93a8ab740
> 03:43:17,336 WARN  [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/ejb: dropping unicast message to wrong destination f567dfca-cdad-2555-0e3b-22c8ebded75b
> 03:43:17,835 WARN  [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/server: dropping unicast message to wrong destination a1fdbb88-a500-483d-7405-70c93a8ab740
> 03:43:17,836 WARN  [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/ejb: dropping unicast message to wrong destination f567dfca-cdad-2555-0e3b-22c8ebded75b
> 03:43:18,335 WARN  [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/server: dropping unicast message to wrong destination a1fdbb88-a500-483d-7405-70c93a8ab740
> 03:43:18,336 WARN  [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/ejb: dropping unicast message to wrong destination f567dfca-cdad-2555-0e3b-22c8ebded75b
> 03:43:18,837 WARN  [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/server: dropping unicast message to wrong destination a1fdbb88-a500-483d-7405-70c93a8ab740
> 03:43:18,838 WARN  [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/ejb: dropping unicast message to wrong destination f567dfca-cdad-2555-0e3b-22c8ebded75b
> 03:43:19,339 WARN  [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/server: dropping unicast message to wrong destination a1fdbb88-a500-483d-7405-70c93a8ab740
> 03:43:19,340 WARN  [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/ejb: dropping unicast message to wrong destination f567dfca-cdad-2555-0e3b-22c8ebded75b
> 03:43:19,840 WARN  [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/server: dropping unicast message to wrong destination a1fdbb88-a500-483d-7405-70c93a8ab740
> 03:43:19,840 WARN  [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/ejb: dropping unicast message to wrong destination f567dfca-cdad-2555-0e3b-22c8ebded75b
> 03:43:20,003 INFO  [org.jboss.as.quickstarts.cluster.hasingleton.service.ejb.SchedulerBean] (EJB default - 1) HASingletonTimer: Info=HASingleton timer @nodeTwo Sat Feb 22 03:43:15 WET 2014
> 03:43:20,003 INFO  [org.jboss.as.quickstarts.cluster.hasingleton.service.ejb.SchedulerBean] (EJB default - 2) HASingletonTimer: Info=HASingleton timer @nodeTwo Sat Feb 22 03:43:15 WET 2014
> 03:43:20,341 WARN  [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/server: dropping unicast message to wrong destination a1fdbb88-a500-483d-7405-70c93a8ab740
> 03:43:20,342 WARN  [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/ejb: dropping unicast message to wrong destination f567dfca-cdad-2555-0e3b-22c8ebded75b
> 03:43:20,841 WARN  [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/server: dropping unicast message to wrong destination a1fdbb88-a500-483d-7405-70c93a8ab740
> 03:43:20,842 WARN  [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/ejb: dropping unicast message to wrong destination f567dfca-cdad-2555-0e3b-22c8ebded75b
> 03:43:21,342 WARN  [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/server: dropping unicast message to wrong destination a1fdbb88-a500-483d-7405-70c93a8ab740
> 03:43:21,342 WARN  [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/ejb: dropping unicast message to wrong destination f567dfca-cdad-2555-0e3b-22c8ebded75b
> 03:43:21,842 WARN  [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/server: dropping unicast message to wrong destination a1fdbb88-a500-483d-7405-70c93a8ab740
> 03:43:21,843 WARN  [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/ejb: dropping unicast message to wrong destination f567dfca-cdad-2555-0e3b-22c8ebded75b
> 03:43:22,343 WARN  [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/server: dropping unicast message to wrong destination a1fdbb88-a500-483d-7405-70c93a8ab740
> 03:43:22,344 WARN  [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/ejb: dropping unicast message to wrong destination f567dfca-cdad-2555-0e3b-22c8ebded75b
> 03:43:22,845 WARN  [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/server: dropping unicast message to wrong destination a1fdbb88-a500-483d-7405-70c93a8ab740
> 03:43:22,845 WARN  [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/ejb: dropping unicast message to wrong destination f567dfca-cdad-2555-0e3b-22c8ebded75b
> 03:43:23,345 WARN  [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/server: dropping unicast message to wrong destination a1fdbb88-a500-483d-7405-70c93a8ab740
> 03:43:23,346 WARN  [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/ejb: dropping unicast message to wrong destination f567dfca-cdad-2555-0e3b-22c8ebded75b
> 03:43:23,846 WARN  [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/server: dropping unicast message to wrong destination a1fdbb88-a500-483d-7405-70c93a8ab740
> 03:43:23,846 WARN  [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/ejb: dropping unicast message to wrong destination f567dfca-cdad-2555-0e3b-22c8ebded75b
> This can be seen using WildFly's cluster-ha-singleton quickstart (github project wildfly/quickstart). Just follow quickstart?s readme till point 4 of "Check the timer" section, and after stop node2 (not node1) start it gain.

--
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


From issues at jboss.org  Wed Mar 12 10:57:10 2014
From: issues at jboss.org (Gabriele Garuglieri (JIRA))
Date: Wed, 12 Mar 2014 10:57:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3104) datasource created with
 console cannot be enabled
In-Reply-To: <JIRA.12534786.1394636123928@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534786.1394636123928@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534786.1394636123928.9197.1394636230773@jira02.app.mwc.hst.phx2.redhat.com>

Gabriele Garuglieri created WFLY-3104:
-----------------------------------------

             Summary: datasource created with console cannot be enabled
                 Key: WFLY-3104
                 URL: https://issues.jboss.org/browse/WFLY-3104
             Project: WildFly
          Issue Type: Bug
      Security Level: Public (Everyone can see)
         Environment: Wildfly 8.0.0 Final
            Reporter: Gabriele Garuglieri


Consider the following cli file:
{noformat}
/subsystem=datasources/data-source=fai-bfsa:add( \
  driver-name=PostgresJDBCDriver, \
  driver-class="org.postgresql.Driver", \
  jndi-name=java:jboss/jdbc/fai-bfsa, \
  connection-url=jdbc:postgresql://tpg0001:5432/xfgb01, \
  max-pool-size=20, \
  min-pool-size=10, \
  new-connection-sql="select 1", \
  check-valid-connection-sql="select 1", \
  user-name=uuuuu, \
  password=uuuuu, \
  background-validation=false, \
  validate-on-match=false, \
  enabled=false, \
  jta=true, \
  use-ccm=true, \
  share-prepared-statements=false, \
)
{noformat}

This is reflected into standalone-full.xml as:
{code:xml}
<datasource jta="true" jndi-name="java:jboss/jdbc/fai-bfsa" pool-name="fai-bfsa" enabled="false" use-ccm="true">
    <connection-url>jdbc:postgresql://tpg0001:5432/xfgb01</connection-url>
    <driver-class>org.postgresql.Driver</driver-class>
    <driver>PostgresJDBCDriver</driver>
    <new-connection-sql>select 1</new-connection-sql>
    <pool>
        <min-pool-size>10</min-pool-size>
        <max-pool-size>20</max-pool-size>
    </pool>
    <security>
        <user-name>uuuuu</user-name>
        <password>uuuuu</password>
    </security>
    <validation>
        <check-valid-connection-sql>select 1</check-valid-connection-sql>
        <validate-on-match>false</validate-on-match>
        <background-validation>false</background-validation>
    </validation>
    <statement>
        <share-prepared-statements>false</share-prepared-statements>
    </statement>
</datasource>
{code}

I can now enable and disable that datasource both via cli or console without problem.

If i create the same datasource via console, with the very same attributes, producing the very same standalone-full.xml (i have diffed them), i cannot enable it nether via cli nor console because i get the following error:

{noformat}
14:33:00,230 ERROR [org.jboss.as.connector.subsystems.datasources.AbstractDataSourceService$AS7DataSourceDeployer] (MSC service thread 1-3) Error during the deployment of java:jboss/jdbc/fai-bfsa: java.lang.IllegalStateException
        at org.jboss.msc.value.InjectedValue.getValue(InjectedValue.java:47)
        at org.jboss.as.connector.subsystems.datasources.AbstractDataSourceService$AS7DataSourceDeployer.getTransactionIntegration(AbstractDataSourceService.java:409)
        at org.jboss.as.connector.subsystems.datasources.AbstractDataSourceService$AS7DataSourceDeployer.createMcf(AbstractDataSourceService.java:461)
        at org.jboss.jca.deployers.common.AbstractDsDeployer.deployDataSource(AbstractDsDeployer.java:430)
        at org.jboss.jca.deployers.common.AbstractDsDeployer.createObjectsAndInjectValue(AbstractDsDeployer.java:283)
        at org.jboss.as.connector.subsystems.datasources.AbstractDataSourceService$AS7DataSourceDeployer.deploy(AbstractDataSourceService.java:310)
        at org.jboss.as.connector.subsystems.datasources.AbstractDataSourceService.start(AbstractDataSourceService.java:124)
        at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948)
        at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_51]
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_51]
        at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_51]

14:33:00,236 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-3) MSC000001: Failed to start service jboss.data-source.java:jboss/jdbc/fai-bfsa: org.jboss.msc.service.StartException in service jboss.data-source.java:jboss/jdbc/fai-bfsa: JBAS010433: Error during the deployment of fai-bfsa
        at org.jboss.as.connector.subsystems.datasources.AbstractDataSourceService.start(AbstractDataSourceService.java:131)
        at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) [jboss-msc-1.2.0.Final.jar:1.2.0.Final]
        at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) [jboss-msc-1.2.0.Final.jar:1.2.0.Final]
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_51]
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_51]
        at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_51]
Caused by: org.jboss.msc.service.StartException in anonymous service: JBAS010432: Unable to start the ds because it generated more than one cf
        at org.jboss.as.connector.subsystems.datasources.AbstractDataSourceService.start(AbstractDataSourceService.java:126)
        ... 5 more

14:33:00,242 INFO  [org.jboss.as.controller] (XNIO-4 task-2) JBAS014774: Servicestatus report
JBAS014775:    New missing/unsatisfied dependencies:
      service jboss.data-source.reference-factory.fai-bfsa (missing) dependents:[service jboss.naming.context.java.jboss.jdbc.fai-bfsa]
      service jboss.data-source-config.fai-bfsa (missing) dependents: [service jboss.data-source.java:jboss/jdbc/fai-bfsa]
JBAS014777:   Services which failed to start:      service jboss.data-source.java:jboss/jdbc/fai-bfsa
{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

From issues at jboss.org  Wed Mar 12 11:09:10 2014
From: issues at jboss.org (Gabriele Garuglieri (JIRA))
Date: Wed, 12 Mar 2014 11:09:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3104) datasource created with
 console cannot be enabled
In-Reply-To: <JIRA.12534786.1394636123000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534786.1394636123000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534786.1394636123000.9214.1394636950657@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-3104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12952339#comment-12952339 ] 

Gabriele Garuglieri commented on WFLY-3104:
-------------------------------------------

One more hint, the problem looks to be caused by jta=true. Setting it to false works in all the circumstances.

Really i do not need that attribute and i created a ds with cli letting it to default, after that both read-resource and console showed it as true and the ds could be enabled and disabled without problems.
Then someone tried to create a similar ds via console setting jta as true like the previous ds, stumbling on this problem.
                
> datasource created with console cannot be enabled
> -------------------------------------------------
>
>                 Key: WFLY-3104
>                 URL: https://issues.jboss.org/browse/WFLY-3104
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>         Environment: Wildfly 8.0.0 Final
>            Reporter: Gabriele Garuglieri
>
> Consider the following cli file:
> {noformat}
> /subsystem=datasources/data-source=fai-bfsa:add( \
>   driver-name=PostgresJDBCDriver, \
>   driver-class="org.postgresql.Driver", \
>   jndi-name=java:jboss/jdbc/fai-bfsa, \
>   connection-url=jdbc:postgresql://tpg0001:5432/xfgb01, \
>   max-pool-size=20, \
>   min-pool-size=10, \
>   new-connection-sql="select 1", \
>   check-valid-connection-sql="select 1", \
>   user-name=uuuuu, \
>   password=uuuuu, \
>   background-validation=false, \
>   validate-on-match=false, \
>   enabled=false, \
>   jta=true, \
>   use-ccm=true, \
>   share-prepared-statements=false, \
> )
> {noformat}
> This is reflected into standalone-full.xml as:
> {code:xml}
> <datasource jta="true" jndi-name="java:jboss/jdbc/fai-bfsa" pool-name="fai-bfsa" enabled="false" use-ccm="true">
>     <connection-url>jdbc:postgresql://tpg0001:5432/xfgb01</connection-url>
>     <driver-class>org.postgresql.Driver</driver-class>
>     <driver>PostgresJDBCDriver</driver>
>     <new-connection-sql>select 1</new-connection-sql>
>     <pool>
>         <min-pool-size>10</min-pool-size>
>         <max-pool-size>20</max-pool-size>
>     </pool>
>     <security>
>         <user-name>uuuuu</user-name>
>         <password>uuuuu</password>
>     </security>
>     <validation>
>         <check-valid-connection-sql>select 1</check-valid-connection-sql>
>         <validate-on-match>false</validate-on-match>
>         <background-validation>false</background-validation>
>     </validation>
>     <statement>
>         <share-prepared-statements>false</share-prepared-statements>
>     </statement>
> </datasource>
> {code}
> I can now enable and disable that datasource both via cli or console without problem.
> If i create the same datasource via console, with the very same attributes, producing the very same standalone-full.xml (i have diffed them), i cannot enable it nether via cli nor console because i get the following error:
> {noformat}
> 14:33:00,230 ERROR [org.jboss.as.connector.subsystems.datasources.AbstractDataSourceService$AS7DataSourceDeployer] (MSC service thread 1-3) Error during the deployment of java:jboss/jdbc/fai-bfsa: java.lang.IllegalStateException
>         at org.jboss.msc.value.InjectedValue.getValue(InjectedValue.java:47)
>         at org.jboss.as.connector.subsystems.datasources.AbstractDataSourceService$AS7DataSourceDeployer.getTransactionIntegration(AbstractDataSourceService.java:409)
>         at org.jboss.as.connector.subsystems.datasources.AbstractDataSourceService$AS7DataSourceDeployer.createMcf(AbstractDataSourceService.java:461)
>         at org.jboss.jca.deployers.common.AbstractDsDeployer.deployDataSource(AbstractDsDeployer.java:430)
>         at org.jboss.jca.deployers.common.AbstractDsDeployer.createObjectsAndInjectValue(AbstractDsDeployer.java:283)
>         at org.jboss.as.connector.subsystems.datasources.AbstractDataSourceService$AS7DataSourceDeployer.deploy(AbstractDataSourceService.java:310)
>         at org.jboss.as.connector.subsystems.datasources.AbstractDataSourceService.start(AbstractDataSourceService.java:124)
>         at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948)
>         at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881)
>         at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_51]
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_51]
>         at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_51]
> 14:33:00,236 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-3) MSC000001: Failed to start service jboss.data-source.java:jboss/jdbc/fai-bfsa: org.jboss.msc.service.StartException in service jboss.data-source.java:jboss/jdbc/fai-bfsa: JBAS010433: Error during the deployment of fai-bfsa
>         at org.jboss.as.connector.subsystems.datasources.AbstractDataSourceService.start(AbstractDataSourceService.java:131)
>         at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) [jboss-msc-1.2.0.Final.jar:1.2.0.Final]
>         at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) [jboss-msc-1.2.0.Final.jar:1.2.0.Final]
>         at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_51]
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_51]
>         at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_51]
> Caused by: org.jboss.msc.service.StartException in anonymous service: JBAS010432: Unable to start the ds because it generated more than one cf
>         at org.jboss.as.connector.subsystems.datasources.AbstractDataSourceService.start(AbstractDataSourceService.java:126)
>         ... 5 more
> 14:33:00,242 INFO  [org.jboss.as.controller] (XNIO-4 task-2) JBAS014774: Servicestatus report
> JBAS014775:    New missing/unsatisfied dependencies:
>       service jboss.data-source.reference-factory.fai-bfsa (missing) dependents:[service jboss.naming.context.java.jboss.jdbc.fai-bfsa]
>       service jboss.data-source-config.fai-bfsa (missing) dependents: [service jboss.data-source.java:jboss/jdbc/fai-bfsa]
> JBAS014777:   Services which failed to start:      service jboss.data-source.java:jboss/jdbc/fai-bfsa
> {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

From issues at jboss.org  Wed Mar 12 11:13:10 2014
From: issues at jboss.org (Christian Bauer (JIRA))
Date: Wed, 12 Mar 2014 11:13:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3105) Container-managed EXTENDED
 persistence context is always joined with transaction even if
 UNSYNCHRONIZED
In-Reply-To: <JIRA.12534789.1394637157071@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534789.1394637157071@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534789.1394637157071.9219.1394637190743@jira02.app.mwc.hst.phx2.redhat.com>

Christian Bauer created WFLY-3105:
-------------------------------------

             Summary: Container-managed EXTENDED persistence context is always joined with transaction even if UNSYNCHRONIZED
                 Key: WFLY-3105
                 URL: https://issues.jboss.org/browse/WFLY-3105
             Project: WildFly
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: JPA / Hibernate
    Affects Versions: 8.0.0.Final
            Reporter: Christian Bauer
            Assignee: Scott Marlow


https://github.com/weld/wildfly/blob/master/testsuite/integration/basic/src/test/java/org/jboss/as/test/integration/jpa/transaction/UnsynchronizedSFSB.jav

Change this test to {code}@PersistenceContext(type = EXTENDED, synchronization = UNSYNCHRONIZED){code} and it will break. 

Looks like an extended PC is always joined to the transaction and flushed on commit, the unsynchronized mode is ignored. From what I can see this is not specified and indeed would make the whole new UNSYNCHRONIZED feature kind of pointless. It's primary use case is propagation of unflushed/unsynchronized extended PC from a SFSB to other beans while keeping transactions intact.



--
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

From issues at jboss.org  Wed Mar 12 11:39:10 2014
From: issues at jboss.org (Christian Bauer (JIRA))
Date: Wed, 12 Mar 2014 11:39:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3105) Container-managed EXTENDED
 persistence context is always joined with transaction even if
 UNSYNCHRONIZED
In-Reply-To: <JIRA.12534789.1394637157000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534789.1394637157000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534789.1394637157000.9361.1394638750862@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-3105?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12952357#comment-12952357 ] 

Christian Bauer commented on WFLY-3105:
---------------------------------------

Of course there is this in JPA 2.1 section 7.6.3: "The association of the extended persistence context with the JTA transaction is independent of the synchronization type of the persistence context and whether the persistence context has been joined to the transaction."

What does that even mean?
                
> Container-managed EXTENDED persistence context is always joined with transaction even if UNSYNCHRONIZED
> -------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-3105
>                 URL: https://issues.jboss.org/browse/WFLY-3105
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JPA / Hibernate
>    Affects Versions: 8.0.0.Final
>            Reporter: Christian Bauer
>            Assignee: Scott Marlow
>
> https://github.com/weld/wildfly/blob/master/testsuite/integration/basic/src/test/java/org/jboss/as/test/integration/jpa/transaction/UnsynchronizedSFSB.jav
> Change this test to {code}@PersistenceContext(type = EXTENDED, synchronization = UNSYNCHRONIZED){code} and it will break. 
> Looks like an extended PC is always joined to the transaction and flushed on commit, the unsynchronized mode is ignored. From what I can see this is not specified and indeed would make the whole new UNSYNCHRONIZED feature kind of pointless. It's primary use case is propagation of unflushed/unsynchronized extended PC from a SFSB to other beans while keeping transactions intact.

--
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

From issues at jboss.org  Wed Mar 12 12:31:10 2014
From: issues at jboss.org (Gabriele Garuglieri (JIRA))
Date: Wed, 12 Mar 2014 12:31:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3104) datasource created with
 console cannot be enabled
In-Reply-To: <JIRA.12534786.1394636123000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534786.1394636123000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534786.1394636123000.9588.1394641870601@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-3104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12952339#comment-12952339 ] 

Gabriele Garuglieri edited comment on WFLY-3104 at 3/12/14 12:30 PM:
---------------------------------------------------------------------

One more hint, the problem looks to be caused by jta=true. Setting it to false works in all the circumstances.

Really i do not need that attribute and i created a ds with cli letting it to default, after that both read-resource and console showed it as true and the ds could be enabled and disabled without problems.
Then someone tried to create a similar ds via console assuming jta had to be true like the model ds, stumbling on this problem.
                
      was (Author: garu):
    One more hint, the problem looks to be caused by jta=true. Setting it to false works in all the circumstances.

Really i do not need that attribute and i created a ds with cli letting it to default, after that both read-resource and console showed it as true and the ds could be enabled and disabled without problems.
Then someone tried to create a similar ds via console setting jta as true like the previous ds, stumbling on this problem.
                  
> datasource created with console cannot be enabled
> -------------------------------------------------
>
>                 Key: WFLY-3104
>                 URL: https://issues.jboss.org/browse/WFLY-3104
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>         Environment: Wildfly 8.0.0 Final
>            Reporter: Gabriele Garuglieri
>
> Consider the following cli file:
> {noformat}
> /subsystem=datasources/data-source=fai-bfsa:add( \
>   driver-name=PostgresJDBCDriver, \
>   driver-class="org.postgresql.Driver", \
>   jndi-name=java:jboss/jdbc/fai-bfsa, \
>   connection-url=jdbc:postgresql://tpg0001:5432/xfgb01, \
>   max-pool-size=20, \
>   min-pool-size=10, \
>   new-connection-sql="select 1", \
>   check-valid-connection-sql="select 1", \
>   user-name=uuuuu, \
>   password=uuuuu, \
>   background-validation=false, \
>   validate-on-match=false, \
>   enabled=false, \
>   jta=true, \
>   use-ccm=true, \
>   share-prepared-statements=false, \
> )
> {noformat}
> This is reflected into standalone-full.xml as:
> {code:xml}
> <datasource jta="true" jndi-name="java:jboss/jdbc/fai-bfsa" pool-name="fai-bfsa" enabled="false" use-ccm="true">
>     <connection-url>jdbc:postgresql://tpg0001:5432/xfgb01</connection-url>
>     <driver-class>org.postgresql.Driver</driver-class>
>     <driver>PostgresJDBCDriver</driver>
>     <new-connection-sql>select 1</new-connection-sql>
>     <pool>
>         <min-pool-size>10</min-pool-size>
>         <max-pool-size>20</max-pool-size>
>     </pool>
>     <security>
>         <user-name>uuuuu</user-name>
>         <password>uuuuu</password>
>     </security>
>     <validation>
>         <check-valid-connection-sql>select 1</check-valid-connection-sql>
>         <validate-on-match>false</validate-on-match>
>         <background-validation>false</background-validation>
>     </validation>
>     <statement>
>         <share-prepared-statements>false</share-prepared-statements>
>     </statement>
> </datasource>
> {code}
> I can now enable and disable that datasource both via cli or console without problem.
> If i create the same datasource via console, with the very same attributes, producing the very same standalone-full.xml (i have diffed them), i cannot enable it nether via cli nor console because i get the following error:
> {noformat}
> 14:33:00,230 ERROR [org.jboss.as.connector.subsystems.datasources.AbstractDataSourceService$AS7DataSourceDeployer] (MSC service thread 1-3) Error during the deployment of java:jboss/jdbc/fai-bfsa: java.lang.IllegalStateException
>         at org.jboss.msc.value.InjectedValue.getValue(InjectedValue.java:47)
>         at org.jboss.as.connector.subsystems.datasources.AbstractDataSourceService$AS7DataSourceDeployer.getTransactionIntegration(AbstractDataSourceService.java:409)
>         at org.jboss.as.connector.subsystems.datasources.AbstractDataSourceService$AS7DataSourceDeployer.createMcf(AbstractDataSourceService.java:461)
>         at org.jboss.jca.deployers.common.AbstractDsDeployer.deployDataSource(AbstractDsDeployer.java:430)
>         at org.jboss.jca.deployers.common.AbstractDsDeployer.createObjectsAndInjectValue(AbstractDsDeployer.java:283)
>         at org.jboss.as.connector.subsystems.datasources.AbstractDataSourceService$AS7DataSourceDeployer.deploy(AbstractDataSourceService.java:310)
>         at org.jboss.as.connector.subsystems.datasources.AbstractDataSourceService.start(AbstractDataSourceService.java:124)
>         at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948)
>         at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881)
>         at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_51]
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_51]
>         at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_51]
> 14:33:00,236 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-3) MSC000001: Failed to start service jboss.data-source.java:jboss/jdbc/fai-bfsa: org.jboss.msc.service.StartException in service jboss.data-source.java:jboss/jdbc/fai-bfsa: JBAS010433: Error during the deployment of fai-bfsa
>         at org.jboss.as.connector.subsystems.datasources.AbstractDataSourceService.start(AbstractDataSourceService.java:131)
>         at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) [jboss-msc-1.2.0.Final.jar:1.2.0.Final]
>         at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) [jboss-msc-1.2.0.Final.jar:1.2.0.Final]
>         at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_51]
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_51]
>         at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_51]
> Caused by: org.jboss.msc.service.StartException in anonymous service: JBAS010432: Unable to start the ds because it generated more than one cf
>         at org.jboss.as.connector.subsystems.datasources.AbstractDataSourceService.start(AbstractDataSourceService.java:126)
>         ... 5 more
> 14:33:00,242 INFO  [org.jboss.as.controller] (XNIO-4 task-2) JBAS014774: Servicestatus report
> JBAS014775:    New missing/unsatisfied dependencies:
>       service jboss.data-source.reference-factory.fai-bfsa (missing) dependents:[service jboss.naming.context.java.jboss.jdbc.fai-bfsa]
>       service jboss.data-source-config.fai-bfsa (missing) dependents: [service jboss.data-source.java:jboss/jdbc/fai-bfsa]
> JBAS014777:   Services which failed to start:      service jboss.data-source.java:jboss/jdbc/fai-bfsa
> {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

From issues at jboss.org  Wed Mar 12 13:37:11 2014
From: issues at jboss.org (Farah Juma (JIRA))
Date: Wed, 12 Mar 2014 13:37:11 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3044) Mojarra's @ViewScoped
 implementation is not cluster-aware resulting in NotSerializableException
In-Reply-To: <JIRA.12533615.1393599715000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12533615.1393599715000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12533615.1393599715000.9735.1394645831281@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-3044?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12952414#comment-12952414 ] 

Farah Juma commented on WFLY-3044:
----------------------------------

[~rhusar] I just took a look at the JSF TCK signature tests. It turns out that the API change for JAVASERVERFACES-3191 will result in a signature test failure since the test expects ViewScoped to be annotated with @NormalScope(passivating = false).
                
> Mojarra's @ViewScoped implementation is not cluster-aware resulting in NotSerializableException
> -----------------------------------------------------------------------------------------------
>
>                 Key: WFLY-3044
>                 URL: https://issues.jboss.org/browse/WFLY-3044
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JSF
>    Affects Versions: 8.0.0.Final
>            Reporter: Radoslav Husar
>            Assignee: Radoslav Husar
>            Priority: Critical
>             Fix For: 8.0.1.Final
>
>
> The problem is in ViewScopeContextManager, namely 
> {code}
>             getContextMap(facesContext).put(contextual, new ViewScopeContextObject(contextual, creational, name));
> {code}
> probably it needs an artificial ID generated to serve as a key.
> Also the ViewScopeContextObject needs to be serializable as well among other things
> {code}
> class ViewScopeContextObject {
> {code}
> Issue manifests as
> {noformat}[Server:server-one] 19:22:41,564 ERROR [org.infinispan.interceptors.InvocationContextInterceptor] (default task-15) ISPN000136: Execution error: org.infinispan.commons.CacheException: java.lang.RuntimeException: Failure to marshal argument(s)  
> [Server:server-one] at org.infinispan.commons.util.Util.rewrapAsCacheException(Util.java:581)  
> ...  
> [Server:server-one] at org.infinispan.transaction.tm.DummyTransaction.notifyAfterCompletion(DummyTransaction.java:263)  
> [Server:server-one] at org.infinispan.transaction.tm.DummyTransaction.runCommitTx(DummyTransaction.java:312)  
> [Server:server-one] at org.infinispan.transaction.tm.DummyTransaction.commit(DummyTransaction.java:69)  
> [Server:server-one] at org.infinispan.transaction.tm.DummyBaseTransactionManager.commit(DummyBaseTransactionManager.java:80)  
> [Server:server-one] at org.infinispan.batch.BatchContainer.resolveTransaction(BatchContainer.java:101)  
> [Server:server-one] at org.infinispan.batch.BatchContainer.endBatch(BatchContainer.java:83)  
> [Server:server-one] at org.infinispan.batch.BatchContainer.endBatch(BatchContainer.java:64)  
> [Server:server-one] at org.infinispan.CacheImpl.endBatch(CacheImpl.java:777)  
> [Server:server-one] at org.infinispan.AbstractDelegatingCache.endBatch(AbstractDelegatingCache.java:53)  
> [Server:server-one] at org.wildfly.clustering.web.infinispan.InfinispanBatcher$1.end(InfinispanBatcher.java:56)  
> [Server:server-one] at org.wildfly.clustering.web.infinispan.InfinispanBatcher$1.close(InfinispanBatcher.java:46)  
> [Server:server-one] at org.wildfly.clustering.web.undertow.session.DistributableSession.requestDone(DistributableSession.java:72)  
> [Server:server-one] at io.undertow.servlet.spec.ServletContextImpl.updateSessionAccessTime(ServletContextImpl.java:704) [undertow-servlet-1.0.0.Final.jar:1.0.0.Final]  
> [Server:server-one] at io.undertow.servlet.spec.HttpServletResponseImpl.responseDone(HttpServletResponseImpl.java:522) [undertow-servlet-1.0.0.Final.jar:1.0.0.Final]  
> [Server:server-one] at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:287) [undertow-servlet-1.0.0.Final.jar:1.0.0.Final]  
> [Server:server-one] at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:227) [undertow-servlet-1.0.0.Final.jar:1.0.0.Final]  
> [Server:server-one] at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:73) [undertow-servlet-1.0.0.Final.jar:1.0.0.Final]  
> [Server:server-one] at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:146) [undertow-servlet-1.0.0.Final.jar:1.0.0.Final]  
> [Server:server-one] at io.undertow.server.Connectors.executeRootHandler(Connectors.java:168) [undertow-core-1.0.0.Final.jar:1.0.0.Final]  
> [Server:server-one] at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:687) [undertow-core-1.0.0.Final.jar:1.0.0.Final]  
> [Server:server-one] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_51]  
> [Server:server-one] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_51]  
> [Server:server-one] at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_51]  
> [Server:server-one] Caused by: java.lang.RuntimeException: Failure to marshal argument(s)  
> [Server:server-one] at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.marshallCall(CommandAwareRpcDispatcher.java:333)  
> [Server:server-one] at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.processSingleCall(CommandAwareRpcDispatcher.java:352)  
> [Server:server-one] at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.invokeRemoteCommand(CommandAwareRpcDispatcher.java:167)  
> [Server:server-one] ... 76 more  
> [Server:server-one] Caused by: org.infinispan.commons.marshall.NotSerializableException: org.jboss.weld.bean.ManagedBean  
> [Server:server-one] Caused by: an exception which occurred:  
> [Server:server-one] in object java.util.HashMap at b37422bb  
> [Server:server-one] in object org.jboss.as.clustering.marshalling.SimpleMarshalledValue at b37422bb  
> [Server:server-one] in object org.infinispan.commands.write.PutKeyValueCommand at db517a36  
> [Server:server-one] in object org.infinispan.commands.tx.PrepareCommand at 6fa34718  
> {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

From issues at jboss.org  Wed Mar 12 14:21:11 2014
From: issues at jboss.org (Aaron Ogburn (JIRA))
Date: Wed, 12 Mar 2014 14:21:11 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBMESSAGING-1941) Messaging deadlocks on
 AspectManager
In-Reply-To: <JIRA.12484258.1360189635000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12484258.1360189635000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12484258.1360189635000.9998.1394648471893@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JBMESSAGING-1941?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12952435#comment-12952435 ] 

Aaron Ogburn commented on JBMESSAGING-1941:
-------------------------------------------

Committed. r8621
                
> Messaging deadlocks on AspectManager
> ------------------------------------
>
>                 Key: JBMESSAGING-1941
>                 URL: https://issues.jboss.org/browse/JBMESSAGING-1941
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 1.4.8.SP9
>         Environment: -JBoss Enterprise Application Platform (EAP) 5
>            Reporter: Aaron Ogburn
>         Attachments: 00779442testpatch.diff, JBMESSAGING-1941.diff
>
>
> Messaging can stall JBoss at start up.  The hang occurs as the main thread blocks in different locations in JMS trying to acquire the AspectManager instance lock:
> {noformat} 
> "main" prio=10 tid=0x00007fe69c1e1000 nid=0x3613 waiting for monitor entry [0x00007fe6828e5000]
>    java.lang.Thread.State: BLOCKED (on object monitor)
>         at org.jboss.aop.AspectManager.getAdvisor(AspectManager.java:728)
>         - waiting to lock <0x00000000a5e43e50> (a org.jboss.aop.AspectManager)
>         at org.jboss.jms.server.endpoint.advised.SessionAdvised.<clinit>(SessionAdvised.java)
>         at org.jboss.jms.server.endpoint.ServerConnectionEndpoint.createSessionDelegate(ServerConnectionEndpoint.java:273)
>         - locked <0x00000000a5600f48> (a org.jboss.aop.asintegration.jboss5.ScopedVFSClassLoaderDomain)
>         at org.jboss.jms.server.endpoint.ServerConnectionEndpoint.createSessionDelegate(ServerConnectionEndpoint.java:229)
> {noformat} 
> Since the main thread is stalled, so too is start up.  This lock is always held by another making a similar call like so:
> {noformat} 
> "WorkManager(2)-1" daemon prio=10 tid=0x00007fe62dd96000 nid=0x363e in
> Object.wait() [0x00007fe68029a000]
>    java.lang.Thread.State: RUNNABLE
>         at org.jboss.jms.server.endpoint.ServerConnectionEndpoint.createSessionDelegate(ServerConnectionEndpoint.java:273)
>         - locked <0x00000000a5e43e50> (a org.jboss.aop.AspectManager)
>         at org.jboss.jms.server.endpoint.ServerConnectionEndpoint.createSessionDelegate(ServerConnectionEndpoint.java:229)
> {noformat} 
> The code there at line 273 is simple enough and shouldn't cause a long stall:
> {code:title=org.jboss.jms.server.endpoint.ServerConnectionEndpoint.java|borderStyle=solid}
>          synchronized (AspectManager.instance())
>          {
>             advised = new SessionAdvised(ep);     // line 273
>          }
> {code}
> Nonetheless, it does clearly hang at this line as WorkManager(2)-1 never progresses.  There's no GC/CPU issues or anything of that nature, but we get a slight in the thread dump as WorkManager(2)-1 is shown to be in Object.wait().  Checking the thread through pstack, we can see the issue.  It is waiting in native/JDK level operations required to initialize the SessionAdvised class:
> {noformat}
> Thread 2 (Thread 0x7fe68029d700 (LWP 13886)):
> #0  0x0000003b3e40b43c in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
> #1  0x00007fe6a12d447e in os:latformEvent:ark() () from /opt/app/jvm/jdk1.6.0_38/jre/lib/amd64/server/libjvm.so
> #2  0x00007fe6a12c54fa in ObjectMonitor::wait(long, bool, Thread*) () from /opt/app/jvm/jdk1.6.0_38/jre/lib/amd64/server/libjvm.so
> #3  0x00007fe6a13ab5f0 in ObjectSynchronizer::waitUninterruptibly(Handle, long, Thread*) () from /opt/app/jvm/jdk1.6.0_38/jre/lib/amd64/server/libjvm.so
> #4  0x00007fe6a107115b in instanceKlass::initialize_impl(instanceKlassHandle, Thread*) () from /opt/app/jvm/jdk1.6.0_38/jre/lib/amd64/server/libjvm.so
> #5  0x00007fe6a107077a in instanceKlass::initialize(Thread*) () from /opt/app/jvm/jdk1.6.0_38/jre/lib/amd64/server/libjvm.so
> #6  0x00007fe6a1097c5c in InterpreterRuntime::_new(JavaThread*, constantPoolOopDesc*, int) () from /opt/app/jvm/jdk1.6.0_38/jre/lib/amd64/server/libjvm.so
> {noformat}
> These calls are naturally synchronized internally in the JVM so only one thread can proceed through initialization of a class at a given time.  Checking for any threads in process of initializing SessionAdvised, we can see only the main thread is.  But the main thread is still blocked for the AspectManager lock.
> So we have a deadlock here.  The main thread holds the initialization lock while waiting for the AspectManager lock, while the WorkManager(2)-1 thread holds the AspectManager lock while waiting for the initialization lock.
> The initialization of SessionAdvised is wrapped in the synchronized block so the main thread should not have been able to proceed into the initialization at all without already possessing the AspectManager lock.  It locks the ScopedVFSClassLoaderDomain, which extends the AspectManager.  This is different from the actual AspectManager though that main tries to lock in the clinit call and that it deadlocks on.

--
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

From issues at jboss.org  Wed Mar 12 16:27:10 2014
From: issues at jboss.org (Richard Achmatowicz (JIRA))
Date: Wed, 12 Mar 2014 16:27:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3106) Infinispan cache statistics
 cannot be enabled/disabled independently of the cache manager statistics
In-Reply-To: <JIRA.12534838.1394655920000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534838.1394655920000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534838.1394655920000.10502.1394656030802@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-3106?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Richard Achmatowicz updated WFLY-3106:
--------------------------------------

    Summary: Infinispan cache statistics cannot be enabled/disabled independently of the cache manager statistics      (was: Infinispan cache statistics cannot be enabled/disabled independently of the cache manage statistics    )

    
> Infinispan cache statistics cannot be enabled/disabled independently of the cache manager statistics    
> --------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-3106
>                 URL: https://issues.jboss.org/browse/WFLY-3106
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Clustering
>    Affects Versions: 8.0.0.Final
>            Reporter: Richard Achmatowicz
>            Assignee: Richard Achmatowicz
>             Fix For: 8.0.1.Final
>
>
> The Infinispan subsystem allows enabling and disabling the collection of statistics for cache managers and caches via the "statistics-enabled" management API attribute.
> It is possible to set statistics-enabled attributes independently for cache managers and caches in the management API, but when checking the Infinispan MBeans, we see that statistics are either enabled for cache managers and their caches, or disabled for cache managers and caches.  

--
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

From issues at jboss.org  Wed Mar 12 16:27:10 2014
From: issues at jboss.org (Richard Achmatowicz (JIRA))
Date: Wed, 12 Mar 2014 16:27:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3106) Infinispan cache statistics
 cannot be enabled/disabled independently of the cache manage statistics
In-Reply-To: <JIRA.12534838.1394655920741@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534838.1394655920741@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534838.1394655920741.10500.1394656030707@jira02.app.mwc.hst.phx2.redhat.com>

Richard Achmatowicz created WFLY-3106:
-----------------------------------------

             Summary: Infinispan cache statistics cannot be enabled/disabled independently of the cache manage statistics    
                 Key: WFLY-3106
                 URL: https://issues.jboss.org/browse/WFLY-3106
             Project: WildFly
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Clustering
    Affects Versions: 8.0.0.Final
            Reporter: Richard Achmatowicz
            Assignee: Richard Achmatowicz
             Fix For: 8.0.1.Final


The Infinispan subsystem allows enabling and disabling the collection of statistics for cache managers and caches via the "statistics-enabled" management API attribute.

It is possible to set statistics-enabled attributes independently for cache managers and caches in the management API, but when checking the Infinispan MBeans, we see that statistics are either enabled for cache managers and their caches, or disabled for cache managers and caches.  



--
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

From issues at jboss.org  Wed Mar 12 16:31:10 2014
From: issues at jboss.org (Richard Achmatowicz (JIRA))
Date: Wed, 12 Mar 2014 16:31:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3106) Infinispan cache statistics
 cannot be enabled/disabled independently of the cache manager statistics
In-Reply-To: <JIRA.12534838.1394655920000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534838.1394655920000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534838.1394655920000.10512.1394656270613@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-3106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12952469#comment-12952469 ] 

Richard Achmatowicz commented on WFLY-3106:
-------------------------------------------

The problem lies with this line in CacheConfigurationService:
{noformat}     this.builder.jmxStatistics().enabled(this.dependencies.getCacheContainer().getCacheManagerConfiguration().globalJmxStatistics().enabled());
{noformat}
 
In other words, when setting up the cache configuration service, which exists for every cache, CacheConfigurationService sets the cache's statistics enabled setting to match that of its cache manager. This has the effect of overriding any value of statistics-enabled which was set in the management API for the cache.

Removing this line fixes the problem.

                
> Infinispan cache statistics cannot be enabled/disabled independently of the cache manager statistics    
> --------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-3106
>                 URL: https://issues.jboss.org/browse/WFLY-3106
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Clustering
>    Affects Versions: 8.0.0.Final
>            Reporter: Richard Achmatowicz
>            Assignee: Richard Achmatowicz
>             Fix For: 8.0.1.Final
>
>
> The Infinispan subsystem allows enabling and disabling the collection of statistics for cache managers and caches via the "statistics-enabled" management API attribute.
> It is possible to set statistics-enabled attributes independently for cache managers and caches in the management API, but when checking the Infinispan MBeans, we see that statistics are either enabled for cache managers and their caches, or disabled for cache managers and caches.  

--
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

From issues at jboss.org  Wed Mar 12 16:39:10 2014
From: issues at jboss.org (Richard Achmatowicz (JIRA))
Date: Wed, 12 Mar 2014 16:39:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3106) Infinispan cache statistics
 cannot be enabled/disabled independently of the cache manager statistics
In-Reply-To: <JIRA.12534838.1394655920000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534838.1394655920000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534838.1394655920000.10528.1394656750638@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-3106?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Richard Achmatowicz updated WFLY-3106:
--------------------------------------

    Git Pull Request: https://github.com/wildfly/wildfly/pull/6031

    
> Infinispan cache statistics cannot be enabled/disabled independently of the cache manager statistics    
> --------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-3106
>                 URL: https://issues.jboss.org/browse/WFLY-3106
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Clustering
>    Affects Versions: 8.0.0.Final
>            Reporter: Richard Achmatowicz
>            Assignee: Richard Achmatowicz
>             Fix For: 8.0.1.Final
>
>
> The Infinispan subsystem allows enabling and disabling the collection of statistics for cache managers and caches via the "statistics-enabled" management API attribute.
> It is possible to set statistics-enabled attributes independently for cache managers and caches in the management API, but when checking the Infinispan MBeans, we see that statistics are either enabled for cache managers and their caches, or disabled for cache managers and caches.  

--
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

From issues at jboss.org  Wed Mar 12 16:41:10 2014
From: issues at jboss.org (Richard Achmatowicz (JIRA))
Date: Wed, 12 Mar 2014 16:41:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3106) Infinispan cache statistics
 cannot be enabled/disabled independently of the cache manager statistics
In-Reply-To: <JIRA.12534838.1394655920000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534838.1394655920000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534838.1394655920000.10533.1394656870597@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-3106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12952471#comment-12952471 ] 

Richard Achmatowicz commented on WFLY-3106:
-------------------------------------------

This has been verified manually.

                
> Infinispan cache statistics cannot be enabled/disabled independently of the cache manager statistics    
> --------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-3106
>                 URL: https://issues.jboss.org/browse/WFLY-3106
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Clustering
>    Affects Versions: 8.0.0.Final
>            Reporter: Richard Achmatowicz
>            Assignee: Richard Achmatowicz
>             Fix For: 8.0.1.Final
>
>
> The Infinispan subsystem allows enabling and disabling the collection of statistics for cache managers and caches via the "statistics-enabled" management API attribute.
> It is possible to set statistics-enabled attributes independently for cache managers and caches in the management API, but when checking the Infinispan MBeans, we see that statistics are either enabled for cache managers and their caches, or disabled for cache managers and caches.  

--
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

From issues at jboss.org  Wed Mar 12 18:31:10 2014
From: issues at jboss.org (Shelly McGowan (JIRA))
Date: Wed, 12 Mar 2014 18:31:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBEE-151) Missing doPrivileged block(s)
 around getContextClassLoader
In-Reply-To: <JIRA.12534710.1394563445000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534710.1394563445000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534710.1394563445000.10900.1394663470622@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JBEE-151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12952489#comment-12952489 ] 

Shelly McGowan commented on JBEE-151:
-------------------------------------

Upstream patch committed:
https://github.com/jboss/jboss-el-api_spec/commit/88e00f1d2e901cf6945471c573583fe0f0d8d58d
                
>  Missing doPrivileged block(s) around getContextClassLoader
> -----------------------------------------------------------
>
>                 Key: JBEE-151
>                 URL: https://issues.jboss.org/browse/JBEE-151
>             Project: JBoss JavaEE Spec APIs
>          Issue Type: Bug
>          Components: general
>            Reporter: Carlo de Wolf
>            Assignee: Shelly McGowan
>
> jboss-el-api_2.2_spec-1.0.2.Final-redhat-1.jar:1.0.2.Final-redhat-1
> {code}
> 12:56:34,897 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[default-host].[/read-props].[jsp]] (http-/127.0.0.1:8080-4) JBWEB000236: Servlet.service() for servlet jsp threw exception: java.security.AccessControlException: access denied ("java.lang.RuntimePermission" "getClassLoader")
> 	at java.security.AccessControlContext.checkPermission(AccessControlContext.java:372) [rt.jar:1.7.0_45]
> 	at java.security.AccessController.checkPermission(AccessController.java:559) [rt.jar:1.7.0_45]
> 	at java.lang.SecurityManager.checkPermission(SecurityManager.java:549) [rt.jar:1.7.0_45]
> 	at java.lang.ClassLoader.checkClassLoaderPermission(ClassLoader.java:1561) [rt.jar:1.7.0_45]
> 	at java.lang.Thread.getContextClassLoader(Thread.java:1472) [rt.jar:1.7.0_45]
> 	at javax.el.FactoryFinder.find(FactoryFinder.java:130) [jboss-el-api_2.2_spec-1.0.2.Final-redhat-1.jar:1.0.2.Final-redhat-1]
> 	at javax.el.ExpressionFactory.newInstance(ExpressionFactory.java:185) [jboss-el-api_2.2_spec-1.0.2.Final-redhat-1.jar:1.0.2.Final-redhat-1]
> 	at javax.el.ExpressionFactory.newInstance(ExpressionFactory.java:156) [jboss-el-api_2.2_spec-1.0.2.Final-redhat-1.jar:1.0.2.Final-redhat-1]
> 	at org.apache.jasper.runtime.JspApplicationContextImpl.<init>(JspApplicationContextImpl.java:48) [jbossweb-7.4.0.Beta4.jar:7.4.0.Beta4]
> {code}

--
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

From issues at jboss.org  Wed Mar 12 18:39:10 2014
From: issues at jboss.org (Shelly McGowan (JIRA))
Date: Wed, 12 Mar 2014 18:39:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBEE-151) Missing doPrivileged block(s)
 around getContextClassLoader
In-Reply-To: <JIRA.12534710.1394563445000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534710.1394563445000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534710.1394563445000.10902.1394663950536@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBEE-151?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Shelly McGowan updated JBEE-151:
--------------------------------

    Fix Version/s: jboss-el-api_2.2_spec-1.0.4.Final
      Component/s: jboss-el-api
                       (was: general)

    
>  Missing doPrivileged block(s) around getContextClassLoader
> -----------------------------------------------------------
>
>                 Key: JBEE-151
>                 URL: https://issues.jboss.org/browse/JBEE-151
>             Project: JBoss JavaEE Spec APIs
>          Issue Type: Bug
>          Components: jboss-el-api
>            Reporter: Carlo de Wolf
>            Assignee: Shelly McGowan
>             Fix For: jboss-el-api_2.2_spec-1.0.4.Final
>
>
> jboss-el-api_2.2_spec-1.0.2.Final-redhat-1.jar:1.0.2.Final-redhat-1
> {code}
> 12:56:34,897 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[default-host].[/read-props].[jsp]] (http-/127.0.0.1:8080-4) JBWEB000236: Servlet.service() for servlet jsp threw exception: java.security.AccessControlException: access denied ("java.lang.RuntimePermission" "getClassLoader")
> 	at java.security.AccessControlContext.checkPermission(AccessControlContext.java:372) [rt.jar:1.7.0_45]
> 	at java.security.AccessController.checkPermission(AccessController.java:559) [rt.jar:1.7.0_45]
> 	at java.lang.SecurityManager.checkPermission(SecurityManager.java:549) [rt.jar:1.7.0_45]
> 	at java.lang.ClassLoader.checkClassLoaderPermission(ClassLoader.java:1561) [rt.jar:1.7.0_45]
> 	at java.lang.Thread.getContextClassLoader(Thread.java:1472) [rt.jar:1.7.0_45]
> 	at javax.el.FactoryFinder.find(FactoryFinder.java:130) [jboss-el-api_2.2_spec-1.0.2.Final-redhat-1.jar:1.0.2.Final-redhat-1]
> 	at javax.el.ExpressionFactory.newInstance(ExpressionFactory.java:185) [jboss-el-api_2.2_spec-1.0.2.Final-redhat-1.jar:1.0.2.Final-redhat-1]
> 	at javax.el.ExpressionFactory.newInstance(ExpressionFactory.java:156) [jboss-el-api_2.2_spec-1.0.2.Final-redhat-1.jar:1.0.2.Final-redhat-1]
> 	at org.apache.jasper.runtime.JspApplicationContextImpl.<init>(JspApplicationContextImpl.java:48) [jbossweb-7.4.0.Beta4.jar:7.4.0.Beta4]
> {code}

--
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

From issues at jboss.org  Wed Mar 12 19:55:11 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 12 Mar 2014 19:55:11 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2644) Java heap space exceeded
 looping connect/disconnect cycle
In-Reply-To: <JIRA.12527822.1386863108000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12527822.1386863108000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12527822.1386863108000.10964.1394668511328@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2644?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12952493#comment-12952493 ] 

RH Bugzilla Integration commented on WFLY-2644:
-----------------------------------------------

Paul Gier <pgier at redhat.com> changed the Status of [bug 1037574|https://bugzilla.redhat.com/show_bug.cgi?id=1037574] from MODIFIED to ON_QA
                
> Java heap space exceeded looping connect/disconnect cycle
> ---------------------------------------------------------
>
>                 Key: WFLY-2644
>                 URL: https://issues.jboss.org/browse/WFLY-2644
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: CLI
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Alexey Loubyansky
>            Assignee: Alexey Loubyansky
>             Fix For: 8.0.0.Final
>
>
> CLIModelControllerClient implementation is not cleaning up something related to connection handling which leads to OOME repeating a cycle of ensureConnected(...) and close(). On my laptop it happens after around 1400 iterations.

--
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

From issues at jboss.org  Wed Mar 12 19:55:11 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 12 Mar 2014 19:55:11 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3099) management authorization
 throws an exception when an LDAP group contains a slash/backslash character
In-Reply-To: <JIRA.12534652.1394538171000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534652.1394538171000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534652.1394538171000.10968.1394668511537@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-3099?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12952494#comment-12952494 ] 

RH Bugzilla Integration commented on WFLY-3099:
-----------------------------------------------

Paul Gier <pgier at redhat.com> changed the Status of [bug 1074560|https://bugzilla.redhat.com/show_bug.cgi?id=1074560] from MODIFIED to ON_QA
                
> management authorization throws an exception when an LDAP group contains a slash/backslash character
> ----------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-3099
>                 URL: https://issues.jboss.org/browse/WFLY-3099
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>    Affects Versions: 8.0.0.Final
>            Reporter: Tom Fonteyne
>            Assignee: Tom Fonteyne
>
> management authorization throws an exception when an LDAP group contains a slash/backslash character

--
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

From issues at jboss.org  Wed Mar 12 19:55:11 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 12 Mar 2014 19:55:11 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3078) directory-grouping
 configuration is not getting persisted via CLI when no servers defined
In-Reply-To: <JIRA.12534347.1394159920000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534347.1394159920000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534347.1394159920000.10975.1394668511986@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-3078?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12952496#comment-12952496 ] 

RH Bugzilla Integration commented on WFLY-3078:
-----------------------------------------------

Paul Gier <pgier at redhat.com> changed the Status of [bug 1073715|https://bugzilla.redhat.com/show_bug.cgi?id=1073715] from MODIFIED to ON_QA
                
> directory-grouping configuration is not getting persisted via CLI when no servers defined
> -----------------------------------------------------------------------------------------
>
>                 Key: WFLY-3078
>                 URL: https://issues.jboss.org/browse/WFLY-3078
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>    Affects Versions: 8.0.0.Final
>         Environment: All Operating System
>            Reporter: Jay Kumar SenSharma
>            Assignee: Emanuel Muckenhuber
>             Fix For: 8.0.1.Final
>
>
> - If none of the servers are defined in "host.xml" (means <servers></servers> empty tag is present) and if the user tries to run the following CLI command to change the "directory-grouping" to  "by-type"  then the value is not persisted in the configuration file (host.xml) and the <servers></servers>  tag is also removed from the host.xml
> {code}
> /host=master/:write-attribute(name=directory-grouping,value=by-type)
> {code}
> - The value of "directory-grouping" is stored "in memory" so this change does not survive the host restart.

--
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

From issues at jboss.org  Wed Mar 12 19:55:12 2014
From: issues at jboss.org (Shelly McGowan (JIRA))
Date: Wed, 12 Mar 2014 19:55:12 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBEE-151) Missing doPrivileged block(s)
 around getContextClassLoader
In-Reply-To: <JIRA.12534710.1394563445000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534710.1394563445000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534710.1394563445000.10984.1394668512415@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JBEE-151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12952489#comment-12952489 ] 

Shelly McGowan edited comment on JBEE-151 at 3/12/14 7:54 PM:
--------------------------------------------------------------

Upstream patch committed to jboss-el-api_2.2 branch:
https://github.com/jboss/jboss-el-api_spec/commit/88e00f1d2e901cf6945471c573583fe0f0d8d58d


                
      was (Author: shelly.mcgowan):
    Upstream patch committed:
https://github.com/jboss/jboss-el-api_spec/commit/88e00f1d2e901cf6945471c573583fe0f0d8d58d
                  
>  Missing doPrivileged block(s) around getContextClassLoader
> -----------------------------------------------------------
>
>                 Key: JBEE-151
>                 URL: https://issues.jboss.org/browse/JBEE-151
>             Project: JBoss JavaEE Spec APIs
>          Issue Type: Bug
>          Components: jboss-el-api
>            Reporter: Carlo de Wolf
>            Assignee: Shelly McGowan
>             Fix For: jboss-el-api_2.2_spec-1.0.4.Final
>
>
> jboss-el-api_2.2_spec-1.0.2.Final-redhat-1.jar:1.0.2.Final-redhat-1
> {code}
> 12:56:34,897 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[default-host].[/read-props].[jsp]] (http-/127.0.0.1:8080-4) JBWEB000236: Servlet.service() for servlet jsp threw exception: java.security.AccessControlException: access denied ("java.lang.RuntimePermission" "getClassLoader")
> 	at java.security.AccessControlContext.checkPermission(AccessControlContext.java:372) [rt.jar:1.7.0_45]
> 	at java.security.AccessController.checkPermission(AccessController.java:559) [rt.jar:1.7.0_45]
> 	at java.lang.SecurityManager.checkPermission(SecurityManager.java:549) [rt.jar:1.7.0_45]
> 	at java.lang.ClassLoader.checkClassLoaderPermission(ClassLoader.java:1561) [rt.jar:1.7.0_45]
> 	at java.lang.Thread.getContextClassLoader(Thread.java:1472) [rt.jar:1.7.0_45]
> 	at javax.el.FactoryFinder.find(FactoryFinder.java:130) [jboss-el-api_2.2_spec-1.0.2.Final-redhat-1.jar:1.0.2.Final-redhat-1]
> 	at javax.el.ExpressionFactory.newInstance(ExpressionFactory.java:185) [jboss-el-api_2.2_spec-1.0.2.Final-redhat-1.jar:1.0.2.Final-redhat-1]
> 	at javax.el.ExpressionFactory.newInstance(ExpressionFactory.java:156) [jboss-el-api_2.2_spec-1.0.2.Final-redhat-1.jar:1.0.2.Final-redhat-1]
> 	at org.apache.jasper.runtime.JspApplicationContextImpl.<init>(JspApplicationContextImpl.java:48) [jbossweb-7.4.0.Beta4.jar:7.4.0.Beta4]
> {code}

--
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

From issues at jboss.org  Wed Mar 12 19:57:10 2014
From: issues at jboss.org (Shelly McGowan (JIRA))
Date: Wed, 12 Mar 2014 19:57:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBEE-151) Missing doPrivileged block(s)
 around getContextClassLoader
In-Reply-To: <JIRA.12534710.1394563445000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534710.1394563445000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534710.1394563445000.10987.1394668630538@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JBEE-151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12952498#comment-12952498 ] 

Shelly McGowan commented on JBEE-151:
-------------------------------------

Fix also committed to master branch for jboss-el-api_3.0:
https://github.com/jboss/jboss-el-api_spec/commit/c82e83c9c78d25abd839f6432ff99527b1e0017c

                
>  Missing doPrivileged block(s) around getContextClassLoader
> -----------------------------------------------------------
>
>                 Key: JBEE-151
>                 URL: https://issues.jboss.org/browse/JBEE-151
>             Project: JBoss JavaEE Spec APIs
>          Issue Type: Bug
>          Components: jboss-el-api
>            Reporter: Carlo de Wolf
>            Assignee: Shelly McGowan
>             Fix For: jboss-el-api_2.2_spec-1.0.4.Final
>
>
> jboss-el-api_2.2_spec-1.0.2.Final-redhat-1.jar:1.0.2.Final-redhat-1
> {code}
> 12:56:34,897 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[default-host].[/read-props].[jsp]] (http-/127.0.0.1:8080-4) JBWEB000236: Servlet.service() for servlet jsp threw exception: java.security.AccessControlException: access denied ("java.lang.RuntimePermission" "getClassLoader")
> 	at java.security.AccessControlContext.checkPermission(AccessControlContext.java:372) [rt.jar:1.7.0_45]
> 	at java.security.AccessController.checkPermission(AccessController.java:559) [rt.jar:1.7.0_45]
> 	at java.lang.SecurityManager.checkPermission(SecurityManager.java:549) [rt.jar:1.7.0_45]
> 	at java.lang.ClassLoader.checkClassLoaderPermission(ClassLoader.java:1561) [rt.jar:1.7.0_45]
> 	at java.lang.Thread.getContextClassLoader(Thread.java:1472) [rt.jar:1.7.0_45]
> 	at javax.el.FactoryFinder.find(FactoryFinder.java:130) [jboss-el-api_2.2_spec-1.0.2.Final-redhat-1.jar:1.0.2.Final-redhat-1]
> 	at javax.el.ExpressionFactory.newInstance(ExpressionFactory.java:185) [jboss-el-api_2.2_spec-1.0.2.Final-redhat-1.jar:1.0.2.Final-redhat-1]
> 	at javax.el.ExpressionFactory.newInstance(ExpressionFactory.java:156) [jboss-el-api_2.2_spec-1.0.2.Final-redhat-1.jar:1.0.2.Final-redhat-1]
> 	at org.apache.jasper.runtime.JspApplicationContextImpl.<init>(JspApplicationContextImpl.java:48) [jbossweb-7.4.0.Beta4.jar:7.4.0.Beta4]
> {code}

--
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

From issues at jboss.org  Wed Mar 12 19:59:10 2014
From: issues at jboss.org (Shelly McGowan (JIRA))
Date: Wed, 12 Mar 2014 19:59:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBEE-151) Missing doPrivileged block(s)
 around getContextClassLoader
In-Reply-To: <JIRA.12534710.1394563445000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534710.1394563445000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534710.1394563445000.10990.1394668750546@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBEE-151?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Shelly McGowan updated JBEE-151:
--------------------------------

    Fix Version/s: jboss-el-api_3.0_spec-1.0.1.Final

    
>  Missing doPrivileged block(s) around getContextClassLoader
> -----------------------------------------------------------
>
>                 Key: JBEE-151
>                 URL: https://issues.jboss.org/browse/JBEE-151
>             Project: JBoss JavaEE Spec APIs
>          Issue Type: Bug
>          Components: jboss-el-api
>            Reporter: Carlo de Wolf
>            Assignee: Shelly McGowan
>             Fix For: jboss-el-api_2.2_spec-1.0.4.Final, jboss-el-api_3.0_spec-1.0.1.Final
>
>
> jboss-el-api_2.2_spec-1.0.2.Final-redhat-1.jar:1.0.2.Final-redhat-1
> {code}
> 12:56:34,897 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[default-host].[/read-props].[jsp]] (http-/127.0.0.1:8080-4) JBWEB000236: Servlet.service() for servlet jsp threw exception: java.security.AccessControlException: access denied ("java.lang.RuntimePermission" "getClassLoader")
> 	at java.security.AccessControlContext.checkPermission(AccessControlContext.java:372) [rt.jar:1.7.0_45]
> 	at java.security.AccessController.checkPermission(AccessController.java:559) [rt.jar:1.7.0_45]
> 	at java.lang.SecurityManager.checkPermission(SecurityManager.java:549) [rt.jar:1.7.0_45]
> 	at java.lang.ClassLoader.checkClassLoaderPermission(ClassLoader.java:1561) [rt.jar:1.7.0_45]
> 	at java.lang.Thread.getContextClassLoader(Thread.java:1472) [rt.jar:1.7.0_45]
> 	at javax.el.FactoryFinder.find(FactoryFinder.java:130) [jboss-el-api_2.2_spec-1.0.2.Final-redhat-1.jar:1.0.2.Final-redhat-1]
> 	at javax.el.ExpressionFactory.newInstance(ExpressionFactory.java:185) [jboss-el-api_2.2_spec-1.0.2.Final-redhat-1.jar:1.0.2.Final-redhat-1]
> 	at javax.el.ExpressionFactory.newInstance(ExpressionFactory.java:156) [jboss-el-api_2.2_spec-1.0.2.Final-redhat-1.jar:1.0.2.Final-redhat-1]
> 	at org.apache.jasper.runtime.JspApplicationContextImpl.<init>(JspApplicationContextImpl.java:48) [jbossweb-7.4.0.Beta4.jar:7.4.0.Beta4]
> {code}

--
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

From issues at jboss.org  Thu Mar 13 03:42:10 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 13 Mar 2014 03:42:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3078) directory-grouping
 configuration is not getting persisted via CLI when no servers defined
In-Reply-To: <JIRA.12534347.1394159920000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534347.1394159920000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534347.1394159920000.11709.1394696530898@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-3078?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12952538#comment-12952538 ] 

RH Bugzilla Integration commented on WFLY-3078:
-----------------------------------------------

Petr Kremensky <pkremens at redhat.com> changed the Status of [bug 1073715|https://bugzilla.redhat.com/show_bug.cgi?id=1073715] from ON_QA to VERIFIED
                
> directory-grouping configuration is not getting persisted via CLI when no servers defined
> -----------------------------------------------------------------------------------------
>
>                 Key: WFLY-3078
>                 URL: https://issues.jboss.org/browse/WFLY-3078
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>    Affects Versions: 8.0.0.Final
>         Environment: All Operating System
>            Reporter: Jay Kumar SenSharma
>            Assignee: Emanuel Muckenhuber
>             Fix For: 8.0.1.Final
>
>
> - If none of the servers are defined in "host.xml" (means <servers></servers> empty tag is present) and if the user tries to run the following CLI command to change the "directory-grouping" to  "by-type"  then the value is not persisted in the configuration file (host.xml) and the <servers></servers>  tag is also removed from the host.xml
> {code}
> /host=master/:write-attribute(name=directory-grouping,value=by-type)
> {code}
> - The value of "directory-grouping" is stored "in memory" so this change does not survive the host restart.

--
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

From issues at jboss.org  Thu Mar 13 03:56:11 2014
From: issues at jboss.org (Michael Anstis (JIRA))
Date: Thu, 13 Mar 2014 03:56:11 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-450) Cannot use decimal
 formatters for integers in an excel decision table
In-Reply-To: <JIRA.12534705.1394557254000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534705.1394557254000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534705.1394557254000.11729.1394697371105@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/DROOLS-450?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12952543#comment-12952543 ] 

Michael Anstis commented on DROOLS-450:
---------------------------------------

What is the locale settings of the computer on which you produced the error? What is the locale of he XLS workbook you produced the error with?

I'm reluctant to merge your pull request until we better understand your scenario: forcing the DataFormatter(Locale.ENGLISH) might work in your scenario but IDK ATM whether it's sufficiently generic and will not cause other users with different locale settings more problems without understanding a few more things first.

                
> Cannot use decimal formatters for integers in an excel decision table
> ---------------------------------------------------------------------
>
>                 Key: DROOLS-450
>                 URL: https://issues.jboss.org/browse/DROOLS-450
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 6.0.1.Final
>            Reporter: Maxime Falaize
>            Assignee: Mark Proctor
>            Priority: Minor
>         Attachments: issue_example.png
>
>
> When I use decimal formatter in an excel action column for numbers that are in fact integers, I am getting this exception :
> {noformat}
> Exception in thread "main" java.lang.RuntimeException: Error while creating KieBase[Message [id=1, level=ERROR, path=com/sample/my_decision_table.xls, line=5, column=0
>    text=Rule Compilation error The method setParameter(double) in the type MyObject is not applicable for the arguments (int, int)]]
> 	at org.drools.compiler.kie.builder.impl.KieContainerImpl.getKieBase(KieContainerImpl.java:260)
> 	at org.drools.compiler.kie.builder.impl.KieContainerImpl.newKieSession(KieContainerImpl.java:400)
> 	at org.drools.compiler.kie.builder.impl.KieContainerImpl.newKieSession(KieContainerImpl.java:375)
> {noformat}
> Actually, the system uses the format number "1,00000" (with comma in french) instead of "1.00000" like it should use.
> This is causing by the line 174 in org.drools.decisiontable.parser.xls.ExcelParser :
> {code:java}
> if ( num - Math.round( num ) != 0 )
> {code}
> I don't understand why we use the formatted value when this test is not passed.
> I think the end users should have the possibility to keep the same formatter for the same column, with integers or not.

--
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

From issues at jboss.org  Thu Mar 13 04:52:10 2014
From: issues at jboss.org (Maxime Falaize (JIRA))
Date: Thu, 13 Mar 2014 04:52:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-450) Cannot use decimal
 formatters for integers in an excel decision table
In-Reply-To: <JIRA.12534705.1394557254000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534705.1394557254000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534705.1394557254000.11789.1394700730781@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/DROOLS-450?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12952554#comment-12952554 ] 

Maxime Falaize commented on DROOLS-450:
---------------------------------------

Hi Michael,

I think the problem is not the locale of the XLS file but the locale of the JRE. The DataFormatter is created with no relation to the xls workbook. I tested to reproduce the error with a different configuration in excel (settings to english locale) and the problem is still here. However, when I set the JRE default locale to English when I start my app (with Locale.setDefault(Locale.ENGLISH)), it works.

I am on a French Windows 7 (so french JRE). If you set your JRE Locale to FRENCH I think you could reproduce the error.

Maybe we can force the locale of the DateFormatter to English only for the numbers ? It would reduce the possibility of regressions.
                
> Cannot use decimal formatters for integers in an excel decision table
> ---------------------------------------------------------------------
>
>                 Key: DROOLS-450
>                 URL: https://issues.jboss.org/browse/DROOLS-450
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 6.0.1.Final
>            Reporter: Maxime Falaize
>            Assignee: Mark Proctor
>            Priority: Minor
>         Attachments: issue_example.png
>
>
> When I use decimal formatter in an excel action column for numbers that are in fact integers, I am getting this exception :
> {noformat}
> Exception in thread "main" java.lang.RuntimeException: Error while creating KieBase[Message [id=1, level=ERROR, path=com/sample/my_decision_table.xls, line=5, column=0
>    text=Rule Compilation error The method setParameter(double) in the type MyObject is not applicable for the arguments (int, int)]]
> 	at org.drools.compiler.kie.builder.impl.KieContainerImpl.getKieBase(KieContainerImpl.java:260)
> 	at org.drools.compiler.kie.builder.impl.KieContainerImpl.newKieSession(KieContainerImpl.java:400)
> 	at org.drools.compiler.kie.builder.impl.KieContainerImpl.newKieSession(KieContainerImpl.java:375)
> {noformat}
> Actually, the system uses the format number "1,00000" (with comma in french) instead of "1.00000" like it should use.
> This is causing by the line 174 in org.drools.decisiontable.parser.xls.ExcelParser :
> {code:java}
> if ( num - Math.round( num ) != 0 )
> {code}
> I don't understand why we use the formatted value when this test is not passed.
> I think the end users should have the possibility to keep the same formatter for the same column, with integers or not.

--
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

From issues at jboss.org  Thu Mar 13 04:58:12 2014
From: issues at jboss.org (Anton Giertli (JIRA))
Date: Thu, 13 Mar 2014 04:58:12 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-453) Allow KieSession globals
 configurable via kmodule.xml
In-Reply-To: <JIRA.12534852.1394701072783@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534852.1394701072783@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534852.1394701072783.11818.1394701092425@jira02.app.mwc.hst.phx2.redhat.com>

Anton Giertli created DROOLS-453:
------------------------------------

             Summary: Allow KieSession globals configurable via kmodule.xml
                 Key: DROOLS-453
                 URL: https://issues.jboss.org/browse/DROOLS-453
             Project: Drools
          Issue Type: Enhancement
      Security Level: Public (Everyone can see)
    Affects Versions: 6.0.0.Final
            Reporter: Anton Giertli
            Assignee: Mark Proctor
             Fix For: 6.1.0.Final


Looking at the current xsd of kmodule.xml
https://github.com/droolsjbpm/droolsjbpm-knowledge/blob/6.0.x/kie-api/src/main/resources/org/kie/api/kmodule.xsd

It is not possible to configure KieSession globals variables via kmodule.xml.

Given the fact it is already possible to configure almost every KieSession related features like listeners, handlers, loggers, globals, also session related, should be configurable through the kmodule.xml too.



--
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

From issues at jboss.org  Thu Mar 13 05:48:10 2014
From: issues at jboss.org (Raj Haque (JIRA))
Date: Thu, 13 Mar 2014 05:48:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBDEPLOY-280) ContextClassLoader is not
 working when war is zipped in Jboss as-7.1.1
In-Reply-To: <JIRA.12534260.1394103073000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534260.1394103073000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534260.1394103073000.11959.1394704090579@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBDEPLOY-280?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Raj Haque resolved JBDEPLOY-280.
--------------------------------

    Resolution: Done


https://community.jboss.org/message/860730#860730
                
> ContextClassLoader is not working when war is zipped in Jboss as-7.1.1
> ----------------------------------------------------------------------
>
>                 Key: JBDEPLOY-280
>                 URL: https://issues.jboss.org/browse/JBDEPLOY-280
>             Project: JBoss Deployers
>          Issue Type: Bug
>          Components: classloading, deployer, release
>         Environment: mac osx,  eclipse kepler ,Apache Maven 3.0.4, java 1.7_0_45 and JBoss Application Server 7.1.1
>            Reporter: Raj Haque
>
> I have some resources(reports and native sql) on my class path. When I unzip the war I can see them under  the classes folder.
>  
> I have been using
> Thread.currentThread().getContextClassLoader(). getResource(".........................");
>  
> This works fine when war is exploded but not when zipped. Hence I can not use JBoss maven deployments.
> I also have some more resources under jar files (jars inside the war file) . It is the same . I can not access them any more.
> I know this issue have been discussed in several post e.g.
> https://community.jboss.org/thread/202208
> https://community.jboss.org/message/761846#761846
> But none of them answers correctly.
>  
> Any help will be much appreciated.
>  
> Thanks In advance.

--
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

From issues at jboss.org  Thu Mar 13 05:54:11 2014
From: issues at jboss.org (Davide Sottara (JIRA))
Date: Thu, 13 Mar 2014 05:54:11 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-454) Support pluggable resource
 types in the KieBuilder
In-Reply-To: <JIRA.12534858.1394704383725@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534858.1394704383725@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534858.1394704383725.11971.1394704451082@jira02.app.mwc.hst.phx2.redhat.com>

Davide Sottara created DROOLS-454:
-------------------------------------

             Summary: Support pluggable resource types in the KieBuilder
                 Key: DROOLS-454
                 URL: https://issues.jboss.org/browse/DROOLS-454
             Project: Drools
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
            Reporter: Davide Sottara
            Assignee: Mark Proctor


A user should be able to register custom resource types and the associated processor. 
Custom resources would be recognized by file extension and processed by the registered processor.
The processor will generate one or more "native" resources (e.g. DRL, BPMN) from each custom resource found in the KieFileSystem: the generated resources will eventually be added to the KieBase.

--
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

From issues at jboss.org  Thu Mar 13 05:54:11 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 13 Mar 2014 05:54:11 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3106) Infinispan cache statistics
 cannot be enabled/disabled independently of the cache manager statistics
In-Reply-To: <JIRA.12534838.1394655920000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534838.1394655920000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534838.1394655920000.11978.1394704451420@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-3106?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated WFLY-3106:
------------------------------------------

        Bugzilla Update: Perform
    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1025023

    
> Infinispan cache statistics cannot be enabled/disabled independently of the cache manager statistics    
> --------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-3106
>                 URL: https://issues.jboss.org/browse/WFLY-3106
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Clustering
>    Affects Versions: 8.0.0.Final
>            Reporter: Richard Achmatowicz
>            Assignee: Richard Achmatowicz
>             Fix For: 8.0.1.Final
>
>
> The Infinispan subsystem allows enabling and disabling the collection of statistics for cache managers and caches via the "statistics-enabled" management API attribute.
> It is possible to set statistics-enabled attributes independently for cache managers and caches in the management API, but when checking the Infinispan MBeans, we see that statistics are either enabled for cache managers and their caches, or disabled for cache managers and caches.  

--
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

From issues at jboss.org  Thu Mar 13 06:08:10 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 13 Mar 2014 06:08:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3094) Warn if there is no resource
 bound for address-settings expiry and dead-letter addresses
In-Reply-To: <JIRA.12534528.1394450392000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534528.1394450392000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534528.1394450392000.12046.1394705290876@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-3094?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12952583#comment-12952583 ] 

RH Bugzilla Integration commented on WFLY-3094:
-----------------------------------------------

Miroslav Novak <mnovak at redhat.com> changed the Status of [bug 1014099|https://bugzilla.redhat.com/show_bug.cgi?id=1014099] from ON_QA to ASSIGNED
                
> Warn if there is no resource bound for address-settings expiry and dead-letter addresses
> ----------------------------------------------------------------------------------------
>
>                 Key: WFLY-3094
>                 URL: https://issues.jboss.org/browse/WFLY-3094
>             Project: WildFly
>          Issue Type: Enhancement
>      Security Level: Public(Everyone can see) 
>          Components: JMS
>    Affects Versions: 8.0.0.Final
>            Reporter: Jeff Mesnil
>            Assignee: Jeff Mesnil
>             Fix For: 8.0.1.Final
>
>
> Warns the user if a address-setting has defined an expiry-address or a dead-letter-address with no queue bound for them as this will result in unintended message loss.
> WildFly default full configuration specifies an expiry address (jms.queue.ExpiryQueue) and dead-letter-addres (jms.queue.DLQ) for the # address settings (i.e. matching all addresses).
> To have a consistent configuration, we must also define 2 queues that will be bound to these settings.

--
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

From issues at jboss.org  Thu Mar 13 06:28:10 2014
From: issues at jboss.org (Michael Anstis (JIRA))
Date: Thu, 13 Mar 2014 06:28:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-450) Cannot use decimal
 formatters for integers in an excel decision table
In-Reply-To: <JIRA.12534705.1394557254000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534705.1394557254000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534705.1394557254000.12110.1394706490820@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/DROOLS-450?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12952590#comment-12952590 ] 

Michael Anstis commented on DROOLS-450:
---------------------------------------

Hello,

Perhaps you can guide me here. 

If your JRE locale is FRENCH then would parsing of numeric values expect them to be formatted "1,000" (instead of "1.000" that the PNG seems to show)? AFAIK using a period as a decimal separator is reserved for other Locales (Spain, Norway and othersd). Are the values in the XLS in fact numeric or Strings? Can you can include a couple of Unit Tests in your PR with both FR and EN locales - and suitable XLS files?   





                
> Cannot use decimal formatters for integers in an excel decision table
> ---------------------------------------------------------------------
>
>                 Key: DROOLS-450
>                 URL: https://issues.jboss.org/browse/DROOLS-450
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 6.0.1.Final
>            Reporter: Maxime Falaize
>            Assignee: Mark Proctor
>            Priority: Minor
>         Attachments: issue_example.png
>
>
> When I use decimal formatter in an excel action column for numbers that are in fact integers, I am getting this exception :
> {noformat}
> Exception in thread "main" java.lang.RuntimeException: Error while creating KieBase[Message [id=1, level=ERROR, path=com/sample/my_decision_table.xls, line=5, column=0
>    text=Rule Compilation error The method setParameter(double) in the type MyObject is not applicable for the arguments (int, int)]]
> 	at org.drools.compiler.kie.builder.impl.KieContainerImpl.getKieBase(KieContainerImpl.java:260)
> 	at org.drools.compiler.kie.builder.impl.KieContainerImpl.newKieSession(KieContainerImpl.java:400)
> 	at org.drools.compiler.kie.builder.impl.KieContainerImpl.newKieSession(KieContainerImpl.java:375)
> {noformat}
> Actually, the system uses the format number "1,00000" (with comma in french) instead of "1.00000" like it should use.
> This is causing by the line 174 in org.drools.decisiontable.parser.xls.ExcelParser :
> {code:java}
> if ( num - Math.round( num ) != 0 )
> {code}
> I don't understand why we use the formatted value when this test is not passed.
> I think the end users should have the possibility to keep the same formatter for the same column, with integers or not.

--
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

From issues at jboss.org  Thu Mar 13 06:32:10 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 13 Mar 2014 06:32:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3094) Warn if there is no resource
 bound for address-settings expiry and dead-letter addresses
In-Reply-To: <JIRA.12534528.1394450392000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534528.1394450392000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534528.1394450392000.12125.1394706730801@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-3094?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12952594#comment-12952594 ] 

RH Bugzilla Integration commented on WFLY-3094:
-----------------------------------------------

Miroslav Novak <mnovak at redhat.com> changed the Status of [bug 1014099|https://bugzilla.redhat.com/show_bug.cgi?id=1014099] from ASSIGNED to VERIFIED
                
> Warn if there is no resource bound for address-settings expiry and dead-letter addresses
> ----------------------------------------------------------------------------------------
>
>                 Key: WFLY-3094
>                 URL: https://issues.jboss.org/browse/WFLY-3094
>             Project: WildFly
>          Issue Type: Enhancement
>      Security Level: Public(Everyone can see) 
>          Components: JMS
>    Affects Versions: 8.0.0.Final
>            Reporter: Jeff Mesnil
>            Assignee: Jeff Mesnil
>             Fix For: 8.0.1.Final
>
>
> Warns the user if a address-setting has defined an expiry-address or a dead-letter-address with no queue bound for them as this will result in unintended message loss.
> WildFly default full configuration specifies an expiry address (jms.queue.ExpiryQueue) and dead-letter-addres (jms.queue.DLQ) for the # address settings (i.e. matching all addresses).
> To have a consistent configuration, we must also define 2 queues that will be bound to these settings.

--
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

From issues at jboss.org  Thu Mar 13 06:42:10 2014
From: issues at jboss.org (Michal Babacek (JIRA))
Date: Thu, 13 Mar 2014 06:42:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBWEB-294) The same JSSE cipher-suite
 behaves differently with various JDKs
In-Reply-To: <JIRA.12534863.1394707274656@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534863.1394707274656@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534863.1394707274656.12145.1394707330880@jira02.app.mwc.hst.phx2.redhat.com>

Michal Babacek created JBWEB-294:
------------------------------------

             Summary: The same JSSE cipher-suite behaves differently with various JDKs
                 Key: JBWEB-294
                 URL: https://issues.jboss.org/browse/JBWEB-294
             Project: JBoss Web
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions: JBossWeb-7.4.0.GA
            Reporter: Michal Babacek
            Assignee: Remy Maucherat
             Fix For: JBossWeb-7.4.0.GA


Hi guys, I believe this is a bug, but correct me if it's just a feature unknown to me.

I have the following settings:

h3. Apache HTTP Server (mod_cluster load balancer)
{code}
  Listen 10.16.92.111:8847
  LogLevel debug
  <VirtualHost 10.16.92.111:8847>
    ServerName 10.16.92.111:8847
    <Directory />
      Order deny,allow
      Deny from all
      Allow from all
    </Directory>
    KeepAliveTimeout 60
    MaxKeepAliveRequests 0
    ServerAdvertise on
    AdvertiseFrequency 5
    ManagerBalancerName qacluster
    AdvertiseGroup 224.0.5.98:60220
    EnableMCPMReceive
    SSLEngine on
    SSLCipherSuite AES128-SHA:ALL:!ADH:!LOW:!MD5:!SSLV2:!NULL
    SSLCertificateFile /mnt/hudson_workspace/proper/server.crt
    SSLCertificateKeyFile /mnt/hudson_workspace/proper/server.key
    SSLCACertificateFile /mnt/hudson_workspace/proper/myca.crt
    #SSLVerifyClient require
    #SSLProxyVerify require
    SSLProxyEngine On
    SSLVerifyDepth 10
    <Location /mcm>
      SetHandler mod_cluster-manager
      Order deny,allow
      Deny from all
      Allow from all
    </Location>
  </VirtualHost>
{code}

h3. JBossWeb subsystem
{code}
<subsystem xmlns="urn:jboss:domain:web:1.5" native="false">
<connector name="https" protocol="HTTP/1.1" socket-binding="https"
           scheme="https" enabled="true" secure="true">
<ssl name="https" ca-certificate-file="/mnt/hudson_workspace/proper/ca-cert.jks"
                  certificate-key-file="/mnt/hudson_workspace/proper/client-cert-key.jks"
                  certificate-file="/mnt/hudson_workspace/proper/client-cert-key.jks"
                  password="tomcat" verify-client="false" key-alias="javaclient"
                  cipher-suite="TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384,!TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,!TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,!TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256,!TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256,TLS_DHE_RSA_WITH_AES_256_GCM_SHA384,!TLS_DHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA,TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384,TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384,TLS_ECDH_RSA_WITH_AES_256_CBC_SHA,TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA,TLS_DHE_RSA_WITH_AES_256_CBC_SHA256,TLS_DHE_RSA_WITH_AES_256_CBC_SHA,!TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256,!TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256,!TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,!TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA,!TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256,!TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256,!TLS_ECDH_RSA_WITH_AES_128_CBC_SHA,!TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA,!TLS_DHE_RSA_WITH_AES_128_CBC_SHA256,!TLS_DHE_RSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA,TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA,TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA,TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA,TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA,TLS_RSA_WITH_AES_256_GCM_SHA384,TLS_RSA_WITH_AES_256_CBC_SHA256,TLS_RSA_WITH_AES_256_CBC_SHA,!TLS_RSA_WITH_AES_128_GCM_SHA256,!TLS_RSA_WITH_AES_128_CBC_SHA256,!TLS_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_3DES_EDE_CBC_SHA" 
                  protocol="TLS"/>
</connector>
<virtual-server name="default-host" enable-welcome-root="true">
<alias name="localhost"/>
<alias name="example.com"/>
</virtual-server>
</subsystem>
{code}

h3. mod_cluster subsystem
{code}
<subsystem xmlns="urn:jboss:domain:modcluster:1.2">
<mod-cluster-config connector="https" advertise-socket="modcluster">
<dynamic-load-provider>
<load-metric type="busyness"/>
</dynamic-load-provider>
<ssl ca-certificate-file="/mnt/hudson_workspace/proper/ca-cert.jks"
     certificate-key-file="/mnt/hudson_workspace/proper/client-cert-key.jks"
     password="tomcat" key-alias="javaclient"
     cipher-suite="TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384,!TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,!TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,!TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256,!TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256,TLS_DHE_RSA_WITH_AES_256_GCM_SHA384,!TLS_DHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA,TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384,TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384,TLS_ECDH_RSA_WITH_AES_256_CBC_SHA,TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA,TLS_DHE_RSA_WITH_AES_256_CBC_SHA256,TLS_DHE_RSA_WITH_AES_256_CBC_SHA,!TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256,!TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256,!TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,!TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA,!TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256,!TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256,!TLS_ECDH_RSA_WITH_AES_128_CBC_SHA,!TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA,!TLS_DHE_RSA_WITH_AES_128_CBC_SHA256,!TLS_DHE_RSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA,TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA,TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA,TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA,TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA,TLS_RSA_WITH_AES_256_GCM_SHA384,TLS_RSA_WITH_AES_256_CBC_SHA256,TLS_RSA_WITH_AES_256_CBC_SHA,!TLS_RSA_WITH_AES_128_GCM_SHA256,!TLS_RSA_WITH_AES_128_CBC_SHA256,!TLS_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_3DES_EDE_CBC_SHA"
     protocol="TLS"/>
</mod-cluster-config>
</subsystem>
{code}

h3. Some properties
{code}
<system-properties>
<property name="javax.net.ssl.trustStore" value="/mnt/hudson_workspace/proper/client-cert-key.jks"/>
<property name="javax.net.ssl.trustStorePassword" value="tomcat"/>
<property name="jboss.mod_cluster.jvmRoute" value="jboss-eap-6.3"/>
<property name="jboss.node.name" value="jboss-eap-6.3"/>
</system-properties>
{code}

The test runs several standalone-ha instances, client accesses the AS7 instances directly, then via mod_cluster load balancer. Some of the AS7 instances are being shut down, failover takes place. Client uses client certificate for authentication.

The result of this test is as follows:

||JDK||Arch||Error||Test result||
|Oracle JDK 1.6|RHEL6 x64|JBWEB002081: No cipher match|(x)|
|Oracle JDK 1.7|RHEL6 x64|javax.net.ssl.SSLHandshakeException (i)|(x)|
|Oracle JDK 1.8|RHEL6 x64|javax.net.ssl.SSLHandshakeException (i)|(x)|
|IBM JDK 1.6|RHEL6 x64|JBWEB002081: No cipher match|(x)|
|IBM JDK 1.7|RHEL6 x64|JBWEB002081: No cipher match|(x)|
|OpenJDK 1.7|RHEL6 x64| |(/)|
|OpenJDK 1.6|RHEL6 x64| |(/)|
|HP JDK 1.7|HP-UX v11.3|JBWEB002081: No cipher match|(x)|

h4. (i) javax.net.ssl.SSLHandshakeException
The funny thing here is that the client can access the AS7 server directly, HTTPS connector is up and running just fine, certificates valid, no problem.
Yet, the AS7 server fails to do handshake with the Apache HTTP Server instance.
Please, note that in the aforementioned cipher-suite, some (those leveraging AES-128) methods are prefixed with *!*, so are some methods in the aforementioned Apache HTTP Server configuration.
{noformat}
[0m[31m12:58:35,574 ERROR [org.jboss.modcluster] (ContainerBackgroundProcessor[StandardEngine[jboss.web]]) MODCLUSTER000043: Failed to send INFO to 10.16.94.122/10.16.94.122:8847: javax.net.ssl.SSLHandshakeException: Received fatal alert: handshake_failure
  at sun.security.ssl.Alerts.getSSLException(Alerts.java:192) [jsse.jar:1.7.0_45]
  at sun.security.ssl.Alerts.getSSLException(Alerts.java:154) [jsse.jar:1.7.0_45]
  at sun.security.ssl.SSLSocketImpl.recvAlert(SSLSocketImpl.java:1959) [jsse.jar:1.7.0_45]
  at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:1077) [jsse.jar:1.7.0_45]
  at sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1312) [jsse.jar:1.7.0_45]
  at sun.security.ssl.SSLSocketImpl.writeRecord(SSLSocketImpl.java:702) [jsse.jar:1.7.0_45]
  at sun.security.ssl.AppOutputStream.write(AppOutputStream.java:122) [jsse.jar:1.7.0_45]
  at sun.nio.cs.StreamEncoder.writeBytes(StreamEncoder.java:221) [rt.jar:1.7.0_45]
  at sun.nio.cs.StreamEncoder.implFlushBuffer(StreamEncoder.java:291) [rt.jar:1.7.0_45]
  at sun.nio.cs.StreamEncoder.implFlush(StreamEncoder.java:295) [rt.jar:1.7.0_45]
  at sun.nio.cs.StreamEncoder.flush(StreamEncoder.java:141) [rt.jar:1.7.0_45]
  at java.io.OutputStreamWriter.flush(OutputStreamWriter.java:229) [rt.jar:1.7.0_45]
  at java.io.BufferedWriter.flush(BufferedWriter.java:254) [rt.jar:1.7.0_45]
  at org.jboss.modcluster.mcmp.impl.DefaultMCMPHandler.sendRequest(DefaultMCMPHandler.java:494)
  at org.jboss.modcluster.mcmp.impl.DefaultMCMPHandler.sendRequest(DefaultMCMPHandler.java:583)
  at org.jboss.modcluster.mcmp.impl.DefaultMCMPHandler.status(DefaultMCMPHandler.java:370)
  at org.jboss.modcluster.mcmp.impl.DefaultMCMPHandler.status(DefaultMCMPHandler.java:350)
  at org.jboss.modcluster.ModClusterService.status(ModClusterService.java:458)
  at org.jboss.modcluster.container.catalina.CatalinaEventHandlerAdapter.lifecycleEvent(CatalinaEventHandlerAdapter.java:249)
  at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:115) [jbossweb-7.4.0.Beta4.jar:7.4.0.Beta4]
  at org.apache.catalina.core.ContainerBase.backgroundProcess(ContainerBase.java:1323) [jbossweb-7.4.0.Beta4.jar:7.4.0.Beta4]
  at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1588) [jbossweb-7.4.0.Beta4.jar:7.4.0.Beta4]
  at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.run(ContainerBase.java:1574) [jbossweb-7.4.0.Beta4.jar:7.4.0.Beta4]
  at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_45]
{noformat}

h3. Question
How come that some JDKs does not know these JSSE cipher-suite methods, some JDKs do, but fail to do handshake with Apache HTTP Server whereas OpenJDK simply passes with "all green"?
What is actually a bug? Is it that OpenJDK should fail as well, because the configuration is wrong, or the other JDKs should pass?

--
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


From issues at jboss.org  Thu Mar 13 06:44:13 2014
From: issues at jboss.org (Emanuel Muckenhuber (JIRA))
Date: Thu, 13 Mar 2014 06:44:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3078) directory-grouping
 configuration is not getting persisted via CLI when no servers defined
In-Reply-To: <JIRA.12534347.1394159920000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534347.1394159920000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534347.1394159920000.12154.1394707453173@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-3078?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Emanuel Muckenhuber resolved WFLY-3078.
---------------------------------------

    Resolution: Done

    
> directory-grouping configuration is not getting persisted via CLI when no servers defined
> -----------------------------------------------------------------------------------------
>
>                 Key: WFLY-3078
>                 URL: https://issues.jboss.org/browse/WFLY-3078
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>    Affects Versions: 8.0.0.Final
>         Environment: All Operating System
>            Reporter: Jay Kumar SenSharma
>            Assignee: Emanuel Muckenhuber
>             Fix For: 8.0.1.Final
>
>
> - If none of the servers are defined in "host.xml" (means <servers></servers> empty tag is present) and if the user tries to run the following CLI command to change the "directory-grouping" to  "by-type"  then the value is not persisted in the configuration file (host.xml) and the <servers></servers>  tag is also removed from the host.xml
> {code}
> /host=master/:write-attribute(name=directory-grouping,value=by-type)
> {code}
> - The value of "directory-grouping" is stored "in memory" so this change does not survive the host restart.

--
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

From issues at jboss.org  Thu Mar 13 06:44:13 2014
From: issues at jboss.org (Michal Babacek (JIRA))
Date: Thu, 13 Mar 2014 06:44:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBWEB-294) The same JSSE cipher-suite
 behaves differently with various JDKs
In-Reply-To: <JIRA.12534863.1394707274000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534863.1394707274000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534863.1394707274000.12158.1394707453520@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JBWEB-294?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12952599#comment-12952599 ] 

Michal Babacek commented on JBWEB-294:
--------------------------------------

@[~jfclere]: I guess you might want to comment on it as well. (perhaps tear apart my configuration... :) )
                
> The same JSSE cipher-suite behaves differently with various JDKs
> ----------------------------------------------------------------
>
>                 Key: JBWEB-294
>                 URL: https://issues.jboss.org/browse/JBWEB-294
>             Project: JBoss Web
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: JBossWeb-7.4.0.GA
>            Reporter: Michal Babacek
>            Assignee: Remy Maucherat
>             Fix For: JBossWeb-7.4.0.GA
>
>
> Hi guys, I believe this is a bug, but correct me if it's just a feature unknown to me.
> I have the following settings:
> h3. Apache HTTP Server (mod_cluster load balancer)
> {code}
>   Listen 10.16.92.111:8847
>   LogLevel debug
>   <VirtualHost 10.16.92.111:8847>
>     ServerName 10.16.92.111:8847
>     <Directory />
>       Order deny,allow
>       Deny from all
>       Allow from all
>     </Directory>
>     KeepAliveTimeout 60
>     MaxKeepAliveRequests 0
>     ServerAdvertise on
>     AdvertiseFrequency 5
>     ManagerBalancerName qacluster
>     AdvertiseGroup 224.0.5.98:60220
>     EnableMCPMReceive
>     SSLEngine on
>     SSLCipherSuite AES128-SHA:ALL:!ADH:!LOW:!MD5:!SSLV2:!NULL
>     SSLCertificateFile /mnt/hudson_workspace/proper/server.crt
>     SSLCertificateKeyFile /mnt/hudson_workspace/proper/server.key
>     SSLCACertificateFile /mnt/hudson_workspace/proper/myca.crt
>     #SSLVerifyClient require
>     #SSLProxyVerify require
>     SSLProxyEngine On
>     SSLVerifyDepth 10
>     <Location /mcm>
>       SetHandler mod_cluster-manager
>       Order deny,allow
>       Deny from all
>       Allow from all
>     </Location>
>   </VirtualHost>
> {code}
> h3. JBossWeb subsystem
> {code}
> <subsystem xmlns="urn:jboss:domain:web:1.5" native="false">
> <connector name="https" protocol="HTTP/1.1" socket-binding="https"
>            scheme="https" enabled="true" secure="true">
> <ssl name="https" ca-certificate-file="/mnt/hudson_workspace/proper/ca-cert.jks"
>                   certificate-key-file="/mnt/hudson_workspace/proper/client-cert-key.jks"
>                   certificate-file="/mnt/hudson_workspace/proper/client-cert-key.jks"
>                   password="tomcat" verify-client="false" key-alias="javaclient"
>                   cipher-suite="TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384,!TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,!TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,!TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256,!TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256,TLS_DHE_RSA_WITH_AES_256_GCM_SHA384,!TLS_DHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA,TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384,TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384,TLS_ECDH_RSA_WITH_AES_256_CBC_SHA,TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA,TLS_DHE_RSA_WITH_AES_256_CBC_SHA256,TLS_DHE_RSA_WITH_AES_256_CBC_SHA,!TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256,!TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256,!TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,!TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA,!TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256,!TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256,!TLS_ECDH_RSA_WITH_AES_128_CBC_SHA,!TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA,!TLS_DHE_RSA_WITH_AES_128_CBC_SHA256,!TLS_DHE_RSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA,TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA,TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA,TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA,TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA,TLS_RSA_WITH_AES_256_GCM_SHA384,TLS_RSA_WITH_AES_256_CBC_SHA256,TLS_RSA_WITH_AES_256_CBC_SHA,!TLS_RSA_WITH_AES_128_GCM_SHA256,!TLS_RSA_WITH_AES_128_CBC_SHA256,!TLS_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_3DES_EDE_CBC_SHA" 
>                   protocol="TLS"/>
> </connector>
> <virtual-server name="default-host" enable-welcome-root="true">
> <alias name="localhost"/>
> <alias name="example.com"/>
> </virtual-server>
> </subsystem>
> {code}
> h3. mod_cluster subsystem
> {code}
> <subsystem xmlns="urn:jboss:domain:modcluster:1.2">
> <mod-cluster-config connector="https" advertise-socket="modcluster">
> <dynamic-load-provider>
> <load-metric type="busyness"/>
> </dynamic-load-provider>
> <ssl ca-certificate-file="/mnt/hudson_workspace/proper/ca-cert.jks"
>      certificate-key-file="/mnt/hudson_workspace/proper/client-cert-key.jks"
>      password="tomcat" key-alias="javaclient"
>      cipher-suite="TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384,!TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,!TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,!TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256,!TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256,TLS_DHE_RSA_WITH_AES_256_GCM_SHA384,!TLS_DHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA,TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384,TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384,TLS_ECDH_RSA_WITH_AES_256_CBC_SHA,TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA,TLS_DHE_RSA_WITH_AES_256_CBC_SHA256,TLS_DHE_RSA_WITH_AES_256_CBC_SHA,!TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256,!TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256,!TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,!TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA,!TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256,!TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256,!TLS_ECDH_RSA_WITH_AES_128_CBC_SHA,!TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA,!TLS_DHE_RSA_WITH_AES_128_CBC_SHA256,!TLS_DHE_RSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA,TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA,TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA,TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA,TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA,TLS_RSA_WITH_AES_256_GCM_SHA384,TLS_RSA_WITH_AES_256_CBC_SHA256,TLS_RSA_WITH_AES_256_CBC_SHA,!TLS_RSA_WITH_AES_128_GCM_SHA256,!TLS_RSA_WITH_AES_128_CBC_SHA256,!TLS_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_3DES_EDE_CBC_SHA"
>      protocol="TLS"/>
> </mod-cluster-config>
> </subsystem>
> {code}
> h3. Some properties
> {code}
> <system-properties>
> <property name="javax.net.ssl.trustStore" value="/mnt/hudson_workspace/proper/client-cert-key.jks"/>
> <property name="javax.net.ssl.trustStorePassword" value="tomcat"/>
> <property name="jboss.mod_cluster.jvmRoute" value="jboss-eap-6.3"/>
> <property name="jboss.node.name" value="jboss-eap-6.3"/>
> </system-properties>
> {code}
> The test runs several standalone-ha instances, client accesses the AS7 instances directly, then via mod_cluster load balancer. Some of the AS7 instances are being shut down, failover takes place. Client uses client certificate for authentication.
> The result of this test is as follows:
> ||JDK||Arch||Error||Test result||
> |Oracle JDK 1.6|RHEL6 x64|JBWEB002081: No cipher match|(x)|
> |Oracle JDK 1.7|RHEL6 x64|javax.net.ssl.SSLHandshakeException (i)|(x)|
> |Oracle JDK 1.8|RHEL6 x64|javax.net.ssl.SSLHandshakeException (i)|(x)|
> |IBM JDK 1.6|RHEL6 x64|JBWEB002081: No cipher match|(x)|
> |IBM JDK 1.7|RHEL6 x64|JBWEB002081: No cipher match|(x)|
> |OpenJDK 1.7|RHEL6 x64| |(/)|
> |OpenJDK 1.6|RHEL6 x64| |(/)|
> |HP JDK 1.7|HP-UX v11.3|JBWEB002081: No cipher match|(x)|
> h4. (i) javax.net.ssl.SSLHandshakeException
> The funny thing here is that the client can access the AS7 server directly, HTTPS connector is up and running just fine, certificates valid, no problem.
> Yet, the AS7 server fails to do handshake with the Apache HTTP Server instance.
> Please, note that in the aforementioned cipher-suite, some (those leveraging AES-128) methods are prefixed with *!*, so are some methods in the aforementioned Apache HTTP Server configuration.
> {noformat}
> [0m[31m12:58:35,574 ERROR [org.jboss.modcluster] (ContainerBackgroundProcessor[StandardEngine[jboss.web]]) MODCLUSTER000043: Failed to send INFO to 10.16.94.122/10.16.94.122:8847: javax.net.ssl.SSLHandshakeException: Received fatal alert: handshake_failure
>   at sun.security.ssl.Alerts.getSSLException(Alerts.java:192) [jsse.jar:1.7.0_45]
>   at sun.security.ssl.Alerts.getSSLException(Alerts.java:154) [jsse.jar:1.7.0_45]
>   at sun.security.ssl.SSLSocketImpl.recvAlert(SSLSocketImpl.java:1959) [jsse.jar:1.7.0_45]
>   at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:1077) [jsse.jar:1.7.0_45]
>   at sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1312) [jsse.jar:1.7.0_45]
>   at sun.security.ssl.SSLSocketImpl.writeRecord(SSLSocketImpl.java:702) [jsse.jar:1.7.0_45]
>   at sun.security.ssl.AppOutputStream.write(AppOutputStream.java:122) [jsse.jar:1.7.0_45]
>   at sun.nio.cs.StreamEncoder.writeBytes(StreamEncoder.java:221) [rt.jar:1.7.0_45]
>   at sun.nio.cs.StreamEncoder.implFlushBuffer(StreamEncoder.java:291) [rt.jar:1.7.0_45]
>   at sun.nio.cs.StreamEncoder.implFlush(StreamEncoder.java:295) [rt.jar:1.7.0_45]
>   at sun.nio.cs.StreamEncoder.flush(StreamEncoder.java:141) [rt.jar:1.7.0_45]
>   at java.io.OutputStreamWriter.flush(OutputStreamWriter.java:229) [rt.jar:1.7.0_45]
>   at java.io.BufferedWriter.flush(BufferedWriter.java:254) [rt.jar:1.7.0_45]
>   at org.jboss.modcluster.mcmp.impl.DefaultMCMPHandler.sendRequest(DefaultMCMPHandler.java:494)
>   at org.jboss.modcluster.mcmp.impl.DefaultMCMPHandler.sendRequest(DefaultMCMPHandler.java:583)
>   at org.jboss.modcluster.mcmp.impl.DefaultMCMPHandler.status(DefaultMCMPHandler.java:370)
>   at org.jboss.modcluster.mcmp.impl.DefaultMCMPHandler.status(DefaultMCMPHandler.java:350)
>   at org.jboss.modcluster.ModClusterService.status(ModClusterService.java:458)
>   at org.jboss.modcluster.container.catalina.CatalinaEventHandlerAdapter.lifecycleEvent(CatalinaEventHandlerAdapter.java:249)
>   at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:115) [jbossweb-7.4.0.Beta4.jar:7.4.0.Beta4]
>   at org.apache.catalina.core.ContainerBase.backgroundProcess(ContainerBase.java:1323) [jbossweb-7.4.0.Beta4.jar:7.4.0.Beta4]
>   at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1588) [jbossweb-7.4.0.Beta4.jar:7.4.0.Beta4]
>   at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.run(ContainerBase.java:1574) [jbossweb-7.4.0.Beta4.jar:7.4.0.Beta4]
>   at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_45]
> {noformat}
> h3. Question
> How come that some JDKs does not know these JSSE cipher-suite methods, some JDKs do, but fail to do handshake with Apache HTTP Server whereas OpenJDK simply passes with "all green"?
> What is actually a bug? Is it that OpenJDK should fail as well, because the configuration is wrong, or the other JDKs should pass?

--
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


From issues at jboss.org  Thu Mar 13 06:44:13 2014
From: issues at jboss.org (Emanuel Muckenhuber (JIRA))
Date: Thu, 13 Mar 2014 06:44:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3008) System property substitution
 does not work in subnet-match
In-Reply-To: <JIRA.12533143.1393263668000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12533143.1393263668000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12533143.1393263668000.12162.1394707453714@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-3008?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Emanuel Muckenhuber resolved WFLY-3008.
---------------------------------------

    Resolution: Done

    
> System property substitution does not work in subnet-match
> ----------------------------------------------------------
>
>                 Key: WFLY-3008
>                 URL: https://issues.jboss.org/browse/WFLY-3008
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>    Affects Versions: 8.0.0.Final
>            Reporter: Rich DiCroce
>            Assignee: Emanuel Muckenhuber
>            Priority: Minor
>             Fix For: 8.0.1.Final
>
>
> Specifying a system property in subnet-match when defining an interface causes an exception on startup. Example:
> {code:xml}
> <property name="subnet" value="192.168.0.0/16"/>
> ...
> <interface name="public">
>     <subnet-match value="${subnet}"/>
> </interface>
> {code}
> Causes:
> {code}
> 12:36:13,457 ERROR [org.jboss.as.server] (Controller Boot Thread) JBAS015956: Caught exception during boot: org.jboss.as.controller.persistence.ConfigurationPersistenceException: JBAS014676: Failed to parse configuration
> 	at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:112) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final]
> 	at org.jboss.as.server.ServerService.boot(ServerService.java:331) [wildfly-server-8.0.0.Final.jar:8.0.0.Final]
> 	at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:256) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final]
> 	at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_45]
> Caused by: javax.xml.stream.XMLStreamException: ParseError at [row,col]:[311,46]
> Message: JBAS014693: Invalid 'value' ${subnet} -- must be of the form address/mask
> 	at org.jboss.as.server.parsing.CommonXml.validateAddressMask(CommonXml.java:605) [wildfly-server-8.0.0.Final.jar:8.0.0.Final]
> 	at org.jboss.as.server.parsing.CommonXml.parseSimpleInterfaceCriterion(CommonXml.java:587) [wildfly-server-8.0.0.Final.jar:8.0.0.Final]
> 	at org.jboss.as.server.parsing.CommonXml.parseInterfaceCriteria(CommonXml.java:467) [wildfly-server-8.0.0.Final.jar:8.0.0.Final]
> 	at org.jboss.as.server.parsing.CommonXml.parseInterfaces(CommonXml.java:644) [wildfly-server-8.0.0.Final.jar:8.0.0.Final]
> 	at org.jboss.as.server.parsing.StandaloneXml.readServerElement_1_4(StandaloneXml.java:465) [wildfly-server-8.0.0.Final.jar:8.0.0.Final]
> 	at org.jboss.as.server.parsing.StandaloneXml.readElement(StandaloneXml.java:145) [wildfly-server-8.0.0.Final.jar:8.0.0.Final]
> 	at org.jboss.as.server.parsing.StandaloneXml.readElement(StandaloneXml.java:107) [wildfly-server-8.0.0.Final.jar:8.0.0.Final]
> 	at org.jboss.staxmapper.XMLMapperImpl.processNested(XMLMapperImpl.java:110) [staxmapper-1.1.0.Final.jar:1.1.0.Final]
> 	at org.jboss.staxmapper.XMLMapperImpl.parseDocument(XMLMapperImpl.java:69) [staxmapper-1.1.0.Final.jar:1.1.0.Final]
> 	at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:104) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final]
> 	... 3 more
> {code}

--
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

From issues at jboss.org  Thu Mar 13 06:44:13 2014
From: issues at jboss.org (Emanuel Muckenhuber (JIRA))
Date: Thu, 13 Mar 2014 06:44:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3000) Incorrect 'Content-Type'
 response set after executing an erroneous command
In-Reply-To: <JIRA.12533034.1393178127000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12533034.1393178127000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12533034.1393178127000.12166.1394707453975@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-3000?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Emanuel Muckenhuber resolved WFLY-3000.
---------------------------------------

    Resolution: Done

    
> Incorrect 'Content-Type' response set after executing an erroneous command
> --------------------------------------------------------------------------
>
>                 Key: WFLY-3000
>                 URL: https://issues.jboss.org/browse/WFLY-3000
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>    Affects Versions: 8.0.0.Final
>            Reporter: Christos Vasilakis
>            Assignee: Emanuel Muckenhuber
>             Fix For: 8.0.1.Final
>
>
> The http management interface, upon error, returns an incorrect 'Content-Type' of 
> {noformat}
> 'Content-Type: text/plain; charset=utf-8' 
> {noformat}
> although JSON response is returned.
> To reproduce, issue from the command line a simple 'read' operation
> {noformat}
> curl --digest -D - http://localhost:9990/management --header "Content-Type: application/json" -d '{"operation":"read-attribute", "name":"foo"}' -u <username>:<password>
> ..
> Content-Type: text/plain; charset=utf-8
> Content-Length: 119
> Date: Sun, 23 Feb 2014 17:27:10 GMT
> {
>     "outcome" : "failed",
>     "failure-description" : "JBAS014792: Unknown attribute foo",
>     "rolled-back" : true
> }
> {noformat}
> The 'Content-Type' should have been set to *'application/json'* instead of *'text/plain'*
> Note: On JBoss AS 7.1.1.Final, the correct type of *'application/json'* is returned for the same operation.

--
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

From issues at jboss.org  Thu Mar 13 06:46:10 2014
From: issues at jboss.org (Michal Babacek (JIRA))
Date: Thu, 13 Mar 2014 06:46:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBWEB-294) The same JSSE cipher-suite
 behaves differently with various JDKs
In-Reply-To: <JIRA.12534863.1394707274000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534863.1394707274000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534863.1394707274000.12173.1394707570757@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JBWEB-294?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12952601#comment-12952601 ] 

Michal Babacek commented on JBWEB-294:
--------------------------------------

BTW: Yes, in my [comment|https://issues.jboss.org/browse/JBWEB-292?focusedCommentId=12951269&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-12951269] on the issue [JBWEB-292] I stated "it works", but it is worth mentioning here that it was OpenJDK 1.7 I worked with.
                
> The same JSSE cipher-suite behaves differently with various JDKs
> ----------------------------------------------------------------
>
>                 Key: JBWEB-294
>                 URL: https://issues.jboss.org/browse/JBWEB-294
>             Project: JBoss Web
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: JBossWeb-7.4.0.GA
>            Reporter: Michal Babacek
>            Assignee: Remy Maucherat
>             Fix For: JBossWeb-7.4.0.GA
>
>
> Hi guys, I believe this is a bug, but correct me if it's just a feature unknown to me.
> I have the following settings:
> h3. Apache HTTP Server (mod_cluster load balancer)
> {code}
>   Listen 10.16.92.111:8847
>   LogLevel debug
>   <VirtualHost 10.16.92.111:8847>
>     ServerName 10.16.92.111:8847
>     <Directory />
>       Order deny,allow
>       Deny from all
>       Allow from all
>     </Directory>
>     KeepAliveTimeout 60
>     MaxKeepAliveRequests 0
>     ServerAdvertise on
>     AdvertiseFrequency 5
>     ManagerBalancerName qacluster
>     AdvertiseGroup 224.0.5.98:60220
>     EnableMCPMReceive
>     SSLEngine on
>     SSLCipherSuite AES128-SHA:ALL:!ADH:!LOW:!MD5:!SSLV2:!NULL
>     SSLCertificateFile /mnt/hudson_workspace/proper/server.crt
>     SSLCertificateKeyFile /mnt/hudson_workspace/proper/server.key
>     SSLCACertificateFile /mnt/hudson_workspace/proper/myca.crt
>     #SSLVerifyClient require
>     #SSLProxyVerify require
>     SSLProxyEngine On
>     SSLVerifyDepth 10
>     <Location /mcm>
>       SetHandler mod_cluster-manager
>       Order deny,allow
>       Deny from all
>       Allow from all
>     </Location>
>   </VirtualHost>
> {code}
> h3. JBossWeb subsystem
> {code}
> <subsystem xmlns="urn:jboss:domain:web:1.5" native="false">
> <connector name="https" protocol="HTTP/1.1" socket-binding="https"
>            scheme="https" enabled="true" secure="true">
> <ssl name="https" ca-certificate-file="/mnt/hudson_workspace/proper/ca-cert.jks"
>                   certificate-key-file="/mnt/hudson_workspace/proper/client-cert-key.jks"
>                   certificate-file="/mnt/hudson_workspace/proper/client-cert-key.jks"
>                   password="tomcat" verify-client="false" key-alias="javaclient"
>                   cipher-suite="TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384,!TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,!TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,!TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256,!TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256,TLS_DHE_RSA_WITH_AES_256_GCM_SHA384,!TLS_DHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA,TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384,TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384,TLS_ECDH_RSA_WITH_AES_256_CBC_SHA,TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA,TLS_DHE_RSA_WITH_AES_256_CBC_SHA256,TLS_DHE_RSA_WITH_AES_256_CBC_SHA,!TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256,!TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256,!TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,!TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA,!TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256,!TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256,!TLS_ECDH_RSA_WITH_AES_128_CBC_SHA,!TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA,!TLS_DHE_RSA_WITH_AES_128_CBC_SHA256,!TLS_DHE_RSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA,TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA,TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA,TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA,TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA,TLS_RSA_WITH_AES_256_GCM_SHA384,TLS_RSA_WITH_AES_256_CBC_SHA256,TLS_RSA_WITH_AES_256_CBC_SHA,!TLS_RSA_WITH_AES_128_GCM_SHA256,!TLS_RSA_WITH_AES_128_CBC_SHA256,!TLS_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_3DES_EDE_CBC_SHA" 
>                   protocol="TLS"/>
> </connector>
> <virtual-server name="default-host" enable-welcome-root="true">
> <alias name="localhost"/>
> <alias name="example.com"/>
> </virtual-server>
> </subsystem>
> {code}
> h3. mod_cluster subsystem
> {code}
> <subsystem xmlns="urn:jboss:domain:modcluster:1.2">
> <mod-cluster-config connector="https" advertise-socket="modcluster">
> <dynamic-load-provider>
> <load-metric type="busyness"/>
> </dynamic-load-provider>
> <ssl ca-certificate-file="/mnt/hudson_workspace/proper/ca-cert.jks"
>      certificate-key-file="/mnt/hudson_workspace/proper/client-cert-key.jks"
>      password="tomcat" key-alias="javaclient"
>      cipher-suite="TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384,!TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,!TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,!TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256,!TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256,TLS_DHE_RSA_WITH_AES_256_GCM_SHA384,!TLS_DHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA,TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384,TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384,TLS_ECDH_RSA_WITH_AES_256_CBC_SHA,TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA,TLS_DHE_RSA_WITH_AES_256_CBC_SHA256,TLS_DHE_RSA_WITH_AES_256_CBC_SHA,!TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256,!TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256,!TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,!TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA,!TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256,!TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256,!TLS_ECDH_RSA_WITH_AES_128_CBC_SHA,!TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA,!TLS_DHE_RSA_WITH_AES_128_CBC_SHA256,!TLS_DHE_RSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA,TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA,TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA,TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA,TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA,TLS_RSA_WITH_AES_256_GCM_SHA384,TLS_RSA_WITH_AES_256_CBC_SHA256,TLS_RSA_WITH_AES_256_CBC_SHA,!TLS_RSA_WITH_AES_128_GCM_SHA256,!TLS_RSA_WITH_AES_128_CBC_SHA256,!TLS_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_3DES_EDE_CBC_SHA"
>      protocol="TLS"/>
> </mod-cluster-config>
> </subsystem>
> {code}
> h3. Some properties
> {code}
> <system-properties>
> <property name="javax.net.ssl.trustStore" value="/mnt/hudson_workspace/proper/client-cert-key.jks"/>
> <property name="javax.net.ssl.trustStorePassword" value="tomcat"/>
> <property name="jboss.mod_cluster.jvmRoute" value="jboss-eap-6.3"/>
> <property name="jboss.node.name" value="jboss-eap-6.3"/>
> </system-properties>
> {code}
> The test runs several standalone-ha instances, client accesses the AS7 instances directly, then via mod_cluster load balancer. Some of the AS7 instances are being shut down, failover takes place. Client uses client certificate for authentication.
> The result of this test is as follows:
> ||JDK||Arch||Error||Test result||
> |Oracle JDK 1.6|RHEL6 x64|JBWEB002081: No cipher match|(x)|
> |Oracle JDK 1.7|RHEL6 x64|javax.net.ssl.SSLHandshakeException (i)|(x)|
> |Oracle JDK 1.8|RHEL6 x64|javax.net.ssl.SSLHandshakeException (i)|(x)|
> |IBM JDK 1.6|RHEL6 x64|JBWEB002081: No cipher match|(x)|
> |IBM JDK 1.7|RHEL6 x64|JBWEB002081: No cipher match|(x)|
> |OpenJDK 1.7|RHEL6 x64| |(/)|
> |OpenJDK 1.6|RHEL6 x64| |(/)|
> |HP JDK 1.7|HP-UX v11.3|JBWEB002081: No cipher match|(x)|
> h4. (i) javax.net.ssl.SSLHandshakeException
> The funny thing here is that the client can access the AS7 server directly, HTTPS connector is up and running just fine, certificates valid, no problem.
> Yet, the AS7 server fails to do handshake with the Apache HTTP Server instance.
> Please, note that in the aforementioned cipher-suite, some (those leveraging AES-128) methods are prefixed with *!*, so are some methods in the aforementioned Apache HTTP Server configuration.
> {noformat}
> [0m[31m12:58:35,574 ERROR [org.jboss.modcluster] (ContainerBackgroundProcessor[StandardEngine[jboss.web]]) MODCLUSTER000043: Failed to send INFO to 10.16.94.122/10.16.94.122:8847: javax.net.ssl.SSLHandshakeException: Received fatal alert: handshake_failure
>   at sun.security.ssl.Alerts.getSSLException(Alerts.java:192) [jsse.jar:1.7.0_45]
>   at sun.security.ssl.Alerts.getSSLException(Alerts.java:154) [jsse.jar:1.7.0_45]
>   at sun.security.ssl.SSLSocketImpl.recvAlert(SSLSocketImpl.java:1959) [jsse.jar:1.7.0_45]
>   at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:1077) [jsse.jar:1.7.0_45]
>   at sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1312) [jsse.jar:1.7.0_45]
>   at sun.security.ssl.SSLSocketImpl.writeRecord(SSLSocketImpl.java:702) [jsse.jar:1.7.0_45]
>   at sun.security.ssl.AppOutputStream.write(AppOutputStream.java:122) [jsse.jar:1.7.0_45]
>   at sun.nio.cs.StreamEncoder.writeBytes(StreamEncoder.java:221) [rt.jar:1.7.0_45]
>   at sun.nio.cs.StreamEncoder.implFlushBuffer(StreamEncoder.java:291) [rt.jar:1.7.0_45]
>   at sun.nio.cs.StreamEncoder.implFlush(StreamEncoder.java:295) [rt.jar:1.7.0_45]
>   at sun.nio.cs.StreamEncoder.flush(StreamEncoder.java:141) [rt.jar:1.7.0_45]
>   at java.io.OutputStreamWriter.flush(OutputStreamWriter.java:229) [rt.jar:1.7.0_45]
>   at java.io.BufferedWriter.flush(BufferedWriter.java:254) [rt.jar:1.7.0_45]
>   at org.jboss.modcluster.mcmp.impl.DefaultMCMPHandler.sendRequest(DefaultMCMPHandler.java:494)
>   at org.jboss.modcluster.mcmp.impl.DefaultMCMPHandler.sendRequest(DefaultMCMPHandler.java:583)
>   at org.jboss.modcluster.mcmp.impl.DefaultMCMPHandler.status(DefaultMCMPHandler.java:370)
>   at org.jboss.modcluster.mcmp.impl.DefaultMCMPHandler.status(DefaultMCMPHandler.java:350)
>   at org.jboss.modcluster.ModClusterService.status(ModClusterService.java:458)
>   at org.jboss.modcluster.container.catalina.CatalinaEventHandlerAdapter.lifecycleEvent(CatalinaEventHandlerAdapter.java:249)
>   at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:115) [jbossweb-7.4.0.Beta4.jar:7.4.0.Beta4]
>   at org.apache.catalina.core.ContainerBase.backgroundProcess(ContainerBase.java:1323) [jbossweb-7.4.0.Beta4.jar:7.4.0.Beta4]
>   at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1588) [jbossweb-7.4.0.Beta4.jar:7.4.0.Beta4]
>   at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.run(ContainerBase.java:1574) [jbossweb-7.4.0.Beta4.jar:7.4.0.Beta4]
>   at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_45]
> {noformat}
> h3. Question
> How come that some JDKs does not know these JSSE cipher-suite methods, some JDKs do, but fail to do handshake with Apache HTTP Server whereas OpenJDK simply passes with "all green"?
> What is actually a bug? Is it that OpenJDK should fail as well, because the configuration is wrong, or the other JDKs should pass?

--
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


From issues at jboss.org  Thu Mar 13 06:50:10 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 13 Mar 2014 06:50:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3106) Infinispan cache statistics
 cannot be enabled/disabled independently of the cache manager statistics
In-Reply-To: <JIRA.12534838.1394655920000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534838.1394655920000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534838.1394655920000.12178.1394707810873@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-3106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12952602#comment-12952602 ] 

RH Bugzilla Integration commented on WFLY-3106:
-----------------------------------------------

Radoslav Husar <rhusar at redhat.com> changed the Status of [bug 1025023|https://bugzilla.redhat.com/show_bug.cgi?id=1025023] from ASSIGNED to POST
                
> Infinispan cache statistics cannot be enabled/disabled independently of the cache manager statistics    
> --------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-3106
>                 URL: https://issues.jboss.org/browse/WFLY-3106
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Clustering
>    Affects Versions: 8.0.0.Final
>            Reporter: Richard Achmatowicz
>            Assignee: Richard Achmatowicz
>             Fix For: 8.0.1.Final
>
>
> The Infinispan subsystem allows enabling and disabling the collection of statistics for cache managers and caches via the "statistics-enabled" management API attribute.
> It is possible to set statistics-enabled attributes independently for cache managers and caches in the management API, but when checking the Infinispan MBeans, we see that statistics are either enabled for cache managers and their caches, or disabled for cache managers and caches.  

--
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

From issues at jboss.org  Thu Mar 13 06:50:11 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 13 Mar 2014 06:50:11 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2415) Add configuration option to
 enable/disable Infinispan statistics
In-Reply-To: <JIRA.12509131.1383157408000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12509131.1383157408000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12509131.1383157408000.12183.1394707811147@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2415?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12952603#comment-12952603 ] 

RH Bugzilla Integration commented on WFLY-2415:
-----------------------------------------------

Radoslav Husar <rhusar at redhat.com> changed the Status of [bug 1025023|https://bugzilla.redhat.com/show_bug.cgi?id=1025023] from ASSIGNED to POST
                
> Add configuration option to enable/disable Infinispan statistics
> ----------------------------------------------------------------
>
>                 Key: WFLY-2415
>                 URL: https://issues.jboss.org/browse/WFLY-2415
>             Project: WildFly
>          Issue Type: Enhancement
>      Security Level: Public(Everyone can see) 
>          Components: Clustering
>            Reporter: Scott Marlow
>            Assignee: Paul Ferraro
>             Fix For: 8.0.0.CR1
>
>
> When the Infinispan MBean is enabled, Infinispan statistics are enabled by default.  Could we allow Infinispan statistics to be enabled/disabled via a WF configuration setting?

--
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

From issues at jboss.org  Thu Mar 13 06:50:11 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 13 Mar 2014 06:50:11 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBWEB-294) The same JSSE cipher-suite
 behaves differently with various JDKs
In-Reply-To: <JIRA.12534863.1394707274000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534863.1394707274000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534863.1394707274000.12198.1394707811854@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBWEB-294?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated JBWEB-294:
------------------------------------------

        Bugzilla Update: Perform
    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1075993

    
> The same JSSE cipher-suite behaves differently with various JDKs
> ----------------------------------------------------------------
>
>                 Key: JBWEB-294
>                 URL: https://issues.jboss.org/browse/JBWEB-294
>             Project: JBoss Web
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: JBossWeb-7.4.0.GA
>            Reporter: Michal Babacek
>            Assignee: Remy Maucherat
>             Fix For: JBossWeb-7.4.0.GA
>
>
> Hi guys, I believe this is a bug, but correct me if it's just a feature unknown to me.
> I have the following settings:
> h3. Apache HTTP Server (mod_cluster load balancer)
> {code}
>   Listen 10.16.92.111:8847
>   LogLevel debug
>   <VirtualHost 10.16.92.111:8847>
>     ServerName 10.16.92.111:8847
>     <Directory />
>       Order deny,allow
>       Deny from all
>       Allow from all
>     </Directory>
>     KeepAliveTimeout 60
>     MaxKeepAliveRequests 0
>     ServerAdvertise on
>     AdvertiseFrequency 5
>     ManagerBalancerName qacluster
>     AdvertiseGroup 224.0.5.98:60220
>     EnableMCPMReceive
>     SSLEngine on
>     SSLCipherSuite AES128-SHA:ALL:!ADH:!LOW:!MD5:!SSLV2:!NULL
>     SSLCertificateFile /mnt/hudson_workspace/proper/server.crt
>     SSLCertificateKeyFile /mnt/hudson_workspace/proper/server.key
>     SSLCACertificateFile /mnt/hudson_workspace/proper/myca.crt
>     #SSLVerifyClient require
>     #SSLProxyVerify require
>     SSLProxyEngine On
>     SSLVerifyDepth 10
>     <Location /mcm>
>       SetHandler mod_cluster-manager
>       Order deny,allow
>       Deny from all
>       Allow from all
>     </Location>
>   </VirtualHost>
> {code}
> h3. JBossWeb subsystem
> {code}
> <subsystem xmlns="urn:jboss:domain:web:1.5" native="false">
> <connector name="https" protocol="HTTP/1.1" socket-binding="https"
>            scheme="https" enabled="true" secure="true">
> <ssl name="https" ca-certificate-file="/mnt/hudson_workspace/proper/ca-cert.jks"
>                   certificate-key-file="/mnt/hudson_workspace/proper/client-cert-key.jks"
>                   certificate-file="/mnt/hudson_workspace/proper/client-cert-key.jks"
>                   password="tomcat" verify-client="false" key-alias="javaclient"
>                   cipher-suite="TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384,!TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,!TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,!TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256,!TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256,TLS_DHE_RSA_WITH_AES_256_GCM_SHA384,!TLS_DHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA,TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384,TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384,TLS_ECDH_RSA_WITH_AES_256_CBC_SHA,TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA,TLS_DHE_RSA_WITH_AES_256_CBC_SHA256,TLS_DHE_RSA_WITH_AES_256_CBC_SHA,!TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256,!TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256,!TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,!TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA,!TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256,!TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256,!TLS_ECDH_RSA_WITH_AES_128_CBC_SHA,!TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA,!TLS_DHE_RSA_WITH_AES_128_CBC_SHA256,!TLS_DHE_RSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA,TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA,TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA,TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA,TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA,TLS_RSA_WITH_AES_256_GCM_SHA384,TLS_RSA_WITH_AES_256_CBC_SHA256,TLS_RSA_WITH_AES_256_CBC_SHA,!TLS_RSA_WITH_AES_128_GCM_SHA256,!TLS_RSA_WITH_AES_128_CBC_SHA256,!TLS_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_3DES_EDE_CBC_SHA" 
>                   protocol="TLS"/>
> </connector>
> <virtual-server name="default-host" enable-welcome-root="true">
> <alias name="localhost"/>
> <alias name="example.com"/>
> </virtual-server>
> </subsystem>
> {code}
> h3. mod_cluster subsystem
> {code}
> <subsystem xmlns="urn:jboss:domain:modcluster:1.2">
> <mod-cluster-config connector="https" advertise-socket="modcluster">
> <dynamic-load-provider>
> <load-metric type="busyness"/>
> </dynamic-load-provider>
> <ssl ca-certificate-file="/mnt/hudson_workspace/proper/ca-cert.jks"
>      certificate-key-file="/mnt/hudson_workspace/proper/client-cert-key.jks"
>      password="tomcat" key-alias="javaclient"
>      cipher-suite="TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384,!TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,!TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,!TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256,!TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256,TLS_DHE_RSA_WITH_AES_256_GCM_SHA384,!TLS_DHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA,TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384,TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384,TLS_ECDH_RSA_WITH_AES_256_CBC_SHA,TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA,TLS_DHE_RSA_WITH_AES_256_CBC_SHA256,TLS_DHE_RSA_WITH_AES_256_CBC_SHA,!TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256,!TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256,!TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,!TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA,!TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256,!TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256,!TLS_ECDH_RSA_WITH_AES_128_CBC_SHA,!TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA,!TLS_DHE_RSA_WITH_AES_128_CBC_SHA256,!TLS_DHE_RSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA,TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA,TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA,TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA,TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA,TLS_RSA_WITH_AES_256_GCM_SHA384,TLS_RSA_WITH_AES_256_CBC_SHA256,TLS_RSA_WITH_AES_256_CBC_SHA,!TLS_RSA_WITH_AES_128_GCM_SHA256,!TLS_RSA_WITH_AES_128_CBC_SHA256,!TLS_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_3DES_EDE_CBC_SHA"
>      protocol="TLS"/>
> </mod-cluster-config>
> </subsystem>
> {code}
> h3. Some properties
> {code}
> <system-properties>
> <property name="javax.net.ssl.trustStore" value="/mnt/hudson_workspace/proper/client-cert-key.jks"/>
> <property name="javax.net.ssl.trustStorePassword" value="tomcat"/>
> <property name="jboss.mod_cluster.jvmRoute" value="jboss-eap-6.3"/>
> <property name="jboss.node.name" value="jboss-eap-6.3"/>
> </system-properties>
> {code}
> The test runs several standalone-ha instances, client accesses the AS7 instances directly, then via mod_cluster load balancer. Some of the AS7 instances are being shut down, failover takes place. Client uses client certificate for authentication.
> The result of this test is as follows:
> ||JDK||Arch||Error||Test result||
> |Oracle JDK 1.6|RHEL6 x64|JBWEB002081: No cipher match|(x)|
> |Oracle JDK 1.7|RHEL6 x64|javax.net.ssl.SSLHandshakeException (i)|(x)|
> |Oracle JDK 1.8|RHEL6 x64|javax.net.ssl.SSLHandshakeException (i)|(x)|
> |IBM JDK 1.6|RHEL6 x64|JBWEB002081: No cipher match|(x)|
> |IBM JDK 1.7|RHEL6 x64|JBWEB002081: No cipher match|(x)|
> |OpenJDK 1.7|RHEL6 x64| |(/)|
> |OpenJDK 1.6|RHEL6 x64| |(/)|
> |HP JDK 1.7|HP-UX v11.3|JBWEB002081: No cipher match|(x)|
> h4. (i) javax.net.ssl.SSLHandshakeException
> The funny thing here is that the client can access the AS7 server directly, HTTPS connector is up and running just fine, certificates valid, no problem.
> Yet, the AS7 server fails to do handshake with the Apache HTTP Server instance.
> Please, note that in the aforementioned cipher-suite, some (those leveraging AES-128) methods are prefixed with *!*, so are some methods in the aforementioned Apache HTTP Server configuration.
> {noformat}
> [0m[31m12:58:35,574 ERROR [org.jboss.modcluster] (ContainerBackgroundProcessor[StandardEngine[jboss.web]]) MODCLUSTER000043: Failed to send INFO to 10.16.94.122/10.16.94.122:8847: javax.net.ssl.SSLHandshakeException: Received fatal alert: handshake_failure
>   at sun.security.ssl.Alerts.getSSLException(Alerts.java:192) [jsse.jar:1.7.0_45]
>   at sun.security.ssl.Alerts.getSSLException(Alerts.java:154) [jsse.jar:1.7.0_45]
>   at sun.security.ssl.SSLSocketImpl.recvAlert(SSLSocketImpl.java:1959) [jsse.jar:1.7.0_45]
>   at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:1077) [jsse.jar:1.7.0_45]
>   at sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1312) [jsse.jar:1.7.0_45]
>   at sun.security.ssl.SSLSocketImpl.writeRecord(SSLSocketImpl.java:702) [jsse.jar:1.7.0_45]
>   at sun.security.ssl.AppOutputStream.write(AppOutputStream.java:122) [jsse.jar:1.7.0_45]
>   at sun.nio.cs.StreamEncoder.writeBytes(StreamEncoder.java:221) [rt.jar:1.7.0_45]
>   at sun.nio.cs.StreamEncoder.implFlushBuffer(StreamEncoder.java:291) [rt.jar:1.7.0_45]
>   at sun.nio.cs.StreamEncoder.implFlush(StreamEncoder.java:295) [rt.jar:1.7.0_45]
>   at sun.nio.cs.StreamEncoder.flush(StreamEncoder.java:141) [rt.jar:1.7.0_45]
>   at java.io.OutputStreamWriter.flush(OutputStreamWriter.java:229) [rt.jar:1.7.0_45]
>   at java.io.BufferedWriter.flush(BufferedWriter.java:254) [rt.jar:1.7.0_45]
>   at org.jboss.modcluster.mcmp.impl.DefaultMCMPHandler.sendRequest(DefaultMCMPHandler.java:494)
>   at org.jboss.modcluster.mcmp.impl.DefaultMCMPHandler.sendRequest(DefaultMCMPHandler.java:583)
>   at org.jboss.modcluster.mcmp.impl.DefaultMCMPHandler.status(DefaultMCMPHandler.java:370)
>   at org.jboss.modcluster.mcmp.impl.DefaultMCMPHandler.status(DefaultMCMPHandler.java:350)
>   at org.jboss.modcluster.ModClusterService.status(ModClusterService.java:458)
>   at org.jboss.modcluster.container.catalina.CatalinaEventHandlerAdapter.lifecycleEvent(CatalinaEventHandlerAdapter.java:249)
>   at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:115) [jbossweb-7.4.0.Beta4.jar:7.4.0.Beta4]
>   at org.apache.catalina.core.ContainerBase.backgroundProcess(ContainerBase.java:1323) [jbossweb-7.4.0.Beta4.jar:7.4.0.Beta4]
>   at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1588) [jbossweb-7.4.0.Beta4.jar:7.4.0.Beta4]
>   at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.run(ContainerBase.java:1574) [jbossweb-7.4.0.Beta4.jar:7.4.0.Beta4]
>   at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_45]
> {noformat}
> h3. Question
> How come that some JDKs does not know these JSSE cipher-suite methods, some JDKs do, but fail to do handshake with Apache HTTP Server whereas OpenJDK simply passes with "all green"?
> What is actually a bug? Is it that OpenJDK should fail as well, because the configuration is wrong, or the other JDKs should pass?

--
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


From issues at jboss.org  Thu Mar 13 06:50:12 2014
From: issues at jboss.org (Robert Spielmann (JIRA))
Date: Thu, 13 Mar 2014 06:50:12 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-372) InstantiationError during
 condition evaluation in Drools 6.0.0.Final
In-Reply-To: <JIRA.12527361.1386606563000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12527361.1386606563000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12527361.1386606563000.12203.1394707812113@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/DROOLS-372?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12952605#comment-12952605 ] 

Robert Spielmann commented on DROOLS-372:
-----------------------------------------

I'm facing the same problem with Drools 5.5.0.Final since we upgraded from 5.2.0.Final yesterday. Is there a way to fix this without upgrading further?
                
> InstantiationError during condition evaluation in Drools 6.0.0.Final
> --------------------------------------------------------------------
>
>                 Key: DROOLS-372
>                 URL: https://issues.jboss.org/browse/DROOLS-372
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 6.0.0.Final
>         Environment: reproduced on both jdk 6 and jdk 7
>            Reporter: Loic Albertin
>            Assignee: Mario Fusco
>             Fix For: 6.0.1.Final
>
>         Attachments: drools-issue.zip
>
>
> Kindly find bellow the initial discussion from rules-user at list.jboss.org
> In addition I attach a sample project that reproduce the error. 
> To run it simply type 'mvn clean install exec:java'.
> An interesting thing is that on my environment the issue always appears at the 21st insertion. 
> {quote}
> Hi all,
> I'm migrating from an old Drools 5.1 version to 6.0.0.Final. Sometimes (I don't really get under which conditions as sometimes it works), I'm facing an InstantiationError exception when I insert a fact into a stateful kie session. This exception is thrown by a generated class named ConditionEvaluator<UUID> which doesn't help for debugging!
> The inserted object is a basic POJO (named JasmineEventEB) except for an attribute named "value" which accept any "Serializable" object and which is causing the issue.
> The rule condition is quite simple
> $e : JasmineEventEB(probe == "Button:pris" && value == "1")
> In debugging I found that it failed when evaluating the value == "1" part. I can also confirm that the value for the actually inserted JasmineEventEB is a string.
> The stacktrace is:
> {noformat}
> java.lang.InstantiationError: java.io.Serializable
>         at ConditionEvaluatorae1a73837e8146bda23004a0450e2e52.evaluate(Unknown Source)
>         at org.drools.core.rule.constraint.MvelConstraint.evaluate(MvelConstraint.java:212)
>         at org.drools.core.rule.constraint.MvelConstraint.isAllowed(MvelConstraint.java:169)
>         at org.drools.core.reteoo.AlphaNode.assertObject(AlphaNode.java:134)
>         at org.drools.core.reteoo.CompositeObjectSinkAdapter.doPropagateAssertObject(CompositeObjectSinkAdapter.java:502)
>         at org.drools.core.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:387)
>         at org.drools.core.reteoo.AlphaNode.assertObject(AlphaNode.java:138)
>         at org.drools.core.reteoo.CompositeObjectSinkAdapter.doPropagateAssertObject(CompositeObjectSinkAdapter.java:502)
>         at org.drools.core.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:377)
>         at org.drools.core.reteoo.ObjectTypeNode.assertObject(ObjectTypeNode.java:288)
>         at org.drools.core.reteoo.EntryPointNode.assertObject(EntryPointNode.java:260)
>         at org.drools.core.common.NamedEntryPoint.insert(NamedEntryPoint.java:360)
>         at org.drools.core.common.NamedEntryPoint.insert(NamedEntryPoint.java:279)
>         at org.drools.core.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:1149)
>         at org.drools.core.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:1093)
>         at org.drools.core.impl.StatefulKnowledgeSessionImpl.insert(StatefulKnowledgeSessionImpl.java:308)
> {noformat}
> I tested both with the java and mvel dialect with the same result.
> Does someone has already encountered this kind of error?
> If you need more details or clarifications please let me know.
> Thanks & regards,
> Lo?c  
> {quote}

--
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


From issues at jboss.org  Thu Mar 13 06:54:11 2014
From: issues at jboss.org (Radoslav Husar (JIRA))
Date: Thu, 13 Mar 2014 06:54:11 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3106) Infinispan cache statistics
 cannot be enabled/disabled independently of the cache manager statistics
In-Reply-To: <JIRA.12534838.1394655920000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534838.1394655920000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534838.1394655920000.12217.1394708051064@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-3106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12952608#comment-12952608 ] 

Radoslav Husar commented on WFLY-3106:
--------------------------------------

Thanks!
                
> Infinispan cache statistics cannot be enabled/disabled independently of the cache manager statistics    
> --------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-3106
>                 URL: https://issues.jboss.org/browse/WFLY-3106
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Clustering
>    Affects Versions: 8.0.0.Final
>            Reporter: Richard Achmatowicz
>            Assignee: Richard Achmatowicz
>             Fix For: 8.0.1.Final
>
>
> The Infinispan subsystem allows enabling and disabling the collection of statistics for cache managers and caches via the "statistics-enabled" management API attribute.
> It is possible to set statistics-enabled attributes independently for cache managers and caches in the management API, but when checking the Infinispan MBeans, we see that statistics are either enabled for cache managers and their caches, or disabled for cache managers and caches.  

--
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

From issues at jboss.org  Thu Mar 13 06:56:10 2014
From: issues at jboss.org (Jay Kumar SenSharma (JIRA))
Date: Thu, 13 Mar 2014 06:56:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3107) WildFly console can not
 display all the profiles when more than 25 profiles are declared in
 domain.xml
In-Reply-To: <JIRA.12534868.1394708129343@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534868.1394708129343@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534868.1394708129343.12244.1394708170582@jira02.app.mwc.hst.phx2.redhat.com>

Jay Kumar SenSharma created WFLY-3107:
-----------------------------------------

             Summary: WildFly console can not display all the profiles when more than 25 profiles are declared in domain.xml
                 Key: WFLY-3107
                 URL: https://issues.jboss.org/browse/WFLY-3107
             Project: WildFly
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Web Console
    Affects Versions: 8.0.0.Final
            Reporter: Jay Kumar SenSharma
            Assignee: Heiko Braun


- When we create 25+ profiles in domain.xml, then we cant see all profiles in admin console. In Admin console I can see 25 profiles only.



--
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

From issues at jboss.org  Thu Mar 13 06:58:10 2014
From: issues at jboss.org (Jay Kumar SenSharma (JIRA))
Date: Thu, 13 Mar 2014 06:58:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3107) WildFly console can not
 display all the profiles when more than 25 profiles are declared in
 domain.xml
In-Reply-To: <JIRA.12534868.1394708129000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534868.1394708129000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534868.1394708129000.12250.1394708290627@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-3107?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jay Kumar SenSharma updated WFLY-3107:
--------------------------------------

    Attachment: WildFly_Console_Does_Not_Show_More_Than_25_Profiles.png


Only 25 Profiles are shown in Console not all.
                
> WildFly console can not display all the profiles when more than 25 profiles are declared in domain.xml
> ------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-3107
>                 URL: https://issues.jboss.org/browse/WFLY-3107
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web Console
>    Affects Versions: 8.0.0.Final
>            Reporter: Jay Kumar SenSharma
>            Assignee: Heiko Braun
>         Attachments: domain.xml, WildFly_Console_Does_Not_Show_More_Than_25_Profiles.png
>
>
> - When we create 25+ profiles in domain.xml, then we cant see all profiles in admin console. In Admin console I can see 25 profiles only.

--
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

From issues at jboss.org  Thu Mar 13 06:58:10 2014
From: issues at jboss.org (Jay Kumar SenSharma (JIRA))
Date: Thu, 13 Mar 2014 06:58:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3107) WildFly console can not
 display all the profiles when more than 25 profiles are declared in
 domain.xml
In-Reply-To: <JIRA.12534868.1394708129000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534868.1394708129000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534868.1394708129000.12253.1394708290769@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-3107?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jay Kumar SenSharma updated WFLY-3107:
--------------------------------------

    Attachment: domain.xml


A Test  "domain.xml" containing more than 30 Dummy profiles.
                
> WildFly console can not display all the profiles when more than 25 profiles are declared in domain.xml
> ------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-3107
>                 URL: https://issues.jboss.org/browse/WFLY-3107
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web Console
>    Affects Versions: 8.0.0.Final
>            Reporter: Jay Kumar SenSharma
>            Assignee: Heiko Braun
>         Attachments: domain.xml, WildFly_Console_Does_Not_Show_More_Than_25_Profiles.png
>
>
> - When we create 25+ profiles in domain.xml, then we cant see all profiles in admin console. In Admin console I can see 25 profiles only.

--
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

From issues at jboss.org  Thu Mar 13 07:00:12 2014
From: issues at jboss.org (Jay Kumar SenSharma (JIRA))
Date: Thu, 13 Mar 2014 07:00:12 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3107) WildFly console can not
 display all the profiles when more than 25 profiles are declared in
 domain.xml
In-Reply-To: <JIRA.12534868.1394708129000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534868.1394708129000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534868.1394708129000.12257.1394708412696@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-3107?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12952614#comment-12952614 ] 

Jay Kumar SenSharma commented on WFLY-3107:
-------------------------------------------

This issue also affects "wildfly-8.0.1.Final-SNAPSHOT" build.
                
> WildFly console can not display all the profiles when more than 25 profiles are declared in domain.xml
> ------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-3107
>                 URL: https://issues.jboss.org/browse/WFLY-3107
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web Console
>    Affects Versions: 8.0.0.Final
>            Reporter: Jay Kumar SenSharma
>            Assignee: Heiko Braun
>         Attachments: domain.xml, WildFly_Console_Does_Not_Show_More_Than_25_Profiles.png
>
>
> - When we create 25+ profiles in domain.xml, then we cant see all profiles in admin console. In Admin console I can see 25 profiles only.

--
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

From issues at jboss.org  Thu Mar 13 07:02:10 2014
From: issues at jboss.org (Mario Fusco (JIRA))
Date: Thu, 13 Mar 2014 07:02:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-372) InstantiationError during
 condition evaluation in Drools 6.0.0.Final
In-Reply-To: <JIRA.12527361.1386606563000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12527361.1386606563000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12527361.1386606563000.12261.1394708530717@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/DROOLS-372?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12952615#comment-12952615 ] 

Mario Fusco commented on DROOLS-372:
------------------------------------

Unfortunately I don't think so. Can you paste the rule that is causing you this problem?
                
> InstantiationError during condition evaluation in Drools 6.0.0.Final
> --------------------------------------------------------------------
>
>                 Key: DROOLS-372
>                 URL: https://issues.jboss.org/browse/DROOLS-372
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 6.0.0.Final
>         Environment: reproduced on both jdk 6 and jdk 7
>            Reporter: Loic Albertin
>            Assignee: Mario Fusco
>             Fix For: 6.0.1.Final
>
>         Attachments: drools-issue.zip
>
>
> Kindly find bellow the initial discussion from rules-user at list.jboss.org
> In addition I attach a sample project that reproduce the error. 
> To run it simply type 'mvn clean install exec:java'.
> An interesting thing is that on my environment the issue always appears at the 21st insertion. 
> {quote}
> Hi all,
> I'm migrating from an old Drools 5.1 version to 6.0.0.Final. Sometimes (I don't really get under which conditions as sometimes it works), I'm facing an InstantiationError exception when I insert a fact into a stateful kie session. This exception is thrown by a generated class named ConditionEvaluator<UUID> which doesn't help for debugging!
> The inserted object is a basic POJO (named JasmineEventEB) except for an attribute named "value" which accept any "Serializable" object and which is causing the issue.
> The rule condition is quite simple
> $e : JasmineEventEB(probe == "Button:pris" && value == "1")
> In debugging I found that it failed when evaluating the value == "1" part. I can also confirm that the value for the actually inserted JasmineEventEB is a string.
> The stacktrace is:
> {noformat}
> java.lang.InstantiationError: java.io.Serializable
>         at ConditionEvaluatorae1a73837e8146bda23004a0450e2e52.evaluate(Unknown Source)
>         at org.drools.core.rule.constraint.MvelConstraint.evaluate(MvelConstraint.java:212)
>         at org.drools.core.rule.constraint.MvelConstraint.isAllowed(MvelConstraint.java:169)
>         at org.drools.core.reteoo.AlphaNode.assertObject(AlphaNode.java:134)
>         at org.drools.core.reteoo.CompositeObjectSinkAdapter.doPropagateAssertObject(CompositeObjectSinkAdapter.java:502)
>         at org.drools.core.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:387)
>         at org.drools.core.reteoo.AlphaNode.assertObject(AlphaNode.java:138)
>         at org.drools.core.reteoo.CompositeObjectSinkAdapter.doPropagateAssertObject(CompositeObjectSinkAdapter.java:502)
>         at org.drools.core.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:377)
>         at org.drools.core.reteoo.ObjectTypeNode.assertObject(ObjectTypeNode.java:288)
>         at org.drools.core.reteoo.EntryPointNode.assertObject(EntryPointNode.java:260)
>         at org.drools.core.common.NamedEntryPoint.insert(NamedEntryPoint.java:360)
>         at org.drools.core.common.NamedEntryPoint.insert(NamedEntryPoint.java:279)
>         at org.drools.core.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:1149)
>         at org.drools.core.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:1093)
>         at org.drools.core.impl.StatefulKnowledgeSessionImpl.insert(StatefulKnowledgeSessionImpl.java:308)
> {noformat}
> I tested both with the java and mvel dialect with the same result.
> Does someone has already encountered this kind of error?
> If you need more details or clarifications please let me know.
> Thanks & regards,
> Lo?c  
> {quote}

--
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


From issues at jboss.org  Thu Mar 13 07:02:10 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 13 Mar 2014 07:02:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3107) WildFly console can not
 display all the profiles when more than 25 profiles are declared in
 domain.xml
In-Reply-To: <JIRA.12534868.1394708129000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534868.1394708129000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534868.1394708129000.12267.1394708530988@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-3107?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated WFLY-3107:
------------------------------------------

        Bugzilla Update: Perform
    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1019816

    
> WildFly console can not display all the profiles when more than 25 profiles are declared in domain.xml
> ------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-3107
>                 URL: https://issues.jboss.org/browse/WFLY-3107
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web Console
>    Affects Versions: 8.0.0.Final
>            Reporter: Jay Kumar SenSharma
>            Assignee: Heiko Braun
>         Attachments: domain.xml, WildFly_Console_Does_Not_Show_More_Than_25_Profiles.png
>
>
> - When we create 25+ profiles in domain.xml, then we cant see all profiles in admin console. In Admin console I can see 25 profiles only.

--
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

From issues at jboss.org  Thu Mar 13 07:04:10 2014
From: issues at jboss.org (Maxime Falaize (JIRA))
Date: Thu, 13 Mar 2014 07:04:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-450) Cannot use decimal
 formatters for integers in an excel decision table
In-Reply-To: <JIRA.12534705.1394557254000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534705.1394557254000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534705.1394557254000.12270.1394708650551@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/DROOLS-450?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12952618#comment-12952618 ] 

Maxime Falaize commented on DROOLS-450:
---------------------------------------

My values in the XLS are numerics and the display is wrong because my excel uses comma as decimal separator for the french locale.
I will make a unit test and include it to the PR.
                
> Cannot use decimal formatters for integers in an excel decision table
> ---------------------------------------------------------------------
>
>                 Key: DROOLS-450
>                 URL: https://issues.jboss.org/browse/DROOLS-450
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 6.0.1.Final
>            Reporter: Maxime Falaize
>            Assignee: Mark Proctor
>            Priority: Minor
>         Attachments: issue_example.png
>
>
> When I use decimal formatter in an excel action column for numbers that are in fact integers, I am getting this exception :
> {noformat}
> Exception in thread "main" java.lang.RuntimeException: Error while creating KieBase[Message [id=1, level=ERROR, path=com/sample/my_decision_table.xls, line=5, column=0
>    text=Rule Compilation error The method setParameter(double) in the type MyObject is not applicable for the arguments (int, int)]]
> 	at org.drools.compiler.kie.builder.impl.KieContainerImpl.getKieBase(KieContainerImpl.java:260)
> 	at org.drools.compiler.kie.builder.impl.KieContainerImpl.newKieSession(KieContainerImpl.java:400)
> 	at org.drools.compiler.kie.builder.impl.KieContainerImpl.newKieSession(KieContainerImpl.java:375)
> {noformat}
> Actually, the system uses the format number "1,00000" (with comma in french) instead of "1.00000" like it should use.
> This is causing by the line 174 in org.drools.decisiontable.parser.xls.ExcelParser :
> {code:java}
> if ( num - Math.round( num ) != 0 )
> {code}
> I don't understand why we use the formatted value when this test is not passed.
> I think the end users should have the possibility to keep the same formatter for the same column, with integers or not.

--
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

From issues at jboss.org  Thu Mar 13 07:18:11 2014
From: issues at jboss.org (Michal Babacek (JIRA))
Date: Thu, 13 Mar 2014 07:18:11 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2663) mod_cluster metric properties
 are never applied
In-Reply-To: <JIRA.12528097.1387305213000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528097.1387305213000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528097.1387305213000.12317.1394709491326@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2663?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Michal Babacek closed WFLY-2663.
--------------------------------



Ain't an issue anymore.
                
> mod_cluster metric properties are never applied
> -----------------------------------------------
>
>                 Key: WFLY-2663
>                 URL: https://issues.jboss.org/browse/WFLY-2663
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Clustering
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Radoslav Husar
>            Assignee: Radoslav Husar
>            Priority: Critical
>             Fix For: 8.0.0.Final
>
>
> Are parsed for but never applied.
> {noformat}
>  <load-metric type="busyness">
>                 <property name="foo" value="bar"/>
>             </load-metric>
> {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

From issues at jboss.org  Thu Mar 13 07:26:12 2014
From: issues at jboss.org (Davide Sottara (JIRA))
Date: Thu, 13 Mar 2014 07:26:12 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-455) Event expiration calculation
	may overflow
In-Reply-To: <JIRA.12534871.1394709964638@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534871.1394709964638@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534871.1394709964638.12352.1394709972023@jira02.app.mwc.hst.phx2.redhat.com>

Davide Sottara created DROOLS-455:
-------------------------------------

             Summary: Event expiration calculation may overflow
                 Key: DROOLS-455
                 URL: https://issues.jboss.org/browse/DROOLS-455
             Project: Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions: 6.1.0.Beta1, 6.0.1.Final, 6.0.0.Final, 5.6.0.Final
            Reporter: Davide Sottara
            Assignee: Edson Tirelli
            Priority: Critical


The calculation of the expiration timestamp of an event in the OTN is effectively  given by the combination :
{code}
Handle.startTimeStamp + Handle.duration + OTN.expirationOffset 
{code}
If the addition overflows, the event will be scheduled for expiration immediately.


--
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

From issues at jboss.org  Thu Mar 13 07:48:10 2014
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Thu, 13 Mar 2014 07:48:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3108) Can't promote --backup slave
 HC to master and reload without moving domain.cached-remote.xml
In-Reply-To: <JIRA.12534873.1394711186910@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534873.1394711186910@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534873.1394711186910.12416.1394711290994@jira02.app.mwc.hst.phx2.redhat.com>

Brian Stansberry created WFLY-3108:
--------------------------------------

             Summary: Can't promote --backup slave HC to master and reload without moving domain.cached-remote.xml
                 Key: WFLY-3108
                 URL: https://issues.jboss.org/browse/WFLY-3108
             Project: WildFly
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Domain Management
    Affects Versions: 8.0.0.Final
            Reporter: Brian Stansberry
            Assignee: Brian Stansberry
             Fix For: 8.0.1.Final


The prescribed mechanism for converting a slave HC to master is to:

1) Start the slave with --backup so a local copy of the domain config is maintained (in file domain.cached-remote.xml).

2) Stop the existing master.

3) Use the cli to connect to the slave and

/host=<slavename>:write-local-domain-controller

4) Then, in the CLI

reload --host=<slavename>

Problem is this fails because the HC expects to have a domain config file "domain.xml".

2014-03-13 09:54:04,829 ERROR [org.jboss.as.host.controller] (Controller Boot Thread) JBAS010932: Caught exception during boot: org.jboss.as.controller.persistence.ConfigurationPersistenceException: JBAS014676: Failed to parse configuration
	at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:112) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
	at org.jboss.as.host.controller.DomainModelControllerService.boot(DomainModelControllerService.java:514) [wildfly-host-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
	at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:256) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
	at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_45]
Caused by: java.io.FileNotFoundException: /Users/bstansberry/tmp/WF801/slave/domain/configuration/domain.xml (No such file or directory)
	at java.io.FileInputStream.open(Native Method) [rt.jar:1.7.0_45]
	at java.io.FileInputStream.<init>(FileInputStream.java:146) [rt.jar:1.7.0_45]
	at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:100) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
	... 3 more

Or, MUCH WORSE, there happens to be a random domain.xml in the filesystem, which has content that is out of sync with the correct domain config. This domain.xml config will be used.



--
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

From issues at jboss.org  Thu Mar 13 07:48:11 2014
From: issues at jboss.org (Tom Tom (JIRA))
Date: Thu, 13 Mar 2014 07:48:11 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3109) CloseReason always null for
 WebSocket onClose methods
In-Reply-To: <JIRA.12534874.1394711228865@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534874.1394711228865@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534874.1394711228865.12419.1394711291129@jira02.app.mwc.hst.phx2.redhat.com>

Tom Tom created WFLY-3109:
-----------------------------

             Summary: CloseReason always null for WebSocket onClose methods
                 Key: WFLY-3109
                 URL: https://issues.jboss.org/browse/WFLY-3109
             Project: WildFly
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions: 8.0.0.Final
         Environment: WildFly 8.0.0.Final on Windows 7 Pro (64 bits) with JDK 7.0u51 (64 bits)
            Reporter: Tom Tom


The onClose method of the websocket endpoints does not receive valid CloseReason, it is always null.

With GlassFish 4.0, the CloseReason is not null and correctly reflects the code and message used to close the wensocket from the client side.

Simplified code sample of the endpoint:

@ServerEndpoint(value = "/test", configurator = MyConfigurator.class)
public class MyEndpoint {
   // onOpen, onMessage and onError, LOGGER are omitted

    @OnClose
    public void onClose(Session session, CloseReason reason) {
        LOGGER.debug("onClose(sessionId={}, reason={})", session.getId(), reason);
    }
}

--
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

From issues at jboss.org  Thu Mar 13 08:30:10 2014
From: issues at jboss.org (Emanuel Muckenhuber (JIRA))
Date: Thu, 13 Mar 2014 08:30:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3110) Don't copy deployment
 contents to all hosts when updating an existing deployment
In-Reply-To: <JIRA.12534883.1394713780639@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534883.1394713780639@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534883.1394713780639.12576.1394713810908@jira02.app.mwc.hst.phx2.redhat.com>

Emanuel Muckenhuber created WFLY-3110:
-----------------------------------------

             Summary: Don't copy deployment contents to all hosts when updating an existing deployment
                 Key: WFLY-3110
                 URL: https://issues.jboss.org/browse/WFLY-3110
             Project: WildFly
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Domain Management
    Affects Versions: 8.0.0.Final
            Reporter: Emanuel Muckenhuber
            Assignee: Emanuel Muckenhuber
             Fix For: 8.0.1.Final


In case a deployment gets updated, the full-replace deployment handler on the host-controller retrieves the deployment regardless a local server uses this deployment or not.

This does not seem to be affecting the deployment add operation, which will only get the deployment contents when an actual server requires the contents.

--
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

From issues at jboss.org  Thu Mar 13 08:32:10 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 13 Mar 2014 08:32:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3110) Don't copy deployment
 contents to all hosts when updating an existing deployment
In-Reply-To: <JIRA.12534883.1394713780000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534883.1394713780000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534883.1394713780000.12579.1394713930791@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-3110?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated WFLY-3110:
------------------------------------------

        Bugzilla Update: Perform
    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1073585

    
> Don't copy deployment contents to all hosts when updating an existing deployment
> --------------------------------------------------------------------------------
>
>                 Key: WFLY-3110
>                 URL: https://issues.jboss.org/browse/WFLY-3110
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>    Affects Versions: 8.0.0.Final
>            Reporter: Emanuel Muckenhuber
>            Assignee: Emanuel Muckenhuber
>             Fix For: 8.0.1.Final
>
>
> In case a deployment gets updated, the full-replace deployment handler on the host-controller retrieves the deployment regardless a local server uses this deployment or not.
> This does not seem to be affecting the deployment add operation, which will only get the deployment contents when an actual server requires the contents.

--
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

From issues at jboss.org  Thu Mar 13 08:32:11 2014
From: issues at jboss.org (Sylvain Brouillat (JIRA))
Date: Thu, 13 Mar 2014 08:32:11 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2850) AJP connector with external
	authentication
In-Reply-To: <JIRA.12530843.1391157375000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530843.1391157375000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530843.1391157375000.12585.1394713931067@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2850?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12952640#comment-12952640 ] 

Sylvain Brouillat commented on WFLY-2850:
-----------------------------------------

I agree, this is a critical problem. It prevents me to run applications in production environment.
                
> AJP connector with external authentication
> ------------------------------------------
>
>                 Key: WFLY-2850
>                 URL: https://issues.jboss.org/browse/WFLY-2850
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Web (Undertow)
>    Affects Versions: 8.0.0.CR1
>            Reporter: Geert Coelmont
>            Assignee: Stuart Douglas
>            Priority: Critical
>
> Tomcat allows to set the tomcatAuthentication attribute of the AJP connector to false to allow external web servers (e.g. apache httpd) to handle the authentication and pass that along.
> A similar option was added recently to JBossWeb as well (see WFLY-254), but JBossWeb has been replaced by Undertow. With Undertow this option isn't available as far as I can see.
> For me this is a critical problem as there is currently no way I can do negotiated (SPNEGO) authentication from within WildFly+Undertow. (See also WFLY-2404).

--
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

From issues at jboss.org  Thu Mar 13 08:32:11 2014
From: issues at jboss.org (Sylvain Brouillat (JIRA))
Date: Thu, 13 Mar 2014 08:32:11 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2850) AJP connector with external
	authentication
In-Reply-To: <JIRA.12530843.1391157375000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530843.1391157375000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530843.1391157375000.12596.1394713931679@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2850?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12952640#comment-12952640 ] 

Sylvain Brouillat edited comment on WFLY-2850 at 3/13/14 8:32 AM:
------------------------------------------------------------------

I agree, this is a critical problem: I'm not able to use WildFly in production environment because of that.
                
      was (Author: sylvain.b):
    I agree, this is a critical problem. It prevents me to run applications in production environment.
                  
> AJP connector with external authentication
> ------------------------------------------
>
>                 Key: WFLY-2850
>                 URL: https://issues.jboss.org/browse/WFLY-2850
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Web (Undertow)
>    Affects Versions: 8.0.0.CR1
>            Reporter: Geert Coelmont
>            Assignee: Stuart Douglas
>            Priority: Critical
>
> Tomcat allows to set the tomcatAuthentication attribute of the AJP connector to false to allow external web servers (e.g. apache httpd) to handle the authentication and pass that along.
> A similar option was added recently to JBossWeb as well (see WFLY-254), but JBossWeb has been replaced by Undertow. With Undertow this option isn't available as far as I can see.
> For me this is a critical problem as there is currently no way I can do negotiated (SPNEGO) authentication from within WildFly+Undertow. (See also WFLY-2404).

--
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

From issues at jboss.org  Thu Mar 13 08:48:11 2014
From: issues at jboss.org (Radoslav Husar (JIRA))
Date: Thu, 13 Mar 2014 08:48:11 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3044) Mojarra's @ViewScoped
 implementation is not cluster-aware resulting in NotSerializableException
In-Reply-To: <JIRA.12533615.1393599715000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12533615.1393599715000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12533615.1393599715000.12765.1394714891583@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-3044?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12952651#comment-12952651 ] 

Radoslav Husar commented on WFLY-3044:
--------------------------------------

Do you know what does the actual spec say? Sounds like the test is bad.
                
> Mojarra's @ViewScoped implementation is not cluster-aware resulting in NotSerializableException
> -----------------------------------------------------------------------------------------------
>
>                 Key: WFLY-3044
>                 URL: https://issues.jboss.org/browse/WFLY-3044
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JSF
>    Affects Versions: 8.0.0.Final
>            Reporter: Radoslav Husar
>            Assignee: Radoslav Husar
>            Priority: Critical
>             Fix For: 8.0.1.Final
>
>
> The problem is in ViewScopeContextManager, namely 
> {code}
>             getContextMap(facesContext).put(contextual, new ViewScopeContextObject(contextual, creational, name));
> {code}
> probably it needs an artificial ID generated to serve as a key.
> Also the ViewScopeContextObject needs to be serializable as well among other things
> {code}
> class ViewScopeContextObject {
> {code}
> Issue manifests as
> {noformat}[Server:server-one] 19:22:41,564 ERROR [org.infinispan.interceptors.InvocationContextInterceptor] (default task-15) ISPN000136: Execution error: org.infinispan.commons.CacheException: java.lang.RuntimeException: Failure to marshal argument(s)  
> [Server:server-one] at org.infinispan.commons.util.Util.rewrapAsCacheException(Util.java:581)  
> ...  
> [Server:server-one] at org.infinispan.transaction.tm.DummyTransaction.notifyAfterCompletion(DummyTransaction.java:263)  
> [Server:server-one] at org.infinispan.transaction.tm.DummyTransaction.runCommitTx(DummyTransaction.java:312)  
> [Server:server-one] at org.infinispan.transaction.tm.DummyTransaction.commit(DummyTransaction.java:69)  
> [Server:server-one] at org.infinispan.transaction.tm.DummyBaseTransactionManager.commit(DummyBaseTransactionManager.java:80)  
> [Server:server-one] at org.infinispan.batch.BatchContainer.resolveTransaction(BatchContainer.java:101)  
> [Server:server-one] at org.infinispan.batch.BatchContainer.endBatch(BatchContainer.java:83)  
> [Server:server-one] at org.infinispan.batch.BatchContainer.endBatch(BatchContainer.java:64)  
> [Server:server-one] at org.infinispan.CacheImpl.endBatch(CacheImpl.java:777)  
> [Server:server-one] at org.infinispan.AbstractDelegatingCache.endBatch(AbstractDelegatingCache.java:53)  
> [Server:server-one] at org.wildfly.clustering.web.infinispan.InfinispanBatcher$1.end(InfinispanBatcher.java:56)  
> [Server:server-one] at org.wildfly.clustering.web.infinispan.InfinispanBatcher$1.close(InfinispanBatcher.java:46)  
> [Server:server-one] at org.wildfly.clustering.web.undertow.session.DistributableSession.requestDone(DistributableSession.java:72)  
> [Server:server-one] at io.undertow.servlet.spec.ServletContextImpl.updateSessionAccessTime(ServletContextImpl.java:704) [undertow-servlet-1.0.0.Final.jar:1.0.0.Final]  
> [Server:server-one] at io.undertow.servlet.spec.HttpServletResponseImpl.responseDone(HttpServletResponseImpl.java:522) [undertow-servlet-1.0.0.Final.jar:1.0.0.Final]  
> [Server:server-one] at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:287) [undertow-servlet-1.0.0.Final.jar:1.0.0.Final]  
> [Server:server-one] at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:227) [undertow-servlet-1.0.0.Final.jar:1.0.0.Final]  
> [Server:server-one] at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:73) [undertow-servlet-1.0.0.Final.jar:1.0.0.Final]  
> [Server:server-one] at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:146) [undertow-servlet-1.0.0.Final.jar:1.0.0.Final]  
> [Server:server-one] at io.undertow.server.Connectors.executeRootHandler(Connectors.java:168) [undertow-core-1.0.0.Final.jar:1.0.0.Final]  
> [Server:server-one] at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:687) [undertow-core-1.0.0.Final.jar:1.0.0.Final]  
> [Server:server-one] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_51]  
> [Server:server-one] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_51]  
> [Server:server-one] at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_51]  
> [Server:server-one] Caused by: java.lang.RuntimeException: Failure to marshal argument(s)  
> [Server:server-one] at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.marshallCall(CommandAwareRpcDispatcher.java:333)  
> [Server:server-one] at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.processSingleCall(CommandAwareRpcDispatcher.java:352)  
> [Server:server-one] at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.invokeRemoteCommand(CommandAwareRpcDispatcher.java:167)  
> [Server:server-one] ... 76 more  
> [Server:server-one] Caused by: org.infinispan.commons.marshall.NotSerializableException: org.jboss.weld.bean.ManagedBean  
> [Server:server-one] Caused by: an exception which occurred:  
> [Server:server-one] in object java.util.HashMap at b37422bb  
> [Server:server-one] in object org.jboss.as.clustering.marshalling.SimpleMarshalledValue at b37422bb  
> [Server:server-one] in object org.infinispan.commands.write.PutKeyValueCommand at db517a36  
> [Server:server-one] in object org.infinispan.commands.tx.PrepareCommand at 6fa34718  
> {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

From issues at jboss.org  Thu Mar 13 08:56:13 2014
From: issues at jboss.org (Richard Achmatowicz (JIRA))
Date: Thu, 13 Mar 2014 08:56:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1799) RpcDispatcher test fails when
 working with large values
In-Reply-To: <JIRA.12533122.1393254868000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12533122.1393254868000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12533122.1393254868000.12793.1394715373545@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JGRP-1799?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12952656#comment-12952656 ] 

Richard Achmatowicz commented on JGRP-1799:
-------------------------------------------

The timeout has been increased from 30s to 60s. 
PR is here: https://github.com/belaban/JGroups/pull/132


                
> RpcDispatcher test fails when working with large values
> -------------------------------------------------------
>
>                 Key: JGRP-1799
>                 URL: https://issues.jboss.org/browse/JGRP-1799
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.2.13
>         Environment: RHEL, Win, Solaris
>            Reporter: Richard Achmatowicz
>            Assignee: Bela Ban
>             Fix For: 3.2.13
>
>
> The two tests:
> * testLargeReturnValue
> * testLargeReturnValueUnicastCall
> make RPC calls with values which are increasingly large. 
> The values used are in this range:
> {noformat}
> SIZES={10000, 20000, 40000, 80000, 100000, 200000, 400000, 800000,1000000, 2000000, 5000000}
> {noformat}
> The tests have been see to fail with the values 1000000, 2000000 and 5000000, always with the same error in each case. 
> In the case of testLargeReturnValue, the test fails because one of the returned values from the RPC is null.
> In the case of testLargeReturnValueUnicastCall, the test fails due to a timeout while sending the RPC.
>  

--
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

From issues at jboss.org  Thu Mar 13 08:56:15 2014
From: issues at jboss.org (Shelly McGowan (JIRA))
Date: Thu, 13 Mar 2014 08:56:15 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBEE-151) Missing doPrivileged block(s)
 around getContextClassLoader
In-Reply-To: <JIRA.12534710.1394563445000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534710.1394563445000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534710.1394563445000.12817.1394715375397@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JBEE-151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12952489#comment-12952489 ] 

Shelly McGowan edited comment on JBEE-151 at 3/13/14 8:55 AM:
--------------------------------------------------------------

Upstream patch committed to jboss-el-api_2.2 branch:
https://github.com/jboss/jboss-el-api_spec/commit/88e00f1d2e901cf6945471c573583fe0f0d8d58d


EL 2.2 API v1.0.4.Final has been released:
https://repository.jboss.org/nexus/content/groups/public/org/jboss/spec/javax/el/jboss-el-api_2.2_spec/1.0.4.Final/

                
      was (Author: shelly.mcgowan):
    Upstream patch committed to jboss-el-api_2.2 branch:
https://github.com/jboss/jboss-el-api_spec/commit/88e00f1d2e901cf6945471c573583fe0f0d8d58d


                  
>  Missing doPrivileged block(s) around getContextClassLoader
> -----------------------------------------------------------
>
>                 Key: JBEE-151
>                 URL: https://issues.jboss.org/browse/JBEE-151
>             Project: JBoss JavaEE Spec APIs
>          Issue Type: Bug
>          Components: jboss-el-api
>            Reporter: Carlo de Wolf
>            Assignee: Shelly McGowan
>             Fix For: jboss-el-api_2.2_spec-1.0.4.Final, jboss-el-api_3.0_spec-1.0.1.Final
>
>
> jboss-el-api_2.2_spec-1.0.2.Final-redhat-1.jar:1.0.2.Final-redhat-1
> {code}
> 12:56:34,897 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[default-host].[/read-props].[jsp]] (http-/127.0.0.1:8080-4) JBWEB000236: Servlet.service() for servlet jsp threw exception: java.security.AccessControlException: access denied ("java.lang.RuntimePermission" "getClassLoader")
> 	at java.security.AccessControlContext.checkPermission(AccessControlContext.java:372) [rt.jar:1.7.0_45]
> 	at java.security.AccessController.checkPermission(AccessController.java:559) [rt.jar:1.7.0_45]
> 	at java.lang.SecurityManager.checkPermission(SecurityManager.java:549) [rt.jar:1.7.0_45]
> 	at java.lang.ClassLoader.checkClassLoaderPermission(ClassLoader.java:1561) [rt.jar:1.7.0_45]
> 	at java.lang.Thread.getContextClassLoader(Thread.java:1472) [rt.jar:1.7.0_45]
> 	at javax.el.FactoryFinder.find(FactoryFinder.java:130) [jboss-el-api_2.2_spec-1.0.2.Final-redhat-1.jar:1.0.2.Final-redhat-1]
> 	at javax.el.ExpressionFactory.newInstance(ExpressionFactory.java:185) [jboss-el-api_2.2_spec-1.0.2.Final-redhat-1.jar:1.0.2.Final-redhat-1]
> 	at javax.el.ExpressionFactory.newInstance(ExpressionFactory.java:156) [jboss-el-api_2.2_spec-1.0.2.Final-redhat-1.jar:1.0.2.Final-redhat-1]
> 	at org.apache.jasper.runtime.JspApplicationContextImpl.<init>(JspApplicationContextImpl.java:48) [jbossweb-7.4.0.Beta4.jar:7.4.0.Beta4]
> {code}

--
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

From issues at jboss.org  Thu Mar 13 08:56:18 2014
From: issues at jboss.org (Richard Achmatowicz (JIRA))
Date: Thu, 13 Mar 2014 08:56:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1799) RpcDispatcher test fails when
 working with large values
In-Reply-To: <JIRA.12533122.1393254868000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12533122.1393254868000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12533122.1393254868000.12866.1394715378590@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JGRP-1799?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Richard Achmatowicz resolved JGRP-1799.
---------------------------------------

    Resolution: Done


Marking this issue as resolved as it seems that the additional delay in processing for large values on slow machines was the source of the problem.
If this turns out not to be the case, will reopen.

                
> RpcDispatcher test fails when working with large values
> -------------------------------------------------------
>
>                 Key: JGRP-1799
>                 URL: https://issues.jboss.org/browse/JGRP-1799
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.2.13
>         Environment: RHEL, Win, Solaris
>            Reporter: Richard Achmatowicz
>            Assignee: Bela Ban
>             Fix For: 3.2.13
>
>
> The two tests:
> * testLargeReturnValue
> * testLargeReturnValueUnicastCall
> make RPC calls with values which are increasingly large. 
> The values used are in this range:
> {noformat}
> SIZES={10000, 20000, 40000, 80000, 100000, 200000, 400000, 800000,1000000, 2000000, 5000000}
> {noformat}
> The tests have been see to fail with the values 1000000, 2000000 and 5000000, always with the same error in each case. 
> In the case of testLargeReturnValue, the test fails because one of the returned values from the RPC is null.
> In the case of testLargeReturnValueUnicastCall, the test fails due to a timeout while sending the RPC.
>  

--
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

From issues at jboss.org  Thu Mar 13 08:58:12 2014
From: issues at jboss.org (Richard Achmatowicz (JIRA))
Date: Thu, 13 Mar 2014 08:58:12 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1797) NakackTest
 testReceptionOfAllMessages fails to receive all messages
In-Reply-To: <JIRA.12533037.1393192228000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12533037.1393192228000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12533037.1393192228000.12896.1394715492287@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JGRP-1797?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Richard Achmatowicz resolved JGRP-1797.
---------------------------------------

    Resolution: Done


Marking this issue as done as it appears that thread contention in a non synchronized block was the problem. 
Will reopen if this proves not to be the case.

                
> NakackTest testReceptionOfAllMessages fails to receive all messages
> -------------------------------------------------------------------
>
>                 Key: JGRP-1797
>                 URL: https://issues.jboss.org/browse/JGRP-1797
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.2.13
>         Environment: RHEL (5/24), Solaris (6/24), HPUX (1/2) where x/y means x failures over y test executions.
>            Reporter: Richard Achmatowicz
>            Assignee: Bela Ban
>             Fix For: 3.2.13
>
>         Attachments: stdout.txt
>
>
> This test does the following:
> - involves channels A, B, and C where only B and C are senders and all are receivers
> - B and C send 1000 multicast messages
> - checks that all messages are received and in the correct order
> This test is failing intermittently but quite often.

--
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

From issues at jboss.org  Thu Mar 13 09:00:14 2014
From: issues at jboss.org (Richard Achmatowicz (JIRA))
Date: Thu, 13 Mar 2014 09:00:14 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1802) OverlappingUnicastMergeTest
 fails to receive all messages
In-Reply-To: <JIRA.12533772.1393856602000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12533772.1393856602000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12533772.1393856602000.12933.1394715614365@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JGRP-1802?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12952662#comment-12952662 ] 

Richard Achmatowicz commented on JGRP-1802:
-------------------------------------------

Provided synchronized access to results array for channel receiver. PR is attached.

                
> OverlappingUnicastMergeTest fails to receive all messages
> ---------------------------------------------------------
>
>                 Key: JGRP-1802
>                 URL: https://issues.jboss.org/browse/JGRP-1802
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.2.13
>         Environment: Solaris, RHEL
>            Reporter: Richard Achmatowicz
>            Assignee: Bela Ban
>             Fix For: 3.2.13
>
>
> OverlappingUnicastMergeTest does the following:
> - set up three channels a,b,c with the layers MERGE2, VERIFY_SUSPECT and FC removed
> - the receiver of each channel will look at all incoming messages: if mcast, ignore it; if unicast, add to the list of messages received
> - inject some new view into the channels which represents a view configuration which should be recovered from
> - send messages to the channels and check that the messages are received, despite the  injected view
> OverlappingUnicastMergeTest this test is failing in a number of ways (i.e. many of the test methods are failing within the test class on multiple platforms. 
> What we expect to see is:
> {noformat}
> receiver A: ucasts=15
> receiver B: ucasts=15
> receiver C: ucasts=15
> {noformat}
> What we instead see is:
> {noformat}
> receiver A: ucasts=15
> receiver B: ucasts=11
> ucasts for B: 
> B: unicast msg #1 from B B: unicast msg #2 from B B: unicast msg #3 from B B: unicast msg #4 from B B: unicast msg #5 from B  A: unicast msg #1 from A C: unicast msg #2 from C C: unicast msg #3 from C A: unicast msg #4 from A C: unicast msg #4 from C C: unicast msg #5 from C 
> {noformat}
> The order here is the order in which the unicasts were received from all three senders by the single receiver. For example, in the above, in testWithViewBC, channel A should receive messages #1 through #5 from channels A, B and C, but it does not receive #1 from channel C. 

--
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

From issues at jboss.org  Thu Mar 13 09:10:10 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 13 Mar 2014 09:10:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3108) Can't promote --backup slave
 HC to master and reload without moving domain.cached-remote.xml
In-Reply-To: <JIRA.12534873.1394711186000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534873.1394711186000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534873.1394711186000.12950.1394716210831@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-3108?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated WFLY-3108:
------------------------------------------

        Bugzilla Update: Perform
    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1076066

    
> Can't promote --backup slave HC to master and reload without moving domain.cached-remote.xml
> --------------------------------------------------------------------------------------------
>
>                 Key: WFLY-3108
>                 URL: https://issues.jboss.org/browse/WFLY-3108
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>    Affects Versions: 8.0.0.Final
>            Reporter: Brian Stansberry
>            Assignee: Brian Stansberry
>             Fix For: 8.0.1.Final
>
>
> The prescribed mechanism for converting a slave HC to master is to:
> 1) Start the slave with --backup so a local copy of the domain config is maintained (in file domain.cached-remote.xml).
> 2) Stop the existing master.
> 3) Use the cli to connect to the slave and
> /host=<slavename>:write-local-domain-controller
> 4) Then, in the CLI
> reload --host=<slavename>
> Problem is this fails because the HC expects to have a domain config file "domain.xml".
> 2014-03-13 09:54:04,829 ERROR [org.jboss.as.host.controller] (Controller Boot Thread) JBAS010932: Caught exception during boot: org.jboss.as.controller.persistence.ConfigurationPersistenceException: JBAS014676: Failed to parse configuration
> 	at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:112) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> 	at org.jboss.as.host.controller.DomainModelControllerService.boot(DomainModelControllerService.java:514) [wildfly-host-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> 	at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:256) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> 	at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_45]
> Caused by: java.io.FileNotFoundException: /Users/bstansberry/tmp/WF801/slave/domain/configuration/domain.xml (No such file or directory)
> 	at java.io.FileInputStream.open(Native Method) [rt.jar:1.7.0_45]
> 	at java.io.FileInputStream.<init>(FileInputStream.java:146) [rt.jar:1.7.0_45]
> 	at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:100) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> 	... 3 more
> Or, MUCH WORSE, there happens to be a random domain.xml in the filesystem, which has content that is out of sync with the correct domain config. This domain.xml config will be used.

--
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

From issues at jboss.org  Thu Mar 13 09:20:10 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 13 Mar 2014 09:20:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3108) Can't promote --backup slave
 HC to master and reload without moving domain.cached-remote.xml
In-Reply-To: <JIRA.12534873.1394711186000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534873.1394711186000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534873.1394711186000.12977.1394716810666@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-3108?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12952673#comment-12952673 ] 

RH Bugzilla Integration commented on WFLY-3108:
-----------------------------------------------

Brian Stansberry <brian.stansberry at redhat.com> changed the Status of [bug 1076066|https://bugzilla.redhat.com/show_bug.cgi?id=1076066] from NEW to ASSIGNED
                
> Can't promote --backup slave HC to master and reload without moving domain.cached-remote.xml
> --------------------------------------------------------------------------------------------
>
>                 Key: WFLY-3108
>                 URL: https://issues.jboss.org/browse/WFLY-3108
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>    Affects Versions: 8.0.0.Final
>            Reporter: Brian Stansberry
>            Assignee: Brian Stansberry
>             Fix For: 8.0.1.Final
>
>
> The prescribed mechanism for converting a slave HC to master is to:
> 1) Start the slave with --backup so a local copy of the domain config is maintained (in file domain.cached-remote.xml).
> 2) Stop the existing master.
> 3) Use the cli to connect to the slave and
> /host=<slavename>:write-local-domain-controller
> 4) Then, in the CLI
> reload --host=<slavename>
> Problem is this fails because the HC expects to have a domain config file "domain.xml".
> 2014-03-13 09:54:04,829 ERROR [org.jboss.as.host.controller] (Controller Boot Thread) JBAS010932: Caught exception during boot: org.jboss.as.controller.persistence.ConfigurationPersistenceException: JBAS014676: Failed to parse configuration
> 	at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:112) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> 	at org.jboss.as.host.controller.DomainModelControllerService.boot(DomainModelControllerService.java:514) [wildfly-host-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> 	at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:256) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> 	at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_45]
> Caused by: java.io.FileNotFoundException: /Users/bstansberry/tmp/WF801/slave/domain/configuration/domain.xml (No such file or directory)
> 	at java.io.FileInputStream.open(Native Method) [rt.jar:1.7.0_45]
> 	at java.io.FileInputStream.<init>(FileInputStream.java:146) [rt.jar:1.7.0_45]
> 	at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:100) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> 	... 3 more
> Or, MUCH WORSE, there happens to be a random domain.xml in the filesystem, which has content that is out of sync with the correct domain config. This domain.xml config will be used.

--
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

From issues at jboss.org  Thu Mar 13 10:18:10 2014
From: issues at jboss.org (Jesper Pedersen (JIRA))
Date: Thu, 13 Mar 2014 10:18:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBJCA-1154) IronJacamar 1.1.4.Final
In-Reply-To: <JIRA.12534902.1394720289582@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534902.1394720289582@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534902.1394720289582.13227.1394720290600@jira02.app.mwc.hst.phx2.redhat.com>

Jesper Pedersen created JBJCA-1154:
--------------------------------------

             Summary: IronJacamar 1.1.4.Final
                 Key: JBJCA-1154
                 URL: https://issues.jboss.org/browse/JBJCA-1154
             Project: IronJacamar
          Issue Type: Release
          Components: Build
            Reporter: Jesper Pedersen
            Assignee: Jesper Pedersen
             Fix For: 1.1.4.Final


Release notes: https://issues.jboss.org/secure/ReleaseNote.jspa?projectId=12310691&version=12323928

--
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

From issues at jboss.org  Thu Mar 13 10:24:11 2014
From: issues at jboss.org (Jesper Pedersen (JIRA))
Date: Thu, 13 Mar 2014 10:24:11 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBJCA-1154) IronJacamar 1.1.4.Final
In-Reply-To: <JIRA.12534902.1394720289000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534902.1394720289000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534902.1394720289000.13304.1394720651387@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBJCA-1154?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jesper Pedersen resolved JBJCA-1154.
------------------------------------

    Resolution: Done

    
> IronJacamar 1.1.4.Final
> -----------------------
>
>                 Key: JBJCA-1154
>                 URL: https://issues.jboss.org/browse/JBJCA-1154
>             Project: IronJacamar
>          Issue Type: Release
>          Components: Build
>            Reporter: Jesper Pedersen
>            Assignee: Jesper Pedersen
>             Fix For: 1.1.4.Final
>
>
> Release notes: https://issues.jboss.org/secure/ReleaseNote.jspa?projectId=12310691&version=12323928

--
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

From issues at jboss.org  Thu Mar 13 10:28:10 2014
From: issues at jboss.org (Farah Juma (JIRA))
Date: Thu, 13 Mar 2014 10:28:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3044) Mojarra's @ViewScoped
 implementation is not cluster-aware resulting in NotSerializableException
In-Reply-To: <JIRA.12533615.1393599715000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12533615.1393599715000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12533615.1393599715000.13311.1394720890611@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-3044?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12952713#comment-12952713 ] 

Farah Juma commented on WFLY-3044:
----------------------------------

There isn't too much about ViewScoped in the actual spec (see Section 7.8.1.1 in the spec file [here | http://download.oracle.com/otndocs/jcp/jsf-2_2-fr-eval-spec/index.html ]). 

We'll need to wait for [JAVASERVERFACES_SPEC_PUBLIC-1268| https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1268] to be resolved.


                
> Mojarra's @ViewScoped implementation is not cluster-aware resulting in NotSerializableException
> -----------------------------------------------------------------------------------------------
>
>                 Key: WFLY-3044
>                 URL: https://issues.jboss.org/browse/WFLY-3044
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JSF
>    Affects Versions: 8.0.0.Final
>            Reporter: Radoslav Husar
>            Assignee: Radoslav Husar
>            Priority: Critical
>             Fix For: 8.0.1.Final
>
>
> The problem is in ViewScopeContextManager, namely 
> {code}
>             getContextMap(facesContext).put(contextual, new ViewScopeContextObject(contextual, creational, name));
> {code}
> probably it needs an artificial ID generated to serve as a key.
> Also the ViewScopeContextObject needs to be serializable as well among other things
> {code}
> class ViewScopeContextObject {
> {code}
> Issue manifests as
> {noformat}[Server:server-one] 19:22:41,564 ERROR [org.infinispan.interceptors.InvocationContextInterceptor] (default task-15) ISPN000136: Execution error: org.infinispan.commons.CacheException: java.lang.RuntimeException: Failure to marshal argument(s)  
> [Server:server-one] at org.infinispan.commons.util.Util.rewrapAsCacheException(Util.java:581)  
> ...  
> [Server:server-one] at org.infinispan.transaction.tm.DummyTransaction.notifyAfterCompletion(DummyTransaction.java:263)  
> [Server:server-one] at org.infinispan.transaction.tm.DummyTransaction.runCommitTx(DummyTransaction.java:312)  
> [Server:server-one] at org.infinispan.transaction.tm.DummyTransaction.commit(DummyTransaction.java:69)  
> [Server:server-one] at org.infinispan.transaction.tm.DummyBaseTransactionManager.commit(DummyBaseTransactionManager.java:80)  
> [Server:server-one] at org.infinispan.batch.BatchContainer.resolveTransaction(BatchContainer.java:101)  
> [Server:server-one] at org.infinispan.batch.BatchContainer.endBatch(BatchContainer.java:83)  
> [Server:server-one] at org.infinispan.batch.BatchContainer.endBatch(BatchContainer.java:64)  
> [Server:server-one] at org.infinispan.CacheImpl.endBatch(CacheImpl.java:777)  
> [Server:server-one] at org.infinispan.AbstractDelegatingCache.endBatch(AbstractDelegatingCache.java:53)  
> [Server:server-one] at org.wildfly.clustering.web.infinispan.InfinispanBatcher$1.end(InfinispanBatcher.java:56)  
> [Server:server-one] at org.wildfly.clustering.web.infinispan.InfinispanBatcher$1.close(InfinispanBatcher.java:46)  
> [Server:server-one] at org.wildfly.clustering.web.undertow.session.DistributableSession.requestDone(DistributableSession.java:72)  
> [Server:server-one] at io.undertow.servlet.spec.ServletContextImpl.updateSessionAccessTime(ServletContextImpl.java:704) [undertow-servlet-1.0.0.Final.jar:1.0.0.Final]  
> [Server:server-one] at io.undertow.servlet.spec.HttpServletResponseImpl.responseDone(HttpServletResponseImpl.java:522) [undertow-servlet-1.0.0.Final.jar:1.0.0.Final]  
> [Server:server-one] at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:287) [undertow-servlet-1.0.0.Final.jar:1.0.0.Final]  
> [Server:server-one] at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:227) [undertow-servlet-1.0.0.Final.jar:1.0.0.Final]  
> [Server:server-one] at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:73) [undertow-servlet-1.0.0.Final.jar:1.0.0.Final]  
> [Server:server-one] at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:146) [undertow-servlet-1.0.0.Final.jar:1.0.0.Final]  
> [Server:server-one] at io.undertow.server.Connectors.executeRootHandler(Connectors.java:168) [undertow-core-1.0.0.Final.jar:1.0.0.Final]  
> [Server:server-one] at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:687) [undertow-core-1.0.0.Final.jar:1.0.0.Final]  
> [Server:server-one] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_51]  
> [Server:server-one] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_51]  
> [Server:server-one] at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_51]  
> [Server:server-one] Caused by: java.lang.RuntimeException: Failure to marshal argument(s)  
> [Server:server-one] at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.marshallCall(CommandAwareRpcDispatcher.java:333)  
> [Server:server-one] at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.processSingleCall(CommandAwareRpcDispatcher.java:352)  
> [Server:server-one] at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.invokeRemoteCommand(CommandAwareRpcDispatcher.java:167)  
> [Server:server-one] ... 76 more  
> [Server:server-one] Caused by: org.infinispan.commons.marshall.NotSerializableException: org.jboss.weld.bean.ManagedBean  
> [Server:server-one] Caused by: an exception which occurred:  
> [Server:server-one] in object java.util.HashMap at b37422bb  
> [Server:server-one] in object org.jboss.as.clustering.marshalling.SimpleMarshalledValue at b37422bb  
> [Server:server-one] in object org.infinispan.commands.write.PutKeyValueCommand at db517a36  
> [Server:server-one] in object org.infinispan.commands.tx.PrepareCommand at 6fa34718  
> {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

From issues at jboss.org  Thu Mar 13 10:34:10 2014
From: issues at jboss.org (Farah Juma (JIRA))
Date: Thu, 13 Mar 2014 10:34:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3044) Mojarra's @ViewScoped
 implementation is not cluster-aware resulting in NotSerializableException
In-Reply-To: <JIRA.12533615.1393599715000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12533615.1393599715000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12533615.1393599715000.13322.1394721250850@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-3044?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12952713#comment-12952713 ] 

Farah Juma edited comment on WFLY-3044 at 3/13/14 10:32 AM:
------------------------------------------------------------

There isn't too much about ViewScoped in the actual spec file (see Section 7.8.1.1 in the spec file [here | http://download.oracle.com/otndocs/jcp/jsf-2_2-fr-eval-spec/index.html ]). However, the [javadocs | http://docs.oracle.com/javaee/7/api/javax/faces/view/ViewScoped.html]  for ViewScoped does have just the @NormalScope annotation though (passivating defaults to false).

We'll need to wait for [JAVASERVERFACES_SPEC_PUBLIC-1268| https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1268] to be resolved.


                
      was (Author: fjuma):
    There isn't too much about ViewScoped in the actual spec (see Section 7.8.1.1 in the spec file [here | http://download.oracle.com/otndocs/jcp/jsf-2_2-fr-eval-spec/index.html ]). 

We'll need to wait for [JAVASERVERFACES_SPEC_PUBLIC-1268| https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1268] to be resolved.


                  
> Mojarra's @ViewScoped implementation is not cluster-aware resulting in NotSerializableException
> -----------------------------------------------------------------------------------------------
>
>                 Key: WFLY-3044
>                 URL: https://issues.jboss.org/browse/WFLY-3044
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JSF
>    Affects Versions: 8.0.0.Final
>            Reporter: Radoslav Husar
>            Assignee: Radoslav Husar
>            Priority: Critical
>             Fix For: 8.0.1.Final
>
>
> The problem is in ViewScopeContextManager, namely 
> {code}
>             getContextMap(facesContext).put(contextual, new ViewScopeContextObject(contextual, creational, name));
> {code}
> probably it needs an artificial ID generated to serve as a key.
> Also the ViewScopeContextObject needs to be serializable as well among other things
> {code}
> class ViewScopeContextObject {
> {code}
> Issue manifests as
> {noformat}[Server:server-one] 19:22:41,564 ERROR [org.infinispan.interceptors.InvocationContextInterceptor] (default task-15) ISPN000136: Execution error: org.infinispan.commons.CacheException: java.lang.RuntimeException: Failure to marshal argument(s)  
> [Server:server-one] at org.infinispan.commons.util.Util.rewrapAsCacheException(Util.java:581)  
> ...  
> [Server:server-one] at org.infinispan.transaction.tm.DummyTransaction.notifyAfterCompletion(DummyTransaction.java:263)  
> [Server:server-one] at org.infinispan.transaction.tm.DummyTransaction.runCommitTx(DummyTransaction.java:312)  
> [Server:server-one] at org.infinispan.transaction.tm.DummyTransaction.commit(DummyTransaction.java:69)  
> [Server:server-one] at org.infinispan.transaction.tm.DummyBaseTransactionManager.commit(DummyBaseTransactionManager.java:80)  
> [Server:server-one] at org.infinispan.batch.BatchContainer.resolveTransaction(BatchContainer.java:101)  
> [Server:server-one] at org.infinispan.batch.BatchContainer.endBatch(BatchContainer.java:83)  
> [Server:server-one] at org.infinispan.batch.BatchContainer.endBatch(BatchContainer.java:64)  
> [Server:server-one] at org.infinispan.CacheImpl.endBatch(CacheImpl.java:777)  
> [Server:server-one] at org.infinispan.AbstractDelegatingCache.endBatch(AbstractDelegatingCache.java:53)  
> [Server:server-one] at org.wildfly.clustering.web.infinispan.InfinispanBatcher$1.end(InfinispanBatcher.java:56)  
> [Server:server-one] at org.wildfly.clustering.web.infinispan.InfinispanBatcher$1.close(InfinispanBatcher.java:46)  
> [Server:server-one] at org.wildfly.clustering.web.undertow.session.DistributableSession.requestDone(DistributableSession.java:72)  
> [Server:server-one] at io.undertow.servlet.spec.ServletContextImpl.updateSessionAccessTime(ServletContextImpl.java:704) [undertow-servlet-1.0.0.Final.jar:1.0.0.Final]  
> [Server:server-one] at io.undertow.servlet.spec.HttpServletResponseImpl.responseDone(HttpServletResponseImpl.java:522) [undertow-servlet-1.0.0.Final.jar:1.0.0.Final]  
> [Server:server-one] at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:287) [undertow-servlet-1.0.0.Final.jar:1.0.0.Final]  
> [Server:server-one] at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:227) [undertow-servlet-1.0.0.Final.jar:1.0.0.Final]  
> [Server:server-one] at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:73) [undertow-servlet-1.0.0.Final.jar:1.0.0.Final]  
> [Server:server-one] at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:146) [undertow-servlet-1.0.0.Final.jar:1.0.0.Final]  
> [Server:server-one] at io.undertow.server.Connectors.executeRootHandler(Connectors.java:168) [undertow-core-1.0.0.Final.jar:1.0.0.Final]  
> [Server:server-one] at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:687) [undertow-core-1.0.0.Final.jar:1.0.0.Final]  
> [Server:server-one] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_51]  
> [Server:server-one] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_51]  
> [Server:server-one] at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_51]  
> [Server:server-one] Caused by: java.lang.RuntimeException: Failure to marshal argument(s)  
> [Server:server-one] at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.marshallCall(CommandAwareRpcDispatcher.java:333)  
> [Server:server-one] at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.processSingleCall(CommandAwareRpcDispatcher.java:352)  
> [Server:server-one] at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.invokeRemoteCommand(CommandAwareRpcDispatcher.java:167)  
> [Server:server-one] ... 76 more  
> [Server:server-one] Caused by: org.infinispan.commons.marshall.NotSerializableException: org.jboss.weld.bean.ManagedBean  
> [Server:server-one] Caused by: an exception which occurred:  
> [Server:server-one] in object java.util.HashMap at b37422bb  
> [Server:server-one] in object org.jboss.as.clustering.marshalling.SimpleMarshalledValue at b37422bb  
> [Server:server-one] in object org.infinispan.commands.write.PutKeyValueCommand at db517a36  
> [Server:server-one] in object org.infinispan.commands.tx.PrepareCommand at 6fa34718  
> {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

From issues at jboss.org  Thu Mar 13 11:18:11 2014
From: issues at jboss.org (Emanuel Muckenhuber (JIRA))
Date: Thu, 13 Mar 2014 11:18:11 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3110) Don't copy the contents to
 all hosts when assigning a deployment to a server-group
In-Reply-To: <JIRA.12534883.1394713780000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534883.1394713780000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534883.1394713780000.13896.1394723891047@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-3110?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Emanuel Muckenhuber updated WFLY-3110:
--------------------------------------

        Summary: Don't copy the contents to all hosts when assigning a deployment to a server-group  (was: Don't copy deployment contents to all hosts when updating an existing deployment)
    Description: When assigning a deployment to a server-group it also copies the actual deployment contents to all hosts regardless of the whether the deployment is used locally or not. This should be changed that the contents are only retrieved if they are actually needed on a local server.  (was: In case a deployment gets updated, the full-replace deployment handler on the host-controller retrieves the deployment regardless a local server uses this deployment or not.

This does not seem to be affecting the deployment add operation, which will only get the deployment contents when an actual server requires the contents.)

    
> Don't copy the contents to all hosts when assigning a deployment to a server-group
> ----------------------------------------------------------------------------------
>
>                 Key: WFLY-3110
>                 URL: https://issues.jboss.org/browse/WFLY-3110
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>    Affects Versions: 8.0.0.Final
>            Reporter: Emanuel Muckenhuber
>            Assignee: Emanuel Muckenhuber
>             Fix For: 8.0.1.Final
>
>
> When assigning a deployment to a server-group it also copies the actual deployment contents to all hosts regardless of the whether the deployment is used locally or not. This should be changed that the contents are only retrieved if they are actually needed on a local server.

--
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

From issues at jboss.org  Thu Mar 13 11:22:15 2014
From: issues at jboss.org (Shelly McGowan (JIRA))
Date: Thu, 13 Mar 2014 11:22:15 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBEE-151) Missing doPrivileged block(s)
 around getContextClassLoader
In-Reply-To: <JIRA.12534710.1394563445000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534710.1394563445000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534710.1394563445000.14011.1394724135131@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JBEE-151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12952498#comment-12952498 ] 

Shelly McGowan edited comment on JBEE-151 at 3/13/14 11:21 AM:
---------------------------------------------------------------

Fix also committed to master branch for jboss-el-api_3.0:
https://github.com/jboss/jboss-el-api_spec/commit/c82e83c9c78d25abd839f6432ff99527b1e0017c

EL 3.0 API v1.0.1.Final has been released:
https://repository.jboss.org/nexus/content/groups/public/org/jboss/spec/javax/el/jboss-el-api_3.0_spec/1.0.1.Final/
                
      was (Author: shelly.mcgowan):
    Fix also committed to master branch for jboss-el-api_3.0:
https://github.com/jboss/jboss-el-api_spec/commit/c82e83c9c78d25abd839f6432ff99527b1e0017c

                  
>  Missing doPrivileged block(s) around getContextClassLoader
> -----------------------------------------------------------
>
>                 Key: JBEE-151
>                 URL: https://issues.jboss.org/browse/JBEE-151
>             Project: JBoss JavaEE Spec APIs
>          Issue Type: Bug
>          Components: jboss-el-api
>            Reporter: Carlo de Wolf
>            Assignee: Shelly McGowan
>             Fix For: jboss-el-api_2.2_spec-1.0.4.Final, jboss-el-api_3.0_spec-1.0.1.Final
>
>
> jboss-el-api_2.2_spec-1.0.2.Final-redhat-1.jar:1.0.2.Final-redhat-1
> {code}
> 12:56:34,897 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[default-host].[/read-props].[jsp]] (http-/127.0.0.1:8080-4) JBWEB000236: Servlet.service() for servlet jsp threw exception: java.security.AccessControlException: access denied ("java.lang.RuntimePermission" "getClassLoader")
> 	at java.security.AccessControlContext.checkPermission(AccessControlContext.java:372) [rt.jar:1.7.0_45]
> 	at java.security.AccessController.checkPermission(AccessController.java:559) [rt.jar:1.7.0_45]
> 	at java.lang.SecurityManager.checkPermission(SecurityManager.java:549) [rt.jar:1.7.0_45]
> 	at java.lang.ClassLoader.checkClassLoaderPermission(ClassLoader.java:1561) [rt.jar:1.7.0_45]
> 	at java.lang.Thread.getContextClassLoader(Thread.java:1472) [rt.jar:1.7.0_45]
> 	at javax.el.FactoryFinder.find(FactoryFinder.java:130) [jboss-el-api_2.2_spec-1.0.2.Final-redhat-1.jar:1.0.2.Final-redhat-1]
> 	at javax.el.ExpressionFactory.newInstance(ExpressionFactory.java:185) [jboss-el-api_2.2_spec-1.0.2.Final-redhat-1.jar:1.0.2.Final-redhat-1]
> 	at javax.el.ExpressionFactory.newInstance(ExpressionFactory.java:156) [jboss-el-api_2.2_spec-1.0.2.Final-redhat-1.jar:1.0.2.Final-redhat-1]
> 	at org.apache.jasper.runtime.JspApplicationContextImpl.<init>(JspApplicationContextImpl.java:48) [jbossweb-7.4.0.Beta4.jar:7.4.0.Beta4]
> {code}

--
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

From issues at jboss.org  Thu Mar 13 11:22:16 2014
From: issues at jboss.org (Shelly McGowan (JIRA))
Date: Thu, 13 Mar 2014 11:22:16 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBEE-151) Missing doPrivileged block(s)
 around getContextClassLoader
In-Reply-To: <JIRA.12534710.1394563445000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534710.1394563445000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534710.1394563445000.14029.1394724136606@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBEE-151?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Shelly McGowan resolved JBEE-151.
---------------------------------

    Resolution: Done

    
>  Missing doPrivileged block(s) around getContextClassLoader
> -----------------------------------------------------------
>
>                 Key: JBEE-151
>                 URL: https://issues.jboss.org/browse/JBEE-151
>             Project: JBoss JavaEE Spec APIs
>          Issue Type: Bug
>          Components: jboss-el-api
>            Reporter: Carlo de Wolf
>            Assignee: Shelly McGowan
>             Fix For: jboss-el-api_2.2_spec-1.0.4.Final, jboss-el-api_3.0_spec-1.0.1.Final
>
>
> jboss-el-api_2.2_spec-1.0.2.Final-redhat-1.jar:1.0.2.Final-redhat-1
> {code}
> 12:56:34,897 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[default-host].[/read-props].[jsp]] (http-/127.0.0.1:8080-4) JBWEB000236: Servlet.service() for servlet jsp threw exception: java.security.AccessControlException: access denied ("java.lang.RuntimePermission" "getClassLoader")
> 	at java.security.AccessControlContext.checkPermission(AccessControlContext.java:372) [rt.jar:1.7.0_45]
> 	at java.security.AccessController.checkPermission(AccessController.java:559) [rt.jar:1.7.0_45]
> 	at java.lang.SecurityManager.checkPermission(SecurityManager.java:549) [rt.jar:1.7.0_45]
> 	at java.lang.ClassLoader.checkClassLoaderPermission(ClassLoader.java:1561) [rt.jar:1.7.0_45]
> 	at java.lang.Thread.getContextClassLoader(Thread.java:1472) [rt.jar:1.7.0_45]
> 	at javax.el.FactoryFinder.find(FactoryFinder.java:130) [jboss-el-api_2.2_spec-1.0.2.Final-redhat-1.jar:1.0.2.Final-redhat-1]
> 	at javax.el.ExpressionFactory.newInstance(ExpressionFactory.java:185) [jboss-el-api_2.2_spec-1.0.2.Final-redhat-1.jar:1.0.2.Final-redhat-1]
> 	at javax.el.ExpressionFactory.newInstance(ExpressionFactory.java:156) [jboss-el-api_2.2_spec-1.0.2.Final-redhat-1.jar:1.0.2.Final-redhat-1]
> 	at org.apache.jasper.runtime.JspApplicationContextImpl.<init>(JspApplicationContextImpl.java:48) [jbossweb-7.4.0.Beta4.jar:7.4.0.Beta4]
> {code}

--
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

From issues at jboss.org  Thu Mar 13 11:24:12 2014
From: issues at jboss.org (Shelly McGowan (JIRA))
Date: Thu, 13 Mar 2014 11:24:12 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBEE-146) jboss-el-api_2.2_spec
 1.0.2.Final cannot access public methods from non-public classes
In-Reply-To: <JIRA.12525180.1384462560000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12525180.1384462560000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12525180.1384462560000.14063.1394724252040@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBEE-146?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Shelly McGowan updated JBEE-146:
--------------------------------

    Fix Version/s: jboss-el-api_3.0_spec-1.0.0.Final

    
> jboss-el-api_2.2_spec 1.0.2.Final cannot access public methods from non-public classes
> --------------------------------------------------------------------------------------
>
>                 Key: JBEE-146
>                 URL: https://issues.jboss.org/browse/JBEE-146
>             Project: JBoss JavaEE Spec APIs
>          Issue Type: Bug
>            Reporter: Farah Juma
>            Assignee: Farah Juma
>             Fix For: jboss-el-api_2.2_spec-1.0.3.Final, jboss-el-api_3.0_spec-1.0.0.Final
>
>
> When accessing a public method of a non-public class via EL that implements a public interface or has a public superclass, the following exception occurs:
> {code}java.lang.IllegalAccessException: Class javax.el.BeanELResolver can not access a member of class X with modifiers "public" 
> {code}
> See https://bugzilla.redhat.com/show_bug.cgi?id=1029387 for more 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

From issues at jboss.org  Thu Mar 13 11:26:11 2014
From: issues at jboss.org (Yong Hao Gao (JIRA))
Date: Thu, 13 Mar 2014 11:26:11 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBMESSAGING-1941) Messaging deadlocks on
 AspectManager
In-Reply-To: <JIRA.12484258.1360189635000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12484258.1360189635000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12484258.1360189635000.14076.1394724371113@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBMESSAGING-1941?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Yong Hao Gao reassigned JBMESSAGING-1941:
-----------------------------------------

    Assignee: Yong Hao Gao

    
> Messaging deadlocks on AspectManager
> ------------------------------------
>
>                 Key: JBMESSAGING-1941
>                 URL: https://issues.jboss.org/browse/JBMESSAGING-1941
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 1.4.8.SP9
>         Environment: -JBoss Enterprise Application Platform (EAP) 5
>            Reporter: Aaron Ogburn
>            Assignee: Yong Hao Gao
>         Attachments: 00779442testpatch.diff, JBMESSAGING-1941.diff
>
>
> Messaging can stall JBoss at start up.  The hang occurs as the main thread blocks in different locations in JMS trying to acquire the AspectManager instance lock:
> {noformat} 
> "main" prio=10 tid=0x00007fe69c1e1000 nid=0x3613 waiting for monitor entry [0x00007fe6828e5000]
>    java.lang.Thread.State: BLOCKED (on object monitor)
>         at org.jboss.aop.AspectManager.getAdvisor(AspectManager.java:728)
>         - waiting to lock <0x00000000a5e43e50> (a org.jboss.aop.AspectManager)
>         at org.jboss.jms.server.endpoint.advised.SessionAdvised.<clinit>(SessionAdvised.java)
>         at org.jboss.jms.server.endpoint.ServerConnectionEndpoint.createSessionDelegate(ServerConnectionEndpoint.java:273)
>         - locked <0x00000000a5600f48> (a org.jboss.aop.asintegration.jboss5.ScopedVFSClassLoaderDomain)
>         at org.jboss.jms.server.endpoint.ServerConnectionEndpoint.createSessionDelegate(ServerConnectionEndpoint.java:229)
> {noformat} 
> Since the main thread is stalled, so too is start up.  This lock is always held by another making a similar call like so:
> {noformat} 
> "WorkManager(2)-1" daemon prio=10 tid=0x00007fe62dd96000 nid=0x363e in
> Object.wait() [0x00007fe68029a000]
>    java.lang.Thread.State: RUNNABLE
>         at org.jboss.jms.server.endpoint.ServerConnectionEndpoint.createSessionDelegate(ServerConnectionEndpoint.java:273)
>         - locked <0x00000000a5e43e50> (a org.jboss.aop.AspectManager)
>         at org.jboss.jms.server.endpoint.ServerConnectionEndpoint.createSessionDelegate(ServerConnectionEndpoint.java:229)
> {noformat} 
> The code there at line 273 is simple enough and shouldn't cause a long stall:
> {code:title=org.jboss.jms.server.endpoint.ServerConnectionEndpoint.java|borderStyle=solid}
>          synchronized (AspectManager.instance())
>          {
>             advised = new SessionAdvised(ep);     // line 273
>          }
> {code}
> Nonetheless, it does clearly hang at this line as WorkManager(2)-1 never progresses.  There's no GC/CPU issues or anything of that nature, but we get a slight in the thread dump as WorkManager(2)-1 is shown to be in Object.wait().  Checking the thread through pstack, we can see the issue.  It is waiting in native/JDK level operations required to initialize the SessionAdvised class:
> {noformat}
> Thread 2 (Thread 0x7fe68029d700 (LWP 13886)):
> #0  0x0000003b3e40b43c in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
> #1  0x00007fe6a12d447e in os:latformEvent:ark() () from /opt/app/jvm/jdk1.6.0_38/jre/lib/amd64/server/libjvm.so
> #2  0x00007fe6a12c54fa in ObjectMonitor::wait(long, bool, Thread*) () from /opt/app/jvm/jdk1.6.0_38/jre/lib/amd64/server/libjvm.so
> #3  0x00007fe6a13ab5f0 in ObjectSynchronizer::waitUninterruptibly(Handle, long, Thread*) () from /opt/app/jvm/jdk1.6.0_38/jre/lib/amd64/server/libjvm.so
> #4  0x00007fe6a107115b in instanceKlass::initialize_impl(instanceKlassHandle, Thread*) () from /opt/app/jvm/jdk1.6.0_38/jre/lib/amd64/server/libjvm.so
> #5  0x00007fe6a107077a in instanceKlass::initialize(Thread*) () from /opt/app/jvm/jdk1.6.0_38/jre/lib/amd64/server/libjvm.so
> #6  0x00007fe6a1097c5c in InterpreterRuntime::_new(JavaThread*, constantPoolOopDesc*, int) () from /opt/app/jvm/jdk1.6.0_38/jre/lib/amd64/server/libjvm.so
> {noformat}
> These calls are naturally synchronized internally in the JVM so only one thread can proceed through initialization of a class at a given time.  Checking for any threads in process of initializing SessionAdvised, we can see only the main thread is.  But the main thread is still blocked for the AspectManager lock.
> So we have a deadlock here.  The main thread holds the initialization lock while waiting for the AspectManager lock, while the WorkManager(2)-1 thread holds the AspectManager lock while waiting for the initialization lock.
> The initialization of SessionAdvised is wrapped in the synchronized block so the main thread should not have been able to proceed into the initialization at all without already possessing the AspectManager lock.  It locks the ScopedVFSClassLoaderDomain, which extends the AspectManager.  This is different from the actual AspectManager though that main tries to lock in the clinit call and that it deadlocks on.

--
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

From issues at jboss.org  Thu Mar 13 11:26:11 2014
From: issues at jboss.org (Yong Hao Gao (JIRA))
Date: Thu, 13 Mar 2014 11:26:11 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBMESSAGING-1941) Messaging deadlocks on
 AspectManager
In-Reply-To: <JIRA.12484258.1360189635000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12484258.1360189635000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12484258.1360189635000.14078.1394724371306@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBMESSAGING-1941?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Yong Hao Gao updated JBMESSAGING-1941:
--------------------------------------

    Fix Version/s: 1.4.8.SP10

    
> Messaging deadlocks on AspectManager
> ------------------------------------
>
>                 Key: JBMESSAGING-1941
>                 URL: https://issues.jboss.org/browse/JBMESSAGING-1941
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 1.4.8.SP9
>         Environment: -JBoss Enterprise Application Platform (EAP) 5
>            Reporter: Aaron Ogburn
>            Assignee: Yong Hao Gao
>             Fix For: 1.4.8.SP10
>
>         Attachments: 00779442testpatch.diff, JBMESSAGING-1941.diff
>
>
> Messaging can stall JBoss at start up.  The hang occurs as the main thread blocks in different locations in JMS trying to acquire the AspectManager instance lock:
> {noformat} 
> "main" prio=10 tid=0x00007fe69c1e1000 nid=0x3613 waiting for monitor entry [0x00007fe6828e5000]
>    java.lang.Thread.State: BLOCKED (on object monitor)
>         at org.jboss.aop.AspectManager.getAdvisor(AspectManager.java:728)
>         - waiting to lock <0x00000000a5e43e50> (a org.jboss.aop.AspectManager)
>         at org.jboss.jms.server.endpoint.advised.SessionAdvised.<clinit>(SessionAdvised.java)
>         at org.jboss.jms.server.endpoint.ServerConnectionEndpoint.createSessionDelegate(ServerConnectionEndpoint.java:273)
>         - locked <0x00000000a5600f48> (a org.jboss.aop.asintegration.jboss5.ScopedVFSClassLoaderDomain)
>         at org.jboss.jms.server.endpoint.ServerConnectionEndpoint.createSessionDelegate(ServerConnectionEndpoint.java:229)
> {noformat} 
> Since the main thread is stalled, so too is start up.  This lock is always held by another making a similar call like so:
> {noformat} 
> "WorkManager(2)-1" daemon prio=10 tid=0x00007fe62dd96000 nid=0x363e in
> Object.wait() [0x00007fe68029a000]
>    java.lang.Thread.State: RUNNABLE
>         at org.jboss.jms.server.endpoint.ServerConnectionEndpoint.createSessionDelegate(ServerConnectionEndpoint.java:273)
>         - locked <0x00000000a5e43e50> (a org.jboss.aop.AspectManager)
>         at org.jboss.jms.server.endpoint.ServerConnectionEndpoint.createSessionDelegate(ServerConnectionEndpoint.java:229)
> {noformat} 
> The code there at line 273 is simple enough and shouldn't cause a long stall:
> {code:title=org.jboss.jms.server.endpoint.ServerConnectionEndpoint.java|borderStyle=solid}
>          synchronized (AspectManager.instance())
>          {
>             advised = new SessionAdvised(ep);     // line 273
>          }
> {code}
> Nonetheless, it does clearly hang at this line as WorkManager(2)-1 never progresses.  There's no GC/CPU issues or anything of that nature, but we get a slight in the thread dump as WorkManager(2)-1 is shown to be in Object.wait().  Checking the thread through pstack, we can see the issue.  It is waiting in native/JDK level operations required to initialize the SessionAdvised class:
> {noformat}
> Thread 2 (Thread 0x7fe68029d700 (LWP 13886)):
> #0  0x0000003b3e40b43c in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
> #1  0x00007fe6a12d447e in os:latformEvent:ark() () from /opt/app/jvm/jdk1.6.0_38/jre/lib/amd64/server/libjvm.so
> #2  0x00007fe6a12c54fa in ObjectMonitor::wait(long, bool, Thread*) () from /opt/app/jvm/jdk1.6.0_38/jre/lib/amd64/server/libjvm.so
> #3  0x00007fe6a13ab5f0 in ObjectSynchronizer::waitUninterruptibly(Handle, long, Thread*) () from /opt/app/jvm/jdk1.6.0_38/jre/lib/amd64/server/libjvm.so
> #4  0x00007fe6a107115b in instanceKlass::initialize_impl(instanceKlassHandle, Thread*) () from /opt/app/jvm/jdk1.6.0_38/jre/lib/amd64/server/libjvm.so
> #5  0x00007fe6a107077a in instanceKlass::initialize(Thread*) () from /opt/app/jvm/jdk1.6.0_38/jre/lib/amd64/server/libjvm.so
> #6  0x00007fe6a1097c5c in InterpreterRuntime::_new(JavaThread*, constantPoolOopDesc*, int) () from /opt/app/jvm/jdk1.6.0_38/jre/lib/amd64/server/libjvm.so
> {noformat}
> These calls are naturally synchronized internally in the JVM so only one thread can proceed through initialization of a class at a given time.  Checking for any threads in process of initializing SessionAdvised, we can see only the main thread is.  But the main thread is still blocked for the AspectManager lock.
> So we have a deadlock here.  The main thread holds the initialization lock while waiting for the AspectManager lock, while the WorkManager(2)-1 thread holds the AspectManager lock while waiting for the initialization lock.
> The initialization of SessionAdvised is wrapped in the synchronized block so the main thread should not have been able to proceed into the initialization at all without already possessing the AspectManager lock.  It locks the ScopedVFSClassLoaderDomain, which extends the AspectManager.  This is different from the actual AspectManager though that main tries to lock in the clinit call and that it deadlocks on.

--
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

From issues at jboss.org  Thu Mar 13 11:28:10 2014
From: issues at jboss.org (Yong Hao Gao (JIRA))
Date: Thu, 13 Mar 2014 11:28:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBMESSAGING-1941) Messaging deadlocks on
 AspectManager
In-Reply-To: <JIRA.12484258.1360189635000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12484258.1360189635000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12484258.1360189635000.14087.1394724490859@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBMESSAGING-1941?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Yong Hao Gao closed JBMESSAGING-1941.
-------------------------------------

    Resolution: Done


Note: Aaron not in the assignee list so I assigned to me. The fix has been done by Aaron.

                
> Messaging deadlocks on AspectManager
> ------------------------------------
>
>                 Key: JBMESSAGING-1941
>                 URL: https://issues.jboss.org/browse/JBMESSAGING-1941
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 1.4.8.SP9
>         Environment: -JBoss Enterprise Application Platform (EAP) 5
>            Reporter: Aaron Ogburn
>            Assignee: Yong Hao Gao
>             Fix For: 1.4.8.SP10
>
>         Attachments: 00779442testpatch.diff, JBMESSAGING-1941.diff
>
>
> Messaging can stall JBoss at start up.  The hang occurs as the main thread blocks in different locations in JMS trying to acquire the AspectManager instance lock:
> {noformat} 
> "main" prio=10 tid=0x00007fe69c1e1000 nid=0x3613 waiting for monitor entry [0x00007fe6828e5000]
>    java.lang.Thread.State: BLOCKED (on object monitor)
>         at org.jboss.aop.AspectManager.getAdvisor(AspectManager.java:728)
>         - waiting to lock <0x00000000a5e43e50> (a org.jboss.aop.AspectManager)
>         at org.jboss.jms.server.endpoint.advised.SessionAdvised.<clinit>(SessionAdvised.java)
>         at org.jboss.jms.server.endpoint.ServerConnectionEndpoint.createSessionDelegate(ServerConnectionEndpoint.java:273)
>         - locked <0x00000000a5600f48> (a org.jboss.aop.asintegration.jboss5.ScopedVFSClassLoaderDomain)
>         at org.jboss.jms.server.endpoint.ServerConnectionEndpoint.createSessionDelegate(ServerConnectionEndpoint.java:229)
> {noformat} 
> Since the main thread is stalled, so too is start up.  This lock is always held by another making a similar call like so:
> {noformat} 
> "WorkManager(2)-1" daemon prio=10 tid=0x00007fe62dd96000 nid=0x363e in
> Object.wait() [0x00007fe68029a000]
>    java.lang.Thread.State: RUNNABLE
>         at org.jboss.jms.server.endpoint.ServerConnectionEndpoint.createSessionDelegate(ServerConnectionEndpoint.java:273)
>         - locked <0x00000000a5e43e50> (a org.jboss.aop.AspectManager)
>         at org.jboss.jms.server.endpoint.ServerConnectionEndpoint.createSessionDelegate(ServerConnectionEndpoint.java:229)
> {noformat} 
> The code there at line 273 is simple enough and shouldn't cause a long stall:
> {code:title=org.jboss.jms.server.endpoint.ServerConnectionEndpoint.java|borderStyle=solid}
>          synchronized (AspectManager.instance())
>          {
>             advised = new SessionAdvised(ep);     // line 273
>          }
> {code}
> Nonetheless, it does clearly hang at this line as WorkManager(2)-1 never progresses.  There's no GC/CPU issues or anything of that nature, but we get a slight in the thread dump as WorkManager(2)-1 is shown to be in Object.wait().  Checking the thread through pstack, we can see the issue.  It is waiting in native/JDK level operations required to initialize the SessionAdvised class:
> {noformat}
> Thread 2 (Thread 0x7fe68029d700 (LWP 13886)):
> #0  0x0000003b3e40b43c in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
> #1  0x00007fe6a12d447e in os:latformEvent:ark() () from /opt/app/jvm/jdk1.6.0_38/jre/lib/amd64/server/libjvm.so
> #2  0x00007fe6a12c54fa in ObjectMonitor::wait(long, bool, Thread*) () from /opt/app/jvm/jdk1.6.0_38/jre/lib/amd64/server/libjvm.so
> #3  0x00007fe6a13ab5f0 in ObjectSynchronizer::waitUninterruptibly(Handle, long, Thread*) () from /opt/app/jvm/jdk1.6.0_38/jre/lib/amd64/server/libjvm.so
> #4  0x00007fe6a107115b in instanceKlass::initialize_impl(instanceKlassHandle, Thread*) () from /opt/app/jvm/jdk1.6.0_38/jre/lib/amd64/server/libjvm.so
> #5  0x00007fe6a107077a in instanceKlass::initialize(Thread*) () from /opt/app/jvm/jdk1.6.0_38/jre/lib/amd64/server/libjvm.so
> #6  0x00007fe6a1097c5c in InterpreterRuntime::_new(JavaThread*, constantPoolOopDesc*, int) () from /opt/app/jvm/jdk1.6.0_38/jre/lib/amd64/server/libjvm.so
> {noformat}
> These calls are naturally synchronized internally in the JVM so only one thread can proceed through initialization of a class at a given time.  Checking for any threads in process of initializing SessionAdvised, we can see only the main thread is.  But the main thread is still blocked for the AspectManager lock.
> So we have a deadlock here.  The main thread holds the initialization lock while waiting for the AspectManager lock, while the WorkManager(2)-1 thread holds the AspectManager lock while waiting for the initialization lock.
> The initialization of SessionAdvised is wrapped in the synchronized block so the main thread should not have been able to proceed into the initialization at all without already possessing the AspectManager lock.  It locks the ScopedVFSClassLoaderDomain, which extends the AspectManager.  This is different from the actual AspectManager though that main tries to lock in the clinit call and that it deadlocks on.

--
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

From issues at jboss.org  Thu Mar 13 13:28:11 2014
From: issues at jboss.org (Jean-Frederic Clere (JIRA))
Date: Thu, 13 Mar 2014 13:28:11 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBWEB-294) The same JSSE cipher-suite
 behaves differently with various JDKs
In-Reply-To: <JIRA.12534863.1394707274000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534863.1394707274000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534863.1394707274000.14491.1394731691027@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JBWEB-294?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12952783#comment-12952783 ] 

Jean-Frederic Clere commented on JBWEB-294:
-------------------------------------------

I will ignore the "JBWEB002081: No cipher match" until you check the cipher supported by the JVM.
For the javax.net.ssl.SSLHandshakeException you need to find which cipher causes it and look in the debug of the ssl to make sure what is wrong - guess the certificate doesn't correspond to the cipher you ask? -
                
> The same JSSE cipher-suite behaves differently with various JDKs
> ----------------------------------------------------------------
>
>                 Key: JBWEB-294
>                 URL: https://issues.jboss.org/browse/JBWEB-294
>             Project: JBoss Web
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: JBossWeb-7.4.0.GA
>            Reporter: Michal Babacek
>            Assignee: Remy Maucherat
>             Fix For: JBossWeb-7.4.0.GA
>
>
> Hi guys, I believe this is a bug, but correct me if it's just a feature unknown to me.
> I have the following settings:
> h3. Apache HTTP Server (mod_cluster load balancer)
> {code}
>   Listen 10.16.92.111:8847
>   LogLevel debug
>   <VirtualHost 10.16.92.111:8847>
>     ServerName 10.16.92.111:8847
>     <Directory />
>       Order deny,allow
>       Deny from all
>       Allow from all
>     </Directory>
>     KeepAliveTimeout 60
>     MaxKeepAliveRequests 0
>     ServerAdvertise on
>     AdvertiseFrequency 5
>     ManagerBalancerName qacluster
>     AdvertiseGroup 224.0.5.98:60220
>     EnableMCPMReceive
>     SSLEngine on
>     SSLCipherSuite AES128-SHA:ALL:!ADH:!LOW:!MD5:!SSLV2:!NULL
>     SSLCertificateFile /mnt/hudson_workspace/proper/server.crt
>     SSLCertificateKeyFile /mnt/hudson_workspace/proper/server.key
>     SSLCACertificateFile /mnt/hudson_workspace/proper/myca.crt
>     #SSLVerifyClient require
>     #SSLProxyVerify require
>     SSLProxyEngine On
>     SSLVerifyDepth 10
>     <Location /mcm>
>       SetHandler mod_cluster-manager
>       Order deny,allow
>       Deny from all
>       Allow from all
>     </Location>
>   </VirtualHost>
> {code}
> h3. JBossWeb subsystem
> {code}
> <subsystem xmlns="urn:jboss:domain:web:1.5" native="false">
> <connector name="https" protocol="HTTP/1.1" socket-binding="https"
>            scheme="https" enabled="true" secure="true">
> <ssl name="https" ca-certificate-file="/mnt/hudson_workspace/proper/ca-cert.jks"
>                   certificate-key-file="/mnt/hudson_workspace/proper/client-cert-key.jks"
>                   certificate-file="/mnt/hudson_workspace/proper/client-cert-key.jks"
>                   password="tomcat" verify-client="false" key-alias="javaclient"
>                   cipher-suite="TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384,!TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,!TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,!TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256,!TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256,TLS_DHE_RSA_WITH_AES_256_GCM_SHA384,!TLS_DHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA,TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384,TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384,TLS_ECDH_RSA_WITH_AES_256_CBC_SHA,TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA,TLS_DHE_RSA_WITH_AES_256_CBC_SHA256,TLS_DHE_RSA_WITH_AES_256_CBC_SHA,!TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256,!TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256,!TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,!TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA,!TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256,!TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256,!TLS_ECDH_RSA_WITH_AES_128_CBC_SHA,!TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA,!TLS_DHE_RSA_WITH_AES_128_CBC_SHA256,!TLS_DHE_RSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA,TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA,TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA,TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA,TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA,TLS_RSA_WITH_AES_256_GCM_SHA384,TLS_RSA_WITH_AES_256_CBC_SHA256,TLS_RSA_WITH_AES_256_CBC_SHA,!TLS_RSA_WITH_AES_128_GCM_SHA256,!TLS_RSA_WITH_AES_128_CBC_SHA256,!TLS_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_3DES_EDE_CBC_SHA" 
>                   protocol="TLS"/>
> </connector>
> <virtual-server name="default-host" enable-welcome-root="true">
> <alias name="localhost"/>
> <alias name="example.com"/>
> </virtual-server>
> </subsystem>
> {code}
> h3. mod_cluster subsystem
> {code}
> <subsystem xmlns="urn:jboss:domain:modcluster:1.2">
> <mod-cluster-config connector="https" advertise-socket="modcluster">
> <dynamic-load-provider>
> <load-metric type="busyness"/>
> </dynamic-load-provider>
> <ssl ca-certificate-file="/mnt/hudson_workspace/proper/ca-cert.jks"
>      certificate-key-file="/mnt/hudson_workspace/proper/client-cert-key.jks"
>      password="tomcat" key-alias="javaclient"
>      cipher-suite="TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384,!TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,!TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,!TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256,!TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256,TLS_DHE_RSA_WITH_AES_256_GCM_SHA384,!TLS_DHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA,TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384,TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384,TLS_ECDH_RSA_WITH_AES_256_CBC_SHA,TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA,TLS_DHE_RSA_WITH_AES_256_CBC_SHA256,TLS_DHE_RSA_WITH_AES_256_CBC_SHA,!TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256,!TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256,!TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,!TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA,!TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256,!TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256,!TLS_ECDH_RSA_WITH_AES_128_CBC_SHA,!TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA,!TLS_DHE_RSA_WITH_AES_128_CBC_SHA256,!TLS_DHE_RSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA,TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA,TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA,TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA,TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA,TLS_RSA_WITH_AES_256_GCM_SHA384,TLS_RSA_WITH_AES_256_CBC_SHA256,TLS_RSA_WITH_AES_256_CBC_SHA,!TLS_RSA_WITH_AES_128_GCM_SHA256,!TLS_RSA_WITH_AES_128_CBC_SHA256,!TLS_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_3DES_EDE_CBC_SHA"
>      protocol="TLS"/>
> </mod-cluster-config>
> </subsystem>
> {code}
> h3. Some properties
> {code}
> <system-properties>
> <property name="javax.net.ssl.trustStore" value="/mnt/hudson_workspace/proper/client-cert-key.jks"/>
> <property name="javax.net.ssl.trustStorePassword" value="tomcat"/>
> <property name="jboss.mod_cluster.jvmRoute" value="jboss-eap-6.3"/>
> <property name="jboss.node.name" value="jboss-eap-6.3"/>
> </system-properties>
> {code}
> The test runs several standalone-ha instances, client accesses the AS7 instances directly, then via mod_cluster load balancer. Some of the AS7 instances are being shut down, failover takes place. Client uses client certificate for authentication.
> The result of this test is as follows:
> ||JDK||Arch||Error||Test result||
> |Oracle JDK 1.6|RHEL6 x64|JBWEB002081: No cipher match|(x)|
> |Oracle JDK 1.7|RHEL6 x64|javax.net.ssl.SSLHandshakeException (i)|(x)|
> |Oracle JDK 1.8|RHEL6 x64|javax.net.ssl.SSLHandshakeException (i)|(x)|
> |IBM JDK 1.6|RHEL6 x64|JBWEB002081: No cipher match|(x)|
> |IBM JDK 1.7|RHEL6 x64|JBWEB002081: No cipher match|(x)|
> |OpenJDK 1.7|RHEL6 x64| |(/)|
> |OpenJDK 1.6|RHEL6 x64| |(/)|
> |HP JDK 1.7|HP-UX v11.3|JBWEB002081: No cipher match|(x)|
> h4. (i) javax.net.ssl.SSLHandshakeException
> The funny thing here is that the client can access the AS7 server directly, HTTPS connector is up and running just fine, certificates valid, no problem.
> Yet, the AS7 server fails to do handshake with the Apache HTTP Server instance.
> Please, note that in the aforementioned cipher-suite, some (those leveraging AES-128) methods are prefixed with *!*, so are some methods in the aforementioned Apache HTTP Server configuration.
> {noformat}
> [0m[31m12:58:35,574 ERROR [org.jboss.modcluster] (ContainerBackgroundProcessor[StandardEngine[jboss.web]]) MODCLUSTER000043: Failed to send INFO to 10.16.94.122/10.16.94.122:8847: javax.net.ssl.SSLHandshakeException: Received fatal alert: handshake_failure
>   at sun.security.ssl.Alerts.getSSLException(Alerts.java:192) [jsse.jar:1.7.0_45]
>   at sun.security.ssl.Alerts.getSSLException(Alerts.java:154) [jsse.jar:1.7.0_45]
>   at sun.security.ssl.SSLSocketImpl.recvAlert(SSLSocketImpl.java:1959) [jsse.jar:1.7.0_45]
>   at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:1077) [jsse.jar:1.7.0_45]
>   at sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1312) [jsse.jar:1.7.0_45]
>   at sun.security.ssl.SSLSocketImpl.writeRecord(SSLSocketImpl.java:702) [jsse.jar:1.7.0_45]
>   at sun.security.ssl.AppOutputStream.write(AppOutputStream.java:122) [jsse.jar:1.7.0_45]
>   at sun.nio.cs.StreamEncoder.writeBytes(StreamEncoder.java:221) [rt.jar:1.7.0_45]
>   at sun.nio.cs.StreamEncoder.implFlushBuffer(StreamEncoder.java:291) [rt.jar:1.7.0_45]
>   at sun.nio.cs.StreamEncoder.implFlush(StreamEncoder.java:295) [rt.jar:1.7.0_45]
>   at sun.nio.cs.StreamEncoder.flush(StreamEncoder.java:141) [rt.jar:1.7.0_45]
>   at java.io.OutputStreamWriter.flush(OutputStreamWriter.java:229) [rt.jar:1.7.0_45]
>   at java.io.BufferedWriter.flush(BufferedWriter.java:254) [rt.jar:1.7.0_45]
>   at org.jboss.modcluster.mcmp.impl.DefaultMCMPHandler.sendRequest(DefaultMCMPHandler.java:494)
>   at org.jboss.modcluster.mcmp.impl.DefaultMCMPHandler.sendRequest(DefaultMCMPHandler.java:583)
>   at org.jboss.modcluster.mcmp.impl.DefaultMCMPHandler.status(DefaultMCMPHandler.java:370)
>   at org.jboss.modcluster.mcmp.impl.DefaultMCMPHandler.status(DefaultMCMPHandler.java:350)
>   at org.jboss.modcluster.ModClusterService.status(ModClusterService.java:458)
>   at org.jboss.modcluster.container.catalina.CatalinaEventHandlerAdapter.lifecycleEvent(CatalinaEventHandlerAdapter.java:249)
>   at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:115) [jbossweb-7.4.0.Beta4.jar:7.4.0.Beta4]
>   at org.apache.catalina.core.ContainerBase.backgroundProcess(ContainerBase.java:1323) [jbossweb-7.4.0.Beta4.jar:7.4.0.Beta4]
>   at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1588) [jbossweb-7.4.0.Beta4.jar:7.4.0.Beta4]
>   at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.run(ContainerBase.java:1574) [jbossweb-7.4.0.Beta4.jar:7.4.0.Beta4]
>   at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_45]
> {noformat}
> h3. Question
> How come that some JDKs does not know these JSSE cipher-suite methods, some JDKs do, but fail to do handshake with Apache HTTP Server whereas OpenJDK simply passes with "all green"?
> What is actually a bug? Is it that OpenJDK should fail as well, because the configuration is wrong, or the other JDKs should pass?

--
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


From issues at jboss.org  Thu Mar 13 13:44:11 2014
From: issues at jboss.org (Bela Ban (JIRA))
Date: Thu, 13 Mar 2014 13:44:11 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1792) "No buffer space available"
 when sending on Mac OS
In-Reply-To: <JIRA.12532823.1392906372000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12532823.1392906372000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12532823.1392906372000.14565.1394732651019@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JGRP-1792?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban reopened JGRP-1792:
----------------------------



Occurred again
                
> "No buffer space available" when sending on Mac OS
> --------------------------------------------------
>
>                 Key: JGRP-1792
>                 URL: https://issues.jboss.org/browse/JGRP-1792
>             Project: JGroups
>          Issue Type: Bug
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>            Priority: Minor
>             Fix For: 3.5
>
>
> When sending multicast messages (with MPerf & fast.xml), the following message appears:
> {noformat}
> 8981 [ERROR] UDP: JGRP000029: A: failed sending message to cluster (1053 bytes): java.io.IOException: No buffer space available, 
> headers: MPerf: DATA999, NAKACK2: [MSG, seqno=1003], UDP: [cluster_name=mperf]
> {noformat}
> The messages *are* received, but the error message occurs on almost every message (1 sender thread sending 1000 messages).
> With {{UdpPerf}} (also shipped with JGroups), which also multicasts messages, the error doesn't happen.
> With {{UPerf}}, which uses unicasts, the error doesn't occur either.
> Todo: compare UdpPerf to MPerf (UDP protocol) to see what the diff is.

--
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

From issues at jboss.org  Thu Mar 13 13:48:10 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 13 Mar 2014 13:48:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2474) Security subsystem does not
 handle acl's module properly, and is missing transformer
In-Reply-To: <JIRA.12524602.1383913636000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12524602.1383913636000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12524602.1383913636000.14594.1394732890980@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2474?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12952793#comment-12952793 ] 

RH Bugzilla Integration commented on WFLY-2474:
-----------------------------------------------

Tomaz Cerar <tcerar at redhat.com> changed the Status of [bug 1029938|https://bugzilla.redhat.com/show_bug.cgi?id=1029938] from NEW to POST
                
> Security subsystem does not handle acl's module properly, and is missing transformer
> ------------------------------------------------------------------------------------
>
>                 Key: WFLY-2474
>                 URL: https://issues.jboss.org/browse/WFLY-2474
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Kabir Khan
>            Assignee: Kabir Khan
>             Fix For: 8.0.0.CR1
>
>
> The parsed add is done for /subsystem=security/security-domain=other/acl=classic/acl-module=acl
> However in the acl resource this is called login-module=acl.
> WHen marshalling
> {code}
> 	<acl>
> 	   <acl-module name="acl" code="AclThingy" flag="required" module="test">
>                 <module-option name="d" value="r"/>
> 	   </acl-module>
> 	</acl>
> {code}
> becomes
> {code}
> 	<acl>
> 	   <login-module name="acl" code="AclThingy" flag="required" module="test">
>                 <module-option name="d" value="r"/>
> 	   </login-module>
> 	</acl>
> {code}

--
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

From issues at jboss.org  Thu Mar 13 13:56:11 2014
From: issues at jboss.org (Ken H (JIRA))
Date: Thu, 13 Mar 2014 13:56:11 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2334) EL expansion broken in
	persistence.xml
In-Reply-To: <JIRA.12508186.1382101486000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508186.1382101486000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508186.1382101486000.14650.1394733371946@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2334?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ken H updated WFLY-2334:
------------------------

    Affects Version/s: 8.0.0.Final
                       JBoss AS7 7.2.0.Final
                           (was: 8.0.0.Beta1)

    
> EL expansion broken in persistence.xml
> --------------------------------------
>
>                 Key: WFLY-2334
>                 URL: https://issues.jboss.org/browse/WFLY-2334
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JPA / Hibernate
>    Affects Versions: JBoss AS7 7.2.0.Final, 8.0.0.Final
>         Environment: OSX, jdk 1.7.0_21
>            Reporter: Ken H
>
> When testing migration from Jboss AS 7.1.1, EL evaluation in persistence.xml no longer functions. I had been using this to change the jta-data-source name for specific environments using environment variables.
> {code}
> <jta-data-source>java:/myds/datasources/${datasource.name:myds}</jta-data-source>
> {code}

--
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

From issues at jboss.org  Thu Mar 13 13:56:13 2014
From: issues at jboss.org (Ken H (JIRA))
Date: Thu, 13 Mar 2014 13:56:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2334) EL expansion broken in
	persistence.xml
In-Reply-To: <JIRA.12508186.1382101486000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508186.1382101486000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508186.1382101486000.14673.1394733373194@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2334?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ken H updated WFLY-2334:
------------------------

    Description: 
When testing migration from Jboss AS 7.1.1 to 7.2.0.Final or WildFly 8.0.0.Final, EL evaluation in persistence.xml no longer functions. I had been using this to change the jta-data-source name for specific environments using environment variables.

{code}
<jta-data-source>java:/myds/datasources/${datasource.name:myds}</jta-data-source>
{code}

  was:
When testing migration from Jboss AS 7.1.1, EL evaluation in persistence.xml no longer functions. I had been using this to change the jta-data-source name for specific environments using environment variables.

{code}
<jta-data-source>java:/myds/datasources/${datasource.name:myds}</jta-data-source>
{code}


    
> EL expansion broken in persistence.xml
> --------------------------------------
>
>                 Key: WFLY-2334
>                 URL: https://issues.jboss.org/browse/WFLY-2334
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JPA / Hibernate
>    Affects Versions: JBoss AS7 7.2.0.Final, 8.0.0.Final
>         Environment: OSX, jdk 1.7.0_21
>            Reporter: Ken H
>
> When testing migration from Jboss AS 7.1.1 to 7.2.0.Final or WildFly 8.0.0.Final, EL evaluation in persistence.xml no longer functions. I had been using this to change the jta-data-source name for specific environments using environment variables.
> {code}
> <jta-data-source>java:/myds/datasources/${datasource.name:myds}</jta-data-source>
> {code}

--
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

From issues at jboss.org  Thu Mar 13 15:04:11 2014
From: issues at jboss.org (Maxime Falaize (JIRA))
Date: Thu, 13 Mar 2014 15:04:11 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-450) Cannot use decimal
 formatters for integers in an excel decision table
In-Reply-To: <JIRA.12534705.1394557254000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534705.1394557254000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534705.1394557254000.15054.1394737451352@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/DROOLS-450?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12952819#comment-12952819 ] 

Maxime Falaize commented on DROOLS-450:
---------------------------------------

I added a test case to my PR. You can test it with and without the patch.
                
> Cannot use decimal formatters for integers in an excel decision table
> ---------------------------------------------------------------------
>
>                 Key: DROOLS-450
>                 URL: https://issues.jboss.org/browse/DROOLS-450
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 6.0.1.Final
>            Reporter: Maxime Falaize
>            Assignee: Mark Proctor
>            Priority: Minor
>         Attachments: issue_example.png
>
>
> When I use decimal formatter in an excel action column for numbers that are in fact integers, I am getting this exception :
> {noformat}
> Exception in thread "main" java.lang.RuntimeException: Error while creating KieBase[Message [id=1, level=ERROR, path=com/sample/my_decision_table.xls, line=5, column=0
>    text=Rule Compilation error The method setParameter(double) in the type MyObject is not applicable for the arguments (int, int)]]
> 	at org.drools.compiler.kie.builder.impl.KieContainerImpl.getKieBase(KieContainerImpl.java:260)
> 	at org.drools.compiler.kie.builder.impl.KieContainerImpl.newKieSession(KieContainerImpl.java:400)
> 	at org.drools.compiler.kie.builder.impl.KieContainerImpl.newKieSession(KieContainerImpl.java:375)
> {noformat}
> Actually, the system uses the format number "1,00000" (with comma in french) instead of "1.00000" like it should use.
> This is causing by the line 174 in org.drools.decisiontable.parser.xls.ExcelParser :
> {code:java}
> if ( num - Math.round( num ) != 0 )
> {code}
> I don't understand why we use the formatted value when this test is not passed.
> I think the end users should have the possibility to keep the same formatter for the same column, with integers or not.

--
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

From issues at jboss.org  Thu Mar 13 15:18:10 2014
From: issues at jboss.org (=?UTF-8?Q?J=C3=B6rg_Br=C3=BCck_=28JIRA=29?=)
Date: Thu, 13 Mar 2014 15:18:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3111) Accessing attribute message
 from class LogingEvent always returns class String
In-Reply-To: <JIRA.12534947.1394738225337@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534947.1394738225337@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534947.1394738225337.15075.1394738290708@jira02.app.mwc.hst.phx2.redhat.com>

J?rg Br?ck created WFLY-3111:
--------------------------------

             Summary: Accessing attribute message from class LogingEvent always returns class String
                 Key: WFLY-3111
                 URL: https://issues.jboss.org/browse/WFLY-3111
             Project: WildFly
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Logging
    Affects Versions: 8.0.0.Final
         Environment: Windows 7, JDK 1.7.0_51
            Reporter: J?rg Br?ck
            Assignee: James Perkins
            Priority: Minor


After Changing from JBoss 5.1.0 to Wildfly the behaviour of my own written Log4j appenders
have changed while accessing LoggingEvent in the function "append" of
class ApppenderSkeleton.

The reason of this behaviour is the implementation of org.apache.log4j.spi.LoggingEvent

 public LoggingEvent(String fqnOfCategoryClass, Category logger, long timeStamp, Priority level, Object message, Throwable throwable) {
        this.fqnOfCategoryClass = fqnOfCategoryClass;
        this.logger = logger;
        this.level = level;
        logRecord = new ExtLogRecord(JBossLevelMapping.getLevelFor(level), message == null ? null : message.toString(), ExtLogRecord.FormatStyle.NO_FORMAT, fqnOfCategoryClass);

The Object message is converted to string and saved in Class ExtLogRecord.

Here the implementation of getMessage:

 public Object getMessage() {
        return logRecord.getMessage();
    }

Here the implementation of getMessage of ExtLogRecord 

public String getMessage() {
        return message;
    }

Because of this String is always returned.

If I understand this code right you can transfer every object to log4j, but you can not access this objects
in an appender because of the LoggingEvent constructor where method toString is called.

What is the reason of this change in contrast to jboss 5.1.0?
Of course I can reconstruct my objects from the string if I overwrite the toString method.


--
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


From issues at jboss.org  Thu Mar 13 15:18:10 2014
From: issues at jboss.org (=?UTF-8?Q?J=C3=B6rg_Br=C3=BCck_=28JIRA=29?=)
Date: Thu, 13 Mar 2014 15:18:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3111) Accessing attribute message
 from class LogigngEvent always returns class String
In-Reply-To: <JIRA.12534947.1394738225000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534947.1394738225000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534947.1394738225000.15077.1394738290838@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-3111?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

J?rg Br?ck updated WFLY-3111:
-----------------------------

    Summary: Accessing attribute message from class LogigngEvent always returns class String  (was: Accessing attribute message from class LogingEvent always returns class String)

    
> Accessing attribute message from class LogigngEvent always returns class String
> -------------------------------------------------------------------------------
>
>                 Key: WFLY-3111
>                 URL: https://issues.jboss.org/browse/WFLY-3111
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Logging
>    Affects Versions: 8.0.0.Final
>         Environment: Windows 7, JDK 1.7.0_51
>            Reporter: J?rg Br?ck
>            Assignee: James Perkins
>            Priority: Minor
>
> After Changing from JBoss 5.1.0 to Wildfly the behaviour of my own written Log4j appenders
> have changed while accessing LoggingEvent in the function "append" of
> class ApppenderSkeleton.
> The reason of this behaviour is the implementation of org.apache.log4j.spi.LoggingEvent
>  public LoggingEvent(String fqnOfCategoryClass, Category logger, long timeStamp, Priority level, Object message, Throwable throwable) {
>         this.fqnOfCategoryClass = fqnOfCategoryClass;
>         this.logger = logger;
>         this.level = level;
>         logRecord = new ExtLogRecord(JBossLevelMapping.getLevelFor(level), message == null ? null : message.toString(), ExtLogRecord.FormatStyle.NO_FORMAT, fqnOfCategoryClass);
> The Object message is converted to string and saved in Class ExtLogRecord.
> Here the implementation of getMessage:
>  public Object getMessage() {
>         return logRecord.getMessage();
>     }
> Here the implementation of getMessage of ExtLogRecord 
> public String getMessage() {
>         return message;
>     }
> Because of this String is always returned.
> If I understand this code right you can transfer every object to log4j, but you can not access this objects
> in an appender because of the LoggingEvent constructor where method toString is called.
> What is the reason of this change in contrast to jboss 5.1.0?
> Of course I can reconstruct my objects from the string if I overwrite the toString method.

--
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


From issues at jboss.org  Thu Mar 13 15:20:10 2014
From: issues at jboss.org (=?UTF-8?Q?J=C3=B6rg_Br=C3=BCck_=28JIRA=29?=)
Date: Thu, 13 Mar 2014 15:20:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3111) Accessing attribute message
 from class LoggingEvent always returns class String
In-Reply-To: <JIRA.12534947.1394738225000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534947.1394738225000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534947.1394738225000.15080.1394738410556@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-3111?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

J?rg Br?ck updated WFLY-3111:
-----------------------------

    Summary: Accessing attribute message from class LoggingEvent always returns class String  (was: Accessing attribute message from class LogigngEvent always returns class String)

    
> Accessing attribute message from class LoggingEvent always returns class String
> -------------------------------------------------------------------------------
>
>                 Key: WFLY-3111
>                 URL: https://issues.jboss.org/browse/WFLY-3111
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Logging
>    Affects Versions: 8.0.0.Final
>         Environment: Windows 7, JDK 1.7.0_51
>            Reporter: J?rg Br?ck
>            Assignee: James Perkins
>            Priority: Minor
>
> After Changing from JBoss 5.1.0 to Wildfly the behaviour of my own written Log4j appenders
> have changed while accessing LoggingEvent in the function "append" of
> class ApppenderSkeleton.
> The reason of this behaviour is the implementation of org.apache.log4j.spi.LoggingEvent
>  public LoggingEvent(String fqnOfCategoryClass, Category logger, long timeStamp, Priority level, Object message, Throwable throwable) {
>         this.fqnOfCategoryClass = fqnOfCategoryClass;
>         this.logger = logger;
>         this.level = level;
>         logRecord = new ExtLogRecord(JBossLevelMapping.getLevelFor(level), message == null ? null : message.toString(), ExtLogRecord.FormatStyle.NO_FORMAT, fqnOfCategoryClass);
> The Object message is converted to string and saved in Class ExtLogRecord.
> Here the implementation of getMessage:
>  public Object getMessage() {
>         return logRecord.getMessage();
>     }
> Here the implementation of getMessage of ExtLogRecord 
> public String getMessage() {
>         return message;
>     }
> Because of this String is always returned.
> If I understand this code right you can transfer every object to log4j, but you can not access this objects
> in an appender because of the LoggingEvent constructor where method toString is called.
> What is the reason of this change in contrast to jboss 5.1.0?
> Of course I can reconstruct my objects from the string if I overwrite the toString method.

--
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


From issues at jboss.org  Thu Mar 13 16:24:10 2014
From: issues at jboss.org (James Perkins (JIRA))
Date: Thu, 13 Mar 2014 16:24:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3111) Accessing attribute message
 from class LoggingEvent always returns class String
In-Reply-To: <JIRA.12534947.1394738225000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534947.1394738225000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534947.1394738225000.15191.1394742250973@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-3111?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12952826#comment-12952826 ] 

James Perkins commented on WFLY-3111:
-------------------------------------

The only way this will work currently is if you include your own version of log4j. I'm assuming of course you're including a log4j configuration file in your deployment. If you're attempting to use an appender as a custom-handler I don't think it will be possible to work. Have a look at https://docs.jboss.org/author/display/WFLY8/How+To#HowTo-HowdoIuselog4j.propertiesorlog4j.xmlinsteadofusingtheloggingsubsystemconfiguration%3F to see how to include your own version of log4j.
                
> Accessing attribute message from class LoggingEvent always returns class String
> -------------------------------------------------------------------------------
>
>                 Key: WFLY-3111
>                 URL: https://issues.jboss.org/browse/WFLY-3111
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Logging
>    Affects Versions: 8.0.0.Final
>         Environment: Windows 7, JDK 1.7.0_51
>            Reporter: J?rg Br?ck
>            Assignee: James Perkins
>            Priority: Minor
>
> After Changing from JBoss 5.1.0 to Wildfly the behaviour of my own written Log4j appenders
> have changed while accessing LoggingEvent in the function "append" of
> class ApppenderSkeleton.
> The reason of this behaviour is the implementation of org.apache.log4j.spi.LoggingEvent
>  public LoggingEvent(String fqnOfCategoryClass, Category logger, long timeStamp, Priority level, Object message, Throwable throwable) {
>         this.fqnOfCategoryClass = fqnOfCategoryClass;
>         this.logger = logger;
>         this.level = level;
>         logRecord = new ExtLogRecord(JBossLevelMapping.getLevelFor(level), message == null ? null : message.toString(), ExtLogRecord.FormatStyle.NO_FORMAT, fqnOfCategoryClass);
> The Object message is converted to string and saved in Class ExtLogRecord.
> Here the implementation of getMessage:
>  public Object getMessage() {
>         return logRecord.getMessage();
>     }
> Here the implementation of getMessage of ExtLogRecord 
> public String getMessage() {
>         return message;
>     }
> Because of this String is always returned.
> If I understand this code right you can transfer every object to log4j, but you can not access this objects
> in an appender because of the LoggingEvent constructor where method toString is called.
> What is the reason of this change in contrast to jboss 5.1.0?
> Of course I can reconstruct my objects from the string if I overwrite the toString method.

--
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


From issues at jboss.org  Thu Mar 13 16:32:13 2014
From: issues at jboss.org (Radoslav Husar (JIRA))
Date: Thu, 13 Mar 2014 16:32:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3112) One can't change history and
 decay with DynamicLoadBalanceFactorProvider
In-Reply-To: <JIRA.12534709.1394560666000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534709.1394560666000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534709.1394560666000.15268.1394742733640@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-3112?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Radoslav Husar moved MODCLUSTER-393 to WFLY-3112:
-------------------------------------------------

              Project: WildFly  (was: mod_cluster)
                  Key: WFLY-3112  (was: MODCLUSTER-393)
    Affects Version/s: 8.0.0.Final
                           (was: 1.2.6.Final)
             Security: Public

    
> One can't change history and decay with DynamicLoadBalanceFactorProvider
> ------------------------------------------------------------------------
>
>                 Key: WFLY-3112
>                 URL: https://issues.jboss.org/browse/WFLY-3112
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 8.0.0.Final
>            Reporter: Michal Babacek
>            Assignee: Radoslav Husar
>            Priority: Critical
>         Attachments: redacted_log
>
>
> I'm under an ugly impression that one can't actually change {{history}} and {{decay}} attributes of *DynamicLoadBalanceFactorProvider*.
> I was trying to figure out why the new test suite of CustomLoadMetric tests does not pass. In order to get load figures without history and decay manipulation, I set the following:
> {code}
> <subsystem xmlns="urn:jboss:domain:modcluster:1.2">
>     <mod-cluster-config advertise-socket="modcluster" connector="ajp">
>     <dynamic-load-provider history="0">
>         <custom-load-metric class="biz.karms.modcluster.CustomLoadMetric" weight="1">
>             <property name="capacity" value="1000"/>
>             <property name="loadfile" value="/tmp/mod_cluster-eapx/loadfileA"/>
>             <property name="parseexpression" value="^LOAD: ([0-9]*)$"/>
>         </custom-load-metric>
>     </dynamic-load-provider>
>     </mod-cluster-config>
> </subsystem>
> {code}
> The aforementioned {{history=0}} effectively means that there is just 1 "slot" for a one historical value on which decay function should work.
> If you take a look at the code in [DynamicLoadBalanceFactorProvider|https://github.com/modcluster/mod_cluster/blob/master/core/src/main/java/org/jboss/modcluster/load/impl/DynamicLoadBalanceFactorProvider.java#L54] constructor, it is apparent
> that the size of the List that later serves for storing the historical values is set sooner than the actual [setHistory(int history)|https://github.com/modcluster/mod_cluster/blob/master/core/src/main/java/org/jboss/modcluster/load/impl/DynamicLoadBalanceFactorProvider.java#L177] method is called.
> The actual size of that List collection wouldn't do any harm by itself but it is being used in the aforementioned class with {{.size()}} to control cycles.
> The same IMHO holds for the decay attribute.
> Anyhow, I put some additional logging to the [DynamicLoadBalanceFactorProvider.java|https://github.com/modcluster/mod_cluster/blob/master/core/src/main/java/org/jboss/modcluster/load/impl/DynamicLoadBalanceFactorProvider.java]:
> {code}
> // Historical value contribute an exponentially decayed factor
> for (int i = 0; i < queue.size(); ++i) {
>     double decay = 1 / Math.pow(decayFactor, i);
>     totalDecay += decay;
>     this.log.info("KTAG: totalLoad:"+totalLoad+", with decay:"+(totalLoad+queue.get(i).doubleValue() * decay));
>     totalLoad += queue.get(i).doubleValue() * decay;
> }
> {code}
> and
> {code}
> try {
>     // Normalize load with respect to capacity
>     this.recordLoad(metricLoadHistory, metric.getLoad(engine) / metric.getCapacity());
>     this.log.info("KTAG metricLoadHistory:"+metricLoadHistory.toString());
>     totalWeight += weight;
>     totalWeightedLoad += this.average(metricLoadHistory) * weight;
> } catch (Exception e) {
>     this.log.error(e.getLocalizedMessage(), e);
> }
> {code}
> with the following being the output: [^redacted_log].
> So, despite having {{history=0}}, which should force the system to keep just 1, the current value, {{metricLoadHistory}} grew from
> {noformat}
> KTAG metricLoadHistory:[0.8]
> {noformat}
> to
> {noformat}
> KTAG metricLoadHistory:[0.9, 0.9, 0.9, 0.9, 0.9, 0.9, 0.9, 0.9, 0.9, 0.8]
> {noformat}
> which is exactly [9|https://github.com/modcluster/mod_cluster/blob/master/core/src/main/java/org/jboss/modcluster/load/impl/DynamicLoadBalanceFactorProvider.java#L50] + [1|https://github.com/modcluster/mod_cluster/blob/master/core/src/main/java/org/jboss/modcluster/load/impl/DynamicLoadBalanceFactorProvider.java#L54] in size :-)
> WDYT?

--
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

From issues at jboss.org  Thu Mar 13 16:34:11 2014
From: issues at jboss.org (Radoslav Husar (JIRA))
Date: Thu, 13 Mar 2014 16:34:11 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3112) One can't change history and
 decay with DynamicLoadBalanceFactorProvider
In-Reply-To: <JIRA.12534709.1394560666000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534709.1394560666000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534709.1394560666000.15289.1394742851139@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-3112?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Radoslav Husar updated WFLY-3112:
---------------------------------

    Fix Version/s: 8.0.1.Final
      Description: 


I'm under an ugly impression that one can't actually change {{history}} and {{decay}} attributes of *DynamicLoadBalanceFactorProvider*.

I was trying to figure out why the new test suite of CustomLoadMetric tests does not pass. In order to get load figures without history and decay manipulation, I set the following:

{code}
<subsystem xmlns="urn:jboss:domain:modcluster:1.2">
    <mod-cluster-config advertise-socket="modcluster" connector="ajp">
    <dynamic-load-provider history="0">
        <custom-load-metric class="biz.karms.modcluster.CustomLoadMetric" weight="1">
            <property name="capacity" value="1000"/>
            <property name="loadfile" value="/tmp/mod_cluster-eapx/loadfileA"/>
            <property name="parseexpression" value="^LOAD: ([0-9]*)$"/>
        </custom-load-metric>
    </dynamic-load-provider>
    </mod-cluster-config>
</subsystem>
{code}

The aforementioned {{history=0}} effectively means that there is just 1 "slot" for a one historical value on which decay function should work.

If you take a look at the code in [DynamicLoadBalanceFactorProvider|https://github.com/modcluster/mod_cluster/blob/master/core/src/main/java/org/jboss/modcluster/load/impl/DynamicLoadBalanceFactorProvider.java#L54] constructor, it is apparent
that the size of the List that later serves for storing the historical values is set sooner than the actual [setHistory(int history)|https://github.com/modcluster/mod_cluster/blob/master/core/src/main/java/org/jboss/modcluster/load/impl/DynamicLoadBalanceFactorProvider.java#L177] method is called.
The actual size of that List collection wouldn't do any harm by itself but it is being used in the aforementioned class with {{.size()}} to control cycles.
The same IMHO holds for the decay attribute.

Anyhow, I put some additional logging to the [DynamicLoadBalanceFactorProvider.java|https://github.com/modcluster/mod_cluster/blob/master/core/src/main/java/org/jboss/modcluster/load/impl/DynamicLoadBalanceFactorProvider.java]:

{code}
// Historical value contribute an exponentially decayed factor
for (int i = 0; i < queue.size(); ++i) {
    double decay = 1 / Math.pow(decayFactor, i);
    totalDecay += decay;
    this.log.info("KTAG: totalLoad:"+totalLoad+", with decay:"+(totalLoad+queue.get(i).doubleValue() * decay));
    totalLoad += queue.get(i).doubleValue() * decay;
}
{code}

and

{code}
try {
    // Normalize load with respect to capacity
    this.recordLoad(metricLoadHistory, metric.getLoad(engine) / metric.getCapacity());
    this.log.info("KTAG metricLoadHistory:"+metricLoadHistory.toString());
    totalWeight += weight;
    totalWeightedLoad += this.average(metricLoadHistory) * weight;
} catch (Exception e) {
    this.log.error(e.getLocalizedMessage(), e);
}
{code}

with the following being the output: [^redacted_log].

So, despite having {{history=0}}, which should force the system to keep just 1, the current value, {{metricLoadHistory}} grew from
{noformat}
KTAG metricLoadHistory:[0.8]
{noformat}
to
{noformat}
KTAG metricLoadHistory:[0.9, 0.9, 0.9, 0.9, 0.9, 0.9, 0.9, 0.9, 0.9, 0.8]
{noformat}
which is exactly [9|https://github.com/modcluster/mod_cluster/blob/master/core/src/main/java/org/jboss/modcluster/load/impl/DynamicLoadBalanceFactorProvider.java#L50] + [1|https://github.com/modcluster/mod_cluster/blob/master/core/src/main/java/org/jboss/modcluster/load/impl/DynamicLoadBalanceFactorProvider.java#L54] in size :-)

WDYT?


  was:



I'm under an ugly impression that one can't actually change {{history}} and {{decay}} attributes of *DynamicLoadBalanceFactorProvider*.

I was trying to figure out why the new test suite of CustomLoadMetric tests does not pass. In order to get load figures without history and decay manipulation, I set the following:

{code}
<subsystem xmlns="urn:jboss:domain:modcluster:1.2">
    <mod-cluster-config advertise-socket="modcluster" connector="ajp">
    <dynamic-load-provider history="0">
        <custom-load-metric class="biz.karms.modcluster.CustomLoadMetric" weight="1">
            <property name="capacity" value="1000"/>
            <property name="loadfile" value="/tmp/mod_cluster-eapx/loadfileA"/>
            <property name="parseexpression" value="^LOAD: ([0-9]*)$"/>
        </custom-load-metric>
    </dynamic-load-provider>
    </mod-cluster-config>
</subsystem>
{code}

The aforementioned {{history=0}} effectively means that there is just 1 "slot" for a one historical value on which decay function should work.

If you take a look at the code in [DynamicLoadBalanceFactorProvider|https://github.com/modcluster/mod_cluster/blob/master/core/src/main/java/org/jboss/modcluster/load/impl/DynamicLoadBalanceFactorProvider.java#L54] constructor, it is apparent
that the size of the List that later serves for storing the historical values is set sooner than the actual [setHistory(int history)|https://github.com/modcluster/mod_cluster/blob/master/core/src/main/java/org/jboss/modcluster/load/impl/DynamicLoadBalanceFactorProvider.java#L177] method is called.
The actual size of that List collection wouldn't do any harm by itself but it is being used in the aforementioned class with {{.size()}} to control cycles.
The same IMHO holds for the decay attribute.

Anyhow, I put some additional logging to the [DynamicLoadBalanceFactorProvider.java|https://github.com/modcluster/mod_cluster/blob/master/core/src/main/java/org/jboss/modcluster/load/impl/DynamicLoadBalanceFactorProvider.java]:

{code}
// Historical value contribute an exponentially decayed factor
for (int i = 0; i < queue.size(); ++i) {
    double decay = 1 / Math.pow(decayFactor, i);
    totalDecay += decay;
    this.log.info("KTAG: totalLoad:"+totalLoad+", with decay:"+(totalLoad+queue.get(i).doubleValue() * decay));
    totalLoad += queue.get(i).doubleValue() * decay;
}
{code}

and

{code}
try {
    // Normalize load with respect to capacity
    this.recordLoad(metricLoadHistory, metric.getLoad(engine) / metric.getCapacity());
    this.log.info("KTAG metricLoadHistory:"+metricLoadHistory.toString());
    totalWeight += weight;
    totalWeightedLoad += this.average(metricLoadHistory) * weight;
} catch (Exception e) {
    this.log.error(e.getLocalizedMessage(), e);
}
{code}

with the following being the output: [^redacted_log].

So, despite having {{history=0}}, which should force the system to keep just 1, the current value, {{metricLoadHistory}} grew from
{noformat}
KTAG metricLoadHistory:[0.8]
{noformat}
to
{noformat}
KTAG metricLoadHistory:[0.9, 0.9, 0.9, 0.9, 0.9, 0.9, 0.9, 0.9, 0.9, 0.8]
{noformat}
which is exactly [9|https://github.com/modcluster/mod_cluster/blob/master/core/src/main/java/org/jboss/modcluster/load/impl/DynamicLoadBalanceFactorProvider.java#L50] + [1|https://github.com/modcluster/mod_cluster/blob/master/core/src/main/java/org/jboss/modcluster/load/impl/DynamicLoadBalanceFactorProvider.java#L54] in size :-)

WDYT?


      Component/s: Clustering


This is a WildFly bug, moved accordingly.

I have a fix ready in a branch.
                
> One can't change history and decay with DynamicLoadBalanceFactorProvider
> ------------------------------------------------------------------------
>
>                 Key: WFLY-3112
>                 URL: https://issues.jboss.org/browse/WFLY-3112
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Clustering
>    Affects Versions: 8.0.0.Final
>            Reporter: Michal Babacek
>            Assignee: Radoslav Husar
>            Priority: Critical
>             Fix For: 8.0.1.Final
>
>         Attachments: redacted_log
>
>
> I'm under an ugly impression that one can't actually change {{history}} and {{decay}} attributes of *DynamicLoadBalanceFactorProvider*.
> I was trying to figure out why the new test suite of CustomLoadMetric tests does not pass. In order to get load figures without history and decay manipulation, I set the following:
> {code}
> <subsystem xmlns="urn:jboss:domain:modcluster:1.2">
>     <mod-cluster-config advertise-socket="modcluster" connector="ajp">
>     <dynamic-load-provider history="0">
>         <custom-load-metric class="biz.karms.modcluster.CustomLoadMetric" weight="1">
>             <property name="capacity" value="1000"/>
>             <property name="loadfile" value="/tmp/mod_cluster-eapx/loadfileA"/>
>             <property name="parseexpression" value="^LOAD: ([0-9]*)$"/>
>         </custom-load-metric>
>     </dynamic-load-provider>
>     </mod-cluster-config>
> </subsystem>
> {code}
> The aforementioned {{history=0}} effectively means that there is just 1 "slot" for a one historical value on which decay function should work.
> If you take a look at the code in [DynamicLoadBalanceFactorProvider|https://github.com/modcluster/mod_cluster/blob/master/core/src/main/java/org/jboss/modcluster/load/impl/DynamicLoadBalanceFactorProvider.java#L54] constructor, it is apparent
> that the size of the List that later serves for storing the historical values is set sooner than the actual [setHistory(int history)|https://github.com/modcluster/mod_cluster/blob/master/core/src/main/java/org/jboss/modcluster/load/impl/DynamicLoadBalanceFactorProvider.java#L177] method is called.
> The actual size of that List collection wouldn't do any harm by itself but it is being used in the aforementioned class with {{.size()}} to control cycles.
> The same IMHO holds for the decay attribute.
> Anyhow, I put some additional logging to the [DynamicLoadBalanceFactorProvider.java|https://github.com/modcluster/mod_cluster/blob/master/core/src/main/java/org/jboss/modcluster/load/impl/DynamicLoadBalanceFactorProvider.java]:
> {code}
> // Historical value contribute an exponentially decayed factor
> for (int i = 0; i < queue.size(); ++i) {
>     double decay = 1 / Math.pow(decayFactor, i);
>     totalDecay += decay;
>     this.log.info("KTAG: totalLoad:"+totalLoad+", with decay:"+(totalLoad+queue.get(i).doubleValue() * decay));
>     totalLoad += queue.get(i).doubleValue() * decay;
> }
> {code}
> and
> {code}
> try {
>     // Normalize load with respect to capacity
>     this.recordLoad(metricLoadHistory, metric.getLoad(engine) / metric.getCapacity());
>     this.log.info("KTAG metricLoadHistory:"+metricLoadHistory.toString());
>     totalWeight += weight;
>     totalWeightedLoad += this.average(metricLoadHistory) * weight;
> } catch (Exception e) {
>     this.log.error(e.getLocalizedMessage(), e);
> }
> {code}
> with the following being the output: [^redacted_log].
> So, despite having {{history=0}}, which should force the system to keep just 1, the current value, {{metricLoadHistory}} grew from
> {noformat}
> KTAG metricLoadHistory:[0.8]
> {noformat}
> to
> {noformat}
> KTAG metricLoadHistory:[0.9, 0.9, 0.9, 0.9, 0.9, 0.9, 0.9, 0.9, 0.9, 0.8]
> {noformat}
> which is exactly [9|https://github.com/modcluster/mod_cluster/blob/master/core/src/main/java/org/jboss/modcluster/load/impl/DynamicLoadBalanceFactorProvider.java#L50] + [1|https://github.com/modcluster/mod_cluster/blob/master/core/src/main/java/org/jboss/modcluster/load/impl/DynamicLoadBalanceFactorProvider.java#L54] in size :-)
> WDYT?

--
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

From issues at jboss.org  Thu Mar 13 16:34:11 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 13 Mar 2014 16:34:11 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3112) One can't change history and
 decay with DynamicLoadBalanceFactorProvider
In-Reply-To: <JIRA.12534709.1394560666000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534709.1394560666000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534709.1394560666000.15303.1394742851950@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-3112?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12952831#comment-12952831 ] 

RH Bugzilla Integration commented on WFLY-3112:
-----------------------------------------------

Radoslav Husar <rhusar at redhat.com> changed the Status of [bug 1075215|https://bugzilla.redhat.com/show_bug.cgi?id=1075215] from NEW to ASSIGNED
                
> One can't change history and decay with DynamicLoadBalanceFactorProvider
> ------------------------------------------------------------------------
>
>                 Key: WFLY-3112
>                 URL: https://issues.jboss.org/browse/WFLY-3112
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Clustering
>    Affects Versions: 8.0.0.Final
>            Reporter: Michal Babacek
>            Assignee: Radoslav Husar
>            Priority: Critical
>             Fix For: 8.0.1.Final
>
>         Attachments: redacted_log
>
>
> I'm under an ugly impression that one can't actually change {{history}} and {{decay}} attributes of *DynamicLoadBalanceFactorProvider*.
> I was trying to figure out why the new test suite of CustomLoadMetric tests does not pass. In order to get load figures without history and decay manipulation, I set the following:
> {code}
> <subsystem xmlns="urn:jboss:domain:modcluster:1.2">
>     <mod-cluster-config advertise-socket="modcluster" connector="ajp">
>     <dynamic-load-provider history="0">
>         <custom-load-metric class="biz.karms.modcluster.CustomLoadMetric" weight="1">
>             <property name="capacity" value="1000"/>
>             <property name="loadfile" value="/tmp/mod_cluster-eapx/loadfileA"/>
>             <property name="parseexpression" value="^LOAD: ([0-9]*)$"/>
>         </custom-load-metric>
>     </dynamic-load-provider>
>     </mod-cluster-config>
> </subsystem>
> {code}
> The aforementioned {{history=0}} effectively means that there is just 1 "slot" for a one historical value on which decay function should work.
> If you take a look at the code in [DynamicLoadBalanceFactorProvider|https://github.com/modcluster/mod_cluster/blob/master/core/src/main/java/org/jboss/modcluster/load/impl/DynamicLoadBalanceFactorProvider.java#L54] constructor, it is apparent
> that the size of the List that later serves for storing the historical values is set sooner than the actual [setHistory(int history)|https://github.com/modcluster/mod_cluster/blob/master/core/src/main/java/org/jboss/modcluster/load/impl/DynamicLoadBalanceFactorProvider.java#L177] method is called.
> The actual size of that List collection wouldn't do any harm by itself but it is being used in the aforementioned class with {{.size()}} to control cycles.
> The same IMHO holds for the decay attribute.
> Anyhow, I put some additional logging to the [DynamicLoadBalanceFactorProvider.java|https://github.com/modcluster/mod_cluster/blob/master/core/src/main/java/org/jboss/modcluster/load/impl/DynamicLoadBalanceFactorProvider.java]:
> {code}
> // Historical value contribute an exponentially decayed factor
> for (int i = 0; i < queue.size(); ++i) {
>     double decay = 1 / Math.pow(decayFactor, i);
>     totalDecay += decay;
>     this.log.info("KTAG: totalLoad:"+totalLoad+", with decay:"+(totalLoad+queue.get(i).doubleValue() * decay));
>     totalLoad += queue.get(i).doubleValue() * decay;
> }
> {code}
> and
> {code}
> try {
>     // Normalize load with respect to capacity
>     this.recordLoad(metricLoadHistory, metric.getLoad(engine) / metric.getCapacity());
>     this.log.info("KTAG metricLoadHistory:"+metricLoadHistory.toString());
>     totalWeight += weight;
>     totalWeightedLoad += this.average(metricLoadHistory) * weight;
> } catch (Exception e) {
>     this.log.error(e.getLocalizedMessage(), e);
> }
> {code}
> with the following being the output: [^redacted_log].
> So, despite having {{history=0}}, which should force the system to keep just 1, the current value, {{metricLoadHistory}} grew from
> {noformat}
> KTAG metricLoadHistory:[0.8]
> {noformat}
> to
> {noformat}
> KTAG metricLoadHistory:[0.9, 0.9, 0.9, 0.9, 0.9, 0.9, 0.9, 0.9, 0.9, 0.8]
> {noformat}
> which is exactly [9|https://github.com/modcluster/mod_cluster/blob/master/core/src/main/java/org/jboss/modcluster/load/impl/DynamicLoadBalanceFactorProvider.java#L50] + [1|https://github.com/modcluster/mod_cluster/blob/master/core/src/main/java/org/jboss/modcluster/load/impl/DynamicLoadBalanceFactorProvider.java#L54] in size :-)
> WDYT?

--
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

From issues at jboss.org  Thu Mar 13 16:36:10 2014
From: issues at jboss.org (Stuart Douglas (JIRA))
Date: Thu, 13 Mar 2014 16:36:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2850) AJP connector with external
	authentication
In-Reply-To: <JIRA.12530843.1391157375000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530843.1391157375000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530843.1391157375000.15306.1394742970591@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2850?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12952832#comment-12952832 ] 

Stuart Douglas commented on WFLY-2850:
--------------------------------------

What did the security domain setup for this look like in AS7/EAP6? I have implemented an authenticator based on this in Undertow, but it would be helpful to know what the server side config used to look like. 
                
> AJP connector with external authentication
> ------------------------------------------
>
>                 Key: WFLY-2850
>                 URL: https://issues.jboss.org/browse/WFLY-2850
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Web (Undertow)
>    Affects Versions: 8.0.0.CR1
>            Reporter: Geert Coelmont
>            Assignee: Stuart Douglas
>            Priority: Critical
>
> Tomcat allows to set the tomcatAuthentication attribute of the AJP connector to false to allow external web servers (e.g. apache httpd) to handle the authentication and pass that along.
> A similar option was added recently to JBossWeb as well (see WFLY-254), but JBossWeb has been replaced by Undertow. With Undertow this option isn't available as far as I can see.
> For me this is a critical problem as there is currently no way I can do negotiated (SPNEGO) authentication from within WildFly+Undertow. (See also WFLY-2404).

--
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

From issues at jboss.org  Thu Mar 13 17:10:12 2014
From: issues at jboss.org (Alexandre Nikolov (JIRA))
Date: Thu, 13 Mar 2014 17:10:12 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3113) Websocket connection fails
 when connecting to protected URL (basic login)
In-Reply-To: <JIRA.12534953.1394744993617@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534953.1394744993617@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534953.1394744993617.15321.1394745012185@jira02.app.mwc.hst.phx2.redhat.com>

Alexandre Nikolov created WFLY-3113:
---------------------------------------

             Summary: Websocket connection fails when connecting to protected URL (basic login)
                 Key: WFLY-3113
                 URL: https://issues.jboss.org/browse/WFLY-3113
             Project: WildFly
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Web (Undertow)
    Affects Versions: 8.0.0.Final
         Environment: WildFly 8.0.0.Final, Windows 8, RedHat Linux
Chrome, Firefox
            Reporter: Alexandre Nikolov
            Assignee: Stuart Douglas


In a sample application for JSR356 support, added security constraints with basic log-in. The websocket endpoint is protect with basic log-in.

When a websocket connection is attempted to the protected URL, there is inconsistent behavior in different browsers:
1. Chrome fails with 401 error code and the log-in screen is not displayed at all.
2. Firefox displays the log-in screen and the websocket is created and opened after the log-in succeeds.

But in a different application, using Atmosphere - both connections fails:
1. Chrome fails with the same error and the log-in screen is displayed after that. Most probably the log-in screen is triggered by Atmosphere when it falls back to long-polling
2. Firefox - The login screen is displayed and if the log-in suceeds, the socket is created, but Atmosphere fails to process it because the reques.getPathInfo() returns the context root prepended to the path info.
For example if the context root is "jsr356test" and the protected path is /pubsub/protected, the path info returned is /jsr356test/pubsub/protected instead of /pubsub/protected
Here is the related discussion on the Atmosphere users group:
https://groups.google.com/forum/#!topic/atmosphere-framework/ntIHOohlYIc

There is test WAR and source in the Atmosphere forum to reproduce the problem.

--
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

From issues at jboss.org  Thu Mar 13 18:12:10 2014
From: issues at jboss.org (Thomas Kriechbaum (JIRA))
Date: Thu, 13 Mar 2014 18:12:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3114) @Resource(lookup="java:...")
 causes an exception for URL resources
In-Reply-To: <JIRA.12534960.1394748695498@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534960.1394748695498@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534960.1394748695498.15360.1394748730755@jira02.app.mwc.hst.phx2.redhat.com>

Thomas Kriechbaum created WFLY-3114:
---------------------------------------

             Summary:  @Resource(lookup="java:...") causes an exception for URL resources
                 Key: WFLY-3114
                 URL: https://issues.jboss.org/browse/WFLY-3114
             Project: WildFly
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions: 8.0.0.Final
            Reporter: Thomas Kriechbaum


When referencing an URL resource via @Resource the lookup-property only supports a valid URLs (e.g. http://www.jboss.org). A JNDI-Name causes an exception (e.g. java:global/url/Configuration or java:app/url/Configuration)

Issue has been discussed in the user form.

Note:
@Resource(name="java:global/url/Configuration") works.
>From my point of view, the javadoc of @Resource is not very easy to understand.

--
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

From issues at jboss.org  Thu Mar 13 18:28:10 2014
From: issues at jboss.org (Thomas Kriechbaum (JIRA))
Date: Thu, 13 Mar 2014 18:28:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3115) JNDI-Names should be
 supported in jboss-specific deployment descriptors for URL resurces
In-Reply-To: <JIRA.12534961.1394749579184@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534961.1394749579184@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534961.1394749579184.15392.1394749690590@jira02.app.mwc.hst.phx2.redhat.com>

Thomas Kriechbaum created WFLY-3115:
---------------------------------------

             Summary: JNDI-Names should be supported in jboss-specific deployment descriptors for URL resurces
                 Key: WFLY-3115
                 URL: https://issues.jboss.org/browse/WFLY-3115
             Project: WildFly
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
    Affects Versions: 8.0.0.Final
            Reporter: Thomas Kriechbaum
            Priority: Critical


When using URL-Resources it would be very helpful, if the jboss-specific deployment descriptor (e.g. jboss-web.xml or jboss-app.xml) allows to reference a JNDI-name. At the moment, only valid URLs are supported.

When defining JNDI-names (e.g. java:app/url/Configuration) instead of convreate URLs, the EAR must not be adopted for each deployment as the specific URL is part of the server configuration (e.g. standalone.xml).

see proposal by [~sfcoy] at https://community.jboss.org/message/861952#861952

--
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

From issues at jboss.org  Thu Mar 13 18:36:10 2014
From: issues at jboss.org (Thomas Kriechbaum (JIRA))
Date: Thu, 13 Mar 2014 18:36:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3115) JNDI-Names should be
 supported in jboss-specific deployment descriptors for URL resources
In-Reply-To: <JIRA.12534961.1394749579000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534961.1394749579000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534961.1394749579000.15399.1394750170849@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-3115?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Thomas Kriechbaum updated WFLY-3115:
------------------------------------

    Summary: JNDI-Names should be supported in jboss-specific deployment descriptors for URL resources  (was: JNDI-Names should be supported in jboss-specific deployment descriptors for URL resurces)

    
> JNDI-Names should be supported in jboss-specific deployment descriptors for URL resources
> -----------------------------------------------------------------------------------------
>
>                 Key: WFLY-3115
>                 URL: https://issues.jboss.org/browse/WFLY-3115
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 8.0.0.Final
>            Reporter: Thomas Kriechbaum
>            Priority: Critical
>
> When using URL-Resources it would be very helpful, if the jboss-specific deployment descriptor (e.g. jboss-web.xml or jboss-app.xml) allows to reference a JNDI-name. At the moment, only valid URLs are supported.
> When defining JNDI-names (e.g. java:app/url/Configuration) instead of convreate URLs, the EAR must not be adopted for each deployment as the specific URL is part of the server configuration (e.g. standalone.xml).
> see proposal by [~sfcoy] at https://community.jboss.org/message/861952#861952

--
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

From issues at jboss.org  Thu Mar 13 18:44:10 2014
From: issues at jboss.org (Thomas Kriechbaum (JIRA))
Date: Thu, 13 Mar 2014 18:44:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3115) JNDI-Names should be
 supported in jboss-specific deployment descriptors for URL resources
In-Reply-To: <JIRA.12534961.1394749579000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534961.1394749579000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534961.1394749579000.15403.1394750650805@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-3115?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Thomas Kriechbaum updated WFLY-3115:
------------------------------------

    Priority: Major  (was: Critical)

    
> JNDI-Names should be supported in jboss-specific deployment descriptors for URL resources
> -----------------------------------------------------------------------------------------
>
>                 Key: WFLY-3115
>                 URL: https://issues.jboss.org/browse/WFLY-3115
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 8.0.0.Final
>            Reporter: Thomas Kriechbaum
>
> When using URL-Resources it would be very helpful, if the jboss-specific deployment descriptor (e.g. jboss-web.xml or jboss-app.xml) allows to reference a JNDI-name. At the moment, only valid URLs are supported.
> When defining JNDI-names (e.g. java:app/url/Configuration) instead of convreate URLs, the EAR must not be adopted for each deployment as the specific URL is part of the server configuration (e.g. standalone.xml).
> see proposal by [~sfcoy] at https://community.jboss.org/message/861952#861952

--
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

From issues at jboss.org  Thu Mar 13 18:46:10 2014
From: issues at jboss.org (Thomas Kriechbaum (JIRA))
Date: Thu, 13 Mar 2014 18:46:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3115) JNDI-Names should be
 supported in jboss-specific deployment descriptors for URL resources
In-Reply-To: <JIRA.12534961.1394749579000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534961.1394749579000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534961.1394749579000.15404.1394750770671@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-3115?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Thomas Kriechbaum updated WFLY-3115:
------------------------------------

    Description: 
When using URL-Resources it would be very helpful, if the jboss-specific deployment descriptor (e.g. jboss-web.xml or jboss-app.xml) allows to reference a JNDI-name. At the moment, only valid URLs are supported.

When defining JNDI-names (e.g. java:jboss/url/Configuration) instead of concrete URLs, the EAR must not be adopted for each deployment as the specific URL is part of the server configuration (e.g. standalone.xml).

see proposal by [~sfcoy] at https://community.jboss.org/message/861952#861952

  was:
When using URL-Resources it would be very helpful, if the jboss-specific deployment descriptor (e.g. jboss-web.xml or jboss-app.xml) allows to reference a JNDI-name. At the moment, only valid URLs are supported.

When defining JNDI-names (e.g. java:app/url/Configuration) instead of convreate URLs, the EAR must not be adopted for each deployment as the specific URL is part of the server configuration (e.g. standalone.xml).

see proposal by [~sfcoy] at https://community.jboss.org/message/861952#861952


    
> JNDI-Names should be supported in jboss-specific deployment descriptors for URL resources
> -----------------------------------------------------------------------------------------
>
>                 Key: WFLY-3115
>                 URL: https://issues.jboss.org/browse/WFLY-3115
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 8.0.0.Final
>            Reporter: Thomas Kriechbaum
>
> When using URL-Resources it would be very helpful, if the jboss-specific deployment descriptor (e.g. jboss-web.xml or jboss-app.xml) allows to reference a JNDI-name. At the moment, only valid URLs are supported.
> When defining JNDI-names (e.g. java:jboss/url/Configuration) instead of concrete URLs, the EAR must not be adopted for each deployment as the specific URL is part of the server configuration (e.g. standalone.xml).
> see proposal by [~sfcoy] at https://community.jboss.org/message/861952#861952

--
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

From issues at jboss.org  Thu Mar 13 21:30:10 2014
From: issues at jboss.org (Harald Pehl (JIRA))
Date: Thu, 13 Mar 2014 21:30:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3116) Update to HAL 2.2.0.Beta5
In-Reply-To: <JIRA.12534965.1394760498036@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534965.1394760498036@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534965.1394760498036.15474.1394760610596@jira02.app.mwc.hst.phx2.redhat.com>

Harald Pehl created WFLY-3116:
---------------------------------

             Summary: Update to HAL 2.2.0.Beta5
                 Key: WFLY-3116
                 URL: https://issues.jboss.org/browse/WFLY-3116
             Project: WildFly
          Issue Type: Component  Upgrade
      Security Level: Public (Everyone can see)
          Components: Web Console
            Reporter: Harald Pehl
            Assignee: Harald Pehl
             Fix For: 8.0.1.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

From issues at jboss.org  Thu Mar 13 21:42:10 2014
From: issues at jboss.org (Yong Hao Gao (JIRA))
Date: Thu, 13 Mar 2014 21:42:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBMESSAGING-1944) When a message is
 rejected by a full destination the session.close() method has a 10 seconds
 delay before returning.
In-Reply-To: <JIRA.12490011.1366617813000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12490011.1366617813000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12490011.1366617813000.15491.1394761330896@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBMESSAGING-1944?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Yong Hao Gao closed JBMESSAGING-1944.
-------------------------------------


    
> When a message is rejected by a full destination the session.close() method has a 10 seconds delay before returning.
> --------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1944
>                 URL: https://issues.jboss.org/browse/JBMESSAGING-1944
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Messaging Core
>         Environment: JBoss EAP 5.x
>            Reporter: Tom Ross
>            Assignee: Tom Ross
>             Fix For: 1.4.8.SP10
>
>
> The session.close() method waits on the send() method to notify it that all message have been sent. This arrangement breaks when a none persistent message gets rejected by a full destination. In that case the close() method waits for 10 seconds before returning.

--
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

From issues at jboss.org  Thu Mar 13 23:02:14 2014
From: issues at jboss.org (Yong Hao Gao (JIRA))
Date: Thu, 13 Mar 2014 23:02:14 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBMESSAGING-1905) Proper handling the
 timeout issue in receive(timeout)
In-Reply-To: <JIRA.12450250.1319507911000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12450250.1319507911000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12450250.1319507911000.15566.1394766134014@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBMESSAGING-1905?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Yong Hao Gao updated JBMESSAGING-1905:
--------------------------------------

    Fix Version/s: 1.4.8.SP11
                       (was: 1.4.8.SP10)

    
> Proper handling the timeout issue in receive(timeout)
> -----------------------------------------------------
>
>                 Key: JBMESSAGING-1905
>                 URL: https://issues.jboss.org/browse/JBMESSAGING-1905
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: JMS Facade
>    Affects Versions: 1.4.0.SP3.CP14, 1.4.8.SP3
>            Reporter: Yong Hao Gao
>            Assignee: Yong Hao Gao
>             Fix For: 1.4.0.SP3.CP15, 1.4.8.SP11
>
>


--
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

From issues at jboss.org  Thu Mar 13 23:02:13 2014
From: issues at jboss.org (Yong Hao Gao (JIRA))
Date: Thu, 13 Mar 2014 23:02:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBMESSAGING-1923) Node cannot enter
 cluster during failover
In-Reply-To: <JIRA.12467181.1337792973000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12467181.1337792973000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12467181.1337792973000.15562.1394766133614@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBMESSAGING-1923?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Yong Hao Gao updated JBMESSAGING-1923:
--------------------------------------

    Fix Version/s: 1.4.8.SP11
                       (was: 1.4.8.SP10)

    
> Node cannot enter cluster during failover
> -----------------------------------------
>
>                 Key: JBMESSAGING-1923
>                 URL: https://issues.jboss.org/browse/JBMESSAGING-1923
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: JMS Clustering
>    Affects Versions: 1.4.0.SP3.CP14, 1.4.8.SP8
>            Reporter: Terrence Cowhey
>            Assignee: Yong Hao Gao
>             Fix For: 1.4.0.SP3.CP15, 1.4.8.SP11
>
>
> The setup is a cluster of 4 nodes, arranged into 2 'sites':
>   Primary Site:   site2blade1, site2blade2
>   Secondary Site: site2blade3, site2blade4
> After restarting the nodes of the secondary site many times, one of them fails to come up, with a deployment failure in JMS - the PostOffice fails with an IllegalStateException.
> The previous restarts were induced by either 'kill -KILL' on the app server, or a graceful shutdown.  The final (failed) restart was on site2blade4, and was induced by a graceful shutdown of the app server.
> The IllegalStateException is being thrown during a failover while a new node is starting to join the cluster. Waiting 60 seconds to start the node in question fixes the issue.

--
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

From issues at jboss.org  Thu Mar 13 23:02:14 2014
From: issues at jboss.org (Yong Hao Gao (JIRA))
Date: Thu, 13 Mar 2014 23:02:14 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBMESSAGING-1880) JMSRedelivered not
 properly set when a client exits without closing the JMS resources
 (connection, session, consumer)
In-Reply-To: <JIRA.12439922.1308214407000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12439922.1308214407000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12439922.1308214407000.15569.1394766134261@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBMESSAGING-1880?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Yong Hao Gao updated JBMESSAGING-1880:
--------------------------------------

    Fix Version/s: 1.4.8.SP11
                       (was: 1.4.8.SP10)

    
> JMSRedelivered not properly set when a client exits without closing the JMS resources (connection, session, consumer)
> ---------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1880
>                 URL: https://issues.jboss.org/browse/JBMESSAGING-1880
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: JMS Facade
>    Affects Versions: 1.4.0.SP3.CP12, 1.4.8.GA
>            Reporter: Yong Hao Gao
>            Assignee: Yong Hao Gao
>             Fix For: 1.4.0.SP3.CP15, 1.4.8.SP11
>
>
> If a client consumer receives a message and exit without acknowledging it or close the connection/session/consumer object, the message will be cancelled at the server side. When the message is delivered, its JMSRedelivered flag should be true.

--
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

From issues at jboss.org  Thu Mar 13 23:02:14 2014
From: issues at jboss.org (Yong Hao Gao (JIRA))
Date: Thu, 13 Mar 2014 23:02:14 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBMESSAGING-1870) ClientSocketWrapper
 constructors have a redundant call to createStreams()
In-Reply-To: <JIRA.12439178.1307498067000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12439178.1307498067000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12439178.1307498067000.15573.1394766134587@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBMESSAGING-1870?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Yong Hao Gao updated JBMESSAGING-1870:
--------------------------------------

    Fix Version/s: 1.4.8.SP11
                       (was: 1.4.8.SP10)

    
> ClientSocketWrapper constructors have a redundant call to createStreams()
> -------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1870
>                 URL: https://issues.jboss.org/browse/JBMESSAGING-1870
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 1.4.0.SP3.CP12, 1.4.8.GA
>            Reporter: Ron Sigal
>            Assignee: Yong Hao Gao
>            Priority: Minor
>             Fix For: 1.4.0.SP3.CP15, 1.4.8.SP11
>
>
> org.jboss.jms.client.remoting.ClientSocketWrapper is derived from org.jboss.remoting.transport.socket.ClientSocketWrapper.  The constructors of the former look like
>    public ClientSocketWrapper(Socket socket) throws IOException
>    {
>       super(socket);
>       createStreams(socket, null);
>    }
>    public ClientSocketWrapper(Socket socket, Map metadata, Integer timeout) throws Exception
>    {
>       super(socket, metadata, timeout);
>       createStreams(socket, metadata);
>    }
> and the constructors of the latter look like
>    public ClientSocketWrapper(Socket socket) throws IOException
>    {
>       super(socket);
>       createStreams(socket, null);
>    }
>    public ClientSocketWrapper(Socket socket, Map metadata, Integer timeout) throws Exception
>    {
>       super(socket, timeout);
>       createStreams(socket, metadata);
>    }
> The calls to createStreams() in the JBossMessaging versions of ClientSocketWrapper is redundant.

--
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

From issues at jboss.org  Thu Mar 13 23:02:14 2014
From: issues at jboss.org (Yong Hao Gao (JIRA))
Date: Thu, 13 Mar 2014 23:02:14 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBMESSAGING-1866) Adapt JBM tests to new
 failover model
In-Reply-To: <JIRA.12437745.1305686696000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12437745.1305686696000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12437745.1305686696000.15575.1394766134710@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBMESSAGING-1866?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Yong Hao Gao updated JBMESSAGING-1866:
--------------------------------------

    Fix Version/s: 1.4.8.SP11
                       (was: 1.4.8.SP10)

    
> Adapt JBM tests to new failover model
> -------------------------------------
>
>                 Key: JBMESSAGING-1866
>                 URL: https://issues.jboss.org/browse/JBMESSAGING-1866
>             Project: JBoss Messaging
>          Issue Type: Task
>          Components: Tests and Performance
>    Affects Versions: 1.4.0.SP3.CP12, 1.4.8.GA
>            Reporter: Yong Hao Gao
>            Assignee: Yong Hao Gao
>             Fix For: 1.4.0.SP3.CP15, 1.4.8.SP11
>
>
> In jbm test suite some tests will fail if the 'keepOldFailoverModel' is set to false. This is because with new model, the failover for a dead node doesn't happen immediately. This affects all tests which expect a failover to happen after a certain timeout.

--
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

From issues at jboss.org  Thu Mar 13 23:02:14 2014
From: issues at jboss.org (Yong Hao Gao (JIRA))
Date: Thu, 13 Mar 2014 23:02:14 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBMESSAGING-1852) Make the connection
 failover retry paramters configurable
In-Reply-To: <JIRA.12433283.1300516134000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12433283.1300516134000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12433283.1300516134000.15579.1394766134961@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBMESSAGING-1852?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Yong Hao Gao updated JBMESSAGING-1852:
--------------------------------------

    Fix Version/s: 1.4.8.SP11
                       (was: 1.4.8.SP10)

    
> Make the connection failover retry paramters configurable
> ---------------------------------------------------------
>
>                 Key: JBMESSAGING-1852
>                 URL: https://issues.jboss.org/browse/JBMESSAGING-1852
>             Project: JBoss Messaging
>          Issue Type: Enhancement
>          Components: JMS Client Manager
>    Affects Versions: 1.4.0.SP3.CP11, 1.4.7.GA
>            Reporter: Yong Hao Gao
>            Assignee: Yong Hao Gao
>             Fix For: 1.4.0.SP3.CP15, 1.4.8.SP11
>
>
> Currently if a connection is broken and the client tries to fail over to a new connection, the retry times and intervals are hardcoded. (10 and 2sec resp.)
> Make it configurable can suit some use cases where the server is shutdown and come back later. (with hardcoded retry, the failover may have given up before the server is back).

--
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

From issues at jboss.org  Thu Mar 13 23:02:15 2014
From: issues at jboss.org (Yong Hao Gao (JIRA))
Date: Thu, 13 Mar 2014 23:02:15 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBMESSAGING-1843) Incorporate JBREM-1144
In-Reply-To: <JIRA.12428684.1295836008000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12428684.1295836008000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12428684.1295836008000.15582.1394766135124@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBMESSAGING-1843?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Yong Hao Gao updated JBMESSAGING-1843:
--------------------------------------

    Fix Version/s: 1.4.8.SP11
                       (was: 1.4.8.SP10)

    
> Incorporate JBREM-1144
> ----------------------
>
>                 Key: JBMESSAGING-1843
>                 URL: https://issues.jboss.org/browse/JBMESSAGING-1843
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: JMS Remoting
>    Affects Versions: 1.4.0.SP3.CP11, 1.4.7.GA
>            Reporter: Yong Hao Gao
>            Assignee: Yong Hao Gao
>            Priority: Critical
>             Fix For: 1.4.0.SP3.CP15, 1.4.8.SP11
>
>


--
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

From issues at jboss.org  Thu Mar 13 23:02:15 2014
From: issues at jboss.org (Yong Hao Gao (JIRA))
Date: Thu, 13 Mar 2014 23:02:15 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBMESSAGING-1834) JBoss Messaging XA
 Recovery Configuration Documentation needs update
In-Reply-To: <JIRA.12426551.1292618175000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12426551.1292618175000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12426551.1292618175000.15586.1394766135408@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBMESSAGING-1834?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Yong Hao Gao updated JBMESSAGING-1834:
--------------------------------------

    Fix Version/s: 1.4.8.SP11
                       (was: 1.4.8.SP10)

    
> JBoss Messaging XA Recovery Configuration Documentation needs update
> --------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1834
>                 URL: https://issues.jboss.org/browse/JBMESSAGING-1834
>             Project: JBoss Messaging
>          Issue Type: Task
>          Components: Documentation and Training
>    Affects Versions: 1.4.7.GA
>            Reporter: Bruno Machado
>              Labels: Documentation,, jboss, messaging
>             Fix For: 1.4.8.SP11
>
>
> Chapter JBoss Messaging XA Recovery Configuration[1] has the following paragraph:
> >> DefaultJMSProvider ships with JBoss Enterprise Application Platform. It is defined in $JBOSS_HOME/server/$PROFILE/conf/jms-ds.xml (or, in a clustered environment, hajndi-jms-ds.xml)
> It is confused because jms-ds.xml is placed on $JBOSS_HOME/server/$PROFILE/deploy/messaging, and for clustered environment there is no hajndi-jms-ds.xml.
> [1] http://docs.redhat.com/docs/en-US/JBoss_Enterprise_Application_Platform/5/html/JBoss_Messaging_User_Guide/recovery.htmljms

--
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

From issues at jboss.org  Thu Mar 13 23:02:15 2014
From: issues at jboss.org (Yong Hao Gao (JIRA))
Date: Thu, 13 Mar 2014 23:02:15 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBMESSAGING-1833) Intermittent test
 failure -- MultipleFailoverTest.testAllKindsOfServerFailures()
In-Reply-To: <JIRA.12426278.1292419518000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12426278.1292419518000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12426278.1292419518000.15589.1394766135643@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBMESSAGING-1833?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Yong Hao Gao updated JBMESSAGING-1833:
--------------------------------------

    Fix Version/s: 1.4.8.SP11
                       (was: 1.4.8.SP10)

    
> Intermittent test failure -- MultipleFailoverTest.testAllKindsOfServerFailures()
> --------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1833
>                 URL: https://issues.jboss.org/browse/JBMESSAGING-1833
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Tests and Performance
>    Affects Versions: 1.4.0.SP3.CP11, 1.4.7.GA
>            Reporter: Yong Hao Gao
>            Assignee: Yong Hao Gao
>             Fix For: 1.4.0.SP3.CP15, 1.4.8.SP11
>
>
> I'm seeing failure in the test, the stack trace:
> 1) testAllKindsOfServerFailures(org.jboss.test.messaging.jms.clustering.MultipleFailoverTest)javax.jms.JMSException: Cannot find a cached connection factory delegate for node -1
> 	at org.jboss.jms.client.container.ClusteringAspect.handleCreateConnectionDelegate(ClusteringAspect.java:217)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at org.jboss.aop.advice.PerInstanceAdvice.invoke(PerInstanceAdvice.java:121)
> 	at org.jboss.jms.client.delegate.ClientClusteredConnectionFactoryDelegate$createConnectionDelegate_N3019492359065420858.invokeNext(ClientClusteredConnectionFactoryDelegate$createConnectionDelegate_N3019492359065420858.java)
> 	at org.jboss.jms.client.delegate.ClientClusteredConnectionFactoryDelegate.createConnectionDelegate(ClientClusteredConnectionFactoryDelegate.java)
> 	at org.jboss.jms.client.FailoverCommandCenter.failureDetected(FailoverCommandCenter.java:129)
> 	at org.jboss.jms.client.container.FailoverValveInterceptor.invoke(FailoverValveInterceptor.java:124)
> 	at org.jboss.aop.advice.PerInstanceInterceptor.invoke(PerInstanceInterceptor.java:105)
> 	at org.jboss.jms.client.delegate.ClientSessionDelegate$send_6145266547759487588.invokeNext(ClientSessionDelegate$send_6145266547759487588.java)
> 	at org.jboss.jms.client.container.ClosedInterceptor.invoke(ClosedInterceptor.java:172)
> 	at org.jboss.aop.advice.PerInstanceInterceptor.invoke(PerInstanceInterceptor.java:105)
> 	at org.jboss.jms.client.delegate.ClientSessionDelegate$send_6145266547759487588.invokeNext(ClientSessionDelegate$send_6145266547759487588.java)
> 	at org.jboss.jms.client.delegate.ClientSessionDelegate.send(ClientSessionDelegate.java)
> 	at org.jboss.jms.client.container.ProducerAspect.handleSend(ProducerAspect.java:276)
> 	at org.jboss.aop.advice.org.jboss.jms.client.container.ProducerAspect40.invoke(ProducerAspect40.java)
> 	at org.jboss.jms.client.delegate.ClientProducerDelegate$send_3961598017717988886.invokeNext(ClientProducerDelegate$send_3961598017717988886.java)
> 	at org.jboss.jms.client.container.ClosedInterceptor.invoke(ClosedInterceptor.java:172)
> 	at org.jboss.aop.advice.PerInstanceInterceptor.invoke(PerInstanceInterceptor.java:105)
> 	at org.jboss.jms.client.delegate.ClientProducerDelegate$send_3961598017717988886.invokeNext(ClientProducerDelegate$send_3961598017717988886.java)
> 	at org.jboss.jms.client.delegate.ClientProducerDelegate.send(ClientProducerDelegate.java)
> 	at org.jboss.jms.client.JBossMessageProducer.send(JBossMessageProducer.java:165)
> 	at org.jboss.jms.client.JBossMessageProducer.send(JBossMessageProducer.java:208)
> 	at org.jboss.jms.client.JBossMessageProducer.send(JBossMessageProducer.java:146)
> 	at org.jboss.jms.client.JBossMessageProducer.send(JBossMessageProducer.java:137)
> 	at org.jboss.test.messaging.jms.clustering.MultipleFailoverTest.testAllKindsOfServerFailures(MultipleFailoverTest.java:174)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at org.jboss.test.messaging.tools.junit.SelectiveTestRunner.main(SelectiveTestRunner.java:58)

--
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

From issues at jboss.org  Thu Mar 13 23:02:15 2014
From: issues at jboss.org (Yong Hao Gao (JIRA))
Date: Thu, 13 Mar 2014 23:02:15 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBMESSAGING-1830) Random
 MultipleFailoverTest failures
In-Reply-To: <JIRA.12424669.1290663743000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12424669.1290663743000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12424669.1290663743000.15591.1394766135784@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBMESSAGING-1830?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Yong Hao Gao updated JBMESSAGING-1830:
--------------------------------------

    Fix Version/s: 1.4.8.SP11
                       (was: 1.4.8.SP10)

    
> Random MultipleFailoverTest failures
> ------------------------------------
>
>                 Key: JBMESSAGING-1830
>                 URL: https://issues.jboss.org/browse/JBMESSAGING-1830
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Tests and Performance
>    Affects Versions: 1.4.0.SP3.CP11, 1.4.7.GA
>            Reporter: Yong Hao Gao
>            Assignee: Yong Hao Gao
>             Fix For: 1.4.0.SP3.CP15, 1.4.8.SP11
>
>
> The MultipleFailoverTest.testAllKindsOfServerFailures sometimes fails for reason not yet known. So far I have found that the some failoveMap updates didn't get received, so the client didn't failover to the right node.

--
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

From issues at jboss.org  Thu Mar 13 23:02:16 2014
From: issues at jboss.org (Yong Hao Gao (JIRA))
Date: Thu, 13 Mar 2014 23:02:16 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBMESSAGING-1802) Sending MapMessage
 with large String value is broken
In-Reply-To: <JIRA.12409280.1271902381000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12409280.1271902381000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12409280.1271902381000.15597.1394766136213@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBMESSAGING-1802?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Yong Hao Gao updated JBMESSAGING-1802:
--------------------------------------

    Fix Version/s: 1.4.8.SP11
                       (was: 1.4.8.SP10)

    
> Sending MapMessage with large String value is broken
> ----------------------------------------------------
>
>                 Key: JBMESSAGING-1802
>                 URL: https://issues.jboss.org/browse/JBMESSAGING-1802
>             Project: JBoss Messaging
>          Issue Type: Feature Request
>    Affects Versions: 1.4.0.SP3.CP10, 1.4.6.GA
>            Reporter: Justin Bertram
>            Assignee: Yong Hao Gao
>             Fix For: 1.4.8.SP11
>
>
> Sending a javax.jms.MapMessage that has a String value >= 65536 characters 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

From issues at jboss.org  Thu Mar 13 23:02:16 2014
From: issues at jboss.org (Yong Hao Gao (JIRA))
Date: Thu, 13 Mar 2014 23:02:16 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBMESSAGING-1794) SecurityStore not
	applied correctly
In-Reply-To: <JIRA.12407035.1268927984000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12407035.1268927984000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12407035.1268927984000.15604.1394766136797@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBMESSAGING-1794?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Yong Hao Gao updated JBMESSAGING-1794:
--------------------------------------

    Fix Version/s: 1.4.8.SP11
                       (was: 1.4.8.SP10)

    
> SecurityStore not applied correctly
> -----------------------------------
>
>                 Key: JBMESSAGING-1794
>                 URL: https://issues.jboss.org/browse/JBMESSAGING-1794
>             Project: JBoss Messaging
>          Issue Type: Feature Request
>          Components: JMS Security
>    Affects Versions: 1.4.6.GA
>            Reporter: Justin Bertram
>            Assignee: Yong Hao Gao
>             Fix For: 1.4.8.SP11
>
>
> The "SecurityStore" in messaging-jboss-beans.xml doesn't appear to be getting applied correctly.  Steps to reproduce:
> 1) Unzip a fresh copy of JBoss EAP 5
> 2) Change the "suckerPassword" attribute in <JBOSS_HOME>/server/all/deploy/messaging/messaging-jboss-beans.xml
> 3) Activate TRACE logging with this category in <JBOSS_HOME>/server/all/conf/jboss-log4j.xml:
>    <category name="org.jboss.jms.server.jbosssx.JBossASSecurityMetadataStore">
>       <priority value="TRACE"/>
>    </category>
> 4) Start the server: <JBOSS_HOME>/bin/run.sh -c all
> 5) This comes up in the log:
> TRACE [org.jboss.jms.server.jbosssx.JBossASSecurityMetadataStore] (main) authenticating user JBM.SUCKER
> TRACE [org.jboss.jms.server.jbosssx.JBossASSecurityMetadataStore] (main) Authenticating sucker user
> WARN  [org.jboss.jms.server.jbosssx.JBossASSecurityMetadataStore] (main) WARNING! POTENTIAL SECURITY RISK. It has been detected that the MessageSucker component which sucks messages from one node to another has not had its password changed from the installation default. Please see the JBoss Messaging user guide for instructions on how to do this.
> ERROR [org.jboss.messaging.util.ExceptionUtil] (main) ConnectionFactoryEndpoint[jboss.messaging.connectionfactory:service=ClusterPullConnectionFactory] createFailoverConnectionDelegate [da-yi5epx6g-1-0jhcpx6g-twc79y-100j3]
> javax.jms.JMSSecurityException: User JBM.SUCKER is NOT authenticated
>    at org.jboss.jms.server.jbosssx.JBossASSecurityMetadataStore.authenticate(JBossASSecurityMetadataStore.java:223)
>    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>    at java.lang.reflect.Method.invoke(Method.java:597)
>    at com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:93)
>    at com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:27)
>    at com.sun.jmx.mbeanserver.MBeanIntrospector.invokeM(MBeanIntrospector.java:208)
>    at com.sun.jmx.mbeanserver.PerInterface.invoke(PerInterface.java:120)
>    at com.sun.jmx.mbeanserver.MBeanSupport.invoke(MBeanSupport.java:262)
>    at javax.management.StandardMBean.invoke(StandardMBean.java:391)
>    at org.jboss.mx.server.RawDynamicInvoker.invoke(RawDynamicInvoker.java:164)
>    at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:668)
>    at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
>    at $Proxy99.authenticate(Unknown Source)
>    at org.jboss.jms.server.endpoint.ServerConnectionFactoryEndpoint.createConnectionDelegateInternal(ServerConnectionFactoryEndpoint.java:233)
>    at org.jboss.jms.server.endpoint.ServerConnectionFactoryEndpoint.createConnectionDelegate(ServerConnectionFactoryEndpoint.java:171)
>    at org.jboss.jms.server.endpoint.advised.ConnectionFactoryAdvised.org$jboss$jms$server$endpoint$advised$ConnectionFactoryAdvised$createConnectionDelegate$aop(ConnectionFactoryAdvised.java:108)
>    at org.jboss.jms.server.endpoint.advised.ConnectionFactoryAdvised.createConnectionDelegate(ConnectionFactoryAdvised.java)
>    at org.jboss.jms.wireformat.ConnectionFactoryCreateConnectionDelegateRequest.serverInvoke(ConnectionFactoryCreateConnectionDelegateRequest.java:91)
>    at org.jboss.jms.server.remoting.JMSServerInvocationHandler.invoke(JMSServerInvocationHandler.java:157)
>    at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:897)
>    at org.jboss.remoting.transport.local.LocalClientInvoker.invoke(LocalClientInvoker.java:106)
>    at org.jboss.remoting.Client.invoke(Client.java:1917)
>    at org.jboss.remoting.Client.invoke(Client.java:768)
>    at org.jboss.jms.client.delegate.ClientConnectionFactoryDelegate.org$jboss$jms$client$delegate$ClientConnectionFactoryDelegate$createConnectionDelegate$aop(ClientConnectionFactoryDelegate.java:178)
>    at org.jboss.jms.client.delegate.ClientConnectionFactoryDelegate$createConnectionDelegate_N3019492359065420858.invokeNext(ClientConnectionFactoryDelegate$createConnectionDelegate_N3019492359065420858.java)
>    at org.jboss.jms.client.container.StateCreationAspect.handleCreateConnectionDelegate(StateCreationAspect.java:80)
>    at org.jboss.aop.advice.org.jboss.jms.client.container.StateCreationAspect_z_handleCreateConnectionDelegate_15295742.invoke(StateCreationAspect_z_handleCreateConnectionDelegate_15295742.java)
>    at org.jboss.jms.client.delegate.ClientConnectionFactoryDelegate$createConnectionDelegate_N3019492359065420858.invokeNext(ClientConnectionFactoryDelegate$createConnectionDelegate_N3019492359065420858.java)
>    at org.jboss.jms.client.delegate.ClientConnectionFactoryDelegate.createConnectionDelegate(ClientConnectionFactoryDelegate.java)
>    at org.jboss.jms.client.JBossConnectionFactory.createConnectionInternal(JBossConnectionFactory.java:205)
>    at org.jboss.jms.client.JBossConnectionFactory.createConnection(JBossConnectionFactory.java:87)
>    at org.jboss.messaging.core.impl.clusterconnection.ClusterConnectionManager$ConnectionInfo.start(ClusterConnectionManager.java:669)
>    at org.jboss.messaging.core.impl.clusterconnection.ClusterConnectionManager.ensureAllConnectionsCreated(ClusterConnectionManager.java:419)
>    at org.jboss.messaging.core.impl.clusterconnection.ClusterConnectionManager.notify(ClusterConnectionManager.java:241)
>    at org.jboss.messaging.core.impl.DefaultClusterNotifier.sendNotification(DefaultClusterNotifier.java:72)
>    at org.jboss.messaging.core.impl.postoffice.MessagingPostOffice.putReplicantLocally(MessagingPostOffice.java:1245)
>    at org.jboss.messaging.core.impl.postoffice.MessagingPostOffice.put(MessagingPostOffice.java:1525)
>    at org.jboss.jms.server.connectionfactory.ConnectionFactoryJNDIMapper.registerConnectionFactory(ConnectionFactoryJNDIMapper.java:252)
>    at org.jboss.jms.server.connectionfactory.ConnectionFactory.startService(ConnectionFactory.java:206)
>    at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanSupport.java:376)
>    at org.jboss.system.ServiceMBeanSupport.start(ServiceMBeanSupport.java:269)
>    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>    at java.lang.reflect.Method.invoke(Method.java:597)
>    at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:157)
>    at org.jboss.mx.server.Invocation.dispatch(Invocation.java:96)
>    at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:138)
>    at org.jboss.mx.server.Invocation.invoke(Invocation.java:90)
>    at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:140)
>    at org.jboss.mx.server.Invocation.invoke(Invocation.java:90)
>    at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
>    at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:668)
>    at org.jboss.system.microcontainer.ServiceProxy.invoke(ServiceProxy.java:206)
>    at $Proxy38.start(Unknown Source)
>    at org.jboss.system.microcontainer.StartStopLifecycleAction.installAction(StartStopLifecycleAction.java:42)
>    at org.jboss.system.microcontainer.StartStopLifecycleAction.installAction(StartStopLifecycleAction.java:37)
>    at org.jboss.dependency.plugins.action.SimpleControllerContextAction.simpleInstallAction(SimpleControllerContextAction.java:62)
>    at org.jboss.dependency.plugins.action.AccessControllerContextAction.install(AccessControllerContextAction.java:71)
>    at org.jboss.dependency.plugins.AbstractControllerContextActions.install(AbstractControllerContextActions.java:51)
>    at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
>    at org.jboss.system.microcontainer.ServiceControllerContext.install(ServiceControllerContext.java:297)
>    at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1633)
>    at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:935)
>    at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1083)
>    at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:985)
>    at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:823)
>    at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
>    at org.jboss.system.ServiceController.doChange(ServiceController.java:688)
>    at org.jboss.system.ServiceController.start(ServiceController.java:460)
>    at org.jboss.system.deployers.ServiceDeployer.start(ServiceDeployer.java:163)
>    at org.jboss.system.deployers.ServiceDeployer.deploy(ServiceDeployer.java:99)
>    at org.jboss.system.deployers.ServiceDeployer.deploy(ServiceDeployer.java:46)
>    at org.jboss.deployers.spi.deployer.helpers.AbstractSimpleRealDeployer.internalDeploy(AbstractSimpleRealDeployer.java:62)
>    at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployer.deploy(AbstractRealDeployer.java:50)
>    at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:171)
>    at org.jboss.deployers.plugins.deployers.DeployersImpl.doDeploy(DeployersImpl.java:1440)
>    at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1158)
>    at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1179)
>    at org.jboss.deployers.plugins.deployers.DeployersImpl.install(DeployersImpl.java:1099)
>    at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
>    at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1633)
>    at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:935)
>    at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1083)
>    at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:985)
>    at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:823)
>    at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
>    at org.jboss.deployers.plugins.deployers.DeployersImpl.process(DeployersImpl.java:782)
>    at org.jboss.deployers.plugins.main.MainDeployerImpl.process(MainDeployerImpl.java:702)
>    at org.jboss.system.server.profileservice.repository.MainDeployerAdapter.process(MainDeployerAdapter.java:117)
>    at org.jboss.system.server.profileservice.repository.ProfileDeployAction.install(ProfileDeployAction.java:70)
>    at org.jboss.system.server.profileservice.repository.AbstractProfileAction.install(AbstractProfileAction.java:53)
>    at org.jboss.system.server.profileservice.repository.AbstractProfileService.install(AbstractProfileService.java:403)
>    at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
>    at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1633)
>    at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:935)
>    at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1083)
>    at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:985)
>    at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:775)
>    at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:540)
>    at org.jboss.system.server.profileservice.repository.AbstractProfileService.registerProfile(AbstractProfileService.java:308)
>    at org.jboss.system.server.profileservice.ProfileServiceBootstrap.start(ProfileServiceBootstrap.java:256)
>    at org.jboss.bootstrap.AbstractServerImpl.start(AbstractServerImpl.java:461)
>    at org.jboss.Main.boot(Main.java:221)
>    at org.jboss.Main$1.run(Main.java:556)
>    at java.lang.Thread.run(Thread.java:619)
> It appears that org.jboss.jms.server.endpoint.ServerConnectionFactoryEndpoint is creating the connection with the password from messaging-jboss-beans.xml, but org.jboss.jms.server.jbosssx.JBossASSecurityMetadataStore is authenticating it with the information from messaging-service.xml (which uses the default password since "SuckerPassword" is commented out).

--
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

From issues at jboss.org  Thu Mar 13 23:02:17 2014
From: issues at jboss.org (Yong Hao Gao (JIRA))
Date: Thu, 13 Mar 2014 23:02:17 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBMESSAGING-1790) A single lagging JBM
 topic subscriber can cause all publishes to lag
In-Reply-To: <JIRA.12405371.1267127552000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12405371.1267127552000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12405371.1267127552000.15608.1394766137021@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBMESSAGING-1790?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Yong Hao Gao updated JBMESSAGING-1790:
--------------------------------------

    Fix Version/s: 1.4.8.SP11
                       (was: 1.4.8.SP10)

    
> A single lagging JBM topic subscriber can cause all publishes to lag
> --------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1790
>                 URL: https://issues.jboss.org/browse/JBMESSAGING-1790
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Messaging Core
>    Affects Versions: 1.4.3.GA
>         Environment: JBoss 5.1.0_GA, JDK 1.6.0_14 and JDK 1.6.0_18, multiple versions of Windows (2008, 2003, Vista)
>            Reporter: Jason Burton
>            Assignee: Yong Hao Gao
>             Fix For: 1.4.8.SP11
>
>         Attachments: stack_traces.zip
>
>
> We have an application that makes heavy use of JMS topics.  The attached stack traces lead me to believe that we have one client that has some sort of network problem and that JBM is trying to write messages to it.  Evidently this client's socket isn't working anymore.  That's no problem (and maybe could be expected), but this causes every other client publish to hang. 
> The attached stack traces are from JBoss and taken 10 seconds apart during an occurence of this.  During this time, we observed that one or more calls to JBossMessageProducer.publish() took 50 seconds to complete (normally takes 2-5 milliseconds).  Best I can tell, the "WorkManager(2)-3" thread is the culprit.  Over the 50 seconds, it seemed to be stuck in a socketWrite() and has object <0x143a2250>  locked.  There are a few other publishing threads waiting on that lock.
> I'm pretty sure this relates to a closed bug:
> https://jira.jboss.org/jira/browse/JBMESSAGING-1220
> This bug report states to run a client out of memory to reproduce the problem, but at the point of the attached server stack traces. there aren't any clients that are out of memory.  We have been able to reproduce this by running a client out of memory, though.  That bug report stated to reduce the prefetchSize to a number of messages whose size would be under the TCP window size.  Best I can tell by searching, the TCP window size defaults to 16K on Windows.  It is definitely possible that the messages we send are larger than 16K, so even setting the prefetchSize to 1 would be larger that the TCP window size.
> Let me know if you need any more information.

--
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

From issues at jboss.org  Thu Mar 13 23:02:17 2014
From: issues at jboss.org (Yong Hao Gao (JIRA))
Date: Thu, 13 Mar 2014 23:02:17 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBMESSAGING-1789) setFetchSize used in
 JDBCPersistenceManager with too large value for oracle (200000)
In-Reply-To: <JIRA.12404244.1265883556000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12404244.1265883556000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12404244.1265883556000.15613.1394766137319@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBMESSAGING-1789?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Yong Hao Gao updated JBMESSAGING-1789:
--------------------------------------

    Fix Version/s: 1.4.8.SP11
                       (was: 1.4.8.SP10)

    
> setFetchSize used in JDBCPersistenceManager with too large value for oracle (200000)
> ------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1789
>                 URL: https://issues.jboss.org/browse/JBMESSAGING-1789
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Messaging Core Persistence
>    Affects Versions: 1.4.5.GA, 1.4.6.GA, 1.4.8.GA
>         Environment: oracle
>            Reporter: Simo Nikula
>            Assignee: Yong Hao Gao
>             Fix For: 1.4.0.SP3.CP15, 1.4.8.SP11
>
>
> in method loadFromStart (line 984 in 1.4.6) fetchSize is set based on parameter number which is as default 200000.
> setting max rows using setMaxRows with same value would be correct way to limit result set.
> java.sql.SQLException: Bigger type length than Maximum
>         at oracle.jdbc.driver.SQLStateMapping.newSQLException(SQLStateMapping.java:70)
>         at oracle.jdbc.driver.DatabaseError.newSQLException(DatabaseError.java:133)
>         at oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:199)
>         at oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:263)
>         at oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:271)
>         at oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:445)
>         at oracle.jdbc.driver.T4CMAREngine.buffer2Value(T4CMAREngine.java:2253)
>         at oracle.jdbc.driver.T4CMAREngine.unmarshalUB2(T4CMAREngine.java:1101)
>         at oracle.jdbc.driver.T4C8TTIrxh.unmarshalV10(T4C8TTIrxh.java:115)
>         at oracle.jdbc.driver.T4C8Oall.receive(T4C8Oall.java:654)
>         at oracle.jdbc.driver.T4CPreparedStatement.doOall8(T4CPreparedStatement.java:194)
>         at oracle.jdbc.driver.T4CPreparedStatement.executeForDescribe(T4CPreparedStatement.java:791)
>         at oracle.jdbc.driver.T4CPreparedStatement.executeMaybeDescribe(T4CPreparedStatement.java:866)
>         at oracle.jdbc.driver.OracleStatement.doExecuteWithTimeout(OracleStatement.java:1186)
>         at oracle.jdbc.driver.OraclePreparedStatement.executeInternal(OraclePreparedStatement.java:3387)
>         at oracle.jdbc.driver.OraclePreparedStatement.executeQuery(OraclePreparedStatement.java:3431)
>         at oracle.jdbc.driver.OraclePreparedStatementWrapper.executeQuery(OraclePreparedStatementWrapper.java:1491)
>         at org.jboss.resource.adapter.jdbc.WrappedPreparedStatement.executeQuery(WrappedPreparedStatement.java:342)
>         at org.jboss.messaging.core.impl.JDBCPersistenceManager.loadFromStart(JDBCPersistenceManager.java:988)
>         at org.jboss.messaging.core.impl.PagingChannelSupport.load(PagingChannelSupport.java:211)
>         at org.jboss.jms.server.destination.TopicService.startService(TopicService.java:92)
>         at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanSupport.java:376)
>         at org.jboss.system.ServiceMBeanSupport.start(ServiceMBeanSupport.java:269)

--
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

From issues at jboss.org  Thu Mar 13 23:02:17 2014
From: issues at jboss.org (Yong Hao Gao (JIRA))
Date: Thu, 13 Mar 2014 23:02:17 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBMESSAGING-1781) JMS failover recovery
 handling failed on cluster setup when the server running with JBOss + MySQL
 crashes.
In-Reply-To: <JIRA.12401699.1263195377000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12401699.1263195377000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12401699.1263195377000.15617.1394766137607@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBMESSAGING-1781?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Yong Hao Gao updated JBMESSAGING-1781:
--------------------------------------

    Fix Version/s: 1.4.8.SP11
                       (was: 1.4.8.SP10)

    
> JMS failover recovery handling failed on cluster setup when the server running with JBOss + MySQL crashes.
> ----------------------------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1781
>                 URL: https://issues.jboss.org/browse/JBMESSAGING-1781
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: JMS Clustering
>    Affects Versions: 1.4.3.GA
>         Environment: java version "1.6.0_17"
> JBoss version 5.1.0.GA
> Operating System: Solaris & Linux 
>            Reporter: Null Reference
>             Fix For: 1.4.8.SP11
>
>
> JBoss Messaging failover recovery handling failed on cluster setup when the server running with JBOss + MySQL crashes.
> Setup details
> server1: JBoss App server + MySQL 
> server2: JBoss App server
> server1 was crashed for some hardware failure, server2 detects that the server1 leaves the cluster and starts the failover recovery operation, failover 
> recovery involves clean up operation from its local map and database, how ever MySQL is down at this moment so the clean up operation failed with some re-tries.
> Restarting the crashed server does not help to join the existing cluster group, the reason being failover recovery has failed. 
> 009-11-24 21:43:24,101 ERROR [main]-[org.jboss.messaging.util.ExceptionUtil] org.jboss.messaging.core.jmx.MessagingPostOfficeService at 1a67848 startService
> java.lang.IllegalArgumentException: Cannot start post office since there is already a post office in the cluster with the same node id (215). Are you sure 
> you have given each node a unique node id during installation?
> at org.jboss.messaging.core.impl.postoffice.MessagingPostOffice.start(MessagingPostOffice.java:372)
> at org.jboss.messaging.core.jmx.MessagingPostOfficeService.startService(MessagingPostOfficeService.java:462)
> at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanSupport.java:376)
> at org.jboss.system.ServiceMBeanSupport.start(ServiceMBeanSupport.java:269)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:157)
> at org.jboss.mx.server.Invocation.dispatch(Invocation.java:96)
> at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:138)
> at org.jboss.mx.server.Invocation.invoke(Invocation.java:90)
> at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:140)
> at org.jboss.mx.server.Invocation.invoke(Invocation.java:90)
> at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
> at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:668)
> at org.jboss.system.microcontainer.ServiceProxy.invoke(ServiceProxy.java:206)
> at $Proxy38.start(Unknown Source)
> at org.jboss.system.microcontainer.StartStopLifecycleAction.installAction(StartStopLifecycleAction.java:42)
> at org.jboss.system.microcontainer.StartStopLifecycleAction.installAction(StartStopLifecycleAction.java:37)
> at org.jboss.dependency.plugins.action.SimpleControllerContextAction.simpleInstallAction(SimpleControllerContextAction.java:62)
> at org.jboss.dependency.plugins.action.AccessControllerContextAction.install(AccessControllerContextAction.java:71)
> at org.jboss.dependency.plugins.AbstractControllerContextActions.install(AbstractControllerContextActions.java:51)
> at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
> at org.jboss.system.microcontainer.ServiceControllerContext.install(ServiceControllerContext.java:286)
> at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1631)
> at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:934)
> at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1082)
> at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:984)
> at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:822)
> at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
> at org.jboss.system.ServiceController.doChange(ServiceController.java:688)
> at org.jboss.system.ServiceController.start(ServiceController.java:460)
> at org.jboss.system.deployers.ServiceDeployer.start(ServiceDeployer.java:163)
> at org.jboss.system.deployers.ServiceDeployer.deploy(ServiceDeployer.java:99)
> at org.jboss.system.deployers.ServiceDeployer.deploy(ServiceDeployer.java:46)
> at org.jboss.deployers.spi.deployer.helpers.AbstractSimpleRealDeployer.internalDeploy(AbstractSimpleRealDeployer.java:62)
> at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployer.deploy(AbstractRealDeployer.java:50)
> at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:171)
> at org.jboss.deployers.plugins.deployers.DeployersImpl.doDeploy(DeployersImpl.java:1439)
> at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1157)
> at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1178)
> at org.jboss.deployers.plugins.deployers.DeployersImpl.install(DeployersImpl.java:1098)
> at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
> at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1631)
> at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:934)
> at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1082)
> at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:984)
> at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:822)
> at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
> at org.jboss.deployers.plugins.deployers.DeployersImpl.process(DeployersImpl.java:781)
> at org.jboss.deployers.plugins.main.MainDeployerImpl.process(MainDeployerImpl.java:702)
> at org.jboss.system.server.profileservice.repository.MainDeployerAdapter.process(MainDeployerAdapter.java:117)
> at org.jboss.system.server.profileservice.repository.ProfileDeployAction.install(ProfileDeployAction.java:70)
> at org.jboss.system.server.profileservice.repository.AbstractProfileAction.install(AbstractProfileAction.java:53)
> at org.jboss.system.server.profileservice.repository.AbstractProfileService.install(AbstractProfileService.java:361)
> at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
> at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1631)
> at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:934)
> at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1082)
> at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:984)
> at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:822)
> at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
> at org.jboss.system.server.profileservice.repository.AbstractProfileService.activateProfile(AbstractProfileService.java:306)
> at org.jboss.system.server.profileservice.ProfileServiceBootstrap.start(ProfileServiceBootstrap.java:271)
> at org.jboss.bootstrap.AbstractServerImpl.start(AbstractServerImpl.java:461)
> at org.jboss.Main.boot(Main.java:221)
> at org.jboss.Main$1.run(Main.java:556)
> at java.lang.Thread.run(Thread.java:619) 

--
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

From issues at jboss.org  Thu Mar 13 23:02:18 2014
From: issues at jboss.org (Yong Hao Gao (JIRA))
Date: Thu, 13 Mar 2014 23:02:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBMESSAGING-1780) When i change the
 default db schemas of jbm tables the DLQ - if it contains message - run in
 deadlock by the next server restart,
 because it wants to use the default schema instead of the modified db schema
In-Reply-To: <JIRA.12401677.1263157708000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12401677.1263157708000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12401677.1263157708000.15621.1394766138038@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBMESSAGING-1780?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Yong Hao Gao updated JBMESSAGING-1780:
--------------------------------------

    Fix Version/s: 1.4.8.SP11
                       (was: 1.4.8.SP10)

    
> When i change the default db schemas of jbm tables the DLQ - if it contains message -  run in deadlock by the next server restart, because it wants to use the default schema instead of the modified db schema 
> ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1780
>                 URL: https://issues.jboss.org/browse/JBMESSAGING-1780
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 1.4.0.SP3.CP09, 1.4.5.GA, 1.4.6.GA
>         Environment: JBoss 5.1.GA+Seam 2.1.1.GA+mysql 5.1
>            Reporter: bb bb
>            Assignee: Yong Hao Gao
>             Fix For: 1.4.0.SP3.CP15, 1.4.8.SP11
>
>
> At first, I modified the default schema of jbm tables in mysql-persistence-service.xml
> so, I changed the sql properties  JBM_DUAL to  newSchema.JBM_DUAL and so on...
> Everything works fine with the modified schema, until I add a posion message to the dead letter queue.
> Then I want to restart the JBoss server, I get an exception to it run in dead lock, because didn't find the jbm_msg tables (but it would be newSchema.jbm_msg  )

--
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

From issues at jboss.org  Thu Mar 13 23:02:18 2014
From: issues at jboss.org (Yong Hao Gao (JIRA))
Date: Thu, 13 Mar 2014 23:02:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBMESSAGING-1777) Error in
 addMessageIDInHeader while bridging from JBossMQ
In-Reply-To: <JIRA.12400922.1261511098000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12400922.1261511098000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12400922.1261511098000.15624.1394766138262@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBMESSAGING-1777?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Yong Hao Gao updated JBMESSAGING-1777:
--------------------------------------

    Fix Version/s: 1.4.8.SP11
                       (was: 1.4.8.SP10)

    
> Error in addMessageIDInHeader while bridging from JBossMQ
> ---------------------------------------------------------
>
>                 Key: JBMESSAGING-1777
>                 URL: https://issues.jboss.org/browse/JBMESSAGING-1777
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 1.4.3.GA
>         Environment: JBoss AS 5.1.0.GA
>            Reporter: Pedro Gontijo
>            Assignee: Yong Hao Gao
>              Labels: JMSXDeliveryCount, addMessageIDInHeader, bridge, jbossmq
>             Fix For: 1.4.0.SP3.CP15, 1.4.8.SP11
>
>
> When addMessageIDInHeader is set to true in a JBossMQ->JBM bridge scenerio the following error occurs:
> WARN  [org.jboss.jms.server.bridge.Bridge] (Thread-27) jboss.messaging:name=MyBridge,service=Bridge Failed to send + acknowledge batch, closing JMS objects
> javax.jms.JMSException: Illegal property name: JMSXDeliveryCount
> 	at org.jboss.mq.SpyMessage.checkProperty(Unknown Source)
> 	at org.jboss.mq.SpyMessage.setObjectProperty(Unknown Source)
> 	at org.jboss.jms.server.bridge.Bridge.addMessageIDInHeader(Bridge.java:1481)
> 	at org.jboss.jms.server.bridge.Bridge.sendMessages(Bridge.java:1391)
> 	at org.jboss.jms.server.bridge.Bridge.sendBatchNonTransacted(Bridge.java:1261)
> 	at org.jboss.jms.server.bridge.Bridge.sendBatch(Bridge.java:1375)
> 	at org.jboss.jms.server.bridge.Bridge.access$1900(Bridge.java:68)
> 	at org.jboss.jms.server.bridge.Bridge$BatchTimeChecker.run(Bridge.java:1638)
> 	at java.lang.Thread.run(Thread.java:595)
> As you can see the error is due JMSX properties, actually, because the addMessageIDInHeader sets then in the MQ message (which is not allowed).

--
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

From issues at jboss.org  Thu Mar 13 23:02:18 2014
From: issues at jboss.org (Yong Hao Gao (JIRA))
Date: Thu, 13 Mar 2014 23:02:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBMESSAGING-1763) Bisocket connection
 won't be closed if pulling out the ethernet cable between client and
 server. The failure detection code won't close the failure connection,
 as a result,
 the subsequent requests will hang after connection account exceeds the
 threshold
In-Reply-To: <JIRA.12398397.1258620828000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12398397.1258620828000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12398397.1258620828000.15629.1394766138594@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBMESSAGING-1763?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Yong Hao Gao updated JBMESSAGING-1763:
--------------------------------------

    Fix Version/s: 1.4.8.SP11
                       (was: 1.4.8.SP10)

    
> Bisocket connection won't be closed if pulling out the ethernet cable between client and server. The failure detection code won't close the failure connection, as a result, the subsequent requests will hang after connection account exceeds the threshold
> -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1763
>                 URL: https://issues.jboss.org/browse/JBMESSAGING-1763
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: JMS Remoting
>    Affects Versions: 1.4.5.GA, 1.4.6.GA
>         Environment: OS: Windows Server 2003. JBoss App Server 4.2.3.GA, JBoss Messaging 1.4.5 GA, JBoss Remoting 2.2.3 SP1 
>            Reporter: mingjun jiang
>            Assignee: Yong Hao Gao
>              Labels: Failure, are, be, by, cable, caused, closed, connection, ethernet, if, manually, out, pulling, they, won't
>             Fix For: 1.4.8.SP11
>
>         Attachments: jboss-test-log  for JBM1.4.5 & Remoting 2.2.3 SP1.zip, QReceiver.java, QSender.java, remoting-bisocket-service.xml
>
>
> We are using JBoss App Server 4.2.3.GA, JBoss Messaging 1.4.5 GA and JBoss Remoting 2.2.3 SP1. In our application, there are a lot of Message listeners running on the client side, these message listeners will receive messages from queue/topic deployed in JBoss Messaging 
> Configuration: 
> We created our own JMS Connection factory which uses the default remoting connector. As you know, the default remoting connector is configured to use the bisocket transport. We didn't change the default value of the remoting connector 
> During we run our application, we open the JBoss web console to monitor the value of currentClientPoolSize under "Jboss.remoting" JMX MBean. 
>   
> How to reproduce this issue: 
> 1. Run 5 message listeners in the client side to receive messages from JBoss Messaging, then we observe the value of currentClientPoolSize is 10 
> 2. After processing several messages, we manually pull out the ethernet cable. The value of currentClientPoolSize is still 10. 
> 3. We run another 5 message listeners in client side, then the value of currentClientPoolSize will become 20 
> 4. After we do the same operations above several times, the value of currentClientPoolSize will increase continuously. Once the value of currentClientPoolSize is equal to the MaxPoolSize, then the subsequent incoming client requests will hang, and we will encounter the following exception in server side 
>        2009-10-20 18:08:09,655 ERROR [org.jboss.remoting.transport.socket.ServerThread] Worker thread initialization failure 
> java.net.SocketException: Connection reset 
>       at java.net.SocketInputStream.read(SocketInputStream.java:168) 
>       at java.io.BufferedInputStream.fill(BufferedInputStream.java:218) 
>       at java.io.BufferedInputStream.read(BufferedInputStream.java:235) 
>       at java.io.FilterInputStream.read(FilterInputStream.java:66) 
>       at org.jboss.remoting.transport.socket.ServerThread.readVersion(ServerThread.java:859) 
>       at org.jboss.remoting.transport.socket.ServerThread.processInvocation(ServerThread.java:545) 
>       at org.jboss.remoting.transport.socket.ServerThread.dorun(ServerThread.java:406) 
>       at org.jboss.remoting.transport.socket.ServerThread.run(ServerThread.java:173) 
> Conclusion: JBoss Messaging won't close the failure connections if they are caused by manually pulling out ethernet cable. As a result, the value of currentClientPoolSize will increase continuously and finally the new client requests will hang 
> Note: If we killed the process of message listener in client side, then the value of currentClientPoolSize will decrease to 0 immediately, it seems that the server could detect the failure connection and perform the corresponding resource releasing. 

--
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

From issues at jboss.org  Thu Mar 13 23:02:18 2014
From: issues at jboss.org (Yong Hao Gao (JIRA))
Date: Thu, 13 Mar 2014 23:02:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBMESSAGING-1761) H2 support
In-Reply-To: <JIRA.12398141.1258377169000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12398141.1258377169000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12398141.1258377169000.15633.1394766138805@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBMESSAGING-1761?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Yong Hao Gao updated JBMESSAGING-1761:
--------------------------------------

    Fix Version/s: 1.4.8.SP11
                       (was: 1.4.8.SP10)

    
> H2 support
> ----------
>
>                 Key: JBMESSAGING-1761
>                 URL: https://issues.jboss.org/browse/JBMESSAGING-1761
>             Project: JBoss Messaging
>          Issue Type: Feature Request
>          Components: Configuration and Management
>    Affects Versions: 1.4.3.GA
>            Reporter: Jesper Pedersen
>            Assignee: Yong Hao Gao
>             Fix For: 1.4.0.SP3.CP15, 1.4.8.SP11
>
>
> In order for the application server to support H2 as the default database we need the necessary persistence-service.xml files.
> H2: http://www.h2database.com/html/main.html
> Please update Branch_5_x and trunk when released.

--
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

From issues at jboss.org  Thu Mar 13 23:02:19 2014
From: issues at jboss.org (Yong Hao Gao (JIRA))
Date: Thu, 13 Mar 2014 23:02:19 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBMESSAGING-1759) JGroups cannot process
 incoming messages during the method execution
In-Reply-To: <JIRA.12397969.1258090254000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12397969.1258090254000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12397969.1258090254000.15639.1394766139222@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBMESSAGING-1759?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Yong Hao Gao updated JBMESSAGING-1759:
--------------------------------------

    Fix Version/s: 1.4.8.SP11
                       (was: 1.4.8.SP10)

    
> JGroups cannot process incoming messages during the method execution
> --------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1759
>                 URL: https://issues.jboss.org/browse/JBMESSAGING-1759
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: JMS Clustering
>    Affects Versions: 1.4.0.SP3.CP07
>         Environment: JBossMessaging-1.4.0_SP3_CP7
>            Reporter: Tyronne Wickramarathne
>            Assignee: Yong Hao Gao
>            Priority: Critical
>             Fix For: 1.4.0.SP3.CP15, 1.4.8.SP11
>
>
> The GroupMember#viewAccepted() takes 31min on the IncomingPacketHandler thread. The JGroups cannot process incoming messages during this method execution. It's completely blocked and leads the following log and subsequent WARNs.
>  2009-11-11 11:50:12.634 [ViewHandler]  WARN [GMS] - failed to collect all ACKs (1) for view [192.168.1.221:49898|2] [192.168.1.221:49898] after 2000ms, missing ACKs from [192.168.1.221:49898] (received=[]), local_addr=192.168.1.221:49898

--
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

From issues at jboss.org  Thu Mar 13 23:02:19 2014
From: issues at jboss.org (Yong Hao Gao (JIRA))
Date: Thu, 13 Mar 2014 23:02:19 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBMESSAGING-1758) Derby support
In-Reply-To: <JIRA.12397921.1258040162000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12397921.1258040162000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12397921.1258040162000.15643.1394766139557@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBMESSAGING-1758?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Yong Hao Gao updated JBMESSAGING-1758:
--------------------------------------

    Fix Version/s: 1.4.8.SP11
                       (was: 1.4.8.SP10)

    
> Derby support
> -------------
>
>                 Key: JBMESSAGING-1758
>                 URL: https://issues.jboss.org/browse/JBMESSAGING-1758
>             Project: JBoss Messaging
>          Issue Type: Feature Request
>          Components: Configuration and Management
>    Affects Versions: 1.4.3.GA
>            Reporter: Jesper Pedersen
>            Assignee: Yong Hao Gao
>             Fix For: 1.4.8.SP11
>
>
> In order for the application server to support Derby as the default database we need the necessary persistence-service.xml files.
> Please update Branch_5_x and trunk when released.

--
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

From issues at jboss.org  Thu Mar 13 23:02:19 2014
From: issues at jboss.org (Yong Hao Gao (JIRA))
Date: Thu, 13 Mar 2014 23:02:19 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBMESSAGING-1754) Implement the JBossMQ
 behavior on JBM, when stopDelivery() is invoked via JMX console
In-Reply-To: <JIRA.12396826.1256800549000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12396826.1256800549000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12396826.1256800549000.15647.1394766139950@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBMESSAGING-1754?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Yong Hao Gao updated JBMESSAGING-1754:
--------------------------------------

    Fix Version/s: 1.4.8.SP11
                       (was: 1.4.8.SP10)

    
> Implement the JBossMQ behavior on JBM, when stopDelivery() is invoked via JMX console
> -------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1754
>                 URL: https://issues.jboss.org/browse/JBMESSAGING-1754
>             Project: JBoss Messaging
>          Issue Type: Feature Request
>          Components: Messaging Core
>    Affects Versions: 1.4.0.SP3.CP08
>         Environment: JBoss-EAP-4.3_CP6, JBM-1.4.0-SP3_CP8P1 
>            Reporter: Tyronne Wickramarathne
>            Assignee: Yong Hao Gao
>             Fix For: 1.4.0.SP3.CP15, 1.4.8.SP11
>
>
> When stopDelivery() is invoked via JMX console for any given MDB, the in process messages are rolled back to their corresponding destination without completing the process. This is however *not* a bug, but the expected behavior in JBM, for this is how it has defined the behavior of stopDelivery(). 
> However on JBossMQ, the in process messages are completed at first, before stopDelivery() is processed. Which means, the call made via stopDelivery() will be kept on hold, until all in process messages are successfully completed. The customers migrating from JBossMQ are seeing this as a compatibility issue, when porting their applications to work on JBM. Hence, would it be possible to accommodate the behavior seen in JBossMQ on JBM please ?
> I have tested this on both JBoss-EAP-4.3_CP6 as well as on JBoss-EAP-4.2_CP7. Both have the same code base for EJB3,JCA but not the JMS provider. Therefore, I'm raising this feature request under JBM.

--
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

From issues at jboss.org  Thu Mar 13 23:02:20 2014
From: issues at jboss.org (Yong Hao Gao (JIRA))
Date: Thu, 13 Mar 2014 23:02:20 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBMESSAGING-1750) Allow arbitrary SQL
 statements for JDBCPersistenceManagerService
In-Reply-To: <JIRA.12396620.1256620011000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12396620.1256620011000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12396620.1256620011000.15651.1394766140307@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBMESSAGING-1750?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Yong Hao Gao updated JBMESSAGING-1750:
--------------------------------------

    Fix Version/s: 1.4.8.SP11
                       (was: 1.4.8.SP10)

    
> Allow arbitrary SQL statements for JDBCPersistenceManagerService
> ----------------------------------------------------------------
>
>                 Key: JBMESSAGING-1750
>                 URL: https://issues.jboss.org/browse/JBMESSAGING-1750
>             Project: JBoss Messaging
>          Issue Type: Feature Request
>          Components: Configuration and Management
>    Affects Versions: 1.4.0.SP3.CP08
>            Reporter: Justin Bertram
>            Assignee: Yong Hao Gao
>             Fix For: 1.4.0.SP3.CP15, 1.4.8.SP11
>
>
> Allow arbitrary SQL statements in the SQLProperties field of org.jboss.messaging.core.jmx.JDBCPersistenceManagerService which will be executed just like all the others (e.g. if CreateTablesOnStartup = "true").  I imagine the statements will need to be named according to some pattern (e.g. "CREATE_*").  
> This functionality will allow greater flexibility for our RDBMS support (e.g. a user could configure support for Oracle TimesTen).

--
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

From issues at jboss.org  Thu Mar 13 23:02:20 2014
From: issues at jboss.org (Yong Hao Gao (JIRA))
Date: Thu, 13 Mar 2014 23:02:20 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBMESSAGING-1747) ClassNotFoundException
 while consuming a message in a JMS Queue
In-Reply-To: <JIRA.12396118.1256073080000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12396118.1256073080000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12396118.1256073080000.15655.1394766140561@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBMESSAGING-1747?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Yong Hao Gao updated JBMESSAGING-1747:
--------------------------------------

    Fix Version/s: 1.4.8.SP11
                       (was: 1.4.8.SP10)

    
> ClassNotFoundException while consuming a message in a JMS Queue
> ---------------------------------------------------------------
>
>                 Key: JBMESSAGING-1747
>                 URL: https://issues.jboss.org/browse/JBMESSAGING-1747
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: JMS Destination Manager
>    Affects Versions: 1.4.1.GA
>         Environment: Jboss version : 5.0.1 GA
>            Reporter: Stephan Lagraulet
>            Assignee: Yong Hao Gao
>             Fix For: 1.4.0.SP3.CP15, 1.4.8.SP11
>
>
> We have several JMS queues setup on our jboss server.
> We are using spring to handle the messages.
> When several clients simultaneously post some messages in different queues, the consumer doesn't find the class for the task, ending with this stack trace:
> 2009-07-28 17:10:21,089  WARN [SimpleMessageListenerContainer] [] - Execution of JMS message listener failed
> java.lang.RuntimeException: fr.billetel.interfaces.ws.allotement.business.etatventes.request.CodificationsTaskRequest
>         at java.net.URLClassLoader$1.run(URLClassLoader.java:200)
>         at java.security.AccessController.doPrivileged(Native Method)
>         at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
>         at java.lang.ClassLoader.loadClass(ClassLoader.java:307)
>         at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301)
>         at java.lang.ClassLoader.loadClass(ClassLoader.java:252)
>         at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:320)
>         at java.lang.Class.forName0(Native Method)
>         at java.lang.Class.forName(Class.java:247)
>         at org.jboss.classloader.spi.base.BaseClassLoaderDomain.loadClass(BaseClassLoaderDomain.java:279)
>         at org.jboss.classloader.spi.base.BaseClassLoaderDomain.loadClass(BaseClassLoaderDomain.java:1102)
>         at org.jboss.classloader.spi.base.BaseClassLoader.loadClassFromDomain(BaseClassLoader.java:772)
>         at org.jboss.classloader.spi.base.BaseClassLoader.loadClass(BaseClassLoader.java:415)
>         at java.lang.ClassLoader.loadClass(ClassLoader.java:252)
>         at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:320)
> We debugged the class org.jboss.messaging.util.OrderedExecutorFactory, and it appears that the class doesn't have the right classloader as it reuses a thread previously setup with an other classloader (the application is packaged in different ears while the queues are defined in deploy), ending in this exception.
> For the moment, we patched the code so that the classloader is reloaded for every call, but it does not seem like a good solution on a long term.

--
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

From issues at jboss.org  Thu Mar 13 23:02:20 2014
From: issues at jboss.org (Yong Hao Gao (JIRA))
Date: Thu, 13 Mar 2014 23:02:20 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBMESSAGING-1744) More documented
 warnings on the usage of JMS selectors
In-Reply-To: <JIRA.12395733.1255528326000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12395733.1255528326000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12395733.1255528326000.15659.1394766140815@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBMESSAGING-1744?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Yong Hao Gao updated JBMESSAGING-1744:
--------------------------------------

    Fix Version/s: 1.4.8.SP11
                       (was: 1.4.8.SP10)

    
> More documented warnings on the usage of JMS selectors
> ------------------------------------------------------
>
>                 Key: JBMESSAGING-1744
>                 URL: https://issues.jboss.org/browse/JBMESSAGING-1744
>             Project: JBoss Messaging
>          Issue Type: Task
>          Components: Documentation and Training
>    Affects Versions: 1.4.0.SP3.CP08, 1.4.0.SP3.CP09, 1.4.5.GA
>         Environment: EAP 4.3 CP06 / 1.4.0.SP3-CP08.patch01
>            Reporter: Noel Rocher
>            Assignee: Yong Hao Gao
>             Fix For: 1.4.0.SP3.CP15, 1.4.8.SP11
>
>
> I'm on-site with a customer who is soon going to production.
> They have designed their application using JMS Selectors on distributed queues.
> We all know this is a broken design but my point is that I think this should be explicitely written in the doc.
> Moreover, GSS is talking about an "unsupported configuration" see case # 348290  (https://enterprise.redhat.com/issue-tracker/?module=issues&action=view&tid=348290). 

--
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

From issues at jboss.org  Thu Mar 13 23:02:20 2014
From: issues at jboss.org (Yong Hao Gao (JIRA))
Date: Thu, 13 Mar 2014 23:02:20 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBMESSAGING-1739) Update to JGroup 2.8
In-Reply-To: <JIRA.12394710.1254132263000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12394710.1254132263000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12394710.1254132263000.15662.1394766140981@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBMESSAGING-1739?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Yong Hao Gao updated JBMESSAGING-1739:
--------------------------------------

    Fix Version/s: 1.4.8.SP11
                       (was: 1.4.8.SP10)

    
> Update to JGroup 2.8
> --------------------
>
>                 Key: JBMESSAGING-1739
>                 URL: https://issues.jboss.org/browse/JBMESSAGING-1739
>             Project: JBoss Messaging
>          Issue Type: Feature Request
>          Components: AS Integration
>    Affects Versions: 1.4.4.GA
>            Reporter: Yong Hao Gao
>            Assignee: Yong Hao Gao
>             Fix For: 1.4.8.SP11
>
>
> Also this thread
> http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4257080#4257080

--
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

From issues at jboss.org  Thu Mar 13 23:02:21 2014
From: issues at jboss.org (Yong Hao Gao (JIRA))
Date: Thu, 13 Mar 2014 23:02:21 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBMESSAGING-1735) Paging should be taken
 care in Transactions
In-Reply-To: <JIRA.12394113.1253096562000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12394113.1253096562000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12394113.1253096562000.15665.1394766141172@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBMESSAGING-1735?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Yong Hao Gao updated JBMESSAGING-1735:
--------------------------------------

    Fix Version/s: 1.4.8.SP11
                       (was: 1.4.8.SP10)

    
> Paging should be taken care in Transactions
> -------------------------------------------
>
>                 Key: JBMESSAGING-1735
>                 URL: https://issues.jboss.org/browse/JBMESSAGING-1735
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 1.4.0.SP3.CP08, 1.4.4.GA
>            Reporter: Yong Hao Gao
>            Assignee: Yong Hao Gao
>             Fix For: 1.4.0.SP3.CP15, 1.4.8.SP11
>
>
> JBM queues has paging feature to save memory, but in transaction case, messages are stored in the transaction callbacks before it committed to the queue for delivery. So if too many messages are included in one transaction, it may use up memory even paging is turned on.

--
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

From issues at jboss.org  Thu Mar 13 23:02:21 2014
From: issues at jboss.org (Yong Hao Gao (JIRA))
Date: Thu, 13 Mar 2014 23:02:21 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBMESSAGING-1731) Expose the JBoss
 Messaging Cluster partition in JMX
In-Reply-To: <JIRA.12393375.1251992073000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12393375.1251992073000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12393375.1251992073000.15670.1394766141434@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBMESSAGING-1731?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Yong Hao Gao updated JBMESSAGING-1731:
--------------------------------------

    Fix Version/s: 1.4.8.SP11
                       (was: 1.4.8.SP10)

    
> Expose the JBoss Messaging Cluster partition in JMX
> ---------------------------------------------------
>
>                 Key: JBMESSAGING-1731
>                 URL: https://issues.jboss.org/browse/JBMESSAGING-1731
>             Project: JBoss Messaging
>          Issue Type: Feature Request
>          Components: Messaging Core
>    Affects Versions: 1.4.4.GA
>            Reporter: Brad Maxwell
>            Assignee: Yong Hao Gao
>             Fix For: 1.4.0.SP3.CP15, 1.4.8.SP11
>
>
> Background:
> I have had a request wanting access to the members of the JBoss Messaging Cluster so that they can configure the Recovery plugin without having to hard code hosts in the configuration file.  With the JBoss Messaging Cluster Partition in JMX they would be able to get an accurate list of the members in the Messaging cluster.

--
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

From issues at jboss.org  Thu Mar 13 23:02:21 2014
From: issues at jboss.org (Yong Hao Gao (JIRA))
Date: Thu, 13 Mar 2014 23:02:21 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBMESSAGING-1723) Queue's delivering
	count == -1
In-Reply-To: <JIRA.12392661.1251244233000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12392661.1251244233000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12392661.1251244233000.15674.1394766141818@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBMESSAGING-1723?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Yong Hao Gao updated JBMESSAGING-1723:
--------------------------------------

    Fix Version/s: 1.4.8.SP11
                       (was: 1.4.8.SP10)

    
> Queue's delivering count == -1
> ------------------------------
>
>                 Key: JBMESSAGING-1723
>                 URL: https://issues.jboss.org/browse/JBMESSAGING-1723
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Messaging Core
>    Affects Versions: 1.4.3.GA
>            Reporter: Ondrej Zizka
>            Assignee: Yong Hao Gao
>            Priority: Minor
>             Fix For: 1.4.0.SP3.CP15, 1.4.8.SP11
>
>         Attachments: JMS_delivCount_-1.png
>
>
> Delivery count of a queue is sometimes -1. See the picture attached.
> Seen on EAP 5 CR3, Sun JDK 6 for Linux.
> Steps to reproduce:
> 1) Start a client sending messages,
> 2) Start a client receiving messages,
> 3) Watch the stats. If you're lucky enough, you'll see it being -1.
> I haven't found anything about this in the docs:
> http://labs.jboss.com/file-access/default/members/jbossmessaging/freezone/docs/userguide-1.4.4.GA/html/configuration.html#conf.serverpeer.attributes.messagecounters  ( 6.6.2.1 )

--
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

From issues at jboss.org  Thu Mar 13 23:02:22 2014
From: issues at jboss.org (Yong Hao Gao (JIRA))
Date: Thu, 13 Mar 2014 23:02:22 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBMESSAGING-1718) JMS Queue MessageCount
 attribute isn't increased on message retrieval
In-Reply-To: <JIRA.12392219.1250684699000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12392219.1250684699000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12392219.1250684699000.15678.1394766142127@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBMESSAGING-1718?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Yong Hao Gao updated JBMESSAGING-1718:
--------------------------------------

    Fix Version/s: 1.4.8.SP11
                       (was: 1.4.8.SP10)

    
> JMS Queue MessageCount attribute isn't increased on message retrieval
> ---------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1718
>                 URL: https://issues.jboss.org/browse/JBMESSAGING-1718
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 1.4.3.GA
>            Reporter: Richard Opalka
>            Assignee: Yong Hao Gao
>             Fix For: 1.4.8.SP11
>
>         Attachments: jaxws-samples-dar-jms-client.sar, jaxws-samples-dar-jms.jar
>
>
> We're sending JMS message to the queue and are verifying it was received by checking the JMS Queue MessageCount attribute.
> This used to work on AS 500, AS 501 and AS 510 but doesn't work on AS trunk and AS Branch_5_x.

--
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

From issues at jboss.org  Thu Mar 13 23:02:22 2014
From: issues at jboss.org (Yong Hao Gao (JIRA))
Date: Thu, 13 Mar 2014 23:02:22 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBMESSAGING-1707)
 ConcurrentModificationException in ClientClusteredConnectionFactoryDelegate
In-Reply-To: <JIRA.12391575.1249981118000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12391575.1249981118000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12391575.1249981118000.15682.1394766142426@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBMESSAGING-1707?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Yong Hao Gao updated JBMESSAGING-1707:
--------------------------------------

    Fix Version/s: 1.4.8.SP11
                       (was: 1.4.8.SP10)

    
> ConcurrentModificationException in ClientClusteredConnectionFactoryDelegate
> ---------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1707
>                 URL: https://issues.jboss.org/browse/JBMESSAGING-1707
>             Project: JBoss Messaging
>          Issue Type: Quality Risk
>          Components: JMS Client Manager
>    Affects Versions: 1.4.3.GA
>            Reporter: Pavel Slavicek
>            Assignee: Clebert Suconic
>             Fix For: 1.4.0.SP3.CP15, 1.4.8.SP11
>
>
> I have found ConcurrentModificationException in ClientClusteredConnectionFactoryDelegate.
> Exception in thread "Thread-11" java.util.ConcurrentModificationException
> 	at java.util.WeakHashMap$HashIterator.nextEntry(WeakHashMap.java:784)
> 	at java.util.WeakHashMap$KeyIterator.next(WeakHashMap.java:817)
> 	at org.jboss.jms.client.delegate.ClientClusteredConnectionFactoryDelegate$FinalizerShutdownHook.run(ClientClusteredConnectionFactoryDelegate.java:414)
> Client:
> client with multiple threads, every thread creates-sends-receives-closes. 
> Problem description:
> Problem is in the ClientClusteredConnectionFactoryDelegate.java in the inner class FinalizerShutdownHook.
> Shutdown hook implementation should to be written as thread safe (see javadoc for addShutdownHook() method). 
> Method run() in the FinalizerShutdownHook class iterates over all elements in the registered delegates 
> but this iteration should be synchronized on the delegates object. 
> Please see http://java.sun.com/javase/6/docs/api/java/util/Collections.html#synchronizedSet%28java.util.Set%29

--
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

From issues at jboss.org  Thu Mar 13 23:02:22 2014
From: issues at jboss.org (Yong Hao Gao (JIRA))
Date: Thu, 13 Mar 2014 23:02:22 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBMESSAGING-1706) JBoss Messaging
 sometimes causes a HeuristicMixedException
In-Reply-To: <JIRA.12391486.1249897294000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12391486.1249897294000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12391486.1249897294000.15690.1394766142875@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBMESSAGING-1706?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Yong Hao Gao updated JBMESSAGING-1706:
--------------------------------------

    Fix Version/s: 1.4.8.SP11
                       (was: 1.4.8.SP10)

    
> JBoss Messaging sometimes causes a HeuristicMixedException
> ----------------------------------------------------------
>
>                 Key: JBMESSAGING-1706
>                 URL: https://issues.jboss.org/browse/JBMESSAGING-1706
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: JMS Clustering
>    Affects Versions: 1.4.4.GA
>            Reporter: Richard Kennard
>            Assignee: Yong Hao Gao
>             Fix For: 1.4.0.SP3.CP15, 1.4.8.SP11
>
>         Attachments: Client_Logs.txt, JBOSS_Server_Logs.txt, remoting-bisocket-service.xml, server.zip
>
>
> I am raising this JIRA to ask the JBoss Messaging Team to take ownership of this issue.
> The issue is that JBM intermittently (ie. when processing large amounts of messages, when bringing up/shutting down nodes in a cluster) throws a HeuristicMixedException. Once it does, that node in the cluster is effectively dead. No more messages get processed. My app has multiple queues, but once one queue on the node fails (say, the e-mail queue) then all queues stop working (say, the reports queues): they all report HeuristicMixedException whenever a messages is sent to them.
> I am using a workaround by having a separate monitoring program that reboots the node whenever it gets stuck in this HeuristicMixedException state.
> The JBoss ESB team have also had to implement a workaround: https://jira.jboss.org/jira/browse/JBESB-2484
> Others on the forum are seeing this too: http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4241134#4241134
> According to Kevin Conner of the ESB team, Howard worked with them on a workaround: https://jira.jboss.org/jira/browse/JBPAPP-1642, but the issue persists.

--
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

From issues at jboss.org  Thu Mar 13 23:02:23 2014
From: issues at jboss.org (Yong Hao Gao (JIRA))
Date: Thu, 13 Mar 2014 23:02:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBMESSAGING-1684) Message remain in the
 queue and do not get dispatched
In-Reply-To: <JIRA.12389860.1247553585000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12389860.1247553585000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12389860.1247553585000.15695.1394766143223@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBMESSAGING-1684?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Yong Hao Gao updated JBMESSAGING-1684:
--------------------------------------

    Fix Version/s: 1.4.8.SP11
                       (was: 1.4.8.SP10)

    
> Message remain in the queue and do not get dispatched
> -----------------------------------------------------
>
>                 Key: JBMESSAGING-1684
>                 URL: https://issues.jboss.org/browse/JBMESSAGING-1684
>             Project: JBoss Messaging
>          Issue Type: Quality Risk
>          Components: JMS Facade
>    Affects Versions: 1.4.3.GA
>         Environment: SuSe Linux Enterprise Server 10, Java 1.5.0_11, AS 5 with JBoss Messaging - default installation
>            Reporter: Alexander Marktl
>            Assignee: Yong Hao Gao
>            Priority: Minor
>             Fix For: 1.4.0.SP3.CP15, 1.4.8.SP11
>
>         Attachments: jms-provider-evaluation.zip
>
>
> I tried to create 10 queues and send 10.000 messages per queue from a single producer per queue to a single consumer per queue. Unfortunately  not all of the messages where delivered, some messages remain in the queues and wait for delivery. The JMX console for example states: 3 messages in the queue, 3 messages pending for delivery. But nothing happens. My receivers don't get these last messages. I don't know if this is a configuration issue or a bug. 
> The queues are named: qname_0 ...qname_n

--
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

From issues at jboss.org  Thu Mar 13 23:02:23 2014
From: issues at jboss.org (Yong Hao Gao (JIRA))
Date: Thu, 13 Mar 2014 23:02:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBMESSAGING-1661) Messages in JBoss 5.1
 that use bridging get stuck in a devlivering mode and are not sent to the
 remote cluster
In-Reply-To: <JIRA.12388472.1245359280000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12388472.1245359280000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12388472.1245359280000.15699.1394766143579@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBMESSAGING-1661?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Yong Hao Gao updated JBMESSAGING-1661:
--------------------------------------

    Fix Version/s: 1.4.8.SP11
                       (was: 1.4.8.SP10)

    
> Messages in JBoss 5.1 that use bridging get stuck in a devlivering mode and are not sent to the remote cluster
> --------------------------------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1661
>                 URL: https://issues.jboss.org/browse/JBMESSAGING-1661
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 1.4.3.GA
>         Environment: Linux -- JBoss 5.1 GA / JBM 1.4.3GA / Remoting 2.5.1
>            Reporter: Peter Crossley
>            Assignee: Yong Hao Gao
>             Fix For: 1.4.8.SP11
>
>
> A Message bridge between to clusters will get in to a state where the messages will not be picked up by the bridge on the topic/queue and remain in the "delivering" counter until the bridge is restarted via the JMX console or by restarting the Jboss instance.
> I attempted to use JBM 1.4.4 which has a fix (JBMESSAGING-1456) that seems to be the same issue, though do to the difference in the remoting I cannot use the 1.4.4 GA release.
> Can we get the fixes that were applied to the 1.4.4 release in a usable build for JBoss AS 5.1

--
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

From issues at jboss.org  Thu Mar 13 23:02:23 2014
From: issues at jboss.org (Yong Hao Gao (JIRA))
Date: Thu, 13 Mar 2014 23:02:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBMESSAGING-1648) Bridge may stop
 working after long time idle
In-Reply-To: <JIRA.12387929.1244716486000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12387929.1244716486000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12387929.1244716486000.15703.1394766143829@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBMESSAGING-1648?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Yong Hao Gao updated JBMESSAGING-1648:
--------------------------------------

    Fix Version/s: 1.4.8.SP11
                       (was: 1.4.8.SP10)

    
> Bridge may stop working after long time idle
> --------------------------------------------
>
>                 Key: JBMESSAGING-1648
>                 URL: https://issues.jboss.org/browse/JBMESSAGING-1648
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: JMS Facade
>    Affects Versions: 1.4.3.GA
>            Reporter: Yong Hao Gao
>            Assignee: Yong Hao Gao
>             Fix For: 1.4.8.SP11
>
>
> Bridge service may stop working after a long time idle

--
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

From issues at jboss.org  Thu Mar 13 23:02:24 2014
From: issues at jboss.org (Yong Hao Gao (JIRA))
Date: Thu, 13 Mar 2014 23:02:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBMESSAGING-1631) Messages are piling up
 in the queues in clustered environment and not pulled by message sucker
In-Reply-To: <JIRA.12386772.1242929972000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12386772.1242929972000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12386772.1242929972000.15711.1394766144610@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBMESSAGING-1631?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Yong Hao Gao updated JBMESSAGING-1631:
--------------------------------------

    Fix Version/s: 1.4.8.SP11
                       (was: 1.4.8.SP10)

    
> Messages are piling up in the queues in clustered environment and not pulled by message sucker
> ----------------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1631
>                 URL: https://issues.jboss.org/browse/JBMESSAGING-1631
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: JMS Clustering
>    Affects Versions: 1.4.0.SP3.CP08
>         Environment: Cluster of a few JBoss 4.2.3 servers with JBM 1.4.2.GA-SP1 or 1.4.0.SP3_CP08 running on x64 windows servers.
> JBoss Remoting 2.5.1 or 2.2.3
> Clustered XA connection factory, clustered queues, both server and client (MDBs) are deployed as one application - identical deployment for all servers in a cluster
>            Reporter: Victor Starenky
>            Assignee: Yong Hao Gao
>             Fix For: 1.4.0.SP3.CP15, 1.4.8.SP11
>
>         Attachments: 1631-test-source.zip, logs-and-config-prod.zip, logs-and-config-test.zip, TestRecommendationSentProcessorMDB.java
>
>
> We have an EJB3 application is running on a cluster of 7 servers. 
> All servers have the same application farmed across them. 
> We have a clustered queue and using clustered connection factory.
> Originally we ran into the bug JBMESSAGING-1456 and while testing the fix ran into a different problem. After the cluster was running for some time (usually overnight with lots of heavy background processing hapenning at that time) we see messages are "piling up" in some queues on some nodes.
> Sympthoms are:
> MessageCount is not zero (rather in the order of hundreeds), DeliveringCount is zero. These nodes have ConsumerCount=0 for the queues experiencing the problem. Message sucker is configured as far as I can tell. Looks like the problem might be related to client and/or server failover leaving some nodes without consumers while sucker not doing it's job (if I understand it correctly). 
> Once we bump the timeout values much higher than they are in the original config files the problem seems to disappear or at least show up much less frequently. Specifically I'm talking about these values:
> messaging-service.xml:
>       <attribute name="FailoverStartTimeout">180000</attribute>
> remoting-bisocket-service.xml:
>                <attribute name="clientLeasePeriod" isParam="true">30000</attribute>
>                <attribute name="validatorPingPeriod" isParam="true">30000</attribute>
>                <attribute name="validatorPingTimeout" isParam="true">20000</attribute>
>                <attribute name="registerCallbackListener">false</attribute>
>                <attribute name="timeout" isParam="true">240000</attribute>
> While this serves as a temporary workaround we don't feel we can rely on JBM in a production clustered environment without having failover working properly.
> This is a big showstopper for us at the moment.
> Attached are the log files from the prod environment of 7 servers with the config files as well as log files from the test environment with just 2 servers (having same issue) and corresponding configs. The logs were produced by the test version of the messaging code with added logging as per JBMESSAGING-1456.

--
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

From issues at jboss.org  Thu Mar 13 23:02:24 2014
From: issues at jboss.org (Yong Hao Gao (JIRA))
Date: Thu, 13 Mar 2014 23:02:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBMESSAGING-1621) Provide complete
 message ordering in a clustered environment
In-Reply-To: <JIRA.12385994.1242110188000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12385994.1242110188000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12385994.1242110188000.15715.1394766144907@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBMESSAGING-1621?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Yong Hao Gao updated JBMESSAGING-1621:
--------------------------------------

    Fix Version/s: 1.4.8.SP11
                       (was: 1.4.8.SP10)

    
> Provide complete message ordering in a clustered environment
> ------------------------------------------------------------
>
>                 Key: JBMESSAGING-1621
>                 URL: https://issues.jboss.org/browse/JBMESSAGING-1621
>             Project: JBoss Messaging
>          Issue Type: Feature Request
>          Components: JMS Clustering
>    Affects Versions: 1.4.0.SP3.CP08, 1.4.4.GA
>            Reporter: Yusuke Yamamoto
>            Assignee: Yong Hao Gao
>             Fix For: 1.4.0.SP3.CP15, 1.4.8.SP11
>
>
> While JBMESSAGING-1416 states message ordering feature in a singleton configuration, customer is also requesting a complete message ordering feature which is applicable in a clustered environment.
> Here's the background:
> In the case JMS is used, both performance and scalability are priority.
> There is a conflict between scalable JMS implementation and complete message ordering feature since order aware messages cannot be processed concurrently.
> But order unaware queues should be still processed in parallel for better throughput.
> Additionally, there are some cases that no downtime is acceptable. But HA-Singleton requires certain amount of time to fail-over the service to other node.

--
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

From issues at jboss.org  Thu Mar 13 23:02:25 2014
From: issues at jboss.org (Yong Hao Gao (JIRA))
Date: Thu, 13 Mar 2014 23:02:25 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBMESSAGING-1619) add example TCP
 cluster configuration
In-Reply-To: <JIRA.12385701.1241645699000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12385701.1241645699000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12385701.1241645699000.15721.1394766145244@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBMESSAGING-1619?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Yong Hao Gao updated JBMESSAGING-1619:
--------------------------------------

    Fix Version/s: 1.4.8.SP11
                       (was: 1.4.8.SP10)

    
> add example TCP cluster configuration
> -------------------------------------
>
>                 Key: JBMESSAGING-1619
>                 URL: https://issues.jboss.org/browse/JBMESSAGING-1619
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: JMS Clustering
>    Affects Versions: 1.4.0.SP3.CP07
>            Reporter: Dennis Reed
>            Assignee: Tyronne Wickramarathne
>             Fix For: 1.4.0.SP3.CP15, 1.4.8.SP11
>
>
> Add an example TCP cluster configuration (commented out) to all the example *-persistence-service.xml files.
> This will make it easier for users who have issues with UDP multicast to configure it to use TCP clustering.
> (The same thing is being done to all the EAP configurations that don't already include this). 

--
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

From issues at jboss.org  Thu Mar 13 23:02:25 2014
From: issues at jboss.org (Yong Hao Gao (JIRA))
Date: Thu, 13 Mar 2014 23:02:25 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBMESSAGING-1615) Programmatic way to
 check the state of a topic
In-Reply-To: <JIRA.12385515.1241518070000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12385515.1241518070000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12385515.1241518070000.15725.1394766145493@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBMESSAGING-1615?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Yong Hao Gao updated JBMESSAGING-1615:
--------------------------------------

    Fix Version/s: 1.4.8.SP11
                       (was: 1.4.8.SP10)

    
> Programmatic way to check the state of a topic
> ----------------------------------------------
>
>                 Key: JBMESSAGING-1615
>                 URL: https://issues.jboss.org/browse/JBMESSAGING-1615
>             Project: JBoss Messaging
>          Issue Type: Feature Request
>    Affects Versions: 1.4.1.GA
>            Reporter: Colin Mondesir
>            Assignee: Yong Hao Gao
>            Priority: Minor
>             Fix For: 1.4.0.SP3.CP15, 1.4.8.SP11
>
>
> When the deployTopic(String, String) method is called we have found there is a slight delay before the topic is available to create MessageConsumer.
> Is there a programmatic way of checking the state that the topic is in, so that we don't have to wait an arbitrary period of time before creating the Consumer?

--
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

From issues at jboss.org  Thu Mar 13 23:02:25 2014
From: issues at jboss.org (Yong Hao Gao (JIRA))
Date: Thu, 13 Mar 2014 23:02:25 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBMESSAGING-1610) expose
 jbossInternalLifecycle method on jms destination mbeans
In-Reply-To: <JIRA.12385140.1240932863000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12385140.1240932863000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12385140.1240932863000.15729.1394766145761@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBMESSAGING-1610?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Yong Hao Gao updated JBMESSAGING-1610:
--------------------------------------

    Fix Version/s: 1.4.8.SP11
                       (was: 1.4.8.SP10)

    
> expose jbossInternalLifecycle method on jms destination mbeans
> --------------------------------------------------------------
>
>                 Key: JBMESSAGING-1610
>                 URL: https://issues.jboss.org/browse/JBMESSAGING-1610
>             Project: JBoss Messaging
>          Issue Type: Task
>          Components: AS Integration
>    Affects Versions: 1.4.3.GA
>            Reporter: Emanuel Muckenhuber
>            Assignee: Yong Hao Gao
>             Fix For: 1.4.0.SP3.CP15, 1.4.8.SP11
>
>
> Currently the Queue and Topic xmbean definitions don't expose the jbossInternalLifecycle(String method). This method is needed that the lifecycle and state changes of a mbean are handled by microcontainer (AS5). Otherwise profileservice cannot determine the current state and a stopped jms destination would be still exposed as running to JON/JOPR.

--
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

From issues at jboss.org  Thu Mar 13 23:02:26 2014
From: issues at jboss.org (Yong Hao Gao (JIRA))
Date: Thu, 13 Mar 2014 23:02:26 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBMESSAGING-1594) Provide support for a
 List of Strings (in StreamMessage) with a size > 64K
In-Reply-To: <JIRA.12383806.1239259186000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12383806.1239259186000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12383806.1239259186000.15733.1394766146044@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBMESSAGING-1594?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Yong Hao Gao updated JBMESSAGING-1594:
--------------------------------------

    Fix Version/s: 1.4.8.SP11
                       (was: 1.4.8.SP10)

    
> Provide support for a List of Strings (in StreamMessage) with a size > 64K
> --------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1594
>                 URL: https://issues.jboss.org/browse/JBMESSAGING-1594
>             Project: JBoss Messaging
>          Issue Type: Feature Request
>          Components: Messaging Core
>    Affects Versions: 1.4.0.SP3
>            Reporter: Colin Mondesir
>            Assignee: Yong Hao Gao
>             Fix For: 1.4.0.SP3.CP15, 1.4.8.SP11
>
>
> Looking at the code, there is support for 'longstring' for java.lang.String. But that doesn't happen for a List of Strings.

--
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

From issues at jboss.org  Thu Mar 13 23:02:26 2014
From: issues at jboss.org (Yong Hao Gao (JIRA))
Date: Thu, 13 Mar 2014 23:02:26 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBMESSAGING-1517) Malformed HTTP POST
 from Post Office management page in JMX Console
In-Reply-To: <JIRA.12380637.1235529018000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12380637.1235529018000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12380637.1235529018000.15737.1394766146332@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBMESSAGING-1517?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Yong Hao Gao updated JBMESSAGING-1517:
--------------------------------------

    Fix Version/s: 1.4.8.SP11
                       (was: 1.4.8.SP10)

    
> Malformed HTTP POST from Post Office management page in JMX Console
> -------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1517
>                 URL: https://issues.jboss.org/browse/JBMESSAGING-1517
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 1.4.0.SP3_CP03, 1.4.2.GA.SP1
>         Environment: All
>            Reporter: Paul Kaiser
>            Assignee: Yong Hao Gao
>             Fix For: 1.4.0.SP3.CP15, 1.4.8.SP11
>
>
> When trying to submit changes to the configuration of the Messaging Post Office from the JMX Console interface, the improper quoting of configuration strings results in an improper HTTP POST. This prevents the submission of any updates to the component.

--
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

From issues at jboss.org  Thu Mar 13 23:02:26 2014
From: issues at jboss.org (Yong Hao Gao (JIRA))
Date: Thu, 13 Mar 2014 23:02:26 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBMESSAGING-1513) Database maintenance
	scripts
In-Reply-To: <JIRA.12380042.1234906477000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12380042.1234906477000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12380042.1234906477000.15741.1394766146559@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBMESSAGING-1513?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Yong Hao Gao updated JBMESSAGING-1513:
--------------------------------------

    Fix Version/s: 1.4.8.SP11
                       (was: 1.4.8.SP10)

    
> Database maintenance scripts
> ----------------------------
>
>                 Key: JBMESSAGING-1513
>                 URL: https://issues.jboss.org/browse/JBMESSAGING-1513
>             Project: JBoss Messaging
>          Issue Type: Feature Request
>          Components: Configuration and Management
>    Affects Versions: 1.4.2.GA.SP1
>            Reporter: Len DiMaggio
>            Assignee: Yong Hao Gao
>             Fix For: 1.4.0.SP3.CP15, 1.4.8.SP11
>
>
> Project JIRA for SOA-P platform JIRA: https://jira.jboss.org/jira/browse/SOA-310

--
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

From issues at jboss.org  Thu Mar 13 23:02:26 2014
From: issues at jboss.org (Yong Hao Gao (JIRA))
Date: Thu, 13 Mar 2014 23:02:26 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBMESSAGING-1491) add support for Ingres
 RDBMS to JBoss Messaging
In-Reply-To: <JIRA.12377766.1232348480000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12377766.1232348480000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12377766.1232348480000.15746.1394766146822@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBMESSAGING-1491?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Yong Hao Gao updated JBMESSAGING-1491:
--------------------------------------

    Fix Version/s: 1.4.8.SP11
                       (was: 1.4.8.SP10)

    
> add support for Ingres RDBMS to JBoss Messaging
> -----------------------------------------------
>
>                 Key: JBMESSAGING-1491
>                 URL: https://issues.jboss.org/browse/JBMESSAGING-1491
>             Project: JBoss Messaging
>          Issue Type: Patch
>    Affects Versions: 1.4.0.SP3.CP06, 2.0.0 Beta1, EAP/SOA-P Integration, 1.4.3.GA, Unscheduled, AS 5.0 Integration
>         Environment: N/A
>            Reporter: murray armfield
>            Assignee: Yong Hao Gao
>            Priority: Minor
>             Fix For: 1.4.0.SP3.CP15, 1.4.8.SP11
>
>         Attachments: ingres-persistence-service.newrev.xml, ingres-persistence-service.xml, ingres-persistence-service.xml, ingres.diff, ingresv2.diff
>
>   Original Estimate: 30 minutes
>  Remaining Estimate: 30 minutes
>
> I've been working on JBoss support on Ingres.
> I've written an ingres-persistence-service.xml file for use with Ingres for inclusion as part of JBoss Messaging

--
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

From issues at jboss.org  Thu Mar 13 23:02:27 2014
From: issues at jboss.org (Yong Hao Gao (JIRA))
Date: Thu, 13 Mar 2014 23:02:27 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBMESSAGING-1490) BridgeService should
	be JAAS aware
In-Reply-To: <JIRA.12377719.1232152026000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12377719.1232152026000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12377719.1232152026000.15750.1394766147063@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBMESSAGING-1490?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Yong Hao Gao updated JBMESSAGING-1490:
--------------------------------------

    Fix Version/s: 1.4.8.SP11
                       (was: 1.4.8.SP10)

    
> BridgeService should be JAAS aware
> ----------------------------------
>
>                 Key: JBMESSAGING-1490
>                 URL: https://issues.jboss.org/browse/JBMESSAGING-1490
>             Project: JBoss Messaging
>          Issue Type: Feature Request
>    Affects Versions: 1.4.2.GA
>         Environment: n/a
>            Reporter: Nicholas Sayer
>            Assignee: Yong Hao Gao
>            Priority: Optional
>             Fix For: 1.4.0.SP3.CP15, 1.4.8.SP11
>
>
> org.jboss.jms.server.bridge.BridgeService currently requires a username and password for the source and destination. It would be better if it could be configured with a JAAS login context name. This would allow username and password information to be set in, for example, a SecureIdentityLoginModule. For example:
>     <application-policy name = "JmsBridgeRealm">
>        <authentication>
>           <login-module code = "org.jboss.resource.security.SecureIdentityLoginModule" flag = "required">
>              <module-option name = "principal">${bridge.user}</module-option>
>              <module-option name = "userName">${bridge.user}</module-option>
>              <module-option name = "password">${bridge.encryptedPassword}</module-option>
>              <module-option name = "ignoreMissigingMCF">true</module-option>
> <!-- it is a separate bug that you must set managedConnectionFactoryName to something regardless of setting ignoreMissingMCF to true -->
>              <module-option name = "managedConnectionFactoryName">jboss.nonexistent:service=NonExistent,name=NonExistent</module-option>
>           </login-module>
>        </authentication>
>     </application-policy>
> There is undoubtedly a better way to accomplish this (probably to pass the JAAS context directly into the JMS connection factory used to vend connections for the bridge), but we're using this as a crude hack for now:
> import java.util.Set;
> import javax.security.auth.Subject;
> import javax.security.auth.login.LoginContext;
> import javax.security.auth.login.LoginException;
> import javax.security.auth.login.CredentialNotFoundException;
> import javax.resource.spi.security.PasswordCredential;
> import org.jboss.jms.server.bridge.BridgeService;
> public class JAASAwareBridgeService extends BridgeService {
>         private String sourceContext, targetContext;
>         public void setSourceLoginContext(String ctxName) { this.sourceContext = ctxName; }
>         public String getSourceLoginContext() { return this.sourceContext; }
>         public void setTargetLoginContext(String ctxName) { this.targetContext = ctxName; }
>         public String getTargetLoginContext() { return this.targetContext; }
>         public void start() throws Exception {
>                 setupSourceCredentials();
>                 setupTargetCredentials();
>                 super.start();
>         }
>         private void setupSourceCredentials() throws LoginException {
>                 PasswordCredential pc = getPasswordCredential(this.sourceContext);
>                 super.setSourceUsername(pc.getUserName());
>                 super.setSourcePassword(new String(pc.getPassword()));
>          }
>         private void setupTargetCredentials() throws LoginException {
>                 PasswordCredential pc = getPasswordCredential(this.targetContext);
>                 super.setTargetUsername(pc.getUserName());
>                 super.setTargetPassword(new String(pc.getPassword()));
>         }
>         private static PasswordCredential getPasswordCredential(String contextName) throws LoginException {
>                 LoginContext ctx = new LoginContext(contextName);
>                 ctx.login();
>                 Subject s = ctx.getSubject();
>                 Set<PasswordCredential> creds = s.getPrivateCredentials(PasswordCredential.class);
>                 if (creds.isEmpty())
>                         throw new CredentialNotFoundException("Login context '" + contextName + "' subject has no PasswordCredential");
>                 return creds.iterator().next(); // get 1st
>         }
> }

--
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

From issues at jboss.org  Thu Mar 13 23:02:27 2014
From: issues at jboss.org (Yong Hao Gao (JIRA))
Date: Thu, 13 Mar 2014 23:02:27 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBMESSAGING-1478) inconsistent test
	suite performance
In-Reply-To: <JIRA.12374336.1231170857000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12374336.1231170857000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12374336.1231170857000.15754.1394766147403@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBMESSAGING-1478?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Yong Hao Gao updated JBMESSAGING-1478:
--------------------------------------

    Fix Version/s: 1.4.8.SP11
                       (was: 1.4.8.SP10)

    
> inconsistent test suite performance
> -----------------------------------
>
>                 Key: JBMESSAGING-1478
>                 URL: https://issues.jboss.org/browse/JBMESSAGING-1478
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Tests and Performance
>    Affects Versions:  1.4.0.SP3.CP04
>            Reporter: Aleksandar Kostadinov
>            Assignee: Yong Hao Gao
>              Labels: isolation, performance, testsuite
>             Fix For: 1.4.0.SP3.CP15, 1.4.8.SP11
>
>
> I see inconsistent performance running the JBM test suite. Here I have 2 builds on the same physical machine (windows), using local disk storage so environment should be pretty stable.
> The mysql database is shared but I doubt it is the culprit. 
> I run the test suite with the following options:
> property( name: "functional.tests.database", value: dbname )
> property( name: "stress.tests.database", value: dbname )
> property( name: "clustering.tests.database", value: dbname )
> property( name: "test.target", value: "report" )
> property( name: "test.bind.address", value: properties["env.MYTESTIP_1"] )
> property( name: "jboss.messaging.groupname", value: properties["env.BUILD_TAG"])                                                                               
> property( name: "jboss.messaging.datachanneludpaddress", value: properties["env.MCAST_ADDR"] )
> property( name: "jboss.messaging.controlchanneludpaddress", value: properties["env.MCAST_ADDR"] )
> Are there any other options I can add to increase isolation from other processes in the same LAN?
> Would you be able to look at these 2 builds and based on the logs, say why is the first one taking longer and eventually timeout?
> http://hudson.qa.jboss.com/hudson/view/SOA-Release/job/soa-jbm/163/
> http://hudson.qa.jboss.com/hudson/view/SOA-Release/job/soa-jbm/164/

--
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

From issues at jboss.org  Thu Mar 13 23:02:27 2014
From: issues at jboss.org (Yong Hao Gao (JIRA))
Date: Thu, 13 Mar 2014 23:02:27 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBMESSAGING-1287) SOA-P test suite
	failures
In-Reply-To: <JIRA.12359686.1210849945000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12359686.1210849945000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12359686.1210849945000.15762.1394766147849@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBMESSAGING-1287?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Yong Hao Gao updated JBMESSAGING-1287:
--------------------------------------

    Fix Version/s: 1.4.8.SP11
                       (was: 1.4.8.SP10)

    
> SOA-P test suite failures
> -------------------------
>
>                 Key: JBMESSAGING-1287
>                 URL: https://issues.jboss.org/browse/JBMESSAGING-1287
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 1.4.0.SP3_CP01
>            Reporter: Aleksandar Kostadinov
>            Assignee: Yong Hao Gao
>             Fix For: 1.4.0.SP3.CP15, 1.4.8.SP11
>
>
> I'm running the JBM test suite against the binaries in the SOA-P Platform 4.2 CP01. I see 4 failures. 
>     * TEST-org.jboss.test.messaging.jms.bridge.BridgeTest-Remote-bisocket.xml.
>     * org.jboss.test.messaging.jms.clustering.MultipleFailoverTest(Clustering).testFailoverFloodTwoServers
>     * org.jboss.test.messaging.jms.clustering.NoFailoverTest(Clustering).testCrashNoFailover
>     * org.jboss.test.messaging.jms.ManifestTest.testManifestEntries
> Failure details in here http://hudson.qa.jboss.com/hudson/job/jboss-soa-platform-JBM-testsuite/73/testReport/
> 3 of the failures are timeout (see console log for BridgeTest). We are running on a 2 CPU DualCore physical machine so system speed should not be an issue. 

--
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

From issues at jboss.org  Thu Mar 13 23:02:27 2014
From: issues at jboss.org (Yong Hao Gao (JIRA))
Date: Thu, 13 Mar 2014 23:02:27 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBMESSAGING-1401) Unverified: Restarting
 a Queue will delete persistent messages in the queue.
In-Reply-To: <JIRA.12363767.1216341538000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12363767.1216341538000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12363767.1216341538000.15758.1394766147652@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBMESSAGING-1401?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Yong Hao Gao updated JBMESSAGING-1401:
--------------------------------------

    Fix Version/s: 1.4.8.SP11
                       (was: 1.4.8.SP10)

    
> Unverified: Restarting a Queue will delete persistent messages in the queue.
> ----------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1401
>                 URL: https://issues.jboss.org/browse/JBMESSAGING-1401
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Configuration and Management
>    Affects Versions: 1.4.0.SP3
>            Reporter: Jay Howell
>            Assignee: Yong Hao Gao
>             Fix For: 1.4.0.SP3.CP15, 1.4.8.SP11
>
>
> Restarting a queue in a running server will delete persistent messages out of the database.  This bug was found while troubleshooting a case.  When a customer restarted the queues, they noticed that all of the persistent messages in the database were gone.  I have yet to verify this and will verify as soon as possible.  I wanted to make sure that I didn't forget to put it in.  So at this point this is an unverified bug. 

--
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

From issues at jboss.org  Thu Mar 13 23:04:10 2014
From: issues at jboss.org (Yong Hao Gao (JIRA))
Date: Thu, 13 Mar 2014 23:04:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBMESSAGING-1947) Deadlock may happen
 when JBM shuts down a JGroups channel
In-Reply-To: <JIRA.12500811.1379402556000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500811.1379402556000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500811.1379402556000.15765.1394766250815@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBMESSAGING-1947?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Yong Hao Gao reopened JBMESSAGING-1947:
---------------------------------------


    
> Deadlock may happen when JBM shuts down a JGroups channel
> ---------------------------------------------------------
>
>                 Key: JBMESSAGING-1947
>                 URL: https://issues.jboss.org/browse/JBMESSAGING-1947
>             Project: JBoss Messaging
>          Issue Type: Feature Request
>          Components: JMS Clustering
>    Affects Versions: 1.4.0.SP3.CP14, 1.4.8.SP9
>            Reporter: Yong Hao Gao
>            Assignee: Yong Hao Gao
>             Fix For: 1.4.0.SP3.CP15, 1.4.8.SP10
>
>
> from Dennis:
> On 2013-09-16 20:37:51, Reed, Dennis commented:
> "The latest issue is a deadlock caused by JBoss Messaging.
> JBoss Messaging is closing the JGroups channel.
> This thread is waiting for a DISCONNECT_OK message from JGroups.
> This thread is holding a lock on a MessagingPostOffice$StateMonitor.
>   "Thread-29" prio=10 tid=0x00007f2e70f90000 nid=0xdc3 in Object.wait() [0x00007f2e590ce000]
>        ...
>        at org.jgroups.util.Promise.getResult(Promise.java:77)
>        at org.jgroups.JChannel.disconnect(JChannel.java:473)
>        ...
>        at org.jgroups.JChannel.close(JChannel.java:498)
>        at org.jboss.messaging.core.impl.postoffice.GroupMember.stop(GroupMember.java:250)
>        ...
>        at org.jboss.messaging.core.impl.postoffice.MessagingPostOffice$StateMonitor.run(MessagingPostOffice.java:4284)
>        - locked <0x00000000e2f1d3e8> (a org.jboss.messaging.core.impl.postoffice.MessagingPostOffice$StateMonitor)
> Another thread is blocking while processing a new view.  (This is BAD and should never be done!!!).
> This thread is waiting for the MessagingPostOffice$StateMonitor locked in the thread above.
> This thread is holding a lock on the view object in JGroups.
>    "IncomingMessageHandler (channel=MessagingPostOffice-CTRL)" daemon prio=10 tid=0x00007f2e70f66800 nid=0xdad waiting for monitor entry [0x00007f2e596d3000]
>       java.lang.Thread.State: BLOCKED (on object monitor)
>        at org.jboss.messaging.core.impl.postoffice.MessagingPostOffice$StateMonitor.stopJBMNodeForRecovery(MessagingPostOffice.java:4264)
>        - waiting to lock <0x00000000e2f1d3e8> (a org.jboss.messaging.core.impl.postoffice.MessagingPostOffice$StateMonitor)
>        at org.jboss.messaging.core.impl.postoffice.MessagingPostOffice.quarantine(MessagingPostOffice.java:1765)
>        at org.jboss.messaging.core.impl.postoffice.MessagingPostOffice.nodesLeft(MessagingPostOffice.java:1585)
>        at org.jboss.messaging.core.impl.postoffice.GroupMember$ControlMembershipListener.viewAccepted(GroupMember.java:609)
>        at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.passUp(MessageDispatcher.java:737)
>        at org.jgroups.blocks.RequestCorrelator.receive(RequestCorrelator.java:372)
>        at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.up(MessageDispatcher.java:779)
>        at org.jgroups.JChannel.up(JChannel.java:1090)
>        ...
>        at org.jgroups.protocols.pbcast.GMS.installView(GMS.java:508)
>        - locked <0x00000000e290d740> (a org.jgroups.Membership)
>        at org.jgroups.protocols.pbcast.GMS.installView(GMS.java:422)
>        ...
> The thread that is trying to send the DISCONNECT_OK is blocked waiting on the view object locked by the thread above:
>    "ViewHandler" prio=10 tid=0x00007f2e7800e800 nid=0xe93 waiting for monitor entry [0x00007f2e58ecd000]
>       java.lang.Thread.State: BLOCKED (on object monitor)
>        at org.jgroups.protocols.pbcast.GMS.getNextView(GMS.java:283)
>        - waiting to lock <0x00000000e290d740> (a org.jgroups.Membership)
>        at org.jgroups.protocols.pbcast.CoordGmsImpl.handleMembershipChange(CoordGmsImpl.java:480)
>        at org.jgroups.protocols.pbcast.GMS$ViewHandler.process(GMS.java:1418)
>        at org.jgroups.protocols.pbcast.GMS$ViewHandler.run(GMS.java:1355)
>        at java.lang.Thread.run(Thread.java:662)"

--
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

From issues at jboss.org  Thu Mar 13 23:04:10 2014
From: issues at jboss.org (Yong Hao Gao (JIRA))
Date: Thu, 13 Mar 2014 23:04:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBMESSAGING-1947) Deadlock may happen
 when JBM shuts down a JGroups channel
In-Reply-To: <JIRA.12500811.1379402556000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500811.1379402556000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500811.1379402556000.15767.1394766250900@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBMESSAGING-1947?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Yong Hao Gao updated JBMESSAGING-1947:
--------------------------------------

    Issue Type: Bug  (was: Feature Request)

    
> Deadlock may happen when JBM shuts down a JGroups channel
> ---------------------------------------------------------
>
>                 Key: JBMESSAGING-1947
>                 URL: https://issues.jboss.org/browse/JBMESSAGING-1947
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: JMS Clustering
>    Affects Versions: 1.4.0.SP3.CP14, 1.4.8.SP9
>            Reporter: Yong Hao Gao
>            Assignee: Yong Hao Gao
>             Fix For: 1.4.0.SP3.CP15, 1.4.8.SP10
>
>
> from Dennis:
> On 2013-09-16 20:37:51, Reed, Dennis commented:
> "The latest issue is a deadlock caused by JBoss Messaging.
> JBoss Messaging is closing the JGroups channel.
> This thread is waiting for a DISCONNECT_OK message from JGroups.
> This thread is holding a lock on a MessagingPostOffice$StateMonitor.
>   "Thread-29" prio=10 tid=0x00007f2e70f90000 nid=0xdc3 in Object.wait() [0x00007f2e590ce000]
>        ...
>        at org.jgroups.util.Promise.getResult(Promise.java:77)
>        at org.jgroups.JChannel.disconnect(JChannel.java:473)
>        ...
>        at org.jgroups.JChannel.close(JChannel.java:498)
>        at org.jboss.messaging.core.impl.postoffice.GroupMember.stop(GroupMember.java:250)
>        ...
>        at org.jboss.messaging.core.impl.postoffice.MessagingPostOffice$StateMonitor.run(MessagingPostOffice.java:4284)
>        - locked <0x00000000e2f1d3e8> (a org.jboss.messaging.core.impl.postoffice.MessagingPostOffice$StateMonitor)
> Another thread is blocking while processing a new view.  (This is BAD and should never be done!!!).
> This thread is waiting for the MessagingPostOffice$StateMonitor locked in the thread above.
> This thread is holding a lock on the view object in JGroups.
>    "IncomingMessageHandler (channel=MessagingPostOffice-CTRL)" daemon prio=10 tid=0x00007f2e70f66800 nid=0xdad waiting for monitor entry [0x00007f2e596d3000]
>       java.lang.Thread.State: BLOCKED (on object monitor)
>        at org.jboss.messaging.core.impl.postoffice.MessagingPostOffice$StateMonitor.stopJBMNodeForRecovery(MessagingPostOffice.java:4264)
>        - waiting to lock <0x00000000e2f1d3e8> (a org.jboss.messaging.core.impl.postoffice.MessagingPostOffice$StateMonitor)
>        at org.jboss.messaging.core.impl.postoffice.MessagingPostOffice.quarantine(MessagingPostOffice.java:1765)
>        at org.jboss.messaging.core.impl.postoffice.MessagingPostOffice.nodesLeft(MessagingPostOffice.java:1585)
>        at org.jboss.messaging.core.impl.postoffice.GroupMember$ControlMembershipListener.viewAccepted(GroupMember.java:609)
>        at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.passUp(MessageDispatcher.java:737)
>        at org.jgroups.blocks.RequestCorrelator.receive(RequestCorrelator.java:372)
>        at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.up(MessageDispatcher.java:779)
>        at org.jgroups.JChannel.up(JChannel.java:1090)
>        ...
>        at org.jgroups.protocols.pbcast.GMS.installView(GMS.java:508)
>        - locked <0x00000000e290d740> (a org.jgroups.Membership)
>        at org.jgroups.protocols.pbcast.GMS.installView(GMS.java:422)
>        ...
> The thread that is trying to send the DISCONNECT_OK is blocked waiting on the view object locked by the thread above:
>    "ViewHandler" prio=10 tid=0x00007f2e7800e800 nid=0xe93 waiting for monitor entry [0x00007f2e58ecd000]
>       java.lang.Thread.State: BLOCKED (on object monitor)
>        at org.jgroups.protocols.pbcast.GMS.getNextView(GMS.java:283)
>        - waiting to lock <0x00000000e290d740> (a org.jgroups.Membership)
>        at org.jgroups.protocols.pbcast.CoordGmsImpl.handleMembershipChange(CoordGmsImpl.java:480)
>        at org.jgroups.protocols.pbcast.GMS$ViewHandler.process(GMS.java:1418)
>        at org.jgroups.protocols.pbcast.GMS$ViewHandler.run(GMS.java:1355)
>        at java.lang.Thread.run(Thread.java:662)"

--
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

From issues at jboss.org  Thu Mar 13 23:06:10 2014
From: issues at jboss.org (Yong Hao Gao (JIRA))
Date: Thu, 13 Mar 2014 23:06:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBMESSAGING-1947) Deadlock may happen
 when JBM shuts down a JGroups channel
In-Reply-To: <JIRA.12500811.1379402556000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500811.1379402556000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500811.1379402556000.15771.1394766370744@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBMESSAGING-1947?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Yong Hao Gao closed JBMESSAGING-1947.
-------------------------------------

    Resolution: Done

    
> Deadlock may happen when JBM shuts down a JGroups channel
> ---------------------------------------------------------
>
>                 Key: JBMESSAGING-1947
>                 URL: https://issues.jboss.org/browse/JBMESSAGING-1947
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: JMS Clustering
>    Affects Versions: 1.4.0.SP3.CP14, 1.4.8.SP9
>            Reporter: Yong Hao Gao
>            Assignee: Yong Hao Gao
>             Fix For: 1.4.0.SP3.CP15, 1.4.8.SP10
>
>
> from Dennis:
> On 2013-09-16 20:37:51, Reed, Dennis commented:
> "The latest issue is a deadlock caused by JBoss Messaging.
> JBoss Messaging is closing the JGroups channel.
> This thread is waiting for a DISCONNECT_OK message from JGroups.
> This thread is holding a lock on a MessagingPostOffice$StateMonitor.
>   "Thread-29" prio=10 tid=0x00007f2e70f90000 nid=0xdc3 in Object.wait() [0x00007f2e590ce000]
>        ...
>        at org.jgroups.util.Promise.getResult(Promise.java:77)
>        at org.jgroups.JChannel.disconnect(JChannel.java:473)
>        ...
>        at org.jgroups.JChannel.close(JChannel.java:498)
>        at org.jboss.messaging.core.impl.postoffice.GroupMember.stop(GroupMember.java:250)
>        ...
>        at org.jboss.messaging.core.impl.postoffice.MessagingPostOffice$StateMonitor.run(MessagingPostOffice.java:4284)
>        - locked <0x00000000e2f1d3e8> (a org.jboss.messaging.core.impl.postoffice.MessagingPostOffice$StateMonitor)
> Another thread is blocking while processing a new view.  (This is BAD and should never be done!!!).
> This thread is waiting for the MessagingPostOffice$StateMonitor locked in the thread above.
> This thread is holding a lock on the view object in JGroups.
>    "IncomingMessageHandler (channel=MessagingPostOffice-CTRL)" daemon prio=10 tid=0x00007f2e70f66800 nid=0xdad waiting for monitor entry [0x00007f2e596d3000]
>       java.lang.Thread.State: BLOCKED (on object monitor)
>        at org.jboss.messaging.core.impl.postoffice.MessagingPostOffice$StateMonitor.stopJBMNodeForRecovery(MessagingPostOffice.java:4264)
>        - waiting to lock <0x00000000e2f1d3e8> (a org.jboss.messaging.core.impl.postoffice.MessagingPostOffice$StateMonitor)
>        at org.jboss.messaging.core.impl.postoffice.MessagingPostOffice.quarantine(MessagingPostOffice.java:1765)
>        at org.jboss.messaging.core.impl.postoffice.MessagingPostOffice.nodesLeft(MessagingPostOffice.java:1585)
>        at org.jboss.messaging.core.impl.postoffice.GroupMember$ControlMembershipListener.viewAccepted(GroupMember.java:609)
>        at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.passUp(MessageDispatcher.java:737)
>        at org.jgroups.blocks.RequestCorrelator.receive(RequestCorrelator.java:372)
>        at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.up(MessageDispatcher.java:779)
>        at org.jgroups.JChannel.up(JChannel.java:1090)
>        ...
>        at org.jgroups.protocols.pbcast.GMS.installView(GMS.java:508)
>        - locked <0x00000000e290d740> (a org.jgroups.Membership)
>        at org.jgroups.protocols.pbcast.GMS.installView(GMS.java:422)
>        ...
> The thread that is trying to send the DISCONNECT_OK is blocked waiting on the view object locked by the thread above:
>    "ViewHandler" prio=10 tid=0x00007f2e7800e800 nid=0xe93 waiting for monitor entry [0x00007f2e58ecd000]
>       java.lang.Thread.State: BLOCKED (on object monitor)
>        at org.jgroups.protocols.pbcast.GMS.getNextView(GMS.java:283)
>        - waiting to lock <0x00000000e290d740> (a org.jgroups.Membership)
>        at org.jgroups.protocols.pbcast.CoordGmsImpl.handleMembershipChange(CoordGmsImpl.java:480)
>        at org.jgroups.protocols.pbcast.GMS$ViewHandler.process(GMS.java:1418)
>        at org.jgroups.protocols.pbcast.GMS$ViewHandler.run(GMS.java:1355)
>        at java.lang.Thread.run(Thread.java:662)"

--
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

From issues at jboss.org  Thu Mar 13 23:30:10 2014
From: issues at jboss.org (Chao Wang (JIRA))
Date: Thu, 13 Mar 2014 23:30:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBWEB-293) NPE if method
 getClassLoader() returns null to represent the bootstrap class loader
In-Reply-To: <JIRA.12534367.1394182683000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534367.1394182683000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534367.1394182683000.15784.1394767810561@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBWEB-293?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Chao Wang updated JBWEB-293:
----------------------------

    Attachment:     (was: JBWEB-293.patch)

    
> NPE if method getClassLoader() returns null to represent the bootstrap class loader
> -----------------------------------------------------------------------------------
>
>                 Key: JBWEB-293
>                 URL: https://issues.jboss.org/browse/JBWEB-293
>             Project: JBoss Web
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: JBossWeb-2.1.14.GA
>            Reporter: Chao Wang
>            Assignee: Chao Wang
>         Attachments: JBWEB-293.patch
>
>
> from the scenario in [JBPAPP-11027|https://issues.jboss.org/browse/JBPAPP-11027] , and java code in java/javax/el/BeanELResolver.java :
> {code:title=BeanELResolver.java|borderStyle=solid}
>         Iterator<Class<?>> iter = cache.keySet().iterator();
>         while (iter.hasNext()) {
>             Class<?> key = iter.next();
>             BeanProperties bp = cache.get(key);
>             if(bp.getType().getClassLoader().equals(classloader)){
>                 iter.remove();
>             }
>         }
> {code}
> Here, when key is "class java.lang.Class" and bp's type is "class java.lang.Class", method getClassLoader() returns null to represent the bootstrap class loader, then NPE as described is threw during stopping service jboss.web
> {noformat}
> cache content:
> class org.jboss.on.embedded.bean.ResourceListItem=javax.el.BeanELResolver$BeanProperties at 36d4423d, 
> class org.jboss.on.embedded.ui.NavigationAction_$$_javassist_seam_9=javax.el.BeanELResolver$BeanProperties at 2948ceea, 
> class org.jboss.on.embedded.ui.ResourceAction_$$_javassist_seam_12=javax.el.BeanELResolver$BeanProperties at 6b0879d2, 
> class org.jboss.on.embedded.ui.nav.SubCategoryTreeNode=javax.el.BeanELResolver$BeanProperties at 797600e3, 
> class org.jboss.on.embedded.ui.nav.PlatformResourceTreeNode=javax.el.BeanELResolver$BeanProperties at 32347561, 
> class java.lang.Class=javax.el.BeanELResolver$BeanProperties at 12064d07, 
> class org.jboss.on.embedded.ui.nav.SingletonResourceTypeTreeNode=javax.el.BeanELResolver$BeanProperties at 5bab0fcf, 
> class org.jboss.on.embedded.ui.nav.ResourceTreeNode=javax.el.BeanELResolver$BeanProperties at 3b9b0e0d, 
> class org.jboss.on.embedded.ui.nav.NonSingletonResourceTypeTreeNode=javax.el.BeanELResolver$BeanProperties at 40b7960d, 
> class org.rhq.core.domain.measurement.MeasurementDefinition=javax.el.BeanELResolver$BeanProperties at 54dc50ac, 
> class org.rhq.core.domain.resource.Resource=javax.el.BeanELResolver$BeanProperties at 4c3477ba, 
> class org.rhq.core.domain.measurement.MeasurementDataTrait=javax.el.BeanELResolver$BeanProperties at 8a07b6c, 
> class org.jboss.seam.security.Identity=javax.el.BeanELResolver$BeanProperties at 6006f3e0, 
> class org.jboss.on.embedded.bean.MeasurementDisplay=javax.el.BeanELResolver$BeanProperties at 68752860}
> {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

From issues at jboss.org  Thu Mar 13 23:30:10 2014
From: issues at jboss.org (Chao Wang (JIRA))
Date: Thu, 13 Mar 2014 23:30:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBWEB-293) NPE if method
 getClassLoader() returns null to represent the bootstrap class loader
In-Reply-To: <JIRA.12534367.1394182683000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534367.1394182683000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534367.1394182683000.15785.1394767810603@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBWEB-293?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Chao Wang updated JBWEB-293:
----------------------------

    Attachment: JBWEB-293.patch

    
> NPE if method getClassLoader() returns null to represent the bootstrap class loader
> -----------------------------------------------------------------------------------
>
>                 Key: JBWEB-293
>                 URL: https://issues.jboss.org/browse/JBWEB-293
>             Project: JBoss Web
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: JBossWeb-2.1.14.GA
>            Reporter: Chao Wang
>            Assignee: Chao Wang
>         Attachments: JBWEB-293.patch
>
>
> from the scenario in [JBPAPP-11027|https://issues.jboss.org/browse/JBPAPP-11027] , and java code in java/javax/el/BeanELResolver.java :
> {code:title=BeanELResolver.java|borderStyle=solid}
>         Iterator<Class<?>> iter = cache.keySet().iterator();
>         while (iter.hasNext()) {
>             Class<?> key = iter.next();
>             BeanProperties bp = cache.get(key);
>             if(bp.getType().getClassLoader().equals(classloader)){
>                 iter.remove();
>             }
>         }
> {code}
> Here, when key is "class java.lang.Class" and bp's type is "class java.lang.Class", method getClassLoader() returns null to represent the bootstrap class loader, then NPE as described is threw during stopping service jboss.web
> {noformat}
> cache content:
> class org.jboss.on.embedded.bean.ResourceListItem=javax.el.BeanELResolver$BeanProperties at 36d4423d, 
> class org.jboss.on.embedded.ui.NavigationAction_$$_javassist_seam_9=javax.el.BeanELResolver$BeanProperties at 2948ceea, 
> class org.jboss.on.embedded.ui.ResourceAction_$$_javassist_seam_12=javax.el.BeanELResolver$BeanProperties at 6b0879d2, 
> class org.jboss.on.embedded.ui.nav.SubCategoryTreeNode=javax.el.BeanELResolver$BeanProperties at 797600e3, 
> class org.jboss.on.embedded.ui.nav.PlatformResourceTreeNode=javax.el.BeanELResolver$BeanProperties at 32347561, 
> class java.lang.Class=javax.el.BeanELResolver$BeanProperties at 12064d07, 
> class org.jboss.on.embedded.ui.nav.SingletonResourceTypeTreeNode=javax.el.BeanELResolver$BeanProperties at 5bab0fcf, 
> class org.jboss.on.embedded.ui.nav.ResourceTreeNode=javax.el.BeanELResolver$BeanProperties at 3b9b0e0d, 
> class org.jboss.on.embedded.ui.nav.NonSingletonResourceTypeTreeNode=javax.el.BeanELResolver$BeanProperties at 40b7960d, 
> class org.rhq.core.domain.measurement.MeasurementDefinition=javax.el.BeanELResolver$BeanProperties at 54dc50ac, 
> class org.rhq.core.domain.resource.Resource=javax.el.BeanELResolver$BeanProperties at 4c3477ba, 
> class org.rhq.core.domain.measurement.MeasurementDataTrait=javax.el.BeanELResolver$BeanProperties at 8a07b6c, 
> class org.jboss.seam.security.Identity=javax.el.BeanELResolver$BeanProperties at 6006f3e0, 
> class org.jboss.on.embedded.bean.MeasurementDisplay=javax.el.BeanELResolver$BeanProperties at 68752860}
> {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

From issues at jboss.org  Fri Mar 14 00:36:10 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 14 Mar 2014 00:36:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBMETA-354) Support EJB 2.0 dtd
	descriptors
In-Reply-To: <JIRA.12460369.1330506796000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12460369.1330506796000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12460369.1330506796000.15791.1394771770702@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBMETA-354?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated JBMETA-354:
-------------------------------------------

        Bugzilla Update: Perform
    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1057835

    
> Support EJB 2.0 dtd descriptors
> -------------------------------
>
>                 Key: JBMETA-354
>                 URL: https://issues.jboss.org/browse/JBMETA-354
>             Project: JBoss Metadata
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: ejb
>    Affects Versions: 7.0.0.Final
>            Reporter: Carlo de Wolf
>


--
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

From issues at jboss.org  Fri Mar 14 01:06:10 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 14 Mar 2014 01:06:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2493) EL cannot access public
 methods/fields of non-public classes
In-Reply-To: <JIRA.12524859.1384250001000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12524859.1384250001000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12524859.1384250001000.15795.1394773570805@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2493?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated WFLY-2493:
------------------------------------------

    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1029387, https://bugzilla.redhat.com/show_bug.cgi?id=1076320  (was: https://bugzilla.redhat.com/show_bug.cgi?id=1029387)

    
> EL cannot access public methods/fields of non-public classes
> ------------------------------------------------------------
>
>                 Key: WFLY-2493
>                 URL: https://issues.jboss.org/browse/WFLY-2493
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JSF
>         Environment: JBoss AS 7.2.0.Final
>            Reporter: Jon?? Trantina
>         Attachments: elresolver_stack, reproducer.zip
>
>
> When trying to access public method/field of non-public class that implements public interface via EL I get 
> {noformat}
> java.lang.IllegalAccessException: Class javax.el.BeanELResolver can not access a member of class X with modifiers "private"
> {noformat}
> E.g. accessing Collections.unmodifiableList(..).size() via EL will throw the exception, because #unmodifiableList returns non-public implementation of List interface.
> This is apparently caused by JDK-4071957 [1], but since that is opened for over 16 years, it should be probably worth it to implement a workaround.
> Workaround for this issue is setting setAccessible(true) on the method before invoking it, thus suppress Java access checking.
> I have attached a simple reproducer app as well as a stack trace of the exception.
> [1] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4071957

--
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


From issues at jboss.org  Fri Mar 14 01:06:11 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 14 Mar 2014 01:06:11 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBEE-146) jboss-el-api_2.2_spec
 1.0.2.Final cannot access public methods from non-public classes
In-Reply-To: <JIRA.12525180.1384462560000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12525180.1384462560000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12525180.1384462560000.15800.1394773571074@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBEE-146?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated JBEE-146:
-----------------------------------------

    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1029387, https://bugzilla.redhat.com/show_bug.cgi?id=1076320  (was: https://bugzilla.redhat.com/show_bug.cgi?id=1029387)

    
> jboss-el-api_2.2_spec 1.0.2.Final cannot access public methods from non-public classes
> --------------------------------------------------------------------------------------
>
>                 Key: JBEE-146
>                 URL: https://issues.jboss.org/browse/JBEE-146
>             Project: JBoss JavaEE Spec APIs
>          Issue Type: Bug
>            Reporter: Farah Juma
>            Assignee: Farah Juma
>             Fix For: jboss-el-api_2.2_spec-1.0.3.Final, jboss-el-api_3.0_spec-1.0.0.Final
>
>
> When accessing a public method of a non-public class via EL that implements a public interface or has a public superclass, the following exception occurs:
> {code}java.lang.IllegalAccessException: Class javax.el.BeanELResolver can not access a member of class X with modifiers "public" 
> {code}
> See https://bugzilla.redhat.com/show_bug.cgi?id=1029387 for more 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

From issues at jboss.org  Fri Mar 14 01:08:10 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 14 Mar 2014 01:08:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBEE-146) jboss-el-api_2.2_spec
 1.0.2.Final cannot access public methods from non-public classes
In-Reply-To: <JIRA.12525180.1384462560000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12525180.1384462560000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12525180.1384462560000.15803.1394773690629@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JBEE-146?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12952866#comment-12952866 ] 

RH Bugzilla Integration commented on JBEE-146:
----------------------------------------------

Jimmy Wilson <jawilson at redhat.com> changed the Status of [bug 1076320|https://bugzilla.redhat.com/show_bug.cgi?id=1076320] from NEW to POST
                
> jboss-el-api_2.2_spec 1.0.2.Final cannot access public methods from non-public classes
> --------------------------------------------------------------------------------------
>
>                 Key: JBEE-146
>                 URL: https://issues.jboss.org/browse/JBEE-146
>             Project: JBoss JavaEE Spec APIs
>          Issue Type: Bug
>            Reporter: Farah Juma
>            Assignee: Farah Juma
>             Fix For: jboss-el-api_2.2_spec-1.0.3.Final, jboss-el-api_3.0_spec-1.0.0.Final
>
>
> When accessing a public method of a non-public class via EL that implements a public interface or has a public superclass, the following exception occurs:
> {code}java.lang.IllegalAccessException: Class javax.el.BeanELResolver can not access a member of class X with modifiers "public" 
> {code}
> See https://bugzilla.redhat.com/show_bug.cgi?id=1029387 for more 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

From issues at jboss.org  Fri Mar 14 01:08:10 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 14 Mar 2014 01:08:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2493) EL cannot access public
 methods/fields of non-public classes
In-Reply-To: <JIRA.12524859.1384250001000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12524859.1384250001000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12524859.1384250001000.15806.1394773690869@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2493?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12952867#comment-12952867 ] 

RH Bugzilla Integration commented on WFLY-2493:
-----------------------------------------------

Jimmy Wilson <jawilson at redhat.com> changed the Status of [bug 1076320|https://bugzilla.redhat.com/show_bug.cgi?id=1076320] from NEW to POST
                
> EL cannot access public methods/fields of non-public classes
> ------------------------------------------------------------
>
>                 Key: WFLY-2493
>                 URL: https://issues.jboss.org/browse/WFLY-2493
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JSF
>         Environment: JBoss AS 7.2.0.Final
>            Reporter: Jon?? Trantina
>         Attachments: elresolver_stack, reproducer.zip
>
>
> When trying to access public method/field of non-public class that implements public interface via EL I get 
> {noformat}
> java.lang.IllegalAccessException: Class javax.el.BeanELResolver can not access a member of class X with modifiers "private"
> {noformat}
> E.g. accessing Collections.unmodifiableList(..).size() via EL will throw the exception, because #unmodifiableList returns non-public implementation of List interface.
> This is apparently caused by JDK-4071957 [1], but since that is opened for over 16 years, it should be probably worth it to implement a workaround.
> Workaround for this issue is setting setAccessible(true) on the method before invoking it, thus suppress Java access checking.
> I have attached a simple reproducer app as well as a stack trace of the exception.
> [1] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4071957

--
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


From issues at jboss.org  Fri Mar 14 03:42:10 2014
From: issues at jboss.org (Alexandre Nikolov (JIRA))
Date: Fri, 14 Mar 2014 03:42:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3113) Websocket connection fails
 when connecting to protected URL (basic login)
In-Reply-To: <JIRA.12534953.1394744993000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534953.1394744993000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534953.1394744993000.15879.1394782930670@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-3113?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Alexandre Nikolov updated WFLY-3113:
------------------------------------

    Description: 
In a sample application for JSR356 support, added security constraints with basic log-in. The websocket endpoint is protect with basic log-in.

When a websocket connection is attempted to the protected URL, there is inconsistent behavior in different browsers:
1. Chrome fails with 401 error code and the log-in screen is not displayed at all.
2. Firefox displays the log-in screen and the websocket is created and opened after the log-in succeeds.

But in a different application, using Atmosphere - both connections fails:
1. Chrome fails with the same error and the log-in screen is displayed after that. Most probably the log-in screen is triggered by Atmosphere when it falls back to long-polling
2. Firefox - The login screen is displayed and if the log-in suceeds, the socket is created, but Atmosphere fails to process it.
For example if the context root is "jsr356test" and the protected path is /pubsub/protected, Atmosphere tries to map /jsr356test/pubsub/protected (which in JSR356 is Session#getRequestURI()) but has mapping set-up for /pubsub/protected (which for a Http request wuld be the path info) 
Here is the related discussion on the Atmosphere users group:
https://groups.google.com/forum/#!topic/atmosphere-framework/ntIHOohlYIc

There is test WAR and source in the Atmosphere forum to reproduce the problem.

  was:
In a sample application for JSR356 support, added security constraints with basic log-in. The websocket endpoint is protect with basic log-in.

When a websocket connection is attempted to the protected URL, there is inconsistent behavior in different browsers:
1. Chrome fails with 401 error code and the log-in screen is not displayed at all.
2. Firefox displays the log-in screen and the websocket is created and opened after the log-in succeeds.

But in a different application, using Atmosphere - both connections fails:
1. Chrome fails with the same error and the log-in screen is displayed after that. Most probably the log-in screen is triggered by Atmosphere when it falls back to long-polling
2. Firefox - The login screen is displayed and if the log-in suceeds, the socket is created, but Atmosphere fails to process it because the reques.getPathInfo() returns the context root prepended to the path info.
For example if the context root is "jsr356test" and the protected path is /pubsub/protected, the path info returned is /jsr356test/pubsub/protected instead of /pubsub/protected
Here is the related discussion on the Atmosphere users group:
https://groups.google.com/forum/#!topic/atmosphere-framework/ntIHOohlYIc

There is test WAR and source in the Atmosphere forum to reproduce the problem.


    
> Websocket connection fails when connecting to protected URL (basic login)
> -------------------------------------------------------------------------
>
>                 Key: WFLY-3113
>                 URL: https://issues.jboss.org/browse/WFLY-3113
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web (Undertow)
>    Affects Versions: 8.0.0.Final
>         Environment: WildFly 8.0.0.Final, Windows 8, RedHat Linux
> Chrome, Firefox
>            Reporter: Alexandre Nikolov
>            Assignee: Stuart Douglas
>              Labels: jsr356,, login
>
> In a sample application for JSR356 support, added security constraints with basic log-in. The websocket endpoint is protect with basic log-in.
> When a websocket connection is attempted to the protected URL, there is inconsistent behavior in different browsers:
> 1. Chrome fails with 401 error code and the log-in screen is not displayed at all.
> 2. Firefox displays the log-in screen and the websocket is created and opened after the log-in succeeds.
> But in a different application, using Atmosphere - both connections fails:
> 1. Chrome fails with the same error and the log-in screen is displayed after that. Most probably the log-in screen is triggered by Atmosphere when it falls back to long-polling
> 2. Firefox - The login screen is displayed and if the log-in suceeds, the socket is created, but Atmosphere fails to process it.
> For example if the context root is "jsr356test" and the protected path is /pubsub/protected, Atmosphere tries to map /jsr356test/pubsub/protected (which in JSR356 is Session#getRequestURI()) but has mapping set-up for /pubsub/protected (which for a Http request wuld be the path info) 
> Here is the related discussion on the Atmosphere users group:
> https://groups.google.com/forum/#!topic/atmosphere-framework/ntIHOohlYIc
> There is test WAR and source in the Atmosphere forum to reproduce the problem.

--
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

From issues at jboss.org  Fri Mar 14 03:44:10 2014
From: issues at jboss.org (Alexandre Nikolov (JIRA))
Date: Fri, 14 Mar 2014 03:44:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3113) Websocket connection fails
 when connecting to protected URL (basic login)
In-Reply-To: <JIRA.12534953.1394744993000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534953.1394744993000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534953.1394744993000.15882.1394783050718@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-3113?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Alexandre Nikolov updated WFLY-3113:
------------------------------------

    Issue Type: Clarification  (was: Bug)

    
> Websocket connection fails when connecting to protected URL (basic login)
> -------------------------------------------------------------------------
>
>                 Key: WFLY-3113
>                 URL: https://issues.jboss.org/browse/WFLY-3113
>             Project: WildFly
>          Issue Type: Clarification
>      Security Level: Public(Everyone can see) 
>          Components: Web (Undertow)
>    Affects Versions: 8.0.0.Final
>         Environment: WildFly 8.0.0.Final, Windows 8, RedHat Linux
> Chrome, Firefox
>            Reporter: Alexandre Nikolov
>            Assignee: Stuart Douglas
>              Labels: jsr356,, login
>
> In a sample application for JSR356 support, added security constraints with basic log-in. The websocket endpoint is protect with basic log-in.
> When a websocket connection is attempted to the protected URL, there is inconsistent behavior in different browsers:
> 1. Chrome fails with 401 error code and the log-in screen is not displayed at all.
> 2. Firefox displays the log-in screen and the websocket is created and opened after the log-in succeeds.
> But in a different application, using Atmosphere - both connections fails:
> 1. Chrome fails with the same error and the log-in screen is displayed after that. Most probably the log-in screen is triggered by Atmosphere when it falls back to long-polling
> 2. Firefox - The login screen is displayed and if the log-in suceeds, the socket is created, but Atmosphere fails to process it.
> For example if the context root is "jsr356test" and the protected path is /pubsub/protected, Atmosphere tries to map /jsr356test/pubsub/protected (which in JSR356 is Session#getRequestURI()) but has mapping set-up for /pubsub/protected (which for a Http request wuld be the path info) 
> Here is the related discussion on the Atmosphere users group:
> https://groups.google.com/forum/#!topic/atmosphere-framework/ntIHOohlYIc
> There is test WAR and source in the Atmosphere forum to reproduce the problem.

--
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

From issues at jboss.org  Fri Mar 14 03:46:11 2014
From: issues at jboss.org (Alexandre Nikolov (JIRA))
Date: Fri, 14 Mar 2014 03:46:11 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3113) Websocket connection fails
 when connecting to protected URL (basic login)
In-Reply-To: <JIRA.12534953.1394744993000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534953.1394744993000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534953.1394744993000.15889.1394783171574@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-3113?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12952885#comment-12952885 ] 

Alexandre Nikolov commented on WFLY-3113:
-----------------------------------------

After further investigation, I think this is not a problem with WildFly, but a combination of two different issue with:
1. Chrome connecting to protected endpoint
2. Atmosphere when the incoming connection is to protected endpoint.

With unprotected endpoint everything works as expected.

So I am changing this issue type to "Clarification". Probably someone needs to take this with Chrome dev. team.
                
> Websocket connection fails when connecting to protected URL (basic login)
> -------------------------------------------------------------------------
>
>                 Key: WFLY-3113
>                 URL: https://issues.jboss.org/browse/WFLY-3113
>             Project: WildFly
>          Issue Type: Clarification
>      Security Level: Public(Everyone can see) 
>          Components: Web (Undertow)
>    Affects Versions: 8.0.0.Final
>         Environment: WildFly 8.0.0.Final, Windows 8, RedHat Linux
> Chrome, Firefox
>            Reporter: Alexandre Nikolov
>            Assignee: Stuart Douglas
>              Labels: jsr356,, login
>
> In a sample application for JSR356 support, added security constraints with basic log-in. The websocket endpoint is protect with basic log-in.
> When a websocket connection is attempted to the protected URL, there is inconsistent behavior in different browsers:
> 1. Chrome fails with 401 error code and the log-in screen is not displayed at all.
> 2. Firefox displays the log-in screen and the websocket is created and opened after the log-in succeeds.
> But in a different application, using Atmosphere - both connections fails:
> 1. Chrome fails with the same error and the log-in screen is displayed after that. Most probably the log-in screen is triggered by Atmosphere when it falls back to long-polling
> 2. Firefox - The login screen is displayed and if the log-in suceeds, the socket is created, but Atmosphere fails to process it.
> For example if the context root is "jsr356test" and the protected path is /pubsub/protected, Atmosphere tries to map /jsr356test/pubsub/protected (which in JSR356 is Session#getRequestURI()) but has mapping set-up for /pubsub/protected (which for a Http request wuld be the path info) 
> Here is the related discussion on the Atmosphere users group:
> https://groups.google.com/forum/#!topic/atmosphere-framework/ntIHOohlYIc
> There is test WAR and source in the Atmosphere forum to reproduce the problem.

--
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

From issues at jboss.org  Fri Mar 14 03:46:11 2014
From: issues at jboss.org (Alexandre Nikolov (JIRA))
Date: Fri, 14 Mar 2014 03:46:11 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3113) Websocket connection fails
 when connecting to protected URL (basic login)
In-Reply-To: <JIRA.12534953.1394744993000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534953.1394744993000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534953.1394744993000.15895.1394783171867@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-3113?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Alexandre Nikolov updated WFLY-3113:
------------------------------------

    Description: 
In a sample application for JSR356 support, added security constraints with basic log-in. The websocket endpoint is protect with basic log-in.

When a websocket connection is attempted to the protected URL, there is inconsistent behavior in different browsers:
1. Chrome fails with 401 error code and the log-in screen is not displayed at all.
2. Firefox displays the log-in screen and the websocket is created and opened after the log-in succeeds.

But in a different application, using Atmosphere - both connections fails:
1. Chrome fails with the same error and the log-in screen is displayed after that. Most probably the log-in screen is triggered by Atmosphere when it falls back to long-polling
2. Firefox - The login screen is displayed and if the log-in suceeds, the socket is created, but Atmosphere fails to process it.
For example if the context root is "jsr356test" and the protected path is /pubsub/protected, Atmosphere tries to map /jsr356test/pubsub/protected (which in JSR356 is Session#getRequestURI()) but has mapping set-up for /pubsub/protected (which for a Http request would be the path info) 
Here is the related discussion on the Atmosphere users group:
https://groups.google.com/forum/#!topic/atmosphere-framework/ntIHOohlYIc

There is test WAR and source in the Atmosphere forum to reproduce the problem.

  was:
In a sample application for JSR356 support, added security constraints with basic log-in. The websocket endpoint is protect with basic log-in.

When a websocket connection is attempted to the protected URL, there is inconsistent behavior in different browsers:
1. Chrome fails with 401 error code and the log-in screen is not displayed at all.
2. Firefox displays the log-in screen and the websocket is created and opened after the log-in succeeds.

But in a different application, using Atmosphere - both connections fails:
1. Chrome fails with the same error and the log-in screen is displayed after that. Most probably the log-in screen is triggered by Atmosphere when it falls back to long-polling
2. Firefox - The login screen is displayed and if the log-in suceeds, the socket is created, but Atmosphere fails to process it.
For example if the context root is "jsr356test" and the protected path is /pubsub/protected, Atmosphere tries to map /jsr356test/pubsub/protected (which in JSR356 is Session#getRequestURI()) but has mapping set-up for /pubsub/protected (which for a Http request wuld be the path info) 
Here is the related discussion on the Atmosphere users group:
https://groups.google.com/forum/#!topic/atmosphere-framework/ntIHOohlYIc

There is test WAR and source in the Atmosphere forum to reproduce the problem.


    
> Websocket connection fails when connecting to protected URL (basic login)
> -------------------------------------------------------------------------
>
>                 Key: WFLY-3113
>                 URL: https://issues.jboss.org/browse/WFLY-3113
>             Project: WildFly
>          Issue Type: Clarification
>      Security Level: Public(Everyone can see) 
>          Components: Web (Undertow)
>    Affects Versions: 8.0.0.Final
>         Environment: WildFly 8.0.0.Final, Windows 8, RedHat Linux
> Chrome, Firefox
>            Reporter: Alexandre Nikolov
>            Assignee: Stuart Douglas
>              Labels: jsr356,, login
>
> In a sample application for JSR356 support, added security constraints with basic log-in. The websocket endpoint is protect with basic log-in.
> When a websocket connection is attempted to the protected URL, there is inconsistent behavior in different browsers:
> 1. Chrome fails with 401 error code and the log-in screen is not displayed at all.
> 2. Firefox displays the log-in screen and the websocket is created and opened after the log-in succeeds.
> But in a different application, using Atmosphere - both connections fails:
> 1. Chrome fails with the same error and the log-in screen is displayed after that. Most probably the log-in screen is triggered by Atmosphere when it falls back to long-polling
> 2. Firefox - The login screen is displayed and if the log-in suceeds, the socket is created, but Atmosphere fails to process it.
> For example if the context root is "jsr356test" and the protected path is /pubsub/protected, Atmosphere tries to map /jsr356test/pubsub/protected (which in JSR356 is Session#getRequestURI()) but has mapping set-up for /pubsub/protected (which for a Http request would be the path info) 
> Here is the related discussion on the Atmosphere users group:
> https://groups.google.com/forum/#!topic/atmosphere-framework/ntIHOohlYIc
> There is test WAR and source in the Atmosphere forum to reproduce the problem.

--
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

From issues at jboss.org  Fri Mar 14 04:12:11 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 14 Mar 2014 04:12:11 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-455) Event expiration calculation
	may overflow
In-Reply-To: <JIRA.12534871.1394709964000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534871.1394709964000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534871.1394709964000.15940.1394784731424@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-455?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated DROOLS-455:
-------------------------------------------

        Bugzilla Update: Perform
    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1076361

    
> Event expiration calculation may overflow
> -----------------------------------------
>
>                 Key: DROOLS-455
>                 URL: https://issues.jboss.org/browse/DROOLS-455
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.6.0.Final, 6.0.0.Final, 6.0.1.Final, 6.1.0.Beta1
>            Reporter: Davide Sottara
>            Assignee: Edson Tirelli
>            Priority: Critical
>
> The calculation of the expiration timestamp of an event in the OTN is effectively  given by the combination :
> {code}
> Handle.startTimeStamp + Handle.duration + OTN.expirationOffset 
> {code}
> If the addition overflows, the event will be scheduled for expiration immediately.

--
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

From issues at jboss.org  Fri Mar 14 04:14:10 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 14 Mar 2014 04:14:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-455) Event expiration calculation
	may overflow
In-Reply-To: <JIRA.12534871.1394709964000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534871.1394709964000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534871.1394709964000.15944.1394784850674@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/DROOLS-455?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12952895#comment-12952895 ] 

RH Bugzilla Integration commented on DROOLS-455:
------------------------------------------------

Mario Fusco <mfusco at redhat.com> changed the Status of [bug 1076361|https://bugzilla.redhat.com/show_bug.cgi?id=1076361] from NEW to ASSIGNED
                
> Event expiration calculation may overflow
> -----------------------------------------
>
>                 Key: DROOLS-455
>                 URL: https://issues.jboss.org/browse/DROOLS-455
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.6.0.Final, 6.0.0.Final, 6.0.1.Final, 6.1.0.Beta1
>            Reporter: Davide Sottara
>            Assignee: Edson Tirelli
>            Priority: Critical
>
> The calculation of the expiration timestamp of an event in the OTN is effectively  given by the combination :
> {code}
> Handle.startTimeStamp + Handle.duration + OTN.expirationOffset 
> {code}
> If the addition overflows, the event will be scheduled for expiration immediately.

--
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

From issues at jboss.org  Fri Mar 14 04:14:10 2014
From: issues at jboss.org (Mario Fusco (JIRA))
Date: Fri, 14 Mar 2014 04:14:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-455) Event expiration calculation
	may overflow
In-Reply-To: <JIRA.12534871.1394709964000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534871.1394709964000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534871.1394709964000.15948.1394784850914@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-455?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mario Fusco reassigned DROOLS-455:
----------------------------------

    Assignee: Mario Fusco  (was: Edson Tirelli)

    
> Event expiration calculation may overflow
> -----------------------------------------
>
>                 Key: DROOLS-455
>                 URL: https://issues.jboss.org/browse/DROOLS-455
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.6.0.Final, 6.0.0.Final, 6.0.1.Final, 6.1.0.Beta1
>            Reporter: Davide Sottara
>            Assignee: Mario Fusco
>            Priority: Critical
>
> The calculation of the expiration timestamp of an event in the OTN is effectively  given by the combination :
> {code}
> Handle.startTimeStamp + Handle.duration + OTN.expirationOffset 
> {code}
> If the addition overflows, the event will be scheduled for expiration immediately.

--
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

From issues at jboss.org  Fri Mar 14 04:16:11 2014
From: issues at jboss.org (Mario Fusco (JIRA))
Date: Fri, 14 Mar 2014 04:16:11 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-455) Event expiration calculation
	may overflow
In-Reply-To: <JIRA.12534871.1394709964000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534871.1394709964000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534871.1394709964000.15953.1394784971559@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-455?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mario Fusco resolved DROOLS-455.
--------------------------------

    Fix Version/s: 6.1.0.Beta2
       Resolution: Done

    
> Event expiration calculation may overflow
> -----------------------------------------
>
>                 Key: DROOLS-455
>                 URL: https://issues.jboss.org/browse/DROOLS-455
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.6.0.Final, 6.0.0.Final, 6.0.1.Final, 6.1.0.Beta1
>            Reporter: Davide Sottara
>            Assignee: Mario Fusco
>            Priority: Critical
>             Fix For: 6.1.0.Beta2
>
>
> The calculation of the expiration timestamp of an event in the OTN is effectively  given by the combination :
> {code}
> Handle.startTimeStamp + Handle.duration + OTN.expirationOffset 
> {code}
> If the addition overflows, the event will be scheduled for expiration immediately.

--
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

From issues at jboss.org  Fri Mar 14 04:58:10 2014
From: issues at jboss.org (Sylvain Brouillat (JIRA))
Date: Fri, 14 Mar 2014 04:58:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2850) AJP connector with external
	authentication
In-Reply-To: <JIRA.12530843.1391157375000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530843.1391157375000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530843.1391157375000.16086.1394787490631@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2850?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12952920#comment-12952920 ] 

Sylvain Brouillat commented on WFLY-2850:
-----------------------------------------

Tomcat define tomcatAuthentication attribute for ajp connector, that when set to false, disable tomcatAuthentication and allows apache to handle authentication and pass remote_user throught AJP channel to tomcat (http://tomcat.apache.org/tomcat-7.0-doc/config/ajp.html). 

I wasn't using AS7/EAP6 but an old configuration AS4, and tomcatAuthentication was set to false by adding ajp connector configuration in server/default/deploy/jbossweb-tomcat55.sar/server.xml :
<Connector port="8009" address="${bind.address}" emptySessionPath="true" enableLookup="true" redirectPort="8443" protocol="AJP/1.3" tomcatAuthentication="false" />

It seems to exist a different way to disable tomcatAuthentication in JBoss7.0 (https://issues.jboss.org/browse/WFLY-254).
                
> AJP connector with external authentication
> ------------------------------------------
>
>                 Key: WFLY-2850
>                 URL: https://issues.jboss.org/browse/WFLY-2850
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Web (Undertow)
>    Affects Versions: 8.0.0.CR1
>            Reporter: Geert Coelmont
>            Assignee: Stuart Douglas
>            Priority: Critical
>
> Tomcat allows to set the tomcatAuthentication attribute of the AJP connector to false to allow external web servers (e.g. apache httpd) to handle the authentication and pass that along.
> A similar option was added recently to JBossWeb as well (see WFLY-254), but JBossWeb has been replaced by Undertow. With Undertow this option isn't available as far as I can see.
> For me this is a critical problem as there is currently no way I can do negotiated (SPNEGO) authentication from within WildFly+Undertow. (See also WFLY-2404).

--
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

From issues at jboss.org  Fri Mar 14 06:30:11 2014
From: issues at jboss.org (Petr Kremensky (JIRA))
Date: Fri, 14 Mar 2014 06:30:11 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3117) Add tests for
 add-logging-api-dependencies logging attribute
In-Reply-To: <JIRA.12534994.1394792931017@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534994.1394792931017@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534994.1394792931017.16495.1394793011598@jira02.app.mwc.hst.phx2.redhat.com>

Petr Kremensky created WFLY-3117:
------------------------------------

             Summary: Add tests for add-logging-api-dependencies logging attribute
                 Key: WFLY-3117
                 URL: https://issues.jboss.org/browse/WFLY-3117
             Project: WildFly
          Issue Type: Task
      Security Level: Public (Everyone can see)
          Components: Test Suite
            Reporter: Petr Kremensky
            Assignee: Petr Kremensky


https://issues.jboss.org/browse/PRODMGT-591 introduced a new logging subsystem attribute add-logging-api-dependencies.

Logging dependencies are still added by default. There are already tests in org.jboss.as.test.integration.logging covering default functionality. We have to test the case when logging modules are not available (set value of *add-logging-api-dependencies* to false).

*LoggingDependenciesTestCase*
* start the server
* deploy a archive with dependency on Log4j
* verify that deployment was successful and undeploy it
* set *add-logging-api-dependencies=false*
* reload the server so the changes are propagated
* deploy the archive again
* exception should be thrown this time during deployment


--
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

From issues at jboss.org  Fri Mar 14 07:06:10 2014
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Fri, 14 Mar 2014 07:06:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (SECURITY-805) Overload
 SecurityVaultFactory.get() to be able to specify the classloader
In-Reply-To: <JIRA.12535004.1394795116620@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12535004.1394795116620@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12535004.1394795116620.16637.1394795170784@jira02.app.mwc.hst.phx2.redhat.com>

Kabir Khan created SECURITY-805:
-----------------------------------

             Summary: Overload SecurityVaultFactory.get() to be able to specify the classloader
                 Key: SECURITY-805
                 URL: https://issues.jboss.org/browse/SECURITY-805
             Project: PicketBox 
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
            Reporter: Kabir Khan
            Assignee: Kabir Khan


To work better with modular class loading in WF

--
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

From issues at jboss.org  Fri Mar 14 07:14:10 2014
From: issues at jboss.org (Petr Kremensky (JIRA))
Date: Fri, 14 Mar 2014 07:14:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2648) Review/move the per-logging
 deployment tests
In-Reply-To: <JIRA.12527851.1386875737000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12527851.1386875737000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12527851.1386875737000.16654.1394795650594@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2648?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Petr Kremensky reassigned WFLY-2648:
------------------------------------

    Assignee: Petr Kremensky  (was: James Perkins)

    
> Review/move the per-logging deployment tests
> --------------------------------------------
>
>                 Key: WFLY-2648
>                 URL: https://issues.jboss.org/browse/WFLY-2648
>             Project: WildFly
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite
>            Reporter: James Perkins
>            Assignee: Petr Kremensky
>            Priority: Minor
>
> The {{org.jboss.as.logging.per-deployment}} property has been deprecated. There are two tests {{LoggingPerDeployFalseTestCase}} and {{LoggingPreferencesPerDeployFalseTestCase}} that use this property. They need to be copied and/or moved to the manualmode tests and modified to use the new attribute.
> Also these tests appear not to work correctly. Breaking the system property during the patch, the tests still seemed to pass. They need to be reviewed and tested when working on this issue.

--
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

From issues at jboss.org  Fri Mar 14 07:16:12 2014
From: issues at jboss.org (Petr Kremensky (JIRA))
Date: Fri, 14 Mar 2014 07:16:12 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2648) Review/move the per-logging
 deployment tests
In-Reply-To: <JIRA.12527851.1386875737000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12527851.1386875737000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12527851.1386875737000.16662.1394795772206@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2648?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12953003#comment-12953003 ] 

Petr Kremensky commented on WFLY-2648:
--------------------------------------

I'll take this.
                
> Review/move the per-logging deployment tests
> --------------------------------------------
>
>                 Key: WFLY-2648
>                 URL: https://issues.jboss.org/browse/WFLY-2648
>             Project: WildFly
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite
>            Reporter: James Perkins
>            Assignee: Petr Kremensky
>            Priority: Minor
>
> The {{org.jboss.as.logging.per-deployment}} property has been deprecated. There are two tests {{LoggingPerDeployFalseTestCase}} and {{LoggingPreferencesPerDeployFalseTestCase}} that use this property. They need to be copied and/or moved to the manualmode tests and modified to use the new attribute.
> Also these tests appear not to work correctly. Breaking the system property during the patch, the tests still seemed to pass. They need to be reviewed and tested when working on this issue.

--
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

From issues at jboss.org  Fri Mar 14 07:30:10 2014
From: issues at jboss.org (Sylvain Brouillat (JIRA))
Date: Fri, 14 Mar 2014 07:30:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2850) AJP connector with external
	authentication
In-Reply-To: <JIRA.12530843.1391157375000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530843.1391157375000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530843.1391157375000.16721.1394796610831@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2850?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12952920#comment-12952920 ] 

Sylvain Brouillat edited comment on WFLY-2850 at 3/14/14 7:28 AM:
------------------------------------------------------------------

I wasn't using AS7/EAP6 but an old configuration AS4, and tomcatAuthentication was set to false by adding ajp connector configuration in server/default/deploy/jbossweb-tomcat55.sar/server.xml :
<Connector port="8009" address="bind.address" emptySessionPath="true" enableLookup="true" redirectPort="8443" protocol="AJP/1.3" tomcatAuthentication="false" />

It exists a different way to disable tomcatAuthentication in JBoss7.1 from system-properties (https://issues.jboss.org/browse/WFLY-254).

You've said : "I have implemented an authenticator based on this in Undertow", are you talking about io.undertow.security.impl.ExternalAuthenticationMechanism class ? Is there a way to enable it from wildfly standalone.xml configuration ? Like using <system-properties> or something else ?
                
      was (Author: sylvain.b):
    Tomcat define tomcatAuthentication attribute for ajp connector, that when set to false, disable tomcatAuthentication and allows apache to handle authentication and pass remote_user throught AJP channel to tomcat (http://tomcat.apache.org/tomcat-7.0-doc/config/ajp.html). 

I wasn't using AS7/EAP6 but an old configuration AS4, and tomcatAuthentication was set to false by adding ajp connector configuration in server/default/deploy/jbossweb-tomcat55.sar/server.xml :
<Connector port="8009" address="${bind.address}" emptySessionPath="true" enableLookup="true" redirectPort="8443" protocol="AJP/1.3" tomcatAuthentication="false" />

It seems to exist a different way to disable tomcatAuthentication in JBoss7.0 (https://issues.jboss.org/browse/WFLY-254).
                  
> AJP connector with external authentication
> ------------------------------------------
>
>                 Key: WFLY-2850
>                 URL: https://issues.jboss.org/browse/WFLY-2850
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Web (Undertow)
>    Affects Versions: 8.0.0.CR1
>            Reporter: Geert Coelmont
>            Assignee: Stuart Douglas
>            Priority: Critical
>
> Tomcat allows to set the tomcatAuthentication attribute of the AJP connector to false to allow external web servers (e.g. apache httpd) to handle the authentication and pass that along.
> A similar option was added recently to JBossWeb as well (see WFLY-254), but JBossWeb has been replaced by Undertow. With Undertow this option isn't available as far as I can see.
> For me this is a critical problem as there is currently no way I can do negotiated (SPNEGO) authentication from within WildFly+Undertow. (See also WFLY-2404).

--
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

From issues at jboss.org  Fri Mar 14 07:36:11 2014
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Fri, 14 Mar 2014 07:36:11 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (SECURITY-805) Overload
 SecurityVaultFactory.get() to be able to specify the classloader
In-Reply-To: <JIRA.12535004.1394795116000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12535004.1394795116000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12535004.1394795116000.16729.1394796971010@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/SECURITY-805?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated SECURITY-805:
--------------------------------

    Attachment: SECURITY-805.diff


Attached patch
                
> Overload SecurityVaultFactory.get() to be able to specify the classloader
> -------------------------------------------------------------------------
>
>                 Key: SECURITY-805
>                 URL: https://issues.jboss.org/browse/SECURITY-805
>             Project: PicketBox 
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>            Reporter: Kabir Khan
>            Assignee: Kabir Khan
>         Attachments: SECURITY-805.diff
>
>
> To work better with modular class loading in WF

--
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

From issues at jboss.org  Fri Mar 14 07:36:11 2014
From: issues at jboss.org (Gary Brown (JIRA))
Date: Fri, 14 Mar 2014 07:36:11 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-456) ResourceConfigurationImpl
 class not found when using drools-karaf-feature
In-Reply-To: <JIRA.12535014.1394796959456@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12535014.1394796959456@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12535014.1394796959456.16737.1394796971856@jira02.app.mwc.hst.phx2.redhat.com>

Gary Brown created DROOLS-456:
---------------------------------

             Summary: ResourceConfigurationImpl class not found when using drools-karaf-feature
                 Key: DROOLS-456
                 URL: https://issues.jboss.org/browse/DROOLS-456
             Project: Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions: 6.1.0.Beta1
            Reporter: Gary Brown
            Assignee: Mark Proctor


While porting RTGov to Karaf, I have been using Drools 2.0.0.CR5 successfully.

However when I updated the version to 2.0.1.Final, and subsequently to 2.1.0.Beta1, I now get a class not found issue:

{noformat}
11:26:49,440 | ERROR | l Console Thread | ResourceTypeImpl                 | 290 - org.kie.internalapi - 6.1.0.20140307-1723 | Error loading resource configuration from properties
java.lang.ClassNotFoundException: org.drools.core.builder.conf.impl.ResourceConfigurationImpl not found by org.kie.internalapi [290]
	at org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1532)[org.apache.felix.framework-4.0.3.redhat-610355.jar:]
	at org.apache.felix.framework.BundleWiringImpl.access$400(BundleWiringImpl.java:75)[org.apache.felix.framework-4.0.3.redhat-610355.jar:]
	at org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:1955)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:356)[:1.7.0_07]
	at java.lang.Class.forName0(Native Method)[:1.7.0_07]
	at java.lang.Class.forName(Class.java:186)[:1.7.0_07]
	at org.kie.internal.io.ResourceTypeImpl.fromProperties(ResourceTypeImpl.java:41)[290:org.kie.internalapi:6.1.0.20140307-1723]
{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

From issues at jboss.org  Fri Mar 14 07:38:10 2014
From: issues at jboss.org (Gary Brown (JIRA))
Date: Fri, 14 Mar 2014 07:38:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-456) ResourceConfigurationImpl
 class not found when using drools-karaf-feature
In-Reply-To: <JIRA.12535014.1394796959000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12535014.1394796959000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12535014.1394796959000.16739.1394797090583@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-456?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Gary Brown updated DROOLS-456:
------------------------------

    Attachment: fuse-drools-issue.log

    
> ResourceConfigurationImpl class not found when using drools-karaf-feature
> -------------------------------------------------------------------------
>
>                 Key: DROOLS-456
>                 URL: https://issues.jboss.org/browse/DROOLS-456
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 6.1.0.Beta1
>            Reporter: Gary Brown
>            Assignee: Mark Proctor
>         Attachments: fuse-drools-issue.log
>
>
> While porting RTGov to Karaf, I have been using Drools 2.0.0.CR5 successfully.
> However when I updated the version to 2.0.1.Final, and subsequently to 2.1.0.Beta1, I now get a class not found issue:
> {noformat}
> 11:26:49,440 | ERROR | l Console Thread | ResourceTypeImpl                 | 290 - org.kie.internalapi - 6.1.0.20140307-1723 | Error loading resource configuration from properties
> java.lang.ClassNotFoundException: org.drools.core.builder.conf.impl.ResourceConfigurationImpl not found by org.kie.internalapi [290]
> 	at org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1532)[org.apache.felix.framework-4.0.3.redhat-610355.jar:]
> 	at org.apache.felix.framework.BundleWiringImpl.access$400(BundleWiringImpl.java:75)[org.apache.felix.framework-4.0.3.redhat-610355.jar:]
> 	at org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:1955)
> 	at java.lang.ClassLoader.loadClass(ClassLoader.java:356)[:1.7.0_07]
> 	at java.lang.Class.forName0(Native Method)[:1.7.0_07]
> 	at java.lang.Class.forName(Class.java:186)[:1.7.0_07]
> 	at org.kie.internal.io.ResourceTypeImpl.fromProperties(ResourceTypeImpl.java:41)[290:org.kie.internalapi:6.1.0.20140307-1723]
> {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

From issues at jboss.org  Fri Mar 14 07:54:10 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 14 Mar 2014 07:54:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2644) Java heap space exceeded
 looping connect/disconnect cycle
In-Reply-To: <JIRA.12527822.1386863108000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12527822.1386863108000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12527822.1386863108000.16762.1394798050751@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2644?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12953012#comment-12953012 ] 

RH Bugzilla Integration commented on WFLY-2644:
-----------------------------------------------

Petr Saka? <psakar at redhat.com> changed the Status of [bug 1037574|https://bugzilla.redhat.com/show_bug.cgi?id=1037574] from ON_QA to ASSIGNED
                
> Java heap space exceeded looping connect/disconnect cycle
> ---------------------------------------------------------
>
>                 Key: WFLY-2644
>                 URL: https://issues.jboss.org/browse/WFLY-2644
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: CLI
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Alexey Loubyansky
>            Assignee: Alexey Loubyansky
>             Fix For: 8.0.0.Final
>
>
> CLIModelControllerClient implementation is not cleaning up something related to connection handling which leads to OOME repeating a cycle of ensureConnected(...) and close(). On my laptop it happens after around 1400 iterations.

--
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


From issues at jboss.org  Fri Mar 14 08:16:11 2014
From: issues at jboss.org (Mariano De Maio (JIRA))
Date: Fri, 14 Mar 2014 08:16:11 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-457) TaskModelProvider's
 ServiceLoader sync problem
In-Reply-To: <JIRA.12535022.1394799288581@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12535022.1394799288581@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12535022.1394799288581.16792.1394799371167@jira02.app.mwc.hst.phx2.redhat.com>

Mariano De Maio created DROOLS-457:
--------------------------------------

             Summary: TaskModelProvider's ServiceLoader sync problem
                 Key: DROOLS-457
                 URL: https://issues.jboss.org/browse/DROOLS-457
             Project: Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions: 6.1.0.Beta1, 6.0.1.Final, 6.0.0.Final, 6.1.0.Beta2, 6.1.0.Final
            Reporter: Mariano De Maio
            Assignee: Mark Proctor


This bug was found related to jBPM6 components, but its solution needs to be implemented in the kie-internal project, hence we report it in this project.

When the TaskModelProvider access the factory object, it iterates the service loader directly. Unfortunately, the ServiceLoader class states:

"Instances of this class are not safe for use by multiple concurrent threads." (http://docs.oracle.com/javase/6/docs/api/java/util/ServiceLoader.html)

This causes that environments that need to use the TaskModelProvider from different threads with no prior invocation.

I'll add a maven test to reproduce the issue. We have also a solution we'll submit in a pull request

--
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

From issues at jboss.org  Fri Mar 14 08:18:10 2014
From: issues at jboss.org (Mariano De Maio (JIRA))
Date: Fri, 14 Mar 2014 08:18:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-457) TaskModelProvider's
 ServiceLoader sync problem
In-Reply-To: <JIRA.12535022.1394799288000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12535022.1394799288000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12535022.1394799288000.16796.1394799490557@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-457?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mariano De Maio updated DROOLS-457:
-----------------------------------

    Attachment: test-case.zip


Test case project attachment
                
> TaskModelProvider's ServiceLoader sync problem
> ----------------------------------------------
>
>                 Key: DROOLS-457
>                 URL: https://issues.jboss.org/browse/DROOLS-457
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 6.0.0.Final, 6.0.1.Final, 6.1.0.Beta1, 6.1.0.Beta2, 6.1.0.Final
>            Reporter: Mariano De Maio
>            Assignee: Mark Proctor
>         Attachments: test-case.zip
>
>
> This bug was found related to jBPM6 components, but its solution needs to be implemented in the kie-internal project, hence we report it in this project.
> When the TaskModelProvider access the factory object, it iterates the service loader directly. Unfortunately, the ServiceLoader class states:
> "Instances of this class are not safe for use by multiple concurrent threads." (http://docs.oracle.com/javase/6/docs/api/java/util/ServiceLoader.html)
> This causes that environments that need to use the TaskModelProvider from different threads with no prior invocation.
> I'll add a maven test to reproduce the issue. We have also a solution we'll submit in a pull request

--
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

From issues at jboss.org  Fri Mar 14 08:40:11 2014
From: issues at jboss.org (Jeremy Whiting (JIRA))
Date: Fri, 14 Mar 2014 08:40:11 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBWEB-295) maxTime attribute statistic
 initial display value.
In-Reply-To: <JIRA.12535023.1394800754536@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12535023.1394800754536@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12535023.1394800754536.16840.1394800811047@jira02.app.mwc.hst.phx2.redhat.com>

Jeremy Whiting created JBWEB-295:
------------------------------------

             Summary: maxTime attribute statistic initial display value.
                 Key: JBWEB-295
                 URL: https://issues.jboss.org/browse/JBWEB-295
             Project: JBoss Web
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Core
    Affects Versions: JBossWeb-7.3.0.GA
         Environment: Linux.
3.13.5-103.fc19.x86_64
            Reporter: Jeremy Whiting
            Assignee: Remy Maucherat


The initial maxTime attribute value when queried on a servlet using the CLI displays a very large value 9223372036854775807L.  The expected value is 0 for a system that has just been started and no requests have been processed for the servlet.
 


--
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

From issues at jboss.org  Fri Mar 14 08:40:11 2014
From: issues at jboss.org (Jeremy Whiting (JIRA))
Date: Fri, 14 Mar 2014 08:40:11 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBWEB-295) maxTime attribute statistic
 initial display value.
In-Reply-To: <JIRA.12535023.1394800754000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12535023.1394800754000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12535023.1394800754000.16845.1394800811300@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBWEB-295?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jeremy Whiting updated JBWEB-295:
---------------------------------

    Environment: 
Linux.
3.13.5-103.fc19.x86_64
openjdk 1.7

  was:
Linux.
3.13.5-103.fc19.x86_64


    
> maxTime attribute statistic initial display value.
> --------------------------------------------------
>
>                 Key: JBWEB-295
>                 URL: https://issues.jboss.org/browse/JBWEB-295
>             Project: JBoss Web
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Core
>    Affects Versions: JBossWeb-7.3.0.GA
>         Environment: Linux.
> 3.13.5-103.fc19.x86_64
> openjdk 1.7
>            Reporter: Jeremy Whiting
>            Assignee: Remy Maucherat
>              Labels: attribute, maxTime, statistics
>
> The initial maxTime attribute value when queried on a servlet using the CLI displays a very large value 9223372036854775807L.  The expected value is 0 for a system that has just been started and no requests have been processed for the servlet.
>  

--
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

From issues at jboss.org  Fri Mar 14 08:58:10 2014
From: issues at jboss.org (Jesper Pedersen (JIRA))
Date: Fri, 14 Mar 2014 08:58:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBJCA-1155) IronJacamar under security
 manager throws exception
In-Reply-To: <JIRA.12535028.1394801854379@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12535028.1394801854379@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12535028.1394801854379.16899.1394801890879@jira02.app.mwc.hst.phx2.redhat.com>

Jesper Pedersen created JBJCA-1155:
--------------------------------------

             Summary: IronJacamar under security manager throws exception
                 Key: JBJCA-1155
                 URL: https://issues.jboss.org/browse/JBJCA-1155
             Project: IronJacamar
          Issue Type: Bug
    Affects Versions: 1.1.4.Final, 1.0.24.Final
            Reporter: Jesper Pedersen
            Assignee: Jesper Pedersen
            Priority: Blocker
             Fix For: 1.0.25.Final, 1.1.5.Final, 1.2.0.CR1




--
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

From issues at jboss.org  Fri Mar 14 09:12:10 2014
From: issues at jboss.org (Bela Ban (JIRA))
Date: Fri, 14 Mar 2014 09:12:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1765) TP: enable loopback by
 default and discard own multicasts
In-Reply-To: <JIRA.12528488.1388489261000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528488.1388489261000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528488.1388489261000.16945.1394802730840@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JGRP-1765?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban resolved JGRP-1765.
----------------------------

    Resolution: Done


By default, messages looped back up are not copied (governed by {{loopback_copy}}). Also, looped back messages are delivered in a separate thread (configurable via {{loopback_separate_thread}}).
                
> TP: enable loopback by default and discard own multicasts
> ---------------------------------------------------------
>
>                 Key: JGRP-1765
>                 URL: https://issues.jboss.org/browse/JGRP-1765
>             Project: JGroups
>          Issue Type: Enhancement
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 3.5
>
>
> Enable {{TP.looback}} by default (deprecate and ignore prop): all messages sent by self are passed right to a thread pool to send them up again.
> When a multicast message sent by self is received, it is currently passed to a thread pool, de-serialized and only then discarded if loopback=true. This means that we create an unneeded buffer for de-serializationand perform de-serialization.
> SOLUTION: discard the multicast from self immediately when receiving it, in {{TP.receive()}}

--
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

From issues at jboss.org  Fri Mar 14 09:14:10 2014
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Fri, 14 Mar 2014 09:14:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3118) <vault> does not have module
	option
In-Reply-To: <JIRA.12535031.1394802647000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12535031.1394802647000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12535031.1394802647000.16949.1394802850709@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-3118?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan moved EAP6-192 to WFLY-3118:
---------------------------------------

              Project: WildFly  (was: EAP 6 Planning Pilot)
                  Key: WFLY-3118  (was: EAP6-192)
           Issue Type: Feature Request  (was: Requirement)
             Workflow: GIT Pull Request workflow   (was: CDW v1)
    Affects Version/s:     (was: 6.3.0.GA)
          Component/s: Security
                           (was: Security)
             Security: Public
       Target Release:   (was: 6.3.0.GA)

    
> <vault> does not have module option
> -----------------------------------
>
>                 Key: WFLY-3118
>                 URL: https://issues.jboss.org/browse/WFLY-3118
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Security
>            Reporter: Derek Horton
>            Assignee: Jimmy Wilson
>
> The <vault> element in standalone/domain.xml takes a 'code' attribute specifying the class to use as the implementation. It does not let you specify a 'module' option like most similar elements have, and instead always loads the class from the org.picketbox module.
> The <vault> element should take a module option too.
> The current workaround is to add the custom vault module as a dependency in the org.picketbox module.
> Additionally, hanging any module.xml can also result in patching conflicts when customers apply future updates.
> Since we have a quite a few customers writing custom vault implementations for various pieces of functionality that it doesn't provide out of the box, we should consider making this type of customer-initiated change patch safe for customers.

--
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

From issues at jboss.org  Fri Mar 14 09:14:10 2014
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Fri, 14 Mar 2014 09:14:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3118) <vault> does not have module
	option
In-Reply-To: <JIRA.12535031.1394802647000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12535031.1394802647000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12535031.1394802647000.16954.1394802850987@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-3118?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan reassigned WFLY-3118:
--------------------------------

    Assignee: Kabir Khan  (was: Jimmy Wilson)

    
> <vault> does not have module option
> -----------------------------------
>
>                 Key: WFLY-3118
>                 URL: https://issues.jboss.org/browse/WFLY-3118
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Security
>            Reporter: Derek Horton
>            Assignee: Kabir Khan
>
> The <vault> element in standalone/domain.xml takes a 'code' attribute specifying the class to use as the implementation. It does not let you specify a 'module' option like most similar elements have, and instead always loads the class from the org.picketbox module.
> The <vault> element should take a module option too.
> The current workaround is to add the custom vault module as a dependency in the org.picketbox module.
> Additionally, hanging any module.xml can also result in patching conflicts when customers apply future updates.
> Since we have a quite a few customers writing custom vault implementations for various pieces of functionality that it doesn't provide out of the box, we should consider making this type of customer-initiated change patch safe for customers.

--
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

From issues at jboss.org  Fri Mar 14 09:32:11 2014
From: issues at jboss.org (Radoslav Husar (JIRA))
Date: Fri, 14 Mar 2014 09:32:11 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3112) One can't change history and
 decay with DynamicLoadBalanceFactorProvider
In-Reply-To: <JIRA.12534709.1394560666000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534709.1394560666000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534709.1394560666000.17006.1394803931304@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-3112?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Radoslav Husar updated WFLY-3112:
---------------------------------

    Bugzilla Update:   (was: Perform)

    
> One can't change history and decay with DynamicLoadBalanceFactorProvider
> ------------------------------------------------------------------------
>
>                 Key: WFLY-3112
>                 URL: https://issues.jboss.org/browse/WFLY-3112
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Clustering
>    Affects Versions: 8.0.0.Final
>            Reporter: Michal Babacek
>            Assignee: Radoslav Husar
>            Priority: Critical
>             Fix For: 8.0.1.Final
>
>         Attachments: redacted_log
>
>
> I'm under an ugly impression that one can't actually change {{history}} and {{decay}} attributes of *DynamicLoadBalanceFactorProvider*.
> I was trying to figure out why the new test suite of CustomLoadMetric tests does not pass. In order to get load figures without history and decay manipulation, I set the following:
> {code}
> <subsystem xmlns="urn:jboss:domain:modcluster:1.2">
>     <mod-cluster-config advertise-socket="modcluster" connector="ajp">
>     <dynamic-load-provider history="0">
>         <custom-load-metric class="biz.karms.modcluster.CustomLoadMetric" weight="1">
>             <property name="capacity" value="1000"/>
>             <property name="loadfile" value="/tmp/mod_cluster-eapx/loadfileA"/>
>             <property name="parseexpression" value="^LOAD: ([0-9]*)$"/>
>         </custom-load-metric>
>     </dynamic-load-provider>
>     </mod-cluster-config>
> </subsystem>
> {code}
> The aforementioned {{history=0}} effectively means that there is just 1 "slot" for a one historical value on which decay function should work.
> If you take a look at the code in [DynamicLoadBalanceFactorProvider|https://github.com/modcluster/mod_cluster/blob/master/core/src/main/java/org/jboss/modcluster/load/impl/DynamicLoadBalanceFactorProvider.java#L54] constructor, it is apparent
> that the size of the List that later serves for storing the historical values is set sooner than the actual [setHistory(int history)|https://github.com/modcluster/mod_cluster/blob/master/core/src/main/java/org/jboss/modcluster/load/impl/DynamicLoadBalanceFactorProvider.java#L177] method is called.
> The actual size of that List collection wouldn't do any harm by itself but it is being used in the aforementioned class with {{.size()}} to control cycles.
> The same IMHO holds for the decay attribute.
> Anyhow, I put some additional logging to the [DynamicLoadBalanceFactorProvider.java|https://github.com/modcluster/mod_cluster/blob/master/core/src/main/java/org/jboss/modcluster/load/impl/DynamicLoadBalanceFactorProvider.java]:
> {code}
> // Historical value contribute an exponentially decayed factor
> for (int i = 0; i < queue.size(); ++i) {
>     double decay = 1 / Math.pow(decayFactor, i);
>     totalDecay += decay;
>     this.log.info("KTAG: totalLoad:"+totalLoad+", with decay:"+(totalLoad+queue.get(i).doubleValue() * decay));
>     totalLoad += queue.get(i).doubleValue() * decay;
> }
> {code}
> and
> {code}
> try {
>     // Normalize load with respect to capacity
>     this.recordLoad(metricLoadHistory, metric.getLoad(engine) / metric.getCapacity());
>     this.log.info("KTAG metricLoadHistory:"+metricLoadHistory.toString());
>     totalWeight += weight;
>     totalWeightedLoad += this.average(metricLoadHistory) * weight;
> } catch (Exception e) {
>     this.log.error(e.getLocalizedMessage(), e);
> }
> {code}
> with the following being the output: [^redacted_log].
> So, despite having {{history=0}}, which should force the system to keep just 1, the current value, {{metricLoadHistory}} grew from
> {noformat}
> KTAG metricLoadHistory:[0.8]
> {noformat}
> to
> {noformat}
> KTAG metricLoadHistory:[0.9, 0.9, 0.9, 0.9, 0.9, 0.9, 0.9, 0.9, 0.9, 0.8]
> {noformat}
> which is exactly [9|https://github.com/modcluster/mod_cluster/blob/master/core/src/main/java/org/jboss/modcluster/load/impl/DynamicLoadBalanceFactorProvider.java#L50] + [1|https://github.com/modcluster/mod_cluster/blob/master/core/src/main/java/org/jboss/modcluster/load/impl/DynamicLoadBalanceFactorProvider.java#L54] in size :-)
> WDYT?

--
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

From issues at jboss.org  Fri Mar 14 09:36:10 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 14 Mar 2014 09:36:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3112) One can't change history and
 decay with DynamicLoadBalanceFactorProvider
In-Reply-To: <JIRA.12534709.1394560666000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534709.1394560666000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534709.1394560666000.17027.1394804170592@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-3112?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12953043#comment-12953043 ] 

RH Bugzilla Integration commented on WFLY-3112:
-----------------------------------------------

Radoslav Husar <rhusar at redhat.com> changed the Status of [bug 1075215|https://bugzilla.redhat.com/show_bug.cgi?id=1075215] from ASSIGNED to POST
                
> One can't change history and decay with DynamicLoadBalanceFactorProvider
> ------------------------------------------------------------------------
>
>                 Key: WFLY-3112
>                 URL: https://issues.jboss.org/browse/WFLY-3112
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Clustering
>    Affects Versions: 8.0.0.Final
>            Reporter: Michal Babacek
>            Assignee: Radoslav Husar
>            Priority: Critical
>             Fix For: 8.0.1.Final
>
>         Attachments: redacted_log
>
>
> I'm under an ugly impression that one can't actually change {{history}} and {{decay}} attributes of *DynamicLoadBalanceFactorProvider*.
> I was trying to figure out why the new test suite of CustomLoadMetric tests does not pass. In order to get load figures without history and decay manipulation, I set the following:
> {code}
> <subsystem xmlns="urn:jboss:domain:modcluster:1.2">
>     <mod-cluster-config advertise-socket="modcluster" connector="ajp">
>     <dynamic-load-provider history="0">
>         <custom-load-metric class="biz.karms.modcluster.CustomLoadMetric" weight="1">
>             <property name="capacity" value="1000"/>
>             <property name="loadfile" value="/tmp/mod_cluster-eapx/loadfileA"/>
>             <property name="parseexpression" value="^LOAD: ([0-9]*)$"/>
>         </custom-load-metric>
>     </dynamic-load-provider>
>     </mod-cluster-config>
> </subsystem>
> {code}
> The aforementioned {{history=0}} effectively means that there is just 1 "slot" for a one historical value on which decay function should work.
> If you take a look at the code in [DynamicLoadBalanceFactorProvider|https://github.com/modcluster/mod_cluster/blob/master/core/src/main/java/org/jboss/modcluster/load/impl/DynamicLoadBalanceFactorProvider.java#L54] constructor, it is apparent
> that the size of the List that later serves for storing the historical values is set sooner than the actual [setHistory(int history)|https://github.com/modcluster/mod_cluster/blob/master/core/src/main/java/org/jboss/modcluster/load/impl/DynamicLoadBalanceFactorProvider.java#L177] method is called.
> The actual size of that List collection wouldn't do any harm by itself but it is being used in the aforementioned class with {{.size()}} to control cycles.
> The same IMHO holds for the decay attribute.
> Anyhow, I put some additional logging to the [DynamicLoadBalanceFactorProvider.java|https://github.com/modcluster/mod_cluster/blob/master/core/src/main/java/org/jboss/modcluster/load/impl/DynamicLoadBalanceFactorProvider.java]:
> {code}
> // Historical value contribute an exponentially decayed factor
> for (int i = 0; i < queue.size(); ++i) {
>     double decay = 1 / Math.pow(decayFactor, i);
>     totalDecay += decay;
>     this.log.info("KTAG: totalLoad:"+totalLoad+", with decay:"+(totalLoad+queue.get(i).doubleValue() * decay));
>     totalLoad += queue.get(i).doubleValue() * decay;
> }
> {code}
> and
> {code}
> try {
>     // Normalize load with respect to capacity
>     this.recordLoad(metricLoadHistory, metric.getLoad(engine) / metric.getCapacity());
>     this.log.info("KTAG metricLoadHistory:"+metricLoadHistory.toString());
>     totalWeight += weight;
>     totalWeightedLoad += this.average(metricLoadHistory) * weight;
> } catch (Exception e) {
>     this.log.error(e.getLocalizedMessage(), e);
> }
> {code}
> with the following being the output: [^redacted_log].
> So, despite having {{history=0}}, which should force the system to keep just 1, the current value, {{metricLoadHistory}} grew from
> {noformat}
> KTAG metricLoadHistory:[0.8]
> {noformat}
> to
> {noformat}
> KTAG metricLoadHistory:[0.9, 0.9, 0.9, 0.9, 0.9, 0.9, 0.9, 0.9, 0.9, 0.8]
> {noformat}
> which is exactly [9|https://github.com/modcluster/mod_cluster/blob/master/core/src/main/java/org/jboss/modcluster/load/impl/DynamicLoadBalanceFactorProvider.java#L50] + [1|https://github.com/modcluster/mod_cluster/blob/master/core/src/main/java/org/jboss/modcluster/load/impl/DynamicLoadBalanceFactorProvider.java#L54] in size :-)
> WDYT?

--
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

From issues at jboss.org  Fri Mar 14 09:40:11 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 14 Mar 2014 09:40:11 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1904) Usage of vault for
 system-properties throws java.lang.SecurityException
In-Reply-To: <JIRA.12498944.1376977640000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12498944.1376977640000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12498944.1376977640000.17047.1394804411254@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-1904?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated WFLY-1904:
------------------------------------------

        Bugzilla Update: Perform
    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=901275, https://bugzilla.redhat.com/show_bug.cgi?id=1076507  (was: https://bugzilla.redhat.com/show_bug.cgi?id=901275)

    
> Usage of vault for system-properties throws java.lang.SecurityException
> -----------------------------------------------------------------------
>
>                 Key: WFLY-1904
>                 URL: https://issues.jboss.org/browse/WFLY-1904
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Security
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Navin Surtani
>            Assignee: Brian Stansberry
>             Fix For: 8.0.1.Final
>
>
> Steps to Reproduce: 1. add the lines in standalone.xml:-
> {code}
>     <system-properties>
>       <property name="javax.net.ssl.trustStore" value="/dir/truststore.jks"/>
>       <property name="javax.net.ssl.trustStorePassword" value="${VAULT::blk::attr::MTBlYWUzNDEtMjI2MC00NWYzLWFiZmUtM2EyYjZkNDgyZWM4TElORV9CUkVBS215YWxpYXM=}" />
>     </system-properties>
>     <vault>
>         <vault-option name="KEYSTORE_URL" value="/opt/jboss-eap-6.0/standalone/configuration/vault.jks"/>
>         <vault-option name="KEYSTORE_PASSWORD" value="MASK-2gTQPnrWJaqrh0pURMKAOw"/>
>         <vault-option name="KEYSTORE_ALIAS" value="myalias"/>
>         <vault-option name="SALT" value="12345678"/>
>         <vault-option name="ITERATION_COUNT" value="44"/>
>         <vault-option name="ENC_FILE_DIR" value="/opt/jboss-eap-6.0/standalone/configuration/"/>
>     </vault>
> {code}
> 2. start EAP6 in standalone mode
> project_key: JBPAPP6
> Usage of vault for system-properties throws java.lang.SecurityException.
> boot.log:-
> {code}
> 20:35:30,267 ERROR [org.jboss.as.controller.management-operation] JBAS014612: Operation ("add") failed - address: ([("system-property" => "javax.net.ssl.trustStorePassword")]): java.lang.SecurityException: JBAS013322: Vault is not initialized
> 	at org.jboss.as.security.vault.RuntimeVaultReader.retrieveFromVault(RuntimeVaultReader.java:98) [jboss-as-security-7.1.2.Final-redhat-1.jar:7.1.2.Final-redhat-1]
> 	at org.jboss.as.server.RuntimeExpressionResolver.resolvePluggableExpression(RuntimeExpressionResolver.java:45) [jboss-as-server-7.1.2.Final-redhat-1.jar:7.1.2.Final-redhat-1]
> 	at org.jboss.as.controller.ExpressionResolverImpl.resolveExpressionsRecursively(ExpressionResolverImpl.java:58) [jboss-as-controller-7.1.2.Final-redhat-1.jar:7.1.2.Final-redhat-1]
> 	at org.jboss.as.controller.ExpressionResolverImpl.resolveExpressions(ExpressionResolverImpl.java:40) [jboss-as-controller-7.1.2.Final-redhat-1.jar:7.1.2.Final-redhat-1]
> 	at org.jboss.as.controller.ModelControllerImpl.resolveExpressions(ModelControllerImpl.java:455) [jboss-as-controller-7.1.2.Final-redhat-1.jar:7.1.2.Final-redhat-1]
> 	at org.jboss.as.controller.OperationContextImpl.resolveExpressions(OperationContextImpl.java:689) [jboss-as-controller-7.1.2.Final-redhat-1.jar:7.1.2.Final-redhat-1]
> 	at org.jboss.as.controller.operations.common.SystemPropertyAddHandler.execute(SystemPropertyAddHandler.java:112) [jboss-as-controller-7.1.2.Final-redhat-1.jar:7.1.2.Final-redhat-1]
> 	at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:397) [jboss-as-controller-7.1.2.Final-redhat-1.jar:7.1.2.Final-redhat-1]
> 	at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:284) [jboss-as-controller-7.1.2.Final-redhat-1.jar:7.1.2.Final-redhat-1]
> 	at org.jboss.as.controller.AbstractOperationContext.completeStep(AbstractOperationContext.java:211) [jboss-as-controller-7.1.2.Final-redhat-1.jar:7.1.2.Final-redhat-1]
> 	at org.jboss.as.controller.ModelControllerImpl.boot(ModelControllerImpl.java:175) [jboss-as-controller-7.1.2.Final-redhat-1.jar:7.1.2.Final-redhat-1]
> 	at org.jboss.as.controller.AbstractControllerService.boot(AbstractControllerService.java:191) [jboss-as-controller-7.1.2.Final-redhat-1.jar:7.1.2.Final-redhat-1]
> 	at org.jboss.as.server.ServerService.boot(ServerService.java:295) [jboss-as-server-7.1.2.Final-redhat-1.jar:7.1.2.Final-redhat-1]
> 	at org.jboss.as.server.ServerService.boot(ServerService.java:270) [jboss-as-server-7.1.2.Final-redhat-1.jar:7.1.2.Final-redhat-1]
> 	at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:156) [jboss-as-controller-7.1.2.Final-redhat-1.jar:7.1.2.Final-redhat-1]
> 	at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_37]
> {code}

--
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

From issues at jboss.org  Fri Mar 14 10:00:12 2014
From: issues at jboss.org (Wolf-Dieter Fink (JIRA))
Date: Fri, 14 Mar 2014 10:00:12 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3119) Management console did not
 show the file path correct if an expression is used
In-Reply-To: <JIRA.12535036.1394805552149@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12535036.1394805552149@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12535036.1394805552149.17251.1394805612607@jira02.app.mwc.hst.phx2.redhat.com>

Wolf-Dieter Fink created WFLY-3119:
--------------------------------------

             Summary: Management console did not show the file path correct if an expression is used
                 Key: WFLY-3119
                 URL: https://issues.jboss.org/browse/WFLY-3119
             Project: WildFly
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Domain Management, Web Console
    Affects Versions: 8.0.0.Final
            Reporter: Wolf-Dieter Fink
            Assignee: Brian Stansberry


If the <file path=> attribute of a file-handler contains an expression the management console show this as "undifined".
Change the attribute is possible anyhow an expression is used.

The CLI show the correct expression:
[standalone at localhost:9990 /] /subsystem=logging/periodic-rotating-file-handler=FILE:read-resource
{
    "outcome" => "success",
    "result" => {
        "append" => true,
        "autoflush" => true,
        "enabled" => true,
        "encoding" => undefined,
        "file" => {
            "relative-to" => "jboss.server.log.dir",
            "path" => expression "${jboss.server.name}"
        },
        "filter" => undefined,
        "filter-spec" => undefined,
        "formatter" => "%d{HH:mm:ss,SSS} %-5p [%c] (%t) %s%E%n",
        "level" => "ALL",
        "name" => "FILE",
        "named-formatter" => "PATTERN",
        "suffix" => ".yyyy-MM-dd"
    }
}


--
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

From issues at jboss.org  Fri Mar 14 10:14:11 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 14 Mar 2014 10:14:11 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3007) Ipv6 addresses may not be
 canonized properly
In-Reply-To: <JIRA.12533139.1393261818000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12533139.1393261818000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12533139.1393261818000.17380.1394806451370@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-3007?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12953094#comment-12953094 ] 

RH Bugzilla Integration commented on WFLY-3007:
-----------------------------------------------

Pavel Jelinek <pjelinek at redhat.com> changed the Status of [bug 1067348|https://bugzilla.redhat.com/show_bug.cgi?id=1067348] from ON_QA to ASSIGNED
                
> Ipv6 addresses may not be canonized properly
> --------------------------------------------
>
>                 Key: WFLY-3007
>                 URL: https://issues.jboss.org/browse/WFLY-3007
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 8.0.0.Final
>            Reporter: Emmanuel Hugonnet
>            Assignee: Emmanuel Hugonnet
>
> On an ipv6 environment we may obtain IP addresses that are not properly canonized which may lead to strange issue with http proxies since the JDK ProxySelector relies on char per char matching.
> All call to InetAddress.getHostName() may produce such an uncanonized address.

--
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

From issues at jboss.org  Fri Mar 14 10:32:10 2014
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Fri, 14 Mar 2014 10:32:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (SECURITY-805) Overload
 SecurityVaultFactory.get() to be able to specify the classloader
In-Reply-To: <JIRA.12535004.1394795116000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12535004.1394795116000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12535004.1394795116000.17478.1394807530830@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/SECURITY-805?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated SECURITY-805:
--------------------------------

    Attachment: SECURITY-805-2.diff

    
> Overload SecurityVaultFactory.get() to be able to specify the classloader
> -------------------------------------------------------------------------
>
>                 Key: SECURITY-805
>                 URL: https://issues.jboss.org/browse/SECURITY-805
>             Project: PicketBox 
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>            Reporter: Kabir Khan
>            Assignee: Kabir Khan
>         Attachments: SECURITY-805-2.diff, SECURITY-805.diff
>
>
> To work better with modular class loading in WF

--
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

From issues at jboss.org  Fri Mar 14 10:36:12 2014
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Fri, 14 Mar 2014 10:36:12 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (SECURITY-805) Overload
 SecurityVaultFactory.get() to be able to specify the classloader
In-Reply-To: <JIRA.12535004.1394795116000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12535004.1394795116000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12535004.1394795116000.17498.1394807772696@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/SECURITY-805?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated SECURITY-805:
--------------------------------

    Attachment:     (was: SECURITY-805-2.diff)

    
> Overload SecurityVaultFactory.get() to be able to specify the classloader
> -------------------------------------------------------------------------
>
>                 Key: SECURITY-805
>                 URL: https://issues.jboss.org/browse/SECURITY-805
>             Project: PicketBox 
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>            Reporter: Kabir Khan
>            Assignee: Kabir Khan
>         Attachments: SECURITY-805.diff
>
>
> To work better with modular class loading in WF

--
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

From issues at jboss.org  Fri Mar 14 10:38:11 2014
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Fri, 14 Mar 2014 10:38:11 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (SECURITY-805) Overload
 SecurityVaultFactory.get() to be able to specify the classloader
In-Reply-To: <JIRA.12535004.1394795116000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12535004.1394795116000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12535004.1394795116000.17508.1394807891104@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/SECURITY-805?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated SECURITY-805:
--------------------------------

    Attachment: SECURITY-805-2.diff

    
> Overload SecurityVaultFactory.get() to be able to specify the classloader
> -------------------------------------------------------------------------
>
>                 Key: SECURITY-805
>                 URL: https://issues.jboss.org/browse/SECURITY-805
>             Project: PicketBox 
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>            Reporter: Kabir Khan
>            Assignee: Kabir Khan
>         Attachments: SECURITY-805-2.diff, SECURITY-805.diff
>
>
> To work better with modular class loading in WF

--
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

From issues at jboss.org  Fri Mar 14 11:02:10 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 14 Mar 2014 11:02:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3007) Ipv6 addresses may not be
 canonized properly
In-Reply-To: <JIRA.12533139.1393261818000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12533139.1393261818000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12533139.1393261818000.17659.1394809330966@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-3007?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12953125#comment-12953125 ] 

RH Bugzilla Integration commented on WFLY-3007:
-----------------------------------------------

Pavel Jelinek <pjelinek at redhat.com> changed the Status of [bug 1067348|https://bugzilla.redhat.com/show_bug.cgi?id=1067348] from ASSIGNED to ON_QA
                
> Ipv6 addresses may not be canonized properly
> --------------------------------------------
>
>                 Key: WFLY-3007
>                 URL: https://issues.jboss.org/browse/WFLY-3007
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 8.0.0.Final
>            Reporter: Emmanuel Hugonnet
>            Assignee: Emmanuel Hugonnet
>
> On an ipv6 environment we may obtain IP addresses that are not properly canonized which may lead to strange issue with http proxies since the JDK ProxySelector relies on char per char matching.
> All call to InetAddress.getHostName() may produce such an uncanonized address.

--
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

From issues at jboss.org  Fri Mar 14 11:16:11 2014
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Fri, 14 Mar 2014 11:16:11 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (SECURITY-805) Overload
 SecurityVaultFactory.get() to be able to specify the classloader
In-Reply-To: <JIRA.12535004.1394795116000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12535004.1394795116000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12535004.1394795116000.17978.1394810171879@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/SECURITY-805?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated SECURITY-805:
--------------------------------

    Attachment:     (was: SECURITY-805-2.diff)

    
> Overload SecurityVaultFactory.get() to be able to specify the classloader
> -------------------------------------------------------------------------
>
>                 Key: SECURITY-805
>                 URL: https://issues.jboss.org/browse/SECURITY-805
>             Project: PicketBox 
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>            Reporter: Kabir Khan
>            Assignee: Kabir Khan
>         Attachments: SECURITY-805-2.diff, SECURITY-805.diff
>
>
> To work better with modular class loading in WF

--
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

From issues at jboss.org  Fri Mar 14 11:16:12 2014
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Fri, 14 Mar 2014 11:16:12 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (SECURITY-805) Overload
 SecurityVaultFactory.get() to be able to specify the classloader
In-Reply-To: <JIRA.12535004.1394795116000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12535004.1394795116000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12535004.1394795116000.17985.1394810172303@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/SECURITY-805?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated SECURITY-805:
--------------------------------

    Attachment: SECURITY-805-2.diff

    
> Overload SecurityVaultFactory.get() to be able to specify the classloader
> -------------------------------------------------------------------------
>
>                 Key: SECURITY-805
>                 URL: https://issues.jboss.org/browse/SECURITY-805
>             Project: PicketBox 
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>            Reporter: Kabir Khan
>            Assignee: Kabir Khan
>         Attachments: SECURITY-805-2.diff, SECURITY-805.diff
>
>
> To work better with modular class loading in WF

--
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

From issues at jboss.org  Fri Mar 14 11:38:10 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 14 Mar 2014 11:38:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3106) Infinispan cache statistics
 cannot be enabled/disabled independently of the cache manager statistics
In-Reply-To: <JIRA.12534838.1394655920000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534838.1394655920000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534838.1394655920000.18227.1394811490748@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-3106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12953171#comment-12953171 ] 

RH Bugzilla Integration commented on WFLY-3106:
-----------------------------------------------

Kabir Khan <kkhan at redhat.com> changed the Status of [bug 1025023|https://bugzilla.redhat.com/show_bug.cgi?id=1025023] from POST to MODIFIED
                
> Infinispan cache statistics cannot be enabled/disabled independently of the cache manager statistics    
> --------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-3106
>                 URL: https://issues.jboss.org/browse/WFLY-3106
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Clustering
>    Affects Versions: 8.0.0.Final
>            Reporter: Richard Achmatowicz
>            Assignee: Richard Achmatowicz
>             Fix For: 8.0.1.Final
>
>
> The Infinispan subsystem allows enabling and disabling the collection of statistics for cache managers and caches via the "statistics-enabled" management API attribute.
> It is possible to set statistics-enabled attributes independently for cache managers and caches in the management API, but when checking the Infinispan MBeans, we see that statistics are either enabled for cache managers and their caches, or disabled for cache managers and caches.  

--
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

From issues at jboss.org  Fri Mar 14 11:38:11 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 14 Mar 2014 11:38:11 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2415) Add configuration option to
 enable/disable Infinispan statistics
In-Reply-To: <JIRA.12509131.1383157408000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12509131.1383157408000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12509131.1383157408000.18241.1394811491367@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2415?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12953173#comment-12953173 ] 

RH Bugzilla Integration commented on WFLY-2415:
-----------------------------------------------

Kabir Khan <kkhan at redhat.com> changed the Status of [bug 1025023|https://bugzilla.redhat.com/show_bug.cgi?id=1025023] from POST to MODIFIED
                
> Add configuration option to enable/disable Infinispan statistics
> ----------------------------------------------------------------
>
>                 Key: WFLY-2415
>                 URL: https://issues.jboss.org/browse/WFLY-2415
>             Project: WildFly
>          Issue Type: Enhancement
>      Security Level: Public(Everyone can see) 
>          Components: Clustering
>            Reporter: Scott Marlow
>            Assignee: Paul Ferraro
>             Fix For: 8.0.0.CR1
>
>
> When the Infinispan MBean is enabled, Infinispan statistics are enabled by default.  Could we allow Infinispan statistics to be enabled/disabled via a WF configuration setting?

--
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

From issues at jboss.org  Fri Mar 14 11:52:10 2014
From: issues at jboss.org (James Perkins (JIRA))
Date: Fri, 14 Mar 2014 11:52:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2648) Review/move the per-logging
 deployment tests
In-Reply-To: <JIRA.12527851.1386875737000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12527851.1386875737000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12527851.1386875737000.18357.1394812330971@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2648?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12953187#comment-12953187 ] 

James Perkins commented on WFLY-2648:
-------------------------------------

Excellent, thanks Petr! Just ping me if you have any questions. I have some vague memories of the issues :)
                
> Review/move the per-logging deployment tests
> --------------------------------------------
>
>                 Key: WFLY-2648
>                 URL: https://issues.jboss.org/browse/WFLY-2648
>             Project: WildFly
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite
>            Reporter: James Perkins
>            Assignee: Petr Kremensky
>            Priority: Minor
>
> The {{org.jboss.as.logging.per-deployment}} property has been deprecated. There are two tests {{LoggingPerDeployFalseTestCase}} and {{LoggingPreferencesPerDeployFalseTestCase}} that use this property. They need to be copied and/or moved to the manualmode tests and modified to use the new attribute.
> Also these tests appear not to work correctly. Breaking the system property during the patch, the tests still seemed to pass. They need to be reviewed and tested when working on this issue.

--
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

From issues at jboss.org  Fri Mar 14 12:32:10 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 14 Mar 2014 12:32:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3042) There should be a warning
 logged if the default value of node identifier has not been changed.
In-Reply-To: <JIRA.12533608.1393595350000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12533608.1393595350000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12533608.1393595350000.18429.1394814730696@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-3042?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12953201#comment-12953201 ] 

RH Bugzilla Integration commented on WFLY-3042:
-----------------------------------------------

Ondrej Chaloupka <ochaloup at redhat.com> changed the Status of [bug 1072312|https://bugzilla.redhat.com/show_bug.cgi?id=1072312] from ON_QA to VERIFIED
                
> There should be a warning logged if the default value of node identifier has not been changed.  
> ------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-3042
>                 URL: https://issues.jboss.org/browse/WFLY-3042
>             Project: WildFly
>          Issue Type: Enhancement
>      Security Level: Public(Everyone can see) 
>          Components: Transactions
>    Affects Versions: 8.0.0.Final
>         Environment: JBoss EAP 6.x
>            Reporter: Tom Ross
>            Assignee: Gytis Trikleris
>
> JBoss EAP instance is using the value of node identifier  to identify XA transactions that belong to it. By default this value is set to 1. Now days in most environments there will be multiple JBoss instances sharing XA resources there for it is necessary to set the value of node identifier to a unique value for each instance. This is something that most end users fail to perform. Therefor it would be helpful if  a warning  message was logged at startup telling the user to do it.

--
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

From issues at jboss.org  Fri Mar 14 12:50:10 2014
From: issues at jboss.org (Bela Ban (JIRA))
Date: Fri, 14 Mar 2014 12:50:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1750) RELAY2 : Address formats are
	not relayed.
In-Reply-To: <JIRA.12526440.1385646708000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12526440.1385646708000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12526440.1385646708000.18439.1394815810761@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JGRP-1750?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12953204#comment-12953204 ] 

Bela Ban commented on JGRP-1750:
--------------------------------

Would you want to set an {{AddressGenerator}} both for (1) nodes in the local cluster and the bridge cluster, or (2) only for nodes of the bridge cluster ? 
The latter case is simple: we could allow to set an {{AddressGenerator}} in Relayer, and use it to generate an address which would then we wrapped with a SiteUUID.
The former case is more generic: in essence, this would allow for multiple {{AddressGenerator}}s to build an address. 
So is your use case (1) or (2) ?
                
> RELAY2 : Address formats are not relayed.
> -----------------------------------------
>
>                 Key: JGRP-1750
>                 URL: https://issues.jboss.org/browse/JGRP-1750
>             Project: JGroups
>          Issue Type: Feature Request
>    Affects Versions: 3.4.1
>            Reporter: Karim AMMOUS
>            Assignee: Bela Ban
>             Fix For: 3.5
>
>
> When defining a relay channel, we haven't the ability to set an AddressGenrator. Indeed, the Relayer uses its own AddressGenerator providing addresses of type SiteUUID. 
> This is particularly embarrassing in the following case: when we define a customized address format (like CanBeSiteMasterTopology or TopologyUUID) for members of two Sites A and B, address format is lost by crossing relay. Address type of messages sent by A to B are seen as SiteUUID at B side.
> Suggestions:
> - Making address format "relayable" ?
> - Using the same (or an extended format) AddressGenerator of site Channel

--
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

From issues at jboss.org  Fri Mar 14 12:54:10 2014
From: issues at jboss.org (Bela Ban (JIRA))
Date: Fri, 14 Mar 2014 12:54:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1759)
 BecomeServerTest.testSendingOfMsgsOnUnconnectedChannel deadlocks
In-Reply-To: <JIRA.12528270.1387483080000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528270.1387483080000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528270.1387483080000.18444.1394816050783@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JGRP-1759?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12953205#comment-12953205 ] 

Bela Ban commented on JGRP-1759:
--------------------------------

I haven't been able to reproduce such a hang, *not a single time* ! Is this specific to 3.2.x ?
                
> BecomeServerTest.testSendingOfMsgsOnUnconnectedChannel deadlocks
> ----------------------------------------------------------------
>
>                 Key: JGRP-1759
>                 URL: https://issues.jboss.org/browse/JGRP-1759
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.5
>         Environment: Windows 2008, x86_64
>            Reporter: Richard Achmatowicz
>            Assignee: Bela Ban
>            Priority: Minor
>             Fix For: 3.5
>
>
> Running the Byteman tests in the QA lab, this test deadlocks in a repeatable fashion and causes the testsuite to hang.
> The test makes use of the Byteman rendezvous built-in function to suspend (and reorder) thread execution. It appears that with threads re-ordered, certain parts of JGroups block in such a way that no progress is made and the test deadlocks.
> .

--
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

From issues at jboss.org  Fri Mar 14 13:02:10 2014
From: issues at jboss.org (Bela Ban (JIRA))
Date: Fri, 14 Mar 2014 13:02:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1750) RELAY2 : Address formats are
	not relayed.
In-Reply-To: <JIRA.12526440.1385646708000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12526440.1385646708000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12526440.1385646708000.18448.1394816530795@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JGRP-1750?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12953206#comment-12953206 ] 

Bela Ban commented on JGRP-1750:
--------------------------------

Perhaps it would be simpler to create a new interface {{ExtendedAddress}} and an impl {{ExtendedUUID}} which contains the UUID and additional data, e.g. {{site_id}}, {{rack_id}} and {{machine_id}} for {{TopologyUUID}}, or a string for {{PayloadUUID}} etc...
The {{AddressGenerator}} would wrap the base address in an {{ExtendedUUID}} and data could then be added to that address, e.g. via puts and gets (conceptual hashmap).
This would also allow us to get rid of a number of classes...
                
> RELAY2 : Address formats are not relayed.
> -----------------------------------------
>
>                 Key: JGRP-1750
>                 URL: https://issues.jboss.org/browse/JGRP-1750
>             Project: JGroups
>          Issue Type: Feature Request
>    Affects Versions: 3.4.1
>            Reporter: Karim AMMOUS
>            Assignee: Bela Ban
>             Fix For: 3.5
>
>
> When defining a relay channel, we haven't the ability to set an AddressGenrator. Indeed, the Relayer uses its own AddressGenerator providing addresses of type SiteUUID. 
> This is particularly embarrassing in the following case: when we define a customized address format (like CanBeSiteMasterTopology or TopologyUUID) for members of two Sites A and B, address format is lost by crossing relay. Address type of messages sent by A to B are seen as SiteUUID at B side.
> Suggestions:
> - Making address format "relayable" ?
> - Using the same (or an extended format) AddressGenerator of site Channel

--
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

From issues at jboss.org  Fri Mar 14 13:10:10 2014
From: issues at jboss.org (Farah Juma (JIRA))
Date: Fri, 14 Mar 2014 13:10:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3120) Upgrade jsf-impl to
	2.2.5-jbossorg-4
In-Reply-To: <JIRA.12535059.1394816991355@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12535059.1394816991355@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12535059.1394816991355.18487.1394817010953@jira02.app.mwc.hst.phx2.redhat.com>

Farah Juma created WFLY-3120:
--------------------------------

             Summary: Upgrade jsf-impl to 2.2.5-jbossorg-4
                 Key: WFLY-3120
                 URL: https://issues.jboss.org/browse/WFLY-3120
             Project: WildFly
          Issue Type: Component  Upgrade
      Security Level: Public (Everyone can see)
          Components: JSF
    Affects Versions: 8.0.0.Final
            Reporter: Farah Juma
            Assignee: Farah Juma


Incorporate the patch for WFLY-2594/[JAVASERVERFACES-3189|https://java.net/jira/browse/JAVASERVERFACES-3189] for WildFly 8.0.1.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

From issues at jboss.org  Fri Mar 14 14:14:10 2014
From: issues at jboss.org (Farah Juma (JIRA))
Date: Fri, 14 Mar 2014 14:14:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3120) Upgrade JSF based on Mojarra
	2.2.6 Final
In-Reply-To: <JIRA.12535059.1394816991000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12535059.1394816991000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12535059.1394816991000.18602.1394820850606@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-3120?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Farah Juma updated WFLY-3120:
-----------------------------

    Summary: Upgrade JSF based on Mojarra 2.2.6 Final  (was: Upgrade jsf-impl to 2.2.5-jbossorg-4)

    
> Upgrade JSF based on Mojarra 2.2.6 Final
> ----------------------------------------
>
>                 Key: WFLY-3120
>                 URL: https://issues.jboss.org/browse/WFLY-3120
>             Project: WildFly
>          Issue Type: Component  Upgrade
>      Security Level: Public(Everyone can see) 
>          Components: JSF
>    Affects Versions: 8.0.0.Final
>            Reporter: Farah Juma
>            Assignee: Farah Juma
>
> Incorporate the patch for WFLY-2594/[JAVASERVERFACES-3189|https://java.net/jira/browse/JAVASERVERFACES-3189] for WildFly 8.0.1.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

From issues at jboss.org  Fri Mar 14 14:14:10 2014
From: issues at jboss.org (Farah Juma (JIRA))
Date: Fri, 14 Mar 2014 14:14:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3120) Upgrade JSF based on Mojarra
	2.2.6 Final
In-Reply-To: <JIRA.12535059.1394816991000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12535059.1394816991000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12535059.1394816991000.18603.1394820850649@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-3120?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Farah Juma updated WFLY-3120:
-----------------------------

    Description: Upgrade JSF based on Mojarra 2.2.6 Final. Also incorporate the patch for WFLY-2594/[JAVASERVERFACES-3189|https://java.net/jira/browse/JAVASERVERFACES-3189] for WildFly 8.0.1.Final.  (was: Incorporate the patch for WFLY-2594/[JAVASERVERFACES-3189|https://java.net/jira/browse/JAVASERVERFACES-3189] for WildFly 8.0.1.Final.)

    
> Upgrade JSF based on Mojarra 2.2.6 Final
> ----------------------------------------
>
>                 Key: WFLY-3120
>                 URL: https://issues.jboss.org/browse/WFLY-3120
>             Project: WildFly
>          Issue Type: Component  Upgrade
>      Security Level: Public(Everyone can see) 
>          Components: JSF
>    Affects Versions: 8.0.0.Final
>            Reporter: Farah Juma
>            Assignee: Farah Juma
>
> Upgrade JSF based on Mojarra 2.2.6 Final. Also incorporate the patch for WFLY-2594/[JAVASERVERFACES-3189|https://java.net/jira/browse/JAVASERVERFACES-3189] for WildFly 8.0.1.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

From issues at jboss.org  Fri Mar 14 14:48:10 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 14 Mar 2014 14:48:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-455) Event expiration calculation
	may overflow
In-Reply-To: <JIRA.12534871.1394709964000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534871.1394709964000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534871.1394709964000.18656.1394822890776@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/DROOLS-455?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12953239#comment-12953239 ] 

RH Bugzilla Integration commented on DROOLS-455:
------------------------------------------------

Mario Fusco <mfusco at redhat.com> changed the Status of [bug 1076361|https://bugzilla.redhat.com/show_bug.cgi?id=1076361] from ASSIGNED to MODIFIED
                
> Event expiration calculation may overflow
> -----------------------------------------
>
>                 Key: DROOLS-455
>                 URL: https://issues.jboss.org/browse/DROOLS-455
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.6.0.Final, 6.0.0.Final, 6.0.1.Final, 6.1.0.Beta1
>            Reporter: Davide Sottara
>            Assignee: Mario Fusco
>            Priority: Critical
>             Fix For: 6.1.0.Beta2
>
>
> The calculation of the expiration timestamp of an event in the OTN is effectively  given by the combination :
> {code}
> Handle.startTimeStamp + Handle.duration + OTN.expirationOffset 
> {code}
> If the addition overflows, the event will be scheduled for expiration immediately.

--
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

From issues at jboss.org  Fri Mar 14 15:08:10 2014
From: issues at jboss.org (rafael liu (JIRA))
Date: Fri, 14 Mar 2014 15:08:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-332) Add sessionDrainingStrategy
 configuration option to modcluster subsystem
In-Reply-To: <JIRA.12458456.1328568619000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12458456.1328568619000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12458456.1328568619000.18774.1394824090629@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-332?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12953245#comment-12953245 ] 

rafael liu commented on WFLY-332:
---------------------------------

Also there's have a more specific use case where the user can set a certain sessionDrainingStrategy value at the moment of the *redeploy*. I think mod_cluster doesn't support this kind o ad-hoc configuration, but IMO that has some real usages:

1. Suppose sessionDrainingStrategy=DEFAULT/ALWAYS, if there's 1 user hanging (say doing a huge download) the redeploy will timeout. Even worst, in a N node scenario, there will be N-1 nodes active during that time.
2. Again with sessionDrainingStrategy=DEFAULT/ALWAYS, if there's a critical bug, draining may not make sense or may introduce an undesirable delay.
                
> Add sessionDrainingStrategy configuration option to modcluster subsystem
> ------------------------------------------------------------------------
>
>                 Key: WFLY-332
>                 URL: https://issues.jboss.org/browse/WFLY-332
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Clustering
>            Reporter: Radoslav Husar
>            Assignee: Jean-Frederic Clere
>             Fix For: 8.0.0.Beta1
>
>
> Add sessionDrainingStrategy configuration option to modcluster subsystem
> * xsd 1.1

--
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

From issues at jboss.org  Fri Mar 14 22:02:10 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 14 Mar 2014 22:02:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3108) Can't promote --backup slave
 HC to master and reload without moving domain.cached-remote.xml
In-Reply-To: <JIRA.12534873.1394711186000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534873.1394711186000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534873.1394711186000.19551.1394848930564@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-3108?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12953274#comment-12953274 ] 

RH Bugzilla Integration commented on WFLY-3108:
-----------------------------------------------

Brian Stansberry <brian.stansberry at redhat.com> changed the Status of [bug 1076066|https://bugzilla.redhat.com/show_bug.cgi?id=1076066] from ASSIGNED to POST
                
> Can't promote --backup slave HC to master and reload without moving domain.cached-remote.xml
> --------------------------------------------------------------------------------------------
>
>                 Key: WFLY-3108
>                 URL: https://issues.jboss.org/browse/WFLY-3108
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>    Affects Versions: 8.0.0.Final
>            Reporter: Brian Stansberry
>            Assignee: Brian Stansberry
>             Fix For: 8.0.1.Final
>
>
> The prescribed mechanism for converting a slave HC to master is to:
> 1) Start the slave with --backup so a local copy of the domain config is maintained (in file domain.cached-remote.xml).
> 2) Stop the existing master.
> 3) Use the cli to connect to the slave and
> /host=<slavename>:write-local-domain-controller
> 4) Then, in the CLI
> reload --host=<slavename>
> Problem is this fails because the HC expects to have a domain config file "domain.xml".
> 2014-03-13 09:54:04,829 ERROR [org.jboss.as.host.controller] (Controller Boot Thread) JBAS010932: Caught exception during boot: org.jboss.as.controller.persistence.ConfigurationPersistenceException: JBAS014676: Failed to parse configuration
> 	at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:112) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> 	at org.jboss.as.host.controller.DomainModelControllerService.boot(DomainModelControllerService.java:514) [wildfly-host-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> 	at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:256) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> 	at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_45]
> Caused by: java.io.FileNotFoundException: /Users/bstansberry/tmp/WF801/slave/domain/configuration/domain.xml (No such file or directory)
> 	at java.io.FileInputStream.open(Native Method) [rt.jar:1.7.0_45]
> 	at java.io.FileInputStream.<init>(FileInputStream.java:146) [rt.jar:1.7.0_45]
> 	at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:100) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> 	... 3 more
> Or, MUCH WORSE, there happens to be a random domain.xml in the filesystem, which has content that is out of sync with the correct domain config. This domain.xml config will be used.

--
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

From issues at jboss.org  Sat Mar 15 10:48:10 2014
From: issues at jboss.org (Mariano De Maio (JIRA))
Date: Sat, 15 Mar 2014 10:48:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-457) TaskModelProvider's
 ServiceLoader sync problem
In-Reply-To: <JIRA.12535022.1394799288000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12535022.1394799288000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12535022.1394799288000.19639.1394894890562@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-457?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mariano De Maio resolved DROOLS-457.
------------------------------------

    Fix Version/s: 6.1.0.Beta2
       Resolution: Done


Pull request merged into master by Maciej Swiderski
                
> TaskModelProvider's ServiceLoader sync problem
> ----------------------------------------------
>
>                 Key: DROOLS-457
>                 URL: https://issues.jboss.org/browse/DROOLS-457
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 6.0.0.Final, 6.0.1.Final, 6.1.0.Beta1, 6.1.0.Beta2, 6.1.0.Final
>            Reporter: Mariano De Maio
>            Assignee: Mark Proctor
>             Fix For: 6.1.0.Beta2
>
>         Attachments: test-case.zip
>
>
> This bug was found related to jBPM6 components, but its solution needs to be implemented in the kie-internal project, hence we report it in this project.
> When the TaskModelProvider access the factory object, it iterates the service loader directly. Unfortunately, the ServiceLoader class states:
> "Instances of this class are not safe for use by multiple concurrent threads." (http://docs.oracle.com/javase/6/docs/api/java/util/ServiceLoader.html)
> This causes that environments that need to use the TaskModelProvider from different threads with no prior invocation.
> I'll add a maven test to reproduce the issue. We have also a solution we'll submit in a pull request

--
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

From issues at jboss.org  Mon Mar 17 00:46:12 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 17 Mar 2014 00:46:12 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1547) deploy directories not
	cleaned up
In-Reply-To: <JIRA.12479851.1353935247000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12479851.1353935247000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12479851.1353935247000.19995.1395031572100@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1547?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12953362#comment-12953362 ] 

RH Bugzilla Integration commented on WFLY-1547:
-----------------------------------------------

James Livingston <jlivings at redhat.com> changed the Status of [bug 901210|https://bugzilla.redhat.com/show_bug.cgi?id=901210] from ASSIGNED to POST
                
> deploy directories not cleaned up
> ---------------------------------
>
>                 Key: WFLY-1547
>                 URL: https://issues.jboss.org/browse/WFLY-1547
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 8.0.0.Alpha1
>            Reporter: Shaun Appleton
>            Assignee: jaikiran pai
>             Fix For: 8.0.0.Beta1
>
>         Attachments: deployment_with_hack_no_hook.txt
>
>
> JBoss EAP 6.0.0 (and 6.0.1.ER3) doesn't clean up it's tmp/vfs directories.
> The following reproduces this -
> i) ensure run.conf has the -Xrs set
> ii) ensure deployments has a deployable .ear in it
> iii) ./run standalone.sh and allow the deployments to deploy
> iv) stop the EAP process ie kill <process_id>
> v) observe content tmp/vfs
> (The -Xrs parameter is used to "-Xrs" to prevent possible interference when JVM is running as a service and receives CTRL_LOGOFF_EVENT or SIGHUP)
> This will eventually cause problems with lack of disk space.
> Note if the -Xrs parameter content is removed but the tmp/vfs dirs stills exist. This could potentially cause inode problems.
> It would be better if there were any additional code so the temp dirs are cleaned up on start up. That would resolve both the -Xrs problem and the excessive dir creation.

--
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

From issues at jboss.org  Mon Mar 17 03:54:10 2014
From: issues at jboss.org (Petr Kremensky (JIRA))
Date: Mon, 17 Mar 2014 03:54:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2648) Review/move the per-logging
 deployment tests
In-Reply-To: <JIRA.12527851.1386875737000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12527851.1386875737000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12527851.1386875737000.20143.1395042850939@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2648?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12953383#comment-12953383 ] 

Petr Kremensky commented on WFLY-2648:
--------------------------------------

Same here :). I remember there was some issue when we use both logging profile and per-deploy logging, so I cover that.
                
> Review/move the per-logging deployment tests
> --------------------------------------------
>
>                 Key: WFLY-2648
>                 URL: https://issues.jboss.org/browse/WFLY-2648
>             Project: WildFly
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite
>            Reporter: James Perkins
>            Assignee: Petr Kremensky
>            Priority: Minor
>
> The {{org.jboss.as.logging.per-deployment}} property has been deprecated. There are two tests {{LoggingPerDeployFalseTestCase}} and {{LoggingPreferencesPerDeployFalseTestCase}} that use this property. They need to be copied and/or moved to the manualmode tests and modified to use the new attribute.
> Also these tests appear not to work correctly. Breaking the system property during the patch, the tests still seemed to pass. They need to be reviewed and tested when working on this issue.

--
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

From issues at jboss.org  Mon Mar 17 04:50:11 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 17 Mar 2014 04:50:11 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1807) UNICAST: skipping of seqnos
In-Reply-To: <JIRA.12534731.1394603645000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534731.1394603645000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534731.1394603645000.20191.1395046211598@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JGRP-1807?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated JGRP-1807:
------------------------------------------

        Bugzilla Update: Perform
    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1077096

    
> UNICAST: skipping of seqnos
> ---------------------------
>
>                 Key: JGRP-1807
>                 URL: https://issues.jboss.org/browse/JGRP-1807
>             Project: JGroups
>          Issue Type: Bug
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 3.2.13, 3.5
>
>
> {noformat}
> The log starts with:
> 10-Mar-2014 13:21:47 WARN  [org.jgroups.protocols.UNICAST2] (OOB-105,shared=tcp) node1/web: (requester=node2/web) message node2/web::1511786 not found in retransmission table of node2/web:
> [1511785 | 1511785 | 1511857] (53 elements, 19 missing)
> The numbers are 1511786-1511804  for "not found in retransmission...."
> And end:
> 10-Mar-2014 14:48:26 WARN  [org.jgroups.protocols.UNICAST2] (OOB-118,shared=tcp) node1/web: (requester=node2/web) message node2/web::1511804 not found in retransmission table of node2/web:
> [1511785 | 1511785 | 1514802] (2998 elements, 19 missing) 
> {noformat}
> It seems that node1  is missing messages 1511785-1511804 which it sent to node2. Since a null message cannot be added to the sender table (due to the {{msg.isFlagSet()}} which would throw an NPE), I asume we're skipping a seqno:
> In {{UNICAST}}, {{UNICAST2}} and {{UNICAST3}} {{down()}}, if a seqno is skipped, we get endless retransmissions. Example: 
> * We get the next seqno 1, add the message to the table and send it
> * We get the next seqno 2. However, if {{running}} is false, we don't add the message
> * We get the next seqno 3. Now {{running}} is true, and we add 3 to the table
> --> Now we have a missing message 2 which will always be null as it hasn't been added to the table
> This is highly unlikely, as I haven't been able to find a scenario where running flips from true to false to true quickly. If it flips from true to false, this is because {{stop()}} has been called. Also, in {{down()}}, we actually check {{running}} and return if false.
> In this scenario, the connections are all removed, so seqno is reset to 1.
> Anyway, I'm going to replace the {{while(running)}} loop with a {{do while(running)}} loop, so we always add the message to the table, even if running=false.
> [1] https://github.com/belaban/JGroups/blob/Branch_JGroups_3_2/src/org/jgroups/protocols/UNICAST2.java#L490

--
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

From issues at jboss.org  Mon Mar 17 07:28:11 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 17 Mar 2014 07:28:11 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBEE-146) jboss-el-api_2.2_spec
 1.0.2.Final cannot access public methods from non-public classes
In-Reply-To: <JIRA.12525180.1384462560000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12525180.1384462560000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12525180.1384462560000.20578.1395055691186@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JBEE-146?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12953441#comment-12953441 ] 

RH Bugzilla Integration commented on JBEE-146:
----------------------------------------------

Carlo de Wolf <cdewolf at redhat.com> changed the Status of [bug 1076320|https://bugzilla.redhat.com/show_bug.cgi?id=1076320] from POST to MODIFIED
                
> jboss-el-api_2.2_spec 1.0.2.Final cannot access public methods from non-public classes
> --------------------------------------------------------------------------------------
>
>                 Key: JBEE-146
>                 URL: https://issues.jboss.org/browse/JBEE-146
>             Project: JBoss JavaEE Spec APIs
>          Issue Type: Bug
>            Reporter: Farah Juma
>            Assignee: Farah Juma
>             Fix For: jboss-el-api_2.2_spec-1.0.3.Final, jboss-el-api_3.0_spec-1.0.0.Final
>
>
> When accessing a public method of a non-public class via EL that implements a public interface or has a public superclass, the following exception occurs:
> {code}java.lang.IllegalAccessException: Class javax.el.BeanELResolver can not access a member of class X with modifiers "public" 
> {code}
> See https://bugzilla.redhat.com/show_bug.cgi?id=1029387 for more 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

From issues at jboss.org  Mon Mar 17 07:28:11 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 17 Mar 2014 07:28:11 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2493) EL cannot access public
 methods/fields of non-public classes
In-Reply-To: <JIRA.12524859.1384250001000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12524859.1384250001000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12524859.1384250001000.20580.1395055691279@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2493?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12953442#comment-12953442 ] 

RH Bugzilla Integration commented on WFLY-2493:
-----------------------------------------------

Carlo de Wolf <cdewolf at redhat.com> changed the Status of [bug 1076320|https://bugzilla.redhat.com/show_bug.cgi?id=1076320] from POST to MODIFIED
                
> EL cannot access public methods/fields of non-public classes
> ------------------------------------------------------------
>
>                 Key: WFLY-2493
>                 URL: https://issues.jboss.org/browse/WFLY-2493
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JSF
>         Environment: JBoss AS 7.2.0.Final
>            Reporter: Jon?? Trantina
>         Attachments: elresolver_stack, reproducer.zip
>
>
> When trying to access public method/field of non-public class that implements public interface via EL I get 
> {noformat}
> java.lang.IllegalAccessException: Class javax.el.BeanELResolver can not access a member of class X with modifiers "private"
> {noformat}
> E.g. accessing Collections.unmodifiableList(..).size() via EL will throw the exception, because #unmodifiableList returns non-public implementation of List interface.
> This is apparently caused by JDK-4071957 [1], but since that is opened for over 16 years, it should be probably worth it to implement a workaround.
> Workaround for this issue is setting setAccessible(true) on the method before invoking it, thus suppress Java access checking.
> I have attached a simple reproducer app as well as a stack trace of the exception.
> [1] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4071957

--
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


From issues at jboss.org  Mon Mar 17 07:40:10 2014
From: issues at jboss.org (Alessio Soldano (JIRA))
Date: Mon, 17 Mar 2014 07:40:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3121) Upgrade to JBossWS 4.3.0.Final
In-Reply-To: <JIRA.12535139.1395056362823@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12535139.1395056362823@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12535139.1395056362823.20664.1395056410703@jira02.app.mwc.hst.phx2.redhat.com>

Alessio Soldano created WFLY-3121:
-------------------------------------

             Summary: Upgrade to JBossWS 4.3.0.Final
                 Key: WFLY-3121
                 URL: https://issues.jboss.org/browse/WFLY-3121
             Project: WildFly
          Issue Type: Component  Upgrade
      Security Level: Public (Everyone can see)
          Components: Web Services
            Reporter: Alessio Soldano
            Assignee: Alessio Soldano
             Fix For: 9.0.0.CR1




--
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

From issues at jboss.org  Mon Mar 17 07:50:10 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 17 Mar 2014 07:50:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3077) Convert command line IPv6 URL
 literals to address literals
In-Reply-To: <JIRA.12534346.1394155395000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534346.1394155395000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534346.1394155395000.20729.1395057010911@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-3077?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12953456#comment-12953456 ] 

RH Bugzilla Integration commented on WFLY-3077:
-----------------------------------------------

Miroslav Novak <mnovak at redhat.com> changed the Status of [bug 1064771|https://bugzilla.redhat.com/show_bug.cgi?id=1064771] from ON_QA to VERIFIED
                
> Convert command line IPv6 URL literals to address literals
> ----------------------------------------------------------
>
>                 Key: WFLY-3077
>                 URL: https://issues.jboss.org/browse/WFLY-3077
>             Project: WildFly
>          Issue Type: Enhancement
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 8.0.0.Final
>            Reporter: Brian Stansberry
>            Assignee: Brian Stansberry
>            Priority: Minor
>             Fix For: 8.0.1.Final
>
>
> When people provide URL-style values like [::1] for command line args like -b, convert them to address values (i.e. strip the enclosing brackets.)

--
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

From issues at jboss.org  Mon Mar 17 08:44:11 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 17 Mar 2014 08:44:11 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3007) Ipv6 addresses may not be
 canonized properly
In-Reply-To: <JIRA.12533139.1393261818000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12533139.1393261818000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12533139.1393261818000.20939.1395060251535@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-3007?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12953477#comment-12953477 ] 

RH Bugzilla Integration commented on WFLY-3007:
-----------------------------------------------

Pavel Jelinek <pjelinek at redhat.com> changed the Status of [bug 1067348|https://bugzilla.redhat.com/show_bug.cgi?id=1067348] from ON_QA to VERIFIED
                
> Ipv6 addresses may not be canonized properly
> --------------------------------------------
>
>                 Key: WFLY-3007
>                 URL: https://issues.jboss.org/browse/WFLY-3007
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 8.0.0.Final
>            Reporter: Emmanuel Hugonnet
>            Assignee: Emmanuel Hugonnet
>
> On an ipv6 environment we may obtain IP addresses that are not properly canonized which may lead to strange issue with http proxies since the JDK ProxySelector relies on char per char matching.
> All call to InetAddress.getHostName() may produce such an uncanonized address.

--
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

From issues at jboss.org  Mon Mar 17 09:16:12 2014
From: issues at jboss.org (Radoslav Husar (JIRA))
Date: Mon, 17 Mar 2014 09:16:12 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-332) Add sessionDrainingStrategy
 configuration option to modcluster subsystem
In-Reply-To: <JIRA.12458456.1328568619000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12458456.1328568619000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12458456.1328568619000.21016.1395062172410@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-332?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12953486#comment-12953486 ] 

Radoslav Husar commented on WFLY-332:
-------------------------------------

Rafael, if I understand correctly, you are saying that having session-draining-strategy configuration separately for undeploy and redeploy would make sense?

I am somewhat failing to see how. In case #1, the redeployment should not fail, the session just won't be drained in time, then the app will be redeployed. While at it, in such use case, one would use e.g. mod_cluster manager to draing the sessions manually in order to prevent termination of a very long running requests. Those are not common though. Also, there is always n-1 when the app is undeployed. In case #2, you would upgrade whole cluster immediately and won't perform any session draining.
                
> Add sessionDrainingStrategy configuration option to modcluster subsystem
> ------------------------------------------------------------------------
>
>                 Key: WFLY-332
>                 URL: https://issues.jboss.org/browse/WFLY-332
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Clustering
>            Reporter: Radoslav Husar
>            Assignee: Jean-Frederic Clere
>             Fix For: 8.0.0.Beta1
>
>
> Add sessionDrainingStrategy configuration option to modcluster subsystem
> * xsd 1.1

--
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

From issues at jboss.org  Mon Mar 17 09:30:11 2014
From: issues at jboss.org (Patrick Bajeneza (JIRA))
Date: Mon, 17 Mar 2014 09:30:11 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1891) HTTPSession sharing between
 wars delivered in an EAR
In-Reply-To: <JIRA.12498698.1376580940000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12498698.1376580940000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12498698.1376580940000.21094.1395063011168@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1891?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12953494#comment-12953494 ] 

Patrick Bajeneza commented on WFLY-1891:
----------------------------------------

Hello Stuart,

Do you have any update for this case?

Thanks
                
> HTTPSession sharing between wars delivered in an EAR
> ----------------------------------------------------
>
>                 Key: WFLY-1891
>                 URL: https://issues.jboss.org/browse/WFLY-1891
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Web (Undertow)
>            Reporter: John Doyle
>            Assignee: Stuart Douglas
>
> WAS and WL have this feature, and its been requested for several earlier versions of AS.  Having this capability will ease the migration of users from WAS and WL to WildFly.

--
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

From issues at jboss.org  Mon Mar 17 09:48:10 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 17 Mar 2014 09:48:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-430) Fails to parse DSL variable
 definition with single dot regex
In-Reply-To: <JIRA.12532345.1392621213000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12532345.1392621213000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12532345.1392621213000.21186.1395064090953@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/DROOLS-430?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12953512#comment-12953512 ] 

RH Bugzilla Integration commented on DROOLS-430:
------------------------------------------------

Marek Winkler <mwinkler at redhat.com> changed the Status of [bug 1065868|https://bugzilla.redhat.com/show_bug.cgi?id=1065868] from ON_QA to VERIFIED
                
> Fails to parse DSL variable definition with single dot regex
> ------------------------------------------------------------
>
>                 Key: DROOLS-430
>                 URL: https://issues.jboss.org/browse/DROOLS-430
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 6.0.1.Final
>            Reporter: Toshiya Kobayashi
>            Assignee: Edson Tirelli
>             Fix For: 6.1.0.Beta1
>
>
> Drools fails to parse DSL variable definition with single dot regex, where I want one any character.
> {noformat}
> [then]Log {message:.}=list.add(\"{message}\");
> {noformat}
> Error message:
> {noformat}
> [1,19]: DSL parser error
> {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

From issues at jboss.org  Mon Mar 17 09:52:10 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 17 Mar 2014 09:52:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-393) Trait Hierarchy is not
 rebuilt correctly when merging packages
In-Reply-To: <JIRA.12528619.1388831451000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528619.1388831451000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528619.1388831451000.21192.1395064330731@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/DROOLS-393?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12953513#comment-12953513 ] 

RH Bugzilla Integration commented on DROOLS-393:
------------------------------------------------

Marek Winkler <mwinkler at redhat.com> changed the Status of [bug 1063803|https://bugzilla.redhat.com/show_bug.cgi?id=1063803] from ON_QA to VERIFIED
                
> Trait Hierarchy is not rebuilt correctly when merging packages
> --------------------------------------------------------------
>
>                 Key: DROOLS-393
>                 URL: https://issues.jboss.org/browse/DROOLS-393
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.5.0.Final, 6.0.0.Final, 6.0.1.Final
>            Reporter: Davide Sottara
>            Assignee: Mario Fusco
>            Priority: Critical
>             Fix For: 5.5.1.Final, 6.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

From issues at jboss.org  Mon Mar 17 09:56:11 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 17 Mar 2014 09:56:11 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-416) Queries do not work with
	events
In-Reply-To: <JIRA.12530363.1390784899000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530363.1390784899000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530363.1390784899000.21204.1395064571108@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/DROOLS-416?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12953518#comment-12953518 ] 

RH Bugzilla Integration commented on DROOLS-416:
------------------------------------------------

Marek Winkler <mwinkler at redhat.com> changed the Status of [bug 1063805|https://bugzilla.redhat.com/show_bug.cgi?id=1063805] from ON_QA to VERIFIED
                
> Queries do not work with events
> -------------------------------
>
>                 Key: DROOLS-416
>                 URL: https://issues.jboss.org/browse/DROOLS-416
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 6.0.0.Final
>            Reporter: Davide Sottara
>            Assignee: Mario Fusco
>            Priority: Critical
>             Fix For: 6.1.0.Beta1
>
>


--
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

From issues at jboss.org  Mon Mar 17 10:00:12 2014
From: issues at jboss.org (Jay Kumar SenSharma (JIRA))
Date: Mon, 17 Mar 2014 10:00:12 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2376) DataSource properties are not
 persisting via CLI
In-Reply-To: <JIRA.12508706.1382624115000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508706.1382624115000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508706.1382624115000.21228.1395064812773@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2376?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12953521#comment-12953521 ] 

Jay Kumar SenSharma commented on WFLY-2376:
-------------------------------------------

The Pull request  [1] does not seems to be fixing the issue.

With the above pull request build still we see that if the class_name is not provided for stale_connection, reauth_plugin and exception_sorter ....Still  WildFly   creates the DataSource *Silently* without throwing any error / exception.    
The DataSource configuration mentioned inside the  "standalone.xml"  still has missing exception-sorter-properties, reauth-plugin-properties etc.

Ideally WildFly should have thrown some Error like following:

{code}
Caused by: javax.xml.stream.XMLStreamException: The exception-sorter-properties is defined without defining the exception-sorter-class-name
	at org.jboss.as.connector.subsystems.datasources.DataSourcesExtension$DataSourceSubsystemParser.writeDS(DataSourcesExtension.java:510)
	at org.jboss.as.connector.subsystems.datasources.DataSourcesExtension$DataSourceSubsystemParser.writeContent(DataSourcesExtension.java:212)
	at org.jboss.as.connector.subsystems.datasources.DataSourcesExtension$DataSourceSubsystemParser.writeContent(DataSourcesExtension.java:193)
	at org.jboss.as.server.parsing.StandaloneXml.writeServerProfile(StandaloneXml.java:1288) [wildfly-server-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
	at org.jboss.as.server.parsing.StandaloneXml.writeContent(StandaloneXml.java:1205) [wildfly-server-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
	at org.jboss.as.server.parsing.StandaloneXml.writeContent(StandaloneXml.java:107) [wildfly-server-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
	at org.jboss.staxmapper.XMLMapperImpl.doDeparse(XMLMapperImpl.java:88) [staxmapper-1.1.0.Final.jar:1.1.0.Final]
	at org.jboss.staxmapper.XMLMapperImpl.deparseDocument(XMLMapperImpl.java:83) [staxmapper-1.1.0.Final.jar:1.1.0.Final]
	at org.jboss.as.controller.persistence.AbstractConfigurationPersister.marshallAsXml(AbstractConfigurationPersister.java:117) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
	... 28 more
{code} 

[1] https://github.com/wildfly/wildfly/pull/5353
                
> DataSource properties are not persisting via CLI
> ------------------------------------------------
>
>                 Key: WFLY-2376
>                 URL: https://issues.jboss.org/browse/WFLY-2376
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JCA
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Jay Kumar SenSharma
>            Assignee: Stefano Maestri
>
> - The CLI command show that there are some valid configuration properties available like following while configuring DataSources, However those properties never get persisted in the DataSource configuration:
> {quote}
>  ./jboss-cli.sh  --user=admin --password=admin at 123 -c --controller=remote://localhost:9999  command="/subsystem=datasources/data-source=testpool:read-resource-description(recursive=true)" 
>             "stale-connection-checker-properties" => {
>                 "type" => OBJECT,
>                 "description" => "The stale connection checker properties",
>                 "expressions-allowed" => true,
>                 "nillable" => true,
>                 "value-type" => STRING,
>                 "access-type" => "read-write",
>                 "storage" => "configuration",
>                 "restart-required" => "no-services"
>             },
>             "reauth-plugin-properties" => {
>                 "type" => OBJECT,
>                 "description" => "The properties for the reauthentication plugin",
>                 "expressions-allowed" => true,
>                 "nillable" => true,
>                 "value-type" => STRING,
>                 "access-type" => "read-write",
>                 "storage" => "configuration",
>                 "restart-required" => "no-services"
>             },
>             "exception-sorter-properties" => {
>                 "type" => OBJECT,
>                 "description" => "The exception sorter properties",
>                 "expressions-allowed" => true,
>                 "nillable" => true,
>                 "value-type" => STRING,
>                 "access-type" => "read-write",
>                 "storage" => "configuration",
>                 "restart-required" => "no-services"
>             },
> {quote}
> - Following command never complains about any issue and the following command executed without any issue but the above properties are not persisted in the DataSource.
>  ./jboss-cli.sh --user=admin --password=admin at 123 -c --controller=remote://localhost:9999 command="/subsystem=datasources/data-source=testpool:add(jndi-name=\"java:jboss/TestDS\",driver-name=\"ojdbc6.jar\",connection-url=\"jdbc:oracle:thin:@DBHostName:1521:DBName\",user-name=\"user\",password=\"pass\",new-connection-sql=\"select 1 from dual\", check-valid-connection-sql=\"select 2 from dual\",valid-connection-checker-class-name=\"org.jboss.resource.adapter.jdbc.vendor.OracleValidConnectionChecker\",exception-sorter-properties={\"prop1\"=>\"value1\"},reauth-plugin-properties={\"reauthProp1\"=>\"reauthValue1\"},exception-sorter-properties={\"exceptionSorterProp1\"=>\"exceptionSorterValue1\"})"
> - The Generated DataSource looks like following:
> ${quote}
>                 <datasource jndi-name="java:jboss/TestDS" pool-name="testpool" enabled="true">
>                     <connection-url>jdbc:oracle:thin:@DBHostName:1521:DBName</connection-url>
>                     <driver>ojdbc6.jar</driver>
>                     <new-connection-sql>select 1 from dual</new-connection-sql>
>                     <security>
>                         <user-name>user</user-name>
>                         <password>pass</password>
>                     </security>
>                     <validation>
>                         <valid-connection-checker class-name="org.jboss.resource.adapter.jdbc.vendor.OracleValidConnectionChecker"/>
>                         <check-valid-connection-sql>select 2 from dual</check-valid-connection-sql>
>                     </validation>
>                 </datasource>
> ${quote}

--
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

From issues at jboss.org  Mon Mar 17 10:00:13 2014
From: issues at jboss.org (Anil Saldhana (JIRA))
Date: Mon, 17 Mar 2014 10:00:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3122) EJBs should inherit the
 enclosing war's security domain
In-Reply-To: <JIRA.12535154.1395064740793@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12535154.1395064740793@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12535154.1395064740793.21231.1395064813068@jira02.app.mwc.hst.phx2.redhat.com>

Anil Saldhana created WFLY-3122:
-----------------------------------

             Summary: EJBs should inherit the enclosing war's security domain
                 Key: WFLY-3122
                 URL: https://issues.jboss.org/browse/WFLY-3122
             Project: WildFly
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: EJB, Security
            Reporter: Anil Saldhana
            Assignee: David Lloyd


[~bill.burke] has opened a discussion at http://lists.jboss.org/pipermail/wildfly-dev/2014-March/001935.html about the need for EJBs packaged in a war, to inherit the security domain of the web application.

--
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

From issues at jboss.org  Mon Mar 17 10:00:13 2014
From: issues at jboss.org (Jay Kumar SenSharma (JIRA))
Date: Mon, 17 Mar 2014 10:00:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2376) DataSource properties are not
 persisting via CLI
In-Reply-To: <JIRA.12508706.1382624115000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508706.1382624115000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508706.1382624115000.21235.1395064813369@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2376?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12953521#comment-12953521 ] 

Jay Kumar SenSharma edited comment on WFLY-2376 at 3/17/14 9:59 AM:
--------------------------------------------------------------------

The Pull request  [1] does not seems to be fixing the issue.

With the above pull request build still we see that if the class_name is not provided for stale_connection, reauth_plugin and exception_sorter ....Still  WildFly   creates the DataSource *Silently* without throwing any error / exception.    
The DataSource configuration mentioned inside the  "standalone.xml"  still has missing exception-sorter-properties, reauth-plugin-properties etc.

Ideally WildFly should have thrown some Error like following:

{code}
Caused by: javax.xml.stream.XMLStreamException: The exception-sorter-properties is defined without defining the exception-sorter-class-name
	at org.jboss.as.connector.subsystems.datasources.DataSourcesExtension$DataSourceSubsystemParser.writeDS(DataSourcesExtension.java:510)
	at org.jboss.as.connector.subsystems.datasources.DataSourcesExtension$DataSourceSubsystemParser.writeContent(DataSourcesExtension.java:212)
	at org.jboss.as.connector.subsystems.datasources.DataSourcesExtension$DataSourceSubsystemParser.writeContent(DataSourcesExtension.java:193)
	at org.jboss.as.server.parsing.StandaloneXml.writeServerProfile(StandaloneXml.java:1288) [wildfly-server-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
	at org.jboss.as.server.parsing.StandaloneXml.writeContent(StandaloneXml.java:1205) [wildfly-server-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
	at org.jboss.as.server.parsing.StandaloneXml.writeContent(StandaloneXml.java:107) [wildfly-server-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
	at org.jboss.staxmapper.XMLMapperImpl.doDeparse(XMLMapperImpl.java:88) [staxmapper-1.1.0.Final.jar:1.1.0.Final]
	at org.jboss.staxmapper.XMLMapperImpl.deparseDocument(XMLMapperImpl.java:83) [staxmapper-1.1.0.Final.jar:1.1.0.Final]
	at org.jboss.as.controller.persistence.AbstractConfigurationPersister.marshallAsXml(AbstractConfigurationPersister.java:117) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
	... 28 more
{code} 


Test DataSource creation command :
{code}
/subsystem=datasources/data-source=testpool:add(jndi-name="java:jboss/TestDS",driver-name="ojdbc6.jar",connection-url="jdbc:oracle:thin:@DBHostName:1521:DBName",user-name="user",password="pass",new-connection-sql="select 1 from dual", check-valid-connection-sql="select 2 from dual",valid-connection-checker-class-name="org.jboss.resource.adapter.jdbc.vendor.OracleValidConnectionChecker", exception-sorter-properties={"prop1"=>"value1"},reauth-plugin-properties={"reauthProp1"=>"reauthValue1"},exception-sorter-properties={"exceptionSorterProp1"=>"exceptionSorterValue1"})   
{code}
[1] https://github.com/wildfly/wildfly/pull/5353
                
      was (Author: jaysensharma):
    The Pull request  [1] does not seems to be fixing the issue.

With the above pull request build still we see that if the class_name is not provided for stale_connection, reauth_plugin and exception_sorter ....Still  WildFly   creates the DataSource *Silently* without throwing any error / exception.    
The DataSource configuration mentioned inside the  "standalone.xml"  still has missing exception-sorter-properties, reauth-plugin-properties etc.

Ideally WildFly should have thrown some Error like following:

{code}
Caused by: javax.xml.stream.XMLStreamException: The exception-sorter-properties is defined without defining the exception-sorter-class-name
	at org.jboss.as.connector.subsystems.datasources.DataSourcesExtension$DataSourceSubsystemParser.writeDS(DataSourcesExtension.java:510)
	at org.jboss.as.connector.subsystems.datasources.DataSourcesExtension$DataSourceSubsystemParser.writeContent(DataSourcesExtension.java:212)
	at org.jboss.as.connector.subsystems.datasources.DataSourcesExtension$DataSourceSubsystemParser.writeContent(DataSourcesExtension.java:193)
	at org.jboss.as.server.parsing.StandaloneXml.writeServerProfile(StandaloneXml.java:1288) [wildfly-server-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
	at org.jboss.as.server.parsing.StandaloneXml.writeContent(StandaloneXml.java:1205) [wildfly-server-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
	at org.jboss.as.server.parsing.StandaloneXml.writeContent(StandaloneXml.java:107) [wildfly-server-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
	at org.jboss.staxmapper.XMLMapperImpl.doDeparse(XMLMapperImpl.java:88) [staxmapper-1.1.0.Final.jar:1.1.0.Final]
	at org.jboss.staxmapper.XMLMapperImpl.deparseDocument(XMLMapperImpl.java:83) [staxmapper-1.1.0.Final.jar:1.1.0.Final]
	at org.jboss.as.controller.persistence.AbstractConfigurationPersister.marshallAsXml(AbstractConfigurationPersister.java:117) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
	... 28 more
{code} 

[1] https://github.com/wildfly/wildfly/pull/5353
                  
> DataSource properties are not persisting via CLI
> ------------------------------------------------
>
>                 Key: WFLY-2376
>                 URL: https://issues.jboss.org/browse/WFLY-2376
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JCA
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Jay Kumar SenSharma
>            Assignee: Stefano Maestri
>
> - The CLI command show that there are some valid configuration properties available like following while configuring DataSources, However those properties never get persisted in the DataSource configuration:
> {quote}
>  ./jboss-cli.sh  --user=admin --password=admin at 123 -c --controller=remote://localhost:9999  command="/subsystem=datasources/data-source=testpool:read-resource-description(recursive=true)" 
>             "stale-connection-checker-properties" => {
>                 "type" => OBJECT,
>                 "description" => "The stale connection checker properties",
>                 "expressions-allowed" => true,
>                 "nillable" => true,
>                 "value-type" => STRING,
>                 "access-type" => "read-write",
>                 "storage" => "configuration",
>                 "restart-required" => "no-services"
>             },
>             "reauth-plugin-properties" => {
>                 "type" => OBJECT,
>                 "description" => "The properties for the reauthentication plugin",
>                 "expressions-allowed" => true,
>                 "nillable" => true,
>                 "value-type" => STRING,
>                 "access-type" => "read-write",
>                 "storage" => "configuration",
>                 "restart-required" => "no-services"
>             },
>             "exception-sorter-properties" => {
>                 "type" => OBJECT,
>                 "description" => "The exception sorter properties",
>                 "expressions-allowed" => true,
>                 "nillable" => true,
>                 "value-type" => STRING,
>                 "access-type" => "read-write",
>                 "storage" => "configuration",
>                 "restart-required" => "no-services"
>             },
> {quote}
> - Following command never complains about any issue and the following command executed without any issue but the above properties are not persisted in the DataSource.
>  ./jboss-cli.sh --user=admin --password=admin at 123 -c --controller=remote://localhost:9999 command="/subsystem=datasources/data-source=testpool:add(jndi-name=\"java:jboss/TestDS\",driver-name=\"ojdbc6.jar\",connection-url=\"jdbc:oracle:thin:@DBHostName:1521:DBName\",user-name=\"user\",password=\"pass\",new-connection-sql=\"select 1 from dual\", check-valid-connection-sql=\"select 2 from dual\",valid-connection-checker-class-name=\"org.jboss.resource.adapter.jdbc.vendor.OracleValidConnectionChecker\",exception-sorter-properties={\"prop1\"=>\"value1\"},reauth-plugin-properties={\"reauthProp1\"=>\"reauthValue1\"},exception-sorter-properties={\"exceptionSorterProp1\"=>\"exceptionSorterValue1\"})"
> - The Generated DataSource looks like following:
> ${quote}
>                 <datasource jndi-name="java:jboss/TestDS" pool-name="testpool" enabled="true">
>                     <connection-url>jdbc:oracle:thin:@DBHostName:1521:DBName</connection-url>
>                     <driver>ojdbc6.jar</driver>
>                     <new-connection-sql>select 1 from dual</new-connection-sql>
>                     <security>
>                         <user-name>user</user-name>
>                         <password>pass</password>
>                     </security>
>                     <validation>
>                         <valid-connection-checker class-name="org.jboss.resource.adapter.jdbc.vendor.OracleValidConnectionChecker"/>
>                         <check-valid-connection-sql>select 2 from dual</check-valid-connection-sql>
>                     </validation>
>                 </datasource>
> ${quote}

--
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

From issues at jboss.org  Mon Mar 17 10:12:12 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 17 Mar 2014 10:12:12 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1547) deploy directories not
	cleaned up
In-Reply-To: <JIRA.12479851.1353935247000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12479851.1353935247000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12479851.1353935247000.21292.1395065532584@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1547?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12953529#comment-12953529 ] 

RH Bugzilla Integration commented on WFLY-1547:
-----------------------------------------------

Kabir Khan <kkhan at redhat.com> changed the Status of [bug 901210|https://bugzilla.redhat.com/show_bug.cgi?id=901210] from POST to MODIFIED
                
> deploy directories not cleaned up
> ---------------------------------
>
>                 Key: WFLY-1547
>                 URL: https://issues.jboss.org/browse/WFLY-1547
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 8.0.0.Alpha1
>            Reporter: Shaun Appleton
>            Assignee: jaikiran pai
>             Fix For: 8.0.0.Beta1
>
>         Attachments: deployment_with_hack_no_hook.txt
>
>
> JBoss EAP 6.0.0 (and 6.0.1.ER3) doesn't clean up it's tmp/vfs directories.
> The following reproduces this -
> i) ensure run.conf has the -Xrs set
> ii) ensure deployments has a deployable .ear in it
> iii) ./run standalone.sh and allow the deployments to deploy
> iv) stop the EAP process ie kill <process_id>
> v) observe content tmp/vfs
> (The -Xrs parameter is used to "-Xrs" to prevent possible interference when JVM is running as a service and receives CTRL_LOGOFF_EVENT or SIGHUP)
> This will eventually cause problems with lack of disk space.
> Note if the -Xrs parameter content is removed but the tmp/vfs dirs stills exist. This could potentially cause inode problems.
> It would be better if there were any additional code so the temp dirs are cleaned up on start up. That would resolve both the -Xrs problem and the excessive dir creation.

--
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

From issues at jboss.org  Mon Mar 17 10:12:12 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 17 Mar 2014 10:12:12 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3108) Can't promote --backup slave
 HC to master and reload without moving domain.cached-remote.xml
In-Reply-To: <JIRA.12534873.1394711186000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534873.1394711186000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534873.1394711186000.21298.1395065532875@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-3108?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12953530#comment-12953530 ] 

RH Bugzilla Integration commented on WFLY-3108:
-----------------------------------------------

Kabir Khan <kkhan at redhat.com> changed the Status of [bug 1076066|https://bugzilla.redhat.com/show_bug.cgi?id=1076066] from POST to MODIFIED
                
> Can't promote --backup slave HC to master and reload without moving domain.cached-remote.xml
> --------------------------------------------------------------------------------------------
>
>                 Key: WFLY-3108
>                 URL: https://issues.jboss.org/browse/WFLY-3108
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>    Affects Versions: 8.0.0.Final
>            Reporter: Brian Stansberry
>            Assignee: Brian Stansberry
>             Fix For: 8.0.1.Final
>
>
> The prescribed mechanism for converting a slave HC to master is to:
> 1) Start the slave with --backup so a local copy of the domain config is maintained (in file domain.cached-remote.xml).
> 2) Stop the existing master.
> 3) Use the cli to connect to the slave and
> /host=<slavename>:write-local-domain-controller
> 4) Then, in the CLI
> reload --host=<slavename>
> Problem is this fails because the HC expects to have a domain config file "domain.xml".
> 2014-03-13 09:54:04,829 ERROR [org.jboss.as.host.controller] (Controller Boot Thread) JBAS010932: Caught exception during boot: org.jboss.as.controller.persistence.ConfigurationPersistenceException: JBAS014676: Failed to parse configuration
> 	at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:112) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> 	at org.jboss.as.host.controller.DomainModelControllerService.boot(DomainModelControllerService.java:514) [wildfly-host-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> 	at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:256) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> 	at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_45]
> Caused by: java.io.FileNotFoundException: /Users/bstansberry/tmp/WF801/slave/domain/configuration/domain.xml (No such file or directory)
> 	at java.io.FileInputStream.open(Native Method) [rt.jar:1.7.0_45]
> 	at java.io.FileInputStream.<init>(FileInputStream.java:146) [rt.jar:1.7.0_45]
> 	at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:100) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> 	... 3 more
> Or, MUCH WORSE, there happens to be a random domain.xml in the filesystem, which has content that is out of sync with the correct domain config. This domain.xml config will be used.

--
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

From issues at jboss.org  Mon Mar 17 10:12:13 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 17 Mar 2014 10:12:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3112) One can't change history and
 decay with DynamicLoadBalanceFactorProvider
In-Reply-To: <JIRA.12534709.1394560666000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534709.1394560666000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534709.1394560666000.21308.1395065533544@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-3112?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12953532#comment-12953532 ] 

RH Bugzilla Integration commented on WFLY-3112:
-----------------------------------------------

Kabir Khan <kkhan at redhat.com> changed the Status of [bug 1075215|https://bugzilla.redhat.com/show_bug.cgi?id=1075215] from POST to MODIFIED
                
> One can't change history and decay with DynamicLoadBalanceFactorProvider
> ------------------------------------------------------------------------
>
>                 Key: WFLY-3112
>                 URL: https://issues.jboss.org/browse/WFLY-3112
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Clustering
>    Affects Versions: 8.0.0.Final
>            Reporter: Michal Babacek
>            Assignee: Radoslav Husar
>            Priority: Critical
>             Fix For: 8.0.1.Final
>
>         Attachments: redacted_log
>
>
> I'm under an ugly impression that one can't actually change {{history}} and {{decay}} attributes of *DynamicLoadBalanceFactorProvider*.
> I was trying to figure out why the new test suite of CustomLoadMetric tests does not pass. In order to get load figures without history and decay manipulation, I set the following:
> {code}
> <subsystem xmlns="urn:jboss:domain:modcluster:1.2">
>     <mod-cluster-config advertise-socket="modcluster" connector="ajp">
>     <dynamic-load-provider history="0">
>         <custom-load-metric class="biz.karms.modcluster.CustomLoadMetric" weight="1">
>             <property name="capacity" value="1000"/>
>             <property name="loadfile" value="/tmp/mod_cluster-eapx/loadfileA"/>
>             <property name="parseexpression" value="^LOAD: ([0-9]*)$"/>
>         </custom-load-metric>
>     </dynamic-load-provider>
>     </mod-cluster-config>
> </subsystem>
> {code}
> The aforementioned {{history=0}} effectively means that there is just 1 "slot" for a one historical value on which decay function should work.
> If you take a look at the code in [DynamicLoadBalanceFactorProvider|https://github.com/modcluster/mod_cluster/blob/master/core/src/main/java/org/jboss/modcluster/load/impl/DynamicLoadBalanceFactorProvider.java#L54] constructor, it is apparent
> that the size of the List that later serves for storing the historical values is set sooner than the actual [setHistory(int history)|https://github.com/modcluster/mod_cluster/blob/master/core/src/main/java/org/jboss/modcluster/load/impl/DynamicLoadBalanceFactorProvider.java#L177] method is called.
> The actual size of that List collection wouldn't do any harm by itself but it is being used in the aforementioned class with {{.size()}} to control cycles.
> The same IMHO holds for the decay attribute.
> Anyhow, I put some additional logging to the [DynamicLoadBalanceFactorProvider.java|https://github.com/modcluster/mod_cluster/blob/master/core/src/main/java/org/jboss/modcluster/load/impl/DynamicLoadBalanceFactorProvider.java]:
> {code}
> // Historical value contribute an exponentially decayed factor
> for (int i = 0; i < queue.size(); ++i) {
>     double decay = 1 / Math.pow(decayFactor, i);
>     totalDecay += decay;
>     this.log.info("KTAG: totalLoad:"+totalLoad+", with decay:"+(totalLoad+queue.get(i).doubleValue() * decay));
>     totalLoad += queue.get(i).doubleValue() * decay;
> }
> {code}
> and
> {code}
> try {
>     // Normalize load with respect to capacity
>     this.recordLoad(metricLoadHistory, metric.getLoad(engine) / metric.getCapacity());
>     this.log.info("KTAG metricLoadHistory:"+metricLoadHistory.toString());
>     totalWeight += weight;
>     totalWeightedLoad += this.average(metricLoadHistory) * weight;
> } catch (Exception e) {
>     this.log.error(e.getLocalizedMessage(), e);
> }
> {code}
> with the following being the output: [^redacted_log].
> So, despite having {{history=0}}, which should force the system to keep just 1, the current value, {{metricLoadHistory}} grew from
> {noformat}
> KTAG metricLoadHistory:[0.8]
> {noformat}
> to
> {noformat}
> KTAG metricLoadHistory:[0.9, 0.9, 0.9, 0.9, 0.9, 0.9, 0.9, 0.9, 0.9, 0.8]
> {noformat}
> which is exactly [9|https://github.com/modcluster/mod_cluster/blob/master/core/src/main/java/org/jboss/modcluster/load/impl/DynamicLoadBalanceFactorProvider.java#L50] + [1|https://github.com/modcluster/mod_cluster/blob/master/core/src/main/java/org/jboss/modcluster/load/impl/DynamicLoadBalanceFactorProvider.java#L54] in size :-)
> WDYT?

--
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

From issues at jboss.org  Mon Mar 17 10:24:10 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 17 Mar 2014 10:24:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-450) Cannot use decimal
 formatters for integers in an excel decision table
In-Reply-To: <JIRA.12534705.1394557254000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534705.1394557254000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534705.1394557254000.21338.1395066250853@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-450?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated DROOLS-450:
-------------------------------------------

        Bugzilla Update: Perform
    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1077228

    
> Cannot use decimal formatters for integers in an excel decision table
> ---------------------------------------------------------------------
>
>                 Key: DROOLS-450
>                 URL: https://issues.jboss.org/browse/DROOLS-450
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 6.0.1.Final
>            Reporter: Maxime Falaize
>            Assignee: Michael Anstis
>            Priority: Minor
>             Fix For: 6.1.0.Beta2
>
>         Attachments: issue_example.png
>
>
> When I use decimal formatter in an excel action column for numbers that are in fact integers, I am getting this exception :
> {noformat}
> Exception in thread "main" java.lang.RuntimeException: Error while creating KieBase[Message [id=1, level=ERROR, path=com/sample/my_decision_table.xls, line=5, column=0
>    text=Rule Compilation error The method setParameter(double) in the type MyObject is not applicable for the arguments (int, int)]]
> 	at org.drools.compiler.kie.builder.impl.KieContainerImpl.getKieBase(KieContainerImpl.java:260)
> 	at org.drools.compiler.kie.builder.impl.KieContainerImpl.newKieSession(KieContainerImpl.java:400)
> 	at org.drools.compiler.kie.builder.impl.KieContainerImpl.newKieSession(KieContainerImpl.java:375)
> {noformat}
> Actually, the system uses the format number "1,00000" (with comma in french) instead of "1.00000" like it should use.
> This is causing by the line 174 in org.drools.decisiontable.parser.xls.ExcelParser :
> {code:java}
> if ( num - Math.round( num ) != 0 )
> {code}
> I don't understand why we use the formatted value when this test is not passed.
> I think the end users should have the possibility to keep the same formatter for the same column, with integers or not.

--
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

From issues at jboss.org  Mon Mar 17 10:32:10 2014
From: issues at jboss.org (Shelly McGowan (JIRA))
Date: Mon, 17 Mar 2014 10:32:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3123) Update Java EE APIs
In-Reply-To: <JIRA.12535159.1395066619331@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12535159.1395066619331@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12535159.1395066619331.21345.1395066730630@jira02.app.mwc.hst.phx2.redhat.com>

Shelly McGowan created WFLY-3123:
------------------------------------

             Summary: Update Java EE APIs
                 Key: WFLY-3123
                 URL: https://issues.jboss.org/browse/WFLY-3123
             Project: WildFly
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: EE
            Reporter: Shelly McGowan
            Assignee: Shelly McGowan
             Fix For: 8.0.1.Final


There were a few bug fix releases of the JBoss Java EE API projects to include in WildFly.

--
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

From issues at jboss.org  Mon Mar 17 10:36:12 2014
From: issues at jboss.org (Shelly McGowan (JIRA))
Date: Mon, 17 Mar 2014 10:36:12 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBEE-152) Release JSP 2.3 APIs
In-Reply-To: <JIRA.12535160.1395066857511@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12535160.1395066857511@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12535160.1395066857511.21353.1395066972447@jira02.app.mwc.hst.phx2.redhat.com>

Shelly McGowan created JBEE-152:
-----------------------------------

             Summary: Release JSP 2.3 APIs 
                 Key: JBEE-152
                 URL: https://issues.jboss.org/browse/JBEE-152
             Project: JBoss JavaEE Spec APIs
          Issue Type: Bug
          Components: jboss-jsp-api
            Reporter: Shelly McGowan
            Assignee: Shelly McGowan


JSP update needed to include bug fix:
https://github.com/jboss/jboss-jsp-api_spec/commit/219be2052b0487624f209f16821ae8c4e840a6fc

--
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

From issues at jboss.org  Mon Mar 17 10:48:10 2014
From: issues at jboss.org (Vojtech Juranek (JIRA))
Date: Mon, 17 Mar 2014 10:48:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3124) JXM PluggableMBeanServerImpl
 assumes RealmUser principal
In-Reply-To: <JIRA.12535162.1395067666075@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12535162.1395067666075@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12535162.1395067666075.21385.1395067690838@jira02.app.mwc.hst.phx2.redhat.com>

Vojtech Juranek created WFLY-3124:
-------------------------------------

             Summary: JXM PluggableMBeanServerImpl assumes RealmUser principal
                 Key: WFLY-3124
                 URL: https://issues.jboss.org/browse/WFLY-3124
             Project: WildFly
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: JMX
    Affects Versions: 8.0.0.Final
            Reporter: Vojtech Juranek
            Assignee: Kabir Khan


JXM {{PluggableMBeanServerImpl$LogAction}} assumes that {{RealmUser}} principal is present when Subject is not null. This condition is not always met and results into following exception:
{noformat}
Caused by: java.util.NoSuchElementException
        at java.util.HashMap$HashIterator.nextEntry(HashMap.java:929)
        at java.util.HashMap$KeyIterator.next(HashMap.java:960)
        at org.jboss.as.jmx.PluggableMBeanServerImpl$LogAction.getCallerUserId(PluggableMBeanServerImpl.java:1250)
        at org.jboss.as.jmx.PluggableMBeanServerImpl$LogAction.doLog(PluggableMBeanServerImpl.java:1233)
        at org.jboss.as.jmx.PluggableMBeanServerImpl.log(PluggableMBeanServerImpl.java:1158)
        at org.jboss.as.jmx.MBeanServerAuditLogRecordFormatter.log(MBeanServerAuditLogRecordFormatter.java:331)
        at org.jboss.as.jmx.MBeanServerAuditLogRecordFormatter.queryNames(MBeanServerAuditLogRecordFormatter.java:170)
        at org.jboss.as.jmx.PluggableMBeanServerImpl.queryNames(PluggableMBeanServerImpl.java:871)
        at org.infinispan.jmx.JmxUtil.findJmxDomain(JmxUtil.java:127)

{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

From issues at jboss.org  Mon Mar 17 10:50:10 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 17 Mar 2014 10:50:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-421) EvaluatorWrapper does not
 resolve the right handle correctly
In-Reply-To: <JIRA.12531077.1391475908000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12531077.1391475908000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12531077.1391475908000.21393.1395067810822@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/DROOLS-421?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12953548#comment-12953548 ] 

RH Bugzilla Integration commented on DROOLS-421:
------------------------------------------------

Marek Winkler <mwinkler at redhat.com> changed the Status of [bug 1063809|https://bugzilla.redhat.com/show_bug.cgi?id=1063809] from ON_QA to VERIFIED
                
> EvaluatorWrapper does not resolve the right handle correctly
> ------------------------------------------------------------
>
>                 Key: DROOLS-421
>                 URL: https://issues.jboss.org/browse/DROOLS-421
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.5.1.Final, 6.0.0.Final, 6.0.1.Final, 6.1.0.Beta1
>            Reporter: Davide Sottara
>            Assignee: Mario Fusco
>            Priority: Critical
>             Fix For: 6.1.0.Beta1
>
>
> The EvaluatorWrapper tries to look up the right handle from the WM, but there may be cases (e.g. when the right input comes from a FROM node)
> where the handle is not in the WM, causing a NPE. This causes the right handle to be null, or to be resolved incorrectly. Evaluations are then inconsistent.

--
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

From issues at jboss.org  Mon Mar 17 10:56:11 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 17 Mar 2014 10:56:11 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-426) Globals can't be used with
 temporal operators
In-Reply-To: <JIRA.12531807.1392151630000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12531807.1392151630000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12531807.1392151630000.21434.1395068171018@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/DROOLS-426?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12953550#comment-12953550 ] 

RH Bugzilla Integration commented on DROOLS-426:
------------------------------------------------

Marek Winkler <mwinkler at redhat.com> changed the Status of [bug 1064224|https://bugzilla.redhat.com/show_bug.cgi?id=1064224] from ON_QA to VERIFIED
                
> Globals can't be used with temporal operators
> ---------------------------------------------
>
>                 Key: DROOLS-426
>                 URL: https://issues.jboss.org/browse/DROOLS-426
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Davide Sottara
>            Assignee: Mario Fusco
>            Priority: Critical
>             Fix For: 6.1.0.Beta1
>
>
> Assuming:
> global Date now;
> The pattern "Foo( this before now )" will generate various errors.
> The reason is that the Global[X]Extractors (X = {"","Date","Number"}
> are erroneously declared as self-referential extractors.
> If Foo is not an @event, a CCE will arise since the operators will use
> "this" rather than the global. Otherwise, the result will be inconsistent

--
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

From issues at jboss.org  Mon Mar 17 11:00:12 2014
From: issues at jboss.org (Tomas Lamr (JIRA))
Date: Mon, 17 Mar 2014 11:00:12 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBAS-9560) child of
 java.rmi.server.UnicastRemoteObject always sent as value when remote jndi
 lookup
In-Reply-To: <JIRA.12535167.1395068349757@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12535167.1395068349757@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12535167.1395068349757.21451.1395068412617@jira02.app.mwc.hst.phx2.redhat.com>

Tomas Lamr created JBAS-9560:
--------------------------------

             Summary: child of java.rmi.server.UnicastRemoteObject always sent as value when remote jndi lookup
                 Key: JBAS-9560
                 URL: https://issues.jboss.org/browse/JBAS-9560
             Project: Application Server 3  4  5 and 6
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Remoting
    Affects Versions: 6.1.0
         Environment: debian testing
            Reporter: Tomas Lamr


Reproducible also on jboss eap 6.2 i.e. AS 7.3.

We have an legacy j2ee app that runs on many application servers. We are trying to port it to AS 7.x, but found one issue.

We use java rmi. Our remote interface implementation (ImplClass) extends java.rmi.server.UnicastRemoteObject. We have a singleton instance of this class in our app that is initialized at the start of the application and then bound into the jndi tree.

For this, we use a context created with org.jboss.as.naming.InitialContextFactory as java.naming.factory.initial
We bind to "java:jboss/exported/" prefix and it works for us for all the other simple values but not for our ImplClass.

When doing lookup on the server, the jndi lookup returns correctly an instance that was created on the server pointing to local connection, but when doing lookup on client with this context
{code}
org.jboss.naming.remote.client.InitialContextFactory
remote://localhost:port/
{code}

we retrieve the same instance as on the server that point to local connection. Hence it seems, that our object is always copied and sent as a value to the client instead of sending the remote proxy which can be used on the client.

The same code works on jboss AS 5.1 (when using jnp) and also on netweaver, websphere and weblogic when using their context implementations.

It would be great if this could be also fixed in jboss as 7.x.

Known workaround: Use a java.rmi.registry.Registry on the server for registering proxy instead of jndi.

According to this site (and possibly some spec)
http://www.javaworld.com/article/2076234/soa/get-smart-with-proxies-and-rmi.html
an object should be passed by value if and only if it is implementing Serializable interface, but the current implementation in jboss as 7.x does not respect this and always passes objects by value.

--
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

From issues at jboss.org  Mon Mar 17 11:02:11 2014
From: issues at jboss.org (Tomas Lamr (JIRA))
Date: Mon, 17 Mar 2014 11:02:11 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBAS-9560) child of
 java.rmi.server.UnicastRemoteObject always sent as value when remote jndi
 lookup
In-Reply-To: <JIRA.12535167.1395068349000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12535167.1395068349000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12535167.1395068349000.21483.1395068531706@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBAS-9560?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tomas Lamr updated JBAS-9560:
-----------------------------


Issue created for the wrong project, please close.
                
> child of java.rmi.server.UnicastRemoteObject always sent as value when remote jndi lookup
> -----------------------------------------------------------------------------------------
>
>                 Key: JBAS-9560
>                 URL: https://issues.jboss.org/browse/JBAS-9560
>             Project: Application Server 3  4  5 and 6
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Remoting
>    Affects Versions: 6.1.0
>         Environment: debian testing
>            Reporter: Tomas Lamr
>
> Reproducible also on jboss eap 6.2 i.e. AS 7.3.
> We have an legacy j2ee app that runs on many application servers. We are trying to port it to AS 7.x, but found one issue.
> We use java rmi. Our remote interface implementation (ImplClass) extends java.rmi.server.UnicastRemoteObject. We have a singleton instance of this class in our app that is initialized at the start of the application and then bound into the jndi tree.
> For this, we use a context created with org.jboss.as.naming.InitialContextFactory as java.naming.factory.initial
> We bind to "java:jboss/exported/" prefix and it works for us for all the other simple values but not for our ImplClass.
> When doing lookup on the server, the jndi lookup returns correctly an instance that was created on the server pointing to local connection, but when doing lookup on client with this context
> {code}
> org.jboss.naming.remote.client.InitialContextFactory
> remote://localhost:port/
> {code}
> we retrieve the same instance as on the server that point to local connection. Hence it seems, that our object is always copied and sent as a value to the client instead of sending the remote proxy which can be used on the client.
> The same code works on jboss AS 5.1 (when using jnp) and also on netweaver, websphere and weblogic when using their context implementations.
> It would be great if this could be also fixed in jboss as 7.x.
> Known workaround: Use a java.rmi.registry.Registry on the server for registering proxy instead of jndi.
> According to this site (and possibly some spec)
> http://www.javaworld.com/article/2076234/soa/get-smart-with-proxies-and-rmi.html
> an object should be passed by value if and only if it is implementing Serializable interface, but the current implementation in jboss as 7.x does not respect this and always passes objects by value.

--
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

From issues at jboss.org  Mon Mar 17 11:10:10 2014
From: issues at jboss.org (Tomas Lamr (JIRA))
Date: Mon, 17 Mar 2014 11:10:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBAS-9560) implemtentation of
 java.rmi.server.UnicastRemoteObject always sent as value when remote jndi
 lookup
In-Reply-To: <JIRA.12535167.1395068349000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12535167.1395068349000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12535167.1395068349000.21514.1395069010711@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBAS-9560?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tomas Lamr updated JBAS-9560:
-----------------------------

    Summary: implemtentation of java.rmi.server.UnicastRemoteObject always sent as value when remote jndi lookup  (was: child of java.rmi.server.UnicastRemoteObject always sent as value when remote jndi lookup)


JBEAP-52
                
> implemtentation of java.rmi.server.UnicastRemoteObject always sent as value when remote jndi lookup
> ---------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-9560
>                 URL: https://issues.jboss.org/browse/JBAS-9560
>             Project: Application Server 3  4  5 and 6
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Remoting
>    Affects Versions: 6.1.0
>         Environment: debian testing
>            Reporter: Tomas Lamr
>
> Reproducible also on jboss eap 6.2 i.e. AS 7.3.
> We have an legacy j2ee app that runs on many application servers. We are trying to port it to AS 7.x, but found one issue.
> We use java rmi. Our remote interface implementation (ImplClass) extends java.rmi.server.UnicastRemoteObject. We have a singleton instance of this class in our app that is initialized at the start of the application and then bound into the jndi tree.
> For this, we use a context created with org.jboss.as.naming.InitialContextFactory as java.naming.factory.initial
> We bind to "java:jboss/exported/" prefix and it works for us for all the other simple values but not for our ImplClass.
> When doing lookup on the server, the jndi lookup returns correctly an instance that was created on the server pointing to local connection, but when doing lookup on client with this context
> {code}
> org.jboss.naming.remote.client.InitialContextFactory
> remote://localhost:port/
> {code}
> we retrieve the same instance as on the server that point to local connection. Hence it seems, that our object is always copied and sent as a value to the client instead of sending the remote proxy which can be used on the client.
> The same code works on jboss AS 5.1 (when using jnp) and also on netweaver, websphere and weblogic when using their context implementations.
> It would be great if this could be also fixed in jboss as 7.x.
> Known workaround: Use a java.rmi.registry.Registry on the server for registering proxy instead of jndi.
> According to this site (and possibly some spec)
> http://www.javaworld.com/article/2076234/soa/get-smart-with-proxies-and-rmi.html
> an object should be passed by value if and only if it is implementing Serializable interface, but the current implementation in jboss as 7.x does not respect this and always passes objects by value.

--
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

From issues at jboss.org  Mon Mar 17 11:38:11 2014
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Mon, 17 Mar 2014 11:38:11 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3108) Can't promote --backup slave
 HC to master and reload without moving domain.cached-remote.xml
In-Reply-To: <JIRA.12534873.1394711186000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534873.1394711186000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534873.1394711186000.21603.1395070691043@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-3108?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFLY-3108:
-----------------------------------

    Bugzilla Update:   (was: Perform)

    
> Can't promote --backup slave HC to master and reload without moving domain.cached-remote.xml
> --------------------------------------------------------------------------------------------
>
>                 Key: WFLY-3108
>                 URL: https://issues.jboss.org/browse/WFLY-3108
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>    Affects Versions: 8.0.0.Final
>            Reporter: Brian Stansberry
>            Assignee: Brian Stansberry
>             Fix For: 8.0.1.Final
>
>
> The prescribed mechanism for converting a slave HC to master is to:
> 1) Start the slave with --backup so a local copy of the domain config is maintained (in file domain.cached-remote.xml).
> 2) Stop the existing master.
> 3) Use the cli to connect to the slave and
> /host=<slavename>:write-local-domain-controller
> 4) Then, in the CLI
> reload --host=<slavename>
> Problem is this fails because the HC expects to have a domain config file "domain.xml".
> 2014-03-13 09:54:04,829 ERROR [org.jboss.as.host.controller] (Controller Boot Thread) JBAS010932: Caught exception during boot: org.jboss.as.controller.persistence.ConfigurationPersistenceException: JBAS014676: Failed to parse configuration
> 	at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:112) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> 	at org.jboss.as.host.controller.DomainModelControllerService.boot(DomainModelControllerService.java:514) [wildfly-host-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> 	at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:256) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> 	at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_45]
> Caused by: java.io.FileNotFoundException: /Users/bstansberry/tmp/WF801/slave/domain/configuration/domain.xml (No such file or directory)
> 	at java.io.FileInputStream.open(Native Method) [rt.jar:1.7.0_45]
> 	at java.io.FileInputStream.<init>(FileInputStream.java:146) [rt.jar:1.7.0_45]
> 	at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:100) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> 	... 3 more
> Or, MUCH WORSE, there happens to be a random domain.xml in the filesystem, which has content that is out of sync with the correct domain config. This domain.xml config will be used.

--
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

From issues at jboss.org  Mon Mar 17 11:56:10 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 17 Mar 2014 11:56:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-444) NOT conditional element is
 broken when used with subnetworks
In-Reply-To: <JIRA.12533569.1393544376000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12533569.1393544376000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12533569.1393544376000.21656.1395071770737@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/DROOLS-444?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12953579#comment-12953579 ] 

RH Bugzilla Integration commented on DROOLS-444:
------------------------------------------------

Marek Winkler <mwinkler at redhat.com> changed the Status of [bug 1072462|https://bugzilla.redhat.com/show_bug.cgi?id=1072462] from ON_QA to VERIFIED
                
> NOT conditional element is broken when used with subnetworks
> ------------------------------------------------------------
>
>                 Key: DROOLS-444
>                 URL: https://issues.jboss.org/browse/DROOLS-444
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 6.0.0.Final, 6.0.1.Final
>            Reporter: Davide Sottara
>            Assignee: Mario Fusco
>            Priority: Critical
>             Fix For: 6.1.0.Beta1
>
>


--
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

From issues at jboss.org  Mon Mar 17 12:00:12 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 17 Mar 2014 12:00:12 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-391) Support class literals with
 complex constraints and custom evaluators
In-Reply-To: <JIRA.12528582.1388747122000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528582.1388747122000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528582.1388747122000.21680.1395072012654@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/DROOLS-391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12953584#comment-12953584 ] 

RH Bugzilla Integration commented on DROOLS-391:
------------------------------------------------

Marek Winkler <mwinkler at redhat.com> changed the Status of [bug 1063795|https://bugzilla.redhat.com/show_bug.cgi?id=1063795] from ON_QA to VERIFIED
                
> Support class literals with complex constraints and custom evaluators
> ---------------------------------------------------------------------
>
>                 Key: DROOLS-391
>                 URL: https://issues.jboss.org/browse/DROOLS-391
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.5.1.Final, 6.0.0.Final
>            Reporter: Davide Sottara
>            Assignee: Mario Fusco
>             Fix For: 6.1.0.Beta1
>
>
> The following is supported, when A is a class name:
> {code} Pattern( this op A ) {code}
> But the following fails with a CCE
> {code} Pattern( this op A || this op B ) {code}
> when it tries to resolve A as a field of the class Pattern

--
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

From issues at jboss.org  Mon Mar 17 12:06:10 2014
From: issues at jboss.org (James Perkins (JIRA))
Date: Mon, 17 Mar 2014 12:06:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2395)
 RootSubsystemOperationsTestCase fails if log directory wasn't properly
 cleaned
In-Reply-To: <JIRA.12508911.1382999078000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508911.1382999078000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508911.1382999078000.21685.1395072370654@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2395?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

James Perkins updated WFLY-2395:
--------------------------------

    Fix Version/s:     (was: 8.0.1.Final)

    
> RootSubsystemOperationsTestCase fails if log directory wasn't properly cleaned
> ------------------------------------------------------------------------------
>
>                 Key: WFLY-2395
>                 URL: https://issues.jboss.org/browse/WFLY-2395
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Logging
>            Reporter: James Perkins
>            Assignee: James Perkins
>
> Some test appears to not be cleaning up the {{target/logs}} directory which causes the tests to fail. While tests should be cleaning up after themselves, the test in the {{RootSubsystemOperationsTestCase}} should also not look for empty directories, but look for the files that _shouldn't_ be there.
> Files left  behind:
> {code}
> [root at build01 logging]# ls -l target/logs/
> total 0
> -rw-r--r-- 1 root root 0 Oct 28 23:00 another.log
> -rw-r--r-- 1 root root 0 Oct 28 23:00 anotherProfile.log
> -rw-r--r-- 1 root root 0 Oct 28 23:00 fileHandler.log
> -rw-r--r-- 1 root root 0 Oct 28 23:00 profileFileHandler.log
> -rw-r--r-- 1 root root 0 Oct 28 23:00 server.log
> -rw-r--r-- 1 root root 0 Oct 28 23:00 sizeLogger.log
> {code}

--
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

From issues at jboss.org  Mon Mar 17 14:30:10 2014
From: issues at jboss.org (John L (JIRA))
Date: Mon, 17 Mar 2014 14:30:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBJCA-1156) encrypted datasource
 security , big performence hit.
In-Reply-To: <JIRA.12535189.1395080950209@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12535189.1395080950209@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12535189.1395080950209.22156.1395081010749@jira02.app.mwc.hst.phx2.redhat.com>

John L created JBJCA-1156:
-----------------------------

             Summary: encrypted datasource security , big performence hit.
                 Key: JBJCA-1156
                 URL: https://issues.jboss.org/browse/JBJCA-1156
             Project: IronJacamar
          Issue Type: Bug
    Affects Versions: 1.0.12.Final
         Environment: using jboss 7.1.1 or jboss 7.1.3
            Reporter: John L
            Assignee: Jesper Pedersen


We setup our jboss7.1.3 to use encrypted datasource passwords:

   <datasources>

                <datasource jndi-name="java:/SomDS" pool-name="SomeDS" enabled="true" use-java-context="true">

.....

                    <security>

                        <security-domain>some-encrypted-ds</security-domain>

                    </security>

                </datasource>

 

...
            	<security-domain name="some-encrypted-ds" cache-type="default">
                	<authentication>
                    	<login-module code="org.picketbox.datasource.security.SecureIdentityLoginModule" flag="required">
                        	<module-option name="username" value="some"/>
                        	<module-option name="password" value="-......."/>
                    	</login-module>
                	</authentication>
            	</security-domain>

By using this our system took a 30% performance hit.

Some transactions might call getConnection 50 times.

It seems from looking at code that even if a connection already exists in the pool the password is
decrypted on every call to get a connection from the datasource.

Seems like it should only decrypt when a new connection is created to the database.

Moving back to unencrypted passwords solves the performance problem.

That is using:

<security xmlns="urn:jboss:domain:datasources:1.1">

                    <user-name>xxx</user-name>

                    <password>yyy</password>

                </security>

--
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

From issues at jboss.org  Mon Mar 17 14:40:10 2014
From: issues at jboss.org (Jesper Pedersen (JIRA))
Date: Mon, 17 Mar 2014 14:40:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBJCA-1156) encrypted datasource
 security , big performence hit.
In-Reply-To: <JIRA.12535189.1395080950000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12535189.1395080950000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12535189.1395080950000.22169.1395081610567@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBJCA-1156?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jesper Pedersen closed JBJCA-1156.
----------------------------------

    Resolution: Rejected


Pool your connections, and use a forum post to discuss this. Otherwise talk to the PicketBox people
                
> encrypted datasource security , big performence hit.
> ----------------------------------------------------
>
>                 Key: JBJCA-1156
>                 URL: https://issues.jboss.org/browse/JBJCA-1156
>             Project: IronJacamar
>          Issue Type: Bug
>    Affects Versions: 1.0.12.Final
>         Environment: using jboss 7.1.1 or jboss 7.1.3
>            Reporter: John L
>            Assignee: Jesper Pedersen
>
> We setup our jboss7.1.3 to use encrypted datasource passwords:
>    <datasources>
>                 <datasource jndi-name="java:/SomDS" pool-name="SomeDS" enabled="true" use-java-context="true">
> .....
>                     <security>
>                         <security-domain>some-encrypted-ds</security-domain>
>                     </security>
>                 </datasource>
>  
> ...
>             	<security-domain name="some-encrypted-ds" cache-type="default">
>                 	<authentication>
>                     	<login-module code="org.picketbox.datasource.security.SecureIdentityLoginModule" flag="required">
>                         	<module-option name="username" value="some"/>
>                         	<module-option name="password" value="-......."/>
>                     	</login-module>
>                 	</authentication>
>             	</security-domain>
> By using this our system took a 30% performance hit.
> Some transactions might call getConnection 50 times.
> It seems from looking at code that even if a connection already exists in the pool the password is
> decrypted on every call to get a connection from the datasource.
> Seems like it should only decrypt when a new connection is created to the database.
> Moving back to unencrypted passwords solves the performance problem.
> That is using:
> <security xmlns="urn:jboss:domain:datasources:1.1">
>                     <user-name>xxx</user-name>
>                     <password>yyy</password>
>                 </security>

--
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

From issues at jboss.org  Mon Mar 17 14:52:10 2014
From: issues at jboss.org (John L (JIRA))
Date: Mon, 17 Mar 2014 14:52:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBJCA-1156) encrypted datasource
 security , big performence hit.
In-Reply-To: <JIRA.12535189.1395080950000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12535189.1395080950000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12535189.1395080950000.22176.1395082330729@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBJCA-1156?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

John L reopened JBJCA-1156:
---------------------------



I did use forums and they told me to post this issue.
https://community.jboss.org/thread/237957

I don't think it is a picket code issue either. 
The pool should defer getting passwords.
The code PoolBySubject.java and SubjectKey.java
and a few other classes in strategy package seem
to be the area that causes all this to happen.


                
> encrypted datasource security , big performence hit.
> ----------------------------------------------------
>
>                 Key: JBJCA-1156
>                 URL: https://issues.jboss.org/browse/JBJCA-1156
>             Project: IronJacamar
>          Issue Type: Bug
>    Affects Versions: 1.0.12.Final
>         Environment: using jboss 7.1.1 or jboss 7.1.3
>            Reporter: John L
>            Assignee: Jesper Pedersen
>
> We setup our jboss7.1.3 to use encrypted datasource passwords:
>    <datasources>
>                 <datasource jndi-name="java:/SomDS" pool-name="SomeDS" enabled="true" use-java-context="true">
> .....
>                     <security>
>                         <security-domain>some-encrypted-ds</security-domain>
>                     </security>
>                 </datasource>
>  
> ...
>             	<security-domain name="some-encrypted-ds" cache-type="default">
>                 	<authentication>
>                     	<login-module code="org.picketbox.datasource.security.SecureIdentityLoginModule" flag="required">
>                         	<module-option name="username" value="some"/>
>                         	<module-option name="password" value="-......."/>
>                     	</login-module>
>                 	</authentication>
>             	</security-domain>
> By using this our system took a 30% performance hit.
> Some transactions might call getConnection 50 times.
> It seems from looking at code that even if a connection already exists in the pool the password is
> decrypted on every call to get a connection from the datasource.
> Seems like it should only decrypt when a new connection is created to the database.
> Moving back to unencrypted passwords solves the performance problem.
> That is using:
> <security xmlns="urn:jboss:domain:datasources:1.1">
>                     <user-name>xxx</user-name>
>                     <password>yyy</password>
>                 </security>

--
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

From issues at jboss.org  Mon Mar 17 15:50:10 2014
From: issues at jboss.org (Eduardo Martins (JIRA))
Date: Mon, 17 Mar 2014 15:50:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2881)
 org.jboss.as.ejb3.timer.schedule.CalendarBasedTimeoutTestCase#testCalendarBasedTimeout
In-Reply-To: <JIRA.12531524.1391864503000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12531524.1391864503000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12531524.1391864503000.22311.1395085810902@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2881?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Eduardo Martins reassigned WFLY-2881:
-------------------------------------

    Assignee: Eduardo Martins  (was: Tomaz Cerar)

    
> org.jboss.as.ejb3.timer.schedule.CalendarBasedTimeoutTestCase#testCalendarBasedTimeout
> --------------------------------------------------------------------------------------
>
>                 Key: WFLY-2881
>                 URL: https://issues.jboss.org/browse/WFLY-2881
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: EJB
>    Affects Versions: 8.0.0.Final
>            Reporter: Frank Langelage
>            Assignee: Eduardo Martins
>         Attachments: org.jboss.as.ejb3.timer.schedule.CalendarBasedTimeoutTestCase.txt, TEST-org.jboss.as.ejb3.timer.schedule.CalendarBasedTimeoutTestCase.xml
>
>
> Running build with smoke tests on current github sources I get failure in this test case.
> HOUR_OF_DAY is not 0 as expected but 1.
> I changed the Assert in the test case to print out firstTimeout.toString() instead of only timeZoneDisplayName.
> See attached files for more.

--
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

From issues at jboss.org  Mon Mar 17 16:52:10 2014
From: issues at jboss.org (Jason Greene (JIRA))
Date: Mon, 17 Mar 2014 16:52:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3102) EJB in WAR should inherit
 WAR's security domain
In-Reply-To: <JIRA.12534724.1394575248000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534724.1394575248000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534724.1394575248000.22353.1395089530669@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-3102?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12953658#comment-12953658 ] 

Jason Greene commented on WFLY-3102:
------------------------------------

hmm I suppose its too risky to do in 8.0.1 but it could be 9.0
                
> EJB in WAR should inherit WAR's security domain
> -----------------------------------------------
>
>                 Key: WFLY-3102
>                 URL: https://issues.jboss.org/browse/WFLY-3102
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Web (Undertow)
>    Affects Versions: 8.0.0.Final
>            Reporter: Bill Burke
>            Assignee: Stuart Douglas
>
> If you define an EJB within WEB-INF/classes it does not inherit the security domain from the WAR file and defaults to "other".  Counter-intuitive, IMO.  Not sure if it is easily fixable though

--
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

From issues at jboss.org  Mon Mar 17 17:06:10 2014
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Mon, 17 Mar 2014 17:06:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (SECURITY-806) SecurityVaultFactory
	caching problems
In-Reply-To: <JIRA.12535199.1395090327030@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12535199.1395090327030@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12535199.1395090327030.22372.1395090370721@jira02.app.mwc.hst.phx2.redhat.com>

Kabir Khan created SECURITY-806:
-----------------------------------

             Summary: SecurityVaultFactory caching problems
                 Key: SECURITY-806
                 URL: https://issues.jboss.org/browse/SECURITY-806
             Project: PicketBox 
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: JBossSX
    Affects Versions: PicketBox_4_0_21.Beta1
            Reporter: Kabir Khan
            Assignee: Anil Saldhana


In WildFly we can define the vault at both the 'core' level, and within the security subsystem. The intent is that the user can specify different vaults in the two places, so say for the core one we go with

{code}
<vault/>
{code}

Now, in the security subsystem I want to use some other vault implementation so I do:
{code}
<vault code="my.custom.Vault"/>
{code}
Assuming the core stuff gets loaded first, that will return the 'default' vault, which gets cached, and which will also be returned for the 'custom' one I want in the security subsystem.


--
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

From issues at jboss.org  Mon Mar 17 17:20:11 2014
From: issues at jboss.org (Dustin Minnich (JIRA))
Date: Mon, 17 Mar 2014 17:20:11 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3033) Better SSO configuration
In-Reply-To: <JIRA.12533478.1393493687000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12533478.1393493687000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12533478.1393493687000.22388.1395091211012@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-3033?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12953661#comment-12953661 ] 

Dustin Minnich commented on WFLY-3033:
--------------------------------------

I want to be able to configure the Secure and HttpOnly attributes for JSESSIONIDSSO cookie. 
                
> Better SSO configuration
> ------------------------
>
>                 Key: WFLY-3033
>                 URL: https://issues.jboss.org/browse/WFLY-3033
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Web (Undertow)
>    Affects Versions: 8.0.0.Final
>            Reporter: Tin Tvrtkovic
>            Assignee: Tomaz Cerar
>            Priority: Critical
>              Labels: single-sign-on, undertow
>             Fix For: 8.0.1.Final
>
>
> When enabling Undertow SSO in standalone.xml, the only option to tweak is the cookie domain.
> My life would be made easier by two changes:
> 1) If the domain is not specified, the SSO cookie should have no domain set. This will make the browser apply the domain from the URL being requested. Currently the cookie domain gets populated with a value from the enclosing XML element.
> 2) There's no way of setting the cookie path, which makes this less useful for services on different URLs. I propose adding a path attribute to the SSO XML element, which would set the cookie path. For example:
> <single-sign-on path="/" />
> Right now my workaround is to use my reverse proxy (Apache) to edit response headers and modify the cookie, removing the domain and adding the path. If anyone else needs the workaround:
> Header edit Set-Cookie "^JSESSIONIDSSO=([^; ]+).+" "JSESSIONIDSSO=$1; path=/"

--
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

From issues at jboss.org  Mon Mar 17 17:28:10 2014
From: issues at jboss.org (Farah Juma (JIRA))
Date: Mon, 17 Mar 2014 17:28:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2897) Including Mojarra
 implementation in WAR file causes
 `com.sun.faces.config.ConfigurationException`
In-Reply-To: <JIRA.12531675.1392069085000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12531675.1392069085000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12531675.1392069085000.22393.1395091690673@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2897?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12953663#comment-12953663 ] 

Farah Juma commented on WFLY-2897:
----------------------------------

For versions of JSF other than JSF 2.2.x, accidentally including a JSF implementation in the WAR file won't cause issues and WildFly's default JSF implementation will be the one that's used. It seems that this error only occurs when accidentally including JSF 2.2.x in the WAR file. WildFly's default JSF implementation will still be the one that's used but the error seems to occur when FaceletTaglibConfigProcessor attempts to process the facelets_jsf_core.taglib.xml file from the JSF JAR in the application's WEB-INF/lib directory:


{code}
2014-03-17 17:05:10,140 FINE  [javax.enterprise.resource.webcontainer.jsf.config] (MSC service thread 1-8) Processing facelet-taglibrary document: 'vfs:/content/sample-1.0-SNAPSHOT.war/WEB-INF/lib/javax.faces-2.2.2.jar/com/sun/faces/metadata/taglib/facelets_jsf_core.taglib.xml'
2014-03-17 17:05:10,141 SEVERE [javax.enterprise.resource.webcontainer.jsf.config] (MSC service thread 1-8) Critical error during deployment: : com.sun.faces.config.ConfigurationException: The tag named passThroughAttribute from namespace http://xmlns.jcp.org/jsf/core has a null handler-class defined
{code}


The above log message does indicate that a JSF implementation has been included in the WAR file (it references 'vfs:/content/sample-1.0-SNAPSHOT.war/WEB-INF/lib/javax.faces-2.2.2.jar/com/sun/faces/metadata/taglib/facelets_jsf_core.taglib.xml'). It doesn't look like there's much that can be done in terms of additional error messages in this case since the JSF subsystem doesn't know that a WAR file includes a JSF implementation unless the WAR_BUNDLES_JSF_IMPL context param is specified.  
                
> Including Mojarra implementation in WAR file causes `com.sun.faces.config.ConfigurationException`
> -------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2897
>                 URL: https://issues.jboss.org/browse/WFLY-2897
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: JSF
>    Affects Versions: 8.0.0.CR1
>            Reporter: Lincoln Baxter III
>            Assignee: Farah Juma
>         Attachments: sample.zip
>
>
> This stack trace was taken from EAP6 or JBoss AS7 - but it also occurs on Wildfly.
> If possible, a nicer exception message (warning the user that they have included an implementation of JSF when,) might be useful. But I don't know the exact dynamics behind this interaction, so not sure what is possible here, or what "should" be the right interaction.
> I just know this was a bit hard to track down until randomly tripping on this in the POM and removing it.
> {code}
> 15:15:37,992 SEVERE [javax.enterprise.resource.webcontainer.jsf.config] (ServerService Thread Pool -- 71) Critical error during deployment: : com.sun.faces.config.ConfigurationException: The tag named passThroughAttribute from namespace http://xmlns.jcp.org/jsf/core has a null handler-class defined
> 	at com.sun.faces.config.processor.FaceletTaglibConfigProcessor.processHandlerClass(FaceletTaglibConfigProcessor.java:415) [jsf-impl-2.1.19-redhat-2.jar:2.1.19-redhat-2]
> 	at com.sun.faces.config.processor.FaceletTaglibConfigProcessor.processTags(FaceletTaglibConfigProcessor.java:371) [jsf-impl-2.1.19-redhat-2.jar:2.1.19-redhat-2]
> 	at com.sun.faces.config.processor.FaceletTaglibConfigProcessor.processTagLibrary(FaceletTaglibConfigProcessor.java:314) [jsf-impl-2.1.19-redhat-2.jar:2.1.19-redhat-2]
> 	at com.sun.faces.config.processor.FaceletTaglibConfigProcessor.process(FaceletTaglibConfigProcessor.java:263) [jsf-impl-2.1.19-redhat-2.jar:2.1.19-redhat-2]
> 	at com.sun.faces.config.ConfigManager.initialize(ConfigManager.java:363) [jsf-impl-2.1.19-redhat-2.jar:2.1.19-redhat-2]
> 	at com.sun.faces.config.ConfigureListener.contextInitialized(ConfigureListener.java:216) [jsf-impl-2.1.19-redhat-2.jar:2.1.19-redhat-2]
> 	at org.apache.catalina.core.StandardContext.contextListenerStart(StandardContext.java:3339) [jbossweb-7.2.2.Final-redhat-1.jar:7.2.2.Final-redhat-1]
> 	at org.apache.catalina.core.StandardContext.start(StandardContext.java:3777) [jbossweb-7.2.2.Final-redhat-1.jar:7.2.2.Final-redhat-1]
> 	at org.jboss.as.web.deployment.WebDeploymentService.doStart(WebDeploymentService.java:156) [jboss-as-web-7.3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14]
> 	at org.jboss.as.web.deployment.WebDeploymentService.access$000(WebDeploymentService.java:60) [jboss-as-web-7.3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14]
> 	at org.jboss.as.web.deployment.WebDeploymentService$1.run(WebDeploymentService.java:93) [jboss-as-web-7.3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14]
> 	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) [rt.jar:1.7.0_21]
> 	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) [rt.jar:1.7.0_21]
> 	at java.util.concurrent.FutureTask.run(FutureTask.java:166) [rt.jar:1.7.0_21]
> 	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)
> {code}

--
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

From issues at jboss.org  Mon Mar 17 17:28:10 2014
From: issues at jboss.org (Farah Juma (JIRA))
Date: Mon, 17 Mar 2014 17:28:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2897) Including Mojarra
 implementation in WAR file causes
 `com.sun.faces.config.ConfigurationException`
In-Reply-To: <JIRA.12531675.1392069085000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12531675.1392069085000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12531675.1392069085000.22396.1395091690795@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2897?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Farah Juma closed WFLY-2897.
----------------------------

    Resolution: Won't Fix

    
> Including Mojarra implementation in WAR file causes `com.sun.faces.config.ConfigurationException`
> -------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2897
>                 URL: https://issues.jboss.org/browse/WFLY-2897
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: JSF
>    Affects Versions: 8.0.0.CR1
>            Reporter: Lincoln Baxter III
>            Assignee: Farah Juma
>         Attachments: sample.zip
>
>
> This stack trace was taken from EAP6 or JBoss AS7 - but it also occurs on Wildfly.
> If possible, a nicer exception message (warning the user that they have included an implementation of JSF when,) might be useful. But I don't know the exact dynamics behind this interaction, so not sure what is possible here, or what "should" be the right interaction.
> I just know this was a bit hard to track down until randomly tripping on this in the POM and removing it.
> {code}
> 15:15:37,992 SEVERE [javax.enterprise.resource.webcontainer.jsf.config] (ServerService Thread Pool -- 71) Critical error during deployment: : com.sun.faces.config.ConfigurationException: The tag named passThroughAttribute from namespace http://xmlns.jcp.org/jsf/core has a null handler-class defined
> 	at com.sun.faces.config.processor.FaceletTaglibConfigProcessor.processHandlerClass(FaceletTaglibConfigProcessor.java:415) [jsf-impl-2.1.19-redhat-2.jar:2.1.19-redhat-2]
> 	at com.sun.faces.config.processor.FaceletTaglibConfigProcessor.processTags(FaceletTaglibConfigProcessor.java:371) [jsf-impl-2.1.19-redhat-2.jar:2.1.19-redhat-2]
> 	at com.sun.faces.config.processor.FaceletTaglibConfigProcessor.processTagLibrary(FaceletTaglibConfigProcessor.java:314) [jsf-impl-2.1.19-redhat-2.jar:2.1.19-redhat-2]
> 	at com.sun.faces.config.processor.FaceletTaglibConfigProcessor.process(FaceletTaglibConfigProcessor.java:263) [jsf-impl-2.1.19-redhat-2.jar:2.1.19-redhat-2]
> 	at com.sun.faces.config.ConfigManager.initialize(ConfigManager.java:363) [jsf-impl-2.1.19-redhat-2.jar:2.1.19-redhat-2]
> 	at com.sun.faces.config.ConfigureListener.contextInitialized(ConfigureListener.java:216) [jsf-impl-2.1.19-redhat-2.jar:2.1.19-redhat-2]
> 	at org.apache.catalina.core.StandardContext.contextListenerStart(StandardContext.java:3339) [jbossweb-7.2.2.Final-redhat-1.jar:7.2.2.Final-redhat-1]
> 	at org.apache.catalina.core.StandardContext.start(StandardContext.java:3777) [jbossweb-7.2.2.Final-redhat-1.jar:7.2.2.Final-redhat-1]
> 	at org.jboss.as.web.deployment.WebDeploymentService.doStart(WebDeploymentService.java:156) [jboss-as-web-7.3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14]
> 	at org.jboss.as.web.deployment.WebDeploymentService.access$000(WebDeploymentService.java:60) [jboss-as-web-7.3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14]
> 	at org.jboss.as.web.deployment.WebDeploymentService$1.run(WebDeploymentService.java:93) [jboss-as-web-7.3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14]
> 	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) [rt.jar:1.7.0_21]
> 	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) [rt.jar:1.7.0_21]
> 	at java.util.concurrent.FutureTask.run(FutureTask.java:166) [rt.jar:1.7.0_21]
> 	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)
> {code}

--
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

From issues at jboss.org  Mon Mar 17 17:42:10 2014
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Mon, 17 Mar 2014 17:42:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-922) <vault> does not have module
	option
In-Reply-To: <JIRA.12482750.1358377991000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12482750.1358377991000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12482750.1358377991000.22407.1395092530776@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-922?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan resolved WFLY-922.
-----------------------------

    Resolution: Duplicate Issue


Replaced by WFLY-3118
                
> <vault> does not have module option
> -----------------------------------
>
>                 Key: WFLY-922
>                 URL: https://issues.jboss.org/browse/WFLY-922
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Security
>            Reporter: James Livingston
>            Assignee: Peter Skopek
>
> The <vault> element in standalone/domain.xml takes a 'code' attribute specifying the class to use as the implementation. It does not let you specify a 'module' option like most similar elements have, and instead always loads the class from the org.picketbox module.
> The <vault> element should take a module option too.

--
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

From issues at jboss.org  Mon Mar 17 17:52:11 2014
From: issues at jboss.org (Lincoln Baxter III (JIRA))
Date: Mon, 17 Mar 2014 17:52:11 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2897) Including Mojarra
 implementation in WAR file causes
 `com.sun.faces.config.ConfigurationException`
In-Reply-To: <JIRA.12531675.1392069085000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12531675.1392069085000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12531675.1392069085000.22440.1395093131332@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2897?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12953670#comment-12953670 ] 

Lincoln Baxter III commented on WFLY-2897:
------------------------------------------

Hmm... couldn't the JSF subsystem tell that the path is coming from a deployment and not from a core module? Just a thought. I never like to suggest using path logic to fix issues like this, but it's just a thought that came to mind. It should be possible to use ClassLoader logic; however, that might be a little bit safer I suppose. This is just an unfortunate problem, but perhaps the easiest solution is to make sure that google can find good information about this error :)
                
> Including Mojarra implementation in WAR file causes `com.sun.faces.config.ConfigurationException`
> -------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2897
>                 URL: https://issues.jboss.org/browse/WFLY-2897
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: JSF
>    Affects Versions: 8.0.0.CR1
>            Reporter: Lincoln Baxter III
>            Assignee: Farah Juma
>         Attachments: sample.zip
>
>
> This stack trace was taken from EAP6 or JBoss AS7 - but it also occurs on Wildfly.
> If possible, a nicer exception message (warning the user that they have included an implementation of JSF when,) might be useful. But I don't know the exact dynamics behind this interaction, so not sure what is possible here, or what "should" be the right interaction.
> I just know this was a bit hard to track down until randomly tripping on this in the POM and removing it.
> {code}
> 15:15:37,992 SEVERE [javax.enterprise.resource.webcontainer.jsf.config] (ServerService Thread Pool -- 71) Critical error during deployment: : com.sun.faces.config.ConfigurationException: The tag named passThroughAttribute from namespace http://xmlns.jcp.org/jsf/core has a null handler-class defined
> 	at com.sun.faces.config.processor.FaceletTaglibConfigProcessor.processHandlerClass(FaceletTaglibConfigProcessor.java:415) [jsf-impl-2.1.19-redhat-2.jar:2.1.19-redhat-2]
> 	at com.sun.faces.config.processor.FaceletTaglibConfigProcessor.processTags(FaceletTaglibConfigProcessor.java:371) [jsf-impl-2.1.19-redhat-2.jar:2.1.19-redhat-2]
> 	at com.sun.faces.config.processor.FaceletTaglibConfigProcessor.processTagLibrary(FaceletTaglibConfigProcessor.java:314) [jsf-impl-2.1.19-redhat-2.jar:2.1.19-redhat-2]
> 	at com.sun.faces.config.processor.FaceletTaglibConfigProcessor.process(FaceletTaglibConfigProcessor.java:263) [jsf-impl-2.1.19-redhat-2.jar:2.1.19-redhat-2]
> 	at com.sun.faces.config.ConfigManager.initialize(ConfigManager.java:363) [jsf-impl-2.1.19-redhat-2.jar:2.1.19-redhat-2]
> 	at com.sun.faces.config.ConfigureListener.contextInitialized(ConfigureListener.java:216) [jsf-impl-2.1.19-redhat-2.jar:2.1.19-redhat-2]
> 	at org.apache.catalina.core.StandardContext.contextListenerStart(StandardContext.java:3339) [jbossweb-7.2.2.Final-redhat-1.jar:7.2.2.Final-redhat-1]
> 	at org.apache.catalina.core.StandardContext.start(StandardContext.java:3777) [jbossweb-7.2.2.Final-redhat-1.jar:7.2.2.Final-redhat-1]
> 	at org.jboss.as.web.deployment.WebDeploymentService.doStart(WebDeploymentService.java:156) [jboss-as-web-7.3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14]
> 	at org.jboss.as.web.deployment.WebDeploymentService.access$000(WebDeploymentService.java:60) [jboss-as-web-7.3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14]
> 	at org.jboss.as.web.deployment.WebDeploymentService$1.run(WebDeploymentService.java:93) [jboss-as-web-7.3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14]
> 	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) [rt.jar:1.7.0_21]
> 	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) [rt.jar:1.7.0_21]
> 	at java.util.concurrent.FutureTask.run(FutureTask.java:166) [rt.jar:1.7.0_21]
> 	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)
> {code}

--
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

From issues at jboss.org  Mon Mar 17 17:52:11 2014
From: issues at jboss.org (Lincoln Baxter III (JIRA))
Date: Mon, 17 Mar 2014 17:52:11 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2897) Including Mojarra
 implementation in WAR file causes
 `com.sun.faces.config.ConfigurationException`
In-Reply-To: <JIRA.12531675.1392069085000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12531675.1392069085000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12531675.1392069085000.22444.1395093131530@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2897?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12953671#comment-12953671 ] 

Lincoln Baxter III commented on WFLY-2897:
------------------------------------------

Hmm... couldn't the JSF subsystem tell that the path is coming from a
deployment and not from a core module? Just a thought. I never like to
suggest using path logic to fix issues like this, but it's just a thought
that came to mind. It should be possible to use ClassLoader logic; however,
that might be a little bit safer I suppose. This is just an unfortunate
problem, but perhaps the easiest solution is to make sure that google can
find good information about this error :)






-- 
Lincoln Baxter, III
http://ocpsoft.org
"Simpler is better."

                
> Including Mojarra implementation in WAR file causes `com.sun.faces.config.ConfigurationException`
> -------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2897
>                 URL: https://issues.jboss.org/browse/WFLY-2897
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: JSF
>    Affects Versions: 8.0.0.CR1
>            Reporter: Lincoln Baxter III
>            Assignee: Farah Juma
>         Attachments: sample.zip
>
>
> This stack trace was taken from EAP6 or JBoss AS7 - but it also occurs on Wildfly.
> If possible, a nicer exception message (warning the user that they have included an implementation of JSF when,) might be useful. But I don't know the exact dynamics behind this interaction, so not sure what is possible here, or what "should" be the right interaction.
> I just know this was a bit hard to track down until randomly tripping on this in the POM and removing it.
> {code}
> 15:15:37,992 SEVERE [javax.enterprise.resource.webcontainer.jsf.config] (ServerService Thread Pool -- 71) Critical error during deployment: : com.sun.faces.config.ConfigurationException: The tag named passThroughAttribute from namespace http://xmlns.jcp.org/jsf/core has a null handler-class defined
> 	at com.sun.faces.config.processor.FaceletTaglibConfigProcessor.processHandlerClass(FaceletTaglibConfigProcessor.java:415) [jsf-impl-2.1.19-redhat-2.jar:2.1.19-redhat-2]
> 	at com.sun.faces.config.processor.FaceletTaglibConfigProcessor.processTags(FaceletTaglibConfigProcessor.java:371) [jsf-impl-2.1.19-redhat-2.jar:2.1.19-redhat-2]
> 	at com.sun.faces.config.processor.FaceletTaglibConfigProcessor.processTagLibrary(FaceletTaglibConfigProcessor.java:314) [jsf-impl-2.1.19-redhat-2.jar:2.1.19-redhat-2]
> 	at com.sun.faces.config.processor.FaceletTaglibConfigProcessor.process(FaceletTaglibConfigProcessor.java:263) [jsf-impl-2.1.19-redhat-2.jar:2.1.19-redhat-2]
> 	at com.sun.faces.config.ConfigManager.initialize(ConfigManager.java:363) [jsf-impl-2.1.19-redhat-2.jar:2.1.19-redhat-2]
> 	at com.sun.faces.config.ConfigureListener.contextInitialized(ConfigureListener.java:216) [jsf-impl-2.1.19-redhat-2.jar:2.1.19-redhat-2]
> 	at org.apache.catalina.core.StandardContext.contextListenerStart(StandardContext.java:3339) [jbossweb-7.2.2.Final-redhat-1.jar:7.2.2.Final-redhat-1]
> 	at org.apache.catalina.core.StandardContext.start(StandardContext.java:3777) [jbossweb-7.2.2.Final-redhat-1.jar:7.2.2.Final-redhat-1]
> 	at org.jboss.as.web.deployment.WebDeploymentService.doStart(WebDeploymentService.java:156) [jboss-as-web-7.3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14]
> 	at org.jboss.as.web.deployment.WebDeploymentService.access$000(WebDeploymentService.java:60) [jboss-as-web-7.3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14]
> 	at org.jboss.as.web.deployment.WebDeploymentService$1.run(WebDeploymentService.java:93) [jboss-as-web-7.3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14]
> 	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) [rt.jar:1.7.0_21]
> 	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) [rt.jar:1.7.0_21]
> 	at java.util.concurrent.FutureTask.run(FutureTask.java:166) [rt.jar:1.7.0_21]
> 	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)
> {code}

--
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

From issues at jboss.org  Mon Mar 17 18:22:10 2014
From: issues at jboss.org (John L (JIRA))
Date: Mon, 17 Mar 2014 18:22:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBJCA-1156) encrypted datasource
 security , big performence hit.
In-Reply-To: <JIRA.12535189.1395080950000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12535189.1395080950000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12535189.1395080950000.22459.1395094930776@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JBJCA-1156?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12953674#comment-12953674 ] 

John L commented on JBJCA-1156:
-------------------------------

A complete pool definition we are using:
<datasource jta="false" jndi-name="java:/SomeDS"
	pool-name="SomeDS" enabled="true" use-java-context="true" xmlns="urn:jboss:domain:datasources:1.1">
	<connection-url>jdbc:jtds:sqlserver://localhost:1433/Some
	</connection-url>
	<driver>jtds</driver>
	<new-connection-sql>select 1</new-connection-sql>	
	<transaction-isolation>TRANSACTION_READ_COMMITTED</transaction-isolation>
	<pool>
		<min-pool-size>1</min-pool-size>
		<max-pool-size>100</max-pool-size>
		<prefill>false</prefill>
		<use-strict-min>false</use-strict-min>
	</pool>
	<security>
		<security-domain>some-encrypted-ds</security-domain>
	</security>
</datasource>

<security-domain name="some-encrypted-ds" cache-type="default">
	    <authentication>
	        <login-module code="org.picketbox.datasource.security.SecureIdentityLoginModule" flag="required">
	            <module-option name="username" value="some"/>
	            <module-option name="password" value="34959585858585"/>
	        </login-module>
	    </authentication>
</security-domain>

Every connection retrieved from datasource via jndi lookup from pool
decrypts the password using blowfish even though the connection is already connected to db.
The blowfish decrypts adds up to a large performance hit.

                
> encrypted datasource security , big performence hit.
> ----------------------------------------------------
>
>                 Key: JBJCA-1156
>                 URL: https://issues.jboss.org/browse/JBJCA-1156
>             Project: IronJacamar
>          Issue Type: Bug
>    Affects Versions: 1.0.12.Final
>         Environment: using jboss 7.1.1 or jboss 7.1.3
>            Reporter: John L
>            Assignee: Jesper Pedersen
>
> We setup our jboss7.1.3 to use encrypted datasource passwords:
>    <datasources>
>                 <datasource jndi-name="java:/SomDS" pool-name="SomeDS" enabled="true" use-java-context="true">
> .....
>                     <security>
>                         <security-domain>some-encrypted-ds</security-domain>
>                     </security>
>                 </datasource>
>  
> ...
>             	<security-domain name="some-encrypted-ds" cache-type="default">
>                 	<authentication>
>                     	<login-module code="org.picketbox.datasource.security.SecureIdentityLoginModule" flag="required">
>                         	<module-option name="username" value="some"/>
>                         	<module-option name="password" value="-......."/>
>                     	</login-module>
>                 	</authentication>
>             	</security-domain>
> By using this our system took a 30% performance hit.
> Some transactions might call getConnection 50 times.
> It seems from looking at code that even if a connection already exists in the pool the password is
> decrypted on every call to get a connection from the datasource.
> Seems like it should only decrypt when a new connection is created to the database.
> Moving back to unencrypted passwords solves the performance problem.
> That is using:
> <security xmlns="urn:jboss:domain:datasources:1.1">
>                     <user-name>xxx</user-name>
>                     <password>yyy</password>
>                 </security>

--
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

From issues at jboss.org  Mon Mar 17 18:48:10 2014
From: issues at jboss.org (Farah Juma (JIRA))
Date: Mon, 17 Mar 2014 18:48:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2897) Including Mojarra
 implementation in WAR file causes
 `com.sun.faces.config.ConfigurationException`
In-Reply-To: <JIRA.12531675.1392069085000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12531675.1392069085000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12531675.1392069085000.22464.1395096490595@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2897?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12953675#comment-12953675 ] 

Farah Juma commented on WFLY-2897:
----------------------------------

I've created this post in the JSF forum to help anyone else who happens to come across this issue:

https://community.jboss.org/thread/238150
                
> Including Mojarra implementation in WAR file causes `com.sun.faces.config.ConfigurationException`
> -------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2897
>                 URL: https://issues.jboss.org/browse/WFLY-2897
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: JSF
>    Affects Versions: 8.0.0.CR1
>            Reporter: Lincoln Baxter III
>            Assignee: Farah Juma
>         Attachments: sample.zip
>
>
> This stack trace was taken from EAP6 or JBoss AS7 - but it also occurs on Wildfly.
> If possible, a nicer exception message (warning the user that they have included an implementation of JSF when,) might be useful. But I don't know the exact dynamics behind this interaction, so not sure what is possible here, or what "should" be the right interaction.
> I just know this was a bit hard to track down until randomly tripping on this in the POM and removing it.
> {code}
> 15:15:37,992 SEVERE [javax.enterprise.resource.webcontainer.jsf.config] (ServerService Thread Pool -- 71) Critical error during deployment: : com.sun.faces.config.ConfigurationException: The tag named passThroughAttribute from namespace http://xmlns.jcp.org/jsf/core has a null handler-class defined
> 	at com.sun.faces.config.processor.FaceletTaglibConfigProcessor.processHandlerClass(FaceletTaglibConfigProcessor.java:415) [jsf-impl-2.1.19-redhat-2.jar:2.1.19-redhat-2]
> 	at com.sun.faces.config.processor.FaceletTaglibConfigProcessor.processTags(FaceletTaglibConfigProcessor.java:371) [jsf-impl-2.1.19-redhat-2.jar:2.1.19-redhat-2]
> 	at com.sun.faces.config.processor.FaceletTaglibConfigProcessor.processTagLibrary(FaceletTaglibConfigProcessor.java:314) [jsf-impl-2.1.19-redhat-2.jar:2.1.19-redhat-2]
> 	at com.sun.faces.config.processor.FaceletTaglibConfigProcessor.process(FaceletTaglibConfigProcessor.java:263) [jsf-impl-2.1.19-redhat-2.jar:2.1.19-redhat-2]
> 	at com.sun.faces.config.ConfigManager.initialize(ConfigManager.java:363) [jsf-impl-2.1.19-redhat-2.jar:2.1.19-redhat-2]
> 	at com.sun.faces.config.ConfigureListener.contextInitialized(ConfigureListener.java:216) [jsf-impl-2.1.19-redhat-2.jar:2.1.19-redhat-2]
> 	at org.apache.catalina.core.StandardContext.contextListenerStart(StandardContext.java:3339) [jbossweb-7.2.2.Final-redhat-1.jar:7.2.2.Final-redhat-1]
> 	at org.apache.catalina.core.StandardContext.start(StandardContext.java:3777) [jbossweb-7.2.2.Final-redhat-1.jar:7.2.2.Final-redhat-1]
> 	at org.jboss.as.web.deployment.WebDeploymentService.doStart(WebDeploymentService.java:156) [jboss-as-web-7.3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14]
> 	at org.jboss.as.web.deployment.WebDeploymentService.access$000(WebDeploymentService.java:60) [jboss-as-web-7.3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14]
> 	at org.jboss.as.web.deployment.WebDeploymentService$1.run(WebDeploymentService.java:93) [jboss-as-web-7.3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14]
> 	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) [rt.jar:1.7.0_21]
> 	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) [rt.jar:1.7.0_21]
> 	at java.util.concurrent.FutureTask.run(FutureTask.java:166) [rt.jar:1.7.0_21]
> 	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)
> {code}

--
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

From issues at jboss.org  Mon Mar 17 19:40:10 2014
From: issues at jboss.org (James Perkins (JIRA))
Date: Mon, 17 Mar 2014 19:40:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2958) Batch deployments don't work
 without a beans.xml
In-Reply-To: <JIRA.12532549.1392742088000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12532549.1392742088000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12532549.1392742088000.22506.1395099610710@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2958?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

James Perkins closed WFLY-2958.
-------------------------------

    Fix Version/s:     (was: 8.0.1.Final)
       Resolution: Rejected


Everything seems to be working as it should be.
                
> Batch deployments don't work without a beans.xml
> ------------------------------------------------
>
>                 Key: WFLY-2958
>                 URL: https://issues.jboss.org/browse/WFLY-2958
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Batch, CDI / Weld
>    Affects Versions: 8.0.0.Final
>            Reporter: James Perkins
>            Assignee: James Perkins
>
> If a deployment does not have a {{beans.xml}} file, which is no longer required, batch deployments fail due to a missing bean manager service.

--
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

From issues at jboss.org  Mon Mar 17 20:34:10 2014
From: issues at jboss.org (Shelly McGowan (JIRA))
Date: Mon, 17 Mar 2014 20:34:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3123) Update Java EE APIs
In-Reply-To: <JIRA.12535159.1395066619000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12535159.1395066619000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12535159.1395066619000.22524.1395102850726@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-3123?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Shelly McGowan updated WFLY-3123:
---------------------------------

    Git Pull Request: https://github.com/wildfly/wildfly/pull/6034

    
> Update Java EE APIs
> -------------------
>
>                 Key: WFLY-3123
>                 URL: https://issues.jboss.org/browse/WFLY-3123
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: EE
>            Reporter: Shelly McGowan
>            Assignee: Shelly McGowan
>             Fix For: 8.0.1.Final
>
>
> There were a few bug fix releases of the JBoss Java EE API projects to include in WildFly.

--
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

From issues at jboss.org  Mon Mar 17 20:38:10 2014
From: issues at jboss.org (Jeff Zhang (JIRA))
Date: Mon, 17 Mar 2014 20:38:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2655) Show warning for JDBC drivers
 as modules with no driver
In-Reply-To: <JIRA.12527980.1387160517000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12527980.1387160517000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12527980.1387160517000.22526.1395103090948@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2655?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jeff Zhang resolved WFLY-2655.
------------------------------

    Fix Version/s: 8.0.1.Final
       Resolution: Done

    
> Show warning for JDBC drivers as modules with no driver
> -------------------------------------------------------
>
>                 Key: WFLY-2655
>                 URL: https://issues.jboss.org/browse/WFLY-2655
>             Project: WildFly
>          Issue Type: Enhancement
>      Security Level: Public(Everyone can see) 
>          Components: JCA
>    Affects Versions: 8.0.0.Beta1
>            Reporter: James Livingston
>            Assignee: Jeff Zhang
>             Fix For: 8.0.1.Final
>
>
> If a <driver> if configured with no <driver-class>, it will attempt to locate the driver(s) via the service loader which should find all JDBC4-compliant drivers.
> When you install a non JDBC4-complicant driver as a module and no <driver-class>, the driver will not be installed. That is expected but emitting a warning that no-drivers could be found in the module would be useful to help users troubleshoot the problem.

--
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

From issues at jboss.org  Mon Mar 17 22:10:11 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 17 Mar 2014 22:10:11 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1547) deploy directories not
	cleaned up
In-Reply-To: <JIRA.12479851.1353935247000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12479851.1353935247000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12479851.1353935247000.22567.1395108611320@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1547?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12953687#comment-12953687 ] 

RH Bugzilla Integration commented on WFLY-1547:
-----------------------------------------------

Paul Gier <pgier at redhat.com> changed the Status of [bug 901210|https://bugzilla.redhat.com/show_bug.cgi?id=901210] from MODIFIED to ON_QA
                
> deploy directories not cleaned up
> ---------------------------------
>
>                 Key: WFLY-1547
>                 URL: https://issues.jboss.org/browse/WFLY-1547
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 8.0.0.Alpha1
>            Reporter: Shaun Appleton
>            Assignee: jaikiran pai
>             Fix For: 8.0.0.Beta1
>
>         Attachments: deployment_with_hack_no_hook.txt
>
>
> JBoss EAP 6.0.0 (and 6.0.1.ER3) doesn't clean up it's tmp/vfs directories.
> The following reproduces this -
> i) ensure run.conf has the -Xrs set
> ii) ensure deployments has a deployable .ear in it
> iii) ./run standalone.sh and allow the deployments to deploy
> iv) stop the EAP process ie kill <process_id>
> v) observe content tmp/vfs
> (The -Xrs parameter is used to "-Xrs" to prevent possible interference when JVM is running as a service and receives CTRL_LOGOFF_EVENT or SIGHUP)
> This will eventually cause problems with lack of disk space.
> Note if the -Xrs parameter content is removed but the tmp/vfs dirs stills exist. This could potentially cause inode problems.
> It would be better if there were any additional code so the temp dirs are cleaned up on start up. That would resolve both the -Xrs problem and the excessive dir creation.

--
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

From issues at jboss.org  Mon Mar 17 22:10:11 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 17 Mar 2014 22:10:11 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3106) Infinispan cache statistics
 cannot be enabled/disabled independently of the cache manager statistics
In-Reply-To: <JIRA.12534838.1394655920000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534838.1394655920000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534838.1394655920000.22570.1395108611509@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-3106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12953688#comment-12953688 ] 

RH Bugzilla Integration commented on WFLY-3106:
-----------------------------------------------

Paul Gier <pgier at redhat.com> changed the Status of [bug 1025023|https://bugzilla.redhat.com/show_bug.cgi?id=1025023] from MODIFIED to ON_QA
                
> Infinispan cache statistics cannot be enabled/disabled independently of the cache manager statistics    
> --------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-3106
>                 URL: https://issues.jboss.org/browse/WFLY-3106
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Clustering
>    Affects Versions: 8.0.0.Final
>            Reporter: Richard Achmatowicz
>            Assignee: Richard Achmatowicz
>             Fix For: 8.0.1.Final
>
>
> The Infinispan subsystem allows enabling and disabling the collection of statistics for cache managers and caches via the "statistics-enabled" management API attribute.
> It is possible to set statistics-enabled attributes independently for cache managers and caches in the management API, but when checking the Infinispan MBeans, we see that statistics are either enabled for cache managers and their caches, or disabled for cache managers and caches.  

--
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

From issues at jboss.org  Mon Mar 17 22:10:11 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 17 Mar 2014 22:10:11 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2415) Add configuration option to
 enable/disable Infinispan statistics
In-Reply-To: <JIRA.12509131.1383157408000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12509131.1383157408000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12509131.1383157408000.22579.1395108611945@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2415?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12953689#comment-12953689 ] 

RH Bugzilla Integration commented on WFLY-2415:
-----------------------------------------------

Paul Gier <pgier at redhat.com> changed the Status of [bug 1025023|https://bugzilla.redhat.com/show_bug.cgi?id=1025023] from MODIFIED to ON_QA
                
> Add configuration option to enable/disable Infinispan statistics
> ----------------------------------------------------------------
>
>                 Key: WFLY-2415
>                 URL: https://issues.jboss.org/browse/WFLY-2415
>             Project: WildFly
>          Issue Type: Enhancement
>      Security Level: Public(Everyone can see) 
>          Components: Clustering
>            Reporter: Scott Marlow
>            Assignee: Paul Ferraro
>             Fix For: 8.0.0.CR1
>
>
> When the Infinispan MBean is enabled, Infinispan statistics are enabled by default.  Could we allow Infinispan statistics to be enabled/disabled via a WF configuration setting?

--
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

From issues at jboss.org  Mon Mar 17 22:10:12 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 17 Mar 2014 22:10:12 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3112) One can't change history and
 decay with DynamicLoadBalanceFactorProvider
In-Reply-To: <JIRA.12534709.1394560666000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534709.1394560666000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534709.1394560666000.22583.1395108612131@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-3112?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12953691#comment-12953691 ] 

RH Bugzilla Integration commented on WFLY-3112:
-----------------------------------------------

Paul Gier <pgier at redhat.com> changed the Status of [bug 1075215|https://bugzilla.redhat.com/show_bug.cgi?id=1075215] from MODIFIED to ON_QA
                
> One can't change history and decay with DynamicLoadBalanceFactorProvider
> ------------------------------------------------------------------------
>
>                 Key: WFLY-3112
>                 URL: https://issues.jboss.org/browse/WFLY-3112
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Clustering
>    Affects Versions: 8.0.0.Final
>            Reporter: Michal Babacek
>            Assignee: Radoslav Husar
>            Priority: Critical
>             Fix For: 8.0.1.Final
>
>         Attachments: redacted_log
>
>
> I'm under an ugly impression that one can't actually change {{history}} and {{decay}} attributes of *DynamicLoadBalanceFactorProvider*.
> I was trying to figure out why the new test suite of CustomLoadMetric tests does not pass. In order to get load figures without history and decay manipulation, I set the following:
> {code}
> <subsystem xmlns="urn:jboss:domain:modcluster:1.2">
>     <mod-cluster-config advertise-socket="modcluster" connector="ajp">
>     <dynamic-load-provider history="0">
>         <custom-load-metric class="biz.karms.modcluster.CustomLoadMetric" weight="1">
>             <property name="capacity" value="1000"/>
>             <property name="loadfile" value="/tmp/mod_cluster-eapx/loadfileA"/>
>             <property name="parseexpression" value="^LOAD: ([0-9]*)$"/>
>         </custom-load-metric>
>     </dynamic-load-provider>
>     </mod-cluster-config>
> </subsystem>
> {code}
> The aforementioned {{history=0}} effectively means that there is just 1 "slot" for a one historical value on which decay function should work.
> If you take a look at the code in [DynamicLoadBalanceFactorProvider|https://github.com/modcluster/mod_cluster/blob/master/core/src/main/java/org/jboss/modcluster/load/impl/DynamicLoadBalanceFactorProvider.java#L54] constructor, it is apparent
> that the size of the List that later serves for storing the historical values is set sooner than the actual [setHistory(int history)|https://github.com/modcluster/mod_cluster/blob/master/core/src/main/java/org/jboss/modcluster/load/impl/DynamicLoadBalanceFactorProvider.java#L177] method is called.
> The actual size of that List collection wouldn't do any harm by itself but it is being used in the aforementioned class with {{.size()}} to control cycles.
> The same IMHO holds for the decay attribute.
> Anyhow, I put some additional logging to the [DynamicLoadBalanceFactorProvider.java|https://github.com/modcluster/mod_cluster/blob/master/core/src/main/java/org/jboss/modcluster/load/impl/DynamicLoadBalanceFactorProvider.java]:
> {code}
> // Historical value contribute an exponentially decayed factor
> for (int i = 0; i < queue.size(); ++i) {
>     double decay = 1 / Math.pow(decayFactor, i);
>     totalDecay += decay;
>     this.log.info("KTAG: totalLoad:"+totalLoad+", with decay:"+(totalLoad+queue.get(i).doubleValue() * decay));
>     totalLoad += queue.get(i).doubleValue() * decay;
> }
> {code}
> and
> {code}
> try {
>     // Normalize load with respect to capacity
>     this.recordLoad(metricLoadHistory, metric.getLoad(engine) / metric.getCapacity());
>     this.log.info("KTAG metricLoadHistory:"+metricLoadHistory.toString());
>     totalWeight += weight;
>     totalWeightedLoad += this.average(metricLoadHistory) * weight;
> } catch (Exception e) {
>     this.log.error(e.getLocalizedMessage(), e);
> }
> {code}
> with the following being the output: [^redacted_log].
> So, despite having {{history=0}}, which should force the system to keep just 1, the current value, {{metricLoadHistory}} grew from
> {noformat}
> KTAG metricLoadHistory:[0.8]
> {noformat}
> to
> {noformat}
> KTAG metricLoadHistory:[0.9, 0.9, 0.9, 0.9, 0.9, 0.9, 0.9, 0.9, 0.9, 0.8]
> {noformat}
> which is exactly [9|https://github.com/modcluster/mod_cluster/blob/master/core/src/main/java/org/jboss/modcluster/load/impl/DynamicLoadBalanceFactorProvider.java#L50] + [1|https://github.com/modcluster/mod_cluster/blob/master/core/src/main/java/org/jboss/modcluster/load/impl/DynamicLoadBalanceFactorProvider.java#L54] in size :-)
> WDYT?

--
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

From issues at jboss.org  Tue Mar 18 03:56:10 2014
From: issues at jboss.org (Jay Kumar SenSharma (JIRA))
Date: Tue, 18 Mar 2014 03:56:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2376) DataSource properties are not
 persisting via CLI
In-Reply-To: <JIRA.12508706.1382624115000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508706.1382624115000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508706.1382624115000.22692.1395129370593@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2376?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jay Kumar SenSharma reopened WFLY-2376:
---------------------------------------



The Pull request [1] does not seems to be fixing the issue.

With the above pull request build still we see that if the class_name is not provided for stale_connection, reauth_plugin and exception_sorter ....Still WildFly creates the DataSource Silently without throwing any error / exception.
The DataSource configuration mentioned inside the "standalone.xml" still has missing exception-sorter-properties, reauth-plugin-properties etc.

Ideally WildFly should have thrown some Error or notified the user that the configuration provided is incorrect hence the datasource can not be processed.

                
> DataSource properties are not persisting via CLI
> ------------------------------------------------
>
>                 Key: WFLY-2376
>                 URL: https://issues.jboss.org/browse/WFLY-2376
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JCA
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Jay Kumar SenSharma
>            Assignee: Stefano Maestri
>
> - The CLI command show that there are some valid configuration properties available like following while configuring DataSources, However those properties never get persisted in the DataSource configuration:
> {quote}
>  ./jboss-cli.sh  --user=admin --password=admin at 123 -c --controller=remote://localhost:9999  command="/subsystem=datasources/data-source=testpool:read-resource-description(recursive=true)" 
>             "stale-connection-checker-properties" => {
>                 "type" => OBJECT,
>                 "description" => "The stale connection checker properties",
>                 "expressions-allowed" => true,
>                 "nillable" => true,
>                 "value-type" => STRING,
>                 "access-type" => "read-write",
>                 "storage" => "configuration",
>                 "restart-required" => "no-services"
>             },
>             "reauth-plugin-properties" => {
>                 "type" => OBJECT,
>                 "description" => "The properties for the reauthentication plugin",
>                 "expressions-allowed" => true,
>                 "nillable" => true,
>                 "value-type" => STRING,
>                 "access-type" => "read-write",
>                 "storage" => "configuration",
>                 "restart-required" => "no-services"
>             },
>             "exception-sorter-properties" => {
>                 "type" => OBJECT,
>                 "description" => "The exception sorter properties",
>                 "expressions-allowed" => true,
>                 "nillable" => true,
>                 "value-type" => STRING,
>                 "access-type" => "read-write",
>                 "storage" => "configuration",
>                 "restart-required" => "no-services"
>             },
> {quote}
> - Following command never complains about any issue and the following command executed without any issue but the above properties are not persisted in the DataSource.
>  ./jboss-cli.sh --user=admin --password=admin at 123 -c --controller=remote://localhost:9999 command="/subsystem=datasources/data-source=testpool:add(jndi-name=\"java:jboss/TestDS\",driver-name=\"ojdbc6.jar\",connection-url=\"jdbc:oracle:thin:@DBHostName:1521:DBName\",user-name=\"user\",password=\"pass\",new-connection-sql=\"select 1 from dual\", check-valid-connection-sql=\"select 2 from dual\",valid-connection-checker-class-name=\"org.jboss.resource.adapter.jdbc.vendor.OracleValidConnectionChecker\",exception-sorter-properties={\"prop1\"=>\"value1\"},reauth-plugin-properties={\"reauthProp1\"=>\"reauthValue1\"},exception-sorter-properties={\"exceptionSorterProp1\"=>\"exceptionSorterValue1\"})"
> - The Generated DataSource looks like following:
> ${quote}
>                 <datasource jndi-name="java:jboss/TestDS" pool-name="testpool" enabled="true">
>                     <connection-url>jdbc:oracle:thin:@DBHostName:1521:DBName</connection-url>
>                     <driver>ojdbc6.jar</driver>
>                     <new-connection-sql>select 1 from dual</new-connection-sql>
>                     <security>
>                         <user-name>user</user-name>
>                         <password>pass</password>
>                     </security>
>                     <validation>
>                         <valid-connection-checker class-name="org.jboss.resource.adapter.jdbc.vendor.OracleValidConnectionChecker"/>
>                         <check-valid-connection-sql>select 2 from dual</check-valid-connection-sql>
>                     </validation>
>                 </datasource>
> ${quote}

--
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

From issues at jboss.org  Tue Mar 18 04:20:10 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 18 Mar 2014 04:20:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-985) jboss-dmr APIs are unable to
 parse swedish characters
In-Reply-To: <JIRA.12488901.1365532124000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12488901.1365532124000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12488901.1365532124000.22733.1395130810625@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-985?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12953720#comment-12953720 ] 

RH Bugzilla Integration commented on WFLY-985:
----------------------------------------------

Jay SenSharma <jsenshar at redhat.com> changed the Status of [bug 950164|https://bugzilla.redhat.com/show_bug.cgi?id=950164] from NEW to CLOSED
                
> jboss-dmr APIs are unable to parse swedish characters
> -----------------------------------------------------
>
>                 Key: WFLY-985
>                 URL: https://issues.jboss.org/browse/WFLY-985
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: CLI
>         Environment: All
>            Reporter: Jay Kumar SenSharma
>            Assignee: Alexey Loubyansky
>              Labels: cli, dmr
>             Fix For: 8.0.0.Alpha2
>
>
> JBossAS 7.2 dmr-api's are unable to parse swedish characters .
> Example:
> ========= Run the following CLI command which will fail:
> [standalone at localhost:9999 /] /core-service=management/ldap-connection=ldap_connection/:add(search-credential=jboss at 123,url=ldap://xx.xx.xxx.xx:389,search-dn="ou=\\u00E5\\u00E5\\u00E5,dc=example,dc=com")
> Ideally it should have generated the following configuration inside the server profile (standalone.xml)
>         <outbound-connections>
>             <ldap name="ldap_connection" url="ldap://xx.xx.xxx.xx:389" search-dn="ou=???,dc=example,dc=com" search-credential="jboss at 123"/>
>         </outbound-connections>

--
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


From issues at jboss.org  Tue Mar 18 05:46:10 2014
From: issues at jboss.org (Masafumi Miura (JIRA))
Date: Tue, 18 Mar 2014 05:46:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBMESSAGING-1950) JBoss start-up hangs
 infrequently at
 org.jboss.jms.server.endpoint.ServerConnectionFactoryEndpoint#createConnectionDelegateInternal
In-Reply-To: <JIRA.12535220.1395135962781@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12535220.1395135962781@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12535220.1395135962781.22877.1395135970849@jira02.app.mwc.hst.phx2.redhat.com>

Masafumi Miura created JBMESSAGING-1950:
-------------------------------------------

             Summary: JBoss start-up hangs infrequently at org.jboss.jms.server.endpoint.ServerConnectionFactoryEndpoint#createConnectionDelegateInternal 
                 Key: JBMESSAGING-1950
                 URL: https://issues.jboss.org/browse/JBMESSAGING-1950
             Project: JBoss Messaging
          Issue Type: Bug
    Affects Versions: 1.4.8.SP9
            Reporter: Masafumi Miura


JBoss start-up hangs infrequently at org.jboss.jms.server.endpoint.ServerConnectionFactoryEndpoint#createConnectionDelegateInternal when calling createTopicSession or createQueueSession in load-on-startup servlet.



--
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

From issues at jboss.org  Tue Mar 18 05:48:10 2014
From: issues at jboss.org (Masafumi Miura (JIRA))
Date: Tue, 18 Mar 2014 05:48:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBMESSAGING-1950) JBoss start-up hangs
 infrequently at
 org.jboss.jms.server.endpoint.ServerConnectionFactoryEndpoint#createConnectionDelegateInternal
In-Reply-To: <JIRA.12535220.1395135962000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12535220.1395135962000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12535220.1395135962000.22883.1395136090690@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBMESSAGING-1950?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Masafumi Miura updated JBMESSAGING-1950:
----------------------------------------

    Attachment: jstack.out


Thread Dumps
                
> JBoss start-up hangs infrequently at org.jboss.jms.server.endpoint.ServerConnectionFactoryEndpoint#createConnectionDelegateInternal 
> ------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1950
>                 URL: https://issues.jboss.org/browse/JBMESSAGING-1950
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 1.4.8.SP9
>            Reporter: Masafumi Miura
>         Attachments: jstack.out
>
>
> JBoss start-up hangs infrequently at org.jboss.jms.server.endpoint.ServerConnectionFactoryEndpoint#createConnectionDelegateInternal when calling createTopicSession or createQueueSession in load-on-startup servlet.

--
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

From issues at jboss.org  Tue Mar 18 05:50:10 2014
From: issues at jboss.org (Masafumi Miura (JIRA))
Date: Tue, 18 Mar 2014 05:50:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBMESSAGING-1950) JBoss start-up hangs
 infrequently at
 org.jboss.jms.server.endpoint.ServerConnectionFactoryEndpoint#createConnectionDelegateInternal
In-Reply-To: <JIRA.12535220.1395135962000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12535220.1395135962000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12535220.1395135962000.22890.1395136210790@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBMESSAGING-1950?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Masafumi Miura updated JBMESSAGING-1950:
----------------------------------------

    Attachment: reproducer.tar.gz

    
> JBoss start-up hangs infrequently at org.jboss.jms.server.endpoint.ServerConnectionFactoryEndpoint#createConnectionDelegateInternal 
> ------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1950
>                 URL: https://issues.jboss.org/browse/JBMESSAGING-1950
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 1.4.8.SP9
>            Reporter: Masafumi Miura
>         Attachments: jstack.out, reproducer.tar.gz
>
>
> JBoss start-up hangs infrequently at org.jboss.jms.server.endpoint.ServerConnectionFactoryEndpoint#createConnectionDelegateInternal when calling createTopicSession or createQueueSession in load-on-startup servlet.

--
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

From issues at jboss.org  Tue Mar 18 05:50:11 2014
From: issues at jboss.org (Masafumi Miura (JIRA))
Date: Tue, 18 Mar 2014 05:50:11 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBMESSAGING-1950) JBoss start-up hangs
 infrequently at
 org.jboss.jms.server.endpoint.ServerConnectionFactoryEndpoint#createConnectionDelegateInternal
In-Reply-To: <JIRA.12535220.1395135962000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12535220.1395135962000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12535220.1395135962000.22895.1395136211011@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBMESSAGING-1950?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Masafumi Miura updated JBMESSAGING-1950:
----------------------------------------

    Comment: was deleted

(was: Thread Dumps)

    
> JBoss start-up hangs infrequently at org.jboss.jms.server.endpoint.ServerConnectionFactoryEndpoint#createConnectionDelegateInternal 
> ------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1950
>                 URL: https://issues.jboss.org/browse/JBMESSAGING-1950
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 1.4.8.SP9
>            Reporter: Masafumi Miura
>         Attachments: jstack.out, reproducer.tar.gz
>
>
> JBoss start-up hangs infrequently at org.jboss.jms.server.endpoint.ServerConnectionFactoryEndpoint#createConnectionDelegateInternal when calling createTopicSession or createQueueSession in load-on-startup servlet.

--
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

From issues at jboss.org  Tue Mar 18 05:52:10 2014
From: issues at jboss.org (Masafumi Miura (JIRA))
Date: Tue, 18 Mar 2014 05:52:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBMESSAGING-1950) JBoss start-up hangs
 infrequently at
 org.jboss.jms.server.endpoint.ServerConnectionFactoryEndpoint#createConnectionDelegateInternal
In-Reply-To: <JIRA.12535220.1395135962000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12535220.1395135962000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12535220.1395135962000.22904.1395136330684@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBMESSAGING-1950?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Masafumi Miura updated JBMESSAGING-1950:
----------------------------------------

    Steps to Reproduce: 
1. Deploy example-servlet.war in the attachment.
2. Start EAP 5 default profile.

Then, JBoss start-up hangs infrequently.
           Component/s: Messaging Core

    
> JBoss start-up hangs infrequently at org.jboss.jms.server.endpoint.ServerConnectionFactoryEndpoint#createConnectionDelegateInternal 
> ------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1950
>                 URL: https://issues.jboss.org/browse/JBMESSAGING-1950
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Messaging Core
>    Affects Versions: 1.4.8.SP9
>            Reporter: Masafumi Miura
>         Attachments: jstack.out, reproducer.tar.gz
>
>
> JBoss start-up hangs infrequently at org.jboss.jms.server.endpoint.ServerConnectionFactoryEndpoint#createConnectionDelegateInternal when calling createTopicSession or createQueueSession in load-on-startup servlet.

--
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

From issues at jboss.org  Tue Mar 18 06:04:10 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 18 Mar 2014 06:04:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-417) Turn on Kie-Ci into an OSGI
	Bundle
In-Reply-To: <JIRA.12530385.1390823961000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530385.1390823961000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530385.1390823961000.22942.1395137050686@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/DROOLS-417?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12953755#comment-12953755 ] 

RH Bugzilla Integration commented on DROOLS-417:
------------------------------------------------

Marek Winkler <mwinkler at redhat.com> changed the Status of [bug 1067867|https://bugzilla.redhat.com/show_bug.cgi?id=1067867] from ON_QA to VERIFIED
                
> Turn on Kie-Ci into an OSGI Bundle
> ----------------------------------
>
>                 Key: DROOLS-417
>                 URL: https://issues.jboss.org/browse/DROOLS-417
>             Project: Drools
>          Issue Type: Enhancement
>      Security Level: Public(Everyone can see) 
>            Reporter: Charles Moulliard
>            Assignee: Mark Proctor
>


--
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

From issues at jboss.org  Tue Mar 18 06:50:11 2014
From: issues at jboss.org (Tomaz Cerar (JIRA))
Date: Tue, 18 Mar 2014 06:50:11 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1547) deploy directories not
	cleaned up
In-Reply-To: <JIRA.12479851.1353935247000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12479851.1353935247000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12479851.1353935247000.23055.1395139811413@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-1547?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tomaz Cerar updated WFLY-1547:
------------------------------

    Comment: was deleted

(was: Paul Gier <pgier at redhat.com> changed the Status of [bug 901210|https://bugzilla.redhat.com/show_bug.cgi?id=901210] from MODIFIED to ON_QA)

    
> deploy directories not cleaned up
> ---------------------------------
>
>                 Key: WFLY-1547
>                 URL: https://issues.jboss.org/browse/WFLY-1547
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 8.0.0.Alpha1
>            Reporter: Shaun Appleton
>            Assignee: jaikiran pai
>             Fix For: 8.0.0.Beta1
>
>         Attachments: deployment_with_hack_no_hook.txt
>
>
> JBoss EAP 6.0.0 (and 6.0.1.ER3) doesn't clean up it's tmp/vfs directories.
> The following reproduces this -
> i) ensure run.conf has the -Xrs set
> ii) ensure deployments has a deployable .ear in it
> iii) ./run standalone.sh and allow the deployments to deploy
> iv) stop the EAP process ie kill <process_id>
> v) observe content tmp/vfs
> (The -Xrs parameter is used to "-Xrs" to prevent possible interference when JVM is running as a service and receives CTRL_LOGOFF_EVENT or SIGHUP)
> This will eventually cause problems with lack of disk space.
> Note if the -Xrs parameter content is removed but the tmp/vfs dirs stills exist. This could potentially cause inode problems.
> It would be better if there were any additional code so the temp dirs are cleaned up on start up. That would resolve both the -Xrs problem and the excessive dir creation.

--
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

From issues at jboss.org  Tue Mar 18 06:50:11 2014
From: issues at jboss.org (Tomaz Cerar (JIRA))
Date: Tue, 18 Mar 2014 06:50:11 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1547) deploy directories not
	cleaned up
In-Reply-To: <JIRA.12479851.1353935247000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12479851.1353935247000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12479851.1353935247000.23058.1395139811538@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-1547?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tomaz Cerar updated WFLY-1547:
------------------------------

    Comment: was deleted

(was: dereed at redhat.com changed the Status of [bug 901210|https://bugzilla.redhat.com/show_bug.cgi?id=901210] from CLOSED to ASSIGNED)

    
> deploy directories not cleaned up
> ---------------------------------
>
>                 Key: WFLY-1547
>                 URL: https://issues.jboss.org/browse/WFLY-1547
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 8.0.0.Alpha1
>            Reporter: Shaun Appleton
>            Assignee: jaikiran pai
>             Fix For: 8.0.0.Beta1
>
>         Attachments: deployment_with_hack_no_hook.txt
>
>
> JBoss EAP 6.0.0 (and 6.0.1.ER3) doesn't clean up it's tmp/vfs directories.
> The following reproduces this -
> i) ensure run.conf has the -Xrs set
> ii) ensure deployments has a deployable .ear in it
> iii) ./run standalone.sh and allow the deployments to deploy
> iv) stop the EAP process ie kill <process_id>
> v) observe content tmp/vfs
> (The -Xrs parameter is used to "-Xrs" to prevent possible interference when JVM is running as a service and receives CTRL_LOGOFF_EVENT or SIGHUP)
> This will eventually cause problems with lack of disk space.
> Note if the -Xrs parameter content is removed but the tmp/vfs dirs stills exist. This could potentially cause inode problems.
> It would be better if there were any additional code so the temp dirs are cleaned up on start up. That would resolve both the -Xrs problem and the excessive dir creation.

--
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

From issues at jboss.org  Tue Mar 18 06:52:11 2014
From: issues at jboss.org (Tomaz Cerar (JIRA))
Date: Tue, 18 Mar 2014 06:52:11 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1547) deploy directories not
	cleaned up
In-Reply-To: <JIRA.12479851.1353935247000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12479851.1353935247000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12479851.1353935247000.23074.1395139931117@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-1547?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tomaz Cerar updated WFLY-1547:
------------------------------

    Comment: was deleted

(was: James Livingston <jlivings at redhat.com> changed the Status of [bug 901210|https://bugzilla.redhat.com/show_bug.cgi?id=901210] from ASSIGNED to POST)

    
> deploy directories not cleaned up
> ---------------------------------
>
>                 Key: WFLY-1547
>                 URL: https://issues.jboss.org/browse/WFLY-1547
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 8.0.0.Alpha1
>            Reporter: Shaun Appleton
>            Assignee: jaikiran pai
>             Fix For: 8.0.0.Beta1
>
>         Attachments: deployment_with_hack_no_hook.txt
>
>
> JBoss EAP 6.0.0 (and 6.0.1.ER3) doesn't clean up it's tmp/vfs directories.
> The following reproduces this -
> i) ensure run.conf has the -Xrs set
> ii) ensure deployments has a deployable .ear in it
> iii) ./run standalone.sh and allow the deployments to deploy
> iv) stop the EAP process ie kill <process_id>
> v) observe content tmp/vfs
> (The -Xrs parameter is used to "-Xrs" to prevent possible interference when JVM is running as a service and receives CTRL_LOGOFF_EVENT or SIGHUP)
> This will eventually cause problems with lack of disk space.
> Note if the -Xrs parameter content is removed but the tmp/vfs dirs stills exist. This could potentially cause inode problems.
> It would be better if there were any additional code so the temp dirs are cleaned up on start up. That would resolve both the -Xrs problem and the excessive dir creation.

--
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

From issues at jboss.org  Tue Mar 18 06:52:12 2014
From: issues at jboss.org (Tomaz Cerar (JIRA))
Date: Tue, 18 Mar 2014 06:52:12 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1547) deploy directories not
	cleaned up
In-Reply-To: <JIRA.12479851.1353935247000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12479851.1353935247000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12479851.1353935247000.23101.1395139932602@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-1547?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tomaz Cerar updated WFLY-1547:
------------------------------

    Comment: was deleted

(was: Kabir Khan <kkhan at redhat.com> changed the Status of [bug 901210|https://bugzilla.redhat.com/show_bug.cgi?id=901210] from POST to MODIFIED)

    
> deploy directories not cleaned up
> ---------------------------------
>
>                 Key: WFLY-1547
>                 URL: https://issues.jboss.org/browse/WFLY-1547
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 8.0.0.Alpha1
>            Reporter: Shaun Appleton
>            Assignee: jaikiran pai
>             Fix For: 8.0.0.Beta1
>
>         Attachments: deployment_with_hack_no_hook.txt
>
>
> JBoss EAP 6.0.0 (and 6.0.1.ER3) doesn't clean up it's tmp/vfs directories.
> The following reproduces this -
> i) ensure run.conf has the -Xrs set
> ii) ensure deployments has a deployable .ear in it
> iii) ./run standalone.sh and allow the deployments to deploy
> iv) stop the EAP process ie kill <process_id>
> v) observe content tmp/vfs
> (The -Xrs parameter is used to "-Xrs" to prevent possible interference when JVM is running as a service and receives CTRL_LOGOFF_EVENT or SIGHUP)
> This will eventually cause problems with lack of disk space.
> Note if the -Xrs parameter content is removed but the tmp/vfs dirs stills exist. This could potentially cause inode problems.
> It would be better if there were any additional code so the temp dirs are cleaned up on start up. That would resolve both the -Xrs problem and the excessive dir creation.

--
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

From issues at jboss.org  Tue Mar 18 07:30:10 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 18 Mar 2014 07:30:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2408) Add TRACE logging for
 connection properties used to connect to LDAP from realm.
In-Reply-To: <JIRA.12509083.1383136851000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12509083.1383136851000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12509083.1383136851000.23177.1395142210963@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2408?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated WFLY-2408:
------------------------------------------

        Bugzilla Update: Perform
    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=974324

    
> Add TRACE logging for connection properties used to connect to LDAP from realm.
> -------------------------------------------------------------------------------
>
>                 Key: WFLY-2408
>                 URL: https://issues.jboss.org/browse/WFLY-2408
>             Project: WildFly
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management, Security
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 8.0.0.CR1
>
>


--
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

From issues at jboss.org  Tue Mar 18 07:58:10 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 18 Mar 2014 07:58:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2408) Add TRACE logging for
 connection properties used to connect to LDAP from realm.
In-Reply-To: <JIRA.12509083.1383136851000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12509083.1383136851000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12509083.1383136851000.23288.1395143890703@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2408?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12953785#comment-12953785 ] 

RH Bugzilla Integration commented on WFLY-2408:
-----------------------------------------------

Darran Lofthouse <darran.lofthouse at redhat.com> changed the Status of [bug 974324|https://bugzilla.redhat.com/show_bug.cgi?id=974324] from ASSIGNED to POST
                
> Add TRACE logging for connection properties used to connect to LDAP from realm.
> -------------------------------------------------------------------------------
>
>                 Key: WFLY-2408
>                 URL: https://issues.jboss.org/browse/WFLY-2408
>             Project: WildFly
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management, Security
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 8.0.0.CR1
>
>


--
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

From issues at jboss.org  Tue Mar 18 07:58:10 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 18 Mar 2014 07:58:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-352) Add sufficient TRACE / DEBUG
 logging to debug security realm configurations.
In-Reply-To: <JIRA.12489981.1366392604000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12489981.1366392604000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12489981.1366392604000.23293.1395143890980@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-352?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12953786#comment-12953786 ] 

RH Bugzilla Integration commented on WFLY-352:
----------------------------------------------

Darran Lofthouse <darran.lofthouse at redhat.com> changed the Status of [bug 974324|https://bugzilla.redhat.com/show_bug.cgi?id=974324] from ASSIGNED to POST
                
> Add sufficient TRACE / DEBUG logging to debug security realm configurations.
> ----------------------------------------------------------------------------
>
>                 Key: WFLY-352
>                 URL: https://issues.jboss.org/browse/WFLY-352
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>            Reporter: Eric Rich
>            Assignee: Darran Lofthouse
>            Priority: Critical
>             Fix For: 8.0.0.Beta1
>
>         Attachments: jboss-as-domain-management-7.1.2.Final-redhat-1.jar, log_mgmt_auth_calls.txt
>
>
> When trying to diagnose LDAP or Admin Configuration issue in Domain mode there is currently no logging for any of the authentication information. 

--
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

From issues at jboss.org  Tue Mar 18 07:58:11 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 18 Mar 2014 07:58:11 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3077) Convert command line IPv6 URL
 literals to address literals
In-Reply-To: <JIRA.12534346.1394155395000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534346.1394155395000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534346.1394155395000.23299.1395143891317@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-3077?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12953787#comment-12953787 ] 

RH Bugzilla Integration commented on WFLY-3077:
-----------------------------------------------

Miroslav Novak <mnovak at redhat.com> changed the Status of [bug 1064771|https://bugzilla.redhat.com/show_bug.cgi?id=1064771] from VERIFIED to ASSIGNED
                
> Convert command line IPv6 URL literals to address literals
> ----------------------------------------------------------
>
>                 Key: WFLY-3077
>                 URL: https://issues.jboss.org/browse/WFLY-3077
>             Project: WildFly
>          Issue Type: Enhancement
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 8.0.0.Final
>            Reporter: Brian Stansberry
>            Assignee: Brian Stansberry
>            Priority: Minor
>             Fix For: 8.0.1.Final
>
>
> When people provide URL-style values like [::1] for command line args like -b, convert them to address values (i.e. strip the enclosing brackets.)

--
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

From issues at jboss.org  Tue Mar 18 08:20:11 2014
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 18 Mar 2014 08:20:11 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3125) Update help text for add-user
 to reflect that password is checked against the configured policy.
In-Reply-To: <JIRA.12535263.1395145186426@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12535263.1395145186426@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12535263.1395145186426.23321.1395145211192@jira02.app.mwc.hst.phx2.redhat.com>

Darran Lofthouse created WFLY-3125:
--------------------------------------

             Summary: Update help text for add-user to reflect that password is checked against the configured policy.
                 Key: WFLY-3125
                 URL: https://issues.jboss.org/browse/WFLY-3125
             Project: WildFly
          Issue Type: Task
      Security Level: Public (Everyone can see)
          Components: Domain Management
            Reporter: Darran Lofthouse
            Assignee: Darran Lofthouse
             Fix For: 8.0.1.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

From issues at jboss.org  Tue Mar 18 08:22:10 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 18 Mar 2014 08:22:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3125) Update help text for add-user
 to reflect that password is checked against the configured policy.
In-Reply-To: <JIRA.12535263.1395145186000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12535263.1395145186000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12535263.1395145186000.23328.1395145330834@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-3125?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated WFLY-3125:
------------------------------------------

        Bugzilla Update: Perform
    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1063888

    
> Update help text for add-user to reflect that password is checked against the configured policy.
> ------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-3125
>                 URL: https://issues.jboss.org/browse/WFLY-3125
>             Project: WildFly
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 8.0.1.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

From issues at jboss.org  Tue Mar 18 08:24:11 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 18 Mar 2014 08:24:11 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3069) slaves cannot reconnect to a
 restarted master if RBAC is enabled
In-Reply-To: <JIRA.12534143.1394020494000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534143.1394020494000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534143.1394020494000.23343.1395145451010@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-3069?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12953794#comment-12953794 ] 

RH Bugzilla Integration commented on WFLY-3069:
-----------------------------------------------

Petr Kremensky <pkremens at redhat.com> changed the Status of [bug 1072915|https://bugzilla.redhat.com/show_bug.cgi?id=1072915] from ON_QA to VERIFIED
                
> slaves cannot reconnect to a restarted master if RBAC is enabled
> ----------------------------------------------------------------
>
>                 Key: WFLY-3069
>                 URL: https://issues.jboss.org/browse/WFLY-3069
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>    Affects Versions: 8.0.0.Final
>            Reporter: Tom Fonteyne
>            Assignee: Emanuel Muckenhuber
>            Priority: Critical
>             Fix For: 8.0.1.Final
>
>
> Enable RBAC in an Wilfly domain setup. "reload --host=master" and the slaves will no longer be connected to the master

--
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

From issues at jboss.org  Tue Mar 18 08:48:12 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 18 Mar 2014 08:48:12 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3125) Update help text for add-user
 to reflect that password is checked against the configured policy.
In-Reply-To: <JIRA.12535263.1395145186000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12535263.1395145186000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12535263.1395145186000.23403.1395146892181@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-3125?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12953799#comment-12953799 ] 

RH Bugzilla Integration commented on WFLY-3125:
-----------------------------------------------

Darran Lofthouse <darran.lofthouse at redhat.com> changed the Status of [bug 1063888|https://bugzilla.redhat.com/show_bug.cgi?id=1063888] from ASSIGNED to POST
                
> Update help text for add-user to reflect that password is checked against the configured policy.
> ------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-3125
>                 URL: https://issues.jboss.org/browse/WFLY-3125
>             Project: WildFly
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 8.0.1.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

From issues at jboss.org  Tue Mar 18 08:56:10 2014
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 18 Mar 2014 08:56:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3126) add-user invalid error
 message for alpha carachter requirement
In-Reply-To: <JIRA.12535266.1395147338349@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12535266.1395147338349@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12535266.1395147338349.23415.1395147370681@jira02.app.mwc.hst.phx2.redhat.com>

Darran Lofthouse created WFLY-3126:
--------------------------------------

             Summary: add-user invalid error message for alpha carachter requirement
                 Key: WFLY-3126
                 URL: https://issues.jboss.org/browse/WFLY-3126
             Project: WildFly
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Domain Management
            Reporter: Darran Lofthouse
            Assignee: Darran Lofthouse
             Fix For: 8.0.1.Final


The following error is output for a password that is entirely numeric: -

{code}
[darranl at localhost bin]$ ./add-user.sh admin2 22222222222

 * Error * 
JBAS015268: Password must have at least 1 alphanumeric character.
{code}

It should say alphabetic not alphanumeric.


--
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

From issues at jboss.org  Tue Mar 18 09:00:13 2014
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 18 Mar 2014 09:00:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3126) add-user invalid error
 message for alpha characters requirement
In-Reply-To: <JIRA.12535266.1395147338000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12535266.1395147338000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12535266.1395147338000.23423.1395147613368@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-3126?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated WFLY-3126:
-----------------------------------

    Summary: add-user invalid error message for alpha characters requirement  (was: add-user invalid error message for alpha carachter requirement)

    
> add-user invalid error message for alpha characters requirement
> ---------------------------------------------------------------
>
>                 Key: WFLY-3126
>                 URL: https://issues.jboss.org/browse/WFLY-3126
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 8.0.1.Final
>
>
> The following error is output for a password that is entirely numeric: -
> {code}
> [darranl at localhost bin]$ ./add-user.sh admin2 22222222222
>  * Error * 
> JBAS015268: Password must have at least 1 alphanumeric character.
> {code}
> It should say alphabetic not alphanumeric.

--
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

From issues at jboss.org  Tue Mar 18 09:02:10 2014
From: issues at jboss.org (Jesper Pedersen (JIRA))
Date: Tue, 18 Mar 2014 09:02:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBJCA-1155) IronJacamar under security
 manager throws exception
In-Reply-To: <JIRA.12535028.1394801854000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12535028.1394801854000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12535028.1394801854000.23441.1395147730626@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBJCA-1155?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jesper Pedersen updated JBJCA-1155:
-----------------------------------

    Fix Version/s: 1.2.0.Beta1
                       (was: 1.2.0.CR1)
      Component/s: Common
                   Core
                   Deployer
                   EIS
                   Embedded
                   JDBC
                   Validator

    
> IronJacamar under security manager throws exception
> ---------------------------------------------------
>
>                 Key: JBJCA-1155
>                 URL: https://issues.jboss.org/browse/JBJCA-1155
>             Project: IronJacamar
>          Issue Type: Bug
>          Components: Common, Core, Deployer, EIS, Embedded, JDBC, Validator
>    Affects Versions: 1.0.24.Final, 1.1.4.Final
>            Reporter: Jesper Pedersen
>            Assignee: Jesper Pedersen
>            Priority: Blocker
>             Fix For: 1.0.25.Final, 1.1.5.Final, 1.2.0.Beta1
>
>


--
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

From issues at jboss.org  Tue Mar 18 09:02:10 2014
From: issues at jboss.org (Jesper Pedersen (JIRA))
Date: Tue, 18 Mar 2014 09:02:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBJCA-1155) IronJacamar under security
 manager throws exception
In-Reply-To: <JIRA.12535028.1394801854000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12535028.1394801854000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12535028.1394801854000.23443.1395147730709@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBJCA-1155?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jesper Pedersen resolved JBJCA-1155.
------------------------------------

    Resolution: Done

    
> IronJacamar under security manager throws exception
> ---------------------------------------------------
>
>                 Key: JBJCA-1155
>                 URL: https://issues.jboss.org/browse/JBJCA-1155
>             Project: IronJacamar
>          Issue Type: Bug
>          Components: Common, Core, Deployer, EIS, Embedded, JDBC, Validator
>    Affects Versions: 1.0.24.Final, 1.1.4.Final
>            Reporter: Jesper Pedersen
>            Assignee: Jesper Pedersen
>            Priority: Blocker
>             Fix For: 1.0.25.Final, 1.1.5.Final, 1.2.0.Beta1
>
>


--
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

From issues at jboss.org  Tue Mar 18 09:14:10 2014
From: issues at jboss.org (Sanne Grinovero (JIRA))
Date: Tue, 18 Mar 2014 09:14:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3127) Upgrade to Apache Avro 1.7.6
In-Reply-To: <JIRA.12535268.1395148407390@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12535268.1395148407390@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12535268.1395148407390.23470.1395148450853@jira02.app.mwc.hst.phx2.redhat.com>

Sanne Grinovero created WFLY-3127:
-------------------------------------

             Summary: Upgrade to Apache Avro 1.7.6
                 Key: WFLY-3127
                 URL: https://issues.jboss.org/browse/WFLY-3127
             Project: WildFly
          Issue Type: Component  Upgrade
      Security Level: Public (Everyone can see)
            Reporter: Sanne Grinovero
            Assignee: Sanne Grinovero
            Priority: Trivial
             Fix For: 8.0.1.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

From issues at jboss.org  Tue Mar 18 09:22:11 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 18 Mar 2014 09:22:11 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2920) StackOverflowError when
 org.jboss.as.jacorb.rmi.InterfaceAnalysis is analyzing javax.ejb.EJBObject
In-Reply-To: <JIRA.12532007.1392269121000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12532007.1392269121000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12532007.1392269121000.23505.1395148931034@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2920?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12953808#comment-12953808 ] 

RH Bugzilla Integration commented on WFLY-2920:
-----------------------------------------------

Jan Martiska <jmartisk at redhat.com> changed the Status of [bug 1064644|https://bugzilla.redhat.com/show_bug.cgi?id=1064644] from ON_QA to VERIFIED
                
> StackOverflowError when org.jboss.as.jacorb.rmi.InterfaceAnalysis is analyzing javax.ejb.EJBObject
> --------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2920
>                 URL: https://issues.jboss.org/browse/WFLY-2920
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: IIOP
>    Affects Versions: 8.0.0.Final
>            Reporter: Osamu Nagano
>            Assignee: Stefan Guilhen
>         Attachments: td.dump
>
>
> Depending on when a thread context switch happens, an IIOP enabled EJB fails to be deployed by throwing {{java.lang.StackOverflowError}}.  Here is the stack trace from the attached thread dump.
> {code}
> "MSC service thread 1-7" prio=10 tid=0x00007f52e8001800 nid=0x4d12 at breakpoint[0x00007f534093f000]
>    java.lang.Thread.State: RUNNABLE
>         at org.jboss.as.jacorb.rmi.WorkCacheManager.getAnalysis(WorkCacheManager.java:105)
>         at org.jboss.as.jacorb.rmi.InterfaceAnalysis.getInterfaceAnalysis(InterfaceAnalysis.java:53)
>         at org.jboss.as.jacorb.rmi.Util.getTypeIDLName(Util.java:104)
>         at org.jboss.as.jacorb.rmi.ParameterAnalysis.<init>(ParameterAnalysis.java:50)
>         at org.jboss.as.jacorb.rmi.OperationAnalysis.<init>(OperationAnalysis.java:91)
>         at org.jboss.as.jacorb.rmi.InterfaceAnalysis.analyzeOperations(InterfaceAnalysis.java:116)
>         at org.jboss.as.jacorb.rmi.ContainerAnalysis.doAnalyze(ContainerAnalysis.java:186)
>         at org.jboss.as.jacorb.rmi.InterfaceAnalysis.doAnalyze(InterfaceAnalysis.java:62)
>         at sun.reflect.GeneratedMethodAccessor3.invoke(Unknown Source)
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>         at java.lang.reflect.Method.invoke(Method.java:606)
>         at org.jboss.as.jacorb.rmi.WorkCacheManager.doTheWork(WorkCacheManager.java:177)
>         at org.jboss.as.jacorb.rmi.WorkCacheManager.getAnalysis(WorkCacheManager.java:105)
>         at org.jboss.as.jacorb.rmi.InterfaceAnalysis.getInterfaceAnalysis(InterfaceAnalysis.java:53)
>         at org.jboss.as.jacorb.rmi.Util.getTypeIDLName(Util.java:104)
>         at org.jboss.as.jacorb.rmi.ParameterAnalysis.<init>(ParameterAnalysis.java:50)
>         at org.jboss.as.jacorb.rmi.OperationAnalysis.<init>(OperationAnalysis.java:91)
>         at org.jboss.as.jacorb.rmi.InterfaceAnalysis.analyzeOperations(InterfaceAnalysis.java:116)
>         at org.jboss.as.jacorb.rmi.ContainerAnalysis.doAnalyze(ContainerAnalysis.java:186)
>         at org.jboss.as.jacorb.rmi.InterfaceAnalysis.doAnalyze(InterfaceAnalysis.java:62)
>         at sun.reflect.GeneratedMethodAccessor3.invoke(Unknown Source)
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>         at java.lang.reflect.Method.invoke(Method.java:606)
>         ...
>         at org.jboss.as.jacorb.rmi.WorkCacheManager.doTheWork(WorkCacheManager.java:177)
>         at org.jboss.as.jacorb.rmi.WorkCacheManager.getAnalysis(WorkCacheManager.java:105)
>         at org.jboss.as.jacorb.rmi.InterfaceAnalysis.getInterfaceAnalysis(InterfaceAnalysis.java:53)
>         at org.jboss.as.jacorb.rmi.Util.getTypeIDLName(Util.java:104)
>         at org.jboss.as.jacorb.rmi.ParameterAnalysis.<init>(ParameterAnalysis.java:50)
>    Locked ownable synchronizers:
>         - <0x00000000f9698790> (a java.util.concurrent.ThreadPoolExecutor$Worker)
> {code}
> The last part including {{Util.getTypeIDLName}} has been repeated as many as possible and the bottom of the stack has been lost.  The same stack has been appeared in a different MSC service thread which is also executing an IIOP enabled EJB deployment.
> The customer identified an improper synchronization in {{org.jboss.as.jacorb.rmi.WorkCacheManager#getAnalysis()}}.  It is reproducible by manually controlling a thread context switch using a debugger.

--
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

From issues at jboss.org  Tue Mar 18 09:34:11 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 18 Mar 2014 09:34:11 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3125) Update help text for add-user
 to reflect that password is checked against the configured policy.
In-Reply-To: <JIRA.12535263.1395145186000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12535263.1395145186000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12535263.1395145186000.23554.1395149651245@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-3125?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12953817#comment-12953817 ] 

RH Bugzilla Integration commented on WFLY-3125:
-----------------------------------------------

Darran Lofthouse <darran.lofthouse at redhat.com> changed the Status of [bug 1063888|https://bugzilla.redhat.com/show_bug.cgi?id=1063888] from POST to ASSIGNED
                
> Update help text for add-user to reflect that password is checked against the configured policy.
> ------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-3125
>                 URL: https://issues.jboss.org/browse/WFLY-3125
>             Project: WildFly
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 8.0.1.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

From issues at jboss.org  Tue Mar 18 09:44:10 2014
From: issues at jboss.org (Jozef Hartinger (JIRA))
Date: Tue, 18 Mar 2014 09:44:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3128) Implement CDI 1.2 bean
 discovery annotation changes
In-Reply-To: <JIRA.12535276.1395150232243@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12535276.1395150232243@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12535276.1395150232243.23593.1395150250609@jira02.app.mwc.hst.phx2.redhat.com>

Jozef Hartinger created WFLY-3128:
-------------------------------------

             Summary: Implement CDI 1.2 bean discovery annotation changes
                 Key: WFLY-3128
                 URL: https://issues.jboss.org/browse/WFLY-3128
             Project: WildFly
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: CDI / Weld
    Affects Versions: 8.0.0.Final
            Reporter: Jozef Hartinger
            Assignee: Martin Kouba
             Fix For: 9.0.0.CR1


https://issues.jboss.org/browse/CDI-377
https://issues.jboss.org/browse/CDI-404
https://issues.jboss.org/browse/CDI-406

--
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

From issues at jboss.org  Tue Mar 18 09:50:10 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 18 Mar 2014 09:50:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3125) Update help text for add-user
 to reflect that password is checked against the configured policy.
In-Reply-To: <JIRA.12535263.1395145186000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12535263.1395145186000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12535263.1395145186000.23607.1395150610716@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-3125?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12953824#comment-12953824 ] 

RH Bugzilla Integration commented on WFLY-3125:
-----------------------------------------------

Darran Lofthouse <darran.lofthouse at redhat.com> changed the Status of [bug 1063888|https://bugzilla.redhat.com/show_bug.cgi?id=1063888] from ASSIGNED to POST
                
> Update help text for add-user to reflect that password is checked against the configured policy.
> ------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-3125
>                 URL: https://issues.jboss.org/browse/WFLY-3125
>             Project: WildFly
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 8.0.1.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

From issues at jboss.org  Tue Mar 18 10:14:12 2014
From: issues at jboss.org (Harald Pehl (JIRA))
Date: Tue, 18 Mar 2014 10:14:12 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3129) Update to HAL 2.2.0.Final
In-Reply-To: <JIRA.12535281.1395151982200@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12535281.1395151982200@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12535281.1395151982200.23708.1395152052551@jira02.app.mwc.hst.phx2.redhat.com>

Harald Pehl created WFLY-3129:
---------------------------------

             Summary: Update to HAL 2.2.0.Final
                 Key: WFLY-3129
                 URL: https://issues.jboss.org/browse/WFLY-3129
             Project: WildFly
          Issue Type: Component  Upgrade
      Security Level: Public (Everyone can see)
          Components: Web Console
            Reporter: Harald Pehl
            Assignee: Harald Pehl
            Priority: Blocker
             Fix For: 8.0.1.Final


This release contains the slimmed HAL console (see HAL-381 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

From issues at jboss.org  Tue Mar 18 11:40:11 2014
From: issues at jboss.org (Gytis Trikleris (JIRA))
Date: Tue, 18 Mar 2014 11:40:11 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-951) It is not possible to enable
 AtomicActionExpiryScanner in EAP 6.x
In-Reply-To: <JIRA.12481931.1357289932000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12481931.1357289932000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12481931.1357289932000.24267.1395157211316@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-951?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12953905#comment-12953905 ] 

Gytis Trikleris commented on WFLY-951:
--------------------------------------

Sorry for delayed response. I have quite a lot on my plate at the moment. But I think I could sort this out in April, if that's all right?
                
> It is not possible to enable AtomicActionExpiryScanner in EAP 6.x
> -----------------------------------------------------------------
>
>                 Key: WFLY-951
>                 URL: https://issues.jboss.org/browse/WFLY-951
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Transactions
>         Environment: JBoss EAP 6.01
>            Reporter: Tom Ross
>            Assignee: Gytis Trikleris
>
> It should be possible to add AtomicActionExpiryScanner to the EAP 6 configuration as outline below:
> {noformat} 
> <system-properties>
>     	<property name="RecoveryEnvironmentBean.expiryScannerClassNames" value="com.arjuna.ats.internal.arjuna.recovery.ExpiredTransactionStatusManagerScanner\\s+com.arjuna.ats.internal.arjuna.recovery.AtomicActionExpiryScanner"/>
>     </system-properties>
> {noformat}?
> Unfortunately the value of the RecoveryEnvironmentBean.expiryScannerClassNames seems to be overwritten in the ArjunaRecoveryManagerService class. As a result there is no easy way of removing transaction manager debris from object store. 

--
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


From issues at jboss.org  Tue Mar 18 12:14:10 2014
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 18 Mar 2014 12:14:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3130) Add a custom RuntimeException
 to add-user utility.
In-Reply-To: <JIRA.12535302.1395159229394@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12535302.1395159229394@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12535302.1395159229394.24360.1395159250822@jira02.app.mwc.hst.phx2.redhat.com>

Darran Lofthouse created WFLY-3130:
--------------------------------------

             Summary: Add a custom RuntimeException to add-user utility.
                 Key: WFLY-3130
                 URL: https://issues.jboss.org/browse/WFLY-3130
             Project: WildFly
          Issue Type: Task
      Security Level: Public (Everyone can see)
          Components: Domain Management
            Reporter: Darran Lofthouse
            Assignee: Darran Lofthouse
             Fix For: 8.0.1.Final


The add-user utility uses a RuntimeException to indicate failure in non-interactive mode, this does not look good so should switch it to a custom exception of our own.

--
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

From issues at jboss.org  Tue Mar 18 12:16:12 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 18 Mar 2014 12:16:12 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3130) Add a custom RuntimeException
 to add-user utility.
In-Reply-To: <JIRA.12535302.1395159229000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12535302.1395159229000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12535302.1395159229000.24367.1395159372095@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-3130?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated WFLY-3130:
------------------------------------------

        Bugzilla Update: Perform
    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1062595

    
> Add a custom RuntimeException to add-user utility.
> --------------------------------------------------
>
>                 Key: WFLY-3130
>                 URL: https://issues.jboss.org/browse/WFLY-3130
>             Project: WildFly
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 8.0.1.Final
>
>
> The add-user utility uses a RuntimeException to indicate failure in non-interactive mode, this does not look good so should switch it to a custom exception of our own.

--
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

From issues at jboss.org  Tue Mar 18 12:18:11 2014
From: issues at jboss.org (Bela Ban (JIRA))
Date: Tue, 18 Mar 2014 12:18:11 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1806) UnicastLoopbackTest fails to
 receive all messages in the allotted time
In-Reply-To: <JIRA.12534313.1394124154000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534313.1394124154000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534313.1394124154000.24375.1395159491171@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JGRP-1806?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban updated JGRP-1806:
---------------------------

    Fix Version/s: 3.2.14
                       (was: 3.2.13)

    
> UnicastLoopbackTest fails to receive all messages in the allotted time
> ----------------------------------------------------------------------
>
>                 Key: JGRP-1806
>                 URL: https://issues.jboss.org/browse/JGRP-1806
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.2.13
>         Environment: RHEL, Windows, Solaris
>            Reporter: Richard Achmatowicz
>            Assignee: Bela Ban
>             Fix For: 3.2.14
>
>
> UnicastLoopbackTest.testUnicastMessagesWithLoopback() is failing with the following error:
> {noformat}
> Error Message
> Test timed out before all messages were received
> Stacktrace
> java.lang.AssertionError 
> at org.testng.Assert.fail(Assert.java:94) 
> at org.jgroups.tests.UnicastLoopbackTest.testUnicastMsgsWithLoopback(UnicastLoopbackTest.java:78) 
> {noformat}
> The test does the following:
> - creates one channel with loopback enabled in the transport
> - the channel is assigned a receiver which collects the messages received and sets a Boolean valued Promise when all messages have been received 
> - the channel sends 1000 messages to itself in a burst
> - waits 20 seconds for the promise to be set to true
> The test fails because the messages do not arrive within the allotted 20 seconds.

--
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

From issues at jboss.org  Tue Mar 18 12:18:11 2014
From: issues at jboss.org (Bela Ban (JIRA))
Date: Tue, 18 Mar 2014 12:18:11 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1806) UnicastLoopbackTest fails to
 receive all messages in the allotted time
In-Reply-To: <JIRA.12534313.1394124154000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534313.1394124154000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534313.1394124154000.24379.1395159491505@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JGRP-1806?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban updated JGRP-1806:
---------------------------

    Fix Version/s: 3.2.13
                       (was: 3.2.14)

    
> UnicastLoopbackTest fails to receive all messages in the allotted time
> ----------------------------------------------------------------------
>
>                 Key: JGRP-1806
>                 URL: https://issues.jboss.org/browse/JGRP-1806
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.2.13
>         Environment: RHEL, Windows, Solaris
>            Reporter: Richard Achmatowicz
>            Assignee: Bela Ban
>             Fix For: 3.2.13
>
>
> UnicastLoopbackTest.testUnicastMessagesWithLoopback() is failing with the following error:
> {noformat}
> Error Message
> Test timed out before all messages were received
> Stacktrace
> java.lang.AssertionError 
> at org.testng.Assert.fail(Assert.java:94) 
> at org.jgroups.tests.UnicastLoopbackTest.testUnicastMsgsWithLoopback(UnicastLoopbackTest.java:78) 
> {noformat}
> The test does the following:
> - creates one channel with loopback enabled in the transport
> - the channel is assigned a receiver which collects the messages received and sets a Boolean valued Promise when all messages have been received 
> - the channel sends 1000 messages to itself in a burst
> - waits 20 seconds for the promise to be set to true
> The test fails because the messages do not arrive within the allotted 20 seconds.

--
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

From issues at jboss.org  Tue Mar 18 12:18:11 2014
From: issues at jboss.org (Bela Ban (JIRA))
Date: Tue, 18 Mar 2014 12:18:11 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1806) UnicastLoopbackTest fails to
 receive all messages in the allotted time
In-Reply-To: <JIRA.12534313.1394124154000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534313.1394124154000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534313.1394124154000.24383.1395159491705@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JGRP-1806?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban resolved JGRP-1806.
----------------------------

    Resolution: Done

    
> UnicastLoopbackTest fails to receive all messages in the allotted time
> ----------------------------------------------------------------------
>
>                 Key: JGRP-1806
>                 URL: https://issues.jboss.org/browse/JGRP-1806
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.2.13
>         Environment: RHEL, Windows, Solaris
>            Reporter: Richard Achmatowicz
>            Assignee: Bela Ban
>             Fix For: 3.2.13
>
>
> UnicastLoopbackTest.testUnicastMessagesWithLoopback() is failing with the following error:
> {noformat}
> Error Message
> Test timed out before all messages were received
> Stacktrace
> java.lang.AssertionError 
> at org.testng.Assert.fail(Assert.java:94) 
> at org.jgroups.tests.UnicastLoopbackTest.testUnicastMsgsWithLoopback(UnicastLoopbackTest.java:78) 
> {noformat}
> The test does the following:
> - creates one channel with loopback enabled in the transport
> - the channel is assigned a receiver which collects the messages received and sets a Boolean valued Promise when all messages have been received 
> - the channel sends 1000 messages to itself in a burst
> - waits 20 seconds for the promise to be set to true
> The test fails because the messages do not arrive within the allotted 20 seconds.

--
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

From issues at jboss.org  Tue Mar 18 12:18:11 2014
From: issues at jboss.org (Bela Ban (JIRA))
Date: Tue, 18 Mar 2014 12:18:11 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1802) OverlappingUnicastMergeTest
 fails to receive all messages
In-Reply-To: <JIRA.12533772.1393856602000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12533772.1393856602000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12533772.1393856602000.24387.1395159491942@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JGRP-1802?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban resolved JGRP-1802.
----------------------------

    Resolution: Done

    
> OverlappingUnicastMergeTest fails to receive all messages
> ---------------------------------------------------------
>
>                 Key: JGRP-1802
>                 URL: https://issues.jboss.org/browse/JGRP-1802
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.2.13
>         Environment: Solaris, RHEL
>            Reporter: Richard Achmatowicz
>            Assignee: Bela Ban
>             Fix For: 3.2.13
>
>
> OverlappingUnicastMergeTest does the following:
> - set up three channels a,b,c with the layers MERGE2, VERIFY_SUSPECT and FC removed
> - the receiver of each channel will look at all incoming messages: if mcast, ignore it; if unicast, add to the list of messages received
> - inject some new view into the channels which represents a view configuration which should be recovered from
> - send messages to the channels and check that the messages are received, despite the  injected view
> OverlappingUnicastMergeTest this test is failing in a number of ways (i.e. many of the test methods are failing within the test class on multiple platforms. 
> What we expect to see is:
> {noformat}
> receiver A: ucasts=15
> receiver B: ucasts=15
> receiver C: ucasts=15
> {noformat}
> What we instead see is:
> {noformat}
> receiver A: ucasts=15
> receiver B: ucasts=11
> ucasts for B: 
> B: unicast msg #1 from B B: unicast msg #2 from B B: unicast msg #3 from B B: unicast msg #4 from B B: unicast msg #5 from B  A: unicast msg #1 from A C: unicast msg #2 from C C: unicast msg #3 from C A: unicast msg #4 from A C: unicast msg #4 from C C: unicast msg #5 from C 
> {noformat}
> The order here is the order in which the unicasts were received from all three senders by the single receiver. For example, in the above, in testWithViewBC, channel A should receive messages #1 through #5 from channels A, B and C, but it does not receive #1 from channel C. 

--
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

From issues at jboss.org  Tue Mar 18 12:18:12 2014
From: issues at jboss.org (Bela Ban (JIRA))
Date: Tue, 18 Mar 2014 12:18:12 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1805) OverlappingMergeTest
 testMergeWithDifferentPartitions fails to create correct merged view
In-Reply-To: <JIRA.12534032.1393962618000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534032.1393962618000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534032.1393962618000.24391.1395159492228@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JGRP-1805?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban resolved JGRP-1805.
----------------------------

    Resolution: Done

    
> OverlappingMergeTest testMergeWithDifferentPartitions fails to create correct merged view
> -----------------------------------------------------------------------------------------
>
>                 Key: JGRP-1805
>                 URL: https://issues.jboss.org/browse/JGRP-1805
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.2.13
>         Environment: RHEL
>            Reporter: Richard Achmatowicz
>            Assignee: Bela Ban
>             Fix For: 3.2.13
>
>
> This test does the following:
> - creates four channels a,b,c,d
> - injects views A: {A,C,B}, B:{A,C,B}, C:{A,C,B} and D: {B,A,C,D}
> - injects a merge event in each of channels A,B,C,D representing these four views
> - checks that all channels have the final view of size 4
> The test fails intermittently on RHEL, with the same failure each time:
> {noformat}
> 181595 [DEBUG] GMS: - A: installing view [A|2] [A]
>    [testng] 181596 [TRACE] GMS: - A: received all 1 ACKs from members for view [A|2]
>    [testng] 181866 [TRACE] GMS: - view [A|3] [] is empty: will not multicast it (last view)
>    [testng] 
>    [testng] -------------------------------------------------------------------
>    [testng] GMS: address=A, cluster=OverlappingMergeTest, physical address=10.16.94.42:27199
>    [testng] -------------------------------------------------------------------
>    [testng] 184954 [TRACE] GMS: - A: no initial members discovered: creating group as first member
>    [testng] 184954 [DEBUG] GMS: - A: installing view [A|0] [A]
>    [testng] 184955 [DEBUG] GMS: - created group (first member). My view is [A|0], impl is org.jgroups.protocols.pbcast.CoordGmsImpl
>    [testng] 
>    [testng] -------------------------------------------------------------------
>    [testng] GMS: address=B, cluster=OverlappingMergeTest, physical address=10.16.94.42:27200
>    [testng] -------------------------------------------------------------------
>    [testng] 184961 [TRACE] GMS: - B: initial_mbrs are A 
>    [testng] 184961 [DEBUG] GMS: - election results: {A=1}
>    [testng] 184961 [DEBUG] GMS: - sending JOIN(B) to A
>    [testng] 185013 [TRACE] GMS: - A: new members=[B], suspected=[], leaving=[], new view: [A|1] [A, B]
>    [testng] 185014 [TRACE] GMS: - A: mcasting view [A|1] [A, B] (2 mbrs)
>    [testng] 
>    [testng] 185025 [DEBUG] GMS: - A: installing view [A|1] [A, B]
>    [testng] 185026 [TRACE] GMS: - A: received all 1 ACKs from members for view [A|1]
>    [testng] 185055 [TRACE] GMS: - B: JOIN-RSP=[A|1] [A, B] [size=2]
>    [testng] 
>    [testng] 
>    [testng] 185055 [DEBUG] GMS: - B: installing view [A|1] [A, B]
>    [testng] 185057 [TRACE] GMS: - A: received all ACKs (1) from joiners for view [A|1]
>    [testng] 
>    [testng] -------------------------------------------------------------------
>    [testng] GMS: address=C, cluster=OverlappingMergeTest, physical address=10.16.94.42:27201
>    [testng] -------------------------------------------------------------------
>    [testng] 185064 [TRACE] GMS: - C: initial_mbrs are B A 
>    [testng] 185064 [DEBUG] GMS: - election results: {A=2}
>    [testng] 185064 [DEBUG] GMS: - sending JOIN(C) to A
>    [testng] 185108 [TRACE] GMS: - A: new members=[C], suspected=[], leaving=[], new view: [A|2] [A, B, C]
>    [testng] 185108 [TRACE] GMS: - A: mcasting view [A|2] [A, B, C] (3 mbrs)
>    [testng] 
>    [testng] 185117 [DEBUG] GMS: - A: installing view [A|2] [A, B, C]
>    [testng] 185118 [DEBUG] GMS: - B: installing view [A|2] [A, B, C]
>    [testng] 185119 [TRACE] GMS: - A: received all 2 ACKs from members for view [A|2]
>    [testng] 185148 [TRACE] GMS: - C: JOIN-RSP=[A|2] [A, B, C] [size=3]
>    [testng] 
>    [testng] 
>    [testng] 185149 [DEBUG] GMS: - C: installing view [A|2] [A, B, C]
>    [testng] 185151 [TRACE] GMS: - A: received all ACKs (1) from joiners for view [A|2]
>    [testng] 
>    [testng] -------------------------------------------------------------------
>    [testng] GMS: address=D, cluster=OverlappingMergeTest, physical address=10.16.94.42:27202
>    [testng] -------------------------------------------------------------------
>    [testng] 185164 [TRACE] GMS: - D: initial_mbrs are B C A 
>    [testng] 185164 [DEBUG] GMS: - election results: {A=3}
>    [testng] 185164 [DEBUG] GMS: - sending JOIN(D) to A
>    [testng] 185203 [TRACE] GMS: - A: new members=[D], suspected=[], leaving=[], new view: [A|3] [A, B, C, D]
>    [testng] 185203 [TRACE] GMS: - A: mcasting view [A|3] [A, B, C, D] (4 mbrs)
>    [testng] 
>    [testng] 185210 [DEBUG] GMS: - A: installing view [A|3] [A, B, C, D]
>    [testng] 185211 [DEBUG] GMS: - B: installing view [A|3] [A, B, C, D]
>    [testng] 185211 [DEBUG] GMS: - C: installing view [A|3] [A, B, C, D]
>    [testng] 185213 [TRACE] GMS: - A: received all 3 ACKs from members for view [A|3]
>    [testng] 185242 [TRACE] GMS: - D: JOIN-RSP=[A|3] [A, B, C, D] [size=4]
>    [testng] 
>    [testng] 
>    [testng] 185242 [DEBUG] GMS: - D: installing view [A|3] [A, B, C, D]
>    [testng] 185242 [TRACE] GMS: - A: received all ACKs (1) from joiners for view [A|3]
>    [testng] 
>    [testng]  ==== Injecting view [A|4] [A, C, B] into A, B and C ====
>    [testng] 185243 [DEBUG] GMS: - A: installing view [A|4] [A, C, B]
>    [testng] 185243 [DEBUG] GMS: - B: installing view [A|4] [A, C, B]
>    [testng] 185244 [DEBUG] GMS: - C: installing view [A|4] [A, C, B]
>    [testng] 
>    [testng]  ==== Injecting view [B|4] [B, A, C, D] into D ====
>    [testng] 
>    [testng] 185245 [DEBUG] GMS: - D: installing view [B|4] [B, A, C, D]
>    [testng] A: [A|4] [A, C, B]
>    [testng] B: [A|4] [A, C, B]
>    [testng] C: [A|4] [A, C, B]
>    [testng] D: [B|4] [B, A, C, D]
>    [testng] 
>    [testng] ==== Injecting a merge event into A, B, C and D====
>    [testng] 185251 [TRACE] GMS: - A: got merge response from A, merge_id=A::3, merge data is sender=A, view=[A|4] [A, C, B], digest=C: [0 (0)], B: [0 (0)], A: [4 (4)]
>    [testng] 185253 [TRACE] GMS: - B: queue is suspended; request MERGE(4 views) is discarded
>    [testng] 185255 [TRACE] GMS: - C: queue is suspended; request MERGE(4 views) is discarded
>    [testng] 185255 [TRACE] GMS: - A: got merge response from B, merge_id=A::3, merge data is sender=B, view=[A|4] [A, C, B], digest=C: [0 (0)], B: [0 (1)], A: [4 (4)]
>    [testng] 190286 [TRACE] GMS: - A: mcasting view MergeView::[A|5] [A, B, C], subgroups=[A|4] [A, C, B], [A|4] [A, C, B] (3 mbrs)
>    [testng] 
>    [testng] 190286 [TRACE] GMS: - B: mcasting view MergeView::[A|5] [A, B, C], subgroups=[A|4] [A, C, B], [A|4] [A, C, B] (3 mbrs)
>    [testng] 
>    [testng] 190317 [DEBUG] GMS: - A: installing view MergeView::[A|5] [A, B, C], subgroups=[A|4] [A, C, B], [A|4] [A, C, B]
>    [testng] 190318 [DEBUG] GMS: - B: installing view MergeView::[A|5] [A, B, C], subgroups=[A|4] [A, C, B], [A|4] [A, C, B]
>    [testng] 190318 [DEBUG] GMS: - C: installing view MergeView::[A|5] [A, B, C], subgroups=[A|4] [A, C, B], [A|4] [A, C, B]
>    [testng] 190320 [TRACE] GMS: - A: received all 3 ACKs from members for view [A|5]
>    [testng] 190320 [TRACE] GMS: - B: received all 3 ACKs from members for view [A|5]
>    [testng] A: [A|5] [A, B, C] (coord=true)
>    [testng] B: [A|5] [A, B, C] (coord=false)
>    [testng] C: [A|5] [A, B, C] (coord=false)
>    [testng] D: [B|4] [B, A, C, D] (coord=false)
>    [testng] 195277 [DEBUG] GMS: - D: sending LEAVE request to B
>    [testng] FAIL: [1] org.jgroups.tests.OverlappingMergeTest.testMergeWithDifferentPartitions()
> {noformat}
>  Whenever this test fails, I see that the queues are suspended on the initial merge attempt.

--
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

From issues at jboss.org  Tue Mar 18 12:18:12 2014
From: issues at jboss.org (Bela Ban (JIRA))
Date: Tue, 18 Mar 2014 12:18:12 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1795) OOBTest
 testRandomRegularAndOOBMulticasts fails to receive all messages
In-Reply-To: <JIRA.12533033.1393174836000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12533033.1393174836000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12533033.1393174836000.24395.1395159492545@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JGRP-1795?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban resolved JGRP-1795.
----------------------------

    Resolution: Done

    
> OOBTest testRandomRegularAndOOBMulticasts fails to receive all messages
> -----------------------------------------------------------------------
>
>                 Key: JGRP-1795
>                 URL: https://issues.jboss.org/browse/JGRP-1795
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.2.13
>         Environment: RHEL(3/24), WIN (1/6), Solaris (6/24) where (x/y) means x failures over y test executions.
>            Reporter: Richard Achmatowicz
>            Assignee: Bela Ban
>             Fix For: 3.2.13
>
>
> This test does the following with two channels a and b:
> - adds a DISCARD layer to a to disccard 50% of down messages
> - sends 20 messages to the group, randomly using a and b as senders, and randomly choosing OOB or non-OOB
> - wait 10 seconds for 20 messages to be received by each of a and b
> - print out the messages received
> - remove the DISCARD layer from a 
> - wait 2.5 seconds for further messages to arrive
> - assert that 20 messages have arrived for each channel a and b
> The test fails on the assertion, with results such as:
> {noformat}
> expected 20 elements, but got 19 (list=[1, 4, 3, 8, 6, 7, 10, 13, 15, 20, 2, 5, 9, 12, 14, 16, 17, 18, 19]), missing=[0, 11]
> {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

From issues at jboss.org  Tue Mar 18 12:18:12 2014
From: issues at jboss.org (Bela Ban (JIRA))
Date: Tue, 18 Mar 2014 12:18:12 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1794) OOBTest method
 testNonBlockingUnicastOOBMessage fails to correctly receive all OOB mssages
In-Reply-To: <JIRA.12532999.1393010892000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12532999.1393010892000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12532999.1393010892000.24398.1395159492705@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JGRP-1794?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban resolved JGRP-1794.
----------------------------

    Resolution: Done

    
> OOBTest method testNonBlockingUnicastOOBMessage  fails to correctly receive all OOB mssages
> -------------------------------------------------------------------------------------------
>
>                 Key: JGRP-1794
>                 URL: https://issues.jboss.org/browse/JGRP-1794
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.2.13
>         Environment: Solaris, RHEL, Windows, HPUX
> tcp stack only
>            Reporter: Richard Achmatowicz
>            Assignee: Bela Ban
>             Fix For: 3.2.13
>
>
> This test fails regularly on multiple platforms. It doesn't fail all the time, but perhaps on 5/10 platform executions.
> The test consists of a sender and a receiver. The receiver B will receive OOB messages but blocks on a latch for 25 seconds when it receives a non-OOB message. After 25 seconds, it unblocks and continues receiving
> The test does this:
> - send 1 regular message from A -> B
> - send 9 OOB meesages from A -> B
> - wait 20 seconds for messages to arrive
> - check that all 9 OOB messages have arrived
> - unblock the latch
> - check that all 10 message have arrived
> The test failures all involve the first 9 OOB messages not arriving completely. For example, sample lists of received messages before the first 20 second interval are:
> [3,2,6,8,9,10,4]
> [2,3,4,8,9,5]
> [2,3,4,8,7,9]
> [2,3,5,4,6]
> So, it appears that either the messages are slow to arrive or not arriving at all.
> A correct result looks like this:
> {noformat}
> list = [2, 4, 3, 7, 8, 9, 10, 5, 6]
> [main]: releasing latch
> list = [2, 4, 3, 7, 8, 9, 10, 5, 6, 1]
> {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

From issues at jboss.org  Tue Mar 18 12:20:10 2014
From: issues at jboss.org (Bela Ban (JIRA))
Date: Tue, 18 Mar 2014 12:20:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1801) DuplicateTest fails when
 testing OOB multicast to all three senders
In-Reply-To: <JIRA.12533765.1393853856000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12533765.1393853856000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12533765.1393853856000.24402.1395159610679@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JGRP-1801?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban updated JGRP-1801:
---------------------------

    Fix Version/s: 3.2.14
                       (was: 3.2.13)

    
> DuplicateTest fails when testing OOB multicast to all three senders
> -------------------------------------------------------------------
>
>                 Key: JGRP-1801
>                 URL: https://issues.jboss.org/browse/JGRP-1801
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.2.13
>         Environment: Windows (18), Solaris (2), RHEL(1) where (x) is the number of failures seen
>            Reporter: Richard Achmatowicz
>            Assignee: Bela Ban
>             Fix For: 3.2.14
>
>
> DuplicateTest does the following:
> - creates three channels containing the DUPL layer called c1, c2, c3
> - DUPL is used to duplicate messages sent
> - channel receiver for channel each keeps a map of messages received from each sender
> - channels send messages: regular, OOB, or mixed
> - the test checks that the messages received  by each channel are correct in number and in order
> The test testOOBMuloticastToAll3Senders is failing regularly on multple platforms. The test makes each of the channels send OOB multicast messages to the group, but only two of three members ever end up receiving the multicast messages. Al example of the failure:
> {noformat}
> Error Message
> expected size=3, msgs: [C2, C1]
> Stacktrace
> java.lang.AssertionError 
> at org.jgroups.tests.DuplicateTest.check(DuplicateTest.java:217) 
> at org.jgroups.tests.DuplicateTest.testOOBMulticastToAll3Senders(DuplicateTest.java:123) 
> {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

From issues at jboss.org  Tue Mar 18 12:30:11 2014
From: issues at jboss.org (Jay Kumar SenSharma (JIRA))
Date: Tue, 18 Mar 2014 12:30:11 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3131) isSensitiveValue of class
 SensitiveVaultExpressionConstraint uses incorrect index in
 java.lang.String.substring method
In-Reply-To: <JIRA.12535307.1395160191151@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12535307.1395160191151@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12535307.1395160191151.24418.1395160211120@jira02.app.mwc.hst.phx2.redhat.com>

Jay Kumar SenSharma created WFLY-3131:
-----------------------------------------

             Summary: isSensitiveValue of class SensitiveVaultExpressionConstraint uses incorrect  index in java.lang.String.substring method
                 Key: WFLY-3131
                 URL: https://issues.jboss.org/browse/WFLY-3131
             Project: WildFly
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Domain Management
    Affects Versions: 8.0.0.Final
         Environment: All
            Reporter: Jay Kumar SenSharma
            Assignee: Brian Stansberry


The isSensitiveValue(ModelNode value) method of class "org.jboss.as.controller.access.constraint.SensitiveVaultExpressionConstraint" seems to be using the incorrect  index in java.lang.String.substring method.  Which is causing the following exceptions in the logs while executing the following kind of CLI command:

{code}
[standalone at localhost:9990 /] /subsystem=logging/periodic-rotating-file-handler=FILE:write-attribute(name=formatter, value="%d{HH:mm:ss,SSS} %-5p [%c] (${jboss.node.name} %t) %s%E%n")
{
    "outcome" => "failed",
    "failure-description" => "JBAS014749: Operation handler failed: String index out of range: -15",
    "rolled-back" => true
}
{code}

The Exception can be seen as following in the WildFly Logs:

{code}
21:58:04,821 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 25) JBAS014612: Operation ("write-attribute") failed - address: ([
    ("subsystem" => "logging"),
    ("periodic-rotating-file-handler" => "FILE")
]): java.lang.StringIndexOutOfBoundsException: String index out of range: -15
	at java.lang.String.substring(String.java:1911) [rt.jar:1.7.0_51]
	at org.jboss.as.controller.access.constraint.SensitiveVaultExpressionConstraint$Factory.isSensitiveValue(SensitiveVaultExpressionConstraint.java:128) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
	at org.jboss.as.controller.access.constraint.SensitiveVaultExpressionConstraint$Factory.isSensitiveAction(SensitiveVaultExpressionConstraint.java:89) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
	at org.jboss.as.controller.access.constraint.SensitiveVaultExpressionConstraint$Factory.getRequiredConstraint(SensitiveVaultExpressionConstraint.java:81) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
	at org.jboss.as.controller.access.rbac.DefaultPermissionFactory.getRequiredPermissions(DefaultPermissionFactory.java:201) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
	at org.jboss.as.controller.access.permission.ManagementPermissionAuthorizer.authorize(ManagementPermissionAuthorizer.java:100) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
	at org.jboss.as.controller.access.management.DelegatingConfigurableAuthorizer.authorize(DelegatingConfigurableAuthorizer.java:98) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
	at org.jboss.as.controller.OperationContextImpl.getBasicAuthorizationResponse(OperationContextImpl.java:1153) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
	at org.jboss.as.controller.OperationContextImpl.authorize(OperationContextImpl.java:1055) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
	at org.jboss.as.controller.OperationContextImpl.authorize(OperationContextImpl.java:1015) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
	at org.jboss.as.controller.OperationContextImpl.getResourceRegistration(OperationContextImpl.java:265) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
	at org.jboss.as.controller.operations.global.WriteAttributeHandler.execute(WriteAttributeHandler.java:72) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
	at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:591) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
	at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:469) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
	at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:273) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
	at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:268) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
	at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:272) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
	at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:146) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:174) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$300(ModelControllerClientOperationHandler.java:105) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:125) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:121) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
	at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.7.0_51]
	at javax.security.auth.Subject.doAs(Subject.java:415) [rt.jar:1.7.0_51]
	at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:94) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:121) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
	at org.jboss.as.protocol.mgmt.AbstractMessageHandler$2$1.doExecute(AbstractMessageHandler.java:283) [wildfly-protocol-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
	at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:504) [wildfly-protocol-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_51]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_51]
	at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_51]
	at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.1.Final.jar:2.1.1.Final]
{code}

--
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

From issues at jboss.org  Tue Mar 18 12:44:11 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 18 Mar 2014 12:44:11 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3131) isSensitiveValue of class
 SensitiveVaultExpressionConstraint uses incorrect index in
 java.lang.String.substring method
In-Reply-To: <JIRA.12535307.1395160191000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12535307.1395160191000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12535307.1395160191000.24527.1395161051180@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-3131?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated WFLY-3131:
------------------------------------------

        Bugzilla Update: Perform
    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1077838

    
> isSensitiveValue of class SensitiveVaultExpressionConstraint uses incorrect  index in java.lang.String.substring method
> -----------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-3131
>                 URL: https://issues.jboss.org/browse/WFLY-3131
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>    Affects Versions: 8.0.0.Final
>         Environment: All
>            Reporter: Jay Kumar SenSharma
>            Assignee: Brian Stansberry
>
> The isSensitiveValue(ModelNode value) method of class "org.jboss.as.controller.access.constraint.SensitiveVaultExpressionConstraint" seems to be using the incorrect  index in java.lang.String.substring method.  Which is causing the following exceptions in the logs while executing the following kind of CLI command:
> {code}
> [standalone at localhost:9990 /] /subsystem=logging/periodic-rotating-file-handler=FILE:write-attribute(name=formatter, value="%d{HH:mm:ss,SSS} %-5p [%c] (${jboss.node.name} %t) %s%E%n")
> {
>     "outcome" => "failed",
>     "failure-description" => "JBAS014749: Operation handler failed: String index out of range: -15",
>     "rolled-back" => true
> }
> {code}
> The Exception can be seen as following in the WildFly Logs:
> {code}
> 21:58:04,821 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 25) JBAS014612: Operation ("write-attribute") failed - address: ([
>     ("subsystem" => "logging"),
>     ("periodic-rotating-file-handler" => "FILE")
> ]): java.lang.StringIndexOutOfBoundsException: String index out of range: -15
> 	at java.lang.String.substring(String.java:1911) [rt.jar:1.7.0_51]
> 	at org.jboss.as.controller.access.constraint.SensitiveVaultExpressionConstraint$Factory.isSensitiveValue(SensitiveVaultExpressionConstraint.java:128) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> 	at org.jboss.as.controller.access.constraint.SensitiveVaultExpressionConstraint$Factory.isSensitiveAction(SensitiveVaultExpressionConstraint.java:89) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> 	at org.jboss.as.controller.access.constraint.SensitiveVaultExpressionConstraint$Factory.getRequiredConstraint(SensitiveVaultExpressionConstraint.java:81) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> 	at org.jboss.as.controller.access.rbac.DefaultPermissionFactory.getRequiredPermissions(DefaultPermissionFactory.java:201) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> 	at org.jboss.as.controller.access.permission.ManagementPermissionAuthorizer.authorize(ManagementPermissionAuthorizer.java:100) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> 	at org.jboss.as.controller.access.management.DelegatingConfigurableAuthorizer.authorize(DelegatingConfigurableAuthorizer.java:98) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> 	at org.jboss.as.controller.OperationContextImpl.getBasicAuthorizationResponse(OperationContextImpl.java:1153) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> 	at org.jboss.as.controller.OperationContextImpl.authorize(OperationContextImpl.java:1055) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> 	at org.jboss.as.controller.OperationContextImpl.authorize(OperationContextImpl.java:1015) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> 	at org.jboss.as.controller.OperationContextImpl.getResourceRegistration(OperationContextImpl.java:265) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> 	at org.jboss.as.controller.operations.global.WriteAttributeHandler.execute(WriteAttributeHandler.java:72) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> 	at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:591) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> 	at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:469) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> 	at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:273) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> 	at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:268) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> 	at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:272) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> 	at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:146) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:174) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$300(ModelControllerClientOperationHandler.java:105) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:125) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:121) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> 	at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.7.0_51]
> 	at javax.security.auth.Subject.doAs(Subject.java:415) [rt.jar:1.7.0_51]
> 	at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:94) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:121) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> 	at org.jboss.as.protocol.mgmt.AbstractMessageHandler$2$1.doExecute(AbstractMessageHandler.java:283) [wildfly-protocol-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> 	at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:504) [wildfly-protocol-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_51]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_51]
> 	at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_51]
> 	at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.1.Final.jar:2.1.1.Final]
> {code}

--
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

From issues at jboss.org  Tue Mar 18 12:52:11 2014
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Tue, 18 Mar 2014 12:52:11 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3131) isSensitiveValue of class
 SensitiveVaultExpressionConstraint uses incorrect index in
 java.lang.String.substring method
In-Reply-To: <JIRA.12535307.1395160191000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12535307.1395160191000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12535307.1395160191000.24546.1395161531296@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-3131?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFLY-3131:
-----------------------------------

    Assignee: Jay Kumar SenSharma  (was: Brian Stansberry)

    
> isSensitiveValue of class SensitiveVaultExpressionConstraint uses incorrect  index in java.lang.String.substring method
> -----------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-3131
>                 URL: https://issues.jboss.org/browse/WFLY-3131
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>    Affects Versions: 8.0.0.Final
>         Environment: All
>            Reporter: Jay Kumar SenSharma
>            Assignee: Jay Kumar SenSharma
>
> The isSensitiveValue(ModelNode value) method of class "org.jboss.as.controller.access.constraint.SensitiveVaultExpressionConstraint" seems to be using the incorrect  index in java.lang.String.substring method.  Which is causing the following exceptions in the logs while executing the following kind of CLI command:
> {code}
> [standalone at localhost:9990 /] /subsystem=logging/periodic-rotating-file-handler=FILE:write-attribute(name=formatter, value="%d{HH:mm:ss,SSS} %-5p [%c] (${jboss.node.name} %t) %s%E%n")
> {
>     "outcome" => "failed",
>     "failure-description" => "JBAS014749: Operation handler failed: String index out of range: -15",
>     "rolled-back" => true
> }
> {code}
> The Exception can be seen as following in the WildFly Logs:
> {code}
> 21:58:04,821 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 25) JBAS014612: Operation ("write-attribute") failed - address: ([
>     ("subsystem" => "logging"),
>     ("periodic-rotating-file-handler" => "FILE")
> ]): java.lang.StringIndexOutOfBoundsException: String index out of range: -15
> 	at java.lang.String.substring(String.java:1911) [rt.jar:1.7.0_51]
> 	at org.jboss.as.controller.access.constraint.SensitiveVaultExpressionConstraint$Factory.isSensitiveValue(SensitiveVaultExpressionConstraint.java:128) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> 	at org.jboss.as.controller.access.constraint.SensitiveVaultExpressionConstraint$Factory.isSensitiveAction(SensitiveVaultExpressionConstraint.java:89) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> 	at org.jboss.as.controller.access.constraint.SensitiveVaultExpressionConstraint$Factory.getRequiredConstraint(SensitiveVaultExpressionConstraint.java:81) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> 	at org.jboss.as.controller.access.rbac.DefaultPermissionFactory.getRequiredPermissions(DefaultPermissionFactory.java:201) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> 	at org.jboss.as.controller.access.permission.ManagementPermissionAuthorizer.authorize(ManagementPermissionAuthorizer.java:100) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> 	at org.jboss.as.controller.access.management.DelegatingConfigurableAuthorizer.authorize(DelegatingConfigurableAuthorizer.java:98) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> 	at org.jboss.as.controller.OperationContextImpl.getBasicAuthorizationResponse(OperationContextImpl.java:1153) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> 	at org.jboss.as.controller.OperationContextImpl.authorize(OperationContextImpl.java:1055) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> 	at org.jboss.as.controller.OperationContextImpl.authorize(OperationContextImpl.java:1015) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> 	at org.jboss.as.controller.OperationContextImpl.getResourceRegistration(OperationContextImpl.java:265) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> 	at org.jboss.as.controller.operations.global.WriteAttributeHandler.execute(WriteAttributeHandler.java:72) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> 	at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:591) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> 	at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:469) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> 	at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:273) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> 	at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:268) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> 	at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:272) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> 	at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:146) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:174) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$300(ModelControllerClientOperationHandler.java:105) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:125) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:121) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> 	at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.7.0_51]
> 	at javax.security.auth.Subject.doAs(Subject.java:415) [rt.jar:1.7.0_51]
> 	at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:94) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:121) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> 	at org.jboss.as.protocol.mgmt.AbstractMessageHandler$2$1.doExecute(AbstractMessageHandler.java:283) [wildfly-protocol-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> 	at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:504) [wildfly-protocol-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_51]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_51]
> 	at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_51]
> 	at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.1.Final.jar:2.1.1.Final]
> {code}

--
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

From issues at jboss.org  Tue Mar 18 12:56:10 2014
From: issues at jboss.org (Richard Yang (JIRA))
Date: Tue, 18 Mar 2014 12:56:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3132) jca enlisting datasource
 failed when datasource is first time used or have been idling for a while
In-Reply-To: <JIRA.12535309.1395161769128@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12535309.1395161769128@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12535309.1395161769128.24558.1395161770834@jira02.app.mwc.hst.phx2.redhat.com>

Richard Yang created WFLY-3132:
----------------------------------

             Summary: jca enlisting datasource failed when datasource is first time used or have been idling for a while
                 Key: WFLY-3132
                 URL: https://issues.jboss.org/browse/WFLY-3132
             Project: WildFly
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: JCA
    Affects Versions: 8.0.0.Final
         Environment: Windows 7 64 bits, java ee 7
            Reporter: Richard Yang
            Assignee: Jesper Pedersen


I am not sure this is a bug. I have opened a thread in the jboss community. But so far I have not got a definitive answer. I can reproduce this everytime.
This same code works fine in eap 6.0.

Please see the issue description in the following thread:
https://community.jboss.org/thread/237883

I would like to provide more details if somebody will work on this issue.

Server log and trace level log (jca trace) are attached on that thread.

Thanks.





--
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

From issues at jboss.org  Tue Mar 18 12:58:11 2014
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Tue, 18 Mar 2014 12:58:11 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2733) Create PicketLink extension
	and subsystems
In-Reply-To: <JIRA.12529014.1389283289000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529014.1389283289000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529014.1389283289000.24570.1395161891035@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2733?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFLY-2733:
-----------------------------------

    Fix Version/s: 9.0.0.CR1
                       (was: 8.0.1.Final)

    
> Create PicketLink extension and subsystems
> ------------------------------------------
>
>                 Key: WFLY-2733
>                 URL: https://issues.jboss.org/browse/WFLY-2733
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>            Reporter: Kabir Khan
>            Assignee: Pedro Igor
>             Fix For: 9.0.0.CR1
>
>
> At a minimum IDM and Federation

--
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

From issues at jboss.org  Tue Mar 18 13:00:10 2014
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Tue, 18 Mar 2014 13:00:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2733) Create PicketLink extension
	and subsystems
In-Reply-To: <JIRA.12529014.1389283289000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529014.1389283289000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529014.1389283289000.24576.1395162010720@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2733?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12953942#comment-12953942 ] 

Brian Stansberry commented on WFLY-2733:
----------------------------------------

AFAIK, this is meant for 9; being managed on Kabir's branch for now, so I'm fixing the Fix Version.
                
> Create PicketLink extension and subsystems
> ------------------------------------------
>
>                 Key: WFLY-2733
>                 URL: https://issues.jboss.org/browse/WFLY-2733
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>            Reporter: Kabir Khan
>            Assignee: Pedro Igor
>             Fix For: 9.0.0.CR1
>
>
> At a minimum IDM and Federation

--
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

From issues at jboss.org  Tue Mar 18 13:02:10 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 18 Mar 2014 13:02:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3130) Add a custom RuntimeException
 to add-user utility.
In-Reply-To: <JIRA.12535302.1395159229000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12535302.1395159229000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12535302.1395159229000.24588.1395162130615@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-3130?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12953943#comment-12953943 ] 

RH Bugzilla Integration commented on WFLY-3130:
-----------------------------------------------

Darran Lofthouse <darran.lofthouse at redhat.com> changed the Status of [bug 1062595|https://bugzilla.redhat.com/show_bug.cgi?id=1062595] from ASSIGNED to POST
                
> Add a custom RuntimeException to add-user utility.
> --------------------------------------------------
>
>                 Key: WFLY-3130
>                 URL: https://issues.jboss.org/browse/WFLY-3130
>             Project: WildFly
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 8.0.1.Final
>
>
> The add-user utility uses a RuntimeException to indicate failure in non-interactive mode, this does not look good so should switch it to a custom exception of our own.

--
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

From issues at jboss.org  Tue Mar 18 13:14:11 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 18 Mar 2014 13:14:11 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2950) jboss-cli using
 https-remoting: command not executed if certificate is unrecognised
In-Reply-To: <JIRA.12532472.1392721164000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12532472.1392721164000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12532472.1392721164000.24613.1395162851466@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2950?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated WFLY-2950:
------------------------------------------

        Bugzilla Update: Perform
    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1026418

    
> jboss-cli using https-remoting: command not executed if certificate is unrecognised
> -----------------------------------------------------------------------------------
>
>                 Key: WFLY-2950
>                 URL: https://issues.jboss.org/browse/WFLY-2950
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: CLI, Domain Management
>    Affects Versions: 8.0.0.Final
>         Environment: Windows 7 Pro
>            Reporter: Darren Jones
>            Assignee: Darran Lofthouse
>              Labels: cli, shutdown
>             Fix For: 8.0.1.Final
>
>
> When using the https management interface from jboss-cli, commands passed with a command line option (such as --command=:shutdown) are not executed if the server certificate is unrecognised - even if accepting the certificate [T]emporarily or [P]ermenantly.
> It appears to be due to the CommandContextImpl.handleSSLFailure() method, which calls error("Unable to connect..."). The error() method sets the exitCode to 1. So, when CliLauncher.processCommands() subsequently runs, it sees that the cmdCtx.exitCode is 1 and ignores any commands.
> I guess the handleSSLFailure needs to reset the exitCode to 0 if the user chooses [T] or [P].

--
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

From issues at jboss.org  Tue Mar 18 13:44:10 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 18 Mar 2014 13:44:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2950) jboss-cli using
 https-remoting: command not executed if certificate is unrecognised
In-Reply-To: <JIRA.12532472.1392721164000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12532472.1392721164000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12532472.1392721164000.24706.1395164650784@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2950?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12953951#comment-12953951 ] 

RH Bugzilla Integration commented on WFLY-2950:
-----------------------------------------------

Darran Lofthouse <darran.lofthouse at redhat.com> changed the Status of [bug 1026418|https://bugzilla.redhat.com/show_bug.cgi?id=1026418] from ASSIGNED to POST
                
> jboss-cli using https-remoting: command not executed if certificate is unrecognised
> -----------------------------------------------------------------------------------
>
>                 Key: WFLY-2950
>                 URL: https://issues.jboss.org/browse/WFLY-2950
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: CLI, Domain Management
>    Affects Versions: 8.0.0.Final
>         Environment: Windows 7 Pro
>            Reporter: Darren Jones
>            Assignee: Darran Lofthouse
>              Labels: cli, shutdown
>             Fix For: 8.0.1.Final
>
>
> When using the https management interface from jboss-cli, commands passed with a command line option (such as --command=:shutdown) are not executed if the server certificate is unrecognised - even if accepting the certificate [T]emporarily or [P]ermenantly.
> It appears to be due to the CommandContextImpl.handleSSLFailure() method, which calls error("Unable to connect..."). The error() method sets the exitCode to 1. So, when CliLauncher.processCommands() subsequently runs, it sees that the cmdCtx.exitCode is 1 and ignores any commands.
> I guess the handleSSLFailure needs to reset the exitCode to 0 if the user chooses [T] or [P].

--
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

From issues at jboss.org  Tue Mar 18 13:44:10 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 18 Mar 2014 13:44:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2538) Certificate acceptance
 causing command entered on starting the CLI to be skipped.
In-Reply-To: <JIRA.12525580.1384872293000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12525580.1384872293000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12525580.1384872293000.24708.1395164650891@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2538?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12953952#comment-12953952 ] 

RH Bugzilla Integration commented on WFLY-2538:
-----------------------------------------------

Darran Lofthouse <darran.lofthouse at redhat.com> changed the Status of [bug 1026418|https://bugzilla.redhat.com/show_bug.cgi?id=1026418] from ASSIGNED to POST
                
> Certificate acceptance causing command entered on starting the CLI to be skipped.
> ---------------------------------------------------------------------------------
>
>                 Key: WFLY-2538
>                 URL: https://issues.jboss.org/browse/WFLY-2538
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: CLI
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 8.0.0.CR1
>
>
> e.g.
> {noformat}
> ./jboss-cli.sh -c shutdown
> Accept certificate? [N]o, [T]emporarily, [P]ermenantly : T
> {noformat}
> The shutdown command is not executed.

--
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

From issues at jboss.org  Tue Mar 18 14:10:11 2014
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 18 Mar 2014 14:10:11 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3133) Misleading error message for
 add-user username requirements.
In-Reply-To: <JIRA.12535314.1395166113656@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12535314.1395166113656@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12535314.1395166113656.24738.1395166211197@jira02.app.mwc.hst.phx2.redhat.com>

Darran Lofthouse created WFLY-3133:
--------------------------------------

             Summary: Misleading error message for add-user username requirements.
                 Key: WFLY-3133
                 URL: https://issues.jboss.org/browse/WFLY-3133
             Project: WildFly
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Domain Management
    Affects Versions: 8.0.0.Final
            Reporter: Darran Lofthouse
            Assignee: Darran Lofthouse
             Fix For: 8.0.1.Final


The current error message is: -

{code}
JBAS015239: Only alpha/numeric usernames accepted.
{code}

However a small set of symbols are allowed.

--
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

From issues at jboss.org  Tue Mar 18 14:10:11 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 18 Mar 2014 14:10:11 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3133) Misleading error message for
 add-user username requirements.
In-Reply-To: <JIRA.12535314.1395166113000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12535314.1395166113000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12535314.1395166113000.24745.1395166211651@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-3133?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated WFLY-3133:
------------------------------------------

        Bugzilla Update: Perform
    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1062611

    
> Misleading error message for add-user username requirements.
> ------------------------------------------------------------
>
>                 Key: WFLY-3133
>                 URL: https://issues.jboss.org/browse/WFLY-3133
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>    Affects Versions: 8.0.0.Final
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 8.0.1.Final
>
>
> The current error message is: -
> {code}
> JBAS015239: Only alpha/numeric usernames accepted.
> {code}
> However a small set of symbols are allowed.

--
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

From issues at jboss.org  Tue Mar 18 14:38:11 2014
From: issues at jboss.org (Jesper Pedersen (JIRA))
Date: Tue, 18 Mar 2014 14:38:11 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3132) jca enlisting datasource
 failed when datasource is first time used or have been idling for a while
In-Reply-To: <JIRA.12535309.1395161769000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12535309.1395161769000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12535309.1395161769000.24776.1395167891088@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-3132?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jesper Pedersen closed WFLY-3132.
---------------------------------

    Resolution: Rejected

    
> jca enlisting datasource failed when datasource is first time used or have been idling for a while
> --------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-3132
>                 URL: https://issues.jboss.org/browse/WFLY-3132
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JCA
>    Affects Versions: 8.0.0.Final
>         Environment: Windows 7 64 bits, java ee 7
>            Reporter: Richard Yang
>            Assignee: Jesper Pedersen
>
> I am not sure this is a bug. I have opened a thread in the jboss community. But so far I have not got a definitive answer. I can reproduce this everytime.
> This same code works fine in eap 6.0.
> Please see the issue description in the following thread:
> https://community.jboss.org/thread/237883
> I would like to provide more details if somebody will work on this issue.
> Server log and trace level log (jca trace) are attached on that thread.
> Thanks.

--
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

From issues at jboss.org  Tue Mar 18 14:52:10 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 18 Mar 2014 14:52:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3133) Misleading error message for
 add-user username requirements.
In-Reply-To: <JIRA.12535314.1395166113000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12535314.1395166113000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12535314.1395166113000.24789.1395168730757@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-3133?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12953969#comment-12953969 ] 

RH Bugzilla Integration commented on WFLY-3133:
-----------------------------------------------

Darran Lofthouse <darran.lofthouse at redhat.com> changed the Status of [bug 1062611|https://bugzilla.redhat.com/show_bug.cgi?id=1062611] from ASSIGNED to POST
                
> Misleading error message for add-user username requirements.
> ------------------------------------------------------------
>
>                 Key: WFLY-3133
>                 URL: https://issues.jboss.org/browse/WFLY-3133
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>    Affects Versions: 8.0.0.Final
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 8.0.1.Final
>
>
> The current error message is: -
> {code}
> JBAS015239: Only alpha/numeric usernames accepted.
> {code}
> However a small set of symbols are allowed.

--
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

From issues at jboss.org  Tue Mar 18 16:18:11 2014
From: issues at jboss.org (Sidney Zurch (JIRA))
Date: Tue, 18 Mar 2014 16:18:11 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-794)
 javax.naming.NameNotFoundException: rmi://127.0.0.1:1090/jmxrmi thrown when
 creating MBeanServerConnection
In-Reply-To: <JIRA.12488795.1365437999000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12488795.1365437999000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12488795.1365437999000.24919.1395173891271@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-794?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12953995#comment-12953995 ] 

Sidney Zurch commented on WFLY-794:
-----------------------------------

Not fixed in 8.0.0.Final.  WildFly deployment requires workaround from AS7-2138.

Rmi URL: service:jmx:rmi://app.xyz.com:28686/jndi/rmi://app.xyz.com:28686/jmxrmi

If workaround is applied app deploys without error.

Error trace without workaround below:
{code}
Caused by: java.io.IOException: Failed to retrieve RMIServer stub: javax.naming.NameNotFoundException: rmi://app.xyz.com:28686/jmxrmi -- service jboss.naming.context.java.rmi:."app.xyz.com:28686".jmxrmi
   at javax.management.remote.rmi.RMIConnector.connect(RMIConnector.java:369) [rt.jar:1.7.0_51]
   at javax.management.remote.JMXConnectorFactory.connect(JMXConnectorFactory.java:268) [rt.jar:1.7.0_51]
   at org.apache.activemq.web.RemoteJMXBrokerFacade.createConnection(RemoteJMXBrokerFacade.java:155) [activemq-web-5.4.3.jar:5.4.3]
   ... 60 more
Caused by: javax.naming.NameNotFoundException: rmi://app.xyz.com:28686/jmxrmi -- service jboss.naming.context.java.rmi:."app.xyz.com:28686".jmxrmi
   at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:104)
   at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:202)
   at org.jboss.as.naming.InitialContext$DefaultInitialContext.lookup(InitialContext.java:233)
   at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:188)
   at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:184)
   at javax.naming.InitialContext.lookup(InitialContext.java:411) [rt.jar:1.7.0_51]
   at javax.naming.InitialContext.lookup(InitialContext.java:411) [rt.jar:1.7.0_51]
   at javax.management.remote.rmi.RMIConnector.findRMIServerJNDI(RMIConnector.java:1936) [rt.jar:1.7.0_51]
   at javax.management.remote.rmi.RMIConnector.findRMIServer(RMIConnector.java:1903) [rt.jar:1.7.0_51]
   at javax.management.remote.rmi.RMIConnector.connect(RMIConnector.java:286) [rt.jar:1.7.0_51]
   ... 62 more
{code}
                
> javax.naming.NameNotFoundException: rmi://127.0.0.1:1090/jmxrmi thrown when creating MBeanServerConnection
> ----------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-794
>                 URL: https://issues.jboss.org/browse/WFLY-794
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JMX
>            Reporter: Alex Corvino
>            Assignee: Darran Lofthouse
>              Labels: investigation_required
>         Attachments: jmx-test.jar, JmxClient.java, JMXConnectionBean.java, JmxServer.java
>
>
> When trying to create a MBeanServerConnection to a NON-JBoss application from within an EJB a "javax.naming.NameNotFoundException" is thrown. 
> Steps to reproduce:
> Set up a stand-alone application that exposes an MBean. (ActiveMQ will work in this case.)
> Modify the attached JMXConnectionBean.java to connect to the ActiveMQ instance.
> Deploy the bean. A NameNotFoundException will be thrown.
> I've seen this behavior in 7.1.1.Final, 7.1.2.Final (EAP), 7.1.3.Final (EAP), EAP 6.1.0.Alpha (7.2.0.Final). 
> Note that this behavior is NOT seen when connecting to another JBoss server. 
> Full stack trace:
> {code} 
> Caused by: java.io.IOException: Failed to retrieve RMIServer stub: javax.naming.NameNotFoundException: rmi://127.0.0.1:1090/jmxrmi -- service jboss.naming.context.java.rmi:."127.0.0.1:1090".jmxrmi
> 	at javax.management.remote.rmi.RMIConnector.connect(RMIConnector.java:340) [:1.6.0_26]
> 	at javax.management.remote.JMXConnectorFactory.connect(JMXConnectorFactory.java:248) [:1.6.0_26]
> 	at com.example.JMXConnectionBean.init(JMXConnectionBean.java:28)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [:1.6.0_26]
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) [:1.6.0_26]
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [:1.6.0_26]
> 	at java.lang.reflect.Method.invoke(Method.java:597) [:1.6.0_26]
> 	at org.jboss.as.ee.component.ManagedReferenceLifecycleMethodInterceptor.processInvocation(ManagedReferenceLifecycleMethodInterceptor.java:70)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287) [jboss-invocation-1.1.0.Final.jar:1.1.0.Final]
> 	at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53) [jboss-invocation-1.1.0.Final.jar:1.1.0.Final]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287) [jboss-invocation-1.1.0.Final.jar:1.1.0.Final]
> 	at org.jboss.as.ee.component.ManagedReferenceInterceptor.processInvocation(ManagedReferenceInterceptor.java:53)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287) [jboss-invocation-1.1.0.Final.jar:1.1.0.Final]
> 	at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53) [jboss-invocation-1.1.0.Final.jar:1.1.0.Final]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287) [jboss-invocation-1.1.0.Final.jar:1.1.0.Final]
> 	at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:44)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287) [jboss-invocation-1.1.0.Final.jar:1.1.0.Final]
> 	at org.jboss.as.ejb3.component.session.SessionInvocationContextInterceptor$CustomSessionInvocationContext.proceed(SessionInvocationContextInterceptor.java:126)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:211)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.requiresNew(CMTTxInterceptor.java:313)
> 	at org.jboss.as.ejb3.tx.SingletonLifecycleCMTTxInterceptor.processInvocation(SingletonLifecycleCMTTxInterceptor.java:56)
> 	at org.jboss.as.ejb3.tx.SingletonLifecycleCMTTxInterceptor.processInvocation(SingletonLifecycleCMTTxInterceptor.java:42)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287) [jboss-invocation-1.1.0.Final.jar:1.1.0.Final]
> 	at org.jboss.as.ejb3.component.session.SessionInvocationContextInterceptor.processInvocation(SessionInvocationContextInterceptor.java:71)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287) [jboss-invocation-1.1.0.Final.jar:1.1.0.Final]
> 	at org.jboss.as.ee.component.TCCLInterceptor.processInvocation(TCCLInterceptor.java:45)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287) [jboss-invocation-1.1.0.Final.jar:1.1.0.Final]
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) [jboss-invocation-1.1.0.Final.jar:1.1.0.Final]
> 	at org.jboss.as.ee.component.BasicComponent.constructComponentInstance(BasicComponent.java:152)
> 	... 9 more
> Caused by: javax.naming.NameNotFoundException: rmi://127.0.0.1:1090/jmxrmi -- service jboss.naming.context.java.rmi:."127.0.0.1:1090".jmxrmi
> 	at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:87)
> 	at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:173)
> 	at org.jboss.as.naming.InitialContext.lookup(InitialContext.java:47)
> 	at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:209)
> 	at javax.naming.InitialContext.lookup(InitialContext.java:392) [:1.6.0_26]
> 	at javax.management.remote.rmi.RMIConnector.findRMIServerJNDI(RMIConnector.java:1888) [:1.6.0_26]
> 	at javax.management.remote.rmi.RMIConnector.findRMIServer(RMIConnector.java:1858) [:1.6.0_26]
> 	at javax.management.remote.rmi.RMIConnector.connect(RMIConnector.java:257) [:1.6.0_26]
> 	... 37 more
> {code}

--
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

From issues at jboss.org  Tue Mar 18 16:48:10 2014
From: issues at jboss.org (Paul Ferraro (JIRA))
Date: Tue, 18 Mar 2014 16:48:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3134) Upgrade Infinispan to
	6.0.2.Final
In-Reply-To: <JIRA.12535335.1395175678683@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12535335.1395175678683@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12535335.1395175678683.24963.1395175690596@jira02.app.mwc.hst.phx2.redhat.com>

Paul Ferraro created WFLY-3134:
----------------------------------

             Summary: Upgrade Infinispan to 6.0.2.Final
                 Key: WFLY-3134
                 URL: https://issues.jboss.org/browse/WFLY-3134
             Project: WildFly
          Issue Type: Component  Upgrade
      Security Level: Public (Everyone can see)
          Components: Clustering
    Affects Versions: 8.0.0.Final
            Reporter: Paul Ferraro
            Assignee: Paul Ferraro
             Fix For: 8.0.1.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

From issues at jboss.org  Tue Mar 18 18:14:10 2014
From: issues at jboss.org (James Perkins (JIRA))
Date: Tue, 18 Mar 2014 18:14:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3135) ARJUNA016087 warning message
 in batch jobs when committing transactions
In-Reply-To: <JIRA.12535338.1395180787959@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12535338.1395180787959@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12535338.1395180787959.25002.1395180850586@jira02.app.mwc.hst.phx2.redhat.com>

James Perkins created WFLY-3135:
-----------------------------------

             Summary: ARJUNA016087 warning message in batch jobs when committing transactions
                 Key: WFLY-3135
                 URL: https://issues.jboss.org/browse/WFLY-3135
             Project: WildFly
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Batch
    Affects Versions: 8.0.0.Final
            Reporter: James Perkins
            Assignee: James Perkins


Batch jobs are getting a warning message printing after a commit is attempted.

{code}
13:52:15,270 WARN  [com.arjuna.ats.jta] (batch-batch - 3) ARJUNA016087: TransactionImple.delistResource - unknown resource
{code}

Turning on trace logging gives the following log messages
{code}
13:52:15,252 INFO  [com.test.cms.batch.partition.mapper.File0591Mapper] (batch-batch - 1) Generation the partitions.....
13:52:15,255 TRACE [com.arjuna.ats.jta] (batch-batch - 2) BaseTransaction.begin
13:52:15,255 INFO  [com.test.cms.batch.reader.File0591Reader] (batch-batch - 2) Reader: OPEN
13:52:15,256 TRACE [com.arjuna.ats.jta] (batch-batch - 2) TransactionImple.getStatus: javax.transaction.Status.STATUS_ACTIVE
13:52:15,256 TRACE [com.arjuna.ats.jta] (batch-batch - 1) BaseTransaction.begin
13:52:15,256 TRACE [com.arjuna.ats.jta] (batch-batch - 2) TransactionSynchronizationRegistryImple.getTransactionKey
13:52:15,256 TRACE [com.arjuna.ats.jta] (batch-batch - 2) TransactionSynchronizationRegistryImple.getResource
13:52:15,256 TRACE [com.arjuna.ats.jta] (batch-batch - 3) BaseTransaction.begin
13:52:15,256 TRACE [com.arjuna.ats.jta] (batch-batch - 2) TransactionImple.getStatus: javax.transaction.Status.STATUS_ACTIVE
13:52:15,256 TRACE [com.arjuna.ats.jta] (batch-batch - 2) TransactionSynchronizationRegistryImple.putResource
13:52:15,256 TRACE [com.arjuna.ats.jta] (batch-batch - 2) TransactionImple.getStatus: javax.transaction.Status.STATUS_ACTIVE
13:52:15,256 INFO  [com.test.cms.batch.reader.File0591Reader] (batch-batch - 3) Reader: OPEN
13:52:15,256 TRACE [com.arjuna.ats.jta] (batch-batch - 2) TransactionSynchronizationRegistryImple.getTransactionKey
13:52:15,257 TRACE [com.arjuna.ats.jta] (batch-batch - 2) TransactionSynchronizationRegistryImple.getTransactionKey
13:52:15,257 TRACE [com.arjuna.ats.jta] (batch-batch - 2) TransactionSynchronizationRegistryImple.getResource
13:52:15,257 TRACE [com.arjuna.ats.jta] (batch-batch - 3) TransactionImple.getStatus: javax.transaction.Status.STATUS_ACTIVE
13:52:15,257 TRACE [com.arjuna.ats.jta] (batch-batch - 2) TransactionImple.getStatus: javax.transaction.Status.STATUS_ACTIVE
13:52:15,257 TRACE [com.arjuna.ats.jta] (batch-batch - 3) TransactionSynchronizationRegistryImple.getTransactionKey
13:52:15,257 TRACE [com.arjuna.ats.jta] (batch-batch - 2) TransactionSynchronizationRegistryImple.getResource
13:52:15,257 TRACE [com.arjuna.ats.jta] (batch-batch - 3) TransactionSynchronizationRegistryImple.getTransactionKey
13:52:15,257 TRACE [com.arjuna.ats.jta] (batch-batch - 2) TransactionImple.getStatus: javax.transaction.Status.STATUS_ACTIVE
13:52:15,257 TRACE [com.arjuna.ats.jta] (batch-batch - 3) TransactionSynchronizationRegistryImple.getResource
13:52:15,259 TRACE [com.arjuna.ats.jta] (batch-batch - 3) TransactionImple.getStatus: javax.transaction.Status.STATUS_ACTIVE
13:52:15,259 TRACE [com.arjuna.ats.jta] (batch-batch - 3) TransactionSynchronizationRegistryImple.getTransactionKey
13:52:15,259 TRACE [com.arjuna.ats.jta] (batch-batch - 3) TransactionSynchronizationRegistryImple.getResource
13:52:15,259 TRACE [com.arjuna.ats.jta] (batch-batch - 3) TransactionImple.getStatus: javax.transaction.Status.STATUS_ACTIVE
13:52:15,259 TRACE [com.arjuna.ats.jta] (batch-batch - 3) TransactionSynchronizationRegistryImple.putResource
13:52:15,260 TRACE [com.arjuna.ats.jta] (batch-batch - 3) TransactionImple.getStatus: javax.transaction.Status.STATUS_ACTIVE
13:52:15,260 TRACE [com.arjuna.ats.jta] (batch-batch - 2) TransactionSynchronizationRegistryImple.getTransactionKey
13:52:15,260 TRACE [com.arjuna.ats.jta] (batch-batch - 3) TransactionSynchronizationRegistryImple.getResource
13:52:15,260 TRACE [com.arjuna.ats.jta] (batch-batch - 2) TransactionSynchronizationRegistryImple.getResource
13:52:15,260 TRACE [com.arjuna.ats.jta] (batch-batch - 3) TransactionImple.getStatus: javax.transaction.Status.STATUS_ACTIVE
13:52:15,260 TRACE [com.arjuna.ats.jta] (batch-batch - 2) TransactionImple.getStatus: javax.transaction.Status.STATUS_ACTIVE
13:52:15,262 TRACE [com.arjuna.ats.jta] (batch-batch - 2) TransactionSynchronizationRegistryImple.getResource
13:52:15,262 TRACE [com.arjuna.ats.jta] (batch-batch - 2) TransactionImple.getStatus: javax.transaction.Status.STATUS_ACTIVE
13:52:15,262 TRACE [com.arjuna.ats.jta] (batch-batch - 2) TransactionSynchronizationRegistryImple.putResource
13:52:15,262 TRACE [com.arjuna.ats.jta] (batch-batch - 2) TransactionImple.getStatus: javax.transaction.Status.STATUS_ACTIVE
13:52:15,262 TRACE [com.arjuna.ats.jta] (batch-batch - 2) TransactionImple.getStatus: javax.transaction.Status.STATUS_ACTIVE
13:52:15,263 TRACE [com.arjuna.ats.jta] (batch-batch - 2) TransactionSynchronizationRegistryImple.registerInterposedSynchronization
13:52:15,263 TRACE [com.arjuna.ats.jta] (batch-batch - 3) TransactionSynchronizationRegistryImple.getTransactionKey
13:52:15,263 TRACE [com.arjuna.ats.jta] (batch-batch - 2) TransactionImple.getStatus: javax.transaction.Status.STATUS_ACTIVE
13:52:15,263 TRACE [com.arjuna.ats.jta] (batch-batch - 3) TransactionSynchronizationRegistryImple.getResource
13:52:15,263 TRACE [com.arjuna.ats.jta] (batch-batch - 2) TransactionImple.enlistResource ( LocalXAResourceImpl at 61568070[connectionListener=35219b06 connectionManager=760a6afc warned=false currentXid=null productName=H2 productVersion=1.3.173 (2013-07-28) jndiName=java:/ISSUER_DS] )
13:52:15,263 TRACE [com.arjuna.ats.jta] (batch-batch - 3) TransactionImple.getStatus: javax.transaction.Status.STATUS_ACTIVE
13:52:15,263 TRACE [com.arjuna.ats.jta] (batch-batch - 2) TransactionImple.getStatus: javax.transaction.Status.STATUS_ACTIVE
13:52:15,263 TRACE [com.arjuna.ats.jta] (batch-batch - 3) TransactionSynchronizationRegistryImple.getResource
13:52:15,263 TRACE [com.arjuna.ats.jta] (batch-batch - 3) TransactionImple.getStatus: javax.transaction.Status.STATUS_ACTIVE
13:52:15,264 TRACE [com.arjuna.ats.jta] (batch-batch - 2) TransactionImple.getStatus: javax.transaction.Status.STATUS_ACTIVE
13:52:15,264 TRACE [com.arjuna.ats.jta] (batch-batch - 3) TransactionSynchronizationRegistryImple.putResource
13:52:15,264 TRACE [com.arjuna.ats.jta] (batch-batch - 2) TransactionImple.getStatus: javax.transaction.Status.STATUS_ACTIVE
13:52:15,264 TRACE [com.arjuna.ats.jta] (batch-batch - 3) TransactionImple.getStatus: javax.transaction.Status.STATUS_ACTIVE
13:52:15,264 TRACE [com.arjuna.ats.jta] (batch-batch - 3) TransactionImple.getStatus: javax.transaction.Status.STATUS_ACTIVE
13:52:15,264 TRACE [com.arjuna.ats.jta] (batch-batch - 2) BaseTransaction.commit
13:52:15,264 TRACE [com.arjuna.ats.jta] (batch-batch - 3) TransactionSynchronizationRegistryImple.registerInterposedSynchronization
13:52:15,264 TRACE [com.arjuna.ats.jta] (batch-batch - 2) TransactionImple.commitAndDisassociate
13:52:15,264 TRACE [com.arjuna.ats.jta] (batch-batch - 3) TransactionImple.getStatus: javax.transaction.Status.STATUS_ACTIVE
13:52:15,265 TRACE [com.arjuna.ats.jta] (batch-batch - 2) SynchronizationImple.beforeCompletion
13:52:15,265 TRACE [com.arjuna.ats.jta] (batch-batch - 3) TransactionImple.enlistResource ( LocalXAResourceImpl at 4d090bc5[connectionListener=5a6417cc connectionManager=760a6afc warned=false currentXid=null productName=H2 productVersion=1.3.173 (2013-07-28) jndiName=java:/ISSUER_DS] )
13:52:15,265 TRACE [com.arjuna.ats.jta] (batch-batch - 2) TransactionImple.getStatus: javax.transaction.Status.STATUS_ACTIVE
13:52:15,265 TRACE [com.arjuna.ats.jta] (batch-batch - 3) TransactionImple.getStatus: javax.transaction.Status.STATUS_ACTIVE
13:52:15,265 TRACE [com.arjuna.ats.jta] (batch-batch - 2) TransactionImple.getStatus: javax.transaction.Status.STATUS_ACTIVE
13:52:15,265 TRACE [com.arjuna.ats.jta] (batch-batch - 2) TransactionImple.delistResource ( LocalXAResourceImpl at 61568070[connectionListener=35219b06 connectionManager=760a6afc warned=false currentXid=< formatId=131077, gtrid_length=29, bqual_length=36, tx_uid=0:ffff7f000001:5c4cbb49:5328b03a:42, node_name=1, branch_uid=0:ffff7f000001:5c4cbb49:5328b03a:46, subordinatenodename=null, eis_name=java:/ISSUER_DS > productName=H2 productVersion=1.3.173 (2013-07-28) jndiName=java:/ISSUER_DS], 67108864 )
13:52:15,265 TRACE [com.arjuna.ats.jta] (batch-batch - 3) TransactionImple.getStatus: javax.transaction.Status.STATUS_ACTIVE
13:52:15,265 TRACE [com.arjuna.ats.jta] (batch-batch - 2) TransactionImple.getStatus: javax.transaction.Status.STATUS_ACTIVE
13:52:15,265 TRACE [com.arjuna.ats.jta] (batch-batch - 3) TransactionImple.getStatus: javax.transaction.Status.STATUS_ACTIVE
13:52:15,266 TRACE [com.arjuna.ats.jta] (batch-batch - 2) SynchronizationImple.afterCompletion
13:52:15,266 TRACE [com.arjuna.ats.jta] (batch-batch - 3) BaseTransaction.commit
13:52:15,266 TRACE [com.arjuna.ats.jta] (batch-batch - 2) BaseTransaction.begin
13:52:15,266 TRACE [com.arjuna.ats.jta] (batch-batch - 3) TransactionImple.commitAndDisassociate
13:52:15,266 INFO  [com.test.cms.batch.reader.File0591Reader] (batch-batch - 2) Reader: READ ITEMS
13:52:15,266 TRACE [com.arjuna.ats.jta] (batch-batch - 3) SynchronizationImple.beforeCompletion
13:52:15,266 TRACE [com.arjuna.ats.jta] (batch-batch - 3) TransactionImple.getStatus: javax.transaction.Status.STATUS_ACTIVE
13:52:15,267 TRACE [com.arjuna.ats.jta] (batch-batch - 3) TransactionImple.getStatus: javax.transaction.Status.STATUS_ACTIVE
13:52:15,267 TRACE [com.arjuna.ats.jta] (batch-batch - 3) TransactionImple.delistResource ( LocalXAResourceImpl at 4d090bc5[connectionListener=5a6417cc connectionManager=760a6afc warned=false currentXid=< formatId=131077, gtrid_length=29, bqual_length=36, tx_uid=0:ffff7f000001:5c4cbb49:5328b03a:44, node_name=1, branch_uid=0:ffff7f000001:5c4cbb49:5328b03a:48, subordinatenodename=null, eis_name=java:/ISSUER_DS > productName=H2 productVersion=1.3.173 (2013-07-28) jndiName=java:/ISSUER_DS], 67108864 )
13:52:15,267 INFO  [com.test.cms.batch.writer.FileWriterTest] (batch-batch - 2) Write item:VALUE_PART_1
13:52:15,267 TRACE [com.arjuna.ats.jta] (batch-batch - 3) TransactionImple.getStatus: javax.transaction.Status.STATUS_ACTIVE
13:52:15,267 TRACE [com.arjuna.ats.jta] (batch-batch - 2) BaseTransaction.commit
13:52:15,267 TRACE [com.arjuna.ats.jta] (batch-batch - 2) TransactionImple.commitAndDisassociate
13:52:15,267 TRACE [com.arjuna.ats.jta] (batch-batch - 3) SynchronizationImple.afterCompletion
13:52:15,267 TRACE [com.arjuna.ats.jta] (batch-batch - 2) BaseTransaction.begin
13:52:15,267 TRACE [com.arjuna.ats.jta] (batch-batch - 3) BaseTransaction.begin
13:52:15,268 INFO  [com.test.cms.batch.reader.File0591Reader] (batch-batch - 2) Reader: READ ITEMS
13:52:15,268 INFO  [com.test.cms.batch.reader.File0591Reader] (batch-batch - 3) Reader: READ ITEMS
13:52:15,268 TRACE [com.arjuna.ats.jta] (batch-batch - 2) BaseTransaction.commit
13:52:15,268 TRACE [com.arjuna.ats.jta] (batch-batch - 2) TransactionImple.commitAndDisassociate
13:52:15,268 INFO  [com.test.cms.batch.writer.FileWriterTest] (batch-batch - 3) Write item:VALUE_PART_2
13:52:15,268 TRACE [com.arjuna.ats.jta] (batch-batch - 2) BaseTransaction.begin
13:52:15,268 TRACE [com.arjuna.ats.jta] (batch-batch - 3) BaseTransaction.commit
13:52:15,268 INFO  [com.test.cms.batch.reader.File0591Reader] (batch-batch - 2) Reader: close
13:52:15,268 TRACE [com.arjuna.ats.jta] (batch-batch - 3) TransactionImple.commitAndDisassociate
13:52:15,268 TRACE [com.arjuna.ats.jta] (batch-batch - 2) TransactionImple.getStatus: javax.transaction.Status.STATUS_ACTIVE
13:52:15,268 TRACE [com.arjuna.ats.jta] (batch-batch - 3) BaseTransaction.begin
13:52:15,268 TRACE [com.arjuna.ats.jta] (batch-batch - 2) TransactionImple.getStatus: javax.transaction.Status.STATUS_ACTIVE
13:52:15,269 TRACE [com.arjuna.ats.jta] (batch-batch - 2) TransactionImple.delistResource ( LocalXAResourceImpl at 61568070[connectionListener=35219b06 connectionManager=760a6afc warned=false currentXid=null productName=H2 productVersion=1.3.173 (2013-07-28) jndiName=java:/ISSUER_DS], 67108864 )
13:52:15,269 INFO  [com.test.cms.batch.reader.File0591Reader] (batch-batch - 3) Reader: READ ITEMS
13:52:15,269 TRACE [com.arjuna.ats.jta] (batch-batch - 2) TransactionImple.getStatus: javax.transaction.Status.STATUS_ACTIVE
13:52:15,269 TRACE [com.arjuna.ats.jta] (batch-batch - 3) BaseTransaction.commit
13:52:15,269 WARN  [com.arjuna.ats.jta] (batch-batch - 2) ARJUNA016087: TransactionImple.delistResource - unknown resource
13:52:15,269 TRACE [com.arjuna.ats.jta] (batch-batch - 3) TransactionImple.commitAndDisassociate
13:52:15,269 TRACE [com.arjuna.ats.jta] (batch-batch - 2) BaseTransaction.commit
13:52:15,269 TRACE [com.arjuna.ats.jta] (batch-batch - 2) TransactionImple.commitAndDisassociate
13:52:15,269 TRACE [com.arjuna.ats.jta] (batch-batch - 3) BaseTransaction.begin
13:52:15,269 INFO  [com.test.cms.batch.reader.File0591Reader] (batch-batch - 2) Reader: close
13:52:15,269 INFO  [com.test.cms.batch.reader.File0591Reader] (batch-batch - 3) Reader: close
13:52:15,270 TRACE [com.arjuna.ats.jta] (batch-batch - 3) TransactionImple.getStatus: javax.transaction.Status.STATUS_ACTIVE
13:52:15,270 TRACE [com.arjuna.ats.jta] (batch-batch - 3) TransactionImple.getStatus: javax.transaction.Status.STATUS_ACTIVE
13:52:15,270 TRACE [com.arjuna.ats.jta] (batch-batch - 3) TransactionImple.delistResource ( LocalXAResourceImpl at 4d090bc5[connectionListener=5a6417cc connectionManager=760a6afc warned=false currentXid=null productName=H2 productVersion=1.3.173 (2013-07-28) jndiName=java:/ISSUER_DS], 67108864 )
13:52:15,270 TRACE [com.arjuna.ats.jta] (batch-batch - 3) TransactionImple.getStatus: javax.transaction.Status.STATUS_ACTIVE
13:52:15,270 WARN  [com.arjuna.ats.jta] (batch-batch - 3) ARJUNA016087: TransactionImple.delistResource - unknown resource
13:52:15,270 TRACE [com.arjuna.ats.jta] (batch-batch - 3) BaseTransaction.commit
13:52:15,270 TRACE [com.arjuna.ats.jta] (batch-batch - 3) TransactionImple.commitAndDisassociate
13:52:15,270 INFO  [com.test.cms.batch.reader.File0591Reader] (batch-batch - 3) Reader: close
13:52:15,270 TRACE [com.arjuna.ats.jta] (batch-batch - 1) BaseTransaction.commit
13:52:15,271 TRACE [com.arjuna.ats.jta] (batch-batch - 1) TransactionImple.commitAndDisassociate
{code}

--
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

From issues at jboss.org  Tue Mar 18 18:32:10 2014
From: issues at jboss.org (Paul Ferraro (JIRA))
Date: Tue, 18 Mar 2014 18:32:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3136) SRV 7.7.2 non-compliance
In-Reply-To: <JIRA.12535344.1395181848469@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12535344.1395181848469@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12535344.1395181848469.25019.1395181930723@jira02.app.mwc.hst.phx2.redhat.com>

Paul Ferraro created WFLY-3136:
----------------------------------

             Summary: SRV 7.7.2 non-compliance
                 Key: WFLY-3136
                 URL: https://issues.jboss.org/browse/WFLY-3136
             Project: WildFly
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Clustering
    Affects Versions: 8.0.0.Final
            Reporter: Paul Ferraro
            Assignee: Paul Ferraro
             Fix For: 8.0.1.Final


>From SRV 7.7.2: Distributed Environments
Within an application marked as distributable, all requests that are part of a session must be handled by one JVM at a time.

Our default configuration using PESSIMISTIC locking.  However, Infinispan only acquires locks on cache write operations.  This only prevents concurrent writes to a session.  We need to make sure both reads and writes to a session use cluster exclusive access, by default at least.

--
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

From issues at jboss.org  Tue Mar 18 18:32:10 2014
From: issues at jboss.org (Paul Ferraro (JIRA))
Date: Tue, 18 Mar 2014 18:32:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3136) SRV 7.7.2 non-compliance
In-Reply-To: <JIRA.12535344.1395181848000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12535344.1395181848000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12535344.1395181848000.25024.1395181930954@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-3136?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Paul Ferraro updated WFLY-3136:
-------------------------------

    Description: 
>From SRV 7.7.2: Distributed Environments
Within an application marked as distributable, all requests that are part of a session must be handled by one JVM at a time.

Our default configuration for the Infinispan cache used for web sessions uses PESSIMISTIC locking.  However, Infinispan only acquires locks on cache write operations.  This only prevents concurrent writes to a session.  We need to make sure both reads and writes to a session use cluster exclusive access, by default at least.

  was:
>From SRV 7.7.2: Distributed Environments
Within an application marked as distributable, all requests that are part of a session must be handled by one JVM at a time.

Our default configuration using PESSIMISTIC locking.  However, Infinispan only acquires locks on cache write operations.  This only prevents concurrent writes to a session.  We need to make sure both reads and writes to a session use cluster exclusive access, by default at least.


    
> SRV 7.7.2 non-compliance
> ------------------------
>
>                 Key: WFLY-3136
>                 URL: https://issues.jboss.org/browse/WFLY-3136
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Clustering
>    Affects Versions: 8.0.0.Final
>            Reporter: Paul Ferraro
>            Assignee: Paul Ferraro
>             Fix For: 8.0.1.Final
>
>
> From SRV 7.7.2: Distributed Environments
> Within an application marked as distributable, all requests that are part of a session must be handled by one JVM at a time.
> Our default configuration for the Infinispan cache used for web sessions uses PESSIMISTIC locking.  However, Infinispan only acquires locks on cache write operations.  This only prevents concurrent writes to a session.  We need to make sure both reads and writes to a session use cluster exclusive access, by default at least.

--
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

From issues at jboss.org  Tue Mar 18 18:32:11 2014
From: issues at jboss.org (Paul Ferraro (JIRA))
Date: Tue, 18 Mar 2014 18:32:11 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3136) SRV 7.7.2 non-compliance
In-Reply-To: <JIRA.12535344.1395181848000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12535344.1395181848000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12535344.1395181848000.25026.1395181931054@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-3136?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Paul Ferraro updated WFLY-3136:
-------------------------------

    Description: 
>From SRV 7.7.2: Distributed Environments
Within an application marked as distributable, all requests that are part of a session must be handled by one JVM at a time.

Our default configuration for the Infinispan cache used for web sessions uses PESSIMISTIC locking.  However, Infinispan only acquires locks on cache write operations.  This only prevents concurrent writes to a session.  Even with REPEATABLE_READ, 2 threads can read a session at the same time.  We need to make sure both reads and writes to a session use cluster exclusive access, by default at least.

  was:
>From SRV 7.7.2: Distributed Environments
Within an application marked as distributable, all requests that are part of a session must be handled by one JVM at a time.

Our default configuration for the Infinispan cache used for web sessions uses PESSIMISTIC locking.  However, Infinispan only acquires locks on cache write operations.  This only prevents concurrent writes to a session.  We need to make sure both reads and writes to a session use cluster exclusive access, by default at least.


    
> SRV 7.7.2 non-compliance
> ------------------------
>
>                 Key: WFLY-3136
>                 URL: https://issues.jboss.org/browse/WFLY-3136
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Clustering
>    Affects Versions: 8.0.0.Final
>            Reporter: Paul Ferraro
>            Assignee: Paul Ferraro
>             Fix For: 8.0.1.Final
>
>
> From SRV 7.7.2: Distributed Environments
> Within an application marked as distributable, all requests that are part of a session must be handled by one JVM at a time.
> Our default configuration for the Infinispan cache used for web sessions uses PESSIMISTIC locking.  However, Infinispan only acquires locks on cache write operations.  This only prevents concurrent writes to a session.  Even with REPEATABLE_READ, 2 threads can read a session at the same time.  We need to make sure both reads and writes to a session use cluster exclusive access, by default at least.

--
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

From issues at jboss.org  Tue Mar 18 19:54:10 2014
From: issues at jboss.org (Mark Torres (JIRA))
Date: Tue, 18 Mar 2014 19:54:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JASSIST-214) Nullpointer in
	RuntimeSupport
In-Reply-To: <JIRA.12525784.1385028379000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12525784.1385028379000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12525784.1385028379000.25065.1395186850915@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JASSIST-214?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12954032#comment-12954032 ] 

Mark Torres commented on JASSIST-214:
-------------------------------------

Thanks Andreas, I encountered the issue and in my case, it is indeed dozer related. The straightforward fix in my case is to change DestBeanCreator in dozer to use the unproxied class's constructor.

                
> Nullpointer in RuntimeSupport
> -----------------------------
>
>                 Key: JASSIST-214
>                 URL: https://issues.jboss.org/browse/JASSIST-214
>             Project: Javassist
>          Issue Type: Bug
>    Affects Versions: 3.16.1-GA
>            Reporter: Michael Burns
>            Assignee: Shigeru Chiba
>
> Under moderate load our multithreaded application frequently gives the following exception:
> java.lang.NullPointerException
>         at javassist.util.proxy.RuntimeSupport$DefaultMethodHandler.invoke(RuntimeSupport.java:38)
>         at com.Customer_$$_javassist_1.getHibernateLazyInitializer(Customer_$$_javassist_1.java)
>         at org.hibernate.Hibernate.isInitialized(Hibernate.java:429)
> This then effects all future instantiations of the Customer object which give the same exception.

--
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

From issues at jboss.org  Tue Mar 18 22:00:11 2014
From: issues at jboss.org (Jay Kumar SenSharma (JIRA))
Date: Tue, 18 Mar 2014 22:00:11 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3131) isSensitiveValue of class
 SensitiveVaultExpressionConstraint uses incorrect index in
 java.lang.String.substring method
In-Reply-To: <JIRA.12535307.1395160191000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12535307.1395160191000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12535307.1395160191000.25192.1395194411061@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-3131?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jay Kumar SenSharma updated WFLY-3131:
--------------------------------------

    Git Pull Request: https://github.com/wildfly/wildfly/pull/6055

    
> isSensitiveValue of class SensitiveVaultExpressionConstraint uses incorrect  index in java.lang.String.substring method
> -----------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-3131
>                 URL: https://issues.jboss.org/browse/WFLY-3131
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>    Affects Versions: 8.0.0.Final
>         Environment: All
>            Reporter: Jay Kumar SenSharma
>            Assignee: Jay Kumar SenSharma
>
> The isSensitiveValue(ModelNode value) method of class "org.jboss.as.controller.access.constraint.SensitiveVaultExpressionConstraint" seems to be using the incorrect  index in java.lang.String.substring method.  Which is causing the following exceptions in the logs while executing the following kind of CLI command:
> {code}
> [standalone at localhost:9990 /] /subsystem=logging/periodic-rotating-file-handler=FILE:write-attribute(name=formatter, value="%d{HH:mm:ss,SSS} %-5p [%c] (${jboss.node.name} %t) %s%E%n")
> {
>     "outcome" => "failed",
>     "failure-description" => "JBAS014749: Operation handler failed: String index out of range: -15",
>     "rolled-back" => true
> }
> {code}
> The Exception can be seen as following in the WildFly Logs:
> {code}
> 21:58:04,821 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 25) JBAS014612: Operation ("write-attribute") failed - address: ([
>     ("subsystem" => "logging"),
>     ("periodic-rotating-file-handler" => "FILE")
> ]): java.lang.StringIndexOutOfBoundsException: String index out of range: -15
> 	at java.lang.String.substring(String.java:1911) [rt.jar:1.7.0_51]
> 	at org.jboss.as.controller.access.constraint.SensitiveVaultExpressionConstraint$Factory.isSensitiveValue(SensitiveVaultExpressionConstraint.java:128) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> 	at org.jboss.as.controller.access.constraint.SensitiveVaultExpressionConstraint$Factory.isSensitiveAction(SensitiveVaultExpressionConstraint.java:89) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> 	at org.jboss.as.controller.access.constraint.SensitiveVaultExpressionConstraint$Factory.getRequiredConstraint(SensitiveVaultExpressionConstraint.java:81) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> 	at org.jboss.as.controller.access.rbac.DefaultPermissionFactory.getRequiredPermissions(DefaultPermissionFactory.java:201) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> 	at org.jboss.as.controller.access.permission.ManagementPermissionAuthorizer.authorize(ManagementPermissionAuthorizer.java:100) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> 	at org.jboss.as.controller.access.management.DelegatingConfigurableAuthorizer.authorize(DelegatingConfigurableAuthorizer.java:98) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> 	at org.jboss.as.controller.OperationContextImpl.getBasicAuthorizationResponse(OperationContextImpl.java:1153) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> 	at org.jboss.as.controller.OperationContextImpl.authorize(OperationContextImpl.java:1055) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> 	at org.jboss.as.controller.OperationContextImpl.authorize(OperationContextImpl.java:1015) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> 	at org.jboss.as.controller.OperationContextImpl.getResourceRegistration(OperationContextImpl.java:265) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> 	at org.jboss.as.controller.operations.global.WriteAttributeHandler.execute(WriteAttributeHandler.java:72) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> 	at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:591) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> 	at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:469) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> 	at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:273) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> 	at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:268) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> 	at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:272) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> 	at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:146) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:174) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$300(ModelControllerClientOperationHandler.java:105) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:125) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:121) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> 	at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.7.0_51]
> 	at javax.security.auth.Subject.doAs(Subject.java:415) [rt.jar:1.7.0_51]
> 	at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:94) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:121) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> 	at org.jboss.as.protocol.mgmt.AbstractMessageHandler$2$1.doExecute(AbstractMessageHandler.java:283) [wildfly-protocol-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> 	at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:504) [wildfly-protocol-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_51]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_51]
> 	at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_51]
> 	at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.1.Final.jar:2.1.1.Final]
> {code}

--
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

From issues at jboss.org  Tue Mar 18 23:04:10 2014
From: issues at jboss.org (rafael liu (JIRA))
Date: Tue, 18 Mar 2014 23:04:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-332) Add sessionDrainingStrategy
 configuration option to modcluster subsystem
In-Reply-To: <JIRA.12458456.1328568619000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12458456.1328568619000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12458456.1328568619000.25248.1395198250639@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-332?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12954048#comment-12954048 ] 

rafael liu commented on WFLY-332:
---------------------------------

Rodaslav, looks like you are talking about mod_cluster end. What I tried to say is that when doing a undeploy/redeploy through WildFly it would be useful to set a sessionDrainingStrategy for that operation only (rather than once, system wide).

In case #1, what I see is JBoss throwing an exception: 
15:46:17,325 WARN  [org.jboss.modcluster] (ServerService Thread Pool -- 137) MODCLUSTER000025: Failed to drain 1 remaining active sessions from default-host:/myapp within 10,000000.1 seconds
15:46:17,327 INFO  [org.jboss.modcluster] (ServerService Thread Pool -- 137) MODCLUSTER000021: All pending requests drained from default-host:/myapp in 10,002000.1 seconds

In case #2, I don't see how to skip session draining in JBoss/WildFly. It always seems to enforce this behavior, am I wrong?
                
> Add sessionDrainingStrategy configuration option to modcluster subsystem
> ------------------------------------------------------------------------
>
>                 Key: WFLY-332
>                 URL: https://issues.jboss.org/browse/WFLY-332
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Clustering
>            Reporter: Radoslav Husar
>            Assignee: Jean-Frederic Clere
>             Fix For: 8.0.0.Beta1
>
>
> Add sessionDrainingStrategy configuration option to modcluster subsystem
> * xsd 1.1

--
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

From issues at jboss.org  Tue Mar 18 23:56:10 2014
From: issues at jboss.org (Richard Yang (JIRA))
Date: Tue, 18 Mar 2014 23:56:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3132) jca enlisting datasource
 failed when datasource is first time used or have been idling for a while
In-Reply-To: <JIRA.12535309.1395161769000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12535309.1395161769000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12535309.1395161769000.25275.1395201370562@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-3132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12954052#comment-12954052 ] 

Richard Yang commented on WFLY-3132:
------------------------------------

Could you explain why this case is closed with no action? I certainly still have the same issue and it happens everytime. I would like to provide more info if you are willing to work on this problem.
                
> jca enlisting datasource failed when datasource is first time used or have been idling for a while
> --------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-3132
>                 URL: https://issues.jboss.org/browse/WFLY-3132
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JCA
>    Affects Versions: 8.0.0.Final
>         Environment: Windows 7 64 bits, java ee 7
>            Reporter: Richard Yang
>            Assignee: Jesper Pedersen
>
> I am not sure this is a bug. I have opened a thread in the jboss community. But so far I have not got a definitive answer. I can reproduce this everytime.
> This same code works fine in eap 6.0.
> Please see the issue description in the following thread:
> https://community.jboss.org/thread/237883
> I would like to provide more details if somebody will work on this issue.
> Server log and trace level log (jca trace) are attached on that thread.
> Thanks.

--
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

From issues at jboss.org  Wed Mar 19 00:04:10 2014
From: issues at jboss.org (Richard Yang (JIRA))
Date: Wed, 19 Mar 2014 00:04:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3137) WELD-000019: Error destroying
 an requestscoped entitymanager
In-Reply-To: <JIRA.12535360.1395201803540@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12535360.1395201803540@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12535360.1395201803540.25279.1395201850555@jira02.app.mwc.hst.phx2.redhat.com>

Richard Yang created WFLY-3137:
----------------------------------

             Summary: WELD-000019: Error destroying an requestscoped entitymanager
                 Key: WFLY-3137
                 URL: https://issues.jboss.org/browse/WFLY-3137
             Project: WildFly
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: CDI / Weld
    Affects Versions: 8.0.0.Final
         Environment: window 7 64bits, javaee 1.7
            Reporter: Richard Yang
            Assignee: Stuart Douglas


I have a simple producer for a requestscoped entitymanager:

@PersistenceContext(unitName = mydatasource)
	private EntityManager em;
@Produces
	@myEM
	@RequestScoped
	protected EntityManager createEntityManager() {
		return this.epenops;
	}

	protected void closeEntityManager(
			@Disposes @myEM EntityManager entityManager) {
		if (entityManager.isOpen()) {
			entityManager.close();
		}
	}

I inject this to applicationScoped bean. In the log, I see for each close of entityManager, wildfly logs an error:
WELD-000019: Error destroying an instance org.jboss.as.jpa.container.TransactionScopedEntityManager at 7c213180 of Producer Method [EntityManager] with qualifiers [@myEM @Any] declared as [[BackedAnnotatedMethod] @Produces @myEM @RequestScoped protected createEntityManager()]

--
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

From issues at jboss.org  Wed Mar 19 00:06:10 2014
From: issues at jboss.org (Richard Yang (JIRA))
Date: Wed, 19 Mar 2014 00:06:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3137) WELD-000019: Error destroying
 an requestscoped entitymanager
In-Reply-To: <JIRA.12535360.1395201803000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12535360.1395201803000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12535360.1395201803000.25283.1395201970620@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-3137?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Richard Yang updated WFLY-3137:
-------------------------------

    Description: 
I have a simple producer for a requestscoped entitymanager:

@PersistenceContext(unitName = mydatasource)
	private EntityManager em;
@Produces
	@myEM
	@RequestScoped
	protected EntityManager createEntityManager() {
		return em;
	}

	protected void closeEntityManager(
			@Disposes @myEM EntityManager entityManager) {
		if (entityManager.isOpen()) {
			entityManager.close();
		}
	}

I inject this to applicationScoped bean. In the log, I see for each close of entityManager, wildfly logs an error:
WELD-000019: Error destroying an instance org.jboss.as.jpa.container.TransactionScopedEntityManager at 7c213180 of Producer Method [EntityManager] with qualifiers [@myEM @Any] declared as [[BackedAnnotatedMethod] @Produces @myEM @RequestScoped protected createEntityManager()]

  was:
I have a simple producer for a requestscoped entitymanager:

@PersistenceContext(unitName = mydatasource)
	private EntityManager em;
@Produces
	@myEM
	@RequestScoped
	protected EntityManager createEntityManager() {
		return this.epenops;
	}

	protected void closeEntityManager(
			@Disposes @myEM EntityManager entityManager) {
		if (entityManager.isOpen()) {
			entityManager.close();
		}
	}

I inject this to applicationScoped bean. In the log, I see for each close of entityManager, wildfly logs an error:
WELD-000019: Error destroying an instance org.jboss.as.jpa.container.TransactionScopedEntityManager at 7c213180 of Producer Method [EntityManager] with qualifiers [@myEM @Any] declared as [[BackedAnnotatedMethod] @Produces @myEM @RequestScoped protected createEntityManager()]


    
> WELD-000019: Error destroying an requestscoped entitymanager
> ------------------------------------------------------------
>
>                 Key: WFLY-3137
>                 URL: https://issues.jboss.org/browse/WFLY-3137
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: CDI / Weld
>    Affects Versions: 8.0.0.Final
>         Environment: window 7 64bits, javaee 1.7
>            Reporter: Richard Yang
>            Assignee: Stuart Douglas
>
> I have a simple producer for a requestscoped entitymanager:
> @PersistenceContext(unitName = mydatasource)
> 	private EntityManager em;
> @Produces
> 	@myEM
> 	@RequestScoped
> 	protected EntityManager createEntityManager() {
> 		return em;
> 	}
> 	protected void closeEntityManager(
> 			@Disposes @myEM EntityManager entityManager) {
> 		if (entityManager.isOpen()) {
> 			entityManager.close();
> 		}
> 	}
> I inject this to applicationScoped bean. In the log, I see for each close of entityManager, wildfly logs an error:
> WELD-000019: Error destroying an instance org.jboss.as.jpa.container.TransactionScopedEntityManager at 7c213180 of Producer Method [EntityManager] with qualifiers [@myEM @Any] declared as [[BackedAnnotatedMethod] @Produces @myEM @RequestScoped protected createEntityManager()]

--
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

From issues at jboss.org  Wed Mar 19 00:06:10 2014
From: issues at jboss.org (Richard Yang (JIRA))
Date: Wed, 19 Mar 2014 00:06:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3137) logging errors in destroying
 a requestscoped entitymanager
In-Reply-To: <JIRA.12535360.1395201803000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12535360.1395201803000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12535360.1395201803000.25285.1395201970701@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-3137?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Richard Yang updated WFLY-3137:
-------------------------------

    Summary: logging errors in destroying a requestscoped entitymanager  (was: WELD-000019: Error destroying an requestscoped entitymanager)

    
> logging errors in destroying a requestscoped entitymanager
> ----------------------------------------------------------
>
>                 Key: WFLY-3137
>                 URL: https://issues.jboss.org/browse/WFLY-3137
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: CDI / Weld
>    Affects Versions: 8.0.0.Final
>         Environment: window 7 64bits, javaee 1.7
>            Reporter: Richard Yang
>            Assignee: Stuart Douglas
>
> I have a simple producer for a requestscoped entitymanager:
> @PersistenceContext(unitName = mydatasource)
> 	private EntityManager em;
> @Produces
> 	@myEM
> 	@RequestScoped
> 	protected EntityManager createEntityManager() {
> 		return em;
> 	}
> 	protected void closeEntityManager(
> 			@Disposes @myEM EntityManager entityManager) {
> 		if (entityManager.isOpen()) {
> 			entityManager.close();
> 		}
> 	}
> I inject this to applicationScoped bean. In the log, I see for each close of entityManager, wildfly logs an error:
> WELD-000019: Error destroying an instance org.jboss.as.jpa.container.TransactionScopedEntityManager at 7c213180 of Producer Method [EntityManager] with qualifiers [@myEM @Any] declared as [[BackedAnnotatedMethod] @Produces @myEM @RequestScoped protected createEntityManager()]

--
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

From issues at jboss.org  Wed Mar 19 03:40:10 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 19 Mar 2014 03:40:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2147) Improve RBAC Performance
In-Reply-To: <JIRA.12501429.1380051921000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501429.1380051921000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501429.1380051921000.25330.1395214810661@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2147?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated WFLY-2147:
------------------------------------------

        Bugzilla Update: Perform
    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1077536

    
> Improve RBAC Performance
> ------------------------
>
>                 Key: WFLY-2147
>                 URL: https://issues.jboss.org/browse/WFLY-2147
>             Project: WildFly
>          Issue Type: Enhancement
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>            Reporter: Brian Stansberry
>            Assignee: Brian Stansberry
>             Fix For: 9.0.0.CR1
>
>
> Parent task for work related to reducing the impact of RBAC (WFLY-490) on management operation performance.

--
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

From issues at jboss.org  Wed Mar 19 05:08:10 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 19 Mar 2014 05:08:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3071) upgrade Generic JMS RA to
	1.0.2.Final
In-Reply-To: <JIRA.12534174.1394029950000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534174.1394029950000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534174.1394029950000.25476.1395220090582@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-3071?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12954090#comment-12954090 ] 

RH Bugzilla Integration commented on WFLY-3071:
-----------------------------------------------

Martin Simka <msimka at redhat.com> changed the Status of [bug 1073354|https://bugzilla.redhat.com/show_bug.cgi?id=1073354] from ON_QA to VERIFIED
                
> upgrade Generic JMS RA to 1.0.2.Final
> -------------------------------------
>
>                 Key: WFLY-3071
>                 URL: https://issues.jboss.org/browse/WFLY-3071
>             Project: WildFly
>          Issue Type: Component  Upgrade
>      Security Level: Public(Everyone can see) 
>          Components: JCA
>    Affects Versions: 8.0.0.Final
>            Reporter: Jeff Mesnil
>            Assignee: Jeff Mesnil
>             Fix For: 8.0.1.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

From issues at jboss.org  Wed Mar 19 05:20:11 2014
From: issues at jboss.org (Carlo de Wolf (JIRA))
Date: Wed, 19 Mar 2014 05:20:11 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (EJBTHREE-926) isCallerInRole()
 implementation should use EJBRoleRefPermissions when jacc is enabled
In-Reply-To: <JIRA.12336437.1174915631000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12336437.1174915631000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12336437.1174915631000.25513.1395220811945@jira02.app.mwc.hst.phx2.redhat.com>

An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jboss-jira/attachments/20140319/a3a9f598/attachment-0001.html 

From issues at jboss.org  Wed Mar 19 05:32:11 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 19 Mar 2014 05:32:11 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-329) ClassFormatException when
 compile template with latest JDK8 (b114)
In-Reply-To: <JIRA.12524625.1383920786000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12524625.1383920786000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12524625.1383920786000.25548.1395221531747@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-329?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated DROOLS-329:
-------------------------------------------

        Bugzilla Update: Perform
    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1078146

    
> ClassFormatException when compile template with latest JDK8 (b114)
> ------------------------------------------------------------------
>
>                 Key: DROOLS-329
>                 URL: https://issues.jboss.org/browse/DROOLS-329
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.5.0.Final, 6.0.0.CR5
>         Environment: Ubuntu linux, latest JDK1.8 (b114) downloaded from https://jdk8.java.net/download.html
>            Reporter: Marek Posolda
>            Assignee: Mark Proctor
>             Fix For: 5.5.1.Final, 6.1.0.Final
>
>
> When trying to run code for compile templates with latest JDK8 (For instance this example https://github.com/droolsjbpm/drools/blob/master/drools-examples/src/main/java/org/drools/examples/templates/SimpleRuleTemplateExample.java )
> it will throw an exception like this:
> {code}
> Exception in thread "main" java.lang.RuntimeException: java.lang.RuntimeException: wrong class format
> 	at org.drools.template.parser.DefaultTemplateRuleBase.readRule(DefaultTemplateRuleBase.java:148)
> 	at org.drools.template.parser.DefaultTemplateRuleBase.<init>(DefaultTemplateRuleBase.java:62)
> 	at org.drools.template.parser.TemplateDataListener.<init>(TemplateDataListener.java:74)
> 	at org.drools.decisiontable.ExternalSpreadsheetCompiler.compile(ExternalSpreadsheetCompiler.java:95)
> 	at org.drools.decisiontable.ExternalSpreadsheetCompiler.compile(ExternalSpreadsheetCompiler.java:81)
> 	at org.drools.examples.templates.SimpleRuleTemplateExample.buildKBase(SimpleRuleTemplateExample.java:84)
> 	at org.drools.examples.templates.SimpleRuleTemplateExample.executeExample(SimpleRuleTemplateExample.java:49)
> 	at org.drools.examples.templates.SimpleRuleTemplateExample.main(SimpleRuleTemplateExample.java:43)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:483)
> 	at com.intellij.rt.execution.application.AppMain.main(AppMain.java:120)
> Caused by: java.lang.RuntimeException: wrong class format
> 	at org.drools.commons.jci.compilers.EclipseJavaCompiler$2.findType(EclipseJavaCompiler.java:263)
> 	at org.drools.commons.jci.compilers.EclipseJavaCompiler$2.findType(EclipseJavaCompiler.java:203)
> 	at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.askForType(LookupEnvironment.java:102)
> 	at org.eclipse.jdt.internal.compiler.lookup.UnresolvedReferenceBinding.resolve(UnresolvedReferenceBinding.java:49)
> 	at org.eclipse.jdt.internal.compiler.lookup.BinaryTypeBinding.resolveType(BinaryTypeBinding.java:122)
> 	at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.getTypeFromTypeSignature(LookupEnvironment.java:1188)
> 	at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.getTypeFromVariantTypeSignature(LookupEnvironment.java:1244)
> 	at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.getTypeArgumentsFromSignature(LookupEnvironment.java:1031)
> 	at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.getTypeFromTypeSignature(LookupEnvironment.java:1193)
> 	at org.eclipse.jdt.internal.compiler.lookup.BinaryTypeBinding.createMethod(BinaryTypeBinding.java:495)
> 	at org.eclipse.jdt.internal.compiler.lookup.BinaryTypeBinding.createMethods(BinaryTypeBinding.java:577)
> 	at org.eclipse.jdt.internal.compiler.lookup.BinaryTypeBinding.cachePartsFrom(BinaryTypeBinding.java:327)
> 	at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.createBinaryTypeFrom(LookupEnvironment.java:640)
> 	at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.createBinaryTypeFrom(LookupEnvironment.java:619)
> 	at org.eclipse.jdt.internal.compiler.Compiler.accept(Compiler.java:295)
> 	at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.askForType(LookupEnvironment.java:133)
> 	at org.eclipse.jdt.internal.compiler.lookup.PackageBinding.getTypeOrPackage(PackageBinding.java:183)
> 	at org.eclipse.jdt.internal.compiler.lookup.CompilationUnitScope.findImport(CompilationUnitScope.java:465)
> 	at org.eclipse.jdt.internal.compiler.lookup.CompilationUnitScope.findSingleImport(CompilationUnitScope.java:519)
> 	at org.eclipse.jdt.internal.compiler.lookup.CompilationUnitScope.faultInImports(CompilationUnitScope.java:368)
> 	at org.eclipse.jdt.internal.compiler.lookup.CompilationUnitScope.faultInTypes(CompilationUnitScope.java:444)
> 	at org.eclipse.jdt.internal.compiler.Compiler.process(Compiler.java:752)
> 	at org.eclipse.jdt.internal.compiler.Compiler.compile(Compiler.java:464)
> 	at org.drools.commons.jci.compilers.EclipseJavaCompiler.compile(EclipseJavaCompiler.java:389)
> 	at org.drools.commons.jci.compilers.AbstractJavaCompiler.compile(AbstractJavaCompiler.java:49)
> 	at org.drools.rule.builder.dialect.java.JavaDialect.compileAll(JavaDialect.java:371)
> 	at org.drools.compiler.DialectCompiletimeRegistry.compileAll(DialectCompiletimeRegistry.java:46)
> 	at org.drools.compiler.PackageRegistry.compileAll(PackageRegistry.java:102)
> 	at org.drools.compiler.PackageBuilder.compileAll(PackageBuilder.java:1006)
> 	at org.drools.compiler.PackageBuilder.compileAllRules(PackageBuilder.java:842)
> 	at org.drools.compiler.PackageBuilder.addPackage(PackageBuilder.java:831)
> 	at org.drools.compiler.PackageBuilder.addPackageFromDrl(PackageBuilder.java:441)
> 	at org.drools.compiler.PackageBuilder.addPackageFromDrl(PackageBuilder.java:419)
> 	at org.drools.template.parser.DefaultTemplateRuleBase.readRule(DefaultTemplateRuleBase.java:139)
> 	... 12 more
> Caused by: org.eclipse.jdt.internal.compiler.classfmt.ClassFormatException
> 	at org.eclipse.jdt.internal.compiler.classfmt.ClassFileReader.<init>(ClassFileReader.java:372)
> 	at org.drools.commons.jci.compilers.EclipseJavaCompiler$2.createNameEnvironmentAnswer(EclipseJavaCompiler.java:287)
> 	at org.drools.commons.jci.compilers.EclipseJavaCompiler$2.findType(EclipseJavaCompiler.java:258)
> 	... 45 more
> {code}
> Workaround, which worked for me is to switch to Janino compiler (See Workaround description)

--
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

From issues at jboss.org  Wed Mar 19 05:44:10 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 19 Mar 2014 05:44:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3073) MBeanServer.createMBean
 methods that take a classloader don't work
In-Reply-To: <JIRA.12534226.1394051286000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534226.1394051286000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534226.1394051286000.25580.1395222250907@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-3073?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12954104#comment-12954104 ] 

RH Bugzilla Integration commented on WFLY-3073:
-----------------------------------------------

Jan Martiska <jmartisk at redhat.com> changed the Status of [bug 1073106|https://bugzilla.redhat.com/show_bug.cgi?id=1073106] from ON_QA to VERIFIED
                
> MBeanServer.createMBean methods that take a classloader don't work
> ------------------------------------------------------------------
>
>                 Key: WFLY-3073
>                 URL: https://issues.jboss.org/browse/WFLY-3073
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JMX
>    Affects Versions: 8.0.0.Final
>            Reporter: Stuart Douglas
>            Assignee: Kabir Khan
>             Fix For: 8.0.1.Final
>
>
> The MBeanServer.createMBean methods that take an "ObjectName loaderName" argument are completely broken in EAP 6.
> These methods call findDelegate to make sure there is already an existing MBean registered with the given name passed in for the new MBean, or else it throws an exception.
> This is obviously wrong, as there'd be no point in calling createMBean if it already existed.
> javax.management.InstanceNotFoundException: test:service=Test
> at org.jboss.as.jmx.PluggableMBeanServerImpl.findDelegate(PluggableMBeanServerImpl.java:1083)
> at org.jboss.as.jmx.PluggableMBeanServerImpl.createMBean(PluggableMBeanServerImpl.java:253)

--
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

From issues at jboss.org  Wed Mar 19 06:06:11 2014
From: issues at jboss.org (Robert Spielmann (JIRA))
Date: Wed, 19 Mar 2014 06:06:11 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-372) InstantiationError during
 condition evaluation in Drools 6.0.0.Final
In-Reply-To: <JIRA.12527361.1386606563000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12527361.1386606563000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12527361.1386606563000.25655.1395223571135@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/DROOLS-372?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12954117#comment-12954117 ] 

Robert Spielmann commented on DROOLS-372:
-----------------------------------------

I tried to pin the cause to a single test or a minimal rule with test case, but I failed. This error occurs randomly across a base of around 2800 tests. I think I'll try to upgrade to Drools 6.
                
> InstantiationError during condition evaluation in Drools 6.0.0.Final
> --------------------------------------------------------------------
>
>                 Key: DROOLS-372
>                 URL: https://issues.jboss.org/browse/DROOLS-372
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 6.0.0.Final
>         Environment: reproduced on both jdk 6 and jdk 7
>            Reporter: Loic Albertin
>            Assignee: Mario Fusco
>             Fix For: 6.0.1.Final
>
>         Attachments: drools-issue.zip
>
>
> Kindly find bellow the initial discussion from rules-user at list.jboss.org
> In addition I attach a sample project that reproduce the error. 
> To run it simply type 'mvn clean install exec:java'.
> An interesting thing is that on my environment the issue always appears at the 21st insertion. 
> {quote}
> Hi all,
> I'm migrating from an old Drools 5.1 version to 6.0.0.Final. Sometimes (I don't really get under which conditions as sometimes it works), I'm facing an InstantiationError exception when I insert a fact into a stateful kie session. This exception is thrown by a generated class named ConditionEvaluator<UUID> which doesn't help for debugging!
> The inserted object is a basic POJO (named JasmineEventEB) except for an attribute named "value" which accept any "Serializable" object and which is causing the issue.
> The rule condition is quite simple
> $e : JasmineEventEB(probe == "Button:pris" && value == "1")
> In debugging I found that it failed when evaluating the value == "1" part. I can also confirm that the value for the actually inserted JasmineEventEB is a string.
> The stacktrace is:
> {noformat}
> java.lang.InstantiationError: java.io.Serializable
>         at ConditionEvaluatorae1a73837e8146bda23004a0450e2e52.evaluate(Unknown Source)
>         at org.drools.core.rule.constraint.MvelConstraint.evaluate(MvelConstraint.java:212)
>         at org.drools.core.rule.constraint.MvelConstraint.isAllowed(MvelConstraint.java:169)
>         at org.drools.core.reteoo.AlphaNode.assertObject(AlphaNode.java:134)
>         at org.drools.core.reteoo.CompositeObjectSinkAdapter.doPropagateAssertObject(CompositeObjectSinkAdapter.java:502)
>         at org.drools.core.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:387)
>         at org.drools.core.reteoo.AlphaNode.assertObject(AlphaNode.java:138)
>         at org.drools.core.reteoo.CompositeObjectSinkAdapter.doPropagateAssertObject(CompositeObjectSinkAdapter.java:502)
>         at org.drools.core.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:377)
>         at org.drools.core.reteoo.ObjectTypeNode.assertObject(ObjectTypeNode.java:288)
>         at org.drools.core.reteoo.EntryPointNode.assertObject(EntryPointNode.java:260)
>         at org.drools.core.common.NamedEntryPoint.insert(NamedEntryPoint.java:360)
>         at org.drools.core.common.NamedEntryPoint.insert(NamedEntryPoint.java:279)
>         at org.drools.core.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:1149)
>         at org.drools.core.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:1093)
>         at org.drools.core.impl.StatefulKnowledgeSessionImpl.insert(StatefulKnowledgeSessionImpl.java:308)
> {noformat}
> I tested both with the java and mvel dialect with the same result.
> Does someone has already encountered this kind of error?
> If you need more details or clarifications please let me know.
> Thanks & regards,
> Lo?c  
> {quote}

--
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


From issues at jboss.org  Wed Mar 19 06:06:11 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 19 Mar 2014 06:06:11 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2913) Generic http management
 operation upload handler
In-Reply-To: <JIRA.12531890.1392210103000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12531890.1392210103000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12531890.1392210103000.25665.1395223571615@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2913?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12954119#comment-12954119 ] 

RH Bugzilla Integration commented on WFLY-2913:
-----------------------------------------------

Jakub Cechacek <jcechace at redhat.com> changed the Status of [bug 1066476|https://bugzilla.redhat.com/show_bug.cgi?id=1066476] from ON_QA to VERIFIED
                
> Generic http management operation upload handler
> ------------------------------------------------
>
>                 Key: WFLY-2913
>                 URL: https://issues.jboss.org/browse/WFLY-2913
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>            Reporter: Emanuel Muckenhuber
>            Assignee: Emanuel Muckenhuber
>             Fix For: 8.0.1.Final
>
>
> The current /management http API handler, does not support generic content uploads, where the add-content handler only allows addition to the content repository. Since operations might attach multiple streams to the operation we need a http handler which can deal with those requests.

--
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

From issues at jboss.org  Wed Mar 19 06:18:10 2014
From: issues at jboss.org (Sanne Grinovero (JIRA))
Date: Wed, 19 Mar 2014 06:18:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3127) Upgrade to Apache Avro 1.7.6
In-Reply-To: <JIRA.12535268.1395148407000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12535268.1395148407000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12535268.1395148407000.25690.1395224290741@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-3127?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Sanne Grinovero resolved WFLY-3127.
-----------------------------------

    Resolution: Done

    
> Upgrade to Apache Avro 1.7.6
> ----------------------------
>
>                 Key: WFLY-3127
>                 URL: https://issues.jboss.org/browse/WFLY-3127
>             Project: WildFly
>          Issue Type: Component  Upgrade
>      Security Level: Public(Everyone can see) 
>            Reporter: Sanne Grinovero
>            Assignee: Sanne Grinovero
>            Priority: Trivial
>             Fix For: 8.0.1.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

From issues at jboss.org  Wed Mar 19 06:46:11 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 19 Mar 2014 06:46:11 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-329) ClassFormatException when
 compile template with latest JDK8 (b114)
In-Reply-To: <JIRA.12524625.1383920786000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12524625.1383920786000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12524625.1383920786000.25772.1395225971078@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/DROOLS-329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12954141#comment-12954141 ] 

RH Bugzilla Integration commented on DROOLS-329:
------------------------------------------------

Mario Fusco <mfusco at redhat.com> changed the Status of [bug 1078146|https://bugzilla.redhat.com/show_bug.cgi?id=1078146] from NEW to ASSIGNED
                
> ClassFormatException when compile template with latest JDK8 (b114)
> ------------------------------------------------------------------
>
>                 Key: DROOLS-329
>                 URL: https://issues.jboss.org/browse/DROOLS-329
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.5.0.Final, 6.0.0.CR5
>         Environment: Ubuntu linux, latest JDK1.8 (b114) downloaded from https://jdk8.java.net/download.html
>            Reporter: Marek Posolda
>            Assignee: Mark Proctor
>             Fix For: 5.5.1.Final, 6.1.0.Final
>
>
> When trying to run code for compile templates with latest JDK8 (For instance this example https://github.com/droolsjbpm/drools/blob/master/drools-examples/src/main/java/org/drools/examples/templates/SimpleRuleTemplateExample.java )
> it will throw an exception like this:
> {code}
> Exception in thread "main" java.lang.RuntimeException: java.lang.RuntimeException: wrong class format
> 	at org.drools.template.parser.DefaultTemplateRuleBase.readRule(DefaultTemplateRuleBase.java:148)
> 	at org.drools.template.parser.DefaultTemplateRuleBase.<init>(DefaultTemplateRuleBase.java:62)
> 	at org.drools.template.parser.TemplateDataListener.<init>(TemplateDataListener.java:74)
> 	at org.drools.decisiontable.ExternalSpreadsheetCompiler.compile(ExternalSpreadsheetCompiler.java:95)
> 	at org.drools.decisiontable.ExternalSpreadsheetCompiler.compile(ExternalSpreadsheetCompiler.java:81)
> 	at org.drools.examples.templates.SimpleRuleTemplateExample.buildKBase(SimpleRuleTemplateExample.java:84)
> 	at org.drools.examples.templates.SimpleRuleTemplateExample.executeExample(SimpleRuleTemplateExample.java:49)
> 	at org.drools.examples.templates.SimpleRuleTemplateExample.main(SimpleRuleTemplateExample.java:43)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:483)
> 	at com.intellij.rt.execution.application.AppMain.main(AppMain.java:120)
> Caused by: java.lang.RuntimeException: wrong class format
> 	at org.drools.commons.jci.compilers.EclipseJavaCompiler$2.findType(EclipseJavaCompiler.java:263)
> 	at org.drools.commons.jci.compilers.EclipseJavaCompiler$2.findType(EclipseJavaCompiler.java:203)
> 	at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.askForType(LookupEnvironment.java:102)
> 	at org.eclipse.jdt.internal.compiler.lookup.UnresolvedReferenceBinding.resolve(UnresolvedReferenceBinding.java:49)
> 	at org.eclipse.jdt.internal.compiler.lookup.BinaryTypeBinding.resolveType(BinaryTypeBinding.java:122)
> 	at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.getTypeFromTypeSignature(LookupEnvironment.java:1188)
> 	at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.getTypeFromVariantTypeSignature(LookupEnvironment.java:1244)
> 	at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.getTypeArgumentsFromSignature(LookupEnvironment.java:1031)
> 	at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.getTypeFromTypeSignature(LookupEnvironment.java:1193)
> 	at org.eclipse.jdt.internal.compiler.lookup.BinaryTypeBinding.createMethod(BinaryTypeBinding.java:495)
> 	at org.eclipse.jdt.internal.compiler.lookup.BinaryTypeBinding.createMethods(BinaryTypeBinding.java:577)
> 	at org.eclipse.jdt.internal.compiler.lookup.BinaryTypeBinding.cachePartsFrom(BinaryTypeBinding.java:327)
> 	at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.createBinaryTypeFrom(LookupEnvironment.java:640)
> 	at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.createBinaryTypeFrom(LookupEnvironment.java:619)
> 	at org.eclipse.jdt.internal.compiler.Compiler.accept(Compiler.java:295)
> 	at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.askForType(LookupEnvironment.java:133)
> 	at org.eclipse.jdt.internal.compiler.lookup.PackageBinding.getTypeOrPackage(PackageBinding.java:183)
> 	at org.eclipse.jdt.internal.compiler.lookup.CompilationUnitScope.findImport(CompilationUnitScope.java:465)
> 	at org.eclipse.jdt.internal.compiler.lookup.CompilationUnitScope.findSingleImport(CompilationUnitScope.java:519)
> 	at org.eclipse.jdt.internal.compiler.lookup.CompilationUnitScope.faultInImports(CompilationUnitScope.java:368)
> 	at org.eclipse.jdt.internal.compiler.lookup.CompilationUnitScope.faultInTypes(CompilationUnitScope.java:444)
> 	at org.eclipse.jdt.internal.compiler.Compiler.process(Compiler.java:752)
> 	at org.eclipse.jdt.internal.compiler.Compiler.compile(Compiler.java:464)
> 	at org.drools.commons.jci.compilers.EclipseJavaCompiler.compile(EclipseJavaCompiler.java:389)
> 	at org.drools.commons.jci.compilers.AbstractJavaCompiler.compile(AbstractJavaCompiler.java:49)
> 	at org.drools.rule.builder.dialect.java.JavaDialect.compileAll(JavaDialect.java:371)
> 	at org.drools.compiler.DialectCompiletimeRegistry.compileAll(DialectCompiletimeRegistry.java:46)
> 	at org.drools.compiler.PackageRegistry.compileAll(PackageRegistry.java:102)
> 	at org.drools.compiler.PackageBuilder.compileAll(PackageBuilder.java:1006)
> 	at org.drools.compiler.PackageBuilder.compileAllRules(PackageBuilder.java:842)
> 	at org.drools.compiler.PackageBuilder.addPackage(PackageBuilder.java:831)
> 	at org.drools.compiler.PackageBuilder.addPackageFromDrl(PackageBuilder.java:441)
> 	at org.drools.compiler.PackageBuilder.addPackageFromDrl(PackageBuilder.java:419)
> 	at org.drools.template.parser.DefaultTemplateRuleBase.readRule(DefaultTemplateRuleBase.java:139)
> 	... 12 more
> Caused by: org.eclipse.jdt.internal.compiler.classfmt.ClassFormatException
> 	at org.eclipse.jdt.internal.compiler.classfmt.ClassFileReader.<init>(ClassFileReader.java:372)
> 	at org.drools.commons.jci.compilers.EclipseJavaCompiler$2.createNameEnvironmentAnswer(EclipseJavaCompiler.java:287)
> 	at org.drools.commons.jci.compilers.EclipseJavaCompiler$2.findType(EclipseJavaCompiler.java:258)
> 	... 45 more
> {code}
> Workaround, which worked for me is to switch to Janino compiler (See Workaround description)

--
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

From issues at jboss.org  Wed Mar 19 07:44:10 2014
From: issues at jboss.org (Remy Maucherat (JIRA))
Date: Wed, 19 Mar 2014 07:44:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBWEB-290) Optimize string literals
 inside jsp expressions
In-Reply-To: <JIRA.12533522.1393516764000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12533522.1393516764000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12533522.1393516764000.25884.1395229450821@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBWEB-290?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Remy Maucherat resolved JBWEB-290.
----------------------------------

    Fix Version/s: JBossWeb-7.4.0.GA
       Resolution: Done


Integrated since the patch was provided as requested. Would still like an answer to my last comment though.
                
> Optimize string literals inside jsp expressions 
> ------------------------------------------------
>
>                 Key: JBWEB-290
>                 URL: https://issues.jboss.org/browse/JBWEB-290
>             Project: JBoss Web
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Tomcat
>    Affects Versions: JBossWeb-3.0.0.Final
>            Reporter: John O'Hara
>            Assignee: Remy Maucherat
>             Fix For: JBossWeb-7.4.0.GA
>
>
> After setting genStringAsCharArray=true, we continue to see StringBuilder concatenating string literals for each jsp request for some of our jsp pages; instead of creating a static char[].
> This occurs when a string literal is included in a jsp expression, e.g.;
> <%="<INPUT type=\"hidden\" name=\"name\" value=\"" + obj.getName() + "\">"%>
> Is it possible to identify string literals inside expressions during the tokenization phase of parsing jsp pages in apache jasper and treat them as text nodes so that the apache jasper generator can apply the same optimizations as string literals outside the jsp expression?

--
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

From issues at jboss.org  Wed Mar 19 07:54:10 2014
From: issues at jboss.org (Jesper Pedersen (JIRA))
Date: Wed, 19 Mar 2014 07:54:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3049) IronJacamar 1.1.4.Final
In-Reply-To: <JIRA.12533667.1393620255000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12533667.1393620255000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12533667.1393620255000.25894.1395230050925@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-3049?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jesper Pedersen resolved WFLY-3049.
-----------------------------------

    Resolution: Done

    
> IronJacamar 1.1.4.Final
> -----------------------
>
>                 Key: WFLY-3049
>                 URL: https://issues.jboss.org/browse/WFLY-3049
>             Project: WildFly
>          Issue Type: Component  Upgrade
>      Security Level: Public(Everyone can see) 
>          Components: Build System
>            Reporter: Jesper Pedersen
>            Assignee: Jesper Pedersen
>            Priority: Blocker
>             Fix For: 8.0.1.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

From issues at jboss.org  Wed Mar 19 08:02:10 2014
From: issues at jboss.org (Eric Wittmann (JIRA))
Date: Wed, 19 Mar 2014 08:02:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3138) the cli exits after
 java.lang.IllegalArgumentException when I type a couple of specific
 commands.
In-Reply-To: <JIRA.12535041.1394807703000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12535041.1394807703000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12535041.1394807703000.25907.1395230530808@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-3138?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Eric Wittmann moved APIMAN-1 to WFLY-3138:
------------------------------------------

     Project: WildFly  (was: APIMan (API Management))
         Key: WFLY-3138  (was: APIMAN-1)
    Workflow: GIT Pull Request workflow   (was: classic default workflow)

    
> the cli exits after java.lang.IllegalArgumentException when I type a couple of specific commands.
> -------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-3138
>                 URL: https://issues.jboss.org/browse/WFLY-3138
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>         Environment: cat /etc/*-release
> Red Hat Enterprise Linux Server release 6.5 (Santiago)
> Red Hat Enterprise Linux Server release 6.5 (Santiago)
> Configured system properties:
> [Server:node-B3] 	[Host Controller] = true
> [Server:node-B3] 	[Server:node-B3] = 
> [Server:node-B3] 	awt.toolkit = sun.awt.X11.XToolkit
> [Server:node-B3] 	file.encoding = UTF-8
> [Server:node-B3] 	file.encoding.pkg = sun.io
> [Server:node-B3] 	file.separator = /
> [Server:node-B3] 	java.awt.graphicsenv = sun.awt.X11GraphicsEnvironment
> [Server:node-B3] 	java.awt.headless = true
> [Server:node-B3] 	java.awt.printerjob = sun.print.PSPrinterJob
> [Server:node-B3] 	java.class.path = /local/myUser/dev/jboss/jboss-modules.jar
> [Server:node-B3] 	java.class.version = 51.0
> [Server:node-B3] 	java.endorsed.dirs = /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.51.x86_64/jre/lib/endorsed
> [Server:node-B3] 	java.ext.dirs = /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.51.x86_64/jre/lib/ext:/usr/java/packages/lib/ext
> [Server:node-B3] 	java.home = /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.51.x86_64/jre
> [Server:node-B3] 	java.io.tmpdir = /tmp
> [Server:node-B3] 	java.library.path = /opt/devenv/lib64:/usr/java/packages/lib/amd64:/usr/lib64:/lib64:/lib:/usr/lib
> [Server:node-B3] 	java.net.preferIPv4Stack = true
> [Server:node-B3] 	java.runtime.name = OpenJDK Runtime Environment
> [Server:node-B3] 	java.runtime.version = 1.7.0_51-mockbuild_2014_01_10_10_19-b00
> [Server:node-B3] 	java.specification.name = Java Platform API Specification
> [Server:node-B3] 	java.specification.vendor = Oracle Corporation
> [Server:node-B3] 	java.specification.version = 1.7
> [Server:node-B3] 	java.util.logging.manager = org.jboss.logmanager.LogManager
> [Server:node-B3] 	java.vendor = Oracle Corporation
> [Server:node-B3] 	java.vendor.url = http://java.oracle.com/
> [Server:node-B3] 	java.vendor.url.bug = http://bugreport.sun.com/bugreport/
> [Server:node-B3] 	java.version = 1.7.0_51
> [Server:node-B3] 	java.vm.info = mixed mode
> [Server:node-B3] 	java.vm.name = OpenJDK 64-Bit Server VM
> [Server:node-B3] 	java.vm.specification.name = Java Virtual Machine Specification
> [Server:node-B3] 	java.vm.specification.vendor = Oracle Corporation
> [Server:node-B3] 	java.vm.specification.version = 1.7
> [Server:node-B3] 	java.vm.vendor = Oracle Corporation
> [Server:node-B3] 	java.vm.version = 24.45-b08
> [Server:node-B3] 	javax.management.builder.initial = org.jboss.as.jmx.PluggableMBeanServerBuilder
> [Server:node-B3] 	javax.xml.datatype.DatatypeFactory = __redirected.__DatatypeFactory
> [Server:node-B3] 	javax.xml.parsers.DocumentBuilderFactory = __redirected.__DocumentBuilderFactory
> [Server:node-B3] 	javax.xml.parsers.SAXParserFactory = __redirected.__SAXParserFactory
> [Server:node-B3] 	javax.xml.stream.XMLEventFactory = __redirected.__XMLEventFactory
> [Server:node-B3] 	javax.xml.stream.XMLInputFactory = __redirected.__XMLInputFactory
> [Server:node-B3] 	javax.xml.stream.XMLOutputFactory = __redirected.__XMLOutputFactory
> [Server:node-B3] 	javax.xml.transform.TransformerFactory = __redirected.__TransformerFactory
> [Server:node-B3] 	javax.xml.validation.SchemaFactory:http://www.w3.org/2001/XMLSchema = __redirected.__SchemaFactory
> [Server:node-B3] 	javax.xml.xpath.XPathFactory:http://java.sun.com/jaxp/xpath/dom = __redirected.__XPathFactory
> [Server:node-B3] 	jboss.bind.address = 0.0.0.0
> [Server:node-B3] 	jboss.domain.base.dir = /local/myUser/dev/jboss/domain
> [Server:node-B3] 	jboss.domain.config.dir = /local/myUser/dev/jboss/domain/configuration
> [Server:node-B3] 	jboss.home.dir = /local/myUser/dev/jboss
> [Server:node-B3] 	jboss.host.name = eclwsd012
> [Server:node-B3] 	jboss.modules.dir = /local/myUser/dev/jboss/modules
> [Server:node-B3] 	jboss.modules.system.pkgs = org.jboss.byteman
> [Server:node-B3] 	jboss.node.name = eclwsd012:node-B3
> [Server:node-B3] 	jboss.qualified.host.name = eclwsd012.xeop.de
> [Server:node-B3] 	jboss.server.base.dir = /local/myUser/dev/jboss/domain/servers/node-B3
> [Server:node-B3] 	jboss.server.config.dir = /local/myUser/dev/jboss/domain/servers/node-B3/configuration
> [Server:node-B3] 	jboss.server.data.dir = /local/myUser/dev/jboss/domain/servers/node-B3/data
> [Server:node-B3] 	jboss.server.deploy.dir = /local/myUser/dev/jboss/domain/servers/node-B3/data/content
> [Server:node-B3] 	jboss.server.log.dir = /local/myUser/dev/jboss/domain/servers/node-B3/log
> [Server:node-B3] 	jboss.server.name = node-B3
> [Server:node-B3] 	jboss.server.persist.config = true
> [Server:node-B3] 	jboss.server.temp.dir = /local/myUser/dev/jboss/domain/servers/node-B3/tmp
> [Server:node-B3] 	jgroups.bind_addr = 172.16.120.24
> [Server:node-B3] 	line.separator = 
> [Server:node-B3] 
> [Server:node-B3] 	logging.configuration = file:/local/myUser/dev/jboss/domain/servers/node-B3/data/logging.properties
> [Server:node-B3] 	module.path = /local/myUser/dev/jboss/modules
> [Server:node-B3] 	org.jboss.resolver.warning = true
> [Server:node-B3] 	org.xml.sax.driver = __redirected.__XMLReaderFactory
> [Server:node-B3] 	os.arch = amd64
> [Server:node-B3] 	os.name = Linux
> [Server:node-B3] 	os.version = 2.6.32-431.3.1.el6.x86_64
> [Server:node-B3] 	path.separator = :
> [Server:node-B3] 	sun.arch.data.model = 64
> [Server:node-B3] 	sun.boot.class.path = /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.51.x86_64/jre/lib/resources.jar:/usr/lib/jvm/java-1.7.0-openjdk-1.7.0.51.x86_64/jre/lib/rt.jar:/usr/lib/jvm/java-1.7.0-openjdk-1.7.0.51.x86_64/jre/lib/sunrsasign.jar:/usr/lib/jvm/java-1.7.0-openjdk-1.7.0.51.x86_64/jre/lib/jsse.jar:/usr/lib/jvm/java-1.7.0-openjdk-1.7.0.51.x86_64/jre/lib/jce.jar:/usr/lib/jvm/java-1.7.0-openjdk-1.7.0.51.x86_64/jre/lib/charsets.jar:/usr/lib/jvm/java-1.7.0-openjdk-1.7.0.51.x86_64/jre/lib/netx.jar:/usr/lib/jvm/java-1.7.0-openjdk-1.7.0.51.x86_64/jre/lib/plugin.jar:/usr/lib/jvm/java-1.7.0-openjdk-1.7.0.51.x86_64/jre/lib/rhino.jar:/usr/lib/jvm/java-1.7.0-openjdk-1.7.0.51.x86_64/jre/lib/jfr.jar:/usr/lib/jvm/java-1.7.0-openjdk-1.7.0.51.x86_64/jre/classes
> [Server:node-B3] 	sun.boot.library.path = /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.51.x86_64/jre/lib/amd64
> [Server:node-B3] 	sun.cpu.endian = little
> [Server:node-B3] 	sun.cpu.isalist = 
> [Server:node-B3] 	sun.io.unicode.encoding = UnicodeLittle
> [Server:node-B3] 	sun.java.command = /local/myUser/dev/jboss/jboss-modules.jar -mp /local/myUser/dev/jboss/modules -jaxpmodule javax.xml.jaxp-provider org.jboss.as.server
> [Server:node-B3] 	sun.java.launcher = SUN_STANDARD
> [Server:node-B3] 	sun.jnu.encoding = UTF-8
> [Server:node-B3] 	sun.management.compiler = HotSpot 64-Bit Tiered Compilers
> [Server:node-B3] 	sun.os.patch.level = unknown
> [Server:node-B3] 	user.country = US
> [Server:node-B3] 	user.dir = /local/myUser/dev/jboss-eap-6.1
> [Server:node-B3] 	user.home = /home/myUser
> [Server:node-B3] 	user.language = en
> [Server:node-B3] 	user.name = myUser
> [Server:node-B3] 	user.timezone = Europe/Berlin
> [Server:node-B3] 15:06:25,736 DEBUG [org.jboss.as.config] (MSC service thread 1-8) VM Arguments: -D[Server:node-B3] -Xms512m -Xmx1024m -Djgroups.bind_addr=172.16.120.24 -D[Host Controller]=true -Djboss.bind.address=0.0.0.0 -Djava.awt.headless=true -Djboss.modules.system.pkgs=org.jboss.byteman -Djboss.home.dir=/local/myUser/dev/jboss -Djava.net.preferIPv4Stack=true -Djboss.server.log.dir=/local/myUser/dev/jboss/domain/servers/node-B3/log -Djboss.server.temp.dir=/local/myUser/dev/jboss/domain/servers/node-B3/tmp -Djboss.server.data.dir=/local/myUser/dev/jboss/domain/servers/node-B3/data -Dlogging.configuration=file:/local/myUser/dev/jboss/domain/servers/node-B3/data/logging.properties 
>            Reporter: neo infinite
>            Assignee: Eric Wittmann
>            Priority: Critical
>
> myuser at myhost/bin:jboss-cli.sh -c
> [domain at localhost:9999 /] read-operation read-children-types
> 	Gets the type names of all the children under the selected resource
> PARAMETERS
> 	n/a
> java.lang.IllegalArgumentException
> 	at org.jboss.dmr.ModelValue.asPropertyList(ModelValue.java:100)
> 	at org.jboss.dmr.ModelNode.asPropertyList(ModelNode.java:360)
> 	at org.jboss.as.cli.handlers.ReadOperationHandler.handleResponse(ReadOperationHandler.java:177)
> 	at org.jboss.as.cli.handlers.BaseOperationCommand.doHandle(BaseOperationCommand.java:213)
> 	at org.jboss.as.cli.handlers.CommandHandlerWithHelp.handle(CommandHandlerWithHelp.java:86)
> 	at org.jboss.as.cli.impl.CommandContextImpl.handle(CommandContextImpl.java:582)
> 	at org.jboss.as.cli.impl.CommandContextImpl.handleSafe(CommandContextImpl.java:598)
> 	at org.jboss.as.cli.impl.CommandContextImpl.interact(CommandContextImpl.java:1186)
> 	at org.jboss.as.cli.impl.CliLauncher.main(CliLauncher.java:259)
> 	at org.jboss.as.cli.CommandLineMain.main(CommandLineMain.java:34)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:606)
> 	at org.jboss.modules.Module.run(Module.java:270)
> 	at org.jboss.modules.Main.main(Main.java:411)
> myuser at myhost/bin:

--
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

From issues at jboss.org  Wed Mar 19 08:02:11 2014
From: issues at jboss.org (Eric Wittmann (JIRA))
Date: Wed, 19 Mar 2014 08:02:11 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3138) the cli exits after
 java.lang.IllegalArgumentException when I type a couple of specific
 commands.
In-Reply-To: <JIRA.12535041.1394807703000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12535041.1394807703000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12535041.1394807703000.25910.1395230531006@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-3138?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12954160#comment-12954160 ] 

Eric Wittmann commented on WFLY-3138:
-------------------------------------

I moved this to WildFly since this is a problem with the CLI.  Not certain if this is the right project.
                
> the cli exits after java.lang.IllegalArgumentException when I type a couple of specific commands.
> -------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-3138
>                 URL: https://issues.jboss.org/browse/WFLY-3138
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>         Environment: cat /etc/*-release
> Red Hat Enterprise Linux Server release 6.5 (Santiago)
> Red Hat Enterprise Linux Server release 6.5 (Santiago)
> Configured system properties:
> [Server:node-B3] 	[Host Controller] = true
> [Server:node-B3] 	[Server:node-B3] = 
> [Server:node-B3] 	awt.toolkit = sun.awt.X11.XToolkit
> [Server:node-B3] 	file.encoding = UTF-8
> [Server:node-B3] 	file.encoding.pkg = sun.io
> [Server:node-B3] 	file.separator = /
> [Server:node-B3] 	java.awt.graphicsenv = sun.awt.X11GraphicsEnvironment
> [Server:node-B3] 	java.awt.headless = true
> [Server:node-B3] 	java.awt.printerjob = sun.print.PSPrinterJob
> [Server:node-B3] 	java.class.path = /local/myUser/dev/jboss/jboss-modules.jar
> [Server:node-B3] 	java.class.version = 51.0
> [Server:node-B3] 	java.endorsed.dirs = /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.51.x86_64/jre/lib/endorsed
> [Server:node-B3] 	java.ext.dirs = /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.51.x86_64/jre/lib/ext:/usr/java/packages/lib/ext
> [Server:node-B3] 	java.home = /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.51.x86_64/jre
> [Server:node-B3] 	java.io.tmpdir = /tmp
> [Server:node-B3] 	java.library.path = /opt/devenv/lib64:/usr/java/packages/lib/amd64:/usr/lib64:/lib64:/lib:/usr/lib
> [Server:node-B3] 	java.net.preferIPv4Stack = true
> [Server:node-B3] 	java.runtime.name = OpenJDK Runtime Environment
> [Server:node-B3] 	java.runtime.version = 1.7.0_51-mockbuild_2014_01_10_10_19-b00
> [Server:node-B3] 	java.specification.name = Java Platform API Specification
> [Server:node-B3] 	java.specification.vendor = Oracle Corporation
> [Server:node-B3] 	java.specification.version = 1.7
> [Server:node-B3] 	java.util.logging.manager = org.jboss.logmanager.LogManager
> [Server:node-B3] 	java.vendor = Oracle Corporation
> [Server:node-B3] 	java.vendor.url = http://java.oracle.com/
> [Server:node-B3] 	java.vendor.url.bug = http://bugreport.sun.com/bugreport/
> [Server:node-B3] 	java.version = 1.7.0_51
> [Server:node-B3] 	java.vm.info = mixed mode
> [Server:node-B3] 	java.vm.name = OpenJDK 64-Bit Server VM
> [Server:node-B3] 	java.vm.specification.name = Java Virtual Machine Specification
> [Server:node-B3] 	java.vm.specification.vendor = Oracle Corporation
> [Server:node-B3] 	java.vm.specification.version = 1.7
> [Server:node-B3] 	java.vm.vendor = Oracle Corporation
> [Server:node-B3] 	java.vm.version = 24.45-b08
> [Server:node-B3] 	javax.management.builder.initial = org.jboss.as.jmx.PluggableMBeanServerBuilder
> [Server:node-B3] 	javax.xml.datatype.DatatypeFactory = __redirected.__DatatypeFactory
> [Server:node-B3] 	javax.xml.parsers.DocumentBuilderFactory = __redirected.__DocumentBuilderFactory
> [Server:node-B3] 	javax.xml.parsers.SAXParserFactory = __redirected.__SAXParserFactory
> [Server:node-B3] 	javax.xml.stream.XMLEventFactory = __redirected.__XMLEventFactory
> [Server:node-B3] 	javax.xml.stream.XMLInputFactory = __redirected.__XMLInputFactory
> [Server:node-B3] 	javax.xml.stream.XMLOutputFactory = __redirected.__XMLOutputFactory
> [Server:node-B3] 	javax.xml.transform.TransformerFactory = __redirected.__TransformerFactory
> [Server:node-B3] 	javax.xml.validation.SchemaFactory:http://www.w3.org/2001/XMLSchema = __redirected.__SchemaFactory
> [Server:node-B3] 	javax.xml.xpath.XPathFactory:http://java.sun.com/jaxp/xpath/dom = __redirected.__XPathFactory
> [Server:node-B3] 	jboss.bind.address = 0.0.0.0
> [Server:node-B3] 	jboss.domain.base.dir = /local/myUser/dev/jboss/domain
> [Server:node-B3] 	jboss.domain.config.dir = /local/myUser/dev/jboss/domain/configuration
> [Server:node-B3] 	jboss.home.dir = /local/myUser/dev/jboss
> [Server:node-B3] 	jboss.host.name = eclwsd012
> [Server:node-B3] 	jboss.modules.dir = /local/myUser/dev/jboss/modules
> [Server:node-B3] 	jboss.modules.system.pkgs = org.jboss.byteman
> [Server:node-B3] 	jboss.node.name = eclwsd012:node-B3
> [Server:node-B3] 	jboss.qualified.host.name = eclwsd012.xeop.de
> [Server:node-B3] 	jboss.server.base.dir = /local/myUser/dev/jboss/domain/servers/node-B3
> [Server:node-B3] 	jboss.server.config.dir = /local/myUser/dev/jboss/domain/servers/node-B3/configuration
> [Server:node-B3] 	jboss.server.data.dir = /local/myUser/dev/jboss/domain/servers/node-B3/data
> [Server:node-B3] 	jboss.server.deploy.dir = /local/myUser/dev/jboss/domain/servers/node-B3/data/content
> [Server:node-B3] 	jboss.server.log.dir = /local/myUser/dev/jboss/domain/servers/node-B3/log
> [Server:node-B3] 	jboss.server.name = node-B3
> [Server:node-B3] 	jboss.server.persist.config = true
> [Server:node-B3] 	jboss.server.temp.dir = /local/myUser/dev/jboss/domain/servers/node-B3/tmp
> [Server:node-B3] 	jgroups.bind_addr = 172.16.120.24
> [Server:node-B3] 	line.separator = 
> [Server:node-B3] 
> [Server:node-B3] 	logging.configuration = file:/local/myUser/dev/jboss/domain/servers/node-B3/data/logging.properties
> [Server:node-B3] 	module.path = /local/myUser/dev/jboss/modules
> [Server:node-B3] 	org.jboss.resolver.warning = true
> [Server:node-B3] 	org.xml.sax.driver = __redirected.__XMLReaderFactory
> [Server:node-B3] 	os.arch = amd64
> [Server:node-B3] 	os.name = Linux
> [Server:node-B3] 	os.version = 2.6.32-431.3.1.el6.x86_64
> [Server:node-B3] 	path.separator = :
> [Server:node-B3] 	sun.arch.data.model = 64
> [Server:node-B3] 	sun.boot.class.path = /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.51.x86_64/jre/lib/resources.jar:/usr/lib/jvm/java-1.7.0-openjdk-1.7.0.51.x86_64/jre/lib/rt.jar:/usr/lib/jvm/java-1.7.0-openjdk-1.7.0.51.x86_64/jre/lib/sunrsasign.jar:/usr/lib/jvm/java-1.7.0-openjdk-1.7.0.51.x86_64/jre/lib/jsse.jar:/usr/lib/jvm/java-1.7.0-openjdk-1.7.0.51.x86_64/jre/lib/jce.jar:/usr/lib/jvm/java-1.7.0-openjdk-1.7.0.51.x86_64/jre/lib/charsets.jar:/usr/lib/jvm/java-1.7.0-openjdk-1.7.0.51.x86_64/jre/lib/netx.jar:/usr/lib/jvm/java-1.7.0-openjdk-1.7.0.51.x86_64/jre/lib/plugin.jar:/usr/lib/jvm/java-1.7.0-openjdk-1.7.0.51.x86_64/jre/lib/rhino.jar:/usr/lib/jvm/java-1.7.0-openjdk-1.7.0.51.x86_64/jre/lib/jfr.jar:/usr/lib/jvm/java-1.7.0-openjdk-1.7.0.51.x86_64/jre/classes
> [Server:node-B3] 	sun.boot.library.path = /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.51.x86_64/jre/lib/amd64
> [Server:node-B3] 	sun.cpu.endian = little
> [Server:node-B3] 	sun.cpu.isalist = 
> [Server:node-B3] 	sun.io.unicode.encoding = UnicodeLittle
> [Server:node-B3] 	sun.java.command = /local/myUser/dev/jboss/jboss-modules.jar -mp /local/myUser/dev/jboss/modules -jaxpmodule javax.xml.jaxp-provider org.jboss.as.server
> [Server:node-B3] 	sun.java.launcher = SUN_STANDARD
> [Server:node-B3] 	sun.jnu.encoding = UTF-8
> [Server:node-B3] 	sun.management.compiler = HotSpot 64-Bit Tiered Compilers
> [Server:node-B3] 	sun.os.patch.level = unknown
> [Server:node-B3] 	user.country = US
> [Server:node-B3] 	user.dir = /local/myUser/dev/jboss-eap-6.1
> [Server:node-B3] 	user.home = /home/myUser
> [Server:node-B3] 	user.language = en
> [Server:node-B3] 	user.name = myUser
> [Server:node-B3] 	user.timezone = Europe/Berlin
> [Server:node-B3] 15:06:25,736 DEBUG [org.jboss.as.config] (MSC service thread 1-8) VM Arguments: -D[Server:node-B3] -Xms512m -Xmx1024m -Djgroups.bind_addr=172.16.120.24 -D[Host Controller]=true -Djboss.bind.address=0.0.0.0 -Djava.awt.headless=true -Djboss.modules.system.pkgs=org.jboss.byteman -Djboss.home.dir=/local/myUser/dev/jboss -Djava.net.preferIPv4Stack=true -Djboss.server.log.dir=/local/myUser/dev/jboss/domain/servers/node-B3/log -Djboss.server.temp.dir=/local/myUser/dev/jboss/domain/servers/node-B3/tmp -Djboss.server.data.dir=/local/myUser/dev/jboss/domain/servers/node-B3/data -Dlogging.configuration=file:/local/myUser/dev/jboss/domain/servers/node-B3/data/logging.properties 
>            Reporter: neo infinite
>            Assignee: Eric Wittmann
>            Priority: Critical
>
> myuser at myhost/bin:jboss-cli.sh -c
> [domain at localhost:9999 /] read-operation read-children-types
> 	Gets the type names of all the children under the selected resource
> PARAMETERS
> 	n/a
> java.lang.IllegalArgumentException
> 	at org.jboss.dmr.ModelValue.asPropertyList(ModelValue.java:100)
> 	at org.jboss.dmr.ModelNode.asPropertyList(ModelNode.java:360)
> 	at org.jboss.as.cli.handlers.ReadOperationHandler.handleResponse(ReadOperationHandler.java:177)
> 	at org.jboss.as.cli.handlers.BaseOperationCommand.doHandle(BaseOperationCommand.java:213)
> 	at org.jboss.as.cli.handlers.CommandHandlerWithHelp.handle(CommandHandlerWithHelp.java:86)
> 	at org.jboss.as.cli.impl.CommandContextImpl.handle(CommandContextImpl.java:582)
> 	at org.jboss.as.cli.impl.CommandContextImpl.handleSafe(CommandContextImpl.java:598)
> 	at org.jboss.as.cli.impl.CommandContextImpl.interact(CommandContextImpl.java:1186)
> 	at org.jboss.as.cli.impl.CliLauncher.main(CliLauncher.java:259)
> 	at org.jboss.as.cli.CommandLineMain.main(CommandLineMain.java:34)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:606)
> 	at org.jboss.modules.Module.run(Module.java:270)
> 	at org.jboss.modules.Main.main(Main.java:411)
> myuser at myhost/bin:

--
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

From issues at jboss.org  Wed Mar 19 08:08:10 2014
From: issues at jboss.org (Paul Ferraro (JIRA))
Date: Wed, 19 Mar 2014 08:08:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3134) Upgrade Infinispan to
	6.0.2.Final
In-Reply-To: <JIRA.12535335.1395175678000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12535335.1395175678000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12535335.1395175678000.25925.1395230890835@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-3134?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Paul Ferraro closed WFLY-3134.
------------------------------

    Resolution: Rejected


Nevermind - this release contains nothing of relevance to WildFly.
                
> Upgrade Infinispan to 6.0.2.Final
> ---------------------------------
>
>                 Key: WFLY-3134
>                 URL: https://issues.jboss.org/browse/WFLY-3134
>             Project: WildFly
>          Issue Type: Component  Upgrade
>      Security Level: Public(Everyone can see) 
>          Components: Clustering
>    Affects Versions: 8.0.0.Final
>            Reporter: Paul Ferraro
>            Assignee: Paul Ferraro
>             Fix For: 8.0.1.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

From issues at jboss.org  Wed Mar 19 08:58:10 2014
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Wed, 19 Mar 2014 08:58:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (SECURITY-807) Add a LoginModule to wrap
 existing Kerberos LoginModule(s) and optionally add a GSSCredential
In-Reply-To: <JIRA.12535397.1395233801363@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12535397.1395233801363@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12535397.1395233801363.26013.1395233890887@jira02.app.mwc.hst.phx2.redhat.com>

Darran Lofthouse created SECURITY-807:
-----------------------------------------

             Summary: Add a LoginModule to wrap existing Kerberos LoginModule(s) and optionally add a GSSCredential
                 Key: SECURITY-807
                 URL: https://issues.jboss.org/browse/SECURITY-807
             Project: PicketBox 
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: Negotiation
            Reporter: Darran Lofthouse
            Assignee: Darran Lofthouse
            Priority: Critical
             Fix For: Negotiation_2_2_8




--
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

From issues at jboss.org  Wed Mar 19 09:06:10 2014
From: issues at jboss.org (Radoslav Husar (JIRA))
Date: Wed, 19 Mar 2014 09:06:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3134) Upgrade Infinispan to
	6.0.2.Final
In-Reply-To: <JIRA.12535335.1395175678000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12535335.1395175678000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12535335.1395175678000.26026.1395234370679@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-3134?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12954184#comment-12954184 ] 

Radoslav Husar commented on WFLY-3134:
--------------------------------------

Right, it's really just a re-release after licence change, which is part of WildFly anyway (http://blog.infinispan.org/2014/03/infinispan-602final-includes-asl2.html).
                
> Upgrade Infinispan to 6.0.2.Final
> ---------------------------------
>
>                 Key: WFLY-3134
>                 URL: https://issues.jboss.org/browse/WFLY-3134
>             Project: WildFly
>          Issue Type: Component  Upgrade
>      Security Level: Public(Everyone can see) 
>          Components: Clustering
>    Affects Versions: 8.0.0.Final
>            Reporter: Paul Ferraro
>            Assignee: Paul Ferraro
>             Fix For: 8.0.1.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

From issues at jboss.org  Wed Mar 19 09:20:10 2014
From: issues at jboss.org (Andrig Miller (JIRA))
Date: Wed, 19 Mar 2014 09:20:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBWEB-290) Optimize string literals
 inside jsp expressions
In-Reply-To: <JIRA.12533522.1393516764000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12533522.1393516764000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12533522.1393516764000.26082.1395235210735@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JBWEB-290?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12954189#comment-12954189 ] 

Andrig Miller commented on JBWEB-290:
-------------------------------------

In terms of being responsible for this code?  If so, we can take ownership of it (the performance team), I have no problem with that at all.  It's actually a fairly simple change, and its also been incorporated into upstream with Undertow as well.  So, Stuart is also familiar with the change.
                
> Optimize string literals inside jsp expressions 
> ------------------------------------------------
>
>                 Key: JBWEB-290
>                 URL: https://issues.jboss.org/browse/JBWEB-290
>             Project: JBoss Web
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Tomcat
>    Affects Versions: JBossWeb-3.0.0.Final
>            Reporter: John O'Hara
>            Assignee: Remy Maucherat
>             Fix For: JBossWeb-7.4.0.GA
>
>
> After setting genStringAsCharArray=true, we continue to see StringBuilder concatenating string literals for each jsp request for some of our jsp pages; instead of creating a static char[].
> This occurs when a string literal is included in a jsp expression, e.g.;
> <%="<INPUT type=\"hidden\" name=\"name\" value=\"" + obj.getName() + "\">"%>
> Is it possible to identify string literals inside expressions during the tokenization phase of parsing jsp pages in apache jasper and treat them as text nodes so that the apache jasper generator can apply the same optimizations as string literals outside the jsp expression?

--
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

From issues at jboss.org  Wed Mar 19 10:42:10 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 19 Mar 2014 10:42:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3099) management authorization
 throws an exception when an LDAP group contains a slash/backslash character
In-Reply-To: <JIRA.12534652.1394538171000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534652.1394538171000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534652.1394538171000.26470.1395240130727@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-3099?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12954237#comment-12954237 ] 

RH Bugzilla Integration commented on WFLY-3099:
-----------------------------------------------

Ondrej Lukas <olukas at redhat.com> changed the Status of [bug 1074560|https://bugzilla.redhat.com/show_bug.cgi?id=1074560] from ON_QA to VERIFIED
                
> management authorization throws an exception when an LDAP group contains a slash/backslash character
> ----------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-3099
>                 URL: https://issues.jboss.org/browse/WFLY-3099
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>    Affects Versions: 8.0.0.Final
>            Reporter: Tom Fonteyne
>            Assignee: Tom Fonteyne
>
> management authorization throws an exception when an LDAP group contains a slash/backslash character

--
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

From issues at jboss.org  Wed Mar 19 10:50:10 2014
From: issues at jboss.org (Sanne Grinovero (JIRA))
Date: Wed, 19 Mar 2014 10:50:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3134) Upgrade Infinispan to
	6.0.2.Final
In-Reply-To: <JIRA.12535335.1395175678000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12535335.1395175678000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12535335.1395175678000.26494.1395240610718@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-3134?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12954241#comment-12954241 ] 

Sanne Grinovero commented on WFLY-3134:
---------------------------------------

There might be more reasons to not update, but license is not the only change.

Infinispan 6.0.1.Final used JBoss Marshaller 1.3.18.GA
Infinispan 6.0.2.Final used JBoss Marshaller 1.4.4.Final and has a couple of lines changed to address a compatibility issue with this Marshaller version

WildFly (master as of today) is using Marshaller 1.4.3.Final; since there are no other differences between Infinispan 6.0.1 and 6.0.2 I think it would be safer to actually do the upgrade of both components.

                
> Upgrade Infinispan to 6.0.2.Final
> ---------------------------------
>
>                 Key: WFLY-3134
>                 URL: https://issues.jboss.org/browse/WFLY-3134
>             Project: WildFly
>          Issue Type: Component  Upgrade
>      Security Level: Public(Everyone can see) 
>          Components: Clustering
>    Affects Versions: 8.0.0.Final
>            Reporter: Paul Ferraro
>            Assignee: Paul Ferraro
>             Fix For: 8.0.1.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

From issues at jboss.org  Wed Mar 19 10:52:10 2014
From: issues at jboss.org (Sanne Grinovero (JIRA))
Date: Wed, 19 Mar 2014 10:52:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3134) Upgrade Infinispan to
	6.0.2.Final
In-Reply-To: <JIRA.12535335.1395175678000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12535335.1395175678000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12535335.1395175678000.26501.1395240730727@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-3134?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Sanne Grinovero reopened WFLY-3134:
-----------------------------------


    
> Upgrade Infinispan to 6.0.2.Final
> ---------------------------------
>
>                 Key: WFLY-3134
>                 URL: https://issues.jboss.org/browse/WFLY-3134
>             Project: WildFly
>          Issue Type: Component  Upgrade
>      Security Level: Public(Everyone can see) 
>          Components: Clustering
>    Affects Versions: 8.0.0.Final
>            Reporter: Paul Ferraro
>            Assignee: Paul Ferraro
>             Fix For: 8.0.1.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

From issues at jboss.org  Wed Mar 19 10:54:10 2014
From: issues at jboss.org (Radoslav Husar (JIRA))
Date: Wed, 19 Mar 2014 10:54:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3134) Upgrade Infinispan to
	6.0.2.Final
In-Reply-To: <JIRA.12535335.1395175678000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12535335.1395175678000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12535335.1395175678000.26511.1395240850859@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-3134?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12954242#comment-12954242 ] 

Radoslav Husar commented on WFLY-3134:
--------------------------------------

There are 2 code changes total in 6.0.2: 

https://github.com/infinispan/infinispan/commit/6591e90dc7f152acc8eed0fb1a8cd6ce30d1512c
https://github.com/infinispan/infinispan/commit/5ee8ef22571e6051e66d5deb77f8be3bc5631377
                
> Upgrade Infinispan to 6.0.2.Final
> ---------------------------------
>
>                 Key: WFLY-3134
>                 URL: https://issues.jboss.org/browse/WFLY-3134
>             Project: WildFly
>          Issue Type: Component  Upgrade
>      Security Level: Public(Everyone can see) 
>          Components: Clustering
>    Affects Versions: 8.0.0.Final
>            Reporter: Paul Ferraro
>            Assignee: Paul Ferraro
>             Fix For: 8.0.1.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

From issues at jboss.org  Wed Mar 19 11:02:10 2014
From: issues at jboss.org (Radoslav Husar (JIRA))
Date: Wed, 19 Mar 2014 11:02:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3134) Upgrade Infinispan to
 6.0.2.Final and JBoss Marshalling to 1.4.4.Final
In-Reply-To: <JIRA.12535335.1395175678000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12535335.1395175678000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12535335.1395175678000.26530.1395241330949@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-3134?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Radoslav Husar updated WFLY-3134:
---------------------------------

    Summary: Upgrade Infinispan to 6.0.2.Final and JBoss Marshalling to 1.4.4.Final  (was: Upgrade Infinispan to 6.0.2.Final)

    
> Upgrade Infinispan to 6.0.2.Final and JBoss Marshalling to 1.4.4.Final
> ----------------------------------------------------------------------
>
>                 Key: WFLY-3134
>                 URL: https://issues.jboss.org/browse/WFLY-3134
>             Project: WildFly
>          Issue Type: Component  Upgrade
>      Security Level: Public(Everyone can see) 
>          Components: Clustering
>    Affects Versions: 8.0.0.Final
>            Reporter: Paul Ferraro
>            Assignee: Paul Ferraro
>             Fix For: 8.0.1.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

From issues at jboss.org  Wed Mar 19 11:02:11 2014
From: issues at jboss.org (Radoslav Husar (JIRA))
Date: Wed, 19 Mar 2014 11:02:11 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3134) Upgrade Infinispan to
 6.0.2.Final and JBoss Marshalling to 1.4.4.Final
In-Reply-To: <JIRA.12535335.1395175678000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12535335.1395175678000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12535335.1395175678000.26534.1395241331188@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-3134?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Radoslav Husar reassigned WFLY-3134:
------------------------------------

    Assignee: Sanne Grinovero  (was: Paul Ferraro)

    
> Upgrade Infinispan to 6.0.2.Final and JBoss Marshalling to 1.4.4.Final
> ----------------------------------------------------------------------
>
>                 Key: WFLY-3134
>                 URL: https://issues.jboss.org/browse/WFLY-3134
>             Project: WildFly
>          Issue Type: Component  Upgrade
>      Security Level: Public(Everyone can see) 
>          Components: Clustering
>    Affects Versions: 8.0.0.Final
>            Reporter: Paul Ferraro
>            Assignee: Sanne Grinovero
>             Fix For: 8.0.1.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

From issues at jboss.org  Wed Mar 19 11:02:11 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 19 Mar 2014 11:02:11 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2950) jboss-cli using
 https-remoting: command not executed if certificate is unrecognised
In-Reply-To: <JIRA.12532472.1392721164000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12532472.1392721164000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12532472.1392721164000.26541.1395241331532@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2950?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12954245#comment-12954245 ] 

RH Bugzilla Integration commented on WFLY-2950:
-----------------------------------------------

Kabir Khan <kkhan at redhat.com> changed the Status of [bug 1026418|https://bugzilla.redhat.com/show_bug.cgi?id=1026418] from POST to MODIFIED
                
> jboss-cli using https-remoting: command not executed if certificate is unrecognised
> -----------------------------------------------------------------------------------
>
>                 Key: WFLY-2950
>                 URL: https://issues.jboss.org/browse/WFLY-2950
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: CLI, Domain Management
>    Affects Versions: 8.0.0.Final
>         Environment: Windows 7 Pro
>            Reporter: Darren Jones
>            Assignee: Darran Lofthouse
>              Labels: cli, shutdown
>             Fix For: 8.0.1.Final
>
>
> When using the https management interface from jboss-cli, commands passed with a command line option (such as --command=:shutdown) are not executed if the server certificate is unrecognised - even if accepting the certificate [T]emporarily or [P]ermenantly.
> It appears to be due to the CommandContextImpl.handleSSLFailure() method, which calls error("Unable to connect..."). The error() method sets the exitCode to 1. So, when CliLauncher.processCommands() subsequently runs, it sees that the cmdCtx.exitCode is 1 and ignores any commands.
> I guess the handleSSLFailure needs to reset the exitCode to 0 if the user chooses [T] or [P].

--
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

From issues at jboss.org  Wed Mar 19 11:02:11 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 19 Mar 2014 11:02:11 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2538) Certificate acceptance
 causing command entered on starting the CLI to be skipped.
In-Reply-To: <JIRA.12525580.1384872293000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12525580.1384872293000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12525580.1384872293000.26544.1395241331668@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2538?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12954246#comment-12954246 ] 

RH Bugzilla Integration commented on WFLY-2538:
-----------------------------------------------

Kabir Khan <kkhan at redhat.com> changed the Status of [bug 1026418|https://bugzilla.redhat.com/show_bug.cgi?id=1026418] from POST to MODIFIED
                
> Certificate acceptance causing command entered on starting the CLI to be skipped.
> ---------------------------------------------------------------------------------
>
>                 Key: WFLY-2538
>                 URL: https://issues.jboss.org/browse/WFLY-2538
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: CLI
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 8.0.0.CR1
>
>
> e.g.
> {noformat}
> ./jboss-cli.sh -c shutdown
> Accept certificate? [N]o, [T]emporarily, [P]ermenantly : T
> {noformat}
> The shutdown command is not executed.

--
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

From issues at jboss.org  Wed Mar 19 11:06:11 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 19 Mar 2014 11:06:11 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3133) Misleading error message for
 add-user username requirements.
In-Reply-To: <JIRA.12535314.1395166113000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12535314.1395166113000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12535314.1395166113000.26569.1395241571236@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-3133?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12954248#comment-12954248 ] 

RH Bugzilla Integration commented on WFLY-3133:
-----------------------------------------------

Kabir Khan <kkhan at redhat.com> changed the Status of [bug 1062611|https://bugzilla.redhat.com/show_bug.cgi?id=1062611] from POST to MODIFIED
                
> Misleading error message for add-user username requirements.
> ------------------------------------------------------------
>
>                 Key: WFLY-3133
>                 URL: https://issues.jboss.org/browse/WFLY-3133
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>    Affects Versions: 8.0.0.Final
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 8.0.1.Final
>
>
> The current error message is: -
> {code}
> JBAS015239: Only alpha/numeric usernames accepted.
> {code}
> However a small set of symbols are allowed.

--
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

From issues at jboss.org  Wed Mar 19 11:06:11 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 19 Mar 2014 11:06:11 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3130) Add a custom RuntimeException
 to add-user utility.
In-Reply-To: <JIRA.12535302.1395159229000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12535302.1395159229000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12535302.1395159229000.26571.1395241571342@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-3130?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12954249#comment-12954249 ] 

RH Bugzilla Integration commented on WFLY-3130:
-----------------------------------------------

Kabir Khan <kkhan at redhat.com> changed the Status of [bug 1062595|https://bugzilla.redhat.com/show_bug.cgi?id=1062595] from POST to MODIFIED
                
> Add a custom RuntimeException to add-user utility.
> --------------------------------------------------
>
>                 Key: WFLY-3130
>                 URL: https://issues.jboss.org/browse/WFLY-3130
>             Project: WildFly
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 8.0.1.Final
>
>
> The add-user utility uses a RuntimeException to indicate failure in non-interactive mode, this does not look good so should switch it to a custom exception of our own.

--
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

From issues at jboss.org  Wed Mar 19 11:06:11 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 19 Mar 2014 11:06:11 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3125) Update help text for add-user
 to reflect that password is checked against the configured policy.
In-Reply-To: <JIRA.12535263.1395145186000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12535263.1395145186000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12535263.1395145186000.26579.1395241571702@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-3125?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12954251#comment-12954251 ] 

RH Bugzilla Integration commented on WFLY-3125:
-----------------------------------------------

Kabir Khan <kkhan at redhat.com> changed the Status of [bug 1063888|https://bugzilla.redhat.com/show_bug.cgi?id=1063888] from POST to MODIFIED
                
> Update help text for add-user to reflect that password is checked against the configured policy.
> ------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-3125
>                 URL: https://issues.jboss.org/browse/WFLY-3125
>             Project: WildFly
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 8.0.1.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

From issues at jboss.org  Wed Mar 19 11:10:11 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 19 Mar 2014 11:10:11 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2408) Add TRACE logging for
 connection properties used to connect to LDAP from realm.
In-Reply-To: <JIRA.12509083.1383136851000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12509083.1383136851000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12509083.1383136851000.26594.1395241811149@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2408?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12954254#comment-12954254 ] 

RH Bugzilla Integration commented on WFLY-2408:
-----------------------------------------------

Kabir Khan <kkhan at redhat.com> changed the Status of [bug 974324|https://bugzilla.redhat.com/show_bug.cgi?id=974324] from POST to MODIFIED
                
> Add TRACE logging for connection properties used to connect to LDAP from realm.
> -------------------------------------------------------------------------------
>
>                 Key: WFLY-2408
>                 URL: https://issues.jboss.org/browse/WFLY-2408
>             Project: WildFly
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management, Security
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 8.0.0.CR1
>
>


--
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

From issues at jboss.org  Wed Mar 19 11:10:11 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 19 Mar 2014 11:10:11 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-352) Add sufficient TRACE / DEBUG
 logging to debug security realm configurations.
In-Reply-To: <JIRA.12489981.1366392604000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12489981.1366392604000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12489981.1366392604000.26601.1395241811494@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-352?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12954255#comment-12954255 ] 

RH Bugzilla Integration commented on WFLY-352:
----------------------------------------------

Kabir Khan <kkhan at redhat.com> changed the Status of [bug 974324|https://bugzilla.redhat.com/show_bug.cgi?id=974324] from POST to MODIFIED
                
> Add sufficient TRACE / DEBUG logging to debug security realm configurations.
> ----------------------------------------------------------------------------
>
>                 Key: WFLY-352
>                 URL: https://issues.jboss.org/browse/WFLY-352
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>            Reporter: Eric Rich
>            Assignee: Darran Lofthouse
>            Priority: Critical
>             Fix For: 8.0.0.Beta1
>
>         Attachments: jboss-as-domain-management-7.1.2.Final-redhat-1.jar, log_mgmt_auth_calls.txt
>
>
> When trying to diagnose LDAP or Admin Configuration issue in Domain mode there is currently no logging for any of the authentication information. 

--
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

From issues at jboss.org  Wed Mar 19 11:22:11 2014
From: issues at jboss.org (James Perkins (JIRA))
Date: Wed, 19 Mar 2014 11:22:11 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3139) Add MongoDB support for a
 batch repository type
In-Reply-To: <JIRA.12535421.1395242465954@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12535421.1395242465954@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12535421.1395242465954.26674.1395242531064@jira02.app.mwc.hst.phx2.redhat.com>

James Perkins created WFLY-3139:
-----------------------------------

             Summary: Add MongoDB support for a batch repository type
                 Key: WFLY-3139
                 URL: https://issues.jboss.org/browse/WFLY-3139
             Project: WildFly
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: Batch
            Reporter: James Perkins
            Assignee: James Perkins
            Priority: Minor


JBeret now supports MongoDB for a repository type. WildFly needs to integrate the new repository type as another option.

--
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

From issues at jboss.org  Wed Mar 19 11:50:11 2014
From: issues at jboss.org (Tom Fonteyne (JIRA))
Date: Wed, 19 Mar 2014 11:50:11 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3140) simply picketlink setup of an
 sp+idp delivers a 403
In-Reply-To: <JIRA.12535424.1395244096711@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12535424.1395244096711@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12535424.1395244096711.26723.1395244211391@jira02.app.mwc.hst.phx2.redhat.com>

Tom Fonteyne created WFLY-3140:
----------------------------------

             Summary: simply picketlink setup of an sp+idp delivers a 403
                 Key: WFLY-3140
                 URL: https://issues.jboss.org/browse/WFLY-3140
             Project: WildFly
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Security
    Affects Versions: 8.0.0.Final
            Reporter: Tom Fonteyne
            Assignee: Darran Lofthouse
            Priority: Critical
         Attachments: plhello.war, plidp.war

A simple picket links setup of an sp and an idp. Accessing the sp, simply delivers "403 - Forbidden"

The same security domains and the identical sp/idp war deployed on EAP 6.1.1 work fine

--
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

From issues at jboss.org  Wed Mar 19 11:50:12 2014
From: issues at jboss.org (Tom Fonteyne (JIRA))
Date: Wed, 19 Mar 2014 11:50:12 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3140) simply picketlink setup of an
 sp+idp delivers a 403
In-Reply-To: <JIRA.12535424.1395244096000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12535424.1395244096000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12535424.1395244096000.26735.1395244212041@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-3140?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tom Fonteyne updated WFLY-3140:
-------------------------------

    Assignee: Anil Saldhana  (was: Darran Lofthouse)

    
> simply picketlink setup of an sp+idp delivers a 403
> ---------------------------------------------------
>
>                 Key: WFLY-3140
>                 URL: https://issues.jboss.org/browse/WFLY-3140
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Security
>    Affects Versions: 8.0.0.Final
>            Reporter: Tom Fonteyne
>            Assignee: Anil Saldhana
>            Priority: Critical
>         Attachments: plhello.war, plidp.war
>
>
> A simple picket links setup of an sp and an idp. Accessing the sp, simply delivers "403 - Forbidden"
> The same security domains and the identical sp/idp war deployed on EAP 6.1.1 work fine

--
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

From issues at jboss.org  Wed Mar 19 11:50:12 2014
From: issues at jboss.org (Tom Fonteyne (JIRA))
Date: Wed, 19 Mar 2014 11:50:12 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3140) simply picketlink setup of an
 sp+idp delivers a 403
In-Reply-To: <JIRA.12535424.1395244096000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12535424.1395244096000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12535424.1395244096000.26738.1395244212213@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-3140?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tom Fonteyne updated WFLY-3140:
-------------------------------

    Attachment: plidp.war
                plhello.war

    
> simply picketlink setup of an sp+idp delivers a 403
> ---------------------------------------------------
>
>                 Key: WFLY-3140
>                 URL: https://issues.jboss.org/browse/WFLY-3140
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Security
>    Affects Versions: 8.0.0.Final
>            Reporter: Tom Fonteyne
>            Assignee: Anil Saldhana
>            Priority: Critical
>         Attachments: plhello.war, plidp.war
>
>
> A simple picket links setup of an sp and an idp. Accessing the sp, simply delivers "403 - Forbidden"
> The same security domains and the identical sp/idp war deployed on EAP 6.1.1 work fine

--
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

From issues at jboss.org  Wed Mar 19 11:52:11 2014
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Wed, 19 Mar 2014 11:52:11 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (SECURITY-807) Add a LoginModule to wrap
 existing Kerberos LoginModule(s) and optionally add a GSSCredential
In-Reply-To: <JIRA.12535397.1395233801000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12535397.1395233801000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12535397.1395233801000.26758.1395244331214@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/SECURITY-807?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated SECURITY-807:
--------------------------------------

    Fix Version/s:     (was: Negotiation_2_2_8)

    
> Add a LoginModule to wrap existing Kerberos LoginModule(s) and optionally add a GSSCredential
> ---------------------------------------------------------------------------------------------
>
>                 Key: SECURITY-807
>                 URL: https://issues.jboss.org/browse/SECURITY-807
>             Project: PicketBox 
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Negotiation
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>            Priority: Critical
>


--
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

From issues at jboss.org  Wed Mar 19 11:52:11 2014
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Wed, 19 Mar 2014 11:52:11 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (SECURITY-807) Add a LoginModule to wrap
 existing Kerberos LoginModule(s) and optionally add a GSSCredential
In-Reply-To: <JIRA.12535397.1395233801000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12535397.1395233801000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12535397.1395233801000.26762.1395244331412@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/SECURITY-807?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated SECURITY-807:
--------------------------------------

    Fix Version/s: Negotiation_2_3_0_CR1

    
> Add a LoginModule to wrap existing Kerberos LoginModule(s) and optionally add a GSSCredential
> ---------------------------------------------------------------------------------------------
>
>                 Key: SECURITY-807
>                 URL: https://issues.jboss.org/browse/SECURITY-807
>             Project: PicketBox 
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Negotiation
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>            Priority: Critical
>             Fix For: Negotiation_2_3_0_CR1
>
>


--
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

From issues at jboss.org  Wed Mar 19 11:54:11 2014
From: issues at jboss.org (Tristan Tarrant (JIRA))
Date: Wed, 19 Mar 2014 11:54:11 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3134) Upgrade Infinispan to
 6.0.2.Final and JBoss Marshalling to 1.4.4.Final
In-Reply-To: <JIRA.12535335.1395175678000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12535335.1395175678000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12535335.1395175678000.26774.1395244451075@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-3134?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12954286#comment-12954286 ] 

Tristan Tarrant commented on WFLY-3134:
---------------------------------------

Yes, and if you ever upgrade to JBoss Marshaller 1.4.4.Final you will need to upgrade to Infinispan 6.0.2 since the serialization format of ECHM had to change.
                
> Upgrade Infinispan to 6.0.2.Final and JBoss Marshalling to 1.4.4.Final
> ----------------------------------------------------------------------
>
>                 Key: WFLY-3134
>                 URL: https://issues.jboss.org/browse/WFLY-3134
>             Project: WildFly
>          Issue Type: Component  Upgrade
>      Security Level: Public(Everyone can see) 
>          Components: Clustering
>    Affects Versions: 8.0.0.Final
>            Reporter: Paul Ferraro
>            Assignee: Sanne Grinovero
>             Fix For: 8.0.1.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

From issues at jboss.org  Wed Mar 19 11:56:10 2014
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Wed, 19 Mar 2014 11:56:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3140) simply picketlink setup of an
 sp+idp delivers a 403
In-Reply-To: <JIRA.12535424.1395244096000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12535424.1395244096000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12535424.1395244096000.26788.1395244570743@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-3140?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFLY-3140:
-----------------------------------

    Assignee: Pedro Igor  (was: Anil Saldhana)

    
> simply picketlink setup of an sp+idp delivers a 403
> ---------------------------------------------------
>
>                 Key: WFLY-3140
>                 URL: https://issues.jboss.org/browse/WFLY-3140
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Security
>    Affects Versions: 8.0.0.Final
>            Reporter: Tom Fonteyne
>            Assignee: Pedro Igor
>            Priority: Critical
>         Attachments: plhello.war, plidp.war
>
>
> A simple picket links setup of an sp and an idp. Accessing the sp, simply delivers "403 - Forbidden"
> The same security domains and the identical sp/idp war deployed on EAP 6.1.1 work fine

--
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

From issues at jboss.org  Wed Mar 19 12:00:12 2014
From: issues at jboss.org (Radoslav Husar (JIRA))
Date: Wed, 19 Mar 2014 12:00:12 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3134) Upgrade Infinispan to
 6.0.2.Final and JBoss Marshalling to 1.4.4.Final
In-Reply-To: <JIRA.12535335.1395175678000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12535335.1395175678000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12535335.1395175678000.26837.1395244812866@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-3134?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12954292#comment-12954292 ] 

Radoslav Husar commented on WFLY-3134:
--------------------------------------

Yes, that's the plan: https://github.com/wildfly/wildfly/pull/6057/files
                
> Upgrade Infinispan to 6.0.2.Final and JBoss Marshalling to 1.4.4.Final
> ----------------------------------------------------------------------
>
>                 Key: WFLY-3134
>                 URL: https://issues.jboss.org/browse/WFLY-3134
>             Project: WildFly
>          Issue Type: Component  Upgrade
>      Security Level: Public(Everyone can see) 
>          Components: Clustering
>    Affects Versions: 8.0.0.Final
>            Reporter: Paul Ferraro
>            Assignee: Sanne Grinovero
>             Fix For: 8.0.1.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

From issues at jboss.org  Wed Mar 19 12:56:10 2014
From: issues at jboss.org (Paul Ferraro (JIRA))
Date: Wed, 19 Mar 2014 12:56:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3134) Upgrade Infinispan to
 6.0.2.Final and JBoss Marshalling to 1.4.4.Final
In-Reply-To: <JIRA.12535335.1395175678000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12535335.1395175678000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12535335.1395175678000.26950.1395248170837@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-3134?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12954311#comment-12954311 ] 

Paul Ferraro commented on WFLY-3134:
------------------------------------

OK - sounds good.
                
> Upgrade Infinispan to 6.0.2.Final and JBoss Marshalling to 1.4.4.Final
> ----------------------------------------------------------------------
>
>                 Key: WFLY-3134
>                 URL: https://issues.jboss.org/browse/WFLY-3134
>             Project: WildFly
>          Issue Type: Component  Upgrade
>      Security Level: Public(Everyone can see) 
>          Components: Clustering
>    Affects Versions: 8.0.0.Final
>            Reporter: Paul Ferraro
>            Assignee: Sanne Grinovero
>             Fix For: 8.0.1.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

From issues at jboss.org  Wed Mar 19 13:16:11 2014
From: issues at jboss.org (Pedro Igor (JIRA))
Date: Wed, 19 Mar 2014 13:16:11 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3140) simply picketlink setup of an
 sp+idp delivers a 403
In-Reply-To: <JIRA.12535424.1395244096000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12535424.1395244096000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12535424.1395244096000.26987.1395249371962@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-3140?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12954314#comment-12954314 ] 

Pedro Igor commented on WFLY-3140:
----------------------------------

Hi Tom,

    WildFly 8.0.0.Final is shipped with PicketLink 2.5.2.Final version. This version is not fully integrated with Undertow, so you won't be able to use the federation features. Beside that, Undertow 1.0.0.Final has an issue that is a blocker to get PL fully functional.

    PicketLink SAML is working in WildFly 8.0.1 (upstream) when using PicketLink 2.6.0.CR1, which provides all the necessary integration to Undertow.

    Please take a look at this workspace [1], which I'm working to get as much tests scenarios as possible for PicketLink Federation. Currently, this workspace is using EAP 6.3 and WildFly 8.0.1 during the tests.

[1] https://github.com/pedroigor/picketlink-tests

Regards.
Pedro Igor
                
> simply picketlink setup of an sp+idp delivers a 403
> ---------------------------------------------------
>
>                 Key: WFLY-3140
>                 URL: https://issues.jboss.org/browse/WFLY-3140
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Security
>    Affects Versions: 8.0.0.Final
>            Reporter: Tom Fonteyne
>            Assignee: Pedro Igor
>            Priority: Critical
>         Attachments: plhello.war, plidp.war
>
>
> A simple picket links setup of an sp and an idp. Accessing the sp, simply delivers "403 - Forbidden"
> The same security domains and the identical sp/idp war deployed on EAP 6.1.1 work fine

--
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

From issues at jboss.org  Wed Mar 19 14:30:11 2014
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Wed, 19 Mar 2014 14:30:11 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3141) Change the ModuleMap to map
 Kerberos to the new JBoss Negotiation KerberosLoginModule
In-Reply-To: <JIRA.12535469.1395253702914@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12535469.1395253702914@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12535469.1395253702914.27245.1395253811408@jira02.app.mwc.hst.phx2.redhat.com>

Darran Lofthouse created WFLY-3141:
--------------------------------------

             Summary: Change the ModuleMap to map Kerberos to the new JBoss Negotiation KerberosLoginModule
                 Key: WFLY-3141
                 URL: https://issues.jboss.org/browse/WFLY-3141
             Project: WildFly
          Issue Type: Task
      Security Level: Public (Everyone can see)
          Components: Security
            Reporter: Darran Lofthouse
            Assignee: Darran Lofthouse
             Fix For: 9.0.0.CR1


At the moment the ModuleOptions map maps the Kerberos short name to the com.sun LoginModule, instead map to the JBoss Negotation KerberosLoginModule which adds two new capabilities: -

 1 - Wrap instantiation of whichever module is actually available.

Note: It does not translate options from one to the other so those are still JDK specific.

 2 - Adds an addGSSCredential option so that the module will add a GSSCredential to the Subject.

This part is needed where the returned Subject is then going to be used with JCA.

--
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

From issues at jboss.org  Wed Mar 19 15:16:11 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 19 Mar 2014 15:16:11 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2474) Security subsystem does not
 handle acl's module properly, and is missing transformer
In-Reply-To: <JIRA.12524602.1383913636000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12524602.1383913636000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12524602.1383913636000.27414.1395256571880@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2474?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12954377#comment-12954377 ] 

RH Bugzilla Integration commented on WFLY-2474:
-----------------------------------------------

Kabir Khan <kkhan at redhat.com> changed the Status of [bug 1029938|https://bugzilla.redhat.com/show_bug.cgi?id=1029938] from POST to MODIFIED
                
> Security subsystem does not handle acl's module properly, and is missing transformer
> ------------------------------------------------------------------------------------
>
>                 Key: WFLY-2474
>                 URL: https://issues.jboss.org/browse/WFLY-2474
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Kabir Khan
>            Assignee: Kabir Khan
>             Fix For: 8.0.0.CR1
>
>
> The parsed add is done for /subsystem=security/security-domain=other/acl=classic/acl-module=acl
> However in the acl resource this is called login-module=acl.
> WHen marshalling
> {code}
> 	<acl>
> 	   <acl-module name="acl" code="AclThingy" flag="required" module="test">
>                 <module-option name="d" value="r"/>
> 	   </acl-module>
> 	</acl>
> {code}
> becomes
> {code}
> 	<acl>
> 	   <login-module name="acl" code="AclThingy" flag="required" module="test">
>                 <module-option name="d" value="r"/>
> 	   </login-module>
> 	</acl>
> {code}

--
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

From issues at jboss.org  Wed Mar 19 15:50:14 2014
From: issues at jboss.org (Scott Marlow (JIRA))
Date: Wed, 19 Mar 2014 15:50:14 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3105) Container-managed EXTENDED
 persistence context is always joined with transaction even if
 UNSYNCHRONIZED
In-Reply-To: <JIRA.12534789.1394637157000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534789.1394637157000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534789.1394637157000.27572.1395258614224@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-3105?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12954395#comment-12954395 ] 

Scott Marlow commented on WFLY-3105:
------------------------------------

Hmm, sounds like a bug in [https://github.com/wildfly/wildfly/blob/master/jpa/src/main/java/org/jboss/as/jpa/container/ExtendedEntityManager.java#L136] and [https://github.com/wildfly/wildfly/blob/master/jpa/src/main/java/org/jboss/as/jpa/transaction/TransactionUtil.java#L82]

>From 7.6.1 Persistence Context Synchronization Type XPC can also be UNSYNCHRONIZED:
{quote}
By default, a container-managed persistence context is of type SynchronizationType.SYNCHRONIZED. Such a persistence context is automatically joined to the current JTA transaction, and updates made to the persistence context are propagated to the underlying resource manager.

A container-managed persistence context may be specified to be of type SynchronizationType.UNSYNCHRONIZED. A persistence context of type SynchronizationType.UNSYNCHRONIZED is not enlisted in any JTA transaction unless explicitly joined to that transaction by the application. A persistence context of type SynchronizationType.UNSYNCHRONIZED is enlisted in a JTA transaction and registered for subsequent transaction notifications against that transaction by the invocation of the EntityManager joinTransaction method. The persistence context remains joined to the transaction until the transaction commits or rolls back. After the transaction commits or rolls back, the persistence context will not be joined to any subsequent transaction unless the joinTransaction method is invoked in the scope of that subsequent transaction.

A persistence context of type SynchronizationType.UNSYNCHRONIZED must not be flushed to the database unless it is joined to a transaction. The application's use of queries with pessimistic locks, bulk update or delete queries, etc. result in the provider throwing the TransactionRequiredException. After the persistence context has been joined to the JTA transaction, these operations are again allowed.

The application is permitted to invoke the persist, merge, remove, and refresh entity lifecycle operations on an entity manager of type SynchronizationType.UNSYNCHRONIZED independent of whether the persistence context is joined to the current transaction. After the persistence context has been joined to a transaction, changes in a persistence context can be flushed to the database either explicitly by the application or by the provider. If the flush method is not explicitly invoked, the persistence provider may defer flushing until commit time depending on the operations invoked and the flush mode setting in effect.

If an extended persistence context of type SynchronizationType.UNSYNCHRONIZED has not been joined to the current JTA transaction, rollback of the JTA transaction will have no effect upon the persistence context. In general, it is recommended that a non-JTA datasource be specified for use by the persistence provider for a persistence context of type SynchronizationType.UNSYNCHRONIZED that has not been joined to a JTA transaction in order to alleviate the risk of integrating uncommitted changes into the persistence context in the event that the transaction is later rolled back.

If a persistence context of type SynchronizationType.UNSYNCHRONIZED has been joined to the JTA transaction, transaction rollback will cause the persistence context to be cleared and all pre-existing managed and removed instances to become detached. (See section 3.3.3.)

When a JTA transaction exists, a persistence context of type SynchronizationType.UNSYNCHRONIZED is propagated with that transaction according to the rules in section 7.6.4.1 regardless of whether the persistence context has been joined to that transaction.
{quote}


                
> Container-managed EXTENDED persistence context is always joined with transaction even if UNSYNCHRONIZED
> -------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-3105
>                 URL: https://issues.jboss.org/browse/WFLY-3105
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JPA / Hibernate
>    Affects Versions: 8.0.0.Final
>            Reporter: Christian Bauer
>            Assignee: Scott Marlow
>
> https://github.com/weld/wildfly/blob/master/testsuite/integration/basic/src/test/java/org/jboss/as/test/integration/jpa/transaction/UnsynchronizedSFSB.jav
> Change this test to {code}@PersistenceContext(type = EXTENDED, synchronization = UNSYNCHRONIZED){code} and it will break. 
> Looks like an extended PC is always joined to the transaction and flushed on commit, the unsynchronized mode is ignored. From what I can see this is not specified and indeed would make the whole new UNSYNCHRONIZED feature kind of pointless. It's primary use case is propagation of unflushed/unsynchronized extended PC from a SFSB to other beans while keeping transactions intact.

--
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

From issues at jboss.org  Wed Mar 19 15:50:14 2014
From: issues at jboss.org (Scott Marlow (JIRA))
Date: Wed, 19 Mar 2014 15:50:14 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3105) Container-managed EXTENDED
 persistence context is always joined with transaction even if
 UNSYNCHRONIZED
In-Reply-To: <JIRA.12534789.1394637157000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534789.1394637157000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534789.1394637157000.27576.1395258614423@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-3105?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Scott Marlow updated WFLY-3105:
-------------------------------

    Fix Version/s: 8.0.1.Final

    
> Container-managed EXTENDED persistence context is always joined with transaction even if UNSYNCHRONIZED
> -------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-3105
>                 URL: https://issues.jboss.org/browse/WFLY-3105
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JPA / Hibernate
>    Affects Versions: 8.0.0.Final
>            Reporter: Christian Bauer
>            Assignee: Scott Marlow
>             Fix For: 8.0.1.Final
>
>
> https://github.com/weld/wildfly/blob/master/testsuite/integration/basic/src/test/java/org/jboss/as/test/integration/jpa/transaction/UnsynchronizedSFSB.jav
> Change this test to {code}@PersistenceContext(type = EXTENDED, synchronization = UNSYNCHRONIZED){code} and it will break. 
> Looks like an extended PC is always joined to the transaction and flushed on commit, the unsynchronized mode is ignored. From what I can see this is not specified and indeed would make the whole new UNSYNCHRONIZED feature kind of pointless. It's primary use case is propagation of unflushed/unsynchronized extended PC from a SFSB to other beans while keeping transactions intact.

--
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

From issues at jboss.org  Wed Mar 19 16:44:10 2014
From: issues at jboss.org (Farah Juma (JIRA))
Date: Wed, 19 Mar 2014 16:44:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3120) Upgrade JSF based on Mojarra
	2.2.6 Final
In-Reply-To: <JIRA.12535059.1394816991000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12535059.1394816991000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12535059.1394816991000.27704.1395261850554@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-3120?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12954405#comment-12954405 ] 

Farah Juma commented on WFLY-3120:
----------------------------------

The patch for JAVASERVERFACES-3189 was committed upstream this week to Mojarra's 2.2.x branch but had to be reverted due to failures that are now occurring with their Cactus-based tests. I'm looking into this. Since this fix was included in jsf-impl-2.2.6-jbossorg-1, I've created a jbossorg-2 version that reverts this fix for now.
                
> Upgrade JSF based on Mojarra 2.2.6 Final
> ----------------------------------------
>
>                 Key: WFLY-3120
>                 URL: https://issues.jboss.org/browse/WFLY-3120
>             Project: WildFly
>          Issue Type: Component  Upgrade
>      Security Level: Public(Everyone can see) 
>          Components: JSF
>    Affects Versions: 8.0.0.Final
>            Reporter: Farah Juma
>            Assignee: Farah Juma
>
> Upgrade JSF based on Mojarra 2.2.6 Final. Also incorporate the patch for WFLY-2594/[JAVASERVERFACES-3189|https://java.net/jira/browse/JAVASERVERFACES-3189] for WildFly 8.0.1.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

From issues at jboss.org  Wed Mar 19 16:46:11 2014
From: issues at jboss.org (Farah Juma (JIRA))
Date: Wed, 19 Mar 2014 16:46:11 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3120) Upgrade JSF based on Mojarra
	2.2.6 Final
In-Reply-To: <JIRA.12535059.1394816991000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12535059.1394816991000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12535059.1394816991000.27707.1395261971723@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-3120?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Farah Juma updated WFLY-3120:
-----------------------------

    Fix Version/s: 8.0.1.Final

    
> Upgrade JSF based on Mojarra 2.2.6 Final
> ----------------------------------------
>
>                 Key: WFLY-3120
>                 URL: https://issues.jboss.org/browse/WFLY-3120
>             Project: WildFly
>          Issue Type: Component  Upgrade
>      Security Level: Public(Everyone can see) 
>          Components: JSF
>    Affects Versions: 8.0.0.Final
>            Reporter: Farah Juma
>            Assignee: Farah Juma
>             Fix For: 8.0.1.Final
>
>
> Upgrade JSF based on Mojarra 2.2.6 Final. Also incorporate the patch for WFLY-2594/[JAVASERVERFACES-3189|https://java.net/jira/browse/JAVASERVERFACES-3189] for WildFly 8.0.1.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

From issues at jboss.org  Wed Mar 19 17:16:11 2014
From: issues at jboss.org (Paul Gier (JIRA))
Date: Wed, 19 Mar 2014 17:16:11 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3142) Upgrade JBoss Modules to
	1.3.3.Final
In-Reply-To: <JIRA.12535513.1395263745293@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12535513.1395263745293@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12535513.1395263745293.27746.1395263771573@jira02.app.mwc.hst.phx2.redhat.com>

Paul Gier created WFLY-3142:
-------------------------------

             Summary: Upgrade JBoss Modules to 1.3.3.Final
                 Key: WFLY-3142
                 URL: https://issues.jboss.org/browse/WFLY-3142
             Project: WildFly
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
            Reporter: Paul Gier


Upgrade JBoss Modules to 1.3.3.Final to stay in sync with EAP

--
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

From issues at jboss.org  Wed Mar 19 17:18:10 2014
From: issues at jboss.org (Paul Gier (JIRA))
Date: Wed, 19 Mar 2014 17:18:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3142) Upgrade JBoss Modules to
	1.3.3.Final
In-Reply-To: <JIRA.12535513.1395263745000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12535513.1395263745000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12535513.1395263745000.27748.1395263890536@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-3142?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Paul Gier updated WFLY-3142:
----------------------------

    Issue Type: Component  Upgrade  (was: Feature Request)

    
> Upgrade JBoss Modules to 1.3.3.Final
> ------------------------------------
>
>                 Key: WFLY-3142
>                 URL: https://issues.jboss.org/browse/WFLY-3142
>             Project: WildFly
>          Issue Type: Component  Upgrade
>      Security Level: Public(Everyone can see) 
>            Reporter: Paul Gier
>
> Upgrade JBoss Modules to 1.3.3.Final to stay in sync with EAP

--
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

From issues at jboss.org  Wed Mar 19 19:04:10 2014
From: issues at jboss.org (Stuart Douglas (JIRA))
Date: Wed, 19 Mar 2014 19:04:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2751) h:inputFile and max-file-size
In-Reply-To: <JIRA.12529408.1389714544000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529408.1389714544000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529408.1389714544000.27871.1395270250709@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2751?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stuart Douglas resolved WFLY-2751.
----------------------------------

    Resolution: Out of Date


This should have been fixed by CDI lazy conversation activation.
                
> h:inputFile and max-file-size
> -----------------------------
>
>                 Key: WFLY-2751
>                 URL: https://issues.jboss.org/browse/WFLY-2751
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: CDI / Weld
>    Affects Versions: 8.0.0.CR1
>         Environment: Open JDK 7, Cent OS
>            Reporter: Andre Pankraz
>            Assignee: Stuart Douglas
>
> If I use h:inputFile (JSF) together with something like e.g.:
> 	<servlet>
> 		<servlet-name>Faces Servlet</servlet-name>
> 		<servlet-class>javax.faces.webapp.FacesServlet</servlet-class>
> 		<load-on-startup>1</load-on-startup>
> 		<multipart-config>
> 			<location>/tmp</location>
> 			<max-file-size>1000</max-file-size>
> 			<max-request-size>2000</max-request-size>
> 			<file-size-threshold>500</file-size-threshold>
> 		</multipart-config>
> 	</servlet>
> and I upload a file which exceeds the max-file-size, I get an exception in the attached style (below).
> I cannot really react to this exception in JSF (global exception handler will not notice this because exception not in context of faces servlet) or in web-xml exception-handlers (to generic RuntimeException, not even an IllegalArgumentException like in spec?!).
> I would expect that this heavily restricts the usability if this new JSF component? I could switch off the restrictions and write a custom validator to check the part-size, but this is not very secure - the to large file is then already written to the given folder?!
> Exception is:
> 16:08:06,837 ERROR [io.undertow.request] (default task-14) Servlet request failed HttpServerExchange{ POST /...Upload.xhtml}: java.lang.RuntimeException: java.io.IOException: UT000054: The maximum size 1000 for an individual file in a multipart request was exceeded
> 	at io.undertow.servlet.spec.HttpServletRequestImpl.parseFormData(HttpServletRequestImpl.java:705) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.servlet.spec.HttpServletRequestImpl.getParameter(HttpServletRequestImpl.java:577) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at org.jboss.weld.servlet.ConversationContextActivator.getConversationId(ConversationContextActivator.java:124) [weld-core-impl-2.1.0.Final.jar:2013-10-11 10:25]
> 	at org.jboss.weld.servlet.ConversationContextActivator.activateConversationContext(ConversationContextActivator.java:91) [weld-core-impl-2.1.0.Final.jar:2013-10-11 10:25]
> 	at org.jboss.weld.servlet.ConversationContextActivator.startConversationContext(ConversationContextActivator.java:79) [weld-core-impl-2.1.0.Final.jar:2013-10-11 10:25]
> 	at org.jboss.weld.servlet.ConversationFilter.doFilter(ConversationFilter.java:68) [weld-core-impl-2.1.0.Final.jar:2013-10-11 10:25]
> 	at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:56) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at de.init.xrepository.util.filter.CharacterEncodingFilter.doFilter(CharacterEncodingFilter.java:29) [classes:]
> 	at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:56) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at de.init.xrepository.util.PageExpiryFilter.doFilter(PageExpiryFilter.java:166) [classes:]
> 	at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:56) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:85) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:93) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:81)
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:113) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.security.handlers.AuthenticationCallHandler.handleRequest(AuthenticationCallHandler.java:52) [undertow-core-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:51) [undertow-core-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) [undertow-core-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:55) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58) [undertow-core-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:65) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:70) [undertow-core-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:218) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:205) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:69) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:134) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.server.Connectors.executeRootHandler(Connectors.java:138) [undertow-core-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:622) [undertow-core-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_45]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_45]
> 	at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_45]
> Caused by: java.io.IOException: UT000054: The maximum size 1000 for an individual file in a multipart request was exceeded
> 	at io.undertow.server.handlers.form.MultiPartParserDefinition$MultiPartUploadHandler.data(MultiPartParserDefinition.java:246) [undertow-core-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.util.MultipartParser$IdentityEncoding.handle(MultipartParser.java:328) [undertow-core-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.util.MultipartParser$ParseState.entity(MultipartParser.java:306) [undertow-core-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.util.MultipartParser$ParseState.parse(MultipartParser.java:111) [undertow-core-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.server.handlers.form.MultiPartParserDefinition$MultiPartUploadHandler.parseBlocking(MultiPartParserDefinition.java:196) [undertow-core-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.servlet.spec.HttpServletRequestImpl.parseFormData(HttpServletRequestImpl.java:703) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	... 37 more

--
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

From issues at jboss.org  Wed Mar 19 19:08:10 2014
From: issues at jboss.org (Stuart Douglas (JIRA))
Date: Wed, 19 Mar 2014 19:08:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3137) logging errors in destroying
 a requestscoped entitymanager
In-Reply-To: <JIRA.12535360.1395201803000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12535360.1395201803000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12535360.1395201803000.27874.1395270490686@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-3137?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12954437#comment-12954437 ] 

Stuart Douglas commented on WFLY-3137:
--------------------------------------

The entity manager is a container managed transaction scoped entity manager, calling close will result in an error. 

All you really need is: 

@PersistenceContext(unitName = mydatasource)
@Produces
@MyEm
private EntityManager em;

The EM is automatically closed at transaction commit/rollback time.
                
> logging errors in destroying a requestscoped entitymanager
> ----------------------------------------------------------
>
>                 Key: WFLY-3137
>                 URL: https://issues.jboss.org/browse/WFLY-3137
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: CDI / Weld
>    Affects Versions: 8.0.0.Final
>         Environment: window 7 64bits, javaee 1.7
>            Reporter: Richard Yang
>            Assignee: Stuart Douglas
>
> I have a simple producer for a requestscoped entitymanager:
> @PersistenceContext(unitName = mydatasource)
> 	private EntityManager em;
> @Produces
> 	@myEM
> 	@RequestScoped
> 	protected EntityManager createEntityManager() {
> 		return em;
> 	}
> 	protected void closeEntityManager(
> 			@Disposes @myEM EntityManager entityManager) {
> 		if (entityManager.isOpen()) {
> 			entityManager.close();
> 		}
> 	}
> I inject this to applicationScoped bean. In the log, I see for each close of entityManager, wildfly logs an error:
> WELD-000019: Error destroying an instance org.jboss.as.jpa.container.TransactionScopedEntityManager at 7c213180 of Producer Method [EntityManager] with qualifiers [@myEM @Any] declared as [[BackedAnnotatedMethod] @Produces @myEM @RequestScoped protected createEntityManager()]

--
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

From issues at jboss.org  Wed Mar 19 19:08:10 2014
From: issues at jboss.org (Stuart Douglas (JIRA))
Date: Wed, 19 Mar 2014 19:08:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3137) logging errors in destroying
 a requestscoped entitymanager
In-Reply-To: <JIRA.12535360.1395201803000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12535360.1395201803000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12535360.1395201803000.27877.1395270490827@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-3137?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stuart Douglas resolved WFLY-3137.
----------------------------------

    Resolution: Rejected

    
> logging errors in destroying a requestscoped entitymanager
> ----------------------------------------------------------
>
>                 Key: WFLY-3137
>                 URL: https://issues.jboss.org/browse/WFLY-3137
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: CDI / Weld
>    Affects Versions: 8.0.0.Final
>         Environment: window 7 64bits, javaee 1.7
>            Reporter: Richard Yang
>            Assignee: Stuart Douglas
>
> I have a simple producer for a requestscoped entitymanager:
> @PersistenceContext(unitName = mydatasource)
> 	private EntityManager em;
> @Produces
> 	@myEM
> 	@RequestScoped
> 	protected EntityManager createEntityManager() {
> 		return em;
> 	}
> 	protected void closeEntityManager(
> 			@Disposes @myEM EntityManager entityManager) {
> 		if (entityManager.isOpen()) {
> 			entityManager.close();
> 		}
> 	}
> I inject this to applicationScoped bean. In the log, I see for each close of entityManager, wildfly logs an error:
> WELD-000019: Error destroying an instance org.jboss.as.jpa.container.TransactionScopedEntityManager at 7c213180 of Producer Method [EntityManager] with qualifiers [@myEM @Any] declared as [[BackedAnnotatedMethod] @Produces @myEM @RequestScoped protected createEntityManager()]

--
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

From issues at jboss.org  Wed Mar 19 19:38:10 2014
From: issues at jboss.org (Stuart Douglas (JIRA))
Date: Wed, 19 Mar 2014 19:38:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2859) Treating all JAX-RS
 components as CDI Beans has some negative consequences
In-Reply-To: <JIRA.12531039.1391445501000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12531039.1391445501000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12531039.1391445501000.27879.1395272290617@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2859?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12954438#comment-12954438 ] 

Stuart Douglas commented on WFLY-2859:
--------------------------------------

[~jharting] Does this look ok to you: https://github.com/stuartwdouglas/Resteasy/compare/WFLY-2859
                
> Treating all JAX-RS components as CDI Beans has some negative consequences
> --------------------------------------------------------------------------
>
>                 Key: WFLY-2859
>                 URL: https://issues.jboss.org/browse/WFLY-2859
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: CDI / Weld, REST
>    Affects Versions: 8.0.0.CR1
>            Reporter: Matt Drees
>            Assignee: Stuart Douglas
>
> It seems that wildfly is now treating all jax-rs Providers and Resources as CDI Beans.  This is probably fine most of the time, but there are some Provider classes that cause UnproxyableResolutionException (WELD-001437) errors, due to the fact that resteasy-cdi attempts to get bean reference whose type is identical to the bean class.
> See the forum link for a specific instance of this.

--
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

From issues at jboss.org  Thu Mar 20 01:58:10 2014
From: issues at jboss.org (no boundaries ! (JIRA))
Date: Thu, 20 Mar 2014 01:58:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (AS7-1509) JSP subsystem configurations
 lost during marshalling
In-Reply-To: <JIRA.12444138.1313047300000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12444138.1313047300000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12444138.1313047300000.28313.1395295090609@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/AS7-1509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12954466#comment-12954466 ] 

no boundaries ! commented on AS7-1509:
--------------------------------------

$JBOSS_HOME$\standalone\configuration\standalone.xml
                
> JSP subsystem configurations lost during marshalling 
> -----------------------------------------------------
>
>                 Key: AS7-1509
>                 URL: https://issues.jboss.org/browse/AS7-1509
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Web
>         Environment: AS7 upstream
>            Reporter: jaikiran pai
>            Assignee: jaikiran pai
>             Fix For: 7.0.1.Final
>
>
> If the web subsystem is configured with the jsp configuration:
> {code}
> <configuration>
>   <jsp-configuration development="true"/>
> </configuration>
> {code}
> and some management operation is carried out like deploying some application, the entire "configuration" element is lost from the xml file during marshalling.
> Please see the referenced forum thread 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

From issues at jboss.org  Thu Mar 20 02:58:11 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 20 Mar 2014 02:58:11 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1547) deploy directories not
	cleaned up
In-Reply-To: <JIRA.12479851.1353935247000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12479851.1353935247000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12479851.1353935247000.28356.1395298691173@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-1547?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated WFLY-1547:
------------------------------------------

    Bugzilla Update: Perform

    
> deploy directories not cleaned up
> ---------------------------------
>
>                 Key: WFLY-1547
>                 URL: https://issues.jboss.org/browse/WFLY-1547
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 8.0.0.Alpha1
>            Reporter: Shaun Appleton
>            Assignee: jaikiran pai
>             Fix For: 8.0.0.Beta1
>
>         Attachments: deployment_with_hack_no_hook.txt
>
>
> JBoss EAP 6.0.0 (and 6.0.1.ER3) doesn't clean up it's tmp/vfs directories.
> The following reproduces this -
> i) ensure run.conf has the -Xrs set
> ii) ensure deployments has a deployable .ear in it
> iii) ./run standalone.sh and allow the deployments to deploy
> iv) stop the EAP process ie kill <process_id>
> v) observe content tmp/vfs
> (The -Xrs parameter is used to "-Xrs" to prevent possible interference when JVM is running as a service and receives CTRL_LOGOFF_EVENT or SIGHUP)
> This will eventually cause problems with lack of disk space.
> Note if the -Xrs parameter content is removed but the tmp/vfs dirs stills exist. This could potentially cause inode problems.
> It would be better if there were any additional code so the temp dirs are cleaned up on start up. That would resolve both the -Xrs problem and the excessive dir creation.

--
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

From issues at jboss.org  Thu Mar 20 04:28:10 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 20 Mar 2014 04:28:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2658) (-Djboss.dist) jboss.dist
 property is not correctly propagated using -Djboss.dist
In-Reply-To: <JIRA.12528002.1387196044000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528002.1387196044000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528002.1387196044000.28494.1395304090892@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2658?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated WFLY-2658:
------------------------------------------

    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=970610, https://bugzilla.redhat.com/show_bug.cgi?id=1078701  (was: https://bugzilla.redhat.com/show_bug.cgi?id=970610)

    
> (-Djboss.dist) jboss.dist property is not correctly propagated using -Djboss.dist
> ---------------------------------------------------------------------------------
>
>                 Key: WFLY-2658
>                 URL: https://issues.jboss.org/browse/WFLY-2658
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Ondrej Lukas
>            Assignee: Ondrej Zizka
>
> This JIRA is clone of bz-970610 (https://bugzilla.redhat.com/show_bug.cgi?id=970610)
> When I run testsuite of EAP 6.1.0 using command [1], where JBOSS_HOME is a path EAP 6.1.0, the manualmode tests fail with error [2]:
> It uses path defined in jboss.dist property defined in testsuite/integration/pom.xml instead of the one provided -Djboss.dist which should redefine it.
> [1] ./integration-tests.sh -Dpublic-repos -DallTests -Dmaven.repo.local=${MAVEN_REPO_LOCAL} -Djboss.dist=${JBOSS_HOME} -Dmaven.test.failure.ignore=true  -Dsurefire.forked.process.timeout=3600
> [2]
> [ERROR] Failed to execute goal org.apache.maven.plugins:maven-antrun-plugin:1.7-redhat-1:run (build-manual-mode-servers) on project jboss-as-ts-integ-manualmode: An Ant BuildException has occured: The following error occurred while executing this line:
> [ERROR] /mnt/hudson_workspace/workspace/eap-60-as-testsuite-one-offs-rhatlapa/jboss-eap-6.1-src/testsuite/integration/src/test/scripts/manualmode-build.xml:52: /mnt/hudson_workspace/workspace/eap-60-as-testsuite-one-offs-rhatlapa/jboss-eap-6.1-src/build/target/jboss-as-7.2.0.Final-redhat-8/modules does not exist.
> [ERROR] around Ant part ...<ant antfile="/mnt/hudson_workspace/workspace/eap-60-as-testsuite-one-offs-rhatlapa/jboss-eap-6.1-src/testsuite/integration/manualmode/../src/test/scripts/manualmode-build.xml">... @ 4:180 in /mnt/hudson_workspace/workspace/eap-60-as-testsuite-one-offs-rhatlapa/jboss-eap-6.1-src/testsuite/integration/manualmode/target/antrun/build-main.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

From issues at jboss.org  Thu Mar 20 05:42:10 2014
From: issues at jboss.org (roy mizrachi (JIRA))
Date: Thu, 20 Mar 2014 05:42:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3050) '=' character removed from
	request cookie
In-Reply-To: <JIRA.12533682.1393766769000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12533682.1393766769000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12533682.1393766769000.28731.1395308530731@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-3050?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12954511#comment-12954511 ] 

roy mizrachi commented on WFLY-3050:
------------------------------------

Will this be fixed in the near future and is there a bypass for this for final version?
This issue is a major issue and prevent me to migrate to jboss.
By the way the issue does not exists in wildfly 8 beta 1

Thanks
                
> '=' character removed from request cookie 
> ------------------------------------------
>
>                 Key: WFLY-3050
>                 URL: https://issues.jboss.org/browse/WFLY-3050
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web (Undertow)
>    Affects Versions: 8.0.0.Final
>         Environment: windows 7
>            Reporter: roy mizrachi
>            Assignee: Stuart Douglas
>
> I'm saving encrypted user token in session cookie:
> Cookie: JCORESESSIONID=aes256$/tew4VVsfdJ32iUX1AOqBGRb717TJC9KkejjAPl6BIAG6kCP4beSraL51eQG2iu5bV9uT3OsubXUcjO+sG2lYNWbu5NliQd361oUz2Yl4LQ=
> The problem is that in the server i see that the '=' character is removed hence i cannot decrypt it.
>  

--
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

From issues at jboss.org  Thu Mar 20 05:52:10 2014
From: issues at jboss.org (Stefan Eder (JIRA))
Date: Thu, 20 Mar 2014 05:52:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (SECURITY-808) Password not passed into
 DatabaseServerLoginModule
In-Reply-To: <JIRA.12535541.1395309128963@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12535541.1395309128963@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12535541.1395309128963.28739.1395309130675@jira02.app.mwc.hst.phx2.redhat.com>

Stefan Eder created SECURITY-808:
------------------------------------

             Summary: Password not passed into DatabaseServerLoginModule
                 Key: SECURITY-808
                 URL: https://issues.jboss.org/browse/SECURITY-808
             Project: PicketBox 
          Issue Type: Bug
      Security Level: Public (Everyone can see)
         Environment: WildFly8 on Windows 7 64-bit
            Reporter: Stefan Eder
            Assignee: Stefan Guilhen
            Priority: Critical


Trying to migrate an application to WildFly (from AS6.1) the migration went pretty smooth except for using the security domain.
The application uses a the ClientLoginModule on the client side and the DatabaseserverLoginModule on the server side.
 
Though the DatabaseServerLoginModule is called the validation of the password fails. I debugged it and the reason seems to be that in {{org.jboss.security.auth.callback.JBossCallbackHandler.getPassword()}} a {{org.jboss.as.security.remoting.RemotingConnectionCredential at 22341334}} is not handled and hence instead of a password the String {{org.jboss.as.security.remoting.RemotingConnectionCredential at 22341334}} is passed through to the DatabaseLoginModule.

See also [DatabaseServerLoginModule broken?|https://community.jboss.org/message/863295] and the related posts

--
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

From issues at jboss.org  Thu Mar 20 06:22:11 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 20 Mar 2014 06:22:11 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2658) (-Djboss.dist) jboss.dist
 property is not correctly propagated using -Djboss.dist
In-Reply-To: <JIRA.12528002.1387196044000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528002.1387196044000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528002.1387196044000.28794.1395310931678@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2658?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12954527#comment-12954527 ] 

RH Bugzilla Integration commented on WFLY-2658:
-----------------------------------------------

Pavel Jelinek <pjelinek at redhat.com> changed the Status of [bug 1078701|https://bugzilla.redhat.com/show_bug.cgi?id=1078701] from NEW to POST
                
> (-Djboss.dist) jboss.dist property is not correctly propagated using -Djboss.dist
> ---------------------------------------------------------------------------------
>
>                 Key: WFLY-2658
>                 URL: https://issues.jboss.org/browse/WFLY-2658
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Ondrej Lukas
>            Assignee: Ondrej Zizka
>
> This JIRA is clone of bz-970610 (https://bugzilla.redhat.com/show_bug.cgi?id=970610)
> When I run testsuite of EAP 6.1.0 using command [1], where JBOSS_HOME is a path EAP 6.1.0, the manualmode tests fail with error [2]:
> It uses path defined in jboss.dist property defined in testsuite/integration/pom.xml instead of the one provided -Djboss.dist which should redefine it.
> [1] ./integration-tests.sh -Dpublic-repos -DallTests -Dmaven.repo.local=${MAVEN_REPO_LOCAL} -Djboss.dist=${JBOSS_HOME} -Dmaven.test.failure.ignore=true  -Dsurefire.forked.process.timeout=3600
> [2]
> [ERROR] Failed to execute goal org.apache.maven.plugins:maven-antrun-plugin:1.7-redhat-1:run (build-manual-mode-servers) on project jboss-as-ts-integ-manualmode: An Ant BuildException has occured: The following error occurred while executing this line:
> [ERROR] /mnt/hudson_workspace/workspace/eap-60-as-testsuite-one-offs-rhatlapa/jboss-eap-6.1-src/testsuite/integration/src/test/scripts/manualmode-build.xml:52: /mnt/hudson_workspace/workspace/eap-60-as-testsuite-one-offs-rhatlapa/jboss-eap-6.1-src/build/target/jboss-as-7.2.0.Final-redhat-8/modules does not exist.
> [ERROR] around Ant part ...<ant antfile="/mnt/hudson_workspace/workspace/eap-60-as-testsuite-one-offs-rhatlapa/jboss-eap-6.1-src/testsuite/integration/manualmode/../src/test/scripts/manualmode-build.xml">... @ 4:180 in /mnt/hudson_workspace/workspace/eap-60-as-testsuite-one-offs-rhatlapa/jboss-eap-6.1-src/testsuite/integration/manualmode/target/antrun/build-main.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

From issues at jboss.org  Thu Mar 20 06:28:10 2014
From: issues at jboss.org (roy mizrachi (JIRA))
Date: Thu, 20 Mar 2014 06:28:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3050) '=' character removed from
	request cookie
In-Reply-To: <JIRA.12533682.1393766769000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12533682.1393766769000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12533682.1393766769000.28808.1395311290598@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-3050?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12954511#comment-12954511 ] 

roy mizrachi edited comment on WFLY-3050 at 3/20/14 6:26 AM:
-------------------------------------------------------------

There should add "allow-equals-in-cookie-value" attribute to wildfly-undertow_1_0.xsd under http-listener.
The options already exists in io.undertow.UndertowOptions.

Will this be fixed in the near future and is there a bypass for this for final version?

This issue is a major issue and prevent me to migrate to jboss.
By the way the issue does not exists in wildfly 8 beta 1

Thanks
                
      was (Author: roim):
    Will this be fixed in the near future and is there a bypass for this for final version?
This issue is a major issue and prevent me to migrate to jboss.
By the way the issue does not exists in wildfly 8 beta 1

Thanks
                  
> '=' character removed from request cookie 
> ------------------------------------------
>
>                 Key: WFLY-3050
>                 URL: https://issues.jboss.org/browse/WFLY-3050
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web (Undertow)
>    Affects Versions: 8.0.0.Final
>         Environment: windows 7
>            Reporter: roy mizrachi
>            Assignee: Stuart Douglas
>
> I'm saving encrypted user token in session cookie:
> Cookie: JCORESESSIONID=aes256$/tew4VVsfdJ32iUX1AOqBGRb717TJC9KkejjAPl6BIAG6kCP4beSraL51eQG2iu5bV9uT3OsubXUcjO+sG2lYNWbu5NliQd361oUz2Yl4LQ=
> The problem is that in the server i see that the '=' character is removed hence i cannot decrypt it.
>  

--
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

From issues at jboss.org  Thu Mar 20 06:44:10 2014
From: issues at jboss.org (Alexey Loubyansky (JIRA))
Date: Thu, 20 Mar 2014 06:44:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3005) cannot override
 logging.configuration in jboss-cli.sh and jboss-cli.bat
In-Reply-To: <JIRA.12533130.1393255976000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12533130.1393255976000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12533130.1393255976000.28852.1395312250628@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-3005?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Alexey Loubyansky resolved WFLY-3005.
-------------------------------------

    Fix Version/s: 8.0.1.Final
       Resolution: Done


Merged.
                
> cannot override logging.configuration in jboss-cli.sh and jboss-cli.bat
> -----------------------------------------------------------------------
>
>                 Key: WFLY-3005
>                 URL: https://issues.jboss.org/browse/WFLY-3005
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: CLI
>    Affects Versions: 8.0.0.Final
>         Environment: windows and linux
>            Reporter: Gabriele Garuglieri
>            Assignee: Alexey Loubyansky
>             Fix For: 8.0.1.Final
>
>
> when using cli scripts jboss-cli.sh and jboss-cli.bat and you cannot write in $JBOSS_HOME because it is serving many server instances, you can override default jboss-cli.xml setting -Djboss.cli.config in $JAVA_OPTS but you cannot override logging.configuration because in both scripts is set with default after expanding $JAVA_OPTS
> last lines of bat script could be modified as follows:
> echo "%JAVA_OPTS%" | findstr /I "logging.configuration" > nul
> if errorlevel == 1 (
>     set "JAVA_OPTS=%JAVA_OPTS% -Dlogging.configuration=file:%JBOSS_HOME%\bin\jboss-cli-logging.properties"
> ) else (
>     echo logging.configuration already set in JAVA_OPTS
> )
> "%JAVA%" %JAVA_OPTS% ^
>     -jar "%JBOSS_RUNJAR%" ^
>     -mp "%JBOSS_MODULEPATH%" ^
>      org.jboss.as.cli ^
>      %*
> Last lines of sh script could be modified as follows:
> LOG_CONF=`echo $JAVA_OPTS | $GREP "logging.configuration"`
> if [ "x$LOG_CONF" = "x" ]; then
>     JAVA_OPTS="$JAVA_OPTS -Dlogging.configuration=file:$JBOSS_HOME/bin/jboss-cli-logging.properties"
> else
>     echo "logging.configuration already set in JAVA_OPTS"
> fi
> # Sample JPDA settings for remote socket debugging
> #JAVA_OPTS="$JAVA_OPTS -agentlib:jdwp=transport=dt_socket,address=8787,server=y,suspend=n"
> eval \"$JAVA\" $JAVA_OPTS -jar \"$JBOSS_HOME/jboss-modules.jar\" -mp \"${JBOSS_MODULEPATH}\" org.jboss.as.cli '"$@"'

--
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

From issues at jboss.org  Thu Mar 20 06:44:10 2014
From: issues at jboss.org (Alexey Loubyansky (JIRA))
Date: Thu, 20 Mar 2014 06:44:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3101) CLI: hide stacktraces for
 exceptions w/o messages when logging errors
In-Reply-To: <JIRA.12534667.1394545185000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534667.1394545185000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534667.1394545185000.28853.1395312250670@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-3101?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Alexey Loubyansky resolved WFLY-3101.
-------------------------------------

    Resolution: Done


Merged.
                
> CLI: hide stacktraces for exceptions w/o messages when logging errors
> ---------------------------------------------------------------------
>
>                 Key: WFLY-3101
>                 URL: https://issues.jboss.org/browse/WFLY-3101
>             Project: WildFly
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: CLI
>    Affects Versions: 8.0.0.Final
>            Reporter: Alexey Loubyansky
>            Assignee: Alexey Loubyansky
>             Fix For: 8.0.1.Final
>
>
> CommandContextImpl contains the following logic
>     public void handleSafe(String line) {
>         exitCode = 0;
>         try {
>             handle(line);
>         } catch(Throwable t) {
>             final StringBuilder buf = new StringBuilder();
>             buf.append(t.getLocalizedMessage());
>             Throwable t1 = t.getCause();
>             while(t1 != null) {
>                 if(t1.getLocalizedMessage() != null) {
>                     buf.append(": ").append(t1.getLocalizedMessage());
>                 } else {
>                     t1.printStackTrace();
>                 }
>                 t1 = t1.getCause();
>             }
>             error(buf.toString());
>         }
>     }
> When an exception does not contain any message, e.g. in some cases IllegalArgumentException, etc, the full stacktraces are logged that are useful for debugging but not nice from the user interface point of view. It was suggested to hide them.

--
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

From issues at jboss.org  Thu Mar 20 06:58:10 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 20 Mar 2014 06:58:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3108) Can't promote --backup slave
 HC to master and reload without moving domain.cached-remote.xml
In-Reply-To: <JIRA.12534873.1394711186000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534873.1394711186000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534873.1394711186000.28864.1395313090601@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-3108?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12954539#comment-12954539 ] 

RH Bugzilla Integration commented on WFLY-3108:
-----------------------------------------------

Rostislav Svoboda <rsvoboda at redhat.com> changed the Status of [bug 1076066|https://bugzilla.redhat.com/show_bug.cgi?id=1076066] from MODIFIED to ON_QA
                
> Can't promote --backup slave HC to master and reload without moving domain.cached-remote.xml
> --------------------------------------------------------------------------------------------
>
>                 Key: WFLY-3108
>                 URL: https://issues.jboss.org/browse/WFLY-3108
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>    Affects Versions: 8.0.0.Final
>            Reporter: Brian Stansberry
>            Assignee: Brian Stansberry
>             Fix For: 8.0.1.Final
>
>
> The prescribed mechanism for converting a slave HC to master is to:
> 1) Start the slave with --backup so a local copy of the domain config is maintained (in file domain.cached-remote.xml).
> 2) Stop the existing master.
> 3) Use the cli to connect to the slave and
> /host=<slavename>:write-local-domain-controller
> 4) Then, in the CLI
> reload --host=<slavename>
> Problem is this fails because the HC expects to have a domain config file "domain.xml".
> 2014-03-13 09:54:04,829 ERROR [org.jboss.as.host.controller] (Controller Boot Thread) JBAS010932: Caught exception during boot: org.jboss.as.controller.persistence.ConfigurationPersistenceException: JBAS014676: Failed to parse configuration
> 	at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:112) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> 	at org.jboss.as.host.controller.DomainModelControllerService.boot(DomainModelControllerService.java:514) [wildfly-host-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> 	at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:256) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> 	at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_45]
> Caused by: java.io.FileNotFoundException: /Users/bstansberry/tmp/WF801/slave/domain/configuration/domain.xml (No such file or directory)
> 	at java.io.FileInputStream.open(Native Method) [rt.jar:1.7.0_45]
> 	at java.io.FileInputStream.<init>(FileInputStream.java:146) [rt.jar:1.7.0_45]
> 	at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:100) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> 	... 3 more
> Or, MUCH WORSE, there happens to be a random domain.xml in the filesystem, which has content that is out of sync with the correct domain config. This domain.xml config will be used.

--
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

From issues at jboss.org  Thu Mar 20 07:30:10 2014
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 20 Mar 2014 07:30:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2903) Create Version 2.1 of the
 domain management schema
In-Reply-To: <JIRA.12531719.1392118739000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12531719.1392118739000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12531719.1392118739000.28933.1395315010711@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2903?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated WFLY-2903:
-----------------------------------

    Priority: Blocker  (was: Critical)

    
> Create Version 2.1 of the domain management schema
> --------------------------------------------------
>
>                 Key: WFLY-2903
>                 URL: https://issues.jboss.org/browse/WFLY-2903
>             Project: WildFly
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>            Priority: Blocker
>             Fix For: 8.0.1.Final
>
>
> Before additional configuration changes can be made a new version of the domain management schema is required - it is better to do this in it's own commit instead of a race for the first issue to add it.

--
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

From issues at jboss.org  Thu Mar 20 07:36:10 2014
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 20 Mar 2014 07:36:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2890) Add support for PKCS#11
 configuration within security realms.
In-Reply-To: <JIRA.12531585.1392035371000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12531585.1392035371000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12531585.1392035371000.28943.1395315370557@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2890?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated WFLY-2890:
-----------------------------------

    Fix Version/s: 8.0.1.Final
                       (was: 9.0.0.CR1)

    
> Add support for PKCS#11 configuration within security realms.
> -------------------------------------------------------------
>
>                 Key: WFLY-2890
>                 URL: https://issues.jboss.org/browse/WFLY-2890
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management, Security
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>            Priority: Critical
>              Labels: eap, management_security,
>             Fix For: 8.0.1.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

From issues at jboss.org  Thu Mar 20 07:38:11 2014
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 20 Mar 2014 07:38:11 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2229) Add support for PKCS12
 Keystores in security realms.
In-Reply-To: <JIRA.12502310.1381144389000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502310.1381144389000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502310.1381144389000.28956.1395315491182@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2229?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated WFLY-2229:
-----------------------------------

    Priority: Critical  (was: Major)

    
> Add support for PKCS12 Keystores in security realms.
> ----------------------------------------------------
>
>                 Key: WFLY-2229
>                 URL: https://issues.jboss.org/browse/WFLY-2229
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management, Security
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>            Priority: Critical
>              Labels: management_security,
>             Fix For: 9.0.0.CR1
>
>


--
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

From issues at jboss.org  Thu Mar 20 07:38:11 2014
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 20 Mar 2014 07:38:11 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2229) Add support for PKCS12
 Keystores in security realms.
In-Reply-To: <JIRA.12502310.1381144389000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502310.1381144389000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502310.1381144389000.28967.1395315491796@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2229?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated WFLY-2229:
-----------------------------------

    Fix Version/s: 8.0.1.Final
                       (was: 9.0.0.CR1)

    
> Add support for PKCS12 Keystores in security realms.
> ----------------------------------------------------
>
>                 Key: WFLY-2229
>                 URL: https://issues.jboss.org/browse/WFLY-2229
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management, Security
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>            Priority: Critical
>              Labels: management_security,
>             Fix For: 8.0.1.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

From issues at jboss.org  Thu Mar 20 07:44:10 2014
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 20 Mar 2014 07:44:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3143) Upgrade to JBoss Negotiation
	2.3.0.Beta1
In-Reply-To: <JIRA.12535552.1395315746719@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12535552.1395315746719@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12535552.1395315746719.28984.1395315850710@jira02.app.mwc.hst.phx2.redhat.com>

Darran Lofthouse created WFLY-3143:
--------------------------------------

             Summary: Upgrade to JBoss Negotiation 2.3.0.Beta1
                 Key: WFLY-3143
                 URL: https://issues.jboss.org/browse/WFLY-3143
             Project: WildFly
          Issue Type: Component  Upgrade
      Security Level: Public (Everyone can see)
          Components: Security
            Reporter: Darran Lofthouse
            Assignee: Darran Lofthouse
             Fix For: 9.0.0.CR1




--
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

From issues at jboss.org  Thu Mar 20 07:52:10 2014
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 20 Mar 2014 07:52:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (SECURITY-807) Add a LoginModule to wrap
 existing Kerberos LoginModule(s) and optionally add a GSSCredential
In-Reply-To: <JIRA.12535397.1395233801000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12535397.1395233801000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12535397.1395233801000.28990.1395316330550@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/SECURITY-807?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse resolved SECURITY-807.
---------------------------------------

    Fix Version/s: Negotiation_2_3_0.Beta1
                       (was: Negotiation_2_3_0_CR1)
       Resolution: Done

    
> Add a LoginModule to wrap existing Kerberos LoginModule(s) and optionally add a GSSCredential
> ---------------------------------------------------------------------------------------------
>
>                 Key: SECURITY-807
>                 URL: https://issues.jboss.org/browse/SECURITY-807
>             Project: PicketBox 
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Negotiation
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>            Priority: Critical
>             Fix For: Negotiation_2_3_0.Beta1
>
>


--
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

From issues at jboss.org  Thu Mar 20 07:54:10 2014
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 20 Mar 2014 07:54:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (SECURITY-809) Release JBoss Negotiation
	2.3.0.Beta1
In-Reply-To: <JIRA.12535553.1395316402018@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12535553.1395316402018@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12535553.1395316402018.28994.1395316450670@jira02.app.mwc.hst.phx2.redhat.com>

Darran Lofthouse created SECURITY-809:
-----------------------------------------

             Summary: Release JBoss Negotiation 2.3.0.Beta1
                 Key: SECURITY-809
                 URL: https://issues.jboss.org/browse/SECURITY-809
             Project: PicketBox 
          Issue Type: Release
      Security Level: Public (Everyone can see)
          Components: Negotiation
            Reporter: Darran Lofthouse
            Assignee: Darran Lofthouse
             Fix For: Negotiation_2_3_0.Beta1




--
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

From issues at jboss.org  Thu Mar 20 08:22:11 2014
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 20 Mar 2014 08:22:11 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (SECURITY-809) Release JBoss Negotiation
	2.3.0.Beta1
In-Reply-To: <JIRA.12535553.1395316402000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12535553.1395316402000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12535553.1395316402000.29075.1395318131043@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/SECURITY-809?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse resolved SECURITY-809.
---------------------------------------

    Resolution: Done

    
> Release JBoss Negotiation 2.3.0.Beta1
> -------------------------------------
>
>                 Key: SECURITY-809
>                 URL: https://issues.jboss.org/browse/SECURITY-809
>             Project: PicketBox 
>          Issue Type: Release
>      Security Level: Public(Everyone can see) 
>          Components: Negotiation
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: Negotiation_2_3_0.Beta1
>
>


--
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

From issues at jboss.org  Thu Mar 20 09:34:10 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 20 Mar 2014 09:34:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3106) Infinispan cache statistics
 cannot be enabled/disabled independently of the cache manager statistics
In-Reply-To: <JIRA.12534838.1394655920000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534838.1394655920000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534838.1394655920000.29266.1395322450792@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-3106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12954605#comment-12954605 ] 

RH Bugzilla Integration commented on WFLY-3106:
-----------------------------------------------

Richard Jan?k <rjanik at redhat.com> changed the Status of [bug 1025023|https://bugzilla.redhat.com/show_bug.cgi?id=1025023] from ON_QA to VERIFIED
                
> Infinispan cache statistics cannot be enabled/disabled independently of the cache manager statistics    
> --------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-3106
>                 URL: https://issues.jboss.org/browse/WFLY-3106
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Clustering
>    Affects Versions: 8.0.0.Final
>            Reporter: Richard Achmatowicz
>            Assignee: Richard Achmatowicz
>             Fix For: 8.0.1.Final
>
>
> The Infinispan subsystem allows enabling and disabling the collection of statistics for cache managers and caches via the "statistics-enabled" management API attribute.
> It is possible to set statistics-enabled attributes independently for cache managers and caches in the management API, but when checking the Infinispan MBeans, we see that statistics are either enabled for cache managers and their caches, or disabled for cache managers and caches.  

--
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


From issues at jboss.org  Thu Mar 20 09:34:11 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 20 Mar 2014 09:34:11 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2415) Add configuration option to
 enable/disable Infinispan statistics
In-Reply-To: <JIRA.12509131.1383157408000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12509131.1383157408000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12509131.1383157408000.29276.1395322451206@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2415?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12954607#comment-12954607 ] 

RH Bugzilla Integration commented on WFLY-2415:
-----------------------------------------------

Richard Jan?k <rjanik at redhat.com> changed the Status of [bug 1025023|https://bugzilla.redhat.com/show_bug.cgi?id=1025023] from ON_QA to VERIFIED
                
> Add configuration option to enable/disable Infinispan statistics
> ----------------------------------------------------------------
>
>                 Key: WFLY-2415
>                 URL: https://issues.jboss.org/browse/WFLY-2415
>             Project: WildFly
>          Issue Type: Enhancement
>      Security Level: Public(Everyone can see) 
>          Components: Clustering
>            Reporter: Scott Marlow
>            Assignee: Paul Ferraro
>             Fix For: 8.0.0.CR1
>
>
> When the Infinispan MBean is enabled, Infinispan statistics are enabled by default.  Could we allow Infinispan statistics to be enabled/disabled via a WF configuration setting?

--
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


From issues at jboss.org  Thu Mar 20 10:08:10 2014
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Thu, 20 Mar 2014 10:08:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-315) Avoid running out of threads
 when connecting to the DC from a slave to pull down missing data
In-Reply-To: <JIRA.12488204.1364406845000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12488204.1364406845000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12488204.1364406845000.29373.1395324490720@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-315?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFLY-315:
----------------------------------

    Priority: Blocker  (was: Major)

    
> Avoid running out of threads when connecting to the DC from a slave to pull down missing data
> ---------------------------------------------------------------------------------------------
>
>                 Key: WFLY-315
>                 URL: https://issues.jboss.org/browse/WFLY-315
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>            Reporter: Kabir Khan
>            Assignee: Emanuel Muckenhuber
>            Priority: Blocker
>             Fix For: 9.0.0.CR1
>
>
> For WFLY-259 when a slave connects to the DC to pull down missing data, it does this by either getting a lock for the DC, or by joining the permit of the existing DC lock if the request to update a slave's server-config was executed as part of a composite obtaining a lock on the DC.
> The way it works at present there is a thread per slave which is blocked until the transaction completes. The DC threads are a finite resource, so a large number of slaves trying to pull down dats will cause deadlock

--
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

From issues at jboss.org  Thu Mar 20 10:10:10 2014
From: issues at jboss.org (Tomas Remes (JIRA))
Date: Thu, 20 Mar 2014 10:10:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3144) Session replication doesn't
 work as expected
In-Reply-To: <JIRA.12535573.1395324594839@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12535573.1395324594839@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12535573.1395324594839.29382.1395324610690@jira02.app.mwc.hst.phx2.redhat.com>

Tomas Remes created WFLY-3144:
---------------------------------

             Summary: Session replication doesn't work as expected
                 Key: WFLY-3144
                 URL: https://issues.jboss.org/browse/WFLY-3144
             Project: WildFly
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: CDI / Weld, EJB
    Affects Versions: 8.0.0.Final
            Reporter: Tomas Remes
            Assignee: Stuart Douglas


I am experimenting with quite simple Stateful SessionScoped bean  ( see org.jboss.weld.tests.clustering.translator.TranslatorControllerBean from attached reproducer) and actually there's not any specific exception, but the behavior is at least weird. I haven't tried with plain EJB so far. Reproducible by following steps:

1. Run first node with "/bin/standalone.sh -c standalone-ha.xml"
2. Run second node with "./bin/standalone.sh -c standalone-ha.xml -Djboss.socket.binding.port-offset=100 -Djboss.node.name=second"
3. Build and deploy attached reproducer
4. Open 127.0.0.1:8080/translator in your browser and translate something.
5. Open 127.0.0.1:8180/translator and note that number of translated sentences is not replicated correctly. 

This works correctly in EAP. I am running with default standalone-ha configuration on oracle's 1.7.0_45 jdk.

--
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

From issues at jboss.org  Thu Mar 20 10:12:10 2014
From: issues at jboss.org (Tomas Remes (JIRA))
Date: Thu, 20 Mar 2014 10:12:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3144) Session replication doesn't
 work as expected
In-Reply-To: <JIRA.12535573.1395324594000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12535573.1395324594000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12535573.1395324594000.29386.1395324730646@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-3144?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tomas Remes updated WFLY-3144:
------------------------------

    Attachment: translator.zip

    
> Session replication doesn't work as expected
> --------------------------------------------
>
>                 Key: WFLY-3144
>                 URL: https://issues.jboss.org/browse/WFLY-3144
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: CDI / Weld, EJB
>    Affects Versions: 8.0.0.Final
>            Reporter: Tomas Remes
>            Assignee: Stuart Douglas
>         Attachments: translator.zip
>
>
> I am experimenting with quite simple Stateful SessionScoped bean  ( see org.jboss.weld.tests.clustering.translator.TranslatorControllerBean from attached reproducer) and actually there's not any specific exception, but the behavior is at least weird. I haven't tried with plain EJB so far. Reproducible by following steps:
> 1. Run first node with "/bin/standalone.sh -c standalone-ha.xml"
> 2. Run second node with "./bin/standalone.sh -c standalone-ha.xml -Djboss.socket.binding.port-offset=100 -Djboss.node.name=second"
> 3. Build and deploy attached reproducer
> 4. Open 127.0.0.1:8080/translator in your browser and translate something.
> 5. Open 127.0.0.1:8180/translator and note that number of translated sentences is not replicated correctly. 
> This works correctly in EAP. I am running with default standalone-ha configuration on oracle's 1.7.0_45 jdk.

--
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

From issues at jboss.org  Thu Mar 20 10:34:11 2014
From: issues at jboss.org (Alessio Soldano (JIRA))
Date: Thu, 20 Mar 2014 10:34:11 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-263) JASPI Support for Web Services
In-Reply-To: <JIRA.12457542.1327505819000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12457542.1327505819000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12457542.1327505819000.29438.1395326051309@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-263?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Alessio Soldano resolved WFLY-263.
----------------------------------

    Resolution: Done


Included in JBossWS 4.3.0.Final upgrade. Some doc at https://docs.jboss.org/author/display/JBWS/Authentication (JASPI Authentication section)
                
> JASPI Support for Web Services
> ------------------------------
>
>                 Key: WFLY-263
>                 URL: https://issues.jboss.org/browse/WFLY-263
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Security, Web Services
>            Reporter: Anil Saldhana
>            Assignee: Jim Ma
>             Fix For: 9.0.0.CR1
>
>
> Take care of the JASPI requirements for SOAP layer.

--
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

From issues at jboss.org  Thu Mar 20 10:42:11 2014
From: issues at jboss.org (Martin Kouba (JIRA))
Date: Thu, 20 Mar 2014 10:42:11 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3144) Session replication doesn't
 work as expected
In-Reply-To: <JIRA.12535573.1395324594000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12535573.1395324594000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12535573.1395324594000.29456.1395326531116@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-3144?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12954640#comment-12954640 ] 

Martin Kouba commented on WFLY-3144:
------------------------------------

For the record: I was able to reproduce the problem with cURL and forged JSESSIONID.
                
> Session replication doesn't work as expected
> --------------------------------------------
>
>                 Key: WFLY-3144
>                 URL: https://issues.jboss.org/browse/WFLY-3144
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: CDI / Weld, EJB
>    Affects Versions: 8.0.0.Final
>            Reporter: Tomas Remes
>            Assignee: Stuart Douglas
>         Attachments: translator.zip
>
>
> I am experimenting with quite simple Stateful SessionScoped bean  ( see org.jboss.weld.tests.clustering.translator.TranslatorControllerBean from attached reproducer) and actually there's not any specific exception, but the behavior is at least weird. I haven't tried with plain EJB so far. Reproducible by following steps:
> 1. Run first node with "/bin/standalone.sh -c standalone-ha.xml"
> 2. Run second node with "./bin/standalone.sh -c standalone-ha.xml -Djboss.socket.binding.port-offset=100 -Djboss.node.name=second"
> 3. Build and deploy attached reproducer
> 4. Open 127.0.0.1:8080/translator in your browser and translate something.
> 5. Open 127.0.0.1:8180/translator and note that number of translated sentences is not replicated correctly. 
> This works correctly in EAP. I am running with default standalone-ha configuration on oracle's 1.7.0_45 jdk.

--
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

From issues at jboss.org  Thu Mar 20 10:46:13 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 20 Mar 2014 10:46:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-450) Cannot use decimal
 formatters for integers in an excel decision table
In-Reply-To: <JIRA.12534705.1394557254000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534705.1394557254000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534705.1394557254000.29474.1395326773274@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/DROOLS-450?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12954643#comment-12954643 ] 

RH Bugzilla Integration commented on DROOLS-450:
------------------------------------------------

Edson Tirelli <etirelli at redhat.com> changed the Status of [bug 1077228|https://bugzilla.redhat.com/show_bug.cgi?id=1077228] from NEW to MODIFIED
                
> Cannot use decimal formatters for integers in an excel decision table
> ---------------------------------------------------------------------
>
>                 Key: DROOLS-450
>                 URL: https://issues.jboss.org/browse/DROOLS-450
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 6.0.1.Final
>            Reporter: Maxime Falaize
>            Assignee: Michael Anstis
>            Priority: Minor
>             Fix For: 6.1.0.Beta2
>
>         Attachments: issue_example.png
>
>
> When I use decimal formatter in an excel action column for numbers that are in fact integers, I am getting this exception :
> {noformat}
> Exception in thread "main" java.lang.RuntimeException: Error while creating KieBase[Message [id=1, level=ERROR, path=com/sample/my_decision_table.xls, line=5, column=0
>    text=Rule Compilation error The method setParameter(double) in the type MyObject is not applicable for the arguments (int, int)]]
> 	at org.drools.compiler.kie.builder.impl.KieContainerImpl.getKieBase(KieContainerImpl.java:260)
> 	at org.drools.compiler.kie.builder.impl.KieContainerImpl.newKieSession(KieContainerImpl.java:400)
> 	at org.drools.compiler.kie.builder.impl.KieContainerImpl.newKieSession(KieContainerImpl.java:375)
> {noformat}
> Actually, the system uses the format number "1,00000" (with comma in french) instead of "1.00000" like it should use.
> This is causing by the line 174 in org.drools.decisiontable.parser.xls.ExcelParser :
> {code:java}
> if ( num - Math.round( num ) != 0 )
> {code}
> I don't understand why we use the formatted value when this test is not passed.
> I think the end users should have the possibility to keep the same formatter for the same column, with integers or not.

--
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

From issues at jboss.org  Thu Mar 20 11:42:10 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 20 Mar 2014 11:42:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (SECURITY-795) AdvancedLdap login module
 does not handle a user that has a slash character in the uid
In-Reply-To: <JIRA.12532238.1392392424000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12532238.1392392424000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12532238.1392392424000.29568.1395330130980@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/SECURITY-795?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12954664#comment-12954664 ] 

RH Bugzilla Integration commented on SECURITY-795:
--------------------------------------------------

Kabir Khan <kkhan at redhat.com> changed the Status of [bug 1065476|https://bugzilla.redhat.com/show_bug.cgi?id=1065476] from ASSIGNED to MODIFIED
                
> AdvancedLdap login module does not handle a user that has a slash character in the uid
> --------------------------------------------------------------------------------------
>
>                 Key: SECURITY-795
>                 URL: https://issues.jboss.org/browse/SECURITY-795
>             Project: PicketBox 
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Negotiation
>    Affects Versions: Negotiation_2_2_5
>            Reporter: Derek Horton
>            Assignee: Derek Horton
>             Fix For: Negotiation_2_2_7
>
>         Attachments: SECURITY-795.patch
>
>
> AdvancedLdap login module does not handle a user that has a slash character in the uid.
> For example, JBoss will fail to authenticate the following user correctly:
> dn: uid=weird/user,ou=Users,dc=my-domain,dc=com
> uid: weird/user
> cn: Weird User

--
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

From issues at jboss.org  Thu Mar 20 11:42:11 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 20 Mar 2014 11:42:11 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (SECURITY-795) AdvancedLdap login module
 does not handle a user that has a slash character in the uid
In-Reply-To: <JIRA.12532238.1392392424000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12532238.1392392424000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12532238.1392392424000.29571.1395330131154@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/SECURITY-795?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12954665#comment-12954665 ] 

RH Bugzilla Integration commented on SECURITY-795:
--------------------------------------------------

Kabir Khan <kkhan at redhat.com> changed the Status of [bug 1065476|https://bugzilla.redhat.com/show_bug.cgi?id=1065476] from MODIFIED to ON_QA
                
> AdvancedLdap login module does not handle a user that has a slash character in the uid
> --------------------------------------------------------------------------------------
>
>                 Key: SECURITY-795
>                 URL: https://issues.jboss.org/browse/SECURITY-795
>             Project: PicketBox 
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Negotiation
>    Affects Versions: Negotiation_2_2_5
>            Reporter: Derek Horton
>            Assignee: Derek Horton
>             Fix For: Negotiation_2_2_7
>
>         Attachments: SECURITY-795.patch
>
>
> AdvancedLdap login module does not handle a user that has a slash character in the uid.
> For example, JBoss will fail to authenticate the following user correctly:
> dn: uid=weird/user,ou=Users,dc=my-domain,dc=com
> uid: weird/user
> cn: Weird User

--
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

From issues at jboss.org  Thu Mar 20 11:56:11 2014
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 20 Mar 2014 11:56:11 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2890) Add support for PKCS#11
 configuration within security realms.
In-Reply-To: <JIRA.12531585.1392035371000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12531585.1392035371000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12531585.1392035371000.29600.1395330971951@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2890?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated WFLY-2890:
-----------------------------------

    Fix Version/s: 9.0.0.CR1
                       (was: 8.0.1.Final)

    
> Add support for PKCS#11 configuration within security realms.
> -------------------------------------------------------------
>
>                 Key: WFLY-2890
>                 URL: https://issues.jboss.org/browse/WFLY-2890
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management, Security
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>            Priority: Critical
>              Labels: eap, management_security,
>             Fix For: 9.0.0.CR1
>
>


--
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

From issues at jboss.org  Thu Mar 20 11:56:12 2014
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 20 Mar 2014 11:56:12 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2951) Enable alternative provider
 to be specified for loading key and trust stores.
In-Reply-To: <JIRA.12532475.1392721634000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12532475.1392721634000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12532475.1392721634000.29604.1395330972203@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2951?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse reopened WFLY-2951:
------------------------------------


    
> Enable alternative provider to be specified for loading key and trust stores.
> -----------------------------------------------------------------------------
>
>                 Key: WFLY-2951
>                 URL: https://issues.jboss.org/browse/WFLY-2951
>             Project: WildFly
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management, Security
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 9.0.0.CR1
>
>
> This is to allow pre-defined PKCS#11 providers to be referenced.

--
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

From issues at jboss.org  Thu Mar 20 11:56:12 2014
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 20 Mar 2014 11:56:12 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2951) Enable alternative provider
 to be specified for loading key and trust stores.
In-Reply-To: <JIRA.12532475.1392721634000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12532475.1392721634000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12532475.1392721634000.29607.1395330972357@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2951?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated WFLY-2951:
-----------------------------------

    Fix Version/s: 8.0.1.Final
                       (was: 9.0.0.CR1)

    
> Enable alternative provider to be specified for loading key and trust stores.
> -----------------------------------------------------------------------------
>
>                 Key: WFLY-2951
>                 URL: https://issues.jboss.org/browse/WFLY-2951
>             Project: WildFly
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management, Security
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 8.0.1.Final
>
>
> This is to allow pre-defined PKCS#11 providers to be referenced.

--
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

From issues at jboss.org  Thu Mar 20 12:24:11 2014
From: issues at jboss.org (Bela Ban (JIRA))
Date: Thu, 20 Mar 2014 12:24:11 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1750) RELAY2 : Address formats are
	not relayed.
In-Reply-To: <JIRA.12526440.1385646708000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12526440.1385646708000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12526440.1385646708000.29668.1395332651135@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JGRP-1750?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12954683#comment-12954683 ] 

Bela Ban commented on JGRP-1750:
--------------------------------

[~ammous] Not sure I understand the need for an AddressGenerator to be set in a bridge. 

Meanwhile, I created an {{ExtendedAddress}} and {{SiteUUID}} and {{SiteMaster}} are both subclasses of it, so you can add any data to them.
I modified UnicastTestRpc slightly and used a config containing RELAY2, and data added to a SiteUUID is actually seen at the receiving end in a different site.

Do you have a small test case that shows your problem ?
(This is on branch JGRP-1750)
                
> RELAY2 : Address formats are not relayed.
> -----------------------------------------
>
>                 Key: JGRP-1750
>                 URL: https://issues.jboss.org/browse/JGRP-1750
>             Project: JGroups
>          Issue Type: Feature Request
>    Affects Versions: 3.4.1
>            Reporter: Karim AMMOUS
>            Assignee: Bela Ban
>             Fix For: 3.5
>
>
> When defining a relay channel, we haven't the ability to set an AddressGenrator. Indeed, the Relayer uses its own AddressGenerator providing addresses of type SiteUUID. 
> This is particularly embarrassing in the following case: when we define a customized address format (like CanBeSiteMasterTopology or TopologyUUID) for members of two Sites A and B, address format is lost by crossing relay. Address type of messages sent by A to B are seen as SiteUUID at B side.
> Suggestions:
> - Making address format "relayable" ?
> - Using the same (or an extended format) AddressGenerator of site Channel

--
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

From issues at jboss.org  Thu Mar 20 12:34:11 2014
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 20 Mar 2014 12:34:11 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2957) Refactor the SSL services
 within the security realms so that key and trust managers are injected
 instead of stores.
In-Reply-To: <JIRA.12532525.1392731377000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12532525.1392731377000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12532525.1392731377000.29712.1395333251555@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2957?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse reopened WFLY-2957:
------------------------------------


    
> Refactor the SSL services within the security realms so that key and trust managers are injected instead of stores.
> -------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2957
>                 URL: https://issues.jboss.org/browse/WFLY-2957
>             Project: WildFly
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management, Security
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 9.0.0.CR1
>
>
> To cope with things like being able to reload trust stores after files have been modified some implementation details regarding file handling have leaked slightly into the SSLIdentityService which represents the servers identity - instead the key and trust manager instances should be injected.

--
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

From issues at jboss.org  Thu Mar 20 12:34:11 2014
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 20 Mar 2014 12:34:11 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2957) Refactor the SSL services
 within the security realms so that key and trust managers are injected
 instead of stores.
In-Reply-To: <JIRA.12532525.1392731377000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12532525.1392731377000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12532525.1392731377000.29715.1395333251675@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2957?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated WFLY-2957:
-----------------------------------

    Priority: Critical  (was: Major)

    
> Refactor the SSL services within the security realms so that key and trust managers are injected instead of stores.
> -------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2957
>                 URL: https://issues.jboss.org/browse/WFLY-2957
>             Project: WildFly
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management, Security
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>            Priority: Critical
>             Fix For: 9.0.0.CR1
>
>
> To cope with things like being able to reload trust stores after files have been modified some implementation details regarding file handling have leaked slightly into the SSLIdentityService which represents the servers identity - instead the key and trust manager instances should be injected.

--
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

From issues at jboss.org  Thu Mar 20 12:34:11 2014
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 20 Mar 2014 12:34:11 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2957) Refactor the SSL services
 within the security realms so that key and trust managers are injected
 instead of stores.
In-Reply-To: <JIRA.12532525.1392731377000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12532525.1392731377000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12532525.1392731377000.29719.1395333251853@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2957?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated WFLY-2957:
-----------------------------------

    Fix Version/s: 8.0.1.Final
                       (was: 9.0.0.CR1)

    
> Refactor the SSL services within the security realms so that key and trust managers are injected instead of stores.
> -------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2957
>                 URL: https://issues.jboss.org/browse/WFLY-2957
>             Project: WildFly
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management, Security
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>            Priority: Critical
>             Fix For: 8.0.1.Final
>
>
> To cope with things like being able to reload trust stores after files have been modified some implementation details regarding file handling have leaked slightly into the SSLIdentityService which represents the servers identity - instead the key and trust manager instances should be injected.

--
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

From issues at jboss.org  Thu Mar 20 12:48:11 2014
From: issues at jboss.org (Scott Marlow (JIRA))
Date: Thu, 20 Mar 2014 12:48:11 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3105) Container-managed EXTENDED
 persistence context is always joined with transaction even if
 UNSYNCHRONIZED
In-Reply-To: <JIRA.12534789.1394637157000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534789.1394637157000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534789.1394637157000.29731.1395334091146@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-3105?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12954688#comment-12954688 ] 

Scott Marlow commented on WFLY-3105:
------------------------------------

The https://github.com/wildfly/wildfly/pull/6065 change is to not join the extended persistence context to the transaction (via EntityManager.joinTransaction()) for UNSYNCHRONIZED.

The added unit test failed before the change and passed after.  
                
> Container-managed EXTENDED persistence context is always joined with transaction even if UNSYNCHRONIZED
> -------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-3105
>                 URL: https://issues.jboss.org/browse/WFLY-3105
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JPA / Hibernate
>    Affects Versions: 8.0.0.Final
>            Reporter: Christian Bauer
>            Assignee: Scott Marlow
>             Fix For: 8.0.1.Final
>
>
> https://github.com/weld/wildfly/blob/master/testsuite/integration/basic/src/test/java/org/jboss/as/test/integration/jpa/transaction/UnsynchronizedSFSB.jav
> Change this test to {code}@PersistenceContext(type = EXTENDED, synchronization = UNSYNCHRONIZED){code} and it will break. 
> Looks like an extended PC is always joined to the transaction and flushed on commit, the unsynchronized mode is ignored. From what I can see this is not specified and indeed would make the whole new UNSYNCHRONIZED feature kind of pointless. It's primary use case is propagation of unflushed/unsynchronized extended PC from a SFSB to other beans while keeping transactions intact.

--
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

From issues at jboss.org  Thu Mar 20 12:58:11 2014
From: issues at jboss.org (Jasbir Sahota (JIRA))
Date: Thu, 20 Mar 2014 12:58:11 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3145) Problem with HTTPS Failed to
 start the http-interface service
In-Reply-To: <JIRA.12535597.1395334662077@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12535597.1395334662077@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12535597.1395334662077.29798.1395334691494@jira02.app.mwc.hst.phx2.redhat.com>

Jasbir Sahota created WFLY-3145:
-----------------------------------

             Summary: Problem with HTTPS Failed to start the http-interface service
                 Key: WFLY-3145
                 URL: https://issues.jboss.org/browse/WFLY-3145
             Project: WildFly
          Issue Type: Support Request
      Security Level: Public (Everyone can see)
    Affects Versions: 8.0.0.Final
            Reporter: Jasbir Sahota
            Priority: Critical




--
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

From issues at jboss.org  Thu Mar 20 13:00:10 2014
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 20 Mar 2014 13:00:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3145) Problem with HTTPS Failed to
 start the http-interface service
In-Reply-To: <JIRA.12535597.1395334662000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12535597.1395334662000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12535597.1395334662000.29804.1395334810818@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-3145?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse reassigned WFLY-3145:
--------------------------------------

    Assignee: Darran Lofthouse

    
> Problem with HTTPS Failed to start the http-interface service
> -------------------------------------------------------------
>
>                 Key: WFLY-3145
>                 URL: https://issues.jboss.org/browse/WFLY-3145
>             Project: WildFly
>          Issue Type: Support Request
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 8.0.0.Final
>            Reporter: Jasbir Sahota
>            Assignee: Darran Lofthouse
>            Priority: Critical
>


--
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

From issues at jboss.org  Thu Mar 20 13:00:11 2014
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 20 Mar 2014 13:00:11 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3145) Problem with HTTPS Failed to
 start the http-interface service
In-Reply-To: <JIRA.12535597.1395334662000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12535597.1395334662000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12535597.1395334662000.29809.1395334811053@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-3145?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated WFLY-3145:
-----------------------------------

    Priority: Major  (was: Critical)

    
> Problem with HTTPS Failed to start the http-interface service
> -------------------------------------------------------------
>
>                 Key: WFLY-3145
>                 URL: https://issues.jboss.org/browse/WFLY-3145
>             Project: WildFly
>          Issue Type: Support Request
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 8.0.0.Final
>            Reporter: Jasbir Sahota
>            Assignee: Darran Lofthouse
>


--
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

From issues at jboss.org  Thu Mar 20 13:04:11 2014
From: issues at jboss.org (Jasbir Sahota (JIRA))
Date: Thu, 20 Mar 2014 13:04:11 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3145) Problem with HTTPS Failed to
 start the http-interface service
In-Reply-To: <JIRA.12535597.1395334662000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12535597.1395334662000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12535597.1395334662000.29820.1395335051045@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-3145?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12954697#comment-12954697 ] 

Jasbir Sahota commented on WFLY-3145:
-------------------------------------

Hi, apologies if I am doing something wrong but I am attempting to simply start Wirefly version 8 in standalone mode and I am getting the following error which reports that the HTTPS Service was not started, I can see the "Caused by: java.net.BindException: Address already in use:" but there seems to be no conflict on port 8080 that I can see: 

16:53:48,489 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-1) MSC000001: Failed to start service jboss.serverManagement.controller.management.http: org.jboss.msc.service.StartException in service jboss.serverManagement.controller.management.http: JBAS015811: Failed to start the http-interface service
        at org.jboss.as.server.mgmt.UndertowHttpManagementService.start(Undertow
HttpManagementService.java:258) [wildfly-server-8.0.0.Final.jar:8.0.0.Final]
        at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) [jboss-msc-1.2.0.Final.jar:1.2.0.Final]
        at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) [jboss-msc-1.2.0.Final.jar:1.2.0.Final]
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_51]
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_51]
        at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_51]
Caused by: java.lang.RuntimeException: java.net.BindException: Address already in use: bind
        at org.jboss.as.domain.http.server.ManagementHttpServer.start(ManagementHttpServer.java:156)
        at org.jboss.as.server.mgmt.UndertowHttpManagementService.start(Undertow
HttpManagementService.java:224) [wildfly-server-8.0.0.Final.jar:8.0.0.Final]
        ... 5 more
Caused by: java.net.BindException: Address already in use: bind
        at sun.nio.ch.Net.bind0(Native Method) [rt.jar:1.7.0_51]
        at sun.nio.ch.Net.bind(Net.java:444) [rt.jar:1.7.0_51]
        at sun.nio.ch.Net.bind(Net.java:436) [rt.jar:1.7.0_51]
        at sun.nio.ch.ServerSocketChannelImpl.bind(ServerSocketChannelImpl.java:214) [rt.jar:1.7.0_51]
        at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:74) [rt.jar:1.7.0_51]
        at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:67) [rt.jar:1.7.0_51]
        at org.xnio.nio.NioXnioWorker.createTcpConnectionServer(NioXnioWorker.java:175)
        at org.xnio.XnioWorker.createStreamConnectionServer(XnioWorker.java:242)

        at org.jboss.as.domain.http.server.ManagementHttpServer.start(Management
HttpServer.java:135)
        ... 6 more
                
> Problem with HTTPS Failed to start the http-interface service
> -------------------------------------------------------------
>
>                 Key: WFLY-3145
>                 URL: https://issues.jboss.org/browse/WFLY-3145
>             Project: WildFly
>          Issue Type: Support Request
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 8.0.0.Final
>            Reporter: Jasbir Sahota
>            Assignee: Darran Lofthouse
>


--
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

From issues at jboss.org  Thu Mar 20 13:06:11 2014
From: issues at jboss.org (Jasbir Sahota (JIRA))
Date: Thu, 20 Mar 2014 13:06:11 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3145) Problem with HTTPS Failed to
 start the http-interface service
In-Reply-To: <JIRA.12535597.1395334662000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12535597.1395334662000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12535597.1395334662000.29828.1395335171099@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-3145?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12954697#comment-12954697 ] 

Jasbir Sahota edited comment on WFLY-3145 at 3/20/14 1:05 PM:
--------------------------------------------------------------

Hi, apologies if I am doing something wrong but I am attempting to simply start Wildfly version 8 in standalone mode and I am getting the following error which reports that the HTTPS Service was not started, I can see the "Caused by: java.net.BindException: Address already in use:" but there seems to be no conflict on port 8080 that I can see: 

16:53:48,489 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-1) MSC000001: Failed to start service jboss.serverManagement.controller.management.http: org.jboss.msc.service.StartException in service jboss.serverManagement.controller.management.http: JBAS015811: Failed to start the http-interface service
        at org.jboss.as.server.mgmt.UndertowHttpManagementService.start(Undertow
HttpManagementService.java:258) [wildfly-server-8.0.0.Final.jar:8.0.0.Final]
        at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) [jboss-msc-1.2.0.Final.jar:1.2.0.Final]
        at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) [jboss-msc-1.2.0.Final.jar:1.2.0.Final]
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_51]
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_51]
        at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_51]
Caused by: java.lang.RuntimeException: java.net.BindException: Address already in use: bind
        at org.jboss.as.domain.http.server.ManagementHttpServer.start(ManagementHttpServer.java:156)
        at org.jboss.as.server.mgmt.UndertowHttpManagementService.start(Undertow
HttpManagementService.java:224) [wildfly-server-8.0.0.Final.jar:8.0.0.Final]
        ... 5 more
Caused by: java.net.BindException: Address already in use: bind
        at sun.nio.ch.Net.bind0(Native Method) [rt.jar:1.7.0_51]
        at sun.nio.ch.Net.bind(Net.java:444) [rt.jar:1.7.0_51]
        at sun.nio.ch.Net.bind(Net.java:436) [rt.jar:1.7.0_51]
        at sun.nio.ch.ServerSocketChannelImpl.bind(ServerSocketChannelImpl.java:214) [rt.jar:1.7.0_51]
        at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:74) [rt.jar:1.7.0_51]
        at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:67) [rt.jar:1.7.0_51]
        at org.xnio.nio.NioXnioWorker.createTcpConnectionServer(NioXnioWorker.java:175)
        at org.xnio.XnioWorker.createStreamConnectionServer(XnioWorker.java:242)

        at org.jboss.as.domain.http.server.ManagementHttpServer.start(Management
HttpServer.java:135)
        ... 6 more
                
      was (Author: jsahota):
    Hi, apologies if I am doing something wrong but I am attempting to simply start Wirefly version 8 in standalone mode and I am getting the following error which reports that the HTTPS Service was not started, I can see the "Caused by: java.net.BindException: Address already in use:" but there seems to be no conflict on port 8080 that I can see: 

16:53:48,489 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-1) MSC000001: Failed to start service jboss.serverManagement.controller.management.http: org.jboss.msc.service.StartException in service jboss.serverManagement.controller.management.http: JBAS015811: Failed to start the http-interface service
        at org.jboss.as.server.mgmt.UndertowHttpManagementService.start(Undertow
HttpManagementService.java:258) [wildfly-server-8.0.0.Final.jar:8.0.0.Final]
        at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) [jboss-msc-1.2.0.Final.jar:1.2.0.Final]
        at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) [jboss-msc-1.2.0.Final.jar:1.2.0.Final]
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_51]
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_51]
        at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_51]
Caused by: java.lang.RuntimeException: java.net.BindException: Address already in use: bind
        at org.jboss.as.domain.http.server.ManagementHttpServer.start(ManagementHttpServer.java:156)
        at org.jboss.as.server.mgmt.UndertowHttpManagementService.start(Undertow
HttpManagementService.java:224) [wildfly-server-8.0.0.Final.jar:8.0.0.Final]
        ... 5 more
Caused by: java.net.BindException: Address already in use: bind
        at sun.nio.ch.Net.bind0(Native Method) [rt.jar:1.7.0_51]
        at sun.nio.ch.Net.bind(Net.java:444) [rt.jar:1.7.0_51]
        at sun.nio.ch.Net.bind(Net.java:436) [rt.jar:1.7.0_51]
        at sun.nio.ch.ServerSocketChannelImpl.bind(ServerSocketChannelImpl.java:214) [rt.jar:1.7.0_51]
        at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:74) [rt.jar:1.7.0_51]
        at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:67) [rt.jar:1.7.0_51]
        at org.xnio.nio.NioXnioWorker.createTcpConnectionServer(NioXnioWorker.java:175)
        at org.xnio.XnioWorker.createStreamConnectionServer(XnioWorker.java:242)

        at org.jboss.as.domain.http.server.ManagementHttpServer.start(Management
HttpServer.java:135)
        ... 6 more
                  
> Problem with HTTPS Failed to start the http-interface service
> -------------------------------------------------------------
>
>                 Key: WFLY-3145
>                 URL: https://issues.jboss.org/browse/WFLY-3145
>             Project: WildFly
>          Issue Type: Support Request
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 8.0.0.Final
>            Reporter: Jasbir Sahota
>            Assignee: Darran Lofthouse
>


--
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

From issues at jboss.org  Thu Mar 20 13:08:11 2014
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 20 Mar 2014 13:08:11 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3145) Problem with HTTPS Failed to
 start the http-interface service
In-Reply-To: <JIRA.12535597.1395334662000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12535597.1395334662000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12535597.1395334662000.29838.1395335291776@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-3145?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12954700#comment-12954700 ] 

Darran Lofthouse commented on WFLY-3145:
----------------------------------------

>From the details so far this appears to be something you should be discussing in the forums not in Jira, Jira is for the recording of bugs and feature requests - the forums are for discussing problems you may be experiencing.

Note: From the stack trace you show this is the management http server which is having a problem which would most likely mean it is port 9990 that is having a conflict not 8080
                
> Problem with HTTPS Failed to start the http-interface service
> -------------------------------------------------------------
>
>                 Key: WFLY-3145
>                 URL: https://issues.jboss.org/browse/WFLY-3145
>             Project: WildFly
>          Issue Type: Support Request
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 8.0.0.Final
>            Reporter: Jasbir Sahota
>            Assignee: Darran Lofthouse
>


--
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

From issues at jboss.org  Thu Mar 20 13:12:11 2014
From: issues at jboss.org (Jasbir Sahota (JIRA))
Date: Thu, 20 Mar 2014 13:12:11 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3145) Problem with HTTPS Failed to
 start the http-interface service
In-Reply-To: <JIRA.12535597.1395334662000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12535597.1395334662000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12535597.1395334662000.29841.1395335531023@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-3145?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12954701#comment-12954701 ] 

Jasbir Sahota commented on WFLY-3145:
-------------------------------------

Darran, many thanks for your reply and apologies for raising this in the wrong place.

Will look into the Port 9990 conflict and close this here.
                
> Problem with HTTPS Failed to start the http-interface service
> -------------------------------------------------------------
>
>                 Key: WFLY-3145
>                 URL: https://issues.jboss.org/browse/WFLY-3145
>             Project: WildFly
>          Issue Type: Support Request
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 8.0.0.Final
>            Reporter: Jasbir Sahota
>            Assignee: Darran Lofthouse
>


--
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

From issues at jboss.org  Thu Mar 20 14:00:11 2014
From: issues at jboss.org (Bela Ban (JIRA))
Date: Thu, 20 Mar 2014 14:00:11 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1750) RELAY2 : Address formats are
	not relayed.
In-Reply-To: <JIRA.12526440.1385646708000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12526440.1385646708000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12526440.1385646708000.29948.1395338411281@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JGRP-1750?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12954713#comment-12954713 ] 

Bela Ban commented on JGRP-1750:
--------------------------------

{{JChannel.setAddressGenerator()}} is very simple now: it doesn't have to take into account already installed address generators, as all address generators are now stored in a list.
When the address is generated, if no or only 1 generators are installed, we use it to generate the address. If we have multiple address generators, we let all of them create an address. If one of them doesn't create an {{ExtendedUUID}}, we discard it.
Then the first {{ExtendedUUID}} is taken and the data and flags of all other addresses is added to the first address, which will be returned.
                
> RELAY2 : Address formats are not relayed.
> -----------------------------------------
>
>                 Key: JGRP-1750
>                 URL: https://issues.jboss.org/browse/JGRP-1750
>             Project: JGroups
>          Issue Type: Feature Request
>    Affects Versions: 3.4.1
>            Reporter: Karim AMMOUS
>            Assignee: Bela Ban
>             Fix For: 3.5
>
>
> When defining a relay channel, we haven't the ability to set an AddressGenrator. Indeed, the Relayer uses its own AddressGenerator providing addresses of type SiteUUID. 
> This is particularly embarrassing in the following case: when we define a customized address format (like CanBeSiteMasterTopology or TopologyUUID) for members of two Sites A and B, address format is lost by crossing relay. Address type of messages sent by A to B are seen as SiteUUID at B side.
> Suggestions:
> - Making address format "relayable" ?
> - Using the same (or an extended format) AddressGenerator of site Channel

--
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

From issues at jboss.org  Thu Mar 20 16:22:11 2014
From: issues at jboss.org (Farah Juma (JIRA))
Date: Thu, 20 Mar 2014 16:22:11 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2594) Undeploy of JSF application
 is throwing SEVERE messages, when there were deployed more JSF apps
In-Reply-To: <JIRA.12526632.1385996741000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12526632.1385996741000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12526632.1385996741000.30291.1395346931036@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2594?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12954760#comment-12954760 ] 

Farah Juma commented on WFLY-2594:
----------------------------------

My patch for JAVASERVERFACES-3189 has now been committed to the Mojarra 2.2.x branch and will be included in the 2.2.7 release.
                
> Undeploy of JSF application is throwing SEVERE messages, when there were deployed more JSF apps
> -----------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2594
>                 URL: https://issues.jboss.org/browse/WFLY-2594
>             Project: WildFly
>          Issue Type: Enhancement
>      Security Level: Public(Everyone can see) 
>          Components: JSF
>         Environment: WildFly Beta2-SNAPSHOT from 2013-12-02
>            Reporter: Tomas Remes
>            Assignee: Farah Juma
>
> When you deploy more than one JSF application and then you undeploy one of them, you'll face following message in server log:
> {noformat}
> SEVERE [javax.faces] (MSC service thread 1-2) Unable to obtain InjectionProvider from init time FacesContext. Does this container implement the Mojarra Injection SPI?
> SEVERE [javax.faces] (MSC service thread 1-2) Unable to call @PreDestroy annotated methods because no InjectionProvider can be found. Does this container implement the Mojarra Injection SPI?
> {noformat}
> I think javax.faces.FactoryFinder.FactoryManagerCache.getApplicationFactoryManager(ClassLoader) shouldn't try to create new instance of FactoryManager in this case. I am not really sure, what is special initialization case, but it seems to me that this should evaluate to true in this case (btw Does this javax.faces.FactoryFinder.FactoryManagerCache.detectSpecialInitializationCase(FacesContext) ever evaluate as true?). 

--
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

From issues at jboss.org  Thu Mar 20 16:42:10 2014
From: issues at jboss.org (Farah Juma (JIRA))
Date: Thu, 20 Mar 2014 16:42:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2713) ViewExpiredException in
 Chrome on WildFly 8.0.0.CR1
In-Reply-To: <JIRA.12528672.1389025086000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528672.1389025086000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528672.1389025086000.30314.1395348130749@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2713?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Farah Juma reassigned WFLY-2713:
--------------------------------

    Assignee: Farah Juma

    
> ViewExpiredException in Chrome on WildFly 8.0.0.CR1
> ---------------------------------------------------
>
>                 Key: WFLY-2713
>                 URL: https://issues.jboss.org/browse/WFLY-2713
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JSF
>    Affects Versions: 8.0.0.CR1
>         Environment: WildFly 8.0.0.CR1
> Chrome 31.0.1650.63 @ Fedora 20 x86_64
>            Reporter: Pavol Pitonak
>            Assignee: Farah Juma
>         Attachments: reproducer.zip
>
>
> # unzip attached reproducer
> # mvn clean package
> # deploy reproducer.war to WildFly 
> # open http://localhost:8080/reproducer/
> # type something to the input
> result:
> * in Chrome, a popup with error is displayed
> * server console contains stack trace:
> {code}
> 17:10:54,852 SEVERE [javax.enterprise.resource.webcontainer.jsf.context] (default task-7) javax.faces.application.ViewExpiredException: viewId:/index.xhtml - View /index.xhtml could not be restored.
> {code}
> * works fine in Firefox 26
> * works fine in WildFly 8.0.0.Beta1

--
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

From issues at jboss.org  Thu Mar 20 16:46:12 2014
From: issues at jboss.org (Tomaz Cerar (JIRA))
Date: Thu, 20 Mar 2014 16:46:12 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3146) Undertow Memory Leak for
	JAX-RS requests
In-Reply-To: <JIRA.12535043.1394808299000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12535043.1394808299000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12535043.1394808299000.30320.1395348372103@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-3146?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tomaz Cerar moved UNDERTOW-203 to WFLY-3146:
--------------------------------------------

              Project: WildFly  (was: Undertow)
                  Key: WFLY-3146  (was: UNDERTOW-203)
    Affects Version/s: 8.0.0.Final
                           (was: 1.0.0.Final)
          Component/s: Web (Undertow)
                           (was: Core)
             Security: Public

    
> Undertow Memory Leak for JAX-RS requests
> ----------------------------------------
>
>                 Key: WFLY-3146
>                 URL: https://issues.jboss.org/browse/WFLY-3146
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web (Undertow)
>    Affects Versions: 8.0.0.Final
>         Environment: Windows 7 Professional
> JDK 1.7.0_21
> WildFly 8.0.0.Final
>            Reporter: Darren Jones
>            Assignee: Tomaz Cerar
>              Labels: MemoryLeak
>         Attachments: hello-client.zip, hello-service-0.1-SNAPSHOT.war, hello-service.zip, JProfiler GC Root.png, server.keystore, standalone.xml, VisualVM Memory.png
>
>
> After half an hour or so of running the automated test suite for our application, the server hangs due to GC and many OutOfMemoryErrors appear in the WildFly server log.
> I've attached VisualVM and JProfiler, both of which demonstrate that many of the objects that are not being garbage collected are Undertow objects. Both tools show that the path to the GC root is via a Java nio SelectionKey, which is held by sun.nio.ch.WindowsSelectorImpl. 
> I'll attach a screenshot of a JProfiler window to demonstrate, but VisualVM shows the same result (albeit presented differently).
> I have also found similar behaviour with a small, trivial example, as described in the Steps to Reproduce. It makes repeated calls to a simple RESTful call to a JAX-RS service. The example doesn't cause as fast a leak as our test suite, but it does demonstrate the problem.
> The example uses https for the call because it seems to leak memory faster than http - but http does also exhibit the problem.
> I have also tried patching WildFly 8.0.0.Final up to Undertow.1.0.2-SNAPSHOT and XNIO.3.3.0-SNAPSHOT (as of this morning), but the problem still occurs.

--
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

From issues at jboss.org  Thu Mar 20 16:46:12 2014
From: issues at jboss.org (Tomaz Cerar (JIRA))
Date: Thu, 20 Mar 2014 16:46:12 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3146) Undertow Memory Leak for
	JAX-RS requests
In-Reply-To: <JIRA.12535043.1394808299000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12535043.1394808299000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12535043.1394808299000.30327.1395348372433@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-3146?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tomaz Cerar updated WFLY-3146:
------------------------------

    Fix Version/s: 8.0.1.Final

    
> Undertow Memory Leak for JAX-RS requests
> ----------------------------------------
>
>                 Key: WFLY-3146
>                 URL: https://issues.jboss.org/browse/WFLY-3146
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web (Undertow)
>    Affects Versions: 8.0.0.Final
>         Environment: Windows 7 Professional
> JDK 1.7.0_21
> WildFly 8.0.0.Final
>            Reporter: Darren Jones
>            Assignee: Tomaz Cerar
>              Labels: MemoryLeak
>             Fix For: 8.0.1.Final
>
>         Attachments: hello-client.zip, hello-service-0.1-SNAPSHOT.war, hello-service.zip, JProfiler GC Root.png, server.keystore, standalone.xml, VisualVM Memory.png
>
>
> After half an hour or so of running the automated test suite for our application, the server hangs due to GC and many OutOfMemoryErrors appear in the WildFly server log.
> I've attached VisualVM and JProfiler, both of which demonstrate that many of the objects that are not being garbage collected are Undertow objects. Both tools show that the path to the GC root is via a Java nio SelectionKey, which is held by sun.nio.ch.WindowsSelectorImpl. 
> I'll attach a screenshot of a JProfiler window to demonstrate, but VisualVM shows the same result (albeit presented differently).
> I have also found similar behaviour with a small, trivial example, as described in the Steps to Reproduce. It makes repeated calls to a simple RESTful call to a JAX-RS service. The example doesn't cause as fast a leak as our test suite, but it does demonstrate the problem.
> The example uses https for the call because it seems to leak memory faster than http - but http does also exhibit the problem.
> I have also tried patching WildFly 8.0.0.Final up to Undertow.1.0.2-SNAPSHOT and XNIO.3.3.0-SNAPSHOT (as of this morning), but the problem still occurs.

--
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

From issues at jboss.org  Thu Mar 20 16:46:12 2014
From: issues at jboss.org (Tomaz Cerar (JIRA))
Date: Thu, 20 Mar 2014 16:46:12 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3146) Undertow Memory Leak for
	JAX-RS requests
In-Reply-To: <JIRA.12535043.1394808299000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12535043.1394808299000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12535043.1394808299000.30330.1395348372617@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-3146?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tomaz Cerar updated WFLY-3146:
------------------------------

    Priority: Critical  (was: Major)

    
> Undertow Memory Leak for JAX-RS requests
> ----------------------------------------
>
>                 Key: WFLY-3146
>                 URL: https://issues.jboss.org/browse/WFLY-3146
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web (Undertow)
>    Affects Versions: 8.0.0.Final
>         Environment: Windows 7 Professional
> JDK 1.7.0_21
> WildFly 8.0.0.Final
>            Reporter: Darren Jones
>            Assignee: Tomaz Cerar
>            Priority: Critical
>              Labels: MemoryLeak
>             Fix For: 8.0.1.Final
>
>         Attachments: hello-client.zip, hello-service-0.1-SNAPSHOT.war, hello-service.zip, JProfiler GC Root.png, server.keystore, standalone.xml, VisualVM Memory.png
>
>
> After half an hour or so of running the automated test suite for our application, the server hangs due to GC and many OutOfMemoryErrors appear in the WildFly server log.
> I've attached VisualVM and JProfiler, both of which demonstrate that many of the objects that are not being garbage collected are Undertow objects. Both tools show that the path to the GC root is via a Java nio SelectionKey, which is held by sun.nio.ch.WindowsSelectorImpl. 
> I'll attach a screenshot of a JProfiler window to demonstrate, but VisualVM shows the same result (albeit presented differently).
> I have also found similar behaviour with a small, trivial example, as described in the Steps to Reproduce. It makes repeated calls to a simple RESTful call to a JAX-RS service. The example doesn't cause as fast a leak as our test suite, but it does demonstrate the problem.
> The example uses https for the call because it seems to leak memory faster than http - but http does also exhibit the problem.
> I have also tried patching WildFly 8.0.0.Final up to Undertow.1.0.2-SNAPSHOT and XNIO.3.3.0-SNAPSHOT (as of this morning), but the problem still occurs.

--
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

From issues at jboss.org  Thu Mar 20 17:08:11 2014
From: issues at jboss.org (Tomaz Cerar (JIRA))
Date: Thu, 20 Mar 2014 17:08:11 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3145) Problem with HTTPS Failed to
 start the http-interface service
In-Reply-To: <JIRA.12535597.1395334662000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12535597.1395334662000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12535597.1395334662000.30389.1395349691589@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-3145?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tomaz Cerar closed WFLY-3145.
-----------------------------

    Resolution: Rejected

    
> Problem with HTTPS Failed to start the http-interface service
> -------------------------------------------------------------
>
>                 Key: WFLY-3145
>                 URL: https://issues.jboss.org/browse/WFLY-3145
>             Project: WildFly
>          Issue Type: Support Request
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 8.0.0.Final
>            Reporter: Jasbir Sahota
>            Assignee: Darran Lofthouse
>


--
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

From issues at jboss.org  Thu Mar 20 18:44:10 2014
From: issues at jboss.org (David Lloyd (JIRA))
Date: Thu, 20 Mar 2014 18:44:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3146) Undertow Memory Leak for
	JAX-RS requests
In-Reply-To: <JIRA.12535043.1394808299000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12535043.1394808299000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12535043.1394808299000.30598.1395355450755@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-3146?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12954787#comment-12954787 ] 

David Lloyd commented on WFLY-3146:
-----------------------------------

https://github.com/xnio/xnio/commit/7dbdf6f5424b seems to take care of the non-SSL case completely.  Still looking into the SSL case.
                
> Undertow Memory Leak for JAX-RS requests
> ----------------------------------------
>
>                 Key: WFLY-3146
>                 URL: https://issues.jboss.org/browse/WFLY-3146
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web (Undertow)
>    Affects Versions: 8.0.0.Final
>         Environment: Windows 7 Professional
> JDK 1.7.0_21
> WildFly 8.0.0.Final
>            Reporter: Darren Jones
>            Assignee: Tomaz Cerar
>            Priority: Critical
>              Labels: MemoryLeak
>             Fix For: 8.0.1.Final
>
>         Attachments: hello-client.zip, hello-service-0.1-SNAPSHOT.war, hello-service.zip, JProfiler GC Root.png, server.keystore, standalone.xml, VisualVM Memory.png
>
>
> After half an hour or so of running the automated test suite for our application, the server hangs due to GC and many OutOfMemoryErrors appear in the WildFly server log.
> I've attached VisualVM and JProfiler, both of which demonstrate that many of the objects that are not being garbage collected are Undertow objects. Both tools show that the path to the GC root is via a Java nio SelectionKey, which is held by sun.nio.ch.WindowsSelectorImpl. 
> I'll attach a screenshot of a JProfiler window to demonstrate, but VisualVM shows the same result (albeit presented differently).
> I have also found similar behaviour with a small, trivial example, as described in the Steps to Reproduce. It makes repeated calls to a simple RESTful call to a JAX-RS service. The example doesn't cause as fast a leak as our test suite, but it does demonstrate the problem.
> The example uses https for the call because it seems to leak memory faster than http - but http does also exhibit the problem.
> I have also tried patching WildFly 8.0.0.Final up to Undertow.1.0.2-SNAPSHOT and XNIO.3.3.0-SNAPSHOT (as of this morning), but the problem still occurs.

--
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

From issues at jboss.org  Thu Mar 20 18:56:10 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 20 Mar 2014 18:56:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBEE-146) jboss-el-api_2.2_spec
 1.0.2.Final cannot access public methods from non-public classes
In-Reply-To: <JIRA.12525180.1384462560000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12525180.1384462560000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12525180.1384462560000.30626.1395356170712@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JBEE-146?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12954790#comment-12954790 ] 

RH Bugzilla Integration commented on JBEE-146:
----------------------------------------------

Vaclav Tunka <vtunka at redhat.com> changed the Status of [bug 1076320|https://bugzilla.redhat.com/show_bug.cgi?id=1076320] from MODIFIED to ON_QA
                
> jboss-el-api_2.2_spec 1.0.2.Final cannot access public methods from non-public classes
> --------------------------------------------------------------------------------------
>
>                 Key: JBEE-146
>                 URL: https://issues.jboss.org/browse/JBEE-146
>             Project: JBoss JavaEE Spec APIs
>          Issue Type: Bug
>            Reporter: Farah Juma
>            Assignee: Farah Juma
>             Fix For: jboss-el-api_2.2_spec-1.0.3.Final, jboss-el-api_3.0_spec-1.0.0.Final
>
>
> When accessing a public method of a non-public class via EL that implements a public interface or has a public superclass, the following exception occurs:
> {code}java.lang.IllegalAccessException: Class javax.el.BeanELResolver can not access a member of class X with modifiers "public" 
> {code}
> See https://bugzilla.redhat.com/show_bug.cgi?id=1029387 for more 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

From issues at jboss.org  Thu Mar 20 18:56:10 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 20 Mar 2014 18:56:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2493) EL cannot access public
 methods/fields of non-public classes
In-Reply-To: <JIRA.12524859.1384250001000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12524859.1384250001000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12524859.1384250001000.30628.1395356170802@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2493?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12954791#comment-12954791 ] 

RH Bugzilla Integration commented on WFLY-2493:
-----------------------------------------------

Vaclav Tunka <vtunka at redhat.com> changed the Status of [bug 1076320|https://bugzilla.redhat.com/show_bug.cgi?id=1076320] from MODIFIED to ON_QA
                
> EL cannot access public methods/fields of non-public classes
> ------------------------------------------------------------
>
>                 Key: WFLY-2493
>                 URL: https://issues.jboss.org/browse/WFLY-2493
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JSF
>         Environment: JBoss AS 7.2.0.Final
>            Reporter: Jon?? Trantina
>         Attachments: elresolver_stack, reproducer.zip
>
>
> When trying to access public method/field of non-public class that implements public interface via EL I get 
> {noformat}
> java.lang.IllegalAccessException: Class javax.el.BeanELResolver can not access a member of class X with modifiers "private"
> {noformat}
> E.g. accessing Collections.unmodifiableList(..).size() via EL will throw the exception, because #unmodifiableList returns non-public implementation of List interface.
> This is apparently caused by JDK-4071957 [1], but since that is opened for over 16 years, it should be probably worth it to implement a workaround.
> Workaround for this issue is setting setAccessible(true) on the method before invoking it, thus suppress Java access checking.
> I have attached a simple reproducer app as well as a stack trace of the exception.
> [1] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4071957

--
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


From issues at jboss.org  Thu Mar 20 20:08:11 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 20 Mar 2014 20:08:11 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3067) Webservices DUP is not
 scanning all visible classes for @WebService annotation
In-Reply-To: <JIRA.12534077.1393987223000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534077.1393987223000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534077.1393987223000.30813.1395360491097@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-3067?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated WFLY-3067:
------------------------------------------

        Bugzilla Update: Perform
    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1079084

    
> Webservices DUP is not scanning all visible classes for @WebService annotation
> ------------------------------------------------------------------------------
>
>                 Key: WFLY-3067
>                 URL: https://issues.jboss.org/browse/WFLY-3067
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web Services
>    Affects Versions: 8.0.0.Final
>            Reporter: Kyle Lape
>            Assignee: Jim Ma
>             Fix For: 8.0.1.Final
>
>
> Sample use case:  You have a .war in an .ear, and the .war has a web.xml with a {{<servlet-class>}} that refers to a JAX-WS endpoint, so the class is annotated with {{@WebService}}.  If that class is packaged in a jar found in the ear's lib directory, the JBossWS DUP won't pick it up, and then Undertow will throw an error like this:
> {noformat}
> UT010009: Servlet ClientEndpoint of type class com.redhat.gss.jaxws.ClientEndpoint does not implement javax.servlet.Servlet
> {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

From issues at jboss.org  Thu Mar 20 20:10:10 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 20 Mar 2014 20:10:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3067) Webservices DUP is not
 scanning all visible classes for @WebService annotation
In-Reply-To: <JIRA.12534077.1393987223000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534077.1393987223000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534077.1393987223000.30819.1395360610807@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-3067?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated WFLY-3067:
------------------------------------------

    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1079084, https://bugzilla.redhat.com/show_bug.cgi?id=1079085  (was: https://bugzilla.redhat.com/show_bug.cgi?id=1079084)

    
> Webservices DUP is not scanning all visible classes for @WebService annotation
> ------------------------------------------------------------------------------
>
>                 Key: WFLY-3067
>                 URL: https://issues.jboss.org/browse/WFLY-3067
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web Services
>    Affects Versions: 8.0.0.Final
>            Reporter: Kyle Lape
>            Assignee: Jim Ma
>             Fix For: 8.0.1.Final
>
>
> Sample use case:  You have a .war in an .ear, and the .war has a web.xml with a {{<servlet-class>}} that refers to a JAX-WS endpoint, so the class is annotated with {{@WebService}}.  If that class is packaged in a jar found in the ear's lib directory, the JBossWS DUP won't pick it up, and then Undertow will throw an error like this:
> {noformat}
> UT010009: Servlet ClientEndpoint of type class com.redhat.gss.jaxws.ClientEndpoint does not implement javax.servlet.Servlet
> {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

From issues at jboss.org  Thu Mar 20 20:24:10 2014
From: issues at jboss.org (David Lloyd (JIRA))
Date: Thu, 20 Mar 2014 20:24:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3146) Undertow Memory Leak for
	JAX-RS requests
In-Reply-To: <JIRA.12535043.1394808299000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12535043.1394808299000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12535043.1394808299000.30826.1395361450634@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-3146?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12954800#comment-12954800 ] 

David Lloyd commented on WFLY-3146:
-----------------------------------

Cautiously optimistic that we have a fix for the SSL issue, will confirm soon.
                
> Undertow Memory Leak for JAX-RS requests
> ----------------------------------------
>
>                 Key: WFLY-3146
>                 URL: https://issues.jboss.org/browse/WFLY-3146
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web (Undertow)
>    Affects Versions: 8.0.0.Final
>         Environment: Windows 7 Professional
> JDK 1.7.0_21
> WildFly 8.0.0.Final
>            Reporter: Darren Jones
>            Assignee: Tomaz Cerar
>            Priority: Critical
>              Labels: MemoryLeak
>             Fix For: 8.0.1.Final
>
>         Attachments: hello-client.zip, hello-service-0.1-SNAPSHOT.war, hello-service.zip, JProfiler GC Root.png, server.keystore, standalone.xml, VisualVM Memory.png
>
>
> After half an hour or so of running the automated test suite for our application, the server hangs due to GC and many OutOfMemoryErrors appear in the WildFly server log.
> I've attached VisualVM and JProfiler, both of which demonstrate that many of the objects that are not being garbage collected are Undertow objects. Both tools show that the path to the GC root is via a Java nio SelectionKey, which is held by sun.nio.ch.WindowsSelectorImpl. 
> I'll attach a screenshot of a JProfiler window to demonstrate, but VisualVM shows the same result (albeit presented differently).
> I have also found similar behaviour with a small, trivial example, as described in the Steps to Reproduce. It makes repeated calls to a simple RESTful call to a JAX-RS service. The example doesn't cause as fast a leak as our test suite, but it does demonstrate the problem.
> The example uses https for the call because it seems to leak memory faster than http - but http does also exhibit the problem.
> I have also tried patching WildFly 8.0.0.Final up to Undertow.1.0.2-SNAPSHOT and XNIO.3.3.0-SNAPSHOT (as of this morning), but the problem still occurs.

--
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

From issues at jboss.org  Thu Mar 20 20:46:10 2014
From: issues at jboss.org (David Lloyd (JIRA))
Date: Thu, 20 Mar 2014 20:46:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3146) Undertow Memory Leak for
	JAX-RS requests
In-Reply-To: <JIRA.12535043.1394808299000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12535043.1394808299000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12535043.1394808299000.30866.1395362770795@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-3146?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12954804#comment-12954804 ] 

David Lloyd commented on WFLY-3146:
-----------------------------------

It looks certain that upstream Undertow plus the aforementioned XNIO commits together fix this issue on Linux at least.  [~ctomc] can you confirm Windows?

If Windows is OK, then we can resolve this issue once both XNIO and Undertow releases are tagged and are upstream.

                
> Undertow Memory Leak for JAX-RS requests
> ----------------------------------------
>
>                 Key: WFLY-3146
>                 URL: https://issues.jboss.org/browse/WFLY-3146
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web (Undertow)
>    Affects Versions: 8.0.0.Final
>         Environment: Windows 7 Professional
> JDK 1.7.0_21
> WildFly 8.0.0.Final
>            Reporter: Darren Jones
>            Assignee: Tomaz Cerar
>            Priority: Critical
>              Labels: MemoryLeak
>             Fix For: 8.0.1.Final
>
>         Attachments: hello-client.zip, hello-service-0.1-SNAPSHOT.war, hello-service.zip, JProfiler GC Root.png, server.keystore, standalone.xml, VisualVM Memory.png
>
>
> After half an hour or so of running the automated test suite for our application, the server hangs due to GC and many OutOfMemoryErrors appear in the WildFly server log.
> I've attached VisualVM and JProfiler, both of which demonstrate that many of the objects that are not being garbage collected are Undertow objects. Both tools show that the path to the GC root is via a Java nio SelectionKey, which is held by sun.nio.ch.WindowsSelectorImpl. 
> I'll attach a screenshot of a JProfiler window to demonstrate, but VisualVM shows the same result (albeit presented differently).
> I have also found similar behaviour with a small, trivial example, as described in the Steps to Reproduce. It makes repeated calls to a simple RESTful call to a JAX-RS service. The example doesn't cause as fast a leak as our test suite, but it does demonstrate the problem.
> The example uses https for the call because it seems to leak memory faster than http - but http does also exhibit the problem.
> I have also tried patching WildFly 8.0.0.Final up to Undertow.1.0.2-SNAPSHOT and XNIO.3.3.0-SNAPSHOT (as of this morning), but the problem still occurs.

--
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

From issues at jboss.org  Thu Mar 20 21:02:11 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 20 Mar 2014 21:02:11 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-922) <vault> does not have module
	option
In-Reply-To: <JIRA.12482750.1358377991000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12482750.1358377991000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12482750.1358377991000.30894.1395363731163@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-922?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated WFLY-922:
-----------------------------------------

        Bugzilla Update:   (was: Perform)
    Bugzilla References:   (was: https://bugzilla.redhat.com/show_bug.cgi?id=901327)

    
> <vault> does not have module option
> -----------------------------------
>
>                 Key: WFLY-922
>                 URL: https://issues.jboss.org/browse/WFLY-922
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Security
>            Reporter: James Livingston
>            Assignee: Peter Skopek
>
> The <vault> element in standalone/domain.xml takes a 'code' attribute specifying the class to use as the implementation. It does not let you specify a 'module' option like most similar elements have, and instead always loads the class from the org.picketbox module.
> The <vault> element should take a module option too.

--
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

From issues at jboss.org  Thu Mar 20 21:54:10 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 20 Mar 2014 21:54:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (LOGMGR-95) Log4j Logger.getParent()
	inconsistent
In-Reply-To: <JIRA.12533204.1393309587000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12533204.1393309587000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12533204.1393309587000.30924.1395366850617@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/LOGMGR-95?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated LOGMGR-95:
------------------------------------------

        Bugzilla Update: Perform
    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1079106

    
> Log4j Logger.getParent() inconsistent
> -------------------------------------
>
>                 Key: LOGMGR-95
>                 URL: https://issues.jboss.org/browse/LOGMGR-95
>             Project: JBoss Log Manager
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: James Livingston
>            Assignee: James Perkins
>
> Log4j Loggers have a getParent() method, whose return value is set up by JBossLogManagerFacade.updateParents(). The method locates the closest parent node which has an existing Log4J logger created *at the time*. This results in the parent being different depending on the order Log4j loggers are used in.
> Consider:
>   Logger.getLogger("a");
>   Logger.getLogger("a.b.c");
>   Logger.getLogger("a.b");
> When the second line causes updateParents() to be called, LoggerNode.getOrCreate() has already created the intermediate "a.b" node. That does not yet have a Log4j Logger created, so the Logger for "a" is returned. Original log4j would have returned "a.b" due to it using the parent structure in the implementation.

--
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

From issues at jboss.org  Thu Mar 20 22:12:10 2014
From: issues at jboss.org (David Lloyd (JIRA))
Date: Thu, 20 Mar 2014 22:12:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3146) Undertow Memory Leak for
	JAX-RS requests
In-Reply-To: <JIRA.12535043.1394808299000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12535043.1394808299000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12535043.1394808299000.30930.1395367930691@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-3146?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12954812#comment-12954812 ] 

David Lloyd commented on WFLY-3146:
-----------------------------------

https://github.com/wildfly/wildfly/pull/6067 updates Undertow
https://github.com/wildfly/wildfly/pull/6068 updates XNIO

With these two PRs in I expect this issue will be resolved.
                
> Undertow Memory Leak for JAX-RS requests
> ----------------------------------------
>
>                 Key: WFLY-3146
>                 URL: https://issues.jboss.org/browse/WFLY-3146
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web (Undertow)
>    Affects Versions: 8.0.0.Final
>         Environment: Windows 7 Professional
> JDK 1.7.0_21
> WildFly 8.0.0.Final
>            Reporter: Darren Jones
>            Assignee: Tomaz Cerar
>            Priority: Critical
>              Labels: MemoryLeak
>             Fix For: 8.0.1.Final
>
>         Attachments: hello-client.zip, hello-service-0.1-SNAPSHOT.war, hello-service.zip, JProfiler GC Root.png, server.keystore, standalone.xml, VisualVM Memory.png
>
>
> After half an hour or so of running the automated test suite for our application, the server hangs due to GC and many OutOfMemoryErrors appear in the WildFly server log.
> I've attached VisualVM and JProfiler, both of which demonstrate that many of the objects that are not being garbage collected are Undertow objects. Both tools show that the path to the GC root is via a Java nio SelectionKey, which is held by sun.nio.ch.WindowsSelectorImpl. 
> I'll attach a screenshot of a JProfiler window to demonstrate, but VisualVM shows the same result (albeit presented differently).
> I have also found similar behaviour with a small, trivial example, as described in the Steps to Reproduce. It makes repeated calls to a simple RESTful call to a JAX-RS service. The example doesn't cause as fast a leak as our test suite, but it does demonstrate the problem.
> The example uses https for the call because it seems to leak memory faster than http - but http does also exhibit the problem.
> I have also tried patching WildFly 8.0.0.Final up to Undertow.1.0.2-SNAPSHOT and XNIO.3.3.0-SNAPSHOT (as of this morning), but the problem still occurs.

--
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

From issues at jboss.org  Fri Mar 21 01:50:10 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 21 Mar 2014 01:50:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3131) isSensitiveValue of class
 SensitiveVaultExpressionConstraint uses incorrect index in
 java.lang.String.substring method
In-Reply-To: <JIRA.12535307.1395160191000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12535307.1395160191000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12535307.1395160191000.31068.1395381010805@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-3131?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12954826#comment-12954826 ] 

RH Bugzilla Integration commented on WFLY-3131:
-----------------------------------------------

Jay SenSharma <jsenshar at redhat.com> changed the Status of [bug 1077838|https://bugzilla.redhat.com/show_bug.cgi?id=1077838] from NEW to MODIFIED
                
> isSensitiveValue of class SensitiveVaultExpressionConstraint uses incorrect  index in java.lang.String.substring method
> -----------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-3131
>                 URL: https://issues.jboss.org/browse/WFLY-3131
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>    Affects Versions: 8.0.0.Final
>         Environment: All
>            Reporter: Jay Kumar SenSharma
>            Assignee: Jay Kumar SenSharma
>
> The isSensitiveValue(ModelNode value) method of class "org.jboss.as.controller.access.constraint.SensitiveVaultExpressionConstraint" seems to be using the incorrect  index in java.lang.String.substring method.  Which is causing the following exceptions in the logs while executing the following kind of CLI command:
> {code}
> [standalone at localhost:9990 /] /subsystem=logging/periodic-rotating-file-handler=FILE:write-attribute(name=formatter, value="%d{HH:mm:ss,SSS} %-5p [%c] (${jboss.node.name} %t) %s%E%n")
> {
>     "outcome" => "failed",
>     "failure-description" => "JBAS014749: Operation handler failed: String index out of range: -15",
>     "rolled-back" => true
> }
> {code}
> The Exception can be seen as following in the WildFly Logs:
> {code}
> 21:58:04,821 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 25) JBAS014612: Operation ("write-attribute") failed - address: ([
>     ("subsystem" => "logging"),
>     ("periodic-rotating-file-handler" => "FILE")
> ]): java.lang.StringIndexOutOfBoundsException: String index out of range: -15
> 	at java.lang.String.substring(String.java:1911) [rt.jar:1.7.0_51]
> 	at org.jboss.as.controller.access.constraint.SensitiveVaultExpressionConstraint$Factory.isSensitiveValue(SensitiveVaultExpressionConstraint.java:128) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> 	at org.jboss.as.controller.access.constraint.SensitiveVaultExpressionConstraint$Factory.isSensitiveAction(SensitiveVaultExpressionConstraint.java:89) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> 	at org.jboss.as.controller.access.constraint.SensitiveVaultExpressionConstraint$Factory.getRequiredConstraint(SensitiveVaultExpressionConstraint.java:81) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> 	at org.jboss.as.controller.access.rbac.DefaultPermissionFactory.getRequiredPermissions(DefaultPermissionFactory.java:201) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> 	at org.jboss.as.controller.access.permission.ManagementPermissionAuthorizer.authorize(ManagementPermissionAuthorizer.java:100) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> 	at org.jboss.as.controller.access.management.DelegatingConfigurableAuthorizer.authorize(DelegatingConfigurableAuthorizer.java:98) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> 	at org.jboss.as.controller.OperationContextImpl.getBasicAuthorizationResponse(OperationContextImpl.java:1153) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> 	at org.jboss.as.controller.OperationContextImpl.authorize(OperationContextImpl.java:1055) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> 	at org.jboss.as.controller.OperationContextImpl.authorize(OperationContextImpl.java:1015) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> 	at org.jboss.as.controller.OperationContextImpl.getResourceRegistration(OperationContextImpl.java:265) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> 	at org.jboss.as.controller.operations.global.WriteAttributeHandler.execute(WriteAttributeHandler.java:72) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> 	at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:591) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> 	at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:469) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> 	at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:273) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> 	at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:268) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> 	at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:272) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> 	at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:146) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:174) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$300(ModelControllerClientOperationHandler.java:105) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:125) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:121) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> 	at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.7.0_51]
> 	at javax.security.auth.Subject.doAs(Subject.java:415) [rt.jar:1.7.0_51]
> 	at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:94) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:121) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> 	at org.jboss.as.protocol.mgmt.AbstractMessageHandler$2$1.doExecute(AbstractMessageHandler.java:283) [wildfly-protocol-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> 	at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:504) [wildfly-protocol-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_51]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_51]
> 	at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_51]
> 	at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.1.Final.jar:2.1.1.Final]
> {code}

--
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

From issues at jboss.org  Fri Mar 21 02:52:10 2014
From: issues at jboss.org (Tomas Remes (JIRA))
Date: Fri, 21 Mar 2014 02:52:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3144) Session replication doesn't
 work as expected
In-Reply-To: <JIRA.12535573.1395324594000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12535573.1395324594000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12535573.1395324594000.31137.1395384730735@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-3144?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12954831#comment-12954831 ] 

Tomas Remes commented on WFLY-3144:
-----------------------------------

Reproducible also by TranslatorClusterTest from https://github.com/maschmid/weld-clustering-tests. Replace PATH* variables with your values and you can use following command:

{noformat}

mvn clean verify -Darquillian=wildfly-cluster-8  -Dnode1.jbossHome=${PATH1}  -Dnode2.jbossHome=${PATH2}  -Dnode1.contextPath="http://127.0.0.1:8080/weld-clustering-tests"  -Dnode2.contextPath="http://127.0.0.1:8180/weld-clustering-tests"  -Dnode1.managementAddress=127.0.0.1  -Dnode1.managementPort=9990  -Dnode2.managementAddress=127.0.0.1  -Dnode2.managementPort=10090  -Dnode2.portOffset=100 -Dtest=TranslatorClusterTest

{noformat}
                
> Session replication doesn't work as expected
> --------------------------------------------
>
>                 Key: WFLY-3144
>                 URL: https://issues.jboss.org/browse/WFLY-3144
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: CDI / Weld, EJB
>    Affects Versions: 8.0.0.Final
>            Reporter: Tomas Remes
>            Assignee: Stuart Douglas
>         Attachments: translator.zip
>
>
> I am experimenting with quite simple Stateful SessionScoped bean  ( see org.jboss.weld.tests.clustering.translator.TranslatorControllerBean from attached reproducer) and actually there's not any specific exception, but the behavior is at least weird. I haven't tried with plain EJB so far. Reproducible by following steps:
> 1. Run first node with "/bin/standalone.sh -c standalone-ha.xml"
> 2. Run second node with "./bin/standalone.sh -c standalone-ha.xml -Djboss.socket.binding.port-offset=100 -Djboss.node.name=second"
> 3. Build and deploy attached reproducer
> 4. Open 127.0.0.1:8080/translator in your browser and translate something.
> 5. Open 127.0.0.1:8180/translator and note that number of translated sentences is not replicated correctly. 
> This works correctly in EAP. I am running with default standalone-ha configuration on oracle's 1.7.0_45 jdk.

--
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

From issues at jboss.org  Fri Mar 21 05:14:10 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 21 Mar 2014 05:14:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3112) One can't change history and
 decay with DynamicLoadBalanceFactorProvider
In-Reply-To: <JIRA.12534709.1394560666000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534709.1394560666000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534709.1394560666000.31517.1395393250696@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-3112?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12954864#comment-12954864 ] 

RH Bugzilla Integration commented on WFLY-3112:
-----------------------------------------------

Michal Babacek <mbabacek at redhat.com> changed the Status of [bug 1075215|https://bugzilla.redhat.com/show_bug.cgi?id=1075215] from ON_QA to VERIFIED
                
> One can't change history and decay with DynamicLoadBalanceFactorProvider
> ------------------------------------------------------------------------
>
>                 Key: WFLY-3112
>                 URL: https://issues.jboss.org/browse/WFLY-3112
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Clustering
>    Affects Versions: 8.0.0.Final
>            Reporter: Michal Babacek
>            Assignee: Radoslav Husar
>            Priority: Critical
>             Fix For: 8.0.1.Final
>
>         Attachments: redacted_log
>
>
> I'm under an ugly impression that one can't actually change {{history}} and {{decay}} attributes of *DynamicLoadBalanceFactorProvider*.
> I was trying to figure out why the new test suite of CustomLoadMetric tests does not pass. In order to get load figures without history and decay manipulation, I set the following:
> {code}
> <subsystem xmlns="urn:jboss:domain:modcluster:1.2">
>     <mod-cluster-config advertise-socket="modcluster" connector="ajp">
>     <dynamic-load-provider history="0">
>         <custom-load-metric class="biz.karms.modcluster.CustomLoadMetric" weight="1">
>             <property name="capacity" value="1000"/>
>             <property name="loadfile" value="/tmp/mod_cluster-eapx/loadfileA"/>
>             <property name="parseexpression" value="^LOAD: ([0-9]*)$"/>
>         </custom-load-metric>
>     </dynamic-load-provider>
>     </mod-cluster-config>
> </subsystem>
> {code}
> The aforementioned {{history=0}} effectively means that there is just 1 "slot" for a one historical value on which decay function should work.
> If you take a look at the code in [DynamicLoadBalanceFactorProvider|https://github.com/modcluster/mod_cluster/blob/master/core/src/main/java/org/jboss/modcluster/load/impl/DynamicLoadBalanceFactorProvider.java#L54] constructor, it is apparent
> that the size of the List that later serves for storing the historical values is set sooner than the actual [setHistory(int history)|https://github.com/modcluster/mod_cluster/blob/master/core/src/main/java/org/jboss/modcluster/load/impl/DynamicLoadBalanceFactorProvider.java#L177] method is called.
> The actual size of that List collection wouldn't do any harm by itself but it is being used in the aforementioned class with {{.size()}} to control cycles.
> The same IMHO holds for the decay attribute.
> Anyhow, I put some additional logging to the [DynamicLoadBalanceFactorProvider.java|https://github.com/modcluster/mod_cluster/blob/master/core/src/main/java/org/jboss/modcluster/load/impl/DynamicLoadBalanceFactorProvider.java]:
> {code}
> // Historical value contribute an exponentially decayed factor
> for (int i = 0; i < queue.size(); ++i) {
>     double decay = 1 / Math.pow(decayFactor, i);
>     totalDecay += decay;
>     this.log.info("KTAG: totalLoad:"+totalLoad+", with decay:"+(totalLoad+queue.get(i).doubleValue() * decay));
>     totalLoad += queue.get(i).doubleValue() * decay;
> }
> {code}
> and
> {code}
> try {
>     // Normalize load with respect to capacity
>     this.recordLoad(metricLoadHistory, metric.getLoad(engine) / metric.getCapacity());
>     this.log.info("KTAG metricLoadHistory:"+metricLoadHistory.toString());
>     totalWeight += weight;
>     totalWeightedLoad += this.average(metricLoadHistory) * weight;
> } catch (Exception e) {
>     this.log.error(e.getLocalizedMessage(), e);
> }
> {code}
> with the following being the output: [^redacted_log].
> So, despite having {{history=0}}, which should force the system to keep just 1, the current value, {{metricLoadHistory}} grew from
> {noformat}
> KTAG metricLoadHistory:[0.8]
> {noformat}
> to
> {noformat}
> KTAG metricLoadHistory:[0.9, 0.9, 0.9, 0.9, 0.9, 0.9, 0.9, 0.9, 0.9, 0.8]
> {noformat}
> which is exactly [9|https://github.com/modcluster/mod_cluster/blob/master/core/src/main/java/org/jboss/modcluster/load/impl/DynamicLoadBalanceFactorProvider.java#L50] + [1|https://github.com/modcluster/mod_cluster/blob/master/core/src/main/java/org/jboss/modcluster/load/impl/DynamicLoadBalanceFactorProvider.java#L54] in size :-)
> WDYT?

--
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

From issues at jboss.org  Fri Mar 21 06:12:10 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 21 Mar 2014 06:12:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3131) isSensitiveValue of class
 SensitiveVaultExpressionConstraint uses incorrect index in
 java.lang.String.substring method
In-Reply-To: <JIRA.12535307.1395160191000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12535307.1395160191000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12535307.1395160191000.31628.1395396730840@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-3131?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12954882#comment-12954882 ] 

RH Bugzilla Integration commented on WFLY-3131:
-----------------------------------------------

Kabir Khan <kkhan at redhat.com> changed the Status of [bug 1077838|https://bugzilla.redhat.com/show_bug.cgi?id=1077838] from MODIFIED to POST
                
> isSensitiveValue of class SensitiveVaultExpressionConstraint uses incorrect  index in java.lang.String.substring method
> -----------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-3131
>                 URL: https://issues.jboss.org/browse/WFLY-3131
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>    Affects Versions: 8.0.0.Final
>         Environment: All
>            Reporter: Jay Kumar SenSharma
>            Assignee: Jay Kumar SenSharma
>
> The isSensitiveValue(ModelNode value) method of class "org.jboss.as.controller.access.constraint.SensitiveVaultExpressionConstraint" seems to be using the incorrect  index in java.lang.String.substring method.  Which is causing the following exceptions in the logs while executing the following kind of CLI command:
> {code}
> [standalone at localhost:9990 /] /subsystem=logging/periodic-rotating-file-handler=FILE:write-attribute(name=formatter, value="%d{HH:mm:ss,SSS} %-5p [%c] (${jboss.node.name} %t) %s%E%n")
> {
>     "outcome" => "failed",
>     "failure-description" => "JBAS014749: Operation handler failed: String index out of range: -15",
>     "rolled-back" => true
> }
> {code}
> The Exception can be seen as following in the WildFly Logs:
> {code}
> 21:58:04,821 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 25) JBAS014612: Operation ("write-attribute") failed - address: ([
>     ("subsystem" => "logging"),
>     ("periodic-rotating-file-handler" => "FILE")
> ]): java.lang.StringIndexOutOfBoundsException: String index out of range: -15
> 	at java.lang.String.substring(String.java:1911) [rt.jar:1.7.0_51]
> 	at org.jboss.as.controller.access.constraint.SensitiveVaultExpressionConstraint$Factory.isSensitiveValue(SensitiveVaultExpressionConstraint.java:128) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> 	at org.jboss.as.controller.access.constraint.SensitiveVaultExpressionConstraint$Factory.isSensitiveAction(SensitiveVaultExpressionConstraint.java:89) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> 	at org.jboss.as.controller.access.constraint.SensitiveVaultExpressionConstraint$Factory.getRequiredConstraint(SensitiveVaultExpressionConstraint.java:81) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> 	at org.jboss.as.controller.access.rbac.DefaultPermissionFactory.getRequiredPermissions(DefaultPermissionFactory.java:201) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> 	at org.jboss.as.controller.access.permission.ManagementPermissionAuthorizer.authorize(ManagementPermissionAuthorizer.java:100) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> 	at org.jboss.as.controller.access.management.DelegatingConfigurableAuthorizer.authorize(DelegatingConfigurableAuthorizer.java:98) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> 	at org.jboss.as.controller.OperationContextImpl.getBasicAuthorizationResponse(OperationContextImpl.java:1153) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> 	at org.jboss.as.controller.OperationContextImpl.authorize(OperationContextImpl.java:1055) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> 	at org.jboss.as.controller.OperationContextImpl.authorize(OperationContextImpl.java:1015) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> 	at org.jboss.as.controller.OperationContextImpl.getResourceRegistration(OperationContextImpl.java:265) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> 	at org.jboss.as.controller.operations.global.WriteAttributeHandler.execute(WriteAttributeHandler.java:72) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> 	at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:591) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> 	at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:469) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> 	at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:273) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> 	at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:268) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> 	at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:272) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> 	at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:146) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:174) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$300(ModelControllerClientOperationHandler.java:105) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:125) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:121) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> 	at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.7.0_51]
> 	at javax.security.auth.Subject.doAs(Subject.java:415) [rt.jar:1.7.0_51]
> 	at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:94) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:121) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> 	at org.jboss.as.protocol.mgmt.AbstractMessageHandler$2$1.doExecute(AbstractMessageHandler.java:283) [wildfly-protocol-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> 	at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:504) [wildfly-protocol-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_51]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_51]
> 	at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_51]
> 	at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.1.Final.jar:2.1.1.Final]
> {code}

--
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

From issues at jboss.org  Fri Mar 21 06:30:11 2014
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Fri, 21 Mar 2014 06:30:11 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3143) Upgrade to JBoss Negotiation
	2.3.0.Beta1
In-Reply-To: <JIRA.12535552.1395315746000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12535552.1395315746000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12535552.1395315746000.31652.1395397811291@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-3143?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse resolved WFLY-3143.
------------------------------------

    Resolution: Done

    
> Upgrade to JBoss Negotiation 2.3.0.Beta1
> ----------------------------------------
>
>                 Key: WFLY-3143
>                 URL: https://issues.jboss.org/browse/WFLY-3143
>             Project: WildFly
>          Issue Type: Component  Upgrade
>      Security Level: Public(Everyone can see) 
>          Components: Security
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 9.0.0.CR1
>
>


--
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

From issues at jboss.org  Fri Mar 21 06:32:10 2014
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Fri, 21 Mar 2014 06:32:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3141) Change the ModuleMap to map
 Kerberos to the new JBoss Negotiation KerberosLoginModule
In-Reply-To: <JIRA.12535469.1395253702000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12535469.1395253702000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12535469.1395253702000.31661.1395397930620@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-3141?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse resolved WFLY-3141.
------------------------------------

    Resolution: Done

    
> Change the ModuleMap to map Kerberos to the new JBoss Negotiation KerberosLoginModule
> -------------------------------------------------------------------------------------
>
>                 Key: WFLY-3141
>                 URL: https://issues.jboss.org/browse/WFLY-3141
>             Project: WildFly
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Security
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 9.0.0.CR1
>
>
> At the moment the ModuleOptions map maps the Kerberos short name to the com.sun LoginModule, instead map to the JBoss Negotation KerberosLoginModule which adds two new capabilities: -
>  1 - Wrap instantiation of whichever module is actually available.
> Note: It does not translate options from one to the other so those are still JDK specific.
>  2 - Adds an addGSSCredential option so that the module will add a GSSCredential to the Subject.
> This part is needed where the returned Subject is then going to be used with JCA.

--
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

From issues at jboss.org  Fri Mar 21 06:50:10 2014
From: issues at jboss.org (Darren Jones (JIRA))
Date: Fri, 21 Mar 2014 06:50:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3146) Undertow Memory Leak for
	JAX-RS requests
In-Reply-To: <JIRA.12535043.1394808299000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12535043.1394808299000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12535043.1394808299000.31688.1395399010637@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-3146?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12954891#comment-12954891 ] 

Darren Jones commented on WFLY-3146:
------------------------------------

FWIW - I've just tried a local build with WildFly 8.0.1.Final-SNAPSHOT, locally patched with those POM changes in the pull requests to use XNIO 3.2.1.Final and Undertow 1.0.2.Final.

I am no longer seeing the memory leak.

Many thanks!
                
> Undertow Memory Leak for JAX-RS requests
> ----------------------------------------
>
>                 Key: WFLY-3146
>                 URL: https://issues.jboss.org/browse/WFLY-3146
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web (Undertow)
>    Affects Versions: 8.0.0.Final
>         Environment: Windows 7 Professional
> JDK 1.7.0_21
> WildFly 8.0.0.Final
>            Reporter: Darren Jones
>            Assignee: Tomaz Cerar
>            Priority: Critical
>              Labels: MemoryLeak
>             Fix For: 8.0.1.Final
>
>         Attachments: hello-client.zip, hello-service-0.1-SNAPSHOT.war, hello-service.zip, JProfiler GC Root.png, server.keystore, standalone.xml, VisualVM Memory.png
>
>
> After half an hour or so of running the automated test suite for our application, the server hangs due to GC and many OutOfMemoryErrors appear in the WildFly server log.
> I've attached VisualVM and JProfiler, both of which demonstrate that many of the objects that are not being garbage collected are Undertow objects. Both tools show that the path to the GC root is via a Java nio SelectionKey, which is held by sun.nio.ch.WindowsSelectorImpl. 
> I'll attach a screenshot of a JProfiler window to demonstrate, but VisualVM shows the same result (albeit presented differently).
> I have also found similar behaviour with a small, trivial example, as described in the Steps to Reproduce. It makes repeated calls to a simple RESTful call to a JAX-RS service. The example doesn't cause as fast a leak as our test suite, but it does demonstrate the problem.
> The example uses https for the call because it seems to leak memory faster than http - but http does also exhibit the problem.
> I have also tried patching WildFly 8.0.0.Final up to Undertow.1.0.2-SNAPSHOT and XNIO.3.3.0-SNAPSHOT (as of this morning), but the problem still occurs.

--
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

From issues at jboss.org  Fri Mar 21 06:54:10 2014
From: issues at jboss.org (Miroslav Novak (JIRA))
Date: Fri, 21 Mar 2014 06:54:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3077) Convert command line IPv6 URL
 literals to address literals
In-Reply-To: <JIRA.12534346.1394155395000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534346.1394155395000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534346.1394155395000.31698.1395399250902@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-3077?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12954892#comment-12954892 ] 

Miroslav Novak commented on WFLY-3077:
--------------------------------------

[...] should also be stripped from properties: jboss.bind.address, jboss.bind.address.management, jboss.bind.address.unsecure,
                
> Convert command line IPv6 URL literals to address literals
> ----------------------------------------------------------
>
>                 Key: WFLY-3077
>                 URL: https://issues.jboss.org/browse/WFLY-3077
>             Project: WildFly
>          Issue Type: Enhancement
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 8.0.0.Final
>            Reporter: Brian Stansberry
>            Assignee: Brian Stansberry
>            Priority: Minor
>             Fix For: 8.0.1.Final
>
>
> When people provide URL-style values like [::1] for command line args like -b, convert them to address values (i.e. strip the enclosing brackets.)

--
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

From issues at jboss.org  Fri Mar 21 06:58:10 2014
From: issues at jboss.org (Maxim Frolov (JIRA))
Date: Fri, 21 Mar 2014 06:58:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3147)
 spec-descriptor-property-replacement causes NPE while parsing exclude
 element in beans.xml
In-Reply-To: <JIRA.12535673.1395399376013@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12535673.1395399376013@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12535673.1395399376013.31702.1395399490554@jira02.app.mwc.hst.phx2.redhat.com>

Maxim Frolov created WFLY-3147:
----------------------------------

             Summary: spec-descriptor-property-replacement causes NPE while parsing exclude element in beans.xml
                 Key: WFLY-3147
                 URL: https://issues.jboss.org/browse/WFLY-3147
             Project: WildFly
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: CDI / Weld, EE
    Affects Versions: 8.0.0.Final
            Reporter: Maxim Frolov
            Assignee: Stuart Douglas


A CDI Bean Archive with a _beans.xml_ which contains {{beans/scan/*exclude*}} XML element causes {{NullPointerExcpetion}} during deployment on server with enabled {{<spec-descriptor-property-replacement>}} parameter in server's _standalone.xml_.

The error stack trace is:
{noformat}
2014-03-21 11:22:52,455 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-11) MSC000001: Failed to start service jboss.deployment.subunit."example.ear"."example-ejb.jar".PARSE: org.jboss.msc.service.StartException in service jboss.deployment.subunit."example.ear"."example-ejb.jar".PARSE: JBAS018733: Failed to process phase PARSE of subdeployment "example-ejb.jar" of deployment "example.ear"
	at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:166) [wildfly-server-8.0.0.Final.jar:8.0.0.Final]
	at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) [jboss-msc-1.2.0.Final.jar:1.2.0.Final]
	at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) [jboss-msc-1.2.0.Final.jar:1.2.0.Final]
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_45]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_45]
	at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_45]
Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: java.lang.NullPointerException
	at org.jboss.as.weld.deployment.processors.BeansXmlProcessor.parseBeansXml(BeansXmlProcessor.java:140)
	at org.jboss.as.weld.deployment.processors.BeansXmlProcessor.deploy(BeansXmlProcessor.java:117)
	at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:159) [wildfly-server-8.0.0.Final.jar:8.0.0.Final]
	... 5 more
Caused by: java.lang.NullPointerException
	at org.jboss.metadata.property.DefaultPropertyReplacer.replaceProperties(DefaultPropertyReplacer.java:52)
	at org.jboss.as.weld.deployment.PropertyReplacingBeansXmlHandler.interpolate(PropertyReplacingBeansXmlHandler.java:64)
	at org.jboss.weld.xml.BeansXmlHandler$4.processStartChildElement(BeansXmlHandler.java:229)
	at org.jboss.weld.xml.BeansXmlHandler.startElement(BeansXmlHandler.java:297)
	at org.apache.xerces.parsers.AbstractSAXParser.startElement(Unknown Source)
	at org.apache.xerces.parsers.AbstractXMLDocumentParser.emptyElement(Unknown Source)
	at org.apache.xerces.impl.xs.XMLSchemaValidator.emptyElement(Unknown Source)
	at org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanStartElement(Unknown Source)
	at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown Source)
	at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown Source)
	at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
	at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
	at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
	at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source)
	at org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser.parse(Unknown Source)
	at org.apache.xerces.jaxp.SAXParserImpl.parse(Unknown Source)
	at org.jboss.weld.xml.BeansXmlParser.parse(BeansXmlParser.java:93)
	at org.jboss.as.weld.deployment.processors.BeansXmlProcessor.parseBeansXml(BeansXmlProcessor.java:136)
	... 7 more

{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

From issues at jboss.org  Fri Mar 21 07:12:10 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 21 Mar 2014 07:12:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2303) mod_cluster XSD is missing
 property and worker-timeout definitions
In-Reply-To: <JIRA.12503065.1381830758000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12503065.1381830758000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12503065.1381830758000.31733.1395400330544@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2303?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12954899#comment-12954899 ] 

RH Bugzilla Integration commented on WFLY-2303:
-----------------------------------------------

Radoslav Husar <rhusar at redhat.com> changed the Status of [bug 1020142|https://bugzilla.redhat.com/show_bug.cgi?id=1020142] from ASSIGNED to POST
                
> mod_cluster XSD is missing property and worker-timeout definitions
> ------------------------------------------------------------------
>
>                 Key: WFLY-2303
>                 URL: https://issues.jboss.org/browse/WFLY-2303
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Clustering
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Radoslav Husar
>            Assignee: Radoslav Husar
>             Fix For: 8.0.0.CR1
>
>
> * worker-timeout
> * property
> are missing.
> Also missing in 7.x

--
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

From issues at jboss.org  Fri Mar 21 07:50:11 2014
From: issues at jboss.org (Harald Pehl (JIRA))
Date: Fri, 21 Mar 2014 07:50:11 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3148) Update to HAL 2.2.1.Final
In-Reply-To: <JIRA.12535686.1395402595132@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12535686.1395402595132@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12535686.1395402595132.31846.1395402611217@jira02.app.mwc.hst.phx2.redhat.com>

Harald Pehl created WFLY-3148:
---------------------------------

             Summary: Update to HAL 2.2.1.Final
                 Key: WFLY-3148
                 URL: https://issues.jboss.org/browse/WFLY-3148
             Project: WildFly
          Issue Type: Component  Upgrade
      Security Level: Public (Everyone can see)
          Components: Web Console
            Reporter: Harald Pehl
            Assignee: Harald Pehl
             Fix For: 8.0.1.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

From issues at jboss.org  Fri Mar 21 07:54:11 2014
From: issues at jboss.org (Bela Ban (JIRA))
Date: Fri, 21 Mar 2014 07:54:11 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1809) New discovery protocol to be
 used in conjunction with SHARED_LOOPBACK
In-Reply-To: <JIRA.12535687.1395402818805@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12535687.1395402818805@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12535687.1395402818805.31853.1395402851223@jira02.app.mwc.hst.phx2.redhat.com>

Bela Ban created JGRP-1809:
------------------------------

             Summary: New discovery protocol to be used in conjunction with SHARED_LOOPBACK
                 Key: JGRP-1809
                 URL: https://issues.jboss.org/browse/JGRP-1809
             Project: JGroups
          Issue Type: Enhancement
            Reporter: Bela Ban
            Assignee: Bela Ban
            Priority: Minor
             Fix For: 3.5


Sometimes tests in the testsuite fail because the nodes run over SHARED_LOOPBACK fail to discover each other and therefore don't form a cluster. This can happen because discovery requests sent via PING are discarded on a full thread pool.
Because the default test stack doesn't have a MERGE protocol, members won't get merged back.

h5. GOAL
* Create a discovery protocol which always discovers other members registered with the same cluster 

h5. SOLUTION
* Instead of using SHARED_LOOPBACK to send and receive discovery requests, query SHARED_LOOPBACK directly for discovery information. E.g. if we have members A,B,C registered with cluster "demo" in SHARED_LOOPBACK, then a node D joining can fetch (via SHARED_LOOPBACK_PING) the PingData of A, B and C directly from SHARED_LOOPBACK.
This way, we won't have any failed test cases (run over SHARED_LOOPBACK) which fail because no other members were discovered. Also, discovery (even for the first node started in a cluster) is very fast, and we don't need the timeout at all.

--
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

From issues at jboss.org  Fri Mar 21 07:56:11 2014
From: issues at jboss.org (Bela Ban (JIRA))
Date: Fri, 21 Mar 2014 07:56:11 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1809) New discovery protocol to be
 used in conjunction with SHARED_LOOPBACK
In-Reply-To: <JIRA.12535687.1395402818000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12535687.1395402818000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12535687.1395402818000.31858.1395402971001@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JGRP-1809?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban updated JGRP-1809:
---------------------------

    Description: 
Sometimes tests in the testsuite fail because the nodes run over SHARED_LOOPBACK fail to discover each other and therefore don't form a cluster. This can happen because discovery requests sent via PING are discarded on a full thread pool.
Because the default test stack doesn't have a MERGE protocol, members won't get merged back.

h5. GOAL
* Create a discovery protocol which always discovers other members registered with the same cluster 

h5. SOLUTION
* Instead of using SHARED_LOOPBACK to send and receive discovery requests, query SHARED_LOOPBACK directly for discovery information. E.g. if we have members A,B,C registered with cluster "demo" in SHARED_LOOPBACK, then a node D joining can fetch (via SHARED_LOOPBACK_PING) the PingData of A, B and C directly from SHARED_LOOPBACK.
* This way, we won't have any failed test cases (run over SHARED_LOOPBACK) which fail because no other members were discovered. Also, discovery (even for the first node started in a cluster) is very fast, and we don't need the timeout at all.
* Also, we don't need to add a MERGE protocol to the stack as merging is not needed

  was:
Sometimes tests in the testsuite fail because the nodes run over SHARED_LOOPBACK fail to discover each other and therefore don't form a cluster. This can happen because discovery requests sent via PING are discarded on a full thread pool.
Because the default test stack doesn't have a MERGE protocol, members won't get merged back.

h5. GOAL
* Create a discovery protocol which always discovers other members registered with the same cluster 

h5. SOLUTION
* Instead of using SHARED_LOOPBACK to send and receive discovery requests, query SHARED_LOOPBACK directly for discovery information. E.g. if we have members A,B,C registered with cluster "demo" in SHARED_LOOPBACK, then a node D joining can fetch (via SHARED_LOOPBACK_PING) the PingData of A, B and C directly from SHARED_LOOPBACK.
This way, we won't have any failed test cases (run over SHARED_LOOPBACK) which fail because no other members were discovered. Also, discovery (even for the first node started in a cluster) is very fast, and we don't need the timeout at all.


    
> New discovery protocol to be used in conjunction with SHARED_LOOPBACK
> ---------------------------------------------------------------------
>
>                 Key: JGRP-1809
>                 URL: https://issues.jboss.org/browse/JGRP-1809
>             Project: JGroups
>          Issue Type: Enhancement
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>            Priority: Minor
>             Fix For: 3.5
>
>
> Sometimes tests in the testsuite fail because the nodes run over SHARED_LOOPBACK fail to discover each other and therefore don't form a cluster. This can happen because discovery requests sent via PING are discarded on a full thread pool.
> Because the default test stack doesn't have a MERGE protocol, members won't get merged back.
> h5. GOAL
> * Create a discovery protocol which always discovers other members registered with the same cluster 
> h5. SOLUTION
> * Instead of using SHARED_LOOPBACK to send and receive discovery requests, query SHARED_LOOPBACK directly for discovery information. E.g. if we have members A,B,C registered with cluster "demo" in SHARED_LOOPBACK, then a node D joining can fetch (via SHARED_LOOPBACK_PING) the PingData of A, B and C directly from SHARED_LOOPBACK.
> * This way, we won't have any failed test cases (run over SHARED_LOOPBACK) which fail because no other members were discovered. Also, discovery (even for the first node started in a cluster) is very fast, and we don't need the timeout at all.
> * Also, we don't need to add a MERGE protocol to the stack as merging is not needed

--
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

From issues at jboss.org  Fri Mar 21 08:30:10 2014
From: issues at jboss.org (Mohan Potturi (JIRA))
Date: Fri, 21 Mar 2014 08:30:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3149) Windows service on 64 bit
 systems cannot be stopped
In-Reply-To: <JIRA.12535694.1395404895679@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12535694.1395404895679@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12535694.1395404895679.31927.1395405010710@jira02.app.mwc.hst.phx2.redhat.com>

Mohan Potturi created WFLY-3149:
-----------------------------------

             Summary: Windows service on 64 bit systems cannot be stopped
                 Key: WFLY-3149
                 URL: https://issues.jboss.org/browse/WFLY-3149
             Project: WildFly
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions: 8.0.0.Final
         Environment: Windows 2008 Server, Windows 7 professional - both 64 bit systems using JDK 1.7.0_09
            Reporter: Mohan Potturi


The Windows service cannot be stopped. It says 'stopping' in the windows service user interface window. The only way to stop it is ti actually kill the java process. It works flawlessly on 32 bit systems though.

--
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

From issues at jboss.org  Fri Mar 21 09:14:11 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 21 Mar 2014 09:14:11 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3131) isSensitiveValue of class
 SensitiveVaultExpressionConstraint uses incorrect index in
 java.lang.String.substring method
In-Reply-To: <JIRA.12535307.1395160191000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12535307.1395160191000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12535307.1395160191000.32090.1395407651072@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-3131?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12954959#comment-12954959 ] 

RH Bugzilla Integration commented on WFLY-3131:
-----------------------------------------------

Kabir Khan <kkhan at redhat.com> changed the Status of [bug 1077838|https://bugzilla.redhat.com/show_bug.cgi?id=1077838] from POST to MODIFIED
                
> isSensitiveValue of class SensitiveVaultExpressionConstraint uses incorrect  index in java.lang.String.substring method
> -----------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-3131
>                 URL: https://issues.jboss.org/browse/WFLY-3131
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>    Affects Versions: 8.0.0.Final
>         Environment: All
>            Reporter: Jay Kumar SenSharma
>            Assignee: Jay Kumar SenSharma
>
> The isSensitiveValue(ModelNode value) method of class "org.jboss.as.controller.access.constraint.SensitiveVaultExpressionConstraint" seems to be using the incorrect  index in java.lang.String.substring method.  Which is causing the following exceptions in the logs while executing the following kind of CLI command:
> {code}
> [standalone at localhost:9990 /] /subsystem=logging/periodic-rotating-file-handler=FILE:write-attribute(name=formatter, value="%d{HH:mm:ss,SSS} %-5p [%c] (${jboss.node.name} %t) %s%E%n")
> {
>     "outcome" => "failed",
>     "failure-description" => "JBAS014749: Operation handler failed: String index out of range: -15",
>     "rolled-back" => true
> }
> {code}
> The Exception can be seen as following in the WildFly Logs:
> {code}
> 21:58:04,821 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 25) JBAS014612: Operation ("write-attribute") failed - address: ([
>     ("subsystem" => "logging"),
>     ("periodic-rotating-file-handler" => "FILE")
> ]): java.lang.StringIndexOutOfBoundsException: String index out of range: -15
> 	at java.lang.String.substring(String.java:1911) [rt.jar:1.7.0_51]
> 	at org.jboss.as.controller.access.constraint.SensitiveVaultExpressionConstraint$Factory.isSensitiveValue(SensitiveVaultExpressionConstraint.java:128) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> 	at org.jboss.as.controller.access.constraint.SensitiveVaultExpressionConstraint$Factory.isSensitiveAction(SensitiveVaultExpressionConstraint.java:89) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> 	at org.jboss.as.controller.access.constraint.SensitiveVaultExpressionConstraint$Factory.getRequiredConstraint(SensitiveVaultExpressionConstraint.java:81) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> 	at org.jboss.as.controller.access.rbac.DefaultPermissionFactory.getRequiredPermissions(DefaultPermissionFactory.java:201) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> 	at org.jboss.as.controller.access.permission.ManagementPermissionAuthorizer.authorize(ManagementPermissionAuthorizer.java:100) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> 	at org.jboss.as.controller.access.management.DelegatingConfigurableAuthorizer.authorize(DelegatingConfigurableAuthorizer.java:98) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> 	at org.jboss.as.controller.OperationContextImpl.getBasicAuthorizationResponse(OperationContextImpl.java:1153) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> 	at org.jboss.as.controller.OperationContextImpl.authorize(OperationContextImpl.java:1055) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> 	at org.jboss.as.controller.OperationContextImpl.authorize(OperationContextImpl.java:1015) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> 	at org.jboss.as.controller.OperationContextImpl.getResourceRegistration(OperationContextImpl.java:265) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> 	at org.jboss.as.controller.operations.global.WriteAttributeHandler.execute(WriteAttributeHandler.java:72) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> 	at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:591) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> 	at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:469) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> 	at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:273) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> 	at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:268) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> 	at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:272) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> 	at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:146) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:174) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$300(ModelControllerClientOperationHandler.java:105) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:125) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:121) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> 	at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.7.0_51]
> 	at javax.security.auth.Subject.doAs(Subject.java:415) [rt.jar:1.7.0_51]
> 	at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:94) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:121) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> 	at org.jboss.as.protocol.mgmt.AbstractMessageHandler$2$1.doExecute(AbstractMessageHandler.java:283) [wildfly-protocol-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> 	at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:504) [wildfly-protocol-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_51]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_51]
> 	at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_51]
> 	at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.1.Final.jar:2.1.1.Final]
> {code}

--
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

From issues at jboss.org  Fri Mar 21 09:20:11 2014
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Fri, 21 Mar 2014 09:20:11 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-315) Avoid running out of threads
 when connecting to the DC from a slave to pull down missing data
In-Reply-To: <JIRA.12488204.1364406845000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12488204.1364406845000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12488204.1364406845000.32115.1395408011166@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-315?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12954967#comment-12954967 ] 

Brian Stansberry commented on WFLY-315:
---------------------------------------

My work on mgmt op cancellation has led into a general look at thread management issues (to allow interruption of request handling without screwing up connections, we have to isolate IO tasks from the cancellable thread, so more async tasks, more thread complication.)

I'm thinking we should go for a single thread pool (the host or server's main pool) with an unlimited size. We can use other techniques to throttle certain kinds of requests. For example, stick tasks in a queue and then only let a certain number of the general purpose threads concurrently process the queue.

Tasks we might throttle:

1) End user requests. I believe this case was the original reason for a limited pool anyway. Note that I don't think there's any limit on the number of HTTP/REST requests, so this limit is pretty incomplete anyway.

2) Slave registration requests. These will block anyway if executed concurrently, so why have > 1 thread doing them? I'm referring to the initial request -- once the message exchange starts no reason to throttle the other requests, as the initial request throttle will naturally do this.

3) Master->Slave and Slave->server requests. Why throttle these? It can just lead to deadlock issues. If we're throttling end user requests we shouldn't need to worry about how many requests a controlling process is sending to its controlled process.

4) Post-registration slave->master requests. Same as 3 above.

The other aspect of this we should look into is why these "slave pulls down missing data" requests are transactional. It's not obvious to me why they can't return and release the lock immediately. But I'm probably missing something.
                
> Avoid running out of threads when connecting to the DC from a slave to pull down missing data
> ---------------------------------------------------------------------------------------------
>
>                 Key: WFLY-315
>                 URL: https://issues.jboss.org/browse/WFLY-315
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>            Reporter: Kabir Khan
>            Assignee: Emanuel Muckenhuber
>            Priority: Blocker
>             Fix For: 9.0.0.CR1
>
>
> For WFLY-259 when a slave connects to the DC to pull down missing data, it does this by either getting a lock for the DC, or by joining the permit of the existing DC lock if the request to update a slave's server-config was executed as part of a composite obtaining a lock on the DC.
> The way it works at present there is a thread per slave which is blocked until the transaction completes. The DC threads are a finite resource, so a large number of slaves trying to pull down dats will cause deadlock

--
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

From issues at jboss.org  Fri Mar 21 09:28:10 2014
From: issues at jboss.org (David Lloyd (JIRA))
Date: Fri, 21 Mar 2014 09:28:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-315) Avoid running out of threads
 when connecting to the DC from a slave to pull down missing data
In-Reply-To: <JIRA.12488204.1364406845000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12488204.1364406845000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12488204.1364406845000.32135.1395408490712@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-315?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12954974#comment-12954974 ] 

David Lloyd commented on WFLY-315:
----------------------------------

You mean, a thread pool with unlimited queue size?  We do need to establish a finite size on the thread pool itself to avoid memory issues, as each thread has a potentially large stack and there are often OS limits on process/thread count.  If you set up a standard ThreadPoolExecutor with a very large core size, it will spawn as many threads as your maximum concurrently executing tasks, which could be very high if you have lots of blocking tasks.
                
> Avoid running out of threads when connecting to the DC from a slave to pull down missing data
> ---------------------------------------------------------------------------------------------
>
>                 Key: WFLY-315
>                 URL: https://issues.jboss.org/browse/WFLY-315
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>            Reporter: Kabir Khan
>            Assignee: Emanuel Muckenhuber
>            Priority: Blocker
>             Fix For: 9.0.0.CR1
>
>
> For WFLY-259 when a slave connects to the DC to pull down missing data, it does this by either getting a lock for the DC, or by joining the permit of the existing DC lock if the request to update a slave's server-config was executed as part of a composite obtaining a lock on the DC.
> The way it works at present there is a thread per slave which is blocked until the transaction completes. The DC threads are a finite resource, so a large number of slaves trying to pull down dats will cause deadlock

--
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

From issues at jboss.org  Fri Mar 21 09:32:12 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 21 Mar 2014 09:32:12 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2644) Java heap space exceeded
 looping connect/disconnect cycle
In-Reply-To: <JIRA.12527822.1386863108000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12527822.1386863108000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12527822.1386863108000.32161.1395408732062@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2644?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12954977#comment-12954977 ] 

RH Bugzilla Integration commented on WFLY-2644:
-----------------------------------------------

Radim Hatlapatka <rhatlapa at redhat.com> changed the Status of [bug 1037574|https://bugzilla.redhat.com/show_bug.cgi?id=1037574] from ASSIGNED to VERIFIED
                
> Java heap space exceeded looping connect/disconnect cycle
> ---------------------------------------------------------
>
>                 Key: WFLY-2644
>                 URL: https://issues.jboss.org/browse/WFLY-2644
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: CLI
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Alexey Loubyansky
>            Assignee: Alexey Loubyansky
>             Fix For: 8.0.0.Final
>
>
> CLIModelControllerClient implementation is not cleaning up something related to connection handling which leads to OOME repeating a cycle of ensureConnected(...) and close(). On my laptop it happens after around 1400 iterations.

--
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

From issues at jboss.org  Fri Mar 21 09:34:11 2014
From: issues at jboss.org (Emanuel Muckenhuber (JIRA))
Date: Fri, 21 Mar 2014 09:34:11 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-315) Avoid running out of threads
 when connecting to the DC from a slave to pull down missing data
In-Reply-To: <JIRA.12488204.1364406845000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12488204.1364406845000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12488204.1364406845000.32173.1395408851274@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-315?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12954980#comment-12954980 ] 

Emanuel Muckenhuber commented on WFLY-315:
------------------------------------------

Yeah, i mean most of this relies on unbounded thread pools, so that operations don't deadlock. We should really get rid of those at one point though.

We do throttle (1) mainly because when i was running a lot of concurrent requests with an not limited thread pool the server pretty much ran out of memory pretty quickly (thanks to ModelNode.clone()). (2) are executed by single thread, because it's kinda pointless have multiple registration just use threads, when they cannot be executed concurrently. (3) we have a limited pool on the DC, however proxied request cannot be limited, because they are all blocking (awaiting the tx.complete from the DC). Also inbound request for fetching data and files are unlimited to avoid deadlocks. This all is a huge mess needs to be cleaned up at one point, however would require some fundamental changes.
                
> Avoid running out of threads when connecting to the DC from a slave to pull down missing data
> ---------------------------------------------------------------------------------------------
>
>                 Key: WFLY-315
>                 URL: https://issues.jboss.org/browse/WFLY-315
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>            Reporter: Kabir Khan
>            Assignee: Emanuel Muckenhuber
>            Priority: Blocker
>             Fix For: 9.0.0.CR1
>
>
> For WFLY-259 when a slave connects to the DC to pull down missing data, it does this by either getting a lock for the DC, or by joining the permit of the existing DC lock if the request to update a slave's server-config was executed as part of a composite obtaining a lock on the DC.
> The way it works at present there is a thread per slave which is blocked until the transaction completes. The DC threads are a finite resource, so a large number of slaves trying to pull down dats will cause deadlock

--
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

From issues at jboss.org  Fri Mar 21 09:42:11 2014
From: issues at jboss.org (Emanuel Muckenhuber (JIRA))
Date: Fri, 21 Mar 2014 09:42:11 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-315) Avoid running out of threads
 when connecting to the DC from a slave to pull down missing data
In-Reply-To: <JIRA.12488204.1364406845000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12488204.1364406845000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12488204.1364406845000.32221.1395409331201@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-315?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12954985#comment-12954985 ] 

Emanuel Muckenhuber commented on WFLY-315:
------------------------------------------

But yeah all blocking/cancellable task have to be executed outside of the IO (remoting) threads. This should be the case already, if you spot something like that it's definitely a bug and has to be fixed. 
                
> Avoid running out of threads when connecting to the DC from a slave to pull down missing data
> ---------------------------------------------------------------------------------------------
>
>                 Key: WFLY-315
>                 URL: https://issues.jboss.org/browse/WFLY-315
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>            Reporter: Kabir Khan
>            Assignee: Emanuel Muckenhuber
>            Priority: Blocker
>             Fix For: 9.0.0.CR1
>
>
> For WFLY-259 when a slave connects to the DC to pull down missing data, it does this by either getting a lock for the DC, or by joining the permit of the existing DC lock if the request to update a slave's server-config was executed as part of a composite obtaining a lock on the DC.
> The way it works at present there is a thread per slave which is blocked until the transaction completes. The DC threads are a finite resource, so a large number of slaves trying to pull down dats will cause deadlock

--
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

From issues at jboss.org  Fri Mar 21 09:42:11 2014
From: issues at jboss.org (Emanuel Muckenhuber (JIRA))
Date: Fri, 21 Mar 2014 09:42:11 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-315) Avoid running out of threads
 when connecting to the DC from a slave to pull down missing data
In-Reply-To: <JIRA.12488204.1364406845000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12488204.1364406845000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12488204.1364406845000.32226.1395409331408@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-315?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12954985#comment-12954985 ] 

Emanuel Muckenhuber edited comment on WFLY-315 at 3/21/14 9:40 AM:
-------------------------------------------------------------------

But yeah all blocking/cancellable tasks have to be executed outside of the IO (remoting) threads. This should be the case already, if you spot something like that it's definitely a bug and has to be fixed. 
                
      was (Author: emuckenhuber):
    But yeah all blocking/cancellable task have to be executed outside of the IO (remoting) threads. This should be the case already, if you spot something like that it's definitely a bug and has to be fixed. 
                  
> Avoid running out of threads when connecting to the DC from a slave to pull down missing data
> ---------------------------------------------------------------------------------------------
>
>                 Key: WFLY-315
>                 URL: https://issues.jboss.org/browse/WFLY-315
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>            Reporter: Kabir Khan
>            Assignee: Emanuel Muckenhuber
>            Priority: Blocker
>             Fix For: 9.0.0.CR1
>
>
> For WFLY-259 when a slave connects to the DC to pull down missing data, it does this by either getting a lock for the DC, or by joining the permit of the existing DC lock if the request to update a slave's server-config was executed as part of a composite obtaining a lock on the DC.
> The way it works at present there is a thread per slave which is blocked until the transaction completes. The DC threads are a finite resource, so a large number of slaves trying to pull down dats will cause deadlock

--
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

From issues at jboss.org  Fri Mar 21 09:54:10 2014
From: issues at jboss.org (David Lloyd (JIRA))
Date: Fri, 21 Mar 2014 09:54:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-315) Avoid running out of threads
 when connecting to the DC from a slave to pull down missing data
In-Reply-To: <JIRA.12488204.1364406845000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12488204.1364406845000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12488204.1364406845000.32292.1395410050938@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-315?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12954998#comment-12954998 ] 

David Lloyd commented on WFLY-315:
----------------------------------

Ideally, dependency-oriented tasks would be asynchronous/callback-based. I have a simple DependencyTask class in jboss-threads that might be interesting for certain trivial cases (probably not for this case though).  The idea is to avoid submitting tasks that you know will block, instead favoring tasks that will proceed and that will resolve future tasks' blocks before they are executed.
                
> Avoid running out of threads when connecting to the DC from a slave to pull down missing data
> ---------------------------------------------------------------------------------------------
>
>                 Key: WFLY-315
>                 URL: https://issues.jboss.org/browse/WFLY-315
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>            Reporter: Kabir Khan
>            Assignee: Emanuel Muckenhuber
>            Priority: Blocker
>             Fix For: 9.0.0.CR1
>
>
> For WFLY-259 when a slave connects to the DC to pull down missing data, it does this by either getting a lock for the DC, or by joining the permit of the existing DC lock if the request to update a slave's server-config was executed as part of a composite obtaining a lock on the DC.
> The way it works at present there is a thread per slave which is blocked until the transaction completes. The DC threads are a finite resource, so a large number of slaves trying to pull down dats will cause deadlock

--
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

From issues at jboss.org  Fri Mar 21 09:56:11 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 21 Mar 2014 09:56:11 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2214) Allow additional environment
 properties to be set for outbound LDAP connections used by security realms.
In-Reply-To: <JIRA.12502155.1380834418000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502155.1380834418000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502155.1380834418000.32298.1395410171443@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2214?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12954999#comment-12954999 ] 

RH Bugzilla Integration commented on WFLY-2214:
-----------------------------------------------

Darran Lofthouse <darran.lofthouse at redhat.com> changed the Status of [bug 1015303|https://bugzilla.redhat.com/show_bug.cgi?id=1015303] from ASSIGNED to POST
                
> Allow additional environment properties to be set for outbound LDAP connections used by security realms.
> --------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2214
>                 URL: https://issues.jboss.org/browse/WFLY-2214
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Derek Horton
>            Assignee: Darran Lofthouse
>             Fix For: 8.0.0.CR1
>
>
> LDAP security realm needs to have configurable timeouts.
> The default LDAP connection timeout appears to be 2 minutes.  If the ldap server is down, it could take 2 minutes for the connection to timeout.  This can cause unneeded delay if you have configured multiple ldap servers for  failover / redundancy.
> The following hack appears to work:
> +++ domain-management/src/main/java/org/jboss/as/domain/management/connections/ldap/LdapConnectionManagerService.java
> @@ -132,6 +132,7 @@ public class LdapConnectionManagerService implements Service<LdapConnectionManag
>          result.put(Context.INITIAL_CONTEXT_FACTORY,initialContextFactory);
>          String url = config.require(URL).asString();
>          result.put(Context.PROVIDER_URL,url);
> +        result.put("com.sun.jndi.ldap.connect.timeout", "500");
>          return result;
>      }

--
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

From issues at jboss.org  Fri Mar 21 10:00:12 2014
From: issues at jboss.org (Jesper Pedersen (JIRA))
Date: Fri, 21 Mar 2014 10:00:12 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (SECURITY-810) Lifetime configuration
 option for Kerberos LoginModule
In-Reply-To: <JIRA.12535718.1395410376007@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12535718.1395410376007@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12535718.1395410376007.32335.1395410412148@jira02.app.mwc.hst.phx2.redhat.com>

Jesper Pedersen created SECURITY-810:
----------------------------------------

             Summary: Lifetime configuration option for Kerberos LoginModule
                 Key: SECURITY-810
                 URL: https://issues.jboss.org/browse/SECURITY-810
             Project: PicketBox 
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
            Reporter: Jesper Pedersen
            Assignee: Darran Lofthouse


Add a configuration option to the Kerberos LoginModule that allows to control the lifetime

--
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

From issues at jboss.org  Fri Mar 21 10:04:11 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 21 Mar 2014 10:04:11 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3077) Convert command line IPv6 URL
 literals to address literals
In-Reply-To: <JIRA.12534346.1394155395000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534346.1394155395000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534346.1394155395000.32353.1395410651708@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-3077?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12955005#comment-12955005 ] 

RH Bugzilla Integration commented on WFLY-3077:
-----------------------------------------------

Rostislav Svoboda <rsvoboda at redhat.com> changed the Status of [bug 1064771|https://bugzilla.redhat.com/show_bug.cgi?id=1064771] from ASSIGNED to VERIFIED
                
> Convert command line IPv6 URL literals to address literals
> ----------------------------------------------------------
>
>                 Key: WFLY-3077
>                 URL: https://issues.jboss.org/browse/WFLY-3077
>             Project: WildFly
>          Issue Type: Enhancement
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 8.0.0.Final
>            Reporter: Brian Stansberry
>            Assignee: Brian Stansberry
>            Priority: Minor
>             Fix For: 8.0.1.Final
>
>
> When people provide URL-style values like [::1] for command line args like -b, convert them to address values (i.e. strip the enclosing brackets.)

--
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

From issues at jboss.org  Fri Mar 21 10:04:12 2014
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Fri, 21 Mar 2014 10:04:12 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (SECURITY-810) Lifetime configuration
 option for Kerberos LoginModule
In-Reply-To: <JIRA.12535718.1395410376000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12535718.1395410376000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12535718.1395410376000.32359.1395410652094@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/SECURITY-810?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated SECURITY-810:
--------------------------------------

    Component/s: Negotiation

    
> Lifetime configuration option for Kerberos LoginModule
> ------------------------------------------------------
>
>                 Key: SECURITY-810
>                 URL: https://issues.jboss.org/browse/SECURITY-810
>             Project: PicketBox 
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Negotiation
>            Reporter: Jesper Pedersen
>            Assignee: Darran Lofthouse
>
> Add a configuration option to the Kerberos LoginModule that allows to control the lifetime

--
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

From issues at jboss.org  Fri Mar 21 10:04:12 2014
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Fri, 21 Mar 2014 10:04:12 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (SECURITY-810) Lifetime configuration
 option for Kerberos LoginModule
In-Reply-To: <JIRA.12535718.1395410376000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12535718.1395410376000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12535718.1395410376000.32363.1395410652390@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/SECURITY-810?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated SECURITY-810:
--------------------------------------

    Fix Version/s: Negotiation_2_3_0_CR1

    
> Lifetime configuration option for Kerberos LoginModule
> ------------------------------------------------------
>
>                 Key: SECURITY-810
>                 URL: https://issues.jboss.org/browse/SECURITY-810
>             Project: PicketBox 
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Negotiation
>            Reporter: Jesper Pedersen
>            Assignee: Darran Lofthouse
>             Fix For: Negotiation_2_3_0_CR1
>
>
> Add a configuration option to the Kerberos LoginModule that allows to control the lifetime

--
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

From issues at jboss.org  Fri Mar 21 10:38:11 2014
From: issues at jboss.org (Scott Marlow (JIRA))
Date: Fri, 21 Mar 2014 10:38:11 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3150) component upgrade to
 Hibernate next ORM 4.3.x release
In-Reply-To: <JIRA.12535729.1395412681668@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12535729.1395412681668@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12535729.1395412681668.32553.1395412691291@jira02.app.mwc.hst.phx2.redhat.com>

Scott Marlow created WFLY-3150:
----------------------------------

             Summary: component upgrade to Hibernate next ORM 4.3.x release 
                 Key: WFLY-3150
                 URL: https://issues.jboss.org/browse/WFLY-3150
             Project: WildFly
          Issue Type: Task
      Security Level: Public (Everyone can see)
          Components: JPA / Hibernate
    Affects Versions: 8.0.0.Final
            Reporter: Scott Marlow
            Assignee: Scott Marlow
             Fix For: 8.0.1.Final


Need the https://hibernate.atlassian.net/browse/HHH-9073 change.

--
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

From issues at jboss.org  Fri Mar 21 10:44:10 2014
From: issues at jboss.org (Farah Juma (JIRA))
Date: Fri, 21 Mar 2014 10:44:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2713) ViewExpiredException in
 Chrome on WildFly 8.0.0.CR1
In-Reply-To: <JIRA.12528672.1389025086000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528672.1389025086000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528672.1389025086000.32577.1395413050849@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2713?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12955022#comment-12955022 ] 

Farah Juma commented on WFLY-2713:
----------------------------------

[~ppitonak] Are you still able to reproduce this? I just tried with the latest WildFly 8.0.1.Final-SNAPSHOT version (i.e., rev 84638b1a4f4705875dfaaf72cd6decd9342394fc) and with Chrome 33.0.1750.152 but wasn't able to reproduce this issue.  
                
> ViewExpiredException in Chrome on WildFly 8.0.0.CR1
> ---------------------------------------------------
>
>                 Key: WFLY-2713
>                 URL: https://issues.jboss.org/browse/WFLY-2713
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JSF
>    Affects Versions: 8.0.0.CR1
>         Environment: WildFly 8.0.0.CR1
> Chrome 31.0.1650.63 @ Fedora 20 x86_64
>            Reporter: Pavol Pitonak
>            Assignee: Farah Juma
>         Attachments: reproducer.zip
>
>
> # unzip attached reproducer
> # mvn clean package
> # deploy reproducer.war to WildFly 
> # open http://localhost:8080/reproducer/
> # type something to the input
> result:
> * in Chrome, a popup with error is displayed
> * server console contains stack trace:
> {code}
> 17:10:54,852 SEVERE [javax.enterprise.resource.webcontainer.jsf.context] (default task-7) javax.faces.application.ViewExpiredException: viewId:/index.xhtml - View /index.xhtml could not be restored.
> {code}
> * works fine in Firefox 26
> * works fine in WildFly 8.0.0.Beta1

--
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

From issues at jboss.org  Fri Mar 21 11:04:11 2014
From: issues at jboss.org (Bela Ban (JIRA))
Date: Fri, 21 Mar 2014 11:04:11 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1750) RELAY2 : Address formats are
	not relayed.
In-Reply-To: <JIRA.12526440.1385646708000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12526440.1385646708000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12526440.1385646708000.32680.1395414251748@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JGRP-1750?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban resolved JGRP-1750.
----------------------------

    Resolution: Done


[~ammous] Let me know if this works now, and reopen if it doesn't.
                
> RELAY2 : Address formats are not relayed.
> -----------------------------------------
>
>                 Key: JGRP-1750
>                 URL: https://issues.jboss.org/browse/JGRP-1750
>             Project: JGroups
>          Issue Type: Feature Request
>    Affects Versions: 3.4.1
>            Reporter: Karim AMMOUS
>            Assignee: Bela Ban
>             Fix For: 3.5
>
>
> When defining a relay channel, we haven't the ability to set an AddressGenrator. Indeed, the Relayer uses its own AddressGenerator providing addresses of type SiteUUID. 
> This is particularly embarrassing in the following case: when we define a customized address format (like CanBeSiteMasterTopology or TopologyUUID) for members of two Sites A and B, address format is lost by crossing relay. Address type of messages sent by A to B are seen as SiteUUID at B side.
> Suggestions:
> - Making address format "relayable" ?
> - Using the same (or an extended format) AddressGenerator of site Channel

--
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

From issues at jboss.org  Fri Mar 21 11:20:10 2014
From: issues at jboss.org (Bela Ban (JIRA))
Date: Fri, 21 Mar 2014 11:20:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1775)
 Relay2Test.testQueueingAndForwarding fails randomly
In-Reply-To: <JIRA.12529835.1390213392000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529835.1390213392000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529835.1390213392000.32734.1395415210604@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JGRP-1775?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban resolved JGRP-1775.
----------------------------

    Resolution: Won't Fix


I'm afraid I won't fix this in 3.5 as that test doesn't exist anymore.
                
> Relay2Test.testQueueingAndForwarding fails randomly
> ---------------------------------------------------
>
>                 Key: JGRP-1775
>                 URL: https://issues.jboss.org/browse/JGRP-1775
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.3.5
>            Reporter: Risto Oikarinen
>            Assignee: Bela Ban
>            Priority: Minor
>             Fix For: 3.5
>
>         Attachments: relay2test_fails_randomly_log.txt
>
>
> Relay2Test.testQueueingAndForwarding seems to be failing randomly. I was able to reproduce this with the following test:
> {code:java}
> public void testQueueInLoop() throws Exception {
>     for ( int i = 0; i < 1000; ++i) {
>         testQueueingAndForwarding();
>         destroy();
>     }
> }
> {code}

--
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

From issues at jboss.org  Fri Mar 21 11:22:10 2014
From: issues at jboss.org (Bela Ban (JIRA))
Date: Fri, 21 Mar 2014 11:22:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1759)
 BecomeServerTest.testSendingOfMsgsOnUnconnectedChannel deadlocks
In-Reply-To: <JIRA.12528270.1387483080000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528270.1387483080000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528270.1387483080000.32738.1395415330662@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JGRP-1759?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12955044#comment-12955044 ] 

Bela Ban commented on JGRP-1759:
--------------------------------

After running another 20 test suite runs, this test *never* failed. I did submit the PR to Byteman though and will use rendezvous with a timeout once this is folded into a new Byteman release. Pushing this to 4.0.
                
> BecomeServerTest.testSendingOfMsgsOnUnconnectedChannel deadlocks
> ----------------------------------------------------------------
>
>                 Key: JGRP-1759
>                 URL: https://issues.jboss.org/browse/JGRP-1759
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.5
>         Environment: Windows 2008, x86_64
>            Reporter: Richard Achmatowicz
>            Assignee: Bela Ban
>            Priority: Minor
>             Fix For: 3.5
>
>
> Running the Byteman tests in the QA lab, this test deadlocks in a repeatable fashion and causes the testsuite to hang.
> The test makes use of the Byteman rendezvous built-in function to suspend (and reorder) thread execution. It appears that with threads re-ordered, certain parts of JGroups block in such a way that no progress is made and the test deadlocks.
> .

--
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

From issues at jboss.org  Fri Mar 21 11:22:10 2014
From: issues at jboss.org (Bela Ban (JIRA))
Date: Fri, 21 Mar 2014 11:22:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1759)
 BecomeServerTest.testSendingOfMsgsOnUnconnectedChannel deadlocks
In-Reply-To: <JIRA.12528270.1387483080000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528270.1387483080000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528270.1387483080000.32742.1395415330835@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JGRP-1759?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban updated JGRP-1759:
---------------------------

    Fix Version/s: 4.0
                       (was: 3.5)

    
> BecomeServerTest.testSendingOfMsgsOnUnconnectedChannel deadlocks
> ----------------------------------------------------------------
>
>                 Key: JGRP-1759
>                 URL: https://issues.jboss.org/browse/JGRP-1759
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.5
>         Environment: Windows 2008, x86_64
>            Reporter: Richard Achmatowicz
>            Assignee: Bela Ban
>            Priority: Minor
>             Fix For: 4.0
>
>
> Running the Byteman tests in the QA lab, this test deadlocks in a repeatable fashion and causes the testsuite to hang.
> The test makes use of the Byteman rendezvous built-in function to suspend (and reorder) thread execution. It appears that with threads re-ordered, certain parts of JGroups block in such a way that no progress is made and the test deadlocks.
> .

--
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

From issues at jboss.org  Fri Mar 21 11:24:10 2014
From: issues at jboss.org (Pavol Pitonak (JIRA))
Date: Fri, 21 Mar 2014 11:24:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2713) ViewExpiredException in
 Chrome on WildFly 8.0.0.CR1
In-Reply-To: <JIRA.12528672.1389025086000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528672.1389025086000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528672.1389025086000.32748.1395415450893@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2713?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12955045#comment-12955045 ] 

Pavol Pitonak commented on WFLY-2713:
-------------------------------------

No, I cannot reproduce anymore with WildFly 8.0.0.Final.
                
> ViewExpiredException in Chrome on WildFly 8.0.0.CR1
> ---------------------------------------------------
>
>                 Key: WFLY-2713
>                 URL: https://issues.jboss.org/browse/WFLY-2713
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JSF
>    Affects Versions: 8.0.0.CR1
>         Environment: WildFly 8.0.0.CR1
> Chrome 31.0.1650.63 @ Fedora 20 x86_64
>            Reporter: Pavol Pitonak
>            Assignee: Farah Juma
>         Attachments: reproducer.zip
>
>
> # unzip attached reproducer
> # mvn clean package
> # deploy reproducer.war to WildFly 
> # open http://localhost:8080/reproducer/
> # type something to the input
> result:
> * in Chrome, a popup with error is displayed
> * server console contains stack trace:
> {code}
> 17:10:54,852 SEVERE [javax.enterprise.resource.webcontainer.jsf.context] (default task-7) javax.faces.application.ViewExpiredException: viewId:/index.xhtml - View /index.xhtml could not be restored.
> {code}
> * works fine in Firefox 26
> * works fine in WildFly 8.0.0.Beta1

--
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

From issues at jboss.org  Fri Mar 21 11:30:11 2014
From: issues at jboss.org (Farah Juma (JIRA))
Date: Fri, 21 Mar 2014 11:30:11 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2713) ViewExpiredException in
 Chrome on WildFly 8.0.0.CR1
In-Reply-To: <JIRA.12528672.1389025086000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528672.1389025086000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528672.1389025086000.32759.1395415811093@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2713?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Farah Juma closed WFLY-2713.
----------------------------

    Resolution: Out of Date

    
> ViewExpiredException in Chrome on WildFly 8.0.0.CR1
> ---------------------------------------------------
>
>                 Key: WFLY-2713
>                 URL: https://issues.jboss.org/browse/WFLY-2713
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JSF
>    Affects Versions: 8.0.0.CR1
>         Environment: WildFly 8.0.0.CR1
> Chrome 31.0.1650.63 @ Fedora 20 x86_64
>            Reporter: Pavol Pitonak
>            Assignee: Farah Juma
>         Attachments: reproducer.zip
>
>
> # unzip attached reproducer
> # mvn clean package
> # deploy reproducer.war to WildFly 
> # open http://localhost:8080/reproducer/
> # type something to the input
> result:
> * in Chrome, a popup with error is displayed
> * server console contains stack trace:
> {code}
> 17:10:54,852 SEVERE [javax.enterprise.resource.webcontainer.jsf.context] (default task-7) javax.faces.application.ViewExpiredException: viewId:/index.xhtml - View /index.xhtml could not be restored.
> {code}
> * works fine in Firefox 26
> * works fine in WildFly 8.0.0.Beta1

--
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

From issues at jboss.org  Fri Mar 21 13:40:10 2014
From: issues at jboss.org (Maxim Frolov (JIRA))
Date: Fri, 21 Mar 2014 13:40:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3147)
 spec-descriptor-property-replacement causes NPE while parsing exclude
 element in beans.xml
In-Reply-To: <JIRA.12535673.1395399376000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12535673.1395399376000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12535673.1395399376000.33043.1395423610535@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-3147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12955089#comment-12955089 ] 

Maxim Frolov commented on WFLY-3147:
------------------------------------

Bug in _weld-core-impl_-2.1.2.Final?
The [BeansXmlHandler|https://github.com/weld/core/blob/2.1.2.Final/impl/src/main/java/org/jboss/weld/xml/BeansXmlHandler.java] always calls interpolate(), even if the argument is _null_.
At runtime Wildfly calls interpolate() method which is overridden by [PropertyReplacingBeansXmlHandler|https://github.com/wildfly/wildfly/blob/8.0.0.Final/weld/src/main/java/org/jboss/as/weld/deployment/PropertyReplacingBeansXmlHandler.java], which delegates processing to [DefaultPropertyReplacer|https://github.com/jboss/metadata/blob/8.0.0.Final/common/src/main/java/org/jboss/metadata/property/DefaultPropertyReplacer.java]. Nowehere the null-check is performed.

I think, that the BeansXmlHandler should not call interpolate() method at all if the value of attribute or XML element is absent.
                
> spec-descriptor-property-replacement causes NPE while parsing exclude element in beans.xml
> ------------------------------------------------------------------------------------------
>
>                 Key: WFLY-3147
>                 URL: https://issues.jboss.org/browse/WFLY-3147
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: CDI / Weld, EE
>    Affects Versions: 8.0.0.Final
>            Reporter: Maxim Frolov
>            Assignee: Stuart Douglas
>
> A CDI Bean Archive with a _beans.xml_ which contains {{beans/scan/*exclude*}} XML element causes {{NullPointerExcpetion}} during deployment on server with enabled {{<spec-descriptor-property-replacement>}} parameter in server's _standalone.xml_.
> The error stack trace is:
> {noformat}
> 2014-03-21 11:22:52,455 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-11) MSC000001: Failed to start service jboss.deployment.subunit."example.ear"."example-ejb.jar".PARSE: org.jboss.msc.service.StartException in service jboss.deployment.subunit."example.ear"."example-ejb.jar".PARSE: JBAS018733: Failed to process phase PARSE of subdeployment "example-ejb.jar" of deployment "example.ear"
> 	at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:166) [wildfly-server-8.0.0.Final.jar:8.0.0.Final]
> 	at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) [jboss-msc-1.2.0.Final.jar:1.2.0.Final]
> 	at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) [jboss-msc-1.2.0.Final.jar:1.2.0.Final]
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_45]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_45]
> 	at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_45]
> Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: java.lang.NullPointerException
> 	at org.jboss.as.weld.deployment.processors.BeansXmlProcessor.parseBeansXml(BeansXmlProcessor.java:140)
> 	at org.jboss.as.weld.deployment.processors.BeansXmlProcessor.deploy(BeansXmlProcessor.java:117)
> 	at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:159) [wildfly-server-8.0.0.Final.jar:8.0.0.Final]
> 	... 5 more
> Caused by: java.lang.NullPointerException
> 	at org.jboss.metadata.property.DefaultPropertyReplacer.replaceProperties(DefaultPropertyReplacer.java:52)
> 	at org.jboss.as.weld.deployment.PropertyReplacingBeansXmlHandler.interpolate(PropertyReplacingBeansXmlHandler.java:64)
> 	at org.jboss.weld.xml.BeansXmlHandler$4.processStartChildElement(BeansXmlHandler.java:229)
> 	at org.jboss.weld.xml.BeansXmlHandler.startElement(BeansXmlHandler.java:297)
> 	at org.apache.xerces.parsers.AbstractSAXParser.startElement(Unknown Source)
> 	at org.apache.xerces.parsers.AbstractXMLDocumentParser.emptyElement(Unknown Source)
> 	at org.apache.xerces.impl.xs.XMLSchemaValidator.emptyElement(Unknown Source)
> 	at org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanStartElement(Unknown Source)
> 	at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown Source)
> 	at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown Source)
> 	at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
> 	at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
> 	at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
> 	at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source)
> 	at org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser.parse(Unknown Source)
> 	at org.apache.xerces.jaxp.SAXParserImpl.parse(Unknown Source)
> 	at org.jboss.weld.xml.BeansXmlParser.parse(BeansXmlParser.java:93)
> 	at org.jboss.as.weld.deployment.processors.BeansXmlProcessor.parseBeansXml(BeansXmlProcessor.java:136)
> 	... 7 more
> {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

From issues at jboss.org  Fri Mar 21 13:48:11 2014
From: issues at jboss.org (Carlo de Wolf (JIRA))
Date: Fri, 21 Mar 2014 13:48:11 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBMETA-374) Properly process
 @DeclareRoles into security-role-ref
In-Reply-To: <JIRA.12535761.1395424056006@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12535761.1395424056006@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12535761.1395424056006.33072.1395424091739@jira02.app.mwc.hst.phx2.redhat.com>

Carlo de Wolf created JBMETA-374:
------------------------------------

             Summary: Properly process @DeclareRoles into security-role-ref
                 Key: JBMETA-374
                 URL: https://issues.jboss.org/browse/JBMETA-374
             Project: JBoss Metadata
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: ejb
    Affects Versions: 1.0.7.GA
            Reporter: Carlo de Wolf
            Assignee: Carlo de Wolf
             Fix For: 1.0.8.GA




--
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

From issues at jboss.org  Fri Mar 21 13:52:10 2014
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Fri, 21 Mar 2014 13:52:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (SECURITY-810) Lifetime configuration
 option for Kerberos LoginModule
In-Reply-To: <JIRA.12535718.1395410376000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12535718.1395410376000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12535718.1395410376000.33083.1395424330770@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/SECURITY-810?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse resolved SECURITY-810.
---------------------------------------

    Resolution: Done


Added the following module option to control the lifetime of the created GSSCredential: -

{code}
    /**
     * The lifetime in seconds of the {@link GSSCredential}, a negative value will set this to GSSCredential.INDEFINITE_LIFETIME.
     *
     * Defaults to GSSCredential.DEFAULT_LIFETIME
     */
    public static final String CREDENTIAL_LIFETIME = "credentialLifetime";
{code}
                
> Lifetime configuration option for Kerberos LoginModule
> ------------------------------------------------------
>
>                 Key: SECURITY-810
>                 URL: https://issues.jboss.org/browse/SECURITY-810
>             Project: PicketBox 
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Negotiation
>            Reporter: Jesper Pedersen
>            Assignee: Darran Lofthouse
>             Fix For: Negotiation_2_3_0_CR1
>
>
> Add a configuration option to the Kerberos LoginModule that allows to control the lifetime

--
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

From issues at jboss.org  Fri Mar 21 14:00:11 2014
From: issues at jboss.org (Maxim Frolov (JIRA))
Date: Fri, 21 Mar 2014 14:00:11 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3147)
 spec-descriptor-property-replacement causes NPE while parsing exclude
 element in beans.xml
In-Reply-To: <JIRA.12535673.1395399376000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12535673.1395399376000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12535673.1395399376000.33097.1395424811417@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-3147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12955100#comment-12955100 ] 

Maxim Frolov commented on WFLY-3147:
------------------------------------

I asked in WELD-DEV mailing list ([http://lists.jboss.org/pipermail/weld-dev/2014-March/003224.html]), whether this issue might be a bug in _weld-core-impl_.
                
> spec-descriptor-property-replacement causes NPE while parsing exclude element in beans.xml
> ------------------------------------------------------------------------------------------
>
>                 Key: WFLY-3147
>                 URL: https://issues.jboss.org/browse/WFLY-3147
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: CDI / Weld, EE
>    Affects Versions: 8.0.0.Final
>            Reporter: Maxim Frolov
>            Assignee: Stuart Douglas
>
> A CDI Bean Archive with a _beans.xml_ which contains {{beans/scan/*exclude*}} XML element causes {{NullPointerExcpetion}} during deployment on server with enabled {{<spec-descriptor-property-replacement>}} parameter in server's _standalone.xml_.
> The error stack trace is:
> {noformat}
> 2014-03-21 11:22:52,455 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-11) MSC000001: Failed to start service jboss.deployment.subunit."example.ear"."example-ejb.jar".PARSE: org.jboss.msc.service.StartException in service jboss.deployment.subunit."example.ear"."example-ejb.jar".PARSE: JBAS018733: Failed to process phase PARSE of subdeployment "example-ejb.jar" of deployment "example.ear"
> 	at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:166) [wildfly-server-8.0.0.Final.jar:8.0.0.Final]
> 	at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) [jboss-msc-1.2.0.Final.jar:1.2.0.Final]
> 	at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) [jboss-msc-1.2.0.Final.jar:1.2.0.Final]
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_45]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_45]
> 	at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_45]
> Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: java.lang.NullPointerException
> 	at org.jboss.as.weld.deployment.processors.BeansXmlProcessor.parseBeansXml(BeansXmlProcessor.java:140)
> 	at org.jboss.as.weld.deployment.processors.BeansXmlProcessor.deploy(BeansXmlProcessor.java:117)
> 	at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:159) [wildfly-server-8.0.0.Final.jar:8.0.0.Final]
> 	... 5 more
> Caused by: java.lang.NullPointerException
> 	at org.jboss.metadata.property.DefaultPropertyReplacer.replaceProperties(DefaultPropertyReplacer.java:52)
> 	at org.jboss.as.weld.deployment.PropertyReplacingBeansXmlHandler.interpolate(PropertyReplacingBeansXmlHandler.java:64)
> 	at org.jboss.weld.xml.BeansXmlHandler$4.processStartChildElement(BeansXmlHandler.java:229)
> 	at org.jboss.weld.xml.BeansXmlHandler.startElement(BeansXmlHandler.java:297)
> 	at org.apache.xerces.parsers.AbstractSAXParser.startElement(Unknown Source)
> 	at org.apache.xerces.parsers.AbstractXMLDocumentParser.emptyElement(Unknown Source)
> 	at org.apache.xerces.impl.xs.XMLSchemaValidator.emptyElement(Unknown Source)
> 	at org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanStartElement(Unknown Source)
> 	at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown Source)
> 	at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown Source)
> 	at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
> 	at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
> 	at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
> 	at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source)
> 	at org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser.parse(Unknown Source)
> 	at org.apache.xerces.jaxp.SAXParserImpl.parse(Unknown Source)
> 	at org.jboss.weld.xml.BeansXmlParser.parse(BeansXmlParser.java:93)
> 	at org.jboss.as.weld.deployment.processors.BeansXmlProcessor.parseBeansXml(BeansXmlProcessor.java:136)
> 	... 7 more
> {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

From issues at jboss.org  Fri Mar 21 14:12:10 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 21 Mar 2014 14:12:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2303) mod_cluster XSD is missing
 property and worker-timeout definitions
In-Reply-To: <JIRA.12503065.1381830758000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12503065.1381830758000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12503065.1381830758000.33122.1395425530637@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2303?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12955105#comment-12955105 ] 

RH Bugzilla Integration commented on WFLY-2303:
-----------------------------------------------

Kabir Khan <kkhan at redhat.com> changed the Status of [bug 1020142|https://bugzilla.redhat.com/show_bug.cgi?id=1020142] from POST to MODIFIED
                
> mod_cluster XSD is missing property and worker-timeout definitions
> ------------------------------------------------------------------
>
>                 Key: WFLY-2303
>                 URL: https://issues.jboss.org/browse/WFLY-2303
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Clustering
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Radoslav Husar
>            Assignee: Radoslav Husar
>             Fix For: 8.0.0.CR1
>
>
> * worker-timeout
> * property
> are missing.
> Also missing in 7.x

--
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

From issues at jboss.org  Fri Mar 21 15:00:11 2014
From: issues at jboss.org (Felix Coutinho (JIRA))
Date: Fri, 21 Mar 2014 15:00:11 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBASMP-65) Could not execute goal
 add-resource / wildfly-maven-plugin
In-Reply-To: <JIRA.12535765.1395428294839@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12535765.1395428294839@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12535765.1395428294839.33173.1395428411987@jira02.app.mwc.hst.phx2.redhat.com>

Felix Coutinho created JBASMP-65:
------------------------------------

             Summary: Could not execute goal add-resource / wildfly-maven-plugin
                 Key: JBASMP-65
                 URL: https://issues.jboss.org/browse/JBASMP-65
             Project: JBoss AS Maven Plugins
          Issue Type: Bug
          Components: deploy, wildfly
    Affects Versions: 7.5.Final
         Environment: Apache Maven 3.2.1 (ea8b2b07643dbb1b84b6d16e1f08391b666bc1e9; 2014-02-14T14:37:52-03:00)
Maven home: /home/felix/Downloads/apache-maven-3.2.1
Java version: 1.7.0_51, vendor: Oracle Corporation
Java home: /usr/lib/jvm/java-7-oracle/jre
Default locale: pt_BR, platform encoding: UTF-8
OS name: "linux", version: "3.8.0-35-generic", arch: "amd64", family: "unix"

            Reporter: Felix Coutinho
            Assignee: James Perkins
            Priority: Blocker


My pom: http://pastebin.com/BJ9zcXrg

felix at felix-DQ77PRO:~/workspaces/java/workspaceGastos/yyy-project$ mvn clean install -X

The debug output:
http://pastebin.com/cM8LbR62

The problem is here:
[ERROR] Failed to execute goal org.wildfly.plugins:wildfly-maven-plugin:1.0.1.Final:add-resource (add-datasource) on project logr: Could not execute goal add-resource. Reason: null: IllegalArgumentException -> [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.wildfly.plugins:wildfly-maven-plugin:1.0.1.Final:add-resource (add-datasource) on project logr: Could not execute goal add-resource. Reason: null
	at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:216)
	at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
	at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
	at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:108)
	at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:76)
	at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
	at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:116)
	at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:361)
	at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:155)
	at org.apache.maven.cli.MavenCli.execute(MavenCli.java:584)
	at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:213)
	at org.apache.maven.cli.MavenCli.main(MavenCli.java:157)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:606)
	at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
	at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
	at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
	at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
Caused by: org.apache.maven.plugin.MojoExecutionException: Could not execute goal add-resource. Reason: null
	at org.wildfly.plugin.deployment.resource.AddResourceMojo.execute(AddResourceMojo.java:118)
	at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:133)
	at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
	... 19 more
Caused by: java.lang.IllegalArgumentException
	at org.jboss.dmr.ModelValue.asList(ModelValue.java:132)
	at org.jboss.dmr.ModelNode.asList(ModelNode.java:1302)
	at org.wildfly.plugin.deployment.resource.AddResourceMojo.resourceExists(AddResourceMojo.java:258)
	at org.wildfly.plugin.deployment.resource.AddResourceMojo.addCompositeResource(AddResourceMojo.java:180)
	at org.wildfly.plugin.deployment.resource.AddResourceMojo.processResources(AddResourceMojo.java:148)
	at org.wildfly.plugin.deployment.resource.AddResourceMojo.execute(AddResourceMojo.java:112)
	... 21 more


Same problem:

http://stackoverflow.com/questions/22533311/wildfly-maven-plugin-not-deploy-xa-datasource

Other:
http://stackoverflow.com/questions/21020926/add-an-xa-datasource-fails-with-jboss-as-maven-plugin?rq=1

--
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

From issues at jboss.org  Fri Mar 21 15:02:10 2014
From: issues at jboss.org (Felix Coutinho (JIRA))
Date: Fri, 21 Mar 2014 15:02:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBASMP-66) Could not execute goal
 add-resource / wildfly-maven-plugin
In-Reply-To: <JIRA.12535766.1395428412438@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12535766.1395428412438@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12535766.1395428412438.33175.1395428530799@jira02.app.mwc.hst.phx2.redhat.com>

Felix Coutinho created JBASMP-66:
------------------------------------

             Summary: Could not execute goal add-resource / wildfly-maven-plugin
                 Key: JBASMP-66
                 URL: https://issues.jboss.org/browse/JBASMP-66
             Project: JBoss AS Maven Plugins
          Issue Type: Bug
          Components: deploy, wildfly
    Affects Versions: 7.5.Final
         Environment: Apache Maven 3.2.1 (ea8b2b07643dbb1b84b6d16e1f08391b666bc1e9; 2014-02-14T14:37:52-03:00)
Maven home: /home/felix/Downloads/apache-maven-3.2.1
Java version: 1.7.0_51, vendor: Oracle Corporation
Java home: /usr/lib/jvm/java-7-oracle/jre
Default locale: pt_BR, platform encoding: UTF-8
OS name: "linux", version: "3.8.0-35-generic", arch: "amd64", family: "unix"

            Reporter: Felix Coutinho
            Assignee: James Perkins
            Priority: Blocker


My pom: http://pastebin.com/BJ9zcXrg

felix at felix-DQ77PRO:~/workspaces/java/workspaceGastos/yyy-project$ mvn clean install -X

The debug output:
http://pastebin.com/cM8LbR62

The problem is here:
[ERROR] Failed to execute goal org.wildfly.plugins:wildfly-maven-plugin:1.0.1.Final:add-resource (add-datasource) on project logr: Could not execute goal add-resource. Reason: null: IllegalArgumentException -> [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.wildfly.plugins:wildfly-maven-plugin:1.0.1.Final:add-resource (add-datasource) on project logr: Could not execute goal add-resource. Reason: null
	at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:216)
	at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
	at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
	at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:108)
	at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:76)
	at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
	at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:116)
	at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:361)
	at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:155)
	at org.apache.maven.cli.MavenCli.execute(MavenCli.java:584)
	at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:213)
	at org.apache.maven.cli.MavenCli.main(MavenCli.java:157)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:606)
	at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
	at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
	at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
	at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
Caused by: org.apache.maven.plugin.MojoExecutionException: Could not execute goal add-resource. Reason: null
	at org.wildfly.plugin.deployment.resource.AddResourceMojo.execute(AddResourceMojo.java:118)
	at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:133)
	at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
	... 19 more
Caused by: java.lang.IllegalArgumentException
	at org.jboss.dmr.ModelValue.asList(ModelValue.java:132)
	at org.jboss.dmr.ModelNode.asList(ModelNode.java:1302)
	at org.wildfly.plugin.deployment.resource.AddResourceMojo.resourceExists(AddResourceMojo.java:258)
	at org.wildfly.plugin.deployment.resource.AddResourceMojo.addCompositeResource(AddResourceMojo.java:180)
	at org.wildfly.plugin.deployment.resource.AddResourceMojo.processResources(AddResourceMojo.java:148)
	at org.wildfly.plugin.deployment.resource.AddResourceMojo.execute(AddResourceMojo.java:112)
	... 21 more


Same problem:

http://stackoverflow.com/questions/22533311/wildfly-maven-plugin-not-deploy-xa-datasource

Other:
http://stackoverflow.com/questions/21020926/add-an-xa-datasource-fails-with-jboss-as-maven-plugin?rq=1

--
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

From issues at jboss.org  Fri Mar 21 15:04:10 2014
From: issues at jboss.org (Scott Marlow (JIRA))
Date: Fri, 21 Mar 2014 15:04:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3105) Container-managed EXTENDED
 persistence context is always joined with transaction even if
 UNSYNCHRONIZED
In-Reply-To: <JIRA.12534789.1394637157000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534789.1394637157000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534789.1394637157000.33180.1395428650764@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-3105?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12955112#comment-12955112 ] 

Scott Marlow commented on WFLY-3105:
------------------------------------

Change is merged in (should show up in the [https://community.jboss.org/thread/224262] nightly build).
                
> Container-managed EXTENDED persistence context is always joined with transaction even if UNSYNCHRONIZED
> -------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-3105
>                 URL: https://issues.jboss.org/browse/WFLY-3105
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JPA / Hibernate
>    Affects Versions: 8.0.0.Final
>            Reporter: Christian Bauer
>            Assignee: Scott Marlow
>             Fix For: 8.0.1.Final
>
>
> https://github.com/weld/wildfly/blob/master/testsuite/integration/basic/src/test/java/org/jboss/as/test/integration/jpa/transaction/UnsynchronizedSFSB.jav
> Change this test to {code}@PersistenceContext(type = EXTENDED, synchronization = UNSYNCHRONIZED){code} and it will break. 
> Looks like an extended PC is always joined to the transaction and flushed on commit, the unsynchronized mode is ignored. From what I can see this is not specified and indeed would make the whole new UNSYNCHRONIZED feature kind of pointless. It's primary use case is propagation of unflushed/unsynchronized extended PC from a SFSB to other beans while keeping transactions intact.

--
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

From issues at jboss.org  Fri Mar 21 15:06:10 2014
From: issues at jboss.org (Arun Gupta (JIRA))
Date: Fri, 21 Mar 2014 15:06:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3151) Possible regression
 standalone.sh due to a space in the startup path
In-Reply-To: <JIRA.12535767.1395428667092@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12535767.1395428667092@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12535767.1395428667092.33183.1395428770793@jira02.app.mwc.hst.phx2.redhat.com>

Arun Gupta created WFLY-3151:
--------------------------------

             Summary: Possible regression standalone.sh due to a space in the startup path
                 Key: WFLY-3151
                 URL: https://issues.jboss.org/browse/WFLY-3151
             Project: WildFly
          Issue Type: Bug
      Security Level: Public (Everyone can see)
            Reporter: Arun Gupta


Sent email to wildfly-dev:

-- cut here --
Java EE 7 CI job on WildFly trunk is failing:

https://arungupta.ci.cloudbees.com/job/Java%20EE%207%20Samples%20on%20WildFly-cb/155/console

Here is the error message:

Started 45 of 56 services (22 services are lazy, passive or on-demand)
 [0m+ wildfly-8.0.1.Final-SNAPSHOT/bin/jboss-cli.sh --connect
'--commands=/subsystem=messaging/hornetq-server=default:write-attribute(name=journal-type,value=NIO),:reload(admin-only=false)'
Error: Could not find or load main class EE
Process leaked file descriptors. See
http://wiki.jenkins-ci.org/display/JENKINS/Spawning+processes+from+build
for more information
Build step 'Execute shell' marked build as failure
-- cut here --

David reponded:

-- cut here --
Looks like a possible regression in standalone.sh due to there being a
space in the startup path.

As a workaround you could change your workspace name from "Java EE 7
Samples on WildFly-cb" to e.g. "java-ee-7-samples-on-wildfly-cb" or
similar (with no spaces).
-- cut here --

--
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

From issues at jboss.org  Fri Mar 21 15:06:10 2014
From: issues at jboss.org (Felix Coutinho (JIRA))
Date: Fri, 21 Mar 2014 15:06:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBASMP-65) Could not execute goal
 add-resource / wildfly-maven-plugin
In-Reply-To: <JIRA.12535765.1395428294000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12535765.1395428294000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12535765.1395428294000.33185.1395428770919@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBASMP-65?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Felix Coutinho closed JBASMP-65.
--------------------------------

    Resolution: Duplicate Issue

    
> Could not execute goal add-resource / wildfly-maven-plugin
> ----------------------------------------------------------
>
>                 Key: JBASMP-65
>                 URL: https://issues.jboss.org/browse/JBASMP-65
>             Project: JBoss AS Maven Plugins
>          Issue Type: Bug
>          Components: deploy, wildfly
>    Affects Versions: 7.5.Final
>         Environment: Apache Maven 3.2.1 (ea8b2b07643dbb1b84b6d16e1f08391b666bc1e9; 2014-02-14T14:37:52-03:00)
> Maven home: /home/felix/Downloads/apache-maven-3.2.1
> Java version: 1.7.0_51, vendor: Oracle Corporation
> Java home: /usr/lib/jvm/java-7-oracle/jre
> Default locale: pt_BR, platform encoding: UTF-8
> OS name: "linux", version: "3.8.0-35-generic", arch: "amd64", family: "unix"
>            Reporter: Felix Coutinho
>            Assignee: James Perkins
>            Priority: Blocker
>              Labels: maven, wildfly
>
> My pom: http://pastebin.com/BJ9zcXrg
> felix at felix-DQ77PRO:~/workspaces/java/workspaceGastos/yyy-project$ mvn clean install -X
> The debug output:
> http://pastebin.com/cM8LbR62
> The problem is here:
> [ERROR] Failed to execute goal org.wildfly.plugins:wildfly-maven-plugin:1.0.1.Final:add-resource (add-datasource) on project logr: Could not execute goal add-resource. Reason: null: IllegalArgumentException -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.wildfly.plugins:wildfly-maven-plugin:1.0.1.Final:add-resource (add-datasource) on project logr: Could not execute goal add-resource. Reason: null
> 	at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:216)
> 	at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
> 	at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
> 	at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:108)
> 	at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:76)
> 	at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
> 	at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:116)
> 	at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:361)
> 	at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:155)
> 	at org.apache.maven.cli.MavenCli.execute(MavenCli.java:584)
> 	at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:213)
> 	at org.apache.maven.cli.MavenCli.main(MavenCli.java:157)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:606)
> 	at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
> 	at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
> 	at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
> 	at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
> Caused by: org.apache.maven.plugin.MojoExecutionException: Could not execute goal add-resource. Reason: null
> 	at org.wildfly.plugin.deployment.resource.AddResourceMojo.execute(AddResourceMojo.java:118)
> 	at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:133)
> 	at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
> 	... 19 more
> Caused by: java.lang.IllegalArgumentException
> 	at org.jboss.dmr.ModelValue.asList(ModelValue.java:132)
> 	at org.jboss.dmr.ModelNode.asList(ModelNode.java:1302)
> 	at org.wildfly.plugin.deployment.resource.AddResourceMojo.resourceExists(AddResourceMojo.java:258)
> 	at org.wildfly.plugin.deployment.resource.AddResourceMojo.addCompositeResource(AddResourceMojo.java:180)
> 	at org.wildfly.plugin.deployment.resource.AddResourceMojo.processResources(AddResourceMojo.java:148)
> 	at org.wildfly.plugin.deployment.resource.AddResourceMojo.execute(AddResourceMojo.java:112)
> 	... 21 more
> Same problem:
> http://stackoverflow.com/questions/22533311/wildfly-maven-plugin-not-deploy-xa-datasource
> Other:
> http://stackoverflow.com/questions/21020926/add-an-xa-datasource-fails-with-jboss-as-maven-plugin?rq=1

--
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

From issues at jboss.org  Fri Mar 21 15:10:10 2014
From: issues at jboss.org (James Perkins (JIRA))
Date: Fri, 21 Mar 2014 15:10:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3151) Possible regression
 standalone.sh due to a space in the startup path
In-Reply-To: <JIRA.12535767.1395428667000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12535767.1395428667000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12535767.1395428667000.33194.1395429010569@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-3151?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

James Perkins reassigned WFLY-3151:
-----------------------------------

    Assignee: James Perkins

    
> Possible regression standalone.sh due to a space in the startup path
> --------------------------------------------------------------------
>
>                 Key: WFLY-3151
>                 URL: https://issues.jboss.org/browse/WFLY-3151
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Arun Gupta
>            Assignee: James Perkins
>
> Sent email to wildfly-dev:
> -- cut here --
> Java EE 7 CI job on WildFly trunk is failing:
> https://arungupta.ci.cloudbees.com/job/Java%20EE%207%20Samples%20on%20WildFly-cb/155/console
> Here is the error message:
> Started 45 of 56 services (22 services are lazy, passive or on-demand)
>  [0m+ wildfly-8.0.1.Final-SNAPSHOT/bin/jboss-cli.sh --connect
> '--commands=/subsystem=messaging/hornetq-server=default:write-attribute(name=journal-type,value=NIO),:reload(admin-only=false)'
> Error: Could not find or load main class EE
> Process leaked file descriptors. See
> http://wiki.jenkins-ci.org/display/JENKINS/Spawning+processes+from+build
> for more information
> Build step 'Execute shell' marked build as failure
> -- cut here --
> David reponded:
> -- cut here --
> Looks like a possible regression in standalone.sh due to there being a
> space in the startup path.
> As a workaround you could change your workspace name from "Java EE 7
> Samples on WildFly-cb" to e.g. "java-ee-7-samples-on-wildfly-cb" or
> similar (with no spaces).
> -- cut here --

--
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

From issues at jboss.org  Fri Mar 21 15:46:11 2014
From: issues at jboss.org (David Lloyd (JIRA))
Date: Fri, 21 Mar 2014 15:46:11 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3151) Failure to start jboss-cli.sh
 due to space in the startup path
In-Reply-To: <JIRA.12535767.1395428667000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12535767.1395428667000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12535767.1395428667000.33223.1395431171174@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-3151?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

David Lloyd updated WFLY-3151:
------------------------------

    Summary: Failure to start jboss-cli.sh due to space in the startup path  (was: Possible regression standalone.sh due to a space in the startup path)

    
> Failure to start jboss-cli.sh due to space in the startup path
> --------------------------------------------------------------
>
>                 Key: WFLY-3151
>                 URL: https://issues.jboss.org/browse/WFLY-3151
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Arun Gupta
>            Assignee: James Perkins
>
> Sent email to wildfly-dev:
> -- cut here --
> Java EE 7 CI job on WildFly trunk is failing:
> https://arungupta.ci.cloudbees.com/job/Java%20EE%207%20Samples%20on%20WildFly-cb/155/console
> Here is the error message:
> Started 45 of 56 services (22 services are lazy, passive or on-demand)
>  [0m+ wildfly-8.0.1.Final-SNAPSHOT/bin/jboss-cli.sh --connect
> '--commands=/subsystem=messaging/hornetq-server=default:write-attribute(name=journal-type,value=NIO),:reload(admin-only=false)'
> Error: Could not find or load main class EE
> Process leaked file descriptors. See
> http://wiki.jenkins-ci.org/display/JENKINS/Spawning+processes+from+build
> for more information
> Build step 'Execute shell' marked build as failure
> -- cut here --
> David reponded:
> -- cut here --
> Looks like a possible regression in standalone.sh due to there being a
> space in the startup path.
> As a workaround you could change your workspace name from "Java EE 7
> Samples on WildFly-cb" to e.g. "java-ee-7-samples-on-wildfly-cb" or
> similar (with no spaces).
> -- cut here --

--
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

From issues at jboss.org  Fri Mar 21 15:46:11 2014
From: issues at jboss.org (David Lloyd (JIRA))
Date: Fri, 21 Mar 2014 15:46:11 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3151) Failure to start jboss-cli.sh
 due to space in the startup path
In-Reply-To: <JIRA.12535767.1395428667000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12535767.1395428667000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12535767.1395428667000.33227.1395431171387@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-3151?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

David Lloyd updated WFLY-3151:
------------------------------

    Description: 
The CLI startup script needs to be modified to process arguments like standalone.sh and friends to, to be tolerant of spaces in the original arg list.

Original report:

Sent email to wildfly-dev:

{noformat}
Java EE 7 CI job on WildFly trunk is failing:

https://arungupta.ci.cloudbees.com/job/Java%20EE%207%20Samples%20on%20WildFly-cb/155/console

Here is the error message:

Started 45 of 56 services (22 services are lazy, passive or on-demand)
 [0m+ wildfly-8.0.1.Final-SNAPSHOT/bin/jboss-cli.sh --connect
'--commands=/subsystem=messaging/hornetq-server=default:write-attribute(name=journal-type,value=NIO),:reload(admin-only=false)'
Error: Could not find or load main class EE
Process leaked file descriptors. See
http://wiki.jenkins-ci.org/display/JENKINS/Spawning+processes+from+build
for more information
Build step 'Execute shell' marked build as failure
{noformat}

David responded:

{noformat}
Looks like a possible regression in standalone.sh due to there being a
space in the startup path.

As a workaround you could change your workspace name from "Java EE 7
Samples on WildFly-cb" to e.g. "java-ee-7-samples-on-wildfly-cb" or
similar (with no spaces).
{noformat}

  was:
Sent email to wildfly-dev:

-- cut here --
Java EE 7 CI job on WildFly trunk is failing:

https://arungupta.ci.cloudbees.com/job/Java%20EE%207%20Samples%20on%20WildFly-cb/155/console

Here is the error message:

Started 45 of 56 services (22 services are lazy, passive or on-demand)
 [0m+ wildfly-8.0.1.Final-SNAPSHOT/bin/jboss-cli.sh --connect
'--commands=/subsystem=messaging/hornetq-server=default:write-attribute(name=journal-type,value=NIO),:reload(admin-only=false)'
Error: Could not find or load main class EE
Process leaked file descriptors. See
http://wiki.jenkins-ci.org/display/JENKINS/Spawning+processes+from+build
for more information
Build step 'Execute shell' marked build as failure
-- cut here --

David reponded:

-- cut here --
Looks like a possible regression in standalone.sh due to there being a
space in the startup path.

As a workaround you could change your workspace name from "Java EE 7
Samples on WildFly-cb" to e.g. "java-ee-7-samples-on-wildfly-cb" or
similar (with no spaces).
-- cut here --


    
> Failure to start jboss-cli.sh due to space in the startup path
> --------------------------------------------------------------
>
>                 Key: WFLY-3151
>                 URL: https://issues.jboss.org/browse/WFLY-3151
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Arun Gupta
>            Assignee: James Perkins
>
> The CLI startup script needs to be modified to process arguments like standalone.sh and friends to, to be tolerant of spaces in the original arg list.
> Original report:
> Sent email to wildfly-dev:
> {noformat}
> Java EE 7 CI job on WildFly trunk is failing:
> https://arungupta.ci.cloudbees.com/job/Java%20EE%207%20Samples%20on%20WildFly-cb/155/console
> Here is the error message:
> Started 45 of 56 services (22 services are lazy, passive or on-demand)
>  [0m+ wildfly-8.0.1.Final-SNAPSHOT/bin/jboss-cli.sh --connect
> '--commands=/subsystem=messaging/hornetq-server=default:write-attribute(name=journal-type,value=NIO),:reload(admin-only=false)'
> Error: Could not find or load main class EE
> Process leaked file descriptors. See
> http://wiki.jenkins-ci.org/display/JENKINS/Spawning+processes+from+build
> for more information
> Build step 'Execute shell' marked build as failure
> {noformat}
> David responded:
> {noformat}
> Looks like a possible regression in standalone.sh due to there being a
> space in the startup path.
> As a workaround you could change your workspace name from "Java EE 7
> Samples on WildFly-cb" to e.g. "java-ee-7-samples-on-wildfly-cb" or
> similar (with no spaces).
> {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

From issues at jboss.org  Fri Mar 21 15:46:11 2014
From: issues at jboss.org (Chris LeCompte (JIRA))
Date: Fri, 21 Mar 2014 15:46:11 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1810) Illegal format string in
 trace message in NAKACK2 protocol
In-Reply-To: <JIRA.12535768.1395431156432@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12535768.1395431156432@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12535768.1395431156432.33228.1395431171438@jira02.app.mwc.hst.phx2.redhat.com>

Chris LeCompte created JGRP-1810:
------------------------------------

             Summary: Illegal format string in trace message in NAKACK2 protocol
                 Key: JGRP-1810
                 URL: https://issues.jboss.org/browse/JGRP-1810
             Project: JGroups
          Issue Type: Bug
    Affects Versions: 3.4.3
            Reporter: Chris LeCompte
            Assignee: Bela Ban
            Priority: Minor


The NAKACK2 protocol has an invalid format string in one of its trace logging outputs:

                    log.trace("%s: my_highest_rcvd (%) < stability_highest_rcvd (%): requesting retransmission of %s",
                              local_addr, my_hr, hr, member + "#" + hr);

This results in an error in the log:

ERROR - Illegal format string "%s: my_highest_rcvd (%) < stability_highest_rcvd (%): requesting retransmission of %s"

The % should be changed to %% to avoid the error.  The arguments are in fact printed alongside the message however anything with ERROR in the text makes QA nervous.

--
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

From issues at jboss.org  Fri Mar 21 15:50:10 2014
From: issues at jboss.org (Bela Ban (JIRA))
Date: Fri, 21 Mar 2014 15:50:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1810) Illegal format string in
 trace message in NAKACK2 protocol
In-Reply-To: <JIRA.12535768.1395431156000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12535768.1395431156000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12535768.1395431156000.33238.1395431410642@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JGRP-1810?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban updated JGRP-1810:
---------------------------

    Fix Version/s: 3.5

    
> Illegal format string in trace message in NAKACK2 protocol
> ----------------------------------------------------------
>
>                 Key: JGRP-1810
>                 URL: https://issues.jboss.org/browse/JGRP-1810
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.4.3
>            Reporter: Chris LeCompte
>            Assignee: Bela Ban
>            Priority: Minor
>             Fix For: 3.5
>
>
> The NAKACK2 protocol has an invalid format string in one of its trace logging outputs:
>                     log.trace("%s: my_highest_rcvd (%) < stability_highest_rcvd (%): requesting retransmission of %s",
>                               local_addr, my_hr, hr, member + "#" + hr);
> This results in an error in the log:
> ERROR - Illegal format string "%s: my_highest_rcvd (%) < stability_highest_rcvd (%): requesting retransmission of %s"
> The % should be changed to %% to avoid the error.  The arguments are in fact printed alongside the message however anything with ERROR in the text makes QA nervous.

--
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

From issues at jboss.org  Fri Mar 21 19:26:10 2014
From: issues at jboss.org (Carlo de Wolf (JIRA))
Date: Fri, 21 Mar 2014 19:26:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBMETA-374) Properly process
 @DeclareRoles into security-role-ref
In-Reply-To: <JIRA.12535761.1395424056000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12535761.1395424056000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12535761.1395424056000.33441.1395444370862@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBMETA-374?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Carlo de Wolf resolved JBMETA-374.
----------------------------------

    Resolution: Done

    
> Properly process @DeclareRoles into security-role-ref
> -----------------------------------------------------
>
>                 Key: JBMETA-374
>                 URL: https://issues.jboss.org/browse/JBMETA-374
>             Project: JBoss Metadata
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: ejb
>    Affects Versions: 1.0.7.GA
>            Reporter: Carlo de Wolf
>            Assignee: Carlo de Wolf
>             Fix For: 1.0.8.GA
>
>


--
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

From issues at jboss.org  Sat Mar 22 06:55:48 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Sat, 22 Mar 2014 06:55:48 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2214) Allow additional environment
 properties to be set for outbound LDAP connections used by security realms.
In-Reply-To: <JIRA.12502155.1380834418000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502155.1380834418000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502155.1380834418000.8.1395485748456@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2214?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12955210#comment-12955210 ] 

RH Bugzilla Integration commented on WFLY-2214:
-----------------------------------------------

Kabir Khan <kkhan at redhat.com> changed the Status of [bug 1015303|https://bugzilla.redhat.com/show_bug.cgi?id=1015303] from POST to MODIFIED
                
> Allow additional environment properties to be set for outbound LDAP connections used by security realms.
> --------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2214
>                 URL: https://issues.jboss.org/browse/WFLY-2214
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Derek Horton
>            Assignee: Darran Lofthouse
>             Fix For: 8.0.0.CR1
>
>
> LDAP security realm needs to have configurable timeouts.
> The default LDAP connection timeout appears to be 2 minutes.  If the ldap server is down, it could take 2 minutes for the connection to timeout.  This can cause unneeded delay if you have configured multiple ldap servers for  failover / redundancy.
> The following hack appears to work:
> +++ domain-management/src/main/java/org/jboss/as/domain/management/connections/ldap/LdapConnectionManagerService.java
> @@ -132,6 +132,7 @@ public class LdapConnectionManagerService implements Service<LdapConnectionManag
>          result.put(Context.INITIAL_CONTEXT_FACTORY,initialContextFactory);
>          String url = config.require(URL).asString();
>          result.put(Context.PROVIDER_URL,url);
> +        result.put("com.sun.jndi.ldap.connect.timeout", "500");
>          return result;
>      }

--
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

From issues at jboss.org  Sat Mar 22 06:58:56 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Sat, 22 Mar 2014 06:58:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2214) Allow additional environment
 properties to be set for outbound LDAP connections used by security realms.
In-Reply-To: <JIRA.12502155.1380834418000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502155.1380834418000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502155.1380834418000.15.1395485936524@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2214?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12955213#comment-12955213 ] 

RH Bugzilla Integration commented on WFLY-2214:
-----------------------------------------------

Kabir Khan <kkhan at redhat.com> changed the Status of [bug 1015303|https://bugzilla.redhat.com/show_bug.cgi?id=1015303] from POST to MODIFIED
                
> Allow additional environment properties to be set for outbound LDAP connections used by security realms.
> --------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2214
>                 URL: https://issues.jboss.org/browse/WFLY-2214
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Derek Horton
>            Assignee: Darran Lofthouse
>             Fix For: 8.0.0.CR1
>
>
> LDAP security realm needs to have configurable timeouts.
> The default LDAP connection timeout appears to be 2 minutes.  If the ldap server is down, it could take 2 minutes for the connection to timeout.  This can cause unneeded delay if you have configured multiple ldap servers for  failover / redundancy.
> The following hack appears to work:
> +++ domain-management/src/main/java/org/jboss/as/domain/management/connections/ldap/LdapConnectionManagerService.java
> @@ -132,6 +132,7 @@ public class LdapConnectionManagerService implements Service<LdapConnectionManag
>          result.put(Context.INITIAL_CONTEXT_FACTORY,initialContextFactory);
>          String url = config.require(URL).asString();
>          result.put(Context.PROVIDER_URL,url);
> +        result.put("com.sun.jndi.ldap.connect.timeout", "500");
>          return result;
>      }

--
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

From issues at jboss.org  Sat Mar 22 07:02:56 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Sat, 22 Mar 2014 07:02:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2214) Allow additional environment
 properties to be set for outbound LDAP connections used by security realms.
In-Reply-To: <JIRA.12502155.1380834418000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502155.1380834418000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502155.1380834418000.22.1395486176475@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2214?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12955215#comment-12955215 ] 

RH Bugzilla Integration commented on WFLY-2214:
-----------------------------------------------

Kabir Khan <kkhan at redhat.com> changed the Status of [bug 1015303|https://bugzilla.redhat.com/show_bug.cgi?id=1015303] from POST to MODIFIED
                
> Allow additional environment properties to be set for outbound LDAP connections used by security realms.
> --------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2214
>                 URL: https://issues.jboss.org/browse/WFLY-2214
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Derek Horton
>            Assignee: Darran Lofthouse
>             Fix For: 8.0.0.CR1
>
>
> LDAP security realm needs to have configurable timeouts.
> The default LDAP connection timeout appears to be 2 minutes.  If the ldap server is down, it could take 2 minutes for the connection to timeout.  This can cause unneeded delay if you have configured multiple ldap servers for  failover / redundancy.
> The following hack appears to work:
> +++ domain-management/src/main/java/org/jboss/as/domain/management/connections/ldap/LdapConnectionManagerService.java
> @@ -132,6 +132,7 @@ public class LdapConnectionManagerService implements Service<LdapConnectionManag
>          result.put(Context.INITIAL_CONTEXT_FACTORY,initialContextFactory);
>          String url = config.require(URL).asString();
>          result.put(Context.PROVIDER_URL,url);
> +        result.put("com.sun.jndi.ldap.connect.timeout", "500");
>          return result;
>      }

--
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

From issues at jboss.org  Sat Mar 22 07:10:57 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Sat, 22 Mar 2014 07:10:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2214) Allow additional environment
 properties to be set for outbound LDAP connections used by security realms.
In-Reply-To: <JIRA.12502155.1380834418000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502155.1380834418000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502155.1380834418000.32.1395486657077@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2214?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12955217#comment-12955217 ] 

RH Bugzilla Integration commented on WFLY-2214:
-----------------------------------------------

Kabir Khan <kkhan at redhat.com> changed the Status of [bug 1015303|https://bugzilla.redhat.com/show_bug.cgi?id=1015303] from POST to MODIFIED
                
> Allow additional environment properties to be set for outbound LDAP connections used by security realms.
> --------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2214
>                 URL: https://issues.jboss.org/browse/WFLY-2214
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Derek Horton
>            Assignee: Darran Lofthouse
>             Fix For: 8.0.0.CR1
>
>
> LDAP security realm needs to have configurable timeouts.
> The default LDAP connection timeout appears to be 2 minutes.  If the ldap server is down, it could take 2 minutes for the connection to timeout.  This can cause unneeded delay if you have configured multiple ldap servers for  failover / redundancy.
> The following hack appears to work:
> +++ domain-management/src/main/java/org/jboss/as/domain/management/connections/ldap/LdapConnectionManagerService.java
> @@ -132,6 +132,7 @@ public class LdapConnectionManagerService implements Service<LdapConnectionManag
>          result.put(Context.INITIAL_CONTEXT_FACTORY,initialContextFactory);
>          String url = config.require(URL).asString();
>          result.put(Context.PROVIDER_URL,url);
> +        result.put("com.sun.jndi.ldap.connect.timeout", "500");
>          return result;
>      }

--
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

From issues at jboss.org  Sat Mar 22 07:24:14 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Sat, 22 Mar 2014 07:24:14 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2214) Allow additional environment
 properties to be set for outbound LDAP connections used by security realms.
In-Reply-To: <JIRA.12502155.1380834418000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502155.1380834418000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502155.1380834418000.6.1395487454385@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2214?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12955311#comment-12955311 ] 

RH Bugzilla Integration commented on WFLY-2214:
-----------------------------------------------

Kabir Khan <kkhan at redhat.com> changed the Status of [bug 1015303|https://bugzilla.redhat.com/show_bug.cgi?id=1015303] from POST to MODIFIED
                
> Allow additional environment properties to be set for outbound LDAP connections used by security realms.
> --------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2214
>                 URL: https://issues.jboss.org/browse/WFLY-2214
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Derek Horton
>            Assignee: Darran Lofthouse
>             Fix For: 8.0.0.CR1
>
>
> LDAP security realm needs to have configurable timeouts.
> The default LDAP connection timeout appears to be 2 minutes.  If the ldap server is down, it could take 2 minutes for the connection to timeout.  This can cause unneeded delay if you have configured multiple ldap servers for  failover / redundancy.
> The following hack appears to work:
> +++ domain-management/src/main/java/org/jboss/as/domain/management/connections/ldap/LdapConnectionManagerService.java
> @@ -132,6 +132,7 @@ public class LdapConnectionManagerService implements Service<LdapConnectionManag
>          result.put(Context.INITIAL_CONTEXT_FACTORY,initialContextFactory);
>          String url = config.require(URL).asString();
>          result.put(Context.PROVIDER_URL,url);
> +        result.put("com.sun.jndi.ldap.connect.timeout", "500");
>          return result;
>      }

--
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

From issues at jboss.org  Sat Mar 22 08:27:13 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Sat, 22 Mar 2014 08:27:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2214) Allow additional environment
 properties to be set for outbound LDAP connections used by security realms.
In-Reply-To: <JIRA.12502155.1380834418000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502155.1380834418000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502155.1380834418000.11.1395491233412@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2214?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12955312#comment-12955312 ] 

RH Bugzilla Integration commented on WFLY-2214:
-----------------------------------------------

Kabir Khan <kkhan at redhat.com> changed the Status of [bug 1015303|https://bugzilla.redhat.com/show_bug.cgi?id=1015303] from POST to MODIFIED
                
> Allow additional environment properties to be set for outbound LDAP connections used by security realms.
> --------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2214
>                 URL: https://issues.jboss.org/browse/WFLY-2214
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Derek Horton
>            Assignee: Darran Lofthouse
>             Fix For: 8.0.0.CR1
>
>
> LDAP security realm needs to have configurable timeouts.
> The default LDAP connection timeout appears to be 2 minutes.  If the ldap server is down, it could take 2 minutes for the connection to timeout.  This can cause unneeded delay if you have configured multiple ldap servers for  failover / redundancy.
> The following hack appears to work:
> +++ domain-management/src/main/java/org/jboss/as/domain/management/connections/ldap/LdapConnectionManagerService.java
> @@ -132,6 +132,7 @@ public class LdapConnectionManagerService implements Service<LdapConnectionManag
>          result.put(Context.INITIAL_CONTEXT_FACTORY,initialContextFactory);
>          String url = config.require(URL).asString();
>          result.put(Context.PROVIDER_URL,url);
> +        result.put("com.sun.jndi.ldap.connect.timeout", "500");
>          return result;
>      }

--
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

From issues at jboss.org  Sat Mar 22 12:12:12 2014
From: issues at jboss.org (Andrei Palade (JIRA))
Date: Sat, 22 Mar 2014 12:12:12 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1811) Arithmetic Exception in MPerf
 when sending less than 10 messages
In-Reply-To: <JIRA.12535810.1395504697268@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12535810.1395504697268@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12535810.1395504697268.19.1395504732944@jira02.app.mwc.hst.phx2.redhat.com>

Andrei Palade created JGRP-1811:
-----------------------------------

             Summary: Arithmetic Exception in MPerf when sending less than 10 messages
                 Key: JGRP-1811
                 URL: https://issues.jboss.org/browse/JGRP-1811
             Project: JGroups
          Issue Type: Bug
            Reporter: Andrei Palade
            Assignee: Bela Ban
            Priority: Minor


Not sure if this is intended to be like this, but in MPerf when the user tries to set the num_msg to 1 and start sending the messages, MPerf throws

Mar 22, 2014 4:02:25 PM org.jgroups.logging.JDKLogImpl error
SEVERE: failure unmarshalling buffer
java.lang.ArithmeticException: / by zero
	at org.jgroups.tests.perf.MPerf.handleData(MPerf.java:418)
	at org.jgroups.tests.perf.MPerf.receive(MPerf.java:280)
	at org.jgroups.JChannel.invokeCallback(JChannel.java:890)
	at org.jgroups.JChannel.up(JChannel.java:746)
	at org.jgroups.stack.ProtocolStack.up(ProtocolStack.java:1030)
	at org.jgroups.protocols.pbcast.STATE_TRANSFER.up(STATE_TRANSFER.java:146)
	at org.jgroups.protocols.FRAG2.up(FRAG2.java:165)
	at org.jgroups.protocols.SEQUENCER.deliver(SEQUENCER.java:606)
	at org.jgroups.protocols.SEQUENCER.unwrapAndDeliver(SEQUENCER.java:573)
	at org.jgroups.protocols.SEQUENCER.up(SEQUENCER.java:279)
	at org.jgroups.protocols.SEQUENCER.up(SEQUENCER.java:308)
	at org.jgroups.protocols.FlowControl.up(FlowControl.java:434)
	at org.jgroups.protocols.FlowControl.up(FlowControl.java:434)
	at org.jgroups.stack.Protocol.up(Protocol.java:409)
	at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:294)
	at org.jgroups.protocols.UNICAST3.up(UNICAST3.java:520)
	at org.jgroups.protocols.pbcast.NAKACK2.deliverBatch(NAKACK2.java:927)
	at org.jgroups.protocols.pbcast.NAKACK2.removeAndPassUp(NAKACK2.java:857)
	at org.jgroups.protocols.pbcast.NAKACK2.handleMessage(NAKACK2.java:792)
	at org.jgroups.protocols.pbcast.NAKACK2.up(NAKACK2.java:573)
	at org.jgroups.protocols.BARRIER.up(BARRIER.java:152)
	at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:147)
	at org.jgroups.protocols.FD_ALL.up(FD_ALL.java:199)
	at org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:296)
	at org.jgroups.protocols.MERGE2.up(MERGE2.java:209)
	at org.jgroups.protocols.Discovery.up(Discovery.java:379)
	at org.jgroups.protocols.TP.passMessageUp(TP.java:1532)
	at org.jgroups.protocols.TP$3.run(TP.java:1466)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
	at java.lang.Thread.run(Thread.java:744)


--
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

From issues at jboss.org  Sat Mar 22 12:46:13 2014
From: issues at jboss.org (Bela Ban (JIRA))
Date: Sat, 22 Mar 2014 12:46:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1811) Arithmetic Exception in MPerf
 when sending less than 10 messages
In-Reply-To: <JIRA.12535810.1395504697000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12535810.1395504697000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12535810.1395504697000.23.1395506773629@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JGRP-1811?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban updated JGRP-1811:
---------------------------

    Fix Version/s: 3.5

    
> Arithmetic Exception in MPerf when sending less than 10 messages
> ----------------------------------------------------------------
>
>                 Key: JGRP-1811
>                 URL: https://issues.jboss.org/browse/JGRP-1811
>             Project: JGroups
>          Issue Type: Bug
>            Reporter: Andrei Palade
>            Assignee: Bela Ban
>            Priority: Minor
>             Fix For: 3.5
>
>
> Not sure if this is intended to be like this, but in MPerf when the user tries to set the num_msg to 1 and start sending the messages, MPerf throws
> Mar 22, 2014 4:02:25 PM org.jgroups.logging.JDKLogImpl error
> SEVERE: failure unmarshalling buffer
> java.lang.ArithmeticException: / by zero
> 	at org.jgroups.tests.perf.MPerf.handleData(MPerf.java:418)
> 	at org.jgroups.tests.perf.MPerf.receive(MPerf.java:280)
> 	at org.jgroups.JChannel.invokeCallback(JChannel.java:890)
> 	at org.jgroups.JChannel.up(JChannel.java:746)
> 	at org.jgroups.stack.ProtocolStack.up(ProtocolStack.java:1030)
> 	at org.jgroups.protocols.pbcast.STATE_TRANSFER.up(STATE_TRANSFER.java:146)
> 	at org.jgroups.protocols.FRAG2.up(FRAG2.java:165)
> 	at org.jgroups.protocols.SEQUENCER.deliver(SEQUENCER.java:606)
> 	at org.jgroups.protocols.SEQUENCER.unwrapAndDeliver(SEQUENCER.java:573)
> 	at org.jgroups.protocols.SEQUENCER.up(SEQUENCER.java:279)
> 	at org.jgroups.protocols.SEQUENCER.up(SEQUENCER.java:308)
> 	at org.jgroups.protocols.FlowControl.up(FlowControl.java:434)
> 	at org.jgroups.protocols.FlowControl.up(FlowControl.java:434)
> 	at org.jgroups.stack.Protocol.up(Protocol.java:409)
> 	at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:294)
> 	at org.jgroups.protocols.UNICAST3.up(UNICAST3.java:520)
> 	at org.jgroups.protocols.pbcast.NAKACK2.deliverBatch(NAKACK2.java:927)
> 	at org.jgroups.protocols.pbcast.NAKACK2.removeAndPassUp(NAKACK2.java:857)
> 	at org.jgroups.protocols.pbcast.NAKACK2.handleMessage(NAKACK2.java:792)
> 	at org.jgroups.protocols.pbcast.NAKACK2.up(NAKACK2.java:573)
> 	at org.jgroups.protocols.BARRIER.up(BARRIER.java:152)
> 	at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:147)
> 	at org.jgroups.protocols.FD_ALL.up(FD_ALL.java:199)
> 	at org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:296)
> 	at org.jgroups.protocols.MERGE2.up(MERGE2.java:209)
> 	at org.jgroups.protocols.Discovery.up(Discovery.java:379)
> 	at org.jgroups.protocols.TP.passMessageUp(TP.java:1532)
> 	at org.jgroups.protocols.TP$3.run(TP.java:1466)
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> 	at java.lang.Thread.run(Thread.java:744)

--
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

From issues at jboss.org  Sat Mar 22 16:20:12 2014
From: issues at jboss.org (Huu Loi Lai (JIRA))
Date: Sat, 22 Mar 2014 16:20:12 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3152) Failed initializing module
 org.jboss.as.logging
In-Reply-To: <JIRA.12535813.1395519516116@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12535813.1395519516116@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12535813.1395519516116.46.1395519612866@jira02.app.mwc.hst.phx2.redhat.com>

Huu Loi Lai created WFLY-3152:
---------------------------------

             Summary:  Failed initializing module org.jboss.as.logging
                 Key: WFLY-3152
                 URL: https://issues.jboss.org/browse/WFLY-3152
             Project: WildFly
          Issue Type: Bug
      Security Level: Public (Everyone can see)
            Reporter: Huu Loi Lai
            Priority: Blocker


I try to run integration test with arquillian and wildfly and I get following erros:
ERROR: JBAS014612: Operation ("parallel-extension-add") failed - address: ([])
java.lang.RuntimeException: JBAS014670: Failed initializing module org.jboss.as.logging
        at org.jboss.as.controller.extension.ParallelExtensionAddHandler$1.execute(ParallelExtensionAddHandler.java:99)
        at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:591)
        at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:469)
        at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:273)
        at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:268)
        at org.jboss.as.controller.ModelControllerImpl.boot(ModelControllerImpl.java:314)
        at org.jboss.as.controller.AbstractControllerService.boot(AbstractControllerService.java:294)
        at org.jboss.as.server.ServerService.boot(ServerService.java:356)
        at org.jboss.as.server.ServerService.boot(ServerService.java:331)
        at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:256)
        at java.lang.Thread.run(Thread.java:744)
Caused by: java.util.concurrent.ExecutionException: java.lang.IllegalStateException: JBAS011592: The logging subsystem requires the log manager to be org.jboss.logmanager.LogManager. The subsystem has not be initialized and cannot be used. To use JBoss Log Manager you must add the system property "java.util.logging.manager" and set it to "org.jboss.logmanager.LogManager"
        at java.util.concurrent.FutureTask.report(FutureTask.java:122)
        at java.util.concurrent.FutureTask.get(FutureTask.java:192)
        at org.jboss.as.controller.extension.ParallelExtensionAddHandler$1.execute(ParallelExtensionAddHandler.java:91)
        ... 10 more
Caused by: java.lang.IllegalStateException: JBAS011592: The logging subsystem requires the log manager to be org.jboss.logmanager.LogManager. The subsystem has not be initialized and cannot be used. To use JBoss Log Manager you must add the system property "java.util.logging.manager" and set it to "org.jboss.logmanager.LogManager"
        at org.jboss.as.logging.LoggingExtension.initialize(LoggingExtension.java:103)
        at org.jboss.as.controller.extension.ExtensionAddHandler.initializeExtension(ExtensionAddHandler.java:98)
        at org.jboss.as.controller.extension.ParallelExtensionAddHandler$ExtensionInitializeTask.call(ParallelExtensionAddHandler.java:127)
        at org.jboss.as.controller.extension.ParallelExtensionAddHandler$ExtensionInitializeTask.call(ParallelExtensionAddHandler.java:113)
        at java.util.concurrent.FutureTask.run(FutureTask.java:266)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
        at java.lang.Thread.run(Thread.java:744)
        at org.jboss.threads.JBossThread.run(JBossThread.java:122)

--
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

From issues at jboss.org  Sat Mar 22 17:36:13 2014
From: issues at jboss.org (David Lloyd (JIRA))
Date: Sat, 22 Mar 2014 17:36:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3152) Failed initializing module
 org.jboss.as.logging
In-Reply-To: <JIRA.12535813.1395519516000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12535813.1395519516000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12535813.1395519516000.55.1395524173100@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-3152?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

David Lloyd resolved WFLY-3152.
-------------------------------

    Resolution: Rejected


This is not a bug.  The error message explains the exact problem.  If you need help, please use the user forums.
                
>  Failed initializing module org.jboss.as.logging
> ------------------------------------------------
>
>                 Key: WFLY-3152
>                 URL: https://issues.jboss.org/browse/WFLY-3152
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Huu Loi Lai
>            Priority: Blocker
>
> I try to run integration test with arquillian and wildfly and I get following erros:
> ERROR: JBAS014612: Operation ("parallel-extension-add") failed - address: ([])
> java.lang.RuntimeException: JBAS014670: Failed initializing module org.jboss.as.logging
>         at org.jboss.as.controller.extension.ParallelExtensionAddHandler$1.execute(ParallelExtensionAddHandler.java:99)
>         at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:591)
>         at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:469)
>         at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:273)
>         at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:268)
>         at org.jboss.as.controller.ModelControllerImpl.boot(ModelControllerImpl.java:314)
>         at org.jboss.as.controller.AbstractControllerService.boot(AbstractControllerService.java:294)
>         at org.jboss.as.server.ServerService.boot(ServerService.java:356)
>         at org.jboss.as.server.ServerService.boot(ServerService.java:331)
>         at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:256)
>         at java.lang.Thread.run(Thread.java:744)
> Caused by: java.util.concurrent.ExecutionException: java.lang.IllegalStateException: JBAS011592: The logging subsystem requires the log manager to be org.jboss.logmanager.LogManager. The subsystem has not be initialized and cannot be used. To use JBoss Log Manager you must add the system property "java.util.logging.manager" and set it to "org.jboss.logmanager.LogManager"
>         at java.util.concurrent.FutureTask.report(FutureTask.java:122)
>         at java.util.concurrent.FutureTask.get(FutureTask.java:192)
>         at org.jboss.as.controller.extension.ParallelExtensionAddHandler$1.execute(ParallelExtensionAddHandler.java:91)
>         ... 10 more
> Caused by: java.lang.IllegalStateException: JBAS011592: The logging subsystem requires the log manager to be org.jboss.logmanager.LogManager. The subsystem has not be initialized and cannot be used. To use JBoss Log Manager you must add the system property "java.util.logging.manager" and set it to "org.jboss.logmanager.LogManager"
>         at org.jboss.as.logging.LoggingExtension.initialize(LoggingExtension.java:103)
>         at org.jboss.as.controller.extension.ExtensionAddHandler.initializeExtension(ExtensionAddHandler.java:98)
>         at org.jboss.as.controller.extension.ParallelExtensionAddHandler$ExtensionInitializeTask.call(ParallelExtensionAddHandler.java:127)
>         at org.jboss.as.controller.extension.ParallelExtensionAddHandler$ExtensionInitializeTask.call(ParallelExtensionAddHandler.java:113)
>         at java.util.concurrent.FutureTask.run(FutureTask.java:266)
>         at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>         at java.lang.Thread.run(Thread.java:744)
>         at org.jboss.threads.JBossThread.run(JBossThread.java:122)

--
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

From issues at jboss.org  Sun Mar 23 13:03:12 2014
From: issues at jboss.org (Emmanuel Hugonnet (JIRA))
Date: Sun, 23 Mar 2014 13:03:12 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3153) Testing legacy subsystem
 transformers between different versions of Wildlfy
In-Reply-To: <JIRA.12535819.1395594160433@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12535819.1395594160433@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12535819.1395594160433.182.1395594192907@jira02.app.mwc.hst.phx2.redhat.com>

Emmanuel Hugonnet created WFLY-3153:
---------------------------------------

             Summary: Testing legacy subsystem transformers between different versions of Wildlfy
                 Key: WFLY-3153
                 URL: https://issues.jboss.org/browse/WFLY-3153
             Project: WildFly
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Domain Management
    Affects Versions: 8.0.0.Final
            Reporter: Emmanuel Hugonnet
            Assignee: Brian Stansberry


The legacy web subsystem is still evolving. Thus we need to make the legacy web subsystem in WildFly evolve and test the transformers.
But testing the transformation between WildFly 8.0.0.Final and the next version of WildFly fails with the following exception :
java.lang.RuntimeException: java.lang.reflect.InvocationTargetException
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:606)
        at org.jboss.as.subsystem.bridge.local.ScopedKernelServicesBootstrap.createChildClassLoaderKernelServices(ScopedKernelServicesBootstrap.java:85)
        at org.jboss.as.subsystem.bridge.local.ScopedKernelServicesBootstrap.createKernelServices(ScopedKernelServicesBootstrap.java:53)
        at org.jboss.as.subsystem.test.SubsystemTestDelegate$LegacyKernelServiceInitializerImpl.install(SubsystemTestDelegate.java:771)
        at org.jboss.as.subsystem.test.SubsystemTestDelegate$LegacyKernelServiceInitializerImpl.access$700(SubsystemTestDelegate.java:644)
        at org.jboss.as.subsystem.test.SubsystemTestDelegate$KernelServicesBuilderImpl.build(SubsystemTestDelegate.java:616)
        at org.jboss.as.web.test.WebSubsystemTestCase.testTransformation_2_0(WebSubsystemTestCase.java:443)
        at org.jboss.as.web.test.WebSubsystemTestCase.testTransformationWildFly8(WebSubsystemTestCase.java:427)
Caused by: java.lang.IllegalArgumentException: JBAS014880: No operation entry called 'add' registered at '[("subsystem" => "web")]'
        at org.jboss.as.controller.operations.validation.OperationValidator.throwOrWarnAboutDescriptorProblem(OperationValidator.java:549)
        at org.jboss.as.controller.operations.validation.OperationValidator.validateOperation(OperationValidator.java:123)
        at org.jboss.as.model.test.ModelTestModelControllerService.boot(ModelTestModelControllerService.java:199)
        at org.jboss.as.controller.AbstractControllerService.boot(AbstractControllerService.java:289)
        at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:256)
        at java.lang.Thread.run(Thread.java:744)


--
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

From issues at jboss.org  Sun Mar 23 16:47:13 2014
From: issues at jboss.org (Tomaz Cerar (JIRA))
Date: Sun, 23 Mar 2014 16:47:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3146) Undertow Memory Leak for
	JAX-RS requests
In-Reply-To: <JIRA.12535043.1394808299000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12535043.1394808299000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12535043.1394808299000.216.1395607633261@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-3146?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tomaz Cerar resolved WFLY-3146.
-------------------------------

      Assignee: Stuart Douglas  (was: Tomaz Cerar)
    Resolution: Done


Both component upgrades ware merged.
                
> Undertow Memory Leak for JAX-RS requests
> ----------------------------------------
>
>                 Key: WFLY-3146
>                 URL: https://issues.jboss.org/browse/WFLY-3146
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web (Undertow)
>    Affects Versions: 8.0.0.Final
>         Environment: Windows 7 Professional
> JDK 1.7.0_21
> WildFly 8.0.0.Final
>            Reporter: Darren Jones
>            Assignee: Stuart Douglas
>            Priority: Critical
>              Labels: MemoryLeak
>             Fix For: 8.0.1.Final
>
>         Attachments: hello-client.zip, hello-service-0.1-SNAPSHOT.war, hello-service.zip, JProfiler GC Root.png, server.keystore, standalone.xml, VisualVM Memory.png
>
>
> After half an hour or so of running the automated test suite for our application, the server hangs due to GC and many OutOfMemoryErrors appear in the WildFly server log.
> I've attached VisualVM and JProfiler, both of which demonstrate that many of the objects that are not being garbage collected are Undertow objects. Both tools show that the path to the GC root is via a Java nio SelectionKey, which is held by sun.nio.ch.WindowsSelectorImpl. 
> I'll attach a screenshot of a JProfiler window to demonstrate, but VisualVM shows the same result (albeit presented differently).
> I have also found similar behaviour with a small, trivial example, as described in the Steps to Reproduce. It makes repeated calls to a simple RESTful call to a JAX-RS service. The example doesn't cause as fast a leak as our test suite, but it does demonstrate the problem.
> The example uses https for the call because it seems to leak memory faster than http - but http does also exhibit the problem.
> I have also tried patching WildFly 8.0.0.Final up to Undertow.1.0.2-SNAPSHOT and XNIO.3.3.0-SNAPSHOT (as of this morning), but the problem still occurs.

--
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

From issues at jboss.org  Sun Mar 23 18:17:12 2014
From: issues at jboss.org (Stuart Douglas (JIRA))
Date: Sun, 23 Mar 2014 18:17:12 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3093) Undertow doesn't show the
 correct error page (401)
In-Reply-To: <JIRA.12534502.1394377769000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534502.1394377769000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534502.1394377769000.232.1395613032923@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-3093?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stuart Douglas resolved WFLY-3093.
----------------------------------

    Fix Version/s: 8.0.1.Final
       Resolution: Done

    
> Undertow doesn't show the correct error page (401)
> --------------------------------------------------
>
>                 Key: WFLY-3093
>                 URL: https://issues.jboss.org/browse/WFLY-3093
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web (Undertow)
>    Affects Versions: 8.0.0.Final
>            Reporter: Juergen Zimmermann
>            Assignee: Stuart Douglas
>             Fix For: 8.0.1.Final
>
>
> I'm using the WildFly snapshot from last Thursday with Undertow 1.0.1.
> When I try to invoke a protected web page, I'm getting an almost blank web page with just the contents "401 - Unauthorized".
> However, in WEB-INF/web.xml I'm having this declaration:
> {code}
> <error-page>
>     <error-code>401</error-code>
>     <location>/rf/error/accessDenied.jsf</location>
> </error-page>
> {code}

--
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

From issues at jboss.org  Sun Mar 23 19:05:13 2014
From: issues at jboss.org (Stuart Douglas (JIRA))
Date: Sun, 23 Mar 2014 19:05:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3113) Websocket connection fails
 when connecting to protected URL (basic login)
In-Reply-To: <JIRA.12534953.1394744993000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534953.1394744993000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534953.1394744993000.238.1395615913149@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-3113?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stuart Douglas resolved WFLY-3113.
----------------------------------

    Resolution: Rejected


As far as I can tell Undertow is behaving as it should. 
                
> Websocket connection fails when connecting to protected URL (basic login)
> -------------------------------------------------------------------------
>
>                 Key: WFLY-3113
>                 URL: https://issues.jboss.org/browse/WFLY-3113
>             Project: WildFly
>          Issue Type: Clarification
>      Security Level: Public(Everyone can see) 
>          Components: Web (Undertow)
>    Affects Versions: 8.0.0.Final
>         Environment: WildFly 8.0.0.Final, Windows 8, RedHat Linux
> Chrome, Firefox
>            Reporter: Alexandre Nikolov
>            Assignee: Stuart Douglas
>              Labels: jsr356,, login
>
> In a sample application for JSR356 support, added security constraints with basic log-in. The websocket endpoint is protect with basic log-in.
> When a websocket connection is attempted to the protected URL, there is inconsistent behavior in different browsers:
> 1. Chrome fails with 401 error code and the log-in screen is not displayed at all.
> 2. Firefox displays the log-in screen and the websocket is created and opened after the log-in succeeds.
> But in a different application, using Atmosphere - both connections fails:
> 1. Chrome fails with the same error and the log-in screen is displayed after that. Most probably the log-in screen is triggered by Atmosphere when it falls back to long-polling
> 2. Firefox - The login screen is displayed and if the log-in suceeds, the socket is created, but Atmosphere fails to process it.
> For example if the context root is "jsr356test" and the protected path is /pubsub/protected, Atmosphere tries to map /jsr356test/pubsub/protected (which in JSR356 is Session#getRequestURI()) but has mapping set-up for /pubsub/protected (which for a Http request would be the path info) 
> Here is the related discussion on the Atmosphere users group:
> https://groups.google.com/forum/#!topic/atmosphere-framework/ntIHOohlYIc
> There is test WAR and source in the Atmosphere forum to reproduce the problem.

--
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

From issues at jboss.org  Sun Mar 23 19:15:14 2014
From: issues at jboss.org (Stuart Douglas (JIRA))
Date: Sun, 23 Mar 2014 19:15:14 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3087) Websocket
 NullPointerException on
 io.undertow.websockets.jsr.annotated.AnnotatedEndpoint$AnnotatedEndpointFrameHandler.handleBinaryMessage(AnnotatedEndpoint.java:373)
In-Reply-To: <JIRA.12534452.1394215322000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534452.1394215322000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534452.1394215322000.259.1395616514059@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-3087?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stuart Douglas resolved WFLY-3087.
----------------------------------

    Fix Version/s: 8.0.1.Final
       Resolution: Done

    
> Websocket NullPointerException on io.undertow.websockets.jsr.annotated.AnnotatedEndpoint$AnnotatedEndpointFrameHandler.handleBinaryMessage(AnnotatedEndpoint.java:373)
> ----------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-3087
>                 URL: https://issues.jboss.org/browse/WFLY-3087
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web (Undertow)
>    Affects Versions: 8.0.0.CR1
>         Environment: windows server 2008
>            Reporter: Admin FlirtyMob
>            Assignee: Stuart Douglas
>             Fix For: 8.0.1.Final
>
>
> 2014-03-07 17:10:49,208 ERROR [org.xnio.listener] (default I/O-1) XNIO001007: A channel event listener threw an exception: java.lang.NullPointerException
> at io.undertow.websockets.jsr.annotated.AnnotatedEndpoint$AnnotatedEndpointFrameHandler.handleBinaryMessage(AnnotatedEndpoint.java:373)
> at io.undertow.websockets.jsr.annotated.AnnotatedEndpoint$AnnotatedEndpointFrameHandler.access$1100(AnnotatedEndpoint.java:126)
> at io.undertow.websockets.jsr.annotated.AnnotatedEndpoint$AnnotatedEndpointFrameHandler$6.complete(AnnotatedEndpoint.java:332)
> at io.undertow.websockets.jsr.annotated.AnnotatedEndpoint$AnnotatedEndpointFrameHandler$6.complete(AnnotatedEndpoint.java:329)
> at io.undertow.websockets.core.BufferedBinaryMessage.read(BufferedBinaryMessage.java:76)
> at io.undertow.websockets.jsr.annotated.AnnotatedEndpoint$AnnotatedEndpointFrameHandler.onBinary(AnnotatedEndpoint.java:329)
> at io.undertow.websockets.core.AbstractReceiveListener.handleEvent(AbstractReceiveListener.java:24)
> at io.undertow.websockets.core.AbstractReceiveListener.handleEvent(AbstractReceiveListener.java:15)
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) [xnio-api-3.2.0.Beta4.jar:3.2.0.Beta4]
> at io.undertow.server.protocol.framed.AbstractFramedChannel$FrameReadListener.handleEvent(AbstractFramedChannel.java:615)
> at io.undertow.server.protocol.framed.AbstractFramedChannel$FrameReadListener.handleEvent(AbstractFramedChannel.java:601)
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) [xnio-api-3.2.0.Beta4.jar:3.2.0.Beta4]
> at org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66) [xnio-api-3.2.0.Beta4.jar:3.2.0.Beta4]
> at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:87) [xnio-nio-3.2.0.Beta4.jar:3.2.0.Beta4]
> at org.xnio.nio.WorkerThread.run(WorkerThread.java:531) [xnio-nio-3.2.0.Beta4.jar:3.2.0.Beta4]

--
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

From issues at jboss.org  Sun Mar 23 19:17:12 2014
From: issues at jboss.org (Stuart Douglas (JIRA))
Date: Sun, 23 Mar 2014 19:17:12 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-937) ServletContext.getResource()
 doesn't work correctly for files containing hash characters
In-Reply-To: <JIRA.12481759.1356360681000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12481759.1356360681000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12481759.1356360681000.262.1395616632951@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-937?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stuart Douglas resolved WFLY-937.
---------------------------------

    Fix Version/s: 8.0.1.Final
       Resolution: Done

    
> ServletContext.getResource() doesn't work correctly for files containing hash characters
> ----------------------------------------------------------------------------------------
>
>                 Key: WFLY-937
>                 URL: https://issues.jboss.org/browse/WFLY-937
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web (Undertow)
>    Affects Versions: JBoss AS7 7.2.0.Final, 8.0.0.CR1
>         Environment: Linux 3.2.0-30-generic Ubuntu SMP x86_64 GNU/Linux
>            Reporter: Christian Kaltepoth
>            Assignee: Stuart Douglas
>             Fix For: 8.0.1.Final
>
>         Attachments: as7-url-bug.zip
>
>
> {{ServletContext.getResource()}} returns an invalid URL if the file name contains {{#}} characters.
> Example:
> {code:java}
> URL url = servletContext.getResource("/file#1.txt");
> {code}
> The resulting URL object will be spitted at the {{#}} character like this:
> {code}
> url.toString():   jndi:/default-host/tomcat-url-bug/file#1.txt
> url.getPath():    /default-host/tomcat-url-bug/file
> url.getRef():     1.txt
> {code}
> Calling {{url.openStream()}} will throw a {{FileNotFoundException}}.
> This is a known Tomcat issue fixed in 7.0.28.
> References:
> https://issues.apache.org/bugzilla/show_bug.cgi?id=53257
> https://issues.apache.org/bugzilla/show_bug.cgi?id=51584
> According to the discussion on the Tomcat issue tracker, there are also problems for other characters which have special meaning in URLs.

--
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

From issues at jboss.org  Sun Mar 23 20:17:13 2014
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Sun, 23 Mar 2014 20:17:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-315) Avoid running out of threads
 when connecting to the DC from a slave to pull down missing data
In-Reply-To: <JIRA.12488204.1364406845000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12488204.1364406845000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12488204.1364406845000.299.1395620233123@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-315?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12955359#comment-12955359 ] 

Brian Stansberry commented on WFLY-315:
---------------------------------------

The IO I'm talking about is writes. The reads are all done by remoting threads, so that's fine. But in many places the thread executing an op itself writes, e.g. to proxy a request, to send a prepared, failed or completed response, or to send a commit/rollback instruction. The problem with this is if an administrative action to cancel the op occurs, the thread is interrupted, and when that thread later interacts with the channel to write, the channel gets closed. Testing administratively cancelling ops from various processes I was regularly seeing the connection from a slave to the master or a server to its HC getting closed.
                
> Avoid running out of threads when connecting to the DC from a slave to pull down missing data
> ---------------------------------------------------------------------------------------------
>
>                 Key: WFLY-315
>                 URL: https://issues.jboss.org/browse/WFLY-315
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>            Reporter: Kabir Khan
>            Assignee: Emanuel Muckenhuber
>            Priority: Blocker
>             Fix For: 9.0.0.CR1
>
>
> For WFLY-259 when a slave connects to the DC to pull down missing data, it does this by either getting a lock for the DC, or by joining the permit of the existing DC lock if the request to update a slave's server-config was executed as part of a composite obtaining a lock on the DC.
> The way it works at present there is a thread per slave which is blocked until the transaction completes. The DC threads are a finite resource, so a large number of slaves trying to pull down dats will cause deadlock

--
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

From issues at jboss.org  Mon Mar 24 00:27:13 2014
From: issues at jboss.org (Stuart Douglas (JIRA))
Date: Mon, 24 Mar 2014 00:27:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3144) Session replication doesn't
 work as expected
In-Reply-To: <JIRA.12535573.1395324594000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12535573.1395324594000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12535573.1395324594000.374.1395635233152@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-3144?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stuart Douglas updated WFLY-3144:
---------------------------------

    Component/s: Clustering

    
> Session replication doesn't work as expected
> --------------------------------------------
>
>                 Key: WFLY-3144
>                 URL: https://issues.jboss.org/browse/WFLY-3144
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: CDI / Weld, Clustering, EJB
>    Affects Versions: 8.0.0.Final
>            Reporter: Tomas Remes
>            Assignee: Stuart Douglas
>         Attachments: translator.zip
>
>
> I am experimenting with quite simple Stateful SessionScoped bean  ( see org.jboss.weld.tests.clustering.translator.TranslatorControllerBean from attached reproducer) and actually there's not any specific exception, but the behavior is at least weird. I haven't tried with plain EJB so far. Reproducible by following steps:
> 1. Run first node with "/bin/standalone.sh -c standalone-ha.xml"
> 2. Run second node with "./bin/standalone.sh -c standalone-ha.xml -Djboss.socket.binding.port-offset=100 -Djboss.node.name=second"
> 3. Build and deploy attached reproducer
> 4. Open 127.0.0.1:8080/translator in your browser and translate something.
> 5. Open 127.0.0.1:8180/translator and note that number of translated sentences is not replicated correctly. 
> This works correctly in EAP. I am running with default standalone-ha configuration on oracle's 1.7.0_45 jdk.

--
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

From issues at jboss.org  Mon Mar 24 04:35:13 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 24 Mar 2014 04:35:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3029) add remove-jndi operations to
 JMS resources
In-Reply-To: <JIRA.12533372.1393423257000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12533372.1393423257000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12533372.1393423257000.507.1395650113341@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-3029?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated WFLY-3029:
------------------------------------------

        Bugzilla Update: Perform
    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1079457

    
> add remove-jndi operations to JMS resources
> -------------------------------------------
>
>                 Key: WFLY-3029
>                 URL: https://issues.jboss.org/browse/WFLY-3029
>             Project: WildFly
>          Issue Type: Enhancement
>      Security Level: Public(Everyone can see) 
>          Components: JMS
>    Affects Versions: 8.0.0.Final
>            Reporter: Jeff Mesnil
>            Assignee: Jeff Mesnil
>             Fix For: 8.0.1.Final
>
>
> JMS resources have a "add-jndi" operation to add a JNDI binding to their entries attribute but there is no mechanism to remove one JNDI binding.
> A remove-jndi operation must be added to handle this use case.

--
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

From issues at jboss.org  Mon Mar 24 05:51:14 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 24 Mar 2014 05:51:14 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3108) Can't promote --backup slave
 HC to master and reload without moving domain.cached-remote.xml
In-Reply-To: <JIRA.12534873.1394711186000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534873.1394711186000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534873.1394711186000.704.1395654674025@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-3108?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12955420#comment-12955420 ] 

RH Bugzilla Integration commented on WFLY-3108:
-----------------------------------------------

Petr Kremensky <pkremens at redhat.com> changed the Status of [bug 1076066|https://bugzilla.redhat.com/show_bug.cgi?id=1076066] from ON_QA to VERIFIED
                
> Can't promote --backup slave HC to master and reload without moving domain.cached-remote.xml
> --------------------------------------------------------------------------------------------
>
>                 Key: WFLY-3108
>                 URL: https://issues.jboss.org/browse/WFLY-3108
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>    Affects Versions: 8.0.0.Final
>            Reporter: Brian Stansberry
>            Assignee: Brian Stansberry
>             Fix For: 8.0.1.Final
>
>
> The prescribed mechanism for converting a slave HC to master is to:
> 1) Start the slave with --backup so a local copy of the domain config is maintained (in file domain.cached-remote.xml).
> 2) Stop the existing master.
> 3) Use the cli to connect to the slave and
> /host=<slavename>:write-local-domain-controller
> 4) Then, in the CLI
> reload --host=<slavename>
> Problem is this fails because the HC expects to have a domain config file "domain.xml".
> 2014-03-13 09:54:04,829 ERROR [org.jboss.as.host.controller] (Controller Boot Thread) JBAS010932: Caught exception during boot: org.jboss.as.controller.persistence.ConfigurationPersistenceException: JBAS014676: Failed to parse configuration
> 	at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:112) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> 	at org.jboss.as.host.controller.DomainModelControllerService.boot(DomainModelControllerService.java:514) [wildfly-host-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> 	at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:256) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> 	at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_45]
> Caused by: java.io.FileNotFoundException: /Users/bstansberry/tmp/WF801/slave/domain/configuration/domain.xml (No such file or directory)
> 	at java.io.FileInputStream.open(Native Method) [rt.jar:1.7.0_45]
> 	at java.io.FileInputStream.<init>(FileInputStream.java:146) [rt.jar:1.7.0_45]
> 	at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:100) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> 	... 3 more
> Or, MUCH WORSE, there happens to be a random domain.xml in the filesystem, which has content that is out of sync with the correct domain config. This domain.xml config will be used.

--
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

From issues at jboss.org  Mon Mar 24 06:01:16 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 24 Mar 2014 06:01:16 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBEE-146) jboss-el-api_2.2_spec
 1.0.2.Final cannot access public methods from non-public classes
In-Reply-To: <JIRA.12525180.1384462560000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12525180.1384462560000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12525180.1384462560000.746.1395655276249@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JBEE-146?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12955426#comment-12955426 ] 

RH Bugzilla Integration commented on JBEE-146:
----------------------------------------------

Matous Jobanek <mjobanek at redhat.com> changed the Status of [bug 1076320|https://bugzilla.redhat.com/show_bug.cgi?id=1076320] from ON_QA to VERIFIED
                
> jboss-el-api_2.2_spec 1.0.2.Final cannot access public methods from non-public classes
> --------------------------------------------------------------------------------------
>
>                 Key: JBEE-146
>                 URL: https://issues.jboss.org/browse/JBEE-146
>             Project: JBoss JavaEE Spec APIs
>          Issue Type: Bug
>            Reporter: Farah Juma
>            Assignee: Farah Juma
>             Fix For: jboss-el-api_2.2_spec-1.0.3.Final, jboss-el-api_3.0_spec-1.0.0.Final
>
>
> When accessing a public method of a non-public class via EL that implements a public interface or has a public superclass, the following exception occurs:
> {code}java.lang.IllegalAccessException: Class javax.el.BeanELResolver can not access a member of class X with modifiers "public" 
> {code}
> See https://bugzilla.redhat.com/show_bug.cgi?id=1029387 for more 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

From issues at jboss.org  Mon Mar 24 06:01:16 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 24 Mar 2014 06:01:16 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2493) EL cannot access public
 methods/fields of non-public classes
In-Reply-To: <JIRA.12524859.1384250001000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12524859.1384250001000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12524859.1384250001000.749.1395655276400@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2493?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12955427#comment-12955427 ] 

RH Bugzilla Integration commented on WFLY-2493:
-----------------------------------------------

Matous Jobanek <mjobanek at redhat.com> changed the Status of [bug 1076320|https://bugzilla.redhat.com/show_bug.cgi?id=1076320] from ON_QA to VERIFIED
                
> EL cannot access public methods/fields of non-public classes
> ------------------------------------------------------------
>
>                 Key: WFLY-2493
>                 URL: https://issues.jboss.org/browse/WFLY-2493
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JSF
>         Environment: JBoss AS 7.2.0.Final
>            Reporter: Jon?? Trantina
>         Attachments: elresolver_stack, reproducer.zip
>
>
> When trying to access public method/field of non-public class that implements public interface via EL I get 
> {noformat}
> java.lang.IllegalAccessException: Class javax.el.BeanELResolver can not access a member of class X with modifiers "private"
> {noformat}
> E.g. accessing Collections.unmodifiableList(..).size() via EL will throw the exception, because #unmodifiableList returns non-public implementation of List interface.
> This is apparently caused by JDK-4071957 [1], but since that is opened for over 16 years, it should be probably worth it to implement a workaround.
> Workaround for this issue is setting setAccessible(true) on the method before invoking it, thus suppress Java access checking.
> I have attached a simple reproducer app as well as a stack trace of the exception.
> [1] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4071957

--
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


From issues at jboss.org  Mon Mar 24 06:23:12 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 24 Mar 2014 06:23:12 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (SECURITY-805) Overload
 SecurityVaultFactory.get() to be able to specify the classloader
In-Reply-To: <JIRA.12535004.1394795116000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12535004.1394795116000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12535004.1394795116000.812.1395656592867@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/SECURITY-805?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated SECURITY-805:
---------------------------------------------

        Bugzilla Update: Perform
    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1079930

    
> Overload SecurityVaultFactory.get() to be able to specify the classloader
> -------------------------------------------------------------------------
>
>                 Key: SECURITY-805
>                 URL: https://issues.jboss.org/browse/SECURITY-805
>             Project: PicketBox 
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>            Reporter: Kabir Khan
>            Assignee: Kabir Khan
>         Attachments: SECURITY-805-2.diff, SECURITY-805.diff
>
>
> To work better with modular class loading in WF

--
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

From issues at jboss.org  Mon Mar 24 06:25:13 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 24 Mar 2014 06:25:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (SECURITY-805) Overload
 SecurityVaultFactory.get() to be able to specify the classloader
In-Reply-To: <JIRA.12535004.1394795116000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12535004.1394795116000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12535004.1394795116000.825.1395656713452@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/SECURITY-805?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12955440#comment-12955440 ] 

RH Bugzilla Integration commented on SECURITY-805:
--------------------------------------------------

Kabir Khan <kkhan at redhat.com> changed the Status of [bug 1079930|https://bugzilla.redhat.com/show_bug.cgi?id=1079930] from NEW to ASSIGNED
                
> Overload SecurityVaultFactory.get() to be able to specify the classloader
> -------------------------------------------------------------------------
>
>                 Key: SECURITY-805
>                 URL: https://issues.jboss.org/browse/SECURITY-805
>             Project: PicketBox 
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>            Reporter: Kabir Khan
>            Assignee: Kabir Khan
>         Attachments: SECURITY-805-2.diff, SECURITY-805.diff
>
>
> To work better with modular class loading in WF

--
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

From issues at jboss.org  Mon Mar 24 06:45:13 2014
From: issues at jboss.org (vishal kumar (JIRA))
Date: Mon, 24 Mar 2014 06:45:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (AS7-4260) Occurences of "Exception
 acquiring ownership of X (via SharedLocalYieldingClusterLockManager)"
In-Reply-To: <JIRA.12462250.1332424552000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12462250.1332424552000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12462250.1332424552000.862.1395657913872@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/AS7-4260?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12955449#comment-12955449 ] 

vishal kumar commented on AS7-4260:
-----------------------------------

Hi,

We are facing the exactly same issue, can you please help in finding out the route cause.

We are having two jboss in standalone cluster , they are giving this particular issue while using the application.

Thanks
                
> Occurences of "Exception acquiring ownership of X (via SharedLocalYieldingClusterLockManager)"
> ----------------------------------------------------------------------------------------------
>
>                 Key: AS7-4260
>                 URL: https://issues.jboss.org/browse/AS7-4260
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Clustering
>    Affects Versions: 7.1.1.Final
>            Reporter: Radoslav Husar
>            Assignee: Paul Ferraro
>              Labels: JBAS018080, as713tracking
>             Fix For: 7.1.3.Final (EAP), EAP 6.1.0.Alpha (7.2.0.Final)
>
>         Attachments: SessionTravel.gif, view-perf18.log, view-perf19.log, view-perf20.log, view-perf21.log
>
>
> There are often occurrences of "Exception acquiring ownership of X":
> During shutdown, using dist:
> {noformat}
> 13:09:28,290 WARN  [org.apache.catalina.session.ManagerBase] (ContainerBackgroundProcessor[StandardEngine[jboss.web]]) JBAS018080: Standard expiration of session qLQps+CQJxEi6pJTBSzis0g3 failed; switching to a brute force cleanup. Problem is JBAS018060: Exception acquiring ownership of qLQps+CQJxEi6pJTBSzis0g3
> {noformat}
> During server crash, using repl:
> {noformat}
> 12:55:49,556 INFO  [org.jboss.as.clustering.impl.CoreGroupCommunicationService.ejb] (Incoming-2,null) JBAS010248: New cluster view for partition ejb: 6 (org.jboss.as.clustering.impl.CoreGroupCommunicationService$GroupView at 327579f6 delta: -1, merge: false)
> 12:55:49,557 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (Incoming-2,null) ISPN000094: Received new cluster view: [perf21/ejb|6] [perf21/ejb, perf20/ejb, perf18/ejb]
> 12:56:31,694 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[default-host]] (ajp-perf20-10.16.90.58-8009-211) Exception sending request initialized lifecycle event to listener instance of class org.jboss.weld.servlet.WeldListener: java.lang.RuntimeException: JBAS018060: Exception acquiring ownership of MvwC8KGWTuKPjD1-JjLW7URZ
> 	at org.jboss.as.web.session.ClusteredSession.acquireSessionOwnership(ClusteredSession.java:528) [jboss-as-web-7.1.2.Final-SNAPSHOT.jar:7.1.2.Final-SNAPSHOT]
> 	at org.jboss.as.web.session.ClusteredSession.expire(ClusteredSession.java:1260) [jboss-as-web-7.1.2.Final-SNAPSHOT.jar:7.1.2.Final-SNAPSHOT]
> 	at org.jboss.as.web.session.ClusteredSession.isValid(ClusteredSession.java:1208) [jboss-as-web-7.1.2.Final-SNAPSHOT.jar:7.1.2.Final-SNAPSHOT]
> 	at org.jboss.as.web.session.ClusteredSession.isValid(ClusteredSession.java:598) [jboss-as-web-7.1.2.Final-SNAPSHOT.jar:7.1.2.Final-SNAPSHOT]
> 	at org.jboss.as.web.session.DistributableSessionManager.add(DistributableSessionManager.java:917) [jboss-as-web-7.1.2.Final-SNAPSHOT.jar:7.1.2.Final-SNAPSHOT]
> 	at org.jboss.as.web.session.DistributableSessionManager.loadSession(DistributableSessionManager.java:1407) [jboss-as-web-7.1.2.Final-SNAPSHOT.jar:7.1.2.Final-SNAPSHOT]
> 	at org.jboss.as.web.session.DistributableSessionManager.findSession(DistributableSessionManager.java:686) [jboss-as-web-7.1.2.Final-SNAPSHOT.jar:7.1.2.Final-SNAPSHOT]
> 	at org.jboss.as.web.session.DistributableSessionManager.findSession(DistributableSessionManager.java:85) [jboss-as-web-7.1.2.Final-SNAPSHOT.jar:7.1.2.Final-SNAPSHOT]
> 	at org.apache.catalina.connector.Request.doGetSession(Request.java:2618) [jbossweb-7.0.13.Final.jar:]
> 	at org.apache.catalina.connector.Request.getSession(Request.java:2375) [jbossweb-7.0.13.Final.jar:]
> 	at org.apache.catalina.connector.RequestFacade.getSession(RequestFacade.java:841) [jbossweb-7.0.13.Final.jar:]
> 	at org.jboss.weld.context.beanstore.http.LazySessionBeanStore.getSession(LazySessionBeanStore.java:72) [weld-core-1.1.5.AS71.Final.jar:2012-02-10 15:31]
> 	at org.jboss.weld.context.beanstore.http.LazySessionBeanStore.<init>(LazySessionBeanStore.java:58) [weld-core-1.1.5.AS71.Final.jar:2012-02-10 15:31]
> 	at org.jboss.weld.context.http.HttpSessionContextImpl.associate(HttpSessionContextImpl.java:31) [weld-core-1.1.5.AS71.Final.jar:2012-02-10 15:31]
> 	at org.jboss.weld.context.http.HttpSessionContextImpl.associate(HttpSessionContextImpl.java:16) [weld-core-1.1.5.AS71.Final.jar:2012-02-10 15:31]
> 	at org.jboss.weld.servlet.WeldListener.requestInitialized(WeldListener.java:134) [weld-core-1.1.5.AS71.Final.jar:2012-02-10 15:31]
> 	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:143) [jbossweb-7.0.13.Final.jar:]
> 	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) [jbossweb-7.0.13.Final.jar:]
> 	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) [jbossweb-7.0.13.Final.jar:]
> 	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:368) [jbossweb-7.0.13.Final.jar:]
> 	at org.apache.coyote.ajp.AjpProcessor.process(AjpProcessor.java:505) [jbossweb-7.0.13.Final.jar:]
> 	at org.apache.coyote.ajp.AjpProtocol$AjpConnectionHandler.process(AjpProtocol.java:445) [jbossweb-7.0.13.Final.jar:]
> 	at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:930) [jbossweb-7.0.13.Final.jar:]
> 	at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_30]
> Caused by: org.jboss.as.clustering.lock.TimeoutException: JBAS010223: Cannot acquire lock //default-host//clusterbench/MvwC8KGWTuKPjD1-JjLW7URZ from cluster
> 	at org.jboss.as.clustering.lock.SharedLocalYieldingClusterLockManager.lock(SharedLocalYieldingClusterLockManager.java:439)
> 	at org.jboss.as.clustering.web.infinispan.DistributedCacheManager.acquireSessionOwnership(DistributedCacheManager.java:372)
> 	at org.jboss.as.web.session.ClusteredSession.acquireSessionOwnership(ClusteredSession.java:520) [jboss-as-web-7.1.2.Final-SNAPSHOT.jar:7.1.2.Final-SNAPSHOT]
> 	... 23 more
> {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

From issues at jboss.org  Mon Mar 24 07:05:13 2014
From: issues at jboss.org (Mario Fusco (JIRA))
Date: Mon, 24 Mar 2014 07:05:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-447) Deadlock when marshalling
 session using WM listeners and fireUntilHalt
In-Reply-To: <JIRA.12534037.1393964199000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534037.1393964199000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534037.1393964199000.897.1395659113165@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-447?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mario Fusco reassigned DROOLS-447:
----------------------------------

    Assignee: Mario Fusco  (was: Edson Tirelli)

    
> Deadlock when marshalling session using WM listeners and fireUntilHalt
> ----------------------------------------------------------------------
>
>                 Key: DROOLS-447
>                 URL: https://issues.jboss.org/browse/DROOLS-447
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 6.0.1.Final, 6.1.0.Beta1
>            Reporter: Davide Sottara
>            Assignee: Mario Fusco
>             Fix For: 6.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

From issues at jboss.org  Mon Mar 24 07:09:14 2014
From: issues at jboss.org (Mario Fusco (JIRA))
Date: Mon, 24 Mar 2014 07:09:14 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-447) Deadlock when marshalling
 session using WM listeners and fireUntilHalt
In-Reply-To: <JIRA.12534037.1393964199000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534037.1393964199000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534037.1393964199000.929.1395659354600@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-447?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mario Fusco resolved DROOLS-447.
--------------------------------

    Resolution: Won't Fix


Invoking fireX inside an event is a bad practice and should be always avoided. In particular, since at the moment some WM events callback are invoked while holding locks on the WM, trying to execute any write operation of the WM itself can inevitably lead to a deadlock.
                
> Deadlock when marshalling session using WM listeners and fireUntilHalt
> ----------------------------------------------------------------------
>
>                 Key: DROOLS-447
>                 URL: https://issues.jboss.org/browse/DROOLS-447
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 6.0.1.Final, 6.1.0.Beta1
>            Reporter: Davide Sottara
>            Assignee: Mario Fusco
>             Fix For: 6.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

From issues at jboss.org  Mon Mar 24 07:17:13 2014
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Mon, 24 Mar 2014 07:17:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2957) Refactor the SSL services
 within the security realms so that key and trust managers are injected
 instead of stores.
In-Reply-To: <JIRA.12532525.1392731377000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12532525.1392731377000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12532525.1392731377000.948.1395659833089@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2957?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse resolved WFLY-2957.
------------------------------------

    Resolution: Done

    
> Refactor the SSL services within the security realms so that key and trust managers are injected instead of stores.
> -------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2957
>                 URL: https://issues.jboss.org/browse/WFLY-2957
>             Project: WildFly
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management, Security
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>            Priority: Critical
>             Fix For: 8.0.1.Final
>
>
> To cope with things like being able to reload trust stores after files have been modified some implementation details regarding file handling have leaked slightly into the SSLIdentityService which represents the servers identity - instead the key and trust manager instances should be injected.

--
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

From issues at jboss.org  Mon Mar 24 07:19:13 2014
From: issues at jboss.org (Tomaz Cerar (JIRA))
Date: Mon, 24 Mar 2014 07:19:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (AS7-4260) Occurences of "Exception
 acquiring ownership of X (via SharedLocalYieldingClusterLockManager)"
In-Reply-To: <JIRA.12462250.1332424552000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12462250.1332424552000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12462250.1332424552000.964.1395659953446@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/AS7-4260?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12955468#comment-12955468 ] 

Tomaz Cerar commented on AS7-4260:
----------------------------------

[~vishalkumar375] so upgrade to newer version that has this fixed.
                
> Occurences of "Exception acquiring ownership of X (via SharedLocalYieldingClusterLockManager)"
> ----------------------------------------------------------------------------------------------
>
>                 Key: AS7-4260
>                 URL: https://issues.jboss.org/browse/AS7-4260
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Clustering
>    Affects Versions: 7.1.1.Final
>            Reporter: Radoslav Husar
>            Assignee: Paul Ferraro
>              Labels: JBAS018080, as713tracking
>             Fix For: 7.1.3.Final (EAP), EAP 6.1.0.Alpha (7.2.0.Final)
>
>         Attachments: SessionTravel.gif, view-perf18.log, view-perf19.log, view-perf20.log, view-perf21.log
>
>
> There are often occurrences of "Exception acquiring ownership of X":
> During shutdown, using dist:
> {noformat}
> 13:09:28,290 WARN  [org.apache.catalina.session.ManagerBase] (ContainerBackgroundProcessor[StandardEngine[jboss.web]]) JBAS018080: Standard expiration of session qLQps+CQJxEi6pJTBSzis0g3 failed; switching to a brute force cleanup. Problem is JBAS018060: Exception acquiring ownership of qLQps+CQJxEi6pJTBSzis0g3
> {noformat}
> During server crash, using repl:
> {noformat}
> 12:55:49,556 INFO  [org.jboss.as.clustering.impl.CoreGroupCommunicationService.ejb] (Incoming-2,null) JBAS010248: New cluster view for partition ejb: 6 (org.jboss.as.clustering.impl.CoreGroupCommunicationService$GroupView at 327579f6 delta: -1, merge: false)
> 12:55:49,557 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (Incoming-2,null) ISPN000094: Received new cluster view: [perf21/ejb|6] [perf21/ejb, perf20/ejb, perf18/ejb]
> 12:56:31,694 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[default-host]] (ajp-perf20-10.16.90.58-8009-211) Exception sending request initialized lifecycle event to listener instance of class org.jboss.weld.servlet.WeldListener: java.lang.RuntimeException: JBAS018060: Exception acquiring ownership of MvwC8KGWTuKPjD1-JjLW7URZ
> 	at org.jboss.as.web.session.ClusteredSession.acquireSessionOwnership(ClusteredSession.java:528) [jboss-as-web-7.1.2.Final-SNAPSHOT.jar:7.1.2.Final-SNAPSHOT]
> 	at org.jboss.as.web.session.ClusteredSession.expire(ClusteredSession.java:1260) [jboss-as-web-7.1.2.Final-SNAPSHOT.jar:7.1.2.Final-SNAPSHOT]
> 	at org.jboss.as.web.session.ClusteredSession.isValid(ClusteredSession.java:1208) [jboss-as-web-7.1.2.Final-SNAPSHOT.jar:7.1.2.Final-SNAPSHOT]
> 	at org.jboss.as.web.session.ClusteredSession.isValid(ClusteredSession.java:598) [jboss-as-web-7.1.2.Final-SNAPSHOT.jar:7.1.2.Final-SNAPSHOT]
> 	at org.jboss.as.web.session.DistributableSessionManager.add(DistributableSessionManager.java:917) [jboss-as-web-7.1.2.Final-SNAPSHOT.jar:7.1.2.Final-SNAPSHOT]
> 	at org.jboss.as.web.session.DistributableSessionManager.loadSession(DistributableSessionManager.java:1407) [jboss-as-web-7.1.2.Final-SNAPSHOT.jar:7.1.2.Final-SNAPSHOT]
> 	at org.jboss.as.web.session.DistributableSessionManager.findSession(DistributableSessionManager.java:686) [jboss-as-web-7.1.2.Final-SNAPSHOT.jar:7.1.2.Final-SNAPSHOT]
> 	at org.jboss.as.web.session.DistributableSessionManager.findSession(DistributableSessionManager.java:85) [jboss-as-web-7.1.2.Final-SNAPSHOT.jar:7.1.2.Final-SNAPSHOT]
> 	at org.apache.catalina.connector.Request.doGetSession(Request.java:2618) [jbossweb-7.0.13.Final.jar:]
> 	at org.apache.catalina.connector.Request.getSession(Request.java:2375) [jbossweb-7.0.13.Final.jar:]
> 	at org.apache.catalina.connector.RequestFacade.getSession(RequestFacade.java:841) [jbossweb-7.0.13.Final.jar:]
> 	at org.jboss.weld.context.beanstore.http.LazySessionBeanStore.getSession(LazySessionBeanStore.java:72) [weld-core-1.1.5.AS71.Final.jar:2012-02-10 15:31]
> 	at org.jboss.weld.context.beanstore.http.LazySessionBeanStore.<init>(LazySessionBeanStore.java:58) [weld-core-1.1.5.AS71.Final.jar:2012-02-10 15:31]
> 	at org.jboss.weld.context.http.HttpSessionContextImpl.associate(HttpSessionContextImpl.java:31) [weld-core-1.1.5.AS71.Final.jar:2012-02-10 15:31]
> 	at org.jboss.weld.context.http.HttpSessionContextImpl.associate(HttpSessionContextImpl.java:16) [weld-core-1.1.5.AS71.Final.jar:2012-02-10 15:31]
> 	at org.jboss.weld.servlet.WeldListener.requestInitialized(WeldListener.java:134) [weld-core-1.1.5.AS71.Final.jar:2012-02-10 15:31]
> 	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:143) [jbossweb-7.0.13.Final.jar:]
> 	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) [jbossweb-7.0.13.Final.jar:]
> 	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) [jbossweb-7.0.13.Final.jar:]
> 	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:368) [jbossweb-7.0.13.Final.jar:]
> 	at org.apache.coyote.ajp.AjpProcessor.process(AjpProcessor.java:505) [jbossweb-7.0.13.Final.jar:]
> 	at org.apache.coyote.ajp.AjpProtocol$AjpConnectionHandler.process(AjpProtocol.java:445) [jbossweb-7.0.13.Final.jar:]
> 	at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:930) [jbossweb-7.0.13.Final.jar:]
> 	at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_30]
> Caused by: org.jboss.as.clustering.lock.TimeoutException: JBAS010223: Cannot acquire lock //default-host//clusterbench/MvwC8KGWTuKPjD1-JjLW7URZ from cluster
> 	at org.jboss.as.clustering.lock.SharedLocalYieldingClusterLockManager.lock(SharedLocalYieldingClusterLockManager.java:439)
> 	at org.jboss.as.clustering.web.infinispan.DistributedCacheManager.acquireSessionOwnership(DistributedCacheManager.java:372)
> 	at org.jboss.as.web.session.ClusteredSession.acquireSessionOwnership(ClusteredSession.java:520) [jboss-as-web-7.1.2.Final-SNAPSHOT.jar:7.1.2.Final-SNAPSHOT]
> 	... 23 more
> {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

From issues at jboss.org  Mon Mar 24 07:25:13 2014
From: issues at jboss.org (Peter Skopek (JIRA))
Date: Mon, 24 Mar 2014 07:25:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (SECURITY-805) Overload
 SecurityVaultFactory.get() to be able to specify the classloader
In-Reply-To: <JIRA.12535004.1394795116000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12535004.1394795116000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12535004.1394795116000.974.1395660313221@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/SECURITY-805?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Peter Skopek resolved SECURITY-805.
-----------------------------------

    Fix Version/s: PicketBox_4_0_21.Beta2
       Resolution: Done

    
> Overload SecurityVaultFactory.get() to be able to specify the classloader
> -------------------------------------------------------------------------
>
>                 Key: SECURITY-805
>                 URL: https://issues.jboss.org/browse/SECURITY-805
>             Project: PicketBox 
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>            Reporter: Kabir Khan
>            Assignee: Kabir Khan
>             Fix For: PicketBox_4_0_21.Beta2
>
>         Attachments: SECURITY-805-2.diff, SECURITY-805.diff
>
>
> To work better with modular class loading in WF

--
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

From issues at jboss.org  Mon Mar 24 07:29:13 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 24 Mar 2014 07:29:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-439) Package builder unable to
 find declared array class
In-Reply-To: <JIRA.12533030.1393157795000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12533030.1393157795000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12533030.1393157795000.979.1395660553516@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-439?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated DROOLS-439:
-------------------------------------------

        Bugzilla Update: Perform
    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1079950

    
> Package builder unable to find declared array class
> ---------------------------------------------------
>
>                 Key: DROOLS-439
>                 URL: https://issues.jboss.org/browse/DROOLS-439
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 6.0.1.Final
>            Reporter: Mark Sullivan
>            Assignee: Mark Proctor
>
> When declaring a fact type with an array field, where the array type is declared in the same package, for example:
> {code}
> declare Owner
>   name : String
> end
> declare Pet
>   owners : Owner[]
> end
> {code}
> The following build error occurs:
> {code}
> [Message [id=1, level=ERROR, path=pets.drl, line=5, column=0
>    text=Unable to find class 'Owner']]
> {code}
> This error doesn't always occur when an array field is declared. It's dependent on the order in which each fact type is processed. 
> PackageBuilder attempts to order fact types for processing based on the declared super type and attribute types.
> The following loop in *PackageBuilder.sortByHierarchy()* processes each field looking for field type dependencies: 
> {code}
>   for (TypeFieldDescr field : tdescr.getFields().values()) {
>     QualifiedName typeName = new QualifiedName(field.getPattern().getObjectType());
>     if (!hasCircularDependency(name, typeName, taxonomy)) {
>       supers.add(typeName);
>     }
>   }
> {code}
> However I don't think it correctly spots the dependency when the field type is an array.
> This issue can be worked around by declaring an unused field of the same type as the array:
> {code}
> declare Owner
>   name : String
> end
> declare Pet
>   owners : Owner[]
>   _unused: Owner
> end
> {code}

--
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

From issues at jboss.org  Mon Mar 24 07:29:13 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 24 Mar 2014 07:29:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-439) Package builder unable to
 find declared array class
In-Reply-To: <JIRA.12533030.1393157795000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12533030.1393157795000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12533030.1393157795000.984.1395660553749@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/DROOLS-439?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12955472#comment-12955472 ] 

RH Bugzilla Integration commented on DROOLS-439:
------------------------------------------------

Mario Fusco <mfusco at redhat.com> changed the Status of [bug 1079950|https://bugzilla.redhat.com/show_bug.cgi?id=1079950] from NEW to ASSIGNED
                
> Package builder unable to find declared array class
> ---------------------------------------------------
>
>                 Key: DROOLS-439
>                 URL: https://issues.jboss.org/browse/DROOLS-439
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 6.0.1.Final
>            Reporter: Mark Sullivan
>            Assignee: Mark Proctor
>
> When declaring a fact type with an array field, where the array type is declared in the same package, for example:
> {code}
> declare Owner
>   name : String
> end
> declare Pet
>   owners : Owner[]
> end
> {code}
> The following build error occurs:
> {code}
> [Message [id=1, level=ERROR, path=pets.drl, line=5, column=0
>    text=Unable to find class 'Owner']]
> {code}
> This error doesn't always occur when an array field is declared. It's dependent on the order in which each fact type is processed. 
> PackageBuilder attempts to order fact types for processing based on the declared super type and attribute types.
> The following loop in *PackageBuilder.sortByHierarchy()* processes each field looking for field type dependencies: 
> {code}
>   for (TypeFieldDescr field : tdescr.getFields().values()) {
>     QualifiedName typeName = new QualifiedName(field.getPattern().getObjectType());
>     if (!hasCircularDependency(name, typeName, taxonomy)) {
>       supers.add(typeName);
>     }
>   }
> {code}
> However I don't think it correctly spots the dependency when the field type is an array.
> This issue can be worked around by declaring an unused field of the same type as the array:
> {code}
> declare Owner
>   name : String
> end
> declare Pet
>   owners : Owner[]
>   _unused: Owner
> end
> {code}

--
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

From issues at jboss.org  Mon Mar 24 07:31:13 2014
From: issues at jboss.org (Mario Fusco (JIRA))
Date: Mon, 24 Mar 2014 07:31:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-439) Package builder unable to
 find declared array class
In-Reply-To: <JIRA.12533030.1393157795000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12533030.1393157795000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12533030.1393157795000.989.1395660673093@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-439?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mario Fusco reassigned DROOLS-439:
----------------------------------

    Assignee: Mario Fusco  (was: Mark Proctor)

    
> Package builder unable to find declared array class
> ---------------------------------------------------
>
>                 Key: DROOLS-439
>                 URL: https://issues.jboss.org/browse/DROOLS-439
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 6.0.1.Final
>            Reporter: Mark Sullivan
>            Assignee: Mario Fusco
>
> When declaring a fact type with an array field, where the array type is declared in the same package, for example:
> {code}
> declare Owner
>   name : String
> end
> declare Pet
>   owners : Owner[]
> end
> {code}
> The following build error occurs:
> {code}
> [Message [id=1, level=ERROR, path=pets.drl, line=5, column=0
>    text=Unable to find class 'Owner']]
> {code}
> This error doesn't always occur when an array field is declared. It's dependent on the order in which each fact type is processed. 
> PackageBuilder attempts to order fact types for processing based on the declared super type and attribute types.
> The following loop in *PackageBuilder.sortByHierarchy()* processes each field looking for field type dependencies: 
> {code}
>   for (TypeFieldDescr field : tdescr.getFields().values()) {
>     QualifiedName typeName = new QualifiedName(field.getPattern().getObjectType());
>     if (!hasCircularDependency(name, typeName, taxonomy)) {
>       supers.add(typeName);
>     }
>   }
> {code}
> However I don't think it correctly spots the dependency when the field type is an array.
> This issue can be worked around by declaring an unused field of the same type as the array:
> {code}
> declare Owner
>   name : String
> end
> declare Pet
>   owners : Owner[]
>   _unused: Owner
> end
> {code}

--
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

From issues at jboss.org  Mon Mar 24 07:31:13 2014
From: issues at jboss.org (Mario Fusco (JIRA))
Date: Mon, 24 Mar 2014 07:31:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-439) Package builder unable to
 find declared array class
In-Reply-To: <JIRA.12533030.1393157795000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12533030.1393157795000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12533030.1393157795000.996.1395660673445@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-439?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mario Fusco resolved DROOLS-439.
--------------------------------

    Resolution: Done

    
> Package builder unable to find declared array class
> ---------------------------------------------------
>
>                 Key: DROOLS-439
>                 URL: https://issues.jboss.org/browse/DROOLS-439
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 6.0.1.Final
>            Reporter: Mark Sullivan
>            Assignee: Mario Fusco
>
> When declaring a fact type with an array field, where the array type is declared in the same package, for example:
> {code}
> declare Owner
>   name : String
> end
> declare Pet
>   owners : Owner[]
> end
> {code}
> The following build error occurs:
> {code}
> [Message [id=1, level=ERROR, path=pets.drl, line=5, column=0
>    text=Unable to find class 'Owner']]
> {code}
> This error doesn't always occur when an array field is declared. It's dependent on the order in which each fact type is processed. 
> PackageBuilder attempts to order fact types for processing based on the declared super type and attribute types.
> The following loop in *PackageBuilder.sortByHierarchy()* processes each field looking for field type dependencies: 
> {code}
>   for (TypeFieldDescr field : tdescr.getFields().values()) {
>     QualifiedName typeName = new QualifiedName(field.getPattern().getObjectType());
>     if (!hasCircularDependency(name, typeName, taxonomy)) {
>       supers.add(typeName);
>     }
>   }
> {code}
> However I don't think it correctly spots the dependency when the field type is an array.
> This issue can be worked around by declaring an unused field of the same type as the array:
> {code}
> declare Owner
>   name : String
> end
> declare Pet
>   owners : Owner[]
>   _unused: Owner
> end
> {code}

--
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

From issues at jboss.org  Mon Mar 24 07:31:13 2014
From: issues at jboss.org (Peter Skopek (JIRA))
Date: Mon, 24 Mar 2014 07:31:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (SECURITY-805) Overload
 SecurityVaultFactory.get() to be able to specify the classloader
In-Reply-To: <JIRA.12535004.1394795116000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12535004.1394795116000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12535004.1394795116000.999.1395660673586@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/SECURITY-805?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Peter Skopek updated SECURITY-805:
----------------------------------

    Fix Version/s: PicketBox_4_0_19.SP5

    
> Overload SecurityVaultFactory.get() to be able to specify the classloader
> -------------------------------------------------------------------------
>
>                 Key: SECURITY-805
>                 URL: https://issues.jboss.org/browse/SECURITY-805
>             Project: PicketBox 
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>            Reporter: Kabir Khan
>            Assignee: Kabir Khan
>             Fix For: PicketBox_4_0_21.Beta2, PicketBox_4_0_19.SP5
>
>         Attachments: SECURITY-805-2.diff, SECURITY-805.diff
>
>
> To work better with modular class loading in WF

--
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

From issues at jboss.org  Mon Mar 24 07:37:12 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 24 Mar 2014 07:37:12 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-436) Cannot access to remote kie
 maven repository - Access denied
In-Reply-To: <JIRA.12532528.1392732984000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12532528.1392732984000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12532528.1392732984000.1023.1395661032987@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-436?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated DROOLS-436:
-------------------------------------------

        Bugzilla Update: Perform
    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1059584

    
> Cannot access to remote kie maven repository - Access denied
> ------------------------------------------------------------
>
>                 Key: DROOLS-436
>                 URL: https://issues.jboss.org/browse/DROOLS-436
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 6.0.1.Final
>         Environment: - Windows 7 64 bits
> - JDK 1.7.0.45
> - Drools 6.0.1.Final
>            Reporter: Rog?rio Disciolli
>            Assignee: Mark Proctor
>
> - Start JBPM 6.0.1.Final binding a specific IP 192.168.0.10
> - Run maven in a remote machine with the pom.xml like this
> <repository>
>   <id>guvnor-m2-repo</id>
>   <name>Guvnor M2 Repo</name>
>   <url>http://192.168.0.10:8080/jbpm-console/maven2/</url>
> </repository>
> Also having username/password in ~/.m2/settings.xml
>   <servers>
>     <server>
>       <id>guvnor-m2-repo</id>
>       <username>admin</username>
>       <password>admin</password>
>     </server>
>   </servers>
> And returned "Access denied (401)" when try get maven-metadata.xml from project.
> Can not authenticate at kie maven repository.
> The same happens when try run Java Project with VM arguments "-Dkie.maven.settings.custom=settings.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


From issues at jboss.org  Mon Mar 24 07:37:13 2014
From: issues at jboss.org (Mario Fusco (JIRA))
Date: Mon, 24 Mar 2014 07:37:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-436) Cannot access to remote kie
 maven repository - Access denied
In-Reply-To: <JIRA.12532528.1392732984000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12532528.1392732984000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12532528.1392732984000.1028.1395661033266@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-436?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mario Fusco reassigned DROOLS-436:
----------------------------------

    Assignee: Mario Fusco  (was: Mark Proctor)

    
> Cannot access to remote kie maven repository - Access denied
> ------------------------------------------------------------
>
>                 Key: DROOLS-436
>                 URL: https://issues.jboss.org/browse/DROOLS-436
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 6.0.1.Final
>         Environment: - Windows 7 64 bits
> - JDK 1.7.0.45
> - Drools 6.0.1.Final
>            Reporter: Rog?rio Disciolli
>            Assignee: Mario Fusco
>
> - Start JBPM 6.0.1.Final binding a specific IP 192.168.0.10
> - Run maven in a remote machine with the pom.xml like this
> <repository>
>   <id>guvnor-m2-repo</id>
>   <name>Guvnor M2 Repo</name>
>   <url>http://192.168.0.10:8080/jbpm-console/maven2/</url>
> </repository>
> Also having username/password in ~/.m2/settings.xml
>   <servers>
>     <server>
>       <id>guvnor-m2-repo</id>
>       <username>admin</username>
>       <password>admin</password>
>     </server>
>   </servers>
> And returned "Access denied (401)" when try get maven-metadata.xml from project.
> Can not authenticate at kie maven repository.
> The same happens when try run Java Project with VM arguments "-Dkie.maven.settings.custom=settings.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


From issues at jboss.org  Mon Mar 24 07:39:12 2014
From: issues at jboss.org (Mario Fusco (JIRA))
Date: Mon, 24 Mar 2014 07:39:12 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-436) Cannot access to remote kie
 maven repository - Access denied
In-Reply-To: <JIRA.12532528.1392732984000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12532528.1392732984000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12532528.1392732984000.1031.1395661152975@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-436?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mario Fusco resolved DROOLS-436.
--------------------------------

    Resolution: Rejected


This is not a bug. See the linked bugzilla ticket explaining how to resolve this problem
                
> Cannot access to remote kie maven repository - Access denied
> ------------------------------------------------------------
>
>                 Key: DROOLS-436
>                 URL: https://issues.jboss.org/browse/DROOLS-436
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 6.0.1.Final
>         Environment: - Windows 7 64 bits
> - JDK 1.7.0.45
> - Drools 6.0.1.Final
>            Reporter: Rog?rio Disciolli
>            Assignee: Mario Fusco
>
> - Start JBPM 6.0.1.Final binding a specific IP 192.168.0.10
> - Run maven in a remote machine with the pom.xml like this
> <repository>
>   <id>guvnor-m2-repo</id>
>   <name>Guvnor M2 Repo</name>
>   <url>http://192.168.0.10:8080/jbpm-console/maven2/</url>
> </repository>
> Also having username/password in ~/.m2/settings.xml
>   <servers>
>     <server>
>       <id>guvnor-m2-repo</id>
>       <username>admin</username>
>       <password>admin</password>
>     </server>
>   </servers>
> And returned "Access denied (401)" when try get maven-metadata.xml from project.
> Can not authenticate at kie maven repository.
> The same happens when try run Java Project with VM arguments "-Dkie.maven.settings.custom=settings.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


From issues at jboss.org  Mon Mar 24 07:41:14 2014
From: issues at jboss.org (Mario Fusco (JIRA))
Date: Mon, 24 Mar 2014 07:41:14 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-429)
 StatefulKnowledgeSession.fireAllRules(AgendaFilter a) and
 StatefulKnowledgeSession.fireAllRules(new
 RuleNameMatchesAgendaFilter("Rule")) are not working in the version drools
 6.0.0 and 6.0.1 which was working in 5.x.It throws
 UnsupportedOperationException
In-Reply-To: <JIRA.12532219.1392386882000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12532219.1392386882000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12532219.1392386882000.1048.1395661274304@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-429?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mario Fusco reassigned DROOLS-429:
----------------------------------

    Assignee: Mario Fusco  (was: Mark Proctor)

    
> StatefulKnowledgeSession.fireAllRules(AgendaFilter a) and StatefulKnowledgeSession.fireAllRules(new RuleNameMatchesAgendaFilter("Rule")) are not working in the version drools 6.0.0 and 6.0.1 which was working in 5.x.It throws UnsupportedOperationException
> ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: DROOLS-429
>                 URL: https://issues.jboss.org/browse/DROOLS-429
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 6.0.0.Final, 6.0.1.Final
>            Reporter: Revathi P
>            Assignee: Mario Fusco
>              Labels: jboss
>             Fix For: 6.0.0.Final, 6.0.1.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

From issues at jboss.org  Mon Mar 24 07:41:14 2014
From: issues at jboss.org (Mario Fusco (JIRA))
Date: Mon, 24 Mar 2014 07:41:14 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-429)
 StatefulKnowledgeSession.fireAllRules(AgendaFilter a) and
 StatefulKnowledgeSession.fireAllRules(new
 RuleNameMatchesAgendaFilter("Rule")) are not working in the version drools
 6.0.0 and 6.0.1 which was working in 5.x.It throws
 UnsupportedOperationException
In-Reply-To: <JIRA.12532219.1392386882000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12532219.1392386882000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12532219.1392386882000.1054.1395661274654@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-429?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mario Fusco resolved DROOLS-429.
--------------------------------

    Resolution: Done

    
> StatefulKnowledgeSession.fireAllRules(AgendaFilter a) and StatefulKnowledgeSession.fireAllRules(new RuleNameMatchesAgendaFilter("Rule")) are not working in the version drools 6.0.0 and 6.0.1 which was working in 5.x.It throws UnsupportedOperationException
> ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: DROOLS-429
>                 URL: https://issues.jboss.org/browse/DROOLS-429
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 6.0.0.Final, 6.0.1.Final
>            Reporter: Revathi P
>            Assignee: Mario Fusco
>              Labels: jboss
>             Fix For: 6.0.1.Final, 6.0.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

From issues at jboss.org  Mon Mar 24 07:43:13 2014
From: issues at jboss.org (Mario Fusco (JIRA))
Date: Mon, 24 Mar 2014 07:43:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-419) "Cannot find KieModule" with
 kieServices.newKieContainer() with LATEST or RELEASE instead of explicit
 version number (eg: 0.0.1) on a application where the KIE module Rule
 artifact project kjar has been locally-installed from remote Maven
 repository.
In-Reply-To: <JIRA.12530799.1391109809000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530799.1391109809000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530799.1391109809000.1062.1395661393138@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-419?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mario Fusco resolved DROOLS-419.
--------------------------------

    Resolution: Done

    
> "Cannot find KieModule" with kieServices.newKieContainer() with LATEST or RELEASE instead of explicit version number (eg: 0.0.1) on a application where the KIE module Rule artifact project kjar has been locally-installed from remote Maven repository.
> ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: DROOLS-419
>                 URL: https://issues.jboss.org/browse/DROOLS-419
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 6.0.1.Final
>         Environment: Right hand side of diagram at http://docs.jboss.org/drools/release/6.0.1.Final/drools-docs/html_single/#d0e933
>            Reporter: Matteo Mortari
>            Assignee: Mario Fusco
>            Priority: Minor
>         Attachments: 20140130.drools6testmvnlatest.zip
>
>
> Hello, this is to report (potentially) a bug about "Cannot find KieModule: com.acme:X:RELEASE" or "Cannot find KieModule: com.acme:X:LATEST" when invoking {{kieServices.newKieContainer( releaseId )}} with LATEST or RELEASE instead of explicit version number (eg: 0.0.1) on a application where the KIE module Rule artifact project kjar has been locally-installed from remote Maven repository.
> More precisely, with reference to http://docs.jboss.org/drools/release/6.0.1.Final/drools-docs/html_single/#d0e933 , I mean that before launching Application, I performed 
> {code}
> mvn org.apache.maven.plugins:maven-dependency-plugin:2.8:get -Dartifact=com.acme:drools6testmvnlatest.therules:LATEST -DrepoUrl=http://nexus-hostname/nexus/content/repositories/releases/
> {code}
> h5. Disclaimer
> I'm not 100% sure whether this is bug of maven process, maven libraries, or Drools library; I prefer to report it anyway because likely could impact other users if installing via the maven-dependency-plugin:get goal, especially in distributed or JavaEE deployments? Sorry if actually not Drools library bug, I report all details below, *including current workaround* I have found to avoid this issue.
> h5. DETAILS
> Suppose there is a kjar artifact KIE module, {{'drools6testmvnlatest.therules'}}, as per attached project zip file. And this artifact is installed in local nexus repository at http://nexus-hostname/nexus/content/repositories/releases/ .
> Now ,suppose with reference to http://docs.jboss.org/drools/release/6.0.1.Final/drools-docs/html_single/#d0e933 , _Application_ is jar {{'drools6testmvnlatest.thestandaloneengine'}} as per attached project zip file, and is being executed on a dedicate machine, not the development computers.
> {code:title=App.java}
> public static void main( String[] args ) {
> 	KieServices kieServices = KieServices.Factory.get();
> 	ReleaseId releaseId = kieServices.newReleaseId( "com.acme", "drools6testmvnlatest.therules", args[0] );
> 	KieContainer kContainer = kieServices.newKieContainer( releaseId );
> 	KieBaseConfiguration kieBaseConf = kieServices.newKieBaseConfiguration();
> 	kieBaseConf.setOption( EventProcessingOption.STREAM );
> 	KieBase kBase = kContainer.newKieBase(kieBaseConf);
> 	for ( KiePackage a : kBase.getKiePackages()) {
> 			for (Rule r : a.getRules()) {
> 				logger.info("KiePackage {} Rule {}", new Object[]{a.getName(), r.getName()});
> 			}
> 	}
> }
> {code}
> The first thing to do before executing it, would be to fetch and install into local .m2 repository the required KIE module Rule artifact project kjar {{'drools6testmvnlatest.therules'}}. To do so, the following command is executed:
> {code}
> mvn org.apache.maven.plugins:maven-dependency-plugin:2.8:get -Dartifact=com.acme:drools6testmvnlatest.therules:LATEST -DrepoUrl=http://nexus-hostname/nexus/content/repositories/releases/
> {code}
> Execution of
> {code}
> java -jar drools6testmvnlatest.thestandaloneengine-jar-with-dependencies.jar RELEASE
> {code}
> Would generate the following stack trace
> {code}
> Exception in thread "main" java.lang.RuntimeException: Cannot find KieModule: com.acme:drools6testmvnlatest.therules:RELEASE
>         at org.drools.compiler.kie.builder.impl.KieServicesImpl.newKieContainer(KieServicesImpl.java:86)
>         at com.acme.drools6testmvnlatest.thestandaloneengine.App.main(App.java:24)
> {code}
> Same for LATEST as launch parameter.
> But fixed version, eg: 0.0.2 as launch parameter, will work.
> {code}
> D:\inbox>java -jar drools6testmvnlatest.thestandaloneengine-jar-with-dependencies.jar 0.0.2
> 2014-01-30 19:24:12,128 [main] INFO  org.drools.compiler.kie.builder.impl.KieRepositoryImpl - KieModule was added:ZipKieModule[ ReleaseId=com.acme:drools6testmvnlatest.therules:0.0.2file=D:\Documents and Settings\mmortari\.m2\repository\com\acme\drools6testmvnlatest.therules\0.0.2\drools6testmvnlatest.therules-0.0.2.jar]
> 2014-01-30 19:24:12,440 [main] INFO  com.acme.drools6testmvnlatest.thestandaloneengine.App - KiePackage com.acme.drools6testmvnlatest.therules Rule Dummy rule on String
> {code}
> Please notice at this point this is the content of the .m2 local repository (this led me to discover the workaround)
> {code}
> D:\DOCUMENTS AND SETTINGS\MMORTARI\.M2\REPOSITORY\COM\ACME
> ????drools6testmvnlatest.therules
>     ?   maven-metadata-nexus-hostname-nexus.xml
>     ?   maven-metadata-nexus-hostname-nexus.xml.sha1
>     ?   maven-metadata-temp.xml
>     ?   maven-metadata-temp.xml.sha1
>     ?   resolver-status.properties
>     ?
>     ????0.0.2
>             drools6testmvnlatest.therules-0.0.2.jar
>             drools6testmvnlatest.therules-0.0.2.jar.sha1
>             drools6testmvnlatest.therules-0.0.2.pom
>             drools6testmvnlatest.therules-0.0.2.pom.sha1
>             _remote.repositories
> {code}
> h5. WORKAROUND
> The only options 1-2-3 ways I found to avoid this issue, and be able to launch successfully with RELEASE or LATEST as the launch parameter for the ReleaseId version, is to:
> h6. Workaround Option 1
> Do 'fake' a pom.xml with the dependency, something similar to:
> {code}
> <project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
>   <modelVersion>4.0.0</modelVersion>
>   <groupId>com.acme</groupId>
>   <artifactId>fakepom</artifactId>
>   <version>0.0.1</version>
>   <packaging>jar</packaging>
>   <dependencies>
>     <dependency>
>       <groupId>com.acme</groupId>
>       <artifactId>drools6testmvnlatest.therules</artifactId>
>       <version>RELEASE</version>
>     </dependency>
>   </dependencies>
>   
> </project>
> {code}
> And then launch maven in the same directory of this 'fake' pom.xml with the following command:
> {code}
> mvn org.apache.maven.plugins:maven-dependency-plugin:2.8:go-offline 
> {code}
> This usually generate the 'maven-metadata-local' file in the local .m2 repo:
> {code}
> D:\DOCUMENTS AND SETTINGS\MMORTARI\.M2\REPOSITORY\COM\ACME
> ????drools6testmvnlatest.therules
>     ?   maven-metadata-nexus-hostname-nexus.xml
>     ?   maven-metadata-nexus-hostname-nexus.xml.sha1
>     ?   maven-metadata-local.xml
>     ?   maven-metadata-local.xml.sha1
>     ?   maven-metadata-temp.xml
>     ?   maven-metadata-temp.xml.sha1
>     ?   resolver-status.properties
>     ?
>     ????0.0.2
>             drools6testmvnlatest.therules-0.0.2.jar
>             drools6testmvnlatest.therules-0.0.2.jar.sha1
>             drools6testmvnlatest.therules-0.0.2.pom
>             drools6testmvnlatest.therules-0.0.2.pom.sha1
>             _remote.repositories
> {code}
> h6. Workaround Option2
> Well, actually this is to report that not all the time the Option1 works, so what I do, is that I copy-rename the 'maven-metadata-temp.xml' file into the 'maven-metadata-local.xml' file.
> h6. Workaround Option3
> Download manually the .jar file, the .pom file from the nexus webapplication, then usual maven 
> {code}
> D:\inbox>mvn install:install-file -Dfile=drools6testmvnlatest.therules-0.0.2.jar -DpomFile=drools6testmvnlatest.therules-0.0.2.pom -Dpackaging=jar
> {code}
> This will create directly the 'maven-metadata-local.xml' file and the ' -Dpackaging=jar' option do force it to install it in the .m2 local repository with .jar extension (not kjar)
> {code}
> D:\DOCUMENTS AND SETTINGS\MMORTARI\.M2\REPOSITORY\COM\ACME
> ????drools6testmvnlatest.therules
>     ?   maven-metadata-local.xml
>     ?
>     ????0.0.2
>             drools6testmvnlatest.therules-0.0.2.jar
>             drools6testmvnlatest.therules-0.0.2.pom
>             _remote.repositories
> {code}

--
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


From issues at jboss.org  Mon Mar 24 08:51:13 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 24 Mar 2014 08:51:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1547) deploy directories not
	cleaned up
In-Reply-To: <JIRA.12479851.1353935247000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12479851.1353935247000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12479851.1353935247000.1290.1395665473253@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1547?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12955514#comment-12955514 ] 

RH Bugzilla Integration commented on WFLY-1547:
-----------------------------------------------

Petr Kremensky <pkremens at redhat.com> changed the Status of [bug 901210|https://bugzilla.redhat.com/show_bug.cgi?id=901210] from ON_QA to VERIFIED
                
> deploy directories not cleaned up
> ---------------------------------
>
>                 Key: WFLY-1547
>                 URL: https://issues.jboss.org/browse/WFLY-1547
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 8.0.0.Alpha1
>            Reporter: Shaun Appleton
>            Assignee: jaikiran pai
>             Fix For: 8.0.0.Beta1
>
>         Attachments: deployment_with_hack_no_hook.txt
>
>
> JBoss EAP 6.0.0 (and 6.0.1.ER3) doesn't clean up it's tmp/vfs directories.
> The following reproduces this -
> i) ensure run.conf has the -Xrs set
> ii) ensure deployments has a deployable .ear in it
> iii) ./run standalone.sh and allow the deployments to deploy
> iv) stop the EAP process ie kill <process_id>
> v) observe content tmp/vfs
> (The -Xrs parameter is used to "-Xrs" to prevent possible interference when JVM is running as a service and receives CTRL_LOGOFF_EVENT or SIGHUP)
> This will eventually cause problems with lack of disk space.
> Note if the -Xrs parameter content is removed but the tmp/vfs dirs stills exist. This could potentially cause inode problems.
> It would be better if there were any additional code so the temp dirs are cleaned up on start up. That would resolve both the -Xrs problem and the excessive dir creation.

--
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

From issues at jboss.org  Mon Mar 24 08:54:02 2014
From: issues at jboss.org (Maxim Frolov (JIRA))
Date: Mon, 24 Mar 2014 08:54:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3147)
 spec-descriptor-property-replacement causes NPE while parsing exclude
 element in beans.xml
In-Reply-To: <JIRA.12535673.1395399376000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12535673.1395399376000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12535673.1395399376000.1305.1395665642658@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-3147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12955516#comment-12955516 ] 

Maxim Frolov commented on WFLY-3147:
------------------------------------

Bug in Weld. See this thread: http://lists.jboss.org/pipermail/weld-dev/2014-March/003224.html
                
> spec-descriptor-property-replacement causes NPE while parsing exclude element in beans.xml
> ------------------------------------------------------------------------------------------
>
>                 Key: WFLY-3147
>                 URL: https://issues.jboss.org/browse/WFLY-3147
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: CDI / Weld, EE
>    Affects Versions: 8.0.0.Final
>            Reporter: Maxim Frolov
>            Assignee: Stuart Douglas
>
> A CDI Bean Archive with a _beans.xml_ which contains {{beans/scan/*exclude*}} XML element causes {{NullPointerExcpetion}} during deployment on server with enabled {{<spec-descriptor-property-replacement>}} parameter in server's _standalone.xml_.
> The error stack trace is:
> {noformat}
> 2014-03-21 11:22:52,455 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-11) MSC000001: Failed to start service jboss.deployment.subunit."example.ear"."example-ejb.jar".PARSE: org.jboss.msc.service.StartException in service jboss.deployment.subunit."example.ear"."example-ejb.jar".PARSE: JBAS018733: Failed to process phase PARSE of subdeployment "example-ejb.jar" of deployment "example.ear"
> 	at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:166) [wildfly-server-8.0.0.Final.jar:8.0.0.Final]
> 	at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) [jboss-msc-1.2.0.Final.jar:1.2.0.Final]
> 	at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) [jboss-msc-1.2.0.Final.jar:1.2.0.Final]
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_45]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_45]
> 	at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_45]
> Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: java.lang.NullPointerException
> 	at org.jboss.as.weld.deployment.processors.BeansXmlProcessor.parseBeansXml(BeansXmlProcessor.java:140)
> 	at org.jboss.as.weld.deployment.processors.BeansXmlProcessor.deploy(BeansXmlProcessor.java:117)
> 	at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:159) [wildfly-server-8.0.0.Final.jar:8.0.0.Final]
> 	... 5 more
> Caused by: java.lang.NullPointerException
> 	at org.jboss.metadata.property.DefaultPropertyReplacer.replaceProperties(DefaultPropertyReplacer.java:52)
> 	at org.jboss.as.weld.deployment.PropertyReplacingBeansXmlHandler.interpolate(PropertyReplacingBeansXmlHandler.java:64)
> 	at org.jboss.weld.xml.BeansXmlHandler$4.processStartChildElement(BeansXmlHandler.java:229)
> 	at org.jboss.weld.xml.BeansXmlHandler.startElement(BeansXmlHandler.java:297)
> 	at org.apache.xerces.parsers.AbstractSAXParser.startElement(Unknown Source)
> 	at org.apache.xerces.parsers.AbstractXMLDocumentParser.emptyElement(Unknown Source)
> 	at org.apache.xerces.impl.xs.XMLSchemaValidator.emptyElement(Unknown Source)
> 	at org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanStartElement(Unknown Source)
> 	at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown Source)
> 	at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown Source)
> 	at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
> 	at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
> 	at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
> 	at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source)
> 	at org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser.parse(Unknown Source)
> 	at org.apache.xerces.jaxp.SAXParserImpl.parse(Unknown Source)
> 	at org.jboss.weld.xml.BeansXmlParser.parse(BeansXmlParser.java:93)
> 	at org.jboss.as.weld.deployment.processors.BeansXmlProcessor.parseBeansXml(BeansXmlProcessor.java:136)
> 	... 7 more
> {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

From issues at jboss.org  Mon Mar 24 09:33:13 2014
From: issues at jboss.org (Emmanuel Hugonnet (JIRA))
Date: Mon, 24 Mar 2014 09:33:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3154) Operation which require
 server reload should check if something was changed
In-Reply-To: <JIRA.12535873.1395667875652@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12535873.1395667875652@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12535873.1395667875652.1957.1395667993843@jira02.app.mwc.hst.phx2.redhat.com>

Emmanuel Hugonnet created WFLY-3154:
---------------------------------------

             Summary:  Operation which require server reload should check if something was changed
                 Key: WFLY-3154
                 URL: https://issues.jboss.org/browse/WFLY-3154
             Project: WildFly
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: Domain Management
    Affects Versions: 8.0.0.Final
            Reporter: Emmanuel Hugonnet
            Assignee: Emmanuel Hugonnet


Description of problem:
Server reload is required even if nothing was actually changed. This could have negative impact on usability of WildFly.

Steps to Reproduce:
 - start standalone
 - connect to cli
 - run: /subsystem=jpa:write-attribute(name=default-extended-persistence-inheritance, value=SHALLOW)
 - reload server
 - run: /subsystem=jpa:write-attribute(name=default-extended-persistence-inheritance, value=SHALLOW)

Actual results:
{
    "outcome" => "success",
    "response-headers" => {
        "operation-requires-reload" => true,
        "process-state" => "reload-required"
    }
}
Expected results:
 - reload is not required

--
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

From issues at jboss.org  Mon Mar 24 09:33:19 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 24 Mar 2014 09:33:19 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3154) Operation which require
 server reload should check if something was changed
In-Reply-To: <JIRA.12535873.1395667875000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12535873.1395667875000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12535873.1395667875000.2057.1395667999265@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-3154?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated WFLY-3154:
------------------------------------------

        Bugzilla Update: Perform
    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=976228

    
>  Operation which require server reload should check if something was changed
> ----------------------------------------------------------------------------
>
>                 Key: WFLY-3154
>                 URL: https://issues.jboss.org/browse/WFLY-3154
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>    Affects Versions: 8.0.0.Final
>            Reporter: Emmanuel Hugonnet
>            Assignee: Emmanuel Hugonnet
>
> Description of problem:
> Server reload is required even if nothing was actually changed. This could have negative impact on usability of WildFly.
> Steps to Reproduce:
>  - start standalone
>  - connect to cli
>  - run: /subsystem=jpa:write-attribute(name=default-extended-persistence-inheritance, value=SHALLOW)
>  - reload server
>  - run: /subsystem=jpa:write-attribute(name=default-extended-persistence-inheritance, value=SHALLOW)
> Actual results:
> {
>     "outcome" => "success",
>     "response-headers" => {
>         "operation-requires-reload" => true,
>         "process-state" => "reload-required"
>     }
> }
> Expected results:
>  - reload is not required

--
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

From issues at jboss.org  Mon Mar 24 10:01:14 2014
From: issues at jboss.org (David Lloyd (JIRA))
Date: Mon, 24 Mar 2014 10:01:14 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3155) Upgrade MSC to 1.2.2.Final
In-Reply-To: <JIRA.12535879.1395669666729@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12535879.1395669666729@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12535879.1395669666729.2444.1395669674032@jira02.app.mwc.hst.phx2.redhat.com>

David Lloyd created WFLY-3155:
---------------------------------

             Summary: Upgrade MSC to 1.2.2.Final
                 Key: WFLY-3155
                 URL: https://issues.jboss.org/browse/WFLY-3155
             Project: WildFly
          Issue Type: Component  Upgrade
      Security Level: Public (Everyone can see)
            Reporter: David Lloyd
            Assignee: David Lloyd
            Priority: Blocker
             Fix For: 8.0.1.Final


This upgrade should be done before release.

--
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

From issues at jboss.org  Mon Mar 24 10:05:15 2014
From: issues at jboss.org (Tomaz Cerar (JIRA))
Date: Mon, 24 Mar 2014 10:05:15 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3156) Upgrade RestEasy to 3.0.7
In-Reply-To: <JIRA.12535882.1395669837938@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12535882.1395669837938@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12535882.1395669837938.2476.1395669915195@jira02.app.mwc.hst.phx2.redhat.com>

Tomaz Cerar created WFLY-3156:
---------------------------------

             Summary: Upgrade RestEasy to 3.0.7
                 Key: WFLY-3156
                 URL: https://issues.jboss.org/browse/WFLY-3156
             Project: WildFly
          Issue Type: Component  Upgrade
      Security Level: Public (Everyone can see)
          Components: REST
    Affects Versions: 8.0.0.Final
            Reporter: Tomaz Cerar
            Assignee: Bill Burke
            Priority: Blocker
             Fix For: 8.0.1.Final


We need new release of RestEasy as it includes few fixes community wants.

--
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

From issues at jboss.org  Mon Mar 24 10:09:14 2014
From: issues at jboss.org (Mario Fusco (JIRA))
Date: Mon, 24 Mar 2014 10:09:14 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-349)
 Accumulate.accumulate(Accumulate.java:182) NullPointerException
In-Reply-To: <JIRA.12525897.1385114371000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12525897.1385114371000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12525897.1385114371000.2519.1395670154341@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-349?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mario Fusco resolved DROOLS-349.
--------------------------------

    Resolution: Rejected


The NPE is not a drools bug, but caused by the fact that the employee inside the ShiftAssignment is null. Changing the first pattern in that rule with the following one fixes the problem.

ShiftAssignment($employee : employee != null, $shiftType : shiftType)
                
> Accumulate.accumulate(Accumulate.java:182) NullPointerException
> ---------------------------------------------------------------
>
>                 Key: DROOLS-349
>                 URL: https://issues.jboss.org/browse/DROOLS-349
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 6.0.0.CR1
>         Environment: Windows 7 64 bit, Optaplanner 6.0.0.CR1, Java 1.7.0_17-b02
>            Reporter: Nick Snels
>            Assignee: Mario Fusco
>
> I reported my issue with a Drools rule in Optaplanner on the Drools user forum (http://drools.46999.n3.nabble.com/Optaplanner-rules-NullPointerException-td4026875.html). I was adviced to create a JIRA ticket.
> =============
> I am trying to accomplish the following, a part time employee (eg 50%) needs to do only half the shifts a full time employee needs to do. I have created a rule, that 
> 1. count number of shifts of certain shiftType 
> 2. count number of shifts of a certain shiftType per employee 
> 3. count the total number of "arbeidsbreuken" per employee and within a certain shiftType 
> 4. do something with these numbers so that an part time employee only gets half the shifts assigned that a full time employee gets 
> The complete rule is: 
> {code}
> rule "arbeidsbreuk" 
>     when     
>     //System.out.println("arbeidsbreuk, Drools!"); 
>     ShiftAssignment($employee : employee, $shiftType : shiftType) 
>     //count aantal shifts 
>         $assignmentTotal : Number() from accumulate( 
>             $assignment : ShiftAssignment(shiftType == $shiftType), 
>             count($assignment) 
>         ) 
>         
>         //count aantal shifts per medewerker 
>         $assignmentTotalEmployee : Number() from accumulate( 
>             $assignmentEmployee : ShiftAssignment(employee == $employee, shiftType == $shiftType), 
>             count($assignmentEmployee) 
>         ) 
>         
>         //count arbeidsbreuken van alle medewerkers 
>         $arbeidsbreukTotal : Number() from accumulate( 
>             //Employee($breuk : arbeidsbreuk), 
>             ShiftAssignment(employee == $employee, shiftType == $shiftType), 
>             sum($employee.getArbeidsbreuk()) 
>         ) 
> $assignmentTotalEmployee.intValue()) 
>     then 
>     System.out.println("Arbeidsbreuk drools: " + $employee.getArbeidsbreuk() + " - " + $assignmentTotal.intValue() + " - " + $assignmentTotalEmployee.intValue() + " - " + $arbeidsbreukTotal); 
>         scoreHolder.addSoftConstraintMatch(kcontext, -(Math.abs(($employee.getArbeidsbreuk() * $assignmentTotal.intValue()) - $assignmentTotalEmployee.intValue()) * (Math.abs(($employee.getArbeidsbreuk() * $assignmentTotal.intValue()) - $assignmentTotalEmployee.intValue()))) ); 
> end 
> {code}
> I get the following error: 
> {code}
> Exception in thread "main" org.drools.core.RuntimeDroolsException: java.lang.NullPointerException 
>         at org.drools.core.rule.Accumulate.accumulate(Accumulate.java:182) 
>         at org.drools.core.phreak.PhreakAccumulateNode.addMatch(PhreakAccumulateNode.java:756) 
>         at org.drools.core.phreak.PhreakAccumulateNode.doLeftInserts(PhreakAccumulateNode.java:164) 
>         at org.drools.core.phreak.PhreakAccumulateNode.doNode(PhreakAccumulateNode.java:81) 
>         at org.drools.core.phreak.RuleNetworkEvaluator.switchOnDoBetaNode(RuleNetworkEvaluator.java:524) 
>         at org.drools.core.phreak.RuleNetworkEvaluator.evalBetaNode(RuleNetworkEvaluator.java:494) 
>         at org.drools.core.phreak.RuleNetworkEvaluator.innerEval(RuleNetworkEvaluator.java:277) 
>         at org.drools.core.phreak.RuleNetworkEvaluator.outerEval(RuleNetworkEvaluator.java:161) 
>         at org.drools.core.phreak.RuleNetworkEvaluator.evaluateNetwork(RuleNetworkEvaluator.java:116) 
>         at org.drools.core.phreak.RuleExecutor.reEvaluateNetwork(RuleExecutor.java:205) 
>         at org.drools.core.phreak.RuleExecutor.evaluateNetworkAndFire(RuleExecutor.java:65) 
>         at org.drools.core.common.DefaultAgenda.fireNextItem(DefaultAgenda.java:936) 
>         at org.drools.core.common.DefaultAgenda.fireAllRules(DefaultAgenda.java:1183) 
>         at org.drools.core.common.AbstractWorkingMemory.fireAllRules(AbstractWorkingMemory.java:935) 
>         at org.drools.core.common.AbstractWorkingMemory.fireAllRules(AbstractWorkingMemory.java:909) 
>         at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:233) 
>         at org.optaplanner.core.impl.score.director.drools.DroolsScoreDirector.calculateScore(DroolsScoreDirector.java:98) 
>         at org.optaplanner.core.impl.solver.scope.DefaultSolverScope.calculateScore(DefaultSolverScope.java:101) 
>         at org.optaplanner.core.impl.bestsolution.BestSolutionRecaller.solvingStarted(BestSolutionRecaller.java:58) 
>         at org.optaplanner.core.impl.solver.DefaultSolver.solvingStarted(DefaultSolver.java:177) 
>         at org.optaplanner.core.impl.solver.DefaultSolver.solve(DefaultSolver.java:154) 
>         at be.ocmwturnhout.permanenties.Main.main(Main.java:495) 
> Caused by: java.lang.NullPointerException 
>         at be.ocmwturnhout.permanenties.solver.Rule_arbeidsbreuk654888368.accumulateExpression2(Rule_arbeidsbreuk654888368.java:23) 
>         at be.ocmwturnhout.permanenties.solver.Rule_arbeidsbreuk654888368AccumulateExpression2Invoker.evaluate(Rule_arbeidsbreuk654888368AccumulateExpression2Invoker.java:25) 
>         at org.drools.core.base.accumulators.JavaAccumulatorFunctionExecutor.accumulate(JavaAccumulatorFunctionExecutor.java:107) 
>         at org.drools.core.rule.Accumulate.accumulate(Accumulate.java:173) 
>         ... 21 more 
> {code}

--
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

From issues at jboss.org  Mon Mar 24 10:33:13 2014
From: issues at jboss.org (Cheng Fang (JIRA))
Date: Mon, 24 Mar 2014 10:33:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-972) EJB calendar timer Sunday
 calculation problem in certain locales
In-Reply-To: <JIRA.12477270.1350507760000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12477270.1350507760000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12477270.1350507760000.2680.1395671593087@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-972?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Cheng Fang reassigned WFLY-972:
-------------------------------

    Assignee: Tomek Adamski  (was: Cheng Fang)


Tomek, can you look into this issue?
                
> EJB calendar timer Sunday calculation problem in certain locales
> ----------------------------------------------------------------
>
>                 Key: WFLY-972
>                 URL: https://issues.jboss.org/browse/WFLY-972
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: EJB
>         Environment: JDK 6 & 7
>            Reporter: Cheng Fang
>            Assignee: Tomek Adamski
>
> My ejb class contains this timeout method:
> {code:java}
>     @Schedule(dayOfWeek="Sun", persistent=false)
>     private void sunday(Timer t) {
>     }
> {code}
> When calling this timer.getNextTimeout(), it returned the Sunday after next Sunday (expecting next Sunday) when running on certain locales (it_IT, es_PE, etc).  It works as expected on other locales like en_US.  
> I added -Duser.language=it -Duser.country=IT to JAVA_OPTS when starting standalone server to use that locale.
> Seems to be a JDK bug.  There could be some differences how dates are calculated in different locales, but shouldn't be that big like skip one Sunday.  Today is Wed.
> One workaround is "to use locale.English when instantiating GregorianCalendar in the following classes."  I tried it on 7.2 with it_IT, and got the expected Sunday.
> {noformat}
> ejb3/src/main/java/org/jboss/as/ejb3/timerservice/schedule/CalendarBasedTimeout.java
> ejb3/src/main/java/org/jboss/as/ejb3/timerservice/schedule/util/CalendarUtil.java
> ejb3/src/main/java/org/jboss/as/ejb3/timerservice/task/CalendarTimerTask.java
> {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

From issues at jboss.org  Mon Mar 24 10:35:16 2014
From: issues at jboss.org (Cheng Fang (JIRA))
Date: Mon, 24 Mar 2014 10:35:16 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2422) Simplify the remote-outbound
	connections
In-Reply-To: <JIRA.12509159.1383210125000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12509159.1383210125000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12509159.1383210125000.2696.1395671716027@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2422?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Cheng Fang reassigned WFLY-2422:
--------------------------------

    Assignee: Tomek Adamski  (was: Cheng Fang)


Tomek, can you take it over?  Looks like I won't be able to get to it any time soon.
                
> 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: Tomek Adamski
>
> 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

From issues at jboss.org  Mon Mar 24 10:53:13 2014
From: issues at jboss.org (Tomek Adamski (JIRA))
Date: Mon, 24 Mar 2014 10:53:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-850) @TransactionTimeout ignored if
 method ist not public
In-Reply-To: <JIRA.12463415.1333657319000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12463415.1333657319000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12463415.1333657319000.2866.1395672793096@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-850?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tomek Adamski reassigned WFLY-850:
----------------------------------

    Assignee: Tomek Adamski  (was: David Lloyd)

    
> @TransactionTimeout ignored if method ist not public
> ----------------------------------------------------
>
>                 Key: WFLY-850
>                 URL: https://issues.jboss.org/browse/WFLY-850
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: EJB
>            Reporter: Frank Langelage
>            Assignee: Tomek Adamski
>            Priority: Minor
>
> The annotation @TransactionTimeout is not honored, when the method has other than public access.
> @Timeout methods invoked by the container are allowed to have "public, private, protected, or package level access".
> So the annotation should work also if method is not public.

--
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

From issues at jboss.org  Mon Mar 24 10:57:13 2014
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Mon, 24 Mar 2014 10:57:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1019) Validate composite operation
 steps just before executing them
In-Reply-To: <JIRA.12482292.1357761533000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12482292.1357761533000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12482292.1357761533000.2902.1395673033477@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-1019?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFLY-1019:
-----------------------------------

    Labels: EAP  (was: )

    
> Validate composite operation steps just before executing them
> -------------------------------------------------------------
>
>                 Key: WFLY-1019
>                 URL: https://issues.jboss.org/browse/WFLY-1019
>             Project: WildFly
>          Issue Type: Enhancement
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>            Reporter: Brian Stansberry
>            Assignee: Brian Stansberry
>              Labels: EAP
>
> Say we have a composite operation with 2 steps:
> 1) /extension=org.jboss.as.messaging:add
> 2) /subsystem=messaging:add
> This will fail:
> Failed to execute batch: JBAS014739: No handler for add at address
> [("subsystem" => "messaging")] 
> This fails because at the time of validation the /subsystem=messaging:add is not valid.
> To illustrate, the execution order is
> Validate 1-2
> 1
> 2
> A possible solution is to convert this to the following:
> V1
> 1
> V2 (works now because 1 has registered the subsystem API)
> 2
> I think that should work but it's a very complex area, particularly in a managed domain, so it's not at all certain this would prove feasible. 

--
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

From issues at jboss.org  Mon Mar 24 11:15:15 2014
From: issues at jboss.org (Alessio Soldano (JIRA))
Date: Mon, 24 Mar 2014 11:15:15 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3067) Webservices DUP is not
 scanning all visible classes for @WebService annotation
In-Reply-To: <JIRA.12534077.1393987223000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534077.1393987223000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534077.1393987223000.2965.1395674115466@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-3067?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Alessio Soldano updated WFLY-3067:
----------------------------------

    Git Pull Request: https://github.com/wildfly/wildfly/pull/5992, https://github.com/wildfly/wildfly/pull/6027  (was: https://github.com/wildfly/wildfly/pull/5992)

    
> Webservices DUP is not scanning all visible classes for @WebService annotation
> ------------------------------------------------------------------------------
>
>                 Key: WFLY-3067
>                 URL: https://issues.jboss.org/browse/WFLY-3067
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web Services
>    Affects Versions: 8.0.0.Final
>            Reporter: Kyle Lape
>            Assignee: Jim Ma
>             Fix For: 8.0.1.Final
>
>
> Sample use case:  You have a .war in an .ear, and the .war has a web.xml with a {{<servlet-class>}} that refers to a JAX-WS endpoint, so the class is annotated with {{@WebService}}.  If that class is packaged in a jar found in the ear's lib directory, the JBossWS DUP won't pick it up, and then Undertow will throw an error like this:
> {noformat}
> UT010009: Servlet ClientEndpoint of type class com.redhat.gss.jaxws.ClientEndpoint does not implement javax.servlet.Servlet
> {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

From issues at jboss.org  Mon Mar 24 11:15:16 2014
From: issues at jboss.org (Alessio Soldano (JIRA))
Date: Mon, 24 Mar 2014 11:15:16 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3067) Webservices DUP is not
 scanning all visible classes for @WebService annotation
In-Reply-To: <JIRA.12534077.1393987223000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534077.1393987223000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534077.1393987223000.2976.1395674116095@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-3067?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Alessio Soldano resolved WFLY-3067.
-----------------------------------

    Resolution: Done


AFAICS this is solved by https://github.com/wildfly/wildfly/pull/6027
                
> Webservices DUP is not scanning all visible classes for @WebService annotation
> ------------------------------------------------------------------------------
>
>                 Key: WFLY-3067
>                 URL: https://issues.jboss.org/browse/WFLY-3067
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web Services
>    Affects Versions: 8.0.0.Final
>            Reporter: Kyle Lape
>            Assignee: Jim Ma
>             Fix For: 8.0.1.Final
>
>
> Sample use case:  You have a .war in an .ear, and the .war has a web.xml with a {{<servlet-class>}} that refers to a JAX-WS endpoint, so the class is annotated with {{@WebService}}.  If that class is packaged in a jar found in the ear's lib directory, the JBossWS DUP won't pick it up, and then Undertow will throw an error like this:
> {noformat}
> UT010009: Servlet ClientEndpoint of type class com.redhat.gss.jaxws.ClientEndpoint does not implement javax.servlet.Servlet
> {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

From issues at jboss.org  Mon Mar 24 11:15:16 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 24 Mar 2014 11:15:16 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3067) Webservices DUP is not
 scanning all visible classes for @WebService annotation
In-Reply-To: <JIRA.12534077.1393987223000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534077.1393987223000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534077.1393987223000.2988.1395674116951@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-3067?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12955684#comment-12955684 ] 

RH Bugzilla Integration commented on WFLY-3067:
-----------------------------------------------

Alessio Soldano <asoldano at redhat.com> changed the Status of [bug 1079084|https://bugzilla.redhat.com/show_bug.cgi?id=1079084] from NEW to ASSIGNED
                
> Webservices DUP is not scanning all visible classes for @WebService annotation
> ------------------------------------------------------------------------------
>
>                 Key: WFLY-3067
>                 URL: https://issues.jboss.org/browse/WFLY-3067
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web Services
>    Affects Versions: 8.0.0.Final
>            Reporter: Kyle Lape
>            Assignee: Jim Ma
>             Fix For: 8.0.1.Final
>
>
> Sample use case:  You have a .war in an .ear, and the .war has a web.xml with a {{<servlet-class>}} that refers to a JAX-WS endpoint, so the class is annotated with {{@WebService}}.  If that class is packaged in a jar found in the ear's lib directory, the JBossWS DUP won't pick it up, and then Undertow will throw an error like this:
> {noformat}
> UT010009: Servlet ClientEndpoint of type class com.redhat.gss.jaxws.ClientEndpoint does not implement javax.servlet.Servlet
> {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

From issues at jboss.org  Mon Mar 24 11:23:12 2014
From: issues at jboss.org (Richard Achmatowicz (JIRA))
Date: Mon, 24 Mar 2014 11:23:12 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1812)
 ProgrammaticApiTest.testSharedTransport fails to receive correct number of
 messages
In-Reply-To: <JIRA.12535897.1395674570564@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12535897.1395674570564@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12535897.1395674570564.3053.1395674592989@jira02.app.mwc.hst.phx2.redhat.com>

Richard Achmatowicz created JGRP-1812:
-----------------------------------------

             Summary: ProgrammaticApiTest.testSharedTransport fails to receive correct number of messages
                 Key: JGRP-1812
                 URL: https://issues.jboss.org/browse/JGRP-1812
             Project: JGroups
          Issue Type: Bug
    Affects Versions: 3.2.14
         Environment: RHEL, Solaris
            Reporter: Richard Achmatowicz
            Assignee: Bela Ban
             Fix For: 3.2.14


ProgrammaticApiTest tests the use of the API for creating and configuring channels. One such test testSharedTransport tests the creation and use of a stack with a shared transport. This test does the following:
- creates two channels A and B
- creates a UDP-based shared transport stack
- assigns the same stack to both channels
- channel A connects to group cluster-one; channel B connects to group cluster-two
- channel A multicasts 10 messages to its group; channel B multicasts 5 messages to its group
- the test then waits for the correct number of multicast messages to arrive

Problem:the test is failing because the receiver on channel A is receiving 20 messages instead of 10 messages.

This test fails intermittently, but fairly regularly.


--
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

From issues at jboss.org  Mon Mar 24 11:27:12 2014
From: issues at jboss.org (Richard Achmatowicz (JIRA))
Date: Mon, 24 Mar 2014 11:27:12 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1812)
 ProgrammaticApiTest.testSharedTransport fails to receive correct number of
 messages
In-Reply-To: <JIRA.12535897.1395674570000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12535897.1395674570000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12535897.1395674570000.3056.1395674832878@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JGRP-1812?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12955691#comment-12955691 ] 

Richard Achmatowicz commented on JGRP-1812:
-------------------------------------------

One example of output from a failed instance of the test:

{noformat}
------------- testSharedTransport -----------

-------------------------------------------------------------------
GMS: address=A, cluster=cluster-one, physical address=10.16.92.26:49627
-------------------------------------------------------------------
111009 [TRACE] GMS: - A: no initial members discovered: creating group as first member
111009 [DEBUG] GMS: - A: installing view [A|0] [A]
111010 [DEBUG] GMS: - created group (first member). My view is [A|0], impl is org.jgroups.protocols.pbcast.CoordGmsImpl

-------------------------------------------------------------------
GMS: address=B, cluster=cluster-two, physical address=10.16.92.26:49627
-------------------------------------------------------------------
112579 [TRACE] GMS: - A: new members=[A], suspected=[], leaving=[], new view: [A|1] [A, A]
112579 [TRACE] GMS: - A: mcasting view [A|1] [A, A] (2 mbrs)
112580 [DEBUG] GMS: - A: installing view [A|1] [A, A]
112581 [TRACE] GMS: - A: received all 1 ACKs from members for view [A|1]
112611 [TRACE] GMS: - A: received all ACKs (1) from joiners for view [A|1]
114019 [TRACE] GMS: - B: initial_mbrs are B
114019 [DEBUG] GMS: - election results: {}
114019 [TRACE] GMS: - could not determine coordinator from responses [B, view_id=, is_server=false, is_coord=false, logical_name=B, physical_addrs=10.16.92.90:53759]
114019 [TRACE] GMS: - clients to choose new coord from are: [B, B]
114019 [TRACE] GMS: - I (B) am not the first of the clients, waiting for another client to become coordinator
[A]<< hello-0
[A]<< hello-1
[A]<< hello-2
[A]<< hello-3
[A]<< hello-4
[A]<< hello-5
[A]<< hello-6
[A]<< hello-7
[A]<< hello-8
[A]<< hello-9
116116 [TRACE] GMS: - A: new members=[], suspected=[], leaving=[A], new view: [A|2] [A]
116116 [TRACE] GMS: - A: mcasting view [A|2] [A] (1 mbrs)
116116 [DEBUG] GMS: - A: installing view [A|2] [A]
116118 [TRACE] GMS: - A: received all 1 ACKs from members for view [A|2]
117529 [TRACE] GMS: - B: initial_mbrs are B
117529 [DEBUG] GMS: - election results: {}
117529 [TRACE] GMS: - could not determine coordinator from responses [B, view_id=, is_server=false, is_coord=false, logical_name=B, physical_addrs=10.16.92.90:53759]
117529 [TRACE] GMS: - clients to choose new coord from are: [B, B]
117529 [TRACE] GMS: - I (B) am not the first of the clients, waiting for another client to become coordinator
121039 [TRACE] GMS: - B: no initial members discovered: creating group as first member
121039 [DEBUG] GMS: - B: installing view [B|0] [B]
121039 [DEBUG] GMS: - created group (first member). My view is [B|0], impl is org.jgroups.protocols.pbcast.CoordGmsImpl
[A]<< hello-0
[A]<< hello-1
[A]<< hello-2
[A]<< hello-3
[A]<< hello-4
[A]<< hello-5
[A]<< hello-6
[A]<< hello-7
[A]<< hello-8
121040 [WARN] NAKACK2: - JGRP000011: B: dropped message 1 from non-member B (view=[B|0] [B]) (received 5 identical messages from B in the last 0 ms)
[A]<< hello-9
[B]<< hello-0
[B]<< hello-1
[B]<< hello-2
[B]<< hello-3
[B]<< hello-4
131043 [TRACE] GMS: - view [B|1] [] is empty: will not multicast it (last view)
131043 [TRACE] GMS: - view [A|3] [] is empty: will not multicast it (last view)
{noformat}

I'm not quite sure what the discovery arrangements are for shared transport nor the mapping of channel names to memberships. It's a little hard to follow :-)
 
                
> ProgrammaticApiTest.testSharedTransport fails to receive correct number of messages
> -----------------------------------------------------------------------------------
>
>                 Key: JGRP-1812
>                 URL: https://issues.jboss.org/browse/JGRP-1812
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.2.14
>         Environment: RHEL, Solaris
>            Reporter: Richard Achmatowicz
>            Assignee: Bela Ban
>             Fix For: 3.2.14
>
>
> ProgrammaticApiTest tests the use of the API for creating and configuring channels. One such test testSharedTransport tests the creation and use of a stack with a shared transport. This test does the following:
> - creates two channels A and B
> - creates a UDP-based shared transport stack
> - assigns the same stack to both channels
> - channel A connects to group cluster-one; channel B connects to group cluster-two
> - channel A multicasts 10 messages to its group; channel B multicasts 5 messages to its group
> - the test then waits for the correct number of multicast messages to arrive
> Problem:the test is failing because the receiver on channel A is receiving 20 messages instead of 10 messages.
> This test fails intermittently, but fairly regularly.

--
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

From issues at jboss.org  Mon Mar 24 11:45:13 2014
From: issues at jboss.org (Richard Achmatowicz (JIRA))
Date: Mon, 24 Mar 2014 11:45:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1812)
 ProgrammaticApiTest.testSharedTransport fails to receive correct number of
 messages
In-Reply-To: <JIRA.12535897.1395674570000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12535897.1395674570000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12535897.1395674570000.3134.1395675913039@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JGRP-1812?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12955703#comment-12955703 ] 

Richard Achmatowicz commented on JGRP-1812:
-------------------------------------------

By the way, this is what I see on a passing run: 

{noformat}
------------- testSharedTransport -----------
43652 [WARN] UDP: - JGRP000014: the receive buffer of socket MulticastSocket was set to 500KB, but the OS only allocated 212.99KB. This might lead to performance problems. Please set your max receive buffer in the OS correctly (e.g. net.core.rmem_max on Linux)

-------------------------------------------------------------------
GMS: address=A, cluster=cluster-one, physical address=10.3.239.189:56487
-------------------------------------------------------------------
47050 [TRACE] GMS: - A: no initial members discovered: creating group as first member
47051 [DEBUG] GMS: - A: installing view [A|0] [A]
47052 [DEBUG] GMS: - created group (first member). My view is [A|0], impl is org.jgroups.protocols.pbcast.CoordGmsImpl

-------------------------------------------------------------------
GMS: address=B, cluster=cluster-two, physical address=10.3.239.189:56487
-------------------------------------------------------------------
50326 [TRACE] GMS: - B: no initial members discovered: creating group as first member
50327 [DEBUG] GMS: - B: installing view [B|0] [B]
50328 [DEBUG] GMS: - created group (first member). My view is [B|0], impl is org.jgroups.protocols.pbcast.CoordGmsImpl
[A]<< hello-0
[B]<< hello-0
[A]<< hello-1
[B]<< hello-1
[A]<< hello-2
[B]<< hello-2
[A]<< hello-3
[B]<< hello-3
[A]<< hello-4
[B]<< hello-4
[A]<< hello-5
[A]<< hello-6
[A]<< hello-7
[A]<< hello-8
[A]<< hello-9
50832 [TRACE] GMS: - view [B|1] [] is empty: will not multicast it (last view)
50833 [TRACE] GMS: - view [A|1] [] is empty: will not multicast it (last view)
{noformat}

                
> ProgrammaticApiTest.testSharedTransport fails to receive correct number of messages
> -----------------------------------------------------------------------------------
>
>                 Key: JGRP-1812
>                 URL: https://issues.jboss.org/browse/JGRP-1812
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.2.14
>         Environment: RHEL, Solaris
>            Reporter: Richard Achmatowicz
>            Assignee: Bela Ban
>             Fix For: 3.2.14
>
>
> ProgrammaticApiTest tests the use of the API for creating and configuring channels. One such test testSharedTransport tests the creation and use of a stack with a shared transport. This test does the following:
> - creates two channels A and B
> - creates a UDP-based shared transport stack
> - assigns the same stack to both channels
> - channel A connects to group cluster-one; channel B connects to group cluster-two
> - channel A multicasts 10 messages to its group; channel B multicasts 5 messages to its group
> - the test then waits for the correct number of multicast messages to arrive
> Problem:the test is failing because the receiver on channel A is receiving 20 messages instead of 10 messages.
> This test fails intermittently, but fairly regularly.

--
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

From issues at jboss.org  Mon Mar 24 11:51:13 2014
From: issues at jboss.org (Bela Ban (JIRA))
Date: Mon, 24 Mar 2014 11:51:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1809) New discovery protocol to be
 used in conjunction with SHARED_LOOPBACK
In-Reply-To: <JIRA.12535687.1395402818000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12535687.1395402818000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12535687.1395402818000.3156.1395676273138@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JGRP-1809?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban resolved JGRP-1809.
----------------------------

    Resolution: Done

    
> New discovery protocol to be used in conjunction with SHARED_LOOPBACK
> ---------------------------------------------------------------------
>
>                 Key: JGRP-1809
>                 URL: https://issues.jboss.org/browse/JGRP-1809
>             Project: JGroups
>          Issue Type: Enhancement
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>            Priority: Minor
>             Fix For: 3.5
>
>
> Sometimes tests in the testsuite fail because the nodes run over SHARED_LOOPBACK fail to discover each other and therefore don't form a cluster. This can happen because discovery requests sent via PING are discarded on a full thread pool.
> Because the default test stack doesn't have a MERGE protocol, members won't get merged back.
> h5. GOAL
> * Create a discovery protocol which always discovers other members registered with the same cluster 
> h5. SOLUTION
> * Instead of using SHARED_LOOPBACK to send and receive discovery requests, query SHARED_LOOPBACK directly for discovery information. E.g. if we have members A,B,C registered with cluster "demo" in SHARED_LOOPBACK, then a node D joining can fetch (via SHARED_LOOPBACK_PING) the PingData of A, B and C directly from SHARED_LOOPBACK.
> * This way, we won't have any failed test cases (run over SHARED_LOOPBACK) which fail because no other members were discovered. Also, discovery (even for the first node started in a cluster) is very fast, and we don't need the timeout at all.
> * Also, we don't need to add a MERGE protocol to the stack as merging is not needed

--
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

From issues at jboss.org  Mon Mar 24 11:55:13 2014
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Mon, 24 Mar 2014 11:55:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1136) Common mechanism for all
 secure socket definitions
In-Reply-To: <JIRA.12413600.1277840615000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12413600.1277840615000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12413600.1277840615000.3191.1395676513302@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-1136?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated WFLY-1136:
-----------------------------------


Brain dump article collecting together the related pieces: -
  https://community.jboss.org/docs/DOC-52501
                
> Common mechanism for all secure socket definitions
> --------------------------------------------------
>
>                 Key: WFLY-1136
>                 URL: https://issues.jboss.org/browse/WFLY-1136
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management, Security
>            Reporter: Brian Stansberry
>            Assignee: Darran Lofthouse
>             Fix For: 9.0.0.CR1
>
>
> This JIRA is based on feedback we received after the Andiamo BOF at JBoss World 2010:
> >> The JAASSecurityDomain in my opinion should
> >> handle all secure socket definitions. Mod-cluster currently does
> >> not support JAASSecurityDomains.
> I won't comment either way on whether JAASSecurityDomain is how we'll do this, but I definitely agree that a common mechanism should be used for all secure socket definitions.

--
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

From issues at jboss.org  Mon Mar 24 12:09:13 2014
From: issues at jboss.org (Bela Ban (JIRA))
Date: Mon, 24 Mar 2014 12:09:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1811) Arithmetic Exception in MPerf
 when sending less than 10 messages
In-Reply-To: <JIRA.12535810.1395504697000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12535810.1395504697000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12535810.1395504697000.3249.1395677353352@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JGRP-1811?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban resolved JGRP-1811.
----------------------------

    Resolution: Done

    
> Arithmetic Exception in MPerf when sending less than 10 messages
> ----------------------------------------------------------------
>
>                 Key: JGRP-1811
>                 URL: https://issues.jboss.org/browse/JGRP-1811
>             Project: JGroups
>          Issue Type: Bug
>            Reporter: Andrei Palade
>            Assignee: Bela Ban
>            Priority: Minor
>             Fix For: 3.5
>
>
> Not sure if this is intended to be like this, but in MPerf when the user tries to set the num_msg to 1 and start sending the messages, MPerf throws
> Mar 22, 2014 4:02:25 PM org.jgroups.logging.JDKLogImpl error
> SEVERE: failure unmarshalling buffer
> java.lang.ArithmeticException: / by zero
> 	at org.jgroups.tests.perf.MPerf.handleData(MPerf.java:418)
> 	at org.jgroups.tests.perf.MPerf.receive(MPerf.java:280)
> 	at org.jgroups.JChannel.invokeCallback(JChannel.java:890)
> 	at org.jgroups.JChannel.up(JChannel.java:746)
> 	at org.jgroups.stack.ProtocolStack.up(ProtocolStack.java:1030)
> 	at org.jgroups.protocols.pbcast.STATE_TRANSFER.up(STATE_TRANSFER.java:146)
> 	at org.jgroups.protocols.FRAG2.up(FRAG2.java:165)
> 	at org.jgroups.protocols.SEQUENCER.deliver(SEQUENCER.java:606)
> 	at org.jgroups.protocols.SEQUENCER.unwrapAndDeliver(SEQUENCER.java:573)
> 	at org.jgroups.protocols.SEQUENCER.up(SEQUENCER.java:279)
> 	at org.jgroups.protocols.SEQUENCER.up(SEQUENCER.java:308)
> 	at org.jgroups.protocols.FlowControl.up(FlowControl.java:434)
> 	at org.jgroups.protocols.FlowControl.up(FlowControl.java:434)
> 	at org.jgroups.stack.Protocol.up(Protocol.java:409)
> 	at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:294)
> 	at org.jgroups.protocols.UNICAST3.up(UNICAST3.java:520)
> 	at org.jgroups.protocols.pbcast.NAKACK2.deliverBatch(NAKACK2.java:927)
> 	at org.jgroups.protocols.pbcast.NAKACK2.removeAndPassUp(NAKACK2.java:857)
> 	at org.jgroups.protocols.pbcast.NAKACK2.handleMessage(NAKACK2.java:792)
> 	at org.jgroups.protocols.pbcast.NAKACK2.up(NAKACK2.java:573)
> 	at org.jgroups.protocols.BARRIER.up(BARRIER.java:152)
> 	at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:147)
> 	at org.jgroups.protocols.FD_ALL.up(FD_ALL.java:199)
> 	at org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:296)
> 	at org.jgroups.protocols.MERGE2.up(MERGE2.java:209)
> 	at org.jgroups.protocols.Discovery.up(Discovery.java:379)
> 	at org.jgroups.protocols.TP.passMessageUp(TP.java:1532)
> 	at org.jgroups.protocols.TP$3.run(TP.java:1466)
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> 	at java.lang.Thread.run(Thread.java:744)

--
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

From issues at jboss.org  Mon Mar 24 12:15:18 2014
From: issues at jboss.org (Bela Ban (JIRA))
Date: Mon, 24 Mar 2014 12:15:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1810) Illegal format string in
 trace message in NAKACK2 protocol
In-Reply-To: <JIRA.12535768.1395431156000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12535768.1395431156000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12535768.1395431156000.3288.1395677718875@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JGRP-1810?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12955729#comment-12955729 ] 

Bela Ban commented on JGRP-1810:
--------------------------------

You meant replace {{%s}} (not {{%%}}) didn't you ?
                
> Illegal format string in trace message in NAKACK2 protocol
> ----------------------------------------------------------
>
>                 Key: JGRP-1810
>                 URL: https://issues.jboss.org/browse/JGRP-1810
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.4.3
>            Reporter: Chris LeCompte
>            Assignee: Bela Ban
>            Priority: Minor
>             Fix For: 3.5
>
>
> The NAKACK2 protocol has an invalid format string in one of its trace logging outputs:
>                     log.trace("%s: my_highest_rcvd (%) < stability_highest_rcvd (%): requesting retransmission of %s",
>                               local_addr, my_hr, hr, member + "#" + hr);
> This results in an error in the log:
> ERROR - Illegal format string "%s: my_highest_rcvd (%) < stability_highest_rcvd (%): requesting retransmission of %s"
> The % should be changed to %% to avoid the error.  The arguments are in fact printed alongside the message however anything with ERROR in the text makes QA nervous.

--
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

From issues at jboss.org  Mon Mar 24 12:19:13 2014
From: issues at jboss.org (Bela Ban (JIRA))
Date: Mon, 24 Mar 2014 12:19:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1810) Illegal format string in
 trace message in NAKACK2 protocol
In-Reply-To: <JIRA.12535768.1395431156000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12535768.1395431156000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12535768.1395431156000.3311.1395677953723@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JGRP-1810?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12955729#comment-12955729 ] 

Bela Ban edited comment on JGRP-1810 at 3/24/14 12:17 PM:
----------------------------------------------------------

You meant replace {{%d}} (not {{%%}}) didn't you ?
                
      was (Author: belaban):
    You meant replace {{%s}} (not {{%%}}) didn't you ?
                  
> Illegal format string in trace message in NAKACK2 protocol
> ----------------------------------------------------------
>
>                 Key: JGRP-1810
>                 URL: https://issues.jboss.org/browse/JGRP-1810
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.4.3
>            Reporter: Chris LeCompte
>            Assignee: Bela Ban
>            Priority: Minor
>             Fix For: 3.5
>
>
> The NAKACK2 protocol has an invalid format string in one of its trace logging outputs:
>                     log.trace("%s: my_highest_rcvd (%) < stability_highest_rcvd (%): requesting retransmission of %s",
>                               local_addr, my_hr, hr, member + "#" + hr);
> This results in an error in the log:
> ERROR - Illegal format string "%s: my_highest_rcvd (%) < stability_highest_rcvd (%): requesting retransmission of %s"
> The % should be changed to %% to avoid the error.  The arguments are in fact printed alongside the message however anything with ERROR in the text makes QA nervous.

--
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

From issues at jboss.org  Mon Mar 24 12:23:13 2014
From: issues at jboss.org (Bela Ban (JIRA))
Date: Mon, 24 Mar 2014 12:23:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1810) Illegal format string in
 trace message in NAKACK2 protocol
In-Reply-To: <JIRA.12535768.1395431156000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12535768.1395431156000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12535768.1395431156000.3358.1395678193002@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JGRP-1810?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban updated JGRP-1810:
---------------------------

    Fix Version/s: 3.4.4
                       (was: 3.5)


The issue doesn't occur in 3.2 because we're not using format strings and in 3.5 because it has been fixed there, only in 3.4.x.
Fixed in 3.4.4
                
> Illegal format string in trace message in NAKACK2 protocol
> ----------------------------------------------------------
>
>                 Key: JGRP-1810
>                 URL: https://issues.jboss.org/browse/JGRP-1810
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.4.3
>            Reporter: Chris LeCompte
>            Assignee: Bela Ban
>            Priority: Minor
>             Fix For: 3.4.4
>
>
> The NAKACK2 protocol has an invalid format string in one of its trace logging outputs:
>                     log.trace("%s: my_highest_rcvd (%) < stability_highest_rcvd (%): requesting retransmission of %s",
>                               local_addr, my_hr, hr, member + "#" + hr);
> This results in an error in the log:
> ERROR - Illegal format string "%s: my_highest_rcvd (%) < stability_highest_rcvd (%): requesting retransmission of %s"
> The % should be changed to %% to avoid the error.  The arguments are in fact printed alongside the message however anything with ERROR in the text makes QA nervous.

--
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

From issues at jboss.org  Mon Mar 24 12:23:13 2014
From: issues at jboss.org (Bela Ban (JIRA))
Date: Mon, 24 Mar 2014 12:23:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1810) Illegal format string in
 trace message in NAKACK2 protocol
In-Reply-To: <JIRA.12535768.1395431156000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12535768.1395431156000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12535768.1395431156000.3361.1395678193210@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JGRP-1810?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban resolved JGRP-1810.
----------------------------

    Resolution: Done

    
> Illegal format string in trace message in NAKACK2 protocol
> ----------------------------------------------------------
>
>                 Key: JGRP-1810
>                 URL: https://issues.jboss.org/browse/JGRP-1810
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.4.3
>            Reporter: Chris LeCompte
>            Assignee: Bela Ban
>            Priority: Minor
>             Fix For: 3.4.4
>
>
> The NAKACK2 protocol has an invalid format string in one of its trace logging outputs:
>                     log.trace("%s: my_highest_rcvd (%) < stability_highest_rcvd (%): requesting retransmission of %s",
>                               local_addr, my_hr, hr, member + "#" + hr);
> This results in an error in the log:
> ERROR - Illegal format string "%s: my_highest_rcvd (%) < stability_highest_rcvd (%): requesting retransmission of %s"
> The % should be changed to %% to avoid the error.  The arguments are in fact printed alongside the message however anything with ERROR in the text makes QA nervous.

--
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

From issues at jboss.org  Mon Mar 24 12:49:14 2014
From: issues at jboss.org (Chris LeCompte (JIRA))
Date: Mon, 24 Mar 2014 12:49:14 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1810) Illegal format string in
 trace message in NAKACK2 protocol
In-Reply-To: <JIRA.12535768.1395431156000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12535768.1395431156000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12535768.1395431156000.3504.1395679754135@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JGRP-1810?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12955758#comment-12955758 ] 

Chris LeCompte commented on JGRP-1810:
--------------------------------------

Shouldn't the my_highest_received(%) be changed to my_highest_received(%d) as well?  
                
> Illegal format string in trace message in NAKACK2 protocol
> ----------------------------------------------------------
>
>                 Key: JGRP-1810
>                 URL: https://issues.jboss.org/browse/JGRP-1810
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.4.3
>            Reporter: Chris LeCompte
>            Assignee: Bela Ban
>            Priority: Minor
>             Fix For: 3.4.4
>
>
> The NAKACK2 protocol has an invalid format string in one of its trace logging outputs:
>                     log.trace("%s: my_highest_rcvd (%) < stability_highest_rcvd (%): requesting retransmission of %s",
>                               local_addr, my_hr, hr, member + "#" + hr);
> This results in an error in the log:
> ERROR - Illegal format string "%s: my_highest_rcvd (%) < stability_highest_rcvd (%): requesting retransmission of %s"
> The % should be changed to %% to avoid the error.  The arguments are in fact printed alongside the message however anything with ERROR in the text makes QA nervous.

--
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

From issues at jboss.org  Mon Mar 24 12:58:02 2014
From: issues at jboss.org (Bela Ban (JIRA))
Date: Mon, 24 Mar 2014 12:58:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1810) Illegal format string in
 trace message in NAKACK2 protocol
In-Reply-To: <JIRA.12535768.1395431156000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12535768.1395431156000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12535768.1395431156000.3589.1395680282975@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JGRP-1810?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12955765#comment-12955765 ] 

Bela Ban commented on JGRP-1810:
--------------------------------

It already is {{%d}} at least on the 3.4 branch. Where did you see {{(%)}} ?
                
> Illegal format string in trace message in NAKACK2 protocol
> ----------------------------------------------------------
>
>                 Key: JGRP-1810
>                 URL: https://issues.jboss.org/browse/JGRP-1810
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.4.3
>            Reporter: Chris LeCompte
>            Assignee: Bela Ban
>            Priority: Minor
>             Fix For: 3.4.4
>
>
> The NAKACK2 protocol has an invalid format string in one of its trace logging outputs:
>                     log.trace("%s: my_highest_rcvd (%) < stability_highest_rcvd (%): requesting retransmission of %s",
>                               local_addr, my_hr, hr, member + "#" + hr);
> This results in an error in the log:
> ERROR - Illegal format string "%s: my_highest_rcvd (%) < stability_highest_rcvd (%): requesting retransmission of %s"
> The % should be changed to %% to avoid the error.  The arguments are in fact printed alongside the message however anything with ERROR in the text makes QA nervous.

--
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

From issues at jboss.org  Mon Mar 24 12:59:13 2014
From: issues at jboss.org (Bela Ban (JIRA))
Date: Mon, 24 Mar 2014 12:59:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1810) Illegal format string in
 trace message in NAKACK2 protocol
In-Reply-To: <JIRA.12535768.1395431156000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12535768.1395431156000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12535768.1395431156000.3617.1395680353208@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JGRP-1810?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12955768#comment-12955768 ] 

Bela Ban commented on JGRP-1810:
--------------------------------

Sorry, I looked in the wrong branch... Fixed now
                
> Illegal format string in trace message in NAKACK2 protocol
> ----------------------------------------------------------
>
>                 Key: JGRP-1810
>                 URL: https://issues.jboss.org/browse/JGRP-1810
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.4.3
>            Reporter: Chris LeCompte
>            Assignee: Bela Ban
>            Priority: Minor
>             Fix For: 3.4.4
>
>
> The NAKACK2 protocol has an invalid format string in one of its trace logging outputs:
>                     log.trace("%s: my_highest_rcvd (%) < stability_highest_rcvd (%): requesting retransmission of %s",
>                               local_addr, my_hr, hr, member + "#" + hr);
> This results in an error in the log:
> ERROR - Illegal format string "%s: my_highest_rcvd (%) < stability_highest_rcvd (%): requesting retransmission of %s"
> The % should be changed to %% to avoid the error.  The arguments are in fact printed alongside the message however anything with ERROR in the text makes QA nervous.

--
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

From issues at jboss.org  Mon Mar 24 13:25:13 2014
From: issues at jboss.org (Richard Achmatowicz (JIRA))
Date: Mon, 24 Mar 2014 13:25:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1805) OverlappingMergeTest
 testMergeWithDifferentPartitions fails to create correct merged view
In-Reply-To: <JIRA.12534032.1393962618000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534032.1393962618000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534032.1393962618000.3642.1395681913119@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JGRP-1805?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12955775#comment-12955775 ] 

Richard Achmatowicz commented on JGRP-1805:
-------------------------------------------

An example of this failure of testMergeWithDifferentPartitions with the additional logging: (one failing copy run in the QA lab, one passing copy run on my local machine)

passing test:
{noformat}
------------- testMergeWithDifferentPartitions -----------
-------------------------------------------------------------------
GMS: address=D, cluster=OverlappingMergeTest, physical address=127.0.0.1:48135
-------------------------------------------------------------------
69904 [TRACE] GMS: - D: initial_mbrs are A
69904 [DEBUG] GMS: - election results: {A=1}
69904 [DEBUG] GMS: - sending JOIN(D) to A
69982 [TRACE] GMS: - D: JOIN-RSP=[A|3] [A, B, C, D] [size=4]
69982 [DEBUG] GMS: - D: installing view [A|3] [A, B, C, D]

 ==== Injecting view [A|4] [A, C, B] into A, B and C ====
69983 [DEBUG] GMS: - A: installing view [A|4] [A, C, B]
69984 [DEBUG] GMS: - B: installing view [A|4] [A, C, B]
69984 [DEBUG] GMS: - C: installing view [A|4] [A, C, B]

 ==== Injecting view [B|4] [B, A, C, D] into D ====

69985 [DEBUG] GMS: - D: installing view [B|4] [B, A, C, D]
A: [A|4] [A, C, B]
B: [A|4] [A, C, B]
C: [A|4] [A, C, B]
D: [B|4] [B, A, C, D]

==== Injecting a merge event into A, B, C and D====
Enabling TRACE debugging for GMS, MERGE2 and Discovery
70012 [DEBUG] GMS: - D: installing view MergeView::[A|5] [A, D, C, B], subgroups=[A|4] [A, C, B], [A|4] [A, C, B], [B|4] [D]
70013 [TRACE] GMS: - D: mcasting view MergeView::[A|5] [A, D, C, B], subgroups=[A|4] [A, C, B], [A|4] [A, C, B], [B|4] [D] (4 mbrs)
70043 [TRACE] GMS: - D: received all 4 ACKs from members for view [A|5]
Disabling TRACE debugging for GMS, MERGE2 and Discovery
A: [A|5] [A, D, C, B] (coord=true)
B: [A|5] [A, D, C, B] (coord=false)
C: [A|5] [A, D, C, B] (coord=false)
D: [A|5] [A, D, C, B] (coord=false)
{noformat}

failing test:
{noformat}
------------- testMergeWithDifferentPartitions -----------

-------------------------------------------------------------------
GMS: address=D, cluster=OverlappingMergeTest, physical address=10.16.92.187:27202
-------------------------------------------------------------------
182881 [TRACE] GMS: - D: initial_mbrs are C A
182882 [DEBUG] GMS: - election results: {A=2}
182882 [DEBUG] GMS: - sending JOIN(D) to A
182986 [TRACE] GMS: - D: JOIN-RSP=[A|3] [A, B, C, D] [size=4]
182986 [DEBUG] GMS: - D: installing view [A|3] [A, B, C, D]

 ==== Injecting view [A|4] [A, C, B] into A, B and C ====
182986 [DEBUG] GMS: - A: installing view [A|4] [A, C, B]
182987 [DEBUG] GMS: - B: installing view [A|4] [A, C, B]
182988 [DEBUG] GMS: - C: installing view [A|4] [A, C, B]

 ==== Injecting view [B|4] [B, A, C, D] into D ====

182989 [DEBUG] GMS: - D: installing view [B|4] [B, A, C, D]
A: [A|4] [A, C, B]
B: [A|4] [A, C, B]
C: [A|4] [A, C, B]
D: [B|4] [B, A, C, D]

==== Injecting a merge event into A, B, C and D====
Enabling TRACE debugging for GMS, MERGE2 and Discovery
Disabling TRACE debugging for GMS, MERGE2 and Discovery
A: [A|5] [A, B, C] (coord=true)
B: [A|5] [A, B, C] (coord=false)
C: [A|5] [A, B, C] (coord=false)
D: [B|4] [B, A, C, D] (coord=false)
{noformat}

It appears that there is no activity after the merge even is injected in the failing case, as there are no TRACE messages appearing.

                
> OverlappingMergeTest testMergeWithDifferentPartitions fails to create correct merged view
> -----------------------------------------------------------------------------------------
>
>                 Key: JGRP-1805
>                 URL: https://issues.jboss.org/browse/JGRP-1805
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.2.13
>         Environment: RHEL
>            Reporter: Richard Achmatowicz
>            Assignee: Bela Ban
>             Fix For: 3.2.13
>
>
> This test does the following:
> - creates four channels a,b,c,d
> - injects views A: {A,C,B}, B:{A,C,B}, C:{A,C,B} and D: {B,A,C,D}
> - injects a merge event in each of channels A,B,C,D representing these four views
> - checks that all channels have the final view of size 4
> The test fails intermittently on RHEL, with the same failure each time:
> {noformat}
> 181595 [DEBUG] GMS: - A: installing view [A|2] [A]
>    [testng] 181596 [TRACE] GMS: - A: received all 1 ACKs from members for view [A|2]
>    [testng] 181866 [TRACE] GMS: - view [A|3] [] is empty: will not multicast it (last view)
>    [testng] 
>    [testng] -------------------------------------------------------------------
>    [testng] GMS: address=A, cluster=OverlappingMergeTest, physical address=10.16.94.42:27199
>    [testng] -------------------------------------------------------------------
>    [testng] 184954 [TRACE] GMS: - A: no initial members discovered: creating group as first member
>    [testng] 184954 [DEBUG] GMS: - A: installing view [A|0] [A]
>    [testng] 184955 [DEBUG] GMS: - created group (first member). My view is [A|0], impl is org.jgroups.protocols.pbcast.CoordGmsImpl
>    [testng] 
>    [testng] -------------------------------------------------------------------
>    [testng] GMS: address=B, cluster=OverlappingMergeTest, physical address=10.16.94.42:27200
>    [testng] -------------------------------------------------------------------
>    [testng] 184961 [TRACE] GMS: - B: initial_mbrs are A 
>    [testng] 184961 [DEBUG] GMS: - election results: {A=1}
>    [testng] 184961 [DEBUG] GMS: - sending JOIN(B) to A
>    [testng] 185013 [TRACE] GMS: - A: new members=[B], suspected=[], leaving=[], new view: [A|1] [A, B]
>    [testng] 185014 [TRACE] GMS: - A: mcasting view [A|1] [A, B] (2 mbrs)
>    [testng] 
>    [testng] 185025 [DEBUG] GMS: - A: installing view [A|1] [A, B]
>    [testng] 185026 [TRACE] GMS: - A: received all 1 ACKs from members for view [A|1]
>    [testng] 185055 [TRACE] GMS: - B: JOIN-RSP=[A|1] [A, B] [size=2]
>    [testng] 
>    [testng] 
>    [testng] 185055 [DEBUG] GMS: - B: installing view [A|1] [A, B]
>    [testng] 185057 [TRACE] GMS: - A: received all ACKs (1) from joiners for view [A|1]
>    [testng] 
>    [testng] -------------------------------------------------------------------
>    [testng] GMS: address=C, cluster=OverlappingMergeTest, physical address=10.16.94.42:27201
>    [testng] -------------------------------------------------------------------
>    [testng] 185064 [TRACE] GMS: - C: initial_mbrs are B A 
>    [testng] 185064 [DEBUG] GMS: - election results: {A=2}
>    [testng] 185064 [DEBUG] GMS: - sending JOIN(C) to A
>    [testng] 185108 [TRACE] GMS: - A: new members=[C], suspected=[], leaving=[], new view: [A|2] [A, B, C]
>    [testng] 185108 [TRACE] GMS: - A: mcasting view [A|2] [A, B, C] (3 mbrs)
>    [testng] 
>    [testng] 185117 [DEBUG] GMS: - A: installing view [A|2] [A, B, C]
>    [testng] 185118 [DEBUG] GMS: - B: installing view [A|2] [A, B, C]
>    [testng] 185119 [TRACE] GMS: - A: received all 2 ACKs from members for view [A|2]
>    [testng] 185148 [TRACE] GMS: - C: JOIN-RSP=[A|2] [A, B, C] [size=3]
>    [testng] 
>    [testng] 
>    [testng] 185149 [DEBUG] GMS: - C: installing view [A|2] [A, B, C]
>    [testng] 185151 [TRACE] GMS: - A: received all ACKs (1) from joiners for view [A|2]
>    [testng] 
>    [testng] -------------------------------------------------------------------
>    [testng] GMS: address=D, cluster=OverlappingMergeTest, physical address=10.16.94.42:27202
>    [testng] -------------------------------------------------------------------
>    [testng] 185164 [TRACE] GMS: - D: initial_mbrs are B C A 
>    [testng] 185164 [DEBUG] GMS: - election results: {A=3}
>    [testng] 185164 [DEBUG] GMS: - sending JOIN(D) to A
>    [testng] 185203 [TRACE] GMS: - A: new members=[D], suspected=[], leaving=[], new view: [A|3] [A, B, C, D]
>    [testng] 185203 [TRACE] GMS: - A: mcasting view [A|3] [A, B, C, D] (4 mbrs)
>    [testng] 
>    [testng] 185210 [DEBUG] GMS: - A: installing view [A|3] [A, B, C, D]
>    [testng] 185211 [DEBUG] GMS: - B: installing view [A|3] [A, B, C, D]
>    [testng] 185211 [DEBUG] GMS: - C: installing view [A|3] [A, B, C, D]
>    [testng] 185213 [TRACE] GMS: - A: received all 3 ACKs from members for view [A|3]
>    [testng] 185242 [TRACE] GMS: - D: JOIN-RSP=[A|3] [A, B, C, D] [size=4]
>    [testng] 
>    [testng] 
>    [testng] 185242 [DEBUG] GMS: - D: installing view [A|3] [A, B, C, D]
>    [testng] 185242 [TRACE] GMS: - A: received all ACKs (1) from joiners for view [A|3]
>    [testng] 
>    [testng]  ==== Injecting view [A|4] [A, C, B] into A, B and C ====
>    [testng] 185243 [DEBUG] GMS: - A: installing view [A|4] [A, C, B]
>    [testng] 185243 [DEBUG] GMS: - B: installing view [A|4] [A, C, B]
>    [testng] 185244 [DEBUG] GMS: - C: installing view [A|4] [A, C, B]
>    [testng] 
>    [testng]  ==== Injecting view [B|4] [B, A, C, D] into D ====
>    [testng] 
>    [testng] 185245 [DEBUG] GMS: - D: installing view [B|4] [B, A, C, D]
>    [testng] A: [A|4] [A, C, B]
>    [testng] B: [A|4] [A, C, B]
>    [testng] C: [A|4] [A, C, B]
>    [testng] D: [B|4] [B, A, C, D]
>    [testng] 
>    [testng] ==== Injecting a merge event into A, B, C and D====
>    [testng] 185251 [TRACE] GMS: - A: got merge response from A, merge_id=A::3, merge data is sender=A, view=[A|4] [A, C, B], digest=C: [0 (0)], B: [0 (0)], A: [4 (4)]
>    [testng] 185253 [TRACE] GMS: - B: queue is suspended; request MERGE(4 views) is discarded
>    [testng] 185255 [TRACE] GMS: - C: queue is suspended; request MERGE(4 views) is discarded
>    [testng] 185255 [TRACE] GMS: - A: got merge response from B, merge_id=A::3, merge data is sender=B, view=[A|4] [A, C, B], digest=C: [0 (0)], B: [0 (1)], A: [4 (4)]
>    [testng] 190286 [TRACE] GMS: - A: mcasting view MergeView::[A|5] [A, B, C], subgroups=[A|4] [A, C, B], [A|4] [A, C, B] (3 mbrs)
>    [testng] 
>    [testng] 190286 [TRACE] GMS: - B: mcasting view MergeView::[A|5] [A, B, C], subgroups=[A|4] [A, C, B], [A|4] [A, C, B] (3 mbrs)
>    [testng] 
>    [testng] 190317 [DEBUG] GMS: - A: installing view MergeView::[A|5] [A, B, C], subgroups=[A|4] [A, C, B], [A|4] [A, C, B]
>    [testng] 190318 [DEBUG] GMS: - B: installing view MergeView::[A|5] [A, B, C], subgroups=[A|4] [A, C, B], [A|4] [A, C, B]
>    [testng] 190318 [DEBUG] GMS: - C: installing view MergeView::[A|5] [A, B, C], subgroups=[A|4] [A, C, B], [A|4] [A, C, B]
>    [testng] 190320 [TRACE] GMS: - A: received all 3 ACKs from members for view [A|5]
>    [testng] 190320 [TRACE] GMS: - B: received all 3 ACKs from members for view [A|5]
>    [testng] A: [A|5] [A, B, C] (coord=true)
>    [testng] B: [A|5] [A, B, C] (coord=false)
>    [testng] C: [A|5] [A, B, C] (coord=false)
>    [testng] D: [B|4] [B, A, C, D] (coord=false)
>    [testng] 195277 [DEBUG] GMS: - D: sending LEAVE request to B
>    [testng] FAIL: [1] org.jgroups.tests.OverlappingMergeTest.testMergeWithDifferentPartitions()
> {noformat}
>  Whenever this test fails, I see that the queues are suspended on the initial merge attempt.

--
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

From issues at jboss.org  Mon Mar 24 13:25:13 2014
From: issues at jboss.org (Richard Achmatowicz (JIRA))
Date: Mon, 24 Mar 2014 13:25:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1805) OverlappingMergeTest
 testMergeWithDifferentPartitions fails to create correct merged view
In-Reply-To: <JIRA.12534032.1393962618000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534032.1393962618000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534032.1393962618000.3646.1395681913334@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JGRP-1805?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12955775#comment-12955775 ] 

Richard Achmatowicz edited comment on JGRP-1805 at 3/24/14 1:25 PM:
--------------------------------------------------------------------

An example of this failure of testMergeWithDifferentPartitions with the additional logging: (one failing copy run in the QA lab, one passing copy run on my local machine)

passing test:
{noformat}
------------- testMergeWithDifferentPartitions -----------
-------------------------------------------------------------------
GMS: address=D, cluster=OverlappingMergeTest, physical address=127.0.0.1:48135
-------------------------------------------------------------------
69904 [TRACE] GMS: - D: initial_mbrs are A
69904 [DEBUG] GMS: - election results: {A=1}
69904 [DEBUG] GMS: - sending JOIN(D) to A
69982 [TRACE] GMS: - D: JOIN-RSP=[A|3] [A, B, C, D] [size=4]
69982 [DEBUG] GMS: - D: installing view [A|3] [A, B, C, D]

 ==== Injecting view [A|4] [A, C, B] into A, B and C ====
69983 [DEBUG] GMS: - A: installing view [A|4] [A, C, B]
69984 [DEBUG] GMS: - B: installing view [A|4] [A, C, B]
69984 [DEBUG] GMS: - C: installing view [A|4] [A, C, B]

 ==== Injecting view [B|4] [B, A, C, D] into D ====

69985 [DEBUG] GMS: - D: installing view [B|4] [B, A, C, D]
A: [A|4] [A, C, B]
B: [A|4] [A, C, B]
C: [A|4] [A, C, B]
D: [B|4] [B, A, C, D]

==== Injecting a merge event into A, B, C and D====
Enabling TRACE debugging for GMS, MERGE2 and Discovery
70012 [DEBUG] GMS: - D: installing view MergeView::[A|5] [A, D, C, B], subgroups=[A|4] [A, C, B], [A|4] [A, C, B], [B|4] [D]
70013 [TRACE] GMS: - D: mcasting view MergeView::[A|5] [A, D, C, B], subgroups=[A|4] [A, C, B], [A|4] [A, C, B], [B|4] [D] (4 mbrs)
70043 [TRACE] GMS: - D: received all 4 ACKs from members for view [A|5]
Disabling TRACE debugging for GMS, MERGE2 and Discovery
A: [A|5] [A, D, C, B] (coord=true)
B: [A|5] [A, D, C, B] (coord=false)
C: [A|5] [A, D, C, B] (coord=false)
D: [A|5] [A, D, C, B] (coord=false)
{noformat}

failing test:
{noformat}
------------- testMergeWithDifferentPartitions -----------

-------------------------------------------------------------------
GMS: address=D, cluster=OverlappingMergeTest, physical address=10.16.92.187:27202
-------------------------------------------------------------------
182881 [TRACE] GMS: - D: initial_mbrs are C A
182882 [DEBUG] GMS: - election results: {A=2}
182882 [DEBUG] GMS: - sending JOIN(D) to A
182986 [TRACE] GMS: - D: JOIN-RSP=[A|3] [A, B, C, D] [size=4]
182986 [DEBUG] GMS: - D: installing view [A|3] [A, B, C, D]

 ==== Injecting view [A|4] [A, C, B] into A, B and C ====
182986 [DEBUG] GMS: - A: installing view [A|4] [A, C, B]
182987 [DEBUG] GMS: - B: installing view [A|4] [A, C, B]
182988 [DEBUG] GMS: - C: installing view [A|4] [A, C, B]

 ==== Injecting view [B|4] [B, A, C, D] into D ====

182989 [DEBUG] GMS: - D: installing view [B|4] [B, A, C, D]
A: [A|4] [A, C, B]
B: [A|4] [A, C, B]
C: [A|4] [A, C, B]
D: [B|4] [B, A, C, D]

==== Injecting a merge event into A, B, C and D====
Enabling TRACE debugging for GMS, MERGE2 and Discovery
Disabling TRACE debugging for GMS, MERGE2 and Discovery
A: [A|5] [A, B, C] (coord=true)
B: [A|5] [A, B, C] (coord=false)
C: [A|5] [A, B, C] (coord=false)
D: [B|4] [B, A, C, D] (coord=false)
{noformat}

It appears that there is no activity after the merge event is injected in the failing case, as there are no TRACE messages appearing.

                
      was (Author: rachmato):
    An example of this failure of testMergeWithDifferentPartitions with the additional logging: (one failing copy run in the QA lab, one passing copy run on my local machine)

passing test:
{noformat}
------------- testMergeWithDifferentPartitions -----------
-------------------------------------------------------------------
GMS: address=D, cluster=OverlappingMergeTest, physical address=127.0.0.1:48135
-------------------------------------------------------------------
69904 [TRACE] GMS: - D: initial_mbrs are A
69904 [DEBUG] GMS: - election results: {A=1}
69904 [DEBUG] GMS: - sending JOIN(D) to A
69982 [TRACE] GMS: - D: JOIN-RSP=[A|3] [A, B, C, D] [size=4]
69982 [DEBUG] GMS: - D: installing view [A|3] [A, B, C, D]

 ==== Injecting view [A|4] [A, C, B] into A, B and C ====
69983 [DEBUG] GMS: - A: installing view [A|4] [A, C, B]
69984 [DEBUG] GMS: - B: installing view [A|4] [A, C, B]
69984 [DEBUG] GMS: - C: installing view [A|4] [A, C, B]

 ==== Injecting view [B|4] [B, A, C, D] into D ====

69985 [DEBUG] GMS: - D: installing view [B|4] [B, A, C, D]
A: [A|4] [A, C, B]
B: [A|4] [A, C, B]
C: [A|4] [A, C, B]
D: [B|4] [B, A, C, D]

==== Injecting a merge event into A, B, C and D====
Enabling TRACE debugging for GMS, MERGE2 and Discovery
70012 [DEBUG] GMS: - D: installing view MergeView::[A|5] [A, D, C, B], subgroups=[A|4] [A, C, B], [A|4] [A, C, B], [B|4] [D]
70013 [TRACE] GMS: - D: mcasting view MergeView::[A|5] [A, D, C, B], subgroups=[A|4] [A, C, B], [A|4] [A, C, B], [B|4] [D] (4 mbrs)
70043 [TRACE] GMS: - D: received all 4 ACKs from members for view [A|5]
Disabling TRACE debugging for GMS, MERGE2 and Discovery
A: [A|5] [A, D, C, B] (coord=true)
B: [A|5] [A, D, C, B] (coord=false)
C: [A|5] [A, D, C, B] (coord=false)
D: [A|5] [A, D, C, B] (coord=false)
{noformat}

failing test:
{noformat}
------------- testMergeWithDifferentPartitions -----------

-------------------------------------------------------------------
GMS: address=D, cluster=OverlappingMergeTest, physical address=10.16.92.187:27202
-------------------------------------------------------------------
182881 [TRACE] GMS: - D: initial_mbrs are C A
182882 [DEBUG] GMS: - election results: {A=2}
182882 [DEBUG] GMS: - sending JOIN(D) to A
182986 [TRACE] GMS: - D: JOIN-RSP=[A|3] [A, B, C, D] [size=4]
182986 [DEBUG] GMS: - D: installing view [A|3] [A, B, C, D]

 ==== Injecting view [A|4] [A, C, B] into A, B and C ====
182986 [DEBUG] GMS: - A: installing view [A|4] [A, C, B]
182987 [DEBUG] GMS: - B: installing view [A|4] [A, C, B]
182988 [DEBUG] GMS: - C: installing view [A|4] [A, C, B]

 ==== Injecting view [B|4] [B, A, C, D] into D ====

182989 [DEBUG] GMS: - D: installing view [B|4] [B, A, C, D]
A: [A|4] [A, C, B]
B: [A|4] [A, C, B]
C: [A|4] [A, C, B]
D: [B|4] [B, A, C, D]

==== Injecting a merge event into A, B, C and D====
Enabling TRACE debugging for GMS, MERGE2 and Discovery
Disabling TRACE debugging for GMS, MERGE2 and Discovery
A: [A|5] [A, B, C] (coord=true)
B: [A|5] [A, B, C] (coord=false)
C: [A|5] [A, B, C] (coord=false)
D: [B|4] [B, A, C, D] (coord=false)
{noformat}

It appears that there is no activity after the merge even is injected in the failing case, as there are no TRACE messages appearing.

                  
> OverlappingMergeTest testMergeWithDifferentPartitions fails to create correct merged view
> -----------------------------------------------------------------------------------------
>
>                 Key: JGRP-1805
>                 URL: https://issues.jboss.org/browse/JGRP-1805
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.2.13
>         Environment: RHEL
>            Reporter: Richard Achmatowicz
>            Assignee: Bela Ban
>             Fix For: 3.2.13
>
>
> This test does the following:
> - creates four channels a,b,c,d
> - injects views A: {A,C,B}, B:{A,C,B}, C:{A,C,B} and D: {B,A,C,D}
> - injects a merge event in each of channels A,B,C,D representing these four views
> - checks that all channels have the final view of size 4
> The test fails intermittently on RHEL, with the same failure each time:
> {noformat}
> 181595 [DEBUG] GMS: - A: installing view [A|2] [A]
>    [testng] 181596 [TRACE] GMS: - A: received all 1 ACKs from members for view [A|2]
>    [testng] 181866 [TRACE] GMS: - view [A|3] [] is empty: will not multicast it (last view)
>    [testng] 
>    [testng] -------------------------------------------------------------------
>    [testng] GMS: address=A, cluster=OverlappingMergeTest, physical address=10.16.94.42:27199
>    [testng] -------------------------------------------------------------------
>    [testng] 184954 [TRACE] GMS: - A: no initial members discovered: creating group as first member
>    [testng] 184954 [DEBUG] GMS: - A: installing view [A|0] [A]
>    [testng] 184955 [DEBUG] GMS: - created group (first member). My view is [A|0], impl is org.jgroups.protocols.pbcast.CoordGmsImpl
>    [testng] 
>    [testng] -------------------------------------------------------------------
>    [testng] GMS: address=B, cluster=OverlappingMergeTest, physical address=10.16.94.42:27200
>    [testng] -------------------------------------------------------------------
>    [testng] 184961 [TRACE] GMS: - B: initial_mbrs are A 
>    [testng] 184961 [DEBUG] GMS: - election results: {A=1}
>    [testng] 184961 [DEBUG] GMS: - sending JOIN(B) to A
>    [testng] 185013 [TRACE] GMS: - A: new members=[B], suspected=[], leaving=[], new view: [A|1] [A, B]
>    [testng] 185014 [TRACE] GMS: - A: mcasting view [A|1] [A, B] (2 mbrs)
>    [testng] 
>    [testng] 185025 [DEBUG] GMS: - A: installing view [A|1] [A, B]
>    [testng] 185026 [TRACE] GMS: - A: received all 1 ACKs from members for view [A|1]
>    [testng] 185055 [TRACE] GMS: - B: JOIN-RSP=[A|1] [A, B] [size=2]
>    [testng] 
>    [testng] 
>    [testng] 185055 [DEBUG] GMS: - B: installing view [A|1] [A, B]
>    [testng] 185057 [TRACE] GMS: - A: received all ACKs (1) from joiners for view [A|1]
>    [testng] 
>    [testng] -------------------------------------------------------------------
>    [testng] GMS: address=C, cluster=OverlappingMergeTest, physical address=10.16.94.42:27201
>    [testng] -------------------------------------------------------------------
>    [testng] 185064 [TRACE] GMS: - C: initial_mbrs are B A 
>    [testng] 185064 [DEBUG] GMS: - election results: {A=2}
>    [testng] 185064 [DEBUG] GMS: - sending JOIN(C) to A
>    [testng] 185108 [TRACE] GMS: - A: new members=[C], suspected=[], leaving=[], new view: [A|2] [A, B, C]
>    [testng] 185108 [TRACE] GMS: - A: mcasting view [A|2] [A, B, C] (3 mbrs)
>    [testng] 
>    [testng] 185117 [DEBUG] GMS: - A: installing view [A|2] [A, B, C]
>    [testng] 185118 [DEBUG] GMS: - B: installing view [A|2] [A, B, C]
>    [testng] 185119 [TRACE] GMS: - A: received all 2 ACKs from members for view [A|2]
>    [testng] 185148 [TRACE] GMS: - C: JOIN-RSP=[A|2] [A, B, C] [size=3]
>    [testng] 
>    [testng] 
>    [testng] 185149 [DEBUG] GMS: - C: installing view [A|2] [A, B, C]
>    [testng] 185151 [TRACE] GMS: - A: received all ACKs (1) from joiners for view [A|2]
>    [testng] 
>    [testng] -------------------------------------------------------------------
>    [testng] GMS: address=D, cluster=OverlappingMergeTest, physical address=10.16.94.42:27202
>    [testng] -------------------------------------------------------------------
>    [testng] 185164 [TRACE] GMS: - D: initial_mbrs are B C A 
>    [testng] 185164 [DEBUG] GMS: - election results: {A=3}
>    [testng] 185164 [DEBUG] GMS: - sending JOIN(D) to A
>    [testng] 185203 [TRACE] GMS: - A: new members=[D], suspected=[], leaving=[], new view: [A|3] [A, B, C, D]
>    [testng] 185203 [TRACE] GMS: - A: mcasting view [A|3] [A, B, C, D] (4 mbrs)
>    [testng] 
>    [testng] 185210 [DEBUG] GMS: - A: installing view [A|3] [A, B, C, D]
>    [testng] 185211 [DEBUG] GMS: - B: installing view [A|3] [A, B, C, D]
>    [testng] 185211 [DEBUG] GMS: - C: installing view [A|3] [A, B, C, D]
>    [testng] 185213 [TRACE] GMS: - A: received all 3 ACKs from members for view [A|3]
>    [testng] 185242 [TRACE] GMS: - D: JOIN-RSP=[A|3] [A, B, C, D] [size=4]
>    [testng] 
>    [testng] 
>    [testng] 185242 [DEBUG] GMS: - D: installing view [A|3] [A, B, C, D]
>    [testng] 185242 [TRACE] GMS: - A: received all ACKs (1) from joiners for view [A|3]
>    [testng] 
>    [testng]  ==== Injecting view [A|4] [A, C, B] into A, B and C ====
>    [testng] 185243 [DEBUG] GMS: - A: installing view [A|4] [A, C, B]
>    [testng] 185243 [DEBUG] GMS: - B: installing view [A|4] [A, C, B]
>    [testng] 185244 [DEBUG] GMS: - C: installing view [A|4] [A, C, B]
>    [testng] 
>    [testng]  ==== Injecting view [B|4] [B, A, C, D] into D ====
>    [testng] 
>    [testng] 185245 [DEBUG] GMS: - D: installing view [B|4] [B, A, C, D]
>    [testng] A: [A|4] [A, C, B]
>    [testng] B: [A|4] [A, C, B]
>    [testng] C: [A|4] [A, C, B]
>    [testng] D: [B|4] [B, A, C, D]
>    [testng] 
>    [testng] ==== Injecting a merge event into A, B, C and D====
>    [testng] 185251 [TRACE] GMS: - A: got merge response from A, merge_id=A::3, merge data is sender=A, view=[A|4] [A, C, B], digest=C: [0 (0)], B: [0 (0)], A: [4 (4)]
>    [testng] 185253 [TRACE] GMS: - B: queue is suspended; request MERGE(4 views) is discarded
>    [testng] 185255 [TRACE] GMS: - C: queue is suspended; request MERGE(4 views) is discarded
>    [testng] 185255 [TRACE] GMS: - A: got merge response from B, merge_id=A::3, merge data is sender=B, view=[A|4] [A, C, B], digest=C: [0 (0)], B: [0 (1)], A: [4 (4)]
>    [testng] 190286 [TRACE] GMS: - A: mcasting view MergeView::[A|5] [A, B, C], subgroups=[A|4] [A, C, B], [A|4] [A, C, B] (3 mbrs)
>    [testng] 
>    [testng] 190286 [TRACE] GMS: - B: mcasting view MergeView::[A|5] [A, B, C], subgroups=[A|4] [A, C, B], [A|4] [A, C, B] (3 mbrs)
>    [testng] 
>    [testng] 190317 [DEBUG] GMS: - A: installing view MergeView::[A|5] [A, B, C], subgroups=[A|4] [A, C, B], [A|4] [A, C, B]
>    [testng] 190318 [DEBUG] GMS: - B: installing view MergeView::[A|5] [A, B, C], subgroups=[A|4] [A, C, B], [A|4] [A, C, B]
>    [testng] 190318 [DEBUG] GMS: - C: installing view MergeView::[A|5] [A, B, C], subgroups=[A|4] [A, C, B], [A|4] [A, C, B]
>    [testng] 190320 [TRACE] GMS: - A: received all 3 ACKs from members for view [A|5]
>    [testng] 190320 [TRACE] GMS: - B: received all 3 ACKs from members for view [A|5]
>    [testng] A: [A|5] [A, B, C] (coord=true)
>    [testng] B: [A|5] [A, B, C] (coord=false)
>    [testng] C: [A|5] [A, B, C] (coord=false)
>    [testng] D: [B|4] [B, A, C, D] (coord=false)
>    [testng] 195277 [DEBUG] GMS: - D: sending LEAVE request to B
>    [testng] FAIL: [1] org.jgroups.tests.OverlappingMergeTest.testMergeWithDifferentPartitions()
> {noformat}
>  Whenever this test fails, I see that the queues are suspended on the initial merge attempt.

--
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

From issues at jboss.org  Mon Mar 24 13:51:14 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 24 Mar 2014 13:51:14 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2709) Connector Subsystem is
 Missing connection-definitions.clear-statistics resource key
In-Reply-To: <JIRA.12528624.1388936027000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528624.1388936027000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528624.1388936027000.3674.1395683474232@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2709?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated WFLY-2709:
------------------------------------------

        Bugzilla Update: Perform
    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1080126

    
> Connector Subsystem is Missing connection-definitions.clear-statistics resource key
> -----------------------------------------------------------------------------------
>
>                 Key: WFLY-2709
>                 URL: https://issues.jboss.org/browse/WFLY-2709
>             Project: WildFly
>          Issue Type: Patch
>      Security Level: Public(Everyone can see) 
>          Components: JCA
>    Affects Versions: 8.0.0.CR1
>            Reporter: Philippe Marschall
>            Assignee: Philippe Marschall
>             Fix For: 8.0.0.Final
>
>
> The connector subsystem is missing the resource key: {{?connection-definitions.clear-statistics?}}. This results in the following exception when looking at the connection definitions of a resource adapter in VisualVM:
> {code}
> 16:06:10,884 ERROR [org.jboss.as.controller.management-operation] (RMI TCP Connection(2)-192.168.0.21) JBAS014612: Operation ("read-resource-description") failed - address: ([
>     ("deployment" => "XADisk.rar"),
>     ("subsystem" => "resource-adapters"),
>     ("statistics" => "statistics"),
>     ("resource-adapter" => "XADisk.rar"),
>     ("connection-definitions" => "java:global/XADiskCF")
> ]): java.util.MissingResourceException: Can't find resource for bundle java.util.PropertyResourceBundle, key connection-definitions.clear-statistics
> 	at java.util.ResourceBundle.getObject(ResourceBundle.java:450) [rt.jar:1.8.0-ea]
> 	at java.util.ResourceBundle.getString(ResourceBundle.java:407) [rt.jar:1.8.0-ea]
> 	at org.jboss.as.controller.descriptions.StandardResourceDescriptionResolver.getOperationDescription(StandardResourceDescriptionResolver.java:184)
> 	at org.jboss.as.controller.descriptions.DefaultOperationDescriptionProvider.getModelDescription(DefaultOperationDescriptionProvider.java:157)
> 	at org.jboss.as.controller.operations.global.ReadResourceDescriptionHandler.doExecuteInternal(ReadResourceDescriptionHandler.java:213)
> 	at org.jboss.as.controller.operations.global.ReadResourceDescriptionHandler.doExecute(ReadResourceDescriptionHandler.java:157)
> 	at org.jboss.as.controller.operations.global.ReadResourceDescriptionHandler.execute(ReadResourceDescriptionHandler.java:150)
> 	at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:591)
> 	at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:469)
> 	at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:273)
> 	at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:268)
> 	at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:272)
> 	at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:146)
> 	at org.jboss.as.jmx.model.ResourceAccessControlUtil.getResourceAccess(ResourceAccessControlUtil.java:85)
> 	at org.jboss.as.jmx.model.ResourceAccessControlUtil.getResourceAccessWithInstanceNotFoundExceptionIfNotAccessible(ResourceAccessControlUtil.java:70)
> 	at org.jboss.as.jmx.model.ModelControllerMBeanHelper.getMBeanInfo(ModelControllerMBeanHelper.java:199)
> 	at org.jboss.as.jmx.model.ModelControllerMBeanServerPlugin.getMBeanInfo(ModelControllerMBeanServerPlugin.java:131)
> 	at org.jboss.as.jmx.PluggableMBeanServerImpl.getMBeanInfo(PluggableMBeanServerImpl.java:582)
> 	at org.jboss.as.jmx.PluggableMBeanServerImpl.getMBeanInfo(PluggableMBeanServerImpl.java:570)
> 	at javax.management.remote.rmi.RMIConnectionImpl.doOperation(RMIConnectionImpl.java:1460) [rt.jar:1.8.0-ea]
> 	at javax.management.remote.rmi.RMIConnectionImpl.access$300(RMIConnectionImpl.java:76) [rt.jar:1.8.0-ea]
> 	at javax.management.remote.rmi.RMIConnectionImpl$PrivilegedOperation.run(RMIConnectionImpl.java:1307) [rt.jar:1.8.0-ea]
> 	at javax.management.remote.rmi.RMIConnectionImpl.doPrivilegedOperation(RMIConnectionImpl.java:1399) [rt.jar:1.8.0-ea]
> 	at javax.management.remote.rmi.RMIConnectionImpl.getMBeanInfo(RMIConnectionImpl.java:904) [rt.jar:1.8.0-ea]
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.8.0-ea]
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) [rt.jar:1.8.0-ea]
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.8.0-ea]
> 	at java.lang.reflect.Method.invoke(Method.java:483) [rt.jar:1.8.0-ea]
> 	at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:323) [rt.jar:1.8.0-ea]
> 	at sun.rmi.transport.Transport$1.run(Transport.java:178) [rt.jar:1.8.0-ea]
> 	at sun.rmi.transport.Transport$1.run(Transport.java:175) [rt.jar:1.8.0-ea]
> 	at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.8.0-ea]
> 	at sun.rmi.transport.Transport.serviceCall(Transport.java:174) [rt.jar:1.8.0-ea]
> 	at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:557) [rt.jar:1.8.0-ea]
> 	at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:812) [rt.jar:1.8.0-ea]
> 	at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:671) [rt.jar:1.8.0-ea]
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0-ea]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0-ea]
> 	at java.lang.Thread.run(Thread.java:744) [rt.jar:1.8.0-ea]
> {code}

--
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


From issues at jboss.org  Mon Mar 24 14:07:13 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 24 Mar 2014 14:07:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-439) Package builder unable to
 find declared array class
In-Reply-To: <JIRA.12533030.1393157795000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12533030.1393157795000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12533030.1393157795000.3732.1395684433181@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/DROOLS-439?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12955794#comment-12955794 ] 

RH Bugzilla Integration commented on DROOLS-439:
------------------------------------------------

Mario Fusco <mfusco at redhat.com> changed the Status of [bug 1079950|https://bugzilla.redhat.com/show_bug.cgi?id=1079950] from ASSIGNED to MODIFIED
                
> Package builder unable to find declared array class
> ---------------------------------------------------
>
>                 Key: DROOLS-439
>                 URL: https://issues.jboss.org/browse/DROOLS-439
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 6.0.1.Final
>            Reporter: Mark Sullivan
>            Assignee: Mario Fusco
>
> When declaring a fact type with an array field, where the array type is declared in the same package, for example:
> {code}
> declare Owner
>   name : String
> end
> declare Pet
>   owners : Owner[]
> end
> {code}
> The following build error occurs:
> {code}
> [Message [id=1, level=ERROR, path=pets.drl, line=5, column=0
>    text=Unable to find class 'Owner']]
> {code}
> This error doesn't always occur when an array field is declared. It's dependent on the order in which each fact type is processed. 
> PackageBuilder attempts to order fact types for processing based on the declared super type and attribute types.
> The following loop in *PackageBuilder.sortByHierarchy()* processes each field looking for field type dependencies: 
> {code}
>   for (TypeFieldDescr field : tdescr.getFields().values()) {
>     QualifiedName typeName = new QualifiedName(field.getPattern().getObjectType());
>     if (!hasCircularDependency(name, typeName, taxonomy)) {
>       supers.add(typeName);
>     }
>   }
> {code}
> However I don't think it correctly spots the dependency when the field type is an array.
> This issue can be worked around by declaring an unused field of the same type as the array:
> {code}
> declare Owner
>   name : String
> end
> declare Pet
>   owners : Owner[]
>   _unused: Owner
> end
> {code}

--
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

From issues at jboss.org  Mon Mar 24 14:37:13 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 24 Mar 2014 14:37:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (SECURITY-805) Overload
 SecurityVaultFactory.get() to be able to specify the classloader
In-Reply-To: <JIRA.12535004.1394795116000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12535004.1394795116000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12535004.1394795116000.3779.1395686233658@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/SECURITY-805?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12955804#comment-12955804 ] 

RH Bugzilla Integration commented on SECURITY-805:
--------------------------------------------------

Kabir Khan <kkhan at redhat.com> changed the Status of [bug 1079930|https://bugzilla.redhat.com/show_bug.cgi?id=1079930] from ASSIGNED to MODIFIED
                
> Overload SecurityVaultFactory.get() to be able to specify the classloader
> -------------------------------------------------------------------------
>
>                 Key: SECURITY-805
>                 URL: https://issues.jboss.org/browse/SECURITY-805
>             Project: PicketBox 
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>            Reporter: Kabir Khan
>            Assignee: Kabir Khan
>             Fix For: PicketBox_4_0_21.Beta2, PicketBox_4_0_19.SP5
>
>         Attachments: SECURITY-805-2.diff, SECURITY-805.diff
>
>
> To work better with modular class loading in WF

--
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

From issues at jboss.org  Mon Mar 24 15:23:12 2014
From: issues at jboss.org (Brett Donahue (JIRA))
Date: Mon, 24 Mar 2014 15:23:12 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1813) JDBC_PING failes to recover
 for corruption issue
In-Reply-To: <JIRA.12535937.1395688882995@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12535937.1395688882995@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12535937.1395688882995.3823.1395688992898@jira02.app.mwc.hst.phx2.redhat.com>

Brett Donahue created JGRP-1813:
-----------------------------------

             Summary: JDBC_PING failes to recover for corruption issue
                 Key: JGRP-1813
                 URL: https://issues.jboss.org/browse/JGRP-1813
             Project: JGroups
          Issue Type: Feature Request
    Affects Versions: 3.4
         Environment: Windows 7
            Reporter: Brett Donahue
            Assignee: Bela Ban
            Priority: Minor


heap space was exhausted and issues occurred.  In the end, one node in the cluster must have corrupted the data in the JDBC_PING table.   From this point onward, our log is full of these (every two seconds):

2014 03 23 04:00:25#+0100#ERROR#org.jgroups.protocols.SMP_JDBC_PING##anonymous#Thread-15###Error java.io.EOFException: null
        at java.io.DataInputStream.readUnsignedShort(DataInputStream.java:340)
        at org.jgroups.stack.IpAddress.readFrom(IpAddress.java:226)
        at org.jgroups.util.Util.readAddress(Util.java:929)
        at org.jgroups.util.Util.readAddresses(Util.java:1047)
        at org.jgroups.protocols.PingData.readFrom(PingData.java:163)
        at org.jgroups.util.Util.streamableFromByteBuffer(Util.java:753)
        at org.jgroups.protocols.Discovery.deserialize(Discovery.java:625)
        at org.jgroups.protocols.JDBC_PING.readAll(JDBC_PING.java:221)
        at org.jgroups.protocols.JDBC_PING.readAll(JDBC_PING.java:201)
        at org.jgroups.protocols.FILE_PING.fetchClusterMembers(FILE_PING.java:68)
        at org.jgroups.protocols.Discovery.sendDiscoveryRequest(Discovery.java:263)
        at org.jgroups.protocols.Discovery.findMembers(Discovery.java:227)
        at org.jgroups.protocols.Discovery.findInitialMembers(Discovery.java:208)
        at org.jgroups.protocols.Discovery.down(Discovery.java:551)
        at org.jgroups.protocols.FILE_PING.down(FILE_PING.java:101)
        at org.jgroups.protocols.MERGE2.down(MERGE2.java:185)
        at org.jgroups.protocols.FD_SOCK.down(FD_SOCK.java:363)
        at org.jgroups.protocols.FD.down(FD.java:307)
        at org.jgroups.protocols.VERIFY_SUSPECT.down(VERIFY_SUSPECT.java:84)
        at org.jgroups.protocols.BARRIER.down(BARRIER.java:95)
        at org.jgroups.protocols.pbcast.NAKACK2.down(NAKACK2.java:533)
        at org.jgroups.protocols.UNICAST3.down(UNICAST3.java:575)
        at org.jgroups.protocols.pbcast.STABLE.down(STABLE.java:347)
        at org.jgroups.protocols.ENCRYPT.down(ENCRYPT.java:925)
        at org.jgroups.protocols.pbcast.ClientGmsImpl.findInitialMembers(ClientGmsImpl.java:201)
        at org.jgroups.protocols.pbcast.ClientGmsImpl.joinInternal(ClientGmsImpl.java:75)
        at org.jgroups.protocols.pbcast.ClientGmsImpl.join(ClientGmsImpl.java:40)
        at org.jgroups.protocols.pbcast.GMS.down(GMS.java:1052)
        at org.jgroups.protocols.FlowControl.down(FlowControl.java:340)
        at org.jgroups.protocols.FRAG2.down(FRAG2.java:136)
        at org.jgroups.protocols.pbcast.STATE_TRANSFER.down(STATE_TRANSFER.java:237)
        at org.jgroups.stack.ProtocolStack.down(ProtocolStack.java:1024)
        at org.jgroups.JChannel.down(JChannel.java:760)
        at org.jgroups.JChannel._connect(JChannel.java:538)
        at org.jgroups.JChannel.connect(JChannel.java:290)
        at org.jgroups.JChannel.connect(JChannel.java:275)
        at com.sap.mobile.platform.server.cluster.service.impl.ClusterCommunicationsJGroupImpl.startCommunications(ClusterCommunicationsJGroupImpl.java:45)
        at com.sap.mobile.platform.server.cluster.service.impl.ClusterCommunicationsJGroupImpl.<init>(ClusterCommunicationsJGroupImpl.java:59)
        at com.sap.mobile.platform.server.cluster.service.impl.ClusterServiceImpl.run(ClusterServiceImpl.java:187)
        at java.lang.Thread.run(Thread.java:791)


--
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

From issues at jboss.org  Mon Mar 24 17:43:12 2014
From: issues at jboss.org (Stuart Douglas (JIRA))
Date: Mon, 24 Mar 2014 17:43:12 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3157) Add support for serving
 static resources from an external location
In-Reply-To: <JIRA.12535954.1395697332229@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12535954.1395697332229@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12535954.1395697332229.4005.1395697392888@jira02.app.mwc.hst.phx2.redhat.com>

Stuart Douglas created WFLY-3157:
------------------------------------

             Summary: Add support for serving static resources from an external location
                 Key: WFLY-3157
                 URL: https://issues.jboss.org/browse/WFLY-3157
             Project: WildFly
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: Web (Undertow)
            Reporter: Stuart Douglas
            Assignee: Stuart Douglas




--
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

From issues at jboss.org  Mon Mar 24 17:51:13 2014
From: issues at jboss.org (Stefan Dilk (JIRA))
Date: Mon, 24 Mar 2014 17:51:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3158) @Model does not work
In-Reply-To: <JIRA.12535955.1395697803525@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12535955.1395697803525@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12535955.1395697803525.4009.1395697873078@jira02.app.mwc.hst.phx2.redhat.com>

Stefan Dilk created WFLY-3158:
---------------------------------

             Summary: @Model does not work
                 Key: WFLY-3158
                 URL: https://issues.jboss.org/browse/WFLY-3158
             Project: WildFly
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: CDI / Weld, JSF
    Affects Versions: 8.0.0.Final
            Reporter: Stefan Dilk
            Assignee: Stuart Douglas


hi,

wildfly not work with @Model annotated beans in JSF.
@RequestScoped and @Named work.
in this ticket it is already reported, but closed:
https://issues.jboss.org/browse/WFLY-2372
in the related CDI ticket the change is made, so please implement this in the next wildfly update. in glassfish4 the @Model annotation works fine.

--
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

From issues at jboss.org  Mon Mar 24 21:59:13 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 24 Mar 2014 21:59:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1013) Can't set attribute "suffix"
 on web access-log
In-Reply-To: <JIRA.12471975.1344415283000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12471975.1344415283000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12471975.1344415283000.4099.1395712753008@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-1013?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated WFLY-1013:
------------------------------------------

        Bugzilla Update: Perform
    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1080233

    
> Can't set attribute "suffix" on web access-log
> ----------------------------------------------
>
>                 Key: WFLY-1013
>                 URL: https://issues.jboss.org/browse/WFLY-1013
>             Project: WildFly
>          Issue Type: Enhancement
>      Security Level: Public(Everyone can see) 
>          Components: Web (Undertow)
>         Environment: N/A
>            Reporter: Ed Roberts
>            Assignee: Tomaz Cerar
>              Labels: logging, suffix, web
>
> In JBoss 5.x you used to be able to specify a suffix attribute value for the JBossWeb access log file, which would be appended to generated log file names.
> In JBoss 7.x you can only specify a prefix. For the logging handlers you can specify both a prefix and a suffix, which is inconsistent.
> Please add the suffix attribute to the access-log element within the parent virtual-server element of the web subsystem xml configuration.

--
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

From issues at jboss.org  Tue Mar 25 01:51:13 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 25 Mar 2014 01:51:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1904) Usage of vault for
 system-properties throws java.lang.SecurityException
In-Reply-To: <JIRA.12498944.1376977640000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12498944.1376977640000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12498944.1376977640000.4245.1395726673196@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1904?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12955887#comment-12955887 ] 

RH Bugzilla Integration commented on WFLY-1904:
-----------------------------------------------

Chao Wang <chaowan at redhat.com> changed the Status of [bug 1076507|https://bugzilla.redhat.com/show_bug.cgi?id=1076507] from NEW to POST
                
> Usage of vault for system-properties throws java.lang.SecurityException
> -----------------------------------------------------------------------
>
>                 Key: WFLY-1904
>                 URL: https://issues.jboss.org/browse/WFLY-1904
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Security
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Navin Surtani
>            Assignee: Brian Stansberry
>             Fix For: 8.0.1.Final
>
>
> Steps to Reproduce: 1. add the lines in standalone.xml:-
> {code}
>     <system-properties>
>       <property name="javax.net.ssl.trustStore" value="/dir/truststore.jks"/>
>       <property name="javax.net.ssl.trustStorePassword" value="${VAULT::blk::attr::MTBlYWUzNDEtMjI2MC00NWYzLWFiZmUtM2EyYjZkNDgyZWM4TElORV9CUkVBS215YWxpYXM=}" />
>     </system-properties>
>     <vault>
>         <vault-option name="KEYSTORE_URL" value="/opt/jboss-eap-6.0/standalone/configuration/vault.jks"/>
>         <vault-option name="KEYSTORE_PASSWORD" value="MASK-2gTQPnrWJaqrh0pURMKAOw"/>
>         <vault-option name="KEYSTORE_ALIAS" value="myalias"/>
>         <vault-option name="SALT" value="12345678"/>
>         <vault-option name="ITERATION_COUNT" value="44"/>
>         <vault-option name="ENC_FILE_DIR" value="/opt/jboss-eap-6.0/standalone/configuration/"/>
>     </vault>
> {code}
> 2. start EAP6 in standalone mode
> project_key: JBPAPP6
> Usage of vault for system-properties throws java.lang.SecurityException.
> boot.log:-
> {code}
> 20:35:30,267 ERROR [org.jboss.as.controller.management-operation] JBAS014612: Operation ("add") failed - address: ([("system-property" => "javax.net.ssl.trustStorePassword")]): java.lang.SecurityException: JBAS013322: Vault is not initialized
> 	at org.jboss.as.security.vault.RuntimeVaultReader.retrieveFromVault(RuntimeVaultReader.java:98) [jboss-as-security-7.1.2.Final-redhat-1.jar:7.1.2.Final-redhat-1]
> 	at org.jboss.as.server.RuntimeExpressionResolver.resolvePluggableExpression(RuntimeExpressionResolver.java:45) [jboss-as-server-7.1.2.Final-redhat-1.jar:7.1.2.Final-redhat-1]
> 	at org.jboss.as.controller.ExpressionResolverImpl.resolveExpressionsRecursively(ExpressionResolverImpl.java:58) [jboss-as-controller-7.1.2.Final-redhat-1.jar:7.1.2.Final-redhat-1]
> 	at org.jboss.as.controller.ExpressionResolverImpl.resolveExpressions(ExpressionResolverImpl.java:40) [jboss-as-controller-7.1.2.Final-redhat-1.jar:7.1.2.Final-redhat-1]
> 	at org.jboss.as.controller.ModelControllerImpl.resolveExpressions(ModelControllerImpl.java:455) [jboss-as-controller-7.1.2.Final-redhat-1.jar:7.1.2.Final-redhat-1]
> 	at org.jboss.as.controller.OperationContextImpl.resolveExpressions(OperationContextImpl.java:689) [jboss-as-controller-7.1.2.Final-redhat-1.jar:7.1.2.Final-redhat-1]
> 	at org.jboss.as.controller.operations.common.SystemPropertyAddHandler.execute(SystemPropertyAddHandler.java:112) [jboss-as-controller-7.1.2.Final-redhat-1.jar:7.1.2.Final-redhat-1]
> 	at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:397) [jboss-as-controller-7.1.2.Final-redhat-1.jar:7.1.2.Final-redhat-1]
> 	at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:284) [jboss-as-controller-7.1.2.Final-redhat-1.jar:7.1.2.Final-redhat-1]
> 	at org.jboss.as.controller.AbstractOperationContext.completeStep(AbstractOperationContext.java:211) [jboss-as-controller-7.1.2.Final-redhat-1.jar:7.1.2.Final-redhat-1]
> 	at org.jboss.as.controller.ModelControllerImpl.boot(ModelControllerImpl.java:175) [jboss-as-controller-7.1.2.Final-redhat-1.jar:7.1.2.Final-redhat-1]
> 	at org.jboss.as.controller.AbstractControllerService.boot(AbstractControllerService.java:191) [jboss-as-controller-7.1.2.Final-redhat-1.jar:7.1.2.Final-redhat-1]
> 	at org.jboss.as.server.ServerService.boot(ServerService.java:295) [jboss-as-server-7.1.2.Final-redhat-1.jar:7.1.2.Final-redhat-1]
> 	at org.jboss.as.server.ServerService.boot(ServerService.java:270) [jboss-as-server-7.1.2.Final-redhat-1.jar:7.1.2.Final-redhat-1]
> 	at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:156) [jboss-as-controller-7.1.2.Final-redhat-1.jar:7.1.2.Final-redhat-1]
> 	at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_37]
> {code}

--
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

From issues at jboss.org  Tue Mar 25 02:01:13 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 25 Mar 2014 02:01:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3016) Prevent NullPointerException
 in JDR CommandLineMain
In-Reply-To: <JIRA.12533291.1393354434000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12533291.1393354434000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12533291.1393354434000.4250.1395727273415@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-3016?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12955888#comment-12955888 ] 

RH Bugzilla Integration commented on WFLY-3016:
-----------------------------------------------

Chao Wang <chaowan at redhat.com> changed the Status of [bug 1069894|https://bugzilla.redhat.com/show_bug.cgi?id=1069894] from NEW to POST
                
> Prevent NullPointerException in JDR CommandLineMain
> ---------------------------------------------------
>
>                 Key: WFLY-3016
>                 URL: https://issues.jboss.org/browse/WFLY-3016
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JDR
>    Affects Versions: 8.0.0.Final
>            Reporter: Brad Maxwell
>            Assignee: Brad Maxwell
>


--
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

From issues at jboss.org  Tue Mar 25 02:27:13 2014
From: issues at jboss.org (Bela Ban (JIRA))
Date: Tue, 25 Mar 2014 02:27:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1813) JDBC_PING failes to recover
 for corruption issue
In-Reply-To: <JIRA.12535937.1395688882000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12535937.1395688882000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12535937.1395688882000.4257.1395728833179@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JGRP-1813?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban updated JGRP-1813:
---------------------------

    Fix Version/s: 3.5

    
> JDBC_PING failes to recover for corruption issue
> ------------------------------------------------
>
>                 Key: JGRP-1813
>                 URL: https://issues.jboss.org/browse/JGRP-1813
>             Project: JGroups
>          Issue Type: Feature Request
>    Affects Versions: 3.4
>         Environment: Windows 7
>            Reporter: Brett Donahue
>            Assignee: Bela Ban
>            Priority: Minor
>              Labels: EOFException, JDBC_PING,, corruption
>             Fix For: 3.5
>
>
> heap space was exhausted and issues occurred.  In the end, one node in the cluster must have corrupted the data in the JDBC_PING table.   From this point onward, our log is full of these (every two seconds):
> 2014 03 23 04:00:25#+0100#ERROR#org.jgroups.protocols.SMP_JDBC_PING##anonymous#Thread-15###Error java.io.EOFException: null
>         at java.io.DataInputStream.readUnsignedShort(DataInputStream.java:340)
>         at org.jgroups.stack.IpAddress.readFrom(IpAddress.java:226)
>         at org.jgroups.util.Util.readAddress(Util.java:929)
>         at org.jgroups.util.Util.readAddresses(Util.java:1047)
>         at org.jgroups.protocols.PingData.readFrom(PingData.java:163)
>         at org.jgroups.util.Util.streamableFromByteBuffer(Util.java:753)
>         at org.jgroups.protocols.Discovery.deserialize(Discovery.java:625)
>         at org.jgroups.protocols.JDBC_PING.readAll(JDBC_PING.java:221)
>         at org.jgroups.protocols.JDBC_PING.readAll(JDBC_PING.java:201)
>         at org.jgroups.protocols.FILE_PING.fetchClusterMembers(FILE_PING.java:68)
>         at org.jgroups.protocols.Discovery.sendDiscoveryRequest(Discovery.java:263)
>         at org.jgroups.protocols.Discovery.findMembers(Discovery.java:227)
>         at org.jgroups.protocols.Discovery.findInitialMembers(Discovery.java:208)
>         at org.jgroups.protocols.Discovery.down(Discovery.java:551)
>         at org.jgroups.protocols.FILE_PING.down(FILE_PING.java:101)
>         at org.jgroups.protocols.MERGE2.down(MERGE2.java:185)
>         at org.jgroups.protocols.FD_SOCK.down(FD_SOCK.java:363)
>         at org.jgroups.protocols.FD.down(FD.java:307)
>         at org.jgroups.protocols.VERIFY_SUSPECT.down(VERIFY_SUSPECT.java:84)
>         at org.jgroups.protocols.BARRIER.down(BARRIER.java:95)
>         at org.jgroups.protocols.pbcast.NAKACK2.down(NAKACK2.java:533)
>         at org.jgroups.protocols.UNICAST3.down(UNICAST3.java:575)
>         at org.jgroups.protocols.pbcast.STABLE.down(STABLE.java:347)
>         at org.jgroups.protocols.ENCRYPT.down(ENCRYPT.java:925)
>         at org.jgroups.protocols.pbcast.ClientGmsImpl.findInitialMembers(ClientGmsImpl.java:201)
>         at org.jgroups.protocols.pbcast.ClientGmsImpl.joinInternal(ClientGmsImpl.java:75)
>         at org.jgroups.protocols.pbcast.ClientGmsImpl.join(ClientGmsImpl.java:40)
>         at org.jgroups.protocols.pbcast.GMS.down(GMS.java:1052)
>         at org.jgroups.protocols.FlowControl.down(FlowControl.java:340)
>         at org.jgroups.protocols.FRAG2.down(FRAG2.java:136)
>         at org.jgroups.protocols.pbcast.STATE_TRANSFER.down(STATE_TRANSFER.java:237)
>         at org.jgroups.stack.ProtocolStack.down(ProtocolStack.java:1024)
>         at org.jgroups.JChannel.down(JChannel.java:760)
>         at org.jgroups.JChannel._connect(JChannel.java:538)
>         at org.jgroups.JChannel.connect(JChannel.java:290)
>         at org.jgroups.JChannel.connect(JChannel.java:275)
>         at com.sap.mobile.platform.server.cluster.service.impl.ClusterCommunicationsJGroupImpl.startCommunications(ClusterCommunicationsJGroupImpl.java:45)
>         at com.sap.mobile.platform.server.cluster.service.impl.ClusterCommunicationsJGroupImpl.<init>(ClusterCommunicationsJGroupImpl.java:59)
>         at com.sap.mobile.platform.server.cluster.service.impl.ClusterServiceImpl.run(ClusterServiceImpl.java:187)
>         at java.lang.Thread.run(Thread.java:791)

--
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

From issues at jboss.org  Tue Mar 25 03:19:12 2014
From: issues at jboss.org (James Livingston (JIRA))
Date: Tue, 25 Mar 2014 03:19:12 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1013) Can't set attribute "suffix"
 on web access-log
In-Reply-To: <JIRA.12471975.1344415283000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12471975.1344415283000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12471975.1344415283000.4310.1395731952938@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-1013?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

James Livingston updated WFLY-1013:
-----------------------------------

    Git Pull Request: https://github.com/wildfly/wildfly/pull/6084

    
> Can't set attribute "suffix" on web access-log
> ----------------------------------------------
>
>                 Key: WFLY-1013
>                 URL: https://issues.jboss.org/browse/WFLY-1013
>             Project: WildFly
>          Issue Type: Enhancement
>      Security Level: Public(Everyone can see) 
>          Components: Web (Undertow)
>         Environment: N/A
>            Reporter: Ed Roberts
>            Assignee: Tomaz Cerar
>              Labels: logging, suffix, web
>
> In JBoss 5.x you used to be able to specify a suffix attribute value for the JBossWeb access log file, which would be appended to generated log file names.
> In JBoss 7.x you can only specify a prefix. For the logging handlers you can specify both a prefix and a suffix, which is inconsistent.
> Please add the suffix attribute to the access-log element within the parent virtual-server element of the web subsystem xml configuration.

--
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

From issues at jboss.org  Tue Mar 25 03:45:13 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 25 Mar 2014 03:45:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1752) Concurrent message headers
 modification causes that message is never sent
In-Reply-To: <JIRA.12526753.1386075180000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12526753.1386075180000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12526753.1386075180000.4337.1395733513632@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JGRP-1752?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12955897#comment-12955897 ] 

RH Bugzilla Integration commented on JGRP-1752:
-----------------------------------------------

Martin Gencur <mgencur at redhat.com> changed the Status of [bug 1043853|https://bugzilla.redhat.com/show_bug.cgi?id=1043853] from NEW to ON_QA
                
> Concurrent message headers modification causes that message is never sent
> -------------------------------------------------------------------------
>
>                 Key: JGRP-1752
>                 URL: https://issues.jboss.org/browse/JGRP-1752
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.4.1
>            Reporter: Radim Vansa
>            Assignee: Bela Ban
>              Labels: 621
>             Fix For: 3.4.2, 3.5
>
>
> Under some circumstances the TP protocol may try to add the TP header to message twice concurrently.
> This happens for example when the stable message triggers retransmission while the message has been sent right now.
> This may result in ArrayOutOfBoundException in Headers._putHeader and/or subsequent NullPointerException in Headers.size(). The retransmission attempt always fails, the message is never delivered. Moreover, keeping this (and possibly following) messages in the transmission table can lead to OOME.

--
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

From issues at jboss.org  Tue Mar 25 03:47:13 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 25 Mar 2014 03:47:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1752) Concurrent message headers
 modification causes that message is never sent
In-Reply-To: <JIRA.12526753.1386075180000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12526753.1386075180000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12526753.1386075180000.4342.1395733633217@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JGRP-1752?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12955898#comment-12955898 ] 

RH Bugzilla Integration commented on JGRP-1752:
-----------------------------------------------

Radim Vansa <rvansa at redhat.com> changed the Status of [bug 1043853|https://bugzilla.redhat.com/show_bug.cgi?id=1043853] from ON_QA to VERIFIED
                
> Concurrent message headers modification causes that message is never sent
> -------------------------------------------------------------------------
>
>                 Key: JGRP-1752
>                 URL: https://issues.jboss.org/browse/JGRP-1752
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.4.1
>            Reporter: Radim Vansa
>            Assignee: Bela Ban
>              Labels: 621
>             Fix For: 3.4.2, 3.5
>
>
> Under some circumstances the TP protocol may try to add the TP header to message twice concurrently.
> This happens for example when the stable message triggers retransmission while the message has been sent right now.
> This may result in ArrayOutOfBoundException in Headers._putHeader and/or subsequent NullPointerException in Headers.size(). The retransmission attempt always fails, the message is never delivered. Moreover, keeping this (and possibly following) messages in the transmission table can lead to OOME.

--
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

From issues at jboss.org  Tue Mar 25 03:51:13 2014
From: issues at jboss.org (Rameshbabu Ananthrapu (JIRA))
Date: Tue, 25 Mar 2014 03:51:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBFORUMS-304) Locking Issue with Jboss6
In-Reply-To: <JIRA.12535964.1395733802299@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12535964.1395733802299@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12535964.1395733802299.4344.1395733873072@jira02.app.mwc.hst.phx2.redhat.com>

Rameshbabu Ananthrapu created JBFORUMS-304:
----------------------------------------------

             Summary: Locking Issue with Jboss6
                 Key: JBFORUMS-304
                 URL: https://issues.jboss.org/browse/JBFORUMS-304
             Project: JBoss Forums
          Issue Type: Feature Request
          Components: Forum Enhancements
            Reporter: Rameshbabu Ananthrapu
            Assignee: Luca Stancapiano


Hi,

Our application is running on jboss6.00 fnal version and database is oracle 11g. After jboss starting we are getting the below exception. Could any one please help me here. I need to be resolve this ASAP as it is existing in production environment.
We dont have this kind of issue in any test environments.


00:17:04,087 WARN  [org.jboss.resource.connectionmanager.TxConnectionManager] Connection error occured: org.jboss.resource.connectionmanager.TxConnectionManager$TxConnectionEventListener at 88e624[state=NORMAL mc=org.jboss.resource.adapter.jdbc.local.LocalManagedConnection at 15950d8 handles=1 lastUse=1395702695471 permit=true trackByTx=true mcp=org.jboss.resource.connectionmanager.JBossManagedConnectionPool$OnePool at ca9ed4 context=org.jboss.resource.connectionmanager.InternalManagedConnectionPool at 8197af xaResource=org.jboss.resource.connectionmanager.TxConnectionManager$LocalXAResource at 1fa249a txSync=null]: java.sql.SQLRecoverableException: I/U-unntak
        at oracle.jdbc.driver.SQLStateMapping.newSQLException(SQLStateMapping.java:101) [:Oracle JDBC Driver version - "11.1.0.7.0-Production"]
        at oracle.jdbc.driver.DatabaseError.newSQLException(DatabaseError.java:133) [:Oracle JDBC Driver version - "11.1.0.7.0-Production"]
        at oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:199) [:Oracle JDBC Driver version - "11.1.0.7.0-Production"]
        at oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:263) [:Oracle JDBC Driver version - "11.1.0.7.0-Production"]
        at oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:521) [:Oracle JDBC Driver version - "11.1.0.7.0-Production"]
        at oracle.jdbc.driver.T4CConnection.doRollback(T4CConnection.java:634) [:Oracle JDBC Driver version - "11.1.0.7.0-Production"]
        at oracle.jdbc.driver.PhysicalConnection.rollback(PhysicalConnection.java:3470) [:Oracle JDBC Driver version - "11.1.0.7.0-Production"]
        at org.jboss.resource.adapter.jdbc.local.LocalManagedConnection.rollback(LocalManagedConnection.java:97) [:6.0.0.Final]
        at org.jboss.resource.connectionmanager.TxConnectionManager$LocalXAResource.rollback(TxConnectionManager.java:1172) [:6.0.0.Final]
        at com.arjuna.ats.internal.jta.resources.arjunacore.XAOnePhaseResource.rollback(XAOnePhaseResource.java:186) [:6.0.0.Final]
        at com.arjuna.ats.internal.arjuna.abstractrecords.LastResourceRecord.topLevelAbort(LastResourceRecord.java:123) [:6.0.0.Final]
        at com.arjuna.ats.arjuna.coordinator.BasicAction.doAbort(BasicAction.java:2902) [:6.0.0.Final]
        at com.arjuna.ats.arjuna.coordinator.BasicAction.doAbort(BasicAction.java:2881) [:6.0.0.Final]
        at com.arjuna.ats.arjuna.coordinator.BasicAction.Abort(BasicAction.java:1602) [:6.0.0.Final]
        at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.cancel(TwoPhaseCoordinator.java:119) [:6.0.0.Final]
        at com.arjuna.ats.arjuna.AtomicAction.cancel(AtomicAction.java:212) [:6.0.0.Final]
        at com.arjuna.ats.arjuna.coordinator.TransactionReaper.doCancellations(TransactionReaper.java:367) [:6.0.0.Final]
        at com.arjuna.ats.internal.arjuna.coordinator.ReaperWorkerThread.run(ReaperWorkerThread.java:79) [:6.0.0.Final]
Caused by: java.io.InterruptedIOException
        at java.net.SocketOutputStream.socketWrite0(Native Method) [:1.6.0_35]
        at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:92) [:1.6.0_35]
        at java.net.SocketOutputStream.write(SocketOutputStream.java:136) [:1.6.0_35]
        at oracle.net.ns.DataPacket.send(DataPacket.java:150) [:Oracle JDBC Driver version - "11.1.0.7.0-Production"]
        at oracle.net.ns.NetOutputStream.flush(NetOutputStream.java:180) [:Oracle JDBC Driver version - "11.1.0.7.0-Production"]
        at oracle.net.ns.NetInputStream.getNextPacket(NetInputStream.java:169) [:Oracle JDBC Driver version - "11.1.0.7.0-Production"]
        at oracle.net.ns.NetInputStream.read(NetInputStream.java:117) [:Oracle JDBC Driver version - "11.1.0.7.0-Production"]
        at oracle.net.ns.NetInputStream.read(NetInputStream.java:92) [:Oracle JDBC Driver version - "11.1.0.7.0-Production"]
        at oracle.net.ns.NetInputStream.read(NetInputStream.java:77) [:Oracle JDBC Driver version - "11.1.0.7.0-Production"]
        at oracle.jdbc.driver.T4CMAREngine.unmarshalUB1(T4CMAREngine.java:1034) [:Oracle JDBC Driver version - "11.1.0.7.0-Production"]
        at oracle.jdbc.driver.T4CMAREngine.unmarshalSB1(T4CMAREngine.java:1010) [:Oracle JDBC Driver version - "11.1.0.7.0-Production"]
        at oracle.jdbc.driver.T4C7Ocommoncall.receive(T4C7Ocommoncall.java:97) [:Oracle JDBC Driver version - "11.1.0.7.0-Production"]
        at oracle.jdbc.driver.T4CConnection.doRollback(T4CConnection.java:626) [:Oracle JDBC Driver version - "11.1.0.7.0-Production"]
        ... 12 more
		
		
After getting the above error we are getting the below exception.
Application running in unix server.		
		
00:18:04,095 INFO  [org.jboss.resource.connectionmanager.CachedConnectionManager] Closing a connection for you.  Please close them yourself: org.jboss.resource.adapter.jdbc.jdk6.WrappedConnectionJDK6 at c80233
00:18:04,096 ERROR [org.jboss.ejb.plugins.LogInterceptor] TransactionRolledbackException in method: public abstract void flow.framework.database.OrderDataMethods.setOrderData(java.lang.String,java.util.Map) throws javax.ejb.ObjectNotFoundException,java.rmi.RemoteException, causedBy:: simpleorm.core.SException$JDBC: ???Preparing [WOLocal 225634]'UPDATE WO_LOCAL SET Overdue_CompleteCount = ?, DueDate = ? WHERE LOCALPK = ? ': java.sql.SQLException: Unable to obtain lock in 60 seconds: org.jboss.resource.adapter.jdbc.local.LocalManagedConnection at 15950d8
        at simpleorm.core.SRecordInstance.flush(SRecordInstance.java:494) [:]
        at simpleorm.core.SConnection.flush(SConnection.java:388) [:]
        at flow.framework.database.impl.OrderDataContext.flush(OrderDataContext.java:144) [:]
        at flow.framework.database.impl.OrderDataImpl.setOrderDataInternal(OrderDataImpl.java:668) [:]
        at flow.framework.database.impl.workorder.WorkOrderDataImpl.setOrderDataInternal(WorkOrderDataImpl.java:160) [:]
        at flow.framework.database.impl.OrderDataImpl.setOrderData(OrderDataImpl.java:206) [:]
        at flow.framework.database.impl.OrderDataImpl.setOrderData(OrderDataImpl.java:177) [:]
        at flow.framework.database.impl.workorder.WorkOrderDataImpl.setOrderData(WorkOrderDataImpl.java:144) [:]
        at sun.reflect.GeneratedMethodAccessor377.invoke(Unknown Source) [:1.6.0_35]
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [:1.6.0_35]
        at java.lang.reflect.Method.invoke(Method.java:597) [:1.6.0_35]
        at org.jboss.invocation.Invocation.performCall(Invocation.java:386) [:6.0.0.Final]
        at org.jboss.ejb.StatelessSessionContainer$ContainerInterceptor.invoke(StatelessSessionContainer.java:233) [:6.0.0.Final]
        at org.jboss.resource.connectionmanager.CachedConnectionInterceptor.invoke(CachedConnectionInterceptor.java:156) [:6.0.0.Final]
        at org.jboss.ejb.plugins.StatelessSessionInstanceInterceptor.invoke(StatelessSessionInstanceInterceptor.java:173) [:6.0.0.Final]
        at org.jboss.ejb.plugins.CallValidationInterceptor.invoke(CallValidationInterceptor.java:63) [:6.0.0.Final]
        at org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext(AbstractTxInterceptor.java:121) [:6.0.0.Final]
        at org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterceptorCMT.java:350) [:6.0.0.Final]
        at org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:181) [:6.0.0.Final]
        at org.jboss.ejb.plugins.SecurityInterceptor.process(SecurityInterceptor.java:228) [:6.0.0.Final]
        at org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.java:211) [:6.0.0.Final]
        at org.jboss.ejb.plugins.security.PreSecurityInterceptor.process(PreSecurityInterceptor.java:97) [:6.0.0.Final]
        at org.jboss.ejb.plugins.security.PreSecurityInterceptor.invoke(PreSecurityInterceptor.java:81) [:6.0.0.Final]
        at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:205) [:6.0.0.Final]
        at org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invoke(ProxyFactoryFinderInterceptor.java:138) [:6.0.0.Final]
        at org.jboss.ejb.SessionContainer.internalInvoke(SessionContainer.java:650) [:6.0.0.Final]
        at org.jboss.ejb.Container.invoke(Container.java:1072) [:6.0.0.Final]
        at sun.reflect.GeneratedMethodAccessor341.invoke(Unknown Source) [:1.6.0_35]
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [:1.6.0_35]
        at java.lang.reflect.Method.invoke(Method.java:597) [:1.6.0_35]
        at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:157) [:6.0.0.GA]
        at org.jboss.mx.server.Invocation.dispatch(Invocation.java:96) [:6.0.0.GA]
        at org.jboss.mx.server.Invocation.invoke(Invocation.java:88) [:6.0.0.GA]
        at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:271) [:6.0.0.GA]
        at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:670) [:6.0.0.GA]
        at org.jboss.invocation.local.LocalInvoker$MBeanServerAction.invoke(LocalInvoker.java:169) [:6.0.0.Final]
        at org.jboss.invocation.local.LocalInvoker.invoke(LocalInvoker.java:118) [:6.0.0.Final]
        at org.jboss.invocation.InvokerInterceptor.invokeLocal(InvokerInterceptor.java:209) [:6.0.0.Final]
        at org.jboss.invocation.InvokerInterceptor.invoke(InvokerInterceptor.java:195) [:6.0.0.Final]
        at org.jboss.proxy.TransactionInterceptor.invoke(TransactionInterceptor.java:61) [:6.0.0.Final]
        at org.jboss.proxy.ejb.SecurityContextInterceptor.invoke(SecurityContextInterceptor.java:64) [:6.0.0.Final]
        at org.jboss.proxy.SecurityInterceptor.invoke(SecurityInterceptor.java:68) [:6.0.0.Final]
        at org.jboss.proxy.ejb.StatelessSessionInterceptor.invoke(StatelessSessionInterceptor.java:112) [:6.0.0.Final]
        at org.jboss.proxy.ClientContainer.invoke(ClientContainer.java:101) [:6.0.0.Final]
        at $Proxy329.setOrderData(Unknown Source)       at flow.framework.oss.common.impl.UtilityBean.internalSetState(UtilityBean.java:379) [:]
        at flow.framework.oss.common.impl.UtilityBean.setState(UtilityBean.java:115) [:]
        at sun.reflect.GeneratedMethodAccessor378.invoke(Unknown Source) [:1.6.0_35]
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [:1.6.0_35]
        at java.lang.reflect.Method.invoke(Method.java:597) [:1.6.0_35]
        at org.jboss.invocation.Invocation.performCall(Invocation.java:386) [:6.0.0.Final]
        at org.jboss.ejb.StatelessSessionContainer$ContainerInterceptor.invoke(StatelessSessionContainer.java:233) [:6.0.0.Final]
        at org.jboss.resource.connectionmanager.CachedConnectionInterceptor.invoke(CachedConnectionInterceptor.java:156) [:6.0.0.Final]
        at org.jboss.ejb.plugins.StatelessSessionInstanceInterceptor.invoke(StatelessSessionInstanceInterceptor.java:173) [:6.0.0.Final]
        at org.jboss.ejb.plugins.CallValidationInterceptor.invoke(CallValidationInterceptor.java:63) [:6.0.0.Final]
        at org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext(AbstractTxInterceptor.java:121) [:6.0.0.Final]
        at org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterceptorCMT.java:350) [:6.0.0.Final]
        at org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:181) [:6.0.0.Final]
        at org.jboss.ejb.plugins.SecurityInterceptor.process(SecurityInterceptor.java:228) [:6.0.0.Final]
        at org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.java:211) [:6.0.0.Final]
        at org.jboss.ejb.plugins.security.PreSecurityInterceptor.process(PreSecurityInterceptor.java:97) [:6.0.0.Final]
        at org.jboss.ejb.plugins.security.PreSecurityInterceptor.invoke(PreSecurityInterceptor.java:81) [:6.0.0.Final]
        at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:205) [:6.0.0.Final]
        at org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invoke(ProxyFactoryFinderInterceptor.java:138) [:6.0.0.Final]
        at org.jboss.ejb.SessionContainer.internalInvoke(SessionContainer.java:650) [:6.0.0.Final]
        at org.jboss.ejb.Container.invoke(Container.java:1072) [:6.0.0.Final]
        at sun.reflect.GeneratedMethodAccessor341.invoke(Unknown Source) [:1.6.0_35]
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [:1.6.0_35]
        at java.lang.reflect.Method.invoke(Method.java:597) [:1.6.0_35]
        at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:157) [:6.0.0.GA]
        at org.jboss.mx.server.Invocation.dispatch(Invocation.java:96) [:6.0.0.GA]
        at org.jboss.mx.server.Invocation.invoke(Invocation.java:88) [:6.0.0.GA]
        at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:271) [:6.0.0.GA]
        at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:670) [:6.0.0.GA]
        at org.jboss.invocation.local.LocalInvoker$MBeanServerAction.invoke(LocalInvoker.java:169) [:6.0.0.Final]
        at org.jboss.invocation.local.LocalInvoker.invoke(LocalInvoker.java:118) [:6.0.0.Final]
        at org.jboss.invocation.InvokerInterceptor.invokeLocal(InvokerInterceptor.java:209) [:6.0.0.Final]
        at org.jboss.invocation.InvokerInterceptor.invoke(InvokerInterceptor.java:195) [:6.0.0.Final]
        at org.jboss.proxy.TransactionInterceptor.invoke(TransactionInterceptor.java:61) [:6.0.0.Final]
        at org.jboss.proxy.ejb.SecurityContextInterceptor.invoke(SecurityContextInterceptor.java:64) [:6.0.0.Final]
        at org.jboss.proxy.SecurityInterceptor.invoke(SecurityInterceptor.java:68) [:6.0.0.Final]
		 at org.jboss.proxy.ejb.StatelessSessionInterceptor.invoke(StatelessSessionInterceptor.java:112) [:6.0.0.Final]
        at org.jboss.proxy.ClientContainer.invoke(ClientContainer.java:101) [:6.0.0.Final]
        at $Proxy339.setState(Unknown Source)   at flow.framework.oss.workorder.impl.StateHandler.handleOverdueEvent(StateHandler.java:1523) [:]
        at flow.framework.oss.workorder.impl.StateHandler.overdueEvent(StateHandler.java:1336) [:]
        at flow.framework.oss.workorder.impl.WorkOrderTimeoutBean.handleOverdueEvents2(WorkOrderTimeoutBean.java:108) [:]
        at flow.framework.oss.workorder.impl.WorkOrderTimeoutBean.handleOverdueEvents(WorkOrderTimeoutBean.java:52) [:]
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [:1.6.0_35]
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) [:1.6.0_35]
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [:1.6.0_35]
        at java.lang.reflect.Method.invoke(Method.java:597) [:1.6.0_35]
        at org.jboss.invocation.Invocation.performCall(Invocation.java:386) [:6.0.0.Final]
        at org.jboss.ejb.StatelessSessionContainer$ContainerInterceptor.invoke(StatelessSessionContainer.java:233) [:6.0.0.Final]
        at org.jboss.resource.connectionmanager.CachedConnectionInterceptor.invoke(CachedConnectionInterceptor.java:156) [:6.0.0.Final]
        at org.jboss.ejb.plugins.StatelessSessionInstanceInterceptor.invoke(StatelessSessionInstanceInterceptor.java:173) [:6.0.0.Final]
        at org.jboss.ejb.plugins.CallValidationInterceptor.invoke(CallValidationInterceptor.java:63) [:6.0.0.Final]
        at org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext(AbstractTxInterceptor.java:121) [:6.0.0.Final]
        at org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterceptorCMT.java:350) [:6.0.0.Final]
        at org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:181) [:6.0.0.Final]
        at org.jboss.ejb.plugins.SecurityInterceptor.process(SecurityInterceptor.java:228) [:6.0.0.Final]
        at org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.java:211) [:6.0.0.Final]
        at org.jboss.ejb.plugins.security.PreSecurityInterceptor.process(PreSecurityInterceptor.java:97) [:6.0.0.Final]
        at org.jboss.ejb.plugins.security.PreSecurityInterceptor.invoke(PreSecurityInterceptor.java:81) [:6.0.0.Final]
        at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:205) [:6.0.0.Final]
        at org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invoke(ProxyFactoryFinderInterceptor.java:138) [:6.0.0.Final]
        at org.jboss.ejb.SessionContainer.internalInvoke(SessionContainer.java:650) [:6.0.0.Final]
        at org.jboss.ejb.Container.invoke(Container.java:1072) [:6.0.0.Final]
        at sun.reflect.GeneratedMethodAccessor341.invoke(Unknown Source) [:1.6.0_35]
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [:1.6.0_35]
        at java.lang.reflect.Method.invoke(Method.java:597) [:1.6.0_35]
        at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:157) [:6.0.0.GA]
        at org.jboss.mx.server.Invocation.dispatch(Invocation.java:96) [:6.0.0.GA]
        at org.jboss.mx.server.Invocation.invoke(Invocation.java:88) [:6.0.0.GA]
        at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:271) [:6.0.0.GA]
        at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:670) [:6.0.0.GA]
        at org.jboss.invocation.unified.server.UnifiedInvoker.invoke(UnifiedInvoker.java:232) [:6.0.0.Final]
        at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:898) [:6.0.0.Final]
        at org.jboss.remoting.transport.socket.ServerThread.completeInvocation(ServerThread.java:791) [:6.0.0.Final]
        at org.jboss.remoting.transport.socket.ServerThread.processInvocation(ServerThread.java:744) [:6.0.0.Final]
        at org.jboss.remoting.transport.socket.ServerThread.dorun(ServerThread.java:586) [:6.0.0.Final]
        at org.jboss.remoting.transport.socket.ServerThread.run(ServerThread.java:234) [:6.0.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

From issues at jboss.org  Tue Mar 25 05:07:12 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 25 Mar 2014 05:07:12 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3154) Operation which require
 server reload should check if something was changed
In-Reply-To: <JIRA.12535873.1395667875000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12535873.1395667875000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12535873.1395667875000.4444.1395738432945@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-3154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12955912#comment-12955912 ] 

RH Bugzilla Integration commented on WFLY-3154:
-----------------------------------------------

Emmanuel Hugonnet (ehsavoie) <ehugonne at redhat.com> changed the Status of [bug 976228|https://bugzilla.redhat.com/show_bug.cgi?id=976228] from ASSIGNED to POST
                
>  Operation which require server reload should check if something was changed
> ----------------------------------------------------------------------------
>
>                 Key: WFLY-3154
>                 URL: https://issues.jboss.org/browse/WFLY-3154
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>    Affects Versions: 8.0.0.Final
>            Reporter: Emmanuel Hugonnet
>            Assignee: Emmanuel Hugonnet
>
> Description of problem:
> Server reload is required even if nothing was actually changed. This could have negative impact on usability of WildFly.
> Steps to Reproduce:
>  - start standalone
>  - connect to cli
>  - run: /subsystem=jpa:write-attribute(name=default-extended-persistence-inheritance, value=SHALLOW)
>  - reload server
>  - run: /subsystem=jpa:write-attribute(name=default-extended-persistence-inheritance, value=SHALLOW)
> Actual results:
> {
>     "outcome" => "success",
>     "response-headers" => {
>         "operation-requires-reload" => true,
>         "process-state" => "reload-required"
>     }
> }
> Expected results:
>  - reload is not required

--
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

From issues at jboss.org  Tue Mar 25 05:52:13 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 25 Mar 2014 05:52:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1013) Can't set attribute "suffix"
 on web access-log
In-Reply-To: <JIRA.12471975.1344415283000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12471975.1344415283000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12471975.1344415283000.4569.1395741133436@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-1013?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated WFLY-1013:
------------------------------------------

        Bugzilla Update:   (was: Perform)
    Bugzilla References:   (was: https://bugzilla.redhat.com/show_bug.cgi?id=1080233)

    
> Can't set attribute "suffix" on web access-log
> ----------------------------------------------
>
>                 Key: WFLY-1013
>                 URL: https://issues.jboss.org/browse/WFLY-1013
>             Project: WildFly
>          Issue Type: Enhancement
>      Security Level: Public(Everyone can see) 
>          Components: Web (Undertow)
>         Environment: N/A
>            Reporter: Ed Roberts
>            Assignee: Tomaz Cerar
>              Labels: logging, suffix, web
>
> In JBoss 5.x you used to be able to specify a suffix attribute value for the JBossWeb access log file, which would be appended to generated log file names.
> In JBoss 7.x you can only specify a prefix. For the logging handlers you can specify both a prefix and a suffix, which is inconsistent.
> Please add the suffix attribute to the access-log element within the parent virtual-server element of the web subsystem xml configuration.

--
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

From issues at jboss.org  Tue Mar 25 06:30:13 2014
From: issues at jboss.org (Jeff Mesnil (JIRA))
Date: Tue, 25 Mar 2014 06:30:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3159) upgrade Generic JMS RA to
	1.0.3.Final
In-Reply-To: <JIRA.12535982.1395743381520@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12535982.1395743381520@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12535982.1395743381520.4706.1395743413586@jira02.app.mwc.hst.phx2.redhat.com>

Jeff Mesnil created WFLY-3159:
---------------------------------

             Summary: upgrade Generic JMS RA to 1.0.3.Final
                 Key: WFLY-3159
                 URL: https://issues.jboss.org/browse/WFLY-3159
             Project: WildFly
          Issue Type: Component  Upgrade
      Security Level: Public (Everyone can see)
          Components: JCA, JMS
            Reporter: Jeff Mesnil
            Assignee: Jeff Mesnil
             Fix For: 8.0.1.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

From issues at jboss.org  Tue Mar 25 06:32:13 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 25 Mar 2014 06:32:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3159) upgrade Generic JMS RA to
	1.0.3.Final
In-Reply-To: <JIRA.12535982.1395743381000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12535982.1395743381000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12535982.1395743381000.4713.1395743533873@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-3159?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated WFLY-3159:
------------------------------------------

        Bugzilla Update: Perform
    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1033008

    
> upgrade Generic JMS RA to 1.0.3.Final
> -------------------------------------
>
>                 Key: WFLY-3159
>                 URL: https://issues.jboss.org/browse/WFLY-3159
>             Project: WildFly
>          Issue Type: Component  Upgrade
>      Security Level: Public(Everyone can see) 
>          Components: JCA, JMS
>            Reporter: Jeff Mesnil
>            Assignee: Jeff Mesnil
>             Fix For: 8.0.1.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

From issues at jboss.org  Tue Mar 25 07:40:13 2014
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 25 Mar 2014 07:40:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3160) Add path
 'sun/security/action' to the 'sun.jdk' module.
In-Reply-To: <JIRA.12535990.1395747599057@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12535990.1395747599057@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12535990.1395747599057.4881.1395747613528@jira02.app.mwc.hst.phx2.redhat.com>

Darran Lofthouse created WFLY-3160:
--------------------------------------

             Summary: Add path 'sun/security/action' to the 'sun.jdk' module.
                 Key: WFLY-3160
                 URL: https://issues.jboss.org/browse/WFLY-3160
             Project: WildFly
          Issue Type: Task
      Security Level: Public (Everyone can see)
          Components: Class Loading, JCA
            Reporter: Darran Lofthouse
            Assignee: Darran Lofthouse
             Fix For: 8.0.1.Final


This path is used by the DB2 JDBC driver when Kerberos authentication is 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

From issues at jboss.org  Tue Mar 25 09:03:14 2014
From: issues at jboss.org (Tomaz Cerar (JIRA))
Date: Tue, 25 Mar 2014 09:03:14 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBEE-146) jboss-el-api_2.2_spec
 1.0.2.Final cannot access public methods from non-public classes
In-Reply-To: <JIRA.12525180.1384462560000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12525180.1384462560000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12525180.1384462560000.5331.1395752594381@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JBEE-146?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12955998#comment-12955998 ] 

Tomaz Cerar commented on JBEE-146:
----------------------------------

Looking at this change I wonder why did we not take the fix from upstream EL that also addresses this?
This is the fix in upstream https://java.net/projects/uel/sources/svn/revision/380
                
> jboss-el-api_2.2_spec 1.0.2.Final cannot access public methods from non-public classes
> --------------------------------------------------------------------------------------
>
>                 Key: JBEE-146
>                 URL: https://issues.jboss.org/browse/JBEE-146
>             Project: JBoss JavaEE Spec APIs
>          Issue Type: Bug
>            Reporter: Farah Juma
>            Assignee: Farah Juma
>             Fix For: jboss-el-api_2.2_spec-1.0.3.Final, jboss-el-api_3.0_spec-1.0.0.Final
>
>
> When accessing a public method of a non-public class via EL that implements a public interface or has a public superclass, the following exception occurs:
> {code}java.lang.IllegalAccessException: Class javax.el.BeanELResolver can not access a member of class X with modifiers "public" 
> {code}
> See https://bugzilla.redhat.com/show_bug.cgi?id=1029387 for more 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

From issues at jboss.org  Tue Mar 25 09:17:13 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 25 Mar 2014 09:17:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3069) slaves cannot reconnect to a
 restarted master if RBAC is enabled
In-Reply-To: <JIRA.12534143.1394020494000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534143.1394020494000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534143.1394020494000.5382.1395753433237@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-3069?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12956006#comment-12956006 ] 

RH Bugzilla Integration commented on WFLY-3069:
-----------------------------------------------

Dominik Pospisil <dpospisi at redhat.com> changed the Status of [bug 1072949|https://bugzilla.redhat.com/show_bug.cgi?id=1072949] from NEW to POST
                
> slaves cannot reconnect to a restarted master if RBAC is enabled
> ----------------------------------------------------------------
>
>                 Key: WFLY-3069
>                 URL: https://issues.jboss.org/browse/WFLY-3069
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>    Affects Versions: 8.0.0.Final
>            Reporter: Tom Fonteyne
>            Assignee: Emanuel Muckenhuber
>            Priority: Critical
>             Fix For: 8.0.1.Final
>
>
> Enable RBAC in an Wilfly domain setup. "reload --host=master" and the slaves will no longer be connected to the master

--
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

From issues at jboss.org  Tue Mar 25 09:51:13 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 25 Mar 2014 09:51:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2610) Add the ability to take an
 external based password to the Vault tool
In-Reply-To: <JIRA.12527043.1386238103000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12527043.1386238103000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12527043.1386238103000.5542.1395755473182@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2610?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated WFLY-2610:
------------------------------------------

        Bugzilla Update: Perform
    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1080466

    
> Add the ability to take an external based password to the Vault tool
> --------------------------------------------------------------------
>
>                 Key: WFLY-2610
>                 URL: https://issues.jboss.org/browse/WFLY-2610
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Scripts, Security
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Ivo Studensky
>            Assignee: Ivo Studensky
>             Fix For: 8.0.0.Final
>
>
> At the moment the Vault tool only supports plain text password as a parameter. With SECURITY-770 committed in it is also possible to configure the Vault to take an external password. Thus the Vault tool needs to support it too.

--
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

From issues at jboss.org  Tue Mar 25 09:51:13 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 25 Mar 2014 09:51:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2610) Add the ability to take an
 external based password to the Vault tool
In-Reply-To: <JIRA.12527043.1386238103000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12527043.1386238103000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12527043.1386238103000.5545.1395755473382@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2610?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12956028#comment-12956028 ] 

RH Bugzilla Integration commented on WFLY-2610:
-----------------------------------------------

Ivo Studensky <istudens at redhat.com> changed the Status of [bug 1080466|https://bugzilla.redhat.com/show_bug.cgi?id=1080466] from NEW to ASSIGNED
                
> Add the ability to take an external based password to the Vault tool
> --------------------------------------------------------------------
>
>                 Key: WFLY-2610
>                 URL: https://issues.jboss.org/browse/WFLY-2610
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Scripts, Security
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Ivo Studensky
>            Assignee: Ivo Studensky
>             Fix For: 8.0.0.Final
>
>
> At the moment the Vault tool only supports plain text password as a parameter. With SECURITY-770 committed in it is also possible to configure the Vault to take an external password. Thus the Vault tool needs to support it too.

--
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

From issues at jboss.org  Tue Mar 25 10:17:14 2014
From: issues at jboss.org (Farah Juma (JIRA))
Date: Tue, 25 Mar 2014 10:17:14 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBEE-146) jboss-el-api_2.2_spec
 1.0.2.Final cannot access public methods from non-public classes
In-Reply-To: <JIRA.12525180.1384462560000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12525180.1384462560000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12525180.1384462560000.5713.1395757034265@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JBEE-146?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12956039#comment-12956039 ] 

Farah Juma commented on JBEE-146:
---------------------------------

Good catch, Tomaz. It looks like the upstream fix was made right around the same time this workaround was added so we weren't aware of it at the time.
                
> jboss-el-api_2.2_spec 1.0.2.Final cannot access public methods from non-public classes
> --------------------------------------------------------------------------------------
>
>                 Key: JBEE-146
>                 URL: https://issues.jboss.org/browse/JBEE-146
>             Project: JBoss JavaEE Spec APIs
>          Issue Type: Bug
>            Reporter: Farah Juma
>            Assignee: Farah Juma
>             Fix For: jboss-el-api_2.2_spec-1.0.3.Final, jboss-el-api_3.0_spec-1.0.0.Final
>
>
> When accessing a public method of a non-public class via EL that implements a public interface or has a public superclass, the following exception occurs:
> {code}java.lang.IllegalAccessException: Class javax.el.BeanELResolver can not access a member of class X with modifiers "public" 
> {code}
> See https://bugzilla.redhat.com/show_bug.cgi?id=1029387 for more 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

From issues at jboss.org  Tue Mar 25 10:23:13 2014
From: issues at jboss.org (Tomasz Adamski (JIRA))
Date: Tue, 25 Mar 2014 10:23:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-850) @TransactionTimeout ignored if
 method ist not public
In-Reply-To: <JIRA.12463415.1333657319000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12463415.1333657319000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12463415.1333657319000.5755.1395757393530@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-850?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12956044#comment-12956044 ] 

Tomasz Adamski edited comment on WFLY-850 at 3/25/14 10:23 AM:
---------------------------------------------------------------

Information about transaction timeout wasn't propagated to @Timeout methods. Added fix and a test.
                
      was (Author: tomekadamski):
    Information about transaction timeout wasn't propagated to @Timeout methods. Added fix and test.
                  
> @TransactionTimeout ignored if method ist not public
> ----------------------------------------------------
>
>                 Key: WFLY-850
>                 URL: https://issues.jboss.org/browse/WFLY-850
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: EJB
>            Reporter: Frank Langelage
>            Assignee: Tomasz Adamski
>            Priority: Minor
>
> The annotation @TransactionTimeout is not honored, when the method has other than public access.
> @Timeout methods invoked by the container are allowed to have "public, private, protected, or package level access".
> So the annotation should work also if method is not public.

--
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

From issues at jboss.org  Tue Mar 25 10:25:13 2014
From: issues at jboss.org (Tomasz Adamski (JIRA))
Date: Tue, 25 Mar 2014 10:25:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-850) @TransactionTimeout ignored if
 method ist not public
In-Reply-To: <JIRA.12463415.1333657319000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12463415.1333657319000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12463415.1333657319000.5768.1395757513362@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-850?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12956044#comment-12956044 ] 

Tomasz Adamski edited comment on WFLY-850 at 3/25/14 10:24 AM:
---------------------------------------------------------------

Information about transaction timeout wasn't propagated to @Timeout methods. Public methods got this information accidentally as all public methods are part of no-interface bean view. Added fix and a test.
                
      was (Author: tomekadamski):
    Information about transaction timeout wasn't propagated to @Timeout methods. Added fix and a test.
                  
> @TransactionTimeout ignored if method ist not public
> ----------------------------------------------------
>
>                 Key: WFLY-850
>                 URL: https://issues.jboss.org/browse/WFLY-850
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: EJB
>            Reporter: Frank Langelage
>            Assignee: Tomasz Adamski
>            Priority: Minor
>
> The annotation @TransactionTimeout is not honored, when the method has other than public access.
> @Timeout methods invoked by the container are allowed to have "public, private, protected, or package level access".
> So the annotation should work also if method is not public.

--
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

From issues at jboss.org  Tue Mar 25 10:27:13 2014
From: issues at jboss.org (Richard Opalka (JIRA))
Date: Tue, 25 Mar 2014 10:27:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3053) BootstrapImpl#bootstrap
 result is inherently racy
In-Reply-To: <JIRA.12533770.1393855564000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12533770.1393855564000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12533770.1393855564000.5779.1395757633129@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-3053?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Richard Opalka reassigned WFLY-3053:
------------------------------------

    Assignee: Richard Opalka  (was: Jason Greene)

    
> BootstrapImpl#bootstrap result is inherently racy
> -------------------------------------------------
>
>                 Key: WFLY-3053
>                 URL: https://issues.jboss.org/browse/WFLY-3053
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Server
>            Reporter: David Lloyd
>            Assignee: Richard Opalka
>             Fix For: 8.0.1.Final
>
>
> The boostrap code presently installs a stability monitor and awaits stability before returning.  It then probes the state of the root service.  There is a window of time in which the root service may be stopped or removed, resulting in big exception traces being logged.  To atomically get the result of the operation, the service container must somehow be frozen until the root service is completely read.

--
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

From issues at jboss.org  Tue Mar 25 10:31:14 2014
From: issues at jboss.org (Tomasz Adamski (JIRA))
Date: Tue, 25 Mar 2014 10:31:14 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2509) Method invocation of a non
 serializable remote EJB
In-Reply-To: <JIRA.12525086.1384425401000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12525086.1384425401000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12525086.1384425401000.5809.1395757874676@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2509?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tomasz Adamski reassigned WFLY-2509:
------------------------------------

    Assignee: Tomasz Adamski  (was: David Lloyd)

    
> Method invocation of a non serializable remote EJB 
> ---------------------------------------------------
>
>                 Key: WFLY-2509
>                 URL: https://issues.jboss.org/browse/WFLY-2509
>             Project: WildFly
>          Issue Type: Enhancement
>      Security Level: Public(Everyone can see) 
>          Components: EJB
>            Reporter: omar al kababji
>            Assignee: Tomasz Adamski
>            Priority: Optional
>
> If you have a remote EJB that is not Serializable (i.e. does not implement the interface Serializable) you can lookup such class from a remote EJB client however when you execute a method you get an error as follows:
> java.lang.IllegalStateException: EJBCLIENT000025: No EJB receiver available for handling 
> The enhancement is to give an error or warning message when the EJB is deployed notifying the developer that he is deploying a Remote EJB that is not implementing the Serializable interface. 
> The same thing happens if you deploy an EJB marked with the annotation @Remote but with no @Stateless nor @Statefull annotations.

--
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

From issues at jboss.org  Tue Mar 25 10:33:13 2014
From: issues at jboss.org (Tomasz Adamski (JIRA))
Date: Tue, 25 Mar 2014 10:33:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2654) The run-as identity does NOT
 apply to the timeout callback method of an enterprise bean
In-Reply-To: <JIRA.12527961.1386963416000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12527961.1386963416000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12527961.1386963416000.5821.1395757993202@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2654?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tomasz Adamski reassigned WFLY-2654:
------------------------------------

    Assignee: Tomasz Adamski  (was: Stuart Douglas)

    
> The run-as identity does NOT apply to the timeout callback method of an enterprise bean
> ---------------------------------------------------------------------------------------
>
>                 Key: WFLY-2654
>                 URL: https://issues.jboss.org/browse/WFLY-2654
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: EJB, Security
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Matus Abaffy
>            Assignee: Tomasz Adamski
>
> EJB 3.2 spec., 12.3.4.1 Run-as:
> bq. The run-as identity applies ... to the timeout callback methods of an enterprise bean;
> Assume the following classes:
> {code}
> @Stateless
> @RunAs("alarm")
> public class Alarm {
>     @EJB
>     private Bell bell;
> // some more logic
>     @Timeout
>     public void ejbTimeout(Timer timer) {
>         bell.ring();
>     }
> }
> {code}
> {code}
> @Stateless
> @RolesAllowed("alarm")
> public class Bell {
>     public void ring() {}
> }
> {code}
> When the Alarm's timeout callback method is invoked due to timer expiration, bell.ring(); results in
> {code}ERROR [org.jboss.as.ejb3.invocation] (EJB default - 1) JBAS014134: EJB Invocation failed on component Bell for method public void org.jboss.as.test.integration.ejb.security.timeout.Bell.ring(): javax.ejb.EJBAccessException: JBAS014502: Invocation on method: public void org.jboss.as.test.integration.ejb.security.timeout.Bell.ring() of bean: Bell is not allowed {code}
> Calling bell.ring(); from Alarm's business methods works as expected (no error).
> Simple test case available at: https://github.com/bafco/wildfly/tree/timeoutSecurity

--
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

From issues at jboss.org  Tue Mar 25 10:33:13 2014
From: issues at jboss.org (Farah Juma (JIRA))
Date: Tue, 25 Mar 2014 10:33:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2669)
 ConcurrentModificationException releasing JSF factories
In-Reply-To: <JIRA.12528215.1387454353000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528215.1387454353000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528215.1387454353000.5824.1395757993423@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2669?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12956052#comment-12956052 ] 

Farah Juma commented on WFLY-2669:
----------------------------------

JAVASERVERFACES-3202 has now been resolved. The fix will be included in the Mojarra 2.2.7 release.
                
> ConcurrentModificationException releasing JSF factories
> -------------------------------------------------------
>
>                 Key: WFLY-2669
>                 URL: https://issues.jboss.org/browse/WFLY-2669
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JSF
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Jozef Hartinger
>            Assignee: Farah Juma
>
> Saw this happen once. Probably a thread-safety problem in JSF API:
> {code}
> 5:04:37,876 ERROR [io.undertow.servlet.request] (MSC service thread 1-4) UT015005: Error invoking method contextDestroyed on listener class com.sun.faces.config.ConfigureListener: java.util.ConcurrentModificationException
>         at java.util.HashMap$HashIterator.nextEntry(HashMap.java:926) [rt.jar:1.7.0_45]
>         at java.util.HashMap$ValueIterator.next(HashMap.java:954) [rt.jar:1.7.0_45]
>         at javax.faces.FactoryFinder.releaseFactories(FactoryFinder.java:440) [jboss-jsf-api_2.2_spec-2.2.4.jar:2.2.4]
>         at com.sun.faces.config.ConfigManager.releaseFactories(ConfigManager.java:808) [jsf-impl-2.2.4-jbossorg-1.jar:]
>         at com.sun.faces.config.ConfigManager.destroy(ConfigManager.java:474) [jsf-impl-2.2.4-jbossorg-1.jar:]
>         at com.sun.faces.config.ConfigureListener.contextDestroyed(ConfigureListener.java:329) [jsf-impl-2.2.4-jbossorg-1.jar:]
>         at io.undertow.servlet.core.ApplicationListeners.contextDestroyed(ApplicationListeners.java:185) [undertow-servlet-1.0.0.Beta27.jar:1.0.0.Beta27]
>         at io.undertow.servlet.core.DeploymentImpl.destroy(DeploymentImpl.java:216) [undertow-servlet-1.0.0.Beta27.jar:1.0.0.Beta27]
>         at io.undertow.servlet.core.DeploymentManagerImpl.undeploy(DeploymentManagerImpl.java:523) [undertow-servlet-1.0.0.Beta27.jar:1.0.0.Beta27]
>         at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.stopContext(UndertowDeploymentService.java:117)
>         at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.stop(UndertowDeploymentService.java:100)
>         at org.jboss.msc.service.ServiceControllerImpl$StopTask.stopService(ServiceControllerImpl.java:2056)
>         at org.jboss.msc.service.ServiceControllerImpl$StopTask.run(ServiceControllerImpl.java:2017)
>         at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_45]
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_45]
>         at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_45]
> {code}

--
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

From issues at jboss.org  Tue Mar 25 11:11:13 2014
From: issues at jboss.org (Jesper Pedersen (JIRA))
Date: Tue, 25 Mar 2014 11:11:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBJCA-1157) Kerberos support
In-Reply-To: <JIRA.12536024.1395760174726@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12536024.1395760174726@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12536024.1395760174726.6260.1395760273417@jira02.app.mwc.hst.phx2.redhat.com>

Jesper Pedersen created JBJCA-1157:
--------------------------------------

             Summary: Kerberos support
                 Key: JBJCA-1157
                 URL: https://issues.jboss.org/browse/JBJCA-1157
             Project: IronJacamar
          Issue Type: Task
          Components: JDBC
            Reporter: Jesper Pedersen
            Assignee: Jesper Pedersen
             Fix For: 1.0.25.Final, 1.1.5.Final, 1.2.0.Beta1




--
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

From issues at jboss.org  Tue Mar 25 14:27:13 2014
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Tue, 25 Mar 2014 14:27:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3161) Optimize
 org.jboss.as.jmx.model.RootResourceIterator
In-Reply-To: <JIRA.12536077.1395771993026@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12536077.1395771993026@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12536077.1395771993026.7041.1395772033013@jira02.app.mwc.hst.phx2.redhat.com>

Brian Stansberry created WFLY-3161:
--------------------------------------

             Summary: Optimize org.jboss.as.jmx.model.RootResourceIterator
                 Key: WFLY-3161
                 URL: https://issues.jboss.org/browse/WFLY-3161
             Project: WildFly
          Issue Type: Sub-task
      Security Level: Public (Everyone can see)
          Components: Domain Management, JMX
    Affects Versions: 8.0.0.Final
            Reporter: Brian Stansberry
            Assignee: Brian Stansberry
             Fix For: 9.0.0.CR1


RootResourceIterator is performing an access control check on a resource before confirming that the caller is in any way interested in that resource. This results in spurious access control checks. Fixing this can speed up queryMBeans and queryNames calls.

--
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

From issues at jboss.org  Tue Mar 25 17:09:15 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 25 Mar 2014 17:09:15 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3130) Add a custom RuntimeException
 to add-user utility.
In-Reply-To: <JIRA.12535302.1395159229000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12535302.1395159229000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12535302.1395159229000.7255.1395781755034@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-3130?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12956267#comment-12956267 ] 

RH Bugzilla Integration commented on WFLY-3130:
-----------------------------------------------

Paul Gier <pgier at redhat.com> changed the Status of [bug 1062595|https://bugzilla.redhat.com/show_bug.cgi?id=1062595] from MODIFIED to ON_QA
                
> Add a custom RuntimeException to add-user utility.
> --------------------------------------------------
>
>                 Key: WFLY-3130
>                 URL: https://issues.jboss.org/browse/WFLY-3130
>             Project: WildFly
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 8.0.1.Final
>
>
> The add-user utility uses a RuntimeException to indicate failure in non-interactive mode, this does not look good so should switch it to a custom exception of our own.

--
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

From issues at jboss.org  Tue Mar 25 17:09:15 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 25 Mar 2014 17:09:15 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2408) Add TRACE logging for
 connection properties used to connect to LDAP from realm.
In-Reply-To: <JIRA.12509083.1383136851000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12509083.1383136851000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12509083.1383136851000.7258.1395781755185@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2408?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12956268#comment-12956268 ] 

RH Bugzilla Integration commented on WFLY-2408:
-----------------------------------------------

Paul Gier <pgier at redhat.com> changed the Status of [bug 974324|https://bugzilla.redhat.com/show_bug.cgi?id=974324] from MODIFIED to ON_QA
                
> Add TRACE logging for connection properties used to connect to LDAP from realm.
> -------------------------------------------------------------------------------
>
>                 Key: WFLY-2408
>                 URL: https://issues.jboss.org/browse/WFLY-2408
>             Project: WildFly
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management, Security
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 8.0.0.CR1
>
>


--
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

From issues at jboss.org  Tue Mar 25 17:09:15 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 25 Mar 2014 17:09:15 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-352) Add sufficient TRACE / DEBUG
 logging to debug security realm configurations.
In-Reply-To: <JIRA.12489981.1366392604000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12489981.1366392604000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12489981.1366392604000.7265.1395781755512@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-352?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12956269#comment-12956269 ] 

RH Bugzilla Integration commented on WFLY-352:
----------------------------------------------

Paul Gier <pgier at redhat.com> changed the Status of [bug 974324|https://bugzilla.redhat.com/show_bug.cgi?id=974324] from MODIFIED to ON_QA
                
> Add sufficient TRACE / DEBUG logging to debug security realm configurations.
> ----------------------------------------------------------------------------
>
>                 Key: WFLY-352
>                 URL: https://issues.jboss.org/browse/WFLY-352
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>            Reporter: Eric Rich
>            Assignee: Darran Lofthouse
>            Priority: Critical
>             Fix For: 8.0.0.Beta1
>
>         Attachments: jboss-as-domain-management-7.1.2.Final-redhat-1.jar, log_mgmt_auth_calls.txt
>
>
> When trying to diagnose LDAP or Admin Configuration issue in Domain mode there is currently no logging for any of the authentication information. 

--
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

From issues at jboss.org  Tue Mar 25 17:09:15 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 25 Mar 2014 17:09:15 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3125) Update help text for add-user
 to reflect that password is checked against the configured policy.
In-Reply-To: <JIRA.12535263.1395145186000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12535263.1395145186000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12535263.1395145186000.7268.1395781755635@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-3125?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12956270#comment-12956270 ] 

RH Bugzilla Integration commented on WFLY-3125:
-----------------------------------------------

Paul Gier <pgier at redhat.com> changed the Status of [bug 1063888|https://bugzilla.redhat.com/show_bug.cgi?id=1063888] from MODIFIED to ON_QA
                
> Update help text for add-user to reflect that password is checked against the configured policy.
> ------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-3125
>                 URL: https://issues.jboss.org/browse/WFLY-3125
>             Project: WildFly
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 8.0.1.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

From issues at jboss.org  Tue Mar 25 17:09:15 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 25 Mar 2014 17:09:15 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3133) Misleading error message for
 add-user username requirements.
In-Reply-To: <JIRA.12535314.1395166113000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12535314.1395166113000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12535314.1395166113000.7273.1395781755884@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-3133?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12956273#comment-12956273 ] 

RH Bugzilla Integration commented on WFLY-3133:
-----------------------------------------------

Paul Gier <pgier at redhat.com> changed the Status of [bug 1062611|https://bugzilla.redhat.com/show_bug.cgi?id=1062611] from MODIFIED to ON_QA
                
> Misleading error message for add-user username requirements.
> ------------------------------------------------------------
>
>                 Key: WFLY-3133
>                 URL: https://issues.jboss.org/browse/WFLY-3133
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>    Affects Versions: 8.0.0.Final
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 8.0.1.Final
>
>
> The current error message is: -
> {code}
> JBAS015239: Only alpha/numeric usernames accepted.
> {code}
> However a small set of symbols are allowed.

--
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

From issues at jboss.org  Tue Mar 25 17:09:16 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 25 Mar 2014 17:09:16 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2474) Security subsystem does not
 handle acl's module properly, and is missing transformer
In-Reply-To: <JIRA.12524602.1383913636000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12524602.1383913636000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12524602.1383913636000.7282.1395781756291@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2474?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12956275#comment-12956275 ] 

RH Bugzilla Integration commented on WFLY-2474:
-----------------------------------------------

Paul Gier <pgier at redhat.com> changed the Status of [bug 1029938|https://bugzilla.redhat.com/show_bug.cgi?id=1029938] from MODIFIED to ON_QA
                
> Security subsystem does not handle acl's module properly, and is missing transformer
> ------------------------------------------------------------------------------------
>
>                 Key: WFLY-2474
>                 URL: https://issues.jboss.org/browse/WFLY-2474
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Kabir Khan
>            Assignee: Kabir Khan
>             Fix For: 8.0.0.CR1
>
>
> The parsed add is done for /subsystem=security/security-domain=other/acl=classic/acl-module=acl
> However in the acl resource this is called login-module=acl.
> WHen marshalling
> {code}
> 	<acl>
> 	   <acl-module name="acl" code="AclThingy" flag="required" module="test">
>                 <module-option name="d" value="r"/>
> 	   </acl-module>
> 	</acl>
> {code}
> becomes
> {code}
> 	<acl>
> 	   <login-module name="acl" code="AclThingy" flag="required" module="test">
>                 <module-option name="d" value="r"/>
> 	   </login-module>
> 	</acl>
> {code}

--
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

From issues at jboss.org  Tue Mar 25 17:09:16 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 25 Mar 2014 17:09:16 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3131) isSensitiveValue of class
 SensitiveVaultExpressionConstraint uses incorrect index in
 java.lang.String.substring method
In-Reply-To: <JIRA.12535307.1395160191000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12535307.1395160191000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12535307.1395160191000.7277.1395781756074@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-3131?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12956274#comment-12956274 ] 

RH Bugzilla Integration commented on WFLY-3131:
-----------------------------------------------

Paul Gier <pgier at redhat.com> changed the Status of [bug 1077838|https://bugzilla.redhat.com/show_bug.cgi?id=1077838] from MODIFIED to ON_QA
                
> isSensitiveValue of class SensitiveVaultExpressionConstraint uses incorrect  index in java.lang.String.substring method
> -----------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-3131
>                 URL: https://issues.jboss.org/browse/WFLY-3131
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>    Affects Versions: 8.0.0.Final
>         Environment: All
>            Reporter: Jay Kumar SenSharma
>            Assignee: Jay Kumar SenSharma
>
> The isSensitiveValue(ModelNode value) method of class "org.jboss.as.controller.access.constraint.SensitiveVaultExpressionConstraint" seems to be using the incorrect  index in java.lang.String.substring method.  Which is causing the following exceptions in the logs while executing the following kind of CLI command:
> {code}
> [standalone at localhost:9990 /] /subsystem=logging/periodic-rotating-file-handler=FILE:write-attribute(name=formatter, value="%d{HH:mm:ss,SSS} %-5p [%c] (${jboss.node.name} %t) %s%E%n")
> {
>     "outcome" => "failed",
>     "failure-description" => "JBAS014749: Operation handler failed: String index out of range: -15",
>     "rolled-back" => true
> }
> {code}
> The Exception can be seen as following in the WildFly Logs:
> {code}
> 21:58:04,821 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 25) JBAS014612: Operation ("write-attribute") failed - address: ([
>     ("subsystem" => "logging"),
>     ("periodic-rotating-file-handler" => "FILE")
> ]): java.lang.StringIndexOutOfBoundsException: String index out of range: -15
> 	at java.lang.String.substring(String.java:1911) [rt.jar:1.7.0_51]
> 	at org.jboss.as.controller.access.constraint.SensitiveVaultExpressionConstraint$Factory.isSensitiveValue(SensitiveVaultExpressionConstraint.java:128) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> 	at org.jboss.as.controller.access.constraint.SensitiveVaultExpressionConstraint$Factory.isSensitiveAction(SensitiveVaultExpressionConstraint.java:89) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> 	at org.jboss.as.controller.access.constraint.SensitiveVaultExpressionConstraint$Factory.getRequiredConstraint(SensitiveVaultExpressionConstraint.java:81) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> 	at org.jboss.as.controller.access.rbac.DefaultPermissionFactory.getRequiredPermissions(DefaultPermissionFactory.java:201) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> 	at org.jboss.as.controller.access.permission.ManagementPermissionAuthorizer.authorize(ManagementPermissionAuthorizer.java:100) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> 	at org.jboss.as.controller.access.management.DelegatingConfigurableAuthorizer.authorize(DelegatingConfigurableAuthorizer.java:98) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> 	at org.jboss.as.controller.OperationContextImpl.getBasicAuthorizationResponse(OperationContextImpl.java:1153) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> 	at org.jboss.as.controller.OperationContextImpl.authorize(OperationContextImpl.java:1055) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> 	at org.jboss.as.controller.OperationContextImpl.authorize(OperationContextImpl.java:1015) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> 	at org.jboss.as.controller.OperationContextImpl.getResourceRegistration(OperationContextImpl.java:265) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> 	at org.jboss.as.controller.operations.global.WriteAttributeHandler.execute(WriteAttributeHandler.java:72) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> 	at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:591) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> 	at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:469) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> 	at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:273) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> 	at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:268) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> 	at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:272) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> 	at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:146) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:174) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$300(ModelControllerClientOperationHandler.java:105) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:125) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:121) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> 	at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.7.0_51]
> 	at javax.security.auth.Subject.doAs(Subject.java:415) [rt.jar:1.7.0_51]
> 	at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:94) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:121) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> 	at org.jboss.as.protocol.mgmt.AbstractMessageHandler$2$1.doExecute(AbstractMessageHandler.java:283) [wildfly-protocol-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> 	at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:504) [wildfly-protocol-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_51]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_51]
> 	at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_51]
> 	at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.1.Final.jar:2.1.1.Final]
> {code}

--
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

From issues at jboss.org  Tue Mar 25 17:09:16 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 25 Mar 2014 17:09:16 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2303) mod_cluster XSD is missing
 property and worker-timeout definitions
In-Reply-To: <JIRA.12503065.1381830758000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12503065.1381830758000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12503065.1381830758000.7293.1395781756788@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2303?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12956278#comment-12956278 ] 

RH Bugzilla Integration commented on WFLY-2303:
-----------------------------------------------

Paul Gier <pgier at redhat.com> changed the Status of [bug 1020142|https://bugzilla.redhat.com/show_bug.cgi?id=1020142] from MODIFIED to ON_QA
                
> mod_cluster XSD is missing property and worker-timeout definitions
> ------------------------------------------------------------------
>
>                 Key: WFLY-2303
>                 URL: https://issues.jboss.org/browse/WFLY-2303
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Clustering
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Radoslav Husar
>            Assignee: Radoslav Husar
>             Fix For: 8.0.0.CR1
>
>
> * worker-timeout
> * property
> are missing.
> Also missing in 7.x

--
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

From issues at jboss.org  Tue Mar 25 17:09:17 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 25 Mar 2014 17:09:17 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (SECURITY-805) Overload
 SecurityVaultFactory.get() to be able to specify the classloader
In-Reply-To: <JIRA.12535004.1394795116000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12535004.1394795116000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12535004.1394795116000.7301.1395781757192@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/SECURITY-805?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12956280#comment-12956280 ] 

RH Bugzilla Integration commented on SECURITY-805:
--------------------------------------------------

Paul Gier <pgier at redhat.com> changed the Status of [bug 1079930|https://bugzilla.redhat.com/show_bug.cgi?id=1079930] from MODIFIED to ON_QA
                
> Overload SecurityVaultFactory.get() to be able to specify the classloader
> -------------------------------------------------------------------------
>
>                 Key: SECURITY-805
>                 URL: https://issues.jboss.org/browse/SECURITY-805
>             Project: PicketBox 
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>            Reporter: Kabir Khan
>            Assignee: Kabir Khan
>             Fix For: PicketBox_4_0_21.Beta2, PicketBox_4_0_19.SP5
>
>         Attachments: SECURITY-805-2.diff, SECURITY-805.diff
>
>
> To work better with modular class loading in WF

--
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

From issues at jboss.org  Tue Mar 25 17:09:17 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 25 Mar 2014 17:09:17 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2214) Allow additional environment
 properties to be set for outbound LDAP connections used by security realms.
In-Reply-To: <JIRA.12502155.1380834418000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502155.1380834418000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502155.1380834418000.7305.1395781757357@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2214?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12956281#comment-12956281 ] 

RH Bugzilla Integration commented on WFLY-2214:
-----------------------------------------------

Paul Gier <pgier at redhat.com> changed the Status of [bug 1015303|https://bugzilla.redhat.com/show_bug.cgi?id=1015303] from MODIFIED to ON_QA
                
> Allow additional environment properties to be set for outbound LDAP connections used by security realms.
> --------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2214
>                 URL: https://issues.jboss.org/browse/WFLY-2214
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Derek Horton
>            Assignee: Darran Lofthouse
>             Fix For: 8.0.0.CR1
>
>
> LDAP security realm needs to have configurable timeouts.
> The default LDAP connection timeout appears to be 2 minutes.  If the ldap server is down, it could take 2 minutes for the connection to timeout.  This can cause unneeded delay if you have configured multiple ldap servers for  failover / redundancy.
> The following hack appears to work:
> +++ domain-management/src/main/java/org/jboss/as/domain/management/connections/ldap/LdapConnectionManagerService.java
> @@ -132,6 +132,7 @@ public class LdapConnectionManagerService implements Service<LdapConnectionManag
>          result.put(Context.INITIAL_CONTEXT_FACTORY,initialContextFactory);
>          String url = config.require(URL).asString();
>          result.put(Context.PROVIDER_URL,url);
> +        result.put("com.sun.jndi.ldap.connect.timeout", "500");
>          return result;
>      }

--
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

From issues at jboss.org  Tue Mar 25 17:09:17 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 25 Mar 2014 17:09:17 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2538) Certificate acceptance
 causing command entered on starting the CLI to be skipped.
In-Reply-To: <JIRA.12525580.1384872293000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12525580.1384872293000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12525580.1384872293000.7312.1395781757706@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2538?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12956283#comment-12956283 ] 

RH Bugzilla Integration commented on WFLY-2538:
-----------------------------------------------

Paul Gier <pgier at redhat.com> changed the Status of [bug 1026418|https://bugzilla.redhat.com/show_bug.cgi?id=1026418] from MODIFIED to ON_QA
                
> Certificate acceptance causing command entered on starting the CLI to be skipped.
> ---------------------------------------------------------------------------------
>
>                 Key: WFLY-2538
>                 URL: https://issues.jboss.org/browse/WFLY-2538
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: CLI
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 8.0.0.CR1
>
>
> e.g.
> {noformat}
> ./jboss-cli.sh -c shutdown
> Accept certificate? [N]o, [T]emporarily, [P]ermenantly : T
> {noformat}
> The shutdown command is not executed.

--
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

From issues at jboss.org  Tue Mar 25 17:09:18 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 25 Mar 2014 17:09:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2950) jboss-cli using
 https-remoting: command not executed if certificate is unrecognised
In-Reply-To: <JIRA.12532472.1392721164000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12532472.1392721164000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12532472.1392721164000.7320.1395781758093@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2950?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12956287#comment-12956287 ] 

RH Bugzilla Integration commented on WFLY-2950:
-----------------------------------------------

Paul Gier <pgier at redhat.com> changed the Status of [bug 1026418|https://bugzilla.redhat.com/show_bug.cgi?id=1026418] from MODIFIED to ON_QA
                
> jboss-cli using https-remoting: command not executed if certificate is unrecognised
> -----------------------------------------------------------------------------------
>
>                 Key: WFLY-2950
>                 URL: https://issues.jboss.org/browse/WFLY-2950
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: CLI, Domain Management
>    Affects Versions: 8.0.0.Final
>         Environment: Windows 7 Pro
>            Reporter: Darren Jones
>            Assignee: Darran Lofthouse
>              Labels: cli, shutdown
>             Fix For: 8.0.1.Final
>
>
> When using the https management interface from jboss-cli, commands passed with a command line option (such as --command=:shutdown) are not executed if the server certificate is unrecognised - even if accepting the certificate [T]emporarily or [P]ermenantly.
> It appears to be due to the CommandContextImpl.handleSSLFailure() method, which calls error("Unable to connect..."). The error() method sets the exitCode to 1. So, when CliLauncher.processCommands() subsequently runs, it sees that the cmdCtx.exitCode is 1 and ignores any commands.
> I guess the handleSSLFailure needs to reset the exitCode to 0 if the user chooses [T] or [P].

--
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

From issues at jboss.org  Tue Mar 25 17:11:13 2014
From: issues at jboss.org (John L (JIRA))
Date: Tue, 25 Mar 2014 17:11:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBLOGGING-101) Each custom log handler
 defined in standalone adds a root log4j console appender
In-Reply-To: <JIRA.12536084.1395781813382@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12536084.1395781813382@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12536084.1395781813382.7342.1395781873425@jira02.app.mwc.hst.phx2.redhat.com>

John L created JBLOGGING-101:
--------------------------------

             Summary: Each custom log handler defined in standalone adds a root log4j console appender
                 Key: JBLOGGING-101
                 URL: https://issues.jboss.org/browse/JBLOGGING-101
             Project: JBoss Logging
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: jboss-logging-log4j
            Reporter: John L
            Assignee: James Perkins


JBoss 7.1.3 Logging custom handlers which are used to wrap existing log4j handlers
into jboss logging handlers calls 
org.jboss.as.logging.handlers.custom.PropertiesConfigurator 
which calls org.apache.log4j.BasicConfigurator.configure()
which by default adds a ConsoleAppender. Maybe should be calling
org.apache.log4j.BasicConfigurator.configure(new NullAppender()); to initialize log4j.
Net result is all log4j messages get forwarded to jboss logging add also get sent to the default ConsoleAppender which then writes it out stdout which then jboss catches
as stdout. So we have 3 custom handlers in our jboss configuration so we get 4 messages
to the screen. (1 for real category and 3 for each console appender added).

Not sure if this is reported in correct project.

--
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

From issues at jboss.org  Tue Mar 25 17:21:13 2014
From: issues at jboss.org (Stuart Douglas (JIRA))
Date: Tue, 25 Mar 2014 17:21:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3144) Session replication doesn't
 work as expected
In-Reply-To: <JIRA.12535573.1395324594000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12535573.1395324594000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12535573.1395324594000.7364.1395782473339@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-3144?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stuart Douglas reassigned WFLY-3144:
------------------------------------

    Assignee: Paul Ferraro  (was: Stuart Douglas)

    
> Session replication doesn't work as expected
> --------------------------------------------
>
>                 Key: WFLY-3144
>                 URL: https://issues.jboss.org/browse/WFLY-3144
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: CDI / Weld, Clustering, EJB
>    Affects Versions: 8.0.0.Final
>            Reporter: Tomas Remes
>            Assignee: Paul Ferraro
>         Attachments: translator.zip
>
>
> I am experimenting with quite simple Stateful SessionScoped bean  ( see org.jboss.weld.tests.clustering.translator.TranslatorControllerBean from attached reproducer) and actually there's not any specific exception, but the behavior is at least weird. I haven't tried with plain EJB so far. Reproducible by following steps:
> 1. Run first node with "/bin/standalone.sh -c standalone-ha.xml"
> 2. Run second node with "./bin/standalone.sh -c standalone-ha.xml -Djboss.socket.binding.port-offset=100 -Djboss.node.name=second"
> 3. Build and deploy attached reproducer
> 4. Open 127.0.0.1:8080/translator in your browser and translate something.
> 5. Open 127.0.0.1:8180/translator and note that number of translated sentences is not replicated correctly. 
> This works correctly in EAP. I am running with default standalone-ha configuration on oracle's 1.7.0_45 jdk.

--
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

From issues at jboss.org  Tue Mar 25 18:11:12 2014
From: issues at jboss.org (Richard Achmatowicz (JIRA))
Date: Tue, 25 Mar 2014 18:11:12 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1801) DuplicateTest fails when
 testing OOB multicast to all three senders
In-Reply-To: <JIRA.12533765.1393853856000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12533765.1393853856000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12533765.1393853856000.7456.1395785472931@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JGRP-1801?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12956308#comment-12956308 ] 

Richard Achmatowicz commented on JGRP-1801:
-------------------------------------------

I managed to reproduce this issue locally on my Windows 7 partition, which, thankfully, is also slow as the machines in the QA lab.

To recap, the failures occur for both TCP and UDP, and involve OOB multicast messages. Messages from one of the senders do not get through. Here are some new debugging results:
- disable the OOB thread pool, the tests always pass on both UDP and TCP
- enable the OOB thread pool, I always seem to get at least one failure on both TCP and UDP

So, it appears this issue has something to do with use of the OOB thread pool. 

I also noticed that the assertion which is failing (the assertion which checks that at least some messages from all three senders has arrived) is checked after 10 seconds. Because this is not a performance test, there is no harm in extending this timeout to, say, 60 seconds. 



 
                
> DuplicateTest fails when testing OOB multicast to all three senders
> -------------------------------------------------------------------
>
>                 Key: JGRP-1801
>                 URL: https://issues.jboss.org/browse/JGRP-1801
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.2.13
>         Environment: Windows (18), Solaris (2), RHEL(1) where (x) is the number of failures seen
>            Reporter: Richard Achmatowicz
>            Assignee: Bela Ban
>             Fix For: 3.2.14
>
>
> DuplicateTest does the following:
> - creates three channels containing the DUPL layer called c1, c2, c3
> - DUPL is used to duplicate messages sent
> - channel receiver for channel each keeps a map of messages received from each sender
> - channels send messages: regular, OOB, or mixed
> - the test checks that the messages received  by each channel are correct in number and in order
> The test testOOBMuloticastToAll3Senders is failing regularly on multple platforms. The test makes each of the channels send OOB multicast messages to the group, but only two of three members ever end up receiving the multicast messages. Al example of the failure:
> {noformat}
> Error Message
> expected size=3, msgs: [C2, C1]
> Stacktrace
> java.lang.AssertionError 
> at org.jgroups.tests.DuplicateTest.check(DuplicateTest.java:217) 
> at org.jgroups.tests.DuplicateTest.testOOBMulticastToAll3Senders(DuplicateTest.java:123) 
> {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

From issues at jboss.org  Tue Mar 25 18:47:13 2014
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Tue, 25 Mar 2014 18:47:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3162) audit syslog handler should
 be able to automatically reconnect
In-Reply-To: <JIRA.12536088.1395787531000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12536088.1395787531000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12536088.1395787531000.7506.1395787633864@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-3162?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry moved PRODMGT-773 to WFLY-3162:
------------------------------------------------

              Project: WildFly  (was: Product Management)
                  Key: WFLY-3162  (was: PRODMGT-773)
             Workflow: GIT Pull Request workflow   (was: JBoss Platforms RFE Workflow v2)
    Affects Version/s: 8.0.0.Final
                           (was: 6)
          Component/s: Domain Management
                           (was: Enterprise Application Platform (EAP))
             Security: Public

    
> audit syslog handler should be able to automatically reconnect
> --------------------------------------------------------------
>
>                 Key: WFLY-3162
>                 URL: https://issues.jboss.org/browse/WFLY-3162
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>    Affects Versions: 8.0.0.Final
>            Reporter: Tom Fonteyne
>            Assignee: John Doyle
>
> When the syslog server goes down, WF will retry (up to 10 times we believe) to reconnect but will then give up. You can manually force a reconnect by issuing:
> /host=master/core-service=management/access=audit/syslog-handler=mysyslog:recycle
> This request is to make it possible to automate this and make it configurable at which interval it should try and reconnect

--
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

From issues at jboss.org  Tue Mar 25 18:49:13 2014
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Tue, 25 Mar 2014 18:49:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3162) audit syslog handler should
 be able to automatically reconnect
In-Reply-To: <JIRA.12536088.1395787531000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12536088.1395787531000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12536088.1395787531000.7510.1395787753069@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-3162?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFLY-3162:
-----------------------------------

    Assignee:     (was: John Doyle)

    
> audit syslog handler should be able to automatically reconnect
> --------------------------------------------------------------
>
>                 Key: WFLY-3162
>                 URL: https://issues.jboss.org/browse/WFLY-3162
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>    Affects Versions: 8.0.0.Final
>            Reporter: Tom Fonteyne
>
> When the syslog server goes down, WF will retry (up to 10 times we believe) to reconnect but will then give up. You can manually force a reconnect by issuing:
> /host=master/core-service=management/access=audit/syslog-handler=mysyslog:recycle
> This request is to make it possible to automate this and make it configurable at which interval it should try and reconnect

--
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

From issues at jboss.org  Tue Mar 25 18:49:13 2014
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Tue, 25 Mar 2014 18:49:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3162) audit syslog handler should
 be able to automatically reconnect
In-Reply-To: <JIRA.12536088.1395787531000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12536088.1395787531000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12536088.1395787531000.7514.1395787753255@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-3162?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFLY-3162:
-----------------------------------

    Labels: EAP  (was: )

    
> audit syslog handler should be able to automatically reconnect
> --------------------------------------------------------------
>
>                 Key: WFLY-3162
>                 URL: https://issues.jboss.org/browse/WFLY-3162
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>    Affects Versions: 8.0.0.Final
>            Reporter: Tom Fonteyne
>              Labels: EAP
>
> When the syslog server goes down, WF will retry (up to 10 times we believe) to reconnect but will then give up. You can manually force a reconnect by issuing:
> /host=master/core-service=management/access=audit/syslog-handler=mysyslog:recycle
> This request is to make it possible to automate this and make it configurable at which interval it should try and reconnect

--
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

From issues at jboss.org  Tue Mar 25 18:55:13 2014
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Tue, 25 Mar 2014 18:55:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3163) EAP 6.2 audit log should
 display the EAP version instead of the AS version
In-Reply-To: <JIRA.12532685.1392822921000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12532685.1392822921000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12532685.1392822921000.7529.1395788113449@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-3163?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry moved PRODMGT-721 to WFLY-3163:
------------------------------------------------

              Project: WildFly  (was: Product Management)
                  Key: WFLY-3163  (was: PRODMGT-721)
           Issue Type: Bug  (was: Feature Request)
             Workflow: GIT Pull Request workflow   (was: JBoss Platforms RFE Workflow v2)
    Affects Version/s: 8.0.0.Final
                           (was: 6)
          Component/s: Domain Management
                           (was: Enterprise Application Platform (EAP))
             Security: Public

    
> EAP 6.2 audit log should display the EAP version instead of the AS version
> --------------------------------------------------------------------------
>
>                 Key: WFLY-3163
>                 URL: https://issues.jboss.org/browse/WFLY-3163
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>    Affects Versions: 8.0.0.Final
>            Reporter: Tom Fonteyne
>            Assignee: John Doyle
>
> EAP audit log should display the EAP version instead of the AS version
> Currently the audit log shows the AS version number instead of the EAP version. Example:
> Feb 13 07:55:43 efjkffglk000000719 syslogappname[553]: 2014-02-13 07:55:43 - {"type" : "core", "r/o" : false, "booting" : false, "version" : "7.3.0.Final-redhat-14", "user" : "$local", "domainUUID" : null, "access" : "NATIVE", "remote-address" : "10.10.10.250/10.10.10.250", "success" : true, "ops" : [{"address" : [{ "host" : "master" },{ "core-service" : "management" },{ "access" : "audit" },{ "logger" : "audit-log" }], "operation" : "write-attribute", "name" : "enabled", "value" : false, "operation-headers" : {"caller-type" : "user", "access-mechanism" : "NATIVE", "domain-uuid" : "fead80e4-690d-4bcf-af71-ecaf30f98381", "push-to-servers" : null}}]}
> "version" : "7.3.0.Final-redhat-14"
> This should show:
> "version" : "6.2.1.GA" 
> There's a request that it show something like "6.2 CP01" but that is a patch file name, not a software version, and is unknown to the software.

--
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

From issues at jboss.org  Tue Mar 25 18:55:13 2014
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Tue, 25 Mar 2014 18:55:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3163) EAP audit log should display
 the EAP version instead of the AS version
In-Reply-To: <JIRA.12532685.1392822921000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12532685.1392822921000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12532685.1392822921000.7536.1395788113763@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-3163?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFLY-3163:
-----------------------------------

    Summary: EAP audit log should display the EAP version instead of the AS version  (was: EAP 6.2 audit log should display the EAP version instead of the AS version)

    
> EAP audit log should display the EAP version instead of the AS version
> ----------------------------------------------------------------------
>
>                 Key: WFLY-3163
>                 URL: https://issues.jboss.org/browse/WFLY-3163
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>    Affects Versions: 8.0.0.Final
>            Reporter: Tom Fonteyne
>            Assignee: John Doyle
>
> EAP audit log should display the EAP version instead of the AS version
> Currently the audit log shows the AS version number instead of the EAP version. Example:
> Feb 13 07:55:43 efjkffglk000000719 syslogappname[553]: 2014-02-13 07:55:43 - {"type" : "core", "r/o" : false, "booting" : false, "version" : "7.3.0.Final-redhat-14", "user" : "$local", "domainUUID" : null, "access" : "NATIVE", "remote-address" : "10.10.10.250/10.10.10.250", "success" : true, "ops" : [{"address" : [{ "host" : "master" },{ "core-service" : "management" },{ "access" : "audit" },{ "logger" : "audit-log" }], "operation" : "write-attribute", "name" : "enabled", "value" : false, "operation-headers" : {"caller-type" : "user", "access-mechanism" : "NATIVE", "domain-uuid" : "fead80e4-690d-4bcf-af71-ecaf30f98381", "push-to-servers" : null}}]}
> "version" : "7.3.0.Final-redhat-14"
> This should show:
> "version" : "6.2.1.GA" 
> There's a request that it show something like "6.2 CP01" but that is a patch file name, not a software version, and is unknown to the software.

--
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

From issues at jboss.org  Tue Mar 25 18:55:14 2014
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Tue, 25 Mar 2014 18:55:14 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3163) EAP audit log should display
 the EAP version instead of the AS version
In-Reply-To: <JIRA.12532685.1392822921000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12532685.1392822921000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12532685.1392822921000.7543.1395788114093@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-3163?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry reassigned WFLY-3163:
--------------------------------------

    Assignee: Brian Stansberry  (was: John Doyle)

    
> EAP audit log should display the EAP version instead of the AS version
> ----------------------------------------------------------------------
>
>                 Key: WFLY-3163
>                 URL: https://issues.jboss.org/browse/WFLY-3163
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>    Affects Versions: 8.0.0.Final
>            Reporter: Tom Fonteyne
>            Assignee: Brian Stansberry
>
> EAP audit log should display the EAP version instead of the AS version
> Currently the audit log shows the AS version number instead of the EAP version. Example:
> Feb 13 07:55:43 efjkffglk000000719 syslogappname[553]: 2014-02-13 07:55:43 - {"type" : "core", "r/o" : false, "booting" : false, "version" : "7.3.0.Final-redhat-14", "user" : "$local", "domainUUID" : null, "access" : "NATIVE", "remote-address" : "10.10.10.250/10.10.10.250", "success" : true, "ops" : [{"address" : [{ "host" : "master" },{ "core-service" : "management" },{ "access" : "audit" },{ "logger" : "audit-log" }], "operation" : "write-attribute", "name" : "enabled", "value" : false, "operation-headers" : {"caller-type" : "user", "access-mechanism" : "NATIVE", "domain-uuid" : "fead80e4-690d-4bcf-af71-ecaf30f98381", "push-to-servers" : null}}]}
> "version" : "7.3.0.Final-redhat-14"
> This should show:
> "version" : "6.2.1.GA" 
> There's a request that it show something like "6.2 CP01" but that is a patch file name, not a software version, and is unknown to the software.

--
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

From issues at jboss.org  Tue Mar 25 18:55:14 2014
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Tue, 25 Mar 2014 18:55:14 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3163) EAP audit log should display
 the EAP version instead of the AS version
In-Reply-To: <JIRA.12532685.1392822921000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12532685.1392822921000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12532685.1392822921000.7546.1395788114269@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-3163?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFLY-3163:
-----------------------------------


    
> EAP audit log should display the EAP version instead of the AS version
> ----------------------------------------------------------------------
>
>                 Key: WFLY-3163
>                 URL: https://issues.jboss.org/browse/WFLY-3163
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>    Affects Versions: 8.0.0.Final
>            Reporter: Tom Fonteyne
>            Assignee: Brian Stansberry
>
> EAP audit log should display the EAP version instead of the AS version
> Currently the audit log shows the AS version number instead of the EAP version. Example:
> Feb 13 07:55:43 efjkffglk000000719 syslogappname[553]: 2014-02-13 07:55:43 - {"type" : "core", "r/o" : false, "booting" : false, "version" : "7.3.0.Final-redhat-14", "user" : "$local", "domainUUID" : null, "access" : "NATIVE", "remote-address" : "10.10.10.250/10.10.10.250", "success" : true, "ops" : [{"address" : [{ "host" : "master" },{ "core-service" : "management" },{ "access" : "audit" },{ "logger" : "audit-log" }], "operation" : "write-attribute", "name" : "enabled", "value" : false, "operation-headers" : {"caller-type" : "user", "access-mechanism" : "NATIVE", "domain-uuid" : "fead80e4-690d-4bcf-af71-ecaf30f98381", "push-to-servers" : null}}]}
> "version" : "7.3.0.Final-redhat-14"
> This should show:
> "version" : "6.2.1.GA" 
> There's a request that it show something like "6.2 CP01" but that is a patch file name, not a software version, and is unknown to the software.

--
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

From issues at jboss.org  Tue Mar 25 19:01:13 2014
From: issues at jboss.org (Jared Morgan (JIRA))
Date: Tue, 25 Mar 2014 19:01:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (HIBERNATE-144) somes images have 404 on
	doc site
In-Reply-To: <JIRA.12535975.1395739702000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12535975.1395739702000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12535975.1395739702000.7578.1395788473254@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/HIBERNATE-144?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jared Morgan moved JBDOCS-355 to HIBERNATE-144:
-----------------------------------------------

       Project: Hibernate Integration  (was: Documentation)
           Key: HIBERNATE-144  (was: JBDOCS-355)
    Issue Type: Bug  (was: Feature Request)
      Security:     (was: Public)

    
> somes images have 404 on doc site
> ---------------------------------
>
>                 Key: HIBERNATE-144
>                 URL: https://issues.jboss.org/browse/HIBERNATE-144
>             Project: Hibernate Integration
>          Issue Type: Bug
>            Reporter: Emmanuel Borlet
>            Assignee: Jared Morgan
>            Priority: Minor
>
> hello,
> on this pages images have 404 :
> http://docs.jboss.org/hibernate/orm/4.1/devguide/en-US/html/ch16.html
> http://docs.jboss.org/hibernate/orm/4.3/devguide/en-US/html/ch16.html
> Cordialement
> Emmanuel Borlet

--
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

From issues at jboss.org  Tue Mar 25 19:01:13 2014
From: issues at jboss.org (Jared Morgan (JIRA))
Date: Tue, 25 Mar 2014 19:01:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (HIBERNATE-144) somes images have 404 on
	doc site
In-Reply-To: <JIRA.12535975.1395739702000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12535975.1395739702000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12535975.1395739702000.7580.1395788473346@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/HIBERNATE-144?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12956317#comment-12956317 ] 

Jared Morgan commented on HIBERNATE-144:
----------------------------------------

Hi Emmanuel

Thanks for taking the time for logging this bug. Looks like this book is missing some image files.

Let me see if I can re-route this issue to the Hibernate project so they can fix the issue.

Thanks for your help with keeping JBoss.org docs accurate.

Cheers

Jared
                
> somes images have 404 on doc site
> ---------------------------------
>
>                 Key: HIBERNATE-144
>                 URL: https://issues.jboss.org/browse/HIBERNATE-144
>             Project: Hibernate Integration
>          Issue Type: Bug
>            Reporter: Emmanuel Borlet
>            Assignee: Jared Morgan
>            Priority: Minor
>
> hello,
> on this pages images have 404 :
> http://docs.jboss.org/hibernate/orm/4.1/devguide/en-US/html/ch16.html
> http://docs.jboss.org/hibernate/orm/4.3/devguide/en-US/html/ch16.html
> Cordialement
> Emmanuel Borlet

--
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

From issues at jboss.org  Tue Mar 25 19:03:12 2014
From: issues at jboss.org (Jared Morgan (JIRA))
Date: Tue, 25 Mar 2014 19:03:12 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (HIBERNATE-144) somes images have 404 on
	doc site
In-Reply-To: <JIRA.12535975.1395739702000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12535975.1395739702000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12535975.1395739702000.7584.1395788592939@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/HIBERNATE-144?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jared Morgan updated HIBERNATE-144:
-----------------------------------

                  Labels: documentation  (was: )
    Estimated Difficulty: Low
                 Affects: Documentation (Ref Guide, User Guide, etc.)

    
> somes images have 404 on doc site
> ---------------------------------
>
>                 Key: HIBERNATE-144
>                 URL: https://issues.jboss.org/browse/HIBERNATE-144
>             Project: Hibernate Integration
>          Issue Type: Bug
>            Reporter: Emmanuel Borlet
>            Assignee: Jared Morgan
>            Priority: Minor
>              Labels: documentation
>
> hello,
> on this pages images have 404 :
> http://docs.jboss.org/hibernate/orm/4.1/devguide/en-US/html/ch16.html
> http://docs.jboss.org/hibernate/orm/4.3/devguide/en-US/html/ch16.html
> Cordialement
> Emmanuel Borlet

--
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

From issues at jboss.org  Tue Mar 25 19:03:13 2014
From: issues at jboss.org (Jared Morgan (JIRA))
Date: Tue, 25 Mar 2014 19:03:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (HIBERNATE-144) somes images have 404 on
	doc site
In-Reply-To: <JIRA.12535975.1395739702000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12535975.1395739702000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12535975.1395739702000.7587.1395788593073@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/HIBERNATE-144?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jared Morgan updated HIBERNATE-144:
-----------------------------------

    Assignee: Steve Ebersole  (was: Jared Morgan)

    
> somes images have 404 on doc site
> ---------------------------------
>
>                 Key: HIBERNATE-144
>                 URL: https://issues.jboss.org/browse/HIBERNATE-144
>             Project: Hibernate Integration
>          Issue Type: Bug
>            Reporter: Emmanuel Borlet
>            Assignee: Steve Ebersole
>            Priority: Minor
>              Labels: documentation
>
> hello,
> on this pages images have 404 :
> http://docs.jboss.org/hibernate/orm/4.1/devguide/en-US/html/ch16.html
> http://docs.jboss.org/hibernate/orm/4.3/devguide/en-US/html/ch16.html
> Cordialement
> Emmanuel Borlet

--
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

From issues at jboss.org  Tue Mar 25 19:13:12 2014
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Tue, 25 Mar 2014 19:13:12 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3164) Create customized Audit Logger
In-Reply-To: <JIRA.12536089.1395789072176@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12536089.1395789072176@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12536089.1395789072176.7595.1395789192957@jira02.app.mwc.hst.phx2.redhat.com>

Kabir Khan created WFLY-3164:
--------------------------------

             Summary: Create customized Audit Logger
                 Key: WFLY-3164
                 URL: https://issues.jboss.org/browse/WFLY-3164
             Project: WildFly
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: Domain Management
            Reporter: Kabir Khan
            Assignee: Brian Stansberry
             Fix For: 9.0.0.CR1


Some users want to have a single line audit log formatter. I think it would be better to have the ability to add your own formatter from a module, something along the lines of:
{code}
<custom-formatter code="org.blah.MyCustomFormatter" module="org.blah/mymodule">
   <property name="layout">...</property>
   <property name="propB">...</property>
</custom-formatter>
{code}
We'd need an SPI, and a slight reworking of the audit log internals. In any case doing this will put us in a better position to provide the single line logger if this proposal is not acceptable to our users.

--
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

From issues at jboss.org  Tue Mar 25 19:29:13 2014
From: issues at jboss.org (James Livingston (JIRA))
Date: Tue, 25 Mar 2014 19:29:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1013) Can't set attribute "suffix"
 on web access-log
In-Reply-To: <JIRA.12471975.1344415283000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12471975.1344415283000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12471975.1344415283000.7643.1395790153191@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-1013?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

James Livingston reassigned WFLY-1013:
--------------------------------------

    Assignee: James Livingston  (was: Tomaz Cerar)

    
> Can't set attribute "suffix" on web access-log
> ----------------------------------------------
>
>                 Key: WFLY-1013
>                 URL: https://issues.jboss.org/browse/WFLY-1013
>             Project: WildFly
>          Issue Type: Enhancement
>      Security Level: Public(Everyone can see) 
>          Components: Web (Undertow)
>         Environment: N/A
>            Reporter: Ed Roberts
>            Assignee: James Livingston
>              Labels: logging, suffix, web
>
> In JBoss 5.x you used to be able to specify a suffix attribute value for the JBossWeb access log file, which would be appended to generated log file names.
> In JBoss 7.x you can only specify a prefix. For the logging handlers you can specify both a prefix and a suffix, which is inconsistent.
> Please add the suffix attribute to the access-log element within the parent virtual-server element of the web subsystem xml configuration.

--
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

From issues at jboss.org  Tue Mar 25 19:55:13 2014
From: issues at jboss.org (James Perkins (JIRA))
Date: Tue, 25 Mar 2014 19:55:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBLOGGING-101) Each custom log handler
 defined in standalone adds a root log4j console appender
In-Reply-To: <JIRA.12536084.1395781813000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12536084.1395781813000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12536084.1395781813000.7676.1395791713087@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JBLOGGING-101?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12956322#comment-12956322 ] 

James Perkins commented on JBLOGGING-101:
-----------------------------------------

This is probably the closest to the right project :) There is no JIRA for the {{log4j-jboss-logmanager}}, so this is good enough. That said it's already fixed in {{1.1.0.Final}} which should be compatible with older version of JBoss AS 7.
                
> Each custom log handler defined in standalone adds a root log4j console appender
> --------------------------------------------------------------------------------
>
>                 Key: JBLOGGING-101
>                 URL: https://issues.jboss.org/browse/JBLOGGING-101
>             Project: JBoss Logging
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: jboss-logging-log4j
>            Reporter: John L
>            Assignee: James Perkins
>
> JBoss 7.1.3 Logging custom handlers which are used to wrap existing log4j handlers
> into jboss logging handlers calls 
> org.jboss.as.logging.handlers.custom.PropertiesConfigurator 
> which calls org.apache.log4j.BasicConfigurator.configure()
> which by default adds a ConsoleAppender. Maybe should be calling
> org.apache.log4j.BasicConfigurator.configure(new NullAppender()); to initialize log4j.
> Net result is all log4j messages get forwarded to jboss logging add also get sent to the default ConsoleAppender which then writes it out stdout which then jboss catches
> as stdout. So we have 3 custom handlers in our jboss configuration so we get 4 messages
> to the screen. (1 for real category and 3 for each console appender added).
> Not sure if this is reported in correct project.

--
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

From issues at jboss.org  Tue Mar 25 19:55:13 2014
From: issues at jboss.org (James Perkins (JIRA))
Date: Tue, 25 Mar 2014 19:55:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBLOGGING-101) Each custom log handler
 defined in standalone adds a root log4j console appender
In-Reply-To: <JIRA.12536084.1395781813000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12536084.1395781813000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12536084.1395781813000.7678.1395791713189@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBLOGGING-101?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

James Perkins closed JBLOGGING-101.
-----------------------------------

    Resolution: Out of Date


Already fixed in {{org.jboss.logmanager:log4j-jboss-logmanager:1.1.0.Final}}
                
> Each custom log handler defined in standalone adds a root log4j console appender
> --------------------------------------------------------------------------------
>
>                 Key: JBLOGGING-101
>                 URL: https://issues.jboss.org/browse/JBLOGGING-101
>             Project: JBoss Logging
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: jboss-logging-log4j
>            Reporter: John L
>            Assignee: James Perkins
>
> JBoss 7.1.3 Logging custom handlers which are used to wrap existing log4j handlers
> into jboss logging handlers calls 
> org.jboss.as.logging.handlers.custom.PropertiesConfigurator 
> which calls org.apache.log4j.BasicConfigurator.configure()
> which by default adds a ConsoleAppender. Maybe should be calling
> org.apache.log4j.BasicConfigurator.configure(new NullAppender()); to initialize log4j.
> Net result is all log4j messages get forwarded to jboss logging add also get sent to the default ConsoleAppender which then writes it out stdout which then jboss catches
> as stdout. So we have 3 custom handlers in our jboss configuration so we get 4 messages
> to the screen. (1 for real category and 3 for each console appender added).
> Not sure if this is reported in correct project.

--
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

From issues at jboss.org  Tue Mar 25 20:01:13 2014
From: issues at jboss.org (John L (JIRA))
Date: Tue, 25 Mar 2014 20:01:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBLOGGING-101) Each custom log handler
 defined in standalone adds a root log4j console appender
In-Reply-To: <JIRA.12536084.1395781813000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12536084.1395781813000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12536084.1395781813000.7691.1395792073739@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JBLOGGING-101?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12956327#comment-12956327 ] 

John L commented on JBLOGGING-101:
----------------------------------

The class with the issue is in:
jboss-as-7.1.3.Final/modules/org/jboss/as/logging/mainjboss-as-logging-7.1.3.Final.jar
So does logmanager replace this version too. Or are you saying upgrade to JBoss 7.2
                
> Each custom log handler defined in standalone adds a root log4j console appender
> --------------------------------------------------------------------------------
>
>                 Key: JBLOGGING-101
>                 URL: https://issues.jboss.org/browse/JBLOGGING-101
>             Project: JBoss Logging
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: jboss-logging-log4j
>            Reporter: John L
>            Assignee: James Perkins
>
> JBoss 7.1.3 Logging custom handlers which are used to wrap existing log4j handlers
> into jboss logging handlers calls 
> org.jboss.as.logging.handlers.custom.PropertiesConfigurator 
> which calls org.apache.log4j.BasicConfigurator.configure()
> which by default adds a ConsoleAppender. Maybe should be calling
> org.apache.log4j.BasicConfigurator.configure(new NullAppender()); to initialize log4j.
> Net result is all log4j messages get forwarded to jboss logging add also get sent to the default ConsoleAppender which then writes it out stdout which then jboss catches
> as stdout. So we have 3 custom handlers in our jboss configuration so we get 4 messages
> to the screen. (1 for real category and 3 for each console appender added).
> Not sure if this is reported in correct project.

--
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

From issues at jboss.org  Tue Mar 25 20:07:13 2014
From: issues at jboss.org (James Perkins (JIRA))
Date: Tue, 25 Mar 2014 20:07:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBLOGGING-101) Each custom log handler
 defined in standalone adds a root log4j console appender
In-Reply-To: <JIRA.12536084.1395781813000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12536084.1395781813000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12536084.1395781813000.7697.1395792433236@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JBLOGGING-101?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12956329#comment-12956329 ] 

James Perkins commented on JBLOGGING-101:
-----------------------------------------

It's been a long time since I looked at that. The code for this has significantly changed. Is this EAP or a custom build of JBoss AS 7.1.3.Final?
                
> Each custom log handler defined in standalone adds a root log4j console appender
> --------------------------------------------------------------------------------
>
>                 Key: JBLOGGING-101
>                 URL: https://issues.jboss.org/browse/JBLOGGING-101
>             Project: JBoss Logging
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: jboss-logging-log4j
>            Reporter: John L
>            Assignee: James Perkins
>
> JBoss 7.1.3 Logging custom handlers which are used to wrap existing log4j handlers
> into jboss logging handlers calls 
> org.jboss.as.logging.handlers.custom.PropertiesConfigurator 
> which calls org.apache.log4j.BasicConfigurator.configure()
> which by default adds a ConsoleAppender. Maybe should be calling
> org.apache.log4j.BasicConfigurator.configure(new NullAppender()); to initialize log4j.
> Net result is all log4j messages get forwarded to jboss logging add also get sent to the default ConsoleAppender which then writes it out stdout which then jboss catches
> as stdout. So we have 3 custom handlers in our jboss configuration so we get 4 messages
> to the screen. (1 for real category and 3 for each console appender added).
> Not sure if this is reported in correct project.

--
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

From issues at jboss.org  Tue Mar 25 20:11:13 2014
From: issues at jboss.org (John L (JIRA))
Date: Tue, 25 Mar 2014 20:11:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBLOGGING-101) Each custom log handler
 defined in standalone adds a root log4j console appender
In-Reply-To: <JIRA.12536084.1395781813000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12536084.1395781813000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12536084.1395781813000.7710.1395792673029@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JBLOGGING-101?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12956332#comment-12956332 ] 

John L commented on JBLOGGING-101:
----------------------------------

It is a custom build of Build JBoss AS 7.1.3.Final (community)
I did look at JBoss 7.2 and saw the code had changed a lot but didn't follow the code yet to be sure
if this issue was fixed. If it is fixed in JBoss 7.2 that is great. Thanks.
                
> Each custom log handler defined in standalone adds a root log4j console appender
> --------------------------------------------------------------------------------
>
>                 Key: JBLOGGING-101
>                 URL: https://issues.jboss.org/browse/JBLOGGING-101
>             Project: JBoss Logging
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: jboss-logging-log4j
>            Reporter: John L
>            Assignee: James Perkins
>
> JBoss 7.1.3 Logging custom handlers which are used to wrap existing log4j handlers
> into jboss logging handlers calls 
> org.jboss.as.logging.handlers.custom.PropertiesConfigurator 
> which calls org.apache.log4j.BasicConfigurator.configure()
> which by default adds a ConsoleAppender. Maybe should be calling
> org.apache.log4j.BasicConfigurator.configure(new NullAppender()); to initialize log4j.
> Net result is all log4j messages get forwarded to jboss logging add also get sent to the default ConsoleAppender which then writes it out stdout which then jboss catches
> as stdout. So we have 3 custom handlers in our jboss configuration so we get 4 messages
> to the screen. (1 for real category and 3 for each console appender added).
> Not sure if this is reported in correct project.

--
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

From issues at jboss.org  Tue Mar 25 20:17:13 2014
From: issues at jboss.org (James Perkins (JIRA))
Date: Tue, 25 Mar 2014 20:17:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBLOGGING-101) Each custom log handler
 defined in standalone adds a root log4j console appender
In-Reply-To: <JIRA.12536084.1395781813000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12536084.1395781813000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12536084.1395781813000.7713.1395793033094@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JBLOGGING-101?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12956333#comment-12956333 ] 

James Perkins commented on JBLOGGING-101:
-----------------------------------------

It's somewhat fixed in 7.2.0.Final and would be better if you override the {{log4j-jboss-logmanager}} dependency. While the 1.0.x version works for the most part, there is some weirdness around using a {{ConsoleAppender}} sometimes. That should be fixed in 1.1.0.Final. Just to note though there is one bug to look out for LOGMGR-95. Not a huge deal, but it's there.

You can build 7.2.0.Final and override the dependency by passing {{-Dversion.org.jboss.logmanager.log4j-jboss-logmanager=1.1.0.Final}} as a build parameter.
                
> Each custom log handler defined in standalone adds a root log4j console appender
> --------------------------------------------------------------------------------
>
>                 Key: JBLOGGING-101
>                 URL: https://issues.jboss.org/browse/JBLOGGING-101
>             Project: JBoss Logging
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: jboss-logging-log4j
>            Reporter: John L
>            Assignee: James Perkins
>
> JBoss 7.1.3 Logging custom handlers which are used to wrap existing log4j handlers
> into jboss logging handlers calls 
> org.jboss.as.logging.handlers.custom.PropertiesConfigurator 
> which calls org.apache.log4j.BasicConfigurator.configure()
> which by default adds a ConsoleAppender. Maybe should be calling
> org.apache.log4j.BasicConfigurator.configure(new NullAppender()); to initialize log4j.
> Net result is all log4j messages get forwarded to jboss logging add also get sent to the default ConsoleAppender which then writes it out stdout which then jboss catches
> as stdout. So we have 3 custom handlers in our jboss configuration so we get 4 messages
> to the screen. (1 for real category and 3 for each console appender added).
> Not sure if this is reported in correct project.

--
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

From issues at jboss.org  Tue Mar 25 20:41:12 2014
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Tue, 25 Mar 2014 20:41:12 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3163) EAP audit log should display
 the EAP version instead of the AS version
In-Reply-To: <JIRA.12532685.1392822921000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12532685.1392822921000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12532685.1392822921000.7736.1395794472916@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-3163?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFLY-3163:
-----------------------------------

    Fix Version/s: 8.0.1.Final

    
> EAP audit log should display the EAP version instead of the AS version
> ----------------------------------------------------------------------
>
>                 Key: WFLY-3163
>                 URL: https://issues.jboss.org/browse/WFLY-3163
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>    Affects Versions: 8.0.0.Final
>            Reporter: Tom Fonteyne
>            Assignee: Brian Stansberry
>             Fix For: 8.0.1.Final
>
>
> EAP audit log should display the EAP version instead of the AS version
> Currently the audit log shows the AS version number instead of the EAP version. Example:
> Feb 13 07:55:43 efjkffglk000000719 syslogappname[553]: 2014-02-13 07:55:43 - {"type" : "core", "r/o" : false, "booting" : false, "version" : "7.3.0.Final-redhat-14", "user" : "$local", "domainUUID" : null, "access" : "NATIVE", "remote-address" : "10.10.10.250/10.10.10.250", "success" : true, "ops" : [{"address" : [{ "host" : "master" },{ "core-service" : "management" },{ "access" : "audit" },{ "logger" : "audit-log" }], "operation" : "write-attribute", "name" : "enabled", "value" : false, "operation-headers" : {"caller-type" : "user", "access-mechanism" : "NATIVE", "domain-uuid" : "fead80e4-690d-4bcf-af71-ecaf30f98381", "push-to-servers" : null}}]}
> "version" : "7.3.0.Final-redhat-14"
> This should show:
> "version" : "6.2.1.GA" 
> There's a request that it show something like "6.2 CP01" but that is a patch file name, not a software version, and is unknown to the software.

--
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

From issues at jboss.org  Wed Mar 26 00:03:12 2014
From: issues at jboss.org (Cristiano da Silva Andrade (JIRA))
Date: Wed, 26 Mar 2014 00:03:12 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3165) Upgrade Undertow to
	1.0.3.Final
In-Reply-To: <JIRA.12536095.1395806492525@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12536095.1395806492525@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12536095.1395806492525.7980.1395806592873@jira02.app.mwc.hst.phx2.redhat.com>

Cristiano da Silva Andrade created WFLY-3165:
------------------------------------------------

             Summary: Upgrade Undertow to 1.0.3.Final 
                 Key: WFLY-3165
                 URL: https://issues.jboss.org/browse/WFLY-3165
             Project: WildFly
          Issue Type: Component  Upgrade
      Security Level: Public (Everyone can see)
          Components: Web (Undertow)
    Affects Versions: 8.0.0.Final
            Reporter: Cristiano da Silva Andrade
            Assignee: Stuart Douglas
             Fix For: 8.0.1.Final


added support HTTPS in reverse proxy

--
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

From issues at jboss.org  Wed Mar 26 00:55:13 2014
From: issues at jboss.org (Stuart Douglas (JIRA))
Date: Wed, 26 Mar 2014 00:55:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3165) Upgrade Undertow to
	1.0.3.Final
In-Reply-To: <JIRA.12536095.1395806492000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12536095.1395806492000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12536095.1395806492000.8011.1395809713020@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-3165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12956362#comment-12956362 ] 

Stuart Douglas commented on WFLY-3165:
--------------------------------------

Unfortunately not, this will be in Undertow 1.1, as it requires XNIO 3.3. 

                
> Upgrade Undertow to 1.0.3.Final 
> --------------------------------
>
>                 Key: WFLY-3165
>                 URL: https://issues.jboss.org/browse/WFLY-3165
>             Project: WildFly
>          Issue Type: Component  Upgrade
>      Security Level: Public(Everyone can see) 
>          Components: Web (Undertow)
>    Affects Versions: 8.0.0.Final
>            Reporter: Cristiano da Silva Andrade
>            Assignee: Stuart Douglas
>             Fix For: 8.0.1.Final
>
>
> added support HTTPS in reverse proxy

--
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

From issues at jboss.org  Wed Mar 26 01:03:12 2014
From: issues at jboss.org (Cristiano da Silva Andrade (JIRA))
Date: Wed, 26 Mar 2014 01:03:12 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3165) Upgrade Undertow to
	1.0.3.Final
In-Reply-To: <JIRA.12536095.1395806492000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12536095.1395806492000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12536095.1395806492000.8018.1395810192907@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-3165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12956364#comment-12956364 ] 

Cristiano da Silva Andrade commented on WFLY-3165:
--------------------------------------------------

So, Wildfly can't be upgraded to 1.0.3.Final ?
                
> Upgrade Undertow to 1.0.3.Final 
> --------------------------------
>
>                 Key: WFLY-3165
>                 URL: https://issues.jboss.org/browse/WFLY-3165
>             Project: WildFly
>          Issue Type: Component  Upgrade
>      Security Level: Public(Everyone can see) 
>          Components: Web (Undertow)
>    Affects Versions: 8.0.0.Final
>            Reporter: Cristiano da Silva Andrade
>            Assignee: Stuart Douglas
>             Fix For: 8.0.1.Final
>
>
> added support HTTPS in reverse proxy

--
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

From issues at jboss.org  Wed Mar 26 01:05:13 2014
From: issues at jboss.org (Stuart Douglas (JIRA))
Date: Wed, 26 Mar 2014 01:05:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3165) Upgrade Undertow to
	1.0.3.Final
In-Reply-To: <JIRA.12536095.1395806492000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12536095.1395806492000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12536095.1395806492000.8020.1395810313335@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-3165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12956365#comment-12956365 ] 

Stuart Douglas commented on WFLY-3165:
--------------------------------------

It can and will be, but the HTTPS client fix is not part of 1.0.3
                
> Upgrade Undertow to 1.0.3.Final 
> --------------------------------
>
>                 Key: WFLY-3165
>                 URL: https://issues.jboss.org/browse/WFLY-3165
>             Project: WildFly
>          Issue Type: Component  Upgrade
>      Security Level: Public(Everyone can see) 
>          Components: Web (Undertow)
>    Affects Versions: 8.0.0.Final
>            Reporter: Cristiano da Silva Andrade
>            Assignee: Stuart Douglas
>             Fix For: 8.0.1.Final
>
>
> added support HTTPS in reverse proxy

--
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

From issues at jboss.org  Wed Mar 26 01:15:15 2014
From: issues at jboss.org (Cristiano da Silva Andrade (JIRA))
Date: Wed, 26 Mar 2014 01:15:15 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3165) Upgrade Undertow to
	1.0.3.Final
In-Reply-To: <JIRA.12536095.1395806492000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12536095.1395806492000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12536095.1395806492000.8028.1395810915329@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-3165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12956366#comment-12956366 ] 

Cristiano da Silva Andrade commented on WFLY-3165:
--------------------------------------------------

1.0.3.Final solves my problem with CLIENT-CERT authentication, when sometimes the SSLInfo is null, this version fixed a bug related to this ? 

I thought it related to UNDERTOW-201, but I didn't see the fix-versions :). Sorry.
                
> Upgrade Undertow to 1.0.3.Final 
> --------------------------------
>
>                 Key: WFLY-3165
>                 URL: https://issues.jboss.org/browse/WFLY-3165
>             Project: WildFly
>          Issue Type: Component  Upgrade
>      Security Level: Public(Everyone can see) 
>          Components: Web (Undertow)
>    Affects Versions: 8.0.0.Final
>            Reporter: Cristiano Andrade
>            Assignee: Stuart Douglas
>             Fix For: 8.0.1.Final
>
>
> added support HTTPS in reverse proxy

--
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

From issues at jboss.org  Wed Mar 26 01:17:13 2014
From: issues at jboss.org (Cristiano da Silva Andrade (JIRA))
Date: Wed, 26 Mar 2014 01:17:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3165) Upgrade Undertow to
	1.0.3.Final
In-Reply-To: <JIRA.12536095.1395806492000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12536095.1395806492000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12536095.1395806492000.8031.1395811033622@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-3165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12956366#comment-12956366 ] 

Cristiano da Silva Andrade edited comment on WFLY-3165 at 3/26/14 1:15 AM:
---------------------------------------------------------------------------

1.0.3.Final solves my problem with CLIENT-CERT authentication, when sometimes the SSLInfo is null, this version fixed a bug related to this ? 

I thought it related to UNDERTOW-201, but I didn't see the fix-version :). Sorry.
                
      was (Author: cristiano.andrade):
    1.0.3.Final solves my problem with CLIENT-CERT authentication, when sometimes the SSLInfo is null, this version fixed a bug related to this ? 

I thought it related to UNDERTOW-201, but I didn't see the fix-versions :). Sorry.
                  
> Upgrade Undertow to 1.0.3.Final 
> --------------------------------
>
>                 Key: WFLY-3165
>                 URL: https://issues.jboss.org/browse/WFLY-3165
>             Project: WildFly
>          Issue Type: Component  Upgrade
>      Security Level: Public(Everyone can see) 
>          Components: Web (Undertow)
>    Affects Versions: 8.0.0.Final
>            Reporter: Cristiano Andrade
>            Assignee: Stuart Douglas
>             Fix For: 8.0.1.Final
>
>
> added support HTTPS in reverse proxy

--
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

From issues at jboss.org  Wed Mar 26 01:23:13 2014
From: issues at jboss.org (Cristiano da Silva Andrade (JIRA))
Date: Wed, 26 Mar 2014 01:23:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3165) Upgrade Undertow to
	1.0.3.Final
In-Reply-To: <JIRA.12536095.1395806492000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12536095.1395806492000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12536095.1395806492000.8036.1395811393606@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-3165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12956366#comment-12956366 ] 

Cristiano da Silva Andrade edited comment on WFLY-3165 at 3/26/14 1:21 AM:
---------------------------------------------------------------------------

1.0.3.Final solves my problem with CLIENT-CERT authentication +  mod_cluster,  when sometimes the SSLInfo is null, this version fixed a bug related to this ? 

I thought it related to UNDERTOW-201, but I didn't see the fix-version :). Sorry.
                
      was (Author: cristiano.andrade):
    1.0.3.Final solves my problem with CLIENT-CERT authentication, when sometimes the SSLInfo is null, this version fixed a bug related to this ? 

I thought it related to UNDERTOW-201, but I didn't see the fix-version :). Sorry.
                  
> Upgrade Undertow to 1.0.3.Final 
> --------------------------------
>
>                 Key: WFLY-3165
>                 URL: https://issues.jboss.org/browse/WFLY-3165
>             Project: WildFly
>          Issue Type: Component  Upgrade
>      Security Level: Public(Everyone can see) 
>          Components: Web (Undertow)
>    Affects Versions: 8.0.0.Final
>            Reporter: Cristiano Andrade
>            Assignee: Stuart Douglas
>             Fix For: 8.0.1.Final
>
>
> added support HTTPS in reverse proxy

--
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

From issues at jboss.org  Wed Mar 26 01:23:13 2014
From: issues at jboss.org (Cristiano da Silva Andrade (JIRA))
Date: Wed, 26 Mar 2014 01:23:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3165) Upgrade Undertow to
	1.0.3.Final
In-Reply-To: <JIRA.12536095.1395806492000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12536095.1395806492000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12536095.1395806492000.8038.1395811393716@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-3165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12956366#comment-12956366 ] 

Cristiano da Silva Andrade edited comment on WFLY-3165 at 3/26/14 1:22 AM:
---------------------------------------------------------------------------

1.0.3.Final solves my problem with CLIENT-CERT authentication +  mod_cluster,  when sometimes in first request the SSLInfo is null, this version fixed a bug related to this ? 

I thought it related to UNDERTOW-201, but I didn't see the fix-version :). Sorry.
                
      was (Author: cristiano.andrade):
    1.0.3.Final solves my problem with CLIENT-CERT authentication +  mod_cluster,  when sometimes the SSLInfo is null, this version fixed a bug related to this ? 

I thought it related to UNDERTOW-201, but I didn't see the fix-version :). Sorry.
                  
> Upgrade Undertow to 1.0.3.Final 
> --------------------------------
>
>                 Key: WFLY-3165
>                 URL: https://issues.jboss.org/browse/WFLY-3165
>             Project: WildFly
>          Issue Type: Component  Upgrade
>      Security Level: Public(Everyone can see) 
>          Components: Web (Undertow)
>    Affects Versions: 8.0.0.Final
>            Reporter: Cristiano Andrade
>            Assignee: Stuart Douglas
>             Fix For: 8.0.1.Final
>
>
> added support HTTPS in reverse proxy

--
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

From issues at jboss.org  Wed Mar 26 02:43:12 2014
From: issues at jboss.org (Rameshbabu Ananthrapu (JIRA))
Date: Wed, 26 Mar 2014 02:43:12 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBFORUMS-304) Locking Issue with Jboss6
In-Reply-To: <JIRA.12535964.1395733802000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12535964.1395733802000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12535964.1395733802000.8063.1395816192886@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JBFORUMS-304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12956373#comment-12956373 ] 

Rameshbabu Ananthrapu commented on JBFORUMS-304:
------------------------------------------------

please respond to this.... any update here...
                
> Locking Issue with Jboss6
> -------------------------
>
>                 Key: JBFORUMS-304
>                 URL: https://issues.jboss.org/browse/JBFORUMS-304
>             Project: JBoss Forums
>          Issue Type: Feature Request
>          Components: Forum Enhancements
>            Reporter: Rameshbabu Ananthrapu
>            Assignee: Luca Stancapiano
>
> Hi,
> Our application is running on jboss6.00 fnal version and database is oracle 11g. After jboss starting we are getting the below exception. Could any one please help me here. I need to be resolve this ASAP as it is existing in production environment.
> We dont have this kind of issue in any test environments.
> 00:17:04,087 WARN  [org.jboss.resource.connectionmanager.TxConnectionManager] Connection error occured: org.jboss.resource.connectionmanager.TxConnectionManager$TxConnectionEventListener at 88e624[state=NORMAL mc=org.jboss.resource.adapter.jdbc.local.LocalManagedConnection at 15950d8 handles=1 lastUse=1395702695471 permit=true trackByTx=true mcp=org.jboss.resource.connectionmanager.JBossManagedConnectionPool$OnePool at ca9ed4 context=org.jboss.resource.connectionmanager.InternalManagedConnectionPool at 8197af xaResource=org.jboss.resource.connectionmanager.TxConnectionManager$LocalXAResource at 1fa249a txSync=null]: java.sql.SQLRecoverableException: I/U-unntak
>         at oracle.jdbc.driver.SQLStateMapping.newSQLException(SQLStateMapping.java:101) [:Oracle JDBC Driver version - "11.1.0.7.0-Production"]
>         at oracle.jdbc.driver.DatabaseError.newSQLException(DatabaseError.java:133) [:Oracle JDBC Driver version - "11.1.0.7.0-Production"]
>         at oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:199) [:Oracle JDBC Driver version - "11.1.0.7.0-Production"]
>         at oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:263) [:Oracle JDBC Driver version - "11.1.0.7.0-Production"]
>         at oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:521) [:Oracle JDBC Driver version - "11.1.0.7.0-Production"]
>         at oracle.jdbc.driver.T4CConnection.doRollback(T4CConnection.java:634) [:Oracle JDBC Driver version - "11.1.0.7.0-Production"]
>         at oracle.jdbc.driver.PhysicalConnection.rollback(PhysicalConnection.java:3470) [:Oracle JDBC Driver version - "11.1.0.7.0-Production"]
>         at org.jboss.resource.adapter.jdbc.local.LocalManagedConnection.rollback(LocalManagedConnection.java:97) [:6.0.0.Final]
>         at org.jboss.resource.connectionmanager.TxConnectionManager$LocalXAResource.rollback(TxConnectionManager.java:1172) [:6.0.0.Final]
>         at com.arjuna.ats.internal.jta.resources.arjunacore.XAOnePhaseResource.rollback(XAOnePhaseResource.java:186) [:6.0.0.Final]
>         at com.arjuna.ats.internal.arjuna.abstractrecords.LastResourceRecord.topLevelAbort(LastResourceRecord.java:123) [:6.0.0.Final]
>         at com.arjuna.ats.arjuna.coordinator.BasicAction.doAbort(BasicAction.java:2902) [:6.0.0.Final]
>         at com.arjuna.ats.arjuna.coordinator.BasicAction.doAbort(BasicAction.java:2881) [:6.0.0.Final]
>         at com.arjuna.ats.arjuna.coordinator.BasicAction.Abort(BasicAction.java:1602) [:6.0.0.Final]
>         at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.cancel(TwoPhaseCoordinator.java:119) [:6.0.0.Final]
>         at com.arjuna.ats.arjuna.AtomicAction.cancel(AtomicAction.java:212) [:6.0.0.Final]
>         at com.arjuna.ats.arjuna.coordinator.TransactionReaper.doCancellations(TransactionReaper.java:367) [:6.0.0.Final]
>         at com.arjuna.ats.internal.arjuna.coordinator.ReaperWorkerThread.run(ReaperWorkerThread.java:79) [:6.0.0.Final]
> Caused by: java.io.InterruptedIOException
>         at java.net.SocketOutputStream.socketWrite0(Native Method) [:1.6.0_35]
>         at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:92) [:1.6.0_35]
>         at java.net.SocketOutputStream.write(SocketOutputStream.java:136) [:1.6.0_35]
>         at oracle.net.ns.DataPacket.send(DataPacket.java:150) [:Oracle JDBC Driver version - "11.1.0.7.0-Production"]
>         at oracle.net.ns.NetOutputStream.flush(NetOutputStream.java:180) [:Oracle JDBC Driver version - "11.1.0.7.0-Production"]
>         at oracle.net.ns.NetInputStream.getNextPacket(NetInputStream.java:169) [:Oracle JDBC Driver version - "11.1.0.7.0-Production"]
>         at oracle.net.ns.NetInputStream.read(NetInputStream.java:117) [:Oracle JDBC Driver version - "11.1.0.7.0-Production"]
>         at oracle.net.ns.NetInputStream.read(NetInputStream.java:92) [:Oracle JDBC Driver version - "11.1.0.7.0-Production"]
>         at oracle.net.ns.NetInputStream.read(NetInputStream.java:77) [:Oracle JDBC Driver version - "11.1.0.7.0-Production"]
>         at oracle.jdbc.driver.T4CMAREngine.unmarshalUB1(T4CMAREngine.java:1034) [:Oracle JDBC Driver version - "11.1.0.7.0-Production"]
>         at oracle.jdbc.driver.T4CMAREngine.unmarshalSB1(T4CMAREngine.java:1010) [:Oracle JDBC Driver version - "11.1.0.7.0-Production"]
>         at oracle.jdbc.driver.T4C7Ocommoncall.receive(T4C7Ocommoncall.java:97) [:Oracle JDBC Driver version - "11.1.0.7.0-Production"]
>         at oracle.jdbc.driver.T4CConnection.doRollback(T4CConnection.java:626) [:Oracle JDBC Driver version - "11.1.0.7.0-Production"]
>         ... 12 more
> 		
> 		
> After getting the above error we are getting the below exception.
> Application running in unix server.		
> 		
> 00:18:04,095 INFO  [org.jboss.resource.connectionmanager.CachedConnectionManager] Closing a connection for you.  Please close them yourself: org.jboss.resource.adapter.jdbc.jdk6.WrappedConnectionJDK6 at c80233
> 00:18:04,096 ERROR [org.jboss.ejb.plugins.LogInterceptor] TransactionRolledbackException in method: public abstract void flow.framework.database.OrderDataMethods.setOrderData(java.lang.String,java.util.Map) throws javax.ejb.ObjectNotFoundException,java.rmi.RemoteException, causedBy:: simpleorm.core.SException$JDBC: ???Preparing [WOLocal 225634]'UPDATE WO_LOCAL SET Overdue_CompleteCount = ?, DueDate = ? WHERE LOCALPK = ? ': java.sql.SQLException: Unable to obtain lock in 60 seconds: org.jboss.resource.adapter.jdbc.local.LocalManagedConnection at 15950d8
>         at simpleorm.core.SRecordInstance.flush(SRecordInstance.java:494) [:]
>         at simpleorm.core.SConnection.flush(SConnection.java:388) [:]
>         at flow.framework.database.impl.OrderDataContext.flush(OrderDataContext.java:144) [:]
>         at flow.framework.database.impl.OrderDataImpl.setOrderDataInternal(OrderDataImpl.java:668) [:]
>         at flow.framework.database.impl.workorder.WorkOrderDataImpl.setOrderDataInternal(WorkOrderDataImpl.java:160) [:]
>         at flow.framework.database.impl.OrderDataImpl.setOrderData(OrderDataImpl.java:206) [:]
>         at flow.framework.database.impl.OrderDataImpl.setOrderData(OrderDataImpl.java:177) [:]
>         at flow.framework.database.impl.workorder.WorkOrderDataImpl.setOrderData(WorkOrderDataImpl.java:144) [:]
>         at sun.reflect.GeneratedMethodAccessor377.invoke(Unknown Source) [:1.6.0_35]
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [:1.6.0_35]
>         at java.lang.reflect.Method.invoke(Method.java:597) [:1.6.0_35]
>         at org.jboss.invocation.Invocation.performCall(Invocation.java:386) [:6.0.0.Final]
>         at org.jboss.ejb.StatelessSessionContainer$ContainerInterceptor.invoke(StatelessSessionContainer.java:233) [:6.0.0.Final]
>         at org.jboss.resource.connectionmanager.CachedConnectionInterceptor.invoke(CachedConnectionInterceptor.java:156) [:6.0.0.Final]
>         at org.jboss.ejb.plugins.StatelessSessionInstanceInterceptor.invoke(StatelessSessionInstanceInterceptor.java:173) [:6.0.0.Final]
>         at org.jboss.ejb.plugins.CallValidationInterceptor.invoke(CallValidationInterceptor.java:63) [:6.0.0.Final]
>         at org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext(AbstractTxInterceptor.java:121) [:6.0.0.Final]
>         at org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterceptorCMT.java:350) [:6.0.0.Final]
>         at org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:181) [:6.0.0.Final]
>         at org.jboss.ejb.plugins.SecurityInterceptor.process(SecurityInterceptor.java:228) [:6.0.0.Final]
>         at org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.java:211) [:6.0.0.Final]
>         at org.jboss.ejb.plugins.security.PreSecurityInterceptor.process(PreSecurityInterceptor.java:97) [:6.0.0.Final]
>         at org.jboss.ejb.plugins.security.PreSecurityInterceptor.invoke(PreSecurityInterceptor.java:81) [:6.0.0.Final]
>         at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:205) [:6.0.0.Final]
>         at org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invoke(ProxyFactoryFinderInterceptor.java:138) [:6.0.0.Final]
>         at org.jboss.ejb.SessionContainer.internalInvoke(SessionContainer.java:650) [:6.0.0.Final]
>         at org.jboss.ejb.Container.invoke(Container.java:1072) [:6.0.0.Final]
>         at sun.reflect.GeneratedMethodAccessor341.invoke(Unknown Source) [:1.6.0_35]
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [:1.6.0_35]
>         at java.lang.reflect.Method.invoke(Method.java:597) [:1.6.0_35]
>         at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:157) [:6.0.0.GA]
>         at org.jboss.mx.server.Invocation.dispatch(Invocation.java:96) [:6.0.0.GA]
>         at org.jboss.mx.server.Invocation.invoke(Invocation.java:88) [:6.0.0.GA]
>         at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:271) [:6.0.0.GA]
>         at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:670) [:6.0.0.GA]
>         at org.jboss.invocation.local.LocalInvoker$MBeanServerAction.invoke(LocalInvoker.java:169) [:6.0.0.Final]
>         at org.jboss.invocation.local.LocalInvoker.invoke(LocalInvoker.java:118) [:6.0.0.Final]
>         at org.jboss.invocation.InvokerInterceptor.invokeLocal(InvokerInterceptor.java:209) [:6.0.0.Final]
>         at org.jboss.invocation.InvokerInterceptor.invoke(InvokerInterceptor.java:195) [:6.0.0.Final]
>         at org.jboss.proxy.TransactionInterceptor.invoke(TransactionInterceptor.java:61) [:6.0.0.Final]
>         at org.jboss.proxy.ejb.SecurityContextInterceptor.invoke(SecurityContextInterceptor.java:64) [:6.0.0.Final]
>         at org.jboss.proxy.SecurityInterceptor.invoke(SecurityInterceptor.java:68) [:6.0.0.Final]
>         at org.jboss.proxy.ejb.StatelessSessionInterceptor.invoke(StatelessSessionInterceptor.java:112) [:6.0.0.Final]
>         at org.jboss.proxy.ClientContainer.invoke(ClientContainer.java:101) [:6.0.0.Final]
>         at $Proxy329.setOrderData(Unknown Source)       at flow.framework.oss.common.impl.UtilityBean.internalSetState(UtilityBean.java:379) [:]
>         at flow.framework.oss.common.impl.UtilityBean.setState(UtilityBean.java:115) [:]
>         at sun.reflect.GeneratedMethodAccessor378.invoke(Unknown Source) [:1.6.0_35]
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [:1.6.0_35]
>         at java.lang.reflect.Method.invoke(Method.java:597) [:1.6.0_35]
>         at org.jboss.invocation.Invocation.performCall(Invocation.java:386) [:6.0.0.Final]
>         at org.jboss.ejb.StatelessSessionContainer$ContainerInterceptor.invoke(StatelessSessionContainer.java:233) [:6.0.0.Final]
>         at org.jboss.resource.connectionmanager.CachedConnectionInterceptor.invoke(CachedConnectionInterceptor.java:156) [:6.0.0.Final]
>         at org.jboss.ejb.plugins.StatelessSessionInstanceInterceptor.invoke(StatelessSessionInstanceInterceptor.java:173) [:6.0.0.Final]
>         at org.jboss.ejb.plugins.CallValidationInterceptor.invoke(CallValidationInterceptor.java:63) [:6.0.0.Final]
>         at org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext(AbstractTxInterceptor.java:121) [:6.0.0.Final]
>         at org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterceptorCMT.java:350) [:6.0.0.Final]
>         at org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:181) [:6.0.0.Final]
>         at org.jboss.ejb.plugins.SecurityInterceptor.process(SecurityInterceptor.java:228) [:6.0.0.Final]
>         at org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.java:211) [:6.0.0.Final]
>         at org.jboss.ejb.plugins.security.PreSecurityInterceptor.process(PreSecurityInterceptor.java:97) [:6.0.0.Final]
>         at org.jboss.ejb.plugins.security.PreSecurityInterceptor.invoke(PreSecurityInterceptor.java:81) [:6.0.0.Final]
>         at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:205) [:6.0.0.Final]
>         at org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invoke(ProxyFactoryFinderInterceptor.java:138) [:6.0.0.Final]
>         at org.jboss.ejb.SessionContainer.internalInvoke(SessionContainer.java:650) [:6.0.0.Final]
>         at org.jboss.ejb.Container.invoke(Container.java:1072) [:6.0.0.Final]
>         at sun.reflect.GeneratedMethodAccessor341.invoke(Unknown Source) [:1.6.0_35]
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [:1.6.0_35]
>         at java.lang.reflect.Method.invoke(Method.java:597) [:1.6.0_35]
>         at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:157) [:6.0.0.GA]
>         at org.jboss.mx.server.Invocation.dispatch(Invocation.java:96) [:6.0.0.GA]
>         at org.jboss.mx.server.Invocation.invoke(Invocation.java:88) [:6.0.0.GA]
>         at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:271) [:6.0.0.GA]
>         at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:670) [:6.0.0.GA]
>         at org.jboss.invocation.local.LocalInvoker$MBeanServerAction.invoke(LocalInvoker.java:169) [:6.0.0.Final]
>         at org.jboss.invocation.local.LocalInvoker.invoke(LocalInvoker.java:118) [:6.0.0.Final]
>         at org.jboss.invocation.InvokerInterceptor.invokeLocal(InvokerInterceptor.java:209) [:6.0.0.Final]
>         at org.jboss.invocation.InvokerInterceptor.invoke(InvokerInterceptor.java:195) [:6.0.0.Final]
>         at org.jboss.proxy.TransactionInterceptor.invoke(TransactionInterceptor.java:61) [:6.0.0.Final]
>         at org.jboss.proxy.ejb.SecurityContextInterceptor.invoke(SecurityContextInterceptor.java:64) [:6.0.0.Final]
>         at org.jboss.proxy.SecurityInterceptor.invoke(SecurityInterceptor.java:68) [:6.0.0.Final]
> 		 at org.jboss.proxy.ejb.StatelessSessionInterceptor.invoke(StatelessSessionInterceptor.java:112) [:6.0.0.Final]
>         at org.jboss.proxy.ClientContainer.invoke(ClientContainer.java:101) [:6.0.0.Final]
>         at $Proxy339.setState(Unknown Source)   at flow.framework.oss.workorder.impl.StateHandler.handleOverdueEvent(StateHandler.java:1523) [:]
>         at flow.framework.oss.workorder.impl.StateHandler.overdueEvent(StateHandler.java:1336) [:]
>         at flow.framework.oss.workorder.impl.WorkOrderTimeoutBean.handleOverdueEvents2(WorkOrderTimeoutBean.java:108) [:]
>         at flow.framework.oss.workorder.impl.WorkOrderTimeoutBean.handleOverdueEvents(WorkOrderTimeoutBean.java:52) [:]
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [:1.6.0_35]
>         at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) [:1.6.0_35]
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [:1.6.0_35]
>         at java.lang.reflect.Method.invoke(Method.java:597) [:1.6.0_35]
>         at org.jboss.invocation.Invocation.performCall(Invocation.java:386) [:6.0.0.Final]
>         at org.jboss.ejb.StatelessSessionContainer$ContainerInterceptor.invoke(StatelessSessionContainer.java:233) [:6.0.0.Final]
>         at org.jboss.resource.connectionmanager.CachedConnectionInterceptor.invoke(CachedConnectionInterceptor.java:156) [:6.0.0.Final]
>         at org.jboss.ejb.plugins.StatelessSessionInstanceInterceptor.invoke(StatelessSessionInstanceInterceptor.java:173) [:6.0.0.Final]
>         at org.jboss.ejb.plugins.CallValidationInterceptor.invoke(CallValidationInterceptor.java:63) [:6.0.0.Final]
>         at org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext(AbstractTxInterceptor.java:121) [:6.0.0.Final]
>         at org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterceptorCMT.java:350) [:6.0.0.Final]
>         at org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:181) [:6.0.0.Final]
>         at org.jboss.ejb.plugins.SecurityInterceptor.process(SecurityInterceptor.java:228) [:6.0.0.Final]
>         at org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.java:211) [:6.0.0.Final]
>         at org.jboss.ejb.plugins.security.PreSecurityInterceptor.process(PreSecurityInterceptor.java:97) [:6.0.0.Final]
>         at org.jboss.ejb.plugins.security.PreSecurityInterceptor.invoke(PreSecurityInterceptor.java:81) [:6.0.0.Final]
>         at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:205) [:6.0.0.Final]
>         at org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invoke(ProxyFactoryFinderInterceptor.java:138) [:6.0.0.Final]
>         at org.jboss.ejb.SessionContainer.internalInvoke(SessionContainer.java:650) [:6.0.0.Final]
>         at org.jboss.ejb.Container.invoke(Container.java:1072) [:6.0.0.Final]
>         at sun.reflect.GeneratedMethodAccessor341.invoke(Unknown Source) [:1.6.0_35]
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [:1.6.0_35]
>         at java.lang.reflect.Method.invoke(Method.java:597) [:1.6.0_35]
>         at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:157) [:6.0.0.GA]
>         at org.jboss.mx.server.Invocation.dispatch(Invocation.java:96) [:6.0.0.GA]
>         at org.jboss.mx.server.Invocation.invoke(Invocation.java:88) [:6.0.0.GA]
>         at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:271) [:6.0.0.GA]
>         at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:670) [:6.0.0.GA]
>         at org.jboss.invocation.unified.server.UnifiedInvoker.invoke(UnifiedInvoker.java:232) [:6.0.0.Final]
>         at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:898) [:6.0.0.Final]
>         at org.jboss.remoting.transport.socket.ServerThread.completeInvocation(ServerThread.java:791) [:6.0.0.Final]
>         at org.jboss.remoting.transport.socket.ServerThread.processInvocation(ServerThread.java:744) [:6.0.0.Final]
>         at org.jboss.remoting.transport.socket.ServerThread.dorun(ServerThread.java:586) [:6.0.0.Final]
>         at org.jboss.remoting.transport.socket.ServerThread.run(ServerThread.java:234) [:6.0.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

From issues at jboss.org  Wed Mar 26 04:49:13 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 26 Mar 2014 04:49:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2610) Add the ability to take an
 external based password to the Vault tool
In-Reply-To: <JIRA.12527043.1386238103000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12527043.1386238103000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12527043.1386238103000.8300.1395823753019@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2610?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12956417#comment-12956417 ] 

RH Bugzilla Integration commented on WFLY-2610:
-----------------------------------------------

Ivo Studensky <istudens at redhat.com> changed the Status of [bug 1080466|https://bugzilla.redhat.com/show_bug.cgi?id=1080466] from ASSIGNED to CLOSED
                
> Add the ability to take an external based password to the Vault tool
> --------------------------------------------------------------------
>
>                 Key: WFLY-2610
>                 URL: https://issues.jboss.org/browse/WFLY-2610
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Scripts, Security
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Ivo Studensky
>            Assignee: Ivo Studensky
>             Fix For: 8.0.0.Final
>
>
> At the moment the Vault tool only supports plain text password as a parameter. With SECURITY-770 committed in it is also possible to configure the Vault to take an external password. Thus the Vault tool needs to support it too.

--
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

From issues at jboss.org  Wed Mar 26 04:51:13 2014
From: issues at jboss.org (hui gao (JIRA))
Date: Wed, 26 Mar 2014 04:51:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3166) can't enable datasource both
 via console or CLI with cluster mode
In-Reply-To: <JIRA.12536115.1395823814886@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12536115.1395823814886@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12536115.1395823814886.8307.1395823873894@jira02.app.mwc.hst.phx2.redhat.com>

hui gao created WFLY-3166:
-----------------------------

             Summary: can't enable datasource both via console or CLI with cluster mode
                 Key: WFLY-3166
                 URL: https://issues.jboss.org/browse/WFLY-3166
             Project: WildFly
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: CLI, Web Console
    Affects Versions: 8.0.0.Final
         Environment: Red Hat Enterprise Linux Server release 5.5
            Reporter: hui gao
            Assignee: Alexey Loubyansky




--
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

From issues at jboss.org  Wed Mar 26 05:03:15 2014
From: issues at jboss.org (hui gao (JIRA))
Date: Wed, 26 Mar 2014 05:03:15 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3166) can't enable datasource both
 via console or CLI with cluster mode
In-Reply-To: <JIRA.12536115.1395823814000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12536115.1395823814000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12536115.1395823814000.8336.1395824595533@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-3166?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

hui gao updated WFLY-3166:
--------------------------

             Description: 
Create a MySQL datasource via CLI:
/profile=front-ha/subsystem=datasources/data-source=testmysql:add(driver-name=com.mysql,jndi-name=java:jboss/datasources/mysql,connection-url=jdbc:mysql://192.168.1.100:3306/udmp,max-pool-size=100,min-pool-size=10,user-name=aaaa,password=bbbb,enabled=false)

And then enable it via console,but lable of enabled didn't to ?.
Check the domain.xml,the value of enabled is still false.

Enable it again whether via CLI or console,error log print:
Response

Internal Server Error
{
    "outcome" => "failed",
    "result" => undefined,
    "failure-description" => "JBAS010839: Operation failed or was rolled back on all servers.",
    "rolled-back" => true,
    "server-groups" => {"front-group1" => {"host" => {"master" => {"fserver1" => {"response" => {
        "outcome" => "failed",
        "failure-description" => "JBAS014749: Operation handler failed: Service jboss.data-source-config.testmysql is already registered",
        "rolled-back" => true
    }}}}}}
}



[Server:fserver1] 16:45:48,888 ERROR [org.jboss.as.controller.management-operation] (host-controller-connection-threads - 10) JBAS014612: Operation ("enable") failed - address: ([
[Server:fserver1]     ("subsystem" => "datasources"),
[Server:fserver1]     ("data-source" => "testmysql")
[Server:fserver1] ]): org.jboss.msc.service.DuplicateServiceException: Service jboss.data-source-config.testmysql is already registered
[Server:fserver1] 	at org.jboss.msc.service.ServiceRegistrationImpl.setInstance(ServiceRegistrationImpl.java:158) [jboss-msc-1.2.0.Final.jar:1.2.0.Final]
[Server:fserver1] 	at org.jboss.msc.service.ServiceControllerImpl.startInstallation(ServiceControllerImpl.java:235) [jboss-msc-1.2.0.Final.jar:1.2.0.Final]
[Server:fserver1] 	at org.jboss.msc.service.ServiceContainerImpl.install(ServiceContainerImpl.java:767) [jboss-msc-1.2.0.Final.jar:1.2.0.Final]
[Server:fserver1] 	at org.jboss.msc.service.ServiceTargetImpl.install(ServiceTargetImpl.java:223) [jboss-msc-1.2.0.Final.jar:1.2.0.Final]
[Server:fserver1] 	at org.jboss.msc.service.ServiceControllerImpl$ChildServiceTarget.install(ServiceControllerImpl.java:2401) [jboss-msc-1.2.0.Final.jar:1.2.0.Final]
[Server:fserver1] 	at org.jboss.msc.service.ServiceBuilderImpl.install(ServiceBuilderImpl.java:317) [jboss-msc-1.2.0.Final.jar:1.2.0.Final]
[Server:fserver1] 	at org.jboss.as.controller.OperationContextImpl$ContextServiceBuilder.install(OperationContextImpl.java:1418) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final]
[Server:fserver1] 	at org.jboss.as.connector.subsystems.datasources.DataSourceEnable.addServices(DataSourceEnable.java:188)
[Server:fserver1] 	at org.jboss.as.connector.subsystems.datasources.DataSourceEnable$1.execute(DataSourceEnable.java:84)
[Server:fserver1] 	at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:591) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final]
[Server:fserver1] 	at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:469) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final]
[Server:fserver1] 	at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:273) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final]
[Server:fserver1] 	at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:268) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final]
[Server:fserver1] 	at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:272) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final]
[Server:fserver1] 	at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:146) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final]
[Server:fserver1] 	at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler.internalExecute(TransactionalProtocolOperationHandler.java:179) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final]
[Server:fserver1] 	at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler.doExecute(TransactionalProtocolOperationHandler.java:149) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final]
[Server:fserver1] 	at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$1.run(TransactionalProtocolOperationHandler.java:113) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final]
[Server:fserver1] 	at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$1.run(TransactionalProtocolOperationHandler.java:109) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final]
[Server:fserver1] 	at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.7.0_25]
[Server:fserver1] 	at javax.security.auth.Subject.doAs(Subject.java:356) [rt.jar:1.7.0_25]
[Server:fserver1] 	at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:83) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final]
[Server:fserver1] 	at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$2$1.run(TransactionalProtocolOperationHandler.java:129) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final]
[Server:fserver1] 	at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$2$1.run(TransactionalProtocolOperationHandler.java:125) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final]
[Server:fserver1] 	at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.7.0_25]
[Server:fserver1] 	at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$2.execute(TransactionalProtocolOperationHandler.java:125) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final]
[Server:fserver1] 	at org.jboss.as.protocol.mgmt.AbstractMessageHandler$2$1.doExecute(AbstractMessageHandler.java:283) [wildfly-protocol-8.0.0.Final.jar:8.0.0.Final]
[Server:fserver1] 	at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:504) [wildfly-protocol-8.0.0.Final.jar:8.0.0.Final]
[Server:fserver1] 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_25]
[Server:fserver1] 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_25]
[Server:fserver1] 	at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25]
[Server:fserver1] 	at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.1.Final.jar:2.1.1.Final]
[Server:fserver1]

    Estimated Difficulty: Medium

    
> can't enable datasource both via console or CLI with cluster mode
> -----------------------------------------------------------------
>
>                 Key: WFLY-3166
>                 URL: https://issues.jboss.org/browse/WFLY-3166
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: CLI, Web Console
>    Affects Versions: 8.0.0.Final
>         Environment: Red Hat Enterprise Linux Server release 5.5
>            Reporter: hui gao
>            Assignee: Alexey Loubyansky
>
> Create a MySQL datasource via CLI:
> /profile=front-ha/subsystem=datasources/data-source=testmysql:add(driver-name=com.mysql,jndi-name=java:jboss/datasources/mysql,connection-url=jdbc:mysql://192.168.1.100:3306/udmp,max-pool-size=100,min-pool-size=10,user-name=aaaa,password=bbbb,enabled=false)
> And then enable it via console,but lable of enabled didn't to ?.
> Check the domain.xml,the value of enabled is still false.
> Enable it again whether via CLI or console,error log print:
> Response
> Internal Server Error
> {
>     "outcome" => "failed",
>     "result" => undefined,
>     "failure-description" => "JBAS010839: Operation failed or was rolled back on all servers.",
>     "rolled-back" => true,
>     "server-groups" => {"front-group1" => {"host" => {"master" => {"fserver1" => {"response" => {
>         "outcome" => "failed",
>         "failure-description" => "JBAS014749: Operation handler failed: Service jboss.data-source-config.testmysql is already registered",
>         "rolled-back" => true
>     }}}}}}
> }
> [Server:fserver1] 16:45:48,888 ERROR [org.jboss.as.controller.management-operation] (host-controller-connection-threads - 10) JBAS014612: Operation ("enable") failed - address: ([
> [Server:fserver1]     ("subsystem" => "datasources"),
> [Server:fserver1]     ("data-source" => "testmysql")
> [Server:fserver1] ]): org.jboss.msc.service.DuplicateServiceException: Service jboss.data-source-config.testmysql is already registered
> [Server:fserver1] 	at org.jboss.msc.service.ServiceRegistrationImpl.setInstance(ServiceRegistrationImpl.java:158) [jboss-msc-1.2.0.Final.jar:1.2.0.Final]
> [Server:fserver1] 	at org.jboss.msc.service.ServiceControllerImpl.startInstallation(ServiceControllerImpl.java:235) [jboss-msc-1.2.0.Final.jar:1.2.0.Final]
> [Server:fserver1] 	at org.jboss.msc.service.ServiceContainerImpl.install(ServiceContainerImpl.java:767) [jboss-msc-1.2.0.Final.jar:1.2.0.Final]
> [Server:fserver1] 	at org.jboss.msc.service.ServiceTargetImpl.install(ServiceTargetImpl.java:223) [jboss-msc-1.2.0.Final.jar:1.2.0.Final]
> [Server:fserver1] 	at org.jboss.msc.service.ServiceControllerImpl$ChildServiceTarget.install(ServiceControllerImpl.java:2401) [jboss-msc-1.2.0.Final.jar:1.2.0.Final]
> [Server:fserver1] 	at org.jboss.msc.service.ServiceBuilderImpl.install(ServiceBuilderImpl.java:317) [jboss-msc-1.2.0.Final.jar:1.2.0.Final]
> [Server:fserver1] 	at org.jboss.as.controller.OperationContextImpl$ContextServiceBuilder.install(OperationContextImpl.java:1418) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final]
> [Server:fserver1] 	at org.jboss.as.connector.subsystems.datasources.DataSourceEnable.addServices(DataSourceEnable.java:188)
> [Server:fserver1] 	at org.jboss.as.connector.subsystems.datasources.DataSourceEnable$1.execute(DataSourceEnable.java:84)
> [Server:fserver1] 	at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:591) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final]
> [Server:fserver1] 	at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:469) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final]
> [Server:fserver1] 	at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:273) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final]
> [Server:fserver1] 	at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:268) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final]
> [Server:fserver1] 	at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:272) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final]
> [Server:fserver1] 	at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:146) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final]
> [Server:fserver1] 	at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler.internalExecute(TransactionalProtocolOperationHandler.java:179) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final]
> [Server:fserver1] 	at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler.doExecute(TransactionalProtocolOperationHandler.java:149) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final]
> [Server:fserver1] 	at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$1.run(TransactionalProtocolOperationHandler.java:113) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final]
> [Server:fserver1] 	at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$1.run(TransactionalProtocolOperationHandler.java:109) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final]
> [Server:fserver1] 	at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.7.0_25]
> [Server:fserver1] 	at javax.security.auth.Subject.doAs(Subject.java:356) [rt.jar:1.7.0_25]
> [Server:fserver1] 	at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:83) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final]
> [Server:fserver1] 	at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$2$1.run(TransactionalProtocolOperationHandler.java:129) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final]
> [Server:fserver1] 	at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$2$1.run(TransactionalProtocolOperationHandler.java:125) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final]
> [Server:fserver1] 	at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.7.0_25]
> [Server:fserver1] 	at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$2.execute(TransactionalProtocolOperationHandler.java:125) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final]
> [Server:fserver1] 	at org.jboss.as.protocol.mgmt.AbstractMessageHandler$2$1.doExecute(AbstractMessageHandler.java:283) [wildfly-protocol-8.0.0.Final.jar:8.0.0.Final]
> [Server:fserver1] 	at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:504) [wildfly-protocol-8.0.0.Final.jar:8.0.0.Final]
> [Server:fserver1] 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_25]
> [Server:fserver1] 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_25]
> [Server:fserver1] 	at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25]
> [Server:fserver1] 	at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.1.Final.jar:2.1.1.Final]
> [Server:fserver1]

--
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


From issues at jboss.org  Wed Mar 26 05:05:13 2014
From: issues at jboss.org (hui gao (JIRA))
Date: Wed, 26 Mar 2014 05:05:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3166) can't enable datasource both
 via console or CLI with cluster mode
In-Reply-To: <JIRA.12536115.1395823814000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12536115.1395823814000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12536115.1395823814000.8340.1395824713414@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-3166?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

hui gao updated WFLY-3166:
--------------------------

    Description: 
Create a MySQL datasource via CLI:
/profile=front-ha/subsystem=datasources/data-source=testmysql:add(driver-name=com.mysql,jndi-name=java:jboss/datasources/mysql,connection-url=jdbc:mysql://192.168.1.100:3306/udmp,max-pool-size=100,min-pool-size=10,user-name=aaaa,password=bbbb,enabled=false)

And then enable it via console,but lable of enabled didn't turn to ?(enabled).
Check the domain.xml,the value of enabled is still false.

Enable it again whether via CLI or console,error log print:
Response

Internal Server Error
{
    "outcome" => "failed",
    "result" => undefined,
    "failure-description" => "JBAS010839: Operation failed or was rolled back on all servers.",
    "rolled-back" => true,
    "server-groups" => {"front-group1" => {"host" => {"master" => {"fserver1" => {"response" => {
        "outcome" => "failed",
        "failure-description" => "JBAS014749: Operation handler failed: Service jboss.data-source-config.testmysql is already registered",
        "rolled-back" => true
    }}}}}}
}



[Server:fserver1] 16:45:48,888 ERROR [org.jboss.as.controller.management-operation] (host-controller-connection-threads - 10) JBAS014612: Operation ("enable") failed - address: ([
[Server:fserver1]     ("subsystem" => "datasources"),
[Server:fserver1]     ("data-source" => "testmysql")
[Server:fserver1] ]): org.jboss.msc.service.DuplicateServiceException: Service jboss.data-source-config.testmysql is already registered
[Server:fserver1] 	at org.jboss.msc.service.ServiceRegistrationImpl.setInstance(ServiceRegistrationImpl.java:158) [jboss-msc-1.2.0.Final.jar:1.2.0.Final]
[Server:fserver1] 	at org.jboss.msc.service.ServiceControllerImpl.startInstallation(ServiceControllerImpl.java:235) [jboss-msc-1.2.0.Final.jar:1.2.0.Final]
[Server:fserver1] 	at org.jboss.msc.service.ServiceContainerImpl.install(ServiceContainerImpl.java:767) [jboss-msc-1.2.0.Final.jar:1.2.0.Final]
[Server:fserver1] 	at org.jboss.msc.service.ServiceTargetImpl.install(ServiceTargetImpl.java:223) [jboss-msc-1.2.0.Final.jar:1.2.0.Final]
[Server:fserver1] 	at org.jboss.msc.service.ServiceControllerImpl$ChildServiceTarget.install(ServiceControllerImpl.java:2401) [jboss-msc-1.2.0.Final.jar:1.2.0.Final]
[Server:fserver1] 	at org.jboss.msc.service.ServiceBuilderImpl.install(ServiceBuilderImpl.java:317) [jboss-msc-1.2.0.Final.jar:1.2.0.Final]
[Server:fserver1] 	at org.jboss.as.controller.OperationContextImpl$ContextServiceBuilder.install(OperationContextImpl.java:1418) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final]
[Server:fserver1] 	at org.jboss.as.connector.subsystems.datasources.DataSourceEnable.addServices(DataSourceEnable.java:188)
[Server:fserver1] 	at org.jboss.as.connector.subsystems.datasources.DataSourceEnable$1.execute(DataSourceEnable.java:84)
[Server:fserver1] 	at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:591) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final]
[Server:fserver1] 	at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:469) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final]
[Server:fserver1] 	at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:273) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final]
[Server:fserver1] 	at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:268) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final]
[Server:fserver1] 	at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:272) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final]
[Server:fserver1] 	at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:146) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final]
[Server:fserver1] 	at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler.internalExecute(TransactionalProtocolOperationHandler.java:179) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final]
[Server:fserver1] 	at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler.doExecute(TransactionalProtocolOperationHandler.java:149) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final]
[Server:fserver1] 	at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$1.run(TransactionalProtocolOperationHandler.java:113) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final]
[Server:fserver1] 	at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$1.run(TransactionalProtocolOperationHandler.java:109) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final]
[Server:fserver1] 	at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.7.0_25]
[Server:fserver1] 	at javax.security.auth.Subject.doAs(Subject.java:356) [rt.jar:1.7.0_25]
[Server:fserver1] 	at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:83) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final]
[Server:fserver1] 	at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$2$1.run(TransactionalProtocolOperationHandler.java:129) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final]
[Server:fserver1] 	at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$2$1.run(TransactionalProtocolOperationHandler.java:125) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final]
[Server:fserver1] 	at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.7.0_25]
[Server:fserver1] 	at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$2.execute(TransactionalProtocolOperationHandler.java:125) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final]
[Server:fserver1] 	at org.jboss.as.protocol.mgmt.AbstractMessageHandler$2$1.doExecute(AbstractMessageHandler.java:283) [wildfly-protocol-8.0.0.Final.jar:8.0.0.Final]
[Server:fserver1] 	at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:504) [wildfly-protocol-8.0.0.Final.jar:8.0.0.Final]
[Server:fserver1] 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_25]
[Server:fserver1] 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_25]
[Server:fserver1] 	at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25]
[Server:fserver1] 	at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.1.Final.jar:2.1.1.Final]
[Server:fserver1]


  was:
Create a MySQL datasource via CLI:
/profile=front-ha/subsystem=datasources/data-source=testmysql:add(driver-name=com.mysql,jndi-name=java:jboss/datasources/mysql,connection-url=jdbc:mysql://192.168.1.100:3306/udmp,max-pool-size=100,min-pool-size=10,user-name=aaaa,password=bbbb,enabled=false)

And then enable it via console,but lable of enabled didn't to ?.
Check the domain.xml,the value of enabled is still false.

Enable it again whether via CLI or console,error log print:
Response

Internal Server Error
{
    "outcome" => "failed",
    "result" => undefined,
    "failure-description" => "JBAS010839: Operation failed or was rolled back on all servers.",
    "rolled-back" => true,
    "server-groups" => {"front-group1" => {"host" => {"master" => {"fserver1" => {"response" => {
        "outcome" => "failed",
        "failure-description" => "JBAS014749: Operation handler failed: Service jboss.data-source-config.testmysql is already registered",
        "rolled-back" => true
    }}}}}}
}



[Server:fserver1] 16:45:48,888 ERROR [org.jboss.as.controller.management-operation] (host-controller-connection-threads - 10) JBAS014612: Operation ("enable") failed - address: ([
[Server:fserver1]     ("subsystem" => "datasources"),
[Server:fserver1]     ("data-source" => "testmysql")
[Server:fserver1] ]): org.jboss.msc.service.DuplicateServiceException: Service jboss.data-source-config.testmysql is already registered
[Server:fserver1] 	at org.jboss.msc.service.ServiceRegistrationImpl.setInstance(ServiceRegistrationImpl.java:158) [jboss-msc-1.2.0.Final.jar:1.2.0.Final]
[Server:fserver1] 	at org.jboss.msc.service.ServiceControllerImpl.startInstallation(ServiceControllerImpl.java:235) [jboss-msc-1.2.0.Final.jar:1.2.0.Final]
[Server:fserver1] 	at org.jboss.msc.service.ServiceContainerImpl.install(ServiceContainerImpl.java:767) [jboss-msc-1.2.0.Final.jar:1.2.0.Final]
[Server:fserver1] 	at org.jboss.msc.service.ServiceTargetImpl.install(ServiceTargetImpl.java:223) [jboss-msc-1.2.0.Final.jar:1.2.0.Final]
[Server:fserver1] 	at org.jboss.msc.service.ServiceControllerImpl$ChildServiceTarget.install(ServiceControllerImpl.java:2401) [jboss-msc-1.2.0.Final.jar:1.2.0.Final]
[Server:fserver1] 	at org.jboss.msc.service.ServiceBuilderImpl.install(ServiceBuilderImpl.java:317) [jboss-msc-1.2.0.Final.jar:1.2.0.Final]
[Server:fserver1] 	at org.jboss.as.controller.OperationContextImpl$ContextServiceBuilder.install(OperationContextImpl.java:1418) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final]
[Server:fserver1] 	at org.jboss.as.connector.subsystems.datasources.DataSourceEnable.addServices(DataSourceEnable.java:188)
[Server:fserver1] 	at org.jboss.as.connector.subsystems.datasources.DataSourceEnable$1.execute(DataSourceEnable.java:84)
[Server:fserver1] 	at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:591) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final]
[Server:fserver1] 	at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:469) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final]
[Server:fserver1] 	at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:273) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final]
[Server:fserver1] 	at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:268) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final]
[Server:fserver1] 	at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:272) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final]
[Server:fserver1] 	at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:146) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final]
[Server:fserver1] 	at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler.internalExecute(TransactionalProtocolOperationHandler.java:179) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final]
[Server:fserver1] 	at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler.doExecute(TransactionalProtocolOperationHandler.java:149) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final]
[Server:fserver1] 	at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$1.run(TransactionalProtocolOperationHandler.java:113) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final]
[Server:fserver1] 	at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$1.run(TransactionalProtocolOperationHandler.java:109) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final]
[Server:fserver1] 	at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.7.0_25]
[Server:fserver1] 	at javax.security.auth.Subject.doAs(Subject.java:356) [rt.jar:1.7.0_25]
[Server:fserver1] 	at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:83) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final]
[Server:fserver1] 	at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$2$1.run(TransactionalProtocolOperationHandler.java:129) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final]
[Server:fserver1] 	at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$2$1.run(TransactionalProtocolOperationHandler.java:125) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final]
[Server:fserver1] 	at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.7.0_25]
[Server:fserver1] 	at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$2.execute(TransactionalProtocolOperationHandler.java:125) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final]
[Server:fserver1] 	at org.jboss.as.protocol.mgmt.AbstractMessageHandler$2$1.doExecute(AbstractMessageHandler.java:283) [wildfly-protocol-8.0.0.Final.jar:8.0.0.Final]
[Server:fserver1] 	at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:504) [wildfly-protocol-8.0.0.Final.jar:8.0.0.Final]
[Server:fserver1] 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_25]
[Server:fserver1] 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_25]
[Server:fserver1] 	at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25]
[Server:fserver1] 	at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.1.Final.jar:2.1.1.Final]
[Server:fserver1]



    
> can't enable datasource both via console or CLI with cluster mode
> -----------------------------------------------------------------
>
>                 Key: WFLY-3166
>                 URL: https://issues.jboss.org/browse/WFLY-3166
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: CLI, Web Console
>    Affects Versions: 8.0.0.Final
>         Environment: Red Hat Enterprise Linux Server release 5.5
>            Reporter: hui gao
>            Assignee: Alexey Loubyansky
>
> Create a MySQL datasource via CLI:
> /profile=front-ha/subsystem=datasources/data-source=testmysql:add(driver-name=com.mysql,jndi-name=java:jboss/datasources/mysql,connection-url=jdbc:mysql://192.168.1.100:3306/udmp,max-pool-size=100,min-pool-size=10,user-name=aaaa,password=bbbb,enabled=false)
> And then enable it via console,but lable of enabled didn't turn to ?(enabled).
> Check the domain.xml,the value of enabled is still false.
> Enable it again whether via CLI or console,error log print:
> Response
> Internal Server Error
> {
>     "outcome" => "failed",
>     "result" => undefined,
>     "failure-description" => "JBAS010839: Operation failed or was rolled back on all servers.",
>     "rolled-back" => true,
>     "server-groups" => {"front-group1" => {"host" => {"master" => {"fserver1" => {"response" => {
>         "outcome" => "failed",
>         "failure-description" => "JBAS014749: Operation handler failed: Service jboss.data-source-config.testmysql is already registered",
>         "rolled-back" => true
>     }}}}}}
> }
> [Server:fserver1] 16:45:48,888 ERROR [org.jboss.as.controller.management-operation] (host-controller-connection-threads - 10) JBAS014612: Operation ("enable") failed - address: ([
> [Server:fserver1]     ("subsystem" => "datasources"),
> [Server:fserver1]     ("data-source" => "testmysql")
> [Server:fserver1] ]): org.jboss.msc.service.DuplicateServiceException: Service jboss.data-source-config.testmysql is already registered
> [Server:fserver1] 	at org.jboss.msc.service.ServiceRegistrationImpl.setInstance(ServiceRegistrationImpl.java:158) [jboss-msc-1.2.0.Final.jar:1.2.0.Final]
> [Server:fserver1] 	at org.jboss.msc.service.ServiceControllerImpl.startInstallation(ServiceControllerImpl.java:235) [jboss-msc-1.2.0.Final.jar:1.2.0.Final]
> [Server:fserver1] 	at org.jboss.msc.service.ServiceContainerImpl.install(ServiceContainerImpl.java:767) [jboss-msc-1.2.0.Final.jar:1.2.0.Final]
> [Server:fserver1] 	at org.jboss.msc.service.ServiceTargetImpl.install(ServiceTargetImpl.java:223) [jboss-msc-1.2.0.Final.jar:1.2.0.Final]
> [Server:fserver1] 	at org.jboss.msc.service.ServiceControllerImpl$ChildServiceTarget.install(ServiceControllerImpl.java:2401) [jboss-msc-1.2.0.Final.jar:1.2.0.Final]
> [Server:fserver1] 	at org.jboss.msc.service.ServiceBuilderImpl.install(ServiceBuilderImpl.java:317) [jboss-msc-1.2.0.Final.jar:1.2.0.Final]
> [Server:fserver1] 	at org.jboss.as.controller.OperationContextImpl$ContextServiceBuilder.install(OperationContextImpl.java:1418) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final]
> [Server:fserver1] 	at org.jboss.as.connector.subsystems.datasources.DataSourceEnable.addServices(DataSourceEnable.java:188)
> [Server:fserver1] 	at org.jboss.as.connector.subsystems.datasources.DataSourceEnable$1.execute(DataSourceEnable.java:84)
> [Server:fserver1] 	at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:591) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final]
> [Server:fserver1] 	at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:469) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final]
> [Server:fserver1] 	at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:273) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final]
> [Server:fserver1] 	at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:268) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final]
> [Server:fserver1] 	at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:272) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final]
> [Server:fserver1] 	at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:146) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final]
> [Server:fserver1] 	at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler.internalExecute(TransactionalProtocolOperationHandler.java:179) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final]
> [Server:fserver1] 	at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler.doExecute(TransactionalProtocolOperationHandler.java:149) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final]
> [Server:fserver1] 	at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$1.run(TransactionalProtocolOperationHandler.java:113) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final]
> [Server:fserver1] 	at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$1.run(TransactionalProtocolOperationHandler.java:109) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final]
> [Server:fserver1] 	at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.7.0_25]
> [Server:fserver1] 	at javax.security.auth.Subject.doAs(Subject.java:356) [rt.jar:1.7.0_25]
> [Server:fserver1] 	at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:83) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final]
> [Server:fserver1] 	at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$2$1.run(TransactionalProtocolOperationHandler.java:129) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final]
> [Server:fserver1] 	at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$2$1.run(TransactionalProtocolOperationHandler.java:125) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final]
> [Server:fserver1] 	at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.7.0_25]
> [Server:fserver1] 	at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$2.execute(TransactionalProtocolOperationHandler.java:125) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final]
> [Server:fserver1] 	at org.jboss.as.protocol.mgmt.AbstractMessageHandler$2$1.doExecute(AbstractMessageHandler.java:283) [wildfly-protocol-8.0.0.Final.jar:8.0.0.Final]
> [Server:fserver1] 	at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:504) [wildfly-protocol-8.0.0.Final.jar:8.0.0.Final]
> [Server:fserver1] 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_25]
> [Server:fserver1] 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_25]
> [Server:fserver1] 	at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25]
> [Server:fserver1] 	at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.1.Final.jar:2.1.1.Final]
> [Server:fserver1]

--
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


From issues at jboss.org  Wed Mar 26 05:07:13 2014
From: issues at jboss.org (hui gao (JIRA))
Date: Wed, 26 Mar 2014 05:07:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3166) can't enable datasource both
 via console or CLI with cluster mode
In-Reply-To: <JIRA.12536115.1395823814000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12536115.1395823814000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12536115.1395823814000.8354.1395824833613@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-3166?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

hui gao updated WFLY-3166:
--------------------------

    Description: 
Create a MySQL datasource via CLI:
/profile=front-ha/subsystem=datasources/data-source=testmysql:add(driver-name=com.mysql,jndi-name=java:jboss/datasources/mysql,connection-url=jdbc:mysql://192.168.1.100:3306/udmp,max-pool-size=100,min-pool-size=10,user-name=aaaa,password=bbbb,enabled=false)

And then enable it via console,but the lable of enabled didn't turn to ?(enabled).
Check the domain.xml,the value of enabled is still false.

Enable it again whether via CLI or console,error log print:
Response

Internal Server Error
{
    "outcome" => "failed",
    "result" => undefined,
    "failure-description" => "JBAS010839: Operation failed or was rolled back on all servers.",
    "rolled-back" => true,
    "server-groups" => {"front-group1" => {"host" => {"master" => {"fserver1" => {"response" => {
        "outcome" => "failed",
        "failure-description" => "JBAS014749: Operation handler failed: Service jboss.data-source-config.testmysql is already registered",
        "rolled-back" => true
    }}}}}}
}



[Server:fserver1] 16:45:48,888 ERROR [org.jboss.as.controller.management-operation] (host-controller-connection-threads - 10) JBAS014612: Operation ("enable") failed - address: ([
[Server:fserver1]     ("subsystem" => "datasources"),
[Server:fserver1]     ("data-source" => "testmysql")
[Server:fserver1] ]): org.jboss.msc.service.DuplicateServiceException: Service jboss.data-source-config.testmysql is already registered
[Server:fserver1] 	at org.jboss.msc.service.ServiceRegistrationImpl.setInstance(ServiceRegistrationImpl.java:158) [jboss-msc-1.2.0.Final.jar:1.2.0.Final]
[Server:fserver1] 	at org.jboss.msc.service.ServiceControllerImpl.startInstallation(ServiceControllerImpl.java:235) [jboss-msc-1.2.0.Final.jar:1.2.0.Final]
[Server:fserver1] 	at org.jboss.msc.service.ServiceContainerImpl.install(ServiceContainerImpl.java:767) [jboss-msc-1.2.0.Final.jar:1.2.0.Final]
[Server:fserver1] 	at org.jboss.msc.service.ServiceTargetImpl.install(ServiceTargetImpl.java:223) [jboss-msc-1.2.0.Final.jar:1.2.0.Final]
[Server:fserver1] 	at org.jboss.msc.service.ServiceControllerImpl$ChildServiceTarget.install(ServiceControllerImpl.java:2401) [jboss-msc-1.2.0.Final.jar:1.2.0.Final]
[Server:fserver1] 	at org.jboss.msc.service.ServiceBuilderImpl.install(ServiceBuilderImpl.java:317) [jboss-msc-1.2.0.Final.jar:1.2.0.Final]
[Server:fserver1] 	at org.jboss.as.controller.OperationContextImpl$ContextServiceBuilder.install(OperationContextImpl.java:1418) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final]
[Server:fserver1] 	at org.jboss.as.connector.subsystems.datasources.DataSourceEnable.addServices(DataSourceEnable.java:188)
[Server:fserver1] 	at org.jboss.as.connector.subsystems.datasources.DataSourceEnable$1.execute(DataSourceEnable.java:84)
[Server:fserver1] 	at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:591) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final]
[Server:fserver1] 	at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:469) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final]
[Server:fserver1] 	at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:273) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final]
[Server:fserver1] 	at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:268) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final]
[Server:fserver1] 	at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:272) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final]
[Server:fserver1] 	at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:146) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final]
[Server:fserver1] 	at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler.internalExecute(TransactionalProtocolOperationHandler.java:179) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final]
[Server:fserver1] 	at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler.doExecute(TransactionalProtocolOperationHandler.java:149) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final]
[Server:fserver1] 	at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$1.run(TransactionalProtocolOperationHandler.java:113) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final]
[Server:fserver1] 	at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$1.run(TransactionalProtocolOperationHandler.java:109) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final]
[Server:fserver1] 	at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.7.0_25]
[Server:fserver1] 	at javax.security.auth.Subject.doAs(Subject.java:356) [rt.jar:1.7.0_25]
[Server:fserver1] 	at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:83) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final]
[Server:fserver1] 	at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$2$1.run(TransactionalProtocolOperationHandler.java:129) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final]
[Server:fserver1] 	at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$2$1.run(TransactionalProtocolOperationHandler.java:125) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final]
[Server:fserver1] 	at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.7.0_25]
[Server:fserver1] 	at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$2.execute(TransactionalProtocolOperationHandler.java:125) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final]
[Server:fserver1] 	at org.jboss.as.protocol.mgmt.AbstractMessageHandler$2$1.doExecute(AbstractMessageHandler.java:283) [wildfly-protocol-8.0.0.Final.jar:8.0.0.Final]
[Server:fserver1] 	at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:504) [wildfly-protocol-8.0.0.Final.jar:8.0.0.Final]
[Server:fserver1] 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_25]
[Server:fserver1] 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_25]
[Server:fserver1] 	at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25]
[Server:fserver1] 	at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.1.Final.jar:2.1.1.Final]
[Server:fserver1]

I tried the standalone mode,it works.


  was:
Create a MySQL datasource via CLI:
/profile=front-ha/subsystem=datasources/data-source=testmysql:add(driver-name=com.mysql,jndi-name=java:jboss/datasources/mysql,connection-url=jdbc:mysql://192.168.1.100:3306/udmp,max-pool-size=100,min-pool-size=10,user-name=aaaa,password=bbbb,enabled=false)

And then enable it via console,but lable of enabled didn't turn to ?(enabled).
Check the domain.xml,the value of enabled is still false.

Enable it again whether via CLI or console,error log print:
Response

Internal Server Error
{
    "outcome" => "failed",
    "result" => undefined,
    "failure-description" => "JBAS010839: Operation failed or was rolled back on all servers.",
    "rolled-back" => true,
    "server-groups" => {"front-group1" => {"host" => {"master" => {"fserver1" => {"response" => {
        "outcome" => "failed",
        "failure-description" => "JBAS014749: Operation handler failed: Service jboss.data-source-config.testmysql is already registered",
        "rolled-back" => true
    }}}}}}
}



[Server:fserver1] 16:45:48,888 ERROR [org.jboss.as.controller.management-operation] (host-controller-connection-threads - 10) JBAS014612: Operation ("enable") failed - address: ([
[Server:fserver1]     ("subsystem" => "datasources"),
[Server:fserver1]     ("data-source" => "testmysql")
[Server:fserver1] ]): org.jboss.msc.service.DuplicateServiceException: Service jboss.data-source-config.testmysql is already registered
[Server:fserver1] 	at org.jboss.msc.service.ServiceRegistrationImpl.setInstance(ServiceRegistrationImpl.java:158) [jboss-msc-1.2.0.Final.jar:1.2.0.Final]
[Server:fserver1] 	at org.jboss.msc.service.ServiceControllerImpl.startInstallation(ServiceControllerImpl.java:235) [jboss-msc-1.2.0.Final.jar:1.2.0.Final]
[Server:fserver1] 	at org.jboss.msc.service.ServiceContainerImpl.install(ServiceContainerImpl.java:767) [jboss-msc-1.2.0.Final.jar:1.2.0.Final]
[Server:fserver1] 	at org.jboss.msc.service.ServiceTargetImpl.install(ServiceTargetImpl.java:223) [jboss-msc-1.2.0.Final.jar:1.2.0.Final]
[Server:fserver1] 	at org.jboss.msc.service.ServiceControllerImpl$ChildServiceTarget.install(ServiceControllerImpl.java:2401) [jboss-msc-1.2.0.Final.jar:1.2.0.Final]
[Server:fserver1] 	at org.jboss.msc.service.ServiceBuilderImpl.install(ServiceBuilderImpl.java:317) [jboss-msc-1.2.0.Final.jar:1.2.0.Final]
[Server:fserver1] 	at org.jboss.as.controller.OperationContextImpl$ContextServiceBuilder.install(OperationContextImpl.java:1418) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final]
[Server:fserver1] 	at org.jboss.as.connector.subsystems.datasources.DataSourceEnable.addServices(DataSourceEnable.java:188)
[Server:fserver1] 	at org.jboss.as.connector.subsystems.datasources.DataSourceEnable$1.execute(DataSourceEnable.java:84)
[Server:fserver1] 	at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:591) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final]
[Server:fserver1] 	at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:469) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final]
[Server:fserver1] 	at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:273) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final]
[Server:fserver1] 	at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:268) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final]
[Server:fserver1] 	at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:272) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final]
[Server:fserver1] 	at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:146) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final]
[Server:fserver1] 	at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler.internalExecute(TransactionalProtocolOperationHandler.java:179) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final]
[Server:fserver1] 	at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler.doExecute(TransactionalProtocolOperationHandler.java:149) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final]
[Server:fserver1] 	at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$1.run(TransactionalProtocolOperationHandler.java:113) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final]
[Server:fserver1] 	at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$1.run(TransactionalProtocolOperationHandler.java:109) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final]
[Server:fserver1] 	at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.7.0_25]
[Server:fserver1] 	at javax.security.auth.Subject.doAs(Subject.java:356) [rt.jar:1.7.0_25]
[Server:fserver1] 	at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:83) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final]
[Server:fserver1] 	at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$2$1.run(TransactionalProtocolOperationHandler.java:129) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final]
[Server:fserver1] 	at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$2$1.run(TransactionalProtocolOperationHandler.java:125) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final]
[Server:fserver1] 	at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.7.0_25]
[Server:fserver1] 	at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$2.execute(TransactionalProtocolOperationHandler.java:125) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final]
[Server:fserver1] 	at org.jboss.as.protocol.mgmt.AbstractMessageHandler$2$1.doExecute(AbstractMessageHandler.java:283) [wildfly-protocol-8.0.0.Final.jar:8.0.0.Final]
[Server:fserver1] 	at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:504) [wildfly-protocol-8.0.0.Final.jar:8.0.0.Final]
[Server:fserver1] 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_25]
[Server:fserver1] 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_25]
[Server:fserver1] 	at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25]
[Server:fserver1] 	at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.1.Final.jar:2.1.1.Final]
[Server:fserver1]



    
> can't enable datasource both via console or CLI with cluster mode
> -----------------------------------------------------------------
>
>                 Key: WFLY-3166
>                 URL: https://issues.jboss.org/browse/WFLY-3166
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: CLI, Web Console
>    Affects Versions: 8.0.0.Final
>         Environment: Red Hat Enterprise Linux Server release 5.5
>            Reporter: hui gao
>            Assignee: Alexey Loubyansky
>
> Create a MySQL datasource via CLI:
> /profile=front-ha/subsystem=datasources/data-source=testmysql:add(driver-name=com.mysql,jndi-name=java:jboss/datasources/mysql,connection-url=jdbc:mysql://192.168.1.100:3306/udmp,max-pool-size=100,min-pool-size=10,user-name=aaaa,password=bbbb,enabled=false)
> And then enable it via console,but the lable of enabled didn't turn to ?(enabled).
> Check the domain.xml,the value of enabled is still false.
> Enable it again whether via CLI or console,error log print:
> Response
> Internal Server Error
> {
>     "outcome" => "failed",
>     "result" => undefined,
>     "failure-description" => "JBAS010839: Operation failed or was rolled back on all servers.",
>     "rolled-back" => true,
>     "server-groups" => {"front-group1" => {"host" => {"master" => {"fserver1" => {"response" => {
>         "outcome" => "failed",
>         "failure-description" => "JBAS014749: Operation handler failed: Service jboss.data-source-config.testmysql is already registered",
>         "rolled-back" => true
>     }}}}}}
> }
> [Server:fserver1] 16:45:48,888 ERROR [org.jboss.as.controller.management-operation] (host-controller-connection-threads - 10) JBAS014612: Operation ("enable") failed - address: ([
> [Server:fserver1]     ("subsystem" => "datasources"),
> [Server:fserver1]     ("data-source" => "testmysql")
> [Server:fserver1] ]): org.jboss.msc.service.DuplicateServiceException: Service jboss.data-source-config.testmysql is already registered
> [Server:fserver1] 	at org.jboss.msc.service.ServiceRegistrationImpl.setInstance(ServiceRegistrationImpl.java:158) [jboss-msc-1.2.0.Final.jar:1.2.0.Final]
> [Server:fserver1] 	at org.jboss.msc.service.ServiceControllerImpl.startInstallation(ServiceControllerImpl.java:235) [jboss-msc-1.2.0.Final.jar:1.2.0.Final]
> [Server:fserver1] 	at org.jboss.msc.service.ServiceContainerImpl.install(ServiceContainerImpl.java:767) [jboss-msc-1.2.0.Final.jar:1.2.0.Final]
> [Server:fserver1] 	at org.jboss.msc.service.ServiceTargetImpl.install(ServiceTargetImpl.java:223) [jboss-msc-1.2.0.Final.jar:1.2.0.Final]
> [Server:fserver1] 	at org.jboss.msc.service.ServiceControllerImpl$ChildServiceTarget.install(ServiceControllerImpl.java:2401) [jboss-msc-1.2.0.Final.jar:1.2.0.Final]
> [Server:fserver1] 	at org.jboss.msc.service.ServiceBuilderImpl.install(ServiceBuilderImpl.java:317) [jboss-msc-1.2.0.Final.jar:1.2.0.Final]
> [Server:fserver1] 	at org.jboss.as.controller.OperationContextImpl$ContextServiceBuilder.install(OperationContextImpl.java:1418) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final]
> [Server:fserver1] 	at org.jboss.as.connector.subsystems.datasources.DataSourceEnable.addServices(DataSourceEnable.java:188)
> [Server:fserver1] 	at org.jboss.as.connector.subsystems.datasources.DataSourceEnable$1.execute(DataSourceEnable.java:84)
> [Server:fserver1] 	at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:591) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final]
> [Server:fserver1] 	at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:469) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final]
> [Server:fserver1] 	at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:273) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final]
> [Server:fserver1] 	at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:268) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final]
> [Server:fserver1] 	at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:272) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final]
> [Server:fserver1] 	at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:146) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final]
> [Server:fserver1] 	at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler.internalExecute(TransactionalProtocolOperationHandler.java:179) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final]
> [Server:fserver1] 	at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler.doExecute(TransactionalProtocolOperationHandler.java:149) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final]
> [Server:fserver1] 	at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$1.run(TransactionalProtocolOperationHandler.java:113) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final]
> [Server:fserver1] 	at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$1.run(TransactionalProtocolOperationHandler.java:109) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final]
> [Server:fserver1] 	at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.7.0_25]
> [Server:fserver1] 	at javax.security.auth.Subject.doAs(Subject.java:356) [rt.jar:1.7.0_25]
> [Server:fserver1] 	at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:83) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final]
> [Server:fserver1] 	at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$2$1.run(TransactionalProtocolOperationHandler.java:129) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final]
> [Server:fserver1] 	at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$2$1.run(TransactionalProtocolOperationHandler.java:125) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final]
> [Server:fserver1] 	at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.7.0_25]
> [Server:fserver1] 	at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$2.execute(TransactionalProtocolOperationHandler.java:125) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final]
> [Server:fserver1] 	at org.jboss.as.protocol.mgmt.AbstractMessageHandler$2$1.doExecute(AbstractMessageHandler.java:283) [wildfly-protocol-8.0.0.Final.jar:8.0.0.Final]
> [Server:fserver1] 	at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:504) [wildfly-protocol-8.0.0.Final.jar:8.0.0.Final]
> [Server:fserver1] 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_25]
> [Server:fserver1] 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_25]
> [Server:fserver1] 	at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25]
> [Server:fserver1] 	at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.1.Final.jar:2.1.1.Final]
> [Server:fserver1]
> I tried the standalone mode,it works.

--
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


From issues at jboss.org  Wed Mar 26 05:09:13 2014
From: issues at jboss.org (hui gao (JIRA))
Date: Wed, 26 Mar 2014 05:09:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3166) can't enable datasource both
 via console or CLI with cluster mode(can't persist to domain.xml)
In-Reply-To: <JIRA.12536115.1395823814000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12536115.1395823814000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12536115.1395823814000.8365.1395824953236@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-3166?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

hui gao updated WFLY-3166:
--------------------------

    Summary: can't enable datasource both via console or CLI with cluster mode(can't persist to domain.xml)  (was: can't enable datasource both via console or CLI with cluster mode)

    
> can't enable datasource both via console or CLI with cluster mode(can't persist to domain.xml)
> ----------------------------------------------------------------------------------------------
>
>                 Key: WFLY-3166
>                 URL: https://issues.jboss.org/browse/WFLY-3166
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: CLI, Web Console
>    Affects Versions: 8.0.0.Final
>         Environment: Red Hat Enterprise Linux Server release 5.5
>            Reporter: hui gao
>            Assignee: Alexey Loubyansky
>
> Create a MySQL datasource via CLI:
> /profile=front-ha/subsystem=datasources/data-source=testmysql:add(driver-name=com.mysql,jndi-name=java:jboss/datasources/mysql,connection-url=jdbc:mysql://192.168.1.100:3306/udmp,max-pool-size=100,min-pool-size=10,user-name=aaaa,password=bbbb,enabled=false)
> And then enable it via console,but the lable of enabled didn't turn to ?(enabled).
> Check the domain.xml,the value of enabled is still false.
> Enable it again whether via CLI or console,error log print:
> Response
> Internal Server Error
> {
>     "outcome" => "failed",
>     "result" => undefined,
>     "failure-description" => "JBAS010839: Operation failed or was rolled back on all servers.",
>     "rolled-back" => true,
>     "server-groups" => {"front-group1" => {"host" => {"master" => {"fserver1" => {"response" => {
>         "outcome" => "failed",
>         "failure-description" => "JBAS014749: Operation handler failed: Service jboss.data-source-config.testmysql is already registered",
>         "rolled-back" => true
>     }}}}}}
> }
> [Server:fserver1] 16:45:48,888 ERROR [org.jboss.as.controller.management-operation] (host-controller-connection-threads - 10) JBAS014612: Operation ("enable") failed - address: ([
> [Server:fserver1]     ("subsystem" => "datasources"),
> [Server:fserver1]     ("data-source" => "testmysql")
> [Server:fserver1] ]): org.jboss.msc.service.DuplicateServiceException: Service jboss.data-source-config.testmysql is already registered
> [Server:fserver1] 	at org.jboss.msc.service.ServiceRegistrationImpl.setInstance(ServiceRegistrationImpl.java:158) [jboss-msc-1.2.0.Final.jar:1.2.0.Final]
> [Server:fserver1] 	at org.jboss.msc.service.ServiceControllerImpl.startInstallation(ServiceControllerImpl.java:235) [jboss-msc-1.2.0.Final.jar:1.2.0.Final]
> [Server:fserver1] 	at org.jboss.msc.service.ServiceContainerImpl.install(ServiceContainerImpl.java:767) [jboss-msc-1.2.0.Final.jar:1.2.0.Final]
> [Server:fserver1] 	at org.jboss.msc.service.ServiceTargetImpl.install(ServiceTargetImpl.java:223) [jboss-msc-1.2.0.Final.jar:1.2.0.Final]
> [Server:fserver1] 	at org.jboss.msc.service.ServiceControllerImpl$ChildServiceTarget.install(ServiceControllerImpl.java:2401) [jboss-msc-1.2.0.Final.jar:1.2.0.Final]
> [Server:fserver1] 	at org.jboss.msc.service.ServiceBuilderImpl.install(ServiceBuilderImpl.java:317) [jboss-msc-1.2.0.Final.jar:1.2.0.Final]
> [Server:fserver1] 	at org.jboss.as.controller.OperationContextImpl$ContextServiceBuilder.install(OperationContextImpl.java:1418) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final]
> [Server:fserver1] 	at org.jboss.as.connector.subsystems.datasources.DataSourceEnable.addServices(DataSourceEnable.java:188)
> [Server:fserver1] 	at org.jboss.as.connector.subsystems.datasources.DataSourceEnable$1.execute(DataSourceEnable.java:84)
> [Server:fserver1] 	at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:591) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final]
> [Server:fserver1] 	at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:469) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final]
> [Server:fserver1] 	at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:273) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final]
> [Server:fserver1] 	at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:268) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final]
> [Server:fserver1] 	at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:272) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final]
> [Server:fserver1] 	at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:146) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final]
> [Server:fserver1] 	at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler.internalExecute(TransactionalProtocolOperationHandler.java:179) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final]
> [Server:fserver1] 	at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler.doExecute(TransactionalProtocolOperationHandler.java:149) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final]
> [Server:fserver1] 	at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$1.run(TransactionalProtocolOperationHandler.java:113) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final]
> [Server:fserver1] 	at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$1.run(TransactionalProtocolOperationHandler.java:109) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final]
> [Server:fserver1] 	at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.7.0_25]
> [Server:fserver1] 	at javax.security.auth.Subject.doAs(Subject.java:356) [rt.jar:1.7.0_25]
> [Server:fserver1] 	at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:83) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final]
> [Server:fserver1] 	at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$2$1.run(TransactionalProtocolOperationHandler.java:129) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final]
> [Server:fserver1] 	at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$2$1.run(TransactionalProtocolOperationHandler.java:125) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final]
> [Server:fserver1] 	at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.7.0_25]
> [Server:fserver1] 	at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$2.execute(TransactionalProtocolOperationHandler.java:125) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final]
> [Server:fserver1] 	at org.jboss.as.protocol.mgmt.AbstractMessageHandler$2$1.doExecute(AbstractMessageHandler.java:283) [wildfly-protocol-8.0.0.Final.jar:8.0.0.Final]
> [Server:fserver1] 	at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:504) [wildfly-protocol-8.0.0.Final.jar:8.0.0.Final]
> [Server:fserver1] 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_25]
> [Server:fserver1] 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_25]
> [Server:fserver1] 	at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25]
> [Server:fserver1] 	at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.1.Final.jar:2.1.1.Final]
> [Server:fserver1]
> I tried the standalone mode,it works.

--
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


From issues at jboss.org  Wed Mar 26 05:11:13 2014
From: issues at jboss.org (hui gao (JIRA))
Date: Wed, 26 Mar 2014 05:11:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3166) can't enable datasource both
 via console or CLI with cluster mode(can't persist to domain.xml)
In-Reply-To: <JIRA.12536115.1395823814000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12536115.1395823814000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12536115.1395823814000.8377.1395825073882@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-3166?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

hui gao updated WFLY-3166:
--------------------------

    Description: 
Create a MySQL datasource via CLI:
/profile=front-ha/subsystem=datasources/data-source=testmysql:add(driver-name=com.mysql,jndi-name=java:jboss/datasources/mysql,connection-url=jdbc:mysql://192.168.1.100:3306/udmp,max-pool-size=100,min-pool-size=10,user-name=aaaa,password=bbbb,enabled=false)

And then enable it via console,but the lable of enabled didn't turn to ?(enabled).
Check the domain.xml,the value of enabled is still false.

Enable it again whether via CLI or console,error log print:
Response

Internal Server Error
{
    "outcome" => "failed",
    "result" => undefined,
    "failure-description" => "JBAS010839: Operation failed or was rolled back on all servers.",
    "rolled-back" => true,
    "server-groups" => {"front-group1" => {"host" => {"master" => {"fserver1" => {"response" => {
        "outcome" => "failed",
        "failure-description" => "JBAS014749: Operation handler failed: Service jboss.data-source-config.testmysql is already registered",
        "rolled-back" => true
    }}}}}}
}



[Server:fserver1] 16:45:48,888 ERROR [org.jboss.as.controller.management-operation] (host-controller-connection-threads - 10) JBAS014612: Operation ("enable") failed - address: ([
[Server:fserver1]     ("subsystem" => "datasources"),
[Server:fserver1]     ("data-source" => "testmysql")
[Server:fserver1] ]): org.jboss.msc.service.DuplicateServiceException: Service jboss.data-source-config.testmysql is already registered
[Server:fserver1] 	at org.jboss.msc.service.ServiceRegistrationImpl.setInstance(ServiceRegistrationImpl.java:158) [jboss-msc-1.2.0.Final.jar:1.2.0.Final]
[Server:fserver1] 	at org.jboss.msc.service.ServiceControllerImpl.startInstallation(ServiceControllerImpl.java:235) [jboss-msc-1.2.0.Final.jar:1.2.0.Final]
[Server:fserver1] 	at org.jboss.msc.service.ServiceContainerImpl.install(ServiceContainerImpl.java:767) [jboss-msc-1.2.0.Final.jar:1.2.0.Final]
[Server:fserver1] 	at org.jboss.msc.service.ServiceTargetImpl.install(ServiceTargetImpl.java:223) [jboss-msc-1.2.0.Final.jar:1.2.0.Final]
[Server:fserver1] 	at org.jboss.msc.service.ServiceControllerImpl$ChildServiceTarget.install(ServiceControllerImpl.java:2401) [jboss-msc-1.2.0.Final.jar:1.2.0.Final]
[Server:fserver1] 	at org.jboss.msc.service.ServiceBuilderImpl.install(ServiceBuilderImpl.java:317) [jboss-msc-1.2.0.Final.jar:1.2.0.Final]
[Server:fserver1] 	at org.jboss.as.controller.OperationContextImpl$ContextServiceBuilder.install(OperationContextImpl.java:1418) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final]
[Server:fserver1] 	at org.jboss.as.connector.subsystems.datasources.DataSourceEnable.addServices(DataSourceEnable.java:188)
[Server:fserver1] 	at org.jboss.as.connector.subsystems.datasources.DataSourceEnable$1.execute(DataSourceEnable.java:84)
[Server:fserver1] 	at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:591) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final]
[Server:fserver1] 	at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:469) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final]
[Server:fserver1] 	at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:273) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final]
[Server:fserver1] 	at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:268) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final]
[Server:fserver1] 	at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:272) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final]
[Server:fserver1] 	at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:146) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final]
[Server:fserver1] 	at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler.internalExecute(TransactionalProtocolOperationHandler.java:179) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final]
[Server:fserver1] 	at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler.doExecute(TransactionalProtocolOperationHandler.java:149) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final]
[Server:fserver1] 	at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$1.run(TransactionalProtocolOperationHandler.java:113) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final]
[Server:fserver1] 	at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$1.run(TransactionalProtocolOperationHandler.java:109) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final]
[Server:fserver1] 	at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.7.0_25]
[Server:fserver1] 	at javax.security.auth.Subject.doAs(Subject.java:356) [rt.jar:1.7.0_25]
[Server:fserver1] 	at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:83) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final]
[Server:fserver1] 	at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$2$1.run(TransactionalProtocolOperationHandler.java:129) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final]
[Server:fserver1] 	at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$2$1.run(TransactionalProtocolOperationHandler.java:125) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final]
[Server:fserver1] 	at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.7.0_25]
[Server:fserver1] 	at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$2.execute(TransactionalProtocolOperationHandler.java:125) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final]
[Server:fserver1] 	at org.jboss.as.protocol.mgmt.AbstractMessageHandler$2$1.doExecute(AbstractMessageHandler.java:283) [wildfly-protocol-8.0.0.Final.jar:8.0.0.Final]
[Server:fserver1] 	at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:504) [wildfly-protocol-8.0.0.Final.jar:8.0.0.Final]
[Server:fserver1] 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_25]
[Server:fserver1] 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_25]
[Server:fserver1] 	at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25]
[Server:fserver1] 	at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.1.Final.jar:2.1.1.Final]
[Server:fserver1]

I tried with the standalone mode,it works.


  was:
Create a MySQL datasource via CLI:
/profile=front-ha/subsystem=datasources/data-source=testmysql:add(driver-name=com.mysql,jndi-name=java:jboss/datasources/mysql,connection-url=jdbc:mysql://192.168.1.100:3306/udmp,max-pool-size=100,min-pool-size=10,user-name=aaaa,password=bbbb,enabled=false)

And then enable it via console,but the lable of enabled didn't turn to ?(enabled).
Check the domain.xml,the value of enabled is still false.

Enable it again whether via CLI or console,error log print:
Response

Internal Server Error
{
    "outcome" => "failed",
    "result" => undefined,
    "failure-description" => "JBAS010839: Operation failed or was rolled back on all servers.",
    "rolled-back" => true,
    "server-groups" => {"front-group1" => {"host" => {"master" => {"fserver1" => {"response" => {
        "outcome" => "failed",
        "failure-description" => "JBAS014749: Operation handler failed: Service jboss.data-source-config.testmysql is already registered",
        "rolled-back" => true
    }}}}}}
}



[Server:fserver1] 16:45:48,888 ERROR [org.jboss.as.controller.management-operation] (host-controller-connection-threads - 10) JBAS014612: Operation ("enable") failed - address: ([
[Server:fserver1]     ("subsystem" => "datasources"),
[Server:fserver1]     ("data-source" => "testmysql")
[Server:fserver1] ]): org.jboss.msc.service.DuplicateServiceException: Service jboss.data-source-config.testmysql is already registered
[Server:fserver1] 	at org.jboss.msc.service.ServiceRegistrationImpl.setInstance(ServiceRegistrationImpl.java:158) [jboss-msc-1.2.0.Final.jar:1.2.0.Final]
[Server:fserver1] 	at org.jboss.msc.service.ServiceControllerImpl.startInstallation(ServiceControllerImpl.java:235) [jboss-msc-1.2.0.Final.jar:1.2.0.Final]
[Server:fserver1] 	at org.jboss.msc.service.ServiceContainerImpl.install(ServiceContainerImpl.java:767) [jboss-msc-1.2.0.Final.jar:1.2.0.Final]
[Server:fserver1] 	at org.jboss.msc.service.ServiceTargetImpl.install(ServiceTargetImpl.java:223) [jboss-msc-1.2.0.Final.jar:1.2.0.Final]
[Server:fserver1] 	at org.jboss.msc.service.ServiceControllerImpl$ChildServiceTarget.install(ServiceControllerImpl.java:2401) [jboss-msc-1.2.0.Final.jar:1.2.0.Final]
[Server:fserver1] 	at org.jboss.msc.service.ServiceBuilderImpl.install(ServiceBuilderImpl.java:317) [jboss-msc-1.2.0.Final.jar:1.2.0.Final]
[Server:fserver1] 	at org.jboss.as.controller.OperationContextImpl$ContextServiceBuilder.install(OperationContextImpl.java:1418) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final]
[Server:fserver1] 	at org.jboss.as.connector.subsystems.datasources.DataSourceEnable.addServices(DataSourceEnable.java:188)
[Server:fserver1] 	at org.jboss.as.connector.subsystems.datasources.DataSourceEnable$1.execute(DataSourceEnable.java:84)
[Server:fserver1] 	at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:591) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final]
[Server:fserver1] 	at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:469) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final]
[Server:fserver1] 	at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:273) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final]
[Server:fserver1] 	at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:268) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final]
[Server:fserver1] 	at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:272) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final]
[Server:fserver1] 	at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:146) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final]
[Server:fserver1] 	at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler.internalExecute(TransactionalProtocolOperationHandler.java:179) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final]
[Server:fserver1] 	at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler.doExecute(TransactionalProtocolOperationHandler.java:149) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final]
[Server:fserver1] 	at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$1.run(TransactionalProtocolOperationHandler.java:113) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final]
[Server:fserver1] 	at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$1.run(TransactionalProtocolOperationHandler.java:109) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final]
[Server:fserver1] 	at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.7.0_25]
[Server:fserver1] 	at javax.security.auth.Subject.doAs(Subject.java:356) [rt.jar:1.7.0_25]
[Server:fserver1] 	at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:83) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final]
[Server:fserver1] 	at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$2$1.run(TransactionalProtocolOperationHandler.java:129) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final]
[Server:fserver1] 	at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$2$1.run(TransactionalProtocolOperationHandler.java:125) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final]
[Server:fserver1] 	at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.7.0_25]
[Server:fserver1] 	at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$2.execute(TransactionalProtocolOperationHandler.java:125) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final]
[Server:fserver1] 	at org.jboss.as.protocol.mgmt.AbstractMessageHandler$2$1.doExecute(AbstractMessageHandler.java:283) [wildfly-protocol-8.0.0.Final.jar:8.0.0.Final]
[Server:fserver1] 	at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:504) [wildfly-protocol-8.0.0.Final.jar:8.0.0.Final]
[Server:fserver1] 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_25]
[Server:fserver1] 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_25]
[Server:fserver1] 	at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25]
[Server:fserver1] 	at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.1.Final.jar:2.1.1.Final]
[Server:fserver1]

I tried the standalone mode,it works.



    
> can't enable datasource both via console or CLI with cluster mode(can't persist to domain.xml)
> ----------------------------------------------------------------------------------------------
>
>                 Key: WFLY-3166
>                 URL: https://issues.jboss.org/browse/WFLY-3166
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: CLI, Web Console
>    Affects Versions: 8.0.0.Final
>         Environment: Red Hat Enterprise Linux Server release 5.5
>            Reporter: hui gao
>            Assignee: Alexey Loubyansky
>
> Create a MySQL datasource via CLI:
> /profile=front-ha/subsystem=datasources/data-source=testmysql:add(driver-name=com.mysql,jndi-name=java:jboss/datasources/mysql,connection-url=jdbc:mysql://192.168.1.100:3306/udmp,max-pool-size=100,min-pool-size=10,user-name=aaaa,password=bbbb,enabled=false)
> And then enable it via console,but the lable of enabled didn't turn to ?(enabled).
> Check the domain.xml,the value of enabled is still false.
> Enable it again whether via CLI or console,error log print:
> Response
> Internal Server Error
> {
>     "outcome" => "failed",
>     "result" => undefined,
>     "failure-description" => "JBAS010839: Operation failed or was rolled back on all servers.",
>     "rolled-back" => true,
>     "server-groups" => {"front-group1" => {"host" => {"master" => {"fserver1" => {"response" => {
>         "outcome" => "failed",
>         "failure-description" => "JBAS014749: Operation handler failed: Service jboss.data-source-config.testmysql is already registered",
>         "rolled-back" => true
>     }}}}}}
> }
> [Server:fserver1] 16:45:48,888 ERROR [org.jboss.as.controller.management-operation] (host-controller-connection-threads - 10) JBAS014612: Operation ("enable") failed - address: ([
> [Server:fserver1]     ("subsystem" => "datasources"),
> [Server:fserver1]     ("data-source" => "testmysql")
> [Server:fserver1] ]): org.jboss.msc.service.DuplicateServiceException: Service jboss.data-source-config.testmysql is already registered
> [Server:fserver1] 	at org.jboss.msc.service.ServiceRegistrationImpl.setInstance(ServiceRegistrationImpl.java:158) [jboss-msc-1.2.0.Final.jar:1.2.0.Final]
> [Server:fserver1] 	at org.jboss.msc.service.ServiceControllerImpl.startInstallation(ServiceControllerImpl.java:235) [jboss-msc-1.2.0.Final.jar:1.2.0.Final]
> [Server:fserver1] 	at org.jboss.msc.service.ServiceContainerImpl.install(ServiceContainerImpl.java:767) [jboss-msc-1.2.0.Final.jar:1.2.0.Final]
> [Server:fserver1] 	at org.jboss.msc.service.ServiceTargetImpl.install(ServiceTargetImpl.java:223) [jboss-msc-1.2.0.Final.jar:1.2.0.Final]
> [Server:fserver1] 	at org.jboss.msc.service.ServiceControllerImpl$ChildServiceTarget.install(ServiceControllerImpl.java:2401) [jboss-msc-1.2.0.Final.jar:1.2.0.Final]
> [Server:fserver1] 	at org.jboss.msc.service.ServiceBuilderImpl.install(ServiceBuilderImpl.java:317) [jboss-msc-1.2.0.Final.jar:1.2.0.Final]
> [Server:fserver1] 	at org.jboss.as.controller.OperationContextImpl$ContextServiceBuilder.install(OperationContextImpl.java:1418) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final]
> [Server:fserver1] 	at org.jboss.as.connector.subsystems.datasources.DataSourceEnable.addServices(DataSourceEnable.java:188)
> [Server:fserver1] 	at org.jboss.as.connector.subsystems.datasources.DataSourceEnable$1.execute(DataSourceEnable.java:84)
> [Server:fserver1] 	at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:591) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final]
> [Server:fserver1] 	at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:469) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final]
> [Server:fserver1] 	at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:273) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final]
> [Server:fserver1] 	at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:268) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final]
> [Server:fserver1] 	at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:272) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final]
> [Server:fserver1] 	at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:146) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final]
> [Server:fserver1] 	at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler.internalExecute(TransactionalProtocolOperationHandler.java:179) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final]
> [Server:fserver1] 	at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler.doExecute(TransactionalProtocolOperationHandler.java:149) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final]
> [Server:fserver1] 	at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$1.run(TransactionalProtocolOperationHandler.java:113) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final]
> [Server:fserver1] 	at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$1.run(TransactionalProtocolOperationHandler.java:109) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final]
> [Server:fserver1] 	at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.7.0_25]
> [Server:fserver1] 	at javax.security.auth.Subject.doAs(Subject.java:356) [rt.jar:1.7.0_25]
> [Server:fserver1] 	at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:83) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final]
> [Server:fserver1] 	at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$2$1.run(TransactionalProtocolOperationHandler.java:129) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final]
> [Server:fserver1] 	at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$2$1.run(TransactionalProtocolOperationHandler.java:125) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final]
> [Server:fserver1] 	at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.7.0_25]
> [Server:fserver1] 	at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$2.execute(TransactionalProtocolOperationHandler.java:125) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final]
> [Server:fserver1] 	at org.jboss.as.protocol.mgmt.AbstractMessageHandler$2$1.doExecute(AbstractMessageHandler.java:283) [wildfly-protocol-8.0.0.Final.jar:8.0.0.Final]
> [Server:fserver1] 	at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:504) [wildfly-protocol-8.0.0.Final.jar:8.0.0.Final]
> [Server:fserver1] 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_25]
> [Server:fserver1] 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_25]
> [Server:fserver1] 	at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25]
> [Server:fserver1] 	at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.1.Final.jar:2.1.1.Final]
> [Server:fserver1]
> I tried with the standalone mode,it works.

--
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


From issues at jboss.org  Wed Mar 26 05:17:14 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 26 Mar 2014 05:17:14 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3159) upgrade Generic JMS RA to
	1.0.3.Final
In-Reply-To: <JIRA.12535982.1395743381000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12535982.1395743381000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12535982.1395743381000.8443.1395825434010@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-3159?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12956431#comment-12956431 ] 

RH Bugzilla Integration commented on WFLY-3159:
-----------------------------------------------

Kabir Khan <kkhan at redhat.com> changed the Status of [bug 1033008|https://bugzilla.redhat.com/show_bug.cgi?id=1033008] from NEW to MODIFIED
                
> upgrade Generic JMS RA to 1.0.3.Final
> -------------------------------------
>
>                 Key: WFLY-3159
>                 URL: https://issues.jboss.org/browse/WFLY-3159
>             Project: WildFly
>          Issue Type: Component  Upgrade
>      Security Level: Public(Everyone can see) 
>          Components: JCA, JMS
>            Reporter: Jeff Mesnil
>            Assignee: Jeff Mesnil
>             Fix For: 8.0.1.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

From issues at jboss.org  Wed Mar 26 06:59:13 2014
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Wed, 26 Mar 2014 06:59:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3167) Allow the SASL protocol to be
 specified for Remoting
In-Reply-To: <JIRA.12536141.1395831547951@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12536141.1395831547951@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12536141.1395831547951.8930.1395831553671@jira02.app.mwc.hst.phx2.redhat.com>

Darran Lofthouse created WFLY-3167:
--------------------------------------

             Summary: Allow the SASL protocol to be specified for Remoting
                 Key: WFLY-3167
                 URL: https://issues.jboss.org/browse/WFLY-3167
             Project: WildFly
          Issue Type: Task
      Security Level: Public (Everyone can see)
          Components: Domain Management, Remoting
            Reporter: Darran Lofthouse
            Assignee: Darran Lofthouse
             Fix For: 9.0.0.CR1


The SASL protocol can now be overridden within Remoting, this is very useful for cases such as GSSAPI where the Kerberos ticket request takes this into account.

There is a slight drawback in that mechanisms like Digest require both sides of the connection to be in synch but the mechanism has also been enhanced to allow a comma separated list of acceptable protocols to be supplied to alleviate this,

--
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

From issues at jboss.org  Wed Mar 26 07:01:13 2014
From: issues at jboss.org (Thorsten Richter (JIRA))
Date: Wed, 26 Mar 2014 07:01:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3168) Wrong Mojarra version on Linux
In-Reply-To: <JIRA.12536142.1395831654298@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12536142.1395831654298@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12536142.1395831654298.8934.1395831673523@jira02.app.mwc.hst.phx2.redhat.com>

Thorsten Richter created WFLY-3168:
--------------------------------------

             Summary: Wrong Mojarra version on Linux
                 Key: WFLY-3168
                 URL: https://issues.jboss.org/browse/WFLY-3168
             Project: WildFly
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: JSF
    Affects Versions: 8.0.0.Final
         Environment: Linux
            Reporter: Thorsten Richter
            Assignee: Farah Juma


We had a bug on Linux that the @ViewScoped annotation didn't work for AJAX requests. We found out, that the Mojarra version is causing the problem. On our Windows development machines everything worked fine, but on the Linux production server @ViewScoped didn't work.
So we searched for the root cause and found out, that the Mojarra version was different on Linux.
The Linux package contains an older version of Mojarra (2.1.7) within the modules/com/sun/jsf-impl folder that needs to be deleted.
The Windows package doesn't even contain a com folder within modules.
So maybe the whole com folder on Linux is wrong?

--
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

From issues at jboss.org  Wed Mar 26 07:05:13 2014
From: issues at jboss.org (Thorsten Richter (JIRA))
Date: Wed, 26 Mar 2014 07:05:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3168) Wrong Mojarra version on Linux
In-Reply-To: <JIRA.12536142.1395831654000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12536142.1395831654000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12536142.1395831654000.8945.1395831913863@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-3168?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Thorsten Richter updated WFLY-3168:
-----------------------------------

    Description: 
We had a bug on Linux that the @ViewScoped annotation didn't work for AJAX requests. We found out, that the Mojarra version is causing the problem. On our Windows development machines everything worked fine, but on the Linux production server @ViewScoped didn't work.
So we searched for the root cause and found out, that the Mojarra version was different on Linux.
The Linux package of Wildfly contains an older version of Mojarra (2.1.7) within the modules/com/sun/jsf-impl folder that needs to be deleted.
The Windows package of Wildfly doesn't even contain a com folder within modules.
So maybe the whole com folder on Linux is wrong?

  was:
We had a bug on Linux that the @ViewScoped annotation didn't work for AJAX requests. We found out, that the Mojarra version is causing the problem. On our Windows development machines everything worked fine, but on the Linux production server @ViewScoped didn't work.
So we searched for the root cause and found out, that the Mojarra version was different on Linux.
The Linux package contains an older version of Mojarra (2.1.7) within the modules/com/sun/jsf-impl folder that needs to be deleted.
The Windows package doesn't even contain a com folder within modules.
So maybe the whole com folder on Linux is wrong?


    
> Wrong Mojarra version on Linux
> ------------------------------
>
>                 Key: WFLY-3168
>                 URL: https://issues.jboss.org/browse/WFLY-3168
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JSF
>    Affects Versions: 8.0.0.Final
>         Environment: Linux
>            Reporter: Thorsten Richter
>            Assignee: Farah Juma
>              Labels: jsf, linux, mojarra, viewscoped
>
> We had a bug on Linux that the @ViewScoped annotation didn't work for AJAX requests. We found out, that the Mojarra version is causing the problem. On our Windows development machines everything worked fine, but on the Linux production server @ViewScoped didn't work.
> So we searched for the root cause and found out, that the Mojarra version was different on Linux.
> The Linux package of Wildfly contains an older version of Mojarra (2.1.7) within the modules/com/sun/jsf-impl folder that needs to be deleted.
> The Windows package of Wildfly doesn't even contain a com folder within modules.
> So maybe the whole com folder on Linux is wrong?

--
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

From issues at jboss.org  Wed Mar 26 07:23:13 2014
From: issues at jboss.org (Jeff Mesnil (JIRA))
Date: Wed, 26 Mar 2014 07:23:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3169) Add JMX notifications for
 management resources
In-Reply-To: <JIRA.12536149.1395832938306@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12536149.1395832938306@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12536149.1395832938306.9009.1395832993658@jira02.app.mwc.hst.phx2.redhat.com>

Jeff Mesnil created WFLY-3169:
---------------------------------

             Summary: Add JMX notifications for management resources
                 Key: WFLY-3169
                 URL: https://issues.jboss.org/browse/WFLY-3169
             Project: WildFly
          Issue Type: Enhancement
      Security Level: Public (Everyone can see)
          Components: JMX
            Reporter: Jeff Mesnil
            Assignee: Kabir Khan


Based on WFLY-266, the JMX subsystem could provide standard JMX notifications for resource registered/unregistered and changes of attributes values.


--
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

From issues at jboss.org  Wed Mar 26 07:23:13 2014
From: issues at jboss.org (Jeff Mesnil (JIRA))
Date: Wed, 26 Mar 2014 07:23:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3169) Add JMX notifications for
 management resources
In-Reply-To: <JIRA.12536149.1395832938000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12536149.1395832938000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12536149.1395832938000.9011.1395832993890@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-3169?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jeff Mesnil reassigned WFLY-3169:
---------------------------------

    Assignee: Jeff Mesnil  (was: Kabir Khan)

    
> Add JMX notifications for management resources
> ----------------------------------------------
>
>                 Key: WFLY-3169
>                 URL: https://issues.jboss.org/browse/WFLY-3169
>             Project: WildFly
>          Issue Type: Enhancement
>      Security Level: Public(Everyone can see) 
>          Components: JMX
>            Reporter: Jeff Mesnil
>            Assignee: Jeff Mesnil
>
> Based on WFLY-266, the JMX subsystem could provide standard JMX notifications for resource registered/unregistered and changes of attributes values.

--
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

From issues at jboss.org  Wed Mar 26 07:59:13 2014
From: issues at jboss.org (Chao Wang (JIRA))
Date: Wed, 26 Mar 2014 07:59:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBWEB-293) NPE if method
 getClassLoader() returns null to represent the bootstrap class loader
In-Reply-To: <JIRA.12534367.1394182683000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534367.1394182683000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534367.1394182683000.9081.1395835153335@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBWEB-293?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Chao Wang resolved JBWEB-293.
-----------------------------

    Resolution: Done

    
> NPE if method getClassLoader() returns null to represent the bootstrap class loader
> -----------------------------------------------------------------------------------
>
>                 Key: JBWEB-293
>                 URL: https://issues.jboss.org/browse/JBWEB-293
>             Project: JBoss Web
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: JBossWeb-2.1.14.GA
>            Reporter: Chao Wang
>            Assignee: Chao Wang
>         Attachments: JBWEB-293.patch
>
>
> from the scenario in [JBPAPP-11027|https://issues.jboss.org/browse/JBPAPP-11027] , and java code in java/javax/el/BeanELResolver.java :
> {code:title=BeanELResolver.java|borderStyle=solid}
>         Iterator<Class<?>> iter = cache.keySet().iterator();
>         while (iter.hasNext()) {
>             Class<?> key = iter.next();
>             BeanProperties bp = cache.get(key);
>             if(bp.getType().getClassLoader().equals(classloader)){
>                 iter.remove();
>             }
>         }
> {code}
> Here, when key is "class java.lang.Class" and bp's type is "class java.lang.Class", method getClassLoader() returns null to represent the bootstrap class loader, then NPE as described is threw during stopping service jboss.web
> {noformat}
> cache content:
> class org.jboss.on.embedded.bean.ResourceListItem=javax.el.BeanELResolver$BeanProperties at 36d4423d, 
> class org.jboss.on.embedded.ui.NavigationAction_$$_javassist_seam_9=javax.el.BeanELResolver$BeanProperties at 2948ceea, 
> class org.jboss.on.embedded.ui.ResourceAction_$$_javassist_seam_12=javax.el.BeanELResolver$BeanProperties at 6b0879d2, 
> class org.jboss.on.embedded.ui.nav.SubCategoryTreeNode=javax.el.BeanELResolver$BeanProperties at 797600e3, 
> class org.jboss.on.embedded.ui.nav.PlatformResourceTreeNode=javax.el.BeanELResolver$BeanProperties at 32347561, 
> class java.lang.Class=javax.el.BeanELResolver$BeanProperties at 12064d07, 
> class org.jboss.on.embedded.ui.nav.SingletonResourceTypeTreeNode=javax.el.BeanELResolver$BeanProperties at 5bab0fcf, 
> class org.jboss.on.embedded.ui.nav.ResourceTreeNode=javax.el.BeanELResolver$BeanProperties at 3b9b0e0d, 
> class org.jboss.on.embedded.ui.nav.NonSingletonResourceTypeTreeNode=javax.el.BeanELResolver$BeanProperties at 40b7960d, 
> class org.rhq.core.domain.measurement.MeasurementDefinition=javax.el.BeanELResolver$BeanProperties at 54dc50ac, 
> class org.rhq.core.domain.resource.Resource=javax.el.BeanELResolver$BeanProperties at 4c3477ba, 
> class org.rhq.core.domain.measurement.MeasurementDataTrait=javax.el.BeanELResolver$BeanProperties at 8a07b6c, 
> class org.jboss.seam.security.Identity=javax.el.BeanELResolver$BeanProperties at 6006f3e0, 
> class org.jboss.on.embedded.bean.MeasurementDisplay=javax.el.BeanELResolver$BeanProperties at 68752860}
> {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

From issues at jboss.org  Wed Mar 26 08:07:13 2014
From: issues at jboss.org (Tom Fonteyne (JIRA))
Date: Wed, 26 Mar 2014 08:07:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3170) system properties are
 trim()'d and loose whitespace
In-Reply-To: <JIRA.12536154.1395835526545@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12536154.1395835526545@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12536154.1395835526545.9111.1395835633147@jira02.app.mwc.hst.phx2.redhat.com>

Tom Fonteyne created WFLY-3170:
----------------------------------

             Summary: system properties are trim()'d and loose whitespace
                 Key: WFLY-3170
                 URL: https://issues.jboss.org/browse/WFLY-3170
             Project: WildFly
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Domain Management
    Affects Versions: 8.0.1.Final
            Reporter: Tom Fonteyne
            Assignee: Brian Stansberry


When a system property was defined as:
  /system-property=foo:add(value="    spaces  ");

it gets written with the correct spaces around it to the configuration file.
When the configuration is read the value gets trimmed and the prefix/suffix of spaces is lost.


--
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

From issues at jboss.org  Wed Mar 26 08:07:13 2014
From: issues at jboss.org (Eduardo Martins (JIRA))
Date: Wed, 26 Mar 2014 08:07:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2881)
 org.jboss.as.ejb3.timer.schedule.CalendarBasedTimeoutTestCase#testCalendarBasedTimeout
In-Reply-To: <JIRA.12531524.1391864503000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12531524.1391864503000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12531524.1391864503000.9113.1395835633243@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2881?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Eduardo Martins resolved WFLY-2881.
-----------------------------------

    Fix Version/s: 8.0.1.Final
       Resolution: Done

    
> org.jboss.as.ejb3.timer.schedule.CalendarBasedTimeoutTestCase#testCalendarBasedTimeout
> --------------------------------------------------------------------------------------
>
>                 Key: WFLY-2881
>                 URL: https://issues.jboss.org/browse/WFLY-2881
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: EJB
>    Affects Versions: 8.0.0.Final
>            Reporter: Frank Langelage
>            Assignee: Eduardo Martins
>             Fix For: 8.0.1.Final
>
>         Attachments: org.jboss.as.ejb3.timer.schedule.CalendarBasedTimeoutTestCase.txt, TEST-org.jboss.as.ejb3.timer.schedule.CalendarBasedTimeoutTestCase.xml
>
>
> Running build with smoke tests on current github sources I get failure in this test case.
> HOUR_OF_DAY is not 0 as expected but 1.
> I changed the Assert in the test case to print out firstTimeout.toString() instead of only timeZoneDisplayName.
> See attached files for more.

--
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

From issues at jboss.org  Wed Mar 26 08:17:13 2014
From: issues at jboss.org (Emmanuel Borlet (JIRA))
Date: Wed, 26 Mar 2014 08:17:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (HIBERNATE-144) somes images have 404 on
	doc site
In-Reply-To: <JIRA.12535975.1395739702000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12535975.1395739702000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12535975.1395739702000.9149.1395836233387@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/HIBERNATE-144?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12956511#comment-12956511 ] 

Emmanuel Borlet commented on HIBERNATE-144:
-------------------------------------------

i have find some using google in the single 

http://docs.jboss.org/hibernate/orm/4.3/devguide/en-US/html_single/chapters/multitenancy/images/

the same trouble for the single page 
http://docs.jboss.org/hibernate/orm/4.2/devguide/en-US/html_single/

                
> somes images have 404 on doc site
> ---------------------------------
>
>                 Key: HIBERNATE-144
>                 URL: https://issues.jboss.org/browse/HIBERNATE-144
>             Project: Hibernate Integration
>          Issue Type: Bug
>            Reporter: Emmanuel Borlet
>            Assignee: Steve Ebersole
>            Priority: Minor
>              Labels: documentation
>
> hello,
> on this pages images have 404 :
> http://docs.jboss.org/hibernate/orm/4.1/devguide/en-US/html/ch16.html
> http://docs.jboss.org/hibernate/orm/4.3/devguide/en-US/html/ch16.html
> Cordialement
> Emmanuel Borlet

--
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

From issues at jboss.org  Wed Mar 26 08:17:13 2014
From: issues at jboss.org (Emmanuel Borlet (JIRA))
Date: Wed, 26 Mar 2014 08:17:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (HIBERNATE-144) somes images have 404 on
	doc site
In-Reply-To: <JIRA.12535975.1395739702000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12535975.1395739702000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12535975.1395739702000.9152.1395836233550@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/HIBERNATE-144?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12956511#comment-12956511 ] 

Emmanuel Borlet edited comment on HIBERNATE-144 at 3/26/14 8:15 AM:
--------------------------------------------------------------------

i have find some using google :

http://docs.jboss.org/hibernate/orm/4.3/devguide/en-US/html_single/chapters/multitenancy/images/

it's the same trouble for the single page :
http://docs.jboss.org/hibernate/orm/4.2/devguide/en-US/html_single/

                
      was (Author: bunam):
    i have find some using google in the single 

http://docs.jboss.org/hibernate/orm/4.3/devguide/en-US/html_single/chapters/multitenancy/images/

the same trouble for the single page 
http://docs.jboss.org/hibernate/orm/4.2/devguide/en-US/html_single/

                  
> somes images have 404 on doc site
> ---------------------------------
>
>                 Key: HIBERNATE-144
>                 URL: https://issues.jboss.org/browse/HIBERNATE-144
>             Project: Hibernate Integration
>          Issue Type: Bug
>            Reporter: Emmanuel Borlet
>            Assignee: Steve Ebersole
>            Priority: Minor
>              Labels: documentation
>
> hello,
> on this pages images have 404 :
> http://docs.jboss.org/hibernate/orm/4.1/devguide/en-US/html/ch16.html
> http://docs.jboss.org/hibernate/orm/4.3/devguide/en-US/html/ch16.html
> Cordialement
> Emmanuel Borlet

--
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

From issues at jboss.org  Wed Mar 26 08:33:13 2014
From: issues at jboss.org (Alexey Loubyansky (JIRA))
Date: Wed, 26 Mar 2014 08:33:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3004) properties are not resolved
 for arguments of commands handled on the client-side
In-Reply-To: <JIRA.12533090.1393247760000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12533090.1393247760000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12533090.1393247760000.9202.1395837193342@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-3004?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Alexey Loubyansky updated WFLY-3004:
------------------------------------

    Git Pull Request: https://github.com/wildfly/wildfly/pull/6019

    
> properties are not resolved for arguments of commands handled on the client-side
> --------------------------------------------------------------------------------
>
>                 Key: WFLY-3004
>                 URL: https://issues.jboss.org/browse/WFLY-3004
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: CLI
>    Affects Versions: 8.0.0.Final
>         Environment: windows 7 and centos 6.4
>            Reporter: Gabriele Garuglieri
>            Assignee: Alexey Loubyansky
>             Fix For: 8.0.1.Final
>
>
> When using cli for batch files using --file and --properties arguments, any property is resolved but for those defined in the connect command line.
> The properties file contains (among the others):
> server.bind.addr = xxxxx
> server.management.port = 9990
> Having:
> connect ${server.bind.addr}
> in the batch file gets
> ERROR [org.jboss.as.cli.CommandContext] Failed to resolve host '${server.bind.addr}': Failed to create URI: Illegal character in authority at index 16: http-remoting://${server.bind.addr}:9990
> Having:
> connect ${server.bind.addr}:${server.management.port}
> gets:
> ERROR [org.jboss.as.cli.CommandContext] The port must be a valid non-negative integer: '${server.bind.addr}:${server.management.
> If i use literal values for the connect command, any other property in the batch is correctly resolved (but that's exactly what i was trying to avoid)

--
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

From issues at jboss.org  Wed Mar 26 08:35:13 2014
From: issues at jboss.org (Alexey Loubyansky (JIRA))
Date: Wed, 26 Mar 2014 08:35:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3004) properties are not resolved
 for arguments of commands handled on the client-side
In-Reply-To: <JIRA.12533090.1393247760000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12533090.1393247760000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12533090.1393247760000.9207.1395837313797@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-3004?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Alexey Loubyansky resolved WFLY-3004.
-------------------------------------

    Resolution: Done


Merged into master.
                
> properties are not resolved for arguments of commands handled on the client-side
> --------------------------------------------------------------------------------
>
>                 Key: WFLY-3004
>                 URL: https://issues.jboss.org/browse/WFLY-3004
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: CLI
>    Affects Versions: 8.0.0.Final
>         Environment: windows 7 and centos 6.4
>            Reporter: Gabriele Garuglieri
>            Assignee: Alexey Loubyansky
>             Fix For: 8.0.1.Final
>
>
> When using cli for batch files using --file and --properties arguments, any property is resolved but for those defined in the connect command line.
> The properties file contains (among the others):
> server.bind.addr = xxxxx
> server.management.port = 9990
> Having:
> connect ${server.bind.addr}
> in the batch file gets
> ERROR [org.jboss.as.cli.CommandContext] Failed to resolve host '${server.bind.addr}': Failed to create URI: Illegal character in authority at index 16: http-remoting://${server.bind.addr}:9990
> Having:
> connect ${server.bind.addr}:${server.management.port}
> gets:
> ERROR [org.jboss.as.cli.CommandContext] The port must be a valid non-negative integer: '${server.bind.addr}:${server.management.
> If i use literal values for the connect command, any other property in the batch is correctly resolved (but that's exactly what i was trying to avoid)

--
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

From issues at jboss.org  Wed Mar 26 08:35:13 2014
From: issues at jboss.org (Alexey Loubyansky (JIRA))
Date: Wed, 26 Mar 2014 08:35:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2857) command/operation
 substitution enclosed with `
In-Reply-To: <JIRA.12531028.1391438664000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12531028.1391438664000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12531028.1391438664000.9211.1395837313997@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2857?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Alexey Loubyansky updated WFLY-2857:
------------------------------------

       Fix Version/s: 8.0.1.Final
    Git Pull Request: https://github.com/wildfly/wildfly/pull/5912

    
> command/operation substitution enclosed with `
> ----------------------------------------------
>
>                 Key: WFLY-2857
>                 URL: https://issues.jboss.org/browse/WFLY-2857
>             Project: WildFly
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: CLI
>            Reporter: Alexey Loubyansky
>            Assignee: Alexey Loubyansky
>             Fix For: 8.0.1.Final
>
>
> Command/operation substitution (following linux style back quoting an expression) would be a useful feature. Among other things, it would be useful to be able to initialize an environment variable to a result of a command or an operation, e.g. 
> set value=`:read-attribute(name=release-version)`
> or
> set value=$(:read-attribute(name=release-version))
> and
> echo $value
> 8.0.0.Final-SNAPSHOT

--
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

From issues at jboss.org  Wed Mar 26 08:35:14 2014
From: issues at jboss.org (Alexey Loubyansky (JIRA))
Date: Wed, 26 Mar 2014 08:35:14 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2857) command/operation
 substitution enclosed with `
In-Reply-To: <JIRA.12531028.1391438664000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12531028.1391438664000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12531028.1391438664000.9215.1395837314214@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2857?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Alexey Loubyansky resolved WFLY-2857.
-------------------------------------

    Resolution: Done


Merged into master.
                
> command/operation substitution enclosed with `
> ----------------------------------------------
>
>                 Key: WFLY-2857
>                 URL: https://issues.jboss.org/browse/WFLY-2857
>             Project: WildFly
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: CLI
>            Reporter: Alexey Loubyansky
>            Assignee: Alexey Loubyansky
>             Fix For: 8.0.1.Final
>
>
> Command/operation substitution (following linux style back quoting an expression) would be a useful feature. Among other things, it would be useful to be able to initialize an environment variable to a result of a command or an operation, e.g. 
> set value=`:read-attribute(name=release-version)`
> or
> set value=$(:read-attribute(name=release-version))
> and
> echo $value
> 8.0.0.Final-SNAPSHOT

--
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

From issues at jboss.org  Wed Mar 26 08:37:13 2014
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Wed, 26 Mar 2014 08:37:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3170) system properties are
 trim()'d and loose whitespace
In-Reply-To: <JIRA.12536154.1395835526000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12536154.1395835526000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12536154.1395835526000.9227.1395837433444@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-3170?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12956525#comment-12956525 ] 

Brian Stansberry commented on WFLY-3170:
----------------------------------------

AIUI you are suggesting using different logic for ModelType.PROPERTY?

That won't work; very few attributes are of type PROPERTY. I'm quite sure a system property resource's value attribute is type STRING.

I'm opposed to changing the AttributeDefinition.parse method, at least for EAP 6.3.x. That will effect nearly every attribute in the system and could produce undesired changes in behavior.
                
> system properties are trim()'d and loose whitespace
> ---------------------------------------------------
>
>                 Key: WFLY-3170
>                 URL: https://issues.jboss.org/browse/WFLY-3170
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>    Affects Versions: 8.0.1.Final
>            Reporter: Tom Fonteyne
>            Assignee: Brian Stansberry
>
> When a system property was defined as:
>   /system-property=foo:add(value="    spaces  ");
> it gets written with the correct spaces around it to the configuration file.
> When the configuration is read the value gets trimmed and the prefix/suffix of spaces is lost.

--
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

From issues at jboss.org  Wed Mar 26 08:51:14 2014
From: issues at jboss.org (Ivo Studensky (JIRA))
Date: Wed, 26 Mar 2014 08:51:14 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBLOGGING-102) Messages#getBundle()
 needs to be privileged
In-Reply-To: <JIRA.12536158.1395838258038@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12536158.1395838258038@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12536158.1395838258038.9288.1395838274899@jira02.app.mwc.hst.phx2.redhat.com>

Ivo Studensky created JBLOGGING-102:
---------------------------------------

             Summary: Messages#getBundle() needs to be privileged
                 Key: JBLOGGING-102
                 URL: https://issues.jboss.org/browse/JBLOGGING-102
             Project: JBoss Logging
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions: 3.2.0.Beta1, 3.1.4.GA
            Reporter: Ivo Studensky
            Assignee: James Perkins
             Fix For: 3.1.5.GA, 3.2.0.Beta2


It ({{org.jboss.logging.Messages#getBundle(Class<T> type, Locale locale)}}) calls {{type.getClassLoader()}} which requires privileges when running with Security Manager.

--
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

From issues at jboss.org  Wed Mar 26 08:57:12 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 26 Mar 2014 08:57:12 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBLOGGING-102) Messages#getBundle()
 needs to be privileged
In-Reply-To: <JIRA.12536158.1395838258000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12536158.1395838258000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12536158.1395838258000.9322.1395838632990@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBLOGGING-102?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated JBLOGGING-102:
----------------------------------------------

        Bugzilla Update: Perform
    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1080991

    
> Messages#getBundle() needs to be privileged
> -------------------------------------------
>
>                 Key: JBLOGGING-102
>                 URL: https://issues.jboss.org/browse/JBLOGGING-102
>             Project: JBoss Logging
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 3.1.4.GA, 3.2.0.Beta1
>            Reporter: Ivo Studensky
>            Assignee: James Perkins
>             Fix For: 3.1.5.GA, 3.2.0.Beta2
>
>
> It ({{org.jboss.logging.Messages#getBundle(Class<T> type, Locale locale)}}) calls {{type.getClassLoader()}} which requires privileges when running with Security Manager.

--
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

From issues at jboss.org  Wed Mar 26 08:59:14 2014
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Wed, 26 Mar 2014 08:59:14 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3164) Create customized Audit Logger
In-Reply-To: <JIRA.12536089.1395789072000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12536089.1395789072000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12536089.1395789072000.9327.1395838754879@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-3164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12956535#comment-12956535 ] 

Brian Stansberry commented on WFLY-3164:
----------------------------------------

Can I assign this to you? I think you have a better grasp of the topic. :)

This sounds like a good approach. I expect we are going to have to create static variant of this that does some basic mappings of a few fields to traditional log record elements, but as you say having the SPI etc needed for this custom formatter approach will make doing that static one simpler; it will just be a less configurable thing that calls into the same logic.
                
> Create customized Audit Logger
> ------------------------------
>
>                 Key: WFLY-3164
>                 URL: https://issues.jboss.org/browse/WFLY-3164
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>            Reporter: Kabir Khan
>            Assignee: Brian Stansberry
>              Labels: EAP
>             Fix For: 9.0.0.CR1
>
>
> Some users want to have a single line audit log formatter. I think it would be better to have the ability to add your own formatter from a module, something along the lines of:
> {code}
> <custom-formatter code="org.blah.MyCustomFormatter" module="org.blah/mymodule">
>    <property name="layout">...</property>
>    <property name="propB">...</property>
> </custom-formatter>
> {code}
> We'd need an SPI, and a slight reworking of the audit log internals. In any case doing this will put us in a better position to provide the single line logger if this proposal is not acceptable to our users.

--
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

From issues at jboss.org  Wed Mar 26 09:21:13 2014
From: issues at jboss.org (Tom Fonteyne (JIRA))
Date: Wed, 26 Mar 2014 09:21:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3170) system properties are
 trim()'d and loose whitespace
In-Reply-To: <JIRA.12536154.1395835526000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12536154.1395835526000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12536154.1395835526000.9450.1395840073850@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-3170?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12956550#comment-12956550 ] 

Tom Fonteyne commented on WFLY-3170:
------------------------------------

it would be for STRING as it looks.

But I agree that while the change is trivial, it would have system-wide (potential) repercussions.

                
> system properties are trim()'d and loose whitespace
> ---------------------------------------------------
>
>                 Key: WFLY-3170
>                 URL: https://issues.jboss.org/browse/WFLY-3170
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>    Affects Versions: 8.0.1.Final
>            Reporter: Tom Fonteyne
>            Assignee: Brian Stansberry
>
> When a system property was defined as:
>   /system-property=foo:add(value="    spaces  ");
> it gets written with the correct spaces around it to the configuration file.
> When the configuration is read the value gets trimmed and the prefix/suffix of spaces is lost.

--
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

From issues at jboss.org  Wed Mar 26 09:29:13 2014
From: issues at jboss.org (Paul Ferraro (JIRA))
Date: Wed, 26 Mar 2014 09:29:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3171) Increase default state
	transfer timeout
In-Reply-To: <JIRA.12536164.1395840490442@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12536164.1395840490442@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12536164.1395840490442.9509.1395840553940@jira02.app.mwc.hst.phx2.redhat.com>

Paul Ferraro created WFLY-3171:
----------------------------------

             Summary: Increase default state transfer timeout
                 Key: WFLY-3171
                 URL: https://issues.jboss.org/browse/WFLY-3171
             Project: WildFly
          Issue Type: Enhancement
      Security Level: Public (Everyone can see)
          Components: Clustering
    Affects Versions: 8.0.0.Final
            Reporter: Paul Ferraro
            Assignee: Paul Ferraro


The current state transfer timeout is 1 minute.  Now that Infinispan uses non-blocking state transfer, we should bump this to 4 minutes, in line with Infinispan's defaults.

Don't forget to include transformers for old model versions.

--
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

From issues at jboss.org  Wed Mar 26 09:47:15 2014
From: issues at jboss.org (Radoslav Husar (JIRA))
Date: Wed, 26 Mar 2014 09:47:15 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3003) Dropping unicast message to
 wrong destination warn after cluster node rejoin
In-Reply-To: <JIRA.12533083.1393242652000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12533083.1393242652000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12533083.1393242652000.9698.1395841635437@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-3003?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Radoslav Husar updated WFLY-3003:
---------------------------------

        Fix Version/s: 8.0.1.Final
             Priority: Critical  (was: Major)
    Affects Version/s: 8.0.0.Final


I am seeing this quite often, just after restarting one of the cluster nodes. Seems to log until entire cluster is restarted.
                
> Dropping unicast message to wrong destination warn after cluster node rejoin
> ----------------------------------------------------------------------------
>
>                 Key: WFLY-3003
>                 URL: https://issues.jboss.org/browse/WFLY-3003
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Clustering
>    Affects Versions: 8.0.0.Final
>            Reporter: Eduardo Martins
>            Assignee: Richard Achmatowicz
>            Priority: Critical
>             Fix For: 8.0.1.Final
>
>
> There is a never ending warn log message printed after a cluster node rejoins, after a shutdown:
> 03:43:15,831 WARN  [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/server: dropping unicast message to wrong destination a1fdbb88-a500-483d-7405-70c93a8ab740
> 03:43:15,831 WARN  [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/ejb: dropping unicast message to wrong destination f567dfca-cdad-2555-0e3b-22c8ebded75b
> 03:43:15,887 INFO  [org.jboss.as.server] (Controller Boot Thread) JBAS018559: Deployed "wildfly-cluster-ha-singleton-service.jar" (runtime-name : "wildfly-cluster-ha-singleton-service.jar")
> 03:43:15,895 INFO  [org.jboss.as] (Controller Boot Thread) JBAS015961: Http management interface listening on http://127.0.0.1:10090/management
> 03:43:15,895 INFO  [org.jboss.as] (Controller Boot Thread) JBAS015951: Admin console listening on http://127.0.0.1:10090
> 03:43:15,896 INFO  [org.jboss.as] (Controller Boot Thread) JBAS015874: WildFly 8.0.1.Final-SNAPSHOT "WildFly" started in 4855ms - Started 345 of 437 services (171 services are lazy, passive or on-demand)
> 03:43:16,332 WARN  [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/server: dropping unicast message to wrong destination a1fdbb88-a500-483d-7405-70c93a8ab740
> 03:43:16,332 WARN  [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/ejb: dropping unicast message to wrong destination f567dfca-cdad-2555-0e3b-22c8ebded75b
> 03:43:16,833 WARN  [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/server: dropping unicast message to wrong destination a1fdbb88-a500-483d-7405-70c93a8ab740
> 03:43:16,834 WARN  [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/ejb: dropping unicast message to wrong destination f567dfca-cdad-2555-0e3b-22c8ebded75b
> 03:43:17,335 WARN  [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/server: dropping unicast message to wrong destination a1fdbb88-a500-483d-7405-70c93a8ab740
> 03:43:17,336 WARN  [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/ejb: dropping unicast message to wrong destination f567dfca-cdad-2555-0e3b-22c8ebded75b
> 03:43:17,835 WARN  [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/server: dropping unicast message to wrong destination a1fdbb88-a500-483d-7405-70c93a8ab740
> 03:43:17,836 WARN  [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/ejb: dropping unicast message to wrong destination f567dfca-cdad-2555-0e3b-22c8ebded75b
> 03:43:18,335 WARN  [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/server: dropping unicast message to wrong destination a1fdbb88-a500-483d-7405-70c93a8ab740
> 03:43:18,336 WARN  [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/ejb: dropping unicast message to wrong destination f567dfca-cdad-2555-0e3b-22c8ebded75b
> 03:43:18,837 WARN  [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/server: dropping unicast message to wrong destination a1fdbb88-a500-483d-7405-70c93a8ab740
> 03:43:18,838 WARN  [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/ejb: dropping unicast message to wrong destination f567dfca-cdad-2555-0e3b-22c8ebded75b
> 03:43:19,339 WARN  [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/server: dropping unicast message to wrong destination a1fdbb88-a500-483d-7405-70c93a8ab740
> 03:43:19,340 WARN  [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/ejb: dropping unicast message to wrong destination f567dfca-cdad-2555-0e3b-22c8ebded75b
> 03:43:19,840 WARN  [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/server: dropping unicast message to wrong destination a1fdbb88-a500-483d-7405-70c93a8ab740
> 03:43:19,840 WARN  [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/ejb: dropping unicast message to wrong destination f567dfca-cdad-2555-0e3b-22c8ebded75b
> 03:43:20,003 INFO  [org.jboss.as.quickstarts.cluster.hasingleton.service.ejb.SchedulerBean] (EJB default - 1) HASingletonTimer: Info=HASingleton timer @nodeTwo Sat Feb 22 03:43:15 WET 2014
> 03:43:20,003 INFO  [org.jboss.as.quickstarts.cluster.hasingleton.service.ejb.SchedulerBean] (EJB default - 2) HASingletonTimer: Info=HASingleton timer @nodeTwo Sat Feb 22 03:43:15 WET 2014
> 03:43:20,341 WARN  [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/server: dropping unicast message to wrong destination a1fdbb88-a500-483d-7405-70c93a8ab740
> 03:43:20,342 WARN  [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/ejb: dropping unicast message to wrong destination f567dfca-cdad-2555-0e3b-22c8ebded75b
> 03:43:20,841 WARN  [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/server: dropping unicast message to wrong destination a1fdbb88-a500-483d-7405-70c93a8ab740
> 03:43:20,842 WARN  [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/ejb: dropping unicast message to wrong destination f567dfca-cdad-2555-0e3b-22c8ebded75b
> 03:43:21,342 WARN  [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/server: dropping unicast message to wrong destination a1fdbb88-a500-483d-7405-70c93a8ab740
> 03:43:21,342 WARN  [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/ejb: dropping unicast message to wrong destination f567dfca-cdad-2555-0e3b-22c8ebded75b
> 03:43:21,842 WARN  [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/server: dropping unicast message to wrong destination a1fdbb88-a500-483d-7405-70c93a8ab740
> 03:43:21,843 WARN  [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/ejb: dropping unicast message to wrong destination f567dfca-cdad-2555-0e3b-22c8ebded75b
> 03:43:22,343 WARN  [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/server: dropping unicast message to wrong destination a1fdbb88-a500-483d-7405-70c93a8ab740
> 03:43:22,344 WARN  [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/ejb: dropping unicast message to wrong destination f567dfca-cdad-2555-0e3b-22c8ebded75b
> 03:43:22,845 WARN  [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/server: dropping unicast message to wrong destination a1fdbb88-a500-483d-7405-70c93a8ab740
> 03:43:22,845 WARN  [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/ejb: dropping unicast message to wrong destination f567dfca-cdad-2555-0e3b-22c8ebded75b
> 03:43:23,345 WARN  [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/server: dropping unicast message to wrong destination a1fdbb88-a500-483d-7405-70c93a8ab740
> 03:43:23,346 WARN  [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/ejb: dropping unicast message to wrong destination f567dfca-cdad-2555-0e3b-22c8ebded75b
> 03:43:23,846 WARN  [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/server: dropping unicast message to wrong destination a1fdbb88-a500-483d-7405-70c93a8ab740
> 03:43:23,846 WARN  [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/ejb: dropping unicast message to wrong destination f567dfca-cdad-2555-0e3b-22c8ebded75b
> This can be seen using WildFly's cluster-ha-singleton quickstart (github project wildfly/quickstart). Just follow quickstart?s readme till point 4 of "Check the timer" section, and after stop node2 (not node1) start it gain.

--
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


From issues at jboss.org  Wed Mar 26 09:57:13 2014
From: issues at jboss.org (Radoslav Husar (JIRA))
Date: Wed, 26 Mar 2014 09:57:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3003) Dropping unicast message to
 wrong destination warn after cluster node rejoin
In-Reply-To: <JIRA.12533083.1393242652000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12533083.1393242652000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12533083.1393242652000.9864.1395842233913@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-3003?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12956573#comment-12956573 ] 

Radoslav Husar edited comment on WFLY-3003 at 3/26/14 9:55 AM:
---------------------------------------------------------------

I am seeing this quite often, here is some basic information to should narrow this down very much:

* Happens just after restarting one of the cluster nodes. 
* Error is gone when the entire cluster is restarted instead.
* The logging is happening on the node being restarted.
* Cleaning up /data, /tmp,  /log does not help.
* Every restart adds one more line of logging. 
* After some timeout, when the node is rejoining, the warnings are gone.

14:51:13,596 WARN  [org.jgroups.protocols.UDP] (Timer-4,shared=udp) JGRP000032: null: no physical address for x220/ejb, dropping message
14:51:13,630 WARN  [org.jgroups.protocols.UNICAST3] (OOB-20,shared=udp) JGRP000040: rhusar2/web: sender x220/web not found in retransmission table

                
      was (Author: rhusar):
    I am seeing this quite often, just after restarting one of the cluster nodes. Seems to log until entire cluster is restarted.
                  
> Dropping unicast message to wrong destination warn after cluster node rejoin
> ----------------------------------------------------------------------------
>
>                 Key: WFLY-3003
>                 URL: https://issues.jboss.org/browse/WFLY-3003
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Clustering
>    Affects Versions: 8.0.0.Final
>            Reporter: Eduardo Martins
>            Assignee: Richard Achmatowicz
>            Priority: Critical
>             Fix For: 8.0.1.Final
>
>
> There is a never ending warn log message printed after a cluster node rejoins, after a shutdown:
> 03:43:15,831 WARN  [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/server: dropping unicast message to wrong destination a1fdbb88-a500-483d-7405-70c93a8ab740
> 03:43:15,831 WARN  [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/ejb: dropping unicast message to wrong destination f567dfca-cdad-2555-0e3b-22c8ebded75b
> 03:43:15,887 INFO  [org.jboss.as.server] (Controller Boot Thread) JBAS018559: Deployed "wildfly-cluster-ha-singleton-service.jar" (runtime-name : "wildfly-cluster-ha-singleton-service.jar")
> 03:43:15,895 INFO  [org.jboss.as] (Controller Boot Thread) JBAS015961: Http management interface listening on http://127.0.0.1:10090/management
> 03:43:15,895 INFO  [org.jboss.as] (Controller Boot Thread) JBAS015951: Admin console listening on http://127.0.0.1:10090
> 03:43:15,896 INFO  [org.jboss.as] (Controller Boot Thread) JBAS015874: WildFly 8.0.1.Final-SNAPSHOT "WildFly" started in 4855ms - Started 345 of 437 services (171 services are lazy, passive or on-demand)
> 03:43:16,332 WARN  [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/server: dropping unicast message to wrong destination a1fdbb88-a500-483d-7405-70c93a8ab740
> 03:43:16,332 WARN  [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/ejb: dropping unicast message to wrong destination f567dfca-cdad-2555-0e3b-22c8ebded75b
> 03:43:16,833 WARN  [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/server: dropping unicast message to wrong destination a1fdbb88-a500-483d-7405-70c93a8ab740
> 03:43:16,834 WARN  [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/ejb: dropping unicast message to wrong destination f567dfca-cdad-2555-0e3b-22c8ebded75b
> 03:43:17,335 WARN  [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/server: dropping unicast message to wrong destination a1fdbb88-a500-483d-7405-70c93a8ab740
> 03:43:17,336 WARN  [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/ejb: dropping unicast message to wrong destination f567dfca-cdad-2555-0e3b-22c8ebded75b
> 03:43:17,835 WARN  [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/server: dropping unicast message to wrong destination a1fdbb88-a500-483d-7405-70c93a8ab740
> 03:43:17,836 WARN  [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/ejb: dropping unicast message to wrong destination f567dfca-cdad-2555-0e3b-22c8ebded75b
> 03:43:18,335 WARN  [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/server: dropping unicast message to wrong destination a1fdbb88-a500-483d-7405-70c93a8ab740
> 03:43:18,336 WARN  [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/ejb: dropping unicast message to wrong destination f567dfca-cdad-2555-0e3b-22c8ebded75b
> 03:43:18,837 WARN  [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/server: dropping unicast message to wrong destination a1fdbb88-a500-483d-7405-70c93a8ab740
> 03:43:18,838 WARN  [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/ejb: dropping unicast message to wrong destination f567dfca-cdad-2555-0e3b-22c8ebded75b
> 03:43:19,339 WARN  [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/server: dropping unicast message to wrong destination a1fdbb88-a500-483d-7405-70c93a8ab740
> 03:43:19,340 WARN  [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/ejb: dropping unicast message to wrong destination f567dfca-cdad-2555-0e3b-22c8ebded75b
> 03:43:19,840 WARN  [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/server: dropping unicast message to wrong destination a1fdbb88-a500-483d-7405-70c93a8ab740
> 03:43:19,840 WARN  [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/ejb: dropping unicast message to wrong destination f567dfca-cdad-2555-0e3b-22c8ebded75b
> 03:43:20,003 INFO  [org.jboss.as.quickstarts.cluster.hasingleton.service.ejb.SchedulerBean] (EJB default - 1) HASingletonTimer: Info=HASingleton timer @nodeTwo Sat Feb 22 03:43:15 WET 2014
> 03:43:20,003 INFO  [org.jboss.as.quickstarts.cluster.hasingleton.service.ejb.SchedulerBean] (EJB default - 2) HASingletonTimer: Info=HASingleton timer @nodeTwo Sat Feb 22 03:43:15 WET 2014
> 03:43:20,341 WARN  [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/server: dropping unicast message to wrong destination a1fdbb88-a500-483d-7405-70c93a8ab740
> 03:43:20,342 WARN  [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/ejb: dropping unicast message to wrong destination f567dfca-cdad-2555-0e3b-22c8ebded75b
> 03:43:20,841 WARN  [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/server: dropping unicast message to wrong destination a1fdbb88-a500-483d-7405-70c93a8ab740
> 03:43:20,842 WARN  [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/ejb: dropping unicast message to wrong destination f567dfca-cdad-2555-0e3b-22c8ebded75b
> 03:43:21,342 WARN  [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/server: dropping unicast message to wrong destination a1fdbb88-a500-483d-7405-70c93a8ab740
> 03:43:21,342 WARN  [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/ejb: dropping unicast message to wrong destination f567dfca-cdad-2555-0e3b-22c8ebded75b
> 03:43:21,842 WARN  [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/server: dropping unicast message to wrong destination a1fdbb88-a500-483d-7405-70c93a8ab740
> 03:43:21,843 WARN  [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/ejb: dropping unicast message to wrong destination f567dfca-cdad-2555-0e3b-22c8ebded75b
> 03:43:22,343 WARN  [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/server: dropping unicast message to wrong destination a1fdbb88-a500-483d-7405-70c93a8ab740
> 03:43:22,344 WARN  [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/ejb: dropping unicast message to wrong destination f567dfca-cdad-2555-0e3b-22c8ebded75b
> 03:43:22,845 WARN  [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/server: dropping unicast message to wrong destination a1fdbb88-a500-483d-7405-70c93a8ab740
> 03:43:22,845 WARN  [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/ejb: dropping unicast message to wrong destination f567dfca-cdad-2555-0e3b-22c8ebded75b
> 03:43:23,345 WARN  [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/server: dropping unicast message to wrong destination a1fdbb88-a500-483d-7405-70c93a8ab740
> 03:43:23,346 WARN  [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/ejb: dropping unicast message to wrong destination f567dfca-cdad-2555-0e3b-22c8ebded75b
> 03:43:23,846 WARN  [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/server: dropping unicast message to wrong destination a1fdbb88-a500-483d-7405-70c93a8ab740
> 03:43:23,846 WARN  [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/ejb: dropping unicast message to wrong destination f567dfca-cdad-2555-0e3b-22c8ebded75b
> This can be seen using WildFly's cluster-ha-singleton quickstart (github project wildfly/quickstart). Just follow quickstart?s readme till point 4 of "Check the timer" section, and after stop node2 (not node1) start it gain.

--
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


From issues at jboss.org  Wed Mar 26 10:03:13 2014
From: issues at jboss.org (Radoslav Husar (JIRA))
Date: Wed, 26 Mar 2014 10:03:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3171) Increase default state
	transfer timeout
In-Reply-To: <JIRA.12536164.1395840490000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12536164.1395840490000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12536164.1395840490000.9931.1395842593453@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-3171?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Radoslav Husar reassigned WFLY-3171:
------------------------------------

    Assignee: Radoslav Husar  (was: Paul Ferraro)

    
> Increase default state transfer timeout
> ---------------------------------------
>
>                 Key: WFLY-3171
>                 URL: https://issues.jboss.org/browse/WFLY-3171
>             Project: WildFly
>          Issue Type: Enhancement
>      Security Level: Public(Everyone can see) 
>          Components: Clustering
>    Affects Versions: 8.0.0.Final
>            Reporter: Paul Ferraro
>            Assignee: Radoslav Husar
>
> The current state transfer timeout is 1 minute.  Now that Infinispan uses non-blocking state transfer, we should bump this to 4 minutes, in line with Infinispan's defaults.
> Don't forget to include transformers for old model versions.

--
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

From issues at jboss.org  Wed Mar 26 10:09:13 2014
From: issues at jboss.org (Richard Achmatowicz (JIRA))
Date: Wed, 26 Mar 2014 10:09:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1801) DuplicateTest fails when
 testing OOB multicast to all three senders
In-Reply-To: <JIRA.12533765.1393853856000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12533765.1393853856000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12533765.1393853856000.9987.1395842953203@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JGRP-1801?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12956592#comment-12956592 ] 

Richard Achmatowicz commented on JGRP-1801:
-------------------------------------------

Even if I adjust the timeout to wait for 60 seconds, I still get failures. 
I added in code to print a dot (.) after each second of waiting. In passing tests, I see this:
{noformat}
------------- testOOBMulticastToAll3Senders -----------
Checking for messages from all senders:
.
[C1]: C1: [1, 2, 3, 4, 5, 6, 7, 8, 9, 10]
[C1]: C2: [9, 2, 1, 10, 3, 5, 6, 7, 4, 8]
[C1]: c3: [1, 10, 2, 3, 5, 4, 8, 9, 7, 6]
Checking for messages from all senders:

[C2]: C1: [1, 2, 10, 3, 4, 6, 8, 9, 5, 7]
[C2]: C2: [3, 1, 2, 4, 5, 6, 7, 8, 9, 10]
[C2]: c3: [2, 5, 6, 1, 10, 3, 7, 8, 9, 4]
Checking for messages from all senders:

[C3]: C1: [1, 2, 10, 3, 4, 5, 6, 7, 8, 9]
[C3]: C2: [1, 10, 2, 3, 4, 5, 6, 7, 8, 9]
[C3]: c3: [1, 8, 2, 3, 4, 5, 9, 10, 7, 6]
{noformat}

but in the faiiing tests, I see this:
{nofomat}
------------- testOOBMulticastToAll3Senders -----------
Checking for messages from all senders:

[C1]: C1: [1, 2, 3, 4, 5, 6, 7, 8, 9, 10]
[C1]: C2: [1, 6, 5, 2, 3, 4, 10, 7, 8, 9]
[C1]: c3: [1, 10, 2, 3, 4, 6, 7, 8, 9, 5]
Checking for messages from all senders:

[C2]: C1: [1, 2, 3, 10, 4, 5, 7, 8, 9, 6]
[C2]: C2: [1, 2, 3, 4, 5, 6, 7, 8, 9, 10]
[C2]: c3: [1, 5, 2, 3, 4, 10, 6, 7, 8, 9]
Checking for messages from all senders:
............................................................
{noformat}

In other words, even with a timeout of 60 seconds, on channel C3, messages are not being received from one of the three channels.

                
> DuplicateTest fails when testing OOB multicast to all three senders
> -------------------------------------------------------------------
>
>                 Key: JGRP-1801
>                 URL: https://issues.jboss.org/browse/JGRP-1801
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.2.13
>         Environment: Windows (18), Solaris (2), RHEL(1) where (x) is the number of failures seen
>            Reporter: Richard Achmatowicz
>            Assignee: Bela Ban
>             Fix For: 3.2.14
>
>
> DuplicateTest does the following:
> - creates three channels containing the DUPL layer called c1, c2, c3
> - DUPL is used to duplicate messages sent
> - channel receiver for channel each keeps a map of messages received from each sender
> - channels send messages: regular, OOB, or mixed
> - the test checks that the messages received  by each channel are correct in number and in order
> The test testOOBMuloticastToAll3Senders is failing regularly on multple platforms. The test makes each of the channels send OOB multicast messages to the group, but only two of three members ever end up receiving the multicast messages. Al example of the failure:
> {noformat}
> Error Message
> expected size=3, msgs: [C2, C1]
> Stacktrace
> java.lang.AssertionError 
> at org.jgroups.tests.DuplicateTest.check(DuplicateTest.java:217) 
> at org.jgroups.tests.DuplicateTest.testOOBMulticastToAll3Senders(DuplicateTest.java:123) 
> {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

From issues at jboss.org  Wed Mar 26 10:09:13 2014
From: issues at jboss.org (Richard Achmatowicz (JIRA))
Date: Wed, 26 Mar 2014 10:09:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1801) DuplicateTest fails when
 testing OOB multicast to all three senders
In-Reply-To: <JIRA.12533765.1393853856000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12533765.1393853856000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12533765.1393853856000.10001.1395842953964@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JGRP-1801?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12956592#comment-12956592 ] 

Richard Achmatowicz edited comment on JGRP-1801 at 3/26/14 10:08 AM:
---------------------------------------------------------------------

Even if I adjust the timeout to wait for 60 seconds, I still get failures. 
I added in code to print a dot (.) after each second of waiting. In passing tests, I see this:
{noformat}
------------- testOOBMulticastToAll3Senders -----------
Checking for messages from all senders:
.
[C1]: C1: [1, 2, 3, 4, 5, 6, 7, 8, 9, 10]
[C1]: C2: [9, 2, 1, 10, 3, 5, 6, 7, 4, 8]
[C1]: c3: [1, 10, 2, 3, 5, 4, 8, 9, 7, 6]
Checking for messages from all senders:

[C2]: C1: [1, 2, 10, 3, 4, 6, 8, 9, 5, 7]
[C2]: C2: [3, 1, 2, 4, 5, 6, 7, 8, 9, 10]
[C2]: c3: [2, 5, 6, 1, 10, 3, 7, 8, 9, 4]
Checking for messages from all senders:

[C3]: C1: [1, 2, 10, 3, 4, 5, 6, 7, 8, 9]
[C3]: C2: [1, 10, 2, 3, 4, 5, 6, 7, 8, 9]
[C3]: c3: [1, 8, 2, 3, 4, 5, 9, 10, 7, 6]
{noformat}

but in the faiiing tests, I see this:
{noformat}
------------- testOOBMulticastToAll3Senders -----------
Checking for messages from all senders:

[C1]: C1: [1, 2, 3, 4, 5, 6, 7, 8, 9, 10]
[C1]: C2: [1, 6, 5, 2, 3, 4, 10, 7, 8, 9]
[C1]: c3: [1, 10, 2, 3, 4, 6, 7, 8, 9, 5]
Checking for messages from all senders:

[C2]: C1: [1, 2, 3, 10, 4, 5, 7, 8, 9, 6]
[C2]: C2: [1, 2, 3, 4, 5, 6, 7, 8, 9, 10]
[C2]: c3: [1, 5, 2, 3, 4, 10, 6, 7, 8, 9]
Checking for messages from all senders:
............................................................
{noformat}

In other words, even with a timeout of 60 seconds, on channel C3, messages are not being received from one of the three channels. It seems that something (either sending or receiving) is getting "stuck".

                
      was (Author: rachmato):
    Even if I adjust the timeout to wait for 60 seconds, I still get failures. 
I added in code to print a dot (.) after each second of waiting. In passing tests, I see this:
{noformat}
------------- testOOBMulticastToAll3Senders -----------
Checking for messages from all senders:
.
[C1]: C1: [1, 2, 3, 4, 5, 6, 7, 8, 9, 10]
[C1]: C2: [9, 2, 1, 10, 3, 5, 6, 7, 4, 8]
[C1]: c3: [1, 10, 2, 3, 5, 4, 8, 9, 7, 6]
Checking for messages from all senders:

[C2]: C1: [1, 2, 10, 3, 4, 6, 8, 9, 5, 7]
[C2]: C2: [3, 1, 2, 4, 5, 6, 7, 8, 9, 10]
[C2]: c3: [2, 5, 6, 1, 10, 3, 7, 8, 9, 4]
Checking for messages from all senders:

[C3]: C1: [1, 2, 10, 3, 4, 5, 6, 7, 8, 9]
[C3]: C2: [1, 10, 2, 3, 4, 5, 6, 7, 8, 9]
[C3]: c3: [1, 8, 2, 3, 4, 5, 9, 10, 7, 6]
{noformat}

but in the faiiing tests, I see this:
{nofomat}
------------- testOOBMulticastToAll3Senders -----------
Checking for messages from all senders:

[C1]: C1: [1, 2, 3, 4, 5, 6, 7, 8, 9, 10]
[C1]: C2: [1, 6, 5, 2, 3, 4, 10, 7, 8, 9]
[C1]: c3: [1, 10, 2, 3, 4, 6, 7, 8, 9, 5]
Checking for messages from all senders:

[C2]: C1: [1, 2, 3, 10, 4, 5, 7, 8, 9, 6]
[C2]: C2: [1, 2, 3, 4, 5, 6, 7, 8, 9, 10]
[C2]: c3: [1, 5, 2, 3, 4, 10, 6, 7, 8, 9]
Checking for messages from all senders:
............................................................
{noformat}

In other words, even with a timeout of 60 seconds, on channel C3, messages are not being received from one of the three channels.

                  
> DuplicateTest fails when testing OOB multicast to all three senders
> -------------------------------------------------------------------
>
>                 Key: JGRP-1801
>                 URL: https://issues.jboss.org/browse/JGRP-1801
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.2.13
>         Environment: Windows (18), Solaris (2), RHEL(1) where (x) is the number of failures seen
>            Reporter: Richard Achmatowicz
>            Assignee: Bela Ban
>             Fix For: 3.2.14
>
>
> DuplicateTest does the following:
> - creates three channels containing the DUPL layer called c1, c2, c3
> - DUPL is used to duplicate messages sent
> - channel receiver for channel each keeps a map of messages received from each sender
> - channels send messages: regular, OOB, or mixed
> - the test checks that the messages received  by each channel are correct in number and in order
> The test testOOBMuloticastToAll3Senders is failing regularly on multple platforms. The test makes each of the channels send OOB multicast messages to the group, but only two of three members ever end up receiving the multicast messages. Al example of the failure:
> {noformat}
> Error Message
> expected size=3, msgs: [C2, C1]
> Stacktrace
> java.lang.AssertionError 
> at org.jgroups.tests.DuplicateTest.check(DuplicateTest.java:217) 
> at org.jgroups.tests.DuplicateTest.testOOBMulticastToAll3Senders(DuplicateTest.java:123) 
> {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

From issues at jboss.org  Wed Mar 26 10:21:13 2014
From: issues at jboss.org (Richard Achmatowicz (JIRA))
Date: Wed, 26 Mar 2014 10:21:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1801) DuplicateTest fails when
 testing OOB multicast to all three senders
In-Reply-To: <JIRA.12533765.1393853856000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12533765.1393853856000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12533765.1393853856000.10182.1395843673228@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JGRP-1801?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12956592#comment-12956592 ] 

Richard Achmatowicz edited comment on JGRP-1801 at 3/26/14 10:20 AM:
---------------------------------------------------------------------

Even if I adjust the timeout to wait for 60 seconds, I still get failures. 
I added in code to print a dot (.) after each second of waiting. In passing tests, I see this:
{noformat}
------------- testOOBMulticastToAll3Senders -----------
Checking for messages from all senders:
.
[C1]: C1: [1, 2, 3, 4, 5, 6, 7, 8, 9, 10]
[C1]: C2: [9, 2, 1, 10, 3, 5, 6, 7, 4, 8]
[C1]: c3: [1, 10, 2, 3, 5, 4, 8, 9, 7, 6]
Checking for messages from all senders:

[C2]: C1: [1, 2, 10, 3, 4, 6, 8, 9, 5, 7]
[C2]: C2: [3, 1, 2, 4, 5, 6, 7, 8, 9, 10]
[C2]: c3: [2, 5, 6, 1, 10, 3, 7, 8, 9, 4]
Checking for messages from all senders:

[C3]: C1: [1, 2, 10, 3, 4, 5, 6, 7, 8, 9]
[C3]: C2: [1, 10, 2, 3, 4, 5, 6, 7, 8, 9]
[C3]: c3: [1, 8, 2, 3, 4, 5, 9, 10, 7, 6]
{noformat}

but in the faiiing tests, I see this:
{noformat}
------------- testOOBMulticastToAll3Senders -----------
Checking for messages from all senders:

[C1]: C1: [1, 2, 3, 4, 5, 6, 7, 8, 9, 10]
[C1]: C2: [1, 6, 5, 2, 3, 4, 10, 7, 8, 9]
[C1]: c3: [1, 10, 2, 3, 4, 6, 7, 8, 9, 5]
Checking for messages from all senders:

[C2]: C1: [1, 2, 3, 10, 4, 5, 7, 8, 9, 6]
[C2]: C2: [1, 2, 3, 4, 5, 6, 7, 8, 9, 10]
[C2]: c3: [1, 5, 2, 3, 4, 10, 6, 7, 8, 9]
Checking for messages from all senders:
............................................................
{noformat}

In other words, even with a timeout of 60 seconds, on channel C3, messages are not being received from one of the three channels. It seems that something (either sending or receiving) is getting "stuck".

Again, disabling the OOB thread pool fixes things.
                
      was (Author: rachmato):
    Even if I adjust the timeout to wait for 60 seconds, I still get failures. 
I added in code to print a dot (.) after each second of waiting. In passing tests, I see this:
{noformat}
------------- testOOBMulticastToAll3Senders -----------
Checking for messages from all senders:
.
[C1]: C1: [1, 2, 3, 4, 5, 6, 7, 8, 9, 10]
[C1]: C2: [9, 2, 1, 10, 3, 5, 6, 7, 4, 8]
[C1]: c3: [1, 10, 2, 3, 5, 4, 8, 9, 7, 6]
Checking for messages from all senders:

[C2]: C1: [1, 2, 10, 3, 4, 6, 8, 9, 5, 7]
[C2]: C2: [3, 1, 2, 4, 5, 6, 7, 8, 9, 10]
[C2]: c3: [2, 5, 6, 1, 10, 3, 7, 8, 9, 4]
Checking for messages from all senders:

[C3]: C1: [1, 2, 10, 3, 4, 5, 6, 7, 8, 9]
[C3]: C2: [1, 10, 2, 3, 4, 5, 6, 7, 8, 9]
[C3]: c3: [1, 8, 2, 3, 4, 5, 9, 10, 7, 6]
{noformat}

but in the faiiing tests, I see this:
{noformat}
------------- testOOBMulticastToAll3Senders -----------
Checking for messages from all senders:

[C1]: C1: [1, 2, 3, 4, 5, 6, 7, 8, 9, 10]
[C1]: C2: [1, 6, 5, 2, 3, 4, 10, 7, 8, 9]
[C1]: c3: [1, 10, 2, 3, 4, 6, 7, 8, 9, 5]
Checking for messages from all senders:

[C2]: C1: [1, 2, 3, 10, 4, 5, 7, 8, 9, 6]
[C2]: C2: [1, 2, 3, 4, 5, 6, 7, 8, 9, 10]
[C2]: c3: [1, 5, 2, 3, 4, 10, 6, 7, 8, 9]
Checking for messages from all senders:
............................................................
{noformat}

In other words, even with a timeout of 60 seconds, on channel C3, messages are not being received from one of the three channels. It seems that something (either sending or receiving) is getting "stuck".

                  
> DuplicateTest fails when testing OOB multicast to all three senders
> -------------------------------------------------------------------
>
>                 Key: JGRP-1801
>                 URL: https://issues.jboss.org/browse/JGRP-1801
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.2.13
>         Environment: Windows (18), Solaris (2), RHEL(1) where (x) is the number of failures seen
>            Reporter: Richard Achmatowicz
>            Assignee: Bela Ban
>             Fix For: 3.2.14
>
>
> DuplicateTest does the following:
> - creates three channels containing the DUPL layer called c1, c2, c3
> - DUPL is used to duplicate messages sent
> - channel receiver for channel each keeps a map of messages received from each sender
> - channels send messages: regular, OOB, or mixed
> - the test checks that the messages received  by each channel are correct in number and in order
> The test testOOBMuloticastToAll3Senders is failing regularly on multple platforms. The test makes each of the channels send OOB multicast messages to the group, but only two of three members ever end up receiving the multicast messages. Al example of the failure:
> {noformat}
> Error Message
> expected size=3, msgs: [C2, C1]
> Stacktrace
> java.lang.AssertionError 
> at org.jgroups.tests.DuplicateTest.check(DuplicateTest.java:217) 
> at org.jgroups.tests.DuplicateTest.testOOBMulticastToAll3Senders(DuplicateTest.java:123) 
> {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

From issues at jboss.org  Wed Mar 26 10:37:18 2014
From: issues at jboss.org (Richard Achmatowicz (JIRA))
Date: Wed, 26 Mar 2014 10:37:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3003) Dropping unicast message to
 wrong destination warn after cluster node rejoin
In-Reply-To: <JIRA.12533083.1393242652000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12533083.1393242652000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12533083.1393242652000.10352.1395844638915@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-3003?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12956621#comment-12956621 ] 

Richard Achmatowicz commented on WFLY-3003:
-------------------------------------------

Sorry for the late reply, got bogged down with other stuff.
This is a known issue: https://issues.jboss.org/browse/WFLY-2632
Bela has responded here: https://issues.jboss.org/browse/JGRP-1755
                
> Dropping unicast message to wrong destination warn after cluster node rejoin
> ----------------------------------------------------------------------------
>
>                 Key: WFLY-3003
>                 URL: https://issues.jboss.org/browse/WFLY-3003
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Clustering
>    Affects Versions: 8.0.0.Final
>            Reporter: Eduardo Martins
>            Assignee: Richard Achmatowicz
>            Priority: Critical
>             Fix For: 8.0.1.Final
>
>
> There is a never ending warn log message printed after a cluster node rejoins, after a shutdown:
> 03:43:15,831 WARN  [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/server: dropping unicast message to wrong destination a1fdbb88-a500-483d-7405-70c93a8ab740
> 03:43:15,831 WARN  [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/ejb: dropping unicast message to wrong destination f567dfca-cdad-2555-0e3b-22c8ebded75b
> 03:43:15,887 INFO  [org.jboss.as.server] (Controller Boot Thread) JBAS018559: Deployed "wildfly-cluster-ha-singleton-service.jar" (runtime-name : "wildfly-cluster-ha-singleton-service.jar")
> 03:43:15,895 INFO  [org.jboss.as] (Controller Boot Thread) JBAS015961: Http management interface listening on http://127.0.0.1:10090/management
> 03:43:15,895 INFO  [org.jboss.as] (Controller Boot Thread) JBAS015951: Admin console listening on http://127.0.0.1:10090
> 03:43:15,896 INFO  [org.jboss.as] (Controller Boot Thread) JBAS015874: WildFly 8.0.1.Final-SNAPSHOT "WildFly" started in 4855ms - Started 345 of 437 services (171 services are lazy, passive or on-demand)
> 03:43:16,332 WARN  [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/server: dropping unicast message to wrong destination a1fdbb88-a500-483d-7405-70c93a8ab740
> 03:43:16,332 WARN  [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/ejb: dropping unicast message to wrong destination f567dfca-cdad-2555-0e3b-22c8ebded75b
> 03:43:16,833 WARN  [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/server: dropping unicast message to wrong destination a1fdbb88-a500-483d-7405-70c93a8ab740
> 03:43:16,834 WARN  [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/ejb: dropping unicast message to wrong destination f567dfca-cdad-2555-0e3b-22c8ebded75b
> 03:43:17,335 WARN  [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/server: dropping unicast message to wrong destination a1fdbb88-a500-483d-7405-70c93a8ab740
> 03:43:17,336 WARN  [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/ejb: dropping unicast message to wrong destination f567dfca-cdad-2555-0e3b-22c8ebded75b
> 03:43:17,835 WARN  [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/server: dropping unicast message to wrong destination a1fdbb88-a500-483d-7405-70c93a8ab740
> 03:43:17,836 WARN  [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/ejb: dropping unicast message to wrong destination f567dfca-cdad-2555-0e3b-22c8ebded75b
> 03:43:18,335 WARN  [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/server: dropping unicast message to wrong destination a1fdbb88-a500-483d-7405-70c93a8ab740
> 03:43:18,336 WARN  [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/ejb: dropping unicast message to wrong destination f567dfca-cdad-2555-0e3b-22c8ebded75b
> 03:43:18,837 WARN  [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/server: dropping unicast message to wrong destination a1fdbb88-a500-483d-7405-70c93a8ab740
> 03:43:18,838 WARN  [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/ejb: dropping unicast message to wrong destination f567dfca-cdad-2555-0e3b-22c8ebded75b
> 03:43:19,339 WARN  [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/server: dropping unicast message to wrong destination a1fdbb88-a500-483d-7405-70c93a8ab740
> 03:43:19,340 WARN  [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/ejb: dropping unicast message to wrong destination f567dfca-cdad-2555-0e3b-22c8ebded75b
> 03:43:19,840 WARN  [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/server: dropping unicast message to wrong destination a1fdbb88-a500-483d-7405-70c93a8ab740
> 03:43:19,840 WARN  [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/ejb: dropping unicast message to wrong destination f567dfca-cdad-2555-0e3b-22c8ebded75b
> 03:43:20,003 INFO  [org.jboss.as.quickstarts.cluster.hasingleton.service.ejb.SchedulerBean] (EJB default - 1) HASingletonTimer: Info=HASingleton timer @nodeTwo Sat Feb 22 03:43:15 WET 2014
> 03:43:20,003 INFO  [org.jboss.as.quickstarts.cluster.hasingleton.service.ejb.SchedulerBean] (EJB default - 2) HASingletonTimer: Info=HASingleton timer @nodeTwo Sat Feb 22 03:43:15 WET 2014
> 03:43:20,341 WARN  [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/server: dropping unicast message to wrong destination a1fdbb88-a500-483d-7405-70c93a8ab740
> 03:43:20,342 WARN  [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/ejb: dropping unicast message to wrong destination f567dfca-cdad-2555-0e3b-22c8ebded75b
> 03:43:20,841 WARN  [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/server: dropping unicast message to wrong destination a1fdbb88-a500-483d-7405-70c93a8ab740
> 03:43:20,842 WARN  [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/ejb: dropping unicast message to wrong destination f567dfca-cdad-2555-0e3b-22c8ebded75b
> 03:43:21,342 WARN  [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/server: dropping unicast message to wrong destination a1fdbb88-a500-483d-7405-70c93a8ab740
> 03:43:21,342 WARN  [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/ejb: dropping unicast message to wrong destination f567dfca-cdad-2555-0e3b-22c8ebded75b
> 03:43:21,842 WARN  [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/server: dropping unicast message to wrong destination a1fdbb88-a500-483d-7405-70c93a8ab740
> 03:43:21,843 WARN  [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/ejb: dropping unicast message to wrong destination f567dfca-cdad-2555-0e3b-22c8ebded75b
> 03:43:22,343 WARN  [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/server: dropping unicast message to wrong destination a1fdbb88-a500-483d-7405-70c93a8ab740
> 03:43:22,344 WARN  [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/ejb: dropping unicast message to wrong destination f567dfca-cdad-2555-0e3b-22c8ebded75b
> 03:43:22,845 WARN  [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/server: dropping unicast message to wrong destination a1fdbb88-a500-483d-7405-70c93a8ab740
> 03:43:22,845 WARN  [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/ejb: dropping unicast message to wrong destination f567dfca-cdad-2555-0e3b-22c8ebded75b
> 03:43:23,345 WARN  [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/server: dropping unicast message to wrong destination a1fdbb88-a500-483d-7405-70c93a8ab740
> 03:43:23,346 WARN  [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/ejb: dropping unicast message to wrong destination f567dfca-cdad-2555-0e3b-22c8ebded75b
> 03:43:23,846 WARN  [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/server: dropping unicast message to wrong destination a1fdbb88-a500-483d-7405-70c93a8ab740
> 03:43:23,846 WARN  [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/ejb: dropping unicast message to wrong destination f567dfca-cdad-2555-0e3b-22c8ebded75b
> This can be seen using WildFly's cluster-ha-singleton quickstart (github project wildfly/quickstart). Just follow quickstart?s readme till point 4 of "Check the timer" section, and after stop node2 (not node1) start it gain.

--
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


From issues at jboss.org  Wed Mar 26 10:41:14 2014
From: issues at jboss.org (Jesper Pedersen (JIRA))
Date: Wed, 26 Mar 2014 10:41:14 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBJCA-1158) TransactionSynchronizer
	missing NPE guard
In-Reply-To: <JIRA.12536181.1395844849228@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12536181.1395844849228@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12536181.1395844849228.10373.1395844874111@jira02.app.mwc.hst.phx2.redhat.com>

Jesper Pedersen created JBJCA-1158:
--------------------------------------

             Summary: TransactionSynchronizer missing NPE guard
                 Key: JBJCA-1158
                 URL: https://issues.jboss.org/browse/JBJCA-1158
             Project: IronJacamar
          Issue Type: Bug
          Components: Core
    Affects Versions: 1.1.4.Final, 1.0.24.Final
            Reporter: Jesper Pedersen
            Assignee: Jesper Pedersen
             Fix For: 1.0.25.Final, 1.1.5.Final, 1.2.0.Beta1




--
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

From issues at jboss.org  Wed Mar 26 10:46:10 2014
From: issues at jboss.org (Bela Ban (JIRA))
Date: Wed, 26 Mar 2014 10:46:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1814) No physical address for X;
 dropping message
In-Reply-To: <JIRA.12536183.1395845002873@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12536183.1395845002873@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12536183.1395845002873.10382.1395845170056@jira02.app.mwc.hst.phx2.redhat.com>

Bela Ban created JGRP-1814:
------------------------------

             Summary: No physical address for X; dropping message
                 Key: JGRP-1814
                 URL: https://issues.jboss.org/browse/JGRP-1814
             Project: JGroups
          Issue Type: Enhancement
            Reporter: Bela Ban
            Assignee: Bela Ban
             Fix For: 3.5


When we have view \{A,B\} and B leaves, then the following happens in UNICAST3:
* B sends a LEAVE-REQ to A
* A sends a LEAVE-RSP to B
* Because the LEAVE-RSP is reliable, A keeps sending the LEAVE-RSP to B until it receives an ACK for the LEAVE-RSP
* However, when B receives the LEAVE-RSP, it marks its connection to be acked, which means that when the next retransmission kicks in, an ACK for the LEAVE-RSP will be sent back to A
* Before this happens, B leaves: the ACK is never sent to A
* A keeps resending the LEAVE-RSP until {{max_retransmit_time}} (default=60s) elapses and the connection is closed. However, the connection is only closed after another 60s (default for {{conn_close_timeout}}).
* Because the reaper removes all entries of {{logical_addr_cache}} before that happens, we're seeing the above warnings

SOLUTION:
# Send LEAVE-RSP unreliable. This bypasses UNICAST3 altogether. The leaver won't block forever if the LEAVE-RSP message is dropped, but only for 3 x {{GMS.leave_timeout}} ms
# Also add a MBR_LEFT event which is sent up and down the stack by GMS when a member left *gracefully*. This allows UNICAST3 to close the connection to a given member *immediately*, stopping unneeded retransmissions to members which left.

--
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

From issues at jboss.org  Wed Mar 26 10:46:10 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 26 Mar 2014 10:46:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3046) Not possible change the
 object store type from hornetq to jdbc via cli commands
In-Reply-To: <JIRA.12533653.1393610670000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12533653.1393610670000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12533653.1393610670000.10396.1395845170789@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-3046?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12956629#comment-12956629 ] 

RH Bugzilla Integration commented on WFLY-3046:
-----------------------------------------------

Ivo Studensky <istudens at redhat.com> changed the Status of [bug 1038993|https://bugzilla.redhat.com/show_bug.cgi?id=1038993] from NEW to ASSIGNED
                
> Not possible change the object store type from hornetq to jdbc via cli commands
> -------------------------------------------------------------------------------
>
>                 Key: WFLY-3046
>                 URL: https://issues.jboss.org/browse/WFLY-3046
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Transactions
>    Affects Versions: 8.0.0.Final
>            Reporter: Ivo Studensky
>            Assignee: Ivo Studensky
>             Fix For: 8.0.1.Final
>
>
> When you have set the object store to be type of hornetq and then you change your mind to set it for jdbc object store the jboss-cli permits this operation but no change is propagated to model and XML file.
> How to reproduce:
> # ./bin/standalone.xml (start eap 6.2.0.GA)
> # ./bin/jboss-cli.sh -c (connect to running eap)
> # /subsystem=transactions:write-attribute(name=use-hornetq-store, value=true)
> # :reload# /subsystem=transactions/log-store=log-store:read-attribute(name=type)# /subsystem=transactions:write-attribute(name=use-jdbc-store, value=true)# :reload
> # /subsystem=transactions/log-store=log-store:read-attribute(name=type)
> The object store stays to be set to hornetq and no change happens in the standalone.xml file.

--
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

From issues at jboss.org  Wed Mar 26 10:49:13 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 26 Mar 2014 10:49:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3046) Not possible change the
 object store type from hornetq to jdbc via cli commands
In-Reply-To: <JIRA.12533653.1393610670000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12533653.1393610670000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12533653.1393610670000.10408.1395845353233@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-3046?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12956630#comment-12956630 ] 

RH Bugzilla Integration commented on WFLY-3046:
-----------------------------------------------

Ivo Studensky <istudens at redhat.com> changed the Status of [bug 1038993|https://bugzilla.redhat.com/show_bug.cgi?id=1038993] from ASSIGNED to POST
                
> Not possible change the object store type from hornetq to jdbc via cli commands
> -------------------------------------------------------------------------------
>
>                 Key: WFLY-3046
>                 URL: https://issues.jboss.org/browse/WFLY-3046
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Transactions
>    Affects Versions: 8.0.0.Final
>            Reporter: Ivo Studensky
>            Assignee: Ivo Studensky
>             Fix For: 8.0.1.Final
>
>
> When you have set the object store to be type of hornetq and then you change your mind to set it for jdbc object store the jboss-cli permits this operation but no change is propagated to model and XML file.
> How to reproduce:
> # ./bin/standalone.xml (start eap 6.2.0.GA)
> # ./bin/jboss-cli.sh -c (connect to running eap)
> # /subsystem=transactions:write-attribute(name=use-hornetq-store, value=true)
> # :reload# /subsystem=transactions/log-store=log-store:read-attribute(name=type)# /subsystem=transactions:write-attribute(name=use-jdbc-store, value=true)# :reload
> # /subsystem=transactions/log-store=log-store:read-attribute(name=type)
> The object store stays to be set to hornetq and no change happens in the standalone.xml file.

--
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

From issues at jboss.org  Wed Mar 26 10:49:13 2014
From: issues at jboss.org (Radoslav Husar (JIRA))
Date: Wed, 26 Mar 2014 10:49:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3003) Dropping unicast message to
 wrong destination warn after cluster node rejoin
In-Reply-To: <JIRA.12533083.1393242652000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12533083.1393242652000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12533083.1393242652000.10417.1395845353677@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-3003?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Radoslav Husar closed WFLY-3003.
--------------------------------

    Resolution: Duplicate Issue


Duplicates WFLY-2632.
                
> Dropping unicast message to wrong destination warn after cluster node rejoin
> ----------------------------------------------------------------------------
>
>                 Key: WFLY-3003
>                 URL: https://issues.jboss.org/browse/WFLY-3003
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Clustering
>    Affects Versions: 8.0.0.Final
>            Reporter: Eduardo Martins
>            Assignee: Richard Achmatowicz
>            Priority: Critical
>             Fix For: 8.0.1.Final
>
>
> There is a never ending warn log message printed after a cluster node rejoins, after a shutdown:
> 03:43:15,831 WARN  [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/server: dropping unicast message to wrong destination a1fdbb88-a500-483d-7405-70c93a8ab740
> 03:43:15,831 WARN  [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/ejb: dropping unicast message to wrong destination f567dfca-cdad-2555-0e3b-22c8ebded75b
> 03:43:15,887 INFO  [org.jboss.as.server] (Controller Boot Thread) JBAS018559: Deployed "wildfly-cluster-ha-singleton-service.jar" (runtime-name : "wildfly-cluster-ha-singleton-service.jar")
> 03:43:15,895 INFO  [org.jboss.as] (Controller Boot Thread) JBAS015961: Http management interface listening on http://127.0.0.1:10090/management
> 03:43:15,895 INFO  [org.jboss.as] (Controller Boot Thread) JBAS015951: Admin console listening on http://127.0.0.1:10090
> 03:43:15,896 INFO  [org.jboss.as] (Controller Boot Thread) JBAS015874: WildFly 8.0.1.Final-SNAPSHOT "WildFly" started in 4855ms - Started 345 of 437 services (171 services are lazy, passive or on-demand)
> 03:43:16,332 WARN  [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/server: dropping unicast message to wrong destination a1fdbb88-a500-483d-7405-70c93a8ab740
> 03:43:16,332 WARN  [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/ejb: dropping unicast message to wrong destination f567dfca-cdad-2555-0e3b-22c8ebded75b
> 03:43:16,833 WARN  [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/server: dropping unicast message to wrong destination a1fdbb88-a500-483d-7405-70c93a8ab740
> 03:43:16,834 WARN  [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/ejb: dropping unicast message to wrong destination f567dfca-cdad-2555-0e3b-22c8ebded75b
> 03:43:17,335 WARN  [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/server: dropping unicast message to wrong destination a1fdbb88-a500-483d-7405-70c93a8ab740
> 03:43:17,336 WARN  [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/ejb: dropping unicast message to wrong destination f567dfca-cdad-2555-0e3b-22c8ebded75b
> 03:43:17,835 WARN  [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/server: dropping unicast message to wrong destination a1fdbb88-a500-483d-7405-70c93a8ab740
> 03:43:17,836 WARN  [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/ejb: dropping unicast message to wrong destination f567dfca-cdad-2555-0e3b-22c8ebded75b
> 03:43:18,335 WARN  [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/server: dropping unicast message to wrong destination a1fdbb88-a500-483d-7405-70c93a8ab740
> 03:43:18,336 WARN  [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/ejb: dropping unicast message to wrong destination f567dfca-cdad-2555-0e3b-22c8ebded75b
> 03:43:18,837 WARN  [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/server: dropping unicast message to wrong destination a1fdbb88-a500-483d-7405-70c93a8ab740
> 03:43:18,838 WARN  [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/ejb: dropping unicast message to wrong destination f567dfca-cdad-2555-0e3b-22c8ebded75b
> 03:43:19,339 WARN  [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/server: dropping unicast message to wrong destination a1fdbb88-a500-483d-7405-70c93a8ab740
> 03:43:19,340 WARN  [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/ejb: dropping unicast message to wrong destination f567dfca-cdad-2555-0e3b-22c8ebded75b
> 03:43:19,840 WARN  [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/server: dropping unicast message to wrong destination a1fdbb88-a500-483d-7405-70c93a8ab740
> 03:43:19,840 WARN  [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/ejb: dropping unicast message to wrong destination f567dfca-cdad-2555-0e3b-22c8ebded75b
> 03:43:20,003 INFO  [org.jboss.as.quickstarts.cluster.hasingleton.service.ejb.SchedulerBean] (EJB default - 1) HASingletonTimer: Info=HASingleton timer @nodeTwo Sat Feb 22 03:43:15 WET 2014
> 03:43:20,003 INFO  [org.jboss.as.quickstarts.cluster.hasingleton.service.ejb.SchedulerBean] (EJB default - 2) HASingletonTimer: Info=HASingleton timer @nodeTwo Sat Feb 22 03:43:15 WET 2014
> 03:43:20,341 WARN  [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/server: dropping unicast message to wrong destination a1fdbb88-a500-483d-7405-70c93a8ab740
> 03:43:20,342 WARN  [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/ejb: dropping unicast message to wrong destination f567dfca-cdad-2555-0e3b-22c8ebded75b
> 03:43:20,841 WARN  [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/server: dropping unicast message to wrong destination a1fdbb88-a500-483d-7405-70c93a8ab740
> 03:43:20,842 WARN  [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/ejb: dropping unicast message to wrong destination f567dfca-cdad-2555-0e3b-22c8ebded75b
> 03:43:21,342 WARN  [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/server: dropping unicast message to wrong destination a1fdbb88-a500-483d-7405-70c93a8ab740
> 03:43:21,342 WARN  [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/ejb: dropping unicast message to wrong destination f567dfca-cdad-2555-0e3b-22c8ebded75b
> 03:43:21,842 WARN  [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/server: dropping unicast message to wrong destination a1fdbb88-a500-483d-7405-70c93a8ab740
> 03:43:21,843 WARN  [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/ejb: dropping unicast message to wrong destination f567dfca-cdad-2555-0e3b-22c8ebded75b
> 03:43:22,343 WARN  [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/server: dropping unicast message to wrong destination a1fdbb88-a500-483d-7405-70c93a8ab740
> 03:43:22,344 WARN  [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/ejb: dropping unicast message to wrong destination f567dfca-cdad-2555-0e3b-22c8ebded75b
> 03:43:22,845 WARN  [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/server: dropping unicast message to wrong destination a1fdbb88-a500-483d-7405-70c93a8ab740
> 03:43:22,845 WARN  [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/ejb: dropping unicast message to wrong destination f567dfca-cdad-2555-0e3b-22c8ebded75b
> 03:43:23,345 WARN  [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/server: dropping unicast message to wrong destination a1fdbb88-a500-483d-7405-70c93a8ab740
> 03:43:23,346 WARN  [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/ejb: dropping unicast message to wrong destination f567dfca-cdad-2555-0e3b-22c8ebded75b
> 03:43:23,846 WARN  [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/server: dropping unicast message to wrong destination a1fdbb88-a500-483d-7405-70c93a8ab740
> 03:43:23,846 WARN  [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/ejb: dropping unicast message to wrong destination f567dfca-cdad-2555-0e3b-22c8ebded75b
> This can be seen using WildFly's cluster-ha-singleton quickstart (github project wildfly/quickstart). Just follow quickstart?s readme till point 4 of "Check the timer" section, and after stop node2 (not node1) start it gain.

--
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


From issues at jboss.org  Wed Mar 26 10:51:14 2014
From: issues at jboss.org (Farah Juma (JIRA))
Date: Wed, 26 Mar 2014 10:51:14 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3168) Wrong Mojarra version on Linux
In-Reply-To: <JIRA.12536142.1395831654000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12536142.1395831654000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12536142.1395831654000.10421.1395845474075@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-3168?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12956634#comment-12956634 ] 

Farah Juma commented on WFLY-3168:
----------------------------------

Are you sure you're running the same version of WildFly on both Linux and Windows? WildFly 8 Final only contains Mojarra 2.2.5 (the Mojarra jar is in the modules/system/layers/base/com/sun/jsf-impl/main directory). Mojarra 2.1.7 hasn't been included in the modules/com/sun/jsf-impl directory since AS 7.1.1.Final.
                
> Wrong Mojarra version on Linux
> ------------------------------
>
>                 Key: WFLY-3168
>                 URL: https://issues.jboss.org/browse/WFLY-3168
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JSF
>    Affects Versions: 8.0.0.Final
>         Environment: Linux
>            Reporter: Thorsten Richter
>            Assignee: Farah Juma
>              Labels: jsf, linux, mojarra, viewscoped
>
> We had a bug on Linux that the @ViewScoped annotation didn't work for AJAX requests. We found out, that the Mojarra version is causing the problem. On our Windows development machines everything worked fine, but on the Linux production server @ViewScoped didn't work.
> So we searched for the root cause and found out, that the Mojarra version was different on Linux.
> The Linux package of Wildfly contains an older version of Mojarra (2.1.7) within the modules/com/sun/jsf-impl folder that needs to be deleted.
> The Windows package of Wildfly doesn't even contain a com folder within modules.
> So maybe the whole com folder on Linux is wrong?

--
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

From issues at jboss.org  Wed Mar 26 10:57:12 2014
From: issues at jboss.org (James Perkins (JIRA))
Date: Wed, 26 Mar 2014 10:57:12 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3172) Upgrade JBeret to 1.0.1
In-Reply-To: <JIRA.12536189.1395845815433@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12536189.1395845815433@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12536189.1395845815433.10463.1395845832861@jira02.app.mwc.hst.phx2.redhat.com>

James Perkins created WFLY-3172:
-----------------------------------

             Summary: Upgrade JBeret to 1.0.1
                 Key: WFLY-3172
                 URL: https://issues.jboss.org/browse/WFLY-3172
             Project: WildFly
          Issue Type: Component  Upgrade
      Security Level: Public (Everyone can see)
          Components: Batch
            Reporter: James Perkins
            Assignee: James Perkins
            Priority: Blocker
             Fix For: 8.0.1.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

From issues at jboss.org  Wed Mar 26 11:03:13 2014
From: issues at jboss.org (Richard Achmatowicz (JIRA))
Date: Wed, 26 Mar 2014 11:03:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2632) JGroups drops unicast
 messages after shutdown/restart
In-Reply-To: <JIRA.12527590.1386700000000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12527590.1386700000000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12527590.1386700000000.10476.1395846193201@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2632?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Richard Achmatowicz updated WFLY-2632:
--------------------------------------

    Fix Version/s: 8.0.1.Final

    
> JGroups drops unicast messages after shutdown/restart
> -----------------------------------------------------
>
>                 Key: WFLY-2632
>                 URL: https://issues.jboss.org/browse/WFLY-2632
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Clustering
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Richard Achmatowicz
>            Assignee: Richard Achmatowicz
>             Fix For: 8.0.1.Final
>
>
> JGroups drops unicast messages (citing wrong destination) after a node in a cluster is shutdown and then restarted.
> The JGroups version in use is 3.4.1.Final.
> Steps to reproduce:
> - start two nodes A, B using the server configuration standalone-ha.xml to create a cluster
> - shutdown A
> - restart A
> - after restart, we see these messages:
> {noformat}
> 13:15:03,227 INFO  [stdout] (ServerService Thread Pool -- 63)
> 13:15:03,228 INFO  [stdout] (ServerService Thread Pool -- 63) -------------------------------------------------------------------
> 13:15:03,228 INFO  [stdout] (ServerService Thread Pool -- 63) GMS: address=lenovo/web, cluster=web, physical address=127.0.0.1:55200
> 13:15:03,229 INFO  [stdout] (ServerService Thread Pool -- 63) -------------------------------------------------------------------
> 13:15:03,414 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (ServerService Thread Pool -- 63) ISPN000094: Received new cluster view: [fred/
> web|3] (2) [fred/web, lenovo/web]
> 13:15:03,422 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (ServerService Thread Pool -- 63) ISPN000079: Cache local address is lenovo/web
> , physical addresses are [127.0.0.1:55200]
> 13:15:03,427 INFO  [org.infinispan.factories.GlobalComponentRegistry] (ServerService Thread Pool -- 63) ISPN000128: Infinispan version: Infinispan 'Infinium' 6
> .0.0.CR1
> 13:15:03,533 WARN  [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: lenovo/web: dropping unicast message to wrong destination ac84f3e5
> -f005-ddb2-b377-46b165e2aa77
> 13:15:03,609 INFO  [org.infinispan.jmx.CacheJmxRegistration] (ServerService Thread Pool -- 61) ISPN000031: MBeans were successfully registered to the platform 
> MBean server.
> 13:15:03,610 INFO  [org.infinispan.jmx.CacheJmxRegistration] (ServerService Thread Pool -- 62) ISPN000031: MBeans were successfully registered to the platform 
> MBean server.
> 13:15:03,765 INFO  [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 62) JBAS010281: Started default-host/distributable cache from web contain
> er
> 13:15:03,768 INFO  [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 61) JBAS010281: Started dist cache from web container
> 13:15:03,906 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-1) JBAS017534: Register web context: /distributable
> 13:15:03,978 INFO  [org.jboss.as.server] (Controller Boot Thread) JBAS018559: Deployed "distributable.war" (runtime-name : "distributable.war")
> 13:15:04,033 WARN  [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: lenovo/web: dropping unicast message to wrong destination ac84f3e5
> -f005-ddb2-b377-46b165e2aa77
> 13:15:04,059 INFO  [org.jboss.as] (Controller Boot Thread) JBAS015961: Http management interface listening on http://127.0.0.1:9990/management
> 13:15:04,060 INFO  [org.jboss.as] (Controller Boot Thread) JBAS015951: Admin console listening on http://127.0.0.1:9990
> 13:15:04,060 INFO  [org.jboss.as] (Controller Boot Thread) JBAS015874: WildFly 8.0.0.Beta2-SNAPSHOT "WildFly" started in 5193ms - Started 293 of 410 services (178 services are lazy, passive or on-demand)
> 13:15:04,533 WARN  [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: lenovo/web: dropping unicast message to wrong destination ac84f3e5-f005-ddb2-b377-46b165e2aa77
> 13:15:05,034 WARN  [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: lenovo/web: dropping unicast message to wrong destination ac84f3e5-f005-ddb2-b377-46b165e2aa77
> 13:15:05,534 WARN  [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: lenovo/web: dropping unicast message to wrong destination ac84f3e5-f005-ddb2-b377-46b165e2aa77
> {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

From issues at jboss.org  Wed Mar 26 11:05:13 2014
From: issues at jboss.org (Jesper Pedersen (JIRA))
Date: Wed, 26 Mar 2014 11:05:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBJCA-1158) TransactionSynchronizer
	missing NPE guard
In-Reply-To: <JIRA.12536181.1395844849000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12536181.1395844849000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12536181.1395844849000.10482.1395846313516@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBJCA-1158?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jesper Pedersen resolved JBJCA-1158.
------------------------------------

    Resolution: Done

    
> TransactionSynchronizer missing NPE guard
> -----------------------------------------
>
>                 Key: JBJCA-1158
>                 URL: https://issues.jboss.org/browse/JBJCA-1158
>             Project: IronJacamar
>          Issue Type: Bug
>          Components: Core
>    Affects Versions: 1.0.24.Final, 1.1.4.Final
>            Reporter: Jesper Pedersen
>            Assignee: Jesper Pedersen
>             Fix For: 1.0.25.Final, 1.1.5.Final, 1.2.0.Beta1
>
>


--
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

From issues at jboss.org  Wed Mar 26 11:15:13 2014
From: issues at jboss.org (Frank Hempel (JIRA))
Date: Wed, 26 Mar 2014 11:15:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3087) Websocket
 NullPointerException on
 io.undertow.websockets.jsr.annotated.AnnotatedEndpoint$AnnotatedEndpointFrameHandler.handleBinaryMessage(AnnotatedEndpoint.java:373)
In-Reply-To: <JIRA.12534452.1394215322000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534452.1394215322000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534452.1394215322000.10535.1395846913722@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-3087?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12956652#comment-12956652 ] 

Frank Hempel commented on WFLY-3087:
------------------------------------

It can be reproduced. All you have to do is don't implement the binaryMessage()-handler in the WebSocket endpoint class. Then the binaryMessage attribute of the AnnotatedEndpoint object is null which is not tested in the handleBinaryMessage method. Anyway, the result at clients would always be the same: no handler -> no action ;)
                
> Websocket NullPointerException on io.undertow.websockets.jsr.annotated.AnnotatedEndpoint$AnnotatedEndpointFrameHandler.handleBinaryMessage(AnnotatedEndpoint.java:373)
> ----------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-3087
>                 URL: https://issues.jboss.org/browse/WFLY-3087
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web (Undertow)
>    Affects Versions: 8.0.0.CR1
>         Environment: windows server 2008
>            Reporter: Admin FlirtyMob
>            Assignee: Stuart Douglas
>             Fix For: 8.0.1.Final
>
>
> 2014-03-07 17:10:49,208 ERROR [org.xnio.listener] (default I/O-1) XNIO001007: A channel event listener threw an exception: java.lang.NullPointerException
> at io.undertow.websockets.jsr.annotated.AnnotatedEndpoint$AnnotatedEndpointFrameHandler.handleBinaryMessage(AnnotatedEndpoint.java:373)
> at io.undertow.websockets.jsr.annotated.AnnotatedEndpoint$AnnotatedEndpointFrameHandler.access$1100(AnnotatedEndpoint.java:126)
> at io.undertow.websockets.jsr.annotated.AnnotatedEndpoint$AnnotatedEndpointFrameHandler$6.complete(AnnotatedEndpoint.java:332)
> at io.undertow.websockets.jsr.annotated.AnnotatedEndpoint$AnnotatedEndpointFrameHandler$6.complete(AnnotatedEndpoint.java:329)
> at io.undertow.websockets.core.BufferedBinaryMessage.read(BufferedBinaryMessage.java:76)
> at io.undertow.websockets.jsr.annotated.AnnotatedEndpoint$AnnotatedEndpointFrameHandler.onBinary(AnnotatedEndpoint.java:329)
> at io.undertow.websockets.core.AbstractReceiveListener.handleEvent(AbstractReceiveListener.java:24)
> at io.undertow.websockets.core.AbstractReceiveListener.handleEvent(AbstractReceiveListener.java:15)
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) [xnio-api-3.2.0.Beta4.jar:3.2.0.Beta4]
> at io.undertow.server.protocol.framed.AbstractFramedChannel$FrameReadListener.handleEvent(AbstractFramedChannel.java:615)
> at io.undertow.server.protocol.framed.AbstractFramedChannel$FrameReadListener.handleEvent(AbstractFramedChannel.java:601)
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) [xnio-api-3.2.0.Beta4.jar:3.2.0.Beta4]
> at org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66) [xnio-api-3.2.0.Beta4.jar:3.2.0.Beta4]
> at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:87) [xnio-nio-3.2.0.Beta4.jar:3.2.0.Beta4]
> at org.xnio.nio.WorkerThread.run(WorkerThread.java:531) [xnio-nio-3.2.0.Beta4.jar:3.2.0.Beta4]

--
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

From issues at jboss.org  Wed Mar 26 11:21:13 2014
From: issues at jboss.org (Bela Ban (JIRA))
Date: Wed, 26 Mar 2014 11:21:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1815) TP: sending a message to a
 non-existent physical address takes too much time
In-Reply-To: <JIRA.12536191.1395847224406@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12536191.1395847224406@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12536191.1395847224406.10561.1395847273137@jira02.app.mwc.hst.phx2.redhat.com>

Bela Ban created JGRP-1815:
------------------------------

             Summary: TP: sending a message to a non-existent physical address takes too much time
                 Key: JGRP-1815
                 URL: https://issues.jboss.org/browse/JGRP-1815
             Project: JGroups
          Issue Type: Enhancement
            Reporter: Bela Ban
            Assignee: Bela Ban
             Fix For: 3.5


When sending a message in the transport, e.g. a message batch, and one or more destinations have no physical addresses in {{logical_addr_cache}}, then we loop {{physical_addr_max_fetch_attempts}} (default: 3) times and also sleep a random number of ms (in range [1..500]). 
This delays the sending of other messages in the same batch, or of other messages in general. Also, if TransferQueueBundler is used, the transfer queue might get filled, so other sender threads are blocked.
SOLUTION:
* Remove the loop when sending a message: if the physical address for a message is not found, simply send a discovery request and drop the message
* The discovery request needs to be sent on a separate thread, as calling {{up(Event)}} directly could also delay the sending of the message or message batch.
* JGRP-1814 will also help, as connections to left members are closed, and therefore not finding a physical address for a destination should be rare

--
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

From issues at jboss.org  Wed Mar 26 11:31:13 2014
From: issues at jboss.org (Tomaz Cerar (JIRA))
Date: Wed, 26 Mar 2014 11:31:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3087) Websocket
 NullPointerException on
 io.undertow.websockets.jsr.annotated.AnnotatedEndpoint$AnnotatedEndpointFrameHandler.handleBinaryMessage(AnnotatedEndpoint.java:373)
In-Reply-To: <JIRA.12534452.1394215322000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534452.1394215322000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534452.1394215322000.10621.1395847873400@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-3087?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12956670#comment-12956670 ] 

Tomaz Cerar commented on WFLY-3087:
-----------------------------------

There ware many changes in work for 8.0.1 coming up soon,
can you test it if it is fixed there? you can grab nightly build at https://community.jboss.org/thread/224262
                
> Websocket NullPointerException on io.undertow.websockets.jsr.annotated.AnnotatedEndpoint$AnnotatedEndpointFrameHandler.handleBinaryMessage(AnnotatedEndpoint.java:373)
> ----------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-3087
>                 URL: https://issues.jboss.org/browse/WFLY-3087
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web (Undertow)
>    Affects Versions: 8.0.0.CR1
>         Environment: windows server 2008
>            Reporter: Admin FlirtyMob
>            Assignee: Stuart Douglas
>             Fix For: 8.0.1.Final
>
>
> 2014-03-07 17:10:49,208 ERROR [org.xnio.listener] (default I/O-1) XNIO001007: A channel event listener threw an exception: java.lang.NullPointerException
> at io.undertow.websockets.jsr.annotated.AnnotatedEndpoint$AnnotatedEndpointFrameHandler.handleBinaryMessage(AnnotatedEndpoint.java:373)
> at io.undertow.websockets.jsr.annotated.AnnotatedEndpoint$AnnotatedEndpointFrameHandler.access$1100(AnnotatedEndpoint.java:126)
> at io.undertow.websockets.jsr.annotated.AnnotatedEndpoint$AnnotatedEndpointFrameHandler$6.complete(AnnotatedEndpoint.java:332)
> at io.undertow.websockets.jsr.annotated.AnnotatedEndpoint$AnnotatedEndpointFrameHandler$6.complete(AnnotatedEndpoint.java:329)
> at io.undertow.websockets.core.BufferedBinaryMessage.read(BufferedBinaryMessage.java:76)
> at io.undertow.websockets.jsr.annotated.AnnotatedEndpoint$AnnotatedEndpointFrameHandler.onBinary(AnnotatedEndpoint.java:329)
> at io.undertow.websockets.core.AbstractReceiveListener.handleEvent(AbstractReceiveListener.java:24)
> at io.undertow.websockets.core.AbstractReceiveListener.handleEvent(AbstractReceiveListener.java:15)
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) [xnio-api-3.2.0.Beta4.jar:3.2.0.Beta4]
> at io.undertow.server.protocol.framed.AbstractFramedChannel$FrameReadListener.handleEvent(AbstractFramedChannel.java:615)
> at io.undertow.server.protocol.framed.AbstractFramedChannel$FrameReadListener.handleEvent(AbstractFramedChannel.java:601)
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) [xnio-api-3.2.0.Beta4.jar:3.2.0.Beta4]
> at org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66) [xnio-api-3.2.0.Beta4.jar:3.2.0.Beta4]
> at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:87) [xnio-nio-3.2.0.Beta4.jar:3.2.0.Beta4]
> at org.xnio.nio.WorkerThread.run(WorkerThread.java:531) [xnio-nio-3.2.0.Beta4.jar:3.2.0.Beta4]

--
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

From issues at jboss.org  Wed Mar 26 11:35:14 2014
From: issues at jboss.org (Paul Ferraro (JIRA))
Date: Wed, 26 Mar 2014 11:35:14 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3173) Default number of DIST owners
 is too conservative
In-Reply-To: <JIRA.12536194.1395848094372@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12536194.1395848094372@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12536194.1395848094372.10650.1395848114449@jira02.app.mwc.hst.phx2.redhat.com>

Paul Ferraro created WFLY-3173:
----------------------------------

             Summary: Default number of DIST owners is too conservative
                 Key: WFLY-3173
                 URL: https://issues.jboss.org/browse/WFLY-3173
             Project: WildFly
          Issue Type: Enhancement
      Security Level: Public (Everyone can see)
          Components: Clustering
    Affects Versions: 8.0.0.Final
            Reporter: Paul Ferraro
            Assignee: Paul Ferraro


WildFly uses DIST by default using 4 owners, which is too conservative.  I think we should lower this default value to 2, which is Infinispan's default value.  We'll get a nice performance bump too.

Don't forget to create transformers to handle the default value change for old model versions.

--
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

From issues at jboss.org  Wed Mar 26 11:41:13 2014
From: issues at jboss.org (Radoslav Husar (JIRA))
Date: Wed, 26 Mar 2014 11:41:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3173) Default number of DIST owners
 is too conservative
In-Reply-To: <JIRA.12536194.1395848094000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12536194.1395848094000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12536194.1395848094000.10654.1395848473586@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-3173?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Radoslav Husar reassigned WFLY-3173:
------------------------------------

    Assignee: Radoslav Husar  (was: Paul Ferraro)

    
> Default number of DIST owners is too conservative
> -------------------------------------------------
>
>                 Key: WFLY-3173
>                 URL: https://issues.jboss.org/browse/WFLY-3173
>             Project: WildFly
>          Issue Type: Enhancement
>      Security Level: Public(Everyone can see) 
>          Components: Clustering
>    Affects Versions: 8.0.0.Final
>            Reporter: Paul Ferraro
>            Assignee: Radoslav Husar
>
> WildFly uses DIST by default using 4 owners, which is too conservative.  I think we should lower this default value to 2, which is Infinispan's default value.  We'll get a nice performance bump too.
> Don't forget to create transformers to handle the default value change for old model versions.

--
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

From issues at jboss.org  Wed Mar 26 11:41:13 2014
From: issues at jboss.org (Scott Marlow (JIRA))
Date: Wed, 26 Mar 2014 11:41:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3150) component upgrade to
 Hibernate next ORM 4.3.x release
In-Reply-To: <JIRA.12535729.1395412681000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12535729.1395412681000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12535729.1395412681000.10657.1395848473750@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-3150?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Scott Marlow updated WFLY-3150:
-------------------------------

    Description: Need the https://hibernate.atlassian.net/browse/HHH-9073 change to pass the TCK.  (was: Need the https://hibernate.atlassian.net/browse/HHH-9073 change.)
       Priority: Blocker  (was: Major)

    
> component upgrade to Hibernate next ORM 4.3.x release 
> ------------------------------------------------------
>
>                 Key: WFLY-3150
>                 URL: https://issues.jboss.org/browse/WFLY-3150
>             Project: WildFly
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: JPA / Hibernate
>    Affects Versions: 8.0.0.Final
>            Reporter: Scott Marlow
>            Assignee: Scott Marlow
>            Priority: Blocker
>             Fix For: 8.0.1.Final
>
>
> Need the https://hibernate.atlassian.net/browse/HHH-9073 change to pass the TCK.

--
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

From issues at jboss.org  Wed Mar 26 12:11:13 2014
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Wed, 26 Mar 2014 12:11:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3170) system properties are
 trim()'d and loose whitespace
In-Reply-To: <JIRA.12536154.1395835526000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12536154.1395835526000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12536154.1395835526000.10764.1395850273526@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-3170?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12956706#comment-12956706 ] 

Brian Stansberry commented on WFLY-3170:
----------------------------------------

Ah, I see. So you a proposing limiting the "no trim" behavior to types that store a string, STRING and the elements in in PROPERTY (perhaps just the value.)

I'd be open to trying this in WF 9, but it should not go into EAP 6 until it has been in the wild for a long time. Not in 6.3.x.
                
> system properties are trim()'d and loose whitespace
> ---------------------------------------------------
>
>                 Key: WFLY-3170
>                 URL: https://issues.jboss.org/browse/WFLY-3170
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>    Affects Versions: 8.0.1.Final
>            Reporter: Tom Fonteyne
>            Assignee: Brian Stansberry
>
> When a system property was defined as:
>   /system-property=foo:add(value="    spaces  ");
> it gets written with the correct spaces around it to the configuration file.
> When the configuration is read the value gets trimmed and the prefix/suffix of spaces is lost.

--
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

From issues at jboss.org  Wed Mar 26 12:19:13 2014
From: issues at jboss.org (Tom Fonteyne (JIRA))
Date: Wed, 26 Mar 2014 12:19:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3170) system properties are
 trim()'d and loose whitespace
In-Reply-To: <JIRA.12536154.1395835526000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12536154.1395835526000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12536154.1395835526000.10790.1395850753103@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-3170?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12956713#comment-12956713 ] 

Tom Fonteyne commented on WFLY-3170:
------------------------------------

yup, that's it indeed.

I'll get a pull request done for WildFly,  but I understand the high risk /postponing for EAP
                
> system properties are trim()'d and loose whitespace
> ---------------------------------------------------
>
>                 Key: WFLY-3170
>                 URL: https://issues.jboss.org/browse/WFLY-3170
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>    Affects Versions: 8.0.1.Final
>            Reporter: Tom Fonteyne
>            Assignee: Brian Stansberry
>
> When a system property was defined as:
>   /system-property=foo:add(value="    spaces  ");
> it gets written with the correct spaces around it to the configuration file.
> When the configuration is read the value gets trimmed and the prefix/suffix of spaces is lost.

--
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

From issues at jboss.org  Wed Mar 26 13:07:12 2014
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 26 Mar 2014 13:07:12 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3164) Create customized Audit Logger
In-Reply-To: <JIRA.12536089.1395789072000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12536089.1395789072000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12536089.1395789072000.11032.1395853632985@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-3164?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan reassigned WFLY-3164:
--------------------------------

    Assignee: Kabir Khan  (was: Brian Stansberry)

    
> Create customized Audit Logger
> ------------------------------
>
>                 Key: WFLY-3164
>                 URL: https://issues.jboss.org/browse/WFLY-3164
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>            Reporter: Kabir Khan
>            Assignee: Kabir Khan
>              Labels: EAP
>             Fix For: 9.0.0.CR1
>
>
> Some users want to have a single line audit log formatter. I think it would be better to have the ability to add your own formatter from a module, something along the lines of:
> {code}
> <custom-formatter code="org.blah.MyCustomFormatter" module="org.blah/mymodule">
>    <property name="layout">...</property>
>    <property name="propB">...</property>
> </custom-formatter>
> {code}
> We'd need an SPI, and a slight reworking of the audit log internals. In any case doing this will put us in a better position to provide the single line logger if this proposal is not acceptable to our users.

--
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

From issues at jboss.org  Wed Mar 26 13:37:13 2014
From: issues at jboss.org (James Perkins (JIRA))
Date: Wed, 26 Mar 2014 13:37:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBLOGGING-102) Messages#getBundle()
 needs to be privileged
In-Reply-To: <JIRA.12536158.1395838258000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12536158.1395838258000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12536158.1395838258000.11089.1395855433332@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBLOGGING-102?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

James Perkins closed JBLOGGING-102.
-----------------------------------

    Fix Version/s: 3.2.0.Beta1
                   3.1.3.GA
                       (was: 3.1.5.GA)
                       (was: 3.2.0.Beta2)
       Resolution: Done


Already fixed 3.1.3.GA
                
> Messages#getBundle() needs to be privileged
> -------------------------------------------
>
>                 Key: JBLOGGING-102
>                 URL: https://issues.jboss.org/browse/JBLOGGING-102
>             Project: JBoss Logging
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 3.1.4.GA, 3.2.0.Beta1
>            Reporter: Ivo Studensky
>            Assignee: James Perkins
>             Fix For: 3.2.0.Beta1, 3.1.3.GA
>
>
> It ({{org.jboss.logging.Messages#getBundle(Class<T> type, Locale locale)}}) calls {{type.getClassLoader()}} which requires privileges when running with Security Manager.

--
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

From issues at jboss.org  Wed Mar 26 13:47:13 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 26 Mar 2014 13:47:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBLOGGING-102) Messages#getBundle()
 needs to be privileged
In-Reply-To: <JIRA.12536158.1395838258000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12536158.1395838258000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12536158.1395838258000.11151.1395856033938@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JBLOGGING-102?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12956751#comment-12956751 ] 

RH Bugzilla Integration commented on JBLOGGING-102:
---------------------------------------------------

James Perkins <jperkins at redhat.com> changed the Status of [bug 1080991|https://bugzilla.redhat.com/show_bug.cgi?id=1080991] from NEW to ASSIGNED
                
> Messages#getBundle() needs to be privileged
> -------------------------------------------
>
>                 Key: JBLOGGING-102
>                 URL: https://issues.jboss.org/browse/JBLOGGING-102
>             Project: JBoss Logging
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 3.1.4.GA, 3.2.0.Beta1
>            Reporter: Ivo Studensky
>            Assignee: James Perkins
>             Fix For: 3.1.3.GA, 3.2.0.Beta1
>
>
> It ({{org.jboss.logging.Messages#getBundle(Class<T> type, Locale locale)}}) calls {{type.getClassLoader()}} which requires privileges when running with Security Manager.

--
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

From issues at jboss.org  Wed Mar 26 13:49:13 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 26 Mar 2014 13:49:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBLOGGING-102) Messages#getBundle()
 needs to be privileged
In-Reply-To: <JIRA.12536158.1395838258000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12536158.1395838258000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12536158.1395838258000.11159.1395856153251@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JBLOGGING-102?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12956753#comment-12956753 ] 

RH Bugzilla Integration commented on JBLOGGING-102:
---------------------------------------------------

Kabir Khan <kkhan at redhat.com> changed the Status of [bug 1080991|https://bugzilla.redhat.com/show_bug.cgi?id=1080991] from ASSIGNED to NEW
                
> Messages#getBundle() needs to be privileged
> -------------------------------------------
>
>                 Key: JBLOGGING-102
>                 URL: https://issues.jboss.org/browse/JBLOGGING-102
>             Project: JBoss Logging
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 3.1.4.GA, 3.2.0.Beta1
>            Reporter: Ivo Studensky
>            Assignee: James Perkins
>             Fix For: 3.1.3.GA, 3.2.0.Beta1
>
>
> It ({{org.jboss.logging.Messages#getBundle(Class<T> type, Locale locale)}}) calls {{type.getClassLoader()}} which requires privileges when running with Security Manager.

--
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

From issues at jboss.org  Wed Mar 26 13:51:13 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 26 Mar 2014 13:51:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBLOGGING-102) Messages#getBundle()
 needs to be privileged
In-Reply-To: <JIRA.12536158.1395838258000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12536158.1395838258000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12536158.1395838258000.11163.1395856273158@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JBLOGGING-102?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12956754#comment-12956754 ] 

RH Bugzilla Integration commented on JBLOGGING-102:
---------------------------------------------------

Kabir Khan <kkhan at redhat.com> changed the Status of [bug 1080991|https://bugzilla.redhat.com/show_bug.cgi?id=1080991] from NEW to ASSIGNED
                
> Messages#getBundle() needs to be privileged
> -------------------------------------------
>
>                 Key: JBLOGGING-102
>                 URL: https://issues.jboss.org/browse/JBLOGGING-102
>             Project: JBoss Logging
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 3.1.4.GA, 3.2.0.Beta1
>            Reporter: Ivo Studensky
>            Assignee: James Perkins
>             Fix For: 3.1.3.GA, 3.2.0.Beta1
>
>
> It ({{org.jboss.logging.Messages#getBundle(Class<T> type, Locale locale)}}) calls {{type.getClassLoader()}} which requires privileges when running with Security Manager.

--
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

From issues at jboss.org  Wed Mar 26 14:45:13 2014
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 26 Mar 2014 14:45:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3164) Create customized Audit Logger
In-Reply-To: <JIRA.12536089.1395789072000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12536089.1395789072000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12536089.1395789072000.11248.1395859513972@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-3164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12956766#comment-12956766 ] 

Kabir Khan commented on WFLY-3164:
----------------------------------

One issue is that we currently only handle two kinds of 'events':
-controller audit events 
-jmx audit events

There is talk of supporting more events like authorization done, connection opened etc. so what we come up with needs to be flexible enough to handle those, and possibly more events like that in the future. The concern being if a user implements a custom formatter for 9.0.0, and we add some more events for 9.1.0 their custom formatter should still work although more events were added for 9.1.0.

A half-baked idea, take with a pinch of salt, is that perhaps for the custom formatter we could have a reference back to one of the WF provided handler types as a 'fallback' for events not handled by the custom formatter.
                
> Create customized Audit Logger
> ------------------------------
>
>                 Key: WFLY-3164
>                 URL: https://issues.jboss.org/browse/WFLY-3164
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>            Reporter: Kabir Khan
>            Assignee: Kabir Khan
>              Labels: EAP
>             Fix For: 9.0.0.CR1
>
>
> Some users want to have a single line audit log formatter. I think it would be better to have the ability to add your own formatter from a module, something along the lines of:
> {code}
> <custom-formatter code="org.blah.MyCustomFormatter" module="org.blah/mymodule">
>    <property name="layout">...</property>
>    <property name="propB">...</property>
> </custom-formatter>
> {code}
> We'd need an SPI, and a slight reworking of the audit log internals. In any case doing this will put us in a better position to provide the single line logger if this proposal is not acceptable to our users.

--
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

From issues at jboss.org  Wed Mar 26 15:55:13 2014
From: issues at jboss.org (Thomas Kriechbaum (JIRA))
Date: Wed, 26 Mar 2014 15:55:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3114) @Resource(lookup="java:...")
 causes an exception for URL resources
In-Reply-To: <JIRA.12534960.1394748695000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534960.1394748695000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534960.1394748695000.11421.1395863713236@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-3114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12956787#comment-12956787 ] 

Thomas Kriechbaum commented on WFLY-3114:
-----------------------------------------

I have tested this scenario with wildfly 8.0.1 SNAPSHOT Build #1040 (25.3.2014  - https://ci.jboss.org/hudson/job/WildFly-latest-master/1040/)
With this build @Resource(lookup="java:...") does not throw an exception any more!

see WFLY-2423 that covers the appropriate fix.
                
>  @Resource(lookup="java:...") causes an exception for URL resources
> -------------------------------------------------------------------
>
>                 Key: WFLY-3114
>                 URL: https://issues.jboss.org/browse/WFLY-3114
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 8.0.0.Final
>            Reporter: Thomas Kriechbaum
>
> When referencing an URL resource via @Resource the lookup-property only supports a valid URLs (e.g. http://www.jboss.org). A JNDI-Name causes an exception (e.g. java:global/url/Configuration or java:app/url/Configuration)
> Issue has been discussed in the user form.
> Note:
> @Resource(name="java:global/url/Configuration") works.
> From my point of view, the javadoc of @Resource is not very easy to understand.

--
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

From issues at jboss.org  Wed Mar 26 15:59:13 2014
From: issues at jboss.org (Thomas Kriechbaum (JIRA))
Date: Wed, 26 Mar 2014 15:59:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3115) JNDI-Names should be
 supported in jboss-specific deployment descriptors for URL resources
In-Reply-To: <JIRA.12534961.1394749579000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534961.1394749579000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534961.1394749579000.11424.1395863953398@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-3115?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12956788#comment-12956788 ] 

Thomas Kriechbaum commented on WFLY-3115:
-----------------------------------------

I have tested this scenario with wildfly 8.0.1 SNAPSHOT Build #1040 (25.3.2014  - https://ci.jboss.org/hudson/job/WildFly-latest-master/1040/)
With this build @Resource(lookup="java:app/url/Configuration") and the following entry in jboss-web.xml resolves an URL defined within standalone.xml

    <resource-ref>
       <res-ref-name>java:app/url/Configuration</res-ref-name>
        <jndi-name>java:jboss/url/Configuration</jndi-name>
     </resource-ref>

see WFLY-2423 that covers the appropriate fix.
                
> JNDI-Names should be supported in jboss-specific deployment descriptors for URL resources
> -----------------------------------------------------------------------------------------
>
>                 Key: WFLY-3115
>                 URL: https://issues.jboss.org/browse/WFLY-3115
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 8.0.0.Final
>            Reporter: Thomas Kriechbaum
>
> When using URL-Resources it would be very helpful, if the jboss-specific deployment descriptor (e.g. jboss-web.xml or jboss-app.xml) allows to reference a JNDI-name. At the moment, only valid URLs are supported.
> When defining JNDI-names (e.g. java:jboss/url/Configuration) instead of concrete URLs, the EAR must not be adopted for each deployment as the specific URL is part of the server configuration (e.g. standalone.xml).
> see proposal by [~sfcoy] at https://community.jboss.org/message/861952#861952

--
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

From issues at jboss.org  Wed Mar 26 16:11:13 2014
From: issues at jboss.org (James Perkins (JIRA))
Date: Wed, 26 Mar 2014 16:11:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3174) Add view of batch jobs with
 ability to view, restart and stop
In-Reply-To: <JIRA.12536214.1395864582192@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12536214.1395864582192@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12536214.1395864582192.11438.1395864673364@jira02.app.mwc.hst.phx2.redhat.com>

James Perkins created WFLY-3174:
-----------------------------------

             Summary: Add view of batch jobs with ability to view, restart and stop
                 Key: WFLY-3174
                 URL: https://issues.jboss.org/browse/WFLY-3174
             Project: WildFly
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: Batch
            Reporter: James Perkins
            Assignee: James Perkins


Currently there is no way to view batch jobs for a deployment with in the batch subsystem management. There should be a way to view the batch jobs that have run on various deployments.

--
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

From issues at jboss.org  Wed Mar 26 16:13:13 2014
From: issues at jboss.org (Stefan Hendriks (JIRA))
Date: Wed, 26 Mar 2014 16:13:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JASSIST-220) Java 8 & Streams/Consumers
 - javassist.bytecode.InterfaceMethodrefInfo cannot be cast to
 javassist.bytecode.MethodrefInfo
In-Reply-To: <JIRA.12536215.1395864695519@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12536215.1395864695519@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12536215.1395864695519.11446.1395864793042@jira02.app.mwc.hst.phx2.redhat.com>

Stefan Hendriks created JASSIST-220:
---------------------------------------

             Summary: Java 8 & Streams/Consumers - javassist.bytecode.InterfaceMethodrefInfo cannot be cast to javassist.bytecode.MethodrefInfo
                 Key: JASSIST-220
                 URL: https://issues.jboss.org/browse/JASSIST-220
             Project: Javassist
          Issue Type: Bug
    Affects Versions: 3.18.1-GA
         Environment: OS X
            Reporter: Stefan Hendriks
            Assignee: Shigeru Chiba


This is a bug report - which also exists on the powermock issue tracker at https://code.google.com/p/powermock/issues/detail?id=490

---
The problem is that an exception is thrown (see below how to reproduce)

Library/Java/JavaVirtualMachines/jdk1.8.0.jdk/Contents/Home/bin/java -ea -Didea.launcher.port=7543 "-Didea.launcher.bin.path=/Applications/IntelliJ IDEA 13.app/bin" -Dfile.encoding=UTF-8 -classpath "/Applications/IntelliJ IDEA 13.app/lib/idea_rt.jar:/Applications/IntelliJ IDEA 13.app/plugins/junit/lib/junit-rt.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0.jdk/Contents/Home/lib/ant-javafx.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0.jdk/Contents/Home/lib/dt.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0.jdk/Contents/Home/lib/javafx-mx.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0.jdk/Contents/Home/lib/jconsole.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0.jdk/Contents/Home/lib/sa-jdi.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0.jdk/Contents/Home/lib/tools.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0.jdk/Contents/Home/jre/lib/charsets.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0.jdk/Contents/Home/jre/lib/deploy.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0.jdk/Contents/Home/jre/lib/htmlconverter.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0.jdk/Contents/Home/jre/lib/javaws.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0.jdk/Contents/Home/jre/lib/jce.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0.jdk/Contents/Home/jre/lib/jfr.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0.jdk/Contents/Home/jre/lib/jfxswt.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0.jdk/Contents/Home/jre/lib/jsse.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0.jdk/Contents/Home/jre/lib/management-agent.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0.jdk/Contents/Home/jre/lib/plugin.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0.jdk/Contents/Home/jre/lib/resources.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0.jdk/Contents/Home/jre/lib/rt.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0.jdk/Contents/Home/jre/lib/ext/cldrdata.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0.jdk/Contents/Home/jre/lib/ext/dnsns.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0.jdk/Contents/Home/jre/lib/ext/jfxrt.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0.jdk/Contents/Home/jre/lib/ext/localedata.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0.jdk/Contents/Home/jre/lib/ext/nashorn.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0.jdk/Contents/Home/jre/lib/ext/sunec.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0.jdk/Contents/Home/jre/lib/ext/sunjce_provider.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0.jdk/Contents/Home/jre/lib/ext/sunpkcs11.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0.jdk/Contents/Home/jre/lib/ext/zipfs.jar:/Users/shendriks/projects/katas/fizzbuzz/java/target/test-classes:/Users/shendriks/projects/katas/fizzbuzz/java/target/classes:/Users/shendriks/.m2/repository/junit/junit/4.8.2/junit-4.8.2.jar:/Users/shendriks/.m2/repository/org/hamcrest/hamcrest-all/1.3/hamcrest-all-1.3.jar:/Users/shendriks/.m2/repository/org/mockito/mockito-all/1.9.5/mockito-all-1.9.5.jar:/Users/shendriks/.m2/repository/org/powermock/powermock-module-junit4/1.5.4/powermock-module-junit4-1.5.4.jar:/Users/shendriks/.m2/repository/org/powermock/powermock-module-junit4-common/1.5.4/powermock-module-junit4-common-1.5.4.jar:/Users/shendriks/.m2/repository/org/powermock/powermock-core/1.5.4/powermock-core-1.5.4.jar:/Users/shendriks/.m2/repository/org/powermock/powermock-reflect/1.5.4/powermock-reflect-1.5.4.jar:/Users/shendriks/.m2/repository/org/objenesis/objenesis/2.1/objenesis-2.1.jar:/Users/shendriks/.m2/repository/org/javassist/javassist/3.18.1-GA/javassist-3.18.1-GA.jar:/Users/shendriks/.m2/repository/org/powermock/powermock-api-mockito/1.5.4/powermock-api-mockito-1.5.4.jar:/Users/shendriks/.m2/repository/org/powermock/powermock-api-support/1.5.4/powermock-api-support-1.5.4.jar" com.intellij.rt.execution.application.AppMain com.intellij.rt.execution.junit.JUnitStarter -ideVersion5 com.fundynamic.katas.FizzBuzzTest
Internal Error occured.
java.lang.IllegalStateException: Failed to transform class with name com.fundynamic.katas.FizzBuzz. Reason: javassist.bytecode.InterfaceMethodrefInfo cannot be cast to javassist.bytecode.MethodrefInfo
	at org.powermock.core.classloader.MockClassLoader.loadMockClass(MockClassLoader.java:214)
	at org.powermock.core.classloader.MockClassLoader.loadModifiedClass(MockClassLoader.java:144)
	at org.powermock.core.classloader.DeferSupportingClassLoader.loadClass(DeferSupportingClassLoader.java:67)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
	at java.lang.Class.forName0(Native Method)
	at java.lang.Class.forName(Class.java:340)
	at sun.reflect.generics.factory.CoreReflectionFactory.makeNamedType(CoreReflectionFactory.java:114)
	at sun.reflect.generics.visitor.Reifier.visitClassTypeSignature(Reifier.java:125)
	at sun.reflect.generics.tree.ClassTypeSignature.accept(ClassTypeSignature.java:49)
	at sun.reflect.annotation.AnnotationParser.parseSig(AnnotationParser.java:439)
	at sun.reflect.annotation.AnnotationParser.parseClassValue(AnnotationParser.java:420)
	at sun.reflect.annotation.AnnotationParser.parseClassArray(AnnotationParser.java:724)
	at sun.reflect.annotation.AnnotationParser.parseArray(AnnotationParser.java:531)
	at sun.reflect.annotation.AnnotationParser.parseMemberValue(AnnotationParser.java:355)
	at sun.reflect.annotation.AnnotationParser.parseAnnotation2(AnnotationParser.java:286)
	at sun.reflect.annotation.AnnotationParser.parseAnnotations2(AnnotationParser.java:120)
	at sun.reflect.annotation.AnnotationParser.parseAnnotations(AnnotationParser.java:72)
	at java.lang.Class.createAnnotationData(Class.java:3410)
	at java.lang.Class.annotationData(Class.java:3399)
	at java.lang.Class.getAnnotations(Class.java:3335)


--
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


From issues at jboss.org  Wed Mar 26 17:22:13 2014
From: issues at jboss.org (Shelly McGowan (JIRA))
Date: Wed, 26 Mar 2014 17:22:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBEE-150) The jboss-jstl-api_1.2_spec
 artifact depends on xalan artifact that is not present in Maven Central
In-Reply-To: <JIRA.12534656.1394540996000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534656.1394540996000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534656.1394540996000.11579.1395868933361@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBEE-150?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Shelly McGowan reassigned JBEE-150:
-----------------------------------

    Assignee: Tomaz Cerar  (was: Shelly McGowan)

    
> The jboss-jstl-api_1.2_spec artifact depends on xalan artifact that is not present in Maven Central
> ---------------------------------------------------------------------------------------------------
>
>                 Key: JBEE-150
>                 URL: https://issues.jboss.org/browse/JBEE-150
>             Project: JBoss JavaEE Spec APIs
>          Issue Type: Bug
>            Reporter: Tomas Repel
>            Assignee: Tomaz Cerar
>
> The org.jboss.spec.javax.servlet.jstl:jboss-jstl-api_1.2_spec:1.1.0.Final depends on xalan:xalan:2.7.1.jbossorg-2 artifact, this one is not present in Maven Central.

--
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

From issues at jboss.org  Wed Mar 26 17:22:13 2014
From: issues at jboss.org (Shelly McGowan (JIRA))
Date: Wed, 26 Mar 2014 17:22:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBEE-148) Unbounded ELEvaluator cache
	can cause OOMEs
In-Reply-To: <JIRA.12533643.1393604030000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12533643.1393604030000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12533643.1393604030000.11586.1395868933768@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBEE-148?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Shelly McGowan reassigned JBEE-148:
-----------------------------------

    Assignee: Tomaz Cerar  (was: Shelly McGowan)

    
> Unbounded ELEvaluator cache can cause OOMEs
> -------------------------------------------
>
>                 Key: JBEE-148
>                 URL: https://issues.jboss.org/browse/JBEE-148
>             Project: JBoss JavaEE Spec APIs
>          Issue Type: Bug
>          Components: jboss-jstl-api
>    Affects Versions: jboss-jstl-api_1.2_spec-1.0.5.Final, jboss-jstl-api_1.2_spec-1.1.0.Final
>            Reporter: Aaron Ogburn
>            Assignee: Tomaz Cerar
>         Attachments: diff.out
>
>
> Unbounded jstl ELEvaluator cache can cause OOMEs.
> Related community issue:
> https://issues.apache.org/bugzilla/show_bug.cgi?id=31789
> This was fixed in 1.0 and 1.1 but never got added to 1.2 so we missed this here too.

--
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

From issues at jboss.org  Wed Mar 26 17:22:13 2014
From: issues at jboss.org (Shelly McGowan (JIRA))
Date: Wed, 26 Mar 2014 17:22:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBEE-149) Patch Taglibs Bug 33934
In-Reply-To: <JIRA.12533663.1393614039000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12533663.1393614039000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12533663.1393614039000.11589.1395868933945@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBEE-149?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Shelly McGowan reassigned JBEE-149:
-----------------------------------

    Assignee: Tomaz Cerar  (was: Shelly McGowan)

    
> Patch Taglibs Bug 33934
> -----------------------
>
>                 Key: JBEE-149
>                 URL: https://issues.jboss.org/browse/JBEE-149
>             Project: JBoss JavaEE Spec APIs
>          Issue Type: Bug
>          Components: jboss-jstl-api
>    Affects Versions: jboss-jstl-api_1.2_spec-1.0.5.Final
>            Reporter: Kevin Formsma
>            Assignee: Tomaz Cerar
>
> Taglibs fixed a bug where SetTag would retain references to the target object, causing pooled SetTag instances to have much higher memory usage when the target object is large. When using many web threads in JBoss 7.2.2, our heap grows due to these objects being associated to pooled SetTags.
> https://issues.apache.org/bugzilla/show_bug.cgi?id=33934
> Can this patch be fixed in the jboss fork of taglibs as well?

--
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

From issues at jboss.org  Wed Mar 26 17:28:12 2014
From: issues at jboss.org (Scott Marlow (JIRA))
Date: Wed, 26 Mar 2014 17:28:12 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3150) component upgrade to
	Hibernate ORM 4.3.5
In-Reply-To: <JIRA.12535729.1395412681000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12535729.1395412681000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12535729.1395412681000.11596.1395869292987@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-3150?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Scott Marlow updated WFLY-3150:
-------------------------------

    Summary: component upgrade to Hibernate ORM 4.3.5  (was: component upgrade to Hibernate next ORM 4.3.x release )

    
> component upgrade to Hibernate ORM 4.3.5
> ----------------------------------------
>
>                 Key: WFLY-3150
>                 URL: https://issues.jboss.org/browse/WFLY-3150
>             Project: WildFly
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: JPA / Hibernate
>    Affects Versions: 8.0.0.Final
>            Reporter: Scott Marlow
>            Assignee: Scott Marlow
>            Priority: Blocker
>             Fix For: 8.0.1.Final
>
>
> Need the https://hibernate.atlassian.net/browse/HHH-9073 change to pass the TCK.

--
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

From issues at jboss.org  Wed Mar 26 18:16:13 2014
From: issues at jboss.org (Paul Ferraro (JIRA))
Date: Wed, 26 Mar 2014 18:16:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3175) Create non-clustered
 implementations of org.wildfly.clustering.api services
In-Reply-To: <JIRA.12536223.1395872156999@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12536223.1395872156999@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12536223.1395872156999.11676.1395872173610@jira02.app.mwc.hst.phx2.redhat.com>

Paul Ferraro created WFLY-3175:
----------------------------------

             Summary: Create non-clustered implementations of org.wildfly.clustering.api services
                 Key: WFLY-3175
                 URL: https://issues.jboss.org/browse/WFLY-3175
             Project: WildFly
          Issue Type: Enhancement
      Security Level: Public (Everyone can see)
          Components: Clustering
    Affects Versions: 8.0.0.Final
            Reporter: Paul Ferraro
            Assignee: Paul Ferraro
             Fix For: 9.0.0.CR1


There are several reasons to do this:
* The implementations are very simple
* An application that uses the public clustering api will can still deploy and function in a non-clustered environment
* We no longer need to use OPTIONAL dependencies in the web and ejb clustering layers

The clustering services would now be installed from a DUP within the infinispan subsystem instead of the jgroups subsystem.
If a cache container defines a transport, then the clustered version of the channel-based service is installed, otherwise the local version will be installed.
If a cache is clustered, then the clustered version of the cache-based services is installed, otherwise a local version will be installed.

--
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

From issues at jboss.org  Wed Mar 26 18:36:13 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 26 Mar 2014 18:36:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBLOGGING-102) Messages#getBundle()
 needs to be privileged
In-Reply-To: <JIRA.12536158.1395838258000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12536158.1395838258000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12536158.1395838258000.11694.1395873373295@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JBLOGGING-102?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12956828#comment-12956828 ] 

RH Bugzilla Integration commented on JBLOGGING-102:
---------------------------------------------------

Kabir Khan <kkhan at redhat.com> changed the Status of [bug 1080991|https://bugzilla.redhat.com/show_bug.cgi?id=1080991] from ASSIGNED to MODIFIED
                
> Messages#getBundle() needs to be privileged
> -------------------------------------------
>
>                 Key: JBLOGGING-102
>                 URL: https://issues.jboss.org/browse/JBLOGGING-102
>             Project: JBoss Logging
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 3.1.4.GA, 3.2.0.Beta1
>            Reporter: Ivo Studensky
>            Assignee: James Perkins
>             Fix For: 3.1.3.GA, 3.2.0.Beta1
>
>
> It ({{org.jboss.logging.Messages#getBundle(Class<T> type, Locale locale)}}) calls {{type.getClassLoader()}} which requires privileges when running with Security Manager.

--
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

From issues at jboss.org  Wed Mar 26 18:40:13 2014
From: issues at jboss.org (Shelly McGowan (JIRA))
Date: Wed, 26 Mar 2014 18:40:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBEE-152) Release JSP 2.3 APIs
In-Reply-To: <JIRA.12535160.1395066857000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12535160.1395066857000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12535160.1395066857000.11699.1395873613591@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JBEE-152?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12956830#comment-12956830 ] 

Shelly McGowan commented on JBEE-152:
-------------------------------------

JSP 2.3 Spec API , v 1.0.1.Final has been released:
https://repository.jboss.org/nexus/content/groups/public/org/jboss/spec/javax/servlet/jsp/jboss-jsp-api_2.3_spec/1.0.1.Final/

This release includes an update to jboss-parent, version 14 and an updated dependency to EL 3.0 API, v 1.0.2.Final.
                
> Release JSP 2.3 APIs 
> ---------------------
>
>                 Key: JBEE-152
>                 URL: https://issues.jboss.org/browse/JBEE-152
>             Project: JBoss JavaEE Spec APIs
>          Issue Type: Bug
>          Components: jboss-jsp-api
>            Reporter: Shelly McGowan
>            Assignee: Shelly McGowan
>
> JSP update needed to include bug fix:
> https://github.com/jboss/jboss-jsp-api_spec/commit/219be2052b0487624f209f16821ae8c4e840a6fc

--
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

From issues at jboss.org  Wed Mar 26 18:42:13 2014
From: issues at jboss.org (Shelly McGowan (JIRA))
Date: Wed, 26 Mar 2014 18:42:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBEE-152) Release JSP 2.3 APIs
In-Reply-To: <JIRA.12535160.1395066857000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12535160.1395066857000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12535160.1395066857000.11701.1395873733026@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBEE-152?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Shelly McGowan resolved JBEE-152.
---------------------------------

    Resolution: Done

    
> Release JSP 2.3 APIs 
> ---------------------
>
>                 Key: JBEE-152
>                 URL: https://issues.jboss.org/browse/JBEE-152
>             Project: JBoss JavaEE Spec APIs
>          Issue Type: Bug
>          Components: jboss-jsp-api
>            Reporter: Shelly McGowan
>            Assignee: Shelly McGowan
>
> JSP update needed to include bug fix:
> https://github.com/jboss/jboss-jsp-api_spec/commit/219be2052b0487624f209f16821ae8c4e840a6fc

--
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

From issues at jboss.org  Wed Mar 26 18:46:14 2014
From: issues at jboss.org (Shelly McGowan (JIRA))
Date: Wed, 26 Mar 2014 18:46:14 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBEE-152) Release JSP 2.3 APIs
In-Reply-To: <JIRA.12535160.1395066857000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12535160.1395066857000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12535160.1395066857000.11727.1395873974853@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBEE-152?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Shelly McGowan updated JBEE-152:
--------------------------------

    Fix Version/s: jboss-jsp-api_2.3_spec-1.0.1.Final

    
> Release JSP 2.3 APIs 
> ---------------------
>
>                 Key: JBEE-152
>                 URL: https://issues.jboss.org/browse/JBEE-152
>             Project: JBoss JavaEE Spec APIs
>          Issue Type: Bug
>          Components: jboss-jsp-api
>            Reporter: Shelly McGowan
>            Assignee: Shelly McGowan
>             Fix For: jboss-jsp-api_2.3_spec-1.0.1.Final
>
>
> JSP update needed to include bug fix:
> https://github.com/jboss/jboss-jsp-api_spec/commit/219be2052b0487624f209f16821ae8c4e840a6fc

--
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

From issues at jboss.org  Wed Mar 26 18:48:12 2014
From: issues at jboss.org (Shelly McGowan (JIRA))
Date: Wed, 26 Mar 2014 18:48:12 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBEE-153) Release EL 3.0 APIs
In-Reply-To: <JIRA.12536225.1395874074151@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12536225.1395874074151@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12536225.1395874074151.11730.1395874092928@jira02.app.mwc.hst.phx2.redhat.com>

Shelly McGowan created JBEE-153:
-----------------------------------

             Summary: Release EL 3.0 APIs
                 Key: JBEE-153
                 URL: https://issues.jboss.org/browse/JBEE-153
             Project: JBoss JavaEE Spec APIs
          Issue Type: Bug
            Reporter: Shelly McGowan
            Assignee: Shelly McGowan
             Fix For: jboss-el-api_3.0_spec-1.0.2.Final


Incorporates pull request:
https://github.com/jboss/jboss-el-api_spec/pull/5

--
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

From issues at jboss.org  Wed Mar 26 18:50:12 2014
From: issues at jboss.org (Shelly McGowan (JIRA))
Date: Wed, 26 Mar 2014 18:50:12 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBEE-153) Release EL 3.0 APIs
In-Reply-To: <JIRA.12536225.1395874074000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12536225.1395874074000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12536225.1395874074000.11732.1395874212920@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBEE-153?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Shelly McGowan resolved JBEE-153.
---------------------------------

    Resolution: Done


JBoss EL 3.0 Spec APIs v 1.0.2.Final has been released:
https://repository.jboss.org/nexus/content/groups/public/org/jboss/spec/javax/el/jboss-el-api_3.0_spec/1.0.2.Final/
                
> Release EL 3.0 APIs
> -------------------
>
>                 Key: JBEE-153
>                 URL: https://issues.jboss.org/browse/JBEE-153
>             Project: JBoss JavaEE Spec APIs
>          Issue Type: Bug
>            Reporter: Shelly McGowan
>            Assignee: Shelly McGowan
>             Fix For: jboss-el-api_3.0_spec-1.0.2.Final
>
>
> Incorporates pull request:
> https://github.com/jboss/jboss-el-api_spec/pull/5

--
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

From issues at jboss.org  Wed Mar 26 19:00:12 2014
From: issues at jboss.org (Shelly McGowan (JIRA))
Date: Wed, 26 Mar 2014 19:00:12 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3123) Update Java EE APIs
In-Reply-To: <JIRA.12535159.1395066619000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12535159.1395066619000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12535159.1395066619000.11752.1395874812939@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-3123?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Shelly McGowan updated WFLY-3123:
---------------------------------

    Git Pull Request: https://github.com/wildfly/wildfly/pull/6034, https://github.com/wildfly/wildfly/pull/6094  (was: https://github.com/wildfly/wildfly/pull/6034)

    
> Update Java EE APIs
> -------------------
>
>                 Key: WFLY-3123
>                 URL: https://issues.jboss.org/browse/WFLY-3123
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: EE
>            Reporter: Shelly McGowan
>            Assignee: Shelly McGowan
>             Fix For: 8.0.1.Final
>
>
> There were a few bug fix releases of the JBoss Java EE API projects to include in WildFly.

--
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

From issues at jboss.org  Wed Mar 26 19:04:12 2014
From: issues at jboss.org (Tomaz Cerar (JIRA))
Date: Wed, 26 Mar 2014 19:04:12 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBEE-146) jboss-el-api_2.2_spec
 1.0.2.Final cannot access public methods from non-public classes
In-Reply-To: <JIRA.12525180.1384462560000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12525180.1384462560000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12525180.1384462560000.11760.1395875052905@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JBEE-146?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12956841#comment-12956841 ] 

Tomaz Cerar commented on JBEE-146:
----------------------------------

I send PR that syncs/rebases our code with upstream. 
                
> jboss-el-api_2.2_spec 1.0.2.Final cannot access public methods from non-public classes
> --------------------------------------------------------------------------------------
>
>                 Key: JBEE-146
>                 URL: https://issues.jboss.org/browse/JBEE-146
>             Project: JBoss JavaEE Spec APIs
>          Issue Type: Bug
>            Reporter: Farah Juma
>            Assignee: Farah Juma
>             Fix For: jboss-el-api_2.2_spec-1.0.3.Final, jboss-el-api_3.0_spec-1.0.0.Final
>
>
> When accessing a public method of a non-public class via EL that implements a public interface or has a public superclass, the following exception occurs:
> {code}java.lang.IllegalAccessException: Class javax.el.BeanELResolver can not access a member of class X with modifiers "public" 
> {code}
> See https://bugzilla.redhat.com/show_bug.cgi?id=1029387 for more 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

From issues at jboss.org  Wed Mar 26 19:06:13 2014
From: issues at jboss.org (Tomaz Cerar (JIRA))
Date: Wed, 26 Mar 2014 19:06:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-519) JSR-341 EL 3.0 support
In-Reply-To: <JIRA.12485400.1361487486000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12485400.1361487486000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12485400.1361487486000.11767.1395875173035@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-519?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12956842#comment-12956842 ] 

Tomaz Cerar commented on WFLY-519:
----------------------------------

As an update, I sent https://github.com/wildfly/wildfly/pull/6094 to do hackish API / Impl split as otherwise our version of EL API was never used and with it none of our optimizations / caching.
This hack should hold us until we decide if we should fork RI or move to Tomcat impl.
                
> JSR-341 EL 3.0 support
> ----------------------
>
>                 Key: WFLY-519
>                 URL: https://issues.jboss.org/browse/WFLY-519
>             Project: WildFly
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Web (Undertow)
>            Reporter: David Lloyd
>            Assignee: Remy Maucherat
>             Fix For: 8.0.0.Beta1
>
>
> Per Java EE 7 spec, update to EL 3.0 API and implementation.

--
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

From issues at jboss.org  Wed Mar 26 19:10:12 2014
From: issues at jboss.org (Tomaz Cerar (JIRA))
Date: Wed, 26 Mar 2014 19:10:12 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBEE-133) Expression Language 3.0
	(JSR-341) APIs
In-Reply-To: <JIRA.12487467.1363659115000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12487467.1363659115000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12487467.1363659115000.11775.1395875412979@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JBEE-133?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12956843#comment-12956843 ] 

Tomaz Cerar commented on JBEE-133:
----------------------------------

https://github.com/wildfly/wildfly/pull/6094 splits API & impl in hackish way for now.
But without it we cannot utilize our own fixes / optimizations in API modules.
                
> Expression Language 3.0 (JSR-341) APIs
> --------------------------------------
>
>                 Key: JBEE-133
>                 URL: https://issues.jboss.org/browse/JBEE-133
>             Project: JBoss JavaEE Spec APIs
>          Issue Type: Sub-task
>          Components: jboss-javaee-specs
>            Reporter: Shelly McGowan
>            Assignee: Remy Maucherat
>             Fix For: JavaEE 7 Spec APIs 1.0.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

From issues at jboss.org  Wed Mar 26 19:16:13 2014
From: issues at jboss.org (James Livingston (JIRA))
Date: Wed, 26 Mar 2014 19:16:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1013) Can't set attribute "suffix"
 on web access-log
In-Reply-To: <JIRA.12471975.1344415283000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12471975.1344415283000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12471975.1344415283000.11780.1395875773943@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-1013?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

James Livingston resolved WFLY-1013.
------------------------------------

    Fix Version/s: 8.0.1.Final
       Resolution: Done

    
> Can't set attribute "suffix" on web access-log
> ----------------------------------------------
>
>                 Key: WFLY-1013
>                 URL: https://issues.jboss.org/browse/WFLY-1013
>             Project: WildFly
>          Issue Type: Enhancement
>      Security Level: Public(Everyone can see) 
>          Components: Web (Undertow)
>         Environment: N/A
>            Reporter: Ed Roberts
>            Assignee: James Livingston
>              Labels: logging, suffix, web
>             Fix For: 8.0.1.Final
>
>
> In JBoss 5.x you used to be able to specify a suffix attribute value for the JBossWeb access log file, which would be appended to generated log file names.
> In JBoss 7.x you can only specify a prefix. For the logging handlers you can specify both a prefix and a suffix, which is inconsistent.
> Please add the suffix attribute to the access-log element within the parent virtual-server element of the web subsystem xml configuration.

--
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

From issues at jboss.org  Wed Mar 26 19:16:14 2014
From: issues at jboss.org (James Livingston (JIRA))
Date: Wed, 26 Mar 2014 19:16:14 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1013) Can't set attribute "suffix"
 on web access-log
In-Reply-To: <JIRA.12471975.1344415283000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12471975.1344415283000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12471975.1344415283000.11783.1395875774149@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1013?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12956844#comment-12956844 ] 

James Livingston commented on WFLY-1013:
----------------------------------------

This is done for 8.0.1
                
> Can't set attribute "suffix" on web access-log
> ----------------------------------------------
>
>                 Key: WFLY-1013
>                 URL: https://issues.jboss.org/browse/WFLY-1013
>             Project: WildFly
>          Issue Type: Enhancement
>      Security Level: Public(Everyone can see) 
>          Components: Web (Undertow)
>         Environment: N/A
>            Reporter: Ed Roberts
>            Assignee: James Livingston
>              Labels: logging, suffix, web
>             Fix For: 8.0.1.Final
>
>
> In JBoss 5.x you used to be able to specify a suffix attribute value for the JBossWeb access log file, which would be appended to generated log file names.
> In JBoss 7.x you can only specify a prefix. For the logging handlers you can specify both a prefix and a suffix, which is inconsistent.
> Please add the suffix attribute to the access-log element within the parent virtual-server element of the web subsystem xml configuration.

--
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

From issues at jboss.org  Wed Mar 26 19:20:13 2014
From: issues at jboss.org (James Livingston (JIRA))
Date: Wed, 26 Mar 2014 19:20:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3165) Upgrade Undertow to
	1.0.3.Final
In-Reply-To: <JIRA.12536095.1395806492000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12536095.1395806492000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12536095.1395806492000.11788.1395876013203@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-3165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12956845#comment-12956845 ] 

James Livingston commented on WFLY-3165:
----------------------------------------

Kabir merged https://github.com/wildfly/wildfly/commit/126abf7297ce85714b51c5fbd011574de9412f80 which contains the Undertow upgrade as well as WFLY-1013
                
> Upgrade Undertow to 1.0.3.Final 
> --------------------------------
>
>                 Key: WFLY-3165
>                 URL: https://issues.jboss.org/browse/WFLY-3165
>             Project: WildFly
>          Issue Type: Component  Upgrade
>      Security Level: Public(Everyone can see) 
>          Components: Web (Undertow)
>    Affects Versions: 8.0.0.Final
>            Reporter: Cristiano Andrade
>            Assignee: Stuart Douglas
>             Fix For: 8.0.1.Final
>
>
> added support HTTPS in reverse proxy

--
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

From issues at jboss.org  Wed Mar 26 19:56:13 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 26 Mar 2014 19:56:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-939) Class-Path manifest entries
 for WARs-in-EAR not handled properly
In-Reply-To: <JIRA.12490006.1366613438000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12490006.1366613438000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12490006.1366613438000.11814.1395878173326@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-939?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12956849#comment-12956849 ] 

RH Bugzilla Integration commented on WFLY-939:
----------------------------------------------

James Livingston <jlivings at redhat.com> changed the Status of [bug 955818|https://bugzilla.redhat.com/show_bug.cgi?id=955818] from NEW to POST
                
> Class-Path manifest entries for WARs-in-EAR not handled properly
> ----------------------------------------------------------------
>
>                 Key: WFLY-939
>                 URL: https://issues.jboss.org/browse/WFLY-939
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Server
>            Reporter: James Livingston
>            Assignee: Stuart Douglas
>             Fix For: 8.0.0.Alpha1
>
>
> ManifestClassPathProcessor handles the processing of Class-Path entries in deployments. The handling of those entries in sub-deployments is broken.
> https://github.com/doctau/examples/tree/master/war-manifest-classpath builds an EAR containing a utility JAR and two WARs, where both WARs refer to the jar via Class-Path manifest headers. The jar is not in the EAR's library directory nor in application.xml
> The resulting module setup will result in the jar being added to the first WAR's module, and the remaining WAR(s) depending on a separate "jar classloader". All WARs should depend on the single shared jar classloader.
> When ManifestClassPathProcessor.handlingExistingClassPathEntry() runs for the first war, it will call createAdditionalModule(), which calls createResourceRoot(). The "deploymentUnit.addToAttachmentList(Attachments.RESOURCE_ROOTS, resourceRoot)" adds it to the resource roots for that WAR.
> When handlingExistingClassPathEntry() runs for the second (and subsequent) WAR, it will already be in the additionalModules list, so "target.addToAttachmentList(Attachments.CLASS_PATH_ENTRIES, moduleSpecification.getModuleIdentifier())" gets run.
> I believe the step of adding it to the CLASS_PATH_ENTRIES attachment needs to happen on the first WAR (so it is added as a module dependency), and it should not be added to the DU RESOURCE_ROOTS so it is not in the WAR's own classloader.

--
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

From issues at jboss.org  Wed Mar 26 21:04:12 2014
From: issues at jboss.org (Desmond Silveira (JIRA))
Date: Wed, 26 Mar 2014 21:04:12 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-458) Drools lock in
 StatelessKnowledgeSessionImpl.
In-Reply-To: <JIRA.12536231.1395882246595@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12536231.1395882246595@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12536231.1395882246595.11854.1395882252886@jira02.app.mwc.hst.phx2.redhat.com>

Desmond Silveira created DROOLS-458:
---------------------------------------

             Summary: Drools lock in StatelessKnowledgeSessionImpl.
                 Key: DROOLS-458
                 URL: https://issues.jboss.org/browse/DROOLS-458
             Project: Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions: 6.0.1.Final
         Environment: Tomcat 7
            Reporter: Desmond Silveira
            Assignee: Mark Proctor


My Tomcat HTTP BIO connector threads (129 of them) got BLOCKED in my production Tomcat 7 instance because Drool 6.0.1 wasn't releasing a lock.

Here is a snippet of the thread dump:

{noformat}
"http-bio-172.16.216.19-80-exec-37513" - Thread t at 6245360
   java.lang.Thread.State: BLOCKED
	at org.drools.core.runtime.process.ProcessRuntimeFactory.getProcessRuntimeFactoryService(ProcessRuntimeFactory.java:20)
	- waiting to lock <219dcd77> (a java.lang.Class) owned by "http-bio-172.16.216.19-80-exec-37511" t at 6245358
	at org.drools.core.runtime.process.ProcessRuntimeFactory.newProcessRuntime(ProcessRuntimeFactory.java:12)
	at org.drools.core.common.AbstractWorkingMemory.createProcessRuntime(AbstractWorkingMemory.java:405)
	at org.drools.core.common.AbstractWorkingMemory.setKnowledgeRuntime(AbstractWorkingMemory.java:1770)
	at org.drools.core.impl.StatefulKnowledgeSessionImpl.<init>(StatefulKnowledgeSessionImpl.java:125)
	at org.drools.core.impl.StatelessKnowledgeSessionImpl.newWorkingMemory(StatelessKnowledgeSessionImpl.java:139)
	at org.drools.core.impl.StatelessKnowledgeSessionImpl.execute(StatelessKnowledgeSessionImpl.java:397)
	at com.local.lds.RuleEngineBean.applyKnowledge(RuleEngineBean.java:50)
	at com.local.lds.LdsBean.search(LdsBean.java:200)
	at com.local.lds.servlet.SearchServlet.doGet(SearchServlet.java:55)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:621)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:722)
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:305)
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
	at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:224)
	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:169)
	at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:472)
	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:168)
	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:98)
	at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:927)
	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118)
	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:407)
	at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:987)
	at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:579)
	at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:307)
	- locked <3575a054> (a org.apache.tomcat.util.net.SocketWrapper)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
	at java.lang.Thread.run(Unknown Source)

   Locked ownable synchronizers:
	- locked <719df963> (a java.util.concurrent.ThreadPoolExecutor$Worker)

"http-bio-172.16.216.19-80-exec-37511" - Thread t at 6245358
   java.lang.Thread.State: RUNNABLE
	at org.kie.internal.utils.ServiceRegistryImpl.addDefault(ServiceRegistryImpl.java:212)
	- locked <3d710637> (a org.kie.internal.utils.ServiceRegistryImpl)
	at org.kie.internal.utils.ServiceRegistryImpl.addDefault(ServiceRegistryImpl.java:207)
	- locked <3d710637> (a org.kie.internal.utils.ServiceRegistryImpl)
	at org.drools.core.runtime.process.ProcessRuntimeFactory.loadProvider(ProcessRuntimeFactory.java:27)
	at org.drools.core.runtime.process.ProcessRuntimeFactory.getProcessRuntimeFactoryService(ProcessRuntimeFactory.java:21)
	- locked <219dcd77> (a java.lang.Class)
	at org.drools.core.runtime.process.ProcessRuntimeFactory.newProcessRuntime(ProcessRuntimeFactory.java:12)
	at org.drools.core.common.AbstractWorkingMemory.createProcessRuntime(AbstractWorkingMemory.java:405)
	at org.drools.core.common.AbstractWorkingMemory.setKnowledgeRuntime(AbstractWorkingMemory.java:1770)
	at org.drools.core.impl.StatefulKnowledgeSessionImpl.<init>(StatefulKnowledgeSessionImpl.java:125)
	at org.drools.core.impl.StatelessKnowledgeSessionImpl.newWorkingMemory(StatelessKnowledgeSessionImpl.java:139)
	at org.drools.core.impl.StatelessKnowledgeSessionImpl.execute(StatelessKnowledgeSessionImpl.java:397)
	at com.local.lds.RuleEngineBean.applyKnowledge(RuleEngineBean.java:50)
	at com.local.lds.LdsBean.search(LdsBean.java:200)
	at com.local.lds.servlet.SearchServlet.doGet(SearchServlet.java:55)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:621)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:722)
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:305)
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
	at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:224)
	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:169)
	at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:472)
	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:168)
	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:98)
	at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:927)
	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118)
	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:407)
	at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:987)
	at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:579)
	at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:307)
	- locked <474f2464> (a org.apache.tomcat.util.net.SocketWrapper)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
	at java.lang.Thread.run(Unknown Source)

   Locked ownable synchronizers:
	- locked <339f344e> (a java.util.concurrent.ThreadPoolExecutor$Worker)

"http-bio-172.16.216.19-80-exec-37447" - Thread t at 6233953
   java.lang.Thread.State: BLOCKED
	at org.drools.core.common.ProjectClassLoader.loadClass(ProjectClassLoader.java:82)
	- waiting to lock <555896b3> (a org.drools.core.common.ProjectClassLoader) owned by "http-bio-172.16.216.19-80-exec-37519" t at 6245366
	at java.lang.ClassLoader.loadClass(Unknown Source)
	at org.drools.core.base.ClassFieldAccessorCache.getClass(ClassFieldAccessorCache.java:122)
	at org.drools.core.base.ClassFieldAccessorCache.getClassObjectType(ClassFieldAccessorCache.java:46)
	at org.drools.core.reteoo.ClassObjectTypeConf.<init>(ClassObjectTypeConf.java:89)
	at org.drools.core.common.ObjectTypeConfigurationRegistry.getObjectTypeConf(ObjectTypeConfigurationRegistry.java:71)
	at org.drools.core.common.AbstractWorkingMemory.initInitialFact(AbstractWorkingMemory.java:385)
	at org.drools.core.common.AbstractWorkingMemory.<init>(AbstractWorkingMemory.java:378)
	at org.drools.core.common.AbstractWorkingMemory.<init>(AbstractWorkingMemory.java:261)
	at org.drools.core.common.PhreakWorkingMemoryFactory.createWorkingMemory(PhreakWorkingMemoryFactory.java:15)
	at org.drools.core.impl.StatelessKnowledgeSessionImpl.newWorkingMemory(StatelessKnowledgeSessionImpl.java:134)
	at org.drools.core.impl.StatelessKnowledgeSessionImpl.execute(StatelessKnowledgeSessionImpl.java:397)
	at com.local.lds.RuleEngineBean.applyKnowledge(RuleEngineBean.java:50)
	at com.local.lds.LdsBean.search(LdsBean.java:200)
	at com.local.lds.servlet.SearchServlet.doGet(SearchServlet.java:55)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:621)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:722)
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:305)
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
	at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:224)
	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:169)
	at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:472)
	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:168)
	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:98)
	at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:927)
	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118)
	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:407)
	at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:987)
	at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:579)
	at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:307)
	- locked <57e6b780> (a org.apache.tomcat.util.net.SocketWrapper)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
	at java.lang.Thread.run(Unknown Source)

   Locked ownable synchronizers:
	- locked <726294fc> (a java.util.concurrent.ThreadPoolExecutor$Worker)

"http-bio-172.16.216.19-80-exec-37519" - Thread t at 6245366
   java.lang.Thread.State: RUNNABLE
	at java.lang.ClassLoader.findLoadedClass0(Native Method)
	at java.lang.ClassLoader.findLoadedClass(Unknown Source)
	at java.lang.ClassLoader.loadClass(Unknown Source)
	- locked <555896b3> (a org.drools.core.common.ProjectClassLoader)
	at org.drools.core.common.ProjectClassLoader.internalLoadClass(ProjectClassLoader.java:99)
	at org.drools.core.common.ProjectClassLoader.loadClass(ProjectClassLoader.java:82)
	- locked <555896b3> (a org.drools.core.common.ProjectClassLoader)
	at java.lang.ClassLoader.loadClass(Unknown Source)
	at org.drools.core.base.ClassFieldAccessorCache.getClass(ClassFieldAccessorCache.java:122)
	at org.drools.core.base.ClassFieldAccessorCache.getClassObjectType(ClassFieldAccessorCache.java:46)
	at org.drools.core.reteoo.ClassObjectTypeConf.<init>(ClassObjectTypeConf.java:89)
	at org.drools.core.common.ObjectTypeConfigurationRegistry.getObjectTypeConf(ObjectTypeConfigurationRegistry.java:71)
	at org.drools.core.common.NamedEntryPoint.insert(NamedEntryPoint.java:164)
	at org.drools.core.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:1148)
	at org.drools.core.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:1092)
	at org.drools.core.impl.StatefulKnowledgeSessionImpl.insert(StatefulKnowledgeSessionImpl.java:308)
	at org.drools.core.impl.StatelessKnowledgeSessionImpl.execute(StatelessKnowledgeSessionImpl.java:400)
	at com.local.lds.RuleEngineBean.applyKnowledge(RuleEngineBean.java:50)
	at com.local.lds.LdsBean.search(LdsBean.java:200)
	at com.local.lds.servlet.SearchServlet.doGet(SearchServlet.java:55)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:621)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:722)
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:305)
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
	at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:224)
	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:169)
	at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:472)
	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:168)
	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:98)
	at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:927)
	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118)
	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:407)
	at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:987)
	at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:579)
	at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:307)
	- locked <43c2901> (a org.apache.tomcat.util.net.SocketWrapper)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
	at java.lang.Thread.run(Unknown Source)

   Locked ownable synchronizers:
	- locked <88f8fa9> (a java.util.concurrent.ThreadPoolExecutor$Worker)
{noformat}

Here is the code that I use to call Drools:

{code:java}
    public static Collection<ResultSet> applyRule(String rule,
            KieBase kb, Collection<ResultSet> resultSets, SearchParameters params) {
        try {
            if (kb == null) {
                return resultSets;
            }
            StatelessKieSession ksession = kb.newStatelessKieSession();
            ksession.setGlobal(OUTPUT, new ArrayList<>());
            Collection<Object> collection = new ArrayList<Object>(resultSets);
            collection.add(params);
            ksession.execute(collection);
            return (Collection<ResultSet>) ksession.getGlobals().get(OUTPUT);
        } catch (ConsequenceException e) {
            LOG.error("Error in rule: " + rule + " " + e.getRule(), e);
            throw e;
        } catch (RuntimeException e) {
            LOG.error("Error in rule: " + rule, e);
            throw e;
        }
    }
{code}

--
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

From issues at jboss.org  Wed Mar 26 21:28:12 2014
From: issues at jboss.org (Shelly McGowan (JIRA))
Date: Wed, 26 Mar 2014 21:28:12 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBEE-153) Release EL 3.0 APIs
In-Reply-To: <JIRA.12536225.1395874074000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12536225.1395874074000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12536225.1395874074000.11859.1395883692877@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBEE-153?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Shelly McGowan reopened JBEE-153:
---------------------------------


    
> Release EL 3.0 APIs
> -------------------
>
>                 Key: JBEE-153
>                 URL: https://issues.jboss.org/browse/JBEE-153
>             Project: JBoss JavaEE Spec APIs
>          Issue Type: Bug
>            Reporter: Shelly McGowan
>            Assignee: Shelly McGowan
>             Fix For: jboss-el-api_3.0_spec-1.0.2.Final
>
>
> Incorporates pull request:
> https://github.com/jboss/jboss-el-api_spec/pull/5

--
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

From issues at jboss.org  Wed Mar 26 21:30:12 2014
From: issues at jboss.org (Shelly McGowan (JIRA))
Date: Wed, 26 Mar 2014 21:30:12 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBEE-153) Release EL 3.0 APIs
In-Reply-To: <JIRA.12536225.1395874074000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12536225.1395874074000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12536225.1395874074000.11861.1395883812911@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JBEE-153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12956856#comment-12956856 ] 

Shelly McGowan commented on JBEE-153:
-------------------------------------

There was an issue found once this release was tested with WildFly Pull Request:
https://github.com/wildfly/wildfly/pull/6094

Reopening to add the fix:
https://github.com/jboss/jboss-el-api_spec/pull/7
                
> Release EL 3.0 APIs
> -------------------
>
>                 Key: JBEE-153
>                 URL: https://issues.jboss.org/browse/JBEE-153
>             Project: JBoss JavaEE Spec APIs
>          Issue Type: Bug
>            Reporter: Shelly McGowan
>            Assignee: Shelly McGowan
>             Fix For: jboss-el-api_3.0_spec-1.0.2.Final
>
>
> Incorporates pull request:
> https://github.com/jboss/jboss-el-api_spec/pull/5

--
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

From issues at jboss.org  Wed Mar 26 21:30:13 2014
From: issues at jboss.org (Shelly McGowan (JIRA))
Date: Wed, 26 Mar 2014 21:30:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBEE-153) Release EL 3.0 APIs
In-Reply-To: <JIRA.12536225.1395874074000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12536225.1395874074000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12536225.1395874074000.11863.1395883813018@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBEE-153?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Shelly McGowan updated JBEE-153:
--------------------------------

    Fix Version/s: jboss-el-api_3.0_spec-1.0.3.Final
                       (was: jboss-el-api_3.0_spec-1.0.2.Final)

    
> Release EL 3.0 APIs
> -------------------
>
>                 Key: JBEE-153
>                 URL: https://issues.jboss.org/browse/JBEE-153
>             Project: JBoss JavaEE Spec APIs
>          Issue Type: Bug
>            Reporter: Shelly McGowan
>            Assignee: Shelly McGowan
>             Fix For: jboss-el-api_3.0_spec-1.0.3.Final
>
>
> Incorporates pull request:
> https://github.com/jboss/jboss-el-api_spec/pull/5

--
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

From issues at jboss.org  Wed Mar 26 22:20:12 2014
From: issues at jboss.org (Jason Kim (JIRA))
Date: Wed, 26 Mar 2014 22:20:12 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3176) Certain file types are
 filtered out and excluded upon deployment
In-Reply-To: <JIRA.12536233.1395886723932@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12536233.1395886723932@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12536233.1395886723932.11883.1395886812968@jira02.app.mwc.hst.phx2.redhat.com>

Jason Kim created WFLY-3176:
-------------------------------

             Summary: Certain file types are filtered out and excluded upon deployment
                 Key: WFLY-3176
                 URL: https://issues.jboss.org/browse/WFLY-3176
             Project: WildFly
          Issue Type: Bug
      Security Level: Public (Everyone can see)
         Environment: Windows 7 x64
            Reporter: Jason Kim


In Wildfly 8.0.0, it was possible to deploy a web application with *.less files as well as other custom extensions, but with the latest build (Build #1041), when I  try to deploy an html page that references *.less files, the *.less files are unavailable and I get a 404 error. 

The same site worked on 8.0.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

From issues at jboss.org  Wed Mar 26 22:20:13 2014
From: issues at jboss.org (Shelly McGowan (JIRA))
Date: Wed, 26 Mar 2014 22:20:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBEE-153) Release EL 3.0 APIs
In-Reply-To: <JIRA.12536225.1395874074000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12536225.1395874074000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12536225.1395874074000.11885.1395886813056@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JBEE-153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12956861#comment-12956861 ] 

Shelly McGowan commented on JBEE-153:
-------------------------------------

JBoss EL 3.0 Spec APIs v 1.0.3.Final has been released:
https://repository.jboss.org/nexus/content/groups/public/org/jboss/spec/javax/el/jboss-el-api_3.0_spec/1.0.3.Final/
This release includes PR #7 to fix the missing resource.
                
> Release EL 3.0 APIs
> -------------------
>
>                 Key: JBEE-153
>                 URL: https://issues.jboss.org/browse/JBEE-153
>             Project: JBoss JavaEE Spec APIs
>          Issue Type: Bug
>            Reporter: Shelly McGowan
>            Assignee: Shelly McGowan
>             Fix For: jboss-el-api_3.0_spec-1.0.3.Final
>
>
> Incorporates pull request:
> https://github.com/jboss/jboss-el-api_spec/pull/5

--
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

From issues at jboss.org  Wed Mar 26 22:20:13 2014
From: issues at jboss.org (Shelly McGowan (JIRA))
Date: Wed, 26 Mar 2014 22:20:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBEE-153) Release EL 3.0 APIs
In-Reply-To: <JIRA.12536225.1395874074000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12536225.1395874074000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12536225.1395874074000.11888.1395886813176@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBEE-153?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Shelly McGowan resolved JBEE-153.
---------------------------------

    Resolution: Done

    
> Release EL 3.0 APIs
> -------------------
>
>                 Key: JBEE-153
>                 URL: https://issues.jboss.org/browse/JBEE-153
>             Project: JBoss JavaEE Spec APIs
>          Issue Type: Bug
>            Reporter: Shelly McGowan
>            Assignee: Shelly McGowan
>             Fix For: jboss-el-api_3.0_spec-1.0.3.Final
>
>
> Incorporates pull request:
> https://github.com/jboss/jboss-el-api_spec/pull/5

--
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

From issues at jboss.org  Wed Mar 26 22:26:12 2014
From: issues at jboss.org (Jason Kim (JIRA))
Date: Wed, 26 Mar 2014 22:26:12 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3176) Certain file types are
 filtered out and excluded upon deployment
In-Reply-To: <JIRA.12536233.1395886723000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12536233.1395886723000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12536233.1395886723000.11893.1395887172853@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-3176?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Kim updated WFLY-3176:
----------------------------

    Description: 
In Wildfly 8.0.0, it was possible to deploy a web application with *.less files as well as other custom extensions, but with the latest build (Build #1041), when I  try to deploy an html page that references *.less files, the *.less files are unavailable and I get a 404 error. 

The same site along with the references to the *.less files worked on 8.0.0 FInal. I tried with other file types, just making up extensions, and Wildfly would not serve the files, instead it would return aa 404 when trying to access them.

  was:
In Wildfly 8.0.0, it was possible to deploy a web application with *.less files as well as other custom extensions, but with the latest build (Build #1041), when I  try to deploy an html page that references *.less files, the *.less files are unavailable and I get a 404 error. 

The same site worked on 8.0.0 FInal.


    
> Certain file types are filtered out and excluded upon deployment
> ----------------------------------------------------------------
>
>                 Key: WFLY-3176
>                 URL: https://issues.jboss.org/browse/WFLY-3176
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>         Environment: Windows 7 x64
>            Reporter: Jason Kim
>
> In Wildfly 8.0.0, it was possible to deploy a web application with *.less files as well as other custom extensions, but with the latest build (Build #1041), when I  try to deploy an html page that references *.less files, the *.less files are unavailable and I get a 404 error. 
> The same site along with the references to the *.less files worked on 8.0.0 FInal. I tried with other file types, just making up extensions, and Wildfly would not serve the files, instead it would return aa 404 when trying to access them.

--
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

From issues at jboss.org  Wed Mar 26 22:52:12 2014
From: issues at jboss.org (Stuart Douglas (JIRA))
Date: Wed, 26 Mar 2014 22:52:12 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3176) Certain file types are
 filtered out and excluded upon deployment
In-Reply-To: <JIRA.12536233.1395886723000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12536233.1395886723000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12536233.1395886723000.11903.1395888732923@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-3176?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stuart Douglas resolved WFLY-3176.
----------------------------------

    Resolution: Done


Should be fixed by the inclusion of Undertow 1.0.3
                
> Certain file types are filtered out and excluded upon deployment
> ----------------------------------------------------------------
>
>                 Key: WFLY-3176
>                 URL: https://issues.jboss.org/browse/WFLY-3176
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>         Environment: Windows 7 x64
>            Reporter: Jason Kim
>
> In Wildfly 8.0.0, it was possible to deploy a web application with *.less files as well as other custom extensions, but with the latest build (Build #1041), when I  try to deploy an html page that references *.less files, the *.less files are unavailable and I get a 404 error. 
> The same site along with the references to the *.less files worked on 8.0.0 FInal. I tried with other file types, just making up extensions, and Wildfly would not serve the files, instead it would return aa 404 when trying to access them.

--
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

From issues at jboss.org  Wed Mar 26 23:14:13 2014
From: issues at jboss.org (Stuart Douglas (JIRA))
Date: Wed, 26 Mar 2014 23:14:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3168) Wrong Mojarra version on Linux
In-Reply-To: <JIRA.12536142.1395831654000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12536142.1395831654000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12536142.1395831654000.11927.1395890053019@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-3168?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12956868#comment-12956868 ] 

Stuart Douglas commented on WFLY-3168:
--------------------------------------

Any chance you installed WF from RPM (or .deb), and there is something screwy in the rpm version? 

Either way this is not our bug, but should be filed against whoever provides the packages, we don't provided different downloads for Linux and Windows, just the single zip file.
                
> Wrong Mojarra version on Linux
> ------------------------------
>
>                 Key: WFLY-3168
>                 URL: https://issues.jboss.org/browse/WFLY-3168
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JSF
>    Affects Versions: 8.0.0.Final
>         Environment: Linux
>            Reporter: Thorsten Richter
>            Assignee: Farah Juma
>              Labels: jsf, linux, mojarra, viewscoped
>
> We had a bug on Linux that the @ViewScoped annotation didn't work for AJAX requests. We found out, that the Mojarra version is causing the problem. On our Windows development machines everything worked fine, but on the Linux production server @ViewScoped didn't work.
> So we searched for the root cause and found out, that the Mojarra version was different on Linux.
> The Linux package of Wildfly contains an older version of Mojarra (2.1.7) within the modules/com/sun/jsf-impl folder that needs to be deleted.
> The Windows package of Wildfly doesn't even contain a com folder within modules.
> So maybe the whole com folder on Linux is wrong?

--
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

From issues at jboss.org  Wed Mar 26 23:14:13 2014
From: issues at jboss.org (Stuart Douglas (JIRA))
Date: Wed, 26 Mar 2014 23:14:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3168) Wrong Mojarra version on Linux
In-Reply-To: <JIRA.12536142.1395831654000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12536142.1395831654000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12536142.1395831654000.11930.1395890053205@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-3168?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stuart Douglas resolved WFLY-3168.
----------------------------------

    Resolution: Rejected

    
> Wrong Mojarra version on Linux
> ------------------------------
>
>                 Key: WFLY-3168
>                 URL: https://issues.jboss.org/browse/WFLY-3168
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JSF
>    Affects Versions: 8.0.0.Final
>         Environment: Linux
>            Reporter: Thorsten Richter
>            Assignee: Farah Juma
>              Labels: jsf, linux, mojarra, viewscoped
>
> We had a bug on Linux that the @ViewScoped annotation didn't work for AJAX requests. We found out, that the Mojarra version is causing the problem. On our Windows development machines everything worked fine, but on the Linux production server @ViewScoped didn't work.
> So we searched for the root cause and found out, that the Mojarra version was different on Linux.
> The Linux package of Wildfly contains an older version of Mojarra (2.1.7) within the modules/com/sun/jsf-impl folder that needs to be deleted.
> The Windows package of Wildfly doesn't even contain a com folder within modules.
> So maybe the whole com folder on Linux is wrong?

--
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

From issues at jboss.org  Thu Mar 27 01:20:13 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 27 Mar 2014 01:20:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2655) Show warning for JDBC drivers
 as modules with no driver
In-Reply-To: <JIRA.12527980.1387160517000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12527980.1387160517000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12527980.1387160517000.11980.1395897613022@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2655?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12956878#comment-12956878 ] 

RH Bugzilla Integration commented on WFLY-2655:
-----------------------------------------------

James Livingston <jlivings at redhat.com> changed the Status of [bug 1043339|https://bugzilla.redhat.com/show_bug.cgi?id=1043339] from NEW to ASSIGNED
                
> Show warning for JDBC drivers as modules with no driver
> -------------------------------------------------------
>
>                 Key: WFLY-2655
>                 URL: https://issues.jboss.org/browse/WFLY-2655
>             Project: WildFly
>          Issue Type: Enhancement
>      Security Level: Public(Everyone can see) 
>          Components: JCA
>    Affects Versions: 8.0.0.Beta1
>            Reporter: James Livingston
>            Assignee: Jeff Zhang
>             Fix For: 8.0.1.Final
>
>
> If a <driver> if configured with no <driver-class>, it will attempt to locate the driver(s) via the service loader which should find all JDBC4-compliant drivers.
> When you install a non JDBC4-complicant driver as a module and no <driver-class>, the driver will not be installed. That is expected but emitting a warning that no-drivers could be found in the module would be useful to help users troubleshoot the problem.

--
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

From issues at jboss.org  Thu Mar 27 02:32:13 2014
From: issues at jboss.org (Ivo Studensky (JIRA))
Date: Thu, 27 Mar 2014 02:32:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBLOGGING-102) Messages#getBundle()
 needs to be privileged
In-Reply-To: <JIRA.12536158.1395838258000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12536158.1395838258000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12536158.1395838258000.11995.1395901933036@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JBLOGGING-102?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12956882#comment-12956882 ] 

Ivo Studensky commented on JBLOGGING-102:
-----------------------------------------

I can't see any fix at [1] [2] [3] [4] [5] [6] [7] [8]. Am I looking at wrong source code?

[1] https://github.com/jboss-logging/jboss-logging/blob/3.1/src/main/java/org/jboss/logging/Messages.java#L66
[2] https://github.com/jboss-logging/jboss-logging/blob/3.1/src/main/java/org/jboss/logging/Messages.java#L71
[3] https://github.com/jboss-logging/jboss-logging/blob/3.1/src/main/java/org/jboss/logging/Messages.java#L76
[4] https://github.com/jboss-logging/jboss-logging/blob/3.1/src/main/java/org/jboss/logging/Messages.java#L81
[5] https://github.com/jboss-logging/jboss-logging/blob/master/src/main/java/org/jboss/logging/Messages.java#L66
[6] https://github.com/jboss-logging/jboss-logging/blob/master/src/main/java/org/jboss/logging/Messages.java#L71
[7] https://github.com/jboss-logging/jboss-logging/blob/master/src/main/java/org/jboss/logging/Messages.java#L76
[8] https://github.com/jboss-logging/jboss-logging/blob/master/src/main/java/org/jboss/logging/Messages.java#L81
                
> Messages#getBundle() needs to be privileged
> -------------------------------------------
>
>                 Key: JBLOGGING-102
>                 URL: https://issues.jboss.org/browse/JBLOGGING-102
>             Project: JBoss Logging
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 3.1.4.GA, 3.2.0.Beta1
>            Reporter: Ivo Studensky
>            Assignee: James Perkins
>             Fix For: 3.1.3.GA, 3.2.0.Beta1
>
>
> It ({{org.jboss.logging.Messages#getBundle(Class<T> type, Locale locale)}}) calls {{type.getClassLoader()}} which requires privileges when running with Security Manager.

--
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

From issues at jboss.org  Thu Mar 27 02:42:12 2014
From: issues at jboss.org (Christian Bauer (JIRA))
Date: Thu, 27 Mar 2014 02:42:12 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3105) Container-managed EXTENDED
 persistence context is always joined with transaction even if
 UNSYNCHRONIZED
In-Reply-To: <JIRA.12534789.1394637157000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534789.1394637157000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534789.1394637157000.12021.1395902532943@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-3105?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12956883#comment-12956883 ] 

Christian Bauer commented on WFLY-3105:
---------------------------------------

Thanks Scott, tested and works now.

                
> Container-managed EXTENDED persistence context is always joined with transaction even if UNSYNCHRONIZED
> -------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-3105
>                 URL: https://issues.jboss.org/browse/WFLY-3105
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JPA / Hibernate
>    Affects Versions: 8.0.0.Final
>            Reporter: Christian Bauer
>            Assignee: Scott Marlow
>             Fix For: 8.0.1.Final
>
>
> https://github.com/weld/wildfly/blob/master/testsuite/integration/basic/src/test/java/org/jboss/as/test/integration/jpa/transaction/UnsynchronizedSFSB.jav
> Change this test to {code}@PersistenceContext(type = EXTENDED, synchronization = UNSYNCHRONIZED){code} and it will break. 
> Looks like an extended PC is always joined to the transaction and flushed on commit, the unsynchronized mode is ignored. From what I can see this is not specified and indeed would make the whole new UNSYNCHRONIZED feature kind of pointless. It's primary use case is propagation of unflushed/unsynchronized extended PC from a SFSB to other beans while keeping transactions intact.

--
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

From issues at jboss.org  Thu Mar 27 04:36:14 2014
From: issues at jboss.org (Bela Ban (JIRA))
Date: Thu, 27 Mar 2014 04:36:14 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1729) Implement a SASL AuthToken
In-Reply-To: <JIRA.12518030.1383663486000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12518030.1383663486000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12518030.1383663486000.12259.1395909374078@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JGRP-1729?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban resolved JGRP-1729.
----------------------------

    Resolution: Done

    
> Implement a SASL AuthToken
> --------------------------
>
>                 Key: JGRP-1729
>                 URL: https://issues.jboss.org/browse/JGRP-1729
>             Project: JGroups
>          Issue Type: Feature Request
>            Reporter: Tristan Tarrant
>            Assignee: Tristan Tarrant
>              Labels: 630, security
>             Fix For: 3.5
>
>
> Implementing a SASL AuthToken will give us the ability to use whatever SASL mechs are offered by the underlying platform without introducing new dependencies. It would also replace many of the currently provided AuthToken implementations (MD5, X509, Krb5) with a more secure, flexible implementation (e.g. safe from replay attacks)

--
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

From issues at jboss.org  Thu Mar 27 05:26:13 2014
From: issues at jboss.org (Ravshan Samandarov (JIRA))
Date: Thu, 27 Mar 2014 05:26:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3177) wrong placement of
 jipijapa-eclipselink-1.0.1.Final.jar file inside bundle. Eclipselink logger
 to work properly it should be moved from org/eclipse/persistence/main to
 org/jipijapa/eclipselink/main and configured in xml file accordingly.
In-Reply-To: <JIRA.12536256.1395912264511@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12536256.1395912264511@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12536256.1395912264511.12434.1395912373160@jira02.app.mwc.hst.phx2.redhat.com>

Ravshan Samandarov created WFLY-3177:
----------------------------------------

             Summary: wrong placement of jipijapa-eclipselink-1.0.1.Final.jar file inside bundle. Eclipselink logger to work properly it should be moved from org/eclipse/persistence/main to org/jipijapa/eclipselink/main and configured in xml file accordingly.
                 Key: WFLY-3177
                 URL: https://issues.jboss.org/browse/WFLY-3177
             Project: WildFly
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
            Reporter: Ravshan Samandarov




--
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

From issues at jboss.org  Thu Mar 27 06:00:16 2014
From: issues at jboss.org (Frank Hempel (JIRA))
Date: Thu, 27 Mar 2014 06:00:16 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3087) Websocket
 NullPointerException on
 io.undertow.websockets.jsr.annotated.AnnotatedEndpoint$AnnotatedEndpointFrameHandler.handleBinaryMessage(AnnotatedEndpoint.java:373)
In-Reply-To: <JIRA.12534452.1394215322000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534452.1394215322000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534452.1394215322000.12517.1395914416097@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-3087?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12956923#comment-12956923 ] 

Frank Hempel commented on WFLY-3087:
------------------------------------

It still bails out with the same traceback. I used the last snapshot, which is build #1043 (26.03.2014 18:41:28). Undertow is there included in version 1.0.3. 
But that is no suprise, current master of undertow shows that the code is still the same (https://github.com/undertow-io/undertow/blob/master/websockets-jsr/src/main/java/io/undertow/websockets/jsr/annotated/AnnotatedEndpoint.java). It probably should better be reported in the undertow tracker. I'm not sure whether you could just move this ticket to the undertow's jira instance or whether it should be opened there separately.
                
> Websocket NullPointerException on io.undertow.websockets.jsr.annotated.AnnotatedEndpoint$AnnotatedEndpointFrameHandler.handleBinaryMessage(AnnotatedEndpoint.java:373)
> ----------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-3087
>                 URL: https://issues.jboss.org/browse/WFLY-3087
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web (Undertow)
>    Affects Versions: 8.0.0.CR1
>         Environment: windows server 2008
>            Reporter: Admin FlirtyMob
>            Assignee: Stuart Douglas
>             Fix For: 8.0.1.Final
>
>
> 2014-03-07 17:10:49,208 ERROR [org.xnio.listener] (default I/O-1) XNIO001007: A channel event listener threw an exception: java.lang.NullPointerException
> at io.undertow.websockets.jsr.annotated.AnnotatedEndpoint$AnnotatedEndpointFrameHandler.handleBinaryMessage(AnnotatedEndpoint.java:373)
> at io.undertow.websockets.jsr.annotated.AnnotatedEndpoint$AnnotatedEndpointFrameHandler.access$1100(AnnotatedEndpoint.java:126)
> at io.undertow.websockets.jsr.annotated.AnnotatedEndpoint$AnnotatedEndpointFrameHandler$6.complete(AnnotatedEndpoint.java:332)
> at io.undertow.websockets.jsr.annotated.AnnotatedEndpoint$AnnotatedEndpointFrameHandler$6.complete(AnnotatedEndpoint.java:329)
> at io.undertow.websockets.core.BufferedBinaryMessage.read(BufferedBinaryMessage.java:76)
> at io.undertow.websockets.jsr.annotated.AnnotatedEndpoint$AnnotatedEndpointFrameHandler.onBinary(AnnotatedEndpoint.java:329)
> at io.undertow.websockets.core.AbstractReceiveListener.handleEvent(AbstractReceiveListener.java:24)
> at io.undertow.websockets.core.AbstractReceiveListener.handleEvent(AbstractReceiveListener.java:15)
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) [xnio-api-3.2.0.Beta4.jar:3.2.0.Beta4]
> at io.undertow.server.protocol.framed.AbstractFramedChannel$FrameReadListener.handleEvent(AbstractFramedChannel.java:615)
> at io.undertow.server.protocol.framed.AbstractFramedChannel$FrameReadListener.handleEvent(AbstractFramedChannel.java:601)
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) [xnio-api-3.2.0.Beta4.jar:3.2.0.Beta4]
> at org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66) [xnio-api-3.2.0.Beta4.jar:3.2.0.Beta4]
> at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:87) [xnio-nio-3.2.0.Beta4.jar:3.2.0.Beta4]
> at org.xnio.nio.WorkerThread.run(WorkerThread.java:531) [xnio-nio-3.2.0.Beta4.jar:3.2.0.Beta4]

--
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

From issues at jboss.org  Thu Mar 27 06:08:13 2014
From: issues at jboss.org (Frank Hempel (JIRA))
Date: Thu, 27 Mar 2014 06:08:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3109) CloseReason always null for
 WebSocket onClose methods
In-Reply-To: <JIRA.12534874.1394711228000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534874.1394711228000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534874.1394711228000.12539.1395914893008@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-3109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12956926#comment-12956926 ] 

Frank Hempel commented on WFLY-3109:
------------------------------------

I would just like to confirm this fact. I also see this "reason-always-null"-behaviour on WildFly 8.0.0.Final as well as the lates Snapshot (build #1043 (26.03.2014 18:41:28)).
                
> CloseReason always null for WebSocket onClose methods
> -----------------------------------------------------
>
>                 Key: WFLY-3109
>                 URL: https://issues.jboss.org/browse/WFLY-3109
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 8.0.0.Final
>         Environment: WildFly 8.0.0.Final on Windows 7 Pro (64 bits) with JDK 7.0u51 (64 bits)
>            Reporter: Tom Tom
>
> The onClose method of the websocket endpoints does not receive valid CloseReason, it is always null.
> With GlassFish 4.0, the CloseReason is not null and correctly reflects the code and message used to close the wensocket from the client side.
> Simplified code sample of the endpoint:
> @ServerEndpoint(value = "/test", configurator = MyConfigurator.class)
> public class MyEndpoint {
>    // onOpen, onMessage and onError, LOGGER are omitted
>     @OnClose
>     public void onClose(Session session, CloseReason reason) {
>         LOGGER.debug("onClose(sessionId={}, reason={})", session.getId(), reason);
>     }
> }

--
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

From issues at jboss.org  Thu Mar 27 06:08:13 2014
From: issues at jboss.org (Frank Hempel (JIRA))
Date: Thu, 27 Mar 2014 06:08:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3109) CloseReason always null for
 WebSocket onClose methods
In-Reply-To: <JIRA.12534874.1394711228000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534874.1394711228000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534874.1394711228000.12551.1395914893669@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-3109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12956926#comment-12956926 ] 

Frank Hempel edited comment on WFLY-3109 at 3/27/14 6:07 AM:
-------------------------------------------------------------

I would just like to confirm this fact. I also see this "reason-always-null"-behaviour on WildFly 8.0.0.Final as well as the latest Snapshot (build #1043 (26.03.2014 18:41:28)).
                
      was (Author: struppimoppi):
    I would just like to confirm this fact. I also see this "reason-always-null"-behaviour on WildFly 8.0.0.Final as well as the lates Snapshot (build #1043 (26.03.2014 18:41:28)).
                  
> CloseReason always null for WebSocket onClose methods
> -----------------------------------------------------
>
>                 Key: WFLY-3109
>                 URL: https://issues.jboss.org/browse/WFLY-3109
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 8.0.0.Final
>         Environment: WildFly 8.0.0.Final on Windows 7 Pro (64 bits) with JDK 7.0u51 (64 bits)
>            Reporter: Tom Tom
>
> The onClose method of the websocket endpoints does not receive valid CloseReason, it is always null.
> With GlassFish 4.0, the CloseReason is not null and correctly reflects the code and message used to close the wensocket from the client side.
> Simplified code sample of the endpoint:
> @ServerEndpoint(value = "/test", configurator = MyConfigurator.class)
> public class MyEndpoint {
>    // onOpen, onMessage and onError, LOGGER are omitted
>     @OnClose
>     public void onClose(Session session, CloseReason reason) {
>         LOGGER.debug("onClose(sessionId={}, reason={})", session.getId(), reason);
>     }
> }

--
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

From issues at jboss.org  Thu Mar 27 06:10:12 2014
From: issues at jboss.org (Chao Wang (JIRA))
Date: Thu, 27 Mar 2014 06:10:12 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (SECURITY-811) NullPointerException in
 DeploymentRoleToRolesMappingProvider
In-Reply-To: <JIRA.12536263.1395914971710@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12536263.1395914971710@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12536263.1395914971710.12554.1395915012883@jira02.app.mwc.hst.phx2.redhat.com>

Chao Wang created SECURITY-811:
----------------------------------

             Summary: NullPointerException in DeploymentRoleToRolesMappingProvider
                 Key: SECURITY-811
                 URL: https://issues.jboss.org/browse/SECURITY-811
             Project: PicketBox 
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: JBossSX
    Affects Versions: JBossSecurity_2.0.8.Final
            Reporter: Chao Wang
            Assignee: Chao Wang
            Priority: Minor


{code:title=DeploymentRoleToRolesMappingProvider.java|borderStyle=solid}
RoleGroup assignedRoles = (SimpleRoleGroup)contextMap.get(SecurityConstants.ROLES_IDENTIFIER);
for (Role r: assignedRoles.getRoles()) {
{code}

A null value of assignedRoles causes NullPointerException on server if user have not input username / passoword yet

--
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

From issues at jboss.org  Thu Mar 27 06:12:13 2014
From: issues at jboss.org (Tomaz Cerar (JIRA))
Date: Thu, 27 Mar 2014 06:12:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3087) Websocket
 NullPointerException on
 io.undertow.websockets.jsr.annotated.AnnotatedEndpoint$AnnotatedEndpointFrameHandler.handleBinaryMessage(AnnotatedEndpoint.java:373)
In-Reply-To: <JIRA.12534452.1394215322000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534452.1394215322000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534452.1394215322000.12561.1395915133205@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-3087?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tomaz Cerar reopened WFLY-3087:
-------------------------------


    
> Websocket NullPointerException on io.undertow.websockets.jsr.annotated.AnnotatedEndpoint$AnnotatedEndpointFrameHandler.handleBinaryMessage(AnnotatedEndpoint.java:373)
> ----------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-3087
>                 URL: https://issues.jboss.org/browse/WFLY-3087
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web (Undertow)
>    Affects Versions: 8.0.0.CR1
>         Environment: windows server 2008
>            Reporter: Admin FlirtyMob
>            Assignee: Stuart Douglas
>             Fix For: 8.0.1.Final
>
>
> 2014-03-07 17:10:49,208 ERROR [org.xnio.listener] (default I/O-1) XNIO001007: A channel event listener threw an exception: java.lang.NullPointerException
> at io.undertow.websockets.jsr.annotated.AnnotatedEndpoint$AnnotatedEndpointFrameHandler.handleBinaryMessage(AnnotatedEndpoint.java:373)
> at io.undertow.websockets.jsr.annotated.AnnotatedEndpoint$AnnotatedEndpointFrameHandler.access$1100(AnnotatedEndpoint.java:126)
> at io.undertow.websockets.jsr.annotated.AnnotatedEndpoint$AnnotatedEndpointFrameHandler$6.complete(AnnotatedEndpoint.java:332)
> at io.undertow.websockets.jsr.annotated.AnnotatedEndpoint$AnnotatedEndpointFrameHandler$6.complete(AnnotatedEndpoint.java:329)
> at io.undertow.websockets.core.BufferedBinaryMessage.read(BufferedBinaryMessage.java:76)
> at io.undertow.websockets.jsr.annotated.AnnotatedEndpoint$AnnotatedEndpointFrameHandler.onBinary(AnnotatedEndpoint.java:329)
> at io.undertow.websockets.core.AbstractReceiveListener.handleEvent(AbstractReceiveListener.java:24)
> at io.undertow.websockets.core.AbstractReceiveListener.handleEvent(AbstractReceiveListener.java:15)
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) [xnio-api-3.2.0.Beta4.jar:3.2.0.Beta4]
> at io.undertow.server.protocol.framed.AbstractFramedChannel$FrameReadListener.handleEvent(AbstractFramedChannel.java:615)
> at io.undertow.server.protocol.framed.AbstractFramedChannel$FrameReadListener.handleEvent(AbstractFramedChannel.java:601)
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) [xnio-api-3.2.0.Beta4.jar:3.2.0.Beta4]
> at org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66) [xnio-api-3.2.0.Beta4.jar:3.2.0.Beta4]
> at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:87) [xnio-nio-3.2.0.Beta4.jar:3.2.0.Beta4]
> at org.xnio.nio.WorkerThread.run(WorkerThread.java:531) [xnio-nio-3.2.0.Beta4.jar:3.2.0.Beta4]

--
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

From issues at jboss.org  Thu Mar 27 06:54:13 2014
From: issues at jboss.org (Chao Wang (JIRA))
Date: Thu, 27 Mar 2014 06:54:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (SECURITY-811) NullPointerException in
 DeploymentRoleToRolesMappingProvider
In-Reply-To: <JIRA.12536263.1395914971000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12536263.1395914971000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12536263.1395914971000.12666.1395917653987@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/SECURITY-811?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Chao Wang updated SECURITY-811:
-------------------------------

    Attachment: SECURITY-811-picketbox.patch

    
> NullPointerException in DeploymentRoleToRolesMappingProvider
> ------------------------------------------------------------
>
>                 Key: SECURITY-811
>                 URL: https://issues.jboss.org/browse/SECURITY-811
>             Project: PicketBox 
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JBossSX
>    Affects Versions: JBossSecurity_2.0.8.Final
>            Reporter: Chao Wang
>            Assignee: Chao Wang
>            Priority: Minor
>         Attachments: SECURITY-811-picketbox.patch, SECURITY-811.patch
>
>
> {code:title=DeploymentRoleToRolesMappingProvider.java|borderStyle=solid}
> RoleGroup assignedRoles = (SimpleRoleGroup)contextMap.get(SecurityConstants.ROLES_IDENTIFIER);
> for (Role r: assignedRoles.getRoles()) {
> {code}
> A null value of assignedRoles causes NullPointerException on server if user have not input username / passoword yet

--
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

From issues at jboss.org  Thu Mar 27 07:00:13 2014
From: issues at jboss.org (Bela Ban (JIRA))
Date: Thu, 27 Mar 2014 07:00:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1814) No physical address for X;
 dropping message
In-Reply-To: <JIRA.12536183.1395845002000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12536183.1395845002000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12536183.1395845002000.12692.1395918013682@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JGRP-1814?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12956948#comment-12956948 ] 

Bela Ban commented on JGRP-1814:
--------------------------------

The MBR_LEFT event has not been implemented: instead, we close all connections to *members which left*, and the xmit-task will remove them after {{conn_close_timeout}} ms (default: 5s).

The sentence "members which left" means *current members which are not in the new view*, e.g. between views V1=\{A,B,C\} and V2=\{A,C,D\}, member B left. However, if we have a connection to P, P will not get closed as it is *not* in the current view V1.
                
> No physical address for X; dropping message
> -------------------------------------------
>
>                 Key: JGRP-1814
>                 URL: https://issues.jboss.org/browse/JGRP-1814
>             Project: JGroups
>          Issue Type: Enhancement
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 3.5
>
>
> When we have view \{A,B\} and B leaves, then the following happens in UNICAST3:
> * B sends a LEAVE-REQ to A
> * A sends a LEAVE-RSP to B
> * Because the LEAVE-RSP is reliable, A keeps sending the LEAVE-RSP to B until it receives an ACK for the LEAVE-RSP
> * However, when B receives the LEAVE-RSP, it marks its connection to be acked, which means that when the next retransmission kicks in, an ACK for the LEAVE-RSP will be sent back to A
> * Before this happens, B leaves: the ACK is never sent to A
> * A keeps resending the LEAVE-RSP until {{max_retransmit_time}} (default=60s) elapses and the connection is closed. However, the connection is only closed after another 60s (default for {{conn_close_timeout}}).
> * Because the reaper removes all entries of {{logical_addr_cache}} before that happens, we're seeing the above warnings
> SOLUTION:
> # Send LEAVE-RSP unreliable. This bypasses UNICAST3 altogether. The leaver won't block forever if the LEAVE-RSP message is dropped, but only for 3 x {{GMS.leave_timeout}} ms
> # Also add a MBR_LEFT event which is sent up and down the stack by GMS when a member left *gracefully*. This allows UNICAST3 to close the connection to a given member *immediately*, stopping unneeded retransmissions to members which left.

--
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

From issues at jboss.org  Thu Mar 27 07:04:13 2014
From: issues at jboss.org (Eduardo Martins (JIRA))
Date: Thu, 27 Mar 2014 07:04:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3114) @Resource(lookup="java:...")
 causes an exception for URL resources
In-Reply-To: <JIRA.12534960.1394748695000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534960.1394748695000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534960.1394748695000.12697.1395918253500@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-3114?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Eduardo Martins closed WFLY-3114.
---------------------------------

      Assignee: Eduardo Martins
    Resolution: Out of Date

    
>  @Resource(lookup="java:...") causes an exception for URL resources
> -------------------------------------------------------------------
>
>                 Key: WFLY-3114
>                 URL: https://issues.jboss.org/browse/WFLY-3114
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 8.0.0.Final
>            Reporter: Thomas Kriechbaum
>            Assignee: Eduardo Martins
>
> When referencing an URL resource via @Resource the lookup-property only supports a valid URLs (e.g. http://www.jboss.org). A JNDI-Name causes an exception (e.g. java:global/url/Configuration or java:app/url/Configuration)
> Issue has been discussed in the user form.
> Note:
> @Resource(name="java:global/url/Configuration") works.
> From my point of view, the javadoc of @Resource is not very easy to understand.

--
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

From issues at jboss.org  Thu Mar 27 07:04:13 2014
From: issues at jboss.org (Eduardo Martins (JIRA))
Date: Thu, 27 Mar 2014 07:04:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3115) JNDI-Names should be
 supported in jboss-specific deployment descriptors for URL resources
In-Reply-To: <JIRA.12534961.1394749579000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534961.1394749579000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534961.1394749579000.12701.1395918253684@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-3115?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Eduardo Martins closed WFLY-3115.
---------------------------------

      Assignee: Eduardo Martins
    Resolution: Out of Date

    
> JNDI-Names should be supported in jboss-specific deployment descriptors for URL resources
> -----------------------------------------------------------------------------------------
>
>                 Key: WFLY-3115
>                 URL: https://issues.jboss.org/browse/WFLY-3115
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 8.0.0.Final
>            Reporter: Thomas Kriechbaum
>            Assignee: Eduardo Martins
>
> When using URL-Resources it would be very helpful, if the jboss-specific deployment descriptor (e.g. jboss-web.xml or jboss-app.xml) allows to reference a JNDI-name. At the moment, only valid URLs are supported.
> When defining JNDI-names (e.g. java:jboss/url/Configuration) instead of concrete URLs, the EAR must not be adopted for each deployment as the specific URL is part of the server configuration (e.g. standalone.xml).
> see proposal by [~sfcoy] at https://community.jboss.org/message/861952#861952

--
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

From issues at jboss.org  Thu Mar 27 08:12:13 2014
From: issues at jboss.org (Bela Ban (JIRA))
Date: Thu, 27 Mar 2014 08:12:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1814) No physical address for X;
 dropping message
In-Reply-To: <JIRA.12536183.1395845002000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12536183.1395845002000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12536183.1395845002000.12825.1395922333149@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JGRP-1814?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban resolved JGRP-1814.
----------------------------

    Resolution: Done

    
> No physical address for X; dropping message
> -------------------------------------------
>
>                 Key: JGRP-1814
>                 URL: https://issues.jboss.org/browse/JGRP-1814
>             Project: JGroups
>          Issue Type: Enhancement
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 3.5
>
>
> When we have view \{A,B\} and B leaves, then the following happens in UNICAST3:
> * B sends a LEAVE-REQ to A
> * A sends a LEAVE-RSP to B
> * Because the LEAVE-RSP is reliable, A keeps sending the LEAVE-RSP to B until it receives an ACK for the LEAVE-RSP
> * However, when B receives the LEAVE-RSP, it marks its connection to be acked, which means that when the next retransmission kicks in, an ACK for the LEAVE-RSP will be sent back to A
> * Before this happens, B leaves: the ACK is never sent to A
> * A keeps resending the LEAVE-RSP until {{max_retransmit_time}} (default=60s) elapses and the connection is closed. However, the connection is only closed after another 60s (default for {{conn_close_timeout}}).
> * Because the reaper removes all entries of {{logical_addr_cache}} before that happens, we're seeing the above warnings
> SOLUTION:
> # Send LEAVE-RSP unreliable. This bypasses UNICAST3 altogether. The leaver won't block forever if the LEAVE-RSP message is dropped, but only for 3 x {{GMS.leave_timeout}} ms
> # Also add a MBR_LEFT event which is sent up and down the stack by GMS when a member left *gracefully*. This allows UNICAST3 to close the connection to a given member *immediately*, stopping unneeded retransmissions to members which left.

--
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

From issues at jboss.org  Thu Mar 27 08:14:12 2014
From: issues at jboss.org (Bela Ban (JIRA))
Date: Thu, 27 Mar 2014 08:14:12 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1815) TP: sending a message to a
 non-existent physical address takes too much time
In-Reply-To: <JIRA.12536191.1395847224000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12536191.1395847224000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12536191.1395847224000.12829.1395922452983@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JGRP-1815?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban resolved JGRP-1815.
----------------------------

    Resolution: Done

    
> TP: sending a message to a non-existent physical address takes too much time
> ----------------------------------------------------------------------------
>
>                 Key: JGRP-1815
>                 URL: https://issues.jboss.org/browse/JGRP-1815
>             Project: JGroups
>          Issue Type: Enhancement
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 3.5
>
>
> When sending a message in the transport, e.g. a message batch, and one or more destinations have no physical addresses in {{logical_addr_cache}}, then we loop {{physical_addr_max_fetch_attempts}} (default: 3) times and also sleep a random number of ms (in range [1..500]). 
> This delays the sending of other messages in the same batch, or of other messages in general. Also, if TransferQueueBundler is used, the transfer queue might get filled, so other sender threads are blocked.
> SOLUTION:
> * Remove the loop when sending a message: if the physical address for a message is not found, simply send a discovery request and drop the message
> * The discovery request needs to be sent on a separate thread, as calling {{up(Event)}} directly could also delay the sending of the message or message batch.
> * JGRP-1814 will also help, as connections to left members are closed, and therefore not finding a physical address for a destination should be rare

--
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

From issues at jboss.org  Thu Mar 27 08:14:13 2014
From: issues at jboss.org (Scott Marlow (JIRA))
Date: Thu, 27 Mar 2014 08:14:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3105) Container-managed EXTENDED
 persistence context is always joined with transaction even if
 UNSYNCHRONIZED
In-Reply-To: <JIRA.12534789.1394637157000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534789.1394637157000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534789.1394637157000.12832.1395922453176@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-3105?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Scott Marlow closed WFLY-3105.
------------------------------



Thanks for reporting this Christian!
                
> Container-managed EXTENDED persistence context is always joined with transaction even if UNSYNCHRONIZED
> -------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-3105
>                 URL: https://issues.jboss.org/browse/WFLY-3105
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JPA / Hibernate
>    Affects Versions: 8.0.0.Final
>            Reporter: Christian Bauer
>            Assignee: Scott Marlow
>             Fix For: 8.0.1.Final
>
>
> https://github.com/weld/wildfly/blob/master/testsuite/integration/basic/src/test/java/org/jboss/as/test/integration/jpa/transaction/UnsynchronizedSFSB.jav
> Change this test to {code}@PersistenceContext(type = EXTENDED, synchronization = UNSYNCHRONIZED){code} and it will break. 
> Looks like an extended PC is always joined to the transaction and flushed on commit, the unsynchronized mode is ignored. From what I can see this is not specified and indeed would make the whole new UNSYNCHRONIZED feature kind of pointless. It's primary use case is propagation of unflushed/unsynchronized extended PC from a SFSB to other beans while keeping transactions intact.

--
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

From issues at jboss.org  Thu Mar 27 08:16:15 2014
From: issues at jboss.org (Scott Marlow (JIRA))
Date: Thu, 27 Mar 2014 08:16:15 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3105) Container-managed EXTENDED
 persistence context is always joined with transaction even if
 UNSYNCHRONIZED
In-Reply-To: <JIRA.12534789.1394637157000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534789.1394637157000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534789.1394637157000.12838.1395922575208@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-3105?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12956971#comment-12956971 ] 

Scott Marlow commented on WFLY-3105:
------------------------------------

And for verifying the fix as well!  :)
                
> Container-managed EXTENDED persistence context is always joined with transaction even if UNSYNCHRONIZED
> -------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-3105
>                 URL: https://issues.jboss.org/browse/WFLY-3105
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JPA / Hibernate
>    Affects Versions: 8.0.0.Final
>            Reporter: Christian Bauer
>            Assignee: Scott Marlow
>             Fix For: 8.0.1.Final
>
>
> https://github.com/weld/wildfly/blob/master/testsuite/integration/basic/src/test/java/org/jboss/as/test/integration/jpa/transaction/UnsynchronizedSFSB.jav
> Change this test to {code}@PersistenceContext(type = EXTENDED, synchronization = UNSYNCHRONIZED){code} and it will break. 
> Looks like an extended PC is always joined to the transaction and flushed on commit, the unsynchronized mode is ignored. From what I can see this is not specified and indeed would make the whole new UNSYNCHRONIZED feature kind of pointless. It's primary use case is propagation of unflushed/unsynchronized extended PC from a SFSB to other beans while keeping transactions intact.

--
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

From issues at jboss.org  Thu Mar 27 08:22:13 2014
From: issues at jboss.org (Bela Ban (JIRA))
Date: Thu, 27 Mar 2014 08:22:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1721) AUTH and ENCRYPT protocols
 configured with plain text passwords
In-Reply-To: <JIRA.12508425.1382426440000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508425.1382426440000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508425.1382426440000.12859.1395922933065@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JGRP-1721?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12956973#comment-12956973 ] 

Bela Ban commented on JGRP-1721:
--------------------------------

I'm going to close this as the keystore name and password can be injected programmatically
                
> AUTH and ENCRYPT protocols configured with plain text passwords
> ---------------------------------------------------------------
>
>                 Key: JGRP-1721
>                 URL: https://issues.jboss.org/browse/JGRP-1721
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.4
>            Reporter: Martin Gencur
>            Assignee: Bela Ban
>             Fix For: 3.5
>
>
> The following parameters of AUTH protocol are stored as plain text:
> * keystore_password
> The following parameters of ENCRYPT protocol are stored as plain text:
> * store_password
> * key_password
> Example:
> {code}
> <ENCRYPT key_store_name="defaultStore.keystore" store_password="changeit" alias="myKey"/>
> {code}
> Requirements for storing passwords: https://docspace.corp.redhat.com/docs/DOC-131628

--
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

From issues at jboss.org  Thu Mar 27 09:24:13 2014
From: issues at jboss.org (David Lloyd (JIRA))
Date: Thu, 27 Mar 2014 09:24:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3178) Update Remoting to 4.0.3.Final
In-Reply-To: <JIRA.12536283.1395926550114@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12536283.1395926550114@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12536283.1395926550114.13356.1395926653117@jira02.app.mwc.hst.phx2.redhat.com>

David Lloyd created WFLY-3178:
---------------------------------

             Summary: Update Remoting to 4.0.3.Final
                 Key: WFLY-3178
                 URL: https://issues.jboss.org/browse/WFLY-3178
             Project: WildFly
          Issue Type: Component  Upgrade
      Security Level: Public (Everyone can see)
          Components: Remoting
            Reporter: David Lloyd
            Assignee: David Lloyd
            Priority: Blocker
             Fix For: 8.0.1.Final


This update prevents a potentially nasty spin loop (REM3-186).

--
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

From issues at jboss.org  Thu Mar 27 09:24:13 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 27 Mar 2014 09:24:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1797) NakackTest
 testReceptionOfAllMessages fails to receive all messages
In-Reply-To: <JIRA.12533037.1393192228000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12533037.1393192228000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12533037.1393192228000.13360.1395926653357@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JGRP-1797?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12956999#comment-12956999 ] 

RH Bugzilla Integration commented on JGRP-1797:
-----------------------------------------------

Richard Achmatowicz <rachmato at redhat.com> changed the Status of [bug 927966|https://bugzilla.redhat.com/show_bug.cgi?id=927966] from NEW to ON_QA
                
> NakackTest testReceptionOfAllMessages fails to receive all messages
> -------------------------------------------------------------------
>
>                 Key: JGRP-1797
>                 URL: https://issues.jboss.org/browse/JGRP-1797
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.2.13
>         Environment: RHEL (5/24), Solaris (6/24), HPUX (1/2) where x/y means x failures over y test executions.
>            Reporter: Richard Achmatowicz
>            Assignee: Bela Ban
>             Fix For: 3.2.13
>
>         Attachments: stdout.txt
>
>
> This test does the following:
> - involves channels A, B, and C where only B and C are senders and all are receivers
> - B and C send 1000 multicast messages
> - checks that all messages are received and in the correct order
> This test is failing intermittently but quite often.

--
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

From issues at jboss.org  Thu Mar 27 09:28:13 2014
From: issues at jboss.org (shinzey shinzey (JIRA))
Date: Thu, 27 Mar 2014 09:28:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3179) Dynamic Deployment of
	Security Domain
In-Reply-To: <JIRA.12536285.1395926783653@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12536285.1395926783653@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12536285.1395926783653.13382.1395926893583@jira02.app.mwc.hst.phx2.redhat.com>

shinzey shinzey created WFLY-3179:
-------------------------------------

             Summary: Dynamic Deployment of Security Domain
                 Key: WFLY-3179
                 URL: https://issues.jboss.org/browse/WFLY-3179
             Project: WildFly
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: Security
    Affects Versions: 8.0.0.Final
         Environment: WildFly 8.0.0.Final
            Reporter: shinzey shinzey
            Assignee: Darran Lofthouse


In JBoss 6, security domains can be dynamically deployed using jboss-beans.xml, which is not working in WildFly 8. It would be quite useful to bring back this feature, so that no manual operations or extra scripts are needed to create security domains during application deployment.

--
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

From issues at jboss.org  Thu Mar 27 10:12:14 2014
From: issues at jboss.org (Radoslav Husar (JIRA))
Date: Thu, 27 Mar 2014 10:12:14 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3144) Session replication doesn't
 work as expected
In-Reply-To: <JIRA.12535573.1395324594000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12535573.1395324594000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12535573.1395324594000.13760.1395929534058@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-3144?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Radoslav Husar reassigned WFLY-3144:
------------------------------------

    Assignee: Radoslav Husar  (was: Paul Ferraro)


Still looking into this. Looks like Weld is creating a new session whereas it shouldn't after failover.
                
> Session replication doesn't work as expected
> --------------------------------------------
>
>                 Key: WFLY-3144
>                 URL: https://issues.jboss.org/browse/WFLY-3144
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: CDI / Weld, Clustering, EJB
>    Affects Versions: 8.0.0.Final
>            Reporter: Tomas Remes
>            Assignee: Radoslav Husar
>         Attachments: translator.zip
>
>
> I am experimenting with quite simple Stateful SessionScoped bean  ( see org.jboss.weld.tests.clustering.translator.TranslatorControllerBean from attached reproducer) and actually there's not any specific exception, but the behavior is at least weird. I haven't tried with plain EJB so far. Reproducible by following steps:
> 1. Run first node with "/bin/standalone.sh -c standalone-ha.xml"
> 2. Run second node with "./bin/standalone.sh -c standalone-ha.xml -Djboss.socket.binding.port-offset=100 -Djboss.node.name=second"
> 3. Build and deploy attached reproducer
> 4. Open 127.0.0.1:8080/translator in your browser and translate something.
> 5. Open 127.0.0.1:8180/translator and note that number of translated sentences is not replicated correctly. 
> This works correctly in EAP. I am running with default standalone-ha configuration on oracle's 1.7.0_45 jdk.

--
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

From issues at jboss.org  Thu Mar 27 10:26:13 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 27 Mar 2014 10:26:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1801) DuplicateTest fails when
 testing OOB multicast to all three senders
In-Reply-To: <JIRA.12533765.1393853856000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12533765.1393853856000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12533765.1393853856000.13785.1395930373187@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JGRP-1801?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated JGRP-1801:
------------------------------------------

        Bugzilla Update: Perform
    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=927911

    
> DuplicateTest fails when testing OOB multicast to all three senders
> -------------------------------------------------------------------
>
>                 Key: JGRP-1801
>                 URL: https://issues.jboss.org/browse/JGRP-1801
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.2.13
>         Environment: Windows (18), Solaris (2), RHEL(1) where (x) is the number of failures seen
>            Reporter: Richard Achmatowicz
>            Assignee: Bela Ban
>             Fix For: 3.2.14
>
>
> DuplicateTest does the following:
> - creates three channels containing the DUPL layer called c1, c2, c3
> - DUPL is used to duplicate messages sent
> - channel receiver for channel each keeps a map of messages received from each sender
> - channels send messages: regular, OOB, or mixed
> - the test checks that the messages received  by each channel are correct in number and in order
> The test testOOBMuloticastToAll3Senders is failing regularly on multple platforms. The test makes each of the channels send OOB multicast messages to the group, but only two of three members ever end up receiving the multicast messages. Al example of the failure:
> {noformat}
> Error Message
> expected size=3, msgs: [C2, C1]
> Stacktrace
> java.lang.AssertionError 
> at org.jgroups.tests.DuplicateTest.check(DuplicateTest.java:217) 
> at org.jgroups.tests.DuplicateTest.testOOBMulticastToAll3Senders(DuplicateTest.java:123) 
> {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

From issues at jboss.org  Thu Mar 27 10:32:13 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 27 Mar 2014 10:32:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1812)
 ProgrammaticApiTest.testSharedTransport fails to receive correct number of
 messages
In-Reply-To: <JIRA.12535897.1395674570000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12535897.1395674570000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12535897.1395674570000.13827.1395930733575@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JGRP-1812?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated JGRP-1812:
------------------------------------------

        Bugzilla Update: Perform
    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=948762

    
> ProgrammaticApiTest.testSharedTransport fails to receive correct number of messages
> -----------------------------------------------------------------------------------
>
>                 Key: JGRP-1812
>                 URL: https://issues.jboss.org/browse/JGRP-1812
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.2.14
>         Environment: RHEL, Solaris
>            Reporter: Richard Achmatowicz
>            Assignee: Bela Ban
>             Fix For: 3.2.14
>
>
> ProgrammaticApiTest tests the use of the API for creating and configuring channels. One such test testSharedTransport tests the creation and use of a stack with a shared transport. This test does the following:
> - creates two channels A and B
> - creates a UDP-based shared transport stack
> - assigns the same stack to both channels
> - channel A connects to group cluster-one; channel B connects to group cluster-two
> - channel A multicasts 10 messages to its group; channel B multicasts 5 messages to its group
> - the test then waits for the correct number of multicast messages to arrive
> Problem:the test is failing because the receiver on channel A is receiving 20 messages instead of 10 messages.
> This test fails intermittently, but fairly regularly.

--
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

From issues at jboss.org  Thu Mar 27 10:52:13 2014
From: issues at jboss.org (Coty Sutherland (JIRA))
Date: Thu, 27 Mar 2014 10:52:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2852) JBoss 7 - EJB Remote
	Transaction Timeout
In-Reply-To: <JIRA.12530939.1391189103000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530939.1391189103000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530939.1391189103000.13873.1395931933698@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2852?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12957044#comment-12957044 ] 

Coty Sutherland commented on WFLY-2852:
---------------------------------------

This looks like a duplicate of https://issues.jboss.org/browse/WFLY-2789.
                
> JBoss 7 - EJB Remote Transaction Timeout
> ----------------------------------------
>
>                 Key: WFLY-2852
>                 URL: https://issues.jboss.org/browse/WFLY-2852
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: EJB
>    Affects Versions: JBoss AS7 7.2.0.Final
>            Reporter: Sofiane Bourguiba
>            Assignee: David Lloyd
>              Labels: jboss
>
> I have a remote call that allow to run a process that takes more than 5 minutes, after passing this time the transaction was canceled and the global transaction was rollbacked at the commit phase.
> The problem is that i can't modify the timeout value.
> Note: After consulting the method createOrResumeXidTransaction of the EJBRemoteTransactionPropagatingInterceptor class, I found that the timeout value is always 300 seconds (it seems that this value is hardcoded)
> You can refer to my discussion with jaikiran pai: https://community.jboss.org/thread/236493
> Thanks,

--
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

From issues at jboss.org  Thu Mar 27 10:52:13 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 27 Mar 2014 10:52:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2852) JBoss 7 - EJB Remote
	Transaction Timeout
In-Reply-To: <JIRA.12530939.1391189103000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530939.1391189103000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530939.1391189103000.13877.1395931933914@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2852?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated WFLY-2852:
------------------------------------------

        Bugzilla Update: Perform
    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1056585

    
> JBoss 7 - EJB Remote Transaction Timeout
> ----------------------------------------
>
>                 Key: WFLY-2852
>                 URL: https://issues.jboss.org/browse/WFLY-2852
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: EJB
>    Affects Versions: JBoss AS7 7.2.0.Final
>            Reporter: Sofiane Bourguiba
>            Assignee: David Lloyd
>              Labels: jboss
>
> I have a remote call that allow to run a process that takes more than 5 minutes, after passing this time the transaction was canceled and the global transaction was rollbacked at the commit phase.
> The problem is that i can't modify the timeout value.
> Note: After consulting the method createOrResumeXidTransaction of the EJBRemoteTransactionPropagatingInterceptor class, I found that the timeout value is always 300 seconds (it seems that this value is hardcoded)
> You can refer to my discussion with jaikiran pai: https://community.jboss.org/thread/236493
> Thanks,

--
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

From issues at jboss.org  Thu Mar 27 11:00:13 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 27 Mar 2014 11:00:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1799) RpcDispatcher test fails when
 working with large values
In-Reply-To: <JIRA.12533122.1393254868000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12533122.1393254868000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12533122.1393254868000.13963.1395932413491@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JGRP-1799?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated JGRP-1799:
------------------------------------------

        Bugzilla Update: Perform
    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1022413

    
> RpcDispatcher test fails when working with large values
> -------------------------------------------------------
>
>                 Key: JGRP-1799
>                 URL: https://issues.jboss.org/browse/JGRP-1799
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.2.13
>         Environment: RHEL, Win, Solaris
>            Reporter: Richard Achmatowicz
>            Assignee: Bela Ban
>             Fix For: 3.2.13
>
>
> The two tests:
> * testLargeReturnValue
> * testLargeReturnValueUnicastCall
> make RPC calls with values which are increasingly large. 
> The values used are in this range:
> {noformat}
> SIZES={10000, 20000, 40000, 80000, 100000, 200000, 400000, 800000,1000000, 2000000, 5000000}
> {noformat}
> The tests have been see to fail with the values 1000000, 2000000 and 5000000, always with the same error in each case. 
> In the case of testLargeReturnValue, the test fails because one of the returned values from the RPC is null.
> In the case of testLargeReturnValueUnicastCall, the test fails due to a timeout while sending the RPC.
>  

--
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

From issues at jboss.org  Thu Mar 27 11:16:14 2014
From: issues at jboss.org (Mario Fusco (JIRA))
Date: Thu, 27 Mar 2014 11:16:14 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-458) Drools lock in
 StatelessKnowledgeSessionImpl.
In-Reply-To: <JIRA.12536231.1395882246000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12536231.1395882246000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12536231.1395882246000.13994.1395933374076@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-458?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mario Fusco reassigned DROOLS-458:
----------------------------------

    Assignee: Mario Fusco  (was: Mark Proctor)

    
> Drools lock in StatelessKnowledgeSessionImpl.
> ---------------------------------------------
>
>                 Key: DROOLS-458
>                 URL: https://issues.jboss.org/browse/DROOLS-458
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 6.0.1.Final
>         Environment: Tomcat 7
>            Reporter: Desmond Silveira
>            Assignee: Mario Fusco
>
> My Tomcat HTTP BIO connector threads (129 of them) got BLOCKED in my production Tomcat 7 instance because Drool 6.0.1 wasn't releasing a lock.
> Here is a snippet of the thread dump:
> {noformat}
> "http-bio-172.16.216.19-80-exec-37513" - Thread t at 6245360
>    java.lang.Thread.State: BLOCKED
> 	at org.drools.core.runtime.process.ProcessRuntimeFactory.getProcessRuntimeFactoryService(ProcessRuntimeFactory.java:20)
> 	- waiting to lock <219dcd77> (a java.lang.Class) owned by "http-bio-172.16.216.19-80-exec-37511" t at 6245358
> 	at org.drools.core.runtime.process.ProcessRuntimeFactory.newProcessRuntime(ProcessRuntimeFactory.java:12)
> 	at org.drools.core.common.AbstractWorkingMemory.createProcessRuntime(AbstractWorkingMemory.java:405)
> 	at org.drools.core.common.AbstractWorkingMemory.setKnowledgeRuntime(AbstractWorkingMemory.java:1770)
> 	at org.drools.core.impl.StatefulKnowledgeSessionImpl.<init>(StatefulKnowledgeSessionImpl.java:125)
> 	at org.drools.core.impl.StatelessKnowledgeSessionImpl.newWorkingMemory(StatelessKnowledgeSessionImpl.java:139)
> 	at org.drools.core.impl.StatelessKnowledgeSessionImpl.execute(StatelessKnowledgeSessionImpl.java:397)
> 	at com.local.lds.RuleEngineBean.applyKnowledge(RuleEngineBean.java:50)
> 	at com.local.lds.LdsBean.search(LdsBean.java:200)
> 	at com.local.lds.servlet.SearchServlet.doGet(SearchServlet.java:55)
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:621)
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:722)
> 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:305)
> 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
> 	at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:224)
> 	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:169)
> 	at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:472)
> 	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:168)
> 	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:98)
> 	at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:927)
> 	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118)
> 	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:407)
> 	at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:987)
> 	at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:579)
> 	at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:307)
> 	- locked <3575a054> (a org.apache.tomcat.util.net.SocketWrapper)
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
> 	at java.lang.Thread.run(Unknown Source)
>    Locked ownable synchronizers:
> 	- locked <719df963> (a java.util.concurrent.ThreadPoolExecutor$Worker)
> "http-bio-172.16.216.19-80-exec-37511" - Thread t at 6245358
>    java.lang.Thread.State: RUNNABLE
> 	at org.kie.internal.utils.ServiceRegistryImpl.addDefault(ServiceRegistryImpl.java:212)
> 	- locked <3d710637> (a org.kie.internal.utils.ServiceRegistryImpl)
> 	at org.kie.internal.utils.ServiceRegistryImpl.addDefault(ServiceRegistryImpl.java:207)
> 	- locked <3d710637> (a org.kie.internal.utils.ServiceRegistryImpl)
> 	at org.drools.core.runtime.process.ProcessRuntimeFactory.loadProvider(ProcessRuntimeFactory.java:27)
> 	at org.drools.core.runtime.process.ProcessRuntimeFactory.getProcessRuntimeFactoryService(ProcessRuntimeFactory.java:21)
> 	- locked <219dcd77> (a java.lang.Class)
> 	at org.drools.core.runtime.process.ProcessRuntimeFactory.newProcessRuntime(ProcessRuntimeFactory.java:12)
> 	at org.drools.core.common.AbstractWorkingMemory.createProcessRuntime(AbstractWorkingMemory.java:405)
> 	at org.drools.core.common.AbstractWorkingMemory.setKnowledgeRuntime(AbstractWorkingMemory.java:1770)
> 	at org.drools.core.impl.StatefulKnowledgeSessionImpl.<init>(StatefulKnowledgeSessionImpl.java:125)
> 	at org.drools.core.impl.StatelessKnowledgeSessionImpl.newWorkingMemory(StatelessKnowledgeSessionImpl.java:139)
> 	at org.drools.core.impl.StatelessKnowledgeSessionImpl.execute(StatelessKnowledgeSessionImpl.java:397)
> 	at com.local.lds.RuleEngineBean.applyKnowledge(RuleEngineBean.java:50)
> 	at com.local.lds.LdsBean.search(LdsBean.java:200)
> 	at com.local.lds.servlet.SearchServlet.doGet(SearchServlet.java:55)
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:621)
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:722)
> 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:305)
> 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
> 	at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:224)
> 	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:169)
> 	at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:472)
> 	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:168)
> 	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:98)
> 	at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:927)
> 	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118)
> 	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:407)
> 	at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:987)
> 	at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:579)
> 	at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:307)
> 	- locked <474f2464> (a org.apache.tomcat.util.net.SocketWrapper)
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
> 	at java.lang.Thread.run(Unknown Source)
>    Locked ownable synchronizers:
> 	- locked <339f344e> (a java.util.concurrent.ThreadPoolExecutor$Worker)
> "http-bio-172.16.216.19-80-exec-37447" - Thread t at 6233953
>    java.lang.Thread.State: BLOCKED
> 	at org.drools.core.common.ProjectClassLoader.loadClass(ProjectClassLoader.java:82)
> 	- waiting to lock <555896b3> (a org.drools.core.common.ProjectClassLoader) owned by "http-bio-172.16.216.19-80-exec-37519" t at 6245366
> 	at java.lang.ClassLoader.loadClass(Unknown Source)
> 	at org.drools.core.base.ClassFieldAccessorCache.getClass(ClassFieldAccessorCache.java:122)
> 	at org.drools.core.base.ClassFieldAccessorCache.getClassObjectType(ClassFieldAccessorCache.java:46)
> 	at org.drools.core.reteoo.ClassObjectTypeConf.<init>(ClassObjectTypeConf.java:89)
> 	at org.drools.core.common.ObjectTypeConfigurationRegistry.getObjectTypeConf(ObjectTypeConfigurationRegistry.java:71)
> 	at org.drools.core.common.AbstractWorkingMemory.initInitialFact(AbstractWorkingMemory.java:385)
> 	at org.drools.core.common.AbstractWorkingMemory.<init>(AbstractWorkingMemory.java:378)
> 	at org.drools.core.common.AbstractWorkingMemory.<init>(AbstractWorkingMemory.java:261)
> 	at org.drools.core.common.PhreakWorkingMemoryFactory.createWorkingMemory(PhreakWorkingMemoryFactory.java:15)
> 	at org.drools.core.impl.StatelessKnowledgeSessionImpl.newWorkingMemory(StatelessKnowledgeSessionImpl.java:134)
> 	at org.drools.core.impl.StatelessKnowledgeSessionImpl.execute(StatelessKnowledgeSessionImpl.java:397)
> 	at com.local.lds.RuleEngineBean.applyKnowledge(RuleEngineBean.java:50)
> 	at com.local.lds.LdsBean.search(LdsBean.java:200)
> 	at com.local.lds.servlet.SearchServlet.doGet(SearchServlet.java:55)
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:621)
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:722)
> 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:305)
> 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
> 	at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:224)
> 	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:169)
> 	at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:472)
> 	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:168)
> 	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:98)
> 	at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:927)
> 	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118)
> 	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:407)
> 	at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:987)
> 	at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:579)
> 	at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:307)
> 	- locked <57e6b780> (a org.apache.tomcat.util.net.SocketWrapper)
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
> 	at java.lang.Thread.run(Unknown Source)
>    Locked ownable synchronizers:
> 	- locked <726294fc> (a java.util.concurrent.ThreadPoolExecutor$Worker)
> "http-bio-172.16.216.19-80-exec-37519" - Thread t at 6245366
>    java.lang.Thread.State: RUNNABLE
> 	at java.lang.ClassLoader.findLoadedClass0(Native Method)
> 	at java.lang.ClassLoader.findLoadedClass(Unknown Source)
> 	at java.lang.ClassLoader.loadClass(Unknown Source)
> 	- locked <555896b3> (a org.drools.core.common.ProjectClassLoader)
> 	at org.drools.core.common.ProjectClassLoader.internalLoadClass(ProjectClassLoader.java:99)
> 	at org.drools.core.common.ProjectClassLoader.loadClass(ProjectClassLoader.java:82)
> 	- locked <555896b3> (a org.drools.core.common.ProjectClassLoader)
> 	at java.lang.ClassLoader.loadClass(Unknown Source)
> 	at org.drools.core.base.ClassFieldAccessorCache.getClass(ClassFieldAccessorCache.java:122)
> 	at org.drools.core.base.ClassFieldAccessorCache.getClassObjectType(ClassFieldAccessorCache.java:46)
> 	at org.drools.core.reteoo.ClassObjectTypeConf.<init>(ClassObjectTypeConf.java:89)
> 	at org.drools.core.common.ObjectTypeConfigurationRegistry.getObjectTypeConf(ObjectTypeConfigurationRegistry.java:71)
> 	at org.drools.core.common.NamedEntryPoint.insert(NamedEntryPoint.java:164)
> 	at org.drools.core.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:1148)
> 	at org.drools.core.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:1092)
> 	at org.drools.core.impl.StatefulKnowledgeSessionImpl.insert(StatefulKnowledgeSessionImpl.java:308)
> 	at org.drools.core.impl.StatelessKnowledgeSessionImpl.execute(StatelessKnowledgeSessionImpl.java:400)
> 	at com.local.lds.RuleEngineBean.applyKnowledge(RuleEngineBean.java:50)
> 	at com.local.lds.LdsBean.search(LdsBean.java:200)
> 	at com.local.lds.servlet.SearchServlet.doGet(SearchServlet.java:55)
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:621)
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:722)
> 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:305)
> 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
> 	at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:224)
> 	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:169)
> 	at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:472)
> 	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:168)
> 	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:98)
> 	at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:927)
> 	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118)
> 	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:407)
> 	at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:987)
> 	at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:579)
> 	at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:307)
> 	- locked <43c2901> (a org.apache.tomcat.util.net.SocketWrapper)
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
> 	at java.lang.Thread.run(Unknown Source)
>    Locked ownable synchronizers:
> 	- locked <88f8fa9> (a java.util.concurrent.ThreadPoolExecutor$Worker)
> {noformat}
> Here is the code that I use to call Drools:
> {code:java}
>     public static Collection<ResultSet> applyRule(String rule,
>             KieBase kb, Collection<ResultSet> resultSets, SearchParameters params) {
>         try {
>             if (kb == null) {
>                 return resultSets;
>             }
>             StatelessKieSession ksession = kb.newStatelessKieSession();
>             ksession.setGlobal(OUTPUT, new ArrayList<>());
>             Collection<Object> collection = new ArrayList<Object>(resultSets);
>             collection.add(params);
>             ksession.execute(collection);
>             return (Collection<ResultSet>) ksession.getGlobals().get(OUTPUT);
>         } catch (ConsequenceException e) {
>             LOG.error("Error in rule: " + rule + " " + e.getRule(), e);
>             throw e;
>         } catch (RuntimeException e) {
>             LOG.error("Error in rule: " + rule, e);
>             throw e;
>         }
>     }
> {code}

--
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

From issues at jboss.org  Thu Mar 27 11:32:12 2014
From: issues at jboss.org (Mario Fusco (JIRA))
Date: Thu, 27 Mar 2014 11:32:12 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-458) Drools lock in
 StatelessKnowledgeSessionImpl.
In-Reply-To: <JIRA.12536231.1395882246000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12536231.1395882246000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12536231.1395882246000.14076.1395934332906@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-458?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mario Fusco resolved DROOLS-458.
--------------------------------

    Resolution: Rejected


I double checked the stack traces you pasted but I still don't see any deadlock there. The 2 blocked threads are not blocking each other, they are blocked only why they are waiting for locks retained by the other 2 running threads. My expectation is that when the 2 running threads have finished what they are doing they will release their locks allowing also the 2 currently blocked threads to move forward.

For this reason I am rejecting this ticket, but if I am overlooking or missing something please feel free to reopen it clarifying where the problem actually is.
                
> Drools lock in StatelessKnowledgeSessionImpl.
> ---------------------------------------------
>
>                 Key: DROOLS-458
>                 URL: https://issues.jboss.org/browse/DROOLS-458
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 6.0.1.Final
>         Environment: Tomcat 7
>            Reporter: Desmond Silveira
>            Assignee: Mario Fusco
>
> My Tomcat HTTP BIO connector threads (129 of them) got BLOCKED in my production Tomcat 7 instance because Drool 6.0.1 wasn't releasing a lock.
> Here is a snippet of the thread dump:
> {noformat}
> "http-bio-172.16.216.19-80-exec-37513" - Thread t at 6245360
>    java.lang.Thread.State: BLOCKED
> 	at org.drools.core.runtime.process.ProcessRuntimeFactory.getProcessRuntimeFactoryService(ProcessRuntimeFactory.java:20)
> 	- waiting to lock <219dcd77> (a java.lang.Class) owned by "http-bio-172.16.216.19-80-exec-37511" t at 6245358
> 	at org.drools.core.runtime.process.ProcessRuntimeFactory.newProcessRuntime(ProcessRuntimeFactory.java:12)
> 	at org.drools.core.common.AbstractWorkingMemory.createProcessRuntime(AbstractWorkingMemory.java:405)
> 	at org.drools.core.common.AbstractWorkingMemory.setKnowledgeRuntime(AbstractWorkingMemory.java:1770)
> 	at org.drools.core.impl.StatefulKnowledgeSessionImpl.<init>(StatefulKnowledgeSessionImpl.java:125)
> 	at org.drools.core.impl.StatelessKnowledgeSessionImpl.newWorkingMemory(StatelessKnowledgeSessionImpl.java:139)
> 	at org.drools.core.impl.StatelessKnowledgeSessionImpl.execute(StatelessKnowledgeSessionImpl.java:397)
> 	at com.local.lds.RuleEngineBean.applyKnowledge(RuleEngineBean.java:50)
> 	at com.local.lds.LdsBean.search(LdsBean.java:200)
> 	at com.local.lds.servlet.SearchServlet.doGet(SearchServlet.java:55)
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:621)
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:722)
> 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:305)
> 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
> 	at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:224)
> 	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:169)
> 	at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:472)
> 	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:168)
> 	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:98)
> 	at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:927)
> 	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118)
> 	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:407)
> 	at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:987)
> 	at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:579)
> 	at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:307)
> 	- locked <3575a054> (a org.apache.tomcat.util.net.SocketWrapper)
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
> 	at java.lang.Thread.run(Unknown Source)
>    Locked ownable synchronizers:
> 	- locked <719df963> (a java.util.concurrent.ThreadPoolExecutor$Worker)
> "http-bio-172.16.216.19-80-exec-37511" - Thread t at 6245358
>    java.lang.Thread.State: RUNNABLE
> 	at org.kie.internal.utils.ServiceRegistryImpl.addDefault(ServiceRegistryImpl.java:212)
> 	- locked <3d710637> (a org.kie.internal.utils.ServiceRegistryImpl)
> 	at org.kie.internal.utils.ServiceRegistryImpl.addDefault(ServiceRegistryImpl.java:207)
> 	- locked <3d710637> (a org.kie.internal.utils.ServiceRegistryImpl)
> 	at org.drools.core.runtime.process.ProcessRuntimeFactory.loadProvider(ProcessRuntimeFactory.java:27)
> 	at org.drools.core.runtime.process.ProcessRuntimeFactory.getProcessRuntimeFactoryService(ProcessRuntimeFactory.java:21)
> 	- locked <219dcd77> (a java.lang.Class)
> 	at org.drools.core.runtime.process.ProcessRuntimeFactory.newProcessRuntime(ProcessRuntimeFactory.java:12)
> 	at org.drools.core.common.AbstractWorkingMemory.createProcessRuntime(AbstractWorkingMemory.java:405)
> 	at org.drools.core.common.AbstractWorkingMemory.setKnowledgeRuntime(AbstractWorkingMemory.java:1770)
> 	at org.drools.core.impl.StatefulKnowledgeSessionImpl.<init>(StatefulKnowledgeSessionImpl.java:125)
> 	at org.drools.core.impl.StatelessKnowledgeSessionImpl.newWorkingMemory(StatelessKnowledgeSessionImpl.java:139)
> 	at org.drools.core.impl.StatelessKnowledgeSessionImpl.execute(StatelessKnowledgeSessionImpl.java:397)
> 	at com.local.lds.RuleEngineBean.applyKnowledge(RuleEngineBean.java:50)
> 	at com.local.lds.LdsBean.search(LdsBean.java:200)
> 	at com.local.lds.servlet.SearchServlet.doGet(SearchServlet.java:55)
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:621)
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:722)
> 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:305)
> 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
> 	at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:224)
> 	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:169)
> 	at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:472)
> 	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:168)
> 	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:98)
> 	at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:927)
> 	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118)
> 	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:407)
> 	at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:987)
> 	at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:579)
> 	at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:307)
> 	- locked <474f2464> (a org.apache.tomcat.util.net.SocketWrapper)
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
> 	at java.lang.Thread.run(Unknown Source)
>    Locked ownable synchronizers:
> 	- locked <339f344e> (a java.util.concurrent.ThreadPoolExecutor$Worker)
> "http-bio-172.16.216.19-80-exec-37447" - Thread t at 6233953
>    java.lang.Thread.State: BLOCKED
> 	at org.drools.core.common.ProjectClassLoader.loadClass(ProjectClassLoader.java:82)
> 	- waiting to lock <555896b3> (a org.drools.core.common.ProjectClassLoader) owned by "http-bio-172.16.216.19-80-exec-37519" t at 6245366
> 	at java.lang.ClassLoader.loadClass(Unknown Source)
> 	at org.drools.core.base.ClassFieldAccessorCache.getClass(ClassFieldAccessorCache.java:122)
> 	at org.drools.core.base.ClassFieldAccessorCache.getClassObjectType(ClassFieldAccessorCache.java:46)
> 	at org.drools.core.reteoo.ClassObjectTypeConf.<init>(ClassObjectTypeConf.java:89)
> 	at org.drools.core.common.ObjectTypeConfigurationRegistry.getObjectTypeConf(ObjectTypeConfigurationRegistry.java:71)
> 	at org.drools.core.common.AbstractWorkingMemory.initInitialFact(AbstractWorkingMemory.java:385)
> 	at org.drools.core.common.AbstractWorkingMemory.<init>(AbstractWorkingMemory.java:378)
> 	at org.drools.core.common.AbstractWorkingMemory.<init>(AbstractWorkingMemory.java:261)
> 	at org.drools.core.common.PhreakWorkingMemoryFactory.createWorkingMemory(PhreakWorkingMemoryFactory.java:15)
> 	at org.drools.core.impl.StatelessKnowledgeSessionImpl.newWorkingMemory(StatelessKnowledgeSessionImpl.java:134)
> 	at org.drools.core.impl.StatelessKnowledgeSessionImpl.execute(StatelessKnowledgeSessionImpl.java:397)
> 	at com.local.lds.RuleEngineBean.applyKnowledge(RuleEngineBean.java:50)
> 	at com.local.lds.LdsBean.search(LdsBean.java:200)
> 	at com.local.lds.servlet.SearchServlet.doGet(SearchServlet.java:55)
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:621)
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:722)
> 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:305)
> 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
> 	at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:224)
> 	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:169)
> 	at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:472)
> 	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:168)
> 	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:98)
> 	at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:927)
> 	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118)
> 	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:407)
> 	at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:987)
> 	at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:579)
> 	at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:307)
> 	- locked <57e6b780> (a org.apache.tomcat.util.net.SocketWrapper)
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
> 	at java.lang.Thread.run(Unknown Source)
>    Locked ownable synchronizers:
> 	- locked <726294fc> (a java.util.concurrent.ThreadPoolExecutor$Worker)
> "http-bio-172.16.216.19-80-exec-37519" - Thread t at 6245366
>    java.lang.Thread.State: RUNNABLE
> 	at java.lang.ClassLoader.findLoadedClass0(Native Method)
> 	at java.lang.ClassLoader.findLoadedClass(Unknown Source)
> 	at java.lang.ClassLoader.loadClass(Unknown Source)
> 	- locked <555896b3> (a org.drools.core.common.ProjectClassLoader)
> 	at org.drools.core.common.ProjectClassLoader.internalLoadClass(ProjectClassLoader.java:99)
> 	at org.drools.core.common.ProjectClassLoader.loadClass(ProjectClassLoader.java:82)
> 	- locked <555896b3> (a org.drools.core.common.ProjectClassLoader)
> 	at java.lang.ClassLoader.loadClass(Unknown Source)
> 	at org.drools.core.base.ClassFieldAccessorCache.getClass(ClassFieldAccessorCache.java:122)
> 	at org.drools.core.base.ClassFieldAccessorCache.getClassObjectType(ClassFieldAccessorCache.java:46)
> 	at org.drools.core.reteoo.ClassObjectTypeConf.<init>(ClassObjectTypeConf.java:89)
> 	at org.drools.core.common.ObjectTypeConfigurationRegistry.getObjectTypeConf(ObjectTypeConfigurationRegistry.java:71)
> 	at org.drools.core.common.NamedEntryPoint.insert(NamedEntryPoint.java:164)
> 	at org.drools.core.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:1148)
> 	at org.drools.core.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:1092)
> 	at org.drools.core.impl.StatefulKnowledgeSessionImpl.insert(StatefulKnowledgeSessionImpl.java:308)
> 	at org.drools.core.impl.StatelessKnowledgeSessionImpl.execute(StatelessKnowledgeSessionImpl.java:400)
> 	at com.local.lds.RuleEngineBean.applyKnowledge(RuleEngineBean.java:50)
> 	at com.local.lds.LdsBean.search(LdsBean.java:200)
> 	at com.local.lds.servlet.SearchServlet.doGet(SearchServlet.java:55)
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:621)
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:722)
> 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:305)
> 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
> 	at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:224)
> 	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:169)
> 	at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:472)
> 	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:168)
> 	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:98)
> 	at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:927)
> 	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118)
> 	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:407)
> 	at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:987)
> 	at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:579)
> 	at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:307)
> 	- locked <43c2901> (a org.apache.tomcat.util.net.SocketWrapper)
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
> 	at java.lang.Thread.run(Unknown Source)
>    Locked ownable synchronizers:
> 	- locked <88f8fa9> (a java.util.concurrent.ThreadPoolExecutor$Worker)
> {noformat}
> Here is the code that I use to call Drools:
> {code:java}
>     public static Collection<ResultSet> applyRule(String rule,
>             KieBase kb, Collection<ResultSet> resultSets, SearchParameters params) {
>         try {
>             if (kb == null) {
>                 return resultSets;
>             }
>             StatelessKieSession ksession = kb.newStatelessKieSession();
>             ksession.setGlobal(OUTPUT, new ArrayList<>());
>             Collection<Object> collection = new ArrayList<Object>(resultSets);
>             collection.add(params);
>             ksession.execute(collection);
>             return (Collection<ResultSet>) ksession.getGlobals().get(OUTPUT);
>         } catch (ConsequenceException e) {
>             LOG.error("Error in rule: " + rule + " " + e.getRule(), e);
>             throw e;
>         } catch (RuntimeException e) {
>             LOG.error("Error in rule: " + rule, e);
>             throw e;
>         }
>     }
> {code}

--
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

From issues at jboss.org  Thu Mar 27 11:40:13 2014
From: issues at jboss.org (Paul Ferraro (JIRA))
Date: Thu, 27 Mar 2014 11:40:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3180) OOMs are still possible when
 using clustered web sessions/SFSBs w/passivation
In-Reply-To: <JIRA.12536320.1395934693524@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12536320.1395934693524@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12536320.1395934693524.14097.1395934813077@jira02.app.mwc.hst.phx2.redhat.com>

Paul Ferraro created WFLY-3180:
----------------------------------

             Summary: OOMs are still possible when using clustered web sessions/SFSBs w/passivation
                 Key: WFLY-3180
                 URL: https://issues.jboss.org/browse/WFLY-3180
             Project: WildFly
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Clustering
    Affects Versions: 8.0.0.Final
            Reporter: Paul Ferraro
            Assignee: Paul Ferraro


Currently, the owner of a web session or SFSB is responsible for schedule passivation.  Unfortunately, much to my surprise, infinispan eviction commands are not broadcasted to the cluster, but are local-only.  Consequently, the number of cache entries stored in memory can grow beyond the configured passivation limits, since remote copies of old cache entries are never evicted.
To fix this, we can use the CommandDispatcher to manually broadcast eviction commands to the cluster.

--
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

From issues at jboss.org  Thu Mar 27 11:56:13 2014
From: issues at jboss.org (Bela Ban (JIRA))
Date: Thu, 27 Mar 2014 11:56:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1816) Message: add flag
	DONT_LOOPBACK
In-Reply-To: <JIRA.12536323.1395935656345@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12536323.1395935656345@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12536323.1395935656345.14133.1395935773122@jira02.app.mwc.hst.phx2.redhat.com>

Bela Ban created JGRP-1816:
------------------------------

             Summary: Message: add flag DONT_LOOPBACK
                 Key: JGRP-1816
                 URL: https://issues.jboss.org/browse/JGRP-1816
             Project: JGroups
          Issue Type: Feature Request
            Reporter: Bela Ban
            Assignee: Bela Ban
             Fix For: 3.5


When flag {{DONT_LOOPBACK}}, then multicast messages ({{dest}} == null) are not looped back up the stack. This can be useful in some cases, e.g. discovery:
* A multicasts a discovery request
* A gets the discovery request and adds information shipped with it (A's logical-physical address mapping and logical name) to its local cache(s)
* A sends a discovery response to itself
* A gets the discovery response and adds its information *again*
--> Because the information was already present, it doesn't need to be added, *but was added 2 more times* !
--> This unneeded processing costs threads from the pool, processing power, locks etc
SOLUTION:
* When sending a multicast message we loop it back up and then multicast  it. When received by the sender, we drop it.
* We now don't even loop back the message if DONT_LOOPBACK is set

--
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

From issues at jboss.org  Thu Mar 27 12:08:13 2014
From: issues at jboss.org (James Perkins (JIRA))
Date: Thu, 27 Mar 2014 12:08:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBLOGGING-102) Messages#getBundle()
 needs to be privileged
In-Reply-To: <JIRA.12536158.1395838258000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12536158.1395838258000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12536158.1395838258000.14180.1395936493048@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JBLOGGING-102?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12957083#comment-12957083 ] 

James Perkins commented on JBLOGGING-102:
-----------------------------------------

It's around the entire block :) https://github.com/jboss-logging/jboss-logging/blob/3.1/src/main/java/org/jboss/logging/Messages.java#L58
                
> Messages#getBundle() needs to be privileged
> -------------------------------------------
>
>                 Key: JBLOGGING-102
>                 URL: https://issues.jboss.org/browse/JBLOGGING-102
>             Project: JBoss Logging
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 3.1.4.GA, 3.2.0.Beta1
>            Reporter: Ivo Studensky
>            Assignee: James Perkins
>             Fix For: 3.1.3.GA, 3.2.0.Beta1
>
>
> It ({{org.jboss.logging.Messages#getBundle(Class<T> type, Locale locale)}}) calls {{type.getClassLoader()}} which requires privileges when running with Security Manager.

--
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

From issues at jboss.org  Thu Mar 27 12:28:12 2014
From: issues at jboss.org (Richard Achmatowicz (JIRA))
Date: Thu, 27 Mar 2014 12:28:12 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1817) OverlappingMergeTest
 testSameCreatorDifferentIDs fails to create correct merged view
In-Reply-To: <JIRA.12536325.1395937598863@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12536325.1395937598863@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12536325.1395937598863.14249.1395937692996@jira02.app.mwc.hst.phx2.redhat.com>

Richard Achmatowicz created JGRP-1817:
-----------------------------------------

             Summary: OverlappingMergeTest testSameCreatorDifferentIDs fails to create correct merged view
                 Key: JGRP-1817
                 URL: https://issues.jboss.org/browse/JGRP-1817
             Project: JGroups
          Issue Type: Bug
    Affects Versions: 3.2.13
         Environment: RHEL
            Reporter: Richard Achmatowicz
            Assignee: Bela Ban
             Fix For: 3.2.13


This test does the following:
- creates four channels a,b,c,d
- injects views A: {A,C,B}, B:{A,C,B}, C:{A,C,B} and D: {B,A,C,D}
- injects a merge event in each of channels A,B,C,D representing these four views
- checks that all channels have the final view of size 4

The test fails intermittently on RHEL, with the same failure each time:

{noformat}
181595 [DEBUG] GMS: - A: installing view [A|2] [A]
   [testng] 181596 [TRACE] GMS: - A: received all 1 ACKs from members for view [A|2]
   [testng] 181866 [TRACE] GMS: - view [A|3] [] is empty: will not multicast it (last view)
   [testng] 
   [testng] -------------------------------------------------------------------
   [testng] GMS: address=A, cluster=OverlappingMergeTest, physical address=10.16.94.42:27199
   [testng] -------------------------------------------------------------------
   [testng] 184954 [TRACE] GMS: - A: no initial members discovered: creating group as first member
   [testng] 184954 [DEBUG] GMS: - A: installing view [A|0] [A]
   [testng] 184955 [DEBUG] GMS: - created group (first member). My view is [A|0], impl is org.jgroups.protocols.pbcast.CoordGmsImpl
   [testng] 
   [testng] -------------------------------------------------------------------
   [testng] GMS: address=B, cluster=OverlappingMergeTest, physical address=10.16.94.42:27200
   [testng] -------------------------------------------------------------------
   [testng] 184961 [TRACE] GMS: - B: initial_mbrs are A 
   [testng] 184961 [DEBUG] GMS: - election results: {A=1}
   [testng] 184961 [DEBUG] GMS: - sending JOIN(B) to A
   [testng] 185013 [TRACE] GMS: - A: new members=[B], suspected=[], leaving=[], new view: [A|1] [A, B]
   [testng] 185014 [TRACE] GMS: - A: mcasting view [A|1] [A, B] (2 mbrs)
   [testng] 
   [testng] 185025 [DEBUG] GMS: - A: installing view [A|1] [A, B]
   [testng] 185026 [TRACE] GMS: - A: received all 1 ACKs from members for view [A|1]
   [testng] 185055 [TRACE] GMS: - B: JOIN-RSP=[A|1] [A, B] [size=2]
   [testng] 
   [testng] 
   [testng] 185055 [DEBUG] GMS: - B: installing view [A|1] [A, B]
   [testng] 185057 [TRACE] GMS: - A: received all ACKs (1) from joiners for view [A|1]
   [testng] 
   [testng] -------------------------------------------------------------------
   [testng] GMS: address=C, cluster=OverlappingMergeTest, physical address=10.16.94.42:27201
   [testng] -------------------------------------------------------------------
   [testng] 185064 [TRACE] GMS: - C: initial_mbrs are B A 
   [testng] 185064 [DEBUG] GMS: - election results: {A=2}
   [testng] 185064 [DEBUG] GMS: - sending JOIN(C) to A
   [testng] 185108 [TRACE] GMS: - A: new members=[C], suspected=[], leaving=[], new view: [A|2] [A, B, C]
   [testng] 185108 [TRACE] GMS: - A: mcasting view [A|2] [A, B, C] (3 mbrs)
   [testng] 
   [testng] 185117 [DEBUG] GMS: - A: installing view [A|2] [A, B, C]
   [testng] 185118 [DEBUG] GMS: - B: installing view [A|2] [A, B, C]
   [testng] 185119 [TRACE] GMS: - A: received all 2 ACKs from members for view [A|2]
   [testng] 185148 [TRACE] GMS: - C: JOIN-RSP=[A|2] [A, B, C] [size=3]
   [testng] 
   [testng] 
   [testng] 185149 [DEBUG] GMS: - C: installing view [A|2] [A, B, C]
   [testng] 185151 [TRACE] GMS: - A: received all ACKs (1) from joiners for view [A|2]
   [testng] 
   [testng] -------------------------------------------------------------------
   [testng] GMS: address=D, cluster=OverlappingMergeTest, physical address=10.16.94.42:27202
   [testng] -------------------------------------------------------------------
   [testng] 185164 [TRACE] GMS: - D: initial_mbrs are B C A 
   [testng] 185164 [DEBUG] GMS: - election results: {A=3}
   [testng] 185164 [DEBUG] GMS: - sending JOIN(D) to A
   [testng] 185203 [TRACE] GMS: - A: new members=[D], suspected=[], leaving=[], new view: [A|3] [A, B, C, D]
   [testng] 185203 [TRACE] GMS: - A: mcasting view [A|3] [A, B, C, D] (4 mbrs)
   [testng] 
   [testng] 185210 [DEBUG] GMS: - A: installing view [A|3] [A, B, C, D]
   [testng] 185211 [DEBUG] GMS: - B: installing view [A|3] [A, B, C, D]
   [testng] 185211 [DEBUG] GMS: - C: installing view [A|3] [A, B, C, D]
   [testng] 185213 [TRACE] GMS: - A: received all 3 ACKs from members for view [A|3]
   [testng] 185242 [TRACE] GMS: - D: JOIN-RSP=[A|3] [A, B, C, D] [size=4]
   [testng] 
   [testng] 
   [testng] 185242 [DEBUG] GMS: - D: installing view [A|3] [A, B, C, D]
   [testng] 185242 [TRACE] GMS: - A: received all ACKs (1) from joiners for view [A|3]
   [testng] 
   [testng]  ==== Injecting view [A|4] [A, C, B] into A, B and C ====
   [testng] 185243 [DEBUG] GMS: - A: installing view [A|4] [A, C, B]
   [testng] 185243 [DEBUG] GMS: - B: installing view [A|4] [A, C, B]
   [testng] 185244 [DEBUG] GMS: - C: installing view [A|4] [A, C, B]
   [testng] 
   [testng]  ==== Injecting view [B|4] [B, A, C, D] into D ====
   [testng] 
   [testng] 185245 [DEBUG] GMS: - D: installing view [B|4] [B, A, C, D]
   [testng] A: [A|4] [A, C, B]
   [testng] B: [A|4] [A, C, B]
   [testng] C: [A|4] [A, C, B]
   [testng] D: [B|4] [B, A, C, D]
   [testng] 
   [testng] ==== Injecting a merge event into A, B, C and D====
   [testng] 185251 [TRACE] GMS: - A: got merge response from A, merge_id=A::3, merge data is sender=A, view=[A|4] [A, C, B], digest=C: [0 (0)], B: [0 (0)], A: [4 (4)]
   [testng] 185253 [TRACE] GMS: - B: queue is suspended; request MERGE(4 views) is discarded
   [testng] 185255 [TRACE] GMS: - C: queue is suspended; request MERGE(4 views) is discarded
   [testng] 185255 [TRACE] GMS: - A: got merge response from B, merge_id=A::3, merge data is sender=B, view=[A|4] [A, C, B], digest=C: [0 (0)], B: [0 (1)], A: [4 (4)]
   [testng] 190286 [TRACE] GMS: - A: mcasting view MergeView::[A|5] [A, B, C], subgroups=[A|4] [A, C, B], [A|4] [A, C, B] (3 mbrs)
   [testng] 
   [testng] 190286 [TRACE] GMS: - B: mcasting view MergeView::[A|5] [A, B, C], subgroups=[A|4] [A, C, B], [A|4] [A, C, B] (3 mbrs)
   [testng] 
   [testng] 190317 [DEBUG] GMS: - A: installing view MergeView::[A|5] [A, B, C], subgroups=[A|4] [A, C, B], [A|4] [A, C, B]
   [testng] 190318 [DEBUG] GMS: - B: installing view MergeView::[A|5] [A, B, C], subgroups=[A|4] [A, C, B], [A|4] [A, C, B]
   [testng] 190318 [DEBUG] GMS: - C: installing view MergeView::[A|5] [A, B, C], subgroups=[A|4] [A, C, B], [A|4] [A, C, B]
   [testng] 190320 [TRACE] GMS: - A: received all 3 ACKs from members for view [A|5]
   [testng] 190320 [TRACE] GMS: - B: received all 3 ACKs from members for view [A|5]
   [testng] A: [A|5] [A, B, C] (coord=true)
   [testng] B: [A|5] [A, B, C] (coord=false)
   [testng] C: [A|5] [A, B, C] (coord=false)
   [testng] D: [B|4] [B, A, C, D] (coord=false)
   [testng] 195277 [DEBUG] GMS: - D: sending LEAVE request to B
   [testng] FAIL: [1] org.jgroups.tests.OverlappingMergeTest.testMergeWithDifferentPartitions()
{noformat}

 Whenever this test fails, I see that the queues are suspended on the initial merge attempt.

--
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

From issues at jboss.org  Thu Mar 27 12:28:13 2014
From: issues at jboss.org (Richard Achmatowicz (JIRA))
Date: Thu, 27 Mar 2014 12:28:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1817) OverlappingMergeTest
 testSameCreatorDifferentIDs fails to create correct merged view
In-Reply-To: <JIRA.12536325.1395937598000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12536325.1395937598000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12536325.1395937598000.14252.1395937693123@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JGRP-1817?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Richard Achmatowicz updated JGRP-1817:
--------------------------------------

    Fix Version/s: 3.2.14
                       (was: 3.2.13)

    
> OverlappingMergeTest testSameCreatorDifferentIDs fails to create correct merged view
> ------------------------------------------------------------------------------------
>
>                 Key: JGRP-1817
>                 URL: https://issues.jboss.org/browse/JGRP-1817
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.2.13
>         Environment: RHEL
>            Reporter: Richard Achmatowicz
>            Assignee: Bela Ban
>             Fix For: 3.2.14
>
>
> This test does the following:
> - creates four channels a,b,c,d
> - injects views A: {A,C,B}, B:{A,C,B}, C:{A,C,B} and D: {B,A,C,D}
> - injects a merge event in each of channels A,B,C,D representing these four views
> - checks that all channels have the final view of size 4
> The test fails intermittently on RHEL, with the same failure each time:
> {noformat}
> 181595 [DEBUG] GMS: - A: installing view [A|2] [A]
>    [testng] 181596 [TRACE] GMS: - A: received all 1 ACKs from members for view [A|2]
>    [testng] 181866 [TRACE] GMS: - view [A|3] [] is empty: will not multicast it (last view)
>    [testng] 
>    [testng] -------------------------------------------------------------------
>    [testng] GMS: address=A, cluster=OverlappingMergeTest, physical address=10.16.94.42:27199
>    [testng] -------------------------------------------------------------------
>    [testng] 184954 [TRACE] GMS: - A: no initial members discovered: creating group as first member
>    [testng] 184954 [DEBUG] GMS: - A: installing view [A|0] [A]
>    [testng] 184955 [DEBUG] GMS: - created group (first member). My view is [A|0], impl is org.jgroups.protocols.pbcast.CoordGmsImpl
>    [testng] 
>    [testng] -------------------------------------------------------------------
>    [testng] GMS: address=B, cluster=OverlappingMergeTest, physical address=10.16.94.42:27200
>    [testng] -------------------------------------------------------------------
>    [testng] 184961 [TRACE] GMS: - B: initial_mbrs are A 
>    [testng] 184961 [DEBUG] GMS: - election results: {A=1}
>    [testng] 184961 [DEBUG] GMS: - sending JOIN(B) to A
>    [testng] 185013 [TRACE] GMS: - A: new members=[B], suspected=[], leaving=[], new view: [A|1] [A, B]
>    [testng] 185014 [TRACE] GMS: - A: mcasting view [A|1] [A, B] (2 mbrs)
>    [testng] 
>    [testng] 185025 [DEBUG] GMS: - A: installing view [A|1] [A, B]
>    [testng] 185026 [TRACE] GMS: - A: received all 1 ACKs from members for view [A|1]
>    [testng] 185055 [TRACE] GMS: - B: JOIN-RSP=[A|1] [A, B] [size=2]
>    [testng] 
>    [testng] 
>    [testng] 185055 [DEBUG] GMS: - B: installing view [A|1] [A, B]
>    [testng] 185057 [TRACE] GMS: - A: received all ACKs (1) from joiners for view [A|1]
>    [testng] 
>    [testng] -------------------------------------------------------------------
>    [testng] GMS: address=C, cluster=OverlappingMergeTest, physical address=10.16.94.42:27201
>    [testng] -------------------------------------------------------------------
>    [testng] 185064 [TRACE] GMS: - C: initial_mbrs are B A 
>    [testng] 185064 [DEBUG] GMS: - election results: {A=2}
>    [testng] 185064 [DEBUG] GMS: - sending JOIN(C) to A
>    [testng] 185108 [TRACE] GMS: - A: new members=[C], suspected=[], leaving=[], new view: [A|2] [A, B, C]
>    [testng] 185108 [TRACE] GMS: - A: mcasting view [A|2] [A, B, C] (3 mbrs)
>    [testng] 
>    [testng] 185117 [DEBUG] GMS: - A: installing view [A|2] [A, B, C]
>    [testng] 185118 [DEBUG] GMS: - B: installing view [A|2] [A, B, C]
>    [testng] 185119 [TRACE] GMS: - A: received all 2 ACKs from members for view [A|2]
>    [testng] 185148 [TRACE] GMS: - C: JOIN-RSP=[A|2] [A, B, C] [size=3]
>    [testng] 
>    [testng] 
>    [testng] 185149 [DEBUG] GMS: - C: installing view [A|2] [A, B, C]
>    [testng] 185151 [TRACE] GMS: - A: received all ACKs (1) from joiners for view [A|2]
>    [testng] 
>    [testng] -------------------------------------------------------------------
>    [testng] GMS: address=D, cluster=OverlappingMergeTest, physical address=10.16.94.42:27202
>    [testng] -------------------------------------------------------------------
>    [testng] 185164 [TRACE] GMS: - D: initial_mbrs are B C A 
>    [testng] 185164 [DEBUG] GMS: - election results: {A=3}
>    [testng] 185164 [DEBUG] GMS: - sending JOIN(D) to A
>    [testng] 185203 [TRACE] GMS: - A: new members=[D], suspected=[], leaving=[], new view: [A|3] [A, B, C, D]
>    [testng] 185203 [TRACE] GMS: - A: mcasting view [A|3] [A, B, C, D] (4 mbrs)
>    [testng] 
>    [testng] 185210 [DEBUG] GMS: - A: installing view [A|3] [A, B, C, D]
>    [testng] 185211 [DEBUG] GMS: - B: installing view [A|3] [A, B, C, D]
>    [testng] 185211 [DEBUG] GMS: - C: installing view [A|3] [A, B, C, D]
>    [testng] 185213 [TRACE] GMS: - A: received all 3 ACKs from members for view [A|3]
>    [testng] 185242 [TRACE] GMS: - D: JOIN-RSP=[A|3] [A, B, C, D] [size=4]
>    [testng] 
>    [testng] 
>    [testng] 185242 [DEBUG] GMS: - D: installing view [A|3] [A, B, C, D]
>    [testng] 185242 [TRACE] GMS: - A: received all ACKs (1) from joiners for view [A|3]
>    [testng] 
>    [testng]  ==== Injecting view [A|4] [A, C, B] into A, B and C ====
>    [testng] 185243 [DEBUG] GMS: - A: installing view [A|4] [A, C, B]
>    [testng] 185243 [DEBUG] GMS: - B: installing view [A|4] [A, C, B]
>    [testng] 185244 [DEBUG] GMS: - C: installing view [A|4] [A, C, B]
>    [testng] 
>    [testng]  ==== Injecting view [B|4] [B, A, C, D] into D ====
>    [testng] 
>    [testng] 185245 [DEBUG] GMS: - D: installing view [B|4] [B, A, C, D]
>    [testng] A: [A|4] [A, C, B]
>    [testng] B: [A|4] [A, C, B]
>    [testng] C: [A|4] [A, C, B]
>    [testng] D: [B|4] [B, A, C, D]
>    [testng] 
>    [testng] ==== Injecting a merge event into A, B, C and D====
>    [testng] 185251 [TRACE] GMS: - A: got merge response from A, merge_id=A::3, merge data is sender=A, view=[A|4] [A, C, B], digest=C: [0 (0)], B: [0 (0)], A: [4 (4)]
>    [testng] 185253 [TRACE] GMS: - B: queue is suspended; request MERGE(4 views) is discarded
>    [testng] 185255 [TRACE] GMS: - C: queue is suspended; request MERGE(4 views) is discarded
>    [testng] 185255 [TRACE] GMS: - A: got merge response from B, merge_id=A::3, merge data is sender=B, view=[A|4] [A, C, B], digest=C: [0 (0)], B: [0 (1)], A: [4 (4)]
>    [testng] 190286 [TRACE] GMS: - A: mcasting view MergeView::[A|5] [A, B, C], subgroups=[A|4] [A, C, B], [A|4] [A, C, B] (3 mbrs)
>    [testng] 
>    [testng] 190286 [TRACE] GMS: - B: mcasting view MergeView::[A|5] [A, B, C], subgroups=[A|4] [A, C, B], [A|4] [A, C, B] (3 mbrs)
>    [testng] 
>    [testng] 190317 [DEBUG] GMS: - A: installing view MergeView::[A|5] [A, B, C], subgroups=[A|4] [A, C, B], [A|4] [A, C, B]
>    [testng] 190318 [DEBUG] GMS: - B: installing view MergeView::[A|5] [A, B, C], subgroups=[A|4] [A, C, B], [A|4] [A, C, B]
>    [testng] 190318 [DEBUG] GMS: - C: installing view MergeView::[A|5] [A, B, C], subgroups=[A|4] [A, C, B], [A|4] [A, C, B]
>    [testng] 190320 [TRACE] GMS: - A: received all 3 ACKs from members for view [A|5]
>    [testng] 190320 [TRACE] GMS: - B: received all 3 ACKs from members for view [A|5]
>    [testng] A: [A|5] [A, B, C] (coord=true)
>    [testng] B: [A|5] [A, B, C] (coord=false)
>    [testng] C: [A|5] [A, B, C] (coord=false)
>    [testng] D: [B|4] [B, A, C, D] (coord=false)
>    [testng] 195277 [DEBUG] GMS: - D: sending LEAVE request to B
>    [testng] FAIL: [1] org.jgroups.tests.OverlappingMergeTest.testMergeWithDifferentPartitions()
> {noformat}
>  Whenever this test fails, I see that the queues are suspended on the initial merge attempt.

--
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

From issues at jboss.org  Thu Mar 27 12:38:14 2014
From: issues at jboss.org (Richard Achmatowicz (JIRA))
Date: Thu, 27 Mar 2014 12:38:14 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1817) OverlappingMergeTest
 testSameCreatorDifferentIDs fails to create correct merged view
In-Reply-To: <JIRA.12536325.1395937598000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12536325.1395937598000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12536325.1395937598000.14288.1395938294421@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JGRP-1817?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Richard Achmatowicz updated JGRP-1817:
--------------------------------------

    Description: 
This test does the following:
- creates three channels a,b,c
- injects views A: {A|5 A}, B:{A|6 A,B}, C:{A|7 A,B,C} 
- injects a merge event in each of channels A,B,C representing these four views
- checks that all channels have the final view of size 3

The test fails intermittently on RHEL, with the same failure each time:

{noformat}
-------------------------------------------------------------------
GMS: address=A, cluster=OverlappingMergeTest, physical address=10.16.95.7:27215
-------------------------------------------------------------------
-------------------------------------------------------------------
GMS: address=B, cluster=OverlappingMergeTest, physical address=10.16.95.7:27216
-------------------------------------------------------------------
-------------------------------------------------------------------
GMS: address=C, cluster=OverlappingMergeTest, physical address=10.16.95.7:27217
-------------------------------------------------------------------

------------- testSameCreatorDifferentIDs -----------
[A] view=[A|5] [A]
[B] view=[A|6] [A, B]
[C] view=[A|7] [A, B, C]

A's view: [A|5] [A]
B's view: [A|6] [A, B]
C's view: [A|7] [A, B, C]
Enabling TRACE debugging for GMS, MERGE2 and Discovery

==== triggering merge solicitation ====:
212534 [TRACE] TCPPING: - A: sending discovery request to 10.16.95.7:27216
212537 [TRACE] TCPPING: - A: sending discovery request to 10.16.95.7:27218
212538 [TRACE] TCPPING: - A: sending discovery request to 10.16.95.7:27217
215538 [TRACE] TCPPING: - A: discovery took 3004 ms: responses: 1 total (1 servers (0 coord), 0 clients)
215539 [TRACE] MERGE2: - Discovery results:
[B]: view_id=[A|6] ([A|6] [A, B])
[A]: view_id=[A|5] ([A|5] [A])
215539 [DEBUG] MERGE2: - A found different views : [A|5], [A|6]; sending up MERGE event with merge participants [B, A].
Discovery results:
[B]: coord=A
[A]: coord=A

==== checking views after merge ====:
....................Disabling TRACE debugging for GMS, MERGE2 and Discovery

A's view: [A|7] [A, B]
B's view: [A|7] [A, B]
C's view: [A|7] [A, B, C]
{noformat}

 Whenever this test fails, it is the discovery phase which fails to find the correct set of views. Instead of finding views for channels A, B and C, it only finds views for channels A and B.
 
Also, the discovery requests  are sent to host:port combinations which are offset by 1. For example, in the case above, the host:port combinations of the channels are 10.16.95.7:27215, 10.16.95.7:27216, and 10.16.95.7:27217, but the pings go put to 10.16.95.7:27216, 10.16.95.7:27217, and 10.16.95.7:27218. Not sure if this is significant as it still covers the channels B and C.



  was:
This test does the following:
- creates four channels a,b,c,d
- injects views A: {A,C,B}, B:{A,C,B}, C:{A,C,B} and D: {B,A,C,D}
- injects a merge event in each of channels A,B,C,D representing these four views
- checks that all channels have the final view of size 4

The test fails intermittently on RHEL, with the same failure each time:

{noformat}
181595 [DEBUG] GMS: - A: installing view [A|2] [A]
   [testng] 181596 [TRACE] GMS: - A: received all 1 ACKs from members for view [A|2]
   [testng] 181866 [TRACE] GMS: - view [A|3] [] is empty: will not multicast it (last view)
   [testng] 
   [testng] -------------------------------------------------------------------
   [testng] GMS: address=A, cluster=OverlappingMergeTest, physical address=10.16.94.42:27199
   [testng] -------------------------------------------------------------------
   [testng] 184954 [TRACE] GMS: - A: no initial members discovered: creating group as first member
   [testng] 184954 [DEBUG] GMS: - A: installing view [A|0] [A]
   [testng] 184955 [DEBUG] GMS: - created group (first member). My view is [A|0], impl is org.jgroups.protocols.pbcast.CoordGmsImpl
   [testng] 
   [testng] -------------------------------------------------------------------
   [testng] GMS: address=B, cluster=OverlappingMergeTest, physical address=10.16.94.42:27200
   [testng] -------------------------------------------------------------------
   [testng] 184961 [TRACE] GMS: - B: initial_mbrs are A 
   [testng] 184961 [DEBUG] GMS: - election results: {A=1}
   [testng] 184961 [DEBUG] GMS: - sending JOIN(B) to A
   [testng] 185013 [TRACE] GMS: - A: new members=[B], suspected=[], leaving=[], new view: [A|1] [A, B]
   [testng] 185014 [TRACE] GMS: - A: mcasting view [A|1] [A, B] (2 mbrs)
   [testng] 
   [testng] 185025 [DEBUG] GMS: - A: installing view [A|1] [A, B]
   [testng] 185026 [TRACE] GMS: - A: received all 1 ACKs from members for view [A|1]
   [testng] 185055 [TRACE] GMS: - B: JOIN-RSP=[A|1] [A, B] [size=2]
   [testng] 
   [testng] 
   [testng] 185055 [DEBUG] GMS: - B: installing view [A|1] [A, B]
   [testng] 185057 [TRACE] GMS: - A: received all ACKs (1) from joiners for view [A|1]
   [testng] 
   [testng] -------------------------------------------------------------------
   [testng] GMS: address=C, cluster=OverlappingMergeTest, physical address=10.16.94.42:27201
   [testng] -------------------------------------------------------------------
   [testng] 185064 [TRACE] GMS: - C: initial_mbrs are B A 
   [testng] 185064 [DEBUG] GMS: - election results: {A=2}
   [testng] 185064 [DEBUG] GMS: - sending JOIN(C) to A
   [testng] 185108 [TRACE] GMS: - A: new members=[C], suspected=[], leaving=[], new view: [A|2] [A, B, C]
   [testng] 185108 [TRACE] GMS: - A: mcasting view [A|2] [A, B, C] (3 mbrs)
   [testng] 
   [testng] 185117 [DEBUG] GMS: - A: installing view [A|2] [A, B, C]
   [testng] 185118 [DEBUG] GMS: - B: installing view [A|2] [A, B, C]
   [testng] 185119 [TRACE] GMS: - A: received all 2 ACKs from members for view [A|2]
   [testng] 185148 [TRACE] GMS: - C: JOIN-RSP=[A|2] [A, B, C] [size=3]
   [testng] 
   [testng] 
   [testng] 185149 [DEBUG] GMS: - C: installing view [A|2] [A, B, C]
   [testng] 185151 [TRACE] GMS: - A: received all ACKs (1) from joiners for view [A|2]
   [testng] 
   [testng] -------------------------------------------------------------------
   [testng] GMS: address=D, cluster=OverlappingMergeTest, physical address=10.16.94.42:27202
   [testng] -------------------------------------------------------------------
   [testng] 185164 [TRACE] GMS: - D: initial_mbrs are B C A 
   [testng] 185164 [DEBUG] GMS: - election results: {A=3}
   [testng] 185164 [DEBUG] GMS: - sending JOIN(D) to A
   [testng] 185203 [TRACE] GMS: - A: new members=[D], suspected=[], leaving=[], new view: [A|3] [A, B, C, D]
   [testng] 185203 [TRACE] GMS: - A: mcasting view [A|3] [A, B, C, D] (4 mbrs)
   [testng] 
   [testng] 185210 [DEBUG] GMS: - A: installing view [A|3] [A, B, C, D]
   [testng] 185211 [DEBUG] GMS: - B: installing view [A|3] [A, B, C, D]
   [testng] 185211 [DEBUG] GMS: - C: installing view [A|3] [A, B, C, D]
   [testng] 185213 [TRACE] GMS: - A: received all 3 ACKs from members for view [A|3]
   [testng] 185242 [TRACE] GMS: - D: JOIN-RSP=[A|3] [A, B, C, D] [size=4]
   [testng] 
   [testng] 
   [testng] 185242 [DEBUG] GMS: - D: installing view [A|3] [A, B, C, D]
   [testng] 185242 [TRACE] GMS: - A: received all ACKs (1) from joiners for view [A|3]
   [testng] 
   [testng]  ==== Injecting view [A|4] [A, C, B] into A, B and C ====
   [testng] 185243 [DEBUG] GMS: - A: installing view [A|4] [A, C, B]
   [testng] 185243 [DEBUG] GMS: - B: installing view [A|4] [A, C, B]
   [testng] 185244 [DEBUG] GMS: - C: installing view [A|4] [A, C, B]
   [testng] 
   [testng]  ==== Injecting view [B|4] [B, A, C, D] into D ====
   [testng] 
   [testng] 185245 [DEBUG] GMS: - D: installing view [B|4] [B, A, C, D]
   [testng] A: [A|4] [A, C, B]
   [testng] B: [A|4] [A, C, B]
   [testng] C: [A|4] [A, C, B]
   [testng] D: [B|4] [B, A, C, D]
   [testng] 
   [testng] ==== Injecting a merge event into A, B, C and D====
   [testng] 185251 [TRACE] GMS: - A: got merge response from A, merge_id=A::3, merge data is sender=A, view=[A|4] [A, C, B], digest=C: [0 (0)], B: [0 (0)], A: [4 (4)]
   [testng] 185253 [TRACE] GMS: - B: queue is suspended; request MERGE(4 views) is discarded
   [testng] 185255 [TRACE] GMS: - C: queue is suspended; request MERGE(4 views) is discarded
   [testng] 185255 [TRACE] GMS: - A: got merge response from B, merge_id=A::3, merge data is sender=B, view=[A|4] [A, C, B], digest=C: [0 (0)], B: [0 (1)], A: [4 (4)]
   [testng] 190286 [TRACE] GMS: - A: mcasting view MergeView::[A|5] [A, B, C], subgroups=[A|4] [A, C, B], [A|4] [A, C, B] (3 mbrs)
   [testng] 
   [testng] 190286 [TRACE] GMS: - B: mcasting view MergeView::[A|5] [A, B, C], subgroups=[A|4] [A, C, B], [A|4] [A, C, B] (3 mbrs)
   [testng] 
   [testng] 190317 [DEBUG] GMS: - A: installing view MergeView::[A|5] [A, B, C], subgroups=[A|4] [A, C, B], [A|4] [A, C, B]
   [testng] 190318 [DEBUG] GMS: - B: installing view MergeView::[A|5] [A, B, C], subgroups=[A|4] [A, C, B], [A|4] [A, C, B]
   [testng] 190318 [DEBUG] GMS: - C: installing view MergeView::[A|5] [A, B, C], subgroups=[A|4] [A, C, B], [A|4] [A, C, B]
   [testng] 190320 [TRACE] GMS: - A: received all 3 ACKs from members for view [A|5]
   [testng] 190320 [TRACE] GMS: - B: received all 3 ACKs from members for view [A|5]
   [testng] A: [A|5] [A, B, C] (coord=true)
   [testng] B: [A|5] [A, B, C] (coord=false)
   [testng] C: [A|5] [A, B, C] (coord=false)
   [testng] D: [B|4] [B, A, C, D] (coord=false)
   [testng] 195277 [DEBUG] GMS: - D: sending LEAVE request to B
   [testng] FAIL: [1] org.jgroups.tests.OverlappingMergeTest.testMergeWithDifferentPartitions()
{noformat}

 Whenever this test fails, I see that the queues are suspended on the initial merge attempt.


    
> OverlappingMergeTest testSameCreatorDifferentIDs fails to create correct merged view
> ------------------------------------------------------------------------------------
>
>                 Key: JGRP-1817
>                 URL: https://issues.jboss.org/browse/JGRP-1817
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.2.13
>         Environment: RHEL
>            Reporter: Richard Achmatowicz
>            Assignee: Bela Ban
>             Fix For: 3.2.14
>
>
> This test does the following:
> - creates three channels a,b,c
> - injects views A: {A|5 A}, B:{A|6 A,B}, C:{A|7 A,B,C} 
> - injects a merge event in each of channels A,B,C representing these four views
> - checks that all channels have the final view of size 3
> The test fails intermittently on RHEL, with the same failure each time:
> {noformat}
> -------------------------------------------------------------------
> GMS: address=A, cluster=OverlappingMergeTest, physical address=10.16.95.7:27215
> -------------------------------------------------------------------
> -------------------------------------------------------------------
> GMS: address=B, cluster=OverlappingMergeTest, physical address=10.16.95.7:27216
> -------------------------------------------------------------------
> -------------------------------------------------------------------
> GMS: address=C, cluster=OverlappingMergeTest, physical address=10.16.95.7:27217
> -------------------------------------------------------------------
> ------------- testSameCreatorDifferentIDs -----------
> [A] view=[A|5] [A]
> [B] view=[A|6] [A, B]
> [C] view=[A|7] [A, B, C]
> A's view: [A|5] [A]
> B's view: [A|6] [A, B]
> C's view: [A|7] [A, B, C]
> Enabling TRACE debugging for GMS, MERGE2 and Discovery
> ==== triggering merge solicitation ====:
> 212534 [TRACE] TCPPING: - A: sending discovery request to 10.16.95.7:27216
> 212537 [TRACE] TCPPING: - A: sending discovery request to 10.16.95.7:27218
> 212538 [TRACE] TCPPING: - A: sending discovery request to 10.16.95.7:27217
> 215538 [TRACE] TCPPING: - A: discovery took 3004 ms: responses: 1 total (1 servers (0 coord), 0 clients)
> 215539 [TRACE] MERGE2: - Discovery results:
> [B]: view_id=[A|6] ([A|6] [A, B])
> [A]: view_id=[A|5] ([A|5] [A])
> 215539 [DEBUG] MERGE2: - A found different views : [A|5], [A|6]; sending up MERGE event with merge participants [B, A].
> Discovery results:
> [B]: coord=A
> [A]: coord=A
> ==== checking views after merge ====:
> ....................Disabling TRACE debugging for GMS, MERGE2 and Discovery
> A's view: [A|7] [A, B]
> B's view: [A|7] [A, B]
> C's view: [A|7] [A, B, C]
> {noformat}
>  Whenever this test fails, it is the discovery phase which fails to find the correct set of views. Instead of finding views for channels A, B and C, it only finds views for channels A and B.
>  
> Also, the discovery requests  are sent to host:port combinations which are offset by 1. For example, in the case above, the host:port combinations of the channels are 10.16.95.7:27215, 10.16.95.7:27216, and 10.16.95.7:27217, but the pings go put to 10.16.95.7:27216, 10.16.95.7:27217, and 10.16.95.7:27218. Not sure if this is significant as it still covers the channels B and C.

--
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

From issues at jboss.org  Thu Mar 27 12:40:13 2014
From: issues at jboss.org (Richard Achmatowicz (JIRA))
Date: Thu, 27 Mar 2014 12:40:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1817) OverlappingMergeTest
 testSameCreatorDifferentIDs fails to create correct merged view
In-Reply-To: <JIRA.12536325.1395937598000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12536325.1395937598000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12536325.1395937598000.14294.1395938413592@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JGRP-1817?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Richard Achmatowicz updated JGRP-1817:
--------------------------------------

    Description: 
This test does the following:
- creates three channels a,b,c
- injects views 
{noformat}
A: {A|5 A}, B:{A|6 A,B}, C:{A|7 A,B,C} 
{noformat}
- injects a merge event in each of channels A,B,C representing these four views
- checks that all channels have the final view of size 3

The test fails intermittently on RHEL, with the same failure each time:

{noformat}
-------------------------------------------------------------------
GMS: address=A, cluster=OverlappingMergeTest, physical address=10.16.95.7:27215
-------------------------------------------------------------------
-------------------------------------------------------------------
GMS: address=B, cluster=OverlappingMergeTest, physical address=10.16.95.7:27216
-------------------------------------------------------------------
-------------------------------------------------------------------
GMS: address=C, cluster=OverlappingMergeTest, physical address=10.16.95.7:27217
-------------------------------------------------------------------

------------- testSameCreatorDifferentIDs -----------
[A] view=[A|5] [A]
[B] view=[A|6] [A, B]
[C] view=[A|7] [A, B, C]

A's view: [A|5] [A]
B's view: [A|6] [A, B]
C's view: [A|7] [A, B, C]
Enabling TRACE debugging for GMS, MERGE2 and Discovery

==== triggering merge solicitation ====:
212534 [TRACE] TCPPING: - A: sending discovery request to 10.16.95.7:27216
212537 [TRACE] TCPPING: - A: sending discovery request to 10.16.95.7:27218
212538 [TRACE] TCPPING: - A: sending discovery request to 10.16.95.7:27217
215538 [TRACE] TCPPING: - A: discovery took 3004 ms: responses: 1 total (1 servers (0 coord), 0 clients)
215539 [TRACE] MERGE2: - Discovery results:
[B]: view_id=[A|6] ([A|6] [A, B])
[A]: view_id=[A|5] ([A|5] [A])
215539 [DEBUG] MERGE2: - A found different views : [A|5], [A|6]; sending up MERGE event with merge participants [B, A].
Discovery results:
[B]: coord=A
[A]: coord=A

==== checking views after merge ====:
....................Disabling TRACE debugging for GMS, MERGE2 and Discovery

A's view: [A|7] [A, B]
B's view: [A|7] [A, B]
C's view: [A|7] [A, B, C]
{noformat}

 Whenever this test fails, it is the discovery phase which fails to find the correct set of views. Instead of finding views for channels A, B and C, it only finds views for channels A and B.
 
Also, the discovery requests  are sent to host:port combinations which are offset by 1. For example, in the case above, the host:port combinations of the channels are 10.16.95.7:27215, 10.16.95.7:27216, and 10.16.95.7:27217, but the pings go put to 10.16.95.7:27216, 10.16.95.7:27217, and 10.16.95.7:27218. Not sure if this is significant as it still covers the channels B and C.



  was:
This test does the following:
- creates three channels a,b,c
- injects views A: {A|5 A}, B:{A|6 A,B}, C:{A|7 A,B,C} 
- injects a merge event in each of channels A,B,C representing these four views
- checks that all channels have the final view of size 3

The test fails intermittently on RHEL, with the same failure each time:

{noformat}
-------------------------------------------------------------------
GMS: address=A, cluster=OverlappingMergeTest, physical address=10.16.95.7:27215
-------------------------------------------------------------------
-------------------------------------------------------------------
GMS: address=B, cluster=OverlappingMergeTest, physical address=10.16.95.7:27216
-------------------------------------------------------------------
-------------------------------------------------------------------
GMS: address=C, cluster=OverlappingMergeTest, physical address=10.16.95.7:27217
-------------------------------------------------------------------

------------- testSameCreatorDifferentIDs -----------
[A] view=[A|5] [A]
[B] view=[A|6] [A, B]
[C] view=[A|7] [A, B, C]

A's view: [A|5] [A]
B's view: [A|6] [A, B]
C's view: [A|7] [A, B, C]
Enabling TRACE debugging for GMS, MERGE2 and Discovery

==== triggering merge solicitation ====:
212534 [TRACE] TCPPING: - A: sending discovery request to 10.16.95.7:27216
212537 [TRACE] TCPPING: - A: sending discovery request to 10.16.95.7:27218
212538 [TRACE] TCPPING: - A: sending discovery request to 10.16.95.7:27217
215538 [TRACE] TCPPING: - A: discovery took 3004 ms: responses: 1 total (1 servers (0 coord), 0 clients)
215539 [TRACE] MERGE2: - Discovery results:
[B]: view_id=[A|6] ([A|6] [A, B])
[A]: view_id=[A|5] ([A|5] [A])
215539 [DEBUG] MERGE2: - A found different views : [A|5], [A|6]; sending up MERGE event with merge participants [B, A].
Discovery results:
[B]: coord=A
[A]: coord=A

==== checking views after merge ====:
....................Disabling TRACE debugging for GMS, MERGE2 and Discovery

A's view: [A|7] [A, B]
B's view: [A|7] [A, B]
C's view: [A|7] [A, B, C]
{noformat}

 Whenever this test fails, it is the discovery phase which fails to find the correct set of views. Instead of finding views for channels A, B and C, it only finds views for channels A and B.
 
Also, the discovery requests  are sent to host:port combinations which are offset by 1. For example, in the case above, the host:port combinations of the channels are 10.16.95.7:27215, 10.16.95.7:27216, and 10.16.95.7:27217, but the pings go put to 10.16.95.7:27216, 10.16.95.7:27217, and 10.16.95.7:27218. Not sure if this is significant as it still covers the channels B and C.




    
> OverlappingMergeTest testSameCreatorDifferentIDs fails to create correct merged view
> ------------------------------------------------------------------------------------
>
>                 Key: JGRP-1817
>                 URL: https://issues.jboss.org/browse/JGRP-1817
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.2.13
>         Environment: RHEL
>            Reporter: Richard Achmatowicz
>            Assignee: Bela Ban
>             Fix For: 3.2.14
>
>
> This test does the following:
> - creates three channels a,b,c
> - injects views 
> {noformat}
> A: {A|5 A}, B:{A|6 A,B}, C:{A|7 A,B,C} 
> {noformat}
> - injects a merge event in each of channels A,B,C representing these four views
> - checks that all channels have the final view of size 3
> The test fails intermittently on RHEL, with the same failure each time:
> {noformat}
> -------------------------------------------------------------------
> GMS: address=A, cluster=OverlappingMergeTest, physical address=10.16.95.7:27215
> -------------------------------------------------------------------
> -------------------------------------------------------------------
> GMS: address=B, cluster=OverlappingMergeTest, physical address=10.16.95.7:27216
> -------------------------------------------------------------------
> -------------------------------------------------------------------
> GMS: address=C, cluster=OverlappingMergeTest, physical address=10.16.95.7:27217
> -------------------------------------------------------------------
> ------------- testSameCreatorDifferentIDs -----------
> [A] view=[A|5] [A]
> [B] view=[A|6] [A, B]
> [C] view=[A|7] [A, B, C]
> A's view: [A|5] [A]
> B's view: [A|6] [A, B]
> C's view: [A|7] [A, B, C]
> Enabling TRACE debugging for GMS, MERGE2 and Discovery
> ==== triggering merge solicitation ====:
> 212534 [TRACE] TCPPING: - A: sending discovery request to 10.16.95.7:27216
> 212537 [TRACE] TCPPING: - A: sending discovery request to 10.16.95.7:27218
> 212538 [TRACE] TCPPING: - A: sending discovery request to 10.16.95.7:27217
> 215538 [TRACE] TCPPING: - A: discovery took 3004 ms: responses: 1 total (1 servers (0 coord), 0 clients)
> 215539 [TRACE] MERGE2: - Discovery results:
> [B]: view_id=[A|6] ([A|6] [A, B])
> [A]: view_id=[A|5] ([A|5] [A])
> 215539 [DEBUG] MERGE2: - A found different views : [A|5], [A|6]; sending up MERGE event with merge participants [B, A].
> Discovery results:
> [B]: coord=A
> [A]: coord=A
> ==== checking views after merge ====:
> ....................Disabling TRACE debugging for GMS, MERGE2 and Discovery
> A's view: [A|7] [A, B]
> B's view: [A|7] [A, B]
> C's view: [A|7] [A, B, C]
> {noformat}
>  Whenever this test fails, it is the discovery phase which fails to find the correct set of views. Instead of finding views for channels A, B and C, it only finds views for channels A and B.
>  
> Also, the discovery requests  are sent to host:port combinations which are offset by 1. For example, in the case above, the host:port combinations of the channels are 10.16.95.7:27215, 10.16.95.7:27216, and 10.16.95.7:27217, but the pings go put to 10.16.95.7:27216, 10.16.95.7:27217, and 10.16.95.7:27218. Not sure if this is significant as it still covers the channels B and C.

--
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

From issues at jboss.org  Thu Mar 27 12:40:14 2014
From: issues at jboss.org (Akhbar Falafel (JIRA))
Date: Thu, 27 Mar 2014 12:40:14 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3181) Hibernate Search w/
 Infinispan - java.lang.Class cannot be cast to java.util.Map
In-Reply-To: <JIRA.12536328.1395938405746@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12536328.1395938405746@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12536328.1395938405746.14305.1395938414132@jira02.app.mwc.hst.phx2.redhat.com>

Akhbar Falafel created WFLY-3181:
------------------------------------

             Summary: Hibernate Search w/ Infinispan - java.lang.Class cannot be cast to java.util.Map
                 Key: WFLY-3181
                 URL: https://issues.jboss.org/browse/WFLY-3181
             Project: WildFly
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: JPA / Hibernate
    Affects Versions: 8.0.0.Final
         Environment: Wildfly 8.0, OS X 10.9.2
            Reporter: Akhbar Falafel
            Assignee: Scott Marlow


When configuring Hibernate Search to use Infinispan as its directory provider, a java.lang.ClassCastException occurs upon deployment of an application making use of Hibernate Search.

Relevant portion of standalone-full-ha.xml:

            <cache-container name="hibernateSearch" default-cache="LuceneIndexesData" jndi-name="java:jboss/infinispan/hibernateSearch" start="EAGER" statistics-enabled="true">
                <transport lock-timeout="60000"/>
                <replicated-cache name="LuceneIndexesMetadata" start="EAGER" statistics-enabled="true" mode="SYNC">
                    <binary-keyed-jdbc-store shared="true" preload="true" passivation="false" purge="false" datasource="java:jboss/datasources/InfinispanDatasource">
                        <binary-keyed-table>
                            <id-column name="ID_COLUMN" type="VARCHAR(255)"/>
                            <data-column name="DATUM" type="BYTEA"/>
                        </binary-keyed-table>
                    </binary-keyed-jdbc-store>
                </replicated-cache>
                <replicated-cache name="LuceneIndexesData" start="EAGER" statistics-enabled="true" mode="SYNC">
                    <binary-keyed-jdbc-store shared="true" preload="true" passivation="false" purge="false" datasource="java:jboss/datasources/InfinispanDatasource">
                        <binary-keyed-table>
                            <id-column name="ID_COLUMN" type="VARCHAR(255)"/>
                            <data-column name="DATUM" type="BYTEA"/>
                        </binary-keyed-table>
                    </binary-keyed-jdbc-store>
                </replicated-cache>
                <replicated-cache name="LuceneIndexesLocking" start="EAGER" statistics-enabled="true" mode="SYNC"/>
            </cache-container>


Relevant portion of persistence.xml:

			<!-- Hibernate Search properties - Infinispan -->
			<property name="hibernate.search.infinispan.cachemanager_jndiname"
				value="java:jboss/infinispan/hibernateSearch" />
			<property name="hibernate.search.default.directory_provider"
				value="infinispan" />
			<property name="hibernate.search.infinispan.chunk_size"
				value="300000000" />
			<property name="hibernate.search.reader.strategy" value="shared" />
			<property name="hibernate.search.worker.execution" value="sync" />
			<property name="hibernate.search.jmx_enabled" value="true" />
			<property name="hibernate.search.autoregister_listeners"
				value="true" />


Stack trace of Exception upon deployment:

12:35:09,837 DEBUG [org.jboss.jca.core.connectionmanager.pool.strategy.OnePool] (ServerService Thread Pool -- 62) InfinispanDS: returnConnection(3ea8c21b, false) [1/20]
12:35:09,837 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 62) MSC000001: Failed to start service jboss.infinispan.hibernateSearch.LuceneIndexesData: org.jboss.msc.service.StartException in service jboss.infinispan.hibernateSearch.LuceneIndexesData: org.infinispan.commons.CacheException: Unable to invoke method public void org.infinispan.persistence.manager.PersistenceManagerImpl.preload() on object of type PersistenceManagerImpl
	at org.jboss.as.clustering.msc.AsynchronousService$1.run(AsynchronousService.java:91) [wildfly-clustering-common-8.0.0.Final.jar:8.0.0.Final]
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_51]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_51]
	at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_51]
	at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.1.Final.jar:2.1.1.Final]
Caused by: org.infinispan.commons.CacheException: Unable to invoke method public void org.infinispan.persistence.manager.PersistenceManagerImpl.preload() on object of type PersistenceManagerImpl
	at org.infinispan.commons.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:185)
	at org.infinispan.factories.AbstractComponentRegistry$PrioritizedMethod.invoke(AbstractComponentRegistry.java:869)
	at org.infinispan.factories.AbstractComponentRegistry.invokeStartMethods(AbstractComponentRegistry.java:638)
	at org.infinispan.factories.AbstractComponentRegistry.internalStart(AbstractComponentRegistry.java:627)
	at org.infinispan.factories.AbstractComponentRegistry.start(AbstractComponentRegistry.java:530)
	at org.infinispan.factories.ComponentRegistry.start(ComponentRegistry.java:216)
	at org.infinispan.CacheImpl.start(CacheImpl.java:675)
	at org.infinispan.manager.DefaultCacheManager.wireAndStartCache(DefaultCacheManager.java:553)
	at org.infinispan.manager.DefaultCacheManager.createCache(DefaultCacheManager.java:516)
	at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:398)
	at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:412)
	at org.jboss.as.clustering.infinispan.DefaultCacheContainer.getCache(DefaultCacheContainer.java:103)
	at org.jboss.as.clustering.infinispan.DefaultCacheContainer.getCache(DefaultCacheContainer.java:94)
	at org.jboss.as.clustering.infinispan.subsystem.CacheService.start(CacheService.java:78)
	at org.jboss.as.clustering.msc.AsynchronousService$1.run(AsynchronousService.java:86) [wildfly-clustering-common-8.0.0.Final.jar:8.0.0.Final]
	... 4 more
Caused by: java.lang.ClassCastException: java.lang.Class cannot be cast to java.util.Map
	at org.infinispan.persistence.jdbc.binary.JdbcBinaryStore.unmarshallBucket(JdbcBinaryStore.java:577)
	at org.infinispan.persistence.jdbc.binary.JdbcBinaryStore.process(JdbcBinaryStore.java:190)
	at org.infinispan.persistence.manager.PersistenceManagerImpl.preload(PersistenceManagerImpl.java:214)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_51]
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_51]
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_51]
	at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_51]
	at org.infinispan.commons.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:183)
	... 18 more

12:35:09,837 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 66) MSC000001: Failed to start service jboss.infinispan.hibernateSearch.LuceneIndexesMetadata: org.jboss.msc.service.StartException in service jboss.infinispan.hibernateSearch.LuceneIndexesMetadata: org.infinispan.commons.CacheException: Unable to invoke method public void org.infinispan.persistence.manager.PersistenceManagerImpl.preload() on object of type PersistenceManagerImpl
	at org.jboss.as.clustering.msc.AsynchronousService$1.run(AsynchronousService.java:91) [wildfly-clustering-common-8.0.0.Final.jar:8.0.0.Final]
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_51]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_51]
	at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_51]
	at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.1.Final.jar:2.1.1.Final]
Caused by: org.infinispan.commons.CacheException: Unable to invoke method public void org.infinispan.persistence.manager.PersistenceManagerImpl.preload() on object of type PersistenceManagerImpl
	at org.infinispan.commons.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:185)
	at org.infinispan.factories.AbstractComponentRegistry$PrioritizedMethod.invoke(AbstractComponentRegistry.java:869)
	at org.infinispan.factories.AbstractComponentRegistry.invokeStartMethods(AbstractComponentRegistry.java:638)
	at org.infinispan.factories.AbstractComponentRegistry.internalStart(AbstractComponentRegistry.java:627)
	at org.infinispan.factories.AbstractComponentRegistry.start(AbstractComponentRegistry.java:530)
	at org.infinispan.factories.ComponentRegistry.start(ComponentRegistry.java:216)
	at org.infinispan.CacheImpl.start(CacheImpl.java:675)
	at org.infinispan.manager.DefaultCacheManager.wireAndStartCache(DefaultCacheManager.java:553)
	at org.infinispan.manager.DefaultCacheManager.createCache(DefaultCacheManager.java:516)
	at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:398)
	at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:412)
	at org.jboss.as.clustering.infinispan.DefaultCacheContainer.getCache(DefaultCacheContainer.java:103)
	at org.jboss.as.clustering.infinispan.DefaultCacheContainer.getCache(DefaultCacheContainer.java:94)
	at org.jboss.as.clustering.infinispan.subsystem.CacheService.start(CacheService.java:78)
	at org.jboss.as.clustering.msc.AsynchronousService$1.run(AsynchronousService.java:86) [wildfly-clustering-common-8.0.0.Final.jar:8.0.0.Final]
	... 4 more
Caused by: java.lang.ClassCastException: java.lang.Class cannot be cast to java.util.Map
	at org.infinispan.persistence.jdbc.binary.JdbcBinaryStore.unmarshallBucket(JdbcBinaryStore.java:577)
	at org.infinispan.persistence.jdbc.binary.JdbcBinaryStore.process(JdbcBinaryStore.java:190)
	at org.infinispan.persistence.manager.PersistenceManagerImpl.preload(PersistenceManagerImpl.java:214)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_51]
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_51]
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_51]
	at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_51]
	at org.infinispan.commons.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:183)
	... 18 more


--
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

From issues at jboss.org  Thu Mar 27 12:44:13 2014
From: issues at jboss.org (Tomaz Cerar (JIRA))
Date: Thu, 27 Mar 2014 12:44:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3181) Hibernate Search w/
 Infinispan - java.lang.Class cannot be cast to java.util.Map
In-Reply-To: <JIRA.12536328.1395938405000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12536328.1395938405000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12536328.1395938405000.14315.1395938653282@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-3181?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tomaz Cerar reassigned WFLY-3181:
---------------------------------

    Assignee: Sanne Grinovero  (was: Scott Marlow)

    
> Hibernate Search w/ Infinispan - java.lang.Class cannot be cast to java.util.Map
> --------------------------------------------------------------------------------
>
>                 Key: WFLY-3181
>                 URL: https://issues.jboss.org/browse/WFLY-3181
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: JPA / Hibernate
>    Affects Versions: 8.0.0.Final
>         Environment: Wildfly 8.0, OS X 10.9.2
>            Reporter: Akhbar Falafel
>            Assignee: Sanne Grinovero
>
> When configuring Hibernate Search to use Infinispan as its directory provider, a java.lang.ClassCastException occurs upon deployment of an application making use of Hibernate Search.
> Relevant portion of standalone-full-ha.xml:
>             <cache-container name="hibernateSearch" default-cache="LuceneIndexesData" jndi-name="java:jboss/infinispan/hibernateSearch" start="EAGER" statistics-enabled="true">
>                 <transport lock-timeout="60000"/>
>                 <replicated-cache name="LuceneIndexesMetadata" start="EAGER" statistics-enabled="true" mode="SYNC">
>                     <binary-keyed-jdbc-store shared="true" preload="true" passivation="false" purge="false" datasource="java:jboss/datasources/InfinispanDatasource">
>                         <binary-keyed-table>
>                             <id-column name="ID_COLUMN" type="VARCHAR(255)"/>
>                             <data-column name="DATUM" type="BYTEA"/>
>                         </binary-keyed-table>
>                     </binary-keyed-jdbc-store>
>                 </replicated-cache>
>                 <replicated-cache name="LuceneIndexesData" start="EAGER" statistics-enabled="true" mode="SYNC">
>                     <binary-keyed-jdbc-store shared="true" preload="true" passivation="false" purge="false" datasource="java:jboss/datasources/InfinispanDatasource">
>                         <binary-keyed-table>
>                             <id-column name="ID_COLUMN" type="VARCHAR(255)"/>
>                             <data-column name="DATUM" type="BYTEA"/>
>                         </binary-keyed-table>
>                     </binary-keyed-jdbc-store>
>                 </replicated-cache>
>                 <replicated-cache name="LuceneIndexesLocking" start="EAGER" statistics-enabled="true" mode="SYNC"/>
>             </cache-container>
> Relevant portion of persistence.xml:
> 			<!-- Hibernate Search properties - Infinispan -->
> 			<property name="hibernate.search.infinispan.cachemanager_jndiname"
> 				value="java:jboss/infinispan/hibernateSearch" />
> 			<property name="hibernate.search.default.directory_provider"
> 				value="infinispan" />
> 			<property name="hibernate.search.infinispan.chunk_size"
> 				value="300000000" />
> 			<property name="hibernate.search.reader.strategy" value="shared" />
> 			<property name="hibernate.search.worker.execution" value="sync" />
> 			<property name="hibernate.search.jmx_enabled" value="true" />
> 			<property name="hibernate.search.autoregister_listeners"
> 				value="true" />
> Stack trace of Exception upon deployment:
> 12:35:09,837 DEBUG [org.jboss.jca.core.connectionmanager.pool.strategy.OnePool] (ServerService Thread Pool -- 62) InfinispanDS: returnConnection(3ea8c21b, false) [1/20]
> 12:35:09,837 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 62) MSC000001: Failed to start service jboss.infinispan.hibernateSearch.LuceneIndexesData: org.jboss.msc.service.StartException in service jboss.infinispan.hibernateSearch.LuceneIndexesData: org.infinispan.commons.CacheException: Unable to invoke method public void org.infinispan.persistence.manager.PersistenceManagerImpl.preload() on object of type PersistenceManagerImpl
> 	at org.jboss.as.clustering.msc.AsynchronousService$1.run(AsynchronousService.java:91) [wildfly-clustering-common-8.0.0.Final.jar:8.0.0.Final]
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_51]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_51]
> 	at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_51]
> 	at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.1.Final.jar:2.1.1.Final]
> Caused by: org.infinispan.commons.CacheException: Unable to invoke method public void org.infinispan.persistence.manager.PersistenceManagerImpl.preload() on object of type PersistenceManagerImpl
> 	at org.infinispan.commons.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:185)
> 	at org.infinispan.factories.AbstractComponentRegistry$PrioritizedMethod.invoke(AbstractComponentRegistry.java:869)
> 	at org.infinispan.factories.AbstractComponentRegistry.invokeStartMethods(AbstractComponentRegistry.java:638)
> 	at org.infinispan.factories.AbstractComponentRegistry.internalStart(AbstractComponentRegistry.java:627)
> 	at org.infinispan.factories.AbstractComponentRegistry.start(AbstractComponentRegistry.java:530)
> 	at org.infinispan.factories.ComponentRegistry.start(ComponentRegistry.java:216)
> 	at org.infinispan.CacheImpl.start(CacheImpl.java:675)
> 	at org.infinispan.manager.DefaultCacheManager.wireAndStartCache(DefaultCacheManager.java:553)
> 	at org.infinispan.manager.DefaultCacheManager.createCache(DefaultCacheManager.java:516)
> 	at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:398)
> 	at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:412)
> 	at org.jboss.as.clustering.infinispan.DefaultCacheContainer.getCache(DefaultCacheContainer.java:103)
> 	at org.jboss.as.clustering.infinispan.DefaultCacheContainer.getCache(DefaultCacheContainer.java:94)
> 	at org.jboss.as.clustering.infinispan.subsystem.CacheService.start(CacheService.java:78)
> 	at org.jboss.as.clustering.msc.AsynchronousService$1.run(AsynchronousService.java:86) [wildfly-clustering-common-8.0.0.Final.jar:8.0.0.Final]
> 	... 4 more
> Caused by: java.lang.ClassCastException: java.lang.Class cannot be cast to java.util.Map
> 	at org.infinispan.persistence.jdbc.binary.JdbcBinaryStore.unmarshallBucket(JdbcBinaryStore.java:577)
> 	at org.infinispan.persistence.jdbc.binary.JdbcBinaryStore.process(JdbcBinaryStore.java:190)
> 	at org.infinispan.persistence.manager.PersistenceManagerImpl.preload(PersistenceManagerImpl.java:214)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_51]
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_51]
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_51]
> 	at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_51]
> 	at org.infinispan.commons.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:183)
> 	... 18 more
> 12:35:09,837 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 66) MSC000001: Failed to start service jboss.infinispan.hibernateSearch.LuceneIndexesMetadata: org.jboss.msc.service.StartException in service jboss.infinispan.hibernateSearch.LuceneIndexesMetadata: org.infinispan.commons.CacheException: Unable to invoke method public void org.infinispan.persistence.manager.PersistenceManagerImpl.preload() on object of type PersistenceManagerImpl
> 	at org.jboss.as.clustering.msc.AsynchronousService$1.run(AsynchronousService.java:91) [wildfly-clustering-common-8.0.0.Final.jar:8.0.0.Final]
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_51]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_51]
> 	at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_51]
> 	at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.1.Final.jar:2.1.1.Final]
> Caused by: org.infinispan.commons.CacheException: Unable to invoke method public void org.infinispan.persistence.manager.PersistenceManagerImpl.preload() on object of type PersistenceManagerImpl
> 	at org.infinispan.commons.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:185)
> 	at org.infinispan.factories.AbstractComponentRegistry$PrioritizedMethod.invoke(AbstractComponentRegistry.java:869)
> 	at org.infinispan.factories.AbstractComponentRegistry.invokeStartMethods(AbstractComponentRegistry.java:638)
> 	at org.infinispan.factories.AbstractComponentRegistry.internalStart(AbstractComponentRegistry.java:627)
> 	at org.infinispan.factories.AbstractComponentRegistry.start(AbstractComponentRegistry.java:530)
> 	at org.infinispan.factories.ComponentRegistry.start(ComponentRegistry.java:216)
> 	at org.infinispan.CacheImpl.start(CacheImpl.java:675)
> 	at org.infinispan.manager.DefaultCacheManager.wireAndStartCache(DefaultCacheManager.java:553)
> 	at org.infinispan.manager.DefaultCacheManager.createCache(DefaultCacheManager.java:516)
> 	at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:398)
> 	at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:412)
> 	at org.jboss.as.clustering.infinispan.DefaultCacheContainer.getCache(DefaultCacheContainer.java:103)
> 	at org.jboss.as.clustering.infinispan.DefaultCacheContainer.getCache(DefaultCacheContainer.java:94)
> 	at org.jboss.as.clustering.infinispan.subsystem.CacheService.start(CacheService.java:78)
> 	at org.jboss.as.clustering.msc.AsynchronousService$1.run(AsynchronousService.java:86) [wildfly-clustering-common-8.0.0.Final.jar:8.0.0.Final]
> 	... 4 more
> Caused by: java.lang.ClassCastException: java.lang.Class cannot be cast to java.util.Map
> 	at org.infinispan.persistence.jdbc.binary.JdbcBinaryStore.unmarshallBucket(JdbcBinaryStore.java:577)
> 	at org.infinispan.persistence.jdbc.binary.JdbcBinaryStore.process(JdbcBinaryStore.java:190)
> 	at org.infinispan.persistence.manager.PersistenceManagerImpl.preload(PersistenceManagerImpl.java:214)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_51]
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_51]
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_51]
> 	at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_51]
> 	at org.infinispan.commons.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:183)
> 	... 18 more

--
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

From issues at jboss.org  Thu Mar 27 12:46:14 2014
From: issues at jboss.org (Tomaz Cerar (JIRA))
Date: Thu, 27 Mar 2014 12:46:14 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3181) Hibernate Search w/
 Infinispan - java.lang.Class cannot be cast to java.util.Map
In-Reply-To: <JIRA.12536328.1395938405000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12536328.1395938405000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12536328.1395938405000.14319.1395938774342@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-3181?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tomaz Cerar updated WFLY-3181:
------------------------------

    Description: 
When configuring Hibernate Search to use Infinispan as its directory provider, a java.lang.ClassCastException occurs upon deployment of an application making use of Hibernate Search.

Relevant portion of standalone-full-ha.xml:
{code:xml}
            <cache-container name="hibernateSearch" default-cache="LuceneIndexesData" jndi-name="java:jboss/infinispan/hibernateSearch" start="EAGER" statistics-enabled="true">
                <transport lock-timeout="60000"/>
                <replicated-cache name="LuceneIndexesMetadata" start="EAGER" statistics-enabled="true" mode="SYNC">
                    <binary-keyed-jdbc-store shared="true" preload="true" passivation="false" purge="false" datasource="java:jboss/datasources/InfinispanDatasource">
                        <binary-keyed-table>
                            <id-column name="ID_COLUMN" type="VARCHAR(255)"/>
                            <data-column name="DATUM" type="BYTEA"/>
                        </binary-keyed-table>
                    </binary-keyed-jdbc-store>
                </replicated-cache>
                <replicated-cache name="LuceneIndexesData" start="EAGER" statistics-enabled="true" mode="SYNC">
                    <binary-keyed-jdbc-store shared="true" preload="true" passivation="false" purge="false" datasource="java:jboss/datasources/InfinispanDatasource">
                        <binary-keyed-table>
                            <id-column name="ID_COLUMN" type="VARCHAR(255)"/>
                            <data-column name="DATUM" type="BYTEA"/>
                        </binary-keyed-table>
                    </binary-keyed-jdbc-store>
                </replicated-cache>
                <replicated-cache name="LuceneIndexesLocking" start="EAGER" statistics-enabled="true" mode="SYNC"/>
            </cache-container>
{code}

Relevant portion of persistence.xml:
{code:xml}
			<!-- Hibernate Search properties - Infinispan -->
			<property name="hibernate.search.infinispan.cachemanager_jndiname"
				value="java:jboss/infinispan/hibernateSearch" />
			<property name="hibernate.search.default.directory_provider"
				value="infinispan" />
			<property name="hibernate.search.infinispan.chunk_size"
				value="300000000" />
			<property name="hibernate.search.reader.strategy" value="shared" />
			<property name="hibernate.search.worker.execution" value="sync" />
			<property name="hibernate.search.jmx_enabled" value="true" />
			<property name="hibernate.search.autoregister_listeners"
				value="true" />
{code}

Stack trace of Exception upon deployment:

{noformat}
12:35:09,837 DEBUG [org.jboss.jca.core.connectionmanager.pool.strategy.OnePool] (ServerService Thread Pool -- 62) InfinispanDS: returnConnection(3ea8c21b, false) [1/20]
12:35:09,837 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 62) MSC000001: Failed to start service jboss.infinispan.hibernateSearch.LuceneIndexesData: org.jboss.msc.service.StartException in service jboss.infinispan.hibernateSearch.LuceneIndexesData: org.infinispan.commons.CacheException: Unable to invoke method public void org.infinispan.persistence.manager.PersistenceManagerImpl.preload() on object of type PersistenceManagerImpl
	at org.jboss.as.clustering.msc.AsynchronousService$1.run(AsynchronousService.java:91) [wildfly-clustering-common-8.0.0.Final.jar:8.0.0.Final]
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_51]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_51]
	at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_51]
	at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.1.Final.jar:2.1.1.Final]
Caused by: org.infinispan.commons.CacheException: Unable to invoke method public void org.infinispan.persistence.manager.PersistenceManagerImpl.preload() on object of type PersistenceManagerImpl
	at org.infinispan.commons.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:185)
	at org.infinispan.factories.AbstractComponentRegistry$PrioritizedMethod.invoke(AbstractComponentRegistry.java:869)
	at org.infinispan.factories.AbstractComponentRegistry.invokeStartMethods(AbstractComponentRegistry.java:638)
	at org.infinispan.factories.AbstractComponentRegistry.internalStart(AbstractComponentRegistry.java:627)
	at org.infinispan.factories.AbstractComponentRegistry.start(AbstractComponentRegistry.java:530)
	at org.infinispan.factories.ComponentRegistry.start(ComponentRegistry.java:216)
	at org.infinispan.CacheImpl.start(CacheImpl.java:675)
	at org.infinispan.manager.DefaultCacheManager.wireAndStartCache(DefaultCacheManager.java:553)
	at org.infinispan.manager.DefaultCacheManager.createCache(DefaultCacheManager.java:516)
	at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:398)
	at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:412)
	at org.jboss.as.clustering.infinispan.DefaultCacheContainer.getCache(DefaultCacheContainer.java:103)
	at org.jboss.as.clustering.infinispan.DefaultCacheContainer.getCache(DefaultCacheContainer.java:94)
	at org.jboss.as.clustering.infinispan.subsystem.CacheService.start(CacheService.java:78)
	at org.jboss.as.clustering.msc.AsynchronousService$1.run(AsynchronousService.java:86) [wildfly-clustering-common-8.0.0.Final.jar:8.0.0.Final]
	... 4 more
Caused by: java.lang.ClassCastException: java.lang.Class cannot be cast to java.util.Map
	at org.infinispan.persistence.jdbc.binary.JdbcBinaryStore.unmarshallBucket(JdbcBinaryStore.java:577)
	at org.infinispan.persistence.jdbc.binary.JdbcBinaryStore.process(JdbcBinaryStore.java:190)
	at org.infinispan.persistence.manager.PersistenceManagerImpl.preload(PersistenceManagerImpl.java:214)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_51]
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_51]
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_51]
	at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_51]
	at org.infinispan.commons.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:183)
	... 18 more

12:35:09,837 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 66) MSC000001: Failed to start service jboss.infinispan.hibernateSearch.LuceneIndexesMetadata: org.jboss.msc.service.StartException in service jboss.infinispan.hibernateSearch.LuceneIndexesMetadata: org.infinispan.commons.CacheException: Unable to invoke method public void org.infinispan.persistence.manager.PersistenceManagerImpl.preload() on object of type PersistenceManagerImpl
	at org.jboss.as.clustering.msc.AsynchronousService$1.run(AsynchronousService.java:91) [wildfly-clustering-common-8.0.0.Final.jar:8.0.0.Final]
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_51]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_51]
	at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_51]
	at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.1.Final.jar:2.1.1.Final]
Caused by: org.infinispan.commons.CacheException: Unable to invoke method public void org.infinispan.persistence.manager.PersistenceManagerImpl.preload() on object of type PersistenceManagerImpl
	at org.infinispan.commons.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:185)
	at org.infinispan.factories.AbstractComponentRegistry$PrioritizedMethod.invoke(AbstractComponentRegistry.java:869)
	at org.infinispan.factories.AbstractComponentRegistry.invokeStartMethods(AbstractComponentRegistry.java:638)
	at org.infinispan.factories.AbstractComponentRegistry.internalStart(AbstractComponentRegistry.java:627)
	at org.infinispan.factories.AbstractComponentRegistry.start(AbstractComponentRegistry.java:530)
	at org.infinispan.factories.ComponentRegistry.start(ComponentRegistry.java:216)
	at org.infinispan.CacheImpl.start(CacheImpl.java:675)
	at org.infinispan.manager.DefaultCacheManager.wireAndStartCache(DefaultCacheManager.java:553)
	at org.infinispan.manager.DefaultCacheManager.createCache(DefaultCacheManager.java:516)
	at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:398)
	at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:412)
	at org.jboss.as.clustering.infinispan.DefaultCacheContainer.getCache(DefaultCacheContainer.java:103)
	at org.jboss.as.clustering.infinispan.DefaultCacheContainer.getCache(DefaultCacheContainer.java:94)
	at org.jboss.as.clustering.infinispan.subsystem.CacheService.start(CacheService.java:78)
	at org.jboss.as.clustering.msc.AsynchronousService$1.run(AsynchronousService.java:86) [wildfly-clustering-common-8.0.0.Final.jar:8.0.0.Final]
	... 4 more
Caused by: java.lang.ClassCastException: java.lang.Class cannot be cast to java.util.Map
	at org.infinispan.persistence.jdbc.binary.JdbcBinaryStore.unmarshallBucket(JdbcBinaryStore.java:577)
	at org.infinispan.persistence.jdbc.binary.JdbcBinaryStore.process(JdbcBinaryStore.java:190)
	at org.infinispan.persistence.manager.PersistenceManagerImpl.preload(PersistenceManagerImpl.java:214)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_51]
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_51]
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_51]
	at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_51]
	at org.infinispan.commons.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:183)
	... 18 more
{noformat}

  was:
When configuring Hibernate Search to use Infinispan as its directory provider, a java.lang.ClassCastException occurs upon deployment of an application making use of Hibernate Search.

Relevant portion of standalone-full-ha.xml:

            <cache-container name="hibernateSearch" default-cache="LuceneIndexesData" jndi-name="java:jboss/infinispan/hibernateSearch" start="EAGER" statistics-enabled="true">
                <transport lock-timeout="60000"/>
                <replicated-cache name="LuceneIndexesMetadata" start="EAGER" statistics-enabled="true" mode="SYNC">
                    <binary-keyed-jdbc-store shared="true" preload="true" passivation="false" purge="false" datasource="java:jboss/datasources/InfinispanDatasource">
                        <binary-keyed-table>
                            <id-column name="ID_COLUMN" type="VARCHAR(255)"/>
                            <data-column name="DATUM" type="BYTEA"/>
                        </binary-keyed-table>
                    </binary-keyed-jdbc-store>
                </replicated-cache>
                <replicated-cache name="LuceneIndexesData" start="EAGER" statistics-enabled="true" mode="SYNC">
                    <binary-keyed-jdbc-store shared="true" preload="true" passivation="false" purge="false" datasource="java:jboss/datasources/InfinispanDatasource">
                        <binary-keyed-table>
                            <id-column name="ID_COLUMN" type="VARCHAR(255)"/>
                            <data-column name="DATUM" type="BYTEA"/>
                        </binary-keyed-table>
                    </binary-keyed-jdbc-store>
                </replicated-cache>
                <replicated-cache name="LuceneIndexesLocking" start="EAGER" statistics-enabled="true" mode="SYNC"/>
            </cache-container>


Relevant portion of persistence.xml:

			<!-- Hibernate Search properties - Infinispan -->
			<property name="hibernate.search.infinispan.cachemanager_jndiname"
				value="java:jboss/infinispan/hibernateSearch" />
			<property name="hibernate.search.default.directory_provider"
				value="infinispan" />
			<property name="hibernate.search.infinispan.chunk_size"
				value="300000000" />
			<property name="hibernate.search.reader.strategy" value="shared" />
			<property name="hibernate.search.worker.execution" value="sync" />
			<property name="hibernate.search.jmx_enabled" value="true" />
			<property name="hibernate.search.autoregister_listeners"
				value="true" />


Stack trace of Exception upon deployment:

12:35:09,837 DEBUG [org.jboss.jca.core.connectionmanager.pool.strategy.OnePool] (ServerService Thread Pool -- 62) InfinispanDS: returnConnection(3ea8c21b, false) [1/20]
12:35:09,837 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 62) MSC000001: Failed to start service jboss.infinispan.hibernateSearch.LuceneIndexesData: org.jboss.msc.service.StartException in service jboss.infinispan.hibernateSearch.LuceneIndexesData: org.infinispan.commons.CacheException: Unable to invoke method public void org.infinispan.persistence.manager.PersistenceManagerImpl.preload() on object of type PersistenceManagerImpl
	at org.jboss.as.clustering.msc.AsynchronousService$1.run(AsynchronousService.java:91) [wildfly-clustering-common-8.0.0.Final.jar:8.0.0.Final]
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_51]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_51]
	at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_51]
	at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.1.Final.jar:2.1.1.Final]
Caused by: org.infinispan.commons.CacheException: Unable to invoke method public void org.infinispan.persistence.manager.PersistenceManagerImpl.preload() on object of type PersistenceManagerImpl
	at org.infinispan.commons.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:185)
	at org.infinispan.factories.AbstractComponentRegistry$PrioritizedMethod.invoke(AbstractComponentRegistry.java:869)
	at org.infinispan.factories.AbstractComponentRegistry.invokeStartMethods(AbstractComponentRegistry.java:638)
	at org.infinispan.factories.AbstractComponentRegistry.internalStart(AbstractComponentRegistry.java:627)
	at org.infinispan.factories.AbstractComponentRegistry.start(AbstractComponentRegistry.java:530)
	at org.infinispan.factories.ComponentRegistry.start(ComponentRegistry.java:216)
	at org.infinispan.CacheImpl.start(CacheImpl.java:675)
	at org.infinispan.manager.DefaultCacheManager.wireAndStartCache(DefaultCacheManager.java:553)
	at org.infinispan.manager.DefaultCacheManager.createCache(DefaultCacheManager.java:516)
	at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:398)
	at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:412)
	at org.jboss.as.clustering.infinispan.DefaultCacheContainer.getCache(DefaultCacheContainer.java:103)
	at org.jboss.as.clustering.infinispan.DefaultCacheContainer.getCache(DefaultCacheContainer.java:94)
	at org.jboss.as.clustering.infinispan.subsystem.CacheService.start(CacheService.java:78)
	at org.jboss.as.clustering.msc.AsynchronousService$1.run(AsynchronousService.java:86) [wildfly-clustering-common-8.0.0.Final.jar:8.0.0.Final]
	... 4 more
Caused by: java.lang.ClassCastException: java.lang.Class cannot be cast to java.util.Map
	at org.infinispan.persistence.jdbc.binary.JdbcBinaryStore.unmarshallBucket(JdbcBinaryStore.java:577)
	at org.infinispan.persistence.jdbc.binary.JdbcBinaryStore.process(JdbcBinaryStore.java:190)
	at org.infinispan.persistence.manager.PersistenceManagerImpl.preload(PersistenceManagerImpl.java:214)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_51]
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_51]
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_51]
	at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_51]
	at org.infinispan.commons.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:183)
	... 18 more

12:35:09,837 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 66) MSC000001: Failed to start service jboss.infinispan.hibernateSearch.LuceneIndexesMetadata: org.jboss.msc.service.StartException in service jboss.infinispan.hibernateSearch.LuceneIndexesMetadata: org.infinispan.commons.CacheException: Unable to invoke method public void org.infinispan.persistence.manager.PersistenceManagerImpl.preload() on object of type PersistenceManagerImpl
	at org.jboss.as.clustering.msc.AsynchronousService$1.run(AsynchronousService.java:91) [wildfly-clustering-common-8.0.0.Final.jar:8.0.0.Final]
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_51]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_51]
	at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_51]
	at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.1.Final.jar:2.1.1.Final]
Caused by: org.infinispan.commons.CacheException: Unable to invoke method public void org.infinispan.persistence.manager.PersistenceManagerImpl.preload() on object of type PersistenceManagerImpl
	at org.infinispan.commons.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:185)
	at org.infinispan.factories.AbstractComponentRegistry$PrioritizedMethod.invoke(AbstractComponentRegistry.java:869)
	at org.infinispan.factories.AbstractComponentRegistry.invokeStartMethods(AbstractComponentRegistry.java:638)
	at org.infinispan.factories.AbstractComponentRegistry.internalStart(AbstractComponentRegistry.java:627)
	at org.infinispan.factories.AbstractComponentRegistry.start(AbstractComponentRegistry.java:530)
	at org.infinispan.factories.ComponentRegistry.start(ComponentRegistry.java:216)
	at org.infinispan.CacheImpl.start(CacheImpl.java:675)
	at org.infinispan.manager.DefaultCacheManager.wireAndStartCache(DefaultCacheManager.java:553)
	at org.infinispan.manager.DefaultCacheManager.createCache(DefaultCacheManager.java:516)
	at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:398)
	at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:412)
	at org.jboss.as.clustering.infinispan.DefaultCacheContainer.getCache(DefaultCacheContainer.java:103)
	at org.jboss.as.clustering.infinispan.DefaultCacheContainer.getCache(DefaultCacheContainer.java:94)
	at org.jboss.as.clustering.infinispan.subsystem.CacheService.start(CacheService.java:78)
	at org.jboss.as.clustering.msc.AsynchronousService$1.run(AsynchronousService.java:86) [wildfly-clustering-common-8.0.0.Final.jar:8.0.0.Final]
	... 4 more
Caused by: java.lang.ClassCastException: java.lang.Class cannot be cast to java.util.Map
	at org.infinispan.persistence.jdbc.binary.JdbcBinaryStore.unmarshallBucket(JdbcBinaryStore.java:577)
	at org.infinispan.persistence.jdbc.binary.JdbcBinaryStore.process(JdbcBinaryStore.java:190)
	at org.infinispan.persistence.manager.PersistenceManagerImpl.preload(PersistenceManagerImpl.java:214)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_51]
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_51]
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_51]
	at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_51]
	at org.infinispan.commons.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:183)
	... 18 more



    
> Hibernate Search w/ Infinispan - java.lang.Class cannot be cast to java.util.Map
> --------------------------------------------------------------------------------
>
>                 Key: WFLY-3181
>                 URL: https://issues.jboss.org/browse/WFLY-3181
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: JPA / Hibernate
>    Affects Versions: 8.0.0.Final
>         Environment: Wildfly 8.0, OS X 10.9.2
>            Reporter: Akhbar Falafel
>            Assignee: Sanne Grinovero
>
> When configuring Hibernate Search to use Infinispan as its directory provider, a java.lang.ClassCastException occurs upon deployment of an application making use of Hibernate Search.
> Relevant portion of standalone-full-ha.xml:
> {code:xml}
>             <cache-container name="hibernateSearch" default-cache="LuceneIndexesData" jndi-name="java:jboss/infinispan/hibernateSearch" start="EAGER" statistics-enabled="true">
>                 <transport lock-timeout="60000"/>
>                 <replicated-cache name="LuceneIndexesMetadata" start="EAGER" statistics-enabled="true" mode="SYNC">
>                     <binary-keyed-jdbc-store shared="true" preload="true" passivation="false" purge="false" datasource="java:jboss/datasources/InfinispanDatasource">
>                         <binary-keyed-table>
>                             <id-column name="ID_COLUMN" type="VARCHAR(255)"/>
>                             <data-column name="DATUM" type="BYTEA"/>
>                         </binary-keyed-table>
>                     </binary-keyed-jdbc-store>
>                 </replicated-cache>
>                 <replicated-cache name="LuceneIndexesData" start="EAGER" statistics-enabled="true" mode="SYNC">
>                     <binary-keyed-jdbc-store shared="true" preload="true" passivation="false" purge="false" datasource="java:jboss/datasources/InfinispanDatasource">
>                         <binary-keyed-table>
>                             <id-column name="ID_COLUMN" type="VARCHAR(255)"/>
>                             <data-column name="DATUM" type="BYTEA"/>
>                         </binary-keyed-table>
>                     </binary-keyed-jdbc-store>
>                 </replicated-cache>
>                 <replicated-cache name="LuceneIndexesLocking" start="EAGER" statistics-enabled="true" mode="SYNC"/>
>             </cache-container>
> {code}
> Relevant portion of persistence.xml:
> {code:xml}
> 			<!-- Hibernate Search properties - Infinispan -->
> 			<property name="hibernate.search.infinispan.cachemanager_jndiname"
> 				value="java:jboss/infinispan/hibernateSearch" />
> 			<property name="hibernate.search.default.directory_provider"
> 				value="infinispan" />
> 			<property name="hibernate.search.infinispan.chunk_size"
> 				value="300000000" />
> 			<property name="hibernate.search.reader.strategy" value="shared" />
> 			<property name="hibernate.search.worker.execution" value="sync" />
> 			<property name="hibernate.search.jmx_enabled" value="true" />
> 			<property name="hibernate.search.autoregister_listeners"
> 				value="true" />
> {code}
> Stack trace of Exception upon deployment:
> {noformat}
> 12:35:09,837 DEBUG [org.jboss.jca.core.connectionmanager.pool.strategy.OnePool] (ServerService Thread Pool -- 62) InfinispanDS: returnConnection(3ea8c21b, false) [1/20]
> 12:35:09,837 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 62) MSC000001: Failed to start service jboss.infinispan.hibernateSearch.LuceneIndexesData: org.jboss.msc.service.StartException in service jboss.infinispan.hibernateSearch.LuceneIndexesData: org.infinispan.commons.CacheException: Unable to invoke method public void org.infinispan.persistence.manager.PersistenceManagerImpl.preload() on object of type PersistenceManagerImpl
> 	at org.jboss.as.clustering.msc.AsynchronousService$1.run(AsynchronousService.java:91) [wildfly-clustering-common-8.0.0.Final.jar:8.0.0.Final]
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_51]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_51]
> 	at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_51]
> 	at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.1.Final.jar:2.1.1.Final]
> Caused by: org.infinispan.commons.CacheException: Unable to invoke method public void org.infinispan.persistence.manager.PersistenceManagerImpl.preload() on object of type PersistenceManagerImpl
> 	at org.infinispan.commons.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:185)
> 	at org.infinispan.factories.AbstractComponentRegistry$PrioritizedMethod.invoke(AbstractComponentRegistry.java:869)
> 	at org.infinispan.factories.AbstractComponentRegistry.invokeStartMethods(AbstractComponentRegistry.java:638)
> 	at org.infinispan.factories.AbstractComponentRegistry.internalStart(AbstractComponentRegistry.java:627)
> 	at org.infinispan.factories.AbstractComponentRegistry.start(AbstractComponentRegistry.java:530)
> 	at org.infinispan.factories.ComponentRegistry.start(ComponentRegistry.java:216)
> 	at org.infinispan.CacheImpl.start(CacheImpl.java:675)
> 	at org.infinispan.manager.DefaultCacheManager.wireAndStartCache(DefaultCacheManager.java:553)
> 	at org.infinispan.manager.DefaultCacheManager.createCache(DefaultCacheManager.java:516)
> 	at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:398)
> 	at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:412)
> 	at org.jboss.as.clustering.infinispan.DefaultCacheContainer.getCache(DefaultCacheContainer.java:103)
> 	at org.jboss.as.clustering.infinispan.DefaultCacheContainer.getCache(DefaultCacheContainer.java:94)
> 	at org.jboss.as.clustering.infinispan.subsystem.CacheService.start(CacheService.java:78)
> 	at org.jboss.as.clustering.msc.AsynchronousService$1.run(AsynchronousService.java:86) [wildfly-clustering-common-8.0.0.Final.jar:8.0.0.Final]
> 	... 4 more
> Caused by: java.lang.ClassCastException: java.lang.Class cannot be cast to java.util.Map
> 	at org.infinispan.persistence.jdbc.binary.JdbcBinaryStore.unmarshallBucket(JdbcBinaryStore.java:577)
> 	at org.infinispan.persistence.jdbc.binary.JdbcBinaryStore.process(JdbcBinaryStore.java:190)
> 	at org.infinispan.persistence.manager.PersistenceManagerImpl.preload(PersistenceManagerImpl.java:214)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_51]
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_51]
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_51]
> 	at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_51]
> 	at org.infinispan.commons.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:183)
> 	... 18 more
> 12:35:09,837 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 66) MSC000001: Failed to start service jboss.infinispan.hibernateSearch.LuceneIndexesMetadata: org.jboss.msc.service.StartException in service jboss.infinispan.hibernateSearch.LuceneIndexesMetadata: org.infinispan.commons.CacheException: Unable to invoke method public void org.infinispan.persistence.manager.PersistenceManagerImpl.preload() on object of type PersistenceManagerImpl
> 	at org.jboss.as.clustering.msc.AsynchronousService$1.run(AsynchronousService.java:91) [wildfly-clustering-common-8.0.0.Final.jar:8.0.0.Final]
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_51]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_51]
> 	at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_51]
> 	at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.1.Final.jar:2.1.1.Final]
> Caused by: org.infinispan.commons.CacheException: Unable to invoke method public void org.infinispan.persistence.manager.PersistenceManagerImpl.preload() on object of type PersistenceManagerImpl
> 	at org.infinispan.commons.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:185)
> 	at org.infinispan.factories.AbstractComponentRegistry$PrioritizedMethod.invoke(AbstractComponentRegistry.java:869)
> 	at org.infinispan.factories.AbstractComponentRegistry.invokeStartMethods(AbstractComponentRegistry.java:638)
> 	at org.infinispan.factories.AbstractComponentRegistry.internalStart(AbstractComponentRegistry.java:627)
> 	at org.infinispan.factories.AbstractComponentRegistry.start(AbstractComponentRegistry.java:530)
> 	at org.infinispan.factories.ComponentRegistry.start(ComponentRegistry.java:216)
> 	at org.infinispan.CacheImpl.start(CacheImpl.java:675)
> 	at org.infinispan.manager.DefaultCacheManager.wireAndStartCache(DefaultCacheManager.java:553)
> 	at org.infinispan.manager.DefaultCacheManager.createCache(DefaultCacheManager.java:516)
> 	at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:398)
> 	at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:412)
> 	at org.jboss.as.clustering.infinispan.DefaultCacheContainer.getCache(DefaultCacheContainer.java:103)
> 	at org.jboss.as.clustering.infinispan.DefaultCacheContainer.getCache(DefaultCacheContainer.java:94)
> 	at org.jboss.as.clustering.infinispan.subsystem.CacheService.start(CacheService.java:78)
> 	at org.jboss.as.clustering.msc.AsynchronousService$1.run(AsynchronousService.java:86) [wildfly-clustering-common-8.0.0.Final.jar:8.0.0.Final]
> 	... 4 more
> Caused by: java.lang.ClassCastException: java.lang.Class cannot be cast to java.util.Map
> 	at org.infinispan.persistence.jdbc.binary.JdbcBinaryStore.unmarshallBucket(JdbcBinaryStore.java:577)
> 	at org.infinispan.persistence.jdbc.binary.JdbcBinaryStore.process(JdbcBinaryStore.java:190)
> 	at org.infinispan.persistence.manager.PersistenceManagerImpl.preload(PersistenceManagerImpl.java:214)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_51]
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_51]
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_51]
> 	at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_51]
> 	at org.infinispan.commons.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:183)
> 	... 18 more
> {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

From issues at jboss.org  Thu Mar 27 12:50:12 2014
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 27 Mar 2014 12:50:12 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (SECURITY-812) Release JBoss Negotiation
	2.3.0.CR1
In-Reply-To: <JIRA.12536331.1395938971831@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12536331.1395938971831@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12536331.1395938971831.14335.1395939012915@jira02.app.mwc.hst.phx2.redhat.com>

Darran Lofthouse created SECURITY-812:
-----------------------------------------

             Summary: Release JBoss Negotiation 2.3.0.CR1
                 Key: SECURITY-812
                 URL: https://issues.jboss.org/browse/SECURITY-812
             Project: PicketBox 
          Issue Type: Release
      Security Level: Public (Everyone can see)
          Components: Negotiation
            Reporter: Darran Lofthouse
            Assignee: Darran Lofthouse
             Fix For: Negotiation_2_3_0_CR1




--
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

From issues at jboss.org  Thu Mar 27 12:52:12 2014
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 27 Mar 2014 12:52:12 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3182) Upgrade to JBoss Negotiation
	2.3.0.CR1
In-Reply-To: <JIRA.12536332.1395939078077@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12536332.1395939078077@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12536332.1395939078077.14340.1395939132944@jira02.app.mwc.hst.phx2.redhat.com>

Darran Lofthouse created WFLY-3182:
--------------------------------------

             Summary: Upgrade to JBoss Negotiation 2.3.0.CR1
                 Key: WFLY-3182
                 URL: https://issues.jboss.org/browse/WFLY-3182
             Project: WildFly
          Issue Type: Component  Upgrade
      Security Level: Public (Everyone can see)
          Components: Security
            Reporter: Darran Lofthouse
            Assignee: Darran Lofthouse
             Fix For: 8.0.1.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

From issues at jboss.org  Thu Mar 27 12:54:13 2014
From: issues at jboss.org (Tomaz Cerar (JIRA))
Date: Thu, 27 Mar 2014 12:54:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3183) getHeader() on EL Expression
In-Reply-To: <JIRA.12536006.1395753100000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12536006.1395753100000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12536006.1395753100000.14343.1395939253047@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-3183?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tomaz Cerar moved UNDERTOW-210 to WFLY-3183:
--------------------------------------------

              Project: WildFly  (was: Undertow)
                  Key: WFLY-3183  (was: UNDERTOW-210)
    Affects Version/s: 8.0.0.Final
                           (was: 1.0.0.Final)
          Component/s: Web (Undertow)
                           (was: Servlet)
             Security: Public

    
> getHeader() on EL Expression
> ----------------------------
>
>                 Key: WFLY-3183
>                 URL: https://issues.jboss.org/browse/WFLY-3183
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web (Undertow)
>    Affects Versions: 8.0.0.Final
>         Environment: ubuntu 13.10, Wildfly 8.0.0.Final managed from Eclipse kepler (added management-native to standalone.xml)
>            Reporter: Ghet Ghetolay
>            Assignee: Tomaz Cerar
>            Priority: Minor
>              Labels: el-expresion, servlet
>         Attachments: standalone.xml
>
>
> When using an EL Expression that involve getHeader() exception is thrown : 
> {noformat}
> 13:05:35,866 SEVERE [javax.enterprise.resource.webcontainer.jsf.application] (default task-1) Error Rendering View[/index.xhtml]: javax.el.ELException: /index.xhtml @9,63 value="#{request.getHeader('user-agent')}": java.lang.IllegalArgumentException: Cannot convert user-agent of type class java.lang.String to class io.undertow.util.HttpString
> 	at com.sun.faces.facelets.el.TagValueExpression.getValue(TagValueExpression.java:114) [jsf-impl-2.2.5-jbossorg-3.jar:]
> 	at javax.faces.component.ComponentStateHelper.eval(ComponentStateHelper.java:194) [jboss-jsf-api_2.2_spec-2.2.5.jar:2.2.5]
> 	at javax.faces.component.ComponentStateHelper.eval(ComponentStateHelper.java:182) [jboss-jsf-api_2.2_spec-2.2.5.jar:2.2.5]
> 	at javax.faces.component.UIOutput.getValue(UIOutput.java:174) [jboss-jsf-api_2.2_spec-2.2.5.jar:2.2.5]
> 	at com.sun.faces.renderkit.html_basic.HtmlBasicInputRenderer.getValue(HtmlBasicInputRenderer.java:205) [jsf-impl-2.2.5-jbossorg-3.jar:]
> 	at com.sun.faces.renderkit.html_basic.HtmlBasicRenderer.getCurrentValue(HtmlBasicRenderer.java:355) [jsf-impl-2.2.5-jbossorg-3.jar:]
> 	at com.sun.faces.renderkit.html_basic.HtmlBasicRenderer.encodeEnd(HtmlBasicRenderer.java:164) [jsf-impl-2.2.5-jbossorg-3.jar:]
> 	at javax.faces.component.UIComponentBase.encodeEnd(UIComponentBase.java:919) [jboss-jsf-api_2.2_spec-2.2.5.jar:2.2.5]
> 	at javax.faces.component.UIComponent.encodeAll(UIComponent.java:1863) [jboss-jsf-api_2.2_spec-2.2.5.jar:2.2.5]
> 	at javax.faces.component.UIComponent.encodeAll(UIComponent.java:1859) [jboss-jsf-api_2.2_spec-2.2.5.jar:2.2.5]
> 	at javax.faces.component.UIComponent.encodeAll(UIComponent.java:1859) [jboss-jsf-api_2.2_spec-2.2.5.jar:2.2.5]
> 	at com.sun.faces.application.view.FaceletViewHandlingStrategy.renderView(FaceletViewHandlingStrategy.java:461) [jsf-impl-2.2.5-jbossorg-3.jar:]
> 	at com.sun.faces.application.view.MultiViewHandler.renderView(MultiViewHandler.java:133) [jsf-impl-2.2.5-jbossorg-3.jar:]
> 	at javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:337) [jboss-jsf-api_2.2_spec-2.2.5.jar:2.2.5]
> 	at com.sun.faces.lifecycle.RenderResponsePhase.execute(RenderResponsePhase.java:120) [jsf-impl-2.2.5-jbossorg-3.jar:]
> 	at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101) [jsf-impl-2.2.5-jbossorg-3.jar:]
> 	at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:219) [jsf-impl-2.2.5-jbossorg-3.jar:]
> 	at javax.faces.webapp.FacesServlet.service(FacesServlet.java:647) [jboss-jsf-api_2.2_spec-2.2.5.jar:2.2.5]
> 	at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85) [undertow-servlet-1.0.0.Final.jar:1.0.0.Final]
> 	at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:61) [undertow-servlet-1.0.0.Final.jar:1.0.0.Final]
> 	at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.0.0.Final.jar:1.0.0.Final]
> 	at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Final.jar:1.0.0.Final]
> 	at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:113) [undertow-servlet-1.0.0.Final.jar:1.0.0.Final]
> 	at io.undertow.security.handlers.AuthenticationCallHandler.handleRequest(AuthenticationCallHandler.java:52) [undertow-core-1.0.0.Final.jar:1.0.0.Final]
> 	at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) [undertow-core-1.0.0.Final.jar:1.0.0.Final]
> 	at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:61) [undertow-servlet-1.0.0.Final.jar:1.0.0.Final]
> 	at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:70) [undertow-servlet-1.0.0.Final.jar:1.0.0.Final]
> 	at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76) [undertow-core-1.0.0.Final.jar:1.0.0.Final]
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Final.jar:1.0.0.Final]
> 	at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Final.jar:1.0.0.Final]
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Final.jar:1.0.0.Final]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:240) [undertow-servlet-1.0.0.Final.jar:1.0.0.Final]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:227) [undertow-servlet-1.0.0.Final.jar:1.0.0.Final]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:73) [undertow-servlet-1.0.0.Final.jar:1.0.0.Final]
> 	at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:146) [undertow-servlet-1.0.0.Final.jar:1.0.0.Final]
> 	at io.undertow.server.Connectors.executeRootHandler(Connectors.java:168) [undertow-core-1.0.0.Final.jar:1.0.0.Final]
> 	at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:687) [undertow-core-1.0.0.Final.jar:1.0.0.Final]
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_51]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_51]
> 	at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_51]
> Caused by: javax.el.ELException: java.lang.IllegalArgumentException: Cannot convert user-agent of type class java.lang.String to class io.undertow.util.HttpString
> 	at com.sun.el.ExpressionFactoryImpl.coerceToType(ExpressionFactoryImpl.java:79) [javax.el-3.0.0.jar:3.0.0]
> 	at javax.el.ELContext.convertToType(ELContext.java:473) [javax.el-3.0.0.jar:3.0.0]
> 	at com.sun.el.lang.EvaluationContext.convertToType(EvaluationContext.java:166) [javax.el-3.0.0.jar:3.0.0]
> 	at javax.el.ELUtil.invokeMethod(ELUtil.java:320) [javax.el-3.0.0.jar:3.0.0]
> 	at javax.el.BeanELResolver.invoke(BeanELResolver.java:536) [javax.el-3.0.0.jar:3.0.0]
> 	at javax.el.CompositeELResolver.invoke(CompositeELResolver.java:256) [javax.el-3.0.0.jar:3.0.0]
> 	at com.sun.el.parser.AstValue.getValue(AstValue.java:136) [javax.el-3.0.0.jar:3.0.0]
> 	at com.sun.el.parser.AstValue.getValue(AstValue.java:204) [javax.el-3.0.0.jar:3.0.0]
> 	at com.sun.el.ValueExpressionImpl.getValue(ValueExpressionImpl.java:226) [javax.el-3.0.0.jar:3.0.0]
> 	at com.sun.faces.facelets.el.TagValueExpression.getValue(TagValueExpression.java:109) [jsf-impl-2.2.5-jbossorg-3.jar:]
> {noformat}
> Here is the jsf page : 
> {code:xml}
> <html xmlns="http://www.w3.org/1999/xhtml"
>       xmlns:h="http://java.sun.com/jsf/html"
>       xmlns:f="http://java.sun.com/jsf/core"
>       xmlns:ui="http://java.sun.com/jsf/facelets">  
>     <h:head>
>     </h:head>  
>     <h:body>  
>     
>     <h:outputText value="#{request.getHeader('user-agent')}"/>
>     
>     </h:body>  
> </html>
> {code}
> Web.xml
> {code:xml}
> <?xml version="1.0" encoding="UTF-8"?>
> <web-app xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> 	xmlns="http://java.sun.com/xml/ns/javaee"
> 	xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd"
> 	version="3.0">
> 	<servlet>
> 		<servlet-name>Faces Servlet</servlet-name>
> 		<servlet-class>javax.faces.webapp.FacesServlet</servlet-class>
> 		<load-on-startup>1</load-on-startup>
> 	</servlet>
> 	<servlet-mapping>
> 		<servlet-name>Faces Servlet</servlet-name>
> 		<url-pattern>*.xhtml</url-pattern>
> 	</servlet-mapping>
> </web-app>
> {code}

--
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

From issues at jboss.org  Thu Mar 27 12:56:14 2014
From: issues at jboss.org (Bela Ban (JIRA))
Date: Thu, 27 Mar 2014 12:56:14 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1816) Message: add flag
	DONT_LOOPBACK
In-Reply-To: <JIRA.12536323.1395935656000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12536323.1395935656000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12536323.1395935656000.14364.1395939374426@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JGRP-1816?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12957107#comment-12957107 ] 

Bela Ban commented on JGRP-1816:
--------------------------------

This is an alternative to {{JChannel.setDiscardOwnMessages()}}:
* The {{DONT_LOOPBACK}} flag can be set *per message*, so it's much more flexible
* The dropping of the message happens at the transport level, not at the JGroups level, so we cut down on unneeded processing
                
> Message: add flag DONT_LOOPBACK
> -------------------------------
>
>                 Key: JGRP-1816
>                 URL: https://issues.jboss.org/browse/JGRP-1816
>             Project: JGroups
>          Issue Type: Feature Request
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 3.5
>
>
> When flag {{DONT_LOOPBACK}}, then multicast messages ({{dest}} == null) are not looped back up the stack. This can be useful in some cases, e.g. discovery:
> * A multicasts a discovery request
> * A gets the discovery request and adds information shipped with it (A's logical-physical address mapping and logical name) to its local cache(s)
> * A sends a discovery response to itself
> * A gets the discovery response and adds its information *again*
> --> Because the information was already present, it doesn't need to be added, *but was added 2 more times* !
> --> This unneeded processing costs threads from the pool, processing power, locks etc
> SOLUTION:
> * When sending a multicast message we loop it back up and then multicast  it. When received by the sender, we drop it.
> * We now don't even loop back the message if DONT_LOOPBACK is set

--
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

From issues at jboss.org  Thu Mar 27 13:00:13 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 27 Mar 2014 13:00:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (SECURITY-812) Release JBoss Negotiation
	2.3.0.CR1
In-Reply-To: <JIRA.12536331.1395938971000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12536331.1395938971000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12536331.1395938971000.14402.1395939613655@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/SECURITY-812?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated SECURITY-812:
---------------------------------------------

        Bugzilla Update: Perform
    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1081607

    
> Release JBoss Negotiation 2.3.0.CR1
> -----------------------------------
>
>                 Key: SECURITY-812
>                 URL: https://issues.jboss.org/browse/SECURITY-812
>             Project: PicketBox 
>          Issue Type: Release
>      Security Level: Public(Everyone can see) 
>          Components: Negotiation
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: Negotiation_2_3_0_CR1
>
>


--
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

From issues at jboss.org  Thu Mar 27 13:00:13 2014
From: issues at jboss.org (Bela Ban (JIRA))
Date: Thu, 27 Mar 2014 13:00:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1816) Message: add flag
	DONT_LOOPBACK
In-Reply-To: <JIRA.12536323.1395935656000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12536323.1395935656000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12536323.1395935656000.14407.1395939613961@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JGRP-1816?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban resolved JGRP-1816.
----------------------------

    Resolution: Done

    
> Message: add flag DONT_LOOPBACK
> -------------------------------
>
>                 Key: JGRP-1816
>                 URL: https://issues.jboss.org/browse/JGRP-1816
>             Project: JGroups
>          Issue Type: Feature Request
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 3.5
>
>
> When flag {{DONT_LOOPBACK}}, then multicast messages ({{dest}} == null) are not looped back up the stack. This can be useful in some cases, e.g. discovery:
> * A multicasts a discovery request
> * A gets the discovery request and adds information shipped with it (A's logical-physical address mapping and logical name) to its local cache(s)
> * A sends a discovery response to itself
> * A gets the discovery response and adds its information *again*
> --> Because the information was already present, it doesn't need to be added, *but was added 2 more times* !
> --> This unneeded processing costs threads from the pool, processing power, locks etc
> SOLUTION:
> * When sending a multicast message we loop it back up and then multicast  it. When received by the sender, we drop it.
> * We now don't even loop back the message if DONT_LOOPBACK is set

--
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

From issues at jboss.org  Thu Mar 27 13:00:13 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 27 Mar 2014 13:00:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3182) Upgrade to JBoss Negotiation
	2.3.0.CR1
In-Reply-To: <JIRA.12536332.1395939078000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12536332.1395939078000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12536332.1395939078000.14405.1395939613843@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-3182?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated WFLY-3182:
------------------------------------------

        Bugzilla Update: Perform
    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1081607

    
> Upgrade to JBoss Negotiation 2.3.0.CR1
> --------------------------------------
>
>                 Key: WFLY-3182
>                 URL: https://issues.jboss.org/browse/WFLY-3182
>             Project: WildFly
>          Issue Type: Component  Upgrade
>      Security Level: Public(Everyone can see) 
>          Components: Security
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 8.0.1.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

From issues at jboss.org  Thu Mar 27 13:06:13 2014
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 27 Mar 2014 13:06:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3182) Upgrade to JBoss Negotiation
	2.3.0.CR1
In-Reply-To: <JIRA.12536332.1395939078000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12536332.1395939078000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12536332.1395939078000.14424.1395939973425@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-3182?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated WFLY-3182:
-----------------------------------

    Fix Version/s: 9.0.0.CR1
                       (was: 8.0.1.Final)

    
> Upgrade to JBoss Negotiation 2.3.0.CR1
> --------------------------------------
>
>                 Key: WFLY-3182
>                 URL: https://issues.jboss.org/browse/WFLY-3182
>             Project: WildFly
>          Issue Type: Component  Upgrade
>      Security Level: Public(Everyone can see) 
>          Components: Security
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 9.0.0.CR1
>
>


--
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

From issues at jboss.org  Thu Mar 27 13:10:13 2014
From: issues at jboss.org (Desmond Silveira (JIRA))
Date: Thu, 27 Mar 2014 13:10:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-458) Drools lock in
 StatelessKnowledgeSessionImpl.
In-Reply-To: <JIRA.12536231.1395882246000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12536231.1395882246000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12536231.1395882246000.14434.1395940213222@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-458?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Desmond Silveira updated DROOLS-458:
------------------------------------

    Attachment: la3ldspg05b.txt


I have attached the full thread dump.

There are 129 blocked threads.
72 are blocked by lock <219dcd77> which is owned by  thread http-bio-172.16.216.19-80-exec-37511.
57 are blocked by lock <555896b3> which is owned by thread http-bio-172.16.216.19-80-exec-37519.
Both of those threads are in a runnable state executing drools code.

In my other Tomcat instances that execute the same code, none of my threads are blocked.  I recently upgraded to Drools 6.0.1 from Drools 5.0.  Other than this library upgrade (and corresponding changes to library calls) and marked increase in traffic, I haven't had any other changes to my system recently, but my threads have been deadlocking over the past couple of weeks.
                
> Drools lock in StatelessKnowledgeSessionImpl.
> ---------------------------------------------
>
>                 Key: DROOLS-458
>                 URL: https://issues.jboss.org/browse/DROOLS-458
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 6.0.1.Final
>         Environment: Tomcat 7
>            Reporter: Desmond Silveira
>            Assignee: Mario Fusco
>         Attachments: la3ldspg05b.txt
>
>
> My Tomcat HTTP BIO connector threads (129 of them) got BLOCKED in my production Tomcat 7 instance because Drool 6.0.1 wasn't releasing a lock.
> Here is a snippet of the thread dump:
> {noformat}
> "http-bio-172.16.216.19-80-exec-37513" - Thread t at 6245360
>    java.lang.Thread.State: BLOCKED
> 	at org.drools.core.runtime.process.ProcessRuntimeFactory.getProcessRuntimeFactoryService(ProcessRuntimeFactory.java:20)
> 	- waiting to lock <219dcd77> (a java.lang.Class) owned by "http-bio-172.16.216.19-80-exec-37511" t at 6245358
> 	at org.drools.core.runtime.process.ProcessRuntimeFactory.newProcessRuntime(ProcessRuntimeFactory.java:12)
> 	at org.drools.core.common.AbstractWorkingMemory.createProcessRuntime(AbstractWorkingMemory.java:405)
> 	at org.drools.core.common.AbstractWorkingMemory.setKnowledgeRuntime(AbstractWorkingMemory.java:1770)
> 	at org.drools.core.impl.StatefulKnowledgeSessionImpl.<init>(StatefulKnowledgeSessionImpl.java:125)
> 	at org.drools.core.impl.StatelessKnowledgeSessionImpl.newWorkingMemory(StatelessKnowledgeSessionImpl.java:139)
> 	at org.drools.core.impl.StatelessKnowledgeSessionImpl.execute(StatelessKnowledgeSessionImpl.java:397)
> 	at com.local.lds.RuleEngineBean.applyKnowledge(RuleEngineBean.java:50)
> 	at com.local.lds.LdsBean.search(LdsBean.java:200)
> 	at com.local.lds.servlet.SearchServlet.doGet(SearchServlet.java:55)
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:621)
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:722)
> 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:305)
> 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
> 	at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:224)
> 	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:169)
> 	at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:472)
> 	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:168)
> 	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:98)
> 	at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:927)
> 	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118)
> 	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:407)
> 	at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:987)
> 	at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:579)
> 	at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:307)
> 	- locked <3575a054> (a org.apache.tomcat.util.net.SocketWrapper)
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
> 	at java.lang.Thread.run(Unknown Source)
>    Locked ownable synchronizers:
> 	- locked <719df963> (a java.util.concurrent.ThreadPoolExecutor$Worker)
> "http-bio-172.16.216.19-80-exec-37511" - Thread t at 6245358
>    java.lang.Thread.State: RUNNABLE
> 	at org.kie.internal.utils.ServiceRegistryImpl.addDefault(ServiceRegistryImpl.java:212)
> 	- locked <3d710637> (a org.kie.internal.utils.ServiceRegistryImpl)
> 	at org.kie.internal.utils.ServiceRegistryImpl.addDefault(ServiceRegistryImpl.java:207)
> 	- locked <3d710637> (a org.kie.internal.utils.ServiceRegistryImpl)
> 	at org.drools.core.runtime.process.ProcessRuntimeFactory.loadProvider(ProcessRuntimeFactory.java:27)
> 	at org.drools.core.runtime.process.ProcessRuntimeFactory.getProcessRuntimeFactoryService(ProcessRuntimeFactory.java:21)
> 	- locked <219dcd77> (a java.lang.Class)
> 	at org.drools.core.runtime.process.ProcessRuntimeFactory.newProcessRuntime(ProcessRuntimeFactory.java:12)
> 	at org.drools.core.common.AbstractWorkingMemory.createProcessRuntime(AbstractWorkingMemory.java:405)
> 	at org.drools.core.common.AbstractWorkingMemory.setKnowledgeRuntime(AbstractWorkingMemory.java:1770)
> 	at org.drools.core.impl.StatefulKnowledgeSessionImpl.<init>(StatefulKnowledgeSessionImpl.java:125)
> 	at org.drools.core.impl.StatelessKnowledgeSessionImpl.newWorkingMemory(StatelessKnowledgeSessionImpl.java:139)
> 	at org.drools.core.impl.StatelessKnowledgeSessionImpl.execute(StatelessKnowledgeSessionImpl.java:397)
> 	at com.local.lds.RuleEngineBean.applyKnowledge(RuleEngineBean.java:50)
> 	at com.local.lds.LdsBean.search(LdsBean.java:200)
> 	at com.local.lds.servlet.SearchServlet.doGet(SearchServlet.java:55)
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:621)
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:722)
> 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:305)
> 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
> 	at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:224)
> 	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:169)
> 	at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:472)
> 	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:168)
> 	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:98)
> 	at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:927)
> 	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118)
> 	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:407)
> 	at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:987)
> 	at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:579)
> 	at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:307)
> 	- locked <474f2464> (a org.apache.tomcat.util.net.SocketWrapper)
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
> 	at java.lang.Thread.run(Unknown Source)
>    Locked ownable synchronizers:
> 	- locked <339f344e> (a java.util.concurrent.ThreadPoolExecutor$Worker)
> "http-bio-172.16.216.19-80-exec-37447" - Thread t at 6233953
>    java.lang.Thread.State: BLOCKED
> 	at org.drools.core.common.ProjectClassLoader.loadClass(ProjectClassLoader.java:82)
> 	- waiting to lock <555896b3> (a org.drools.core.common.ProjectClassLoader) owned by "http-bio-172.16.216.19-80-exec-37519" t at 6245366
> 	at java.lang.ClassLoader.loadClass(Unknown Source)
> 	at org.drools.core.base.ClassFieldAccessorCache.getClass(ClassFieldAccessorCache.java:122)
> 	at org.drools.core.base.ClassFieldAccessorCache.getClassObjectType(ClassFieldAccessorCache.java:46)
> 	at org.drools.core.reteoo.ClassObjectTypeConf.<init>(ClassObjectTypeConf.java:89)
> 	at org.drools.core.common.ObjectTypeConfigurationRegistry.getObjectTypeConf(ObjectTypeConfigurationRegistry.java:71)
> 	at org.drools.core.common.AbstractWorkingMemory.initInitialFact(AbstractWorkingMemory.java:385)
> 	at org.drools.core.common.AbstractWorkingMemory.<init>(AbstractWorkingMemory.java:378)
> 	at org.drools.core.common.AbstractWorkingMemory.<init>(AbstractWorkingMemory.java:261)
> 	at org.drools.core.common.PhreakWorkingMemoryFactory.createWorkingMemory(PhreakWorkingMemoryFactory.java:15)
> 	at org.drools.core.impl.StatelessKnowledgeSessionImpl.newWorkingMemory(StatelessKnowledgeSessionImpl.java:134)
> 	at org.drools.core.impl.StatelessKnowledgeSessionImpl.execute(StatelessKnowledgeSessionImpl.java:397)
> 	at com.local.lds.RuleEngineBean.applyKnowledge(RuleEngineBean.java:50)
> 	at com.local.lds.LdsBean.search(LdsBean.java:200)
> 	at com.local.lds.servlet.SearchServlet.doGet(SearchServlet.java:55)
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:621)
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:722)
> 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:305)
> 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
> 	at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:224)
> 	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:169)
> 	at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:472)
> 	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:168)
> 	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:98)
> 	at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:927)
> 	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118)
> 	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:407)
> 	at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:987)
> 	at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:579)
> 	at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:307)
> 	- locked <57e6b780> (a org.apache.tomcat.util.net.SocketWrapper)
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
> 	at java.lang.Thread.run(Unknown Source)
>    Locked ownable synchronizers:
> 	- locked <726294fc> (a java.util.concurrent.ThreadPoolExecutor$Worker)
> "http-bio-172.16.216.19-80-exec-37519" - Thread t at 6245366
>    java.lang.Thread.State: RUNNABLE
> 	at java.lang.ClassLoader.findLoadedClass0(Native Method)
> 	at java.lang.ClassLoader.findLoadedClass(Unknown Source)
> 	at java.lang.ClassLoader.loadClass(Unknown Source)
> 	- locked <555896b3> (a org.drools.core.common.ProjectClassLoader)
> 	at org.drools.core.common.ProjectClassLoader.internalLoadClass(ProjectClassLoader.java:99)
> 	at org.drools.core.common.ProjectClassLoader.loadClass(ProjectClassLoader.java:82)
> 	- locked <555896b3> (a org.drools.core.common.ProjectClassLoader)
> 	at java.lang.ClassLoader.loadClass(Unknown Source)
> 	at org.drools.core.base.ClassFieldAccessorCache.getClass(ClassFieldAccessorCache.java:122)
> 	at org.drools.core.base.ClassFieldAccessorCache.getClassObjectType(ClassFieldAccessorCache.java:46)
> 	at org.drools.core.reteoo.ClassObjectTypeConf.<init>(ClassObjectTypeConf.java:89)
> 	at org.drools.core.common.ObjectTypeConfigurationRegistry.getObjectTypeConf(ObjectTypeConfigurationRegistry.java:71)
> 	at org.drools.core.common.NamedEntryPoint.insert(NamedEntryPoint.java:164)
> 	at org.drools.core.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:1148)
> 	at org.drools.core.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:1092)
> 	at org.drools.core.impl.StatefulKnowledgeSessionImpl.insert(StatefulKnowledgeSessionImpl.java:308)
> 	at org.drools.core.impl.StatelessKnowledgeSessionImpl.execute(StatelessKnowledgeSessionImpl.java:400)
> 	at com.local.lds.RuleEngineBean.applyKnowledge(RuleEngineBean.java:50)
> 	at com.local.lds.LdsBean.search(LdsBean.java:200)
> 	at com.local.lds.servlet.SearchServlet.doGet(SearchServlet.java:55)
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:621)
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:722)
> 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:305)
> 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
> 	at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:224)
> 	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:169)
> 	at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:472)
> 	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:168)
> 	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:98)
> 	at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:927)
> 	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118)
> 	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:407)
> 	at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:987)
> 	at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:579)
> 	at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:307)
> 	- locked <43c2901> (a org.apache.tomcat.util.net.SocketWrapper)
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
> 	at java.lang.Thread.run(Unknown Source)
>    Locked ownable synchronizers:
> 	- locked <88f8fa9> (a java.util.concurrent.ThreadPoolExecutor$Worker)
> {noformat}
> Here is the code that I use to call Drools:
> {code:java}
>     public static Collection<ResultSet> applyRule(String rule,
>             KieBase kb, Collection<ResultSet> resultSets, SearchParameters params) {
>         try {
>             if (kb == null) {
>                 return resultSets;
>             }
>             StatelessKieSession ksession = kb.newStatelessKieSession();
>             ksession.setGlobal(OUTPUT, new ArrayList<>());
>             Collection<Object> collection = new ArrayList<Object>(resultSets);
>             collection.add(params);
>             ksession.execute(collection);
>             return (Collection<ResultSet>) ksession.getGlobals().get(OUTPUT);
>         } catch (ConsequenceException e) {
>             LOG.error("Error in rule: " + rule + " " + e.getRule(), e);
>             throw e;
>         } catch (RuntimeException e) {
>             LOG.error("Error in rule: " + rule, e);
>             throw e;
>         }
>     }
> {code}

--
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

From issues at jboss.org  Thu Mar 27 13:13:03 2014
From: issues at jboss.org (Desmond Silveira (JIRA))
Date: Thu, 27 Mar 2014 13:13:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-458) Drools lock in
 StatelessKnowledgeSessionImpl.
In-Reply-To: <JIRA.12536231.1395882246000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12536231.1395882246000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12536231.1395882246000.14440.1395940383693@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-458?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Desmond Silveira reopened DROOLS-458:
-------------------------------------


    
> Drools lock in StatelessKnowledgeSessionImpl.
> ---------------------------------------------
>
>                 Key: DROOLS-458
>                 URL: https://issues.jboss.org/browse/DROOLS-458
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 6.0.1.Final
>         Environment: Tomcat 7
>            Reporter: Desmond Silveira
>            Assignee: Mario Fusco
>         Attachments: la3ldspg05b.txt
>
>
> My Tomcat HTTP BIO connector threads (129 of them) got BLOCKED in my production Tomcat 7 instance because Drool 6.0.1 wasn't releasing a lock.
> Here is a snippet of the thread dump:
> {noformat}
> "http-bio-172.16.216.19-80-exec-37513" - Thread t at 6245360
>    java.lang.Thread.State: BLOCKED
> 	at org.drools.core.runtime.process.ProcessRuntimeFactory.getProcessRuntimeFactoryService(ProcessRuntimeFactory.java:20)
> 	- waiting to lock <219dcd77> (a java.lang.Class) owned by "http-bio-172.16.216.19-80-exec-37511" t at 6245358
> 	at org.drools.core.runtime.process.ProcessRuntimeFactory.newProcessRuntime(ProcessRuntimeFactory.java:12)
> 	at org.drools.core.common.AbstractWorkingMemory.createProcessRuntime(AbstractWorkingMemory.java:405)
> 	at org.drools.core.common.AbstractWorkingMemory.setKnowledgeRuntime(AbstractWorkingMemory.java:1770)
> 	at org.drools.core.impl.StatefulKnowledgeSessionImpl.<init>(StatefulKnowledgeSessionImpl.java:125)
> 	at org.drools.core.impl.StatelessKnowledgeSessionImpl.newWorkingMemory(StatelessKnowledgeSessionImpl.java:139)
> 	at org.drools.core.impl.StatelessKnowledgeSessionImpl.execute(StatelessKnowledgeSessionImpl.java:397)
> 	at com.local.lds.RuleEngineBean.applyKnowledge(RuleEngineBean.java:50)
> 	at com.local.lds.LdsBean.search(LdsBean.java:200)
> 	at com.local.lds.servlet.SearchServlet.doGet(SearchServlet.java:55)
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:621)
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:722)
> 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:305)
> 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
> 	at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:224)
> 	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:169)
> 	at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:472)
> 	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:168)
> 	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:98)
> 	at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:927)
> 	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118)
> 	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:407)
> 	at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:987)
> 	at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:579)
> 	at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:307)
> 	- locked <3575a054> (a org.apache.tomcat.util.net.SocketWrapper)
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
> 	at java.lang.Thread.run(Unknown Source)
>    Locked ownable synchronizers:
> 	- locked <719df963> (a java.util.concurrent.ThreadPoolExecutor$Worker)
> "http-bio-172.16.216.19-80-exec-37511" - Thread t at 6245358
>    java.lang.Thread.State: RUNNABLE
> 	at org.kie.internal.utils.ServiceRegistryImpl.addDefault(ServiceRegistryImpl.java:212)
> 	- locked <3d710637> (a org.kie.internal.utils.ServiceRegistryImpl)
> 	at org.kie.internal.utils.ServiceRegistryImpl.addDefault(ServiceRegistryImpl.java:207)
> 	- locked <3d710637> (a org.kie.internal.utils.ServiceRegistryImpl)
> 	at org.drools.core.runtime.process.ProcessRuntimeFactory.loadProvider(ProcessRuntimeFactory.java:27)
> 	at org.drools.core.runtime.process.ProcessRuntimeFactory.getProcessRuntimeFactoryService(ProcessRuntimeFactory.java:21)
> 	- locked <219dcd77> (a java.lang.Class)
> 	at org.drools.core.runtime.process.ProcessRuntimeFactory.newProcessRuntime(ProcessRuntimeFactory.java:12)
> 	at org.drools.core.common.AbstractWorkingMemory.createProcessRuntime(AbstractWorkingMemory.java:405)
> 	at org.drools.core.common.AbstractWorkingMemory.setKnowledgeRuntime(AbstractWorkingMemory.java:1770)
> 	at org.drools.core.impl.StatefulKnowledgeSessionImpl.<init>(StatefulKnowledgeSessionImpl.java:125)
> 	at org.drools.core.impl.StatelessKnowledgeSessionImpl.newWorkingMemory(StatelessKnowledgeSessionImpl.java:139)
> 	at org.drools.core.impl.StatelessKnowledgeSessionImpl.execute(StatelessKnowledgeSessionImpl.java:397)
> 	at com.local.lds.RuleEngineBean.applyKnowledge(RuleEngineBean.java:50)
> 	at com.local.lds.LdsBean.search(LdsBean.java:200)
> 	at com.local.lds.servlet.SearchServlet.doGet(SearchServlet.java:55)
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:621)
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:722)
> 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:305)
> 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
> 	at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:224)
> 	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:169)
> 	at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:472)
> 	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:168)
> 	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:98)
> 	at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:927)
> 	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118)
> 	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:407)
> 	at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:987)
> 	at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:579)
> 	at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:307)
> 	- locked <474f2464> (a org.apache.tomcat.util.net.SocketWrapper)
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
> 	at java.lang.Thread.run(Unknown Source)
>    Locked ownable synchronizers:
> 	- locked <339f344e> (a java.util.concurrent.ThreadPoolExecutor$Worker)
> "http-bio-172.16.216.19-80-exec-37447" - Thread t at 6233953
>    java.lang.Thread.State: BLOCKED
> 	at org.drools.core.common.ProjectClassLoader.loadClass(ProjectClassLoader.java:82)
> 	- waiting to lock <555896b3> (a org.drools.core.common.ProjectClassLoader) owned by "http-bio-172.16.216.19-80-exec-37519" t at 6245366
> 	at java.lang.ClassLoader.loadClass(Unknown Source)
> 	at org.drools.core.base.ClassFieldAccessorCache.getClass(ClassFieldAccessorCache.java:122)
> 	at org.drools.core.base.ClassFieldAccessorCache.getClassObjectType(ClassFieldAccessorCache.java:46)
> 	at org.drools.core.reteoo.ClassObjectTypeConf.<init>(ClassObjectTypeConf.java:89)
> 	at org.drools.core.common.ObjectTypeConfigurationRegistry.getObjectTypeConf(ObjectTypeConfigurationRegistry.java:71)
> 	at org.drools.core.common.AbstractWorkingMemory.initInitialFact(AbstractWorkingMemory.java:385)
> 	at org.drools.core.common.AbstractWorkingMemory.<init>(AbstractWorkingMemory.java:378)
> 	at org.drools.core.common.AbstractWorkingMemory.<init>(AbstractWorkingMemory.java:261)
> 	at org.drools.core.common.PhreakWorkingMemoryFactory.createWorkingMemory(PhreakWorkingMemoryFactory.java:15)
> 	at org.drools.core.impl.StatelessKnowledgeSessionImpl.newWorkingMemory(StatelessKnowledgeSessionImpl.java:134)
> 	at org.drools.core.impl.StatelessKnowledgeSessionImpl.execute(StatelessKnowledgeSessionImpl.java:397)
> 	at com.local.lds.RuleEngineBean.applyKnowledge(RuleEngineBean.java:50)
> 	at com.local.lds.LdsBean.search(LdsBean.java:200)
> 	at com.local.lds.servlet.SearchServlet.doGet(SearchServlet.java:55)
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:621)
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:722)
> 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:305)
> 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
> 	at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:224)
> 	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:169)
> 	at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:472)
> 	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:168)
> 	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:98)
> 	at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:927)
> 	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118)
> 	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:407)
> 	at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:987)
> 	at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:579)
> 	at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:307)
> 	- locked <57e6b780> (a org.apache.tomcat.util.net.SocketWrapper)
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
> 	at java.lang.Thread.run(Unknown Source)
>    Locked ownable synchronizers:
> 	- locked <726294fc> (a java.util.concurrent.ThreadPoolExecutor$Worker)
> "http-bio-172.16.216.19-80-exec-37519" - Thread t at 6245366
>    java.lang.Thread.State: RUNNABLE
> 	at java.lang.ClassLoader.findLoadedClass0(Native Method)
> 	at java.lang.ClassLoader.findLoadedClass(Unknown Source)
> 	at java.lang.ClassLoader.loadClass(Unknown Source)
> 	- locked <555896b3> (a org.drools.core.common.ProjectClassLoader)
> 	at org.drools.core.common.ProjectClassLoader.internalLoadClass(ProjectClassLoader.java:99)
> 	at org.drools.core.common.ProjectClassLoader.loadClass(ProjectClassLoader.java:82)
> 	- locked <555896b3> (a org.drools.core.common.ProjectClassLoader)
> 	at java.lang.ClassLoader.loadClass(Unknown Source)
> 	at org.drools.core.base.ClassFieldAccessorCache.getClass(ClassFieldAccessorCache.java:122)
> 	at org.drools.core.base.ClassFieldAccessorCache.getClassObjectType(ClassFieldAccessorCache.java:46)
> 	at org.drools.core.reteoo.ClassObjectTypeConf.<init>(ClassObjectTypeConf.java:89)
> 	at org.drools.core.common.ObjectTypeConfigurationRegistry.getObjectTypeConf(ObjectTypeConfigurationRegistry.java:71)
> 	at org.drools.core.common.NamedEntryPoint.insert(NamedEntryPoint.java:164)
> 	at org.drools.core.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:1148)
> 	at org.drools.core.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:1092)
> 	at org.drools.core.impl.StatefulKnowledgeSessionImpl.insert(StatefulKnowledgeSessionImpl.java:308)
> 	at org.drools.core.impl.StatelessKnowledgeSessionImpl.execute(StatelessKnowledgeSessionImpl.java:400)
> 	at com.local.lds.RuleEngineBean.applyKnowledge(RuleEngineBean.java:50)
> 	at com.local.lds.LdsBean.search(LdsBean.java:200)
> 	at com.local.lds.servlet.SearchServlet.doGet(SearchServlet.java:55)
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:621)
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:722)
> 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:305)
> 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
> 	at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:224)
> 	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:169)
> 	at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:472)
> 	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:168)
> 	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:98)
> 	at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:927)
> 	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118)
> 	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:407)
> 	at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:987)
> 	at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:579)
> 	at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:307)
> 	- locked <43c2901> (a org.apache.tomcat.util.net.SocketWrapper)
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
> 	at java.lang.Thread.run(Unknown Source)
>    Locked ownable synchronizers:
> 	- locked <88f8fa9> (a java.util.concurrent.ThreadPoolExecutor$Worker)
> {noformat}
> Here is the code that I use to call Drools:
> {code:java}
>     public static Collection<ResultSet> applyRule(String rule,
>             KieBase kb, Collection<ResultSet> resultSets, SearchParameters params) {
>         try {
>             if (kb == null) {
>                 return resultSets;
>             }
>             StatelessKieSession ksession = kb.newStatelessKieSession();
>             ksession.setGlobal(OUTPUT, new ArrayList<>());
>             Collection<Object> collection = new ArrayList<Object>(resultSets);
>             collection.add(params);
>             ksession.execute(collection);
>             return (Collection<ResultSet>) ksession.getGlobals().get(OUTPUT);
>         } catch (ConsequenceException e) {
>             LOG.error("Error in rule: " + rule + " " + e.getRule(), e);
>             throw e;
>         } catch (RuntimeException e) {
>             LOG.error("Error in rule: " + rule, e);
>             throw e;
>         }
>     }
> {code}

--
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

From issues at jboss.org  Thu Mar 27 13:40:13 2014
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 27 Mar 2014 13:40:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (SECURITY-812) Release JBoss Negotiation
	2.3.0.CR1
In-Reply-To: <JIRA.12536331.1395938971000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12536331.1395938971000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12536331.1395938971000.14528.1395942013355@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/SECURITY-812?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse resolved SECURITY-812.
---------------------------------------

    Resolution: Done

    
> Release JBoss Negotiation 2.3.0.CR1
> -----------------------------------
>
>                 Key: SECURITY-812
>                 URL: https://issues.jboss.org/browse/SECURITY-812
>             Project: PicketBox 
>          Issue Type: Release
>      Security Level: Public(Everyone can see) 
>          Components: Negotiation
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: Negotiation_2_3_0_CR1
>
>


--
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

From issues at jboss.org  Thu Mar 27 13:40:13 2014
From: issues at jboss.org (Bela Ban (JIRA))
Date: Thu, 27 Mar 2014 13:40:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1813) JDBC_PING fails to recover
 for corruption issue
In-Reply-To: <JIRA.12535937.1395688882000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12535937.1395688882000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12535937.1395688882000.14535.1395942013757@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JGRP-1813?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban updated JGRP-1813:
---------------------------

    Summary: JDBC_PING fails to recover for corruption issue  (was: JDBC_PING failes to recover for corruption issue)

    
> JDBC_PING fails to recover for corruption issue
> -----------------------------------------------
>
>                 Key: JGRP-1813
>                 URL: https://issues.jboss.org/browse/JGRP-1813
>             Project: JGroups
>          Issue Type: Feature Request
>    Affects Versions: 3.4
>         Environment: Windows 7
>            Reporter: Brett Donahue
>            Assignee: Bela Ban
>            Priority: Minor
>              Labels: EOFException, JDBC_PING,, corruption
>             Fix For: 3.5
>
>
> heap space was exhausted and issues occurred.  In the end, one node in the cluster must have corrupted the data in the JDBC_PING table.   From this point onward, our log is full of these (every two seconds):
> 2014 03 23 04:00:25#+0100#ERROR#org.jgroups.protocols.SMP_JDBC_PING##anonymous#Thread-15###Error java.io.EOFException: null
>         at java.io.DataInputStream.readUnsignedShort(DataInputStream.java:340)
>         at org.jgroups.stack.IpAddress.readFrom(IpAddress.java:226)
>         at org.jgroups.util.Util.readAddress(Util.java:929)
>         at org.jgroups.util.Util.readAddresses(Util.java:1047)
>         at org.jgroups.protocols.PingData.readFrom(PingData.java:163)
>         at org.jgroups.util.Util.streamableFromByteBuffer(Util.java:753)
>         at org.jgroups.protocols.Discovery.deserialize(Discovery.java:625)
>         at org.jgroups.protocols.JDBC_PING.readAll(JDBC_PING.java:221)
>         at org.jgroups.protocols.JDBC_PING.readAll(JDBC_PING.java:201)
>         at org.jgroups.protocols.FILE_PING.fetchClusterMembers(FILE_PING.java:68)
>         at org.jgroups.protocols.Discovery.sendDiscoveryRequest(Discovery.java:263)
>         at org.jgroups.protocols.Discovery.findMembers(Discovery.java:227)
>         at org.jgroups.protocols.Discovery.findInitialMembers(Discovery.java:208)
>         at org.jgroups.protocols.Discovery.down(Discovery.java:551)
>         at org.jgroups.protocols.FILE_PING.down(FILE_PING.java:101)
>         at org.jgroups.protocols.MERGE2.down(MERGE2.java:185)
>         at org.jgroups.protocols.FD_SOCK.down(FD_SOCK.java:363)
>         at org.jgroups.protocols.FD.down(FD.java:307)
>         at org.jgroups.protocols.VERIFY_SUSPECT.down(VERIFY_SUSPECT.java:84)
>         at org.jgroups.protocols.BARRIER.down(BARRIER.java:95)
>         at org.jgroups.protocols.pbcast.NAKACK2.down(NAKACK2.java:533)
>         at org.jgroups.protocols.UNICAST3.down(UNICAST3.java:575)
>         at org.jgroups.protocols.pbcast.STABLE.down(STABLE.java:347)
>         at org.jgroups.protocols.ENCRYPT.down(ENCRYPT.java:925)
>         at org.jgroups.protocols.pbcast.ClientGmsImpl.findInitialMembers(ClientGmsImpl.java:201)
>         at org.jgroups.protocols.pbcast.ClientGmsImpl.joinInternal(ClientGmsImpl.java:75)
>         at org.jgroups.protocols.pbcast.ClientGmsImpl.join(ClientGmsImpl.java:40)
>         at org.jgroups.protocols.pbcast.GMS.down(GMS.java:1052)
>         at org.jgroups.protocols.FlowControl.down(FlowControl.java:340)
>         at org.jgroups.protocols.FRAG2.down(FRAG2.java:136)
>         at org.jgroups.protocols.pbcast.STATE_TRANSFER.down(STATE_TRANSFER.java:237)
>         at org.jgroups.stack.ProtocolStack.down(ProtocolStack.java:1024)
>         at org.jgroups.JChannel.down(JChannel.java:760)
>         at org.jgroups.JChannel._connect(JChannel.java:538)
>         at org.jgroups.JChannel.connect(JChannel.java:290)
>         at org.jgroups.JChannel.connect(JChannel.java:275)
>         at com.sap.mobile.platform.server.cluster.service.impl.ClusterCommunicationsJGroupImpl.startCommunications(ClusterCommunicationsJGroupImpl.java:45)
>         at com.sap.mobile.platform.server.cluster.service.impl.ClusterCommunicationsJGroupImpl.<init>(ClusterCommunicationsJGroupImpl.java:59)
>         at com.sap.mobile.platform.server.cluster.service.impl.ClusterServiceImpl.run(ClusterServiceImpl.java:187)
>         at java.lang.Thread.run(Thread.java:791)

--
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

From issues at jboss.org  Thu Mar 27 13:42:14 2014
From: issues at jboss.org (Bela Ban (JIRA))
Date: Thu, 27 Mar 2014 13:42:14 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1813) JDBC_PING fails to recover
 for corruption issue
In-Reply-To: <JIRA.12535937.1395688882000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12535937.1395688882000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12535937.1395688882000.14548.1395942134249@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JGRP-1813?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12957136#comment-12957136 ] 

Bela Ban commented on JGRP-1813:
--------------------------------

Assuming you don't want to purge the table manually, the best option I see here is to remove the offending row(s) from the table when encountering an exception.
                
> JDBC_PING fails to recover for corruption issue
> -----------------------------------------------
>
>                 Key: JGRP-1813
>                 URL: https://issues.jboss.org/browse/JGRP-1813
>             Project: JGroups
>          Issue Type: Feature Request
>    Affects Versions: 3.4
>         Environment: Windows 7
>            Reporter: Brett Donahue
>            Assignee: Bela Ban
>            Priority: Minor
>              Labels: EOFException, JDBC_PING,, corruption
>             Fix For: 3.5
>
>
> heap space was exhausted and issues occurred.  In the end, one node in the cluster must have corrupted the data in the JDBC_PING table.   From this point onward, our log is full of these (every two seconds):
> 2014 03 23 04:00:25#+0100#ERROR#org.jgroups.protocols.SMP_JDBC_PING##anonymous#Thread-15###Error java.io.EOFException: null
>         at java.io.DataInputStream.readUnsignedShort(DataInputStream.java:340)
>         at org.jgroups.stack.IpAddress.readFrom(IpAddress.java:226)
>         at org.jgroups.util.Util.readAddress(Util.java:929)
>         at org.jgroups.util.Util.readAddresses(Util.java:1047)
>         at org.jgroups.protocols.PingData.readFrom(PingData.java:163)
>         at org.jgroups.util.Util.streamableFromByteBuffer(Util.java:753)
>         at org.jgroups.protocols.Discovery.deserialize(Discovery.java:625)
>         at org.jgroups.protocols.JDBC_PING.readAll(JDBC_PING.java:221)
>         at org.jgroups.protocols.JDBC_PING.readAll(JDBC_PING.java:201)
>         at org.jgroups.protocols.FILE_PING.fetchClusterMembers(FILE_PING.java:68)
>         at org.jgroups.protocols.Discovery.sendDiscoveryRequest(Discovery.java:263)
>         at org.jgroups.protocols.Discovery.findMembers(Discovery.java:227)
>         at org.jgroups.protocols.Discovery.findInitialMembers(Discovery.java:208)
>         at org.jgroups.protocols.Discovery.down(Discovery.java:551)
>         at org.jgroups.protocols.FILE_PING.down(FILE_PING.java:101)
>         at org.jgroups.protocols.MERGE2.down(MERGE2.java:185)
>         at org.jgroups.protocols.FD_SOCK.down(FD_SOCK.java:363)
>         at org.jgroups.protocols.FD.down(FD.java:307)
>         at org.jgroups.protocols.VERIFY_SUSPECT.down(VERIFY_SUSPECT.java:84)
>         at org.jgroups.protocols.BARRIER.down(BARRIER.java:95)
>         at org.jgroups.protocols.pbcast.NAKACK2.down(NAKACK2.java:533)
>         at org.jgroups.protocols.UNICAST3.down(UNICAST3.java:575)
>         at org.jgroups.protocols.pbcast.STABLE.down(STABLE.java:347)
>         at org.jgroups.protocols.ENCRYPT.down(ENCRYPT.java:925)
>         at org.jgroups.protocols.pbcast.ClientGmsImpl.findInitialMembers(ClientGmsImpl.java:201)
>         at org.jgroups.protocols.pbcast.ClientGmsImpl.joinInternal(ClientGmsImpl.java:75)
>         at org.jgroups.protocols.pbcast.ClientGmsImpl.join(ClientGmsImpl.java:40)
>         at org.jgroups.protocols.pbcast.GMS.down(GMS.java:1052)
>         at org.jgroups.protocols.FlowControl.down(FlowControl.java:340)
>         at org.jgroups.protocols.FRAG2.down(FRAG2.java:136)
>         at org.jgroups.protocols.pbcast.STATE_TRANSFER.down(STATE_TRANSFER.java:237)
>         at org.jgroups.stack.ProtocolStack.down(ProtocolStack.java:1024)
>         at org.jgroups.JChannel.down(JChannel.java:760)
>         at org.jgroups.JChannel._connect(JChannel.java:538)
>         at org.jgroups.JChannel.connect(JChannel.java:290)
>         at org.jgroups.JChannel.connect(JChannel.java:275)
>         at com.sap.mobile.platform.server.cluster.service.impl.ClusterCommunicationsJGroupImpl.startCommunications(ClusterCommunicationsJGroupImpl.java:45)
>         at com.sap.mobile.platform.server.cluster.service.impl.ClusterCommunicationsJGroupImpl.<init>(ClusterCommunicationsJGroupImpl.java:59)
>         at com.sap.mobile.platform.server.cluster.service.impl.ClusterServiceImpl.run(ClusterServiceImpl.java:187)
>         at java.lang.Thread.run(Thread.java:791)

--
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

From issues at jboss.org  Thu Mar 27 14:02:13 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 27 Mar 2014 14:02:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3046) Not possible change the
 object store type from hornetq to jdbc via cli commands
In-Reply-To: <JIRA.12533653.1393610670000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12533653.1393610670000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12533653.1393610670000.14577.1395943333199@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-3046?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12957140#comment-12957140 ] 

RH Bugzilla Integration commented on WFLY-3046:
-----------------------------------------------

Kabir Khan <kkhan at redhat.com> changed the Status of [bug 1038993|https://bugzilla.redhat.com/show_bug.cgi?id=1038993] from POST to MODIFIED
                
> Not possible change the object store type from hornetq to jdbc via cli commands
> -------------------------------------------------------------------------------
>
>                 Key: WFLY-3046
>                 URL: https://issues.jboss.org/browse/WFLY-3046
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Transactions
>    Affects Versions: 8.0.0.Final
>            Reporter: Ivo Studensky
>            Assignee: Ivo Studensky
>             Fix For: 8.0.1.Final
>
>
> When you have set the object store to be type of hornetq and then you change your mind to set it for jdbc object store the jboss-cli permits this operation but no change is propagated to model and XML file.
> How to reproduce:
> # ./bin/standalone.xml (start eap 6.2.0.GA)
> # ./bin/jboss-cli.sh -c (connect to running eap)
> # /subsystem=transactions:write-attribute(name=use-hornetq-store, value=true)
> # :reload# /subsystem=transactions/log-store=log-store:read-attribute(name=type)# /subsystem=transactions:write-attribute(name=use-jdbc-store, value=true)# :reload
> # /subsystem=transactions/log-store=log-store:read-attribute(name=type)
> The object store stays to be set to hornetq and no change happens in the standalone.xml file.

--
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

From issues at jboss.org  Thu Mar 27 14:04:13 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 27 Mar 2014 14:04:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-939) Class-Path manifest entries
 for WARs-in-EAR not handled properly
In-Reply-To: <JIRA.12490006.1366613438000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12490006.1366613438000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12490006.1366613438000.14582.1395943453069@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-939?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12957141#comment-12957141 ] 

RH Bugzilla Integration commented on WFLY-939:
----------------------------------------------

Kabir Khan <kkhan at redhat.com> changed the Status of [bug 955818|https://bugzilla.redhat.com/show_bug.cgi?id=955818] from POST to MODIFIED
                
> Class-Path manifest entries for WARs-in-EAR not handled properly
> ----------------------------------------------------------------
>
>                 Key: WFLY-939
>                 URL: https://issues.jboss.org/browse/WFLY-939
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Server
>            Reporter: James Livingston
>            Assignee: Stuart Douglas
>             Fix For: 8.0.0.Alpha1
>
>
> ManifestClassPathProcessor handles the processing of Class-Path entries in deployments. The handling of those entries in sub-deployments is broken.
> https://github.com/doctau/examples/tree/master/war-manifest-classpath builds an EAR containing a utility JAR and two WARs, where both WARs refer to the jar via Class-Path manifest headers. The jar is not in the EAR's library directory nor in application.xml
> The resulting module setup will result in the jar being added to the first WAR's module, and the remaining WAR(s) depending on a separate "jar classloader". All WARs should depend on the single shared jar classloader.
> When ManifestClassPathProcessor.handlingExistingClassPathEntry() runs for the first war, it will call createAdditionalModule(), which calls createResourceRoot(). The "deploymentUnit.addToAttachmentList(Attachments.RESOURCE_ROOTS, resourceRoot)" adds it to the resource roots for that WAR.
> When handlingExistingClassPathEntry() runs for the second (and subsequent) WAR, it will already be in the additionalModules list, so "target.addToAttachmentList(Attachments.CLASS_PATH_ENTRIES, moduleSpecification.getModuleIdentifier())" gets run.
> I believe the step of adding it to the CLASS_PATH_ENTRIES attachment needs to happen on the first WAR (so it is added as a module dependency), and it should not be added to the DU RESOURCE_ROOTS so it is not in the WAR's own classloader.

--
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

From issues at jboss.org  Thu Mar 27 14:04:13 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 27 Mar 2014 14:04:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3081) Redirect Forward port web
 subsystem1.6 xsd and parser from EAP 6.3
In-Reply-To: <JIRA.12534374.1394189470000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534374.1394189470000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534374.1394189470000.14588.1395943453366@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-3081?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12957143#comment-12957143 ] 

RH Bugzilla Integration commented on WFLY-3081:
-----------------------------------------------

Kabir Khan <kkhan at redhat.com> changed the Status of [bug 900786|https://bugzilla.redhat.com/show_bug.cgi?id=900786] from POST to MODIFIED
                
> Redirect Forward port web subsystem1.6 xsd and parser from EAP 6.3
> ------------------------------------------------------------------
>
>                 Key: WFLY-3081
>                 URL: https://issues.jboss.org/browse/WFLY-3081
>             Project: WildFly
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Web (JBoss Web)
>    Affects Versions: 8.0.0.Final
>            Reporter: Emmanuel Hugonnet
>            Assignee: Emmanuel Hugonnet
>
> Support configuring a connector on the http socket and then redirect to the https socket without having to specify the actual port number outside of the socket-binding-group.
> Support for configuring proxy port and proxy name using socket-binding also.
> + add transformers

--
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

From issues at jboss.org  Thu Mar 27 14:04:14 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 27 Mar 2014 14:04:14 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1070) Add a redirect-socket
 configuration to the web connector config
In-Reply-To: <JIRA.12462483.1332792004000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12462483.1332792004000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12462483.1332792004000.14601.1395943454051@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1070?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12957144#comment-12957144 ] 

RH Bugzilla Integration commented on WFLY-1070:
-----------------------------------------------

Kabir Khan <kkhan at redhat.com> changed the Status of [bug 900786|https://bugzilla.redhat.com/show_bug.cgi?id=900786] from POST to MODIFIED
                
> Add a redirect-socket configuration to the web connector config
> ---------------------------------------------------------------
>
>                 Key: WFLY-1070
>                 URL: https://issues.jboss.org/browse/WFLY-1070
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Web (Undertow)
>            Reporter: Brian Stansberry
>            Assignee: Tomaz Cerar
>             Fix For: 8.0.0.CR1
>
>
> Support configuring a connector on the http socket and then redirect to the https socket without having to specify the actual port number outside of the socket-binding-group.
> The referenced forum thread has an example that uses "redirect-port" for this, but a new attribute would be needed, since changing the meaning of "redirect-port" would be incompatible.
>  

--
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

From issues at jboss.org  Thu Mar 27 14:10:13 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 27 Mar 2014 14:10:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3182) Upgrade to JBoss Negotiation
	2.3.0.CR1
In-Reply-To: <JIRA.12536332.1395939078000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12536332.1395939078000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12536332.1395939078000.14609.1395943813091@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-3182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12957145#comment-12957145 ] 

RH Bugzilla Integration commented on WFLY-3182:
-----------------------------------------------

Darran Lofthouse <darran.lofthouse at redhat.com> changed the Status of [bug 1081607|https://bugzilla.redhat.com/show_bug.cgi?id=1081607] from ASSIGNED to POST
                
> Upgrade to JBoss Negotiation 2.3.0.CR1
> --------------------------------------
>
>                 Key: WFLY-3182
>                 URL: https://issues.jboss.org/browse/WFLY-3182
>             Project: WildFly
>          Issue Type: Component  Upgrade
>      Security Level: Public(Everyone can see) 
>          Components: Security
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 9.0.0.CR1
>
>


--
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

From issues at jboss.org  Thu Mar 27 14:10:13 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 27 Mar 2014 14:10:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (SECURITY-812) Release JBoss Negotiation
	2.3.0.CR1
In-Reply-To: <JIRA.12536331.1395938971000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12536331.1395938971000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12536331.1395938971000.14612.1395943813223@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/SECURITY-812?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12957146#comment-12957146 ] 

RH Bugzilla Integration commented on SECURITY-812:
--------------------------------------------------

Darran Lofthouse <darran.lofthouse at redhat.com> changed the Status of [bug 1081607|https://bugzilla.redhat.com/show_bug.cgi?id=1081607] from ASSIGNED to POST
                
> Release JBoss Negotiation 2.3.0.CR1
> -----------------------------------
>
>                 Key: SECURITY-812
>                 URL: https://issues.jboss.org/browse/SECURITY-812
>             Project: PicketBox 
>          Issue Type: Release
>      Security Level: Public(Everyone can see) 
>          Components: Negotiation
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: Negotiation_2_3_0_CR1
>
>


--
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

From issues at jboss.org  Thu Mar 27 16:40:13 2014
From: issues at jboss.org (Scott Marlow (JIRA))
Date: Thu, 27 Mar 2014 16:40:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3177) wrong placement of
 jipijapa-eclipselink-1.0.1.Final.jar file inside bundle. Eclipselink logger
 to work properly it should be moved from org/eclipse/persistence/main to
 org/jipijapa/eclipselink/main and configured in xml file accordingly.
In-Reply-To: <JIRA.12536256.1395912264000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12536256.1395912264000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12536256.1395912264000.14969.1395952813026@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-3177?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Scott Marlow updated WFLY-3177:
-------------------------------

    Component/s: JPA / Hibernate

    
> wrong placement of jipijapa-eclipselink-1.0.1.Final.jar file inside bundle. Eclipselink logger to work properly it should be moved from org/eclipse/persistence/main to org/jipijapa/eclipselink/main and configured in xml file accordingly.
> ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-3177
>                 URL: https://issues.jboss.org/browse/WFLY-3177
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: JPA / Hibernate
>            Reporter: Ravshan Samandarov
>


--
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

From issues at jboss.org  Thu Mar 27 16:40:13 2014
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Thu, 27 Mar 2014 16:40:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3184) Accept non-list params for
 deployment add command's 'content' param
In-Reply-To: <JIRA.12536362.1395952784911@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12536362.1395952784911@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12536362.1395952784911.14971.1395952813125@jira02.app.mwc.hst.phx2.redhat.com>

Brian Stansberry created WFLY-3184:
--------------------------------------

             Summary: Accept non-list params for deployment add command's 'content' param
                 Key: WFLY-3184
                 URL: https://issues.jboss.org/browse/WFLY-3184
             Project: WildFly
          Issue Type: Enhancement
      Security Level: Public (Everyone can see)
          Components: Domain Management
            Reporter: Brian Stansberry
            Assignee: Brian Stansberry
            Priority: Minor


The deployment resource's 'content' attribute is of type list, but it only accepts a single element. Changing this would break compatibility, but it would be nice if CLI users could skip the useless [].

This could be handled server-side using a ParameterCorrector, but we'd need to figure out how to prevent validation problems when the user tries it in the CLI. 

--
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

From issues at jboss.org  Thu Mar 27 16:54:12 2014
From: issues at jboss.org (Scott Marlow (JIRA))
Date: Thu, 27 Mar 2014 16:54:12 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3177) wrong placement of
 jipijapa-eclipselink-1.0.1.Final.jar file inside bundle. Eclipselink logger
 to work properly it should be moved from org/eclipse/persistence/main to
 org/jipijapa/eclipselink/main and configured in xml file accordingly.
In-Reply-To: <JIRA.12536256.1395912264000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12536256.1395912264000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12536256.1395912264000.14986.1395953652884@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-3177?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12957205#comment-12957205 ] 

Scott Marlow commented on WFLY-3177:
------------------------------------

In the wildfly/modules/system/layers/base/org/eclipse/persistence/main folder is the jipijapa-eclipselink-1.0.1.Final.jar file.  Contents of jipijapa-eclipselink-1.0.1.Final.jar are:
{quote}
META-INF/
META-INF/MANIFEST.MF
org/
org/jipijapa/
org/jipijapa/eclipselink/
META-INF/services/
org/jipijapa/eclipselink/JBossAS7ServerPlatform.class
org/jipijapa/eclipselink/VFSArchive.class
org/jipijapa/eclipselink/VFSArchive$1.class
org/jipijapa/eclipselink/JBossAS7ServerPlatform$JBossAS7TransactionController.class
org/jipijapa/eclipselink/EclipseLinkPersistenceProviderAdaptor.class
org/jipijapa/eclipselink/JBossArchiveFactoryImpl.class
org/jipijapa/eclipselink/JBossLogger.class
META-INF/services/org.jipijapa.plugin.spi.PersistenceProviderAdaptor
META-INF/maven/
META-INF/maven/org.jipijapa/
META-INF/maven/org.jipijapa/jipijapa-eclipselink/
META-INF/maven/org.jipijapa/jipijapa-eclipselink/pom.xml
META-INF/maven/org.jipijapa/jipijapa-eclipselink/pom.properties
{quote}

In [https://github.com/jipijapa/jipijapa/blob/master/eclipselink/src/main/java/org/jipijapa/eclipselink/EclipseLinkPersistenceProviderAdaptor.java#L75], the "eclipselink.logging.logger" property should be set to org.jipijapa.eclipselink.JBossLogger which looks right to me.

What are your persistence.xml contents?  


                
> wrong placement of jipijapa-eclipselink-1.0.1.Final.jar file inside bundle. Eclipselink logger to work properly it should be moved from org/eclipse/persistence/main to org/jipijapa/eclipselink/main and configured in xml file accordingly.
> ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-3177
>                 URL: https://issues.jboss.org/browse/WFLY-3177
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: JPA / Hibernate
>            Reporter: Ravshan Samandarov
>


--
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

From issues at jboss.org  Thu Mar 27 17:17:02 2014
From: issues at jboss.org (Tomaz Cerar (JIRA))
Date: Thu, 27 Mar 2014 17:17:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3100) ClassCastException in JSPs
 where spring-web tags and jstl tags are used
In-Reply-To: <JIRA.12534665.1394544099000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534665.1394544099000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534665.1394544099000.15001.1395955022742@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-3100?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tomaz Cerar resolved WFLY-3100.
-------------------------------

         Assignee: Shelly McGowan  (was: Remy Maucherat)
    Fix Version/s: 8.0.1.Final
       Resolution: Done


Fixed version of spec jsp api was merged to master.
                
> ClassCastException in JSPs where spring-web tags and jstl tags are used
> -----------------------------------------------------------------------
>
>                 Key: WFLY-3100
>                 URL: https://issues.jboss.org/browse/WFLY-3100
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: EE, Web (Undertow)
>    Affects Versions: 8.0.0.Final
>            Reporter: abhishek vijra
>            Assignee: Shelly McGowan
>              Labels: jsp, jstl
>             Fix For: 8.0.1.Final
>
>         Attachments: spring-fun.war
>
>
> Following JSP with spring tags 
> <%@ page contentType="text/html;charset=UTF-8" language="java" %>
> <%@ taglib prefix="c" uri="http://java.sun.com/jstl/core" %>
> <%@ taglib prefix="spring" uri="http://www.springframework.org/tags" %>
> <html>
>   <head><title>Simple jsp page</title></head>
>   <body>
>   
>   <c:set var="hasError" value="${param.hasError}" />
>   <c:set var="msg" value="${param.msg}" />
>   
>   <c:if test="${param.hasError=='true'}">
>     Message: <spring:message text="${param.msg}"/>
>   </c:if>
>   
>   </body>
> </html>
> breaks following error 
>  ERROR [org.springframework.web.servlet.tags.MessageTag] (default task-1) org.apache.taglibs.standard.lang.jstl.ImplicitObjects cannot be cast to javax.servlet.jsp.el.ImplicitObjectELResolver$ImplicitObjects: java.lang.ClassCastException: org.apache.taglibs.standard.lang.jstl.ImplicitObjects cannot be cast to javax.servlet.jsp.el.ImplicitObjectELResolver$ImplicitObjects
> 	at javax.servlet.jsp.el.ImplicitObjectELResolver$ImplicitObjects.getImplicitObjects(ImplicitObjectELResolver.java:608) [jboss-jsp-api_2.3_spec-1.0.0.Final.jar:1.0.0.Final]
> 	at javax.servlet.jsp.el.ImplicitObjectELResolver.getValue(ImplicitObjectELResolver.java:169) [jboss-jsp-api_2.3_spec-1.0.0.Final.jar:1.0.0.Final]
> 	at org.apache.jasper.el.JasperELResolver.getValue(JasperELResolver.java:95) [jastow-1.0.0.Final.jar:1.0.0.Final]
> 	at org.apache.jasper.el.VariableResolverImpl.resolveVariable(VariableResolverImpl.java:32) [jastow-1.0.0.Final.jar:1.0.0.Final]
> 	at org.apache.jasper.el.ELResolverImpl.getValue(ELResolverImpl.java:78) [jastow-1.0.0.Final.jar:1.0.0.Final]
> 	at com.sun.el.parser.AstIdentifier.getValue(AstIdentifier.java:116) [javax.el-3.0.0.jar:3.0.0]
> 	at com.sun.el.parser.AstValue.getBase(AstValue.java:151) [javax.el-3.0.0.jar:3.0.0]
> 	at com.sun.el.parser.AstValue.getValue(AstValue.java:200) [javax.el-3.0.0.jar:3.0.0]
> There are two jars (jboss-jsp-api_2.3_spec-1.0.0.Final.jar and jboss-jstl-api_1.2_spec-1.0.4.Final.jar) that are incompatible with each other due to a bug -- both are storing an object in the same place, but the objects are not compatible.
> The result is that a jsp page cannot contain both JSTL and Spring tags, or it will get that error.

--
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

From issues at jboss.org  Thu Mar 27 18:00:14 2014
From: issues at jboss.org (Desmond Silveira (JIRA))
Date: Thu, 27 Mar 2014 18:00:14 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-458) Drools lock in
 StatelessKnowledgeSessionImpl.
In-Reply-To: <JIRA.12536231.1395882246000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12536231.1395882246000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12536231.1395882246000.15013.1395957614060@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/DROOLS-458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12957214#comment-12957214 ] 

Desmond Silveira commented on DROOLS-458:
-----------------------------------------

I looked through the relevant Drools source code in detail, and I would agree that the synchronization _seems_ to be implemented correctly.  But the fact that I had so many threads blocked for a long period of time certainly seems to indicate that there's a problem in the code.
                
> Drools lock in StatelessKnowledgeSessionImpl.
> ---------------------------------------------
>
>                 Key: DROOLS-458
>                 URL: https://issues.jboss.org/browse/DROOLS-458
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 6.0.1.Final
>         Environment: Tomcat 7
>            Reporter: Desmond Silveira
>            Assignee: Mario Fusco
>         Attachments: la3ldspg05b.txt
>
>
> My Tomcat HTTP BIO connector threads (129 of them) got BLOCKED in my production Tomcat 7 instance because Drool 6.0.1 wasn't releasing a lock.
> Here is a snippet of the thread dump:
> {noformat}
> "http-bio-172.16.216.19-80-exec-37513" - Thread t at 6245360
>    java.lang.Thread.State: BLOCKED
> 	at org.drools.core.runtime.process.ProcessRuntimeFactory.getProcessRuntimeFactoryService(ProcessRuntimeFactory.java:20)
> 	- waiting to lock <219dcd77> (a java.lang.Class) owned by "http-bio-172.16.216.19-80-exec-37511" t at 6245358
> 	at org.drools.core.runtime.process.ProcessRuntimeFactory.newProcessRuntime(ProcessRuntimeFactory.java:12)
> 	at org.drools.core.common.AbstractWorkingMemory.createProcessRuntime(AbstractWorkingMemory.java:405)
> 	at org.drools.core.common.AbstractWorkingMemory.setKnowledgeRuntime(AbstractWorkingMemory.java:1770)
> 	at org.drools.core.impl.StatefulKnowledgeSessionImpl.<init>(StatefulKnowledgeSessionImpl.java:125)
> 	at org.drools.core.impl.StatelessKnowledgeSessionImpl.newWorkingMemory(StatelessKnowledgeSessionImpl.java:139)
> 	at org.drools.core.impl.StatelessKnowledgeSessionImpl.execute(StatelessKnowledgeSessionImpl.java:397)
> 	at com.local.lds.RuleEngineBean.applyKnowledge(RuleEngineBean.java:50)
> 	at com.local.lds.LdsBean.search(LdsBean.java:200)
> 	at com.local.lds.servlet.SearchServlet.doGet(SearchServlet.java:55)
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:621)
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:722)
> 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:305)
> 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
> 	at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:224)
> 	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:169)
> 	at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:472)
> 	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:168)
> 	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:98)
> 	at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:927)
> 	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118)
> 	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:407)
> 	at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:987)
> 	at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:579)
> 	at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:307)
> 	- locked <3575a054> (a org.apache.tomcat.util.net.SocketWrapper)
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
> 	at java.lang.Thread.run(Unknown Source)
>    Locked ownable synchronizers:
> 	- locked <719df963> (a java.util.concurrent.ThreadPoolExecutor$Worker)
> "http-bio-172.16.216.19-80-exec-37511" - Thread t at 6245358
>    java.lang.Thread.State: RUNNABLE
> 	at org.kie.internal.utils.ServiceRegistryImpl.addDefault(ServiceRegistryImpl.java:212)
> 	- locked <3d710637> (a org.kie.internal.utils.ServiceRegistryImpl)
> 	at org.kie.internal.utils.ServiceRegistryImpl.addDefault(ServiceRegistryImpl.java:207)
> 	- locked <3d710637> (a org.kie.internal.utils.ServiceRegistryImpl)
> 	at org.drools.core.runtime.process.ProcessRuntimeFactory.loadProvider(ProcessRuntimeFactory.java:27)
> 	at org.drools.core.runtime.process.ProcessRuntimeFactory.getProcessRuntimeFactoryService(ProcessRuntimeFactory.java:21)
> 	- locked <219dcd77> (a java.lang.Class)
> 	at org.drools.core.runtime.process.ProcessRuntimeFactory.newProcessRuntime(ProcessRuntimeFactory.java:12)
> 	at org.drools.core.common.AbstractWorkingMemory.createProcessRuntime(AbstractWorkingMemory.java:405)
> 	at org.drools.core.common.AbstractWorkingMemory.setKnowledgeRuntime(AbstractWorkingMemory.java:1770)
> 	at org.drools.core.impl.StatefulKnowledgeSessionImpl.<init>(StatefulKnowledgeSessionImpl.java:125)
> 	at org.drools.core.impl.StatelessKnowledgeSessionImpl.newWorkingMemory(StatelessKnowledgeSessionImpl.java:139)
> 	at org.drools.core.impl.StatelessKnowledgeSessionImpl.execute(StatelessKnowledgeSessionImpl.java:397)
> 	at com.local.lds.RuleEngineBean.applyKnowledge(RuleEngineBean.java:50)
> 	at com.local.lds.LdsBean.search(LdsBean.java:200)
> 	at com.local.lds.servlet.SearchServlet.doGet(SearchServlet.java:55)
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:621)
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:722)
> 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:305)
> 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
> 	at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:224)
> 	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:169)
> 	at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:472)
> 	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:168)
> 	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:98)
> 	at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:927)
> 	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118)
> 	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:407)
> 	at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:987)
> 	at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:579)
> 	at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:307)
> 	- locked <474f2464> (a org.apache.tomcat.util.net.SocketWrapper)
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
> 	at java.lang.Thread.run(Unknown Source)
>    Locked ownable synchronizers:
> 	- locked <339f344e> (a java.util.concurrent.ThreadPoolExecutor$Worker)
> "http-bio-172.16.216.19-80-exec-37447" - Thread t at 6233953
>    java.lang.Thread.State: BLOCKED
> 	at org.drools.core.common.ProjectClassLoader.loadClass(ProjectClassLoader.java:82)
> 	- waiting to lock <555896b3> (a org.drools.core.common.ProjectClassLoader) owned by "http-bio-172.16.216.19-80-exec-37519" t at 6245366
> 	at java.lang.ClassLoader.loadClass(Unknown Source)
> 	at org.drools.core.base.ClassFieldAccessorCache.getClass(ClassFieldAccessorCache.java:122)
> 	at org.drools.core.base.ClassFieldAccessorCache.getClassObjectType(ClassFieldAccessorCache.java:46)
> 	at org.drools.core.reteoo.ClassObjectTypeConf.<init>(ClassObjectTypeConf.java:89)
> 	at org.drools.core.common.ObjectTypeConfigurationRegistry.getObjectTypeConf(ObjectTypeConfigurationRegistry.java:71)
> 	at org.drools.core.common.AbstractWorkingMemory.initInitialFact(AbstractWorkingMemory.java:385)
> 	at org.drools.core.common.AbstractWorkingMemory.<init>(AbstractWorkingMemory.java:378)
> 	at org.drools.core.common.AbstractWorkingMemory.<init>(AbstractWorkingMemory.java:261)
> 	at org.drools.core.common.PhreakWorkingMemoryFactory.createWorkingMemory(PhreakWorkingMemoryFactory.java:15)
> 	at org.drools.core.impl.StatelessKnowledgeSessionImpl.newWorkingMemory(StatelessKnowledgeSessionImpl.java:134)
> 	at org.drools.core.impl.StatelessKnowledgeSessionImpl.execute(StatelessKnowledgeSessionImpl.java:397)
> 	at com.local.lds.RuleEngineBean.applyKnowledge(RuleEngineBean.java:50)
> 	at com.local.lds.LdsBean.search(LdsBean.java:200)
> 	at com.local.lds.servlet.SearchServlet.doGet(SearchServlet.java:55)
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:621)
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:722)
> 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:305)
> 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
> 	at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:224)
> 	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:169)
> 	at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:472)
> 	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:168)
> 	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:98)
> 	at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:927)
> 	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118)
> 	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:407)
> 	at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:987)
> 	at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:579)
> 	at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:307)
> 	- locked <57e6b780> (a org.apache.tomcat.util.net.SocketWrapper)
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
> 	at java.lang.Thread.run(Unknown Source)
>    Locked ownable synchronizers:
> 	- locked <726294fc> (a java.util.concurrent.ThreadPoolExecutor$Worker)
> "http-bio-172.16.216.19-80-exec-37519" - Thread t at 6245366
>    java.lang.Thread.State: RUNNABLE
> 	at java.lang.ClassLoader.findLoadedClass0(Native Method)
> 	at java.lang.ClassLoader.findLoadedClass(Unknown Source)
> 	at java.lang.ClassLoader.loadClass(Unknown Source)
> 	- locked <555896b3> (a org.drools.core.common.ProjectClassLoader)
> 	at org.drools.core.common.ProjectClassLoader.internalLoadClass(ProjectClassLoader.java:99)
> 	at org.drools.core.common.ProjectClassLoader.loadClass(ProjectClassLoader.java:82)
> 	- locked <555896b3> (a org.drools.core.common.ProjectClassLoader)
> 	at java.lang.ClassLoader.loadClass(Unknown Source)
> 	at org.drools.core.base.ClassFieldAccessorCache.getClass(ClassFieldAccessorCache.java:122)
> 	at org.drools.core.base.ClassFieldAccessorCache.getClassObjectType(ClassFieldAccessorCache.java:46)
> 	at org.drools.core.reteoo.ClassObjectTypeConf.<init>(ClassObjectTypeConf.java:89)
> 	at org.drools.core.common.ObjectTypeConfigurationRegistry.getObjectTypeConf(ObjectTypeConfigurationRegistry.java:71)
> 	at org.drools.core.common.NamedEntryPoint.insert(NamedEntryPoint.java:164)
> 	at org.drools.core.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:1148)
> 	at org.drools.core.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:1092)
> 	at org.drools.core.impl.StatefulKnowledgeSessionImpl.insert(StatefulKnowledgeSessionImpl.java:308)
> 	at org.drools.core.impl.StatelessKnowledgeSessionImpl.execute(StatelessKnowledgeSessionImpl.java:400)
> 	at com.local.lds.RuleEngineBean.applyKnowledge(RuleEngineBean.java:50)
> 	at com.local.lds.LdsBean.search(LdsBean.java:200)
> 	at com.local.lds.servlet.SearchServlet.doGet(SearchServlet.java:55)
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:621)
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:722)
> 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:305)
> 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
> 	at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:224)
> 	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:169)
> 	at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:472)
> 	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:168)
> 	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:98)
> 	at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:927)
> 	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118)
> 	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:407)
> 	at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:987)
> 	at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:579)
> 	at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:307)
> 	- locked <43c2901> (a org.apache.tomcat.util.net.SocketWrapper)
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
> 	at java.lang.Thread.run(Unknown Source)
>    Locked ownable synchronizers:
> 	- locked <88f8fa9> (a java.util.concurrent.ThreadPoolExecutor$Worker)
> {noformat}
> Here is the code that I use to call Drools:
> {code:java}
>     public static Collection<ResultSet> applyRule(String rule,
>             KieBase kb, Collection<ResultSet> resultSets, SearchParameters params) {
>         try {
>             if (kb == null) {
>                 return resultSets;
>             }
>             StatelessKieSession ksession = kb.newStatelessKieSession();
>             ksession.setGlobal(OUTPUT, new ArrayList<>());
>             Collection<Object> collection = new ArrayList<Object>(resultSets);
>             collection.add(params);
>             ksession.execute(collection);
>             return (Collection<ResultSet>) ksession.getGlobals().get(OUTPUT);
>         } catch (ConsequenceException e) {
>             LOG.error("Error in rule: " + rule + " " + e.getRule(), e);
>             throw e;
>         } catch (RuntimeException e) {
>             LOG.error("Error in rule: " + rule, e);
>             throw e;
>         }
>     }
> {code}

--
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

From issues at jboss.org  Thu Mar 27 18:08:13 2014
From: issues at jboss.org (Paul Ferraro (JIRA))
Date: Thu, 27 Mar 2014 18:08:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3185) Strip cluster name from node
	names
In-Reply-To: <JIRA.12536365.1395958073956@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12536365.1395958073956@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12536365.1395958073956.15022.1395958093336@jira02.app.mwc.hst.phx2.redhat.com>

Paul Ferraro created WFLY-3185:
----------------------------------

             Summary: Strip cluster name from node names
                 Key: WFLY-3185
                 URL: https://issues.jboss.org/browse/WFLY-3185
             Project: WildFly
          Issue Type: Enhancement
      Security Level: Public (Everyone can see)
          Components: Clustering
    Affects Versions: 8.0.0.Final
            Reporter: Paul Ferraro
            Assignee: Paul Ferraro
             Fix For: 9.0.0.CR1


Currently, we generate cluster node names using the following format:

node-name/cluster-name

Including the cluster-name in the node name is redundant and only serves to add unnecessary bytes to messages.

We just need to make sure to include the cluster name in any log messages that refer to the node 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

From issues at jboss.org  Thu Mar 27 20:48:13 2014
From: issues at jboss.org (Jason Kim (JIRA))
Date: Thu, 27 Mar 2014 20:48:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3033) Better SSO configuration
In-Reply-To: <JIRA.12533478.1393493687000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12533478.1393493687000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12533478.1393493687000.15091.1395967693136@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-3033?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12957221#comment-12957221 ] 

Jason Kim commented on WFLY-3033:
---------------------------------

I just enabled "path" configuration and am using it on my wildfly. Figured, some others may not want to wait for the update so I put in a pull request. Pull request - https://github.com/wildfly/wildfly/pull/6099
                
> Better SSO configuration
> ------------------------
>
>                 Key: WFLY-3033
>                 URL: https://issues.jboss.org/browse/WFLY-3033
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Web (Undertow)
>    Affects Versions: 8.0.0.Final
>            Reporter: Tin Tvrtkovic
>            Assignee: Tomaz Cerar
>            Priority: Critical
>              Labels: single-sign-on, undertow
>             Fix For: 8.0.1.Final
>
>
> When enabling Undertow SSO in standalone.xml, the only option to tweak is the cookie domain.
> My life would be made easier by two changes:
> 1) If the domain is not specified, the SSO cookie should have no domain set. This will make the browser apply the domain from the URL being requested. Currently the cookie domain gets populated with a value from the enclosing XML element.
> 2) There's no way of setting the cookie path, which makes this less useful for services on different URLs. I propose adding a path attribute to the SSO XML element, which would set the cookie path. For example:
> <single-sign-on path="/" />
> Right now my workaround is to use my reverse proxy (Apache) to edit response headers and modify the cookie, removing the domain and adding the path. If anyone else needs the workaround:
> Header edit Set-Cookie "^JSESSIONIDSSO=([^; ]+).+" "JSESSIONIDSSO=$1; path=/"

--
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

From issues at jboss.org  Thu Mar 27 21:06:13 2014
From: issues at jboss.org (Radoslav Husar (JIRA))
Date: Thu, 27 Mar 2014 21:06:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3144) Session replication doesn't
 work as expected
In-Reply-To: <JIRA.12535573.1395324594000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12535573.1395324594000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12535573.1395324594000.15123.1395968773759@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-3144?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12957223#comment-12957223 ] 

Radoslav Husar commented on WFLY-3144:
--------------------------------------

This is a Weld issue. See WELD-1635 for fix.

The fix in WildFly will require a Weld upgrade.
                
> Session replication doesn't work as expected
> --------------------------------------------
>
>                 Key: WFLY-3144
>                 URL: https://issues.jboss.org/browse/WFLY-3144
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: CDI / Weld, Clustering, EJB
>    Affects Versions: 8.0.0.Final
>            Reporter: Tomas Remes
>            Assignee: Radoslav Husar
>         Attachments: translator.zip
>
>
> I am experimenting with quite simple Stateful SessionScoped bean  ( see org.jboss.weld.tests.clustering.translator.TranslatorControllerBean from attached reproducer) and actually there's not any specific exception, but the behavior is at least weird. I haven't tried with plain EJB so far. Reproducible by following steps:
> 1. Run first node with "/bin/standalone.sh -c standalone-ha.xml"
> 2. Run second node with "./bin/standalone.sh -c standalone-ha.xml -Djboss.socket.binding.port-offset=100 -Djboss.node.name=second"
> 3. Build and deploy attached reproducer
> 4. Open 127.0.0.1:8080/translator in your browser and translate something.
> 5. Open 127.0.0.1:8180/translator and note that number of translated sentences is not replicated correctly. 
> This works correctly in EAP. I am running with default standalone-ha configuration on oracle's 1.7.0_45 jdk.

--
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

From issues at jboss.org  Thu Mar 27 21:06:13 2014
From: issues at jboss.org (Radoslav Husar (JIRA))
Date: Thu, 27 Mar 2014 21:06:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3144) Session replication doesn't
 work as expected
In-Reply-To: <JIRA.12535573.1395324594000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12535573.1395324594000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12535573.1395324594000.15126.1395968773899@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-3144?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Radoslav Husar updated WFLY-3144:
---------------------------------

    Fix Version/s: 8.0.1.Final

    
> Session replication doesn't work as expected
> --------------------------------------------
>
>                 Key: WFLY-3144
>                 URL: https://issues.jboss.org/browse/WFLY-3144
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: CDI / Weld, Clustering, EJB
>    Affects Versions: 8.0.0.Final
>            Reporter: Tomas Remes
>            Assignee: Radoslav Husar
>             Fix For: 8.0.1.Final
>
>         Attachments: translator.zip
>
>
> I am experimenting with quite simple Stateful SessionScoped bean  ( see org.jboss.weld.tests.clustering.translator.TranslatorControllerBean from attached reproducer) and actually there's not any specific exception, but the behavior is at least weird. I haven't tried with plain EJB so far. Reproducible by following steps:
> 1. Run first node with "/bin/standalone.sh -c standalone-ha.xml"
> 2. Run second node with "./bin/standalone.sh -c standalone-ha.xml -Djboss.socket.binding.port-offset=100 -Djboss.node.name=second"
> 3. Build and deploy attached reproducer
> 4. Open 127.0.0.1:8080/translator in your browser and translate something.
> 5. Open 127.0.0.1:8180/translator and note that number of translated sentences is not replicated correctly. 
> This works correctly in EAP. I am running with default standalone-ha configuration on oracle's 1.7.0_45 jdk.

--
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

From issues at jboss.org  Thu Mar 27 21:54:12 2014
From: issues at jboss.org (Jason Kim (JIRA))
Date: Thu, 27 Mar 2014 21:54:12 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3033) Better SSO configuration
In-Reply-To: <JIRA.12533478.1393493687000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12533478.1393493687000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12533478.1393493687000.15164.1395971652972@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-3033?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12957221#comment-12957221 ] 

Jason Kim edited comment on WFLY-3033 at 3/27/14 9:52 PM:
----------------------------------------------------------

Disregard this comment. Pull Request at https://github.com/wildfly/wildfly/pull/6080 accomplishes what I was looking for. 
                
      was (Author: lc1207h):
    I just enabled "path" configuration and am using it on my wildfly. Figured, some others may not want to wait for the update so I put in a pull request. Pull request - https://github.com/wildfly/wildfly/pull/6099
                  
> Better SSO configuration
> ------------------------
>
>                 Key: WFLY-3033
>                 URL: https://issues.jboss.org/browse/WFLY-3033
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Web (Undertow)
>    Affects Versions: 8.0.0.Final
>            Reporter: Tin Tvrtkovic
>            Assignee: Tomaz Cerar
>            Priority: Critical
>              Labels: single-sign-on, undertow
>             Fix For: 8.0.1.Final
>
>
> When enabling Undertow SSO in standalone.xml, the only option to tweak is the cookie domain.
> My life would be made easier by two changes:
> 1) If the domain is not specified, the SSO cookie should have no domain set. This will make the browser apply the domain from the URL being requested. Currently the cookie domain gets populated with a value from the enclosing XML element.
> 2) There's no way of setting the cookie path, which makes this less useful for services on different URLs. I propose adding a path attribute to the SSO XML element, which would set the cookie path. For example:
> <single-sign-on path="/" />
> Right now my workaround is to use my reverse proxy (Apache) to edit response headers and modify the cookie, removing the domain and adding the path. If anyone else needs the workaround:
> Header edit Set-Cookie "^JSESSIONIDSSO=([^; ]+).+" "JSESSIONIDSSO=$1; path=/"

--
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

From issues at jboss.org  Fri Mar 28 03:02:13 2014
From: issues at jboss.org (Ravshan Samandarov (JIRA))
Date: Fri, 28 Mar 2014 03:02:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3177) wrong placement of
 jipijapa-eclipselink-1.0.1.Final.jar file inside bundle. Eclipselink logger
 to work properly it should be moved from org/eclipse/persistence/main to
 org/jipijapa/eclipselink/main and configured in xml file accordingly.
In-Reply-To: <JIRA.12536256.1395912264000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12536256.1395912264000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12536256.1395912264000.15256.1395990133008@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-3177?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12957236#comment-12957236 ] 

Ravshan Samandarov commented on WFLY-3177:
------------------------------------------

logging didn't work for me until i moved jipijapa-eclipselink-1.0.1.Final.jar to org/jipijapa/eclipselink/main and reconfigured module xml file. and finally I set logging to ServerLogger in persistence.xml
                
> wrong placement of jipijapa-eclipselink-1.0.1.Final.jar file inside bundle. Eclipselink logger to work properly it should be moved from org/eclipse/persistence/main to org/jipijapa/eclipselink/main and configured in xml file accordingly.
> ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-3177
>                 URL: https://issues.jboss.org/browse/WFLY-3177
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: JPA / Hibernate
>            Reporter: Ravshan Samandarov
>


--
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

From issues at jboss.org  Fri Mar 28 03:42:13 2014
From: issues at jboss.org (Bela Ban (JIRA))
Date: Fri, 28 Mar 2014 03:42:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1813) JDBC_PING fails to recover
 for corruption issue
In-Reply-To: <JIRA.12535937.1395688882000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12535937.1395688882000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12535937.1395688882000.15286.1395992533314@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JGRP-1813?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12957241#comment-12957241 ] 

Bela Ban commented on JGRP-1813:
--------------------------------

OK, the row is removed when there's an exception reading it. I'm closing this issue now; please reopen if this still doesn't work.
                
> JDBC_PING fails to recover for corruption issue
> -----------------------------------------------
>
>                 Key: JGRP-1813
>                 URL: https://issues.jboss.org/browse/JGRP-1813
>             Project: JGroups
>          Issue Type: Feature Request
>    Affects Versions: 3.4
>         Environment: Windows 7
>            Reporter: Brett Donahue
>            Assignee: Bela Ban
>            Priority: Minor
>              Labels: EOFException, JDBC_PING,, corruption
>             Fix For: 3.5
>
>
> heap space was exhausted and issues occurred.  In the end, one node in the cluster must have corrupted the data in the JDBC_PING table.   From this point onward, our log is full of these (every two seconds):
> 2014 03 23 04:00:25#+0100#ERROR#org.jgroups.protocols.SMP_JDBC_PING##anonymous#Thread-15###Error java.io.EOFException: null
>         at java.io.DataInputStream.readUnsignedShort(DataInputStream.java:340)
>         at org.jgroups.stack.IpAddress.readFrom(IpAddress.java:226)
>         at org.jgroups.util.Util.readAddress(Util.java:929)
>         at org.jgroups.util.Util.readAddresses(Util.java:1047)
>         at org.jgroups.protocols.PingData.readFrom(PingData.java:163)
>         at org.jgroups.util.Util.streamableFromByteBuffer(Util.java:753)
>         at org.jgroups.protocols.Discovery.deserialize(Discovery.java:625)
>         at org.jgroups.protocols.JDBC_PING.readAll(JDBC_PING.java:221)
>         at org.jgroups.protocols.JDBC_PING.readAll(JDBC_PING.java:201)
>         at org.jgroups.protocols.FILE_PING.fetchClusterMembers(FILE_PING.java:68)
>         at org.jgroups.protocols.Discovery.sendDiscoveryRequest(Discovery.java:263)
>         at org.jgroups.protocols.Discovery.findMembers(Discovery.java:227)
>         at org.jgroups.protocols.Discovery.findInitialMembers(Discovery.java:208)
>         at org.jgroups.protocols.Discovery.down(Discovery.java:551)
>         at org.jgroups.protocols.FILE_PING.down(FILE_PING.java:101)
>         at org.jgroups.protocols.MERGE2.down(MERGE2.java:185)
>         at org.jgroups.protocols.FD_SOCK.down(FD_SOCK.java:363)
>         at org.jgroups.protocols.FD.down(FD.java:307)
>         at org.jgroups.protocols.VERIFY_SUSPECT.down(VERIFY_SUSPECT.java:84)
>         at org.jgroups.protocols.BARRIER.down(BARRIER.java:95)
>         at org.jgroups.protocols.pbcast.NAKACK2.down(NAKACK2.java:533)
>         at org.jgroups.protocols.UNICAST3.down(UNICAST3.java:575)
>         at org.jgroups.protocols.pbcast.STABLE.down(STABLE.java:347)
>         at org.jgroups.protocols.ENCRYPT.down(ENCRYPT.java:925)
>         at org.jgroups.protocols.pbcast.ClientGmsImpl.findInitialMembers(ClientGmsImpl.java:201)
>         at org.jgroups.protocols.pbcast.ClientGmsImpl.joinInternal(ClientGmsImpl.java:75)
>         at org.jgroups.protocols.pbcast.ClientGmsImpl.join(ClientGmsImpl.java:40)
>         at org.jgroups.protocols.pbcast.GMS.down(GMS.java:1052)
>         at org.jgroups.protocols.FlowControl.down(FlowControl.java:340)
>         at org.jgroups.protocols.FRAG2.down(FRAG2.java:136)
>         at org.jgroups.protocols.pbcast.STATE_TRANSFER.down(STATE_TRANSFER.java:237)
>         at org.jgroups.stack.ProtocolStack.down(ProtocolStack.java:1024)
>         at org.jgroups.JChannel.down(JChannel.java:760)
>         at org.jgroups.JChannel._connect(JChannel.java:538)
>         at org.jgroups.JChannel.connect(JChannel.java:290)
>         at org.jgroups.JChannel.connect(JChannel.java:275)
>         at com.sap.mobile.platform.server.cluster.service.impl.ClusterCommunicationsJGroupImpl.startCommunications(ClusterCommunicationsJGroupImpl.java:45)
>         at com.sap.mobile.platform.server.cluster.service.impl.ClusterCommunicationsJGroupImpl.<init>(ClusterCommunicationsJGroupImpl.java:59)
>         at com.sap.mobile.platform.server.cluster.service.impl.ClusterServiceImpl.run(ClusterServiceImpl.java:187)
>         at java.lang.Thread.run(Thread.java:791)

--
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

From issues at jboss.org  Fri Mar 28 03:44:13 2014
From: issues at jboss.org (Bela Ban (JIRA))
Date: Fri, 28 Mar 2014 03:44:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1813) JDBC_PING fails to recover
 for corruption issue
In-Reply-To: <JIRA.12535937.1395688882000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12535937.1395688882000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12535937.1395688882000.15291.1395992653063@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JGRP-1813?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban updated JGRP-1813:
---------------------------

    Fix Version/s: 3.4.4

    
> JDBC_PING fails to recover for corruption issue
> -----------------------------------------------
>
>                 Key: JGRP-1813
>                 URL: https://issues.jboss.org/browse/JGRP-1813
>             Project: JGroups
>          Issue Type: Feature Request
>    Affects Versions: 3.4
>         Environment: Windows 7
>            Reporter: Brett Donahue
>            Assignee: Bela Ban
>            Priority: Minor
>              Labels: EOFException, JDBC_PING,, corruption
>             Fix For: 3.5, 3.4.4
>
>
> heap space was exhausted and issues occurred.  In the end, one node in the cluster must have corrupted the data in the JDBC_PING table.   From this point onward, our log is full of these (every two seconds):
> 2014 03 23 04:00:25#+0100#ERROR#org.jgroups.protocols.SMP_JDBC_PING##anonymous#Thread-15###Error java.io.EOFException: null
>         at java.io.DataInputStream.readUnsignedShort(DataInputStream.java:340)
>         at org.jgroups.stack.IpAddress.readFrom(IpAddress.java:226)
>         at org.jgroups.util.Util.readAddress(Util.java:929)
>         at org.jgroups.util.Util.readAddresses(Util.java:1047)
>         at org.jgroups.protocols.PingData.readFrom(PingData.java:163)
>         at org.jgroups.util.Util.streamableFromByteBuffer(Util.java:753)
>         at org.jgroups.protocols.Discovery.deserialize(Discovery.java:625)
>         at org.jgroups.protocols.JDBC_PING.readAll(JDBC_PING.java:221)
>         at org.jgroups.protocols.JDBC_PING.readAll(JDBC_PING.java:201)
>         at org.jgroups.protocols.FILE_PING.fetchClusterMembers(FILE_PING.java:68)
>         at org.jgroups.protocols.Discovery.sendDiscoveryRequest(Discovery.java:263)
>         at org.jgroups.protocols.Discovery.findMembers(Discovery.java:227)
>         at org.jgroups.protocols.Discovery.findInitialMembers(Discovery.java:208)
>         at org.jgroups.protocols.Discovery.down(Discovery.java:551)
>         at org.jgroups.protocols.FILE_PING.down(FILE_PING.java:101)
>         at org.jgroups.protocols.MERGE2.down(MERGE2.java:185)
>         at org.jgroups.protocols.FD_SOCK.down(FD_SOCK.java:363)
>         at org.jgroups.protocols.FD.down(FD.java:307)
>         at org.jgroups.protocols.VERIFY_SUSPECT.down(VERIFY_SUSPECT.java:84)
>         at org.jgroups.protocols.BARRIER.down(BARRIER.java:95)
>         at org.jgroups.protocols.pbcast.NAKACK2.down(NAKACK2.java:533)
>         at org.jgroups.protocols.UNICAST3.down(UNICAST3.java:575)
>         at org.jgroups.protocols.pbcast.STABLE.down(STABLE.java:347)
>         at org.jgroups.protocols.ENCRYPT.down(ENCRYPT.java:925)
>         at org.jgroups.protocols.pbcast.ClientGmsImpl.findInitialMembers(ClientGmsImpl.java:201)
>         at org.jgroups.protocols.pbcast.ClientGmsImpl.joinInternal(ClientGmsImpl.java:75)
>         at org.jgroups.protocols.pbcast.ClientGmsImpl.join(ClientGmsImpl.java:40)
>         at org.jgroups.protocols.pbcast.GMS.down(GMS.java:1052)
>         at org.jgroups.protocols.FlowControl.down(FlowControl.java:340)
>         at org.jgroups.protocols.FRAG2.down(FRAG2.java:136)
>         at org.jgroups.protocols.pbcast.STATE_TRANSFER.down(STATE_TRANSFER.java:237)
>         at org.jgroups.stack.ProtocolStack.down(ProtocolStack.java:1024)
>         at org.jgroups.JChannel.down(JChannel.java:760)
>         at org.jgroups.JChannel._connect(JChannel.java:538)
>         at org.jgroups.JChannel.connect(JChannel.java:290)
>         at org.jgroups.JChannel.connect(JChannel.java:275)
>         at com.sap.mobile.platform.server.cluster.service.impl.ClusterCommunicationsJGroupImpl.startCommunications(ClusterCommunicationsJGroupImpl.java:45)
>         at com.sap.mobile.platform.server.cluster.service.impl.ClusterCommunicationsJGroupImpl.<init>(ClusterCommunicationsJGroupImpl.java:59)
>         at com.sap.mobile.platform.server.cluster.service.impl.ClusterServiceImpl.run(ClusterServiceImpl.java:187)
>         at java.lang.Thread.run(Thread.java:791)

--
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

From issues at jboss.org  Fri Mar 28 03:44:13 2014
From: issues at jboss.org (Bela Ban (JIRA))
Date: Fri, 28 Mar 2014 03:44:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1813) JDBC_PING fails to recover
 for corruption issue
In-Reply-To: <JIRA.12535937.1395688882000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12535937.1395688882000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12535937.1395688882000.15294.1395992653230@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JGRP-1813?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban resolved JGRP-1813.
----------------------------

    Resolution: Done

    
> JDBC_PING fails to recover for corruption issue
> -----------------------------------------------
>
>                 Key: JGRP-1813
>                 URL: https://issues.jboss.org/browse/JGRP-1813
>             Project: JGroups
>          Issue Type: Feature Request
>    Affects Versions: 3.4
>         Environment: Windows 7
>            Reporter: Brett Donahue
>            Assignee: Bela Ban
>            Priority: Minor
>              Labels: EOFException, JDBC_PING,, corruption
>             Fix For: 3.5, 3.4.4
>
>
> heap space was exhausted and issues occurred.  In the end, one node in the cluster must have corrupted the data in the JDBC_PING table.   From this point onward, our log is full of these (every two seconds):
> 2014 03 23 04:00:25#+0100#ERROR#org.jgroups.protocols.SMP_JDBC_PING##anonymous#Thread-15###Error java.io.EOFException: null
>         at java.io.DataInputStream.readUnsignedShort(DataInputStream.java:340)
>         at org.jgroups.stack.IpAddress.readFrom(IpAddress.java:226)
>         at org.jgroups.util.Util.readAddress(Util.java:929)
>         at org.jgroups.util.Util.readAddresses(Util.java:1047)
>         at org.jgroups.protocols.PingData.readFrom(PingData.java:163)
>         at org.jgroups.util.Util.streamableFromByteBuffer(Util.java:753)
>         at org.jgroups.protocols.Discovery.deserialize(Discovery.java:625)
>         at org.jgroups.protocols.JDBC_PING.readAll(JDBC_PING.java:221)
>         at org.jgroups.protocols.JDBC_PING.readAll(JDBC_PING.java:201)
>         at org.jgroups.protocols.FILE_PING.fetchClusterMembers(FILE_PING.java:68)
>         at org.jgroups.protocols.Discovery.sendDiscoveryRequest(Discovery.java:263)
>         at org.jgroups.protocols.Discovery.findMembers(Discovery.java:227)
>         at org.jgroups.protocols.Discovery.findInitialMembers(Discovery.java:208)
>         at org.jgroups.protocols.Discovery.down(Discovery.java:551)
>         at org.jgroups.protocols.FILE_PING.down(FILE_PING.java:101)
>         at org.jgroups.protocols.MERGE2.down(MERGE2.java:185)
>         at org.jgroups.protocols.FD_SOCK.down(FD_SOCK.java:363)
>         at org.jgroups.protocols.FD.down(FD.java:307)
>         at org.jgroups.protocols.VERIFY_SUSPECT.down(VERIFY_SUSPECT.java:84)
>         at org.jgroups.protocols.BARRIER.down(BARRIER.java:95)
>         at org.jgroups.protocols.pbcast.NAKACK2.down(NAKACK2.java:533)
>         at org.jgroups.protocols.UNICAST3.down(UNICAST3.java:575)
>         at org.jgroups.protocols.pbcast.STABLE.down(STABLE.java:347)
>         at org.jgroups.protocols.ENCRYPT.down(ENCRYPT.java:925)
>         at org.jgroups.protocols.pbcast.ClientGmsImpl.findInitialMembers(ClientGmsImpl.java:201)
>         at org.jgroups.protocols.pbcast.ClientGmsImpl.joinInternal(ClientGmsImpl.java:75)
>         at org.jgroups.protocols.pbcast.ClientGmsImpl.join(ClientGmsImpl.java:40)
>         at org.jgroups.protocols.pbcast.GMS.down(GMS.java:1052)
>         at org.jgroups.protocols.FlowControl.down(FlowControl.java:340)
>         at org.jgroups.protocols.FRAG2.down(FRAG2.java:136)
>         at org.jgroups.protocols.pbcast.STATE_TRANSFER.down(STATE_TRANSFER.java:237)
>         at org.jgroups.stack.ProtocolStack.down(ProtocolStack.java:1024)
>         at org.jgroups.JChannel.down(JChannel.java:760)
>         at org.jgroups.JChannel._connect(JChannel.java:538)
>         at org.jgroups.JChannel.connect(JChannel.java:290)
>         at org.jgroups.JChannel.connect(JChannel.java:275)
>         at com.sap.mobile.platform.server.cluster.service.impl.ClusterCommunicationsJGroupImpl.startCommunications(ClusterCommunicationsJGroupImpl.java:45)
>         at com.sap.mobile.platform.server.cluster.service.impl.ClusterCommunicationsJGroupImpl.<init>(ClusterCommunicationsJGroupImpl.java:59)
>         at com.sap.mobile.platform.server.cluster.service.impl.ClusterServiceImpl.run(ClusterServiceImpl.java:187)
>         at java.lang.Thread.run(Thread.java:791)

--
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

From issues at jboss.org  Fri Mar 28 03:48:12 2014
From: issues at jboss.org (Bela Ban (JIRA))
Date: Fri, 28 Mar 2014 03:48:12 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1721) AUTH and ENCRYPT protocols
 configured with plain text passwords
In-Reply-To: <JIRA.12508425.1382426440000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508425.1382426440000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508425.1382426440000.15298.1395992892996@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JGRP-1721?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban resolved JGRP-1721.
----------------------------

    Resolution: Won't Fix

    
> AUTH and ENCRYPT protocols configured with plain text passwords
> ---------------------------------------------------------------
>
>                 Key: JGRP-1721
>                 URL: https://issues.jboss.org/browse/JGRP-1721
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.4
>            Reporter: Martin Gencur
>            Assignee: Bela Ban
>             Fix For: 3.5
>
>
> The following parameters of AUTH protocol are stored as plain text:
> * keystore_password
> The following parameters of ENCRYPT protocol are stored as plain text:
> * store_password
> * key_password
> Example:
> {code}
> <ENCRYPT key_store_name="defaultStore.keystore" store_password="changeit" alias="myKey"/>
> {code}
> Requirements for storing passwords: https://docspace.corp.redhat.com/docs/DOC-131628

--
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

From issues at jboss.org  Fri Mar 28 03:50:13 2014
From: issues at jboss.org (Ivo Studensky (JIRA))
Date: Fri, 28 Mar 2014 03:50:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBLOGGING-102) Messages#getBundle()
 needs to be privileged
In-Reply-To: <JIRA.12536158.1395838258000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12536158.1395838258000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12536158.1395838258000.15306.1395993013018@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JBLOGGING-102?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12957242#comment-12957242 ] 

Ivo Studensky commented on JBLOGGING-102:
-----------------------------------------

I am sorry I was testing with wrong version.
                
> Messages#getBundle() needs to be privileged
> -------------------------------------------
>
>                 Key: JBLOGGING-102
>                 URL: https://issues.jboss.org/browse/JBLOGGING-102
>             Project: JBoss Logging
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 3.1.4.GA, 3.2.0.Beta1
>            Reporter: Ivo Studensky
>            Assignee: James Perkins
>             Fix For: 3.1.3.GA, 3.2.0.Beta1
>
>
> It ({{org.jboss.logging.Messages#getBundle(Class<T> type, Locale locale)}}) calls {{type.getClassLoader()}} which requires privileges when running with Security Manager.

--
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

From issues at jboss.org  Fri Mar 28 04:40:12 2014
From: issues at jboss.org (Emmanuel Hugonnet (JIRA))
Date: Fri, 28 Mar 2014 04:40:12 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3154) Operation which require
 server reload should check if something was changed
In-Reply-To: <JIRA.12535873.1395667875000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12535873.1395667875000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12535873.1395667875000.15334.1395996012906@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-3154?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Emmanuel Hugonnet updated WFLY-3154:
------------------------------------

    Git Pull Request: https://github.com/wildfly/wildfly/pull/6091  (was: https://github.com/kabir/wildfly/pull/28)

    
>  Operation which require server reload should check if something was changed
> ----------------------------------------------------------------------------
>
>                 Key: WFLY-3154
>                 URL: https://issues.jboss.org/browse/WFLY-3154
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>    Affects Versions: 8.0.0.Final
>            Reporter: Emmanuel Hugonnet
>            Assignee: Emmanuel Hugonnet
>
> Description of problem:
> Server reload is required even if nothing was actually changed. This could have negative impact on usability of WildFly.
> Steps to Reproduce:
>  - start standalone
>  - connect to cli
>  - run: /subsystem=jpa:write-attribute(name=default-extended-persistence-inheritance, value=SHALLOW)
>  - reload server
>  - run: /subsystem=jpa:write-attribute(name=default-extended-persistence-inheritance, value=SHALLOW)
> Actual results:
> {
>     "outcome" => "success",
>     "response-headers" => {
>         "operation-requires-reload" => true,
>         "process-state" => "reload-required"
>     }
> }
> Expected results:
>  - reload is not required

--
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

From issues at jboss.org  Fri Mar 28 04:58:13 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 28 Mar 2014 04:58:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2474) Security subsystem does not
 handle acl's module properly, and is missing transformer
In-Reply-To: <JIRA.12524602.1383913636000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12524602.1383913636000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12524602.1383913636000.15371.1395997093121@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2474?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12957249#comment-12957249 ] 

RH Bugzilla Integration commented on WFLY-2474:
-----------------------------------------------

Ondrej Lukas <olukas at redhat.com> changed the Status of [bug 1029938|https://bugzilla.redhat.com/show_bug.cgi?id=1029938] from ON_QA to VERIFIED
                
> Security subsystem does not handle acl's module properly, and is missing transformer
> ------------------------------------------------------------------------------------
>
>                 Key: WFLY-2474
>                 URL: https://issues.jboss.org/browse/WFLY-2474
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Kabir Khan
>            Assignee: Kabir Khan
>             Fix For: 8.0.0.CR1
>
>
> The parsed add is done for /subsystem=security/security-domain=other/acl=classic/acl-module=acl
> However in the acl resource this is called login-module=acl.
> WHen marshalling
> {code}
> 	<acl>
> 	   <acl-module name="acl" code="AclThingy" flag="required" module="test">
>                 <module-option name="d" value="r"/>
> 	   </acl-module>
> 	</acl>
> {code}
> becomes
> {code}
> 	<acl>
> 	   <login-module name="acl" code="AclThingy" flag="required" module="test">
>                 <module-option name="d" value="r"/>
> 	   </login-module>
> 	</acl>
> {code}

--
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

From issues at jboss.org  Fri Mar 28 05:08:13 2014
From: issues at jboss.org (Jozef Hartinger (JIRA))
Date: Fri, 28 Mar 2014 05:08:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3186) Upgrade to Weld 2.2
In-Reply-To: <JIRA.12536376.1395997650581@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12536376.1395997650581@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12536376.1395997650581.15401.1395997693185@jira02.app.mwc.hst.phx2.redhat.com>

Jozef Hartinger created WFLY-3186:
-------------------------------------

             Summary: Upgrade to Weld 2.2
                 Key: WFLY-3186
                 URL: https://issues.jboss.org/browse/WFLY-3186
             Project: WildFly
          Issue Type: Task
      Security Level: Public (Everyone can see)
            Reporter: Jozef Hartinger
            Assignee: Jozef Hartinger
             Fix For: 8.0.1.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

From issues at jboss.org  Fri Mar 28 05:08:13 2014
From: issues at jboss.org (Jozef Hartinger (JIRA))
Date: Fri, 28 Mar 2014 05:08:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3186) Upgrade to Weld 2.2
In-Reply-To: <JIRA.12536376.1395997650000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12536376.1395997650000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12536376.1395997650000.15404.1395997693399@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-3186?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jozef Hartinger updated WFLY-3186:
----------------------------------

    Fix Version/s:     (was: 8.0.1.Final)

    
> Upgrade to Weld 2.2
> -------------------
>
>                 Key: WFLY-3186
>                 URL: https://issues.jboss.org/browse/WFLY-3186
>             Project: WildFly
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>            Reporter: Jozef Hartinger
>            Assignee: Jozef Hartinger
>


--
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

From issues at jboss.org  Fri Mar 28 05:52:13 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 28 Mar 2014 05:52:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (SECURITY-812) Release JBoss Negotiation
	2.3.0.CR1
In-Reply-To: <JIRA.12536331.1395938971000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12536331.1395938971000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12536331.1395938971000.15624.1396000333435@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/SECURITY-812?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12957271#comment-12957271 ] 

RH Bugzilla Integration commented on SECURITY-812:
--------------------------------------------------

Kabir Khan <kkhan at redhat.com> changed the Status of [bug 1081607|https://bugzilla.redhat.com/show_bug.cgi?id=1081607] from POST to MODIFIED
                
> Release JBoss Negotiation 2.3.0.CR1
> -----------------------------------
>
>                 Key: SECURITY-812
>                 URL: https://issues.jboss.org/browse/SECURITY-812
>             Project: PicketBox 
>          Issue Type: Release
>      Security Level: Public(Everyone can see) 
>          Components: Negotiation
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: Negotiation_2_3_0_CR1
>
>


--
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

From issues at jboss.org  Fri Mar 28 05:52:13 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 28 Mar 2014 05:52:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3182) Upgrade to JBoss Negotiation
	2.3.0.CR1
In-Reply-To: <JIRA.12536332.1395939078000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12536332.1395939078000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12536332.1395939078000.15627.1396000333610@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-3182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12957272#comment-12957272 ] 

RH Bugzilla Integration commented on WFLY-3182:
-----------------------------------------------

Kabir Khan <kkhan at redhat.com> changed the Status of [bug 1081607|https://bugzilla.redhat.com/show_bug.cgi?id=1081607] from POST to MODIFIED
                
> Upgrade to JBoss Negotiation 2.3.0.CR1
> --------------------------------------
>
>                 Key: WFLY-3182
>                 URL: https://issues.jboss.org/browse/WFLY-3182
>             Project: WildFly
>          Issue Type: Component  Upgrade
>      Security Level: Public(Everyone can see) 
>          Components: Security
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 9.0.0.CR1
>
>


--
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

From issues at jboss.org  Fri Mar 28 05:56:12 2014
From: issues at jboss.org (Jim Ma (JIRA))
Date: Fri, 28 Mar 2014 05:56:12 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3187) Can't deploy same webservice
 endpoint impl with different url pattern
In-Reply-To: <JIRA.12536383.1396000502967@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12536383.1396000502967@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12536383.1396000502967.15647.1396000572942@jira02.app.mwc.hst.phx2.redhat.com>

Jim Ma created WFLY-3187:
----------------------------

             Summary: Can't deploy same webservice endpoint impl with different url pattern
                 Key: WFLY-3187
                 URL: https://issues.jboss.org/browse/WFLY-3187
             Project: WildFly
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Web Services
            Reporter: Jim Ma
            Assignee: Jim Ma
             Fix For: 8.0.1.Final


After WFLY-3067 change, CustomerServiceImpl can only be deployed with address http://localhost:8080/webcontext/test1. It should be started with /test2 urlPattern too.
{code:xml}
<?xml version="1.0" encoding="UTF-8"?>
<web-app xmlns="http://java.sun.com/xml/ns/j2ee"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd"
  version="2.4">
  <servlet>
    <servlet-name>TestService</servlet-name>
    <servlet-class>org.jboss.test.ws.jaxws.samples.webresult.CustomerServiceImpl</servlet-class>
  </servlet>
  <servlet-mapping>
    <servlet-name>TestService</servlet-name>
    <url-pattern>/test1/*</url-pattern>
  </servlet-mapping>
  <servlet>
    <servlet-name>TestService2</servlet-name>
    <servlet-class>org.jboss.test.ws.jaxws.samples.webresult.CustomerServiceImpl</servlet-class>
  </servlet>
  <servlet-mapping>
    <servlet-name>TestService2</servlet-name>
    <url-pattern>/test2/*</url-pattern>
  </servlet-mapping>
</web-app>
{code}

--
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

From issues at jboss.org  Fri Mar 28 05:56:13 2014
From: issues at jboss.org (Jim Ma (JIRA))
Date: Fri, 28 Mar 2014 05:56:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3187) Can't deploy same webservice
 endpoint impl with different url patterns
In-Reply-To: <JIRA.12536383.1396000502000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12536383.1396000502000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12536383.1396000502000.15651.1396000573123@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-3187?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jim Ma updated WFLY-3187:
-------------------------

    Summary: Can't deploy same webservice endpoint impl with different url patterns  (was: Can't deploy same webservice endpoint impl with different url pattern)

    
> Can't deploy same webservice endpoint impl with different url patterns
> ----------------------------------------------------------------------
>
>                 Key: WFLY-3187
>                 URL: https://issues.jboss.org/browse/WFLY-3187
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web Services
>            Reporter: Jim Ma
>            Assignee: Jim Ma
>             Fix For: 8.0.1.Final
>
>
> After WFLY-3067 change, CustomerServiceImpl can only be deployed with address http://localhost:8080/webcontext/test1. It should be started with /test2 urlPattern too.
> {code:xml}
> <?xml version="1.0" encoding="UTF-8"?>
> <web-app xmlns="http://java.sun.com/xml/ns/j2ee"
>   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>   xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd"
>   version="2.4">
>   <servlet>
>     <servlet-name>TestService</servlet-name>
>     <servlet-class>org.jboss.test.ws.jaxws.samples.webresult.CustomerServiceImpl</servlet-class>
>   </servlet>
>   <servlet-mapping>
>     <servlet-name>TestService</servlet-name>
>     <url-pattern>/test1/*</url-pattern>
>   </servlet-mapping>
>   <servlet>
>     <servlet-name>TestService2</servlet-name>
>     <servlet-class>org.jboss.test.ws.jaxws.samples.webresult.CustomerServiceImpl</servlet-class>
>   </servlet>
>   <servlet-mapping>
>     <servlet-name>TestService2</servlet-name>
>     <url-pattern>/test2/*</url-pattern>
>   </servlet-mapping>
> </web-app>
> {code}

--
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

From issues at jboss.org  Fri Mar 28 06:32:12 2014
From: issues at jboss.org (gui borland (JIRA))
Date: Fri, 28 Mar 2014 06:32:12 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBJCA-1159) DB Connections leaked if TX
 is not active after retrieving a connection
In-Reply-To: <JIRA.12536390.1396002726453@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12536390.1396002726453@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12536390.1396002726453.15752.1396002732934@jira02.app.mwc.hst.phx2.redhat.com>

gui borland created JBJCA-1159:
----------------------------------

             Summary: DB Connections leaked if TX is not active after retrieving a connection
                 Key: JBJCA-1159
                 URL: https://issues.jboss.org/browse/JBJCA-1159
             Project: IronJacamar
          Issue Type: Bug
          Components: Core
    Affects Versions: 1.0.19.Final
         Environment: AS7 EAP6.1
            Reporter: gui borland
            Assignee: Jesper Pedersen
            Priority: Critical


When  a connection is retrieved from the MCP, ironjacamar will register it to ongoing JTA transaction. However, if the ongoing TX is not 'active' anymore the connection is lost. 



--
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

From issues at jboss.org  Fri Mar 28 06:42:13 2014
From: issues at jboss.org (gui borland (JIRA))
Date: Fri, 28 Mar 2014 06:42:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBJCA-1159) DB Connections leaked if TX
 is not active after retrieving a connection
In-Reply-To: <JIRA.12536390.1396002726000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12536390.1396002726000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12536390.1396002726000.15777.1396003333070@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBJCA-1159?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

gui borland updated JBJCA-1159:
-------------------------------

    Description: 
When  a connection is retrieved from the MCP, ironjacamar will register it to ongoing JTA transaction. However, if the ongoing TX is not 'active' anymore the connection is lost. 

The code of AbstractPool demonstrates the problem. The call to getLock will throw an exception if the current TX is not active anymore and the cl is not returned to the pool.

This issue can be reproduced on AS7 by using any EJB that requires a tx and does something with a DB connection. Put a breakpoint in the code below after retrieving the connectionlistener, and then wait for the transaction to timeout. Once that's done, continue the thread. The connection is not release (can be seen in JMX)

We have noticed this problem regularly during our performance tests. 
{code}
 ConnectionListener cl = mcp.getConnection(subject, cri);
      if (trace)
         log.tracef("Got connection from pool tracked by transaction=%s tx=%s", cl, trackByTransaction);

      TransactionSynchronizationRegistry tsr = getTransactionSynchronizationRegistry();
      Lock lock = getLock();
      try
      {
         lock.lockInterruptibly();
      }
      catch (InterruptedException ie)
      {
         Thread.interrupted();

         throw new ResourceException(bundle.unableObtainLock(), ie);
      }
{code}

It seems this issue was introduced by changes done for https://issues.jboss.org/browse/JBJCA-572

  was:
When  a connection is retrieved from the MCP, ironjacamar will register it to ongoing JTA transaction. However, if the ongoing TX is not 'active' anymore the connection is lost. 




    
> DB Connections leaked if TX is not active after retrieving a connection
> -----------------------------------------------------------------------
>
>                 Key: JBJCA-1159
>                 URL: https://issues.jboss.org/browse/JBJCA-1159
>             Project: IronJacamar
>          Issue Type: Bug
>          Components: Core
>    Affects Versions: 1.0.19.Final
>         Environment: AS7 EAP6.1
>            Reporter: gui borland
>            Assignee: Jesper Pedersen
>            Priority: Critical
>
> When  a connection is retrieved from the MCP, ironjacamar will register it to ongoing JTA transaction. However, if the ongoing TX is not 'active' anymore the connection is lost. 
> The code of AbstractPool demonstrates the problem. The call to getLock will throw an exception if the current TX is not active anymore and the cl is not returned to the pool.
> This issue can be reproduced on AS7 by using any EJB that requires a tx and does something with a DB connection. Put a breakpoint in the code below after retrieving the connectionlistener, and then wait for the transaction to timeout. Once that's done, continue the thread. The connection is not release (can be seen in JMX)
> We have noticed this problem regularly during our performance tests. 
> {code}
>  ConnectionListener cl = mcp.getConnection(subject, cri);
>       if (trace)
>          log.tracef("Got connection from pool tracked by transaction=%s tx=%s", cl, trackByTransaction);
>       TransactionSynchronizationRegistry tsr = getTransactionSynchronizationRegistry();
>       Lock lock = getLock();
>       try
>       {
>          lock.lockInterruptibly();
>       }
>       catch (InterruptedException ie)
>       {
>          Thread.interrupted();
>          throw new ResourceException(bundle.unableObtainLock(), ie);
>       }
> {code}
> It seems this issue was introduced by changes done for https://issues.jboss.org/browse/JBJCA-572

--
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

From issues at jboss.org  Fri Mar 28 07:36:13 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 28 Mar 2014 07:36:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (SECURITY-795) AdvancedLdap login module
 does not handle a user that has a slash character in the uid
In-Reply-To: <JIRA.12532238.1392392424000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12532238.1392392424000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12532238.1392392424000.15913.1396006573556@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/SECURITY-795?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12957310#comment-12957310 ] 

RH Bugzilla Integration commented on SECURITY-795:
--------------------------------------------------

Ondrej Lukas <olukas at redhat.com> changed the Status of [bug 1065476|https://bugzilla.redhat.com/show_bug.cgi?id=1065476] from ON_QA to VERIFIED
                
> AdvancedLdap login module does not handle a user that has a slash character in the uid
> --------------------------------------------------------------------------------------
>
>                 Key: SECURITY-795
>                 URL: https://issues.jboss.org/browse/SECURITY-795
>             Project: PicketBox 
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Negotiation
>    Affects Versions: Negotiation_2_2_5
>            Reporter: Derek Horton
>            Assignee: Derek Horton
>             Fix For: Negotiation_2_2_7
>
>         Attachments: SECURITY-795.patch
>
>
> AdvancedLdap login module does not handle a user that has a slash character in the uid.
> For example, JBoss will fail to authenticate the following user correctly:
> dn: uid=weird/user,ou=Users,dc=my-domain,dc=com
> uid: weird/user
> cn: Weird User

--
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

From issues at jboss.org  Fri Mar 28 07:46:13 2014
From: issues at jboss.org (Scott Marlow (JIRA))
Date: Fri, 28 Mar 2014 07:46:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3177) wrong placement of
 jipijapa-eclipselink-1.0.1.Final.jar file inside bundle. Eclipselink logger
 to work properly it should be moved from org/eclipse/persistence/main to
 org/jipijapa/eclipselink/main and configured in xml file accordingly.
In-Reply-To: <JIRA.12536256.1395912264000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12536256.1395912264000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12536256.1395912264000.15937.1396007173932@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-3177?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12957314#comment-12957314 ] 

Scott Marlow commented on WFLY-3177:
------------------------------------

Why do you have a org/jipijapa/eclipselink/main folder?  

Did you follow the steps listed on [https://docs.jboss.org/author/display/WFLY8/JPA+Reference+Guide#JPAReferenceGuide-UsingEclipseLink]?  I'm trying to understand if we have a software bug somewhere or if this is just configuration.  

I suspect that your persistence.xml is specifying the "org.jipijapa.eclipselink" module instead of the default  "org.eclipse.persistence".  But, I need to see your persistence.xml to tell for sure.
                
> wrong placement of jipijapa-eclipselink-1.0.1.Final.jar file inside bundle. Eclipselink logger to work properly it should be moved from org/eclipse/persistence/main to org/jipijapa/eclipselink/main and configured in xml file accordingly.
> ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-3177
>                 URL: https://issues.jboss.org/browse/WFLY-3177
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: JPA / Hibernate
>            Reporter: Ravshan Samandarov
>


--
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

From issues at jboss.org  Fri Mar 28 08:28:12 2014
From: issues at jboss.org (Shrihari Chakrapani (JIRA))
Date: Fri, 28 Mar 2014 08:28:12 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBJCA-1159) DB Connections leaked if TX
 is not active after retrieving a connection
In-Reply-To: <JIRA.12536390.1396002726000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12536390.1396002726000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12536390.1396002726000.16028.1396009692995@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JBJCA-1159?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12957328#comment-12957328 ] 

Shrihari Chakrapani commented on JBJCA-1159:
--------------------------------------------

An example of how acquiring a lock can fail, if a TX timesout
{noformat}
Caused by: java.lang.IllegalStateException: No transaction is running
        at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionSynchronizationRegistryImple.getTransactionImple(TransactionSynchronizationRegistryImple.java:232)
        at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionSynchronizationRegistryImple.getResource(TransactionSynchronizationRegistryImple.java:125)
        at org.jboss.jca.core.connectionmanager.pool.AbstractPool.getLock(AbstractPool.java:264)
        at org.jboss.jca.core.connectionmanager.pool.AbstractPool.getTransactionNewConnection(AbstractPool.java:500)
        at org.jboss.jca.core.connectionmanager.pool.AbstractPool.getConnection(AbstractPool.java:374)
        at org.jboss.jca.core.connectionmanager.AbstractConnectionManager.getManagedConnection(AbstractConnectionManager.java:329)
        at org.jboss.jca.core.connectionmanager.tx.TxConnectionManagerImpl.getManagedConnection(TxConnectionManagerImpl.java:368)
        at org.jboss.jca.core.connectionmanager.AbstractConnectionManager.allocateConnection(AbstractConnectionManager.java:464)
        at org.jboss.jca.adapters.jdbc.WrapperDataSource.getConnection(WrapperDataSource.java:139)
        at org.hibernate.ejb.connection.InjectedDataSourceConnectionProvider.getConnection(InjectedDataSourceConnectionProvider.java:70)
        at org.hibernate.internal.AbstractSessionImpl$NonContextualJdbcConnectionAccess.obtainConnection(AbstractSessionImpl.java:292)
        at org.hibernate.engine.jdbc.internal.LogicalConnectionImpl.obtainConnection(LogicalConnectionImpl.java:214)
        at org.hibernate.engine.jdbc.internal.LogicalConnectionImpl.getConnection(LogicalConnectionImpl.java:157)
        at org.hibernate.engine.jdbc.internal.StatementPreparerImpl.connection(StatementPreparerImpl.java:56)
        at org.hibernate.engine.jdbc.internal.StatementPreparerImpl$5.doPrepare(StatementPreparerImpl.java:161)
        at org.hibernate.engine.jdbc.internal.StatementPreparerImpl$StatementPreparationTemplate.prepareStatement(StatementPreparerImpl.java:182)
        at org.hibernate.engine.jdbc.internal.StatementPreparerImpl.prepareQueryStatement(StatementPreparerImpl.java:159)
        at org.hibernate.loader.Loader.prepareQueryStatement(Loader.java:1854)
        at org.hibernate.loader.Loader.executeQueryStatement(Loader.java:1831)
        at org.hibernate.loader.Loader.executeQueryStatement(Loader.java:1811)
        at org.hibernate.loader.Loader.doQuery(Loader.java:899)
        at org.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections(Loader.java:341)
        at org.hibernate.loader.Loader.doList(Loader.java:2516)
        at org.hibernate.loader.Loader.doList(Loader.java:2502)
        at org.hibernate.loader.Loader.listIgnoreQueryCache(Loader.java:2332)
        at org.hibernate.loader.Loader.list(Loader.java:2327)
        at org.hibernate.loader.hql.QueryLoader.list(QueryLoader.java:490)
        at org.hibernate.hql.internal.ast.QueryTranslatorImpl.list(QueryTranslatorImpl.java:355)
        at org.hibernate.engine.query.spi.HQLQueryPlan.performList(HQLQueryPlan.java:195)
        at org.hibernate.internal.SessionImpl.list(SessionImpl.java:1269)
        at org.hibernate.internal.QueryImpl.list(QueryImpl.java:101)
        at org.hibernate.ejb.QueryImpl.getResultList(QueryImpl.java:264)
{noformat}
                
> DB Connections leaked if TX is not active after retrieving a connection
> -----------------------------------------------------------------------
>
>                 Key: JBJCA-1159
>                 URL: https://issues.jboss.org/browse/JBJCA-1159
>             Project: IronJacamar
>          Issue Type: Bug
>          Components: Core
>    Affects Versions: 1.0.19.Final
>         Environment: AS7 EAP6.1
>            Reporter: gui borland
>            Assignee: Jesper Pedersen
>            Priority: Critical
>
> When  a connection is retrieved from the MCP, ironjacamar will register it to ongoing JTA transaction. However, if the ongoing TX is not 'active' anymore the connection is lost. 
> The code of AbstractPool demonstrates the problem. The call to getLock will throw an exception if the current TX is not active anymore and the cl is not returned to the pool.
> This issue can be reproduced on AS7 by using any EJB that requires a tx and does something with a DB connection. Put a breakpoint in the code below after retrieving the connectionlistener, and then wait for the transaction to timeout. Once that's done, continue the thread. The connection is not release (can be seen in JMX)
> We have noticed this problem regularly during our performance tests. 
> {code}
>  ConnectionListener cl = mcp.getConnection(subject, cri);
>       if (trace)
>          log.tracef("Got connection from pool tracked by transaction=%s tx=%s", cl, trackByTransaction);
>       TransactionSynchronizationRegistry tsr = getTransactionSynchronizationRegistry();
>       Lock lock = getLock();
>       try
>       {
>          lock.lockInterruptibly();
>       }
>       catch (InterruptedException ie)
>       {
>          Thread.interrupted();
>          throw new ResourceException(bundle.unableObtainLock(), ie);
>       }
> {code}
> It seems this issue was introduced by changes done for https://issues.jboss.org/browse/JBJCA-572

--
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

From issues at jboss.org  Fri Mar 28 09:22:13 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 28 Mar 2014 09:22:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-352) Add sufficient TRACE / DEBUG
 logging to debug security realm configurations.
In-Reply-To: <JIRA.12489981.1366392604000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12489981.1366392604000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12489981.1366392604000.16140.1396012933377@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-352?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12957344#comment-12957344 ] 

RH Bugzilla Integration commented on WFLY-352:
----------------------------------------------

Ondrej Lukas <olukas at redhat.com> changed the Status of [bug 974324|https://bugzilla.redhat.com/show_bug.cgi?id=974324] from ON_QA to ASSIGNED
                
> Add sufficient TRACE / DEBUG logging to debug security realm configurations.
> ----------------------------------------------------------------------------
>
>                 Key: WFLY-352
>                 URL: https://issues.jboss.org/browse/WFLY-352
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>            Reporter: Eric Rich
>            Assignee: Darran Lofthouse
>            Priority: Critical
>             Fix For: 8.0.0.Beta1
>
>         Attachments: jboss-as-domain-management-7.1.2.Final-redhat-1.jar, log_mgmt_auth_calls.txt
>
>
> When trying to diagnose LDAP or Admin Configuration issue in Domain mode there is currently no logging for any of the authentication information. 

--
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

From issues at jboss.org  Fri Mar 28 09:22:13 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 28 Mar 2014 09:22:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2408) Add TRACE logging for
 connection properties used to connect to LDAP from realm.
In-Reply-To: <JIRA.12509083.1383136851000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12509083.1383136851000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12509083.1383136851000.16146.1396012933645@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2408?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12957345#comment-12957345 ] 

RH Bugzilla Integration commented on WFLY-2408:
-----------------------------------------------

Ondrej Lukas <olukas at redhat.com> changed the Status of [bug 974324|https://bugzilla.redhat.com/show_bug.cgi?id=974324] from ON_QA to ASSIGNED
                
> Add TRACE logging for connection properties used to connect to LDAP from realm.
> -------------------------------------------------------------------------------
>
>                 Key: WFLY-2408
>                 URL: https://issues.jboss.org/browse/WFLY-2408
>             Project: WildFly
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management, Security
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 8.0.0.CR1
>
>


--
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

From issues at jboss.org  Fri Mar 28 09:33:01 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 28 Mar 2014 09:33:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3131) isSensitiveValue of class
 SensitiveVaultExpressionConstraint uses incorrect index in
 java.lang.String.substring method
In-Reply-To: <JIRA.12535307.1395160191000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12535307.1395160191000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12535307.1395160191000.16161.1396013581479@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-3131?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12957348#comment-12957348 ] 

RH Bugzilla Integration commented on WFLY-3131:
-----------------------------------------------

Ondrej Lukas <olukas at redhat.com> changed the Status of [bug 1077838|https://bugzilla.redhat.com/show_bug.cgi?id=1077838] from ON_QA to VERIFIED
                
> isSensitiveValue of class SensitiveVaultExpressionConstraint uses incorrect  index in java.lang.String.substring method
> -----------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-3131
>                 URL: https://issues.jboss.org/browse/WFLY-3131
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>    Affects Versions: 8.0.0.Final
>         Environment: All
>            Reporter: Jay Kumar SenSharma
>            Assignee: Jay Kumar SenSharma
>
> The isSensitiveValue(ModelNode value) method of class "org.jboss.as.controller.access.constraint.SensitiveVaultExpressionConstraint" seems to be using the incorrect  index in java.lang.String.substring method.  Which is causing the following exceptions in the logs while executing the following kind of CLI command:
> {code}
> [standalone at localhost:9990 /] /subsystem=logging/periodic-rotating-file-handler=FILE:write-attribute(name=formatter, value="%d{HH:mm:ss,SSS} %-5p [%c] (${jboss.node.name} %t) %s%E%n")
> {
>     "outcome" => "failed",
>     "failure-description" => "JBAS014749: Operation handler failed: String index out of range: -15",
>     "rolled-back" => true
> }
> {code}
> The Exception can be seen as following in the WildFly Logs:
> {code}
> 21:58:04,821 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 25) JBAS014612: Operation ("write-attribute") failed - address: ([
>     ("subsystem" => "logging"),
>     ("periodic-rotating-file-handler" => "FILE")
> ]): java.lang.StringIndexOutOfBoundsException: String index out of range: -15
> 	at java.lang.String.substring(String.java:1911) [rt.jar:1.7.0_51]
> 	at org.jboss.as.controller.access.constraint.SensitiveVaultExpressionConstraint$Factory.isSensitiveValue(SensitiveVaultExpressionConstraint.java:128) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> 	at org.jboss.as.controller.access.constraint.SensitiveVaultExpressionConstraint$Factory.isSensitiveAction(SensitiveVaultExpressionConstraint.java:89) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> 	at org.jboss.as.controller.access.constraint.SensitiveVaultExpressionConstraint$Factory.getRequiredConstraint(SensitiveVaultExpressionConstraint.java:81) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> 	at org.jboss.as.controller.access.rbac.DefaultPermissionFactory.getRequiredPermissions(DefaultPermissionFactory.java:201) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> 	at org.jboss.as.controller.access.permission.ManagementPermissionAuthorizer.authorize(ManagementPermissionAuthorizer.java:100) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> 	at org.jboss.as.controller.access.management.DelegatingConfigurableAuthorizer.authorize(DelegatingConfigurableAuthorizer.java:98) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> 	at org.jboss.as.controller.OperationContextImpl.getBasicAuthorizationResponse(OperationContextImpl.java:1153) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> 	at org.jboss.as.controller.OperationContextImpl.authorize(OperationContextImpl.java:1055) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> 	at org.jboss.as.controller.OperationContextImpl.authorize(OperationContextImpl.java:1015) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> 	at org.jboss.as.controller.OperationContextImpl.getResourceRegistration(OperationContextImpl.java:265) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> 	at org.jboss.as.controller.operations.global.WriteAttributeHandler.execute(WriteAttributeHandler.java:72) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> 	at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:591) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> 	at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:469) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> 	at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:273) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> 	at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:268) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> 	at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:272) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> 	at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:146) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:174) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$300(ModelControllerClientOperationHandler.java:105) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:125) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:121) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> 	at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.7.0_51]
> 	at javax.security.auth.Subject.doAs(Subject.java:415) [rt.jar:1.7.0_51]
> 	at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:94) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:121) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> 	at org.jboss.as.protocol.mgmt.AbstractMessageHandler$2$1.doExecute(AbstractMessageHandler.java:283) [wildfly-protocol-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> 	at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:504) [wildfly-protocol-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_51]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_51]
> 	at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_51]
> 	at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.1.Final.jar:2.1.1.Final]
> {code}

--
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

From issues at jboss.org  Fri Mar 28 10:14:13 2014
From: issues at jboss.org (Radoslav Husar (JIRA))
Date: Fri, 28 Mar 2014 10:14:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3144) Session replication doesn't
 work as expected
In-Reply-To: <JIRA.12535573.1395324594000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12535573.1395324594000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12535573.1395324594000.16254.1396016053269@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-3144?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12957357#comment-12957357 ] 

Radoslav Husar commented on WFLY-3144:
--------------------------------------

To test, pull in the changes from https://github.com/wildfly/wildfly/pull/6097 and patched/master build of Weld.
                
> Session replication doesn't work as expected
> --------------------------------------------
>
>                 Key: WFLY-3144
>                 URL: https://issues.jboss.org/browse/WFLY-3144
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: CDI / Weld, Clustering, EJB
>    Affects Versions: 8.0.0.Final
>            Reporter: Tomas Remes
>            Assignee: Radoslav Husar
>             Fix For: 8.0.1.Final
>
>         Attachments: translator.zip
>
>
> I am experimenting with quite simple Stateful SessionScoped bean  ( see org.jboss.weld.tests.clustering.translator.TranslatorControllerBean from attached reproducer) and actually there's not any specific exception, but the behavior is at least weird. I haven't tried with plain EJB so far. Reproducible by following steps:
> 1. Run first node with "/bin/standalone.sh -c standalone-ha.xml"
> 2. Run second node with "./bin/standalone.sh -c standalone-ha.xml -Djboss.socket.binding.port-offset=100 -Djboss.node.name=second"
> 3. Build and deploy attached reproducer
> 4. Open 127.0.0.1:8080/translator in your browser and translate something.
> 5. Open 127.0.0.1:8180/translator and note that number of translated sentences is not replicated correctly. 
> This works correctly in EAP. I am running with default standalone-ha configuration on oracle's 1.7.0_45 jdk.

--
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

From issues at jboss.org  Fri Mar 28 10:30:13 2014
From: issues at jboss.org (Akhbar Falafel (JIRA))
Date: Fri, 28 Mar 2014 10:30:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3181) Hibernate Search w/
 Infinispan - java.lang.Class cannot be cast to java.util.Map
In-Reply-To: <JIRA.12536328.1395938405000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12536328.1395938405000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12536328.1395938405000.16279.1396017013151@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-3181?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Akhbar Falafel updated WFLY-3181:
---------------------------------

    Issue Type: Bug  (was: Feature Request)

    
> Hibernate Search w/ Infinispan - java.lang.Class cannot be cast to java.util.Map
> --------------------------------------------------------------------------------
>
>                 Key: WFLY-3181
>                 URL: https://issues.jboss.org/browse/WFLY-3181
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JPA / Hibernate
>    Affects Versions: 8.0.0.Final
>         Environment: Wildfly 8.0, OS X 10.9.2
>            Reporter: Akhbar Falafel
>            Assignee: Sanne Grinovero
>
> When configuring Hibernate Search to use Infinispan as its directory provider, a java.lang.ClassCastException occurs upon deployment of an application making use of Hibernate Search.
> Relevant portion of standalone-full-ha.xml:
> {code:xml}
>             <cache-container name="hibernateSearch" default-cache="LuceneIndexesData" jndi-name="java:jboss/infinispan/hibernateSearch" start="EAGER" statistics-enabled="true">
>                 <transport lock-timeout="60000"/>
>                 <replicated-cache name="LuceneIndexesMetadata" start="EAGER" statistics-enabled="true" mode="SYNC">
>                     <binary-keyed-jdbc-store shared="true" preload="true" passivation="false" purge="false" datasource="java:jboss/datasources/InfinispanDatasource">
>                         <binary-keyed-table>
>                             <id-column name="ID_COLUMN" type="VARCHAR(255)"/>
>                             <data-column name="DATUM" type="BYTEA"/>
>                         </binary-keyed-table>
>                     </binary-keyed-jdbc-store>
>                 </replicated-cache>
>                 <replicated-cache name="LuceneIndexesData" start="EAGER" statistics-enabled="true" mode="SYNC">
>                     <binary-keyed-jdbc-store shared="true" preload="true" passivation="false" purge="false" datasource="java:jboss/datasources/InfinispanDatasource">
>                         <binary-keyed-table>
>                             <id-column name="ID_COLUMN" type="VARCHAR(255)"/>
>                             <data-column name="DATUM" type="BYTEA"/>
>                         </binary-keyed-table>
>                     </binary-keyed-jdbc-store>
>                 </replicated-cache>
>                 <replicated-cache name="LuceneIndexesLocking" start="EAGER" statistics-enabled="true" mode="SYNC"/>
>             </cache-container>
> {code}
> Relevant portion of persistence.xml:
> {code:xml}
> 			<!-- Hibernate Search properties - Infinispan -->
> 			<property name="hibernate.search.infinispan.cachemanager_jndiname"
> 				value="java:jboss/infinispan/hibernateSearch" />
> 			<property name="hibernate.search.default.directory_provider"
> 				value="infinispan" />
> 			<property name="hibernate.search.infinispan.chunk_size"
> 				value="300000000" />
> 			<property name="hibernate.search.reader.strategy" value="shared" />
> 			<property name="hibernate.search.worker.execution" value="sync" />
> 			<property name="hibernate.search.jmx_enabled" value="true" />
> 			<property name="hibernate.search.autoregister_listeners"
> 				value="true" />
> {code}
> Stack trace of Exception upon deployment:
> {noformat}
> 12:35:09,837 DEBUG [org.jboss.jca.core.connectionmanager.pool.strategy.OnePool] (ServerService Thread Pool -- 62) InfinispanDS: returnConnection(3ea8c21b, false) [1/20]
> 12:35:09,837 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 62) MSC000001: Failed to start service jboss.infinispan.hibernateSearch.LuceneIndexesData: org.jboss.msc.service.StartException in service jboss.infinispan.hibernateSearch.LuceneIndexesData: org.infinispan.commons.CacheException: Unable to invoke method public void org.infinispan.persistence.manager.PersistenceManagerImpl.preload() on object of type PersistenceManagerImpl
> 	at org.jboss.as.clustering.msc.AsynchronousService$1.run(AsynchronousService.java:91) [wildfly-clustering-common-8.0.0.Final.jar:8.0.0.Final]
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_51]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_51]
> 	at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_51]
> 	at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.1.Final.jar:2.1.1.Final]
> Caused by: org.infinispan.commons.CacheException: Unable to invoke method public void org.infinispan.persistence.manager.PersistenceManagerImpl.preload() on object of type PersistenceManagerImpl
> 	at org.infinispan.commons.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:185)
> 	at org.infinispan.factories.AbstractComponentRegistry$PrioritizedMethod.invoke(AbstractComponentRegistry.java:869)
> 	at org.infinispan.factories.AbstractComponentRegistry.invokeStartMethods(AbstractComponentRegistry.java:638)
> 	at org.infinispan.factories.AbstractComponentRegistry.internalStart(AbstractComponentRegistry.java:627)
> 	at org.infinispan.factories.AbstractComponentRegistry.start(AbstractComponentRegistry.java:530)
> 	at org.infinispan.factories.ComponentRegistry.start(ComponentRegistry.java:216)
> 	at org.infinispan.CacheImpl.start(CacheImpl.java:675)
> 	at org.infinispan.manager.DefaultCacheManager.wireAndStartCache(DefaultCacheManager.java:553)
> 	at org.infinispan.manager.DefaultCacheManager.createCache(DefaultCacheManager.java:516)
> 	at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:398)
> 	at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:412)
> 	at org.jboss.as.clustering.infinispan.DefaultCacheContainer.getCache(DefaultCacheContainer.java:103)
> 	at org.jboss.as.clustering.infinispan.DefaultCacheContainer.getCache(DefaultCacheContainer.java:94)
> 	at org.jboss.as.clustering.infinispan.subsystem.CacheService.start(CacheService.java:78)
> 	at org.jboss.as.clustering.msc.AsynchronousService$1.run(AsynchronousService.java:86) [wildfly-clustering-common-8.0.0.Final.jar:8.0.0.Final]
> 	... 4 more
> Caused by: java.lang.ClassCastException: java.lang.Class cannot be cast to java.util.Map
> 	at org.infinispan.persistence.jdbc.binary.JdbcBinaryStore.unmarshallBucket(JdbcBinaryStore.java:577)
> 	at org.infinispan.persistence.jdbc.binary.JdbcBinaryStore.process(JdbcBinaryStore.java:190)
> 	at org.infinispan.persistence.manager.PersistenceManagerImpl.preload(PersistenceManagerImpl.java:214)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_51]
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_51]
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_51]
> 	at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_51]
> 	at org.infinispan.commons.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:183)
> 	... 18 more
> 12:35:09,837 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 66) MSC000001: Failed to start service jboss.infinispan.hibernateSearch.LuceneIndexesMetadata: org.jboss.msc.service.StartException in service jboss.infinispan.hibernateSearch.LuceneIndexesMetadata: org.infinispan.commons.CacheException: Unable to invoke method public void org.infinispan.persistence.manager.PersistenceManagerImpl.preload() on object of type PersistenceManagerImpl
> 	at org.jboss.as.clustering.msc.AsynchronousService$1.run(AsynchronousService.java:91) [wildfly-clustering-common-8.0.0.Final.jar:8.0.0.Final]
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_51]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_51]
> 	at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_51]
> 	at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.1.Final.jar:2.1.1.Final]
> Caused by: org.infinispan.commons.CacheException: Unable to invoke method public void org.infinispan.persistence.manager.PersistenceManagerImpl.preload() on object of type PersistenceManagerImpl
> 	at org.infinispan.commons.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:185)
> 	at org.infinispan.factories.AbstractComponentRegistry$PrioritizedMethod.invoke(AbstractComponentRegistry.java:869)
> 	at org.infinispan.factories.AbstractComponentRegistry.invokeStartMethods(AbstractComponentRegistry.java:638)
> 	at org.infinispan.factories.AbstractComponentRegistry.internalStart(AbstractComponentRegistry.java:627)
> 	at org.infinispan.factories.AbstractComponentRegistry.start(AbstractComponentRegistry.java:530)
> 	at org.infinispan.factories.ComponentRegistry.start(ComponentRegistry.java:216)
> 	at org.infinispan.CacheImpl.start(CacheImpl.java:675)
> 	at org.infinispan.manager.DefaultCacheManager.wireAndStartCache(DefaultCacheManager.java:553)
> 	at org.infinispan.manager.DefaultCacheManager.createCache(DefaultCacheManager.java:516)
> 	at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:398)
> 	at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:412)
> 	at org.jboss.as.clustering.infinispan.DefaultCacheContainer.getCache(DefaultCacheContainer.java:103)
> 	at org.jboss.as.clustering.infinispan.DefaultCacheContainer.getCache(DefaultCacheContainer.java:94)
> 	at org.jboss.as.clustering.infinispan.subsystem.CacheService.start(CacheService.java:78)
> 	at org.jboss.as.clustering.msc.AsynchronousService$1.run(AsynchronousService.java:86) [wildfly-clustering-common-8.0.0.Final.jar:8.0.0.Final]
> 	... 4 more
> Caused by: java.lang.ClassCastException: java.lang.Class cannot be cast to java.util.Map
> 	at org.infinispan.persistence.jdbc.binary.JdbcBinaryStore.unmarshallBucket(JdbcBinaryStore.java:577)
> 	at org.infinispan.persistence.jdbc.binary.JdbcBinaryStore.process(JdbcBinaryStore.java:190)
> 	at org.infinispan.persistence.manager.PersistenceManagerImpl.preload(PersistenceManagerImpl.java:214)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_51]
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_51]
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_51]
> 	at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_51]
> 	at org.infinispan.commons.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:183)
> 	... 18 more
> {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

From issues at jboss.org  Fri Mar 28 11:00:13 2014
From: issues at jboss.org (Paul Ferraro (JIRA))
Date: Fri, 28 Mar 2014 11:00:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3188) Optimize use of Infinispan
	listeners
In-Reply-To: <JIRA.12536472.1396018713551@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12536472.1396018713551@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12536472.1396018713551.16360.1396018813950@jira02.app.mwc.hst.phx2.redhat.com>

Paul Ferraro created WFLY-3188:
----------------------------------

             Summary: Optimize use of Infinispan listeners
                 Key: WFLY-3188
                 URL: https://issues.jboss.org/browse/WFLY-3188
             Project: WildFly
          Issue Type: Enhancement
      Security Level: Public (Everyone can see)
          Components: Clustering
    Affects Versions: 8.0.0.Final
            Reporter: Paul Ferraro
            Assignee: Paul Ferraro
             Fix For: 9.0.0.CR1


Typically, when we use an Infinispan cache listener, we only need it to be invoked on one node in the cluster.  Infinispan 6/7 have added several mechanisms to filter when listeners are invoked.  For example, we can leverage @Listener(primaryOnly = true) in many places.

--
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

From issues at jboss.org  Fri Mar 28 12:02:13 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 28 Mar 2014 12:02:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3124) JXM PluggableMBeanServerImpl
 assumes RealmUser principal
In-Reply-To: <JIRA.12535162.1395067666000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12535162.1395067666000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12535162.1395067666000.16455.1396022533435@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-3124?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated WFLY-3124:
------------------------------------------

        Bugzilla Update: Perform
    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1082072

    
> JXM PluggableMBeanServerImpl assumes RealmUser principal
> --------------------------------------------------------
>
>                 Key: WFLY-3124
>                 URL: https://issues.jboss.org/browse/WFLY-3124
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JMX
>    Affects Versions: 8.0.0.Final
>            Reporter: Vojtech Juranek
>            Assignee: Kabir Khan
>
> JXM {{PluggableMBeanServerImpl$LogAction}} assumes that {{RealmUser}} principal is present when Subject is not null. This condition is not always met and results into following exception:
> {noformat}
> Caused by: java.util.NoSuchElementException
>         at java.util.HashMap$HashIterator.nextEntry(HashMap.java:929)
>         at java.util.HashMap$KeyIterator.next(HashMap.java:960)
>         at org.jboss.as.jmx.PluggableMBeanServerImpl$LogAction.getCallerUserId(PluggableMBeanServerImpl.java:1250)
>         at org.jboss.as.jmx.PluggableMBeanServerImpl$LogAction.doLog(PluggableMBeanServerImpl.java:1233)
>         at org.jboss.as.jmx.PluggableMBeanServerImpl.log(PluggableMBeanServerImpl.java:1158)
>         at org.jboss.as.jmx.MBeanServerAuditLogRecordFormatter.log(MBeanServerAuditLogRecordFormatter.java:331)
>         at org.jboss.as.jmx.MBeanServerAuditLogRecordFormatter.queryNames(MBeanServerAuditLogRecordFormatter.java:170)
>         at org.jboss.as.jmx.PluggableMBeanServerImpl.queryNames(PluggableMBeanServerImpl.java:871)
>         at org.infinispan.jmx.JmxUtil.findJmxDomain(JmxUtil.java:127)
> {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

From issues at jboss.org  Fri Mar 28 12:24:13 2014
From: issues at jboss.org (Jozef Hartinger (JIRA))
Date: Fri, 28 Mar 2014 12:24:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3186) Upgrade to Weld 2.2
In-Reply-To: <JIRA.12536376.1395997650000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12536376.1395997650000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12536376.1395997650000.16555.1396023853810@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-3186?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jozef Hartinger updated WFLY-3186:
----------------------------------

    Component/s: CDI / Weld

    
> Upgrade to Weld 2.2
> -------------------
>
>                 Key: WFLY-3186
>                 URL: https://issues.jboss.org/browse/WFLY-3186
>             Project: WildFly
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: CDI / Weld
>            Reporter: Jozef Hartinger
>            Assignee: Jozef Hartinger
>


--
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

From issues at jboss.org  Fri Mar 28 12:26:13 2014
From: issues at jboss.org (Jozef Hartinger (JIRA))
Date: Fri, 28 Mar 2014 12:26:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3158) @Model does not work
In-Reply-To: <JIRA.12535955.1395697803000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12535955.1395697803000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12535955.1395697803000.16563.1396023973198@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-3158?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jozef Hartinger updated WFLY-3158:
----------------------------------

    Issue Type: Feature Request  (was: Bug)
      Assignee: Jozef Hartinger  (was: Stuart Douglas)

    
> @Model does not work
> --------------------
>
>                 Key: WFLY-3158
>                 URL: https://issues.jboss.org/browse/WFLY-3158
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: CDI / Weld, JSF
>    Affects Versions: 8.0.0.Final
>            Reporter: Stefan Dilk
>            Assignee: Jozef Hartinger
>
> hi,
> wildfly not work with @Model annotated beans in JSF.
> @RequestScoped and @Named work.
> in this ticket it is already reported, but closed:
> https://issues.jboss.org/browse/WFLY-2372
> in the related CDI ticket the change is made, so please implement this in the next wildfly update. in glassfish4 the @Model annotation works fine.

--
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

From issues at jboss.org  Fri Mar 28 12:28:13 2014
From: issues at jboss.org (Jozef Hartinger (JIRA))
Date: Fri, 28 Mar 2014 12:28:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3158) @Model does not work
In-Reply-To: <JIRA.12535955.1395697803000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12535955.1395697803000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12535955.1395697803000.16573.1396024093043@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-3158?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12957408#comment-12957408 ] 

Jozef Hartinger commented on WFLY-3158:
---------------------------------------

As WFLY-2372 says, stereotype-annotated classes are not detected in implicit bean archives in CDI 1.1 You can either switch to bean-discovery-mode="annotated" or wait for CDI 1.2 (Weld 2.2)
                
> @Model does not work
> --------------------
>
>                 Key: WFLY-3158
>                 URL: https://issues.jboss.org/browse/WFLY-3158
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: CDI / Weld, JSF
>    Affects Versions: 8.0.0.Final
>            Reporter: Stefan Dilk
>            Assignee: Jozef Hartinger
>
> hi,
> wildfly not work with @Model annotated beans in JSF.
> @RequestScoped and @Named work.
> in this ticket it is already reported, but closed:
> https://issues.jboss.org/browse/WFLY-2372
> in the related CDI ticket the change is made, so please implement this in the next wildfly update. in glassfish4 the @Model annotation works fine.

--
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

From issues at jboss.org  Fri Mar 28 12:30:13 2014
From: issues at jboss.org (Jozef Hartinger (JIRA))
Date: Fri, 28 Mar 2014 12:30:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2689) @Producer method never called
 when producing a bean from a static module
In-Reply-To: <JIRA.12528426.1388061121000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528426.1388061121000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528426.1388061121000.16587.1396024213165@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2689?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jozef Hartinger resolved WFLY-2689.
-----------------------------------

    Fix Version/s: 8.0.0.Final
       Resolution: Done


I believe this was resolved for 8.0.0.Final. Feel free to reopen if I am wrong.
                
> @Producer method never called when producing a bean from a static module
> ------------------------------------------------------------------------
>
>                 Key: WFLY-2689
>                 URL: https://issues.jboss.org/browse/WFLY-2689
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: CDI / Weld
>    Affects Versions: 8.0.0.CR1
>         Environment: WildFly 8.0.0.CR1
>            Reporter: Pedro Igor
>            Assignee: Jozef Hartinger
>             Fix For: 8.0.0.Final
>
>
> I've configured a static module for PicketLink CDI library. This library provides some extensions which are loaded fine, as described by WFLY-1370.
> However, I'm trying to deploy my application which the following producer method:
> {code}
> @Produces
> @PicketLink
> public PartitionManager getPartitionManager() {
>     // produce an instance
> }
> {code}
> Where the @PicketLink annotation is a qualifier that allows my deployment to provide its own instance instead.
> In the PicketLink side, we have a injection point as follows:
> @Inject
> @PicketLink
> private Instance<PartitionManager> partitionManagerInstance;
> Where a call to partitionManagerInstance.isUnsatisfied() always returns true, even if my deployment provides a proper producer method.
> The issue here is that the producer method is never called, despite the use of qualifiers or not.
> FYI, I'm able to listen for events fired by PicketLink during the application startup as follows:
> public void observeIdentityConfigurationEvent(@Observes IdentityConfigurationEvent event) {
>     // observer
> }
> Where IdentityConfigurationEvent is one of the lifecycle events fired by PicketLink during the startup.

--
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

From issues at jboss.org  Fri Mar 28 12:52:12 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 28 Mar 2014 12:52:12 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-101) JMSService.start is doing
	blocking I/O
In-Reply-To: <JIRA.12489128.1365693199000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12489128.1365693199000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12489128.1365693199000.16648.1396025532925@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-101?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated WFLY-101:
-----------------------------------------

        Bugzilla Update: Perform
    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1003913, https://bugzilla.redhat.com/show_bug.cgi?id=1082103  (was: https://bugzilla.redhat.com/show_bug.cgi?id=1003913)

    
> JMSService.start is doing blocking I/O
> --------------------------------------
>
>                 Key: WFLY-101
>                 URL: https://issues.jboss.org/browse/WFLY-101
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JMS
>            Reporter: Jeff Mesnil
>            Assignee: Jeff Mesnil
>             Fix For: 8.0.0.Alpha1
>
>
> flag the start context as asynchronous

--
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

From issues at jboss.org  Fri Mar 28 13:32:13 2014
From: issues at jboss.org (Jesper Pedersen (JIRA))
Date: Fri, 28 Mar 2014 13:32:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBJCA-1159) ConnectionListener leaked if
 TSR throws IllegalStateException
In-Reply-To: <JIRA.12536390.1396002726000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12536390.1396002726000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12536390.1396002726000.16722.1396027933048@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBJCA-1159?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jesper Pedersen updated JBJCA-1159:
-----------------------------------

              Summary: ConnectionListener leaked if TSR throws IllegalStateException  (was: DB Connections leaked if TX is not active after retrieving a connection)
        Fix Version/s: 1.0.25.Final
                       1.1.5.Final
                       1.2.0.Beta1
    Affects Version/s: 1.1.4.Final
                       1.0.24.Final
                           (was: 1.0.19.Final)


There is a TSR.getTransactionKey() check, but that doesn't eliminate a race. So IronJacamar needs to guard against its TSR usage.

In the future, open a forum thread before creating JIRAs. Thanks
                
> ConnectionListener leaked if TSR throws IllegalStateException
> -------------------------------------------------------------
>
>                 Key: JBJCA-1159
>                 URL: https://issues.jboss.org/browse/JBJCA-1159
>             Project: IronJacamar
>          Issue Type: Bug
>          Components: Core
>    Affects Versions: 1.0.24.Final, 1.1.4.Final
>         Environment: AS7 EAP6.1
>            Reporter: gui borland
>            Assignee: Jesper Pedersen
>            Priority: Critical
>             Fix For: 1.0.25.Final, 1.1.5.Final, 1.2.0.Beta1
>
>
> When  a connection is retrieved from the MCP, ironjacamar will register it to ongoing JTA transaction. However, if the ongoing TX is not 'active' anymore the connection is lost. 
> The code of AbstractPool demonstrates the problem. The call to getLock will throw an exception if the current TX is not active anymore and the cl is not returned to the pool.
> This issue can be reproduced on AS7 by using any EJB that requires a tx and does something with a DB connection. Put a breakpoint in the code below after retrieving the connectionlistener, and then wait for the transaction to timeout. Once that's done, continue the thread. The connection is not release (can be seen in JMX)
> We have noticed this problem regularly during our performance tests. 
> {code}
>  ConnectionListener cl = mcp.getConnection(subject, cri);
>       if (trace)
>          log.tracef("Got connection from pool tracked by transaction=%s tx=%s", cl, trackByTransaction);
>       TransactionSynchronizationRegistry tsr = getTransactionSynchronizationRegistry();
>       Lock lock = getLock();
>       try
>       {
>          lock.lockInterruptibly();
>       }
>       catch (InterruptedException ie)
>       {
>          Thread.interrupted();
>          throw new ResourceException(bundle.unableObtainLock(), ie);
>       }
> {code}
> It seems this issue was introduced by changes done for https://issues.jboss.org/browse/JBJCA-572

--
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

From issues at jboss.org  Fri Mar 28 13:37:01 2014
From: issues at jboss.org (Jesper Pedersen (JIRA))
Date: Fri, 28 Mar 2014 13:37:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBJCA-1159) ConnectionListener leaked if
 TSR throws IllegalStateException
In-Reply-To: <JIRA.12536390.1396002726000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12536390.1396002726000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12536390.1396002726000.16754.1396028221882@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBJCA-1159?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jesper Pedersen updated JBJCA-1159:
-----------------------------------

    Priority: Blocker  (was: Critical)

    
> ConnectionListener leaked if TSR throws IllegalStateException
> -------------------------------------------------------------
>
>                 Key: JBJCA-1159
>                 URL: https://issues.jboss.org/browse/JBJCA-1159
>             Project: IronJacamar
>          Issue Type: Bug
>          Components: Core
>    Affects Versions: 1.0.24.Final, 1.1.4.Final
>         Environment: AS7 EAP6.1
>            Reporter: gui borland
>            Assignee: Jesper Pedersen
>            Priority: Blocker
>             Fix For: 1.0.25.Final, 1.1.5.Final, 1.2.0.Beta1
>
>
> When  a connection is retrieved from the MCP, ironjacamar will register it to ongoing JTA transaction. However, if the ongoing TX is not 'active' anymore the connection is lost. 
> The code of AbstractPool demonstrates the problem. The call to getLock will throw an exception if the current TX is not active anymore and the cl is not returned to the pool.
> This issue can be reproduced on AS7 by using any EJB that requires a tx and does something with a DB connection. Put a breakpoint in the code below after retrieving the connectionlistener, and then wait for the transaction to timeout. Once that's done, continue the thread. The connection is not release (can be seen in JMX)
> We have noticed this problem regularly during our performance tests. 
> {code}
>  ConnectionListener cl = mcp.getConnection(subject, cri);
>       if (trace)
>          log.tracef("Got connection from pool tracked by transaction=%s tx=%s", cl, trackByTransaction);
>       TransactionSynchronizationRegistry tsr = getTransactionSynchronizationRegistry();
>       Lock lock = getLock();
>       try
>       {
>          lock.lockInterruptibly();
>       }
>       catch (InterruptedException ie)
>       {
>          Thread.interrupted();
>          throw new ResourceException(bundle.unableObtainLock(), ie);
>       }
> {code}
> It seems this issue was introduced by changes done for https://issues.jboss.org/browse/JBJCA-572

--
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

From issues at jboss.org  Fri Mar 28 17:32:12 2014
From: issues at jboss.org (Paul Ferraro (JIRA))
Date: Fri, 28 Mar 2014 17:32:12 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3136) SRV 7.7.2 non-compliance
In-Reply-To: <JIRA.12535344.1395181848000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12535344.1395181848000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12535344.1395181848000.17065.1396042332940@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-3136?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Paul Ferraro reopened WFLY-3136:
--------------------------------



This fix can be optimized.
                
> SRV 7.7.2 non-compliance
> ------------------------
>
>                 Key: WFLY-3136
>                 URL: https://issues.jboss.org/browse/WFLY-3136
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Clustering
>    Affects Versions: 8.0.0.Final
>            Reporter: Paul Ferraro
>            Assignee: Paul Ferraro
>             Fix For: 8.0.1.Final
>
>
> From SRV 7.7.2: Distributed Environments
> Within an application marked as distributable, all requests that are part of a session must be handled by one JVM at a time.
> Our default configuration for the Infinispan cache used for web sessions uses PESSIMISTIC locking.  However, Infinispan only acquires locks on cache write operations.  This only prevents concurrent writes to a session.  Even with REPEATABLE_READ, 2 threads can read a session at the same time.  We need to make sure both reads and writes to a session use cluster exclusive access, by default at least.

--
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

From issues at jboss.org  Fri Mar 28 17:32:13 2014
From: issues at jboss.org (Paul Ferraro (JIRA))
Date: Fri, 28 Mar 2014 17:32:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3136) SRV 7.7.2 non-compliance
In-Reply-To: <JIRA.12535344.1395181848000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12535344.1395181848000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12535344.1395181848000.17068.1396042333048@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-3136?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Paul Ferraro updated WFLY-3136:
-------------------------------

    Git Pull Request: https://github.com/wildfly/wildfly/pull/6081, https://github.com/wildfly/wildfly/pull/6101  (was: https://github.com/wildfly/wildfly/pull/6081)

    
> SRV 7.7.2 non-compliance
> ------------------------
>
>                 Key: WFLY-3136
>                 URL: https://issues.jboss.org/browse/WFLY-3136
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Clustering
>    Affects Versions: 8.0.0.Final
>            Reporter: Paul Ferraro
>            Assignee: Paul Ferraro
>             Fix For: 8.0.1.Final
>
>
> From SRV 7.7.2: Distributed Environments
> Within an application marked as distributable, all requests that are part of a session must be handled by one JVM at a time.
> Our default configuration for the Infinispan cache used for web sessions uses PESSIMISTIC locking.  However, Infinispan only acquires locks on cache write operations.  This only prevents concurrent writes to a session.  Even with REPEATABLE_READ, 2 threads can read a session at the same time.  We need to make sure both reads and writes to a session use cluster exclusive access, by default at least.

--
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

From issues at jboss.org  Sat Mar 29 05:30:13 2014
From: issues at jboss.org (Stefan Dilk (JIRA))
Date: Sat, 29 Mar 2014 05:30:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3158) @Model does not work
In-Reply-To: <JIRA.12535955.1395697803000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12535955.1395697803000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12535955.1395697803000.17178.1396085413005@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-3158?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12957516#comment-12957516 ] 

Stefan Dilk commented on WFLY-3158:
-----------------------------------

but in glassfish 4 this works.
i mean glassfish uses weld too, so i think it is a bug in wildfly.
please correct me if i go wrong.
                
> @Model does not work
> --------------------
>
>                 Key: WFLY-3158
>                 URL: https://issues.jboss.org/browse/WFLY-3158
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: CDI / Weld, JSF
>    Affects Versions: 8.0.0.Final
>            Reporter: Stefan Dilk
>            Assignee: Jozef Hartinger
>
> hi,
> wildfly not work with @Model annotated beans in JSF.
> @RequestScoped and @Named work.
> in this ticket it is already reported, but closed:
> https://issues.jboss.org/browse/WFLY-2372
> in the related CDI ticket the change is made, so please implement this in the next wildfly update. in glassfish4 the @Model annotation works fine.

--
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

From issues at jboss.org  Sat Mar 29 13:14:12 2014
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Sat, 29 Mar 2014 13:14:12 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3118) <vault> does not have module
	option
In-Reply-To: <JIRA.12535031.1394802647000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12535031.1394802647000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12535031.1394802647000.17246.1396113252972@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-3118?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan closed WFLY-3118.
----------------------------

    Resolution: Done

    
> <vault> does not have module option
> -----------------------------------
>
>                 Key: WFLY-3118
>                 URL: https://issues.jboss.org/browse/WFLY-3118
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Security
>            Reporter: Derek Horton
>            Assignee: Kabir Khan
>
> The <vault> element in standalone/domain.xml takes a 'code' attribute specifying the class to use as the implementation. It does not let you specify a 'module' option like most similar elements have, and instead always loads the class from the org.picketbox module.
> The <vault> element should take a module option too.
> The current workaround is to add the custom vault module as a dependency in the org.picketbox module.
> Additionally, hanging any module.xml can also result in patching conflicts when customers apply future updates.
> Since we have a quite a few customers writing custom vault implementations for various pieces of functionality that it doesn't provide out of the box, we should consider making this type of customer-initiated change patch safe for customers.

--
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

From issues at jboss.org  Sat Mar 29 17:50:12 2014
From: issues at jboss.org (Damon Horrell (JIRA))
Date: Sat, 29 Mar 2014 17:50:12 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-424) drools-camel support for
 session-scoped knowledge session
In-Reply-To: <JIRA.12531542.1391928586000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12531542.1391928586000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12531542.1391928586000.17323.1396129812880@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/DROOLS-424?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12957543#comment-12957543 ] 

Damon Horrell commented on DROOLS-424:
--------------------------------------

If anyone is looking for a server for drools with a session-scoped knowledge session then you can use:

http://anonsvn.jboss.org/repos/tohu/trunk/tohu/tohu-xml/src/main/java/org/tohu/server/

This is part of the Tohu project but there is nothing Tohu-specific about it so it could be easily adapted for other purposes.  It uses the CommandExecutor but currently only supports request/responses in XML format.
                
> drools-camel support for session-scoped knowledge session
> ---------------------------------------------------------
>
>                 Key: DROOLS-424
>                 URL: https://issues.jboss.org/browse/DROOLS-424
>             Project: Drools
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.6.0.Final
>            Reporter: Damon Horrell
>            Assignee: Mark Proctor
>
> The Spring configuration for drools-camel allows creation of either a stateless knowledge session (i.e. effectively request-scoped), or a single stateful knowledge session which is shared by all requests (i.e. effectively application-scoped).   There is no session-scoped option.
> This differs from the earlier drools-execution-server module (version 0.0.4) which was replaced by drools-camel.  drools-execution-server maintained a separate StatefulKnowledgeSession instance per HTTP session.
> Can you please add support for a session-scoped StatefulKnowledgeSession?

--
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

From issues at jboss.org  Sun Mar 30 23:42:13 2014
From: issues at jboss.org (shinzey shinzey (JIRA))
Date: Sun, 30 Mar 2014 23:42:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3189) Error validating
	jboss-ejb3.xml.
In-Reply-To: <JIRA.12536543.1396237263260@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12536543.1396237263260@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12536543.1396237263260.17559.1396237333122@jira02.app.mwc.hst.phx2.redhat.com>

shinzey shinzey created WFLY-3189:
-------------------------------------

             Summary: Error validating jboss-ejb3.xml.
                 Key: WFLY-3189
                 URL: https://issues.jboss.org/browse/WFLY-3189
             Project: WildFly
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: EJB
    Affects Versions: 8.0.0.Final
         Environment: WildFly 8.0.0.Final
            Reporter: shinzey shinzey
            Assignee: David Lloyd


I'm trying to configure code completion for jboss-ejb3.xml with schema, but fail to do that due to the following validation error:
{noformat}
src-resolve: Cannot resolve the name 'javaee:jboss-ejb-beanType' to a(n) 'type definition' component. [33]
src-resolve: Cannot resolve the name 'javaee:jboss-ejb-jarType' to a(n) 'type definition' component. [35]
src-resolve: Cannot resolve the name 'javaee:jboss-enterprise-beansType' to a(n) 'type definition' component. [37]
src-resolve: Cannot resolve the name 'javaee:assembly-descriptor-entry' to a(n) 'element declaration' component. [35]
src-resolve: Cannot resolve the name 'javaee:jboss-assembly-descriptor-bean-entryType' to a(n) 'type definition' component. [39]
{noformat}
The jboss-ejb3.xml is quite simple:
{code:xml}
<?xml version="1.0" encoding="UTF-8"?>
<jboss:ejb-jar version="3.1" impl-version="2.0"
               xmlns="http://java.sun.com/xml/ns/javaee"
               xmlns:jboss="http://www.jboss.com/xml/ns/javaee"
               xmlns:s="urn:security:1.1"
               xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
               xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/ejb-jar_3_1.xsd
                                   http://www.jboss.com/xml/ns/javaee http://www.jboss.org/j2ee/schema/jboss-ejb3-2_0.xsd">
    <assembly-descriptor>
        <s:security>
            <ejb-name>*</ejb-name>
            <s:security-domain>testsd</s:security-domain>
        </s:security>
    </assembly-descriptor>
</jboss:ejb-jar>
{code}

--
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

From issues at jboss.org  Mon Mar 31 00:16:13 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 31 Mar 2014 00:16:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-834) org.jboss.as.cmp dependency
 added only to EJB subdeployments
In-Reply-To: <JIRA.12487745.1363921408000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12487745.1363921408000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12487745.1363921408000.17573.1396239373852@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-834?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12957577#comment-12957577 ] 

RH Bugzilla Integration commented on WFLY-834:
----------------------------------------------

James Livingston <jlivings at redhat.com> changed the Status of [bug 924548|https://bugzilla.redhat.com/show_bug.cgi?id=924548] from NEW to POST
                
> org.jboss.as.cmp dependency added only to EJB subdeployments
> ------------------------------------------------------------
>
>                 Key: WFLY-834
>                 URL: https://issues.jboss.org/browse/WFLY-834
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: EJB
>            Reporter: James Livingston
>            Assignee: jaikiran pai
>
> The CMP code adds a module dependency on org.jboss.as.cmp if there are any CMP beans in it (via the CMP marker).
> If the <ejb-class> refers to a class not in the EJB jar itself, such as in a library jar, this will result in the proxy being created in the EAR classloader and not being able to find JBoss' CmpProxy class.
> The solution is to add the dependency to the top-level deployment so it is available in all sub-deployments, rather than the such the ejb subdeployment.

--
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

From issues at jboss.org  Mon Mar 31 01:50:12 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 31 Mar 2014 01:50:12 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3130) Add a custom RuntimeException
 to add-user utility.
In-Reply-To: <JIRA.12535302.1395159229000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12535302.1395159229000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12535302.1395159229000.17676.1396245012949@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-3130?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12957586#comment-12957586 ] 

RH Bugzilla Integration commented on WFLY-3130:
-----------------------------------------------

Petr Kremensky <pkremens at redhat.com> changed the Status of [bug 1062595|https://bugzilla.redhat.com/show_bug.cgi?id=1062595] from ON_QA to VERIFIED
                
> Add a custom RuntimeException to add-user utility.
> --------------------------------------------------
>
>                 Key: WFLY-3130
>                 URL: https://issues.jboss.org/browse/WFLY-3130
>             Project: WildFly
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 8.0.1.Final
>
>
> The add-user utility uses a RuntimeException to indicate failure in non-interactive mode, this does not look good so should switch it to a custom exception of our own.

--
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

From issues at jboss.org  Mon Mar 31 01:54:12 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 31 Mar 2014 01:54:12 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3133) Misleading error message for
 add-user username requirements.
In-Reply-To: <JIRA.12535314.1395166113000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12535314.1395166113000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12535314.1395166113000.17692.1396245252921@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-3133?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12957588#comment-12957588 ] 

RH Bugzilla Integration commented on WFLY-3133:
-----------------------------------------------

Petr Kremensky <pkremens at redhat.com> changed the Status of [bug 1062611|https://bugzilla.redhat.com/show_bug.cgi?id=1062611] from ON_QA to VERIFIED
                
> Misleading error message for add-user username requirements.
> ------------------------------------------------------------
>
>                 Key: WFLY-3133
>                 URL: https://issues.jboss.org/browse/WFLY-3133
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>    Affects Versions: 8.0.0.Final
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 8.0.1.Final
>
>
> The current error message is: -
> {code}
> JBAS015239: Only alpha/numeric usernames accepted.
> {code}
> However a small set of symbols are allowed.

--
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

From issues at jboss.org  Mon Mar 31 03:02:13 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 31 Mar 2014 03:02:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3125) Update help text for add-user
 to reflect that password is checked against the configured policy.
In-Reply-To: <JIRA.12535263.1395145186000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12535263.1395145186000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12535263.1395145186000.17733.1396249333457@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-3125?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12957596#comment-12957596 ] 

RH Bugzilla Integration commented on WFLY-3125:
-----------------------------------------------

Petr Kremensky <pkremens at redhat.com> changed the Status of [bug 1063888|https://bugzilla.redhat.com/show_bug.cgi?id=1063888] from ON_QA to VERIFIED
                
> Update help text for add-user to reflect that password is checked against the configured policy.
> ------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-3125
>                 URL: https://issues.jboss.org/browse/WFLY-3125
>             Project: WildFly
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 8.0.1.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

From issues at jboss.org  Mon Mar 31 03:08:13 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 31 Mar 2014 03:08:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2950) jboss-cli using
 https-remoting: command not executed if certificate is unrecognised
In-Reply-To: <JIRA.12532472.1392721164000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12532472.1392721164000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12532472.1392721164000.17742.1396249693018@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2950?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12957598#comment-12957598 ] 

RH Bugzilla Integration commented on WFLY-2950:
-----------------------------------------------

Petr Kremensky <pkremens at redhat.com> changed the Status of [bug 1026418|https://bugzilla.redhat.com/show_bug.cgi?id=1026418] from ON_QA to VERIFIED
                
> jboss-cli using https-remoting: command not executed if certificate is unrecognised
> -----------------------------------------------------------------------------------
>
>                 Key: WFLY-2950
>                 URL: https://issues.jboss.org/browse/WFLY-2950
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: CLI, Domain Management
>    Affects Versions: 8.0.0.Final
>         Environment: Windows 7 Pro
>            Reporter: Darren Jones
>            Assignee: Darran Lofthouse
>              Labels: cli, shutdown
>             Fix For: 8.0.1.Final
>
>
> When using the https management interface from jboss-cli, commands passed with a command line option (such as --command=:shutdown) are not executed if the server certificate is unrecognised - even if accepting the certificate [T]emporarily or [P]ermenantly.
> It appears to be due to the CommandContextImpl.handleSSLFailure() method, which calls error("Unable to connect..."). The error() method sets the exitCode to 1. So, when CliLauncher.processCommands() subsequently runs, it sees that the cmdCtx.exitCode is 1 and ignores any commands.
> I guess the handleSSLFailure needs to reset the exitCode to 0 if the user chooses [T] or [P].

--
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

From issues at jboss.org  Mon Mar 31 03:08:13 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 31 Mar 2014 03:08:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2538) Certificate acceptance
 causing command entered on starting the CLI to be skipped.
In-Reply-To: <JIRA.12525580.1384872293000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12525580.1384872293000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12525580.1384872293000.17746.1396249693290@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2538?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12957599#comment-12957599 ] 

RH Bugzilla Integration commented on WFLY-2538:
-----------------------------------------------

Petr Kremensky <pkremens at redhat.com> changed the Status of [bug 1026418|https://bugzilla.redhat.com/show_bug.cgi?id=1026418] from ON_QA to VERIFIED
                
> Certificate acceptance causing command entered on starting the CLI to be skipped.
> ---------------------------------------------------------------------------------
>
>                 Key: WFLY-2538
>                 URL: https://issues.jboss.org/browse/WFLY-2538
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: CLI
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 8.0.0.CR1
>
>
> e.g.
> {noformat}
> ./jboss-cli.sh -c shutdown
> Accept certificate? [N]o, [T]emporarily, [P]ermenantly : T
> {noformat}
> The shutdown command is not executed.

--
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

From issues at jboss.org  Mon Mar 31 03:22:13 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 31 Mar 2014 03:22:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3108) Can't promote --backup slave
 HC to master and reload without moving domain.cached-remote.xml
In-Reply-To: <JIRA.12534873.1394711186000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534873.1394711186000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534873.1394711186000.17770.1396250533181@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-3108?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated WFLY-3108:
------------------------------------------

        Bugzilla Update: Perform
    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1076066, https://bugzilla.redhat.com/show_bug.cgi?id=1082478  (was: https://bugzilla.redhat.com/show_bug.cgi?id=1076066)

    
> Can't promote --backup slave HC to master and reload without moving domain.cached-remote.xml
> --------------------------------------------------------------------------------------------
>
>                 Key: WFLY-3108
>                 URL: https://issues.jboss.org/browse/WFLY-3108
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>    Affects Versions: 8.0.0.Final
>            Reporter: Brian Stansberry
>            Assignee: Brian Stansberry
>             Fix For: 8.0.1.Final
>
>
> The prescribed mechanism for converting a slave HC to master is to:
> 1) Start the slave with --backup so a local copy of the domain config is maintained (in file domain.cached-remote.xml).
> 2) Stop the existing master.
> 3) Use the cli to connect to the slave and
> /host=<slavename>:write-local-domain-controller
> 4) Then, in the CLI
> reload --host=<slavename>
> Problem is this fails because the HC expects to have a domain config file "domain.xml".
> 2014-03-13 09:54:04,829 ERROR [org.jboss.as.host.controller] (Controller Boot Thread) JBAS010932: Caught exception during boot: org.jboss.as.controller.persistence.ConfigurationPersistenceException: JBAS014676: Failed to parse configuration
> 	at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:112) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> 	at org.jboss.as.host.controller.DomainModelControllerService.boot(DomainModelControllerService.java:514) [wildfly-host-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> 	at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:256) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> 	at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_45]
> Caused by: java.io.FileNotFoundException: /Users/bstansberry/tmp/WF801/slave/domain/configuration/domain.xml (No such file or directory)
> 	at java.io.FileInputStream.open(Native Method) [rt.jar:1.7.0_45]
> 	at java.io.FileInputStream.<init>(FileInputStream.java:146) [rt.jar:1.7.0_45]
> 	at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:100) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> 	... 3 more
> Or, MUCH WORSE, there happens to be a random domain.xml in the filesystem, which has content that is out of sync with the correct domain config. This domain.xml config will be used.

--
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

From issues at jboss.org  Mon Mar 31 03:40:12 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 31 Mar 2014 03:40:12 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3108) Can't promote --backup slave
 HC to master and reload without moving domain.cached-remote.xml
In-Reply-To: <JIRA.12534873.1394711186000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534873.1394711186000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534873.1394711186000.17789.1396251612980@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-3108?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12957609#comment-12957609 ] 

RH Bugzilla Integration commented on WFLY-3108:
-----------------------------------------------

Osamu Nagano <onagano at redhat.com> changed the Status of [bug 1082478|https://bugzilla.redhat.com/show_bug.cgi?id=1082478] from NEW to POST
                
> Can't promote --backup slave HC to master and reload without moving domain.cached-remote.xml
> --------------------------------------------------------------------------------------------
>
>                 Key: WFLY-3108
>                 URL: https://issues.jboss.org/browse/WFLY-3108
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>    Affects Versions: 8.0.0.Final
>            Reporter: Brian Stansberry
>            Assignee: Brian Stansberry
>             Fix For: 8.0.1.Final
>
>
> The prescribed mechanism for converting a slave HC to master is to:
> 1) Start the slave with --backup so a local copy of the domain config is maintained (in file domain.cached-remote.xml).
> 2) Stop the existing master.
> 3) Use the cli to connect to the slave and
> /host=<slavename>:write-local-domain-controller
> 4) Then, in the CLI
> reload --host=<slavename>
> Problem is this fails because the HC expects to have a domain config file "domain.xml".
> 2014-03-13 09:54:04,829 ERROR [org.jboss.as.host.controller] (Controller Boot Thread) JBAS010932: Caught exception during boot: org.jboss.as.controller.persistence.ConfigurationPersistenceException: JBAS014676: Failed to parse configuration
> 	at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:112) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> 	at org.jboss.as.host.controller.DomainModelControllerService.boot(DomainModelControllerService.java:514) [wildfly-host-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> 	at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:256) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> 	at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_45]
> Caused by: java.io.FileNotFoundException: /Users/bstansberry/tmp/WF801/slave/domain/configuration/domain.xml (No such file or directory)
> 	at java.io.FileInputStream.open(Native Method) [rt.jar:1.7.0_45]
> 	at java.io.FileInputStream.<init>(FileInputStream.java:146) [rt.jar:1.7.0_45]
> 	at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:100) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> 	... 3 more
> Or, MUCH WORSE, there happens to be a random domain.xml in the filesystem, which has content that is out of sync with the correct domain config. This domain.xml config will be used.

--
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

From issues at jboss.org  Mon Mar 31 04:54:13 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 31 Mar 2014 04:54:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2214) Allow additional environment
 properties to be set for outbound LDAP connections used by security realms.
In-Reply-To: <JIRA.12502155.1380834418000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502155.1380834418000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502155.1380834418000.17907.1396256053390@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2214?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12957627#comment-12957627 ] 

RH Bugzilla Integration commented on WFLY-2214:
-----------------------------------------------

Ondrej Lukas <olukas at redhat.com> changed the Status of [bug 1015303|https://bugzilla.redhat.com/show_bug.cgi?id=1015303] from ON_QA to VERIFIED
                
> Allow additional environment properties to be set for outbound LDAP connections used by security realms.
> --------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2214
>                 URL: https://issues.jboss.org/browse/WFLY-2214
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Derek Horton
>            Assignee: Darran Lofthouse
>             Fix For: 8.0.0.CR1
>
>
> LDAP security realm needs to have configurable timeouts.
> The default LDAP connection timeout appears to be 2 minutes.  If the ldap server is down, it could take 2 minutes for the connection to timeout.  This can cause unneeded delay if you have configured multiple ldap servers for  failover / redundancy.
> The following hack appears to work:
> +++ domain-management/src/main/java/org/jboss/as/domain/management/connections/ldap/LdapConnectionManagerService.java
> @@ -132,6 +132,7 @@ public class LdapConnectionManagerService implements Service<LdapConnectionManag
>          result.put(Context.INITIAL_CONTEXT_FACTORY,initialContextFactory);
>          String url = config.require(URL).asString();
>          result.put(Context.PROVIDER_URL,url);
> +        result.put("com.sun.jndi.ldap.connect.timeout", "500");
>          return result;
>      }

--
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

From issues at jboss.org  Mon Mar 31 05:20:13 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 31 Mar 2014 05:20:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (SECURITY-805) Overload
 SecurityVaultFactory.get() to be able to specify the classloader
In-Reply-To: <JIRA.12535004.1394795116000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12535004.1394795116000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12535004.1394795116000.17963.1396257613138@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/SECURITY-805?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12957637#comment-12957637 ] 

RH Bugzilla Integration commented on SECURITY-805:
--------------------------------------------------

Pavel Jelinek <pjelinek at redhat.com> changed the Status of [bug 1079930|https://bugzilla.redhat.com/show_bug.cgi?id=1079930] from ON_QA to VERIFIED
                
> Overload SecurityVaultFactory.get() to be able to specify the classloader
> -------------------------------------------------------------------------
>
>                 Key: SECURITY-805
>                 URL: https://issues.jboss.org/browse/SECURITY-805
>             Project: PicketBox 
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>            Reporter: Kabir Khan
>            Assignee: Kabir Khan
>             Fix For: PicketBox_4_0_21.Beta2, PicketBox_4_0_19.SP5
>
>         Attachments: SECURITY-805-2.diff, SECURITY-805.diff
>
>
> To work better with modular class loading in WF

--
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

From issues at jboss.org  Mon Mar 31 05:56:13 2014
From: issues at jboss.org (=?UTF-8?Q?Petr_=C5=A0irok=C3=BD_=28JIRA=29?=)
Date: Mon, 31 Mar 2014 05:56:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-459) 5.6.x: update version to
 5.6.1-SNAPSHOT as 5.6.0.Final is already out
In-Reply-To: <JIRA.12536587.1396259748392@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12536587.1396259748392@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12536587.1396259748392.18071.1396259773348@jira02.app.mwc.hst.phx2.redhat.com>

Petr ?irok? created DROOLS-459:
----------------------------------

             Summary: 5.6.x: update version to 5.6.1-SNAPSHOT as 5.6.0.Final is already out
                 Key: DROOLS-459
                 URL: https://issues.jboss.org/browse/DROOLS-459
             Project: Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
            Reporter: Petr ?irok?
            Assignee: Michael Biarnes Kiefer


The version in 5.6.x branch is still 5.6.0-SNAPSHOT, even though the 5.6.0.Final has been already released. Please update the version to 5.6.1-SNAPSHOT.

Similarly with jBPM, the version should be updated to 5.5.1-SNAPSHOT.

--
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


From issues at jboss.org  Mon Mar 31 06:12:12 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 31 Mar 2014 06:12:12 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-101) JMSService.start is doing
	blocking I/O
In-Reply-To: <JIRA.12489128.1365693199000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12489128.1365693199000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12489128.1365693199000.18080.1396260732952@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-101?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12957660#comment-12957660 ] 

RH Bugzilla Integration commented on WFLY-101:
----------------------------------------------

Pavel Jelinek <pjelinek at redhat.com> changed the Status of [bug 1082103|https://bugzilla.redhat.com/show_bug.cgi?id=1082103] from NEW to POST
                
> JMSService.start is doing blocking I/O
> --------------------------------------
>
>                 Key: WFLY-101
>                 URL: https://issues.jboss.org/browse/WFLY-101
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JMS
>            Reporter: Jeff Mesnil
>            Assignee: Jeff Mesnil
>             Fix For: 8.0.0.Alpha1
>
>
> flag the start context as asynchronous

--
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

From issues at jboss.org  Mon Mar 31 07:20:12 2014
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Mon, 31 Mar 2014 07:20:12 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3190) Make it possible to use
 custom vault with CLI
In-Reply-To: <JIRA.12536591.1396264771932@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12536591.1396264771932@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12536591.1396264771932.18203.1396264812885@jira02.app.mwc.hst.phx2.redhat.com>

Kabir Khan created WFLY-3190:
--------------------------------

             Summary: Make it possible to use custom vault with CLI
                 Key: WFLY-3190
                 URL: https://issues.jboss.org/browse/WFLY-3190
             Project: WildFly
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: CLI
            Reporter: Kabir Khan
            Assignee: Kabir Khan
             Fix For: 9.0.0.CR1




--
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

From issues at jboss.org  Mon Mar 31 08:40:13 2014
From: issues at jboss.org (Scott Marlow (JIRA))
Date: Mon, 31 Mar 2014 08:40:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2881)
 org.jboss.as.ejb3.timer.schedule.CalendarBasedTimeoutTestCase#testCalendarBasedTimeout
In-Reply-To: <JIRA.12531524.1391864503000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12531524.1391864503000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12531524.1391864503000.18712.1396269613101@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2881?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Scott Marlow reopened WFLY-2881:
--------------------------------



reopening to go with the pull request https://github.com/wildfly/wildfly/pull/6098 against WFLY-2881.  
                
> org.jboss.as.ejb3.timer.schedule.CalendarBasedTimeoutTestCase#testCalendarBasedTimeout
> --------------------------------------------------------------------------------------
>
>                 Key: WFLY-2881
>                 URL: https://issues.jboss.org/browse/WFLY-2881
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: EJB
>    Affects Versions: 8.0.0.Final
>            Reporter: Frank Langelage
>            Assignee: Eduardo Martins
>             Fix For: 8.0.1.Final
>
>         Attachments: org.jboss.as.ejb3.timer.schedule.CalendarBasedTimeoutTestCase.txt, TEST-org.jboss.as.ejb3.timer.schedule.CalendarBasedTimeoutTestCase.xml
>
>
> Running build with smoke tests on current github sources I get failure in this test case.
> HOUR_OF_DAY is not 0 as expected but 1.
> I changed the Assert in the test case to print out firstTimeout.toString() instead of only timeZoneDisplayName.
> See attached files for more.

--
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

From issues at jboss.org  Mon Mar 31 08:52:13 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 31 Mar 2014 08:52:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2303) mod_cluster XSD is missing
 property and worker-timeout definitions
In-Reply-To: <JIRA.12503065.1381830758000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12503065.1381830758000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12503065.1381830758000.18837.1396270333229@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2303?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12957734#comment-12957734 ] 

RH Bugzilla Integration commented on WFLY-2303:
-----------------------------------------------

Michal Babacek <mbabacek at redhat.com> changed the Status of [bug 1020142|https://bugzilla.redhat.com/show_bug.cgi?id=1020142] from ON_QA to VERIFIED
                
> mod_cluster XSD is missing property and worker-timeout definitions
> ------------------------------------------------------------------
>
>                 Key: WFLY-2303
>                 URL: https://issues.jboss.org/browse/WFLY-2303
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Clustering
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Radoslav Husar
>            Assignee: Radoslav Husar
>             Fix For: 8.0.0.CR1
>
>
> * worker-timeout
> * property
> are missing.
> Also missing in 7.x

--
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

From issues at jboss.org  Mon Mar 31 08:58:13 2014
From: issues at jboss.org (Jay Kumar SenSharma (JIRA))
Date: Mon, 31 Mar 2014 08:58:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3191) Console uses hardcoded
 hornetq-server name as "default" causes issue while moniroting JMS metrics
In-Reply-To: <JIRA.12536602.1396270659147@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12536602.1396270659147@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12536602.1396270659147.18868.1396270693306@jira02.app.mwc.hst.phx2.redhat.com>

Jay Kumar SenSharma created WFLY-3191:
-----------------------------------------

             Summary: Console uses hardcoded hornetq-server name as "default"  causes issue while moniroting JMS metrics
                 Key: WFLY-3191
                 URL: https://issues.jboss.org/browse/WFLY-3191
             Project: WildFly
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Web Console
    Affects Versions: 8.0.1.Final
         Environment: All
            Reporter: Jay Kumar SenSharma
            Assignee: Heiko Braun


Looks like the API [1] is using hardcoded hornetQ server name as "default" inside the "QueueMetrics.java" as following:

{code}
   final HelpSystem.AddressCallback addressCallback = new HelpSystem.AddressCallback() {
            @Override
            public ModelNode getAddress() {
                ModelNode address = new ModelNode();
                address.get(ModelDescriptionConstants.ADDRESS).set(RuntimeBaseAddress.get());
                address.get(ModelDescriptionConstants.ADDRESS).add("subsystem", "messaging");
                address.get(ModelDescriptionConstants.ADDRESS).add("hornetq-server", "default");
                address.get(ModelDescriptionConstants.ADDRESS).add("jms-queue", "*");
                return address;
            }
        };
{code}

- Above is causing issue if someone alters the "Hornetq-server" name to something else. In that case the Console will not be able to display the QueueMetrics for any JMS Queue or Topic.

- See attached Screenshot with the When the HornetQ server name was changed to "testing"

{code}
        <subsystem xmlns="urn:jboss:domain:messaging:2.0">
            <hornetq-server name="testing">
             .
             .
            </hornetq-server>
        </subsystem>
{code}


[1] https://github.com/hal/core/blob/master/gui/src/main/java/org/jboss/as/console/client/shared/runtime/jms/QueueMetrics.java


--
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

From issues at jboss.org  Mon Mar 31 09:32:13 2014
From: issues at jboss.org (Emmanuel Hugonnet (JIRA))
Date: Mon, 31 Mar 2014 09:32:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3192)
 AroundInvokeAnnotationParsingProcessor should fail when more methods with
 @AroundInvoke annotation are found in the class
In-Reply-To: <JIRA.12536611.1396272723714@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12536611.1396272723714@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12536611.1396272723714.19082.1396272733106@jira02.app.mwc.hst.phx2.redhat.com>

Emmanuel Hugonnet created WFLY-3192:
---------------------------------------

             Summary: AroundInvokeAnnotationParsingProcessor should fail when more methods with @AroundInvoke annotation are found in the class
                 Key: WFLY-3192
                 URL: https://issues.jboss.org/browse/WFLY-3192
             Project: WildFly
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: EE
    Affects Versions: 8.0.0.Final
            Reporter: Emmanuel Hugonnet
            Assignee: Emmanuel Hugonnet




AroundInvokeAnnotationParsingProcessor should fail when more methods with @AroundInvoke annotation is found in the class.
The specification says:

A class must not declare more than one AroundInvoke method.

The JBoss AS allows more such methods and then it chooses one of them which is used as the interceptor.

It becomes even more important to check the interceptor validity now with the new feature introduced by AS7-5897 (server side non-EE interceptors for EE invocations).



--
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

From issues at jboss.org  Mon Mar 31 09:34:14 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 31 Mar 2014 09:34:14 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3192)
 AroundInvokeAnnotationParsingProcessor should fail when more methods with
 @AroundInvoke annotation are found in the class
In-Reply-To: <JIRA.12536611.1396272723000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12536611.1396272723000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12536611.1396272723000.19088.1396272854272@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-3192?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated WFLY-3192:
------------------------------------------

    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=901324

    
> AroundInvokeAnnotationParsingProcessor should fail when more methods with @AroundInvoke annotation are found in the class
> -------------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-3192
>                 URL: https://issues.jboss.org/browse/WFLY-3192
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: EE
>    Affects Versions: 8.0.0.Final
>            Reporter: Emmanuel Hugonnet
>            Assignee: Emmanuel Hugonnet
>
> AroundInvokeAnnotationParsingProcessor should fail when more methods with @AroundInvoke annotation is found in the class.
> The specification says:
> A class must not declare more than one AroundInvoke method.
> The JBoss AS allows more such methods and then it chooses one of them which is used as the interceptor.
> It becomes even more important to check the interceptor validity now with the new feature introduced by AS7-5897 (server side non-EE interceptors for EE invocations).

--
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

From issues at jboss.org  Mon Mar 31 09:34:15 2014
From: issues at jboss.org (Jeff Mesnil (JIRA))
Date: Mon, 31 Mar 2014 09:34:15 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3193) upgrade Generic JMS RA to
	1.0.4.Final
In-Reply-To: <JIRA.12536613.1396272835973@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12536613.1396272835973@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12536613.1396272835973.19113.1396272855442@jira02.app.mwc.hst.phx2.redhat.com>

Jeff Mesnil created WFLY-3193:
---------------------------------

             Summary: upgrade Generic JMS RA to 1.0.4.Final
                 Key: WFLY-3193
                 URL: https://issues.jboss.org/browse/WFLY-3193
             Project: WildFly
          Issue Type: Component  Upgrade
      Security Level: Public (Everyone can see)
          Components: JCA, JMS
    Affects Versions: 8.0.0.Final
            Reporter: Jeff Mesnil
            Assignee: Jeff Mesnil
             Fix For: 8.0.1.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

From issues at jboss.org  Mon Mar 31 09:40:13 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 31 Mar 2014 09:40:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3193) upgrade Generic JMS RA to
	1.0.4.Final
In-Reply-To: <JIRA.12536613.1396272835000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12536613.1396272835000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12536613.1396272835000.19141.1396273213740@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-3193?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated WFLY-3193:
------------------------------------------

        Bugzilla Update: Perform
    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1082617

    
> upgrade Generic JMS RA to 1.0.4.Final
> -------------------------------------
>
>                 Key: WFLY-3193
>                 URL: https://issues.jboss.org/browse/WFLY-3193
>             Project: WildFly
>          Issue Type: Component  Upgrade
>      Security Level: Public(Everyone can see) 
>          Components: JCA, JMS
>    Affects Versions: 8.0.0.Final
>            Reporter: Jeff Mesnil
>            Assignee: Jeff Mesnil
>             Fix For: 8.0.1.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

From issues at jboss.org  Mon Mar 31 10:02:15 2014
From: issues at jboss.org (Wolf-Dieter Fink (JIRA))
Date: Mon, 31 Mar 2014 10:02:15 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3194) ApplicationClient container
 can not use a declarative method to activate EJBClientInterceptors
In-Reply-To: <JIRA.12536616.1396274455967@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12536616.1396274455967@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12536616.1396274455967.19298.1396274535465@jira02.app.mwc.hst.phx2.redhat.com>

Wolf-Dieter Fink created WFLY-3194:
--------------------------------------

             Summary: ApplicationClient container can not use a declarative method to activate EJBClientInterceptors
                 Key: WFLY-3194
                 URL: https://issues.jboss.org/browse/WFLY-3194
             Project: WildFly
          Issue Type: Bug
      Security Level: Public (Everyone can see)
         Environment: appclient
            Reporter: Wolf-Dieter Fink


With the java services approach it is possible to add a client side interceptor by adding the services file META-INF/services/org.jboss.ejb.client.EJBClientInterceptor to activate the interceptor if the class is accessable.
The file must be added to the client.jar in case of a simple standalone client.
And to the ejb.jar if the interceptor is used inside a server application.

For the appclient I expect that add this file to 
  EAR/client.jar/META-INF/services
will do the same.
Nevertheless adding the file to ear/META_INF ear/ejb.jar/META-INF do not woth either.
Also adding the class to the client.jar, as ear module or as server module with dependency did not work.

All theses Interceptors can be used if the client Main method add this with the JBoss API.

A working example can be found here 
  https://github.com/wfink/jboss-eap-quickstarts/tree/application-client/app-client
For the example with the services approach try
  https://github.com/wfink/jboss-eap-quickstarts/tree/application-client-withServices/app-client

--
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

From issues at jboss.org  Mon Mar 31 10:02:16 2014
From: issues at jboss.org (Wolf-Dieter Fink (JIRA))
Date: Mon, 31 Mar 2014 10:02:16 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3194) ApplicationClient container
 can not use a declarative method to activate EJBClientInterceptors
In-Reply-To: <JIRA.12536616.1396274455000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12536616.1396274455000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12536616.1396274455000.19310.1396274536034@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-3194?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Wolf-Dieter Fink updated WFLY-3194:
-----------------------------------

    Component/s: Application Client

    
> ApplicationClient container can not use a declarative method to activate EJBClientInterceptors
> ----------------------------------------------------------------------------------------------
>
>                 Key: WFLY-3194
>                 URL: https://issues.jboss.org/browse/WFLY-3194
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Application Client
>         Environment: appclient
>            Reporter: Wolf-Dieter Fink
>              Labels: application-scoped, ejb
>
> With the java services approach it is possible to add a client side interceptor by adding the services file META-INF/services/org.jboss.ejb.client.EJBClientInterceptor to activate the interceptor if the class is accessable.
> The file must be added to the client.jar in case of a simple standalone client.
> And to the ejb.jar if the interceptor is used inside a server application.
> For the appclient I expect that add this file to 
>   EAR/client.jar/META-INF/services
> will do the same.
> Nevertheless adding the file to ear/META_INF ear/ejb.jar/META-INF do not woth either.
> Also adding the class to the client.jar, as ear module or as server module with dependency did not work.
> All theses Interceptors can be used if the client Main method add this with the JBoss API.
> A working example can be found here 
>   https://github.com/wfink/jboss-eap-quickstarts/tree/application-client/app-client
> For the example with the services approach try
>   https://github.com/wfink/jboss-eap-quickstarts/tree/application-client-withServices/app-client

--
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

From issues at jboss.org  Mon Mar 31 10:02:16 2014
From: issues at jboss.org (Wolf-Dieter Fink (JIRA))
Date: Mon, 31 Mar 2014 10:02:16 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3194) ApplicationClient container
 can not use a declarative method to activate EJBClientInterceptors
In-Reply-To: <JIRA.12536616.1396274455000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12536616.1396274455000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12536616.1396274455000.19313.1396274536183@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-3194?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Wolf-Dieter Fink updated WFLY-3194:
-----------------------------------

    Labels: ejb  (was: application-scoped ejb)

    
> ApplicationClient container can not use a declarative method to activate EJBClientInterceptors
> ----------------------------------------------------------------------------------------------
>
>                 Key: WFLY-3194
>                 URL: https://issues.jboss.org/browse/WFLY-3194
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Application Client
>         Environment: appclient
>            Reporter: Wolf-Dieter Fink
>              Labels: ejb
>
> With the java services approach it is possible to add a client side interceptor by adding the services file META-INF/services/org.jboss.ejb.client.EJBClientInterceptor to activate the interceptor if the class is accessable.
> The file must be added to the client.jar in case of a simple standalone client.
> And to the ejb.jar if the interceptor is used inside a server application.
> For the appclient I expect that add this file to 
>   EAR/client.jar/META-INF/services
> will do the same.
> Nevertheless adding the file to ear/META_INF ear/ejb.jar/META-INF do not woth either.
> Also adding the class to the client.jar, as ear module or as server module with dependency did not work.
> All theses Interceptors can be used if the client Main method add this with the JBoss API.
> A working example can be found here 
>   https://github.com/wfink/jboss-eap-quickstarts/tree/application-client/app-client
> For the example with the services approach try
>   https://github.com/wfink/jboss-eap-quickstarts/tree/application-client-withServices/app-client

--
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

From issues at jboss.org  Mon Mar 31 10:04:12 2014
From: issues at jboss.org (Wolf-Dieter Fink (JIRA))
Date: Mon, 31 Mar 2014 10:04:12 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3194) ApplicationClient container
 can not use a declarative method to activate EJBClientInterceptors
In-Reply-To: <JIRA.12536616.1396274455000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12536616.1396274455000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12536616.1396274455000.19321.1396274652981@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-3194?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Wolf-Dieter Fink updated WFLY-3194:
-----------------------------------

    Affects Version/s: 8.0.0.Final

    
> ApplicationClient container can not use a declarative method to activate EJBClientInterceptors
> ----------------------------------------------------------------------------------------------
>
>                 Key: WFLY-3194
>                 URL: https://issues.jboss.org/browse/WFLY-3194
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Application Client
>    Affects Versions: 8.0.0.Final
>         Environment: appclient
>            Reporter: Wolf-Dieter Fink
>              Labels: ejb
>
> With the java services approach it is possible to add a client side interceptor by adding the services file META-INF/services/org.jboss.ejb.client.EJBClientInterceptor to activate the interceptor if the class is accessable.
> The file must be added to the client.jar in case of a simple standalone client.
> And to the ejb.jar if the interceptor is used inside a server application.
> For the appclient I expect that add this file to 
>   EAR/client.jar/META-INF/services
> will do the same.
> Nevertheless adding the file to ear/META_INF ear/ejb.jar/META-INF do not woth either.
> Also adding the class to the client.jar, as ear module or as server module with dependency did not work.
> All theses Interceptors can be used if the client Main method add this with the JBoss API.
> A working example can be found here 
>   https://github.com/wfink/jboss-eap-quickstarts/tree/application-client/app-client
> For the example with the services approach try
>   https://github.com/wfink/jboss-eap-quickstarts/tree/application-client-withServices/app-client

--
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

From issues at jboss.org  Mon Mar 31 10:04:13 2014
From: issues at jboss.org (Wolf-Dieter Fink (JIRA))
Date: Mon, 31 Mar 2014 10:04:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3194) ApplicationClient container
 can not use a declarative method to activate EJBClientInterceptors
In-Reply-To: <JIRA.12536616.1396274455000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12536616.1396274455000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12536616.1396274455000.19326.1396274653178@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-3194?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Wolf-Dieter Fink reassigned WFLY-3194:
--------------------------------------

    Assignee: Stuart Douglas

    
> ApplicationClient container can not use a declarative method to activate EJBClientInterceptors
> ----------------------------------------------------------------------------------------------
>
>                 Key: WFLY-3194
>                 URL: https://issues.jboss.org/browse/WFLY-3194
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Application Client
>    Affects Versions: 8.0.0.Final
>         Environment: appclient
>            Reporter: Wolf-Dieter Fink
>            Assignee: Stuart Douglas
>              Labels: ejb
>
> With the java services approach it is possible to add a client side interceptor by adding the services file META-INF/services/org.jboss.ejb.client.EJBClientInterceptor to activate the interceptor if the class is accessable.
> The file must be added to the client.jar in case of a simple standalone client.
> And to the ejb.jar if the interceptor is used inside a server application.
> For the appclient I expect that add this file to 
>   EAR/client.jar/META-INF/services
> will do the same.
> Nevertheless adding the file to ear/META_INF ear/ejb.jar/META-INF do not woth either.
> Also adding the class to the client.jar, as ear module or as server module with dependency did not work.
> All theses Interceptors can be used if the client Main method add this with the JBoss API.
> A working example can be found here 
>   https://github.com/wfink/jboss-eap-quickstarts/tree/application-client/app-client
> For the example with the services approach try
>   https://github.com/wfink/jboss-eap-quickstarts/tree/application-client-withServices/app-client

--
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

From issues at jboss.org  Mon Mar 31 10:42:13 2014
From: issues at jboss.org (Jesper Pedersen (JIRA))
Date: Mon, 31 Mar 2014 10:42:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBJCA-1159) ConnectionListener leaked if
 TSR throws IllegalStateException
In-Reply-To: <JIRA.12536390.1396002726000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12536390.1396002726000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12536390.1396002726000.19446.1396276933336@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBJCA-1159?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jesper Pedersen resolved JBJCA-1159.
------------------------------------

    Resolution: Done

    
> ConnectionListener leaked if TSR throws IllegalStateException
> -------------------------------------------------------------
>
>                 Key: JBJCA-1159
>                 URL: https://issues.jboss.org/browse/JBJCA-1159
>             Project: IronJacamar
>          Issue Type: Bug
>          Components: Core
>    Affects Versions: 1.0.24.Final, 1.1.4.Final
>         Environment: AS7 EAP6.1
>            Reporter: gui borland
>            Assignee: Jesper Pedersen
>            Priority: Blocker
>             Fix For: 1.0.25.Final, 1.1.5.Final, 1.2.0.Beta1
>
>
> When  a connection is retrieved from the MCP, ironjacamar will register it to ongoing JTA transaction. However, if the ongoing TX is not 'active' anymore the connection is lost. 
> The code of AbstractPool demonstrates the problem. The call to getLock will throw an exception if the current TX is not active anymore and the cl is not returned to the pool.
> This issue can be reproduced on AS7 by using any EJB that requires a tx and does something with a DB connection. Put a breakpoint in the code below after retrieving the connectionlistener, and then wait for the transaction to timeout. Once that's done, continue the thread. The connection is not release (can be seen in JMX)
> We have noticed this problem regularly during our performance tests. 
> {code}
>  ConnectionListener cl = mcp.getConnection(subject, cri);
>       if (trace)
>          log.tracef("Got connection from pool tracked by transaction=%s tx=%s", cl, trackByTransaction);
>       TransactionSynchronizationRegistry tsr = getTransactionSynchronizationRegistry();
>       Lock lock = getLock();
>       try
>       {
>          lock.lockInterruptibly();
>       }
>       catch (InterruptedException ie)
>       {
>          Thread.interrupted();
>          throw new ResourceException(bundle.unableObtainLock(), ie);
>       }
> {code}
> It seems this issue was introduced by changes done for https://issues.jboss.org/browse/JBJCA-572

--
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

From issues at jboss.org  Mon Mar 31 10:44:14 2014
From: issues at jboss.org (David Lloyd (JIRA))
Date: Mon, 31 Mar 2014 10:44:14 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3195) VFS root creation is wrong on
	Windows
In-Reply-To: <JIRA.12536630.1396277009146@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12536630.1396277009146@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12536630.1396277009146.19472.1396277054583@jira02.app.mwc.hst.phx2.redhat.com>

David Lloyd created WFLY-3195:
---------------------------------

             Summary: VFS root creation is wrong on Windows
                 Key: WFLY-3195
                 URL: https://issues.jboss.org/browse/WFLY-3195
             Project: WildFly
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: VFS
            Reporter: David Lloyd
            Assignee: David Lloyd


This may ultimately be a problem with VFS, or with WildFly.

We create our deployment root with an absolute VFS path of {{/content}} (see https://github.com/wildfly/wildfly/blob/dca817f584a24525c5a2f2f655aefed6d69466cf/server/src/main/java/org/jboss/as/server/deployment/module/DeploymentRootMountProcessor.java#L79 for details).  However on Windows, we have special path handling (see https://github.com/jbossas/jboss-vfs/blob/eff9d8ae6d49e30038126304b5858c6c0937d672/src/main/java/org/jboss/vfs/VFS.java#L180 for details) which causes these paths to become absolute with a drive letter (e.g. {{W:/tmp/blah/foo/content/...}}) but only on windows.  This makes writing policy files (for EAP) quite difficult, as well as just being generally wrong.

--
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

From issues at jboss.org  Mon Mar 31 10:44:14 2014
From: issues at jboss.org (Tomaz Cerar (JIRA))
Date: Mon, 31 Mar 2014 10:44:14 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3195) VFS root creation is wrong on
	Windows
In-Reply-To: <JIRA.12536630.1396277009000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12536630.1396277009000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12536630.1396277009000.19476.1396277054767@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-3195?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tomaz Cerar reassigned WFLY-3195:
---------------------------------

    Assignee: Tomaz Cerar  (was: David Lloyd)

    
> VFS root creation is wrong on Windows
> -------------------------------------
>
>                 Key: WFLY-3195
>                 URL: https://issues.jboss.org/browse/WFLY-3195
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: VFS
>            Reporter: David Lloyd
>            Assignee: Tomaz Cerar
>
> This may ultimately be a problem with VFS, or with WildFly.
> We create our deployment root with an absolute VFS path of {{/content}} (see https://github.com/wildfly/wildfly/blob/dca817f584a24525c5a2f2f655aefed6d69466cf/server/src/main/java/org/jboss/as/server/deployment/module/DeploymentRootMountProcessor.java#L79 for details).  However on Windows, we have special path handling (see https://github.com/jbossas/jboss-vfs/blob/eff9d8ae6d49e30038126304b5858c6c0937d672/src/main/java/org/jboss/vfs/VFS.java#L180 for details) which causes these paths to become absolute with a drive letter (e.g. {{W:/tmp/blah/foo/content/...}}) but only on windows.  This makes writing policy files (for EAP) quite difficult, as well as just being generally wrong.

--
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

From issues at jboss.org  Mon Mar 31 10:47:09 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 31 Mar 2014 10:47:09 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3195) VFS root creation is wrong on
	Windows
In-Reply-To: <JIRA.12536630.1396277009000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12536630.1396277009000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12536630.1396277009000.19480.1396277229173@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-3195?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated WFLY-3195:
------------------------------------------

        Bugzilla Update: Perform
    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1082491

    
> VFS root creation is wrong on Windows
> -------------------------------------
>
>                 Key: WFLY-3195
>                 URL: https://issues.jboss.org/browse/WFLY-3195
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: VFS
>            Reporter: David Lloyd
>            Assignee: Tomaz Cerar
>
> This may ultimately be a problem with VFS, or with WildFly.
> We create our deployment root with an absolute VFS path of {{/content}} (see https://github.com/wildfly/wildfly/blob/dca817f584a24525c5a2f2f655aefed6d69466cf/server/src/main/java/org/jboss/as/server/deployment/module/DeploymentRootMountProcessor.java#L79 for details).  However on Windows, we have special path handling (see https://github.com/jbossas/jboss-vfs/blob/eff9d8ae6d49e30038126304b5858c6c0937d672/src/main/java/org/jboss/vfs/VFS.java#L180 for details) which causes these paths to become absolute with a drive letter (e.g. {{W:/tmp/blah/foo/content/...}}) but only on windows.  This makes writing policy files (for EAP) quite difficult, as well as just being generally wrong.

--
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

From issues at jboss.org  Mon Mar 31 10:47:09 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 31 Mar 2014 10:47:09 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3195) VFS root creation is wrong on
	Windows
In-Reply-To: <JIRA.12536630.1396277009000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12536630.1396277009000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12536630.1396277009000.19488.1396277229608@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-3195?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated WFLY-3195:
------------------------------------------

    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1082491, https://bugzilla.redhat.com/show_bug.cgi?id=1082518  (was: https://bugzilla.redhat.com/show_bug.cgi?id=1082491)

    
> VFS root creation is wrong on Windows
> -------------------------------------
>
>                 Key: WFLY-3195
>                 URL: https://issues.jboss.org/browse/WFLY-3195
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: VFS
>            Reporter: David Lloyd
>            Assignee: Tomaz Cerar
>
> This may ultimately be a problem with VFS, or with WildFly.
> We create our deployment root with an absolute VFS path of {{/content}} (see https://github.com/wildfly/wildfly/blob/dca817f584a24525c5a2f2f655aefed6d69466cf/server/src/main/java/org/jboss/as/server/deployment/module/DeploymentRootMountProcessor.java#L79 for details).  However on Windows, we have special path handling (see https://github.com/jbossas/jboss-vfs/blob/eff9d8ae6d49e30038126304b5858c6c0937d672/src/main/java/org/jboss/vfs/VFS.java#L180 for details) which causes these paths to become absolute with a drive letter (e.g. {{W:/tmp/blah/foo/content/...}}) but only on windows.  This makes writing policy files (for EAP) quite difficult, as well as just being generally wrong.

--
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

From issues at jboss.org  Mon Mar 31 10:50:13 2014
From: issues at jboss.org (Bela Ban (JIRA))
Date: Mon, 31 Mar 2014 10:50:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1818) Discovery protocol for Gogle
	Cloud Storage
In-Reply-To: <JIRA.12536633.1396277375463@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12536633.1396277375463@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12536633.1396277375463.19501.1396277413219@jira02.app.mwc.hst.phx2.redhat.com>

Bela Ban created JGRP-1818:
------------------------------

             Summary: Discovery protocol for Gogle Cloud Storage
                 Key: JGRP-1818
                 URL: https://issues.jboss.org/browse/JGRP-1818
             Project: JGroups
          Issue Type: Feature Request
            Reporter: Bela Ban
            Assignee: Bela Ban
             Fix For: 3.5


Write a discovery protocol based on Google Cloud Storage. This can then be used with Google Compute Engine. Using S3_PING as starting point should be simple, see [1].

[1] https://developers.google.com/storage/docs/migrating

--
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

From issues at jboss.org  Mon Mar 31 10:56:12 2014
From: issues at jboss.org (Ales Justin (JIRA))
Date: Mon, 31 Mar 2014 10:56:12 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1818) Discovery protocol for Google
 Cloud Storage
In-Reply-To: <JIRA.12536633.1396277375000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12536633.1396277375000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12536633.1396277375000.19509.1396277772893@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JGRP-1818?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ales Justin updated JGRP-1818:
------------------------------

    Summary: Discovery protocol for Google Cloud Storage  (was: Discovery protocol for Gogle Cloud Storage)

    
> Discovery protocol for Google Cloud Storage
> -------------------------------------------
>
>                 Key: JGRP-1818
>                 URL: https://issues.jboss.org/browse/JGRP-1818
>             Project: JGroups
>          Issue Type: Feature Request
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 3.5
>
>
> Write a discovery protocol based on Google Cloud Storage. This can then be used with Google Compute Engine. Using S3_PING as starting point should be simple, see [1].
> [1] https://developers.google.com/storage/docs/migrating

--
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

From issues at jboss.org  Mon Mar 31 10:58:12 2014
From: issues at jboss.org (Bela Ban (JIRA))
Date: Mon, 31 Mar 2014 10:58:12 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1818) Discovery protocol for Google
 Cloud Storage
In-Reply-To: <JIRA.12536633.1396277375000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12536633.1396277375000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12536633.1396277375000.19512.1396277892921@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JGRP-1818?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban updated JGRP-1818:
---------------------------

    Description: 
Write a discovery protocol based on Google Cloud Storage. This can then be used with Google Compute Engine. Using S3_PING as starting point should be simple, see [1].
An overview of the API is at [2]. 
[1] https://developers.google.com/storage/docs/migrating
[2] https://developers.google.com/storage/docs/xml-api-overview

  was:
Write a discovery protocol based on Google Cloud Storage. This can then be used with Google Compute Engine. Using S3_PING as starting point should be simple, see [1].

[1] https://developers.google.com/storage/docs/migrating


    
> Discovery protocol for Google Cloud Storage
> -------------------------------------------
>
>                 Key: JGRP-1818
>                 URL: https://issues.jboss.org/browse/JGRP-1818
>             Project: JGroups
>          Issue Type: Feature Request
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 3.5
>
>
> Write a discovery protocol based on Google Cloud Storage. This can then be used with Google Compute Engine. Using S3_PING as starting point should be simple, see [1].
> An overview of the API is at [2]. 
> [1] https://developers.google.com/storage/docs/migrating
> [2] https://developers.google.com/storage/docs/xml-api-overview

--
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

From issues at jboss.org  Mon Mar 31 11:00:14 2014
From: issues at jboss.org (Jesper Pedersen (JIRA))
Date: Mon, 31 Mar 2014 11:00:14 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBJCA-1157) Kerberos support
In-Reply-To: <JIRA.12536024.1395760174000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12536024.1395760174000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12536024.1395760174000.19518.1396278014042@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBJCA-1157?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jesper Pedersen resolved JBJCA-1157.
------------------------------------

    Resolution: Done

    
> Kerberos support
> ----------------
>
>                 Key: JBJCA-1157
>                 URL: https://issues.jboss.org/browse/JBJCA-1157
>             Project: IronJacamar
>          Issue Type: Task
>          Components: JDBC
>            Reporter: Jesper Pedersen
>            Assignee: Jesper Pedersen
>             Fix For: 1.0.25.Final, 1.1.5.Final, 1.2.0.Beta1
>
>


--
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

From issues at jboss.org  Mon Mar 31 11:00:14 2014
From: issues at jboss.org (Jesper Pedersen (JIRA))
Date: Mon, 31 Mar 2014 11:00:14 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBJCA-1160) IronJacamar 1.0.25.Final
In-Reply-To: <JIRA.12536636.1396277972115@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12536636.1396277972115@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12536636.1396277972115.19522.1396278014257@jira02.app.mwc.hst.phx2.redhat.com>

Jesper Pedersen created JBJCA-1160:
--------------------------------------

             Summary: IronJacamar 1.0.25.Final
                 Key: JBJCA-1160
                 URL: https://issues.jboss.org/browse/JBJCA-1160
             Project: IronJacamar
          Issue Type: Release
          Components: Build
            Reporter: Jesper Pedersen
            Assignee: Jesper Pedersen
             Fix For: 1.0.25.Final


Release notes: https://issues.jboss.org/secure/ReleaseNote.jspa?projectId=12310691&version=12324212

--
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

From issues at jboss.org  Mon Mar 31 11:04:13 2014
From: issues at jboss.org (Jesper Pedersen (JIRA))
Date: Mon, 31 Mar 2014 11:04:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBJCA-1160) IronJacamar 1.0.25.Final
In-Reply-To: <JIRA.12536636.1396277972000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12536636.1396277972000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12536636.1396277972000.19535.1396278253059@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBJCA-1160?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jesper Pedersen resolved JBJCA-1160.
------------------------------------

    Resolution: Done

    
> IronJacamar 1.0.25.Final
> ------------------------
>
>                 Key: JBJCA-1160
>                 URL: https://issues.jboss.org/browse/JBJCA-1160
>             Project: IronJacamar
>          Issue Type: Release
>          Components: Build
>            Reporter: Jesper Pedersen
>            Assignee: Jesper Pedersen
>             Fix For: 1.0.25.Final
>
>
> Release notes: https://issues.jboss.org/secure/ReleaseNote.jspa?projectId=12310691&version=12324212

--
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

From issues at jboss.org  Mon Mar 31 12:40:13 2014
From: issues at jboss.org (Bela Ban (JIRA))
Date: Mon, 31 Mar 2014 12:40:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1818) Discovery protocol for Google
 Cloud Storage
In-Reply-To: <JIRA.12536633.1396277375000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12536633.1396277375000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12536633.1396277375000.20010.1396284013043@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JGRP-1818?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban updated JGRP-1818:
---------------------------

    Priority: Optional  (was: Major)


Nice but not need to have in 3.5
                
> Discovery protocol for Google Cloud Storage
> -------------------------------------------
>
>                 Key: JGRP-1818
>                 URL: https://issues.jboss.org/browse/JGRP-1818
>             Project: JGroups
>          Issue Type: Feature Request
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>            Priority: Optional
>             Fix For: 3.5
>
>
> Write a discovery protocol based on Google Cloud Storage. This can then be used with Google Compute Engine. Using S3_PING as starting point should be simple, see [1].
> An overview of the API is at [2]. 
> [1] https://developers.google.com/storage/docs/migrating
> [2] https://developers.google.com/storage/docs/xml-api-overview

--
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

From issues at jboss.org  Mon Mar 31 12:54:13 2014
From: issues at jboss.org (Jesper Pedersen (JIRA))
Date: Mon, 31 Mar 2014 12:54:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBJCA-1161) NPE in
 SemaphoreArrayListManagedConnectionPool
In-Reply-To: <JIRA.12536651.1396284851410@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12536651.1396284851410@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12536651.1396284851410.20057.1396284853028@jira02.app.mwc.hst.phx2.redhat.com>

Jesper Pedersen created JBJCA-1161:
--------------------------------------

             Summary: NPE in SemaphoreArrayListManagedConnectionPool
                 Key: JBJCA-1161
                 URL: https://issues.jboss.org/browse/JBJCA-1161
             Project: IronJacamar
          Issue Type: Bug
          Components: Core
    Affects Versions: 1.0.25.Final
            Reporter: Jesper Pedersen
            Assignee: Jesper Pedersen
            Priority: Blocker
             Fix For: 1.0.26.Final


{noformat}
at org.jboss.jca.core.connectionmanager.pool.mcp.SemaphoreArrayListManagedConnectionPool.doDestroy(SemaphoreArrayListManagedConnectionPool.java:866)
    at org.jboss.jca.core.connectionmanager.pool.mcp.SemaphoreArrayListManagedConnectionPool.getConnection(SemaphoreArrayListManagedConnectionPool.java:312)
    at org.jboss.jca.core.connectionmanager.pool.AbstractPool.getSimpleConnection(AbstractPool.java:404)
 {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

From issues at jboss.org  Mon Mar 31 14:59:13 2014
From: issues at jboss.org (James Perkins (JIRA))
Date: Mon, 31 Mar 2014 14:59:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBASMP-59) Shutdown CLI handler fails
 due to different ModelControllerClient being used
In-Reply-To: <JIRA.12524826.1384198081000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12524826.1384198081000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12524826.1384198081000.20503.1396292353813@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBASMP-59?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

James Perkins closed JBASMP-59.
-------------------------------

    Fix Version/s:     (was: 7.6.Final)
       Resolution: Out of Date


Doesn't seem to be an issue.
                
> Shutdown CLI handler fails due to different ModelControllerClient being used
> ----------------------------------------------------------------------------
>
>                 Key: JBASMP-59
>                 URL: https://issues.jboss.org/browse/JBASMP-59
>             Project: JBoss AS Maven Plugins
>          Issue Type: Bug
>            Reporter: James Perkins
>            Assignee: James Perkins
>
> See https://github.com/wildfly/wildfly/blob/7.2.0.Final-prerelease1/cli/src/main/java/org/jboss/as/cli/handlers/ShutdownHandler.java#L96. Likely just need the {{NonClosingModelControllerClient}} to extend the {{CLIModelControllerClient}}.

--
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

From issues at jboss.org  Mon Mar 31 15:39:13 2014
From: issues at jboss.org (Jesper Pedersen (JIRA))
Date: Mon, 31 Mar 2014 15:39:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBJCA-1162) IronJacamar 1.0.26.Final
In-Reply-To: <JIRA.12536667.1396294653345@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12536667.1396294653345@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12536667.1396294653345.20564.1396294753130@jira02.app.mwc.hst.phx2.redhat.com>

Jesper Pedersen created JBJCA-1162:
--------------------------------------

             Summary: IronJacamar 1.0.26.Final
                 Key: JBJCA-1162
                 URL: https://issues.jboss.org/browse/JBJCA-1162
             Project: IronJacamar
          Issue Type: Release
          Components: Build
            Reporter: Jesper Pedersen
            Assignee: Jesper Pedersen
             Fix For: 1.0.26.Final


Release notes: https://issues.jboss.org/secure/ReleaseNote.jspa?projectId=12310691&version=12324605

--
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

From issues at jboss.org  Mon Mar 31 15:39:13 2014
From: issues at jboss.org (Jesper Pedersen (JIRA))
Date: Mon, 31 Mar 2014 15:39:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBJCA-1162) IronJacamar 1.0.26.Final
In-Reply-To: <JIRA.12536667.1396294653000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12536667.1396294653000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12536667.1396294653000.20567.1396294753262@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBJCA-1162?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jesper Pedersen resolved JBJCA-1162.
------------------------------------

    Resolution: Done

    
> IronJacamar 1.0.26.Final
> ------------------------
>
>                 Key: JBJCA-1162
>                 URL: https://issues.jboss.org/browse/JBJCA-1162
>             Project: IronJacamar
>          Issue Type: Release
>          Components: Build
>            Reporter: Jesper Pedersen
>            Assignee: Jesper Pedersen
>             Fix For: 1.0.26.Final
>
>
> Release notes: https://issues.jboss.org/secure/ReleaseNote.jspa?projectId=12310691&version=12324605

--
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

From issues at jboss.org  Mon Mar 31 15:39:13 2014
From: issues at jboss.org (Jesper Pedersen (JIRA))
Date: Mon, 31 Mar 2014 15:39:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBJCA-1162) IronJacamar 1.0.26.Final
In-Reply-To: <JIRA.12536667.1396294653000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12536667.1396294653000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12536667.1396294653000.20570.1396294753432@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBJCA-1162?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jesper Pedersen closed JBJCA-1162.
----------------------------------


    
> IronJacamar 1.0.26.Final
> ------------------------
>
>                 Key: JBJCA-1162
>                 URL: https://issues.jboss.org/browse/JBJCA-1162
>             Project: IronJacamar
>          Issue Type: Release
>          Components: Build
>            Reporter: Jesper Pedersen
>            Assignee: Jesper Pedersen
>             Fix For: 1.0.26.Final
>
>
> Release notes: https://issues.jboss.org/secure/ReleaseNote.jspa?projectId=12310691&version=12324605

--
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

From issues at jboss.org  Mon Mar 31 15:39:13 2014
From: issues at jboss.org (Jesper Pedersen (JIRA))
Date: Mon, 31 Mar 2014 15:39:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBJCA-1161) NPE in
 SemaphoreArrayListManagedConnectionPool
In-Reply-To: <JIRA.12536651.1396284851000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12536651.1396284851000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12536651.1396284851000.20574.1396294753619@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBJCA-1161?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jesper Pedersen resolved JBJCA-1161.
------------------------------------

    Resolution: Done

    
> NPE in SemaphoreArrayListManagedConnectionPool
> ----------------------------------------------
>
>                 Key: JBJCA-1161
>                 URL: https://issues.jboss.org/browse/JBJCA-1161
>             Project: IronJacamar
>          Issue Type: Bug
>          Components: Core
>    Affects Versions: 1.0.25.Final
>            Reporter: Jesper Pedersen
>            Assignee: Jesper Pedersen
>            Priority: Blocker
>             Fix For: 1.0.26.Final
>
>
> {noformat}
> at org.jboss.jca.core.connectionmanager.pool.mcp.SemaphoreArrayListManagedConnectionPool.doDestroy(SemaphoreArrayListManagedConnectionPool.java:866)
>     at org.jboss.jca.core.connectionmanager.pool.mcp.SemaphoreArrayListManagedConnectionPool.getConnection(SemaphoreArrayListManagedConnectionPool.java:312)
>     at org.jboss.jca.core.connectionmanager.pool.AbstractPool.getSimpleConnection(AbstractPool.java:404)
>  {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

From issues at jboss.org  Mon Mar 31 15:39:13 2014
From: issues at jboss.org (Jesper Pedersen (JIRA))
Date: Mon, 31 Mar 2014 15:39:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBJCA-1161) NPE in
 SemaphoreArrayListManagedConnectionPool
In-Reply-To: <JIRA.12536651.1396284851000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12536651.1396284851000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12536651.1396284851000.20577.1396294753812@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBJCA-1161?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jesper Pedersen closed JBJCA-1161.
----------------------------------


    
> NPE in SemaphoreArrayListManagedConnectionPool
> ----------------------------------------------
>
>                 Key: JBJCA-1161
>                 URL: https://issues.jboss.org/browse/JBJCA-1161
>             Project: IronJacamar
>          Issue Type: Bug
>          Components: Core
>    Affects Versions: 1.0.25.Final
>            Reporter: Jesper Pedersen
>            Assignee: Jesper Pedersen
>            Priority: Blocker
>             Fix For: 1.0.26.Final
>
>
> {noformat}
> at org.jboss.jca.core.connectionmanager.pool.mcp.SemaphoreArrayListManagedConnectionPool.doDestroy(SemaphoreArrayListManagedConnectionPool.java:866)
>     at org.jboss.jca.core.connectionmanager.pool.mcp.SemaphoreArrayListManagedConnectionPool.getConnection(SemaphoreArrayListManagedConnectionPool.java:312)
>     at org.jboss.jca.core.connectionmanager.pool.AbstractPool.getSimpleConnection(AbstractPool.java:404)
>  {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

From issues at jboss.org  Mon Mar 31 23:01:12 2014
From: issues at jboss.org (Scott Stark (JIRA))
Date: Mon, 31 Mar 2014 23:01:12 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3196) Confusing
 IllegalStateException: WELD-000340: A request must be associated with the
 context when mixing JSF/CDI
In-Reply-To: <JIRA.12536695.1396321252437@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12536695.1396321252437@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12536695.1396321252437.21024.1396321272956@jira02.app.mwc.hst.phx2.redhat.com>

Scott Stark created WFLY-3196:
---------------------------------

             Summary: Confusing IllegalStateException: WELD-000340: A request must be associated with the context when mixing JSF/CDI
                 Key: WFLY-3196
                 URL: https://issues.jboss.org/browse/WFLY-3196
             Project: WildFly
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: CDI / Weld, JSF
    Affects Versions: 8.0.0.Final
         Environment: [clock-jsf-test 846]$ uname -a
Darwin scotts-imac 13.1.0 Darwin Kernel Version 13.1.0: Thu Jan 16 19:40:37 PST 2014; root:xnu-2422.90.20~2/RELEASE_X86_64 x86_64
[clock-jsf-test 847]$ java -version
java version "1.8.0"
Java(TM) SE Runtime Environment (build 1.8.0-b132)
Java HotSpot(TM) 64-Bit Server VM (build 25.0-b70, mixed mode)

Also seen with:
java version "1.7.0_45"
Java(TM) SE Runtime Environment (build 1.7.0_45-b18)
Java HotSpot(TM) 64-Bit Server VM (build 24.45-b08, mixed mode)

            Reporter: Scott Stark
            Assignee: Stuart Douglas


I have a simple web app doing injection into a JSF managed bean using @EJB. When the managed bean lifecycle and duration is described using the JSF @ManagedBean and @ApplicationScoped I get a "IllegalStateException: WELD-000340 ..." error when loading the welcome page. The only workaround I have seen is to disable implicit CDI usage, but the web app is using CDI, so that is not appropriate.

The problem seems to be a lack of understanding what is going on between the weld and jsf containers. I understand that the JSF @ManagedBean is deprecated in favor of CDI @Named, but it would be nice if we can provide better feedback when @ManagedBean is used along with CDI.

The following git repo provides a complete test application along with the steps to cause the error as well as how to fix it by only using CDI annotations.

https://github.com/starksm64/clock-jsf-test


--
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

From issues at jboss.org  Mon Mar 31 23:05:13 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 31 Mar 2014 23:05:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2949) Cannot get exception as
	pass-by-reference
In-Reply-To: <JIRA.12532450.1392708507000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12532450.1392708507000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12532450.1392708507000.21031.1396321513461@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2949?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated WFLY-2949:
------------------------------------------

    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1055896, https://bugzilla.redhat.com/show_bug.cgi?id=1082880  (was: https://bugzilla.redhat.com/show_bug.cgi?id=1055896)

    
> Cannot get exception as pass-by-reference
> -----------------------------------------
>
>                 Key: WFLY-2949
>                 URL: https://issues.jboss.org/browse/WFLY-2949
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: EJB
>    Affects Versions: 8.0.0.Final
>            Reporter: Osamu Nagano
>            Assignee: David Lloyd
>             Fix For: 8.0.1.Final
>
>
> Despite of {{<in-vm-remote-interface-invocation pass-by-value="false"/>}}, an exception is not thrown by reference, which results in {{java.io.NotSerializableException}} if the exception doesn't implement {{Serializable}}.  This is a blocker of a large migration project from WebLogic because it throws by reference even if that doesn't implement {{Serializable}}.

--
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

From issues at jboss.org  Mon Mar 31 23:17:13 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 31 Mar 2014 23:17:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2949) Cannot get exception as
	pass-by-reference
In-Reply-To: <JIRA.12532450.1392708507000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12532450.1392708507000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12532450.1392708507000.21037.1396322233479@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2949?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12957946#comment-12957946 ] 

RH Bugzilla Integration commented on WFLY-2949:
-----------------------------------------------

Osamu Nagano <onagano at redhat.com> changed the Status of [bug 1082880|https://bugzilla.redhat.com/show_bug.cgi?id=1082880] from NEW to POST
                
> Cannot get exception as pass-by-reference
> -----------------------------------------
>
>                 Key: WFLY-2949
>                 URL: https://issues.jboss.org/browse/WFLY-2949
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: EJB
>    Affects Versions: 8.0.0.Final
>            Reporter: Osamu Nagano
>            Assignee: David Lloyd
>             Fix For: 8.0.1.Final
>
>
> Despite of {{<in-vm-remote-interface-invocation pass-by-value="false"/>}}, an exception is not thrown by reference, which results in {{java.io.NotSerializableException}} if the exception doesn't implement {{Serializable}}.  This is a blocker of a large migration project from WebLogic because it throws by reference even if that doesn't implement {{Serializable}}.

--
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

From issues at jboss.org  Mon Mar 31 23:19:12 2014
From: issues at jboss.org (Stuart Douglas (JIRA))
Date: Mon, 31 Mar 2014 23:19:12 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3196) Confusing
 IllegalStateException: WELD-000340: A request must be associated with the
 context when mixing JSF/CDI
In-Reply-To: <JIRA.12536695.1396321252000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12536695.1396321252000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12536695.1396321252000.21041.1396322352949@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-3196?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stuart Douglas reassigned WFLY-3196:
------------------------------------

    Assignee: Jozef Hartinger  (was: Stuart Douglas)

    
> Confusing IllegalStateException: WELD-000340: A request must be associated with the context when mixing JSF/CDI
> ---------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-3196
>                 URL: https://issues.jboss.org/browse/WFLY-3196
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: CDI / Weld, JSF
>    Affects Versions: 8.0.0.Final
>         Environment: [clock-jsf-test 846]$ uname -a
> Darwin scotts-imac 13.1.0 Darwin Kernel Version 13.1.0: Thu Jan 16 19:40:37 PST 2014; root:xnu-2422.90.20~2/RELEASE_X86_64 x86_64
> [clock-jsf-test 847]$ java -version
> java version "1.8.0"
> Java(TM) SE Runtime Environment (build 1.8.0-b132)
> Java HotSpot(TM) 64-Bit Server VM (build 25.0-b70, mixed mode)
> Also seen with:
> java version "1.7.0_45"
> Java(TM) SE Runtime Environment (build 1.7.0_45-b18)
> Java HotSpot(TM) 64-Bit Server VM (build 24.45-b08, mixed mode)
>            Reporter: Scott Stark
>            Assignee: Jozef Hartinger
>
> I have a simple web app doing injection into a JSF managed bean using @EJB. When the managed bean lifecycle and duration is described using the JSF @ManagedBean and @ApplicationScoped I get a "IllegalStateException: WELD-000340 ..." error when loading the welcome page. The only workaround I have seen is to disable implicit CDI usage, but the web app is using CDI, so that is not appropriate.
> The problem seems to be a lack of understanding what is going on between the weld and jsf containers. I understand that the JSF @ManagedBean is deprecated in favor of CDI @Named, but it would be nice if we can provide better feedback when @ManagedBean is used along with CDI.
> The following git repo provides a complete test application along with the steps to cause the error as well as how to fix it by only using CDI annotations.
> https://github.com/starksm64/clock-jsf-test

--
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