[JBoss JIRA] (DROOLS-329) ClassFormatException when compile template with latest JDK8 (b114)
by Joel Njanga (JIRA)
[ https://issues.jboss.org/browse/DROOLS-329?page=com.atlassian.jira.plugin... ]
Joel Njanga edited comment on DROOLS-329 at 2/27/15 2:46 PM:
-------------------------------------------------------------
Version 4.4.1 of org.eclipse.jdt.core.compiler:ecj fixes this for us too. We are using Drools 5.0.1 and Jdk1.8u31.
However, we can't wait until this ticket is officially resolved.
Thanks.
was (Author: joel.njanga):
Version 4.4.1 of org.eclipse.jdt.core.compiler:ecj works fixes this for us too. We are using Drools 5.0.1 and Jdk1.8u31.
However, we can't wait until this ticket is officially resolved.
Thanks.
> 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.2.0.Final
>
>
> 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)
6 years, 6 months
[JBoss JIRA] (DROOLS-329) ClassFormatException when compile template with latest JDK8 (b114)
by Joel Njanga (JIRA)
[ https://issues.jboss.org/browse/DROOLS-329?page=com.atlassian.jira.plugin... ]
Joel Njanga commented on DROOLS-329:
------------------------------------
Version 4.4.1 of org.eclipse.jdt.core.compiler:ecj works fixes this for us too. We are using Drools 5.0.1 and Jdk1.8u31.
However, we can't wait until this ticket is officially resolved.
Thanks.
> 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.2.0.Final
>
>
> 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)
6 years, 6 months
[JBoss JIRA] (DROOLS-731) In a catch22 using a NOT constraint in rules shared by multiple facts
by Bill Tuminaro (JIRA)
[ https://issues.jboss.org/browse/DROOLS-731?page=com.atlassian.jira.plugin... ]
Bill Tuminaro updated DROOLS-731:
---------------------------------
Issue Type: Bug (was: Feature Request)
> In a catch22 using a NOT constraint in rules shared by multiple facts
> ---------------------------------------------------------------------
>
> Key: DROOLS-731
> URL: https://issues.jboss.org/browse/DROOLS-731
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 6.0.1.Final, 6.1.0.Final
> Environment: Custom application that completely wraps Drools Fusion written as an OSGI application hosted on Websphere Liberty profile.
> Reporter: Bill Tuminaro
> Assignee: Mario Fusco
> Attachments: DROOLS-731_DroolsTestCases.zip
>
>
> I have a reproducer for these related issues.
> We have encountered a couple of issues (Exceptions) when using a NOT constraint in rules that have facts associated with them when we call upgradeToVersion() or kSession.delete(). The catch22 is that one version of the NOT constraint avoids one Exception while causing another. Reproducing the issue requires 2 rules sharing the same NOT constraint. I have narrowed the issue(s) down to 2 very simple rules that use the org.drools.compiler.FactA class.
> Here are the 2 rules used:
> static final String ruleDrl = "package org.some.test\n" +
> "import org.drools.compiler.FactA\n" +
> "declare FactA\n" +
> "@role(event)" +
> "end\n" +
> "rule \"R200_0\" when\n" +
> // " $FactA : FactA ($FactA_field2 : field2 == 111002)\n" + // version A: using this version causes a NPE when calling ksession.delete()
> " not FactA($FactA_field2 == 111002, this after $FactA)\n" +
> " not FactA(field2 == 105742, this after $FactA)\n" + // Version B: using this version causes the IllegalArgumentException: Cannot remove a sink,
> // when the list of sinks is null on the updateToVersion() call
> "then\n" +
> "end\n";
> static final String ruleDrl2 = "package org.some.test\n" +
> "import org.drools.compiler.FactA\n" +
> "declare FactA\n" +
> "@role(event)" +
> "end\n" +
> "rule \"R1437_0\" when\n" +
> " $FactA : FactA ($FactA_field2 : field2 == 105742)\n" +
> " not FactA($FactA_field2 == 105742, this after $FactA)\n" + // version A:
> // " not FactA(field2 == 105742, this after $FactA)\n" + // Version B:
> "then\n" +
> "end\n";
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
6 years, 6 months
[JBoss JIRA] (DROOLS-731) In a catch22 using a NOT constraint in rules shared by multiple facts
by Bill Tuminaro (JIRA)
[ https://issues.jboss.org/browse/DROOLS-731?page=com.atlassian.jira.plugin... ]
Bill Tuminaro updated DROOLS-731:
---------------------------------
Attachment: DROOLS-731_DroolsTestCases.zip
> In a catch22 using a NOT constraint in rules shared by multiple facts
> ---------------------------------------------------------------------
>
> Key: DROOLS-731
> URL: https://issues.jboss.org/browse/DROOLS-731
> Project: Drools
> Issue Type: Feature Request
> Components: core engine
> Affects Versions: 6.0.1.Final, 6.1.0.Final
> Environment: Custom application that completely wraps Drools Fusion written as an OSGI application hosted on Websphere Liberty profile.
> Reporter: Bill Tuminaro
> Assignee: Mario Fusco
> Attachments: DROOLS-731_DroolsTestCases.zip
>
>
> I have a reproducer for these related issues.
> We have encountered a couple of issues (Exceptions) when using a NOT constraint in rules that have facts associated with them when we call upgradeToVersion() or kSession.delete(). The catch22 is that one version of the NOT constraint avoids one Exception while causing another. Reproducing the issue requires 2 rules sharing the same NOT constraint. I have narrowed the issue(s) down to 2 very simple rules that use the org.drools.compiler.FactA class.
> Here are the 2 rules used:
> static final String ruleDrl = "package org.some.test\n" +
> "import org.drools.compiler.FactA\n" +
> "declare FactA\n" +
> "@role(event)" +
> "end\n" +
> "rule \"R200_0\" when\n" +
> // " $FactA : FactA ($FactA_field2 : field2 == 111002)\n" + // version A: using this version causes a NPE when calling ksession.delete()
> " not FactA($FactA_field2 == 111002, this after $FactA)\n" +
> " not FactA(field2 == 105742, this after $FactA)\n" + // Version B: using this version causes the IllegalArgumentException: Cannot remove a sink,
> // when the list of sinks is null on the updateToVersion() call
> "then\n" +
> "end\n";
> static final String ruleDrl2 = "package org.some.test\n" +
> "import org.drools.compiler.FactA\n" +
> "declare FactA\n" +
> "@role(event)" +
> "end\n" +
> "rule \"R1437_0\" when\n" +
> " $FactA : FactA ($FactA_field2 : field2 == 105742)\n" +
> " not FactA($FactA_field2 == 105742, this after $FactA)\n" + // version A:
> // " not FactA(field2 == 105742, this after $FactA)\n" + // Version B:
> "then\n" +
> "end\n";
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
6 years, 6 months
[JBoss JIRA] (DROOLS-731) In a catch22 using a NOT constraint in rules shared by multiple facts
by Bill Tuminaro (JIRA)
Bill Tuminaro created DROOLS-731:
------------------------------------
Summary: In a catch22 using a NOT constraint in rules shared by multiple facts
Key: DROOLS-731
URL: https://issues.jboss.org/browse/DROOLS-731
Project: Drools
Issue Type: Feature Request
Components: core engine
Affects Versions: 6.1.0.Final, 6.0.1.Final
Environment: Custom application that completely wraps Drools Fusion written as an OSGI application hosted on Websphere Liberty profile.
Reporter: Bill Tuminaro
Assignee: Mario Fusco
I have a reproducer for these related issues.
We have encountered a couple of issues (Exceptions) when using a NOT constraint in rules that have facts associated with them when we call upgradeToVersion() or kSession.delete(). The catch22 is that one version of the NOT constraint avoids one Exception while causing another. Reproducing the issue requires 2 rules sharing the same NOT constraint. I have narrowed the issue(s) down to 2 very simple rules that use the org.drools.compiler.FactA class.
Here are the 2 rules used:
static final String ruleDrl = "package org.some.test\n" +
"import org.drools.compiler.FactA\n" +
"declare FactA\n" +
"@role(event)" +
"end\n" +
"rule \"R200_0\" when\n" +
// " $FactA : FactA ($FactA_field2 : field2 == 111002)\n" + // version A: using this version causes a NPE when calling ksession.delete()
" not FactA($FactA_field2 == 111002, this after $FactA)\n" +
" not FactA(field2 == 105742, this after $FactA)\n" + // Version B: using this version causes the IllegalArgumentException: Cannot remove a sink,
// when the list of sinks is null on the updateToVersion() call
"then\n" +
"end\n";
static final String ruleDrl2 = "package org.some.test\n" +
"import org.drools.compiler.FactA\n" +
"declare FactA\n" +
"@role(event)" +
"end\n" +
"rule \"R1437_0\" when\n" +
" $FactA : FactA ($FactA_field2 : field2 == 105742)\n" +
" not FactA($FactA_field2 == 105742, this after $FactA)\n" + // version A:
// " not FactA(field2 == 105742, this after $FactA)\n" + // Version B:
"then\n" +
"end\n";
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
6 years, 6 months
[JBoss JIRA] (JGRP-1918) ConcurrentModificationException in Locking notification
by Paul Illingworth (JIRA)
Paul Illingworth created JGRP-1918:
--------------------------------------
Summary: ConcurrentModificationException in Locking notification
Key: JGRP-1918
URL: https://issues.jboss.org/browse/JGRP-1918
Project: JGroups
Issue Type: Bug
Affects Versions: 3.6.2
Environment: JUnit text running in Eclipse on Windows
Reporter: Paul Illingworth
Assignee: Bela Ban
I have code which unregisters a lock listener whilst a lock notification event is being fired leading to
java.util.ConcurrentModificationException
at java.util.HashMap$HashIterator.nextEntry(HashMap.java:926)
at java.util.HashMap$KeyIterator.next(HashMap.java:960)
at org.jgroups.protocols.Locking.notifyUnlocked(Locking.java:581)
at org.jgroups.protocols.Locking$ServerLock.setOwner(Locking.java:767)
at org.jgroups.protocols.Locking$ServerLock.handleRequest(Locking.java:655)
at org.jgroups.protocols.Locking.handleLockRequest(Locking.java:393)
at org.jgroups.protocols.Locking.up(Locking.java:226)
at org.jgroups.stack.Protocol.up(Protocol.java:412)
at org.jgroups.protocols.FORK.up(FORK.java:139)
at org.jgroups.protocols.FRAG2.up(FRAG2.java:182)
at org.jgroups.protocols.FlowControl.up(FlowControl.java:447)
at org.jgroups.protocols.FlowControl.up(FlowControl.java:447)
at org.jgroups.stack.Protocol.up(Protocol.java:420)
at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:294)
at org.jgroups.protocols.UNICAST3.deliverBatch(UNICAST3.java:1087)
at org.jgroups.protocols.UNICAST3.removeAndDeliver(UNICAST3.java:886)
at org.jgroups.protocols.UNICAST3.handleDataReceivedFromSelf(UNICAST3.java:821)
at org.jgroups.protocols.UNICAST3.up(UNICAST3.java:424)
at org.jgroups.protocols.pbcast.NAKACK2.up(NAKACK2.java:652)
at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:155)
at org.jgroups.protocols.FD.up(FD.java:253)
at org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:297)
at org.jgroups.protocols.MERGE3.up(MERGE3.java:288)
at org.jgroups.protocols.Discovery.up(Discovery.java:291)
at org.jgroups.protocols.TP$ProtocolAdapter.up(TP.java:2842)
at org.jgroups.protocols.TP.passMessageUp(TP.java:1577)
at org.jgroups.protocols.TP$3.run(TP.java:1511)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:724)
The org.jgroups.protocols.Locking#lock_listeners is simple a HashSet which gets iterated over, This needs to be synchronised is some way.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
6 years, 6 months
[JBoss JIRA] (WFLY-4393) Client-side message context value HTTP_REQUEST_HEADERS is not shared between SOAP handlers
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFLY-4393?page=com.atlassian.jira.plugin.... ]
Tomaz Cerar reassigned WFLY-4393:
---------------------------------
Assignee: Alessio Soldano (was: Jason Greene)
> Client-side message context value HTTP_REQUEST_HEADERS is not shared between SOAP handlers
> ------------------------------------------------------------------------------------------
>
> Key: WFLY-4393
> URL: https://issues.jboss.org/browse/WFLY-4393
> Project: WildFly
> Issue Type: Bug
> Components: Web Services
> Affects Versions: 8.2.0.Final
> Reporter: Takashi Nishigaya
> Assignee: Alessio Soldano
> Attachments: handler_header_chain.zip
>
>
> CXF runtime does NOT propagate JAX-WS standard context value MessageContext.HTTP_REQUEST_HEADERS to the subsequent client-side SOAP handlers. For instance,
> 1. The first client handler puts the newly created HTTP request header map that contains the custom header 'foo' in the message context.
> 2. The second client handler can not refer to the custom header 'foo' added in the step 1. The HTTP request header map in the message context is null.
> The weird thing is that the custom header added in the step 1 is correctly received by the server-side web services.
> The both of Java SE default JAX-WS implementations and GlassFish correctly share HTTP_REQUEST_HEADERS map between handlers.
> Please check the attached test case and compare the two test case. The method testHandlerChainOnServer() tests the case that the client is running on the container. On the other hand, testHandlerChainOnStandalone() tests the standalone client case.
> In order to reproduce the issue:
> $ mvm clean test -P wildly-managed (or -P wildly-remote)
> Additionally, this behavior is the same in EAP 6.3.3.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
6 years, 6 months
[JBoss JIRA] (JBMETA-385) Add overridable flag to servlet metadata
by Bartosz Baranowski (JIRA)
[ https://issues.jboss.org/browse/JBMETA-385?page=com.atlassian.jira.plugin... ]
Bartosz Baranowski reassigned JBMETA-385:
-----------------------------------------
Assignee: Bartosz Baranowski (was: Jean-Frederic Clere)
> Add overridable flag to servlet metadata
> ----------------------------------------
>
> Key: JBMETA-385
> URL: https://issues.jboss.org/browse/JBMETA-385
> Project: JBoss Metadata
> Issue Type: Enhancement
> Components: web
> Affects Versions: 7.2.1.Final
> Reporter: James Livingston
> Assignee: Bartosz Baranowski
>
> To resolve https://bugzilla.redhat.com/show_bug.cgi?id=1094248, I believe we need an additional 'overridable' flag on the servlet metadata which indicates whether ServletContainerInitializers (and other code using servlet dynamic registration) should be allowed to override the servlet. Normally this is not allowed, however JBWeb's internal use of DefaultServlet to handle static resources should be.
> This only needs to go into 7, since the Undertow subsystem in Wildfly handles this quite differently, so does not need to pass a flag between components.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
6 years, 6 months