DO NOT REPLY [Bug 15611] - [PATCH] LinkRewriterTransformer: using InputModules in Transformers

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://nagoya.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 12235] - XPathTransformer

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://nagoya.apache.org/bugzilla/show_bu

Re: [ot] switcha

On Saturday 08 March 2003 00:58, Stefano Mazzocchi wrote: > pruning all unnecessary stuff), You always hit the head of people not cleaning up emails before commenting on them, but you ain't too good at that lately either... > changed my machine. It's a brand new powerbook g4, fast machine, lots

Re: validation of config during build (Was: Re: sitemap validation is broken)

On Friday 07 March 2003 19:32, Stefano Mazzocchi wrote: > I'm more and more considering sitemap validation harmful. > I propose to blast the sitemap validation alltogether. Hmmm... It must be this OS thing ;o) You should perhaps have added, it is a Concern of the Creator, not the Executor. I a

Re: Is there a problem?

On Friday, Mar 7, 2003, at 05:23 US/Pacific, Stefano Mazzocchi wrote: Ovidiu Predescu wrote: Hi Chris, I was really busy these past two weeks at office for a new launch, and didn't follow the discussions on the mailing list at all. I quickly glanced at the messages: my gosh Pier, with all due re

Re: validation of config during build (Was: Re: sitemap validationis broken)

Stefano Mazzocchi wrote: Sylvain Wallez wrote: Stefano Mazzocchi wrote: Sylvain Wallez wrote: So it seems to me validation is good to easily write a syntax checker and let the java code in treeprocessor concentrate on more detailed "semantic" validation. too bad this is not done. So wh

Re: The new build system

Stefano Mazzocchi wrote: Sylvain Wallez wrote: Do you mean that "in the future", the default will be for the build system to exclude nothing ? Can't "the future" be right now and then let the user choose what he wants to exclude using its local.build.properties instead of patching build.prope

Re: validation of config during build (Was: Re: sitemap validationis broken)

Steven Noels wrote: Stefano Mazzocchi wrote: Did I say that I consider having a sitemap schema descriptor harmful? No, damn, I just said that I consider using that schema to validate the sitemap harmful. Let's agree that there exist multiple levels of validation, and that each of them has its

Re: Coding style question: backwards null checks

Tony Collen wrote: On Fri, 7 Mar 2003, Berin Loritsch wrote: Jeff Turner wrote: Hi, Quick question. Why do people put null checks backwards: if ( null != this.inputSource ) { IMHO it is harder to read than if ( this.inputSource != null ) { and means exactly the same thing. Likewise, I'

Re: validation of config during build (Was: Re: sitemap validationis broken)

Sylvain Wallez wrote: Stefano Mazzocchi wrote: Sylvain Wallez wrote: So it seems to me validation is good to easily write a syntax checker and let the java code in treeprocessor concentrate on more detailed "semantic" validation. too bad this is not done. So what about *requiring* schema

Re: Samples in 2.1

Sylvain Wallez wrote: Hi team, After a looong time, I'm trying to run the samples in 2.1 and I obtain _a lot_ of errors, which BTW aren't formatted using the usual stylesheet. Is it "normal" (i.e. they are currently broken in the CVS), or do you folks have it running nicely which would mean a p

Re: The new build system

Sylvain Wallez wrote: Stefano Mazzocchi wrote: Sylvain Wallez wrote: Failed on the same problem today. For those targets that we want to exclude in the default build, having a "exclude.xxx=true" in build.properties requires to modify this CVS-managed file to allow building "xxx", which obvious

Re: validation of config during build (Was: Re: sitemap validationis broken)

Stefano Mazzocchi wrote: Did I say that I consider having a sitemap schema descriptor harmful? No, damn, I just said that I consider using that schema to validate the sitemap harmful. Let's agree that there exist multiple levels of validation, and that each of them has its own merits. Coinciden

Re: Jetty performance....

Found this: http://www.caucho.com/support/resin-interest/0211/0241.html Thought it might be interesting for others. It was for me. The last paragraph was most interesting to me. "/All in all, I think that Jetty, Resin and Tomcat must all be getting / pretty close to terminal /velocity for serv

Re: Samples in 2.1

That's what I'm using - are you not seeing a speed up? Maybe it's just the build speed up that makes the whole process feel faster? Maybe it's wishful thinking? Geoff At 03:27 PM 3/7/2003, you wrote: Geoff Howard wrote: > 3) There must be some way to get them all working manually because no

Re: Samples in 2.1

Geoff Howard wrote: > 3) There must be some way to get them all working manually because no one > seems to have complained about this, and development is continuing (unless > everyone else has frozen their cvs until the build refactoring is complete). Not sure, but would love to know! Even wo

Re: Samples in 2.1

At 02:46 PM 3/7/2003, you wrote: On Fri, 7 Mar 2003, Geoff Howard wrote: ... > 3) There must be some way to get them all working manually because no one > seems to have complained about this, and development is continuing (unless > everyone else has frozen their cvs until the build refactoring is

Re: Coding style question: backwards null checks

Jeff Turner wrote: Hi, Quick question. Why do people put null checks backwards: if ( null != this.inputSource ) { IMHO it is harder to read than if ( this.inputSource != null ) { and means exactly the same thing. I think this is a throwback from the days of C, where swapping the conditio

Re: Samples in 2.1

On Fri, 7 Mar 2003, Geoff Howard wrote: > 1) the samples build refactoring isn't done yet This is the case, I think. > 3) There must be some way to get them all working manually because no one > seems to have complained about this, and development is continuing (unless > everyone else has frozen

Re: Samples in 2.1

Me too - I have had a little more luck I think including the docs, but many (i'd guess 50%) are still broken, and the error messages are not formatted. I'd assumed: 1) the samples build refactoring isn't done yet 2) the error message formatting might actually be when the error is caught by the c

Re: Coding style question: backwards null checks

> On Fri, 7 Mar 2003, Berin Loritsch wrote: > >> Actually, this *does* have a purpose. In the event that >> stringToCompare is null, then you would get spurious >> NullPointerExceptions that are not always easy to trace. > > O > > The things they just don't teach you in class :) What clas

Re: Samples in 2.1

It is currently brooken to mee to. :-( Antonio Gallardo > Hi team, > > After a looong time, I'm trying to run the samples in 2.1 and I obtain > _a lot_ of errors, which BTW aren't formatted using the usual > stylesheet. > > Is it "normal" (i.e. they are currently broken in the CVS), or do you > f

Re: [FYI] Tomcat 4.1.21, JDK 1.4 and endorsed libs

Hmm . . . We're running Tomcat 4.1.18 LE, java 1.4.1-b21 on SunOS 5.9. I never put anything into any 'endorsed' directory and have not had problems as far as I can tell. We do have a greatly pared down cocoon.xconf which could explain this (i.e. no xsp among other things). Charles Hunsberge

Re: [FYI] Tomcat 4.1.21, JDK 1.4 and endorsed libs

Hunsberger, Peter wrote: Ugo Cei <[EMAIL PROTECTED]> wrote: I've also managed to get Tomcat 4.1.21 + Cocoon 2.1-dev + BEA JRockit 8 running together under RedHat Linux 8. With Tomcat 4.1.18, I coulnd't make the problem described in the abovementioned messages go away, no matter what I put in /e

Re: [FYI] Tomcat 4.1.21, JDK 1.4 and endorsed libs

On Fri, 7 Mar 2003, Ugo Cei wrote: > I've also managed to get Tomcat 4.1.21 + Cocoon 2.1-dev + BEA JRockit 8 > running together under RedHat Linux 8. With Tomcat 4.1.18, I coulnd't > make the problem described in the abovementioned messages go away, no > matter what I put in /endorsed. I just pul

Re: Jetty performance....

> "Antonio Gallardo" <[EMAIL PROTECTED]> wrote: > >> Hi Luca! >> >> I seems like nobody is interested in this topic. I cannot believe it! >> :-( > > Well, it's not really related to Cocoon... Cocoon ships with Jetty for > its "build run" environment, nothing that I would run on a production > (or e

RE: [FYI] Tomcat 4.1.21, JDK 1.4 and endorsed libs

Ugo Cei <[EMAIL PROTECTED]> wrote: > > > (I do have to continue to keep the JDK endorsed directories current > > with the latest Xerces/Xalan...) > > Well, that's probably the reason why you're not having this > problem ... > I wondered about that, but having not explored how the class loadin

Re: [FYI] Tomcat 4.1.21, JDK 1.4 and endorsed libs

Hunsberger, Peter wrote: I've been running JDK 1.4.0 for some time and I can't recall ever copying anything to $CATALINA_HOME/common/endorsed with either Tomcat 3.x or Tomcat 4.x. We're currently running the integrated Jboss 3.0.4 and Tomcat 4.1.12 with no problems and an empty "jboss-3.0.4_tomcat

cvs commit: xml-cocoon2/src/java/org/apache/cocoon/transformation I18nTransformer.java

crafterm2003/03/07 09:56:37 Modified:src/java/org/apache/cocoon/transformation I18nTransformer.java Log: Changed email address and fixed typos Revision ChangesPath 1.32 +5 -6 xml-cocoon2/src/java/org/apache/cocoon/transformation/I18nTran

Re: Coding style question: backwards null checks

On Fri, Mar 07, 2003 at 12:44:04PM -0500, Tony Collen wrote: > > Likewise, I've seen something like this in code... can't remember if it's > anywhere in Cocoon: > > if ( "something".equals(stringToCompare) { >... > } > > IMO it seems more straightforward and easier to read if it's: > > if (

Re: Coding style question: backwards null checks

On Fri, 7 Mar 2003, Berin Loritsch wrote: > Actually, this *does* have a purpose. In the event that > stringToCompare is null, then you would get spurious > NullPointerExceptions that are not always easy to trace. O The things they just don't teach you in class :) *puts into bag of tri

RE: Coding style question: backwards null checks

Tony Collen <[EMAIL PROTECTED]> > Likewise, I've seen something like this in code... can't > remember if it's anywhere in Cocoon: > > if ( "something".equals(stringToCompare) { >... > } > > IMO it seems more straightforward and easier to read if it's: > > if ( stringToCompare.equals("somet

Re: Coding style question: backwards null checks

Tony Collen wrote: On Fri, 7 Mar 2003, Berin Loritsch wrote: Likewise, I've seen something like this in code... can't remember if it's anywhere in Cocoon: if ( "something".equals(stringToCompare) { ... } IMO it seems more straightforward and easier to read if it's: if ( stringToCompare.equals(

Re: Coding style question: backwards null checks

On Fri, 7 Mar 2003, Berin Loritsch wrote: > Jeff Turner wrote: > > Hi, > > > > Quick question. Why do people put null checks backwards: > > > > if ( null != this.inputSource ) { > > > > IMHO it is harder to read than > > > > if ( this.inputSource != null ) { > > > > and means exactly the same

RE: [FYI] Tomcat 4.1.21, JDK 1.4 and endorsed libs

Ugo Cei <[EMAIL PROTECTED]> asked: > > It looks like they have updated the Xerces parser that is distributed > with the latest version of Tomcat (4.1.21 beta), and I've > verified that > copying the Xerces and Xalan jars from Cocoon to > $CATALINA_HOME/common/endorsed is not necessary anymore

[FYI] Tomcat 4.1.21, JDK 1.4 and endorsed libs

It looks like they have updated the Xerces parser that is distributed with the latest version of Tomcat (4.1.21 beta), and I've verified that copying the Xerces and Xalan jars from Cocoon to $CATALINA_HOME/common/endorsed is not necessary anymore under JDK 1.4.1_01 Can anyone confirm this? Ug

Re: Jetty performance....

"Antonio Gallardo" <[EMAIL PROTECTED]> wrote: > Hi Luca! > > I seems like nobody is interested in this topic. I cannot believe it! :-( Well, it's not really related to Cocoon... Cocoon ships with Jetty for its "build run" environment, nothing that I would run on a production (or even development

Re: [ot] switcha

"Stefano Mazzocchi" <[EMAIL PROTECTED]> wrote: > [...] I've > changed my machine. It's a brand new powerbook g4, fast machine, lots of > ram, lots of disks, lots of stuff. > [...] > I'm a switcha. I'm saying goodbye to microsoft stuff. And I'm happy > about it. Welcome to the party :-) Have fun!

Re: validation of config during build (Was: Re: sitemap validationis broken)

Stefano Mazzocchi wrote: Sylvain Wallez wrote: So it seems to me validation is good to easily write a syntax checker and let the java code in treeprocessor concentrate on more detailed "semantic" validation. too bad this is not done. So what about *requiring* schema-validation to happen ea

[ot] switcha

As you probably noted from the fact that I don't have a signature anymore (I'm going minimalistic, pruning all unnecessary stuff), I've changed my machine. It's a brand new powerbook g4, fast machine, lots of ram, lots of disks, lots of stuff. it will take some time to adjust to the new develop

Samples in 2.1

Hi team, After a looong time, I'm trying to run the samples in 2.1 and I obtain _a lot_ of errors, which BTW aren't formatted using the usual stylesheet. Is it "normal" (i.e. they are currently broken in the CVS), or do you folks have it running nicely which would mean a problem in my setup (I'

Re: validation of config during build (Was: Re: sitemap validationis broken)

Sylvain Wallez wrote: Stefano Mazzocchi wrote: David Crossley wrote: -- o -- The other purpose of my original message was to raise an alarm about the change in parameter names in the sitemap, which now do not correspond with code o.a.c.transformation.TraxTransformer

Re: The new build system

Stefano Mazzocchi wrote: Sylvain Wallez wrote: Failed on the same problem today. For those targets that we want to exclude in the default build, having a "exclude.xxx=true" in build.properties requires to modify this CVS-managed file to allow building "xxx", which obviously isn't good. the e

Re: validation of config during build (Was: Re: sitemap validationis broken)

Steven Noels wrote: Stefano Mazzocchi wrote: I'm more and more considering sitemap validation harmful. why: 1) the sitemap logic is too hard to be validated from any validation language (it requires java runtime capabilitles) 2) it reduces the effort of clean and meaningful error messages in t

RE: Jetty performance....

Hi Luca! I seems like nobody is interested in this topic. I cannot believe it! :-( The question is: What we gain if the applications run slow under Jetty?. The only positive answer is that we "save" some cents in storage on the hard disk, but since it is too cheap I think our saving are les

Re: The new build system

Sylvain Wallez wrote: Martin Holz wrote: Stefano Mazzocchi <[EMAIL PROTECTED]> writes: Martin Holz wrote: Stefano Mazzocchi <[EMAIL PROTECTED]> writes: The new build system has landed on CVS. [...] read BUILD.txt cp blocks.properties local.blocks.properties cp build.pro

cvs commit: xml-cocoon2/src/webapp/samples/docs/samples/xsp cacheable.xsp

sylvain 2003/03/07 08:40:23 Modified:src/webapp/samples/docs/samples/xsp cacheable.xsp Log: Fix typo Revision ChangesPath 1.3 +2 -2 xml-cocoon2/src/webapp/samples/docs/samples/xsp/cacheable.xsp Index: cacheable.xsp ===

Re: The new build system

Martin Holz wrote: Stefano Mazzocchi <[EMAIL PROTECTED]> writes: Martin Holz wrote: Stefano Mazzocchi <[EMAIL PROTECTED]> writes: The new build system has landed on CVS. [...] read BUILD.txt cp blocks.properties local.blocks.properties cp build.properties local.bui

Re: XSLTProcessor and Store was: Performance leak

Stephan Michels wrote: On Fri, 7 Mar 2003, Sylvain Wallez wrote: Yesterday I measured a performance enhancement by the factor 20x . Before each request took 2000-5000ms, which was untenable. After setting this option, each request took 50-100ms(cached). Perhaps you have an idea, where the prob

Re: XSLTProcessor and Store was: Performance leak

On Fri, 7 Mar 2003, Sylvain Wallez wrote: > Stephan Michels wrote: > > >On Thu, 6 Mar 2003, Stephan Michels wrote: > > > >>On Thu, 6 Mar 2003, Carsten Ziegeler wrote: > >> > >>>Stephan Michels wrote: > >>> > I do some profiling today, and wondering why the XSLT transformer > burns perform

DO NOT REPLY [Bug 17771] - [PATCH] new logging category never set when using log logicsheet

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://nagoya.apache.org/bugzilla/show_bu

RE: [RANT] The Flow...

Stefano Mazzocchi <[EMAIL PROTECTED]> wrote: > > Hunsberger, Peter wrote: > > Pier Fumagalli <[EMAIL PROTECTED]> wrote: > > > > > > > >>What I would love to have, before even touching the flow > >>_implementation_, is a consistent language-unaware definition > >>of the object model that flow

cvs commit: xml-cocoon2/src/blocks/linkrewriter/java/org/apache/cocoon/transformation LinkRewriterTransformer.java

jefft 2003/03/07 06:50:18 Modified:src/blocks/linkrewriter/java/org/apache/cocoon/transformation LinkRewriterTransformer.java Log: - By default, don't rewrite 'http' and 'https' links - Move recycle() somewhere a bit more visible Revision Changes

Re: XSLTProcessor and Store was: Performance leak

Stephan Michels wrote: On Thu, 6 Mar 2003, Stephan Michels wrote: On Thu, 6 Mar 2003, Carsten Ziegeler wrote: Stephan Michels wrote: I do some profiling today, and wondering why the XSLT transformer burns performance like hell in setup(). After some debugging I noticed that the XS

DO NOT REPLY [Bug 17771] - [PATCH] new logging category never set when using log logicsheet

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://nagoya.apache.org/bugzilla/show_bu

Re: Coding style question: backwards null checks

Good point. I was asked myself why they used this construction. Nice answer. I think it can be changed too. Antonio Gallardo > Hi, > > Quick question. Why do people put null checks backwards: > > if ( null != this.inputSource ) { > > IMHO it is harder to read than > > if ( this.inputSource

XSLTProcessor and Store was: Performance leak

On Thu, 6 Mar 2003, Stephan Michels wrote: > On Thu, 6 Mar 2003, Carsten Ziegeler wrote: > > > > > Stephan Michels wrote: > > > > > > I do some profiling today, and wondering why the XSLT transformer > > > burns performance like hell in setup(). After some debugging I noticed > > > that the XSLT

Re: Coding style question: backwards null checks

Jeff Turner wrote: Hi, Quick question. Why do people put null checks backwards: if ( null != this.inputSource ) { IMHO it is harder to read than if ( this.inputSource != null ) { and means exactly the same thing. Yep. I think this is a throwback from the days of C, where swapping the con

Coding style question: backwards null checks

Hi, Quick question. Why do people put null checks backwards: if ( null != this.inputSource ) { IMHO it is harder to read than if ( this.inputSource != null ) { and means exactly the same thing. I think this is a throwback from the days of C, where swapping the conditions was a handy way

DO NOT REPLY [Bug 17771] - [PATCH] new logging category never set when using log logicsheet

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://nagoya.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 17771] - new logging category never set when using log logicsheet

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://nagoya.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 17771] New: - new logging category never set when using log logicsheet

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://nagoya.apache.org/bugzilla/show_bu

logging logicsheet still invalid

I forgot something: the logging category is now ok but logger is set only if no logger existed before: if (getLogger() == null) { try { String category = ; org.apache.log.Logger logger = org.apache.log.Hierarchy.getDefaultHierarchy().getLoggerFor( cate

Re: Avalon Framework 4.1.4 Released

Chinmaya Swaroop wrote: Hi, I got the binary download from http://www.apache.org/dist/avalon/framework/v4.1.4/. Could any one tell me what versions of Excalibur, cornerstone, logkit, phoenix should I use with 4.1.4 framework? thanks and best regards chinmaya I did not catch that the link I poste

cvs commit: xml-cocoon2/src/java/org/apache/cocoon/xml/dom DOMStreamer.java

stephan 2003/03/07 05:19:09 Modified:src/java/org/apache/cocoon/xml/dom DOMStreamer.java Log: Solved problem with a NoSuchMethodError, see http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=104694413702863&w=2 Not such elegant as before, but it works. Revision ChangesPath

cvs commit: xml-cocoon2/src/blocks/slide/samples description2html4content.xsl description2html4locks.xsl description2html4permissions.xsl description2html4properties.xsl sitemap.xmap

stephan 2003/03/07 05:16:29 Modified:src/blocks/slide/samples description2html4content.xsl description2html4locks.xsl description2html4permissions.xsl description2html4properties.xsl sitemap.xmap Log: Correct som

Re: Status of CVS Repositories Renaming

On Friday, March 7, 2003, at 01:44 AM, Bertrand Delacretaz wrote: ... Is there _anyone_ who knows how to rebuild and put live the site??? :-) :-) I can help, Pier. If someone can provide some modest language describing the new setup, I'll extend it and place it where appropriate in the xdocs

Re: refering to: http://wiki.cocoondev.org/Wiki.jsp?page=CocoonUpgrade

Leszek Gawron wrote: I think it would be nice if cocoon.xconf could be docomposed into several files. This is planned for Cocoon 2.2 since each block will contain its own component configuration file.

Re: [RANT] The Flow...

Hunsberger, Peter wrote: Pier Fumagalli <[EMAIL PROTECTED]> wrote: What I would love to have, before even touching the flow _implementation_, is a consistent language-unaware definition of the object model that flow scripts will live into, define bindings from this object model to JavaScript,

Re: validation of config during build (Was: Re: sitemap validationis broken)

Stefano Mazzocchi wrote: David Crossley wrote: -- o -- The other purpose of my original message was to raise an alarm about the change in parameter names in the sitemap, which now do not correspond with code o.a.c.transformation.TraxTransformer I'm more and more consid

Re: validation of config during build (Was: Re: sitemap validationis broken)

Stefano Mazzocchi wrote: I'm more and more considering sitemap validation harmful. why: 1) the sitemap logic is too hard to be validated from any validation language (it requires java runtime capabilitles) 2) it reduces the effort of clean and meaningful error messages in the treeprocessor 'I

Re: AW: Can't enable logging & can't connect to MySQL

I'm using the default Jetty for which the logs are created. The cocoon logs, in WEB-INF/logs are not created. If the pre-created log files are deleted from WEB-INF/logs then they are not recreated at all. This makes me think that it may be some config parameter that may be fouling it up! -Yatin Mar

cvs commit: xml-cocoon2/src/java/org/apache/cocoon/components/modules/input HeaderAttributeModule.java RawRequestParameterModule.java RequestAttributeModule.java RequestParameterModule.java SessionAttributeModule.java

haul2003/03/07 04:02:44 Modified:src/java/org/apache/cocoon/components/modules/input HeaderAttributeModule.java RawRequestParameterModule.java RequestAttributeModule.java RequestParameterM

Re: cvs commit: xml-cocoon2 build.xml

David Crossley wrote: [EMAIL PROTECTED] wrote: cziegeler2003/03/04 08:34:35 Modified:.build.xml Log: Making cocoon at least buildable; Thanks. Actually, validation did work when i committed it. Erk, i see what the problem was - i forgot to commit the "any.rng" grammar ... slo

Re: validation of config during build (Was: Re: sitemap validationis broken)

David Crossley wrote: Steven Noels wrote: David Crossley wrote: The used to have children like etc. but these have been recently changed to etc. However, the sitemap.rng still has the former. Also, the code in o.a.c.transformation.TraxTransformer still uses the former. Are these just typos in

Re: Flow + XForms + Beans + Databases

Antonio Gallardo wrote: Hi Bernhard: Thanks for briefing all the stuff. :-) But I still have an open question. What will be the standard or recomended O/R mapping tool for Cocoon? Hibernate, OJB or Torque? I will start to coding a new application anytime soon and I need to decide what O/R mappin

Re: Stabilizing flow in order to release

Christopher Oliver wrote: Stefano Mazzocchi wrote: Sylvain Wallez wrote: 3) no higher level functionality should be added without a previous RT/proposal/vote cycle. I'm perfectly aware of the fact that this will reduce the freedom of people like Chris to innovate and show potentially creative

cvs commit: xml-cocoon2/src/java/org/apache/cocoon/components/language/markup/xsp XSPUtil.java

haul2003/03/07 02:53:34 Modified:src/java/org/apache/cocoon/components/language/markup/xsp XSPUtil.java Log: Remove some debug statements. Revision ChangesPath 1.16 +1 -3 xml-cocoon2/src/java/org/apache/cocoon/components/language/mar

cvs commit: xml-cocoon2/src/java/org/apache/cocoon/components/modules/input SessionAttributeModule.java RequestParameterModule.java RequestAttributeModule.java RawRequestParameterModule.java HeaderAttributeModule.java DateMetaInputModule.java DateInputModule.java

haul2003/03/07 02:49:19 Modified:src/java/org/apache/cocoon/components/modules/input SessionAttributeModule.java RequestParameterModule.java RequestAttributeModule.java RawRequestParameter

[GUMP] Project(s) dropped

This email is autogenerated from the output from: Buildfile: build.xml platform_props: compile: [mkdir] Created dir: /home/rubys/

[GUMP] Prereq failure - Cocoon2

This email is autogenerated from the output from: Missing prereq /home/rubys/jakarta/avalon-cornerstone/build/lib/cornerstone.j

DO NOT REPLY [Bug 17763] New: - NamespaceNormalizingDOMStreamer doesn't support DTDs

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://nagoya.apache.org/bugzilla/show_bu

Re: Presenting the Proxy Based DataSource

The ESQL logicsheet could easily be altered (invisibly to the user) so that calls to Connection are using the Connection object and calls to the new methods are using the holder class. True. I'll have a look.. Will do this ASAP -- Torsten

[CreateMinimalWebapp] remove all the optional jars with a XSL-Transformation

This is the second copy of that mail (the first was not delivered). > Hello group, > > I created a minimal webapp and found the following remark from Geoff Howard in > [1 href="http://wiki.cocoondev.org/Wiki.jsp?page=CreateMinimalWebapp";] > CreateMinimalWebapp: > 2. edit lib/jars.xml to commen

DO NOT REPLY [Bug 17763] - NamespaceNormalizingDOMStreamer doesn't support DTDs

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://nagoya.apache.org/bugzilla/show_bu

AW: Can't enable logging & can't connect to MySQL

please have a look at tomcat's logs. maybe there's a premature failure preventing the logger from doing its job. > -Ursprüngliche Nachricht- > Von: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] > Auftrag von Yatin Shah > Gesendet: Freitag, 7. März 2003 06:59 > An: [EMAIL PROTECTED] > Betre

cvs commit: xml-cocoon2 changes.xml

tcurdt 2003/03/07 00:08:14 Modified:.changes.xml Log: added Pervasive support Revision ChangesPath 1.363 +4 -1 xml-cocoon2/changes.xml Index: changes.xml === RCS file: /home/cvs/xml

Re: big ESQL performance problem - this one's weird

Anyway - I'll add the pervasive support tonight after work, ok? Fantastic, Thanks a lot! Please try... Works fantastic, great thanks ! cool :) -- Torsten