[JBoss JIRA] (DROOLS-1541) newInsert.outIdentifier/getValue.identifier don't refer via fact handle (as per doc.), get only original, not replacement, fact object instances
by Matteo Mortari (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1541?page=com.atlassian.jira.plugi... ]
Matteo Mortari commented on DROOLS-1541:
----------------------------------------
I don't believe there is an error in the documentation, neither there is an error in the code.
I believe the real problem here is mixing two api approaches, using the Commands Vs calling operations directly on the KieSession. Therefore, if one had to use only the Commands API, none of the mentioned issue would manifest.
Anyway, given the Commands API does not support the case of calling "update" and replacing the actual object instance, there could be an edge-case of mixing the two approaches.
But even in the case of mixing Commands API and calling operations directly on the KieSession, it is (still) *incorrect* to reuse a ExecutionResults after subsequent operations have been performed directly on the KieSession.
This is because ExecutionResults represents a "snapshot" of the results of the execution of the Commands, contextually to the KieSession.execute(Command c).
Once the execute returns a given ExecutionResults instance, the KieSession does NOT keep a reference to it, and that given instance will not be updated following subsequent KieSession API call. If the user want an updated ExecutionResults, it will require a new execute of Commands, which will return a consistent (new, up-to-date) ExecutionResults instance.
I want to stress the fact the ExecutionResults represent the result contextually to the Commands API call.
As an example see below, although I would NOT recommend it as it mixes Commands API and calling operations directly on the KieSession.
{code:java}
// Step1
ExecutionResults resultsA = session.execute(
CommandFactory.newBatchExecution( Arrays.asList(new Command[]{
CommandFactory.newInsert( new Measurement("color", "red"), "my_out_ID" ),
CommandFactory.newFireAllRules()
}))
);
FactHandle redFH = (FactHandle) resultsA.getFactHandle("my_out_ID");
// Step2
Object replacedInstance = new Measurement("color", "reddish");
session.update(redFH, replacedInstance );
session.fireAllRules();
// Step3
ExecutionResults resultsB = session.execute(
CommandFactory.newBatchExecution( Arrays.asList(new Command[]{
CommandFactory.newGetObject(redFH, "my_out_ID")
}))
);
assertEquals( replacedInstance, resultsB.getValue("my_out_ID") );
{code}
At step2, it would be INCORRECT to re-use the ExecutionResults coming from step1. The more correct approach in this case would be to retrieve an up-to-date ExecutionResults instance by calling a new execute Commands, i.e.: step3.
I hope this clarifies the misunderstanding.
If I incorrectly interpreted your original description, kindly let us know, please (eventually re-opening this jira)
Thank you,
MM
> newInsert.outIdentifier/getValue.identifier don't refer via fact handle (as per doc.), get only original, not replacement, fact object instances
> ------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: DROOLS-1541
> URL: https://issues.jboss.org/browse/DROOLS-1541
> Project: Drools
> Issue Type: Bug
> Components: core engine, kie server
> Affects Versions: 6.3.0.Final, 6.5.0.Final
> Reporter: Daniel B.
> Assignee: Mario Fusco
>
> The identifier passed to the {{KieCommands.newInsert}} method's {{outIdentifier}} parameter and to the {{ExecutionResults.getValue}} method's {{identifier}} parameter doesn't actually refer to the fact object _via the fact handle_ as described in the documentation of {{InsertObjectCommand}}).
> The documentation says:
> {quote}
> 11.2.2. InsertObjectCommand
> ...
> outIdentifier Id to identify the FactHandle created in the object insertion and added to the execution results
> {quote}
> Although the Drools code in method {{InsertObjectCommand.execute}} does map the given identifier both to the original object and to the fact handle, the code in method {{ExecutionResultImpl.getValue}} retrieves the _original_ object instead of retrieving the object _currently associated with the fact handle_.
> This means that if the original fact object instance is replaced with a different instance (e.g., with {{update(kcontext.getKieRuntime().getFactHandle($oldObj), newObj);}} in the rules), then {{ExecutionResults.getValue}} will return the _original_ fact object, not the _current_ value of the fact object (the object instance currently associated with the fact handle created in the {{newInsert}} call).
> That in turn means that immutable fact object instances cannot be used with {{ExecutionResults.getValue}}.
> (It's not 100% clear that it's the code that is wrong (relative to the documentation) rather than it being documentation that's wrong (relative to the code). However, the behavior described by the documentation seems more useful than the behavior exhibited by the code.)
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 8 months
[JBoss JIRA] (JGRP-2168) JChannel(Collection<Protocol>) constructor clears protocol properties with non-default converter whose associated system property is not defined
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/JGRP-2168?page=com.atlassian.jira.plugin.... ]
Paul Ferraro commented on JGRP-2168:
------------------------------------
{quote}I did change the InitialHosts converter to return a null value, which won't overwrite the value set programmatically.{quote}
That should do the trick.
{quote}Which other converters do cause issues?{quote}
If I'm not mistaken, the converter for TCPGOSSIP initial_hosts has the same issue.
Re: system properties overwriting explicitly set values - that's fine.
> JChannel(Collection<Protocol>) constructor clears protocol properties with non-default converter whose associated system property is not defined
> ------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: JGRP-2168
> URL: https://issues.jboss.org/browse/JGRP-2168
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.6.13, 4.0.1
> Reporter: Paul Ferraro
> Assignee: Bela Ban
> Fix For: 4.0.3
>
>
> WildFly 11 recently started using the new JChannel(Protocol...) constructor for creating channels. This has resulted in the inability to configure certain protocol properties, most notably, initial_hosts for TCPPING.
> Because this constructor calls resolveAndAssignFields(...) with an empty map, if a property was explicitly set, and its associated system property does not exist, and that property uses a non-default converter, then it will have its value undefined (or, more specifically, set to whatever the converter does with a null value).
> Additionally, if the assocated system property did exist, it would take precedence over an explicitly set value. I don't think that's a good idea.
> Consider the following:
> {code:java}
> TCP transport = new TCP();
> transport.setBindAddress(InetAddress.getLocalHost());
> transport.setBindPort(9600);
> TCPPING ping = new TCPPING();
> ping.setInitialHosts(Collections.singletonList(new IpAddress(transport.getBindAddress(), transport.getBindPort())));
> JChannel channel = new JChannel(transport, ping);
> assert !ping.getInitialHosts().isEmpty() : "No initial hosts!";
> {code}
> Side note: new JChannel(Collection<Protocol>) should really be new JChannel(List<Protocol>), since the collection should be ordered.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 8 months
[JBoss JIRA] (WFCORE-1282) Unable to create HTTPS connection using *ECDH_RSA* cipher suites / kECDHr cipher string
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1282?page=com.atlassian.jira.plugi... ]
Kabir Khan updated WFCORE-1282:
-------------------------------
Fix Version/s: 3.0.0.Beta20
(was: 3.0.0.Beta19)
> Unable to create HTTPS connection using *ECDH_RSA* cipher suites / kECDHr cipher string
> ---------------------------------------------------------------------------------------
>
> Key: WFCORE-1282
> URL: https://issues.jboss.org/browse/WFCORE-1282
> Project: WildFly Core
> Issue Type: Bug
> Components: Security
> Affects Versions: 1.0.2.Final
> Environment: Oracle Java
> Reporter: Martin Choma
> Assignee: Darran Lofthouse
> Priority: Critical
> Fix For: 3.0.0.Beta20
>
> Attachments: client_debug_eap6.log, client_debug_eap7.log, server-cert-key-ec.jks, server_debug_eap6.log, server_debug_eap7.log
>
>
> User using these cipher suites / cipher name in EAP6 won't be able to use it in EAP7.
> Setting as critical as these cipher suites, are considered for strong and widely used in my opinion.
> In server log, error "no cipher suites in common" can be seen using -Djavax.net.debug=all.
> Note, that analogous configuration in EAP6 works fine.
> Issue can be seen on Oracle Java only, as on OpenJDK / IBM these suites are not provided by method getDefaultCipherSuites().
> Also is it possible to log "no cipher suites in common" and similar tls handshake errors without -Djavax.net.debug for better troubleshooting?
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 8 months
[JBoss JIRA] (WFCORE-887) "Deprecate" using an expression in model refs to interfaces
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFCORE-887?page=com.atlassian.jira.plugin... ]
Kabir Khan updated WFCORE-887:
------------------------------
Fix Version/s: 3.0.0.Beta20
(was: 3.0.0.Beta19)
> "Deprecate" using an expression in model refs to interfaces
> -----------------------------------------------------------
>
> Key: WFCORE-887
> URL: https://issues.jboss.org/browse/WFCORE-887
> Project: WildFly Core
> Issue Type: Task
> Components: Domain Management
> Reporter: Brian Stansberry
> Fix For: 3.0.0.Beta20
>
>
> SocketBindingGroupResourceDefinition and OutboundSocketBindingResourceDefinition both have attributes that represent model refs to interface resources, but which also allow expressions.
> Model references should not allow expressions. These were "grandfathered in" when the large scale expression support roll out happened for AS 7.2 / EAP 6.1.
> There's no metadata facility to record that expression support is deprecated, but the add handler for these should log a WARN if they encounter an expression. Hopefully in EAP 8 we can then remove expression support.
> We should look for other cases like this too, although those changes should be separate JIRAs.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 8 months
[JBoss JIRA] (JGRP-2168) JChannel(Collection<Protocol>) constructor clears protocol properties with non-default converter whose associated system property is not defined
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/JGRP-2168?page=com.atlassian.jira.plugin.... ]
Paul Ferraro edited comment on JGRP-2168 at 5/9/17 8:14 AM:
------------------------------------------------------------
{quote}First off: I cannot change the Collection to a List as this would be an API change.{quote}
Why not add a new constructor that accepts a List<? extends Protocol> and deprecate the old one?
was (Author: pferraro):
{quote}First off: I cannot change the Collection to a List as this would be an API change.{quote}
Why can't you add a new constructor that accepts a List and deprecate the old one?
> JChannel(Collection<Protocol>) constructor clears protocol properties with non-default converter whose associated system property is not defined
> ------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: JGRP-2168
> URL: https://issues.jboss.org/browse/JGRP-2168
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.6.13, 4.0.1
> Reporter: Paul Ferraro
> Assignee: Bela Ban
> Fix For: 4.0.3
>
>
> WildFly 11 recently started using the new JChannel(Protocol...) constructor for creating channels. This has resulted in the inability to configure certain protocol properties, most notably, initial_hosts for TCPPING.
> Because this constructor calls resolveAndAssignFields(...) with an empty map, if a property was explicitly set, and its associated system property does not exist, and that property uses a non-default converter, then it will have its value undefined (or, more specifically, set to whatever the converter does with a null value).
> Additionally, if the assocated system property did exist, it would take precedence over an explicitly set value. I don't think that's a good idea.
> Consider the following:
> {code:java}
> TCP transport = new TCP();
> transport.setBindAddress(InetAddress.getLocalHost());
> transport.setBindPort(9600);
> TCPPING ping = new TCPPING();
> ping.setInitialHosts(Collections.singletonList(new IpAddress(transport.getBindAddress(), transport.getBindPort())));
> JChannel channel = new JChannel(transport, ping);
> assert !ping.getInitialHosts().isEmpty() : "No initial hosts!";
> {code}
> Side note: new JChannel(Collection<Protocol>) should really be new JChannel(List<Protocol>), since the collection should be ordered.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 8 months
[JBoss JIRA] (WFCORE-2068) HTTPSConnectionWithCLITestCase and HTTPSManagementInterfaceTestCase Failing Due To Native Protocol Issue
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2068?page=com.atlassian.jira.plugi... ]
Kabir Khan updated WFCORE-2068:
-------------------------------
Fix Version/s: 3.0.0.Beta20
(was: 3.0.0.Beta19)
> HTTPSConnectionWithCLITestCase and HTTPSManagementInterfaceTestCase Failing Due To Native Protocol Issue
> --------------------------------------------------------------------------------------------------------
>
> Key: WFCORE-2068
> URL: https://issues.jboss.org/browse/WFCORE-2068
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management, Remoting, Test Suite
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Priority: Blocker
> Fix For: 3.0.0.Beta20
>
>
> The listed test case is failing during clean up with the following error: -
> {noformat}
> java.io.IOException: java.io.IOException: WFLYPRT0054: Channel closed
> at org.jboss.as.protocol.mgmt.ManagementClientChannelStrategy$Establishing.getChannel(ManagementClientChannelStrategy.java:166)
> at org.jboss.as.controller.client.impl.RemotingModelControllerClient.getOrCreateChannel(RemotingModelControllerClient.java:135)
> at org.jboss.as.controller.client.impl.RemotingModelControllerClient$1.getChannel(RemotingModelControllerClient.java:59)
> at org.jboss.as.protocol.mgmt.ManagementChannelHandler.executeRequest(ManagementChannelHandler.java:135)
> at org.jboss.as.protocol.mgmt.ManagementChannelHandler.executeRequest(ManagementChannelHandler.java:110)
> at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeRequest(AbstractModelControllerClient.java:263)
> at org.jboss.as.controller.client.impl.AbstractModelControllerClient.execute(AbstractModelControllerClient.java:168)
> at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeForResult(AbstractModelControllerClient.java:147)
> at org.jboss.as.controller.client.impl.AbstractModelControllerClient.execute(AbstractModelControllerClient.java:80)
> {noformat}
> The stage of the test using HTTP Upgrade over a HTTPS connection appears to be working fine, the issue is with the native management interface used for test clean up.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 8 months
[JBoss JIRA] (WFCORE-2016) Change sasl-authentication-factor for management auth works after reload, but not after server restart
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2016?page=com.atlassian.jira.plugi... ]
Kabir Khan updated WFCORE-2016:
-------------------------------
Fix Version/s: 3.0.0.Beta20
(was: 3.0.0.Beta19)
> Change sasl-authentication-factor for management auth works after reload, but not after server restart
> ------------------------------------------------------------------------------------------------------
>
> Key: WFCORE-2016
> URL: https://issues.jboss.org/browse/WFCORE-2016
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management, Security
> Reporter: Zach Rhoads
> Assignee: Darran Lofthouse
> Fix For: 3.0.0.Beta20
>
>
> I can successfully configure a new sasl-authentication-factory and assign it to the management interface:
> {code}
> /subsystem=elytron/filesystem-realm=exampleFsRealm:add(path=fs-realm-users,relative-to=jboss.server.config.dir)
> /subsystem=elytron/filesystem-realm=exampleFsRealm/identity=user1:add()
> /subsystem=elytron/filesystem-realm=exampleFsRealm/identity=user1:set-password(clear={password="password123"})
> /subsystem=elytron/filesystem-realm=exampleFsRealm/identity=user1:add-attribute(name=Roles, value=["Admin","Guest"])
> /subsystem=elytron/simple-role-decoder=from-roles-attribute:add(attribute=Roles)
> /subsystem=elytron/security-domain=exampleFsSD:add(realms=[{realm=exampleFsRealm,role-decoder=from-roles-attribute}],default-realm=exampleFsRealm,permission-mapper=login-permission-mapper)
> /subsystem=elytron/sasl-authentication-factory=example-sasl-auth:add(sasl-server-factory=configured,security-domain=exampleFsSD,mechanism-configurations=[{mechanism-name=DIGEST-MD5,mechanism-realm-configurations=[{realm-name=exampleSaslRealm}]}])
> /core-service=management/management-interface=http-interface:write-attribute(name=http-upgrade.sasl-authentication-factory, value=example-sasl-auth)
> reload
> {code}
> after reload, i am forced to re-authenticate and it succeeds:
> {code}
> [standalone@localhost:9990 /] reload
> Authenticating against security realm: exampleSaslRealm
> Username: user1
> Password:
> [standalone@localhost:9990 /]
> {code}
> Once i restart the server though and try to connect, i get a timeout:
> {code}
> $ ./jboss-cli.sh -c
> Failed to connect to the controller: The controller is not available at localhost:9990: java.net.ConnectException: WFLYPRT0023: Could not connect to remote+http://localhost:9990. The connection timed out: WFLYPRT0023: Could not connect to remote+http://localhost:9990. The connection timed out
> {code}
> It also fails if i force no local auth:
> {code}
> $ ./jboss-cli.sh -c --no-local-auth
> Failed to connect to the controller: The controller is not available at localhost:9990: java.net.ConnectException: WFLYPRT0023: Could not connect to remote+http://localhost:9990. The connection timed out: WFLYPRT0023: Could not connect to remote+http://localhost:9990. The connection timed out
> {code}/
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 8 months