Re: DO NOT REPLY [Bug 31649] - [Patch] Flowscript: Switch to re-implementation of official Rhino

[Bertrand Delacretaz]

Le 16 oct. 04, à 08:07, [EMAIL PROTECTED] a écrit :
...After reading your reply twice I think that we don't need two rhino 
impls in a
built Cocoon. Maybe we can make it a switch during build?
(So we (I) wouldn't have to do all this renaming things ...)
I think a build-time switch would be sufficient.
-Bertrnad


smime.p7s
Description: S/MIME cryptographic signature

Re: [RT] Some notes about the "Real Blocks" issue

[Ralph Goers]

I'm curious about this for a completely different reason.  It has been 
the stated policy that every attempt will be made to use only formally 
released third-party jars in formal releases of Cocoon.  Does this mean 
that 2.1.6 cannot be released until Xalan 2.6.1 is released?  If not, 
please make the source this jar was built from available on the Cocoon site.

Ralph
Niclas Hedhman wrote:
Your talk is not entirely reflected by the actions of the community. I just 
did a svn up on the 2.1 branch;

A  lib/endorsed/xalan-2.6.1-dev-20041008T0304.jar
D  lib/endorsed/xalan-2.6.0.jar
Why does the 2.1 branch require a timestamped/snapshot version of Xalan, if 
everything is so fine and dandy with it?
Antonio makes the following motivation in the commit message;
"Update xalan to 2.6.1-dev-20041008T0304"

Just curious.
Niclas
 

DO NOT REPLY [Bug 31649] - [Patch] Flowscript: Switch to re-implementation of official Rhino

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=31649

[Patch] Flowscript: Switch to re-implementation of official Rhino





--- Additional Comments From [EMAIL PROTECTED]  2004-10-16 06:07 ---
Wow, that was quick! 
Thank you very much again!

The discussion on renaming of packages in rhino-1.4pre-cont has already started. 

After reading your reply twice I think that we don't need two rhino impls in a
built Cocoon. Maybe we can make it a switch during build? 
(So we (I) wouldn't have to do all this renaming things ...)

WDOT?

Re: [RT] Some notes about the "Real Blocks" issue

[Niclas Hedhman]

On Saturday 16 October 2004 04:55, Stefano Mazzocchi wrote:

> Because they have been around forever *AND* they don't change their
> contracts overnight. 

Your talk is not entirely reflected by the actions of the community. I just 
did a svn up on the 2.1 branch;

A  lib/endorsed/xalan-2.6.1-dev-20041008T0304.jar
D  lib/endorsed/xalan-2.6.0.jar

Why does the 2.1 branch require a timestamped/snapshot version of Xalan, if 
everything is so fine and dandy with it?
Antonio makes the following motivation in the commit message;
"Update xalan to 2.6.1-dev-20041008T0304"

Just curious.
Niclas
-- 
   +--//---+
  / http://www.bali.ac/
 / http://niclas.hedhman.org / 
+--//---+

cocoon call back with params to jsp

[Rokibul Islam Khan]

Hi

I am trying to use cocoon extensively for
report publishing. For using cocoon as report publisher I need to call back
from cocoon to my web application (based on struts) with params. When user request for any report i forward the request to cocoon.
The problem is when cocoon call the corresponding jsp ( the
jsp call the business
object for retreving data
and render itself in xml) for retrieving xml from application. In normal case
its working fine. But when I need creiate area based retrieving then
I have to send the parameters to cocoon and cocoon have
to request the xml generator
jsp with those params. Any body have any idea that how can I do that or any alternet idea to do that ?

 

Im using the following
pipeline match pattern for viewing the employee report.

    

    

    

 
  

    map:match>

 

Quick Question regarding cocoon check out directory from svn and java 1.5

[JD Daniels]

I am about to start building a new server for my new cocoon projects. I 
have  a few questions:

1.) I have started using SVN in my own projects and I really like it. 
but I am a little confused about about what version of cocoon supports 
java 1.5, and if that suport is available. Where is the main development 
going on? I see as my choices:

https://svn.apache.org/repos/asf/cocoon/branches/BRANCH_2_1_X
https://svn.apache.org/repos/asf/cocoon/tags/RELEASE_2_1_RC_1
https://svn.apache.org/repos/asf/cocoon/trunk
I was assuming that cocoon/trunk would always be the latest and 
greatest, but I have seen a few messages on this list implying that 
changes are being back ported to the 2.1.X branches . So which 
folder can I choose to just relax in the fact that when i update, I am 
using the latest and greatest? Is a 2.1.6, 2.1.7, etc planned before an 
official 2.2?

I have been using tomcat from day one to host cocoon, but have heard 
many good things about jetty. Would anyone like to voice their opinion 
on the best release of jetty to try out? Or even if I should stick with 
tomcat because of familiarity ( I am planning on upgrading to tomcat 5)

Thanks
JD

Re: Merging CForm's DOMHelper with DOMUtil?

[Vadim Gritsenko]

Bart Molenkamp wrote:
I need to parse XML files to documents.
Why don't you use SourceResolver and SourceUtil?

I found out that CForm's
DomHelper class could be very useful for that, mostly because it records
line and character positions of nodes. Isn't this useful for other
Cocoon parts as well? Thus making this class more globally available in
Cocoon? Or maybe merge it with DOMUtil?
Unfortunately, this works only with Xerces, and it works only with Xerces DOM 
documents, and only when those documents were created by the method in this helper.

Moreover, this helper will fail with ClassCastException if "foreign" DOM is 
passed instead of degrading gracefully. Even worse, it will fail with 
NoClassDefFoundError if Xerces isn't in the classpath.

In short, there is some refactoring required in order to make it possible to 
bring this functionality into the DOMUtil. But, some of the methods could easily 
be moved into the DOMUtil.

This also shows that CForms currently do some unefficient double parsing if 
XMLizable source is passed to it.

This also makes me think; LocationTrackingDOMParser could be an alternative 
implementation of cocoon.xconf's , making location information 
available globally in Cocoon.

Vadim

RE: [RT] Some notes about the "Real Blocks" issue

[Hunsberger, Peter]

Stefano Mazzocchi <[EMAIL PROTECTED]> writes:
> 
> Hunsberger, Peter wrote:
> 
> > Umm, I don't really see a pattern here.  From everything 
> I've seen the 
> > communities involved with Spring and Geronimo have little in common 
> > with the Avalon/Excalibur communities. (Let me qualify that 
> by saying 
> > I haven't looked that closely.) More-over, they both have the 
> > advantage of being able to look at past history and learn from it.
> 
> I need a *record* of stability, the attitude is not enough, I'm sorry.

Fair enough.  How long of record?

> >>History should teach people not to repeat the same mistakes
> >>again... but hey, what do I know, I've only been around here for 7
> > years.
> > 
> > Many people have learned many things both technically and community 
> > wise in the past 7 years. If it is really this bad why aren't we 
> > writing our own XML parsers and XSLT engines?
> 
> Because they have been around forever *AND* they don't change their 
> contracts overnight. Example: xalan2 broke 25% of the gump build last 
> night, it was solved after a few hours.

You'd know better than I, but when Cocoon started using Xalan I don't
think it was around very long or very stable?  The issue here (in Cocoon
land) seems more a bias against containers than any real policy...

> > After all they are as critical to
> > Cocoon as the containers.  Why not take it all the way and 
> write our 
> > own JVM?
> 
> FYI, I spent the last day making sure that gump runs against 
> Kaffe and 
> GNU classpath to see how far away we are in that regard.
 
Cool, from the way you posted that it sounds like the results where
positive ??? (Java 1.5 here we come...)

RE: [RT] Some notes about the "Real Blocks" issue

[Stephen McConnell]

> -Original Message-
> From: Stefano Mazzocchi [mailto:[EMAIL PROTECTED]


> Because they have been around forever *AND* they don't change their
> contracts overnight. 

So who is changing contracts Stefano?  

Re: [RT] Some notes about the "Real Blocks" issue

[Stefano Mazzocchi]

Hunsberger, Peter wrote:
Umm, I don't really see a pattern here.  From everything I've seen the
communities involved with Spring and Geronimo have little in common with
the Avalon/Excalibur communities. (Let me qualify that by saying I
haven't looked that closely.) More-over, they both have the advantage of
being able to look at past history and learn from it.  
I need a *record* of stability, the attitude is not enough, I'm sorry.
History should teach people not to repeat the same mistakes 
again... but hey, what do I know, I've only been around here for 7
years.
Many people have learned many things both technically and community wise
in the past 7 years. If it is really this bad why aren't we writing our
own XML parsers and XSLT engines? 
Because they have been around forever *AND* they don't change their 
contracts overnight. Example: xalan2 broke 25% of the gump build last 
night, it was solved after a few hours.

After all they are as critical to
Cocoon as the containers.  Why not take it all the way and write our own
JVM?
FYI, I spent the last day making sure that gump runs against Kaffe and 
GNU classpath to see how far away we are in that regard.

--
Stefano.


smime.p7s
Description: S/MIME Cryptographic Signature

DO NOT REPLY [Bug 31649] - [Patch] Flowscript: Switch to re-implementation of official Rhino

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=31649

[Patch] Flowscript: Switch to re-implementation of official Rhino





--- Additional Comments From [EMAIL PROTECTED]  2004-10-15 20:48 ---
I added to Rhino in cvs.mozilla.org changes to make it binary and source
compatible with Rhino usage in Cocoon. So now you do not need any patches to run
the calculator example, just replace rhino jar. 

The change also include the compatibility with number usage bug.

Re: [PATCH] wd references

[Vadim Gritsenko]

Jorg Heymans wrote:
minor: you might also want to change "Excepted" to "Expected" in 
DefaultSelectionListBuilder.java.
Thanks
Vadim

Re: [PATCH] wd references

[Jorg Heymans]

minor: you might also want to change "Excepted" to "Expected" in 
DefaultSelectionListBuilder.java.


Vadim Gritsenko wrote:
Jorg Heymans wrote:
The defaultselectionlistbuilder was still expecting wd: (woody?) 
elements.

Doing a grep in src/blocks/forms/java/org/apache/cocoon/forms reveals 
a few more of these, summarized below. I can provide a patch for these 
as well if wanted :=)

./datatype/DefaultSelectionListBuilder.java 
./datatype/DynamicSelectionList.java
./datatype/EnumSelectionList.java 
./datatype/FlowJXPathSelectionListBuilder.java
./formmodel/Field.java
./formmodel/MultiValueField.java 
./formmodel/RepeaterActionDefinitionBuilder.java
./formmodel/SubmitDefinitionBuilder.java

Fixed wd, wi references which I found in the files.
Vadim

RE: [RT] Some notes about the "Real Blocks" issue

[Hunsberger, Peter]

Stefano Mazzocchi <[EMAIL PROTECTED]> writes:

> Hunsberger, Peter wrote:
> 
>  > Maybe I'm
> > just too optimistic in believing there should be container 
> > implementations mature enough for Cocoon to depend on?
> 
> What *really* bothers me about this thread is the fact that very few 
> seem to realize that "maturity" for dependencies means 
> "stability of the 
> contract and stability of the community".
> 
> Avalon is dead.
> 
> Excalibur is asleep.
> 
> Spring is outside the ASF.
> 
> Geronimo is still incubating.
> 
> Can you see the pattern?

Umm, I don't really see a pattern here.  From everything I've seen the
communities involved with Spring and Geronimo have little in common with
the Avalon/Excalibur communities. (Let me qualify that by saying I
haven't looked that closely.) More-over, they both have the advantage of
being able to look at past history and learn from it.  

> History should teach people not to repeat the same mistakes 
> again... but hey, what do I know, I've only been around here for 7
years.

Many people have learned many things both technically and community wise
in the past 7 years. If it is really this bad why aren't we writing our
own XML parsers and XSLT engines?  After all they are as critical to
Cocoon as the containers.  Why not take it all the way and write our own
JVM?

Re: [PATCH] wd references

[Vadim Gritsenko]

Jorg Heymans wrote:
The defaultselectionlistbuilder was still expecting wd: (woody?) elements.
Doing a grep in src/blocks/forms/java/org/apache/cocoon/forms reveals a 
few more of these, summarized below. I can provide a patch for these as 
well if wanted :=)

./datatype/DefaultSelectionListBuilder.java 
./datatype/DynamicSelectionList.java
./datatype/EnumSelectionList.java 
./datatype/FlowJXPathSelectionListBuilder.java
./formmodel/Field.java
./formmodel/MultiValueField.java 
./formmodel/RepeaterActionDefinitionBuilder.java
./formmodel/SubmitDefinitionBuilder.java
Fixed wd, wi references which I found in the files.
Vadim

Re: [RT] Some notes about the "Real Blocks" issue

[Ugo Cei]

Il giorno 15/ott/04, alle 20:18, Vadim Gritsenko ha scritto:
Ugo Cei wrote:
Il giorno 15/ott/04, alle 13:01, Vadim Gritsenko ha scritto:
The best plan IMHO would be:
1. Remove ECM - implementation of Avalon container. Keep re-usable 
components code (XSLT, Source, Store, etc).
2. Drop in the container which replaces it.
3. Write bridge code between container in (2) and (1).
4. Test.
5. Release Cocoon 2.3.
6. Continue with usual Cocoon development: improvements, 
refactorings, as you see fit: rewrite source resolving or sitemap 
processor or whatever you want if you have time for it.

For a useful example of 6, Store implementation should plug in into 
Java 1.5 management API instead of having background checker thread.
Looks like a very good plan to me.
Do you have suggestions for (3)? Particularly, how AvalonBeanFactory 
should be implemented, and what should be the basis for 
ComponentSelectors?
Er, no. Actually what I proposed was to keep the two containers (ECM 
and the new one) separate, instead of emulating or wrapping the former 
inside the latter.

Ugo
--
Ugo Cei - http://beblogging.com/


smime.p7s
Description: S/MIME cryptographic signature

Re: [RT] Some notes about the "Real Blocks" issue

[Stefano Mazzocchi]

Hunsberger, Peter wrote:
> Maybe I'm
just too optimistic in believing there should be container
implementations mature enough for Cocoon to depend on?
What *really* bothers me about this thread is the fact that very few 
seem to realize that "maturity" for dependencies means "stability of the 
contract and stability of the community".

Avalon is dead.
Excalibur is asleep.
Spring is outside the ASF.
Geronimo is still incubating.
Can you see the pattern?
History should teach people not to repeat the same mistakes again... but 
hey, what do I know, I've only been around here for 7 years.

--
Stefano.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: GT2004 was brilliant

[Stefano Mazzocchi]

Ugo Cei wrote:
Il giorno 15/ott/04, alle 12:04, Gianugo Rabellino ha scritto:
Any chance you can "just" iDVD it for now with just separate chapters
per session? I know this would mean a hefty download, but isn't this
why bittorrent is there? Others then might jump in and postproduce the
sessions. But I would certainly like having DVD quality video for the
GT.
I would certainly like this better that last year's videos, whose 
quality was certainly not optimal for, say, projecting them on a large 
screen to your office colleagues (this is not to blame Stefano, who 
probably did the best possible job, given the desired compression levels).

I am just wondering: will we be able to fit everything in a single DVD?
forget it. Last year I had 4 DV tapes for a total of 40Gb. Cut here and 
there and you get 30Gb, reduce quality and framerate by two and you 
might get to 10Gb, but not sure about how presentable it would be.

--
Stefano.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: jxtemplate output garbles markup

[Jorg Heymans]

Vadim Gritsenko wrote:
Historically, it works same way everywhere in Cocoon. If you remember 
XSP, you understand what I mean :)
never used XSP, and proud of it ;-)
I guess this behaviour causes user confusion because comparing with 
plain JSP, PHP, ASP, etc, Cocoon is (so to speak) "strongly typed": 
String is *always* a String, even if it looks like XML snippet :) To 
make it real XML, you have to parse it.
ok, another lesson learned - thanks.
Vadim
Jorg

Re: Daisy as CMS: why don't use JDO?

[JD Daniels]

Luca Garulli wrote:
By some responses in this thread I understand that they don't know JDO.
bye,
Luca Garulli
OrienTechnologies.com
(the light ODBMS, all in one JDO solution)
 

This is the most unproductive thread I have ever seen on this list. I 
had to choose between an O/R mapping tool a while ago, and I made the 
decision based on discussions that took place on this list. Thank 
goodness this crap wasn't cluttering it up at the time.

Luca, do the same thing others did... when i had to choose, I downloaded 
a hibernate sample, and an ojb sample from the wiki. If you think JDO is 
the best thing since sliced bread, build something simple that uses it, 
and provide a sample with good comments. If  it is solid and useable, 
and you demonstrate that, people will use it. Nobody is going to use 
anything because someone flailed their arms, called them uneducated 
(don't tell us what we don't know) and say my way is better. Pay 
attention to your medium. cocoon doesn't provide O/R mapping. If you had 
posted "Hey I made a patch for this cocoon sample that uses JDO and I 
have all the good points highlighted", I would have gone and taken a 
look and maybe took some time to consider that solution for future 
projects. You current post however, elicted no more than a grumble and 
press of the delete button.

I have always considered this list to be mature, stable, and a great 
fountain of learning material. I hate seeing crap like this use up the 
bandwidth.

Please let it rest and stop insulting people.
JD

Re: jxtemplate output garbles markup

[Vadim Gritsenko]

Jorg Heymans wrote:

Vadim Gritsenko wrote:
Jorg Heymans wrote:
Hi,
This has come up a few times before without solution.
 produces "" if data 
contains "".
Using {$mybean.data} yields the same results.

Is there a way around this?

It seems to be correct behavior - as long as "mybean.data" is a String 
object. Now, it would be wrong if "data" is instane of XMLizable, or 
XMLFragment, or DOM Node.

fair enough, is this because one could produce invalid xml data otherwise?
Historically, it works same way everywhere in Cocoon. If you remember XSP, you 
understand what I mean :)

I guess this behaviour causes user confusion because comparing with plain JSP, 
PHP, ASP, etc, Cocoon is (so to speak) "strongly typed": String is *always* a 
String, even if it looks like XML snippet :) To make it real XML, you have to 
parse it.

Vadim

RE: [RT] Some notes about the "Real Blocks" issue

[Garry Munro]

>>ho ho ho


Sorry,
replied to the wrong email
Doh !!!
G

-Original Message-
From: Garry Munro 
Sent: 15 October 2004 13:30
To: '[EMAIL PROTECTED]'
Subject: RE: [RT] Some notes about the "Real Blocks" issue



-Original Message-
From: Ugo Cei [mailto:[EMAIL PROTECTED]
Sent: 15 October 2004 13:19
To: [EMAIL PROTECTED]
Subject: Re: [RT] Some notes about the "Real Blocks" issue


Il giorno 15/ott/04, alle 13:01, Vadim Gritsenko ha scritto:

> The best plan IMHO would be:
>
> 1. Remove ECM - implementation of Avalon container. Keep re-usable 
> components code (XSLT, Source, Store, etc).
> 2. Drop in the container which replaces it.
> 3. Write bridge code between container in (2) and (1).
> 4. Test.
> 5. Release Cocoon 2.3.
> 6. Continue with usual Cocoon development: improvements, refactorings,

> as you see fit: rewrite source resolving or sitemap processor or 
> whatever you want if you have time for it.
>
> For a useful example of 6, Store implementation should plug in into 
> Java 1.5 management API instead of having background checker thread.


Looks like a very good plan to me.

Ugo

-- 
Ugo Cei - http://beblogging.com/

This electronic message contains information which may be privileged and confidential. 
The information is intended to be for the use of the individual(s) or entity named 
above. If you are not the intended recipient, be aware that any disclosure, copying, 
distribution or use of the contents of this information is prohibited. If you have 
received this electronic message in error, please notify us by telephone on 0131 476 
6000 and delete the material from your computer.

DO NOT REPLY [Bug 31649] - [Patch] Flowscript: Switch to re-implementation of official Rhino

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=31649

[Patch] Flowscript: Switch to re-implementation of official Rhino





--- Additional Comments From [EMAIL PROTECTED]  2004-10-15 19:00 ---
Reinhard Poetz wrote:

> So far, I found two problems:
> 
> 1.) samples/blocks/forms/form1.flow
> seems to be a problem with type recognition

This is a bug in Rhino bindings in Cocoon and caused by the following code in
ScriptableWidget.put:

...
value = unwrap(value);
if (value instanceof Double) {
// make woody accept a JS Number

The problem here is that the code assumes that numbers in Rhino are represented
by Double. But this is wrong and was wrong from the first public release of
Rhino in 1998 as to check for numbers java applications should always check for
Number, not Double. 

Since it is possible to modify the the JavaScript source in the example so the
number would be Integer even with Chris' version of Rhino that has to be fixed
in any case in all instances of this duplicated code in Cocoon.

> 
> 2.) samples/blocks/forms/carselector
> Seems to be a problem of event handling in Cocoon Forms which uses Rhino (but
> creating continuations is not allowed in form events)

I fixed that compatibility issue in Rhino CVS and that should work now.

Re: jxtemplate output garbles markup

[Jorg Heymans]

Vadim Gritsenko wrote:
Jorg Heymans wrote:
Hi,
This has come up a few times before without solution.
 produces "" if data 
contains "".
Using {$mybean.data} yields the same results.

Is there a way around this?

It seems to be correct behavior - as long as "mybean.data" is a String 
object. Now, it would be wrong if "data" is instane of XMLizable, or 
XMLFragment, or DOM Node.
fair enough, is this because one could produce invalid xml data otherwise?
Jorg

Re: jxtemplate output garbles markup

[Vadim Gritsenko]

Jorg Heymans wrote:
Hi,
This has come up a few times before without solution.
 produces "" if data 
contains "".
Using {$mybean.data} yields the same results.

Is there a way around this?
It seems to be correct behavior - as long as "mybean.data" is a String object. 
Now, it would be wrong if "data" is instane of XMLizable, or XMLFragment, or DOM 
Node.

Vadim

Re: [RT] Some notes about the "Real Blocks" issue

[Vadim Gritsenko]

Ugo Cei wrote:
Il giorno 15/ott/04, alle 13:01, Vadim Gritsenko ha scritto:
The best plan IMHO would be:
1. Remove ECM - implementation of Avalon container. Keep re-usable 
components code (XSLT, Source, Store, etc).
2. Drop in the container which replaces it.
3. Write bridge code between container in (2) and (1).
4. Test.
5. Release Cocoon 2.3.
6. Continue with usual Cocoon development: improvements, refactorings, 
as you see fit: rewrite source resolving or sitemap processor or 
whatever you want if you have time for it.

For a useful example of 6, Store implementation should plug in into 
Java 1.5 management API instead of having background checker thread.

Looks like a very good plan to me.
Do you have suggestions for (3)? Particularly, how AvalonBeanFactory should be 
implemented, and what should be the basis for ComponentSelectors?

Vadim

DO NOT REPLY [Bug 31649] - [Patch] Flowscript: Switch to re-implementation of official Rhino

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=31649

[Patch] Flowscript: Switch to re-implementation of official Rhino





--- Additional Comments From [EMAIL PROTECTED]  2004-10-15 17:46 ---
So far, I found two problems:

1.) samples/blocks/forms/form1.flow
seems to be a problem with type recognition

java.lang.RuntimeException: Incorrect value type for "account" (expected class
java.lang.Long, got class java.lang.Integer.
at org.apache.cocoon.forms.formmodel.Field.setValue(Field.java:132)
at
org.apache.cocoon.forms.flow.javascript.ScriptableWidget.put(ScriptableWidget.java:211)
at 
org.mozilla.javascript.ScriptableObject.putProperty(ScriptableObject.java:1348)
at org.mozilla.javascript.ScriptRuntime.setObjectProp(ScriptRuntime.java:1439)
at org.mozilla.javascript.ScriptRuntime.setObjectProp(ScriptRuntime.java:1429)
at org.mozilla.javascript.Interpreter.interpret(Interpreter.java:2752)
at org.mozilla.javascript.Interpreter.interpret(Interpreter.java:2163)
at 
org.mozilla.javascript.InterpretedFunction.call(InterpretedFunction.java:140)
at org.mozilla.javascript.ScriptRuntime.applyOrCall(ScriptRuntime.java:2171)
at org.mozilla.javascript.BaseFunction.execIdCall(BaseFunction.java:254)
at org.mozilla.javascript.IdFunctionObject.call(IdFunctionObject.java:121)
at org.mozilla.javascript.Interpreter.interpret(Interpreter.java:3025)
at org.mozilla.javascript.Interpreter.interpret(Interpreter.java:2163)
at 
org.mozilla.javascript.InterpretedFunction.call(InterpretedFunction.java:140)
at org.mozilla.javascript.ContextFactory.doTopCall(ContextFactory.java:301)
...

2.) samples/blocks/forms/carselector
Seems to be a problem of event handling in Cocoon Forms which uses Rhino (but
creating continuations is not allowed in form events)

org.mozilla.javascript.WrappedException: Wrapped
java.lang.IllegalStateException: Context.enter can not be used to recursively
enter Context instances already associated with the current thread using
Context.call(ContextAction)
(resource://org/apache/cocoon/forms/flow/javascript/Form.js#127)
at org.mozilla.javascript.Context.throwAsScriptRuntimeEx(Context.java:1763)
at org.mozilla.javascript.MemberBox.invoke(MemberBox.java:191)
at org.mozilla.javascript.NativeJavaMethod.call(NativeJavaMethod.java:197)
at org.mozilla.javascript.Interpreter.interpret(Interpreter.java:3025)
at org.mozilla.javascript.Interpreter.interpret(Interpreter.java:2163)
at 
org.mozilla.javascript.InterpretedFunction.call(InterpretedFunction.java:140)
at org.mozilla.javascript.ContextFactory.doTopCall(ContextFactory.java:301)
at org.mozilla.javascript.ScriptRuntime.doTopCall(ScriptRuntime.java:2778)
at org.mozilla.javascript.Interpreter.interpret(Interpreter.java:2144)
at 
org.mozilla.javascript.InterpretedFunction.call(InterpretedFunction.java:140)
at org.mozilla.javascript.Context.call(Context.java:484)
at 
org.mozilla.javascript.ScriptableObject.callMethod(ScriptableObject.java:1496)
at 
org.mozilla.javascript.ScriptableObject.callMethod(ScriptableObject.java:1467)
at
org.apache.cocoon.components.flow.javascript.fom.FOM_JavaScriptInterpreter.handleContinuation(FOM_JavaScriptInterpreter.java:785)
at
org.apache.cocoon.components.treeprocessor.sitemap.CallFunctionNode.invoke(CallFunctionNode.java:120)

jxtemplate output garbles markup

[Jorg Heymans]

Hi,
This has come up a few times before without solution.
 produces "" if data 
contains "".
Using {$mybean.data} yields the same results.

Is there a way around this?
Regards
Jorg

Re: [RT] Some notes about the "Real Blocks" issue

[Reinhard Poetz]

Pier Fumagalli wrote:
On 14 Oct 2004, at 16:18, Stefano Mazzocchi wrote:
Ugo Cei wrote:
Il giorno 14/ott/04, alle 16:50, Stefano Mazzocchi ha scritto:
real block kernel and Rickard Oberg's AOP framework, this would be 
modern.
Too bad he has not open-sourced it yet, or has he?

No, and he will not.
But the ideas are available and implementation doesn't scare me.
My point remains: we've been burned too much before already in 
depending on frameworks we don't control.

I still think it would be better to write our own entirely from scratch.
Want to use ideas for Spring? sure, bring them on, but depending on it 
is asking for trouble.

100% agreed! :-P
Pier
Agree too!
--
Reinhard

Re: Integrating rhino-1.6pre

[Reinhard Poetz]

Vadim Gritsenko wrote:
Antonio Gallardo wrote:
Vadim Gritsenko dijo:
Reinhard Poetz wrote:
And one last question: Does this have any legal implications
(licencing)?

As long as you do your contributions under MPL, which means you keep
cocoondev
rhino licensed as MPL, I see no issues at all.

I have a question: Under a MPL project: Is the committer able to choose
whatever type of license he wants for his code?

No. License clearly ;-) says:
 3.1. Application of License.
 The Modifications which You create or to which You contribute are
 governed by the terms of this License, including without limitation
 Section 2.2. The Source Code version of Covered Code may be
 distributed only under the terms of this License or a future version
 of this License released under Section 6.1, and You must include a
 copy of this License with every copy of the Source Code You
 distribute.
Which means, all modifications you do to MPL code base has to be 
released under MPL. You can also see definition of Modification which 
basically says that Modification is changes to existing files or new 
file with some MPL code pasted into it. But if you add BRAND NEW file 
containing no MPL code whatsoever, you can do with them whatever you 
want (IIUC).

Vadim
Thanks!
The remaining question is: What is the target namespace fore 
rhino-1.4pre-continuations?

Steven, is moving to org.cocoondev an option, or do we have other alternatives?
--
Reinhard

Re: Integrating rhino-1.6pre

[Reinhard Poetz]

Antonio Gallardo wrote:
+1.
Thanks again for this nice work!
Thanks, but the difficult part has been done by Igor!
--
Reinhard

Re: Flowscript bug???

[Vadim Gritsenko]

Claudius Spellmann wrote:
Hi,
I was just woudering wether this is a bug or not:
When I try to access a value object returned by an EJB I always get a 
java.io.NotSerializableException thrown by the value object .
...
java.io.NotSerializableException: 
org.apache.cocoon.components.flow.javascript.fom.CompilingClassLoader
...
   at 
org.apache.cocoon.environment.http.HttpSession.getAttribute(HttpSession.java:172) 
   at 
org.apache.cocoon.components.flow.javascript.fom.FOM_JavaScriptInterpreter.getSessionScope(FOM_JavaScriptInterpreter.java:350) 
This has nothing to do with EJB.
Problem is that currently Flow session scope is not serializable. WebLogic 
requires session attributes to be serializable (required for clustering).

Vadim

Re: Possible security problem with flowscript

[Leszek Gawron]

Niklas Eklund wrote:
Rob Berens wrote:
Carsten Ziegeler wrote:
Hmm, I might be wrong, but does this really protect you?
If you have a flow that is usable by not authenticated users,
you run into the same problem I think.
I see, you are right. A unauthorized user can get access to the 
continuation
by adding the continuation parameter to another request he is authorized
for.

I have solved a similar problem in an application by using a wrapped 
sendPage() like:

function w_sendPage(x, y, z) {
  var currentUser = getCurrUser(); // userPrincipal/remoteUser/whatever
  sendPage(x, y, z);
  if (currentUser != getCurrUser()) {
 throw "Bad boy!";
  }
}
It's nice but does not work for cforms.
--
Leszek Gawron  [EMAIL PROTECTED]
Project ManagerMobileBox sp. z o.o.
+48 (61) 855 06 67  http://www.mobilebox.pl
mobile: +48 (501) 720 812   fax: +48 (61) 853 29 65

Re: Possible security problem with flowscript

[Niklas Eklund]

Rob Berens wrote:
Carsten Ziegeler wrote:
Hmm, I might be wrong, but does this really protect you?
If you have a flow that is usable by not authenticated users,
you run into the same problem I think.
I see, you are right. A unauthorized user can get access to the continuation
by adding the continuation parameter to another request he is authorized
for.
I have solved a similar problem in an application by using a wrapped 
sendPage() like:

function w_sendPage(x, y, z) {
  var currentUser = getCurrUser(); // userPrincipal/remoteUser/whatever
  sendPage(x, y, z);
  if (currentUser != getCurrUser()) {
 throw "Bad boy!";
  }
}
Although not perfect, in that application, where authorization is 
mandatory, it stops users from giving/emailing each other links to stuff 
which as you can imagine can cause some problems. This is the poor man's 
version of Vadim's proposed pre-function-call and 
pre-handle-continuation hooks.
This won't stop unauthorized users from "stealing" other unauthorized 
continuations though... but it will stop unauthorized users from using 
authorized continuations.

 Regards,
   Niklas

Flowscript bug???

[Claudius Spellmann]

Hi,
I was just woudering wether this is a bug or not:
When I try to access a value object returned by an EJB I always get a 
java.io.NotSerializableException thrown by the value object .
The problem is always reproduceable and is only occuring when an ejb is 
returning a valueobject everything is working fine with primitive 
datatypes and Strings.
We're using cocoon 2.2.0-dev on bea6.1 .

Stacktrace:
<15.10.2004 17:26:57 CEST>   
java.io.NotSerializableException: 
org.apache.cocoon.components.flow.javascript.fom.CompilingClassLoader
   at java.io.ObjectOutputStream.outputObject(ObjectOutputStream.java:1143)
   at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:361)
   at 
java.io.ObjectOutputStream.outputClassFields(ObjectOutputStream.java:1822)
   at 
java.io.ObjectOutputStream.defaultWriteObject(ObjectOutputStream.java:475)
   at java.io.ObjectOutputStream.outputObject(ObjectOutputStream.java:1209)
   at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:361)
   at 
java.io.ObjectOutputStream.outputClassFields(ObjectOutputStream.java:1822)
   at 
java.io.ObjectOutputStream.defaultWriteObject(ObjectOutputStream.java:475)
   at java.io.ObjectOutputStream.outputObject(ObjectOutputStream.java:1209)
   at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:361)
   at java.io.ObjectOutputStream.outputArray(ObjectOutputStream.java:1093)
   at 
java.io.ObjectOutputStream.checkSubstitutableSpecialClasses(ObjectOutputStream.java:451)
   at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:356)
   at 
java.io.ObjectOutputStream.outputClassFields(ObjectOutputStream.java:1822)
   at 
java.io.ObjectOutputStream.defaultWriteObject(ObjectOutputStream.java:475)
   at java.io.ObjectOutputStream.outputObject(ObjectOutputStream.java:1209)
   at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:361)
   at 
java.io.ObjectOutputStream.outputClassFields(ObjectOutputStream.java:1822)
   at 
java.io.ObjectOutputStream.defaultWriteObject(ObjectOutputStream.java:475)
   at java.io.ObjectOutputStream.outputObject(ObjectOutputStream.java:1209)
   at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:361)
   at java.io.ObjectOutputStream.outputArray(ObjectOutputStream.java:1093)
   at 
java.io.ObjectOutputStream.checkSubstitutableSpecialClasses(ObjectOutputStream.java:451)
   at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:356)
   at 
java.io.ObjectOutputStream.outputClassFields(ObjectOutputStream.java:1822)
   at 
java.io.ObjectOutputStream.defaultWriteObject(ObjectOutputStream.java:475)
   at java.io.ObjectOutputStream.outputObject(ObjectOutputStream.java:1209)
   at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:361)
   at 
java.io.ObjectOutputStream.outputClassFields(ObjectOutputStream.java:1822)
   at 
java.io.ObjectOutputStream.defaultWriteObject(ObjectOutputStream.java:475)
   at java.io.ObjectOutputStream.outputObject(ObjectOutputStream.java:1209)
   at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:361)
   at java.io.ObjectOutputStream.outputArray(ObjectOutputStream.java:1093)
   at 
java.io.ObjectOutputStream.checkSubstitutableSpecialClasses(ObjectOutputStream.java:451)
   at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:356)
   at 
java.io.ObjectOutputStream.outputClassFields(ObjectOutputStream.java:1822)
   at 
java.io.ObjectOutputStream.defaultWriteObject(ObjectOutputStream.java:475)
   at java.io.ObjectOutputStream.outputObject(ObjectOutputStream.java:1209)
   at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:361)
   at 
java.io.ObjectOutputStream.outputClassFields(ObjectOutputStream.java:1822)
   at 
java.io.ObjectOutputStream.defaultWriteObject(ObjectOutputStream.java:475)
   at java.io.ObjectOutputStream.outputObject(ObjectOutputStream.java:1209)
   at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:361)
   at java.io.ObjectOutputStream.outputArray(ObjectOutputStream.java:1093)
   at 
java.io.ObjectOutputStream.checkSubstitutableSpecialClasses(ObjectOutputStream.java:451)
   at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:356)
   at 
java.io.ObjectOutputStream.outputClassFields(ObjectOutputStream.java:1822)
   at 
java.io.ObjectOutputStream.defaultWriteObject(ObjectOutputStream.java:475)
   at java.io.ObjectOutputStream.outputObject(ObjectOutputStream.java:1209)
   at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:361)
   at 
java.io.ObjectOutputStream.outputClassFields(ObjectOutputStream.java:1822)
   at 
java.io.ObjectOutputStream.defaultWriteObject(ObjectOutputStream.java:475)
   at java.io.ObjectOutputStream.outputObject(ObjectOutputStream.java:1209)
   at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:361)
   at java.io.ObjectOutputStream.outputArray(ObjectOutputStream.java:1093)
   at 
java.io.ObjectOutputStream.checkSubstitutableSpecialClasses(ObjectOutputStream.java:451)
   at java.io.Objec

Re: [RT] Some notes about the "Real Blocks" issue

[Pier Fumagalli]

On 14 Oct 2004, at 16:18, Stefano Mazzocchi wrote:
Ugo Cei wrote:
Il giorno 14/ott/04, alle 16:50, Stefano Mazzocchi ha scritto:
real block kernel and Rickard Oberg's AOP framework, this would be 
modern.
Too bad he has not open-sourced it yet, or has he?
No, and he will not.
But the ideas are available and implementation doesn't scare me.
My point remains: we've been burned too much before already in 
depending on frameworks we don't control.

I still think it would be better to write our own entirely from 
scratch.

Want to use ideas for Spring? sure, bring them on, but depending on it 
is asking for trouble.

100% agreed! :-P
Pier


smime.p7s
Description: S/MIME cryptographic signature

Re: Sales Materials

[Tony Collen]

Bertrand Delacretaz wrote:
Le 15 oct. 04, à 00:03, Upayavira a écrit :
...I saw Gianugo's presentation - only wish I could get hold of the 
video right now. Need more of that kinda thing...

Maybe starting a "success stories" page on the wiki and priming it with 
the contents of the GT success stories prez would be good?
Sounds like http://wiki.apache.org/cocoon/Testimonials would be the 
perfect page to extend.

Tony

Re: Invalid content length, revisited

[Unico Hommes]

Vadim Gritsenko wrote:
Unico Hommes wrote:
Vadim Gritsenko wrote:
Unico Hommes wrote:
Vadim Gritsenko wrote:
Unico Hommes wrote:
Oh I see now. The ResourceReader also sets the content length on 
the response. It *really* shouldn't do that IMHO. Anybody know 
why it does that?



I see that EnvironmentWrapper ignores set content length. And it 
has RequestWrapper. BUT IT DOES NOT HAVE ResponseWrapper! I guess 
that's the real problem.

ResourceReader probably should be changed to set content length on 
the environment, but this is fix in only one case. ResponseWrapper 
seems to be the fix for all cases at once. Or, am I missing 
something?

What about FOM though? Doesn't a flowscript run within an 
EnvironmentWrapper? If so, having WrapperResponse ignore calls to 
setHeader() and related methods would be undesirable.


Shouldn't it / could it run under MutableEnvironmentFacade?
I think that in the following scenario there will be an 
EnvironmentWrapper in there somewhere:

sitemap


 
 


 


 
 

flowscript
--
function foo() {
 cocoon.response.setHeader("foo", "bar");
 cocoon.sendPage("bar");
}
Because function foo() is called via a SitemapSource its environment 
is a WrappedEnvironment  (don't know, but I am guessing) and the call 
to setHeader will be to WrappedResponse?

But that is good! foo should *not* set content length in this scenario 
- you have further processing to do on the SAX events (in this case -- 
default serializer) - and content length *will* be different after 
pipeline is complete.

I tried to find an example of a http/1.1 header that does not depend on 
the top level processing environment but didn't find one. So I guess you 
are right that it is a good thing foo() cannot set headers. OK, I guess 
we should implement the WrappedResponse solution then. Any other opinions?

--
Unico

DO NOT REPLY [Bug 31676] - [PATCH] HolderAwareContinuationsManagerImpl

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=31676

[PATCH] HolderAwareContinuationsManagerImpl





--- Additional Comments From [EMAIL PROTECTED]  2004-10-15 14:31 ---
For paranoid users (some of our clients can be described like that) it would be
useful to restrict continuations to session only (if I or somebody on the team
else messed something up with caching headers - It turns out I do it wrong right
now). User might have not logged out so the session is still valid. This would
allow someone to run page from cache without knowing the session cookie and
still be able to access the application. Paranoid as I've written.

But if we are to implement map of continuation IDs we've made a full turn and
we're back with WebContinuationsHolder :)
What now ?

Re: Invalid content length, revisited

[Vadim Gritsenko]

Unico Hommes wrote:
Vadim Gritsenko wrote:
Unico Hommes wrote:
Vadim Gritsenko wrote:
Unico Hommes wrote:
Oh I see now. The ResourceReader also sets the content length on 
the response. It *really* shouldn't do that IMHO. Anybody know why 
it does that?


I see that EnvironmentWrapper ignores set content length. And it has 
RequestWrapper. BUT IT DOES NOT HAVE ResponseWrapper! I guess that's 
the real problem.

ResourceReader probably should be changed to set content length on 
the environment, but this is fix in only one case. ResponseWrapper 
seems to be the fix for all cases at once. Or, am I missing something?

What about FOM though? Doesn't a flowscript run within an 
EnvironmentWrapper? If so, having WrapperResponse ignore calls to 
setHeader() and related methods would be undesirable.

Shouldn't it / could it run under MutableEnvironmentFacade?
I think that in the following scenario there will be an 
EnvironmentWrapper in there somewhere:

sitemap


 
 


 


 
 

flowscript
--
function foo() {
 cocoon.response.setHeader("foo", "bar");
 cocoon.sendPage("bar");
}
Because function foo() is called via a SitemapSource its environment is 
a WrappedEnvironment  (don't know, but I am guessing) and the call to 
setHeader will be to WrappedResponse?
But that is good! foo should *not* set content length in this scenario - you 
have further processing to do on the SAX events (in this case -- default 
serializer) - and content length *will* be different after pipeline is complete.

Vadim

Re: Integrating rhino-1.6pre

[Antonio Gallardo]

Hi:

Now realized Reinhard expect opinions from our side in this issue. So see
below: ;-)


Sylvain Wallez dijo:
> Bertrand Delacretaz wrote:
>
>> Le 15 oct. 04, à 08:50, Reinhard Poetz a écrit :
>>
>>> Igor kindly provided a new patch for Cocoon 2.1.5.1 which works now
>>> for me! Before I can apply the patch I want to propose to change the
>>> package names in Rhino (thanks Igor for the idea). This way we can
>>> have both implementations of rhino in parallel in Cocoon and our
>>> users can switch whenever they are ready to do it.
>>
>>
>> +1, many thanks for your work up to know (I even heard you did some of
>> it while listening to the GT presentations ;-)
>
>
> +1

+1!
>
>>> ...What do you prefer? Moving to SVN before (of course, only if
>>> somebody does the migration) or simply creating a CVS branch and then
>>> move on with the new package names
>>
>>
>> I think a CVS branch is good enough, as the aim is to replace the
>> current Rhino stuff soon anyway.
>
>
> +1 also.

+1.

Thanks again for this nice work!

Best Regards,

Antonio Gallardo

RE: [RT] Some notes about the "Real Blocks" issue

[Hunsberger, Peter]

Ugo Cei <[EMAIL PROTECTED]> writes:

> 
> Il giorno 13/ott/04, alle 18:59, Ugo Cei ha scritto:
> 
> > - [ ] Geronimo/JMX?
> >   This thread:
> >
> > http://thread.gmane.org/gmane.comp.java.springframework.devel/4910
> >   might provide some suggestions re the
> >   implementation of the kernel.
> 
> I just came upon this interview with Aslak Hellesoy on The 
> Server Side  
>  textFull.html>. It was published a few days ago but I hadn't seen it  
> yet. I'll paste a brief quote:
> 
> "[The Geronimo developers] have been thinking about this 
> since they've  
> been writing the thing, that if you think about Geronimo as 
> the outer  
> container, if you think of it as a bucket. They have a lot of 
> goodies  
> in that bucket, like connection pooling, transaction management,  
> integration with messaging systems and all that. And if you think of  
> that bucket in a classical J2EE container, in order to benefit from  
> these things, you have to stick in something that looks like a J2EE  
> component.
> 
> What they are actually doing is, they are sticking a smaller bucket  
> inside that, that sort of acts as a glue between Pico and 
> Geronimo. So  
> let us say I am writing this component that needs, for example, a  
> connection pool. Now what I can do, I can write my class and I could  
> say in constructor, I could say I want a connection pool. I 
> can drop it  
> inside Pico, which is inside Geronimo now, and Geronimo will give it  
> the connection pool, so it is simple."
> 
> I find this is very similar to what we're trying to do with the new  
> kernel. And it works with Spring as well as with Pico.
> 
> Now the question is: can a Cocoon block be a GBean? And if it can,  
> should we either:
> 
> 1. Borrow some ideas from Geronimo and do our own thing?
> 2. Borrow some code from Geronimo and adapt it to our needs?
> 3. Build a "lightweight" version of Geronimo (no J2EE stuff, just  
> servlets) to use as our kernel?
> 4. None of the above?

Not sure of the answer to you question, but it seems to me that if
someone wants J2EE capabilities then they should just be running inside
a J2EE container.  

What would be interesting is if there was a way Cocoon to adopt to any
form of external container.  For Jboss you've got Mbeans and Geronimo
you've got Gbeans.  Basically, you'd need an container adaptor for each
container. Presumably, then you could build a version of CLI that worked
the same way. At that point, some of the issues discussed in this thread
could become external concerns: if you want hot deployment you'd have to
be using an external container that supported such and had a mechanism
for signaling back to Cocoon (Eg, Jboss and Mbeans, if not others) when
a related component was deployed.

Doing this for multiple external containers is probably way too much
generalization for the real needs of Cocoon, but as has been pointed out
before, everyone everywhere is attacking portions of this problem and
inventing a Cocoon only solution seems a bit counter productive.  The
lessons of Avalon shouldn't be forgotten, but the communities building
containers have matured a lot in the last couple of years.  Maybe I'm
just too optimistic in believing there should be container
implementations mature enough for Cocoon to depend on?

Re: Possible security problem with flowscript

[Rob Berens]

Carsten Ziegeler wrote:

> Rob Berens wrote:
>
> > We identified this problem already and decided to solve it by
> > having a different way of making the continuation request. In
> > our case we use the original request with a request paremater e.g
> >
> > Original request:
> > mywebapp/original.html
> >
> > Continuation request:
> > mywebapp/original.html?continuation=123456
> >
> > The sitemap does auhorization based on the request without
> > taken into consideration a possible continuation parameter
> > and therefore both the original request and the continuation
> > request are checked in the same way. After the authorization
> > has taken place the continuation is detected by:
> >
> > 
> >   
> > 
> >
> Hmm, I might be wrong, but does this really protect you?
> If you have a flow that is usable by not authenticated users,
> you run into the same problem I think.
>
I see, you are right. A unauthorized user can get access to the continuation
by adding the continuation parameter to another request he is authorized
for.

Rob

Re: Invalid content length, revisited

[Unico Hommes]

Vadim Gritsenko wrote:
Unico Hommes wrote:
Vadim Gritsenko wrote:
Unico Hommes wrote:
Oh I see now. The ResourceReader also sets the content length on 
the response. It *really* shouldn't do that IMHO. Anybody know why 
it does that?


I see that EnvironmentWrapper ignores set content length. And it has 
RequestWrapper. BUT IT DOES NOT HAVE ResponseWrapper! I guess that's 
the real problem.

ResourceReader probably should be changed to set content length on 
the environment, but this is fix in only one case. ResponseWrapper 
seems to be the fix for all cases at once. Or, am I missing something?

What about FOM though? Doesn't a flowscript run within an 
EnvironmentWrapper? If so, having WrapperResponse ignore calls to 
setHeader() and related methods would be undesirable.

Shouldn't it / could it run under MutableEnvironmentFacade?
I think that in the following scenario there will be an 
EnvironmentWrapper in there somewhere:

sitemap


 
 


 


 
 

flowscript
--
function foo() {
 cocoon.response.setHeader("foo", "bar");
 cocoon.sendPage("bar");
}
Because function foo() is called via a SitemapSource its environment is 
a WrappedEnvironment  (don't know, but I am guessing) and the call to 
setHeader will be to WrappedResponse?

--
Unico

DO NOT REPLY [Bug 31676] - [PATCH] HolderAwareContinuationsManagerImpl

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=31676

[PATCH] HolderAwareContinuationsManagerImpl





--- Additional Comments From [EMAIL PROTECTED]  2004-10-15 14:00 ---
Hm. But my solution only provides a way to properly clean up session when it is
invalidated.

Is there still a reason for providing "continuations session isolation", i.e.
making continuations of one session invisible in another? If yes, than this
SessionBoundWebContinuation should still contain map of continuations IDs, right?

Re: Integrating rhino-1.6pre

[Antonio Gallardo]

Vadim Gritsenko dijo:
> Antonio Gallardo wrote:
>> Vadim Gritsenko dijo:
>>
>>>Reinhard Poetz wrote:
>>>
And one last question: Does this have any legal implications
(licencing)?
>>>
>>>As long as you do your contributions under MPL, which means you keep
>>>cocoondev
>>>rhino licensed as MPL, I see no issues at all.
>>
>>
>> I have a question: Under a MPL project: Is the committer able to choose
>> whatever type of license he wants for his code?
>
> No. License clearly ;-) says:
>
>   3.1. Application of License.
>   The Modifications which You create or to which You contribute are
>   governed by the terms of this License, including without limitation
>   Section 2.2. The Source Code version of Covered Code may be
>   distributed only under the terms of this License or a future version
>   of this License released under Section 6.1, and You must include a
>   copy of this License with every copy of the Source Code You
>   distribute.
>
> Which means, all modifications you do to MPL code base has to be released
> under
> MPL. You can also see definition of Modification which basically says that
> Modification is changes to existing files or new file with some MPL code
> pasted
> into it. But if you add BRAND NEW file containing no MPL code whatsoever,
> you
> can do with them whatever you want (IIUC).

In a MPL project the committer can only commit under the MPL.

Thanks for the explanation. Now it is clear to me. :-)

Best Regards,

Antonio Gallardo

Re: Invalid content length, revisited

[Vadim Gritsenko]

Unico Hommes wrote:
Vadim Gritsenko wrote:
Unico Hommes wrote:
Oh I see now. The ResourceReader also sets the content length on the 
response. It *really* shouldn't do that IMHO. Anybody know why it 
does that?

I see that EnvironmentWrapper ignores set content length. And it has 
RequestWrapper. BUT IT DOES NOT HAVE ResponseWrapper! I guess that's 
the real problem.

ResourceReader probably should be changed to set content length on the 
environment, but this is fix in only one case. ResponseWrapper seems 
to be the fix for all cases at once. Or, am I missing something?

What about FOM though? Doesn't a flowscript run within an 
EnvironmentWrapper? If so, having WrapperResponse ignore calls to 
setHeader() and related methods would be undesirable.
Shouldn't it / could it run under MutableEnvironmentFacade?
Vadim

Re: Invalid content length, revisited

[Unico Hommes]

Vadim Gritsenko wrote:
Unico Hommes wrote:
Oh I see now. The ResourceReader also sets the content length on the 
response. It *really* shouldn't do that IMHO. Anybody know why it 
does that?

I see that EnvironmentWrapper ignores set content length. And it has 
RequestWrapper. BUT IT DOES NOT HAVE ResponseWrapper! I guess that's 
the real problem.

ResourceReader probably should be changed to set content length on the 
environment, but this is fix in only one case. ResponseWrapper seems 
to be the fix for all cases at once. Or, am I missing something?

What about FOM though? Doesn't a flowscript run within an 
EnvironmentWrapper? If so, having WrapperResponse ignore calls to 
setHeader() and related methods would be undesirable.

--
Unico

RE: Possible security problem with flowscript

[Carsten Ziegeler]

 
Rob Berens wrote:

> We identified this problem already and decided to solve it by 
> having a different way of making the continuation request. In 
> our case we use the original request with a request paremater e.g
> 
> Original request:
> mywebapp/original.html
> 
> Continuation request:
> mywebapp/original.html?continuation=123456
> 
> The sitemap does auhorization based on the request without 
> taken into consideration a possible continuation parameter 
> and therefore both the original request and the continuation 
> request are checked in the same way. A fter the authorization 
> has taken place the continuation is detected by:
> 
> 
>   
> 
> 
> Of course adding a request parameter to the original request 
> is a bit thougher then just replacing the last part by 
> 123456.continue. To solve this we have a transformer that, 
> apart from many other things, for several attributes like 
> href, src etc. replaces the string:
> continuation:123456
> 
> by the original request with a continuation parameter e.g.
> /mywebapp/original.html?continuation=123456
> 
> So it is something like a continuation pseudo protocol.
> 
Hmm, I might be wrong, but does this really protect you?
If you have a flow that is usable by not authenticated users,
you run into the same problem I think.

Carsten

RE: Possible security problem with flowscript

[Carsten Ziegeler]

Torsten Curdt wrote:
> 
> >>...but that *is* important: if you would be using a flow based 
> >>authentication mechanism this is not a problem at all.
> >>
> > 
> > Why? If flow checks the authentication, I simply use a 
> continuation id 
> > from an authenticated user and I'm in the application.
> 
> sure, same for any authentication mechanism that stores the 
> credentials inside the session. you cannot prevent that.
> 
> it's like the key to your house. if you have it you are in! 
> that's how it is. otherwise you have to authenticate on each request.
> 
> But I am glad "simply use a continuation id"
> usually is not that simple ;-)
> 
Yepp, that's true :)

Carsten

DO NOT REPLY [Bug 31676] - [PATCH] HolderAwareContinuationsManagerImpl

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=31676

[PATCH] HolderAwareContinuationsManagerImpl





--- Additional Comments From [EMAIL PROTECTED]  2004-10-15 13:45 ---
Ok with me. Let's others have a chance to comment.

Re: Possible security problem with flowscript

[Rob Berens]

On Friday, October 15, 2004 1:39 PM Carsten Ziegeler wrote
> Today we came across a possible security problem when you use flow
> script. We tested the following example with 2.1.5.1 and the
> current 2.1.x branch. Here is a simple example:
>
> We have two areas in our web application, one is available for every
> user and one area is only accessible for authenticated users.
> We create two sub sitemaps - one for each area. Both are using
> flow with different scripts. The second sitemap is protected
> by using the authentication framework (how the authentication
> is done is actually not important).
> In each sitemap we have a matcher for the continuation id:
>
> Sitemap for global area:
>  - mounted at /global
>  - flowscript global.js
>  - matcher for continuation id
>
>
>
>
> Sitemap for protected area:
>  - mounted at /protected
>  - flowscript protected.js
>  - matcher for continuation id
>
>
>
>
> Now, if someone is able to pick up a valid continuation id for the
protected
> area, it is possible to continue the flow script in "protected.js" by
> calling: "/global/continue.CONT_ID".
> Which means there isn't any further check, if the continuation id belongs
> to the sitemap or to the used javascripts in that sitemap.
> And flow is able to continue the script without any problems.

We identified this problem already and decided to solve it by having a
different way of making the continuation request. In our case we use the
original request with a request paremater e.g

Original request:
mywebapp/original.html

Continuation request:
mywebapp/original.html?continuation=123456

The sitemap does auhorization based on the request without taken into
consideration a possible continuation parameter and therefore both the
original request and the continuation request are checked in the same way. A
fter the authorization has taken place the continuation is detected by:


  


Of course adding a request parameter to the original request is a bit
thougher then just replacing the last part by 123456.continue. To solve this
we have a transformer that, apart from many other things, for several
attributes like href, src etc. replaces the string:
continuation:123456

by the original request with a continuation parameter e.g.
/mywebapp/original.html?continuation=123456

So it is something like a continuation pseudo protocol.

Rob Berens
Osirion B.V.
Gagelveld 41
6596 CC  Milsbeek
The Netherlands
Tel: +31 (0)485-54 02 03
Fax: +31 (0)485-54 02 04
E-mail: [EMAIL PROTECTED]

Re: Invalid content length, revisited

[Unico Hommes]

Vadim Gritsenko wrote:
Unico Hommes wrote:
Oh I see now. The ResourceReader also sets the content length on the 
response. It *really* shouldn't do that IMHO. Anybody know why it 
does that?

I see that EnvironmentWrapper ignores set content length. And it has 
RequestWrapper. BUT IT DOES NOT HAVE ResponseWrapper! I guess that's 
the real problem.

ResourceReader probably should be changed to set content length on the 
environment, but this is fix in only one case. ResponseWrapper seems 
to be the fix for all cases at once. Or, am I missing something?

I guess you are absolutely right. The Response object in the case of an 
internal request should be a WrappedResponse object. I don't think 
ResourceReader should deal with Environment directly.

There still remains the question whether the ResourceReader should be 
setting the Content-Length itself though. In fact setting response 
headers while generating a pipeline may be a bad idea in general 
depending on the type of header. When the processing pipeline 
implementation is caching there is no way to reproduce the original 
response and hence the cached response is different from the original 
generated response.

--
Unico

Re: Possible security problem with flowscript

[Vadim Gritsenko]

Leszek Gawron wrote:
Vadim Gritsenko wrote:
Leszek Gawron wrote:
Sylvain Wallez wrote:
Leszek Gawron wrote:
1. You login.
2. Do stuff.
3. Logout.

Did you forgot to invalidate continuations? Your fault. (1)
invalidating every continuation by hand is asking for problems hard to 
find.
For web application which requires session it is very convenient to 
invalidate all continuations when continuation holder is unbound from 
session (session invalidated).
Agreed, with minor differences. Currently I don't have any special "continuation 
holder", just single root continuations object. Moving the logic of maintaining 
and invalidating root continuations object into flow implementation makes sense 
to me.


I left some comments already in the bug report.
Thank you .. I have made a comment also. Please read it if you have time.
Done :)
Vadim

Re: Possible security problem with flowscript

[Torsten Curdt]

...but that *is* important: if you would be using a flow 
based authentication mechanism this is not a problem at all.

Why? If flow checks the authentication, I simply use a continuation
id from an authenticated user and I'm in the application. 
sure, same for any authentication mechanism that
stores the credentials inside the session. you
cannot prevent that.
it's like the key to your house. if you have it
you are in! that's how it is. otherwise you have
to authenticate on each request.
But I am glad "simply use a continuation id"
usually is not that simple ;-)
cheers
--
Torsten

DO NOT REPLY [Bug 31676] - [PATCH] HolderAwareContinuationsManagerImpl

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=31676

[PATCH] HolderAwareContinuationsManagerImpl





--- Additional Comments From [EMAIL PROTECTED]  2004-10-15 13:30 ---
Your solution saves us one class (WebContinuationsHolder). If we cannot come up
with any other place to put ContinuationsHolder to (apart from session) I am OK
with your proposal.
If it was accepted in the form you propose I could prepare another patch. For
current ContinuationsManagerImpl. Basing on some configuration a
SessionBoundWebContinuation would be made a parent for parentless continuations.
Is that ok?

DO NOT REPLY [Bug 31676] - [PATCH] HolderAwareContinuationsManagerImpl

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=31676

[PATCH] HolderAwareContinuationsManagerImpl





--- Additional Comments From [EMAIL PROTECTED]  2004-10-15 13:22 ---
You are missing one point though - only one, root continuation should be stored
in one session. And it should be unbounded only once when session is expired. So
no performance issues here. And when you are creating continuation, this root
continuation will be parent for all continuations for which no parent was
explicitly specified.

I agree that storing continuations manager in each continuation is not a good
idea. So probably we could do with adding RootWebContinuation class which
extends WebContinuation and implements HttpSessionBindingListener...

WDYT?

Re: GT2004 was brilliant

[Vadim Gritsenko]

Jeremy Quinn wrote:
On 15 Oct 2004, at 11:04, Gianugo Rabellino wrote:
Any chance you can "just" iDVD it for now with just separate chapters
per session? I know this would mean a hefty download, but isn't this
why bittorrent is there? Others then might jump in and postproduce the
sessions. But I would certainly like having DVD quality video for the
GT.
How to distribute it?
BitTorrent, as suggested above? If you have the place to put the seed, that 
is... But we would have to organize "downloading session" - it's not that many 
folks who would download it, so we need to gather in one point in time to 
realize torrent potentials.


Infrastructure I imagine will be reluctant with even heavily compressed 
video (they have not actually replied to me yet anyway ).
Well it worked for last year, so should work this year as well (precedent, isn't 
that how things are done in England anyway? ;-))

Vadim

Re: Possible security problem with flowscript

[Leszek Gawron]

Vadim Gritsenko wrote:
Leszek Gawron wrote:
Sylvain Wallez wrote:
Leszek Gawron wrote:
Sylvain Wallez wrote:
This has already been identified by Leszek Gawron. Although this is 
an issue, it can only be exploited by hijacking a continuation ID 
which, if done, also means the ability to hijack the session ID and 
therefore the associated authorizations.

Exactly.

1. You login.
2. Do stuff.
3. Logout.

Did you forgot to invalidate continuations? Your fault. (1)
invalidating every continuation by hand is asking for problems hard to find.
For web application which requires session it is very convenient to invalidate 
all continuations when continuation holder is unbound from session (session 
invalidated).

I left some comments already in the bug report.
Thank you .. I have made a comment also. Please read it if you have time.
--
Leszek Gawron  [EMAIL PROTECTED]
Project ManagerMobileBox sp. z o.o.
+48 (61) 855 06 67  http://www.mobilebox.pl
mobile: +48 (501) 720 812   fax: +48 (61) 853 29 65

Re: Invalid content length, revisited

[Vadim Gritsenko]

Unico Hommes wrote:
Oh I see now. The ResourceReader also sets the content length on the 
response. It *really* shouldn't do that IMHO. Anybody know why it does 
that?
I see that EnvironmentWrapper ignores set content length. And it has 
RequestWrapper. BUT IT DOES NOT HAVE ResponseWrapper! I guess that's the real 
problem.

ResourceReader probably should be changed to set content length on the 
environment, but this is fix in only one case. ResponseWrapper seems to be the 
fix for all cases at once. Or, am I missing something?

Vadim

DO NOT REPLY [Bug 31676] - [PATCH] HolderAwareContinuationsManagerImpl

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=31676

[PATCH] HolderAwareContinuationsManagerImpl





--- Additional Comments From [EMAIL PROTECTED]  2004-10-15 13:10 ---
I think implementing HttpSessionBindingListener for WebContinuation is not
enough. The continuation in valueUnbound would have to notify the continuations
manager that it has disposed itself so the continuations manager could remove
all references to it (expiration info for example). The WebContinuation would
have to keep reference to a continuation manager.
It would also affect performance I think because the continuations manager would
be notified for EVERY continuation (I mean parent/child relationships).

Re: Cocoon 2.1.6 Release Plan, Re: Syncing 2.1.x and 2.2

[Unico Hommes]

Vadim Gritsenko wrote:
Carsten Ziegeler wrote:
According to the wiki we still have some open blocks/areas.
http://wiki.apache.org/cocoon/MergingBranches

In addition it seems that some new things have been checked in
only to one branch, either trunk or 2.1.x, but not to both.
Could everyone please verify that all patches, fixes etc. are
applied accordingly? Of course, there are features that
should only apply to 2.2.
I see a successful merging as a minimum requirement for the 2.1.6
release.

What else beside merging? I'd say checking out all tests and samples 
is another required step. Going through TODO/Bugzilla items to 
identify blockers could be the third thing. I'm aware of at least one 
open issue [1] which could be addressed in 2.1.6

Vadim
[1] http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=109596886721684

Both the test and the code seem to be wrong. IIUC the behavior should be 
that failing to redirect from flow should raise a ProcessingException. 
IOW a 500 response status code should be the correct behavior. However 
the test case tests for a 404 and the actual response code seems to be 200.

--
Unico

Re: Cocoon 2.1.6 Release Plan, Re: Syncing 2.1.x and 2.2

[Vadim Gritsenko]

Carsten Ziegeler wrote:
What about the sitemap reloading/flow script problem you reported recently?
Is this already fixed?
Yep.
http://svn.apache.org/viewcvs.cgi/cocoon/trunk/status.xml?r1=51847&r2=53752&p1=cocoon/trunk/status.xml&p2=cocoon/trunk/status.xml&diff_format=h&root=Apache-SVN
Vadim

Re: Possible security problem with flowscript

[Vadim Gritsenko]

Leszek Gawron wrote:
Sylvain Wallez wrote:
Leszek Gawron wrote:
Sylvain Wallez wrote:
This has already been identified by Leszek Gawron. Although this is 
an issue, it can only be exploited by hijacking a continuation ID 
which, if 
done, also means the ability to hijack the session ID and therefore 
the associated authorizations.
Exactly.

1. You login.
2. Do stuff.
3. Logout.
Did you forgot to invalidate continuations? Your fault. (1)

4. Even restart your computer.
5. Go to firefox cache - the page is there (still do not know why if 
I set caching headers properly).
Properly configured headers allow to keep stuff out of cache - works for me.
http://www.mozilla.org/projects/netlib/http/http-caching-faq.html

5. http://thehost.com/myapp/showReport.do. The page loads from cache. 
The page content has a hidden input with valid continuation.
See (1) above.

The solution for this is the continuation-per-session manager, where 
a continuation ID only exists within a given session.

Would you be so kind and review my solution for this? It is not quite 
finished (instrumentation and debug info is not implemented) but I am 
very eager to polish it if it could be useful to anyone but me.
I left some comments already in the bug report.

I also like your idea of associating the sitemap ID to the 
continuation so that a given continuation can only be called in the 
sitemap that created it. As the flowscript interpreter already holds 
this ID, that should be pretty much straightforward.
It won't work - see my example in the other email on this subject.

How can I retrieve that ID? I could implement a test version for Carsten.
It is in AbstractInterpreter.getInterpreterID()
Vadim

Re: Integrating rhino-1.6pre

[Sylvain Wallez]

Bertrand Delacretaz wrote:
Le 15 oct. 04, à 08:50, Reinhard Poetz a écrit :
Igor kindly provided a new patch for Cocoon 2.1.5.1 which works now 
for me! Before I can apply the patch I want to propose to change the 
package names in Rhino (thanks Igor for the idea). This way we can 
have both implementations of rhino in parallel in Cocoon and our 
users can switch whenever they are ready to do it.

+1, many thanks for your work up to know (I even heard you did some of 
it while listening to the GT presentations ;-)

+1
...What do you prefer? Moving to SVN before (of course, only if 
somebody does the migration) or simply creating a CVS branch and then 
move on with the new package names

I think a CVS branch is good enough, as the aim is to replace the 
current Rhino stuff soon anyway.

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

Re: Possible security problem with flowscript

[Vadim Gritsenko]

Torsten Curdt wrote:
Today we came across a possible security problem when you use flow
script. We tested the following example with 2.1.5.1 and the
current 2.1.x branch. Here is a simple example:
We have two areas in our web application, one is available for every
user and one area is only accessible for authenticated users.
We create two sub sitemaps - one for each area. Both are using
flow with different scripts. The second sitemap is protected
by using the authentication framework (how the authentication
is done is actually not important).

...but that *is* important: if you would be using a flow based
authentication mechanism this is not a problem at all.

So it seems that it would be good if we would have some further checks.
I think, it would be good if flow would check if the continuation id
belongs to the sitemap where the map:call is performed. Currently the
ids are global and not on a per sitemap level.

We could create a continuation manager per sitemap. ...but
I am not really sure whether this is a good idea to make
this the default.
Or we store the continuations in the session. Or?
Tying the continuations to the session is not good idea as well. For two reasons:
 * Flow does not require session - so session might not be there
 * Session can be hijacked as easily as continuation:
 http://a.b.c/some/page;jsessionID=1234567890
Even tying continuations to the sitemap won't help. Consider this simple snippet:

  

  
  

  


That would also be an option. On the other hand
this would make a session mandatory for continuations.
...which is not necessarily needed.
Exactly.
Real solution to this problem seems to me authentication check which is 
happening in FOM_JavaScriptInterpreter.handleContinuation. Check in *that* place 
won't be possible to "circumvent" - unless you hijack session, see above.

How about adding pre-function-call and pre-handle-continuation hooks?
Vadim

RE: Cocoon 2.1.6 Release Plan, Re: Syncing 2.1.x and 2.2

[Carsten Ziegeler]

Vadim Gritsenko wrote:
> 
> Carsten Ziegeler wrote:
> > According to the wiki we still have some open blocks/areas. 
> > 
> >>http://wiki.apache.org/cocoon/MergingBranches
> > 
> > 
> > In addition it seems that some new things have been checked 
> in only to 
> > one branch, either trunk or 2.1.x, but not to both.
> > Could everyone please verify that all patches, fixes etc. 
> are applied 
> > accordingly? Of course, there are features that should only 
> apply to 
> > 2.2.
> > 
> > I see a successful merging as a minimum requirement for the 2.1.6 
> > release.
> 
> What else beside merging? I'd say checking out all tests and 
> samples is another required step. Going through TODO/Bugzilla 
> items to identify blockers could be the third thing. I'm 
> aware of at least one open issue [1] which could be addressed in 2.1.6
> 
What about the sitemap reloading/flow script problem you reported recently?
Is this already fixed?

Carsten

Re: Possible security problem with flowscript

[Leszek Gawron]

Sylvain Wallez wrote:
Leszek Gawron wrote:
Sylvain Wallez wrote:
This has already been identified by Leszek Gawron. Although this is 
an issue, it can only be exploited by hijacking a continuation ID 
which, if 

> done, also means the ability to hijack the session ID and therefore the
> associated authorizations.
not only ..
1. You login.
2. Do stuff.
3. Logout.
4. Even restart your computer.
5. Go to firefox cache - the page is there (still do not know why if I 
set caching headers properly).
5. http://thehost.com/myapp/showReport.do. The page loads from cache. 
The page content has a hidden input with valid continuation.
6. submit form.
7. the report is yours!

You're right, but this works only during the continuation expiration 
period.

The solution for this is the continuation-per-session manager, where 
a continuation ID only exists within a given session.

Would you be so kind and review my solution for this? It is not quite 
finished (instrumentation and debug info is not implemented) but I am 
very eager to polish it if it could be useful to anyone but me.

I'm insanely busy until next wednesday and unfortunately will not be 
able to look at it before. Maybe someone else can do it in the meantime?

I also like your idea of associating the sitemap ID to the continuation 
so that a given continuation can only be called in the sitemap that 
created it. As the flowscript interpreter already holds this ID, that 
should be pretty much straightforward.

Sylvain
How can I retrieve that ID? I could implement a test version for Carsten.
--
Leszek Gawron  [EMAIL PROTECTED]
Project ManagerMobileBox sp. z o.o.
+48 (61) 855 06 67  http://www.mobilebox.pl
mobile: +48 (501) 720 812   fax: +48 (61) 853 29 65

Re: Possible security problem with flowscript

[Sylvain Wallez]

Leszek Gawron wrote:
Sylvain Wallez wrote:
This has already been identified by Leszek Gawron. Although this is 
an issue, it can only be exploited by hijacking a continuation ID 
which, if 
> done, also means the ability to hijack the session ID and therefore the
> associated authorizations.
not only ..
1. You login.
2. Do stuff.
3. Logout.
4. Even restart your computer.
5. Go to firefox cache - the page is there (still do not know why if I 
set caching headers properly).
5. http://thehost.com/myapp/showReport.do. The page loads from cache. 
The page content has a hidden input with valid continuation.
6. submit form.
7. the report is yours!

You're right, but this works only during the continuation expiration period.
The solution for this is the continuation-per-session manager, where 
a continuation ID only exists within a given session.
Would you be so kind and review my solution for this? It is not quite 
finished (instrumentation and debug info is not implemented) but I am 
very eager to polish it if it could be useful to anyone but me.

I'm insanely busy until next wednesday and unfortunately will not be 
able to look at it before. Maybe someone else can do it in the meantime?

I also like your idea of associating the sitemap ID to the continuation 
so that a given continuation can only be called in the sitemap that 
created it. As the flowscript interpreter already holds this ID, that 
should be pretty much straightforward.

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

Re: Integrating rhino-1.6pre

[Vadim Gritsenko]

Antonio Gallardo wrote:
Vadim Gritsenko dijo:
Reinhard Poetz wrote:
And one last question: Does this have any legal implications
(licencing)?
As long as you do your contributions under MPL, which means you keep
cocoondev
rhino licensed as MPL, I see no issues at all.

I have a question: Under a MPL project: Is the committer able to choose
whatever type of license he wants for his code?
No. License clearly ;-) says:
 3.1. Application of License.
 The Modifications which You create or to which You contribute are
 governed by the terms of this License, including without limitation
 Section 2.2. The Source Code version of Covered Code may be
 distributed only under the terms of this License or a future version
 of this License released under Section 6.1, and You must include a
 copy of this License with every copy of the Source Code You
 distribute.
Which means, all modifications you do to MPL code base has to be released under 
MPL. You can also see definition of Modification which basically says that 
Modification is changes to existing files or new file with some MPL code pasted 
into it. But if you add BRAND NEW file containing no MPL code whatsoever, you 
can do with them whatever you want (IIUC).

Vadim

RE: Possible security problem with flowscript

[Carsten Ziegeler]

Torsten Curdt wrote:
> 
> > Today we came across a possible security problem when you use flow 
> > script. We tested the following example with 2.1.5.1 and 
> the current 
> > 2.1.x branch. Here is a simple example:
> > 
> > We have two areas in our web application, one is available 
> for every 
> > user and one area is only accessible for authenticated users.
> > We create two sub sitemaps - one for each area. Both are using flow 
> > with different scripts. The second sitemap is protected by 
> using the 
> > authentication framework (how the authentication is done is 
> actually 
> > not important).
> 
> ...but that *is* important: if you would be using a flow 
> based authentication mechanism this is not a problem at all.
> 
Why? If flow checks the authentication, I simply use a continuation
id from an authenticated user and I'm in the application. 

Carsten 

Re: Possible security problem with flowscript

[Leszek Gawron]

Torsten Curdt wrote:
Today we came across a possible security problem when you use flow
script. We tested the following example with 2.1.5.1 and the
current 2.1.x branch. Here is a simple example:
We have two areas in our web application, one is available for every
user and one area is only accessible for authenticated users.
We create two sub sitemaps - one for each area. Both are using
flow with different scripts. The second sitemap is protected
by using the authentication framework (how the authentication
is done is actually not important).

...but that *is* important: if you would be using a flow based
authentication mechanism this is not a problem at all.

So it seems that it would be good if we would have some further checks.
I think, it would be good if flow would check if the continuation id
belongs to the sitemap where the map:call is performed. Currently the
ids are global and not on a per sitemap level.

We could create a continuation manager per sitemap. ...but
I am not really sure whether this is a good idea to make
this the default.
Is there a possibility to attach some "attributes" to sitemap? I mean for 
example continuations holder?

--
Leszek Gawron  [EMAIL PROTECTED]
Project ManagerMobileBox sp. z o.o.
+48 (61) 855 06 67  http://www.mobilebox.pl
mobile: +48 (501) 720 812   fax: +48 (61) 853 29 65

Re: Possible security problem with flowscript

[Leszek Gawron]

Sylvain Wallez wrote:
This has already been identified by Leszek Gawron. Although this is an 
issue, it can only be exploited by hijacking a continuation ID which, if 
> done, also means the ability to hijack the session ID and therefore the
> associated authorizations.
not only ..
1. You login.
2. Do stuff.
3. Logout.
4. Even restart your computer.
5. Go to firefox cache - the page is there (still do not know why if I set 
caching headers properly).
5. http://thehost.com/myapp/showReport.do. The page loads from cache. The page 
content has a hidden input with valid continuation.
6. submit form.
7. the report is yours!

The solution for this is the continuation-per-session manager, where a 
continuation ID only exists within a given session.
Would you be so kind and review my solution for this? It is not quite finished 
(instrumentation and debug info is not implemented) but I am very eager to 
polish it if it could be useful to anyone but me.

--
Leszek Gawron  [EMAIL PROTECTED]
Project ManagerMobileBox sp. z o.o.
+48 (61) 855 06 67  http://www.mobilebox.pl
mobile: +48 (501) 720 812   fax: +48 (61) 853 29 65

Cocoon 2.1.6 Release Plan, Re: Syncing 2.1.x and 2.2

[Vadim Gritsenko]

Carsten Ziegeler wrote:
According to the wiki we still have some open blocks/areas. 

http://wiki.apache.org/cocoon/MergingBranches

In addition it seems that some new things have been checked in
only to one branch, either trunk or 2.1.x, but not to both.
Could everyone please verify that all patches, fixes etc. are
applied accordingly? Of course, there are features that
should only apply to 2.2.
I see a successful merging as a minimum requirement for the 2.1.6
release.
What else beside merging? I'd say checking out all tests and samples is another 
required step. Going through TODO/Bugzilla items to identify blockers could be 
the third thing. I'm aware of at least one open issue [1] which could be 
addressed in 2.1.6

Vadim
[1] http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=109596886721684

Re: [RT] Some notes about the "Real Blocks" issue

[Ugo Cei]

Il giorno 15/ott/04, alle 13:01, Vadim Gritsenko ha scritto:
The best plan IMHO would be:
1. Remove ECM - implementation of Avalon container. Keep re-usable 
components code (XSLT, Source, Store, etc).
2. Drop in the container which replaces it.
3. Write bridge code between container in (2) and (1).
4. Test.
5. Release Cocoon 2.3.
6. Continue with usual Cocoon development: improvements, refactorings, 
as you see fit: rewrite source resolving or sitemap processor or 
whatever you want if you have time for it.

For a useful example of 6, Store implementation should plug in into 
Java 1.5 management API instead of having background checker thread.

Looks like a very good plan to me.
Ugo
--
Ugo Cei - http://beblogging.com/


smime.p7s
Description: S/MIME cryptographic signature

Re: Possible security problem with flowscript

[Torsten Curdt]

Today we came across a possible security problem when you use flow
script. We tested the following example with 2.1.5.1 and the
current 2.1.x branch. Here is a simple example:
We have two areas in our web application, one is available for every
user and one area is only accessible for authenticated users.
We create two sub sitemaps - one for each area. Both are using
flow with different scripts. The second sitemap is protected
by using the authentication framework (how the authentication
is done is actually not important).
...but that *is* important: if you would be using a flow based
authentication mechanism this is not a problem at all.

So it seems that it would be good if we would have some further checks.
I think, it would be good if flow would check if the continuation id
belongs to the sitemap where the map:call is performed. Currently the
ids are global and not on a per sitemap level.
We could create a continuation manager per sitemap. ...but
I am not really sure whether this is a good idea to make
this the default.
Or we store the continuations in the session. Or?
That would also be an option. On the other hand
this would make a session mandatory for continuations.
...which is not necessarily needed.
cheers
--
Torsten

Re: Integrating rhino-1.6pre

[Antonio Gallardo]

Vadim Gritsenko dijo:
> Reinhard Poetz wrote:
>>
>> Igor kindly provided a new patch for Cocoon 2.1.5.1 which works now for
>> me! Before I can apply the patch I want to propose to change the package
>> names in Rhino (thanks Igor for the idea). This way we can have both
>> implementations of rhino in parallel in Cocoon and our users can switch
>> whenever they are ready to do it.
>>
>> If nobody speaks up against it, I volunteer doing the renaming if I get
>> commit access to
>> http://cvs.cocoondev.org/cgi-bin/viewcvs.cgi/?cvsroot=rhino. Of course
>> this leads to a loss of the history. What do you prefer? Moving to SVN
>> before (of course, only if somebody does the migration) or simply
>> creating a CVS branch and then move on with the new package names.
>>
>> And one last question: Does this have any legal implications
>> (licencing)?
>
> As long as you do your contributions under MPL, which means you keep
> cocoondev
> rhino licensed as MPL, I see no issues at all.

Hi Vadim:

First, I am really happy with the Reinhard's work in this area! Thank you,
Reinhardt! :-)

I have a question: Under a MPL project: Is the committer able to choose
whatever type of license he wants for his code?

I am a little bit confused with that. I know we don't need to worry much
about the rhino clone on cocoondev which will become less important for us
and perhaps die. But this important for us to understand the MPL. Of
course I know you are not a lawyer, but a little bit of helps is good for
all and as often is very welcome. ;-)

Best Regards,

Antonio Gallardo

Re: GT2004 was brilliant

[David Crossley]

Jeremy Quinn wrote:
> 
> How to distribute it?
> 
> Infrastructure I imagine will be reluctant with even heavily compressed 
> video (they have not actually replied to me yet anyway ).

Yes they have, a few hours after your question.
Noel asked: how big, was it as "extensive" as last year's,
and he can't remember what was discussed last year.

I have been trying to search my local mail archives
but cannot get it either.

-- 
David Crossley

Re: Possible security problem with flowscript

[Sylvain Wallez]

Carsten Ziegeler wrote:
Today we came across a possible security problem when you use flow
script. We tested the following example with 2.1.5.1 and the
current 2.1.x branch. Here is a simple example:
We have two areas in our web application, one is available for every
user and one area is only accessible for authenticated users.
We create two sub sitemaps - one for each area. Both are using
flow with different scripts. The second sitemap is protected
by using the authentication framework (how the authentication
is done is actually not important).
In each sitemap we have a matcher for the continuation id:
Sitemap for global area:
- mounted at /global
- flowscript global.js
- matcher for continuation id
  
  
  
Sitemap for protected area:
- mounted at /protected
- flowscript protected.js
- matcher for continuation id
  
  
  
Now, if someone is able to pick up a valid continuation id for the protected
area, it is possible to continue the flow script in "protected.js" by
calling: "/global/continue.CONT_ID".
Which means there isn't any further check, if the continuation id belongs
to the sitemap or to the used javascripts in that sitemap.
And flow is able to continue the script without any problems.
So it seems that it would be good if we would have some further checks.
I think, it would be good if flow would check if the continuation id
belongs to the sitemap where the map:call is performed. Currently the
ids are global and not on a per sitemap level.
Or we store the continuations in the session. Or?
 

This has already been identified by Leszek Gawron. Although this is an 
issue, it can only be exploited by hijacking a continuation ID which, if 
done, also means the ability to hijack the session ID and therefore the 
associated authorizations.

The solution for this is the continuation-per-session manager, where a 
continuation ID only exists within a given session.

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

Re: Possible security problem with flowscript

[Leszek Gawron]

Carsten Ziegeler wrote:
Today we came across a possible security problem when you use flow
script. We tested the following example with 2.1.5.1 and the
current 2.1.x branch. Here is a simple example:
We have two areas in our web application, one is available for every
user and one area is only accessible for authenticated users.
We create two sub sitemaps - one for each area. Both are using
flow with different scripts. The second sitemap is protected
by using the authentication framework (how the authentication
is done is actually not important).
In each sitemap we have a matcher for the continuation id:
Sitemap for global area:
 - mounted at /global
 - flowscript global.js
 - matcher for continuation id
   
   
   
Sitemap for protected area:
 - mounted at /protected
 - flowscript protected.js
 - matcher for continuation id
   
   
   
Now, if someone is able to pick up a valid continuation id for the protected
area, it is possible to continue the flow script in "protected.js" by
calling: "/global/continue.CONT_ID".
Which means there isn't any further check, if the continuation id belongs
to the sitemap or to the used javascripts in that sitemap.
And flow is able to continue the script without any problems.
So it seems that it would be good if we would have some further checks.
I think, it would be good if flow would check if the continuation id
belongs to the sitemap where the map:call is performed. Currently the
ids are global and not on a per sitemap level.
Or we store the continuations in the session. Or?
Ah.. I did not read your mail carefully enough. You would like to bind 
continuations to the sitemap. My HolderAwareContinuationsManagerImpl stores 
all continuations in session regardles of it's creation place. If there is 
some possibility to bind a WebContinuationsHolder to a particular sitemap the 
change in my continuations manager is a few liner really (just change the way 
the WebContinuationsHolder is being looked up).

--
Leszek Gawron  [EMAIL PROTECTED]
Project ManagerMobileBox sp. z o.o.
+48 (61) 855 06 67  http://www.mobilebox.pl
mobile: +48 (501) 720 812   fax: +48 (61) 853 29 65

Re: Possible security problem with flowscript

[Leszek Gawron]

I have implemented a fix for that. Please see
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=109768021416304&w=2
and http://issues.apache.org/bugzilla/show_bug.cgi?id=31676
The continuations get stored in session. This way the continuation can be 
resumed only for the same session.

Still waiting for the patch to be applied. It would be the best if user could 
choose a continuations manager implementation for build configuration.

lg
Jeremy Quinn wrote:
Hi Carsten,
I can concur.
I found this out recently to my surprise, when I realised any sitemap 
continuation handler (using a request parameter) would handle any 
continuation it received, regardless of where it came from.
It was actually useful to me at the time, but I had not considered the 
security implications!!

regards Jeremy
On 15 Oct 2004, at 12:39, Carsten Ziegeler wrote:
Today we came across a possible security problem when you use flow
script. We tested the following example with 2.1.5.1 and the
current 2.1.x branch. Here is a simple example:
We have two areas in our web application, one is available for every
user and one area is only accessible for authenticated users.
We create two sub sitemaps - one for each area. Both are using
flow with different scripts. The second sitemap is protected
by using the authentication framework (how the authentication
is done is actually not important).
In each sitemap we have a matcher for the continuation id:
Sitemap for global area:
 - mounted at /global
 - flowscript global.js
 - matcher for continuation id
   
   
   
Sitemap for protected area:
 - mounted at /protected
 - flowscript protected.js
 - matcher for continuation id
   
   
   
Now, if someone is able to pick up a valid continuation id for the 
protected
area, it is possible to continue the flow script in "protected.js" by
calling: "/global/continue.CONT_ID".
Which means there isn't any further check, if the continuation id belongs
to the sitemap or to the used javascripts in that sitemap.
And flow is able to continue the script without any problems.

So it seems that it would be good if we would have some further checks.
I think, it would be good if flow would check if the continuation id
belongs to the sitemap where the map:call is performed. Currently the
ids are global and not on a per sitemap level.
Or we store the continuations in the session. Or?
Carsten
Carsten Ziegeler
Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.net/weblogs/rael/


  If email from this address is not signed
IT IS NOT FROM ME
Always check the label, folks !


--
Leszek Gawron  [EMAIL PROTECTED]
Project ManagerMobileBox sp. z o.o.
+48 (61) 855 06 67  http://www.mobilebox.pl
mobile: +48 (501) 720 812   fax: +48 (61) 853 29 65

Re: Possible security problem with flowscript

[Jeremy Quinn]

Hi Carsten,
I can concur.
I found this out recently to my surprise, when I realised any sitemap 
continuation handler (using a request parameter) would handle any 
continuation it received, regardless of where it came from.
It was actually useful to me at the time, but I had not considered the 
security implications!!

regards Jeremy
On 15 Oct 2004, at 12:39, Carsten Ziegeler wrote:
Today we came across a possible security problem when you use flow
script. We tested the following example with 2.1.5.1 and the
current 2.1.x branch. Here is a simple example:
We have two areas in our web application, one is available for every
user and one area is only accessible for authenticated users.
We create two sub sitemaps - one for each area. Both are using
flow with different scripts. The second sitemap is protected
by using the authentication framework (how the authentication
is done is actually not important).
In each sitemap we have a matcher for the continuation id:
Sitemap for global area:
 - mounted at /global
 - flowscript global.js
 - matcher for continuation id
   
   
   
Sitemap for protected area:
 - mounted at /protected
 - flowscript protected.js
 - matcher for continuation id
   
   
   
Now, if someone is able to pick up a valid continuation id for the 
protected
area, it is possible to continue the flow script in "protected.js" by
calling: "/global/continue.CONT_ID".
Which means there isn't any further check, if the continuation id 
belongs
to the sitemap or to the used javascripts in that sitemap.
And flow is able to continue the script without any problems.

So it seems that it would be good if we would have some further checks.
I think, it would be good if flow would check if the continuation id
belongs to the sitemap where the map:call is performed. Currently the
ids are global and not on a per sitemap level.
Or we store the continuations in the session. Or?
Carsten
Carsten Ziegeler
Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.net/weblogs/rael/


  If email from this address is not signed
IT IS NOT FROM ME
Always check the label, folks !



smime.p7s
Description: S/MIME cryptographic signature

RE: Syncing 2.1.x and 2.2

[Carsten Ziegeler]

According to the wiki we still have some open blocks/areas. 

> http://wiki.apache.org/cocoon/MergingBranches

In addition it seems that some new things have been checked in
only to one branch, either trunk or 2.1.x, but not to both.
Could everyone please verify that all patches, fixes etc. are
applied accordingly? Of course, there are features that
should only apply to 2.2.

I see a successful merging as a minimum requirement for the 2.1.6
release.

Carsten
> -Original Message-
> From: Carsten Ziegeler [mailto:[EMAIL PROTECTED] 
> Sent: Wednesday, August 11, 2004 1:51 PM
> To: Cocoon-Dev
> Subject: Syncing 2.1.x and 2.2
> 
> In order to port back some of the changes we did in the 2.2 
> branch to 2.1.x, I created a page on our wiki that keeps 
> track about it.
> You can find the site here:
> 
> http://wiki.apache.org/cocoon/MergingBranches
> 
> For this I compared the two source trees with each other and 
> checked the changes; I hope I did nothing wrong :(
> 
> So, whoever has some time can just pick out one of the 
> remaining items and work on it :) Some of the blocks 
> shouldn't take more than 10 minutes.
> 
> I think the most difficult part is the core (java sources). 
> We have to be very careful to not introduce incompatibilities 
> here (for example by removing deprecated code etc)! So, 
> perhaps we can split the core into different packages if required.
> 
> Carsten 
> 
> Carsten Ziegeler
> Open Source Group, S&N AG
> http://www.s-und-n.de
> http://www.osoco.net/weblogs/rael/
> 

Possible security problem with flowscript

[Carsten Ziegeler]

Today we came across a possible security problem when you use flow
script. We tested the following example with 2.1.5.1 and the
current 2.1.x branch. Here is a simple example:

We have two areas in our web application, one is available for every
user and one area is only accessible for authenticated users.
We create two sub sitemaps - one for each area. Both are using
flow with different scripts. The second sitemap is protected
by using the authentication framework (how the authentication
is done is actually not important).
In each sitemap we have a matcher for the continuation id:

Sitemap for global area:
 - mounted at /global
 - flowscript global.js
 - matcher for continuation id
   
   
   

Sitemap for protected area:
 - mounted at /protected
 - flowscript protected.js
 - matcher for continuation id
   
   
   

Now, if someone is able to pick up a valid continuation id for the protected
area, it is possible to continue the flow script in "protected.js" by
calling: "/global/continue.CONT_ID".
Which means there isn't any further check, if the continuation id belongs
to the sitemap or to the used javascripts in that sitemap.
And flow is able to continue the script without any problems.

So it seems that it would be good if we would have some further checks.
I think, it would be good if flow would check if the continuation id
belongs to the sitemap where the map:call is performed. Currently the
ids are global and not on a per sitemap level.
Or we store the continuations in the session. Or?


Carsten 

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

Re: GT2004 was brilliant

[Jeremy Quinn]

On 15 Oct 2004, at 11:04, Gianugo Rabellino wrote:
On Fri, 15 Oct 2004 09:56:16 +0100, Jeremy Quinn
<[EMAIL PROTECTED]> wrote:
On 14 Oct 2004, at 17:31, Jeremy Quinn wrote:
We videoed all of the sessions, processing it all will take a while, 
I
hope to begin uploading one per day from tomorrow.

Having spent a long night of compressor-hell, the timescale above may
prove to be a bit optimistic.
Working with Steven's introduction, I have yet to reproduce the
combination of image quality, image size, file size, frame rate etc.
that Stefano achieved.
Any chance you can "just" iDVD it for now with just separate chapters
per session? I know this would mean a hefty download, but isn't this
why bittorrent is there? Others then might jump in and postproduce the
sessions. But I would certainly like having DVD quality video for the
GT.
How to distribute it?
Infrastructure I imagine will be reluctant with even heavily compressed 
video (they have not actually replied to me yet anyway ).

I have iDVD, but no DVD burner.
regards Jeremy

  If email from this address is not signed
IT IS NOT FROM ME
Always check the label, folks !



smime.p7s
Description: S/MIME cryptographic signature

Re: Invalid content length, revisited

[Unico Hommes]

Unico Hommes wrote:
Rogier Peters wrote:
Guys,
On 18/5 Joerg asked a question about invalid content length errors[1] 
due to
readers. There is also a bug that is somewhat related[2], but it 
seems to be
WONTFIX.

 

The WONTFIX seems to apply to the original description of the bug 
only. There is a related issue that is mentioned in that thread that I 
think *is* a valid problem.

I have the following case :
 generatorreader
 |  |
 validator .. dtd
 |
 serializer
In this case the reader sets the content-length, and the serializer 
doesn't. So
if the length of the serializer's output is greater than that of the 
dtd, output
is incomplete.
Althoug a quick fix is not to get the dtd through a reader, I'm sure 
there are
cases where that isn't a solution. I didn't post this as a bug, yet, 
because I am not sure whether this is just
unintended use of the reader.  

It oughta work. I don't see how it doesn't. 

Oh I see now. The ResourceReader also sets the content length on the 
response. It *really* shouldn't do that IMHO. Anybody know why it does that?

--
Unico

Re: Invalid content length, revisited

[Unico Hommes]

Rogier Peters wrote:
Guys,
On 18/5 Joerg asked a question about invalid content length errors[1] due to
readers. There is also a bug that is somewhat related[2], but it seems to be
WONTFIX.
 

The WONTFIX seems to apply to the original description of the bug only. 
There is a related issue that is mentioned in that thread that I think 
*is* a valid problem.

I have the following case :
 generatorreader
 |  |
 validator .. dtd
 |
 serializer
In this case the reader sets the content-length, and the serializer doesn't. So
if the length of the serializer's output is greater than that of the dtd, output
is incomplete.
Althoug a quick fix is not to get the dtd through a reader, I'm sure there are
cases where that isn't a solution. 
I didn't post this as a bug, yet, because I am not sure whether this is just
unintended use of the reader. 
 

It oughta work. I don't see how it doesn't. The environment that is 
associated with internal requests (EnvironmentWrapper) does not forward 
setContentLength() to its wrapped instance so it shouldn't reach the 
HttpEnvironment. Perhaps reading a cocoon pipeline is interpreted as an 
internal redirect in wich case MutableEnvironmentFacade *does* forward it?

Also, I can't quite get my mind around what's the best way to solve this. Joerg
suggested in his original mail[1] to build some awareness in to the reader to
see if it is called as a cocoon-source or not. Another possible solution would
be setting content-length from all serializers, although Carsten suggests in the
closing of the bug that content-length can not be set repeatedly. 

 

The problem Carsten mentions is that once the http headers are sent 
setting the content-length header has no effect.

I agree with Joerg that it smells that the (resource) reader is setting 
all kinds of response headers where it should probably better be handled 
by the processing pipeline. That is the IoC approach that is taken with 
setting the Content-Type header. By doing it in that way, you avoid the 
current problem that a ResourceReader in a caching pipeline produces 
different responses depending on whether the content is served from the 
cache or produced by a call to generate().

So perhaps we should think about enhancing the SitemapOutputComponent 
interface with several additional methods to allow the processing 
pipeline to set more response headers. I know of one problem with 
content encoding where the pipeline should be able to determine the 
encoding in order to return it in the Content-Type header.

What do others think?

Re: Integrating rhino-1.6pre

[Vadim Gritsenko]

Reinhard Poetz wrote:
Igor kindly provided a new patch for Cocoon 2.1.5.1 which works now for 
me! Before I can apply the patch I want to propose to change the package 
names in Rhino (thanks Igor for the idea). This way we can have both 
implementations of rhino in parallel in Cocoon and our users can switch 
whenever they are ready to do it.

If nobody speaks up against it, I volunteer doing the renaming if I get 
commit access to 
http://cvs.cocoondev.org/cgi-bin/viewcvs.cgi/?cvsroot=rhino. Of course 
this leads to a loss of the history. What do you prefer? Moving to SVN 
before (of course, only if somebody does the migration) or simply 
creating a CVS branch and then move on with the new package names.

And one last question: Does this have any legal implications (licencing)?
As long as you do your contributions under MPL, which means you keep cocoondev 
rhino licensed as MPL, I see no issues at all.

Vadim

Re: [RT] Some notes about the "Real Blocks" issue

[Vadim Gritsenko]

Carsten Ziegeler wrote:
Ugo Cei wrote:
The interfaces that are in Butterfly are a verbatim copy 
(apart maybe from some minor changes, some time has passed 
and I don't remember all the details) of the Excalibur ones.

Of course, the package names have changed (and the 
o.a.butterfly will have to be changed to o.a.cocoon if they 
ever make it into the Cocoon core), but are you suggesting 
that we shoud keep o.a.excalibur.source.Source and so on?
Of course! We *must* keep all Avalon / Excalibur interfaces which are currently 
employed in our code base. But implementation is a different story.


Don't know :) I'm just concerned about compatibility and about
the learning curve. Today people are used to the excalibur
source handling - which takes a little bit of time to learn.
Introducing a new source handling - even if only the interfaces
are different - increases this learning curve as they have to
get used to new things.

Hmmm, OK, how about:
package org.apache.excalibur.source;
public interface Source extends org.apache.cocoon.source.Source {} ?
You mean this as a compatibility layer, right? So, new code would use
the o.a.c.s.Source and old code can still use the o.a.e.s.Source?
Hmm, I actually don't know what's best. What do others think?
The best plan IMHO would be:
1. Remove ECM - implementation of Avalon container. Keep re-usable components 
code (XSLT, Source, Store, etc).
2. Drop in the container which replaces it.
3. Write bridge code between container in (2) and (1).
4. Test.
5. Release Cocoon 2.3.
6. Continue with usual Cocoon development: improvements, refactorings, as you 
see fit: rewrite source resolving or sitemap processor or whatever you want if 
you have time for it.

For a useful example of 6, Store implementation should plug in into Java 1.5 
management API instead of having background checker thread.

Vadim

DO NOT REPLY [Bug 31726] New: - Small API change to access sitemap data structure

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=31726

Small API change to access sitemap data structure

   Summary: Small API change to access sitemap data structure
   Product: Cocoon 2
   Version: 2.1.5
  Platform: All
OS/Version: Other
Status: NEW
  Severity: Enhancement
  Priority: Other
 Component: core
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


I'd like a method that I can call to recursively walk through the sitemap data
structure - probably some sort of finite state automaton stuff. At the Cocoon
GetTogether, Sylvain suggested that this might actually be quite easy.

I'd like to see whether I can visualize the sitemap of a running server, i.e.
not just some small fraction of it, not process sitemap.xmap using XSLT. Perhaps
try to visualize it using hyperbolic trees of some sort.

Re: GT2004 was brilliant

[Ugo Cei]

Il giorno 15/ott/04, alle 12:04, Gianugo Rabellino ha scritto:
Any chance you can "just" iDVD it for now with just separate chapters
per session? I know this would mean a hefty download, but isn't this
why bittorrent is there? Others then might jump in and postproduce the
sessions. But I would certainly like having DVD quality video for the
GT.
I would certainly like this better that last year's videos, whose 
quality was certainly not optimal for, say, projecting them on a large 
screen to your office colleagues (this is not to blame Stefano, who 
probably did the best possible job, given the desired compression 
levels).

I am just wondering: will we be able to fit everything in a single DVD?
Ugo
--
Ugo Cei - http://beblogging.com/


smime.p7s
Description: S/MIME cryptographic signature

Re: GT2004 was brilliant

[Ugo Cei]

Il giorno 15/ott/04, alle 12:04, Gianugo Rabellino ha scritto:
Any chance you can "just" iDVD it for now with just separate chapters
per session? I know this would mean a hefty download, but isn't this
why bittorrent is there? Others then might jump in and postproduce the
sessions. But I would certainly like having DVD quality video for the
GT.
I would certainly like this better that last year's videos, whose 
quality was certainly not optimal for, say, projecting them on a large 
screen to your office colleagues (this is not to blame Stefano, who 
probably did the best possible job, given the desired compression 
levels).

I am just wondering: will we be able to fit everything in a single DVD?
Ugo
--
Ugo Cei - http://beblogging.com/


smime.p7s
Description: S/MIME cryptographic signature

Re: GT2004 was brilliant

[Gianugo Rabellino]

On Fri, 15 Oct 2004 09:56:16 +0100, Jeremy Quinn
<[EMAIL PROTECTED]> wrote:
> 
> On 14 Oct 2004, at 17:31, Jeremy Quinn wrote:
> 
> > We videoed all of the sessions, processing it all will take a while, I
> > hope to begin uploading one per day from tomorrow.
> >
> 
> Having spent a long night of compressor-hell, the timescale above may
> prove to be a bit optimistic.
> 
> Working with Steven's introduction, I have yet to reproduce the
> combination of image quality, image size, file size, frame rate etc.
> that Stefano achieved.

Any chance you can "just" iDVD it for now with just separate chapters
per session? I know this would mean a hefty download, but isn't this
why bittorrent is there? Others then might jump in and postproduce the
sessions. But I would certainly like having DVD quality video for the
GT.

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

Invalid content length, revisited

[Rogier Peters]

Guys,

On 18/5 Joerg asked a question about invalid content length errors[1] due to
readers. There is also a bug that is somewhat related[2], but it seems to be
WONTFIX.

I have the following case :

  generatorreader
  |  |
  validator .. dtd
  |
  serializer

In this case the reader sets the content-length, and the serializer doesn't. So
if the length of the serializer's output is greater than that of the dtd, output
is incomplete.
Althoug a quick fix is not to get the dtd through a reader, I'm sure there are
cases where that isn't a solution. 
I didn't post this as a bug, yet, because I am not sure whether this is just
unintended use of the reader. 
Also, I can't quite get my mind around what's the best way to solve this. Joerg
suggested in his original mail[1] to build some awareness in to the reader to
see if it is called as a cocoon-source or not. Another possible solution would
be setting content-length from all serializers, although Carsten suggests in the
closing of the bug that content-length can not be set repeatedly. 

OTOH I tried to reproduce this behaviour by getting an XSL through a reader,
like so:

  

  

  



  

But apparently the xsl-transformer doesn't like that.

Any thoughts?

Rogier

[1] http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=108491735914313&w=2
[2] http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17370

DO NOT REPLY [Bug 31649] - [Patch] Flowscript: Switch to re-implementation of official Rhino

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=31649

[Patch] Flowscript: Switch to re-implementation of official Rhino





--- Additional Comments From [EMAIL PROTECTED]  2004-10-15 09:15 ---
Could you specify what exectly are those other isues?

Re: Daisy as CMS: why don't use JDO?

[Luca Garulli]

On Fri, 15 Oct 2004 10:48:00 +0200, Sylvain Wallez <[EMAIL PROTECTED]> wrote:

> "hate"? I haven't seen such a strong word.

:-D

> >My initial question was just a suggestion to discuss technically the
> >use of JDO inside Daisy / Cocoon galaxy.
> 
> You really should see Cocoon as a very open integration platform. Do you
> know other systems that can connnect to big SAP systems and at the same
> time play dynamically-generated music?

I'm working with Cocoon for a big customer. So I know its powerful ;-)

> >but maybe sometimes
> >it's better to know better a technology rather than reinvent the well
> >every time and after some time realize that it was better to use a
> >tool for that purpose... the history teach.
> 
> Don't worry. People here know the existence of JDO. If they chose
> another route, that is their choice, that they made after having
> carefully weighted the pros and cons, regarding their needs and environment.

By some responses in this thread I understand that they don't know JDO.

bye,
Luca Garulli
OrienTechnologies.com
(the light ODBMS, all in one JDO solution)

Re: GT2004 was brilliant

[Jeremy Quinn]

On 14 Oct 2004, at 17:31, Jeremy Quinn wrote:
We videoed all of the sessions, processing it all will take a while, I 
hope to begin uploading one per day from tomorrow.

Having spent a long night of compressor-hell, the timescale above may 
prove to be a bit optimistic.

Working with Steven's introduction, I have yet to reproduce the 
combination of image quality, image size, file size, frame rate etc. 
that Stefano achieved.

Am persevering 
regards Jeremy

  If email from this address is not signed
IT IS NOT FROM ME
Always check the label, folks !



smime.p7s
Description: S/MIME cryptographic signature

Re: Daisy as CMS: why don't use JDO?

[Sylvain Wallez]

Luca Garulli wrote:
On Thu, 14 Oct 2004 23:40:44 +0200, Sylvain Wallez <[EMAIL PROTECTED]> wrote:
 

Although off-topic, Daisy is part of the Cocoon galaxy. So more
importantly, what the heck does this list has to do with JDO
evangelisation? That's what this somewhat useless thread was all about.
Luca, although you evidently love JDO, this list is about Cocoon.
   

Surely I love JDO ;-) but here someone hate it !!! :-D
 

"hate"? I haven't seen such a strong word.
My initial question was just a suggestion to discuss technically the
use of JDO inside Daisy / Cocoon galaxy.
 

Object persistency is not a primary concern of Cocoon, but one of the 
associated business logic. So although Cocoon can provide examples or 
advices on how to cleanly integrate such or such persistency system, it 
will never promote one.

You really should see Cocoon as a very open integration platform. Do you 
know other systems that can connnect to big SAP systems and at the same 
time play dynamically-generated music?

I don't want to make proselytes here about JDO,
But you evidently do.
but maybe sometimes
it's better to know better a technology rather than reinvent the well
every time and after some time realize that it was better to use a
tool for that purpose... the history teach.
 

Don't worry. People here know the existence of JDO. If they chose 
another route, that is their choice, that they made after having 
carefully weighted the pros and cons, regarding their needs and environment.

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

Re: Sales Materials

[Bertrand Delacretaz]

Le 15 oct. 04, à 10:18, Niclas Hedhman a écrit :
...Today you got the http://cocoon.apache.org/link/livesites-2.1.html. 
Can't this
concept be extended?..
I like the idea - we could complete the page with some key points about 
the various sites mentioned.

And having this on the "official" site instead of the wiki makes 
filtering out what is published easier.

-Bertrand


smime.p7s
Description: S/MIME cryptographic signature

Re: Daisy as CMS: why don't use JDO?

[Luca Garulli]

On Thu, 14 Oct 2004 23:40:44 +0200, Sylvain Wallez <[EMAIL PROTECTED]> wrote:
>
> Although off-topic, Daisy is part of the Cocoon galaxy. So more
> importantly, what the heck does this list has to do with JDO
> evangelisation? That's what this somewhat useless thread was all about.
> 
> Luca, although you evidently love JDO, this list is about Cocoon.

Surely I love JDO ;-) but here someone hate it !!! :-D

My initial question was just a suggestion to discuss technically the
use of JDO inside Daisy / Cocoon galaxy.

I don't want to make proselytes here about JDO, but maybe sometimes
it's better to know better a technology rather than reinvent the well
every time and after some time realize that it was better to use a
tool for that purpose... the history teach.

bye,
Luca Garulli
OrienTechnologies.com
(the light ODBMS, all in one JDO solution)