<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Hi Dimitris,<br>
<br>
Thanks. Putting off issues from category (1) works for me. Unless
someone with 687 votes says otherwise. :-)<br>
<br>
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:<br>
<br>
1) JBREM-63 "Get rid of the legacy configuration that embeds xml
parsing"<br>
<br>
<blockquote>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.<br>
<br>
</blockquote>
2) JBREM-713 "Check if jbossweb can replace tomcat jars for the http
server invoker" is currently scheduled for Remoting 2.4."<br>
<br>
<blockquote>JBAS-2766 "tomcat libraries not available to remoting when
using http transport" is related.<br>
<br>
</blockquote>
3) JBREM-687 "allow binding to 0.0.0.0"<br>
<br>
<blockquote>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).<br>
<br>
</blockquote>
4) JBREM-643 "configuration for multi-homed server invokers"<br>
<br>
<blockquote>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!<br>
<br>
</blockquote>
-Ron<br>
<br>
<br>
Dimitris Andreadis wrote:
<blockquote cite="mid:46F0EF76.3040007@redhat.com" type="cite">Hi Ron,
<br>
<br>
thats a very good summary, thanks.
<br>
<br>
I think we should put on hold (1) type of issues and deal with (3) (4)
(5), as time permits.
<br>
<br>
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.
<br>
<br>
Ron Sigal wrote:
<br>
<blockquote type="cite">Hi Dimitris,
<br>
<br>
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:
<br>
<br>
(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.
<br>
<br>
(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.
<br>
<br>
(3) Independent of both Remoting API and version. These could (and in
some cases should) be finished now.
<br>
<br>
(4) Doesn't look like a Remoting issue to me (I could be wrong). These
could be done any time.
<br>
<br>
(5) May no longer be necessary.
<br>
<br>
Now, I have a couple of questions.
<br>
<br>
(1) Am I on the right track in my descriptions below?
<br>
<br>
(2) What is the time frame for getting Remoting 2.4 into JBossAS 5.0?
We could probably adjust the release schedule accordingly.
<br>
<br>
(3) Do you (or does anyone else) have any opinions about the urgency of
these issues?
<br>
<br>
Thanks,
<br>
Ron
<br>
<br>
=================================================================================================================================
<br>
JBAS-1465 Pooled Invoker should use common thread pool
<br>
Isn't pooled invoker obsoleted by unifed invoker?
<br>
<br>
JBAS-1984 HttpNamingContextFactory unable to reconnect
<br>
Independent of Remoting API
<br>
<br>
JBAS-2448 The server side of org.jboss.invocation.pooled has multiple
synchronization issues
<br>
Again, is the pooled invoker obsolote?
<br>
JBAS-2766 tomcat libraries not available to remoting when using http
transport
<br>
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
<br>
Independent of Remoting API.
<br>
<br>
JBAS-3151 Convert HA-JNDI stubs to Remoting
<br>
Depends on Remoting API.
<br>
JBAS-3154 Cleanup the remoting module in 3.2.x
<br>
Independent of Remoting API.
<br>
JBAS-3291 Allow Configurable Parameters To Defined Client
Interceptors In JRMPProxyFactory
<br>
(1) In AS 4.x, independent of Remoting API.
<br>
(2) In AS 5.0, obsoleted by JBAS-4456.
<br>
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)
<br>
Independent of Remoting API.
<br>
JBAS-3658 Remote classloading service - Redesign
<br>
Related to Remoting 3 design.
<br>
JBAS-3724 NotFoundInDispatcherException from InvokerLocator when
accessing remote calls when on a non default port
<br>
Duplicates JBAS-3309.
<br>
JBAS-3765 AOP-based version of RetryInterceptor
<br>
Might depend on Remoting API. Not sure.
<br>
JBAS-3885 JMXConnectorServer not respecting the -b value
<br>
I could be wrong, but doesn't look like a Remoting issue.
<br>
JBAS-3925 Unification of transports to Remoting 2.2.0
<br>
Depends on JBAS-3926, JBAS-3927, JBAS-3928, JBAS-3929, JBAS-3930,
JBAS-3931, below.
<br>
JBAS-3926 Move remoting transports out of conf/jboss-service.xml to
a remoting-beans.xml
<br>
I think this depends on JBREM-63 "Get rid of the legacy
configuration that embeds xml parsing". In forum thread
<a class="moz-txt-link-freetext" href="http://www.jboss.com/index.html?module=bb&op=viewtopic&t=106643">http://www.jboss.com/index.html?module=bb&op=viewtopic&t=106643</a>,
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.
<br>
JBAS-3927 Update naming service to using remoting based proxy
<br>
Depends on Remoting API.
<br>
<br>
JBAS-3928 Replace jmx-invoker-service.xml with jmx-remoting.sar
<br>
I'm not familiar with jmx-remoting in AS 5.0, but I don't think it
uses anything from Remoting. Is that true?
<br>
JBAS-3929 RMIAdaptorExt view of
org.jboss.mx.remoting.service.JMXConnectorServerService
<br>
Doesn't seem to depend on Remoting API.
<br>
<br>
JBAS-3931 Synch up ejb3x transport configs
<br>
Doesn't seem to depend on Remoting API.
<br>
JBAS-4456 Replace JRMPProxyService with a remoting based bean.
<br>
Seems to depend on Remoting API.
<br>
JBAS-4578 Upgrade jboss remoting to v2.2.2.GA (from v2.2.1.GA)
<br>
Done?
<br>
JBAS-4586 unified invoker causes delays under load
<br>
Bug. Needs to be looked at.
<br>
<br>
Dimitris Andreadis wrote:
<br>
<blockquote type="cite">We have this base issue to track
unification of transports in AS5
<br>
<a class="moz-txt-link-freetext" href="http://jira.jboss.com/jira/browse/JBAS-3925">http://jira.jboss.com/jira/browse/JBAS-3925</a>
<br>
<br>
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?
<br>
<br>
_______________________________________________
<br>
jboss-development mailing list
<br>
<a class="moz-txt-link-abbreviated" href="mailto:jboss-development@lists.jboss.org">jboss-development@lists.jboss.org</a>
<br>
<a class="moz-txt-link-freetext" href="https://lists.jboss.org/mailman/listinfo/jboss-development">https://lists.jboss.org/mailman/listinfo/jboss-development</a>
<br>
</blockquote>
<br>
-- <br>
JBoss, a Division of Red Hat
<br>
"My company's smarter than your company."
<br>
<br>
<br>
------------------------------------------------------------------------
<br>
<br>
_______________________________________________
<br>
jboss-development mailing list
<br>
<a class="moz-txt-link-abbreviated" href="mailto:jboss-development@lists.jboss.org">jboss-development@lists.jboss.org</a>
<br>
<a class="moz-txt-link-freetext" href="https://lists.jboss.org/mailman/listinfo/jboss-development">https://lists.jboss.org/mailman/listinfo/jboss-development</a>
<br>
</blockquote>
_______________________________________________
<br>
jboss-development mailing list
<br>
<a class="moz-txt-link-abbreviated" href="mailto:jboss-development@lists.jboss.org">jboss-development@lists.jboss.org</a>
<br>
<a class="moz-txt-link-freetext" href="https://lists.jboss.org/mailman/listinfo/jboss-development">https://lists.jboss.org/mailman/listinfo/jboss-development</a>
<br>
</blockquote>
<br>
<div class="moz-signature">-- <br>
<font color="#000000">JBoss, a Division of Red Hat<br>
"My company's smarter than your company."
</font></div>
</body>
</html>