Berin,
I appreciate your view. Please understand my comments in the context of the
discussions between Adam, Stephen, Darrell, Gary, and others related to the
issue of why there is any real difference between Context and
ServiceManager, and what that difference should be, especially from the
perspective of client code. As I see, just before posting this, Adam is
also responding to you with his take on this issue.
So don't take them as defining what it is, but my view of what it should be.
And then we can debate over our differing views, which is fine.
> I see a Context as a PROVIDER of DATA.
That isn't the case already with Phoenix. That isn't the case for any other
notion of Context in any similar area of Java programming. I'll get to my
personal view of why "container as provider of data" is wrong at the end of
this message.
> I dislike using the COntext to provide services
Why? Again, ServletContext and others all provide services.
> The ServiceManager is used to provide a NAMING SERVICE for
> SERVICES (AKA components).
I understand. We agree on the ServiceManager. The issue is how it differs
from the Context, and why.
Here is my abstract view. There are only objects. Objects have methods,
which return value and/or affect change. Some objects may be lightweight,
some objects may be heavyweight. Some objects may be provided by the
container, some may be registered. Some objects may have their own
lifecycle needs, some objects don't. Some objects may be specific to a
particular context, some objects may be shared across all contexts. Some
objects are available early in a component's lifecycle, some aren't
available until later in the component's lifecycle.
The only thing that the component cares about is that it can bind to those
objects that it needs at the proper time throughout its lifecycle.
--- Noel
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
