access component manager from outside cocoon?

Hi All, I am wanting to write a servlet filter that does some catch all session management issues based on facts stored in user profiles in XML format in my cocoon web application. Is there any way sensible way to access Cocoon or the ComponentManager from another servlet/servlet filter?

cvs commit: cocoon-2.1/lib/core resolver-20030708.jar resolver-20021114.jar

crossley2003/07/08 18:59:27 Modified:lib jars.xml Added: lib/core resolver-20030708.jar Removed: lib/core resolver-20021114.jar Log: Upgrade entity-resolver to the current version from xml-commons. This enables parsing of "XML Catalogs" that have a doc

Re: cvs commit: cocoon-site/site/2.1/*

Thanks. Now the wrong mailing list links are no longer available and the first PDFs have images, Antonio :) Joerg Vadim Gritsenko wrote: Done. Here is the log for you: ... Vadim

Re: cvs commit: cocoon-site/site/2.1/*

Joerg Heinicke wrote: A complete website update would take hours ... and megabytes ... This was only the root directory (for removing links to invalid mail-lists.html) and nearly 1 MB. But it seems that I can not login on daedalus as written at daedalus. Whom should I ask? Can someone else do

Re: cvs commit: cocoon-site/site/2.1/*

Forrest CVS HEAD did not work, used tagged version "stable-20030626". Joerg Steven Noels wrote: On 9/07/2003 0:02 Joerg Heinicke wrote: A complete website update would take hours ... and megabytes ... This was only the root directory (for removing links to invalid mail-lists.html) and nearly

Re: cvs commit: cocoon-site/site/2.1/*

On 9/07/2003 0:02 Joerg Heinicke wrote: A complete website update would take hours ... and megabytes ... This was only the root directory (for removing links to invalid mail-lists.html) and nearly 1 MB. But it seems that I can not login on daedalus as written at daedalus. Whom should I ask? Ca

Re: cvs commit: cocoon-site/site/2.1/*

A complete website update would take hours ... and megabytes ... This was only the root directory (for removing links to invalid mail-lists.html) and nearly 1 MB. But it seems that I can not login on daedalus as written at daedalus. Whom should I ask? Can someone else do the update? Joerg

Re: website redirection

Vadim Gritsenko wrote: Steven Noels wrote: The current setup of http://xml.apache.org/cocoon** is a redirect to http://cocoon.apache.org/2.0{1} using this .htaccess file: RedirectMatch permanent /cocoon(.*)$ "http://cocoon.apache.org/2.0$1 ... which means people who still use the old entry poin

Re: [vote] extend FOM_Request with remoteUser

Giacomo Pati wrote: Hi all I'd like to propose an extension to the FOM_Request class with the property 'remoteUser'. +1 hadn't noticed it was missing Geoff Howard

Re: [vote] extend FOM_Request with remoteUser

Giacomo Pati wrote: Hi all I'd like to propose an extension to the FOM_Request class with the property 'remoteUser'. +1. remoteUser obviously belongs to the business logic domain. Sylvain -- Sylvain Wallez Anyware Technologies http://www.apache.org/~sylvain

Old mailist in cocoon website.

hi: The Cocoon website still point to the old mail list @xml.apache.org check: http://cocoon.apache.org/2.1/mail-lists.html People tring to joint the list is having problem with this. Best Regards, Antonio Gallardo

RE: [vote] extend FOM_Request with remoteUser

> I'd like to propose an extension to the FOM_Request class > with the property 'remoteUser'. +1, your use case depicts a valid scenario > Use case > > The servlet container is configured for 'basic > authentication'. The Flow script needs the login name to map > it to a User object

[vote] extend FOM_Request with remoteUser

Hi all I'd like to propose an extension to the FOM_Request class with the property 'remoteUser'. Use case The servlet container is configured for 'basic authentication'. The Flow script needs the login name to map it to a User object. Alternative --- Use Input Module to pass th

Re: Tomcat 4.1.24 + Cocoon 2.1M3 : yet another endorsed lib issue...

Ok. My issue is still present with the option 2 of your wiki. If it doesn't work with this solution, there is no doubt that it will fail with the ParanoidServlet, no ? Sylvain Wallez wrote: Olivier Billard wrote: Thanks again ! I'll try it. From my previous mail, is there other differences b

Re: Tomcat 4.1.24 + Cocoon 2.1M3 : yet another endorsed lib issue...

Olivier Billard wrote: Thanks again ! I'll try it. From my previous mail, is there other differences between the paranoid servlet and the "too cool" one ? Absolutely no difference except the "shielding" classloader. Actually, ParanoidCocoonServlet is just a wrapper around any servlet with th

Re: Tomcat 4.1.24 + Cocoon 2.1M3 : yet another endorsed lib issue...

Thanks again ! I'll try it. From my previous mail, is there other differences between the paranoid servlet and the "too cool" one ? -- Olivier Sylvain Wallez wrote: Olivier Billard wrote: Thanks for your answer... ... but your wiki says why to use the ParanoidServlet, but not how to use it .

Re: Tomcat 4.1.24 + Cocoon 2.1M3 : yet another endorsed lib issue...

Thanks Joerg, In fact, I just tested with my own local tomcat and it works... Seems like the admin is gonna hear from me ;) Is the paranoid different from the "hippie" one just from that classloader order, or is there any other differences ? -- Olivier Billard Joerg Heinicke wrote: Besides the

Re: Tomcat 4.1.24 + Cocoon 2.1M3 : yet another endorsed lib issue...

Besides the ParanoidCocoonServlet option 2 should work (copying endorsed jars to $TOMCAT/common/endorsed (I have the same Tomcat version in use and working). Joerg Olivier Billard wrote: Hi all, Could you tell me what is the current receipe to get Cocoon M3 work with Tomcat 4.1.24 ? - Copy JA

cvs commit: cocoon-2.1 forrest.properties

cziegeler2003/07/08 07:12:55 Modified:.forrest.properties Log: Changing version :( Revision ChangesPath 1.17 +1 -1 cocoon-2.1/forrest.properties Index: forrest.properties === RCS fi

cvs commit: cocoon-2.1/src/blocks/woody/java/org/apache/cocoon/woody/acting HandleFormSubmitAction.java MakeFormAction.java

cziegeler2003/07/08 07:04:41 Modified:src/blocks/woody/java/org/apache/cocoon/woody/acting HandleFormSubmitAction.java MakeFormAction.java Log: Properly releasing sources Revision ChangesPath 1.5 +28 -22 cocoon-2.1/src/blocks/woody/java/o

Re: Tomcat 4.1.24 + Cocoon 2.1M3 : yet another endorsed lib issue...

Olivier Billard wrote: Thanks for your answer... ... but your wiki says why to use the ParanoidServlet, but not how to use it ... Erhm... edit your web.xml and change the servlet class name from org.apache.cocoon.servlet.CocoonServlet to org.apache.cocoon.servlet.ParanoidCocoonServlet ! It'

DO NOT REPLY [Bug 21213] - [PATCH] Paginator caches dynamic pagesheet rules

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: cocoon-site/site/news index.html

stevenn 2003/07/08 06:30:42 Modified:site/news index.html Log: GetTogether date Revision ChangesPath 1.6 +14 -5 cocoon-site/site/news/index.html Index: index.html === RCS file: /home/cvs/co

cvs commit: cocoon-site/site/link hosting.html livesites.html

stevenn 2003/07/08 06:30:06 Modified:site/link hosting.html livesites.html Log: changed AO hosting entry and added Orixo site Revision ChangesPath 1.2 +3 -2 cocoon-site/site/link/hosting.html Index: hosting.html ==

cvs commit: cocoon-site/src/documentation/content/xdocs/news index.xml

stevenn 2003/07/08 06:28:47 Modified:src/documentation/content/xdocs/news index.xml Log: GetTogether date Revision ChangesPath 1.7 +7 -0 cocoon-site/src/documentation/content/xdocs/news/index.xml Index: index.xml =

cvs commit: cocoon-site/src/documentation/content/xdocs/link livesites.xml

stevenn 2003/07/08 06:19:07 Modified:src/documentation/content/xdocs/link livesites.xml Log: added Orixo website Revision ChangesPath 1.3 +1 -0 cocoon-site/src/documentation/content/xdocs/link/livesites.xml Index: livesites.xml ==

RE: Bugzilla mails

Thanks Pier! From: Pier Fumagalli [mailto:[EMAIL PROTECTED] > Fixed... >

cvs commit: cocoon-site/src/documentation/content/xdocs/link hosting.xml

stevenn 2003/07/08 06:17:52 Modified:src/documentation/content/xdocs/link hosting.xml Log: AO does more than 1.8 Revision ChangesPath 1.2 +1 -1 cocoon-site/src/documentation/content/xdocs/link/hosting.xml Index: hosting.xml ==

Re: Tomcat 4.1.24 + Cocoon 2.1M3 : yet another endorsed lib issue...

Sorry, I meant younger than... Olivier Billard wrote: Thanks for your answer... ... but your wiki says why to use the ParanoidServlet, but not how to use it ... Is this already in use with a cocoon older than 6th June ? Sylvain Wallez wrote: Olivier Billard wrote: Hi all, Could you tell me

Re: Tomcat 4.1.24 + Cocoon 2.1M3 : yet another endorsed lib issue...

Thanks for your answer... ... but your wiki says why to use the ParanoidServlet, but not how to use it ... Is this already in use with a cocoon older than 6th June ? Sylvain Wallez wrote: Olivier Billard wrote: Hi all, Could you tell me what is the current receipe to get Cocoon M3 work with

Re: Bugzilla mails

"Joerg Heinicke" <[EMAIL PROTECTED]> wrote: > After the mailing list moves the account [EMAIL PROTECTED] > should be updated. Otherwise we won't get any mails from Bugzilla. Fixed... There was also a problem with the mailing list configuration... Every mail sent to cocoon-(.*)@xml.apache.org was

Re: Tomcat 4.1.24 + Cocoon 2.1M3 : yet another endorsed lib issue...

Olivier Billard wrote: Hi all, Could you tell me what is the current receipe to get Cocoon M3 work with Tomcat 4.1.24 ? - Copy JARs from lib/endorsed to JDK endorsed folder (didn't try - copy endorsed jars to $TOMCAT/common/endorsed (doesn't work for me) - leave $TOMCAT/common/endorsed empty (do

Re: Bugzilla mails

http://nagoya.apache.org/ The Scarab Issue Tracking System: Scarab is an alternative Issue Tracking System and it will shortly replace the current BugZilla installation. Joerg -- System Development VIRBUS AG Fon +49(0)341-979-7419 Fax +49(0)341-979-7409 [EMAIL PROTECTED] www.virbus.de

[IGNORE] Testing delivery to list from BugZilla.

Part 1 of 2 .

Tomcat 4.1.24 + Cocoon 2.1M3 : yet another endorsed lib issue...

Hi all, Could you tell me what is the current receipe to get Cocoon M3 work with Tomcat 4.1.24 ? - Copy JARs from lib/endorsed to JDK endorsed folder (didn't try - copy endorsed jars to $TOMCAT/common/endorsed (doesn't work for me) - leave $TOMCAT/common/endorsed empty (doesn't work for me) Wiki

RE: protected vs private instance members (in Woody)

Sylvain Wallez wrote: > -Original Message- > From: Sylvain Wallez [mailto:[EMAIL PROTECTED] > Sent: Tuesday, July 08, 2003 2:29 PM > To: [EMAIL PROTECTED] > Subject: Re: protected vs private instance members (in Woody) > > > >+5 (and you owe me another beer that I didn't gave up this time

Re: Cocoon and Component Manager (was RE: protected vs private instancemembers (in Woody))

Carsten Ziegeler wrote: Upayavira wrote: That was me! I know :) When I converted the CocoonBean to use ModifiableSources, I needed to get hold of a SourceResolver. As the bean isn't an Avalon component, it didn't have one itself. The only place I could think of to get it was the Coco

Re: protected vs private instance members (in Woody)

Carsten Ziegeler wrote: Puh, I need some beer... Sylvain Wallez wrote: Take another example : CocoonComponentManager.getCurrentEnvironment(). We need this method to have the "public" access modifier because we need this information to implement SitemapSource and other pipeline machinery. But w

Re: Bugzilla mails

On Mon, Jul 07, 2003 at 06:26:44PM +0200, Andreas Kuckartz wrote: > There are other alternatives to Bugzilla as well. One of them is Scarab > (http://scarab.tigris.org/). An aspect of Jira which I do not like is that > it is proprietary. But then, the JIRA docs are built using Cocoon ;) http://ww

Re: LinkGatherer and Internal Requests

On Mon, Jul 07, 2003 at 10:33:26AM +0100, Upayavira wrote: > Having seen Sylvain's env.isExternal(), I have updated CLI so that it only adds a > LinkGatherer to external pipelines. Thus it will no longer be appended to internal > cocoon: pipelines. Thanks for that Sylvain. > > Jeff had a problem

Re: website redirection

Steven Noels wrote: The current setup of http://xml.apache.org/cocoon** is a redirect to http://cocoon.apache.org/2.0{1} using this .htaccess file: RedirectMatch permanent /cocoon(.*)$ "http://cocoon.apache.org/2.0$1 ... which means people who still use the old entry point will not be aware of

RE: protected vs private instance members (in Woody)

Puh, I need some beer... Sylvain Wallez wrote: > Take another example : CocoonComponentManager.getCurrentEnvironment(). > We need this method to have the "public" access modifier because we need > this information to implement SitemapSource and other pipeline > machinery. But we all agree that

RE: Cocoon and Component Manager (was RE: protected vs private instance members (in Woody))

Upayavira wrote: > > On 8 Jul 2003 at 12:29, Carsten Ziegeler wrote: > > > Has someone followed the changes to Cocoon.java regarding the > > component manager. It started as private was changed to protected and > > then changed to public by someone who needed it (also it was never > > meant to be

Re: protected vs private instance members (in Woody)

Carsten Ziegeler wrote: Sylvain Wallez wrote: Sure. But then, one way or the other, the contract of the class with its subclasses is changed, and the subclasses are broken ! Yepp, but I think in this case it's ok, the subclasses have to be adjusted accordingly. You can't make implementations 1

Cocoon and Component Manager (was RE: protected vs private instance members (in Woody))

On 8 Jul 2003 at 12:29, Carsten Ziegeler wrote: > Has someone followed the changes to Cocoon.java regarding the > component manager. It started as private was changed to protected and > then changed to public by someone who needed it (also it was never > meant to be public!). But as it's open sour

RE: protected vs private instance members (in Woody)

Sylvain Wallez wrote: > > Sure. But then, one way or the other, the contract of the class with its > subclasses is changed, and the subclasses are broken ! > Yepp, but I think in this case it's ok, the subclasses have to be adjusted accordingly. You can't make implementations 100% compatible and de

website redirection

The current setup of http://xml.apache.org/cocoon** is a redirect to http://cocoon.apache.org/2.0{1} using this .htaccess file: RedirectMatch permanent /cocoon(.*)$ "http://cocoon.apache.org/2.0$1 ... which means people who still use the old entry point will not be aware of our TLP status other

Re: interest on Woody extension ?

> Sounds interessting. Please submit them using Bugzilla. ok, done. it seems that bugzilla is sending mail to the old mailing lists. anyway, here's the link: http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21397 Cheers, Frank

Re: protected vs private instance members (in Woody)

Carsten Ziegeler wrote: Vadim Gritsenko wrote: Carsten Ziegeler wrote: I hope this makes sense :) if not at all, we can revert it. Not exactly; see Sylvain's response and in addition to it please recall a vote about flow model "add only very necessary things instead of adding al

cvs commit: cocoon-2.1/src/documentation/xdocs/userdocs/generators search-generator.xml

upayavira2003/07/08 01:46:33 Modified:src/documentation/xdocs/userdocs/generators search-generator.xml Log: Fixing Typos Revision ChangesPath 1.2 +5 -5 cocoon-2.1/src/documentation/xdocs/userdocs/generators/search-generator.xml Ind

cvs commit: cocoon-2.1/src/webapp/WEB-INF/entities catalog.xcat

crossley2003/07/08 01:41:14 Modified:src/webapp/WEB-INF/entities catalog.xcat Log: Tweaks to the experimental "XML Catalog": - Removed old sitemap DTD - Added missing book DTD - Added document type declaration for catalog DTD, but commented-out because many tools cannot cope

cvs commit: cocoon-2.1/src/webapp/samples/catalog article.xml

crossley2003/07/08 01:35:41 Modified:src/webapp/samples/catalog article.xml Log: Correct the image height. Revision ChangesPath 1.2 +1 -1 cocoon-2.1/src/webapp/samples/catalog/article.xml Index: article.xml ===

Re: JXTemplate* and FOM moved to core

On 8/07/2003 8:03 Christopher Oliver wrote: I've moved the FOM implementation and JXTemplate* to the core. For now I've left the original flow implementation in place as a second interpreter, so Woody, Linotype, XMLForm, and the Flow samples will continue to work without change until we can mig

cvs commit: cocoon-2.1/src/documentation/xdocs/userdocs/generators xpathdirectory-generator.xml

upayavira2003/07/08 01:27:21 Modified:src/documentation/xdocs/userdocs/generators xpathdirectory-generator.xml Log: Minor grammar & typo changes Revision ChangesPath 1.2 +4 -4 cocoon-2.1/src/documentation/xdocs/userdocs/generators/xpath

cvs commit: cocoon-2.1/src/documentation/xdocs/userdocs/readers axisrpc-reader.xml

giacomo 2003/07/08 01:21:56 Modified:src/documentation/xdocs/userdocs/readers axisrpc-reader.xml Log: reflect correct version Revision ChangesPath 1.2 +1 -1 cocoon-2.1/src/documentation/xdocs/userdocs/readers/axisrpc-reader.xml Index: axisrpc-reader.xml

Re: SourceResolver in M3 and symbolic links

On Tue, 2003-07-08 at 09:56, Bruno Dumon wrote: > On Mon, 2003-07-07 at 22:55, Nathaniel Alfred wrote: > > The latest version of excalibur.source.SourceResolver packaged > > with Cocoon-2.1m3 normalizes URIs containing "/foo/../bar" to "/bar". > > At first sight this looks a good idea and is accor

Re: SourceResolver in M3 and symbolic links

On Mon, 2003-07-07 at 22:55, Nathaniel Alfred wrote: > The latest version of excalibur.source.SourceResolver packaged > with Cocoon-2.1m3 normalizes URIs containing "/foo/../bar" to "/bar". > At first sight this looks a good idea and is according to RFC 2396. > > But when dealing with file: URIs