April 2015 - jboss-jira - Jboss List Archives

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

9 years, 7 months

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)

9 years, 7 months

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)

9 years, 7 months

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)

9 years, 7 months

1
0
0 / 0

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

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/WFLY-4296?page=com.atlassian.jira.plugin.... ] Tomaz Cerar commented on WFLY-4296: ----------------------------------- This is being removed as it cannot be properly supported/implemented in all scenarios in which server and its tooling operates, and as such is causing more problems that it solves. Currently only scenario where it kinda works ok is in standalone mode when you are doing application developing. And when you keep this in mind you can see that EE6+ feature http://docs.oracle.com/javaee/7/api/javax/annotation/sql/DataSourceDefini... more than satisfies it. What it lacks is if nothing else full support for deployment in domain, runtime statistics & management operations. This brings confusion to users as data sources behave differently depending how they are deployed. When this was initially implemented it was only done to ease migration from AS < 7 to 7+ where this was only way to deploy datasources. > 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)

9 years, 7 months

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: ----------------------------------- another problem is tools, as if you include it, it can modify build & test behavior for the user. > 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)

9 years, 7 months

1
0
0 / 0

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

by Paul Gier (JIRA)

Paul Gier created WFLY-4571: ------------------------------- Summary: 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)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (AS7-4265) cli command to add/remove AS modules

by Brian Riehman (JIRA)

[ https://issues.jboss.org/browse/AS7-4265?page=com.atlassian.jira.plugin.s... ] Brian Riehman commented on AS7-4265: ------------------------------------ A note for [~davidj] and [~madhu.garimilla]: I had the same requirement to add a file to my deployment's classpath and provide it using a module. The only solution I found was to manually specify the module XML to be used via the {{--module-xml}} argument to {{module add}}. This isn't ideal since it requires you to generate the module file, but at least it can be scripted instead of being done by hand. > cli command to add/remove AS modules > ------------------------------------ > > Key: AS7-4265 > URL: https://issues.jboss.org/browse/AS7-4265 > Project: Application Server 7 > Issue Type: Task > Components: CLI > Reporter: Alexey Loubyansky > Assignee: Alexey Loubyansky > Fix For: 7.1.2.Final (EAP) > > > I think it'd be useful to have a command to add modules to the AS which given the jars, dependencies, etc would generate the structure in the modules dir, copy the jars and generate the xml. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-537) Use maven plugins (animal-sniffer?) to ensure that code and dependencies conform to the supported minimum version

by Petr Široký (JIRA)

[ https://issues.jboss.org/browse/DROOLS-537?page=com.atlassian.jira.plugin... ] Petr Široký commented on DROOLS-537: ------------------------------------ I checked that all the repos (master branch) can be successfully built with the animal-sniffer plugin enabled. Tried with Oracle JDKs 6,7,8. Still need to measure the impact on the build speed. > Use maven plugins (animal-sniffer?) to ensure that code and dependencies conform to the supported minimum version > ----------------------------------------------------------------------------------------------------------------- > > Key: DROOLS-537 > URL: https://issues.jboss.org/browse/DROOLS-537 > Project: Drools > Issue Type: Task > Affects Versions: 6.1.0.CR1 > Reporter: Marco Rietveld > Assignee: Petr Široký > > Every now and then, one of us uses syntax or a class from a higher version of Java than what we use. > Or otherwise, one of us will use a dependency that's been compiled in Java X+1 while the build is based on Java X. > Can we prevent discovering these mistakes too late by using the animal-sniffer plugin? > One of the more important points here is that using the animal-sniffer (or another plugin that can be used for this) must *not* significantly delay or prolong the build! -- This message was sent by Atlassian JIRA (v6.3.15#6346)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (JBJCA-1263) IronJacamar 1.0.32.Final

by Jesper Pedersen (JIRA)

[ https://issues.jboss.org/browse/JBJCA-1263?page=com.atlassian.jira.plugin... ] Jesper Pedersen resolved JBJCA-1263. ------------------------------------ Resolution: Done > IronJacamar 1.0.32.Final > ------------------------ > > Key: JBJCA-1263 > URL: https://issues.jboss.org/browse/JBJCA-1263 > Project: IronJacamar > Issue Type: Release > Components: Build > Reporter: Jesper Pedersen > Assignee: Jesper Pedersen > Fix For: 1.0.32.Final > > > Release notes: https://issues.jboss.org/secure/ReleaseNote.jspa?projectId=12310691&versi... -- This message was sent by Atlassian JIRA (v6.3.15#6346)

9 years, 7 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira April 2015