>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.
I totally agree with what you're saying about the security issue, I was
just talking about the ability to dynamically download a stub. You're right
about the security issue though. In our setup the client VM (servlet
engine) and the app server VM are both in a very secure network that is not
reachable by outsiders so there is no need to worry about third party
packet sniffers. I know not everyone has that luxury though.....
>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.
What I meant was if the API didn't change but implementation details
changed. If the API changed then obviously you'd have to re-compile.
BP
>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".
