I've found a solution (the code is very draft, it is just to proof an
idea).
class PluginConfigInstaller : IWindsorInstaller, IInterceptor
{
private readonly IEnumerable<string> _componentIds;
private readonly IResource _resource;
public PluginConfigInstaller(IResource resource,
IEnumerable<string> componentIds)
{
_componentIds = componentIds;
_resource=resource;
}
public void Install(IWindsorContainer container,
IConfigurationStore store)
{
var generator = new ProxyGenerator();
var proxy =
generator.CreateInterfaceProxyWithTargetInterface(store, this);
var interpreter = new XmlInterpreter(_resource);
interpreter.ProcessResource(_resource,proxy);
proxy.AddFacilityConfiguration();
}
public void Intercept(IInvocation invocation)
{
bool validCall = true;
if (invocation.Method.Name == "AddFacilityConfiguration")
validCall=false;
if(invocation.Method.Name == "AddComponentConfiguration")
{
var conf = invocation.GetArgumentValue(1) as
IConfiguration;
validCall =
_componentIds.Contains(conf.Attributes["id"]);
}
if(validCall)
invocation.Proceed();
}
}
PluginConfigInstaller wraps the IConfigurationStore and prevents
calls to AddFacilityConfiguration and allows
AddComponentConfiguration only for components with id from
componentIds list provided in ctor.
On Mar 25, 4:00 pm, Jason Meckley <[email protected]> wrote:
> 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.
