DO NOT REPLY [Bug 28724] - FragmentExtractor always returns same fragment

[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=28724

FragmentExtractor always returns same fragment





--- Additional Comments From [EMAIL PROTECTED]  2004-06-02 06:44 ---
Sorry I wasn't clear enough:
For every request with new parameters to the pipeline, the setup() method of the
FragmentExtractorTransformer will be executed. But in this method the int
fragmentID variable will be reset to zero. So I've deleted this reset
(//fragmentID = 0;) and the grafic output works now correct.

DO NOT REPLY [Bug 29308] - issue with javaflow continuations

[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=29308

issue with javaflow continuations





--- Additional Comments From [EMAIL PROTECTED]  2004-06-02 04:25 ---
why is it failing if it is not an inner class but just a package class (not
public) as outlined in the first code sample in initial bug report ?

I would favour your idea of using a regular expression in class loader to
determine which classes need to be instrumented. This is because, if an end
client is using the continuations based third party set of classes, it will be
really difficult for him to determine which classes needs continuations and
which dont. Although it is inefficient perf wise, still it is worth the
convenience. It would be nice if sun folks realize the importance of
continuations and provide a framework to transparently migrate the current stack
 and program counter for execution. 

I am toying with the idea of using this continuation framework with Java NIO so
that we can get seemless transparent asynchronous I/O framework with programmer
coding sequentially. This way, we can emulate a socket which is internally
asynchronous but for outside world, might appear blocking. Although there is a
hidden cost of continuation stack capture etc.,. if we code the I/O framework
sensibly (doing enough buffering in async I/O layer before passing the control
back to program), the programming convenience outweighs the performance drop a lot.

Changes to cocoon:/ protocol processing?

[Antonio Gallardo]

Hi:

We are experiencing a similar problem in a local application using the
lastest CVS as Andreas posted:

http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=108609520613365&w=2

The application worked well and no changes were done. The problem is
related to redirections using cocoon:/ protocol:

We have a main sitemap that redirects to a second level sitemap in a
directory structure:

* Main sitemap
  |
  +-- Sub sitemap A (SSA)
  |
  +-- SubSitemap B (SSB)

We called a flow in SSA. At the end of the flow in SSA we do a call to a
flow function in SSB. It start the function at flow in SSB. The problem is
when we are inside flow in SSB and we try to use:

form.showForm("SSB/somePage");

We got: "Resource not found". But it worked before! No matter, I tried:

form.showForm("/SSB/somePage");
form.showForm("//SSB/somePage");
form.showForm("//SSB/somePage");

It never works! The same error.

Hope this helps to find the source of the error.

Best Regards,

Antonio Gallardo.

Re: Adding a global validation message to a form?

[Joerg Heinicke]

On 01.06.2004 23:43, Bruno Dumon wrote:
Once we have this kind of functionality, we can drop the fd:messages
widget which was introduced as a temporary solution.
OTOH, from monitoring the users list, it seems a fd:message widget
(singular) would be useful since many users are now using the fd:output
widget for outputting messages (and then need to do special things to
get i18n working for that).
Hmm, not every form message must be necessarily an error, maybe they are 
just info (without the need for a failing validation). So we need a 
mixture of fd:message and the described functionality for the form 
itself. Maybe even this makes the fd:message not superfluous because the 
messages can be placed more fine-grained with it.

you mean fd:messages ? (with the 's')
Oh, you make a difference between singular and plural. Then I have to 
re-read the last sections ... ah, there is also a "singular" in parantheses.

At the moment we have fd:messages. You can have many of them and add one 
or more messages. So, yes, I meant fd:messages. But what's the use case 
of having fd:message additionally or as replacement if fd:messages is 
dropped?

Joerg

RE: forms validation question

[Hunsberger, Peter]

Bruno Dumon <[EMAIL PROTECTED]> writes:

> 
> On Tue, 2004-06-01 at 23:07, Hunsberger, Peter wrote:
> > Bruno Dumon <[EMAIL PROTECTED]> writes:
> > 
> > As I've noted previously, we've got a proprietary forms 
> system and I 
> > don't have much experience with cForms.  However, our 
> experience may 
> > be useful to you (feel free to disregard!).
> 
> Always appreciated!

Cool...

> > 
> > We allow multiple templates per form model. Basically we treat them 
> > both as metadata and create a merged instance specific 
> metadata model 
> > as needed.  This allows templates to customize generic form objects 
> > giving you much more back end reusability and allowing you 
> to exploit 
> > XSLT for custom rendering much more easily.  To do this we 
> couple the 
> > validation rules to the template and not to the form model, 
> thus you 
> > avoid the issues of having to merge the models at 
> validation time. Our 
> > Validation rules are a Schematron skeleton that gets converted into 
> > normal Schematron via XSLT at validation time (via a Cocoon 
> pipeline). 
> > Essentially, the presentation template has a link to the validation 
> > template.
> 
> The way I see it (currently), the combination of a CForms 
> model and template is what the template is in your system. 
> CForms doesn't try to replace the backend.

Hmm, not sure.  Our form model is independent of the back end and how
the data is produced.  

I think the biggest difference is that we have three components: a
metadata object model (similar to half the cForms form model), the
presentation template (similar to the cForms template) and a separate
validation template (the other half of the cForms form model), but
coupled to the template.  It's a little more work to maintain but it
separates out the concerns completely.

> 
> I see in fact two different uses of the form framework:
> 
>  * smaller applications where the required CForms forms are 
> defined ad hoc. This is what lots of people are doing.
> 

Something our system is definitely not designed for!

>  * applications whereby all fields and screens are defined in 
> the backend, usually a large amount of them, and usually 
> adjustable by the customer of the application. In this case 
> the CForms form definitions and templates can be generated 
> dynamically based on information from the backend, and CForms 
> then simply functions as the thing that actually handles the 
> user interaction.
> 
> For a long time I had mainly the first scenario as use case, 
> but it just happens that (potential) customers we've been in 
> contact with often need the second case. Due to the 
> declarative nature of CForms (which was originally mainly to 
> make it usable by 'non-programmers'), it is actually quite 
> easy to generate these CForms from backend data. With typical 
> Java form handling frameworks one would need to generate and 
> compile Java code to do this kind of stuff.
 
This is precisely what our system is designed to do.

> OTOH, there are also concrete plans to add widget repository 
> functionalities to CForms itself, so that for people who 
> directly use CForms, it will also become possible to reuse 
> widget definitions across multiple forms.
> 

I have some thoughts on how you can do a generalized repository (a
generalization of our generalizations).  I'll have to think about
whether it's anything anyone could actually use without getting lost in
the generalizations and resulting abstractions...

Re: Adding a global validation message to a form?

[Bruno Dumon]

On Tue, 2004-06-01 at 23:02, Joerg Heinicke wrote:
> On 29.05.2004 11:14, Bruno Dumon wrote:
> 
> >>Moving this to dev list. Find the original thread at 
> >>http://marc.theaimsgroup.com/?t=10855910974&r=1&w=4.
> 
> >>>I'm not sure if this is a good
> >>>solution, since those messages are not specifically recognized as being
> >>>validation errors, and so this wouldn't work together with
> >>>fi:validation-errors. Maybe the best would be to allow adding validation
> >>>errors (multiple ones) on the form itself.
> >>
> >>The form itself becomes ValidationErrorAware? I searched for it when 
> >>thinking about a solution, but unfortunately the form is not 
> >>implementing the interface.
> > 
> > 
> > No, I would rather have a method like addValidationError on the form,
> > not setValidationError. One global validation error message seems to
> > limitting to me.
> 
> I agree.
> 
> >>>fi:validation-errors would
> >>>then better be replaced with a ft:validation-errors (which can crawl the
> >>>widget tree), since otherwise it wouldn't find the errors attached to
> >>>the form.
> >>
> >>Hmm, I guess it is also possible to add a fi:validation-message to the 
> >>form widget as it is done for all other widgets. It must be possible to 
> >>differ between form widget (= global) validation errors, collected 
> >>"somewhere" and widget specific errors. In other words I do not want to 
> >>be forced to collect all errors at one place just because of using 
> >>ft:validation-errors for the global errors.
> > 
> > This behaviour could be made configurable via an attribute on the
> > element:
> > 
> > 
> 
> fi:validation-errors vs. ft:form-errors - was this renaming intended?

yes, since this tag would retrieve the errors of the form, which can be
multiple ones, and have the extra functionality of the 'all' attribute.
However, maybe this kind of functionality would potentially be useful
for all types of container widgets. Need to think some more about it.

> 
> > all=false would give only the errors added directly to the form, while
> > all=true would give all errors from all widgets (including those added
> > to the form).
> > 
> > Once we have this kind of functionality, we can drop the fd:messages
> > widget which was introduced as a temporary solution.
> > 
> > OTOH, from monitoring the users list, it seems a fd:message widget
> > (singular) would be useful since many users are now using the fd:output
> > widget for outputting messages (and then need to do special things to
> > get i18n working for that).
> 
> Hmm, not every form message must be necessarily an error, maybe they are 
> just info (without the need for a failing validation). So we need a 
> mixture of fd:message and the described functionality for the form 
> itself. Maybe even this makes the fd:message not superfluous because the 
> messages can be placed more fine-grained with it.

you mean fd:messages ? (with the 's')

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

RE: forms validation question

[Bruno Dumon]

On Tue, 2004-06-01 at 23:07, Hunsberger, Peter wrote:
> Bruno Dumon <[EMAIL PROTECTED]> writes:
> 
> As I've noted previously, we've got a proprietary forms system and I
> don't have much experience with cForms.  However, our experience may be
> useful to you (feel free to disregard!).

Always appreciated!

> 
> We allow multiple templates per form model. Basically we treat them both
> as metadata and create a merged instance specific metadata model as
> needed.  This allows templates to customize generic form objects giving
> you much more back end reusability and allowing you to exploit XSLT for
> custom rendering much more easily.  To do this we couple the validation
> rules to the template and not to the form model, thus you avoid the
> issues of having to merge the models at validation time. Our Validation
> rules are a Schematron skeleton that gets converted into normal
> Schematron via XSLT at validation time (via a Cocoon pipeline).
> Essentially, the presentation template has a link to the validation
> template.

The way I see it (currently), the combination of a CForms model and
template is what the template is in your system. CForms doesn't try to
replace the backend.

I see in fact two different uses of the form framework:

 * smaller applications where the required CForms forms are defined ad
hoc. This is what lots of people are doing.

 * applications whereby all fields and screens are defined in the
backend, usually a large amount of them, and usually adjustable by the
customer of the application. In this case the CForms form definitions
and templates can be generated dynamically based on information from the
backend, and CForms then simply functions as the thing that actually
handles the user interaction.

For a long time I had mainly the first scenario as use case, but it just
happens that (potential) customers we've been in contact with often need
the second case. Due to the declarative nature of CForms (which was
originally mainly to make it usable by 'non-programmers'), it is
actually quite easy to generate these CForms from backend data. With
typical Java form handling frameworks one would need to generate and
compile Java code to do this kind of stuff.

OTOH, there are also concrete plans to add widget repository
functionalities to CForms itself, so that for people who directly use
CForms, it will also become possible to reuse widget definitions across
multiple forms.

> 
> We do allow for widgets to be specified as mandatory at the form level,
> but for those that are not mandatory, the template writer can choose to
> include them as they see fit. 
> 
> Don't know if you can do any of this with cForms, but it's certainly
> proved very powerful for us...
> 
> An example for us is a Radiation therapy form.  We support over 30
> possible widgets, but no single user of the form wants to see them all.
> For many treatment protocols we show less than 10. 

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

RE: forms validation question

[Hunsberger, Peter]

Bruno Dumon <[EMAIL PROTECTED]> writes:

As I've noted previously, we've got a proprietary forms system and I
don't have much experience with cForms.  However, our experience may be
useful to you (feel free to disregard!).

We allow multiple templates per form model. Basically we treat them both
as metadata and create a merged instance specific metadata model as
needed.  This allows templates to customize generic form objects giving
you much more back end reusability and allowing you to exploit XSLT for
custom rendering much more easily.  To do this we couple the validation
rules to the template and not to the form model, thus you avoid the
issues of having to merge the models at validation time. Our Validation
rules are a Schematron skeleton that gets converted into normal
Schematron via XSLT at validation time (via a Cocoon pipeline).
Essentially, the presentation template has a link to the validation
template.

We do allow for widgets to be specified as mandatory at the form level,
but for those that are not mandatory, the template writer can choose to
include them as they see fit. 

Don't know if you can do any of this with cForms, but it's certainly
proved very powerful for us...

An example for us is a Radiation therapy form.  We support over 30
possible widgets, but no single user of the form wants to see them all.
For many treatment protocols we show less than 10. 

> 
> On Sat, 2004-05-29 at 13:20, BURGHARD Eric wrote:
> > Hi,
> > 
> > I've got a simple question (request) about how the form are 
> validated.
> > 
> > It seems that for the moment, the whole model is validated 
> even if we 
> > don't use all the widgets in the template.
> 
> What you're doing here isn't supported, and you've just found 
> out one of the reasons why.
> 
> > 
> > So is there a reason to check the rules of all the widgets 
> instead of 
> > the rules of the submitted widgets (from the template) ?
> 
> I don't have time right now to explain this deeply (or to 
> think about it deeply), but I think the widget tree should 
> always be completely processed.
> 
> Just to drop some things:
> 
>  * the form can't know which widgets the template would 
> decide to display [and thus which widgets are the 'submitted 
> widgets'], unless we would encode that information in the 
> request (ie. by adding a hidden input field for each widget 
> to indicate if it is there)
> 
>  * but: it should be the server-side form model which expects 
> certain widgets to be there, instead of the other way around 
> (ie the request saying which widgets it decides to submit)
> 
>  * validation can do checks between multiple widgets, how 
> should this deal with the possibility of arbitrary widgets 
> not being displayed?
> 
>  * what to do with required widgets? Is it because the 
> template author decides that a widget should not be 
> displayed, that is suddenly becomes not required?
> 
>  * In general, I don't think it is the template writer who 
> decides which widgets to display. There's been suggestions 
> about how one form model should be combinable with multiple 
> templates which display different subsets of the widgets, but 
> this doesn't make sense to me. Having one form model for each 
> separate form makes things much easier. Besides, it's not 
> like the template author could simply decide to move one 
> widget from one page to another, since the controller logic 
> (and also the form model with its validation logic) have 
> expectations about widgets actually being there on a page. As 
> an example, take the amazon checkout
> wizard: I don't believe it would be possible to randomly move 
> widgets between its different pages.
> 
> The solution lies, I think, in the union widget (which we 
> still need to finish up -- I don't know its current state). 
> You can think of it as a switch between multiple (groups of) 
> widgets. You could then define a union between "the widget" 
> and "no widget", and switch the union to the desired case.
> 
> Another solution may be the proposed widget states (see 
> somewhere on the wiki), though I don't have that fresh in my 
> mind right now.
> 
> -- 
> Bruno Dumon http://outerthought.org/
> Outerthought - Open Source, Java & XML Competence Support Center
> [EMAIL PROTECTED]  [EMAIL PROTECTED]
> 
> 
> 

DO NOT REPLY [Bug 28724] - FragmentExtractor always returns same fragment

[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=28724

FragmentExtractor always returns same fragment





--- Additional Comments From [EMAIL PROTECTED]  2004-06-01 21:06 ---
Don't understand your last comment, but at least for the moment you seemed to be
satisfied :)

Re: Adding a global validation message to a form?

[Joerg Heinicke]

On 29.05.2004 11:14, Bruno Dumon wrote:
Moving this to dev list. Find the original thread at 
http://marc.theaimsgroup.com/?t=10855910974&r=1&w=4.

I'm not sure if this is a good
solution, since those messages are not specifically recognized as being
validation errors, and so this wouldn't work together with
fi:validation-errors. Maybe the best would be to allow adding validation
errors (multiple ones) on the form itself.
The form itself becomes ValidationErrorAware? I searched for it when 
thinking about a solution, but unfortunately the form is not 
implementing the interface.

No, I would rather have a method like addValidationError on the form,
not setValidationError. One global validation error message seems to
limitting to me.
I agree.
fi:validation-errors would
then better be replaced with a ft:validation-errors (which can crawl the
widget tree), since otherwise it wouldn't find the errors attached to
the form.
Hmm, I guess it is also possible to add a fi:validation-message to the 
form widget as it is done for all other widgets. It must be possible to 
differ between form widget (= global) validation errors, collected 
"somewhere" and widget specific errors. In other words I do not want to 
be forced to collect all errors at one place just because of using 
ft:validation-errors for the global errors.
This behaviour could be made configurable via an attribute on the
element:

fi:validation-errors vs. ft:form-errors - was this renaming intended?
all=false would give only the errors added directly to the form, while
all=true would give all errors from all widgets (including those added
to the form).
Once we have this kind of functionality, we can drop the fd:messages
widget which was introduced as a temporary solution.
OTOH, from monitoring the users list, it seems a fd:message widget
(singular) would be useful since many users are now using the fd:output
widget for outputting messages (and then need to do special things to
get i18n working for that).
Hmm, not every form message must be necessarily an error, maybe they are 
just info (without the need for a failing validation). So we need a 
mixture of fd:message and the described functionality for the form 
itself. Maybe even this makes the fd:message not superfluous because the 
messages can be placed more fine-grained with it.

Joerg

Re: invalid content length

[Joerg Heinicke]

On 21.05.2004 21:36, Joerg Heinicke wrote:
Can anybody tell me what can cause the invalid content length?
Found at least the reason: A stylesheet is imported via cocoon:/ and in
this pipeline the stylesheet is *read* from disk, the ResourceReader 
also sets the content-length header, the 919 bytes are the length of the 
stylesheet.

Now the question how to fix it. Referencing the stylesheet in the same 
way directly from the sitemap would result in a ProcessingException:
"Streaming of an internal pipeline is not possible with a reader." 
(AbstractProcessingPipeline, line 678).

1st issue: That this exception is not thrown when the stylesheet is 
imported by another stylesheet via cocoon:/ is 1.) somewhat inconsistent 
and 2.) hints on a bigger problem (why is this internal request not 
recognized as an internal request?).

On the one hand we could for simplification throw an exception for this 
case too - however this case will be recognized as internal request. On 
the other hand there is no need for it as transformers don't need to be 
streamed - otherwise it would not work using the reader as it did. This 
would allow to write partly shorter sitemaps, but I don't know if it's 
worth the effort to recognize internal requests sent by transformer steps.

2nd issue: Letting the reader set the headers "unasked" does not sound 
like IoC. The SitemapOutputComponent has a method 
shouldSetContentLength(), the AbstractReader implements it by returning 
false, but the ResourceReader sets it? Thinking in code smells [1] this 
stinks :)
Just another issue I want to nag you. Nobody cares or has an opinion? I 
would like to have solved both issues: 1. correct recognition of 
internal pipelines. 2. the reader is explicitely asked for setting the 
headers or this tasks is completely removed from it and put into the 
pipeline - but no auto magic.

Joerg

Re: [heads up] [cforms] problem with calendar popup on ie6

[Joerg Heinicke]

On 14.05.2004 17:30, Tim Larson wrote:
Random thought: We could have a partial solution by making the
calendar popup (and help popups, etc.) draggable, like the sample
on the "diner" page linked above.
I would not like to see us maintaining forks of Matt Kruse's code, but 
it would be a nice feature request to him as everybody everywhere with 
IE has the same problem.

Joerg

Re: Mime-Type setting of a serializer [was: RE:cvs commit: cocoon-2.1/src/java/org/apache/cocoon/components/pipelineAbstractProcessingPipeline.java]

[Joerg Heinicke]

On 25.05.2004 12:00, Carsten Ziegeler wrote:
http://issues.apache.org/bugzilla/show_bug.cgi?id=26997

One of them is the order in which the mime-type is evaluated.
I think we should change if for the serializer as well in order
to make it equal to the order used for the reader. So the order
should be:
- optional configured mime-type in the usage of the serializer
  (perhaps this can be removed)
- configured mime-type in the configuration of the serializer
- ask the serializer
Yes, for consistency.
Now for the encoding. In general I would say that a serializer
is configured with a mime-type and (perhaps) with an encoding.
Now, a working solution should be that the serializer is
configured with the combination of mime-type and encoding:

This should work out of the box. It has only the disadvantage
that you configure the encoding twice on the serializer.
WDYT?
To be honest I really don't like it. Why shall a user have to care what 
comes out at the end (the header) and why he has to know the needed 
format for it ("mimetype;charset")? To say nothing of the duplicate 
configuration and the nice effects if you change one and forget the 
other one ... IMO the serializer must know the encoding in any case, so 
it should get the complete control over it and the pipeline (setting the 
header) only asks the serializer. This is what I tried with the patch.

Joerg

[BUG] Registering of JavaFlow fails (was: [JavaFlow] java.lang.VerifyException)

[Stephan Coboos]

Hello,
I have a problem using Objects in JavaFlow before a while loop. Please 
see my first posting [JavaFlow] java.lang.VerifyException. In my opinion 
it can be a bug in the JavaFlow block.

Because my fist posting was not so clear, I had tried to reproduce the 
error for a while and I had discovered the following code which creates 
such an error (you need the packages of Lucene):

package foo.bar;
import org.apache.cocoon.components.flow.java.AbstractContinuable;
import org.apache.lucene.queryParser.*;
import org.apache.lucene.search.*;
import org.apache.lucene.analysis.standard.StandardAnalyzer;
public class TestFlow extends AbstractContinuable {
   public void doTest() throws Exception {
  
// This causes an error -> The class can not be registered at 
first call!!!
   Query query = null;
   Hits hits;
   IndexSearcher searcher = null;
  // end

   while(true) {
  
   this.sendPageAndWait("foo");
  
   query = QueryParser.parse("foo", "bar", new StandardAnalyzer());
   hits = searcher.search(query);
   }
   }
}

If you test this error you can see that the first call of any (!) url of 
the corresponding cocoon app causes in a empty page. The flow-log shows 
as last entry the following line:

registered java class "foo.bar.TestFlow" for flow
Then, Cocoon stops working and displays a empty page.
In the logs of my servlet container Tomcat I can see the follwing error 
message:

2004-06-01 19:58:33 StandardWrapperValve[Cocoon]: Servlet.service() for 
servlet Cocoon threw exception
java.lang.VerifyError: (class: foo/bar/TestFlow, method: doTest 
signature: ()V) Incompatible object argument for function call
   at java.lang.Class.getDeclaredMethods0(Native Method)
   at java.lang.Class.privateGetDeclaredMethods(Class.java:1647)
   at java.lang.Class.privateGetPublicMethods(Class.java:1770)
   at java.lang.Class.getMethods(Class.java:824)
   at 
org.apache.cocoon.components.flow.java.JavaInterpreter.initialize(JavaInterpreter.java:96)
   at 
org.apache.cocoon.components.flow.java.JavaInterpreter.callFunction(JavaInterpreter.java:130)
   at 
org.apache.cocoon.components.treeprocessor.sitemap.CallFunctionNode.invoke(CallFunctionNode.java:130)
   at 
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:49)
   at 
org.apache.cocoon.components.treeprocessor.sitemap.PreparableMatchNode.invoke(PreparableMatchNode.java:130)
   at 
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:72)
   at 
org.apache.cocoon.components.treeprocessor.sitemap.PipelineNode.invoke(PipelineNode.java:126)
   at 
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:72)
   at 
org.apache.cocoon.components.treeprocessor.sitemap.PipelinesNode.invoke(PipelinesNode.java:101)
   at 
org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreeProcessor.java:336)
   at 
org.apache.cocoon.components.treeprocessor.TreeProcessor.handleCocoonRedirect(TreeProcessor.java:382)
   at 
org.apache.cocoon.components.treeprocessor.TreeProcessor.access$000(TreeProcessor.java:66)
   at 
org.apache.cocoon.components.treeprocessor.TreeProcessor$TreeProcessorRedirector.cocoonRedirect(TreeProcessor.java:543)
   at 
org.apache.cocoon.environment.ForwardRedirector.redirect(ForwardRedirector.java:58)
   at 
org.apache.cocoon.components.treeprocessor.sitemap.RedirectToURINode.invoke(RedirectToURINode.java:69)
   at 
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:49)
   at 
org.apache.cocoon.components.treeprocessor.sitemap.PreparableMatchNode.invoke(PreparableMatchNode.java:130)
   at 
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:72)
   at 
org.apache.cocoon.components.treeprocessor.sitemap.PipelineNode.invoke(PipelineNode.java:126)
   at 
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:72)
   at 
org.apache.cocoon.components.treeprocessor.sitemap.PipelinesNode.invoke(PipelinesNode.java:101)
   at 
org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreeProcessor.java:336)
   at 
org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreeProcessor.java:277)
   at 
org.apache.cocoon.components.treeprocessor.sitemap.MountNode.invoke(MountNode.java:103)
   at 
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:49)
   at 
org.apache.cocoon.components.treeprocessor.sitemap.PreparableMatchNode.invoke(PreparableMatchNode.java:130)
   at 
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:72)
   at 
org.apache.cocoon.components.treepro

Re: [CForms] Question on storing form data

[Reinhard Poetz]

Bruno Dumon wrote:
I see no reason to not ask this question on the mailing list? Anyway,
see below.
 

Point taken, I was so focused that you have the answer that I wrote 
directly to you.

Anyway, thanks Bruno and here the answer for all ;-)
On Tue, 2004-06-01 at 13:38, Reinhard Pötz wrote:
 

Hi Bruno,
Recently I was asked why CForms use a widget-tree to store the form 
data.
   

why why why... why do we live?
Everything can be done in different ways, using different approaches,
and in the end you have to choose one, the one you think or feel would
be best.
 

I answered that we need strongly-typed data. The person asking me 
replied that we could have reached the same using a combination DOM tree 
and some kind of schema (XML Schema, RelaxNG).
   

I don't see where you would store the strongly typed data then? (or any
of the state variables that are present in eg the Field class)
A DOM tree is a pure data model. CForm's widgets contain both data and
behaviour.
The widget-tree API is easier: ie doing widget.getChild("otherwidget"):
try to write the equivalent DOM-code for that.
I also don't see much use of nor the datatypes, nor the structural
validation that XML Schema offers for the purpose of end-users filling
in forms.
Sure there are all kinds of ways around it, ie annotating the schema
with extra hints towards editing, making a custom DOM implementation,
and so on. This would all be a very interesting exercise, but I'm paid
to make working solutions, not to do research.
In short: it isn't as simple as just taking a readily-available DOM and
XML Schema implementation together. And any solution you could come up
with would probably not be that far of from binding a DOM to a CForms
form, except that the distinction would be blurred. But I'd be happy to
be proved wrong of course!
 

I searched the archives 
but can find the message, though I'm sure it was answered somewhere.

Can you give me a hint?
Many thanks in advance!
Best,
Reinhard
   

--
Reinhard

DO NOT REPLY [Bug 26392] - failing Cocoon 2.0.4 deployment on Tomcat 5 through broken Batik JAR

[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=26392

failing Cocoon 2.0.4 deployment on Tomcat 5 through broken Batik JAR





--- Additional Comments From [EMAIL PROTECTED]  2004-06-01 18:00 ---
Ok, it is:
WONTFIX as far as a future binary distribution is concerned (because there 
probably won't be a new 2.0.x distribution) and
FIXED as far as the CVS-version is concerned.

Re: JXTG and caching

[Sylvain Wallez]

Vadim Gritsenko wrote:
Sylvain Wallez wrote:
Moreover, you may consider the case of complex pipelines where the 
actual template depends on the user rights, target browser or 
whatever else. In that case, the cache information can be different 
depending on used template.

And for caching to play right with proxies and browsers, Vary header 
(and/or some others) should be set. What mechanism can be used to set 
headers from the JX template?

 ??
Sylvain
--
Sylvain Wallez  Anyware Technologies
http://www.apache.org/~sylvain   http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }

SVN status?

[Pier Fumagalli]

When is it going to happen? Did it happen already? Did I miss 
something? Why do I feel so confused?

I have a quickie patch for 2.1, that's all...
	Pier


smime.p7s
Description: S/MIME cryptographic signature

Re: [heads up] PMC chair nominations

[Pier Fumagalli]

On 1 Jun 2004, at 10:17, Gianugo Rabellino wrote:
On Jun 1, 2004, at 10:13 AM, Sylvain Wallez wrote:
 - Vadim Gritsenko
 - Sylvain Wallez
 - Matthew Langham
 - Gianugo Rabellino
 [- Bertrand Delacretaz]
Ah, and contrarily to last year, I do accept the nomination ;-)
And you get my reliefed +1 in return. :-)
Gianugo, you're _so_ lazy! :-P
+1 for Sylvain
Pier


smime.p7s
Description: S/MIME cryptographic signature

DO NOT REPLY [Bug 26392] - failing Cocoon 2.0.4 deployment on Tomcat 5 through broken Batik JAR

[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=26392

failing Cocoon 2.0.4 deployment on Tomcat 5 through broken Batik JAR





--- Additional Comments From [EMAIL PROTECTED]  2004-06-01 16:44 ---
I don't agree as it was in CLOSED FIXED state. The bug has been fixed by
upgrading Batik in 2.0 CVS.

Re: JXTG and caching

[Vadim Gritsenko]

Sylvain Wallez wrote:
Moreover, you may consider the case of complex pipelines where the 
actual template depends on the user rights, target browser or whatever 
else. In that case, the cache information can be different depending 
on used template.

And for caching to play right with proxies and browsers, Vary header 
(and/or some others) should be set. What mechanism can be used to set 
headers from the JX template?

Vadim

[JavaFlow] java.lang.VerifyException

[Stephan Coboos]

Hello,
I'am using JavaFlow. All my JavaFlows works very well, except one. If I 
use this Flow I got a empty page each first call. In the next call I got 
an exception which displays that the method of the flow can not be found 
but the name of the method is correct and it is correct registered:

org.apache.cocoon.ProcessingException: No method found for 
'editSingleContainer' at 
org.apache.cocoon.components.flow.java.JavaInterpreter.callFunction(JavaInterpreter.java:135) 
at 
org.apache.cocoon.components.treeprocessor.sitemap.CallFunctionNode.invoke(CallFunctionNode.java:130) 
at 
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:49) 
at 
org.apache.cocoon.components.treeprocessor.sitemap.PreparableMatchNode.invoke(PreparableMatchNode.java:130) 
at 
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:72) 
at 
org.apache.cocoon.components.treeprocessor.sitemap.PipelineNode.invoke(PipelineNode.java:126) 
at 
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:72) 
at 
org.apache.cocoon.components.treeprocessor.sitemap.PipelinesNode.invoke(PipelinesNode.java:101) 

The Tomcat logs shows me the following:
java.lang.VerifyError: (class: foo/bar/flow/EditSingleContainerFlow, 
method: doEditSingleContainer signature: ()V) Incompatible object 
argument for function call
   at java.lang.Class.getDeclaredMethods0(Native Method)
   at java.lang.Class.privateGetDeclaredMethods(Class.java:1647)
   at java.lang.Class.privateGetPublicMethods(Class.java:1770)
   at java.lang.Class.getMethods(Class.java:824)
   at 
org.apache.cocoon.components.flow.java.JavaInterpreter.initialize(JavaInterpreter.java:96)
   at 
org.apache.cocoon.components.flow.java.JavaInterpreter.callFunction(JavaInterpreter.java:130)
   at 
org.apache.cocoon.components.treeprocessor.sitemap.CallFunctionNode.invoke(CallFunctionNode.java:130)
   at 
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:49)
   at 
org.apache.cocoon.components.treeprocessor.sitemap.PreparableMatchNode.invoke(PreparableMatchNode.java:130)
   at 
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:72)
   at 
org.apache.cocoon.components.treeprocessor.sitemap.PipelineNode.invoke(PipelineNode.java:126)
   at 
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:72)
   at 
org.apache.cocoon.components.treeprocessor.sitemap.PipelinesNode.invoke(PipelinesNode.java:101)
   at 
org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreeProcessor.java:336)
   at 
org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreeProcessor.java:277)
   at 
org.apache.cocoon.components.treeprocessor.sitemap.MountNode.invoke(MountNode.java:103)
   at 
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:49)
   at 
org.apache.cocoon.components.treeprocessor.sitemap.PreparableMatchNode.invoke(PreparableMatchNode.java:130)
   at 
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:72)
   at 
org.apache.cocoon.components.treeprocessor.sitemap.PipelineNode.invoke(PipelineNode.java:126)
   at 
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:72)
   at 
org.apache.cocoon.components.treeprocessor.sitemap.PipelinesNode.invoke(PipelinesNode.java:101)
   at 
org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreeProcessor.java:336)
   at 
org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreeProcessor.java:277)
   at org.apache.cocoon.Cocoon.process(Cocoon.java:619)
   at 
org.apache.cocoon.servlet.CocoonServlet.service(CocoonServlet.java:1073)
   at javax.servlet.http.HttpServlet.service(HttpServlet.java:810)
   at 
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:237)
   at 
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:157)
   at 
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:214)
   at 
org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104)
   at 
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520)
   at 
org.apache.catalina.core.StandardContextValve.invokeInternal(StandardContextValve.java:198)
   at 
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:152)
   at 
org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104)
   at 
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520)
   at 
org.apache.catalina.core.Standard

Re: cvs commit: cocoon-2.1/src/java/org/apache/cocoon/components/flow/javascript/fom FOM_Cocoon.java

[Vadim Gritsenko]

Carsten Ziegeler wrote:
Vadim Gritsenko wrote: 
 

vgritsenko2004/05/28 05:20:20
 Modified:
src/blocks/forms/java/org/apache/cocoon/forms/flow/javascript
   Form.js
  
src/java/org/apache/cocoon/components/flow/javascript/fom
   FOM_Cocoon.java
 Log:
 CocoonComponentManager was moved, but source was not refactored.
 Correcting package name. Forms still do not work - required method
 was removed.
 
   

Which method is needed?
 

Line:
   var objectModel = 
org.apache.cocoon.components.container.CocoonComponentManager.getCurrentEnvironment().getObjectModel();

Method:
   CocoonComponentManager.getCurrentEnvironment()
Try submitting any form from samples.
Vadim

Re: [PMC-IMP] Candidates for PMC chair (was Re: [heads up] PMC chair nominations)

[Gianugo Rabellino]

On Jun 1, 2004, at 2:37 PM, Matthew Langham wrote:
Also, the list proposed by Stefano isn't restrictive and
other PMC members can be nominated or nominate themselves.
I nominate:
Andrew Savory
Gianugo Rabellino (again, just to make sure he doesn't forget to 
accept or
decline :-))
Given the current candidates, it will already be difficult enough to 
choose. As I said on the PMC list, also, I'll be starting a big Cocoon 
based project here which will require me an important onsite presence, 
so I will risk to have very little time to devote to this task. So, I'm 
declining but feel very proud about being nominated: so much proud that 
I'll be glad to nominate myself for the 2005 PMC elections. :-)

Ciao,
--
Gianugo Rabellino
Pro-netics s.r.l. -  http://www.pro-netics.com
Orixo, the XML business alliance: http://www.orixo.com

Re: Excalibur becomes Top-level project.

[Berin Loritsch]

Niclas Hedhman wrote:
Everyone,
For those who doesn't subscribe to [EMAIL PROTECTED] or 
[EMAIL PROTECTED], I would like to inform that the ASF Board approved 
the motion to create  Apache Excalibur top-level project, and Leo Simons has 
been appointed as its Chair.

To Avalon that means we hand-over the "avalon-excalibur" repository, which 
includes;

  *  Excalibur Component Manager
  *  Excalibur system components, such as thread, logger, pool et el.
  *  Fortress
  *  Site documentation for these pieces.
If Excalibur TLP also wants to resume control of "avalon-phoenix", they are 
welcome to do so.

Perhaps something from the avalon-sandbox will be transferred.
My Question to Excalibur TLP is basically;
Is there anything that Excalibur TLP wants the Avalon TLP to do prior to the 
transfer, in respect to these codebases?
I don't think so, but let me find out.
--
"Programming today is a race between software engineers striving to 
build bigger and better idiot-proof programs, and the Universe trying to 
produce bigger and better idiots. So far, the Universe is winning."
- Rich Cook

Re: [PMC-IMP] Candidates for PMC chair (was Re: [heads up] PMC chair nominations)

[Andrew Savory]

Hi,
On 1 Jun 2004, at 13:37, Matthew Langham wrote:
Also, the list proposed by Stefano isn't restrictive and
other PMC members can be nominated or nominate themselves.
I nominate:
Andrew Savory
Gianugo Rabellino (again, just to make sure he doesn't forget to 
accept or
decline :-))
I accept the nomination, thanks. Tough competition though ;-)
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: JXTG and caching

[Leszek Gawron]

Sylvain Wallez wrote:
Leszek Gawron wrote:
While almost everybody buried XSP it has got one great feature that 
JXTG  lacks: it's cacheable. I know that there is no way to implement 
automatic JXTG caching but what if I know on what env does jx template 
operate. If I know that it is for example only request param "abc" and 
"bcd" and session attribute "xxx" then I know when I can use cached 
entry. The question is: how?

Should I extend JXTemplateGenerator so it is a cached component? I 
understand it gets the validity methods to implement then. So every 
time I call my extended component from flow I pass also the validity 
calculated in flow. Something like this:

function niceCachedResponse() {
  var cacheKey = cocoon.request.get( "abc" ) + "!!spacer!!"
+ cocoon.request.get( "bcd" ) + "!!spacer!!"
+ cocoon.session.getAttribute( "xxx" );
  var pageValidity = new DeltaTimeCacheValidity( 60 * 60 * 24 );
// one day
  cocoon.sendPage( "view/cached.jx", {
 JXTGExtCacheKey: cacheKey,
 JXTGExtpageValidity: pageValidity
 someOtherBizData: data } );
}
Does it have a chance to work ?

Well, it _could_ have a chance to work, but flowscript is definitely not 
the appropriate location to compute cache information for an element of 
the view pipeline.
I started to implement the functionality we discussed but then it hit me: it's 
completely useles for my case. Look at this:

function showData() {
  var bizData = {};
  bizData[ "pageData" ] = fetchBizDataByHeavyDBRetrieval();
  var validity = cocoon.createObject( DBViewValidity );
  bizData[ "cacheingInfo" ] = validity;
  cocoon.sendPage( "view/someview.jx",
   bizData,
   function() {
 cocoon.releaseObject( validity );
   } );
}
What is the point of implementing caching control in JXTG in this case if I do 
 "heavy db retrieval" anyway.

CachingJXTG is good here only for those cases which in which one can omit 
bizData preparation.

It would have to look somewhat like this:
function showData() {
  var validityKey = "request-param:a!!spacer!!request-param:b";
  var pipeline = "view/someview.jx"
  if ( someCacheManager.isValid( pipeline, validityKey ) ) {
// hope the cache entry does not expire between isValid and page
// generation
var dummyBizData = {};
cocoon.sendPage( "view/someview.jx", dummyBizData );
return;
  }
  // the page is not cached
  // do the heavy processing here and send new page
  var bizData = {};
  bizData[ "pageData" ] = fetchBizDataByHeavyDBRetrieval();
  var validity = cocoon.createObject( DBViewValidity );
  bizData[ "cacheingInfo" ] = validity;
  cocoon.sendPage( "view/someview.jx",
   bizData,
   function() {
 cocoon.releaseObject( validity );
   } );
}
It does not look like SoC.
LG
--
Leszek Gawron

Changes to cocoon:/ protocol processing?

[Andreas Hartmann]

Hi Cocoon developers,
ATM, Lenya does not work with the Cocoon CVS head.
It seems like cocoon:/ URLs are resolved in another way.
Has anything changed in this area? How can I debug it?
Thanks in advance!
-- Andreas

Re: Large xml's in cocoon

[Ugo Cei]

Upayavira wrote:
Switching to Jetty was the best thing we did - Tomcat fell over all the 
time. Jetty has just stayed up.
I find Tomcat 5 to be infinitely more stable and performant than Tomcat 
4, so I can live with that for the moment.

If you ever decide to switch, let me know and I'll send you config samples.
We are in the process of ordering a couple new servers, so we might 
switch when we install them. But it's more probable that I switch jobs 
before we switch application servers ;-). Thank you anyway.

Ugo

Re: [heads up] PMC chair nominations

[Antonio Gallardo]

Vadim Gritsenko dijo:
> Stefano Mazzocchi wrote:
>
>> The ASF board decided not to accept Steven's resigns until the PMC
>> itself came up with a new informed decision on who should follow him.
>>
>> This means that Steven remains the chair until the board ratifies it.
>>
>> Here I would like to start the nominations (in no particular order):
>>
>>  - Vadim Gritsenko
>>  - Sylvain Wallez
>>  - Matthew Langham
>>  - Gianugo Rabellino
>>  [- Bertrand Delacretaz]
>>
>> Bertrand already rejected the nomination but I still wanted to mention
>> him as being part of my list.
>>
>> Given my participation as a board director, and as coherence with my
>> past public and private actions, I will not accept a nomination as the
>> Cocoon PMC chair.
>>
>> If you think somebody else should be in the ballot that is not listed
>> above, please add him/her to the list.
>>
>> If you are listed and you don't want to accept the nomination, please
>> say so.
>>
>> As for the duty of the PMC chair, I think that a great chair is
>> somebody that doesn't do much at all and makes sure to collect the
>> feedback and pass it along to the board, or make sure that board
>> actions are passed down to the PMC.
>>
>> The PMC chair should not be doing stuff for others, it should just be
>> the social bridge between two different communities.
>
>
> Given this job description; I'll accept your nomination ;-)

The decision will be a hard one. All candidates are great! ;-)

Best regards,

Antonio Gallardo

Re: [heads up] PMC chair nominations

[Vadim Gritsenko]

Stefano Mazzocchi wrote:
The ASF board decided not to accept Steven's resigns until the PMC 
itself came up with a new informed decision on who should follow him.

This means that Steven remains the chair until the board ratifies it.
Here I would like to start the nominations (in no particular order):
 - Vadim Gritsenko
 - Sylvain Wallez
 - Matthew Langham
 - Gianugo Rabellino
 [- Bertrand Delacretaz]
Bertrand already rejected the nomination but I still wanted to mention 
him as being part of my list.

Given my participation as a board director, and as coherence with my 
past public and private actions, I will not accept a nomination as the 
Cocoon PMC chair.

If you think somebody else should be in the ballot that is not listed 
above, please add him/her to the list.

If you are listed and you don't want to accept the nomination, please 
say so.

As for the duty of the PMC chair, I think that a great chair is 
somebody that doesn't do much at all and makes sure to collect the 
feedback and pass it along to the board, or make sure that board 
actions are passed down to the PMC.

The PMC chair should not be doing stuff for others, it should just be 
the social bridge between two different communities.

Given this job description; I'll accept your nomination ;-)
Vadim

RE: [PMC-IMP] Candidates for PMC chair (was Re: [heads up] PMC chair nominations)

[Matthew Langham]

> Also, the list proposed by Stefano isn't restrictive and 
> other PMC members can be nominated or nominate themselves.
> 

I nominate:

Andrew Savory
Gianugo Rabellino (again, just to make sure he doesn't forget to accept or
decline :-))

Matthew

Re: [heads up] PMC chair nominations

[Bertrand Delacretaz]

Le 31 mai 04, à 12:25, Stefano Mazzocchi a écrit :
...Bertrand already rejected the nomination but I still wanted to 
mention him as being part of my list
Thanks.
As this is now a public discussion, Let me just restate my reasons 
publicly so that there's no mystery about this: I'd be willing to do my 
part, but the timing is bad for me, due to a biiig overseas trip this 
summer combined with other new volunteer work that I have accepted in 
my local community.

So it's wiser for me not to accept the nomination at this time. Maybe 
next time ;-)

-Bertrand

[PMC-IMP] Candidates for PMC chair (was Re: [heads up] PMC chair nominations)

[Sylvain Wallez]

Matthew Langham wrote:
The nominations should be made and the nominees themselves either acceptor reject.
   

Also, the list proposed by Stefano isn't restrictive and other PMC 
members can be nominated or nominate themselves.

Yepp - we were getting ahead of ourselves I think. Anyway, as stated in the last mail, I accept my nomination.
 

So let's build the list of candidates. In order for people to have 
enough time to jump in, I propose to close the list tomorrow, June 2, at 
14:00 CEST (GMT+0200) and start a vote afterwards. This makes 24 hours 
from now on and 48 hours after Stefano's initial post.

The candidates to the PMC chair are:
- Matthew Langham
- Sylvain Wallez
(add your name here if you're a PMC member and candidate).
Sylvain
--
Sylvain Wallez  Anyware Technologies
http://www.apache.org/~sylvain   http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }

DO NOT REPLY [Bug 26392] - failing Cocoon 2.0.4 deployment on Tomcat 5 through broken Batik JAR

[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=26392

failing Cocoon 2.0.4 deployment on Tomcat 5 through broken Batik JAR





--- Additional Comments From [EMAIL PROTECTED]  2004-06-01 12:04 ---
This should have been resolved as WONTFIX, not as FIXED.

DO NOT REPLY [Bug 26392] - failing Cocoon 2.0.4 deployment on Tomcat 5 through broken Batik JAR

[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=26392

failing Cocoon 2.0.4 deployment on Tomcat 5 through broken Batik JAR

[EMAIL PROTECTED] changed:

   What|Removed |Added

 CC||[EMAIL PROTECTED]
 Status|RESOLVED|CLOSED

DO NOT REPLY [Bug 26392] - failing Cocoon 2.0.4 deployment on Tomcat 5 through broken Batik JAR

[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=26392

failing Cocoon 2.0.4 deployment on Tomcat 5 through broken Batik JAR

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution||FIXED



--- Additional Comments From [EMAIL PROTECTED]  2004-06-01 11:55 ---
No, distributions are distributed and so remain untouched forever. It's an
immutable collection of files of a specific date. The reason is simple: If we
change a distribution we might break it at another place. At the end we have 5
different versions of one dist and five different errors. How shall one
reference a specific version of a dist?

The JAR is fixed in cocoon-2.0 CVS, but there will probably never be a final
Cocoon 2.0.5 as it would be to much effort to put all the files into Apache
License 2.0 - and that's a requirement by the Apache Software Foundation for
released stuff since 1st March 2004.

If it's possible for you, you should grab Cocoon 2.0 from CVS, maybe there are
also snapshots available. Cocoon 2.0 CVS is "release ready", we only missed the
deadline mentioned above to do a final release. If you need a working an
released version you have to switch to Cocoon 2.1. Don't fear the build process
itself in both 2.0 CVS and 2.1 releases. Especially in the latter ones it's easy
to build Cocoon yourself.

DO NOT REPLY [Bug 26392] - failing Cocoon 2.0.4 deployment on Tomcat 5 through broken Batik JAR

[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=26392

failing Cocoon 2.0.4 deployment on Tomcat 5 through broken Batik JAR

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|CLOSED  |REOPENED
 Resolution|FIXED   |



--- Additional Comments From [EMAIL PROTECTED]  2004-06-01 11:04 ---
The bug is not fixed for Tomcat 5.0.25 and Cocoon 2.0.4 - downloaded binary 
distribution today and had the same error. The only thing helped is the 
unpacking/packing of \webapps\cocoon\WEB-INF\lib\batik-all-1.5b2.jar with 
WinRar. 
Is it possible to include correct version of archieve to the binary 
distribution?

Re: [heads up] PMC chair nominations

[David Crossley]

> +1
> (couldn't resist ;-)

:-) and i couldn't resist the chance to practice
my new Forrest chairperson skills. Good luck to
whoever gets the Cocoon job.

--David

RE: [heads up] PMC chair nominations

[Matthew Langham]

> The nominations should be made and the nominees themselves either accept
or reject.

Yepp - we were getting ahead of ourselves I think. Anyway, as stated in the
last mail, I accept my nomination.

Matthew

Re: [heads up] PMC chair nominations

[Reinhard Poetz]

David Crossley wrote:
It is very confusing when people use the "+1" thing
in general conversation. What are you plussing?
The nominations should be made and the nominees themselves
either accept or reject. There is no voting to be done
until we have clear nominations in front of us.
 

+1
(couldn't resist ;-)
--
Reinhard

Re: [heads up] PMC chair nominations

[Bertrand Delacretaz]

Le 1 juin 04, à 11:48, David Crossley a écrit :
It is very confusing when people use the "+1" thing
in general conversation. What are you plussing?
In my case, showing agreement/appreciation about what's being said.
Sorry if this is confusing, point taken.
...The nominations should be made and the nominees themselves
either accept or reject. There is no voting to be done
until we have clear nominations in front of us.
100% agreed (now I have to refrain from saying +1 here ;-)
-Bertrand

Re: JXTG and caching

[Sylvain Wallez]

Leszek Gawron wrote:
Sylvain Wallez wrote:
Leszek Gawron wrote:
Sylvain Wallez wrote:
 

One question: if this NewsHelper is NOT an avalon component (or 
object instantiated by flow.createObject) then it doesn't have acces 
to any backend logic or data (for example database that stores 
expiration time for different news services). Would it be possible 
to instantiate this object via flow.createObject analogy?


Two anwsers to this:
- we could add a builtin "createObject()" to the JXG expression 
language, thus directly solving your problem. I don't think this is a 
good idea as it opens the door to too much code in the template.
I do not like it either.
- the NewsHelper object can be created in the flow and passed as 
viewData. This keeps things clean: the flow gives necessary data to 
the view, and the view pulls what it needs from that data, including 
means to compute the cache information.
That's fine by me. It's nearly the same what I proposed (if not the 
same). If somebody gave me some points I would like to implement some 
version of it.

Thinking out loud:
1. flow passes cache info to template via some object instance that 
provides cache key and validity. It could be 2 objects (one for key 
one for validity) but it looks like one object is cleaner (we could 
impose some interface - is there one in cocoon already?)

What flow passes to the view is completely up to your choices.
2. There is CachingJXTemplateGenerator that extends the one we have now.
3. CJXTG implements getKey() and getValidity(). According to cocoon 
docs if null is passed from these methods the result is not being 
cached. So we could even modify the existing generator and have only 
one that does caching or not.

Yep. No need for a cacheable extension.
4. "Compiled" page template has to hold 2 more values - cache key and 
validity assuming the values are Jexl or JXpath expressions.

Yep.
5. getValidity() and getKey() have access to the template and flow 
bizData (via FlowHelper). When invoked they get appropriate 
jexl(jxpath) expression and evaluate it against bizData. If there is 
no jx:cache-key jx:validity defined then null is returned and no 
caching is being performed.

Exactly.
6. voilla we have a jxtemplate that is very performant for sites 
slashdot like  (I mean lots of reads, infrequent page updates).

Yupp.
I would like to become an active contributor but the entry step is too 
big without your help. I know it sounds a bit like a waste of time 
talking some simple functionality over and then doing the review 
instead of implementing it by oneself but if you choose the first 
variant you'll have a new active contributor in some future (near I hope).

You also have to consider time: we often don't have the time to 
implement all the nice feature we discuss here, and new contributors are 
therefore very welcome.

So ask whatever you need to get started, we'll try to help you in your 
way inside the Cocoon internals. Others will certainly learn from that 
too. About caching, you may want to read a wiki page [1] explaining how 
the pipeline machinery works.

[1] http://wiki.cocoondev.org/Wiki.jsp?page=WritingForCacheEfficiency
Sylvain
--
Sylvain Wallez  Anyware Technologies
http://www.apache.org/~sylvain   http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }

Re: [heads up] PMC chair nominations

[David Crossley]

It is very confusing when people use the "+1" thing
in general conversation. What are you plussing?

The nominations should be made and the nominees themselves
either accept or reject. There is no voting to be done
until we have clear nominations in front of us.

--David

Re: JXTG and caching

[Torsten Curdt]

I actually do think that the JX language can be rewritten as a Jelly 
taglib. Any taker?
Actually when talking about alternatives to XSP also Jelly
came to my mind. What do you think?
Plus it already comes with a good set of taglibs.
cheers
--
Torsten

Re: JXTG and caching

[Leszek Gawron]

Sylvain Wallez wrote:
Well, although not the nicest construct, I still prefer it to the one 
you initially proposed, as the cache information is still triggered by 
the generator, even if the corresponding code is in the flowscript.
Right, I didn't think of that. Your solution is a "pull" while mine is "push" one.
--
Leszek Gawron

Re: JXTG and caching

[Leszek Gawron]

Sylvain Wallez wrote:
Leszek Gawron wrote:
Sylvain Wallez wrote:
 

One question: if this NewsHelper is NOT an avalon component (or object 
instantiated by flow.createObject) then it doesn't have acces to any 
backend logic or data (for example database that stores expiration 
time for different news services). Would it be possible to instantiate 
this object via flow.createObject analogy?

Two anwsers to this:
- we could add a builtin "createObject()" to the JXG expression 
language, thus directly solving your problem. I don't think this is a 
good idea as it opens the door to too much code in the template.
I do not like it either.
- the NewsHelper object can be created in the flow and passed as 
viewData. This keeps things clean: the flow gives necessary data to the 
view, and the view pulls what it needs from that data, including means 
to compute the cache information.
That's fine by me. It's nearly the same what I proposed (if not the same). If 
somebody gave me some points I would like to implement some version of it.

Thinking out loud:
1. flow passes cache info to template via some object instance that provides 
cache key and validity. It could be 2 objects (one for key one for validity) 
but it looks like one object is cleaner (we could impose some interface - is 
there one in cocoon already?)

2. There is CachingJXTemplateGenerator that extends the one we have now.
3. CJXTG implements getKey() and getValidity(). According to cocoon docs if 
null is passed from these methods the result is not being cached. So we could 
even modify the existing generator and have only one that does caching or not.

4. "Compiled" page template has to hold 2 more values - cache key and validity 
assuming the values are Jexl or JXpath expressions.

5. getValidity() and getKey() have access to the template and flow bizData 
(via FlowHelper). When invoked they get appropriate jexl(jxpath) expression 
and evaluate it against bizData. If there is no jx:cache-key jx:validity 
defined then null is returned and no caching is being performed.

6. voilla we have a jxtemplate that is very performant for sites slashdot like 
 (I mean lots of reads, infrequent page updates).

I would like to become an active contributor but the entry step is too big 
without your help. I know it sounds a bit like a waste of time talking some 
simple functionality over and then doing the review instead of implementing it 
by oneself but if you choose the first variant you'll have a new active 
contributor in some future (near I hope).

--
Leszek Gawron

Re: JXTG and caching

[Upayavira]

Leszek Gawron wrote:
Upayavira wrote:
Leszek Gawron wrote:
Sylvain Wallez wrote:
 

One question: if this NewsHelper is NOT an avalon component (or 
object instantiated by flow.createObject) then it doesn't have acces 
to any backend logic or data (for example database that stores 
expiration time for different news services). Would it be possible 
to instantiate this object via flow.createObject analogy?

Of course. You could equally well say:
sendPage("my-url", {"myObject", myAvalonObject});

Regards, Upayavira

But that does not differ from what I proposed in first post and 
Sylvain wrote it is a bad idea.
I would say it is different, in as much as previously you calculated the 
validity in flowscript. Now, you pass in an object, and the template 
asks the object for its validity. So the object itself knows how to 
decide whether it is valid or not, which seems quite reasonable to me.

Adding that level of complexity to flowscript can make your flowscripts 
very complex very quickly. That is what I believe Sylvain is objecting to.

Regards, Upayavira

DO NOT REPLY [Bug 29308] - issue with javaflow continuations

[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=29308

issue with javaflow continuations





--- Additional Comments From [EMAIL PROTECTED]  2004-06-01 09:36 ---
>From the TODO.txt file:

 - The classloader seems to have problems with inner classes, because the
   the inner classes is not transformed by the ContinuationClassLoader, which
   caused a LinkageError.
   Temporary solution is to implement Continuable for the inner class.

This can be fixed, if another selection was found to determine
which classes must be transformed, instead of implementing Continuable.
Maybe some wildcard statement, like transform all "mycasses.*".
Using a marker inferface also doesn't work if you use third party libraries.
I don't know. Maybe you have an idea.

Re: JXTG and caching

[Sylvain Wallez]

Leszek Gawron wrote:
Upayavira wrote:
Leszek Gawron wrote:
Sylvain Wallez wrote:
 

One question: if this NewsHelper is NOT an avalon component (or 
object instantiated by flow.createObject) then it doesn't have acces 
to any backend logic or data (for example database that stores 
expiration time for different news services). Would it be possible 
to instantiate this object via flow.createObject analogy?

Of course. You could equally well say:
sendPage("my-url", {"myObject", myAvalonObject});

Regards, Upayavira
But that does not differ from what I proposed in first post and 
Sylvain wrote it is a bad idea.

Please read my last post. There's a subtle but very important 
difference: the cache information is computed *by the template* even if 
the information needed for that is given in the view data.

And this distinction is important, as that's in the template that we 
precisely know what constitutes the cache validity. Moreover, you may 
consider the case of complex pipelines where the actual template depends 
on the user rights, target browser or whatever else. In that case, the 
cache information can be different depending on used template.

So, in simple words: cache information is a concern of pipeline 
components, data needed to compute it can come from anywhere, including 
flowscript view data.

Sylvain
--
Sylvain Wallez  Anyware Technologies
http://www.apache.org/~sylvain   http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }

Re: JXTG and caching

[Sylvain Wallez]

Leszek Gawron wrote:
Sylvain Wallez wrote:
Well, it _could_ have a chance to work, but flowscript is definitely 
not the appropriate location to compute cache information for an 
element of the view pipeline.
not the appropriate .. but really there is no other place ..
The problem with JXG is that the template is the generate() method 
_only_ whereas an XSP is the full class, allowing to define getKey() 
and getValidity().

So what about adding two optional attributes on the template's root 
element, defining the cache information?


   xmlns:jx="http://apache.org/cocoon/templates/jx/1.0";
   jx:cache-key='${cocoon.request.get("abc") + "!!spacer!!" + 
cocoon.request.get("bcd")'
   jx:cache-validity='${new DeltaTimeCacheValidity(60 * 60 * 24)}'>
   ... template 


WDYT?
Fine for simple cases but limits of this solution will appear very fast.
I just know what would users do (what I would also do if I wanted 
something more complex)

the .js file:
function validityForView() {
  var validity = new SomeVeryHardToComputeInOneLineValidity();
  return validity;
}
function keyForView() {
  var key = someVeryStrangeKeyFetchedFromSomewhere;
  return key;
}
function showSomeView() {
  cocoon.session.setAttribute( "myViewValidityFunc", validityForView );
  cocoon.session.setAttribute( "myViewKey", keyForView );
  cocoon.sendPage( "view/myview.jx", {} );
}
the template:
http://apache.org/cocoon/templates/jx/1.0";
   jx:cache-key='${cocoon.session.myViewKey()}'
   jx:cache-validity='${cocoon.session.myViewValidityFunc()}'>
   ... template 


Well, although not the nicest construct, I still prefer it to the one 
you initially proposed, as the cache information is still triggered by 
the generator, even if the corresponding code is in the flowscript.

This and other examples proove that we need a way to extend jxtemplate 
generator with flow functions (or other logic "providers") when simple 
macro is not enough. This may lead to a jsb taglib nightmare but hey: 
user has got his own brain not to put database inserts in there and if 
he is he's just asking for troubles.

I still do not understand why we do have jx:formatDate and 
jx:formatNumber which are just some instances of formatters while 
there either should be none at all or just pluggable ones.


I totally agree with you. The  is good for simple cases, but 
we need taglibs à la XSP or Jelly.

I actually do think that the JX language can be rewritten as a Jelly 
taglib. Any taker?

Sylvain
--
Sylvain Wallez  Anyware Technologies
http://www.apache.org/~sylvain   http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }

DO NOT REPLY [Bug 28724] - FragmentExtractor always returns same fragment

[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=28724

FragmentExtractor always returns same fragment





--- Additional Comments From [EMAIL PROTECTED]  2004-06-01 09:28 ---
Resolved, thank you:
see below a log extract of sitemap.xmap:
grep fragmentID sitemap.log
DEBUG   (2004-06-01) 11:00.02:047   [sitemap.transformer.extractor] 
(/netstat/portstat/logarithm.html) PoolThread-4/FragmentExtractorTransformer: 
setup(): fragmentID now 0.
DEBUG   (2004-06-01) 11:00.11:375   [sitemap.transformer.extractor] 
(/netstat/portstat/logarithm.html) PoolThread-4/FragmentExtractorTransformer: 
startElement(): fragmentID now 1.
DEBUG   (2004-06-01) 11:00.15:373   [sitemap.transformer.extractor] 
(/netstat/portstat/logarithm.html) PoolThread-4/FragmentExtractorTransformer: 
endElement(): fragmentID now 1.
DEBUG   (2004-06-01) 11:01.19:122   [sitemap.transformer.extractor] 
(/netstat/portstat/logarithm.html) PoolThread-4/FragmentExtractorTransformer: 
setup(): fragmentID now 0.
DEBUG   (2004-06-01) 11:01.22:234   [sitemap.transformer.extractor] 
(/netstat/portstat/logarithm.html) PoolThread-4/FragmentExtractorTransformer: 
startElement(): fragmentID now 1.
DEBUG   (2004-06-01) 11:01.25:712   [sitemap.transformer.extractor] 
(/netstat/portstat/logarithm.html) PoolThread-4/FragmentExtractorTransformer: 
endElement(): fragmentID now 1.

so I changed the setup() in FragmentExtractorTransformer.java, because it's 
called every time, when the client makes a new request . The map type of the 
pipeline is default, means 'cacheable', cocoon version V2.1.5.
//fragmentID = 0;

And now it works.
Sarah

Re: [heads up] PMC chair nominations

[Sylvain Wallez]

Matthew Langham wrote:
Looks like this thread is now stuck to the dev list :).
 

- Vadim Gritsenko
- Sylvain Wallez
- Matthew Langham
- Gianugo Rabellino
[- Bertrand Delacretaz]
   

I was very honored by the nomination and would have been willing to step up
to bat if no-one else was interested. But, Sylvain has already accepted his
nomination, received a couple of votes and would be a good choice for PMC
chair.
So here's my +1 for Sylvain also.
 

Well, thanks all for your support, but I wouldn't like to be the new PMC 
chair simply because I was the first one to make my voice heard!

Sylvain
--
Sylvain Wallez  Anyware Technologies
http://www.apache.org/~sylvain   http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }

Re: JXTG and caching

[Leszek Gawron]

Upayavira wrote:
Leszek Gawron wrote:
Sylvain Wallez wrote:
 

One question: if this NewsHelper is NOT an avalon component (or object 
instantiated by flow.createObject) then it doesn't have acces to any 
backend logic or data (for example database that stores expiration 
time for different news services). Would it be possible to instantiate 
this object via flow.createObject analogy?

Of course. You could equally well say:
sendPage("my-url", {"myObject", myAvalonObject});

Regards, Upayavira

But that does not differ from what I proposed in first post and Sylvain wrote 
it is a bad idea.

--
Leszek Gawron

Re: JXTG and caching

[Sylvain Wallez]

Leszek Gawron wrote:
Sylvain Wallez wrote:
 
One question: if this NewsHelper is NOT an avalon component (or object 
instantiated by flow.createObject) then it doesn't have acces to any 
backend logic or data (for example database that stores expiration 
time for different news services). Would it be possible to instantiate 
this object via flow.createObject analogy?

Two anwsers to this:
- we could add a builtin "createObject()" to the JXG expression 
language, thus directly solving your problem. I don't think this is a 
good idea as it opens the door to too much code in the template.
- the NewsHelper object can be created in the flow and passed as 
viewData. This keeps things clean: the flow gives necessary data to the 
view, and the view pulls what it needs from that data, including means 
to compute the cache information.

Sylvain
--
Sylvain Wallez  Anyware Technologies
http://www.apache.org/~sylvain   http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }

Re: JXTG and caching

[Bertrand Delacretaz]

Le 1 juin 04, à 10:48, Sylvain Wallez a écrit :
...Taking your example of news urgency, the corresponding algorithm 
would certainly not fit into a single attribute (because of the "if" 
constructs it's likely to contain), but could simply be written as :

 
Sounds good!
Moreover, I find that being limited to a single attribute enforces 
good SoC by forbidding complicated code in the template.
+1
-Bertrand

Re: [heads up] PMC chair nominations

[Gianugo Rabellino]

On Jun 1, 2004, at 10:13 AM, Sylvain Wallez wrote:
 - Vadim Gritsenko
 - Sylvain Wallez
 - Matthew Langham
 - Gianugo Rabellino
 [- Bertrand Delacretaz]
Ah, and contrarily to last year, I do accept the nomination ;-)
And you get my reliefed +1 in return. :-)
Ciao,
--
Gianugo Rabellino
Pro-netics s.r.l. -  http://www.pro-netics.com
Orixo, the XML business alliance: http://www.orixo.com

Re: JXTG and caching

[Upayavira]

Leszek Gawron wrote:
Sylvain Wallez wrote:
 
One question: if this NewsHelper is NOT an avalon component (or object 
instantiated by flow.createObject) then it doesn't have acces to any 
backend logic or data (for example database that stores expiration 
time for different news services). Would it be possible to instantiate 
this object via flow.createObject analogy?
Of course. You could equally well say:
sendPage("my-url", {"myObject", myAvalonObject});

Regards, Upayavira

Re: JXTG and caching

[Leszek Gawron]

Sylvain Wallez wrote:
 
One question: if this NewsHelper is NOT an avalon component (or object 
instantiated by flow.createObject) then it doesn't have acces to any backend 
logic or data (for example database that stores expiration time for different 
news services). Would it be possible to instantiate this object via 
flow.createObject analogy?

--
Leszek Gawron

RE: [heads up] PMC chair nominations

[Matthew Langham]

Looks like this thread is now stuck to the dev list :).

> >>
> >>  - Vadim Gritsenko
> >>  - Sylvain Wallez
> >>  - Matthew Langham
> >>  - Gianugo Rabellino
> >>  [- Bertrand Delacretaz]
> >>

I was very honored by the nomination and would have been willing to step up
to bat if no-one else was interested. But, Sylvain has already accepted his
nomination, received a couple of votes and would be a good choice for PMC
chair.

So here's my +1 for Sylvain also.

Matthew

Re: Large xml's in cocoon

[Upayavira]

Ugo Cei wrote:
Pier Fumagalli wrote:
Oh, on a side note, Ugo, I'd seriously switch your 
development/production environments... I'm not going into performance 
details (I don't want to raise a can of worms), but at least on my 
tests Tomcat is using 3x the memory that Jetty is using per single 
request, so it's more likely for you to have OOMEs on Tomcat rather 
than Jetty.

I couldn't agree more with this, Pier, but until my boss gets me a new 
engineer, I'm not going to learn how to properly configure Jetty for 
vhosts, authentication, logging and HTTPS and switch over. I don't 
want to do this job anymore, so they stay where they are ;-).
Whilst I can undestand the sentiment of not wanting to do sysadmin work, 
I would say that Jetty is _far_ easier to configure than Tomcat. It is 
in fact just far simpler alround. Vhosts are easy, as is authentication 
realms (I can send you config samples). For logging, I'm not that sure 
(we just redirect Jetty's console to a file). HTTPs listeners are 
available in Jetty's default config file, including examples of how to 
refer to your keystore.

Switching to Jetty was the best thing we did - Tomcat fell over all the 
time. Jetty has just stayed up.

If you ever decide to switch, let me know and I'll send you config samples.
Regards, Upayavira

Re: [heads up] PMC chair nominations

[Antonio Gallardo]

Bertrand Delacretaz dijo:
> Le 1 juin 04, à 10:13, Sylvain Wallez a écrit :
>> ...I see no problem with the PMC election process occuring in public.
>> There's nothing confidential in it.
>
> +1

Same here: +1.

>
>> ...Ah, and contrarily to last year, I do accept the nomination ;-)
>
> Good news!
> +1 for Sylvain.

+1

> (now, if several people accept, how do we choose between these bright
> nice dedicated gentlemen ;-)

+1 too! :-D

Best Regards,

Antonio Gallardo

Re: JXTG and caching

[Sylvain Wallez]

Bertrand Delacretaz wrote:
Le 1 juin 04, à 10:09, Sylvain Wallez a écrit :
...Well, it _could_ have a chance to work, but flowscript is 
definitely not the appropriate location to compute cache information 
for an element of the view pipeline

flowscript maybe not but how about backend java code?
Use-case: for a news site, you might want the cache validity to be 
dependent on the "urgency" of the news, for example cache older news 
for a longer time, assuming they won't change much anymore.

In this case the cache validity (or at least hints to the appropriate 
validity range) needs to come from the backend.

...So what about adding two optional attributes on the template's 
root element, defining the cache information?


   xmlns:jx="http://apache.org/cocoon/templates/jx/1.0";
   jx:cache-key='${cocoon.request.get("abc") + "!!spacer!!" + 
cocoon.request.get("bcd")'
   jx:cache-validity='${new DeltaTimeCacheValidity(60 * 60 * 24)}'>
   ... template 


I like the idea, and IIUC it would also allow the Flow to receive the 
DeltaTimeCacheValidity (for example) from your java code and pass it 
down to JXTG, right?

jx:cache-validity='${someObjectComingFromJavaCodeViaFlow}'>
Or, in other words, do you see this as having access to any additional 
variables passed in the cocoon.sendPage call?

Sure. Since the expression is evaluated, you can access any information 
that is needed, and also some backend code.

Taking your example of news urgency, the corresponding algorithm would 
certainly not fit into a single attribute (because of the "if" 
constructs it's likely to contain), but could simply be written as :

 

Moreover, I find that being limited to a single attribute enforces good 
SoC by forbidding complicated code in the template.

Sylvain
--
Sylvain Wallez  Anyware Technologies
http://www.apache.org/~sylvain   http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }

Re: JXTG and caching

[Leszek Gawron]

Sylvain Wallez wrote:
Well, it _could_ have a chance to work, but flowscript is definitely not 
the appropriate location to compute cache information for an element of 
the view pipeline.
not the appropriate .. but really there is no other place ..
The problem with JXG is that the template is the generate() method 
_only_ whereas an XSP is the full class, allowing to define getKey() and 
getValidity().

So what about adding two optional attributes on the template's root 
element, defining the cache information?


   xmlns:jx="http://apache.org/cocoon/templates/jx/1.0";
   jx:cache-key='${cocoon.request.get("abc") + "!!spacer!!" + 
cocoon.request.get("bcd")'
   jx:cache-validity='${new DeltaTimeCacheValidity(60 * 60 * 24)}'>
   ... template 


WDYT?
Fine for simple cases but limits of this solution will appear very fast.
I just know what would users do (what I would also do if I wanted something 
more complex)

the .js file:
function validityForView() {
  var validity = new SomeVeryHardToComputeInOneLineValidity();
  return validity;
}
function keyForView() {
  var key = someVeryStrangeKeyFetchedFromSomewhere;
  return key;
}
function showSomeView() {
  cocoon.session.setAttribute( "myViewValidityFunc", validityForView );
  cocoon.session.setAttribute( "myViewKey", keyForView );
  cocoon.sendPage( "view/myview.jx", {} );
}
the template:
http://apache.org/cocoon/templates/jx/1.0";
   jx:cache-key='${cocoon.session.myViewKey()}'
   jx:cache-validity='${cocoon.session.myViewValidityFunc()}'>
   ... template 

This and other examples proove that we need a way to extend jxtemplate 
generator with flow functions (or other logic "providers") when simple macro 
is not enough. This may lead to a jsb taglib nightmare but hey: user has got 
his own brain not to put database inserts in there and if he is he's just 
asking for troubles.

I still do not understand why we do have jx:formatDate and jx:formatNumber 
which are just some instances of formatters while there either should be none 
at all or just pluggable ones. Like these:

function stringToSAX( str, consumer, ignoreRootElement ) {
var is = new Packages.org.xml.sax.InputSource( new java.io.StringReader( str ) 
);
var ignore = ( ignoreRootElement == "true" );
var parser = null;
var includeConsumer = new org.apache.cocoon.xml.IncludeXMLConsumer( consumer, 
consumer );
includeConsumer.setIgnoreRootElement( true );
try {   
parser = cocoon.getComponent( 
Packages.org.apache.excalibur.xml.sax.SAXParser.ROLE );
parser.parse( is, includeConsumer );
} finally {
if ( parser != null ) cocoon.releaseComponent( parser );
}
}

function wikiToSAX( str, consumer ) {
var radeoxStr = radeoxEngine.render( str, radeoxContext );
var buffer = new java.lang.StringBuffer("" );
buffer.append( radeoxStr )
buffer.append( "" );
var is = new Packages.org.xml.sax.InputSource( new java.io.StringReader( 
buffer.toString() ) );
var parser = null;
var includeConsumer = new org.apache.cocoon.xml.IncludeXMLConsumer( consumer, 
consumer );
includeConsumer.setIgnoreRootElement( true );
try {   
parser = cocoon.getComponent( 
Packages.org.apache.excalibur.xml.sax.SAXParser.ROLE );
parser.parse( is, includeConsumer );
} finally {
if ( parser != null ) cocoon.releaseComponent( parser );
}
}
Now I have to do the same session trick and build a macro:




I did not mean to sound unpleasant by any way. I would like to contribute 
something more than bug reports but I do not know cocoon's internals that much 
to catch all possible problems.

--
Leszek Gawron

Re: [heads up] PMC chair nominations

[Bertrand Delacretaz]

Le 1 juin 04, à 10:13, Sylvain Wallez a écrit :
...I see no problem with the PMC election process occuring in public. 
There's nothing confidential in it.
+1
...Ah, and contrarily to last year, I do accept the nomination ;-)
Good news!
+1 for Sylvain.
(now, if several people accept, how do we choose between these bright 
nice dedicated gentlemen ;-)

-Bertrand

Re: JXTG and caching

[Bertrand Delacretaz]

Le 1 juin 04, à 10:09, Sylvain Wallez a écrit :
...Well, it _could_ have a chance to work, but flowscript is 
definitely not the appropriate location to compute cache information 
for an element of the view pipeline
flowscript maybe not but how about backend java code?
Use-case: for a news site, you might want the cache validity to be 
dependent on the "urgency" of the news, for example cache older news 
for a longer time, assuming they won't change much anymore.

In this case the cache validity (or at least hints to the appropriate 
validity range) needs to come from the backend.

...So what about adding two optional attributes on the template's root 
element, defining the cache information?


   xmlns:jx="http://apache.org/cocoon/templates/jx/1.0";
   jx:cache-key='${cocoon.request.get("abc") + "!!spacer!!" + 
cocoon.request.get("bcd")'
   jx:cache-validity='${new DeltaTimeCacheValidity(60 * 60 * 24)}'>
   ... template 

I like the idea, and IIUC it would also allow the Flow to receive the 
DeltaTimeCacheValidity (for example) from your java code and pass it 
down to JXTG, right?

jx:cache-validity='${someObjectComingFromJavaCodeViaFlow}'>
Or, in other words, do you see this as having access to any additional 
variables passed in the cocoon.sendPage call?

-Bertrand

Re: SVN and Certificates

[Martin Holz]

Reinhard Poetz <[EMAIL PROTECTED]> writes:

> Pier Fumagalli wrote:
> >
> > Did you actually manage to get SubEclipse working :-P What
> > platform (keeps crashing my Eclipse M8 on MacOS/X)

AFAIK it won't work with Eclipse 3.0M8 for now. There where some
incompatible changes in the Eclipse Team API and the SubEclipse
waits until those changes are better documenented. 

> 
> I used Eclipse 2.1.2 under Win2k. IIRC this plugin only works for
> Win2k at the moment.

I got it compiled and running on Linux/Eclipse 2.1.3 using the command line
 interface. Don't remember the exact steps :-(. Seems a little bit slow
compared to the svn commmand line client.


Martin

Re: [heads up] PMC chair nominations

[Sylvain Wallez]

Stefano Mazzocchi wrote:
Stefano Mazzocchi wrote:
The ASF board decided not to accept Steven's resigns until the PMC 
itself came up with a new informed decision on who should follow him.

This means that Steven remains the chair until the board ratifies it.
Here I would like to start the nominations (in no particular order):
 - Vadim Gritsenko
 - Sylvain Wallez
 - Matthew Langham
 - Gianugo Rabellino
 [- Bertrand Delacretaz]
Bertrand already rejected the nomination but I still wanted to 
mention him as being part of my list.

Given my participation as a board director, and as coherence with my 
past public and private actions, I will not accept a nomination as 
the Cocoon PMC chair.

If you think somebody else should be in the ballot that is not listed 
above, please add him/her to the list.

If you are listed and you don't want to accept the nomination, please 
say so.

As for the duty of the PMC chair, I think that a great chair is 
somebody that doesn't do much at all and makes sure to collect the 
feedback and pass it along to the board, or make sure that board 
actions are passed down to the PMC.

The PMC chair should not be doing stuff for others, it should just be 
the social bridge between two different communities.

damn, this was supposed to go to [EMAIL PROTECTED]
Oh well. Sorry about that ;-)

I see no problem with the PMC election process occuring in public. 
There's nothing confidential in it.

Ah, and contrarily to last year, I do accept the nomination ;-)
Sylvain
--
Sylvain Wallez  Anyware Technologies
http://www.apache.org/~sylvain   http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }

Re: JXTG and caching

[Sylvain Wallez]

Leszek Gawron wrote:
While almost everybody buried XSP it has got one great feature that 
JXTG  lacks: it's cacheable. I know that there is no way to implement 
automatic JXTG caching but what if I know on what env does jx template 
operate. If I know that it is for example only request param "abc" and 
"bcd" and session attribute "xxx" then I know when I can use cached 
entry. The question is: how?

Should I extend JXTemplateGenerator so it is a cached component? I 
understand it gets the validity methods to implement then. So every 
time I call my extended component from flow I pass also the validity 
calculated in flow. Something like this:

function niceCachedResponse() {
  var cacheKey = cocoon.request.get( "abc" ) + "!!spacer!!"
+ cocoon.request.get( "bcd" ) + "!!spacer!!"
+ cocoon.session.getAttribute( "xxx" );
  var pageValidity = new DeltaTimeCacheValidity( 60 * 60 * 24 );
// one day
  cocoon.sendPage( "view/cached.jx", {
 JXTGExtCacheKey: cacheKey,
 JXTGExtpageValidity: pageValidity
 someOtherBizData: data } );
}
Does it have a chance to work ?

Well, it _could_ have a chance to work, but flowscript is definitely not 
the appropriate location to compute cache information for an element of 
the view pipeline.

The problem with JXG is that the template is the generate() method 
_only_ whereas an XSP is the full class, allowing to define getKey() and 
getValidity().

So what about adding two optional attributes on the template's root 
element, defining the cache information?


   xmlns:jx="http://apache.org/cocoon/templates/jx/1.0";
   jx:cache-key='${cocoon.request.get("abc") + "!!spacer!!" + 
cocoon.request.get("bcd")'
   jx:cache-validity='${new DeltaTimeCacheValidity(60 * 60 * 24)}'>
   ... template 


WDYT?
Sylvain
--
Sylvain Wallez  Anyware Technologies
http://www.apache.org/~sylvain   http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }