[JBoss JIRA] (WFLY-4349) SEVERE JSF error on undeploy of WS module after Mojarra upgrade to 2.2.10
by Farah Juma (JIRA)
[ https://issues.jboss.org/browse/WFLY-4349?page=com.atlassian.jira.plugin.... ]
Farah Juma resolved WFLY-4349.
------------------------------
Fix Version/s: 9.0.0.Beta1
Resolution: Done
> SEVERE JSF error on undeploy of WS module after Mojarra upgrade to 2.2.10
> -------------------------------------------------------------------------
>
> Key: WFLY-4349
> URL: https://issues.jboss.org/browse/WFLY-4349
> Project: WildFly
> Issue Type: Bug
> Components: JSF
> Affects Versions: 9.0.0.Alpha1
> Environment: WildFly Full 9.0.0.Alpha2-SNAPSHOT (WildFly Core 1.0.0.Alpha18)
> Oracle JDK 1.7.0_80-ea-b05, Solaris SPARC 10
> Reporter: Frank Langelage
> Assignee: Farah Juma
> Labels: mojarra, undertow
> Fix For: 9.0.0.Beta1
>
>
> Since latest update I get a SEVERE entry in server.log for every web-module getting undeployed. Those Web-modules contain webservices and are war files inside and ear.
> 15.02. 21:31:48,151 INFO [org.wildfly.extension.undertow#unregisterDeployment] WFLYUT0022: Unregistered web context: /mbi-ws/maj2e-langfr-dev/production
> 15.02. 21:31:48,151 INFO [org.wildfly.extension.undertow#unregisterDeployment] WFLYUT0022: Unregistered web context: /mbi/maj2e-langfr-dev/web
> 15.02. 21:31:48,155 SEVERE [javax.enterprise.resource.webcontainer.jsf.config#contextDestroyed] Unexpected state during contextDestroyed: no ConfigManager instance in current ServletContext but one is expected to exist.
> 15.02. 21:31:48,201 INFO [org.wildfly.extension.undertow#unregisterDeployment] WFLYUT0022: Unregistered web context: /mbi-ws/maj2e-langfr-dev/planning
> 15.02. 21:31:48,204 SEVERE [javax.enterprise.resource.webcontainer.jsf.config#contextDestroyed] Unexpected state during contextDestroyed: no ConfigManager instance in current ServletContext but one is expected to exist.
> 15.02. 21:31:48,239 SEVERE [javax.enterprise.resource.webcontainer.jsf.config#contextDestroyed] Unexpected state during contextDestroyed: no ConfigManager instance in current ServletContext but one is expected to exist.
> 15.02. 21:31:48,217 INFO [org.wildfly.extension.undertow#unregisterDeployment] WFLYUT0022: Unregistered web context: /mbi-ws/maj2e-langfr-dev/core
> 15.02. 21:31:48,359 INFO [org.wildfly.extension.undertow#unregisterDeployment] WFLYUT0022: Unregistered web context: /mbi-ws/maj2e-langfr-dev/sales
> 15.02. 21:31:48,372 INFO [org.wildfly.extension.undertow#unregisterDeployment] WFLYUT0022: Unregistered web context: /mbi-ws/maj2e-langfr-dev/costing
> 15.02. 21:31:48,379 INFO [org.wildfly.extension.undertow#unregisterDeployment] WFLYUT0022: Unregistered web context: /mbi-ws/maj2e-langfr-dev/purchase
> 15.02. 21:31:48,381 SEVERE [javax.enterprise.resource.webcontainer.jsf.config#contextDestroyed] Unexpected state during contextDestroyed: no ConfigManager instance in current ServletContext but one is expected to exist.
> 15.02. 21:31:48,383 INFO [org.wildfly.extension.undertow#unregisterDeployment] WFLYUT0022: Unregistered web context: /mbi-ws/maj2e-langfr-dev/external
> 15.02. 21:31:48,396 SEVERE [javax.enterprise.resource.webcontainer.jsf.config#contextDestroyed] Unexpected state during contextDestroyed: no ConfigManager instance in current ServletContext but one is expected to exist.
> 15.02. 21:31:48,397 SEVERE [javax.enterprise.resource.webcontainer.jsf.config#contextDestroyed] Unexpected state during contextDestroyed: no ConfigManager instance in current ServletContext but one is expected to exist.
> 15.02. 21:31:48,399 SEVERE [javax.enterprise.resource.webcontainer.jsf.config#contextDestroyed] Unexpected state during contextDestroyed: no ConfigManager instance in current ServletContext but one is expected to exist.
> 15.02. 21:31:48,402 INFO [org.wildfly.extension.undertow#unregisterDeployment] WFLYUT0022: Unregistered web context: /mbi-ws/maj2e-langfr-dev/inventory
> 15.02. 21:31:48,444 SEVERE [javax.enterprise.resource.webcontainer.jsf.config#contextDestroyed] Unexpected state during contextDestroyed: no ConfigManager instance in current ServletContext but one is expected to exist.
> 15.02. 21:31:48,404 INFO [org.wildfly.extension.undertow#unregisterDeployment] WFLYUT0022: Unregistered web context: /mbi-ws/maj2e-langfr-dev/common
> 15.02. 21:31:48,407 INFO [org.wildfly.extension.undertow#unregisterDeployment] WFLYUT0022: Unregistered web context: /mbi-ws/maj2e-langfr-dev/distribution
> 15.02. 21:31:48,408 SEVERE [javax.enterprise.resource.webcontainer.jsf.config#contextDestroyed] Unexpected state during contextDestroyed: no ConfigManager instance in current ServletContext but one is expected to exist.
> 15.02. 21:31:48,480 SEVERE [javax.enterprise.resource.webcontainer.jsf.config#contextDestroyed] Unexpected state during contextDestroyed: no ConfigManager instance in current ServletContext but one is expected to exist.
> 15.02. 21:31:48,481 SEVERE [javax.enterprise.resource.webcontainer.jsf.config#contextDestroyed] Unexpected state during contextDestroyed: no ConfigManager instance in current ServletContext but one is expected to exist.
> Undeploy of my war file does not generate this SEVERE error.
> 15.02. 21:43:24,243 INFO [org.wildfly.extension.undertow#unregisterDeployment] WFLYUT0022: Unregistered web context: /web-maj2e-langfr-dev
> When I go back to the previous Mojarra 2.2.9-jbossorg-2 the error message disappears.
> There are also a lot of theses SEVERE error messages in the testsuite output files (*.txt).
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 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.3.0.Beta1
(was: 6.2.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
> 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.3.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.3.11#6341)
11 years, 3 months
[JBoss JIRA] (DROOLS-669) Create "behavesAs" operator to support traiting
by Michael Biarnes Kiefer (JIRA)
[ https://issues.jboss.org/browse/DROOLS-669?page=com.atlassian.jira.plugin... ]
Michael Biarnes Kiefer updated DROOLS-669:
------------------------------------------
Fix Version/s: 6.3.0.Beta1
(was: 6.2.0.Final)
> Create "behavesAs" operator to support traiting
> -----------------------------------------------
>
> Key: DROOLS-669
> URL: https://issues.jboss.org/browse/DROOLS-669
> Project: Drools
> Issue Type: Feature Request
> Affects Versions: 6.2.0.CR3
> Reporter: Davide Sottara
> Assignee: Davide Sottara
> Fix For: 6.3.0.Beta1
>
>
> Define an operator that would check if an object can provide *natively* all the methods required by an interface. This would ensure that, upon donning the interface as a trait, no soft field would be required, and that all methods in the interface would have a concrete implementation.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months
[JBoss JIRA] (DROOLS-607) Match.getObjects() should reflect the patterns' order
by Michael Biarnes Kiefer (JIRA)
[ https://issues.jboss.org/browse/DROOLS-607?page=com.atlassian.jira.plugin... ]
Michael Biarnes Kiefer updated DROOLS-607:
------------------------------------------
Fix Version/s: 6.3.0.Beta1
(was: 6.2.0.Final)
> Match.getObjects() should reflect the patterns' order
> -----------------------------------------------------
>
> Key: DROOLS-607
> URL: https://issues.jboss.org/browse/DROOLS-607
> Project: Drools
> Issue Type: Enhancement
> Affects Versions: 5.5.0.Final, 5.6.0.Final, 6.0.0.Final, 6.1.0.Final
> Reporter: Davide Sottara
> Assignee: Mark Proctor
> Priority: Minor
> Fix For: 6.3.0.Beta1
>
>
> if Match.getObjects() is called on a rule with LHS A() B() C(),
> the resulting list will have the matching objects in reversed order
> - that is, [c, b, a] - making it more difficult to analyze it.
> The object's position in the list should reflect the LHS.
> The order should be preserved even when subnetworks are present.
> For example, A() not B() C() should then result in the list [a, *, c ]
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months
[JBoss JIRA] (DROOLS-569) Property reactivity prevents index update
by Michael Biarnes Kiefer (JIRA)
[ https://issues.jboss.org/browse/DROOLS-569?page=com.atlassian.jira.plugin... ]
Michael Biarnes Kiefer updated DROOLS-569:
------------------------------------------
Fix Version/s: 6.3.0.Beta1
(was: 6.2.0.Final)
> Property reactivity prevents index update
> -----------------------------------------
>
> Key: DROOLS-569
> URL: https://issues.jboss.org/browse/DROOLS-569
> Project: Drools
> Issue Type: Bug
> Reporter: Mario Fusco
> Assignee: Mario Fusco
> Labels: backport-to-6.0.x
> Fix For: 6.3.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.3.11#6341)
11 years, 3 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.3.0.Beta1
(was: 6.2.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
> Affects Versions: 6.1.0.Beta2
> Reporter: Geoffrey De Smet
> Assignee: Michael Anstis
> Fix For: 6.3.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.3.11#6341)
11 years, 3 months
[JBoss JIRA] (DROOLS-680) "contains" operator behaves inconsistently when used with Maps
by Michael Biarnes Kiefer (JIRA)
[ https://issues.jboss.org/browse/DROOLS-680?page=com.atlassian.jira.plugin... ]
Michael Biarnes Kiefer updated DROOLS-680:
------------------------------------------
Fix Version/s: 6.3.0.Beta1
(was: 6.2.0.Final)
> "contains" operator behaves inconsistently when used with Maps
> --------------------------------------------------------------
>
> Key: DROOLS-680
> URL: https://issues.jboss.org/browse/DROOLS-680
> Project: Drools
> Issue Type: Bug
> Affects Versions: 5.6.0.Final, 6.0.1.Final, 6.1.0.Final, 6.2.0.CR4
> Reporter: Davide Sottara
> Assignee: Mario Fusco
> Fix For: 6.3.0.Beta1
>
>
> In a rule
> {code}
> Bean( map contains "x" ) // assuming "map" is a property of type Map
> {code}
> "contains" is arbitrarily interpreted as "containsKey"
> The constrain will then fail after being jitted
> The documentation explicitly states that "contains" applies to collections
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months