[JBoss JIRA] (WFLY-6136) Wildfly 10.0.0.Final duplitates contents of <jsp-config><include-prelude> or <include-coda> directives in web.xml
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-6136?page=com.atlassian.jira.plugin.... ]
Stuart Douglas reassigned WFLY-6136:
------------------------------------
Assignee: Stuart Douglas (was: Jason Greene)
> Wildfly 10.0.0.Final duplitates contents of <jsp-config><include-prelude> or <include-coda> directives in web.xml
> -----------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-6136
> URL: https://issues.jboss.org/browse/WFLY-6136
> Project: WildFly
> Issue Type: Bug
> Affects Versions: 10.0.0.Final
> Environment: Ubuntu Linux 14.04 amd64
> Reporter: Juanm Manuel Enrique Muñido
> Assignee: Stuart Douglas
>
> I have been successfully deploying an application on WildFly 8.2.1 and WildFly 9.0.2 versions with the following <jsp-config> directives in web.xml deployment descriptor:
> <jsp-config>
> <jsp-property-group>
> <description>header and footer settings</description>
> <url-pattern>/WEB-INF/view/*</url-pattern>
> <url-pattern>/WEB-INF/error/*</url-pattern>
> <include-prelude>/WEB-INF/jspf/header.jspf</include-prelude>
> <include-coda>/WEB-INF/jspf/footer.jspf</include-coda>
> </jsp-property-group>
> </jsp-config>
> This code fragment includes the contents of /WEB-INF/jspf/header.jspf at the beginning of each .jsp file and <include-coda>/WEB-INF/jspf/footer.jspf</include-coda> at the end of each .jsp file that matches the <url-pattern>.
> But when I try to deploy this application with the same deployment descriptor in WildFly 10.0.0.Final, the contents of /WEB-INF/jspf/header.jspf and /WEB-INF/jspf/footer.jspf are included twice in each .jsp file that matches the <url-pattern>.
> If I add another <url-pattern> line, then the contents of /WEB-INF/jspf/header.jspf and /WEB-INF/jspf/footer.jspf are included three times, and so on.
> Any suggestion about this issue?
> Is this a deployment descriptor issue or a configuration issue in the standalone.xml of WildFly 10.0.0.Final version?
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 9 months
[JBoss JIRA] (WFLY-6136) Wildfly 10.0.0.Final duplitates contents of <jsp-config><include-prelude> or <include-coda> directives in web.xml
by Juanm Manuel Enrique Muñido (JIRA)
[ https://issues.jboss.org/browse/WFLY-6136?page=com.atlassian.jira.plugin.... ]
Juanm Manuel Enrique Muñido updated WFLY-6136:
----------------------------------------------
Description:
I have been successfully deploying an application on WildFly 8.2.1 and WildFly 9.0.2 versions with the following <jsp-config> directives in web.xml deployment descriptor:
<jsp-config>
<jsp-property-group>
<description>header and footer settings</description>
<url-pattern>/WEB-INF/view/*</url-pattern>
<url-pattern>/WEB-INF/error/*</url-pattern>
<include-prelude>/WEB-INF/jspf/header.jspf</include-prelude>
<include-coda>/WEB-INF/jspf/footer.jspf</include-coda>
</jsp-property-group>
</jsp-config>
This code fragment includes the contents of /WEB-INF/jspf/header.jspf at the beginning of each .jsp file and <include-coda>/WEB-INF/jspf/footer.jspf</include-coda> at the end of each .jsp file that matches the <url-pattern>.
But when I try to deploy this application with the same deployment descriptor in WildFly 10.0.0.Final, the contents of /WEB-INF/jspf/header.jspf and /WEB-INF/jspf/footer.jspf are included twice in each .jsp file that matches the <url-pattern>.
If I add another <url-pattern> line, then the contents of /WEB-INF/jspf/header.jspf and /WEB-INF/jspf/footer.jspf are included three times, and so on.
Any suggestion about this issue?
Is this a deployment descriptor issue or a configuration issue in the standalone.xml of WildFly 10.0.0.Final version?
was:
I have been successfully deploying an application on WildFly 8.2.1 and WildFly 9.0.2 versions with the following <jsp-config> directives in web.xml deployment descriptor:
<jsp-config>
<jsp-property-group>
<description>header and footer settings</description>
<url-pattern>/WEB-INF/view/*</url-pattern>
<url-pattern>/WEB-INF/error/*</url-pattern>
<include-prelude>/WEB-INF/jspf/header.jspf</include-prelude>
<include-coda>/WEB-INF/jspf/footer.jspf</include-coda>
</jsp-property-group>
</jsp-config>
This code fragment includes the contents of /WEB-INF/jspf/header.jspf at the beginning of each .jsp file and <include-coda>/WEB-INF/jspf/footer.jspf</include-coda> at the end of each .jsp file that matches the <url-pattern>.
But when I try to deploy this application with the same deployment descriptor in WildFly 10.0.0.Final, the contents of /WEB-INF/jspf/header.jspf and /WEB-INF/jspf/footer.jspf are included twice in each .jsp file that matches the <url-pattern>.
If I add another <url-pattern> line, then the contents of /WEB-INF/jspf/header.jspf and /WEB-INF/jspf/footer.jspf are included three times, and so on.
Any suggestion about this issue?
Is this a deployment descriptor issue or a configuration issue in the standalone.xml of WildFly 10.0.0.Final version?
Summary: Wildfly 10.0.0.Final duplitates contents of <jsp-config><include-prelude> or <include-coda> directives in web.xml (was: Wildfly 10.0.0.Final duplitates contents of <jsp-config><include-prelude> or <include-coda> directives un web.xml)
> Wildfly 10.0.0.Final duplitates contents of <jsp-config><include-prelude> or <include-coda> directives in web.xml
> -----------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-6136
> URL: https://issues.jboss.org/browse/WFLY-6136
> Project: WildFly
> Issue Type: Bug
> Affects Versions: 10.0.0.Final
> Environment: Ubuntu Linux 14.04 amd64
> Reporter: Juanm Manuel Enrique Muñido
> Assignee: Jason Greene
>
> I have been successfully deploying an application on WildFly 8.2.1 and WildFly 9.0.2 versions with the following <jsp-config> directives in web.xml deployment descriptor:
> <jsp-config>
> <jsp-property-group>
> <description>header and footer settings</description>
> <url-pattern>/WEB-INF/view/*</url-pattern>
> <url-pattern>/WEB-INF/error/*</url-pattern>
> <include-prelude>/WEB-INF/jspf/header.jspf</include-prelude>
> <include-coda>/WEB-INF/jspf/footer.jspf</include-coda>
> </jsp-property-group>
> </jsp-config>
> This code fragment includes the contents of /WEB-INF/jspf/header.jspf at the beginning of each .jsp file and <include-coda>/WEB-INF/jspf/footer.jspf</include-coda> at the end of each .jsp file that matches the <url-pattern>.
> But when I try to deploy this application with the same deployment descriptor in WildFly 10.0.0.Final, the contents of /WEB-INF/jspf/header.jspf and /WEB-INF/jspf/footer.jspf are included twice in each .jsp file that matches the <url-pattern>.
> If I add another <url-pattern> line, then the contents of /WEB-INF/jspf/header.jspf and /WEB-INF/jspf/footer.jspf are included three times, and so on.
> Any suggestion about this issue?
> Is this a deployment descriptor issue or a configuration issue in the standalone.xml of WildFly 10.0.0.Final version?
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 9 months
[JBoss JIRA] (WFLY-6136) Wildfly 10.0.0.Final duplitates contents of <jsp-config><include-prelude> or <include-coda> directives un web.xml
by Juanm Manuel Enrique Muñido (JIRA)
Juanm Manuel Enrique Muñido created WFLY-6136:
-------------------------------------------------
Summary: Wildfly 10.0.0.Final duplitates contents of <jsp-config><include-prelude> or <include-coda> directives un web.xml
Key: WFLY-6136
URL: https://issues.jboss.org/browse/WFLY-6136
Project: WildFly
Issue Type: Bug
Affects Versions: 10.0.0.Final
Environment: Ubuntu Linux 14.04 amd64
Reporter: Juanm Manuel Enrique Muñido
Assignee: Jason Greene
I have been successfully deploying an application on WildFly 8.2.1 and WildFly 9.0.2 versions with the following <jsp-config> directives in web.xml deployment descriptor:
<jsp-config>
<jsp-property-group>
<description>header and footer settings</description>
<url-pattern>/WEB-INF/view/*</url-pattern>
<url-pattern>/WEB-INF/error/*</url-pattern>
<include-prelude>/WEB-INF/jspf/header.jspf</include-prelude>
<include-coda>/WEB-INF/jspf/footer.jspf</include-coda>
</jsp-property-group>
</jsp-config>
This code fragment includes the contents of /WEB-INF/jspf/header.jspf at the beginning of each .jsp file and <include-coda>/WEB-INF/jspf/footer.jspf</include-coda> at the end of each .jsp file that matches the <url-pattern>.
But when I try to deploy this application with the same deployment descriptor in WildFly 10.0.0.Final, the contents of /WEB-INF/jspf/header.jspf and /WEB-INF/jspf/footer.jspf are included twice in each .jsp file that matches the <url-pattern>.
If I add another <url-pattern> line, then the contents of /WEB-INF/jspf/header.jspf and /WEB-INF/jspf/footer.jspf are included three times, and so on.
Any suggestion about this issue?
Is this a deployment descriptor issue or a configuration issue in the standalone.xml of WildFly 10.0.0.Final version?
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 9 months
[JBoss JIRA] (WFLY-6127) Throw IllegalStateException if JTA tx has an unsynchronized persistence context and the target is synchronized persistence context
by Scott Marlow (JIRA)
[ https://issues.jboss.org/browse/WFLY-6127?page=com.atlassian.jira.plugin.... ]
Scott Marlow commented on WFLY-6127:
------------------------------------
I pushed a better version of the fix to https://github.com/scottmarlow/wildfly/tree/WFLY-6127 and squashed the commits (so previous concern mentioned about the downside is address). With the new change, we only introduce a little more overhead for unsynchronized persistence contexts.
> Throw IllegalStateException if JTA tx has an unsynchronized persistence context and the target is synchronized persistence context
> ----------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-6127
> URL: https://issues.jboss.org/browse/WFLY-6127
> Project: WildFly
> Issue Type: Bug
> Components: JPA / Hibernate
> Affects Versions: 9.0.2.Final
> Reporter: Mazen Mahmoud
> Assignee: Scott Marlow
> Priority: Minor
> Fix For: 10.1.0.Final
>
> Attachments: server-log.txt
>
>
> SPEC: If a component is called and the JTA transaction is propagated into that component:
> If there is a persistence context of type SynchronizationType.UNSYNCHRONIZED
> associated with the JTA transaction and the target component specifies a persistence context of type SynchronizationType.SYNCHRONIZED, the IllegalStateException is thrown by the container
> We have a stateful session bean (SFB1) / PC: TRANSACTION/UNSYNCHRONIZED)
> stateful session bean (SFB2) / PC: TRANSACTION/SYNCHRONIZED)
> SFB1 method M1 (REQUIRED) calls SFB2 Method 2 (REQUIRED):
> PC is propagated from SFB1 to SFB2 without any exception.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 9 months
[JBoss JIRA] (WFLY-6135) Throw IllegalStateException if JTA tx has an unsynchronized persistence context and the target is synchronized persistence context
by Scott Marlow (JIRA)
Scott Marlow created WFLY-6135:
----------------------------------
Summary: Throw IllegalStateException if JTA tx has an unsynchronized persistence context and the target is synchronized persistence context
Key: WFLY-6135
URL: https://issues.jboss.org/browse/WFLY-6135
Project: WildFly
Issue Type: Bug
Components: JPA / Hibernate
Affects Versions: 9.0.2.Final
Reporter: Scott Marlow
Assignee: Scott Marlow
Priority: Minor
Fix For: 10.1.0.Final
SPEC: If a component is called and the JTA transaction is propagated into that component:
If there is a persistence context of type SynchronizationType.UNSYNCHRONIZED
associated with the JTA transaction and the target component specifies a persistence context of type SynchronizationType.SYNCHRONIZED, the IllegalStateException is thrown by the container
We have a stateful session bean (SFB1) / PC: TRANSACTION/UNSYNCHRONIZED)
stateful session bean (SFB2) / PC: TRANSACTION/SYNCHRONIZED)
SFB1 method M1 (REQUIRED) calls SFB2 Method 2 (REQUIRED):
PC is propagated from SFB1 to SFB2 without any exception.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 9 months
[JBoss JIRA] (WFLY-6127) Throw IllegalStateException if JTA tx has an unsynchronized persistence context and the target is synchronized persistence context
by Scott Marlow (JIRA)
[ https://issues.jboss.org/browse/WFLY-6127?page=com.atlassian.jira.plugin.... ]
Scott Marlow updated WFLY-6127:
-------------------------------
Fix Version/s: 10.1.0.Final
> Throw IllegalStateException if JTA tx has an unsynchronized persistence context and the target is synchronized persistence context
> ----------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-6127
> URL: https://issues.jboss.org/browse/WFLY-6127
> Project: WildFly
> Issue Type: Bug
> Components: JPA / Hibernate
> Affects Versions: 9.0.2.Final
> Reporter: Mazen Mahmoud
> Assignee: Scott Marlow
> Priority: Minor
> Fix For: 10.1.0.Final
>
> Attachments: server-log.txt
>
>
> SPEC: If a component is called and the JTA transaction is propagated into that component:
> If there is a persistence context of type SynchronizationType.UNSYNCHRONIZED
> associated with the JTA transaction and the target component specifies a persistence context of type SynchronizationType.SYNCHRONIZED, the IllegalStateException is thrown by the container
> We have a stateful session bean (SFB1) / PC: TRANSACTION/UNSYNCHRONIZED)
> stateful session bean (SFB2) / PC: TRANSACTION/SYNCHRONIZED)
> SFB1 method M1 (REQUIRED) calls SFB2 Method 2 (REQUIRED):
> PC is propagated from SFB1 to SFB2 without any exception.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 9 months
[JBoss JIRA] (DROOLS-1030) Nullpointer in JpaTimerJobInstance.call on startup
by Artur Kronenberg (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1030?page=com.atlassian.jira.plugi... ]
Artur Kronenberg edited comment on DROOLS-1030 at 2/5/16 12:51 PM:
-------------------------------------------------------------------
For the people coming here with the same issue, this is the workaround I implemented:
1. Add a new Interface with say one method isExpired(). This method determines whether or not the fact can go.
2. Add a rule to match that interface. For me the Interface is called Expirable. This is my rule:
rule "fact_expiry_automation"
when
$e : Expirable( expired == true );
then
retract($e);
end
3. Have all your facts implement that interface.
4. Add a timer task manually that calls fireAllRules. Use an AgendaFilter in case you want to only match this rule exactly.
5. Run the task as often as you wish.
You will also have to remove the expires annotation on the original facts to stop drools from also trying to expire facts.
This solution has an issue where the expiry for the facts only work if the facts are inserted on session level. For example, I had to restructure my rules to not use entrypoints so that these facts could also expire programatically.
Hope that helps
UPDATE: not actually working because a fact is not reevaluated. My new workaround:
The timer task inserts a new ExpiryFact each time it runs. That way there's a new fact that must be evaluated. The fact caries an expiryTimestamp that i can then compare with the expiry field on my other facts.
was (Author: pandaadb):
For the people coming here with the same issue, this is the workaround I implemented:
1. Add a new Interface with say one method isExpired(). This method determines whether or not the fact can go.
2. Add a rule to match that interface. For me the Interface is called Expirable. This is my rule:
rule "fact_expiry_automation"
when
$e : Expirable( expired == true );
then
retract($e);
end
3. Have all your facts implement that interface.
4. Add a timer task manually that calls fireAllRules. Use an AgendaFilter in case you want to only match this rule exactly.
5. Run the task as often as you wish.
You will also have to remove the expires annotation on the original facts to stop drools from also trying to expire facts.
This solution has an issue where the expiry for the facts only work if the facts are inserted on session level. For example, I had to restructure my rules to not use entrypoints so that these facts could also expire programatically.
Hope that helps
> Nullpointer in JpaTimerJobInstance.call on startup
> ---------------------------------------------------
>
> Key: DROOLS-1030
> URL: https://issues.jboss.org/browse/DROOLS-1030
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Environment: Mac OS 10.10.5, Eclipse Mars Release, Java 1.8, Drools 6.3.0.Final
> Reporter: Artur Kronenberg
> Assignee: Mario Fusco
> Fix For: 6.4.0.CR1
>
> Attachments: test-standalone.zip
>
>
> Hi,
> I have noticed Nullpointer exceptions when I try and reload a persisted session on startup. It is a bit hard to recreate (I am actually not managing it now since I deleted all old sessions to attempt recreation) but I figured maybe someone has an idea. Essentially I am getting this NPE twice:
> java.lang.NullPointerException: null
> at org.drools.persistence.jpa.JpaTimerJobInstance.call(JpaTimerJobInstance.java:50) [drools-persistence-jpa-6.3.0.Final.jar:6.3.0.Final]
> at org.drools.persistence.jpa.JpaTimerJobInstance.call(JpaTimerJobInstance.java:30) [drools-persistence-jpa-6.3.0.Final.jar:6.3.0.Final]
> at java.util.concurrent.FutureTask.run(FutureTask.java:266) [na:1.8.0_51]
> at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180) [na:1.8.0_51]
> at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293) [na:1.8.0_51]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [na:1.8.0_51]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [na:1.8.0_51]
> at java.lang.Thread.run(Thread.java:745) [na:1.8.0_51]
> When debugging I noticed the following behaviour which points to a race condition:
> If I start my server and try to recreate the session, those NPEs happen 2x.
> If I start my server and put a breakpoint BEFORE creating the CommandService for execution, I can wait for a few seconds and the service can be found.
> It appears that the scheduler's timerJobFactoryManager is not fully there at the time the sessions is being loaded? Or something else is racing with the service creation.
> Is there a way for me to make sure everything is fully instantiated before I use drools? Does a workaround exist? Is this even a bug?
> Thanks and let me know your thoughts. If I run into this again I will attempt to try and reproduce it. Let me know if more info is needed!
> UPDATE:
> I noticed that the reason I can't reproduce it at the moment is that the JpaTimerJobInstance is never called with the newly persisted session. It appears that that timer job depends on something else to happen so that it thinks it needs to start the timerJob
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 9 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
* DONE: {{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
* 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
* 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
* DONE: {{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
> * DONE: {{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
> * DONE: Rsp: see https://issues.jboss.org/browse/JGRP-2011
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 9 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 resolved JGRP-1605.
----------------------------
Resolution: Done
> 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
> * DONE: {{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
> * DONE: Rsp: see https://issues.jboss.org/browse/JGRP-2011
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 9 months
[JBoss JIRA] (JGRP-1620) RpcDispatcher/MessageDispatcher changes
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1620?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-1620:
---------------------------
Summary: RpcDispatcher/MessageDispatcher changes (was: MessageDispatcher changes)
> RpcDispatcher/MessageDispatcher changes
> ---------------------------------------
>
> Key: JGRP-1620
> URL: https://issues.jboss.org/browse/JGRP-1620
> Project: JGroups
> Issue Type: Feature Request
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 4.0
>
>
> * In MessageDispatcher.castMessageXXX() and send(), we pass a Message as argument. Change this to only ship the byte[] buffer and options.
> ** This prevents a unicast RPC from having a message with a null dest, or a multicast RPC having a message with a non-null dest (JGRP-1617).
> * Return null from castMessage() if the call is async, instead of a null {{RspList}}
> * Investigate whether non-blocking RPCs need to create Request instances at all
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 9 months