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.
