Ok, 2 points:
Well, I'm not too thrilled with the dependency stuff as it currently works
either, but I think something like it is necessary. Here are the things I
want to be able to do, that I think lead to recursive deployment and
dependencies.
a. After I deploy mystuff-service.xml, depending on 47 other packages in
its classpath, and containing 150 mbean configurations, I discover that one
of the jars, stuff.jar is the wrong version. I want to be able to undeploy
stuff.jar, have all the depending packages (including mystuff-service.xml)
undeploy and suspend, and redeploy stuff.jar (correct version) and have all
the suspended packages redeploy. If there are 27 packages depending on
stuff.jar, I don't want to have to figure out what they are and undeploy
them by hand so I can fix stuff.jar. To me, this means that the classpath
stuff is dependency information.
b. If you allow sars containing both a jboss-service.xml and some classes,
you get recursive dependencies, and you have to (imho) allow including sars
in classpaths. For instance, I want all the jca stuff in one sar, I don't
think it makes sense otherwise. You need it all, why make it easy to break
by losing one package? However, this means every mydb-service.xml file
setting up a ConnectionFactoryLoader needs (for completeness) jbosscx.sar
in its classpath... this example doesn't recurse (recur?) too much, but
we've opened the door to recursion of indefinite depth.
Second... I don't understand why you want the AutoDeployer to know about
dependency information, but not the ServiceDeployer. As far as I know, the
only dependency info we have now is in *service.xml files, where it is
really relevant: classpath and needed mbeans. Why make it harder for
someone who wants to deploy programatically? Or do you think of
dependencies.xml as sort of a deployment script? How would it be different
from the classpath in *service.xml?
Anyway.. I think we maybe agree on the universal deployer and the unpacking
service?
Thanks
david jencks
On 2001.09.20 21:45:50 -0400 David Maplesden wrote:
> 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
