DO NOT REPLY [Bug 15843] - EmptyStackException in EnvironmentStack

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 15843] - EmptyStackException in EnvironmentStack

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: quicky: SWT & (mounted) subsitemaps

Steven Noels wrote: Hi folks, am I correct to assume there is still an issue with Source resolving, which gets manifested when one uses the SWT in a subsitemap? I get http://apache.org/cocoon/include/1.0"; xmlns:source="http://apache.org/cocoon/source/1.0";>The src attribute could not be re

org/apache/cocoon/mail does not compile conditionally

Even without mail.jar not present in the lib/optional directory, this code in this package will still be compiled, leading to compilation errors. Bernhard, could you please try to fix the problem? If not, I can take of it tomorrow morning when I wake up. Thanks, -- Ovidiu Predescu <[EMAIL PROTE

Re: quicky: SWT & (mounted) subsitemaps

Sylvain Wallez wrote: http://apache.org/cocoon/include/1.0"; xmlns:source="http://apache.org/cocoon/source/1.0";>The src attribute could not be resolved and failed to cancel The 'src' attribute above is empty. Can't this be the reason ? Well, I'm a bit confused: there is a src attribute on

cvs commit: xml-cocoon2 build.xml

cziegeler2003/01/08 00:48:36 Modified:.build.xml Log: Removed the include.scratchpad.libs property - include.webapp.libs is sufficient Revision ChangesPath 1.303 +3 -4 xml-cocoon2/build.xml Index: build.xml =

DO NOT REPLY [Bug 9075] - [PATCH] Contribution of SAP R/3(r) connectivity components

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_bug

Re: Defining Source Interfaces

Carsten Ziegeler wrote: Sylvain Wallez wrote: However, I still consider the new implementation of SourceResolverImpl.release() in Excalibur (dated 15 dec. and not currently in Cocoon) to be a performance burden since in most cases all component-related operations it performs *will be useles

Re: quicky: SWT & (mounted) subsitemaps

Steven Noels wrote: Sylvain Wallez wrote: http://apache.org/cocoon/include/1.0"; xmlns:source="http://apache.org/cocoon/source/1.0";>The src attribute could not be resolved and failed to cancel The 'src' attribute above is empty. Can't this be the reason ? Well, I'm a bit confused: there i

RE: cocoon and eclipse.

On Wed, 8 Jan 2003, Carsten Ziegeler wrote: > Giacomo Pati wrote: > > > > That's a lot! > > > > I've only had about ~180! Do you have deprecation turned on? Than that > > will explain alot. > > > > BTW: Someone (IIRC Carsten) had committed Mail... classes that are > > compiled against 1.4 version

RE: Defining Source Interfaces

Sylvain Wallez wrote: > > The performance problem is that among all implementations of Source that > I know of (URLSource, FileSource, SlideSource, BlobSource, XMLDBSource, > SitemapSource and CVSSource), only one actually needs to be disposed > (SitemapSource). > > So having a isSelectable()-

Re: org/apache/cocoon/mail does not compile conditionally

On Wed, 8 Jan 2003, Ovidiu Predescu wrote: > Even without mail.jar not present in the lib/optional directory, this > code in this package will still be compiled, leading to compilation > errors. Bernhard, could you please try to fix the problem? If not, I > can take of it tomorrow morning when I w

cvs commit: xml-cocoon2 build.xml

cziegeler2003/01/08 01:28:02 Modified:.build.xml Log: Fixing mock include for scratchpad build Revision ChangesPath 1.304 +2 -2 xml-cocoon2/build.xml Index: build.xml === RCS file: /

Re: Sources with strange line endings

Giacomo Pati wrote: I'm browsing throu the code doing Eclipses 'Organize Imports' all over I've realized there are a bunch of java file with strange line endings (always a blank line every other line). Torsten (Curdt): As it seems that they might be committed by you would you mind fixing them?

Re: Defining Source Interfaces

Carsten Ziegeler wrote: Sylvain Wallez wrote: The performance problem is that among all implementations of Source that I know of (URLSource, FileSource, SlideSource, BlobSource, XMLDBSource, SitemapSource and CVSSource), only one actually needs to be disposed (SitemapSource). So having a i

Re: Sources with strange line endings

On Wed, 8 Jan 2003, Torsten Curdt wrote: > Giacomo Pati wrote: > > I'm browsing throu the code doing Eclipses 'Organize Imports' all over > > I've realized there are a bunch of java file with strange line endings > > (always a blank line every other line). > > > > > > Torsten (Curdt): As it seems

Re: Sources with strange line endings

Torsten Curdt wrote: Giacomo Pati wrote: I'm browsing throu the code doing Eclipses 'Organize Imports' all over I've realized there are a bunch of java file with strange line endings (always a blank line every other line). Torsten (Curdt): As it seems that they might be committed by you would

Re: Sources with strange line endings

Sylvain Wallez wrote: Torsten Curdt wrote: Giacomo Pati wrote: I'm browsing throu the code doing Eclipses 'Organize Imports' all over I've realized there are a bunch of java file with strange line endings (always a blank line every other line). Torsten (Curdt): As it seems that they might be

cvs commit: xml-cocoon2/src/java/org/apache/cocoon/components/source ContextSourceFactory.java

sylvain 2003/01/08 03:01:39 Added: src/java/org/apache/cocoon/components/source Tag: cocoon_2_0_3_branch ContextSourceFactory.java Log: Fix bug #15279 (writeable source doesn't work with context: URLs) Revision ChangesPath No re

cvs commit: xml-cocoon2/src/webapp/WEB-INF cocoon.xconf

sylvain 2003/01/08 03:02:18 Modified:src/webapp/WEB-INF Tag: cocoon_2_0_3_branch cocoon.xconf Log: Fix bug #15279 (writeable source doesn't work with context: URLs) Revision ChangesPath No revision No revision 1.4.2.5

DO NOT REPLY [Bug 15279] - WriteableSource doesn't work with context: URLs

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

cvs commit: xml-cocoon2/src/java/org/apache/cocoon/components/source/impl ContextSourceFactory.java

sylvain 2003/01/08 03:04:53 Modified:src/java/org/apache/cocoon/components/source/impl ContextSourceFactory.java Log: Fix bug #15279 (writeable source doesn't work with context: URLs) Revision ChangesPath 1.7 +27 -29 xml-cocoon2/src/java/

Re: quicky: SWT & (mounted) subsitemaps

Sylvain Wallez wrote: Steven Noels wrote: and read http://marc.theaimsgroup.com/?t=10399060151&r=1&w=2 Yeah, I assigned myself this bug and have to fix it ASAP. But so many things to do ASAP... Fixed in both branches. In 2.0.4, you need to modify cocoon.xconf : - remove url-factory

Re: quicky: SWT & (mounted) subsitemaps

On Wednesday, Jan 8, 2003, at 08:48 Europe/London, Steven Noels wrote: Well, I'm a bit confused: there is a src attribute on the source:write element, but only in the status report apparently, and a source:source element which content should list the filename according to http://xml.apache

Re: quicky: SWT & (mounted) subsitemaps

Jeremy Quinn wrote: A bunch of people have reported recently that context:// does not work as a . TBH I do not remember testing it before that went into the docs I just assumed it would work, naughty me! I just fixed it and it does work now ;-) Sylvain -- Sylvain Wallez

Re: quicky: SWT & (mounted) subsitemaps

Sylvain Wallez wrote: Fixed in both branches. In 2.0.4, you need to modify cocoon.xconf : - remove url-factory 'context' - add source-handler : I'll check it out ASAP (before tomorrow). Thanks! -- Steven Noelshttp://outerthought.org/ Outerthought - Open Source, Jav

RE: Defining Source Interfaces

Sylvain Wallez wrote: > > Carsten Ziegeler wrote: > > >Sylvain Wallez wrote: > > > > > >>The performance problem is that among all implementations of > Source that > >>I know of (URLSource, FileSource, SlideSource, BlobSource, XMLDBSource, > >>SitemapSource and CVSSource), only one actually needs

Re: quicky: SWT & (mounted) subsitemaps

Jeremy Quinn wrote: On Wednesday, Jan 8, 2003, at 08:48 Europe/London, Steven Noels wrote: Well, I'm a bit confused: there is a src attribute on the source:write element, but only in the status report apparently, and a source:source element which content should list the filename according

Re: quicky: SWT & (mounted) subsitemaps

On Wednesday, Jan 8, 2003, at 12:03 Europe/London, Steven Noels wrote: Jeremy Quinn wrote: On Wednesday, Jan 8, 2003, at 08:48 Europe/London, Steven Noels wrote: Well, I'm a bit confused: there is a src attribute on the source:write element, but only in the status report apparently, and a

Re: quicky: SWT & (mounted) subsitemaps

Steven Noels wrote: > Could this be the case because I'm using this from an auto-mounted > subsitemap? Or that I use a file generating pointing to a pipeline using > cocoon: ? I checked without cocoon: protocol, no luck either... here's my SWT input file: http://apache.org/cocoon/include/1.0";

Re: Defining Source Interfaces

Carsten Ziegeler wrote: Sylvain Wallez wrote: Carsten Ziegeler wrote: Ah, btw you're right that the Source object should return a Collection instead of an Iterator for the children - I will fix that, too, asap. Cool. But I'm still not that happy with these methods being on Source itself. Wh

cvs commit: xml-cocoon2/src/documentation/xdocs/link livesites.xml

jeremy 2003/01/08 04:32:22 Modified:src/documentation/xdocs/link livesites.xml Log: added www.iniva.org to livesites Revision ChangesPath 1.11 +1 -0 xml-cocoon2/src/documentation/xdocs/link/livesites.xml Index: livesites.xml =

Re: quicky: SWT & (mounted) subsitemaps

Jeremy Quinn wrote: The only thing I can think of at this stage is this: should be : like you have : at the beginning SWT will balk on the extra text-node I believe. No luck. I'm lost on my first adventure with the SWT. See, Sylvain? ;-) -- Steven Noels

Re: quicky: SWT & (mounted) subsitemaps

Jeremy Quinn wrote: On Wednesday, Jan 8, 2003, at 08:48 Europe/London, Steven Noels wrote: Well, I'm a bit confused: there is a src attribute on the source:write element, but only in the status report apparently, and a source:source element which content should list the filename according

Re: cvs commit: xml-cocoon2/src/java/org/apache/cocoon/components/source/implContextSourceFactory.java

This change seems to introduce a loop at startup. If I revert to revision 1.6 Cocoon starts as usual. Sylvain, is this change running on your side? We used Tomcat 4.1.18, JDK 1.3.1, and ./build.sh clean installscratchpadwar. Giacomo On 8 Jan 2003 [EMAIL PROTECTED] wrote: > sylvain 2003/01/

[GUMP] Build Failure - xml-cocoon2

[echo] -- [echo] Apache Cocoon 20030108 [1999-2002] [echo] -- [echo] Building with Apache Ant version 1.6alpha compiled on January 8 2003 [echo] using build file /home

Re: Defining Source Interfaces

Nicola Ken Barozzi wrote: I really don't understand much of the heat in this discussion because I'm not so into it, but I'm happy you guys are and are making progress :-) Thanks. Actually, the discussions is about many points, one after the other ;-) I just wanted to ask for a second (plea

Re: [GUMP] Build Failure - xml-cocoon2

Sam Ruby wrote: This email is autogenerated from the output from: [...] BUILD FAILED file:///home/rubys/jakarta/xml-cocoon2

Re: cvs commit: xml-cocoon2/src/java/org/apache/cocoon/components/source/implContextSourceFactory.java

Giacomo Pati wrote: This change seems to introduce a loop at startup. If I revert to revision 1.6 Cocoon starts as usual. Sylvain, is this change running on your side? We used Tomcat 4.1.18, JDK 1.3.1, and ./build.sh clean installscratchpadwar. Shame on me, I tested only in the 2.0.x branch

RE: Defining Source Interfaces

Sylvain Wallez wrote: > > Nicola Ken Barozzi wrote: > > > > > I really don't understand much of the heat in this discussion because > > I'm not so into it, but I'm happy you guys are and are making > progress :-) > > > Thanks. Actually, the discussions is about many points, one after the

cvs commit: xml-cocoon2/src/java/org/apache/cocoon/components/source/impl ContextSourceFactory.java

sylvain 2003/01/08 06:08:05 Modified:src/java/org/apache/cocoon/components/source/impl ContextSourceFactory.java Log: Fix endless loop Revision ChangesPath 1.8 +14 -2 xml-cocoon2/src/java/org/apache/cocoon/components/source/impl/ContextS

Re: cvs commit: xml-cocoon2/src/java/org/apache/cocoon/components/source/implContextSourceFactory.java

Giacomo Pati wrote: This change seems to introduce a loop at startup. If I revert to revision 1.6 Cocoon starts as usual. Sylvain, is this change running on your side? We used Tomcat 4.1.18, JDK 1.3.1, and ./build.sh clean installscratchpadwar. Fixed. For an unknown reason, looking up the S

Re: Defining Source Interfaces

Carsten Ziegeler wrote: Sylvain Wallez wrote: [...] You're totally on track. If you need this action right now, I would suggest to mimic what's in the DirectoryGenerator, that makes the assumption that the Source is a file. You can then use all the facilities given by File. And we only ar

RE: cvs commit: xml-cocoon2/src/java/org/apache/cocoon/components/source/impl ContextSourceFactory.java

> From: Sylvain Wallez [mailto:[EMAIL PROTECTED]] > > > Fixed. > > For an unknown reason, looking up the SourceResolver in the compose() > method of a SourceFactory leads to an endless loop. So the fix consists > in delaying this lookup to the first call to getSource(). > > I don't know if it's r

Re: Defining Source Interfaces

Carsten Ziegeler wrote: Sylvain Wallez wrote: Carsten Ziegeler wrote: Cool. But I'm still not that happy with these methods being on Source itself. What about TraversableSource or HierarchicalSource (I have this last one ready on my PC with collections) ? I really don't like all the

RE: Defining Source Interfaces

Nicola Ken Barozzi wrote: > > Carsten Ziegeler wrote: > > Sylvain Wallez wrote: > > > [...] > >>You're totally on track. If you need this action right now, I would > >>suggest to mimic what's in the DirectoryGenerator, that makes the > >>assumption that the Source is a file. You can then use all th

Re: Defining Source Interfaces

Nicola Ken Barozzi wrote: Carsten Ziegeler wrote: Sylvain Wallez wrote: [...] You're totally on track. If you need this action right now, I would suggest to mimic what's in the DirectoryGenerator, that makes the assumption that the Source is a file. You can then use all the facilities g

Re: Defining Source Interfaces

Carsten Ziegeler wrote: Nicola Ken Barozzi wrote: Carsten Ziegeler wrote: Sylvain Wallez wrote: [...] You're totally on track. If you need this action right now, I would suggest to mimic what's in the DirectoryGenerator, that makes the assumption that the Source is a file. You can then u

RE: Defining Source Interfaces

Sylvain Wallez wrote: > > Okay. Let me throw in more arguments ;-) > Great! > How many protocols do we have for which parent and children make sense ? > Actually 2 : 'file' and 'slide' (and 'cvs' soon). For other protocols > such as 'cocoon', 'resource', 'blob', 'xmldb', 'http', etc, this has no

RE: Defining Source Interfaces

> > And as far as code cleanliness is concerned, an "instanceof" test seems > > more OOP to me than a isTraversable() method that tells us if is we have > > the right to use getParent() and getChildren(). With a separate > > interface, these methods do not exist if they do not make sense. > > > T

RE: Defining Source Interfaces

> -Original Message- > From: Stephan Michels [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, January 08, 2003 3:47 PM > To: [EMAIL PROTECTED] > Subject: RE: Defining Source Interfaces > > > > > > > And as far as code cleanliness is concerned, an "instanceof" > test seems > > > more OOP to m

Re: Defining Source Interfaces

Sylvain Wallez wrote: Nicola Ken Barozzi wrote: Carsten Ziegeler wrote: Sylvain Wallez wrote: [...] You're totally on track. If you need this action right now, I would suggest to mimic what's in the DirectoryGenerator, that makes the assumption that the Source is a file. You can then u

RE: Defining Source Interfaces

> From: Nicola Ken Barozzi [mailto:[EMAIL PROTECTED]] > >>MHO: It all depends on what a Source is. > >> > >>1 - If a source is a plug to a URI-based source handler, it should have > >>children. > >>2 -If it's a plug to a resource, it should not. > >> > >>Usually a source is (2), but since we bin

RE: [BUGS] cocoon 2.0.4 map:redirect-to

AFAIK, internal redirect is only implemented for the interpreted sitemap (treeprocessor), and 2.0.x uses the compiled sitemap by default. >From http://xml.apache.org/cocoon/changes.html for 2.0.3: Handle request forwarding (aka internal redirects) using the "cocoon:" pseudo-protocol : wri

RE: CVSView block

Hi, what is exactly your configuration problem? What do you want to use/write? Carsten > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, January 07, 2003 10:25 PM > To: [EMAIL PROTECTED] > Subject: CVSView block > > > Hi again, > > I mad

[Flow]: Modularizing flow scripts

My flowscript is getting big, and I've coded just a fraction of the functionality of my app. Is it possible to make it more modular, by including files from a master script that is the one referred to in the sitemap? Ugo -- Ugo Cei - http://www.beblogging.com/blog/ -

XMLForm / instance data from XML / Popup sample

Hi all, I've spend some time now understanding XMLForm and I have looked at the popup sample from Michael http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15100 I couldn't find a post from Josema Alonso regarding XForms & Xindice that appeared related. Ivelin, which one do you have in mind? Cou

Re: Defining Source Interfaces

Carsten Ziegeler wrote: Sylvain Wallez wrote: And as far as code cleanliness is concerned, an "instanceof" test seems more OOP to me than a isTraversable() method that tells us if is we have the right to use getParent() and getChildren(). With a separate interface, these methods do not exi

RE: Defining Source Interfaces

Sylvain Wallez wrote: > > > Following Stephen's example, I grep'ed instanceof on the whole 2.1 > source base and found... 388 of them ! > And how many of them are *not* because of Avalon? > >Anyway, I think your arguments are better than mine (sniff). > > > >So, we have a TraversableSource or Hie

Re: Defining Source Interfaces

On Wed, 8 Jan 2003, Sylvain Wallez wrote: > >Anyway, I think your arguments are better than mine (sniff). > > > >So, we have a TraversableSource or HierarchicalSource or ...? > > I'm not a native speaker, but the definition of traversable given by > dictionary.com makes me prefer hierarchical...

Re: Defining Source Interfaces

Nicola Ken Barozzi wrote: Sylvain Wallez wrote: Nicola Ken Barozzi wrote: Carsten Ziegeler wrote: Sylvain Wallez wrote: [...] You're totally on track. If you need this action right now, I would suggest to mimic what's in the DirectoryGenerator, that makes the assumption that the Sou

RE: Defining Source Interfaces

> > About the move() and copy() methods, I don't know if they should be kept > > in the new incarnation of this interface. > > > I don't think that they are important. A copy is a read/write action and > a move a read/write/delete action. We could make an utility class providing > support for it (

RE: Defining Source Interfaces

Sylvain Wallez wrote: > > Aren't we all a little bit mad to send dozen of mails for a bunch of > methods ;-P > And the real fun has just started: finding the correct name of something! Yuppie! BTW: How are our current blocks called now? (no, no, please don't take this as serious). Carsten ---

Re: Defining Source Interfaces

Stephan Michels wrote: On Wed, 8 Jan 2003, Sylvain Wallez wrote: Anyway, I think your arguments are better than mine (sniff). So, we have a TraversableSource or HierarchicalSource or ...? I'm not a native speaker, but the definition of traversable given by dictionary.com makes me prefer

Re: [RT] Flow/Sitemap Integration

On Mon, 23 Dec 2002, Stefano Mazzocchi wrote: > I know almost everybody is idle for the holydays, but I want to reply to > this before I forgot :) Unfortunaltly my idle time is over and im now back in "freezing" Germany. Hmmm... > > Michael Melhem wrote: > > Hi, > > > > Ok, here is a little "ran

cvs commit: xml-cocoon2/src/java/org/apache/cocoon/components/source/impl SitemapSource.java

cziegeler2003/01/08 08:07:38 Modified:src/java/org/apache/cocoon/components/source/impl SitemapSource.java Log: Minor performance update Revision ChangesPath 1.29 +12 -6 xml-cocoon2/src/java/org/apache/cocoon/components/source/impl/Sitema

Re: Defining Source Interfaces

Carsten Ziegeler wrote: Sylvain Wallez wrote: Aren't we all a little bit mad to send dozen of mails for a bunch of methods ;-P And the real fun has just started: finding the correct name of something! Yuppie! BTW: How are our current blocks called now? (no, no, please don't take this as ser

Re: Defining Source Interfaces

> >>About the move() and copy() methods, I don't know if they should be kept > >>in the new incarnation of this interface. > > > >:-/ not another MoveableSource ;-) > > ROFL !!! ;-) > Seriously, are these methods of real use ? I thought that these methods could be a good start for a cms webpor

Re: Defining Source Interfaces

Stephan Michels wrote: About the move() and copy() methods, I don't know if they should be kept in the new incarnation of this interface. I don't think that they are important. A copy is a read/write action and a move a read/write/delete action. We could make an utility class providing support

Re: cvs commit: xml-cocoon2/src/java/org/apache/cocoon/components/source/implContextSourceFactory.java

On Wed, 8 Jan 2003, Sylvain Wallez wrote: > Giacomo Pati wrote: > > >This change seems to introduce a loop at startup. If I revert to revision > >1.6 Cocoon starts as usual. > > > >Sylvain, is this change running on your side? We used Tomcat 4.1.18, JDK > >1.3.1, and ./build.sh clean installscratc

RE: Defining Source Interfaces

Sylvain Wallez wrote: > > > >The problem is, if you are using getInputStream/getOutputSteam to copy > >a file in a slide repository, that all metadata informations get lost. On > >the other hand, if you are using an external SourceUtil to copy a file, > >you can't hide all implementation details. >

cvs commit: xml-cocoon2/src/java/org/apache/cocoon/components/pipeline/impl AbstractCachingProcessingPipeline.java

cziegeler2003/01/08 08:20:13 Modified:src/java/org/apache/cocoon/components/pipeline/impl AbstractCachingProcessingPipeline.java Log: Added smart caching (which is the default and acts like the old 2.0.x caching) Revision ChangesPath 1.11 +3 -

cvs commit: xml-cocoon2/src/blocks/batik/java/org/apache/cocoon/serialization SVGSerializer.java

giacomo 2003/01/08 08:27:13 Modified:src/blocks/batik/java/org/apache/cocoon/serialization SVGSerializer.java Log: fixed a todo. God! Eclipse even finds those // TODO lines Revision ChangesPath 1.2 +4 -3 xml-cocoon2/src/blocks/batik/jav

RE: Defining Source Interfaces

On Wed, 8 Jan 2003, Carsten Ziegeler wrote: > > Sylvain Wallez wrote: > > What do you think about the ModifiableSource in Excalibur? (That should be > the replacement for WriteableSource - please let *me* win this time ;) ) Sylvain is hard to beat somtimes, I can tell from experience ;) Giacomo

cvs commit: xml-cocoon2/src/java/org/apache/cocoon/components/pipeline/impl AbstractCachingProcessingPipeline.java

cziegeler2003/01/08 08:35:13 Modified:src/java/org/apache/cocoon/components/pipeline/impl AbstractCachingProcessingPipeline.java Log: Turning of smart caching :( as it doesn't work... Revision ChangesPath 1.12 +17 -12 xml-cocoon2/src/java/

RE: Defining Source Interfaces

On Wed, 8 Jan 2003, Carsten Ziegeler wrote: > > > > -Original Message- > > From: Stephan Michels [mailto:[EMAIL PROTECTED]] > > Sent: Wednesday, January 08, 2003 3:47 PM > > To: [EMAIL PROTECTED] > > Subject: RE: Defining Source Interfaces > > > > > > > > > > > > And as far as code cleanli

RE: Defining Source Interfaces

Giacomo Pati wrote: > > And here is the definitiv answer from the avalon team: > > > > "Remember that this is component-oriented programming (COP) and > not OOP". > > > > :) > > C'mon. LifecycleHelper is the master batch of COP and not a "normal" > class! > :) Yes, I know - but if you look at m

RE: Defining Source Interfaces

On Wed, 8 Jan 2003, Carsten Ziegeler wrote: > Sylvain Wallez wrote: > > > > > >The problem is, if you are using getInputStream/getOutputSteam to copy > > >a file in a slide repository, that all metadata informations get lost. On > > >the other hand, if you are using an external SourceUtil to cop

Re: [Flow]: Modularizing flow scripts

On Wed, 8 Jan 2003, Ugo Cei wrote: > My flowscript is getting big, and I've coded just a fraction of the > functionality of my app. What is big for you in terms of lines? I thought a flowscript would be small and logic is modularized into Java classes. Giacomo

RE: [BUGS] cocoon 2.0.4 map:redirect-to

THANK YOU! I just switched to the interpreted sitemap and does indeed work, but it took a while to get everything else working again. In cocoon.xconf, why is the "file" attribute of "sitemap" ignored when using the interpreted sitemap implementation? Is there a new attribute to use for this purp

cvs commit: xml-cocoon2/src/java/org/apache/cocoon/components/pipeline/impl AbstractCachingProcessingPipeline.java

cziegeler2003/01/08 08:42:30 Modified:src/java/org/apache/cocoon/components/pipeline/impl AbstractCachingProcessingPipeline.java Log: Turning on smart caching as it works now :) Revision ChangesPath 1.13 +6 -5 xml-cocoon2/src/java/org/ap

cvs commit: xml-cocoon2/src/java/org/apache/cocoon/components/pipeline/impl AbstractCachingProcessingPipeline.java

cziegeler2003/01/08 08:42:58 Modified:src/java/org/apache/cocoon/components/pipeline/impl AbstractCachingProcessingPipeline.java Log: Turning on smart caching as it works now :) Revision ChangesPath 1.14 +1 -2 xml-cocoon2/src/java/org/ap

Re: Defining Source Interfaces

On Wed, 8 Jan 2003, Sylvain Wallez wrote: > Carsten Ziegeler wrote: > > >Sylvain Wallez wrote: > > > > > > > > >>And as far as code cleanliness is concerned, an "instanceof" test seems > >>more OOP to me than a isTraversable() method that tells us if is we have > >>the right to use getParent() an

Re: [Flow]: Modularizing flow scripts

Giacomo Pati wrote: On Wed, 8 Jan 2003, Ugo Cei wrote: My flowscript is getting big, and I've coded just a fraction of the functionality of my app. What is big for you in terms of lines? The one I'm currently working on is about 300 lines and I'm starting to feel unconfortable about it. The

RE: Defining Source Interfaces

> Stephan Michels wrote: > > >On Wed, 8 Jan 2003, Sylvain Wallez wrote: > > > >>>Anyway, I think your arguments are better than mine (sniff). > >>> > >>>So, we have a TraversableSource or HierarchicalSource or ...? > >>> > >>I'm not a native speaker, but the definition of traversable given by > >>d

Re: CVSView block

On Wed, Jan 08, 2003 at 04:12:12PM +0100, Carsten Ziegeler wrote: > Hi, > > what is exactly your configuration problem? What do you want to use/write? > > Carsten > I need to configure the root path for the generator, at construction time, so that it processes the (mandatory) path parameter (g

Re: Defining Source Interfaces

Giacomo Pati wrote: On Wed, 8 Jan 2003, Carsten Ziegeler wrote: Sylvain Wallez wrote: What do you think about the ModifiableSource in Excalibur? (That should be the replacement for WriteableSource - please let *me* win this time ;) ) Sylvain is hard to beat somtimes, I can tell from expe

Accessing java.sql.ResultSet via jxpath

Hello, we are thinking how a multi-line result from an SQL-query can be passed efficiently from the logic layer to the flow layer. One possibility, that currently works, is to build a List of Java objects (one for each row) and access this List via jxpath in the view. In the view we then have

[ANNOUNCE] XSLT-process 2.2 available

What is it? === XSLT-process is a mode for GNU Emacs/XEmacs which transforms it into a powerful editor with XSLT processing and debugging capabilities. With this mode you can: - run an XSLT processor on the Emacs buffer you edit, and view the results either in another Emacs buffer or i

Re: [Flow]: Modularizing flow scripts

Hi Ugo, On Wednesday, Jan 8, 2003, at 07:43 US/Pacific, Ugo Cei wrote: My flowscript is getting big, and I've coded just a fraction of the functionality of my app. Is it possible to make it more modular, by including files from a master script that is the one referred to in the sitemap? The

cvs commit: xml-cocoon2 build.xml

ovidiu 2003/01/08 10:38:14 Modified:.build.xml Log: Added conditional compilation for the mail action code in scratchpad. Revision ChangesPath 1.305 +18 -1 xml-cocoon2/build.xml Index: build.xml =

Re: org/apache/cocoon/mail does not compile conditionally

On Wednesday, Jan 8, 2003, at 01:26 US/Pacific, Giacomo Pati wrote: On Wed, 8 Jan 2003, Ovidiu Predescu wrote: Even without mail.jar not present in the lib/optional directory, this code in this package will still be compiled, leading to compilation errors. Bernhard, could you please try to fix

Re: Build system problems on OS/X 10.2.3

On Wednesday, Jan 1, 2003, at 04:46 US/Pacific, Jeremy Quinn wrote: On Wednesday, Jan 1, 2003, at 02:44 Europe/London, David Crossley wrote: I get the same problem on Linux with Java-1.3.1 ./build.sh -Dinclude.webapp.libs=yes webapp Well that is interesting! I was seriously beginning to thi

Re: quicky: SWT & (mounted) subsitemaps

Steven Noels wrote: No luck. I'm lost on my first adventure with the SWT. See, Sylvain? ;-) Ah - thanks to Bruno, I think I found out. In 2.0.3/4/5, the syntax of the SWT (still in scratchpad then) should be: http://apache.org/cocoon/source/1.0"; src="gump-profile.xml"> ... In HE

Re: quicky: SWT & (mounted) subsitemaps

Steven Noels wrote: In 2.0.3/4/5, the syntax of the SWT (still in scratchpad then) should be: http://apache.org/cocoon/source/1.0"; src="gump-profile.xml"> ... isn't needed, too. And now, I'll keep my mouth shut! -- Steven Noelshttp://outerthought.org/ Oute

RE: Build system problems on OS/X 10.2.3

We get the same error on Win2k + java1.3.1 but at another position during the build process. What's the reason for this ant problem? Regards, Reinhard > -Original Message- > From: Ovidiu Predescu [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, January 08, 2003 7:44 PM > To: [EMAIL PROTECTE

[FIXED] Re: Build system problems on OS/X 10.2.3, Linux and Windows

By increasing the amount of heap space allocated to the JVM, the build works fine now. I've added the -Xmx512mb parameter to the java invocation in tools/bin/ant, the last line in this file. A similar thing has to be done in tools/bin/ant.bat. I can check-in this change if it fixes the build pr

DO NOT REPLY [Bug 15900] New: - regexp matcher fails on certain patterns

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 15900] - regexp matcher fails on certain patterns

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 15900] - regexp matcher fails on certain patterns

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

  1   2   >