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.
