[jboss-dev] Naming over Remoting 3

[Carlo de Wolf]

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 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
>