April 2015 - jboss-jira - Jboss List Archives

[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)

11 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)

11 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)

11 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)

11 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)

11 years

1
0
0 / 0

[JBoss JIRA] (WFLY-4296) remove _ds.xml deployment support

by Jason Greene (JIRA)

[ https://issues.jboss.org/browse/WFLY-4296?page=com.atlassian.jira.plugin.... ] Jason Greene commented on WFLY-4296: ------------------------------------ Guys the agreement is that we would deprecate it, and get community feedback. There was no agreement to just remove it. > remove _ds.xml deployment support > --------------------------------- > > Key: WFLY-4296 > URL: https://issues.jboss.org/browse/WFLY-4296 > Project: WildFly > Issue Type: Feature Request > Components: JCA > Reporter: Stefano Maestri > Assignee: Stefano Maestri > Fix For: No Release > > -- This message was sent by Atlassian JIRA (v6.3.15#6346)

11 years

1
0
0 / 0

[JBoss JIRA] (WFCORE-656) Review log categories and remove/change where necessary

by James Perkins (JIRA)

[ https://issues.jboss.org/browse/WFCORE-656?page=com.atlassian.jira.plugin... ] James Perkins updated WFCORE-656: --------------------------------- Git Pull Request: https://github.com/wildfly/wildfly-core/pull/653, https://github.com/wildfly/wildfly-core/pull/654 (was: https://github.com/wildfly/wildfly-core/pull/653, https://github.com/wildfly/wildfly-core/pull/654, https://github.com/wildfly/wildfly/pull/7400) > Review log categories and remove/change where necessary > ------------------------------------------------------- > > Key: WFCORE-656 > URL: https://issues.jboss.org/browse/WFCORE-656 > Project: WildFly Core > Issue Type: Task > Components: Logging > Reporter: James Perkins > Assignee: James Perkins > Fix For: 1.0.0.CR1 > > > Look for situations like; > {code} > MessagingLogger ROOT_LOGGER = Logger.getMessageLogger(MessagingLogger.class, "org.jboss.as.messaging"); > MessagingLogger MESSAGING_LOGGER = Logger.getMessageLogger(MessagingLogger.class, "org.jboss.messaging"); > {code} > Possibly change all to org.wildfly.*. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

11 years

1
0
0 / 0

[JBoss JIRA] (WFCORE-263) Cancelling management op on slave HC tree is broken

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-263?page=com.atlassian.jira.plugin... ] Brian Stansberry updated WFCORE-263: ------------------------------------ Fix Version/s: 2.0.0.Alpha1 (was: 1.0.0.Beta6) > Cancelling management op on slave HC tree is broken > --------------------------------------------------- > > Key: WFCORE-263 > URL: https://issues.jboss.org/browse/WFCORE-263 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Affects Versions: 1.0.0.Alpha9 > Reporter: James Livingston > Assignee: Brian Stansberry > Fix For: 2.0.0.Alpha1 > > Attachments: unundeployable.zip > > > If you have a DC with a slave HC, and perform a management operation which gets stuck, non-progressing operations will be reported for both the DC and the slave HC via: > /host=master/core-service=management/service=management-operations:find-non-progressing-operation > /host=slave/core-service=management/service=management-operations:find-non-progressing-operation > Cancelling the operation under /host=master works as expected, pushing the cancellation down to the slave and the controllers become responsive again. > If however you attempt to cancel the operation under /host=slave, it goes bad. { "outcome" => "success", "result" => undefined } is reported in the CLI, but the controllers are still unresponsive. > Running :find-non-progressing-operation against the slave will report the {outcome=success,result=undefined} rather than that no non-progressing operations were found, and active-operation=*:read-resource() shows it as not cancelled. > Once you attempt to cancel it on a slave, attempting to cancel it under /host=master will report success, but leave the slave op in a weird state, and things requiring the controller lock (such as the web UI) will still not respond. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

11 years

1
0
0 / 0

[JBoss JIRA] (WFCORE-263) Cancelling management op on slave HC tree is broken

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-263?page=com.atlassian.jira.plugin... ] Brian Stansberry reopened WFCORE-263: ------------------------------------- Reopening. The test I added introduced instability in the testsuite. I don't know if that was due to the test or the fix; in any case I reverted the patch. > Cancelling management op on slave HC tree is broken > --------------------------------------------------- > > Key: WFCORE-263 > URL: https://issues.jboss.org/browse/WFCORE-263 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Affects Versions: 1.0.0.Alpha9 > Reporter: James Livingston > Assignee: Brian Stansberry > Fix For: 1.0.0.Beta6 > > Attachments: unundeployable.zip > > > If you have a DC with a slave HC, and perform a management operation which gets stuck, non-progressing operations will be reported for both the DC and the slave HC via: > /host=master/core-service=management/service=management-operations:find-non-progressing-operation > /host=slave/core-service=management/service=management-operations:find-non-progressing-operation > Cancelling the operation under /host=master works as expected, pushing the cancellation down to the slave and the controllers become responsive again. > If however you attempt to cancel the operation under /host=slave, it goes bad. { "outcome" => "success", "result" => undefined } is reported in the CLI, but the controllers are still unresponsive. > Running :find-non-progressing-operation against the slave will report the {outcome=success,result=undefined} rather than that no non-progressing operations were found, and active-operation=*:read-resource() shows it as not cancelled. > Once you attempt to cancel it on a slave, attempting to cancel it under /host=master will report success, but leave the slave op in a weird state, and things requiring the controller lock (such as the web UI) will still not respond. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

11 years

1
0
0 / 0

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

by Paul Gier (JIRA)

[ https://issues.jboss.org/browse/WFLY-4571?page=com.atlassian.jira.plugin.... ] Paul Gier commented on WFLY-4571: --------------------------------- How would the tools dependency management affect the test behavior? For the arquillian deps for example, the BOM should only set the versions of the dependencies if they are already in the build. They shouldn't have any effect on a build that doesn't have those dependencies. Same with the wildfly-maven-plugin, since it's in "pluginManagement" instead of "plugins", the BOM should only have the effect of setting the version for the plugin if you already added it to the build. But I might be missing something. > 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)

11 years

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira April 2015