[JBoss JIRA] (AS7-5722) Backward compatibility issue with JMS clients
by Clebert Suconic (JIRA)
[ https://issues.jboss.org/browse/AS7-5722?page=com.atlassian.jira.plugin.s... ]
Clebert Suconic commented on AS7-5722:
--------------------------------------
This should been fixed on the latest Beta. We should have a CR soon.
> Backward compatibility issue with JMS clients
> ---------------------------------------------
>
> Key: AS7-5722
> URL: https://issues.jboss.org/browse/AS7-5722
> Project: Application Server 7
> Issue Type: Bug
> Components: JMS
> Reporter: Miroslav Novak
> Assignee: Jeff Mesnil
> Priority: Critical
> Fix For: 7.2.0.Alpha1
>
>
> When standalone jms client is trying to connect with "old" jboss-client.jar from AS 7.1.2.Final (HornetQ 2.2.16.Final) to AS 7.2.0.Alpha1 (HornetQ 2.3.0.Beta1) then ClassNotFoundException it thrown:
> Console log of jms client:
> {code}
> [jbossqa@station4 as7-with-hq-replicated]$ java -cp /home/jbossqa/hornetq_eap6_testsuite/as7-with-hq-replicated/client-1.0-SNAPSHOT.jar:/home/jbossqa/hornetq_eap6_testsuite/server1/jboss-eap-6.0/bin/client/jboss-client.jar org.jboss.jms.client.TestProducer 192.168.40.1 jms/queue/testQueue0 10
> remote://192.168.40.1:4447
> Oct 10, 2012 11:44:41 AM org.xnio.Xnio <clinit>
> INFO: XNIO Version 3.0.6.GA-redhat-1
> Oct 10, 2012 11:44:41 AM org.xnio.nio.NioXnio <clinit>
> INFO: XNIO NIO Implementation Version 3.0.6.GA-redhat-1
> Oct 10, 2012 11:44:41 AM org.jboss.remoting3.EndpointImpl <clinit>
> INFO: JBoss Remoting version 3.2.8.SP1-redhat-1
> Oct 10, 2012 11:44:42 AM org.jboss.naming.remote.protocol.v1.RemoteNamingStoreV1$MessageReceiver handleEnd
> ERROR: Channel end notification received, closing channel Channel ID f6fa08e1 (outbound) of Remoting connection 2a0ab444 to /192.168.40.1:4447
> org.jboss.naming.remote.protocol.NamingIOException: Failed to lookup [Root exception is java.io.IOException: java.lang.ClassNotFoundException: org.hornetq.api.core.BroadcastEndpointFactoryConfiguration]
> at org.jboss.naming.remote.client.ClientUtil.namingException(ClientUtil.java:49)
> at org.jboss.naming.remote.protocol.v1.Protocol$1.execute(Protocol.java:104)
> at org.jboss.naming.remote.protocol.v1.RemoteNamingStoreV1.lookup(RemoteNamingStoreV1.java:78)
> at org.jboss.naming.remote.client.HaRemoteNamingStore$1.operation(HaRemoteNamingStore.java:227)
> at org.jboss.naming.remote.client.HaRemoteNamingStore.namingOperation(HaRemoteNamingStore.java:119)
> at org.jboss.naming.remote.client.HaRemoteNamingStore.lookup(HaRemoteNamingStore.java:223)
> at org.jboss.naming.remote.client.RemoteContext.lookup(RemoteContext.java:79)
> at org.jboss.naming.remote.client.RemoteContext.lookup(RemoteContext.java:83)
> at javax.naming.InitialContext.lookup(InitialContext.java:409)
> at org.jboss.jms.client.TestProducer.startClient(TestProducer.java:47)
> at org.jboss.jms.client.TestProducer.main(TestProducer.java:28)
> Caused by: java.io.IOException: java.lang.ClassNotFoundException: org.hornetq.api.core.BroadcastEndpointFactoryConfiguration
> at org.jboss.naming.remote.protocol.v1.Protocol$1$3.read(Protocol.java:159)
> at org.jboss.naming.remote.protocol.v1.BaseProtocolCommand.readResult(BaseProtocolCommand.java:60)
> at org.jboss.naming.remote.protocol.v1.Protocol$1.handleClientMessage(Protocol.java:149)
> at org.jboss.naming.remote.protocol.v1.RemoteNamingStoreV1$MessageReceiver$1.run(RemoteNamingStoreV1.java:210)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
> at java.lang.Thread.run(Thread.java:679)
> Caused by: java.lang.ClassNotFoundException: org.hornetq.api.core.BroadcastEndpointFactoryConfiguration
> at java.net.URLClassLoader$1.run(URLClassLoader.java:217)
> at java.security.AccessController.doPrivileged(Native Method)
> at java.net.URLClassLoader.findClass(URLClassLoader.java:205)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:321)
> at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:294)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:266)
> at java.lang.Class.forName0(Native Method)
> at java.lang.Class.forName(Class.java:264)
> at org.jboss.marshalling.AbstractClassResolver.loadClass(AbstractClassResolver.java:135)
> at org.jboss.marshalling.AbstractClassResolver.resolveClass(AbstractClassResolver.java:116)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadClassDescriptor(RiverUnmarshaller.java:871)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadClassDescriptor(RiverUnmarshaller.java:903)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadClassDescriptor(RiverUnmarshaller.java:903)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadNewObject(RiverUnmarshaller.java:1205)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:272)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:209)
> at org.jboss.marshalling.river.RiverUnmarshaller.readFields(RiverUnmarshaller.java:1678)
> at org.jboss.marshalling.river.RiverUnmarshaller.doInitSerializable(RiverUnmarshaller.java:1594)
> at org.jboss.marshalling.river.RiverUnmarshaller.doInitSerializable(RiverUnmarshaller.java:1558)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadNewObject(RiverUnmarshaller.java:1236)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:272)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:209)
> at org.jboss.marshalling.AbstractObjectInput.readObject(AbstractObjectInput.java:37)
> at org.jboss.naming.remote.protocol.v1.Protocol$1$3.read(Protocol.java:156)
> ... 6 more
> Oct 10, 2012 11:44:42 AM org.jboss.naming.remote.protocol.v1.RemoteNamingStoreV1$MessageReceiver handleEnd
> ERROR: Channel end notification received, closing channel Channel ID dac0f594 (outbound) of Remoting connection 16e1eea8 to /192.168.40.1:4447
> {code}
> How to reproduce:
> 1) Download reproducer.zip from QA Lab and unzip reproducer.zip: {code}scp -r messaging-18.jbm.lab.bos.redhat.com:/home/mnovak/reproducer-backward-compatibility .{code}
> 2) Start AS7 server:{code}cd jboss-as-7.2.0.Alpha1-SNAPSHOT/bin;sh standalone.sh -c standalone-full-ha.xml -b localhost{code}
> 3) Start jms producer:{code}java -cp $PWD/client-1.0-SNAPSHOT.jar:$PWD/jboss-old-hq226-client.jar org.jboss.jms.client.TestProducer localhost jms/queue/testQueue0 10{code}
--
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
13 years, 6 months
[JBoss JIRA] (AS7-5722) Backward compatibility issue with JMS clients
by John Doyle (JIRA)
[ https://issues.jboss.org/browse/AS7-5722?page=com.atlassian.jira.plugin.s... ]
John Doyle commented on AS7-5722:
---------------------------------
[~andrigmiller] Do you have a written record of that compatibility commitment? [~pslavicek] Do you know if we're testing such a comittment?
> Backward compatibility issue with JMS clients
> ---------------------------------------------
>
> Key: AS7-5722
> URL: https://issues.jboss.org/browse/AS7-5722
> Project: Application Server 7
> Issue Type: Bug
> Components: JMS
> Reporter: Miroslav Novak
> Assignee: Jeff Mesnil
> Priority: Critical
> Fix For: 7.2.0.Alpha1
>
>
> When standalone jms client is trying to connect with "old" jboss-client.jar from AS 7.1.2.Final (HornetQ 2.2.16.Final) to AS 7.2.0.Alpha1 (HornetQ 2.3.0.Beta1) then ClassNotFoundException it thrown:
> Console log of jms client:
> {code}
> [jbossqa@station4 as7-with-hq-replicated]$ java -cp /home/jbossqa/hornetq_eap6_testsuite/as7-with-hq-replicated/client-1.0-SNAPSHOT.jar:/home/jbossqa/hornetq_eap6_testsuite/server1/jboss-eap-6.0/bin/client/jboss-client.jar org.jboss.jms.client.TestProducer 192.168.40.1 jms/queue/testQueue0 10
> remote://192.168.40.1:4447
> Oct 10, 2012 11:44:41 AM org.xnio.Xnio <clinit>
> INFO: XNIO Version 3.0.6.GA-redhat-1
> Oct 10, 2012 11:44:41 AM org.xnio.nio.NioXnio <clinit>
> INFO: XNIO NIO Implementation Version 3.0.6.GA-redhat-1
> Oct 10, 2012 11:44:41 AM org.jboss.remoting3.EndpointImpl <clinit>
> INFO: JBoss Remoting version 3.2.8.SP1-redhat-1
> Oct 10, 2012 11:44:42 AM org.jboss.naming.remote.protocol.v1.RemoteNamingStoreV1$MessageReceiver handleEnd
> ERROR: Channel end notification received, closing channel Channel ID f6fa08e1 (outbound) of Remoting connection 2a0ab444 to /192.168.40.1:4447
> org.jboss.naming.remote.protocol.NamingIOException: Failed to lookup [Root exception is java.io.IOException: java.lang.ClassNotFoundException: org.hornetq.api.core.BroadcastEndpointFactoryConfiguration]
> at org.jboss.naming.remote.client.ClientUtil.namingException(ClientUtil.java:49)
> at org.jboss.naming.remote.protocol.v1.Protocol$1.execute(Protocol.java:104)
> at org.jboss.naming.remote.protocol.v1.RemoteNamingStoreV1.lookup(RemoteNamingStoreV1.java:78)
> at org.jboss.naming.remote.client.HaRemoteNamingStore$1.operation(HaRemoteNamingStore.java:227)
> at org.jboss.naming.remote.client.HaRemoteNamingStore.namingOperation(HaRemoteNamingStore.java:119)
> at org.jboss.naming.remote.client.HaRemoteNamingStore.lookup(HaRemoteNamingStore.java:223)
> at org.jboss.naming.remote.client.RemoteContext.lookup(RemoteContext.java:79)
> at org.jboss.naming.remote.client.RemoteContext.lookup(RemoteContext.java:83)
> at javax.naming.InitialContext.lookup(InitialContext.java:409)
> at org.jboss.jms.client.TestProducer.startClient(TestProducer.java:47)
> at org.jboss.jms.client.TestProducer.main(TestProducer.java:28)
> Caused by: java.io.IOException: java.lang.ClassNotFoundException: org.hornetq.api.core.BroadcastEndpointFactoryConfiguration
> at org.jboss.naming.remote.protocol.v1.Protocol$1$3.read(Protocol.java:159)
> at org.jboss.naming.remote.protocol.v1.BaseProtocolCommand.readResult(BaseProtocolCommand.java:60)
> at org.jboss.naming.remote.protocol.v1.Protocol$1.handleClientMessage(Protocol.java:149)
> at org.jboss.naming.remote.protocol.v1.RemoteNamingStoreV1$MessageReceiver$1.run(RemoteNamingStoreV1.java:210)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
> at java.lang.Thread.run(Thread.java:679)
> Caused by: java.lang.ClassNotFoundException: org.hornetq.api.core.BroadcastEndpointFactoryConfiguration
> at java.net.URLClassLoader$1.run(URLClassLoader.java:217)
> at java.security.AccessController.doPrivileged(Native Method)
> at java.net.URLClassLoader.findClass(URLClassLoader.java:205)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:321)
> at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:294)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:266)
> at java.lang.Class.forName0(Native Method)
> at java.lang.Class.forName(Class.java:264)
> at org.jboss.marshalling.AbstractClassResolver.loadClass(AbstractClassResolver.java:135)
> at org.jboss.marshalling.AbstractClassResolver.resolveClass(AbstractClassResolver.java:116)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadClassDescriptor(RiverUnmarshaller.java:871)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadClassDescriptor(RiverUnmarshaller.java:903)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadClassDescriptor(RiverUnmarshaller.java:903)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadNewObject(RiverUnmarshaller.java:1205)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:272)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:209)
> at org.jboss.marshalling.river.RiverUnmarshaller.readFields(RiverUnmarshaller.java:1678)
> at org.jboss.marshalling.river.RiverUnmarshaller.doInitSerializable(RiverUnmarshaller.java:1594)
> at org.jboss.marshalling.river.RiverUnmarshaller.doInitSerializable(RiverUnmarshaller.java:1558)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadNewObject(RiverUnmarshaller.java:1236)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:272)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:209)
> at org.jboss.marshalling.AbstractObjectInput.readObject(AbstractObjectInput.java:37)
> at org.jboss.naming.remote.protocol.v1.Protocol$1$3.read(Protocol.java:156)
> ... 6 more
> Oct 10, 2012 11:44:42 AM org.jboss.naming.remote.protocol.v1.RemoteNamingStoreV1$MessageReceiver handleEnd
> ERROR: Channel end notification received, closing channel Channel ID dac0f594 (outbound) of Remoting connection 16e1eea8 to /192.168.40.1:4447
> {code}
> How to reproduce:
> 1) Download reproducer.zip from QA Lab and unzip reproducer.zip: {code}scp -r messaging-18.jbm.lab.bos.redhat.com:/home/mnovak/reproducer-backward-compatibility .{code}
> 2) Start AS7 server:{code}cd jboss-as-7.2.0.Alpha1-SNAPSHOT/bin;sh standalone.sh -c standalone-full-ha.xml -b localhost{code}
> 3) Start jms producer:{code}java -cp $PWD/client-1.0-SNAPSHOT.jar:$PWD/jboss-old-hq226-client.jar org.jboss.jms.client.TestProducer localhost jms/queue/testQueue0 10{code}
--
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
13 years, 6 months
[JBoss JIRA] (JASSIST-189) Bridge methods are proxied instead of desired methods
by Scott Marlow (JIRA)
[ https://issues.jboss.org/browse/JASSIST-189?page=com.atlassian.jira.plugi... ]
Scott Marlow commented on JASSIST-189:
--------------------------------------
Is the above patch to ProxyFactory correct?
> Bridge methods are proxied instead of desired methods
> -----------------------------------------------------
>
> Key: JASSIST-189
> URL: https://issues.jboss.org/browse/JASSIST-189
> Project: Javassist
> Issue Type: Bug
> Affects Versions: 3.17.1-GA
> Environment: OS X, Java 1.7.0_09
> Reporter: Donnchadh Ó Donnabháin
> Assignee: Shigeru Chiba
>
> The following test intermittently fails:
> {code}
> package org.javassist.test.covariantproxy;
> import java.lang.reflect.Method;
> import javassist.util.proxy.MethodHandler;
> import javassist.util.proxy.ProxyFactory;
> import javassist.util.proxy.ProxyObject;
> import junit.framework.TestCase;
> public class CovariantProxyTest extends TestCase {
>
> public interface TestProxy {
>
> }
>
> public static class TestMethodHandler implements MethodHandler {
>
> boolean invoked = false;
> public Object invoke(Object self, Method thisMethod, Method proceed, Object[] args) throws Throwable {
> invoked = true;
> return proceed.invoke(self, args);
> }
>
> public boolean wasInvoked() {
> return invoked;
> }
> public void reset() {
> invoked = false;
> }
> }
> public static class Issue {
>
> private Integer id;
>
> public Integer getId() {
> return id;
> }
>
> public void setId(Integer id) {
> this.id = id;
> }
> }
>
> public static class PublishedIssue extends Issue {
>
> }
> public static abstract class Article {
>
> private Integer id;
>
> public Integer getId() {
> return id;
> }
>
> public void setId(Integer id) {
> this.id = id;
> }
>
> public abstract Issue getIssue();
> }
> public static class PublishedArticle extends Article {
>
> private PublishedIssue issue;
>
> @Override
> public PublishedIssue getIssue() {
> return issue;
> }
>
> public void setIssue(PublishedIssue issue) {
> this.issue = issue;
> }
>
> }
>
> public void testThatCallingAMethodWithCovariantReturnTypeCallsProxy() throws Exception {
> Class persistentClass = PublishedArticle.class;
> ProxyFactory factory = new ProxyFactory();
> factory.setUseCache(false);
> factory.setSuperclass(persistentClass);
> factory.setInterfaces(new Class[] {TestProxy.class});
> Class cl = factory.createClass();
> TestProxy proxy = ( TestProxy ) cl.newInstance();
> TestMethodHandler methodHandler = new TestMethodHandler();
> ( ( ProxyObject ) proxy ).setHandler( methodHandler );
>
> ((Article)proxy).getIssue();
> assertTrue(methodHandler.wasInvoked());
>
> methodHandler.reset();
>
> PublishedArticle article = (PublishedArticle) proxy;
>
> article.getIssue();
>
> assertTrue(methodHandler.wasInvoked());
>
> }
>
> }
> {code}
> Were there tests added for JASSIST-24 ? I don't see any associated source.
> This bug causes a problem in hibernate, described in https://hibernate.onjira.com/browse/HHH-7884 .
> This may be related to JASSIST-162 but the circumstances are slightly different.
> The problem occurs intermittently so it appears to depend on the order in which the methods are processed.
--
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
13 years, 6 months
[JBoss JIRA] (AS7-6275) AS7/EAP6 @Stateless/mappedName behaviour could be made consistent with AS5/EAP5
by Baptiste MATHUS (JIRA)
[ https://issues.jboss.org/browse/AS7-6275?page=com.atlassian.jira.plugin.s... ]
Baptiste MATHUS updated AS7-6275:
---------------------------------
Issue Type: Bug (was: Feature Request)
> AS7/EAP6 @Stateless/mappedName behaviour could be made consistent with AS5/EAP5
> -------------------------------------------------------------------------------
>
> Key: AS7-6275
> URL: https://issues.jboss.org/browse/AS7-6275
> Project: Application Server 7
> Issue Type: Bug
> Affects Versions: 7.1.3.Final (EAP)
> Environment: Windows7
> Reporter: Baptiste MATHUS
> Labels: regression
>
> Though I agree mappedName was never meant to be standard, as reminded in the link below, at least it was something done within JBoss AS, and I wonder if something better for *JBoss* users&customers couldn't be made to help them.
> How difficult would it be for example to bind SLSB to the given mappedName (in addition to the standard portable jndi naming, sure)?
> I admit we've certainly been using it the wrong way in our shop, but that's how it is now, and today this change is currently being one of the biggest PITA for us to migrate between EAP5 and EAP6...
> By the way, even a special patch or workaround that could make that possible would be perfect.
> WDYT?
> Thanks!
> (Note: I already read carefully the following thread: http://lists.jboss.org/pipermail/jboss-as7-dev/2011-May/002246.html I searched the jiras without finding one about that subject, so I eventually decided to create this entry for potential reference).
--
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
13 years, 6 months
[JBoss JIRA] (DROOLS-9) Exception in User-defined Java method when rules are optimized by the JIT compiler
by Andreas Bentele (JIRA)
[ https://issues.jboss.org/browse/DROOLS-9?page=com.atlassian.jira.plugin.s... ]
Andreas Bentele updated DROOLS-9:
---------------------------------
Description:
I watched this issue after upgrading from Drools 5.3.1 to Drools 5.5.0.Final.
I didn't find any trivial example, so I reproduced the error with a non-trivial test case derived from a real-live rule, and attached the test case to this issue. The output is listed in the field "Steps to reproduce":
What does the application:
- it calls the rule "DroolsJITTest-Rule" 20 times - 20 is the threshold for jitting. In the output, you can see the line "Service.getAllTimers" 20 times.
- after that output, a exception during jitting is thrown, because com.sample.Service.getTimePerStroke(Service.java:42) throwed an exception
- this service is called in the LHS of the rule
But:
# in the rule, the following expression evaluates always to false, because service.getLongValue returns always 0
{code}
$service.getLongValue(service.workplaceIdForMachineId($machineId, $actionTimestamp), "RC.WORKPLACE_LEADING_OPERATION_ID") > 0
{code}
# from this and rule semantics it follows that the next expression should never be evaluated, but the JIT compiler evaluates it:
{code}
service.getTimePerStroke($service.getLongValue(service.workplaceIdForMachineId($machineId, $actionTimestamp), "RC.WORKPLACE_LEADING_OPERATION_ID")) > 15
{code}
# as we have seen in the bullet no. 1, the parameter of service.getTimePerStroke is 0. In com.sample.Service, Line 41 the parameter value is asserted to be not 0, so an RuntimeException is thrown (Line 42).
Code of the rule:
{code}
rule "DroolsJITTest-Rule"
when
$service : Service()
p: PulseEvent(
$actionTimestamp : actionTimestamp,
$eventTimestamp : eventTimestamp
)
t: TimerToken(
$machineId : id,
$timestampUTC : timestampUTC,
$service.getLongValue(service.workplaceIdForMachineId($machineId, $actionTimestamp), "RC.WORKPLACE_LEADING_OPERATION_ID") > 0,
service.getTimePerStroke($service.getLongValue(service.workplaceIdForMachineId($machineId, $actionTimestamp), "RC.WORKPLACE_LEADING_OPERATION_ID")) > 15
) from $service.getAllTimers("RC.MACHINE_STROKE_TIMER")
then
System.out.println( "Rule executed" );
update(p);
end
{code}
I think, it's a failure that the JIT compiler evaluates the line
{code}
service.getTimePerStroke($service.getLongValue(service.workplaceIdForMachineId($machineId, $actionTimestamp), "RC.WORKPLACE_LEADING_OPERATION_ID")) > 15
{code}
because the previous condition expression evaluates to false. Or do you think this behavior works as designed?
was:
I watched this issue after upgrading from Drools 5.3.1 to Drools 5.5.0.Final.
I didn't find any trivial example, so I reproduced the error with a non-trivial test case derived from a real-live rule, and attached the test case to this issue. The output is listed in the field "Steps to reproduce":
What does the application:
- it calls the rule "DroolsJITTest-Rule" 20 times - 20 is the threshold for jitting. In the output, you can see the line "Service.getAllTimers" 20 times.
- after that output, a exception during jitting is thrown, because com.sample.Service.getTimePerStroke(Service.java:42) throwed an exception
- this service is called in the LHS of the rule
But:
# in the rule, the following expression evaluates always to false, because service.getLongValue returns always 0
{code}
$service.getLongValue(service.workplaceIdForMachineId($machineId, $actionTimestamp), "RC.WORKPLACE_LEADING_OPERATION_ID") > 0
{code}
# from this and rule semantics it follows that the next expression should never be evaluated, but the JIT compiler evaluates it:
{code}
service.getTimePerStroke($service.getLongValue(service.workplaceIdForMachineId($machineId, $actionTimestamp), "RC.WORKPLACE_LEADING_OPERATION_ID")) > 15
{code}
# as we have seen in the bullet no. 1, the parameter of service.getTimePerStroke is 0. In com.sample.Service, Line 41 the parameter value is asserted to be not 0, so an RuntimeException is thrown (Line 42).
Code of the rule:
{code}
rule "DroolsJITTest-Rule"
when
$service : Service()
p: PulseEvent(
$actionTimestamp : actionTimestamp,
$eventTimestamp : eventTimestamp
)
t: TimerToken(
$machineId : id,
$timestampUTC : timestampUTC,
$service.getLongValue(service.workplaceIdForMachineId($machineId, $actionTimestamp), "RC.WORKPLACE_LEADING_OPERATION_ID") > 0,
service.getTimePerStroke($service.getLongValue(service.workplaceIdForMachineId($machineId, $actionTimestamp), "RC.WORKPLACE_LEADING_OPERATION_ID")) > 15
) from $service.getAllTimers("RC.MACHINE_STROKE_TIMER")
then
System.out.println( "Rule executed" );
update(p);
end
{code}
> Exception in User-defined Java method when rules are optimized by the JIT compiler
> -----------------------------------------------------------------------------------
>
> Key: DROOLS-9
> URL: https://issues.jboss.org/browse/DROOLS-9
> Project: Drools
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Reporter: Andreas Bentele
> Assignee: Mark Proctor
> Attachments: DroolsJITTestCase.zip
>
>
> I watched this issue after upgrading from Drools 5.3.1 to Drools 5.5.0.Final.
> I didn't find any trivial example, so I reproduced the error with a non-trivial test case derived from a real-live rule, and attached the test case to this issue. The output is listed in the field "Steps to reproduce":
> What does the application:
> - it calls the rule "DroolsJITTest-Rule" 20 times - 20 is the threshold for jitting. In the output, you can see the line "Service.getAllTimers" 20 times.
> - after that output, a exception during jitting is thrown, because com.sample.Service.getTimePerStroke(Service.java:42) throwed an exception
> - this service is called in the LHS of the rule
> But:
> # in the rule, the following expression evaluates always to false, because service.getLongValue returns always 0
> {code}
> $service.getLongValue(service.workplaceIdForMachineId($machineId, $actionTimestamp), "RC.WORKPLACE_LEADING_OPERATION_ID") > 0
> {code}
> # from this and rule semantics it follows that the next expression should never be evaluated, but the JIT compiler evaluates it:
> {code}
> service.getTimePerStroke($service.getLongValue(service.workplaceIdForMachineId($machineId, $actionTimestamp), "RC.WORKPLACE_LEADING_OPERATION_ID")) > 15
> {code}
> # as we have seen in the bullet no. 1, the parameter of service.getTimePerStroke is 0. In com.sample.Service, Line 41 the parameter value is asserted to be not 0, so an RuntimeException is thrown (Line 42).
> Code of the rule:
> {code}
> rule "DroolsJITTest-Rule"
> when
> $service : Service()
> p: PulseEvent(
> $actionTimestamp : actionTimestamp,
> $eventTimestamp : eventTimestamp
> )
> t: TimerToken(
> $machineId : id,
> $timestampUTC : timestampUTC,
> $service.getLongValue(service.workplaceIdForMachineId($machineId, $actionTimestamp), "RC.WORKPLACE_LEADING_OPERATION_ID") > 0,
> service.getTimePerStroke($service.getLongValue(service.workplaceIdForMachineId($machineId, $actionTimestamp), "RC.WORKPLACE_LEADING_OPERATION_ID")) > 15
> ) from $service.getAllTimers("RC.MACHINE_STROKE_TIMER")
> then
> System.out.println( "Rule executed" );
> update(p);
> end
> {code}
> I think, it's a failure that the JIT compiler evaluates the line
> {code}
> service.getTimePerStroke($service.getLongValue(service.workplaceIdForMachineId($machineId, $actionTimestamp), "RC.WORKPLACE_LEADING_OPERATION_ID")) > 15
> {code}
> because the previous condition expression evaluates to false. Or do you think this behavior works as designed?
--
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
13 years, 6 months
[JBoss JIRA] (JBWEB-228) Globally configure an Authenticator Valve for the whole JBoss.
by Dimitris Andreadis (JIRA)
[ https://issues.jboss.org/browse/JBWEB-228?page=com.atlassian.jira.plugin.... ]
Dimitris Andreadis resolved JBWEB-228.
--------------------------------------
Resolution: Done
> Globally configure an Authenticator Valve for the whole JBoss.
> --------------------------------------------------------------
>
> Key: JBWEB-228
> URL: https://issues.jboss.org/browse/JBWEB-228
> Project: JBoss Web
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Affects Versions: JBossWeb-7.0.0.GA, JBossWeb-7.0.1.GA , JBossWeb-7.0.2.GA, JBossWeb-7.0.9.GA
> Reporter: Mo Zo
> Assignee: Jean-Frederic Clere
>
> Please add an option to set and configure an Authenticator (Valve) globally for all applications in a JBoss by using standard JBoss mechanisms like domain.xml, standalone.xml and DMR, so that it would be possible to reference an Authenticator like this:
> web.xml
> <login-config>
> <auth-method>CUSTOM</auth-method>
> </login-config>
> To achieve this I had to modify:
> ...\modules\org\jboss\as\web\main\jbossweb-7.0.X.Final.jar\org\apache\catalina\startup\Authenticators.properties
> CUSTOM=<full qualified authenticator class name>
> which certainly is not a good way.
--
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
13 years, 6 months
[JBoss JIRA] (JBWEB-228) Globally configure an Authenticator Valve for the whole JBoss.
by Dimitris Andreadis (JIRA)
[ https://issues.jboss.org/browse/JBWEB-228?page=com.atlassian.jira.plugin.... ]
Dimitris Andreadis reopened JBWEB-228:
--------------------------------------
> Globally configure an Authenticator Valve for the whole JBoss.
> --------------------------------------------------------------
>
> Key: JBWEB-228
> URL: https://issues.jboss.org/browse/JBWEB-228
> Project: JBoss Web
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Affects Versions: JBossWeb-7.0.0.GA, JBossWeb-7.0.1.GA , JBossWeb-7.0.2.GA, JBossWeb-7.0.9.GA
> Reporter: Mo Zo
> Assignee: Jean-Frederic Clere
>
> Please add an option to set and configure an Authenticator (Valve) globally for all applications in a JBoss by using standard JBoss mechanisms like domain.xml, standalone.xml and DMR, so that it would be possible to reference an Authenticator like this:
> web.xml
> <login-config>
> <auth-method>CUSTOM</auth-method>
> </login-config>
> To achieve this I had to modify:
> ...\modules\org\jboss\as\web\main\jbossweb-7.0.X.Final.jar\org\apache\catalina\startup\Authenticators.properties
> CUSTOM=<full qualified authenticator class name>
> which certainly is not a good way.
--
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
13 years, 6 months
[JBoss JIRA] (DROOLS-9) Exception in User-defined Java method when rules are optimized by the JIT compiler
by Andreas Bentele (JIRA)
[ https://issues.jboss.org/browse/DROOLS-9?page=com.atlassian.jira.plugin.s... ]
Andreas Bentele updated DROOLS-9:
---------------------------------
Description:
I watched this issue after upgrading from Drools 5.3.1 to Drools 5.5.0.Final.
I didn't find any trivial example, so I reproduced the error with a non-trivial test case derived from a real-live rule, and attached the test case to this issue. The output is listed in the field "Steps to reproduce":
What does the application:
- it calls the rule "DroolsJITTest-Rule" 20 times - 20 is the threshold for jitting. In the output, you can see the line "Service.getAllTimers" 20 times.
- after that output, a exception during jitting is thrown, because com.sample.Service.getTimePerStroke(Service.java:42) throwed an exception
- this service is called in the LHS of the rule
But:
# in the rule, the following expression evaluates always to false, because service.getLongValue returns always 0
{code}
$service.getLongValue(service.workplaceIdForMachineId($machineId, $actionTimestamp), "RC.WORKPLACE_LEADING_OPERATION_ID") > 0
{code}
# from this and rule semantics it follows that the next expression should never be evaluated, but the JIT compiler evaluates it:
{code}
service.getTimePerStroke($service.getLongValue(service.workplaceIdForMachineId($machineId, $actionTimestamp), "RC.WORKPLACE_LEADING_OPERATION_ID")) > 15
{code}
# as we have seen in the bullet no. 1, the parameter of service.getTimePerStroke is 0. In com.sample.Service, Line 41 the parameter value is asserted to be not 0, so an RuntimeException is thrown (Line 42).
Code of the rule:
{code}
rule "DroolsJITTest-Rule"
when
$service : Service()
p: PulseEvent(
$actionTimestamp : actionTimestamp,
$eventTimestamp : eventTimestamp
)
t: TimerToken(
$machineId : id,
$timestampUTC : timestampUTC,
$service.getLongValue(service.workplaceIdForMachineId($machineId, $actionTimestamp), "RC.WORKPLACE_LEADING_OPERATION_ID") > 0,
service.getTimePerStroke($service.getLongValue(service.workplaceIdForMachineId($machineId, $actionTimestamp), "RC.WORKPLACE_LEADING_OPERATION_ID")) > 15
) from $service.getAllTimers("RC.MACHINE_STROKE_TIMER")
then
System.out.println( "Rule executed" );
update(p);
end
{code}
was:
I watched this issue after upgrading from Drools 5.3.1 to Drools 5.5.0.Final.
I didn't find any trivial example, so I reproduced the error with a non-trivial test case, and attached the test case to this issue. The output is listed in the field "Steps to reproduce":
What does the application:
- it calls the rule "DroolsJITTest-Rule" 20 times - 20 is the threshold for jitting. In the output, you can see the line "Service.getAllTimers" 20 times.
- after that output, a exception during jitting is thrown, because com.sample.Service.getTimePerStroke(Service.java:42) throwed an exception
- this service is called in the LHS of the rule
But:
Code of the rule:
{code}
rule "DroolsJITTest-Rule"
when
$service : Service()
p: PulseEvent(
$actionTimestamp : actionTimestamp,
$eventTimestamp : eventTimestamp
)
t: TimerToken(
$machineId : id,
$timestampUTC : timestampUTC,
$service.getLongValue(service.workplaceIdForMachineId($machineId, $actionTimestamp), "RC.WORKPLACE_LEADING_OPERATION_ID") > 0,
service.getTimePerStroke($service.getLongValue(service.workplaceIdForMachineId($machineId, $actionTimestamp), "RC.WORKPLACE_LEADING_OPERATION_ID")) > 15
) from $service.getAllTimers("RC.MACHINE_STROKE_TIMER")
then
System.out.println( "Rule executed" );
update(p);
end
{code}
> Exception in User-defined Java method when rules are optimized by the JIT compiler
> -----------------------------------------------------------------------------------
>
> Key: DROOLS-9
> URL: https://issues.jboss.org/browse/DROOLS-9
> Project: Drools
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Reporter: Andreas Bentele
> Assignee: Mark Proctor
> Attachments: DroolsJITTestCase.zip
>
>
> I watched this issue after upgrading from Drools 5.3.1 to Drools 5.5.0.Final.
> I didn't find any trivial example, so I reproduced the error with a non-trivial test case derived from a real-live rule, and attached the test case to this issue. The output is listed in the field "Steps to reproduce":
> What does the application:
> - it calls the rule "DroolsJITTest-Rule" 20 times - 20 is the threshold for jitting. In the output, you can see the line "Service.getAllTimers" 20 times.
> - after that output, a exception during jitting is thrown, because com.sample.Service.getTimePerStroke(Service.java:42) throwed an exception
> - this service is called in the LHS of the rule
> But:
> # in the rule, the following expression evaluates always to false, because service.getLongValue returns always 0
> {code}
> $service.getLongValue(service.workplaceIdForMachineId($machineId, $actionTimestamp), "RC.WORKPLACE_LEADING_OPERATION_ID") > 0
> {code}
> # from this and rule semantics it follows that the next expression should never be evaluated, but the JIT compiler evaluates it:
> {code}
> service.getTimePerStroke($service.getLongValue(service.workplaceIdForMachineId($machineId, $actionTimestamp), "RC.WORKPLACE_LEADING_OPERATION_ID")) > 15
> {code}
> # as we have seen in the bullet no. 1, the parameter of service.getTimePerStroke is 0. In com.sample.Service, Line 41 the parameter value is asserted to be not 0, so an RuntimeException is thrown (Line 42).
> Code of the rule:
> {code}
> rule "DroolsJITTest-Rule"
> when
> $service : Service()
> p: PulseEvent(
> $actionTimestamp : actionTimestamp,
> $eventTimestamp : eventTimestamp
> )
> t: TimerToken(
> $machineId : id,
> $timestampUTC : timestampUTC,
> $service.getLongValue(service.workplaceIdForMachineId($machineId, $actionTimestamp), "RC.WORKPLACE_LEADING_OPERATION_ID") > 0,
> service.getTimePerStroke($service.getLongValue(service.workplaceIdForMachineId($machineId, $actionTimestamp), "RC.WORKPLACE_LEADING_OPERATION_ID")) > 15
> ) from $service.getAllTimers("RC.MACHINE_STROKE_TIMER")
> then
> System.out.println( "Rule executed" );
> update(p);
> end
> {code}
--
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
13 years, 6 months
[JBoss JIRA] (DROOLS-9) Exception in User-defined Java method when rules are optimized by the JIT compiler
by Andreas Bentele (JIRA)
[ https://issues.jboss.org/browse/DROOLS-9?page=com.atlassian.jira.plugin.s... ]
Andreas Bentele updated DROOLS-9:
---------------------------------
Description:
I watched this issue after upgrading from Drools 5.3.1 to Drools 5.5.0.Final.
I didn't find any trivial example, so I reproduced the error with a non-trivial test case, and attached the test case to this issue. The output is listed in the field "Steps to reproduce":
What does the application:
- it calls the rule "DroolsJITTest-Rule" 20 times - 20 is the threshold for jitting. In the output, you can see the line "Service.getAllTimers" 20 times.
- after that output, a exception during jitting is thrown, because com.sample.Service.getTimePerStroke(Service.java:42) throwed an exception
- this service is called in the LHS of the rule
But:
Code of the rule:
{code}
rule "DroolsJITTest-Rule"
when
$service : Service()
p: PulseEvent(
$actionTimestamp : actionTimestamp,
$eventTimestamp : eventTimestamp
)
t: TimerToken(
$machineId : id,
$timestampUTC : timestampUTC,
$service.getLongValue(service.workplaceIdForMachineId($machineId, $actionTimestamp), "RC.WORKPLACE_LEADING_OPERATION_ID") > 0,
service.getTimePerStroke($service.getLongValue(service.workplaceIdForMachineId($machineId, $actionTimestamp), "RC.WORKPLACE_LEADING_OPERATION_ID")) > 15
) from $service.getAllTimers("RC.MACHINE_STROKE_TIMER")
then
System.out.println( "Rule executed" );
update(p);
end
{code}
was:
I watched this issue after upgrading from Drools 5.3.1 to Drools 5.5.0.Final.
I didn't find any trivial example, so I reproduced the error with a non-trivial test case, and attached the test case to this issue.
> Exception in User-defined Java method when rules are optimized by the JIT compiler
> -----------------------------------------------------------------------------------
>
> Key: DROOLS-9
> URL: https://issues.jboss.org/browse/DROOLS-9
> Project: Drools
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Reporter: Andreas Bentele
> Assignee: Mark Proctor
> Attachments: DroolsJITTestCase.zip
>
>
> I watched this issue after upgrading from Drools 5.3.1 to Drools 5.5.0.Final.
> I didn't find any trivial example, so I reproduced the error with a non-trivial test case, and attached the test case to this issue. The output is listed in the field "Steps to reproduce":
> What does the application:
> - it calls the rule "DroolsJITTest-Rule" 20 times - 20 is the threshold for jitting. In the output, you can see the line "Service.getAllTimers" 20 times.
> - after that output, a exception during jitting is thrown, because com.sample.Service.getTimePerStroke(Service.java:42) throwed an exception
> - this service is called in the LHS of the rule
> But:
> Code of the rule:
> {code}
> rule "DroolsJITTest-Rule"
> when
> $service : Service()
> p: PulseEvent(
> $actionTimestamp : actionTimestamp,
> $eventTimestamp : eventTimestamp
> )
> t: TimerToken(
> $machineId : id,
> $timestampUTC : timestampUTC,
> $service.getLongValue(service.workplaceIdForMachineId($machineId, $actionTimestamp), "RC.WORKPLACE_LEADING_OPERATION_ID") > 0,
> service.getTimePerStroke($service.getLongValue(service.workplaceIdForMachineId($machineId, $actionTimestamp), "RC.WORKPLACE_LEADING_OPERATION_ID")) > 15
> ) from $service.getAllTimers("RC.MACHINE_STROKE_TIMER")
> then
> System.out.println( "Rule executed" );
> update(p);
> end
> {code}
--
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
13 years, 6 months