Thanks for the info. I agree with you about the confusion...
Do you think if I get the stuff I outlined working we can add the security
aspects after that?
Thanks
david jencks
On 2001.09.21 01:25:58 -0400 Scott M Stark wrote:
> I think part of the confusion on AutoDeployer vs UniversalDeployer is
> that
> the AutoDeployer is a limited UniversalDeployer today. It accepts ears,
> jars, wars,
> and rars and delgates to specific deployers, so let's isolate dependency
> management
> to the UniversalDeployer and leave simplify the role of the AutoDeployer
> to
> detecting
> changes and notifying the UniversalDeployer.
>
> More below.
>
> ----- Original Message -----
> From: "David Jencks" <[EMAIL PROTECTED]>
> To: "jboss-dev" <[EMAIL PROTECTED]>
> Sent: Thursday, September 20, 2001 6:39 PM
> Subject: [JBoss-dev] Thoughts on deployers
>
>
> > Ok, I'm almost ready to get to work ;-)
> >
> > We need to be able to deploy:
> >
> > sar
> > rar
> > ear
> > ejb-jar
> > war
> > plain old jar
> > directories (?)
> > *-service.xml files
> >
> > we need to be able to unpack
> >
> > sar
> > rar
> > ear
> >
> A war must also be unarchived. The war content is specified as the
> unarchived contents of the war.
>
> > and put the contained jars in a directory structure and find one or
> more
> > config files.
> >
> > Any of the *ar packages may contain a *-service.xml file which can
> contain
> >
> > *ar/*-service.xml dependency information (in one or more classpath
> > elements)
> > (meaning automatically deploy these first, if not already deployed)
> > mbean dependency information (meaning wait till these mbeans are
> started
> > before creating any mbeans configured in this package)
> > mbean configuration
> >
> > I'll talk about recursive deployment/undeployment and suspension in
> more
> > detail in another post.
> >
> > A sar can presumably contain any of the other packages,
> > an ear can contain any of the other packages,
> > a rar can contain plain old jars (and other libs)
> >
> > The other packages have sun-specified deployment descriptors also.
> >
> > So, I propose a universal deployer, that has access to unpacking
> services,
> > can create and aggregate classloaders, and can delegate interpretation
> of
> > the *.xml configuration files to the appropriate sub-deployers, in a
> > specified order:
> > jboss-service.xml
> > application.xml
> > ra.xml
> > ejb-jar.xml
> > the war config file (don't know much about this one)
> >
> war has: web.xml and jboss-web.xml
>
> > Many of these delegate deployers may end up calling the universal
> deployer
> > again to deploy sub-packages, in particular the jboss-service.xml has
> the
> > classpath dependencies to deploy.
> >
> > The autodeployer just watches for new/timestamp-changed files and calls
> > deploy for the former, undeploy and deploy for the latter. It doesn't
> need
> > to know about any deployers except the universal deployer.
> >
> >
> > So what I'd like to do first is make the universal deployer and
> unpacking
> > service, and hook everything else up to it, removing the existing
> unpacking
> > services from RARDeployer and J2eeDeployer (which maybe we should call
> > EARDeployer).
> >
> The EARDeployer needs to also be updated to know about the RARs that
> were deployed as part of the EAR. In general we need to overhaul the
> deployment
> objects as they were originally only designed for unsecure ejbs. Now as
> of
> J2EE 1.3 life is a much more complicated mixture of jars, wars, rars +
> security.
>
>
>
> _______________________________________________
> Jboss-development mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/jboss-development
>
>
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
