You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Paul Hammant <pa...@yahoo.com> on 2003/06/23 13:57:04 UTC
exCornerstone components.
Folks,
Would anyone mind if I added PicoContainer compatability to the ConnectionManager, ThreadManager
etc components formerly known as Cornerstone?
The comps would not lose Avalon-Framework compatability. Nothing about usage would change. There
would be no imports on external to Apache libraries. It might at a few K to the jar size, but that
is about it. I categorise this as completely harmless.
Thoughts?
- Paul
________________________________________________________________________
Want to chat instantly with your online friends? Get the FREE Yahoo!
Messenger http://uk.messenger.yahoo.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: exCornerstone components.
Posted by Paul Hammant <pa...@yahoo.com>.
Yeah, I forgot the that it was in a new repo that is not sandbox.
- Paul
--- Stephen McConnell <mc...@apache.org> wrote: >
>
> Paul Hammant wrote:
>
> >Folks,
> >
> >Would anyone mind if I added PicoContainer compatability to the ConnectionManager,
> ThreadManager
> >etc components formerly known as Cornerstone?
> >
> >The comps would not lose Avalon-Framework compatability. Nothing about usage would change.
> There
> >would be no imports on external to Apache libraries. It might at a few K to the jar size, but
> that
> >is about it. I categorise this as completely harmless.
> >
>
> Paul:
>
> I don't like the idea of doing this in the avalon-components repository
> but I would not object to seeing content added in sandbox. This would
> give everyone a better chance to understand the implications.
>
> Cheers, Steve.
>
> --
>
> Stephen J. McConnell
> mailto:mcconnell@apache.org
> http://www.osm.net
>
> Sent via James running under Merlin as an NT service.
> http://avalon.apache.org/sandbox/merlin
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
> For additional commands, e-mail: dev-help@avalon.apache.org
>
________________________________________________________________________
Want to chat instantly with your online friends? Get the FREE Yahoo!
Messenger http://uk.messenger.yahoo.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: exCornerstone components.
Posted by Stephen McConnell <mc...@apache.org>.
Paul Hammant wrote:
>Folks,
>
>Would anyone mind if I added PicoContainer compatability to the ConnectionManager, ThreadManager
>etc components formerly known as Cornerstone?
>
>The comps would not lose Avalon-Framework compatability. Nothing about usage would change. There
>would be no imports on external to Apache libraries. It might at a few K to the jar size, but that
>is about it. I categorise this as completely harmless.
>
Paul:
I don't like the idea of doing this in the avalon-components repository
but I would not object to seeing content added in sandbox. This would
give everyone a better chance to understand the implications.
Cheers, Steve.
--
Stephen J. McConnell
mailto:mcconnell@apache.org
http://www.osm.net
Sent via James running under Merlin as an NT service.
http://avalon.apache.org/sandbox/merlin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: exCornerstone components.
Posted by Leo Simons <le...@apache.org>.
Paul Hammant wrote:
>>> like the idea, but some reservations :D
>>
>> I'm reversing direction completely.
>
> I'm likely to reverse myself dude. I don't have the time to bite into
> another chore.
the whole idea with open source is that the source might continue to
live when a developer moves on, innit? :D
Anyways, you know me for sometimes reversing direction several times in
a day, don't you?
I think what's actually the key with pico is that you make it real easy
to remove the "new" keyword even for the simplest of beans (ie, of the
size where the import org.apache.{blah} statements would otherwise take
up a significant part of the sourcefile), and that makes it easy to do
simple proxy-based AOP even for the simplest of beans, and boy, does
that have potential. Pico on its own is not nor should be a complete
replacement for avalon, but it sure is a candidate for managing the
ComponentHandler beans that live in fortress (for example).
the actual syntax and type safety doesn't matter to me as much as how
much shorter and simpler your component sourcefile becomes as a result.
You can work with Pico 5 mins after you learn java.
> I've dropped the ball on a number of Avalon related things. For example
> Sevak. It needs a little attention, and I should help finish it off.
you mean "finish it off" as in "finish it", I hope?
> Please also be aware (folks) that PicoContainer is a place that PeterD
> hangs out. As you know I continue to be a friend to him. Pico embraces
> the multi-container design, that we no longer allow here. If you like a
> reborn Lowest Common Denominator (LCD) and multiple visions of component
> compatible (but potentially competing and divergent) containers. That
> said all my friends here are welcome there. We are not going to reopen
> old wounds though. It is also trying to be an XP project. Simplest
> thing, TDD et al.
PicoContainer is forming to be a neat project, and from what I've seen
by looking at the mail archives a cool group of people surrounds it. I
like the atmosphere of TDD. Doesn't mean I'm planning to get involved; I
have unfortunately no time nor energy to be a responsible member of
another OSS project 8-).......whether or not a long-lasting community
forms around it (lets hope so), those ideas really do have merit on
their own (and don't you dare convince me otherwise for the next 24
hours at least!).
> Death to Static! Long live IoC!! (what we all have in common)
and with that, goodnight to y'all!
cheers,
- Leo
PS: only 331 unread messages left on dev@avalon ;)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: exCornerstone components.
Posted by Paul Hammant <Pa...@ThoughtWorks.net>.
Leo,
>>
>> like the idea, but some reservations :D
>
>
> I'm reversing direction completely. A little bit of experimentation
> over the holidays (yes I'm an addict) has shown me that "type III IoC"
> is, in fact, one of the best ideas of 2003 I've seen so far. I hope to
> write and donate to picocontainer an essay lining out why, but in the
> meantime I'd just want to point out to y'all my reservations are
> henceforth lifted.
I'm likely to reverse myself dude. I don't have the time to bite into
another chore. Thoughtworks is giving me lots to do, inside and outside
of client hours.
I've dropped the ball on a number of Avalon related things. For example
Sevak. It needs a little attention, and I should help finish it off.
Please also be aware (folks) that PicoContainer is a place that PeterD
hangs out. As you know I continue to be a friend to him. Pico embraces
the multi-container design, that we no longer allow here. If you like a
reborn Lowest Common Denominator (LCD) and multiple visions of component
compatible (but potentially competing and divergent) containers. That
said all my friends here are welcome there. We are not going to reopen
old wounds though. It is also trying to be an XP project. Simplest
thing, TDD et al.
Death to Static! Long live IoC!! (what we all have in common)
- Paul
--
http://www.thoughtworks.com -> The art of heavy lifting.
Home for many Agile practicing, Open Source activists...
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: exCornerstone components.
Posted by Leo Simons <le...@apache.org>.
J Aaron Farr wrote:
> Correct me if I'm wrong, but type III is defined by the servicing of
> components via the constructor, right?
yep.
> I'm interested in PicoContainer, but I'm not completely convinced it's
> better for all cases.
definately not for all cases. It is a lot simpler for the simple cases.
Consider building a more full-featured container out of pico-hosted
beans, for example. Or consider preaching the benefits of COP to fresh
CompSci students. Even the 14-year-old brother of a friend of mine (who
knows PHP and is learning java) gets it.
just IMVHO for now.
cheers,
- Leo
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: exCornerstone components.
Posted by J Aaron Farr <fa...@apache.org>.
On Sun, 2003-07-27 at 17:53, Leo Simons wrote:
> Leo Simons wrote:
> > Paul Hammant wrote:
> >
> >> Would anyone mind if I added PicoContainer compatability to the
> >> ConnectionManager, ThreadManager
> >> etc components formerly known as Cornerstone?
> >
> <snip/>
> >
> >> Thoughts?
> >
> > like the idea, but some reservations :D
>
> I'm reversing direction completely. A little bit of experimentation over
> the holidays (yes I'm an addict) has shown me that "type III IoC" is, in
> fact, one of the best ideas of 2003 I've seen so far. I hope to write
> and donate to picocontainer an essay lining out why, but in the meantime
> I'd just want to point out to y'all my reservations are henceforth lifted.
>
Correct me if I'm wrong, but type III is defined by the servicing of
components via the constructor, right?
I'm interested in PicoContainer, but I'm not completely convinced it's
better for all cases. I'll be watching for your essay.
--
jaaron <http://jadetower.org>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: exCornerstone components.
Posted by Leo Simons <le...@apache.org>.
Leo Simons wrote:
> Paul Hammant wrote:
>
>> Would anyone mind if I added PicoContainer compatability to the
>> ConnectionManager, ThreadManager
>> etc components formerly known as Cornerstone?
>
<snip/>
>
>> Thoughts?
>
> like the idea, but some reservations :D
I'm reversing direction completely. A little bit of experimentation over
the holidays (yes I'm an addict) has shown me that "type III IoC" is, in
fact, one of the best ideas of 2003 I've seen so far. I hope to write
and donate to picocontainer an essay lining out why, but in the meantime
I'd just want to point out to y'all my reservations are henceforth lifted.
:D
cheers!
- Leo
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: exCornerstone components.
Posted by Paul Hammant <Pa...@yahoo.com>.
Anton,
Welcome.
>1) it surely makes sense to automate this
> (but, maybe we shall do that tomorrow and
> use hand-craft today? :-)
>
>2) if this is a separate class, should we packages it
> * in the main jar
> * in an additional jar
> if we choose additional, then we shall save even those
> tiny kb that would otherwise be added
>
>
It would be a lot easier to just put the new classes in the same jars as
the impls :-) We've done some poking and it is very easy to make these
classes.
>>>I don't think you need to worry about Avalon users using the constructor directly.
>>>
>>>
>
>LS> my thought was about people that use neither pico nor avalon but just
>LS> need a reusable bean. One of the good things about pico is that you're
>LS> also making that a real possibility, innit?
>
>Truly speaking, I think it going to be great!
>Probably we're approaching one step closer to the KISS idiom :)
>I think we all feel a fresh wind blowing from Pico :-)
>
>And the more inter-container compatibility the better :-))
>
>
Nope. The more inter-component compatbility the better :-) Components
are far more important IMHO.
It is only the components I see as shared between Pico/Nano containers
over at Codehaus and Avalon's various containers.
- Paul
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re[2]: exCornerstone components.
Posted by Anton Tagunov <at...@mail.cnt.ru>.
Hi, Leo, Paul and All!
LS> ConnectionManagerBean extends DefaultConnectionManager
LS> {
LS> public ConnectionManagerBean( /* ... stuff goes here ... */ )
LS> {
LS> super();
LS> /** ... stuff goes here ... */
LS> }
LS> }
LS> there would be the need for an added constructor in either an existing
LS> class or a new class, right? And that constructor would need to be
LS> changed whenever a dependency is added, right?
If Leo has caught the idea right, then
1) it surely makes sense to automate this
(but, maybe we shall do that tomorrow and
use hand-craft today? :-)
2) if this is a separate class, should we packages it
* in the main jar
* in an additional jar
if we choose additional, then we shall save even those
tiny kb that would otherwise be added
>> I don't think you need to worry about Avalon users using the constructor directly.
LS> my thought was about people that use neither pico nor avalon but just
LS> need a reusable bean. One of the good things about pico is that you're
LS> also making that a real possibility, innit?
Truly speaking, I think it going to be great!
Probably we're approaching one step closer to the KISS idiom :)
I think we all feel a fresh wind blowing from Pico :-)
And the more inter-container compatibility the better :-))
- Anton
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: exCornerstone components.
Posted by Leo Simons <le...@apache.org>.
Paul Hammant wrote:
> I think you worry too much.
probably :D. It is better to worry up front than complain in retrospect!
> There would be no use of the word Pico in the codebase of
> exCornerstone.
ah, I renamed half of my bad example to ***Bean already:
ConnectionManagerBean extends DefaultConnectionManager
{
public ConnectionManagerBean( /* ... stuff goes here ... */ )
{
super();
/** ... stuff goes here ... */
}
}
there would be the need for an added constructor in either an existing
class or a new class, right? And that constructor would need to be
changed whenever a dependency is added, right?
> I don't think you need to worry about Avalon users using the constructor directly.
my thought was about people that use neither pico nor avalon but just
need a reusable bean. One of the good things about pico is that you're
also making that a real possibility, innit?
> Pico users will have to just accept that there might be changes.
that's a bit of a policy change for how we currently try to do things
:D. Not saying that's neccessarily a bad thing here.
anyways, no -1 here, but no +1 yet either.
gotta run!
- LSD
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: exCornerstone components.
Posted by Paul Hammant <pa...@yahoo.com>.
Leo,
I think you worry too much. There would be no use of the word Pico in the codebase of
exCornerstone. PicoContainer does not need .xinfo, so no changes there.
"avalon-interop" not needed. There is no automanted tool in teh works. This will be a hand crafted
effort.
I don't think you need to worry about Avalon users using the constructor directly. Pico users will
have to just accept that there might be changes.
- Paul
--- Leo Simons <le...@apache.org> wrote: > Paul Hammant wrote:
> > Would anyone mind if I added PicoContainer compatability to the ConnectionManager,
> ThreadManager
> > etc components formerly known as Cornerstone?
>
> you mean addition of various classes like
>
> ConnectionManagerBean extends DefaultConnectionManager
> {
> public PicoConnectionManager( /* ... stuff goes here ... */ )
> {
> /** ... stuff goes here ... */
> }
> }
>
> right?
>
> No problem with that per se. I think its an elegant idea and providing
> some support for it would be nice, but there some potential issues to
> remove first. IIUC, adding a new dependendency to
> DefaultConnectionManager would mean that this ConnectionManagerBean its
> constructor would need to change too. Which means we should be willing
> to maintain it. Makes one wonder:
>
> - Who is going to maintain that? (only possible good answer: the same
> people that work on cornerstone)
>
> - Is it possible to automate this maintainance? If so... is it already
> implemented? Who will implement it? Where will that stuff live?
> (possible answer: there's a maven-pico-avalon-interop plugin that
> generates the class based on the @avalon.dependency attributes over at
> picocontainer.org)
>
> - Are we willing to track PicoContainer developments? (iow what is the
> vector of change for the constructor argument concept and is that
> acceptable to us)
>
> - What about backwards compatibility issues where people who just use
> this stuff as beans depend on the signature of the constructor? (this
> worries me the most. Adding a dependency might mean code changes to
> client code.)
>
> maybe it makes sense to do this on a branch first? I don't really feel
> like adding these classes, releasing, reconsidering, and then alienating
> users.
>
> > Thoughts?
>
> like the idea, but some reservations :D
>
> - LSD
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
> For additional commands, e-mail: dev-help@avalon.apache.org
>
________________________________________________________________________
Want to chat instantly with your online friends? Get the FREE Yahoo!
Messenger http://uk.messenger.yahoo.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: exCornerstone components.
Posted by Leo Simons <le...@apache.org>.
Paul Hammant wrote:
> Would anyone mind if I added PicoContainer compatability to the ConnectionManager, ThreadManager
> etc components formerly known as Cornerstone?
you mean addition of various classes like
ConnectionManagerBean extends DefaultConnectionManager
{
public PicoConnectionManager( /* ... stuff goes here ... */ )
{
/** ... stuff goes here ... */
}
}
right?
No problem with that per se. I think its an elegant idea and providing
some support for it would be nice, but there some potential issues to
remove first. IIUC, adding a new dependendency to
DefaultConnectionManager would mean that this ConnectionManagerBean its
constructor would need to change too. Which means we should be willing
to maintain it. Makes one wonder:
- Who is going to maintain that? (only possible good answer: the same
people that work on cornerstone)
- Is it possible to automate this maintainance? If so... is it already
implemented? Who will implement it? Where will that stuff live?
(possible answer: there's a maven-pico-avalon-interop plugin that
generates the class based on the @avalon.dependency attributes over at
picocontainer.org)
- Are we willing to track PicoContainer developments? (iow what is the
vector of change for the constructor argument concept and is that
acceptable to us)
- What about backwards compatibility issues where people who just use
this stuff as beans depend on the signature of the constructor? (this
worries me the most. Adding a dependency might mean code changes to
client code.)
maybe it makes sense to do this on a branch first? I don't really feel
like adding these classes, releasing, reconsidering, and then alienating
users.
> Thoughts?
like the idea, but some reservations :D
- LSD
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
RE: exCornerstone components.
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> From: Paul Hammant [mailto:paul_hammant@yahoo.com]
>
> > What would that mean? A new constructor?
>
> In a new class, yes. Nothing about the current API would change.
>
> > Instinctive -1 based on not wanting to incur promises to remain
> > compatible with non-Avalon containers...
>
> Reconsider? I'll not commti anything that breaks the design
> or use of exCornerstone :-)
OK, so it's subclassing + new constructor.
I'll retract the -1, but what I'd like is for that subclass to
be hosted with PicoContainer, not with exCornerstone. Much
like we handled the Log4J adapter for logging -> off to Log4J.
Let's see what others think.
/LS
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
RE: exCornerstone components.
Posted by Paul Hammant <pa...@yahoo.com>.
> What would that mean? A new constructor?
In a new class, yes. Nothing about the current API would change.
> Instinctive -1 based on not wanting to incur promises to remain
> compatible with non-Avalon containers...
Reconsider? I'll not commti anything that breaks the design or use of exCornerstone :-)
- Paul
________________________________________________________________________
Want to chat instantly with your online friends? Get the FREE Yahoo!
Messenger http://uk.messenger.yahoo.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
RE: exCornerstone components.
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> From: Paul Hammant [mailto:paul_hammant@yahoo.com]
>
> Thoughts?
Ummm...
What would that mean? A new constructor?
Instinctive -1 based on not wanting to incur promises to remain
compatible with non-Avalon containers...
/LS
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
RE: exCornerstone components.
Posted by Paul Hammant <pa...@yahoo.com>.
> Sounds like there is a desire to support it, and some uncertainty over the
> implications. Could you post a simple concrete example so that people can
> see what it would mean?
I'll do one in Sandbox
> From what I saw, pico looks neat. Will you be contributing some of those
> ideas to A5?
It is difficult to see *any* overlap with A4, A5, A6+ for anything other than the TLA IoC.
- Paul
________________________________________________________________________
Want to chat instantly with your online friends? Get the FREE Yahoo!
Messenger http://uk.messenger.yahoo.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
RE: exCornerstone components.
Posted by "Noel J. Bergman" <no...@devtech.com>.
Paul,
Sounds like there is a desire to support it, and some uncertainty over the
implications. Could you post a simple concrete example so that people can
see what it would mean?
>From what I saw, pico looks neat. Will you be contributing some of those
ideas to A5?
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org