This would require the key to be an object containing both the name and the
elementType. I believe this would also allow plugins with the same name to be
both a Filter and an Appender or Layout as well. To be honest, it probably
would be nicer if elementType could default to the type attribute, but that is
not possible since default values on annotations must be constants.
Ralph
On Mar 13, 2013, at 10:52 PM, Scott Deboy wrote:
> After working through the 'left out to attempt to get around spam blocker'
> plugin support, I noticed something that I think may be an issue.
>
> I have a default/no-op 'left out' implementation:
> @Plugin(name = "default", type = "Core", elementType = "left out",
> printObject = false)
> public class DefaultLeftOut implements LeftOut {
>
> If some other person names another plugin as 'default' in 'core' (admittedly
> default is a terrible name and I should rename it)...we will have a problem.
>
> I think the element type should be part of the resolution..
>
> Still using:
> PluginManager pluginManager = new PluginManager("Core");
> pluginManager.collectPlugins();
>
> But instead of code using:
> PluginType type = getPluginManager().getPluginType(name);
> (with name = 'default' in this LeftOut case, giving me a DefaultLeftOut)
>
> Maybe:
> PluginType type = getPluginmanager().getPluginType(elementType, name);
> (with elementType = 'leftOut' and name = 'default' in this leftOut case)
>
> In theory, we should also update the Maps in pluginmanager to support this
> uniqueness...right now we collide just on 'name' in the type.
>
> Right now, the last one wins, which isn't ideal.
>
> At least we'd reduce the likelihood of collisions.
>
> What do you think?
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
