date:20030909

BarZ,

Feel free to submit patches to JXForms, for example for "selectBoolean". 
Nobody is "responsible" for JXForms or other Cocoon development per se. 
It's voluntary.

Regards,

Chris

Barzilai Spinak wrote:

Hello Christopher.
A couple of days ago I posted a question related to JXForms and nobody 
answered.
By looking into the CVS submissions, I think you may be one of the 
programmers related to  that block.
Am I right?   Can you help me with my question?
Another programmer seems to be  cziegeler but I think he's on vacation 
or something.
Who would be the right person to ask?

Here's a reference to it.

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

Thanks for your help

BarZ

ADSL para estar en internet las 24 horas a máxima velocidad 
  y sin ocupar el teléfono.
---
http://www.internet.com.uy   Tel. 707.42.52

JXForms and selectBoolean

2003-09-09 Thread Barzilai Spinak

Hello Christopher.
A couple of days ago I posted a question related to JXForms and nobody 
answered.
By looking into the CVS submissions, I think you may be one of the 
programmers related to  that block.
Am I right?   Can you help me with my question?
Another programmer seems to be  cziegeler but I think he's on vacation 
or something.
Who would be the right person to ask?

Here's a reference to it.

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

Thanks for your help

BarZ

ADSL para estar en internet las 24 horas a máxima velocidad 
	  y sin ocupar el teléfono.
---
http://www.internet.com.uy   Tel. 707.42.52

[Woody multi page forms] was Re: cvs commit:cocoon-2.1/src/blocks/woody/java/org/apache/cocoon/woody/flow/javascriptwoody.js

BTW that flowscript code was written with the intention of supporting 
multi-page Woody forms with automated back/forward navigation as in 
JXForms. However, when I looked into implementing this I discovered that 
Woody forms cannot be presented in multiple pages because apparently the 
entire form is "submitted" with each request. As a result the fields 
that are not presented in the first page fail validation because they 
have no values. Or am I missing something?

In addition, the "validator" function in show() was not intended to 
return a value. I did that originally simply because it wasn't possible 
to programatically add validation errors to the form widgets themselves 
at the time it was written (not sure if that's still the case).

Chris

Sylvain Wallez wrote:

Christopher Oliver wrote:

The code you copied was an incorrect workaround for an old bug. Just 
remove it.

Ok, thanks.

Sylvain

Re: Announcing 2.1.1

Unfortunately I think 2.1.1 contains a Rhino regression I temporarily 
introduced while trying to fix bug 22513 which will cause any scripts 
with nested functions to fail. This includes some of the flow samples 
like PetStore and JXForms.

IMO we are in serious need of regression tests for flowscript. In the 
meantime any help others can provide with respect to testing the flow 
implementation is appreciated.

Regards,

Chris

Steven Noels wrote:

Joerg Heinicke wrote:

We are helpless without Carsten :-)

Joerg

Sylvain Wallez wrote:

Hi team,

The 2.1.1 should now have reached the mirrors. Does someone know how 
to update the web site and send the announcements ?

I'll update the main website tomorrow (just the news page on the 
cocoon.apache.org). I wouldn't update the complete 
cocoon.apache.org/2.1/ right now, since the current content is still 
valid, and the reshuffling that Carsten started seems more aimed at an 
upcoming 2.2 release, and might need some more work. That leaves us 
with the security warning missing from the 2.1 site... maybe a partial 
update of the main page is enough.

I'll send out an announcement after that.

Re: New protocol for in-memory resources

2003-09-09 Thread Vadim Gritsenko

Sylvain Wallez wrote:

Tuomo L wrote:

It would be convinient,
if one could use a protocolthat defines a source (FilePart) located 
in memory.
This could be for example: "multipart://foo.zip" . Then it would
be possible to extract that in-memory zip-file to the target-dir.

Is this possible already, or am I going to wrong direction here?

You know that you can access files inside zip using jar: protocol, right?


This is not possible today, but really is the right direction, and 
would be a valuable addition.


Wouldn't it be too much strain on system's resources (read: memory) in 
production environment (with the exception of light uses like 
departamental server) to render this feature useless? I agree though 
that it might be actually convinient.

Just wondering, ;-)

PS Do we have TraversableInspectableRestrictableZipSource?

Vadim

Re: EJB + Cocoon, "Best Practices" / Betwixt

2003-09-09 Thread Christoph Gaffga

> that invokes the EJB and returns the DTO. It then passes the DTO to
Betwixt
> which converts it to SAX events.  I posted the BeanGenerator on the list a

Perheaps you are also interested in a BetwixtTransformer, analoge to
CastorTransformer?
I post it here, perheaps anyone can put it in the scratchpad?

regards
Christoph


org.apache.cocoon.tranformation.BetwixtTransformer:
---

/*


   The Apache Software License, Version 1.1


 Copyright (C) 1999-2003 The Apache Software Foundation. All rights
reserved.
 Redistribution and use in source and binary forms, with or without
modifica-
 tion, are permitted provided that the following conditions are met:
 1. Redistributions of  source code must  retain the above copyright
notice,
this list of conditions and the following disclaimer.
 2. Redistributions in binary form must reproduce the above copyright
notice,
this list of conditions and the following disclaimer in the
documentation
and/or other materials provided with the distribution.
 3. The end-user documentation included with the redistribution, if any,
must
include  the following  acknowledgment:  "This product includes
software
developed  by the  Apache Software Foundation
(http://www.apache.org/)."
Alternately, this  acknowledgment may  appear in the software itself,
if
and wherever such third-party acknowledgments normally appear.
 4. The names "Apache Cocoon" and  "Apache Software Foundation" must  not
be
used to  endorse or promote  products derived from  this software
without
prior written permission. For written permission, please contact
[EMAIL PROTECTED]
 5. Products  derived from this software may not  be called "Apache", nor
may
"Apache" appear  in their name,  without prior written permission  of
the
Apache Software Foundation.
 THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED
WARRANTIES,
 INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY
AND
 FITNESS  FOR A PARTICULAR  PURPOSE ARE  DISCLAIMED.  IN NO  EVENT SHALL
THE
 APACHE SOFTWARE  FOUNDATION  OR ITS CONTRIBUTORS  BE LIABLE FOR  ANY
DIRECT,
 INDIRECT, INCIDENTAL, SPECIAL,  EXEMPLARY, OR CONSEQUENTIAL  DAMAGES
(INCLU-
 DING, BUT NOT LIMITED TO, PROCUREMENT  OF SUBSTITUTE GOODS OR SERVICES;
LOSS
 OF USE, DATA, OR  PROFITS; OR BUSINESS  INTERRUPTION)  HOWEVER CAUSED AND
ON
 ANY  THEORY OF LIABILITY,  WHETHER  IN CONTRACT,  STRICT LIABILITY,  OR
TORT
 (INCLUDING  NEGLIGENCE OR  OTHERWISE) ARISING IN  ANY WAY OUT OF THE  USE
OF
 THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
 This software  consists of voluntary contributions made  by many
individuals
 on  behalf of the Apache Software  Foundation and was  originally created
by
 Stefano Mazzocchi  <[EMAIL PROTECTED]>. For more  information on the
Apache
 Software Foundation, please see .
 */

package org.apache.cocoon.transformation;

import java.lang.reflect.Proxy;
import java.util.Collection;
import java.util.Iterator;
import java.util.Map;

import org.apache.avalon.framework.configuration.Configurable;
import org.apache.avalon.framework.configuration.Configuration;
import org.apache.avalon.framework.configuration.ConfigurationException;
import org.apache.avalon.framework.parameters.Parameters;
import org.apache.cocoon.environment.Context;
import org.apache.cocoon.environment.ObjectModelHelper;
import org.apache.cocoon.environment.Request;
import org.apache.cocoon.environment.Session;
import org.apache.cocoon.environment.SourceResolver;
import org.apache.commons.betwixt.XMLIntrospector;
import org.apache.commons.betwixt.io.SAXBeanWriter;
import org.apache.commons.betwixt.strategy.ClassNormalizer;
import org.apache.commons.logging.impl.LogKitLogger;
import org.xml.sax.Attributes;
import org.xml.sax.SAXException;

/**
 * Betwixt transformer marshals a object from the Sitemap, Session, Request
or
 * the Conext into a series of SAX events.
 *
 * Configuation: The betwixt transformer can be configured to not output
element
 * reference ids. The default setting is to output reference IDs.
 * 
 *   true
 *   
 * 
 *
 * A sample for the use:
 * 
 *   ;
 *
 *
 *
 *   
 * 
 * The BetwixtTransfomer support only one Element
betwixt:include.
 * This element is replaced with the marshalled object. The Object given
through the
 * attribute name will be searched in the request,
session,
 * context and at least in

Re: [Vote] Releasing 2.1.1

Vadim Gritsenko wrote:
Reinhard Poetz wrote:

a comment by Vadim:
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=106096301526641&w=2
My comment has nothing to do with proxies. As Joerg found out, this is 
the problem with M$ html "extensions" and XPath:

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

Consensus was to switch away from yahoo to some other site, say, google. 
Not sure if it was done or not yet...

Vadim
The switch is done, it's a really pure list of Google tech and SciFi 
news until now.

Joerg

Re: cvs commit:cocoon-2.1/src/blocks/woody/java/org/apache/cocoon/woody/flow/javascriptwoody.js

Christopher Oliver wrote:

The code you copied was an incorrect workaround for an old bug. Just remove it.

Ok, thanks.

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: Flow and map:handle-errors

Timothy Larson wrote:

If I request a page where the pipeline encounters an error (e.g. file not found) then the handle-errors pipeline is invoked. However, when I request the same page from the flow with cocoon.sendPageAndWait("somepage"); the handle-errors pipeline is not invoked and no exception is thrown either.

Can anyone else confirm this?

Error-handlers are not invoked on internal requests, which is what the
flow uses behind sendPage[AndWait](). In that case, the exception are
propagated.

Internal requests are created in 2 circumstances :
- use of SitemapSource: SourceResolver.resolveURI("cocoon:/blah")
- use of internal redirects: or
Redirector.redirect("cocoon:/blah")

The flow uses an internal redirect to handle an external request. This
means that the propagated exception is only catched by the top-level
Cocoon object which outputs the default error page (if configured to do
so). So we can say that the behaviour of not executing error handlers
for internal requests is not suitable for internal redirects.

There are 2 solutions to solve this :
1/ apply the same policy for internal redirects than the one that was
active before the redirect (i.e. handle errors on internal redirects
resulting from external requests)
2/ let the user choose the behaviour through the a new attribute such as
handle-internal="true" on .

Thinking further, these 2 solutions are complementary if we consider
that 2/ applies only to internal requests produced by the SitemapSource.

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: cvs commit:cocoon-2.1/src/blocks/woody/java/org/apache/cocoon/woody/flow/javascriptwoody.js

The code you copied was an incorrect workaround for an old bug. Just
remove it.

-Original Message-
From: Sylvain Wallez [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, September 09, 2003 12:45 PM
To: [EMAIL PROTECTED]
Subject: Re: cvs
commit:cocoon-2.1/src/blocks/woody/java/org/apache/cocoon/woody/flow/jav
ascriptwoody.js

Christopher Oliver wrote:

>Never. It's a bug in the flow implementation if it is. The script
shouldn't check for it.
>

Sorry Chris, but I just copied over to showForm() some code that you 
wrote in show(), without really understanding its behaviour ;-)

Is this related to an old bug ? Can we safely remove this check ?

>-Original Message-
>From: Bruno Dumon [mailto:[EMAIL PROTECTED] 
>Sent: Tuesday, September 09, 2003 7:42 AM
>To: [EMAIL PROTECTED]
>Subject: Re: cvs
>commit:cocoon-2.1/src/blocks/woody/java/org/apache/cocoon/woody/flow/ja
v
>ascriptwoody.js
>
>On Tue, 2003-09-09 at 16:38, [EMAIL PROTECTED] wrote:
>
>  
>
>>  +while (true) {
>>  +if (cocoon.request == null) {
>>  +// this continuation has been invalidated
>>  +this.dead = true;
>>  +handleInvalidContinuation();
>>  +Woody.suicide();
>>  +}
>>
>>
>While we're at it... anyone knows under what conditions exactly the
cocoon.request can be null?
>

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

Flow and map:handle-errors

2003-09-09 Thread Timothy Larson

If I request a page where the pipeline encounters an error
(e.g. file not found) then the handle-errors pipeline is
invoked. However, when I request the same page from the flow
with cocoon.sendPageAndWait("somepage"); the handle-errors
pipeline is not invoked and no exception is thrown either.

Can anyone else confirm this?

--Tim Larson


__
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com

Re: cvs commit:cocoon-2.1/src/blocks/woody/java/org/apache/cocoon/woody/flow/javascriptwoody.js

Christopher Oliver wrote:

Never. It's a bug in the flow implementation if it is. The script shouldn't check for it.

Sorry Chris, but I just copied over to showForm() some code that you 
wrote in show(), without really understanding its behaviour ;-)

Is this related to an old bug ? Can we safely remove this check ?

-Original Message-
From: Bruno Dumon [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, September 09, 2003 7:42 AM
To: [EMAIL PROTECTED]
Subject: Re: cvs
commit:cocoon-2.1/src/blocks/woody/java/org/apache/cocoon/woody/flow/jav
ascriptwoody.js

On Tue, 2003-09-09 at 16:38, [EMAIL PROTECTED] wrote:

 

 +while (true) {
 +if (cocoon.request == null) {
 +// this continuation has been invalidated
 +this.dead = true;
 +handleInvalidContinuation();
 +Woody.suicide();
 +}
   

While we're at it... anyone knows under what conditions exactly the cocoon.request can be null?

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: Removing usage of LogKitManager / LogKitManagable

Ok, done. The vote for the change was unambiguous. Please review my 
commits and change the code if necessary.

Joerg

Peter Royal wrote:

On Tuesday, September 9, 2003, at 12:34  PM, Joerg Heinicke wrote:

Hello Peter,

we already have this:
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=106215953707243&w=2
and this:
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21730.
If it's wished I can do the change again and commit it immediately.

Anybody against it?


That's what I get for not paying attention :)

I say commit it. I also have some slight changes to go on top of that 
when subclassing CocoonServlet to have it connect to an existing Logger 
hierarchy that I'll apply when you're done.
-pete

RE: cvs commit:cocoon-2.1/src/blocks/woody/java/org/apache/cocoon/woody/flow/javascriptwoody.js

Never. It's a bug in the flow implementation if it is. The script
shouldn't check for it.

-Original Message-
From: Bruno Dumon [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, September 09, 2003 7:42 AM
To: [EMAIL PROTECTED]
Subject: Re: cvs
commit:cocoon-2.1/src/blocks/woody/java/org/apache/cocoon/woody/flow/jav
ascriptwoody.js

On Tue, 2003-09-09 at 16:38, [EMAIL PROTECTED] wrote:

>   +while (true) {
>   +if (cocoon.request == null) {
>   +// this continuation has been invalidated
>   +this.dead = true;
>   +handleInvalidContinuation();
>   +Woody.suicide();
>   +}

While we're at it... anyone knows under what conditions exactly the
cocoon.request can be null?

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

DO NOT REPLY [Bug 21730] - [PATCH] LogKitManager => LoggerManager

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

[PATCH] LogKitManager => LoggerManager





--- Additional Comments From [EMAIL PROTECTED]  2003-09-09 19:15 ---
Created an attachment (id=8118)
The patch against the current CocoonTask.java after it has moved into the scratchpad 
block.

DO NOT REPLY [Bug 21730] - [PATCH] LogKitManager => LoggerManager

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

[PATCH] LogKitManager => LoggerManager

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|RESOLVED|CLOSED

DO NOT REPLY [Bug 21730] - [PATCH] LogKitManager => LoggerManager

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

[PATCH] LogKitManager => LoggerManager

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

DO NOT REPLY [Bug 21730] - [PATCH] LogKitManager => LoggerManager

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

[PATCH] LogKitManager => LoggerManager





--- Additional Comments From [EMAIL PROTECTED]  2003-09-09 19:16 ---
Created an attachment (id=8119)
The three patched files Cocoon.java, CocoonWrapper.java and CocoonServlet.java.

DO NOT REPLY [Bug 21730] - [PATCH] LogKitManager => LoggerManager

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

[PATCH] LogKitManager => LoggerManager

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |ASSIGNED



--- Additional Comments From [EMAIL PROTECTED]  2003-09-09 19:14 ---
Attachements 7387 - 7390 are outdated. The updated patches are already added to
the CVS, but will be added here for completeness.

Re: Announcing 2.1.1

2003-09-09 Thread Steven Noels

Joerg Heinicke wrote:

We are helpless without Carsten :-)

Joerg

Sylvain Wallez wrote:

Hi team,

The 2.1.1 should now have reached the mirrors. Does someone know how 
to update the web site and send the announcements ?
I'll update the main website tomorrow (just the news page on the 
cocoon.apache.org). I wouldn't update the complete 
cocoon.apache.org/2.1/ right now, since the current content is still 
valid, and the reshuffling that Carsten started seems more aimed at an 
upcoming 2.2 release, and might need some more work. That leaves us with 
the security warning missing from the 2.1 site... maybe a partial update 
of the main page is enough.

I'll send out an announcement after that.


--
Steven Noelshttp://outerthought.org/
Outerthought - Open Source Java & XMLAn Orixo Member
Read my weblog athttp://blogs.cocoondev.org/stevenn/
stevenn at outerthought.orgstevenn at apache.org

Re: New protocol for in-memory resources

Tuomo L wrote:

Hi,

I've been playing with the upload-mechanism of Cocoon, and noticed that
it's now required to cath the uploaded file since cocoon deletes it (At
least this is the behaviour on my 2.1 installation with "autosave-upload"
true and "allow-uploads" true)
I'm working on a "ZipArchiveExtractorAction", which accepts two
parameters via sitemap: "source" and "target".
Now, with source resolving, I can use protocols such as:
"cocoon://foo.zip", "context://foo.zip" etc. It would be convinient,
if one could use a protocolthat defines a source (FilePart) located in memory.
This could be for example: "multipart://foo.zip" . Then it would
be possible to extract that in-memory zip-file to the target-dir.
Is this possible already, or am I going to wrong direction here?
 

This is not possible today, but really is the right direction, and would 
be a valuable addition.

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

New protocol for in-memory resources

2003-09-09 Thread Tuomo L

Hi,

I've been playing with the upload-mechanism of Cocoon, and noticed that
it's now required to cath the uploaded file since cocoon deletes it (At
least this is the behaviour on my 2.1 installation with "autosave-upload"
true and "allow-uploads" true)

I'm working on a "ZipArchiveExtractorAction", which accepts two
parameters via sitemap: "source" and "target".

Now, with source resolving, I can use protocols such as:
"cocoon://foo.zip", "context://foo.zip" etc. It would be convinient,
if one could use a protocolthat defines a source (FilePart) located in memory.
This could be for example: "multipart://foo.zip" . Then it would
be possible to extract that in-memory zip-file to the target-dir.

Is this possible already, or am I going to wrong direction here?

-Tuomo

RE: "Remove" problems with the Woody sample

2003-09-09 Thread Hugo Burm



> -Original Message-
> From: Bruno Dumon [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, September 09, 2003 11:05 AM
> To: [EMAIL PROTECTED]
> Subject: Re: "Remove" problems with the Woody sample
>
>
> On Sat, 2003-09-06 at 13:39, Hugo Burm wrote:
> > This is about the "Bean Binding" sample on the Woody samples
> page, and the
> > "Remove" option of the Contacts on this page.
> > (Cocoon version: 2.1.2, one day after the release of 2.1.1)
> >
> > 1)
> > If I have more than one Contact (e.g. by adding the lines
> > contact = new Packages.org.apache.cocoon.woody.samples.Contact();
> > contact.setId("2");
> > contact.setFirstName("Hugo");
> > bean.addContact(contact);
> > to the "form2bean" function in "binding_example.js"),
> > I cannot delete more than one at a time. When I check two
> Contacts, Click on
> > "Remove selected contacts", then only one of them is removed.
>
> You mean that only one is removed _after performing the binding_, right?
> They are both removed from the repeater-widget, but there's something
> wrong in the repeater binding indeed. It doesn't work for binding to XML
> documents either.

Yes, that is wat I meant. After pressing "Submit Query", one of the two
contacts that was just removed by the repeater, re-appears. Sorry for not
explaining that clearly.

>
> This seems to be caused by the classical problem when removing items
> from a list while running through it.
>
> I've tried to solve this by first storing the JXPathContexts of the
> items to delete in a seperate list, and then running backwards through
> that list, and it seems to work all right. Will commit this soon.
>
> Thanks for reporting this problem!
>

Thanks for repairing it.

> >
> > 2)
> > The Contacts are not removed from the ArrayList. By the Remove
> option, all
> > relevant keys of the Contact are set to null, so you will never
> see it again
> > in this context.  But the item is not removed from the list. This is a
> > problem if you have a persistence framework flushing the list
> to hard disk
> > (zombie records in your database).
> >
>
> Not sure that I follow here: I suppose that if I don't see the item
> anymore on jx-generated page, it really isn't in the arraylist anymore?
>

Because this occured both for the standaard Woody repeater and for my own
map-repeater which uses Maps instead of ArrayLists, I concluded it was a
Woody problem. But now I did some additionally checks, it looks like it is a
Hibernate problem. Hibernate is doing runtime reflection: it replaces the
instances of the classes like Maps, Lists, Sets with its own instances in
order to do its O/R mapping. May be there is a problem with JXPath. I have
to post this to some other list.


> >
> > I checked the Woody source. I guess it must be the JXPath
> removePath() in
> > DeleteNodeJXPathBinding.java.
> > What is this removePath() supposed to do?
>
> Remove the addressed path. If it addresses an item in a collection, it
> means removing the item from the collection.

That was what I was wondering about: does it actually remove it from the
Collection, or does it just set all keys to null, like it is doing in my
environment. But now I have some obvious suspects for the latter behaviour
(the combination of Hibernate annd JXPath)

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


Hugo Burm

Re: cvs commit: cocoon-2.1/src/blocks/woody/java/org/apache/cocoon/woody/flow/javascript woody.js

On Tue, 2003-09-09 at 16:38, [EMAIL PROTECTED] wrote:

>   +while (true) {
>   +if (cocoon.request == null) {
>   +// this continuation has been invalidated
>   +this.dead = true;
>   +handleInvalidContinuation();
>   +Woody.suicide();
>   +}

While we're at it... anyone knows under what conditions exactly the
cocoon.request can be null?

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

Re: Exception during undeploy

Bruno Dumon wrote:

On Tue, 2003-09-09 at 17:30, Joerg Heinicke wrote:

As somebody might remember we had a problem with the undeployment with 
Tomcat. This was fixed in Cocoon 2.1.1 by updating excalibur event and util 
concurrent IIRC. Now the undeployment works and no process hangs but I get 
an exception (see below). Does any body has an idea (JBoss 3.0.6, Tomcat 
4.1.18, Cocoon 2.1.1, Java 1.4.1_03)? This exception did not occur in the 
three weeks old Cocoon version.


Could there be an older version of the PooledExecutor class somewhere in
the classpath?
Hmm, I can not imagine where it shall come from, but I will have a look 
tomorrow. Thanks for the - actually obvious - hint.

Joerg



2003-09-09 17:23:37,338 ERROR [org.jboss.web.localhost.Engine] - Root 
Cause -
java.lang.NoSuchMethodError: 
EDU.oswego.cs.dl.util.concurrent.PooledExecutor.shutdownNow()V
at 
org.apache.excalibur.event.command.TPCThreadManager.doDispose(TPCThreadManager.java:179)
at 
org.apache.excalibur.event.command.AbstractThreadManager.dispose(AbstractThreadManager.java:231)

Re: Announcing 2.1.1

We are helpless without Carsten :-)

Joerg

Sylvain Wallez wrote:

Hi team,

The 2.1.1 should now have reached the mirrors. Does someone know how to 
update the web site and send the announcements ?

Sylvain

Re: Removing usage of LogKitManager / LogKitManagable

2003-09-09 Thread Peter Royal

On Tuesday, September 9, 2003, at 12:34  PM, Joerg Heinicke wrote:
Hello Peter,

we already have this:
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=106215953707243&w=2
and this:
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21730.
If it's wished I can do the change again and commit it immediately.

Anybody against it?
That's what I get for not paying attention :)

I say commit it. I also have some slight changes to go on top of that 
when subclassing CocoonServlet to have it connect to an existing Logger 
hierarchy that I'll apply when you're done.
-pete

Announcing 2.1.1

Hi team,

The 2.1.1 should now have reached the mirrors. Does someone know how to 
update the web site and send the announcements ?

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: [RT] Implementing Cocoon Blocks

2003-09-09 Thread Geoff Howard

Bruno Dumon wrote:
On Sat, 2003-08-30 at 04:57, Geoff Howard wrote:

But this brings up another point - what to do if the wiring.xml and 
others is deleted?  Presumably, all blocks are "uninstalled" in this 
state, but what does this do to persistence requirements.

Also, how to recreate the deploy step efficiently?  For example:

You deploy a block with some dependencies and configuration.  The block 
deploy process walks you through setting configs and resolving 
dependencies.  You then have no record of these deployment choices 
except in wiring.xml which is not meant for human consumption.  Perhaps 
it would be good to record these human-step deployment time 
configurations in a conf file which could be easily reprocessed to 
easily re-deploy all blocks to their last configuration.


I think the conf file you're speaking of here is simply the wiring.xml
file itself? Remember, the block deployer has read-write access to this
file, so it can first read the existing information, then let the
administrator modify it, and then write it back. It's not like each time
you want to modify the configuration of one block you'll have to
re-enter all the parameters for other blocks as well.
Ugh, I see now that I didn't explain well the scenario I was thinking of 
and now can't remember!  IIRC I was trying to think through the process 
of replication and/or staging.  In this case, would I copy over 
wiring.xml and all blocks directories? (presumably)  But, what if some 
of the deploy-time configurations need to change on the way?  For 
instance, on a staging server, you use a different database.  So, I was 
just trying to get a picture in my head of how that would work and what 
the pitfalls were.

Geoff

Re: [RT] Implementing Cocoon Blocks

2003-09-09 Thread Geoff Howard

Bruno Dumon wrote:
(catching up on block discussions...)

On Fri, 2003-08-29 at 05:53, Geoff Howard wrote:

Implementation Phases
-
Phase 1: definition of the contract between the block manager inside 
cocoon and the standalone block deployer. These contracts include:

1) description of the file system layout (see above for a suggestion)
2) description of the wiring document schema
3) description of the block metadata schema
Ok, the file system seems fine - how about starting the discussion with 
the following for the wiring document?  (I'm assuming stuff will have to 
change - just trying to get the ball rolling)



  
/mail/

  
name="external-skin">cob:yetanothercompany.com/skins/fancy/1.2.2
  cob:mycompany.com/skins/corporate/34.3.345
  cob:mycompany.com/repositories/email/exchange/3.2.1


  guest
  sj3u493

  
  

  mail.blah.org

  
  
  


Wiki'd here: http://wiki.cocoondev.org/Wiki.jsp?page=BlocksWiring

For sake of discussion, I recorded a wire-id instead of the location. 
Can blocks be in other locations other than WEB-INF/blocks/{$wire-id} ?

I also considered recording the wire-id instead of the uri for 
connections between blocks - what are the arguments for each?

 was out of the blue using the wiring metaphore.  Other 
options?  Free association: connect, attach, solder, wire, use ...
Avalon Phoenix uses the words "assembly" and "provide" instead of
"wiring" and "connection", which I quite like (I mean the assembly &
provide).
I don't quite see where these terms would be used - can you explain a 
little more?  Maybe a proposed set of changes to the example above?

Geoff

Re: Exception during undeploy

On Tue, 2003-09-09 at 17:30, Joerg Heinicke wrote:
> As somebody might remember we had a problem with the undeployment with 
> Tomcat. This was fixed in Cocoon 2.1.1 by updating excalibur event and util 
> concurrent IIRC. Now the undeployment works and no process hangs but I get 
> an exception (see below). Does any body has an idea (JBoss 3.0.6, Tomcat 
> 4.1.18, Cocoon 2.1.1, Java 1.4.1_03)? This exception did not occur in the 
> three weeks old Cocoon version.

Could there be an older version of the PooledExecutor class somewhere in
the classpath?

> 
> Joerg
> 
> 
> 2003-09-09 17:23:37,328 ERROR [org.jboss.web.localhost.Engine] 
> StandardWrapper[:Cocoon]: Servlet Cocoon threw unload() exception
> javax.servlet.ServletException: Servlet.destroy() for servlet Cocoon threw 

> 
> 2003-09-09 17:23:37,338 ERROR [org.jboss.web.localhost.Engine] - Root 
> Cause -
> java.lang.NoSuchMethodError: 
> EDU.oswego.cs.dl.util.concurrent.PooledExecutor.shutdownNow()V
>  at 
> org.apache.excalibur.event.command.TPCThreadManager.doDispose(TPCThreadManager.java:179)
>  at 
> org.apache.excalibur.event.command.AbstractThreadManager.dispose(AbstractThreadManager.java:231)
>  at 


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

Re: Removing usage of LogKitManager / LogKitManagable

Hello Peter,

we already have this:
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=106215953707243&w=2
and this:
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21730.
If it's wished I can do the change again and commit it immediately.

Anybody against it?

Joerg

Peter Royal wrote:

Anyone opposed to removing the usage of the LogKitManagable interface 
from HEAD?

The impact is that Loggable components would no longer be able to 
receive a logger, and on the flipside, Log4J support will be much easier 
to implement as all logging-impl specific code is then in CocoonServlet, 
Cocoon.java and all other classes will just deal with the Avalon facade.

-pete

Exception during undeploy

As somebody might remember we had a problem with the undeployment with 
Tomcat. This was fixed in Cocoon 2.1.1 by updating excalibur event and util 
concurrent IIRC. Now the undeployment works and no process hangs but I get 
an exception (see below). Does any body has an idea (JBoss 3.0.6, Tomcat 
4.1.18, Cocoon 2.1.1, Java 1.4.1_03)? This exception did not occur in the 
three weeks old Cocoon version.

Joerg

2003-09-09 17:23:37,328 ERROR [org.jboss.web.localhost.Engine] 
StandardWrapper[:Cocoon]: Servlet Cocoon threw unload() exception
javax.servlet.ServletException: Servlet.destroy() for servlet Cocoon threw 
exception
at 
org.apache.catalina.core.StandardWrapper.unload(StandardWrapper.java:1134)
at 
org.apache.catalina.core.StandardWrapper.stop(StandardWrapper.java:1353)
at 
org.apache.catalina.core.ContainerBase.removeChild(ContainerBase.java:1036)
at 
org.apache.catalina.startup.ContextConfig.stop(ContextConfig.java:701)
at 
org.apache.catalina.startup.ContextConfig.lifecycleEvent(ContextConfig.java:245)
at 
org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:166)
at 
org.apache.catalina.core.StandardContext.stop(StandardContext.java:3672)
at 
org.apache.catalina.core.ContainerBase.removeChild(ContainerBase.java:1036)
at 
org.apache.catalina.core.StandardHostDeployer.remove(StandardHostDeployer.java:420)
at org.apache.catalina.core.StandardHost.remove(StandardHost.java:852)
at 
org.jboss.web.catalina.EmbeddedCatalinaService41.performUndeploy(EmbeddedCatalinaService41.java:330)
at 
org.jboss.web.AbstractWebContainer.stop(AbstractWebContainer.java:345)
at org.jboss.deployment.MainDeployer.stop(MainDeployer.java:475)
at org.jboss.deployment.MainDeployer.stop(MainDeployer.java:490)
at org.jboss.deployment.MainDeployer.undeploy(MainDeployer.java:449)
at org.jboss.deployment.MainDeployer.undeploy(MainDeployer.java:444)
at org.jboss.deployment.MainDeployer.undeploy(MainDeployer.java:417)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:324)
at 
org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispatcher.java:284)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:517)
at org.jboss.util.jmx.MBeanProxy.invoke(MBeanProxy.java:174)
at $Proxy3.undeploy(Unknown Source)
at 
org.jboss.deployment.scanner.URLDeploymentScanner.undeploy(URLDeploymentScanner.java:465)
at 
org.jboss.deployment.scanner.URLDeploymentScanner.scan(URLDeploymentScanner.java:554)
at 
org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.doScan(AbstractDeploymentScanner.java:212)
at 
org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.loop(AbstractDeploymentScanner.java:225)
at 
org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.run(AbstractDeploymentScanner.java:202)

2003-09-09 17:23:37,338 ERROR [org.jboss.web.localhost.Engine] - Root 
Cause -
java.lang.NoSuchMethodError: 
EDU.oswego.cs.dl.util.concurrent.PooledExecutor.shutdownNow()V
at 
org.apache.excalibur.event.command.TPCThreadManager.doDispose(TPCThreadManager.java:179)
at 
org.apache.excalibur.event.command.AbstractThreadManager.dispose(AbstractThreadManager.java:231)
at 
org.apache.avalon.framework.container.ContainerUtil.dispose(ContainerUtil.java:328)
at org.apache.cocoon.Cocoon.dispose(Cocoon.java:499)
at 
org.apache.cocoon.servlet.CocoonServlet.disposeCocoon(CocoonServlet.java:1472)
at 
org.apache.cocoon.servlet.CocoonServlet.destroy(CocoonServlet.java:519)
at 
org.apache.catalina.core.StandardWrapper.unload(StandardWrapper.java:1123)
at 
org.apache.catalina.core.StandardWrapper.stop(StandardWrapper.java:1353)
at 
org.apache.catalina.core.ContainerBase.removeChild(ContainerBase.java:1036)
at 
org.apache.catalina.startup.ContextConfig.stop(ContextConfig.java:701)
at 
org.apache.catalina.startup.ContextConfig.lifecycleEvent(ContextConfig.java:245)
at 
org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:166)
at 
org.apache.catalina.core.StandardContext.stop(StandardContext.java:3672)
at 
org.apache.catalina.core.ContainerBase.removeChild(ContainerBase.java:1036)
at 
org.apache.catalina.core.StandardHostDeployer.remove(StandardHostDeployer.java:420)
at org.apache.catalina.core.StandardHost.remove(StandardHost.java:852)
at 
org.jboss.web.catalina.EmbeddedCatalinaService41.performUndeploy(EmbeddedCatalinaService41.java:330)
at

Re: [RT] Implementing Cocoon Blocks

On Sat, 2003-08-30 at 04:57, Geoff Howard wrote:

> But this brings up another point - what to do if the wiring.xml and 
> others is deleted?  Presumably, all blocks are "uninstalled" in this 
> state, but what does this do to persistence requirements.
> 
> Also, how to recreate the deploy step efficiently?  For example:
> 
> You deploy a block with some dependencies and configuration.  The block 
> deploy process walks you through setting configs and resolving 
> dependencies.  You then have no record of these deployment choices 
> except in wiring.xml which is not meant for human consumption.  Perhaps 
> it would be good to record these human-step deployment time 
> configurations in a conf file which could be easily reprocessed to 
> easily re-deploy all blocks to their last configuration.

I think the conf file you're speaking of here is simply the wiring.xml
file itself? Remember, the block deployer has read-write access to this
file, so it can first read the existing information, then let the
administrator modify it, and then write it back. It's not like each time
you want to modify the configuration of one block you'll have to
re-enter all the parameters for other blocks as well.

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

Re: strange ...

On Tue, Sep 09, 2003 at 03:19:17PM +0200, Bruno Dumon wrote:
> On Tue, 2003-09-09 at 15:09, Leszek Gawron wrote:
> > On Tue, Sep 09, 2003 at 02:35:10PM +0200, Bruno Dumon wrote:
> > I think this couldn't work as the Cocoon FOM when 
> > cocoon.request.getParameter( "test" ) is issued does 
> > request.getParameter( "test" );
> > 
> > while the xsp-request logicsheet performs encoding translation:
> > 
> > public static String getParameter(Map objectModel, String name,
> >   String defaultValue, String form_encoding,
> >   String container_encoding) {
> > if(container_encoding == null)
> > container_encoding = "ISO-8859-1"; // default per Servlet spec
> > 
> > Request request = ObjectModelHelper.getRequest(objectModel);
> > String value = request.getParameter(name);
> > if(form_encoding != null && value != null && value.length() > 0) {
> > try {
> > value = new String(value.getBytes(container_encoding), 
> > form_encoding);
> > } catch(java.io.UnsupportedEncodingException uee) {
> > throw new CascadingRuntimeException("Unsupported Encoding 
> > Exception", uee);
> >}
> > }
> > 
> > if (value == null) {
> > value = defaultValue;
> > }
> > 
> > return value;
> > }
> 
> This translation is also part of the Cocoon Http Request object wrapper,
> and will be activated if you either set the relevant parameters in the
> web.xml or use the SetCharacterEncodingAction
I have found the problem!! :)
cocoon.request.getParameter( "test" ) returns proper string with national
characters

while cocoon.request.get( "test" ) does not !
LG
-- 
__
 | /  \ |Leszek Gawron//  \\
\_\\  //_/   [EMAIL PROTECTED]   _\\()//_
 .'/()\'. Phone: +48(501)720812 / //  \\ \
  \\  //  recursive: adj; see recursive  | \__/ |

Re: strange ...

On Tue, 2003-09-09 at 15:09, Leszek Gawron wrote:
> On Tue, Sep 09, 2003 at 02:35:10PM +0200, Bruno Dumon wrote:
> I think this couldn't work as the Cocoon FOM when 
> cocoon.request.getParameter( "test" ) is issued does 
> request.getParameter( "test" );
> 
> while the xsp-request logicsheet performs encoding translation:
> 
> public static String getParameter(Map objectModel, String name,
>   String defaultValue, String form_encoding,
>   String container_encoding) {
> if(container_encoding == null)
> container_encoding = "ISO-8859-1"; // default per Servlet spec
> 
> Request request = ObjectModelHelper.getRequest(objectModel);
> String value = request.getParameter(name);
> if(form_encoding != null && value != null && value.length() > 0) {
> try {
> value = new String(value.getBytes(container_encoding), 
> form_encoding);
> } catch(java.io.UnsupportedEncodingException uee) {
> throw new CascadingRuntimeException("Unsupported Encoding 
> Exception", uee);
>}
> }
> 
> if (value == null) {
> value = defaultValue;
> }
> 
> return value;
> }

This translation is also part of the Cocoon Http Request object wrapper,
and will be activated if you either set the relevant parameters in the
web.xml or use the SetCharacterEncodingAction

there's some information about this here:
http://wiki.cocoondev.org/Wiki.jsp?page=RequestParameterEncoding

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

Re: [RT] Implementing Cocoon Blocks

(catching up on block discussions...)

On Fri, 2003-08-29 at 05:53, Geoff Howard wrote:

> > Implementation Phases
> > -
> > 
> > Phase 1: definition of the contract between the block manager inside 
> > cocoon and the standalone block deployer. These contracts include:
> > 
> >  1) description of the file system layout (see above for a suggestion)
> >  2) description of the wiring document schema
> >  3) description of the block metadata schema
> 
> Ok, the file system seems fine - how about starting the discussion with 
> the following for the wiring document?  (I'm assuming stuff will have to 
> change - just trying to get the ball rolling)
> 
> 
> 
>
>  /mail/
>  
> name="external-skin">cob:yetanothercompany.com/skins/fancy/1.2.2
> name="internal-skin">cob:mycompany.com/skins/corporate/34.3.345
> name="repository">cob:mycompany.com/repositories/email/exchange/3.2.1
>  
>  
>guest
>sj3u493
>  
>
> wire-id="394781274834">
>  
>mail.blah.org
>  
>
> wire-id="947384127832"/>
> wire-id="746394782637"/>
> 
> 
> Wiki'd here: http://wiki.cocoondev.org/Wiki.jsp?page=BlocksWiring
> 
> For sake of discussion, I recorded a wire-id instead of the location. 
> Can blocks be in other locations other than WEB-INF/blocks/{$wire-id} ?
> 
> I also considered recording the wire-id instead of the uri for 
> connections between blocks - what are the arguments for each?
> 
>  was out of the blue using the wiring metaphore.  Other 
> options?  Free association: connect, attach, solder, wire, use ...

Avalon Phoenix uses the words "assembly" and "provide" instead of
"wiring" and "connection", which I quite like (I mean the assembly &
provide).

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

RE: Woody: repeater handlers

2003-09-09 Thread Gunter D'Hondt

Sorry, my mistake!

RepeaterHandler != FormHandler and a FormHandler can contain multiple
RepeaterHandlers

Gunter


-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Gunter D'Hondt
Sent: dinsdag 9 september 2003 15:09
To: [EMAIL PROTECTED]
Subject: Woody: repeater handlers


I'm trying to build a page with two repeater widgets which each have
their own events. But the RepeaterHandler (=FormHandler) class can only
handle events for one repeater (only one repeaterName, addCommand,
removeCommand, etc). 

Any suggestions how to expand this so that the sample form could include
another repeater with its own add/remove buttons?

Gunter D'Hondt 
Sofico NV

Removing usage of LogKitManager / LogKitManagable

2003-09-09 Thread Peter Royal

Anyone opposed to removing the usage of the LogKitManagable interface 
from HEAD?

The impact is that Loggable components would no longer be able to 
receive a logger, and on the flipside, Log4J support will be much 
easier to implement as all logging-impl specific code is then in 
CocoonServlet, Cocoon.java and all other classes will just deal with 
the Avalon facade.

-pete

Woody: repeater handlers

2003-09-09 Thread Gunter D'Hondt

I'm trying to build a page with two repeater widgets which each have
their own events. But the RepeaterHandler (=FormHandler) class can only
handle events for one repeater (only one repeaterName, addCommand,
removeCommand, etc). 

Any suggestions how to expand this so that the sample form could include
another repeater with its own add/remove buttons?

Gunter D'Hondt 
Sofico NV

Re: strange ...

On Tue, Sep 09, 2003 at 02:35:10PM +0200, Bruno Dumon wrote:
I think this couldn't work as the Cocoon FOM when 
cocoon.request.getParameter( "test" ) is issued does 
request.getParameter( "test" );

while the xsp-request logicsheet performs encoding translation:

public static String getParameter(Map objectModel, String name,
  String defaultValue, String form_encoding,
  String container_encoding) {
if(container_encoding == null)
container_encoding = "ISO-8859-1"; // default per Servlet spec

Request request = ObjectModelHelper.getRequest(objectModel);
String value = request.getParameter(name);
if(form_encoding != null && value != null && value.length() > 0) {
try {
value = new String(value.getBytes(container_encoding), form_encoding);
} catch(java.io.UnsupportedEncodingException uee) {
throw new CascadingRuntimeException("Unsupported Encoding Exception", 
uee);
   }
}

if (value == null) {
value = defaultValue;
}

return value;
}

LG
-- 
__
 | /  \ |Leszek Gawron//  \\
\_\\  //_/   [EMAIL PROTECTED]   _\\()//_
 .'/()\'. Phone: +48(501)720812 / //  \\ \
  \\  //  recursive: adj; see recursive  | \__/ |

Re: strange ...

On Tue, Sep 09, 2003 at 02:35:10PM +0200, Bruno Dumon wrote:
> On Tue, 2003-09-09 at 14:30, Leszek Gawron wrote:
> > getLogger().error( "!!" + request.getCharacterEncoding() );
> > outputs: 
> > 
> > ERROR   (2003-09-09) 14:27.57:265   [sitemap.action.serverpages]
> > (/gemini-manager/projects/server-works/2) Thread-11/request_xsp: !!null
> 
> Why is this strange? Hasn't this always been the case?
> getCharacterEncoding only returns something if the browser supplied it,
> which most don't.
> 
> > 
> > all my database scripts gone crazy and mix up all polish letters on inserts
> > 
> 
> Are the strings correct before sending them to the database? If so,
> seems more like a database or database driver problem.
this is what get's logged when I issue 
getLogger().error(  )

(/gemini-manager/) Thread-11/request_xsp: łżę2

(I do not know if you will see polish letters but trust me this is correct)

the same one did under flow via 
cocoon.log.error( cocoon.request.get( "test" ) );

Thread-8/FOM_Cocoon$FOM_Log: Ä?
I am nearly sure that this worked few days ago (I've been updating cocoon much
so I cannot give you the exact date)
LG

-- 
__
 | /  \ |Leszek Gawron//  \\
\_\\  //_/   [EMAIL PROTECTED]   _\\()//_
 .'/()\'. Phone: +48(501)720812 / //  \\ \
  \\  //  recursive: adj; see recursive  | \__/ |

[OT] GetTogether - arrivals and departures

2003-09-09 Thread Torsten Curdt

Hi, guys!

I thought it might be cool to know when everyone is
heading to (and leaving from) Genth. If you already
know why not add it to...
http://wiki.cocoondev.org/Wiki.jsp?page=GetTogetherAttending

cheers
--
Torsten

Re: strange ...

On Tue, 2003-09-09 at 14:30, Leszek Gawron wrote:
> getLogger().error( "!!" + request.getCharacterEncoding() );
> outputs: 
> 
> ERROR   (2003-09-09) 14:27.57:265   [sitemap.action.serverpages]
> (/gemini-manager/projects/server-works/2) Thread-11/request_xsp: !!null

Why is this strange? Hasn't this always been the case?
getCharacterEncoding only returns something if the browser supplied it,
which most don't.

> 
> all my database scripts gone crazy and mix up all polish letters on inserts
> 

Are the strings correct before sending them to the database? If so,
seems more like a database or database driver problem.

>   LG
> 
> PS. cocoon current cvs version

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

strange ...


getLogger().error( "!!" + request.getCharacterEncoding() );
outputs: 

ERROR   (2003-09-09) 14:27.57:265   [sitemap.action.serverpages]
(/gemini-manager/projects/server-works/2) Thread-11/request_xsp: !!null

all my database scripts gone crazy and mix up all polish letters on inserts

LG

PS. cocoon current cvs version

-- 
__
 | /  \ |Leszek Gawron//  \\
\_\\  //_/   [EMAIL PROTECTED]   _\\()//_
 .'/()\'. Phone: +48(501)720812 / //  \\ \
  \\  //  recursive: adj; see recursive  | \__/ |

Re: Problems integrating Cocoon build in our build system

Now, I have not been looking at it until some minutes ago. But unfortunately 
it did not help me. The first steps I have already done and the xpatching of 
any files I don't really need (at least until now).

And I wonder how the validate jars works for you if not only by accident. 
The hard coded "relativation" of a possible absolute path can not work in 
many cases. If I deactivate javadoc and validate jars it works for me as I 
want it.

Joerg

Steven Noels wrote:
Joerg Heinicke wrote:

We have a global repository that now also stores the Cocoon 2.1.1 
sources. If one wants to use Cocoon in his project he has to build it 
after setting some properties (the normal local.*.properties). The 
Cocoon sources in the repository shall stay untouched of course. 
Therefore I set the properties ${build.root}, ${tools.tasks.dest}, 
${tools.loader.dest} and almost everything works ...


Joerg, off the top of my head: have you looked at 
http://wiki.cocoondev.org/Wiki.jsp?page=YourCocoonBasedProject

We use this approach for a large Woody-based project we are working on 
with a customer, and it works rather well.


--
System Development
VIRBUS AG
Fon  +49(0)341-979-7419
Fax  +49(0)341-979-7409
[EMAIL PROTECTED]
www.virbus.de

Re: Problems integrating Cocoon build in our build system

2003-09-09 Thread Steven Noels

Joerg Heinicke wrote:

We have a global repository that now also stores the Cocoon 2.1.1 
sources. If one wants to use Cocoon in his project he has to build it 
after setting some properties (the normal local.*.properties). The 
Cocoon sources in the repository shall stay untouched of course. 
Therefore I set the properties ${build.root}, ${tools.tasks.dest}, 
${tools.loader.dest} and almost everything works ...
Joerg, off the top of my head: have you looked at 
http://wiki.cocoondev.org/Wiki.jsp?page=YourCocoonBasedProject

We use this approach for a large Woody-based project we are working on 
with a customer, and it works rather well.


--
Steven Noelshttp://outerthought.org/
Outerthought - Open Source Java & XMLAn Orixo Member
Read my weblog athttp://blogs.cocoondev.org/stevenn/
stevenn at outerthought.orgstevenn at apache.org

Problems integrating Cocoon build in our build system

We have a global repository that now also stores the Cocoon 2.1.1 sources. 
If one wants to use Cocoon in his project he has to build it after setting 
some properties (the normal local.*.properties). The Cocoon sources in the 
repository shall stay untouched of course. Therefore I set the properties 
${build.root}, ${tools.tasks.dest}, ${tools.loader.dest} and almost 
everything works ...

1. Javadoc: It's not possible to build the Javadocs. I get an error message 
that a temporary file could not be created. I guess this is because of the 
write protection of the repository, but I don't know how to solve it.

2. validating jars: The current-jars.xml can not be accessed. This is 
because of the param in validate-build.xml line 52:



The ${build.root} is an absolute path pointing to a directory outside the 
repository, so the document($current-files) => 
document("../..//absolute/path/current-jars.xml") in the stylesheet fails. A 
possible solution is to make ${build.temp} always absolute (is it possible 
in any way with Ant?) or to test in the stylesheet if it's absolute.
But this would only solve one half of the problem. The stylesheet is taken 
from ${tools}/src/check-jars.xsl. Only for theory, but if this is also aside 
the normal processing, the ../.. would be wrong too. We could move the path 
resolving completely into the stylesheet, but that's not so nice IMO.

3. compiled tools classes: In general I don't like the idea of mixing source 
files and generated (or here compiled) files. Why are the tools classes 
output to the tools directory and not also to the build directory??

Joerg

--
System Development
VIRBUS AG
Fon  +49(0)341-979-7419
Fax  +49(0)341-979-7409
[EMAIL PROTECTED]
www.virbus.de

Re: "Remove" problems with the Woody sample