I added David's and Carlo's comments to the thread Ron had started on this topic.
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4266823

Carlo de Wolf wrote:
Whether it will be ATTCTMVP (tm) or something else ( for example 
http://anonsvn.jboss.org/repos/jbossas/projects/ejb3/trunk/remoting2/src/main/java/org/jboss/ejb3/remoting/endpoint/RemotableEndpoint.java 
) remains to be seen. I like 
http://anonsvn.jboss.org/repos/common/invokablecontainer/trunk/api/src/main/java/org/jboss/ejb3/container/api/Invocation.java 
with the exception that target is not a first class citizen.

AOPRemotingInvocationHandler & Dispatcher definitely need to go. The 
first, because remoting is not an aspect, the second because it's a 
singleton with weird SPI ( 
http://fisheye.jboss.org/browse/JBossAS/trunk/ejb3/src/main/org/jboss/ejb3/session/ClassProxyHack.java?r=69926 
).

Now if you put JNDI, Remoting and proxies in one sentence one 
requirement is the most important:
- all proxies must be transport unaware.

So if I bind an EJB into JNDI it doesn't matter whether I lookup through 
an HTTP(S), IIOP or whatever to get a proxy tied to the connection with 
which I'm communicating with AS.
The same goes for clustering, that is just a virtual connection to a 
virtual host (/ real cluster).

Carlo

On 11/19/2009 03:54 AM, Ron Sigal wrote:
  
So ATTCRMVP (tm) would be the descendant of
org.jboss.aspects.remoting.AOPRemotingInvocationHandler /
org.jboss.aop.Dispatcher ?

David M. Lloyd wrote:
   
    
One observation that's neither here nor there - ALR has been kicking
around a "back to basics" simple invocation mechanism that should work
for all Things That Call Remote Methods Via a Proxy (tm), for EJB3 and
whatever else it may apply to, which opens the possibility to come up
with a standard Remoting 3 invocation service of some sort.

It looks pretty good to me so far.  It lives here:
http://anonsvn.jboss.org/repos/common/invokablecontainer/trunk/api/

Granted realistically this is going to apply more to what we stick
*in* JNDI, than how JNDI is itself implemented (which, afaict, -could-
just be a straight-up Remoting 3 service type, though that'd be a more
significant departure from the current implementation from what I
understand of it, than sticking with something more RMI-like).

- DML

On 11/18/2009 07:42 PM, Ron Sigal wrote:
     
      
I subject has arisen in JBAS-3151 "Convert HA-JNDI stubs to Remoting"
that Brian has suggested deserves some discussion. I've started a forum
thread
(http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4266436#4266436),

but here's the teaser:


*"ron" wrote:*

...
Is there anything wrong with HARMIClient and HARMIServer, other than the
fact that they depend on RMI?
---



*"brian" wrote:*

Not particularly, no. I think the main issues are 1) we want to unify as
much as possible on a single remote invocation mechanism 2) get rid of
myriad sockets opened by different services. I suppose the latter goes
beyond the description of this JIRA as it involve converting
HANamingService to use a Remoting connector instead of directly
listening on port 1101.



*"ron" wrote:*

It looks like there are two kinds of Naming listeners:

1. the "bootstrap" listeners in org.jnp.server.Main and
org.jboss.ha.jndi.HANamingService, and

2. the actual service listeners: org.jnp.server.NamingServer and
org.jboss.ha.framework.server.HARMIServerImpl

So, we'd like to replace them all with handlers on a single Remoting
connector (or, actually, the Remoting 3 version of of handlers and
connectors).



*"brian" wrote:*

The bootstrap listener part probably bears discussion on the jboss-dev
list since it much more directly impacts stuff like end-user
configuration (i.e. jndi.properties or other ways of setting the
properties passed to new InitialContext()). The service listeners are
more straightforward.



Discuss?

-Ron



_______________________________________________
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
   
    

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