[JBoss JIRA] (WFLY-1376) HttpServletResponseImpl.getWriter() cannot be called: getOutputStream() already called
by Juergen Zimmermann (JIRA)
[ https://issues.jboss.org/browse/WFLY-1376?page=com.atlassian.jira.plugin.... ]
Juergen Zimmermann commented on WFLY-1376:
------------------------------------------
I don't see this issue with Undertow 1.0.0.CR1 in the latest WildFly snapshot
> HttpServletResponseImpl.getWriter() cannot be called: getOutputStream() already called
> --------------------------------------------------------------------------------------
>
> Key: WFLY-1376
> URL: https://issues.jboss.org/browse/WFLY-1376
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Web (Undertow)
> Affects Versions: 8.0.0.Alpha1
> Reporter: Juergen Zimmermann
> Assignee: Stuart Douglas
> Fix For: 8.0.0.Alpha2
>
>
> When I invoke a RESTful web service for a not existing URI (resulting in a 404 error) I'm getting the stacktrace below. This is working fine with EAP 6.1.Beta.
> In web.xml I have this declaration for a 404 error and a JSF-based error page:
> <error-page>
> <error-code>404</error-code>
> <location>/error/pageNotFound.jsf</location>
> </error-page>
> Stacktrace:
> 12:36:03,921 SEVERE [javax.enterprise.resource.webcontainer.jsf.application] Error Rendering View[/error/pageNotFound.xhtml]: java.lang.IllegalStateException: UT010006: Cannot call getWriter(), getOutputStream() already called
> at io.undertow.servlet.spec.HttpServletResponseImpl.getWriter(HttpServletResponseImpl.java:284) [undertow-servlet-1.0.0.Alpha15.jar:1.0.0.Alpha15]
> at com.sun.faces.context.ExternalContextImpl.getResponseOutputWriter(ExternalContextImpl.java:834) [jsf-impl-2.2.0-m13-jbossorg-1.jar:]
> at javax.faces.context.ExternalContextWrapper.getResponseOutputWriter(ExternalContextWrapper.java:785) [jboss-jsf-api_2.2_spec-2.2.0-m13.jar:2.2.0-m13]
> at com.sun.faces.application.view.FaceletViewHandlingStrategy.createResponseWriter(FaceletViewHandlingStrategy.java:1166) [jsf-impl-2.2.0-m13-jbossorg-1.jar:]
> at com.sun.faces.application.view.FaceletViewHandlingStrategy.renderView(FaceletViewHandlingStrategy.java:390) [jsf-impl-2.2.0-m13-jbossorg-1.jar:]
> at com.sun.faces.application.view.MultiViewHandler.renderView(MultiViewHandler.java:131) [jsf-impl-2.2.0-m13-jbossorg-1.jar:]
> at javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:337) [jboss-jsf-api_2.2_spec-2.2.0-m13.jar:2.2.0-m13]
> at javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:337) [jboss-jsf-api_2.2_spec-2.2.0-m13.jar:2.2.0-m13]
> at com.sun.faces.lifecycle.RenderResponsePhase.execute(RenderResponsePhase.java:120) [jsf-impl-2.2.0-m13-jbossorg-1.jar:]
> at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101) [jsf-impl-2.2.0-m13-jbossorg-1.jar:]
> at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:219) [jsf-impl-2.2.0-m13-jbossorg-1.jar:]
> at javax.faces.webapp.FacesServlet.service(FacesServlet.java:647) [jboss-jsf-api_2.2_spec-2.2.0-m13.jar:2.2.0-m13]
> at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:87) [undertow-servlet-1.0.0.Alpha15.jar:1.0.0.Alpha15]
> at io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:82) [undertow-servlet-1.0.0.Alpha15.jar:1.0.0.Alpha15]
> at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:54) [undertow-servlet-1.0.0.Alpha15.jar:1.0.0.Alpha15]
> at io.undertow.server.HttpHandlers.executeHandler(HttpHandlers.java:46) [undertow-core-1.0.0.Alpha15.jar:1.0.0.Alpha15]
> at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:116) [undertow-servlet-1.0.0.Alpha15.jar:1.0.0.Alpha15]
> at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.0.0.Alpha15.jar:1.0.0.Alpha15]
> at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:79)
> at io.undertow.server.HttpHandlers.executeHandler(HttpHandlers.java:46) [undertow-core-1.0.0.Alpha15.jar:1.0.0.Alpha15]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:26) [undertow-core-1.0.0.Alpha15.jar:1.0.0.Alpha15]
> at io.undertow.server.HttpHandlers.executeHandler(HttpHandlers.java:46) [undertow-core-1.0.0.Alpha15.jar:1.0.0.Alpha15]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:26) [undertow-core-1.0.0.Alpha15.jar:1.0.0.Alpha15]
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:108) [undertow-servlet-1.0.0.Alpha15.jar:1.0.0.Alpha15]
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchToPath(ServletInitialHandler.java:93) [undertow-servlet-1.0.0.Alpha15.jar:1.0.0.Alpha15]
> at io.undertow.servlet.spec.RequestDispatcherImpl.error(RequestDispatcherImpl.java:367) [undertow-servlet-1.0.0.Alpha15.jar:1.0.0.Alpha15]
> at io.undertow.servlet.spec.RequestDispatcherImpl.error(RequestDispatcherImpl.java:286) [undertow-servlet-1.0.0.Alpha15.jar:1.0.0.Alpha15]
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:124) [undertow-servlet-1.0.0.Alpha15.jar:1.0.0.Alpha15]
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:106) [undertow-servlet-1.0.0.Alpha15.jar:1.0.0.Alpha15]
> at io.undertow.servlet.handlers.ServletInitialHandler.handleRequest(ServletInitialHandler.java:83) [undertow-servlet-1.0.0.Alpha15.jar:1.0.0.Alpha15]
> at io.undertow.server.HttpHandlers.executeRootHandler(HttpHandlers.java:52) [undertow-core-1.0.0.Alpha15.jar:1.0.0.Alpha15]
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:544) [undertow-core-1.0.0.Alpha15.jar:1.0.0.Alpha15]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_21]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_21]
> at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_21]
--
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
12 years, 3 months
[JBoss JIRA] (DROOLS-410) Drools invokes superclass static method
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/DROOLS-410?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration commented on DROOLS-410:
------------------------------------------------
Mario Fusco <mfusco(a)redhat.com> changed the Status of [bug 1057550|https://bugzilla.redhat.com/show_bug.cgi?id=1057550] from ASSIGNED to MODIFIED
> Drools invokes superclass static method
> ---------------------------------------
>
> Key: DROOLS-410
> URL: https://issues.jboss.org/browse/DROOLS-410
> Project: Drools
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Reporter: Michaël Mathieu
> Assignee: Mario Fusco
> Fix For: 6.1.0.Beta1
>
>
> For a very simple rule, with same parameter, the result is sometimes different.
> Drools invokes superclass static method.
> {code}
> package test;
> public class ARef {
> private String ref;
> protected ARef(String ref) {
> this.ref = ref;
> }
> public static ARef valueOf(String ref) {
> System.out.println("ARef> " + ref);
> return new ARef(ref);
> }
> @Override
> public String toString() {
> return ref;
> }
> @Override
> public int hashCode() {
> final int prime = 31;
> int result = 1;
> result = prime * result + ((ref == null) ? 0 : ref.hashCode());
> return result;
> }
> @Override
> public boolean equals(Object obj) {
> if (this == obj) return true;
> if (obj == null) return false;
> if (getClass() != obj.getClass()) return false;
> ARef other = (ARef) obj;
> if (ref == null) {
> if (other.ref != null) return false;
> } else if (!ref.equals(other.ref)) return false;
> return true;
> }
> }
> {code}
> {code}
> package test;
> public class BRef extends ARef {
> private BRef(String ref) {
> super(ref);
> }
> public static BRef valueOf(String ref) {
> System.out.println("BRef> " + ref);
> return new BRef(ref);
> }
> }
> {code}
> {code}
> package test;
> public class Criteria {
> private BRef ref;
> private boolean ok = false;
> public Criteria(BRef ref) {
> this.ref = ref;
> }
> public BRef getRef() {
> return ref;
> }
> public boolean isOk() {
> return ok;
> }
> public void setOk() {
> this.ok = true;
> }
> }
> {code}
> {code}
> package test;
> import java.io.StringReader;
> import org.drools.RuleBase;
> import org.drools.RuleBaseFactory;
> import org.drools.StatelessSession;
> import org.drools.compiler.PackageBuilder;
> import org.drools.rule.Package;
> public class Test {
> private static final String DRL = "package test\r\n" + "dialect \"mvel\"\r\n" + "import test.*;\r\n" + "rule \"myRule\"\r\n" + "when\r\n"
> + " criteria:Criteria(ref == BRef.valueOf(\"toto\"))\r\n" + "then\r\n" + " criteria.setOk();\r\n" + "end";
> public static void main(String[] args) {
> System.out.println(DRL);
> try {
> PackageBuilder builder = new PackageBuilder();
> builder.addPackageFromDrl(new StringReader(DRL));
> Package pkg = builder.getPackage();
> RuleBase ruleBase = RuleBaseFactory.newRuleBase();
> ruleBase.addPackage(pkg);
> for (int i = 0; i < 1000; i++) {
> Criteria criteria = new Criteria(BRef.valueOf("toto"));
> StatelessSession session = ruleBase.newStatelessSession();
> session.execute(criteria);
> System.out.println("[" + i + "] " + criteria.isOk());
> }
> } catch (Exception e) {
> e.printStackTrace();
> }
> }
> }
> {code}
> Output:
> {code}
> package test
> dialect "mvel"
> import test.*;
> rule "myRule"
> when
> criteria:Criteria(ref == BRef.valueOf("toto"))
> then
> criteria.setOk();
> end
> BRef> toto
> BRef> toto
> BRef> toto
> [0] true
> BRef> toto
> BRef> toto
> [1] true
> BRef> toto
> BRef> toto
> [2] true
> ...
> BRef> toto
> ARef> toto
> [109] false
> BRef> toto
> ARef> toto
> [110] false
> ...
> BRef> toto
> ARef> toto
> [998] false
> BRef> toto
> ARef> toto
> [999] false
> {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
12 years, 3 months
[JBoss JIRA] (JBLOGGING-95) Add Logger/LoggerProvider to support new Log4j 2 to improve performance
by Nicholas Williams (JIRA)
[ https://issues.jboss.org/browse/JBLOGGING-95?page=com.atlassian.jira.plug... ]
Nicholas Williams edited comment on JBLOGGING-95 at 2/2/14 2:46 PM:
--------------------------------------------------------------------
Huh. I didn't even notice that this had been merged and close. Guess I didn't get the email update or something. Thanks!
Since this didn't get backported and included in 3.1.4.GA (sad face), when do we expect 3.2.0 to come out? Log4j 2 is going GA in the next couple of weeks, my book goes to the printers next week, and I'd really like this to all line up. I'd at least like to get 3.2.0.Beta1 rolling in the next week or two. There haven't been many changes at all to this version. :-)
Is there anything I can do to help move things along?
was (Author: beamerblvd):
Huh. I didn't even notice that this had been merged and close. Guess I didn't get the email update or something. Thanks!
Since this didn't get backported and included in 3.1.4.GA (sad face), when do we expect 3.2.0 to come out? Log4j 2 is going GA in the next couple of weeks, my book goes to the printers next week, and I'd really like this to all line up. :-)
Is there anything I can do to help move things along?
> Add Logger/LoggerProvider to support new Log4j 2 to improve performance
> -----------------------------------------------------------------------
>
> Key: JBLOGGING-95
> URL: https://issues.jboss.org/browse/JBLOGGING-95
> Project: JBoss Logging
> Issue Type: Enhancement
> Security Level: Public(Everyone can see)
> Components: jboss-logging-spi
> Affects Versions: 3.2.0.Beta1
> Reporter: Nicholas Williams
> Assignee: David Lloyd
> Priority: Minor
> Fix For: 3.2.0.Beta1
>
> Original Estimate: 1 day
> Remaining Estimate: 1 day
>
> The new Log4j 2 project will be released soon. It has major improvements over Log4j and Logback. Currently, JBoss Logging can log to Log4j 2 indirectly by way of SLF4J (if the log4j-slf4j artifact is on the classpath) or the Log4j 1.2 API (if the log4j-1.2-api artifact is on the classpath and when JBLOGGING-94 is fixed). However, performance would be improved if JBoss Logging could log directly to the Log4j 2 API.
> Looks like we just need a new {{Log4j2Logger}} and {{Log4j2LoggerProvider}}. I'll try to submit a pull request in the next few weeks. I'm currently working on other tasks in Log4j 2.
--
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
12 years, 3 months
[JBoss JIRA] (JBLOGGING-95) Add Logger/LoggerProvider to support new Log4j 2 to improve performance
by Nicholas Williams (JIRA)
[ https://issues.jboss.org/browse/JBLOGGING-95?page=com.atlassian.jira.plug... ]
Nicholas Williams commented on JBLOGGING-95:
--------------------------------------------
Huh. I didn't even notice that this had been merged and close. Guess I didn't get the email update or something. Thanks!
Since this didn't get backported and included in 3.1.4.GA (sad face), when do we expect 3.2.0 to come out? Log4j 2 is going GA in the next couple of weeks, my book goes to the printers next week, and I'd really like this to all line up. :-)
Is there anything I can do to help move things along?
> Add Logger/LoggerProvider to support new Log4j 2 to improve performance
> -----------------------------------------------------------------------
>
> Key: JBLOGGING-95
> URL: https://issues.jboss.org/browse/JBLOGGING-95
> Project: JBoss Logging
> Issue Type: Enhancement
> Security Level: Public(Everyone can see)
> Components: jboss-logging-spi
> Affects Versions: 3.2.0.Beta1
> Reporter: Nicholas Williams
> Assignee: David Lloyd
> Priority: Minor
> Fix For: 3.2.0.Beta1
>
> Original Estimate: 1 day
> Remaining Estimate: 1 day
>
> The new Log4j 2 project will be released soon. It has major improvements over Log4j and Logback. Currently, JBoss Logging can log to Log4j 2 indirectly by way of SLF4J (if the log4j-slf4j artifact is on the classpath) or the Log4j 1.2 API (if the log4j-1.2-api artifact is on the classpath and when JBLOGGING-94 is fixed). However, performance would be improved if JBoss Logging could log directly to the Log4j 2 API.
> Looks like we just need a new {{Log4j2Logger}} and {{Log4j2LoggerProvider}}. I'll try to submit a pull request in the next few weeks. I'm currently working on other tasks in Log4j 2.
--
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
12 years, 3 months
[JBoss JIRA] (JGRP-1789) Fix host binding of tests involving GossipRouter
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1789?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-1789:
---------------------------
Fix Version/s: 3.5
> Fix host binding of tests involving GossipRouter
> ------------------------------------------------
>
> Key: JGRP-1789
> URL: https://issues.jboss.org/browse/JGRP-1789
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.2.13
> Environment: Windows
> Reporter: Richard Achmatowicz
> Assignee: Bela Ban
> Fix For: 3.2.13, 3.5
>
>
> Tests like TUNNEL_Test, TUNNELDeadlockTest, and GossipRouterTest make use of the following:
> - a GosspiRouter which binds to a certain host address and port
> - a GossipRouter client whose TUNNEL protocol binds to a certain host address and port
> - a property gossip_router_hosts which specifies the gossip router hosts the client can connect to
> If these bind addresses are not specified, we often get test failures involving an inability of the client to communicate with the GossipRouter, due to each not having the other's correct address, or one being on local host and the other on a non-localhost interface:
> {noformat}
> ------------- startRouter -----------
> -- starting GossipRouter on 127.0.0.1[23003]
> ------------- testConnectThree -----------
> -------------------------------------------------------------------
> GMS: address=B, cluster=TUNNEL_Test, physical address=192.168.5.141:61373
> -------------------------------------------------------------------
> 605382 [WARN] TUNNEL: - Failed connecting to GossipRouter at /127.0.0.1:23003
> 605383 [WARN] TUNNEL: - failed reconnecting stub to GR at /127.0.0.1:23003: java.lang.Exception: Could not connect to /127.0.0.1:23003
> 605383 [ERROR] TUNNEL: - failed sending message to cluster (94 bytes): java.lang.Exception: None of the available stubs [RouterStub[localsocket=/192.168.5.141:51802,router_host=127.0.0.1::23003,connected=false]] accepted a multicast message, cause: null
> {noformat}
> TUNNEL_Test and GossipRouterTest are failing on Windows, for example, due to this sort of issue.
>
--
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
12 years, 3 months
[JBoss JIRA] (JGRP-1786) 3.5
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1786?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-1786:
---------------------------
Summary: 3.5 (was: TimeSchedulerTest.test2Tasks fails repeatably with DefaultTimeScheduler)
Fix Version/s: 3.5
Hi Richard,
good analysis, I'm trying to resolve this in 3.5 and backport if needed. Note though that DefaultScheduler (despite its name) is not used anymore...
> 3.5
> ---
>
> Key: JGRP-1786
> URL: https://issues.jboss.org/browse/JGRP-1786
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.2.13
> Environment: RHEL 5 x86_64
> Windows x86_64
> Reporter: Richard Achmatowicz
> Assignee: Bela Ban
> Fix For: 3.5
>
>
> The test case starts off by scheduling a timer task using the DefaultTimeScheduler and then sleeping, waiting for the task to execute
> Instead of the task being executed, the call to sleep is interrupted and the test case fails with an interrupted exception. Catching this interrupted exception shows that the task has not had a chance to execute before the sleep was interrupted.
> The same test case passes with the other two TimeScheduler implementations: TimeScheduler2 and HashedTimingWheel.
>
--
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
12 years, 3 months
[JBoss JIRA] (AS7-5088) Weblogic EJB Lookup fails from JBoss AS
by living lazer (JIRA)
[ https://issues.jboss.org/browse/AS7-5088?page=com.atlassian.jira.plugin.s... ]
living lazer commented on AS7-5088:
-----------------------------------
Was this moved to a forum? I am facing the same issue, no idea and already spent 24hours...
> Weblogic EJB Lookup fails from JBoss AS
> ----------------------------------------
>
> Key: AS7-5088
> URL: https://issues.jboss.org/browse/AS7-5088
> Project: Application Server 7
> Issue Type: Bug
> Environment: JBoss AS 7.1.0.Final
> EJB Deployed in Weblogic 10
> OS - Windows XP
> JDK - jdk160_05 (Used by jboss)
> Reporter: Badal Pradhan
>
> I am trying to access EJB deployed in Weblogic 10 by its RemoteInterface from JBoss.
> My initial context config for lookup is as below:
> Hashtable<String,String> wlContextEnv = new Hashtable<String,String>();
> wlContextEnv.put(Context.INITIAL_CONTEXT_FACTORY, "weblogic.jndi.WLInitialContextFactory");
> wlContextEnv.put(Context.PROVIDER_URL, "t3://localhost:7001");
> wlInitialContext = new InitialContext(wlContextEnv);
> During access the bean it throws the below exception:
> java.lang.LinkageError: Failed to link weblogic/corba/client/cluster/ORBSocketFactory
> .....
> Caused by: java.lang.ClassNotFoundException: com.sun.corba.se.spi.legacy.connection.ORBSocketFactory
> Since the above class belongs to jdk rt.jar then what is the issue here? Am I missed any config for it.
> Note: I have wlclient.jar in my ear/lib.
--
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
12 years, 3 months
[JBoss JIRA] (DROOLS-319) "Unknown boolean operator" RuntimeException
by David Tombs (JIRA)
[ https://issues.jboss.org/browse/DROOLS-319?page=com.atlassian.jira.plugin... ]
David Tombs commented on DROOLS-319:
------------------------------------
Hi Michael, I don't remember exactly how I did it but somewhere on the stacktrace from the exception I saw which constraint it was evaluating. Hope that helps.
> "Unknown boolean operator" RuntimeException
> -------------------------------------------
>
> Key: DROOLS-319
> URL: https://issues.jboss.org/browse/DROOLS-319
> Project: Drools
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 5.5.0.Final
> Environment: Windows 8, java version "1.7.0_40"
> Reporter: David Tombs
> Assignee: Mark Proctor
>
> Steps to reproduce:
> # Create a decision table with something like {{fooString != ""}} in the constraint and {{true}} in the rule cell.
> # Execute the rule against a few objects.
> Actual Result:
> An internal Drools thread will crash with {{java.lang.RuntimeException: Unknown boolean operator}} when trying to compile {{fooString != "" == true}}.
> {noformat}
> Exception in thread "Thread-15" java.lang.RuntimeException: Unknown boolean operator
> at org.drools.rule.constraint.ConditionAnalyzer$AritmeticOperator.fromMvelOpCode(ConditionAnalyzer.java:1059)
> at org.drools.rule.constraint.ConditionAnalyzer.analyzeNode(ConditionAnalyzer.java:169)
> at org.drools.rule.constraint.ConditionAnalyzer.analyzeSingleCondition(ConditionAnalyzer.java:106)
> at org.drools.rule.constraint.ConditionAnalyzer.analyzeCondition(ConditionAnalyzer.java:99)
> at org.drools.rule.constraint.ConditionAnalyzer.analyzeCondition(ConditionAnalyzer.java:70)
> at org.drools.rule.constraint.MvelConditionEvaluator.getAnalyzedCondition(MvelConditionEvaluator.java:83)
> at org.drools.rule.constraint.MvelConstraint.executeJitting(MvelConstraint.java:270)
> at org.drools.rule.constraint.MvelConstraint.access$200(MvelConstraint.java:51)
> at org.drools.rule.constraint.MvelConstraint$ConditionJitter.run(MvelConstraint.java:250)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:724)
> {noformat}
> Expected Result:
> Even if an Exception is thrown, the currently-thrown exception is too low level and took me lots of investigation and debugging inside the drools code to figure out what I did wrong.
--
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
12 years, 3 months