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 <sc...@gmail.com> on 2013/03/14 06:52:06 UTC
Log4j2 plugin resolution
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?
Re: Log4j2 plugin resolution
Posted by Ralph Goers <ra...@dslextreme.com>.
Go ahead and create a Jira issue.
I have a enhancement to the Flume Appender that I have to do for $work but after I get that complete I plan to look at the defects. I really want to look at the async stuff Remko did and I know there are a few bugs reported that should be easy fixes. And I need to help Scott with his plugin.
Ralph
On Mar 14, 2013, at 10:41 AM, Scott Deboy wrote:
> Want me to file a bug then? I could probably work on this if you don't have cycles...but since you're the expert in this area, I would defer to you..you probably have stronger opinions on how things should be named than I do.
>
> Scott
>
>
> On Thu, Mar 14, 2013 at 10:23 AM, Ralph Goers <ra...@dslextreme.com> wrote:
> 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: log4j-dev-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>
>
Re: Log4j2 plugin resolution
Posted by Scott Deboy <sc...@gmail.com>.
Want me to file a bug then? I could probably work on this if you don't have
cycles...but since you're the expert in this area, I would defer to
you..you probably have stronger opinions on how things should be named than
I do.
Scott
On Thu, Mar 14, 2013 at 10:23 AM, Ralph Goers <ra...@dslextreme.com>wrote:
> 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: log4j-dev-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>
>
Re: Log4j2 plugin resolution
Posted by Ralph Goers <ra...@dslextreme.com>.
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: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: Log4j2 plugin resolution
Posted by Ralph Goers <ra...@dslextreme.com>.
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: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org