cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Berin Loritsch <blorit...@apache.org>
Subject Re: sitemap component selector (was: sub sitemap broken)
Date Tue, 19 Jun 2001 13:36:07 GMT
Torsten Curdt wrote:
> 
> > > > I also get the same error by requesting a page from the sub-sitemap with
a ?cocoon-reload=true parameter.
> > > >
> > > > > What I found out so far....
> > > > >
> > > > > 1) When I start with a clean repository everything seems to work...
> > > > > 2) Restarting Tomcat a second time shows the bug.
> > > > >
> > > > > I checked the SitemapComponentSelector. The parent selector is always
set
> > > > > - never null. That's really strange!
> > > > >
> > > > > What's the difference to a clean repository?!
> > >
> > > Berin, Giacomo,
> > >
> > > I'm really trying to track this down but I need
> > > your guidance...
> > >
> > > For my understanding: Where is the need of an hierarchical
> > > ComponentManager when we want to reuse components as good
> > > as possible? When a component is looked up and an instance
> > > is created, the instance is only available to the ComponentManager
> > > (and it's childs) that created it, right? But how does that make
> > > sense? When a component is created in a sub sitemap's ComponentManager
> > > why shouldn't this component also be reused in a different sub sitemap
> > > or the main sitemap? What did I miss to understand ?
> >
> > What happens is that the ComponentManager will try to look up a Component
> > itself.  If it can't find it, it checks it's parent.  If the parent can't
> > find it, the original component manager will attempt to build it.  This
> > happens for each ComponentManager in the chain.
> 
> But since the Component will be created within the original
> ComponentManager (which might be a child of others) means the
> parent ComponentManager will not be aware of Components inside the
> child ComponentManager(s). I'm asking if this is really desireable
> in terms of re-use - even for security constraints...
> 
> > The Sitemaps do need their own ComponentManager due to security constraints,
> > and the fact that the ExcaliburComponentManager is Initializable now.  That
> > means that once it is initialized, it cannot add new components.
> 
> Hm... AFAIU the concept in general Components are loaded when they are needed
> (except for those implementing e.g. ThreadSafe - the daemon thing) But how can
> this work if the ComponentManager is initializeable... Components will not be able
> to be added later on when they are needed... Did the basic concept change?

It is a method of limiting knowledge.  We don't want entities that don't know
each other to know each other's contents.

> > > In my last working version there was also only ONE ComponentManager
> > > for all sitemaps. My first humbled tries to go back to one ComponentManager
> > > failed. But before wasting time on this maybe one of you guys might
> > > spend a minute and entlighten me ;)
> >
> > This was true.  But this is also before Excalibur made that design change.
> > You will find that the design change is also what enables the load on startup
> > of ThreadSafe Components (i.e. getting Daemon Components to run when the
> > ComponentManager is initialized.
> 
> Yes... but the ComponentManager cannot know about all the Components that
> will be needed to load, will he? (Well, except from the RoleManager...)

Once configured yes.  Also, before it is initialized, you can insert as many
manual components as you wish.

> Anyway - coming back to the original problem... Have you any idea what might
> cause the difference if there is a repository or not?
> Keeping your words in mind I wonder if the new ComponentManager inside the
> AbstractSitemap lacks initialzing!?

I have no clue what the difference is between having a Repository or not--unless
the repository version is instantiated with the wrong ComponentManager!  That is
most likely the issue.

It is initialized after it is Configured.  Check the sitemap.xsl file.

> 
> Just throw me a bone and I'll have a look at it ;)
> Thanks
> --
> Torsten
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
Mime
View raw message