(moving to [EMAIL PROTECTED])

On Thu, Sep 04, 2003 at 12:24:48PM +0100, Upayavira wrote:
> Juan Jose Pablos wrote:
> 
> >David Crossley wrote:
> >
> >>
> >>Yes i noticed this recent change too. One of our projects had
> >>site.xml entries like Juan shows above, ending in a directory slash
> >>with no explicit reference to index.html
> >>
> >
> >So is this the expect behaviour?, when there is a ending slash a 
> >welcome.file "index.html" would be used?
> >
> >Cheers,
> >Cheche
> 
> Don't entirely understand what you guys are discussing, but the CLI 
> should, if it comes across a link ending in a slash, it should append 
> 'index.html' to that. You can change the filename that is appended using 
> the <default-filename/> node in the cli.xconf, but I believe it will 
> default to 'index.html' if one is not specified (the actual default 
> value comes from an entry in org.apache.cocoon.Constants).
> 
> This behaviour should not have changed at all since the xconf format was 
> first created.

Possibly it does append index.html, but it still breaks:

java.lang.NullPointerException
        at 
org.apache.cocoon.environment.AbstractEnvironment.release(AbstractEnvironment.java:521)
        at 
org.apache.cocoon.environment.wrapper.MutableEnvironmentFacade.release(MutableEnvironmentFacade.java:332)
        at org.apache.cocoon.generation.FileGenerator.recycle(FileGenerator.java:90)
        at 
org.apache.avalon.excalibur.pool.ResourceLimitingPool.put(ResourceLimitingPool.java:438)
        at 
org.apache.avalon.excalibur.component.PoolableComponentHandler.doPut(PoolableComponentHandler.java:245)
        at 
org.apache.avalon.excalibur.component.ComponentHandler.put(ComponentHandler.java:452)
        at 
org.apache.avalon.excalibur.component.ExcaliburComponentSelector.release(ExcaliburComponentSelector.java:336)
        at 
org.apache.cocoon.components.ExtendedComponentSelector.release(ExtendedComponentSelector.java:326)
        at 
org.apache.cocoon.components.ExtendedComponentSelector.release(ExtendedComponentSelector.java:323)
        at 
org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.recycle(AbstractProcessingPipeline.java:641)
        at 
org.apache.cocoon.components.pipeline.impl.BaseCachingProcessingPipeline.recycle(BaseCachingProcessingPipeline.java:112)
        at 
org.apache.cocoon.components.pipeline.impl.AbstractCachingProcessingPipeline.recycle(AbstractCachingProcessingPipeline.java:961)
        at 
org.apache.avalon.excalibur.pool.ResourceLimitingPool.put(ResourceLimitingPool.java:438)
        at 
org.apache.avalon.excalibur.component.PoolableComponentHandler.doPut(PoolableComponentHandler.java:245)
        at 
org.apache.avalon.excalibur.component.ComponentHandler.put(ComponentHandler.java:452)
        at 
org.apache.avalon.excalibur.component.ExcaliburComponentSelector.release(ExcaliburComponentSelector.java:336)
        at 
org.apache.cocoon.components.ExtendedComponentSelector.release(ExtendedComponentSelector.java:326)
        at 
org.apache.cocoon.components.EnvironmentDescription.release(CocoonComponentManager.java:602)
        at 
org.apache.cocoon.components.CocoonComponentManager.endProcessing(CocoonComponentManager.java:212)
        at org.apache.cocoon.Cocoon.process(Cocoon.java:659)
        at org.apache.cocoon.bean.CocoonWrapper.getPage(CocoonWrapper.java:551)
        at org.apache.cocoon.bean.CocoonBean.processTarget(CocoonBean.java:477)
        at org.apache.cocoon.bean.CocoonBean.process(CocoonBean.java:294)
        at org.apache.cocoon.Main.main(Main.java:392)
....
....
* [0] community/
* [49] forrestbot-intro.html

That is with a <link href="community/"> in index.html.  There is a
community/index.xml file.

Whether to append anything to directory links is debatable.  It feels
very similar to the question of whether to munge page extensions.
Perhaps we could solve the problem in the same way, by declaring that
links of the form '**/' have a MIME type 'text/directory' [1], and then
having an entry in mime.types to specify a default filename, if any:

text/directory  index.html

Or perhaps a <mime-types> section in cli.xconf?

Anyway, just random thoughts.  The problem is very easy to work around
now we have wildcard exclusions, with <exclude pattern="**/"/>


--Jeff

[1] http://www.faqs.org/rfcs/rfc2425.html

> Hope this is relevant.
> 
> Upayavira
> 
> 

Reply via email to