[jboss-dev] Unification of transports in AS

[Ron Sigal]

Hi Dimitris,

I've been looking at the Remoting component issues in JBAS, trying to 
get a handle on what needs to be done and when.  It seems to me that 
these issues fall into one of the following categories:

(1) Depends on either Remoting API or Remoting 3 design.  These could 
wait for Remoting 3, or, depending on how different the Remoting 
versions are, we could finish them and then redo them for Remoting 3.  
The upcoming design meeting should shed additional light.

(2) Independent of Remoting API but depends on an issue currently 
scheduled for Remoting 2.4.  For these issues, we could need to wait at 
least until Remoting 2.4 is available.

(3) Independent of both Remoting API and version.  These could (and in 
some cases should) be finished now.

(4) Doesn't look like a Remoting issue to me (I could be wrong).  These 
could be done any time.

(5) May no longer be necessary.

Now, I have a couple of questions.

(1) Am I on the right track in my descriptions below?

(2) What is the time frame for getting Remoting 2.4 into JBossAS 5.0?  
We could probably adjust the release schedule accordingly.

(3) Do you (or does anyone else) have any opinions about the urgency of 
these issues?

Thanks,
Ron

=================================================================================================================================
JBAS-1465 Pooled Invoker should use common thread pool
    Isn't pooled invoker obsoleted by unifed invoker?

JBAS-1984 HttpNamingContextFactory unable to reconnect
    Independent of Remoting API

JBAS-2448 The server side of org.jboss.invocation.pooled has multiple 
synchronization issues
    Again, is the pooled invoker obsolote?
   
JBAS-2766 tomcat libraries not available to remoting when using http 
transport
    Independent of Remoting API.  I gather that the solution is to put 
the unified invoker configuration in its own sar.  One catch, though, is 
that the http transport currently depends on tomcat jars, and JBoss 5 
ships with JBossWeb.  Issue JBREM-713 "Check if jbossweb can replace 
tomcat jars for the http server invoker" is currently scheduled for 
Remoting 2.4. 
   
JBAS-2939 Make Invocation policies more configurable
    Independent of Remoting API.

JBAS-3151 Convert HA-JNDI stubs to Remoting
    Depends on Remoting API.
   
JBAS-3154 Cleanup the remoting module in 3.2.x
    Independent of Remoting API.
   
JBAS-3291 Allow Configurable Parameters To Defined Client Interceptors 
In JRMPProxyFactory
    (1) In AS 4.x, independent of Remoting API.
    (2) In AS 5.0, obsoleted by JBAS-4456.
   
JBAS-3309 Remote client couldn't connect EJB remote interface if the 
ejb3.deployer InvokerLocator port is set to non-default value. (other 
than 3873)
    Independent of Remoting API.
   
JBAS-3658 Remote classloading service - Redesign
    Related to Remoting 3 design.
   
JBAS-3724 NotFoundInDispatcherException from InvokerLocator when 
accessing remote calls when on a non default port
    Duplicates JBAS-3309.
   
JBAS-3765 AOP-based version of RetryInterceptor
    Might depend on Remoting API.  Not sure.
   
JBAS-3885 JMXConnectorServer not respecting the -b value
    I could be wrong, but doesn't look like a Remoting issue.
   
JBAS-3925 Unification of transports to Remoting 2.2.0
    Depends on JBAS-3926, JBAS-3927, JBAS-3928, JBAS-3929, JBAS-3930, 
JBAS-3931, below.
   
JBAS-3926 Move remoting transports out of conf/jboss-service.xml to a 
remoting-beans.xml
    I think this depends on JBREM-63 "Get rid of the legacy 
configuration that embeds xml parsing".  In forum thread 
http://www.jboss.com/index.html?module=bb&op=viewtopic&t=106643, Scott 
says "The first step is to ensure that every externalizable behavior has 
a pojo metadata object."  So, for each of the MBeans defined in Remoting 
(e.g., Connector, AbstractDetector), we should create a metadata 
configuration class.  JBREM-63 is currently scheduled for Remoting 2.4.
   
JBAS-3927 Update naming service to using remoting based proxy
    Depends on Remoting API.

JBAS-3928 Replace jmx-invoker-service.xml with jmx-remoting.sar
    I'm not familiar with jmx-remoting in AS 5.0, but I don't think it 
uses anything from Remoting. Is that true?
   
JBAS-3929 RMIAdaptorExt view of 
org.jboss.mx.remoting.service.JMXConnectorServerService
    Doesn't seem to depend on Remoting API.

JBAS-3931 Synch up ejb3x transport configs
    Doesn't seem to depend on Remoting API.
   
JBAS-4456 Replace JRMPProxyService with a remoting based bean.
    Seems to depend on Remoting API.
   
JBAS-4578 Upgrade jboss remoting to v2.2.2.GA (from v2.2.1.GA)
    Done?
   
JBAS-4586 unified invoker causes delays under load
    Bug.  Needs to be looked at.

Dimitris Andreadis wrote:
> We have this base issue to track unification of transports in AS5
> http://jira.jboss.com/jira/browse/JBAS-3925
>
> My concern is without a clear strategy yet on remoting v3 (which I 
> understand is currently under discussion) in terms of API changes and 
> compatibility with v2, shouldn't we delay this set of tasks?
>
> _______________________________________________
> jboss-development mailing list
> jboss-development at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-development

-- 
JBoss, a Division of Red Hat
"My company's smarter than your company."
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jboss-development/attachments/20070918/ef330f70/attachment.html