[JBoss JIRA] (JBRULES-3620) Conditional named consequences
by Mario Fusco (JIRA)
Mario Fusco created JBRULES-3620:
------------------------------------
Summary: Conditional named consequences
Key: JBRULES-3620
URL: https://issues.jboss.org/browse/JBRULES-3620
Project: Drools
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Reporter: Mario Fusco
Assignee: Mario Fusco
Implement named consequence like in the following example:
rule R1
A() do[t1] B()
then
// default consequence executed with both A() and B()
then[t1]
// named consequence on A()
end
In this example, when a match for A() is found, the consequence named t1 is scheduled on the agenda and then the LHS pattern matching evaluation continues as per normal looking for a join with B() and eventually scheduling also the default consequence.
The named consequence activation can be optionally guarded by a condition like in:
A() if (condition) do[t1] B()
Here the named consequence t1 is activated only if the boolean condition (expressed on the last pattern before the if, A() in this case) evaluates to true. The conditional named consequence invocation can be also breaking, i.e. can block any further pattern matching when the condition is satisfied like in:
A() if (condition) break[t1] B()
Note that the use of a breaking named consequence without any condition like in:
A() break[t1] B()
doesn't make sense (and should generate a compile time error) because the join with B() shouldn't be reachable.
Using one or more if/else it is also possible to have multiple nested conditions like in the following example:
A() if (condition1) do[t1] else if (condition2) do[t2] else break[t3] B()
--
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
11 years, 9 months
[JBoss JIRA] (JGRP-1484) SEQUENCER and merge-views broken
by David Hotham (JIRA)
David Hotham created JGRP-1484:
----------------------------------
Summary: SEQUENCER and merge-views broken
Key: JGRP-1484
URL: https://issues.jboss.org/browse/JGRP-1484
Project: JGroups
Issue Type: Bug
Affects Versions: 3.0.10
Reporter: David Hotham
Assignee: Bela Ban
Here's a new way in which putting SEQUENCER below GMS is broken.
Start with A having view B|4 [B,A], while B, C and D all have view B|7 [B,C,D].
Now we start a merge, in which B is coordinator. B creates the view C|8 [C, D, A, B].
(I've opened a pull request saying that B surely shouldn't issue a view where the ViewID says that C was the creator. But I think that this is incidental, and not key to the bug that I'm reporting here).
Now B sends INSTALL_MERGE_VIEW to B (a coordinator) and A (a merge participant, per Util.determineMergeParticipants).
B gets this first and broadcasts the new view to [B, C, D]. In particular, B is now not a coordinator.
Then A gets the INSTALL_MERGE_VIEW, and it too tries broadcasting the new view. SEQUENCER gets involved, and forwards the broadcast to B (as the coordinator in the old view). B discards this; it's no longer a coordinator.
So the new view is not installed at A. All future broadcasts from A are forwarded to B, who discards them. The group is fractured, and none of A's broadcasts are delivered.
I'm not sure what the right fix would be. I wonder whether things should be arranged so that in a merge:
- coordinators behave as today, broadcasting the new view to their own sub-groups
- but mere participants do not do this: they should just have the new view installed on them.
--
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
11 years, 9 months
[JBoss JIRA] (JBRULES-3618) Unexpected behaviour when using expression in duration-attribute
by Wannes Kerckhove (JIRA)
Wannes Kerckhove created JBRULES-3618:
-----------------------------------------
Summary: Unexpected behaviour when using expression in duration-attribute
Key: JBRULES-3618
URL: https://issues.jboss.org/browse/JBRULES-3618
Project: Drools
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: drools-core (expert)
Affects Versions: 5.4.0.Final
Environment: Microsoft Windows 7 Enterprise, Eclipse Juno IDE
Reporter: Wannes Kerckhove
Assignee: Mark Proctor
In some cases the duration-attribute for a rule doesn't behave as would be expected when an expression is used to indicate the duration time (i.e. it triggers too late). When replacing the expression with the equivalent literal value, the rule triggers correctly.
--
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
11 years, 9 months
[JBoss JIRA] (JGRP-1508) MessageDispatcher allows sending messages after the channel has been closed
by Dan Berindei (JIRA)
Dan Berindei created JGRP-1508:
----------------------------------
Summary: MessageDispatcher allows sending messages after the channel has been closed
Key: JGRP-1508
URL: https://issues.jboss.org/browse/JGRP-1508
Project: JGroups
Issue Type: Bug
Affects Versions: 3.1, 3.0.13
Reporter: Dan Berindei
Assignee: Bela Ban
Channel.send() throws an exception if the channel is already closed, but MessageDispatcher goes around this and doesn't throw an exception immediately. Instead, if castMessage() was synchronous, it blocks and it times out after the request timeout expires.
--
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
11 years, 9 months
[JBoss JIRA] (AS7-5403) CLONE - Adding modcluster via the CLI fails.
by Joe Wertz (JIRA)
[ https://issues.jboss.org/browse/AS7-5403?page=com.atlassian.jira.plugin.s... ]
Joe Wertz commented on AS7-5403:
--------------------------------
The basic problem is that the modcluster subsystem cannot start without certain values in the mod-cluster-config being configured. However, the mod-cluster-config can't be set up until there is a subsystem. The composite operation works because the subsystem does not attempt to start until after the mod-cluster-config is set up.
I've found a few solutions, but the best seems to be this one.
1) Start the modcluster in a disabled mode. Adding a new attribute to /subsystem=modcluster:add(), 'enabled', and defaulting it to 'false', would allow the subsystem to be installed. Then the user could go into the mod-cluster-config and set up whatever they wanted, and go back and start the subsystem service once the setup is complete.
This creates a small hassle, because the user has to go back and manually activate the subsystem after it's installed and configured, but it allows the user to configure the subsystem to their liking.
Thoughts?
> CLONE - Adding modcluster via the CLI fails.
> --------------------------------------------
>
> Key: AS7-5403
> URL: https://issues.jboss.org/browse/AS7-5403
> Project: Application Server 7
> Issue Type: Bug
> Components: CLI
> Affects Versions: 7.1.2.Final (EAP)
> Reporter: Tom Fonteyne
> Assignee: Joe Wertz
>
> Adding modcluster via the CLI fails.
--
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
11 years, 9 months
[JBoss JIRA] (AS7-5497) Exception handling of EJB container for MDB is incorrect
by Adam Kovari (JIRA)
[ https://issues.jboss.org/browse/AS7-5497?page=com.atlassian.jira.plugin.s... ]
Adam Kovari moved JBPAPP-9833 to AS7-5497:
------------------------------------------
Project: Application Server 7 (was: JBoss Enterprise Application Platform)
Key: AS7-5497 (was: JBPAPP-9833)
Workflow: GIT Pull Request workflow (was: jira)
Affects Version/s: 7.1.2.Final (EAP)
(was: EAP 6.0.0)
Component/s: EJB
(was: EJB)
Security: (was: Public)
Fix Version/s: (was: TBD EAP 6)
Docs QE Status: (was: NEW)
> Exception handling of EJB container for MDB is incorrect
> --------------------------------------------------------
>
> Key: AS7-5497
> URL: https://issues.jboss.org/browse/AS7-5497
> Project: Application Server 7
> Issue Type: Bug
> Components: EJB
> Affects Versions: 7.1.2.Final (EAP)
> Environment: JBoss EAP 6.0.0
> Reporter: Adam Kovari
> Assignee: JBoss SET
> Priority: Minor
> Labels: eap6, ejb3.1
>
> After deploying a MDB with Container-Managed transaction and
> TransactionAttribute NOT_SUPPORTED, a RuntimeException thrown from
> within the MDB onMessage() is reported to the Adapter as such, with no
> EJBException wrapping. I.e.: the "((javax.jms.MessageListener)
> endPoint).onMessage(message)" call in our adapter fails with the
> exception type originally thrown.
> This does not look compliant with EJB 3.1 spec(JSR 318: Enterprise
> JavaBeansTM, Version 3.1, Table 20 page 392, last cell bottom right):
> "Throw EJBException that wraps the original exception to resource
> adapter".
> Another part of spec I was just made aware of says this:
> p383 of the spec states -
> In the case of a message-driven bean, the container logs the exception and then throws a javax.ejb.EJBException that wraps the original exception to the resource adapter. (See [15]).
--
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
11 years, 9 months
[JBoss JIRA] (AS7-4567) Weld does not find CDI Beans within AS7 modules
by Gernot P (JIRA)
Gernot P created AS7-4567:
-----------------------------
Summary: Weld does not find CDI Beans within AS7 modules
Key: AS7-4567
URL: https://issues.jboss.org/browse/AS7-4567
Project: Application Server 7
Issue Type: Bug
Components: Class Loading
Affects Versions: 7.1.1.Final, 7.1.0.Final
Reporter: Gernot P
Assignee: David Lloyd
I've a my.jar which contains cdi beans and cdi producer methods and a META-INF/beans.xml file.
Putting this jar to WEB-INF/lib in my war, the web app can use the cdi producer methods of my.jar.
After moving my.jar from WEB-INF/lib to a AS7 module(and adding a dependency in the war's MANIFEST.MF) AS7 reports
org.jboss.weld.exceptions.DeploymentException: WELD-001408 Unsatisfied dependencies for type [BeanXY] with qualifiers [@Default] at injection point [[field] @Inject
It seams that weld does not (or cannot) scan my.jar which is inside AS7 module. (instantiating BeanXY directly ("new BeanXY()") works - so the module is loaded correctly)
--
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
11 years, 9 months
[JBoss JIRA] (AS7-2227) Port the legacy jmx-console to AS7
by Dimitris Andreadis (Created) (JIRA)
Port the legacy jmx-console to AS7
----------------------------------
Key: AS7-2227
URL: https://issues.jboss.org/browse/AS7-2227
Project: Application Server 7
Issue Type: Feature Request
Components: Console
Affects Versions: 7.1.0.Alpha1, 7.0.2.Final
Reporter: Dimitris Andreadis
Assignee: Dimitris Andreadis
Fix For: 7.1.0.Beta1
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 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
11 years, 9 months
[JBoss JIRA] (AS7-5443) Lookup of application resources failed in PreDestroy
by Cheng Fang (JIRA)
Cheng Fang created AS7-5443:
-------------------------------
Summary: Lookup of application resources failed in PreDestroy
Key: AS7-5443
URL: https://issues.jboss.org/browse/AS7-5443
Project: Application Server 7
Issue Type: Bug
Components: Naming
Affects Versions: 7.2.0.Alpha1
Reporter: Cheng Fang
Assignee: Eduardo Martins
JNDI lookup (e.g., java:app/AppName)in servlet or ejb @PreDestroy method failed:
{noformat}
13:33:32,223 INFO [stdout] (MSC service thread 1-16) In preDestroy of test.TestServlet@bea6b3
13:33:32,224 ERROR [stderr] (MSC service thread 1-16) javax.naming.NameNotFoundException: Error looking up AppName, service service jboss.naming.context.java.app.test.AppName is not started
13:33:32,224 ERROR [stderr] (MSC service thread 1-16) at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:126)
13:33:32,224 ERROR [stderr] (MSC service thread 1-16) at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:74)
13:33:32,224 ERROR [stderr] (MSC service thread 1-16) at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:179)
13:33:32,224 ERROR [stderr] (MSC service thread 1-16) at org.jboss.as.naming.InitialContext.lookup(InitialContext.java:129)
13:33:32,224 ERROR [stderr] (MSC service thread 1-16) at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:215)
13:33:32,224 ERROR [stderr] (MSC service thread 1-16) at javax.naming.InitialContext.lookup(InitialContext.java:392)
13:33:32,224 ERROR [stderr] (MSC service thread 1-16) at javax.naming.InitialContext.doLookup(InitialContext.java:265)
13:33:32,224 ERROR [stderr] (MSC service thread 1-16) at test.TestServlet.preDestroy(TestServlet.java:25)
13:33:32,224 ERROR [stderr] (MSC service thread 1-16) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
13:33:32,225 ERROR [stderr] (MSC service thread 1-16) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
13:33:32,225 ERROR [stderr] (MSC service thread 1-16) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
13:33:32,225 ERROR [stderr] (MSC service thread 1-16) at java.lang.reflect.Method.invoke(Method.java:597)
13:33:32,225 ERROR [stderr] (MSC service thread 1-16) at org.jboss.as.ee.component.ManagedReferenceLifecycleMethodInterceptorFactory$ManagedReferenceLifecycleMethodInterceptor.processInvocation(ManagedReferenceLifecycleMethodInterceptorFactory.java:130)
13:33:32,225 ERROR [stderr] (MSC service thread 1-16) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288)
13:33:32,225 ERROR [stderr] (MSC service thread 1-16) at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53)
13:33:32,225 ERROR [stderr] (MSC service thread 1-16) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288)
13:33:32,225 ERROR [stderr] (MSC service thread 1-16) at org.jboss.as.ee.component.ManagedReferenceReleaseInterceptorFactory$ManagedReferenceReleaseInterceptor.processInvocation(ManagedReferenceReleaseInterceptorFactory.java:90)
13:33:32,225 ERROR [stderr] (MSC service thread 1-16) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288)
13:33:32,225 ERROR [stderr] (MSC service thread 1-16) at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53)
13:33:32,225 ERROR [stderr] (MSC service thread 1-16) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288)
13:33:32,225 ERROR [stderr] (MSC service thread 1-16) at org.jboss.as.ee.component.ManagedReferenceReleaseInterceptorFactory$ManagedReferenceReleaseInterceptor.processInvocation(ManagedReferenceReleaseInterceptorFactory.java:90)
13:33:32,226 ERROR [stderr] (MSC service thread 1-16) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288)
13:33:32,226 ERROR [stderr] (MSC service thread 1-16) at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53)
13:33:32,226 ERROR [stderr] (MSC service thread 1-16) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288)
13:33:32,226 ERROR [stderr] (MSC service thread 1-16) at org.jboss.as.ee.component.TCCLInterceptor.processInvocation(TCCLInterceptor.java:45)
13:33:32,226 ERROR [stderr] (MSC service thread 1-16) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288)
13:33:32,226 ERROR [stderr] (MSC service thread 1-16) at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
13:33:32,226 ERROR [stderr] (MSC service thread 1-16) at org.jboss.as.ee.component.BasicComponentInstance.destroy(BasicComponentInstance.java:119)
13:33:32,226 ERROR [stderr] (MSC service thread 1-16) at org.jboss.as.web.deployment.component.WebComponentInstantiator$1.release(WebComponentInstantiator.java:63)
13:33:32,226 ERROR [stderr] (MSC service thread 1-16) at org.jboss.as.web.deployment.WebInjectionContainer.destroyInstance(WebInjectionContainer.java:69)
13:33:32,226 ERROR [stderr] (MSC service thread 1-16) at org.apache.catalina.core.StandardWrapper.unload(StandardWrapper.java:1389)
13:33:32,226 ERROR [stderr] (MSC service thread 1-16) at org.apache.catalina.core.StandardWrapper.stop(StandardWrapper.java:1682)
13:33:32,227 ERROR [stderr] (MSC service thread 1-16) at org.apache.catalina.core.StandardContext.stop(StandardContext.java:3985)
13:33:32,227 ERROR [stderr] (MSC service thread 1-16) at org.jboss.as.web.deployment.WebDeploymentService.stop(WebDeploymentService.java:118)
13:33:32,227 ERROR [stderr] (MSC service thread 1-16) at org.jboss.msc.service.ServiceControllerImpl$StopTask.stopService(ServiceControllerImpl.java:1911)
13:33:32,227 ERROR [stderr] (MSC service thread 1-16) at org.jboss.msc.service.ServiceControllerImpl$StopTask.run(ServiceControllerImpl.java:1874)
13:33:32,227 ERROR [stderr] (MSC service thread 1-16) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
13:33:32,227 ERROR [stderr] (MSC service thread 1-16) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
13:33:32,227 ERROR [stderr] (MSC service thread 1-16) at java.lang.Thread.run(Thread.java:680)
{noformat}
jndi service and application resources should be available in @PreDestroy.
--
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
11 years, 9 months