March 2017 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFCORE-2605) Upgrade DMR to 1.4.0.Final

by Brian Stansberry (JIRA)

Brian Stansberry created WFCORE-2605: ---------------------------------------- Summary: Upgrade DMR to 1.4.0.Final Key: WFCORE-2605 URL: https://issues.jboss.org/browse/WFCORE-2605 Project: WildFly Core Issue Type: Component Upgrade Components: Domain Management Reporter: Brian Stansberry Assignee: Brian Stansberry Fix For: 3.0.0.Beta12 Just a pom change to the currently used 1.4.0.Beta2 to promote it to final. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFCORE-2604) Upgrade DMR to 1.4.0.Final

by Brian Stansberry (JIRA)

Brian Stansberry created WFCORE-2604: ---------------------------------------- Summary: Upgrade DMR to 1.4.0.Final Key: WFCORE-2604 URL: https://issues.jboss.org/browse/WFCORE-2604 Project: WildFly Core Issue Type: Component Upgrade Components: Domain Management Reporter: Brian Stansberry Assignee: Brian Stansberry Fix For: 3.0.0.Beta12 Just a pom change to the currently used 1.4.0.Beta2 to promote it to final. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFCORE-2217) ValidationStepHandler does not get triggered on boot in subsystem-/core-model tests

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2217?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-2217: ------------------------------------- Issue Type: Bug (was: Component Upgrade) > ValidationStepHandler does not get triggered on boot in subsystem-/core-model tests > ----------------------------------------------------------------------------------- > > Key: WFCORE-2217 > URL: https://issues.jboss.org/browse/WFCORE-2217 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Affects Versions: 3.0.0.Alpha16 > Reporter: Kabir Khan > Assignee: Brian Stansberry > Fix For: 4.0.0.Alpha1 > > > During a normal server boot ValidationStepHandler gets called. But during a core-model-/subsystem tests it does not get called on boot. The issue is that in these tests bootOperations.postExtensionOps are null, so the if block at https://github.com/wildfly/wildfly-core/blob/3.0.0.Alpha19/controller/src... which contains the validation logic at https://github.com/wildfly/wildfly-core/blob/3.0.0.Alpha19/controller/src... does not get called. > The fix is quite simple: > {code} > diff --git a/controller/src/main/java/org/jboss/as/controller/ModelControllerImpl.java b/controller/src/main/java/org/jboss/as/controller/ModelControllerImpl.java > index 4a6cc7c..d8e1911 100644 > --- a/controller/src/main/java/org/jboss/as/controller/ModelControllerImpl.java > +++ b/controller/src/main/java/org/jboss/as/controller/ModelControllerImpl.java > @@ -517,21 +517,21 @@ class ModelControllerImpl implements ModelController { > } > > resultAction = postExtContext.executeOperation(); > + } > > - if (!skipModelValidation && resultAction == OperationContext.ResultAction.KEEP && bootOperations.postExtensionOps != null) { > - //Get the modified resources from the initial operations and add to the resources to be validated by the post operations > - Set<PathAddress> validateAddresses = new HashSet<PathAddress>(); > - Resource root = managementModel.get().getRootResource(); > - addAllAddresses(managementModel.get().getRootResourceRegistration(), PathAddress.EMPTY_ADDRESS, root, validateAddresses); > - > - final AbstractOperationContext validateContext = new OperationContextImpl(operationID, POST_EXTENSION_BOOT_OPERATION, > - EMPTY_ADDRESS, this, processType, runningModeControl.getRunningMode(), > - contextFlags, handler, null, managementModel.get(), control, processState, auditLogger, > - bootingFlag.get(), hostServerGroupTracker, null, null, notificationSupport, false, > - extraValidationStepHandler, partialModel, securityIdentitySupplier); > - validateContext.addModifiedResourcesForModelValidation(validateAddresses); > - resultAction = validateContext.executeOperation(); > - } > + if (!skipModelValidation && resultAction == OperationContext.ResultAction.KEEP) { > + //Get the modified resources from the initial operations and add to the resources to be validated by the post operations > + Set<PathAddress> validateAddresses = new HashSet<PathAddress>(); > + Resource root = managementModel.get().getRootResource(); > + addAllAddresses(managementModel.get().getRootResourceRegistration(), PathAddress.EMPTY_ADDRESS, root, validateAddresses); > + > + final AbstractOperationContext validateContext = new OperationContextImpl(operationID, POST_EXTENSION_BOOT_OPERATION, > + EMPTY_ADDRESS, this, processType, runningModeControl.getRunningMode(), > + contextFlags, handler, null, managementModel.get(), control, processState, auditLogger, > + bootingFlag.get(), hostServerGroupTracker, null, null, notificationSupport, false, > + extraValidationStepHandler, partialModel, securityIdentitySupplier); > + validateContext.addModifiedResourcesForModelValidation(validateAddresses); > + resultAction = validateContext.executeOperation(); > } > > return resultAction == OperationContext.ResultAction.KEEP; > {code} > but changing this and trying to run the widlfly-core tests causes failures in the remoting subsystem and loads in the core-model-tests. There are bound to be more in the subsystems in full. > I'd hazard a guess and say that the subsystem tests are aiming for good coverage, and so might be setting stuff which would fail validation e.g. of Alternatives. > For core model tests it is complaining about things like missing management-xxx-versions in the model, default interfaces in socket binding groups and a lot of things like that. In a lot of cases the xml used in the tests uses minimum information to set up things for what is needed. WIP for the core model tests is: > {code} > diff --git a/controller/src/main/java/org/jboss/as/controller/ModelControllerImpl.java b/controller/src/main/java/org/jboss/as/controller/ModelControllerImpl.java > index 4a6cc7c..d8e1911 100644 > --- a/controller/src/main/java/org/jboss/as/controller/ModelControllerImpl.java > +++ b/controller/src/main/java/org/jboss/as/controller/ModelControllerImpl.java > @@ -517,21 +517,21 @@ class ModelControllerImpl implements ModelController { > } > > resultAction = postExtContext.executeOperation(); > + } > > - if (!skipModelValidation && resultAction == OperationContext.ResultAction.KEEP && bootOperations.postExtensionOps != null) { > - //Get the modified resources from the initial operations and add to the resources to be validated by the post operations > - Set<PathAddress> validateAddresses = new HashSet<PathAddress>(); > - Resource root = managementModel.get().getRootResource(); > - addAllAddresses(managementModel.get().getRootResourceRegistration(), PathAddress.EMPTY_ADDRESS, root, validateAddresses); > - > - final AbstractOperationContext validateContext = new OperationContextImpl(operationID, POST_EXTENSION_BOOT_OPERATION, > - EMPTY_ADDRESS, this, processType, runningModeControl.getRunningMode(), > - contextFlags, handler, null, managementModel.get(), control, processState, auditLogger, > - bootingFlag.get(), hostServerGroupTracker, null, null, notificationSupport, false, > - extraValidationStepHandler, partialModel, securityIdentitySupplier); > - validateContext.addModifiedResourcesForModelValidation(validateAddresses); > - resultAction = validateContext.executeOperation(); > - } > + if (!skipModelValidation && resultAction == OperationContext.ResultAction.KEEP) { > + //Get the modified resources from the initial operations and add to the resources to be validated by the post operations > + Set<PathAddress> validateAddresses = new HashSet<PathAddress>(); > + Resource root = managementModel.get().getRootResource(); > + addAllAddresses(managementModel.get().getRootResourceRegistration(), PathAddress.EMPTY_ADDRESS, root, validateAddresses); > + > + final AbstractOperationContext validateContext = new OperationContextImpl(operationID, POST_EXTENSION_BOOT_OPERATION, > + EMPTY_ADDRESS, this, processType, runningModeControl.getRunningMode(), > + contextFlags, handler, null, managementModel.get(), control, processState, auditLogger, > + bootingFlag.get(), hostServerGroupTracker, null, null, notificationSupport, false, > + extraValidationStepHandler, partialModel, securityIdentitySupplier); > + validateContext.addModifiedResourcesForModelValidation(validateAddresses); > + resultAction = validateContext.executeOperation(); > } > > return resultAction == OperationContext.ResultAction.KEEP; > {code} > So although the fix is simple, the fallout of this is quite big. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ELY-1030) Move TokenSecurityRealm to org.wildfly.security.auth.realm package

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-1030?page=com.atlassian.jira.plugin.s... ] Darran Lofthouse updated ELY-1030: ---------------------------------- Fix Version/s: 1.1.0.Beta35 (was: 1.1.0.Beta34) > Move TokenSecurityRealm to org.wildfly.security.auth.realm package > ------------------------------------------------------------------ > > Key: ELY-1030 > URL: https://issues.jboss.org/browse/ELY-1030 > Project: WildFly Elytron > Issue Type: Enhancement > Components: Realms > Reporter: Darran Lofthouse > Assignee: Pedro Igor > Priority: Critical > Fix For: 1.1.0.Beta35 > > > The LDAP and JDBC realms have their own package as they have quite a few utility and configuration classes, the token realm only has one so I don't think we really need this one to be in it'own realm. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ELY-1031) Make the CredentialStore class final

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-1031?page=com.atlassian.jira.plugin.s... ] Darran Lofthouse updated ELY-1031: ---------------------------------- Fix Version/s: 1.1.0.Beta35 (was: 1.1.0.Beta34) > Make the CredentialStore class final > ------------------------------------ > > Key: ELY-1031 > URL: https://issues.jboss.org/browse/ELY-1031 > Project: WildFly Elytron > Issue Type: Enhancement > Components: Credential Store > Reporter: Darran Lofthouse > Assignee: Peter Skopek > Priority: Critical > Fix For: 1.1.0.Beta35 > > > Unless there is a reason this has not already be done the class should probably be made final to be sure extension is not possible. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ELY-1028) AuthenticationException should extend IOException

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-1028?page=com.atlassian.jira.plugin.s... ] Darran Lofthouse updated ELY-1028: ---------------------------------- Fix Version/s: 1.1.0.Beta35 (was: 1.1.0.Beta34) > AuthenticationException should extend IOException > ------------------------------------------------- > > Key: ELY-1028 > URL: https://issues.jboss.org/browse/ELY-1028 > Project: WildFly Elytron > Issue Type: Bug > Components: API / SPI > Reporter: David Lloyd > Assignee: David Lloyd > Fix For: 1.1.0.Beta35 > > > Remote authentications use I/O. AuthenticationException pertains solely to remote authentications. Therefore it (like SaslException and many others) should extend IOException, not GeneralSecurityException. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ELY-1029) Support clients that provide an optional CallbackHandler

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-1029?page=com.atlassian.jira.plugin.s... ] Darran Lofthouse updated ELY-1029: ---------------------------------- Fix Version/s: 1.1.0.Beta35 (was: 1.1.0.Beta34) > Support clients that provide an optional CallbackHandler > -------------------------------------------------------- > > Key: ELY-1029 > URL: https://issues.jboss.org/browse/ELY-1029 > Project: WildFly Elytron > Issue Type: Enhancement > Components: Authentication Client > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Priority: Blocker > Fix For: 1.1.0.Beta35 > > > Clients such as the WildFly CLI provide a CallbackHandler implementation in case it is needed and not as a sign that it must be used, i.e. the desired outcome is that if the information required can be obtained from the configuration then authentication proceeds without interaction with the end user. > Neither the CLI or the end user should be required to be fully aware of the underlying security configuration. > This is similar to web browser HTTP authentication where there is only an interaction with the user if actually required. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ELY-1045) Release WildFly Elytron 1.1.0.Beta34

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-1045?page=com.atlassian.jira.plugin.s... ] Darran Lofthouse resolved ELY-1045. ----------------------------------- Resolution: Done > Release WildFly Elytron 1.1.0.Beta34 > ------------------------------------ > > Key: ELY-1045 > URL: https://issues.jboss.org/browse/ELY-1045 > Project: WildFly Elytron > Issue Type: Release > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 1.1.0.Beta34 > > -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-8479) add jaxrs integration tests to check registration of resources in mgt model

by R Searls (JIRA)

R Searls created WFLY-8479: ------------------------------ Summary: add jaxrs integration tests to check registration of resources in mgt model Key: WFLY-8479 URL: https://issues.jboss.org/browse/WFLY-8479 Project: WildFly Issue Type: Task Components: REST Affects Versions: 11.0.0.Beta1 Reporter: R Searls Assignee: R Searls Priority: Trivial WFLY-8026 was about proper registration of jaxrs app resources in the mgt model. It is desirable to added integration tests to confirm registration is working with the various ways a REST app can be defined. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (DROOLS-1471) Unable to marshall a kieSession running in stream mode.

by Mario Fusco (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1471?page=com.atlassian.jira.plugi... ] Mario Fusco resolved DROOLS-1471. --------------------------------- Resolution: Rejected Serialization requires a snapshot of the session, so it can't be done while a fireUntilHalt is concurrently running. > Unable to marshall a kieSession running in stream mode. > ------------------------------------------------------- > > Key: DROOLS-1471 > URL: https://issues.jboss.org/browse/DROOLS-1471 > Project: Drools > Issue Type: Bug > Components: core engine > Affects Versions: 6.4.0.Final, 6.5.0.Final > Reporter: Manjunath S Paramesan > Assignee: Mario Fusco > > Runtime exceptions are thrown when Marshalling a KieSession in runtime. Please see the stack trace below: > java.util.concurrent.ExecutionException: java.lang.NullPointerException > at java.util.concurrent.FutureTask.report(FutureTask.java:122) > at java.util.concurrent.FutureTask.get(FutureTask.java:206) > at drools.tester.drools.marshallng.tester.ReproducerTest.test(ReproducerTest.java:91) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50) > at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) > at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47) > at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:24) > at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325) > at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78) > at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57) > at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290) > at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71) > at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288) > at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58) > at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268) > at org.junit.runners.ParentRunner.run(ParentRunner.java:363) > at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:86) > at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38) > at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:459) > at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:675) > at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:382) > at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:192) > Caused by: java.lang.NullPointerException > at org.drools.core.util.index.TupleList.removeFirst(TupleList.java:142) > at org.drools.core.phreak.RuleExecutor.getNextTuple(RuleExecutor.java:167) > at org.drools.core.phreak.RuleExecutor.fire(RuleExecutor.java:107) > at org.drools.core.phreak.RuleExecutor.evaluateNetworkAndFire(RuleExecutor.java:74) > at org.drools.core.common.DefaultAgenda.fireNextItem(DefaultAgenda.java:1007) > at org.drools.core.common.DefaultAgenda.fireLoop(DefaultAgenda.java:1350) > at org.drools.core.common.DefaultAgenda.fireUntilHalt(DefaultAgenda.java:1269) > at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireUntilHalt(StatefulKnowledgeSessionImpl.java:1345) > at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireUntilHalt(StatefulKnowledgeSessionImpl.java:1324) > at drools.tester.drools.marshallng.tester.ReproducerTest$1.run(ReproducerTest.java:73) > at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) > 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:745) -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira March 2017