Re: [jboss-dev] Unification of transports in AS

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(a)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(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jboss-development _______________________________________________ jboss-development mailing list jboss-development(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-development