> From: Noel J. Bergman [mailto:[EMAIL PROTECTED]] > > 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.
Startup and shutdown services are *bad* and invite abuse. Exposing too many services is not a good thing. Keep in mind that we can view certain services such as getResource(), and getPhysicalDirectory() in Servlets as a way to provide a namespace to an underlying data structure like a directory. > > 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. The Context should have a values that represent something concrete. Things like File, ClassLoader, String, Integer, Boolean, URL, etc. I would limit it to objects which are included in the JDK. We cannot guarantee access of user defined objects accross containers. > 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. Any "object" that fits the definition of a component is a Service. That means it has the following qualifications: 1) It must have a no argument constructor (like all components/beans etc.) 2) It must have a separate work interface 3) It needs lifecycle support Any service needs to be accessed through the ServiceManager. In Avalon 5 we can revisit if there needs to be any real distinction between them. > 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. -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
