On Oct 29, 11:18 pm, John Hampton <[EMAIL PROTECTED]> wrote: > I apologize if this message doesn't really fit, but hopefully this info > helps. > > First, logging is a feature of the Environment Component Manager, not of > Component Manager itself. Take a look at: > > http://trac.edgewall.org/browser/trunk/trac/env.py#L203 > > and > > http://trac.edgewall.org/browser/trunk/trac/core.py#L210 > > Second, due to this, Environment is the only component manager used in > Trac. I agree with Noah, osimons, and Remy, that if you're > instantiating you own ComponentManager object, then you're doing it wrong. > > Why is it that you need another ComponentManager?
Because I need any ComponentManager to instantiate my EP provider. It was unclear why EP should be instantiated with Environment component manager if I need my plugin to receive environment properties (including logging interface). I thought that Environment is responsible for instantiating plugin components placed in its plugins/ directory. It seemed that Environment should maintain the registry of plugged components. It is said that Components are singletones from within ComponentManager, so they are isolated inside the environment, but there are some nuances. In reality even if components are isolated within managers - interfaces are still global. When plugin/component states that it implements some interface - let's call such component IC (Implementor Component) - this IC is registered in global _registry. _registry is a mapping from global Interface to a list of ICs. Every EPP object contains property that allows to get a list of ICs supporting some EP from registry. EPP defines a class variable like: extensions = ExtensionPoint(InterfaceClass) which is a property. Attempt to read extensions variable results in a query to _registry for a list of components. These components then called as needed. The thing that goes unnoticed here is that query is made to the Component Manager of EPP and the returned list contains IC components from this particular Manager. If there is no IC component inside CM - it will be created by it. My mistake was to assume that Components are able to call each other interfaces regardless of the CM they were created with. This was a false assumption, so when you design a plugin with IC that relies on some Component Manager features (such as logging) - you need to make sure that your EPP is instantiated from within that CM. So when writing plugin for Trac component model you need to be aware of the ComponentManager for your ExtensionPoint. It might not be actual for Trac, which has only one CM called Environment, but it would be interesting to see how this Component subsystem can be enhanced and applied in larger systems. Components are isolated from each other in ComponentManagers, so that the state within CM is shared and preserved among the same set of components. It is not very convenient to think that EPP defines in which Manager IC will appear, but it is acceptable. The intention is somehow clear, although it is interesting if it was an organic architecture or there was some reasoning among several variants. Another question - why Environment object is passed by chain from one piece of code to another? Why not to make Environment object a singleton for Trac and return it if called without parameters. Is there a scenario when several Environments objects are used simultaneously in Trac so that one env object passed is different from another? Even if there are such scenarios - would it be better to provide a single global object to manage Environments by id (path) rather than making env obj a skewer? -- WBR, anatoli --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Trac Development" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/trac-dev?hl=en -~----------~----~----~----~------~----~------~--~---
