[JBoss JIRA] (WFLY-3668) Change startup script to read new logger code in 9.x
by Jorge Solorzano (JIRA)
[ https://issues.jboss.org/browse/WFLY-3668?page=com.atlassian.jira.plugin.... ]
Jorge Solorzano updated WFLY-3668:
----------------------------------
Remaining Estimate: 0 minutes (was: 50 minutes)
> Change startup script to read new logger code in 9.x
> ----------------------------------------------------
>
> Key: WFLY-3668
> URL: https://issues.jboss.org/browse/WFLY-3668
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Scripts
> Affects Versions: 9.0.0.Beta1
> Environment: Linux
> Reporter: Jorge Solorzano
> Assignee: Tomaz Cerar
> Priority: Minor
> Fix For: 9.0.0.Beta1
>
> Original Estimate: 1 hour
> Time Spent: 10 minutes
> Remaining Estimate: 0 minutes
>
> The refactor of the wildfly-core includes changes in logger codes that affects the startup script to verify if the server is started.
> The code JBAS015874 changed to WFLYSRV0025.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 11 months
[JBoss JIRA] (WFLY-3668) Change startup script to read new logger code in 9.x
by Jorge Solorzano (JIRA)
Jorge Solorzano created WFLY-3668:
-------------------------------------
Summary: Change startup script to read new logger code in 9.x
Key: WFLY-3668
URL: https://issues.jboss.org/browse/WFLY-3668
Project: WildFly
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Scripts
Affects Versions: 9.0.0.Beta1
Environment: Linux
Reporter: Jorge Solorzano
Assignee: Tomaz Cerar
Priority: Minor
Fix For: 9.0.0.Beta1
The refactor of the wildfly-core includes changes in logger codes that affects the startup script to verify if the server is started.
The code JBAS015874 changed to WFLYSRV0025.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 11 months
[JBoss JIRA] (DROOLS-495) kie maven plugin, packaging kjar, test resources file not resolved
by Matteo Mortari (JIRA)
[ https://issues.jboss.org/browse/DROOLS-495?page=com.atlassian.jira.plugin... ]
Matteo Mortari commented on DROOLS-495:
---------------------------------------
Thank you Petr, for the fix on master and the workaround, works for me.
Ciao,
Matteo
> kie maven plugin, packaging kjar, test resources file not resolved
> ------------------------------------------------------------------
>
> Key: DROOLS-495
> URL: https://issues.jboss.org/browse/DROOLS-495
> Project: Drools
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 6.1.0.Beta3, 6.1.0.CR2
> Reporter: Matteo Mortari
> Assignee: Petr Široký
> Fix For: 6.1.0.Final
>
> Attachments: 20140521.drools6test.testresources.zip
>
>
> I understand the idiomatic way for a drools Kie rule Maven project to be built, as shown in the [example|https://github.com/droolsjbpm/drools/blob/master/kie-maven-plugin...], is to include in the pom:
> * Kie Maven plugin
> * set packaging to {{kjar}}
> However, normally the file resources available under
> {noformat}
> src/
> test/
> resources/
> aresource.txt
> {noformat}
> should be available while running {{mvn test}}
> However I noticed if packaging is set to {{kjar}}, this fails. It is working as expected if instead the packaging is set to the standard {{jar}}
> Consider the following attached example project to replicate the issue. It contains the 'aresource.txt' file in the standard Maven layout directory {{src/test/resources}} as shown above. However the following simple test fails:
> {code:title=AppTest.java|borderStyle=solid}
> @Test
> public void testFindTheFile() {
> URL resource = getClass().getResource("/aresource.txt");
> assertNotNull(resource);
> }
> {code}
> Setting instead the project packaging to the standard {{jar}} instead, pass the test, and in fact it can be noticed the 'aresource.txt' file is available under {{target/test-classes}} directory.
> Extract of the pom failing the test due to packaging set to {{kjar}}
> {code:xml|title=pom.xml}
> <project ...>
> <modelVersion>4.0.0</modelVersion>
> <groupId>com.acme</groupId>
> <artifactId>drools6test.testresources</artifactId>
> <version>0.0.1-SNAPSHOT</version>
>
> <packaging>kjar</packaging>
>
> <!-- ... -->
>
> <dependencyManagement>
> <dependencies>
> <dependency>
> <groupId>org.drools</groupId>
> <artifactId>drools-bom</artifactId>
> <type>pom</type>
> <version>6.1.0.Beta3</version>
> <scope>import</scope>
> </dependency>
> </dependencies>
> </dependencyManagement>
>
> <!-- ... -->
> <build>
> <finalName>drools6test.testresources</finalName>
> <plugins>
> <plugin>
> <groupId>org.kie</groupId>
> <artifactId>kie-maven-plugin</artifactId>
> <version>6.1.0.Beta3</version>
> <extensions>true</extensions>
> </plugin>
> </plugins>
> </project>
> {code}
> Thank you in advance for your feedback accordingly;
> Ciao
> Matteo
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 11 months
[JBoss JIRA] (JGRP-1863) Excessive dropped messages due to missing physical address
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1863?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-1863:
--------------------------------
Do you think you'll use {{RELAY2}} on top of {{FORK}} in WF 9 ? If so, this combo needs to be tested
> Excessive dropped messages due to missing physical address
> ----------------------------------------------------------
>
> Key: JGRP-1863
> URL: https://issues.jboss.org/browse/JGRP-1863
> Project: JGroups
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 3.5
> Reporter: Paul Ferraro
> Assignee: Bela Ban
> Priority: Blocker
> Fix For: 3.5
>
>
> When running the x-site replication tests (and only those tests - the others run fine) from the clustering testsuite in WildFly against JGroups 3.5, I encounter failures due to:
> {noformat}
> 12:15:48,537 WARN [org.infinispan.xsite.BackupSenderImpl] (default task-1) ISPN000202: Problems backing up data for cache dist to site SFO: org.infinispan.util.concurrent.TimeoutException: Timed out after 10 seconds waiting for a response from SFO (sync, timeout=10000)
> {noformat}
> The logs preceding this indicate the cause of the timeout:
> {noformat}
> 12:15:38,536 WARN [org.jgroups.protocols.UDP] (TransferQueueBundler,shared=udp) JGRP000032: null: no physical address for SiteMaster(NYC), dropping message
> 12:15:38,536 WARN [org.jgroups.protocols.UDP] (TransferQueueBundler,shared=udp) JGRP000032: null: no physical address for SiteMaster(SFO), dropping message
> 12:15:39,506 WARN [org.jgroups.protocols.UDP] (TransferQueueBundler,shared=udp) JGRP000032: null: no physical address for SiteMaster(SFO), dropping message
> 12:15:39,507 WARN [org.jgroups.protocols.UDP] (TransferQueueBundler,shared=udp) JGRP000032: null: no physical address for SiteMaster(NYC), dropping message
> {noformat}
> These messages repeat about 100 or so times over a period of 10 seconds.
> A little investigation reveals that the process for fetching physical addresses for a given logical destination address has changed. In 3.4, a given call to sendToSingleMember(...) would attempt to lookup the physical address by sending a Event.GET_PHYSICAL_ADDRESS up the stack and wait a predetermined period for a response. Any concurrent calls to sendToSingleMember(...) would also wait, but only one thread in a given time period would ever send the Event.GET_PHYSICAL_ADDRESS event up the stack.
> In 3.5 the process is different. In org.jgroups.protocols.TP, the FIND_MBRS event is used to lookup the phsyical addresses, instead of directly sending up a GET_PHYSICAL_ADDRESS event. However, looking at the implementation of the FIND_MBRS event handling within org.jgroups.protocols.Discovery, I see that this triggers a asynchronous GET_MBRS_REQ message. Since this message is sent asynchronously, this means that the response from the original FIND_MBRS event will most certainly be empty. Thus the thread that initiated the FIND_MBRS will most certainly log the PhysicalAddrMissing warning, as will any concurrent/subsequent calls to sendToSingleMember(...) for the same destination until that asynchronous processing completes. This is a departure from the logic in 3.4, where the thread initiating the physical address lookup would wait for some time for the address cache to be updated. I should think that the PhysicalAddrMissing warnings should stop once the original GET_MBRS_REQ message is handled, but that doesn't seem to be happening (hence the 100 or so sequential warning messages over a period of 10 seconds preceding the timeout log message from infinispan).
> Curiously, I see a org.jgroups.protocols.TP.setPingData(...) method, which seems to be responsible for populating the physical address cache from the FIND_MBRS event results from org.jgroups.protocols.Discovery - however, this method doesn't seem to be referenced anywhere. Might that be the source of the problem?
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 11 months
[JBoss JIRA] (JGRP-1863) Excessive dropped messages due to missing physical address
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1863?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-1863:
--------------------------------
OK. No, programmatic configuration didn't change.
I'll remove {TP.setPingData()}} as it's not used anymore.
> Excessive dropped messages due to missing physical address
> ----------------------------------------------------------
>
> Key: JGRP-1863
> URL: https://issues.jboss.org/browse/JGRP-1863
> Project: JGroups
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 3.5
> Reporter: Paul Ferraro
> Assignee: Bela Ban
> Priority: Blocker
> Fix For: 3.5
>
>
> When running the x-site replication tests (and only those tests - the others run fine) from the clustering testsuite in WildFly against JGroups 3.5, I encounter failures due to:
> {noformat}
> 12:15:48,537 WARN [org.infinispan.xsite.BackupSenderImpl] (default task-1) ISPN000202: Problems backing up data for cache dist to site SFO: org.infinispan.util.concurrent.TimeoutException: Timed out after 10 seconds waiting for a response from SFO (sync, timeout=10000)
> {noformat}
> The logs preceding this indicate the cause of the timeout:
> {noformat}
> 12:15:38,536 WARN [org.jgroups.protocols.UDP] (TransferQueueBundler,shared=udp) JGRP000032: null: no physical address for SiteMaster(NYC), dropping message
> 12:15:38,536 WARN [org.jgroups.protocols.UDP] (TransferQueueBundler,shared=udp) JGRP000032: null: no physical address for SiteMaster(SFO), dropping message
> 12:15:39,506 WARN [org.jgroups.protocols.UDP] (TransferQueueBundler,shared=udp) JGRP000032: null: no physical address for SiteMaster(SFO), dropping message
> 12:15:39,507 WARN [org.jgroups.protocols.UDP] (TransferQueueBundler,shared=udp) JGRP000032: null: no physical address for SiteMaster(NYC), dropping message
> {noformat}
> These messages repeat about 100 or so times over a period of 10 seconds.
> A little investigation reveals that the process for fetching physical addresses for a given logical destination address has changed. In 3.4, a given call to sendToSingleMember(...) would attempt to lookup the physical address by sending a Event.GET_PHYSICAL_ADDRESS up the stack and wait a predetermined period for a response. Any concurrent calls to sendToSingleMember(...) would also wait, but only one thread in a given time period would ever send the Event.GET_PHYSICAL_ADDRESS event up the stack.
> In 3.5 the process is different. In org.jgroups.protocols.TP, the FIND_MBRS event is used to lookup the phsyical addresses, instead of directly sending up a GET_PHYSICAL_ADDRESS event. However, looking at the implementation of the FIND_MBRS event handling within org.jgroups.protocols.Discovery, I see that this triggers a asynchronous GET_MBRS_REQ message. Since this message is sent asynchronously, this means that the response from the original FIND_MBRS event will most certainly be empty. Thus the thread that initiated the FIND_MBRS will most certainly log the PhysicalAddrMissing warning, as will any concurrent/subsequent calls to sendToSingleMember(...) for the same destination until that asynchronous processing completes. This is a departure from the logic in 3.4, where the thread initiating the physical address lookup would wait for some time for the address cache to be updated. I should think that the PhysicalAddrMissing warnings should stop once the original GET_MBRS_REQ message is handled, but that doesn't seem to be happening (hence the 100 or so sequential warning messages over a period of 10 seconds preceding the timeout log message from infinispan).
> Curiously, I see a org.jgroups.protocols.TP.setPingData(...) method, which seems to be responsible for populating the physical address cache from the FIND_MBRS event results from org.jgroups.protocols.Discovery - however, this method doesn't seem to be referenced anywhere. Might that be the source of the problem?
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 11 months
[JBoss JIRA] (DROOLS-566) Drools 6.1.CR2 is not compatible with mvel 2.2.1
by Claus Ibsen (JIRA)
[ https://issues.jboss.org/browse/DROOLS-566?page=com.atlassian.jira.plugin... ]
Claus Ibsen updated DROOLS-566:
-------------------------------
Summary: Drools 6.1.CR2 is not compatible with mvel 2.2.1 (was: Drools 6.1.RC2 is not compatible with mvel 2.2.1)
> Drools 6.1.CR2 is not compatible with mvel 2.2.1
> ------------------------------------------------
>
> Key: DROOLS-566
> URL: https://issues.jboss.org/browse/DROOLS-566
> Project: Drools
> Issue Type: Task
> Security Level: Public(Everyone can see)
> Reporter: Claus Ibsen
> Assignee: Mark Proctor
>
> We have a drools 6 example in fabric8 and we got this exception after upgrading mvel from 2.1.9 to 2.2.1
> {code}
> Stacktrace
> org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'ksession-table-1': Cannot resolve reference to bean 'decisionCSV' while setting bean property 'kBase'; nested exception is org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'decisionCSV': Invocation of init method failed; nested exception is java.lang.IncompatibleClassChangeError: Implementing class
> at java.lang.ClassLoader.defineClass1(Native Method)
> at java.lang.ClassLoader.defineClass(ClassLoader.java:800)
> at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
> at java.net.URLClassLoader.defineClass(URLClassLoader.java:449)
> at java.net.URLClassLoader.access$100(URLClassLoader.java:71)
> at java.net.URLClassLoader$1.run(URLClassLoader.java:361)
> at java.net.URLClassLoader$1.run(URLClassLoader.java:355)
> at java.security.AccessController.doPrivileged(Native Method)
> at java.net.URLClassLoader.findClass(URLClassLoader.java:354)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:425)
> at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:358)
> at org.drools.compiler.rule.builder.RuleBuildContext.<init>(RuleBuildContext.java:86)
> at org.drools.compiler.builder.impl.KnowledgeBuilderImpl.buildRuleBuilderContext(KnowledgeBuilderImpl.java:1628)
> at org.drools.compiler.builder.impl.KnowledgeBuilderImpl.preProcessRules(KnowledgeBuilderImpl.java:981)
> at org.drools.compiler.builder.impl.KnowledgeBuilderImpl.compileRules(KnowledgeBuilderImpl.java:962)
> at org.drools.compiler.builder.impl.KnowledgeBuilderImpl.compileAllRules(KnowledgeBuilderImpl.java:842)
> 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:219)
> at org.drools.compiler.kie.builder.impl.KieContainerImpl.createKieBase(KieContainerImpl.java:386)
> at org.drools.compiler.kie.builder.impl.KieContainerImpl.getKieBase(KieContainerImpl.java:346)
> at org.kie.spring.KieObjectsResolver.resolveKBase(KieObjectsResolver.java:51)
> at org.kie.spring.factorybeans.KBaseFactoryBean.afterPropertiesSet(KBaseFactoryBean.java:139)
> at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.invokeInitMethods(AbstractAutowireCapableBeanFactory.java:1571)
> at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1509)
> at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:521)
> at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:458)
> at org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:296)
> at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:223)
> at org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:293)
> at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:194)
> at org.springframework.beans.factory.support.BeanDefinitionValueResolver.resolveReference(BeanDefinitionValueResolver.java:328)
> at org.springframework.beans.factory.support.BeanDefinitionValueResolver.resolveValueIfNecessary(BeanDefinitionValueResolver.java:108)
> at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.applyPropertyValues(AbstractAutowireCapableBeanFactory.java:1417)
> at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.populateBean(AbstractAutowireCapableBeanFactory.java:1158)
> at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:519)
> at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:458)
> at org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:296)
> at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:223)
> at org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:293)
> at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:194)
> at org.springframework.beans.factory.support.DefaultListableBeanFactory.preInstantiateSingletons(DefaultListableBeanFactory.java:615)
> at org.springframework.context.support.AbstractApplicationContext.finishBeanFactoryInitialization(AbstractApplicationContext.java:932)
> at org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:479)
> at org.springframework.context.support.ClassPathXmlApplicationContext.<init>(ClassPathXmlApplicationContext.java:139)
> at org.springframework.context.support.ClassPathXmlApplicationContext.<init>(ClassPathXmlApplicationContext.java:83)
> at io.fabric8.example.drools.KieSpringDecisionTest.setup(KieSpringDecisionTest.java:41)
> {code}
> It works if we keep mvel version at 2.1.9.
> Just wanted the heads-up as other people may hit that issue.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 11 months
[JBoss JIRA] (DROOLS-566) Drools 6.1.CR2 is not compatible with mvel 2.2.1
by Claus Ibsen (JIRA)
[ https://issues.jboss.org/browse/DROOLS-566?page=com.atlassian.jira.plugin... ]
Claus Ibsen commented on DROOLS-566:
------------------------------------
btw the example is here
https://github.com/fabric8io/fabric8/tree/master/quickstarts/karaf/camel-...
> Drools 6.1.CR2 is not compatible with mvel 2.2.1
> ------------------------------------------------
>
> Key: DROOLS-566
> URL: https://issues.jboss.org/browse/DROOLS-566
> Project: Drools
> Issue Type: Task
> Security Level: Public(Everyone can see)
> Reporter: Claus Ibsen
> Assignee: Mark Proctor
>
> We have a drools 6 example in fabric8 and we got this exception after upgrading mvel from 2.1.9 to 2.2.1
> {code}
> Stacktrace
> org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'ksession-table-1': Cannot resolve reference to bean 'decisionCSV' while setting bean property 'kBase'; nested exception is org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'decisionCSV': Invocation of init method failed; nested exception is java.lang.IncompatibleClassChangeError: Implementing class
> at java.lang.ClassLoader.defineClass1(Native Method)
> at java.lang.ClassLoader.defineClass(ClassLoader.java:800)
> at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
> at java.net.URLClassLoader.defineClass(URLClassLoader.java:449)
> at java.net.URLClassLoader.access$100(URLClassLoader.java:71)
> at java.net.URLClassLoader$1.run(URLClassLoader.java:361)
> at java.net.URLClassLoader$1.run(URLClassLoader.java:355)
> at java.security.AccessController.doPrivileged(Native Method)
> at java.net.URLClassLoader.findClass(URLClassLoader.java:354)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:425)
> at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:358)
> at org.drools.compiler.rule.builder.RuleBuildContext.<init>(RuleBuildContext.java:86)
> at org.drools.compiler.builder.impl.KnowledgeBuilderImpl.buildRuleBuilderContext(KnowledgeBuilderImpl.java:1628)
> at org.drools.compiler.builder.impl.KnowledgeBuilderImpl.preProcessRules(KnowledgeBuilderImpl.java:981)
> at org.drools.compiler.builder.impl.KnowledgeBuilderImpl.compileRules(KnowledgeBuilderImpl.java:962)
> at org.drools.compiler.builder.impl.KnowledgeBuilderImpl.compileAllRules(KnowledgeBuilderImpl.java:842)
> 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:219)
> at org.drools.compiler.kie.builder.impl.KieContainerImpl.createKieBase(KieContainerImpl.java:386)
> at org.drools.compiler.kie.builder.impl.KieContainerImpl.getKieBase(KieContainerImpl.java:346)
> at org.kie.spring.KieObjectsResolver.resolveKBase(KieObjectsResolver.java:51)
> at org.kie.spring.factorybeans.KBaseFactoryBean.afterPropertiesSet(KBaseFactoryBean.java:139)
> at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.invokeInitMethods(AbstractAutowireCapableBeanFactory.java:1571)
> at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1509)
> at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:521)
> at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:458)
> at org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:296)
> at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:223)
> at org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:293)
> at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:194)
> at org.springframework.beans.factory.support.BeanDefinitionValueResolver.resolveReference(BeanDefinitionValueResolver.java:328)
> at org.springframework.beans.factory.support.BeanDefinitionValueResolver.resolveValueIfNecessary(BeanDefinitionValueResolver.java:108)
> at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.applyPropertyValues(AbstractAutowireCapableBeanFactory.java:1417)
> at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.populateBean(AbstractAutowireCapableBeanFactory.java:1158)
> at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:519)
> at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:458)
> at org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:296)
> at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:223)
> at org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:293)
> at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:194)
> at org.springframework.beans.factory.support.DefaultListableBeanFactory.preInstantiateSingletons(DefaultListableBeanFactory.java:615)
> at org.springframework.context.support.AbstractApplicationContext.finishBeanFactoryInitialization(AbstractApplicationContext.java:932)
> at org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:479)
> at org.springframework.context.support.ClassPathXmlApplicationContext.<init>(ClassPathXmlApplicationContext.java:139)
> at org.springframework.context.support.ClassPathXmlApplicationContext.<init>(ClassPathXmlApplicationContext.java:83)
> at io.fabric8.example.drools.KieSpringDecisionTest.setup(KieSpringDecisionTest.java:41)
> {code}
> It works if we keep mvel version at 2.1.9.
> Just wanted the heads-up as other people may hit that issue.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 11 months
[JBoss JIRA] (DROOLS-566) Drools 6.1.RC2 is not compatible with mvel 2.2.1
by Claus Ibsen (JIRA)
Claus Ibsen created DROOLS-566:
----------------------------------
Summary: Drools 6.1.RC2 is not compatible with mvel 2.2.1
Key: DROOLS-566
URL: https://issues.jboss.org/browse/DROOLS-566
Project: Drools
Issue Type: Task
Security Level: Public (Everyone can see)
Reporter: Claus Ibsen
Assignee: Mark Proctor
We have a drools 6 example in fabric8 and we got this exception after upgrading mvel from 2.1.9 to 2.2.1
{code}
Stacktrace
org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'ksession-table-1': Cannot resolve reference to bean 'decisionCSV' while setting bean property 'kBase'; nested exception is org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'decisionCSV': Invocation of init method failed; nested exception is java.lang.IncompatibleClassChangeError: Implementing class
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:800)
at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
at java.net.URLClassLoader.defineClass(URLClassLoader.java:449)
at java.net.URLClassLoader.access$100(URLClassLoader.java:71)
at java.net.URLClassLoader$1.run(URLClassLoader.java:361)
at java.net.URLClassLoader$1.run(URLClassLoader.java:355)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:354)
at java.lang.ClassLoader.loadClass(ClassLoader.java:425)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308)
at java.lang.ClassLoader.loadClass(ClassLoader.java:358)
at org.drools.compiler.rule.builder.RuleBuildContext.<init>(RuleBuildContext.java:86)
at org.drools.compiler.builder.impl.KnowledgeBuilderImpl.buildRuleBuilderContext(KnowledgeBuilderImpl.java:1628)
at org.drools.compiler.builder.impl.KnowledgeBuilderImpl.preProcessRules(KnowledgeBuilderImpl.java:981)
at org.drools.compiler.builder.impl.KnowledgeBuilderImpl.compileRules(KnowledgeBuilderImpl.java:962)
at org.drools.compiler.builder.impl.KnowledgeBuilderImpl.compileAllRules(KnowledgeBuilderImpl.java:842)
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:219)
at org.drools.compiler.kie.builder.impl.KieContainerImpl.createKieBase(KieContainerImpl.java:386)
at org.drools.compiler.kie.builder.impl.KieContainerImpl.getKieBase(KieContainerImpl.java:346)
at org.kie.spring.KieObjectsResolver.resolveKBase(KieObjectsResolver.java:51)
at org.kie.spring.factorybeans.KBaseFactoryBean.afterPropertiesSet(KBaseFactoryBean.java:139)
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.invokeInitMethods(AbstractAutowireCapableBeanFactory.java:1571)
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1509)
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:521)
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:458)
at org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:296)
at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:223)
at org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:293)
at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:194)
at org.springframework.beans.factory.support.BeanDefinitionValueResolver.resolveReference(BeanDefinitionValueResolver.java:328)
at org.springframework.beans.factory.support.BeanDefinitionValueResolver.resolveValueIfNecessary(BeanDefinitionValueResolver.java:108)
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.applyPropertyValues(AbstractAutowireCapableBeanFactory.java:1417)
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.populateBean(AbstractAutowireCapableBeanFactory.java:1158)
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:519)
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:458)
at org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:296)
at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:223)
at org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:293)
at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:194)
at org.springframework.beans.factory.support.DefaultListableBeanFactory.preInstantiateSingletons(DefaultListableBeanFactory.java:615)
at org.springframework.context.support.AbstractApplicationContext.finishBeanFactoryInitialization(AbstractApplicationContext.java:932)
at org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:479)
at org.springframework.context.support.ClassPathXmlApplicationContext.<init>(ClassPathXmlApplicationContext.java:139)
at org.springframework.context.support.ClassPathXmlApplicationContext.<init>(ClassPathXmlApplicationContext.java:83)
at io.fabric8.example.drools.KieSpringDecisionTest.setup(KieSpringDecisionTest.java:41)
{code}
It works if we keep mvel version at 2.1.9.
Just wanted the heads-up as other people may hit that issue.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 11 months
[JBoss JIRA] (WFLY-3385) when using jsp:include the jsp:param being encoded at the included jsp
by Zbynek Novak (JIRA)
[ https://issues.jboss.org/browse/WFLY-3385?page=com.atlassian.jira.plugin.... ]
Zbynek Novak commented on WFLY-3385:
------------------------------------
Hi Stuart,
I have found out, that the problem with merging of URL encoded query parameters still exists.
When you forward request processing to path with query parameter, that do not contain special characters only spaces (see bellow), then QueryParametersUtil parseQueryString do not trigger decode of parameter value.
This key remains encoded:
&description=very+long+message
Can you check it?
Thanks
ZZ
> when using jsp:include the jsp:param being encoded at the included jsp
> ----------------------------------------------------------------------
>
> Key: WFLY-3385
> URL: https://issues.jboss.org/browse/WFLY-3385
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Web (Undertow)
> Affects Versions: 8.1.0.CR2
> Reporter: roy mizrachi
> Assignee: Stuart Douglas
> Fix For: 9.0.0.Beta1
>
>
> I have JSP A that includes JSP B like this:
> <jsp:include page="../anotherFolder/B.jsp">
> <jsp:param name="pathToRootContext" value='../' />
> </jsp:include>
> In JSP B i have the following:
> String pathToRootContext = request.getParameter("pathToRootContext");
> The value i get in the pathToRootContext is "..%2f"
> I tried the following but it didn't help:
> <servlet-container name="default" default-encoding="UTF-8">
> <jsp-config development="true" java-encoding="UTF-8"/>
> </servlet-container>
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 11 months