cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Vadim Gritsenko" <vadim.gritse...@verizon.net>
Subject Re: Bug in TreeProcessor sitemap reloading?
Date Sun, 14 Apr 2002 03:51:41 GMT
Sylvain,

> Vadim Gritsenko wrote:
>
> >Hi all,
> >
> >Is this an undiscovered bug in the TreeProcessor?
> >
> >0. Go to http://localhost:8080/cocoon/formvalidation/test
> >1. Hit "submit"
> >2. Touch sitemap.xmap
> >3. Hit "submit"
> >4. Get "java.lang.IllegalStateException: You cannot lookup components
on
> >a disposed ComponentManager"
> >
> >XSP page never gets new component manager on the sitemap
> >re-initialization.
> >
>
> This seems to be a bug in the way the XSP engine handles CMs : 
> ServerPagesGenerator calls ProgramGenerator.load() with its own CM, 
> which is then propagated down to JavaProgram which uses it to create a

> ComponentHandler for the compiled XSP. The XSP is then stored in the 
> ProgramGenerator cache.

It seems to me that the bug not in the XSP engine but in the program
generator. May be it should return component handler instead of trying
to manage components by itself? Consider scenario: same XSP page is used
in two sitemaps, but these two sitemaps have different component which
is looked up by XSP. In current implementation, XSP will get this
component from the sitemap who invoked this XSP first.

If program generator returns handler, then every sitemap will get
handler for this XSP, with different manager -> XSP will lookup correct
component from the correct sitemap. And, on sitemap reload, this handler
will be disposed by the sitemap.

Thoughts?


> Now the CM in ServerPagesGenerator is the local CM of the sitemap, 
> created with the contents of <map:components>. When the sitemap is 
> reloaded, this CM is disposed and a new one is created. But the cached

> XSP still references the previous CM which is now disposed.
>
> This bug doesn't exist in the compiled engine because a compiled
sitemap 
> doesn't have a local CM, but only a set of selectors for each
component 
> type and thus the XSP uses Cocoon's root CM.
>
> IMO, to solve this problem, the ProgramGenerator should use its own CM

> (i.e. Cocoon's root CM) to get a ComponentHandler and then make 
> XSPGenerator (or AbstractServerPage?) recomposable so that it gets the

> correct sitemap CM.

This does not work for sitemap compilation: it must be created with
parent sitemap manager in order to inherit components configured in the
parent.

I rolled back some of the changes - but left recomposable.


> Thoughts ? Does this affect also the JavaScript XSP engine ?

Yes - if XSP needs to get some component.

Vadim


> Sylvain



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


Mime
View raw message