On Thu, 5 Dec 2002 06:43 am, Darrell DeBoer wrote: > This example is giving me a few troubles: > > > getServletContext().isPrincipleInRole( String role, Principle p ); > > > getSessionContext().isCallerInRole( String role ); > > These are container provided services, and it would "feel" right that they > would be split out from the provision of other services. But then you > realise: - these interfaces are defined as part of a specification. The > container can't choose whether or not to provides these things, they are > required. And the container can't arbitrarily provide new stuff in this > way, since then a component would become non-portable. > > So I can't see the argument for the Container-provided/Peer-provided > divide. But I can see an argument for a logical and code separation of > services defined in the spec (and therefore part of the Avalon-Framework > contracts), and other services (both container and peer).
This is pretty much my view, too. To separate out resources that are modelled in framework is useful. To separate out resources that are not modelled in framework is pointless. > At the moment, I don't think any such services exist. Maybe we should come > up with some, and *maybe* they should be provided in a separate mechanism > to regular services. But since they are part of the spec, components won't > need to "declare" the context they require It would be really handy to have some framework-level cross-container services that allow better interaction with the container. This is possibly the missing piece that we're struggling with. One problem is that it doesn't take long before you hit avalon's enormous scope. It's difficult (impossible?) to come up with a useful set of mandatory services that will span this scope. Even the canonical getHomeDir() example is a problem for lightweight containers with no such concept, or tightly sandboxed containers that don't (or can't) allow file system access. So whatever we come up with will have to be optional. And ideally more strongly-typed than: (ApplicationDeployer)context; or (ApplicationDeployer)context.get( ApplicationDeployer.ROLE ); or (ApplicationDeployer)serviceManager.lookup( ApplicationDeployer.ROLE ); There are heaps of options: (note: below, 'these services' means 'those services defined by framework, which the container supports', not 'any arbitrary services'): 1. Don't bother. 2. Deliver these services via Context.get(). 3. Deliver these services via ServiceManager.lookup(). 4. Deliver these services via a ServiceManager equivalent and a new lifecycle stage. Eg the ContainerServiceable that Gary suggested. 5. Deliver each of these services via a new lifecycle stage. Eg DeployerEnabled.deloyerEnable( Deployer ), ShutdownEnabled.shutdownEnable( ShutdownRequester ), etc. 6. Deliver each of these services via a typed getter on Context. Eg Context.getApplicationDeployer(), Context.getShutdownRequester(). 7. Any of the above, on a per-service basis. Again, I'm only talking about services that are defined by framework, not container-specific services. > things like MailetContext > and ServletContext are removed from these arguments, since they aren't part > of the Avalon-Framework contracts. Honestly, MailetContext and ServletContext were always just noise. There's nothing in common between these and framework's Context except the word 'Context' in their names, and the fact that they each deliver a subset of the resources used by components. -- Adam -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
