[JBoss JIRA] (JBJCA-1207) config-properties should be "read-writable" by CLI
by Jooho Lee (JIRA)
Jooho Lee created JBJCA-1207:
--------------------------------
Summary: config-properties should be "read-writable" by CLI
Key: JBJCA-1207
URL: https://issues.jboss.org/browse/JBJCA-1207
Project: IronJacamar
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: AS
Affects Versions: 1.0.17.Final
Environment: EAP 6.1.0
RHEL 6.5
Reporter: Jooho Lee
Assignee: Jesper Pedersen
Using CLI, it is possible to control websphere message server but config-properties can not be modified or created because its access-type is read-only.
For example,
{code:title=CLI Command|borderStyle=solid}
/profile=MMPS-dev-03-profile/subsystem=resource-adapters/resource-adapter=wmq.jmsra.rar/admin-objects=FDSLPublishQueue/config-properties=baseQueueName:write-attribute(name=value,value=test)
{
"outcome" => "failed",
"failure-description" => "JBAS014639: Attribute value is not writable",
"rolled-back" => true
}
{code}
This is because the fact that baseQueueName(config-properties)' access-type is read-only but I don't see any reasons why this attritbute couldn't be writable.
Is there any reasons the attribute has to be read-only? otherwise, it should be read-write.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 9 months
[JBoss JIRA] (WFLY-3705) read-resource recursive-depth has no effect when recursive=true
by Arcadiy Ivanov (JIRA)
[ https://issues.jboss.org/browse/WFLY-3705?page=com.atlassian.jira.plugin.... ]
Arcadiy Ivanov commented on WFLY-3705:
--------------------------------------
Revised behavioral table:
{noformat}
Recursive | Recursive Depth | Behavior
T | U | Max depth recursion
F | U | No recursion
T | 0 | No recursion
F | 0 | No recursion
T | N, N > 0 | N-deep recursion
F | N, N > 0 | No recursion
U | U | No recursion
U | 0 | No recursion
U | N, N > 0 | N-deep recursion
{noformat}
> read-resource recursive-depth has no effect when recursive=true
> ---------------------------------------------------------------
>
> Key: WFLY-3705
> URL: https://issues.jboss.org/browse/WFLY-3705
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Documentation, Domain Management
> Affects Versions: 8.1.0.Final
> Environment: Linux aimobile-sm.servicemesh.com 3.15.7-200.fc20.x86_64 #1 SMP Mon Jul 28 18:50:26 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
> Reporter: Arcadiy Ivanov
> Assignee: Brian Stansberry
>
> The code inside ReadResourceHandler.doExecuteInternal(OperationContext context, ModelNode operation) goes as follows:
> {noformat}
> final int recursiveDepth = operation.get(ModelDescriptionConstants.RECURSIVE_DEPTH).asInt(0);
> final boolean recursive = recursiveDepth > 0 || operation.get(ModelDescriptionConstants.RECURSIVE).asBoolean(false);
> {noformat}
> The [documentation|https://docs.jboss.org/author/display/WFLY8/Global+operations] states:
> recursive-depth – (int) – The depth to which information about child resources should be included *if recursive is {{true}*. If not set, the depth will be unlimited; i.e. all descendant resources will be included.
> The logic, however, as implemented goes - either recursive-depth is greater than zero OR recursive is true.
> The proper implementation should be:
> {noformat}
> final int recursiveDepth = operation.get(ModelDescriptionConstants.RECURSIVE_DEPTH).asInt(0);
> final boolean recursive = operation.get(ModelDescriptionConstants.RECURSIVE).asBoolean(false) &&
> (!operation.get(ModelDescriptionConstants.RECURSIVE_DEPTH).isDefined() || recursiveDepth > 0);
> {noformat}
> The above snippet works as follows: recurs IF recursive is set AND (either recursive-depth is not defined OR recursive-depth is greater than 0).
>
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 9 months
[JBoss JIRA] (WFLY-3705) read-resource recursive-depth has no effect when recursive=true
by Arcadiy Ivanov (JIRA)
[ https://issues.jboss.org/browse/WFLY-3705?page=com.atlassian.jira.plugin.... ]
Arcadiy Ivanov commented on WFLY-3705:
--------------------------------------
FYI: The build system is unstable and produces non-deterministic results:
The last manually triggered build of this ended up with only one failure vs 2 failures in a previous identical build and 11 failures in the previous functionally-identical change:
java.lang.AssertionError: null
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.smoke.mgmt.BasicOperationsUnitTestCase.testReadResourceRecursiveDepth(BasicOperationsUnitTestCase.java:118)
> read-resource recursive-depth has no effect when recursive=true
> ---------------------------------------------------------------
>
> Key: WFLY-3705
> URL: https://issues.jboss.org/browse/WFLY-3705
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Documentation, Domain Management
> Affects Versions: 8.1.0.Final
> Environment: Linux aimobile-sm.servicemesh.com 3.15.7-200.fc20.x86_64 #1 SMP Mon Jul 28 18:50:26 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
> Reporter: Arcadiy Ivanov
> Assignee: Brian Stansberry
>
> The code inside ReadResourceHandler.doExecuteInternal(OperationContext context, ModelNode operation) goes as follows:
> {noformat}
> final int recursiveDepth = operation.get(ModelDescriptionConstants.RECURSIVE_DEPTH).asInt(0);
> final boolean recursive = recursiveDepth > 0 || operation.get(ModelDescriptionConstants.RECURSIVE).asBoolean(false);
> {noformat}
> The [documentation|https://docs.jboss.org/author/display/WFLY8/Global+operations] states:
> recursive-depth – (int) – The depth to which information about child resources should be included *if recursive is {{true}*. If not set, the depth will be unlimited; i.e. all descendant resources will be included.
> The logic, however, as implemented goes - either recursive-depth is greater than zero OR recursive is true.
> The proper implementation should be:
> {noformat}
> final int recursiveDepth = operation.get(ModelDescriptionConstants.RECURSIVE_DEPTH).asInt(0);
> final boolean recursive = operation.get(ModelDescriptionConstants.RECURSIVE).asBoolean(false) &&
> (!operation.get(ModelDescriptionConstants.RECURSIVE_DEPTH).isDefined() || recursiveDepth > 0);
> {noformat}
> The above snippet works as follows: recurs IF recursive is set AND (either recursive-depth is not defined OR recursive-depth is greater than 0).
>
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 9 months
[JBoss JIRA] (WFLY-2946) Improve 'cd' behavior in batch mode
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-2946?page=com.atlassian.jira.plugin.... ]
Brian Stansberry commented on WFLY-2946:
----------------------------------------
There might be other examples besides this one, but I can certainly imagine a case where a single 'add' would produce a resource tree instead of just a single resource. And the CLI wouldn't be able to know that would happen.
For example, a resource with child resources for various properties might take an optional 'properties' param in its add handler and if present just add all the children.
> Improve 'cd' behavior in batch mode
> -----------------------------------
>
> Key: WFLY-2946
> URL: https://issues.jboss.org/browse/WFLY-2946
> Project: WildFly
> Issue Type: Enhancement
> Security Level: Public(Everyone can see)
> Components: CLI
> Affects Versions: 8.0.0.Final
> Reporter: Brian Stansberry
> Assignee: Alexey Loubyansky
>
> See discussion at https://community.jboss.org/message/858108#858108 for background.
> The problem is the 'cd' behavior discussed in my comment. A 'cd' in batch mode seems to have triggered the CLI validating the location (or some other op against the address), which fails since the previous batch step that created the location hasn't executed.
> Would it be better to simply accept the address in batch mode, or somehow be a bit smarter?
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 9 months
[JBoss JIRA] (WFLY-2946) Improve 'cd' behavior in batch mode
by Alexey Loubyansky (JIRA)
[ https://issues.jboss.org/browse/WFLY-2946?page=com.atlassian.jira.plugin.... ]
Alexey Loubyansky commented on WFLY-2946:
-----------------------------------------
Could there be operations called other than 'add' that (theoretically at least) could create new paths?
For the CLI (or any other tool) to be sure about its assumptions, it needs hints from the operation description, i.e. the metadata.
I think, I don't mind --no-validation. One thing to take into account is that the name of the argument will be a reserved argument CLI name, so commands will not be allowed to have an argument with that name but a different meaning.
> Improve 'cd' behavior in batch mode
> -----------------------------------
>
> Key: WFLY-2946
> URL: https://issues.jboss.org/browse/WFLY-2946
> Project: WildFly
> Issue Type: Enhancement
> Security Level: Public(Everyone can see)
> Components: CLI
> Affects Versions: 8.0.0.Final
> Reporter: Brian Stansberry
> Assignee: Alexey Loubyansky
>
> See discussion at https://community.jboss.org/message/858108#858108 for background.
> The problem is the 'cd' behavior discussed in my comment. A 'cd' in batch mode seems to have triggered the CLI validating the location (or some other op against the address), which fails since the previous batch step that created the location hasn't executed.
> Would it be better to simply accept the address in batch mode, or somehow be a bit smarter?
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 9 months
[JBoss JIRA] (JGRP-1871) NPEs due to non-volatile Protocol variables
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/JGRP-1871?page=com.atlassian.jira.plugin.... ]
Paul Ferraro commented on JGRP-1871:
------------------------------------
That said, it may be worth addressing this anyway. It one were to make runtime modifications to a given protocol property, unless that property is volatile, or some other memory synchronization is in place, its visibility to other threads is not guaranteed by the java memory model.
> NPEs due to non-volatile Protocol variables
> -------------------------------------------
>
> Key: JGRP-1871
> URL: https://issues.jboss.org/browse/JGRP-1871
> Project: JGroups
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 3.4.5, 3.5
> Reporter: Paul Ferraro
> Assignee: Paul Ferraro
>
> In WildFly a given channel is created in one thread, but is potentially started in a different thread. Unfortunately, many of the protocol variables that are set during Protocol.init() are non-volatile. This can cause unexpected behavior as seen in WFLY-3727.
> To ensure clean initialization for multi-threaded environments like WF, all non-final variables within every JGroups' Protocol should be volatile.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 9 months
[JBoss JIRA] (JGRP-1871) NPEs due to non-volatile Protocol variables
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/JGRP-1871?page=com.atlassian.jira.plugin.... ]
Paul Ferraro commented on JGRP-1871:
------------------------------------
"What's the time between creating the channel and calling connect() on it ?"
I mean new JChannel(...) vs channel.connect(...). In WildFly I have one service that creates and closes a channel, and a child service that connects and disconnects a channel. This way a single channel instance can be connected, disconnected, and reconnected without having to destroy and recreate it. These 2 services are started by different threads and are completely managed by WildFly's service container.
Given the right architecture, I'm sure that this could be reproduced fairly easily.
Traditionally, both Infinispan and JBoss AS will create and connect a channel in the same thread. The separation of the two is unique to WF8.
My workaround, which so far seems to work, is here:
https://github.com/pferraro/wildfly/commit/99d18fffcae310dfc69c6d6abfe01f...
I'm relying on WF's ServiceContainer itself to perform synchronization of the thread memory spaces. I haven't seen this issue in our CI jobs since this fix went into place.
> NPEs due to non-volatile Protocol variables
> -------------------------------------------
>
> Key: JGRP-1871
> URL: https://issues.jboss.org/browse/JGRP-1871
> Project: JGroups
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 3.4.5, 3.5
> Reporter: Paul Ferraro
> Assignee: Paul Ferraro
>
> In WildFly a given channel is created in one thread, but is potentially started in a different thread. Unfortunately, many of the protocol variables that are set during Protocol.init() are non-volatile. This can cause unexpected behavior as seen in WFLY-3727.
> To ensure clean initialization for multi-threaded environments like WF, all non-final variables within every JGroups' Protocol should be volatile.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 9 months
[JBoss JIRA] (WFLY-3697) Custom http handlers support
by Nicky Mølholm (JIRA)
[ https://issues.jboss.org/browse/WFLY-3697?page=com.atlassian.jira.plugin.... ]
Nicky Mølholm commented on WFLY-3697:
-------------------------------------
I have tested the custom-handlers branch customer filter support - using my own global module with a custom httphandler in it. Semantically a "filter" in the wildfly/undertow integration.
It works great and is easy to use - really good job !
I tested the priority support too. Added a breakpoint in my handler method and inspected the stack trace. It affected the filters that was declared in my standalone xml config - but I had to explicitly add a priority to them also. Otherwise, my custom filter is at the back of the chain.
I saw some other filters in the chain - that are implicitly added to the inbound calls. It would be cool if I could place my filter in front of them - or in the midst. But let us just call it a wish list ;)
> Custom http handlers support
> ----------------------------
>
> Key: WFLY-3697
> URL: https://issues.jboss.org/browse/WFLY-3697
> Project: WildFly
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Web (Undertow)
> Reporter: Tomaz Cerar
> Assignee: Tomaz Cerar
> Fix For: 9.0.0.Beta1
>
>
> We need support for custom handlers & filters
> something along the lines
> {code:xml}
> <handlers>
> <handler name="myhandler" class="full.class.name" module"full.module.name" />
> <handlers>
> <filters>
> <filter name="myfilter" class="full.class.name" module"full.module.name" />
> <filters>
> {code}
> There should also be a way to pass in arbitrary config options
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 9 months
[JBoss JIRA] (JBASMP-71) JBoss Maven Plugin fails deploy in domain mode if one server is stopped
by Jorge Solorzano (JIRA)
Jorge Solorzano created JBASMP-71:
-------------------------------------
Summary: JBoss Maven Plugin fails deploy in domain mode if one server is stopped
Key: JBASMP-71
URL: https://issues.jboss.org/browse/JBASMP-71
Project: JBoss AS Maven Plugins
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: deploy
Affects Versions: 7.5.Final
Reporter: Jorge Solorzano
Assignee: James Perkins
I have a cluster in domain mode and configured my project to do the deploy on a server group (jboss-as:deploy), but if I have one server stopped the deploy fails.
I think it should do the deploy even if all servers are stopped, after all the master is the one who get the deploy and when the servers come back online then the master sends the content to the servers.
If I do the deploy directly from the manangement console it don't care if all servers (in the server group) are stopped.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 9 months
[JBoss JIRA] (ELY-41) Password Recognition and Parsing Framework
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/ELY-41?page=com.atlassian.jira.plugin.sys... ]
Darran Lofthouse updated ELY-41:
--------------------------------
Description:
I don't think having a single PasswordUtils that recognises and parses all password types is going to be a good idea long term - I think a lot of the responsibility for what is supported needs to come from the realm.
A scenario I am thinking is an LDAP server is configured to support clear text passwords, that server verifies the strength of the password before letting a user set it - this could be circumvented by setting the password value to something we would parse as one of the other password types. The problem is the user could just hash 'password' - this would pass the LDAP servers dictionary attack check.
The second issue is that different formats could be realm specific, e.g. LDAP supports trival digests in formats slightly different to those we already support.
One idea I am starting to think about it a password parser that a realm can build up with a set of supported password types, working on LDAP it is apparent realms potentially need configuration for the credential types they will claim to support before the RealmIdentity is identified so not a major deviation from the work I am already finding necessary.
Looking at the current PasswordUtils.java the following public utility methods are exposed: -
{code}
org.wildfly.security.password.PasswordUtils
org.wildfly.security.password.PasswordUtils.identifyAlgorithm(char[])
org.wildfly.security.password.PasswordUtils.identifyAlgorithm(String)
org.wildfly.security.password.PasswordUtils.getCryptStringChars(PasswordSpec)
org.wildfly.security.password.PasswordUtils.getCryptString(PasswordSpec)
org.wildfly.security.password.PasswordUtils.parseCryptString(String)
org.wildfly.security.password.PasswordUtils.parseCryptString(char[])
{code}
>From the perspective of a realm the primary task I am trying to achieve is to take a password string and convert it to a PasswordSpec. Algorithm identification seems to be used primarily by tests, not convinced it is justified in an API.
was:
I don't think having a single PasswordUtils that recognises and parses all password types is going to be a good idea long term - I think a lot of the responsibility for what is supported needs to come from the realm.
A scenario I am thinking is an LDAP server is configured to support clear text passwords, that server verifies the strength of the password before letting a user set it - this could be circumvented by setting the password value to something we would parse as one of the other password types. The problem is the user could just hash 'password' - this would pass the LDAP servers dictionary attack check.
The second issue is that different formats could be realm specific, e.g. LDAP supports trival digests in formats slightly different to those we already support.
One idea I am starting to think about it a password parser that a realm can build up with a set of supported password types, working on LDAP it is apparent realms potentially need configuration for the credential types they will claim to support before the RealmIdentity is identified so not a major deviation from the work I am already finding necessary.
Looking at the current PasswordUtils.java the following public utility methods are exposed: -
{code}
org.wildfly.security.password.PasswordUtils
org.wildfly.security.password.PasswordUtils.identifyAlgorithm(char[])
org.wildfly.security.password.PasswordUtils.identifyAlgorithm(String)
org.wildfly.security.password.PasswordUtils.getCryptStringChars(PasswordSpec)
org.wildfly.security.password.PasswordUtils.getCryptString(PasswordSpec)
org.wildfly.security.password.PasswordUtils.parseCryptString(String)
org.wildfly.security.password.PasswordUtils.parseCryptString(char[])
{code}
>From the perspective of a realm the primary task I am trying to achieve is to take a password string and convert it to a PasswordSpec - algorithm identification could be internal.
> Password Recognition and Parsing Framework
> ------------------------------------------
>
> Key: ELY-41
> URL: https://issues.jboss.org/browse/ELY-41
> Project: WildFly Elytron
> Issue Type: Task
> Security Level: Public(Everyone can see)
> Components: API / SPI
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Fix For: 1.0.0.Beta1
>
>
> I don't think having a single PasswordUtils that recognises and parses all password types is going to be a good idea long term - I think a lot of the responsibility for what is supported needs to come from the realm.
> A scenario I am thinking is an LDAP server is configured to support clear text passwords, that server verifies the strength of the password before letting a user set it - this could be circumvented by setting the password value to something we would parse as one of the other password types. The problem is the user could just hash 'password' - this would pass the LDAP servers dictionary attack check.
> The second issue is that different formats could be realm specific, e.g. LDAP supports trival digests in formats slightly different to those we already support.
> One idea I am starting to think about it a password parser that a realm can build up with a set of supported password types, working on LDAP it is apparent realms potentially need configuration for the credential types they will claim to support before the RealmIdentity is identified so not a major deviation from the work I am already finding necessary.
> Looking at the current PasswordUtils.java the following public utility methods are exposed: -
> {code}
> org.wildfly.security.password.PasswordUtils
> org.wildfly.security.password.PasswordUtils.identifyAlgorithm(char[])
> org.wildfly.security.password.PasswordUtils.identifyAlgorithm(String)
> org.wildfly.security.password.PasswordUtils.getCryptStringChars(PasswordSpec)
> org.wildfly.security.password.PasswordUtils.getCryptString(PasswordSpec)
> org.wildfly.security.password.PasswordUtils.parseCryptString(String)
> org.wildfly.security.password.PasswordUtils.parseCryptString(char[])
> {code}
> From the perspective of a realm the primary task I am trying to achieve is to take a password string and convert it to a PasswordSpec. Algorithm identification seems to be used primarily by tests, not convinced it is justified in an API.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 9 months