ClassCastException for Postgres datasource in Generator

[Harald Wehr]

I posted this to cocoon user list but did not get a helpful answer, so I 
try again here. Sorry for double posting:

In one of our Generators we want to use Postgres as Datasource. In
web.xml we added the postgres driver this way:
  
  load-class
  
org.postgresql.Driver
  
  
In cocoon.xconf we added the parameters for the connection:
 

  
  jdbc:postgresql://192.168.9.2/vrgis
  vrgis
  sigrv

  
In our Generator we implemented the Interface Composable with this method:

public void compose(ComponentManager manager) throws ComponentException {
ComponentSelector selector = (ComponentSelector)
manager.lookup(DataSourceComponent.ROLE+"Selector");
this.datasource = (DataSourceComponent) selector.select("vrgis");
}
Wenn we try to use the datasource in the generate-method we get a
ClassCastException.
--schnipp
Connection conn =  datasource.getConnection();
System.out.println(conn);
((Jdbc3Connection)conn).addDataType("geometry","org.postgis.PGgeometry");
((Jdbc3Connection)conn).addDataType("MultiLineString","org.postgis.MultiLineString");
--schnipp
The exception occurs when we try to cast the Connection. When we build
the connection ourself everything is working fine:
Class.forName("org.postgresql.Driver");
String url = "jdbc:postgresql://192.168.9.2/vrgis";
Connection conn = DriverManager.getConnection(url, dbuser, dbpass);
((Jdbc3Connection)conn).addDataType("geometry","org.postgis.PGgeometry");
((Jdbc3Connection)conn).addDataType("MultiLineString","org.postgis.MultiLineString");
System.out.println(conn);
In both ways the System.outs give:
org.postgresql.jdbc3.Jdbc3Connection
Do you have any hints, whats happening here? We are using Cocoon 2.1.3
on Suse Linux 8.1. We tested several postgres-driver version, but that
didn't help out here.
Harald

DO NOT REPLY [Bug 25433] - [PATCH] Sitemap Viewer

[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://nagoya.apache.org/bugzilla/show_bug.cgi?id=25433

[PATCH] Sitemap Viewer





--- Additional Comments From [EMAIL PROTECTED]  2003-12-15 01:12 ---
Jelle, would you please prepare the diff file again. It has a lot of junk in it,
and some patches are duplicated. Anyway, be sure that you have done a 'cvs
update' first, then make sure Cocoon builds and your sample works, then do the
'cvs diff -u > sitemap-viewer.diff'.

Also, can you provide some brief notes about any major changes and bugfixes. I
need to add a sensible cvs log message. Thanks.

DO NOT REPLY [Bug 25518] - [Patch] flow attribute and flow continuation input modules

[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://nagoya.apache.org/bugzilla/show_bug.cgi?id=25518

[Patch] flow attribute and flow continuation input modules





--- Additional Comments From [EMAIL PROTECTED]  2003-12-15 00:16 ---
Created an attachment (id=9573)
The patch

DO NOT REPLY [Bug 25518] New: - [Patch] flow attribute and flow continuation input modules

[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://nagoya.apache.org/bugzilla/show_bug.cgi?id=25518

[Patch] flow attribute and flow continuation input modules

   Summary: [Patch] flow attribute and flow continuation input
modules
   Product: Cocoon 2
   Version: Current CVS 2.1
  Platform: Other
OS/Version: Other
Status: NEW
  Severity: Enhancement
  Priority: Other
 Component: sitemap components
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


JXPath aware input modules that makes the flow attributes and the flow 
continuation object respectively available in the sitemap.

Examples:

  {flow-attribute:attr}

  {flow-attribute:attr}

  {flow-continuation:id}

Nearly no code, but usefull anyway ;)

DO NOT REPLY [Bug 25517] - [Patch] module source

[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://nagoya.apache.org/bugzilla/show_bug.cgi?id=25517

[Patch] module source





--- Additional Comments From [EMAIL PROTECTED]  2003-12-15 00:04 ---
Created an attachment (id=9572)
The patch

DO NOT REPLY [Bug 25517] New: - [Patch] module source

[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://nagoya.apache.org/bugzilla/show_bug.cgi?id=25517

[Patch] module source

   Summary: [Patch] module source
   Product: Cocoon 2
   Version: Current CVS 2.1
  Platform: Other
OS/Version: Other
Status: NEW
  Severity: Enhancement
  Priority: Other
 Component: sitemap components
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


Readable source that are accessed with URI:s like:

  module::[#xpath]

For reading the object that is found by applying the XPath (JXPath), on the 
attribute from the input-module. If the object is a String or an InputStream, 
it made available in form of an InputStream otherwise an exception is thrown.

The module source can be used for various things e.g. instead of the 
StreamGenerator:

  

For reading html from a input field in a form:

  

Instead of the PartSource for reading multi part mime data:

  module:raw-request-param:foo

It can also be used for more advanced things like reading Wiki content from a 
textarea

  
  
  
  

Re: StreamGenerator doesn't accept text/html

[Michael Wechner]

Joerg Heinicke wrote:

On 14.12.2003 18:12, Michael Wechner wrote:

Mmmh, but Epoz sends wellformed xhtml. The point is Epoz sends 
text/html
as content-type, which is not handled by StreamGenerator(, yet).
I don't want to tidy anything, at the mom.

My question is:

Why does the StreamGenerator not support text/html??


I guess this was the simplest way to enforce well-formedness. But 
the test on a specific content type is no that good IMO. Why not 
simply let the parser complain about well-formedness errors?




Good point. Look at the fact that it accepts text/plain :) so why not
text/html or what ever?


it seems to me that two fixes should be made: Epoz should send 
"text/xhtml"


Not text/xhtml, but similar: 
http://www.w3.org/TR/xhtml-media-types/#summary 


right

http://www.xml.com/pub/a/2003/03/19/dive-into-xml.html
http://www.web-graphics.com/mtarchive/000861.php
but still ... ;-)

Michi



and the generic StreamGenerator should be able to check 
well-formedness instead just checking the mime-type, maybe by 
default, but which could be configured to be turned off because of 
possible performance issues.


Simply trying parsing and rethrowing a parsing error ... what it has 
to do in any case. 



Joerg

DO NOT REPLY [Bug 25270] - cocoonCrawler broken with infinite depth=-1

[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://nagoya.apache.org/bugzilla/show_bug.cgi?id=25270

cocoonCrawler broken with infinite depth=-1

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED



--- Additional Comments From [EMAIL PROTECTED]  2003-12-14 21:06 ---
applied your proposed solution;
now crawling should work again,
can you recheck

DO NOT REPLY [Bug 25481] - Caching of aggregated content not working with cocoon:/ protocol

[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://nagoya.apache.org/bugzilla/show_bug.cgi?id=25481

Caching of aggregated content not working with cocoon:/ protocol

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |ASSIGNED



--- Additional Comments From [EMAIL PROTECTED]  2003-12-14 21:04 ---
Thanks for the help Vadim. At least least i can workaround the problem now
without having to change the source. 

Having had a look at the ContentAggregator class, i can see the problem is
really hairy. I can think of a patch that would suite my case: add all request
parameters to the key calculation. Do you think this could solve a few problems
with this without breaking anything else? I can supply this patch it really is
quite easy, just let me know.

Re: StreamGenerator doesn't accept text/html

[Joerg Heinicke]

On 14.12.2003 18:12, Michael Wechner wrote:

Mmmh, but Epoz sends wellformed xhtml. The point is Epoz sends 
text/html
as content-type, which is not handled by StreamGenerator(, yet).
I don't want to tidy anything, at the mom.

My question is:

Why does the StreamGenerator not support text/html??


I guess this was the simplest way to enforce well-formedness. But the 
test on a specific content type is no that good IMO. Why not simply 
let the parser complain about well-formedness errors?


Good point. Look at the fact that it accepts text/plain :) so why not
text/html or what ever?


it seems to me that two fixes should be made: Epoz should send 
"text/xhtml"
Not text/xhtml, but similar: http://www.w3.org/TR/xhtml-media-types/#summary

and the generic StreamGenerator should be able to check 
well-formedness instead just checking the mime-type, maybe by default, 
but which could be configured to be turned off because of possible 
performance issues.
Simply trying parsing and rethrowing a parsing error ... what it has to 
do in any case.

Joerg

Re: StreamGenerator doesn't accept text/html

[Michael Wechner]

Rolf Kulemann wrote:

On Sun, 2003-12-14 at 00:39, Joerg Heinicke wrote:

On 14.12.2003 00:12, Rolf Kulemann wrote:


Mmmh, but Epoz sends wellformed xhtml. The point is Epoz sends text/html
as content-type, which is not handled by StreamGenerator(, yet).
I don't want to tidy anything, at the mom.
My question is:

Why does the StreamGenerator not support text/html??
I guess this was the simplest way to enforce well-formedness. But the 
test on a specific content type is no that good IMO. Why not simply let 
the parser complain about well-formedness errors?


Good point. Look at the fact that it accepts text/plain :) so why not
text/html or what ever?
it seems to me that two fixes should be made: Epoz should send 
"text/xhtml" and the generic StreamGenerator should be able to check 
well-formedness instead just checking the mime-type, maybe by default, 
but which could be configured to be turned off because of possible 
performance issues.

Michi







--
Michael Wechner
Wyona Inc.  -   Open Source Content Management   -   Apache Lenya
http://www.wyona.com  http://cocoon.apache.org/lenya/
[EMAIL PROTECTED][EMAIL PROTECTED]

DO NOT REPLY [Bug 25481] - Caching of aggregated content not working with cocoon:/ protocol

[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://nagoya.apache.org/bugzilla/show_bug.cgi?id=25481

Caching of aggregated content not working with cocoon:/ protocol





--- Additional Comments From [EMAIL PROTECTED]  2003-12-14 16:56 ---
Jorg,

You may want also to check the bug #4641, it is somewhat related.
The problem is that key for aggregation is composed from the parts' URIs. Try
changing your pipeline to:


  ... add parameter matcher to get value for test parameter ...
  

... pass value ...

  
  


results will be different. For the pointer to the relevant code, see
o.a.c.sitemap.ContentAggregator, generateKey() method, line 182-194 in current
Cocoon 2.0 CVS.

PS Cocoon 2.1 implementation is *very* different. If you are in no position to
upgrade, you can provide a patch for 2.0.

Vadim

Re: Moved ParanoidCocoonServlet to its own block

[Upayavira]

Sylvain Wallez wrote:

Upayavira wrote:

Sylvain Wallez wrote:



Using "servlet-debug" allows to connect the Eclipse debugger to the 
running Jetty if needed. It also allows to do code hotswap on the 
running server (I had some problems hotswapping code produced by the 
JDK's javac).


How do you get the howswap to work? How does it show that code has 
been swapped? I've done everything you've suggested, and I can run 
Jetty and debug, but I have to restart Jetty whenever I recompile 
classes.


Hotswap is only possible when you modify the code while the program is 
stopped at a breakpoint. I don't know what's the magic behind it, but 
often the new modified code replaces the old one and the program 
continues with the new one. Eclipse shows a warning when hotswap isn't 
possible.
Ahh. Hotswap when at a breakpoint. I'll give it a go. Thanks.

This is not the same as servlet context reloading that may happen when 
the contents of WEB-INF/classes is modified. Tomcat does this, but I 
don't know about Jetty. It's implemented in the servlet engine by 
regularly scanning the contents of WEB-INF/classes and WEB-INF/lib 
(the "normal" servlet classpath), which means it won't detect changes 
in build/eclipse/classes.
Thanks for clarifying. Jetty doesn't do this kind of hotswapping AFAIK.

Upayavira

Re: [Woody] Row Submit Action

[Upayavira]

Sylvain Wallez wrote:

Upayavira wrote:

Bruno Dumon wrote:

On Fri, 2003-12-12 at 11:47, Upayavira wrote:
 

I need a row submit action, that allows a form to be submitted for 
a specific line in a repeater.

An example usecase would be on a selling site, you have a repeater 
showing purchasable items, each with a 'buy' button next to it.

Clicking on a row submit action will submit the form and allow the 
flowscript code that deals with the submitted form to gain access 
to either the repeater row object, or at least the row index that 
was clicked.

Is there anything like this already? Any of you interested in 
adding it ;-)
  


Use a wd:submit widget (or wd:action) as child of the repeater. In 
its event handler you can get the repeater row by getting the parent 
of the submitted widget:

event.getSourceWidget().getParent()

using getId() on it will return the row number (as a string). You 
can access other widgets on the repeater row by using the 
getWidget(id) method on it.

Bruno,

Thanks for this. What I've done is extend the RowAction to give it a 
'submit-row' action-command. I've added a property to the repeater 
for it to store and access the 'submittedRow'. When the submit-row 
RowAction is clicked, it sets the submitted row on the repeater. Then 
from flow, the submitted row can be found from flow using 
form.getWidget("repeatername").getSubmittedRow().

I would rather not do it in an event handler, as I'd have to store 
the row somewhere for future use outside of the forms flow.

Is this reasonable? Is it a reasonable patch?


IMO, it's better to go through the widget that triggered the submit 
than asking to the repeater (furthermore, what happens in the case of 
nested repeaters?).

I you want this to be handled by the flow, The Form object provides a 
getSubmitWidget() that gives the submitting widget. From there, you 
can use the same getParent() as outlined by Bruno to access the row, 
and then the row id, child widgets, etc.
Splendid. That's what I wanted to be able to do, and without any 
modifications to Cocoon - even better!

Thanks for this.

Upayavira

Bug report for Cocoon 2 [2003/12/14]

[bugzilla]

+---+
| Bugzilla Bug ID   |
| +-+
| | Status: UNC=Unconfirmed NEW=New ASS=Assigned|
| | OPN=ReopenedVER=Verified(Skipped Closed/Resolved)   |
| |   +-+
| |   | Severity: BLK=Blocker CRI=CriticalMAJ=Major |
| |   |   MIN=Minor   NOR=Normal  ENH=Enhancement   |
| |   |   +-+
| |   |   | Date Posted |
| |   |   |  +--+
| |   |   |  | Description  |
| |   |   |  |  |
| 5978|Ass|Nor|2002-01-23|Java SecurityManager java.lang.RuntimePermission c|
| 6200|New|Maj|2002-02-03|Parser failure with validate=true when processing |
| 9916|New|Enh|2002-06-17|javax.xml.transform.Transformer accepts object par|
|10203|Opn|Enh|2002-06-25|Docs referenced by XSLT's document() are not inclu|
|10827|New|Nor|2002-07-15|ESQL  doesn't support namespaces|
|11716|New|Nor|2002-08-15| is formatting sensitive   |
|13479|New|Maj|2002-10-10|Cocoon fails to compile sitemap and XSP in JBoss 3|
|14074|New|Nor|2002-10-29|Previously reported tar bug - isn't (well, it is b|
|14327|New|Nor|2002-11-07|[PATCH] JSPReader: make the output encoding config|
|15302|Ass|Nor|2002-12-12|XSPUtil.relativeFilename() returns differents resu|
|15316|Opn|Nor|2002-12-12|FOP does not resolve relative paths   |
|15614|Opn|Min|2002-12-22|Some documentation is inaccurate by version   |
|15841|New|Nor|2003-01-07|xsp:attribute handled incorrectly |
|16537|New|Nor|2003-01-29|[PATCH] fixed redirect under JRun 3.1 |
|16545|New|Min|2003-01-29|Logicsheet embedded in used-defined logicsheet doe|
|16710|New|Maj|2003-02-03|SQLTransformer.Query.serializeRow forces lower cas|
|17594|New|Nor|2003-03-03|WebSphere redirect bug|
|17771|New|Nor|2003-03-07|[PATCH] new logging category never set when using |
|17924|New|Nor|2003-03-12|Cached resources don't have Expires-Header|
|17984|New|Enh|2003-03-14|SQLTransformer only handles nested or sequential q|
|18116|New|Min|2003-03-18|VelocityGenerator  child elements don't |
|19138|New|Enh|2003-04-18|[PATCH] Made SQLTransformer paginatable   |
|19641|New|Nor|2003-05-05|[PATCH] HSSFSerializer Support for FreezePane |
|20190|New|Maj|2003-05-23|JSPs in external subsite fail |
|20508|New|Nor|2003-06-05|[PATCH] Namespace cleanup in HTMLSerializer   |
|20631|New|Nor|2003-06-10|[PATCH] Support for transactions in SQLTransformer|
|20640|New|Maj|2003-06-10|Pages keep reloading with Cocoon 2.04 |
|20736|New|Maj|2003-06-13|JXForms validator rejects null value for numeric f|
|21107|New|Maj|2003-06-26|possible sitemap reload locking issue |
|21177|New|Nor|2003-06-30|a crash in the name() function of the xslt, when u|
|21301|New|Maj|2003-07-03|esql:get-xml error: Could not find Component (role|
|21536|Opn|Enh|2003-07-12|[PATCH] 2 new generators: MultiPartPosted XML and |
|22132|New|Nor|2003-08-05|Cannot use redirect-to after submit jxform|
|22400|New|Enh|2003-08-13|SQLTransformer to optionally preserve case of colu|
|22842|New|Nor|2003-08-30|flow: importPackage/importClass problems creating |
|23002|New|Nor|2003-09-08|HSSF Serializer does not process  are sometim|
|23901|New|Nor|2003-10-17|[PATCH] [woody], adding  and moving l|
|23921|New|Enh|2003-10-19|[PATCH] New ReadDOMTransformer/WriteDOMTransformer|
|23939|New|Nor|2003-10-20|document('relative-URI') seems to resolve wrongly |
|24135|Ass|Min|2003-10-26|carselector sample: reloading page puts old values|
|24180|New|Enh|2003-10-28|[WOODY] Test the presence of all required fields i|
|24289|New|Nor|2003-10-31|MultipartParser cannot handle multibyte character |
|24319|New|Nor|2003-11-01|[PATCH] Template-based web site   |
|24389|New|Enh|2003-11-04|[PATCH] New ResourceLoadAction|
|24390|New|Enh|2003-11-04|[PATCH] New StaticStringModule|
|24391|New|Nor|2003-11-04|[PATCH] wsinclude and htmlinclude transformers|
|24402|New|Enh|2003-11-04|[PATCH] XML posting from SourceWritingTransformer |
|24433|New|Nor|2003-11-05|JXTemplate generator does not handle format-number|
|24457|New|Nor|2003-11-06|Xalan/XSLT using UTF-8: Incorrect SAXException: At|
|24498|New|Nor|2003-11-07|Need to be able to use "cinclude" or "xinclude" to|
|24529|New|Enh|2003-11-08|[PATCH] file upload component for usage with flows|
|24647|New|Nor|2003-11-12|content-length in ResourceReader  

Re: Status of 2.2 - Continuing?

[Giacomo Pati]

Unico Hommes wrote:
 

Carsten Ziegeler wrote:

Hi,

whats the current status regarding the tree processor in 2.2?

As the tree processor is the central component that is 
required to run cocoon and as we currently just can't start 
2.2 to test/implement anything else, I think we should see 
that we get a runnable 2.2 asap.

What do you think about just installing the tree processor from 2.1?
This version should work in 2.2 and while someone is 
concentrating on the treeprocessor for 2.2, all others can 
start with whatever they want (e.g. blocks).



I was planning on working on the tree processor for 2.2 next week and
during the holidays. I've been extremely busy at work for the past few
weeks (am in the office right now) but this will be over after
tomorrow's deadline.
I don't know how long it's going to take me to get the tree processor
into a workable state. The changes that need to be made are extensive so
there will be a test period after things start to work as well. I'd say,
I'll probably be able to put in enough time to get it working over Xmas.
I'm +1 on your proposal of installing the tree processor from 2.1 if you
think this will get you started on blocks sooner than that. Else I'd
advise to wait a little bit more. If we do revert to 2.1 tree processor
we will need to move the work I have been doing componentized tree
processor over to a different package.
Thoughts?
Sounds like a good plan, so +1 to give time until next year (sound like 
a looong period :-) If we can't manage to amke it run until than we 
could move it to another package and reinstantiate the 2.1 treeprocessor 
instead.

--
Otego AG  Tel:   +41 (0)1  240 00 55
Giacomo Pati, CTO Mobile:+41 (0)79 262 21 04
Apache Software Foundation Member Mailto:[EMAIL PROTECTED]
Hohlstrasse 216   Mailto:[EMAIL PROTECTED]
CH-8004 ZürichWeb:   http://www.otego.com

RE: Status of 2.2 - Continuing?

[Unico Hommes]

 

Joerg Heinicke wrote:
> 
> On 14.12.2003 14:38, Reinhard Poetz wrote:
> 
> >>>Hi,
> >>>
> >>>whats the current status regarding the tree processor in 2.2?
> >>>
> >>>As the tree processor is the central component that is required to 
> >>>run cocoon and as we currently just can't start
> >>>2.2 to test/implement anything else, I think we should see that we 
> >>>get a runnable 2.2 asap.
> >>>
> >>>What do you think about just installing the tree processor
> >>
> >>from 2.1? 
> >>
> >>I was planning on working on the tree processor for 2.2 
> next week and 
> >>during the holidays. I've been extremely busy at work for 
> the past few 
> >>weeks (am in the office right now) but this will be over after 
> >>tomorrow's deadline.
> >>
> >>I don't know how long it's going to take me to get the tree 
> processor 
> >>into a workable state. The changes that need to be made are 
> extensive 
> >>so there will be a test period after things start to work 
> as well. I'd 
> >>say, I'll probably be able to put in enough time to get it working 
> >>over Xmas.
> > 
> > I'm +1 to give you the requested time frame. Have a deeper 
> look into 
> > the code and give us feedback after Xmas how long it will 
> take you. If 
> > you say it's too much time we can jump back then. I don't think we 
> > should do it now and if you say that it's too much work we 
> can install 
> > the 2.1 version then. But I don't think it is a good idea 
> to jump back 
> > right now.
> 
> Same opinion here: give Unico the time and switch back in the 
> new year if necessary (though it would not be a good start into it).
> 

It's probably only a question of how long it will take to make the tree
processor run with fortress. If someone is able to do that within a
short time frame and thinks it's worth the effort then I think they
should. 

Unico

RE: Status of 2.2 - Continuing?

[Unico Hommes]

 

Sylvain Wallez wrote:
> 
> Carsten Ziegeler wrote:
> 
> >Hi,
> >
> >whats the current status regarding the tree processor in 2.2?
> >  
> >
> 
> Stalled... I don't have much time for it now...
> 
> >As the tree processor is the central component that is 
> required to run cocoon and as we currently just can't start 
> 2.2 to test/implement anything else, I think we should see 
> that we get a runnable 2.2 asap.
> >
> >What do you think about just installing the tree processor 
> from 2.1? This version should work in 2.2 and while someone 
> is concentrating on the treeprocessor for 2.2, all others can 
> start with whatever they want (e.g. blocks).
> >  
> >
> 
> +1.
> 
> We should move the current state of the 2.2 treeprocessor to 
> another package and reinstall the 2.1 one so they can live 
> their lives in parallel. This will also allow us to switch 
> between one and the other until the new one is considered stable.
> 

Agreed.

> AFAIR, the main obstacle with the current treeprocessor 
> regarding Fortress was the use of Recomposable. Removing this 
> dependency isn't a hard work and I can do it rather quickly.
> 
> For the new processor name, I was thinking about 
> "componentized processor" (because all statements are 
> component declarations) or "flat tree processor" (because the 
> tree is flattened). What do you think?
> 

I find componentizedprocessor too long for a package name what about
just 'processor' for a package name?

Unico

Re: Status of 2.2 - Continuing?

[Joerg Heinicke]

On 14.12.2003 14:38, Reinhard Poetz wrote:

Hi,

whats the current status regarding the tree processor in 2.2?

As the tree processor is the central component that is
required to run cocoon and as we currently just can't start 
2.2 to test/implement anything else, I think we should see 
that we get a runnable 2.2 asap.

What do you think about just installing the tree processor 
from 2.1? 

I was planning on working on the tree processor for 2.2 next 
week and during the holidays. I've been extremely busy at 
work for the past few weeks (am in the office right now) but 
this will be over after tomorrow's deadline.

I don't know how long it's going to take me to get the tree 
processor into a workable state. The changes that need to be 
made are extensive so there will be a test period after 
things start to work as well. I'd say, I'll probably be able 
to put in enough time to get it working over Xmas.
I'm +1 to give you the requested time frame. Have a deeper look into the
code and give us feedback after Xmas how long it will take you. If you
say it's too much time we can jump back then. I don't think we should do
it now and if you say that it's too much work we can install the 2.1
version then. But I don't think it is a good idea to jump back right
now.
Same opinion here: give Unico the time and switch back in the new year 
if necessary (though it would not be a good start into it).

Joerg

RE: Status of 2.2 - Continuing?

[Reinhard Poetz]

From: Unico Hommes

> Carsten Ziegeler wrote:
> > 
> > Hi,
> > 
> > whats the current status regarding the tree processor in 2.2?
> > 
> > As the tree processor is the central component that is
> > required to run cocoon and as we currently just can't start 
> > 2.2 to test/implement anything else, I think we should see 
> > that we get a runnable 2.2 asap.
> > 
> > What do you think about just installing the tree processor 
> from 2.1? 
> > This version should work in 2.2 and while someone is 
> concentrating on 
> > the treeprocessor for 2.2, all others can start with whatever they 
> > want (e.g. blocks).
> > 
> 
> I was planning on working on the tree processor for 2.2 next 
> week and during the holidays. I've been extremely busy at 
> work for the past few weeks (am in the office right now) but 
> this will be over after tomorrow's deadline.
> 
> I don't know how long it's going to take me to get the tree 
> processor into a workable state. The changes that need to be 
> made are extensive so there will be a test period after 
> things start to work as well. I'd say, I'll probably be able 
> to put in enough time to get it working over Xmas.
> 
> I'm +1 on your proposal of installing the tree processor from 
> 2.1 if you think this will get you started on blocks sooner 
> than that. Else I'd advise to wait a little bit more. If we 
> do revert to 2.1 tree processor we will need to move the work 
> I have been doing componentized tree processor over to a 
> different package.
> 
> Thoughts?

I'm +1 to give you the requested time frame. Have a deeper look into the
code and give us feedback after Xmas how long it will take you. If you
say it's too much time we can jump back then. I don't think we should do
it now and if you say that it's too much work we can install the 2.1
version then. But I don't think it is a good idea to jump back right
now.

For all of you who want to start next week or over Xmas with blocks
which are the main reason for our 2.2 repository: IIUC some parts of
blocks can be implemented *without* a working core Cocoon. Don't forget
to add an issue to Bugzilla to avoid duplicate implementation.

--
Reinhard

DO NOT REPLY [Bug 14327] - [PATCH] JSPReader: make the output encoding configurable.

[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://nagoya.apache.org/bugzilla/show_bug.cgi?id=14327

[PATCH] JSPReader: make the output encoding configurable.

[EMAIL PROTECTED] changed:

   What|Removed |Added

Summary|JSPReader: make the output  |[PATCH] JSPReader: make the
   |encoding configurable.  |output encoding
   ||configurable.

DO NOT REPLY [Bug 14327] - JSPReader: make the output encoding configurable.

[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://nagoya.apache.org/bugzilla/show_bug.cgi?id=14327

JSPReader: make the output encoding configurable.





--- Additional Comments From [EMAIL PROTECTED]  2003-12-14 13:15 ---
see patch attached to bug 23269, it implements configurable buffer size and
output encoding.

Re: Status of 2.2 - Continuing?

[Sylvain Wallez]

Carsten Ziegeler wrote:

Hi,

whats the current status regarding the tree processor in 2.2?
 

Stalled... I don't have much time for it now...

As the tree processor is the central component that is required to run cocoon and as we currently just can't start 2.2 to test/implement anything else, I think we should see that we get a runnable 2.2 asap.

What do you think about just installing the tree processor from 2.1? This version should work in 2.2 and while someone is concentrating on the treeprocessor for 2.2, all others can start with whatever they want (e.g. blocks).
 

+1.

We should move the current state of the 2.2 treeprocessor to another 
package and reinstall the 2.1 one so they can live their lives in 
parallel. This will also allow us to switch between one and the other 
until the new one is considered stable.

AFAIR, the main obstacle with the current treeprocessor regarding 
Fortress was the use of Recomposable. Removing this dependency isn't a 
hard work and I can do it rather quickly.

For the new processor name, I was thinking about "componentized 
processor" (because all statements are component declarations) or "flat 
tree processor" (because the tree is flattened). What do you think?

Sylvain

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

RE: Status of 2.2 - Continuing?

[Unico Hommes]

 

Carsten Ziegeler wrote:
> 
> Hi,
> 
> whats the current status regarding the tree processor in 2.2?
> 
> As the tree processor is the central component that is 
> required to run cocoon and as we currently just can't start 
> 2.2 to test/implement anything else, I think we should see 
> that we get a runnable 2.2 asap.
> 
> What do you think about just installing the tree processor from 2.1?
> This version should work in 2.2 and while someone is 
> concentrating on the treeprocessor for 2.2, all others can 
> start with whatever they want (e.g. blocks).
> 

I was planning on working on the tree processor for 2.2 next week and
during the holidays. I've been extremely busy at work for the past few
weeks (am in the office right now) but this will be over after
tomorrow's deadline.

I don't know how long it's going to take me to get the tree processor
into a workable state. The changes that need to be made are extensive so
there will be a test period after things start to work as well. I'd say,
I'll probably be able to put in enough time to get it working over Xmas.

I'm +1 on your proposal of installing the tree processor from 2.1 if you
think this will get you started on blocks sooner than that. Else I'd
advise to wait a little bit more. If we do revert to 2.1 tree processor
we will need to move the work I have been doing componentized tree
processor over to a different package.

Thoughts?

Unico

Re: [Woody] Row Submit Action

[Sylvain Wallez]

Upayavira wrote:

Bruno Dumon wrote:

On Fri, 2003-12-12 at 11:47, Upayavira wrote:
 

I need a row submit action, that allows a form to be submitted for a 
specific line in a repeater.

An example usecase would be on a selling site, you have a repeater 
showing purchasable items, each with a 'buy' button next to it.

Clicking on a row submit action will submit the form and allow the 
flowscript code that deals with the submitted form to gain access to 
either the repeater row object, or at least the row index that was 
clicked.

Is there anything like this already? Any of you interested in adding 
it ;-)
  


Use a wd:submit widget (or wd:action) as child of the repeater. In 
its event handler you can get the repeater row by getting the parent 
of the submitted widget:

event.getSourceWidget().getParent()

using getId() on it will return the row number (as a string). You can 
access other widgets on the repeater row by using the getWidget(id) 
method on it.

Bruno,

Thanks for this. What I've done is extend the RowAction to give it a 
'submit-row' action-command. I've added a property to the repeater for 
it to store and access the 'submittedRow'. When the submit-row 
RowAction is clicked, it sets the submitted row on the repeater. Then 
from flow, the submitted row can be found from flow using 
form.getWidget("repeatername").getSubmittedRow().

I would rather not do it in an event handler, as I'd have to store the 
row somewhere for future use outside of the forms flow.

Is this reasonable? Is it a reasonable patch?


IMO, it's better to go through the widget that triggered the submit than 
asking to the repeater (furthermore, what happens in the case of nested 
repeaters?).

I you want this to be handled by the flow, The Form object provides a 
getSubmitWidget() that gives the submitting widget. From there, you can 
use the same getParent() as outlined by Bruno to access the row, and 
then the row id, child widgets, etc.

Sylvain

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

Re: Moved ParanoidCocoonServlet to its own block

[Sylvain Wallez]

Upayavira wrote:

Sylvain Wallez wrote:



Using "servlet-debug" allows to connect the Eclipse debugger to the 
running Jetty if needed. It also allows to do code hotswap on the 
running server (I had some problems hotswapping code produced by the 
JDK's javac).


How do you get the howswap to work? How does it show that code has 
been swapped? I've done everything you've suggested, and I can run 
Jetty and debug, but I have to restart Jetty whenever I recompile 
classes.


Hotswap is only possible when you modify the code while the program is 
stopped at a breakpoint. I don't know what's the magic behind it, but 
often the new modified code replaces the old one and the program 
continues with the new one. Eclipse shows a warning when hotswap isn't 
possible.

This is not the same as servlet context reloading that may happen when 
the contents of WEB-INF/classes is modified. Tomcat does this, but I 
don't know about Jetty. It's implemented in the servlet engine by 
regularly scanning the contents of WEB-INF/classes and WEB-INF/lib (the 
"normal" servlet classpath), which means it won't detect changes in 
build/eclipse/classes.

Hope this helps,
Sylvain
--
Sylvain Wallez  Anyware Technologies
http://www.apache.org/~sylvain   http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance  -  http://www.orixo.com

Status of 2.2 - Continuing?

[Carsten Ziegeler]

Hi,

whats the current status regarding the tree processor in 2.2?

As the tree processor is the central component that is required
to run cocoon and as we currently just can't start 2.2 
to test/implement anything else, I think we should see that
we get a runnable 2.2 asap.

What do you think about just installing the tree processor from 2.1?
This version should work in 2.2 and while someone is concentrating
on the treeprocessor for 2.2, all others can start with whatever
they want (e.g. blocks).


Carsten 

DO NOT REPLY [Bug 25481] - Caching of aggregated content not working with cocoon:/ protocol

[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://nagoya.apache.org/bugzilla/show_bug.cgi?id=25481

Caching of aggregated content not working with cocoon:/ protocol





--- Additional Comments From [EMAIL PROTECTED]  2003-12-14 11:17 ---
This bug only affects 2.0.4 it seems, i tested on 2.1.3 without probs. 

Is anyone interested in helping me out here? eg tell me in which class the
timestampcachevalidity for an executed pipeline is set so i can dig from there.

RE: CVS broken (was: Re: Moved ParanoidCocoonServlet to its own block)

[Carsten Ziegeler]

Geoff Howard  wrote:
> > Don't know :) I guess it's because we don't check if the "conf" 
> directory
> > exists before we apply the xconfpatch tool.
> 
> Is that where the error occurred in building?  If so, it's easy to fix.
> 
Yes, I think this was the place (but I'm not quiet sure anymore ). Simply
removing the conf directory will display the error again.

Carsten

Re: [CocoonBean] recycle?

[Simon Mieth]

On Sun, 14 Dec 2003 08:05:52 +
Upayavira <[EMAIL PROTECTED]> wrote:


> Thinking about this, it occurs to me that what your
> 'recycle' method does is to remove all targets, rather
> than recycle the component.
> 
> Therefore, I'd suggest we have a method called something
> like removeTargets() that does crawler = new Crawler();
> 
> Regards, Upayavira
> 

Hi Upayavira,

sounds clearer now. I looked  in CocoonBean-source the last
days and it looks like there are only the
exclude-/includePattern not available for remove/change. All
other things can be setXXX().

I don't use the include/excludePattern, but a
removeXXcludePattern may be usefull in some cases too.

Best regards,

Simon

Re: [Woody] Row Submit Action

[Upayavira]

Bruno Dumon wrote:

On Fri, 2003-12-12 at 11:47, Upayavira wrote:
 

I need a row submit action, that allows a form to be submitted for a 
specific line in a repeater.

An example usecase would be on a selling site, you have a repeater 
showing purchasable items, each with a 'buy' button next to it.

Clicking on a row submit action will submit the form and allow the 
flowscript code that deals with the submitted form to gain access to 
either the repeater row object, or at least the row index that was clicked.

Is there anything like this already? Any of you interested in adding it ;-)
   

Use a wd:submit widget (or wd:action) as child of the repeater. In its
event handler you can get the repeater row by getting the parent of the
submitted widget:
event.getSourceWidget().getParent()

using getId() on it will return the row number (as a string). You can
access other widgets on the repeater row by using the getWidget(id)
method on it.
 

Bruno,

Thanks for this. What I've done is extend the RowAction to give it a 
'submit-row' action-command. I've added a property to the repeater for 
it to store and access the 'submittedRow'. When the submit-row RowAction 
is clicked, it sets the submitted row on the repeater. Then from flow, 
the submitted row can be found from flow using 
form.getWidget("repeatername").getSubmittedRow().

I would rather not do it in an event handler, as I'd have to store the 
row somewhere for future use outside of the forms flow.

Is this reasonable? Is it a reasonable patch?

Regards, Upayavira

Re: Moved ParanoidCocoonServlet to its own block

[Upayavira]

Sylvain Wallez wrote:

Stefano Mazzocchi wrote:

On 11 Dec 2003, at 13:53, Sylvain Wallez wrote:

Last one for today ;-)

I moved the ParanoidCocoonServlet and associated classes to a new 
"paranoid" block?

Why this? Because ParanoidCocoonServlet is actually a generic 
servlet wrapper that can shield _any_ servlet in a 
ParanoidClassLoader. Moving it to its own block leads to having a 
"cocoon-paranoid-block.jar" that can be deployed separately from 
"cocoon.jar".

This allows several things:
- use the ParanoidCocoonServlet with another servlet. Yes, remember 
Cocoon isn't the only servlet ;-)
- leave only paranoid.jar in WEB-INF/lib and have all other libs 
located somewhere else by using the "paranoid-classpath" init 
parameter.

I use this second feature to load "build/eclipse/classes" in Jetty. 
This allows faster roundtrips since it removes the need to "build 
webapp" at each code change.


Uh, can you elaborate more on this? I'm very interested in knowing 
how you develop on eclipse.


Run "build webapp".

In web.xml, use ParanoidCocoonServlet and add the following parameter:
   
 paranoid-classpath
 dev-classpath.txt
   
The "dev-classpath.txt" file is looked up relative to the working 
directory, which is the main cocoon directory when using 
cocoon.[bat|sh]. It contains:
   class-dir: build/eclipse/classes
   lib-dir: build/webapp/WEB-INF/lib

Run "build eclipse-project", and open and build the project with Eclipse.

Next you have to delete the cocoon.roles that's in 
build/eclipse/classes as it doesn't contain all the roles defined by 
blocks. Doing this ensures the full cocoon.roles located in 
WEB-INF/lib/cocoon.jar will be used.

Launch "cocoon servlet-debug", and voilà, you're using the latest 
modifications done in Eclipse.

Using "servlet-debug" allows to connect the Eclipse debugger to the 
running Jetty if needed. It also allows to do code hotswap on the 
running server (I had some problems hotswapping code produced by the 
JDK's javac).
How do you get the howswap to work? How does it show that code has been 
swapped? I've done everything you've suggested, and I can run Jetty and 
debug, but I have to restart Jetty whenever I recompile classes.

Regards, Upayavira

Re: [CocoonBean] recycle?

[Upayavira]

Simon Mieth wrote:

Hi again,

i forgot, the CocoonBean setup like ContextDir is the same
and a changes are ignored, this needs a new cocoon-instance.
So the "recycle" only works with the initialized Context.

Maybe there is a better name as "recycle" to protect
confusion about the interface from Avalon.
Best Regards,

Simon

 

Thinking about this, it occurs to me that what your 'recycle' method 
does is to remove all targets, rather than recycle the component.

Therefore, I'd suggest we have a method called something like 
removeTargets() that does crawler = new Crawler();

Regards, Upayavira