The builder's classLoader is the thread's context class loader (notice,
builder.getClassLoader(), not builder.getClass().getClassLoader()). It will
have visibility to the WAR's classes as well as the frameworks.
On 12/15/06, Kent Tong <[EMAIL PROTECTED]> wrote:
Hi,
In IOCUtilities.java, it is using the class loader of the RegistryBuilder
to load the manifests:
public static void addDefaultModules(RegistryBuilder builder)
{
try
{
Enumeration<URL> urls =
builder.getClassLoader().getResources("META-INF/MANIFEST.MF");
while (urls.hasMoreElements())
{
URL url = urls.nextElement();
addModulesInManifest(builder, url);
}
}
...
}
If the T5 jars are stored in the common lib in Tomcat, will it miss
those manifests in the jars in the context lib? I can see that the
TapestryFilter is correctly using the thread's context classloader,
so I am just wondering why the same technique is not applied to
IOCUtilities. If it is indeed a bug, I can try to fix it.
--
Author of a book for learning Tapestry (http://www.agileskills2.org/EWDT)
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Howard M. Lewis Ship
TWD Consulting, Inc.
Independent J2EE / Open-Source Java Consultant
Creator and PMC Chair, Apache Tapestry
Creator, Apache HiveMind
Professional Tapestry training, mentoring, support
and project work. http://howardlewisship.com
