This was created by Scott Stark and assigned a priority of BLOCKER.  (There's quite a few votes.)  As I said below, I think JBAS-3926 "Move remoting transports out of conf/jboss-service.xml to a remoting-beans.xml" depends on JBREM-63.  I see that JBREM-3926 is currently assigned to you.

JBAS-2766 "tomcat libraries not available to remoting when using http transport" is related.

The new issue JBAS-4704 "The port for the InvokerLayer (ejb3-deployer) listens only to one interface (address)" depends on JBREM-687, which is done.  Actually, I think we could reclassify JBREM-687 as a bug and add it to a Remoting 2.2.2.SP2 (and 2.2.2.SP1_CP01).

This one might also be considered related to JBAS-4704, though the relationship is less compelling.  But I mention it just because it might be something someone wants.  Again, vote early, vote often!

Hi Ron,

thats a very good summary, thanks.

I think we should put on hold (1) type of issues and deal with (3) (4) (5), as time permits.

About (2) I don't believe there is urgency in rushing a remoting 2.4 out, unless some other project/critical fix depends on it.

Ron Sigal wrote:

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@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-development

-- 
JBoss, a Division of Red Hat
"My company's smarter than your company."


------------------------------------------------------------------------

_______________________________________________
jboss-development mailing list
jboss-development@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-development

_______________________________________________
jboss-development mailing list
jboss-development@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-development