December 2013 - jboss-jira - Jboss List Archives

[JBoss JIRA] (LOGMGR-89) LogContext's root logger is not created with a strong child hash map when strong=true

by James Perkins (JIRA)

[ https://issues.jboss.org/browse/LOGMGR-89?page=com.atlassian.jira.plugin.... ] James Perkins resolved LOGMGR-89. --------------------------------- Fix Version/s: 1.2.3.GA 1.3.3.Final 1.4.4.Final 1.5.2.Final 2.0.0.Beta1 Resolution: Done Pull request has been merged > LogContext's root logger is not created with a strong child hash map when strong=true > ------------------------------------------------------------------------------------- > > Key: LOGMGR-89 > URL: https://issues.jboss.org/browse/LOGMGR-89 > Project: JBoss Log Manager > Issue Type: Bug > Security Level: Public(Everyone can see) > Environment: This issue happens on 32-bit JVMs, and I can reproduce it on JDK 6 (64-bit) > Reporter: Kyle Lape > Assignee: David Lloyd > Fix For: 1.2.3.GA, 1.3.3.Final, 1.4.4.Final, 1.5.2.Final, 2.0.0.Beta1 > > > When deploying an application in EAP 6 that has a log4j.xml that is deployed by the logging subsystem, it seems that the LogContext is somehow losing a reference to a custom logger, causing all configuration for that logger to be lost. > Given this configuration > {code:xml} > <?xml version="1.0" encoding="UTF-8"?> > <!DOCTYPE log4j:configuration SYSTEM "log4j.dtd"> > <log4j:configuration xmlns:log4j="http://jakarta.apache.org/log4j/" debug="true"> > <appender name="SAMPLE_APP" class="org.apache.log4j.RollingFileAppender"> > <param name="File" value="${jboss.server.log.dir}/SampleApp.log"/> > <param name="MaxFileSize" value="2MB"/> > <param name="MaxBackupIndex" value="5"/> > <param name="Append" value="true"/> > <layout class="org.apache.log4j.PatternLayout"> > <param name="ConversionPattern" value="%d %c [%t] %-5p - %m%n"/> > </layout> > </appender> > <appender name="SAMPLE_APP_MDB" class="org.apache.log4j.RollingFileAppender"> > <param name="File" value="${jboss.server.log.dir}/SampleApp-MDB.log"/> > <param name="MaxFileSize" value="2MB"/> > <param name="MaxBackupIndex" value="5"/> > <param name="Append" value="true"/> > <layout class="org.apache.log4j.PatternLayout"> > <param name="ConversionPattern" value="%d %c [%t] %-5p - %m%n"/> > </layout> > </appender> > <logger name="com.redhat" additivity="false"> > <level value="TRACE"/> > <appender-ref ref="SAMPLE_APP_MDB"/> > </logger> > <root> > <priority value="TRACE"/> > <appender-ref ref="SAMPLE_APP"/> > </root> > </log4j:configuration> > {code} > Every log message ends up in {{SAMPLE_APP}}, regardless of which logger was used. One message like this is also printed to the log: > {noformat} > 11:33:00,110 INFO [stdout] (Finalizer) log4j: Finalizing appender named [SAMPLE_APP_MDB]. > {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, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2643) JBOSS_LOG_DIR is checked but not used to set jboss.server.log.dir

by Stian Lund (JIRA)

[ https://issues.jboss.org/browse/WFLY-2643?page=com.atlassian.jira.plugin.... ] Stian Lund edited comment on WFLY-2643 at 12/12/13 1:45 PM: ------------------------------------------------------------ Are you sure about that? There would be little point in checking for the value being set, if it is only the Java property that controls the setting. In addition, the value of for instance JBOSS_BASE_DIR is checked for in the same way but is also used to set a property on launch. I would be interested to know the reasoning behind LOG_DIR not being considered to have the same use? The reason I ask, is I would like to have LOG_DIR set in init (it already wraps the location of CONSOLE_LOG), and not have to code the property into standalone.conf as well, which is not very elegant IMO. was (Author: pathduck): Are you sure about that? There would be little point in checking for the value being set, if it is only the Java property that controls the setting. In addition, the value of for instance JBOSS_BASE_DIR is checked for in the same way but is also used to set a property on launch. I would be interested to know the reasoning behind LOG_DIR not being considered to have the same use? The reason I ask, is I would like to have LOG_DIR set in init (it already wraps the location of CONSOLE_LOG), and not have to code the property into standalone.conf as well, whixh is not very elegant IMO. > JBOSS_LOG_DIR is checked but not used to set jboss.server.log.dir > ----------------------------------------------------------------- > > Key: WFLY-2643 > URL: https://issues.jboss.org/browse/WFLY-2643 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Logging, Server > Affects Versions: JBoss AS7 7.1.1.Final, 8.0.0.Beta1 > Environment: All > Reporter: Stian Lund > Assignee: James Perkins > Labels: jbossas, logging, wildfly > > In standalone/domain start scripts (standalone.sh/bat) the value of environment variable JBOSS_LOG_DIR is checked for: > {code} > # determine the default log dir, if not set > if [ "x$JBOSS_LOG_DIR" = "x" ]; then > JBOSS_LOG_DIR="$JBOSS_BASE_DIR/log" > fi > {code} > However, this is not actually used to set the value of Java property jboss.server.log.dir. > {code} > -Djboss.home.dir="$JBOSS_HOME" > -Djboss.server.base.dir="$JBOSS_BASE_DIR" > "$SERVER_OPTS" > {code} > (It should be set at the same place) > This leads Jboss/Wildfly/EAP to assume the default value of $JBOSS_BASE_DIR/log. > This is a problem for those who want to override the location of the server.log files. -- 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, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2643) JBOSS_LOG_DIR is checked but not used to set jboss.server.log.dir

by Stian Lund (JIRA)

[ https://issues.jboss.org/browse/WFLY-2643?page=com.atlassian.jira.plugin.... ] Stian Lund commented on WFLY-2643: ---------------------------------- Are you sure about that? There would be little point in checking for the value being set, if it is only the Java property that controls the setting. In addition, the value of for instance JBOSS_BASE_DIR is checked for in the same way but is also used to set a property on launch. I would be interested to know the reasoning behind LOG_DIR not being considered to have the same use? The reason I ask, is I would like to have LOG_DIR set in init (it already wraps the location of CONSOLE_LOG), and not have to code the property into standalone.conf as well, whixh is not very elegant IMO. > JBOSS_LOG_DIR is checked but not used to set jboss.server.log.dir > ----------------------------------------------------------------- > > Key: WFLY-2643 > URL: https://issues.jboss.org/browse/WFLY-2643 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Logging, Server > Affects Versions: JBoss AS7 7.1.1.Final, 8.0.0.Beta1 > Environment: All > Reporter: Stian Lund > Assignee: James Perkins > Labels: jbossas, logging, wildfly > > In standalone/domain start scripts (standalone.sh/bat) the value of environment variable JBOSS_LOG_DIR is checked for: > {code} > # determine the default log dir, if not set > if [ "x$JBOSS_LOG_DIR" = "x" ]; then > JBOSS_LOG_DIR="$JBOSS_BASE_DIR/log" > fi > {code} > However, this is not actually used to set the value of Java property jboss.server.log.dir. > {code} > -Djboss.home.dir="$JBOSS_HOME" > -Djboss.server.base.dir="$JBOSS_BASE_DIR" > "$SERVER_OPTS" > {code} > (It should be set at the same place) > This leads Jboss/Wildfly/EAP to assume the default value of $JBOSS_BASE_DIR/log. > This is a problem for those who want to override the location of the server.log files. -- 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, 11 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-249) Handle conflicts when using @position in declared types

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/DROOLS-249?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on DROOLS-249: ------------------------------------------------ Marek Winkler <mwinkler(a)redhat.com> changed the Status of [bug 1021812|https://bugzilla.redhat.com/show_bug.cgi?id=1021812] from ON_QA to VERIFIED > Handle conflicts when using @position in declared types > ------------------------------------------------------- > > Key: DROOLS-249 > URL: https://issues.jboss.org/browse/DROOLS-249 > Project: Drools > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 5.5.0.Final, 6.0.0.CR2 > Reporter: Davide Sottara > Assignee: Mario Fusco > Priority: Minor > Fix For: 5.5.1.Final, 6.0.0.Final > > > declare A > f : int @position(2) > g : int @position(1) > end > declare B extends A > h : int @position(3) > i : int @position(2) > end > The resulting field order may not be deterministic because of > - the clashes (2) > - the missing pos (0) > this is dangerous when used with positional constraints > B( $x, $y, $z, $w ; ) > Marked as minor because of the obvious workaround -- 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, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2646) Expose patch description through mgmt API

by Emanuel Muckenhuber (JIRA)

Emanuel Muckenhuber created WFLY-2646: ----------------------------------------- Summary: Expose patch description through mgmt API Key: WFLY-2646 URL: https://issues.jboss.org/browse/WFLY-2646 Project: WildFly Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Patching Affects Versions: 8.0.0.CR1 Reporter: Emanuel Muckenhuber Fix For: 8.0.0.Final It should be possible to view the description of an installed patch through the mgmt API (maybe patch history). The information is stored as part of the backed up patch.xml. -- 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, 11 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-178) NoSuchMethodError at runtime due to eval in query (BW chaining)

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/DROOLS-178?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on DROOLS-178: ------------------------------------------------ Marek Winkler <mwinkler(a)redhat.com> changed the Status of [bug 1021810|https://bugzilla.redhat.com/show_bug.cgi?id=1021810] from ON_QA to VERIFIED > NoSuchMethodError at runtime due to eval in query (BW chaining) > --------------------------------------------------------------- > > Key: DROOLS-178 > URL: https://issues.jboss.org/browse/DROOLS-178 > Project: Drools > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 5.5.0.Final > Reporter: Wolfgang Laun > Assignee: Mario Fusco > Priority: Critical > Fix For: 5.5.1.Final, 6.0.0.Final > > > An eval CW in a query used in a BW chaining rule compiles, but causes a NoSuchMethodError when executed. > Exception in thread "main" java.lang.NoSuchMethodError: > pythagoras.Rule_isTriple_17ac16f7237046ee9562afce35dfe174.eval0(III)Z > at pythagoras.Rule_isTriple_17ac16f7237046ee9562afce35dfe174Eval0InvokerGenerated.evaluate(Unknown > Source) > at pythagoras.Rule_isTriple_17ac16f7237046ee9562afce35dfe174Eval0Invoker.evaluate(Unknown > Source) > at org.drools.rule.EvalCondition.isAllowed(EvalCondition.java:114) > at org.drools.reteoo.EvalConditionNode.assertLeftTuple(EvalConditionNode.java:176) > at org.drools.reteoo.SingleLeftTupleSinkAdapter.doPropagateAssertLeftTuple(SingleLeftTupleSinkAdapter.java:196) > at org.drools.reteoo.SingleLeftTupleSinkAdapter.propagateAssertLeftTuple(SingleLeftTupleSinkAdapter.java:71) > at org.drools.reteoo.JoinNode.propagateFromRight(JoinNode.java:159) > at org.drools.reteoo.JoinNode.assertObject(JoinNode.java:148) > at org.drools.reteoo.CompositeObjectSinkAdapter.doPropagateAssertObject(CompositeObjectSinkAdapter.java:497) > at org.drools.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:382) > at org.drools.reteoo.ObjectTypeNode.assertObject(ObjectTypeNode.java:235) > at org.drools.reteoo.EntryPointNode.assertObject(EntryPointNode.java:240) > at org.drools.common.NamedEntryPoint.insert(NamedEntryPoint.java:350) > at org.drools.common.NamedEntryPoint.insert(NamedEntryPoint.java:311) > at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:903) > at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:847) > at org.drools.impl.StatefulKnowledgeSessionImpl.insert(StatefulKnowledgeSessionImpl.java:269) > at pythagoras.Main.makeFacts(Main.java:94) -- 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, 11 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-251) Classloader fails to resolve when annotation and declared class have the same name

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/DROOLS-251?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on DROOLS-251: ------------------------------------------------ Marek Winkler <mwinkler(a)redhat.com> changed the Status of [bug 1021806|https://bugzilla.redhat.com/show_bug.cgi?id=1021806] from ON_QA to VERIFIED > Classloader fails to resolve when annotation and declared class have the same name > ---------------------------------------------------------------------------------- > > Key: DROOLS-251 > URL: https://issues.jboss.org/browse/DROOLS-251 > Project: Drools > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 5.5.0.Final, 6.0.0.CR2 > Reporter: Davide Sottara > Assignee: Mario Fusco > Fix For: 5.5.1.Final, 6.0.0.Final > > > package test > declare Annot > fld : int @Annot > end > The packagebuilder type resolver will confuse the annotation with the declared class and throw exceptions (varies depending on optional import > statements) -- 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, 11 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-295) Phreak mode does not evaluate 'from collect' correctly.

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/DROOLS-295?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on DROOLS-295: ------------------------------------------------ Marek Winkler <mwinkler(a)redhat.com> changed the Status of [bug 1018296|https://bugzilla.redhat.com/show_bug.cgi?id=1018296] from ON_QA to VERIFIED > Phreak mode does not evaluate 'from collect' correctly. > ------------------------------------------------------- > > Key: DROOLS-295 > URL: https://issues.jboss.org/browse/DROOLS-295 > Project: Drools > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 6.0.0.CR4 > Environment: Mac OS-X 10.8.5, Oracle Hotspot 1.7.0_40, Drools 6.1.0-SNAPSHOT > Reporter: Duncan Doyle > Assignee: Mario Fusco > Fix For: 6.0.0.Final > > > Reproducer project at: https://github.com/DuncanDoyle/Drools6PhreakFromCollectIssue > Run 'mvn clean test'. There are 2 tests which execute exactly the same thing against the same ruleset, one in ReteOO mode and one in Phreak. The result of the Phreak test is incorrect. There seems to be an issue with the 'from collect' in Phreak mode. > Please note that I'm using Drools 6.0.0-SNAPSHOT, as 6.0.0.Cr4-Pre1 contains a bug which causes the 'from collect' to go into an infinite loop. See Drools-276 > -- 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, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2645) SFSB containing injected DataSource fails to passivate/serialize

by Paul Ferraro (JIRA)

[ https://issues.jboss.org/browse/WFLY-2645?page=com.atlassian.jira.plugin.... ] Paul Ferraro edited comment on WFLY-2645 at 12/12/13 12:11 PM: --------------------------------------------------------------- Moving this issue back to WildFly. This is an integration bug. was (Author: pferraro): Moving this issue back to WildFly. > SFSB containing injected DataSource fails to passivate/serialize > ---------------------------------------------------------------- > > Key: WFLY-2645 > URL: https://issues.jboss.org/browse/WFLY-2645 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: JCA > Affects Versions: 8.0.0.Beta1 > Reporter: Paul Ferraro > Assignee: Stefano Maestri > Priority: Critical > Fix For: 8.0.0.CR1 > > > See JBPAPP6-1762 for details. -- 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, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2645) SFSB containing injected DataSource fails to passivate/serialize

by Paul Ferraro (JIRA)

[ https://issues.jboss.org/browse/WFLY-2645?page=com.atlassian.jira.plugin.... ] Paul Ferraro updated WFLY-2645: ------------------------------- Summary: SFSB containing injected DataSource fails to passivate/serialize (was: DataSource marked as Serializable) > SFSB containing injected DataSource fails to passivate/serialize > ---------------------------------------------------------------- > > Key: WFLY-2645 > URL: https://issues.jboss.org/browse/WFLY-2645 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: JCA > Affects Versions: 8.0.0.Beta1 > Reporter: Paul Ferraro > Assignee: Stefano Maestri > Priority: Critical > Fix For: 8.0.0.CR1 > > > See JBPAPP6-1762 for details. -- 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, 11 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 December 2013