You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Vadim Gritsenko <va...@reverycodes.com> on 2004/06/08 14:14:52 UTC
Bug? Foreign SourceResolver in Generator.configure()
Hey,
Noticed yesterday while using HTMLGenerator: SourceResolver used in
configure() method, obtained via
this.manager.lookup(org.apache.excalibur.source.SourceResolver.ROLE),
appears to be not of the sitemap where generator was declared, but of
the sitemap where generator is used. Bug?
PS This is cocoon-2.1-20040517
Vadim
RE: Bug? Foreign SourceResolver in Generator.configure()
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Reinhard Poetz wrote:
>
> To make sure we all speak about the same:
>
> main-sitemap:
> <map:components>
> <map:generator type="xyz" src="XyzGenerator">
> <confFile>myConfFile.txt</confFile>
> </map:generator>
> </map:components>
>
> some sub-sitemap:
> <map:generator type="xyz">
> <map:parameter name="confFile" value="confFile2.txt"/>
> </map:generator>
You mean map:generate, right :)
>
> myConfFile is located relativ to the main-sitemap myConfFile
> is located relativ to the sub-sitemap
>
> That's the way *I* expect it. Another behaviour is IMHO a bug
> because I wouldn't have a chance to set a global
> configuration file, would I?
Yes, I agree with you - and I think as well that it's a bug.
As a workaround you could use "context://" in the first case
and perhaps that's what the user currently use and that's
why noone has the problem right now?
> 2.2 gives us the chance to correct it.
>
That's true.
Carsten
Re: Bug? Foreign SourceResolver in Generator.configure()
Posted by Reinhard Poetz <re...@apache.org>.
Carsten Ziegeler wrote:
>Reinhard Poetz wrote:
>
>
>>Carsten Ziegeler wrote:
>>
>>
>>
>>>Thanks Vadim for the test case.
>>>
>>>Ok, we have a minor problem here :)
>>>
>>>The contract of the SourceResolver is that it always
>>>
>>>
>>resolves relative
>>
>>
>>>to the *current sitemap*. The interesting question now is:
>>>
>>>
>>what is the
>>
>>
>>>"current sitemap" for a component that is instantiated? Is it the
>>>sitemap the component is declared in or the sitemap of the current
>>>request?
>>>Now, I tend to the first option. If this is the case we have a bug :(
>>>
>>>To be precise I think we have this behaviour in Cocoon since 2.1.0.
>>>I just tested 2.1.5 and the problem exists there as well.
>>>
>>>The problem is that the lookup and therefore the
>>>
>>>
>>initialization of the
>>
>>
>>>generator is started from the sub sitemap and the sub
>>>
>>>
>>sitemap of course
>>
>>
>>>runs in the context of the location of the sub sitemap.
>>>
>>>Now, we could solve this by "surrounding" the initialization
>>>
>>>
>>phase of a
>>
>>
>>>component with a change of the current context. So, all init
>>>
>>>
>>methods of
>>
>>
>>>a component run in the context of the sitemap where the component is
>>>defined. All other methods run in the context of the sitemap
>>>
>>>
>>where the
>>
>>
>>>component is used.
>>>
>>>WDYT?
>>>
>>>
>>>
>>>
>>Sounds to be the solution that is expected by the user.
>>
>>
>>
>Yes, the problem imho is that it "sounds" this way. Although this
>bug is in Cocoon since years, noone complained about it until
>recently - so either noone needed it until now or the current
>way (the "bug") is the way user expect it :)
>
>
To make sure we all speak about the same:
main-sitemap:
<map:components>
<map:generator type="xyz" src="XyzGenerator">
<confFile>myConfFile.txt</confFile>
</map:generator>
</map:components>
some sub-sitemap:
<map:generator type="xyz">
<map:parameter name="confFile" value="confFile2.txt"/>
</map:generator>
myConfFile is located relativ to the main-sitemap
myConfFile is located relativ to the sub-sitemap
That's the way *I* expect it. Another behaviour is IMHO a bug because I
wouldn't have a chance to set a global configuration file, would I?
2.2 gives us the chance to correct it.
--
Reinhard
RE: Bug? Foreign SourceResolver in Generator.configure()
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Vadim Gritsenko wrote:
>
> All sitemap components have two sitemaps - one where
> component is defined, and another where it is used. Reminds
> me of the general problem we have with all other components
> as well. All components have
> (logically) at least two managers, one is "own" manager,
> where component was defined / created; and another is current
> manager of the current request. But physically, component has
> ability to recieve only one manager through compose() method
> (or service() method - for those following all renamings).
> For a moment, we are "abusing" Recomposable to pass second
> manager (and overwriting the first one).
>
> Now, if we somehow able to distinguish between those two - it
> can help fix the problem of two sitemaps, right?
>
Yepp. We already have a solution for this (if this is a nice one,
I don't know).
The component gets the manager of the sitemap it is declared in
via compose/service.
If the component wants the manager of the current sitemap (the
sitemap it is currently used in), it can get this via the Context
object.
WDYT?
Carsten
Re: Bug? Foreign SourceResolver in Generator.configure()
Posted by Vadim Gritsenko <va...@reverycodes.com>.
Carsten Ziegeler wrote:
>Vadim Gritsenko wrote:
>
>
>>Usually you declare component once, and re-use in several
>>sitemaps. In this case, relative URLs in configuration are
>>not possible, only context:// URLs. So, I'd say, nobody
>>should expect such behavior, at least, it is not intuitive.
>>
>>Now question, suppose that this component looks up some other
>>component
>>-- this second component, which sitemap will be current for it?
>>
>>
>>
>Yepp, I was wondering about this as well :)
>
>And if we consider this a bug, and we would change it, the generator
>would behave different in these two cases:
>
>a)
>configure() {
> URI = configuration.getURI();
> source = resolver.resolve(URI); <-- resolved relative to sitemap the
> component is declared in.
>}
>
>b)
>configure() {
> URI = configuration.getURI();
>}
>
>generate() {
> source =resolver.resolve(URI); <-- resolved relative to sitemap the
> component is used in.
>}
>
>Hmm...
>
>
All sitemap components have two sitemaps - one where component is
defined, and another where it is used. Reminds me of the general problem
we have with all other components as well. All components have
(logically) at least two managers, one is "own" manager, where component
was defined / created; and another is current manager of the current
request. But physically, component has ability to recieve only one
manager through compose() method (or service() method - for those
following all renamings). For a moment, we are "abusing" Recomposable to
pass second manager (and overwriting the first one).
Now, if we somehow able to distinguish between those two - it can help
fix the problem of two sitemaps, right?
Vadim
RE: Bug? Foreign SourceResolver in Generator.configure()
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Vadim Gritsenko wrote:
>
> Usually you declare component once, and re-use in several
> sitemaps. In this case, relative URLs in configuration are
> not possible, only context:// URLs. So, I'd say, nobody
> should expect such behavior, at least, it is not intuitive.
>
> Now question, suppose that this component looks up some other
> component
> -- this second component, which sitemap will be current for it?
>
Yepp, I was wondering about this as well :)
And if we consider this a bug, and we would change it, the generator
would behave different in these two cases:
a)
configure() {
URI = configuration.getURI();
source = resolver.resolve(URI); <-- resolved relative to sitemap the
component is declared in.
}
b)
configure() {
URI = configuration.getURI();
}
generate() {
source =resolver.resolve(URI); <-- resolved relative to sitemap the
component is used in.
}
Hmm...
Carsten
Re: Bug? Foreign SourceResolver in Generator.configure()
Posted by Vadim Gritsenko <va...@reverycodes.com>.
Carsten Ziegeler wrote:
>Reinhard Poetz wrote:
>
>
>>Carsten Ziegeler wrote:
>>
>>
>>
>>>Thanks Vadim for the test case.
>>>
>>>Ok, we have a minor problem here :)
>>>
>>>The contract of the SourceResolver is that it always
>>>
>>>
>>resolves relative
>>
>>
>>>to the *current sitemap*. The interesting question now is:
>>>
>>>
>>what is the
>>
>>
>>>"current sitemap" for a component that is instantiated? Is it the
>>>sitemap the component is declared in or the sitemap of the current
>>>request?
>>>Now, I tend to the first option. If this is the case we have a bug :(
>>>
>>>To be precise I think we have this behaviour in Cocoon since 2.1.0.
>>>I just tested 2.1.5 and the problem exists there as well.
>>>
>>>The problem is that the lookup and therefore the
>>>
>>>
>>initialization of the
>>
>>
>>>generator is started from the sub sitemap and the sub
>>>
>>>
>>sitemap of course
>>
>>
>>>runs in the context of the location of the sub sitemap.
>>>
>>>Now, we could solve this by "surrounding" the initialization
>>>
>>>
>>phase of a
>>
>>
>>>component with a change of the current context. So, all init
>>>
>>>
>>methods of
>>
>>
>>>a component run in the context of the sitemap where the component is
>>>defined. All other methods run in the context of the sitemap
>>>
>>>
>>where the
>>
>>
>>>component is used.
>>>
>>>WDYT?
>>>
>>>
>>>
>>>
>>Sounds to be the solution that is expected by the user.
>>
>>
>>
>Yes, the problem imho is that it "sounds" this way. Although this
>bug is in Cocoon since years, noone complained about it until
>recently - so either noone needed it until now or the current
>way (the "bug") is the way user expect it :)
>
>
Usually you declare component once, and re-use in several sitemaps. In
this case, relative URLs in configuration are not possible, only
context:// URLs. So, I'd say, nobody should expect such behavior, at
least, it is not intuitive.
Now question, suppose that this component looks up some other component
-- this second component, which sitemap will be current for it?
Vadim
RE: Bug? Foreign SourceResolver in Generator.configure()
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Reinhard Poetz wrote:
>
> Carsten Ziegeler wrote:
>
> >Thanks Vadim for the test case.
> >
> >Ok, we have a minor problem here :)
> >
> >The contract of the SourceResolver is that it always
> resolves relative
> >to the *current sitemap*. The interesting question now is:
> what is the
> >"current sitemap" for a component that is instantiated? Is it the
> >sitemap the component is declared in or the sitemap of the current
> >request?
> >Now, I tend to the first option. If this is the case we have a bug :(
> >
> >To be precise I think we have this behaviour in Cocoon since 2.1.0.
> >I just tested 2.1.5 and the problem exists there as well.
> >
> >The problem is that the lookup and therefore the
> initialization of the
> >generator is started from the sub sitemap and the sub
> sitemap of course
> >runs in the context of the location of the sub sitemap.
> >
> >Now, we could solve this by "surrounding" the initialization
> phase of a
> >component with a change of the current context. So, all init
> methods of
> >a component run in the context of the sitemap where the component is
> >defined. All other methods run in the context of the sitemap
> where the
> >component is used.
> >
> >WDYT?
> >
> >
>
> Sounds to be the solution that is expected by the user.
>
Yes, the problem imho is that it "sounds" this way. Although this
bug is in Cocoon since years, noone complained about it until
recently - so either noone needed it until now or the current
way (the "bug") is the way user expect it :)
Carsten
Re: Bug? Foreign SourceResolver in Generator.configure()
Posted by Reinhard Poetz <re...@apache.org>.
Carsten Ziegeler wrote:
>Thanks Vadim for the test case.
>
>Ok, we have a minor problem here :)
>
>The contract of the SourceResolver is that it always resolves relative
>to the *current sitemap*. The interesting question now is: what is
>the "current sitemap" for a component that is instantiated? Is
>it the sitemap the component is declared in or the sitemap of the
>current request?
>Now, I tend to the first option. If this is the case we have a bug :(
>
>To be precise I think we have this behaviour in Cocoon since 2.1.0.
>I just tested 2.1.5 and the problem exists there as well.
>
>The problem is that the lookup and therefore the initialization of
>the generator is started from the sub sitemap and the sub sitemap
>of course runs in the context of the location of the sub sitemap.
>
>Now, we could solve this by "surrounding" the initialization phase
>of a component with a change of the current context. So, all init
>methods of a component run in the context of the sitemap where the
>component is defined. All other methods run in the context
>of the sitemap where the component is used.
>
>WDYT?
>
>
Sounds to be the solution that is expected by the user.
--
Reinhard
RE: Bug? Foreign SourceResolver in Generator.configure()
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Thanks Vadim for the test case.
Ok, we have a minor problem here :)
The contract of the SourceResolver is that it always resolves relative
to the *current sitemap*. The interesting question now is: what is
the "current sitemap" for a component that is instantiated? Is
it the sitemap the component is declared in or the sitemap of the
current request?
Now, I tend to the first option. If this is the case we have a bug :(
To be precise I think we have this behaviour in Cocoon since 2.1.0.
I just tested 2.1.5 and the problem exists there as well.
The problem is that the lookup and therefore the initialization of
the generator is started from the sub sitemap and the sub sitemap
of course runs in the context of the location of the sub sitemap.
Now, we could solve this by "surrounding" the initialization phase
of a component with a change of the current context. So, all init
methods of a component run in the context of the sitemap where the
component is defined. All other methods run in the context
of the sitemap where the component is used.
WDYT?
Carsten
> -----Original Message-----
> From: Vadim Gritsenko [mailto:vadim@reverycodes.com]
> Sent: Tuesday, June 08, 2004 9:07 PM
> To: dev@cocoon.apache.org
> Subject: Re: Bug? Foreign SourceResolver in Generator.configure()
>
> Vadim Gritsenko wrote:
>
> > Carsten Ziegeler wrote:
> >
> >> Vadim Gritsenko wrote:
> >>
> >>> Hey,
> >>>
> >>> Noticed yesterday while using HTMLGenerator:
> SourceResolver used in
> >>> configure() method, obtained via
> >>>
> this.manager.lookup(org.apache.excalibur.source.SourceResolver.ROLE)
> >>> , appears to be not of the sitemap where generator was
> declared, but
> >>> of the sitemap where generator is used. Bug?
> >>>
> >>
> >> I would be happy if we could call this a feature :) But I
> think this
> >> is a bug :(
> >>
> >> Do we already have a sample where this bug can be seen?
> >
>
> Rebuild cocoon, go to root sitemap, change
>
> <map:generator name="html" logger="sitemap.generator.html"
> src="org.apache.cocoon.generation.HTMLGenerator"
> label="content">
> <!-- Tidy configuration file.
> <jtidy-config>context://WEB-INF/tidy.properties</jtidy-config>
> -->
> </map:generator>
>
> to
>
> <map:generator name="html" logger="sitemap.generator.html"
> src="org.apache.cocoon.generation.HTMLGenerator"
> label="content">
> <jtidy-config>WEB-INF/tidy.properties</jtidy-config>
> </map:generator>
>
> you'll get:
> java.io.FileNotFoundException:
>
> C:\apache\cocoon-2.1\build\webapp\samples\blocks\html\WEB-INF\
> tidy.properties
> (The system cannot find the path specified)
>
>
> Note that file was resolved relative to sub-sub-sitemap, not
> root sitemap.
>
> Vadim
>
>
Re: Bug? Foreign SourceResolver in Generator.configure()
Posted by Vadim Gritsenko <va...@reverycodes.com>.
Vadim Gritsenko wrote:
> Carsten Ziegeler wrote:
>
>> Vadim Gritsenko wrote:
>>
>>> Hey,
>>>
>>> Noticed yesterday while using HTMLGenerator: SourceResolver used in
>>> configure() method, obtained via
>>> this.manager.lookup(org.apache.excalibur.source.SourceResolver.ROLE),
>>> appears to be not of the sitemap where generator was declared, but
>>> of the sitemap where generator is used. Bug?
>>>
>>
>> I would be happy if we could call this a feature :)
>> But I think this is a bug :(
>>
>> Do we already have a sample where this bug can be seen?
>
Rebuild cocoon, go to root sitemap, change
<map:generator name="html" logger="sitemap.generator.html"
src="org.apache.cocoon.generation.HTMLGenerator"
label="content">
<!-- Tidy configuration file.
<jtidy-config>context://WEB-INF/tidy.properties</jtidy-config>
-->
</map:generator>
to
<map:generator name="html" logger="sitemap.generator.html"
src="org.apache.cocoon.generation.HTMLGenerator"
label="content">
<jtidy-config>WEB-INF/tidy.properties</jtidy-config>
</map:generator>
you'll get:
java.io.FileNotFoundException:
C:\apache\cocoon-2.1\build\webapp\samples\blocks\html\WEB-INF\tidy.properties
(The system cannot find the path specified)
Note that file was resolved relative to sub-sub-sitemap, not root sitemap.
Vadim
Re: Bug? Foreign SourceResolver in Generator.configure()
Posted by Vadim Gritsenko <va...@reverycodes.com>.
Carsten Ziegeler wrote:
>Vadim Gritsenko wrote:
>
>
>>Hey,
>>
>>Noticed yesterday while using HTMLGenerator: SourceResolver used in
>>configure() method, obtained via
>>this.manager.lookup(org.apache.excalibur.source.SourceResolver.ROLE),
>>appears to be not of the sitemap where generator was
>>declared, but of the sitemap where generator is used. Bug?
>>
>>
>>
>I would be happy if we could call this a feature :)
>But I think this is a bug :(
>
>Do we already have a sample where this bug can be seen?
>
>
I'll come up with sample, today.
Vadim
RE: Bug? Foreign SourceResolver in Generator.configure()
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Vadim Gritsenko wrote:
>
> Hey,
>
> Noticed yesterday while using HTMLGenerator: SourceResolver used in
> configure() method, obtained via
> this.manager.lookup(org.apache.excalibur.source.SourceResolver.ROLE),
> appears to be not of the sitemap where generator was
> declared, but of the sitemap where generator is used. Bug?
>
I would be happy if we could call this a feature :)
But I think this is a bug :(
Do we already have a sample where this bug can be seen?
Carsten