I have absolutely no problem with recursive dependencies, the examples you
give illustrate where and why they can be useful.
My problem is that simply doing the dependency stuff in ServiceDeployer
doesn't solve the whole problem, because the service deployer can't enfore
dependencies between the services it is deploying and rar's and ear's etc.
For example any ear you want to deploy needs to wait for the
jetty-service.xml file to be deployed first, otherwise it has no servlet
container to run in. But the ServiceDeployer can't enforce this because it
doesn't deploy ear's.
However I think the AutoDeployer can enforce these dependencies AND there is
no reason why it can't enforce the recursive dependencies you need as well,
I just think dealing with dependencies in more than one place is a waste of
time and effort. Instead of having every deployer do dependencies in its
own way simply let the AutoDeployer take care of them all.
I do see the dependencies.xml file exactly as a sort of deployment script,
and it would differ from the classpath in a couple of very fundamental ways.
1) it can enforce dependencies between any sorts of files you want
to deploy
2) IT IS NOT A CLASSPATH
I know doing it this way would result in some duplicated information,
because jars would be listed in a classpath element as well as in the
dependency info, but I just think it is better. You could even have the
autodeployer automatically use the classpath element to build the dependency
info, but it is not the only place dependency info can come from.
David
> -----Original Message-----
> From: David Jencks [mailto:[EMAIL PROTECTED]]
> Sent: Friday, September 21, 2001 3:02 PM
> To: [EMAIL PROTECTED]
> Subject: Re: [JBoss-dev] Thoughts on deployers
>
>
> 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
>
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
