April 2015 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-4441) web.xml parser process cannot handle exception for xml file which does not have the encoding attribute

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-4441?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-4441: ----------------------------------------------- baranowb <bbaranow(a)redhat.com> changed the Status of [bug 1184292|https://bugzilla.redhat.com/show_bug.cgi?id=1184292] from POST to MODIFIED > web.xml parser process cannot handle exception for xml file which does not have the encoding attribute > ------------------------------------------------------------------------------------------------------ > > Key: WFLY-4441 > URL: https://issues.jboss.org/browse/WFLY-4441 > Project: WildFly > Issue Type: Bug > Affects Versions: 9.0.0.Alpha1 > Reporter: Tomas Hofman > Assignee: Tomas Hofman > > Description copied from https://bugzilla.redhat.com/show_bug.cgi?id=1184292 > Description of problem: > When XMLStreamException occurs by web.xml parser process for xml file which does not have the encoding attribute, e.getLocation()[1] is null. We cannot find cause of exception by NullPointerException. > [1] > - org.jboss.as.web.deployment.WebParsingDeploymentProcessor.java > #115 } catch (XMLStreamException e) { > -> #116 throw new DeploymentUnitProcessingException(MESSAGES.failToParseXMLDescriptor(webXml, e.getLocation().getLineNumber(), e.getLocation().getColumnNumber()), e); > #117 } catch (IOException e) { > #118 throw new DeploymentUnitProcessingException(MESSAGES.failToParseXMLDescriptor(webXml), e); > #119 } > Version-Release number of selected component (if applicable): > EAP 6.3.2 > How reproducible: > Attached web.xml for reproducing. > Steps to Reproduce: > 1. Create war application using attached web.xml. > 2. Deploy war to EAP. > 3. Start EAP. > Actual results: > You can confirm NullPointerException. > 15:56:23,190 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-2) MSC000001: Failed to start service jboss.deployment.unit."test.war".PARSE: org.jboss.msc.service.StartException in service jboss.deployment.unit."test.war".PARSE: JBAS018733: Failed to process phase PARSE of deployment "test.war" > at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:166) [jboss-as-server-7.4.2.Final-redhat-2.jar:7.4.2.Final-redhat-2] > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1980) [jboss-msc-1.1.5.Final-redhat-1.jar:1.1.5.Final-redhat-1] > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1913) [jboss-msc-1.1.5.Final-redhat-1.jar:1.1.5.Final-redhat-1] > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_71] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_71] > at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_71] > Caused by: java.lang.NullPointerException > at org.jboss.as.web.deployment.WebParsingDeploymentProcessor.deploy(WebParsingDeploymentProcessor.java:116) > at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:159) [jboss-as-server-7.4.2.Final-redhat-2.jar:7.4.2.Final-redhat-2] > ... 5 more -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years

1
0
0 / 0

[JBoss JIRA] (WFCORE-553) ModelControllerClientOperationHandler doesn't manage the clientRequestExecutor properly

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFCORE-553?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on WFCORE-553: ------------------------------------------------ baranowb <bbaranow(a)redhat.com> changed the Status of [bug 1199319|https://bugzilla.redhat.com/show_bug.cgi?id=1199319] from POST to MODIFIED > ModelControllerClientOperationHandler doesn't manage the clientRequestExecutor properly > ---------------------------------------------------------------------------------------- > > Key: WFCORE-553 > URL: https://issues.jboss.org/browse/WFCORE-553 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Affects Versions: 1.0.0.Alpha1, 1.0.0.Alpha18 > Reporter: Brian Stansberry > Assignee: Brian Stansberry > Fix For: 1.0.0.Beta1 > > > ModelControllerClientOperationHandler's constructor creates a ThreadPoolExecutor for handling client requests and then the class doesn't clean it up. > In addition, an instance of ModelControllerClientOperationHandler is created per channel, not one per ModelControllerClientOperationHandlerFactoryService. I know I at least thought of the thread pool as being per remote management interface, not per channel. > Making it be per ModelControllerClientOperationHandlerFactoryService and cleaning it up in that service's stop would be the easiest fix, but the pool settings may not be appropriate if we do that, so tread carefully. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years

1
0
0 / 0

[JBoss JIRA] (JBJCA-1252) MCPs can become detached

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/JBJCA-1252?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on JBJCA-1252: ------------------------------------------------ Ivo Studensky <istudens(a)redhat.com> changed the Status of [bug 1210570|https://bugzilla.redhat.com/show_bug.cgi?id=1210570] from NEW to MODIFIED > MCPs can become detached > ------------------------ > > Key: JBJCA-1252 > URL: https://issues.jboss.org/browse/JBJCA-1252 > Project: IronJacamar > Issue Type: Bug > Components: Core > Affects Versions: 1.0.31.Final, 1.1.9.Final, 1.2.2.Final > Reporter: Jesper Pedersen > Assignee: Jesper Pedersen > Priority: Blocker > Fix For: 1.0.32.Final, 1.1.10.Final, 1.2.3.Final > > -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years

1
0
0 / 0

[JBoss JIRA] (WFLY-4572) wildfly-arquillian uses slf4j-api:1.7.7.jbossorg-1 which is not available in maven central repository

by Martin Kouba (JIRA)

[ https://issues.jboss.org/browse/WFLY-4572?page=com.atlassian.jira.plugin.... ] Martin Kouba commented on WFLY-4572: ------------------------------------ [~ctomc] In fact, {{wildfly-core-feature-pack}} depends on this artifact. Given that {{wildfly-core-feature-pack}} is published to maven central, I believe it shouldn't. > wildfly-arquillian uses slf4j-api:1.7.7.jbossorg-1 which is not available in maven central repository > ----------------------------------------------------------------------------------------------------- > > Key: WFLY-4572 > URL: https://issues.jboss.org/browse/WFLY-4572 > Project: WildFly > Issue Type: Bug > Components: Test Suite > Affects Versions: 8.2.0.Final, 9.0.0.Beta2 > Reporter: Martin Kouba > Assignee: Paul Gier > > GAV: {{org.slf4j:slf4j-api:1.7.7.jbossorg-1}} > As a result, it's not possible to build a project which depends on some referencing module, e.g. {{wildfly-arquillian-common}}, and does not define JBoss repository at the same time. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years

1
0
0 / 0

[JBoss JIRA] (WFLY-4572) wildfly-arquillian uses slf4j-api:1.7.7.jbossorg-1 which is not available in maven central repository

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/WFLY-4572?page=com.atlassian.jira.plugin.... ] Tomaz Cerar updated WFLY-4572: ------------------------------ Summary: wildfly-arquillian uses slf4j-api:1.7.7.jbossorg-1 which is not available in maven central repository (was: wildfly-parent manages dependency slf4j-api:1.7.7.jbossorg-1 which is not available in maven central repository) > wildfly-arquillian uses slf4j-api:1.7.7.jbossorg-1 which is not available in maven central repository > ----------------------------------------------------------------------------------------------------- > > Key: WFLY-4572 > URL: https://issues.jboss.org/browse/WFLY-4572 > Project: WildFly > Issue Type: Bug > Components: Test Suite > Affects Versions: 8.2.0.Final, 9.0.0.Beta2 > Reporter: Martin Kouba > Assignee: Paul Gier > > GAV: {{org.slf4j:slf4j-api:1.7.7.jbossorg-1}} > As a result, it's not possible to build a project which depends on some referencing module, e.g. {{wildfly-arquillian-common}}, and does not define JBoss repository at the same time. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years

1
0
0 / 0

[JBoss JIRA] (WFLY-4572) wildfly-parent manages dependency slf4j-api:1.7.7.jbossorg-1 which is not available in maven central repository

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/WFLY-4572?page=com.atlassian.jira.plugin.... ] Tomaz Cerar commented on WFLY-4572: ----------------------------------- Don't see how this has anything to do with wildfly itself. It needs to be addressed in wildfly-arquillian adapters. wildfly-parent needs to use that specific version. arquillian adapters, shouldn't. > wildfly-parent manages dependency slf4j-api:1.7.7.jbossorg-1 which is not available in maven central repository > --------------------------------------------------------------------------------------------------------------- > > Key: WFLY-4572 > URL: https://issues.jboss.org/browse/WFLY-4572 > Project: WildFly > Issue Type: Bug > Components: Build System > Affects Versions: 8.2.0.Final, 9.0.0.Beta2 > Reporter: Martin Kouba > Assignee: Paul Gier > > GAV: {{org.slf4j:slf4j-api:1.7.7.jbossorg-1}} > As a result, it's not possible to build a project which depends on some referencing module, e.g. {{wildfly-arquillian-common}}, and does not define JBoss repository at the same time. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years

1
0
0 / 0

[JBoss JIRA] (WFLY-4572) wildfly-parent manages dependency slf4j-api:1.7.7.jbossorg-1 which is not available in maven central repository

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/WFLY-4572?page=com.atlassian.jira.plugin.... ] Tomaz Cerar updated WFLY-4572: ------------------------------ Component/s: Test Suite (was: Build System) > wildfly-parent manages dependency slf4j-api:1.7.7.jbossorg-1 which is not available in maven central repository > --------------------------------------------------------------------------------------------------------------- > > Key: WFLY-4572 > URL: https://issues.jboss.org/browse/WFLY-4572 > Project: WildFly > Issue Type: Bug > Components: Test Suite > Affects Versions: 8.2.0.Final, 9.0.0.Beta2 > Reporter: Martin Kouba > Assignee: Paul Gier > > GAV: {{org.slf4j:slf4j-api:1.7.7.jbossorg-1}} > As a result, it's not possible to build a project which depends on some referencing module, e.g. {{wildfly-arquillian-common}}, and does not define JBoss repository at the same time. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years

1
0
0 / 0

[JBoss JIRA] (WFLY-4571) Merge the wildfly BOMs into a single BOM

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/WFLY-4571?page=com.atlassian.jira.plugin.... ] Tomaz Cerar commented on WFLY-4571: ----------------------------------- Biggest problem I see is importing arquilian related boms. https://github.com/wildfly/boms/blob/master/jboss-javaee-7.0-with-tools/p... as they bring with them mayhem of dependencies. And lots of people doesn't use arquillian why push it down their throats. > Merge the wildfly BOMs into a single BOM > ---------------------------------------- > > Key: WFLY-4571 > URL: https://issues.jboss.org/browse/WFLY-4571 > Project: WildFly > Issue Type: Enhancement > Reporter: Paul Gier > Assignee: Paul Gier > > We had some discussion on the jbossdeveloper list [1] about merging the current wildfly/eap boms into a single one instead of a separate bom for each use case. > The only problematic BOM might be the hibernate3 bom because this includes dependencies which conflict with the hibernate 4 bom. So the hibernate 3 bom will probably need to remain separate. > [1]http://lists.jboss.org/pipermail/jbossdeveloper/2015-April/000347.html -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years

1
0
0 / 0

[JBoss JIRA] (WFLY-4572) wildfly-parent manages dependency slf4j-api:1.7.7.jbossorg-1 which is not available in maven central repository

by Martin Kouba (JIRA)

Martin Kouba created WFLY-4572: ---------------------------------- Summary: wildfly-parent manages dependency slf4j-api:1.7.7.jbossorg-1 which is not available in maven central repository Key: WFLY-4572 URL: https://issues.jboss.org/browse/WFLY-4572 Project: WildFly Issue Type: Bug Components: Build System Affects Versions: 9.0.0.Beta2, 8.2.0.Final Reporter: Martin Kouba Assignee: Paul Gier GAV: {{org.slf4j:slf4j-api:1.7.7.jbossorg-1}} As a result, it's not possible to build a project which depends on some referencing module, e.g. {{wildfly-arquillian-common}}, and does not define JBoss repository at the same time. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years

1
0
0 / 0

[JBoss JIRA] (WFLY-2807) Messaging subsystem runtime-queue resource is not registered as "runtime-only"

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFLY-2807?page=com.atlassian.jira.plugin.... ] Brian Stansberry reassigned WFLY-2807: -------------------------------------- Assignee: Kabir Khan (was: Brian Stansberry) Resolution: Done > Messaging subsystem runtime-queue resource is not registered as "runtime-only" > ------------------------------------------------------------------------------ > > Key: WFLY-2807 > URL: https://issues.jboss.org/browse/WFLY-2807 > Project: WildFly > Issue Type: Bug > Components: Domain Management, JMS > Affects Versions: 8.0.0.CR1 > Reporter: Brian Stansberry > Assignee: Kabir Khan > Fix For: 9.0.0.CR1 > > > The runtime-queue resource only exists at runtime but isn't registered as such. I noticed this as ManagementClient does a recursive read-resource of the entire tree, but with include-runtime=false, but a CI run showed a failure reading one of these resources anyway: > ``` > 21:01:01,754 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 4) JBAS014613: Operation ("read-attribute") failed - address: ([ > ("subsystem" => "messaging"), > ("hornetq-server" => "default"), > ("runtime-queue" => "jms.tempqueue.661a6b15-7863-4d6c-b4b1-f8d62d294ea5") > ]) - failure description: "JBAS011676: No resource exists at address [ > (\"subsystem\" => \"messaging\"), > (\"hornetq-server\" => \"default\"), > (\"runtime-queue\" => \"jms.tempqueue.661a6b15-7863-4d6c-b4b1-f8d62d294ea5\") > ]" > ``` > Doing read-resource with these is a bit problematic in any case, since a bunch of read-attribute calls get executed as steps (that's what the above was) but the resource can disappear in the middle. But that's a separate problem. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira April 2015