[JBoss JIRA] (WFLY-3699) Missing param-name in a web.xml causes NullPointerException during deployment
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFLY-3699?page=com.atlassian.jira.plugin.... ]
Tomaz Cerar commented on WFLY-3699:
-----------------------------------
This should fail the deployment during parsing of descriptors not so late on.
Fix will probably be needed in metadata
> 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
>
> - 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, 5 months
[JBoss JIRA] (WFLY-3699) Missing param-name in a web.xml causes NullPointerException during deployment
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-3699?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration updated WFLY-3699:
------------------------------------------
Bugzilla Update: Perform
Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1125421
> 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
> Affects Versions: 9.0.0.Beta1
> Reporter: Jay Kumar SenSharma
> Assignee: Farah Juma
>
> - 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, 5 months
[JBoss JIRA] (WFLY-3699) Missing param-name in a web.xml causes NullPointerException during deployment
by Jay Kumar SenSharma (JIRA)
Jay Kumar SenSharma created WFLY-3699:
-----------------------------------------
Summary: 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
Affects Versions: 9.0.0.Beta1
Reporter: Jay Kumar SenSharma
Assignee: Farah Juma
- 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, 5 months
[JBoss JIRA] (JGRP-1864) UDP unable to bind to ephemeral port: port out of range:65536
by Ion Savin (JIRA)
[ https://issues.jboss.org/browse/JGRP-1864?page=com.atlassian.jira.plugin.... ]
Ion Savin commented on JGRP-1864:
---------------------------------
This is sufficient to trigger the failure with JGroups on that machine:
https://github.com/isavin/sample-ipv6-bind-fail/blob/master/src/main/java...
Since the non-JGroups app fails (ping6 fails also) this is probably not related to JGroups. If I find anything which might be relevant to this issue I'll reopen / update it.
Thanks for looking at this and sorry for the noise!
> UDP unable to bind to ephemeral port: port out of range:65536
> -------------------------------------------------------------
>
> Key: JGRP-1864
> URL: https://issues.jboss.org/browse/JGRP-1864
> Project: JGroups
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 3.4.4
> Reporter: Dan Berindei
> Assignee: Bela Ban
> Priority: Minor
> Fix For: 3.4.5, 3.5
>
>
> It looks like {{UDP.createEphemeralDatagramSocket()}} swallows any errors it gets while creating the socket, and throws this exception after trying to bind to all ports in the 0 - 65535 range:
> {noformat}
> java.lang.IllegalArgumentException: port out of range:65536
> at java.net.InetSocketAddress.checkPort(InetSocketAddress.java:143)
> at java.net.InetSocketAddress.<init>(InetSocketAddress.java:185)
> at java.net.DatagramSocket.<init>(DatagramSocket.java:284)
> at org.jgroups.util.DefaultSocketFactory.createDatagramSocket(DefaultSocketFactory.java:62)
> at org.jgroups.protocols.UDP.createEphemeralDatagramSocket(UDP.java:429)
> at org.jgroups.protocols.UDP.createSockets(UDP.java:311)
> at org.jgroups.protocols.UDP.start(UDP.java:216)
> at org.jgroups.stack.ProtocolStack.startStack(ProtocolStack.java:966)
> at org.jgroups.JChannel.startStack(JChannel.java:889)
> at org.jgroups.JChannel._preConnect(JChannel.java:547)
> at org.jgroups.JChannel.connect(JChannel.java:282)
> at org.jgroups.JChannel.connect(JChannel.java:273)
> at org.infinispan.remoting.transport.jgroups.JGroupsTransport.startJGroupsChannelIfNeeded(JGroupsTransport.java:200)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 5 months
[JBoss JIRA] (ELY-37) Audit Logging Integration
by Darran Lofthouse (JIRA)
Darran Lofthouse created ELY-37:
-----------------------------------
Summary: Audit Logging Integration
Key: ELY-37
URL: https://issues.jboss.org/browse/ELY-37
Project: WildFly Elytron
Issue Type: Task
Security Level: Public (Everyone can see)
Components: API / SPI, Audit
Reporter: Darran Lofthouse
Fix For: 1.0.0.Beta1
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 5 months
[JBoss JIRA] (ELY-36) Authentication Context Lifecycle
by Darran Lofthouse (JIRA)
Darran Lofthouse created ELY-36:
-----------------------------------
Summary: Authentication Context Lifecycle
Key: ELY-36
URL: https://issues.jboss.org/browse/ELY-36
Project: WildFly Elytron
Issue Type: Task
Security Level: Public (Everyone can see)
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.2.6#6264)
11 years, 5 months
[JBoss JIRA] (ELY-35) Notification of outcome from authentication mechanism through to realm.
by Darran Lofthouse (JIRA)
Darran Lofthouse created ELY-35:
-----------------------------------
Summary: Notification of outcome from authentication mechanism through to realm.
Key: ELY-35
URL: https://issues.jboss.org/browse/ELY-35
Project: WildFly Elytron
Issue Type: Task
Security Level: Public (Everyone can see)
Components: API / SPI
Reporter: Darran Lofthouse
Fix For: 1.0.0.Beta1
Realm implementations may want to track successful / unsuccessful calls.
Note: There may be a better way to consider this so do not take the title too literally.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 5 months
[JBoss JIRA] (ELY-34) Create a JAAS based security realm.
by Darran Lofthouse (JIRA)
Darran Lofthouse created ELY-34:
-----------------------------------
Summary: Create a JAAS based security realm.
Key: ELY-34
URL: https://issues.jboss.org/browse/ELY-34
Project: WildFly Elytron
Issue Type: Sub-task
Security Level: Public (Everyone can see)
Components: Realms
Reporter: Darran Lofthouse
Assignee: Darran Lofthouse
Fix For: 1.0.0.Beta1
Legacy integration is always going to be a concern so should verify that we can delegate to JAAS if required.
_Delegating to JAAS is always going to simplify the password types supported so this is more of an ensure we can integrate with JAAS rather than ensure we can fully integrate with JAAS._
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 5 months
[JBoss JIRA] (WFLY-3638) Remove use of deprecated methods from CoreManagementResourceDefinition and ServerRootResourceDefinition
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-3638?page=com.atlassian.jira.plugin.... ]
Brian Stansberry edited comment on WFLY-3638 at 7/31/14 11:55 AM:
------------------------------------------------------------------
One last background comment... this test has a bunch of stuff related to letting arquillian provide a modular environment (actually starting a full server process), and then a full mock model controller etc is run inside that environment. My assumption is all that stuff about providing the environment remains in ParseAndMarshalModelsTestCase and the static utility methods will "just work", same as they do now. We don't allow an arquillian dependency in core, so we can't move any of that stuff into the utility.
was (Author: brian.stansberry):
One last background comment... this test has a bunch of stuff related to letting arquillian provide a modular environment (actually starting a full server process), and then a full mock model controller etc is run inside that environment. My assumption is all that stuff remains in ParseAndMarshalModelsTestCase and the static utility methods will "just work", same as they do now. We don't allow an arquillian dependency in core, so we can't move any of that stuff into the utility.
> Remove use of deprecated methods from CoreManagementResourceDefinition and ServerRootResourceDefinition
> -------------------------------------------------------------------------------------------------------
>
> Key: WFLY-3638
> URL: https://issues.jboss.org/browse/WFLY-3638
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Test Suite
> Reporter: Emmanuel Hugonnet
> Assignee: Emmanuel Hugonnet
> Fix For: 9.0.0.Beta1
>
>
> ServerRootResourceDefinition constructor and CoreManagementResourceDefinition static methods have been deprecated.
> Replace their use with the new methods with the BootErrorCollector parameter.
> This can be done with core 1.0.0.Alpha4.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 5 months
[JBoss JIRA] (WFLY-3638) Remove use of deprecated methods from CoreManagementResourceDefinition and ServerRootResourceDefinition
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-3638?page=com.atlassian.jira.plugin.... ]
Brian Stansberry commented on WFLY-3638:
----------------------------------------
One last background comment... this test has a bunch of stuff related to letting arquillian provide a modular environment (actually starting a full server process), and then a full mock model controller etc is run inside that environment. My assumption is all that stuff remains in ParseAndMarshalModelsTestCase and the static utility methods will "just work", same as they do now. We don't allow an arquillian dependency in core, so we can't move any of that stuff into the utility.
> Remove use of deprecated methods from CoreManagementResourceDefinition and ServerRootResourceDefinition
> -------------------------------------------------------------------------------------------------------
>
> Key: WFLY-3638
> URL: https://issues.jboss.org/browse/WFLY-3638
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Test Suite
> Reporter: Emmanuel Hugonnet
> Assignee: Emmanuel Hugonnet
> Fix For: 9.0.0.Beta1
>
>
> ServerRootResourceDefinition constructor and CoreManagementResourceDefinition static methods have been deprecated.
> Replace their use with the new methods with the BootErrorCollector parameter.
> This can be done with core 1.0.0.Alpha4.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 5 months