-
1. Re: Classloading vs. VFS
alrubinger May 28, 2009 2:48 AM (in response to jesper.pedersen)This results from parsing a bootstrap.xml with hooks to VFS before VFS itself has been init'd. I've addressed this in jboss-bootstrap-impl-as by a manual hack:
https://jira.jboss.org/jira/browse/JBBOOT-67
http://fisheye.jboss.org/changelog/JBossAS/?cs=88598
So for users of MCServer who need VFS, you've gotta do something similar. But a better solution is for some initvfs.xml to come along early in the bootstrap chain, install an MC Bean which will init VFS, and then all should be good.
Looks like the NCDFE is blocking you from doing that. Which is another issue alltogether. Due to parent>child delegation and leaking of class references, we've got to be very careful what's on the application CP, URLCL, etc. Note that in Branch_5_x of AS right now we prove that things can work. :)
S,
ALR -
2. Re: Classloading vs. VFS
jesper.pedersen May 28, 2009 8:45 AM (in response to jesper.pedersen)
So for users of MCServer who need VFS, you've gotta do something similar. But a better solution is for some initvfs.xml to come along early in the bootstrap chain, install an MC Bean which will init VFS, and then all should be good.
That is the solution I use currently.
Looks like the NCDFE is blocking you from doing that. Which is another issue alltogether. Due to parent>child delegation and leaking of class references, we've got to be very careful what's on the application CP, URLCL, etc.
I only have an AppCL which has my Main and is a parent to the URLCL which has all the JARs. The URLCL is passed to the ServerFactory in bootstrap.
That is the way the ServerFactory is documented and more importantly the way I want my classloader architecture before the MC kicks in.
Note that in Branch_5_x of AS right now we prove that things can work. :)
I see AS usage of bootstrap as a very nice proof-of-concept. However AS shouldn't mandate the way bootstrap should work. There are other projects in the World.
We should make sure that impl-mc meets most of the requirements for projects using the MC as the foundation. Otherwise each project has to implement an extension to fill in the blanks. -
3. Re: Classloading vs. VFS
alrubinger May 28, 2009 9:52 AM (in response to jesper.pedersen)"jesper.pedersen" wrote:
Looks like the NCDFE is blocking you from doing that. Which is another issue alltogether. Due to parent>child delegation and leaking of class references, we've got to be very careful what's on the application CP, URLCL, etc.
I only have an AppCL which has my Main and is a parent to the URLCL which has all the JARs. The URLCL is passed to the ServerFactory in bootstrap.
Right, what I'm getting at is the "all the JARs" part. Take a look at how restrictive/careful we've gotta be in AS, for example:/** * The default list of boot libraries. Does not include * the JAXP or JMX impl, users of this class should add the * proper libraries. * TODO: use vfs to list the root directory * http://www.jboss.org/index.html?module=bb&op=viewtopic&t=153175 * * Copied from legacy bootstrap ServerLoader * //TODO JBAS-6920 */ @Deprecated public static final String[] DEFAULT_BOOT_LIBRARY_LIST = { // Concurrent "concurrent.jar", // Logging "log4j-boot.jar", "jboss-logging-spi.jar", "jboss-logging-log4j.jar", "jboss-logging-jdk.jar", "jboss-logmanager.jar", "jboss-logbridge.jar", // Common jars "jboss-common-core.jar", "jboss-xml-binding.jar", // Bootstrap "jboss-bootstrap-spi.jar", "jboss-bootstrap-spi-as.jar", "jboss-bootstrap-spi-mc.jar", "jboss-bootstrap-impl-base.jar", "jboss-bootstrap-impl-as.jar", "jboss-bootstrap-impl-mc.jar", // Microcontainer "javassist.jar", "jboss-reflect.jar", "jboss-mdr.jar", "jboss-dependency.jar", "jboss-kernel.jar", "jboss-metatype.jar", "jboss-managed.jar", // Fixme ClassLoading "jboss-vfs.jar", "jboss-classloading-spi.jar", "jboss-classloader.jar", "jboss-classloading.jar", "jboss-classloading-vfs.jar", // Fixme aop "jboss-aop.jar", "jboss-aop-mc-int.jar", "trove.jar",};
That's in Main. Any more/less leads to NCDFE."jesper.pedersen" wrote:
We should make sure that impl-mc meets most of the requirements for projects using the MC as the foundation. Otherwise each project has to implement an extension to fill in the blanks.
So I suppose the question on the table is whether MCServer should init VFS automatically. While convenient, the thing there is that this isn't really MCServer's job (because it implies VFS will always be used). Opinions?
S,
ALR -
4. Re: Classloading vs. VFS
jesper.pedersen May 28, 2009 10:24 AM (in response to jesper.pedersen)Yeah, and do we want to create that hard dependency between the MC and VFS ?
Another question is if bootstrap/MC should make assumptions about CLs. I think having to define a DEFAULT_BOOT_LIBRARY_LIST is something we should think about. -
5. Re: Classloading vs. VFS
alrubinger May 28, 2009 10:59 AM (in response to jesper.pedersen)"jesper.pedersen" wrote:
Another question is if bootstrap/MC should make assumptions about CLs. I think having to define a DEFAULT_BOOT_LIBRARY_LIST is something we should think about.
We don't. :) We boot library list is of the AS Main, not bootstrap. It can be removed from its explicit form if we change the build to only put stuff in $JBOSS_HOME/lib which should be part of the boot CL.
S,
ALR -
6. Re: Classloading vs. VFS
jesper.pedersen May 28, 2009 1:29 PM (in response to jesper.pedersen)
We don't. :) We boot library list is of the AS Main, not bootstrap. It can be removed from its explicit form if we change the build to only put stuff in $JBOSS_HOME/lib which should be part of the boot CL.
My point is here - why do we have to define a DEFAULT_BOOT_LIBRARY_LIBS in our Main ? Splitting our classloader structure into multiple layers shouldn't be needed.
Passing the classloader defined in Main to the bootstrap implementation should be enough.
And I'm not talking about the AS; I'm talking about projects that uses the MC as a foundation and bootstrap to get it up and running. -
7. Re: Classloading vs. VFS
alrubinger May 28, 2009 4:06 PM (in response to jesper.pedersen)"jesper.pedersen" wrote:
My point is here - why do we have to define a DEFAULT_BOOT_LIBRARY_LIBS in our Main ? Splitting our classloader structure into multiple layers shouldn't be needed.
Passing the classloader defined in Main to the bootstrap implementation should be enough.
You've lost me. All I do in AS Main is pass the CL to the bootstrap impl.ClassLoader newCl = new URLClassLoader(allTheStuffInBootLib); Server server = ServerFactory.createServer(newCl); Thread.currentThread().setContextClassLoader(newCl); server.start();
What are you proposing should be done instead?
S,
ALR -
8. Re: Classloading vs. VFS
jesper.pedersen May 28, 2009 4:52 PM (in response to jesper.pedersen)The same - but allTheInBootLib IS all the stuff in lib which is > DEFAULT_BOOT_LIBRARY_LIBS.
I only have a single lib/ directory where the entire container is located. -
9. Re: Classloading vs. VFS
alrubinger Jun 1, 2009 3:58 PM (in response to jesper.pedersen)Ran through this a bit today. Came across in the JCA Standalone:
Caused by: java.net.MalformedURLException: unknown protocol: vfsfile
...as Jesper's been encountering.
It's this logic which fully inits VFS:
http://anonsvn.jboss.org/repos/jbossas/projects/bootstrap/trunk/impl-as/src/main/java/org/jboss/bootstrap/impl/as/lifecycle/VfsInitializingLifecycleEventHandler.java
Note the installation of the protocol handlers.
Let's work through this first, get it committed to SVN, then address the ClassLoading issues. :)
S,
ALR