You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by bu...@apache.org on 2003/06/03 14:58:09 UTC
DO NOT REPLY [Bug 20445] New: -
i18n transformer does not recognize 2.0 namespace
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20445>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20445
i18n transformer does not recognize 2.0 namespace
Summary: i18n transformer does not recognize 2.0 namespace
Product: Cocoon 2
Version: 2.1m2
Platform: Sun
OS/Version: Solaris
Status: NEW
Severity: Major
Priority: Other
Component: sitemap components
AssignedTo: cocoon-dev@xml.apache.org
ReportedBy: matomira@acm.org
The i18n transformer is not backwards-compatible. It only accepts the 2.1
namespace.
RE: Log level, compatibility
Posted by Geoff Howard <co...@leverageweb.com>.
> -----Original Message-----
> From: Vadim Gritsenko [mailto:vadim.gritsenko@verizon.net]
> Geoff Howard wrote:
>
> > At 02:14 AM 6/4/2003, Konstantin wrote:
> >
> >> +1 for lowering the log level to WARN.
> >> But it'd be much better to provide two (or more) typical
> configurations,
> >> e.g.:
> >> - development: log level - DEBUG, development cache settings, etc.
> >> - testing: log level - WARN, etc.
> >
>
> INFO should be even better.
>
> ...
>
> > Any takers to help me out?
>
>
> Why not simply error.level in build.properties and ant filtering of
> logkit.xconf? Simple, and no additional code.
>
> Vadim
That would work for this case but the build is not currently filtering
logkit.xconf is it? In general people have asked for this ability, and
I'd find it useful. Doesn't need to be tied to any log level change though,
just fishing. ;)
As an update, I tried using org.apache.tools.ant.filters.ExpandProperties
which extends java.io.Reader to wrap the File object on the way in to the
DocumentBuilder, but was getting errors.
Geoff
Re: Log level, compatibility
Posted by Vadim Gritsenko <va...@verizon.net>.
Geoff Howard wrote:
> At 02:14 AM 6/4/2003, Konstantin wrote:
>
>> +1 for lowering the log level to WARN.
>> But it'd be much better to provide two (or more) typical configurations,
>> e.g.:
>> - development: log level - DEBUG, development cache settings, etc.
>> - testing: log level - WARN, etc.
>
INFO should be even better.
>> - production: log level - ERROR, etc.
>>
>> What do you think?
>
...
> Any takers to help me out?
Why not simply error.level in build.properties and ant filtering of
logkit.xconf? Simple, and no additional code.
Vadim
Re: Log level, compatibility (was: Re: DO NOT REPLY [Bug
20445] New: - i18n transformer does notrecognize 2.0 namespace)
Posted by Geoff Howard <co...@leverageweb.com>.
At 02:14 AM 6/4/2003, Konstantin wrote:
>+1 for lowering the log level to WARN.
>But it'd be much better to provide two (or more) typical configurations,
>e.g.:
> - development: log level - DEBUG, development cache settings, etc.
> - testing: log level - WARN, etc.
> - production: log level - ERROR, etc.
>
>What do you think?
This could be done now with the new custom-config build target I've been
working on which uses <xpatch>. Currently, the only way to do this
would be to provide multiple patch files for the log xconf which rely on
different build properties (like config.loglevel.warn=true) because no
variable expansion is done on the contents of the xpatch.
(see:
http://wiki.cocoondev.org/Wiki.jsp?page=XPatchTaskUsage
http://wiki.cocoondev.org/Wiki.jsp?page=YourCocoonBasedProject (my comment
at the end)
http://marc.theaimsgroup.com/?l=xml-cocoon-cvs&m=105440069221225&w=2
It would be nice to enable variable substitution though. I looked at the
ant docs but
1) saw a warning of API instability in the package/class that
looked like what I'd need to do the expansion
2) only saw methods to operate on strings, but didn't see a clean way
to do so for xml being parsed in.
Any takers to help me out?
Geoff
Log level, compatibility (was: Re: DO NOT REPLY [Bug 20445] New: - i18n transformer does notrecognize 2.0 namespace)
Posted by Konstantin Piroumian <kp...@apache.org>.
From: "Bruno Dumon" <br...@outerthought.org>
> On Tue, 2003-06-03 at 23:12, Joerg Heinicke wrote:
> > I guess, legacy support won't be readded, so this is a WONTFIX?
> >
>
> yes, I agree. A bit of a problem though is that upon encountering the
> old namespace, the I18nTransformer nicely logs a warning, however the
> log level is error by default. Maybe we should lower it to warn instead?
Btw, the WARNING text in 2.1 states:
>>>>
...
Until then, there will be no warranty that newer versions will maintain
backward
compatibility for such parts, even in the most simple cases. Of course
Cocoon will be compatible to latest release, 2.0.x release.
...
<<<<
Somewhat contradicting statements, arent they? Should the version 2.1 be
backward compatible with 2.0.x releases?
>
> (there are other components also logging deprecation warnings not
> visible by default)
+1 for lowering the log level to WARN.
But it'd be much better to provide two (or more) typical configurations,
e.g.:
- development: log level - DEBUG, development cache settings, etc.
- testing: log level - WARN, etc.
- production: log level - ERROR, etc.
What do you think?
>
> --
> Bruno Dumon http://outerthought.org/
> Outerthought - Open Source, Java & XML Competence Support Center
> bruno@outerthought.org bruno@apache.org
>
>
Re: DO NOT REPLY [Bug 20445] New: - i18n transformer does not
recognize 2.0 namespace
Posted by Joerg Heinicke <jo...@gmx.de>.
Bruno Dumon wrote:
>>I guess, legacy support won't be readded, so this is a WONTFIX?
>
> yes, I agree. A bit of a problem though is that upon encountering the
> old namespace, the I18nTransformer nicely logs a warning, however the
> log level is error by default. Maybe we should lower it to warn instead?
>
> (there are other components also logging deprecation warnings not
> visible by default)
+ 0.5
Re: [Bug 20445] New: - i18n transformer does not recognize 2.0 namespace
Posted by Konstantin Piroumian <kp...@apache.org>.
From: "Sylvain Wallez" <sy...@anyware-tech.com>
> Bruno Dumon wrote:
> >On Tue, 2003-06-03 at 23:12, Joerg Heinicke wrote:
> >
> >
> >>I guess, legacy support won't be readded, so this is a WONTFIX?
> >>
> >>
> >
> >yes, I agree. A bit of a problem though is that upon encountering the
> >old namespace, the I18nTransformer nicely logs a warning, however the
> >log level is error by default. Maybe we should lower it to warn instead?
> >
> >(there are other components also logging deprecation warnings not
> >visible by default)
> >
>
> We should make a difference between deprecation (still works, but likely
> to disappear in the future), and detection of abandoned features.
>
> So IMO, if the old i18n namespace is detected but not supported, then
> the message should be an error, since the feature is no longer provided.
Agree.
>
> But this leads to another question : why did we loose backwards
> compatibility ? I'm a bit ignorant about the evolutions that led to
> change the namespace, but why haven't we kept the old transformer beside
> a new one handling the new namespace ?
I should take a look at the differences more carefully. I can't remember any
serious changes in syntax, except new extensions. The namespace was changed
to indicate the different syntax.
At the time of introducing the new namespace I asked the list if there are
any objections and didn't get anything in reply, so I droped the old one to
reduce the maintenance.
>
> This would have allowed a smooth migration path by not breaking existing
> applications. Of course, the old transformer should log a deprecation
> warning encouraging users to migrate to the new one.
>
> So what about renaming the new transformer to I18nTransformer2 and
> re-adding the old I18nTransformer ?
Personally, I am -0 for having two different transformers doing almost the
same thing just because I don't have any time now to devote to it. Though,
it's quite easy to get the i18n transformer from C 2.0 and modify it to be
compatible with C 2.1, then rename the new one to I18nTransformer2 (but what
about the reversion history?).
Maybe it'd be easier to provide a stylesheet that will transform 2.0 syntax
to 2.1? And maybe a target in build to perform this in batch mode.
--
Konstantin
>
> Sylvain
>
> --
> Sylvain Wallez Anyware Technologies
> http://www.apache.org/~sylvain http://www.anyware-tech.com
> { XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
>
>
>
Re: [Bug 20445] New: - i18n transformer does not recognize 2.0 namespace
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Bruno Dumon wrote:
>On Tue, 2003-06-03 at 23:12, Joerg Heinicke wrote:
>
>
>>I guess, legacy support won't be readded, so this is a WONTFIX?
>>
>>
>
>yes, I agree. A bit of a problem though is that upon encountering the
>old namespace, the I18nTransformer nicely logs a warning, however the
>log level is error by default. Maybe we should lower it to warn instead?
>
>(there are other components also logging deprecation warnings not
>visible by default)
>
We should make a difference between deprecation (still works, but likely
to disappear in the future), and detection of abandoned features.
So IMO, if the old i18n namespace is detected but not supported, then
the message should be an error, since the feature is no longer provided.
But this leads to another question : why did we loose backwards
compatibility ? I'm a bit ignorant about the evolutions that led to
change the namespace, but why haven't we kept the old transformer beside
a new one handling the new namespace ?
This would have allowed a smooth migration path by not breaking existing
applications. Of course, the old transformer should log a deprecation
warning encouraging users to migrate to the new one.
So what about renaming the new transformer to I18nTransformer2 and
re-adding the old I18nTransformer ?
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: DO NOT REPLY [Bug 20445] New: - i18n transformer does not
recognize 2.0 namespace
Posted by Bruno Dumon <br...@outerthought.org>.
On Tue, 2003-06-03 at 23:12, Joerg Heinicke wrote:
> I guess, legacy support won't be readded, so this is a WONTFIX?
>
yes, I agree. A bit of a problem though is that upon encountering the
old namespace, the I18nTransformer nicely logs a warning, however the
log level is error by default. Maybe we should lower it to warn instead?
(there are other components also logging deprecation warnings not
visible by default)
--
Bruno Dumon http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
bruno@outerthought.org bruno@apache.org
Re: DO NOT REPLY [Bug 20445] New: - i18n transformer does not
recognize 2.0 namespace
Posted by Joerg Heinicke <jo...@gmx.de>.
I guess, legacy support won't be readded, so this is a WONTFIX?
Joerg
bugzilla@apache.org wrote:
> http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20445
>
> i18n transformer does not recognize 2.0 namespace
>
> Summary: i18n transformer does not recognize 2.0 namespace
> Product: Cocoon 2
> Version: 2.1m2
> Platform: Sun
> OS/Version: Solaris
> Status: NEW
> Severity: Major
> Priority: Other
> Component: sitemap components
> AssignedTo: cocoon-dev@xml.apache.org
> ReportedBy: matomira@acm.org
>
>
> The i18n transformer is not backwards-compatible. It only accepts the 2.1
> namespace.