[JBoss JIRA] (DROOLS-372) InstantiationError during condition evaluation in Drools 6.0.0.Final
by Loic Albertin (JIRA)
Loic Albertin created DROOLS-372:
------------------------------------
Summary: InstantiationError during condition evaluation in Drools 6.0.0.Final
Key: DROOLS-372
URL: https://issues.jboss.org/browse/DROOLS-372
Project: Drools
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: 6.0.0.Final
Environment: reproduced on both jdk 6 and jdk 7
Reporter: Loic Albertin
Assignee: Mark Proctor
Kindly find bellow the initial discussion from rules-user(a)list.jboss.org
In addition I attach a sample project that reproduce the error.
To run it simply type 'mvn clean install exec:java'.
An interesting thing is that on my environment the issue always appears at the 21st insertion.
{quote}
Hi all,
I'm migrating from an old Drools 5.1 version to 6.0.0.Final. Sometimes (I don't really get under which conditions as sometimes it works), I'm facing an InstantiationError exception when I insert a fact into a stateful kie session. This exception is thrown by a generated class named ConditionEvaluator<UUID> which doesn't help for debugging!
The inserted object is a basic POJO (named JasmineEventEB) except for an attribute named "value" which accept any "Serializable" object and which is causing the issue.
The rule condition is quite simple
$e : JasmineEventEB(probe == "Button:pris" && value == "1")
In debugging I found that it failed when evaluating the value == "1" part. I can also confirm that the value for the actually inserted JasmineEventEB is a string.
The stacktrace is:
{noformat}
java.lang.InstantiationError: java.io.Serializable
at ConditionEvaluatorae1a73837e8146bda23004a0450e2e52.evaluate(Unknown Source)
at org.drools.core.rule.constraint.MvelConstraint.evaluate(MvelConstraint.java:212)
at org.drools.core.rule.constraint.MvelConstraint.isAllowed(MvelConstraint.java:169)
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.AlphaNode.assertObject(AlphaNode.java:138)
at org.drools.core.reteoo.CompositeObjectSinkAdapter.doPropagateAssertObject(CompositeObjectSinkAdapter.java:502)
at org.drools.core.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:377)
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:1149)
at org.drools.core.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:1093)
at org.drools.core.impl.StatefulKnowledgeSessionImpl.insert(StatefulKnowledgeSessionImpl.java:308)
{noformat}
I tested both with the java and mvel dialect with the same result.
Does someone has already encountered this kind of error?
If you need more details or clarifications please let me know.
Thanks & regards,
Loïc
{quote}
--
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, 10 months
[JBoss JIRA] (DROOLS-372) InstantiationError during condition evaluation in Drools 6.0.0.Final
by Loic Albertin (JIRA)
[ https://issues.jboss.org/browse/DROOLS-372?page=com.atlassian.jira.plugin... ]
Loic Albertin updated DROOLS-372:
---------------------------------
Attachment: drools-issue.zip
> InstantiationError during condition evaluation in Drools 6.0.0.Final
> --------------------------------------------------------------------
>
> Key: DROOLS-372
> URL: https://issues.jboss.org/browse/DROOLS-372
> Project: Drools
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 6.0.0.Final
> Environment: reproduced on both jdk 6 and jdk 7
> Reporter: Loic Albertin
> Assignee: Mark Proctor
> Attachments: drools-issue.zip
>
>
> Kindly find bellow the initial discussion from rules-user(a)list.jboss.org
> In addition I attach a sample project that reproduce the error.
> To run it simply type 'mvn clean install exec:java'.
> An interesting thing is that on my environment the issue always appears at the 21st insertion.
> {quote}
> Hi all,
> I'm migrating from an old Drools 5.1 version to 6.0.0.Final. Sometimes (I don't really get under which conditions as sometimes it works), I'm facing an InstantiationError exception when I insert a fact into a stateful kie session. This exception is thrown by a generated class named ConditionEvaluator<UUID> which doesn't help for debugging!
> The inserted object is a basic POJO (named JasmineEventEB) except for an attribute named "value" which accept any "Serializable" object and which is causing the issue.
> The rule condition is quite simple
> $e : JasmineEventEB(probe == "Button:pris" && value == "1")
> In debugging I found that it failed when evaluating the value == "1" part. I can also confirm that the value for the actually inserted JasmineEventEB is a string.
> The stacktrace is:
> {noformat}
> java.lang.InstantiationError: java.io.Serializable
> at ConditionEvaluatorae1a73837e8146bda23004a0450e2e52.evaluate(Unknown Source)
> at org.drools.core.rule.constraint.MvelConstraint.evaluate(MvelConstraint.java:212)
> at org.drools.core.rule.constraint.MvelConstraint.isAllowed(MvelConstraint.java:169)
> 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.AlphaNode.assertObject(AlphaNode.java:138)
> at org.drools.core.reteoo.CompositeObjectSinkAdapter.doPropagateAssertObject(CompositeObjectSinkAdapter.java:502)
> at org.drools.core.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:377)
> 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:1149)
> at org.drools.core.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:1093)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.insert(StatefulKnowledgeSessionImpl.java:308)
> {noformat}
> I tested both with the java and mvel dialect with the same result.
> Does someone has already encountered this kind of error?
> If you need more details or clarifications please let me know.
> Thanks & regards,
> Loïc
> {quote}
--
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, 10 months
[JBoss JIRA] (WFLY-705) Implement a User Agent and Remote Address Filter for the HTTP Management Interface
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFLY-705?page=com.atlassian.jira.plugin.s... ]
Tomaz Cerar commented on WFLY-705:
----------------------------------
Just to make sure we don't have confusion here, jbossweb is not used management interface server in AS7 we use internal sun http server, in wildfly 8 it is managed by undertow (but not undertow subsystem).
> Implement a User Agent and Remote Address Filter for the HTTP Management Interface
> ----------------------------------------------------------------------------------
>
> Key: WFLY-705
> URL: https://issues.jboss.org/browse/WFLY-705
> Project: WildFly
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Domain Management, Security
> Reporter: Darran Lofthouse
> Assignee: Andre Dietisheim
> Fix For: Awaiting Volunteers
>
>
> The HTTP Management interface provides access to manage the domain model, this interface is partly dependent on the protection supplied by an end users web browser.
> This feature request is to optionally filter inbound requests based on a configurable list of supported user agents and or remote addresses - this will mean buggy browser versions can be excluded and remote clients restricted.
> Anyone interested in contributing please feel free to ping darranl in #jboss-as7.
--
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, 10 months
[JBoss JIRA] (WFLY-2619) Enable https port override for Undertow
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFLY-2619?page=com.atlassian.jira.plugin.... ]
Tomaz Cerar reassigned WFLY-2619:
---------------------------------
Assignee: Tomaz Cerar (was: Darran Lofthouse)
> Enable https port override for Undertow
> ---------------------------------------
>
> Key: WFLY-2619
> URL: https://issues.jboss.org/browse/WFLY-2619
> Project: WildFly
> Issue Type: Task
> Security Level: Public(Everyone can see)
> Components: Web (Undertow)
> Affects Versions: 8.0.0.Beta1
> Reporter: Darran Lofthouse
> Assignee: Tomaz Cerar
> Fix For: 8.0.0.CR1
>
>
> At the moment the http to https redirect automatically discovers the port to redirect to - for situations where automatic discovery is not reliable e.g. port forwarding a config options should be provided to specify the redirect port to use.
--
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, 10 months
[JBoss JIRA] (WFLY-2611) Support CDI injection in various JSF artifacts
by Tomas Remes (JIRA)
[ https://issues.jboss.org/browse/WFLY-2611?page=com.atlassian.jira.plugin.... ]
Tomas Remes updated WFLY-2611:
------------------------------
Description:
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|
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||
|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||
> Support CDI injection in various JSF artifacts
> ----------------------------------------------
>
> 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
> Reporter: Tomas Remes
> Assignee: Stuart Douglas
>
> 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|
>
--
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, 10 months
[JBoss JIRA] (JGRP-1753) BlockingInputStream: reading beyond the array's capacity
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1753?page=com.atlassian.jira.plugin.... ]
Bela Ban resolved JGRP-1753.
----------------------------
Resolution: Done
> BlockingInputStream: reading beyond the array's capacity
> --------------------------------------------------------
>
> Key: JGRP-1753
> URL: https://issues.jboss.org/browse/JGRP-1753
> Project: JGroups
> Issue Type: Bug
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 3.4.2, 3.5
>
>
> If a BlockingInputStream {{input}} has a capacity of 8000 and we're calling {{input.read(buf, 0, buf.length)}} on a user buffer of 10000 with 14000 bytes added to {{input}}, then the following can happen:
> * {{input}} reads the first 8000 bytes and copies them to the user's buffer
> * The write position for the user's buffer is now at 8000 and the max number of bytes to be added is 2000 bytes, even if we have another 6000 bytes !
> * Instead of adding another 2000 bytes, we add another 6000 bytes, leading to an ArrayIndexOutOfBoundsException
> SOLUTION: the length of the remaining bytes has to be min(available, remaining space in user's buffer).
> The unit test is {{BlockingInputStreamTest.testWritingBeyondLength()}}
--
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, 10 months