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
