On 2001.09.12 23:22:40 -0400 David Maplesden wrote:
> 1. doesn't work, I tried it hoping it would. The problem is not when the
> RARDeployer is deployed but when the rar's themselves are deployed. It
> is
> easy to specify (using a depends tag or the classpath element) that the
> RARDeployer or indeed the entire jbosscx.sar needs to be deployed before
> my
> mbean, the trouble is this does not neccessarily deploy the rar's.
>
> The way you originally had the configuration with two AutoDeployers (one
> in
> the jbosscx.sar) this would have worked, but when I changed the
> AutoDeployer
> so that it could wait for the Deployers it uses to be deployed after
> itself
> then I removed the AutoDeployer from the jbosscx.sar because it really
> isn't
> needed. Of course now one way of fixing the problem would be to have
> this
> extra AutoDeployer again, but I'm not sure I like having two
> AutoDeployers
> just for this reason.
I think until we think of a better solution having 2 autodeployers is
better than splitting up the jbosscx.sar.
After a quick look at the autodeployer, it looks to me as if it might help
to try to deploy all possible files as soon as a deployer is registered. It
looks to me as if currently the autodeployer will wait till the next scan
to use the newly registered deployer.
>
> 2. Sounds feasible and desirable. I had a similar idea except that
> instead
> of having to specify these primary sars in the main jboss-service.xml
> file
> you could just put them in the deploy lib and everything would work
> nicely.
> This means however that we are going to run into problems with specifying
> dependencies between rar's and sar's or between ear's and sar's or even
> between ear's and rar's! Basically there is no mechanism at present to
> specify a dependency between files destined for different deployers,
> which
> is the problem I am having. The only way to really do this of course
> would
> be in the AutoDeployer itself but that would require some other mechanism
> because the AutoDeployer doesn't know anything about the content of the
> files it is deploying, maybe a naming scheme?
>
I agree there is a big problem with autodeploy order - you can specify some
things with ordering the deployers and the directories, but this is shaky
at best.
How about a more generalized/unified deployment architecture? At least ejb
jars and ear's are allowed to have more configuration files in them, why
not put a jboss-service.xml file in that can refer to the application.xml
and external files (or internal jars for use in mbeans, as I think you
suggest below.)
so...
Any kind of file goes into the universal deployer.
First we look for a jboss-service.xml which will specify
external sar, jar, rar, ear, war dependencies that should be deployed first
a scope for the classloaders for this stuff (? not sure about this)
internal jar, rar, (ejb) jar dependencies (as you suggest below)
may reference application.xml, ejb-jar.xml, ra.xml (although I'm not sure
what info would be conveyed)
mbean dependencies
mbean configuration
The deployer will unpack the contained packages and feed the internal and
external dependencies to the appropriate deployers.
Then it would deploy using the application.xml or ejb-jar.xml or ra.xml
or...
If there is no jboss-service.xml, it will skip that step and treat it like
a regular rar, ear, or whatever.
It seems to me that all these deployers have 2 stages,
-create some classloaders and make the classes available
-interpret some configuration info.
maybe we can make the first step shared among all the deployers, and get
similar "recycling" classloaders everywhere. Does this make sense to you?
> I have no objection to you moving the classpath deployment ahead of the
> depends check. The reason I didn't do it is that it looks (to me) to be
> quite tricky to do without breaking anything (e.g. what do you do if the
> sar
> you are recursively deploying is not deployed because of another
> dependency,
> how can you even tell if this has happened) and I felt like it probably
> wasn't needed. People should know what mbeans are in the sars they are
> recursively deploying and not put them in depends tags.
Is there a problem with having all the classes available from a sar without
instantiating any mbeans? I couldn't think of a convincing problem, not
could I think of a problem of setting up some of the classloaders and
waiting for others.
>
> On a related note I think we should seriously look at changing the sar
> format so that it contains jars and a default directory structure. We
> can
> then expand the directory structure and copy the jars somewhere on
> deployment and leave the sar in the deploy directory without any live
> reference to it. This will allow people to actually remove the sar from
> the
> deploy directory, at the moment they can't because once it is deployed
> jboss
> has it open with a URLClassLoader. This will also allow directory
> structures to be contained in a sar (useful for hypersonic and jbossmq at
> least). There would then have to be some default way of finding the root
> of
> the directory structure like System.getProperty("jboss.system.deployed")
> +
> sarFileName.
I've thought this too, the RarDeployer and I think the J2ee deployer do
this. Would we prohibit anything except jar/rar/?? other package formats
to be in the sar? or allow "loose" files as in a jar.
david jencks
>
> David
>
> > -----Original Message-----
> > From: David Jencks [mailto:[EMAIL PROTECTED]]
> > Sent: Thursday, September 13, 2001 3:06 PM
> > To: [EMAIL PROTECTED]
> > Subject: Re: [JBoss-dev] CVS update:
> > jbosscx/src/resources/jca-sar/META-IN F jboss-service.xml
> >
> >
> > Well, I have 2 ideas
> >
> > 1. If you put hsql-default-service.xml and jbosscx.sar in
> > lib/ext and had
> > your *service.xml include hsql-default-service.xml in a
> > classpath element,
> > I would expect that to force hsql-default-service to load
> > before your file,
> > forcing jbosscx.sar to load, at which point it will
> > autodeploy the rars,
> > then jsql-default-service will create the DefaultDS
> > ConnectionFactoryLoader
> > mbean, ready for use, then your mbeans will load. If this
> > doesn't happen,
> > it's a bug i want to fix, or understand why I shouldn't. Did
> > you try this?
> > What happened? I think we may need to calling deploy on a
> > deployed package
> > does nothing rather than redeploys it in order to reduce churn when
> > packages are deployed in a random order.
> >
> > 2. I was thinking that a goal for the structuring of the startup
> > configuration might be to have a bunch of small specialized
> > sars each for a
> > piece of jboss. For instance, the
> > naming-tm-security-webserver startup,
> > jbosscx, jbossmq, jetty, jms-connector, and finally the j2ee
> > deployer/autodeployer. Then we could have one
> > master-service.xml file that
> > basically lists all these components in the classpath and
> > provides more
> > specific configuration of some variable mbeans - maybe
> > datasources. That
> > way you can assemble your jboss server from big preconfigured
> > chunks. In
> > this case, none of these "base" sars would be autodeployed --
> > they'd be
> > listed in master.service.xml, so by the time your *-service.xml got
> > autodeployed, everything would be in place. However, I
> > haven't had time to
> > try this out.
> >
> >
> > Btw, the mbean - sar dependency looks good. I'm going to see about
> > implementing undeploy as well, along with improved sar-sar dependency
> > management. Do you have an objection to deploying the packages in the
> > classpath elements before checking the depends elements? That
> > way if one of
> > the listed packages provides a needed mbean deployment can proceed
> > automatically.
> >
> > Thanks
> > david jencks
> >
> >
> > On 2001.09.12 22:10:37 -0400 David Maplesden wrote:
> > > I thought you might notice this.
> > >
> > > It did make a lot of sense to have it all in one place but it causes
> > > problems when loading mbeans that lookup the DefaultDS in their
> > > initialisation. I have a custom mbean I am deploying in
> > JBoss and if it
> > > gets deployed before the various RAR files are deployed
> > then the lookup
> > > of
> > > the DataSource fails.
> > >
> > > Currently there is no way to test if the rar files have
> > been deployed or
> > > not, so the only way I could solve the problem was to
> > guarantee the rar
> > > files are deployed first by starting the RARDeployer before the
> > > AutoDeployer
> > > and moving all the service.xml files etc into the deploy
> > directory which
> > > gets deployed after the deploy/lib directory.
> > >
> > > If you can think of another solution I would like to hear it.
> > >
> > > Cheers,
> > > David.
> > >
> > > > -----Original Message-----
> > > > From: David Jencks [mailto:[EMAIL PROTECTED]]
> > > > Sent: Thursday, September 13, 2001 2:16 PM
> > > > To: [EMAIL PROTECTED]
> > > > Subject: Re: [JBoss-dev] CVS update:
> > > > jbosscx/src/resources/jca-sar/META-INF jboss-service.xml
> > > >
> > > >
> > > > David, what problem are you solving by splitting up this
> > package? I
> > > > thought it made a lot of sense to have all the jca stuff in
> > > > one package.
> > > >
> > > > david jencks
> > > >
> > > >
> > > > On 2001.09.12 19:06:52 -0400 David Maplesden wrote:
> > > > > User: dmaplesden
> > > > > Date: 01/09/12 16:06:52
> > > > >
> > > > > Modified: src/resources/jca-sar/META-INF jboss-service.xml
> > > > > Log:
> > > > > Change default configuration to start RARDeployer before
> > > > AutoDeployer
> > > > >
> > > > > Revision Changes Path
> > > > > 1.3 +1 -5
> > > > jbosscx/src/resources/jca-sar/META-INF/jboss-service.xml
> > > > >
> > > > > Index: jboss-service.xml
> > > > >
> > > >
> > ===================================================================
> > > > > RCS file:
> > > > /cvsroot/jboss/jbosscx/src/resources/jca-sar/META-INF/jboss-se
> > > > rvice.xml,v
> > > > > retrieving revision 1.2
> > > > > retrieving revision 1.3
> > > > > diff -u -r1.2 -r1.3
> > > > > --- jboss-service.xml 2001/09/11 02:48:21 1.2
> > > > > +++ jboss-service.xml 2001/09/12 23:06:52 1.3
> > > > > @@ -7,7 +7,7 @@
> > > > > <!--
> > > >
> > > > > -->
> > > > > <!--
> > > >
> > =====================================================================
> > > > > -->
> > > > >
> > > > > -<!-- $Id: jboss-service.xml,v 1.2 2001/09/11 02:48:21
> > > > dmaplesden Exp $
> > > > > -->
> > > > > +<!-- $Id: jboss-service.xml,v 1.3 2001/09/12 23:06:52
> > > > dmaplesden Exp $
> > > > > -->
> > > > >
> > > > > <!--
> > > > > | This contains configuration for the
> > RARDeployer and the
> > > > > @@ -31,10 +31,6 @@
> > > > > <!-- The RARDeployer and three Connection Manager
> > Factories are
> > > > > parts of -->
> > > > > <!-- JBoss and do not need further configuration.
> > > >
> > > > > -->
> > > > > <!--
> > > >
> > ====================================================================
> > > > > -->
> > > > > -
> > > > > - <mbean code="org.jboss.resource.RARDeployer"
> > > > > - name="JCA:service=RARDeployer">
> > > > > - </mbean>
> > > > >
> > > > > <!--
> > > > > | Minerva no transaction connection manager factory.
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > _______________________________________________
> > > > > 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
