July 2014 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-3575) Parameterize subsystem version in xsite testsuite xslt stylesheet

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/WFLY-3575?page=com.atlassian.jira.plugin.... ] Radoslav Husar reassigned WFLY-3575: ------------------------------------ Assignee: Radoslav Husar (was: Richard Achmatowicz) We should be able to let the tranformations ignore the schema whatsoever, so that upgrades dont break the test. I have done this in all transformation used by the perf tests so we could do it here too. > Parameterize subsystem version in xsite testsuite xslt stylesheet > ----------------------------------------------------------------- > > Key: WFLY-3575 > URL: https://issues.jboss.org/browse/WFLY-3575 > Project: WildFly > Issue Type: Task > Security Level: Public(Everyone can see) > Components: Clustering > Affects Versions: 8.1.0.Final > Reporter: Paul Ferraro > Assignee: Radoslav Husar > > I wasted a good couple of hours today trying to figure out why my changes broke the xsite tests. It turns out that the xslt scripts have the subsystem schema version hardcoded, and I had created a new schema version. > We should parameterize this, in the same way as the addCacheContainer.xsl stylesheet does. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-538) Unable to resolve class error , drools 5.5 in concurrent execution. JSR94Support and Spring

by Maruthi Shanmugam (JIRA)

[ https://issues.jboss.org/browse/DROOLS-538?page=com.atlassian.jira.plugin... ] Maruthi Shanmugam commented on DROOLS-538: ------------------------------------------ Hi Davide, I can compile the source code myself.. Would you able give me the instructions for the same... 6.* migration is not possible, because it would be a big leap for us. Meanwhile i also will get the reproducer for you. Can you share me the instruction for compiling the source > Unable to resolve class error , drools 5.5 in concurrent execution. JSR94Support and Spring > -------------------------------------------------------------------------------------------- > > Key: DROOLS-538 > URL: https://issues.jboss.org/browse/DROOLS-538 > Project: Drools > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 5.5.0.Final > Environment: Linux Red Hat , Enterprise, JDK 1.6, Drools 5.5.Final > Reporter: Maruthi Shanmugam > Assignee: Mark Proctor > Priority: Blocker > > We use Drools 5.5 and drool implementation is done through Spring JSR94Support API> > The Rule engine is called in concurrent mode, > i.e , JSR94Support.executeStateless(name,list) is executed through multiple threads. > And when the rules are executed we randomly get the following exception > org.drools.RuntimeDroolsException: Unable to resolve class 'someclass(this is sample)here actual class is printed>' > at org.drools.base.ClassFieldAccessorCache.getClass(ClassFieldAccessorCache.java:126) > at org.drools.base.ClassFieldAccessorCache.getClassObjectType(ClassFieldAccessorCache.java:48) > at org.drools.reteoo.ClassObjectTypeConf.<init>(ClassObjectTypeConf.java:83) > at org.drools.common.ObjectTypeConfigurationRegistry.getObjectTypeConf(ObjectTypeConfigurationRegistry.java:71) > at org.drools.common.NamedEntryPoint.insert(NamedEntryPoint.java:159) > at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:903) > at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:847) > at org.drools.reteoo.ReteooStatelessSession.executeWithResults(ReteooStatelessSession.java:273) > The rules are registered every 15 minutes through RuleAdministrator.registerRuleExecutionset , > so whenever we refresh the rules and the subsequent thread even after the registration is completed, fails with the above message. This happens only when the rules are invoked concurrently. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3575) Parameterize subsystem version in xsite testsuite xslt stylesheet

by Paul Ferraro (JIRA)

Paul Ferraro created WFLY-3575: ---------------------------------- Summary: Parameterize subsystem version in xsite testsuite xslt stylesheet Key: WFLY-3575 URL: https://issues.jboss.org/browse/WFLY-3575 Project: WildFly Issue Type: Task Security Level: Public (Everyone can see) Components: Clustering Affects Versions: 8.1.0.Final Reporter: Paul Ferraro Assignee: Richard Achmatowicz I wasted a good couple of hours today trying to figure out why my changes broke the xsite tests. It turns out that the xslt scripts have the subsystem schema version hardcoded, and I had created a new schema version. We should parameterize this, in the same way as the addCacheContainer.xsl stylesheet does. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-538) Unable to resolve class error , drools 5.5 in concurrent execution. JSR94Support and Spring

by Davide Sottara (JIRA)

[ https://issues.jboss.org/browse/DROOLS-538?page=com.atlassian.jira.plugin... ] Davide Sottara commented on DROOLS-538: --------------------------------------- I see the problem, the issue is that 5.6 was not fully thread-safe either. Any chance you can try the 6.x series, and the 6.1.CR in particular? 5.6 is final, too, so it won't be possible to include any new fix in that version (unless you can compile the source code yourself) It would interesting to see if the newer versions suffer from the same problem. Could you please create a reproducer for us to test? Thanks > Unable to resolve class error , drools 5.5 in concurrent execution. JSR94Support and Spring > -------------------------------------------------------------------------------------------- > > Key: DROOLS-538 > URL: https://issues.jboss.org/browse/DROOLS-538 > Project: Drools > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 5.5.0.Final > Environment: Linux Red Hat , Enterprise, JDK 1.6, Drools 5.5.Final > Reporter: Maruthi Shanmugam > Assignee: Mark Proctor > Priority: Blocker > > We use Drools 5.5 and drool implementation is done through Spring JSR94Support API> > The Rule engine is called in concurrent mode, > i.e , JSR94Support.executeStateless(name,list) is executed through multiple threads. > And when the rules are executed we randomly get the following exception > org.drools.RuntimeDroolsException: Unable to resolve class 'someclass(this is sample)here actual class is printed>' > at org.drools.base.ClassFieldAccessorCache.getClass(ClassFieldAccessorCache.java:126) > at org.drools.base.ClassFieldAccessorCache.getClassObjectType(ClassFieldAccessorCache.java:48) > at org.drools.reteoo.ClassObjectTypeConf.<init>(ClassObjectTypeConf.java:83) > at org.drools.common.ObjectTypeConfigurationRegistry.getObjectTypeConf(ObjectTypeConfigurationRegistry.java:71) > at org.drools.common.NamedEntryPoint.insert(NamedEntryPoint.java:159) > at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:903) > at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:847) > at org.drools.reteoo.ReteooStatelessSession.executeWithResults(ReteooStatelessSession.java:273) > The rules are registered every 15 minutes through RuleAdministrator.registerRuleExecutionset , > so whenever we refresh the rules and the subsequent thread even after the registration is completed, fails with the above message. This happens only when the rules are invoked concurrently. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-538) Unable to resolve class error , drools 5.5 in concurrent execution. JSR94Support and Spring

by Maruthi Shanmugam (JIRA)

[ https://issues.jboss.org/browse/DROOLS-538?page=com.atlassian.jira.plugin... ] Maruthi Shanmugam commented on DROOLS-538: ------------------------------------------ ClassName : ClassFieldAccessorCache This is the method which throws Exception during concurrency. Highlighted Line number throws the exception public Class getClass(String className) { try { return this.classLoader.loadClass( className ); // Exception happens here. And This happens only during multithreading or concurrent calls. } catch ( ClassNotFoundException e ) { throw new RuntimeDroolsException( "Unable to resolve class '" + className + "'" ); } } > Unable to resolve class error , drools 5.5 in concurrent execution. JSR94Support and Spring > -------------------------------------------------------------------------------------------- > > Key: DROOLS-538 > URL: https://issues.jboss.org/browse/DROOLS-538 > Project: Drools > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 5.5.0.Final > Environment: Linux Red Hat , Enterprise, JDK 1.6, Drools 5.5.Final > Reporter: Maruthi Shanmugam > Assignee: Mark Proctor > Priority: Blocker > > We use Drools 5.5 and drool implementation is done through Spring JSR94Support API> > The Rule engine is called in concurrent mode, > i.e , JSR94Support.executeStateless(name,list) is executed through multiple threads. > And when the rules are executed we randomly get the following exception > org.drools.RuntimeDroolsException: Unable to resolve class 'someclass(this is sample)here actual class is printed>' > at org.drools.base.ClassFieldAccessorCache.getClass(ClassFieldAccessorCache.java:126) > at org.drools.base.ClassFieldAccessorCache.getClassObjectType(ClassFieldAccessorCache.java:48) > at org.drools.reteoo.ClassObjectTypeConf.<init>(ClassObjectTypeConf.java:83) > at org.drools.common.ObjectTypeConfigurationRegistry.getObjectTypeConf(ObjectTypeConfigurationRegistry.java:71) > at org.drools.common.NamedEntryPoint.insert(NamedEntryPoint.java:159) > at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:903) > at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:847) > at org.drools.reteoo.ReteooStatelessSession.executeWithResults(ReteooStatelessSession.java:273) > The rules are registered every 15 minutes through RuleAdministrator.registerRuleExecutionset , > so whenever we refresh the rules and the subsequent thread even after the registration is completed, fails with the above message. This happens only when the rules are invoked concurrently. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3572) Deployment overlay feature does not work if a leading / is present on the overlay path

by Stuart Douglas (JIRA)

[ https://issues.jboss.org/browse/WFLY-3572?page=com.atlassian.jira.plugin.... ] Stuart Douglas commented on WFLY-3572: -------------------------------------- I investigated and it turns out that this is because you are using the path /overlay-2.jar instead of overlay-2.jar. This is a bug, I will fix it so both versions work. > Deployment overlay feature does not work if a leading / is present on the overlay path > -------------------------------------------------------------------------------------- > > Key: WFLY-3572 > URL: https://issues.jboss.org/browse/WFLY-3572 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Server > Affects Versions: 8.1.0.Final > Reporter: Lyle Wang > Assignee: Stuart Douglas > Attachments: wmq.jmsra.rar > > > According to WFLY-1359[1], we should be able to add a jar for an existing deployment. > Testing against WildFly 8.1.0 Final, the deployment-overlay feature reports errors on adding a new .jar for a .rar resource adapter deployment. > [1] - https://issues.jboss.org/browse/WFLY-1359 -- This message was sent by Atlassian JIRA (v6.2.6#6264)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3572) Deployment overlay feature does not work if a leading / is present on the overlay path

by Stuart Douglas (JIRA)

[ https://issues.jboss.org/browse/WFLY-3572?page=com.atlassian.jira.plugin.... ] Stuart Douglas updated WFLY-3572: --------------------------------- Summary: Deployment overlay feature does not work if a leading / is present on the overlay path (was: Deployment Overlay feature is not able to add jar files for resource adapter (rar) deployments) > Deployment overlay feature does not work if a leading / is present on the overlay path > -------------------------------------------------------------------------------------- > > Key: WFLY-3572 > URL: https://issues.jboss.org/browse/WFLY-3572 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Server > Affects Versions: 8.1.0.Final > Reporter: Lyle Wang > Assignee: Stuart Douglas > Attachments: wmq.jmsra.rar > > > According to WFLY-1359[1], we should be able to add a jar for an existing deployment. > Testing against WildFly 8.1.0 Final, the deployment-overlay feature reports errors on adding a new .jar for a .rar resource adapter deployment. > [1] - https://issues.jboss.org/browse/WFLY-1359 -- This message was sent by Atlassian JIRA (v6.2.6#6264)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-538) Unable to resolve class error , drools 5.5 in concurrent execution. JSR94Support and Spring

by Maruthi Shanmugam (JIRA)

[ https://issues.jboss.org/browse/DROOLS-538?page=com.atlassian.jira.plugin... ] Maruthi Shanmugam commented on DROOLS-538: ------------------------------------------ With the updated version I am getting this error. Caused by: java.lang.NullPointerException at org.drools.reteoo.RuleTerminalNode$SortDeclarations.compare(RuleTerminalNode.java:427) at org.drools.reteoo.RuleTerminalNode$SortDeclarations.compare(RuleTerminalNode.java:420) at java.util.Arrays.mergeSort(Arrays.java:2874) at java.util.Arrays.sort(Arrays.java:3251) at java.util.Arrays.sort(Arrays.java:3269) at org.drools.reteoo.RuleTerminalNode.getDeclarations(RuleTerminalNode.java:374) at org.drools.base.mvel.MVELConsequence.evaluate(MVELConsequence.java:84) at org.drools.common.DefaultAgenda.fireActivation(DefaultAgenda.java:1282) ... 25 more > Unable to resolve class error , drools 5.5 in concurrent execution. JSR94Support and Spring > -------------------------------------------------------------------------------------------- > > Key: DROOLS-538 > URL: https://issues.jboss.org/browse/DROOLS-538 > Project: Drools > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 5.5.0.Final > Environment: Linux Red Hat , Enterprise, JDK 1.6, Drools 5.5.Final > Reporter: Maruthi Shanmugam > Assignee: Mark Proctor > Priority: Blocker > > We use Drools 5.5 and drool implementation is done through Spring JSR94Support API> > The Rule engine is called in concurrent mode, > i.e , JSR94Support.executeStateless(name,list) is executed through multiple threads. > And when the rules are executed we randomly get the following exception > org.drools.RuntimeDroolsException: Unable to resolve class 'someclass(this is sample)here actual class is printed>' > at org.drools.base.ClassFieldAccessorCache.getClass(ClassFieldAccessorCache.java:126) > at org.drools.base.ClassFieldAccessorCache.getClassObjectType(ClassFieldAccessorCache.java:48) > at org.drools.reteoo.ClassObjectTypeConf.<init>(ClassObjectTypeConf.java:83) > at org.drools.common.ObjectTypeConfigurationRegistry.getObjectTypeConf(ObjectTypeConfigurationRegistry.java:71) > at org.drools.common.NamedEntryPoint.insert(NamedEntryPoint.java:159) > at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:903) > at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:847) > at org.drools.reteoo.ReteooStatelessSession.executeWithResults(ReteooStatelessSession.java:273) > The rules are registered every 15 minutes through RuleAdministrator.registerRuleExecutionset , > so whenever we refresh the rules and the subsequent thread even after the registration is completed, fails with the above message. This happens only when the rules are invoked concurrently. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-538) Unable to resolve class error , drools 5.5 in concurrent execution. JSR94Support and Spring

by Maruthi Shanmugam (JIRA)

[ https://issues.jboss.org/browse/DROOLS-538?page=com.atlassian.jira.plugin... ] Maruthi Shanmugam commented on DROOLS-538: ------------------------------------------ The same error is reproduced in the 5.6.0.Final as well. The error occurs only during the following scenarios. We load the Rules using RuleSource , and RegisterRuleSets using RuleAdministrator. And we periodically refresh the Rulesource and register the rulesets , the drls again. After the refresh of rulesource , the first concurrent Request throws this error. > Unable to resolve class error , drools 5.5 in concurrent execution. JSR94Support and Spring > -------------------------------------------------------------------------------------------- > > Key: DROOLS-538 > URL: https://issues.jboss.org/browse/DROOLS-538 > Project: Drools > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 5.5.0.Final > Environment: Linux Red Hat , Enterprise, JDK 1.6, Drools 5.5.Final > Reporter: Maruthi Shanmugam > Assignee: Mark Proctor > Priority: Blocker > > We use Drools 5.5 and drool implementation is done through Spring JSR94Support API> > The Rule engine is called in concurrent mode, > i.e , JSR94Support.executeStateless(name,list) is executed through multiple threads. > And when the rules are executed we randomly get the following exception > org.drools.RuntimeDroolsException: Unable to resolve class 'someclass(this is sample)here actual class is printed>' > at org.drools.base.ClassFieldAccessorCache.getClass(ClassFieldAccessorCache.java:126) > at org.drools.base.ClassFieldAccessorCache.getClassObjectType(ClassFieldAccessorCache.java:48) > at org.drools.reteoo.ClassObjectTypeConf.<init>(ClassObjectTypeConf.java:83) > at org.drools.common.ObjectTypeConfigurationRegistry.getObjectTypeConf(ObjectTypeConfigurationRegistry.java:71) > at org.drools.common.NamedEntryPoint.insert(NamedEntryPoint.java:159) > at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:903) > at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:847) > at org.drools.reteoo.ReteooStatelessSession.executeWithResults(ReteooStatelessSession.java:273) > The rules are registered every 15 minutes through RuleAdministrator.registerRuleExecutionset , > so whenever we refresh the rules and the subsequent thread even after the registration is completed, fails with the above message. This happens only when the rules are invoked concurrently. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3401) EJB StatefulTimeoutTestCase fails occasionally in CI environment

by Paul Ferraro (JIRA)

[ https://issues.jboss.org/browse/WFLY-3401?page=com.atlassian.jira.plugin.... ] Paul Ferraro updated WFLY-3401: ------------------------------- Git Pull Request: https://github.com/wildfly/wildfly/pull/6474 (was: https://github.com/wildfly/wildfly/pull/6363) > EJB StatefulTimeoutTestCase fails occasionally in CI environment > ---------------------------------------------------------------- > > Key: WFLY-3401 > URL: https://issues.jboss.org/browse/WFLY-3401 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Clustering > Affects Versions: 8.1.0.CR2 > Reporter: Paul Ferraro > Assignee: Paul Ferraro > Fix For: 9.0.0.Alpha1 > > > Probably a timing issue in the test. > http://brontes.lab.eng.brq.redhat.com/viewLog.html?buildId=15982&buildTyp... > {noformat} > java.lang.AssertionError: expected:<0> but was:<2> > at org.junit.Assert.fail(Assert.java:88) > at org.junit.Assert.failNotEquals(Assert.java:743) > at org.junit.Assert.assertEquals(Assert.java:118) > at org.junit.Assert.assertEquals(Assert.java:555) > at org.junit.Assert.assertEquals(Assert.java:542) > at org.jboss.as.test.clustering.cluster.ejb.stateful.StatefulTimeoutTestCase.timeout(StatefulTimeoutTestCase.java:119) > {noformat} -- This message was sent by Atlassian JIRA (v6.2.6#6264)

9 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 July 2014