Sylvain Wallez skrev:
Daniel Fagerstrom wrote:
Summarizing my opinions: Users should be able to use any container.
... but we should have one usable out of the box for users that don't
want or don't know how to make a choice.
Absolutely. In the long run I think that the OSGi declarative
My only fear with this whole discussion is that we are once again going
to lose focus on finishing 2.2.
Ralph
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Wed, 4 Jan 2006, Carsten Ziegeler wrote:
Date: Wed, 04 Jan 2006 12:36:19 +0100
From: Carsten Ziegeler <[EMAIL PROTECTED]>
Reply-To: dev@cocoon.apache.org
To: dev@cocoon.apache.org
Subject: Re: [RT] Simplifying component handling
Sylvain
Daniel Fagerstrom wrote:
Summarizing my opinions: Users should be able to use any container.
... but we should have one usable out of the box for users that don't
want or don't know how to make a choice.
Blocks and a more fine grained modularization of the core gives the
possiblity to mig
Carsten Ziegeler wrote:
Sylvain Wallez wrote:
Guys, remember the real-blocks container story? Two reasons led to the
choice of OSGi: there are existing implementations, and it stopped the
endless discussions about what the container API should be.
We have exactly the same here. "why not th
Le 4 janv. 06, à 12:36, Carsten Ziegeler a écrit :
...Yes, so why not throwing ECM++ away and use an existing container?
We
can provide an Avalon compatibility bridge for nearly any existing
container...
I was thinking about this after reading the replies this morning,
sounds like an ideal so
Sylvain Wallez wrote:
> Guys, remember the real-blocks container story? Two reasons led to the
> choice of OSGi: there are existing implementations, and it stopped the
> endless discussions about what the container API should be.
>
> We have exactly the same here. "why not this or that" and "I d
Sylvain Wallez wrote:
>
> Carsten, what's wrong with the Spring bridge?
>
See my reply from today.
Carsten
--
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
Sylvain Wallez wrote:
...
Guys, remember the real-blocks container story? Two reasons led to the
choice of OSGi: there are existing implementations, and it stopped the
endless discussions about what the container API should be.
We have exactly the same here. "why not this or that" and "I don'
Wow, a long and fun thread ;)
Seem like most want to migrate away from the Avalon interfaces for
component handling and that some (I'm included), in the long term, want
to move away even from ECM++. IMO, with all communities that specializes
on containers, building containers should be outside th
Carsten Ziegeler wrote:
Vadim Gritsenko wrote:
Carsten Ziegeler wrote:
So I'm coming back to my idea, is anyone against adding constructor
injection to ECM++ or at least make it pluggable so I can add it for my
own projects? The change adds only a feature while maintaining 100%
compatib
Sylvain Wallez wrote:
> I asked Carsten why he doesn't want to use the bridge that _he_ wrote,
> and would love to have his answer. Carsten?
>
Now all this comparing of the things Apple did with our situation is
missing imho a big difference: Apple decided that their next OS (MacOS
X) should have
Vadim Gritsenko wrote:
> Carsten Ziegeler wrote:
>
>>So I'm coming back to my idea, is anyone against adding constructor
>>injection to ECM++ or at least make it pluggable so I can add it for my
>>own projects? The change adds only a feature while maintaining 100%
>>compatibility.
>
>
> Why not
Giacomo Pati wrote:
On Tue, 3 Jan 2006, Sylvain Wallez wrote:
Right. And the simplest and most consistent step to go forward is IMO
to just use what's already there, providing a nice bridge to a
rock-solid container used by thousands of people.
If you mean Spring as the "rock-solid container
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Tue, 3 Jan 2006, Sylvain Wallez wrote:
Right. And the simplest and most consistent step to go forward is IMO to just
use what's already there, providing a nice bridge to a rock-solid container
used by thousands of people.
If you mean Spring as
Carsten Ziegeler wrote:
So I'm coming back to my idea, is anyone against adding constructor
injection to ECM++ or at least make it pluggable so I can add it for my
own projects? The change adds only a feature while maintaining 100%
compatibility.
Why not setter injection?
Vadim
On Jan 3, 2006, at 9:06 AM, Peter Hunsberger wrote:
On 1/3/06, Giacomo Pati <[EMAIL PROTECTED]> wrote:
I'm with Sylvain's and Gianugo's oppinion. I also see users getting
confused with multiple choices of "how to write a component". I'd
say in
this area we need a revolution instead of an e
On 1/3/06, Giacomo Pati <[EMAIL PROTECTED]> wrote:
>
> I'm with Sylvain's and Gianugo's oppinion. I also see users getting
> confused with multiple choices of "how to write a component". I'd say in
> this area we need a revolution instead of an evolution.
I really don't get this objection; if I se
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Tue, 3 Jan 2006, Carsten Ziegeler wrote:
Date: Tue, 03 Jan 2006 11:49:32 +0100
From: Carsten Ziegeler <[EMAIL PROTECTED]>
Reply-To: dev@cocoon.apache.org
To: dev@cocoon.apache.org
Subject: Re: [RT] Simplifying component handling
Giacom
Giacomo Pati wrote:
I'm with Sylvain's and Gianugo's opinion. I also see users getting
confused with multiple choices of "how to write a component". I'd say
in this area we need a revolution instead of an evolution.
Moving to POJOs doesn't need a revolution. We already have the bridge.
Maybe
Giacomo Pati wrote:
>
> I'm with Sylvain's and Gianugo's oppinion. I also see users getting
> confused with multiple choices of "how to write a component".
I personally don't see a problem *if* we tell them how to do it right.
Perhaps I'm wrong, don't know.
> I'd say in this area we need a revol
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Tue, 3 Jan 2006, Sylvain Wallez wrote:
Date: Tue, 03 Jan 2006 10:13:33 +0100
From: Sylvain Wallez <[EMAIL PROTECTED]>
Reply-To: dev@cocoon.apache.org
To: dev@cocoon.apache.org
Subject: Re: [RT] Simplifying component handling
Carsten Zi
Carsten Ziegeler wrote:
Sorry, but I don't comment on this. Just one (final) question: are you -1 on
the changes?
Yes, -1 because:
- the mixed model will bring confusion,
- having yet another Cocoon-specific way of handling components just
makes the learning curve steeper,
- the number of
Sorry, but I don't comment on this. Just one (final) question: are you
-1 on the changes?
Carsten
Sylvain Wallez wrote:
> Carsten Ziegeler wrote:
>
>>Hmm, so why is ECM++ different from ECM (includes, JMX etc.)? With the
>>same argument we could just use ECM with the container integrations and
>
Carsten Ziegeler wrote:
Hmm, so why is ECM++ different from ECM (includes, JMX etc.)? With the
same argument we could just use ECM with the container integrations and
that's it.
Oh yes, sure! And why not going back to the Director interface of the
good old Cocoon 1.0 times?
Seriously, ECM
Addressing both, Sylvain's and Gianugo's response (at least partially):
Gianugo Rabellino wrote:
>
> It's not so easy. First let me state that I don't have any particular
> blocker if all we're talking about is adding constructor injection to
> ECM++: whatever goes in the direction of a lighter an
Carsten Ziegeler wrote:
So I'm coming back to my idea, is anyone against adding constructor
injection to ECM++ or at least make it pluggable so I can add it for my
own projects? The change adds only a feature while maintaining 100%
compatibility.
I have strong reservations about components
On 1/3/06, Upayavira <[EMAIL PROTECTED]> wrote:
> Reinhard Poetz wrote:
> > --- Carsten Ziegeler <[EMAIL PROTECTED]> schrieb:
> >>Gianugo Rabellino wrote:
> >>
> >>Yeah, and I really don't understand this - I (and
> >>others) propose small
> >>but simple steps to a) improve using Cocoon and b)
> >>
Reinhard Poetz wrote:
> --- Carsten Ziegeler <[EMAIL PROTECTED]> schrieb:
>
>
>>Gianugo Rabellino wrote:
>>
>>>On 1/2/06, Ralph Goers
>>
>><[EMAIL PROTECTED]> wrote:
>>
That seems to be a catch-22. How do you move away
>>
>>from Avalon without
>>
making these kind of changes?
>>>
>>Good
--- Carsten Ziegeler <[EMAIL PROTECTED]> schrieb:
> Gianugo Rabellino wrote:
> > On 1/2/06, Ralph Goers
> <[EMAIL PROTECTED]> wrote:
> >
> >>That seems to be a catch-22. How do you move away
> from Avalon without
> >>making these kind of changes?
> >
> Good question - I think noone is able to
Le 3 janv. 06, à 08:11, Carsten Ziegeler a écrit :
...So I'm coming back to my idea, is anyone against adding constructor
injection to ECM++ or at least make it pluggable so I can add it for my
own projects? The change adds only a feature while maintaining 100%
compatibility...
I'm +1 on this
Gianugo Rabellino wrote:
> On 1/2/06, Ralph Goers <[EMAIL PROTECTED]> wrote:
>
>>That seems to be a catch-22. How do you move away from Avalon without
>>making these kind of changes?
>
Good question - I think noone is able to answer that one.
>
> Honestly, I don't see how anything in the 2.x s
On Dec 30, 2005, at 4:05 PM, Berin Loritsch wrote:
Seriously, I agree that writing less code is good, but not at the
price of too black magic implying weaker contracts.
Agreed. To achieve the goal of less code would require major
overhauls of the entire system.
Yes. I think Cocoon co
This thread got me thinking about alternatives to dependency
injection. The only credible alternative I can think of for Cocoon is
a Service Locator. One of the things I liked about Avalon was its
combination of dependency injection and service locator. This
combination made sense for a gen
On 1/2/06, Ralph Goers <[EMAIL PROTECTED]> wrote:
> That seems to be a catch-22. How do you move away from Avalon without
> making these kind of changes?
Honestly, I don't see how anything in the 2.x series could move away
from Avalon. Too much refactoring needed, too many issues on the
table.
C
That seems to be a catch-22. How do you move away from Avalon without
making these kind of changes?
Carsten Ziegeler wrote:
But as we can't get any consensus on any changes, I think we should
drop the topic and wait until we have moved away from Avalon completly.
Carsten
Max Pfingsthorn wrote:
> ...
>
>>>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 ro
...
> > 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 Clas
> 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;
>
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;
>>}
>
>
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;
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);
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 n
On Saturday 31 December 2005 11:47, Berin Loritsch wrote:
> Also note that Pico can work with setter injection
> as well as constructor injection
So does Spring.
Cheers
Niclas
Torsten Curdt wrote:
On 30.12.2005, at 20:21, Vadim Gritsenko wrote:
Carsten Ziegeler wrote:
Gianugo Rabellino wrote:
I'm definitely not a fan of constructor injection, exp. when we
consider how (way too) often we resorted to inheritance in Cocoon
components. Now, while interface injectio
On 30.12.2005, at 20:21, Vadim Gritsenko wrote:
Carsten Ziegeler wrote:
Gianugo Rabellino wrote:
I'm definitely not a fan of constructor injection, exp. when we
consider how (way too) often we resorted to inheritance in Cocoon
components. Now, while interface injection is clearly out of
fas
On Dec 30, 2005, at 12:09 PM, Carsten Ziegeler wrote:
Aren't you tired of implementing a service/dispose combo for each of
your components over and over again? Now, actually, I am. Big time.
If you look at several of our components, they do something like this:
class MyComponent implements SO
Sylvain Wallez wrote:
But I think it can even get easier:
1. Let's just assume that every component is ThreadSafe - unless
otherwise stated - no need to declare the interface anymore. I think
apart from the interpreter most components are threadsafe or poolable
anyway.
This is a huge chan
Giacomo Pati wrote:
I'm almost sure that Cocoon 2.2 will stay 1.4 compatible for another
year at least. So an approach with Xdoclet or qdox (see Maven2's
Mojo's) will be the only way to go ATM.
Have a look at http://retrotranslator.sourceforge.net/
Real JDK 1.5 annotations (and more) with JD
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Fri, 30 Dec 2005, Vadim Gritsenko wrote:
Date: Fri, 30 Dec 2005 15:06:34 -0500
From: Vadim Gritsenko <[EMAIL PROTECTED]>
Reply-To: dev@cocoon.apache.org
To: dev@cocoon.apache.org
Subject: Re: [RT] Simplifying component handling
Giacom
On 12/30/05, Giacomo Pati <[EMAIL PROTECTED]> wrote:
> On Fri, 30 Dec 2005, Vadim Gritsenko wrote:
> > Carsten Ziegeler wrote:
> >> Gianugo Rabellino wrote:
> >> > I'm definitely not a fan of constructor injection, exp. when we
> >> > consider how (way too) often we resorted to inheritance in Co
Giacomo Pati wrote:
On Fri, 30 Dec 2005, Vadim Gritsenko wrote:
Carsten Ziegeler wrote:
Gianugo Rabellino wrote:
> I'm definitely not a fan of constructor injection, exp. when we
> consider how (way too) often we resorted to inheritance in Cocoon
> components. Now, while interface injecti
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Fri, 30 Dec 2005, Vadim Gritsenko wrote:
Date: Fri, 30 Dec 2005 14:21:07 -0500
From: Vadim Gritsenko <[EMAIL PROTECTED]>
Reply-To: dev@cocoon.apache.org
To: dev@cocoon.apache.org
Subject: Re: [RT] Simplifying component handling
Carsten Zi
Carsten Ziegeler wrote:
Gianugo Rabellino wrote:
I'm definitely not a fan of constructor injection, exp. when we
consider how (way too) often we resorted to inheritance in Cocoon
components. Now, while interface injection is clearly out of fashion,
sticking with Avalon/Excalibur also means that
Ralph Goers wrote:
Sylvain Wallez wrote:
This is a huge change compared to the current behaviour, where no
interface means not threadsafe and not reusable. IMO, this change can
only happen if we completely move away from Avalon.
Isn't that the direction we are headed anyway?
Yes, of course
Gianugo Rabellino wrote:
>
> I'm definitely not a fan of constructor injection, exp. when we
> consider how (way too) often we resorted to inheritance in Cocoon
> components. Now, while interface injection is clearly out of fashion,
> sticking with Avalon/Excalibur also means that it would be diff
Gianugo Rabellino wrote:
I'm also still not completely sold on factories. Indeed, they work and
they're a brilliant solution, but am I the only one smelling hack and
workaround?
I didn't like this when I first saw it either. My thought was to have
the Generator, etc. be thread safe and have
Sylvain Wallez wrote:
This is a huge change compared to the current behaviour, where no
interface means not threadsafe and not reusable. IMO, this change can
only happen if we completely move away from Avalon.
Isn't that the direction we are headed anyway?
Sylvain Wallez wrote:
>>public void dispose() {
>> if ( m != null ) {
>>m.release(compA);
>>m.release(compB);
>> }
>>}
>>
>
>
> The test "m != null" is useless, as dispose should never be called
> twice. Removes 2 lines :-)
>
No, it is not useless - if some exception happens during
+ 1 with comments below
Carsten Ziegeler wrote:
Aren't you tired of implementing a service/dispose combo for each of
your components over and over again? Now, actually, I am. Big time.
If you look at several of our components, they do something like this:
class MyComponent implements SOMETHIN
On 12/30/05, Carsten Ziegeler <[EMAIL PROTECTED]> wrote:
> Aren't you tired of implementing a service/dispose combo for each of
> your components over and over again? Now, actually, I am. Big time.
>
>
> Way too much code me thinks. So what about:
>
> class MyComponent implements SOMETHING, Thread
Carsten Ziegeler wrote:
Aren't you tired of implementing a service/dispose combo for each of
your components over and over again? Now, actually, I am. Big time.
If you look at several of our components, they do something like this:
class MyComponent implements SOMETHING, ThreadSafe, Disposable,
Aren't you tired of implementing a service/dispose combo for each of
your components over and over again? Now, actually, I am. Big time.
If you look at several of our components, they do something like this:
class MyComponent implements SOMETHING, ThreadSafe, Disposable,
Serviceable {
protected C
63 matches
Mail list logo
