I don't know, I beginning to regret starting to think about it :-)
It's hard, there are different pro's and con's to each approach. At the
moment the autodeployer thing I have done does not do any recursive
deploy/undeploy at all, but I think it would be easy to build in.
Scott has a good point as well, but I can't think of any other way of
expressing the dependencies for the AutoDeployer as it has absolutely no
information about the format of the files it is deploying. You could easily
make it so that every file has its own dependency file and you simply drop
them both into the deployment directory at the same time. I don't know if
this is really any better...
David
> -----Original Message-----
> From: David Jencks [mailto:[EMAIL PROTECTED]]
> Sent: Friday, September 21, 2001 3:26 PM
> To: [EMAIL PROTECTED]
> Subject: Re: [JBoss-dev] Thoughts on deployers
>
>
> Well, I certainly want to see it, I hope my reservations in
> my reply to
> your previous post are answered by it. Do you think they are?
>
> Thanks
> david jencks
>
> On 2001.09.20 22:37:44 -0400 David Maplesden wrote:
> > 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
> >
> >
>
> _______________________________________________
> 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
