[JBoss JIRA] (WFLY-6815) JDOM cannot create default parser
by Thomas Diesler (JIRA)
[ https://issues.jboss.org/browse/WFLY-6815?page=com.atlassian.jira.plugin.... ]
Thomas Diesler updated WFLY-6815:
---------------------------------
Fix Version/s: (was: 10.1.0.Final)
> JDOM cannot create default parser
> ---------------------------------
>
> Key: WFLY-6815
> URL: https://issues.jboss.org/browse/WFLY-6815
> Project: WildFly
> Issue Type: Sub-task
> Components: Build System
> Reporter: Thomas Diesler
> Assignee: Thomas Diesler
>
> Happens when a tool accesses the org.jdom module
> {code}
> org.jdom.JDOMException: Could not load default SAX parser: org.apache.xerces.parsers.SAXParser: SAX2 driver class org.apache.xerces.parsers.SAXParser not found: org.apache.xerces.parsers.SAXParser from [Module "org.wildfly.extras.config:main" from local module loader @a3d8174 (finder: local module finder @1ba9117e (roots: /Users/tdiesler/git/wildfly-camel/itests/standalone/smoke/target/wildfly-10.1.0.Final-SNAPSHOT/modules,/Users/tdiesler/git/wildfly-camel/itests/standalone/smoke/target/wildfly-10.1.0.Final-SNAPSHOT/modules/system/layers/fuse,/Users/tdiesler/git/wildfly-camel/itests/standalone/smoke/target/wildfly-10.1.0.Final-SNAPSHOT/modules/system/layers/base))]
> at org.jdom.input.SAXBuilder.createParser(SAXBuilder.java:649)
> at org.jdom.input.SAXBuilder.build(SAXBuilder.java:489)
> at org.jdom.input.SAXBuilder.build(SAXBuilder.java:905)
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 6 months
[JBoss JIRA] (WFLY-6815) JDOM cannot create default parser
by Thomas Diesler (JIRA)
[ https://issues.jboss.org/browse/WFLY-6815?page=com.atlassian.jira.plugin.... ]
Thomas Diesler closed WFLY-6815.
--------------------------------
Resolution: Won't Fix
> JDOM cannot create default parser
> ---------------------------------
>
> Key: WFLY-6815
> URL: https://issues.jboss.org/browse/WFLY-6815
> Project: WildFly
> Issue Type: Sub-task
> Components: Build System
> Reporter: Thomas Diesler
> Assignee: Thomas Diesler
>
> Happens when a tool accesses the org.jdom module
> {code}
> org.jdom.JDOMException: Could not load default SAX parser: org.apache.xerces.parsers.SAXParser: SAX2 driver class org.apache.xerces.parsers.SAXParser not found: org.apache.xerces.parsers.SAXParser from [Module "org.wildfly.extras.config:main" from local module loader @a3d8174 (finder: local module finder @1ba9117e (roots: /Users/tdiesler/git/wildfly-camel/itests/standalone/smoke/target/wildfly-10.1.0.Final-SNAPSHOT/modules,/Users/tdiesler/git/wildfly-camel/itests/standalone/smoke/target/wildfly-10.1.0.Final-SNAPSHOT/modules/system/layers/fuse,/Users/tdiesler/git/wildfly-camel/itests/standalone/smoke/target/wildfly-10.1.0.Final-SNAPSHOT/modules/system/layers/base))]
> at org.jdom.input.SAXBuilder.createParser(SAXBuilder.java:649)
> at org.jdom.input.SAXBuilder.build(SAXBuilder.java:489)
> at org.jdom.input.SAXBuilder.build(SAXBuilder.java:905)
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 6 months
[JBoss JIRA] (WFLY-6815) JDOM cannot create default parser
by Thomas Diesler (JIRA)
[ https://issues.jboss.org/browse/WFLY-6815?page=com.atlassian.jira.plugin.... ]
Thomas Diesler closed WFLY-6815.
--------------------------------
Resolution: Won't Fix
Works when caller has a wire to org.apache.xerces so that the default SAX parser can be loaded
> JDOM cannot create default parser
> ---------------------------------
>
> Key: WFLY-6815
> URL: https://issues.jboss.org/browse/WFLY-6815
> Project: WildFly
> Issue Type: Sub-task
> Components: Build System
> Reporter: Thomas Diesler
> Assignee: Thomas Diesler
> Fix For: 10.1.0.Final
>
>
> Happens when a tool accesses the org.jdom module
> {code}
> org.jdom.JDOMException: Could not load default SAX parser: org.apache.xerces.parsers.SAXParser: SAX2 driver class org.apache.xerces.parsers.SAXParser not found: org.apache.xerces.parsers.SAXParser from [Module "org.wildfly.extras.config:main" from local module loader @a3d8174 (finder: local module finder @1ba9117e (roots: /Users/tdiesler/git/wildfly-camel/itests/standalone/smoke/target/wildfly-10.1.0.Final-SNAPSHOT/modules,/Users/tdiesler/git/wildfly-camel/itests/standalone/smoke/target/wildfly-10.1.0.Final-SNAPSHOT/modules/system/layers/fuse,/Users/tdiesler/git/wildfly-camel/itests/standalone/smoke/target/wildfly-10.1.0.Final-SNAPSHOT/modules/system/layers/base))]
> at org.jdom.input.SAXBuilder.createParser(SAXBuilder.java:649)
> at org.jdom.input.SAXBuilder.build(SAXBuilder.java:489)
> at org.jdom.input.SAXBuilder.build(SAXBuilder.java:905)
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 6 months
[JBoss JIRA] (WFLY-6815) JDOM cannot create default parser
by Thomas Diesler (JIRA)
[ https://issues.jboss.org/browse/WFLY-6815?page=com.atlassian.jira.plugin.... ]
Thomas Diesler updated WFLY-6815:
---------------------------------
Description:
Happens when a tool accesses the org.jdom module
{code}
org.jdom.JDOMException: Could not load default SAX parser: org.apache.xerces.parsers.SAXParser: SAX2 driver class org.apache.xerces.parsers.SAXParser not found: org.apache.xerces.parsers.SAXParser from [Module "org.wildfly.extras.config:main" from local module loader @a3d8174 (finder: local module finder @1ba9117e (roots: /Users/tdiesler/git/wildfly-camel/itests/standalone/smoke/target/wildfly-10.1.0.Final-SNAPSHOT/modules,/Users/tdiesler/git/wildfly-camel/itests/standalone/smoke/target/wildfly-10.1.0.Final-SNAPSHOT/modules/system/layers/fuse,/Users/tdiesler/git/wildfly-camel/itests/standalone/smoke/target/wildfly-10.1.0.Final-SNAPSHOT/modules/system/layers/base))]
at org.jdom.input.SAXBuilder.createParser(SAXBuilder.java:649)
at org.jdom.input.SAXBuilder.build(SAXBuilder.java:489)
at org.jdom.input.SAXBuilder.build(SAXBuilder.java:905)
{code}
was:
{code}
org.jdom.JDOMException: Could not load default SAX parser: org.apache.xerces.parsers.SAXParser: SAX2 driver class org.apache.xerces.parsers.SAXParser not found: org.apache.xerces.parsers.SAXParser from [Module "org.wildfly.extras.config:main" from local module loader @a3d8174 (finder: local module finder @1ba9117e (roots: /Users/tdiesler/git/wildfly-camel/itests/standalone/smoke/target/wildfly-10.1.0.Final-SNAPSHOT/modules,/Users/tdiesler/git/wildfly-camel/itests/standalone/smoke/target/wildfly-10.1.0.Final-SNAPSHOT/modules/system/layers/fuse,/Users/tdiesler/git/wildfly-camel/itests/standalone/smoke/target/wildfly-10.1.0.Final-SNAPSHOT/modules/system/layers/base))]
at org.jdom.input.SAXBuilder.createParser(SAXBuilder.java:649)
at org.jdom.input.SAXBuilder.build(SAXBuilder.java:489)
at org.jdom.input.SAXBuilder.build(SAXBuilder.java:905)
{code}
> JDOM cannot create default parser
> ---------------------------------
>
> Key: WFLY-6815
> URL: https://issues.jboss.org/browse/WFLY-6815
> Project: WildFly
> Issue Type: Sub-task
> Components: Build System
> Reporter: Thomas Diesler
> Assignee: Thomas Diesler
> Fix For: 10.1.0.Final
>
>
> Happens when a tool accesses the org.jdom module
> {code}
> org.jdom.JDOMException: Could not load default SAX parser: org.apache.xerces.parsers.SAXParser: SAX2 driver class org.apache.xerces.parsers.SAXParser not found: org.apache.xerces.parsers.SAXParser from [Module "org.wildfly.extras.config:main" from local module loader @a3d8174 (finder: local module finder @1ba9117e (roots: /Users/tdiesler/git/wildfly-camel/itests/standalone/smoke/target/wildfly-10.1.0.Final-SNAPSHOT/modules,/Users/tdiesler/git/wildfly-camel/itests/standalone/smoke/target/wildfly-10.1.0.Final-SNAPSHOT/modules/system/layers/fuse,/Users/tdiesler/git/wildfly-camel/itests/standalone/smoke/target/wildfly-10.1.0.Final-SNAPSHOT/modules/system/layers/base))]
> at org.jdom.input.SAXBuilder.createParser(SAXBuilder.java:649)
> at org.jdom.input.SAXBuilder.build(SAXBuilder.java:489)
> at org.jdom.input.SAXBuilder.build(SAXBuilder.java:905)
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 6 months
[JBoss JIRA] (DROOLS-1229) Event expiration cycles itself when expiring events from large set of same rules with "after" operator
by Tibor Zimányi (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1229?page=com.atlassian.jira.plugi... ]
Tibor Zimányi updated DROOLS-1229:
----------------------------------
Description:
When using many same rules with after, event expiration cycles itself.
Using 64 copies of this rule [1], code here [2] cycles itself. I think it is because when it searches through child and peer tuples, it can find already expired tuple and it tries to expire it again. So the problem is either there or in that there is some cycle in tuple chain.
[1]
import org.drools.testcoverage.common.model.EventA;
import org.drools.testcoverage.common.model.EventB;
declare org.drools.testcoverage.common.model.EventA @role( event ) @duration(duration) end declare org.drools.testcoverage.common.model.EventB @role( event ) @duration(duration) end rule R0 when
$event1: org.drools.testcoverage.common.model.EventA()
$event2: org.drools.testcoverage.common.model.EventB(this != $event1, this after [1,10] $event1)
then end
[2] https://github.com/droolsjbpm/drools/blob/master/drools-core/src/main/jav...
I will make a PR with reproducer and proposed fix for this.
was:
When using many same rules with after, event expiration cycles itself.
Using 64 copies of this rule:
I will make a PR with reproducer and proposed fix for this.
> Event expiration cycles itself when expiring events from large set of same rules with "after" operator
> ------------------------------------------------------------------------------------------------------
>
> Key: DROOLS-1229
> URL: https://issues.jboss.org/browse/DROOLS-1229
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 6.4.0.Final
> Reporter: Tibor Zimányi
> Assignee: Mario Fusco
>
> When using many same rules with after, event expiration cycles itself.
> Using 64 copies of this rule [1], code here [2] cycles itself. I think it is because when it searches through child and peer tuples, it can find already expired tuple and it tries to expire it again. So the problem is either there or in that there is some cycle in tuple chain.
> [1]
> import org.drools.testcoverage.common.model.EventA;
> import org.drools.testcoverage.common.model.EventB;
> declare org.drools.testcoverage.common.model.EventA @role( event ) @duration(duration) end declare org.drools.testcoverage.common.model.EventB @role( event ) @duration(duration) end rule R0 when
> $event1: org.drools.testcoverage.common.model.EventA()
> $event2: org.drools.testcoverage.common.model.EventB(this != $event1, this after [1,10] $event1)
> then end
> [2] https://github.com/droolsjbpm/drools/blob/master/drools-core/src/main/jav...
> I will make a PR with reproducer and proposed fix for this.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 6 months
[JBoss JIRA] (DROOLS-1198) NoClassDefFoundError when using str[endsWith] on a field that matches an imported class name
by Chris Austin (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1198?page=com.atlassian.jira.plugi... ]
Chris Austin commented on DROOLS-1198:
--------------------------------------
That test works for me, but if I change the import from
import mssp.io.model.User;
To:
import mssp.io.model.*;
Then the error occurs.
If that doesn't trigger it for you then it might be related to running it on OS X, which has a case preserving/insensitive filesystem.
> NoClassDefFoundError when using str[endsWith] on a field that matches an imported class name
> --------------------------------------------------------------------------------------------
>
> Key: DROOLS-1198
> URL: https://issues.jboss.org/browse/DROOLS-1198
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 6.4.0.Final
> Reporter: Chris Austin
> Assignee: Mario Fusco
> Priority: Minor
> Attachments: DROOLS-1198-unabletoreproduce.zip
>
>
> This error was triggered when accessing the user field with str[endsWith] when user is null:
> java.lang.NoClassDefFoundError: mssp/io/model/user (wrong name: mssp/io/model/User)
> Condition that triggers the error:
> $a : Alert(user!=null, user str[endsWith] "$")
> This does not trigger the error:
> $a : Alert(user!=null, user matches ".+\\$")
> If I remove the import for the User class the error will not be triggered. As a workaround I've switched to using matches instead of str[endsWith], but I'd prefer to switch back.
> I did not experience this issue in 6.3.0-Final, so it appears to be a regression in 6.4.0-Final
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 6 months
[JBoss JIRA] (DROOLS-1198) NoClassDefFoundError when using str[endsWith] on a field that matches an imported class name
by Matteo Mortari (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1198?page=com.atlassian.jira.plugi... ]
Matteo Mortari commented on DROOLS-1198:
----------------------------------------
Hello [~chrisxaustin], would it be possible for you to provide a reproducer, please?
This is because I've checked your statements but unfortunately I'm unable to reproduce the error you mentioned.
Here are my assumptions, following your description:
* an {{Alert}} class pojo with a "user" field of type String.
* a {{User}} class pojo, which needs to be imported in the import statements - the actual definition is not relevant
* the LHS condition as per your description with the operator {{str\[endsWith\]}}
checked against 6.4.0.Final, does not trigger the error you mentioned.
I've attached the Maven project containing the JUnit which I drafted, and running the test suite the error does not trigger: [^DROOLS-1198-unabletoreproduce.zip]. Possibly could help you to provide a reproducer?
> NoClassDefFoundError when using str[endsWith] on a field that matches an imported class name
> --------------------------------------------------------------------------------------------
>
> Key: DROOLS-1198
> URL: https://issues.jboss.org/browse/DROOLS-1198
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 6.4.0.Final
> Reporter: Chris Austin
> Assignee: Mario Fusco
> Priority: Minor
> Attachments: DROOLS-1198-unabletoreproduce.zip
>
>
> This error was triggered when accessing the user field with str[endsWith] when user is null:
> java.lang.NoClassDefFoundError: mssp/io/model/user (wrong name: mssp/io/model/User)
> Condition that triggers the error:
> $a : Alert(user!=null, user str[endsWith] "$")
> This does not trigger the error:
> $a : Alert(user!=null, user matches ".+\\$")
> If I remove the import for the User class the error will not be triggered. As a workaround I've switched to using matches instead of str[endsWith], but I'd prefer to switch back.
> I did not experience this issue in 6.3.0-Final, so it appears to be a regression in 6.4.0-Final
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 6 months
[JBoss JIRA] (DROOLS-1198) NoClassDefFoundError when using str[endsWith] on a field that matches an imported class name
by Matteo Mortari (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1198?page=com.atlassian.jira.plugi... ]
Matteo Mortari updated DROOLS-1198:
-----------------------------------
Attachment: DROOLS-1198-unabletoreproduce.zip
> NoClassDefFoundError when using str[endsWith] on a field that matches an imported class name
> --------------------------------------------------------------------------------------------
>
> Key: DROOLS-1198
> URL: https://issues.jboss.org/browse/DROOLS-1198
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 6.4.0.Final
> Reporter: Chris Austin
> Assignee: Mario Fusco
> Priority: Minor
> Attachments: DROOLS-1198-unabletoreproduce.zip
>
>
> This error was triggered when accessing the user field with str[endsWith] when user is null:
> java.lang.NoClassDefFoundError: mssp/io/model/user (wrong name: mssp/io/model/User)
> Condition that triggers the error:
> $a : Alert(user!=null, user str[endsWith] "$")
> This does not trigger the error:
> $a : Alert(user!=null, user matches ".+\\$")
> If I remove the import for the User class the error will not be triggered. As a workaround I've switched to using matches instead of str[endsWith], but I'd prefer to switch back.
> I did not experience this issue in 6.3.0-Final, so it appears to be a regression in 6.4.0-Final
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 6 months
[JBoss JIRA] (WFCORE-1647) Default app-name value of Syslog handler in Audit Logging violates specification
by Jan Tymel (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1647?page=com.atlassian.jira.plugi... ]
Jan Tymel commented on WFCORE-1647:
-----------------------------------
Ooops, you're right. I overlooked that I had been in incorrect folder when running the server (dist/target instead of build/target). In 3.0.0.Alpha3 is the default app-name {{WildFly}} so it works as expected.
> Default app-name value of Syslog handler in Audit Logging violates specification
> --------------------------------------------------------------------------------
>
> Key: WFCORE-1647
> URL: https://issues.jboss.org/browse/WFCORE-1647
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 3.0.0.Alpha3
> Reporter: Jan Tymel
> Assignee: Brian Stansberry
>
> According to syslog specification[1] {{app-name}} cannot contain space character (" "). However, the default value in WildFly Core 3.0.0.Alpha3 is {{WildFly Core}}. This results in the syslog server is not able to capture Process ID from which the message was sent.
> E.g. following piece of information is captured {{WildFly[Core] (...)}} instead of {{WildFlyCore[795]}}
> Suggestions for improvement:
> Change default value {{WildFly Core}} to one without space character.
> Also please consider addition of check whether {{app-name}} contains space character.
> [1] https://tools.ietf.org/html/rfc5424#page-8
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 6 months