You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Carsten Ziegeler <cz...@s-und-n.de> on 2003/03/11 08:53:59 UTC
Finishing Deprecation Package
As I will not do it this week, here is a list of
things that have to be done to get the deprecation
package working. If someone wants to do it, I will
be very happy - otherwise I will perhaps do it
next week.
The XScriptObject must be changed to inherit from the
excalibur source instead of the cocoon source. It might
be, that a logicsheet needs to be adapted as well.
The Source interface from Cocoon and the
CocoonToAvalonSource class have to be moved from the
deprecated package into the core package.
org.apache.cocoon.components.resolver.ResolverImpl has
to be changed to use the new Resolver from the excalibur
xmlutil package.
Carsten
Carsten Ziegeler
Open Source Group, S&N AG
RE: Finishing Deprecation Package
Posted by David Crossley <cr...@indexgeo.com.au>.
Carsten Ziegeler wrote:
> David Crossley wrote:
> > Carsten Ziegeler wrote:
> > >
<snip/>
> > >
> > > org.apache.cocoon.components.resolver.ResolverImpl has
> > > to be changed to use the new Resolver from the excalibur
> > > xmlutil package.
> >
> > Whoa, not so fast Carsten. I see that you have suddenly
> > ripped out the comprehensive ResolverImpl.java and
> > replaced it with a basic DefaultResolver.java ... Why?
> > What is the reason for these drastic changes and why
> > was there no discussion?
>
> It's not a drastic change.
Okay i should not have used the word "drastic". It appeared
so to me because there was no indication of what had happened.
> > This class was not marked as deprecated. Nicola Ken had
> > already cleverly moved the deprecated Resolver.java into
> > src/deprecated/
>
> Yes, but ResolverImpl depends on Resolver, so you have a
> dependency from the core to the deprecated package and
> this has to be avoided.
>
> > We have also lost the ability to configure the entity
> > resolver via cocoon.xconf which was one purpose of
> > the ResolverImpl.java
>
> This is not true (unless it's a bug).
Sorry, i was wrong and was seriously confused. Yes we can
still do things like raise the verbosity level via cocoon.xconf
It cannot be properly tested until the samples/misc/ is working
again.
I think that my main problem is that i was already distressed
by three weeks of total loss of productivity with Cocoon
development due to recent repository and build upheaval.
Now the component that i was working on has been broken
and i had no handle on how to start to fix it.
> In fact, if you compare
> the code, the new DefaultResolver is absolutely the same as
> the old ResolverImpl, so it should still be configurable and
> working as the old one.
Aha. After a few more wasted hours of wandering around the code
i see that you have moved the whole thing over to Excalibur
as DefaultEntityResolver. Now it makes sense. If only you had
given a useful cvs log message or a short email or changes.xml
> If anything is not working the way it should, it's simply a
> bug which has to be fixed.
Okay ... there is a massive bug somewhere that has to be fixed.
--David
Re: more xmlforms + schematron, why ?
Posted by ivelin <iv...@apache.org>.
Schematron is just one of the implementations of the Validator interface.
You can choose to not use any external Validator in which case the Action
might do the validation and use Form.addViolation().
-=Ivelin=-
----- Original Message -----
From: "Jeremy Quinn" <je...@media.demon.co.uk>
To: <co...@xml.apache.org>
Sent: Thursday, March 13, 2003 11:34 AM
Subject: Re: more xmlforms + schematron, why ?
>
> On Thursday, March 13, 2003, at 04:50 PM, Torsten Curdt wrote:
>
> >
> >> and if anyone does have a simple idea of how to do a simple check
> >> with schematron for alpha or non alpha strings ( 'test' is good,
> >> 'test1' or 'test#' is bad ) I'd be very gratefull for that too :)
> >
> > Sorry, I personally dislike schematron and don't use it - so I don't
> > have anything at hand :) But you might wanna have a look into the
> > "translate" function
> >
>
> Is Schematron the only Schema language you can use with XMLForms?
>
> regards Jeremy
Re: more xmlforms + schematron, why ?
Posted by Jeremy Quinn <je...@media.demon.co.uk>.
On Thursday, March 13, 2003, at 04:50 PM, Torsten Curdt wrote:
>
>> and if anyone does have a simple idea of how to do a simple check
>> with schematron for alpha or non alpha strings ( 'test' is good,
>> 'test1' or 'test#' is bad ) I'd be very gratefull for that too :)
>
> Sorry, I personally dislike schematron and don't use it - so I don't
> have anything at hand :) But you might wanna have a look into the
> "translate" function
>
Is Schematron the only Schema language you can use with XMLForms?
regards Jeremy
Re: more xmlforms + schematron, why ?
Posted by Jeremy Quinn <je...@media.demon.co.uk>.
On Thursday, March 13, 2003, at 04:50 PM, Torsten Curdt wrote:
>
>> and if anyone does have a simple idea of how to do a simple check
>> with schematron for alpha or non alpha strings ( 'test' is good,
>> 'test1' or 'test#' is bad ) I'd be very gratefull for that too :)
>
> Sorry, I personally dislike schematron and don't use it - so I don't
> have anything at hand :) But you might wanna have a look into the
> "translate" function
>
Is Schematron the only Schema language you can use with XMLForms?
regards Jeremy
Re: more xmlforms + schematron, why ?
Posted by Torsten Curdt <tc...@dff.st>.
> Looking at xmlforms and schematron more closely, I'm starting to
> wonder why this combination was chosen anyways? from the examples
> it seems the purpose of schematrons is to validate input fields, but checking
> something simple as if a field is only alpha characters seems to be near
> impossible or atleast really hard with schematron (or am I missing something
> here ? )
There have been heavy discussions. You might find some in the archives.
> Isn't schematron intended for checking document structure, not validity of
> single fields/elements ?
Well, you can use it for both. But you have to use XSLT functions for
content validity. See the XSLT pages/mailing list for help on the
functions.
> and if anyone does have a simple idea of how to do a simple check with
> schematron for alpha or non alpha strings ( 'test' is good, 'test1' or
> 'test#' is bad ) I'd be very gratefull for that too :)
Sorry, I personally dislike schematron and don't use it - so I don't
have anything at hand :) But you might wanna have a look into the
"translate" function
--
Torsten
Re: more xmlforms + schematron, why ?
Posted by Christopher Oliver <re...@verizon.net>.
It may not help you at the moment because its still under development,
but with the current XMLForm integration with the Cocoon flow layer, you
can also do validation in JavaScript, meaning you have regular
expressions, String operations, etc, the full power of JavaScript and
Java, if you need it.
Thanks to somebody (not sure who), the XMLForm samples now seem to be
working, so you can now play with the XMLForm FeedBack Wizard driven by
the flow layer:
http://localhost:8888/samples/xmlform/overview.html
Regards,
Chris
Guido Casper wrote:
> I agree, that the lack of support for regular expressions is the biggest
> obstacle to schematron use.
>
> I wonder if anybody is already working on a second validator for XMLForm
> with support for regular expressions.
>
> Guido
>
> ----- Original Message -----
> From: "Jeroen Cranendonk" <j....@emaxx.nl>
> To: <co...@xml.apache.org>
> Sent: Thursday, March 13, 2003 4:50 PM
> Subject: more xmlforms + schematron, why ?
>
>
>
>>Looking at xmlforms and schematron more closely, I'm starting to
>>wonder why this combination was chosen anyways? from the examples
>>it seems the purpose of schematrons is to validate input fields, but
>
> checking
>
>>something simple as if a field is only alpha characters seems to be near
>>impossible or atleast really hard with schematron (or am I missing
>
> something
>
>>here ? )
>>Isn't schematron intended for checking document structure, not validity of
>>single fields/elements ?
>>
>>Could someone eleborate on this ? please ? :)
>>and if anyone does have a simple idea of how to do a simple check with
>>schematron for alpha or non alpha strings ( 'test' is good, 'test1' or
>>'test#' is bad ) I'd be very gratefull for that too :)
>>
>>Many thanks in advance,
>>Jeroen Cranendonk
>
>
>
Re: more xmlforms + schematron, why ?
Posted by Guido Casper <gc...@s-und-n.de>.
I agree, that the lack of support for regular expressions is the biggest
obstacle to schematron use.
I wonder if anybody is already working on a second validator for XMLForm
with support for regular expressions.
Guido
----- Original Message -----
From: "Jeroen Cranendonk" <j....@emaxx.nl>
To: <co...@xml.apache.org>
Sent: Thursday, March 13, 2003 4:50 PM
Subject: more xmlforms + schematron, why ?
> Looking at xmlforms and schematron more closely, I'm starting to
> wonder why this combination was chosen anyways? from the examples
> it seems the purpose of schematrons is to validate input fields, but
checking
> something simple as if a field is only alpha characters seems to be near
> impossible or atleast really hard with schematron (or am I missing
something
> here ? )
> Isn't schematron intended for checking document structure, not validity of
> single fields/elements ?
>
> Could someone eleborate on this ? please ? :)
> and if anyone does have a simple idea of how to do a simple check with
> schematron for alpha or non alpha strings ( 'test' is good, 'test1' or
> 'test#' is bad ) I'd be very gratefull for that too :)
>
> Many thanks in advance,
> Jeroen Cranendonk
more xmlforms + schematron, why ?
Posted by Jeroen Cranendonk <j....@emaxx.nl>.
Looking at xmlforms and schematron more closely, I'm starting to
wonder why this combination was chosen anyways? from the examples
it seems the purpose of schematrons is to validate input fields, but checking
something simple as if a field is only alpha characters seems to be near
impossible or atleast really hard with schematron (or am I missing something
here ? )
Isn't schematron intended for checking document structure, not validity of
single fields/elements ?
Could someone eleborate on this ? please ? :)
and if anyone does have a simple idea of how to do a simple check with
schematron for alpha or non alpha strings ( 'test' is good, 'test1' or
'test#' is bad ) I'd be very gratefull for that too :)
Many thanks in advance,
Jeroen Cranendonk
RE: Finishing Deprecation Package
Posted by David Crossley <cr...@indexgeo.com.au>.
Carsten Ziegeler wrote:
> Hi David,
>
> I just fixed some bugs in the catalog resolving code; as far
> as I can tell everything is working fine. If you experience
> problems, just let me know.
Thanks, our emails crossed in mid-air :-)
I will look into it tomorrow.
--David
RE: Finishing Deprecation Package
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
I just did a fix for absolute paths on windows. All your
tests work for me on w2k.
Carsten
RE: Finishing Deprecation Package
Posted by David Crossley <cr...@indexgeo.com.au>.
David Crossley wrote:
> Carsten Ziegeler wrote:
> >
> <snip/>
> > Ok, done (I hope) - I changed the implementation and the cocoon.xconf.
> > How can we test it to ensure that it works correctly?
>
> The main way is via the samples/catalog/
> (top Samples page => Catalog Entity Resolver)
>
> Try the first sample to ensure that default config
> is okay.
>
> Then try the sdocbook demo. It shows how to configure
> a new catalog and where to get the DTD (only takes
> a few minutes to configure). I will try after dinner,
> then we need to get all other platforms to try.
Okay, this works for me on Linux. Would people on other
platforms please try it.
> We should also enhance 'build test' to include
> a test for local-catalog.
>
> --David
Re: Finishing Deprecation Package
Posted by David Crossley <cr...@indexgeo.com.au>.
Jeremy Quinn wrote:
> David Crossley wrote:
>
> > Jeremy Quinn wrote:
> > <snip/>
> >> OK
> >>
> >> This still fails:
> >>
> >> http://localhost:8888/samples/catalog/sdocbook-demo
> >>
> >> org.apache.cocoon.ProcessingException: Failed to execute pipeline.:
> >> java.io.FileNotFoundException:
> >> /Users/jermq/Checkouts/Secure/cocoon-2.1/build/webapp/samples/catalog/
> >> sdocbook.dtd (No such file or directory)
> >>
> >> While this one appears to be working:
> >>
> >> http://localhost:8888/samples/catalog/catalog-demo
> >
> > This sounds to me like you do not have your local catalog
> > properly configured for the Simplified DocBook DTD. Did you
> > follow the instructions on that page? You can raise the
> > verbosity level of the entity-resolver to 10 in cocoon.xconf
> > and watch the catalog loading messages when Jetty starts and
> > when you access the webapp sample.
>
> OK, I did these tests 'out of the box'.
>
> I'll try to get this tested today.
Bertrand Delacretaz has already reported success on Macintosh.
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=104814413820514
So only test it if you are interested.
--David
Re: Finishing Deprecation Package
Posted by Jeremy Quinn <je...@media.demon.co.uk>.
On Sunday, March 23, 2003, at 01:43 PM, David Crossley wrote:
> Jeremy Quinn wrote:
> <snip/>
>> OK
>>
>> This still fails:
>>
>> http://localhost:8888/samples/catalog/sdocbook-demo
>>
>> org.apache.cocoon.ProcessingException: Failed to execute pipeline.:
>> java.io.FileNotFoundException:
>> /Users/jermq/Checkouts/Secure/cocoon-2.1/build/webapp/samples/catalog/
>> sdocbook.dtd (No such file or directory)
>>
>> While this one appears to be working:
>>
>> http://localhost:8888/samples/catalog/catalog-demo
>
> This sounds to me like you do not have your local catalog
> properly configured for the Simplified DocBook DTD. Did you
> follow the instructions on that page? You can raise the
> verbosity level of the entity-resolver to 10 in cocoon.xconf
> and watch the catalog loading messages when Jetty starts and
> when you access the webapp sample.
OK, I did these tests 'out of the box'.
I'll try to get this tested today.
Thanks
regards Jeremy
Re: Finishing Deprecation Package
Posted by David Crossley <cr...@indexgeo.com.au>.
Jeremy Quinn wrote:
<snip/>
> OK
>
> This still fails:
>
> http://localhost:8888/samples/catalog/sdocbook-demo
>
> org.apache.cocoon.ProcessingException: Failed to execute pipeline.:
> java.io.FileNotFoundException:
> /Users/jermq/Checkouts/Secure/cocoon-2.1/build/webapp/samples/catalog/
> sdocbook.dtd (No such file or directory)
>
> While this one appears to be working:
>
> http://localhost:8888/samples/catalog/catalog-demo
This sounds to me like you do not have your local catalog
properly configured for the Simplified DocBook DTD. Did you
follow the instructions on that page? You can raise the
verbosity level of the entity-resolver to 10 in cocoon.xconf
and watch the catalog loading messages when Jetty starts and
when you access the webapp sample.
--David
Re: Finishing Deprecation Package
Posted by Jeremy Quinn <je...@media.demon.co.uk>.
On Wednesday, March 19, 2003, at 07:47 AM, Carsten Ziegeler wrote:
> Jeremy Quinn wrote:
>>> You will find a excalibur-xmlutils jar with the date of today
>>> 20030317.
>>> If you have this jar, then you're upto date.
>>
>> My fresh checkout has given me 'excalibur-xmlutil-20030313.jar' so
>> this
>> may be where the problem lies.
>>
> Strange. It seems that Eclipse 2.1RC2 has the same problems with cvs
> that
> 2.0.2 had, but 2.1RC1 not. Sigh...
>
> Ok, I recommitted the files just now.
>
> Could you please check it? Thanks.
OK
This still fails:
http://localhost:8888/samples/catalog/sdocbook-demo
org.apache.cocoon.ProcessingException: Failed to execute pipeline.:
java.io.FileNotFoundException:
/Users/jermq/Checkouts/Secure/cocoon-2.1/build/webapp/samples/catalog/
sdocbook.dtd (No such file or directory)
While this one appears to be working:
http://localhost:8888/samples/catalog/catalog-demo
regards Jeremy
RE: Finishing Deprecation Package
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Jeremy Quinn wrote:
> > You will find a excalibur-xmlutils jar with the date of today 20030317.
> > If you have this jar, then you're upto date.
>
> My fresh checkout has given me 'excalibur-xmlutil-20030313.jar' so this
> may be where the problem lies.
>
Strange. It seems that Eclipse 2.1RC2 has the same problems with cvs that
2.0.2 had, but 2.1RC1 not. Sigh...
Ok, I recommitted the files just now.
Could you please check it? Thanks.
Carsten
Re: Finishing Deprecation Package
Posted by Jeremy Quinn <je...@media.demon.co.uk>.
On Monday, March 17, 2003, at 02:56 PM, Carsten Ziegeler wrote:
>
> Jeremy Quinn wrote:
>>
>>
>> I just did a fresh update (to the version that made the log I just
>> sent
>> you), but this was all I got :
>>
>> P blocks.properties
>> P build.xml
>> P src/scratchpad/webapp/samples/imagereader/sitemap.xmap
>>
>> So either I am up to date WRT this particular code, or I have a
>> problem
>> with my local repository and need to re-checkout.
>>
> You will find a excalibur-xmlutils jar with the date of today 20030317.
> If you have this jar, then you're upto date.
My fresh checkout has given me 'excalibur-xmlutil-20030313.jar' so this
may be where the problem lies.
>
>> I will do a fresh checkout and report back .... after lunch :)
>>
> Have a nice meal!
Very nice ;)
Aubergine & artichoke focaccia, in a little Italian eatery in Brixton
called Eco. Yummy ;)
regards Jeremy
RE: Finishing Deprecation Package
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Jeremy Quinn wrote:
>
>
> I just did a fresh update (to the version that made the log I just sent
> you), but this was all I got :
>
> P blocks.properties
> P build.xml
> P src/scratchpad/webapp/samples/imagereader/sitemap.xmap
>
> So either I am up to date WRT this particular code, or I have a problem
> with my local repository and need to re-checkout.
>
You will find a excalibur-xmlutils jar with the date of today 20030317.
If you have this jar, then you're upto date.
> I will do a fresh checkout and report back .... after lunch :)
>
Have a nice meal!
Carsten
Re: Finishing Deprecation Package
Posted by Jeremy Quinn <je...@media.demon.co.uk>.
On Monday, March 17, 2003, at 02:22 PM, Carsten Ziegeler wrote:
>
> Jeremy Quinn wrote
>>> Sorry, I was a little bit unprecise. You have to set the loglevel in
>>> the
>>> logkit.xconf - change the setting for core and for manager from ERROR
>>> to DEBUG. You will find the messages in the core.log.
>>
>> OK, hope this helps ..... no hits, just the startup.
>>
> Yes, that's perfect.
Glad to be of assistance.
> As far as I can tell, it seems that you are using an "old" version of
> the excalibur xmlutil. Your version has a bug in resolving the
> catalogs.
> Could you please update to the latest cvs version of Cocoon and try
> again?
I just did a fresh update (to the version that made the log I just sent
you), but this was all I got :
P blocks.properties
P build.xml
P src/scratchpad/webapp/samples/imagereader/sitemap.xmap
So either I am up to date WRT this particular code, or I have a problem
with my local repository and need to re-checkout.
I will do a fresh checkout and report back .... after lunch :)
regards Jeremy
RE: Finishing Deprecation Package
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Jeremy Quinn wrote
> > Sorry, I was a little bit unprecise. You have to set the loglevel in
> > the
> > logkit.xconf - change the setting for core and for manager from ERROR
> > to DEBUG. You will find the messages in the core.log.
>
> OK, hope this helps ..... no hits, just the startup.
>
Yes, that's perfect.
As far as I can tell, it seems that you are using an "old" version of
the excalibur xmlutil. Your version has a bug in resolving the catalogs.
Could you please update to the latest cvs version of Cocoon and try
again? If it not works then, sending the same (updated) log would be
very helpfull.
Thanks for your help!
Carsten
Re: Finishing Deprecation Package
Posted by Jeremy Quinn <je...@media.demon.co.uk>.
On Monday, March 17, 2003, at 01:38 PM, Carsten Ziegeler wrote:
>
> Jeremy Quinn wrote:
>>
>> On Monday, March 17, 2003, at 07:33 AM, Carsten Ziegeler wrote:
>>
>>> Hi Jeremy,
>>>
>>> can you please turn on debug logging and post what the new
>>> resolver logs on startup?
>>
>> Hi Carsten,
>>
>> I made this change in web.xml :
<snip/>
> Sorry, I was a little bit unprecise. You have to set the loglevel in
> the
> logkit.xconf - change the setting for core and for manager from ERROR
> to DEBUG. You will find the messages in the core.log.
OK, hope this helps ..... no hits, just the startup.
RE: Finishing Deprecation Package
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Jeremy Quinn wrote:
>
> On Monday, March 17, 2003, at 07:33 AM, Carsten Ziegeler wrote:
>
> > Hi Jeremy,
> >
> > can you please turn on debug logging and post what the new
> > resolver logs on startup?
>
> Hi Carsten,
>
> I made this change in web.xml :
>
> <init-param>
> <param-name>log-level</param-name>
> <param-value>WARN</param-value>
> </init-param>
> to:
> <init-param>
> <param-name>log-level</param-name>
> <param-value>DEBUG</param-value>
> </init-param>
>
> then restarted Jetty.
>
> Then found that there was no mention of 'catalog' or 'entities' in the
> (very long) log, so did not want to post it as I suspected I had done
> the wrong thing ....
>
Sorry, I was a little bit unprecise. You have to set the loglevel in the
logkit.xconf - change the setting for core and for manager from ERROR
to DEBUG. You will find the messages in the core.log.
Carsten
Re: Finishing Deprecation Package
Posted by Jeremy Quinn <je...@media.demon.co.uk>.
On Monday, March 17, 2003, at 07:33 AM, Carsten Ziegeler wrote:
> Hi Jeremy,
>
> can you please turn on debug logging and post what the new
> resolver logs on startup?
Hi Carsten,
I made this change in web.xml :
<init-param>
<param-name>log-level</param-name>
<param-value>WARN</param-value>
</init-param>
to:
<init-param>
<param-name>log-level</param-name>
<param-value>DEBUG</param-value>
</init-param>
then restarted Jetty.
Then found that there was no mention of 'catalog' or 'entities' in the
(very long) log, so did not want to post it as I suspected I had done
the wrong thing ....
Suggestions?
regards Jeremy
RE: Finishing Deprecation Package
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Hi Jeremy,
can you please turn on debug logging and post what the new
resolver logs on startup?
Carsten
> -----Original Message-----
> From: Jeremy Quinn [mailto:jeremy@media.demon.co.uk]
> Sent: Friday, March 14, 2003 5:45 PM
> To: cocoon-dev@xml.apache.org
> Subject: Re: Finishing Deprecation Package
>
>
>
> On Friday, March 14, 2003, at 09:03 AM, David Crossley wrote:
>
> > The main way is via the samples/catalog/
> > (top Samples page => Catalog Entity Resolver)
> >
> > Try the first sample to ensure that default config
> > is okay.
>
> No, I get :
>
> An error occurredorg.apache.cocoon.ProcessingExceptionUnable to get
> transformer handler for style.xslorg.apache.cocoon.ProcessingException:
> Unable to get transformer handler for style.xsl:
> org.apache.excalibur.xml.xslt.XSLTProcessorException: Exception in
> creating Transform Handlerjava.io.FileNotFoundException:
> /Users/jermq/Checkouts/Secure/cocoon-2.1/build/webapp/samples/catalog/
> ISOnum.pen (No such file or directory)Original exception :
> org.apache.excalibur.xml.xslt.XSLTProcessorException: Exception in
> creating Transform Handler at
> org.apache.excalibur.xml.xslt.XSLTProcessorImpl.getTransformerHandlerAnd
> Validity(XSLTProcessorImpl.java:348) at
> org.apache.cocoon.transformation.TraxTransformer.setup(TraxTransformer.j
> ava:283) at
>
> etc.
>
> on MacOSX + current CVS + Jetty + JVM 1.4.1.
>
> regards Jeremy
>
Re: Finishing Deprecation Package
Posted by Jeremy Quinn <je...@media.demon.co.uk>.
On Friday, March 14, 2003, at 09:03 AM, David Crossley wrote:
> The main way is via the samples/catalog/
> (top Samples page => Catalog Entity Resolver)
>
> Try the first sample to ensure that default config
> is okay.
No, I get :
An error occurredorg.apache.cocoon.ProcessingExceptionUnable to get
transformer handler for style.xslorg.apache.cocoon.ProcessingException:
Unable to get transformer handler for style.xsl:
org.apache.excalibur.xml.xslt.XSLTProcessorException: Exception in
creating Transform Handlerjava.io.FileNotFoundException:
/Users/jermq/Checkouts/Secure/cocoon-2.1/build/webapp/samples/catalog/
ISOnum.pen (No such file or directory)Original exception :
org.apache.excalibur.xml.xslt.XSLTProcessorException: Exception in
creating Transform Handler at
org.apache.excalibur.xml.xslt.XSLTProcessorImpl.getTransformerHandlerAnd
Validity(XSLTProcessorImpl.java:348) at
org.apache.cocoon.transformation.TraxTransformer.setup(TraxTransformer.j
ava:283) at
etc.
on MacOSX + current CVS + Jetty + JVM 1.4.1.
regards Jeremy
RE: Finishing Deprecation Package
Posted by David Crossley <cr...@indexgeo.com.au>.
Carsten Ziegeler wrote:
>
<snip/>
> Ok, done (I hope) - I changed the implementation and the cocoon.xconf.
> How can we test it to ensure that it works correctly?
The main way is via the samples/catalog/
(top Samples page => Catalog Entity Resolver)
Try the first sample to ensure that default config
is okay.
Then try the sdocbook demo. It shows how to configure
a new catalog and where to get the DTD (only takes
a few minutes to configure). I will try after dinner,
then we need to get all other platforms to try.
We should also enhance 'build test' to include
a test for local-catalog.
--David
RE: Finishing Deprecation Package
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
David Crossley wrote:
> > Now, there is something wrong with this approach. We can easily
> > change (which should be the 'correct' solution) that a path
> > starting with "/" is treated as an absolute path. So
> > if you want to load from the context directory, you have
> > to specify "WEB-INF/.." instead of "/WEB-INF".
>
> When i was investigating these issues today, i commented the
> same to myself.
>
> > But using a starting "/" with two different behaviours is imho
> > too confusing.
> > What do you think? Changing the above is absolutely simple.
>
> I agree - let us do it. I will note this in changes.xml later,
> though it should not affect too many people as this is
> only for over-riding the default Cocoon catalog.
>
Ok, done (I hope) - I changed the implementation and the cocoon.xconf.
How can we test it to ensure that it works correctly?
If everything is working, we can update the changes and docs.
> > Or did I oversee something?
>
> Well the thing that really worries me is the hell that we
> went through last time with getting consistent behaviour
> on all platforms.
>
Yes, I understand that - but I think if we work together we will
solve this.
Thanks
Carsten
RE: Finishing Deprecation Package
Posted by David Crossley <cr...@indexgeo.com.au>.
Carsten Ziegeler wrote:
> David Crossley wrote:
> > Carsten Ziegeler wrote:
> > > I just fixed some bugs in the catalog resolving code; as far
> > > as I can tell everything is working fine. If you experience
> > > problems, just let me know.
> >
> > Most bits seem to be working again, e.g. main Cocoon documentation.
> > I also resurrected the 'catalog-demo' sample and that works.
> >
> > However other bits are still broken. The "Simplified DocBook"
> > sample is busted. The old ResolverImpl.java used to load an
> > additional catalog via the "local-catalog" parameter of
> > cocoon.xconf using a full filesystem pathname starting with "/"
> > ... now that is busted and the resolver tries to incorrectly
> > load it from .../cocoon-2.1/build/webapp/home/me/work/...
> ^^^^^
> Uh, that's not nice. The default catalog is defined by "/WEB-INF/...."
> and this is loaded from the context directory.
> Now, you say that if I define the "local-catalog" with "/..." then
> this should *not* be loaded from the context directory, but
> it should be assumed that this is an absolute path, right?
Yes. And that is how it has always worked in the past.
Remember too that the entity resolver deals with the pathname
itself, and it expects a platform-independent pathname as
described in CatalogManager.properties (i will tweak the
cocoon.xconf description to match that).
> Now, there is something wrong with this approach. We can easily
> change (which should be the 'correct' solution) that a path
> starting with "/" is treated as an absolute path. So
> if you want to load from the context directory, you have
> to specify "WEB-INF/.." instead of "/WEB-INF".
When i was investigating these issues today, i commented the
same to myself.
> But using a starting "/" with two different behaviours is imho
> too confusing.
> What do you think? Changing the above is absolutely simple.
I agree - let us do it. I will note this in changes.xml later,
though it should not affect too many people as this is
only for over-riding the default Cocoon catalog.
> Or did I oversee something?
Well the thing that really worries me is the hell that we
went through last time with getting consistent behaviour
on all platforms.
--David
RE: Finishing Deprecation Package
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
David Crossley wrote:
>
> Carsten Ziegeler wrote:
> > I just fixed some bugs in the catalog resolving code; as far
> > as I can tell everything is working fine. If you experience
> > problems, just let me know.
>
> Most bits seem to be working again, e.g. main Cocoon documentation.
> I also resurrected the 'catalog-demo' sample and that works.
>
> However other bits are still broken. The "Simplified DocBook"
> sample is busted. The old ResolverImpl.java used to load an
> additional catalog via the "local-catalog" parameter of
> cocoon.xconf using a full filesystem pathname starting with "/"
> ... now that is busted and the resolver tries to incorrectly
> load it from .../cocoon-2.1/build/webapp/home/me/work/...
> ^^^^^
Uh, that's not nice. The default catalog is defined by "/WEB-INF/...."
and this is loaded from the context directory.
Now, you say that if I define the "local-catalog" with "/..." then
this should *not* be loaded from the context directory, but
it should be assumed that this is an absolute path, right?
Now, there is something wrong with this approach. We can easily
change (which should be the 'correct' solution) that a path
starting with "/" is treated as an absolute path. So
if you want to load from the context directory, you have
to specify "WEB-INF/.." instead of "/WEB-INF".
But using a starting "/" with two different behaviours is imho
too confusing.
What do you think? Changing the above is absolutely simple.
Or did I oversee something?
Carsten
RE: Finishing Deprecation Package
Posted by David Crossley <cr...@indexgeo.com.au>.
Carsten Ziegeler wrote:
> I just fixed some bugs in the catalog resolving code; as far
> as I can tell everything is working fine. If you experience
> problems, just let me know.
Most bits seem to be working again, e.g. main Cocoon documentation.
I also resurrected the 'catalog-demo' sample and that works.
However other bits are still broken. The "Simplified DocBook"
sample is busted. The old ResolverImpl.java used to load an
additional catalog via the "local-catalog" parameter of
cocoon.xconf using a full filesystem pathname starting with "/"
... now that is busted and the resolver tries to incorrectly
load it from .../cocoon-2.1/build/webapp/home/me/work/...
^^^^^
I really do not understand why this behaviour had to be changed.
We spent many months figuring out how to load catalogs from either
under WEB-INF or from a local filesystem pathname and doing it
consistently on all platforms.
By the way, 'build test' will need to be fixed too. However,
some other tests are currently failing before it gets to the
entity resolver tests.
--David
RE: Finishing Deprecation Package
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Hi David,
I just fixed some bugs in the catalog resolving code; as far
as I can tell everything is working fine. If you experience
problems, just let me know.
Carsten
RE: Finishing Deprecation Package
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
David Crossley wrote:
>
> On Tue, 2003-03-11 Carsten Ziegeler wrote:
> > As I will not do it this week, here is a list of
> > things that have to be done to get the deprecation
> > package working. If someone wants to do it, I will
> > be very happy - otherwise I will perhaps do it
> > next week.
> >
> > The XScriptObject must be changed to inherit from the
> > excalibur source instead of the cocoon source. It might
> > be, that a logicsheet needs to be adapted as well.
> >
> > The Source interface from Cocoon and the
> > CocoonToAvalonSource class have to be moved from the
> > deprecated package into the core package.
> >
> > org.apache.cocoon.components.resolver.ResolverImpl has
> > to be changed to use the new Resolver from the excalibur
> > xmlutil package.
>
> Whoa, not so fast Carsten. I see that you have suddenly
> ripped out the comprehensive ResolverImpl.java and
> replaced it with a basic DefaultResolver.java ... Why?
> What is the reason for these drastic changes and why
> was there no discussion?
>
It's not a drastic change.
> This class was not marked as deprecated. Nicola Ken had
> already cleverly moved the deprecated Resolver.java into
> src/deprecated/
Yes, but ResolverImpl depends on Resolver, so you have a
dependency from the core to the deprecated package and
this has to be avoided.
> We have also lost the ability to configure the entity
> resolver via cocoon.xconf which was one purpose of
> the ResolverImpl.java
>
This is not true (unless it's a bug). In fact, if you compare
the code, the new DefaultResolver is absolutely the same as
the old ResolverImpl, so it should still be configurable and
working as the old one.
If anything is not working the way it should, it's simply a
bug which has to be fixed.
Carsten
Re: Finishing Deprecation Package
Posted by David Crossley <cr...@indexgeo.com.au>.
On Tue, 2003-03-11 Carsten Ziegeler wrote:
> As I will not do it this week, here is a list of
> things that have to be done to get the deprecation
> package working. If someone wants to do it, I will
> be very happy - otherwise I will perhaps do it
> next week.
>
> The XScriptObject must be changed to inherit from the
> excalibur source instead of the cocoon source. It might
> be, that a logicsheet needs to be adapted as well.
>
> The Source interface from Cocoon and the
> CocoonToAvalonSource class have to be moved from the
> deprecated package into the core package.
>
> org.apache.cocoon.components.resolver.ResolverImpl has
> to be changed to use the new Resolver from the excalibur
> xmlutil package.
Whoa, not so fast Carsten. I see that you have suddenly
ripped out the comprehensive ResolverImpl.java and
replaced it with a basic DefaultResolver.java ... Why?
What is the reason for these drastic changes and why
was there no discussion?
This class was not marked as deprecated. Nicola Ken had
already cleverly moved the deprecated Resolver.java into
src/deprecated/
I note that 'build docs' is now busted because it is not
using the entity resolver anymore. This is demonstrated
with the document xdocs/catalog-test.xdoc during 'build docs'
and via installing/tests.html with the webapp. And if we
did not have the belt-and-braces thing of copying all of
the DTDs under xdocs, as well as the originals in WEB-INF,
then documentation would all be broken.
Why is the entity resolver now busted? I do not know, but ...
The ResolverImpl.java in Cocoon uses the new version of
resolver.jar from xml-commons and configures it appropriately.
Is that jar compatible with the new DefaultResolver.java ?
We have also lost the ability to configure the entity
resolver via cocoon.xconf which was one purpose of
the ResolverImpl.java
I would prefer that these changes were rolled back until
we talk about it.
--David