OK, I agree with most of what you propose... with one big difference. I now
feel (after already playing with service deployer) that dependencies have no
real place in the individual deployers, they just complicate the code for
each of them (or for the proposed universal deployer).
At the end of the day the only thing which needs to know about ANY
dependencies is the AutoDeployer, the individual deployers should just be
able to concentrate on deploying the application they are asked to, when
they are asked to. The AutoDeployer can keep track of dependencies
(including recursive ones if you want) across all types of files and deploy
and undeploy the right files at that right times.
I think this is much cleaner and will be much easier for people to use, and
the dependency stuff won't interfere when users manually deploy/undeploy
things via JMX.
So the consequences of this are...
1- classpaths go back to being classpaths instead of recursive dependency
lists.
2- no dependency stuff in *-service.xml files
3- hence no need for *-service.xml files in jars, ears or rars
4- individual deployers have no need to deploy any other files, they just do
their normal jobs.
5- autodeployer keeps track of dependencies, asks individual deployers to
deploy and undeploy when
neccessary.
6- autodeployer reads the dependencies for the files in given watched
directory from a dependencies.xml file in that directory, no file = no
dependencies.
What do you think?
David M
> -----Original Message-----
> From: David Jencks [mailto:[EMAIL PROTECTED]]
> Sent: Friday, September 21, 2001 1:40 PM
> To: jboss-dev
> 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
>
> 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)
>
> 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).
>
> (I think this is essentially what David Maplesden is thinking of also,
> however I do have time now ;-))
>
>
> How does this look?
>
> thanks
> david jencks
>
> _______________________________________________
> 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
