[JBoss JIRA] (JBMETA-373) [backport JBMETA-371] DefaultPropertyReplacer + PropertyResolver is broken for vault expressions
by Chris Dolphy (JIRA)
[ https://issues.jboss.org/browse/JBMETA-373?page=com.atlassian.jira.plugin... ]
Chris Dolphy commented on JBMETA-373:
-------------------------------------
Pull request to add JBMETA-371 to 7.0.9
https://github.com/jboss/metadata/pull/58
> [backport JBMETA-371] DefaultPropertyReplacer + PropertyResolver is broken for vault expressions
> ------------------------------------------------------------------------------------------------
>
> Key: JBMETA-373
> URL: https://issues.jboss.org/browse/JBMETA-373
> Project: JBoss Metadata
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: common
> Affects Versions: 7.0.4.Final
> Reporter: Chris Dolphy
> Assignee: Brian Stansberry
>
> The DefaultPropertyReplacer + PropertyResolver algorithm is broken for vault expressions. It's based on the assumption that the contents of the expression string between "${" and "}" have a fixed format a la the old JBoss AS system properties (e.g. propertyname[: default value]) and then the PropertyResolver tries to resolve "propertyname".
> This is incorrect in the case of vault expressions, which do not follow this format. In particular the ":" char appears multiple places in a vault expression and does not serve as a delimiter between "propertyname" and "default value".
--
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
10 years, 2 months
[JBoss JIRA] (WFLY-2851) Can't validate jboss-deployment-structure.xml due to incorrect schema
by Harald Wellmann (JIRA)
[ https://issues.jboss.org/browse/WFLY-2851?page=com.atlassian.jira.plugin.... ]
Harald Wellmann updated WFLY-2851:
----------------------------------
Description:
The following deployment structure cannot be validated against the XML schema:
{code:xml}
<jboss-deployment-structure xmlns="urn:jboss:deployment-structure:1.2">
<deployment>
<dependencies>
<module name="foo"/>
</dependencies>
</deployment>
</jboss-deployment-structure>
{code}
This looks like a glitch in the schema where the {{module-alias}} element in {{deploymentType}} is missing a {{minOccurs="0"}}.
The same holds for the {{filter}} element of {{resource-root}}, which should be optional according to the schema documentation.
was:
The following deployment structure cannot be validated against the XML schema:
{code:xml}
<jboss-deployment-structure xmlns="urn:jboss:deployment-structure:1.2">
<deployment>
<dependencies>
<module name="foo"/>
</dependencies>
</deployment>
</jboss-deployment-structure>
{code}
This looks like a glitch in the schema where the {{module-alias}} element in {{deploymentType}} is missing a {{minOccurs="0"}}.
> Can't validate jboss-deployment-structure.xml due to incorrect schema
> ---------------------------------------------------------------------
>
> Key: WFLY-2851
> URL: https://issues.jboss.org/browse/WFLY-2851
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 8.0.0.CR1
> Reporter: Harald Wellmann
>
> The following deployment structure cannot be validated against the XML schema:
> {code:xml}
> <jboss-deployment-structure xmlns="urn:jboss:deployment-structure:1.2">
> <deployment>
> <dependencies>
> <module name="foo"/>
> </dependencies>
> </deployment>
> </jboss-deployment-structure>
> {code}
> This looks like a glitch in the schema where the {{module-alias}} element in {{deploymentType}} is missing a {{minOccurs="0"}}.
> The same holds for the {{filter}} element of {{resource-root}}, which should be optional according to the schema documentation.
--
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
10 years, 2 months
[JBoss JIRA] (WFLY-2851) Can't validate jboss-deployment-structure.xml due to incorrect schema
by Harald Wellmann (JIRA)
Harald Wellmann created WFLY-2851:
-------------------------------------
Summary: Can't validate jboss-deployment-structure.xml due to incorrect schema
Key: WFLY-2851
URL: https://issues.jboss.org/browse/WFLY-2851
Project: WildFly
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: 8.0.0.CR1
Reporter: Harald Wellmann
The following deployment structure cannot be validated against the XML schema:
{code:xml}
<jboss-deployment-structure xmlns="urn:jboss:deployment-structure:1.2">
<deployment>
<dependencies>
<module name="foo"/>
</dependencies>
</deployment>
</jboss-deployment-structure>
{code}
This looks like a glitch in the schema where the {{module-alias}} element in {{deploymentType}} is missing a {{minOccurs="0"}}.
--
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
10 years, 2 months
[JBoss JIRA] (WFLY-1901) Could not grant javax.xml.ws.WebServicePermission to a deployment
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-1901?page=com.atlassian.jira.plugin.... ]
Stuart Douglas commented on WFLY-1901:
--------------------------------------
In my PR I have added a module attribute that allows you to specify the module to load the permission from.
> Could not grant javax.xml.ws.WebServicePermission to a deployment
> -----------------------------------------------------------------
>
> Key: WFLY-1901
> URL: https://issues.jboss.org/browse/WFLY-1901
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Security Manager
> Affects Versions: 8.0.0.Alpha4
> Reporter: Alessio Soldano
> Assignee: Stefan Guilhen
> Fix For: 8.0.0.Final
>
>
> It's currently not possible by default to grant the javax.xml.ws.WebServicePermission "publish" permission to a user deployment by adding the proper entry in standalone.xml:
> {noformat}
> <subsystem xmlns="urn:jboss:domain:security-manager:1.0">
> <deployment-permissions>
> <minimum-set>
> ...
> <permission class="javax.xml.ws.WebServicePermission" name="publishEndpoint"/>
> </minimum-set>
> </deployment-permissions>
> </subsystem>
> {noformat}
--
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
10 years, 2 months
[JBoss JIRA] (WFLY-2611) Unify JSF action listener and CDI integration
by Tomas Remes (JIRA)
[ https://issues.jboss.org/browse/WFLY-2611?page=com.atlassian.jira.plugin.... ]
Tomas Remes updated WFLY-2611:
------------------------------
Description:
There are three ways, how can user specify custom JSF action listener:
1. Method binding - with actionListener param. This case is ok, meaning CDI injection and interceptor works for given method/bean.
2. Providing custom implementation - <f:actionListener type="org.jboss.jsf.listeners.MyActionListener"/>. In this case CDI doesn't work at all for processAction method of given class.
3. Defining in faces-config - in this case CDI injection works, but interceptor is not executed.
Reproducer available at https://github.com/tremes/javaee7-samples/tree/cdi-testing/jsf/jsf-listen.... Test can be executed with "mvn clean test -Pwildfly-managed-arquillian" or "mvn clean test -Pwildfly-remote-arquillian" and IMHO all should pass.
was:
There are three ways, how can user specify custom JSF action listener:
1. Method binding - with actionListener param. This case is ok, meaning CDI injection and interceptor works for given method/bean.
2. Providing custom implementation - <f:actionListener type="org.jboss.jsf.listeners.MyActionListener"/>. In this case CDI doesn't work at all for processAction method of given class.
3. Defining in faces-config - in this case CDI injection works, but interceptor is not executed.
Producer available at https://github.com/tremes/javaee7-samples/tree/cdi-testing/jsf/jsf-listen.... Test can be executed with "mvn clean test -Pwildfly-managed-arquillian" or "mvn clean test -Pwildfly-remote-arquillian" and IMHO all should pass.
> Unify JSF action listener and CDI integration
> ---------------------------------------------
>
> Key: WFLY-2611
> URL: https://issues.jboss.org/browse/WFLY-2611
> Project: WildFly
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: CDI / Weld, JSF
> Affects Versions: 8.0.0.CR1
> Reporter: Tomas Remes
> Assignee: Farah Juma
>
> There are three ways, how can user specify custom JSF action listener:
> 1. Method binding - with actionListener param. This case is ok, meaning CDI injection and interceptor works for given method/bean.
> 2. Providing custom implementation - <f:actionListener type="org.jboss.jsf.listeners.MyActionListener"/>. In this case CDI doesn't work at all for processAction method of given class.
> 3. Defining in faces-config - in this case CDI injection works, but interceptor is not executed.
> Reproducer available at https://github.com/tremes/javaee7-samples/tree/cdi-testing/jsf/jsf-listen.... Test can be executed with "mvn clean test -Pwildfly-managed-arquillian" or "mvn clean test -Pwildfly-remote-arquillian" and IMHO all should pass.
>
--
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
10 years, 2 months
[JBoss JIRA] (WFLY-2611) Unify JSF action listener and CDI integration
by Tomas Remes (JIRA)
[ https://issues.jboss.org/browse/WFLY-2611?page=com.atlassian.jira.plugin.... ]
Tomas Remes edited comment on WFLY-2611 at 1/31/14 9:02 AM:
------------------------------------------------------------
I've realized that the original issue was too general (and basically all functionality works as expected IMO), so I've changed the description to be more specific.
was (Author: tremes):
In JSF spec there is also following sentence: "..the following JSF artifacts are also injectable." followed by the classes listed above. I am not sure, if I understand it correctly. Does it mean that when I create e.g my custom NavigationHandler (and specify it in faces-config), should it be available for injection? e.g like this:
{noformat}
@Inject
CustomNavigationHandler handler;
{noformat}
[~ssilvert] Can you please elaborate?
> Unify JSF action listener and CDI integration
> ---------------------------------------------
>
> Key: WFLY-2611
> URL: https://issues.jboss.org/browse/WFLY-2611
> Project: WildFly
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: CDI / Weld, JSF
> Affects Versions: 8.0.0.CR1
> Reporter: Tomas Remes
> Assignee: Farah Juma
>
> There are three ways, how can user specify custom JSF action listener:
> 1. Method binding - with actionListener param. This case is ok, meaning CDI injection and interceptor works for given method/bean.
> 2. Providing custom implementation - <f:actionListener type="org.jboss.jsf.listeners.MyActionListener"/>. In this case CDI doesn't work at all for processAction method of given class.
> 3. Defining in faces-config - in this case CDI injection works, but interceptor is not executed.
> Producer available at https://github.com/tremes/javaee7-samples/tree/cdi-testing/jsf/jsf-listen.... Test can be executed with "mvn clean test -Pwildfly-managed-arquillian" or "mvn clean test -Pwildfly-remote-arquillian" and IMHO all should pass.
>
--
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
10 years, 2 months
[JBoss JIRA] (WFLY-2611) Unify JSF action listener and CDI integration
by Tomas Remes (JIRA)
[ https://issues.jboss.org/browse/WFLY-2611?page=com.atlassian.jira.plugin.... ]
Tomas Remes updated WFLY-2611:
------------------------------
Summary: Unify JSF action listener and CDI integration (was: Support CDI injection in various JSF artifacts)
Assignee: Farah Juma (was: Stuart Douglas)
Affects Version/s: 8.0.0.CR1
Description:
There are three ways, how can user specify custom JSF action listener:
1. Method binding - with actionListener param. This case is ok, meaning CDI injection and interceptor works for given method/bean.
2. Providing custom implementation - <f:actionListener type="org.jboss.jsf.listeners.MyActionListener"/>. In this case CDI doesn't work at all for processAction method of given class.
3. Defining in faces-config - in this case CDI injection works, but interceptor is not executed.
Producer available at https://github.com/tremes/javaee7-samples/tree/cdi-testing/jsf/jsf-listen.... Test can be executed with "mvn clean test -Pwildfly-managed-arquillian" or "mvn clean test -Pwildfly-remote-arquillian" and IMHO all should pass.
was:
If I understand correctly to the subchapter "5.4.1
JSF Managed Classes and Java EE Annotations" of JSF 2.2 specification, there should be opportunity to use a lot of (and not only) CDI annotations in various JSF artifacts (ActionListener, SystemEventListener, etc. - for full list, please see the spec).
So far I tried locally this (will be filling the table during time):
||JSF artifact||CDI Injection||
|javax.el.ELResolver|works|
|javax.faces.application.ApplicationFactory|works only for ApplicationScoped and Dependent scoped beans - probably reasonable ?|
|javax.faces.application.NavigationHandler|works|
|javax.faces.application.ResourceHandler|works only for ApplicationScoped and Dependent scoped beans - probably reasonable ?|
|javax.faces.application.StateManager|works (however there is question about availability of injected instances in constructor of this custom delegating object|
|javax.faces.component.visit.VisitContextFactory|works|
|javax.faces.context.ExceptionHandlerFactory|works|
|javax.faces.context.ExternalContextFactory|works|
|javax.faces.context.FacesContextFactory|works|
|javax.faces.context.FlashFactory|works|
|javax.faces.context.PartialViewContextFactory|works|
|javax.faces.event.ActionListener|works only when specified also in faces-config|
|javax.faces.event.SystemEventListener|works only for ApplicationScoped and Dependent scoped beans - probably reasonable ?|
|javax.faces.lifecycle.ClientWindowFactory|works|
|javax.faces.lifecycle.LifecycleFactory|works only for ApplicationScoped and Dependent scoped beans - probably reasonable ?|
|javax.faces.lifecycle.PhaseListener|works|
|javax.faces.render.RenderKitFactory|works only for ApplicationScoped and Dependent scoped beans - probably reasonable ?|
|javax.faces.view.ViewDeclarationLanguageFactory|works only for ApplicationScoped and Dependent scoped beans - probably reasonable ?|
|javax.faces.view.facelets.FaceletCacheFactory|works only for ApplicationScoped and Dependent scoped beans - probably reasonable ?|
|javax.faces.view.facelets.TagHandlerDelegateFactory|works|
> Unify JSF action listener and CDI integration
> ---------------------------------------------
>
> Key: WFLY-2611
> URL: https://issues.jboss.org/browse/WFLY-2611
> Project: WildFly
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: CDI / Weld, JSF
> Affects Versions: 8.0.0.CR1
> Reporter: Tomas Remes
> Assignee: Farah Juma
>
> There are three ways, how can user specify custom JSF action listener:
> 1. Method binding - with actionListener param. This case is ok, meaning CDI injection and interceptor works for given method/bean.
> 2. Providing custom implementation - <f:actionListener type="org.jboss.jsf.listeners.MyActionListener"/>. In this case CDI doesn't work at all for processAction method of given class.
> 3. Defining in faces-config - in this case CDI injection works, but interceptor is not executed.
> Producer available at https://github.com/tremes/javaee7-samples/tree/cdi-testing/jsf/jsf-listen.... Test can be executed with "mvn clean test -Pwildfly-managed-arquillian" or "mvn clean test -Pwildfly-remote-arquillian" and IMHO all should pass.
>
--
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
10 years, 2 months
[JBoss JIRA] (WFLY-2100) Vault.sh logging improvements
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFLY-2100?page=com.atlassian.jira.plugin.... ]
Darran Lofthouse updated WFLY-2100:
-----------------------------------
Assignee: Peter Skopek (was: Darran Lofthouse)
Peter - is this one that should come your way?
> Vault.sh logging improvements
> -----------------------------
>
> Key: WFLY-2100
> URL: https://issues.jboss.org/browse/WFLY-2100
> Project: WildFly
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Security
> Affects Versions: 8.0.0.Alpha4
> Reporter: Chris Dolphy
> Assignee: Peter Skopek
> Fix For: 9.0.0.CR1
>
>
> Several errors with vault.sh (ineractive Vault Tool) do not display enough information to debug.
> For example, "Exception occurred:PBOX000128: Unable to encrypt data". It would be nice if there was some way to see the cause of this exception either with additional logging options, a verbose option or by default. This one is caused by VaultInteraction.java only displaying the localized error message of the exception.
--
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
10 years, 2 months
[JBoss JIRA] (WFLY-2847) Caller's security identity doesn't get propagated by default
by Matus Abaffy (JIRA)
[ https://issues.jboss.org/browse/WFLY-2847?page=com.atlassian.jira.plugin.... ]
Matus Abaffy updated WFLY-2847:
-------------------------------
Description:
3 session beans: @RunAs("printer") Printer, which calls HelperBean (no security annotations), which calls @RolesAllowed("printer") Toner. The last invocation results in
{{javax.ejb.EJBAccessException: JBAS014502: Invocation on method: public void org.jboss.as.test.integration.ejb.security.runas.propagation.Toner.spill() of bean: Toner is not allowed}}
Printer calling Toner (directly) works just fine. And if the HelperBean is a CDI managed bean, it works just fine too.
According to EJB spec, 12 Security management, 12.1 Overview:
bq. "By default, the caller principal will be propagated as the caller identity. The Bean Provider can use the RunAs annotation to specify that a security principal that has been assigned to a specified security role be used instead. See Section 12.3.4."
12.3.4 Specification of Security Identities in the Deployment Descriptor:
bq. "The Bean Provider or Application Assembler typically specifies whether the caller’s security identity should be used for the execution of the methods of an enterprise bean or whether a specific run-as identity should be used. By default the caller’s security identity is used."
etc.
{code}
@Stateless
@RunAs("printer")
@PermitAll
public class Printer {
@EJB
HelperBean hb;
public void invokeHelperBean() {
hb.invokeToner();
}
}
{code}
{code}
@Stateful
public class HelperBean {
@EJB
Toner toner;
public void invokeToner() {
toner.spill();
}
}
{code}
{code}
@Stateless
@RolesAllowed("printer")
public class Toner {
public void spill() {}
}
{code}
A bit sophisticated test available at: https://github.com/bafco/wildfly/commits/securityContext
was:
3 session beans: @RunAs("printer") Printer, which calls HelperBean (no security annotations), which calls @RolesAllowed("printer") Toner. The last invocation results in
{{javax.ejb.EJBAccessException: JBAS014502: Invocation on method: public void org.jboss.as.test.integration.ejb.security.runas.propagation.Toner.spill() of bean: Toner is not allowed}}
Printer calling Toner (directly) works just fine. And if the HelperBean is a CDI managed bean, it works just fine too.
According to EJB spec, 12 Security management, 12.1 Overview:
bq. "By default, the caller principal will be propagated as the caller identity. The Bean Provider can use the RunAs annotation to specify that a security principal that has been assigned to a specified security role be used instead. See Section 12.3.4."
12.3.4 Specification of Security Identities in the Deployment Descriptor:
bq. "The Bean Provider or Application Assembler typically specifies whether the caller’s security identity should be used for the execution of the methods of an enterprise bean or whether a specific run-as identity should be used. By default the caller’s security identity is used."
etc.
{code}
@RunAs("printer")
@PermitAll
public class Printer {
@EJB
HelperBean hb;
public void invokeHelperBean() {
hb.invokeToner();
}
}
{code}
{code}
@Stateful
public class HelperBean {
@EJB
Toner toner;
public void invokeToner() {
toner.spill();
}
}
{code}
{code}
@Stateless
@RolesAllowed("printer")
public class Toner {
public void spill() {}
}
{code}
A bit sophisticated test available at: https://github.com/bafco/wildfly/commits/securityContext
> Caller's security identity doesn't get propagated by default
> ------------------------------------------------------------
>
> Key: WFLY-2847
> URL: https://issues.jboss.org/browse/WFLY-2847
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: EJB, Security
> Affects Versions: 8.0.0.CR1
> Reporter: Matus Abaffy
> Assignee: David Lloyd
>
> 3 session beans: @RunAs("printer") Printer, which calls HelperBean (no security annotations), which calls @RolesAllowed("printer") Toner. The last invocation results in
> {{javax.ejb.EJBAccessException: JBAS014502: Invocation on method: public void org.jboss.as.test.integration.ejb.security.runas.propagation.Toner.spill() of bean: Toner is not allowed}}
> Printer calling Toner (directly) works just fine. And if the HelperBean is a CDI managed bean, it works just fine too.
> According to EJB spec, 12 Security management, 12.1 Overview:
> bq. "By default, the caller principal will be propagated as the caller identity. The Bean Provider can use the RunAs annotation to specify that a security principal that has been assigned to a specified security role be used instead. See Section 12.3.4."
> 12.3.4 Specification of Security Identities in the Deployment Descriptor:
> bq. "The Bean Provider or Application Assembler typically specifies whether the caller’s security identity should be used for the execution of the methods of an enterprise bean or whether a specific run-as identity should be used. By default the caller’s security identity is used."
> etc.
> {code}
> @Stateless
> @RunAs("printer")
> @PermitAll
> public class Printer {
> @EJB
> HelperBean hb;
> public void invokeHelperBean() {
> hb.invokeToner();
> }
> }
> {code}
> {code}
> @Stateful
> public class HelperBean {
> @EJB
> Toner toner;
> public void invokeToner() {
> toner.spill();
> }
> }
> {code}
> {code}
> @Stateless
> @RolesAllowed("printer")
> public class Toner {
> public void spill() {}
> }
> {code}
> A bit sophisticated test available at: https://github.com/bafco/wildfly/commits/securityContext
--
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
10 years, 2 months
[JBoss JIRA] (DROOLS-404) NoClassDefFoundError happens when using "function"s in drl
by Mario Fusco (JIRA)
[ https://issues.jboss.org/browse/DROOLS-404?page=com.atlassian.jira.plugin... ]
Mario Fusco resolved DROOLS-404.
--------------------------------
Fix Version/s: 6.1.0.Beta1
Resolution: Done
> NoClassDefFoundError happens when using "function"s in drl
> ----------------------------------------------------------
>
> Key: DROOLS-404
> URL: https://issues.jboss.org/browse/DROOLS-404
> Project: Drools
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 6.0.0.Final, 6.0.1.Final
> Environment: The base environment is the same as DefaultKieSessionExample.
> See attached maven project for details.
> Reporter: Nandor Galambosi
> Assignee: Mario Fusco
> Fix For: 6.1.0.Beta1
>
> Attachments: noclassdeffound.zip
>
>
> If I reuse a KieSession for multiple times, it seems to forget about the function defined in the DRL file.
> DRL:
> {noformat}
> package org.drools.example.api.defaultkiesession.Hal1
> import org.drools.example.api.defaultkiesession.Message
> function boolean alwaysTrue() {
> return true;
> }
> rule "rule 1" when
> m : Message( )
> then
> retract(m);
> end
> rule "rule 2" when
> Message( alwaysTrue(), text == "Hello, HAL. Do you read me, HAL?" )
> then
> insert( new Message("HAL", "Dave. I read you." ) );
> end
> {noformat}
> Java code:
> {noformat}
> package org.drools.example.api.defaultkiesession;
> import org.kie.api.KieServices;
> import org.kie.api.runtime.KieContainer;
> import org.kie.api.runtime.KieSession;
> public class DefaultKieSessionExample
> {
> static int counter = 0;
> public void failCase1()
> {
> KieServices ks = KieServices.Factory.get();
> KieContainer kContainer = ks.getKieClasspathContainer();
> KieSession kSession = kContainer.newKieSession();
> for( counter = 0; counter < 10000; ++counter) {
> kSession.insert(new Message("Dave", "Hello, HAL. Do you read me, HAL?"));
> kSession.fireAllRules();
> if (kSession.getFactCount() != 0) {
> System.err.println("error");
> }
> }
> }
> public static void main(String[] args)
> {
> try {
> DefaultKieSessionExample defaultKieSessionExample = new DefaultKieSessionExample();
> defaultKieSessionExample.failCase1();
> } catch (NoClassDefFoundError error) {
> System.err.println("Failed after "+counter+" testcases");
> error.printStackTrace();
> }
> }
> }
> {noformat}
> Runs fine for some iterations, and after a while an exception happens:
> {noformat}
> java.lang.NoClassDefFoundError: org/drools/example/api/defaultkiesession/Hal1/AlwaysTrue
> at ConditionEvaluator19fe4e382c304060b0046f5cdc6a59fa.evaluate(Unknown Source)
> at org.drools.core.rule.constraint.MvelConstraint.evaluate(MvelConstraint.java:217)
> at org.drools.core.rule.constraint.MvelConstraint.isAllowed(MvelConstraint.java:174)
> at org.drools.core.reteoo.AlphaNode.assertObject(AlphaNode.java:134)
> at org.drools.core.reteoo.CompositeObjectSinkAdapter.doPropagateAssertObject(CompositeObjectSinkAdapter.java:502)
> at org.drools.core.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:387)
> at org.drools.core.reteoo.ObjectTypeNode.assertObject(ObjectTypeNode.java:288)
> at org.drools.core.reteoo.EntryPointNode.assertObject(EntryPointNode.java:260)
> at org.drools.core.common.NamedEntryPoint.insert(NamedEntryPoint.java:360)
> at org.drools.core.common.NamedEntryPoint.insert(NamedEntryPoint.java:279)
> at org.drools.core.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:1148)
> at org.drools.core.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:1092)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.insert(StatefulKnowledgeSessionImpl.java:308)
> at org.drools.example.api.defaultkiesession.DefaultKieSessionExample.failCase1(DefaultKieSessionExample.java:17)
> at org.drools.example.api.defaultkiesession.DefaultKieSessionExample.main(DefaultKieSessionExample.java:29)
> Caused by: java.lang.ClassNotFoundException: org.drools.example.api.defaultkiesession.Hal1.AlwaysTrue
> at org.drools.core.common.ProjectClassLoader.tryDefineType(ProjectClassLoader.java:123)
> at org.drools.core.common.ProjectClassLoader.loadType(ProjectClassLoader.java:114)
> at org.drools.core.common.ProjectClassLoader.loadClass(ProjectClassLoader.java:84)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:247)
> ... 15 more
> {noformat}
--
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
10 years, 2 months