Re: [vote] Arje Cahn as a new Cocoon committer

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Sylvain Wallez wrote: > Please cast your votes! +1, welcome :-) - -- Unico -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (Darwin) iD8DBQFDIWEecuec8tVNKAwRAkrwAKDXHhsIHEMp7m7uPupTB/qm4PPN3ACg2JxT z2ww43JTIDL3SC1huLX3Ick= =e0Vj -END PGP SIGN

Re: [JCR Block] Viewing content of properties and last modified

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Andreas Hartmann wrote: > Michael Wechner wrote: > >> Sylvain Wallez wrote: >> >>> Michael Wechner wrote: >>> Hi I have two questions re the JCR Block 1) How can one actually access the content of properties? >>> >>> >>>

Re: [VOTE] Switch to Maven NOW

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Carsten Ziegeler wrote: > So far the response was positiv, so I think we should just vote about it > and then do it. If you have any questions, please use the proposal thread. > > So please cast your votes for switching to Maven2 NOW as > outlined/dis

Re: DirectoryGenerator using abstract Source

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Michael Wechner wrote: > Joerg Heinicke wrote: > >> On 13.07.2005 00:28, Michael Wechner wrote: >> >>> It seems to me that the directory generator is not really based >>> on the "abstract methods" of an excalibur Source, but rather takes >>> the sourc

Re: Implementing in Forrest Locationmap

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Tim Williams wrote: > -BEGIN PGP SIGNED MESSAGE- > >>> >>>As can be seen in this code Unico reused much of the sitemap code >>>from Cocoon. My question is, can we also leverage the >>>code? Any pointers as to how to do this would be greatl

Re: Implementing in Forrest Locationmap

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Thorsten Scherler wrote: > On Mon, 2005-07-11 at 12:57 +0200, Unico Hommes wrote: > > Hi Ross! Great to see Forrest is finally making use of the > locationmap. I've been using it successfully myself for quite a while > now. >

Re: Implementing in Forrest Locationmap

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Ross! Great to see Forrest is finally making use of the locationmap. I've been using it successfully myself for quite a while now. Ross Gardler wrote: > Quite some time ago Unico created a Locationmap module for Forrest. > This allows us to specify

Re: [vote] Give Max Pfingsthorn temporary and restricted commit privileges to our code repository

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Reinhard Poetz wrote: > > As you all know, Max Pfingsthorn is one of our Google Summer of Code > students and he will work on the implementation of the cforms library. > > In order to make his life and the life of his two mentors (Sylvain and > I) ea

Re: svn commit: r191129 - /cocoon/trunk/blocks.properties

Reinhard Poetz wrote: > [EMAIL PROTECTED] wrote: > >> Author: unico >> Date: Fri Jun 17 04:24:24 2005 >> New Revision: 191129 >> >> URL: http://svn.apache.org/viewcvs?rev=191129&view=rev >> Log: >> jms dependencies changed >> >> Modified: >> cocoon/trunk/blocks.properties > > > Maybe I've ov

Re: FW: svn commit: r191131 - /cocoon/branches/BRANCH_2_1_X/src/blocks/mail/java/org/apache/cocoon/mail/transformation/SendMailTransformer.java

It does. Thanks, I'll fix it. -- Unico Nathaniel Alfred wrote: > Twice static final int MODE_xxx = 8 looks like copy-waste error? > Cheers, Alfred. > > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Sent: Freitag, 17. Juni 2005 13:46 > To: cvs@cocoon.apache.org

Re: [VOTE] Consensus about documentation location - revised version

Linden H van der (MI) wrote: > Hi Bertrand, > > >>P.S. Helma, it seems like your mailer is breaking threads sometimes, >>but not always. For example, [2] starts a new thread although it is >>obviously a reply to [3]. If it's easy to fix it might be >>good for our >>archives. >> >>[2] >>http:

Re: [VOTE] Document Editors, and a new Committer

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Upayavira wrote: > > On this basis, I'd like to propose Helma Van Der Linden as a Cocoon > committer, and thus our first 'publisher'. She has been participating > regularly in our community, and has shown a quiet but steady interest in > helping wit

Re: Eclipse 3.1's "Unnecessary else statement"

Carsten Ziegeler wrote: > Sylvain Wallez wrote: > >>Hi all, >> >>I noticed for a while that many commits are related to "making Eclipse >>happier" because of an additional 3.1 feature that flags "unnecessary >>else statement". >> >>These changes are for constructs such as: >>if (condition) {

Re: Small CMS on top of the SVN repository

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ross Gardler wrote: > Unico Hommes wrote: > >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA1 >> >> Linden H van der (MI) wrote: >> >>>> I have a little time on my hands to actually implement some o

Re: Planet Cocoon license and reuse of docs

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Stefano Mazzocchi wrote: > Unico Hommes wrote: > > >>BTW. Where *is* Linotype? I found this >>http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=110705988801725&w=2 but >> looking at http://simile.mit.edu/ I can&#

Re: Small CMS on top of the SVN repository

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Linden H van der (MI) wrote: >>I have a little time on my hands to actually implement some >>of the things mentioned. My only question is what are others >>possibly doing in parallel setting up some other system. I'd >>rather not duplicate efforts w

Re: Block builder and deployer

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Nicola Ken Barozzi wrote: > Unico Hommes wrote: > ... > >> Exactly my thinking. In fact the reason I asked is that I was thinking >> of starting a Maven2 plugin for cocoon. I've been looking at the >> emerging Maven

Re: Block builder and deployer

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Reinhard Poetz wrote: > Nicola Ken Barozzi wrote: > >> Unico Hommes wrote: >> ... >> >>> Exactly my thinking. In fact the reason I asked is that I was thinking >>> of starting a Maven2 plugin for cocoon. I&

Re: Small CMS on top of the SVN repository

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Reinhard Poetz wrote: > Unico Hommes wrote: > >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA1 >> >> Sylvain Wallez wrote: >> >> >>> Yes it *is* about the technology. Why don't we have co

Re: Block builder and deployer

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Reinhard Poetz wrote: > Unico Hommes wrote: > >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA1 >> >> Reinhard Poetz wrote: >> >>> Unico Hommes wrote: >>> >>> Nice to see you back

Re: Planet Cocoon license and reuse of docs

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Sylvain Wallez wrote: > > Yes it *is* about the technology. Why don't we have cool docs? Because > writing them in XML is a major PITA. That's why I dislike writing docs > so much. > > Give me an htmlarea in a webapp and I'll be happy to dump my bra

Re: modifiable source and .tmp files

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Reinhard Poetz wrote: > Unico Hommes wrote: > > Nice to see you back Unico! Thanks Reinhard! Lurker mode is off now, but still have some catching up to do. One of the things I'd been meaning to find out is what is the status of your

Re: modifiable source and .tmp files

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Close the OutputStream. Jorg Heymans wrote: > Hi, > > As per [1], i decided to have a go at implementing a SAX based > TeeTransformer. > > Now the code works [2], but cocoon writes a .tmp file instead of the > intended file (say myfile.log.tmp inste

Re: EHDefaultStore

On 3-dec-04, at 13:27, Jon Evans wrote: Hi Jorg, On 2 Dec 2004, at 13:38, Jorg Heymans wrote: Jon Evans wrote: I had to create my own "version" of EHDefaultStore, specific to my app, because I didn't want an eternal cache. I expire items after 5 minutes so that a db hit is forced (in case the da

Re: EHDefaultStore

On 3-dec-04, at 13:12, Jon Evans wrote: Hi Unico, On 2 Dec 2004, at 13:35, Unico Hommes wrote: On 2-dec-04, at 13:13, Jon Evans wrote: I needed a cache for part of my webapp. Basically I can look up lists of things, based on a number of parameters. I put all the parameters into a Serializable

Re: EHDefaultStore

On 2-dec-04, at 14:35, Unico Hommes wrote: Look at the implementation of CacheManager.create(1) 1. http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=107066391625123&w=2 Sorry this was not supposed to be related. The above link is an explanation of the current Store pattern in Coco

Re: EHDefaultStore

On 2-dec-04, at 13:13, Jon Evans wrote: Hi, I needed a cache for part of my webapp. Basically I can look up lists of things, based on a number of parameters. I put all the parameters into a Serializable class which becomes the key. If it isn't in the cache then I create a new object using a s

Re: [BUILD SYSTEM] New eclipse-customized-project task

Antonio Gallardo wrote: Hi: I wrote a new task for the Cocoon build system. The new task build the eclipse project files only for the blocks included in [local.]blocks.properties. Nice! Please commit it. -- Unico

Re: svn commit: rev 76124 - cocoon/trunk

On 18-nov-04, at 22:21, Geoff Howard wrote: On Wed, 17 Nov 2004 16:25:46 +0100, Unico Hommes <[EMAIL PROTECTED]> wrote: Geoff Howard wrote: ... I guess my question about optional dependencies gave the wrong impression of the utility of jms in event cache. I don't think it's a

Re: [VOTE] Release of 2.1.6

On 17-nov-04, at 22:32, Carsten Ziegeler wrote: Please cast your votes for releasing the current SVN of 2.1.x as 2.1.6. The vote will end on friday morning. +1 -- Unico

Re: svn commit: rev 76124 - cocoon/trunk

Geoff Howard wrote: Please change what? Remove what is viewed to be a key use-case of a block to avoid a dependency? Move one class into its own block? (there are very few classes in the event cache block anyway). The jms event cache item could also be moved into the "jms" block, but that then in

Re: NPE in AbstractCachingProcessingPipeline

the release. Carsten -Original Message- From: Unico Hommes [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 16, 2004 4:00 PM To: [EMAIL PROTECTED] Subject: Re: NPE in AbstractCachingProcessingPipeline The section that causes the NPE was added recently. If you say that there are

Re: NPE in AbstractCachingProcessingPipeline

The section that causes the NPE was added recently. If you say that there are situations where it causes an NPE then I believe you immediately. The code is rather incomprehensible to me as well to say the least. Lots of side effects and null states that are supposed to signal some sort of situa

Re: [URGENT] Fix status and sync branches before release

Vadim Gritsenko wrote: Hi guys, There are some changes which claimed to be in 2.1 and actually not in 2.1, and changes which are in 2.1 but not in 2.2. Please review the list and help to reconcile discrpancies before a release: --- cocoon-2.1.X\status.xml2004-11-11 09:36:01.164552000 -0500 +

Re: Problems with Quartz JobStore

Vadim Gritsenko wrote: Unico Hommes wrote: What if, instead of using the short names and , you declare the datasource like so: class="org.apache.avalon.excalibur.datasource.ResourceLimitingJdbcDataSource"> jdbc:postgresql://localhost/quartz cocoon ***

Re: Problems with Quartz JobStore

What if, instead of using the short names and , you declare the datasource like so: class="org.apache.avalon.excalibur.datasource.ResourceLimitingJdbcDataSource"> jdbc:postgresql://localhost/quartz cocoon * I was under the impression that ECM would transpare

Re: Implementation of the Continuations checker

On 30-okt-04, at 21:02, Giacomo Pati wrote: On Sat, 30 Oct 2004, Unico Hommes wrote: On 30-okt-04, at 18:46, Ralph Goers wrote: Carsten Ziegeler wrote: I think the key point is that we are using Quartz as the implementation, but not as the interface. Now we already have the quartz block with the

Re: [Heads up] Change to build system in 2.1.x

On 30-okt-04, at 20:05, Unico Hommes wrote: On 30-okt-04, at 19:29, Stefano Mazzocchi wrote: Ugo Cei wrote: Il giorno 25/ott/04, alle 19:14, Unico Hommes ha scritto: I've completed the changes to the build system discussed earlier [1]. In order to do so I have extended the gump descriptor

Re: [Heads up] Change to build system in 2.1.x

On 30-okt-04, at 19:29, Stefano Mazzocchi wrote: Ugo Cei wrote: Il giorno 25/ott/04, alle 19:14, Unico Hommes ha scritto: I've completed the changes to the build system discussed earlier [1]. In order to do so I have extended the gump descriptor with additional information that allows the

Re: Implementation of the Continuations checker

On 30-okt-04, at 18:46, Ralph Goers wrote: Carsten Ziegeler wrote: I think the key point is that we are using Quartz as the implementation, but not as the interface. Now we already have the quartz block with the required implementation, so it's easy to use that. The first step is to do this move.

Re: Persisting SimpleLuceneQuery [Long]

Jeremy Quinn wrote: On 29 Oct 2004, at 13:37, Unico Hommes wrote: Jeremy Quinn wrote: If email from this address is not signed IT IS NOT FROM ME Always check the label

Re: Persisting SimpleLuceneQuery [Long]

Jeremy Quinn wrote: If email from this address is not signed IT IS NOT FROM ME Always check the label, folks ! -

Re: Implementation of the Continuations checker

Nicola Ken Barozzi wrote: Unico Hommes wrote: ... I believe that the excalibur event package lives on at d-haven [1]. Why not use that? Oh oh. We did this discussion with the container, I hope we don't have to go over this again for every Avalon dependency we have ;-P Nope just with A

Re: Implementation of the Continuations checker

Giacomo Pati wrote: On Fri, 29 Oct 2004, Carsten Ziegeler wrote: Giacomo Pati wrote: On Fri, 29 Oct 2004, Carsten Ziegeler wrote: The current implementation of our continuations manager uses the excalibur event package for the background checker that checks for expired continuations. Now, this appr

Re: [VOTE] Leszek Gawron and Ralph Goers as committers

Torsten Curdt wrote: Folks please cast your votes for: [ ] Leszek [ ] Ralph as Apache Cocoon committers. +1 for both. -- Unico

Re: Locking the JS global scope to avoid implicit declarations

Carsten Ziegeler wrote: Sylvain Wallez wrote Carsten Ziegeler wrote: This might be a dump question, but I thought that global variables are attached to the session of the current user. Is this wrong or are there different kinds of global variables? Yes, t

Re: Blocker: Exception using cocoon:// protocol

Vadim Gritsenko wrote: Hey all, There is some issue with cocoon:// protocol that I can't wrap my head around... It is blocking 2.1.6 release. NullPointerException occurs when request's pipeline uses / includes another pipeline via cocoon:// protocol. It is reproducable using multiple samples:

Re: svn commit: rev 55619 - in cocoon/branches/BRANCH_2_1_X/src: test/anteater webapp/samples/test/reader-mime-type

Vadim Gritsenko wrote: Unico Hommes wrote: Vadim Gritsenko wrote: Unico Hommes wrote: Now only one release blocker remains: NPE in AbstractEnvironment.release() No, not exactly. As I see it, ResourceReader should return Source's mimeType in this particular case, as per: public S

Re: When to set mime-type

Luigi Bai wrote: On Wed, 27 Oct 2004, Unico Hommes wrote: Luigi Bai wrote: Exactly. This is the problem with delaying the setting of the mime type. For the general case we'd always have to buffer the whole response which isn't practical. Well, according to the Servlet spec, you rea

Re: When to set mime-type

Luigi Bai wrote: On Wed, 27 Oct 2004, Unico Hommes wrote: I would like to consider allowing the mime-type to be set during processing, perhaps even as late as after endDocument(). The reason for this is: I store images in XML documents as Base64 encoded data, and its element tag looks like

Re: When to set mime-type

Luigi Bai wrote: On Wed, 27 Oct 2004, Unico Hommes wrote: Vadim Gritsenko wrote: Unico Hommes wrote: Now only one release blocker remains: NPE in AbstractEnvironment.release() No, not exactly. As I see it, ResourceReader should return Source's mimeType in this particular case, a

Re: svn commit: rev 55619 - in cocoon/branches/BRANCH_2_1_X/src: test/anteater webapp/samples/test/reader-mime-type

Vadim Gritsenko wrote: Unico Hommes wrote: Now only one release blocker remains: NPE in AbstractEnvironment.release() No, not exactly. As I see it, ResourceReader should return Source's mimeType in this particular case, as per: public String getMimeType() { Contex

Re: svn commit: rev 55619 - in cocoon/branches/BRANCH_2_1_X/src: test/anteater webapp/samples/test/reader-mime-type

Now only one release blocker remains: NPE in AbstractEnvironment.release() -- Unico [EMAIL PROTECTED] wrote: Author: unico Date: Tue Oct 26 10:07:04 2004 New Revision: 55619 Modified: cocoon/branches/BRANCH_2_1_X/src/test/anteater/reader-mime-type.xml cocoon/branches/BRANCH_2_1_X/src/webapp/sa

Re: getInputStream() in FOM_Cocoon.FOM_Request ?

This seemed to be related to the removal of instrumentation from the axis block. Should be fixed now. -- Unico Tim Larson wrote: On Tue, Oct 26, 2004 at 01:49:24PM +0200, Unico Hommes wrote: On 24-okt-04, at 13:47, Unico Hommes wrote: The Request interface itself does not have

Re: getInputStream() in FOM_Cocoon.FOM_Request ?

On 24-okt-04, at 13:47, Unico Hommes wrote: On 24-okt-04, at 1:38, Frédéric Glorieux wrote: Hello, Like explained in another thread, I'm trying to implement a PUT binaries in the webdav/davmap demo. I wrote a simple "RequestReader" like waited in the sitemap sample, it works well

Re: [Heads up] Change to build system in 2.1.x

On 25-okt-04, at 20:35, Vadim Gritsenko wrote: Unico Hommes wrote: I've completed the changes to the build system discussed earlier [1]. In order to do so I have extended the gump descriptor with additional information that allows the build system to locate one or more dependency jar

[Heads up] Change to build system in 2.1.x

I've completed the changes to the build system discussed earlier [1]. In order to do so I have extended the gump descriptor with additional information that allows the build system to locate one or more dependency jars per project within ./lib/optional. See for an example the cocoon-block-axis

Re: getInputStream() in FOM_Cocoon.FOM_Request ?

Sylvain Wallez wrote: Frédéric Glorieux wrote: The Request interface itself does not have getInputStream method, only HttpRequest does. So first step would be to add getInputStream method to the Request and then add it to FOM. DONE, it seems to work for me. Still problems for a real world WebDA

Re: getInputStream() in FOM_Cocoon.FOM_Request ?

On 24-okt-04, at 1:38, Frédéric Glorieux wrote: Hello, Like explained in another thread, I'm trying to implement a PUT binaries in the webdav/davmap demo. I wrote a simple "RequestReader" like waited in the sitemap sample, it works well for httpRequest, because there is a getInputStream() metho

Re: webdav block, davmap, binaries PUT, request reader

Hi again, I thought that would have worked :-/ The problem may be that getInputStream is not defined on the Response interface but only on HttpResponse class. Hmm sorry, I guess a Reader is the best option ATM. -- Unico On 23-okt-04, at 20:30, Frédéric Glorieux wrote: Hello Unico, Back from fami

Re: webdav block, davmap, binaries PUT, request reader

You probably no longer need to write a Reader for that. Instead you should be able to use the ModuleSource. This component exposes input module values as Sources. Syntax is like so: module:moduleName:moduleAttr . So in the case of davmap, it would become: -- Unico On 23-okt-04, at 1:57, Frédé

Re: [cron block] dependency question

Vadim Gritsenko wrote: Unico Hommes wrote: Vadim Gritsenko wrote: Unico Hommes wrote: I'd like to add the ability to use an excalibur DataSourceComponent as the ConnectionProvider for the QuartzJobScheduler's JobStore. However the solution I had in mind results in an additional dep

Re: [cron block] dependency question

Vadim Gritsenko wrote: Unico Hommes wrote: I'd like to add the ability to use an excalibur DataSourceComponent as the ConnectionProvider for the QuartzJobScheduler's JobStore. However the solution I had in mind results in an additional dependency on the cocoon databases block. Not be

Re: [cron block] dependency question

Upayavira wrote: Unico Hommes wrote: Reinhard Poetz wrote: Unico Hommes wrote: [snip] For splitting the eclipse project there is an additional requirement that blocks and core directory don't overlap. Eclipse cannot deal with overlapping projects. So that would mean that the 2.2 core mo

Re: [cron block] dependency question

Reinhard Poetz wrote: Unico Hommes wrote: [snip] For splitting the eclipse project there is an additional requirement that blocks and core directory don't overlap. Eclipse cannot deal with overlapping projects. So that would mean that the 2.2 core move to /repos/asf/cocoon/trunk/core .

Re: [cron block] dependency question

Carsten Ziegeler wrote: Unico Hommes wrote: Ok ok, I get the hint ;-) Oh, that wasn't targetted at you, Unico, but if you have time... :) I didn't really feel that it was. It just seems opportune that I take up the issue since I raised it. I'll see what I can do. But

Re: [cron block] dependency question

Reinhard Poetz wrote: Unico Hommes wrote: Carsten Ziegeler wrote: 2. Move blocks to one location. /repos/asf/cocoon/trunk/blocks? yes 3. Separate blocks build system from core build system and let one drive the other. Comments? Some thoughts I want to share: goal: move towards real blocks

Re: [cron block] dependency question

Carsten Ziegeler wrote: Vadim Gritsenko wrote: Just an idea; can we move ALL libraries to lib/optional, and copy them into the WEB-INF/lib on as-needed basis, i.e. if block included which needs a library, only then librariy is copied over? This should be possible using the info from gump.xml.

Re: [RT] applying SoC on cocoon itself

Sylvain Wallez wrote: Unico Hommes wrote: Sylvain Wallez wrote: We already have this src="" attribute which currently is a raw string. Does this mean that we will enforce the contract on this by explicitely stating that it's a URI that will be resolved in the local co

Re: [RT] applying SoC on cocoon itself

Sylvain Wallez wrote: Stefano Mazzocchi wrote: Sylvain Wallez wrote: Stefano Mazzocchi wrote: and this solves *ALSO* the issue that was identified at the GT about "virtual pipeline components" resolving services locally or remotely (block-wise). The current problem with VPCs is the context in w

[cron block] dependency question

I'd like to add the ability to use an excalibur DataSourceComponent as the ConnectionProvider for the QuartzJobScheduler's JobStore. However the solution I had in mind results in an additional dependency on the cocoon databases block. Not because of a compilation dependency on the source code o

Re: svn commit: rev 55002 - cocoon/trunk/src/java/org/apache/cocoon/environment/wrapper

Sylvain Wallez wrote: Unico Hommes wrote: Sylvain Wallez wrote: [EMAIL PROTECTED] wrote: Author: unico Date: Mon Oct 18 06:10:24 2004 New Revision: 55002 Added: cocoon/trunk/src/java/org/apache/cocoon/environment/wrapper/ResponseWrapper.java Modified: cocoon/trunk/src/java/org/apache

Re: svn commit: rev 55002 - cocoon/trunk/src/java/org/apache/cocoon/environment/wrapper

Sylvain Wallez wrote: [EMAIL PROTECTED] wrote: Author: unico Date: Mon Oct 18 06:10:24 2004 New Revision: 55002 Added: cocoon/trunk/src/java/org/apache/cocoon/environment/wrapper/ResponseWrapper.java Modified: cocoon/trunk/src/java/org/apache/cocoon/environment/wrapper/EnvironmentWrapper.ja

Re: container independent lifecycles?

Ugo Cei wrote: Il giorno 16/ott/04, alle 18:36, Ugo Cei ha scritto: I posted a question about this to the Spring forum: I could have avoided it: the answer is in the users' list archive: http://sourceforge.net/mailarchive/message.php?msg_id=8578586 Looks like a very decent solution to me :-) -- Un

Re: container independent lifecycles?

Sylvain Wallez wrote: Unico Hommes wrote: That was one of my questions also. I have not had time to look at Spring framework so bare with me. One of the issues we currently have with ECM is that it does not do shutdown in order based on dependency information. At several places this leads to

Re: container independent lifecycles?

Ugo Cei wrote: Il giorno 16/ott/04, alle 16:08, Tim Larson ha scritto: All this talk about being independent from the container...but how do we get lifecycles and still stay independend from the container? public class X { public void init() { ... } public void destroy() { ... } } Now, there

Re: Invalid content length, revisited

Vadim Gritsenko wrote: Unico Hommes wrote: Vadim Gritsenko wrote: Unico Hommes wrote: Vadim Gritsenko wrote: Unico Hommes wrote: Oh I see now. The ResourceReader also sets the content length on the response. It *really* shouldn't do that IMHO. Anybody know why it does that? I see

Re: Invalid content length, revisited

Vadim Gritsenko wrote: Unico Hommes wrote: Vadim Gritsenko wrote: Unico Hommes wrote: Oh I see now. The ResourceReader also sets the content length on the response. It *really* shouldn't do that IMHO. Anybody know why it does that? I see that EnvironmentWrapper ignores set content length

Re: Invalid content length, revisited

Vadim Gritsenko wrote: Unico Hommes wrote: Oh I see now. The ResourceReader also sets the content length on the response. It *really* shouldn't do that IMHO. Anybody know why it does that? I see that EnvironmentWrapper ignores set content length. And it has RequestWrapper. BUT IT DOES NOT

Re: Invalid content length, revisited

Vadim Gritsenko wrote: Unico Hommes wrote: Oh I see now. The ResourceReader also sets the content length on the response. It *really* shouldn't do that IMHO. Anybody know why it does that? I see that EnvironmentWrapper ignores set content length. And it has RequestWrapper. BUT IT DOES NOT

Re: Cocoon 2.1.6 Release Plan, Re: Syncing 2.1.x and 2.2

Vadim Gritsenko wrote: Carsten Ziegeler wrote: According to the wiki we still have some open blocks/areas. http://wiki.apache.org/cocoon/MergingBranches In addition it seems that some new things have been checked in only to one branch, either trunk or 2.1.x, but not to both. Could everyone please

Re: Invalid content length, revisited

Unico Hommes wrote: Rogier Peters wrote: Guys, On 18/5 Joerg asked a question about invalid content length errors[1] due to readers. There is also a bug that is somewhat related[2], but it seems to be WONTFIX. The WONTFIX seems to apply to the original description of the bug only. There is

Re: Invalid content length, revisited

Rogier Peters wrote: Guys, On 18/5 Joerg asked a question about invalid content length errors[1] due to readers. There is also a bug that is somewhat related[2], but it seems to be WONTFIX. The WONTFIX seems to apply to the original description of the bug only. There is a related issue that is

Re: Fw: [SourceForge.net Release] ehcache : ehcache

Vadim Gritsenko wrote: Unico Hommes wrote: SourceForge.net wrote: Project "ehcache" ('ehcache') has released the new version of package 'ehcache'. I believe this was to be our cue for moving ehcache based store to the core and making it our default right? I have ju

Fw: [SourceForge.net Release] ehcache : ehcache

SourceForge.net wrote: Project: ehcache (ehcache) Package: ehcache Date : 2004-09-28 07:03 Project "ehcache" ('ehcache') has released the new version of package 'ehcache'. You can download it from SourceForge.net by following this link:

Re: svn commit: rev 47048 - cocoon/branches/BRANCH_2_1_X/src/blocks/cron/java/org/apache/cocoon/components/cron

Vadim Gritsenko wrote: [EMAIL PROTECTED] wrote: > Modified: cocoon/branches/BRANCH_2_1_X/src/blocks/cron/java/org/apache/cocoon/components/cron/QuartzJobScheduler.java > == > --- cocoon/branches/BRANCH_2_1_X/src/blocks/c

Re: DO NOT REPLY [Bug 31234] - Event Aware cache does not remove registry key

Geoff Howard wrote: On 15 Sep 2004 10:29:27 -, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: http://issues.apache.org/bugzilla/show_bug.cgi?id=31234 Event Aware cache does not remove registry key ... --- Additional Comments From [EMAIL PROTECTED] 2004-09-15 10:29 --- Thanks O

Re: Planning 2.1.6

Carsten Ziegeler wrote: The 2.1.x branch contains imho enough important bug fixes for a new release: 2.1.6. What do you think of a release by the end of september? +1 -- Unico

Re: EHCache in its own block?

Upayavira wrote: Pier Fumagalli wrote: On 2 Sep 2004, at 08:19, Ugo Cei wrote: Pier Fumagalli wrote: I think it might have been because in the code comments of the EHStore there's a mention that the store is not persistent across JVM restarts, but now it seems they "fixed" it... http://ehcache.so

Re: EHCache in its own block?

Ralph Goers wrote: At 9/1/2004 05:24 AM, you wrote: Could I move the EHCache-based store in its own block (unstable, for now, of course)? It seems to be behaving a lot better than JCS, and I seriously don't want to build the whole scratchpad just for one simple class and jar... Shouldn't both

Re: EHCache in its own block?

Pier Fumagalli wrote: On 1 Sep 2004, at 13:38, Unico Hommes wrote: Pier Fumagalli wrote: Could I move the EHCache-based store in its own block (unstable, for now, of course)? It seems to be behaving a lot better than JCS, and I seriously don't want to build the whole scratchpad just fo

Re: EHCache in its own block?

Pier Fumagalli wrote: Could I move the EHCache-based store in its own block (unstable, for now, of course)? It seems to be behaving a lot better than JCS, and I seriously don't want to build the whole scratchpad just for one simple class and jar... Some time ago I proposed the creation of a cac

Re: Actual implementation of passthrough

Nicola Ken Barozzi wrote: If the @passthrough attribute is to be put in the section of the mounted sitemap, it seems easy: make the PipelinesNodeBuilder set a passthrough variable in the PipelinesNode, and have the PipelinesNode tell or not the last PipelineNode if it has to stop: public v

Re: problem in 2.1 branch?

Antonio Gallardo wrote: Hi: I am trying to update libs, after doing a svn up and make a full rebuild I got: java.lang.ClassNotFoundException: org.apache.cocoon.components.jms.JMSEventListener am I missing a jar file? No, I forgot to commit the removal of some obsolete xpatch files. Very sorry a

Re: Subversion really slow

Leszek Gawron wrote: Unico Hommes wrote: My experience with subversion since we switched is that the cocoon repository is painfully slow at least using subclipse. I haven't much previous experience with subversion but I was under the impression that it should be more performant then CVS?

Re: Subversion really slow

Unico Hommes wrote: Vadim Gritsenko wrote: Ugo Cei wrote: On OS X Panther: $ time svn update At revision 36287. real1m6.448s user0m2.010s sys 0m4.010s On Windows XP, HDD 7200 RPM, last access timestamp disabled: cocoon-2.2.X $ time svn up At revision 36287. real0m29.125s user

Re: Subversion really slow

Vadim Gritsenko wrote: Ugo Cei wrote: On OS X Panther: $ time svn update At revision 36287. real1m6.448s user0m2.010s sys 0m4.010s On Windows XP, HDD 7200 RPM, last access timestamp disabled: cocoon-2.2.X $ time svn up At revision 36287. real0m29.125s user0m1.632s sys 0m2.6

Re: Subversion really slow

Vadim Gritsenko wrote: Adam R. B. Jack wrote: On Thu, 12 Aug 2004, Unico Hommes wrote: Well at least my applications don't freeze up and I can do other things in the meantime. But to give an impression to others of how serious this is on Windows platform, the first mail I sent was just af

Re: Subversion really slow

Adam R. B. Jack wrote: On Thu, 12 Aug 2004, Unico Hommes wrote: Well at least my applications don't freeze up and I can do other things in the meantime. But to give an impression to others of how serious this is on Windows platform, the first mail I sent was just after I started 's

Re: Subversion really slow

surf the net! I read somewhere that performance problems with subclipse will be solved as soon as svn 1.1 is out and they use it. Carsten -----Original Message- From: Unico Hommes [mailto:[EMAIL PROTECTED] Sent: Thursday, August 12, 2004 3:43 PM To: [EMAIL PROTECTED] Subject: Subversion really

  1   2   3   4   5   >