[JBoss JIRA] (WFLY-490) Simple Domain Management Role Based Permissions
by Gopi Chand Uppala (JIRA)
[ https://issues.jboss.org/browse/WFLY-490?page=com.atlassian.jira.plugin.s... ]
Gopi Chand Uppala commented on WFLY-490:
----------------------------------------
Thanks! Hope it gets rolled into JBoss EAP quickly.
> Simple Domain Management Role Based Permissions
> -----------------------------------------------
>
> Key: WFLY-490
> URL: https://issues.jboss.org/browse/WFLY-490
> Project: WildFly
> Issue Type: Sub-task
> Components: Domain Management, Security
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Priority: Blocker
> Labels: Authorization
> Fix For: 8.0.0.CR1
>
>
> Implement some coarse permissions for domain operations. Possibly allowing a break down for subsystem, profile, server, server-group - maybe read - write - execute.
> Also consider confidentiality in exchange e.g. Can read metrics over http but must use https to add new server.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 12 months
[JBoss JIRA] (AS7-3143) JMS Messages with CMP and transactional=true are not commited to the queue
by Tom Eicher (JIRA)
[ https://issues.jboss.org/browse/AS7-3143?page=com.atlassian.jira.plugin.s... ]
Tom Eicher commented on AS7-3143:
---------------------------------
So using JmsXA will will fix the problem of messages not being received (at all) in the MDB.
However, the parameter is still not completely ignored since transacted=false will work with multiple MDBs (ActivationConfigProperty maxSessions) as configured,
whereas transacted=true will only have one (single-threaded) MDB working on the queue, i.e. the message posting/receiving is serialized.
Is this expected behaviour or maybe another bug ?
> JMS Messages with CMP and transactional=true are not commited to the queue
> --------------------------------------------------------------------------
>
> Key: AS7-3143
> URL: https://issues.jboss.org/browse/AS7-3143
> Project: Application Server 7
> Issue Type: Bug
> Components: JMS
> Affects Versions: 7.0.1.Final, 7.1.0.CR1, 7.1.0.CR1b
> Environment: Windows 7, Java 1.6 update 24
> Reporter: Markus Döring
> Assignee: Carlo de Wolf
> Fix For: 7.1.0.Final
>
> Attachments: TestEAR.ear.zip, TestEAR.ear.zip, TestEAR.ear.zip
>
>
> When sending a message to a JMS queue using container managed transactions and setting transactional=true (connection.createSession(true, Session.AUTO_ACKNOWLEDGE)), the message is never added to the queue.
> Using transactional=false is not an option because the message is added to the queue immediately and not after transaction commit.
> This can be reproduced with the attached EAR (exploded deployment, so just unpack the .zip in the deployments directory) and the standalone-full.xml (JBoss 7.1.0.CR1
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 12 months
[JBoss JIRA] (AS7-4932) CLONE - Using session passivation results in WeldListener: java.lang.NullPointerException on normal operation
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/AS7-4932?page=com.atlassian.jira.plugin.s... ]
RH Bugzilla Integration commented on AS7-4932:
----------------------------------------------
Paul Ferraro <paul.ferraro(a)redhat.com> made a comment on [bug 900549|https://bugzilla.redhat.com/show_bug.cgi?id=900549]
The Infinispan team has identified another condition that can trigger this bug, specifically ISPN-2974. The fix is currently be ported to Infinispan 5.2.x - and should soon be available for consumption by EAP 6.1.
What should we do with the status of this BZ?
> CLONE - Using session passivation results in WeldListener: java.lang.NullPointerException on normal operation
> -------------------------------------------------------------------------------------------------------------
>
> Key: AS7-4932
> URL: https://issues.jboss.org/browse/AS7-4932
> Project: Application Server 7
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 7.1.2.Final (EAP)
> Reporter: Radoslav Husar
> Assignee: Paul Ferraro
> Priority: Blocker
> Labels: as713tracking
> Fix For: 7.1.3.Final (EAP)
>
>
> NPE is thrown in roughly 0.36% of HTTP session request processing in the test.
> This results in response code 503 returned to the client with the exception.
> The test is using passivation-enabled WAR of clusterbench
> https://github.com/rhusar/clusterbench
> Here is a shorter soak test run that uncovered the issue
> https://hudson.qa.jboss.com/hudson/view/EAP6/view/EAP6-Clustering-Soak/jo...
> {noformat}
> [JBossINF] 19:52:10,113 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[default-host]] (ajp-perf20/10.16.90.58:8009-2570) Exception sending request initialized lifecycle event to listener instance of class org.jboss.weld.servlet.WeldListener: java.lang.NullPointerException
> [JBossINF] at org.jboss.as.web.session.ClusteredSession.update(ClusteredSession.java:972) [jboss-as-web-7.1.2.Final-redhat-1.jar:7.1.2.Final-redhat-1]
> [JBossINF] at org.jboss.as.web.session.DistributableSessionManager.loadSession(DistributableSessionManager.java:1377) [jboss-as-web-7.1.2.Final-redhat-1.jar:7.1.2.Final-redhat-1]
> [JBossINF] at org.jboss.as.web.session.DistributableSessionManager.findSession(DistributableSessionManager.java:673) [jboss-as-web-7.1.2.Final-redhat-1.jar:7.1.2.Final-redhat-1]
> [JBossINF] at org.jboss.as.web.session.DistributableSessionManager.findSession(DistributableSessionManager.java:84) [jboss-as-web-7.1.2.Final-redhat-1.jar:7.1.2.Final-redhat-1]
> [JBossINF] at org.apache.catalina.connector.Request.doGetSession(Request.java:2618) [jbossweb-7.0.16.Final-redhat-1.jar:]
> [JBossINF] at org.apache.catalina.connector.Request.getSession(Request.java:2375) [jbossweb-7.0.16.Final-redhat-1.jar:]
> [JBossINF] at org.apache.catalina.connector.RequestFacade.getSession(RequestFacade.java:841) [jbossweb-7.0.16.Final-redhat-1.jar:]
> [JBossINF] at org.jboss.weld.context.beanstore.http.LazySessionBeanStore.getSession(LazySessionBeanStore.java:72) [weld-core-1.1.8.Final-redhat-1.jar:1.1.8.Final-redhat-1]
> [JBossINF] at org.jboss.weld.context.beanstore.http.LazySessionBeanStore.<init>(LazySessionBeanStore.java:58) [weld-core-1.1.8.Final-redhat-1.jar:1.1.8.Final-redhat-1]
> [JBossINF] at org.jboss.weld.context.http.HttpSessionContextImpl.associate(HttpSessionContextImpl.java:31) [weld-core-1.1.8.Final-redhat-1.jar:1.1.8.Final-redhat-1]
> [JBossINF] at org.jboss.weld.context.http.HttpSessionContextImpl.associate(HttpSessionContextImpl.java:16) [weld-core-1.1.8.Final-redhat-1.jar:1.1.8.Final-redhat-1]
> [JBossINF] at org.jboss.weld.servlet.WeldListener.requestInitialized(WeldListener.java:134) [weld-core-1.1.8.Final-redhat-1.jar:1.1.8.Final-redhat-1]
> [JBossINF] at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:143) [jbossweb-7.0.16.Final-redhat-1.jar:]
> [JBossINF] at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) [jbossweb-7.0.16.Final-redhat-1.jar:]
> [JBossINF] at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) [jbossweb-7.0.16.Final-redhat-1.jar:]
> [JBossINF] at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:368) [jbossweb-7.0.16.Final-redhat-1.jar:]
> [JBossINF] at org.apache.coyote.ajp.AjpProcessor.process(AjpProcessor.java:505) [jbossweb-7.0.16.Final-redhat-1.jar:]
> [JBossINF] at org.apache.coyote.ajp.AjpProtocol$AjpConnectionHandler.process(AjpProtocol.java:452) [jbossweb-7.0.16.Final-redhat-1.jar:]
> [JBossINF] at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:931) [jbossweb-7.0.16.Final-redhat-1.jar:]
> [JBossINF] at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_30]
> {noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 12 months
[JBoss JIRA] (WFLY-490) Simple Domain Management Role Based Permissions
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-490?page=com.atlassian.jira.plugin.s... ]
Brian Stansberry updated WFLY-490:
----------------------------------
Fix Version/s: 8.0.0.CR1
Priority: Blocker (was: Major)
Thanks for the feedback.
We've decided to pull this back into WildFly 8.
> Simple Domain Management Role Based Permissions
> -----------------------------------------------
>
> Key: WFLY-490
> URL: https://issues.jboss.org/browse/WFLY-490
> Project: WildFly
> Issue Type: Sub-task
> Components: Domain Management, Security
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Priority: Blocker
> Labels: Authorization
> Fix For: 8.0.0.CR1
>
>
> Implement some coarse permissions for domain operations. Possibly allowing a break down for subsystem, profile, server, server-group - maybe read - write - execute.
> Also consider confidentiality in exchange e.g. Can read metrics over http but must use https to add new server.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 12 months
[JBoss JIRA] (JBLOGGING-94) JBoss Logging does not detect log4j 2.0
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/JBLOGGING-94?page=com.atlassian.jira.plug... ]
David Lloyd reassigned JBLOGGING-94:
------------------------------------
Assignee: James Perkins (was: David Lloyd)
James could you whip up a patch for this? Thanks.
> JBoss Logging does not detect log4j 2.0
> ---------------------------------------
>
> Key: JBLOGGING-94
> URL: https://issues.jboss.org/browse/JBLOGGING-94
> Project: JBoss Logging
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: jboss-logging-log4j
> Affects Versions: 3.1.2.GA
> Environment: Hibernate
> Reporter: Henry Clout
> Assignee: James Perkins
>
> The class org.jboss.logging.LoggerProviders checks for the presence of log4j using the code:
> {code}
> private static LoggerProvider tryLog4j(final ClassLoader cl) throws ClassNotFoundException {
> Class.forName("org.apache.log4j.LogManager", true, cl);
> // JBLOGGING-65 - slf4j can disguise itself as log4j. Test for a class that slf4j doesn't provide.
> Class.forName("org.apache.log4j.Hierarchy", true, cl);
> return new Log4jLoggerProvider();
> }
> {code}
> However, despite having the log4j-1.2-api-2.0.jar bridge included, this fails as the class org.apache.log4j.Hierarchy is not present in log4j 2.0.
> I worked around this by forcing JBoss logging to use slf4j (which is then proxied to log4j) by setting the -Dorg.jboss.logging.provider=slf4j option.
> As a proper fix, however, how about checking for a class that is included in log4j 1.2, 2.0 but not slf4j? org.apache.log4j.config.PropertySetter seems to tick the box.
> I tested changing the afore mentioned method to:
> {code}
> private static LoggerProvider tryLog4j(final ClassLoader cl) throws ClassNotFoundException {
> Class.forName("org.apache.log4j.LogManager", true, cl);
> // JBLOGGING-65 - slf4j can disguise itself as log4j. Test for a class that slf4j doesn't provide.
> Class.forName("org.apache.log4j.config.PropertySetter", true, cl);
> return new Log4jLoggerProvider();
> }
> {code}
> And indeed I started receiving logging messages from Hibernate (via JBoss logging.)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 12 months
[JBoss JIRA] (AS7-6727) Modular build not in sync with modules directory structure
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/AS7-6727?page=com.atlassian.jira.plugin.s... ]
RH Bugzilla Integration commented on AS7-6727:
----------------------------------------------
Pavel Jelinek <pjelinek(a)redhat.com> changed the Status of [bug 947145|https://bugzilla.redhat.com/show_bug.cgi?id=947145] from ON_QA to VERIFIED
> Modular build not in sync with modules directory structure
> ----------------------------------------------------------
>
> Key: AS7-6727
> URL: https://issues.jboss.org/browse/AS7-6727
> Project: Application Server 7
> Issue Type: Bug
> Components: OSGi
> Reporter: Thomas Diesler
> Assignee: Thomas Diesler
> Labels: Karaf
>
> {code}
> [echo] Static modules: [org.jboss.as.standalone,org.jboss.as.domain-http-error-context,,, org.jboss.logging, org.jboss.vfs, org.slf4j, org.jboss.logging.jul-to-slf4j-stub]
> [java] Exception in thread "main" java.io.FileNotFoundException: /Users/tdiesler/git/jboss-as/build-modular/../build/src/main/resources/modules/org/jboss/as/logging/main/module.xml (No such file or directory)
> [java] at java.io.FileInputStream.open(Native Method)
> [java] at java.io.FileInputStream.<init>(FileInputStream.java:138)
> [java] at org.jboss.as.config.assembly.ModuleParser.parse(ModuleParser.java:61)
> [java] at org.jboss.as.config.assembly.GenerateModulesDefinition.processModuleDependency(GenerateModulesDefinition.java:193)
> [java] at org.jboss.as.config.assembly.GenerateModulesDefinition.process(GenerateModulesDefinition.java:130)
> [java] at org.jboss.as.config.assembly.GenerateModulesDefinition.main(GenerateModulesDefinition.java:104)
> [java] Java Result: 1
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 12 months
[JBoss JIRA] (AS7-6727) Modular build not in sync with modules directory structure
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/AS7-6727?page=com.atlassian.jira.plugin.s... ]
RH Bugzilla Integration commented on AS7-6727:
----------------------------------------------
Pavel Jelinek <pjelinek(a)redhat.com> made a comment on [bug 947145|https://bugzilla.redhat.com/show_bug.cgi?id=947145]
In EAP 6.1.0.ER5 the build-modular ant config and other files changed to meet new modules directory structure.
> Modular build not in sync with modules directory structure
> ----------------------------------------------------------
>
> Key: AS7-6727
> URL: https://issues.jboss.org/browse/AS7-6727
> Project: Application Server 7
> Issue Type: Bug
> Components: OSGi
> Reporter: Thomas Diesler
> Assignee: Thomas Diesler
> Labels: Karaf
>
> {code}
> [echo] Static modules: [org.jboss.as.standalone,org.jboss.as.domain-http-error-context,,, org.jboss.logging, org.jboss.vfs, org.slf4j, org.jboss.logging.jul-to-slf4j-stub]
> [java] Exception in thread "main" java.io.FileNotFoundException: /Users/tdiesler/git/jboss-as/build-modular/../build/src/main/resources/modules/org/jboss/as/logging/main/module.xml (No such file or directory)
> [java] at java.io.FileInputStream.open(Native Method)
> [java] at java.io.FileInputStream.<init>(FileInputStream.java:138)
> [java] at org.jboss.as.config.assembly.ModuleParser.parse(ModuleParser.java:61)
> [java] at org.jboss.as.config.assembly.GenerateModulesDefinition.processModuleDependency(GenerateModulesDefinition.java:193)
> [java] at org.jboss.as.config.assembly.GenerateModulesDefinition.process(GenerateModulesDefinition.java:130)
> [java] at org.jboss.as.config.assembly.GenerateModulesDefinition.main(GenerateModulesDefinition.java:104)
> [java] Java Result: 1
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 12 months
[JBoss JIRA] (JBLOGGING-94) JBoss Logging does not detect log4j 2.0
by Henry Clout (JIRA)
[ https://issues.jboss.org/browse/JBLOGGING-94?page=com.atlassian.jira.plug... ]
Henry Clout updated JBLOGGING-94:
---------------------------------
Description:
The class org.jboss.logging.LoggerProviders checks for the presence of log4j using the code:
{code}
private static LoggerProvider tryLog4j(final ClassLoader cl) throws ClassNotFoundException {
Class.forName("org.apache.log4j.LogManager", true, cl);
// JBLOGGING-65 - slf4j can disguise itself as log4j. Test for a class that slf4j doesn't provide.
Class.forName("org.apache.log4j.Hierarchy", true, cl);
return new Log4jLoggerProvider();
}
{code}
However, despite having the log4j-1.2-api-2.0.jar bridge included, this fails as the class org.apache.log4j.Hierarchy is not present in log4j 2.0.
I worked around this by forcing JBoss logging to use slf4j (which is then proxied to log4j) by setting the -Dorg.jboss.logging.provider=slf4j option.
As a proper fix, however, how about checking for a class that is included in log4j 1.2, 2.0 but not slf4j? org.apache.log4j.config.PropertySetter seems to tick the box.
I tested changing the afore mentioned method to:
{code}
private static LoggerProvider tryLog4j(final ClassLoader cl) throws ClassNotFoundException {
Class.forName("org.apache.log4j.LogManager", true, cl);
// JBLOGGING-65 - slf4j can disguise itself as log4j. Test for a class that slf4j doesn't provide.
Class.forName("org.apache.log4j.config.PropertySetter", true, cl);
return new Log4jLoggerProvider();
}
{code}
And indeed I started receiving logging messages from Hibernate (via JBoss logging.)
was:
The class org.jboss.logging.LoggerProviders checkes for the presence of log4j using the code:
{code}
private static LoggerProvider tryLog4j(final ClassLoader cl) throws ClassNotFoundException {
Class.forName("org.apache.log4j.LogManager", true, cl);
// JBLOGGING-65 - slf4j can disguise itself as log4j. Test for a class that slf4j doesn't provide.
Class.forName("org.apache.log4j.Hierarchy", true, cl);
return new Log4jLoggerProvider();
}
{code}
However, despite having the log4j-1.2-api-2.0.jar bridge included, this fails as the class org.apache.log4j.Hierarchy is not present in log4j 2.0.
I worked around this by forcing JBoss logging to use slf4j (which is then proxied to log4j) by setting the -Dorg.jboss.logging.provider=slf4j option.
As a proper fix, however, how about checking for a class that is included in log4j 1.2, 2.0 but not slf4j? org.apache.log4j.config.PropertySetter seems to tick the box.
I tested changing the afore mentioned method to:
{code}
private static LoggerProvider tryLog4j(final ClassLoader cl) throws ClassNotFoundException {
Class.forName("org.apache.log4j.LogManager", true, cl);
// JBLOGGING-65 - slf4j can disguise itself as log4j. Test for a class that slf4j doesn't provide.
Class.forName("org.apache.log4j.config.PropertySetter", true, cl);
return new Log4jLoggerProvider();
}
{code}
And indeed I started receiving logging messages from Hibernate (via JBoss logging.)
> JBoss Logging does not detect log4j 2.0
> ---------------------------------------
>
> Key: JBLOGGING-94
> URL: https://issues.jboss.org/browse/JBLOGGING-94
> Project: JBoss Logging
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: jboss-logging-log4j
> Affects Versions: 3.1.2.GA
> Environment: Hibernate
> Reporter: Henry Clout
> Assignee: David Lloyd
>
> The class org.jboss.logging.LoggerProviders checks for the presence of log4j using the code:
> {code}
> private static LoggerProvider tryLog4j(final ClassLoader cl) throws ClassNotFoundException {
> Class.forName("org.apache.log4j.LogManager", true, cl);
> // JBLOGGING-65 - slf4j can disguise itself as log4j. Test for a class that slf4j doesn't provide.
> Class.forName("org.apache.log4j.Hierarchy", true, cl);
> return new Log4jLoggerProvider();
> }
> {code}
> However, despite having the log4j-1.2-api-2.0.jar bridge included, this fails as the class org.apache.log4j.Hierarchy is not present in log4j 2.0.
> I worked around this by forcing JBoss logging to use slf4j (which is then proxied to log4j) by setting the -Dorg.jboss.logging.provider=slf4j option.
> As a proper fix, however, how about checking for a class that is included in log4j 1.2, 2.0 but not slf4j? org.apache.log4j.config.PropertySetter seems to tick the box.
> I tested changing the afore mentioned method to:
> {code}
> private static LoggerProvider tryLog4j(final ClassLoader cl) throws ClassNotFoundException {
> Class.forName("org.apache.log4j.LogManager", true, cl);
> // JBLOGGING-65 - slf4j can disguise itself as log4j. Test for a class that slf4j doesn't provide.
> Class.forName("org.apache.log4j.config.PropertySetter", true, cl);
> return new Log4jLoggerProvider();
> }
> {code}
> And indeed I started receiving logging messages from Hibernate (via JBoss logging.)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 12 months
[JBoss JIRA] (JBLOGGING-94) JBoss Logging does not detect log4j 2.0
by Henry Clout (JIRA)
[ https://issues.jboss.org/browse/JBLOGGING-94?page=com.atlassian.jira.plug... ]
Henry Clout updated JBLOGGING-94:
---------------------------------
Description:
The class org.jboss.logging.LoggerProviders checkes for the presence of log4j using the code:
{code}
private static LoggerProvider tryLog4j(final ClassLoader cl) throws ClassNotFoundException {
Class.forName("org.apache.log4j.LogManager", true, cl);
// JBLOGGING-65 - slf4j can disguise itself as log4j. Test for a class that slf4j doesn't provide.
Class.forName("org.apache.log4j.Hierarchy", true, cl);
return new Log4jLoggerProvider();
}
{code}
However, despite having the log4j-1.2-api-2.0.jar bridge included, this fails as the class org.apache.log4j.Hierarchy is not present in log4j 2.0.
I worked around this by forcing JBoss logging to use slf4j (which is then proxied to log4j) by setting the -Dorg.jboss.logging.provider=slf4j option.
As a proper fix, however, how about checking for a class that is included in log4j 1.2, 2.0 but not slf4j? org.apache.log4j.config.PropertySetter seems to tick the box.
I tested changing the afore mentioned method to:
private static LoggerProvider tryLog4j(final ClassLoader cl) throws ClassNotFoundException {
Class.forName("org.apache.log4j.LogManager", true, cl);
// JBLOGGING-65 - slf4j can disguise itself as log4j. Test for a class that slf4j doesn't provide.
Class.forName("org.apache.log4j.config.PropertySetter", true, cl);
return new Log4jLoggerProvider();
}
And indeed I started receiving logging messages from Hibernate (via JBoss logging.)
was:
The class org.jboss.logging.LoggerProviders checkes for the presence of log4j using the code:
private static LoggerProvider tryLog4j(final ClassLoader cl) throws ClassNotFoundException {
Class.forName("org.apache.log4j.LogManager", true, cl);
// JBLOGGING-65 - slf4j can disguise itself as log4j. Test for a class that slf4j doesn't provide.
Class.forName("org.apache.log4j.Hierarchy", true, cl);
return new Log4jLoggerProvider();
}
However, despite having the log4j-1.2-api-2.0.jar bridge included, this fails as the class org.apache.log4j.Hierarchy is not present in log4j 2.0.
I worked around this by forcing JBoss logging to use slf4j (which is then proxied to log4j) by setting the -Dorg.jboss.logging.provider=slf4j option.
As a proper fix, however, how about checking for a class that is included in log4j 1.2, 2.0 but not slf4j? org.apache.log4j.config.PropertySetter seems to tick the box.
I tested changing the afore mentioned method to:
private static LoggerProvider tryLog4j(final ClassLoader cl) throws ClassNotFoundException {
Class.forName("org.apache.log4j.LogManager", true, cl);
// JBLOGGING-65 - slf4j can disguise itself as log4j. Test for a class that slf4j doesn't provide.
Class.forName("org.apache.log4j.config.PropertySetter", true, cl);
return new Log4jLoggerProvider();
}
And indeed I started receiving logging messages from Hibernate (via JBoss logging.)
> JBoss Logging does not detect log4j 2.0
> ---------------------------------------
>
> Key: JBLOGGING-94
> URL: https://issues.jboss.org/browse/JBLOGGING-94
> Project: JBoss Logging
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: jboss-logging-log4j
> Affects Versions: 3.1.2.GA
> Environment: Hibernate
> Reporter: Henry Clout
> Assignee: David Lloyd
>
> The class org.jboss.logging.LoggerProviders checkes for the presence of log4j using the code:
> {code}
> private static LoggerProvider tryLog4j(final ClassLoader cl) throws ClassNotFoundException {
> Class.forName("org.apache.log4j.LogManager", true, cl);
> // JBLOGGING-65 - slf4j can disguise itself as log4j. Test for a class that slf4j doesn't provide.
> Class.forName("org.apache.log4j.Hierarchy", true, cl);
> return new Log4jLoggerProvider();
> }
> {code}
> However, despite having the log4j-1.2-api-2.0.jar bridge included, this fails as the class org.apache.log4j.Hierarchy is not present in log4j 2.0.
> I worked around this by forcing JBoss logging to use slf4j (which is then proxied to log4j) by setting the -Dorg.jboss.logging.provider=slf4j option.
> As a proper fix, however, how about checking for a class that is included in log4j 1.2, 2.0 but not slf4j? org.apache.log4j.config.PropertySetter seems to tick the box.
> I tested changing the afore mentioned method to:
> private static LoggerProvider tryLog4j(final ClassLoader cl) throws ClassNotFoundException {
> Class.forName("org.apache.log4j.LogManager", true, cl);
> // JBLOGGING-65 - slf4j can disguise itself as log4j. Test for a class that slf4j doesn't provide.
> Class.forName("org.apache.log4j.config.PropertySetter", true, cl);
> return new Log4jLoggerProvider();
> }
> And indeed I started receiving logging messages from Hibernate (via JBoss logging.)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 12 months
[JBoss JIRA] (JBLOGGING-94) JBoss Logging does not detect log4j 2.0
by Henry Clout (JIRA)
[ https://issues.jboss.org/browse/JBLOGGING-94?page=com.atlassian.jira.plug... ]
Henry Clout updated JBLOGGING-94:
---------------------------------
Description:
The class org.jboss.logging.LoggerProviders checkes for the presence of log4j using the code:
{code}
private static LoggerProvider tryLog4j(final ClassLoader cl) throws ClassNotFoundException {
Class.forName("org.apache.log4j.LogManager", true, cl);
// JBLOGGING-65 - slf4j can disguise itself as log4j. Test for a class that slf4j doesn't provide.
Class.forName("org.apache.log4j.Hierarchy", true, cl);
return new Log4jLoggerProvider();
}
{code}
However, despite having the log4j-1.2-api-2.0.jar bridge included, this fails as the class org.apache.log4j.Hierarchy is not present in log4j 2.0.
I worked around this by forcing JBoss logging to use slf4j (which is then proxied to log4j) by setting the -Dorg.jboss.logging.provider=slf4j option.
As a proper fix, however, how about checking for a class that is included in log4j 1.2, 2.0 but not slf4j? org.apache.log4j.config.PropertySetter seems to tick the box.
I tested changing the afore mentioned method to:
{code}
private static LoggerProvider tryLog4j(final ClassLoader cl) throws ClassNotFoundException {
Class.forName("org.apache.log4j.LogManager", true, cl);
// JBLOGGING-65 - slf4j can disguise itself as log4j. Test for a class that slf4j doesn't provide.
Class.forName("org.apache.log4j.config.PropertySetter", true, cl);
return new Log4jLoggerProvider();
}
{code}
And indeed I started receiving logging messages from Hibernate (via JBoss logging.)
was:
The class org.jboss.logging.LoggerProviders checkes for the presence of log4j using the code:
{code}
private static LoggerProvider tryLog4j(final ClassLoader cl) throws ClassNotFoundException {
Class.forName("org.apache.log4j.LogManager", true, cl);
// JBLOGGING-65 - slf4j can disguise itself as log4j. Test for a class that slf4j doesn't provide.
Class.forName("org.apache.log4j.Hierarchy", true, cl);
return new Log4jLoggerProvider();
}
{code}
However, despite having the log4j-1.2-api-2.0.jar bridge included, this fails as the class org.apache.log4j.Hierarchy is not present in log4j 2.0.
I worked around this by forcing JBoss logging to use slf4j (which is then proxied to log4j) by setting the -Dorg.jboss.logging.provider=slf4j option.
As a proper fix, however, how about checking for a class that is included in log4j 1.2, 2.0 but not slf4j? org.apache.log4j.config.PropertySetter seems to tick the box.
I tested changing the afore mentioned method to:
private static LoggerProvider tryLog4j(final ClassLoader cl) throws ClassNotFoundException {
Class.forName("org.apache.log4j.LogManager", true, cl);
// JBLOGGING-65 - slf4j can disguise itself as log4j. Test for a class that slf4j doesn't provide.
Class.forName("org.apache.log4j.config.PropertySetter", true, cl);
return new Log4jLoggerProvider();
}
And indeed I started receiving logging messages from Hibernate (via JBoss logging.)
> JBoss Logging does not detect log4j 2.0
> ---------------------------------------
>
> Key: JBLOGGING-94
> URL: https://issues.jboss.org/browse/JBLOGGING-94
> Project: JBoss Logging
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: jboss-logging-log4j
> Affects Versions: 3.1.2.GA
> Environment: Hibernate
> Reporter: Henry Clout
> Assignee: David Lloyd
>
> The class org.jboss.logging.LoggerProviders checkes for the presence of log4j using the code:
> {code}
> private static LoggerProvider tryLog4j(final ClassLoader cl) throws ClassNotFoundException {
> Class.forName("org.apache.log4j.LogManager", true, cl);
> // JBLOGGING-65 - slf4j can disguise itself as log4j. Test for a class that slf4j doesn't provide.
> Class.forName("org.apache.log4j.Hierarchy", true, cl);
> return new Log4jLoggerProvider();
> }
> {code}
> However, despite having the log4j-1.2-api-2.0.jar bridge included, this fails as the class org.apache.log4j.Hierarchy is not present in log4j 2.0.
> I worked around this by forcing JBoss logging to use slf4j (which is then proxied to log4j) by setting the -Dorg.jboss.logging.provider=slf4j option.
> As a proper fix, however, how about checking for a class that is included in log4j 1.2, 2.0 but not slf4j? org.apache.log4j.config.PropertySetter seems to tick the box.
> I tested changing the afore mentioned method to:
> {code}
> private static LoggerProvider tryLog4j(final ClassLoader cl) throws ClassNotFoundException {
> Class.forName("org.apache.log4j.LogManager", true, cl);
> // JBLOGGING-65 - slf4j can disguise itself as log4j. Test for a class that slf4j doesn't provide.
> Class.forName("org.apache.log4j.config.PropertySetter", true, cl);
> return new Log4jLoggerProvider();
> }
> {code}
> And indeed I started receiving logging messages from Hibernate (via JBoss logging.)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 12 months