[JBoss JIRA] (WFLY-6134) Deployment with @JMSConnectionFactoryDefinitions annotation cannot be deployed
by Jeff Mesnil (JIRA)
[ https://issues.jboss.org/browse/WFLY-6134?page=com.atlassian.jira.plugin.... ]
Jeff Mesnil moved JBEAP-3268 to WFLY-6134:
------------------------------------------
Project: WildFly (was: JBoss Enterprise Application Platform)
Key: WFLY-6134 (was: JBEAP-3268)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: JMS
(was: JMS)
Target Release: (was: 7.0.0.GA)
Affects Version/s: 10.0.0.Final
(was: 7.0.0.ER5)
Affects Testing: (was: Regression)
> Deployment with @JMSConnectionFactoryDefinitions annotation cannot be deployed
> ------------------------------------------------------------------------------
>
> Key: WFLY-6134
> URL: https://issues.jboss.org/browse/WFLY-6134
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Affects Versions: 10.0.0.Final
> Reporter: Jeff Mesnil
> Assignee: Jeff Mesnil
> Priority: Blocker
>
> There is regression in EAP 7.0.0.ER5 against EAP 7.0.0.ER4 hit by TCK 7.
> Deployment of MDB which contains:
> {code}
> @JMSConnectionFactoryDefinition(
> name = "java:jboss/exported/MyConnectionFactory",
> resourceAdapter = "activemq-ra",
> properties = {
> "connectors=http-connector",}
> )
> {code}
> definition of connection factory fails with:
> {code}
> 09:19:10,704 ERROR [org.jboss.as.controller.management-operation] (DeploymentScanner-threads - 1) WFLYCTL0013: Operation ("deploy") failed - address: ([("deployment" => "mdb.jar")]) - failure description: {
> "WFLYCTL0180: Services with missing/unavailable dependencies" => ["jboss.connector.direct-connection-factory-activator.java:jboss/exported/MyConnectionFactory is missing [jboss.ra.deployer.\"activemq-ra.rar\"]"],
> "WFLYCTL0288: One or more services were unable to start due to one or more indirect dependencies not being available." => {
> "Services that were unable to start:" => [
> "jboss.deployment.unit.\"mdb.jar\".component.mdb1.JndiBindingsService",
> "jboss.deployment.unit.\"mdb.jar\".component.mdb1.START",
> "jboss.deployment.unit.\"mdb.jar\".deploymentCompleteService",
> "jboss.deployment.unit.\"mdb.jar\".jndiDependencyService",
> "jboss.deployment.unit.\"mdb.jar\".moduleDeploymentRuntimeInformationStart",
> "jboss.naming.context.java.comp.mdb.mdb.mdb1.env.\"org.jboss.qa.hornetq.apps.mdb.LocalMdbFromQueueAnnotated\".cf"
> ],
> "Services that may be the cause:" => [
> "jboss.connection-factory.reference-factory.jboss.naming.context.java.jboss.exported.MyConnectionFactory",
> "jboss.ra.deployer.\"activemq-ra.rar\""
> ]
> }
> }
> {code}
> Failed TCK tests:
> {code}
> com/sun/ts/tests/jms/ee20/resourcedefs/annotations/Client.java#checkClientIDOnDurableConnFactoryTest FAIL 20
> com/sun/ts/tests/jms/ee20/resourcedefs/annotations/Client.java#sendAndRecvQueueTestFromAppClient FAIL 20
> com/sun/ts/tests/jms/ee20/resourcedefs/annotations/Client.java#sendAndRecvQueueTestFromEjbClient FAIL 20
> com/sun/ts/tests/jms/ee20/resourcedefs/annotations/Client.java#sendAndRecvQueueTestFromJspClient FAIL 20
> com/sun/ts/tests/jms/ee20/resourcedefs/annotations/Client.java#sendAndRecvQueueTestFromServletClient FAIL 20
> com/sun/ts/tests/jms/ee20/resourcedefs/annotations/Client.java#sendAndRecvTopicTestFromAppClient FAIL 20
> com/sun/ts/tests/jms/ee20/resourcedefs/annotations/Client.java#sendAndRecvTopicTestFromEjbClient FAIL 20
> com/sun/ts/tests/jms/ee20/resourcedefs/annotations/Client.java#sendAndRecvTopicTestFromJspClient FAIL 20
> com/sun/ts/tests/jms/ee20/resourcedefs/annotations/Client.java#sendAndRecvTopicTestFromServletClient FAIL 20
> com/sun/ts/tests/jms/ee20/resourcedefs/annotations/Client.java#verifyLookupWithRAElementSpecifiedTest
> com/sun/ts/tests/jms/ee20/resourcedefs/descriptor/Client.java#checkClientIDOnDurableConnFactoryTest_from_appclient FAIL 20
> com/sun/ts/tests/jms/ee20/resourcedefs/descriptor/Client.java#checkClientIDOnDurableConnFactoryTest_from_ejb FAIL 20
> com/sun/ts/tests/jms/ee20/resourcedefs/descriptor/Client.java#checkClientIDOnDurableConnFactoryTest_from_jsp FAIL 20
> com/sun/ts/tests/jms/ee20/resourcedefs/descriptor/Client.java#checkClientIDOnDurableConnFactoryTest_from_servlet FAIL 20
> com/sun/ts/tests/jms/ee20/resourcedefs/descriptor/Client.java#sendAndRecvQueueTest_from_appclient FAIL 20
> com/sun/ts/tests/jms/ee20/resourcedefs/descriptor/Client.java#sendAndRecvQueueTest_from_ejb FAIL 20
> com/sun/ts/tests/jms/ee20/resourcedefs/descriptor/Client.java#sendAndRecvQueueTest_from_jsp FAIL 20
> com/sun/ts/tests/jms/ee20/resourcedefs/descriptor/Client.java#sendAndRecvQueueTest_from_servlet FAIL 20
> com/sun/ts/tests/jms/ee20/resourcedefs/descriptor/Client.java#sendAndRecvTopicTest_from_appclient FAIL 20
> com/sun/ts/tests/jms/ee20/resourcedefs/descriptor/Client.java#sendAndRecvTopicTest_from_ejb FAIL 20
> com/sun/ts/tests/jms/ee20/resourcedefs/descriptor/Client.java#sendAndRecvTopicTest_from_jsp FAIL 20
> com/sun/ts/tests/jms/ee20/resourcedefs/descriptor/Client.java#sendAndRecvTopicTest_from_servlet FAIL 20
> com/sun/ts/tests/jms/ee20/resourcedefs/descriptor/Client.java#verifyLookupWithRAElementSpecifiedTest_from_appclient FAIL 20
> com/sun/ts/tests/jms/ee20/resourcedefs/descriptor/Client.java#verifyLookupWithRAElementSpecifiedTest_from_ejb FAIL 20
> com/sun/ts/tests/jms/ee20/resourcedefs/descriptor/Client.java#verifyLookupWithRAElementSpecifiedTest_from_jsp FAIL 20
> com/sun/ts/tests/jms/ee20/resourcedefs/descriptor/Client.java#verifyLookupWithRAElementSpecifiedTest_from_servlet
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 2 months
[JBoss JIRA] (WFLY-6133) Add --connection-properties to datasource add command
by Alexey Loubyansky (JIRA)
[ https://issues.jboss.org/browse/WFLY-6133?page=com.atlassian.jira.plugin.... ]
Alexey Loubyansky updated WFLY-6133:
------------------------------------
Description: After WFCORE-1362 has been merged, a test for it has to be added to org.jboss.as.test.integration.management.cli.DataSourceTestCase. (was: It isn't possible to add connection-properties using {{datasource add}} command. They can be added after the DS is created by directly working on {{/subsystem=datasources/data-source=XX/connection-properties}}
It would be nice to have parameter --connection-properties in datasource add command. It could work the same way as {{xa-data-source add --name=DS --xa-datasource-properties=}})
> Add --connection-properties to datasource add command
> -----------------------------------------------------
>
> Key: WFLY-6133
> URL: https://issues.jboss.org/browse/WFLY-6133
> Project: WildFly
> Issue Type: Enhancement
> Components: CLI
> Reporter: Alexey Loubyansky
> Assignee: Alexey Loubyansky
>
> After WFCORE-1362 has been merged, a test for it has to be added to org.jboss.as.test.integration.management.cli.DataSourceTestCase.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 2 months
[JBoss JIRA] (WFCORE-1363) Add --connection-properties to datasource add command
by Alexey Loubyansky (JIRA)
Alexey Loubyansky created WFCORE-1363:
-----------------------------------------
Summary: Add --connection-properties to datasource add command
Key: WFCORE-1363
URL: https://issues.jboss.org/browse/WFCORE-1363
Project: WildFly Core
Issue Type: Enhancement
Components: CLI
Reporter: Alexey Loubyansky
Assignee: Alexey Loubyansky
It isn't possible to add connection-properties using {{datasource add}} command. They can be added after the DS is created by directly working on {{/subsystem=datasources/data-source=XX/connection-properties}}
It would be nice to have parameter --connection-properties in datasource add command. It could work the same way as {{xa-data-source add --name=DS --xa-datasource-properties=}}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 2 months
[JBoss JIRA] (WFLY-6133) Add --connection-properties to datasource add command
by Alexey Loubyansky (JIRA)
[ https://issues.jboss.org/browse/WFLY-6133?page=com.atlassian.jira.plugin.... ]
Alexey Loubyansky moved WFCORE-1363 to WFLY-6133:
-------------------------------------------------
Project: WildFly (was: WildFly Core)
Key: WFLY-6133 (was: WFCORE-1363)
Component/s: CLI
(was: CLI)
> Add --connection-properties to datasource add command
> -----------------------------------------------------
>
> Key: WFLY-6133
> URL: https://issues.jboss.org/browse/WFLY-6133
> Project: WildFly
> Issue Type: Enhancement
> Components: CLI
> Reporter: Alexey Loubyansky
> Assignee: Alexey Loubyansky
>
> It isn't possible to add connection-properties using {{datasource add}} command. They can be added after the DS is created by directly working on {{/subsystem=datasources/data-source=XX/connection-properties}}
> It would be nice to have parameter --connection-properties in datasource add command. It could work the same way as {{xa-data-source add --name=DS --xa-datasource-properties=}}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 2 months
[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:
* DONE: MessageDispatcher: remove MessageListener
* DONE: Merge AsyncRequestHandler and RequestHandler, OR make them 2 separate interfaces, ie. AsyncRH doesn't extend RH
* DONE: Remove @Deprecated methods, properties or classes
* NOTDONE: Remove direct access to Message in JChannel.send() methods (to prevent passing in the same message more than once)
** Power users often want to access a message object directly, e.g. set flags or add a header, so I won't remove this method
* NOTDONE: Make {{RspFilter}} --> {{RspFilter<T>}}
** We need to be able to handle objects of type T *and* Throwable, so we cannot change this to 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.
* DONE: Request<T>
* DONE: RpcDispatcher: only 1 Marshaller, not separate ones for reqs and rsps
* RpcDispatcher: use CompletableFuture instead of NotifiyingFuture
* DONE: Rsp: see https://issues.jboss.org/browse/JGRP-2011
was:
API changes to be done in 4.0, which break code:
* DONE: MessageDispatcher: remove MessageListener
* DONE: Merge AsyncRequestHandler and RequestHandler, OR make them 2 separate interfaces, ie. AsyncRH doesn't extend RH
* DONE: 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)
* NOTDONE: Make {{RspFilter}} --> {{RspFilter<T>}}
** We need to be able to handle objects of type T *and* Throwable, so we cannot change this to 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.
* DONE: Request<T>
* DONE: RpcDispatcher: only 1 Marshaller, not separate ones for reqs and rsps
* RpcDispatcher: use CompletableFuture instead of NotifiyingFuture
* DONE: Rsp: see https://issues.jboss.org/browse/JGRP-2011
> 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:
> * DONE: MessageDispatcher: remove MessageListener
> * DONE: Merge AsyncRequestHandler and RequestHandler, OR make them 2 separate interfaces, ie. AsyncRH doesn't extend RH
> * DONE: Remove @Deprecated methods, properties or classes
> * NOTDONE: Remove direct access to Message in JChannel.send() methods (to prevent passing in the same message more than once)
> ** Power users often want to access a message object directly, e.g. set flags or add a header, so I won't remove this method
> * NOTDONE: Make {{RspFilter}} --> {{RspFilter<T>}}
> ** We need to be able to handle objects of type T *and* Throwable, so we cannot change this to 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.
> * DONE: Request<T>
> * DONE: RpcDispatcher: only 1 Marshaller, not separate ones for reqs and rsps
> * RpcDispatcher: use CompletableFuture instead of NotifiyingFuture
> * DONE: Rsp: see https://issues.jboss.org/browse/JGRP-2011
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 2 months
[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:
* DONE: MessageDispatcher: remove MessageListener
* DONE: Merge AsyncRequestHandler and RequestHandler, OR make them 2 separate interfaces, ie. AsyncRH doesn't extend RH
* DONE: 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)
* NOTDONE: Make {{RspFilter}} --> {{RspFilter<T>}}
** We need to be able to handle objects of type T *and* Throwable, so we cannot change this to 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.
* DONE: Request<T>
* DONE: RpcDispatcher: only 1 Marshaller, not separate ones for reqs and rsps
* RpcDispatcher: use CompletableFuture instead of NotifiyingFuture
* DONE: Rsp: see https://issues.jboss.org/browse/JGRP-2011
was:
API changes to be done in 4.0, which break code:
* DONE: MessageDispatcher: remove MessageListener
* Merge AsyncRequestHandler and RequestHandler, OR make them 2 separate interfaces, ie. AsyncRH doesn't extend RH
* DONE: 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)
* NOTDONE: Make {{RspFilter}} --> {{RspFilter<T>}}
** We need to be able to handle objects of type T *and* Throwable, so we cannot change this to 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.
* DONE: Request<T>
* DONE: RpcDispatcher: only 1 Marshaller, not separate ones for reqs and rsps
* RpcDispatcher: use CompletableFuture instead of NotifiyingFuture
* DONE: Rsp: see https://issues.jboss.org/browse/JGRP-2011
> 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:
> * DONE: MessageDispatcher: remove MessageListener
> * DONE: Merge AsyncRequestHandler and RequestHandler, OR make them 2 separate interfaces, ie. AsyncRH doesn't extend RH
> * DONE: 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)
> * NOTDONE: Make {{RspFilter}} --> {{RspFilter<T>}}
> ** We need to be able to handle objects of type T *and* Throwable, so we cannot change this to 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.
> * DONE: Request<T>
> * DONE: RpcDispatcher: only 1 Marshaller, not separate ones for reqs and rsps
> * RpcDispatcher: use CompletableFuture instead of NotifiyingFuture
> * DONE: Rsp: see https://issues.jboss.org/browse/JGRP-2011
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 2 months
[JBoss JIRA] (LOGTOOL-91) Add ability to provide constant values for properties
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/LOGTOOL-91?page=com.atlassian.jira.plugin... ]
David Lloyd commented on LOGTOOL-91:
------------------------------------
Yeah looks good. I'd probably default to 0 rather than MIN_VALUE though.
> Add ability to provide constant values for properties
> -----------------------------------------------------
>
> Key: LOGTOOL-91
> URL: https://issues.jboss.org/browse/LOGTOOL-91
> Project: Log Tool
> Issue Type: Feature Request
> Reporter: David Lloyd
> Assignee: James Perkins
>
> Right now I have to do this:
> {code}
> @Message(id = 28, value = "An unexpected protocol error occurred")
> XAException protocolErrorXA(@Property int errorCode);
> // ... then later ...
> throw Log.log.protocolErrorXA(XAException.XAER_RMFAIL);
> {code}
> I'd rather be able to do this:
> {code}
> @Message(id = 28, value = "An unexpected protocol error occurred")
> @Property(name = "errorCode", intValue = XAException.XAER_RMFAIL)
> XAException protocolErrorXA();
> // ... then later ...
> throw Log.log.protocolErrorXA();
> {code}
> The same annotation ({{@Property}}) could be reused by making it multi-valued (i.e. invisible wrapper annotation) and adding in defaulted {{xxxValue}} parameters (primitive types, {{Class<XX>}}, and {{String}}) which are rejected when applied directly to a method parameter.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 2 months
[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:
* DONE: MessageDispatcher: remove MessageListener
* Merge AsyncRequestHandler and RequestHandler, OR make them 2 separate interfaces, ie. AsyncRH doesn't extend RH
* DONE: 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)
* NOTDONE: Make {{RspFilter}} --> {{RspFilter<T>}}
** We need to be able to handle objects of type T *and* Throwable, so we cannot change this to 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.
* DONE: Request<T>
* DONE: RpcDispatcher: only 1 Marshaller, not separate ones for reqs and rsps
* RpcDispatcher: use CompletableFuture instead of NotifiyingFuture
* DONE: Rsp: see https://issues.jboss.org/browse/JGRP-2011
was:
API changes to be done in 4.0, which break code:
* DONE: MessageDispatcher: remove MessageListener
* Merge AsyncRequestHandler and RequestHandler, OR make them 2 separate interfaces, ie. AsyncRH doesn't extend RH
* DONE: 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)
* NOTDONE: Make {{RspFilter}} --> {{RspFilter<T>}}
** We need to be able to handle objects of type T *and* Throwable, so we cannot change this to 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.
* DONE: Request<T>
* RpcDispatcher: only 1 Marshaller, not separate ones for reqs and rsps
* RpcDispatcher: use CompletableFuture instead of NotifiyingFuture
* DONE: Rsp: see https://issues.jboss.org/browse/JGRP-2011
> 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:
> * DONE: MessageDispatcher: remove MessageListener
> * Merge AsyncRequestHandler and RequestHandler, OR make them 2 separate interfaces, ie. AsyncRH doesn't extend RH
> * DONE: 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)
> * NOTDONE: Make {{RspFilter}} --> {{RspFilter<T>}}
> ** We need to be able to handle objects of type T *and* Throwable, so we cannot change this to 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.
> * DONE: Request<T>
> * DONE: RpcDispatcher: only 1 Marshaller, not separate ones for reqs and rsps
> * RpcDispatcher: use CompletableFuture instead of NotifiyingFuture
> * DONE: Rsp: see https://issues.jboss.org/browse/JGRP-2011
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 2 months
[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:
* DONE: MessageDispatcher: remove MessageListener
* Merge AsyncRequestHandler and RequestHandler, OR make them 2 separate interfaces, ie. AsyncRH doesn't extend RH
* DONE: 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)
* NOTDONE: Make {{RspFilter}} --> {{RspFilter<T>}}
** We need to be able to handle objects of type T *and* Throwable, so we cannot change this to 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.
* DONE: Request<T>
* RpcDispatcher: only 1 Marshaller, not separate ones for reqs and rsps
* RpcDispatcher: use CompletableFuture instead of NotifiyingFuture
* DONE: Rsp: see https://issues.jboss.org/browse/JGRP-2011
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
* DONE: 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)
* NOTDONE: Make {{RspFilter}} --> {{RspFilter<T>}}
** We need to be able to handle objects of type T *and* Throwable, so we cannot change this to 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.
* DONE: Request<T>
* RpcDispatcher: only 1 Marshaller, not separate ones for reqs and rsps
* RpcDispatcher: use CompletableFuture instead of NotifiyingFuture
* DONE: Rsp: see https://issues.jboss.org/browse/JGRP-2011
> 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:
> * DONE: MessageDispatcher: remove MessageListener
> * Merge AsyncRequestHandler and RequestHandler, OR make them 2 separate interfaces, ie. AsyncRH doesn't extend RH
> * DONE: 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)
> * NOTDONE: Make {{RspFilter}} --> {{RspFilter<T>}}
> ** We need to be able to handle objects of type T *and* Throwable, so we cannot change this to 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.
> * DONE: Request<T>
> * RpcDispatcher: only 1 Marshaller, not separate ones for reqs and rsps
> * RpcDispatcher: use CompletableFuture instead of NotifiyingFuture
> * DONE: Rsp: see https://issues.jboss.org/browse/JGRP-2011
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 2 months