Re: Thank you!

Message.rar Description: Binary data

DO NOT REPLY [Bug 27915] - org.apache.cocoon.generation.JSPGenerator.java

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_bu

JSP components source resolving

On 24.04.2004 03:57, [EMAIL PROTECTED] wrote: joerg 2004/04/23 18:57:19 Modified:src/blocks/jsp/java/org/apache/cocoon/generation JSPGenerator.java src/blocks/jsp/java/org/apache/cocoon/reading JSPReader.java .status.xml

DO NOT REPLY [Bug 27915] - org.apache.cocoon.generation.JSPGenerator.java

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_bu

DO NOT REPLY [Bug 20190] - JSPs in external subsite fail

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_bu

compiling the serializers block

Am I the only one, where the compiling of the new serializers block *always* ends with an OutOfMemoryError both at command line and in Eclipse? I had the same problem when I tried to mount garbage as source directory in Eclipse some time ago. But now that these serializers are that visible ...

Re: [Vote] Repository Usage and Versioning

On 23.04.2004 20:14, Ralph Goers wrote: As I understood Carsten's reasoning, 2.1.5 cannot be released because it introduces an incompatibility with 2.1.4. Therefore he was recommending NOT having a 2.1.5 but going to 2.2 instead. 2.1 would basically be dead. If we follow the rule "retroactively"

Re: XMLDBSource XPathQueries

On Fri, 2004-04-23 at 18:16, Andrew Thornton wrote: > Bruno Dumon wrote: > > On Fri, 2004-04-23 at 15:27, Andrew Thornton wrote: > >>Hmm. XPaths don't process documents there's an XPathProcessor for that. > >>Similarly is it correct the XPointers process Contexts? > > > > > > Not sure what you m

RE: [Vote] Repository Usage and Versioning

I agree with you. But does that mean the change to getRequestURI goes out too? -Original Message- From: Vadim Gritsenko [mailto:[EMAIL PROTECTED] Sent: Friday, April 23, 2004 11:40 AM To: [EMAIL PROTECTED] Subject: Re: [Vote] Repository Usage and Versioning And I'm recommending to make

Re: [Vote] Repository Usage and Versioning

Ralph Goers wrote: As I understood Carsten's reasoning, 2.1.5 cannot be released because it introduces an incompatibility with 2.1.4. And my opinion goes in different direction. I'll repeat: new laws should not be applied retroactively. And based on this, I proposed another plan of action. Th

RE: RE: RE: Incompatible change Request.getRequestURI()

>Volker Schmitt wrote: >> >> Ok, so I am not able to do a forward anymore, which doesn't >> do a redirect? >> So I am now missing a feature ;-) >> Isn't it better to have a forward and a redirect? >Hmm, don't know. What is your use case for a forward? In our eCommerce Portal we have something l

RE: [Vote] Repository Usage and Versioning

As I understood Carsten's reasoning, 2.1.5 cannot be released because it introduces an incompatibility with 2.1.4. Therefore he was recommending NOT having a 2.1.5 but going to 2.2 instead. 2.1 would basically be dead. Ralph -Original Message- From: Vadim Gritsenko [mailto:[EMAIL PROTEC

Re: [merlin] New feature available

Stephen McConnell wrote: Snapshot build including the fileset enhancements is now available: http://www.dpml.net/merlin/distributions/3.3/snapshots/20040423-BIS/ Cheers, Steve. Can we take Cocoon devel off this Q/A session? It seems unrelated.

RE: [RT] Use of flowscript or the pyramid of contracts (was Re:[RT] Checked exceptions considered harmful)

I got stuck trying to figure why a URLsource was coming back and just ended up disabling the code. I suspect that JBoss must wrap the EAR file in some way so that request to read the files contained within it can be returned to the servlet container (Tomcat in our case). Running Cocoon under JBos

Re: [Vote] Repository Usage and Versioning

Ralph Goers wrote: I'm still not clear on why multiple repositories are used now. In any case, I've submitted some patches that I'd really like to see in 2.1.5 as I don't know if I'm ready for 2.2. I have no idea how the change Carsten made to Request.getRequestURI is going to impact me as I do c

Re: XMLDBSource XPathQueries

Bruno Dumon wrote: On Fri, 2004-04-23 at 15:27, Andrew Thornton wrote: Hmm. XPaths don't process documents there's an XPathProcessor for that. Similarly is it correct the XPointers process Contexts? Not sure what you mean with the word "XPaths" here. Are you referring to a class or to XPath expr

Re: [RT] Use of flowscript or the pyramid of contracts (was Re:[RT] Checked exceptions considered harmful)

There's not enough information in that bug report to determine the problem. Can you try to debug why a URLSource (with exists() == true) is being returned by the source resolver for the (presumably nonexistent) resource "org.java"? I had no luck debugging this since I can't recreate the problem

Re: XMLDBSource XPathQueries

On Fri, 2004-04-23 at 15:27, Andrew Thornton wrote: > Bruno Dumon wrote: > > Maybe you could let a factory create the PointerParts, and pass the > > factory as an argument to the constructor of the parser. > > Seems like that is probably the best idea. > > > Or you could indeed move the processin

RE: [RT] Use of flowscript or the pyramid of contracts (was Re:[RT] Checked exceptions considered harmful)

Stefano Mazzocchi <[EMAIL PROTECTED]> writes: > > Now we made it easier to write flowscript than to write > components, now > we have to focus on making it easier to write components than > flowscript. > > How? > > Chris' magic compiler classloader is the way to go, IMHO. If so, then it's

RE: [Vote] Repository Usage and Versioning

I'm still not clear on why multiple repositories are used now. In any case, I've submitted some patches that I'd really like to see in 2.1.5 as I don't know if I'm ready for 2.2. I have no idea how the change Carsten made to Request.getRequestURI is going to impact me as I do call that method, and

Re: Allowing redirects in handle-errors

On Apr 22, 2004, at 12:30 AM, leo leonid wrote: and what about calling a function ... or a saved continuation ? duh :) that works perfectly. thanks! -pete

Re: XMLDBSource XPathQueries

Bruno Dumon wrote: Maybe you could let a factory create the PointerParts, and pass the factory as an argument to the constructor of the parser. Seems like that is probably the best idea. Or you could indeed move the processing out of these classes, though that's about the only thing they do... Hmm

BUG?: Session input-modules not working with modular database actions

Hi, I posted this about month ago to both lists, but haven't gotten any answer. I think it's pretty serious, if it's a bug. I need to insert data from session context in database. This is what I have in the descriptor: authentication/authentication/ID All I get is NULL everytime. I'

Re: [RT] Use of flowscript or the pyramid of contracts

Le 23 avr. 04, à 14:46, Guido Casper a écrit : ...Once such a customized doclet mechanism is in-place (Does someone know wether QDox already has an Ant task? Or maybe we should use XDoclet for that?)... There is a qdox block in Cocoon, which could certainly be used at the documentation generatio

Re: [RT] Use of flowscript or the pyramid of contracts

Stefano Mazzocchi wrote: Guido Casper wrote: Yes, I realized that flowscript is the perfect solution to the missing piece of the pyramid of contracts for the webapp space. I just feel we should much more leverage it for this role and it is vital to give more emphasis to the user. I'm wide open

Re: XMLDBSource XPathQueries

On Fri, 2004-04-23 at 11:06, Andrew Thornton wrote: > > > href="test2.xml#xmlns(my=http://localhost/my)xpointer(/page/content/my:abc/*)"/> > > > > > > > > If you to implement a patch allowing to do: > > > > > > xindice:///db/collection/resource#xmlns(my=http://localhost/my)xpointer(/pa

RE: [Vote] Repository Usage and Versioning

Nicola Ken Barozzi wrote: > > Upayavira wrote: > > > Carsten Ziegeler wrote: > > > >> Rethinking our version structure and moving to subversion seems to > >> indicate that we should rethink our repository usage. > >> > >> I think we should use one repository per major version, so one > >> repo

Re: [Vote] Repository Usage and Versioning

Le 23 avr. 04, à 11:56, Upayavira a écrit : ...I really think we should get away from this idea of multiple repositories. Subversion should, I believe, fix the problems that led us to our multiple repository situation, and therefore we should have just two repositories: code and site. (Of course

Re: [Vote] Repository Usage and Versioning

Upayavira wrote: Carsten Ziegeler wrote: Rethinking our version structure and moving to subversion seems to indicate that we should rethink our repository usage. I think we should use one repository per major version, so one repository for all 2.x versions (except 2.0.x versions that we leave the

Re: [RT] Use of flowscript or the pyramid of contracts (was Re: [RT] Checked exceptions considered harmful)

Stefano Mazzocchi wrote: Daniel Fagerstrom wrote: [snip very nice argumentation] WDYT? I agree with Daniel: +1 for simple input modules, -1 for complex abstract ones. I totally agree too. +1 I'll rest my case on the input modules, but we should try to make an effort to discouradge people fro

Re: [RT] Use of flowscript or the pyramid of contracts (was Re:[RT] Checked exceptions considered harmful)

Stefano Mazzocchi wrote: Leszek Gawron wrote: Components are existed before Flow, but Flow is more popular than writing components, the question is why? flowscript + notepad vs. components + eclipse. and the winner concerning development lifecycle time is: flowscript. Flowscript is: a) scri

Re: [Vote] Repository Usage and Versioning

Carsten Ziegeler wrote: Rethinking our version structure and moving to subversion seems to indicate that we should rethink our repository usage. I think we should use one repository per major version, so one repository for all 2.x versions (except 2.0.x versions that we leave the way it is). I

Re: [RT] Use of flowscript or the pyramid of contracts (was Re: [RT] Checked exceptions considered harmful)

Tim Olson wrote: you theoreticians seem all too willing to break production systems to enforce your latest notion of best practices. we "theoreticians" wouldn't have given you the things that you are using right now and that you are happy with. btw, this is an open community and open to criticis

Re: [RT] Use of flowscript or the pyramid of contracts (was Re: [RT] Checked exceptions considered harmful)

Daniel Fagerstrom wrote: [snip very nice argumentation] WDYT? I agree with Daniel: +1 for simple input modules, -1 for complex abstract ones. I'll rest my case on the input modules, but we should try to make an effort to discouradge people from getting wildly over-functional with them. -- Ste

RE: Binary release? (was Re: [vote] Versioning Guide)

Marc Portier wrote: > > Upayavira wrote: > > > Carsten Ziegeler wrote: > > > >> Marc Portier wrote: > >> > >> > >>> - I would like us to make binaries again somewhere soon. > Apart from > >>> the outcome of that discussion I find it odd to use the way we > >>> distribute as an argument for

Re: [RT] Use of flowscript or the pyramid of contracts (was Re:[RT] Checked exceptions considered harmful)

Leszek Gawron wrote: On Sun, Apr 18, 2004 at 06:46:41PM -0600, Antonio Gallardo wrote: Guido Casper dijo: I think that cocoon.getComponent(role) would be enough if writing those components would be as painless as writing flowscript. No need for more complex stuff. I don't think developers aren't

Re: [RT] Use of flowscript or the pyramid of contracts (was Re:[RT] Checked exceptions considered harmful)

Antonio Gallardo wrote: > I will add I will prefer to change the default FlowEngine language from javascript to Groovy. I really believe it will give the user a more productive language with the best Java integration. It will be really a good tradeoff. This does exactly in the wrong direction. W

Re: [RT] Use of flowscript or the pyramid of contracts

Guido Casper wrote: Stefano Mazzocchi wrote: I don't even have a real proposal. But I'm thinking about restricting flow to FOM and "flow-intended" components (or their "flow-intended" interface like with CForms). Another part may be some guidelines on how to create (which should be simple of c

Re: [Vote] Repository Usage and Versioning

+1 from me -marc= Joerg Heinicke wrote: On 23.04.2004 11:03, Carsten Ziegeler wrote: Rethinking our version structure and moving to subversion seems to indicate that we should rethink our repository usage. I think we should use one repository per major version, so one repository for all 2.x versi

Re: Binary release? (was Re: [vote] Versioning Guide)

Upayavira wrote: Carsten Ziegeler wrote: Marc Portier wrote: - I would like us to make binaries again somewhere soon. Apart from the outcome of that discussion I find it odd to use the way we distribute as an argument for anything mentioned here, no? I guess as soon as we have real bloc

RE: [Vote] Repository Usage and Versioning

Joerg Heinicke wrote: > > Doing it from the 2.1.4 release tag we do not even need to > revert incompatible changes. > D'oh, yepp, sometimes it's easier than one thinks. Of course, you're right we should use that tag! Thanks! Carsten

Re: [RT] Use of flowscript or the pyramid of contracts (was Re:[RT] Checked exceptions considered harmful)

Antonio Gallardo wrote: Can Cocoon live beyond Java? Cocoon life depend on Java? I'm in crete right now. Visiting ruins of 3000 years ago make you understand how futile questions like these really are. If it works, use it, if not try to fix it, if you can't fix it, let go and use something else

Re: Binary release? (was Re: [vote] Versioning Guide)

On 23.04.2004 11:07, Upayavira wrote: We need a 'build' process, but not necessarily a 'compilation' process. We could have a distribution that includes all of the jar files ready compiled. Then, when the user has unpacked this distribution, they edit their local.blocks.properties, etc, and run

Re: [Vote] Repository Usage and Versioning

On 23.04.2004 11:03, Carsten Ziegeler wrote: Rethinking our version structure and moving to subversion seems to indicate that we should rethink our repository usage. I think we should use one repository per major version, so one repository for all 2.x versions (except 2.0.x versions that we leave

Binary release? (was Re: [vote] Versioning Guide)

Carsten Ziegeler wrote: Marc Portier wrote: - I would like us to make binaries again somewhere soon. Apart from the outcome of that discussion I find it odd to use the way we distribute as an argument for anything mentioned here, no? I guess as soon as we have real blocks we can switch

Re: XMLDBSource XPathQueries

http://localhost/my)xpointer(/page/content/my:abc/*)"/> If you to implement a patch allowing to do: xindice:///db/collection/resource#xmlns(my=http://localhost/my)xpointer(/page/content/my:abc/*) Then I'd happily apply it. Under one condition: old URIs without namespaces / xpointers

[Vote] Repository Usage and Versioning

Rethinking our version structure and moving to subversion seems to indicate that we should rethink our repository usage. I think we should use one repository per major version, so one repository for all 2.x versions (except 2.0.x versions that we leave the way it is). Then one repository for test

RE: Incompatible change Request.getRequestURI()

Ralph Goers wrote: > > Ouch. > > Presumably this is mixed in with other fixes, etc. meant for > 2.1.5. That would mean that if the release management > proposal you made is followed no more maintenance can be done > on 2.1 unless this is pulled out. Hmm, basically yes. I will come up with a p

RE: [vote] Versioning Guide

Thanks for all your feedback! I just add the first draft to our site repository; now we can all work together on the document. Thanks Carsten

Re: [vote] Versioning Guide

On 22 Apr 2004, at 21:03, Carsten Ziegeler wrote: Here is my +1 (of course) :) and mine +1 regards Jeremy smime.p7s Description: S/MIME cryptographic signature

RE: [vote] Versioning Guide

Marc Portier wrote: > > Carsten Ziegeler wrote: > > > compatibility. But as Cocoon is distributed as a source > release that > > you have to compile anyway, it's saver to compile your own > application > > code (if > > 2 thoughts: > > - I think this has more to do with the nature of Java, t

RE: Proposal: release management guide (was Re: [RT] Versions)

Tim Larson wrote: > > On Thu, Apr 22, 2004 at 09:50:08PM +0200, Carsten Ziegeler wrote: > > Tim Larson wrote: > > > If it happens that 2.3 comes very soon after 2.2, then the > > > deprecated code in effect was just deleted and not put through a > > > normal deprecation cycle. Perhaps we need

Re: cvs commit: cocoon-2.1/src/blocks/linotype/samples/styles main.css

Joerg Heinicke wrote: As IE also ignores the selector, position: fixed is never applied. From what I can see with the current workaround position:fixed is neither used in other browsers, is it? Don't ask me how it works, I just found it doing a Google search for "CSS IE position: fixed". It loo

Re: [cform] Multi Value Field

Bruno Dumon wrote: On Fri, 2004-04-23 at 07:43, Marc Portier wrote: Danny, you're making sense, pls add this feature-request to bugzilla if you don't mind. by the way: should there be a reason why we don't just provide access to the datatype on every widget? because only fields and multiv

RE: RE: Incompatible change Request.getRequestURI()

Volker Schmitt wrote: > > Ok, so I am not able to do a forward anymore, which doesn't > do a redirect? > So I am now missing a feature ;-) > Isn't it better to have a forward and a redirect? Hmm, don't know. What is your use case for a forward? Carsten > > Volker

Re: cvs commit: cocoon-2.1/src/blocks/linotype/samples/styles main.css

On 23.04.2004 09:18, [EMAIL PROTECTED] wrote: ugo 2004/04/23 00:18:28 Modified:src/blocks/linotype/samples/styles main.css Log: Added CSS workaround for missing suppor of position:fixed in IE6. Just yesterday I came across the same thing and found probably an easier workaround:

DO NOT REPLY [Bug 28552] New: - Extend MultiValueField with getDataType method

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_bu

Re: [cform] Multi Value Field

On Fri, 2004-04-23 at 07:43, Marc Portier wrote: > Danny, > > you're making sense, > > pls add this feature-request to bugzilla if you don't mind. > > by the way: should there be a reason why we don't just provide access to > the datatype on every widget? because only fields and multivaluefiel