logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ralph Goers <ralph.go...@dslextreme.com>
Subject Re: Log4j2 plugin resolution
Date Thu, 14 Mar 2013 07:15:44 GMT
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.


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: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org

View raw message