January 2015 - jboss-jira - Jboss List Archives

[JBoss JIRA] (JBLOGGING-112) JBoss Logging doesn't recognize log4j implementation

by David Lloyd (JIRA)

[ https://issues.jboss.org/browse/JBLOGGING-112?page=com.atlassian.jira.plu... ] David Lloyd commented on JBLOGGING-112: --------------------------------------- This should be fixed in 3.2 as well. > JBoss Logging doesn't recognize log4j implementation > ---------------------------------------------------- > > Key: JBLOGGING-112 > URL: https://issues.jboss.org/browse/JBLOGGING-112 > Project: JBoss Logging > Issue Type: Bug > Affects Versions: 3.2.0.Final, 3.3.0.Alpha1 > Reporter: Richard Achmatowicz > Assignee: James Perkins > Fix For: 3.2.1.Final, 3.3.0.Alpha1 > > > There seems to be a typo in org.jboss.logging.LoggingProviders in the method tryLog4j(): the logging provider implementation used is Log4j2LoggerProvider, whereas it should be Log4jLoggerProvider. > The net effect is that if I have log4j jars on the classpath and include a log4j configuration, the configuration gets parsed but log4j is not used as the logging provider; instead, JDK logging provider is used. > -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4271) Wildfly BOM wrong dependencies

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/WFLY-4271?page=com.atlassian.jira.plugin.... ] Tomaz Cerar reassigned WFLY-4271: --------------------------------- Assignee: Tomaz Cerar (was: Jason Greene) > Wildfly BOM wrong dependencies > ------------------------------ > > Key: WFLY-4271 > URL: https://issues.jboss.org/browse/WFLY-4271 > Project: WildFly > Issue Type: Bug > Affects Versions: 8.2.0.Final > Environment: Wildfly 8.2.0.Final, BOM org.wildfly.bom:jboss-javaee-7.0-with-all:8.2.1.Final > Reporter: Vsevolod Golovanov > Assignee: Tomaz Cerar > > 1. The BOM {{org.wildfly.bom:jboss-javaee-7.0-with-all:8.2.1.Final}} (indirectly) imports {{org.jboss.resteasy:resteasy-jaxrs-all:3.0.10.Final}} that has the following dependencies: > {code} > <version.io.undertow>1.0.1.Final</version.io.undertow> > ... > <dependency> > <groupId>io.undertow</groupId> > <artifactId>undertow-servlet</artifactId> > <version>${version.io.undertow}</version> > </dependency> > <dependency> > <groupId>io.undertow</groupId> > <artifactId>undertow-core</artifactId> > <version>${version.io.undertow}</version> > </dependency> > {code} > The version should be 1.1.0.Final. The wrong version messes up debugging in Eclipse, and probably compiling in Eclipse. > 2. {{org.wildfly.bom:jboss-bom-parent:8.2.1.Final}}: > {code} > <version.org.hibernate-jpamodelgen>4.3.5.Final</version.org.hibernate-jpamodelgen> > {code} > , which affects {{org.wildfly.bom:jboss-javaee-7.0-with-hibernate:8.2.1.Final}}: > {code} > <dependency> > <groupId>org.hibernate</groupId> > <artifactId>hibernate-jpamodelgen</artifactId> > <version>${version.org.hibernate-jpamodelgen}</version> > </dependency> > {code} > Hibernate 4.3.7.Final from SourceForge has jpamodelgen 4.3.7.Final supplied. > Hoping for a BOM 8.2.2.Final release, because our project POMs are complex enough without workarounds for such errors. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4271) Wildfly BOM wrong dependencies

by Vsevolod Golovanov (JIRA)

Vsevolod Golovanov created WFLY-4271: ---------------------------------------- Summary: Wildfly BOM wrong dependencies Key: WFLY-4271 URL: https://issues.jboss.org/browse/WFLY-4271 Project: WildFly Issue Type: Bug Affects Versions: 8.2.0.Final Environment: Wildfly 8.2.0.Final, BOM org.wildfly.bom:jboss-javaee-7.0-with-all:8.2.1.Final Reporter: Vsevolod Golovanov Assignee: Jason Greene 1. The BOM {{org.wildfly.bom:jboss-javaee-7.0-with-all:8.2.1.Final}} (indirectly) imports {{org.jboss.resteasy:resteasy-jaxrs-all:3.0.10.Final}} that has the following dependencies: {code} <version.io.undertow>1.0.1.Final</version.io.undertow> ... <dependency> <groupId>io.undertow</groupId> <artifactId>undertow-servlet</artifactId> <version>${version.io.undertow}</version> </dependency> <dependency> <groupId>io.undertow</groupId> <artifactId>undertow-core</artifactId> <version>${version.io.undertow}</version> </dependency> {code} The version should be 1.1.0.Final. The wrong version messes up debugging in Eclipse, and probably compiling in Eclipse. 2. {{org.wildfly.bom:jboss-bom-parent:8.2.1.Final}}: {code} <version.org.hibernate-jpamodelgen>4.3.5.Final</version.org.hibernate-jpamodelgen> {code} , which affects {{org.wildfly.bom:jboss-javaee-7.0-with-hibernate:8.2.1.Final}}: {code} <dependency> <groupId>org.hibernate</groupId> <artifactId>hibernate-jpamodelgen</artifactId> <version>${version.org.hibernate-jpamodelgen}</version> </dependency> {code} Hibernate 4.3.7.Final from SourceForge has jpamodelgen 4.3.7.Final supplied. Hoping for a BOM 8.2.2.Final release, because our project POMs are complex enough without workarounds for such errors. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-507) Unit test FileSystemDeploymentServiceUnitTestCase fails on IBM JDK

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFCORE-507?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on WFCORE-507: ------------------------------------------------ Kabir Khan <kkhan(a)redhat.com> changed the Status of [bug 1182466|https://bugzilla.redhat.com/show_bug.cgi?id=1182466] from POST to MODIFIED > Unit test FileSystemDeploymentServiceUnitTestCase fails on IBM JDK > -------------------------------------------------------------------- > > Key: WFCORE-507 > URL: https://issues.jboss.org/browse/WFCORE-507 > Project: WildFly Core > Issue Type: Bug > Components: Test Suite > Affects Versions: 1.0.0.Alpha15 > Reporter: Emmanuel Hugonnet > Assignee: Emmanuel Hugonnet > Priority: Trivial > Fix For: 1.0.0.Alpha16 > > > Always on IBM JDK org.jboss.as.server.deployment.scanner.FileSystemDeploymentServiceUnitTestCase.testNoUndeployment fails with: > - java.net.ConnectException: Connection refused > - java.lang.UnsupportedOperationException: cannot get the capability, performing dispose of the retransforming environment -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (JBLOGGING-112) JBoss Logging doesn't recognize log4j implementation

by Richard Achmatowicz (JIRA)

[ https://issues.jboss.org/browse/JBLOGGING-112?page=com.atlassian.jira.plu... ] Richard Achmatowicz commented on JBLOGGING-112: ----------------------------------------------- Note: when the logging implementation is chosen via org.jboss.logging.provider, if certain classes cannot be found (e.g. org.apache.log4j.LogManager), a ClassNotFoundException is raised but then swallowed and another provider is chosen. If a user specifies a specific provider but either forgets to have the provider on the classpath or chooses the wrong maven artifact, it would be nice to log the ClassNotFoundException with an appropriate warning. I spent a lot of time trying to use log4j and found that the problem was having an old enough maven artifact on the classpath which contained the LogManager, and the only easy way to find the problem was but debugging the sources. > JBoss Logging doesn't recognize log4j implementation > ---------------------------------------------------- > > Key: JBLOGGING-112 > URL: https://issues.jboss.org/browse/JBLOGGING-112 > Project: JBoss Logging > Issue Type: Bug > Affects Versions: 3.2.0.Final, 3.3.0.Alpha1 > Reporter: Richard Achmatowicz > Assignee: James Perkins > Fix For: 3.3.0.Alpha1 > > > There seems to be a typo in org.jboss.logging.LoggingProviders in the method tryLog4j(): the logging provider implementation used is Log4j2LoggerProvider, whereas it should be Log4jLoggerProvider. > The net effect is that if I have log4j jars on the classpath and include a log4j configuration, the configuration gets parsed but log4j is not used as the logging provider; instead, JDK logging provider is used. > -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4259) ClassNotFound exception when connecting a remote HornetQ client over SSL

by Jon Kranes (JIRA)

[ https://issues.jboss.org/browse/WFLY-4259?page=com.atlassian.jira.plugin.... ] Jon Kranes updated WFLY-4259: ----------------------------- Description: When using HornetQ with a remote client connecting with SSL (using a netty-connector with ssl-enabled=true) the server throws an exception in ModuleClassLoader when the client attempts to connect. The exception is: java.lang.ClassNotFoundException: javax.net.SSLException After doing some investigation I was able to resolve this issue by adding a dependency in the io.netty module.xml file <dependencies> <module name="javax.api"/> <dependencies Without this dependency, it appear that Netty is unable to load classes that it needs from javax.net.ssl. was: When using HornetQ with a remote client connecting with SSL (using a netty-connector with ssl-enabled=true) the server throws an exception in ModuleClassLoader when the client attempts to connect. The exception is: java.lang.ClassNotFoundException: javax.net.SSLException After doing some investigation I was able to resolve this issue by adding a dependency in the io.netty module.xml file <dependencies> <module name="javax.api"/> <dependencies Without this dependency, it appear that Netty is unable to load classes that it needs from javax.net.ssl. NOTE: adding this dependency resolves the issue in Wildfly 8.2.0.Final. However, it does NOT resolve the issue in 8.1.0.Final. Even after adding this dependency I still got the ClassNotFoundException. > ClassNotFound exception when connecting a remote HornetQ client over SSL > ------------------------------------------------------------------------ > > Key: WFLY-4259 > URL: https://issues.jboss.org/browse/WFLY-4259 > Project: WildFly > Issue Type: Bug > Components: JMS > Affects Versions: 8.1.0.Final, 8.2.0.Final > Reporter: Jon Kranes > Assignee: Jeff Mesnil > > When using HornetQ with a remote client connecting with SSL (using a netty-connector with ssl-enabled=true) the server throws an exception in ModuleClassLoader when the client attempts to connect. The exception is: > java.lang.ClassNotFoundException: javax.net.SSLException > After doing some investigation I was able to resolve this issue by adding a dependency in the io.netty module.xml file > <dependencies> > <module name="javax.api"/> > <dependencies > Without this dependency, it appear that Netty is unable to load classes that it needs from javax.net.ssl. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4259) ClassNotFound exception when connecting a remote HornetQ client over SSL

by Jon Kranes (JIRA)

[ https://issues.jboss.org/browse/WFLY-4259?page=com.atlassian.jira.plugin.... ] Jon Kranes updated WFLY-4259: ----------------------------- Workaround Description: The issue can be worked around by modifying the module.xml file as noted in the issue description. (was: The issue can be worked around in 8.2.0.Final by modifying the module.xml file as noted in the issue description. However this workaround does not seem to fix the issue in 8.1.0.Final) > ClassNotFound exception when connecting a remote HornetQ client over SSL > ------------------------------------------------------------------------ > > Key: WFLY-4259 > URL: https://issues.jboss.org/browse/WFLY-4259 > Project: WildFly > Issue Type: Bug > Components: JMS > Affects Versions: 8.1.0.Final, 8.2.0.Final > Reporter: Jon Kranes > Assignee: Jeff Mesnil > > When using HornetQ with a remote client connecting with SSL (using a netty-connector with ssl-enabled=true) the server throws an exception in ModuleClassLoader when the client attempts to connect. The exception is: > java.lang.ClassNotFoundException: javax.net.SSLException > After doing some investigation I was able to resolve this issue by adding a dependency in the io.netty module.xml file > <dependencies> > <module name="javax.api"/> > <dependencies > Without this dependency, it appear that Netty is unable to load classes that it needs from javax.net.ssl. > NOTE: adding this dependency resolves the issue in Wildfly 8.2.0.Final. However, it does NOT resolve the issue in 8.1.0.Final. Even after adding this dependency I still got the ClassNotFoundException. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-692) Can't resolve declared types in decision tables

by Marc Dzaebel (JIRA)

[ https://issues.jboss.org/browse/DROOLS-692?page=com.atlassian.jira.plugin... ] Marc Dzaebel updated DROOLS-692: -------------------------------- Description: Can't resolve _declared types_ within .drl in decision tables. (was: Can't resolve _declared types_ within .drl in decision tables) Forum Reference: http://drools-moved.46999.n3.nabble.com/Import-of-declared-type-in-other-..., https://groups.google.com/forum/#!topic/drools-usage/WxTGGaYrXq8 > Can't resolve declared types in decision tables > ----------------------------------------------- > > Key: DROOLS-692 > URL: https://issues.jboss.org/browse/DROOLS-692 > Project: Drools > Issue Type: Bug > Affects Versions: 6.0.0.Final, 6.1.0.Final, 6.2.0.CR4 > Environment: Win7, Office 356, JDK 8_u40, Eclipse-Luna, Compiler-Compliance: 1.8 > Reporter: Marc Dzaebel > Assignee: Mark Proctor > Labels: DecisionTables, DeclaredTypes > Attachments: DecisionTableTest.java, Sample.drl, Sample.xls > > > Can't resolve _declared types_ within .drl in decision tables. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-57) Deprecated resource is present in r-r-d of /subsystem=security/security-domain=*

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFCORE-57?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFCORE-57: ----------------------------------------------- Petr Kremensky <pkremens(a)redhat.com> changed the Status of [bug 1070214|https://bugzilla.redhat.com/show_bug.cgi?id=1070214] from ON_QA to VERIFIED > Deprecated resource is present in r-r-d of /subsystem=security/security-domain=* > -------------------------------------------------------------------------------- > > Key: WFCORE-57 > URL: https://issues.jboss.org/browse/WFCORE-57 > Project: WildFly Core > Issue Type: Enhancement > Components: Domain Management > Affects Versions: 1.0.0.Alpha4 > Reporter: Harald Pehl > Assignee: Emmanuel Hugonnet > Priority: Minor > Fix For: 1.0.0.Alpha9 > > > When executing > {code} > /subsystem=security/security-domain=*:read-resource-description(recursive-depth=2) > {code} > the acl subresource contains both the deprecated child-resource {{login-module}} and the new one called {{acl-module}}: > {code} > ... > "acl" => { > "description" => "Access control list configuration. Configures a list of ACL modules to be used.", > "model-description" => {"classic" => { > "description" => "Access control list configuration. Configures a list of ACL modules to be used.", > ... > "operations" => undefined, > "children" => { > "acl-module" => { > "description" => "ACL module", > "model-description" => {"*" => { > "description" => "List of authentication modules", > ... > "operations" => undefined, > "children" => {} > }} > }, > "login-module" => { > "description" => "Login module", > "model-description" => {"*" => undefined} > } > } > }} > }, > ... > {code} > However the deprecated subresource {{login-modules}} should only appear if setting {{include-aliases=true}} -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4269) redelivery ResourceAdapter Config is not respected when defined in more than one config.

by Jesper Pedersen (JIRA)

[ https://issues.jboss.org/browse/WFLY-4269?page=com.atlassian.jira.plugin.... ] Jesper Pedersen reassigned WFLY-4269: ------------------------------------- Assignee: (was: Jesper Pedersen) Component/s: EJB (was: JCA) > redelivery ResourceAdapter Config is not respected when defined in more than one config. > ---------------------------------------------------------------------------------------- > > Key: WFLY-4269 > URL: https://issues.jboss.org/browse/WFLY-4269 > Project: WildFly > Issue Type: Bug > Components: EJB > Affects Versions: 9.0.0.Alpha1 > Environment: All > Reporter: Jay Kumar SenSharma > > - If the MDB defines the "initialRedeliveryDelay" and "maximumRedeliveries" ActivationConfigProperty via annotation OR using "ejb-jar.xml" file, As well as if the "initialRedeliveryDelay" "config-property" is defined inside the <resource-adapter> section of standalone.xml then *both* are ignored, and it starts taking the default value of initialRedeliveryDelay for Activemq resource adapter as 1 Second see [1] > [1] http://activemq.apache.org/redelivery-policy.html -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 3 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 January 2015