[EMAIL PROTECTED]: Project cocoon (in module cocoon) failed

[Gump]

To whom it may engage...

This is an automated request, but not an unsolicited one. For 
more information please visit http://gump.apache.org/nagged.html, 
and/or contact the folk at [EMAIL PROTECTED]

Project cocoon has an issue affecting its community integration.
This issue affects 55 projects.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- cocoon :  Java XML Framework
- cocoon-block-ajax :  Ajax - Utilities and resources for Ajax applications.
- cocoon-block-apples :  Java XML Framework
- cocoon-block-asciiart :  Java XML Framework
- cocoon-block-authentication-fw :  Java XML Framework
- cocoon-block-axis :  Java XML Framework
- cocoon-block-batik :  Java XML Framework
- cocoon-block-bsf :  Java XML Framework
- cocoon-block-captcha :  Utilites to generate simple CAPTCHAs
- cocoon-block-chaperon :  Java XML Framework
- cocoon-block-core-samples-additional :  Additional core samples.
- cocoon-block-core-samples-main :  Main core samples.
- cocoon-block-cron :  Java XML Framework
- cocoon-block-databases :  Java XML Framework
- cocoon-block-deli :  Java XML Framework
- cocoon-block-eventcache :  Java XML Framework
- cocoon-block-fop :  Java XML Framework
- cocoon-block-forms :  Java XML Framework
- cocoon-block-hsqldb :  Java XML Framework
- cocoon-block-html :  Java XML Framework
- cocoon-block-itext :  Java XML Framework
- cocoon-block-javaflow :  Java XML Framework
- cocoon-block-jcr :  A "jcr:" protocol for Cocoon
- cocoon-block-jfor :  Java XML Framework
- cocoon-block-jms :  Java XML Framework
- cocoon-block-jsp :  Java XML Framework
- cocoon-block-linkrewriter :  Java XML Framework
- cocoon-block-lucene :  Java XML Framework
- cocoon-block-midi :  Java XML Framework
- cocoon-block-naming :  Java XML Framework
- cocoon-block-ojb :  Java XML Framework
- cocoon-block-paranoid :  Java XML Framework
- cocoon-block-petstore :  Java XML Framework
- cocoon-block-profiler :  Java XML Framework
- cocoon-block-proxy :  Java XML Framework
- cocoon-block-python :  Java XML Framework
- cocoon-block-qdox :  Java XML Framework
- cocoon-block-querybean :  Java XML Framework
- cocoon-block-repository :  Java XML Framework
- cocoon-block-serializers :  Java XML Framework
- cocoon-block-session-fw :  Java XML Framework
- cocoon-block-slop :  Java XML Framework
- cocoon-block-spring-app :  A demo for Spring and Cocoon
- cocoon-block-stx :  Java XML Framework
- cocoon-block-taglib :  Java XML Framework
- cocoon-block-template :  Java XML Framework
- cocoon-block-tour :  Java XML Framework
- cocoon-block-validation :  In-pipeline validation of documents
- cocoon-block-velocity :  Java XML Framework
- cocoon-block-web3 :  Java XML Framework
- cocoon-block-xmldb :  Java XML Framework
- cocoon-block-xsp :  Java XML Framework
- forrest :  Apache Forrest is an XML standards-oriented documentation fr...
- forrest-test :  Apache Forrest is an XML standards-oriented documentation 
fr...
- lenya :  Content Management System


Full details are available at:
http://vmgump.apache.org/gump/public/cocoon/cocoon/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were 
provided:
 -DEBUG- Output [cocoon.jar] identifier set to output basename: [cocoon]
 -DEBUG- Output [cocoon-testcase.jar] identifier set to output basename: 
[cocoon-testcase]
 -DEBUG- Output [cocoon-deprecated.jar] identifier set to output basename: 
[cocoon-deprecated]
 -INFO- Made directory 
[/usr/local/gump/public/workspace/cocoon/build/cocoon-15102005/test]
 -INFO- Failed with reason build failed
 -INFO- Project Reports in: 
/usr/local/gump/public/workspace/cocoon/build/cocoon-15102005/test/output
 -WARNING- No directory 
[/usr/local/gump/public/workspace/cocoon/build/cocoon-15102005/test/output]
 -INFO- Failed to extract fallback artifacts from Gump Repository



The following work was performed:
http://vmgump.apache.org/gump/public/cocoon/cocoon/gump_work/build_cocoon_cocoon.html
Work Name: build_cocoon_cocoon (Type: Build)
Work ended in a state of : Failed
Elapsed: 17 secs
Command Line: java -Djava.awt.headless=true 
-Xbootclasspath/p:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-apis.jar:/usr/local/gump/public/workspace/xml-xerces2/java/build/xercesImpl.jar
 org.apache.tools.ant.Main -Dgump.merge=/x1/gump/public/gump/work/merge.xml 
-Dbuild.sysclasspath=only 
-Dlogkit.jar=/usr/local/gump/public/workspace/avalon-trunk/runtime/logkit/target/deliverables/jars/avalon-logkit-15102005.jar
 -Dbuild=build/cocoon-15102005 gump-core 
[Working Directory: /usr/local/gump/public/workspace/cocoon]
CLASSPATH: 
/opt/jdk1.4/lib/tools.jar:/usr/local/g

[EMAIL PROTECTED]: Project cocoon (in module cocoon) failed

[Gump]

To whom it may engage...

This is an automated request, but not an unsolicited one. For 
more information please visit http://gump.apache.org/nagged.html, 
and/or contact the folk at [EMAIL PROTECTED]

Project cocoon has an issue affecting its community integration.
This issue affects 55 projects.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- cocoon :  Java XML Framework
- cocoon-block-ajax :  Ajax - Utilities and resources for Ajax applications.
- cocoon-block-apples :  Java XML Framework
- cocoon-block-asciiart :  Java XML Framework
- cocoon-block-authentication-fw :  Java XML Framework
- cocoon-block-axis :  Java XML Framework
- cocoon-block-batik :  Java XML Framework
- cocoon-block-bsf :  Java XML Framework
- cocoon-block-captcha :  Utilites to generate simple CAPTCHAs
- cocoon-block-chaperon :  Java XML Framework
- cocoon-block-core-samples-additional :  Additional core samples.
- cocoon-block-core-samples-main :  Main core samples.
- cocoon-block-cron :  Java XML Framework
- cocoon-block-databases :  Java XML Framework
- cocoon-block-deli :  Java XML Framework
- cocoon-block-eventcache :  Java XML Framework
- cocoon-block-fop :  Java XML Framework
- cocoon-block-forms :  Java XML Framework
- cocoon-block-hsqldb :  Java XML Framework
- cocoon-block-html :  Java XML Framework
- cocoon-block-itext :  Java XML Framework
- cocoon-block-javaflow :  Java XML Framework
- cocoon-block-jcr :  A "jcr:" protocol for Cocoon
- cocoon-block-jfor :  Java XML Framework
- cocoon-block-jms :  Java XML Framework
- cocoon-block-jsp :  Java XML Framework
- cocoon-block-linkrewriter :  Java XML Framework
- cocoon-block-lucene :  Java XML Framework
- cocoon-block-midi :  Java XML Framework
- cocoon-block-naming :  Java XML Framework
- cocoon-block-ojb :  Java XML Framework
- cocoon-block-paranoid :  Java XML Framework
- cocoon-block-petstore :  Java XML Framework
- cocoon-block-profiler :  Java XML Framework
- cocoon-block-proxy :  Java XML Framework
- cocoon-block-python :  Java XML Framework
- cocoon-block-qdox :  Java XML Framework
- cocoon-block-querybean :  Java XML Framework
- cocoon-block-repository :  Java XML Framework
- cocoon-block-serializers :  Java XML Framework
- cocoon-block-session-fw :  Java XML Framework
- cocoon-block-slop :  Java XML Framework
- cocoon-block-spring-app :  A demo for Spring and Cocoon
- cocoon-block-stx :  Java XML Framework
- cocoon-block-taglib :  Java XML Framework
- cocoon-block-template :  Java XML Framework
- cocoon-block-tour :  Java XML Framework
- cocoon-block-validation :  In-pipeline validation of documents
- cocoon-block-velocity :  Java XML Framework
- cocoon-block-web3 :  Java XML Framework
- cocoon-block-xmldb :  Java XML Framework
- cocoon-block-xsp :  Java XML Framework
- forrest :  Apache Forrest is an XML standards-oriented documentation fr...
- forrest-test :  Apache Forrest is an XML standards-oriented documentation 
fr...
- lenya :  Content Management System


Full details are available at:
http://vmgump.apache.org/gump/public/cocoon/cocoon/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were 
provided:
 -DEBUG- Output [cocoon.jar] identifier set to output basename: [cocoon]
 -DEBUG- Output [cocoon-testcase.jar] identifier set to output basename: 
[cocoon-testcase]
 -DEBUG- Output [cocoon-deprecated.jar] identifier set to output basename: 
[cocoon-deprecated]
 -INFO- Made directory 
[/usr/local/gump/public/workspace/cocoon/build/cocoon-15102005/test]
 -INFO- Failed with reason build failed
 -INFO- Project Reports in: 
/usr/local/gump/public/workspace/cocoon/build/cocoon-15102005/test/output
 -WARNING- No directory 
[/usr/local/gump/public/workspace/cocoon/build/cocoon-15102005/test/output]
 -INFO- Failed to extract fallback artifacts from Gump Repository



The following work was performed:
http://vmgump.apache.org/gump/public/cocoon/cocoon/gump_work/build_cocoon_cocoon.html
Work Name: build_cocoon_cocoon (Type: Build)
Work ended in a state of : Failed
Elapsed: 17 secs
Command Line: java -Djava.awt.headless=true 
-Xbootclasspath/p:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-apis.jar:/usr/local/gump/public/workspace/xml-xerces2/java/build/xercesImpl.jar
 org.apache.tools.ant.Main -Dgump.merge=/x1/gump/public/gump/work/merge.xml 
-Dbuild.sysclasspath=only 
-Dlogkit.jar=/usr/local/gump/public/workspace/avalon-trunk/runtime/logkit/target/deliverables/jars/avalon-logkit-15102005.jar
 -Dbuild=build/cocoon-15102005 gump-core 
[Working Directory: /usr/local/gump/public/workspace/cocoon]
CLASSPATH: 
/opt/jdk1.4/lib/tools.jar:/usr/local/g

Re: [SHRT] Cocoon on Rails Application Component Kernel (CRACK)

[Antonio Gallardo]

Max Pfingsthorn wrote:

... 
 

Very easy. Since the talk is about conventions as in Rails, 
then here we 
introduce a new development rule again:


"The field name should be unique in the whole application. If you use 
the same name in 2 different forms, then they refer to the 
same field in 
the database."


Tha means, if we decide a field is called "userName", then 
whenever we 
use this name we are refering to the same field! Even if the 
name is in 
2 different forms.
   



Okay, but don't you run into ambiguity issues then? Maybe we can qualify the field id by a table 
name? Something like "cars.brand" to differentiate it from "motocycles.brand". 
Would make it clearer, I think. Would also help when generating the final ER diagram.
 

Yes. But at the end is only a name. As you suggested "cars.brand" can be 
also recommended but not required to the user. Recommended, because that 
way the user can easily follow what he wrote. But the system is going to 
register this as only a name. BTW, I am not sure if a "dot" inbetween 
"table.column" name can be supported. For most SQL languages the "dot" 
is a valid operator. Maybe we can replace it with underscore, hence: 
"cars_brand" wait ... I don't know if this is a good idea Well, 
we need to think a solution here too. ;-)




...
 

I guess it could work with Sylvain's suggestion that the 
 

user makes a library for each entity and uses those for 
building the final forms. However, this is a rather rigid 
assumption... and still hard to analyze.
   




 

The forms library is still valid. It address another user need: 
Reutilization of user predefined field types. Of course we 
should also 
provide a default cform field library.
   



Errr.. What do you mean now? I thought you want to go the other way? If you 
really want to generate the DB schema from forms then you need to analyse 
libraries as well to get the complete picture, not provide them... Or did I get 
something wrong?
 

No we only pick from the libraries the fields that are declared in the 
forms. Not the whole library. The forms libraries are like macro sets. 
But we will need to define it inside a form in order to use the defined 
macro. It is something like a datatype definition file and we pick only 
the definitions declared inside the forms.




Okay, I can see that. So you are suggesting to extend the form definitions by 
an extra attribute per field in case we want to store it or not (default is to 
store it)?
 

IMHO, for normal fields, yes. Calculated fields are more often 
transient. So, the default for them should be to not store them in the 
database.


 




 

We don't want to just figure out what people is 
writing. If 
this was the case, then Druid is already done for 2 years 
now. We want 
to make a step further in the current approach. And in this 
case why the 
initial point for building the application are the forms not 
the db schema.
  

   

I just don't see how explicitly not using the model the 
 

application is built on (db schema), but trying to infer it 
through some obscure means is better...
   


Some reasons:

1-Faster development time.
2-Easier for people that does not understand SQL or write bad SQL.
3-Bring O/R mapping to the masses.

... between others that I cannot think right now are IMHO, full valid 
reasons to make a try to that. ;-)
   



I agree. That would be nice. However, reason 2 is not really valid as there 
wouldn't be any SQL writing even if we had people make an ER diagram.

Reason 2 is valid for both. From DB model --> forms and from forms --> 
Db model. ;-)



You can do that just fine in XML and generate stuff from that (as Druid does, 
even visually, like you say).
What we basically need, according to you, is to provide a bridge from a bunch of form 
definitions to a Druid ER diagram, right? "that is all"?
 


Yes.


...
 

I believe, Dreamweaver does something like this already. 
 

Then the last 20% of making new forms or adjusting generated 
ones goes quickly.
   




 

I think we should think in Open Source tools only. Maybe this is just 
me, sorry.
   



Of course, I agree, just wanted to point out that it is possible to do it 
quickly.

...
 

Okay, but I think this will be very hard. Much harder than 
 


letting people do it the other way and edit generated stuff by hand.
   




 

Yes, it is. And this is exaclty why we don't have it now. And why I 
explained we don't found the time to work on that. I just wanted to 
share the idea to see what other people can contribute to this.


I think it is posible to build something like this here. To 
me there is 
no project that cannot be done is a Open Source community. As 
a sample, 
I remember how M$ pointed out for years that a project like a browser 
(Mozilla) should never becomes a reality in a Open Source 
community. We 
know now the reality. ;-)
   



Yes, that is true. I actually believe the same. However, there should be some 

RE: [SHRT] Cocoon on Rails Application Component Kernel (CRACK)

[Max Pfingsthorn]

...

> Sorry for the delay in my reply. It is hard to follow 100 
> mails daily on 
> the list. ;-)

No problem, I feel your pain ;)

... 
> Very easy. Since the talk is about conventions as in Rails, 
> then here we 
> introduce a new development rule again:
> 
> "The field name should be unique in the whole application. If you use 
> the same name in 2 different forms, then they refer to the 
> same field in 
> the database."
> 
> Tha means, if we decide a field is called "userName", then 
> whenever we 
> use this name we are refering to the same field! Even if the 
> name is in 
> 2 different forms.

Okay, but don't you run into ambiguity issues then? Maybe we can qualify the 
field id by a table name? Something like "cars.brand" to differentiate it from 
"motocycles.brand". Would make it clearer, I think. Would also help when 
generating the final ER diagram.

> 
> >Meaning, do you have a good algorithm to extract an 
> ER-diagram from a bunch of forms?
> >
> 
> Well, still not, but the above rule, allow to create it. WDYT?

True.

...
> 
> >I guess it could work with Sylvain's suggestion that the 
> user makes a library for each entity and uses those for 
> building the final forms. However, this is a rather rigid 
> assumption... and still hard to analyze.
> >  
> >
> The forms library is still valid. It address another user need: 
> Reutilization of user predefined field types. Of course we 
> should also 
> provide a default cform field library.

Errr.. What do you mean now? I thought you want to go the other way? If you 
really want to generate the DB schema from forms then you need to analyse 
libraries as well to get the complete picture, not provide them... Or did I get 
something wrong?

...
> >
> >Wouldn't it become a sort of ER diagram then?
> >
> 
> Yes, somehow. But an E-R diagram from wich can be very easy 
> to build the 
> database model in DDL (Data Definition Language).

Of course, isn't that what general ER diagrams are used for anyway?

> 
> >Plus the calculated/processing fields?
> >  
> >
> Yes. Since the sum of calculated fields is less than the sum of 
> non-calculated (hence persisten) fields, we can also introduce a new 
> attribute to define then. That way we can also use the form 
> library to 
> have some predefined calculated fields. As a sample. The sum of the 
> column in a invoce. The calculated field can also use the value of 
> another calculated field to calculate itself. ie: the tax field in an 
> invoice. or the subtotal + shipping. I hope it explain the idea.
> 
> If we think more about the caculated fields, they are not 
> persistents. 
> The calculated are showed in the form just to provide more 
> info to the 
> user. Often, they are not going to be store in the database. 
> Sometimes, 
> we need to store also calculated fields in the database for DB 
> performance reasons.

Okay, I can see that. So you are suggesting to extend the form definitions by 
an extra attribute per field in case we want to store it or not (default is to 
store it)?

> 
> >  
> >
> >>We don't want to just figure out what people is 
> >>writing. If 
> >>this was the case, then Druid is already done for 2 years 
> >>now. We want 
> >>to make a step further in the current approach. And in this 
> >>case why the 
> >>initial point for building the application are the forms not 
> >>the db schema.
> >>
> >>
> >
> >I just don't see how explicitly not using the model the 
> application is built on (db schema), but trying to infer it 
> through some obscure means is better...
> >
> Some reasons:
> 
> 1-Faster development time.
> 2-Easier for people that does not understand SQL or write bad SQL.
> 3-Bring O/R mapping to the masses.
> 
> ... between others that I cannot think right now are IMHO, full valid 
> reasons to make a try to that. ;-)

I agree. That would be nice. However, reason 2 is not really valid as there 
wouldn't be any SQL writing even if we had people make an ER diagram. You can 
do that just fine in XML and generate stuff from that (as Druid does, even 
visually, like you say).
What we basically need, according to you, is to provide a bridge from a bunch 
of form definitions to a Druid ER diagram, right? "that is all"?

...
> >I believe, Dreamweaver does something like this already. 
> Then the last 20% of making new forms or adjusting generated 
> ones goes quickly.
> >  
> >
> I think we should think in Open Source tools only. Maybe this is just 
> me, sorry.

Of course, I agree, just wanted to point out that it is possible to do it 
quickly.

...
> >
> >Okay, but I think this will be very hard. Much harder than 
> letting people do it the other way and edit generated stuff by hand.
> >  
> >
> Yes, it is. And this is exaclty why we don't have it now. And why I 
> explained we don't found the time to work on that. I just wanted to 
> share the idea to see what other people can contribute to this.
> 
> I think it is posible to build something like this here. To 
> me the

Re: REQ Fixing really old bugs

[hepabolu]

Antonio Gallardo wrote:

hepabolu wrote:


Bertrand Delacretaz wrote:


Le 12 oct. 05, à 13:06, Torsten Curdt a écrit :


Instead of waiting for this *not* to happen
(and we know it's not going to happen) I'd say -
let's ask the people whether those old bugs still
apply...





I like the idea - how do you suggest asking?

We could add a comment to each open issue with the question (which 
would send a mail to bug reporters), pointing to a wiki page with an 
explanation, and set all bugs to NEEDINFO?




Sounds good and at least requires less work than going over all of 
them by hand. Can this be done as a batch?


How about:
"We noticed this bug is open for quite some time. We wish to move on 
them and need your help. Can you verify that the bug still applies 
with the current version of Cocoon? Please verify and report back. 
More information can be found here."



Hmm. This sounds more or less the same as CLOSE the bugs. You provided 
before a very interesting sample: Suppose you requested a [Link] in the 
bug report. How do you will feel if you got this meesage:


You're right. I was thinking about those "bugs" and intended to get them 
closed before the cleanup issue. There are only three of them AFAIK.


Bye, Helma

Re: [vote-result] Ross Gardler as a new Cocoon committer

[Ross Gardler]

David Crossley wrote:

Ross Gardler wrote:


Daniel Fagerstrom wrote:

We had 22 +1 for Ross as a committer and no other votes. I'll arrange so 
that he get access.


Thanks Cocoon Devs. In appreciation for this vote I plan to do a test 
run of the Docs publication this afternoon (UTC).



I don't recall anyone telling you that new committers
can join the Cocoon PMC if they choose to. Just
subscribe to the pmc list and send a message to
say that you are there. Then someone will ask the
Board to acknowledge, to satify bureaucracy.


Thanks for that clarification David.

Ross

Re: [SHRT] Cocoon on Rails Application Component Kernel (CRACK)

[Antonio Gallardo]

Max Pfingsthorn wrote:

Sorry for the delay in my reply. It is hard to follow 100 mails daily on 
the list. ;-)



Hi everyone!

Sorry, this one turned out to be quite long with the quotes inside. Bear with 
me, please! :)

...
 

Hmm, okay. But how do you generate a database schema from a 
 

few forms? Especially if there are graph-like relationships 
between the entities you cannot model in a form definition.
   

Can you point to a graph-like relationships model that cannot 
be modeled 
in SQL? Maybe I don't got your point.
   



Sure. Imagine you have a multi-component web application (as in it has a forum, 
a calendar, and a wiki) and you want all components to have file attachments. 
You wouldn't want to have a separate implementation for each of the components, 
but rather use a common one for all of them. Now, you don't have a tree 
structure of relationships anymore, but a DAG (directed acyclic graph, 
http://en.wikipedia.org/wiki/Directed_acyclic_graph).
These can of course be modelled in SQL using foreign keys, but that is not the 
point. How do you know when you are actually referring to the same entity in 
your forms?



Very easy. Since the talk is about conventions as in Rails, then here we 
introduce a new development rule again:


"The field name should be unique in the whole application. If you use 
the same name in 2 different forms, then they refer to the same field in 
the database."


Tha means, if we decide a field is called "userName", then whenever we 
use this name we are refering to the same field! Even if the name is in 
2 different forms.



Meaning, do you have a good algorithm to extract an ER-diagram from a bunch of 
forms?



Well, still not, but the above rule, allow to create it. WDYT?


I think, that would be pretty hard... Especially if you say you might have 
multiple forms for the same table, where these forms might have different 
amounts of fields (some left out, some added for processing).
 


Maybe not. ;-)


I guess it could work with Sylvain's suggestion that the user makes a library 
for each entity and uses those for building the final forms. However, this is a 
rather rigid assumption... and still hard to analyze.
 

The forms library is still valid. It address another user need: 
Reutilization of user predefined field types. Of course we should also 
provide a default cform field library.


 

If you think about it, the form code that is generated is 
 

not more than a skeleton anyway. No application will use the 
exact generated code.
   

I think it would be much easier addind these extra bits (add 
 

extra fields or remove ones you don't want to edit) by hand 
than trying to figure out what people meant when they were 
writing their forms.
   




 

No. The initial thread discussion was about patterns. The idea is to 
follow a pattern in order to get the code generated. I am not telling 
the initial form model is exactly as our current form definition.
   



Aha.

 

We believe we just  need to define few more attributes in the form 
definition.
   



Wouldn't it become a sort of ER diagram then?



Yes, somehow. But an E-R diagram from wich can be very easy to build the 
database model in DDL (Data Definition Language).



Plus the calculated/processing fields?
 

Yes. Since the sum of calculated fields is less than the sum of 
non-calculated (hence persisten) fields, we can also introduce a new 
attribute to define then. That way we can also use the form library to 
have some predefined calculated fields. As a sample. The sum of the 
column in a invoce. The calculated field can also use the value of 
another calculated field to calculate itself. ie: the tax field in an 
invoice. or the subtotal + shipping. I hope it explain the idea.


If we think more about the caculated fields, they are not persistents. 
The calculated are showed in the form just to provide more info to the 
user. Often, they are not going to be store in the database. Sometimes, 
we need to store also calculated fields in the database for DB 
performance reasons.


 

We don't want to just figure out what people is 
writing. If 
this was the case, then Druid is already done for 2 years 
now. We want 
to make a step further in the current approach. And in this 
case why the 
initial point for building the application are the forms not 
the db schema.
   



I just don't see how explicitly not using the model the application is built on 
(db schema), but trying to infer it through some obscure means is better...


Some reasons:

1-Faster development time.
2-Easier for people that does not understand SQL or write bad SQL.
3-Bring O/R mapping to the masses.

... between others that I cannot think right now are IMHO, full valid 
reasons to make a try to that. ;-)



Maybe it would be more worthwhile to make an effort to write a graphical form 
editor for the lepido project which operates on a certain model of the data the 
application edits.


This is also a part of

Re: Cocoon Setup.exe for Windows

[Antonio Gallardo]

Ugo Cei wrote:



Il giorno 14/ott/05, alle ore 02:02, Antonio Gallardo ha scritto:

In short 1 installer for all the platforms. Maybe we can also build  
a simple GUI for block selection for deployment and so on. ;-)



Antonio, weren't you paying attention when I wrote this [1] just a  
few days ago? ;-)


I saw it. But, since there were threads related to a binary cocoon 
distributions, then:


installer != builder.

I think at least both efforts target different audience. ;-)

Best Regards,

Antonio Gallardo.

Re: Ajax libraries: let's wait a bit

[Pier Fumagalli]

On 15 Oct 2005, at 17:51, Sylvain Wallez wrote:

Pier Fumagalli wrote:

On 15 Oct 2005, at 13:40, Sylvain Wallez wrote:


The current drawback of Dojo is that the all the spiffy effects  
are  there (and more [4]), but lack a close integration with  
background  page update. But that should be a couple of classes


And that it takes currently between 4 to 5 seconds to initialize  
on  my Safari...


That's because you're loading the uncompressed version, i.e. a lot  
of uncompressed scripts are being loaded dynamically.


Ah, that said, though, it seems to be lacking of support for Safari  
in lost of places... I tried Drag and Drop and DatePicker, for  
example, and while they work in Mozilla, they don't on Safari. Even  
the example you sent (FishEye) doesn't hide the labels correctly on  
Safari (while it does on Mozilla).


That said, the Editor works on Safari as well (apart from "saving").

Pier



smime.p7s
Description: S/MIME cryptographic signature

Re: REQ Fixing really old bugs

[Antonio Gallardo]

Bertrand Delacretaz wrote:


Le 12 oct. 05, à 17:05, Joerg Heinicke a écrit :

...Don't we have the votes feature of bugzilla for prioritizing the 
issues?...



We might, but an active and traceable action from the bug reporters/CC 
people is more useful I think.



No. The votes does not work now, simply because it was clear that voting 
in a bug does don't help at all. Maybe it was not a clear policy in the 
cocoon community, but I got that idea from the list. I liked to use the 
vote system. If we want to use the vote system, wich in fact will buble 
the most important bugs from the user base POV, then we should send a 
mail to the user list. We need to tell them, we now care about votes and 
invite them to vote for the bugs they really cares. I think in 3 weeks 
we will enough votes to make decisions.


Best Regards,

Antonio Gallardo.

Re: [Fwd: RE: Unintentional Caching with Tomcat 5.5.x]

[Carsten Ziegeler]

Ard Schrijvers wrote:
> I don't know if it is a bug or an intentional thing to not include url 
> parameters in the cache key of an expires pipeline. I though think the 
> expires caching would be of much more value if the cache key used in expires 
> pipelines would include parameters. Guess it would not be to difficult to 
> built this in?
> 
> In a practical case in which I really needed expires pipelines for 
> performance, I did JS rewriting for posts of a form to set the form 
> parameters in the URL seperated by "/" to avoid having the expires pipeline 
> return the same cached pages for all posts to one pipeline. Very annoying!
> 
> So I would guess it is a bug, otherwise a very peculiar feature :-)   
> 
The uri is used as a "default" for the cache key. You can include
parameters and any additional information in the key if you need to.

You can define your own cache key by setting a parameter on the pipeline:

  

So, you can e.g. use input modules to add the uri and the request
parameters in there.

HTH
Carsten

-- 
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/

Re: REQ Fixing really old bugs

[Antonio Gallardo]

hepabolu wrote:


Bertrand Delacretaz wrote:


Le 12 oct. 05, à 13:06, Torsten Curdt a écrit :


Instead of waiting for this *not* to happen
(and we know it's not going to happen) I'd say -
let's ask the people whether those old bugs still
apply...




I like the idea - how do you suggest asking?

We could add a comment to each open issue with the question (which 
would send a mail to bug reporters), pointing to a wiki page with an 
explanation, and set all bugs to NEEDINFO?



Sounds good and at least requires less work than going over all of 
them by hand. Can this be done as a batch?


How about:
"We noticed this bug is open for quite some time. We wish to move on 
them and need your help. Can you verify that the bug still applies 
with the current version of Cocoon? Please verify and report back. 
More information can be found here."


Hmm. This sounds more or less the same as CLOSE the bugs. You provided 
before a very interesting sample: Suppose you requested a [Link] in the 
bug report. How do you will feel if you got this meesage:


"We noticed this bug is open for quite some time. We wish to move on 
them and need your help. Can you verify that the bug still applies with 
the current version of Cocoon? Please verify and report back. More 
information can be found here."


After getting a notice like that, then my face will then look something 
like: 8-0!


It makes me feel like we are a company sending bulk mail and at the same 
time speaking about the "customized attention", "we care about you" et al.


If users got the time to report the bugs, I think at least we owe them a 
real bug review. Just request more info if needed.


WDYT?

Best Regards,

Antonio Gallardo.

Re: Ajax libraries: let's wait a bit

[Sylvain Wallez]

Pier Fumagalli wrote:


On 15 Oct 2005, at 13:40, Sylvain Wallez wrote:



The current drawback of Dojo is that the all the spiffy effects are  
there (and more [4]), but lack a close integration with background  
page update. But that should be a couple of classes



And that it takes currently between 4 to 5 seconds to initialize on  
my Safari...



That's because you're loading the uncompressed version, i.e. a lot of 
uncompressed scripts are being loaded dynamically.


Sylvain

--
Sylvain WallezAnyware Technologies
http://people.apache.org/~sylvain http://www.anyware-tech.com
Apache Software Foundation Member Research & Technology Director

Re: REQ Fixing really old bugs

[Antonio Gallardo]

Joerg Heinicke wrote:


Bertrand Delacretaz  apache.org> writes:

 

I don't think we'll ever get there, my last count says we have 303 open 
bugzilla issues, and my perception is that we have little collective 
energy to analyze and prioritize them, we've been chasing this for 
months now without significant results.


How about doing a "bug amnesty" as follows?
   



I don't like the idea of a general amnesty. Really many bugs are only about
enhancements or provide at least patches. IMO it can give a bad impression to
the community if we just ignore these issues.

But I like the idea of an EXPIRED state. This applied *by hand* on the bugs is
not that disruptive.
 


I will add, lets define a policy. for example:

If a bug was marked as "NEEDINFO" and the user does not provided more 
info in 2-3 months, then mark the bug as expired and close the bug. I 
think there are already some candidates to be expired.


Best Regards,

Antonio Gallardo.


Jörg

PS:

Is there again a problem known to infrastructure? I can not send any email to
[EMAIL PROTECTED] via POP3 and GMX, but have to use Gmane for it:

Hi. This is the qmail-send program at mail.gmx.net.
I'm afraid I wasn't able to deliver your message to the following addresses.
This is a permanent error; I've given up. Sorry it didn't work out.

:
140.211.166.49_does_not_like_recipient./Remote_host_said:_550_
http://dsbl.org/listing?213.165.64.20/Giving_up_on_140.211.166.49./
 

Re: REQ Fixing really old bugs

[Antonio Gallardo]

Ralph Goers wrote:




Bertrand Delacretaz wrote:


Le 10 oct. 05, à 16:07, hepabolu a écrit :

...while looking at Bugzilla I noticed some open bugs entered as far 
back as 2002. Could someone have a look and do _something_ about it? 
It's not a good sign that bugs are open thatlong...




I don't think we'll ever get there, my last count says we have 303 
open bugzilla issues, and my perception is that we have little 
collective energy to analyze and prioritize them, we've been chasing 
this for months now without significant results.


How about doing a "bug amnesty" as follows?

1) Set ALL Cocoon2 open issues to WONTFIX state, with a comment like 
BUG_AMNESTY_2005_10 and a link to a wiki page explaning what's 
happening.


This will send a mail to bug reporters, people in CC etc. to give 
them a chance to react.


2) In the explanation, ask people who receive these mails to reopen 
the issue if they think it is still current, if their patch still 
does make sense, etc.

Explain that the goal is to have an up-to-date list of relevant issues.

This would allow collaborative cleanup of the list of issues by the 
people who are interested in them. We might miss a few issues if 
people don't reply, but they'd be marked with BUG_AMNESTY_2005_10 in 
the comments if we need them back, so easy to find.


Without such a scheme, I'm afraid we'll drag this list forever 
without being able to separate the wheat from the chaff.


WDYT?

-Bertrand



I wouldn't do this with all bugs, but if a bug has been opened for 6 
months or perhaps a year or more and has had no activity then I think 
changing its status to EXPIRED would be appropriate.  It can always be 
reopened and fixed.


No, because it becomes invisible. Hidding reported bugs is a bad idea.

Best Regards,

Antonio Gallardo.

Re: REQ Fixing really old bugs

[Antonio Gallardo]

Torsten Curdt wrote:



On 10.10.2005, at 21:18, Gregor J. Rothfuss wrote:


Bertrand Delacretaz wrote:


Le 10 oct. 05, à 20:32, Geert Josten a écrit :


> How about doing a "bug amnesty" as follows?

Good idea. Hasn't this been done before with some of the bugs?...


some, yes, but not on a large scale, which I think we need now.



mozilla did this recently, too. they had quite the controversy  
around it, but it worked out in the end. more at


http://weblogs.mozillazine.org/gerv/archives/2005/09/ autounco_info.html

also, +1 on the idea.




+1

Cannot remember how many times I've asked for further feedback
...and did not get any



Then we should only close the bugs marked as "INFO" and not all of them. 
If the user was not able to give us more info, then close the bug. I was 
thinking that not all the users fill a bug report. I wonder wich will be 
the message to our user base, if we just choose a date and close 
everything after that they.


It is a really that some bugs takes longer than 2 months to be fixed.

Best Regards,

Antonio Gallardo

Re: Public/Private classification (was Re: javadocs navigation)

[Stefano Mazzocchi]

Reinhard Poetz wrote:

Stefano Mazzocchi wrote:


Reinhard Poetz wrote:


Stefano Mazzocchi wrote:


Daniel Fagerstrom wrote:





[...]


Daniel,

let me repeat: I don't care about precision and elegance and 
completeness, I care about usability.


I am thinking at flow users that want to use java components to do 
their stuff. They should *NOT* care about 
org.apache.cocoon.xml.XMLPipe.




Not all Cocoon users are flow users only ...




Reinhard, how many cocoon users have ever implemented 
org.apache.cocoon.xml.XMLPipe?


My point is not about flow, is about brevity over completeness.



Stefano,

TBH I have no strong opinion whether XMLPipe should be part of the 
public _documentation_.  Of course it is part of the _public API_ 
because otherwise you're not able to implement e.g. a transformer, but 
I'm sure that you know this as you're the author of this interface ;-)


I only doubt that the proposed way of how to find the classes and 
interfaces, that should become part of the public documentation, will 
lead to success. Do you guys really think that many people will start to 
evaluate ~670 classes and interfaces? And if yes, Daniel, Vadim you and 
me can't agree whether the interface XMLPipe is public or not. So I'm 
not really optimistice about the outcome as we have to discuss the other 
669 classes and interfaces too.


I'm just with Daniel that we should talk about the principles of what is 
public and private first.
After agreeing on them one person can move the public interfaces and 
classes into a seperate directoy and then we can create a cocoon-api.jar 
and can create javadocs out of it.


If you or others think that the "wiki way" of tagging classes is more 
successful (and faster), please go for it. Believe me, it's not my 
intention to block this, especially as I don't have the time to work on 
the alternative within the next 3-4 weeks.


Boy, this is getting frustrating.

I don't give a proverbial f*&k on how we do it the fact is that there 
are many levels of "public API" and we are not acknoledging that, 
nowhere something like this can be found.


In the past, we wanted FOM to be the only interface between flowscript 
and the rest of the system but given how many services are embedded in 
components and how many things were never added to FOM but just expected 
to be discovered out of getComponent(), which means that you need to 
know the entire cocoon internals to be able to write a simple 
flowscript, which is totally ridiculous.


You want principles? here they are:

 1) script-oriented people, those who don't know java and don't care, 
those looking for RAD, those coming from the client or from the XML 
world, should have a reduced API which includes FOM + useful components 
+ environment API and no cocoon internals.


 2) for power users, willing to extend cocoon, the cocoon internal APIs 
(pipelines, caching, input modules, etc..)


 3) for cocoon devepers, everything but at least packaged by block.

This is what I want.

I don't care if we do it by hand or we do it by javadoc or by other means.

I don't care if we use wikis or post-its to find out which interface 
goes in which category(s), or if we use tags or even if we use embedded 
RDF in the javadoc comments for it.


All I want is to help our users stick around... because honestly, I find 
myself in the very uncomfortable position of suggesting people *NOT*TO* 
use cocoon, because is such a horrible climb to get to that comfortable 
plateau of productivity and this is honestly not acceptable today.


--
Stefano.

Re: Public/Private classification (was Re: javadocs navigation)

[Stefano Mazzocchi]

Vadim Gritsenko wrote:

Stefano Mazzocchi wrote:


Reinhard Poetz wrote:

Reinhard, how many cocoon users have ever implemented 
org.apache.cocoon.xml.XMLPipe?



All users who implemented at least one Transformer.

  public interface Transformer extends XMLPipe, SitemapModelComponent {
  }

If you are implementing transformer for a first time, you have to have 
javadocs (or source code (or IDE with reflection)) to implement it.


I don't think you guys understand what I'm saying.

For each user that needs to write a transformer, there are 20 users that 
don't, but if they go all to the same place, only the user that is able 
to write transformers will stick around.


which is *exactly* what's happening.

So, we can keep the same attitude, or change it.

I'm for changing it.

--
Stefano.

RE: [Fwd: RE: Unintentional Caching with Tomcat 5.5.x]

[Ard Schrijvers]

I don't know if it is a bug or an intentional thing to not include url 
parameters in the cache key of an expires pipeline. I though think the expires 
caching would be of much more value if the cache key used in expires pipelines 
would include parameters. Guess it would not be to difficult to built this in?

In a practical case in which I really needed expires pipelines for performance, 
I did JS rewriting for posts of a form to set the form parameters in the URL 
seperated by "/" to avoid having the expires pipeline return the same cached 
pages for all posts to one pipeline. Very annoying!

So I would guess it is a bug, otherwise a very peculiar feature :-)   

> -Original Message-
> From: Joerg Heinicke [mailto:[EMAIL PROTECTED]
> Posted At: zaterdag 15 oktober 2005 9:43
> Posted To: Cocoon Dev List
> Conversation: [Fwd: RE: Unintentional Caching with Tomcat 5.5.x]
> Subject: [Fwd: RE: Unintentional Caching with Tomcat 5.5.x]
> 
> 
> A bug? Is there any way to influence the cache key of an 
> expires pipeline?
> 
> The rest of the thread: 
> http://marc.theaimsgroup.com/?t=11291025191&r=1&w=4.
> 
> Jörg
> 
>  Original Message 
> Subject: RE: Unintentional Caching with Tomcat 5.5.x
> Date: Wed, 12 Oct 2005 10:29:21 +0200
> From: Ard Schrijvers <[EMAIL PROTECTED]>
> Reply-To: users@cocoon.apache.org
> To: 
> 
> Is it in a noncaching/caching/expires pipeline?
> 
> I noticed the "expires" pipelines to ignore pararameters. 
> Just set your 
> logging and look for the cache key generated for the first 
> request. If 
> paramters are not represented in the cache key, then for example
> http://?page=1
> http://?page=2
> 
> will return the same cache key, and thus the same cached 
> page. I don't 
> know the behavior for caching pipelines, but for expires 
> pipelines, the 
> request paramater won't be included in the key.
> 
> AS
> 
> > -Original Message-
> > From: John Lianoglou [mailto:[EMAIL PROTECTED]
> > Posted At: woensdag 12 oktober 2005 9:33
> > Posted To: Cocoon User List
> > Conversation: Unintentional Caching with Tomcat 5.5.x
> > Subject: Unintentional Caching with Tomcat 5.5.x
> > 
> > 
> > Hey all,
> > 
> > I'm experiencing some strange caching that I really don't 
> intend to  
> > occur. The caching seems to ignore GET params in the URL 
> (as well as  
> > POST params, for that matter)... I guess I only mention the GETs  
> > being different because at least the URL string is different.
> > 
> > I've set up my cocoon installation to run as the default 
> > context of a  
> > "virtual host" I set up in my Tomcat install (eg, a  
> > element in  
> > server.xml).
> > 
> > I find that deleting the virtual host's working directory 
> allows the  
> > page to render with different data that actually honors the GET  
> > params... This naturally only works for the very first set 
> of GETs I  
> > use to access the page... also, editing XSL templates, 
> > pipelines, etc  
> > for any particular URI does NOT have an effect on the URI's output  
> > until I do the working directory purge.
> > 
> > Anyone have any ideas about how I can permanently keep 
> Cocoon and/or  
> > Tomcat from caching these silly pages?
> > 
> > I'm using Cocoon 2.1.7 and Tomcat 5.5.9
> 

Re: Ajax libraries: let's wait a bit

[Pier Fumagalli]

On 15 Oct 2005, at 13:40, Sylvain Wallez wrote:


The current drawback of Dojo is that the all the spiffy effects are  
there (and more [4]), but lack a close integration with background  
page update. But that should be a couple of classes


And that it takes currently between 4 to 5 seconds to initialize on  
my Safari...


Pier




smime.p7s
Description: S/MIME cryptographic signature

Ajax libraries: let's wait a bit

[Sylvain Wallez]

Hi all,

A few days ago, I raised some concerns [1] about the Scriptaculous 
JavaScript library which we started to use in the Ajax block, because of 
modifications made to JavaScript base classes made by the underlying 
Prototype library on which it is based.


I had no satisfying answer on the Scriptaculous mailing-list, and 
removing the base classes extensions in Prototype would mean rewriting a 
lot of things in Scriptaculous and is thus very unlikely to happen. 
Furthermore, I also wanted to use the Sortable [2] class for CForms 
repeaters, but had to make important modifications to the class itself 
for this to work with CForms because the conventions used are different.


Considering this, I decided that Scriptaculous was a wrong choice and 
looked to other alternatives.


The most promising so far is the Dojo Toolkit [3] :
- it has a very cool "load on demand" feature that allows to have only 
bootstrap 

Re: Website Changes

[hepabolu]

Thanks for the effort but somehow I don't see what happened, Is it just
that you restored the site from SVN? Or is there more under the hood
that I fail to see?

Thanks.

Bye, Helma
On 10/15/05, Sylvain Wallez <[EMAIL PROTECTED]> wrote:
Vadim Gritsenko wrote:> Regenerated, updated, synced, etc. Order is restored.:-)Thanks Vadim!

Re: [VOTE] bugzilla issues cleanup

[Joerg Heinicke]

Sorry to add my concerns to the vote thread. Should have mentioned them 
earlier.


On 14.10.2005 14:32, Bertrand Delacretaz wrote:

1) Set all open issues (except those filed since September 1st, but 
including patches) to resolution=LATER and PRIORITY=P5, and add to each 
issue the comment shown under "Bugzilla comment to send" on 
http://wiki.apache.org/cocoon BugzillaIssuesCleanup. This can be done en 
masse in bugzilla.


September 1st is much to late IMO. It is not even two months ago. I 
would propose at least half a year or all bugs of this year. But IIRC to 
many bugs are of this year, aren't they? So what about a compromise of 
July 1st (= second half year of 2005)?



3) We wait 2 weeks, until October 31st


IMO also to short period of time. 1 month at least. When I got fixed a 
bug in other projects I always need some time to re-checkout the project 
(from which I mostly use only releases), set up a testcase and so on. 
Don't put the reporters to much under pressure.


4) After this deadline, Issues in state LATER and containing 
BUGZILLA_CLEANUP_2005_10 are  those which were not confirmed, we can 
reopen them if we want, or they stay in that state, with priority=P5 in 
any case.


Of course every bug can be reopened. But it is an issue of perception. 
Doing this clean up to aggressively can lead to affronts to the reporters.


Jörg

Re: [RT] Is Cocoon Obsolete?

[Joerg Heinicke]

On 14.10.2005 15:07, Vadim Gritsenko wrote:

I do not really understand a helper class as an API. Furthermore it is 
not easy. I always have to look up how to write the code.


Decision was made early in 2.0 dev cycle to have objectModel Map as a 
contract between Cocoon and components:


That was the time when I had my first contact with Cocoon :)

But it is flexible to include additional objects. And that's exactly 
what happened: flowContext, continuation, etc.


But the context gets really arbitrary. See the effects for the FOM 
access from flow pipeline and non-flow pipeline (which is fixed in the 
meantime IIRC).


Jörg

Re: Public/Private classification (was Re: javadocs navigation)

[Joerg Heinicke]

On 15.10.2005 10:38, Reinhard Poetz wrote:

I only doubt that the proposed way of how to find the classes and 
interfaces, that should become part of the public documentation, will 
lead to success. Do you guys really think that many people will start to 
evaluate ~670 classes and interfaces? And if yes, Daniel, Vadim you and 
me can't agree whether the interface XMLPipe is public or not. So I'm 
not really optimistice about the outcome as we have to discuss the other 
669 classes and interfaces too.


I'm just with Daniel that we should talk about the principles of what is 
public and private first.
After agreeing on them one person can move the public interfaces and 
classes into a seperate directoy and then we can create a cocoon-api.jar 
and can create javadocs out of it.


Amen.

Jörg

Re: Public/Private classification (was Re: javadocs navigation)

[Reinhard Poetz]

Stefano Mazzocchi wrote:

Reinhard Poetz wrote:


Stefano Mazzocchi wrote:


Daniel Fagerstrom wrote:




[...]


Daniel,

let me repeat: I don't care about precision and elegance and 
completeness, I care about usability.


I am thinking at flow users that want to use java components to do 
their stuff. They should *NOT* care about org.apache.cocoon.xml.XMLPipe.




Not all Cocoon users are flow users only ...



Reinhard, how many cocoon users have ever implemented 
org.apache.cocoon.xml.XMLPipe?


My point is not about flow, is about brevity over completeness.


Stefano,

TBH I have no strong opinion whether XMLPipe should be part of the public 
_documentation_.  Of course it is part of the _public API_ because otherwise 
you're not able to implement e.g. a transformer, but I'm sure that you know this 
as you're the author of this interface ;-)


I only doubt that the proposed way of how to find the classes and interfaces, 
that should become part of the public documentation, will lead to success. Do 
you guys really think that many people will start to evaluate ~670 classes and 
interfaces? And if yes, Daniel, Vadim you and me can't agree whether the 
interface XMLPipe is public or not. So I'm not really optimistice about the 
outcome as we have to discuss the other 669 classes and interfaces too.


I'm just with Daniel that we should talk about the principles of what is public 
and private first.
After agreeing on them one person can move the public interfaces and classes 
into a seperate directoy and then we can create a cocoon-api.jar and can create 
javadocs out of it.


If you or others think that the "wiki way" of tagging classes is more successful 
(and faster), please go for it. Believe me, it's not my intention to block this, 
especially as I don't have the time to work on the alternative within the next 
3-4 weeks.


--
Reinhard Pötz   Independent Consultant, Trainer & (IT)-Coach 


{Software Engineering, Open Source, Web Applications, Apache Cocoon}

   web(log): http://www.poetz.cc

Re: Website Changes

[Sylvain Wallez]

Vadim Gritsenko wrote:


Regenerated, updated, synced, etc. Order is restored.



:-)

Thanks Vadim!

Sylvain

--
Sylvain WallezAnyware Technologies
http://people.apache.org/~sylvain http://www.anyware-tech.com
Apache Software Foundation Member Research & Technology Director

DO NOT REPLY [Bug 37094] - I18nTransformer add support for ISO8601

[bugzilla]

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://issues.apache.org/bugzilla/show_bug.cgi?id=37094





--- Additional Comments From [EMAIL PROTECTED]  2005-10-15 09:50 ---
(In reply to comment #3)
> What about the license?

http://www.w3.org/Consortium/Legal/IPR-FAQ-2620#GNU

« Additionally, the W3C license permits W3C code to be used in other
(non-copyleft) licenses or even proprietary software. »

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

[Fwd: RE: Unintentional Caching with Tomcat 5.5.x]

[Joerg Heinicke]

A bug? Is there any way to influence the cache key of an expires pipeline?

The rest of the thread: 
http://marc.theaimsgroup.com/?t=11291025191&r=1&w=4.


Jörg

 Original Message 
Subject: RE: Unintentional Caching with Tomcat 5.5.x
Date: Wed, 12 Oct 2005 10:29:21 +0200
From: Ard Schrijvers <[EMAIL PROTECTED]>
Reply-To: users@cocoon.apache.org
To: 

Is it in a noncaching/caching/expires pipeline?

I noticed the "expires" pipelines to ignore pararameters. Just set your 
logging and look for the cache key generated for the first request. If 
paramters are not represented in the cache key, then for example

http://?page=1
http://?page=2

will return the same cache key, and thus the same cached page. I don't 
know the behavior for caching pipelines, but for expires pipelines, the 
request paramater won't be included in the key.


AS


-Original Message-
From: John Lianoglou [mailto:[EMAIL PROTECTED]
Posted At: woensdag 12 oktober 2005 9:33
Posted To: Cocoon User List
Conversation: Unintentional Caching with Tomcat 5.5.x
Subject: Unintentional Caching with Tomcat 5.5.x


Hey all,

I'm experiencing some strange caching that I really don't intend to  
occur. The caching seems to ignore GET params in the URL (as well as  
POST params, for that matter)... I guess I only mention the GETs  
being different because at least the URL string is different.


I've set up my cocoon installation to run as the default 
context of a  
"virtual host" I set up in my Tomcat install (eg, a  
element in  
server.xml).


I find that deleting the virtual host's working directory allows the  
page to render with different data that actually honors the GET  
params... This naturally only works for the very first set of GETs I  
use to access the page... also, editing XSL templates, 
pipelines, etc  
for any particular URI does NOT have an effect on the URI's output  
until I do the working directory purge.


Anyone have any ideas about how I can permanently keep Cocoon and/or  
Tomcat from caching these silly pages?


I'm using Cocoon 2.1.7 and Tomcat 5.5.9