Classpath State of the Union
Classpath State of the Union
- Subject: Classpath State of the Union
- From: Mike Schrag <email@hidden>
- Date: Mon, 12 Nov 2007 12:14:05 -0500
Lots of people have been plagued with classpath oddities (especially
the Session and the Main class one matching javamail and log4j
respectively). After much digging, the "official unofficial" causes
seem to be:
1) When launching from Eclipse, bundle loading works a little
differently, and I believe Anjo's fixes to WOLips should have this
resolved now.
2) When launching from Commandline (... including deployment), there
are several nasty buggers at play:
2a) Whether or not you are embedding frameworks, check your .woa's
Info.plist. If it defines the key Has_WOComponents (whether or not it
says true, just whether it exists), this is a bug. At some point in
WOLips, the default Info.plist template was modified to include this,
and it causes .woa bundles to be identified as frameworks by the
NSBundle loader. Ordinarily, classes are loaded from .woa bundles
first, followed by frameworks. When Has_WOComponents is set, it
appears that the .woa gets lumped in with the frameworks, and it
actually loads last instead of first. So delete this key and value if
it's in your .woa and it should save you some pain.
2b) If you embed frameworks, there is a bug in NSBundle that causes
all jars within your application to load in as part of the .woa. So
each framework loads its jars, and the framework classes are
associated with the Framework, then at the end of the process, the
main bundle loads all of its jars. The problem is that the loading
behavior is such that it doesn't restrict to your Resources folder, it
loads ALL jars in the .woa. This means that it slurps up all the jars
from your embedded frameworks also. This causes indeterminate load
order of the classes, which is probably one of the most likely reasons
people get the Session and Main problem. There are two fixes to this
-- either you move your frameworks outside of the woa and modify your
MacOSClasspath.txt to point to their new location, or you have to
patch NSBundle. Hopefully we will have an acceptable workaround for
this patching soon -- Q is working on some fanciness to make it
possible to fix without shipping a decompiled NSBundle in Project
Wonder.
The combination of these two problems I believe explains the vast
majority of these funky loading issues people run into ... The actual
fix is submitted to Apple, too, so if they qualify and approve it,
maybe these problems will go away in future WO's.
ms
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden