Berin Loritsch wrote:
>
> 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.
Try the current CVS. I fixed this problem.
> > > > > >
> > > > > > 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
