[IMP] Release process starts at 11:00 UTC
I will start the release process of 2.1.7 at 11:00 UTC which is in approx. 2,5 hours. Please refrain from checking in during the release process. Thanks Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: [Vote] Release of 2.1.7 on wednesday
On 22 Mar 2005, at 14:48, Carsten Ziegeler wrote: It seems that most of us agree that the current reported problems are no blockers, so I suggest to release tomorrow (wednesday) whatever we will have by then (if someone is able to fix some problems in the next 20 hours even better). So, please cast your votes: Thanks for all the hard work, chaps! +1 regards Jeremy If email from this address is not signed IT IS NOT FROM ME Always check the label, folks ! smime.p7s Description: S/MIME cryptographic signature
Re: Couple of tests I ran on Cocoon, VMs and JDKs
Stefano Mazzocchi wrote: Pier Fumagalli wrote: FYI, might be interesting for the Cocooners out there, as that's what I've tested. http://www.betaversion.org/~pier/wiki/display/pier/32+Versus+64 Interesting. It would also be kinda cool to have some other data in terms of concurrency, you are stressing with 10 threads, but it would be interesting to see if the 64bit architecture handles load better or worse (don't know why, but it's another axis to consider that you haven't in your exercise). yes, I know you might not care :-) Anybody done any comparisons between Java 1.5 and 1.4.2? ...Since Cocoon now compiles cleanly on 1.5. Ben
Re: Couple of tests I ran on Cocoon, VMs and JDKs
On 23 Mar 2005, at 04:32, Stefano Mazzocchi wrote: Pier Fumagalli wrote: FYI, might be interesting for the Cocooners out there, as that's what I've tested. http://www.betaversion.org/~pier/wiki/display/pier/32+Versus+64 Interesting. It would also be kinda cool to have some other data in terms of concurrency, you are stressing with 10 threads, but it would be interesting to see if the 64bit architecture handles load better or worse (don't know why, but it's another axis to consider that you haven't in your exercise). yes, I know you might not care :-) Yep, I don't! :-) For VNUNET, our acceptor limit set on Jetty is (IIRC) 15. So, only a maximum of 15 threads can access Cocoon at the same time. We cache the bejesus out of the application, so parallelization of tasks is not that important to us, while raw speed definitely is. FWIW, I tested threading comparing normal linux threads with NPTL, and there you definitely had a massive improvement by switching to NPTL, but more than that, I can't tell you... I believe SIMILE runs on the same hardware, right (or was it a HP 360/G3?) I think you can ran the tests yourself! :-P Pier smime.p7s Description: S/MIME cryptographic signature
Re: [IMP] Release process starts at 11:00 UTC
Carsten Ziegeler wrote: I will start the release process of 2.1.7 at 11:00 UTC which is in approx. 2,5 hours. Please refrain from checking in during the release process. Thanks Carsten OK, I start the process NOW... Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
[IMP] End of code freeze
The code freeze is over - the release is currently uploading. Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: Experimental per-sitemap reloadable classloader
Sylvain Wallez wrote: So I wrote in 2.2 an experimental per-sitemap classpath that allows each sitemap to define its own specific classpath for the components defined by map:components. The syntax is as follows (the sitemap is in src/webapp hence the ../..). map:components map:classpath class-dir src=../../build/eclipse/ lib-dir src=../../lib/ /map:classpath !-- other components -- /map:components Hmmm, I've used this for the first time today and I have to say that I would love my cocoon application to be 'self-contained', so to speak, so that I can move it around at best. What I've done is: 1) package my stuff so that it looks like a real block README.txt INSTALL.txt sitemap.xmap -- this is my block sitemap stylesheets -- this is the block resources * -- add other resources at will src/java -- this is the components sources lib -- this contains the jar my code depends on build/eclipse -- here is where eclipse compiles stuff 2) add map:classpath class-dir src=./build/eclipse/ lib-dir src=./lib/ /map:classpath to the sitemap above 3) add a symlink $COCOON_HOME/build/webapp/mycocoonapp - /code/mycocoonapp et voila', you are able to 'mount' stuff in cocoon without even touching a single line in your cocoon installation, then you just have to have your proxypass setup so that http://host/mycocoonapp points to http://127.0.0.1:/mycocoonapp. Easy, fast and secure. Too bad it doesn't work! since 'lib-dir' resolves the '.' in './lib' as local to the cocoon context, instead of the location of the sitemap it's found in. This is a mistake, IMO: a real block should *NOT* contain any information about where it has been mounted and this behavior requires it to do so, preventing the block to be mounted somewhere else transparently. Is there any need for this behavior that I didn't consider? -- Stefano.
Re: Experimental per-sitemap reloadable classloader
Stefano Mazzocchi wrote: Sylvain Wallez wrote: So I wrote in 2.2 an experimental per-sitemap classpath that allows each sitemap to define its own specific classpath for the components defined by map:components. The syntax is as follows (the sitemap is in src/webapp hence the ../..). map:components map:classpath class-dir src=../../build/eclipse/ lib-dir src=../../lib/ /map:classpath !-- other components -- /map:components Hmmm, I've used this for the first time today and I have to say that I would love my cocoon application to be 'self-contained', so to speak, so that I can move it around at best. What I've done is: 1) package my stuff so that it looks like a real block README.txt INSTALL.txt sitemap.xmap -- this is my block sitemap stylesheets -- this is the block resources * -- add other resources at will src/java -- this is the components sources lib -- this contains the jar my code depends on build/eclipse -- here is where eclipse compiles stuff 2) add map:classpath class-dir src=./build/eclipse/ lib-dir src=./lib/ /map:classpath to the sitemap above 3) add a symlink $COCOON_HOME/build/webapp/mycocoonapp - /code/mycocoonapp et voila', you are able to 'mount' stuff in cocoon without even touching a single line in your cocoon installation, then you just have to have your proxypass setup so that http://host/mycocoonapp points to http://127.0.0.1:/mycocoonapp. Easy, fast and secure. Too bad it doesn't work! since 'lib-dir' resolves the '.' in './lib' as local to the cocoon context, instead of the location of the sitemap it's found in. This is a mistake, IMO: a real block should *NOT* contain any information about where it has been mounted and this behavior requires it to do so, preventing the block to be mounted somewhere else transparently. Is there any need for this behavior that I didn't consider? I will check the lib problem. If it behaves as you state, this is clearly a bug. I've been using the per-classpath feature extensively lately, but without additional libs (just a class-dir), and it works like a charm. What a productivity boost! Here's my classpath declaration : map:classpath class-dir src=BLOCK-INF/classes/ /map:classpath IMO the name eclipse should not appear, as the contents of the classes dir can be generated equally by saving your file in Eclipse or running an Ant build (I use both). My sample was the first layout I used, but I quickly changed to self-contained mini-apps as you describe. I think in a near future we'll have a src-dir configuration as well using the compiling classloader. Also, I don't use symlinks in build/webapp that can be destroyed by a build clean, but use the mount-table matcher. Copy mount-table.xml.sample in the main Cocoon dir to mount-table.xml and mount your external mini-apps there. The only thing missing is the automatic reload of classes (you still need to touch the sitemap, which I sometimes forget), but other than this minor annoyance, what a pleasure! Sylvain -- Sylvain WallezAnyware Technologies http://apache.org/~sylvainhttp://anyware-tech.com Apache Software Foundation Member Research Technology Director
