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: [EMAIL PROTECTED]
> For additional commands, email: [EMAIL PROTECTED]
S/MIME Cryptographic Signature
