After sleeping on this overnight I think we should remove the default on the
elementType and just require it to be specified. Having an elementType of
"EMPTY" is going to create problems when trying to use the compound key
necessary to do what you are suggesting below.
Ralph
On Mar 14, 2013, at 12:15 AM, Ralph Goers wrote:
> 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]
