You are viewing a plain text version of this content. The canonical link for it is here.
Posted to log4j-dev@logging.apache.org by "Scott Deboy (JIRA)" <ji...@apache.org> on 2013/04/08 06:43:17 UTC
[jira] [Updated] (LOG4J2-191) Improve plugin uniqueness by name and
type, not just name
[ https://issues.apache.org/jira/browse/LOG4J2-191?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Scott Deboy updated LOG4J2-191:
-------------------------------
Description:
I have a default/no-op 'advertiser' implementation:
@Plugin(name = "default", type = "Core", elementType = "advertiser", printObject = false)
public class DefaultLeftOut implements Advertiser {
If some other person names another plugin as 'default' in core or even under a different 'type' (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 Advertiser case, giving me a DefaultAdvertiser)
Maybe:
PluginType type = getPluginmanager().getPluginType(elementType, name);
(with elementType = 'advertiser' and name = 'default' in this advertiser 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.
Along with passing in type type and name in the lookup, collisions of name and type (another 'default' in 'core') should be logged at warn level. I suppose last one registered should still win.
was:
I have a default/no-op 'advertiser' implementation:
@Plugin(name = "default", type = "Core", elementType = "advertiser", printObject = false)
public class DefaultLeftOut implements Advertiser {
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 Advertiser case, giving me a DefaultAdvertiser)
Maybe:
PluginType type = getPluginmanager().getPluginType(elementType, name);
(with elementType = 'advertiser' and name = 'default' in this advertiser 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.
> Improve plugin uniqueness by name and type, not just name
> ---------------------------------------------------------
>
> Key: LOG4J2-191
> URL: https://issues.apache.org/jira/browse/LOG4J2-191
> Project: Log4j 2
> Issue Type: Bug
> Reporter: Scott Deboy
>
> I have a default/no-op 'advertiser' implementation:
> @Plugin(name = "default", type = "Core", elementType = "advertiser", printObject = false)
> public class DefaultLeftOut implements Advertiser {
> If some other person names another plugin as 'default' in core or even under a different 'type' (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 Advertiser case, giving me a DefaultAdvertiser)
> Maybe:
> PluginType type = getPluginmanager().getPluginType(elementType, name);
> (with elementType = 'advertiser' and name = 'default' in this advertiser 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.
> Along with passing in type type and name in the lookup, collisions of name and type (another 'default' in 'core') should be logged at warn level. I suppose last one registered should still win.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org