April 2015 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-4501) Upgrade jsoup from 1.7.1 to 1.8.1

by Fernando Nasser (JIRA)

[ https://issues.jboss.org/browse/WFLY-4501?page=com.atlassian.jira.plugin.... ] Fernando Nasser reassigned WFLY-4501: ------------------------------------- Assignee: Fernando Nasser (was: Paul Gier) > Upgrade jsoup from 1.7.1 to 1.8.1 > --------------------------------- > > Key: WFLY-4501 > URL: https://issues.jboss.org/browse/WFLY-4501 > Project: WildFly > Issue Type: Feature Request > Components: XML Frameworks > Reporter: Paul Gier > Assignee: Fernando Nasser > > Upgrade jdom 1.1.2 to 1.1.3 to sync with layered projects. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-638) deployment runtime-name mismatch between content repo and server-group and logs

by ehsavoie Hugonnet (JIRA)

[ https://issues.jboss.org/browse/WFCORE-638?page=com.atlassian.jira.plugin... ] ehsavoie Hugonnet moved WFLY-4477 to WFCORE-638: ------------------------------------------------ Project: WildFly Core (was: WildFly) Key: WFCORE-638 (was: WFLY-4477) Affects Version/s: 1.0.0.Beta3 (was: 8.2.0.Final) Component/s: Domain Management (was: Domain Management) > deployment runtime-name mismatch between content repo and server-group and logs > ------------------------------------------------------------------------------- > > Key: WFCORE-638 > URL: https://issues.jboss.org/browse/WFCORE-638 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Affects Versions: 1.0.0.Beta3 > Reporter: Ian Kent > Assignee: ehsavoie Hugonnet > Attachments: Screen Shot 2015-03-31 at 12.49.20 PM.png, Screen Shot 2015-03-31 at 12.49.45 PM.png > > > We are continuously deploying web applications (wars) into our wildfly domain as part of our continuous deployment driven by Bamboo. > Each time an application build succeeds it will trigger a deployment to our wildfly domain. > If this is the first deployment we run this command. > {noformat} > jboss-cli.sh --connect --controller=somehost:9990 --user=admin --password=admin --command="deploy app-0.1-SNAPSHOT.war --name=app.war --runtime-name=app-0.1-SNAP\ > SHOT-b1.war --server-groups=A > {noformat} > For subsequent deployments we force a redeploy over existing deployment. > {noformat} > jboss-cli.sh --connect --controller=somehost:9990 --user=admin --password=admin --command="deploy app-0.1-SNAPSHOT.war --name=app.war --runtime-name=app-0.1-SNAP\ > SHOT-b2.war --force > jboss-cli.sh --connect --controller=somehost:9990 --user=admin --password=admin --command="deploy app-0.1-SNAPSHOT.war --name=app.war --runtime-name=app-0.1-SNAP\ > SHOT-b3.war --force > jboss-cli.sh --connect --controller=somehost:9990 --user=admin --password=admin --command="deploy app-0.1-SNAPSHOT.war --name=app.war --runtime-name=app-0.1-SNAP\ > SHOT-b4.war --force > etc.... > {noformat} > Since upgrading to WildFly 8.2.0 we see a strange behaviour in the domain management web console (http://somehost:9990/console/App.html#domain-deployments). > The application runtime name in content repository is not the same as what is shown in the server group. > I will attach screenshots for an app named apollo.war. You will see from the screenshots that the content repository shows runtime name=apollo-0.1.12-SNAPSHOT-11\ > 03.war, but the > server group shows runtime-name=apollo-0.1.12-SNAPSHOT-1045.war. (The last number in runtime-name is the build number from bamboo) > The server.logs from wildfly show "Deployed "apollo.war" (runtime-name : "apollo-0.1.12-SNAPSHOT-1045.war")" > However, we can tell by app capabilities that what is really deployed is apollo-0.1.12-SNAPSHOT-1103.war. > We are totally confused by this discrepency. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4500) CMResourceService#stop fails to clean up

by Philippe Marschall (JIRA)

Philippe Marschall created WFLY-4500: ---------------------------------------- Summary: CMResourceService#stop fails to clean up Key: WFLY-4500 URL: https://issues.jboss.org/browse/WFLY-4500 Project: WildFly Issue Type: Patch Components: Transactions Reporter: Philippe Marschall Assignee: Tom Jenkinson CMResourceService#stop fails to clean up values that #start creates. The issue is the line {code} jtaEnvironmentBean.getValue().getPerformImmediateCleanupOfCommitMarkableResourceBranchesMap().remove(immediateCleanup); {code} immediateCleanup is a {{Boolean}} and the return type of {{getPerformImmediateCleanupOfCommitMarkableResourceBranchesMap()}} is {{Map<String, Boolean>}} So this line never does anything. The line should read {code} jtaEnvironmentBean.getValue().getPerformImmediateCleanupOfCommitMarkableResourceBranchesMap().remove(jndiName); {code} because if we look a the #start method above we see {code} Map<String, Boolean> performImmediateCleanupOfConnectableResourceBranchesMap = jtaEnvironmentBean.getValue().getPerformImmediateCleanupOfCommitMarkableResourceBranchesMap(); performImmediateCleanupOfConnectableResourceBranchesMap.put(jndiName, immediateCleanup); {code} -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (LOGMGR-120) Thread local log level overriding

by John Mezzetta (JIRA)

[ https://issues.jboss.org/browse/LOGMGR-120?page=com.atlassian.jira.plugin... ] John Mezzetta updated LOGMGR-120: --------------------------------- Hi David, Is it possible to remove the public thread in Jira? We have an Non-disclosure agreement with Red hat and the open source thread should not have been used to have this dialog. And I hope it is ok to discuss this via e-mail. We can also move the discussion to a Customer Portal support case if you like. I am not sure what you mean by a filter, but if you are talking about typical logging filters, they tend to do further narrowing of output log messages. In other words, after the level check (ie. Only show INFO and above), there could be a filter that takes the INFO and above messages and only allow the ones with the word “joe” through (for example). Force logging is a bit different. Instead of narrowing scope like a traditional filter, it widens scope. So in our example, all INFO messages would be let through, and any messages from any level (FINEST and above) containing the word “joe” (for example) would also be let through. Does this make sense? Am I understanding the term filter properly? Thanks, John From: David Lloyd (JIRA) [mailto:issues@jboss.org] Sent: Friday, April 10, 2015 10:35 AM To: John Mezzetta Subject: [JBoss JIRA] (LOGMGR-120) Thread local log level overriding [https://static.jboss.org/developer/gravatar/a9e35a1be800d158663cd340ac4d1...] David Lloyd<https://issues.jboss.org/secure/ViewProfile.jspa?name=dmlloyd> commented on [Feature Request] LOGMGR-120<https://issues.jboss.org/browse/LOGMGR-120> Re: Thread local log level overriding<https://issues.jboss.org/browse/LOGMGR-120> It sounds like what you're describing is more along the lines of consulting a Filter (instead of doing a level check) to determine if a message is logged during certain operations. Would you say that is an accurate assessment? [Add Comment]<https://issues.jboss.org/browse/LOGMGR-120#add-comment> Add Comment<https://issues.jboss.org/browse/LOGMGR-120#add-comment> This message was sent by Atlassian JIRA (v6.3.11#6341-sha1:83c4d29) [Atlassian logo] > Thread local log level overriding > --------------------------------- > > Key: LOGMGR-120 > URL: https://issues.jboss.org/browse/LOGMGR-120 > Project: JBoss Log Manager > Issue Type: Feature Request > Components: core > Affects Versions: 1.5.2.Final > Reporter: Matthew Robson > Assignee: James Perkins > Attachments: force_logging.patch > > > Having the ability to force logs down to a filter no matter what the log level is set to. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4499) Fix Compiler Warnings in Transactions Subsystem

by Philippe Marschall (JIRA)

Philippe Marschall created WFLY-4499: ---------------------------------------- Summary: Fix Compiler Warnings in Transactions Subsystem Key: WFLY-4499 URL: https://issues.jboss.org/browse/WFLY-4499 Project: WildFly Issue Type: Patch Components: Transactions Reporter: Philippe Marschall Assignee: Tom Jenkinson The transactions subsystem contains several compiler warnings. Some of them (mostly related to generics) are quite easy to fix. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (LOGMGR-120) Thread local log level overriding

by James Perkins (JIRA)

[ https://issues.jboss.org/browse/LOGMGR-120?page=com.atlassian.jira.plugin... ] James Perkins commented on LOGMGR-120: -------------------------------------- I've linked a PR that works based on a system property. {code:java} public class Main { static { System.setProperty("java.util.logging.manager", "org.jboss.logmanager.LogManager"); System.setProperty("org.jboss.logmanager.useThreadLocalLevel", "true"); } public static void main(final String[] args) throws Exception { Logger.getLogger("").setLevel(Level.INFO); final Logger logger = Logger.getLogger(Main.class.getName()); LogManager.setThreadLocalLogLevel(Level.FINE); logger.fine("Test 1"); LogManager.setThreadLocalLogLevel(null); logger.fine("Test 2"); logger.info("Test 3"); LogManager.setThreadLocalLogLevel(Level.OFF); logger.info("Test 4"); } } {code} This example would only print {{Test 1}} and {{Test 3}}. > Thread local log level overriding > --------------------------------- > > Key: LOGMGR-120 > URL: https://issues.jboss.org/browse/LOGMGR-120 > Project: JBoss Log Manager > Issue Type: Feature Request > Components: core > Affects Versions: 1.5.2.Final > Reporter: Matthew Robson > Assignee: James Perkins > Attachments: force_logging.patch > > > Having the ability to force logs down to a filter no matter what the log level is set to. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3893) JacORB compatibility subsystem

by Tomasz Adamski (JIRA)

[ https://issues.jboss.org/browse/WFLY-3893?page=com.atlassian.jira.plugin.... ] Tomasz Adamski closed WFLY-3893. -------------------------------- Resolution: Done > JacORB compatibility subsystem > ------------------------------ > > Key: WFLY-3893 > URL: https://issues.jboss.org/browse/WFLY-3893 > Project: WildFly > Issue Type: Feature Request > Components: IIOP > Reporter: Tomasz Adamski > Assignee: Tomasz Adamski > > Create jacorb compatibility subsystem which will be able to parse jacorb subsystem configuration, map it to iiop-openjdk configuration, and (if possible) emulate jacorb subsystem using iiop-openjdk subsystem. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (LOGMGR-120) Thread local log level overriding

by David Lloyd (JIRA)

[ https://issues.jboss.org/browse/LOGMGR-120?page=com.atlassian.jira.plugin... ] David Lloyd commented on LOGMGR-120: ------------------------------------ It sounds like what you're describing is more along the lines of consulting a Filter (instead of doing a level check) to determine if a message is logged during certain operations. Would you say that is an accurate assessment? > Thread local log level overriding > --------------------------------- > > Key: LOGMGR-120 > URL: https://issues.jboss.org/browse/LOGMGR-120 > Project: JBoss Log Manager > Issue Type: Feature Request > Components: core > Affects Versions: 1.5.2.Final > Reporter: Matthew Robson > Assignee: James Perkins > Attachments: force_logging.patch > > > Having the ability to force logs down to a filter no matter what the log level is set to. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2455) Provide a way to add custom XAResource frameworks to the transaction manager

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/WFLY-2455?page=com.atlassian.jira.plugin.... ] Tom Jenkinson closed WFLY-2455. ------------------------------- Resolution: Rejected > Provide a way to add custom XAResource frameworks to the transaction manager > ---------------------------------------------------------------------------- > > Key: WFLY-2455 > URL: https://issues.jboss.org/browse/WFLY-2455 > Project: WildFly > Issue Type: Enhancement > Components: Transactions > Affects Versions: 8.0.0.Beta1 > Reporter: Koen Janssens > Assignee: Amos Feng > > Using a custom jbossts-properties.xml file defined via the com.arjuna.ats.arjuna.common.propertiesFile systemsetting, i can register a custom recovery manager for arjuna. > However, the ArjunaRecoveryManagerService class overwrite the recovery configuration mentioned in my jbossts-properties.xml file with a hardcoded list of recovery modules. > This makes me wonder if/how the hornetq recovery (org.hornetq.jms.server.recovery.HornetQXAResourceRecover) gets registered in wildfly.. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2455) Provide a way to add custom XAResource frameworks to the transaction manager

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/WFLY-2455?page=com.atlassian.jira.plugin.... ] Tom Jenkinson commented on WFLY-2455: ------------------------------------- And of course, it already exists! Sorry about that, the method you need to call is in: https://github.com/jbosstm/jboss-transaction-spi/blob/master/src/main/jav... You can see how it is resolved in a few different places: 1. Clustering https://github.com/wildfly/wildfly/blob/master/clustering/infinispan/exte... https://github.com/wildfly/wildfly/blob/master/clustering/infinispan/exte... 2. EJB3 https://github.com/wildfly/wildfly/blob/master/ejb3/src/main/java/org/jbo... https://github.com/wildfly/wildfly/blob/master/ejb3/src/main/java/org/jbo... 3. HornetQ https://github.com/wildfly/wildfly/blob/master/messaging/src/main/java/or... (used internally in HornetQ - https://github.com/hornetq/hornetq/blob/master/hornetq-jms-server/src/mai...) > Provide a way to add custom XAResource frameworks to the transaction manager > ---------------------------------------------------------------------------- > > Key: WFLY-2455 > URL: https://issues.jboss.org/browse/WFLY-2455 > Project: WildFly > Issue Type: Enhancement > Components: Transactions > Affects Versions: 8.0.0.Beta1 > Reporter: Koen Janssens > Assignee: Amos Feng > > Using a custom jbossts-properties.xml file defined via the com.arjuna.ats.arjuna.common.propertiesFile systemsetting, i can register a custom recovery manager for arjuna. > However, the ArjunaRecoveryManagerService class overwrite the recovery configuration mentioned in my jbossts-properties.xml file with a hardcoded list of recovery modules. > This makes me wonder if/how the hornetq recovery (org.hornetq.jms.server.recovery.HornetQXAResourceRecover) gets registered in wildfly.. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 2 months

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