cvs commit: xml-cocoon2/src/scratchpad/src/org/apache/cocoon/treeprocessor/sitemap SitemapLanguage.java

cziegeler02/02/07 23:48:33 Modified:src/scratchpad/src/org/apache/cocoon/transformation EncodeURLTransformer.java src/scratchpad/src/org/apache/cocoon/treeprocessor/sitemap SitemapLanguage.java Log: - TreeProcessor now u

Re: [WARN] Bugzilla is still unaccessible?

> I don't have any problems accessing bugzilla and > the link on xml.apache.org is correct, too. > I had the same problem with the wrong link information some days > ago, but after a force reload in my IE (CTRL+F5) it got the correct > information. Some inbetween proxy problem perhaps. Thanks, re

RE: [WARN] Bugzilla is still unaccessible?

I don't have any problems accessing bugzilla and the link on xml.apache.org is correct, too. I had the same problem with the wrong link information some days ago, but after a force reload in my IE (CTRL+F5) it got the correct information. Some inbetween proxy problem perhaps. Carsten > -Ori

RE: RequestLifecycle [was: Re: cvs commit: xml-cocoon2/src/java/org/apache/cocoon/sitemap DefaultSitemapComponentSelector.java]

Sylvain Wallez wrote: > > Carsten Ziegeler wrote: > > >Sylvain Wallez wrote: > > > >> > >> > >> > >>But I have also have a question : should enter/leaveEnvironment be > >>called only once per request (i.e. on the root sitemap), or also on > >>every nested subsitemap ? > >> > >>In sitemap.handler,

RE: cvs commit: xml-cocoon2/src/scratchpad/src/org/apache/cocoon/transformation EncodeURLTransformer.java

> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] > Sent: Thursday, February 07, 2002 5:41 PM > To: [EMAIL PROTECTED] > Subject: Re: cvs commit: > xml-cocoon2/src/scratchpad/src/org/apache/cocoon/transformation > EncodeURLTransformer.java > > > Zitiere [EMAIL PROTECTED]: > > > cziegeler02/0

[WARN] Bugzilla is still unaccessible?

Hi, all! Still can't get access to Bugzilla. Anybody knows what's wrong? I can't submit the patch for i18n transformer - current version works not very correct and breaks samples. I've sent the patch to cocoon-dev yesterday, can anybody please apply it? Also, I've noticed that the link to 'Bug d

RE: Dispatcher/Adapter

Vadim, I like this as an elegant way to "go outside" the main flow, do something and continue. The important factor is the ability to script the behavior, change of the script produces changes of the behavior. > > Vadim, > > The document you are sending contains two in the case of this > example

[OT] howdy and congratulations

hey guys, long time no see. congratulations on getting a production c2 release out the door. i'm impressed with its quality and speed, and sorry i've not been able to participate for a while now. my day job got refocused away from doing web sites and onto doing webapps a while back, and while we w

RE: Dispatcher/Adapter

> From: DZIEMBOWSKI,KINGA (HP-NewJersey,ex2) [mailto:[EMAIL PROTECTED]] > > Vadim, > The document you are sending contains two in the case of this example > it will not work. is expected to be unique. Invent some other > modification of the document. How come? It works! When are embedded in e

RE: Dispatcher/Adapter

Vadim, The document you are sending contains two in the case of this example it will not work. is expected to be unique. Invent some other modification of the document. Kinga > -Original Message- > From: Vadim Gritsenko [mailto:[EMAIL PROTECTED]] > Sent: Thursday, February 07, 2002 7:

RE: Dispatcher/Adapter

No, I used online sample with: This is a part of the Body node tree This is a part of the Body node tree This is not a part of the Body node tree :) Vadim > From: DZIEMBOWSKI,KINGA (HP-NewJersey,ex2) [mailto:[EMAIL PROTECTED]] > > I belive you are using the first version I sent

RE: Java Compiler, Re: [vote] move tree-processor in the main trunk

Vadim, >Is there any interest in integrating Cocoon with pizza Java Compiler? >http://pizzacompiler.sourceforge.net Never heared of that... >My observations about it so far are: >1. Compiled byte code is almost identical to Sun's compiler output. >2. It is 450 Kb in size, comparing with 4.7Mb o

RE: StoreJanitor new calculation [was: Re: Store Janitor Hangs System]

Hi, applied to the scratchpad. Own config is missing. I have to go to bed now ;)... TIA ~Gerhard "Sorry, but my karma just ran over your dogma." >-Original Message- >From: Peter Hargreaves [mailto:[EMAIL PROTECTED]] >Sent: Tuesday, February 05, 2002 1:36 AM >To: [EMAIL PROTECTED] >Su

cvs commit: xml-cocoon2/src/scratchpad/src/org/apache/cocoon/jispstore StoreJanitorImpl.java MRUMemoryStore.java

froehlich02/02/07 15:38:07 Removed: src/scratchpad/src/org/apache/cocoon/jispstore StoreJanitorImpl.java MRUMemoryStore.java Log: moved to the main trunk -- In case of troubles, e-mail:

cvs commit: xml-cocoon2/src/scratchpad/src/org/apache/cocoon/storejanitor StoreJanitorImpl.java

froehlich02/02/07 15:37:35 Added: src/scratchpad/src/org/apache/cocoon/storejanitor StoreJanitorImpl.java Log: added re-factored StoreJanitor from Peter Hargreaves [[EMAIL PROTECTED]] into the scratchpad. Config is coming soon. Revision Changes

cvs commit: xml-cocoon2/src/scratchpad/src/org/apache/cocoon/storejanitor - New directory

froehlich02/02/07 15:36:07 xml-cocoon2/src/scratchpad/src/org/apache/cocoon/storejanitor - New directory -- In case of troubles, e-mail: [EMAIL PROTECTED] To unsubscribe, e-mail: [EMAIL PROTECTED] For addition

cvs commit: xml-cocoon2/src/java/org/apache/cocoon Cocoon.java Main.java

dims02/02/07 15:28:34 Modified:.build.xml src/java/org/apache/cocoon Cocoon.java Main.java Log: Trying to precompile both XSP and XMAP files. This can be used in Production WAR deployments where users do not need to tweak the XSP and XMAP. To try thi

RE: Dispatcher/Adapter

Vadim, The proposal contains set of interfaces and abstractions. The extensions build on top of it can choose the appropriate implementation. In this example the xml document is processed by StreamGenerator, then by the transformer implementing Dispatcher interface. This transformer is extracting

RE: Dispatcher/Adapter

I belive you are using the first version I sent. I omitted one line of code. It is corrected in the download from the page http://soap.bluestone.com/proposal. Kinga > -Original Message- > From: Vadim Gritsenko [mailto:[EMAIL PROTECTED]] > Sent: Thursday, February 07, 2002 5:43 PM > To: [

RE: Dispatcher/Adapter

I have got an exception: org.xml.sax.SAXException: Can't have more than one root on a DOM! :) BTW: Does this proposal based on DOM? Or is DOM used just in this example? Vadim > -Original Message- > From: DZIEMBOWSKI,KINGA (HP-NewJersey,ex2) [mailto:[EMAIL PROTECTED]] > Sent: Thursday, F

Dispatcher/Adapter

Hi, I feel that the tension of release is over, and we can return to the discussion on my proposal. I propose to add to the Cocoon project Dispatcher/Adapter concept. This set of interfaces and basic abstraction allows building pluggable extensions in a more standardized way. The real life example

Re: Interpreted Sitemap?

On Thursday 07 February 2002 05:00 pm, Sylvain Wallez wrote: > Fixed ! > > Peter, Giacomo, could you please test again ? Verified! :) -pete -- peter royal -> [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For ad

Re: Interpreted Sitemap?

giacomo wrote: >On Wed, 6 Feb 2002, Peter Royal wrote: > >>On Wednesday 06 February 2002 04:35 pm, Sylvain Wallez wrote: >> >>> src="our-app/sitemap.xmap" check-reload="yes"/> >>> src="original.sitemap.xmap"

cvs commit: xml-cocoon2/src/scratchpad/src/org/apache/cocoon/treeprocessor/sitemap MountNode.java

sylvain 02/02/07 13:53:55 Modified:src/scratchpad/src/org/apache/cocoon/treeprocessor TreeProcessor.java src/scratchpad/src/org/apache/cocoon/treeprocessor/sitemap MountNode.java Log: Fix map:mount bug when a file is spe

Java Compiler, Re: [vote] move tree-processor in the main trunk

All, Is there any interest in integrating Cocoon with pizza Java Compiler? http://pizzacompiler.sourceforge.net My observations about it so far are: 1. Compiled byte code is almost identical to Sun's compiler output. 2. It is 450 Kb in size, comparing with 4.7Mb of javac. 3. Startup time is fast

RE: [RT] Access Control (was [RT] Cocoon as OS)

> From: Sylvain Wallez [mailto:[EMAIL PROTECTED]] > > Vadim Gritsenko wrote: > > >>But the servlet spec doesn't allow a servlet to set the user > >>credential in the container. > >> > > > >It will be set for you by the container. > > > > There'a misunderstanding here : if authentication is perfo

Re: [RT] Access Control (was [RT] Cocoon as OS)

Vadim Gritsenko wrote: >>From: Sylvain Wallez [mailto:[EMAIL PROTECTED]] >> >>Vadim Gritsenko wrote: >> >>But the servlet spec doesn't allow a servlet to set the user >>credential in the container. >> > >It will be set for you by the container. > There'a misunderstanding here : if authenticatio

RE: [RT] Access Control (was [RT] Cocoon as OS)

> From: Greg Weinger [mailto:[EMAIL PROTECTED]] > > > > > > But the servlet spec doesn't allow a servlet to set the user > > > credentials in the container. > > > > It will be set for you by the container. > > > > Servlet spec 2.3, SRV.12.5.3 Form Based Authentication: > > 4. The container at

Re: EncodeURLTransformer to scratchpad

Stefano Mazzocchi wrote: >Sylvain Wallez wrote: > >>Carsten Ziegeler wrote: >> >>>But two minor things with your check-in: >>>a) Please add the licence header next time to the source when you check-in >>> >>Carsten, why is the full Apache license needed in each source file ? Did >>I miss somethin

Re: Application level config file/s ?

On Thursday 07 February 2002 02:34 pm, Marcus Crafter wrote: > Cocoon currently has the notion of user-roles to allow just this > for role definitions, and to me it seems like a good idea to > allow this at the component configuration level too ? perhaps even to > the exten

RequestLifecycle [was: Re: cvs commit: xml-cocoon2/src/java/org/apache/cocoon/sitemap DefaultSitemapComponentSelector.java]

Carsten Ziegeler wrote: >Sylvain Wallez wrote: > >> >> >> >>But I have also have a question : should enter/leaveEnvironment be >>called only once per request (i.e. on the root sitemap), or also on >>every nested subsitemap ? >> >>In sitemap.handler, it seems to be called for each subsitemap, whic

RE: [RT] Access Control (was [RT] Cocoon as OS)

> > But the servlet spec doesn't allow a servlet to set the user > credentials > > in the container. > > It will be set for you by the container. > > Servlet spec 2.3, SRV.12.5.3 Form Based Authentication: > 4. The container attempts to authenticate the user > using the information from th

Re: Anybody on Weblogic 6.1?

Here it is, but it looks more like a hack though. BR /kesh - Original Message - From: "Davanum Srinivas" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Wednesday, February 06, 2002 3:15 PM Subject: Re: Anybody on Weblogic 6.1? > Kesh, > > Yes, please send us a patch. > > Thanks, > di

Application level config file/s ?

Hi All, Hope all is well. I've been thinking recently about whether or not it makes sense to be able to separate the cocoon.xconf configuration file, so that application developers who choose to use Avalon, if they wish, can have their component's configur

RE: [vote] move tree-processor in the main trunk

> From: giacomo [mailto:[EMAIL PROTECTED]] > > On Thu, 7 Feb 2002, Stefano Mazzocchi wrote: > > > Ok, > > > > sitemap code generation is getting slower every day and is likely to > > become worse as we add more bugfixes and error generation. > > The last major rewrite has introduced a boost in

Re: Sitemap regeneration time slowed ?

On Fri, 8 Feb 2002, David Crossley wrote: > Christian Schmitt wrote: > > Vadim Gritsenko wrote: > > > > Christian Schmitt wrote: > > > > > > > > Hi all, > > > > after further checking into our "challenge" here, > > > > that's what we've found out: > > > > > > > > The changes to sitemap.xsl checke

Re: [vote] move tree-processor in the main trunk

On Thu, 7 Feb 2002, Stefano Mazzocchi wrote: > Ok, > > sitemap code generation is getting slower every day and is likely to > become worse as we add more bugfixes and error generation. The last major rewrite has introduced a boost in slownes. > Clearly, developping on cocoon with 20 seconds del

RE: [RT] Access Control (was [RT] Cocoon as OS)

> From: Sylvain Wallez [mailto:[EMAIL PROTECTED]] > > Vadim Gritsenko wrote: > > > > >>>The main problem, I think, is that HTTP requests on their own do not > >>>have the concept a user built into it, which is necessary to perform > >>>user-based access control. > >>> > >>They have, see (ftp:/

Re: cvs commit: xml-cocoon2/src/scratchpad/src/org/apache/cocoon/transformation EncodeURLTransformer.java

Zitiere [EMAIL PROTECTED]: > cziegeler02/02/07 06:40:17 > > Modified:src/scratchpad/src/org/apache/cocoon/transformation > EncodeURLTransformer.java > Log: > Improved encode transformer - it is now cacheable, if now session is > available Do you think

Re: [Patch] Character handling in i18n transformer fix

The best spec is the source code - welcome to the Open Source ;) A little less you can learn from docs: http://xml.apache.org/cocoon/apidocs/org/apache/cocoon/transformation/I18nTr ansformer.html and from the i18n samples that show most of the possible usage patterns. Although, there is a lot of

AW: [Patch] Character handling in i18n transformer fix

Hi Konstantin, I always uses the to translate 'Some text', eg. like these: Some text to be translated myparam1 myparam2 should be fine, since they used new i18n tags. But you'r right in case of your eg. the buffer is overwritten and will ignore 'normal text' Could you

Fw: [WOT] Google Programming Contest.

> Sorry for the Way Off Topic, and sorry if I missed this on the list already: > > http://www.google.com/programming-contest/ > > They say C++ or Java. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email

Re: [Patch] Character handling in i18n transformer fix

Good time of day again! I've fixed i18n transformer - now i18n samples work, also it'd be fine if anybody could test pages where chunked character data happens. Now, I hope, everything should be fine. I've change the implementation like as if a character filter is used - all the chunked data is

Re: [RT] Access Control (was [RT] Cocoon as OS)

Vadim Gritsenko wrote: >>>The main problem, I think, is that HTTP requests on their own do not >>>have the concept a user built into it, which is necessary to perform >>>user-based access control. >>> >>They have, see (ftp://ftp.isi.edu/in-notes/rfc2617.txt), for all the >>technical details ;).

Re: [vote] move tree-processor in the main trunk

On Thu, 07 Feb 2002 09:46:58 -0500, Berin Loritsch <[EMAIL PROTECTED]> wrote: > Vadim Gritsenko wrote: > > >>>Moreover, I'd love to be able to decide what to use (interpreted or > >>>compiled) from cocoon.xconf or, in case the treeprocessor ends > >>> > > up > > > >>>faster all the time, si

Re: [vote] move tree-processor in the main trunk

Jason Foster wrote: > > >> Just to make things clear : sitemap is only one of the possible uses >> of the TreeProcessor : it's a generic framework for implementing >> pipeline assembly languages (hence "Processor") with an evaluation >> tree (hence "Tree"). >> >> The supported languages are d

XSP Languages, RE: [vote] move tree-processor in the main trunk

> From: Jason Foster [mailto:[EMAIL PROTECTED]] > > > > > Just to make things clear : sitemap is only one of the possible uses of > > the TreeProcessor : it's a generic framework for implementing pipeline > > assembly languages (hence "Processor") with an evaluation tree (hence > > "Tree"). > >

Re: [vote] move tree-processor in the main trunk

> Just to make things clear : sitemap is only one of the possible uses of > the TreeProcessor : it's a generic framework for implementing pipeline > assembly languages (hence "Processor") with an evaluation tree (hence > "Tree"). > > The supported languages are defined in treeprocessor.xconf

Re: [vote] move tree-processor in the main trunk

Stefano Mazzocchi wrote: >Ok, > >sitemap code generation is getting slower every day and is likely to >become worse as we add more bugfixes and error generation. > >Clearly, developping on cocoon with 20 seconds delays between changes is >a nightmare and would scare people away instantly. > >Now

Re: [Patch] Character handling in i18n transformer fix

It seems that I've made an hasty conclusion that everything's work - the cause was another Tomcat instance with the old C2 deployed ;(( Current version of i18n transformer does not handle i18n samples correctly. The quick glance to the source showed that the problem is that the startI18NElement()

RE: Vote: JDJ Readers Choice Awards

Why Cocoon is not in the "Best Java Component" category? This ... weblogic portal is in. Vadim > -Original Message- > From: Carsten Ziegeler [mailto:[EMAIL PROTECTED]] > Sent: Thursday, January 31, 2002 3:00 AM > To: Cocoon-Dev; Cocoon-Users > Subject: Vote: JDJ Readers Choice Awards >

AW: [Patch] Character handling in i18n transformer fix

-Ursprüngliche Nachricht- Von: Piroumian, Konstantin [mailto:[EMAIL PROTECTED]] Gesendet am: Donnerstag, 7. Februar 2002 16:05 An: [EMAIL PROTECTED] Betreff: Re: [Patch] Character handling in i18n transformer fix > Applied, please check. Thanks > > I'm not sure about this trim() though:

Re: [Patch] Character handling in i18n transformer fix

> Applied, please check. Thanks > > I'm not sure about this trim() though: the result may be the words > concatenated with each other without single space... Yes, that's true, I think that trim() should be used at the end only - when looking for the translation. I'll fix it now. Konstantin >

Re: [vote] move tree-processor in the main trunk

Vadim Gritsenko wrote: >>>Moreover, I'd love to be able to decide what to use (interpreted or >>>compiled) from cocoon.xconf or, in case the treeprocessor ends >>> > up > >>>faster all the time, simply blast the compiled version and get rid >>> > of > >>>that stupid javac! >>> >>+1 I like

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

cziegeler02/02/07 06:40:17 Modified:src/scratchpad/src/org/apache/cocoon/transformation EncodeURLTransformer.java Log: Improved encode transformer - it is now cacheable, if now session is available Revision ChangesPath 1.3 +51 -52 xml-co

RE: [vote] move tree-processor in the main trunk

> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] > > > Ok, > > > > Now that we have a functional interpreted sitemap engine, I > > suggest we > > move this on the main trunk and keep improving on it from there. > +1 +1 > > Also, I would like to propose a name change: TreeProcessor isn't > >

Re: EncodeURLTransformer to scratchpad

On Thursday 07 February 2002 04:41 am, Sylvain Wallez wrote: > Carsten Ziegeler wrote: > >But two minor things with your check-in: > >a) Please add the licence header next time to the source when you check-in > > Carsten, why is the full Apache license needed in each source file ? Did > I miss som

RE: Sitemap regeneration time slowed ?

> From: Christian Schmitt [mailto:[EMAIL PROTECTED]] > > On Wed, Feb 06, 2002 at 03:26:54PM -0500, Vadim Gritsenko wrote: > > > From: Christian Schmitt [mailto:[EMAIL PROTECTED]] > > > > > > Hi all, > > > after further checking into our "challenge" here, > > > that's what we've found out: > > > >

RE: [Patch] Character handling in i18n transformer fix

Applied, please check. I'm not sure about this trim() though: the result may be the words concatenated with each other without single space... Vadim > -Original Message- > From: Piroumian, Konstantin [mailto:[EMAIL PROTECTED]] > Sent: Thursday, February 07, 2002 8:02 AM > To: [EMAIL PRO

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

vgritsenko02/02/07 06:23:15 Modified:src/java/org/apache/cocoon/transformation I18nTransformer.java Log: Applied patch from Piroumian, Konstantin [[EMAIL PROTECTED]] Revision ChangesPath 1.11 +28 -38 xml-cocoon2/src/java/org/apache/cocoon

Re: Sitemap regeneration time slowed ?

Christian Schmitt wrote: > Vadim Gritsenko wrote: > > > Christian Schmitt wrote: > > > > > > Hi all, > > > after further checking into our "challenge" here, > > > that's what we've found out: > > > > > > The changes to sitemap.xsl checked in recently checking the > > > pipeline rules, is what br

Re: JDJ Readers Choice Awards Logo

Carsten Ziegeler wrote: > Sylvain Wallez wrote: > > Carsten Ziegeler wrote: > > >what do you think about adding the JDJ Logo to our website? > > > > > >(from http://www.sys-con.com/java/readerschoice2002/468x60.jpg). > > > > > >Is this "legal"? > > > > > It seems to be, as http://www.sys-con.com/j

RE: [RT] Access Control (was [RT] Cocoon as OS)

> From: Daniel Fagerstrom [mailto:[EMAIL PROTECTED]] > > Greg Weinger wrote: > > > Browsers know about the HTTP authentication protocol, and if you use > > that, > > > they will send you username and password automatically. > > > > Where do you retrieve them? AFAIK they're not available in the

RE: [3rd party jar] sax-bugfix

> From: Carsten Ziegeler [mailto:[EMAIL PROTECTED]] > > Stefano Mazzocchi wrote: > > > > "Theodore W. Leung" wrote: > > > > > > Can anyone in cocoon verify the origin of this jar. If we can't, we'll > > > have to remove it from CVS. > > > > Let's remove it. xml-cocoon is a dead tree anyway. > >

Re: How to determine the end of character data?

> Sylvain Wallez wrote: > > Martin Holz wrote: > > >Piroumian, Konstantin wrote: > > >>Hi, Cocooners! > > >> > > >>According to SAX API the parser is free to split the character data to > > >>chunks. This causes problems in i18n transformer, which handles character > > >>data in the 'characters(ch

cvs commit: xml-cocoon2/src/java/org/apache/cocoon/components/xslt XSLTProcessorImpl.java

cziegeler02/02/07 05:10:41 Modified:src/java/org/apache/cocoon/components/xslt XSLTProcessorImpl.java Log: PP of code Revision ChangesPath 1.12 +279 -285 xml-cocoon2/src/java/org/apache/cocoon/components/xslt/XSLTProcessorImpl.java Ind

[Patch] Character handling in i18n transformer fix

Hi! I can't access the Bugzilla to submit this patch, seems that the site is down. Can anybody please apply this patch to i18n transformer that fixes chunked character SAX event handling. Thanks to Tommy Santoso for this patch. Best regards, Konstantin Piroumian i18n.diff Description:

Re: [RT] Access Control (was [RT] Cocoon as OS)

Greg Weinger wrote: > > Browsers know about the HTTP authentication protocol, and if you use > that, > > they will send you username and password automatically. > > Where do you retrieve them? AFAIK they're not available in the Servlet > API. You can use getAuthType(), getRemoteUser(), getUserPri

Re: [vote] move tree-processor in the main trunk

> Ok, > > Now that we have a functional interpreted sitemap engine, I > suggest we > move this on the main trunk and keep improving on it from there. +1 > > Also, I would like to propose a name change: TreeProcessor isn't > exactlyself-explanatory as a 'sitemap interpreter'. +1 > > Moreov

Re: [vote] move tree-processor in the main trunk

> Ok, > > sitemap code generation is getting slower every day and is likely to > become worse as we add more bugfixes and error generation. > > Clearly, developping on cocoon with 20 seconds delays between changes is > a nightmare and would scare people away instantly. > > Now that we have a funct

Re: [vote] move tree-processor in the main trunk

Yes, that's kool +1 for the tree-procressor ~Gerhard Stefano

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

cziegeler02/02/07 03:55:18 Modified:src/java/org/apache/cocoon/components CocoonComponentManager.java Log: Fix for new RequestLifecycle components when entering subsitemap Revision ChangesPath 1.6 +21 -8 xml-cocoon2/src/java/org/apache/

RE: [vote] move tree-processor in the main trunk

Stefano Mazzocchi wrote: > > Ok, > > sitemap code generation is getting slower every day and is likely to > become worse as we add more bugfixes and error generation. > > Clearly, developping on cocoon with 20 seconds delays between changes is > a nightmare and would scare people away instantl

RE: EncodeURLTransformer to scratchpad

Please refer to the comment affixed to the end of each list message: "To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] " - To unsubscribe, e-mail: [EMAIL P

R: EncodeURLTransformer to scratchpad

Title: R: EncodeURLTransformer to scratchpad I want unsubscribe myself from the mailing list ...how can I do? -Messaggio originale- Da: Stefano Mazzocchi [mailto:[EMAIL PROTECTED]] Inviato: giovedì 7 febbraio 2002 12.39 A: [EMAIL PROTECTED] Oggetto: Re: EncodeURLTransformer to scratc

[vote] move tree-processor in the main trunk

Ok, sitemap code generation is getting slower every day and is likely to become worse as we add more bugfixes and error generation. Clearly, developping on cocoon with 20 seconds delays between changes is a nightmare and would scare people away instantly. Now that we have a functional interpret

Re: EncodeURLTransformer to scratchpad

Sylvain Wallez wrote: > > Carsten Ziegeler wrote: > > >But two minor things with your check-in: > >a) Please add the licence header next time to the source when you check-in > > > Carsten, why is the full Apache license needed in each source file ? Did > I miss something about this ? Because ot

Re: [3rd party jar] sax-bugfix

Carsten Ziegeler wrote: > > Stefano Mazzocchi wrote: > > > > "Theodore W. Leung" wrote: > > > > > > Can anyone in cocoon verify the origin of this jar. If we can't, we'll > > > have to remove it from CVS. > > > > Let's remove it. xml-cocoon is a dead tree anyway. > > > > Anybody against this? >

RE: cvs commit: xml-cocoon2/src/java/org/apache/cocoon/sitemap DefaultSitemapComponentSelector.java

Sylvain Wallez wrote: > > > > But I have also have a question : should enter/leaveEnvironment be > called only once per request (i.e. on the root sitemap), or also on > every nested subsitemap ? > > In sitemap.handler, it seems to be called for each subsitemap, which > means for example that a R

Re: cvs commit: xml-cocoon2/src/java/org/apache/cocoon/sitemap DefaultSitemapComponentSelector.java

Carsten Ziegeler wrote: >Sylvain Wallez wrote: > >>Vadim Gritsenko wrote: >> >>>Sylvain, >>> >>>How it is different from SitemapComponentSelector? >>> >>>Just curios... >>> >>>Vadim >>> >>It's identical :) But as the TreeProcessor has it's own >>ComponentSelector to directly handle the syntax of

cvs commit: xml-cocoon2/src/scratchpad/src/org/apache/cocoon/treeprocessor/sitemap SitemapLanguage.java

sylvain 02/02/07 02:48:57 Modified:src/scratchpad/src/org/apache/cocoon/treeprocessor/sitemap SitemapLanguage.java Log: Remove some commented out code that is no more useful Revision ChangesPath 1.5 +2 -48 xml-cocoon2/src/scratchpad/src

AW: AW: How to determine the end of character data?

Hi Konstantin, I know you work on this stuff recently, could you please check it out at the next opportunity, not sure if it's the best way to make it. I would appreciate if you could make it, and maybe check it in as a patch ? thanks mate, Tommy -Ursprüngliche Nachricht- Von: Matt Serg

RE: EncodeURLTransformer to scratchpad

> -Original Message- > From: Sylvain Wallez [mailto:[EMAIL PROTECTED]] > Sent: Thursday, February 07, 2002 10:42 AM > To: [EMAIL PROTECTED] > Subject: Re: EncodeURLTransformer to scratchpad > > > Carsten Ziegeler wrote: > > >But two minor things with your check-in: > >a) Please add the l

Re: EncodeURLTransformer to scratchpad

Carsten Ziegeler wrote: >But two minor things with your check-in: >a) Please add the licence header next time to the source when you check-in > Carsten, why is the full Apache license needed in each source file ? Did I miss something about this ? This makes the mouse wheel roll and roll to go d

Re: Sitemap regeneration time slowed ?

On Wed, Feb 06, 2002 at 03:26:54PM -0500, Vadim Gritsenko wrote: > > From: Christian Schmitt [mailto:[EMAIL PROTECTED]] > > > > Hi all, > > after further checking into our "challenge" here, > > that's what we've found out: > > > > The changes to sitemap.xsl checked in recently checking the > > p

cvs commit: xml-cocoon2/src/scratchpad/src/org/apache/cocoon/treeprocessor TreeProcessor.java

cziegeler02/02/07 01:07:22 Modified:src/scratchpad/src/org/apache/cocoon/treeprocessor TreeProcessor.java Log: Added first part of support for the RequestLifecycleComponent to the TreeProcessor Revision ChangesPath 1.7 +4 -1 xml-cocoon

RE: cvs commit: xml-cocoon2/src/java/org/apache/cocoon/sitemap DefaultSitemapComponentSelector.java

Sylvain Wallez wrote: > > Vadim Gritsenko wrote: > > >Sylvain, > > > >How it is different from SitemapComponentSelector? > > > >Just curios... > > > >Vadim > > > It's identical :) But as the TreeProcessor has it's own > ComponentSelector to directly handle the syntax of as > its configuration, I

cvs commit: xml-cocoon2/src/java/org/apache/cocoon/util/log CocoonLogFormatter.java XMLCocoonLogFormatter.java

cziegeler02/02/07 00:59:17 Modified:src/java/org/apache/cocoon/environment/commandline FileSavingEnvironment.java LinkSamplingEnvironment.java src/java/org/apache/cocoon/environment/http HttpEnvironme

Re: cvs commit: xml-cocoon2/src/java/org/apache/cocoon/sitemap DefaultSitemapComponentSelector.java

Vadim Gritsenko wrote: >Sylvain, > >How it is different from SitemapComponentSelector? > >Just curios... > >Vadim > It's identical :) But as the TreeProcessor has it's own ComponentSelector to directly handle the syntax of as its configuration, I had to move the sitemap specific methods (getLa

cvs commit: xml-cocoon2/src/scratchpad/src/org/apache/cocoon/generation XPathDirectoryGenerator.java

cziegeler02/02/07 00:17:53 Modified:src/java/org/apache/cocoon/generation DirectoryGenerator.java FileGenerator.java FragmentExtractorGenerator.java HTMLGenerator.java JspGenerator.java PhpGenerator.java