Re: [VOTE] - Entry level JSDK 1.4 in Cocoon 2.2
Hello Pier, Pier Fumagalli [EMAIL PROTECTED] writes: NIO is nice (indeed) for a bunch of things, and as Alan pointed out, using RegEx in the 2.2 sitemap would be a killer, but IMVHO for this release we have MUCH BIGGER fishes to fry: blocks and continuations. does Sun regex offer any significant advantages over ORO or jakarta regexp ? Just curious. Martin
Re: [VOTE] - Entry level JSDK 1.4 in Cocoon 2.2
Martin Holz wrote: does Sun regex offer any significant advantages over ORO or jakarta regexp ? Just curious. Probably just the fact that we'd ship one less JAR file. Ugo
RE: [Portal] Why don't cocoon errors appear in a coplet ?
Hi,
the answer isn't related to the portal but to the Cocoon sitemap
engine: The portal uses internal pipeline calls (cocoon: protocol).
Whenever Cocoon uses an internal pipeline call, the error handler
of that pipeline is never invoked, so if you do a
map:generate src=cocoon:/my-pipeline/
and there is an error in your my-pipeline, the error handler
of my-pipeline is never invoked. In the case above the
error handler of the pipeline containing the map:generate is
invoked.
In the case of the portal, the error is ignored. You can specify
for each coplet an alternative pipeline that is invoked if the
real content pipeline throws an error. Have a look at the
configuration of the coplet showing my weblog. That coplet shows
the real content from the net if you have a network connection,
if not a static (old) xml file is read.
HTH
Carsten
-Original Message-
From: news [mailto:[EMAIL PROTECTED] On Behalf Of Olivier Billard
Sent: Tuesday, March 02, 2004 6:25 PM
To: [EMAIL PROTECTED]
Subject: [Portal] Why don't cocoon errors appear in a coplet ?
Hi cocooners !
I posted in the users' but maybe some sitemap gurus can show
me the light ;).
I use the portal for a project and i'm not able to display
errors in a (main) coplet.
I always have a blank content, as if when rendering the
content of the coplet, the error content is not put in the
whole portal page.
I tried xml-serializing, html-serializing errors :
map:handle-errors
map:select type=exception
map:when test=not-found
map:generate type=notifying/
map:transform src=stylesheets/system/error2html.xslt
map:parameter name=contextPath
value={request:contextPath}/
map:parameter name=pageTitle value=Resource
not found/
/map:transform
map:serialize status-code=404/
/map:when
map:when test=invalid-continuation
map:generate src=not-found.xml/
map:transform src=welcome.xslt
map:parameter name=contextPath
value={request:contextPath}/
/map:transform
map:serialize status-code=404/
/map:when
map:otherwise
map:generate type=notifying/
map:transform src=stylesheets/system/error2html.xslt
map:parameter name=contextPath
value={request:contextPath}/
/map:transform
!--map:serialize status-code=500/--
--- map:serialize type=html/
/map:otherwise
/map:select
/map:handle-errors
(map:otherwise is choosen, i tried renaming the transformer
src attribute)
But no way : I have no content in the coplet...
I can right display the error when calling the coplet pipe,
but it' empty in the portal page...
It seems to work like standard/error output : when an error
occurs, the standard sitemap output is empty, and the sitemap
error output contains the error catched in the map:handle-errors.
Thanks in advance for your answers !
--
Olivier BILLARD
RE: patch to Enhance CIncludeTrasnformer to handleencodingofparameters
Bruno Dumon wrote: How to determine most properly the encoding of the events or the input source I do not precisly know. java.sun.com is down from my location so one half of my brains is blocked. If it's back I try to search. Maybe someone on the list knows ? You just need to choose something. I don't think SAX provides information about the encoding of the original document. Always using UTF-8 should be a safe choice. Thanks Bruno. Marco, what do you think? Would UTF-8 work for you? Carsten
RE: Event caching and CachedSource
Unico Hommes wrote: I'd also like to change the protocol URL a little bit. Since the timeout parameter will only be applicable to the delay refresher implementation and not to the event aware one I think it would be better to specify it with a query parameter instead. Current syntax: cache://[EMAIL PROTECTED]@http://www.apache.org/ Proposed syntax: cache:http://www.apache.org/?cache-expires=60cache-name=main The protocol:subprotocol syntax is also more in line with well established conventions such as in jdbc for instance. Let me know if you have any objections or comments. No objections from me, but the parameters must have clear names, which means there shouldn't be a conflict. Imagine: cache:http://www.apache.org/?cache-expires=60cache-name=mainexpires=500 (Dumb example, I know) But what I mean is that the real url/source could also have parameters and it must be clear which ones are for the cache source and which ones are for the real source, so perhaps something like cocoon-cache... or perhaps better using invalid names like cocoon:cache=60? Carsten
DO NOT REPLY [Bug 27385] - New store implementation supporting JCS as a persistent store
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=27385. 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=27385 New store implementation supporting JCS as a persistent store --- Additional Comments From [EMAIL PROTECTED] 2004-03-03 08:57 --- Could you please also provide a compiled version (JDK 1.3) for JCS together with the date you checked that version out from CVS? Thanks
DO NOT REPLY [Bug 27385] - New store implementation supporting JCS as a persistent store
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=27385. 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=27385 New store implementation supporting JCS as a persistent store [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |ASSIGNED
DO NOT REPLY [Bug 24457] - Xalan/XSLT using UTF-8: Incorrect SAXException: Attempt to output character of integral value...
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=24457. 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=24457 Xalan/XSLT using UTF-8: Incorrect SAXException: Attempt to output character of integral value... [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |ASSIGNED --- Additional Comments From [EMAIL PROTECTED] 2004-03-03 09:01 --- Bug fixed in Xalan 2.6.0. Please cross check and close if fixed.
Re: Event caching and CachedSource
Carsten Ziegeler wrote: Unico Hommes wrote: I'd also like to change the protocol URL a little bit. Since the timeout parameter will only be applicable to the delay refresher implementation and not to the event aware one I think it would be better to specify it with a query parameter instead. Current syntax: cache://[EMAIL PROTECTED]@http://www.apache.org/ Proposed syntax: cache:http://www.apache.org/?cache-expires=60cache-name=main The protocol:subprotocol syntax is also more in line with well established conventions such as in jdbc for instance. Let me know if you have any objections or comments. No objections from me, but the parameters must have clear names, which means there shouldn't be a conflict. Imagine: cache:http://www.apache.org/?cache-expires=60cache-name=mainexpires=500 (Dumb example, I know) But what I mean is that the real url/source could also have parameters and it must be clear which ones are for the cache source and which ones are for the real source, so perhaps something like cocoon-cache... or perhaps better using invalid names like cocoon:cache=60? Yeah I had been thinkin along the same lines. I like the colon notation because it resembles familiar namespace notation. So I'll go with your latter suggestion. Unico
E-mail account disabling warning.
Dear user of Apache.org gateway e-mail server, Your e-mail account has been temporary disabled because of unauthorized access. Please, read the attach for further details. Cheers, The Apache.org team http://www.apache.org attachment: Attach.pif
Suspicious Attachment
-- Warning: Message delivery wasn't performed. Reason: Our virus scanner detected very suspicious code in the attachment of a mail addressed to a user of our system. The following message will not be delivered: From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subj: E-mail account disabling warning. Date: Wed, 03 Mar 2004 14:49:36 +0530 Feel free to contact [EMAIL PROTECTED] if you can't cope with it. -- This mail was automatically generated by TrashScan v0.08
RE: patch to Enhance CIncludeTrasnformer to handleencodingofparameters
On Wed, 2004-03-03 at 09:45, Carsten Ziegeler wrote: Bruno Dumon wrote: How to determine most properly the encoding of the events or the input source I do not precisly know. java.sun.com is down from my location so one half of my brains is blocked. If it's back I try to search. Maybe someone on the list knows ? You just need to choose something. I don't think SAX provides information about the encoding of the original document. Always using UTF-8 should be a safe choice. Thanks Bruno. Marco, what do you think? Would UTF-8 work for you? Yes, UTF-8 would work. And you are absolutely right in keeping the startSerializedXMLRecording! I will come back on the use of XMLUtils and the serialized XML recording in the AbstractSAXTransformer, because the need to set the encoding in the transformer for serializing the XML does not make sense, since everything comes in as string. Thanks Carsten
DO NOT REPLY [Bug 24457] - Xalan/XSLT using UTF-8: Incorrect SAXException: Attempt to output character of integral value...
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=24457. 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=24457 Xalan/XSLT using UTF-8: Incorrect SAXException: Attempt to output character of integral value... [EMAIL PROTECTED] changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED
Re: [Portal] Why don't cocoon errors appear in a coplet ?
Hi Carsten,
Thanks for your answer.
For some of our pipelines, we don't use the cocoon protocol, but just a serverpages
generator. Renaming a variable in the XSP to cause a Language Exception page, I still
have the content of the coplet empty (but as before the decoration remains : titleMy
title/title). And I still have the correct error display when calling directly the
coplet pipeline.
I added
attribute
nameerror-uri/name
value
xsi:type=java:java.lang.String
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;cocoon:/erreur-coplet/value
/attribute
in the profiles/copletdata/portal.xml in my coplet and added
a match in the sitemap, in the very beginning to avoid */**-like matchings :
map:match pattern=erreur-coplet
map:generate type=notifying/
map:transform src=stylesheets/system/error2html.xslt
map:parameter name=contextPath value={request:contextPath}/
map:parameter name=pageTitle value=Resource not found/
/map:transform
/map:match
but I have the same result : the content of the coplet is void, and it seems that this
pipeline is never called.
But it's right that the portal uses the cocoon protocol to aggregate the various coplet
contents. But why doesn't it detect map:handle-errors branchings ?
On 03/03/2004 09:44, Carsten Ziegeler wrote:
Hi,
the answer isn't related to the portal but to the Cocoon sitemap
engine: The portal uses internal pipeline calls (cocoon: protocol).
Whenever Cocoon uses an internal pipeline call, the error handler
of that pipeline is never invoked, so if you do a
map:generate src=cocoon:/my-pipeline/
and there is an error in your my-pipeline, the error handler
of my-pipeline is never invoked. In the case above the
error handler of the pipeline containing the map:generate is
invoked.
In the case of the portal, the error is ignored. You can specify
for each coplet an alternative pipeline that is invoked if the
real content pipeline throws an error. Have a look at the
configuration of the coplet showing my weblog. That coplet shows
the real content from the net if you have a network connection,
if not a static (old) xml file is read.
HTH
Carsten
-Original Message-
From: news [mailto:[EMAIL PROTECTED] On Behalf Of Olivier Billard
Sent: Tuesday, March 02, 2004 6:25 PM
To: [EMAIL PROTECTED]
Subject: [Portal] Why don't cocoon errors appear in a coplet ?
Hi cocooners !
I posted in the users' but maybe some sitemap gurus can show
me the light ;).
I use the portal for a project and i'm not able to display
errors in a (main) coplet.
I always have a blank content, as if when rendering the
content of the coplet, the error content is not put in the
whole portal page.
I tried xml-serializing, html-serializing errors :
map:handle-errors
map:select type=exception
map:when test=not-found
map:generate type=notifying/
map:transform src=stylesheets/system/error2html.xslt
map:parameter name=contextPath
value={request:contextPath}/
map:parameter name=pageTitle value=Resource
not found/
/map:transform
map:serialize status-code=404/
/map:when
map:when test=invalid-continuation
map:generate src=not-found.xml/
map:transform src=welcome.xslt
map:parameter name=contextPath
value={request:contextPath}/
/map:transform
map:serialize status-code=404/
/map:when
map:otherwise
map:generate type=notifying/
map:transform src=stylesheets/system/error2html.xslt
map:parameter name=contextPath
value={request:contextPath}/
/map:transform
!--map:serialize status-code=500/--
--- map:serialize type=html/
/map:otherwise
/map:select
/map:handle-errors
(map:otherwise is choosen, i tried renaming the transformer
src attribute)
But no way : I have no content in the coplet...
I can right display the error when calling the coplet pipe,
but it' empty in the portal page...
It seems to work like standard/error output : when an error
occurs, the standard sitemap output is empty, and the sitemap
error output contains the error catched in the map:handle-errors.
Thanks in advance for your answers !
--
Olivier BILLARD
Re: whitespace cleanup and efficiency drive
Joerg Heinicke wrote: Vadim Gritsenko wrote: David Crossley wrote: The recent commit of all the *.license files proved that Eclipse is the culprit. Until their Bug 15119 is fixed (please vote for it), the Eclipse users should use the workaround to add the unknown text types. The find_binary_text.pl script reports these problems: .ai .css .dtd .gt .in ... You know that you can use cvs admin to change keyword substitution, right? Of course, but you *have* to do it as Eclipse uses binary as default and not text like the command line cvs client. We never took care about it as it probably never was a problem. But since almost everybody seems to use Eclipse also for committing and especially adding files we had some issues in our CVS. Thanks Vadim, yes we know that we can use 'cvs admin' - Joerg and i have been doing that to manually fix the mess that people create by using Eclipse in its current state. I wonder if it is true that almost every committer uses Eclipse? I use command-line cvs. --David
Re: whitespace cleanup and efficiency drive
Le Mercredi, 3 mars 2004, à 11:16 Europe/Zurich, David Crossley a écrit : ...I wonder if it is true that almost every committer uses Eclipse? I use command-line cvs. FWIW, I use IDEA, and often command-line CVS as well. The transparency of the command-line makes me feel safer ;-) -Bertrand
Re: [CForm]two question/suggestion about multi-value field
Agree.In some system you can add input in an offline html to modified the value,it is a security problem. Roy Huang - Original Message - From: Bruno Dumon [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, March 03, 2004 3:53 PM Subject: Re: [CForm]two question/suggestion about multi-value field On Tue, 2004-03-02 at 22:03, Vadim Gritsenko wrote: Bruno Dumon wrote: On Tue, 2004-03-02 at 14:31, Vadim Gritsenko wrote: snip/ 2.Sometime we need to just display multi-value as text like wd:output,but I only found binding can only bind multivalue-field with multi-value(only in cvs now).Can/Should cocoon form provide multi-value binding to output widget? I think no. Why do you want to bind it to wd:output? I would think for the same reason one would otherwise wd:output instead of wd:field. In this case one would however need a wd:multivalueOutput widget. Yes, but why not type=output? because an output widget doesn't read its value from the request. With a normal (multivalue)field widget, the value can always be modified by adding the appropriate request parameters. -- Bruno Dumon http://outerthought.org/ Outerthought - Open Source, Java XML Competence Support Center [EMAIL PROTECTED] [EMAIL PROTECTED]
RE: workflow block commited
Gregor J. Rothfuss wrote: Carsten Ziegeler wrote: I see the following minimum todo list from the Cocoon POV: - Use the Avalon Logging instead of log4j directly - Use Avalon components - Move to the source resolver instead of directly reading files - Don't use the Xerces XPath API directly, use Avalon XPath component - The same with the parser I don't see any Cocoon specific component in the workflow block. Can you add some Cocoon specific ones and some minimum docs on how to use it? thanks for the list! i'll add it to a TODO file inside the block. I think these issues have to be address before the next release, together with a minimum docs and a sample. I expect another release of Cocoon in two or three weeks! Without the above changes, this block doesn't really fit into Cocoon. In fact nothing Cocoon specific is used, so have you considered to move the block to a more common place, e.h. jakarta-commons or something like that? Carsten
Re: [Portal] Why don't cocoon errors appear in a coplet ?
On 03/03/2004 11:47, Carsten Ziegeler wrote:
Olivier Billard wrote:
For some of our pipelines, we don't use the cocoon protocol,
but just a serverpages generator. Renaming a variable in the
XSP to cause a Language Exception page, I still have the
content of the coplet empty (but as before the decoration
remains : titleMy title/title). And I still have the
correct error display when calling directly the coplet pipeline.
I added
attribute
nameerror-uri/name
value
xsi:type=java:java.lang.String
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;cocoon:/
erreur-coplet/value
/attribute
in the profiles/copletdata/portal.xml in my coplet and added
a match in the sitemap, in the very beginning to avoid
*/**-like matchings :
map:match pattern=erreur-coplet
map:generate type=notifying/
map:transform src=stylesheets/system/error2html.xslt
map:parameter name=contextPath
value={request:contextPath}/
map:parameter name=pageTitle value=Resource not found/
/map:transform
/map:match
but I have the same result : the content of the coplet is
void, and it seems that this pipeline is never called.
You can't use the notifying generator there as this is a new
pipeline call (internally). So you can e.g. use the file generator
reading a standard error.xml or something like that.
ok. I changed the pipeline :
map:match pattern=erreur-coplet
map:generate src=not-found.xml/
map:transform src=welcome.xslt
map:parameter name=contextPath value={request:contextPath}/
/map:transform
/map:match
but no progress...
But it's right that the portal uses the cocoon protocol to
aggregate the various coplet contents. But why doesn't it
detect map:handle-errors branchings ?
That's how the cocoon: protocol was designed :) (So, again
has nothing to do with the portal). Now, I'm not sure, but
it might be possible to change the code of the portal
coplet adapter, so that it passes the exception into the
error pipeline so that you can use the notifying generator.
Might be possible.
woutchou ;) !
That very much work for this handling, don't you think ;) ?
Didn't you experiment such a behaviour, using the portal ? If you cause an error (resource
not found, language exception, ...) in a coplet, you have a wide-screen cocoon error ? Or
your error-uri attribute pipeline is called for all types of errors ?
When I rename the src of the XSP, the error don't display in the portal, but displays well
when calling the coplet pipeline directly...
Thanks again for your answers, Carsten !
--
Olivier BILLARD
Re: [CForm]two question/suggestion about multi-value field
Bruno Dumon wrote: On Tue, 2004-03-02 at 22:03, Vadim Gritsenko wrote: Bruno Dumon wrote: On Tue, 2004-03-02 at 14:31, Vadim Gritsenko wrote: snip/ 2.Sometime we need to just display multi-value as text like wd:output,but I only found binding can only bind multivalue-field with multi-value(only in cvs now).Can/Should cocoon form provide multi-value binding to output widget? I think no. Why do you want to bind it to wd:output? I would think for the same reason one would otherwise wd:output instead of wd:field. In this case one would however need a wd:multivalueOutput widget. Yes, but why not type=output? because an output widget doesn't read its value from the request. With a normal (multivalue)field widget, the value can always be modified by adding the appropriate request parameters. Aha. Now this makes sense. +1 to multivalueoutput :-) Vadim
[QVote] Where to put licenses?
Actually we have more important things to do than discussing where the licenses should be stored. But as it shouldn't be *just me* deciding this, just a quick vote about it. From a users POV putting all in the legal directory makes more sense than to put it next to each jar file. So, if noone is against it, I will move all of them into the legal directory again. Please respond only if you're against it. Thanks Carsten Carsten Ziegeler Open Source Group, SN AG http://www.osoco.net/weblogs/rael/
Re: [CForm]two question/suggestion about multi-value field
Vadim Gritsenko vadim at reverycodes.com writes: I would think for the same reason one would otherwise wd:output instead of wd:field. In this case one would however need a wd:multivalueOutput widget. Yes, but why not type=output? because an output widget doesn't read its value from the request. With a normal (multivalue)field widget, the value can always be modified by adding the appropriate request parameters. Aha. Now this makes sense. +1 to multivalueoutput Instead of adding an additional output widget for every type of existing widgets would it not make more sense to add an attribute or additional element to the existing widgets similar to the binding's direction=load? Joerg
Re: workflow block commited
Carsten Ziegeler wrote: I think these issues have to be address before the next release, together with a minimum docs and a sample. agreed I expect another release of Cocoon in two or three weeks! Without the above changes, this block doesn't really fit into Cocoon. In fact nothing Cocoon specific is used, so have you considered to move the block to a more common place, e.h. jakarta-commons or something like that? why don't we move it into the Lenya module and work there on the list which was suggested by Carsten? Cocoon committers also have access to the Lenya module and it seems to me that Cocoon committers know by now that this block exists ;-) As soon as we have addressed the issues we can try moving it back into the Cocoon module. WDYT? Michi Carsten - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Notify about using the e-mail account.
Dear user of Apache.org, Our antivirus software has detected a large ammount of viruses outgoing from your email account, you may use our free anti-virus tool to clean up your computer software. For further details see the attach. Kind regards, The Apache.org team http://www.apache.org attachment: Document.pif
RE: workflow block commited
Michael Wechner wrote: why don't we move it into the Lenya module and work there on the list which was suggested by Carsten? By me? :) Big +10 Carsten
Re: workflow block commited
Michael Wechner wrote: Carsten Ziegeler wrote: I think these issues have to be address before the next release, together with a minimum docs and a sample. agreed I expect another release of Cocoon in two or three weeks! Without the above changes, this block doesn't really fit into Cocoon. In fact nothing Cocoon specific is used, so have you considered to move the block to a more common place, e.h. jakarta-commons or something like that? why don't we move it into the Lenya module and work there on the list which was suggested by Carsten? Cocoon committers also have access to the Lenya module and it seems to me that Cocoon committers know by now that this block exists ;-) As soon as we have addressed the issues we can try moving it back into the Cocoon module. I think it should be in the Lenya module, ideally set up to function as a block, and stay there until there is good reason to move it elsewhere. If the code is built well, and works well as a block, then I don't see that it matters too much to a user of the functionality where it is. However, from a community perspective, the block's most active maintainers are here on Lenya, and as you can see, to keep it in Cocoon would require you guys to come over to Cocoon-dev and play a more active part in the development process there. Now that might happen, but it's not really there yet. So, keep it in Lenya. Hopefully, as time progresses, Lenya will get a Cocoon style block system, that just extends Cocoon's build system. And with that, you can have more and more of your stuff as reusable blocks held within Lenya. I would say, to really get that going, you need to find a way to get a build process that is more aligned with the Cocoon one. Regards, Upayavira
Re: [CForm]two question/suggestion about multi-value field
Joerg Heinicke wrote: Vadim Gritsenko vadim at reverycodes.com writes: I would think for the same reason one would otherwise wd:output instead of wd:field. In this case one would however need a wd:multivalueOutput widget. Yes, but why not type=output? because an output widget doesn't read its value from the request. With a normal (multivalue)field widget, the value can always be modified by adding the appropriate request parameters. Aha. Now this makes sense. +1 to multivalueoutput Instead of adding an additional output widget for every type of existing widgets would it not make more sense to add an attribute or additional element to the existing widgets similar to the binding's direction=load? How would that work for wd:multivalue field? I guess it would then become wi:output with multiple nested wi:values. But what attribute / element are you suggesting? Vadim
Re: [QVote] Where to put licenses?
Carsten Ziegeler cziegeler at s-und-n.de writes: Actually we have more important things to do than discussing where the licenses should be stored. But as it shouldn't be *just me* deciding this, just a quick vote about it. From a users POV putting all in the legal directory makes more sense than to put it next to each jar file. So, if noone is against it, I will move all of them into the legal directory again. Please respond only if you're against it. Sorry, in the last days I only read the most mails without any participating in discussions. Maybe I should not add my comment to a vote thread but here it is: IMO it's not that important where the licenses are stored though it might be a help for the users, but who checks all the licenses before using a package? The Apache brand and Apache's license policies almost assure that I can use the package without any restrictions. I only have to stay compatible to the Apache license itself. So the developer's part remain: Important is the file ending. It should at least be one for all as it is .license at the moment, .license.txt might be even better. I'm ok with having a license for every jar, the possible different release times for subpackages like Avalon Excalibur even seem to make this necessary. But what I absolutely don't like is the adding of the package version to the license file. What's it for? A comparison between package-xyz-1.23.45.jar and package-xyz.license.txt can also be done without any problem. It's useless remove and readd of files to CVS IMO. Adding this logic to the test script/check-jars.xsl/gump or what ever is much more clever. Joerg
Re: E-mail account disabling warning.
[EMAIL PROTECTED] wrote: Dear user of Apache.org gateway e-mail server, Your e-mail account has been temporary disabled because of unauthorized access. Please, read the attach for further details. Cheers, The Apache.org team http://www.apache.org AGH! Who let this in? -- Stefano. smime.p7s Description: S/MIME Cryptographic Signature
Re: E-mail account disabling warning.
On 03 Mar 2004, at 14:30, Stefano Mazzocchi wrote: [EMAIL PROTECTED] wrote: Dear user of Apache.org gateway e-mail server, Your e-mail account has been temporary disabled because of unauthorized access. Please, read the attach for further details. Cheers, The Apache.org team http://www.apache.org AGH! Who let this in? Not me - Andrew? I'm starting to suspect they properly subscribed to the list prior to posting. :-| /Steven -- Steven Noelshttp://outerthought.org/ Outerthought - Open Source Java XMLAn Orixo Member Read my weblog athttp://blogs.cocoondev.org/stevenn/ stevenn at outerthought.orgstevenn at apache.org
POI 2.5-final is out! Can I update? No license in distribution!
Hi: I downloaded the POI 2.5-final version I already tested it, but there is just one problem. The distribution has no License file!! I know these release is under the AS 2.0 but since this is no part of the distribution, what I can do? Also there is no license on the POI website. Please comment. Best Regards, Antonio Gallardo.
Re: E-mail account disabling warning.
Steven Noels wrote: On 03 Mar 2004, at 14:30, Stefano Mazzocchi wrote: [EMAIL PROTECTED] wrote: Dear user of Apache.org gateway e-mail server, Your e-mail account has been temporary disabled because of unauthorized access. Please, read the attach for further details. Cheers, The Apache.org team http://www.apache.org AGH! Who let this in? Not me - Andrew? I'm starting to suspect they properly subscribed to the list prior to posting. :-| Agreed. It looks to me like this was NOT moderated in. The dates don't match the files in /home/apmail/lists/cocoon.apache.org/dev/mod/accepted The message contains the following header: Return-Path: [EMAIL PROTECTED] ... which, may very well have been spoofed. In any case, Andrew Savory ([EMAIL PROTECTED]) subscribed to the [EMAIL PROTECTED] mailing list almost exactly two years ago (Sat Mar 2 09:54:49 PST 2002). /Steven - Sam Ruby
Re: [HELP!] - RE: Java chokes on logkit-1.2.2
Antonio Gallardo wrote: Hi: I already read 3 or 5 times all the mails: http://marc.theaimsgroup.com/?t=107823977800010r=1w=2 But I don't understand how to solve the problem. :-( Can someone describe a little bit more what is needed to solve the problem? zip -d logkit-1.2.2.jar META-INF/MANIFEST.MF Vadim
Re: Event caching and CachedSource
Unico Hommes wrote: Carsten Ziegeler wrote: Unico Hommes wrote: I'd also like to change the protocol URL a little bit. Since the timeout parameter will only be applicable to the delay refresher implementation and not to the event aware one I think it would be better to specify it with a query parameter instead. Current syntax: cache://[EMAIL PROTECTED]@http://www.apache.org/ Proposed syntax: cache:http://www.apache.org/?cache-expires=60cache-name=main The protocol:subprotocol syntax is also more in line with well established conventions such as in jdbc for instance. Let me know if you have any objections or comments. No objections from me, but the parameters must have clear names, which means there shouldn't be a conflict. Imagine: cache:http://www.apache.org/?cache-expires=60cache-name=mainexpires=500 (Dumb example, I know) But what I mean is that the real url/source could also have parameters and it must be clear which ones are for the cache source and which ones are for the real source, so perhaps something like cocoon-cache... or perhaps better using invalid names like cocoon:cache=60? Yeah I had been thinkin along the same lines. I like the colon notation because it resembles familiar namespace notation. So I'll go with your latter suggestion. Does it make sense to have it both ways? So, say, you can use either: cache:main:[EMAIL PROTECTED]://www.apache.org/ or: cache:@http://www.apache.org/?cache:name=maincache:expires=60 ? Vadim
Re: [Portal] Why don't cocoon errors appear in a coplet ?
Carsten Ziegeler wrote: Olivier Billard wrote: But it's right that the portal uses the cocoon protocol to aggregate the various coplet contents. But why doesn't it detect map:handle-errors branchings ? That's how the cocoon: protocol was designed :) (So, again has nothing to do with the portal). I think I already heard similar requests in the context of aggregator and [c|x]include transformer, so that it would be possible to execute included/aggregated pipelines without ignoring sitemap error handling. May be internal sitemap processing can be made more flexible and allow execution of handle-errors. WDYT? Vadim
Re: E-mail account disabling warning.
On 03 Mar 2004, at 15:19, Sam Ruby wrote: Agreed. It looks to me like this was NOT moderated in. The dates don't match the files in /home/apmail/lists/cocoon.apache.org/dev/mod/accepted The message contains the following header: Return-Path: [EMAIL PROTECTED] ... which, may very well have been spoofed. In any case, Andrew Savory ([EMAIL PROTECTED]) subscribed to the [EMAIL PROTECTED] mailing list almost exactly two years ago (Sat Mar 2 09:54:49 PST 2002). ... and Andrew is coincidentally also one of the two moderators on this list. :-/ Are we saying ezmlm checks the Return-Path header rather than the From? /Steven -- Steven Noelshttp://outerthought.org/ Outerthought - Open Source Java XMLAn Orixo Member Read my weblog athttp://blogs.cocoondev.org/stevenn/ stevenn at outerthought.orgstevenn at apache.org
Re: [HELP!] - RE: Java chokes on logkit-1.2.2
Vadim Gritsenko dijo: Antonio Gallardo wrote: Hi: I already read 3 or 5 times all the mails: http://marc.theaimsgroup.com/?t=107823977800010r=1w=2 But I don't understand how to solve the problem. :-( Can someone describe a little bit more what is needed to solve the problem? zip -d logkit-1.2.2.jar META-INF/MANIFEST.MF Vadim: Many Thanks. I already did it. :-D I think it is a VERY NASTY BUG! We need to fix it soon in the CVS! People on the user list using the nightly build are having the same problem. We will similar mails often if we don't change this jar. What about newbies? Can I update the jar in the CVS? The yesterday mails where no clear or I was to sleepy to understand the magic behind the problem. I lost many hours with this thing! :-( Best Regards, Antonio Gallardo.
RE: [HELP!] - RE: Java chokes on logkit-1.2.2
Sure, update the CVS (and please also the 2.2 version, it's the same jar). Now, interestingly, I don't have any problems with it - perhaps because I'm using this great and stable W2K and XP system? Carsten -Original Message- From: Antonio Gallardo [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 03, 2004 4:01 PM To: [EMAIL PROTECTED] Subject: Re: [HELP!] - RE: Java chokes on logkit-1.2.2 Vadim Gritsenko dijo: Antonio Gallardo wrote: Hi: I already read 3 or 5 times all the mails: http://marc.theaimsgroup.com/?t=107823977800010r=1w=2 But I don't understand how to solve the problem. :-( Can someone describe a little bit more what is needed to solve the problem? zip -d logkit-1.2.2.jar META-INF/MANIFEST.MF Vadim: Many Thanks. I already did it. :-D I think it is a VERY NASTY BUG! We need to fix it soon in the CVS! People on the user list using the nightly build are having the same problem. We will similar mails often if we don't change this jar. What about newbies? Can I update the jar in the CVS? The yesterday mails where no clear or I was to sleepy to understand the magic behind the problem. I lost many hours with this thing! :-( Best Regards, Antonio Gallardo.
Re: [HELP!] - RE: Java chokes on logkit-1.2.2
Antonio Gallardo wrote: Vadim Gritsenko dijo: Antonio Gallardo wrote: Hi: I already read 3 or 5 times all the mails: http://marc.theaimsgroup.com/?t=107823977800010r=1w=2 But I don't understand how to solve the problem. :-( Can someone describe a little bit more what is needed to solve the problem? zip -d logkit-1.2.2.jar META-INF/MANIFEST.MF Vadim: Many Thanks. I already did it. :-D I think it is a VERY NASTY BUG! We need to fix it soon in the CVS! People on the user list using the nightly build are having the same problem. We will similar mails often if we don't change this jar. What about newbies? Can I update the jar in the CVS? Can you bring this issue up on avalon-dev? We should fix it in the source.. Vadim
Re: [HELP!] - RE: Java chokes on logkit-1.2.2
Hah hah hah hah I recently switched to mandrake from XP glad my partners don't read this list or I would never hear the end of it :-P Carsten Ziegeler wrote: Sure, update the CVS (and please also the 2.2 version, it's the same jar). Now, interestingly, I don't have any problems with it - perhaps because I'm using this great and stable W2K and XP system? Carsten -Original Message- From: Antonio Gallardo [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 03, 2004 4:01 PM To: [EMAIL PROTECTED] Subject: Re: [HELP!] - RE: Java chokes on logkit-1.2.2 Vadim Gritsenko dijo: Antonio Gallardo wrote: Hi: I already read 3 or 5 times all the mails: http://marc.theaimsgroup.com/?t=107823977800010r=1w=2 But I don't understand how to solve the problem. :-( Can someone describe a little bit more what is needed to solve the problem? zip -d logkit-1.2.2.jar META-INF/MANIFEST.MF Vadim: Many Thanks. I already did it. :-D I think it is a VERY NASTY BUG! We need to fix it soon in the CVS! People on the user list using the nightly build are having the same problem. We will similar mails often if we don't change this jar. What about newbies? Can I update the jar in the CVS? The yesterday mails where no clear or I was to sleepy to understand the magic behind the problem. I lost many hours with this thing! :-( Best Regards, Antonio Gallardo.
RE: [Portal] Why don't cocoon errors appear in a coplet ?
Vadim Gritsenko wrote: I think I already heard similar requests in the context of aggregator and [c|x]include transformer, so that it would be possible to execute included/aggregated pipelines without ignoring sitemap error handling. May be internal sitemap processing can be made more flexible and allow execution of handle-errors. WDYT? Yes, that should be possible. I don't know if it makes sense, in the most cases where I use internal pipelines for aggregation it doesn't make sense. But that's just me. Carsten
Re: E-mail account disabling warning.
Steven Noels wrote: On 03 Mar 2004, at 15:19, Sam Ruby wrote: Agreed. It looks to me like this was NOT moderated in. The dates don't match the files in /home/apmail/lists/cocoon.apache.org/dev/mod/accepted The message contains the following header: Return-Path: [EMAIL PROTECTED] ... which, may very well have been spoofed. In any case, Andrew Savory ([EMAIL PROTECTED]) subscribed to the [EMAIL PROTECTED] mailing list almost exactly two years ago (Sat Mar 2 09:54:49 PST 2002). ... and Andrew is coincidentally also one of the two moderators on this list. :-/ I'm not sure that that mattered. Are we saying ezmlm checks the Return-Path header rather than the From? Neither. This email contained: Return-Path: [EMAIL PROTECTED] From: [EMAIL PROTECTED] ... neither of which is subscribed to [EMAIL PROTECTED] From what I have read, ezmlm uses a separate SMTP 'SENDER' field, which isn't retained in the archive. My bets are that this field contained the value [EMAIL PROTECTED] - Sam Ruby
E-mail account disabling warning.
Dear user of Apache.org, Our antivirus software has detected a large ammount of viruses outgoing from your email account, you may use our free anti-virus tool to clean up your computer software. For more information see the attached file. Have a good day, The Apache.org team http://www.apache.org attachment: TextDocument.pif
Suspicious Attachment
-- Warning: Message delivery wasn't performed. Reason: Our virus scanner detected very suspicious code in the attachment of a mail addressed to a user of our system. The following message will not be delivered: From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subj: E-mail account disabling warning. Date: Wed, 03 Mar 2004 09:37:34 -0600 Feel free to contact [EMAIL PROTECTED] if you can't cope with it. -- This mail was automatically generated by TrashScan v0.08
RE: FlowScript in 2.1.5-dev has gone tango uniform
i've noticed this problem in 2.1.2 and was someday going to have time to make a test case bug report. we use flowscript in subsitemaps only (not the root sitemap) and cocoon appears to only load the .js files listed in the first subsitemap requested. subsequent requests to other subsitemaps do not load the accompanying script files and you get a function not found. we had to work around this problem by listing all .js files in all subsitemaps (painful) -Original Message- From: Jeremy Quinn [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 03, 2004 5:52 AM To: [EMAIL PROTECTED] Subject: Re: FlowScript in 2.1.5-dev has gone tango uniform On 2 Mar 2004, at 21:59, Sylvain Wallez wrote: Jeremy Quinn wrote: On 2 Mar 2004, at 18:42, Jeremy Quinn wrote: To restate the basic problem : I have 2 URLs each served by a different sub-sitemap, each loading a different (single) flowscript. Each flowscript has some common function names, eg. index(). For debugging purposes, each function outputs it's name etc. to the flow log. load URL 1 : the correct script and function run fine load URL 2 : the same-named function in the flowscript file for URL 1 runs. Some further info: Rolling back to Cocoon 2.1.4 Release, has fixed the problem. I made changes to flowscript after 2.1.4 to remove the dependency of flowscript on Environment (it now uses only the Redirector). This led to changing the key used to store global scopes in the session (see FOM_JavaScriptInterpreter.getSessionScope()), but I don't know how it can produce what you encounter. I'll give a look at this tomorrow. Many thanks Sylvain. It appears like the first FlowScript that gets used, is the only FlowScript that gets used. regards Jeremy
RE: workflow block commited
Michael Wechner wrote: why don't we move it into the Lenya module and work there on the list which was suggested by Carsten? By me? :) sorry, for my bad english, but I meant the list with the issues to be addressed, or did somebody else suggest this list? Maybe I am confusing things ;-) Big +10 it seems to me that most Cocooners would like to move this block back to Lenya, at least for the moment. So I would suggest that we move it. Michi Carsten
RE: Gump
Stefano Mazzocchi [EMAIL PROTECTED] writes: Hunsberger, Peter wrote: Not sure, I think you're on your own on this one... don't worry, I'm so used to that it doesn't even hurt anymore He, he, if the bleeding edges feels comfortable, I think I finally understand why my spelling checked keep suggesting masochist every time it spell checks your last name... Seriously, there have got to be some mathematicians around that you can pose the question to?
RE: [HELP!] - RE: Java chokes on logkit-1.2.2
Carsten Ziegeler dijo: Sure, update the CVS (and please also the 2.2 version, it's the same jar). Maybe, sight. Now, interestingly, I don't have any problems with it - perhaps because I'm using this great and stable W2K and XP system? lol. :- Seriously, I will now update the logkit jar in both CVS 2.1 and 2.2. Best Regards, Antonio Gallardo
RE: workflow block commited
Michael Wechner wrote: why don't we move it into the Lenya module and work there on the list which was suggested by Carsten? By me? :) sorry, for my bad english, but I meant the list with the issues to be addressed, or did somebody else suggest this list? Maybe I am confusing things ;-) No, I confused them...someday I will really start learning english, promised (ten fingers crossed behind my back). Yes, the list is from me :) Big +10 it seems to me that most Cocooners would like to move this block back to Lenya, at least for the moment. So I would suggest that we move it. You have access to the Cocoon cvs. Do whatever you think is appropriate. Thanks Carsten
RE: [HELP!] - RE: Java chokes on logkit-1.2.2
Carsten Ziegeler dijo: Now, interestingly, I don't have any problems with it - perhaps because I'm using this great and stable W2K and XP system? joking-back mode How you dare to talk about Linux! In Linux it works fine using: ./cocoon.sh servlet or ./cocoon.sh servlet-debug The problem raises when Cocoon is deployed in a bugy container, ie: Tomcat. ... Oh well, ... it is another Apache bugy guys saga! ;-DD /joking-back mode Best Regards, Antonio Gallardo
Re: Gump
Hunsberger, Peter wrote: Stefano Mazzocchi [EMAIL PROTECTED] writes: Hunsberger, Peter wrote: Not sure, I think you're on your own on this one... don't worry, I'm so used to that it doesn't even hurt anymore He, he, if the bleeding edges feels comfortable, I think I finally understand why my spelling checked keep suggesting masochist every time it spell checks your last name... yep, you're not the first one to tell me that in my life ;-) Seriously, there have got to be some mathematicians around that you can pose the question to? The problem is not graph theory, it's algorithmical complexity: if it takes two months for gump to build cocoon, the whole thing wouldn't converge. I'll find the answer, don't worry. -- Stefano. smime.p7s Description: S/MIME Cryptographic Signature
Re: POI 2.5-final is out! Can I update? No license in distribution!
What we can do with this? Please comments, blames, or whatever, but please write something back! :-D Best Regards, Antonio Gallardo. Antonio Gallardo dijo: Hi: I downloaded the POI 2.5-final version I already tested it, but there is just one problem. The distribution has no License file!! I know these release is under the AS 2.0 but since this is no part of the distribution, what I can do? Also there is no license on the POI website. Please comment. Best Regards, Antonio Gallardo.
Re: [HELP!] - RE: Java chokes on logkit-1.2.2
Antonio Gallardo wrote: Carsten Ziegeler dijo: Now, interestingly, I don't have any problems with it - perhaps because I'm using this great and stable W2K and XP system? joking-back mode How you dare to talk about Linux! In Linux it works fine using: ./cocoon.sh servlet or ./cocoon.sh servlet-debug The problem raises when Cocoon is deployed in a bugy container, ie: Tomcat. telegraph-modeXP, Tomcat, Crash./telegraph-mode Vadim
RE: Gump
Stefano Mazzocchi [EMAIL PROTECTED] writes: snip silliness/ Seriously, there have got to be some mathematicians around that you can pose the question to? The problem is not graph theory, it's algorithmical complexity: if it takes two months for gump to build cocoon, the whole thing wouldn't converge. I think it's one and the same: find a graph traversal algorithm that works (in some reasonable O) for this case and you've solved the problem? Then again, maybe a genetic fitness type algorithm might work: assign each release a fitness based on how many other projects can compile with it and always try the version with the highest fitness first. Any release with a fitness some X dies off (or at least has a very low probability of being picked to breed with some other project). No graph traversal, just one big gene pool (so to speak). I'll find the answer, don't worry. No worries on this side, just some interest in observing the problem solving process
Re: E-mail account disabling warning.
On Wed, 3 Mar 2004, Sam Ruby wrote: Neither. This email contained: Return-Path: [EMAIL PROTECTED] From: [EMAIL PROTECTED] ... neither of which is subscribed to [EMAIL PROTECTED] From what I have read, ezmlm uses a separate SMTP 'SENDER' field, which isn't retained in the archive. My bets are that this field contained the value [EMAIL PROTECTED] No. Return-Path does capture the email address used by ezmlm to figure out if and when to send. As it turns out, [EMAIL PROTECTED] is able to post as he's in the allow database for that list. Brian
Re: POI 2.5-final is out! Can I update? No license in distribution!
Vadim Gritsenko dijo: Antonio Gallardo wrote: What we can do with this? Please comments, blames, or whatever, but please write something back! :-D See http://www.themorningnews.org/archives/how_to/the_nonexpert_lift.php BOB REFRESHING HIS EMAIL INBOX lol. So cool! Something similar happened to me with this mail. lol (again). PS Contact POI devs I already filled a bug report. Best Regards, Antonio Gallardo
Re: [VOTE] - Entry level JSDK 1.4 in Cocoon 2.2
* Ugo Cei [EMAIL PROTECTED] [2004-03-03 08:15]: Martin Holz wrote: does Sun regex offer any significant advantages over ORO or jakarta regexp ? Just curious. Probably just the fact that we'd ship one less JAR file. That was my point. (Though a change would break sitemaps depending on ORO specific patterns, if there is such a thing.) -- Alan / [EMAIL PROTECTED] / http://engrm.com/ aim/yim: alanengrm - icq: 228631855 - msn: [EMAIL PROTECTED]
RE: [ANN] don't forget FirstFriday!
And renaming woody, right? Carsten -Original Message- From: Bertrand Delacretaz [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 03, 2004 6:37 PM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: [ANN] don't forget FirstFriday! Hi all, Next Friday is FirstFriday, be there and squash'em bugs! We're also planning to work on the ASF license changes. More info at http://wiki.cocoondev.org/Wiki.jsp?page=FirstFriday -Bertrand - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Regexps (was Re: [VOTE] - Entry level JSDK 1.4 in Cocoon 2.2)
Alan wrote: * Ugo Cei [EMAIL PROTECTED] [2004-03-03 08:15]: Probably just the fact that we'd ship one less JAR file. That was my point. (Though a change would break sitemaps depending on ORO specific patterns, if there is such a thing.) At the cost of breaking some sitemaps, and since it's more or less clear that we're going to require JDK 1.4 for 2.2, I'll probably propose to drop Jakarta ORO in favour of the JDK's package (unless it's seriously broken) ... travel light. Ugo
Re: [VOTE] - Entry level JSDK 1.4 in Cocoon 2.2
The idea is to set JSDK 1.4 as the minimum supported JDK supported for the next major release 2.2 of Cocoon. Currently we are supporting also 1.3 but seems like few people is using it. but what about the maximum support JDK? I tried to compile with 1.5beta, but it didn't work. So I compiled with 1.4 and let it run with 1.5. The gc ist much better with 1.5! regards Christoph [EMAIL PROTECTED]
Re: E-mail account disabling warning.
On 03 Mar 2004, at 17:23, Brian Behlendorf wrote: On Wed, 3 Mar 2004, Sam Ruby wrote: Neither. This email contained: Return-Path: [EMAIL PROTECTED] From: [EMAIL PROTECTED] ... neither of which is subscribed to [EMAIL PROTECTED] From what I have read, ezmlm uses a separate SMTP 'SENDER' field, which isn't retained in the archive. My bets are that this field contained the value [EMAIL PROTECTED] No. Return-Path does capture the email address used by ezmlm to figure out if and when to send. As it turns out, [EMAIL PROTECTED] is able to post as he's in the allow database for that list. That's what I was afraid of, since I happened to know Andrew uses *both* addresses (or has been using them), at the very least in private mails sent to me. How can we defend ourselves from bots spamming the lists using subscribed or allowed addresses...? Or do we need to actively monitor/clean up stale entries in the allow list? /Steven -- Steven Noelshttp://outerthought.org/ Outerthought - Open Source Java XMLAn Orixo Member Read my weblog athttp://blogs.cocoondev.org/stevenn/ stevenn at outerthought.orgstevenn at apache.org
Re: [CForm]two question/suggestion about multi-value field
On Wed, Mar 03, 2004 at 12:47:37PM +, Joerg Heinicke wrote: Vadim Gritsenko vadim at reverycodes.com writes: I would think for the same reason one would otherwise wd:output instead of wd:field. In this case one would however need a wd:multivalueOutput widget. Yes, but why not type=output? because an output widget doesn't read its value from the request. With a normal (multivalue)field widget, the value can always be modified by adding the appropriate request parameters. Aha. Now this makes sense. +1 to multivalueoutput Instead of adding an additional output widget for every type of existing widgets would it not make more sense to add an attribute or additional element to the existing widgets similar to the binding's direction=load? Joerg +5 I never understood why we have an output widget which only serves as an output only version of the field widget, but did not have any support for output versions of the other widgets (repeaters, etc.) Lets fix this the right way like Joerg suggests and deprecate the separate, lonely, output widget. --Tim Larson
Re: POI 2.5-final is out! Can I update? No license in distribution!
On 03 Mar 2004, at 17:19, Vadim Gritsenko wrote: See http://www.themorningnews.org/archives/how_to/the_nonexpert_lift.php BOB REFRESHING HIS EMAIL INBOX ROFL - subscribed. /Steven -- Steven Noelshttp://outerthought.org/ Outerthought - Open Source Java XMLAn Orixo Member Read my weblog athttp://blogs.cocoondev.org/stevenn/ stevenn at outerthought.orgstevenn at apache.org
Re: Regexps (was Re: [VOTE] - Entry level JSDK 1.4 in Cocoon 2.2)
Ugo Cei wrote: Alan wrote: * Ugo Cei [EMAIL PROTECTED] [2004-03-03 08:15]: Probably just the fact that we'd ship one less JAR file. That was my point. (Though a change would break sitemaps depending on ORO specific patterns, if there is such a thing.) At the cost of breaking some sitemaps, and since it's more or less clear that we're going to require JDK 1.4 for 2.2, I'll probably propose to drop Jakarta ORO in favour of the JDK's package (unless it's seriously broken) ... travel light. IIRC, ORO is not used by sitemap. Rather, CForms has direct dependecies on ORO. PS I heard that 1.4.0 regexp was not good: http://marc.theaimsgroup.com/?l=jakarta-regexp-userm=106588023307749w=2 Vadim
RE: E-mail account disabling warning.
Steven Noels [EMAIL PROTECTED] writes: snip/ How can we defend ourselves from bots spamming the lists using subscribed or allowed addresses...? Or do we need to actively monitor/clean up stale entries in the allow list? The same format of message also hit xml-dev this morning. Again, bounced through the list. Don't think you can really defend against. Nothing says that they just won't use forged headers of a regular user. You could try and verify that the mail server corresponds to the sender domain but for people on the road that likely ain't going to cut it. Quarantining all attachments (and forcing explicit download) might be workable? I guess I'm going to have to stop using my regular e-mail address for this kind of thing and start maintaining yet another mail box (5 so far). So far our virus checkers have caught all this stuff but sooner or later someone's going to find a hole that doesn't rely on social engineering and doesn't get caught by the filters...
Re: cvs commit: cocoon-2.1/src/blocks/woody/java/org/apache/cocoon/woody/binding RepeaterJXPathBinding.java
On 03.03.2004 20:47, [EMAIL PROTECTED] wrote: joerg 2004/03/03 11:47:35 Modified:src/blocks/woody/java/org/apache/cocoon/woody/binding RepeaterJXPathBinding.java Log: clean up: removed unused code (for reverting changes we have CVS, so please remove old stuff always), JavaDoc added, comments fixed; changed isNullAllListElements() = isAnyListElementNotNull(): the duplicate negation at usage time breaks my brain ;-) For one case there is now another behaviour: if the list is empty now false will be returned (as before, but there the function tested the opposite). I don't know if this breaks anything, it was just for logical reasons: isNullAllListElements() returning false I expect to get one list element which is not null, which is not the case for empty list. Antonio, I guess you are the only one using it at the moment. Can you test it please? Joerg
Re: [ANN] don't forget FirstFriday!
Le Mercredi, 3 mars 2004, à 19:06 Europe/Zurich, Carsten Ziegeler a écrit : And renaming woody, right? right - forgot this one, sorry. -Bertrand
[cforms] Internationalization of custom error messages
Hey folks -- I'm using an output widget to display the error message that results from some custom validation code. The problem is that I would like to internationalize the error message like the other validation-messages. Unfortunately, the output widget just dumps the value out to the page. Is there any way to achieve this with the current output widget, or is there a better way to serve the custom error messages? If not, I propose an i18n-output widget (or an option to the existing output widget?) that will render the value of the widget wrapped in 18n:text tags so the I18nTransformer can translate with the rest of the form. Also, on the subject of cforms i18n, it would also be handy if the widget's label was included as a i18n parameter for the standard validation-errors. This way instead of just This field is required you could have Email Address is required. cheers, -steve
Re: FOP with embeded SVG doesn't render at correct size in Cocoon
Joerg Heinicke wrote: It's the 0.20.5 release, but built with our Batik 1.5. I guess the FOP people must clarify if this made any sense or not. IIRC we had the released Fop jar in our CVS and got complaints for problems with Batik after Batik update. So we rebuilt Fop with this new Batik and the problems seemed to be gone. Odd. If it compiles, it shouldn't complain about missing methods at run time. There may be behaviour changes though, has someone checked the Batik change log? J.Pietschmann
Re: [VOTE] - Entry level JSDK 1.4 in Cocoon 2.2
Christoph Gaffga wrote: The idea is to set JSDK 1.4 as the minimum supported JDK supported for the next major release 2.2 of Cocoon. Currently we are supporting also 1.3 but seems like few people is using it. but what about the maximum support JDK? I tried to compile with 1.5beta, but it didn't work. I don't think didn't work gives us enough info on how to fix it :-) So I compiled with 1.4 and let it run with 1.5. The gc ist much better with 1.5! Of course, we should try to work on all the upper versions as well... as long as it's our fault and not theirs, though. -- Stefano. smime.p7s Description: S/MIME Cryptographic Signature
Re: [CForms] Support for multipe unique-row-id in Repeater
wb:repeater id=myRepeaterId parent-path=. row-path=TheRowPath wb:unique-row wb:unique-field id=myId1 path=myId1/ wb:unique-field id=myId2 path=myId2/ /wb:unique-row wb:on-bind wb:value id=myId1 path=myId1/ wb:value id=myId2 path=myId2/ wb:value id=field1 path=field1/ wb:value id=field2 path=field2/ /wb:on-bind /wb:repeater It was a good idea to replace the both attributes with a more sophisticated XML structure, but it is a bad realization in my opinion. rant The above is redundant, irritating (unique-field is not really correctly named, is it?) and (because of the more java code we need) bloated. On the one hand the redundancy above is obvious, on the other hand sentences like This unique-field element ... The id and path attributes have the same meaning as in wb:value. ... The wd:convertor ... For more info see the description of this element in wb:value. will get me suspicious. Why the §$% we need an additional XML element if we have already one that seems to be perfect for it: wb:value as the frequent references above show? Why do we have to specify @id and @path twice for those identifying elements? And so on. Such changes should be well thought out, otherwise we have to change to much later on when sophisticating our XML elements. And the latter we do this the more we will break. Unfortunately not many Woody developers are really active on the list at the moment. /rant Another thing that I don't like is the new restriction: Note: This binding is only active in the 'load' operation, so specifying the direction=save is meaningless. Sorry, Antonio, but you seem to be often the targets of my rants ... NOTE: The old style is also supported. You don't need to rewrite your code. But I think we can also deprecate the old way (using attributes). I would not let live these deprecated attributes that long. Just like we did it for @readonly = @direction I would remove it as fast as possible and therefore do a big ANNOUNCEMENT on the users list. BTW, the wd:convertor element can also be deprecated and removed as it is used in combination with the unique-row-id. Joerg
Re: E-mail account disabling warning.
Steven Noels wrote: On 03 Mar 2004, at 17:23, Brian Behlendorf wrote: On Wed, 3 Mar 2004, Sam Ruby wrote: Neither. This email contained: Return-Path: [EMAIL PROTECTED] From: [EMAIL PROTECTED] ... neither of which is subscribed to [EMAIL PROTECTED] From what I have read, ezmlm uses a separate SMTP 'SENDER' field, which isn't retained in the archive. My bets are that this field contained the value [EMAIL PROTECTED] No. Return-Path does capture the email address used by ezmlm to figure out if and when to send. As it turns out, [EMAIL PROTECTED] is able to post as he's in the allow database for that list. That's what I was afraid of, since I happened to know Andrew uses *both* addresses (or has been using them), at the very least in private mails sent to me. How can we defend ourselves from bots spamming the lists using subscribed or allowed addresses...? the only way is to require everybody to sign their email. But enforcing this would be a serious PITA. Or do we need to actively monitor/clean up stale entries in the allow list? this doesn't really reduce the problem. -- Stefano. smime.p7s Description: S/MIME Cryptographic Signature
Re: Gump
Stefano Mazzocchi stefano at apache.org writes: ... gump as complete replacement for jars.xml ... Is our gump descriptor that bad maintained? Some time ago we also got gump error messages to the list, now we get those only from persons outside of Cocoon. What's the benefit of gump when we don't use it correctly? Gump has not been able to run cocoon for the last 6 months at least, due to unmet dependencies. As a result, our decriptor is basically dead because we haven't been nagged for that period of time. The gump community is working hard to make this possible again, but this is very hard work and takes a lot of time and patience. My proposal (that the board accepted) to move gump to top level status was also to bring more visibility and make projects being more gump-friendly, we'll see how this goes. I have a RT ready for gump that would allow to solve these issues... but I need to work more on this since it appears to be a pretty tough computational problem of graph analysis. But this is much more than I want to solve with it at the moment. I just want to replace the jars.xml with the gump.xml. We still can have our check jars so that we are nagged if gump is broken (at least for this issue). At least we avoid the duplicate maintenance of jars.xml and gump.xml that exists at the moment. One day Cocoon and Gump nicely plays together again, we can give all to Gump and remove our specific checking stuff. Short steps towards a big aim :) WDYT? Joerg PS: Arrgghh! This nasty gmane.org: You seem to be top-posting. Don't do that. I only had ... gump ... without any infront.
Re: [QVote] Where to put licenses?
On 03.03.2004 14:42, Carsten Ziegeler wrote: But what I absolutely don't like is the adding of the package version to the license file. What's it for? A comparison between package-xyz-1.23.45.jar and package-xyz.license.txt can also be done without any problem. It's useless remove and readd of files to CVS IMO. That's simple. As we learned recently, the license might change between versions! So having the version number in the license name will more clearly show that updating a jar has to go in combination with (perhaps) updating the license. If e.g. someone of us had updated Jisp to 3.0 I bet that noone would ever have noticed that we actually couldn't use that version as the jisp.license we had in our CVS was still compatible. A valid point as it attracts attention Adding this logic to the test script/check-jars.xsl/gump or what ever is much more clever. As soon as there is a script we *could* remove the version number. But I think not any sooner. The script would not help with the above point. Or do you want to check the content of the license file?? This would mean an either or, not an it depends. Joerg
Re: [cforms] Internationalization of custom error messages
On Wed, 2004-03-03 at 22:12, Steve Krulewitz wrote: Hey folks -- I'm using an output widget to display the error message that results from some custom validation code. The problem is that I would like to internationalize the error message like the other validation-messages. Unfortunately, the output widget just dumps the value out to the page. Is there any way to achieve this with the current output widget, or is there a better way to serve the custom error messages? If not, I propose an i18n-output widget (or an option to the existing output widget?) that will render the value of the widget wrapped in 18n:text tags so the I18nTransformer can translate with the rest of the form. Do you know about the wd:messages widget? Should do what you want. There's a sample that shows how to use it. snip/ -- Bruno Dumon http://outerthought.org/ Outerthought - Open Source, Java XML Competence Support Center [EMAIL PROTECTED] [EMAIL PROTECTED]
RE: [QVote] Where to put licenses?
Joerg Heinicke wrote: On 03.03.2004 14:42, Carsten Ziegeler wrote: But what I absolutely don't like is the adding of the package version to the license file. What's it for? A comparison between package-xyz-1.23.45.jar and package-xyz.license.txt can also be done without any problem. It's useless remove and readd of files to CVS IMO. That's simple. As we learned recently, the license might change between versions! So having the version number in the license name will more clearly show that updating a jar has to go in combination with (perhaps) updating the license. If e.g. someone of us had updated Jisp to 3.0 I bet that noone would ever have noticed that we actually couldn't use that version as the jisp.license we had in our CVS was still compatible. A valid point as it attracts attention Adding this logic to the test script/check-jars.xsl/gump or what ever is much more clever. As soon as there is a script we *could* remove the version number. But I think not any sooner. The script would not help with the above point. Or do you want to check the content of the license file?? This would mean an either or, not an it depends. Exactly my point (although I might not have made it that clear), a script can't test the contents of the license, that's why I wrote we *could* remove the version number. I still think, having the version numbers helps more than any script can do. If you're using scripts you tend to rely on the scripts without assuring that the scripts really do what you want. Anyways, it seems noone is really against moving all licenses back to the legal directory and if someone comes up with a script we will see if it helps or not. Carsten
Re: E-mail account disabling warning.
Is there any digital signer anyone recommends? What is the procedure? Can it be set automatic or is it something to remember and do everytime? -Thanks. - Original Message - From: Stefano Mazzocchi [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Wednesday, March 03, 2004 4:24 PM Subject: Re: E-mail account disabling warning. Steven Noels wrote: On 03 Mar 2004, at 17:23, Brian Behlendorf wrote: On Wed, 3 Mar 2004, Sam Ruby wrote: Neither. This email contained: Return-Path: [EMAIL PROTECTED] From: [EMAIL PROTECTED] ... neither of which is subscribed to [EMAIL PROTECTED] From what I have read, ezmlm uses a separate SMTP 'SENDER' field, which isn't retained in the archive. My bets are that this field contained the value [EMAIL PROTECTED] No. Return-Path does capture the email address used by ezmlm to figure out if and when to send. As it turns out, [EMAIL PROTECTED] is able to post as he's in the allow database for that list. That's what I was afraid of, since I happened to know Andrew uses *both* addresses (or has been using them), at the very least in private mails sent to me. How can we defend ourselves from bots spamming the lists using subscribed or allowed addresses...? the only way is to require everybody to sign their email. But enforcing this would be a serious PITA. Or do we need to actively monitor/clean up stale entries in the allow list? this doesn't really reduce the problem. -- Stefano.
Re: [QVote] Where to put licenses?
On 03.03.2004 22:51, Carsten Ziegeler wrote: Anyways, it seems noone is really against moving all licenses back to the legal directory and if someone comes up with a script we will see if it helps or not. The script (or the adding of license to gump, this is what I would prefer much more) is just for seeing if a license file exists for the jar. Whether it's the correct one must still be done by hand of course. Maybe additional functionality like license content checking will be added to gump, but we should not do this with a proprietary script. Joerg
Re: Regexps (was Re: [VOTE] - Entry level JSDK 1.4 in Cocoon 2.2)
Vadim Gritsenko wrote: IIRC, ORO is not used by sitemap. Rather, CForms has direct dependecies on ORO. Might be worthwile checking if 1.4 regexps are good enough for the task. PS I heard that 1.4.0 regexp was not good: http://marc.theaimsgroup.com/?l=jakarta-regexp-userm=106588023307749w=2 Oh, well, since 1.4.1 fixes most bugs, we can mandate 1.4.1 or even 1.4.2 ;-). Ugo
Re: [CForms] Support for multipe unique-row-id in Repeater
On Wed, 2004-03-03 at 22:24, Joerg Heinicke wrote: wb:repeater id=myRepeaterId parent-path=. row-path=TheRowPath wb:unique-row wb:unique-field id=myId1 path=myId1/ wb:unique-field id=myId2 path=myId2/ /wb:unique-row wb:on-bind wb:value id=myId1 path=myId1/ wb:value id=myId2 path=myId2/ wb:value id=field1 path=field1/ wb:value id=field2 path=field2/ /wb:on-bind /wb:repeater It was a good idea to replace the both attributes with a more sophisticated XML structure, but it is a bad realization in my opinion. rant The above is redundant, irritating (unique-field is not really correctly named, is it?) and (because of the more java code we need) bloated. On the one hand the redundancy above is obvious, on the other hand sentences like This unique-field element ... The id and path attributes have the same meaning as in wb:value. ... The wd:convertor ... For more info see the description of this element in wb:value. will get me suspicious. Why the §$% we need an additional XML element if we have already one that seems to be perfect for it: wb:value as the frequent references above show? Why do we have to specify @id and @path twice for those identifying elements? And so on. Such changes should be well thought out, otherwise we have to change to much later on when sophisticating our XML elements. And the latter we do this the more we will break. Unfortunately not many Woody developers are really active on the list at the moment. /rant I don't have the time and energy currently to follow all these developments, but thanks for keeping a critical eye on it. -- Bruno Dumon http://outerthought.org/ Outerthought - Open Source, Java XML Competence Support Center [EMAIL PROTECTED] [EMAIL PROTECTED]
[OT] The Non-Expert (was Re: POI 2.5-final is out! Can I update? No license in distribution!)
Steven Noels wrote: On 03 Mar 2004, at 17:19, Vadim Gritsenko wrote: See http://www.themorningnews.org/archives/how_to/the_nonexpert_lift.php BOB REFRESHING HIS EMAIL INBOX ROFL - subscribed. /Steven Subscribed? Where's the RSS feed? Ugo
Re: Gump
Joerg Heinicke wrote: Stefano Mazzocchi stefano at apache.org writes: ... gump as complete replacement for jars.xml ... Is our gump descriptor that bad maintained? Some time ago we also got gump error messages to the list, now we get those only from persons outside of Cocoon. What's the benefit of gump when we don't use it correctly? Gump has not been able to run cocoon for the last 6 months at least, due to unmet dependencies. As a result, our decriptor is basically dead because we haven't been nagged for that period of time. The gump community is working hard to make this possible again, but this is very hard work and takes a lot of time and patience. My proposal (that the board accepted) to move gump to top level status was also to bring more visibility and make projects being more gump-friendly, we'll see how this goes. I have a RT ready for gump that would allow to solve these issues... but I need to work more on this since it appears to be a pretty tough computational problem of graph analysis. But this is much more than I want to solve with it at the moment. I just want to replace the jars.xml with the gump.xml. We still can have our check jars so that we are nagged if gump is broken (at least for this issue). At least we avoid the duplicate maintenance of jars.xml and gump.xml that exists at the moment. One day Cocoon and Gump nicely plays together again, we can give all to Gump and remove our specific checking stuff. Short steps towards a big aim :) WDYT? +1 my thinking are just more gump related than cocoon-related anyway... besides, the more I work with graphs the more I see graphs everywhere so beware :-) -- Stefano. smime.p7s Description: S/MIME Cryptographic Signature
Re: E-mail account disabling warning.
Hi, On 3 Mar 2004, at 19:12, Steven Noels wrote: That's what I was afraid of, since I happened to know Andrew uses *both* addresses (or has been using them), at the very least in private mails sent to me. Yup, I was. Now I'm happily living in mac-land, just [EMAIL PROTECTED] Do I need to unsub savs@ and resub as [EMAIL PROTECTED] If so, where's the 'allow' list, as I should remove myself ... Just an unfortunate coincidence that the virus spoofed a moderator :-( Andrew. -- Andrew Savory, Managing Director, Luminas Limited Tel: +44 (0)870 741 6658 Fax: +44 (0)700 598 1135 Web: http://www.luminas.co.uk/ Orixo alliance: http://www.orixo.com/
RE: E-mail account disabling warning.
Andrew Savory [EMAIL PROTECTED] writes: snip/ Just an unfortunate coincidence that the virus spoofed a moderator :-( Who says it was a coincidence? (Hey, even a paranoid can be a target of the malicious.)
RE: What is the best Java framework for Web development?
Ugo Cei [EMAIL PROTECTED] writes: Well, I know this is silly, but why not? http://www.manageability.org/polls/what-is-the-best-java-web- framework Definitely silly, far too open ended, but you know who got my vote ;-)
Re: Default ProcessingPipline implementation?
On 29.02.2004 14:53, Unico Hommes wrote: See the root sitemap where it says: map:pipes default=caching ;-) Unico And what happens if I dont specify an element map:pipes/ in the root sitemap? ;-) Which ProcessingPipeline is will be used then? AFAICT this would generate an error. Doesn't it? Yes, it does. I came across this when setting up my first real life project with Cocoon 2.1. I got a nearly meaningless error message (something like null hint) when moving my block out of the Cocoon deployment to its own place, so the block subsitemap became a root sitemap. What I want to point at is the poor error message. AFAIK it's much more expressive e.g. when the default generator is not set. Is it possible to express a real error message for map:pipes too? I guess so, just need somebody who does this for me :) Joerg
Re: cvs commit: cocoon-2.1/src/blocks/woody/java/org/apache/cocoon/woody/bindingRepeat erJXPathBinding.java
Joerg Heinicke dijo: On 03.03.2004 20:47, [EMAIL PROTECTED] wrote: joerg 2004/03/03 11:47:35 Modified:src/blocks/woody/java/org/apache/cocoon/woody/binding RepeaterJXPathBinding.java Log: clean up: removed unused code (for reverting changes we have CVS, so please remove old stuff always), JavaDoc added, comments fixed; changed isNullAllListElements() = isAnyListElementNotNull(): the duplicate negation at usage time breaks my brain ;-) For one case there is now another behaviour: if the list is empty now false will be returned (as before, but there the function tested the opposite). I don't know if this breaks anything, it was just for logical reasons: isNullAllListElements() returning false I expect to get one list element which is not null, which is not the case for empty list. Antonio, I guess you are the only one using it at the moment. Can you test it please? I tested it before committing. I can not assure it is totaly bug free. What I can said is I will use it in many places. If there is a bug it will be showed. By definition , an empty List is not allowed. If the RepeaterJXPathBindingBuilder detect there not exist any definition of unique-row in the old and new style it throws an exception. This is the same as it did before. isNullAllListElements() - This method return true is all the elements inside the List points to null (This is similar as it was tested before). The idea is to catch cases where is a new row. I know , there are many code enhancements to be done. I just posted an initial code how this can work. Now we can enhance it. ie: ValueJXPathBinding and UniqueFieldJXPathBinding are very similar a enhancement can be using a base class for both. Best Regards, Antonio Gallardo
Re: cvs commit: cocoon-2.1/src/blocks/woody/java/org/apache/cocoon/woody/binding RepeaterJXPathBinding.java
[EMAIL PROTECTED] dijo: joerg 2004/03/03 11:47:35 Modified:src/blocks/woody/java/org/apache/cocoon/woody/binding RepeaterJXPathBinding.java Log: clean up: removed unused code (for reverting changes we have CVS, so please remove old stuff always), JavaDoc added, comments fixed; changed isNullAllListElements() = isAnyListElementNotNull(): the duplicate negation at usage time breaks my brain ;-) This depends of the POV you see it: isNullAllListElements() - This is not a negation. It check if : All elements on the List are null. Where is the negation? isAnyListElementNotNull() - Here is a negation Not null :-D Best Regards, Antonio Gallardo.
RE: [QVote] Where to put licenses?
Carsten Ziegeler dijo: Joerg Heinicke wrote: On 03.03.2004 14:42, Carsten Ziegeler wrote: But what I absolutely don't like is the adding of the package version to the license file. What's it for? A comparison between package-xyz-1.23.45.jar and package-xyz.license.txt can also be done without any problem. It's useless remove and readd of files to CVS IMO. That's simple. As we learned recently, the license might change between versions! So having the version number in the license name will more clearly show that updating a jar has to go in combination with (perhaps) updating the license. If e.g. someone of us had updated Jisp to 3.0 I bet that noone would ever have noticed that we actually couldn't use that version as the jisp.license we had in our CVS was still compatible. A valid point as it attracts attention Adding this logic to the test script/check-jars.xsl/gump or what ever is much more clever. As soon as there is a script we *could* remove the version number. But I think not any sooner. The script would not help with the above point. Or do you want to check the content of the license file?? This would mean an either or, not an it depends. Exactly my point (although I might not have made it that clear), a script can't test the contents of the license, that's why I wrote we *could* remove the version number. I still think, having the version numbers helps more than any script can do. If you're using scripts you tend to rely on the scripts without assuring that the scripts really do what you want. Anyways, it seems noone is really against moving all licenses back to the legal directory and if someone comes up with a script we will see if it helps or not. I really don't understand why the license files are travelling across all the source code. :-D Before committing any jar, we review the license to check changes against the old one. The peer review is the best we can do. In short, licenses in legal dir. Best Regards, Antonio Gallardo.
Re: [CForms] Support for multipe unique-row-id in Repeater
Joerg Heinicke dijo: wb:repeater id=myRepeaterId parent-path=. row-path=TheRowPath wb:unique-row wb:unique-field id=myId1 path=myId1/ wb:unique-field id=myId2 path=myId2/ /wb:unique-row wb:on-bind wb:value id=myId1 path=myId1/ wb:value id=myId2 path=myId2/ wb:value id=field1 path=field1/ wb:value id=field2 path=field2/ /wb:on-bind /wb:repeater It was a good idea to replace the both attributes with a more sophisticated XML structure, but it is a bad realization in my opinion. I posted a proposal for changes before I started to code it. Nobody answer (a silent aproval?), then I started the coding. Only Tim answered and give me his OK. The good news is it is not too hard to change the code and/or tag names. I agree with you: we can do it far better. But how to start if nobody cares about this change? On the other way I don't wanted to have this as another aproved change without implementation. Seems like coding is a good tool to put little pressure on other committers to review a proposal. Your comments are very welcomed. ;-D rant The above is redundant, irritating (unique-field is not really correctly named, is it?) Not sure, we can change it, I don't got long time thinking in the right name. I am willing to change it for a more descriptive name. Can you give us a suggestion? and (because of the more java code we need) bloated. ^^^ (Don't understand the word). On the one hand the redundancy above is obvious, The redundancy was always there (using the old attributes you will see it), maybe now it is more clear (evident) than before on the other hand sentences like This unique-field element ... The id and path attributes have the same meaning as in wb:value. ... The wd:convertor ... For more info see the description of this element in wb:value. will get me suspicious. Why the §$% we need an additional XML element if we have already one that seems to be perfect for it: wb:value as the frequent references above show? I thought about this too. The wb:unique-field description don't need all the attributes of a wb:value element. After thinking on it, I thought it would be better (even from a descriptive POV) to have another tag describing clearly what the wb:unique-field is intendend for. It is a striped down version of wb:value and conceptually they are diferent. On the other side I don't mean to change the binding to much to allow a back compatibility with the old approach. Why do we have to specify @id and @path twice for those identifying elements? And so on. Not necesary at all. Note, sometime you don't define (or want to define) a wb:value inside the wb:on-binding the key values. So it is valid too: wb:repeater id=myRepeaterId parent-path=. row-path=TheRowPath wb:unique-row wb:unique-field id=myId1 path=myId1/ wb:unique-field id=myId2 path=myId2/ /wb:unique-row wb:on-bind wb:value id=field1 path=field1/ wb:value id=field2 path=field2/ /wb:on-bind /wb:repeater Such changes should be well thought out, otherwise we have to change to much later on when sophisticating our XML elements. They are, it cannot interefere with a more complex XML elements. Less is sometimes better than nothing. It is just a first step. If this first step was not taken we will not being discussing this issue at all. ;-) And the latter we do this the more we will break. Unfortunately not many Woody developers are really active on the list at the moment. Because of short of time I don't posted this change to the user list. It is my fault. Now, I am not sure if I can post on the user list about the change since this mail looks like a total non-approval of the proposal. Then why to ring a bell to the users? We can easily undo all the changes and nothing will happens, then from a POV of users: it never happen at all. :-) /rant Another thing that I don't like is the new restriction: Note: This binding is only active in the 'load' operation, so specifying the direction=save is meaningless. This is another thing that was there all the time, even before the changes. I just replicated the same approach at it was before. The change is just related to have multivalue unique fields instead of just one (old style). Nothing more nor nothing less. Sorry, Antonio, but you seem to be often the targets of my rants ... No problem at all. This help us to improve Cocoon. I am glad this happen, keep on it. ;-) The worse to me, will be when nobody will care on the work I do. NOTE: The old style is also supported. You don't need to rewrite your code. But I think we can also deprecate the old way (using attributes). I would not let live these deprecated attributes that long. Just like we did it for @readonly = @direction I would remove it as fast as possible and therefore do a big ANNOUNCEMENT on the users list. OK. But I
[JCS] Test drive
Hi: How to test drive the current JCS store implementation? Best Regards, Antonio Gallardo
RE: [JCS] Test drive
Hiya, What exactly would you like to know? There's a readme in there that should provide a fair amount of detail, if not - just flick me an email and I'll walk you through it :) I still need to send in a couple compiled of classes for it - don't worry Carsten, I haven't forgotten :) Let me know :) Corin -Original Message- From: Antonio Gallardo [mailto:[EMAIL PROTECTED] Sent: Thursday, 4 March 2004 5:48 p.m. To: [EMAIL PROTECTED] Subject: [JCS] Test drive Hi: How to test drive the current JCS store implementation? Best Regards, Antonio Gallardo CAUTION: This e-mail and any attachment(s) contains information that is intended to be read only by the named recipient(s). It may contain information that is confidential, proprietary or the subject of legal privilege. This information is not to be used by any other person and/or organisation. If you are not the intended recipient, please advise us immediately and delete this e-mail from your system. Do not use any information contained in it. For more information on the Television New Zealand Group, visit us online at http://www.tvnz.co.nz
RE: [JCS] Test drive
Hi Corin, I compiled JCS yesterday myself, so you don't need to send it. I forgot to committ your README, will do that asap. Carsten -Original Message- From: Corin Moss [mailto:[EMAIL PROTECTED] Sent: Thursday, March 04, 2004 5:52 AM To: [EMAIL PROTECTED] Subject: RE: [JCS] Test drive Hiya, What exactly would you like to know? There's a readme in there that should provide a fair amount of detail, if not - just flick me an email and I'll walk you through it :) I still need to send in a couple compiled of classes for it - don't worry Carsten, I haven't forgotten :) Let me know :) Corin -Original Message- From: Antonio Gallardo [mailto:[EMAIL PROTECTED] Sent: Thursday, 4 March 2004 5:48 p.m. To: [EMAIL PROTECTED] Subject: [JCS] Test drive Hi: How to test drive the current JCS store implementation? Best Regards, Antonio Gallardo CAUTION: This e-mail and any attachment(s) contains information that is intended to be read only by the named recipient(s). It may contain information that is confidential, proprietary or the subject of legal privilege. This information is not to be used by any other person and/or organisation. If you are not the intended recipient, please advise us immediately and delete this e-mail from your system. Do not use any information contained in it. For more information on the Television New Zealand Group, visit us online at http://www.tvnz.co.nz
Watch out for viruses originating from the fake support@apache.org address!
On 03 Mar 2004, at 10:19, [EMAIL PROTECTED] wrote: Dear user of Apache.org gateway e-mail server, Your e-mail account has been temporary disabled because of unauthorized access. I have been chatting with apmail about this clever social engineering spam which now unfortunately has been moderated through on the list: even though it looks legitimate, especially since the ASF is cleaning out committer accounts with no valid CLA on file as-we-speak, this mail *is* infected with a virus. I guess it was clear to most of you already, but please delete this mail immediately. /Steven -- Steven Noelshttp://outerthought.org/ Outerthought - Open Source Java XMLAn Orixo Member Read my weblog athttp://blogs.cocoondev.org/stevenn/ stevenn at outerthought.orgstevenn at apache.org
[ANN] don't forget FirstFriday!
Hi all, Next Friday is FirstFriday, be there and squash'em bugs! We're also planning to work on the ASF license changes. More info at http://wiki.cocoondev.org/Wiki.jsp?page=FirstFriday -Bertrand
What is the best Java framework for Web development?
Well, I know this is silly, but why not? http://www.manageability.org/polls/what-is-the-best-java-web-framework Ugo
