[JBoss JIRA] (WFLY-3955) Non-persistent overlay gets persisted later
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-3955?page=com.atlassian.jira.plugin.... ]
Stuart Douglas resolved WFLY-3955.
----------------------------------
Resolution: Rejected
The PERSISTENT flag is only supported for deployments. It is not supported for any other operations.
> Non-persistent overlay gets persisted later
> -------------------------------------------
>
> Key: WFLY-3955
> URL: https://issues.jboss.org/browse/WFLY-3955
> Project: WildFly
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 8.1.0.Final, 9.0.0.Alpha1
> Reporter: Stan Silvert
> Assignee: Stuart Douglas
>
> In an add handler at startup, I have code that creates a non-persistent overlay like this:
> {code}
> private void addOverlay(OperationContext context) throws OperationFailedException {
> PathAddress overlayAddress = PathAddress.pathAddress(PathElement.pathElement(DEPLOYMENT_OVERLAY, overlayName));
> ModelNode addOp = Util.createOperation(ADD, overlayAddress);
> addOp.get(PERSISTENT).set(false);
> context.addStep(addOp, getAddHandler(context, overlayAddress), OperationContext.Stage.MODEL);
> }
> private OperationStepHandler getAddHandler(OperationContext context, PathAddress address) {
> ImmutableManagementResourceRegistration rootResourceRegistration = context.getRootResourceRegistration();
> return rootResourceRegistration.getOperationHandler(address, ADD);
> }
> {code}
> addOverlay() is called from the populateModel() method of my Add Handler. This works fine and creates the overlay without persisting to standalone.xml.
> However, if I deploy any WAR then the overlay is written out to standalone.xml.
> I can get you some better test code if you need it later.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years
[JBoss JIRA] (WFLY-3955) Non-persistent overlay gets persisted later
by Stan Silvert (JIRA)
[ https://issues.jboss.org/browse/WFLY-3955?page=com.atlassian.jira.plugin.... ]
Stan Silvert updated WFLY-3955:
-------------------------------
Description:
In an add handler at startup, I have code that creates a non-persistent overlay like this:
{code}
private void addOverlay(OperationContext context) throws OperationFailedException {
PathAddress overlayAddress = PathAddress.pathAddress(PathElement.pathElement(DEPLOYMENT_OVERLAY, overlayName));
ModelNode addOp = Util.createOperation(ADD, overlayAddress);
addOp.get(PERSISTENT).set(false);
context.addStep(addOp, getAddHandler(context, overlayAddress), OperationContext.Stage.MODEL);
}
private OperationStepHandler getAddHandler(OperationContext context, PathAddress address) {
ImmutableManagementResourceRegistration rootResourceRegistration = context.getRootResourceRegistration();
return rootResourceRegistration.getOperationHandler(address, ADD);
}
{code}
addOverlay() is called from the populateModel() method of my Add Handler. This works fine and creates the overlay without persisting to standalone.xml.
However, if I deploy any WAR then the overlay is written out to standalone.xml.
I can get you some better test code if you need it later.
was:
In an add handler at startup, I have code that creates a non-persistent overlay like this:
{code}
private void addOverlay(OperationContext context) throws OperationFailedException {
PathAddress overlayAddress = PathAddress.pathAddress(PathElement.pathElement(DEPLOYMENT_OVERLAY, overlayName));
ModelNode addOp = Util.createOperation(ADD, overlayAddress);
addOp.get(PERSISTENT).set(false);
context.addStep(addOp, getAddHandler(context, overlayAddress), OperationContext.Stage.MODEL);
}
private OperationStepHandler getAddHandler(OperationContext context, PathAddress address) {
ImmutableManagementResourceRegistration rootResourceRegistration = context.getRootResourceRegistration();
return rootResourceRegistration.getOperationHandler(address, ADD);
}
{code}
This works fine and creates the overlay without persisting to standalone.xml.
However, if I deploy any WAR then the overlay is written out to standalone.xml.
I can get you some better test code if you need it later.
> Non-persistent overlay gets persisted later
> -------------------------------------------
>
> Key: WFLY-3955
> URL: https://issues.jboss.org/browse/WFLY-3955
> Project: WildFly
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 8.1.0.Final, 9.0.0.Alpha1
> Reporter: Stan Silvert
> Assignee: Stuart Douglas
>
> In an add handler at startup, I have code that creates a non-persistent overlay like this:
> {code}
> private void addOverlay(OperationContext context) throws OperationFailedException {
> PathAddress overlayAddress = PathAddress.pathAddress(PathElement.pathElement(DEPLOYMENT_OVERLAY, overlayName));
> ModelNode addOp = Util.createOperation(ADD, overlayAddress);
> addOp.get(PERSISTENT).set(false);
> context.addStep(addOp, getAddHandler(context, overlayAddress), OperationContext.Stage.MODEL);
> }
> private OperationStepHandler getAddHandler(OperationContext context, PathAddress address) {
> ImmutableManagementResourceRegistration rootResourceRegistration = context.getRootResourceRegistration();
> return rootResourceRegistration.getOperationHandler(address, ADD);
> }
> {code}
> addOverlay() is called from the populateModel() method of my Add Handler. This works fine and creates the overlay without persisting to standalone.xml.
> However, if I deploy any WAR then the overlay is written out to standalone.xml.
> I can get you some better test code if you need it later.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years
[JBoss JIRA] (WFLY-3955) Non-persistent overlay gets persisted later
by Stan Silvert (JIRA)
Stan Silvert created WFLY-3955:
----------------------------------
Summary: Non-persistent overlay gets persisted later
Key: WFLY-3955
URL: https://issues.jboss.org/browse/WFLY-3955
Project: WildFly
Issue Type: Bug
Components: Domain Management
Affects Versions: 9.0.0.Alpha1, 8.1.0.Final
Reporter: Stan Silvert
Assignee: Stuart Douglas
In an add handler at startup, I have code that creates a non-persistent overlay like this:
{code}
private void addOverlay(OperationContext context) throws OperationFailedException {
PathAddress overlayAddress = PathAddress.pathAddress(PathElement.pathElement(DEPLOYMENT_OVERLAY, overlayName));
ModelNode addOp = Util.createOperation(ADD, overlayAddress);
addOp.get(PERSISTENT).set(false);
context.addStep(addOp, getAddHandler(context, overlayAddress), OperationContext.Stage.MODEL);
}
private OperationStepHandler getAddHandler(OperationContext context, PathAddress address) {
ImmutableManagementResourceRegistration rootResourceRegistration = context.getRootResourceRegistration();
return rootResourceRegistration.getOperationHandler(address, ADD);
}
{code}
This works fine and creates the overlay without persisting to standalone.xml.
However, if I deploy any WAR then the overlay is written out to standalone.xml.
I can get you some better test code if you need it later.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years
[JBoss JIRA] (WFLY-1067) Integrate JGroups with core AS security infrastructure
by Richard Achmatowicz (JIRA)
[ https://issues.jboss.org/browse/WFLY-1067?page=com.atlassian.jira.plugin.... ]
Richard Achmatowicz commented on WFLY-1067:
-------------------------------------------
David, Brian, thanks for your comments.
We (clustering) are setting up a meeting with Darran to discuss these issues and also those of mod cluster. Also, have touched base with the security team (Boleslsaw Davidowicz) to stay in closer contact in future with the security team.
> Integrate JGroups with core AS security infrastructure
> ------------------------------------------------------
>
> Key: WFLY-1067
> URL: https://issues.jboss.org/browse/WFLY-1067
> Project: WildFly
> Issue Type: Feature Request
> Components: Clustering, Security
> Reporter: Brian Stansberry
> Assignee: Richard Achmatowicz
>
> Container task for better integrating JGroups security with overall AS security. The basic concept is the various security aware aspects of JGroups will expose an SPI, and the AS can create implementations of those SPIs that integrate with the AS security realms. The AS JGroups subsystem will inject the implementation into the JGroups runtime components.
> Subtasks are for the various aspects. These can be done separately but a common overall design should be created to ensure a consistent approach is taken.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years
[JBoss JIRA] (ELY-92) StringPrep fails on Windows
by David Lloyd (JIRA)
David Lloyd created ELY-92:
------------------------------
Summary: StringPrep fails on Windows
Key: ELY-92
URL: https://issues.jboss.org/browse/ELY-92
Project: WildFly Elytron
Issue Type: Bug
Components: Utils
Environment: Windows
Reporter: David Lloyd
Fix For: 1.0.0.Beta1
StringPrep completely fails in every way on Windows, maybe due to differences in JDK's Normalizer. Investigate.
This is probably the root cause:
{noformat}
org.junit.ComparisonFailure: expected:<a[Å]b> but was:<a[Ã…]b>
at org.junit.Assert.assertEquals(Assert.java:115)
at org.junit.Assert.assertEquals(Assert.java:144)
at org.wildfly.security.sasl.test.StringPrepTest.testNFKC(StringPrepTest.java:218)
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.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:264)
at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153)
at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:124)
at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:200)
at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:153)
at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103)
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years
[JBoss JIRA] (ELY-36) Server Authentication Context Lifecycle
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/ELY-36?page=com.atlassian.jira.plugin.sys... ]
David Lloyd updated ELY-36:
---------------------------
Summary: Server Authentication Context Lifecycle (was: Authentication Context Lifecycle)
> Server Authentication Context Lifecycle
> ---------------------------------------
>
> Key: ELY-36
> URL: https://issues.jboss.org/browse/ELY-36
> Project: WildFly Elytron
> Issue Type: Task
> Components: API / SPI
> Reporter: Darran Lofthouse
> Fix For: 1.0.0.Beta1
>
>
> The authentication context is used with a sequence of calls during the authentication process, this task is to look into how we can apply a lifecycle to that so that appropriate clean up can be performed.
> This could be closely related to ELY-35 which specifically looks at outcome notification.
> When considering a lifecycle I think we have two key events to think about, the most natural one being once the authentication process is complete regardless of outcome - however should also consider intermediate responses going back to the client - we do not want to be holding onto expensive resources once we pass control back to the client as that risks a Dos based attack.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years