You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@excalibur.apache.org by hammett <ha...@uol.com.br> on 2005/06/16 06:45:12 UTC
[Not yet a proposal]: Excalibur Container
Hi there,
Hitting the same button again - sorry! - I'd like to re-open the discussion
about a container implementation, still based on the old suggestion from Leo
Sutic, but this time using Java 1.5.
Rationale:
- Java 5 has nice features that may allow us to code a container different
from anything currently available
- An excalibur container has no relation to Fortress/Phoenix/any other which
translates in freedom on its implementation, design and functionality
- We don't even have to think about an avalon container, just focus on
Inversion of control and its meaning. An avalon adapter could come
gracefully from a good design
- For those, like myself, that haven't dig into java 5, that would be a
great opportunity :-)
Thoughts?
--
Cheers,
hammett
http://www.castleproject.org/~hammett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@excalibur.apache.org
For additional commands, e-mail: dev-help@excalibur.apache.org
Re: [Not yet a proposal]: Excalibur Container
Posted by Berin Loritsch <bl...@d-haven.org>.
hammett wrote:
> Hi there,
>
> Hitting the same button again - sorry! - I'd like to re-open the
> discussion about a container implementation, still based on the old
> suggestion from Leo Sutic, but this time using Java 1.5.
>
> Rationale:
> - Java 5 has nice features that may allow us to code a container
> different from anything currently available
> - An excalibur container has no relation to Fortress/Phoenix/any other
> which translates in freedom on its implementation, design and functionality
> - We don't even have to think about an avalon container, just focus on
> Inversion of control and its meaning. An avalon adapter could come
> gracefully from a good design
> - For those, like myself, that haven't dig into java 5, that would be a
> great opportunity :-)
>
> Thoughts?
>
I've done alot with that in Dojo, using Java 5:
http://scm.d-haven.org/svn/d-haven/trunk/dojo/
There's alot of fun stuff.
Oh, BTW, one thing you can do with Java5 and ComponentManager:
interface ComponentManager
{
<T> T lookup(Class<T>);
}
What that allows you to do when using the CM is something like this:
CacheManager cache = cm.lookup(CacheManager.class);
No casting, and using the interface to do the lookup! Very convenient.
Nevertheless, just take a look at what I've done so far and see if it
makes sense. I strove for simplicity.
--
Design is a funny word. Some people think design means how it looks.
But of course, if you dig deeper, it's really how it works.
-- Steve Jobs
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@excalibur.apache.org
For additional commands, e-mail: dev-help@excalibur.apache.org
Re: [Not yet a proposal]: Excalibur Container
Posted by hammett <ha...@uol.com.br>.
Hey Berin,
----- Original Message -----
From: "Berin Loritsch" <bl...@d-haven.org>
> I think the best aspect of what I did was to be DI flavor of the week
> agnostic. I intentionally developed a system that would allow Spring
> style components, Avalon style components, and PicoContainer style
> components all live peacefully together.
I'm all for that too! +1
> I was in the process of incorporating security into the model, and that
> resulted in the J5Sec project. I think I have yet to incorporate it in to
> the Dojo suite. It is imperative that a Dojo that uses remote components
> has a robust security model.
One of the strenghts of Castle Microkernel is that it is only focused in
being a inversion of control container. Anything else comes in the form of
facilities - yes the word was borrowed from merlin. This approach lead us to
a small code base, easy to grasp and more focused on extensions points. The
challenge that arises is how to compose extensions, chaining them, but that
was also nicely addressed in castle microkernel eventually :-)
> Add to that my really simple configuration tool that I have been working
> on for a different project, and you can see where this is going. Granted
> I'm only one guy doing all this.
And what do you think? Shall we start our little monster experimentation
from there or start a new monster altogether? ;-)
I'd rather go with a new thing, just because I - and possible others - need
to grasp the Java 1.5 from the start... :-\
--
Cheers,
hammett
http://www.castleproject.org/~hammett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@excalibur.apache.org
For additional commands, e-mail: dev-help@excalibur.apache.org
Re: [Not yet a proposal]: Excalibur Container
Posted by Berin Loritsch <bl...@d-haven.org>.
hammett wrote:
>
> I'm aware that Berin has created a container implementation using Java
> 1.5, I have dig into it when I was researching to create the current
> version of castle microkernel. We could go from Berin's work or ask him
> what he would have done differently now, and then start from there.
> Everyone here - due all past and work experience - should have a perfect
> view of what make up a good container implementation. As long as we work
> - peacefully - on an intersection, we will be in good shape.
>
I think the best aspect of what I did was to be DI flavor of the week
agnostic. I intentionally developed a system that would allow Spring
style components, Avalon style components, and PicoContainer style
components all live peacefully together.
I kept things simple by mapping one "Dojo" per component style du jour,
and incorporated the concept of a "MultiDojo" which could resolve
component implementations from the set of Dojos which made that up.
Can there be AOP? Absolutely. It should be relatively easy to
implement within this scheme.
I was in the process of incorporating security into the model, and that
resulted in the J5Sec project. I think I have yet to incorporate it in
to the Dojo suite. It is imperative that a Dojo that uses remote
components has a robust security model.
One of the things I had in mind was having an implementation of a "Budo"
(the integration piece that let's Dojo interact with components of that
school of thought) that would merely be proxies that called a remote
service. That service could be an RMI implementation, or more usefully
a Web Service.
Add to that my really simple configuration tool that I have been working
on for a different project, and you can see where this is going.
Granted I'm only one guy doing all this.
--
Design is a funny word. Some people think design means how it looks.
But of course, if you dig deeper, it's really how it works.
-- Steve Jobs
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@excalibur.apache.org
For additional commands, e-mail: dev-help@excalibur.apache.org
Re: [Not yet a proposal]: Excalibur Container
Posted by hammett <ha...@uol.com.br>.
----- Original Message -----
From: "Torsten Schlabach" <ts...@apache.org>
> What's the goal? Who is supposed to use this container for what? Why would
> any project choose this new container over any existing one?
Well, there's nothing planned. If we build something reasonable, it will
attrack users, they come with more use cases, we can accept the use cases
and work on the deficiencies and finally we will have a user-driven product.
The bottom line is that we are wasting too briliant heads around here
without building anything new. I want to give the kick off, and I'm positive
about how people will contribute, even by saying "man, that sucks, drop it
all and restart all over" :-)
I'm aware that Berin has created a container implementation using Java 1.5,
I have dig into it when I was researching to create the current version of
castle microkernel. We could go from Berin's work or ask him what he would
have done differently now, and then start from there. Everyone here - due
all past and work experience - should have a perfect view of what make up a
good container implementation. As long as we work - peacefully - on an
intersection, we will be in good shape.
--
Cheers,
hammett
http://www.castleproject.org/~hammett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@excalibur.apache.org
For additional commands, e-mail: dev-help@excalibur.apache.org
Re: [Not yet a proposal]: Excalibur Container
Posted by hammett <ha...@uol.com.br>.
Hey Eric, still owing you a beer :-)
----- Original Message -----
From: "Eric Pugh" <ep...@opensourceconnections.com>
>I would just suggest that the name of the container not be Excalibur..
>there is enough baggage around that as is. Also, how would you
>differentiate from Spring/Nano?
As this is not even a proposal, sure thing we can work on a new name. I'd
recommend that we don't spend much energy on that at first, though. We might
go on with a codename "dolphin" or something silly like that and in the end
choose a decent name.
> I guess I am wondering from a marketing perspective "why is your product
> better" (even if it's just ideas at this point!)?
It would be better if we sum up all problems and deficiencies that we have
faced in the past and address them in this container implementation. It
would be a consequence, and not planned up front.
> Will it be the implementation based on Java 5 features?
I hope so :-)
> Will it be the support for existing components?
Something to be decided. I'd say that we shouldn't worry about that.
> Will it be some sort of new technique that makes setting up a container
> easy/better?
Hope so too.
--
Cheers,
hammett
http://www.castleproject.org/~hammett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@excalibur.apache.org
For additional commands, e-mail: dev-help@excalibur.apache.org
Re: [Not yet a proposal]: Excalibur Container
Posted by Eric Pugh <ep...@opensourceconnections.com>.
I would just suggest that the name of the container not be
Excalibur.. there is enough baggage around that as is. Also, how
would you differentiate from Spring/Nano?
I guess I am wondering from a marketing perspective "why is your
product better" (even if it's just ideas at this point!)?
Will it be the implementation based on Java 5 features?
Will it be the support for existing components?
Will it be some sort of new technique that makes setting up a
container easy/better?
Eric Pugh
On Jun 16, 2005, at 5:36 AM, Torsten Schlabach wrote:
> hammet,
>
>
>
>>> Thoughts?
>>>
>>>
>
> What's the goal? Who is supposed to use this container for what?
> Why would
> any project choose this new container over any existing one?
>
> Regards,
> Torsten
>
>
>
>
>> Hi there,
>>
>> Hitting the same button again - sorry! - I'd like to re-open the
>> discussion
>> about a container implementation, still based on the old
>> suggestion from
>> Leo
>> Sutic, but this time using Java 1.5.
>>
>> Rationale:
>> - Java 5 has nice features that may allow us to code a container
>> different
>> from anything currently available
>> - An excalibur container has no relation to Fortress/Phoenix/any
>> other
>> which
>> translates in freedom on its implementation, design and functionality
>> - We don't even have to think about an avalon container, just
>> focus on
>> Inversion of control and its meaning. An avalon adapter could come
>> gracefully from a good design
>> - For those, like myself, that haven't dig into java 5, that would
>> be a
>> great opportunity :-)
>>
>> Thoughts?
>>
>> --
>> Cheers,
>> hammett
>> http://www.castleproject.org/~hammett
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@excalibur.apache.org
>> For additional commands, e-mail: dev-help@excalibur.apache.org
>>
>>
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@excalibur.apache.org
> For additional commands, e-mail: dev-help@excalibur.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@excalibur.apache.org
For additional commands, e-mail: dev-help@excalibur.apache.org
Re: [Not yet a proposal]: Excalibur Container
Posted by Torsten Schlabach <ts...@apache.org>.
hammet,
>> Thoughts?
What's the goal? Who is supposed to use this container for what? Why would
any project choose this new container over any existing one?
Regards,
Torsten
> Hi there,
>
> Hitting the same button again - sorry! - I'd like to re-open the
> discussion
> about a container implementation, still based on the old suggestion from
> Leo
> Sutic, but this time using Java 1.5.
>
> Rationale:
> - Java 5 has nice features that may allow us to code a container different
> from anything currently available
> - An excalibur container has no relation to Fortress/Phoenix/any other
> which
> translates in freedom on its implementation, design and functionality
> - We don't even have to think about an avalon container, just focus on
> Inversion of control and its meaning. An avalon adapter could come
> gracefully from a good design
> - For those, like myself, that haven't dig into java 5, that would be a
> great opportunity :-)
>
> Thoughts?
>
> --
> Cheers,
> hammett
> http://www.castleproject.org/~hammett
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@excalibur.apache.org
> For additional commands, e-mail: dev-help@excalibur.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@excalibur.apache.org
For additional commands, e-mail: dev-help@excalibur.apache.org
Re: [Not yet a proposal]: Excalibur Container
Posted by hammett <ha...@uol.com.br>.
Thanks, dude ;-)
--
Cheers,
hammett
http://www.castleproject.org/~hammett
----- Original Message -----
From: "Leo Simons" <ma...@leosimons.com>
> On 16-06-2005 06:45, "hammett" <ha...@uol.com.br> wrote:
>> Thoughts?
>
> I love where you've taken castle and the surrounding .net stuff. It would
> no
> doubt benefit the java world a whole lot if you could bring some of those
> innovations over the fence.
>
> I'm probably not going to be able to participate. Stretched too thin
> already.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@excalibur.apache.org
For additional commands, e-mail: dev-help@excalibur.apache.org
Re: [Not yet a proposal]: Excalibur Container
Posted by Leo Simons <ma...@leosimons.com>.
On 16-06-2005 06:45, "hammett" <ha...@uol.com.br> wrote:
> Thoughts?
I love where you've taken castle and the surrounding .net stuff. It would no
doubt benefit the java world a whole lot if you could bring some of those
innovations over the fence.
I'm probably not going to be able to participate. Stretched too thin
already.
- LSD
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@excalibur.apache.org
For additional commands, e-mail: dev-help@excalibur.apache.org