Connor,
Thank you very much for the response. Based on this it sounds like the
creation of EJB JARs suitable for deployment is not a task that is required
for SilverStream deployment. SilverStream does do some EJBc type of
functionality, but it is all behind the scenes.
I would expect that the other application servers will switch to a
similar
deployment schemes to support EJB 2.0.
Thank you for the information.
Zack
> -----Original Message-----
> From: Conor MacNeill [mailto:[EMAIL PROTECTED]
> Sent: Thursday, August 30, 2001 8:44 AM
> To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
> Subject: Re: The EJB-JAR task and the SilverStream server.
>
>
> From: "Zack Grossbart" <[EMAIL PROTECTED]>
> To: "Ant-Dev" <[EMAIL PROTECTED]>
> Sent: Tuesday, August 28, 2001 9:04 PM
> Subject: The EJB-JAR task and the SilverStream server.
> > Hi,
> >
> > I was looking at the EJB-JAR task and its sub-tasks, and I had a couple
> of
> > questions. Most of the tasks for the application servers concern
> themselves
> > with stub generation and the generation of server specific
> files, but not
> > with the actual deployment. Since most of these application servers
> deploy
> > with a "copy these files to this directory" type of procedure I'm
> assuming
> > that these tasks are meant to be used in conjunction with the copy task.
> Is
> > this true?
>
> The <ejbjar> task is for putting together jar files suitable for
> deployment, i.e. with all the required files, both standard and
> vendor-specific. The task does not do deployment. In my development
> environment, I have a separate install Ant script which takes these jars
> anmd puts them in the right place. For production code, it is
> different and
> the jars are packaged up as solaris packages for deployment. I don't see
> that there is an advantage in having this task do everything - better to
> build the process from multiple smaller process components.
>
> >
> > None of the existing deployers call code outside of Ant, and only the
> > iPlanet code calls to an external executable. This must means that the
> code
> > for generating deployment information and stubs that I would expect to
> live
> > with each of the servers has been replicated in Ant. Is this the case?
>
> No, not really. The <ejbjar> task normally invokes the vendor's supplied
> tools to build the final EJB jar. So it is not replication as such. In
> addition the task adds other value in determining what has
> changed and what
> needs to be updated. I know many app server are moving to an "automatic"
> type of deployment. I have added support for that mode in the <weblogic>
> element (noejbc attribute). In any case, my personal preference is to run
> this step in the development phase and discover my errors then rather than
> during the deployment phase. YMMV.
>
> >
> > I am interested in providing support for deploying EJBs to the
> SilverStream
> > application server. The SilverStream deployment is very black box. It
> > provides an executable that takes a server name, an EJB Jar, and an XML
> file
> > that is a set of server specific information called a deployment plan.
> All
> > of the stub generation and the copying of files is done behind
> the scenes
> > within this executable. This scheme appears to be very different from
> the
> > scheme supported by the other application servers. The SilverStream
> > deployment scheme is more suitable to the Execute task then the
> deployment
> > tasks, I think :).
>
> OK, I don't know silverstream but if you can't prepare a jar before
> deployment, if it really behind the scenes, then all you would
> use <ejbjar>
> for would be to pull together the EJB jar to feed into the black box.
>
> >
> > Does anybody have any advice about this? Given the required changes to
> > support client inter-operability in EJB 2.0, does anybody have any ideas
> how
> > this deployment scheme will change? Are there any plans to support
> > deploying other types of J2EE modules (application clients, WARs, EARs,
> > Connectors)?
>
> Currently Ant tasks don't really support deployment (except <copy> :-) ).
> They produce the components, EJB jars, EARs, WARs, etc) .
>
> Conor
>
