I wonder if we should insist that every file have an explicit deployer, and
keep those without a deployer in a list, and everytime a new deployer comes
online, run the list through it. This would require that we have a jar
deployer that refuses to deploy jars with META-INF/<any recognizable dd>
This would solve Adrians problem, right?
david jencks
On 2002.03.03 11:21:12 -0500 Adrian Brock wrote:
> Hi Jason,
>
> I was seeing a similar problem with the jms-xa mbean.
> I've hacked the build to create jbosscx-service.xml and
> add a jbosspool.jar and jbosscx.jar to lib.
>
> There seems to be a problem with the rar deployments.
> If you modify jbosscx-service.xml or jbosscx.sar
> the RARDeployer gets loaded after rars. This means main
> deployer doesn't recognise the rar deployments and your
> server is broken.
>
> Perhaps the scanner should use the DeploymentSorter
> on "deploy" or deployedSet before deploying/undeploying anything?
>
> This patch gives reasonable results on the testsuite,
> but you have to do a build clean first to get the
> deployments in the correct order.
>
> Of course, you have to copy src/etc/conf/default jbosscx-service.xml
> from the jboss-service.xml
>
> Index: build/build.xml
> ===================================================================
> RCS file: /cvsroot/jboss/build/jboss/build.xml,v
> retrieving revision 1.98
> diff -r1.98 build.xml
> 799a799,816
> > <!-- Copy the generated libraries -->
> > <mkdir dir="${install.lib}"/>
> > <copy todir="${install.lib}" filtering="no">
> > <fileset dir="${_module.output}/lib">
> > <include name="jbosscx.jar"/>
> > </fileset>
> > </copy>
> >
> > <!-- Default server config -->
> >
> > <!-- Copy the jbosscx service xml snippet -->
> > <mkdir dir="${install.server}/default/deploy"/>
> > <copy todir="${install.server}/default/deploy" filtering="no">
> > <fileset dir="${_module.output}/etc/conf/default">
> > <include name="jbosscx-service.xml"/>
> > </fileset>
> > </copy>
> >
> 804d820
> < <include name="jbosscx.sar"/>
> 807a824
> > <!-- <include name="jbosscx.sar"/> -->
> 896a914,921
> >
> > <!-- Copy the generated libraries -->
> > <mkdir dir="${install.lib}"/>
> > <copy todir="${install.lib}" filtering="no">
> > <fileset dir="${_module.output}/lib">
> > <include name="jbosspool.jar"/>
> > </fileset>
> > </copy>
> Index: connector/build.xml
> ===================================================================
> RCS file: /cvsroot/jboss/jbosscx/build.xml,v
> retrieving revision 1.28
> diff -r1.28 build.xml
> 271a272,277
> > <copy todir="${build.etc}" filtering="yes">
> > <fileset dir="${source.etc}">
> > <include name="**/*"/>
> > </fileset>
> > </copy>
> >
> 308a315,323
> > <!-- Build jbosscx.jar -->
> > <jar jarfile="${build.lib}/jbosscx.jar"
> > manifest="${build.etc}/manifest/version.mf">
> > <fileset dir="${build.classes}">
> > <include name="**"/>
> > <exclude name="**/adapter/**/*.*"/>
> > </fileset>
> > </jar>
> >
> 311c326
> < <jar jarfile="${build.lib}/jbosscx.sar"
> ---
> > <!-- <jar jarfile="${build.lib}/jbosscx.sar"
> 323c338
> < </jar>
> ---
> > </jar> -->
> Index: server/src/etc/deploy/hsqldb-default-service.xml
> ===================================================================
> RCS file: /cvsroot/jboss/jboss/src/etc/deploy/hsqldb-default-service.xml,v
> retrieving revision 1.1
> diff -r1.1 hsqldb-default-service.xml
> 14c14
> < <classpath archives="jbosscx.sar"/>
> ---
> > <classpath archives="*"/>
>
>
> Regards,
> Adrian
>
> > >
> > >
> > >In general, that won't help. It happens in this
> > case that jbosscx.sar
> > >defines an mbean that DefaultDS needs, so deployment
> > would wait, but if put
> > >the ConnectionFactoryLoader class somewhere else
> > there'd be no way to look
> > >for it using depends. Marc wanted to use the
> > MBeanClassLoader to keep
> > >track of class dependencies and wait if a class was
> > not found when you
> > >tried to "install" it. I'm not sure how far he got
> > with this.
> > >
> > I thought he had given up on this saying there were
> > too many issues... I
> > could be wrong.
> >
> > >Looking for depends elements before the mbean is
> > available also means you
> > >either have to parse the xml twice or parse it into
> > a holding structure and
> > >then later transfer it to the mbean itself. I guess
> > the latter might be
> > >possible using xmbean interceptors, but I'm not
> > convinced it will buy us
> > >anything.
> > >
> > I was looking at this, and had a look at the JAXB and
> > some Castor.
> > Basically we have all of the information we need
> > from the XML. If the
> > first step was to take XML and turn it into an object
> > model (which would
> > do type checking, property resolution amoung other
> > things), then would
> > not have to parse twice.
> >
> > I read some parts of the JAXB user's guide and it
> > looks like it must
> > have a DTD to generate classes... which means that we
> > probably can not
> > use it for jboss-service.xml, as the config snippet
> > support won't work.
> > I have not looked at the details from Castor, but if
> > it will allow us
> > to map xml with out a schema then it might be the way
> > to go.
> >
> > Any ways, that still needs to be sorted out and
> > prototyped before we can
> > go implementing it anywhere.
> >
> > Short-term, parsing twice does not seem too bad
> > here... though as you
> > said I am not sure how much it will help... though I
> > think it would be
> > the right thing todo here, do depends before
> > installing.
> >
> > I think that we might want to "do away" with the .sar
> > format as we know
> > it... we can figure out how to deal with native
> > libraries and canned
> > file systems later.
> >
> > To get around the problem that I am seeing, we would
> > need to pull out
> > the common resource classes and deploy them from
> > lib/* and then just
> > deploy the config for the connection*.
> >
> > --jason
> >
> >
> >
> > _______________________________________________
> > Jboss-development mailing list
> > [EMAIL PROTECTED]
> > https://lists.sourceforge.net/lists/listinfo/jboss-dev
> > lopment
>
>
>
> _________________________________________________________
> View thread online: http://main.jboss.org/thread.jsp?forum=66&thread=10057
>
> _______________________________________________
> 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
