cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Unico Hommes <un...@hippo.nl>
Subject Re: DO NOT REPLY [Bug 27432] New: - Malformed HTTP headers (debug information in Parameters object)
Date Thu, 04 Mar 2004 19:13:06 GMT


Sylvain Wallez wrote:

> Carsten Ziegeler wrote:
> 
>> Bertrand Delacretaz wrote:
>>  
>>
>>> Le Jeudi, 4 mars 2004, à 14:37 Europe/Zurich, Carsten Ziegeler a écrit :
>>>
>>>   
>>>
>>>> ...I think, we should disable this feature for now and find     
>>>
>>> a better   
>>>
>>>> and compatible way....
>>>>     
>>>
>>> Wouldn't just changing the header name from 
>>> org.apache.cocoon.sitemap/Location to something like 
>>> X-Cocoon-debug-sitemap-location fix the problem?
>>>
>>>   
>>
>> Perhaps in this special case, I don't know, perhaps Lars can answer this.
>>
>>  
>>
>>> Using a known prefix like "X-Cocoon-debug-" also makes it easy to 
>>> filter out these headers when needed.
>>>   
> 
> 
> This information is absolutely not meant to be sent back to the browser!
> 
>> But then you have to change every component that currently iterates 
>> over the parameters and every component has to filter.
>> We actually really introduced an incompatible feature and to be 
>> honest, I don't even know where it is used and if it's useful at all.
>>  
>>
> 
> I'm the one who introduced this feature: it allows every sitemap 
> component to know the location from where it is invoked, which allows 
> more meaningful messages to be produced by these components. You can 
> find some example usage of this in e.g. AbstractWildcardMatcher and 
> AbstractProcessingPipeline.
> 
> The parameters object is the only one that is related to a particular 
> usage of a component in a sitemap statement, and therefore the only 
> place where this information can be stored.
> 
> Now I understand the problem Lars encountered, and I'm sorry to have 
> missed that when I implemented that feature (I don't use these 
> parameter-iterating actions).
> 
> So how do we solve this? I do want to keep this information which is an 
> important means to provide more help to the developper in case of problem.
> 
> So here's a proposal (I should have thought about it way earlier...): 
> let's use a "LocatedParameters", subclass of "Parameters" with an 
> additional "getLocation()" method. It has no impact on components that 
> iterate on parameters, and yet still provide location whenever it's needed.
> 

Does it make sense to narrow the location down even more by passing the 
parameter name with that method?

location = parameters.getLocation(name);

I am surprised this isn't part of the Parameters interface already.

Unico

Mime
View raw message