You are viewing a plain text version of this content. The canonical link for it is here.

Posted to dev@cocoon.apache.org by Leo Sutic <le...@inspireinfrastructure.com> on 2003/04/24 19:03:06 UTC

CocoonComponentManager.java

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

RE: CocoonComponentManager.java (Showstopper)

Posted by Leo Sutic <le...@inspireinfrastructure.com>.

OK, can confirm that it works fine.

/LS

> From: Leo Sutic [mailto:leo.sutic@inspireinfrastructure.com]

RE: CocoonComponentManager.java (Showstopper)

Posted by Leo Sutic <le...@inspireinfrastructure.com>.

Thanks Carsten!

> From: Carsten Ziegeler [mailto:cziegeler@s-und-n.de] 
> 
> Hi Leo,
> 
> thanks for reporting and analyzing this. I fixed this over
> the weekend (hopefully).

I'll try out the latest CVS of Cocoon and get back to you.

/LS

RE: CocoonComponentManager.java (Showstopper)

Posted by Carsten Ziegeler <cz...@s-und-n.de>.

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

RE: CocoonComponentManager.java (Showstopper)

Posted by Leo Sutic <le...@inspireinfrastructure.com>.

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