OK, (trying to be helpful) I have finished implementing a dependency
mechanism in the AutoDeployer. I am going to finish testing it, change the
default configuration a little to use it and then commit it so you can have
a look before I leave (remember I will be away for the next week or so).
Please, please, please do dependencies this way, I really think it is the
best approach. It should be easy for you build recursive deploy/undeploy
into the AutoDeployer on top of what I have done, and it will make writing
the ServiceDeployer miles easier. Also the J2ee deployer and RAR deployer
will not need to be changed at all, a bonus in my book.
If you have any serious reservations about this let me know now and won't
commit, but if you want the code I have written today I think it will be of
use.
David
> -----Original Message-----
> From: David Maplesden [mailto:[EMAIL PROTECTED]]
> Sent: Friday, September 21, 2001 1:46 PM
> To: '[EMAIL PROTECTED]'
> Subject: RE: [JBoss-dev] Thoughts on deployers
>
>
> 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
>
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
