DO NOT REPLY [Bug 28869] - I18nTransformer: unmatched brackets cause OutOfMemoryError

[bugzilla]

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

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

I18nTransformer: unmatched brackets cause OutOfMemoryError





--- Additional Comments From [EMAIL PROTECTED]  2004-05-11 06:22 ---
Oops, forgot to mention, this is the file that serves as the basis for
generation of messages_*.xml. But I checked the generated file, and it copies
the mismatched brackets faithfully. In the generated file it looks like this: 


Ihr Guthaben: {0] {1}


Yes, I also thought it strange that it didn't have problems until the faulty
translation is called, instead of when any translation in the file is called. 
I've since expanded my unit test to check for mismatched brackets... ;-)

Re: Using CocoonBean in a CocoonServlet

[Upayavira]

Sylvain Wallez wrote:

Upayavira wrote:

Sylvain Wallez wrote:

Hi folks,

In one of our projects, we use CocoonBean in a CocoonServlet 
environment to dump a collection of generated documents on disk. 
Doing this, we encountered two problems:

- CocoonComponentManager.checkEnvironment barfs and throws an 
Exception since the servlet environment exists on the stack when the 
CocoonBean starts its processing.
 Obvious solution is to remove this test, as indicated in the 
method's comments.


I'm okay with it. Although it would be better if the Bean within a 
servlet could share the Cocoon object, along with all that goes with 
it. That would make the Bean really quick to start up. I believe 
Unico had ideas about this.


If the CLI and Servlet environments were sharing the same Cocoon 
object, the CLI wouldn't load a logkit.xconf and there would therefore 
be no problem.

But in my particular case, it's better for the two environments not to 
share the same Cocoon object, as this allows to cleanly separate the 
application front end (the CocoonServlet) from the publishing part 
(the CocoonBean).
Does this mean that you have two webapps? I guess my ideal would be one 
bean per webapp. Is that what you mean by "clean separation"?

What do you do about the slow startup of the bean? It needs to 
initialise an entire Cocoon instance before it can do anything. Do you 
run the bean in the background, or keep a app context bean? Would it 
help if the bean was known to work in multithreaded environments?

Regards, Upayavira

Sylvain

DO NOT REPLY [Bug 28889] - jetty-4.2.19.jar seems compiled for +jdk1.4

[bugzilla]

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

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

jetty-4.2.19.jar seems compiled for +jdk1.4

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|RESOLVED|CLOSED

DO NOT REPLY [Bug 25321] - [Roadmap] Cocoon - NEXT release

[bugzilla]

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

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

[Roadmap] Cocoon - NEXT release

This bug depends on bug 28889, which changed state:

   What|Old Value   |New Value

 Status|NEW |RESOLVED
 Resolution||FIXED

DO NOT REPLY [Bug 28889] - jetty-4.2.19.jar seems compiled for +jdk1.4

[bugzilla]

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

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

jetty-4.2.19.jar seems compiled for +jdk1.4

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED



--- Additional Comments From [EMAIL PROTECTED]  2004-05-11 03:21 ---
jetty was updated from Forrest. Thanks Juan Jose.

Re: [QVote] Release 2.1.5 on May 14th

[David Crossley]

Joerg Heinicke wrote:
> David Crossley wrote:
> > The FirstFriday was a little bit active and some Bugzilla
> > issues were addressed. The Roadmap shows that there are some
> > major problems still:
> > http://nagoya.apache.org/bugzilla/showdependencytree.cgi?id=25321
> > 
> > Do we really want to release in this state?
> 
> Yes, we should IMO. Open issues are
> 
> 22842
> flow: importPackage/importClass problems creating InitialContext()
> => bug is half a year old, we released it already
>
> 25083
> JXTemplate evaluates expressions in comments, need jx:comment?
> => minor issue
> 
> 25285
> Processing pipelines from within flowscript and get various results objects
> => assigned to Sylvain ;-)

Sylvain reminded that it is now closed.

> 25203
> SQLTransformer: duplicate namespace declaration when serializing XML
> => extremely old, I tried to reproduce it on Friday and did not get it
> 
> 26753
> Persistent store or cache corruption?
> => For that one we might change the default store.

That was one of the options that was discussed at last
FirstFriday on IRC. However, no-one has done anything
and now we are in a code freeze.

> 27467
> Upgrade all source files to ASF 2.0 license
> => That's of course a *must*.

There are various outstanding issues. IIRC the community
decided to release anyway.

> 28680
> HTML serialization has no space between publicId and systemId
> => Don't know about it, but it seems Xalan related - though you
> wrote it does not happen on command line.

It seems silly to release something that we know will produce
broken output.

--David

DO NOT REPLY [Bug 28889] - jetty-4.2.19.jar seems compiled for +jdk1.4

[bugzilla]

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

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

jetty-4.2.19.jar seems compiled for +jdk1.4





--- Additional Comments From [EMAIL PROTECTED]  2004-05-11 00:57 ---
You can download from Forrest svn.
http://svn.apache.org/viewcvs.cgi/xml/forrest/trunk/tools/jetty/?root=Apache-SVN

DO NOT REPLY [Bug 25321] - [Roadmap] Cocoon - NEXT release

[bugzilla]

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

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

[Roadmap] Cocoon - NEXT release

[EMAIL PROTECTED] changed:

   What|Removed |Added

  BugsThisDependsOn||28889

DO NOT REPLY [Bug 28889] - jetty-4.2.19.jar seems compiled for +jdk1.4

[bugzilla]

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

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

jetty-4.2.19.jar seems compiled for +jdk1.4

[EMAIL PROTECTED] changed:

   What|Removed |Added

OtherBugsDependingO||25321
  nThis||
   Severity|Normal  |Blocker



--- Additional Comments From [EMAIL PROTECTED]  2004-05-11 00:54 ---
This would be indeed a blocker for the release.

DO NOT REPLY [Bug 28889] New: - jetty-4.2.19.jar seems compiled for +jdk1.4

[bugzilla]

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

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

jetty-4.2.19.jar seems compiled for +jdk1.4

   Summary: jetty-4.2.19.jar seems compiled for +jdk1.4
   Product: Cocoon 2
   Version: Current CVS 2.1
  Platform: All
OS/Version: All
Status: NEW
  Severity: Normal
  Priority: Other
 Component: core
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


[EMAIL PROTECTED]:~/xml/cocoon-2.1$ java -version
java version "1.3.1_10"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.1_10-b03)
Java HotSpot(TM) Client VM (build 1.3.1_10-b03, mixed mode)

[EMAIL PROTECTED]:~/xml/cocoon-2.1$ ./cocoon.sh servlet
./cocoon.sh: using ./build/webapp as the webapp directory
 Loading 
Processing repository: ./tools/jetty/lib
Adding jar: ./tools/jetty/lib/jetty-4.2.19.jar
Adding jar: ./tools/jetty/lib/servlet-2.3.jar
Processing repository: ./lib/endorsed
Adding jar: ./lib/endorsed/xalan-2.6.0.jar
Adding jar: ./lib/endorsed/xercesImpl-2.6.2.jar
Adding jar: ./lib/endorsed/xml-apis.jar
Adding jar: ./lib/endorsed/jakarta-bcel-20040329.jar
Adding jar: ./lib/endorsed/jakarta-regexp-1.3.jar
 Executing -
Main Class: org.mortbay.jetty.Server
Exception in thread "main" java.lang.reflect.InvocationTargetException:
java.lang.NoSuchMethodError
at org.mortbay.util.Resource.newResource(Resource.java:95)
at org.mortbay.jetty.Server.(Server.java:63)
at org.mortbay.jetty.Server.main(Server.java:428)
at java.lang.reflect.Method.invoke(Native Method)
at Loader.invokeMain(Unknown Source)
at Loader.run(Unknown Source)
at Loader.main(Unknown Source)


This error dissapear on jdk 1.4.

International apache branches

[Scherler, Thorsten]

Hello Greg, cocoon devs, forrest devs, lenya devs.

I am thinking about to open up a cocoon/-lenya site in Spain.
There is a growing community and the majority wants to communicate in 
spanish.

Does anybody knows what the ASF policy for international branches is 
(Greg as chairman)?

Can it be a direct spin-off of e.g. lenya (like e.g. 
http://www.xaraya.com/ and http://es.xaraya.com/)?

Could it be then hosted like http://es.cocoon.apache.org/lenya/ or 
http://cocoon.apache.org/lenya/es/?

How forrest deals with i18n?

Any help, input, links or thoughts are highly welcome.

King regards
Thorsten
--

 Thorsten Scherler
 Spain
 <@mail> [EMAIL PROTECTED]
 <@cocoon-WIKI> 
http://wiki.cocoondev.org/Wiki.jsp?page=Scherler

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

[Hunsberger, Peter]

Askild Aaberg Olsen <[EMAIL PROTECTED]> writes:
 
> 
> A link from http://www.mattkruse.com/javascript/calendarpopup/
> leads to http://www.webreference.com/dhtml/diner/seethru/


Ugg! Haven't seen this with our code, have seen problems that Z-order
fixes, at least with IE 5.5 and above (all that we've tested).  Yet
another reason to move to Flash

> 
> Askild
> -
> 
> Marc Portier wrote:
> > Hi all,
> > 
> > I just checked in an update for one of our cforms samples
> > that reveals a 
> > somewhat nasty visual presentation of the nice calendar 
> widget we use
> > 
> > please update, build, start cocoon and check over with:
> > http://localhost:/samples/blocks/forms/for> m1.flow
> > then 
> > click the calendar icon next to the 'birthday' 
> > field
> > 
> > 
> > if placed just above a (multi-line) selection list (like done
> > now) the 
> > calendar popup seems to be kept behind that selection list...
> > 
> > anyone that has a clue what is causing this?
> > 
> > regards
> > -marc=
> 
> 
> 

DO NOT REPLY [Bug 27957] - JSP content type overrides serializer

[bugzilla]

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

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

JSP content type overrides serializer





--- Additional Comments From [EMAIL PROTECTED]  2004-05-10 22:08 ---
No, you're right.  According to proper usage of readers, the mime-type should be
specified as a parameter to the reader in the sitemap.  The mime-type should not
be able to be set from the JSP page itself.

Re: [cforms] getWidget removal affecting 2.1.5 release?

[Sylvain Wallez]

Marc Portier wrote:

hey there,

last friday (before codefreeze) I checked in the new lookupWidget and 
the getWidget to getChild rename...

the first makes every widget a natural starting point for widget-tree 
navigation using a path-like expression (even including construct like 
../)

the latter was based on some recent discussion that indicated the 
higher semantical value of getChild over getWidget, and accorded 
better with the getParent counterpart...

this last change however has quite some impact on existing 
installations: current cforms users will need to run through their 
code to search/replace getWidget to getChild (or lookupChild in fact)

out of convenience to our users we might do slightly more though
- clear documentation on the woody2cforms page
and then apply some more gentle phasing out approach of deprecation by
- re-introduce the getwidget, but make it deprecated
in which case we should decide if the implementation should
[ ] just work
[ ] log a warning and keep on working
[X] fail with some RTE


If we have decided to change the API (and I'm +1 for this one), then 
let's do it quick, and fail hard to ease migration of existing 
applications. There's nothing worse than something that used to work but 
no more does with no particular reason. Sometimes, the dynamic nature of 
JavaScript doesn't help...

We'll remove the getWidget() method completely later.

Sylvain

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

Re: Using CocoonBean in a CocoonServlet

[Sylvain Wallez]

Upayavira wrote:

Sylvain Wallez wrote:

Hi folks,

In one of our projects, we use CocoonBean in a CocoonServlet 
environment to dump a collection of generated documents on disk. 
Doing this, we encountered two problems:

- CocoonComponentManager.checkEnvironment barfs and throws an 
Exception since the servlet environment exists on the stack when the 
CocoonBean starts its processing.
 Obvious solution is to remove this test, as indicated in the 
method's comments.


I'm okay with it. Although it would be better if the Bean within a 
servlet could share the Cocoon object, along with all that goes with 
it. That would make the Bean really quick to start up. I believe Unico 
had ideas about this.


If the CLI and Servlet environments were sharing the same Cocoon object, 
the CLI wouldn't load a logkit.xconf and there would therefore be no 
problem.

But in my particular case, it's better for the two environments not to 
share the same Cocoon object, as this allows to cleanly separate the 
application front end (the CocoonServlet) from the publishing part (the 
CocoonBean).

Sylvain

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

Re: Using CocoonBean in a CocoonServlet

[Sylvain Wallez]

Carsten Ziegeler wrote:

Sylvain Wallez wrote:
 

Hi folks,

In one of our projects, we use CocoonBean in a CocoonServlet 
environment to dump a collection of generated documents on 
disk. Doing this, we encountered two problems:

- CocoonComponentManager.checkEnvironment barfs and throws an 
Exception since the servlet environment exists on the stack 
when the CocoonBean starts its processing.
 Obvious solution is to remove this test, as indicated in 
the method's comments.

   

I would be happy if we could leave the check in. This is to
find a bug that sits somewhere deep in the core of Cocoon and
is very rarely to reproduce. I hope that there will be the
day when someone is able to have a reproducable test case.
Isn't there a better way?
 

Mmmh... the environment stack cannot be empty, since CocoonServlet is 
calling CocoonBean.

The only solution I can see so far, but which looks hacky, would be to 
push a special "marker environment" that would demarcate the 
CocoonServlet environment stack from that of the CocoonBean. We could 
then have checkEnvironment() test either an empty stack or that special 
marker environment.

WDYT?

Sylvain

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

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

[JD Daniels]

I fix this the hacky way

put the calendar div inside an iframe
you can manipuliate the iframe the same way as a div.. however i gets slow
if you have a large form with many iframes being moved / toggled

JD

-Original Message-
From: Joerg Heinicke [mailto:[EMAIL PROTECTED]
Sent: May 10, 2004 12:54 PM
To: [EMAIL PROTECTED]
Subject: Re: [heads up] [cforms] problem with calendar popup on ie6


On 10.05.2004 22:21, Marc Portier wrote:

> Hi all,
>
> I just checked in an update for one of our cforms samples that reveals a
> somewhat nasty visual presentation of the nice calendar widget we use
>
> please update, build, start cocoon and check over with:
> http://localhost:/samples/blocks/forms/form1.flow
> then click the calendar icon next to the 'birthday' field
>
>
> if placed just above a (multi-line) selection list (like done now) the
> calendar popup seems to be kept behind that selection list...
>
> anyone that has a clue what is causing this?

No, but I heard about this being "normal" behaviour of IE. Somebody told
me about it last week when talking about CSS/XHTML hacks to not confuse
older browsers - or IE if it does not understand some particular one
like position:fixed
(http://marc.theaimsgroup.com/?t=10579696307&r=1&w=4). But I don't
remember the solution as it was not so important for me. I will ask him.

Joerg

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

[Sylvain Wallez]

Joerg Heinicke wrote:

I wrote:

But I don't remember the solution as it was not so important for me. 
I will ask him. 


http://www.webreference.com/dhtml/diner/seethru/ says:

"This is not a "z-index" issue. There is no fix."


Yep, this is a known IE bug, which affects all absolutely positioned 
divs that overlap a dropdown list.

As far as our calendar s concerned, a workaround is to use the separate 
window mode instead of the div mode, but this doesn't apply to help popups.

Another workaround is to change the form layout so that there's no 
calendar above a dropdown list :-/

Sylvain

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

Re: Moving to subversion - volunteers?

[Joerg Heinicke]

On 10.05.2004 21:55, Andreas Hochsteger wrote:

Could it be, that you rather meant the following:
/cocoon/
 /trunk/ <- current trunk (same as HEAD on CVS)
 /tags/ <- Tags on specific Milestones and Releases
 /branches/ <- Branches of the cocoon repository
 /branches/2.1/ <- Cocoon 2.1 branch
 /branches/new-kernel/ <- current 2.2 code
Yeah, that's what I want. With the additional "lazy branching" for older 
minor releases, i.e. create branch 2.1 only if it is needed for security 
patches for example.

Joerg

Re: [cforms] getWidget removal affecting 2.1.5 release?

[Joerg Heinicke]

On 10.05.2004 21:44, Marc Portier wrote:

this last change however has quite some impact on existing 
installations: current cforms users will need to run through their code 
to search/replace getWidget to getChild (or lookupChild in fact)
I use Cocoon 2.1.4 Woody at my project at the moment. I will probably 
upgrade in near future as there are some fixes in cforms that I would 
like to have (calendar.js, early validation on action widgets). And I 
use getWidget() at the moment heavily, mostly for custom validations. 
So, yes, I would like to have a solution.

out of convenience to our users we might do slightly more though
- clear documentation on the woody2cforms page
Of course this must be documented, but for me this is not enough as I'm 
aware of the change with or without the docu :)

and then apply some more gentle phasing out approach of deprecation by
- re-introduce the getwidget, but make it deprecated
in which case we should decide if the implementation should
[ ] just work
[ ] log a warning and keep on working
[X] fail with some RTE
If we do nothing, I will mostly fail with "undefined value" error, won't 
I? Deprecation is clear. "just work" gives no hint on deprecation, you 
never know that it is deprecated. Logging is also no solution IMO as I 
would need to search the logs for usages. So I prefer the RTE on usages. 
I can click through my application without any need to look anywhere for 
messages where I might have forgotten one getWidget().

Joerg

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

[Joerg Heinicke]

I wrote:

But I don't remember the solution as it was not so important for me. I will ask him. 
http://www.webreference.com/dhtml/diner/seethru/ says:

"This is not a "z-index" issue. There is no fix."

Maybe I had to much beer inside when I thought the guy talked about a 
solution ;-)

Joerg

RE: [VOTE] RE: LogKitLoggerManager

[Ralph Goers]

Maybe, but now we have 3 +1's. :-)
Ralph

-Original Message-
From: Joerg Heinicke [mailto:[EMAIL PROTECTED] 
Sent: Monday, May 10, 2004 1:33 PM
To: [EMAIL PROTECTED]
Subject: Re: [VOTE] RE: LogKitLoggerManager

On 10.05.2004 22:18, Ralph Goers wrote:

> Thanks. So we need at least one more +1 for this. Anybody?

Begging Marketing ;-)

Joerg

Session losing authentication context - still an open bug?

[H . vanderLinden]

Guys,

I've run into a problem that is probably a variation of an old bug. It would
be really nice if this could be solved before 2.1.5.

Problem:

My webapp has it's own sitemap in a separate directory below the standard
Cocoon sitemap in the root dir. I suppose this is a subsitemap, I just keep
forgetting to look at it this way.

I built my authentication along the lines of the Authentication-fw with flow
sample. I've tried building a flowscript function per use case. This works
until I want to move onto the next function. Then I get an error like
"authentication context not found in session". 

Could someone please solve this?

Related: I cannot go from one "protected/pipeline" to the next
"protected/pipeline2" without the above error, so I need to go to the
"public/pipeline" that goes through the "protect" function. If I do that I
loose all the bizData I added to the cocoon.sendPage("public/pipeline",
bizData) statement.

Does anybody know what to do? I now solve it by adding the objects to the
session, but there must be a more elegant way.

Thanks.

Bye, Helma

RE: HELP!!!!! Double coercion exception in flowscript - SOLVED

[H . vanderLinden]

Yes, read the message in search of my problem, but it didn't hit home until
I actually found out it was the continuation id that I messed up. :-(

Bye, Helma

> -Original Message-
> From: Joerg Heinicke [mailto:[EMAIL PROTECTED] 
> Sent: Monday, 10 May 2004 22:20
> To: [EMAIL PROTECTED]
> Subject: Re: HELP! Double coercion exception in 
> flowscript - SOLVED
> 
> 
> On 10.05.2004 16:37, [EMAIL PROTECTED] wrote:
> > The problem was caused by a faulty syntax for the continuation id:
> > 
> > ${continuation/id} should be #{$continuation/id}
> > 
> > Bye, Helma
> > 
> > 
> >>-Original Message-
> >>From: [EMAIL PROTECTED] 
> >>
> >>Hi,
> >>
> >>I run into a double coercion exception when I'm trying to 
> >>display a form using a flowscript.
> 
> http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=107412183108550&w=4
> 
> Item 3.
> 
> ;-)
> 
> Joerg
> 

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

[Joerg Heinicke]

On 10.05.2004 22:21, Marc Portier wrote:

Hi all,

I just checked in an update for one of our cforms samples that reveals a 
somewhat nasty visual presentation of the nice calendar widget we use

please update, build, start cocoon and check over with:
http://localhost:/samples/blocks/forms/form1.flow
then click the calendar icon next to the 'birthday' field
if placed just above a (multi-line) selection list (like done now) the 
calendar popup seems to be kept behind that selection list...

anyone that has a clue what is causing this?
No, but I heard about this being "normal" behaviour of IE. Somebody told 
me about it last week when talking about CSS/XHTML hacks to not confuse 
older browsers - or IE if it does not understand some particular one 
like position:fixed 
(http://marc.theaimsgroup.com/?t=10579696307&r=1&w=4). But I don't 
remember the solution as it was not so important for me. I will ask him.

Joerg

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

[Askild Aaberg Olsen]

A link from http://www.mattkruse.com/javascript/calendarpopup/
leads to http://www.webreference.com/dhtml/diner/seethru/

Askild
-

Marc Portier wrote:
> Hi all,
> 
> I just checked in an update for one of our cforms samples 
> that reveals a 
> somewhat nasty visual presentation of the nice calendar widget we use
> 
> please update, build, start cocoon and check over with: 
> http://localhost:/samples/blocks/forms/for> m1.flow
> then 
> click the calendar icon next to the 'birthday' 
> field
> 
> 
> if placed just above a (multi-line) selection list (like done 
> now) the 
> calendar popup seems to be kept behind that selection list...
> 
> anyone that has a clue what is causing this?
> 
> regards
> -marc=

DO NOT REPLY [Bug 28869] - I18nTransformer: unmatched brackets cause OutOfMemoryError

[bugzilla]

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

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

I18nTransformer: unmatched brackets cause OutOfMemoryError

[EMAIL PROTECTED] changed:

   What|Removed |Added

  Component|core|sitemap components
Summary|Unmatched brackets in i18n  |I18nTransformer: unmatched
   |dictionary cause|brackets cause
   |OutOfMemoryError|OutOfMemoryError



--- Additional Comments From [EMAIL PROTECTED]  2004-05-10 20:49 ---
> 
>   Test
>   This is a {0]
> 

Just curious about this strange notation. Does it work?

> If a page is called which references this translation

Especially the fact that it only happens on references to the translation (not
the file) make this behaviour more weird.

Re: [VOTE] RE: LogKitLoggerManager

[Ugo Cei]

Il giorno 10/mag/04, alle 22:18, Ralph Goers ha scritto:

Thanks. So we need at least one more +1 for this. Anybody?
+1

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

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

[Hunsberger, Peter]

Marc Portier <[EMAIL PROTECTED]> asks:

> 
> Hi all,
> 
> I just checked in an update for one of our cforms samples 
> that reveals a 
> somewhat nasty visual presentation of the nice calendar widget we use
> 
> please update, build, start cocoon and check over with: 
> http://localhost:/samples/blocks/forms/for> m1.flow
> then 
> click the calendar icon next to the 'birthday' 
> field
> 
> 
> if placed just above a (multi-line) selection list (like done 
> now) the 
> calendar popup seems to be kept behind that selection list...
> 
> anyone that has a clue what is causing this?

If it's with IE then there's a bug associated with IE's handling of Z
order for selection lists that might be the problem.  Try something
like:

object.style.zIndex = N;

Where "object" is the thing being obscured and N is either 1 or some
large number, depending on which way the bug is showing up...

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

[Ugo Cei]

Il giorno 10/mag/04, alle 22:21, Marc Portier ha scritto:

I just checked in an update for one of our cforms samples that reveals 
a somewhat nasty visual presentation of the nice calendar widget we 
use
Not just the calendar, also the help popup.

if placed just above a (multi-line) selection list (like done now) the 
calendar popup seems to be kept behind that selection list...

anyone that has a clue what is causing this?
That stupid IE is causing this, I think ;-) Mozilla doesn't, at least 
here. And unfortunately I'm not proficient enough with CSS and DHTML to 
try to fix it.

	Ugo

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

DO NOT REPLY [Bug 27957] - JSP content type overrides serializer

[bugzilla]

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

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

JSP content type overrides serializer





--- Additional Comments From [EMAIL PROTECTED]  2004-05-10 20:37 ---
Couldn't you set the content type in the sitemap for the reader too or is it
dynamical? I mean it is decided in the JSP (what I would find "strange" though),
not you need 3 different types. JSPReader and JSPGenerator use the same
JSPEngine - with all the consequences. We would probably need a parameter then.

Joerg

Re: [VOTE] RE: LogKitLoggerManager

[Joerg Heinicke]

On 10.05.2004 22:18, Ralph Goers wrote:

Thanks. So we need at least one more +1 for this. Anybody?
Begging Marketing ;-)

Joerg

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

[Marc Portier]

Hi all,

I just checked in an update for one of our cforms samples that reveals a 
somewhat nasty visual presentation of the nice calendar widget we use

please update, build, start cocoon and check over with:
http://localhost:/samples/blocks/forms/form1.flow
then click the calendar icon next to the 'birthday' field
if placed just above a (multi-line) selection list (like done now) the 
calendar popup seems to be kept behind that selection list...

anyone that has a clue what is causing this?

regards
-marc=
--
Marc Portierhttp://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog athttp://blogs.cocoondev.org/mpo/
[EMAIL PROTECTED]  [EMAIL PROTECTED]

Re: HELP!!!!! Double coercion exception in flowscript - SOLVED

[Tony Collen]

Joerg Heinicke wrote:
On 10.05.2004 16:37, [EMAIL PROTECTED] wrote:

The problem was caused by a faulty syntax for the continuation id:

${continuation/id} should be #{$continuation/id}

Bye, Helma


-Original Message-
From: [EMAIL PROTECTED]
Hi,
I run into a double coercion exception when I'm trying to display a 
form using a flowscript.


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

Item 3.


Yeah, I'm not fond of the two possible syntaxes, and when I asked about it, I never got a clear 
answer beyond "so you can use either syntax" when I asked why there were two syntaxes to begin with. 
Huh?   I'd like to deprecate one but where would you start?

;-)

Joerg


Tony

RE: [VOTE] RE: LogKitLoggerManager

[Ralph Goers]

Thanks. So we need at least one more +1 for this. Anybody?

Ralph

-Original Message-
From: Carsten Ziegeler [mailto:[EMAIL PROTECTED] 
Sent: Monday, May 10, 2004 12:03 PM
To: [EMAIL PROTECTED]
Subject: RE: [VOTE] RE: LogKitLoggerManager

+1

Just replace my solution.

Carsten 

> -Original Message-
> From: Ralph Goers [mailto:[EMAIL PROTECTED] 
> Sent: Sunday, May 09, 2004 11:09 PM
> To: '[EMAIL PROTECTED]'
> Subject: [VOTE] RE: LogKitLoggerManager
> 
> Yes, this change is backward compatible with 2.1.4, but not 
> with the version Carsten checked in last week.  I'd 
> appreciate a vote to have this patch applied.
> 
> Ralph
> 
> -Original Message-
> From: Joerg Heinicke [mailto:[EMAIL PROTECTED]
> Sent: Sunday, May 09, 2004 1:52 PM
> To: [EMAIL PROTECTED]
> Subject: Re: LogKitLoggerManager
> 
> On 09.05.2004 19:25, Ralph Goers wrote:
> 
> > I've submitted patch 28860. I realize this is after the 
> code freeze, 
> > but
> I'd
> > prefer to see this patch instead of the current code. If 2.1.5 goes 
> > out
> with
> > the current code we would have to maintain the current behavior of 
> > logger-type.
> 
> I guess it's completely backwards compatible (same default 
> behaviour and so on). Then it can go in, but we must vote 
> about it. It's best if you start the vote yourself. But IMO 
> we should not wait 72 h for that vote as we would have only 
> Thursday to test it. 36 h are enough for this case IMO.
> 
> Joerg
> 

Re: HELP!!!!! Double coercion exception in flowscript - SOLVED

[Joerg Heinicke]

On 10.05.2004 16:37, [EMAIL PROTECTED] wrote:
The problem was caused by a faulty syntax for the continuation id:

${continuation/id} should be #{$continuation/id}

Bye, Helma


-Original Message-
From: [EMAIL PROTECTED] 

Hi,

I run into a double coercion exception when I'm trying to 
display a form using a flowscript.
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=107412183108550&w=4

Item 3.

;-)

Joerg

Re: Supersonic block has landed (Power Trio tutorial/example app)

[Upayavira]

Bertrand Delacretaz wrote:

Le 10 mai 04, à 21:21, Joerg Heinicke a écrit :

On 10.05.2004 14:28, Bertrand Delacretaz wrote:

...I think that it should be called the "tour" block, yet still
have the familiar name of "Supersonic Tour"...
Do others have the same opinion? If so I'm ok to rename the block, I 
agree that it's a more descriptive name.


I prefer 'tour' as blockname and 'Supersonic Tour' as name for the 
tour itself. I guess that's the same David suggested.


I also would do this step before the release, supersonic block was 
only introduced some days ago and there are no external dependencies 
on it.


+1 for changing the name before the release (I'm ok with "tour" as I 
said before)
Feel free to do it if you have time, I won't have time before Wednesday.
+1 from me too.

Upayavira

Re: Moving to subversion - volunteers?

[Andreas Hochsteger]

Upayavira wrote:

Nicola Ken Barozzi wrote:

Carsten Ziegeler wrote:

We agreed that we move to subversion as soon as possible.
Next friday we will (hopefully) release 2.1.5, so we
should move right after the release.
Any volunteers for doing this?


Err... what should we actually do?

I mean, let's say that we have decided that the format will be:

/cocoon/ <- this is the repository
  /2.0/
/trunk/  <- trunk of 2.0
/tags/   <- tags of 2.0
  /2.1/
/trunk/  <- trunk of 2.1
/tags/   <- tags of 2.1
IIUC we just need to ask infrastructure to run cvs2svn to the 
cocoon-2.1 and cocoon-2.2 repos and put them under "cocoon" as 2.1 and 
2.2.


Personally, I would leave 2.0 as is, and then:
/cocoon/
 /trunk/ <- current trunk
 /tags/new-kernel/ <- current 2.2 code
Could it be, that you rather meant the following:
/cocoon/
 /trunk/ <- current trunk (same as HEAD on CVS)
 /tags/ <- Tags on specific Milestones and Releases
 /branches/ <- Branches of the cocoon repository
 /branches/2.1/ <- Cocoon 2.1 branch
 /branches/new-kernel/ <- current 2.2 code
The following pages cover especially repository organization, branching
and merging very well:
http://svnbook.red-bean.com/svnbook/ch04.html
http://svnbook.red-bean.com/svnbook/ch04s07.html
For all CVS users which are not yet familar with Subversion I'll
recommend the following link (Subversion for CVS Users):
http://svnbook.red-bean.com/svnbook/apa.html
I would do it this way as, if we are to follow our new versioning 
scheme, we cannot identify the new kernel with the version 2.2, so we 
shouldn't use version numbers in our repository names. We should use 
'feature names' in our branches/tags. E.g. Forrest has its 'copyless' 
branch. So we should have a 'new kernel' branch.
This sounds good to me.

But version numbers should of course be used for Tags (which means a
certain unmutable release) or branches of already released new
major/minor versions where other maintenance releases may follow.
Branches for experimental things (like the new-kernel branch) should
then be merged back to the trunk again, when it is decided to base
further development on it.

Regards, Upayavira

/cocoon
Bye,
Andreas.

[cforms] getWidget removal affecting 2.1.5 release?

[Marc Portier]

hey there,

last friday (before codefreeze) I checked in the new lookupWidget and 
the getWidget to getChild rename...

the first makes every widget a natural starting point for widget-tree 
navigation using a path-like expression (even including construct like ../)

the latter was based on some recent discussion that indicated the higher 
semantical value of getChild over getWidget, and accorded better with 
the getParent counterpart...

this last change however has quite some impact on existing 
installations: current cforms users will need to run through their code 
to search/replace getWidget to getChild (or lookupChild in fact)

out of convenience to our users we might do slightly more though
- clear documentation on the woody2cforms page
and then apply some more gentle phasing out approach of deprecation by
- re-introduce the getwidget, but make it deprecated
in which case we should decide if the implementation should
[ ] just work
[ ] log a warning and keep on working
[ ] fail with some RTE
or we let everybody just live with the consequences of working with 
unstable blocks (in which case the wiki update should suffice)
(of course: if we don't do provide this transition kind of stuff for 
2.1.5 we shouldn't do it at all, so it's now during code freeze or just 
forgetting about it)

reactions welcomed,

-marc=
PS: by the way: on a related issue I'm now convinced we have everything 
in place now to just ditch the ContainerWidget interface, but this is 
more of a hidden change that can easily happen after 2.1.5 (and together 
with all the other stuff that still needs to happen)
--
Marc Portierhttp://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog athttp://blogs.cocoondev.org/mpo/
[EMAIL PROTECTED]  [EMAIL PROTECTED]

Re: [VOTE] RE: LogKitLoggerManager

[Joerg Heinicke]

On 10.05.2004 21:24, Joerg Heinicke wrote:

Argh, I haven't looked at the patch. If it really does change
the Cocoon core class and not just only the servlet than -1
for now. We can intregrate it right after the release.


No, sorry, this information was wrong.
I also know why. I mixed it with the RequestListener patch.

Joerg

Re: Supersonic block has landed (Power Trio tutorial/example app)

[Bertrand Delacretaz]

Le 10 mai 04, à 21:21, Joerg Heinicke a écrit :

On 10.05.2004 14:28, Bertrand Delacretaz wrote:

...I think that it should be called the "tour" block, yet still
have the familiar name of "Supersonic Tour"...
Do others have the same opinion? If so I'm ok to rename the block, I 
agree that it's a more descriptive name.
I prefer 'tour' as blockname and 'Supersonic Tour' as name for the 
tour itself. I guess that's the same David suggested.

I also would do this step before the release, supersonic block was 
only introduced some days ago and there are no external dependencies 
on it.
+1 for changing the name before the release (I'm ok with "tour" as I 
said before)
Feel free to do it if you have time, I won't have time before Wednesday.

-Bertrand

Re: [VOTE] RE: LogKitLoggerManager

[Joerg Heinicke]

On 10.05.2004 21:19, Carsten Ziegeler wrote:

Argh, I haven't looked at the patch. If it really does change
the Cocoon core class and not just only the servlet than -1
for now. We can intregrate it right after the release.
No, sorry, this information was wrong. It touches only the servlet:

Index: CocoonServlet.java
===
RCS file: 
/home/cvspublic/cocoon-2.1/src/java/org/apache/cocoon/servlet/CocoonServlet.java,v

Joerg

Re: Supersonic block has landed (Power Trio tutorial/example app)

[Joerg Heinicke]

On 10.05.2004 14:28, Bertrand Delacretaz wrote:

...I think that it should be called the "tour" block, yet still
have the familiar name of "Supersonic Tour"...


Do others have the same opinion? If so I'm ok to rename the block, I 
agree that it's a more descriptive name.
I prefer 'tour' as blockname and 'Supersonic Tour' as name for the tour 
itself. I guess that's the same David suggested.

I also would do this step before the release, supersonic block was only 
introduced some days ago and there are no external dependencies on it.

Joerg

RE: [VOTE] RE: LogKitLoggerManager

[Carsten Ziegeler]

Argh, I haven't looked at the patch. If it really does change
the Cocoon core class and not just only the servlet than -1
for now. We can intregrate it right after the release.

Carsten 

> -Original Message-
> From: Joerg Heinicke [mailto:[EMAIL PROTECTED] 
> Sent: Monday, May 10, 2004 8:40 PM
> To: [EMAIL PROTECTED]
> Subject: Re: [VOTE] RE: LogKitLoggerManager
> 
> On 10.05.2004 16:42, Ralph Goers wrote:
> 
> > Thanks Joerg,
> > 
> > Maybe I should have marked this as QVOTE since you are the only one 
> > who has replied?
> 
> A qvote here means more or less "If no one objects I will 
> commit". IMO during the code freeze this is not applicable. 
> Also your patch goes into the core, the Cocoon class itself. 
> If there is no common interest we will better leave it out 
> for the release. For a successful vote you need at least 3 
> binding +1 and no veto. So where are the interests?
> 
> Joerg
> 

RE: Using CocoonBean in a CocoonServlet

[Carsten Ziegeler]

Sylvain Wallez wrote:
> 
> Hi folks,
> 
> In one of our projects, we use CocoonBean in a CocoonServlet 
> environment to dump a collection of generated documents on 
> disk. Doing this, we encountered two problems:
> 
> - CocoonComponentManager.checkEnvironment barfs and throws an 
> Exception since the servlet environment exists on the stack 
> when the CocoonBean starts its processing.
>   Obvious solution is to remove this test, as indicated in 
> the method's comments.
> 
I would be happy if we could leave the check in. This is to
find a bug that sits somewhere deep in the core of Cocoon and
is very rarely to reproduce. I hope that there will be the
day when someone is able to have a reproducable test case.
Isn't there a better way?

Carsten

RE: [QVote] Release 2.1.5 on May 14th

[Carsten Ziegeler]

Is there a real blocker in it? Sorry - I have only access to mails
currently (I can't access CVS or web until friday morning...).

The last time I looked there weren't real blockers - or they were
in 2.1.4 already.

Carsten 

> -Original Message-
> From: David Crossley [mailto:[EMAIL PROTECTED] 
> Sent: Monday, May 10, 2004 6:13 AM
> To: [EMAIL PROTECTED]
> Subject: RE: [QVote] Release 2.1.5 on May 14th
> 
> Carsten Ziegeler wrote:
> > Bertrand Delacretaz wrote:
> > > Sylvain Wallez a écrit :
> > > > ...There are still many little things to solidify in the CForms 
> > > > API until it can be marked stable, and therefore Cocoon 
> 2.1.5 will 
> > > > not contain a stable CForms
> > > 
> > > +1, let's not forget to release early, release often.
> > > CForms can still mature after 2.1.5.
> >
> > Exactly.
> > 
> > We shouldn't get into the trap of "we have to finish XYZ 
> before we can 
> > release" again.
> 
> The FirstFriday was a little bit active and some Bugzilla 
> issues were addressed. The Roadmap shows that there are some 
> major problems still:
> http://nagoya.apache.org/bugzilla/showdependencytree.cgi?id=25321
> 
> Do we really want to release in this state?
> 
> --David
> 
> 
> 

RE: [VOTE] RE: LogKitLoggerManager

[Carsten Ziegeler]

+1

Just replace my solution.

Carsten 

> -Original Message-
> From: Ralph Goers [mailto:[EMAIL PROTECTED] 
> Sent: Sunday, May 09, 2004 11:09 PM
> To: '[EMAIL PROTECTED]'
> Subject: [VOTE] RE: LogKitLoggerManager
> 
> Yes, this change is backward compatible with 2.1.4, but not 
> with the version Carsten checked in last week.  I'd 
> appreciate a vote to have this patch applied.
> 
> Ralph
> 
> -Original Message-
> From: Joerg Heinicke [mailto:[EMAIL PROTECTED]
> Sent: Sunday, May 09, 2004 1:52 PM
> To: [EMAIL PROTECTED]
> Subject: Re: LogKitLoggerManager
> 
> On 09.05.2004 19:25, Ralph Goers wrote:
> 
> > I've submitted patch 28860. I realize this is after the 
> code freeze, 
> > but
> I'd
> > prefer to see this patch instead of the current code. If 2.1.5 goes 
> > out
> with
> > the current code we would have to maintain the current behavior of 
> > logger-type.
> 
> I guess it's completely backwards compatible (same default 
> behaviour and so on). Then it can go in, but we must vote 
> about it. It's best if you start the vote yourself. But IMO 
> we should not wait 72 h for that vote as we would have only 
> Thursday to test it. 36 h are enough for this case IMO.
> 
> Joerg
> 

Re: [VOTE] RE: LogKitLoggerManager

[Joerg Heinicke]

On 10.05.2004 16:42, Ralph Goers wrote:

Thanks Joerg,

Maybe I should have marked this as QVOTE since you are the only one who has
replied?
A qvote here means more or less "If no one objects I will commit". IMO 
during the code freeze this is not applicable. Also your patch goes into 
the core, the Cocoon class itself. If there is no common interest we 
will better leave it out for the release. For a successful vote you need 
at least 3 binding +1 and no veto. So where are the interests?

Joerg

Re: [CForms]FormattingDateConvertor can't convert blank to date in current cvs version.

[Joerg Heinicke]

On 10.05.2004 17:50, Bruno Dumon wrote:

I made a little error in my change, it simply needs an "else value =
null" added. I'll fix it after the code freeze.
Why after? Surely the code freeze is intended to be a time for fixing 
bugs (but not for committing 'innovations')?
Code freeze is for fixing showstopper bugs. The above issue may fall
into that category, especially since a user noticed and reported it, and
that it was working before. I'll try to fix it one of the next days.
I don't want to discuss now what's allowed during code freeze 
extensively, but IMO it's just a evaluation of benefit and risk of a 
patch. In this case I guess the risk to break something is very low.

Joerg

Re: [QVote] Release 2.1.5 on May 14th

[Joerg Heinicke]

On 10.05.2004 11:15, Sylvain Wallez wrote:

Processing pipelines from within flowscript and get various results 
objects
=> assigned to Sylvain ;-)
Doh! This has been implemented for a long time now in PipelineUtil. Bug 
closed!!
Of course! I use it myself already in my current project (CSV-upload 
with CForms, processPipelineToDOM, chaperon, back to CForms). I only 
read the bug summary and did not relate this to processPipelineTo***().

Joerg

Re: XConfToolTask and more than one patch action per file

[Geoff Howard]

+1 from me - I didn't know why it was that way either and just left things as I 
found them whenever I've touched it.  This task goes back pretty far though IIRC 
- maybe there was a forgotten reason?

Geoff

Ralph Goers wrote:

I had thought about doing this in my last update to XConfToolTask, but I
didn't want to add two features in one patch.
Doing this could actually be pretty easy.  Currently, it looks at the root
node and grabs info from it. It would be pretty easy to see if the child
nodes are some sort of "patch" node, and if so iterate through them getting
the info that would normally be on the root node from each patch node
instead.
It would be nice to do this as you could put related patches in one file.

Ralph

-Original Message-
From: Claas Thiele [mailto:[EMAIL PROTECTED] 
Sent: Monday, May 10, 2004 9:00 AM
To: [EMAIL PROTECTED]
Subject: XConfToolTask and more than one patch action per file

Whats the reason for having one patch action per patchfile only?

Using filesets the execution order of the patches is not predictable and 
so it is a hell writing more complex patches.

Would it be a good idea having a set of actions in one patchfile like 
xupdate has?

Claas

Re: Supersonic block has landed (Power Trio tutorial/example app)

[Geoff Howard]

Bruno Dumon wrote:

On Mon, 2004-05-10 at 14:28, Bertrand Delacretaz wrote:

Le 10 mai 04, à 05:59, David Crossley a écrit :

...I think that it should be called the "tour" block, yet still
have the familiar name of "Supersonic Tour"...
Do others have the same opinion? If so I'm ok to rename the block, I 
agree that it's a more descriptive name.


how about the full "supersonictour" ?
Yes, I have the same opinion too, and either tour or supersonictour are fine 
with me.  Antonio, were you thinking of HSQL (stands for Hypersonic SQL, doesn't 
it?).

Geoff

RE: XConfToolTask and more than one patch action per file

[Ralph Goers]

I had thought about doing this in my last update to XConfToolTask, but I
didn't want to add two features in one patch.

Doing this could actually be pretty easy.  Currently, it looks at the root
node and grabs info from it. It would be pretty easy to see if the child
nodes are some sort of "patch" node, and if so iterate through them getting
the info that would normally be on the root node from each patch node
instead.

It would be nice to do this as you could put related patches in one file.

Ralph

-Original Message-
From: Claas Thiele [mailto:[EMAIL PROTECTED] 
Sent: Monday, May 10, 2004 9:00 AM
To: [EMAIL PROTECTED]
Subject: XConfToolTask and more than one patch action per file

Whats the reason for having one patch action per patchfile only?

Using filesets the execution order of the patches is not predictable and 
so it is a hell writing more complex patches.

Would it be a good idea having a set of actions in one patchfile like 
xupdate has?


Claas

XConfToolTask and more than one patch action per file

[Claas Thiele]

Whats the reason for having one patch action per patchfile only?

Using filesets the execution order of the patches is not predictable and 
so it is a hell writing more complex patches.

Would it be a good idea having a set of actions in one patchfile like 
xupdate has?

Claas

Re: Supersonic block has landed (Power Trio tutorial/example app)

[Bruno Dumon]

On Mon, 2004-05-10 at 14:28, Bertrand Delacretaz wrote:
> Le 10 mai 04, à 05:59, David Crossley a écrit :
> > ...I think that it should be called the "tour" block, yet still
> > have the familiar name of "Supersonic Tour"...
> 
> Do others have the same opinion? If so I'm ok to rename the block, I 
> agree that it's a more descriptive name.

how about the full "supersonictour" ?

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

Re: [CForms]FormattingDateConvertor can't convert blank to date in current cvs version.

[Bruno Dumon]

On Sun, 2004-05-09 at 14:20, Upayavira wrote:
> Bruno Dumon wrote:
> 
> >On Sun, 2004-05-09 at 12:07, roy huang wrote:
> >  
> >
> >>Hi All:
> >>  If I user xml as data to binding cocoon forms,I must using DateConvertor to 
> >> convert string to date like:
> >>   >>path="date" >
> >>
> >>  
> >>-MM-dd
> >>  
> >>
> >>  
> >>
> >>the data may looks like:
> >>1971-05-06
> >>
> >>But if the data is  it will error like:
> >>org.apache.avalon.framework.CascadingRuntimeException: 
> >>"resource://org/apache/cocoon/forms/flow/javascript/Form.js", line 160: uncaught 
> >>JavaScript exception: at bindingSample 
> >>(file:/D:/eclipse/workspace/cocoon-2.1/build/webapp/samples/blocks/forms/flow/bindings.js,
> >> Line 73) at (resource://org/apache/cocoon/forms/flow/javascript/Form.js, Line 
> >>160): java.lang.RuntimeException: Incorrect value type for "date" (expected class 
> >>java.util.Date, got class java.lang.String.
> >>
> >>But it works only several days ago,so I check the cvs and believe is Bruno's 
> >>change in 5.6 makes it. Here's what he said in cvs comments:
> >>
> >>Made Convertor.convertFromString contract more solid by letting it
> >>return a ConversionResult object (instead of null/not-null to indicate
> >>successful conversion). This also moves the responsibility
> >>of creating the ValidationError to the Convertor, allowing convertors
> >>to set more specialised messages in them.
> >>
> >>What can I do to convert an blank ("") string to Date type? Or this should be 
> >>considered in the FormattingDateConvert.java?I believe this function is need 
> >>because date may be blank.
> >>
> >>WDYT?
> >>
> >>
> >
> >I made a little error in my change, it simply needs an "else value =
> >null" added. I'll fix it after the code freeze.
> >  
> >
> Why after? Surely the code freeze is intended to be a time for fixing 
> bugs (but not for committing 'innovations')?

Code freeze is for fixing showstopper bugs. The above issue may fall
into that category, especially since a user noticed and reported it, and
that it was working before. I'll try to fix it one of the next days.

>  Otherwise, this bug will be 
> enshrined in 2.1.5, which would be a shame.
> 
> Regards, Upayavira
-- 
Bruno Dumon http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
[EMAIL PROTECTED]  [EMAIL PROTECTED]

Re: Using CocoonBean in a CocoonServlet

[Upayavira]

Sylvain Wallez wrote:

Hi folks,

In one of our projects, we use CocoonBean in a CocoonServlet 
environment to dump a collection of generated documents on disk. Doing 
this, we encountered two problems:

- CocoonComponentManager.checkEnvironment barfs and throws an 
Exception since the servlet environment exists on the stack when the 
CocoonBean starts its processing.
 Obvious solution is to remove this test, as indicated in the method's 
comments.
I'm okay with it. Although it would be better if the Bean within a 
servlet could share the Cocoon object, along with all that goes with it. 
That would make the Bean really quick to start up. I believe Unico had 
ideas about this.

- CocoonWrapper reconfigures the default log hierarchy which is also 
used by CocoonServlet, thus leading to a big mess in loggers.
 I have a simple patch here that makes CocoonBean create its own 
hierarchy.
I'm okay with this. Never looked much at the logging code myself.

I consider these as bugs and would like to commit the changes even if 
we're in code freeze. Note that this changes _nothing_ when CocoonBean 
is run in normal CLI mode. 
Regards, Upayavira

Re: Warning for informix query

[Torsten Curdt]

Hi,

I am getting the following warning for informix. Can someone tell what I have 
to do to avoid this.My queries work mysteriously at times. Sometimes they 
work sometimes they dont.
Hi, Anna,

this is nothing serious. The database signature is not being recognized
yet so it defaults to the generic jdbc query type. If you explicitly
specifiy the query type being "jdbc" the warning will be gone.
If not someone else adds this I will fix it next week.

But it's just a warning anyway. Your queries should work all the time.
Maybe you can clarify "sometimes they don't" a bit more?
cheers
--
Torsten

DO NOT REPLY [Bug 27957] - JSP content type overrides serializer

[bugzilla]

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

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

JSP content type overrides serializer





--- Additional Comments From [EMAIL PROTECTED]  2004-05-10 14:55 ---
The only problem with overriding setContentType() in the wrapper, is we need to
make sure that files read using the JSPReader are allowed to set the content
type, since they are not serialized by cocoon.  The setContentType() in the
wrapper should only be suppressed when using the JSPGenerator.

RE: [VOTE] RE: LogKitLoggerManager

[Ralph Goers]

Thanks Joerg,

Maybe I should have marked this as QVOTE since you are the only one who has
replied?

Ralph

-Original Message-
From: Joerg Heinicke [mailto:[EMAIL PROTECTED] 
Sent: Monday, May 10, 2004 1:14 AM
To: [EMAIL PROTECTED]
Subject: Re: [VOTE] RE: LogKitLoggerManager

On 09.05.2004 23:08, Ralph Goers wrote:

> Yes, this change is backward compatible with 2.1.4, but not with the
version
> Carsten checked in last week.  I'd appreciate a vote to have this patch
> applied.

Ok, then +1 from my side.

Joerg

RE: HELP!!!!! Double coercion exception in flowscript - SOLVED

[H . vanderLinden]

The problem was caused by a faulty syntax for the continuation id:

${continuation/id} should be #{$continuation/id}

Bye, Helma

> -Original Message-
> From: [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED] 
> Sent: Monday, 10 May 2004 14:05
> To: [EMAIL PROTECTED]
> Subject: HELP! Double coercion exception in flowscript
> 
> 
> Hi,
> 
> I run into a double coercion exception when I'm trying to 
> display a form using a flowscript. While debugging with the 
> flowscript editor I noticed that a second thread is started 
> and both threads run the flowscript function that is going to 
> display the form.
> 
> Can anyone tell me why this is happening and what I can do about it?
> 
> More specific: the webapp starts with a login form, when the 
> user logs in correctly a "search" page is shown. At this 
> point I have 1 thread as far as I can see. After submitting 
> the search request the result is displayed (1
> thread) and the user selects 1 record, which is then 
> displayed in detail
> (again: 1 thread as far as I can tell). Added to this page 
> are submenus and when I click on a menu item I get a second 
> thread with the above result.
> 
> 
> Note: I just (a few minutes ago) updated to the latest CVS 
> HEAD and the problem still exists.
> 
> 
> Bye,
> 
> Helma van der Linden
> Medical Informatics
> University Maastricht
> POBOX 616
> 6200 MD Maastricht
> The Netherlands
> 

DO NOT REPLY [Bug 28869] New: - Unmatched brackets in i18n dictionary cause OutOfMemoryError

[bugzilla]

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

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

Unmatched brackets in i18n dictionary cause OutOfMemoryError

   Summary: Unmatched brackets in i18n dictionary cause
OutOfMemoryError
   Product: Cocoon 2
   Version: 2.1.3
  Platform: All
OS/Version: Linux
Status: NEW
  Severity: Critical
  Priority: Other
 Component: core
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


Running Cocoon 2.1.3 on Tomcat 4.1.12-LE-jdk14, SuSE Linux Pro 8.2.  Create an
i18n dictionary entry like this (note the unmatched bracket):

  Test
  This is a {0]
 
If a page is called which references this translation, the browser "load" icon
spins; Tomcat claims more and more memory until it quits with a
java.lang.OutOfMemoryError (stack trace below).

The I18nTransfomer uses a java.text.MessageFormat to parse the parameters; this
class throws an IllegalArgumentException if it finds unmatched brackets. I
suspect that this exception is being swallowed somewhere instead of being
rethrown. Obviously this bug is caused by user (i.e. developer) error, but it
would be nice if the exception were cleanly rethrown - this cost me and a
colleague 2 hours Friday afternoon trying to find the bug!

John Webber

The stack trace in Tomcat:

2004-05-10 15:07:35 StandardWrapperValve[Cocoon]: Servlet.service() for servlet
Cocoon threw exception
javax.servlet.ServletException: Servlet execution threw an exception
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:269)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:193)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:260)
at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
at
org.apache.catalina.core.StandardContext.invoke(StandardContext.java:2396)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:180)
at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643)
at
org.apache.catalina.valves.ErrorDispatcherValve.invoke(ErrorDispatcherValve.java:170)
at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:641)
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:172)
at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:641)
at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:469)
at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:641)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:174)
at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
at org.apache.coyote.tomcat4.CoyoteAdapter.service(CoyoteAdapter.java:223)
at
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:405)
at
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection(Http11Protocol.java:380)
at
org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.java:508)
at
org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:533)
at java.lang.Thread.run(Thread.java:534)
- Root Cause -
java.lang.OutOfMemoryError

Using CocoonBean in a CocoonServlet

[Sylvain Wallez]

Hi folks,

In one of our projects, we use CocoonBean in a CocoonServlet environment 
to dump a collection of generated documents on disk. Doing this, we 
encountered two problems:

- CocoonComponentManager.checkEnvironment barfs and throws an Exception 
since the servlet environment exists on the stack when the CocoonBean 
starts its processing.
 Obvious solution is to remove this test, as indicated in the method's 
comments.

- CocoonWrapper reconfigures the default log hierarchy which is also 
used by CocoonServlet, thus leading to a big mess in loggers.
 I have a simple patch here that makes CocoonBean create its own hierarchy.

I consider these as bugs and would like to commit the changes even if 
we're in code freeze. Note that this changes _nothing_ when CocoonBean 
is run in normal CLI mode.
Any objections?

Sylvain

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

Re: Supersonic block has landed (Power Trio tutorial/example app)

[Antonio Gallardo]

Bertrand Delacretaz dijo:
> Le 10 mai 04, à 05:59, David Crossley a écrit :
>> ...I think that it should be called the "tour" block, yet still
>> have the familiar name of "Supersonic Tour"...
>
> Do others have the same opinion? If so I'm ok to rename the block, I
> agree that it's a more descriptive name.

I am +1 for a more clear name as "tour", "intro", "tutorial", "starthere"
or a similar name. The "supersonic" name is cool but it does not clear
about what it is about. Then I have concerns how easily a newbie will find
it. Remember Cocoon is a best with more than 100 MB.


Supersonic: suggest me a Database name (not sure, but I think I hear about
that some time ago. I don't know even if it still exists or not.).


Best Regards,

Antonio Gallardo

Re: Supersonic block has landed (Power Trio tutorial/example app)

[Bertrand Delacretaz]

Le 10 mai 04, à 05:59, David Crossley a écrit :
...I think that it should be called the "tour" block, yet still
have the familiar name of "Supersonic Tour"...
Do others have the same opinion? If so I'm ok to rename the block, I 
agree that it's a more descriptive name.

-Bertrand

HELP!!!!! Double coercion exception in flowscript

[H . vanderLinden]

Hi,

I run into a double coercion exception when I'm trying to display a form
using a flowscript. While debugging with the flowscript editor I noticed
that a second thread is started and both threads run the flowscript function
that is going to display the form.

Can anyone tell me why this is happening and what I can do about it?

More specific: the webapp starts with a login form, when the user logs in
correctly a "search" page is shown. At this point I have 1 thread as far as
I can see. After submitting the search request the result is displayed (1
thread) and the user selects 1 record, which is then displayed in detail
(again: 1 thread as far as I can tell). Added to this page are submenus and
when I click on a menu item I get a second thread with the above result.


Note: I just (a few minutes ago) updated to the latest CVS HEAD and the
problem still exists.


Bye,

Helma van der Linden
Medical Informatics
University Maastricht
POBOX 616
6200 MD Maastricht
The Netherlands

DO NOT REPLY [Bug 27440] - nesting-error in SQLTransformer

[bugzilla]

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

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

nesting-error in SQLTransformer





--- Additional Comments From [EMAIL PROTECTED]  2004-05-10 05:36 ---
Created an attachment (id=11483)
Updated SQLTransformer diff against CVS 1.19

DO NOT REPLY [Bug 25283] - [Roadmap] Flowscript - NEXT release

[bugzilla]

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

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

[Roadmap] Flowscript - NEXT release

This bug depends on bug 25285, which changed state:

   What|Old Value   |New Value

 Status|NEW |RESOLVED
 Resolution||FIXED

Re: [QVote] Release 2.1.5 on May 14th

[Sylvain Wallez]

Joerg Heinicke wrote:

On 10.05.2004 06:12, David Crossley wrote:

The FirstFriday was a little bit active and some Bugzilla
issues were addressed. The Roadmap shows that there are some
major problems still:
http://nagoya.apache.org/bugzilla/showdependencytree.cgi?id=25321
Do we really want to release in this state?


Yes, we should IMO. Open issues are




Processing pipelines from within flowscript and get various results 
objects
=> assigned to Sylvain ;-)


Doh! This has been implemented for a long time now in PipelineUtil. Bug 
closed!!

Sylvain

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

Re: Question about parser.

[Lionel Crine]

You are right, It's a user question. Won't make the mistake.

Anyway here is the answer :
I stream my dom in an SAX endElement method So I had two startDocument.
So, to make it work, You should DOM the DOMResult.getDocumentElement();
Lionel

At 13:38 08/05/2004 +0200, you wrote:
On Fri, 2004-05-07 at 15:48, Lionel Crine wrote:
> Hi again,
>
> I have some trouble in my pipeline and don't really what's going on.
>
> In a transformer (SAX), i get DOM from an XML base and then I parse it in
> the endElement method.
>
>
> I tried two ways :
>
> 1/
> DOMStreamer s = new DOMStreamer(this.contentHandler, this.lexicalHandler);
> s.stream(DOMResult);
>
> 2/
> String strResult = XMLUtils.serializeNode(DOMResult,
> UtilsFunction.getInstance().setProperties(true)); --> UtilsFunction
> redefine the property object.
>
> InputSource inputSource = new InputSource(new
> ByteArrayInputStream(strResult.getBytes(UtilsParam.getInstance().UTF8)));
> SAXParser parser = (SAXParser) this.manager.lookup(SAXParser.ROLE);
> parser.parse(inputSource, new IncludeXMLConsumer(super.xmlConsumer));
>
>
> 1/ With the first method --> When I tried to put an "xslt" transformer
> after this one, I get an error :
>
> Original Exception: java.lang.RuntimeException: java.lang.RuntimeException
>  at
> org.apache.xalan.transformer.TransformerImpl.run(TransformerImpl.java:3364)
>  at
> 
org.apache.xalan.transformer.TransformerHandlerImpl.endDocument(TransformerHandlerImpl.java:427)
>  at
> org.apache.cocoon.xml.AbstractXMLPipe.endDocument(AbstractXMLPipe.java:91)
>  at
> 
org.apache.cocoon.transformation.TraxTransformer.endDocument(TraxTransformer.java:583)
>
>
> 2/ With the second method --> All is Fine.
>
> What's the difference between this two methods ?

The serialization in between.

The problem is either that the DOM-tree is invalid or a bug in the
DOMStreamer. The first option is more likely.
To find out what could be wrong, insert a LogTransformer in the pipeline
and examine its output. If you can't find anything wrong in it, let us
have a look at it.
PS: we've got a user mailing list for this sort of questions.

--
Bruno Dumon http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
[EMAIL PROTECTED]  [EMAIL PROTECTED]
Lionel CRINE
Ingénieur Systèmes documentaires
Société : 4DConcept
22 rue Etienne de Jouy 78353 JOUY EN JOSAS
Tel : 01.34.58.70.70 Fax : 01.39.58.70.70

DO NOT REPLY [Bug 28809] - [PATCH] chaperon improvements for xdoc

[bugzilla]

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

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

[PATCH] chaperon improvements for xdoc





--- Additional Comments From [EMAIL PROTECTED]  2004-05-10 04:59 ---
Created an attachment (id=11482)
how embarrassing.. this patch should work.

Re: [QVote] Release 2.1.5 on May 14th

[Ugo Cei]

Joerg Heinicke wrote:
JXTemplate evaluates expressions in comments, need jx:comment?
=> minor issue
Also present in previous releases.

	Ugo

Re: [QVote] Release 2.1.5 on May 14th

[Joerg Heinicke]

On 10.05.2004 06:12, David Crossley wrote:

The FirstFriday was a little bit active and some Bugzilla
issues were addressed. The Roadmap shows that there are some
major problems still:
http://nagoya.apache.org/bugzilla/showdependencytree.cgi?id=25321
Do we really want to release in this state?
Yes, we should IMO. Open issues are

flow: importPackage/importClass problems creating InitialContext()
=> bug is half a year old, we released it already
JXTemplate evaluates expressions in comments, need jx:comment?
=> minor issue
Processing pipelines from within flowscript and get various results objects
=> assigned to Sylvain ;-)
SQLTransformer: duplicate namespace declaration when serializing XML
=> extremely old, I tried to reproduce it on Friday and did not get it
Persistent store or cache corruption?
=> For that one we might change the default store.
Upgrade all source files to ASF 2.0 license
=> That's of course a *must*.
HTML serialization has no space between publicId and systemId
=> Don't know about it, but it seems Xalan related - though you wrote it 
does not happen on command line.

Joerg

Re: Cocoon after 2.1.5

[Joerg Heinicke]

On 09.05.2004 23:14, Carsten Ziegeler wrote:

Considering all our version discussions, we want the next Cocoon
version to be a minor version change, so this will be 2.2.
We will put new features into it that were planned for 2.2 anyway,
perhaps except blocks.
Pier suggested that we follow the Linux versioning, so the version
numbers .0, .2, etc. mark stable versions whereas .1,.3 etc. mark
developer versions.
If we want to follow this, we should imho skip 2.2, use 2.3 to
indicate a developer version and 2.4 will then be the final and
stable version.
WDYT?
Is this not a bit different then our release guide? I thought we will 
have a sandbox branch, that is merged (partly) into the head on demand. 
The head remains at that time with the current version and before each 
release we decide whether we have to increment only patch or if 
necessary minor or even major release number. I prefer this system over 
the above linux system.

Joerg

Re: [VOTE] RE: LogKitLoggerManager

[Joerg Heinicke]

On 09.05.2004 23:08, Ralph Goers wrote:

Yes, this change is backward compatible with 2.1.4, but not with the version
Carsten checked in last week.  I'd appreciate a vote to have this patch
applied.
Ok, then +1 from my side.

Joerg

Re: [CForms]FormattingDateConvertor can't convert blank to date in current cvs version.

[Sylvain Wallez]

Joerg Heinicke wrote:

On 09.05.2004 14:20, Upayavira wrote:

I made a little error in my change, it simply needs an "else value =
null" added. I'll fix it after the code freeze.
Why after? Surely the code freeze is intended to be a time for fixing 
bugs


+1 That's what the code freeze is about. Otherwise we wouldn't need it 
and could release today as it is.


+1 !

Sylvain

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

Re: Cocoon after 2.1.5

[Sylvain Wallez]

Carsten Ziegeler wrote:

Considering all our version discussions, we want the next Cocoon
version to be a minor version change, so this will be 2.2.
We will put new features into it that were planned for 2.2 anyway,
perhaps except blocks.
Pier suggested that we follow the Linux versioning, so the version
numbers .0, .2, etc. mark stable versions whereas .1,.3 etc. mark
developer versions.
If we want to follow this, we should imho skip 2.2, use 2.3 to
indicate a developer version and 2.4 will then be the final and
stable version.
 

I'm sorry, but I never understood this concept of "developper version". 
Can it be called a version if it's for developpers only ? Isn't this 
actually a development _branch_ that can be given whatever name we want, 
such as "newkernel" as was suggested ?

Sylvain

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

Re: [CForms]FormattingDateConvertor can't convert blank to date in current cvs version.

[roy huang]

+1
- Original Message - 
From: "Joerg Heinicke" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Sunday, May 09, 2004 9:05 PM
Subject: Re: [CForms]FormattingDateConvertor can't convert blank to date in current 
cvs version.


> On 09.05.2004 14:20, Upayavira wrote:
> 
> >> I made a little error in my change, it simply needs an "else value =
> >> null" added. I'll fix it after the code freeze.
> >>
> > Why after? Surely the code freeze is intended to be a time for fixing 
> > bugs
> 
> +1 That's what the code freeze is about. Otherwise we wouldn't need it 
> and could release today as it is.
> 
> Joerg
>