You are viewing a plain text version of this content. The canonical link for it is here.
Posted to phoenix-dev@avalon.apache.org by Peter Donald <pe...@apache.org> on 2002/10/01 10:26:05 UTC
Map and Array Dependencies
Hi,
I have just added support for complex dependencies in Phoenix so that they can
either be an array of services or a map of services. To declare an array you
just postfix it with "[]" and to declare a map you postfix it with "#" in
xinfo file. And then you can just access it via something like
void service( ServiceManager sm )
{
//An array of services
MyService[] services1 =
(MyService[])sm.lookup( MyService[].class.getName() );
//Same as above
MyService[] services2 =
(MyService[])sm.lookup( MyService.ROLE + "[]" );
//A unmodifiable Map of services
Map services3 =
(Map)sm.lookup( MyService.ROLE + "#" );
}
It seems to work well. However I don't really like the idea of postfixing the
service with "#" to indicate a map. I have thought about using "{}" instead
or maybe "<>" - Any preferences?
Any other comments?
--
Cheers,
Peter Donald
The big mistake that men make is that when they turn thirteen or fourteen and
all of a sudden they've reached puberty, they believe that they like women.
Actually, you're just horny. It doesn't mean you like women any more at
twenty-one than you did at ten. --Jules Feiffer (cartoonist)
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Map and Array Dependencies
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
OK, cool.
> From: Peter Donald [mailto:peter@apache.org]
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Map and Array Dependencies
Posted by Peter Donald <pe...@apache.org>.
On Tue, 1 Oct 2002 23:16, Berin Loritsch wrote:
> Leo Sutic wrote:
> > Just one more thing, Peter...
> >
> > I'm fine with the Array lookup.
> >
> > But the Map lookup looks a lot like a ComponentSelector.
>
> I agree here. I think that was the result of the Map question
> a long time ago. The biggest problem with the Map I have is that
> it must be an Unmodifiable Map. Noone should be able to bind
> new services to that Map, or change the bindings that are there.
>
> What does Map provide that XXXSelector doesn't?
* iteration over services.
* Cleaner semantics (no notion of criteria, construction or alternative
policys of provisioning as has been with selector)
> > Is the difference that in both cases the component doing
> > the lookup is intended to perform operations on *all*
> > returned services, as opposed to just selecting one of them?
>
> That is a key question. With arrays, I have a sneaking
> suspiscion that the exact indexes of the components will
> change as we change the number of components. That can spell
> disastor for someone who is banking on the behavior of
> component 6 returned from an array. If the array is smaller
> we get an IndexOutOfBoundsException. If the array has a
> new element inserted at position 5, then what used to be
> 6 is now 7.
You can't stop people from writing bad code ;)
> > That is, while with selector you did:
> >
> > 1. lookup selector.
> > 2. select *one* service.
> > 3. perform operation on service.
>
> Which is what I would expect. A component should know its
> dependencies up front.
Which is where the different stress is. The multiplicity of dependencies may
be not known at development time and must be specified at deployment time.
--
Cheers,
Peter Donald
-----------------------------------------------
"Only two things are infinite, the universe and
human stupidity, and I'm not sure about the
former." -Albert Einstein
-----------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Map and Array Dependencies
Posted by Peter Donald <pe...@apache.org>.
On Tue, 1 Oct 2002 23:42, Leo Sutic wrote:
> But the Map return - what does it guarantee in terms of key -> value
> mapping? What type is the key? I don't like it.
key is type string. Contents of map is defined at assembly time.
--
Cheers,
Peter Donald
*------------------------------------------------------*
| "Nearly all men can stand adversity, but if you want |
| to test a man's character, give him power." |
| -Abraham Lincoln |
*------------------------------------------------------*
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Map and Array Dependencies
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> From: Berin Loritsch [mailto:bloritsch@apache.org]
>
> > Is the difference that in both cases the component doing
> > the lookup is intended to perform operations on *all* returned
> > services, as opposed to just selecting one of them?
>
>
> That is a key question. With arrays, I have a sneaking
> suspiscion that the exact indexes of the components will
> change as we change the number of components. That can spell
> disastor for someone who is banking on the behavior of
> component 6 returned from an array. If the array is smaller
> we get an IndexOutOfBoundsException. If the array has a new
> element inserted at position 5, then what used to be 6 is now 7.
That's exactly the type of behavior that should not be allowed.
What I want is for the array return to have no guarantees as
to its length or the specific indexes - and as far as I can tell,
this is the case.
But the Map return - what does it guarantee in terms of key -> value
mapping? What type is the key? I don't like it.
> > But with Map / Array lookup you'd:
> >
> > 1. lookup Map / Array
> > 2. foreach Service service in Map/Array do service.method ()
>
>
> I don't like this from a security perspective. What you are
> doing is making it alot easier to write trojan components
> that operate on all the services. In essence we are giving
> up too much control.
I disagree. You still have to specify each component in the array in the
assembly config.
/LS
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Map and Array Dependencies
Posted by Berin Loritsch <bl...@apache.org>.
Leo Sutic wrote:
> Just one more thing, Peter...
>
> I'm fine with the Array lookup.
>
> But the Map lookup looks a lot like a ComponentSelector.
I agree here. I think that was the result of the Map question
a long time ago. The biggest problem with the Map I have is that
it must be an Unmodifiable Map. Noone should be able to bind
new services to that Map, or change the bindings that are there.
What does Map provide that XXXSelector doesn't?
> Is the difference that in both cases the component doing
> the lookup is intended to perform operations on *all*
> returned services, as opposed to just selecting one of them?
That is a key question. With arrays, I have a sneaking
suspiscion that the exact indexes of the components will
change as we change the number of components. That can spell
disastor for someone who is banking on the behavior of
component 6 returned from an array. If the array is smaller
we get an IndexOutOfBoundsException. If the array has a
new element inserted at position 5, then what used to be
6 is now 7.
Arrays are bad for predictability in that sense, and they
take too long to linearly search them for the specific
component we want.
> That is, while with selector you did:
>
> 1. lookup selector.
> 2. select *one* service.
> 3. perform operation on service.
Which is what I would expect. A component should know its
dependencies up front.
>
> But with Map / Array lookup you'd:
>
> 1. lookup Map / Array
> 2. foreach Service service in Map/Array do service.method ()
I don't like this from a security perspective. What you are
doing is making it alot easier to write trojan components
that operate on all the services. In essence we are giving
up too much control.
When you develop from a forknowledge perspective, you know
what needs to be there to work and you use it. When you
develop from a discovery perspective, things are more
flexible, but at a high price. Just look at all the issues
with IIS. Microsoft can make things easy, but they have
a hard time making things secure.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Map and Array Dependencies
Posted by Peter Donald <pe...@apache.org>.
On Tue, 1 Oct 2002 22:59, Leo Sutic wrote:
> Just one more thing, Peter...
>
> I'm fine with the Array lookup.
>
> But the Map lookup looks a lot like a ComponentSelector.
yep. That was one of the original options proposed instead of Selector. The
key difference is that with the Map the consumer can iterate through all the
services.
> Is the difference that in both cases the component doing
> the lookup is intended to perform operations on *all*
> returned services, as opposed to just selecting one of them?
>
> That is, while with selector you did:
>
> 1. lookup selector.
> 2. select *one* service.
> 3. perform operation on service.
>
> But with Map / Array lookup you'd:
>
> 1. lookup Map / Array
> 2. foreach Service service in Map/Array do service.method ()
Sorta. The users of Selector know the criteria with which to aquire components
but never know how many components back the selector. They can never iterate
through them all or anything like that and can implement any sort of policy
(from being a Factory, to a fancy map to a proper query resolver).
However a map is designed to allow the consumers of a service to iterate
through the services. The keys in map are really only used to tag the service
and probably don't mean that much to the consumer of the service.
Consider the question of a Broker or Exporter component that exports
components (via RMI, AltRMI, SOAP, IIOP, intra-process or whatever).
With fixed dependencies you end up having an "link" component for every object
you want to export/brokered that registers exported object with broker
service. Each of these links will de-register service on shutdown.
Now lets say you have 10 objects you want exported. That adds 12 more objects
to your system when you really only need 1 object and the other 11 are work
arounds for inflexibility of service provisioning.
--
Cheers,
Peter Donald
-----------------------------------------------------------
Don't take life too seriously --
you'll never get out of it alive.
-----------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Map and Array Dependencies
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
Just one more thing, Peter...
I'm fine with the Array lookup.
But the Map lookup looks a lot like a ComponentSelector.
Is the difference that in both cases the component doing
the lookup is intended to perform operations on *all*
returned services, as opposed to just selecting one of them?
That is, while with selector you did:
1. lookup selector.
2. select *one* service.
3. perform operation on service.
But with Map / Array lookup you'd:
1. lookup Map / Array
2. foreach Service service in Map/Array do service.method ()
/LS
> From: Peter Donald [mailto:peter@apache.org]
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Map and Array Dependencies
Posted by Peter Donald <pe...@apache.org>.
On Tue, 1 Oct 2002 22:27, Stephen McConnell wrote:
> Peter Donald wrote:
> >On Tue, 1 Oct 2002 19:10, Leo Simons wrote:
> >>>Any other comments?
> >>
> >>This adds additional semantic meaning to the lookup key, modifying the
> >>sm contract.
> >
> >nope. See other mail - it adds meaning to the type not the lookup key.
> >
> >>What if I have an application deployed in phoenix 4.0 that just happens
> >>to postfix about half of its components with "#"? It will break in the
> >>next release.
> >
> >False. It is an impossible contract as previously they were interpreted as
> >pure classnames in which case both [] and # were not viable within
> > phoenix.
>
> Now that's incorrect.
> That is absolutely not criteria that states that a lookup key is an
> interface class name.
Errrrr - look 10 lines up where I wrote "See other mail - it adds meaning to
the type not the lookup key."
Type mapping to key is a convention that is followed by everyone else but you.
Fortress/ECM enforces the convention while Phoenix just strongly recomends
it.
--
Cheers,
Peter Donald
*------------------------------------------------------*
| "Nearly all men can stand adversity, but if you want |
| to test a man's character, give him power." |
| -Abraham Lincoln |
*------------------------------------------------------*
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Map and Array Dependencies
Posted by Peter Donald <pe...@apache.org>.
On Tue, 1 Oct 2002 19:42, Leo Simons wrote:
> On Tue, 2002-10-01 at 11:27, Peter Donald wrote:
> > On Tue, 1 Oct 2002 19:10, Leo Simons wrote:
> > > > Any other comments?
> > >
> > > This adds additional semantic meaning to the lookup key, modifying the
> > > sm contract.
> >
> > nope. See other mail - it adds meaning to the type not the lookup key.
>
> oh. I should shut up then =)
>
> I don't think I get it though. If you now do:
>
> sm.lookup( MyService.ROLE + "#" );
>
> phoenix behaves differently from before, right?
nope.
> So the contract relating
> to the lookup() method changes. I'm probably being silly here....
In phoenix the lookup key is decoupled from the type of the service and it has
been for a while. So you could quite easily have
MyService[] services =
(MyService[])sm.lookup( "Theres a hole in my bucket, dear Eliza" );
and that would be perfectly valid. The role name defaults to the name of the
type unless otherwise specified.
However if you specified a type that had a postfix of "#" then it will behave
different. Previously the type just indicated the name of java interface that
implements service. That has been expanded so that we can have array types.
We have also added a custom interpretation of "#" because java does not
natively support a map type.
--
Cheers,
Peter Donald
-----------------------------------------------
"You can't depend on your eyes when your
imagination is out of focus." -Mark Twain
-----------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Map and Array Dependencies
Posted by Leo Simons <le...@apache.org>.
On Tue, 2002-10-01 at 11:27, Peter Donald wrote:
> On Tue, 1 Oct 2002 19:10, Leo Simons wrote:
> > > Any other comments?
> >
> > This adds additional semantic meaning to the lookup key, modifying the
> > sm contract.
>
> nope. See other mail - it adds meaning to the type not the lookup key.
oh. I should shut up then =)
I don't think I get it though. If you now do:
sm.lookup( MyService.ROLE + "#" );
phoenix behaves differently from before, right? So the contract relating
to the lookup() method changes. I'm probably being silly here....
cheers,
Leo
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Map and Array Dependencies
Posted by Leo Simons <le...@apache.org>.
On Tue, 2002-10-01 at 11:27, Peter Donald wrote:
> On Tue, 1 Oct 2002 19:10, Leo Simons wrote:
> > > Any other comments?
> >
> > This adds additional semantic meaning to the lookup key, modifying the
> > sm contract.
>
> nope. See other mail - it adds meaning to the type not the lookup key.
oh. I should shut up then =)
I don't think I get it though. If you now do:
sm.lookup( MyService.ROLE + "#" );
phoenix behaves differently from before, right? So the contract relating
to the lookup() method changes. I'm probably being silly here....
cheers,
Leo
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Map and Array Dependencies
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> From: Stephen McConnell [mailto:mcconnell@apache.org]
>
>
> Peter Donald wrote:
>
> >On Tue, 1 Oct 2002 19:10, Leo Simons wrote:
> >
> >
> >>>Any other comments?
> >>>
> >>>
> >>This adds additional semantic meaning to the lookup key,
> modifying the
> >>sm contract.
> >>
> >>
> >
> >nope. See other mail - it adds meaning to the type not the
> lookup key.
> >
> >
> >
> >>What if I have an application deployed in phoenix 4.0 that just
> >>happens to postfix about half of its components with "#"? It will
> >>break in the next release.
> >>
> >>
> >
> >False. It is an impossible contract as previously they were
> interpreted
> >as
> >pure classnames in which case both [] and # were not viable
> within phoenix.
> >
> >
>
> Now that's incorrect.
> That is absolutely not criteria that states that a lookup key is an
> interface class name.
> Steve.
In the context Peter says it, he's right. Like this:
Suppose you have this:
<dependency>
<service interface="org.MyService">
</dependency>
In Phoenix, you can look up the dependency with the key "org.MyService"
OR you can give it a role name:
<dependency>
<role>myservice</role>
<service interface="org.MyService">
</dependency>
and use "myservice" as a lookup key.
What Peter means is that in the case where the role defaulted to the
interface
name, there was no way you could have [] or # in the role. If you had
explicitely
specified a role name, then that will be unchanged. That is, if I had:
<dependency>
<role>myservice#</role>
<service interface="org.MyService">
</dependency>
Then lookup ("myservice#") will *still* give me a MyService interface,
and not a
map, because the dependency is still on an interface and not a map.
1.
<dependency>
<role>myservice#</role>
<service interface="org.MyService">
</dependency>
lookup ("myservice") <ERROR>
lookup ("myservice#") instanceof org.MyService
2.
<dependency>
<role>myservice#</role>
<service interface="org.MyService#">
</dependency>
lookup ("myservice") <ERROR>
lookup ("myservice#") instanceof java.util.Map
3.
<dependency>
<role>myservice</role>
<service interface="org.MyService#">
</dependency>
lookup ("myservice") instanceof java.util.Map
lookup ("myservice#") <ERROR>
/LS
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Map and Array Dependencies
Posted by Stephen McConnell <mc...@apache.org>.
Peter Donald wrote:
>On Tue, 1 Oct 2002 19:10, Leo Simons wrote:
>
>
>>>Any other comments?
>>>
>>>
>>This adds additional semantic meaning to the lookup key, modifying the
>>sm contract.
>>
>>
>
>nope. See other mail - it adds meaning to the type not the lookup key.
>
>
>
>>What if I have an application deployed in phoenix 4.0 that just happens
>>to postfix about half of its components with "#"? It will break in the
>>next release.
>>
>>
>
>False. It is an impossible contract as previously they were interpreted as
>pure classnames in which case both [] and # were not viable within phoenix.
>
>
Now that's incorrect.
That is absolutely not criteria that states that a lookup key is an
interface class name.
Steve.
>
>
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Map and Array Dependencies
Posted by Peter Donald <pe...@apache.org>.
On Tue, 1 Oct 2002 19:10, Leo Simons wrote:
> > Any other comments?
>
> This adds additional semantic meaning to the lookup key, modifying the
> sm contract.
nope. See other mail - it adds meaning to the type not the lookup key.
> What if I have an application deployed in phoenix 4.0 that just happens
> to postfix about half of its components with "#"? It will break in the
> next release.
False. It is an impossible contract as previously they were interpreted as
pure classnames in which case both [] and # were not viable within phoenix.
--
Cheers,
Peter Donald
*-----------------------------------------------------*
* "Faced with the choice between changing one's mind, *
* and proving that there is no need to do so - almost *
* everyone gets busy on the proof." *
* - John Kenneth Galbraith *
*-----------------------------------------------------*
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Map and Array Dependencies
Posted by Peter Donald <pe...@apache.org>.
On Tue, 1 Oct 2002 19:10, Leo Simons wrote:
> > Any other comments?
>
> This adds additional semantic meaning to the lookup key, modifying the
> sm contract.
nope. See other mail - it adds meaning to the type not the lookup key.
> What if I have an application deployed in phoenix 4.0 that just happens
> to postfix about half of its components with "#"? It will break in the
> next release.
False. It is an impossible contract as previously they were interpreted as
pure classnames in which case both [] and # were not viable within phoenix.
--
Cheers,
Peter Donald
*-----------------------------------------------------*
* "Faced with the choice between changing one's mind, *
* and proving that there is no need to do so - almost *
* everyone gets busy on the proof." *
* - John Kenneth Galbraith *
*-----------------------------------------------------*
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Map and Array Dependencies
Posted by Peter Donald <pe...@apache.org>.
On Tue, 1 Oct 2002 23:25, Peter Donald wrote:
> > I would be much more comfortable if we had a stable branch (which can be
> > separate from the MAIN branch). The stable branch would only have bug
> > fixes for six months, or until we are ready to make the development
> > branch the stable one.
> >
> > Do you think that would be possible?
Oha and there is a stable branch for last release aswell if we need it. The
branch is labeled "RELEASE_402-branch" and the release is marked with
RELEASE_402-before-merge".
--
Cheers,
Peter Donald
-----------------------------------------------------
When a stupid man is doing something he's ashamed of,
he always declares that it is his duty.
George Bernard Shaw
-----------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Map and Array Dependencies
Posted by Peter Donald <pe...@apache.org>.
On Tue, 1 Oct 2002 22:59, Berin Loritsch wrote:
> I think a sensible approach is to do what Linux Kernel development does.
> It branches the development into a Stable branch and a Development
> branch. The truth is we need a *stable* Phoenix.
>
> By splitting the development in that way, we don't stifle Phoenix's
> development but we also provide a stable branch for users.
Thats effectively what we are doing. Theres a FACTORY branch for some of the
risky changes submitted By Igor. I have also held of committing large chunks
of code precisely because they are not stable/tested enough.
Theres plenty of stuff that I haven't committed and wont till we get a
> > For example we have talked about allowing Map as dependencies since
> > before you were involved with Avalon - way back when it was just me
> > Berin, Fede and Stefano. Arrays have been "approved" before but no one
> > ever got around to implementing them.
>
> I'll be honest, I don't recall those conversations or the problems that
> the Map/Array were supposed to solve. They probably occured,
It was during our ComponentSelector/NamedComponentManager/ nested
ComponentManager "discussions". IIRC I think it was Fede who wanted simple
types (Map and array), me who wanted nested ComponentManagers and you and
Stefano who wanted Selectors.
> but I am
> not sure that forcing a returned value based on a postfix is probably
> not the best answer.
Okay then don't think of it as a postfix. Think of it as indicating a type.
Dont think of "com.biz.Foo[]" as "com.biz.Foo" with "[]" postfix. Think it as
an array type. (Of course we need to have a special notation for maps as java
lacks any native associative arrays).
> I would be much more comfortable if we had a stable branch (which can be
> separate from the MAIN branch). The stable branch would only have bug
> fixes for six months, or until we are ready to make the development
> branch the stable one.
>
> Do you think that would be possible?
It is effectively what we are doing sans the unstable branch. ie Anything that
I consider too risky is being developed outside of Apache CVS, on a branch or
in excalibur.
You possibly seen reference to "Spice" which is the container I developed
using CK. It is similar to Merlin2 with minor differences and is effectively
my testing ground where I try out the ideas. Most of it will be migrated back
to CK/Info/Phoenix over time but it wont be done while Phoenix is in stable
mode.
I think it will be two more releases on the stable trunk before I break off
and start implementing new slightly more risky features.
--
Cheers,
Peter Donald
*--------------------------------*
| Every rule has an exception, |
| except the rule of exceptions. |
*--------------------------------*
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Map and Array Dependencies
Posted by Berin Loritsch <bl...@apache.org>.
Leo Simons wrote:
>>I think a sensible approach is to do what Linux Kernel development does.
>>It branches the development into a Stable branch and a Development
>>branch. The truth is we need a *stable* Phoenix.
>
>
> Which is what I would propose....but I am afraid that the people most
> active on phoenix maintainance (ie pete, paul, ....) would just leave
> the stable branch lying around, being stable.
>
> The linux kernel team has more resources. Maintaining branches is a
> resource commitment. I'm not going to ask it of the phoenix people.
>
> but it'd be smart =)
Hopefully, all that is required is for it to sit around. However if
there are bug fixes that people submit, it would be easier to apply
them to the branch. Then you can determine if it is still true of the
new development--which might be the case with classloader issues.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Map and Array Dependencies
Posted by Leo Simons <le...@apache.org>.
that makes me a very happy jagged little pill :)
- LSD
On Tue, 2002-10-01 at 16:05, Peter Royal wrote:
> On Tuesday, October 1, 2002, at 09:18 AM, Leo Simons wrote:
> > Which is what I would propose....but I am afraid that the people most
> > active on phoenix maintainance (ie pete, paul, ....) would just leave
> > the stable branch lying around, being stable.
>
> I volunteer to monitor the stable branch. I'll even help with releases
> if Paul is tracking HEAD more.
>
> I envision a 4.0.x branch to continue, with all the new goodies in 4.(
> x > 0 )
> -pete
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Map and Array Dependencies
Posted by Peter Royal <pr...@apache.org>.
On Tuesday, October 1, 2002, at 09:18 AM, Leo Simons wrote:
> Which is what I would propose....but I am afraid that the people most
> active on phoenix maintainance (ie pete, paul, ....) would just leave
> the stable branch lying around, being stable.
I volunteer to monitor the stable branch. I'll even help with releases
if Paul is tracking HEAD more.
I envision a 4.0.x branch to continue, with all the new goodies in 4.(
x > 0 )
-pete
--
peter royal -> proyal@apache.org
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Map and Array Dependencies
Posted by Leo Simons <le...@apache.org>.
> I think a sensible approach is to do what Linux Kernel development does.
> It branches the development into a Stable branch and a Development
> branch. The truth is we need a *stable* Phoenix.
Which is what I would propose....but I am afraid that the people most
active on phoenix maintainance (ie pete, paul, ....) would just leave
the stable branch lying around, being stable.
The linux kernel team has more resources. Maintaining branches is a
resource commitment. I'm not going to ask it of the phoenix people.
but it'd be smart =)
- Leo
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Map and Array Dependencies
Posted by Berin Loritsch <bl...@apache.org>.
Peter Donald wrote:
> On Tue, 1 Oct 2002 19:57, Leo Simons wrote:
>
>
>>yup. I don't have a better answer than anyone else to this dilemma. All
>>I know is that it would be very nice for me, and I think for many avalon
>>users, to have only bugfixes, docs, testing etc for phoenix for like 6
>>months or so.
>
>
> why would we want to hobble Phoenix in that way?
I think a sensible approach is to do what Linux Kernel development does.
It branches the development into a Stable branch and a Development
branch. The truth is we need a *stable* Phoenix.
By splitting the development in that way, we don't stifle Phoenix's
development but we also provide a stable branch for users.
>>The answer to questions like the one leading to the changes we're
>>talking about now could be "we don't support this directly. Wait until
>>phoenix 5 or so or solve at the application level". It's about choosing
>>between stability/compatibility and continuous improvement. It seems I'm
>>wrong in this particular case, but on a larger scale it is something
>>where we need to shift the balance towards stability.
>
>
> It has already happened. If you have not been taking notice of the commits you
> will have missed that this is exactly what is happening. Almost all the work
> that is going into Phoenix (and Fortress for that matter) at this stage is
> consolidation.
>
> Parts are being extracted and unit tested to a far greater degree than before.
> Features that we have been putting off for ages are being added in and unit
> tested.
Yep.
> For example we have talked about allowing Map as dependencies since before you
> were involved with Avalon - way back when it was just me Berin, Fede and
> Stefano. Arrays have been "approved" before but no one ever got around to
> implementing them.
I'll be honest, I don't recall those conversations or the problems that
the Map/Array were supposed to solve. They probably occured, but I am
not sure that forcing a returned value based on a postfix is probably
not the best answer.
> The ClassLoader stuff I am implementing atm has been needed for ages and will
> allow us to embed Catalina (and/or Jo!) into phoenix cleanly. Something that
> has seen some discussion lately on the Phoenix list. It will also allow us to
> embed EJBs if one so desires.
That has been needed for ages.
> After that there will be integration of Installer enhancements (from XML),
> then comes Auto-Assembly, factorys that can create Avalon services from
> WebServices, exposing kernel components to applications etc.
Kool.
> Finally we will integrate the Info and interceptor architecture combo. This
> will allow us to do things that are not possible in any container now
> (Avalon, EJB or CORBA) and allow us much more flexibility than ever (and
> scarily half the credit for that belongs with Microsoft).
;P That is scary. The two language features that C# has that are
necessary for modern development are delegates and attributes. I would
love both of these features to exist in Java--and it will probably
happen by 2038 (when 32 bit clocks are insufficient). Delegates are
critical to intelligent software (i.e. artificial intelligence), and
Attributes are critical to component lookup and resolution.
Damn, makes me wish I had a C# compiler....
>
> If you think you have something to offer then participate. If you don't want
> to see any progress for whatever reason then don't. Simple as that really.
>
I would be much more comfortable if we had a stable branch (which can be
separate from the MAIN branch). The stable branch would only have bug
fixes for six months, or until we are ready to make the development
branch the stable one.
Do you think that would be possible?
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Map and Array Dependencies
Posted by Ulrich Mayring <ul...@denic.de>.
Leo Simons wrote:
> On Tue, 2002-10-01 at 12:27, Peter Donald wrote:
>
>>Features that we have been putting off for ages are being added in and unit
>>tested.
>
> which is the part I find puzzling, I guess. I guess I'm not so confident
> as you that this won't collide with the finding and fixing of existing
> issues.
A release version should be feature-freezed, only bugfixes and security patches
should go in. That way, over time, the users have a stable reference
implementation, where they can depend on that it doesn't change.
New features are for the next version. Maybe Peter is right now developing the
next version? :)
Ulrich
--
Ulrich Mayring
DENIC eG, Systementwicklung
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Map and Array Dependencies
Posted by Ulrich Mayring <ul...@denic.de>.
Leo Simons wrote:
> On Tue, 2002-10-01 at 12:27, Peter Donald wrote:
>
>>Features that we have been putting off for ages are being added in and unit
>>tested.
>
> which is the part I find puzzling, I guess. I guess I'm not so confident
> as you that this won't collide with the finding and fixing of existing
> issues.
A release version should be feature-freezed, only bugfixes and security patches
should go in. That way, over time, the users have a stable reference
implementation, where they can depend on that it doesn't change.
New features are for the next version. Maybe Peter is right now developing the
next version? :)
Ulrich
--
Ulrich Mayring
DENIC eG, Systementwicklung
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Map and Array Dependencies
Posted by Leo Simons <le...@apache.org>.
On Tue, 2002-10-01 at 12:27, Peter Donald wrote:
> On Tue, 1 Oct 2002 19:57, Leo Simons wrote:
> > true. Avalon doesn't offer a convenient way to satisfy all use cases it
> > wants to satisfy.
>
> There is no magic bullet and there never will be.
That was exactly my point I guess =)
> > yup. I don't have a better answer than anyone else to this dilemma. All
> > I know is that it would be very nice for me, and I think for many avalon
> > users, to have only bugfixes, docs, testing etc for phoenix for like 6
> > months or so.
>
> why would we want to hobble Phoenix in that way?
it's finally been released as stable. In my (yes, limited) experience
with software development, once something is marked 'stable', some
people will finally start submitting bug reports or even bothering
looking under the hood.
Phoenix is a bit exceptional as it has had a long alpha and beta road,
so there might be only a few issues. It seems there are always twice the
amount you expect though.
that's why =)
> > The answer to questions like the one leading to the changes we're
> > talking about now could be "we don't support this directly. Wait until
> > phoenix 5 or so or solve at the application level". It's about choosing
> > between stability/compatibility and continuous improvement. It seems I'm
> > wrong in this particular case, but on a larger scale it is something
> > where we need to shift the balance towards stability.
>
> It has already happened. If you have not been taking notice of the commits you
> will have missed that this is exactly what is happening. Almost all the work
> that is going into Phoenix (and Fortress for that matter) at this stage is
> consolidation.
(for other english impaired:
con·sol·i·date
1. To unite into one system or whole; combine: consolidated five
separate agencies into a single department.
2. To make strong or secure; strengthen: She consolidated her power
during her first year in office.
3. To make firm or coherent; form into a compact mass.)
I think you mean 2 & 3 from the above =)
> Parts are being extracted and unit tested to a far greater degree than before.
which is worthy of whoo-hoohs. It just seems to me that as there is
still so many unit tests to be/being added, it is inevitable there will
be bugs to be found and fixed.
> Features that we have been putting off for ages are being added in and unit
> tested.
which is the part I find puzzling, I guess. I guess I'm not so confident
as you that this won't collide with the finding and fixing of existing
issues.
> For example we have talked about allowing Map as dependencies since before you
> were involved with Avalon - way back when it was just me Berin, Fede and
> Stefano. Arrays have been "approved" before but no one ever got around to
> implementing them.
ahh. I hope you understand how it looked to me: a new concept added to
released code without any prior discussion as to how/what/why/etc.
> If you think you have something to offer then participate.
In this case (and also wrt interceptor architecture, dynamic dependency
resolutions, etc) it makes no sense whatsoever for me to get involved
and do coding. I'd be in over my head, and in the way.
But I feel I do have something to offer, like voicing user (and
executive management!) fears wrt ever changing feature sets. I
understand it can be annoying when you finish a few hours of coding and
then hear someone say "but won't it impact backwards compatibility?",
but I think it is still important the question is asked, and answered.
When/if we have a 'complete' set of specs/unit tests/regression tests,
that will happen automatically. We're not there yet so I'll keep moaning
about it from time to time.
> If you don't want
> to see any progress for whatever reason then don't. Simple as that really.
If only it were :)
> ------------------------------------------------------------
> militant agnostic: i don't know, and you don't know either.
> ------------------------------------------------------------
how appropriate :)
cheers,
Leo
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Map and Array Dependencies
Posted by Leo Simons <le...@apache.org>.
On Tue, 2002-10-01 at 12:27, Peter Donald wrote:
> On Tue, 1 Oct 2002 19:57, Leo Simons wrote:
> > true. Avalon doesn't offer a convenient way to satisfy all use cases it
> > wants to satisfy.
>
> There is no magic bullet and there never will be.
That was exactly my point I guess =)
> > yup. I don't have a better answer than anyone else to this dilemma. All
> > I know is that it would be very nice for me, and I think for many avalon
> > users, to have only bugfixes, docs, testing etc for phoenix for like 6
> > months or so.
>
> why would we want to hobble Phoenix in that way?
it's finally been released as stable. In my (yes, limited) experience
with software development, once something is marked 'stable', some
people will finally start submitting bug reports or even bothering
looking under the hood.
Phoenix is a bit exceptional as it has had a long alpha and beta road,
so there might be only a few issues. It seems there are always twice the
amount you expect though.
that's why =)
> > The answer to questions like the one leading to the changes we're
> > talking about now could be "we don't support this directly. Wait until
> > phoenix 5 or so or solve at the application level". It's about choosing
> > between stability/compatibility and continuous improvement. It seems I'm
> > wrong in this particular case, but on a larger scale it is something
> > where we need to shift the balance towards stability.
>
> It has already happened. If you have not been taking notice of the commits you
> will have missed that this is exactly what is happening. Almost all the work
> that is going into Phoenix (and Fortress for that matter) at this stage is
> consolidation.
(for other english impaired:
con·sol·i·date
1. To unite into one system or whole; combine: consolidated five
separate agencies into a single department.
2. To make strong or secure; strengthen: She consolidated her power
during her first year in office.
3. To make firm or coherent; form into a compact mass.)
I think you mean 2 & 3 from the above =)
> Parts are being extracted and unit tested to a far greater degree than before.
which is worthy of whoo-hoohs. It just seems to me that as there is
still so many unit tests to be/being added, it is inevitable there will
be bugs to be found and fixed.
> Features that we have been putting off for ages are being added in and unit
> tested.
which is the part I find puzzling, I guess. I guess I'm not so confident
as you that this won't collide with the finding and fixing of existing
issues.
> For example we have talked about allowing Map as dependencies since before you
> were involved with Avalon - way back when it was just me Berin, Fede and
> Stefano. Arrays have been "approved" before but no one ever got around to
> implementing them.
ahh. I hope you understand how it looked to me: a new concept added to
released code without any prior discussion as to how/what/why/etc.
> If you think you have something to offer then participate.
In this case (and also wrt interceptor architecture, dynamic dependency
resolutions, etc) it makes no sense whatsoever for me to get involved
and do coding. I'd be in over my head, and in the way.
But I feel I do have something to offer, like voicing user (and
executive management!) fears wrt ever changing feature sets. I
understand it can be annoying when you finish a few hours of coding and
then hear someone say "but won't it impact backwards compatibility?",
but I think it is still important the question is asked, and answered.
When/if we have a 'complete' set of specs/unit tests/regression tests,
that will happen automatically. We're not there yet so I'll keep moaning
about it from time to time.
> If you don't want
> to see any progress for whatever reason then don't. Simple as that really.
If only it were :)
> ------------------------------------------------------------
> militant agnostic: i don't know, and you don't know either.
> ------------------------------------------------------------
how appropriate :)
cheers,
Leo
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Map and Array Dependencies
Posted by Peter Donald <pe...@apache.org>.
On Tue, 1 Oct 2002 19:57, Leo Simons wrote:
> true. Avalon doesn't offer a convenient way to satisfy all use cases it
> wants to satisfy.
There is no magic bullet and there never will be.
> yup. I don't have a better answer than anyone else to this dilemma. All
> I know is that it would be very nice for me, and I think for many avalon
> users, to have only bugfixes, docs, testing etc for phoenix for like 6
> months or so.
why would we want to hobble Phoenix in that way?
> The answer to questions like the one leading to the changes we're
> talking about now could be "we don't support this directly. Wait until
> phoenix 5 or so or solve at the application level". It's about choosing
> between stability/compatibility and continuous improvement. It seems I'm
> wrong in this particular case, but on a larger scale it is something
> where we need to shift the balance towards stability.
It has already happened. If you have not been taking notice of the commits you
will have missed that this is exactly what is happening. Almost all the work
that is going into Phoenix (and Fortress for that matter) at this stage is
consolidation.
Parts are being extracted and unit tested to a far greater degree than before.
Features that we have been putting off for ages are being added in and unit
tested.
For example we have talked about allowing Map as dependencies since before you
were involved with Avalon - way back when it was just me Berin, Fede and
Stefano. Arrays have been "approved" before but no one ever got around to
implementing them.
The ClassLoader stuff I am implementing atm has been needed for ages and will
allow us to embed Catalina (and/or Jo!) into phoenix cleanly. Something that
has seen some discussion lately on the Phoenix list. It will also allow us to
embed EJBs if one so desires.
After that there will be integration of Installer enhancements (from XML),
then comes Auto-Assembly, factorys that can create Avalon services from
WebServices, exposing kernel components to applications etc.
Finally we will integrate the Info and interceptor architecture combo. This
will allow us to do things that are not possible in any container now
(Avalon, EJB or CORBA) and allow us much more flexibility than ever (and
scarily half the credit for that belongs with Microsoft).
If you think you have something to offer then participate. If you don't want
to see any progress for whatever reason then don't. Simple as that really.
--
Cheers,
Peter Donald
------------------------------------------------------------
militant agnostic: i don't know, and you don't know either.
------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Map and Array Dependencies
Posted by Peter Donald <pe...@apache.org>.
On Tue, 1 Oct 2002 19:57, Leo Simons wrote:
> true. Avalon doesn't offer a convenient way to satisfy all use cases it
> wants to satisfy.
There is no magic bullet and there never will be.
> yup. I don't have a better answer than anyone else to this dilemma. All
> I know is that it would be very nice for me, and I think for many avalon
> users, to have only bugfixes, docs, testing etc for phoenix for like 6
> months or so.
why would we want to hobble Phoenix in that way?
> The answer to questions like the one leading to the changes we're
> talking about now could be "we don't support this directly. Wait until
> phoenix 5 or so or solve at the application level". It's about choosing
> between stability/compatibility and continuous improvement. It seems I'm
> wrong in this particular case, but on a larger scale it is something
> where we need to shift the balance towards stability.
It has already happened. If you have not been taking notice of the commits you
will have missed that this is exactly what is happening. Almost all the work
that is going into Phoenix (and Fortress for that matter) at this stage is
consolidation.
Parts are being extracted and unit tested to a far greater degree than before.
Features that we have been putting off for ages are being added in and unit
tested.
For example we have talked about allowing Map as dependencies since before you
were involved with Avalon - way back when it was just me Berin, Fede and
Stefano. Arrays have been "approved" before but no one ever got around to
implementing them.
The ClassLoader stuff I am implementing atm has been needed for ages and will
allow us to embed Catalina (and/or Jo!) into phoenix cleanly. Something that
has seen some discussion lately on the Phoenix list. It will also allow us to
embed EJBs if one so desires.
After that there will be integration of Installer enhancements (from XML),
then comes Auto-Assembly, factorys that can create Avalon services from
WebServices, exposing kernel components to applications etc.
Finally we will integrate the Info and interceptor architecture combo. This
will allow us to do things that are not possible in any container now
(Avalon, EJB or CORBA) and allow us much more flexibility than ever (and
scarily half the credit for that belongs with Microsoft).
If you think you have something to offer then participate. If you don't want
to see any progress for whatever reason then don't. Simple as that really.
--
Cheers,
Peter Donald
------------------------------------------------------------
militant agnostic: i don't know, and you don't know either.
------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Map and Array Dependencies
Posted by Leo Simons <le...@apache.org>.
On Tue, 2002-10-01 at 11:30, Leo Sutic wrote:
> > From: Leo Simons [mailto:leosimons@apache.org]
>
> > This makes your components (atm)
> > phoenix-specific, it is also the way to a dll-like-hell if we
> > keep adding meaning to core contracts that wasn't there before.
> >
> > What if I have an application deployed in phoenix 4.0 that
> > just happens to postfix about half of its components with
> > "#"? It will break in the next release. Granted, what are the
> > chances....but the thing with contracts is you should be
> > really strict about them.
> >
> > We could do the whole yada-yada on this again....
> >
> > I'm not going to throw a -1 at it because I don't really feel
> > like having to go over exactly the same discussions again. I
> > feel like doing so though.
> >
> > Anyway, it makes me more sure that the only way to have
> > avalon survive is to define that the minimum contracts
> > defined in avalon framework are also the maximum ones........
>
> Yes, but we repeatedly slam into discovering that the
> contracts we specify aren't enough.
>
> Simply put - Avalon as it is is not mature enough to fulfill
> its intended scope.
true. Avalon doesn't offer a convenient way to satisfy all use cases it
wants to satisfy.
There's a tradeoff between stability in a limited set of problem domains
and not supporting all problem domains on the one hand, and unstability
(ie framework 4.2, 4.3, 5, 6, 7....) with increasing support for
different problem domains on the other hand.
> We can keep trying to come up with the ultimate container,
> but since no one of us knows what that container would need
> for a feature set, we keep having diverging implementations
> as each developer tries to solve his own problems.
>
> Good parts: It means that the framework is indeed evolving.
>
> Bad parts: Avalon as a dependency is less attractive.
yup. I don't have a better answer than anyone else to this dilemma. All
I know is that it would be very nice for me, and I think for many avalon
users, to have only bugfixes, docs, testing etc for phoenix for like 6
months or so.
The answer to questions like the one leading to the changes we're
talking about now could be "we don't support this directly. Wait until
phoenix 5 or so or solve at the application level". It's about choosing
between stability/compatibility and continuous improvement. It seems I'm
wrong in this particular case, but on a larger scale it is something
where we need to shift the balance towards stability.
cheers,
Leo Simons
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Map and Array Dependencies
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> From: Leo Simons [mailto:leosimons@apache.org]
>
> On Tue, 2002-10-01 at 10:26, Peter Donald wrote:
> > Any other comments?
>
> This adds additional semantic meaning to the lookup key,
> modifying the sm contract.
No - see Peter's reply to me.
> This makes your components (atm)
> phoenix-specific, it is also the way to a dll-like-hell if we
> keep adding meaning to core contracts that wasn't there before.
>
> What if I have an application deployed in phoenix 4.0 that
> just happens to postfix about half of its components with
> "#"? It will break in the next release. Granted, what are the
> chances....but the thing with contracts is you should be
> really strict about them.
>
> We could do the whole yada-yada on this again....
>
> I'm not going to throw a -1 at it because I don't really feel
> like having to go over exactly the same discussions again. I
> feel like doing so though.
>
> Anyway, it makes me more sure that the only way to have
> avalon survive is to define that the minimum contracts
> defined in avalon framework are also the maximum ones........
Yes, but we repeatedly slam into discovering that the
contracts we specify aren't enough.
Simply put - Avalon as it is is not mature enough to fulfill
its intended scope.
We can keep trying to come up with the ultimate container,
but since no one of us knows what that container would need
for a feature set, we keep having diverging implementations
as each developer tries to solve his own problems.
Good parts: It means that the framework is indeed evolving.
Bad parts: Avalon as a dependency is less attractive.
Again, I think the component portability has to be abandoned
in favor of a JNDI publishing solution with containers that can
export and import components from JNDI in a uniform way. That
would accommodate the current shear we have in interpreting the
contracts.
/LS
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Map and Array Dependencies
Posted by Leo Simons <le...@apache.org>.
On Tue, 2002-10-01 at 10:26, Peter Donald wrote:
> Hi,
>
> I have just added support for complex dependencies in Phoenix so that they can
> either be an array of services or a map of services. To declare an array you
> just postfix it with "[]" and to declare a map you postfix it with "#" in
> xinfo file. And then you can just access it via something like
>
> void service( ServiceManager sm )
> {
> //An array of services
> MyService[] services1 =
> (MyService[])sm.lookup( MyService[].class.getName() );
>
> //Same as above
> MyService[] services2 =
> (MyService[])sm.lookup( MyService.ROLE + "[]" );
>
> //A unmodifiable Map of services
> Map services3 =
> (Map)sm.lookup( MyService.ROLE + "#" );
> }
>
> It seems to work well. However I don't really like the idea of postfixing the
> service with "#" to indicate a map. I have thought about using "{}" instead
> or maybe "<>" - Any preferences?
I like # best.
> Any other comments?
This adds additional semantic meaning to the lookup key, modifying the
sm contract. This makes your components (atm) phoenix-specific, it is
also the way to a dll-like-hell if we keep adding meaning to core
contracts that wasn't there before.
What if I have an application deployed in phoenix 4.0 that just happens
to postfix about half of its components with "#"? It will break in the
next release. Granted, what are the chances....but the thing with
contracts is you should be really strict about them.
We could do the whole yada-yada on this again....
I'm not going to throw a -1 at it because I don't really feel like
having to go over exactly the same discussions again. I feel like doing
so though.
Anyway, it makes me more sure that the only way to have avalon survive
is to define that the minimum contracts defined in avalon framework are
also the maximum ones........
All that said, it does seem like a nice idea that satisfies a particular
need. We just can't do it :S
cheers,
Leo
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Map and Array Dependencies
Posted by Leo Simons <le...@apache.org>.
On Tue, 2002-10-01 at 10:26, Peter Donald wrote:
> Hi,
>
> I have just added support for complex dependencies in Phoenix so that they can
> either be an array of services or a map of services. To declare an array you
> just postfix it with "[]" and to declare a map you postfix it with "#" in
> xinfo file. And then you can just access it via something like
>
> void service( ServiceManager sm )
> {
> //An array of services
> MyService[] services1 =
> (MyService[])sm.lookup( MyService[].class.getName() );
>
> //Same as above
> MyService[] services2 =
> (MyService[])sm.lookup( MyService.ROLE + "[]" );
>
> //A unmodifiable Map of services
> Map services3 =
> (Map)sm.lookup( MyService.ROLE + "#" );
> }
>
> It seems to work well. However I don't really like the idea of postfixing the
> service with "#" to indicate a map. I have thought about using "{}" instead
> or maybe "<>" - Any preferences?
I like # best.
> Any other comments?
This adds additional semantic meaning to the lookup key, modifying the
sm contract. This makes your components (atm) phoenix-specific, it is
also the way to a dll-like-hell if we keep adding meaning to core
contracts that wasn't there before.
What if I have an application deployed in phoenix 4.0 that just happens
to postfix about half of its components with "#"? It will break in the
next release. Granted, what are the chances....but the thing with
contracts is you should be really strict about them.
We could do the whole yada-yada on this again....
I'm not going to throw a -1 at it because I don't really feel like
having to go over exactly the same discussions again. I feel like doing
so though.
Anyway, it makes me more sure that the only way to have avalon survive
is to define that the minimum contracts defined in avalon framework are
also the maximum ones........
All that said, it does seem like a nice idea that satisfies a particular
need. We just can't do it :S
cheers,
Leo
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Map and Array Dependencies
Posted by Ugo Cei <u....@cbim.it>.
Peter Donald wrote:
>>Unfortunately, some guys here in Italy and maybe other
>>countries are stuck with Italian keyboards that don't have the { and }
>>keys ;-)
>
>
> are you serious or is that a joke ? ;)
I'm half serious. Actually I'm writing this mail on an Italian keyboard.
Fortunately, under Linux, I can use AltGr+7 and AltGr+0 to type braces,
and don't have to use Alt+1,2,3 and Alt+1,2,5.
I can assure you that finding a laptop with a US keyboard in Italy is
next to impossible.
Ugo
--
Ugo Cei - http://www.beblogging.com/blog/
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Map and Array Dependencies
Posted by Peter Donald <pe...@apache.org>.
On Tue, 1 Oct 2002 22:22, Ugo Cei wrote:
> Peter Donald wrote:
> > It seems to work well. However I don't really like the idea of postfixing
> > the service with "#" to indicate a map. I have thought about using "{}"
> > instead or maybe "<>" - Any preferences?
>
> {} is used in Perl to denote associative arrays (i.e. maps), so I'd
> prefer it.
works for me.
> Unfortunately, some guys here in Italy and maybe other
> countries are stuck with Italian keyboards that don't have the { and }
> keys ;-)
are you serious or is that a joke ? ;)
--
Cheers,
Peter Donald
-----------------------------------------------
"You can't depend on your eyes when your
imagination is out of focus." -Mark Twain
-----------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Map and Array Dependencies
Posted by Ugo Cei <u....@cbim.it>.
Peter Donald wrote:
> It seems to work well. However I don't really like the idea of postfixing the
> service with "#" to indicate a map. I have thought about using "{}" instead
> or maybe "<>" - Any preferences?
{} is used in Perl to denote associative arrays (i.e. maps), so I'd
prefer it. Unfortunately, some guys here in Italy and maybe other
countries are stuck with Italian keyboards that don't have the { and }
keys ;-)
Ugo
--
Ugo Cei - http://www.beblogging.com/blog/
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Map and Array Dependencies
Posted by Stephen McConnell <mc...@apache.org>.
Berin Loritsch wrote:
> Leo Sutic wrote:
>
>>
>>> From: Peter Donald [mailto:peter@apache.org]
>>> Hi,
>>
>
>> ---------------------- Alt 2
>>
>> I think that the use of the postfix magic character(s), # and [], in the
>> lookup() call *must* go, since they imply that the returned type (map or
>> array or object) isn't part of the role, but can be determined at
>> runtime.
>>
>> Let the role string, when used in the lookup() call, remain an opaque
>> string.
>>
>> I should be able to do:
>>
>> MyService[] services2 =
>> (MyService[])sm.lookup( "incoming-queues" );
>>
>> MyService[] services3 =
>> (MyService[])sm.lookup( "outgoing-queues" );
>>
>>
>> To return to your example:
>>
>> <dependencies>
>> <dependency>
>> <service name="org.apache.MyService[]"/>
>> </dependency>
>> </dependencies>
>>
>> +1 - this means that I have a dependency on an array of MyService.
>
>
>
> Concidering that someone (I think it was Stephen) greatly opposed the
> semantic of "Selector" to refer to a Service/Component Selector, adding
> in additional constraints on the meaning of a lookup key is not a good
> idea.
It was (and my opinion hasn't changed).
>
> I am missing a large part of the conversation, so I am not sure what
> problem the solution is for. I believe it was Peter D. that suggested
> writing an XXXManager for any specific set of components that fulfilled
> the same role. That provides the maximum amount of flexibility in
> lifecycle and convenience methods.
>
> I really would like to avoid any more sementics on the lookup key.
Me too.
Cheers, Steve.
>
> As to the example above, the SEDA solution would never require you to
> lookup multiple incoming queues. Instead, the EventPipeline would
> automatically gather the events from the different Queues and place
> them into the EventHandler for the Stage. The Stage would then use
> a SinkMap to send the outgoing events to the proper location.
>
> I think that is a much nicer solution than looking up the incoming
> queues explicitly, and then looking up the outgoing queues and routing
> events in that way.
>
>
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Map and Array Dependencies
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> -----Original Message-----
> From: Berin Loritsch [mailto:bloritsch@apache.org]
> Sent: den 1 oktober 2002 14:39
> To: Avalon Developers List
> Subject: Re: Map and Array Dependencies
>
>
> Leo Sutic wrote:
> >
> >>From: Peter Donald [mailto:peter@apache.org]
> >>
> >>Hi,
>
> > ---------------------- Alt 2
> >
> > I think that the use of the postfix magic character(s), #
> and [], in
> > the
> > lookup() call *must* go, since they imply that the returned
> type (map or
> > array or object) isn't part of the role, but can be determined at
> > runtime.
> >
> > Let the role string, when used in the lookup() call, remain
> an opaque
> > string.
> >
> > I should be able to do:
> >
> > MyService[] services2 =
> > (MyService[])sm.lookup( "incoming-queues" );
> >
> > MyService[] services3 =
> > (MyService[])sm.lookup( "outgoing-queues" );
> >
> >
> > To return to your example:
> >
> > <dependencies>
> > <dependency>
> > <service name="org.apache.MyService[]"/>
> > </dependency>
> > </dependencies>
> >
> > +1 - this means that I have a dependency on an array of MyService.
>
>
> Concidering that someone (I think it was Stephen) greatly
> opposed the semantic of "Selector" to refer to a
> Service/Component Selector, adding in additional constraints
> on the meaning of a lookup key is not a good idea.
We're not. I thought we were, but we're not.
> I am missing a large part of the conversation, so I am not
> sure what problem the solution is for.
http://marc.theaimsgroup.com/?l=avalon-dev&m=103346011218360&w=2
> I believe it was
> Peter D. that suggested writing an XXXManager for any
> specific set of components that fulfilled the same role.
> That provides the maximum amount of flexibility in lifecycle
> and convenience methods.
I think the gain outweighs the cost in this case. We're not adding
any semantics to the lookup key, only semantics to the dependency
declaration (which is decoupled from the lookup key).
As you, I have no immediate problem for this to solve, but
apparently someone has, and since the cost of adding this is zero,
I don't see why not.
/LS
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Map and Array Dependencies
Posted by Berin Loritsch <bl...@apache.org>.
Leo Sutic wrote:
>
>>From: Peter Donald [mailto:peter@apache.org]
>>
>>Hi,
> ---------------------- Alt 2
>
> I think that the use of the postfix magic character(s), # and [], in the
> lookup() call *must* go, since they imply that the returned type (map or
> array or object) isn't part of the role, but can be determined at
> runtime.
>
> Let the role string, when used in the lookup() call, remain an opaque
> string.
>
> I should be able to do:
>
> MyService[] services2 =
> (MyService[])sm.lookup( "incoming-queues" );
>
> MyService[] services3 =
> (MyService[])sm.lookup( "outgoing-queues" );
>
>
> To return to your example:
>
> <dependencies>
> <dependency>
> <service name="org.apache.MyService[]"/>
> </dependency>
> </dependencies>
>
> +1 - this means that I have a dependency on an array of MyService.
Concidering that someone (I think it was Stephen) greatly opposed the
semantic of "Selector" to refer to a Service/Component Selector, adding
in additional constraints on the meaning of a lookup key is not a good
idea.
I am missing a large part of the conversation, so I am not sure what
problem the solution is for. I believe it was Peter D. that suggested
writing an XXXManager for any specific set of components that fulfilled
the same role. That provides the maximum amount of flexibility in
lifecycle and convenience methods.
I really would like to avoid any more sementics on the lookup key.
As to the example above, the SEDA solution would never require you to
lookup multiple incoming queues. Instead, the EventPipeline would
automatically gather the events from the different Queues and place
them into the EventHandler for the Stage. The Stage would then use
a SinkMap to send the outgoing events to the proper location.
I think that is a much nicer solution than looking up the incoming
queues explicitly, and then looking up the outgoing queues and routing
events in that way.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Map and Array Dependencies
Posted by Peter Donald <pe...@apache.org>.
On Tue, 1 Oct 2002 18:50, Leo Sutic wrote:
> # is fine. Besides having the best smiley, # is called "hash",
> and associates to HashMap for me.
that was my logic aswell ;)
> If this type of lookup behavior is part of framework, then maybe the
> correct solution is to add methods to the ServiceManager interface.
>
> MyService.ROLE + "[]" --> ServiceManager.lookupAll (String role);
> MyService.ROLE + "#" --> ServiceManager.lookupMap (String role);
>
> Ignoring backwards compatibility here.
Theres quite a few things I would like to do if it weren't for backwards
compatability and this may be one of them ;)
> ---------------------- Alt 2
>
> I think that the use of the postfix magic character(s), # and [], in the
> lookup() call *must* go, since they imply that the returned type (map or
> array or object) isn't part of the role, but can be determined at
> runtime.
My mistake. "#" and "[]" and postfixed to the type. If no role is specified
then it will default to the type but you can still remap it via something
like;
<dependencies>
<dependency>
<role>incoming-queues</role>
<service name="org.apache.MyService#"/>
</dependency>
</dependencies>
However if no role is specified it will default to the type (much like in
normal case).
--
Cheers,
Peter Donald
------------------------------------
The two secrets to success:
1- Don't tell anyone everything.
------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Map and Array Dependencies
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> From: Peter Donald [mailto:peter@apache.org]
>
> Hi,
>
> I have just added support for complex dependencies in Phoenix
> so that they can
> either be an array of services or a map of services. To
> declare an array you
> just postfix it with "[]" and to declare a map you postfix it
> with "#" in
> xinfo file. And then you can just access it via something like
>
> void service( ServiceManager sm )
> {
> //An array of services
> MyService[] services1 =
> (MyService[])sm.lookup( MyService[].class.getName() );
>
> //Same as above
> MyService[] services2 =
> (MyService[])sm.lookup( MyService.ROLE + "[]" );
>
> //A unmodifiable Map of services
> Map services3 =
> (Map)sm.lookup( MyService.ROLE + "#" );
> }
>
> It seems to work well. However I don't really like the idea
> of postfixing the
> service with "#" to indicate a map.
Hmmm... :-# ... :-{} ... :-<> ...
# is fine. Besides having the best smiley, # is called "hash",
and associates to HashMap for me.
> I have thought about
> using "{}" instead
> or maybe "<>" - Any preferences?
>
> Any other comments?
If this type of lookup behavior is part of framework, then maybe the
correct solution is to add methods to the ServiceManager interface.
MyService.ROLE + "[]" --> ServiceManager.lookupAll (String role);
MyService.ROLE + "#" --> ServiceManager.lookupMap (String role);
Ignoring backwards compatibility here. But say that lookupAll can be
defined
as
new Object[] { lookup (role - "[]") };
That is, for containers not supporting this naming scheme, the [] is
ignored.
Same for map - a singleton map is returned with the component mapped to
the
null key.
---------------------- Alt 2
I think that the use of the postfix magic character(s), # and [], in the
lookup() call *must* go, since they imply that the returned type (map or
array or object) isn't part of the role, but can be determined at
runtime.
Let the role string, when used in the lookup() call, remain an opaque
string.
I should be able to do:
MyService[] services2 =
(MyService[])sm.lookup( "incoming-queues" );
MyService[] services3 =
(MyService[])sm.lookup( "outgoing-queues" );
To return to your example:
<dependencies>
<dependency>
<service name="org.apache.MyService[]"/>
</dependency>
</dependencies>
+1 - this means that I have a dependency on an array of MyService.
void service( ServiceManager sm )
{
Service[] services = (Service[])sm.lookup( Service[].class.getName()
);
//use returned services here
}
NO. The [] should not be in the lookup. What if I use
Service.class.getName() + "#"
here instead? Do I get a map? Suddenly, you have dependency information
creeping back into the code and away from the xinfo.
<block class="org.apache.MyComponent" name="myComp">
<provide name="service1" role="org.apache.MyService[]"/> <provide
name="service2" role="org.apache.MyService[]"/> <provide
name="service3" role="org.apache.MyService[]"/> </block>
+1 - Fine, cool.
/LS
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>