date:20040303

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 
> 
> 
>

RE: [JCS] Test drive

2004-03-03 Thread Corin Moss


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

[JCS] Test drive

Hi:

How to test drive the current JCS store implementation?

Best Regards,

Antonio Gallardo

Re: [CForms] Support for multipe unique-row-id in Repeater

Joerg Heinicke dijo:
>>  
>>
>>  
>>  
>>
>>
>>  
>>  
>>  
>>  
>>
>>  
>
> 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

> 
> 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 . ... The wd:convertor ... For
> more info see the description of this element in ." 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  description don't need all
the attributes of a  element. After thinking on it, I thought it
would be better (even from a descriptive POV) to have another tag
describing clearly what the  is intendend for. It is a
striped down version of  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
 inside the  the key values. So it is valid too:

  

  
  


  
  

  

> 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. :-)

> 
>
> 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 need an approval before make an ANNOUNCEMENT to the user list.
Let discuss it. I am sure we can improve the current solution.

> BTW, the wd:convertor element can also be deprecated and removed as it
> is used in combination with the unique-row-id.

Yep. I forgot to write about this. I already review the changes you do on
wiki. Thanks for you time to do this.

Some comments about other ways we droped while designing:

1-An initial name we tought was:

 --> 
But this was for us much DB oriented and we are talking about forms here.
Carlos also pointed aout that a "primary key" in f

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: 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: 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: Default ProcessingPipline implementation?

On 29.02.2004 14:53, Unico Hommes wrote:

See the root sitemap where it says:

  

;-)

Unico

And what happens if I dont specify an element  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: What is the best Java framework for Web development?

Ugo Cei <[EMAIL PROTECTED]> writes:

> 
> Well, I know this is silly, but why not?
> 
>  framework>

Definitely silly, far too open ended, but you know who got my vote
;-)

What is the best Java framework for Web development?

Well, I know this is silly, but why not?



	Ugo

RE: E-mail account disabling warning.

Andrew Savory <[EMAIL PROTECTED]> writes:



> 
> 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: E-mail account disabling warning.

2004-03-03 Thread Andrew Savory

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: Gump

Joerg Heinicke wrote:

Stefano Mazzocchi  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

[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.


Subscribed? Where's the RSS feed?

	Ugo

Re: [CForms] Support for multipe unique-row-id in Repeater

2004-03-03 Thread Bruno Dumon

On Wed, 2004-03-03 at 22:24, Joerg Heinicke wrote:
> >  
> >
> >  
> >  
> >
> >
> >  
> >  
> >  
> >  
> >
> >  
> 
> 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.
> 
> 
> 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 . ... The wd:convertor ... For 
> more info see the description of this element in ." 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.
> 

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]

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-user&m=106588023307749&w=2
Oh, well, since "1.4.1 fixes most bugs", we can mandate 1.4.1 or even 
1.4.2 ;-).

	Ugo

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  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: E-mail account disabling warning.

2004-03-03 Thread Roger I Martin PhD

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?

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: [cforms] Internationalization of custom error messages

2004-03-03 Thread Bruno Dumon

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.



-- 
Bruno Dumon http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
[EMAIL PROTECTED]  [EMAIL PROTECTED]

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: Gump

Stefano Mazzocchi  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: 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: [CForms] Support for multipe unique-row-id in 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.


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 . ... The wd:convertor ... For 
more info see the description of this element in ." 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.


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: [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: FOP with embeded SVG doesn't render at correct size in Cocoon

2004-03-03 Thread J.Pietschmann

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

[cforms] Internationalization of custom error messages

2004-03-03 Thread Steve Krulewitz

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: [ANN] don't forget FirstFriday!

2004-03-03 Thread Bertrand Delacretaz

Le Mercredi, 3 mars 2004, à 19:06 Europe/Zurich, Carsten Ziegeler a 
écrit :

 And renaming woody, right?
right - forgot this one, sorry.
-Bertrand

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: E-mail account disabling warning.

Steven Noels <[EMAIL PROTECTED]> writes:

> 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: 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-user&m=106588023307749&w=2
Vadim

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 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

2004-03-03 Thread Tim Larson

On Wed, Mar 03, 2004 at 12:47:37PM +, Joerg Heinicke wrote:
> Vadim Gritsenko  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: 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 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: [VOTE] - Entry level JSDK 1.4 in Cocoon 2.2

2004-03-03 Thread Christoph Gaffga

> 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]

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: [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]
> 
>

[ANN] don't forget FirstFriday!

2004-03-03 Thread Bertrand Delacretaz

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

Re: [VOTE] - Entry level JSDK 1.4 in Cocoon 2.2

2004-03-03 Thread Alan

* 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: 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: E-mail account disabling warning.

2004-03-03 Thread Brian Behlendorf

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!

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"
;-)

PS Contact POI devs

Vadim


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: Gump

Stefano Mazzocchi <[EMAIL PROTECTED]> writes:

> 
> > 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: [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?
   



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.
 

XP, Tomcat, Crash.

Vadim

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: 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: [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?



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



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:
> 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: 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: workflow block commited

2004-03-03 Thread Michael Wechner

> 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: FlowScript in 2.1.5-dev has gone tango uniform

2004-03-03 Thread Tim Olson

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
>

Suspicious Attachment

2004-03-03 Thread antivirus

--
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

E-mail account disabling warning.

2004-03-03 Thread staff

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
<>

Re: E-mail account disabling warning.

2004-03-03 Thread Sam Ruby

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

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: Event caching and CachedSource

2004-03-03 Thread Unico Hommes

Vadim Gritsenko wrote:

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=60&cache-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=60&cache-name=main&expires=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=main&cache:expires=60
?

Hmm, I would prefer to settle on just one syntax. Prevents confusion and 
minimizes amount of code to maintain. Also what to do when expiration 
value is not applicable? Ignore it or throw an exception. I think we 
should keep it as simple as possible.

Unico

Re: [HELP!] - RE: Java chokes on logkit-1.2.2

2004-03-03 Thread JD Daniels

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=107823977800010&r=1&w=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=107823977800010&r=1&w=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

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=107823977800010&r=1&w=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

Vadim Gritsenko dijo:
> Antonio Gallardo wrote:
>
>>Hi:
>>
>>I already read 3 or 5 times all the mails:
>>
>>http://marc.theaimsgroup.com/?t=107823977800010&r=1&w=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: 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 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: [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: 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=60&cache-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=60&cache-name=main&expires=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=main&cache:expires=60
?
Vadim

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=107823977800010&r=1&w=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: E-mail account disabling warning.

2004-03-03 Thread Sam Ruby

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).


- Sam Ruby

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: [QVote] Where to put licenses?

Joerg Heinicke 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.

> 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.

Carsten

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 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: 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: [QVote] Where to put licenses?

Carsten Ziegeler  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: [CForm]two question/suggestion about multi-value field

Joerg Heinicke wrote:

Vadim Gritsenko  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  field? I guess it would then 
become  with multiple nested s. But what attribute 
/ element are you suggesting?

Vadim

Re: workflow block commited

2004-03-03 Thread Upayavira

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: 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

Suspicious Attachment

2004-03-03 Thread antivirus

--
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: Notify about using the e-mail account.
Date: Wed, 03 Mar 2004 07:01:51 -0600

Feel free to contact [EMAIL PROTECTED] if you can't cope with it.
--

This mail was automatically generated by TrashScan v0.08

Notify about using the e-mail account.

2004-03-03 Thread management

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
<>

Re: workflow block commited

2004-03-03 Thread Michael Wechner

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]

Re: [CForm]two question/suggestion about multi-value field

Vadim Gritsenko  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

[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, S&N AG
http://www.osoco.net/weblogs/rael/

Re: [Portal] Why don't cocoon errors appear in a coplet ?

2004-03-03 Thread Olivier Billard

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 : My title). And I still have the
"correct" error display when calling directly the coplet pipeline.

I added

error-uri

xsi:type="java:java.lang.String"

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";>cocoon:/
erreur-coplet

in the profiles/copletdata/portal.xml in my coplet and added
a match in the sitemap, in the very beginning to avoid
*/**-like matchings :

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 :

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:

 

2.Sometime we need to just display multi-value as text like
 

,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

Re: whitespace cleanup and efficiency drive

Bertrand Delacretaz wrote:

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 ;-)


I have IDEA but had not time yet to try its CVS client (...it requires 
to change cvsroot...), so I'm using command line.

Vadim

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: [CForm]two question/suggestion about multi-value field

2004-03-03 Thread roy huang

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:
> > >
> > >  
> > >
> > >>>2.Sometime we need to just display multi-value as text like
> > >>>  
> > >>>
> > >>,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: FlowScript in 2.1.5-dev has gone tango uniform

2004-03-03 Thread Jeremy Quinn

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


smime.p7s
Description: S/MIME cryptographic signature

Re: FlowScript in 2.1.5-dev has gone tango uniform

2004-03-03 Thread Jeremy Quinn

On 2 Mar 2004, at 22:07, Antonio Gallardo wrote:

Hi Jeremy:

Are you updated your endorsed libs? Please don't get offended by the
obvious question, but I thought this problem is related to this issue. 
Can
you check this?
Which versions am I supposed to have?

I just did a CVS Update, surely any updates to the endorsed libs would 
have arrived with that ?

regards Jeremy

Jeremy Quinn dijo:
Hi All

I just upgraded my copy of Cocoon to today's CVS version.

A (previously working) site that uses a lot of FlowScript has gone
completely TU.
I am getting a lot of this :

org.apache.cocoon.ResourceNotFoundException: Function
"javascript:album()" not found
Where it worked before the update.

But stranger still, while I was doing some testing, I got an error 
that
said that a script that was not even referred to by the current
pipeline, did not contain the function I was calling !!

Do what ?!?

Have there been some changes to the FlowScript infrastructure that
could result in the wrong FlowScript file being used under certain
circumstances?
I have several flowscripts, used independently by different
Sub-SiteMaps, that have the same function names. The first SiteMap I
invoke, works (does not matter which one) all subsequent invocations 
of
pipelines with similar (but different) FlowScripts fail.

Any ideas anyone?

regards Jeremy



smime.p7s
Description: S/MIME cryptographic signature

RE: [Portal] Why don't cocoon errors appear in a coplet ?

 
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 : My title). And I still have the 
> "correct" error display when calling directly the coplet pipeline.
> 
> I added
>
>  error-uri
>  xsi:type="java:java.lang.String"
>
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";>cocoon:/
> erreur-coplet
>
> 
> in the profiles/copletdata/portal.xml in my coplet and added 
> a match in the sitemap, in the very beginning to avoid 
> */**-like matchings :
> 
>
>  
>  
> value="{request:contextPath}"/>
>
>  
>
> 
> 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. 
 
> 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.

Carsten

Re: whitespace cleanup and efficiency drive

2004-03-03 Thread Bertrand Delacretaz

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: whitespace cleanup and efficiency drive

2004-03-03 Thread David Crossley

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: [Portal] Why don't cocoon errors appear in a coplet ?

2004-03-03 Thread Olivier Billard

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 : My 
title). And I still have the "correct" error display when calling directly the 
coplet pipeline.

I added
  
error-uri
http://www.w3.org/2001/XMLSchema-instance";>cocoon:/erreur-coplet
  
in the profiles/copletdata/portal.xml in my coplet and added
a match in the sitemap, in the very beginning to avoid */**-like matchings :
  


  
  

  
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


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: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

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 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

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
.
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: patch to Enhance CIncludeTrasnformer to handleencodingofparameters

2004-03-03 Thread Marco Dubbeld

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

Suspicious Attachment

2004-03-03 Thread antivirus

--
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

E-mail account disabling warning.

2004-03-03 Thread support

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
<>

Re: Event caching and CachedSource

2004-03-03 Thread Unico Hommes

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=60&cache-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=60&cache-name=main&expires=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

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
.
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.

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
.
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 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
.
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

RE: Event caching and CachedSource