[JBoss JIRA] (WFLY-2627) EJB container-transaction configuration with ejb-jar.xml leads to wrong transaction behavior
by Norbert Bumm (JIRA)
[ https://issues.jboss.org/browse/WFLY-2627?page=com.atlassian.jira.plugin.... ]
Norbert Bumm updated WFLY-2627:
-------------------------------
Attachment: wildfly-src-7.2.0.Final-TransactionBug.patch
Patch for wildfly 7.2.0.Final to fix this bug and WFLY-67
> EJB container-transaction configuration with ejb-jar.xml leads to wrong transaction behavior
> --------------------------------------------------------------------------------------------
>
> Key: WFLY-2627
> URL: https://issues.jboss.org/browse/WFLY-2627
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: EJB, Transactions
> Environment: jdk1.7.0_45_x64, Windows 7
> Reporter: Norbert Bumm
> Assignee: David Lloyd
> Attachments: arquillian-jpa.zip, wildfly-src-7.2.0.Final-TransactionBug.patch
>
>
> If there is a global transaction declaration for “Supports” and a “Required” declaration for a specific Method the “Required” gets ignored. I first encountered the problem with an old 2.1 EJB, but the problem is also there with a 3.1 EJB with deployment descriptor. It works correct with annotations.
> ejb-jar.xml snippet
> {code:xml}
> <container-transaction>
> <method>
> <ejb-name>UserDAOImpl</ejb-name>
> <method-name>*</method-name>
> </method>
> <trans-attribute>Supports</trans-attribute>
> </container-transaction>
> <container-transaction>
> <method>
> <ejb-name>UserDAOImpl</ejb-name>
> <method-intf>Local</method-intf>
> <method-name>createUser</method-name>
> </method>
> <trans-attribute>Required</trans-attribute>
> </container-transaction>
> {code}
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
9 years, 9 months
[JBoss JIRA] (DROOLS-329) ClassFormatException when compile template with latest JDK8 (b114)
by Vsevolod Minkov (JIRA)
[ https://issues.jboss.org/browse/DROOLS-329?page=com.atlassian.jira.plugin... ]
Vsevolod Minkov edited comment on DROOLS-329 at 8/2/14 5:49 AM:
----------------------------------------------------------------
The workaround is using newer version of org.eclipse.jdt.core.compiler:ecj (4.4 works fine)
was (Author: vsevolod.minkov):
The workaroung is using newer version of org.eclipse.jdt.core.compiler:ecj (4.4 works fine)
> 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)
9 years, 9 months
[JBoss JIRA] (DROOLS-329) ClassFormatException when compile template with latest JDK8 (b114)
by Vsevolod Minkov (JIRA)
[ https://issues.jboss.org/browse/DROOLS-329?page=com.atlassian.jira.plugin... ]
Vsevolod Minkov commented on DROOLS-329:
----------------------------------------
The workaroung is using newer version of org.eclipse.jdt.core.compiler:ecj (4.4 works fine)
> 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)
9 years, 9 months
[JBoss JIRA] (DROOLS-553) Build does not build on maven 3.2.2 with an empty repository
by Geoffrey De Smet (JIRA)
[ https://issues.jboss.org/browse/DROOLS-553?page=com.atlassian.jira.plugin... ]
Geoffrey De Smet commented on DROOLS-553:
-----------------------------------------
See https://plus.google.com/114843822427522708527/posts/fFmqTkH53pa
> Build does not build on maven 3.2.2 with an empty repository
> ------------------------------------------------------------
>
> Key: DROOLS-553
> URL: https://issues.jboss.org/browse/DROOLS-553
> Project: Drools
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Reporter: Geoffrey De Smet
> Assignee: Michael Biarnes Kiefer
> Priority: Blocker
>
> Our community contributors should be able to just build our stuff with the latest maven version. Currently that doesn't work.
> Building with maven 3.0.5 works.
> To reproduce:
> - Use maven 3.2.2
> - Build droolsjbpm-build-bootstrap
> - Do not build uberfire first
> - rm ~/.m2/repository/org/uberfire
> => this will force droolsjbpm-build-bootstrap to download the uberfire-bom 6.2.0-SNAPSHOT, which fails with maven 3.2.2:
> {code}
> $ mvn clean install -Dfull -DskipTests -U
> [INFO] Scanning for projects...
> [ERROR] The build could not read 1 project -> [Help 1]
> [ERROR]
> [ERROR] The project org.kie:kie-parent-with-dependencies:6.2.0-SNAPSHOT (/Users/.../OptaPlanner/droolsjbpm-build-bootstrap/kie-parent-with-dependencies/pom.xml) has 1 error
> [ERROR] Non-resolvable import POM: Could not find artifact org.uberfire:uberfire-bom:pom:0.4.2-SNAPSHOT @ org.kie:kie-parent-with-dependencies:[unknown-version], /Users/.../OptaPlanner/droolsjbpm-build-bootstrap/kie-parent-with-dependencies/pom.xml, line 137, column 19 -> [Help 2]
> [ERROR]
> [ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> [ERROR]
> [ERROR] For more information about the errors and possible solutions, please read the following articles:
> [ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/ProjectBuildingException
> [ERROR] [Help 2] http://cwiki.apache.org/confluence/display/MAVEN/UnresolvableModelException
> {code}
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
9 years, 9 months
[JBoss JIRA] (DROOLS-553) Build does not build on maven 3.2.2 with an empty repository
by Geoffrey De Smet (JIRA)
[ https://issues.jboss.org/browse/DROOLS-553?page=com.atlassian.jira.plugin... ]
Geoffrey De Smet commented on DROOLS-553:
-----------------------------------------
[~skipcole] I feel your pain, but our readme is already pretty long:
https://github.com/droolsjbpm/droolsjbpm-build-bootstrap/blob/master/READ...
And most users don't read it (have you read it completely?).
Now, I understand that you'd like that warning to be the first line in that readme:
- but so does anybody else who encounters a pitfall: they all want that their pitfall is the first warning in the readme
- this pitfall only have a very short window of existence: maven 3.2.2 is just out, the regression is already fixed and they implied to release 3.2.3 really soon (TM) now.
- googling the error message brings a user to this jira issue which often happens sooner than the user actually reading the readme...
The root cause needs to fixed, that's the only efficient way to stop wasting people's time (including mine), so I'll add some extra, *polite* pressure on maven to release 3.2.3 (feel free to do the same), that will actually help.
> Build does not build on maven 3.2.2 with an empty repository
> ------------------------------------------------------------
>
> Key: DROOLS-553
> URL: https://issues.jboss.org/browse/DROOLS-553
> Project: Drools
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Reporter: Geoffrey De Smet
> Assignee: Michael Biarnes Kiefer
> Priority: Blocker
>
> Our community contributors should be able to just build our stuff with the latest maven version. Currently that doesn't work.
> Building with maven 3.0.5 works.
> To reproduce:
> - Use maven 3.2.2
> - Build droolsjbpm-build-bootstrap
> - Do not build uberfire first
> - rm ~/.m2/repository/org/uberfire
> => this will force droolsjbpm-build-bootstrap to download the uberfire-bom 6.2.0-SNAPSHOT, which fails with maven 3.2.2:
> {code}
> $ mvn clean install -Dfull -DskipTests -U
> [INFO] Scanning for projects...
> [ERROR] The build could not read 1 project -> [Help 1]
> [ERROR]
> [ERROR] The project org.kie:kie-parent-with-dependencies:6.2.0-SNAPSHOT (/Users/.../OptaPlanner/droolsjbpm-build-bootstrap/kie-parent-with-dependencies/pom.xml) has 1 error
> [ERROR] Non-resolvable import POM: Could not find artifact org.uberfire:uberfire-bom:pom:0.4.2-SNAPSHOT @ org.kie:kie-parent-with-dependencies:[unknown-version], /Users/.../OptaPlanner/droolsjbpm-build-bootstrap/kie-parent-with-dependencies/pom.xml, line 137, column 19 -> [Help 2]
> [ERROR]
> [ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> [ERROR]
> [ERROR] For more information about the errors and possible solutions, please read the following articles:
> [ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/ProjectBuildingException
> [ERROR] [Help 2] http://cwiki.apache.org/confluence/display/MAVEN/UnresolvableModelException
> {code}
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
9 years, 9 months
[JBoss JIRA] (WFLY-3703) arq.container.domain.ManagementClient.readRootNode does not see servers on remote hosts
by Arcadiy Ivanov (JIRA)
[ https://issues.jboss.org/browse/WFLY-3703?page=com.atlassian.jira.plugin.... ]
Arcadiy Ivanov commented on WFLY-3703:
--------------------------------------
Added a pull request with a fix.
> arq.container.domain.ManagementClient.readRootNode does not see servers on remote hosts
> ---------------------------------------------------------------------------------------
>
> Key: WFLY-3703
> URL: https://issues.jboss.org/browse/WFLY-3703
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Test Suite
> Affects Versions: 8.1.0.Final
> Environment: Linux aimobile-sm.servicemesh.com 3.15.6-200.fc20.x86_64 #1 SMP Fri Jul 18 02:36:27 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
> Reporter: Arcadiy Ivanov
> Assignee: Alexey Loubyansky
> Priority: Blocker
> Attachments: non-recursive.txt, recursive-runtime.txt, recursive.txt
>
>
> Trying to use Arquillian with remote multi-host domain.
> Now see the code snippet below:
> * readRootNode calls readResource with includeRuntime set to true.
> * readResource also sets recursive to true.
> However due to this behavior of read-resource *no hosts other than domain controller's are visible to Arquillian*:
> [proxies – (boolean, default is false) – whether to include remote resources in a recursive query (i.e. host level resources from slave Host Controllers in a query of the Domain Controller; running server resources in a query of a host).|https://docs.jboss.org/author/display/WFLY8/Global+operations]
> +As a result if I have a DC on localhost with no servers and Host1 with Node1 on 127.0.0.2 and Host2 with Node2 on 127.0.0.3, Arquillian will not find ANY servers to deploy to - no proxies (remote hosts) will be enumerated.+
> {noformat}
> private void readRootNode() throws Exception {
> rootNode = readResource(new ModelNode());
> }
> private ModelNode readResource(ModelNode address) throws Exception {
> return readResource(address, true);
> }
> private ModelNode readResource(ModelNode address, boolean includeRuntime) throws Exception {
> final ModelNode operation = new ModelNode();
> operation.get(OP).set(READ_RESOURCE_OPERATION);
> operation.get(RECURSIVE).set("true");
> operation.get(INCLUDE_RUNTIME).set(includeRuntime);
> operation.get(OP_ADDR).set(address);
> return executeForResult(operation);
> }
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
9 years, 9 months