October 2014 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-3968) access log doesn't support %{r, xxx}

by Stuart Douglas (JIRA)

[ https://issues.jboss.org/browse/WFLY-3968?page=com.atlassian.jira.plugin.... ] Stuart Douglas moved UNDERTOW-330 to WFLY-3968: ----------------------------------------------- Project: WildFly (was: Undertow) Key: WFLY-3968 (was: UNDERTOW-330) Affects Version/s: 9.0.0.Alpha1 8.1.0.Final (was: 1.0.15.Final) Component/s: Web (Undertow) (was: Core) > access log doesn't support %{r,xxx} > ----------------------------------- > > Key: WFLY-3968 > URL: https://issues.jboss.org/browse/WFLY-3968 > Project: WildFly > Issue Type: Bug > Components: Web (Undertow) > Affects Versions: 9.0.0.Alpha1, 8.1.0.Final > Environment: Wildfly 8.1.0.Final > Reporter: Vsevolod Golovanov > Assignee: Stuart Douglas > > AccessLogHandler's javadoc mentions: > {quote} > {{%\{r,xxx\}}} xxx is an attribute in the ServletRequest > {quote} > But adding the following to access log pattern > {code} > %{r,javax.servlet.error.status_code} > {code} > results in a server log message: > {code} > 19:55:55,432 ERROR [undertow] (MSC service thread 1-6) UT005017: Unknown variable %{r,javax.servlet.error.status_code} > {code} -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years

1
0
0 / 0

[JBoss JIRA] (WFCORE-160) Bash scripts should not attempt to expand argument properties

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFCORE-160?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on WFCORE-160: ------------------------------------------------ James Perkins <jperkins(a)redhat.com> changed the Status of [bug 1145960|https://bugzilla.redhat.com/show_bug.cgi?id=1145960] from ON_QA to POST > Bash scripts should not attempt to expand argument properties > ------------------------------------------------------------- > > Key: WFCORE-160 > URL: https://issues.jboss.org/browse/WFCORE-160 > Project: WildFly Core > Issue Type: Bug > Components: Scripts > Reporter: James Perkins > Assignee: James Perkins > > Scripts that parse the command line arguments use a pattern like > {code} > while [ "$#" -gt 0 ] > do > case "$1" in > *) > CLI_OPTS="$CLI_OPTS \"$1\"" > ;; > esac > shift > done > {code} > The {{CLI_OPTS="$CLI_OPTS \"$1\""}} should be {{CLI_OPTS="$CLI_OPTS '$1'"}} -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years

1
0
0 / 0

[JBoss JIRA] (WFCORE-160) Bash scripts should not attempt to expand argument properties

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFCORE-160?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration updated WFCORE-160: ------------------------------------------- Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1145960 > Bash scripts should not attempt to expand argument properties > ------------------------------------------------------------- > > Key: WFCORE-160 > URL: https://issues.jboss.org/browse/WFCORE-160 > Project: WildFly Core > Issue Type: Bug > Components: Scripts > Reporter: James Perkins > Assignee: James Perkins > > Scripts that parse the command line arguments use a pattern like > {code} > while [ "$#" -gt 0 ] > do > case "$1" in > *) > CLI_OPTS="$CLI_OPTS \"$1\"" > ;; > esac > shift > done > {code} > The {{CLI_OPTS="$CLI_OPTS \"$1\""}} should be {{CLI_OPTS="$CLI_OPTS '$1'"}} -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years

1
0
0 / 0

[JBoss JIRA] (WFCORE-160) Bash scripts should not attempt to expand argument properties

by James Perkins (JIRA)

James Perkins created WFCORE-160: ------------------------------------ Summary: Bash scripts should not attempt to expand argument properties Key: WFCORE-160 URL: https://issues.jboss.org/browse/WFCORE-160 Project: WildFly Core Issue Type: Bug Components: Scripts Reporter: James Perkins Assignee: James Perkins Scripts that parse the command line arguments use a pattern like {code} while [ "$#" -gt 0 ] do case "$1" in *) CLI_OPTS="$CLI_OPTS \"$1\"" ;; esac shift done {code} The {{CLI_OPTS="$CLI_OPTS \"$1\""}} should be {{CLI_OPTS="$CLI_OPTS '$1'"}} -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years

1
0
0 / 0

[JBoss JIRA] (JBLOGGING-111) LoggerProvider configured with new ServiceLoader crash

by Frederic Allard (JIRA)

Frederic Allard created JBLOGGING-111: ----------------------------------------- Summary: LoggerProvider configured with new ServiceLoader crash Key: JBLOGGING-111 URL: https://issues.jboss.org/browse/JBLOGGING-111 Project: JBoss Logging Issue Type: Bug Affects Versions: 3.2.0.Beta1 Environment: Weblogic 10.3.2.0 Configured in ejb jar, deployed by an ear file Reporter: Frederic Allard Assignee: James Perkins There is a new feature in the beta which uses the ServiceLoader to specify a LoggerProvider to be used by JBoss Logging. org.jboss.logging.LoggerProviders snippet : {code} // Next try for a service provider try { final ServiceLoader<LoggerProvider> loader = ServiceLoader.load(LoggerProvider.class, cl); if (loader.iterator().hasNext()) { return loader.iterator().next(); } } catch (Throwable ignore) { // TODO consider printing the stack trace as it should only happen once } {code} When you try to configure a provider (ex. org.jboss.logging.Slf4jLoggerProvider), the ServiceLoader crash silently and ignore the provider. {code} java.util.ServiceConfigurationError: org.jboss.logging.LoggerProvider: Provider org.jboss.logging.Slf4jLoggerProvider could not be instantiated: java.lang.IllegalAccessException: Class java.util.ServiceLoader$LazyIterator can not access a member of class org.jboss.logging.Slf4jLoggerProvider with modifiers "" at java.util.ServiceLoader.fail(ServiceLoader.java:207) at java.util.ServiceLoader.access$100(ServiceLoader.java:164) at java.util.ServiceLoader$LazyIterator.next(ServiceLoader.java:353) at java.util.ServiceLoader$1.next(ServiceLoader.java:421) at org.jboss.logging.LoggerProviders.findProvider(LoggerProviders.java:70) at org.jboss.logging.LoggerProviders.find(LoggerProviders.java:32) at org.jboss.logging.LoggerProviders.<clinit>(LoggerProviders.java:29) at org.jboss.logging.Logger.getLogger(Logger.java:2177) at org.jboss.logging.Logger$1.run(Logger.java:2277) at java.security.AccessController.doPrivileged(Native Method) at org.jboss.logging.Logger.getMessageLogger(Logger.java:2241) at org.jboss.logging.Logger.getMessageLogger(Logger.java:2228) at org.hibernate.cfg.Configuration.<clinit>(Configuration.java:176) ... {code} This is caused by the fact that all JBoss providers are not public classes and are instead package classes. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years

1
0
0 / 0

[JBoss JIRA] (DROOLS-629) NullPointerException thrown on next call to insert and fireAllRules after stream garbage collection runs

by Mario Fusco (JIRA)

[ https://issues.jboss.org/browse/DROOLS-629?page=com.atlassian.jira.plugin... ] Mario Fusco resolved DROOLS-629. -------------------------------- Fix Version/s: 6.2.0.CR1 Resolution: Done Fixed by https://github.com/droolsjbpm/drools/commit/12d01aa18edbb9570d6dbf7cc64c8... > NullPointerException thrown on next call to insert and fireAllRules after stream garbage collection runs > -------------------------------------------------------------------------------------------------------- > > Key: DROOLS-629 > URL: https://issues.jboss.org/browse/DROOLS-629 > Project: Drools > Issue Type: Bug > Affects Versions: 6.1.0.Final, 6.2.0.Beta3 > Reporter: Mike Wilson > Assignee: Mario Fusco > Fix For: 6.2.0.CR1 > > Attachments: drools-gc-causes-npe-example.zip > > > I have observed that the following NullPointerException (NPE) occurs consistently with a very specific set of rules and a very specific set of inputs into a stream session: > {code} > java.lang.NullPointerException > at org.drools.core.util.AbstractHashTable$SingleIndex.equal(AbstractHashTable.java:491) > at org.drools.core.util.index.LeftTupleList.matches(LeftTupleList.java:266) > at org.drools.core.util.index.LeftTupleIndexHashTable.get(LeftTupleIndexHashTable.java:434) > at org.drools.core.util.index.LeftTupleIndexHashTable.getFirst(LeftTupleIndexHashTable.java:217) > at org.drools.core.reteoo.BetaNode.getFirstLeftTuple(BetaNode.java:443) > at org.drools.core.phreak.PhreakJoinNode.doRightInserts(PhreakJoinNode.java:144) > at org.drools.core.phreak.PhreakJoinNode.doNode(PhreakJoinNode.java:56) > at org.drools.core.phreak.RuleNetworkEvaluator.switchOnDoBetaNode(RuleNetworkEvaluator.java:548) > at org.drools.core.phreak.RuleNetworkEvaluator.evalBetaNode(RuleNetworkEvaluator.java:534) > at org.drools.core.phreak.RuleNetworkEvaluator.innerEval(RuleNetworkEvaluator.java:334) > at org.drools.core.phreak.RuleNetworkEvaluator.outerEval(RuleNetworkEvaluator.java:161) > at org.drools.core.phreak.RuleNetworkEvaluator.evaluateNetwork(RuleNetworkEvaluator.java:116) > at org.drools.core.phreak.RuleExecutor.reEvaluateNetwork(RuleExecutor.java:229) > at org.drools.core.phreak.RuleExecutor.evaluateNetworkAndFire(RuleExecutor.java:98) > at org.drools.core.common.DefaultAgenda.fireNextItem(DefaultAgenda.java:988) > at org.drools.core.common.DefaultAgenda.fireAllRules(DefaultAgenda.java:1274) > at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1281) > at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1254) > ... > {code} > The exception always occurs on the next call to "insert" and "fireAllRules" after the following method is invoked within the session: org.drools.core.common.DefaultAgenda$DefaultGarbageCollector.forceGcUnlinkedRules(). > I have attached a maven project that contains a JUnit test, which reproduces this exception using Drools version 6.2.0.Beta3. > A side effect of this exeption occurring in the middle of fireAllRules is that an extra fact is left over in working memory, which is essentially a memory leak. I assume this is because the evaluation of the LHS of the rules is what causes the NPE to occur, so the fact is not deleted, because the RHS of the rules don't execute. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years

1
0
0 / 0

[JBoss JIRA] (DROOLS-629) NullPointerException thrown on next call to insert and fireAllRules after stream garbage collection runs

by Mario Fusco (JIRA)

[ https://issues.jboss.org/browse/DROOLS-629?page=com.atlassian.jira.plugin... ] Mario Fusco reassigned DROOLS-629: ---------------------------------- Assignee: Mario Fusco (was: Mark Proctor) > NullPointerException thrown on next call to insert and fireAllRules after stream garbage collection runs > -------------------------------------------------------------------------------------------------------- > > Key: DROOLS-629 > URL: https://issues.jboss.org/browse/DROOLS-629 > Project: Drools > Issue Type: Bug > Affects Versions: 6.1.0.Final, 6.2.0.Beta3 > Reporter: Mike Wilson > Assignee: Mario Fusco > Attachments: drools-gc-causes-npe-example.zip > > > I have observed that the following NullPointerException (NPE) occurs consistently with a very specific set of rules and a very specific set of inputs into a stream session: > {code} > java.lang.NullPointerException > at org.drools.core.util.AbstractHashTable$SingleIndex.equal(AbstractHashTable.java:491) > at org.drools.core.util.index.LeftTupleList.matches(LeftTupleList.java:266) > at org.drools.core.util.index.LeftTupleIndexHashTable.get(LeftTupleIndexHashTable.java:434) > at org.drools.core.util.index.LeftTupleIndexHashTable.getFirst(LeftTupleIndexHashTable.java:217) > at org.drools.core.reteoo.BetaNode.getFirstLeftTuple(BetaNode.java:443) > at org.drools.core.phreak.PhreakJoinNode.doRightInserts(PhreakJoinNode.java:144) > at org.drools.core.phreak.PhreakJoinNode.doNode(PhreakJoinNode.java:56) > at org.drools.core.phreak.RuleNetworkEvaluator.switchOnDoBetaNode(RuleNetworkEvaluator.java:548) > at org.drools.core.phreak.RuleNetworkEvaluator.evalBetaNode(RuleNetworkEvaluator.java:534) > at org.drools.core.phreak.RuleNetworkEvaluator.innerEval(RuleNetworkEvaluator.java:334) > at org.drools.core.phreak.RuleNetworkEvaluator.outerEval(RuleNetworkEvaluator.java:161) > at org.drools.core.phreak.RuleNetworkEvaluator.evaluateNetwork(RuleNetworkEvaluator.java:116) > at org.drools.core.phreak.RuleExecutor.reEvaluateNetwork(RuleExecutor.java:229) > at org.drools.core.phreak.RuleExecutor.evaluateNetworkAndFire(RuleExecutor.java:98) > at org.drools.core.common.DefaultAgenda.fireNextItem(DefaultAgenda.java:988) > at org.drools.core.common.DefaultAgenda.fireAllRules(DefaultAgenda.java:1274) > at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1281) > at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1254) > ... > {code} > The exception always occurs on the next call to "insert" and "fireAllRules" after the following method is invoked within the session: org.drools.core.common.DefaultAgenda$DefaultGarbageCollector.forceGcUnlinkedRules(). > I have attached a maven project that contains a JUnit test, which reproduces this exception using Drools version 6.2.0.Beta3. > A side effect of this exeption occurring in the middle of fireAllRules is that an extra fact is left over in working memory, which is essentially a memory leak. I assume this is because the evaluation of the LHS of the rules is what causes the NPE to occur, so the fact is not deleted, because the RHS of the rules don't execute. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years

1
0
0 / 0

[JBoss JIRA] (WFLY-3966) Update saaj-impl based on fix for SAAJ-74

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-3966?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration updated WFLY-3966: ------------------------------------------ Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1151526, https://bugzilla.redhat.com/show_bug.cgi?id=1151530 (was: https://bugzilla.redhat.com/show_bug.cgi?id=1151526) > Update saaj-impl based on fix for SAAJ-74 > ----------------------------------------- > > Key: WFLY-3966 > URL: https://issues.jboss.org/browse/WFLY-3966 > Project: WildFly > Issue Type: Component Upgrade > Components: Web Services > Affects Versions: 9.0.0.Alpha1 > Reporter: Mustafa Musaji > > SOAP 1.2 spec says that HTTP 400 should return a soapFault error. At the moment the code only returns SoapFault for HTTP 500 which is wrong. > The issue is recorded in the SAAJ JIRA: https://java.net/jira/browse/SAAJ-74 -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years

1
0
0 / 0

[JBoss JIRA] (WFLY-3966) Update saaj-impl based on fix for SAAJ-74

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-3966?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-3966: ----------------------------------------------- Mustafa Musaji <mmusaji(a)redhat.com> changed the Status of [bug 1151530|https://bugzilla.redhat.com/show_bug.cgi?id=1151530] from NEW to ASSIGNED > Update saaj-impl based on fix for SAAJ-74 > ----------------------------------------- > > Key: WFLY-3966 > URL: https://issues.jboss.org/browse/WFLY-3966 > Project: WildFly > Issue Type: Component Upgrade > Components: Web Services > Affects Versions: 9.0.0.Alpha1 > Reporter: Mustafa Musaji > > SOAP 1.2 spec says that HTTP 400 should return a soapFault error. At the moment the code only returns SoapFault for HTTP 500 which is wrong. > The issue is recorded in the SAAJ JIRA: https://java.net/jira/browse/SAAJ-74 -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years

1
0
0 / 0

[JBoss JIRA] (WFLY-3966) Update saaj-impl based on fix for SAAJ-74

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-3966?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-3966: ----------------------------------------------- Mustafa Musaji <mmusaji(a)redhat.com> changed the Status of [bug 1151526|https://bugzilla.redhat.com/show_bug.cgi?id=1151526] from NEW to ASSIGNED > Update saaj-impl based on fix for SAAJ-74 > ----------------------------------------- > > Key: WFLY-3966 > URL: https://issues.jboss.org/browse/WFLY-3966 > Project: WildFly > Issue Type: Component Upgrade > Components: Web Services > Affects Versions: 9.0.0.Alpha1 > Reporter: Mustafa Musaji > > SOAP 1.2 spec says that HTTP 400 should return a soapFault error. At the moment the code only returns SoapFault for HTTP 500 which is wrong. > The issue is recorded in the SAAJ JIRA: https://java.net/jira/browse/SAAJ-74 -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years

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 October 2014