cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "solprovider (JIRA)" <>
Subject [jira] Commented: (COCOON-2068) Add failover for loading classes.
Date Thu, 24 May 2007 14:55:16 GMT


solprovider commented on COCOON-2068:

Hi Carlsten,

I changed the code and comment for this entry after thinking for a moment.  Thanks for the
quick response.

My environment is SAP Portal.  The best method to install Cocoon would be as a servlet in
the WAS, but that is politically improbable so I am converting Cocoon to a PAR. ("Portal Archive"
PAR = SAP Portal's corruption of the EAR standard.  I have not investigated Sun's "Provider
Archive" PAR.)  A PAR may be more flexible than a servlet.  SAP does not worry about standards
so this will be fun.   My effort should also discover issues typically unnoticed by people
using the Jetty or Tomcat environments (as in yesterday's report.)

Adding the correct directories to the ClassLoader would be good, but I have yet to find a
method to create the directory paths to where the files are located.  The files in a PAR are
distributed to several directories.  The SAP method is to use "ResourceBundles", but that
is more customization than should be necessary.

Next is architecting how to call getResource from ClassUtils using the ServletContext rather
than the ClassLoader because the ClassLoader cannot find files in the JAR calling it.  Creating
a generic solution is difficult because Cocoon isolates the servlet class.  I may void the
warranty with that patch.

> Add failover for loading classes.
> ---------------------------------
>                 Key: COCOON-2068
>                 URL:
>             Project: Cocoon
>          Issue Type: Improvement
>          Components: * Cocoon Core
>    Affects Versions: 2.1.10
>            Reporter: solprovider
>            Priority: Minor
> The ClassLoader from currentThread.getContextClassLoader() was unable to retrieve classes
in my environment.  Add fallback to standard Java class loading.
> NOTE: The two "set" lines would work in either order.  I believe Cocoon is using a custom
ClassLoader to dynamically load changes so the custom method must be tried first.  (The auto-reload
ability will be lost for environments using the fallback, but at least they will be able to
use Cocoon.)
> public class ClassUtils{
>    public static Class loadClass(String className) throws ClassNotFoundException{
>       Class ret;
>       try{
>          ret= ClassUtils.getClassLoader().loadClass(className);
>       }catch(ClassNotFoundException e){
>           ret= Class.forName(className);
>      }
>       return ret;
>    }
> }

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message