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 updated WFLY-4501: ---------------------------------- Git Pull Request: https://github.com/wildfly/wildfly/pull/7332 (was: https://github.com/wildfly/wildfly/pull/7132) > 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 soup from 1.7.1 to 1.8.1 for bug fixes and better speed -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-639) ManagementPermissionAuthorizer is limited to the standard roles for its authorizeJmxOperation impl

by Brian Stansberry (JIRA)

Brian Stansberry created WFCORE-639: --------------------------------------- Summary: ManagementPermissionAuthorizer is limited to the standard roles for its authorizeJmxOperation impl Key: WFCORE-639 URL: https://issues.jboss.org/browse/WFCORE-639 Project: WildFly Core Issue Type: Bug Components: Domain Management Reporter: Brian Stansberry ManagementPermissionAuthorizer.authorizeJmxOperation uses hard coded decision making based on the standard 7 roles. This is inflexible and specifically doesn't allow scoped roles to function properly. I believe the JmxPermissionFactory interface needs to be redone to use permissions instead of role names. It should have an API more like org.jboss.as.controller.access.permission.PermissionFactory, with getUserPermissions and getRequiredPermissions. Something like PermissionCollection getUserPermissions(Caller caller, Environment callEnvironment, JmxAction action) PermissionCollection getRequiredPermissions(JmxAction action); Then ManagementPermissionAuthorizer.authorizeJmxOperation does a permission match check similar to what it does for management resource permissions. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 9 months

1
0
0 / 0

[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 updated WFLY-4501: ---------------------------------- Description: Upgrade soup from 1.7.1 to 1.8.1 for bug fixes and better speed (was: Upgrade jdom 1.1.2 to 1.1.3 to sync with layered projects.) > 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 soup from 1.7.1 to 1.8.1 for bug fixes and better speed -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 9 months

1
0
0 / 0

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

by Fernando Nasser (JIRA)

Fernando Nasser created WFLY-4501: ------------------------------------- Summary: 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: Paul Gier 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)

9 years, 9 months

1
0
0 / 0

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

9 years, 9 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)

9 years, 9 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)

9 years, 9 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)

9 years, 9 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)

9 years, 9 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)

9 years, 9 months

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