June 2014 - jboss-jira - Jboss List Archives

[JBoss JIRA] (DROOLS-479) Pseudo Clock doesn't work for 2 not statements

by Richard Ambridge (JIRA)

[ https://issues.jboss.org/browse/DROOLS-479?page=com.atlassian.jira.plugin... ] Richard Ambridge commented on DROOLS-479: ----------------------------------------- Thanks for the update. I don't understand why the first part of the test works, but not the second? First template is 'if cheese=smelly and no cheese=a after 3 seconds. Then cheese=smelly is inserted, clock advanced 10 seconds.. template fires. Second template is 'if cheese=stinky and no cheese=a after 3 seconds and no cheese=b after 5 seconds. Then cheese=stinky is inserted, clock advanced 10 seconds.. no template. If the first insert is skipped, (e.g comment out lines 109-120) then the second template seems to work fine. The 'fireUntilHalt' is run in the thread, and it should start before any inserts. This does work in 'real time', but the issue is that this is a simplified test case from our development. The real gap in events could be 48 hours, and we can't easily wait that long in junit tests. Thanks for looking at this. > Pseudo Clock doesn't work for 2 not statements > ---------------------------------------------- > > Key: DROOLS-479 > URL: https://issues.jboss.org/browse/DROOLS-479 > Project: Drools > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 6.0.1.Final, 6.1.0.Beta3 > Environment: linux 14.04 > Reporter: Richard Ambridge > Assignee: Mark Proctor > Labels: pseudoclock > > If a rule (event) has the following: > + "when\n" > + " $s : Cheese(type==\"stinky\")\n" > + " not( Cheese(type==\"a\", this after [0s,3s] $s ) )\n" > + " not( Cheese(type==\"b\", this after [0s,5s] $s ) )\n" //2 * not > and pseudo clock is used, the rule doesn't fire. > If realtime clock is used, the rule works. -- This message was sent by Atlassian JIRA (v6.2.3#6260)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2912) Generic JMS adapter does not deploy correctly in domain mode.

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-2912?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration updated WFLY-2912: ------------------------------------------ Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1064299, https://bugzilla.redhat.com/show_bug.cgi?id=1070106, https://bugzilla.redhat.com/show_bug.cgi?id=1074569, https://bugzilla.redhat.com/show_bug.cgi?id=1103238, https://bugzilla.redhat.com/show_bug.cgi?id=1103673 (was: https://bugzilla.redhat.com/show_bug.cgi?id=1064299, https://bugzilla.redhat.com/show_bug.cgi?id=1070106, https://bugzilla.redhat.com/show_bug.cgi?id=1074569, https://bugzilla.redhat.com/show_bug.cgi?id=1103238) > Generic JMS adapter does not deploy correctly in domain mode. > ------------------------------------------------------------- > > Key: WFLY-2912 > URL: https://issues.jboss.org/browse/WFLY-2912 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: JCA > Affects Versions: 8.0.0.Final > Reporter: Tom Ross > Assignee: Stefano Maestri > Fix For: 8.1.0.CR1, 8.1.0.Final > > > When trying to use generic resource adapter with third part JMS providers like TIBCO it is necessary to use generic RA provided in JBoss EAP 6.2. Unfortunately it would appear that when trying to use in domain mode the RA does not get deployed full, though it works perfectly in standalone mode. -- This message was sent by Atlassian JIRA (v6.2.3#6260)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3386) Nullpointer exception on AbstractSessionBeanStore.getLockStore from within Activiti CDI

by Andries Ehlers (JIRA)

[ https://issues.jboss.org/browse/WFLY-3386?page=com.atlassian.jira.plugin.... ] Andries Ehlers commented on WFLY-3386: -------------------------------------- Hi Martin, I did detail it in a previous comment, but just to re-iterate: A web client calls our JAX-RS resource. The JAX-RS resource performs some basic conversion from DTO to internal domain model with Dozer. We have a Stateless Session Bean (injected with @Inject, not @EJB) containing business logic. The Session Bean has an injected Activiti BusinessProcess. There is no JSF involved, no explicit interaction in our code with the conversation scope; its simply Web-Client -> JAX-RS Resource -> Stateless Session Bean -> BusinessProcess. I'm not 100% sure as to the supported CDI version, but based on some JIRA issues I found the are referring to integrating CDI 1.1 etc. Regards, Andries > Nullpointer exception on AbstractSessionBeanStore.getLockStore from within Activiti CDI > --------------------------------------------------------------------------------------- > > Key: WFLY-3386 > URL: https://issues.jboss.org/browse/WFLY-3386 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: CDI / Weld > Affects Versions: 8.0.0.Final > Environment: CentOS, Mac (Mountain Lion). > Reporter: Andries Ehlers > Assignee: Martin Kouba > > Background: > The actual exception seems to be very close the one in issue: WFLY-3001 but we are not using JSF at all, but Activiti CDI. > Not sure if this is a Wildfly or Activiti issue - it could very well be that there is a bug in Activiti with how it manages the CDI scopes. Unfortunately we're at a loss and seeing that the nullpointer is thrown from within a weld AbstractSessionBeanStore, I decided to post it here. Please advise. > Error: > We use Activiti CDI within Wildfly 8.0.0.Final. We randomly encounter an issue (sometimes immediately after a redeploy, other times after a few hours of inactivity on the server) the following issue. When Activiti attempts to retrieve the ContextBeanInstance from its ConversationScopedAssociationProxy, a NullPointer exception is thrown while attempting to retrieve the lock store within Weld (see below). > ----------------------------- > 2014-05-21 10:05:34,430 INFO [stdout] (default task-12) java.lang.NullPointerException: null > 2014-05-21 10:05:34,430 INFO [stdout] (default task-12) at org.jboss.weld.context.beanstore.http.AbstractSessionBeanStore.getLockStore(AbstractSessionBeanStore.java:113) ~[weld-core-impl-2.1.2.Final.jar!/:2014-01-09 09:23] > 2014-05-21 10:05:34,430 INFO [stdout] (default task-12) at org.jboss.weld.context.beanstore.AttributeBeanStore.lock(AttributeBeanStore.java:210) ~[weld-core-impl-2.1.2.Final.jar!/:2014-01-09 09:23] > 2014-05-21 10:05:34,430 INFO [stdout] (default task-12) at org.jboss.weld.context.AbstractContext.get(AbstractContext.java:90) ~[weld-core-impl-2.1.2.Final.jar!/:2014-01-09 09:23] > 2014-05-21 10:05:34,431 INFO [stdout] (default task-12) at org.jboss.weld.context.PassivatingContextWrapper$AbstractPassivatingContextWrapper.get(PassivatingContextWrapper.java:76) ~[weld-core-impl-2.1.2.Final.jar!/:2014-01-09 09:23] > 2014-05-21 10:05:34,431 INFO [stdout] (default task-12) at org.jboss.weld.bean.proxy.ContextBeanInstance.getInstance(ContextBeanInstance.java:98) ~[weld-core-impl-2.1.2.Final.jar!/:2014-01-09 09:23] > 2014-05-21 10:05:34,431 INFO [stdout] (default task-12) at org.jboss.weld.bean.proxy.ProxyMethodHandler.invoke(ProxyMethodHandler.java:78) ~[weld-core-impl-2.1.2.Final.jar!/:2014-01-09 09:23] > 2014-05-21 10:05:34,431 INFO [stdout] (default task-12) at org.activiti.cdi.impl.context.DefaultContextAssociationManager$ConversationScopedAssociation$Proxy$_$$_WeldClientProxy.getTask(Unknown Source) ~[activiti-cdi-5.15.jar:na] > 2014-05-21 10:05:34,431 INFO [stdout] (default task-12) at org.activiti.cdi.impl.context.DefaultContextAssociationManager.getTask(DefaultContextAssociationManager.java:237) ~[activiti-cdi-5.15.jar:na] > 2014-05-21 10:05:34,432 INFO [stdout] (default task-12) at org.activiti.cdi.BusinessProcess.startTask(BusinessProcess.java:332) ~[activiti-cdi-5.15.jar:na] -- This message was sent by Atlassian JIRA (v6.2.3#6260)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3419) beans in module jars are not discovered except the first jar in module

by Petr Sakař (JIRA)

[ https://issues.jboss.org/browse/WFLY-3419?page=com.atlassian.jira.plugin.... ] Petr Sakař commented on WFLY-3419: ---------------------------------- [~jason.greene] EAP currently behaves as expected - beans are discovered only in jar with beans.xml. I would suggest to keep the restriction, as it gives precise control which jar in module should be scanned. The problem in Wildfly is that only first jar including beans.xml is scanned, others containing beans.xml are not scanned. > beans in module jars are not discovered except the first jar in module > ---------------------------------------------------------------------- > > Key: WFLY-3419 > URL: https://issues.jboss.org/browse/WFLY-3419 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: CDI / Weld > Affects Versions: 8.0.0.Final, 8.1.0.Final > Reporter: Petr Sakař > Assignee: Jason Greene > Attachments: jboss-module-test.src.zip, module.multiplejars.zip, module.ok.zip, servlet-cdi-test-jar.src.zip, servlet-cdi-test3.src.zip, servlet-cdi-test3.war > > > CDI does not scan module with multiple jars. Only first jar is scanned. > Workaround is to package everything in single jar file. > To reproduce: > {CODE} > #download attached files > #download and unzip wildfly > cd wildfly-9.0.0.Alpha1-SNAPSHOT #or other version > 8.0.0 > unzip ../module.multiplejars.zip > cp ../servlet-cdi-test3.war standalone/deployments/ > ./bin/standalone.sh > # observe deployment fails > # stop server > unzip ../module.ok.zip > ./bin/standalone.sh > # observe deployment succeeds > {CODE} > The same scenario succeeds in both cases on EAP 6.2.x. > module.ok.zip was created from module.multiplejars.zip by merging jar files into single one -- This message was sent by Atlassian JIRA (v6.2.3#6260)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-207) Add start/stop operations to hornetq-server resource

by Jeff Mesnil (JIRA)

[ https://issues.jboss.org/browse/WFLY-207?page=com.atlassian.jira.plugin.s... ] Jeff Mesnil commented on WFLY-207: ---------------------------------- HornetQServerControl does not expose start/stop methods > Add start/stop operations to hornetq-server resource > ---------------------------------------------------- > > Key: WFLY-207 > URL: https://issues.jboss.org/browse/WFLY-207 > Project: WildFly > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Components: JMS > Reporter: Jeff Mesnil > Assignee: Jeff Mesnil > Fix For: 9.0.0.CR1 > > > Currently it is not possible to start/stop a hornetq-server resource without removing or adding it. > For HornetQ replicated nodes, it'd be useful to be able to start/stop the node (runtime operations) without changing its configuration. That'd be necessary to restart replicated backup servers that have fallen back -- This message was sent by Atlassian JIRA (v6.2.3#6260)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-207) Add start/stop operations to hornetq-server resource

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-207?page=com.atlassian.jira.plugin.s... ] RH Bugzilla Integration updated WFLY-207: ----------------------------------------- Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1099730 > Add start/stop operations to hornetq-server resource > ---------------------------------------------------- > > Key: WFLY-207 > URL: https://issues.jboss.org/browse/WFLY-207 > Project: WildFly > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Components: JMS > Reporter: Jeff Mesnil > Assignee: Jeff Mesnil > Fix For: 9.0.0.CR1 > > > Currently it is not possible to start/stop a hornetq-server resource without removing or adding it. > For HornetQ replicated nodes, it'd be useful to be able to start/stop the node (runtime operations) without changing its configuration. That'd be necessary to restart replicated backup servers that have fallen back -- This message was sent by Atlassian JIRA (v6.2.3#6260)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3426) Add MBean server support to Management console

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/WFLY-3426?page=com.atlassian.jira.plugin.... ] Tomaz Cerar updated WFLY-3426: ------------------------------ Affects Version/s: (was: 8.2.0.CR1) > Add MBean server support to Management console > ---------------------------------------------- > > Key: WFLY-3426 > URL: https://issues.jboss.org/browse/WFLY-3426 > Project: WildFly > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Reporter: Sebastian Łaskawiec > Assignee: Jason Greene > Priority: Minor > > In JBoss 5.x server there was a web based tool for managing JMX Beans. Currently this functionality is supported via bundled JConsole. It would be convenient to have such functionality based on HTTP Web Management panel. > As discussed on email thread (subject: "JMX Console over Web Admin Console") it should be placed a part of standard management resource tree or in context of HTTP management interface. -- This message was sent by Atlassian JIRA (v6.2.3#6260)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3426) Add MBean server support to Management console

by Sebastian Łaskawiec (JIRA)

Sebastian Łaskawiec created WFLY-3426: ----------------------------------------- Summary: Add MBean server support to Management console Key: WFLY-3426 URL: https://issues.jboss.org/browse/WFLY-3426 Project: WildFly Issue Type: Feature Request Security Level: Public (Everyone can see) Affects Versions: 8.2.0.CR1 Reporter: Sebastian Łaskawiec Assignee: Jason Greene Priority: Minor In JBoss 5.x server there was a web based tool for managing JMX Beans. Currently this functionality is supported via bundled JConsole. It would be convenient to have such functionality based on HTTP Web Management panel. As discussed on email thread (subject: "JMX Console over Web Admin Console") it should be placed a part of standard management resource tree or in context of HTTP management interface. -- This message was sent by Atlassian JIRA (v6.2.3#6260)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-1197) Port the legacy jmx-console to AS7

by Sebastian Łaskawiec (JIRA)

[ https://issues.jboss.org/browse/WFLY-1197?page=com.atlassian.jira.plugin.... ] Sebastian Łaskawiec commented on WFLY-1197: ------------------------------------------- Rebased Darren's code and detached from parent: https://github.com/altanis/wildfly/commits/jmx-console-ported > Port the legacy jmx-console to AS7 > ---------------------------------- > > Key: WFLY-1197 > URL: https://issues.jboss.org/browse/WFLY-1197 > Project: WildFly > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: JMX > Reporter: Dimitris Andreadis > Assignee: Darran Lofthouse > Labels: JMX, as7, jmx-console, management_security,, management_sso > Attachments: jmx-console.war, jmx-console.war > > > I've seen a few people asking for a port of the old jmx-console to AS7, for monitoring purposes, until equivalent functionality is available through the new GWT-based console. > I've ported the old console in this branch: > https://github.com/dandreadis/jboss-as/commits/jmx-console > It only includes a new top-level directory 'jmx-console'. The directory is not build by default, and when you build it manually it does not alter the server configuration in any way, you need to manually copy the resulting target/jboss-as-jmx-console-VERSION.war to the server deployment directory (and rename it to jmx-console.war) > If there is interest, it could be included in the AS7 distro in some top level 'legacy' directory so it is not deployed by default? > The resulting .war is attached on this JIRA, in case someone wants to use it. It work just as well on AS 7.0.2 and the latest AS 7.1.x development branch. -- This message was sent by Atlassian JIRA (v6.2.3#6260)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-510) Traiting a non-natively traitable bean breaks the assert behavior

by Davide Sottara (JIRA)

[ https://issues.jboss.org/browse/DROOLS-510?page=com.atlassian.jira.plugin... ] Davide Sottara updated DROOLS-510: ---------------------------------- Git Pull Request: https://github.com/droolsjbpm/drools/pull/340 > Traiting a non-natively traitable bean breaks the assert behavior > ----------------------------------------------------------------- > > Key: DROOLS-510 > URL: https://issues.jboss.org/browse/DROOLS-510 > Project: Drools > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 5.6.0.Final, 6.1.0.Beta4 > Reporter: Davide Sottara > Assignee: Davide Sottara > > Only beans implementing the TraitableBean interface can be used with "don" and "shed". If a non-traitable object is processed, the engine creates a proxy to add the required behavior. In versions up to 6.1.B4, this proxy appears EQUAL but not the SAME as the original fact. This will break the lookup of the handle if the user keeps a reference to the original object and tries to use it (e.g. to re-insert or delete the object) -- This message was sent by Atlassian JIRA (v6.2.3#6260)

9 years, 10 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 June 2014