I disagree. The classpath element is used for explicitly stating which jars are necessary for the package you are deploying. If one of the "classpath" jars is undeployed, the depending package will be suspended until the needed jar is again deployed.
Is this the same functionality your MBeanClassLoader is supposed to provide? If so, how exactly is this supposed to work? I think most of the problems are caused by the time during which jetty needed tools.jar in lib/ext and we couldn't ship it, and the excessive list in the conf/default/jboss-service.xml. IMHO these jars need to be parceled out to the packages that actually use them. david jencks On 2001.12.06 00:13:47 -0500 marc fleury wrote: > I am against it, the only reason it is there is that a directory cannot > be listed through http, which is a bummer really but that is the way it > goes. However a file based installation can be listed easily and thus we > would bypass the need to list the individual jars by just specifying the > directory. > > This throws off a lot of people and I understand why people complain a > lot these days about "file not found" on boot, it is because they are > missing some components (removed whatever) and then the classpath is > trying to load and fails miserably. > > Let the mbean loading fail, also the comments in there explain clearly > that it is supposed to be left commented if not used in net-boot mode, > will make it clear > > ---- > JBoss Forums: JBoss Development: Explicit use of Classpath in service.xml > View: http://jboss.org/forums/thread.jsp?forum=66&thread=4932 > Reply: >http://jboss.org/forums/post.jsp?forum=66&thread=4932&message=355598&reply=true > > > > _______________________________________________ > 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
