[JBoss JIRA] (JGRP-1955) Additional unit test for merge
by Bela Ban (JIRA)
Bela Ban created JGRP-1955:
------------------------------
Summary: Additional unit test for merge
Key: JGRP-1955
URL: https://issues.jboss.org/browse/JGRP-1955
Project: JGroups
Issue Type: Task
Reporter: Bela Ban
Assignee: Bela Ban
Fix For: 3.6.5
Add a unit test to {{OverlappingMergeTest}} for:
{noformat}
A: A,B,C
B: A,B,C
C: A,B,C
{noformat}
Then, the following view is installed:
{noformat}
A: A,B
B: A,B
C: A,B,C // still has the same view
{noformat}
Make sure that a merge ensues which installs view A,B,C in all 3 members
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 2 months
[JBoss JIRA] (WFLY-5219) Datasource transformer for EAP6.2 work with wrong model version.
by Hynek Švábek (JIRA)
[ https://issues.jboss.org/browse/WFLY-5219?page=com.atlassian.jira.plugin.... ]
Hynek Švábek updated WFLY-5219:
-------------------------------
Affects Version/s: 10.0.0.Beta2
> Datasource transformer for EAP6.2 work with wrong model version.
> ----------------------------------------------------------------
>
> Key: WFLY-5219
> URL: https://issues.jboss.org/browse/WFLY-5219
> Project: WildFly
> Issue Type: Bug
> Components: Domain Management, JCA
> Affects Versions: 10.0.0.Beta2
> Reporter: Hynek Švábek
> Assignee: Jesper Pedersen
> Priority: Blocker
>
> Datasource transformer for EAP6.2 work with wrong model version.
> EAP 6.2 doesn't contain datasource model version 1.2, right version is 1.1 (jboss-as-datasources_1_1.xsd)
> {code}
> https://github.com/wildfly/wildfly/blob/master/connector/src/main/java/or...
> {code}
> I execute this command over CLI
> DomainController - EAP7 DR8
> Slave - EAP 6.2
> {code}
> data-source add --profile=full-ha --jndi-name=java:jboss/datasources/TestDS --name=java:jboss/datasources/TestDS --driver-name=h2 --connection-url=jdbc:h2:mem:test;DB_CLOSE_DELAY=-1
> {code}
> and get this output
> {code}
> Failed to execute line 'data-source add --profile=full-ha --jndi-name=java:jboss/datasources/TestDS --name=java:jboss/datasources/TestDS --driver-name=h2 --connection-url=jdbc:h2:mem:test;DB_CLOSE_DELAY=-1': org.jboss.as.cli.CommandLineException: {"host-failure-descriptions" => {"slave" => "WFLYCTL0297: Transforming operation {
> \"address\" => [
> (\"profile\" => \"full-ha\"),
> (\"subsystem\" => \"datasources\"),
> (\"data-source\" => \"java:jboss/datasources/TestDS\")
> ],
> \"operation\" => \"add\",
> \"jndi-name\" => \"java:jboss/datasources/TestDS\",
> \"driver-name\" => \"h2\",
> \"connection-url\" => \"jdbc:h2:mem:test;DB_CLOSE_DELAY=-1\",
> \"operation-headers\" => {
> \"caller-type\" => \"user\",
> \"access-mechanism\" => \"NATIVE\",
> \"domain-uuid\" => \"1dc420b4-d16f-4d0b-9cc5-3709939cff7d\",
> \"execute-for-coordinator\" => true,
> \"domain-controller-lock-id\" => 131382573
> }
> } at resource [
> (\"profile\" => \"full-ha\"),
> (\"subsystem\" => \"datasources\"),
> (\"data-source\" => \"java:jboss/datasources/TestDS\")
> ] to subsystem 'datasources' model version '1.2.0' -- attributes [statistics-enabled] WFLYJCA0088: Attributes [statistics-enabled] rejected. Must be true"}}
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 2 months
[JBoss JIRA] (WFLY-5219) Datasource transformer for EAP6.2 work with wrong model version.
by Hynek Švábek (JIRA)
Hynek Švábek created WFLY-5219:
----------------------------------
Summary: Datasource transformer for EAP6.2 work with wrong model version.
Key: WFLY-5219
URL: https://issues.jboss.org/browse/WFLY-5219
Project: WildFly
Issue Type: Bug
Components: JCA, Domain Management
Reporter: Hynek Švábek
Assignee: Jesper Pedersen
Priority: Blocker
Datasource transformer for EAP6.2 work with wrong model version.
EAP 6.2 doesn't contain datasource model version 1.2, right version is 1.1 (jboss-as-datasources_1_1.xsd)
{code}
https://github.com/wildfly/wildfly/blob/master/connector/src/main/java/or...
{code}
I execute this command over CLI
DomainController - EAP7 DR8
Slave - EAP 6.2
{code}
data-source add --profile=full-ha --jndi-name=java:jboss/datasources/TestDS --name=java:jboss/datasources/TestDS --driver-name=h2 --connection-url=jdbc:h2:mem:test;DB_CLOSE_DELAY=-1
{code}
and get this output
{code}
Failed to execute line 'data-source add --profile=full-ha --jndi-name=java:jboss/datasources/TestDS --name=java:jboss/datasources/TestDS --driver-name=h2 --connection-url=jdbc:h2:mem:test;DB_CLOSE_DELAY=-1': org.jboss.as.cli.CommandLineException: {"host-failure-descriptions" => {"slave" => "WFLYCTL0297: Transforming operation {
\"address\" => [
(\"profile\" => \"full-ha\"),
(\"subsystem\" => \"datasources\"),
(\"data-source\" => \"java:jboss/datasources/TestDS\")
],
\"operation\" => \"add\",
\"jndi-name\" => \"java:jboss/datasources/TestDS\",
\"driver-name\" => \"h2\",
\"connection-url\" => \"jdbc:h2:mem:test;DB_CLOSE_DELAY=-1\",
\"operation-headers\" => {
\"caller-type\" => \"user\",
\"access-mechanism\" => \"NATIVE\",
\"domain-uuid\" => \"1dc420b4-d16f-4d0b-9cc5-3709939cff7d\",
\"execute-for-coordinator\" => true,
\"domain-controller-lock-id\" => 131382573
}
} at resource [
(\"profile\" => \"full-ha\"),
(\"subsystem\" => \"datasources\"),
(\"data-source\" => \"java:jboss/datasources/TestDS\")
] to subsystem 'datasources' model version '1.2.0' -- attributes [statistics-enabled] WFLYJCA0088: Attributes [statistics-enabled] rejected. Must be true"}}
{code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 2 months
[JBoss JIRA] (SECURITY-905) Add protection of our GSSCredential added by the KerberosLoginModule
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/SECURITY-905?page=com.atlassian.jira.plug... ]
RH Bugzilla Integration commented on SECURITY-905:
--------------------------------------------------
Carlo de Wolf <cdewolf(a)redhat.com> changed the Status of [bug 1097276|https://bugzilla.redhat.com/show_bug.cgi?id=1097276] from ASSIGNED to MODIFIED
> Add protection of our GSSCredential added by the KerberosLoginModule
> --------------------------------------------------------------------
>
> Key: SECURITY-905
> URL: https://issues.jboss.org/browse/SECURITY-905
> Project: PicketBox
> Issue Type: Task
> Components: Negotiation
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Fix For: Negotiation_2_3_8_Beta1
>
>
> GSSManager implementation can have an optimisation that attempts to obtain the GSSCredential from the private credentials in the Subject, in some situations such as JDBC drivers this can mean that a driver gets direct access to the credential we are supposed to be managing the lifecycle of.
> The optimisation is based on checking if it is an instance of GSSCredentialImpl - if not then GSSManager creates a new instance.
> This Jira issue is to wrap the instance we place in the Subject to prevent the optimisation kicking in. This then means code using the credential such as a JDBC driver is free to do what it wants with it's own credential without impacting on ours.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 2 months
[JBoss JIRA] (DROOLS-329) ClassFormatException when compile template with latest JDK8 (b114)
by Mario Fusco (JIRA)
[ https://issues.jboss.org/browse/DROOLS-329?page=com.atlassian.jira.plugin... ]
Mario Fusco commented on DROOLS-329:
------------------------------------
This works for me. Do you have a reproducer of your problem?
> 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: Mario Fusco
> Fix For: 5.5.1.Final, 6.3.0.CR1
>
>
> 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.15#6346)
10 years, 2 months
[JBoss JIRA] (WFCORE-923) Execution timeout for CLI operations
by Lyle Wang (JIRA)
[ https://issues.jboss.org/browse/WFCORE-923?page=com.atlassian.jira.plugin... ]
Lyle Wang updated WFCORE-923:
-----------------------------
Description:
It will be great if we could have a timeout setting to "stop-the-CLI-execution-after-nnn-seconds" , for all general CLI operations.
Specifically, during some CLI operations, for example "deploy" or "reload", it is possible that things get stuck and hang-up, CLI cannot get back / return to the user after a long waiting. In this case, if we're able to setup an "execution timeout" and let CLI return with an error message, that would be much better. User should be able to know command execution results by viewing the related logs or checking the status.
Currently there is "- -timeout" setting when running "jboss-cli.sh", but that seems only effective on "connect" operation, tried to use this "- -timeout" with a CLI script file, which has "deploy" inside (./jboss-cli.sh --file=test.cli --timeout=xxx), it doesn't work when the deployment takes a long time.
was:
It will be great if we could have a timeout setting to "stop-the-CLI-execution-after-nnn-seconds" , for all general CLI operations.
Specifically, during some CLI operations, for example "deploy" or "reload", it is possible that things get stuck and hang-up, CLI cannot get back / return to the user after a long waiting. In this case, if we're able to setup an "execution timeout" and let CLI return with an error message, that would be much better. User should be able to know command execution results by viewing the related logs or checking the status.
Currently there is "--timeout" setting when running "jboss-cli.sh", but that seems only effective on "connect" operation, tried to use this "--timeout" with a CLI script file, which has "deploy" inside (./jboss-cli.sh --file=test.cli --timeout=xxx), it doesn't work when the deployment takes a long time.
> Execution timeout for CLI operations
> ------------------------------------
>
> Key: WFCORE-923
> URL: https://issues.jboss.org/browse/WFCORE-923
> Project: WildFly Core
> Issue Type: Feature Request
> Components: CLI
> Affects Versions: 2.0.0.Beta4
> Reporter: Lyle Wang
> Assignee: Alexey Loubyansky
> Labels: cli, timeout
>
> It will be great if we could have a timeout setting to "stop-the-CLI-execution-after-nnn-seconds" , for all general CLI operations.
> Specifically, during some CLI operations, for example "deploy" or "reload", it is possible that things get stuck and hang-up, CLI cannot get back / return to the user after a long waiting. In this case, if we're able to setup an "execution timeout" and let CLI return with an error message, that would be much better. User should be able to know command execution results by viewing the related logs or checking the status.
> Currently there is "- -timeout" setting when running "jboss-cli.sh", but that seems only effective on "connect" operation, tried to use this "- -timeout" with a CLI script file, which has "deploy" inside (./jboss-cli.sh --file=test.cli --timeout=xxx), it doesn't work when the deployment takes a long time.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 2 months
[JBoss JIRA] (WFCORE-923) Execution timeout for CLI operations
by Lyle Wang (JIRA)
[ https://issues.jboss.org/browse/WFCORE-923?page=com.atlassian.jira.plugin... ]
Lyle Wang updated WFCORE-923:
-----------------------------
Description:
It will be great if we could have a timeout setting to "stop-the-CLI-execution-after-nnn-seconds" , for all general CLI operations.
Specifically, during some CLI operations, for example "deploy" or "reload", it is possible that things get stuck and hang-up, CLI cannot get back / return to the user after a long waiting. In this case, if we're able to setup an "execution timeout" and let CLI return with an error message, that would be much better. User should be able to know command execution results by viewing the related logs or checking the status.
Currently there is "--timeout" setting when running "jboss-cli.sh", but that seems only effective on "connect" operation, tried to use this timeout with a CLI script file, which has "deploy" inside (./jboss-cli.sh --file=test.cli --timeout=xxx), it doesn't work when the deployment takes a long time.
was:
It will be great if we could have a timeout setting to "stop-the-CLI-execution-after-nnn-seconds" , for all general CLI operations.
Specifically, during some CLI operations, for example "deploy" or "reload", it is possible that things get stuck and hang-up, CLI cannot get back / return to the user after a long waiting. In this case, if we're able to setup an "execution timeout" and let CLI return with an error message, that would be much better. User should be able to know command execution results by viewing the related logs or checking the status.
Currently there is "- -timeout" setting when running "jboss-cli.sh", but that seems only effective on "connect" operation, tried to use this "- -timeout" with a CLI script file, which has "deploy" inside (./jboss-cli.sh --file=test.cli --timeout=xxx), it doesn't work when the deployment takes a long time.
> Execution timeout for CLI operations
> ------------------------------------
>
> Key: WFCORE-923
> URL: https://issues.jboss.org/browse/WFCORE-923
> Project: WildFly Core
> Issue Type: Feature Request
> Components: CLI
> Affects Versions: 2.0.0.Beta4
> Reporter: Lyle Wang
> Assignee: Alexey Loubyansky
> Labels: cli, timeout
>
> It will be great if we could have a timeout setting to "stop-the-CLI-execution-after-nnn-seconds" , for all general CLI operations.
> Specifically, during some CLI operations, for example "deploy" or "reload", it is possible that things get stuck and hang-up, CLI cannot get back / return to the user after a long waiting. In this case, if we're able to setup an "execution timeout" and let CLI return with an error message, that would be much better. User should be able to know command execution results by viewing the related logs or checking the status.
> Currently there is "--timeout" setting when running "jboss-cli.sh", but that seems only effective on "connect" operation, tried to use this timeout with a CLI script file, which has "deploy" inside (./jboss-cli.sh --file=test.cli --timeout=xxx), it doesn't work when the deployment takes a long time.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 2 months