sitemap component selector (was: sub sitemap broken)

[Torsten Curdt <tc...@dff.st>]

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

---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org

Re: sitemap component selector (was: sub sitemap broken)

[Berin Loritsch <bl...@apache.org>]

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: cocoon-dev-unsubscribe@xml.apache.org
> > For additional commands, email: cocoon-dev-help@xml.apache.org

Re: sitemap component selector (was: sub sitemap broken)

[Berin Loritsch <bl...@apache.org>]

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

RE: sitemap component selector (was: sub sitemap broken)

[Torsten Curdt <tc...@dff.st>]

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

Re: sitemap component selector (was: sub sitemap broken)

[Berin Loritsch <bl...@apache.org>]

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.

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.

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

RE: sitemap component selector (was: sub sitemap broken)

[Torsten Curdt <tc...@dff.st>]

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

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 ;)
--
Torsten

---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org

Re: sitemap component selector (was: sub sitemap broken)

[Sergio Carvalho <se...@acm.org>]

I also get the same error by requesting a page from the sub-sitemap with a ?cocoon-reload=true parameter.

On Mon, 18 Jun 2001 11:56:59 +0200
"Torsten Curdt" <tc...@dff.st> wrote:

> 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?!
> --
> Torsten
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
> 
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org