Hi Ranjan,
Another point on this is that it can be hard for the deployment tool to
automatically determine which classes to extract from the beans jar file
apart from the usual. Thats why I think that the deployment tool need to
allow the user to individually select some additional classes from the jar
file. This selection should always be made persistent (recall - appear
somewhat intelligent) between different interactions of the deployment tool
with the beans jar. The deployment wizard in JBuilder 3.5 provides this ease
of use. This kind of functionality really has 2 resident places 1)
deployment tool 2) IDE tool.
kind regards,
William Louth
> -----Original Message-----
> From: Louth, William (Exchange)
> Sent: Tuesday, April 25, 2000 5:47 PM
> To: 'A mailing list for Enterprise JavaBeans development'
> Subject: RE: Separation of interfaces and implementation bean
>
> Hi Ranjan,
>
> You should be using a deployment tool which extracts the list of classes
> required for client side deployment this includes stubs (i.e proxy),
> remote interfaces (home and remote), and application specific serializable
> classes into a client jar file. Inprise Application Server (IAS) provides
> this feature along with Gemstone I believe. Web Logic has something for
> applets called "applet archiver".
>
> kind regards,
>
> William Louth
>
> -----Original Message-----
> From: Ranjan Bagchi [SMTP:[EMAIL PROTECTED]]
> Sent: Friday, April 21, 2000 6:01 PM
> To: [EMAIL PROTECTED]
> Subject: Separation of interfaces and implementation bean
>
> Hi --
>
> This is a deployment problem -- I'm using Weblogic 4.51 w/ IBM VAJava.
>
> I'm trying to avoid distributing the Bean class within a .jar file
> to the clients: it's a general good practice, all they need is the
> interfaces, they certainly shouldn't be instantiating the Bean, and the
> bytecode for the bean may contain private data which could be misused.
>
> It seems that if I remove the bean class from the ejb-jar and stick it
> into the server classpath directly it still fails to deploy. Reading
> through the EJB spec this does seem to be proper behavior.
>
> Is the only way to do this to massage the ejb-jar, pull out the
> interface .class files and distribute only those to the clients? It's
> doable, and certainly even scriptable, but it's still kind of hokey.
>
> Curious what others are doing.
>
> Ranjan
>
> ==========================================================================
> =
> 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".
***********************************************************************
Bear Stearns is not responsible for any recommendation, solicitation,
offer or agreement or any information about any transaction, customer
account or account activity contained in this communication.
***********************************************************************
===========================================================================
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".
