August 2015 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFCORE-304) Enable user agent and address filters.

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-304?page=com.atlassian.jira.plugin... ] Brian Stansberry updated WFCORE-304: ------------------------------------ Fix Version/s: (was: 2.0.0.Alpha9) Unscheduling as the parent task is not scheduled. > Enable user agent and address filters. > -------------------------------------- > > Key: WFCORE-304 > URL: https://issues.jboss.org/browse/WFCORE-304 > Project: WildFly Core > Issue Type: Sub-task > Components: Domain Management > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > -- This message was sent by Atlassian JIRA (v6.3.15#6346)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-296) Switch URI scheme from remoting:// http-remoting:// https-remoting:// to remote:// remote+http:// and remote+https://

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-296?page=com.atlassian.jira.plugin... ] Brian Stansberry updated WFCORE-296: ------------------------------------ Fix Version/s: 2.0.0.CR1 (was: 2.0.0.Alpha9) > Switch URI scheme from remoting:// http-remoting:// https-remoting:// to remote:// remote+http:// and remote+https:// > --------------------------------------------------------------------------------------------------------------------- > > Key: WFCORE-296 > URL: https://issues.jboss.org/browse/WFCORE-296 > Project: WildFly Core > Issue Type: Enhancement > Components: CLI, Domain Management > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 2.0.0.CR1 > > > From [~dmlloyd] > {quote} > When we have multi-layer protocol going on, the URI scheme we should use > is like this: > outer+middle+inner:// > {quote} > Switch URI schemes from remoting:// http-remoting:// https-remoting:// to remote:// remote+http:// and remote+https:// > The existing schemes will be needed for backwards compatibility but somehow deprecated. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-266) Deprecate the ParameterValidator constructor variants that accept allowNull and allowExpressions params

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-266?page=com.atlassian.jira.plugin... ] Brian Stansberry updated WFCORE-266: ------------------------------------ Fix Version/s: 3.0.0.Beta1 (was: 2.0.0.Alpha9) > Deprecate the ParameterValidator constructor variants that accept allowNull and allowExpressions params > ------------------------------------------------------------------------------------------------------- > > Key: WFCORE-266 > URL: https://issues.jboss.org/browse/WFCORE-266 > Project: WildFly Core > Issue Type: Task > Components: Domain Management > Reporter: Brian Stansberry > Fix For: 3.0.0.Beta1 > > > Most of the ParameterValidator implementations that get passed to AttributeDefinition accept params to control whether null and expressions are allowed. These are now redundant, as AttributeDefinition wraps the provided validator with NillableOrExpressionParameterValidator, and it handles that aspect of validation based on the settings of the AD. > So we should deprecate these constructor variants to let people know they aren't needed. Ideally shift the code as well. > CRITICAL: before doing this, make sure the AttributeDefinition variants that support complex types properly wrap any validators that are configured for *element* validation. A quick look shows that ListAttributeDefinition.Builder and MapAttributeDefinition.Builder do. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-683) ListModuleRootsHandler and ModuleLocationHandler don't handle PrivilegedActionException properly

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-683?page=com.atlassian.jira.plugin... ] Brian Stansberry updated WFCORE-683: ------------------------------------ Fix Version/s: 3.0.0.Alpha1 (was: 2.0.0.Alpha9) > ListModuleRootsHandler and ModuleLocationHandler don't handle PrivilegedActionException properly > ------------------------------------------------------------------------------------------------ > > Key: WFCORE-683 > URL: https://issues.jboss.org/browse/WFCORE-683 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Affects Versions: 1.0.0.CR1 > Reporter: Brian Stansberry > Fix For: 3.0.0.Alpha1 > > > The two inner class OSHs in ModuleLoadingResourceDefinition don't deal with exceptions properly. They invoke AccessController.doPrivileged and then deal with any PrivilegedActionException by rethrowing as OperationFailedException. > OperationFailedException represents a client mistake and is handled as such (e.g. isn't logged in the server log.) It shouldn't be thrown here unless the PrivilegedActionException.getCause() value is itself an OFE. Otherwise, the OSHs should throw a RuntimeException. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-646) Product to Project Schema and Model Sync

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-646?page=com.atlassian.jira.plugin... ] Brian Stansberry updated WFCORE-646: ------------------------------------ Fix Version/s: 2.0.0.CR1 (was: 2.0.0.Alpha9) > Product to Project Schema and Model Sync > ---------------------------------------- > > Key: WFCORE-646 > URL: https://issues.jboss.org/browse/WFCORE-646 > Project: WildFly Core > Issue Type: Task > Components: Domain Management > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 2.0.0.CR1 > > > Periodic sync of EAP schemas with WildFly. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

8 years, 8 months

1
0
0 / 0

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

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-137) Add Kerberos tests to domain-management module

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-137?page=com.atlassian.jira.plugin... ] Brian Stansberry updated WFCORE-137: ------------------------------------ Fix Version/s: 2.0.0.CR1 (was: 2.0.0.Alpha9) [~dlofthouse] Please resolve or reschedule. > Add Kerberos tests to domain-management module > ---------------------------------------------- > > Key: WFCORE-137 > URL: https://issues.jboss.org/browse/WFCORE-137 > Project: WildFly Core > Issue Type: Sub-task > Components: Domain Management, Security > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 2.0.0.CR1 > > -- This message was sent by Atlassian JIRA (v6.3.15#6346)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-103) Add Full Kerberos Support

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-103?page=com.atlassian.jira.plugin... ] Brian Stansberry updated WFCORE-103: ------------------------------------ Fix Version/s: 2.0.0.CR1 (was: 2.0.0.Alpha9) [~dlofthouse] Please resolve or reschedule. > Add Full Kerberos Support > ------------------------- > > Key: WFCORE-103 > URL: https://issues.jboss.org/browse/WFCORE-103 > Project: WildFly Core > Issue Type: Task > Components: Domain Management > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Labels: management_security, > Fix For: 2.0.0.CR1 > > > There are a number of steps required to full add Kerberos support - this is a top level tracking task to be resolved once all steps are complete. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

8 years, 8 months

1
0
0 / 0

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

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-688) Remove ServerEnvironment.getModulesDir()

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-688?page=com.atlassian.jira.plugin... ] Brian Stansberry commented on WFCORE-688: ----------------------------------------- At this point I don't expect to actually do this; but I rescheduled it to CR1 as Alpha9 is not valid. > Remove ServerEnvironment.getModulesDir() > ---------------------------------------- > > Key: WFCORE-688 > URL: https://issues.jboss.org/browse/WFCORE-688 > Project: WildFly Core > Issue Type: Task > Components: Domain Management, Server > Reporter: Brian Stansberry > Assignee: Brian Stansberry > Fix For: 2.0.0.CR1 > > > This method was deprecated in 7.1.0 and the OSGi subsystem is removing the only known use of it in 7.1.2. Remove the method in 7.2. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

8 years, 8 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira August 2015