[jboss-dev] Unification of transports in AS
Ron Sigal
ron.sigal at jboss.com
Wed Sep 19 18:46:37 EDT 2007
Hi Dimitris,
Thanks. Putting off issues from category (1) works for me. Unless
someone with 687 votes says otherwise. :-)
As for category (2), I guess it's also a matter of counting votes. To
summarize for anyone listening, there are now, as far as I can see,
three, or possibly four, relevant outstanding issues scheduled for
Remoting 2.4:
1) JBREM-63 "Get rid of the legacy configuration that embeds xml parsing"
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.
2) JBREM-713 "Check if jbossweb can replace tomcat jars for the http
server invoker" is currently scheduled for Remoting 2.4."
JBAS-2766 "tomcat libraries not available to remoting when using
http transport" is related.
3) JBREM-687 "allow binding to 0.0.0.0"
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).
4) JBREM-643 "configuration for multi-homed server invokers"
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!
-Ron
Dimitris Andreadis wrote:
> 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 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."
>>
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> jboss-development mailing list
>> jboss-development at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jboss-development
> _______________________________________________
> 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/20070919/16fdd3f3/attachment.html
More information about the jboss-development
mailing list