[JBoss JIRA] (WFLY-3694) StateHolderSaver behaves incorrectly when object is neither StateHolder nor Serializable
by Rich DiCroce (JIRA)
Rich DiCroce created WFLY-3694:
----------------------------------
Summary: StateHolderSaver behaves incorrectly when object is neither StateHolder nor Serializable
Key: WFLY-3694
URL: https://issues.jboss.org/browse/WFLY-3694
Project: WildFly
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: JSF
Affects Versions: 8.1.0.Final
Reporter: Rich DiCroce
Assignee: Farah Juma
javax.faces.component.StateHolderSaver does not work properly if the object to be saved does not implement Serializable or StateHolder. Such an object will cause the below exception, if the class does not have a public no-arg constructor.
This issue was already filed with Mojarra as JAVASERVERFACES-1716 by someone else and was closed as Won't Fix. I am not sure why, given that the proposed fix should work and the last comment is completely wrong. But I figure a JBoss developer has a better chance of getting this resolved than I do.
As a workaround, I am declaring a public no-arg constructor, but that risks someone else using it without understanding why it's there.
{noformat}
2014-07-30 13:55:58,201 ERROR [com.lapis.jsf.framework.ui.exception.FrameworkExceptionHandler] (default task-66) Exception ID 1631720075: javax.faces.FacesException: Unexpected error restoring state for component with id j_idt27:analyzerTable. Cause: java.lang.IllegalStateException: java.lang.InstantiationException: com.sg.song.nms.analyzer.field.ViewElementQueryField.
at com.sun.faces.application.view.FaceletPartialStateManagementStrategy$2.visit(FaceletPartialStateManagementStrategy.java:387) [jsf-impl-2.2.6-jbossorg-4.jar:]
at com.sun.faces.component.visit.FullVisitContext.invokeVisitCallback(FullVisitContext.java:151) [jsf-impl-2.2.6-jbossorg-4.jar:]
at org.primefaces.component.api.UIData.visitTree(UIData.java:692) [primefaces-5.0.jar:5.0]
at javax.faces.component.UIComponent.visitTree(UIComponent.java:1701) [jboss-jsf-api_2.2_spec-2.2.6.jar:2.2.6]
at javax.faces.component.UIForm.visitTree(UIForm.java:371) [jboss-jsf-api_2.2_spec-2.2.6.jar:2.2.6]
at javax.faces.component.UIComponent.visitTree(UIComponent.java:1701) [jboss-jsf-api_2.2_spec-2.2.6.jar:2.2.6]
at javax.faces.component.UIComponent.visitTree(UIComponent.java:1701) [jboss-jsf-api_2.2_spec-2.2.6.jar:2.2.6]
at com.sun.faces.application.view.FaceletPartialStateManagementStrategy.restoreView(FaceletPartialStateManagementStrategy.java:367) [jsf-impl-2.2.6-jbossorg-4.jar:]
at com.sun.faces.application.StateManagerImpl.restoreView(StateManagerImpl.java:138) [jsf-impl-2.2.6-jbossorg-4.jar:]
at com.sun.faces.application.view.ViewHandlingStrategy.restoreView(ViewHandlingStrategy.java:123) [jsf-impl-2.2.6-jbossorg-4.jar:]
at com.sun.faces.application.view.FaceletViewHandlingStrategy.restoreView(FaceletViewHandlingStrategy.java:590) [jsf-impl-2.2.6-jbossorg-4.jar:]
at com.sun.faces.application.view.MultiViewHandler.restoreView(MultiViewHandler.java:150) [jsf-impl-2.2.6-jbossorg-4.jar:]
at javax.faces.application.ViewHandlerWrapper.restoreView(ViewHandlerWrapper.java:353) [jboss-jsf-api_2.2_spec-2.2.6.jar:2.2.6]
at javax.faces.application.ViewHandlerWrapper.restoreView(ViewHandlerWrapper.java:353) [jboss-jsf-api_2.2_spec-2.2.6.jar:2.2.6]
at org.omnifaces.viewhandler.RestorableViewHandler.restoreView(RestorableViewHandler.java:66) [omnifaces-1.8.1.jar:1.8.1-20140603]
at javax.faces.application.ViewHandlerWrapper.restoreView(ViewHandlerWrapper.java:353) [jboss-jsf-api_2.2_spec-2.2.6.jar:2.2.6]
at javax.faces.application.ViewHandlerWrapper.restoreView(ViewHandlerWrapper.java:353) [jboss-jsf-api_2.2_spec-2.2.6.jar:2.2.6]
at com.sun.faces.lifecycle.RestoreViewPhase.execute(RestoreViewPhase.java:197) [jsf-impl-2.2.6-jbossorg-4.jar:]
at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101) [jsf-impl-2.2.6-jbossorg-4.jar:]
at com.sun.faces.lifecycle.RestoreViewPhase.doPhase(RestoreViewPhase.java:121) [jsf-impl-2.2.6-jbossorg-4.jar:]
at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:198) [jsf-impl-2.2.6-jbossorg-4.jar:]
at org.apache.deltaspike.jsf.impl.listener.request.DeltaSpikeLifecycleWrapper.execute(DeltaSpikeLifecycleWrapper.java:89) [deltaspike-jsf-module-impl-1.0.1.jar:1.0.1]
at javax.faces.lifecycle.LifecycleWrapper.execute(LifecycleWrapper.java:77) [jboss-jsf-api_2.2_spec-2.2.6.jar:2.2.6]
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:646) [jboss-jsf-api_2.2_spec-2.2.6.jar:2.2.6]
at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:130) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
at io.undertow.websockets.jsr.JsrWebSocketFilter.doFilter(JsrWebSocketFilter.java:123) [undertow-websockets-jsr-1.0.15.Final.jar:1.0.15.Final]
at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
at io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:85) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:61) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:113) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:56) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:61) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:70) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:240) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:227) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:73) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:146) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
at io.undertow.server.Connectors.executeRootHandler(Connectors.java:177) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:727) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_05]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_05]
at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_05]
Caused by: java.lang.IllegalStateException: java.lang.InstantiationException: com.sg.song.nms.analyzer.field.ViewElementQueryField
at javax.faces.component.StateHolderSaver.restore(StateHolderSaver.java:153) [jboss-jsf-api_2.2_spec-2.2.6.jar:2.2.6]
at javax.faces.component.ComponentStateHelper.restoreState(ComponentStateHelper.java:306) [jboss-jsf-api_2.2_spec-2.2.6.jar:2.2.6]
at javax.faces.component.UIComponentBase.restoreState(UIComponentBase.java:1621) [jboss-jsf-api_2.2_spec-2.2.6.jar:2.2.6]
at javax.faces.component.UIData.restoreState(UIData.java:1750) [jboss-jsf-api_2.2_spec-2.2.6.jar:2.2.6]
at com.sun.faces.application.view.FaceletPartialStateManagementStrategy$2.visit(FaceletPartialStateManagementStrategy.java:380) [jsf-impl-2.2.6-jbossorg-4.jar:]
... 54 more
Caused by: java.lang.InstantiationException: com.sg.song.nms.analyzer.field.ViewElementQueryField
at java.lang.Class.newInstance(Class.java:418) [rt.jar:1.8.0_05]
at javax.faces.component.StateHolderSaver.restore(StateHolderSaver.java:150) [jboss-jsf-api_2.2_spec-2.2.6.jar:2.2.6]
... 58 more
Caused by: java.lang.NoSuchMethodException: com.sg.song.nms.analyzer.field.ViewElementQueryField.<init>()
at java.lang.Class.getConstructor0(Class.java:2971) [rt.jar:1.8.0_05]
at java.lang.Class.newInstance(Class.java:403) [rt.jar:1.8.0_05]
... 59 more
{noformat}
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
10 years, 6 months
[JBoss JIRA] (JGRP-1864) UDP unable to bind to ephemeral port: port out of range:65536
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1864?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-1864:
--------------------------------
ah, different error, thanks Ion I should be able to reproduce this.
> UDP unable to bind to ephemeral port: port out of range:65536
> -------------------------------------------------------------
>
> Key: JGRP-1864
> URL: https://issues.jboss.org/browse/JGRP-1864
> Project: JGroups
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 3.4.4
> Reporter: Dan Berindei
> Assignee: Bela Ban
> Priority: Minor
> Fix For: 3.4.5, 3.5
>
>
> It looks like {{UDP.createEphemeralDatagramSocket()}} swallows any errors it gets while creating the socket, and throws this exception after trying to bind to all ports in the 0 - 65535 range:
> {noformat}
> java.lang.IllegalArgumentException: port out of range:65536
> at java.net.InetSocketAddress.checkPort(InetSocketAddress.java:143)
> at java.net.InetSocketAddress.<init>(InetSocketAddress.java:185)
> at java.net.DatagramSocket.<init>(DatagramSocket.java:284)
> at org.jgroups.util.DefaultSocketFactory.createDatagramSocket(DefaultSocketFactory.java:62)
> at org.jgroups.protocols.UDP.createEphemeralDatagramSocket(UDP.java:429)
> at org.jgroups.protocols.UDP.createSockets(UDP.java:311)
> at org.jgroups.protocols.UDP.start(UDP.java:216)
> at org.jgroups.stack.ProtocolStack.startStack(ProtocolStack.java:966)
> at org.jgroups.JChannel.startStack(JChannel.java:889)
> at org.jgroups.JChannel._preConnect(JChannel.java:547)
> at org.jgroups.JChannel.connect(JChannel.java:282)
> at org.jgroups.JChannel.connect(JChannel.java:273)
> at org.infinispan.remoting.transport.jgroups.JGroupsTransport.startJGroupsChannelIfNeeded(JGroupsTransport.java:200)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
10 years, 6 months
[JBoss JIRA] (DROOLS-569) Property reactivity prevents index update
by Mario Fusco (JIRA)
[ https://issues.jboss.org/browse/DROOLS-569?page=com.atlassian.jira.plugin... ]
Mario Fusco reopened DROOLS-569:
--------------------------------
This fix is not thread safe. In particular the beta memory shouldn't be changed from the alpha network (user thread).
More in general we found we also have a potential race condition since the alpha network can change the PropagationContext inside a RightTuple while the beta network is using it. For now the only suggested solution is making the pctx inside the RightTuple immutable and cloning the whole RT when it is necessary to change it. However this is still under discussion.
> Property reactivity prevents index update
> -----------------------------------------
>
> Key: DROOLS-569
> URL: https://issues.jboss.org/browse/DROOLS-569
> Project: Drools
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Reporter: Mario Fusco
> Assignee: Mario Fusco
> Labels: backport-to-6.0.x
> Fix For: 6.2.0.Beta1
>
>
> When a property is part of the pattern matching it can anyway be excluded from the property reactivity with a negative watch. Anyway if the property is also indexed this implies that when the fact is modified it skips not only the modification propagation (as requested) but also the update of the corresponding index causing an inconsistency.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
10 years, 6 months
[JBoss JIRA] (DROOLS-329) ClassFormatException when compile template with latest JDK8 (b114)
by Michael Biarnes Kiefer (JIRA)
[ https://issues.jboss.org/browse/DROOLS-329?page=com.atlassian.jira.plugin... ]
Michael Biarnes Kiefer updated DROOLS-329:
------------------------------------------
Fix Version/s: 6.2.0.Beta1
(was: 6.1.0.Final)
> ClassFormatException when compile template with latest JDK8 (b114)
> ------------------------------------------------------------------
>
> Key: DROOLS-329
> URL: https://issues.jboss.org/browse/DROOLS-329
> Project: Drools
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 5.5.0.Final, 6.0.0.CR5
> Environment: Ubuntu linux, latest JDK1.8 (b114) downloaded from https://jdk8.java.net/download.html
> Reporter: Marek Posolda
> Assignee: Mark Proctor
> Fix For: 5.5.1.Final, 6.2.0.Beta1
>
>
> When trying to run code for compile templates with latest JDK8 (For instance this example https://github.com/droolsjbpm/drools/blob/master/drools-examples/src/main... )
> it will throw an exception like this:
> {code}
> Exception in thread "main" java.lang.RuntimeException: java.lang.RuntimeException: wrong class format
> at org.drools.template.parser.DefaultTemplateRuleBase.readRule(DefaultTemplateRuleBase.java:148)
> at org.drools.template.parser.DefaultTemplateRuleBase.<init>(DefaultTemplateRuleBase.java:62)
> at org.drools.template.parser.TemplateDataListener.<init>(TemplateDataListener.java:74)
> at org.drools.decisiontable.ExternalSpreadsheetCompiler.compile(ExternalSpreadsheetCompiler.java:95)
> at org.drools.decisiontable.ExternalSpreadsheetCompiler.compile(ExternalSpreadsheetCompiler.java:81)
> at org.drools.examples.templates.SimpleRuleTemplateExample.buildKBase(SimpleRuleTemplateExample.java:84)
> at org.drools.examples.templates.SimpleRuleTemplateExample.executeExample(SimpleRuleTemplateExample.java:49)
> at org.drools.examples.templates.SimpleRuleTemplateExample.main(SimpleRuleTemplateExample.java:43)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:483)
> at com.intellij.rt.execution.application.AppMain.main(AppMain.java:120)
> Caused by: java.lang.RuntimeException: wrong class format
> at org.drools.commons.jci.compilers.EclipseJavaCompiler$2.findType(EclipseJavaCompiler.java:263)
> at org.drools.commons.jci.compilers.EclipseJavaCompiler$2.findType(EclipseJavaCompiler.java:203)
> at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.askForType(LookupEnvironment.java:102)
> at org.eclipse.jdt.internal.compiler.lookup.UnresolvedReferenceBinding.resolve(UnresolvedReferenceBinding.java:49)
> at org.eclipse.jdt.internal.compiler.lookup.BinaryTypeBinding.resolveType(BinaryTypeBinding.java:122)
> at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.getTypeFromTypeSignature(LookupEnvironment.java:1188)
> at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.getTypeFromVariantTypeSignature(LookupEnvironment.java:1244)
> at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.getTypeArgumentsFromSignature(LookupEnvironment.java:1031)
> at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.getTypeFromTypeSignature(LookupEnvironment.java:1193)
> at org.eclipse.jdt.internal.compiler.lookup.BinaryTypeBinding.createMethod(BinaryTypeBinding.java:495)
> at org.eclipse.jdt.internal.compiler.lookup.BinaryTypeBinding.createMethods(BinaryTypeBinding.java:577)
> at org.eclipse.jdt.internal.compiler.lookup.BinaryTypeBinding.cachePartsFrom(BinaryTypeBinding.java:327)
> at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.createBinaryTypeFrom(LookupEnvironment.java:640)
> at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.createBinaryTypeFrom(LookupEnvironment.java:619)
> at org.eclipse.jdt.internal.compiler.Compiler.accept(Compiler.java:295)
> at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.askForType(LookupEnvironment.java:133)
> at org.eclipse.jdt.internal.compiler.lookup.PackageBinding.getTypeOrPackage(PackageBinding.java:183)
> at org.eclipse.jdt.internal.compiler.lookup.CompilationUnitScope.findImport(CompilationUnitScope.java:465)
> at org.eclipse.jdt.internal.compiler.lookup.CompilationUnitScope.findSingleImport(CompilationUnitScope.java:519)
> at org.eclipse.jdt.internal.compiler.lookup.CompilationUnitScope.faultInImports(CompilationUnitScope.java:368)
> at org.eclipse.jdt.internal.compiler.lookup.CompilationUnitScope.faultInTypes(CompilationUnitScope.java:444)
> at org.eclipse.jdt.internal.compiler.Compiler.process(Compiler.java:752)
> at org.eclipse.jdt.internal.compiler.Compiler.compile(Compiler.java:464)
> at org.drools.commons.jci.compilers.EclipseJavaCompiler.compile(EclipseJavaCompiler.java:389)
> at org.drools.commons.jci.compilers.AbstractJavaCompiler.compile(AbstractJavaCompiler.java:49)
> at org.drools.rule.builder.dialect.java.JavaDialect.compileAll(JavaDialect.java:371)
> at org.drools.compiler.DialectCompiletimeRegistry.compileAll(DialectCompiletimeRegistry.java:46)
> at org.drools.compiler.PackageRegistry.compileAll(PackageRegistry.java:102)
> at org.drools.compiler.PackageBuilder.compileAll(PackageBuilder.java:1006)
> at org.drools.compiler.PackageBuilder.compileAllRules(PackageBuilder.java:842)
> at org.drools.compiler.PackageBuilder.addPackage(PackageBuilder.java:831)
> at org.drools.compiler.PackageBuilder.addPackageFromDrl(PackageBuilder.java:441)
> at org.drools.compiler.PackageBuilder.addPackageFromDrl(PackageBuilder.java:419)
> at org.drools.template.parser.DefaultTemplateRuleBase.readRule(DefaultTemplateRuleBase.java:139)
> ... 12 more
> Caused by: org.eclipse.jdt.internal.compiler.classfmt.ClassFormatException
> at org.eclipse.jdt.internal.compiler.classfmt.ClassFileReader.<init>(ClassFileReader.java:372)
> at org.drools.commons.jci.compilers.EclipseJavaCompiler$2.createNameEnvironmentAnswer(EclipseJavaCompiler.java:287)
> at org.drools.commons.jci.compilers.EclipseJavaCompiler$2.findType(EclipseJavaCompiler.java:258)
> ... 45 more
> {code}
> Workaround, which worked for me is to switch to Janino compiler (See Workaround description)
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
10 years, 6 months
[JBoss JIRA] (DROOLS-470) Decision Table (XLS) should support fixed conditions, such as SeatDesignation(isNeighborOf($guest))
by Michael Biarnes Kiefer (JIRA)
[ https://issues.jboss.org/browse/DROOLS-470?page=com.atlassian.jira.plugin... ]
Michael Biarnes Kiefer updated DROOLS-470:
------------------------------------------
Fix Version/s: 6.2.0.Beta1
(was: 6.1.0.Final)
> Decision Table (XLS) should support fixed conditions, such as SeatDesignation(isNeighborOf($guest))
> ---------------------------------------------------------------------------------------------------
>
> Key: DROOLS-470
> URL: https://issues.jboss.org/browse/DROOLS-470
> Project: Drools
> Issue Type: Enhancement
> Security Level: Public(Everyone can see)
> Affects Versions: 6.1.0.Beta2
> Reporter: Geoffrey De Smet
> Assignee: Michael Anstis
> Fix For: 6.2.0.Beta1
>
>
> This DT should work:
> ||CONDITION||CONDITION||ACTION|
> |$guest : SeatDesignation()|$neighbor : SeatDesignation(isNeighborOf($guest))||
> |guestName == "$param"|guestName == "$param"|doSomething();|
> It crashes because of the "SeatDesignation(isNeighborOf($guest))". Only empty parenthesis are allowed.
> Failing workaround 1: This workaround (as specified by the docs), does NOT work well, because it adds the same condition (isNeighborOf($guest)) multiple times in the same rule:
> ||CONDITION||CONDITION||CONDITION||ACTION|
> |$guest : SeatDesignation()|$neighbor : SeatDesignation()|||
> |guestName == "$param"|isNeighborOf($guest), guestName == "$param"|isNeighborOf($guest), guestAge == "$param"|doSomething();|
> Failing workaround 2: Adding an extra, hidden column with that condition does not work when new rows are added because condition columns with an empty cell are ignored.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
10 years, 6 months
[JBoss JIRA] (DROOLS-448) Traiting non-declared POJOS prevents the execution of WM actions from outside the WM
by Michael Biarnes Kiefer (JIRA)
[ https://issues.jboss.org/browse/DROOLS-448?page=com.atlassian.jira.plugin... ]
Michael Biarnes Kiefer updated DROOLS-448:
------------------------------------------
Fix Version/s: 6.2.0.Beta1
(was: 6.1.0.Final)
> Traiting non-declared POJOS prevents the execution of WM actions from outside the WM
> ------------------------------------------------------------------------------------
>
> Key: DROOLS-448
> URL: https://issues.jboss.org/browse/DROOLS-448
> Project: Drools
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 5.6.0.Final, 6.0.0.Final, 6.0.1.Final, 6.1.0.Beta1
> Reporter: Davide Sottara
> Assignee: Davide Sottara
> Priority: Critical
> Fix For: 6.2.0.Beta1
>
>
> When a trait is applied to non-declared bean, a transparent proxy is created and the handle is updated accordingly. However, this prevents the lookup of the handle using the original object as a key.
> The proxy creation should be avoided.
> See also PLANNER-229
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
10 years, 6 months
[JBoss JIRA] (DROOLS-546) FactType.get/set should throw specific exception (not NPE) for unknown fields
by Michael Biarnes Kiefer (JIRA)
[ https://issues.jboss.org/browse/DROOLS-546?page=com.atlassian.jira.plugin... ]
Michael Biarnes Kiefer updated DROOLS-546:
------------------------------------------
Fix Version/s: 6.2.0.Beta1
(was: 6.1.0.Final)
> FactType.get/set should throw specific exception (not NPE) for unknown fields
> -----------------------------------------------------------------------------
>
> Key: DROOLS-546
> URL: https://issues.jboss.org/browse/DROOLS-546
> Project: Drools
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 6.1.0.CR1
> Reporter: Benoit Voisin
> Assignee: Mario Fusco
> Fix For: 6.2.0.Beta1
>
>
> factType.get(instance, "unknownField") is currently throwing an NPE. This gives improper information to the user/developper.
> I propose that it throws a new UnknownFactFieldException giving improved information giving good hints for debugging or enabling specific exception management.
> See pull request for test-case and proposed fix
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
10 years, 6 months