[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 could be internal.
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.
> 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 could be internal.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 11 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 reassigned ELY-41:
-----------------------------------
Assignee: Darran Lofthouse
> 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.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 11 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:
----------------------------------------
I think that's reasonable. The only alternative I can think of is hacks like analyzing the batch for add ops and guessing that those mean the 'cd' would be valid. And that would have tons of holes. This could be more useful in general too, e.g. outside a batch.
I think the name of the argument is important, and limiting it to cd at first is a good idea. Those two points are a bit contradictory, because a name that's good for the 'cd' command only may be poor if we later expand the use.
Would simply "--no-validation" work, or are there cases (besides cd) where we need to do some validation no matter what?
I could see this even being useful for low-level operations, basically turning off the jboss-cli.xml "validate-operation-requests" setting for one op.
> 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, 11 months
[JBoss JIRA] (DROOLS-568) Module dependencies missing from brms and bpms layers to support remote runtime engines
by David Ward (JIRA)
[ https://issues.jboss.org/browse/DROOLS-568?page=com.atlassian.jira.plugin... ]
David Ward commented on DROOLS-568:
-----------------------------------
Working on testing this now. Thanks Jeremy.
> Module dependencies missing from brms and bpms layers to support remote runtime engines
> ---------------------------------------------------------------------------------------
>
> Key: DROOLS-568
> URL: https://issues.jboss.org/browse/DROOLS-568
> Project: Drools
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 6.1.0.CR2
> Environment: JBoss EAP 6.3
> Reporter: David Ward
> Assignee: Jeremy Lindop
>
> Regarding artifacts:
> org.kie:kie-eap-distributions-brms-layer::6.1.0.CR2
> org.kie:kie-eap-integration-brms:brms-layer:6.0.2-redhat-7
> org.kie:kie-eap-distributions-bpms-layer::6.1.0.CR2
> org.kie:kie-eap-integration-bpms:bpms-layer:6.0.2-redhat-7
> And these modules:
> modules/system/layers/brms/org/kie/main/module.xml
> modules/system/layers/bpms/org/kie/main/module.xml
> There are missing libraries needed to support the remote rest and jms runtime engine factories (and associated builders):
> org.kie.services.client.api.RemoteJmsRuntimeEngineFactory/Builder
> org.kie.services.client.api.RemoteRestRuntimeEngineFactory/Builder
> Including at least these resource-roots:
> org.kie.remote:kie-services-client
> org.kie.remote:kie-services-jaxb
> and this dependency module:
> org.jboss.resteasy:resteasy-jackson-provider
> (Although still validating other possible dependencies.)
> Without having all the necessary libraries included and dependencies linked, using the RemoteRuntimeEngines via kie-services-client is not possible.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 11 months
[JBoss JIRA] (DROOLS-568) Module dependencies missing from brms and bpms layers to support remote runtime engines
by Jeremy Lindop (JIRA)
[ https://issues.jboss.org/browse/DROOLS-568?page=com.atlassian.jira.plugin... ]
Jeremy Lindop commented on DROOLS-568:
--------------------------------------
Fixed on 6.0.x branch by creating a new org.kie.remote module for the bpms layer.
https://github.com/droolsjbpm/kie-wb-distributions/commit/df1a24c297bc76d...
> Module dependencies missing from brms and bpms layers to support remote runtime engines
> ---------------------------------------------------------------------------------------
>
> Key: DROOLS-568
> URL: https://issues.jboss.org/browse/DROOLS-568
> Project: Drools
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 6.1.0.CR2
> Environment: JBoss EAP 6.3
> Reporter: David Ward
> Assignee: Jeremy Lindop
>
> Regarding artifacts:
> org.kie:kie-eap-distributions-brms-layer::6.1.0.CR2
> org.kie:kie-eap-integration-brms:brms-layer:6.0.2-redhat-7
> org.kie:kie-eap-distributions-bpms-layer::6.1.0.CR2
> org.kie:kie-eap-integration-bpms:bpms-layer:6.0.2-redhat-7
> And these modules:
> modules/system/layers/brms/org/kie/main/module.xml
> modules/system/layers/bpms/org/kie/main/module.xml
> There are missing libraries needed to support the remote rest and jms runtime engine factories (and associated builders):
> org.kie.services.client.api.RemoteJmsRuntimeEngineFactory/Builder
> org.kie.services.client.api.RemoteRestRuntimeEngineFactory/Builder
> Including at least these resource-roots:
> org.kie.remote:kie-services-client
> org.kie.remote:kie-services-jaxb
> and this dependency module:
> org.jboss.resteasy:resteasy-jackson-provider
> (Although still validating other possible dependencies.)
> Without having all the necessary libraries included and dependencies linked, using the RemoteRuntimeEngines via kie-services-client is not possible.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 11 months
[JBoss JIRA] (JBMETA-377) NullPointerException occurs during parsing web.xml with missing context param-name
by Jay Kumar SenSharma (JIRA)
[ https://issues.jboss.org/browse/JBMETA-377?page=com.atlassian.jira.plugin... ]
Jay Kumar SenSharma commented on JBMETA-377:
--------------------------------------------
Sent a new Pull request:: https://github.com/jboss/metadata/pull/68
Which causes the appropriate parsing message to be displayed during deployment rather than throwing NullPointerException:
{code}
Caused by: javax.xml.stream.XMLStreamException: ParseError at [row,col]:[16,7]
Message: param-name element missing in context-param
at org.jboss.metadata.parser.ee.ParamValueMetaDataParser.parse(ParamValueMetaDataParser.java:90)
at org.jboss.metadata.parser.servlet.WebCommonMetaDataParser.parse(WebCommonMetaDataParser.java:70)
at org.jboss.metadata.parser.servlet.WebMetaDataParser.parse(WebMetaDataParser.java:184)
at org.jboss.metadata.parser.servlet.WebMetaDataParser.parse(WebMetaDataParser.java:57)
at org.wildfly.extension.undertow.deployment.WebParsingDeploymentProcessor.deploy(WebParsingDeploymentProcessor.java:93)
... 6 more
{code}
> NullPointerException occurs during parsing web.xml with missing context param-name
> ----------------------------------------------------------------------------------
>
> Key: JBMETA-377
> URL: https://issues.jboss.org/browse/JBMETA-377
> Project: JBoss Metadata
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: common
> Affects Versions: 8.0.0.Final
> Reporter: Jay Kumar SenSharma
>
> [Opening this issue to track down the issue specific to jboss metadata]
> While deploying a WAR, If the web.xml file is used which has context <param-value> defined, However it has missing <param-name> then it causes NullPointerException.
> Refer to for more details: https://issues.jboss.org/browse/WFLY-3699
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 11 months
[JBoss JIRA] (WFLY-3699) Missing param-name in a web.xml causes NullPointerException during deployment
by Jay Kumar SenSharma (JIRA)
[ https://issues.jboss.org/browse/WFLY-3699?page=com.atlassian.jira.plugin.... ]
Jay Kumar SenSharma updated WFLY-3699:
--------------------------------------
Git Pull Request: https://github.com/jboss/metadata/pull/68 (was: https://github.com/jboss/metadata/pull/65)
> Missing param-name in a web.xml causes NullPointerException during deployment
> ------------------------------------------------------------------------------
>
> Key: WFLY-3699
> URL: https://issues.jboss.org/browse/WFLY-3699
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: JSF, Web (Undertow)
> Affects Versions: 9.0.0.Beta1
> Reporter: Jay Kumar SenSharma
> Assignee: Farah Juma
> Attachments: ContextParamNullDemo.war
>
>
> - While deploying a WAR, If the web.xml file is used which has context <param-value> defined, However it has missing <param-name> then it causes NullPointerException as following:
> {code}
> 00:12:09,583 INFO [org.jboss.as.server.deployment] (MSC service thread 1-6) WFLYSRV0027: Starting deployment of "ContextParamNullDemo.war" (runtime-name: "ContextParamNullDemo.war")
> 00:12:09,591 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-7) MSC000001: Failed to start service jboss.deployment.unit."ContextParamNullDemo.war".PARSE: org.jboss.msc.service.StartException in service jboss.deployment.unit."ContextParamNullDemo.war".PARSE: WFLYSRV0153: Failed to process phase PARSE of deployment "ContextParamNullDemo.war"
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:163) [wildfly-server-9.0.0.Alpha1-SNAPSHOT.jar:9.0.0.Alpha1-SNAPSHOT]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) [jboss-msc-1.2.2.Final.jar:1.2.2.Final]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) [jboss-msc-1.2.2.Final.jar:1.2.2.Final]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_51]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_51]
> at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_51]
> Caused by: java.lang.NullPointerException
> at org.jboss.as.jsf.deployment.JSFVersionProcessor.deploy(JSFVersionProcessor.java:91)
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:156) [wildfly-server-9.0.0.Alpha1-SNAPSHOT.jar:9.0.0.Alpha1-SNAPSHOT]
> ... 5 more
> 00:12:09,598 ERROR [org.jboss.as.controller.management-operation] (DeploymentScanner-threads - 1) WFLYCTL0013: Operation ("deploy") failed - address: ([("deployment" => "ContextParamNullDemo.war")]) - failure description: {"WFLYCTL0080: Failed services" => {"jboss.deployment.unit.\"ContextParamNullDemo.war\".PARSE" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.\"ContextParamNullDemo.war\".PARSE: WFLYSRV0153: Failed to process phase PARSE of deployment \"ContextParamNullDemo.war\"
> Caused by: java.lang.NullPointerException"}}
> {code}
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 11 months
[JBoss JIRA] (JBMETA-377) NullPointerException occurs during parsing web.xml with missing context param-name
by Jay Kumar SenSharma (JIRA)
[ https://issues.jboss.org/browse/JBMETA-377?page=com.atlassian.jira.plugin... ]
Jay Kumar SenSharma updated JBMETA-377:
---------------------------------------
Comment: was deleted
(was: Sent a new Pull request for this issue:
https://github.com/jboss/metadata/pull/65
With this fix it should report the actual cause of the deployment failure as following:
{code}
Caused by: javax.xml.stream.XMLStreamException: ParseError at [row,col]:[16,7]
Message: <param-name> is not defined properly inside the web.xml
at org.jboss.metadata.parser.ee.ParamValueMetaDataParser.parse(ParamValueMetaDataParser.java:90)
at org.jboss.metadata.parser.servlet.WebCommonMetaDataParser.parse(WebCommonMetaDataParser.java:70)
at org.jboss.metadata.parser.servlet.WebMetaDataParser.parse(WebMetaDataParser.java:184)
at org.jboss.metadata.parser.servlet.WebMetaDataParser.parse(WebMetaDataParser.java:57)
{code}
)
> NullPointerException occurs during parsing web.xml with missing context param-name
> ----------------------------------------------------------------------------------
>
> Key: JBMETA-377
> URL: https://issues.jboss.org/browse/JBMETA-377
> Project: JBoss Metadata
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: common
> Affects Versions: 8.0.0.Final
> Reporter: Jay Kumar SenSharma
>
> [Opening this issue to track down the issue specific to jboss metadata]
> While deploying a WAR, If the web.xml file is used which has context <param-value> defined, However it has missing <param-name> then it causes NullPointerException.
> Refer to for more details: https://issues.jboss.org/browse/WFLY-3699
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 11 months
[JBoss JIRA] (JBMETA-378) Presence of <servlet-name> and <url-pattern> is not validated for <servlet-mapping> inside the web.xml
by Jay Kumar SenSharma (JIRA)
[ https://issues.jboss.org/browse/JBMETA-378?page=com.atlassian.jira.plugin... ]
Jay Kumar SenSharma commented on JBMETA-378:
--------------------------------------------
Sent new pull request: https://github.com/jboss/metadata/pull/67
Which will display meaning full message while parsing the deployment descriptor, and will display following kind of message rather than throwing NullPointerException.
{code}
Caused by: javax.xml.stream.XMLStreamException: ParseError at [row,col]:[16,2]
Message: servlet-name element missing in servlet-mapping
at org.jboss.metadata.parser.servlet.ServletMappingMetaDataParser.parse(ServletMappingMetaDataParser.java:85)
at org.jboss.metadata.parser.servlet.WebCommonMetaDataParser.parse(WebCommonMetaDataParser.java:110)
at org.jboss.metadata.parser.servlet.WebMetaDataParser.parse(WebMetaDataParser.java:184)
at org.jboss.metadata.parser.servlet.WebMetaDataParser.parse(WebMetaDataParser.java:57)
at org.wildfly.extension.undertow.deployment.WebParsingDeploymentProcessor.deploy(WebParsingDeploymentProcessor.java:93)
... 6 more
{code}
> Presence of <servlet-name> and <url-pattern> is not validated for <servlet-mapping> inside the web.xml
> ------------------------------------------------------------------------------------------------------
>
> Key: JBMETA-378
> URL: https://issues.jboss.org/browse/JBMETA-378
> Project: JBoss Metadata
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: web
> Affects Versions: 8.0.1.Final
> Reporter: Jay Kumar SenSharma
> Assignee: Jean-Frederic Clere
>
> - JBoss Metadata APIs do not validate if the <servlet-mapping> tag has valid mappings or not. This should have been handled properly.
> *Example:* If following kind of web.xml based application is deployed on WildFly9 then
> {code}
> <?xml version="1.0"?>
> <web-app xmlns="http://java.sun.com/xml/ns/javaee"
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd"
> version="3.0">
> <servlet>
> <servlet-name>MyServlet</servlet-name>
> <servlet-class>servlets.MyServlet</servlet-class>
> <load-on-startup>1</load-on-startup>
> </servlet>
> <servlet-mapping>
> <servlet-name>MyServlet</servlet-name>
> <!--url-pattern></url-pattern--> <!-- NOTICE url-pattern-tag is missing here -->
> </servlet-mapping>
> </web-app>
> {code}
> - With the above kind of web.xml a NullPointerException is encountered during deployment.
> {code}
> 15:50:20,207 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-7) MSC000001: Failed to start service jboss.undertow.deployment.default-server.default-host./ContextParamNullDemo.UndertowDeploymentInfoService: org.jboss.msc.service.StartException in service jboss.undertow.deployment.default-server.default-host./ContextParamNullDemo.UndertowDeploymentInfoService: Failed to start service
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1904) [jboss-msc-1.2.2.Final.jar:1.2.2.Final]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_51]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_51]
> at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_51]
> Caused by: java.lang.NullPointerException
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService.handleServletMappings(UndertowDeploymentInfoService.java:910)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService.createServletConfig(UndertowDeploymentInfoService.java:656)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService.start(UndertowDeploymentInfoService.java:252)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) [jboss-msc-1.2.2.Final.jar:1.2.2.Final]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) [jboss-msc-1.2.2.Final.jar:1.2.2.Final]
> ... 3 more
> 15:50:20,348 ERROR [org.jboss.as.controller.management-operation] (DeploymentScanner-threads - 1) WFLYCTL0013: Operation ("deploy") failed - address: ([("deployment" => "ContextParamNullDemo.war")]) - failure description: {"WFLYCTL0080: Failed services" => {"jboss.undertow.deployment.default-server.default-host./ContextParamNullDemo.UndertowDeploymentInfoService" => "org.jboss.msc.service.StartException in service jboss.undertow.deployment.default-server.default-host./ContextParamNullDemo.UndertowDeploymentInfoService: Failed to start service
> Caused by: java.lang.NullPointerException"}}
> {code}
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 11 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:
-----------------------------------------
So, I don't think it's a good idea to just not validate the arguments just because the batch mode is on. Even as an exception for the cd.
Validation exists for a reason (it was actually requested by the users) and, IMO, it still makes sense in the batch mode too.
So, I propose, as a compromise for this case to add an argument to the cd (or perhaps even make it a global one supported by all the cli commands), e.g. --no-arg-validation or something shorter but clear, which would indicate that the user is actually asking to not validate the arguments.
Because in this case the user does know that the address that is being entered does not exist at this point.
Making it a global argument for all the commands though, should have as a consequence the fact that the non-validated commands might have unpredicted results (in their behavior and the effect on the management model). And that would be the user's responsibility.
The cd command in this sense is really harmless. So, perhaps, as a start this kind of argument could be added only to the cd.
> 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, 11 months