You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tapestry.apache.org by Kent Tong <ke...@cpttm.org.mo> on 2006/12/15 17:05:03 UTC

T5: bug in IOCUtilities?

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: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org


Re: T5: bug in IOCUtilities?

Posted by Kent Tong <ke...@cpttm.org.mo>.
Howard Lewis Ship <hlship <at> gmail.com> writes:

> 
> 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.

Right! Sorry for the false alarm!

--
Author of a book for learning Tapestry (http://www.agileskills2.org/EWDT)


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org


Re: T5: bug in IOCUtilities?

Posted by Howard Lewis Ship <hl...@gmail.com>.
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 <ke...@cpttm.org.mo> 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: dev-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
>
>


-- 
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