windsor xml configuration is designed to configure how the container operates. it sound's like you want to define how a single plug-in operates. For that I would use a custom configuration handler. similar to how Monorail has it's own configuration section independent of windsor. This will give you full control over how a plug-in is processed. Something else to consider: who will be writing the plug-in configuration? This will drive the design of how to configure & process the plug-in installation.
On Mar 25, 8:18 am, Krzysztof Koźmic (2) <[email protected]> wrote: > Notice you can unregister component only if no other component depends > on it. > Also there's no way to unregister a facility, that's why if you want > to safely > 'test' what a plugin provides, an additional test container seems to > be the way to go. > > On 25 Mar, 12:59, Konstantin <[email protected]> wrote: > > > I do not like to reject plugins. The purpose is to reuse castle > > configuration system but limit the scope that can be configured. > > Plugin config should contain only components configurations and > > properties anything else should be ignored. > > Plugin contains implementation of some interface lets call it > > IPluginInstaller (i decided to avoid using IWindsorInstaller to > > prevent facility registrations and other unwanted at this pint > > features) which is instantiated and requested for the list of the > > components. Plugin config contains only configuration for these > > components (connection strings,timeouts etc and assignments of core > > components to be pushed to ctor e.g. ${core.DataBus} ). Any > > configuration for component that was not returned by IPluginInstaller > > should be ignored , facilities registrations should be ignored etc. > > > >Container's events are actually not hacky - most facilities (incl. > > > these comming out of the box) > > subscribe to, and act upon container events. > > > Yes, but subscribe -> process config -> unsubscribe is hacky to my > > mind. > > > >There's no way to reject registration of component AFAIR > > > Immediate unregister will do the thing I guess :) > > > On Mar 25, 11:53 am, Krzysztof Koźmic (2) <[email protected]> wrote: > > > > Konstantin, > > > > That's an interesting problem :) > > > What do you want to do when a plugin containing invalid configuration > > > is registered? > > > Container's events are actually not hacky - most facilities (incl. > > > these comming out of the box) > > > subscribe to, and act upon container events. > > > There's no way to reject registration of component AFAIR (although > > > that might be not such a bad idea - perhaps it should be added to > > > uservoice?) > > > but if you want not to allow the app to work any further, you may > > > simply throw an exception at that point. > > > > If you want to play safe, and reject plugins that don't obey your > > > rules while you might try another approach. > > > > Create another container, register the plugin in it, if everything is > > > fine, none of your rules were broken, than its safe to register it > > > with main container, > > > if not, you will probably log it, or show some message to the user, > > > but your main container will never have been reached by the plugin. > > > > On 25 Mar, 07:37, Konstantin <[email protected]> wrote: > > > > > Yep, I've thought about it. It is posiible to subscribe for event > > > > before installing new configuration and tailor it as flow of component > > > > registrations and unsubscribe ufter conf is loaded. > > > > But this approach is more likely a dirty hack then honest solution. > > > > Other solution that i can think about is applying xslt befor loading > > > > xml configuration, but it also looks dirty. > > > > What i was asking about is some logic in windsor configuration able to > > > > handle such filtering. > > > > > On 25 мар, 00:36, Tuna Toksoz <[email protected]> wrote: > > > > > > There is ComponentRegistering event in microkernel but not sure about > > > > > facilities. > > > > > > Tuna Toksöz > > > > > Eternal sunshine of the open source mind. > > > > > >http://devlicio.us/blogs/tuna_toksozhttp://tunatoksoz.comhttp://twitt... > > > > > > On Wed, Mar 24, 2010 at 5:44 PM, Konstantin > > > > > <[email protected]>wrote: > > > > > > > I'm building application extensibility model on top of Windsor. Each > > > > > > plugin has it's own config file and IWindsorInstaller > > > > > > implementation. > > > > > > When loading plugin the config file is processed with XmlInterpreter > > > > > > and installed to container then the plugin IWindsorInstaller > > > > > > implementation is installed. > > > > > > > I need to limit the registrations loaded from plugin configuration > > > > > > file. e.g. Facilities should not be registered, all defined > > > > > > components > > > > > > should belong to plugin assembly etc. > > > > > > > Is it feasible with windsor? > > > > > > > -- > > > > > > You received this message because you are subscribed to the Google > > > > > > Groups > > > > > > "Castle Project Users" group. > > > > > > To post to this group, send email to > > > > > > [email protected] > > > > > > . > > > > > > To unsubscribe from this group, send email to > > > > > > [email protected]<castle-project-users%2Bun > > > > > > [email protected]> > > > > > > . > > > > > > For more options, visit this group at > > > > > >http://groups.google.com/group/castle-project-users?hl=en. -- You received this message because you are subscribed to the Google Groups "Castle Project Users" 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/castle-project-users?hl=en.
