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