[JBoss JIRA] (DROOLS-725) ClassCastException on malformed accumulate
by Mario Fusco (JIRA)
[ https://issues.jboss.org/browse/DROOLS-725?page=com.atlassian.jira.plugin... ]
Mario Fusco resolved DROOLS-725.
--------------------------------
Resolution: Done
Fixed by https://github.com/droolsjbpm/drools/commit/6662376730f48cd0d181e9cc7daf9...
> ClassCastException on malformed accumulate
> ------------------------------------------
>
> Key: DROOLS-725
> URL: https://issues.jboss.org/browse/DROOLS-725
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 6.1.0.Final, 6.2.0.CR4
> Environment: java version "1.7.0_60"
> Java(TM) SE Runtime Environment (build 1.7.0_60-b19)
> Java HotSpot(TM) 64-Bit Server VM (build 24.60-b09, mixed mode)
> Reporter: Davide Angelocola
> Assignee: Mario Fusco
> Priority: Minor
>
> Given a rule like:
> rule "test case"
> when
> Number() from accumulate(
> not Number(),
> init( double total = 0; ),
> action( ),
> reverse( ),
> result( new Double( total ) )
> )
> then
> // no op
> end
> the following exception is thrown:
> java.lang.ClassCastException: org.drools.compiler.lang.descr.NotDescr cannot be cast to org.drools.compiler.lang.descr.PatternDescr
> at org.drools.compiler.lang.descr.AccumulateDescr.getInputPattern(AccumulateDescr.java:194)
> at org.drools.compiler.rule.builder.util.PackageBuilderUtil.isReadLocalsFromTuple(PackageBuilderUtil.java:21)
> at org.drools.compiler.rule.builder.dialect.java.JavaAccumulateBuilder.build(JavaAccumulateBuilder.java:93)
> at org.drools.compiler.rule.builder.dialect.java.JavaAccumulateBuilder.build(JavaAccumulateBuilder.java:66)
> at org.drools.compiler.rule.builder.PatternBuilder.build(PatternBuilder.java:320)
> at org.drools.compiler.rule.builder.PatternBuilder.build(PatternBuilder.java:138)
> at org.drools.compiler.rule.builder.GroupElementBuilder.build(GroupElementBuilder.java:66)
> at org.drools.compiler.rule.builder.RuleBuilder.build(RuleBuilder.java:89)
> at org.drools.compiler.builder.impl.KnowledgeBuilderImpl.addRule(KnowledgeBuilderImpl.java:1652)
> at org.drools.compiler.builder.impl.KnowledgeBuilderImpl.compileRules(KnowledgeBuilderImpl.java:968)
> at org.drools.compiler.builder.impl.KnowledgeBuilderImpl.compileAllRules(KnowledgeBuilderImpl.java:844)
> at org.drools.compiler.builder.impl.CompositeKnowledgeBuilderImpl.buildRules(CompositeKnowledgeBuilderImpl.java:279)
> at org.drools.compiler.builder.impl.CompositeKnowledgeBuilderImpl.buildPackages(CompositeKnowledgeBuilderImpl.java:103)
> at org.drools.compiler.builder.impl.CompositeKnowledgeBuilderImpl.build(CompositeKnowledgeBuilderImpl.java:91)
> at org.drools.compiler.kie.builder.impl.AbstractKieModule.buildKnowledgePackages(AbstractKieModule.java:220)
> at org.drools.compiler.kie.builder.impl.AbstractKieProject.verify(AbstractKieProject.java:43)
> at org.drools.compiler.kie.builder.impl.KieBuilderImpl.buildKieProject(KieBuilderImpl.java:208)
> at org.drools.compiler.kie.builder.impl.KieBuilderImpl.buildAll(KieBuilderImpl.java:177)
> at regressions.DroolsCompilerBugTest.bug(DroolsCompilerBugTest.java:26)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
> at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
> at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
> at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:50)
> at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:459)
> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:675)
> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:382)
> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:192)
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 2 months
[JBoss JIRA] (WFLY-706) Change the default object store of JBoss transactions to use the hornetq object store
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/WFLY-706?page=com.atlassian.jira.plugin.s... ]
Tom Jenkinson closed WFLY-706.
------------------------------
Fix Version/s: (was: Awaiting Volunteers)
Resolution: Deferred
As per the limitation I think it does not make sense to pursue this as the default. In the future we may need to consider running the recovery manager out of process and so making this change could need a revert in the future. The journal store has performance benefits that can be enabled by config.
> Change the default object store of JBoss transactions to use the hornetq object store
> -------------------------------------------------------------------------------------
>
> Key: WFLY-706
> URL: https://issues.jboss.org/browse/WFLY-706
> Project: WildFly
> Issue Type: Feature Request
> Components: Transactions
> Reporter: Tom Jenkinson
>
> This would provide a performance boost, however it is not supportable until AS7-925 is complete as the object store cannot be manipulated on the filesystem to resolve heuristics, tooling is necessary.
> PS Do not implement this feature without tooling or discussing with me, I will add this after tooling is added.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 2 months
[JBoss JIRA] (WFLY-4383) Wrong order of elements in appclient.xml
by Panagiotis Sotiropoulos (JIRA)
[ https://issues.jboss.org/browse/WFLY-4383?page=com.atlassian.jira.plugin.... ]
Panagiotis Sotiropoulos commented on WFLY-4383:
-----------------------------------------------
This issue is related to https://bugzilla.redhat.com/show_bug.cgi?id=1195138
> Wrong order of elements in appclient.xml
> ------------------------------------------
>
> Key: WFLY-4383
> URL: https://issues.jboss.org/browse/WFLY-4383
> Project: WildFly
> Issue Type: Bug
> Components: Application Client
> Affects Versions: 9.0.0.Alpha1
> Reporter: Panagiotis Sotiropoulos
> Assignee: Panagiotis Sotiropoulos
>
> Description of problem:
> File appclient/configuration/appclient.xml has an incorrect order of elements. <core-environment> tag should be before <recovery-environment /> tag. These tags is in <subsystem xmlns="urn:jboss:domain:transactions:1.4"> and schema is in docs/schema/jboss-as-txn_1_4.xsd. This schema defines specific order of elements.
> Version-Release number of selected component (if applicable):
> 6.4.0.ER2
> Validate logs:
> appclient/configuration/appclient.xml:150: element recovery-environment: Schemas validity error : Element '{urn:jboss:domain:transactions:1.4}recovery-environment': This element is not expected. Expected is ( {urn:jboss:domain:transactions:1.4}core-environment ).
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 2 months
[JBoss JIRA] (WFCORE-564) setXmlWrapperElement() doesn't work properly with multiple resource children
by Tomaz Cerar (JIRA)
Tomaz Cerar created WFCORE-564:
----------------------------------
Summary: setXmlWrapperElement() doesn't work properly with multiple resource children
Key: WFCORE-564
URL: https://issues.jboss.org/browse/WFCORE-564
Project: WildFly Core
Issue Type: Bug
Components: XML Frameworks
Affects Versions: 1.0.0.Alpha19
Reporter: Tomaz Cerar
Assignee: Tomaz Cerar
{noformat}Jeff Mesnil 12:13 @ctomc hi tomaz. The setXmlWrapperElement() method in persistent xml builder API is supposed to add a XML wrapper around all the resource's XML elements, right? and not around each resource element.
ie it looks like <wrapper><res /><res /></wrapper> and not <wrapper><res /></wrapper><wrapper><res /></wrapper>
Tomaz Cerar 12:17 hmm, you are right also around resources
it would be <wrapper> <res /> <res/> </wrapper>
just remembered i had that in 1.0 xsd of undertow subsystem
Jeff Mesnil 12:20 yes, I want to wrap some resources (eg queue) in a wrapper (<queues>). But the persistent XM parser is broken (it wants one wrapper around each resource)
the XML persister is working as expected though
Tomaz Cerar @jmesnil you are right it is broken, i can reproduce it also on undertow-1.0.xml test case
i just had one resource under it so it passed{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 2 months
[JBoss JIRA] (WFLY-4383) Wrong order of elements in appclient.xml
by Panagiotis Sotiropoulos (JIRA)
Panagiotis Sotiropoulos created WFLY-4383:
---------------------------------------------
Summary: Wrong order of elements in appclient.xml
Key: WFLY-4383
URL: https://issues.jboss.org/browse/WFLY-4383
Project: WildFly
Issue Type: Bug
Components: Application Client
Affects Versions: 9.0.0.Alpha1
Reporter: Panagiotis Sotiropoulos
Assignee: Panagiotis Sotiropoulos
Description of problem:
File appclient/configuration/appclient.xml has an incorrect order of elements. <core-environment> tag should be before <recovery-environment /> tag. These tags is in <subsystem xmlns="urn:jboss:domain:transactions:1.4"> and schema is in docs/schema/jboss-as-txn_1_4.xsd. This schema defines specific order of elements.
Version-Release number of selected component (if applicable):
6.4.0.ER2
Validate logs:
appclient/configuration/appclient.xml:150: element recovery-environment: Schemas validity error : Element '{urn:jboss:domain:transactions:1.4}recovery-environment': This element is not expected. Expected is ( {urn:jboss:domain:transactions:1.4}core-environment ).
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 2 months
[JBoss JIRA] (WFLY-706) Change the default object store of JBoss transactions to use the hornetq object store
by Michael Musgrove (JIRA)
[ https://issues.jboss.org/browse/WFLY-706?page=com.atlassian.jira.plugin.s... ]
Michael Musgrove commented on WFLY-706:
---------------------------------------
A limitation of this store is that it cannot be shared, so, for example, we could not run the recovery manager in a separate JVM.
> Change the default object store of JBoss transactions to use the hornetq object store
> -------------------------------------------------------------------------------------
>
> Key: WFLY-706
> URL: https://issues.jboss.org/browse/WFLY-706
> Project: WildFly
> Issue Type: Feature Request
> Components: Transactions
> Reporter: Tom Jenkinson
> Fix For: Awaiting Volunteers
>
>
> This would provide a performance boost, however it is not supportable until AS7-925 is complete as the object store cannot be manipulated on the filesystem to resolve heuristics, tooling is necessary.
> PS Do not implement this feature without tooling or discussing with me, I will add this after tooling is added.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 2 months
[JBoss JIRA] (WFCORE-563) Upgrade to Xerces 2.11.0.SP1
by Carlo de Wolf (JIRA)
[ https://issues.jboss.org/browse/WFCORE-563?page=com.atlassian.jira.plugin... ]
Carlo de Wolf updated WFCORE-563:
---------------------------------
Summary: Upgrade to Xerces 2.11.0.SP1 (was: Upgrade to Xerces 2.11.0)
> Upgrade to Xerces 2.11.0.SP1
> ----------------------------
>
> Key: WFCORE-563
> URL: https://issues.jboss.org/browse/WFCORE-563
> Project: WildFly Core
> Issue Type: Component Upgrade
> Affects Versions: 1.0.0.Alpha19
> Environment: WildFly 8.1.0.Final, JDK 7, Ubuntu, Windows, Mac OS
> Reporter: Carlos Barragan
> Assignee: Carlo de Wolf
> Priority: Critical
> Attachments: stacktrace.txt
>
>
> Xerces 2.9.1 has a bug when parsing Times with "24" hrs.
> {code}
> DatatypeFactory.newInstance().newXMLGregorianCalendar("24:00:00Z");
> {code}
> We have this problem in one of our web services because we get request with the above time format.
> Xerces 2.11.0 does not contain that bug.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 2 months
[JBoss JIRA] (DROOLS-724) Preemptive authentication in KIE Scanner
by Mario Fusco (JIRA)
[ https://issues.jboss.org/browse/DROOLS-724?page=com.atlassian.jira.plugin... ]
Mario Fusco resolved DROOLS-724.
--------------------------------
Resolution: Won't Fix
What you're asking makes sense but the current Wagon API doesn't allow me to fix this issue.
The problem here is that you could have multiple servers in your settings.xml file and only one (or anyway a subset of them) could have been configured with the usePreemptive flag. Conversely the WagonProvider interface allow me to create one single Wagon to be used for all the http(s) requests. In other words there's no way to have different Wagons configured for the different servers you may have in your settings.xml file so I am obliged to use a minimal Wagon configuration.
> Preemptive authentication in KIE Scanner
> ----------------------------------------
>
> Key: DROOLS-724
> URL: https://issues.jboss.org/browse/DROOLS-724
> Project: Drools
> Issue Type: Bug
> Components: kie server
> Affects Versions: 6.1.0.Final
> Reporter: Rares Vernica
> Assignee: Mario Fusco
>
> The pre-emptive authentication setting from Maven's settings.xml is not picked up by Drools:
> <server>
> <id>guvnor-m2-repo</id>
> <username>...</username>
> <password>...</password>
> <configuration>
> <httpConfiguration>
> <usePreemptive>true</usePreemptive>
> </httpConfiguration>
> </configuration>
> </server>
> I am not sure if the bug is in Drools or Wagon. To fix it, I made the pre-emptive always true, but adding:
> ...
> if ( "http".equals( roleHint ) || "https".equals( roleHint ) ) {
> HttpMethodConfiguration httpMethodConfiguration = new HttpMethodConfiguration();
> httpMethodConfiguration.setUsePreemptive( true );
> HttpConfiguration httpConfiguration = new HttpConfiguration();
> httpConfiguration.setAll( httpMethodConfiguration );
>
> HttpWagon httpWagon = new HttpWagon();
> httpWagon.setHttpConfiguration( httpConfiguration );
>
> return httpWagon;
> }
> ...
> in Aether$ManualWagonProvider. This obviously is not a good solution.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 2 months