cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <sylv...@apache.org>
Subject Re: DO NOT REPLY [Bug 27432] New: - Malformed HTTP headers (debug information in Parameters object)
Date Thu, 04 Mar 2004 18:02:58 GMT
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.

WDYT?

Sylvain

-- 
Sylvain Wallez                                  Anyware Technologies
http://www.apache.org/~sylvain           http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }


Mime
View raw message