July 2012 - jboss-jira - Jboss List Archives

[JBoss JIRA] (AS7-5240) The naming subsystem is not shown in the profiles subsystem view if the server is started in domain mode

by Wolf-Dieter Fink (JIRA)

Wolf-Dieter Fink created AS7-5240: ------------------------------------- Summary: The naming subsystem is not shown in the profiles subsystem view if the server is started in domain mode Key: AS7-5240 URL: https://issues.jboss.org/browse/AS7-5240 Project: Application Server 7 Issue Type: Bug Components: Console, Domain Management Affects Versions: 7.1.2.Final (EAP) Environment: Domain mode Reporter: Wolf-Dieter Fink Assignee: Heiko Braun The naming subsystem is not shown in domain mode for the different profiles. If the server is started in standalone mode the naming subsystem is shown in the tree of Profile/Container between Transaction and EJB3. In domain mode I expect it if I select a profile at the same location. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 11 months

2
3
0 / 0

[JBoss JIRA] (AS7-5269) HornetQ interceptors are not supported

by Jeff Mesnil (JIRA)

Jeff Mesnil created AS7-5269: -------------------------------- Summary: HornetQ interceptors are not supported Key: AS7-5269 URL: https://issues.jboss.org/browse/AS7-5269 Project: Application Server 7 Issue Type: Feature Request Components: JMS Affects Versions: 7.1.2.Final (EAP) Reporter: Jeff Mesnil Assignee: Jeff Mesnil HornetQ interceptors are not supported by the messaging subsystem. Their attributes are handled by the XML parser but they are not set when adding the HornetQ server instance. Moreover, passing the interceptor class name is not enough. Since they are loaded by HornetQ, its classloader must be able to access them. The interceptors must be put in a JBoss module that is declared as a transitive dependency of org.hornetq module. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 11 months

1
2
0 / 0

[JBoss JIRA] (JBRULES-3587) Declarations from "declare" sections don't apply to sub-classes if those live in a different package

by Jörg Henne (JIRA)

Jörg Henne created JBRULES-3587: ----------------------------------- Summary: Declarations from "declare" sections don't apply to sub-classes if those live in a different package Key: JBRULES-3587 URL: https://issues.jboss.org/browse/JBRULES-3587 Project: Drools Issue Type: Bug Security Level: Public (Everyone can see) Components: drools-compiler Affects Versions: 5.4.0.Final Reporter: Jörg Henne Assignee: Mark Proctor Declarations (like {{@role(event)}}) in a {{declare}}-Section should apply to sub-classes of the declared class, too, but don't if the sub-class resides in a different package than the base class. Attached you'll find an example which demonstrates the issue. The class {{ButtonEvent}} derives from {{VSCPEvent}} which is declared with{{@role(event)}}. Running {{com.levigo.overlord.DroolsTest}} yields a {{java.lang.ClassCastException: org.drools.common.DefaultFactHandle}} which is caused by the ButtonEvent not being recognized as an event instead of a fact. The Problem goes away if {{ButtonEvent}} is declared as an event (uncomment the section in {{overlord.drl}} or {{ButtonEvent}} is moved to the same package as {{VSCPEvent}}. For more information see the referenced forum thread. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 11 months

2
5
0 / 0

[JBoss JIRA] Created: (JBRULES-3033) java.lang.ClassCastException when change rule condition and declarative facts/events are used

by Federico Weisse (JIRA)

java.lang.ClassCastException when change rule condition and declarative facts/events are used --------------------------------------------------------------------------------------------- Key: JBRULES-3033 URL: https://issues.jboss.org/browse/JBRULES-3033 Project: Drools Issue Type: Bug Security Level: Public (Everyone can see) Components: drools-core Affects Versions: 5.1.1.FINAL Reporter: Federico Weisse Assignee: Mark Proctor We have drl files where we declare events. we use declarative events (there is no java class AlertaPosManual) (like this) declare AlertaPosManual @role (event) @expires(10s) idTerminal : java.lang.String end We use a StatefullSession for fusion cep and we need that changes in rules refresh the kBase in runtime. But when a rule condition changes this exception in throw Exception in thread "Thread-2" java.lang.ClassCastException: com.sample.ConsumoPostManual cannot be cast to com.sample.ConsumoPostManual at org.drools.base.com.sample.ConsumoPostManual17710704$getIdTerminal.getValue(Unknown Source) at org.drools.base.extractors.BaseObjectClassFieldReader.getHashCode(BaseObjectClassFieldReader.java:192) at org.drools.base.ClassFieldReader.getHashCode(ClassFieldReader.java:193) at org.drools.core.util.AbstractHashTable$SingleIndex.hashCodeOf(AbstractHashTable.java:582) at org.drools.core.util.RightTupleIndexHashTable.getOrCreate(RightTupleIndexHashTable.java:360) at org.drools.core.util.RightTupleIndexHashTable.add(RightTupleIndexHashTable.java:243) at org.drools.reteoo.AccumulateNode.assertObject(AccumulateNode.java:246) at org.drools.reteoo.ObjectTypeNode.updateSink(ObjectTypeNode.java:276) at org.drools.reteoo.PropagationQueuingNode.updateSink(PropagationQueuingNode.java:111) at org.drools.reteoo.BetaNode.attach(BetaNode.java:214) at org.drools.reteoo.builder.BuildUtils.attachNode(BuildUtils.java:151) at org.drools.reteoo.builder.CollectBuilder.build(CollectBuilder.java:114) at org.drools.reteoo.builder.PatternBuilder.attachPattern(PatternBuilder.java:111) at org.drools.reteoo.builder.PatternBuilder.build(PatternBuilder.java:72) at org.drools.reteoo.builder.GroupElementBuilder$AndBuilder.build(GroupElementBuilder.java:132) at org.drools.reteoo.builder.GroupElementBuilder.build(GroupElementBuilder.java:78) at org.drools.reteoo.builder.ReteooRuleBuilder.addSubRule(ReteooRuleBuilder.java:155) at org.drools.reteoo.builder.ReteooRuleBuilder.addRule(ReteooRuleBuilder.java:128) at org.drools.reteoo.ReteooBuilder.addRule(ReteooBuilder.java:117) at org.drools.reteoo.ReteooRuleBase.addRule(ReteooRuleBase.java:428) at org.drools.common.AbstractRuleBase.addRule(AbstractRuleBase.java:721) at org.drools.common.AbstractRuleBase.addPackages(AbstractRuleBase.java:545) at org.drools.reteoo.ReteooRuleBase.addPackages(ReteooRuleBase.java:445) at org.drools.reteoo.ReteooRuleBase.addPackage(ReteooRuleBase.java:452) at org.drools.agent.impl.KnowledgeAgentImpl.addResourcesToKnowledgeBase(KnowledgeAgentImpl.java:937) at org.drools.agent.impl.KnowledgeAgentImpl.incrementalBuildResources(KnowledgeAgentImpl.java:821) at org.drools.agent.impl.KnowledgeAgentImpl.buildKnowledgeBase(KnowledgeAgentImpl.java:586) at org.drools.agent.impl.KnowledgeAgentImpl.applyChangeSet(KnowledgeAgentImpl.java:185) at org.drools.agent.impl.KnowledgeAgentImpl$ChangeSetNotificationDetector.run(KnowledgeAgentImpl.java:1106) at java.lang.Thread.run(Thread.java:619) I think that's because the statefullSession has an instance of com.sample.ConsumoPostManual (loaded with the classLoader org.drools.rule.JavaDialectRuntimeData$PackageClassLoader@1218b25) But when the kBase is regenerated and the class com.sample.ConsumoPostManual to, the classLoader org.drools.rule.JavaDialectRuntimeData is recreated so there are two versions of the class com.sample.ConsumoPostManual in differents classLoader (one in the statefullSession and the other in the kBase) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 11 months

2
2
0 / 0

[JBoss JIRA] Created: (JBRULES-2962) Knowledge Agent rebuilding KnowledgeBase with scanner/notifier does not work with declared facts

by Ross Hall (JIRA)

Knowledge Agent rebuilding KnowledgeBase with scanner/notifier does not work with declared facts ------------------------------------------------------------------------------------------------ Key: JBRULES-2962 URL: https://issues.jboss.org/browse/JBRULES-2962 Project: Drools Issue Type: Bug Security Level: Public (Everyone can see) Components: drools-core Affects Versions: 5.2.0.M1, 5.1.1.FINAL Reporter: Ross Hall Assignee: Mark Proctor When reloading rules in a KnowledgeAgent declared facts will cause ClassCastExceptions when new-instance is set to false. When new-instance is set to true, the KnowledgeBase is rebuilt, however declared facts are not recognized and associated rules will not fire. Rules not using declared facts will fire normally. Using POJOs works fine. In both cases the KnowledgeAgent will build the rule base the first time, the issue only seems to occur when the changeset resources are modified and are detected by the resource notifier and scanner. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 11 months

8
15
0 / 0

[JBoss JIRA] Created: (AS7-1613) NPE in TranslatingSuspendableChannel.scheduleReadTask

by Ondrej Zizka (JIRA)

NPE in TranslatingSuspendableChannel.scheduleReadTask ----------------------------------------------------- Key: AS7-1613 URL: https://issues.jboss.org/browse/AS7-1613 Project: Application Server 7 Issue Type: Bug Components: CLI Affects Versions: 7.0.1.Final Reporter: Ondrej Zizka Assignee: Alexey Loubyansky Happened after a while of inactivity (if that matters). [standalone@localhost:9999 interface=public] cd .. [standalone@localhost:9999 /] cd .. [standalone@localhost:9999 /] ls extension core-service path subsystem system-property deployment interface socket-binding-group [standalone@localhost:9999 /] Exception in thread "pool-1-thread-21" java.lang.NullPointerException at org.xnio.channels.TranslatingSuspendableChannel.scheduleReadTask(TranslatingSuspendableChannel.java:253) at org.xnio.channels.TranslatingSuspendableChannel.resumeReads(TranslatingSuspendableChannel.java:233) at org.jboss.remoting3.remote.ClientConnectionOpenListener$Authentication$2.run(ClientConnectionOpenListener.java:498) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) at java.lang.Thread.run(Thread.java:662) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 11 months

2
4
0 / 0

[JBoss JIRA] (AS7-2022) TS: Coverage reports

by Ondrej Zizka (Created) (JIRA)

TS: Coverage reports -------------------- Key: AS7-2022 URL: https://issues.jboss.org/browse/AS7-2022 Project: Application Server 7 Issue Type: Sub-task Components: Test Suite Affects Versions: 7.1.0.Alpha1 Reporter: Ondrej Zizka Assignee: Ondrej Zizka There are some coverage jobs in Hudson: * Aggregated: https://hudson.qa.jboss.com/hudson//view/JBoss%20AS/job/jboss-as7-code-co... * Per module: https://hudson.qa.jboss.com/hudson/view/JBoss AS/job/JBoss-AS-7.0.x-unit-coverage/ -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 11 months

9
42
0 / 0

[JBoss JIRA] (AS7-4704) Cannot deploy exploded .jar inside exploded .war

by Adrian Mitev (JIRA)

Adrian Mitev created AS7-4704: --------------------------------- Summary: Cannot deploy exploded .jar inside exploded .war Key: AS7-4704 URL: https://issues.jboss.org/browse/AS7-4704 Project: Application Server 7 Issue Type: Bug Affects Versions: 7.1.1.Final Reporter: Adrian Mitev Hi all! I deploy my app as an exploded war there in WEB-INF/lib there is a jar deployed as exploded folder. However when the server starts I get the following exception: 17:59:15,423 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-3) MSC00001: Failed to start service jboss.deployment.unit."MyApp.war".STRUCTURE: org.jboss.msc.service.StartException in service jboss.deployment.unit."MyApp.war".STRUCTURE: Failed to process phase STRUCTURE of deployment "MyApp.war" at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:119) [jboss-as-server-7.1.1.Final.jar:7.1.1.Final] at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1811) [jboss-msc-1.0.2.GA.jar:1.0.2.GA] at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1746) [jboss-msc-1.0.2.GA.jar:1.0.2.GA] at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_24] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_24] at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_24] Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: org.jboss.as.server.deployment.DeploymentUnitProcessingException: JBAS018037: Failed to process WEB-INF/lib: "/C:/Users/amitev/Desktop/mse2012/jboss-as-7.1.1.Final/standalone/deployments/MyApp.war/WEB-INF/lib/Module1.jar" at org.jboss.as.web.deployment.WarStructureDeploymentProcessor.deploy(WarStructureDeploymentProcessor.java:120) at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:113) [jboss-as-server-7.1.1.Final.jar:7.1.1.Final] ... 5 more Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: JBAS018037: Failed to process WEB-INF/lib: "/C:/Users/amitev/Desktop/mse2012/jboss-as-7.1.1.Final/standalone/deployments/MyApp.war/WEB-INF/lib/Module1.jar" at org.jboss.as.web.deployment.WarStructureDeploymentProcessor.createWebInfLibResources(WarStructureDeploymentProcessor.java:175) at org.jboss.as.web.deployment.WarStructureDeploymentProcessor.createResourceRoots(WarStructureDeploymentProcessor.java:153) at org.jboss.as.web.deployment.WarStructureDeploymentProcessor.deploy(WarStructureDeploymentProcessor.java:114) ... 6 more Caused by: java.util.zip.ZipException: error in opening zip file at java.util.zip.ZipFile.open(Native Method) [rt.jar:1.6.0_24] at java.util.zip.ZipFile.<init>(ZipFile.java:127) [rt.jar:1.6.0_24] at java.util.jar.JarFile.<init>(JarFile.java:135) [rt.jar:1.6.0_24] at java.util.jar.JarFile.<init>(JarFile.java:99) [rt.jar:1.6.0_24] at org.jboss.vfs.spi.JavaZipFileSystem.<init>(JavaZipFileSystem.java:97) at org.jboss.vfs.spi.JavaZipFileSystem.<init>(JavaZipFileSystem.java:83) at org.jboss.vfs.VFS.mountZip(VFS.java:408) at org.jboss.vfs.VFS.mountZip(VFS.java:434) at org.jboss.as.web.deployment.WarStructureDeploymentProcessor.createWebInfLibResources(WarStructureDeploymentProcessor.java:170) ... 8 more -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 11 months

4
11
0 / 0

[JBoss JIRA] Created: (JBRULES-2791) Spring's JpaTransactionManager should be used instead of both: DroolsSpringTransactionManager and DroolsSpringJpaManager

by Anatoly Polinsky (JIRA)

Spring's JpaTransactionManager should be used instead of both: DroolsSpringTransactionManager and DroolsSpringJpaManager ------------------------------------------------------------------------------------------------------------------------ Key: JBRULES-2791 URL: https://jira.jboss.org/browse/JBRULES-2791 Project: Drools Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 5.1.1.FINAL, FUTURE Environment: Spring Based Applications Reporter: Anatoly Polinsky Assignee: Mark Proctor Instead of having two different components: "DroolsSpringTransactionManager" and "DroolsSpringJpaManager" that aim to do the work of "org.springframework.orm.jpa.JpaTransactionManager", and trying to fit a JTA model into it, the Spring's "JpaTransactionManager" itself should be used. And instead of manually managing and constantly getting references to a "proper entity manager" from JpaManger within a SingleSessionCommandService, a @PersistenceContext should be injected. This will decouple SingleSessionCommandService from JpaManager interface, and will allow _any_ JPA provider to inject an entity manager. It has more benefits, such as trust in underline JPA providers ( e.g. Hibernate ) and Spring Transaction Management capabilities to manage the process that they are actually excellent at. /Anatoly -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 11 months

2
2
0 / 0

[JBoss JIRA] (JBCOMMON-126) NullPointerException when using PropertyMap concurrently

by Michael Pradel (JIRA)

Michael Pradel created JBCOMMON-126: --------------------------------------- Summary: NullPointerException when using PropertyMap concurrently Key: JBCOMMON-126 URL: https://issues.jboss.org/browse/JBCOMMON-126 Project: JBoss Common Issue Type: Bug Security Level: Public (Everyone can see) Components: common-core (2.x) Affects Versions: 2.2.18.GA Environment: All environments Reporter: Michael Pradel PropertyMap extends Properties, which is a thread-safe class, but it doesn't preserve its thread safety. This leads to surprising crashes if you have a reference of type Properties (documented as thread-safe) that turns out to be a PropertyMap (not thread-safe). Here's a simplified example that shows how we hit this bug: final Properties p = getProps(); p.setProperty("a", "b"); Thread t1 = new Thread(new Runnable() { public void run() { p.remove("a"); } }); Thread t2 = new Thread(new Runnable() { public void run() { p.clear(); } }); t1.start(); t2.start(); try { t1.join(); t2.join(); } catch (InterruptedException e) { e.printStackTrace(); } Properties getProps() { // return new Properties(); // OK return new PropertyMap(); // leads to NullPointerException } The code runs fine if getProps returns Properties (as it should, because Properties is thread-safe), but raises a NullPointerException if getProps returns a PropertyMap. Are you aware of this inconsistency? It seems that the safest way of extending Properties is to make methods that override synchronized methods synchronized. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 11 months

2
2
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 July 2012