[Springframework-developer] Re: [Springframework-user] ClassPathXmlApplicationContext

[Colin S. <col...@ex...>]

I actually added two convenience methods to ClassLoadUtils, for making 
this sort of stuff easier:

    /**
     * Given an input class object, returns a string which consists of 
the class's package
     * name as a pathname, i.e., a leading '/' is added, and all dots 
('.') are replaced by
     * slashes ('/'). A trailing slash is <b>not</b> added.
     * @param clazz the input class
     * @return a path which represents the package name, including a 
leading slash
     */
    public static String classPackageAsResourcePath(Class clazz) {
        StringBuffer retval = new StringBuffer("/");
        if (clazz == null)
            return retval.toString();
        StringTokenizer st = new 
StringTokenizer(clazz.getPackage().getName(), ".");
        while (st.hasMoreTokens()) {
            retval.append(st.nextToken());
            if (st.hasMoreTokens())
                retval.append("/");
        }
        return retval.toString();
    }
 
 
    /**
     * Returns a path suitable for use with {@see Class.getResource} 
build by taking
     * the package of the specified class file, converting all dots 
('.') to slashes
     * ('/'), adding a trailing slash, and concatenating the specified 
resource name
     * to this. As such, this function may be used to build a path 
suitable for loading
     * a resource file that is in the same package as a class file.
     * @param clazz the Class whose package will be used as the base.
     * @param resourceName the resource name to append. A leading slash 
is optional.
     * @return The built-up resource path.
     */
    public static String addResourcePathToPackagePath(Class clazz, 
String resourceName) {
        if (!resourceName.startsWith("/"))
            return classPackageAsResourcePath(clazz) + "/" + resourceName;
        else
            return classPackageAsResourcePath(clazz) + resourceName;
    }


These should make having a context definition (or any other resource) 
that stays in the same package as a certain class trivial. E.g.

import ClassLoaderUtils;
public class MyClass {
  private static String RESOURCE = 
ClassLoaderUtils.addResourcePathToPackagePath(MyClass.class, 
"myresource.xml";

  ...
}


Regards,
Colin



Colin Sampaleanu wrote:

> Yes, Class.getResourceAsStream will attempt to load out of the package 
> where the code is executing, but don't forget, it is not your code (in 
> your package), which would be calling getResourceAsStream, it is 
> Spring's code, in its own package. It's actually even more complicated 
> then that, because the call actually ends up going to Springs's 
> ClassLoaderUtils, where the loading happens via a
>        InputStream in = 
> Thread.currentThread().getContextClassLoader().getResourceAsStream(name);
> This is so that if you are in an environment such as a J2EE 
> application server, where the context classpath has been set 
> appropriately by the appserver in the current thread, the right 
> classloader ends up loading the data. If Spring didn't do this, in 
> some app server environments, a spring lib instance in the appserver's 
> own support directory would be used as the basis of the classpath to 
> search, and would never see the resources in the classloader farther 
> down in the hierarchy.
>
> So what I would suggest doing is something like this:
>
> Define a utility method somewhere:
>    /**
>     * Given an input class object, returns a string which consists of 
> the class's package
>     * name as a pathname, i.e., a leading '/' is added, and all dots 
> ('.') are replaced by
>     * slashes ('/')
>     * @param clazz the input class
>     * @return a path which represents the package name, including a 
> leading slash
>     */
>    public static String classPackageAsPath(Class clazz) {
>        StringBuffer retval = new StringBuffer("/");
>        if (clazz == null)
>            return retval.toString();
>        StringTokenizer st = new 
> StringTokenizer(clazz.getPackage().getName(), ".");
>        while (st.hasMoreTokens()) {
>            retval.append(st.nextToken());
>            if (st.hasMoreTokens())
>                retval.append("/");
>        }
>        System.out.println("returning: " + retval.toString());
>        return retval.toString();
>    }
>
> then when you need to load resources relative to a class's package, do 
> something like this:
>
>  private static final String CONTEXT =
>    FileUtil.classPackageAsPath(BasicMappedPersistenceTest.class)
>      + "/BasicMappedPersistenceTestContext.xml";
>
>   ....
>      appContext = new ClassPathXmlApplicationContext(CONTEXT);
>
>
>
> As to whether this belongs in the user list or the dev list, it's 
> somewhat of a grey area. That is, my explanation above definitely 
> belongs in the user list, but this discussion could certainly have 
> lead (or may lead) to further discussion about how to improve this 
> area of spring, which is best handled in the dev list.
>
>
> Regards,
> Colin
>
>
> Keith Donald wrote:
>
>> Is it correct to always prepend a "/" to a resource path passed into
>> ClassPathXmlApplicationContext?  This behaivior forces me to hard-code
>> fully-qualified references to my application context xml files.  
>> Instead,
>> I'd like to be able to pass in a relative name and have
>> getResourceAsStream() attempt to load the resource out of the package 
>> where
>> the code is executing (which is the default behaivior of
>> Class.getResourceAsStream().)
>>
>> For example, I have a context located in my classpath at:
>> /com/csi/cogids/console/console-context.xml.  To load it, I must pass 
>> that
>> full path to ClassPathApplicationContext().  Now say two weeks later I
>> re-factor and re-locate this code to another package--I have to make 
>> sure I
>> update the reference.  I'd rather just be able to say: new
>> ClassPathApplicationContext("console-context.xml") and have it by 
>> default
>> look in the current executing class's package directory.
>>
>> Should I mail stuff like this to the developer list?
>>
>> Thanks,
>> Keith
>