date:20040308

Christopher Oliver wrote:

Steven Noels wrote:

On 08 Mar 2004, at 23:09, Stefano Mazzocchi wrote:

unless donated by the well-known friendly-neightbor-organization 
directly, that is.


I took the plunge and started talking. See my other mail.




Hopefully that will lead to something productive. However, it still 
won't solve the Websphere/Weblogic issue.

Assuming that sooner or later continuations are added to standard 
Rhino (whether it moves to Apache or not), to ensure that the proper 
version is used by Cocoon we would need to refactor the flow and woody 
/forms and jxtemplate components to use an isolated version of Rhino 
that is loaded by its own class loader (that means all references to 
org.mozilla.javscript.* will need to be removed from Cocoon code and 
the corresponding functionality encapsulated with interfaces that  
delegate to the isolated version of Rhino).

So, somewhat ironically, having a forked version of Rhino actually 
makes solving the Websphere/Weblogic problem much easier (we can 
simply rename the packages).


Just curious: what is Rhino used for in WL and WS? Is it used in the 
application space, or in the container space. In other words, can using 
the ParanoidCocoonServlet solve the problem?

Sylvain

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

[CVS-problem] pre-commit check failed

2004-03-08 Thread Reinhard Pötz

As you may saw I wanted to commit the results of renaming Woody to 
CocoonForms but when I commit a file I get the error message "pre-commit 
check failed". Any ideas what's going on here? (I've already checked 
whether the license is okay, if I use Unix-style line feeds)

--
Reinhard

Re: AW: [RT] Forwarding of internal pipeline calls

Marco Rolappe wrote:

well, I'll stop now...
noo, don't :-)

as sinful as it might seem around here, I have been thinking about a 
non-XML version of a sitemap syntax and it is surprisingly similar to 
what you described.

DISCLAIMER: before people run off to their bosses and pull the emergency 
break, remember: this is an RT, this is the place where crazy new ideas 
are discussed and distroyed... what remains standing might be the next 
big innovation in the field ;-)

--
Stefano.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [VOTE] Rename Rhino-with-continuations packages

2004-03-08 Thread Christopher Oliver

Steven Noels wrote:

On 08 Mar 2004, at 23:09, Stefano Mazzocchi wrote:

unless donated by the well-known friendly-neightbor-organization 
directly, that is.


I took the plunge and started talking. See my other mail.




Hopefully that will lead to something productive. However, it still 
won't solve the Websphere/Weblogic issue.

Assuming that sooner or later continuations are added to standard Rhino 
(whether it moves to Apache or not), to ensure that the proper version 
is used by Cocoon we would need to refactor the flow and woody /forms 
and jxtemplate components to use an isolated version of Rhino that is 
loaded by its own class loader (that means all references to 
org.mozilla.javscript.* will need to be removed from Cocoon code and the 
corresponding functionality encapsulated with interfaces that  delegate 
to the isolated version of Rhino).

So, somewhat ironically, having a forked version of Rhino actually makes 
solving the Websphere/Weblogic problem much easier (we can simply rename 
the packages).

--
Chris

Re: cvs commit: cocoon-2.1 status.xml

Vadim Gritsenko wrote:

[EMAIL PROTECTED] wrote:

  public void characters(char[] ch, int start, int length) {
if (ch.length > 0 && start >= 0 && length > 1) {
 -String text = new String(ch, start, length);
  if (elementStack.size() > 0) {
  IndexHelperField tos = (IndexHelperField) 
elementStack.peek();
 -tos.appendText(text);
 +tos.appendText(ch, start, length);
  }
 -bodyText.append(text);
 +bodyText.append(' ');
 +bodyText.append(ch, start, length);
  }
  }

What will happen when "keyword" text is streamed as two characters 
events, "key" and "word"? I think it will become "key word", and 
indexing will break.

IIUC, idea was to add a space in between tags, i.e. so 
sometext is not indexed as "sometext". If that's 
correct, then better fix would be to add space only if boolean flag 
had_start_or_end_element_in_between_char_events set.


Joerg?

Vadim

DO NOT REPLY [Bug 26997] - Encoding in HTTP-Header is not set by Serializer

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

Encoding in HTTP-Header is not set by Serializer

[EMAIL PROTECTED] changed:

   What|Removed |Added

   Severity|Normal  |Major
   Priority|Other   |High



--- Additional Comments From [EMAIL PROTECTED]  2004-03-09 02:12 ---
another thread: http://marc.theaimsgroup.com/?t=10765019024&r=1&w=4

Cocoon should set the header including the charset.

namespace for FilterTransformer (was: DO NOT REPLY [Bug 27301] - FilterTransformer: Generates not matching block tags)

On 09.03.2004 01:48, [EMAIL PROTECTED] wrote:

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

FilterTransformer: Generates not matching block tags
...

Maybe we should put block in its own namespace ...
What do you think about this? The RoleFilterT extending FilterT already 
has its own namespace "http://apache.org/cocoon/role-filter/1.0";. So 
putting the block element into "http://apache.org/cocoon/filter/1.0"; or 
is this namespace already in use?

Joerg

DO NOT REPLY [Bug 27432] - Malformed HTTP headers (debug information in Parameters object)

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

Malformed HTTP headers (debug information in Parameters object)

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED



--- Additional Comments From [EMAIL PROTECTED]  2004-03-09 01:00 ---
This means the bug is fixed, isn't it?

DO NOT REPLY [Bug 27301] - FilterTransformer: Generates not matching block tags

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

FilterTransformer: Generates not matching block tags

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED



--- Additional Comments From [EMAIL PROTECTED]  2004-03-09 00:59 ---
Thanks for spotting. Please cross-test and close the bug afterwards.

Re: [VOTE] Rename Rhino-with-continuations packages

Steven Noels wrote:

On 08 Mar 2004, at 23:09, Stefano Mazzocchi wrote:

unless donated by the well-known friendly-neightbor-organization 
directly, that is.


I took the plunge and started talking. See my other mail.
Thanks for doing this Steven, it is truely appreciated from my part.

--
Stefano.


smime.p7s
Description: S/MIME Cryptographic Signature

DO NOT REPLY [Bug 27301] - FilterTransformer: Generates not matching block tags

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

FilterTransformer: Generates not matching block tags





--- Additional Comments From [EMAIL PROTECTED]  2004-03-09 00:48 ---
I get another result. That might be due to a more intelligent Xalan (finally - I
often saw results like above):


http://apache.org/cocoon/include/1.0";>
  http://apache.org/cocoon/include/1.0"; id="1">




  


Can you try it with Xalan 2.6?

Though I don't like the output above. How do you want to match on block later on
in the pipeline if you only can guess in which namespace it is?

Therefore I will commit a patch so that the result looks like the followign:


http://apache.org/cocoon/include/1.0";>
  




  


Maybe we should put block in its own namespace, but first I will patch this thing.

Joerg

DO NOT REPLY [Bug 27275] - xsl:sort not sorting correctly

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

xsl:sort not sorting correctly





--- Additional Comments From [EMAIL PROTECTED]  2004-03-09 00:41 ---
Good to hear. No, I tested it with latest Cocoon from CVS.

DO NOT REPLY [Bug 27275] - xsl:sort not sorting correctly

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

xsl:sort not sorting correctly

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|RESOLVED|CLOSED



--- Additional Comments From [EMAIL PROTECTED]  2004-03-09 00:29 ---
Found the problem I think. 
The problem seems to be 2.1.2's endorsed libraries. Cocoon 2.1.2 has xalan-
2.5.1.jar,xercesImpl-2.5.0.jar and xml-apis.jar.

I took the updated libraries from Cocoon 2.1.4: xalan-2.5.2.jar and xercesImpl-
2.6.1.jar. The sort() funciton started to work. 

Jorg, are you using 2.1.2?  

Khanh

DO NOT REPLY [Bug 26445] - NPE at o.a.xalan.transformer.TransformerImpl.java:1497

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

NPE at o.a.xalan.transformer.TransformerImpl.java:1497





--- Additional Comments From [EMAIL PROTECTED]  2004-03-09 00:27 ---
Hi Joerg, 
I want to apologize, to not test and respond further to my own problem. I'm too 
busy on other fronts. I did circumvent the issue for myself, by not following 
any links in the offline generation and adding any URL myself (and copying all 
other resources by hand). But I try to do my best to improve these great 
products cocoon and xalan. 
 
Having a QA background, I can tell you the Xalan 2.6.0 patch does not solve the 
issue, but what to do about the NPE. 
 
Vector vars = sroot.getVariablesAndParamsComposed(); 
int i = vars.size(); 
 
The function getVariablesAndParamsComposed(); must have a contract, either 
saying it returns sometimes null, then the rest of vars.size() should not be 
executed. Or it has a contract that always ensures the existence of this 
Vector, than it should behave like this. I guess a new Vector could should be 
initialized by the (access)-method getVariablesAndParamsComposed(); instead of 
returning null 9or otherwise ensure in that object it is always created, 
because I would not know what to do in this setParameter() method otherwise --> 
would have to throw an exception with no recoverable meaning (the internal 
error type :-(( ). 
 
Again, I'm sorry to let you do all the debugging here. Would you be able to 
propose this change to the Xalan people or open an appropriate case there? I 
could do it to, but you have now dug into the code.  
 
Thanks, I'd really appreciate it. However I won't be angry if you don't. 
 
Kaj 
P.S.: I do not agree with "The NPE is a runtime exception, so there is no must 
of handling it.". An NPE should never occur and sometimes it is very helpful to 
handle such exceptions, to deliver some context in an error message (like what 
parameter is set and what is the value - which might give me a starting point 
to blame my style-sheet) and then re-throw the exception. I agree with the rest 
of your comment that this is difficult, as it is another library that crashes. 
But it would be a defensive programming strategy. Sorry for the lecture, may be 
I have worked in QA for too long? 
 
--- 
Do you have a Plan-B? 
http://www.conficio.com/

DO NOT REPLY [Bug 27275] - xsl:sort not sorting correctly

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

xsl:sort not sorting correctly

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||WORKSFORME



--- Additional Comments From [EMAIL PROTECTED]  2004-03-09 00:21 ---
Hello Khanh Vo,

I tested exactly your stylesheet and it works for me, I get the output


  
one
  
  
two
  
  
three
  


with the one and only template in the stylesheet:

  

  
 

  

  

  

  

Now I can only start with wild guessing: Are you sure the for-each is executed?
If you get exactly the output below I guess the template containing the for-each
is not accessed at all. Maybe you can solve this issue on a XSLT list like
Mulberry's: http://www.mulberrytech.com/xsl/xsl-list/.

Joerg

Re: regarding JCS usage...



Joerg Heinicke wrote:

On 09.03.2004 00:16, Corin Moss wrote:

As I said before, the advantage of JCS is that it provides an interface
to many different store types - which greatly enhances the functionality
of Cocoon.  I don't think there's much point in developing yet another
cache library when there are lots out there that do the job well :)  (I
guess that's why JISP was chosen to start with.)


That's indeed the thing that I want to see: the abstraction of 
caching/store through a cache layer. Therefore we should not add EHCache 
or any other to our CVS, but add it to JCS, so that we can access it 
through the JCS interfaces.

We do have that of course with the excalibur Store service interface, 
albeit a JSR compliant one would be preferable. Still, plugging in your 
caching product of choice is a trivial matter.

I'm do wonder why the EHCache guys decided to fork instead of contribute 
to JCS.

--
Unico

Re: regarding JCS usage...



Stefano Mazzocchi wrote:
Corin Moss wrote:


Would it be worth polling the users and dev lists to get something of a
"wish-list" for store functionality?


why don't we go back and see what is the problem we are trying so solve 
instead of branching off like crazy?

Admittedly, I was a little bit quick with checking in the EHCache store
implementation. And I doubt we should consider it to be a serious
candidate for our needs. Their being a rather obscure fork and semi
subproject of a reknowned BSD incompatible software project and all. I'd
realy love to use JCS instead.
OTOH it may help to allow people to compare some options and get some
test feedback.
we must store lots of objects persistently and retrieve them fast.

let's solve that issue first.

I think that a balanced btree implemented in a file system is the 
easiest/most efficient way to go.

I know very little about this matter so I'll leave that to others. I
would however obviously prefer to use something external instead of
having to maintain it ourselves.
--
Unico

DO NOT REPLY [Bug 27260] - Stackoverflow using xslt from subsitemap with cocoon://-protocol

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

Stackoverflow using xslt from subsitemap with cocoon://-protocol

[EMAIL PROTECTED] changed:

   What|Removed |Added

   Severity|Normal  |Major
 Status|NEW |ASSIGNED



--- Additional Comments From [EMAIL PROTECTED]  2004-03-09 00:12 ---
I can confirm it. I like especially the fact that it works with cocoon:/, but
not with cocoon://.

Mr. "Internal" Carsten :) Do you have any idea? If it is not in 2.1.3 (what I
don't have tested), but in 2.1.4, it's a regression.

RE: regarding JCS usage...

2004-03-08 Thread Ralph Goers

If JCS is just an abstraction layer I wonder why it has the problems
identified with it?  I would expect that it wouldn't be difficult to plug in
EHCache to JCS if that is the case.

Ralph

 -Original Message-
From:   Joerg Heinicke [mailto:[EMAIL PROTECTED] 
Sent:   Monday, March 08, 2004 3:56 PM
To: [EMAIL PROTECTED]
Subject:Re: regarding JCS usage...

On 09.03.2004 00:16, Corin Moss wrote:

> As I said before, the advantage of JCS is that it provides an interface
> to many different store types - which greatly enhances the functionality
> of Cocoon.  I don't think there's much point in developing yet another
> cache library when there are lots out there that do the job well :)  (I
> guess that's why JISP was chosen to start with.)

That's indeed the thing that I want to see: the abstraction of 
caching/store through a cache layer. Therefore we should not add EHCache 
or any other to our CVS, but add it to JCS, so that we can access it 
through the JCS interfaces.

Joerg

Re: regarding JCS usage...

On 09.03.2004 00:16, Corin Moss wrote:

As I said before, the advantage of JCS is that it provides an interface
to many different store types - which greatly enhances the functionality
of Cocoon.  I don't think there's much point in developing yet another
cache library when there are lots out there that do the job well :)  (I
guess that's why JISP was chosen to start with.)
That's indeed the thing that I want to see: the abstraction of 
caching/store through a cache layer. Therefore we should not add EHCache 
or any other to our CVS, but add it to JCS, so that we can access it 
through the JCS interfaces.

Joerg

RE: [Paginator Sample] ClassCastException

2004-03-08 Thread Corin Moss

Hiya,

This might be unrelated to the Paginator itself.

I noticed last night that when I used the JCSTransientStore I got a
class cast exception when trying to write to the transient cache.  I
haven't had a chance to look at this more - but this might be it.
Although I'd imagine that it would manifest in more ways than just this.

Anyone else had this?

-Original Message-
From: Joerg Heinicke [mailto:[EMAIL PROTECTED]
Sent: Tuesday, 9 March 2004 12:45 p.m.
To: [EMAIL PROTECTED]
Subject: Re: [Paginator Sample] ClassCastException

On 08.03.2004 22:30, Alex Romayev wrote:

> Hi,
>
> Paginator transformer seems to be broken in CVS.  The
> sample produces: java.lang.ClassCastException.

Sorry, but I can not confirm it as it works for me.

Joerg

CAUTION: This e-mail and any attachment(s) contains information
that is intended to be read only by the named recipient(s). It
may contain information that is confidential, proprietary or the
subject of legal privilege. This information is not to be used by
any other person and/or organisation. If you are not the intended
recipient, please advise us immediately and delete this e-mail
from your system. Do not use any information contained in it.

For more information on the Television New Zealand Group, visit
us online at http://www.tvnz.co.nz

DO NOT REPLY [Bug 25113] - [Roadmap] CocoonForms - FUTURE releases

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

[Roadmap] CocoonForms - FUTURE releases

[EMAIL PROTECTED] changed:

   What|Removed |Added

  BugsThisDependsOn||27147

DO NOT REPLY [Bug 27147] - Woody field styling: selection lists with optgroups

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

Woody field styling: selection lists with optgroups

[EMAIL PROTECTED] changed:

   What|Removed |Added

OtherBugsDependingO||25113
  nThis||
  Component|Samples |CocoonForms

Re: [Paginator Sample] ClassCastException

On 08.03.2004 22:30, Alex Romayev wrote:

Hi,

Paginator transformer seems to be broken in CVS.  The
sample produces: java.lang.ClassCastException.
Sorry, but I can not confirm it as it works for me.

Joerg

DO NOT REPLY [Bug 27020] - [Patch] Grayscale and RGB tinting added to ImageReader

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

[Patch] Grayscale and RGB tinting added to ImageReader

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED



--- Additional Comments From [EMAIL PROTECTED]  2004-03-08 23:37 ---
Patch applied to 2.1 and 2.2, and samples added for showing the functionality.
Thanks very much for your contribution. The next time please avoid tabs. I also
had to fix a little bug for grayscale only setting, following statement missed
the test for the grayscalefilter:

if (width > 0 || height > 0 || null != colorFilter) {

and the original image was delivered.

Would be good if you can test it too and close the bug afterwards.

Thanks,

Joerg

Windows only defect using form tag with enctype set

2004-03-08 Thread depub2

Defect:

The following defect occurs ONLY on the MS windows platform,
it does NOT occur on the linux platform.
Both platforms were setup with tomcat 4.1.29, and cocoon 2.1.4.

On the windows platorm, a woody form will lose it's data when
the enctype="multipart/form-data" is specified in the form
template, for example:



This enctype is required for proper operation of the upload
widget.

To see the problem for yourself, on a windows based server, simply add
enctype="multipart/form-data"
to the form tag (see above) in
~/cocoon/samples/woody/forms/form2_template.xml
and then run the XML Binding sample.

In the test case, (very similar to the XML Binding demo), a
flowscript which uses the showForm() function does not exit.

It is believed that the showForm() call in the flowscript
never exits because validation always fails because we have a required field
(which is filled in with valid data by the user) and that field is null
because the widget is not being updated with the request data because of
this defect when enctype="multipart/form-data".

Again, this problem only occurs on the MS Windows platform
and works fine on a linux platform. The problem does not appear to be
browser dependent.

RE: regarding JCS usage...

2004-03-08 Thread Ralph Goers

If I understand the issue correctly...  We have purchased Tangosol Coherence
so if there is a way that whatever Cocoon uses is pluggable enough that a
third party product could be used instead of a light-weight solution (i.e.
to provide clustering support) that would be great.  I believe Coherence is
Jcache compliant so obviously I'd love to something compliant with that.

Ralph

 -Original Message-
From:   Corin Moss [mailto:[EMAIL PROTECTED] 
Sent:   Monday, March 08, 2004 1:03 PM
To: [EMAIL PROTECTED]
Subject:RE: regarding JCS usage...

Hi,

I agree that this is bad news.

Before a decision is made one way or another, it might be a good idea to
agree on minimal functionality required of a store.  I'm not overly in
favour of a true light-weight cache like EHCache being the only
supported caching mechanism.  In my usage of JCS I intend to utilise the
distributed caching functionality, and see that this is a really big
plus of JCS. 

Perhaps we need to investigate having several options for caching which
are actively supported?  This would allow users like myself who have
Cocoon spread over multiple servers to use the advanced functionality of
the distributed cache.  Perhaps something light-weight like EHCache or
similar could be used by default? Provided of course, that both can be
actively supported ;)

Would it be worth polling the users and dev lists to get something of a
"wish-list" for store functionality?

WDYT?

Corin

-Original Message-
From: Unico Hommes [mailto:[EMAIL PROTECTED]

Sent: Tuesday, 9 March 2004 5:21 a.m.
To: [EMAIL PROTECTED]
Subject: Re: regarding JCS usage...

Marco Rolappe wrote:

>I stumbled over the following thread in the hibernate forum about JCS
>problems:
>
>http://forum.hibernate.org/viewtopic.php?t=924937
>
>
>thought it might be useful to know before going JCS. there's also an

>alternative (EHCache) mentioned.
> 

>

Hmm, more bad news about JCS. It's beginning to look less and less

likely candidate for our caching needs. I've been talking with a guy on

the JCS users list who has created a patch for the JCS shutdown bug I

mentioned earlier. Hopefully this issue will be resolved soon and I can

start doing some heavy testing to see for myself.

Unico

CAUTION: This e-mail and any attachment(s) contains information
that is intended to be read only by the named recipient(s). It
may contain information that is confidential, proprietary or the
subject of legal privilege. This information is not to be used by
any other person and/or organisation. If you are not the intended
recipient, please advise us immediately and delete this e-mail
from your system. Do not use any information contained in it.

For more information on the Television New Zealand Group, visit
us online at http://www.tvnz.co.nz

RE: regarding JCS usage...

2004-03-08 Thread Corin Moss

Hiya,

I don't think that anyone disagrees that the issue of utmost importance
for the Store is fast and simple. The work done to date on JCS, and now
EHCache highlights that there are some fairly well developed caching
systems out there.  Most of them fulfil the first requirement, some of
them don't necessarily meet the second ;)

As I said before, the advantage of JCS is that it provides an interface
to many different store types - which greatly enhances the functionality
of Cocoon.  I don't think there's much point in developing yet another
cache library when there are lots out there that do the job well :)  (I
guess that's why JISP was chosen to start with.)

As I understand it, the problem that we're trying to solve was initially
one of license, and then secondly a reliability issue within the version
of JISP being used.  The license issue precludes upgrading the version
of JISP used, and I wouldn't think that supporting the 2.51 version of
JISP would be a particularly attractive idea :)

Hopefully the various caching packages being looked at solve both
problems.

Corin

-Original Message-
From: Stefano Mazzocchi [mailto:[EMAIL PROTECTED]
Sent: Tuesday, 9 March 2004 11:50 a.m.
To: [EMAIL PROTECTED]
Subject: Re: regarding JCS usage...

Corin Moss wrote:

> Would it be worth polling the users and dev lists to get something of
> a "wish-list" for store functionality?

why don't we go back and see what is the problem we are trying so solve
instead of branching off like crazy?

we must store lots of objects persistently and retrieve them fast.

let's solve that issue first.

I think that a balanced btree implemented in a file system is the
easiest/most efficient way to go.

--
Stefano.

CAUTION: This e-mail and any attachment(s) contains information
that is intended to be read only by the named recipient(s). It
may contain information that is confidential, proprietary or the
subject of legal privilege. This information is not to be used by
any other person and/or organisation. If you are not the intended
recipient, please advise us immediately and delete this e-mail
from your system. Do not use any information contained in it.

For more information on the Television New Zealand Group, visit
us online at http://www.tvnz.co.nz

Re: [VOTE] Rename Rhino-with-continuations packages

On 08 Mar 2004, at 23:09, Stefano Mazzocchi wrote:

unless donated by the well-known friendly-neightbor-organization 
directly, that is.
I took the plunge and started talking. See my other mail.


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

Cocoon's Rhino+continuations fork

(partly in reply to  
http://thread.gmane.org/gmane.comp.mozilla.devel.jseng/3038)

Dear all, more specifically Rhino devs,

the issue with Cocoon's Rhino fork seems to be appearing with  
increasing rate on both the Rhino and Cocoon mailing lists. While the  
discussion underneath remains strictly theoretical unless someone kicks  
in and starts fixing things, I'd like to iterate over a couple of  
thoughts and scenarios, if only as a means to start some common thread,  
maybe even consensus, and to better understand where we stand at ATM. I  
work with the ASF Cocoon project (ASF = Apache Software Foundation).

Cocoon has been investigating the use of continuations as a novel  
approach to web application development quite a while before the  
Rhino+cont fork. It were mainly Ovidiu Predescu and later on Chris  
Oliver who started this exploration, first using a Java-based Scheme  
interpreter, and then by refactoring Rhino in order to add  
continuations support to the interpreter core - this work was done by  
Chris.

Much of this work was done (undeliberately, as the Cocoon community  
needed some time to actually buy the concept) a bit under the radar of  
the Cocoon community, so it took us some time to fully realize that  
Chris' Rhino fork now sits firmly in the core of Cocoon, and that the  
fork situation is less optimal than it should be - most importantly  
from a legal and community perspective.

First of all, there's a legal aspect. While forking is an unevitable  
aspect of open source development, we do need to investigate whether it  
is legal at all to fork and (re)license Rhino+cont under an ASL2.0  
compatible license, in order to ship it with Cocoon.

This is troubled partly by the license status of Rhino itself. Upon  
personal investigation a while ago, I found some source files which  
where licensed using the NPL1.1  
(http://lxr.mozilla.org/mozilla/source/js/rhino/src/org/mozilla/ 
javascript/Context.java), while others used the newer MPL1.1  
(http://lxr.mozilla.org/mozilla/source/js/rhino/src/org/mozilla/ 
javascript/ClassCache.java). I think it is safe to state that the  
intended overall license of Rhino was the tri-license combo MPL 1.1/GPL  
2.0/LGPL 2.1 - which seems to be OK for redistribution as a library  
with an ASF project according to the unofficial ASF license FAQ @  
http://nagoya.apache.org/wiki/apachewiki.cgi?Licensing

IMHO, it would be nice if the license status of Rhino is cleared out by  
adding the correct license headers to the source files.

But we don't distribute the original Rhino version with Cocoon, we use  
the one hosted at cocoondev.org instead  
(http://cvs.cocoondev.org/cgi-bin/viewcvs.cgi/?cvsroot=rhino). So first  
of all, we need to find out whether this fork can be effectively  
licensed under an ASL2.0 compatible license (preferably the ASL license  
itself). For that, it needs a copyright holder, which doesn't exist  
ATM. One could think Chris is the logical choice as the copyright  
holder, but this might be preposterous: he indeed adapted the code,  
adding some good continuations juice to it, but didn't change the  
license headers. From what I understand from the email archives, he did  
had the intention to eventually merge stuff back into the official  
Rhino trunk, but found no time to do so in due time, and eventually was  
confronted with the situation that merging changes back in became much  
harder than a simple "cvs merge" effort. So the cocoondev.org  
Rhino+cont fork was born, without copyright holder and license, and  
coincidentally became a valuable core component of Cocoon.

Simply put, the clarification of the license status of Rhino would  
already learn us how to properly and legally fork Rhino for Cocoon's  
purposes. Alas, forking and changing package names seems to be the only  
easy way to move forward to address some urgent technical issues ATM:  
when running Cocoon inside the WebLogic container, which ships with the  
official Rhino library, our stuff clashes due to identical package  
names. But before blessing this fork by changing package names, we need  
to find out whether forking and relicensing Rhino under an ASL  
compatible license can be done at all (besides the copyright holder  
stuff, which we eventually might sort out on our own).

On the community perspective, it feels awkward to see a core feature of  
Cocoon depend on a single-person effort, as much as we appreciate the  
work of Chris. Upsofar, not many people joined him in his work, partly  
because the interest of most Cocoon developers lies in the web  
application framework spectrum rather than in language interpreters.  
I'm sure this situation is greatly different in the Rhino community.  
Also, we cannot simply put Chris' fork into Cocoon CVS since the  
development of language interpreters are not part of our mission. The  
use of continuations for webapp development however is becoming a core  
part of our operations, and Rhino seems

Re: regarding JCS usage...

Corin Moss wrote:


Would it be worth polling the users and dev lists to get something of a
"wish-list" for store functionality?
why don't we go back and see what is the problem we are trying so solve 
instead of branching off like crazy?

we must store lots of objects persistently and retrieve them fast.

let's solve that issue first.

I think that a balanced btree implemented in a file system is the 
easiest/most efficient way to go.

--
Stefano.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [VOTE] Rename Rhino-with-continuations packages

Steven Noels wrote:

On 08 Mar 2004, at 09:39, Reinhard Pötz wrote:

IIRC the argumentation was that Cocoon is about web publishing and web 
applications and not about programming language interpreters. So it 
should find a different place.


Exactly.

And a forked version of a well-known open source project of a 
friendly-neighbor-organization is very unlikely to be a welcome addition 
to the ASF stable.
unless donated by the well-known friendly-neightbor-organization 
directly, that is.

--
Stefano.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: First pass at Apache Wiki conversion

2004-03-08 Thread Upayavira

Upayavira wrote:

Antonio Gallardo wrote:

Upayavira dijo:
 

I've been working on converting the JSPWiki Cocoon wiki to MoinMoin
wiki. This will enable Cocoon to make use of Apache's Wiki farm.
  


Thanks fro your effort.

I already noted many pages are Orphaned:

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

Okay. That'll be because of some [] links that I haven't reformatted 
correctly, I suspect. I'll look into it.
Just fixed the RecentChanges problem I was having; It now works. So, 
apart from problems with the format conversion, the whole thing should 
hold together.

Regards, Upayavira

Re: [VOTE] Rename Rhino-with-continuations packages

Antonio Gallardo wrote:

Sorry, but, I am still -0. :-(
We are all open to better solutions, Antonio, but I personally see none. 
 It's not easy matter and forking is a painful thing, but we *must* do 
something.

If you have a better idea, I'm all ears. Keep in mind that along with 
the idea there must be committment to make it happen.

--
Stefano.


smime.p7s
Description: S/MIME Cryptographic Signature

RE: Experience with workflow at Hippo Webworks

Guido Casper <[EMAIL PROTECTED]> writes:

> 
> Hunsberger, Peter wrote:
> 
> > Guido Casper <[EMAIL PROTECTED]> writes:
> > 
> >>Hunsberger, Peter wrote:
> >>
> >>>For the end user I believe you always have to have modeling
> >>
> >>tools for
> >>
> >>>building work flow, the internal implementation should be
> >>
> >>completely
> >>
> >>>transparent; the first time I wrote GUI modeling tools for
> >>
> >>work flow
> >>
> >>>was 13 years ago (as a subcontractor for one of the major work flow
> >>>vendors) I don't believe the end user expectations have 
> >>
> >>declined since
> >>
> >>>then!
> >>
> >>I'm slowly starting to see an unsolvable conflict :-)
> >>
> >>Some are looking for a tool for developers and some are 
> looking for a
> >>tool for users. And I guess we'll be having a hard time 
> >>finding a single 
> >>tool being both.
> > 
> > 
> > I probably should have written "For the end user I believe 
> you always 
> > have to have the option of having modeling tools for building work 
> > flow...".  However, even as written originally I don't see 
> a conflict? 
> > I think it's not unreasonable to assume that the modeling 
> tools will 
> > be independent of Cocoon.
> > 
> > What is needed is a way to take the models, where ever they may 
> > originate, and implement them in Cocoon.  I think the only 
> way that's 
> > going to be generally possible is if Cocoon has some form 
> of template 
> > based model (even if it is internally used to generate a 
> script based 
> > implementation via some XSLT).
> 
> As I see it, a user tool can only work within a limited context. The 
> more you try to widen that context, the more the user tool starts 
> resembling my development tool (with a UI still intended for 
> end users) 
> and things get messy.

Hmm, maybe, but I don't think so; work flow modeling has been around for
a pretty long time now.  The modeling tool I worked on 12-13 years ago
is still being sold although I think that package was sold off and the
company we did the work for now sells something based on a different
code base.  The concepts, even then, where well defined, and there
wasn't much in the way of work flows you couldn't model.

> If my state objects and my action objects both are Avalon 
> components I 
> can easily build really complex conditions and state transferring 
> activities. I hardly see how these may be modelled in a user tool.
> 
> IMO modeling tools are great tools for communicating using 
> models being 
> reduced representations of the reality (isn't that what models are 
> about?) but are usually hard to use to generate the reality 
> out of the 
> model.

I believe model based engineering is going to be more and more common.
You may have heard of Model Driven Architecture?  Really, I think this
is Integrated CASE becoming a reality for all code... I do know that for
what we want to do we can't do it without tools that the business
analysts can use to build the work flows; there is no way that we can
involve developers for each of the 1000's of work flows that we will
building over the next couple of years.

> I think it would be a good idea to talk about these two
> -a user-oriented workflow tool with a modeling UI and a well defined 
> limited context
> -and a more flexible development tool
> 
> as separate implementations sharing the same interface.
> 

I don't see any reason to limit the user oriented tool?  Start from a
flexible underlying model, be aware that it should be possible to
generate the model form some GUI

Re: cvs commit: cocoon-2.1/legal ehcache-0.7.jar.license.txt

On 08.03.2004 22:36, [EMAIL PROTECTED] wrote:

unico   2004/03/08 13:36:26

  Added:   src/blocks/scratchpad/lib ehcache-0.7.jar
   src/blocks/scratchpad/java/org/apache/cocoon/components/store
EHStore.java
   legalehcache-0.7.jar.license.txt
  Log:
  start new experimental store implementation based on ehcache (http://ehcache.sourceforge.net/)
  
  Index: ehcache-0.7.jar.license.txt
...

   * 3. The end-user documentation included with the redistribution, if
   *any, must include the following acknowlegement:
   *   "This product includes software developed by the
   *Apache Software Foundation (http://www.apache.org/)."
...

   * 4. The names "The Jakarta Project", "Commons", and "Apache Software
   *Foundation" must not be used to endorse or promote products derived
   *from this software without prior written permission. For written
   *permission, please contact [EMAIL PROTECTED]
   *
   * 5. Products derived from this software may not be called "Apache"
   *nor may "Apache" appear in their names without prior written
   *permission of the Apache Group.
...

   * This software consists of voluntary contributions made by many
   * individuals on behalf of the Apache Software Foundation.  For more
   * information on the Apache Software Foundation, please see
   * .
Maybe someone should tell them that their license is somewhat unaccurate.

Joerg

Cocoon 2.1.5 (was: DO NOT REPLY [Bug 26456] - First Xindice DB is created in current directory (instead of WEB-INF?))

On 08.03.2004 22:23, [EMAIL PROTECTED] wrote:

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

First Xindice DB is created in current directory (instead of WEB-INF?)

--- Additional Comments From [EMAIL PROTECTED]  2004-03-08 21:23 ---
Umm, I guess I underestimated my workload, so there is no release before march
1st :-)
Status page mentions 1.1b4-dev, not 1.1b4, that's why there is no tag yet :-)
Again looked to fast - what's up today ...

When Cocoon 2.1.5 is due? I think we should make xindice 1.1b4 before Cocoon 2.1.5
Let's ask Carsten. The way to Cocoon Forms must of course be finished 
before the release and we should make sure the correct licenses or is 
the license issue completely finished (besides Woody JS)?

Joerg

[Paginator Sample] ClassCastException

2004-03-08 Thread Alex Romayev

Hi,

Paginator transformer seems to be broken in CVS.  The
sample produces: java.lang.ClassCastException.

Regards,
-Alex

DO NOT REPLY [Bug 26851] - [PATCH] LinkStatusGenerator, incorrect link content type check

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

[PATCH] LinkStatusGenerator, incorrect link content type check

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED



--- Additional Comments From [EMAIL PROTECTED]  2004-03-08 21:23 ---
Now patch applied - better control it twice :)

DO NOT REPLY [Bug 26456] - First Xindice DB is created in current directory (instead of WEB-INF?)

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

First Xindice DB is created in current directory (instead of WEB-INF?)





--- Additional Comments From [EMAIL PROTECTED]  2004-03-08 21:23 ---
Umm, I guess I underestimated my workload, so there is no release before march
1st :-)
Status page mentions 1.1b4-dev, not 1.1b4, that's why there is no tag yet :-)

When Cocoon 2.1.5 is due? I think we should make xindice 1.1b4 before Cocoon 2.1.5

Vadim

Re: regarding JCS usage...

Corin Moss wrote:

Hi,

I agree that this is bad news.

Before a decision is made one way or another, it might be a good idea to
agree on minimal functionality required of a store.  I'm not overly in
favour of a true light-weight cache like EHCache being the only
supported caching mechanism.  In my usage of JCS I intend to utilise the
distributed caching functionality, and see that this is a really big
plus of JCS. 
Minimal functionality for a store is pretty much that most of the 
methods are implemented and working (there may be some exceptions such 
as free() method). I don't think we need to exclude anything beyond that 
requirement.

Perhaps we need to investigate having several options for caching which
are actively supported?  This would allow users like myself who have
Cocoon spread over multiple servers to use the advanced functionality of
the distributed cache.  Perhaps something light-weight like EHCache or
similar could be used by default? Provided of course, that both can be
actively supported ;)
Sure, this is no problem. I mean we won't to throw out JCS integration 
again :-). Just a matter of what we ship as our default.

Would it be worth polling the users and dev lists to get something of a
"wish-list" for store functionality?
Dunno. If you think it will be useful.

--
Unico

DO NOT REPLY [Bug 26851] - [PATCH] LinkStatusGenerator, incorrect link content type check

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

[PATCH] LinkStatusGenerator, incorrect link content type check





--- Additional Comments From [EMAIL PROTECTED]  2004-03-08 21:12 ---
*damn* You got me - I should not look at so many different bugs in such a short
time :)

RE: regarding JCS usage...

2004-03-08 Thread Corin Moss

Hi,

I agree that this is bad news.

Before a decision is made one way or another, it might be a good idea to
agree on minimal functionality required of a store.  I'm not overly in
favour of a true light-weight cache like EHCache being the only
supported caching mechanism.  In my usage of JCS I intend to utilise the
distributed caching functionality, and see that this is a really big
plus of JCS. 

Perhaps we need to investigate having several options for caching which
are actively supported?  This would allow users like myself who have
Cocoon spread over multiple servers to use the advanced functionality of
the distributed cache.  Perhaps something light-weight like EHCache or
similar could be used by default? Provided of course, that both can be
actively supported ;)

Would it be worth polling the users and dev lists to get something of a
"wish-list" for store functionality?

WDYT?

Corin

-Original Message-
From: Unico Hommes [mailto:[EMAIL PROTECTED]
Sent: Tuesday, 9 March 2004 5:21 a.m.
To: [EMAIL PROTECTED]
Subject: Re: regarding JCS usage...

Marco Rolappe wrote:

>I stumbled over the following thread in the hibernate forum about JCS
>problems:
>
>http://forum.hibernate.org/viewtopic.php?t=924937
>
>
>thought it might be useful to know before going JCS. there's also an
>alternative (EHCache) mentioned.
> 
>

Hmm, more bad news about JCS. It's beginning to look less and less
likely candidate for our caching needs. I've been talking with a guy on
the JCS users list who has created a patch for the JCS shutdown bug I
mentioned earlier. Hopefully this issue will be resolved soon and I can
start doing some heavy testing to see for myself.

Unico

CAUTION: This e-mail and any attachment(s) contains information
that is intended to be read only by the named recipient(s). It
may contain information that is confidential, proprietary or the
subject of legal privilege. This information is not to be used by
any other person and/or organisation. If you are not the intended
recipient, please advise us immediately and delete this e-mail
from your system. Do not use any information contained in it.

For more information on the Television New Zealand Group, visit
us online at http://www.tvnz.co.nz

DO NOT REPLY [Bug 27484] - NPE - Cocoon attempts to resolve input source incorrectly

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

NPE - Cocoon attempts to resolve input source incorrectly





--- Additional Comments From [EMAIL PROTECTED]  2004-03-08 21:02 ---
The problem occurs when the flowscript attempts to load and use a package 
using code like:

var handler = Packages.org.stjude.ct.ui.login.LoginHandler();
logonOk = handler.logon( cocoon );

If running expanded we see that the compile method in CompilingClassLoader 
attempts to compile:

org
org.stjude
org.stjude.ct
org.stjude.ct.ui
org.stjude.ct.ui.login

sequentially.  Forcing this method to always throw a "ClassNotFound" exception 
allows the code to work normally (at the expense of disabling the ability to 
dynamically compile Java classes for the flow).

DO NOT REPLY [Bug 26851] - [PATCH] LinkStatusGenerator, incorrect link content type check

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

[PATCH] LinkStatusGenerator, incorrect link content type check





--- Additional Comments From [EMAIL PROTECTED]  2004-03-08 21:01 ---
yes, objection ;-) the content type doesn't *always* contain the charset,
depends on the servlet container it seems.

so, just check 'em both.

Re: cvs commit: cocoon-2.1/src/blocks/eventcache/java/org/apache/cocoon/caching/impl StoreEventRegistryImpl.java DefaultEventRegistryImpl.java



Joerg Heinicke wrote:
Unico Hommes  hippo.nl> writes:


Hmm, but it seems Jisp is doing the bad thing again. Upon storage it 
keeps saying:

ERROR   (2004-02-29) 14:23.34:294   [core.store.persistent] 
(Unknown-URI) Unknown-thread/AbstractJispFilesystemStore: store(..): 
Exception
java.io.IOException: Bad file descriptor
	at java.io.RandomAccessFile.length(Native Method)




Not having closely followed the Jisp bug thread. Is this the known issue?


Charles Yates has added a bug
(http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26932) with the same
stacktrace and he wrote as summary 'DefaultPersistentStore disposed before
DefaultStore on shutdown'. If that's the reason it shall be easy to fix, shall
it not? Though it's a really strange error message for an access to an already
disposed object. Had anybody a look on it? Maybe it would be interesting where
he get his impression from? Maybe he is listening ... ?
It's very well possible that that is the reason though. I recently 
noticed that this was happening also.

The problem I encountered was that some components (such as DefaultStore 
I presume - and StoreEventCacheRegistry in the case I was looking at) 
use the persistent store upon disposal. Now if the 
DefaultPersistentStore is already disposed this could cause problems.

Unfortunately I don't see an easy solution ATM since AFAIK ECM doesn't 
provide control over shutdown order (Fortress does BTW).

Anyone any ideas?

--
Unico

DO NOT REPLY [Bug 26963] - Jisp/ JDK 1.5 b1/ java.io.StreamCorruptedException

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

Jisp/ JDK 1.5 b1/ java.io.StreamCorruptedException

[EMAIL PROTECTED] changed:

   What|Removed |Added

Summary|Problem with jdk1.5 beta1   |Jisp/ JDK 1.5 b1/
   ||java.io.StreamCorruptedExcep
   ||tion



--- Additional Comments From [EMAIL PROTECTED]  2004-03-08 20:38 ---
Don't we have already enough problems with Jisp :)

Re: cvs commit: cocoon-2.1/src/blocks/eventcache/java/org/apache/cocoon/caching/impl StoreEventRegistryImpl.java DefaultEventRegistryImpl.java

Unico Hommes  hippo.nl> writes:

> Hmm, but it seems Jisp is doing the bad thing again. Upon storage it 
> keeps saying:
> 
> ERROR   (2004-02-29) 14:23.34:294   [core.store.persistent] 
> (Unknown-URI) Unknown-thread/AbstractJispFilesystemStore: store(..): 
> Exception
> java.io.IOException: Bad file descriptor
>   at java.io.RandomAccessFile.length(Native Method)

> Not having closely followed the Jisp bug thread. Is this the known issue?

Charles Yates has added a bug
(http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26932) with the same
stacktrace and he wrote as summary 'DefaultPersistentStore disposed before
DefaultStore on shutdown'. If that's the reason it shall be easy to fix, shall
it not? Though it's a really strange error message for an access to an already
disposed object. Had anybody a look on it? Maybe it would be interesting where
he get his impression from? Maybe he is listening ... ?

Joerg

DO NOT REPLY [Bug 26851] - [PATCH] LinkStatusGenerator, incorrect link content type check

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

[PATCH] LinkStatusGenerator, incorrect link content type check





--- Additional Comments From [EMAIL PROTECTED]  2004-03-08 20:26 ---
But then just

if (content_type.startsWith(linkContentType + ";")) ...

is simpler. Any objections against applying it?

RE: [SUMMARY] From Woody to Cocoon Forms 1.0

Pier Fumagalli <[EMAIL PROTECTED]> writes:

> > The way the JVM classloading mechanism is designed (well, the code
> > verifier actually) is that you cannot have two classes with 
> the same 
> > name and package in the same classloading hierarchy.
> >
> > So, for example, suppose you have the following hierarchy:
> >
> > B
> >/
> >   A
> >\
> > C
> >
> > where block A depends on block B and C. Now, if B and C expose the
> > same class, there is no problem if that is accessed from B 
> or from C 
> > internally, but as soon as A starts to access it, which one does it 
> > get?
> 
> Perfectly correct... More in details, A will have an instance of the 
> Class object from either B or C linked to the class name. For example 
> if both B and C expose the class "org.betaversion.MyClass", 
> the C and B 
> classloader will both contain an instance of that class 
> associated with 
> that name.
> 
> When A receives an instance of "org.betaversion.MyClass" the ByteCode 
> Verifier will check it against A's classloader instance of the 
> "org.betaversion.MyClass" class object, which he got from either B or 
> C.
> 
> If the instance of the class object A has is different from the one 
> that instantiated the object, well, the BCV will throw a 
> ClassCastException
> 
> (It might be tricky to understand what's an instance of a Class and 
> what's an instance of an Object, if someone has some doubts, ask me, 
> please... I had to read the JVM specification 3 or 4 times before 
> grasping it)
> 
> > So, in short, it is feasible (IMHO, even if I haven't tried yet) to
> > come up with a classloading hierarchy that allows 
> isolation, but only 
> > when the semantics associated to the class usage are *really* 
> > isolated.
> 
> It is absolutely possible, yes... IN THEORY! :-D
> 
> It means that if (in the above example), we could analyze all classes 
> accessible by A supplied by B and C (which means all public classes), 
> analyze their signatures, come up with a list of all the class 
> instances which are "visible" from outside, we can safely see whether 
> we can (or not) satisfy our versions tree.
> 
> In practice (though) this is quite impossible as 99.9% of the classes 
> created are always "public" and therefore accessible from the 
> children 
> class loaders...

It's interesting to note that this same problem comes up on EJB related
mailing lists from time to time.  In particular, if you search the JBoss
forums for "versioning"  you'll note two things:

1) some EJB container vendors *may* have implemented versioning for EJB
instances;

2) people want this feature and have proposed ways to do it that have at
least partial buy in.

Really, adding a version attribute to a JNDI lookup isn't a big deal.
Extending a class loader to respect this attribute is a bit more of a
pain, but is it that bad? I'd note that I'd differ from some proposals
in that I'd default to oldest version instead of newest (since that
makes it easier to keep old code running) if no version is specified.  

I've noted the similarities between some of the Cocoon block proposals
and EJB management before.  I'm beginning to suspect that if done right
Cocoon blocks (and other Cocoon features) could replace EJB's for a lot
of what we  do with EJB's: eg, look up classes at run time, pull code
out of remote repositories.  Combined with Avalon pooling etc. and it's
not clear what EJB's really buy you over blocks (we're not doing
container managed persistence).

> > Now, if A asks for a particular task that B executes, requiring
> > version 1 of block X, then asks for another task, executed 
> by C, left 
> > to D, which handles to E which requires version 2 of X, 
> then you get a 
> > ClassCastException. No way out!
> >
> > And debugging this is going to be the biggest pain in the universe!!
> 
> Not even debugging... Analyzing the dependencies (although possible) 
> will be a nightmare...
> 
> > So, my suggestion is to create a dependency checker which will tell
> > all the potential class collision conflicts, at deploy time (by 
> > crawling the class space, perform MD5 hashing of classes 
> and identify 
> > collisions)
> 
> You don't even have to have an MD5 :-) Because even if you have the 
> SAME EXACT file, if that file is loaded by two different 
> classloaders, 
> you won't be able to do a cast operation...
> 
> It's a matter of instances of class objects... The instance of the 
> class is different, no way you can cast...

If you're working with EJB's it's likely you already have this problem
(and it's not just casting).  It's not unusual to have a data class
loaded by the EJB container that is used in the servlet container.  I
spent a couple of hours just this week figuring out why adding a method
to a data class suddenly resulted in a No Class Def Found; touching the
class had resulted in Jikes building the classes in a different order
and the EJB tree got an instance of the class that previously hadn't
existed.  In

Re: cvs commit: cocoon-2.1/src/blocks/scratchpad/java/org/apache/cocoon/components/source/impl CachingSource.java AsyncCachingSource.java RefresherImpl.java

2004-03-08 Thread Christian Haul

Unico Hommes wrote:
Christian Haul wrote:

Unico Hommes wrote:

However, I'm not quite sure if this is the way to go. I'm currently
thinking of intercepting and wrapping sources at the selector level.
With the current setup, we need to add the configuration to the URL
in all places it is used. By wrapping a protocol with a cached version
we wouldn't be able to distinguish eg access to a local services from
a remote service (in terms of network hops).
So what if we were to intercept those sources at the selector based
on eg wildcard matching on URL? This would be "cross-cutting" and it
would be easy to provide more complex caching parameters for a wrapped
source.
For the life of me I can't figure out what exactly it is you are saying. 
Care to elaborate? Perhaps give an example?
Say, you would like to access you webdav always asynchronously as well 
as remote webservices. Local services, however, should be accessed
directly.

Solution 1 is to go through your sitemap and wrap your URLs accordingly.
Solution 2 is to say, for "http://*.localsite.com/*"; use plain http, for
everything else use "acached://[EMAIL PROTECTED]" (or a better syntax that doesn't
encode everything into the URL).
To achieve this, one could replace the component selector holding the
source factories and always return a wrapper. Only when the real URL
is available (eg absolutize() or get() is called), the decision is made
which factory to use.
Esp. with a event based cache, how would you specify the event to 
invalidate the source from within the URL?

I was thinking to use querystring parameter to pass it in and default to 
the wrapped Source's system id (getURI). This is what I am using right 
now for WebDAV sources and it works perfectly.
Ah well. I have Documentum DQL as URL and would need to have something
else for a key, like the document ID or a folder name.

By the way I think you are the one to ask Christian: I noticed there 
is no scheduler.addPeriodicJob(.. Object job, ..) method. Is there a 
reason for this or can I add one? So that the Refresher can add 
itself and its update targets directly.


Although I'd like to help I haven't touched the Cron block before. But 
speaking of addPeriodicJob() it would be great to have a way to say 
"do this right now AND repeat every 10 minutes". The current 
implementation
provides only for a "do this every 10 minutes and start in 10 minutes 
for the first time". IIUC this limitation does not stem from the Qartz 
API but from what the Cocoon JobScheduler provides.

Yeah it does. There already exists a plain addJob method with the 
signature I am talking about.
But AFAIK there's either "do now", "do at cron spec" (like mondays at 
12am), or "do every x minutes starting in x minutes". Of course, what
I would like to have is just a combination of addPeriodicJob() and 
fireJob() 

Speaking of random ideas around the cached source, it might be nice to
provide a URL for the content when it's not yet available. But then this
might add too much features to a supposed to be simple concept.
I was also thinking of an implementation of the update mechanism where 
objects don't get invalidated if they cannot be regenerated (eg. due to 
WebDAV server offline, network problems, etc.) but get rescheduled instead.
Makes sense.

	Chris.

DO NOT REPLY [Bug 26456] - First Xindice DB is created in current directory (instead of WEB-INF?)

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

First Xindice DB is created in current directory (instead of WEB-INF?)





--- Additional Comments From [EMAIL PROTECTED]  2004-03-08 20:19 ---
Hello Vadim,

can you provide a status update? The XIndice CVS has no 1.1b4 tag, but the
status.xml mentions it for 4th of March?

Joerg

DO NOT REPLY [Bug 26445] - NPE at o.a.xalan.transformer.TransformerImpl.java:1497

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

NPE at o.a.xalan.transformer.TransformerImpl.java:1497

[EMAIL PROTECTED] changed:

   What|Removed |Added

 CC||[EMAIL PROTECTED]
 AssignedTo|[EMAIL PROTECTED]   |[EMAIL PROTECTED]



--- Additional Comments From [EMAIL PROTECTED]  2004-03-08 20:16 ---
Have you done any further research? I had a look at the place in the code:

  public void setParameter(String name, String namespace, Object value)
  {

VariableStack varstack = getXPathContext().getVarStack();
QName qname = new QName(namespace, name);
XObject xobject = XObject.create(value, getXPathContext());

StylesheetRoot sroot = m_stylesheetRoot;
Vector vars = sroot.getVariablesAndParamsComposed();
int i = vars.size();
while (--i >= 0)
{
  ElemVariable variable = (ElemVariable)vars.elementAt(i);
  if(variable.getXSLToken() == Constants.ELEMNAME_PARAMVARIABLE && 
 variable.getName().equals(qname))
  {
  varstack.setGlobalVariable(i, xobject);
  }
}
  }

vars.size() is in ine 1497 and causes the NPE. I don't know how you can enforce
this NPE. Bug the CVS on TransformerImpl
(http://cvs.apache.org/viewcvs.cgi/xml-xalan/java/src/org/apache/xalan/transformer/TransformerImpl.java)
shows a fix near to the in the stacktrace mentioned line (refering to bug
#25368). The patch is included in the new Xalan 2.6.0 version, so maybe you try
this one. It's included in recent Cocoon 2.1 from CVS.

Please report back. Otherwise we have to put the blame on your stylesheet (or
your usage in general) or on Xalan and close the bug.

Joerg

DO NOT REPLY [Bug 26086] - [PATCH] Dereferencing null TextEvent() argument in JXTemplateGenerator

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

[PATCH] Dereferencing null TextEvent() argument in JXTemplateGenerator





--- Additional Comments From [EMAIL PROTECTED]  2004-03-08 19:58 ---
Chris, what about this bug and its very simple patch?

Re: SimpleFormTransformer

On 08.03.2004 20:09, Steven Noels wrote:

I would request that you poll your users.  I am not in favor of this.


I don't think there would be any reason to remove these lightweight form 
handling components from Cocoon. You should expect however that the 
majority of development effort goes into CForms - but then again, these 
components are simple enough to live without much shepherding.
+1 AFAIK this are also only very few classes.

Joerg

Re: [VOTE] Rename Rhino-with-continuations packages

On 08.03.2004 03:59, Christopher Oliver wrote:

In order to allow the use of Flowscript on the BEA Weblogic and IBM 
Websphere application servers (and possibly in other environments) I 
propose that we rename the Rhino packages from org.mozilla to 
org.cocoondev. The Rhino codebase used in Cocoon is currently hosted on 
cocoondev.org 
(http://cvs.cocoondev.org/cgi-bin/viewcvs.cgi/rhino1_5R4pre/?cvsroot=rhino). 
The standard Rhino core in the mozilla.org CVS has been completely 
rewritten since I added the interpreter that supports continuations. 
Therefore it is impossible to move support for continuations to that 
codebase in the short term. However, even if that were possible it would 
not solve the problem of using Flowscript on Weblogic and Websphere, 
because each contains its own forked or old version of Rhino which is 
exposed to the class loader used by Cocoon.

Here is my +1.
Though I absolutely don't like it I see we nearly have no other choice 
(besides paying Chris more than his employer or doing his work at the 
company he works for ;-) ).

+0

Joerg

Re: Experience with workflow at Hippo Webworks

2004-03-08 Thread Guido Casper

Hunsberger, Peter wrote:

Guido Casper <[EMAIL PROTECTED]> writes:

Hunsberger, Peter wrote:

For the end user I believe you always have to have modeling 
tools for 

building work flow, the internal implementation should be 
completely 

transparent; the first time I wrote GUI modeling tools for 
work flow 

was 13 years ago (as a subcontractor for one of the major work flow 
vendors) I don't believe the end user expectations have 
declined since 

then!
I'm slowly starting to see an unsolvable conflict :-)

Some are looking for a tool for developers and some are looking for a 
tool for users. And I guess we'll be having a hard time 
finding a single 
tool being both.


I probably should have written "For the end user I believe you always
have to have the option of having modeling tools for building work
flow...".  However, even as written originally I don't see a conflict? I
think it's not unreasonable to assume that the modeling tools will be
independent of Cocoon. 

What is needed is a way to take the models, where ever they may
originate, and implement them in Cocoon.  I think the only way that's
going to be generally possible is if Cocoon has some form of template
based model (even if it is internally used to generate a script based
implementation via some XSLT).
As I see it, a user tool can only work within a limited context. The 
more you try to widen that context, the more the user tool starts 
resembling my development tool (with a UI still intended for end users) 
and things get messy.

If my state objects and my action objects both are Avalon components I 
can easily build really complex conditions and state transferring 
activities. I hardly see how these may be modelled in a user tool.

IMO modelling tools are great tools for communicating using models being 
reduced representations of the reality (isn't that what models are 
about?) but are usually hard to use to generate the reality out of the 
model.

I think it would be a good idea to talk about these two
-a user-oriented workflow tool with a modeling UI and a well defined 
limited context
-and a more flexible development tool

as separate implementations sharing the same interface.

WDYT?

Guido

--
Guido Casper
-
S&N AG, Competence Center Open Source
Tel.: +49-5251-1581-87
Klingenderstr. 5mailto:[EMAIL PROTECTED]
D-33100 Paderborn   http://www.s-und-n.de
-

[cocoon 2.2] JStyle

Hello Carsten,

you removed jstyle.jar some days ago during updating the licenses. Was 
the removal by intention? Cocoon 2.2 does no longer compile 
(JStyleFormatter.java). Has this styling ever been in use?

Joerg

DO NOT REPLY [Bug 26011] - NullpointerException in CocoonServlet on SAP J2EE Engine 6.20

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

NullpointerException in CocoonServlet on SAP J2EE Engine 6.20

[EMAIL PROTECTED] changed:

   What|Removed |Added

 AssignedTo|[EMAIL PROTECTED]   |hans-
   ||[EMAIL PROTECTED]
   ||e



--- Additional Comments From [EMAIL PROTECTED]  2004-03-08 19:32 ---
Any further information? Otherwise we will close the bug.

RE: Experience with workflow at Hippo Webworks

Guido Casper <[EMAIL PROTECTED]> writes:
> 
> Hunsberger, Peter wrote:
> > For the end user I believe you always have to have modeling 
> tools for 
> > building work flow, the internal implementation should be 
> completely 
> > transparent; the first time I wrote GUI modeling tools for 
> work flow 
> > was 13 years ago (as a subcontractor for one of the major work flow 
> > vendors) I don't believe the end user expectations have 
> declined since 
> > then!
> 
> I'm slowly starting to see an unsolvable conflict :-)
> 
> Some are looking for a tool for developers and some are looking for a 
> tool for users. And I guess we'll be having a hard time 
> finding a single 
> tool being both.

I probably should have written "For the end user I believe you always
have to have the option of having modeling tools for building work
flow...".  However, even as written originally I don't see a conflict? I
think it's not unreasonable to assume that the modeling tools will be
independent of Cocoon. 

What is needed is a way to take the models, where ever they may
originate, and implement them in Cocoon.  I think the only way that's
going to be generally possible is if Cocoon has some form of template
based model (even if it is internally used to generate a script based
implementation via some XSLT).

Re: Experience with workflow at Hippo Webworks

2004-03-08 Thread Guido Casper

Hunsberger, Peter wrote:
For the end user I believe you always have to have modeling tools for
building work flow, the internal implementation should be completely
transparent; the first time I wrote GUI modeling tools for work flow was
13 years ago (as a subcontractor for one of the major work flow vendors)
I don't believe the end user expectations have declined since then!
I'm slowly starting to see an unsolvable conflict :-)

Some are looking for a tool for developers and some are looking for a 
tool for users. And I guess we'll be having a hard time finding a single 
tool being both.

Guido

--
Guido Casper
-
S&N AG, Competence Center Open Source
Tel.: +49-5251-1581-87
Klingenderstr. 5mailto:[EMAIL PROTECTED]
D-33100 Paderborn   http://www.s-und-n.de
-

Re: SimpleFormTransformer (was: From Woody to CocoonForms)

On 08 Mar 2004, at 06:23, Ralph Goers wrote:

I would request that you poll your users.  I am not in favor of this.
I don't think there would be any reason to remove these lightweight 
form handling components from Cocoon. You should expect however that 
the majority of development effort goes into CForms - but then again, 
these components are simple enough to live without much shepherding.


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

RE: [portal] JSR168 portlets problems under PortalEngine

2004-03-08 Thread DURDINA Michal

...
> 
> > 1. test2.jsp: Call to 
> > portalContext.getSupportedWindowStates() returns null.
> > 
> I fixed this (hopefully) yesterday morning in the CVS.
> 

Haven't got chance to test it again. After I updated my whole cocoon-distribution from 
CVS and build clean webapplication only with portal-block and I am encountering 
problem that did not occure before. After click on JSR-168 tab the exception occured:

INFO(2004-03-08) 19:42.51:791   [core.authentication-manager] 
(/cocoon21/samples/portal/auth) Thread-7/PipelineAuthenticator: Authenticator: User 
authenticated using handler 'portal-handler'
FATAL_E (2004-03-08) 19:42.58:619   [core.xslt-processor] 
(/cocoon21/samples/portal/portal) Thread-9/TraxErrorHandler: Error in TraxTransformer: 
javax.xml.transform.TransformerException: java.util.ConcurrentModificationException
javax.xml.transform.TransformerException: java.util.ConcurrentModificationException
at 
org.apache.xalan.transformer.TransformerImpl.transformNode(TransformerImpl.java:1226)
at org.apache.xalan.transformer.TransformerImpl.run(TransformerImpl.java:3135)
at 
org.apache.xalan.transformer.TransformerHandlerImpl.endDocument(TransformerHandlerImpl.java:433)
at org.apache.cocoon.xml.AbstractXMLPipe.endDocument(AbstractXMLPipe.java:56)
at 
org.apache.cocoon.transformation.TraxTransformer.endDocument(TraxTransformer.java:549)
at 
org.apache.cocoon.portal.impl.PortalManagerImpl.showPortal(PortalManagerImpl.java:76)
...

But when I comment out testsuite portlets and leave only "internal" TestPortlet1, 
exception does not occur. If it has something to do with the fact the cocoon doesn't 
use last pluto container and I used latest testsuite (it didn't change much last days) 
then please ignore this report. BTW: When testing in cocoon I replaced latest pluto 
jars with ones that come with cocoon.

> > 2. test2.jsp: Call to renderRequest.getParameter("testName") 
> > returns null after 2.nd and every other render() was called. 
> > Portlet container should preserve request parameters sent 
> > upon 1.st request for every subsequent call of render() in 
> > the portlet which was not target of the subsequent client 
> > request (JSR-168spec chap. 11.1.1 §3). But jakarta-pluto is 
> > also doing this, so it's not exactly cocoon problem. 
> > 
> Did you test the latest pluto version?

Yes I did. It is still happening with latest jakarta-pluto/Tomcat from CVS today, so I 
reported that to pluto bugzilla.

> 
> > 3. test3.jsp: Submit to url created by 
> > renderResponse.createRenderURL(); 
> > url.setWindowState(WindowState.MAXIMIZED); changes correctly 
> > return value of renderRequest.getWindowState() to 
> > "maximized", but the portlet window actually does not 
> > maximize. By contrast when submit to url with 
> > WindowState.MINIMIZED is executed, the portlet windows 
> > minimizes but stays minimized forever - I could not get it to 
> > normal size by clicking window icons.
> > 

Reported to cocoon bugzilla.

> > 4. test4.jsp: Simmilar to point 2. but at this time 
> > parameters set by _action_ are not preserved. When testing in 
> > jakarta-pluto, they are.
> > 
> > My testing env:
> > cocoon-portal block build from CVS (04.march.2003) 
> > jakarta-testuite built from CVS (04.march.2003)
> > 
> Thanks for reporting this! I think the best way is if you file bugs
> into bugzilla. Please enter a bug to the Cocoon bugs if the
> problem is only with the Cocoon portal and to Pluto's bug list
> if the bug is in Pluto as well.
> 
> I will try to update the version of Pluto used in Cocoon to the
> latest version in the next days and then have a look at the bugs
> you described.
> 
> Many thanks!
> 

Thank you!

Michal

Re: Experience with workflow at Hippo Webworks

2004-03-08 Thread Guido Casper

Johan Stuyts wrote:
Using the GoF State pattern works 
great for simple state machines and I use it a lot. But the pattern does 
not talk about nested and/or parallel states, which become 
incomprehensible when coded in Java; the state machine logic gets 
intermixed with the document logic.
Johan, can you give me an example of parallel states?
I currently can't even imagine what that might look like on a drawing 
(hope my business user can ;-) Also I'm not convinced about the need for 
nested states, although I could think of ways the state pattern might 
account for that (a state object might use the state pattern itself).
What would be a possible alternative implementation?

As for the newsletter problem I'll have to solve that one as well :-)
But I can think of ways to solve that without introducing a whole bunch 
of new concepts or terminology just to solve that single use case. If 
you tell me I'm mixing concerns that may be true. I'm fine with mixing 
concerns and bending the framework a little for complex cases if it's 
still easy to grasp.
But if the technology doesn't allow me to solve simple problems easily 
(there might be people claiming the same to be true for Cocoon (in case 
not being familiar with it) and I think this may be a reason Cocoon not 
being adopted _much_ wider. I don't mean that as a criticism in any way 
(it would be one to myself), it's just a fact, AFAICS), I loose interest.

If somebody comes up with a full featured workflow engine still simple 
to use from Cocoon for simple use cases, I would immediately use that.

Guido

--
Guido Casper
-
S&N AG, Competence Center Open Source
Tel.: +49-5251-1581-87
Klingenderstr. 5mailto:[EMAIL PROTECTED]
D-33100 Paderborn   http://www.s-und-n.de
-

RE: Experience with workflow at Hippo Webworks

Stefano Mazzocchi <[EMAIL PROTECTED]> writes:

> > In that situation, asking a user to write a new version of 
> a program 
> > for
> > that specific need doesn't seem a good solution to me ;-)
> 
> Wait a second: to you think that guy would be more confortable in 
> writing a FSM code?
> 
> Let's compare apples to apples here: we are not discussing how the 
> workflows should be edited, but how they are going to impact 
> our system 
> and how we are going to build them.
> 
> there are several solution on the table and at least two 
> architecturally 
> orthogonal questions:
> 
>   1) should the workflow engine have direct data control?
>   2) should the workflow engine deal with procedural scripts 
> or finite 
> state machines directly?
> 
> my take would be
> 
>   1) no, it should be saparate, sort of a process knowledge base that 
> the flow logic interrogates when it need to

I would definitely agree.

> 
>   2) procedural scripts: they are always easier to program
> 

Does it really matter if you have 1) ?  At that point I think you're
very close to having a generalized Cocoon component that picks up a work
flow definition and runs with it...  

For the end user I believe you always have to have modeling tools for
building work flow, the internal implementation should be completely
transparent; the first time I wrote GUI modeling tools for work flow was
13 years ago (as a subcontractor for one of the major work flow vendors)
I don't believe the end user expectations have declined since then!

Re: regarding JCS usage...

2004-03-08 Thread Ugo Cei

Marco Rolappe wrote:
I stumbled over the following thread in the hibernate forum about JCS
problems:
http://forum.hibernate.org/viewtopic.php?t=924937

thought it might be useful to know before going JCS. there's also an
alternative (EHCache) mentioned.
I've been using EHCache in production with Hibernate, and have no 
problems to report about it, even though the load is very light.

EHCache's license, unlike Hibernate's, is APL 1.1, by the way.

	Ugo

RE: Experience with workflow at Hippo Webworks

Guido Casper <[EMAIL PROTECTED]> writes:

> Continuations within a webapps are better than a FSMs because 
> the FSM approach is just a workaround for the lack of a 
> single-threaded view of my webapp and continuations brought 
> back that view to me. However for potentially everlasting 
> conditional (and rather detached) workflow state 
> transistions FSMs do not look like a workaround to me but 
> like the (or 
> one) solution.
> 
> Page flow control mostly is rather small pieces of 
> potentially complex conditional logic with few branches (the 
> user "is passively guided" through the page flow) while 
> workflow logic looks like an everlasting loop of simple 
> conditional logic with potentially lots of branches (the 
> user "actively triggers" the workflow).

I think I agree with you that continuations don't bring anything
specifically to the work flow model.  However, I believe that there is a
continuum from flow to work flow; a sequence of screens is a sequence of
screens.  Where I draw the line is based on what the persistence
requirements are: if a state must be persisted only across a browser
request, Cocoon flow continuations are sufficient.  However, if a state
must be persisted across multiple browser sessions then continuations
bring nothing to the table.  Instead, you need an external state model
that allows you to create (or recreate) the sequence of steps required
to manipulate the "document" at any given point in time.

To put it another way, a work flow description tells us what sequence of
screens must be presented dependant on the document instance and user at
hand.  Cocoon flow (and continuations) are a way to manage that work
flow instance within a browser session.  

The issue that I think has to be solved is; how to take a generalized
work flow model and turn it into a Cocoon flow. This raises many
questions:

- Can a database or document driven flow controller be created that is
generalized enough to handle any work flow model?  

- Is there a nice way to map between some generalized flow model and
Cocoon flow?  In other words, what's the equivalent of Woody (ahem,
cforms) templates for work flow?  And, what's the equivalent of cforms
transforms for work flow?  

- If we do this correctly does the requirement to write flowscript
disappear and instead get turned into a requirement to just write a work
flow template? (Even if it does, I bet writing flowscript would still be
faster for writing small apps and prototypes).

DO NOT REPLY [Bug 27518] New: - [portal] submit to url minimize locks window minimized

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

[portal] submit to url minimize locks window minimized

   Summary: [portal] submit to url minimize locks window minimized
   Product: Cocoon 2
   Version: Current CVS 2.1
  Platform: All
OS/Version: Other
Status: NEW
  Severity: Major
  Priority: Other
 Component: blocks
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


This occured when testing test3.jsp from jakarta-pluto testuite in 
Cocoon/Tomcat:

Submit to url created by renderResponse.createRenderURL(); url.setWindowState
(WindowState.MAXIMIZED); changes correctly return value of 
renderRequest.getWindowState() to "maximized", but the portlet window actually 
does not maximize. By contrast when submit to url with WindowState.MINIMIZED is 
executed, the portlet windows minimizes but stays minimized forever - I could 
not get it to normal size by clicking window icons.

Re: regarding JCS usage...

Marco Rolappe wrote:

I stumbled over the following thread in the hibernate forum about JCS
problems:
http://forum.hibernate.org/viewtopic.php?t=924937

thought it might be useful to know before going JCS. there's also an
alternative (EHCache) mentioned.
 

Hmm, more bad news about JCS. It's beginning to look less and less 
likely candidate for our caching needs. I've been talking with a guy on 
the JCS users list who has created a patch for the JCS shutdown bug I 
mentioned earlier. Hopefully this issue will be resolved soon and I can 
start doing some heavy testing to see for myself.

Unico

regarding JCS usage...

2004-03-08 Thread Marco Rolappe

I stumbled over the following thread in the hibernate forum about JCS
problems:

http://forum.hibernate.org/viewtopic.php?t=924937


thought it might be useful to know before going JCS. there's also an
alternative (EHCache) mentioned.

RE: [RT] Forwarding of internal pipeline calls

From: Ralph Goers [mailto:[EMAIL PROTECTED] 
> 
> Is it possible to specify the error handling as an attribute 
> of map:redirect-to instead of a parameter of the uri?  It 
> feels awkward to have to do it that way.  Obviously, if it 
> needed to tacked on to the uri internally so it could be 
> picked up later in the pipeline processing that could be 
> done, as long as it was removed then too.  
> 
The latest idea we had is to not use a parameter but to make
the redirect a real forward, which means the error handler
of the called pipeline is always used.
But this is an incompatible change of course which has to 
voted.

I think, making this an attribute on the redirect element
is possible as well, yes.

Carsten

> 
>  -Original Message-
> From: Carsten Ziegeler [mailto:[EMAIL PROTECTED] 
> Sent: Monday, March 08, 2004 7:48 AM
> To:   [EMAIL PROTECTED]
> Subject:  RE: [RT] Forwarding of internal pipeline calls
> 
> Sounds good (and more important it sounds possible :) ). So, 
> we just have to do some votes (about the redirect=forwarding) 
> and the correct notion of this one, implement it and voila 
> have this nice little feature many users ask for.
> Great!
> 
> Carsten
> 
>

RE: [RT] Forwarding of internal pipeline calls

2004-03-08 Thread Ralph Goers

Is it possible to specify the error handling as an attribute of
map:redirect-to instead of a parameter of the uri?  It feels awkward to have
to do it that way.  Obviously, if it needed to tacked on to the uri
internally so it could be picked up later in the pipeline processing that
could be done, as long as it was removed then too.  

Ralph

 -Original Message-
From:   Carsten Ziegeler [mailto:[EMAIL PROTECTED] 
Sent:   Monday, March 08, 2004 7:48 AM
To: [EMAIL PROTECTED]
Subject:RE: [RT] Forwarding of internal pipeline calls

Sounds good (and more important it sounds possible :) ). So, we just
have to do some votes (about the redirect=forwarding) and the
correct notion of this one, implement it and voila have this
nice little feature many users ask for.
Great!

Carsten

RE: [RT] Forwarding of internal pipeline calls

Sylvain Wallez wrote:
> 
> 
> Ah yes, I understand the "technically nearly impossible" now:
> - pipeline building is always under control of the 
> treeprocessor. So in that phase, this is possible.
Yes.

> - for external requests, pipeling processing occurs within 
> the treeprocessor (in the node that closes the pipeline), so 
> it's possible here also
Yes.

> - for internal requests, pipeline processing occurs outside 
> of the treeprocessor, when the caller uses 
> SitemapSource.getInputStream(). This is where the difficult 
> point is...
Yupp.

> 
> Mmmh... what we can do is give the SitemapSource an 
> error-handling processor which would just wrap the 
> error-handler (if any) in the  where the 
> pipeline was built. The SitemapSource can then call that 
> special processor if a problem arises during pipeline execution.
> 
> The means for the TreeProcessor to pass this special 
> error-handling processor to the SitemapSource can be the 
> MutableEnvironmentFacade that's already considered as a 
> special case by the TreeProcessor. This class is a kind of 
> "backwards communication channel" from the Processor to the 
> SitemapSource.
> 
> I think this should work, and this solution has no impact on 
> the existing interfaces.
> 
Sounds good (and more important it sounds possible :) ). So, we just
have to do some votes (about the redirect=forwarding) and the
correct notion of this one, implement it and voila have this
nice little feature many users ask for.
Great!

Carsten

Re: [RT] Forwarding of internal pipeline calls

Carsten Ziegeler wrote:

Sylvain Wallez wrote:

Sorry, what is "technically nearly impossible"??

Without changing the interfaces and without having a clean separation of concerns, it's not possible. Of course if we change some core interfaces, the treeprocessor and the pipeline implementation, this is possible. Something along these lines.

So, I just tried the other way:

The current implementation I have can only be used for redirects, although it's fairly simple to extend it to be used in map:generate etc. as well.

WDYT? Is this of general interest?

This question comes regularly on the table. Maybe it's time to give it an answer now :-)

YES :)

The current state is that is considered only for requests coming directly from the outside world, and not for internal requests (i.e. "cocoon:").

Firstly, this behaviour is IMO bad for forwards (redirects to "cocoon:"): forwarding should fully delegate the request, including error handling. Fixing this can be accomplished easily by overriding isInternal() in TreeProcessor.ForwardEnvironmentWrapper: instead of always returning false, we can delegate the call to the wrapped environment (will return true on http and cli environments).

Yes, that's what I did - and it seems to work. Now, the question is if we can simply change this for redirect's?

Well, that's a first step that will give consistency to the error
handling for external requests ;-)

Secondly, we have to define means for handle-errors to be used on internal requests (i.e. SitemapSource). And in that case, as you outlined, this can be determined by the caller (the place where the "cocoon:" occurs) or in the callee (the called pipeline).

- by the caller, I don't see any other way than using an additional parameter as you proposed above. But instead of "cocoon:forward", naming it "cocoon:handle-errors" seems more adequate.

Ok.

- by the callee, this can be done using an additional attribute on the error-handler. What comes to mind is

Policy defined by the caller should have precedence over the one defined in the pipeline.

How does it sound?

Good, but as I tried to state, it's not that easy to get the second implemented. The pipeline is currently executed in the ProcessingPipeline object, so that's were the generator is started etc. When an exception occurs during pipeline processing it happens there. And the pipeline doesn't have any connection to the tree processor or to the handle errors part etc. So that would be the challenge.

Ah yes, I understand the "technically nearly impossible" now:
- pipeline building is always under control of the treeprocessor. So in
that phase, this is possible.
- for external requests, pipeling processing occurs within the
treeprocessor (in the node that closes the pipeline), so it's possible
here also
- for internal requests, pipeline processing occurs outside of the
treeprocessor, when the caller uses SitemapSource.getInputStream(). This
is where the difficult point is...

Mmmh... what we can do is give the SitemapSource an error-handling
processor which would just wrap the error-handler (if any) in the
where the pipeline was built. The SitemapSource can then
call that special processor if a problem arises during pipeline execution.

The means for the TreeProcessor to pass this special error-handling
processor to the SitemapSource can be the MutableEnvironmentFacade
that's already considered as a special case by the TreeProcessor. This
class is a kind of "backwards communication channel" from the Processor
to the SitemapSource.

I think this should work, and this solution has no impact on the
existing interfaces.

Sylvain

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

Re: [VOTE] Rename Rhino-with-continuations packages

2004-03-08 Thread Tim Larson

On Mon, Mar 08, 2004 at 03:32:44PM +0100, Steven Noels wrote:
> Maybe we could rename it into "Cocoon Scripting Engine" while we are at 
> it - as this seems to be a common usage pattern. ;-)

Now you made me LOL :)

--Tim Larson

RE: [RT] Forwarding of internal pipeline calls

Sylvain Wallez wrote:
> 
> Sorry, what is "technically nearly impossible"??
> 
Without changing the interfaces and without having a clean separation
of concerns, it's not possible. Of course if we change some core
interfaces, the treeprocessor and the pipeline implementation,
this is possible. Something along these lines.

> >So, I just tried the other way:
> >
> >
> >The current implementation I have can only be used for redirects, 
> >although it's fairly simple to extend it to be used in map:generate 
> >etc. as well.
> >
> >WDYT? Is this of general interest?
> >  
> >
> 
> This question comes regularly on the table. Maybe it's time 
> to give it an answer now :-)
> 
YES :)

> The current state is that  is considered 
> only for requests coming directly from the outside world, and 
> not for internal requests (i.e. "cocoon:").
> 
> Firstly, this behaviour is IMO bad for forwards (redirects to
> "cocoon:"): forwarding should fully delegate the request, 
> including error handling. Fixing this can be accomplished 
> easily by overriding
> isInternal() in TreeProcessor.ForwardEnvironmentWrapper: 
> instead of always returning false, we can delegate the call 
> to the wrapped environment (will return true on http and cli 
> environments).
Yes, that's what I did - and it seems to work. Now, the question
is if we can simply change this for redirect's?

> 
> Secondly, we have to define means for handle-errors to be 
> used on internal requests (i.e. SitemapSource). And in that 
> case, as you outlined, this can be determined by the caller 
> (the place where the "cocoon:" occurs) or in the callee (the 
> called pipeline).
> 
> - by the caller, I don't see any other way than using an 
> additional parameter as you proposed above. But instead of 
> "cocoon:forward", naming it "cocoon:handle-errors" seems more 
> adequate.
> 
Ok.

> - by the callee, this can be done using an additional 
> attribute on the error-handler. What comes to mind is 
> 
> 
> Policy defined by the caller should have precedence over the 
> one defined in the pipeline.
> 
> How does it sound?
> 
Good, but as I tried to state, it's not that easy to get the second
implemented. The pipeline is currently executed in the ProcessingPipeline
object, so that's were the generator is started etc. When an 
exception occurs during pipeline processing it happens there. And
the pipeline doesn't have any connection to the tree processor or
to the handle errors part etc. So that would be the challenge.

Carsten

Re: [RT] Forwarding of internal pipeline calls

Carsten Ziegeler wrote:

While using internal cocoon redirects, I found out that there are
potential problems with error handling (it might be that we have
discusses this already...).
Now, if you do a:

than this is an internal pipeline call (and not a new http request).
This has of course some advantages (e.g. performance etc), but
has imho the drawback that in this case, the error handling
of the calling pipeline is *always* used. This means if an error
occurs while processing the "something" pipeline, the error
handler of the pipeline containing the redirect-to is invoked.
Now, in general this might be a good solution for internal pipeline
calls when they are used in a map:generate etc., but it's imho
a little unusal for a redirect.
We had recently the discussion on this list, if we need a general
solution to specify which error handler is used for internal pipeline
calls. I discussed this a little bit with Vadim on IRC during our
first friday and he suggest to specify this not on the caller but
on the called pipeline. So the map:pipeline containing the
"something" pipeline specifies what to do. Regardless if this is
the better choice than specifying it in the uri ("cocoon:"),
it's technically nearly impossible. When the internal pipeline
is called, everything happens outside the treehandler and there is
no real chance to get the error handler etc. (Of course we could
change something here and there and then it will work.)
 

Sorry, what is "technically nearly impossible"??

So, I just tried the other way:

The current implementation I have can only be used for redirects,
although it's fairly simple to extend it to be used in
map:generate etc. as well.
WDYT? Is this of general interest?
 

This question comes regularly on the table. Maybe it's time to give it 
an answer now :-)

The current state is that  is considered only for 
requests coming directly from the outside world, and not for internal 
requests (i.e. "cocoon:").

Firstly, this behaviour is IMO bad for forwards (redirects to 
"cocoon:"): forwarding should fully delegate the request, including 
error handling. Fixing this can be accomplished easily by overriding 
isInternal() in TreeProcessor.ForwardEnvironmentWrapper: instead of 
always returning false, we can delegate the call to the wrapped 
environment (will return true on http and cli environments).

Secondly, we have to define means for handle-errors to be used on 
internal requests (i.e. SitemapSource). And in that case, as you 
outlined, this can be determined by the caller (the place where the 
"cocoon:" occurs) or in the callee (the called pipeline).

- by the caller, I don't see any other way than using an additional 
parameter as you proposed above. But instead of "cocoon:forward", naming 
it "cocoon:handle-errors" seems more adequate.

- by the callee, this can be done using an additional attribute on the 
error-handler. What comes to mind is 

Policy defined by the caller should have precedence over the one defined 
in the pipeline.

How does it sound?

Sylvain

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

Re: [VOTE] Rename Rhino-with-continuations packages

On 08 Mar 2004, at 11:16, Sylvain Wallez wrote:

Very good point. It cannot be the ASF, and cocoondev.org isn't a legal 
entity that can hold a copyright. Considering that rhino+cont's single 
author is Chris, he could be the copyright holder, but community-wise 
this doesn't sound good.

And in the same area, what will be (or can be) its license? Is it 
possible to relicense the fork or should we keep MPL?
IIRC, MPL 1.0 is tainted - 1.1 is not. And Rhino consists of source 
code with a variety of license headers attached: a legal mess IMO. 
Maybe we should ask for a to-be-forked donation from Mozilla to get a 
"legally stable" snapshot to work upon.

My personal problem though is that I have a bit of an ethical issue 
asking for a (donation) favor from an open source community, knowing 
that we won't properly community-shepherd their code anyhow - 
preferring our own fork for obvious reasons.

Anyway, I'm +1 for the renaming, which, since the fork does exist, 
will make it clear and visible, along with solving the technical 
problems in WS and WL.
Maybe we could rename it into "Cocoon Scripting Engine" while we are at 
it - as this seems to be a common usage pattern. ;-)


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

Re: ManifestToolTask.java vs. Ant

Antonio Gallardo wrote:

Hi:

Is posible to replace tool/src/anttask/ManifestToolTask.java with:

http://ant.apache.org/manual/CoreTasks/manifest.html

Are we using ManifestToolTask at all? If so, why? can we change the
implementation to use  instead?
 

Take a look at what it does (see ManifestToolTask.java, line 63-86), and 
where it is used (CocoonServlet.java, line 616-695), and then tell us 
can it be used or not :)

Vadim

Re: New main license.txt missing some info?

Antonio Gallardo wrote:

Hi:

Reading the main LICENSE in Cocoon, seems like we forgot to fill this line:

Copyright [] [name of copyright owner]
 

No. This is intentional. Please re-read paragraph above this line, and 
then re-read chapter 1, definition of Work.

Vadim

Re: [VOTE] Rename Rhino-with-continuations packages

Christopher Oliver wrote:

In order to allow the use of Flowscript on the BEA Weblogic and IBM 
Websphere application servers (and possibly in other environments) I 
propose that we rename the Rhino packages from org.mozilla to 
org.cocoondev. The Rhino codebase used in Cocoon is currently hosted 
on cocoondev.org 
(http://cvs.cocoondev.org/cgi-bin/viewcvs.cgi/rhino1_5R4pre/?cvsroot=rhino). 
The standard Rhino core in the mozilla.org CVS has been completely 
rewritten since I added the interpreter that supports continuations. 
Therefore it is impossible to move support for continuations to that 
codebase in the short term. However, even if that were possible it 
would not solve the problem of using Flowscript on Weblogic and 
Websphere, because each contains its own forked or old version of 
Rhino which is exposed to the class loader used by Cocoon.


+1. There is chance we deploy on WebSphere soon...

Vadim

Deprecating FormValidatorAction

2004-03-08 Thread Leszek Gawron

As the FormValidatorAction is not cool fancy and new it still intruduces some
interesting functionality that does not exist in flow. Suppose you do not use
CForms in all your application views. So you have plain html with links that
will trigger some flow function:

http://www.myhost.com/myapp/document/edit.do?documentId=123&storeName=first

Although all cocoon examples silently omit the request parameter validation it
is needed here (as in all places that we use request parameters). So instead
of validating the request parameters manually in flow (which makes the code
look really ugly) we could use the existing functionality of
FormValidatorAction. The only thing that should be done is to convert it to
cocoon component so it could be easily obtained from flow and rename it to
something like RequestParameterValidator.

This way you could still use the format of validator descriptors and use flow
this way: 

function edit() {
var validator = cocoon.getComponent(
"o.a.c.RequestParameterValidator");
if ( validator.validateRequestParams(
"descriptors/edit-document-descriptor.xml" ) {
// validate params vs. database and proceed to some view

} else { 
// extract errors from validator (as in xsp-formval) and 
// show some view with error message that the reuqest was 
// malformed
}
}

AbstractValidatorAction implements a lot of validating condition types along
with constraint-sets which is maybe not so useful now for forms (as CForms is
much more powerful) but very useful just to validate request parameters.

My regards
LG

AW: [RT] Forwarding of internal pipeline calls

2004-03-08 Thread Marco Rolappe

I don't really want to delve too deeply into this (the mail would become
very long ;-) but...

the core problem IMO is the current concept(s) of the sitemap; I had that
feeling already when starting with Cocoon, hearing about the 'sitemap' and
then looking at it and being confused.

and when seeing a proposal like a separate protocol for forwarding I find it
fairly obvious that there's something wrong.

one of the core problems I see is missing SoC. the most powerful thing and
the core concept (for me) are the processing pipelines; they are supposed to
produce a deliverable response by using a generator, transformers and a
serializer. the missing/weak SoC IMO already starts with Reader's; these
haven't really anything to do with (XML/SAX) processing pipelines.

I think the reason(ing) for forcing Reader's into the pipeline concept
already leads to the core problem; requests are always mapped to pipelines.

I don't know what you people use internal 'redirects' for, but I mainly use
it for delegation or aliasing respectively. the reasoning for internal
'redirects' I assume are the same as for Reader's. force everything into a
pipeline (which still is an XML processing pipeline).

all of it would be so much cleaner, more elegant, more
maintainable/resuable... if concerns were better separated; declaration of
URI space handled by sitemap (think contract/interface), definition of URI
space (think implementation, including useful concepts like inheritance),
definition of processing pipelines and respective pipeline components.

you would map URIs/requests, e.g. to 'request processors', not directly to
pipelines (which are still XML processing pipelines ;-) here you could
eliminate the aliasing internal 'redirect'; you just map a set of requests
to the same processing:

"foo(*)", "bar(*)" -> pipeline baz(param: {1})

the delegating internal 'redirect' wouldn't be needed anymore since you
could directly call pipelines by name (which is also more maintainable than
making it part of the URI space). think of ...

or you map to a flow controller, or to a reader, ...

there's so many problems such a cleanup would solve...

I've been thinking about it for a while and I'm considering starting an
alternative Processor implementation.

example snippet ( converted to a serializer):

...
// serializer contract: SAX input, no SAX output
serializer amore2pml
{
xsltc  src: cocoon://emotion/core/stylesheets/layout.xsl
cinclude  support-caching: true, expires: 86400
xsltc  src: stylesheets/vodafone-de.xsl, contextpath:
{sitemap-context:context-path}
xsltc  src: stylesheets/adapt.xsl
i18n  locale: de
xsltc  src: cocoon://emotion/core/stylesheets/amore2pml.xsl,
service-name: eMotion
vizzavi-image
partner-ml
}
...

generators:
// generator contract: no SAX input, SAX output
generator header(which)
{
file src: headers/{which}.xml   // use file generator
}

generator footer(which)
{
file src: footers/{which}.xml
}

well, I'll stop now...

> -Ursprungliche Nachricht-
> Von: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] Auftrag
> von Carsten Ziegeler
> Gesendet: Montag, 8. Marz 2004 12:31
> An: [EMAIL PROTECTED]
> Betreff: RE: [RT] Forwarding of internal pipeline calls
>
>
> Unico Hommes wrote:
>
> > I am just thinking whether it'd be worth a separate protocol
> > something like forward://something ?
> >
> Yes, I thought of this as well. Unfortunately we have to many hardcoded
> places, where against the protocol name "cocoon:" is tested. So if
> we provide a new protocol we have to change all those places as well.
>
> And we have to come up with a good name, as
> 
> might look at little bit strange :)
>
> Carsten
>

Re: [RT] Forwarding of internal pipeline calls

Carsten Ziegeler wrote:

Unico Hommes wrote:
 

Carsten Ziegeler wrote:

   

Unico Hommes wrote:



 

I am just thinking whether it'd be worth a separate 
   

protocol something 
   

like forward://something ?

  

   

Yes, I thought of this as well. Unfortunately we have to 
 

many hardcoded 
   

places, where against the protocol name "cocoon:" is tested. 
 

So if we 
   

provide a new protocol we have to change all those places as well.

And we have to come up with a good name, as  might look at little bit strange :)

 

O I thought you meant by forward the behavior that error 
handling would 
be forwarded to the called pipeline and that the default 
behavior should 
be that errors are handled by the calling pipeline. 
   

Yes, I meant that :) I think the word "forward" is good for a 
redirect (map:redirect-to uri="forward://sggd" but not
for a general source definition (map:generate src="forward://")

 

Hmm I see. It would be more clear if the opposite of forward:// would be 
include:// (also the servlet api terminology) but we already have 
cocoon:// . I guess it's not worth deprecating cocoon:// in favor of 
forward:// and include:// would it?

In that 
case it may 
be a lot less places where it had to change?
   

Why? Perhaps we meant the same?

 

What should be the default behavior?

   

The default should be as it is now.

 

Confusion abound :-) I see I was mixing things up. Sorry for that. I get 
it now.

Unico

Re: Another advantage using Java 1.4

2004-03-08 Thread Upayavira

Unico Hommes wrote:

Antonio Gallardo wrote:

Hi:

If we will have 1.4 as a minimum requirement for Cocoon 2.2, we can take
advantage of parallel building in Cocoon:
http://ant.apache.org/manual/CoreTasks/parallel.html

I wonder how much we can reduce the building time by compiling blocks in
parallel thread.
 

I doesn't look to me that 1.4 is a requirement for this task. Is it?
No. Only the 'threadsPerProcessor' attribute requries 1.4.

Upayavira

DO NOT REPLY [Bug 27432] - Malformed HTTP headers (debug information in Parameters object)

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

Malformed HTTP headers (debug information in Parameters object)





--- Additional Comments From [EMAIL PROTECTED]  2004-03-08 12:13 ---
I just commited a fix for this problem.

RE: [RT] Forwarding of internal pipeline calls

Unico Hommes wrote:
> 
> Carsten Ziegeler wrote:
> 
> >Unico Hommes wrote:
> >
> >  
> >
> >>I am just thinking whether it'd be worth a separate 
> protocol something 
> >>like forward://something ?
> >>
> >>
> >>
> >Yes, I thought of this as well. Unfortunately we have to 
> many hardcoded 
> >places, where against the protocol name "cocoon:" is tested. 
> So if we 
> >provide a new protocol we have to change all those places as well.
> >
> >And we have to come up with a good name, as  >src="forward://something"/> might look at little bit strange :)
> >  
> >
> 
> O I thought you meant by forward the behavior that error 
> handling would 
> be forwarded to the called pipeline and that the default 
> behavior should 
> be that errors are handled by the calling pipeline. 
Yes, I meant that :) I think the word "forward" is good for a 
redirect (map:redirect-to uri="forward://sggd" but not
for a general source definition (map:generate src="forward://")


> In that 
> case it may 
> be a lot less places where it had to change?
Why? Perhaps we meant the same?

> What should be the default behavior?
> 
The default should be as it is now.

Carsten

Re: First pass at Apache Wiki conversion

On 06 Mar 2004, at 23:40, Upayavira wrote:

Please let me know your comments, publically or privately, so that we 
can get this site working really well.
Spaces in between [] (JSPWiki) should be collapsed, I think: [Steven 
Noels] -> StevenNoels

We should also cater for [SN|Steven Noels] -> StevenNoels

\\ should be replaced by [[BR]]

Will hunt for some more.


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

Re: Another advantage using Java 1.4

Antonio Gallardo wrote:

Hi:

If we will have 1.4 as a minimum requirement for Cocoon 2.2, we can take
advantage of parallel building in Cocoon:
http://ant.apache.org/manual/CoreTasks/parallel.html

I wonder how much we can reduce the building time by compiling blocks in
parallel thread.
 

I doesn't look to me that 1.4 is a requirement for this task. Is it?

Unico

Re: [OT?] File upload weirdness on MacOSX

2004-03-08 Thread Jeremy Quinn

On 4 Mar 2004, at 11:26, Sylvain Wallez wrote:

Hi all,

This is a bit OT, but I encountered some problems with file uploads on  
MacOSX, using the woody upload sample  
(http://localhost:/samples/woody/upload):

- with Safari, no upload happens at all! I checked the incoming  
stream, and the file input is simply not sent.

- with Mozilla, accented letters in filenames are sent as the  
unaccented letter followed by the accent as an XML entity (e.g. "é" is  
sent as "é", 769 being the unicode for "combining acute  
accent"). Is this notation allowed by the http RFC??

Weird...

Any hints?
I know ... I am way behind with this list !!!

I just tried the Woody Upload sample with cocoon 2.1.4, and it appeared  
to work correctly (it showed the uploaded document on the 'success'  
screen). I uploaded the file :
	file://localhost/Users/jerm/Development/Libs/Apache/cocoon-2.1.4/ 
CREDITS.txt

Have not tested Mozilla.

HTH

regards Jeremy


smime.p7s
Description: S/MIME cryptographic signature

Re: [RT] Forwarding of internal pipeline calls

Carsten Ziegeler wrote:

Unico Hommes wrote:

 

I am just thinking whether it'd be worth a separate protocol 
something like forward://something ?

   

Yes, I thought of this as well. Unfortunately we have to many hardcoded
places, where against the protocol name "cocoon:" is tested. So if
we provide a new protocol we have to change all those places as well.
And we have to come up with a good name, as 
 
might look at little bit strange :)
 

O I thought you meant by forward the behavior that error handling would 
be forwarded to the called pipeline and that the default behavior should 
be that errors are handled by the calling pipeline. In that case it may 
be a lot less places where it had to change?
What should be the default behavior?

--
Unico

RE: [RT] Forwarding of internal pipeline calls

Unico Hommes wrote:

> I am just thinking whether it'd be worth a separate protocol 
> something like forward://something ?
> 
Yes, I thought of this as well. Unfortunately we have to many hardcoded
places, where against the protocol name "cocoon:" is tested. So if
we provide a new protocol we have to change all those places as well.

And we have to come up with a good name, as 
 
might look at little bit strange :)

Carsten

Re: [RT] Forwarding of internal pipeline calls

Carsten Ziegeler wrote:

While using internal cocoon redirects, I found out that there are
potential problems with error handling (it might be that we have
discusses this already...).
Now, if you do a:

than this is an internal pipeline call (and not a new http request).
This has of course some advantages (e.g. performance etc), but
has imho the drawback that in this case, the error handling
of the calling pipeline is *always* used. This means if an error
occurs while processing the "something" pipeline, the error
handler of the pipeline containing the redirect-to is invoked.
Now, in general this might be a good solution for internal pipeline
calls when they are used in a map:generate etc., but it's imho
a little unusal for a redirect.
We had recently the discussion on this list, if we need a general
solution to specify which error handler is used for internal pipeline
calls. I discussed this a little bit with Vadim on IRC during our
first friday and he suggest to specify this not on the caller but
on the called pipeline. So the map:pipeline containing the
"something" pipeline specifies what to do. Regardless if this is
the better choice than specifying it in the uri ("cocoon:"),
it's technically nearly impossible. When the internal pipeline
is called, everything happens outside the treehandler and there is
no real chance to get the error handler etc. (Of course we could
change something here and there and then it will work.)
So, I just tried the other way:

The current implementation I have can only be used for redirects,
although it's fairly simple to extend it to be used in
map:generate etc. as well.
WDYT? Is this of general interest?

 

I am just thinking whether it'd be worth a separate protocol something 
like forward://something ?

--
Unico

[RT] Forwarding of internal pipeline calls

While using internal cocoon redirects, I found out that there are
potential problems with error handling (it might be that we have
discusses this already...).

Now, if you do a:


than this is an internal pipeline call (and not a new http request).
This has of course some advantages (e.g. performance etc), but
has imho the drawback that in this case, the error handling
of the calling pipeline is *always* used. This means if an error
occurs while processing the "something" pipeline, the error
handler of the pipeline containing the redirect-to is invoked.

Now, in general this might be a good solution for internal pipeline
calls when they are used in a map:generate etc., but it's imho
a little unusal for a redirect.

We had recently the discussion on this list, if we need a general
solution to specify which error handler is used for internal pipeline
calls. I discussed this a little bit with Vadim on IRC during our
first friday and he suggest to specify this not on the caller but
on the called pipeline. So the map:pipeline containing the
"something" pipeline specifies what to do. Regardless if this is
the better choice than specifying it in the uri ("cocoon:"),
it's technically nearly impossible. When the internal pipeline
is called, everything happens outside the treehandler and there is
no real chance to get the error handler etc. (Of course we could
change something here and there and then it will work.)

So, I just tried the other way:


The current implementation I have can only be used for redirects,
although it's fairly simple to extend it to be used in
map:generate etc. as well.

WDYT? Is this of general interest?

Carsten 

Carsten Ziegeler 
Open Source Group, S&N AG
http://www.osoco.net/weblogs/rael/

Re: Experience with workflow at Hippo Webworks

2004-03-08 Thread Johan Stuyts

On Mon, 08 Mar 2004 11:41:12 +0100, Unico Hommes <[EMAIL PROTECTED]> wrote:

Johan Stuyts wrote:

On Fri, 05 Mar 2004 17:18:53 -0500, Stefano Mazzocchi 
<[EMAIL PROTECTED]> wrote:

Johan Stuyts wrote:

Experience with workflow at Hippo Webworks
==
At Hippo we used OSWorkflow to implement a workflow solution in a 
demo.
Below are our experiences.

As people with different levels of experience are interested in 
workflow
I will start with a (very) brief introduction to workflow.

Workflow introduction
-
Very simply put workflow serves two purposes:
- to determine who can do what at which time with an object;
- to generate a list of pending tasks for users.
An example of the first is that an editor (who) can only publish (do
what) a document (an object) after a writer has asked for a review (at
which time).
The lists of documents to be reviewed is an example of a pending task
list for an editor.
Each object type can have its own specific workflow.

The demo workflow
-
The demo we created has a workflow for a basic document type, a web
page. I have attached a diagram of it.
A document gets created by a writer. The writer is not allowed to
publish his document directly, he has to ask the editor for review.
The editor can easily review documents because we generate a list of
documents waiting for review. The editor can click on the document and
can either approve or disapprove. If the document gets approved it is
published on the public server.
If the document gets disapproved the writer can not ask for a review
without editing it first. Editing the document when it has been 
approved
will bring the document back to the editing state too. After making 
his
changes the user can ask for a review of the new version.

Implementation
--
For the document repository we use Slide. For the workflow engine we
used OSWorkflow. We connected these two using Slide interceptors.


wow, supercool!! I want it :-)

When a document is created the interceptor checks to see whether a
workflow already exists. It does this by retrieving the workflow ID 
from
a WebDAV property of the document. If it doesn't exist a new workflow 
is
created in the workflow store.


Interesting terminology you use here: let me ask you this before we get
confused: "workflow" is for you an instance of the model or the model
itself?


I use the same term for both the model and the instance :">


When our frontend retrieves the tree of documents, the interceptor 
will
retrieve the workflow for each document.


Seems to be the instance. Ok, careful though, because normally people
refer to workflow as the "model", not the instance.


I will be more explicit in further messages.


Looking at the role of the user
the interceptor will determine which actions are enabled. The enabled
actions (including their display text and activation URLs) are set in 
a
WebDAV property of the document.

For the generation of the pending task list we used the OSWorkflow 
query
API to generate the documents which are in the waiting-for-review 
state.
The approve and disapprove actions are passed to the frontend in the
same way as the commands for a writer.

Not all actions are directly shown in the menu, because the user 
invokes
them implicitly. The edit action for example is invoked by the
interceptor each time the user saves the document.

Issues
--
We encountered issues with both slides and OSWorkflow during the
implementation.
Before we used Slide, we used the Cocoon repository. The semantics of
the repository interceptors and the Slide interceptors is not the 
same.
With the repository interceptor we were able to add a property to the
document in postStoreContent(...). In Slide we had to do this in
preStoreContent(...).


IMHO, makes more sense to add metadata in pre-saving than in
post-saving. It's way more efficient for clustered environments.


I dont't care what's better. I just thought that two technologies used 
heavily in Cocoon having different semantics for the same concept was 
confusing.

Well I care. The interception mechanism in the repository was crafted 
after Slide's. If there are diverging semantics or you need extra 
functionality it can be fixed quite easily.


Apart from that the Slide interceptors work very well, but (in the
version of Slide we used) they get called a lot. A single store of a
document invoked preStoreContent(...) and postStoreContent(...) 
multiple
times.


well, this is a bug then. there should be a way to connect to an atomic
event for a content store... you might want to bring this up on 
slide-dev


OK. I will look into this (making sure we don't add the same 
interceptor multiple times).

Interception in Slide is quite low level. For instance, when verioning 
is turned on one WebDAV PUT will typically result in 2n pre- and 2n post 
store operations calls where n is the number of versions the resource 
will have after transaction commit. (I ev

Re: Experience with workflow at Hippo Webworks

Johan Stuyts wrote:

On Fri, 05 Mar 2004 17:18:53 -0500, Stefano Mazzocchi 
<[EMAIL PROTECTED]> wrote:

Johan Stuyts wrote:

Experience with workflow at Hippo Webworks
==
At Hippo we used OSWorkflow to implement a workflow solution in a demo.
Below are our experiences.
As people with different levels of experience are interested in 
workflow
I will start with a (very) brief introduction to workflow.

Workflow introduction
-
Very simply put workflow serves two purposes:
- to determine who can do what at which time with an object;
- to generate a list of pending tasks for users.
An example of the first is that an editor (who) can only publish (do
what) a document (an object) after a writer has asked for a review (at
which time).
The lists of documents to be reviewed is an example of a pending task
list for an editor.
Each object type can have its own specific workflow.

The demo workflow
-
The demo we created has a workflow for a basic document type, a web
page. I have attached a diagram of it.
A document gets created by a writer. The writer is not allowed to
publish his document directly, he has to ask the editor for review.
The editor can easily review documents because we generate a list of
documents waiting for review. The editor can click on the document and
can either approve or disapprove. If the document gets approved it is
published on the public server.
If the document gets disapproved the writer can not ask for a review
without editing it first. Editing the document when it has been 
approved
will bring the document back to the editing state too. After making his
changes the user can ask for a review of the new version.

Implementation
--
For the document repository we use Slide. For the workflow engine we
used OSWorkflow. We connected these two using Slide interceptors.


wow, supercool!! I want it :-)

When a document is created the interceptor checks to see whether a
workflow already exists. It does this by retrieving the workflow ID 
from
a WebDAV property of the document. If it doesn't exist a new 
workflow is
created in the workflow store.


Interesting terminology you use here: let me ask you this before we get
confused: "workflow" is for you an instance of the model or the model
itself?


I use the same term for both the model and the instance :">


When our frontend retrieves the tree of documents, the interceptor will
retrieve the workflow for each document.


Seems to be the instance. Ok, careful though, because normally people
refer to workflow as the "model", not the instance.


I will be more explicit in further messages.


Looking at the role of the user
the interceptor will determine which actions are enabled. The enabled
actions (including their display text and activation URLs) are set in a
WebDAV property of the document.
For the generation of the pending task list we used the OSWorkflow 
query
API to generate the documents which are in the waiting-for-review 
state.
The approve and disapprove actions are passed to the frontend in the
same way as the commands for a writer.

Not all actions are directly shown in the menu, because the user 
invokes
them implicitly. The edit action for example is invoked by the
interceptor each time the user saves the document.

Issues
--
We encountered issues with both slides and OSWorkflow during the
implementation.
Before we used Slide, we used the Cocoon repository. The semantics of
the repository interceptors and the Slide interceptors is not the same.
With the repository interceptor we were able to add a property to the
document in postStoreContent(...). In Slide we had to do this in
preStoreContent(...).


IMHO, makes more sense to add metadata in pre-saving than in
post-saving. It's way more efficient for clustered environments.


I dont't care what's better. I just thought that two technologies used 
heavily in Cocoon having different semantics for the same concept was 
confusing.

Well I care. The interception mechanism in the repository was crafted 
after Slide's. If there are diverging semantics or you need extra 
functionality it can be fixed quite easily.


Apart from that the Slide interceptors work very well, but (in the
version of Slide we used) they get called a lot. A single store of a
document invoked preStoreContent(...) and postStoreContent(...) 
multiple
times.


well, this is a bug then. there should be a way to connect to an atomic
event for a content store... you might want to bring this up on 
slide-dev


OK. I will look into this (making sure we don't add the same 
interceptor multiple times).

Interception in Slide is quite low level. For instance, when verioning 
is turned on one WebDAV PUT will typically result in 2n pre- and 2n post 
store operations calls where n is the number of versions the resource 
will have after transaction commit. (I even suspect the factor 2 in that 
is actually the number of stores configured for the

Re: Experience with workflow at Hippo Webworks

2004-03-08 Thread Johan Stuyts

On Sun, 07 Mar 2004 21:47:26 +0100, Gianugo Rabellino <[EMAIL PROTECTED]> 
wrote:

Guido Casper wrote:

Gianugo Rabellino wrote:
For one, this might buy usage of some well-established worflow 
description languages, such as XPDL or BPEL: this would mean, in turn, 
being able to use existing tools to manage the workflow configuration.

This is a very important point IMO: workflow configuration shouldn't 
belong to programmers: it's a job for business people who shouldn't 
give a damn about Java/Javascript/XML, then need drawing tools.


That's perfectly fine. It just doesn't reflect my current use case :-) 
I can imagine something like that for workflow logic just not for page 
flow logic.
What is the difference among the two? "Page flow logic" means navigation 
to me, while workflow (in CMS) is a way to describe formally a process 
of any kind that affects the lifecycle of a resource. Now, this actually 
means "how a resource gets published" in its most simple incarnation 
(and granted I've seen so many overcomplex workflow in planning stage 
become a "publish" button in production), but ir could be more complex 
than that.



  

  
  


  
  

  
  ...

I'm afraid it's not that simple. Your workflow allows only for a 
linear flow, where you have only one way to go in the opposite 
directions (back and forth). But quite often you need to be able to 
model n ways in or out, you might need conditionals, you might need 
vetoes, and so on and on: workflow is a messy beast to handle.


Gianugo, this configuration is not meant to be a description of my 
workflow.
It's a definition of what state objects are available.
Doesn't quite looke like that: you seem to be mixing states and 
transitions, by explicitely telling States which are the back and forth 
states (here transitions are opaque). IMO you should have lists of 
states, list of transitions and then something to glue them together 
(much like woody^H^H^H^H^Hcforms does for definition and template).
I do not agree with you here. A state machine is a single concern for me. 
Separating a state machine into states and transitions which are defined 
at different locations makes everything more difficult to understand.

The Lenya workflow definition XML places the transitions below the states 
and I find this very inconvenient. A transition is bound to the source 
state. When I am in a particular state I want to know where I can go next. 
I have never needed to know where I came from. If you care about this, 
then you don't have a state machine (maybe you should split states). The 
current state should provide enough context for handling the next action 
that gets invoked.

The only reuse I see are the functions that get called for evaluating 
conditions, when entering a state and when leaving a state.


The actual workflow is made up of the State objects themselves (as I 
said, the workflow is coded in Java, not in XML). Actually "State 
object" might be misnamed (I just took it from the state pattern) as 
they don't hold any state (or other data) but get instantiated by the 
workflow engine when reading the current state of an object. They just 
hold the conditional logic. This means, looking at the state objects 
you don't see the overall workflow. But that's the whole idea. You just 
code isolated steps and decisions of workflow since every workflow may 
be broken down into isolated steps.

The alternative would be to have a giant nested case statement.
Well, isn't it what the actual workflow is? What you do in the typical 
scenario is:

a) define states;
b) define transitions;
c) persist the state as an object attribute;
d) get the state attribute and run a gian nested case statement.
The State pattern embellishes all this mess, but it's still there 
nevertheless: somewhere you have to put the switchboard anyway.

The major drawback currently is that my AbstractState has to know 
about all the other states (to prevent each State class having to 
know about all the other states) and (when adding NewState) has to be 
updated with: allowEnterNewState(doc, user) {return false;}
Hmmm... I see that all your samples refer to user objects flying around: 
aren't you mixing concerns here? User verification belongs to the 
authorization level...
The authorization has to be performed on individual actions and not on the 
whole object. Also the roles of a person are not global, but document 
specific. If you have a big site it is possible you have an editor for 
each section of the site. If the authorization level is capable of 
performing this kind of authorization, the authorization should be moved 
here ofcourse.


This sounds a bit overwhelming, there are too many dependencies to 
account for and you end up with a very proprietary and not reusable 
code.
What depencies do you mean? Actually I found changing workflow very 
easy and flexible as long as you don't come up with new states.
... which is exactly the point of user-defined workflows.

It is

Re: [VOTE] Rename Rhino-with-continuations packages