On Wed, 4 Dec 2002 11:07, Adam Murdoch wrote: > These are useful things, no question. Components need some way to get at > data and services that are supplied by the container. Again, why do they > care that a particular service or piece of data was supplied by the > container or a peer?
Components don't care what the origins of the resource are - all of it is potentially "contextualized" on a per component basis and all generally has certain criteria to adhere to but beyond that it is about it. The different resources are separated out for the sake of humans and no other reason. Context is separated from ServiceManager because humans see them as different things - especially during the assembly process. > Yes, I know that they're "different logical things". But so are, say, > authentication services and persistence services. We don't use different > mechanisms to deliver those services to components. It would be pointless > to do so: I disagree. If persistence were provided to the component and the component was effectively made to be an OJB object or something like that then we would likely provide persistence/transaction capabilities in a very different manner. Most likely via some transparent EJB-like manner. In the same way if AAA services were provided to a component as part of it's environment then it would likely also follow an EJB/Servlet style setup where the container does it via interception and allows components to access it programatically via something like getServletContext().isPrincipleInRole( String role, Principle p ); getSessionContext().isCallerInRole( String role ); (or insert real examples here or JAAS). If the services are things that the container provides to the component as part of it's environment then the user perceives them as different to services that the component uses. I can't think of one API that actually merges the two concepts. When we tried to merge the two things together the primary reason we separated them out again was because of user complaints. ie If a resources requires resources A, B and C and C is container provided. All three are accessed in the same way so the person sees them as much the same (like the component sees them as much the same). However during assembly they are only required to assemble A and B - which creates a cognitive dissonance because they are treated as identical in one place but different in another. > So which of these cases do you think offer the most benefit to the > component writer? Assume logger, config, params have been split out > already: 1. No separation. > 2. Separate data and services. > 3. Separate container-provided resources and peer-provided resources. +1 > 4. Separate container-provided data, container-provided services, > peer-provided data, and peer-provided services. > 5. Who cares? Why are you bothering me with these questions? :) -- Cheers, Peter Donald *------------------------------------------------* | Those who know how to think need no teachers. | | - Gandhi | *------------------------------------------------* -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
