[
https://jira.jboss.org/jira/browse/JBAS-6346?page=com.atlassian.jira.plug...
]
Galder Zamarreno commented on JBAS-6346:
----------------------------------------
It's been like that since day 1 of EJB3. IMO, it's a wise thing to do as it
separates the load balancing work from the actual proxy implementation (Unified, JRMP,
Pooled...etc). Problem is that the interceptor still lacks some of the stuff EJB2 had,
such as failover denial under transaction:
https://jira.jboss.org/jira/browse/EJBTHREE-1137. Whether that will get implemented or not
depends on whether a fully distributed TM can be integrated for clustered invocation:
https://jira.jboss.org/jira/browse/JBAS-5239.
Fallback Invoker Interceptor
----------------------------
Key: JBAS-6346
URL:
https://jira.jboss.org/jira/browse/JBAS-6346
Project: JBoss Application Server
Issue Type: Feature Request
Security Level: Public(Everyone can see)
Components: Aspects, EJB3, Remoting
Affects Versions: JBossAS-4.2.3.GA, JBossAS-5.0.0.GA
Reporter: Andrew Oliver
Presently to configure EJBs to be remotely accessible via a given set of protocols you
must give them separate JNDI names. In commercially distributed software where you have
multiple configurations this is inconvenient. Ideally there would be an interceptor that
takes the place of the InvokerRemoteInterceptor.java and retries the connection on a
series of protocols. The choice could then be saved in the proxy for "first
use" next time. This would be similar to the ClusterChooserInterceptor.java. The
server side configuration would show a InvokerLocator which is configured to a series of
invoker Locator which is bound to a series of invokers. The call would be retried once
for each invoker dependent on failure type and then fail completely (in the worst case) or
return the first successful invocation.
This would allow "autoconfiguration" of the appserver for example using pure
socket or HTTP invocation depending on the first success making the server easier to
install in both IT and VAR/OEM environments.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira