International apache branches
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 nameThorsten Scherler/name countrySpain/country @mail [EMAIL PROTECTED]/@mail @cocoon-WIKI http://wiki.cocoondev.org/Wiki.jsp?page=Scherler/@cocoon-WIKI /thorsten
DO NOT REPLY [Bug 28889] - jetty-4.2.19.jar seems compiled for +jdk1.4
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=28889. 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 25321] - [Roadmap] Cocoon - NEXT release
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=25321. 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
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=28889. 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
Re: [QVote] Release 2.1.5 on May 14th
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
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=28889. 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.
DO NOT REPLY [Bug 25321] - [Roadmap] Cocoon - NEXT release
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=25321. 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
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=28889. 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
Using CocoonBean in a CocoonServlet
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 }
DO NOT REPLY [Bug 28869] New: - Unmatched brackets in i18n dictionary cause OutOfMemoryError
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=28869.
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):
entry
keyTest/key
translation lang=enThis is a {0]/translation
/entry
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
RE: HELP!!!!! Double coercion exception in flowscript - SOLVED
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 27957] - JSP content type overrides serializer
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=27957. 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: Warning for informix query
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
Re: Using CocoonBean in a CocoonServlet
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: [CForms]FormattingDateConvertor can't convert blank to date in current cvs version.
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: fb:value id=date path=date fd:convertor datatype=date fd:patterns fd:pattern-MM-dd/fd:pattern /fd:patterns /fd:convertor /fb:value the data may looks like: date1971-05-06/date But if the data is datedate 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: Supersonic block has landed (Power Trio tutorial/example app)
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]
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)
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
+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: [QVote] Release 2.1.5 on May 14th
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: [CForms]FormattingDateConvertor can't convert blank to date in current cvs version.
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: [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: [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: [QVote] Release 2.1.5 on May 14th
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: Using CocoonBean in a CocoonServlet
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: [VOTE] RE: LogKitLoggerManager
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: Supersonic block has landed (Power Trio tutorial/example app)
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: Supersonic block has landed (Power Trio tutorial/example app)
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
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
[cforms] getWidget removal affecting 2.1.5 release?
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: Moving to subversion - volunteers?
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.
Re: Supersonic block has landed (Power Trio tutorial/example app)
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: 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-devm=107412183108550w=4
Item 3.
;-)
Joerg
RE: [VOTE] RE: LogKitLoggerManager
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: [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
DO NOT REPLY [Bug 27957] - JSP content type overrides serializer
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=27957. 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: [heads up] [cforms] problem with calendar popup on ie6
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: [VOTE] RE: LogKitLoggerManager
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/
DO NOT REPLY [Bug 28869] - I18nTransformer: unmatched brackets cause OutOfMemoryError
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=28869.
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 ---
entry
keyTest/key
translation lang=enThis is a {0]/translation
/entry
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: [heads up] [cforms] problem with calendar popup on ie6
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=
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=10579696307r=1w=4). But I don't remember the solution as it was not so important for me. I will ask him. Joerg
RE: HELP!!!!! Double coercion exception in flowscript - SOLVED
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-devm=107412183108550w=4
Item 3.
;-)
Joerg
Session losing authentication context - still an open bug?
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: [heads up] [cforms] problem with calendar popup on ie6
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: [cforms] getWidget removal affecting 2.1.5 release?
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: Moving to subversion - volunteers?
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: [heads up] [cforms] problem with calendar popup on ie6
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: [heads up] [cforms] problem with calendar popup on ie6
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=10579696307r=1w=4). But I don't remember the solution as it was not so important for me. I will ask him. Joerg
Re: Using CocoonBean in a CocoonServlet
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: Using CocoonBean in a CocoonServlet
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: [cforms] getWidget removal affecting 2.1.5 release?
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 }
DO NOT REPLY [Bug 27957] - JSP content type overrides serializer
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=27957. 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: [heads up] [cforms] problem with calendar popup on ie6
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=
Re: [CForms]FormattingDateConvertor can't convert blank to date in current cvs version.
+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
Re: Cocoon after 2.1.5
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.
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: [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: [QVote] Release 2.1.5 on May 14th
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: [QVote] Release 2.1.5 on May 14th
Joerg Heinicke wrote: JXTemplate evaluates expressions in comments, need jx:comment? = minor issue Also present in previous releases. Ugo
DO NOT REPLY [Bug 28809] - [PATCH] chaperon improvements for xdoc
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=28809. 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: Question about parser.
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
Re: [QVote] Release 2.1.5 on May 14th
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
snip/
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 }
DO NOT REPLY [Bug 25283] - [Roadmap] Flowscript - NEXT release
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=25283. 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
DO NOT REPLY [Bug 27440] - nesting-error in SQLTransformer
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=27440. 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
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
Re: Supersonic block has landed (Power Trio tutorial/example app)
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
Re: Supersonic block has landed (Power Trio tutorial/example app)
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. OT 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.). /OT Best Regards, Antonio Gallardo
