[JBoss JIRA] (JGRP-1605) API changes
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1605?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-1605:
---------------------------
Description:
API changes to be done in 4.0, which break code:
* MessageDispatcher: remove MessageListener
* Merge AsyncRequestHandler and RequestHandler, OR make them 2 separate interfaces, ie. AsyncRH doesn't extend RH
* Remove @Deprecated methods, properties or classes
* Remove direct access to Message in JChannel.send() methods (to prevent passing in the same message more than once)
* Make {{RspFilter}} --> {{RspFilter<T>}}
* {{ProtocolStack.findProtocol(Class<?> clazz)}} should return generic type {{<T extends Protocol>>}}, so no casting is needed. Requires changes to a number of methods in the same class.
* Request<T>
was:
API changes to be done in 4.0, which break code:
* MessageDispatcher: remove MessageListener
* Merge AsyncRequestHandler and RequestHandler, OR make them 2 separate interfaces, ie. AsyncRH doesn't extend RH
* Remove @Deprecated methods, properties or classes
* Remove direct access to Message in JChannel.send() methods (to prevent passing in the same message more than once)
* Make {{RspFilter}} --> {{RspFilter<T>}}
* {{ProtocolStack.findProtocol(Class<?> clazz)}} should return generic type {{<T extends Protocol>>}}, so no casting is needed. Requires changes to a number of methods in the same class.
> API changes
> -----------
>
> Key: JGRP-1605
> URL: https://issues.jboss.org/browse/JGRP-1605
> Project: JGroups
> Issue Type: Task
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 4.0
>
>
> API changes to be done in 4.0, which break code:
> * MessageDispatcher: remove MessageListener
> * Merge AsyncRequestHandler and RequestHandler, OR make them 2 separate interfaces, ie. AsyncRH doesn't extend RH
> * Remove @Deprecated methods, properties or classes
> * Remove direct access to Message in JChannel.send() methods (to prevent passing in the same message more than once)
> * Make {{RspFilter}} --> {{RspFilter<T>}}
> * {{ProtocolStack.findProtocol(Class<?> clazz)}} should return generic type {{<T extends Protocol>>}}, so no casting is needed. Requires changes to a number of methods in the same class.
> * Request<T>
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 3 months
[JBoss JIRA] (DROOLS-1032) WebSphere JMS on Kie server produces errors in log
by Karel Suta (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1032?page=com.atlassian.jira.plugi... ]
Karel Suta commented on DROOLS-1032:
------------------------------------
Yes, I am able to reproduce it with manually created profile, tried in kie-server-integ-tests-common module.
> WebSphere JMS on Kie server produces errors in log
> --------------------------------------------------
>
> Key: DROOLS-1032
> URL: https://issues.jboss.org/browse/DROOLS-1032
> Project: Drools
> Issue Type: Bug
> Components: kie server
> Affects Versions: 6.4.x
> Environment: WebSphere 8.5.5.7
> Reporter: Karel Suta
> Assignee: Maciej Swiderski
> Labels: reported-by-qe
> Attachments: stacktrace.txt
>
>
> When I run WebSphere JMS tests for Kie server then SystemOut log gets filled by exception listed in attachment.
> It doesn't cause any error in Kie server functionality as error is created by WebSphereSecurityAdapter while JMS use JMSSecurityAdapter to get needed info, it just spam log making it almost unusable for searching for any real issue logged there.
> Caused by https://github.com/droolsjbpm/droolsjbpm-integration/blob/master/kie-serv...
> Maybe would be good to reduce log level there to be able to filter out this error.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 3 months
[JBoss JIRA] (DROOLS-1033) In kmodule.xml, the <kbase> name should be optional if all that kbase's ksessions are named (or if there is only 1 kbase)
by Geoffrey De Smet (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1033?page=com.atlassian.jira.plugi... ]
Geoffrey De Smet updated DROOLS-1033:
-------------------------------------
Priority: Minor (was: Major)
> In kmodule.xml, the <kbase> name should be optional if all that kbase's ksessions are named (or if there is only 1 kbase)
> -------------------------------------------------------------------------------------------------------------------------
>
> Key: DROOLS-1033
> URL: https://issues.jboss.org/browse/DROOLS-1033
> Project: Drools
> Issue Type: Enhancement
> Components: core engine
> Affects Versions: 6.3.0.Final
> Reporter: Geoffrey De Smet
> Assignee: Mario Fusco
> Priority: Minor
>
> Currently this kmodule.xml isn't accepted because the kbase names are missing:
> {code}
> <kmodule ...>
> <kbase packages="org.cars">
> <ksession name="carsKsession"/>
> </kbase>
> <kbase packages="org.planes">
> <ksession name="planesKsession"/>
> </kbase>
> </kmodule>
> {code}
> From OptaPlanner, we find what we need through the ksession name, so the kbase names can be anonymous (or uniquely generated - we don't care).
> Having to specify a unique kbase name, is an annoying hoop to jump through (including maintenance burden) - but more importantly it bloats our Quick Start minimal code examples of "using OptaPlanner with a KieContainer and Kjar".
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 3 months
[JBoss JIRA] (DROOLS-1033) In kmodule.xml, the <kbase> name should be optional if all that kbase's ksessions are named (or if there is only 1 kbase)
by Geoffrey De Smet (JIRA)
Geoffrey De Smet created DROOLS-1033:
----------------------------------------
Summary: In kmodule.xml, the <kbase> name should be optional if all that kbase's ksessions are named (or if there is only 1 kbase)
Key: DROOLS-1033
URL: https://issues.jboss.org/browse/DROOLS-1033
Project: Drools
Issue Type: Enhancement
Components: core engine
Affects Versions: 6.3.0.Final
Reporter: Geoffrey De Smet
Assignee: Mario Fusco
Currently this kmodule.xml isn't accepted because the kbase names are missing:
{code}
<kmodule ...>
<kbase packages="org.cars">
<ksession name="carsKsession"/>
</kbase>
<kbase packages="org.planes">
<ksession name="planesKsession"/>
</kbase>
</kmodule>
{code}
>From OptaPlanner, we find what we need through the ksession name, so the kbase names can be anonymous (or uniquely generated - we don't care).
Having to specify a unique kbase name, is an annoying hoop to jump through (including maintenance burden) - but more importantly it bloats our Quick Start minimal code examples of "using OptaPlanner with a KieContainer and Kjar".
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 3 months
[JBoss JIRA] (DROOLS-1032) WebSphere JMS on Kie server produces errors in log
by Maciej Swiderski (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1032?page=com.atlassian.jira.plugi... ]
Maciej Swiderski commented on DROOLS-1032:
------------------------------------------
WebSphereAdapter is used by JMSSecurityAdapter so there seems to be an issue with registry configuration as it should not throw execution when finding user's groups. We can lower the log level and maybe put the stack trace to debug but there seems to be another issue with WAS registry configuration. Can this be reproduced without cargo?
> WebSphere JMS on Kie server produces errors in log
> --------------------------------------------------
>
> Key: DROOLS-1032
> URL: https://issues.jboss.org/browse/DROOLS-1032
> Project: Drools
> Issue Type: Bug
> Components: kie server
> Affects Versions: 6.4.x
> Environment: WebSphere 8.5.5.7
> Reporter: Karel Suta
> Assignee: Maciej Swiderski
> Labels: reported-by-qe
> Attachments: stacktrace.txt
>
>
> When I run WebSphere JMS tests for Kie server then SystemOut log gets filled by exception listed in attachment.
> It doesn't cause any error in Kie server functionality as error is created by WebSphereSecurityAdapter while JMS use JMSSecurityAdapter to get needed info, it just spam log making it almost unusable for searching for any real issue logged there.
> Caused by https://github.com/droolsjbpm/droolsjbpm-integration/blob/master/kie-serv...
> Maybe would be good to reduce log level there to be able to filter out this error.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 3 months