[JBoss JIRA] (WFLY-12217) Update subsystem schemas to reference the new XML schema for credential-reference
by Farah Juma (Jira)
[ https://issues.jboss.org/browse/WFLY-12217?page=com.atlassian.jira.plugin... ]
Farah Juma updated WFLY-12217:
------------------------------
Summary: Update subsystem schemas to reference the new XML schema for credential-reference (was: Provide XML schema for credential-reference)
> Update subsystem schemas to reference the new XML schema for credential-reference
> ---------------------------------------------------------------------------------
>
> Key: WFLY-12217
> URL: https://issues.jboss.org/browse/WFLY-12217
> Project: WildFly
> Issue Type: Task
> Components: Management, Security
> Reporter: Farah Juma
> Assignee: Farah Juma
> Priority: Major
> Labels: credential-reference, eap72
> Fix For: 10.0.0.Beta1
>
>
> With https://issues.jboss.org/browse/EAP7-538, all passwords references in the subsystems must support credential references.
> The model attribute is provided by wildlfy-controller module (including its XML parser and marshaller) but the corresponding XML element has been added directly to the subsystems XML schemas. This will become a maintenance issue when/if the credential references has to be updated and all the subsystems schema risk to be out of sync with the actual code reading/writing the credential reference.
> We should follow the same design than for threads attributes (provided by the willdfly-threads module): the wildlfy-controller module provides a XML schema for the credential-references with its own versioned namespace and any subsystem that requires it will just refer to it.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 10 months
[JBoss JIRA] (WFCORE-4535) WildFly discovery subsystem registers capabilities using an ambiguous contract
by Paul Ferraro (Jira)
Paul Ferraro created WFCORE-4535:
------------------------------------
Summary: WildFly discovery subsystem registers capabilities using an ambiguous contract
Key: WFCORE-4535
URL: https://issues.jboss.org/browse/WFCORE-4535
Project: WildFly Core
Issue Type: Bug
Components: Discovery
Affects Versions: 9.0.1.Final
Reporter: Paul Ferraro
Assignee: Paul Ferraro
The discovery subsystem registers capabilities of the form RuntimeCapability<Void> with a service type of DiscoveryProvider.class with the model.
However, during runtime it registers capabilities of the form RuntimeCapability<DiscoveryProvider> with the OperationContext using the same name.
This violates the capability contract. Since the capability specified during resource registration is what defines the contract, and since non-trivial discovery provider implementations cannot reasonably register an implementation during the model phase without requiring runtime dependencies, we should prefer the former definition over the latter.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 10 months
[JBoss JIRA] (WFCORE-4535) WildFly discovery subsystem registers capabilities using an ambiguous contract
by Paul Ferraro (Jira)
[ https://issues.jboss.org/browse/WFCORE-4535?page=com.atlassian.jira.plugi... ]
Paul Ferraro updated WFCORE-4535:
---------------------------------
Priority: Critical (was: Major)
> WildFly discovery subsystem registers capabilities using an ambiguous contract
> ------------------------------------------------------------------------------
>
> Key: WFCORE-4535
> URL: https://issues.jboss.org/browse/WFCORE-4535
> Project: WildFly Core
> Issue Type: Bug
> Components: Discovery
> Affects Versions: 9.0.1.Final
> Reporter: Paul Ferraro
> Assignee: Paul Ferraro
> Priority: Critical
>
> The discovery subsystem registers capabilities of the form RuntimeCapability<Void> with a service type of DiscoveryProvider.class with the model.
> However, during runtime it registers capabilities of the form RuntimeCapability<DiscoveryProvider> with the OperationContext using the same name.
> This violates the capability contract. Since the capability specified during resource registration is what defines the contract, and since non-trivial discovery provider implementations cannot reasonably register an implementation during the model phase without requiring runtime dependencies, we should prefer the former definition over the latter.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 10 months
[JBoss JIRA] (WFLY-11983) Unify line-endings of bat scripts (regression against WF15)
by James Perkins (Jira)
[ https://issues.jboss.org/browse/WFLY-11983?page=com.atlassian.jira.plugin... ]
James Perkins edited comment on WFLY-11983 at 6/20/19 12:47 PM:
----------------------------------------------------------------
You are correct the files themselves need to be updated. You'd have to apply this change then do something like {{find feature-pack/src -name "*.bat" | xargs -I \{\} git reset-file "\{\}"}}. Every user would have to do this though or more importantly whoever does the release.
That said there is also WFGP-144 which fixes this issue with the changes on the [WFCORE-4502|https://issues.jboss.org/browse/WFCORE-4502?focusedCommentId=...] comment.
was (Author: jamezp):
You are correct the files themselves need to be updated. You'd have to apply this change then do something like {{find feature-pack/src -name "*.bat" | xargs git reset-file}}. Every user would have to do this though or more importantly whoever does the release.
That said there is also WFGP-144 which fixes this issue with the changes on the [WFCORE-4502|https://issues.jboss.org/browse/WFCORE-4502?focusedCommentId=...] comment.
> Unify line-endings of bat scripts (regression against WF15)
> -----------------------------------------------------------
>
> Key: WFLY-11983
> URL: https://issues.jboss.org/browse/WFLY-11983
> Project: WildFly
> Issue Type: Bug
> Components: Scripts
> Affects Versions: 16.0.0.Final
> Reporter: Marek Kopecky
> Assignee: Radoslav Husar
> Priority: Major
>
> Line-endings of bat scripts should be unified. This is regression against WF15.
> Some files in WF16 uses CRLF, another LF only. We need to clarify the recommended line ending and use this line ending in all Windows scripts.
> WF16:
> {noformat}
> $ find | grep bat$ | xargs file
> ./wsprovide.bat: DOS batch file, ASCII text, with CRLF line terminators
> ./jboss-cli.bat: DOS batch file, ASCII text
> ./elytron-tool.bat: DOS batch file, ASCII text
> ./domain.bat: DOS batch file, ASCII text, with CRLF line terminators
> ./wsconsume.bat: DOS batch file, ASCII text, with CRLF line terminators
> ./standalone.bat: DOS batch file, ASCII text, with CRLF line terminators
> ./vault.bat: DOS batch file, ASCII text, with CRLF line terminators
> ./domain.conf.bat: ASCII text, with CRLF line terminators
> ./common.bat: DOS batch file, ASCII text, with CRLF line terminators
> ./jdr.bat: DOS batch file, ASCII text
> ./jconsole.bat: DOS batch file, ASCII text
> ./appclient.bat: DOS batch file, ASCII text, with CRLF line terminators
> ./appclient.conf.bat: ASCII text, with CRLF line terminators
> ./standalone.conf.bat: ASCII text, with CRLF line terminators
> ./add-user.bat: DOS batch file, ASCII text
> $
> {noformat}
> WF15:
> {noformat}
> $ find | grep bat$ | xargs file
> ./wsprovide.bat: DOS batch file, ASCII text, with CRLF line terminators
> ./jboss-cli.bat: DOS batch file, ASCII text, with CRLF line terminators
> ./elytron-tool.bat: DOS batch file, ASCII text, with CRLF line terminators
> ./domain.bat: DOS batch file, ASCII text, with CRLF line terminators
> ./wsconsume.bat: DOS batch file, ASCII text, with CRLF line terminators
> ./standalone.bat: DOS batch file, ASCII text, with CRLF line terminators
> ./vault.bat: DOS batch file, ASCII text, with CRLF line terminators
> ./domain.conf.bat: ASCII text, with CRLF line terminators
> ./common.bat: DOS batch file, ASCII text, with CRLF line terminators
> ./jdr.bat: DOS batch file, ASCII text, with CRLF line terminators
> ./jconsole.bat: DOS batch file, ASCII text, with CRLF line terminators
> ./appclient.bat: DOS batch file, ASCII text, with CRLF line terminators
> ./appclient.conf.bat: ASCII text, with CRLF line terminators
> ./standalone.conf.bat: ASCII text, with CRLF line terminators
> ./add-user.bat: DOS batch file, ASCII text, with CRLF line terminators
> $
> {noformat}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 10 months
[JBoss JIRA] (JGRP-2355) TCP_NIO2 fails under Java 8
by Bela Ban (Jira)
[ https://issues.jboss.org/browse/JGRP-2355?page=com.atlassian.jira.plugin.... ]
Bela Ban resolved JGRP-2355.
----------------------------
Resolution: Done
> TCP_NIO2 fails under Java 8
> ---------------------------
>
> Key: JGRP-2355
> URL: https://issues.jboss.org/browse/JGRP-2355
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 4.1.1
> Reporter: Paul Ferraro
> Assignee: Bela Ban
> Priority: Critical
> Fix For: 4.1.2
>
>
> Because the 4.1.x releases are built with JDK11, I see the following at runtime when running under Java 8:
> {noformat}
> WARN [org.jgroups.protocols.TCP_NIO2] (TQ-Bundler-6,ejb,node-1) node-1: failed sending message to 127.0.0.1:7700: java.lang.NoSuchMethodError: java.nio.ByteBuffer.clear()Ljava/nio/ByteBuffer;
> {noformat}
> The problematic code seems to be here:
> https://github.com/belaban/JGroups/blob/master/src/org/jgroups/blocks/cs/...
> In JDK8, Buffer.clear() was final and returned a Buffer object (hence the need for your code to cast). However, in JDK11 Buffer.clear() is no longer final, allowing subclasses to override the return type, which ByteBuffer indeed does (to return a ByteBuffer). However, since JGroups 4.1.x is built with JDK11, when running on Java 8, the method is not found.
> N.B. There is a similar problem with uses of ByteBuffer.flip() and limit(...). I didn't catch these at first since NioConnection.Reader.run() swallows Errors.
> There are 2 ways to fix this:
> 1. Ensure 4.1.x releases are built using JDK8 (since source is still compatible with Java 8)
> 2. Cast java.io.ByteBuffer to java.nio.Buffer when invoking clear() to avoid the NoSuchMethodError.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 10 months
[JBoss JIRA] (JGRP-2355) TCP_NIO2 fails under Java 8
by Paul Ferraro (Jira)
[ https://issues.jboss.org/browse/JGRP-2355?page=com.atlassian.jira.plugin.... ]
Paul Ferraro commented on JGRP-2355:
------------------------------------
FWIW, this PR allows TCP_NIO2 to work under Java 8 even when built using JDK11.
https://github.com/belaban/JGroups/pull/430
> TCP_NIO2 fails under Java 8
> ---------------------------
>
> Key: JGRP-2355
> URL: https://issues.jboss.org/browse/JGRP-2355
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 4.1.1
> Reporter: Paul Ferraro
> Assignee: Bela Ban
> Priority: Critical
> Fix For: 4.1.2
>
>
> Because the 4.1.x releases are built with JDK11, I see the following at runtime when running under Java 8:
> {noformat}
> WARN [org.jgroups.protocols.TCP_NIO2] (TQ-Bundler-6,ejb,node-1) node-1: failed sending message to 127.0.0.1:7700: java.lang.NoSuchMethodError: java.nio.ByteBuffer.clear()Ljava/nio/ByteBuffer;
> {noformat}
> The problematic code seems to be here:
> https://github.com/belaban/JGroups/blob/master/src/org/jgroups/blocks/cs/...
> In JDK8, Buffer.clear() was final and returned a Buffer object (hence the need for your code to cast). However, in JDK11 Buffer.clear() is no longer final, allowing subclasses to override the return type, which ByteBuffer indeed does (to return a ByteBuffer). However, since JGroups 4.1.x is built with JDK11, when running on Java 8, the method is not found.
> N.B. There is a similar problem with uses of ByteBuffer.flip() and limit(...). I didn't catch these at first since NioConnection.Reader.run() swallows Errors.
> There are 2 ways to fix this:
> 1. Ensure 4.1.x releases are built using JDK8 (since source is still compatible with Java 8)
> 2. Cast java.io.ByteBuffer to java.nio.Buffer when invoking clear() to avoid the NoSuchMethodError.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 10 months
[JBoss JIRA] (JGRP-2355) TCP_NIO2 fails under Java 8
by Paul Ferraro (Jira)
[ https://issues.jboss.org/browse/JGRP-2355?page=com.atlassian.jira.plugin.... ]
Paul Ferraro edited comment on JGRP-2355 at 6/20/19 12:25 PM:
--------------------------------------------------------------
FWIW, this PR allows TCP_NIO2 to work under Java 8 even when built using JDK11.
https://github.com/belaban/JGroups/pull/430
Feel free to close it if you don't want these changes.
was (Author: pferraro):
FWIW, this PR allows TCP_NIO2 to work under Java 8 even when built using JDK11.
https://github.com/belaban/JGroups/pull/430
> TCP_NIO2 fails under Java 8
> ---------------------------
>
> Key: JGRP-2355
> URL: https://issues.jboss.org/browse/JGRP-2355
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 4.1.1
> Reporter: Paul Ferraro
> Assignee: Bela Ban
> Priority: Critical
> Fix For: 4.1.2
>
>
> Because the 4.1.x releases are built with JDK11, I see the following at runtime when running under Java 8:
> {noformat}
> WARN [org.jgroups.protocols.TCP_NIO2] (TQ-Bundler-6,ejb,node-1) node-1: failed sending message to 127.0.0.1:7700: java.lang.NoSuchMethodError: java.nio.ByteBuffer.clear()Ljava/nio/ByteBuffer;
> {noformat}
> The problematic code seems to be here:
> https://github.com/belaban/JGroups/blob/master/src/org/jgroups/blocks/cs/...
> In JDK8, Buffer.clear() was final and returned a Buffer object (hence the need for your code to cast). However, in JDK11 Buffer.clear() is no longer final, allowing subclasses to override the return type, which ByteBuffer indeed does (to return a ByteBuffer). However, since JGroups 4.1.x is built with JDK11, when running on Java 8, the method is not found.
> N.B. There is a similar problem with uses of ByteBuffer.flip() and limit(...). I didn't catch these at first since NioConnection.Reader.run() swallows Errors.
> There are 2 ways to fix this:
> 1. Ensure 4.1.x releases are built using JDK8 (since source is still compatible with Java 8)
> 2. Cast java.io.ByteBuffer to java.nio.Buffer when invoking clear() to avoid the NoSuchMethodError.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 10 months
[JBoss JIRA] (JGRP-2355) TCP_NIO2 fails under Java 8
by Paul Ferraro (Jira)
[ https://issues.jboss.org/browse/JGRP-2355?page=com.atlassian.jira.plugin.... ]
Paul Ferraro updated JGRP-2355:
-------------------------------
Description:
Because the 4.1.x releases are built with JDK11, I see the following at runtime when running under Java 8:
{noformat}
WARN [org.jgroups.protocols.TCP_NIO2] (TQ-Bundler-6,ejb,node-1) node-1: failed sending message to 127.0.0.1:7700: java.lang.NoSuchMethodError: java.nio.ByteBuffer.clear()Ljava/nio/ByteBuffer;
{noformat}
The problematic code seems to be here:
https://github.com/belaban/JGroups/blob/master/src/org/jgroups/blocks/cs/...
In JDK8, Buffer.clear() was final and returned a Buffer object (hence the need for your code to cast). However, in JDK11 Buffer.clear() is no longer final, allowing subclasses to override the return type, which ByteBuffer indeed does (to return a ByteBuffer). However, since JGroups 4.1.x is built with JDK11, when running on Java 8, the method is not found.
N.B. There is a similar problem with uses of ByteBuffer.flip() and limit(...). I didn't catch these at first since NioConnection.Reader.run() swallows Errors.
There are 2 ways to fix this:
1. Ensure 4.1.x releases are built using JDK8 (since source is still compatible with Java 8)
2. Cast java.io.ByteBuffer to java.nio.Buffer when invoking clear() to avoid the NoSuchMethodError.
was:
Because the 4.1.x releases are built with JDK11, I see the following at runtime when running under Java 8:
{noformat}
WARN [org.jgroups.protocols.TCP_NIO2] (TQ-Bundler-6,ejb,node-1) node-1: failed sending message to 127.0.0.1:7700: java.lang.NoSuchMethodError: java.nio.ByteBuffer.clear()Ljava/nio/ByteBuffer;
{noformat}
The problematic code seems to be here:
https://github.com/belaban/JGroups/blob/master/src/org/jgroups/blocks/cs/...
In JDK8, Buffer.clear() was final and returned a Buffer object (hence the need for your code to cast). However, in JDK11 Buffer.clear() is no longer final, allowing subclasses to override the return type, which ByteBuffer indeed does (to return a ByteBuffer). However, since JGroups 4.1.x is built with JDK11, when running on Java 8, the method is not found.
N.B. There is a similar problem with uses of ByteBuffer.flip(). I didn't catch these at first since NioConnection.Reader.run() swallows Errors.
There are 2 ways to fix this:
1. Ensure 4.1.x releases are built using JDK8 (since source is still compatible with Java 8)
2. Cast java.io.ByteBuffer to java.nio.Buffer when invoking clear() to avoid the NoSuchMethodError.
> TCP_NIO2 fails under Java 8
> ---------------------------
>
> Key: JGRP-2355
> URL: https://issues.jboss.org/browse/JGRP-2355
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 4.1.1
> Reporter: Paul Ferraro
> Assignee: Bela Ban
> Priority: Critical
> Fix For: 4.1.2
>
>
> Because the 4.1.x releases are built with JDK11, I see the following at runtime when running under Java 8:
> {noformat}
> WARN [org.jgroups.protocols.TCP_NIO2] (TQ-Bundler-6,ejb,node-1) node-1: failed sending message to 127.0.0.1:7700: java.lang.NoSuchMethodError: java.nio.ByteBuffer.clear()Ljava/nio/ByteBuffer;
> {noformat}
> The problematic code seems to be here:
> https://github.com/belaban/JGroups/blob/master/src/org/jgroups/blocks/cs/...
> In JDK8, Buffer.clear() was final and returned a Buffer object (hence the need for your code to cast). However, in JDK11 Buffer.clear() is no longer final, allowing subclasses to override the return type, which ByteBuffer indeed does (to return a ByteBuffer). However, since JGroups 4.1.x is built with JDK11, when running on Java 8, the method is not found.
> N.B. There is a similar problem with uses of ByteBuffer.flip() and limit(...). I didn't catch these at first since NioConnection.Reader.run() swallows Errors.
> There are 2 ways to fix this:
> 1. Ensure 4.1.x releases are built using JDK8 (since source is still compatible with Java 8)
> 2. Cast java.io.ByteBuffer to java.nio.Buffer when invoking clear() to avoid the NoSuchMethodError.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 10 months
[JBoss JIRA] (DROOLS-4200) Design and implement new DataSources API
by Mario Fusco (Jira)
Mario Fusco created DROOLS-4200:
-----------------------------------
Summary: Design and implement new DataSources API
Key: DROOLS-4200
URL: https://issues.jboss.org/browse/DROOLS-4200
Project: Drools
Issue Type: Task
Components: core engine
Reporter: Mario Fusco
Assignee: Mario Fusco
We need 2 distinct DataSources:
* DataStream with only an append operation
* DataStore with all 3 WMA operations (has to return a FH)
Each RuleUnit will have a mailbox. When a RuleUnit is executed for the first time all data in its DataSources are flushed into its mailbox (wrapped in Commands). Then, when the RuleUnit is quiescent, it remains subscribed to its DataSources so that all new operation performed on them get also automatically flushed into its mailbox.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 10 months
[JBoss JIRA] (JGRP-2355) TCP_NIO2 fails under Java 8
by Bela Ban (Jira)
[ https://issues.jboss.org/browse/JGRP-2355?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-2355:
--------------------------------
Option #1. But I always forget to switch to JDK 8 (from JDK 11, which I routinely use) when building...
> TCP_NIO2 fails under Java 8
> ---------------------------
>
> Key: JGRP-2355
> URL: https://issues.jboss.org/browse/JGRP-2355
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 4.1.1
> Reporter: Paul Ferraro
> Assignee: Bela Ban
> Priority: Critical
> Fix For: 4.1.2
>
>
> Because the 4.1.x releases are built with JDK11, I see the following at runtime when running under Java 8:
> {noformat}
> WARN [org.jgroups.protocols.TCP_NIO2] (TQ-Bundler-6,ejb,node-1) node-1: failed sending message to 127.0.0.1:7700: java.lang.NoSuchMethodError: java.nio.ByteBuffer.clear()Ljava/nio/ByteBuffer;
> {noformat}
> The problematic code seems to be here:
> https://github.com/belaban/JGroups/blob/master/src/org/jgroups/blocks/cs/...
> In JDK8, Buffer.clear() was final and returned a Buffer object (hence the need for your code to cast). However, in JDK11 Buffer.clear() is no longer final, allowing subclasses to override the return type, which ByteBuffer indeed does (to return a ByteBuffer). However, since JGroups 4.1.x is built with JDK11, when running on Java 8, the method is not found.
> N.B. There is a similar problem with uses of ByteBuffer.flip(). I didn't catch these at first since NioConnection.Reader.run() swallows Errors.
> There are 2 ways to fix this:
> 1. Ensure 4.1.x releases are built using JDK8 (since source is still compatible with Java 8)
> 2. Cast java.io.ByteBuffer to java.nio.Buffer when invoking clear() to avoid the NoSuchMethodError.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 10 months