OK, I've finished the AutoDeployer stuff and it works, but I guess it might
not be the whole solution so I've decided not to commit it to CVS.
I will send it to you off-list in case you find it useful.
You know my thoughts on the whole issue.
To clarify I have two main concerns.
1) make dependency specification as easy and consistent as possible across
all package types. I guess allowing for the inclusion of a
jboss-service.xml (or even a jboss-dependency.xml ??) in every type of
package as you suggested would acomplish this.
2) allow the specification of dependencies between packages deployed by
different deployers. It is very important that a sar can be made to wait
for an ear or a rar or vice versa. The simplest way of doing this is to let
the AutoDeployer do it, if you come up with a another way then that's all
good too. I have a custom sar that uses the DefaultDS, and if it gets
deployed before the jboss-jdbc.rar then it fails so we need to be able to do
this.
I will be interested to see what you can come up with, good hunting while
I'm gone ;-)
Cheers
David.
> -----Original Message-----
> From: David Jencks [mailto:[EMAIL PROTECTED]]
> Sent: Friday, September 21, 2001 4:20 PM
> To: [EMAIL PROTECTED]
> Subject: Re: [JBoss-dev] Thoughts on deployers
>
>
> I'm glad you like my examples, I was beginning to worry I was
> the only one
> who thought those were worthwhile scenarios.
>
> I still don't understand why you want the AutoDeployer to do
> dependency
> checking rather than ServiceDeployer/UniversalDeployer. I
> think manual
> deployment should have access to the same dependency info as auto
> deployment-- I regard autodeployment as chiefly a development
> convenience,
> I would expect a production site to want more of a
> script-based audit-trail
> friendly deployment method. We want to be able to include
> jboss-service.xml files in an ear anyway, to be able to include mbean
> configuration specific to the application. Why not use it
> for dependencies
> as well?
>
> Also, to me, the fact that the dependency list is currently labelled
> classpath is, well, kind of irrelevant. I think of it as a
> list of stuff
> that needs to be deployed in the current scope before the
> current file is
> deployed. If there are undeployed classes on it, they go
> into the current
> scopes' classloader. If they are a *-service.xml file, they
> get processed
> first. It's not like we're checking to make sure that the list is
> complete-- if you leave out the classpath but all the classes for your
> mbeans are already available, we don't keep you from creating
> your mbeans.
>
> I sometimes understand your wish you never started thinking about this
> ;-)).
>
> Thanks
> david jencks
>
> On 2001.09.20 23:04:56 -0400 David Maplesden wrote:
> > 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
> >
> >
>
> _______________________________________________
> 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
