From: Adrian B. <no...@jb...> - 2002-03-03 16:21:13
|
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 > Jbo...@li... > https://lists.sourceforge.net/lists/listinfo/jboss-dev > lopment _________________________________________________________ View thread online: http://main.jboss.org/thread.jsp?forum=66&thread=10057 |