You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by vinaysahil chandran <sa...@yahoo.com> on 2002/03/10 03:46:40 UTC

[ALTRMI]-PATCH JNDI interface for Altrmi clients

Paul,
Did some prelim' JNDI bridge work for client-side
lookup's and listing.

The Client code now would do something like :

		Hashtable env = new Hashtable(); 
	
env.put(Context.INITIAL_CONTEXT_FACTORY,"org.apache.commons.altrmi.client.impl.naming.AltrmiInitialContextFactory");
	
env.put(Context.PROVIDER_URL,"altrmi://localhost:1235/SocketCustomStream");
		env.put("proxy.type","C");
		env.put("bean.type","NBO");
	    Context ctx = new InitialContext(env);
	    //list
        System.out.println("Listing Published Objects
At Server...");

        NamingEnumeration
listOfPublishedObjectsOnServer = ctx.list("all");
		int i=0;
       
while(listOfPublishedObjectsOnServer.hasMore())
        {
            System.out.println("..[" + i + "]:" +
listOfPublishedObjectsOnServer.next());
            ++i;
        }

        TestInterface ti = (TestInterface)
ctx.lookup("Hello");

        new TestClient(ti);
        ctx.close();



Comments ??



Regards,
V i n a y

++++++++++++++++++++++++++++++++++++++++++++
Patches follows 
DefaultInterfaceLookupFactory: added supported stream
types are an array for check's done with
InitialContextFactory

++++++++++++++++++++++++++++++++++++++++++++


cvs -q diff DefaultInterfaceLookupFactory.java (in
directory
C:\jcommons\cvs\jakarta-commons-sandbox\altrmi\src\java\org\apache\commons\altrmi\client\impl)
Index: DefaultInterfaceLookupFactory.java
===================================================================
RCS file:
/home/cvspublic/jakarta-commons-sandbox/altrmi/src/java/org/apache/commons/altrmi/client/impl/DefaultInterfaceLookupFactory.java,v
retrieving revision 1.2
diff -r1.2 DefaultInterfaceLookupFactory.java
26a27,31
> 	public static String[] supportedStreams=new
String[]
> 												{"SocketObjectStream",
> 												 "SocketCustomStream",
> 												  "RMI"
> 												};




__________________________________________________
Do You Yahoo!?
Try FREE Yahoo! Mail - the world's greatest free email!
http://mail.yahoo.com/

Re: [ALTRMI]-PATCH JNDI interface for Altrmi clients

Posted by Paul Hammant <Pa...@yahoo.com>.
Vinay,

>Paul,
>Did some prelim' JNDI bridge work for client-side
>lookup's and listing.
>
><skip/>
>
>
>Comments ??
>
I am over the moon.... I will put it in now!

- Paul


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: [ALTRMI]-PATCH JNDI interface for Altrmi clients

Posted by Paul Hammant <Pa...@yahoo.com>.
Vinay,

>Yaa , maybe we can have the sockete-client option,
>in to express JNDI presence within the altrmi story.
>
OK, I have booked in a test that uses the new JNDI client interface.  It 
works fine :-)

- Paul


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: [ALTRMI]-PATCH JNDI interface for Altrmi clients

Posted by Paul Hammant <Pa...@yahoo.com>.
Vinay,

>>2) The URL naming scheme for JNDI is very different
>>to the colon 
>>delimited design that I have started in
>>InterfaceLookupFactory.  Should 
>>we change that to look more like JNDI ?
>>
>
>Hey Paul, I left some println' hanging in there 
>amongst the jndi code .
>Can you get rid of those.
>I am sorry for that .
>
No probs.

>>3) Tests.  I think some of the tests should be
>>changed to use JNDI for 
>>the lookup.  Not all, as we should show people that
>>they have options...
>>
>Yaa , maybe we can have the sockete-client option,
>in to express JNDI presence within the altrmi story.
>
OK, I'll code one.

- Paul


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: [ALTRMI]-PATCH JNDI interface for Altrmi clients

Posted by vinaysahil chandran <sa...@yahoo.com>.
> 3) your name has replaced mine as auther of the
> smaller class, as i did 
> nothing really.
>
:-)) haha ....

> 
> 1) I hate the env.put() business of JNDI.  Should we
> also provide a 
> helper factory (optional use) that will make an
> InitialContext for comon 
> types of transport? It would be a non-standard way
> of making an initial 
> context but many people do this anyway in their
> code.
>
Sure , sounds good . 
> 2) The URL naming scheme for JNDI is very different
> to the colon 
> delimited design that I have started in
> InterfaceLookupFactory.  Should 
> we change that to look more like JNDI ?
> 

Hey Paul, I left some println' hanging in there 
amongst the jndi code .
Can you get rid of those.
I am sorry for that .

> 3) Tests.  I think some of the tests should be
> changed to use JNDI for 
> the lookup.  Not all, as we should show people that
> they have options...
> 
Yaa , maybe we can have the sockete-client option,
in to express JNDI presence within the altrmi story.
:-)

V i n a y.

__________________________________________________
Do You Yahoo!?
Try FREE Yahoo! Mail - the world's greatest free email!
http://mail.yahoo.com/

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: [ALTRMI]-PATCH JNDI interface for Altrmi clients

Posted by Paul Hammant <Pa...@yahoo.com>.
Vinay,

>Did some prelim' JNDI bridge work for client-side
>lookup's and listing.
>
Yes it is good stuff.  I have committed it.  Some small changes :

1) names of clases have be prefixed with Default.  Why? EOB is likely to 
re-implement to allow internal VM lookup when the client thinks it is 
doing an external socket lookup (the holy grail).

2) 'supportedstreams' is static so has gone uppercase and final

3) your name has replaced mine as auther of the smaller class, as i did 
nothing really.

Thoughts......

1) I hate the env.put() business of JNDI.  Should we also provide a 
helper factory (optional use) that will make an InitialContext for comon 
types of transport? It would be a non-standard way of making an initial 
context but many people do this anyway in their code.

2) The URL naming scheme for JNDI is very different to the colon 
delimited design that I have started in InterfaceLookupFactory.  Should 
we change that to look more like JNDI ?

3) Tests.  I think some of the tests should be changed to use JNDI for 
the lookup.  Not all, as we should show people that they have options...

Your thoughts?

- Paul




--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>