[JBoss JIRA] (WFCORE-107) Update whoami operation to return authentication mechanism where verbose=true
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-107?page=com.atlassian.jira.plugin... ]
Brian Stansberry updated WFCORE-107:
------------------------------------
Fix Version/s: 3.0.0.Beta1
(was: 2.0.0.Alpha9)
> Update whoami operation to return authentication mechanism where verbose=true
> -----------------------------------------------------------------------------
>
> Key: WFCORE-107
> URL: https://issues.jboss.org/browse/WFCORE-107
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Domain Management
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Fix For: 3.0.0.Beta1
>
>
> The admin console currently contains a "logout" handler that follows a round of HTTP message exchanges to trick the web browser into forgetting the credentials it has cached.
> This only makes sense where the browser has cached a credential - if we return the authentication mechanism then the console can make a better decision regarding displaying the logout link or could change the implementation so display a message to the user explaining why logout does not make sense.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 8 months
[JBoss JIRA] (WFCORE-364) Hangs in mixed domain testsuite
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-364?page=com.atlassian.jira.plugin... ]
Brian Stansberry commented on WFCORE-364:
-----------------------------------------
I still think this is out of date.
> Hangs in mixed domain testsuite
> -------------------------------
>
> Key: WFCORE-364
> URL: https://issues.jboss.org/browse/WFCORE-364
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
> Fix For: 2.0.0.CR1
>
> Attachments: testsuite-hang1-server.txt, testsuite-hang2-client.txt, testsuite-hang2-server.txt
>
>
> http://lightning.mw.lab.eng.bos.redhat.com/jenkins/job/wildfly-param-pull...
> https://dl.dropboxusercontent.com/u/712508/mixed-hang-debug.zip contains details.
> 30805.dump is the client and shows the problem is occurring in the @After cleanup of MixedDomainDeploymentTest as it removes deployments from the domain.
> "main" prio=10 tid=0xf7605c00 nid=0x7856 in Object.wait() [0xf776e000]
> java.lang.Thread.State: WAITING (on object monitor)
> at java.lang.Object.wait(Native Method)
> - waiting on <0xe50275f0> (a org.jboss.as.protocol.mgmt.ActiveOperationSupport$ActiveOperationImpl)
> at java.lang.Object.wait(Object.java:503)
> at org.jboss.threads.AsyncFutureTask.await(AsyncFutureTask.java:192)
> - locked <0xe50275f0> (a org.jboss.as.protocol.mgmt.ActiveOperationSupport$ActiveOperationImpl)
> at org.jboss.threads.AsyncFutureTask.get(AsyncFutureTask.java:266)
> - locked <0xe50275f0> (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.controller.client.helpers.domain.impl.DomainClientImpl.execute(DomainClientImpl.java:81)
> at org.jboss.as.test.integration.domain.mixed.MixedDomainDeploymentTest.removeDeployment(MixedDomainDeploymentTest.java:441)
> at org.jboss.as.test.integration.domain.mixed.MixedDomainDeploymentTest.cleanDeployments(MixedDomainDeploymentTest.java:343)
> at org.jboss.as.test.integration.domain.mixed.MixedDomainDeploymentTest.confirmNoDeployments(MixedDomainDeploymentTest.java:163)
> 31894.dump shows the master HC. management-handler-thread is blocking on the way out (after sending the commit or rollback) waiting for a final result response from the slave.
> "management-handler-thread - 1" prio=10 tid=0xca0efc00 nid=0x7cdd in Object.wait() [0xc7469000]
> java.lang.Thread.State: WAITING (on object monitor)
> at java.lang.Object.wait(Native Method)
> - waiting on <0xeb6d6558> (a org.jboss.as.protocol.mgmt.ActiveOperationSupport$ActiveOperationImpl)
> at java.lang.Object.wait(Object.java:503)
> at org.jboss.threads.AsyncFutureTask.await(AsyncFutureTask.java:192)
> - locked <0xeb6d6558> (a org.jboss.as.protocol.mgmt.ActiveOperationSupport$ActiveOperationImpl)
> at org.jboss.threads.AsyncFutureTask.get(AsyncFutureTask.java:266)
> - locked <0xeb6d6558> (a org.jboss.as.protocol.mgmt.ActiveOperationSupport$ActiveOperationImpl)
> at org.jboss.as.controller.client.impl.AbstractDelegatingAsyncFuture.get(AbstractDelegatingAsyncFuture.java:100)
> at org.jboss.as.domain.controller.operations.coordination.DomainSlaveHandler.finalizeOp(DomainSlaveHandler.java:215)
> at org.jboss.as.domain.controller.operations.coordination.DomainSlaveHandler.access$000(DomainSlaveHandler.java:58)
> at org.jboss.as.domain.controller.operations.coordination.DomainSlaveHandler$1.handleResult(DomainSlaveHandler.java:179)
> at org.jboss.as.controller.AbstractOperationContext$Step.handleRollback(AbstractOperationContext.java:805)
> at org.jboss.as.controller.AbstractOperationContext$Step.finalizeInternal(AbstractOperationContext.java:763)
> at org.jboss.as.controller.AbstractOperationContext$Step.finalizeStep(AbstractOperationContext.java:738)
> (Note that the "handleRollback" method name is a red-herring -- the method should be renamed to a "handleResult" as it now is called no matter what the result.)
> 31986.dump is the slave HC. It shows it is blocking in stage DONE after having sent operationPrepared to the master, waiting for commit or rollback.
> "domain-connection-threads - 1" prio=10 tid=0xc91a8400 nid=0x7d1a waiting on condition [0xc87fe000]
> java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <0xea1fd410> (a java.util.concurrent.CountDownLatch$Sync)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:186)
> at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:834)
> at java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:994)
> at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1303)
> at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:236)
> at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ProxyOperationControlProxy.operationPrepared(TransactionalProtocolOperationHandler.java:173)
> at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:337)
> at org.jboss.as.controller.AbstractOperationContext.completeStep(AbstractOperationContext.java:211)
> at org.jboss.as.domain.controller.operations.coordination.ServerOperationsResolverHandler.execute(ServerOperationsResolverHandler.java:128)
> Indication is the commit or rollback message is getting lost. There are no threads shown sending or receiving it.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 8 months
[JBoss JIRA] (WFCORE-364) Hangs in mixed domain testsuite
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-364?page=com.atlassian.jira.plugin... ]
Brian Stansberry updated WFCORE-364:
------------------------------------
Fix Version/s: 2.0.0.CR1
(was: 2.0.0.Alpha9)
> Hangs in mixed domain testsuite
> -------------------------------
>
> Key: WFCORE-364
> URL: https://issues.jboss.org/browse/WFCORE-364
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
> Fix For: 2.0.0.CR1
>
> Attachments: testsuite-hang1-server.txt, testsuite-hang2-client.txt, testsuite-hang2-server.txt
>
>
> http://lightning.mw.lab.eng.bos.redhat.com/jenkins/job/wildfly-param-pull...
> https://dl.dropboxusercontent.com/u/712508/mixed-hang-debug.zip contains details.
> 30805.dump is the client and shows the problem is occurring in the @After cleanup of MixedDomainDeploymentTest as it removes deployments from the domain.
> "main" prio=10 tid=0xf7605c00 nid=0x7856 in Object.wait() [0xf776e000]
> java.lang.Thread.State: WAITING (on object monitor)
> at java.lang.Object.wait(Native Method)
> - waiting on <0xe50275f0> (a org.jboss.as.protocol.mgmt.ActiveOperationSupport$ActiveOperationImpl)
> at java.lang.Object.wait(Object.java:503)
> at org.jboss.threads.AsyncFutureTask.await(AsyncFutureTask.java:192)
> - locked <0xe50275f0> (a org.jboss.as.protocol.mgmt.ActiveOperationSupport$ActiveOperationImpl)
> at org.jboss.threads.AsyncFutureTask.get(AsyncFutureTask.java:266)
> - locked <0xe50275f0> (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.controller.client.helpers.domain.impl.DomainClientImpl.execute(DomainClientImpl.java:81)
> at org.jboss.as.test.integration.domain.mixed.MixedDomainDeploymentTest.removeDeployment(MixedDomainDeploymentTest.java:441)
> at org.jboss.as.test.integration.domain.mixed.MixedDomainDeploymentTest.cleanDeployments(MixedDomainDeploymentTest.java:343)
> at org.jboss.as.test.integration.domain.mixed.MixedDomainDeploymentTest.confirmNoDeployments(MixedDomainDeploymentTest.java:163)
> 31894.dump shows the master HC. management-handler-thread is blocking on the way out (after sending the commit or rollback) waiting for a final result response from the slave.
> "management-handler-thread - 1" prio=10 tid=0xca0efc00 nid=0x7cdd in Object.wait() [0xc7469000]
> java.lang.Thread.State: WAITING (on object monitor)
> at java.lang.Object.wait(Native Method)
> - waiting on <0xeb6d6558> (a org.jboss.as.protocol.mgmt.ActiveOperationSupport$ActiveOperationImpl)
> at java.lang.Object.wait(Object.java:503)
> at org.jboss.threads.AsyncFutureTask.await(AsyncFutureTask.java:192)
> - locked <0xeb6d6558> (a org.jboss.as.protocol.mgmt.ActiveOperationSupport$ActiveOperationImpl)
> at org.jboss.threads.AsyncFutureTask.get(AsyncFutureTask.java:266)
> - locked <0xeb6d6558> (a org.jboss.as.protocol.mgmt.ActiveOperationSupport$ActiveOperationImpl)
> at org.jboss.as.controller.client.impl.AbstractDelegatingAsyncFuture.get(AbstractDelegatingAsyncFuture.java:100)
> at org.jboss.as.domain.controller.operations.coordination.DomainSlaveHandler.finalizeOp(DomainSlaveHandler.java:215)
> at org.jboss.as.domain.controller.operations.coordination.DomainSlaveHandler.access$000(DomainSlaveHandler.java:58)
> at org.jboss.as.domain.controller.operations.coordination.DomainSlaveHandler$1.handleResult(DomainSlaveHandler.java:179)
> at org.jboss.as.controller.AbstractOperationContext$Step.handleRollback(AbstractOperationContext.java:805)
> at org.jboss.as.controller.AbstractOperationContext$Step.finalizeInternal(AbstractOperationContext.java:763)
> at org.jboss.as.controller.AbstractOperationContext$Step.finalizeStep(AbstractOperationContext.java:738)
> (Note that the "handleRollback" method name is a red-herring -- the method should be renamed to a "handleResult" as it now is called no matter what the result.)
> 31986.dump is the slave HC. It shows it is blocking in stage DONE after having sent operationPrepared to the master, waiting for commit or rollback.
> "domain-connection-threads - 1" prio=10 tid=0xc91a8400 nid=0x7d1a waiting on condition [0xc87fe000]
> java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <0xea1fd410> (a java.util.concurrent.CountDownLatch$Sync)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:186)
> at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:834)
> at java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:994)
> at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1303)
> at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:236)
> at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ProxyOperationControlProxy.operationPrepared(TransactionalProtocolOperationHandler.java:173)
> at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:337)
> at org.jboss.as.controller.AbstractOperationContext.completeStep(AbstractOperationContext.java:211)
> at org.jboss.as.domain.controller.operations.coordination.ServerOperationsResolverHandler.execute(ServerOperationsResolverHandler.java:128)
> Indication is the commit or rollback message is getting lost. There are no threads shown sending or receiving it.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 8 months
[JBoss JIRA] (DROOLS-37) Operators on java.lang.Comparable object doesn't work if JIT is enable
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/DROOLS-37?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on DROOLS-37:
-----------------------------------------------
Marek Winkler <mwinkler(a)redhat.com> changed the Status of [bug 1233978|https://bugzilla.redhat.com/show_bug.cgi?id=1233978] from ON_QA to VERIFIED
> Operators on java.lang.Comparable object doesn't work if JIT is enable
> ----------------------------------------------------------------------
>
> Key: DROOLS-37
> URL: https://issues.jboss.org/browse/DROOLS-37
> Project: Drools
> Issue Type: Bug
> Affects Versions: 5.5.0.Final
> Environment: Windows XP
> Java 1.5
> joda-time 1.6.2
> Reporter: Jérémy SOULA
> Assignee: Mario Fusco
> Labels: 5.5, comparable, localDate
> Fix For: 5.5.1.Final, 6.0.0.Alpha9
>
> Attachments: drools-bugs.zip
>
>
> In my application, i have rules that used org.joda.time.LocalDate to compare date like
> {noformat}
> rule "toto"
> when
> LocalDateForDroolsTestBean(
> infDate>=supDate
> )
> then
> //Anything
> end
> {noformat}
> With Drools 5.3, all works fine.
> With Drools 5.5, an exception occured because JIT optimizer automaticaly enabled:
> {noformat}
> Exception in thread "main" java.lang.NoSuchMethodError: org.joda.time.LocalDate.compareTo(Lorg/joda/time/LocalDate;)I
> at ConditionEvaluatorf8ba8fa3003345adbf3979e901488f23.evaluate(Unknown Source)
> at org.drools.rule.constraint.MvelConstraint.evaluate(MvelConstraint.java:200)
> at org.drools.rule.constraint.MvelConstraint.isAllowed(MvelConstraint.java:157)
> at org.drools.reteoo.AlphaNode.assertObject(AlphaNode.java:137)
> at org.drools.reteoo.SingleObjectSinkAdapter.propagateAssertObject(SingleObjectSinkAdapter.java:59)
> at org.drools.reteoo.ObjectTypeNode.assertObject(ObjectTypeNode.java:235)
> at org.drools.reteoo.EntryPointNode.assertObject(EntryPointNode.java:240)
> at org.drools.common.NamedEntryPoint.insert(NamedEntryPoint.java:350)
> at org.drools.common.NamedEntryPoint.insert(NamedEntryPoint.java:311)
> at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:903)
> at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:847)
> at org.drools.impl.StatefulKnowledgeSessionImpl.insert(StatefulKnowledgeSessionImpl.java:269)
> at org.drools.impl.StatelessKnowledgeSessionImpl.execute(StatelessKnowledgeSessionImpl.java:304)
> at fr.jsoula.jboss.drools.bugs.comparable.ComparableBug.main(ComparableBug.java:39)
> {noformat}
> After search, it seems that the bytecode generated by org.drools.rule.builder.dialect.asm.ClassGenerator can't call the method public int compareTo(Object partial) of org.joda.time.LocalDate. The parameter of the method must be the same class of the current object.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 8 months
[JBoss JIRA] (WFCORE-710) Make ServerOperationResolver handle deployment-overlays similarly to deployments
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-710?page=com.atlassian.jira.plugin... ]
Brian Stansberry updated WFCORE-710:
------------------------------------
Fix Version/s: 2.0.0.CR1
(was: 2.0.0.Alpha9)
[~kabirkhan] I'm moving this to CR1 as Alpha9 is clearly incorrect. But if this won't happen for CR1 please reschedule.
> Make ServerOperationResolver handle deployment-overlays similarly to deployments
> --------------------------------------------------------------------------------
>
> Key: WFCORE-710
> URL: https://issues.jboss.org/browse/WFCORE-710
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Domain Management
> Affects Versions: 2.0.0.Alpha2
> Reporter: Kabir Khan
> Assignee: Kabir Khan
> Fix For: 2.0.0.CR1
>
>
> Currently in domain mode a
> {code}
> /deployment-overlay=xxx:add(...)
> {code}
> results in a deployment overlay on ALL servers.
> However for deployments
> {code}
> /deployment=xxx:add(...)
> {code}
> does not get pushed to the servers. This happens when it is associated with a server group:
> {code}
> /server-group=zzz/deployment=xxx:add(...)
> {code}
> Similarly
> {code}
> /deployment-overlay=xxx:add(...)
> {code}
> should not get pushed to the servers, until we have a
> {code}
> /server-group=zzz/deployment=yyy:add(...)
> {code}
> which picks out the servers we want to have the overlay
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 8 months