You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@forrest.apache.org by Jeff Turner <je...@apache.org> on 2003/09/01 14:41:36 UTC
Outstanding issues for 0.5? (Re: Forrest 0.5?)
On Sat, Aug 30, 2003 at 04:50:22PM -0700, Ted Leung wrote:
> Hi guys,
>
> Is there a plan to do a Coccon 2.1 compatible Forrest 0.5 in the next
> few weeks?
How about scheduling a release for Thursday? Hopefully Cocoon will have
released 2.1.1 by then.
What needs doing before we make another release?
Anyone feel up to debugging ihtml brokenness? :)
--Jeff
> Ted
>
Re: Outstanding issues for 0.5? (Re: Forrest 0.5?)
Posted by Juan Jose Pablos <ch...@che-che.com>.
Jeff,
I have got a minor bugs that I would like to check in ( sorry I have
been on holidays with limited email support).
I am going to revise all the bugs in JIRA If there is any bug that needs
to be for 0.5 I will change it.
Cheers,
Cheche
Jeff Turner wrote:
> On Sat, Aug 30, 2003 at 04:50:22PM -0700, Ted Leung wrote:
>
>>Hi guys,
>>
>>Is there a plan to do a Coccon 2.1 compatible Forrest 0.5 in the next
>>few weeks?
>
>
> How about scheduling a release for Thursday? Hopefully Cocoon will have
> released 2.1.1 by then.
>
> What needs doing before we make another release?
>
> Anyone feel up to debugging ihtml brokenness? :)
>
>
> --Jeff
>
>
>>Ted
>>
CLI: Handling links to directories (Re: broken build when href=directory)
Posted by Jeff Turner <je...@apache.org>.
(moving to dev@cocoon)
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
>
>
Re: broken build when href=directory (Was: IHTML sample bug)
Posted by Upayavira <uv...@upaya.co.uk>.
Jeff Turner wrote:
>On Thu, Sep 04, 2003 at 01:37:21PM +0200, Juan Jose Pablos wrote:
>
>
>>Upayavira wrote:
>>
>>
>>>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.
>>>
>>>
>>The behaviour has changed over the last few weeks, last time it change
>>was when you guys fixed HTMLGenerator.
>>
>>
>
>Are you sure? I experience the problem with the version of Cocoon
>currently in Forrest. I think it existed with the old CLI too. We
>filtered out **/ links in filterlinks.xsl, and now do the same in
>cli.xconf.
>
>
Ah, I'm (a little) relieved. I could not see any recent changes that
could have caused this.
Now off to continue on cocoon-dev.
Upayavira
Re: broken build when href=directory (Was: IHTML sample bug)
Posted by Juan Jose Pablos <ch...@che-che.com>.
Jeff,
>>The behaviour has changed over the last few weeks, last time it change
>>was when you guys fixed HTMLGenerator.
>
>
> Are you sure? I experience the problem with the version of Cocoon
> currently in Forrest. I think it existed with the old CLI too. We
> filtered out **/ links in filterlinks.xsl, and now do the same in
> cli.xconf.
With 20030831 I did not get that error, yesterday I upgraded and I got
that "file not found error".
Cheers,
Cheche
Re: broken build when href=directory (Was: IHTML sample bug)
Posted by Jeff Turner <je...@apache.org>.
On Thu, Sep 04, 2003 at 01:37:21PM +0200, Juan Jose Pablos wrote:
> Upayavira wrote:
> >
> >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.
>
> The behaviour has changed over the last few weeks, last time it change
> was when you guys fixed HTMLGenerator.
Are you sure? I experience the problem with the version of Cocoon
currently in Forrest. I think it existed with the old CLI too. We
filtered out **/ links in filterlinks.xsl, and now do the same in
cli.xconf.
--Jeff
> I happy with any behaviour as long as there is a consensus.
>
> >
> >Hope this is relevant.
> >
> >Upayavira
> >
>
> It is!
>
> Cheers,
> Cheche
>
Re: broken build when href=directory (Was: IHTML sample bug)
Posted by Juan Jose Pablos <ch...@che-che.com>.
Upayavira wrote:
>
> 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.
The behaviour has changed over the last few weeks, last time it change
was when you guys fixed HTMLGenerator.
I happy with any behaviour as long as there is a consensus.
>
> Hope this is relevant.
>
> Upayavira
>
It is!
Cheers,
Cheche
CLI: Handling links to directories (Re: broken build when href=directory)
Posted by Jeff Turner <je...@apache.org>.
(moving to dev@cocoon)
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
>
>
Re: broken build when href=directory (Was: IHTML sample bug)
Posted by Upayavira <uv...@upaya.co.uk>.
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.
Hope this is relevant.
Upayavira
Re: broken build when href=directory (Was: IHTML sample bug)
Posted by Jeff Turner <je...@apache.org>.
On Thu, Sep 04, 2003 at 12:51:22PM +0100, Upayavira wrote:
> Jeff Turner wrote:
> >On Thu, Sep 04, 2003 at 01:22:54PM +0200, 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?
> >
> >IMHO it's not up to Forrest. We just emit the link as-is.
> >
> Yes. If a user puts a URL into a page ending in a slash, that stays as
> is. But with just a slash, how do you deal with crawling? You can get
> the content from blah/, but what filename do you use to save that
> content? The behaviour I'm referring to changes the filename to
> blah/index.html when saving it. But it doesn't do any rewriting of the
> filenames or anything like that.
Oh I see. I hadn't thought of link rewriting and link following as
separate operations.
> >I've added an <exclude pattern="**/"/> to the default cli.xconf to fix
> >the problem in Forrest.
> >
> >
> That's unfortunate really as it could confuse some people as to why huge
> sections of their site are excluded.
True, although its always been like this in Forrest and AFAIR no-one has
complained. Thanks for the info!
--Jeff
> (But until bug is fixed, unfortunately necessary).
>
> Regards, Upayavira
>
Re: broken build when href=directory (Was: IHTML sample bug)
Posted by Upayavira <uv...@upaya.co.uk>.
Jeff Turner wrote:
>On Thu, Sep 04, 2003 at 01:22:54PM +0200, 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?
>>
>>
>
>IMHO it's not up to Forrest. We just emit the link as-is.
>
Yes. If a user puts a URL into a page ending in a slash, that stays as
is. But with just a slash, how do you deal with crawling? You can get
the content from blah/, but what filename do you use to save that
content? The behaviour I'm referring to changes the filename to
blah/index.html when saving it. But it doesn't do any rewriting of the
filenames or anything like that.
>I've added an <exclude pattern="**/"/> to the default cli.xconf to fix
>the problem in Forrest.
>
>
That's unfortunate really as it could confuse some people as to why huge
sections of their site are excluded.
(But until bug is fixed, unfortunately necessary).
Regards, Upayavira
Re: broken build when href=directory (Was: IHTML sample bug)
Posted by Jeff Turner <je...@apache.org>.
On Thu, Sep 04, 2003 at 01:22:54PM +0200, 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?
IMHO it's not up to Forrest. We just emit the link as-is.
I've added an <exclude pattern="**/"/> to the default cli.xconf to fix
the problem in Forrest.
--Jeff
> Cheers,
> Cheche
>
Re: broken build when href=directory (Was: IHTML sample bug)
Posted by Juan Jose Pablos <ch...@che-che.com>.
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
broken build when href=directory (Was: IHTML sample bug)
Posted by David Crossley <cr...@indexgeo.com.au>.
Juan Jose Pablos wrote:
> Upayavira wrote:
> >
> > Does the ihtml sample use the HTMLGenerator?
> >
> > Carsten has just fixed a CLI bug in the HTMLGenerator that prevented it
> > working without an HTTPEnvironment present. So if someone is able to
> > upgrade to CVS Cocoon and retest the IHTML sample, it might well work.
>
> I upgrade cocoon on my system, and that seems to fix this issue.
Great, but i think that this second thing is a different issue.
Hence i changed the Subject line.
> But It
> change another behaviour, it expect an index.xml when you define:
>
> <samples label="Samples" href="samples/" tab="samples">
>
> X [0] samples/index.html BROKEN:
> /var/tmp/fs/build/tmp/context/content/xdocs/samples/index.xml (No such
> file or directory)
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
It built fine and generated an index.html in the correct place
using the relevant index.xml source.
Recently that changed and i had to use explicit index.html hrefs.
--David
Re: IHTML sample bug (was Re: Outstanding issues for 0.5? (Re: Forrest
Posted by Juan Jose Pablos <ch...@che-che.com>.
Upayavira,
Upayavira wrote:
>
> Win one, loose one :-(
>
> Have you been able to work out where this error is coming from? Is the
> file actually there?
The file is not actually there, and it was not there before.
I remeber than a couple of months ago it used to be like that, I can fix
this adding a dummy index.xml file but, is this behaviour normal?
I tried to modify the welcome file value, but that does not do much.
Cheers,
Cheche
Re: IHTML sample bug (was Re: Outstanding issues for 0.5? (Re: Forrest
Posted by Upayavira <uv...@upaya.co.uk>.
Juan Jose Pablos wrote:
> Upayavira ,
>
> Upayavira wrote:
>
>>
>> Does the ihtml sample use the HTMLGenerator?
>>
>> Carsten has just fixed a CLI bug in the HTMLGenerator that prevented
>> it working without an HTTPEnvironment present. So if someone is able
>> to upgrade to CVS Cocoon and retest the IHTML sample, it might well
>> work.
>
>
> I upgrade cocoon on my system, and that seems to fix this issue. But
> It change another behaviour, it expect an index.xml when you define:
>
> <samples label="Samples" href="samples/" tab="samples">
>
> X [0] samples/index.html BROKEN:
> /var/tmp/fs/build/tmp/context/content/xdocs/samples/index.xml (No such
> file or directory)
Win one, loose one :-(
Have you been able to work out where this error is coming from? Is the
file actually there?
Upayavira
Re: IHTML sample bug (was Re: Outstanding issues for 0.5? (Re: Forrest
0.5?)
Posted by Juan Jose Pablos <ch...@che-che.com>.
Upayavira ,
Upayavira wrote:
>
> Does the ihtml sample use the HTMLGenerator?
>
> Carsten has just fixed a CLI bug in the HTMLGenerator that prevented it
> working without an HTTPEnvironment present. So if someone is able to
> upgrade to CVS Cocoon and retest the IHTML sample, it might well work.
I upgrade cocoon on my system, and that seems to fix this issue. But It
change another behaviour, it expect an index.xml when you define:
<samples label="Samples" href="samples/" tab="samples">
X [0] samples/index.html BROKEN:
/var/tmp/fs/build/tmp/context/content/xdocs/samples/index.xml (No such
file or directory)
>
> This fix'll automatically be included in the 2.1.1 Cocoon release which
> will probably be done on Friday.
>
Cool, After friday we can focus for 2 weeks on upgrade from 0.4 and
fixing issues.
Cheers,
cheche
IHTML sample bug (was Re: Outstanding issues for 0.5? (Re: Forrest
0.5?)
Posted by Upayavira <uv...@upaya.co.uk>.
Juan Jose Pablos wrote:
> Upayavira,
>
> Upayavira wrote:
>
>>
>> Can anyone explain to me exactly what the problem is with ihtml? And
>> possibly give me a sample page that doesn't work?
>
>
>
> From the lastest version of forrest
>
> mkdir /var/tmp/fs; cd /var/tmp/fs
> forrest seed; forrest
>
> There is a sample page on:
> /var/tmp/fs/src/documentation/content/xdocs/samples/ihtml-sample.ihtml
Does the ihtml sample use the HTMLGenerator?
Carsten has just fixed a CLI bug in the HTMLGenerator that prevented it
working without an HTTPEnvironment present. So if someone is able to
upgrade to CVS Cocoon and retest the IHTML sample, it might well work.
This fix'll automatically be included in the 2.1.1 Cocoon release which
will probably be done on Friday.
Regards,
Upayavira
Re: Outstanding issues for 0.5? (Re: Forrest 0.5?)
Posted by Juan Jose Pablos <ch...@che-che.com>.
Upayavira,
Upayavira wrote:
>
> Can anyone explain to me exactly what the problem is with ihtml? And
> possibly give me a sample page that doesn't work?
From the lastest version of forrest
mkdir /var/tmp/fs; cd /var/tmp/fs
forrest seed; forrest
There is a sample page on:
/var/tmp/fs/src/documentation/content/xdocs/samples/ihtml-sample.ihtml
Cheers,
Cheche
Re: Outstanding issues for 0.5? (Re: Forrest 0.5?)
Posted by Upayavira <uv...@upaya.co.uk>.
Nicola Ken Barozzi wrote:
>
> Jeff Turner wrote, On 01/09/2003 14.41:
> ...
>
>> Anyone feel up to debugging ihtml brokenness? :)
>
>
> I just checked again and ihtml does work in the webapp and not in the
> CLI.
>
> I think this is a CLI bug, and currently I have no time to put my
> hands on Cocoon again, so it will have to slip by unless others take
> the chore.
Can anyone explain to me exactly what the problem is with ihtml? And
possibly give me a sample page that doesn't work?
Regards, Upayavira
Re: Outstanding issues for 0.5? (Re: Forrest 0.5?)
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Jeff Turner wrote, On 01/09/2003 14.41:
...
> Anyone feel up to debugging ihtml brokenness? :)
I just checked again and ihtml does work in the webapp and not in the CLI.
I think this is a CLI bug, and currently I have no time to put my hands
on Cocoon again, so it will have to slip by unless others take the chore.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------