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.
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 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.
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.
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
