Re: Happy New Year!, Re: Merry Christmas
Vadim Gritsenko wrote: Time to change subject. Happy New Year, everybody! Now's the time (at least here): Happy New Year to the whole Cocoon community! May 2006 finally bring us the long awaited 2.2 and much more! Sylvain -- Sylvain WallezAnyware Technologies http://bluxte.net http://www.anyware-tech.com Apache Software Foundation Member Research & Technology Director
Re: Cocoon 2.1.7 hang
OK. I ran some basic tests on one of my machines. Just for basic info it is a P4 2.5 GHz with 1 GB of memory running RHEL 3. The only thing I did was set up JMeter to login to the portal as user cocoon. In all the tests the computer was maxed at 100% cpu. Before the change: 5 threads login repeated 10 times: Avg 3.4 seconds, Max 27 seconds. 10 threads login repeaded 5 times: Avg 6.760 seconds, Max 22 seconds After the change: 5 threads login repeated 10 times: Avg 1.3 seconds, Max 2.6 seconds 5 threads login repeated 20 times: Avg 1.2 seconds, Max 2.5 seconds 10 threads login repeated 5 times: Avg 2.4 seconds, Max 10 seconds. 10 threads login repeated 10 times: Avg 2.1 seconds, Max 13 seconds. The change has been checked into 2.1. I'll test it on 2.2 and check it in also. Ralph Carsten Ziegeler wrote: Castor seems to have a lot of useful little "hacks" - I just found out, that we can prevent castor from checking for default constructors which I really needed for 2.2 - it's there, you only have to find out how to configure it :). Im curious how the matches configuration looks like :) Carsten Ralph Goers wrote: OK. I figured out how to use the matches attribute and was able to verify that it doesn't throw ClassNotFoundExceptions all the time. I'll do a little load testing next to see what kind of difference it makes on throughput.
Re: svn commit: r360290 - in /cocoon/trunk/src/java/org/apache/cocoon: components/modules/output/SessionAttributeOutputModule.java xml/dom/DOMStreamer.java
Carsten Ziegeler wrote:
[EMAIL PROTECTED] schrieb:
Author: antonio
Date: Sat Dec 31 07:22:11 2005
New Revision: 360290
URL: http://svn.apache.org/viewcvs?rev=360290&view=rev
Log:
Compares Strings using equals()
Modified:
cocoon/trunk/src/java/org/apache/cocoon/components/modules/output/SessionAttributeOutputModule.java
cocoon/trunk/src/java/org/apache/cocoon/xml/dom/DOMStreamer.java
-String declname = (prefix == "") ? "xmlns" : "xmlns:" + prefix;
+String declname = (prefix.equals("")) ? "xmlns" : "xmlns:" +
prefix;
I think testing string length against zero is a better way.
OK. :-)
Best Regards,
Antonio Gallardo
Re: svn commit: r360290 - in /cocoon/trunk/src/java/org/apache/cocoon: components/modules/output/SessionAttributeOutputModule.java xml/dom/DOMStreamer.java
[EMAIL PROTECTED] schrieb:
> Author: antonio
> Date: Sat Dec 31 07:22:11 2005
> New Revision: 360290
>
> URL: http://svn.apache.org/viewcvs?rev=360290&view=rev
> Log:
> Compares Strings using equals()
>
> Modified:
>
> cocoon/trunk/src/java/org/apache/cocoon/components/modules/output/SessionAttributeOutputModule.java
> cocoon/trunk/src/java/org/apache/cocoon/xml/dom/DOMStreamer.java
>
> -String declname = (prefix == "") ? "xmlns" : "xmlns:" +
> prefix;
> +String declname = (prefix.equals("")) ? "xmlns" : "xmlns:" +
> prefix;
I think testing string length against zero is a better way.
Carsten
--
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
Re: cocoon.zones down
Le 31 déc. 05, à 16:54, Antonio Gallardo a écrit : ...Samples site for trunk and 21branch are down... Seems like both SVN codebases are broken ATM. For the trunk, changes in cocoon.sh don't seem to work on the zone (it's Solaris), see http://cocoon.zones.apache.org/logs/cocoon-demos/trunk/stderr.log And for the 2.1 branch it's the (already reported here) webdav block problem, see http://cocoon.zones.apache.org/logs/cocoon-demos/21branch/stdout.log -Bertrand smime.p7s Description: S/MIME cryptographic signature
cocoon.zones down
Hi: Samples site for trunk and 21branch are down. Best Regards, Antonio Gallardo
Re: [RT] Simplifying component handling
> On 30.12.2005 19:09, Carsten Ziegeler wrote:
> > Way too much code me thinks. So what about:
> >
> > class MyComponent implements SOMETHING, ThreadSafe {
> > protected final ClassA compA;
> > protected final ClassB compB;
> >
> > public MyComponent(ClassA a, ClassB b) {
> > compA = a;
> > compB = b;
> > }
> > }
I've tried this (with Jakarta Commons Attributes) and the end result
can be summarized as "it is barely worth it" in terms of added
complexity and behind-the-scenes magic. Technically it is a huge
success. But the price you pay is that it makes the code that much
more non-standard.
This is also for a closed code base that has a fixed team of a few
developers. For open source, having additional magic would probably be
even more expensive in terms of complexity, initial threshold for
developers, and embeddability.
(Regarding the lower embeddability: This is my main problem with
Commons Logging. It has magic all right - just not the right magic!)
For Cocoon, I'd recommend against it. So what if the code is a little
bit bigger, if it means that it can actually be understood without
knowing a hundred additional, Cocoon-specific contracts up front.
/LS
Re: [RT] Simplifying component handling
Niclas Hedhman wrote:
> On Saturday 31 December 2005 02:09, Carsten Ziegeler wrote:
>
>>My final idea is to use even more magic (but it might be too much magic?):
>>
>>class MyComponent implements SOMETHING {
>> protected final ClassA component_A;
>> protected final ClassB component_B;
>>}
>
>
> Yipee, yet another thread on a new container architecture. Can't wait to see
> the hours of debate leading up to "no change"...
>
Exactly.
> Honestly guys, I'm starting to think that Cocoon won't manage to do the
> separation from Avalon, purely due to the number of ways to do it exceeds the
> number of strong-willed people in the community, and disagreements of what is
> the best move.
Too true :( And this all is not just about the "separation from Avalon".
Sigh
>
>
> Time for me to close the shop, and start with something more exciting.
Sounds like a good plan! If you found something, let me know!
Carsten
--
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
Re: [RT] Simplifying component handling
Joerg Heinicke wrote:
> On 30.12.2005 19:09, Carsten Ziegeler wrote:
>
>
>>class MyComponent implements SOMETHING, ThreadSafe, Disposable,
>>Serviceable {
>>protected ClassA compA;
>>protected ClassB compB;
>>protected ServiceManager m;
>>
>>public void service(ServiceManager m) {
>> this.m = m;
>> compA = (ClassA)m.lookup(ClassA.ROLE);
>> compB = (ClassB)m.lookup(ClassB.ROLE);
>>}
>>public void dispose() {
>> if ( m != null ) {
>>m.release(compA);
>>m.release(compB);
>> }
>>}
>>
>>Way too much code me thinks. So what about:
>>
>>class MyComponent implements SOMETHING, ThreadSafe {
>> protected final ClassA compA;
>> protected final ClassB compB;
>>
>> public MyComponent(ClassA a, ClassB b) {
>>compA = a;
>>compB = b;
>> }
>>}
>>
>>We could simply add constructor injection: if the implementation does
>>not provide a default constructor, the available constructor is called
>>using reflection and the components are injected on construction of the
>>object - no need to configure something in any xml configuration file.
>>Implementing this is easy - I did this already years ago for Fortress.
>
>
> What's the contract for the auto-wiring? Just assuming ClassA and ClassB
> have public static fields called ROLE? Sounds somewhat "strange".
>
No, the contract would be to search for a component which is registered
using the ClassA as the role name. Actually ClassA and ClassB are two
interfaces.
Carsten
--
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
Re: JavaScriptHelper fails to compile in 2.1
Ralph Goers wrote: > cocoon-block-forms-compile: > Compiling 7 source files to > C:\cocoon\BRANCH_2_1_X\build\cocoon\blocks\forms\dest > C:\cocoon\BRANCH_2_1_X\src\blocks\forms\java\org\apache\cocoon\forms\util\JavaScriptHelper.java:60: > > compileReader(org.mozilla.javascript.Scriptable,java.io.Reader,java.lang.String,int,java.lang.Object) > > in org.mozilla.javascript.Context cannot be applied to > (java.io.StringReader,java.lang.String,int,) > script = ctx.compileReader( > ^ > 1 error > Ups, sorry my mistake - I forgot that we are using the same source for both branches and of course we are using a different rhino version. Thanks for fixing this, Ralph Carsten -- Carsten Ziegeler - Open Source Group, S&N AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: Handling of status file - added to Daisy
Carsten Ziegeler wrote: Just as reminder: a) please add all changes to a status.xml (of course there are exceptions like fixing typos etc.) b) Starting with 2.2 we have separate status files for each block, so if you're changing something in a block, add it to the status.xml of that block and not in the global status.xml. c) If you're adding something to both, 2.1.x and 2.2, add the change to the status.xml of 2.1 only - all the status files in the 2.2 repository contain only changes from 2.1.x to 2.2. I've added this info to a Daisy page: http://cocoon.zones.apache.org/daisy/documentation/g2/793.html If there are other "rules of thumb" or "do not forget to do this" snippets of info, add them there. BTW if there is another page that is more appropriate, move the content there. Bye, Helma
Re: [RT] Simplifying component handling
On 30.12.2005 19:09, Carsten Ziegeler wrote:
class MyComponent implements SOMETHING, ThreadSafe, Disposable,
Serviceable {
protected ClassA compA;
protected ClassB compB;
protected ServiceManager m;
public void service(ServiceManager m) {
this.m = m;
compA = (ClassA)m.lookup(ClassA.ROLE);
compB = (ClassB)m.lookup(ClassB.ROLE);
}
public void dispose() {
if ( m != null ) {
m.release(compA);
m.release(compB);
}
}
Way too much code me thinks. So what about:
class MyComponent implements SOMETHING, ThreadSafe {
protected final ClassA compA;
protected final ClassB compB;
public MyComponent(ClassA a, ClassB b) {
compA = a;
compB = b;
}
}
We could simply add constructor injection: if the implementation does
not provide a default constructor, the available constructor is called
using reflection and the components are injected on construction of the
object - no need to configure something in any xml configuration file.
Implementing this is easy - I did this already years ago for Fortress.
What's the contract for the auto-wiring? Just assuming ClassA and ClassB
have public static fields called ROLE? Sounds somewhat "strange".
Jörg
webdav block broken in 2.1 branch.
Hi: I just updated from the SVN. I tried to make a full build. I got: cocoon-block-webdav-compile: Compiling 10 source files to /home/agallardo/svn/cocoon-2.1/build/cocoon/blocks/webdav/dest /home/agallardo/svn/cocoon-2.1/src/blocks/webdav/java/org/apache/cocoon/components/source/impl/WebDAVSource.java:596: cannot resolve symbol symbol : method newWebDAVSource (org.apache.webdav.lib.WebdavResource,org.apache.commons.httpclient.HttpURL,java.lang.String,org.apache.avalon.framework.logger.Logger) location: class org.apache.cocoon.components.source.impl.WebDAVSource WebDAVSource src = WebDAVSource.newWebDAVSource(resources[i], ^ 1 error Best Regards, Antonio Gallardo.
