<vendor>
Inprise - IAS 4.0 has a similar appraoch, You can extract a client jar
file from the console that contains the required classes and types etc.
</vendor>
-----Original Message-----
From: Chris Raber <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED] <[EMAIL PROTECTED]>
Date: Wednesday, April 05, 2000 10:42 PM
Subject: Re: dynamic loading of client stubs across server instances
><vendor>
>In GemStone/J we handle this by creating a "client jar" during the
>deployment process that has all classes and resources needed by the client
>to access the server beans.
>
>To use this you simply put the client jar on the class path of the client.
></vendor>
>
>> -----Original Message-----
>> From: Sammy Ballew [SMTP:[EMAIL PROTECTED]]
>> Sent: Tuesday, April 04, 2000 12:58 PM
>> To: [EMAIL PROTECTED]
>> Subject: dynamic loading of client stubs across server instances
>>
>> The WebLogic Server (WLS) uses dynamic distribution
>> and loading of client stubs. However, if EJB A in
>> server instance X wants to access EJB B in server
>> instance Y the stubs needed to access B must be
>> *manually* distributed to instance X.
>>
>> WLS doe not allow dyanamic loading of classes within
>> the server so instance X cannot load the stubs. An
>> error occurs.
>>
>> The answer from BEA is that allowing WLS to dynamically
>> load classes poses too significant of a security problem
>> to be allowed. They considered a change in version 5.1
>> but did not carry through because of the security
>> concern.
>>
>> I should mention that this restriction is also imposed on
>> JSPs executing in an instance of WLS. The JSPs must be
>> in the same WLS instance as the EJBs or stubs must be
>> manually distributed. This seems significant since it
>> seems logical to separate execution of JSPs and EJBs
>> within a runtime environment.
>>
>> Some questions are:
>>
>> 1. Do other vendors products have this same restriction?
>> 2. If #1 answer is "yes" do developers consider this acceptable?
>> 3. Is the security concern by BEA valid?
>> 4. Any other thoughts/questions/answers you may have on this
>> subject?
>>
>> sammy
>>
>>
==========================================================================
>> =
>> 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".
>
>
===========================================================================
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".
