cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Torsten Curdt" <tcu...@dff.st>
Subject RE: sitemap component selector (was: sub sitemap broken)
Date Tue, 19 Jun 2001 13:14:46 GMT
> > > 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?

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

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

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