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
