cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Carsten Ziegeler" <cziege...@s-und-n.de>
Subject RE: CocoonComponentManager.java (Showstopper)
Date Mon, 28 Apr 2003 06:29:47 GMT
Hi Leo,

thanks for reporting and analyzing this. I fixed this over
the weekend (hopefully).

Carsten

> -----Original Message-----
> From: Leo Sutic [mailto:leo.sutic@inspireinfrastructure.com]
> Sent: Thursday, April 24, 2003 7:24 PM
> To: cocoon-dev@xml.apache.org
> Subject: RE: CocoonComponentManager.java (Showstopper)
> 
> 
> I'm trying to remove the use of statics in CocoonComponentManager.
> 
> As I understand it, the CocoonComponentManager is a Singleton with
> respect to the Cocoon instance, right?
> 
> This means that the static variables could in theory be localized to
> that instance, if it weren't for the need to access them via static
> accessors.
> 
> This one is no problem, as it is thread local, and, as I understand it,
> empty at the start of a request and empty at the end of one.
> 
>     /** The environment information */
>     private static InheritableThreadLocal environmentStack = new
> CloningInheritableThreadLocal();
> 
> So that variable should be just fine and we're not going to have any
> classloader issues here.
> 
> This one I don't get:
> 
>     private static Map sitemapConfigurationHolders = new HashMap(15);
> 
> Can these be made thread-local, or per-instance?
> 
>             holder =
> (SitemapConfigurationHolder)sitemapConfigurationHolders.get( role );
>             if ( null == holder ) {
>                 // create new holder
>                 holder = new DefaultSitemapConfigurationHolder( role );
>                 sitemapConfigurationHolders.put( role, holder );
>             }
> 
> This one, however, is poison:
> 
>     private static ComponentManager rootManager;
> 
> Can it be made instance-specific? It is only used as a default in:
> 
>     public ComponentManager getSitemapComponentManager()
> 
> and that method is only referenced from AbstractEnvironment in the
> starting()
> method. Ironically, the Environment is created in CocoonComponentManager
> itself,
> so it is a no-brainer to pass the manager in right then and there.
> 
> However, the SourceUtil and JSCocoon classes also reference this method.
> 
> The question is then: Is JSCocoon's invocations done before or after the
> 
> Environment is set up? In that case, the getSitemapComponentManager
> can return null if no environment is set up:
> 
>     public ComponentManager getSitemapComponentManager() {
>         final EnvironmentStack stack =
> (EnvironmentStack)environmentStack.get();
>         
>         if ( null != stack && !stack.empty()) {
>             Object[] o = (Object[])stack.peek();
>             return (ComponentManager)o[2];
>         }
>         
>         // if we don't have an environment yet, just return null
>         return null; // WAS: rootManager;
>     }
> 
> Since, if I understand this correctly, the only time you'd fall through
> was when
> called from the AbstractEnvironment.starting() method, which was
> unneeded.
> 
> /LS
> 
> > From: Leo Sutic [mailto:leo.sutic@inspireinfrastructure.com] 
> > 
> > In CocoonComponentManager there's this:
> > 
> >     private static ComponentManager rootManager;
> > 
> > and this:
> > 
> >     private static Map sitemapConfigurationHolders = new HashMap(15);
> > 
> > This completely obliterates any attempt at having multiple 
> > cocoon instances 
> > in one classloader, as it forces one config->one classloader.
> > 
> > Is this intentional?
> > 
> > /LS
> > 
> > 
> 

Mime
View raw message