On Tue, 2003-07-08 at 17:40, Stephen McConnell wrote: > I would like to propose the following as a standard set of context entry > name. These names deal with the context entry names that componets > should use (i.e. I'm not thinking about container side context keys). > > urn:avalon:partition.name -- the partition name in merlin and > the application name in Phoenix > urn:avalon:name -- the deployment scenario name (i.e. > for a singleton this is the component > name or block.name in Phoenix, for other > lifestyles, the name may not be unique > across component instances, but the name > is unique within a single containment > scope) > urn:avalon:home.dir -- a directory that a container > can gaurantee to make available > across JVM sessions (unique per > component that requests it) > urn:avalon:temp.dir -- a directory that is made available > to a component and will be destroy > on JVM termination (unique per > component that requests it) > urn:avalon:classloader -- a classloader for the component > (may not contain any containment > classes)
This would cover almost everything. I'm not sure what the partition.name would be for Fortress though. The only things not covered which Phoenix's BlockContext provide are: getResourceAsStream(String) requestShutdown() and I'm not certain these should be in the context anyway. > > > > >And why is there no way to get a list of all context values from the Context > >interface? All we have is get(Object key). > > > > The component declares what it needs in meta. This encorages good SOC > bacause the component implementation cannot do navigation or discovery - > if it needs something it has to say what it needs and the container has > to deal with the supply. Understood. However, currently there isn't a consistent way for containers to provide these dependencies. Perhaps this would be a good spot for assembly/container events. For example, in the servlet spec, you have ServletContextListener. What about an AvalonContextListener? Listeners would have a chance to update or modify the Context before it's passed to any services, blocks, components, etc. There might be creation listeners or access listeners. For example, in addition to adding simple configuration values to the Context, you could map a JNDI InitialContext or ServletContext into the Avalon Context. Just brainstorming at the moment. -- jaaron <http://jadetower.org> --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
