I can double check the spec on this. However, it doesnt assure me that the
stubs I download from a PRO.narrow() are genuine and that a mediator hasnt
replaced them with malicious versions. Again for an Application there is no
sandbox.
Not to mention, if the API changed you'd likely need to recompile the client
anyways. So whats the advantage? Maybe Im being simply dense.
Dave Wolf
Internet Applications Division
Sybase
> -----Original Message-----
> From: A mailing list for Enterprise JavaBeans development
> [mailto:[EMAIL PROTECTED]]On Behalf Of Brian Ploetz
> Sent: Tuesday, August 29, 2000 3:34 PM
> To: [EMAIL PROTECTED]
> Subject: Re: Remote Client Question.
>
>
> Hmmm, I'm pretty sure dynamically downloading a stub is a
> basic RMI
> feature and not vendor specific at all....Anyway, if the stubs have to be
> installed in the client's classpath, then that makes hot deployment a real
> pain in the arse if the implementation of a bean needs to change on the
> fly. Use of some smart proxies between the client and the app server will
> make things a lot simpler for the client so they don't have to worry about
> such things....
>
> BP
>
> >I believe the ability to download stubs is vendor dependant. I dont know
> >about you, but Im not excited about downloading bytecode to my
> application
> >off the web. Remember outside of an Applet there is no sandbox and no
> >guarantee the home and remote interfaces havent been rerouted
> with malicious
> >versions. Id approach downloading stubs with caution myself.
> >
> >But I think Im on of the more conservative types on this group <g>
> >
> >Dave Wolf
> >Internet Applicatins Division
> >Sybase
> >
> >
> >> -----Original Message-----
> >> From: A mailing list for Enterprise JavaBeans development
> >> [mailto:[EMAIL PROTECTED]]On Behalf Of Brian Ploetz
> >> Sent: Tuesday, August 29, 2000 11:22 AM
> >> To: [EMAIL PROTECTED]
> >> Subject: Re: Remote Client Question.
> >>
> >>
> >> Well you'll need the Home and Remote .class files on the
> >> client side to
> >> compile your code, but the stub itself will be automatically downloaded
> >> over the wire if it doesn't reside in the client's classpath.
> >>
> >>
> >> >Is there any way that a remote client can have an instance to a remote
> >> >interface without the use of a jar. IOW, dynamically load the remote,
> >> >and home via an IP address. I find it silly to have to
> manually set up
> >> >a jar and a classpath on each client.
> >> >
> >> >Example.
> >> >
> >> >public static void main(String [] args) {
> >> > try {
> >> > Context jndiContext = getVendorSpecificJNDIContext();
> >> > Object ref = jndiContext.lookup("CustomerHome");
> >> > CustomerHome home = (CustomerHome)
> >> >PortableRemoteObject.narrow(ref, CustomerHome.class);
> >> > Customer customer = home.create(...);
> >> > /* How can I get the current CustomerHome and Customer without
> >> >manually placing it on every client?*/
> >> > .
> >> > .
> >> > } catch (...) {
> >> > .
> >> > .
> >> > .
> >> > }
> >> >}
>
> :::::::::::::::::::::::::::::::::::::::::::::::::::::::
> Brian Ploetz - TradeOut
> Middleware Systems Architect
> [EMAIL PROTECTED]
> phone: (617) 503 - 8208
> fax: (617) 492 - 0699
> www.tradeout.com
> :::::::::::::::::::::::::::::::::::::::::::::::::::::::
>
> ==================================================================
> =========
> To unsubscribe, send email to [EMAIL PROTECTED] and include
> in the body
> of the message "signoff EJB-INTEREST". For general help, send email to
> [EMAIL PROTECTED] and include in the body of the message "help".
>
>
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
