Re: Getter method for retrieving the attributes of an appender from the LoggerContext

[Remko Popma]

I agree. 
It seems like we're preparing to do a lot of work to essentially enable users 
to duplicate our unit tests...

Sent from my iPhone

> On 2016/01/28, at 0:44, Mikael Ståldal  wrote:
> 
> OK, then the keeping config nodes approach might not be a good idea.
> 
> However, I still don't think that the benefit of being able to inspect
> appender's config justifies the cost of increasing the complexity of every
> appender (including future ones and 3rd party plugins).
> 
> On Wed, Jan 27, 2016 at 4:22 PM, Apostolis Giannakidis <
> ap.giannaki...@gmail.com> wrote:
> 
>> One use case that I have at hand at the moment is that I want to be able
>> to verify that my appenders have the expected configuration attributes. For
>> example, I would like to be able to verify that my syslog appender is
>> connecting to the expected host,port,protocol, etc.
>> 
>> On Wed, Jan 27, 2016 at 3:19 PM, Mikael Ståldal >> wrote:
>> 
>>> It would be useful if Apostolis Giannakidis can explain the use case
>>> behind this request, now it is a bit abstract to me.
>>> 
 On Wed, Jan 27, 2016 at 4:13 PM, Matt Sicker  wrote:
 
 I mean keeping the Node tree to get attributes. It would only work from
 config files (and the config builder classes). We get questions every so
 often about modifying the config programmatically which would either need
 to maintain more Nodes or just be unsupported.
 
 On 27 January 2016 at 09:09, Mikael Ståldal 
 wrote:
 
> I don't quite understand what you mean.
> 
>> On Wed, Jan 27, 2016 at 4:02 PM, Matt Sicker  wrote:
>> 
>> That sounds a little fragile as some people either create or modify
 their
>> creation directly from the plugin factories.
>> 
>> On 27 January 2016 at 07:05, Mikael Ståldal <
 mikael.stal...@magine.com>
>> wrote:
>> 
>>> Then perhaps we should keep the node tree and expose it for this
 kind
> of
>>> queries, something like this:
>>> 
>>> String hostname = loggerContext.getConfiguration().
>>> getAttributesForAppender("syslogAppender").get("host");
>>> 
>>> This would require a new method in
>>> org.apache.logging.log4j.core.config.Configuration:
>>> 
>>> public Map getAttributesForAppender(String
> appenderName);
>>> 
>>> 
>>> 
>>> On Wed, Jan 27, 2016 at 1:27 PM, Ralph Goers <
> ralph.go...@dslextreme.com
>>> 
>>> wrote:
>>> 
 While I understand your point, the node tree is discarded after
 the
 plugins are created. We would have to keep it around for this to
> work.
 Furthermore, each component would need to have a reference to its
 corresponding node, which we obviously don't currently do.
 
 Ralph
 
> On Jan 27, 2016, at 2:33 AM, Mikael Ståldal <
>> mikael.stal...@magine.com
 
 wrote:
> 
> To me it does not seems good to force all Appender
 implementations
> to
> implement this. Especially not since the next logical step
 would
> then
>>> be
 to
> do the same with other components such as Layouts. That would
 be a
>> lot
>>> of
> work in total, and also add more work for all future
 components,
 including
> 3rd party plugins.
> 
> I think it makes more sense, and would be less work in total,
 if
> the
> configuration system would store and expose those attributes
> without
> involving the components themselves.
> 
> On Wed, Jan 27, 2016 at 7:14 AM, Gary Gregory <
>> garydgreg...@gmail.com>
> wrote:
> 
>> Apostolis,
>> 
>> You are warmly welcome to contribute to Log4j. You can create
 a
> JIRA
>>> and
>> attach a patch in unified diff file format. Unit tests as
 part of
>> the
 patch
>> are a must IMO. Feel free to flush out any design or
> implementation
 here on
>> the dev ML.
>> 
>> Thank you!
>> Gary
>> 
>> On Tue, Jan 26, 2016 at 5:02 PM, Ralph Goers <
 ralph.go...@dslextreme.com>
>> wrote:
>> 
>>> All the attributes have to have String representations to be
> usable
>>> in
>> the
>>> XML, JSON & Properties configurations. Yes, the Map could
 contain
 Objects
>>> but then every one of them has to be cast to its real object
 to
> be
>> usable.
>>> 
>>> The map should be read-only because modifying its contents
 would
>> have
 no
>>> effect on the appender.
>>> 
>>> The map should not be stored in an ivar but constructed
 whenever

Re: Getter method for retrieving the attributes of an appender from the LoggerContext

[Mikael Ståldal]

OK, then the keeping config nodes approach might not be a good idea.

However, I still don't think that the benefit of being able to inspect
appender's config justifies the cost of increasing the complexity of every
appender (including future ones and 3rd party plugins).

On Wed, Jan 27, 2016 at 4:22 PM, Apostolis Giannakidis <
ap.giannaki...@gmail.com> wrote:

> One use case that I have at hand at the moment is that I want to be able
> to verify that my appenders have the expected configuration attributes. For
> example, I would like to be able to verify that my syslog appender is
> connecting to the expected host,port,protocol, etc.
>
> On Wed, Jan 27, 2016 at 3:19 PM, Mikael Ståldal  > wrote:
>
>> It would be useful if Apostolis Giannakidis can explain the use case
>> behind this request, now it is a bit abstract to me.
>>
>> On Wed, Jan 27, 2016 at 4:13 PM, Matt Sicker  wrote:
>>
>>> I mean keeping the Node tree to get attributes. It would only work from
>>> config files (and the config builder classes). We get questions every so
>>> often about modifying the config programmatically which would either need
>>> to maintain more Nodes or just be unsupported.
>>>
>>> On 27 January 2016 at 09:09, Mikael Ståldal 
>>> wrote:
>>>
>>> > I don't quite understand what you mean.
>>> >
>>> > On Wed, Jan 27, 2016 at 4:02 PM, Matt Sicker  wrote:
>>> >
>>> > > That sounds a little fragile as some people either create or modify
>>> their
>>> > > creation directly from the plugin factories.
>>> > >
>>> > > On 27 January 2016 at 07:05, Mikael Ståldal <
>>> mikael.stal...@magine.com>
>>> > > wrote:
>>> > >
>>> > > > Then perhaps we should keep the node tree and expose it for this
>>> kind
>>> > of
>>> > > > queries, something like this:
>>> > > >
>>> > > > String hostname = loggerContext.getConfiguration().
>>> > > > getAttributesForAppender("syslogAppender").get("host");
>>> > > >
>>> > > > This would require a new method in
>>> > > > org.apache.logging.log4j.core.config.Configuration:
>>> > > >
>>> > > > public Map getAttributesForAppender(String
>>> > appenderName);
>>> > > >
>>> > > >
>>> > > >
>>> > > > On Wed, Jan 27, 2016 at 1:27 PM, Ralph Goers <
>>> > ralph.go...@dslextreme.com
>>> > > >
>>> > > > wrote:
>>> > > >
>>> > > > > While I understand your point, the node tree is discarded after
>>> the
>>> > > > > plugins are created. We would have to keep it around for this to
>>> > work.
>>> > > > > Furthermore, each component would need to have a reference to its
>>> > > > > corresponding node, which we obviously don't currently do.
>>> > > > >
>>> > > > > Ralph
>>> > > > >
>>> > > > > > On Jan 27, 2016, at 2:33 AM, Mikael Ståldal <
>>> > > mikael.stal...@magine.com
>>> > > > >
>>> > > > > wrote:
>>> > > > > >
>>> > > > > > To me it does not seems good to force all Appender
>>> implementations
>>> > to
>>> > > > > > implement this. Especially not since the next logical step
>>> would
>>> > then
>>> > > > be
>>> > > > > to
>>> > > > > > do the same with other components such as Layouts. That would
>>> be a
>>> > > lot
>>> > > > of
>>> > > > > > work in total, and also add more work for all future
>>> components,
>>> > > > > including
>>> > > > > > 3rd party plugins.
>>> > > > > >
>>> > > > > > I think it makes more sense, and would be less work in total,
>>> if
>>> > the
>>> > > > > > configuration system would store and expose those attributes
>>> > without
>>> > > > > > involving the components themselves.
>>> > > > > >
>>> > > > > > On Wed, Jan 27, 2016 at 7:14 AM, Gary Gregory <
>>> > > garydgreg...@gmail.com>
>>> > > > > > wrote:
>>> > > > > >
>>> > > > > >> Apostolis,
>>> > > > > >>
>>> > > > > >> You are warmly welcome to contribute to Log4j. You can create
>>> a
>>> > JIRA
>>> > > > and
>>> > > > > >> attach a patch in unified diff file format. Unit tests as
>>> part of
>>> > > the
>>> > > > > patch
>>> > > > > >> are a must IMO. Feel free to flush out any design or
>>> > implementation
>>> > > > > here on
>>> > > > > >> the dev ML.
>>> > > > > >>
>>> > > > > >> Thank you!
>>> > > > > >> Gary
>>> > > > > >>
>>> > > > > >> On Tue, Jan 26, 2016 at 5:02 PM, Ralph Goers <
>>> > > > > ralph.go...@dslextreme.com>
>>> > > > > >> wrote:
>>> > > > > >>
>>> > > > > >>> All the attributes have to have String representations to be
>>> > usable
>>> > > > in
>>> > > > > >> the
>>> > > > > >>> XML, JSON & Properties configurations. Yes, the Map could
>>> contain
>>> > > > > Objects
>>> > > > > >>> but then every one of them has to be cast to its real object
>>> to
>>> > be
>>> > > > > >> usable.
>>> > > > > >>>
>>> > > > > >>> The map should be read-only because modifying its contents
>>> would
>>> > > have
>>> > > > > no
>>> > > > > >>> effect on the appender.
>>> > > > > >>>
>>> > > > > >>> The map should not be stored in an ivar but constructed
>>> whenever
>>> > > the
>>> > > > > >>> attributes are retrieved. 

Re: Getter method for retrieving the attributes of an appender from the LoggerContext

[Apostolis Giannakidis]

One use case that I have at hand at the moment is that I want to be able to
verify that my appenders have the expected configuration attributes. For
example, I would like to be able to verify that my syslog appender is
connecting to the expected host,port,protocol, etc.

On Wed, Jan 27, 2016 at 3:19 PM, Mikael Ståldal 
wrote:

> It would be useful if Apostolis Giannakidis can explain the use case
> behind this request, now it is a bit abstract to me.
>
> On Wed, Jan 27, 2016 at 4:13 PM, Matt Sicker  wrote:
>
>> I mean keeping the Node tree to get attributes. It would only work from
>> config files (and the config builder classes). We get questions every so
>> often about modifying the config programmatically which would either need
>> to maintain more Nodes or just be unsupported.
>>
>> On 27 January 2016 at 09:09, Mikael Ståldal 
>> wrote:
>>
>> > I don't quite understand what you mean.
>> >
>> > On Wed, Jan 27, 2016 at 4:02 PM, Matt Sicker  wrote:
>> >
>> > > That sounds a little fragile as some people either create or modify
>> their
>> > > creation directly from the plugin factories.
>> > >
>> > > On 27 January 2016 at 07:05, Mikael Ståldal <
>> mikael.stal...@magine.com>
>> > > wrote:
>> > >
>> > > > Then perhaps we should keep the node tree and expose it for this
>> kind
>> > of
>> > > > queries, something like this:
>> > > >
>> > > > String hostname = loggerContext.getConfiguration().
>> > > > getAttributesForAppender("syslogAppender").get("host");
>> > > >
>> > > > This would require a new method in
>> > > > org.apache.logging.log4j.core.config.Configuration:
>> > > >
>> > > > public Map getAttributesForAppender(String
>> > appenderName);
>> > > >
>> > > >
>> > > >
>> > > > On Wed, Jan 27, 2016 at 1:27 PM, Ralph Goers <
>> > ralph.go...@dslextreme.com
>> > > >
>> > > > wrote:
>> > > >
>> > > > > While I understand your point, the node tree is discarded after
>> the
>> > > > > plugins are created. We would have to keep it around for this to
>> > work.
>> > > > > Furthermore, each component would need to have a reference to its
>> > > > > corresponding node, which we obviously don't currently do.
>> > > > >
>> > > > > Ralph
>> > > > >
>> > > > > > On Jan 27, 2016, at 2:33 AM, Mikael Ståldal <
>> > > mikael.stal...@magine.com
>> > > > >
>> > > > > wrote:
>> > > > > >
>> > > > > > To me it does not seems good to force all Appender
>> implementations
>> > to
>> > > > > > implement this. Especially not since the next logical step would
>> > then
>> > > > be
>> > > > > to
>> > > > > > do the same with other components such as Layouts. That would
>> be a
>> > > lot
>> > > > of
>> > > > > > work in total, and also add more work for all future components,
>> > > > > including
>> > > > > > 3rd party plugins.
>> > > > > >
>> > > > > > I think it makes more sense, and would be less work in total, if
>> > the
>> > > > > > configuration system would store and expose those attributes
>> > without
>> > > > > > involving the components themselves.
>> > > > > >
>> > > > > > On Wed, Jan 27, 2016 at 7:14 AM, Gary Gregory <
>> > > garydgreg...@gmail.com>
>> > > > > > wrote:
>> > > > > >
>> > > > > >> Apostolis,
>> > > > > >>
>> > > > > >> You are warmly welcome to contribute to Log4j. You can create a
>> > JIRA
>> > > > and
>> > > > > >> attach a patch in unified diff file format. Unit tests as part
>> of
>> > > the
>> > > > > patch
>> > > > > >> are a must IMO. Feel free to flush out any design or
>> > implementation
>> > > > > here on
>> > > > > >> the dev ML.
>> > > > > >>
>> > > > > >> Thank you!
>> > > > > >> Gary
>> > > > > >>
>> > > > > >> On Tue, Jan 26, 2016 at 5:02 PM, Ralph Goers <
>> > > > > ralph.go...@dslextreme.com>
>> > > > > >> wrote:
>> > > > > >>
>> > > > > >>> All the attributes have to have String representations to be
>> > usable
>> > > > in
>> > > > > >> the
>> > > > > >>> XML, JSON & Properties configurations. Yes, the Map could
>> contain
>> > > > > Objects
>> > > > > >>> but then every one of them has to be cast to its real object
>> to
>> > be
>> > > > > >> usable.
>> > > > > >>>
>> > > > > >>> The map should be read-only because modifying its contents
>> would
>> > > have
>> > > > > no
>> > > > > >>> effect on the appender.
>> > > > > >>>
>> > > > > >>> The map should not be stored in an ivar but constructed
>> whenever
>> > > the
>> > > > > >>> attributes are retrieved. Otherwise it will be temping to just
>> > keep
>> > > > > them
>> > > > > >> in
>> > > > > >>> a map and not as individual attributes, which would cause
>> > problems.
>> > > > > >>>
>> > > > > >>> If you have nesting such as  MyAppender extends MyBaseAppender
>> > > > extends
>> > > > > >>> AbstractOutputStreamAppender extends AbstractAppender, I
>> > envision a
>> > > > > >>> fillAttributes method at each “level” that fills in the
>> > attributes
>> > > it
>> > > > > >> knows
>> > > > > >>> about, so 

Re: Getter method for retrieving the attributes of an appender from the LoggerContext

[Mikael Ståldal]

To me it does not seems good to force all Appender implementations to
implement this. Especially not since the next logical step would then be to
do the same with other components such as Layouts. That would be a lot of
work in total, and also add more work for all future components, including
3rd party plugins.

I think it makes more sense, and would be less work in total, if the
configuration system would store and expose those attributes without
involving the components themselves.

On Wed, Jan 27, 2016 at 7:14 AM, Gary Gregory 
wrote:

> Apostolis,
>
> You are warmly welcome to contribute to Log4j. You can create a JIRA and
> attach a patch in unified diff file format. Unit tests as part of the patch
> are a must IMO. Feel free to flush out any design or implementation here on
> the dev ML.
>
> Thank you!
> Gary
>
> On Tue, Jan 26, 2016 at 5:02 PM, Ralph Goers 
> wrote:
>
> > All the attributes have to have String representations to be usable in
> the
> > XML, JSON & Properties configurations. Yes, the Map could contain Objects
> > but then every one of them has to be cast to its real object to be
> usable.
> >
> > The map should be read-only because modifying its contents would have no
> > effect on the appender.
> >
> > The map should not be stored in an ivar but constructed whenever the
> > attributes are retrieved. Otherwise it will be temping to just keep them
> in
> > a map and not as individual attributes, which would cause problems.
> >
> > If you have nesting such as  MyAppender extends MyBaseAppender extends
> > AbstractOutputStreamAppender extends AbstractAppender, I envision a
> > fillAttributes method at each “level” that fills in the attributes it
> knows
> > about, so fillAttributeMap(map) should always call
> > super.fillAttributeMap(map) - except in AbstractAppender of course - and
> > should call it before filling in its own attributes so that it can
> override
> > any values provided by the base Appenders.  If the primary Appender does
> > not implement fillAttributeMap then only the attributes of its super
> > classes will be included, which is actually correct for the
> SyslogAppender.
> >
> > Ralph
> >
> > > On Jan 26, 2016, at 5:24 PM, Apostolis Giannakidis <
> > ap.giannaki...@gmail.com> wrote:
> > >
> > > One thing to note here. Correct me if I am wrong, but the map should
> > > be Map > > Object> because not all attributes are Strings. From the top of my
> head,
> > I
> > > know that an attribute could also be a boolean.
> > >
> > > On Wed, Jan 27, 2016 at 12:06 AM, Gary Gregory  >
> > > wrote:
> > >
> > >> I could see AbstractAppender implementing a getAttributes() method
> like
> > >> this:
> > >>
> > >>public Map getAttributes() {
> > >>Map map = new HashMap<>();
> > >>fillAttributeMap(map);
> > >>// (1) should the map be read-only? why?
> > >>// (2) if the map is cached in an ivar, the it must be updated
> by
> > >> each appender when an attribute changes, so
> > >>// I'd say no and follow the KISS principle for now.
> > >>return map;
> > >>}
> > >>
> > >>protected void fillAttributeMap(Map map) {
> > >>// ...
> > >>}
> > >>
> > >> The boilerplate of creating and/or managing the map can be in
> > >> getAttributes().
> > >> Actually filling in the map in is done in fillAttributeMap() which
> each
> > >> appender can override.
> > >>
> > >> fillAttributeMap() could be abstract to force each appender to make
> sure
> > >> developers pay attention to providing an implementation.
> > >>
> > >> Gary
> > >>
> > >>
> > >> On Tue, Jan 26, 2016 at 3:46 PM, Apostolis Giannakidis <
> > >> ap.giannaki...@gmail.com> wrote:
> > >>
> > >>> Well, since the idea is to add it to the Appender interface, it means
> > >> that
> > >>> all concrete Appenders need to be modified as well. So, yes, I can
> give
> > >> it
> > >>> a try to implement it for all the Appenders. One other simple way
> would
> > >> be
> > >>> to implement it once in the AbstractAppender so that all its
> subclasses
> > >>> will inherit it.
> > >>>
> > >>> On Tue, Jan 26, 2016 at 9:15 PM, Gary Gregory <
> garydgreg...@gmail.com>
> > >>> wrote:
> > >>>
> >  On Tue, Jan 26, 2016 at 1:06 PM, Apostolis Giannakidis <
> >  ap.giannaki...@gmail.com> wrote:
> > 
> > > Actually, since this seems to be a useful feature, I would love to
> do
> > >>> the
> > > patch myself and contribute it to the project, if you don't mind.
> > >
> > 
> >  Do you plan on implementing this for all Appenders?
> > 
> >  Gary
> > 
> > >
> > > On Tue, Jan 26, 2016 at 8:56 PM, Ralph Goers <
> > >>> ralph.go...@dslextreme.com
> > >
> > > wrote:
> > >
> > >> Actually, I kind of like the idea of adding a getAttributes()
> > >> method
> > >>> to
> > >> the Appender interface. Then each 

Re: Getter method for retrieving the attributes of an appender from the LoggerContext

[Mikael Ståldal]

Then perhaps we should keep the node tree and expose it for this kind of
queries, something like this:

String hostname = loggerContext.getConfiguration().
getAttributesForAppender("syslogAppender").get("host");

This would require a new method in
org.apache.logging.log4j.core.config.Configuration:

public Map getAttributesForAppender(String appenderName);



On Wed, Jan 27, 2016 at 1:27 PM, Ralph Goers 
wrote:

> While I understand your point, the node tree is discarded after the
> plugins are created. We would have to keep it around for this to work.
> Furthermore, each component would need to have a reference to its
> corresponding node, which we obviously don't currently do.
>
> Ralph
>
> > On Jan 27, 2016, at 2:33 AM, Mikael Ståldal 
> wrote:
> >
> > To me it does not seems good to force all Appender implementations to
> > implement this. Especially not since the next logical step would then be
> to
> > do the same with other components such as Layouts. That would be a lot of
> > work in total, and also add more work for all future components,
> including
> > 3rd party plugins.
> >
> > I think it makes more sense, and would be less work in total, if the
> > configuration system would store and expose those attributes without
> > involving the components themselves.
> >
> > On Wed, Jan 27, 2016 at 7:14 AM, Gary Gregory 
> > wrote:
> >
> >> Apostolis,
> >>
> >> You are warmly welcome to contribute to Log4j. You can create a JIRA and
> >> attach a patch in unified diff file format. Unit tests as part of the
> patch
> >> are a must IMO. Feel free to flush out any design or implementation
> here on
> >> the dev ML.
> >>
> >> Thank you!
> >> Gary
> >>
> >> On Tue, Jan 26, 2016 at 5:02 PM, Ralph Goers <
> ralph.go...@dslextreme.com>
> >> wrote:
> >>
> >>> All the attributes have to have String representations to be usable in
> >> the
> >>> XML, JSON & Properties configurations. Yes, the Map could contain
> Objects
> >>> but then every one of them has to be cast to its real object to be
> >> usable.
> >>>
> >>> The map should be read-only because modifying its contents would have
> no
> >>> effect on the appender.
> >>>
> >>> The map should not be stored in an ivar but constructed whenever the
> >>> attributes are retrieved. Otherwise it will be temping to just keep
> them
> >> in
> >>> a map and not as individual attributes, which would cause problems.
> >>>
> >>> If you have nesting such as  MyAppender extends MyBaseAppender extends
> >>> AbstractOutputStreamAppender extends AbstractAppender, I envision a
> >>> fillAttributes method at each “level” that fills in the attributes it
> >> knows
> >>> about, so fillAttributeMap(map) should always call
> >>> super.fillAttributeMap(map) - except in AbstractAppender of course -
> and
> >>> should call it before filling in its own attributes so that it can
> >> override
> >>> any values provided by the base Appenders.  If the primary Appender
> does
> >>> not implement fillAttributeMap then only the attributes of its super
> >>> classes will be included, which is actually correct for the
> >> SyslogAppender.
> >>>
> >>> Ralph
> >>>
>  On Jan 26, 2016, at 5:24 PM, Apostolis Giannakidis <
> >>> ap.giannaki...@gmail.com> wrote:
> 
>  One thing to note here. Correct me if I am wrong, but the map should
>  be Map  Object> because not all attributes are Strings. From the top of my
> >> head,
> >>> I
>  know that an attribute could also be a boolean.
> 
>  On Wed, Jan 27, 2016 at 12:06 AM, Gary Gregory <
> garydgreg...@gmail.com
> >>>
>  wrote:
> 
> > I could see AbstractAppender implementing a getAttributes() method
> >> like
> > this:
> >
> >   public Map getAttributes() {
> >   Map map = new HashMap<>();
> >   fillAttributeMap(map);
> >   // (1) should the map be read-only? why?
> >   // (2) if the map is cached in an ivar, the it must be updated
> >> by
> > each appender when an attribute changes, so
> >   // I'd say no and follow the KISS principle for now.
> >   return map;
> >   }
> >
> >   protected void fillAttributeMap(Map map) {
> >   // ...
> >   }
> >
> > The boilerplate of creating and/or managing the map can be in
> > getAttributes().
> > Actually filling in the map in is done in fillAttributeMap() which
> >> each
> > appender can override.
> >
> > fillAttributeMap() could be abstract to force each appender to make
> >> sure
> > developers pay attention to providing an implementation.
> >
> > Gary
> >
> >
> > On Tue, Jan 26, 2016 at 3:46 PM, Apostolis Giannakidis <
> > ap.giannaki...@gmail.com> wrote:
> >
> >> Well, since the idea is to add it to the Appender interface, it
> means
> > that
> >> all concrete 

Re: Getter method for retrieving the attributes of an appender from the LoggerContext

[Matt Sicker]

That sounds a little fragile as some people either create or modify their
creation directly from the plugin factories.

On 27 January 2016 at 07:05, Mikael Ståldal 
wrote:

> Then perhaps we should keep the node tree and expose it for this kind of
> queries, something like this:
>
> String hostname = loggerContext.getConfiguration().
> getAttributesForAppender("syslogAppender").get("host");
>
> This would require a new method in
> org.apache.logging.log4j.core.config.Configuration:
>
> public Map getAttributesForAppender(String appenderName);
>
>
>
> On Wed, Jan 27, 2016 at 1:27 PM, Ralph Goers 
> wrote:
>
> > While I understand your point, the node tree is discarded after the
> > plugins are created. We would have to keep it around for this to work.
> > Furthermore, each component would need to have a reference to its
> > corresponding node, which we obviously don't currently do.
> >
> > Ralph
> >
> > > On Jan 27, 2016, at 2:33 AM, Mikael Ståldal  >
> > wrote:
> > >
> > > To me it does not seems good to force all Appender implementations to
> > > implement this. Especially not since the next logical step would then
> be
> > to
> > > do the same with other components such as Layouts. That would be a lot
> of
> > > work in total, and also add more work for all future components,
> > including
> > > 3rd party plugins.
> > >
> > > I think it makes more sense, and would be less work in total, if the
> > > configuration system would store and expose those attributes without
> > > involving the components themselves.
> > >
> > > On Wed, Jan 27, 2016 at 7:14 AM, Gary Gregory 
> > > wrote:
> > >
> > >> Apostolis,
> > >>
> > >> You are warmly welcome to contribute to Log4j. You can create a JIRA
> and
> > >> attach a patch in unified diff file format. Unit tests as part of the
> > patch
> > >> are a must IMO. Feel free to flush out any design or implementation
> > here on
> > >> the dev ML.
> > >>
> > >> Thank you!
> > >> Gary
> > >>
> > >> On Tue, Jan 26, 2016 at 5:02 PM, Ralph Goers <
> > ralph.go...@dslextreme.com>
> > >> wrote:
> > >>
> > >>> All the attributes have to have String representations to be usable
> in
> > >> the
> > >>> XML, JSON & Properties configurations. Yes, the Map could contain
> > Objects
> > >>> but then every one of them has to be cast to its real object to be
> > >> usable.
> > >>>
> > >>> The map should be read-only because modifying its contents would have
> > no
> > >>> effect on the appender.
> > >>>
> > >>> The map should not be stored in an ivar but constructed whenever the
> > >>> attributes are retrieved. Otherwise it will be temping to just keep
> > them
> > >> in
> > >>> a map and not as individual attributes, which would cause problems.
> > >>>
> > >>> If you have nesting such as  MyAppender extends MyBaseAppender
> extends
> > >>> AbstractOutputStreamAppender extends AbstractAppender, I envision a
> > >>> fillAttributes method at each “level” that fills in the attributes it
> > >> knows
> > >>> about, so fillAttributeMap(map) should always call
> > >>> super.fillAttributeMap(map) - except in AbstractAppender of course -
> > and
> > >>> should call it before filling in its own attributes so that it can
> > >> override
> > >>> any values provided by the base Appenders.  If the primary Appender
> > does
> > >>> not implement fillAttributeMap then only the attributes of its super
> > >>> classes will be included, which is actually correct for the
> > >> SyslogAppender.
> > >>>
> > >>> Ralph
> > >>>
> >  On Jan 26, 2016, at 5:24 PM, Apostolis Giannakidis <
> > >>> ap.giannaki...@gmail.com> wrote:
> > 
> >  One thing to note here. Correct me if I am wrong, but the map should
> >  be Map >  Object> because not all attributes are Strings. From the top of my
> > >> head,
> > >>> I
> >  know that an attribute could also be a boolean.
> > 
> >  On Wed, Jan 27, 2016 at 12:06 AM, Gary Gregory <
> > garydgreg...@gmail.com
> > >>>
> >  wrote:
> > 
> > > I could see AbstractAppender implementing a getAttributes() method
> > >> like
> > > this:
> > >
> > >   public Map getAttributes() {
> > >   Map map = new HashMap<>();
> > >   fillAttributeMap(map);
> > >   // (1) should the map be read-only? why?
> > >   // (2) if the map is cached in an ivar, the it must be
> updated
> > >> by
> > > each appender when an attribute changes, so
> > >   // I'd say no and follow the KISS principle for now.
> > >   return map;
> > >   }
> > >
> > >   protected void fillAttributeMap(Map map) {
> > >   // ...
> > >   }
> > >
> > > The boilerplate of creating and/or managing the map can be in
> > > getAttributes().
> > > Actually filling in the map in is done in fillAttributeMap() which
> 

Re: Getter method for retrieving the attributes of an appender from the LoggerContext

[Matt Sicker]

I mean keeping the Node tree to get attributes. It would only work from
config files (and the config builder classes). We get questions every so
often about modifying the config programmatically which would either need
to maintain more Nodes or just be unsupported.

On 27 January 2016 at 09:09, Mikael Ståldal 
wrote:

> I don't quite understand what you mean.
>
> On Wed, Jan 27, 2016 at 4:02 PM, Matt Sicker  wrote:
>
> > That sounds a little fragile as some people either create or modify their
> > creation directly from the plugin factories.
> >
> > On 27 January 2016 at 07:05, Mikael Ståldal 
> > wrote:
> >
> > > Then perhaps we should keep the node tree and expose it for this kind
> of
> > > queries, something like this:
> > >
> > > String hostname = loggerContext.getConfiguration().
> > > getAttributesForAppender("syslogAppender").get("host");
> > >
> > > This would require a new method in
> > > org.apache.logging.log4j.core.config.Configuration:
> > >
> > > public Map getAttributesForAppender(String
> appenderName);
> > >
> > >
> > >
> > > On Wed, Jan 27, 2016 at 1:27 PM, Ralph Goers <
> ralph.go...@dslextreme.com
> > >
> > > wrote:
> > >
> > > > While I understand your point, the node tree is discarded after the
> > > > plugins are created. We would have to keep it around for this to
> work.
> > > > Furthermore, each component would need to have a reference to its
> > > > corresponding node, which we obviously don't currently do.
> > > >
> > > > Ralph
> > > >
> > > > > On Jan 27, 2016, at 2:33 AM, Mikael Ståldal <
> > mikael.stal...@magine.com
> > > >
> > > > wrote:
> > > > >
> > > > > To me it does not seems good to force all Appender implementations
> to
> > > > > implement this. Especially not since the next logical step would
> then
> > > be
> > > > to
> > > > > do the same with other components such as Layouts. That would be a
> > lot
> > > of
> > > > > work in total, and also add more work for all future components,
> > > > including
> > > > > 3rd party plugins.
> > > > >
> > > > > I think it makes more sense, and would be less work in total, if
> the
> > > > > configuration system would store and expose those attributes
> without
> > > > > involving the components themselves.
> > > > >
> > > > > On Wed, Jan 27, 2016 at 7:14 AM, Gary Gregory <
> > garydgreg...@gmail.com>
> > > > > wrote:
> > > > >
> > > > >> Apostolis,
> > > > >>
> > > > >> You are warmly welcome to contribute to Log4j. You can create a
> JIRA
> > > and
> > > > >> attach a patch in unified diff file format. Unit tests as part of
> > the
> > > > patch
> > > > >> are a must IMO. Feel free to flush out any design or
> implementation
> > > > here on
> > > > >> the dev ML.
> > > > >>
> > > > >> Thank you!
> > > > >> Gary
> > > > >>
> > > > >> On Tue, Jan 26, 2016 at 5:02 PM, Ralph Goers <
> > > > ralph.go...@dslextreme.com>
> > > > >> wrote:
> > > > >>
> > > > >>> All the attributes have to have String representations to be
> usable
> > > in
> > > > >> the
> > > > >>> XML, JSON & Properties configurations. Yes, the Map could contain
> > > > Objects
> > > > >>> but then every one of them has to be cast to its real object to
> be
> > > > >> usable.
> > > > >>>
> > > > >>> The map should be read-only because modifying its contents would
> > have
> > > > no
> > > > >>> effect on the appender.
> > > > >>>
> > > > >>> The map should not be stored in an ivar but constructed whenever
> > the
> > > > >>> attributes are retrieved. Otherwise it will be temping to just
> keep
> > > > them
> > > > >> in
> > > > >>> a map and not as individual attributes, which would cause
> problems.
> > > > >>>
> > > > >>> If you have nesting such as  MyAppender extends MyBaseAppender
> > > extends
> > > > >>> AbstractOutputStreamAppender extends AbstractAppender, I
> envision a
> > > > >>> fillAttributes method at each “level” that fills in the
> attributes
> > it
> > > > >> knows
> > > > >>> about, so fillAttributeMap(map) should always call
> > > > >>> super.fillAttributeMap(map) - except in AbstractAppender of
> course
> > -
> > > > and
> > > > >>> should call it before filling in its own attributes so that it
> can
> > > > >> override
> > > > >>> any values provided by the base Appenders.  If the primary
> Appender
> > > > does
> > > > >>> not implement fillAttributeMap then only the attributes of its
> > super
> > > > >>> classes will be included, which is actually correct for the
> > > > >> SyslogAppender.
> > > > >>>
> > > > >>> Ralph
> > > > >>>
> > > >  On Jan 26, 2016, at 5:24 PM, Apostolis Giannakidis <
> > > > >>> ap.giannaki...@gmail.com> wrote:
> > > > 
> > > >  One thing to note here. Correct me if I am wrong, but the map
> > should
> > > >  be Map > > >  Object> because not all attributes are Strings. From the top of
> my
> > > > >> head,
> > > > >>> I
> > > >  know that an attribute could also be a boolean.
> > > > 
> > 

Re: Getter method for retrieving the attributes of an appender from the LoggerContext

[Mikael Ståldal]

It would be useful if Apostolis Giannakidis can explain the use case behind
this request, now it is a bit abstract to me.

On Wed, Jan 27, 2016 at 4:13 PM, Matt Sicker  wrote:

> I mean keeping the Node tree to get attributes. It would only work from
> config files (and the config builder classes). We get questions every so
> often about modifying the config programmatically which would either need
> to maintain more Nodes or just be unsupported.
>
> On 27 January 2016 at 09:09, Mikael Ståldal 
> wrote:
>
> > I don't quite understand what you mean.
> >
> > On Wed, Jan 27, 2016 at 4:02 PM, Matt Sicker  wrote:
> >
> > > That sounds a little fragile as some people either create or modify
> their
> > > creation directly from the plugin factories.
> > >
> > > On 27 January 2016 at 07:05, Mikael Ståldal  >
> > > wrote:
> > >
> > > > Then perhaps we should keep the node tree and expose it for this kind
> > of
> > > > queries, something like this:
> > > >
> > > > String hostname = loggerContext.getConfiguration().
> > > > getAttributesForAppender("syslogAppender").get("host");
> > > >
> > > > This would require a new method in
> > > > org.apache.logging.log4j.core.config.Configuration:
> > > >
> > > > public Map getAttributesForAppender(String
> > appenderName);
> > > >
> > > >
> > > >
> > > > On Wed, Jan 27, 2016 at 1:27 PM, Ralph Goers <
> > ralph.go...@dslextreme.com
> > > >
> > > > wrote:
> > > >
> > > > > While I understand your point, the node tree is discarded after the
> > > > > plugins are created. We would have to keep it around for this to
> > work.
> > > > > Furthermore, each component would need to have a reference to its
> > > > > corresponding node, which we obviously don't currently do.
> > > > >
> > > > > Ralph
> > > > >
> > > > > > On Jan 27, 2016, at 2:33 AM, Mikael Ståldal <
> > > mikael.stal...@magine.com
> > > > >
> > > > > wrote:
> > > > > >
> > > > > > To me it does not seems good to force all Appender
> implementations
> > to
> > > > > > implement this. Especially not since the next logical step would
> > then
> > > > be
> > > > > to
> > > > > > do the same with other components such as Layouts. That would be
> a
> > > lot
> > > > of
> > > > > > work in total, and also add more work for all future components,
> > > > > including
> > > > > > 3rd party plugins.
> > > > > >
> > > > > > I think it makes more sense, and would be less work in total, if
> > the
> > > > > > configuration system would store and expose those attributes
> > without
> > > > > > involving the components themselves.
> > > > > >
> > > > > > On Wed, Jan 27, 2016 at 7:14 AM, Gary Gregory <
> > > garydgreg...@gmail.com>
> > > > > > wrote:
> > > > > >
> > > > > >> Apostolis,
> > > > > >>
> > > > > >> You are warmly welcome to contribute to Log4j. You can create a
> > JIRA
> > > > and
> > > > > >> attach a patch in unified diff file format. Unit tests as part
> of
> > > the
> > > > > patch
> > > > > >> are a must IMO. Feel free to flush out any design or
> > implementation
> > > > > here on
> > > > > >> the dev ML.
> > > > > >>
> > > > > >> Thank you!
> > > > > >> Gary
> > > > > >>
> > > > > >> On Tue, Jan 26, 2016 at 5:02 PM, Ralph Goers <
> > > > > ralph.go...@dslextreme.com>
> > > > > >> wrote:
> > > > > >>
> > > > > >>> All the attributes have to have String representations to be
> > usable
> > > > in
> > > > > >> the
> > > > > >>> XML, JSON & Properties configurations. Yes, the Map could
> contain
> > > > > Objects
> > > > > >>> but then every one of them has to be cast to its real object to
> > be
> > > > > >> usable.
> > > > > >>>
> > > > > >>> The map should be read-only because modifying its contents
> would
> > > have
> > > > > no
> > > > > >>> effect on the appender.
> > > > > >>>
> > > > > >>> The map should not be stored in an ivar but constructed
> whenever
> > > the
> > > > > >>> attributes are retrieved. Otherwise it will be temping to just
> > keep
> > > > > them
> > > > > >> in
> > > > > >>> a map and not as individual attributes, which would cause
> > problems.
> > > > > >>>
> > > > > >>> If you have nesting such as  MyAppender extends MyBaseAppender
> > > > extends
> > > > > >>> AbstractOutputStreamAppender extends AbstractAppender, I
> > envision a
> > > > > >>> fillAttributes method at each “level” that fills in the
> > attributes
> > > it
> > > > > >> knows
> > > > > >>> about, so fillAttributeMap(map) should always call
> > > > > >>> super.fillAttributeMap(map) - except in AbstractAppender of
> > course
> > > -
> > > > > and
> > > > > >>> should call it before filling in its own attributes so that it
> > can
> > > > > >> override
> > > > > >>> any values provided by the base Appenders.  If the primary
> > Appender
> > > > > does
> > > > > >>> not implement fillAttributeMap then only the attributes of its
> > > super
> > > > > >>> classes will be included, which is actually correct for the
> > > > 

Re: Getter method for retrieving the attributes of an appender from the LoggerContext

[Gary Gregory]

Apostolis,

You are warmly welcome to contribute to Log4j. You can create a JIRA and
attach a patch in unified diff file format. Unit tests as part of the patch
are a must IMO. Feel free to flush out any design or implementation here on
the dev ML.

Thank you!
Gary

On Tue, Jan 26, 2016 at 5:02 PM, Ralph Goers 
wrote:

> All the attributes have to have String representations to be usable in the
> XML, JSON & Properties configurations. Yes, the Map could contain Objects
> but then every one of them has to be cast to its real object to be usable.
>
> The map should be read-only because modifying its contents would have no
> effect on the appender.
>
> The map should not be stored in an ivar but constructed whenever the
> attributes are retrieved. Otherwise it will be temping to just keep them in
> a map and not as individual attributes, which would cause problems.
>
> If you have nesting such as  MyAppender extends MyBaseAppender extends
> AbstractOutputStreamAppender extends AbstractAppender, I envision a
> fillAttributes method at each “level” that fills in the attributes it knows
> about, so fillAttributeMap(map) should always call
> super.fillAttributeMap(map) - except in AbstractAppender of course - and
> should call it before filling in its own attributes so that it can override
> any values provided by the base Appenders.  If the primary Appender does
> not implement fillAttributeMap then only the attributes of its super
> classes will be included, which is actually correct for the SyslogAppender.
>
> Ralph
>
> > On Jan 26, 2016, at 5:24 PM, Apostolis Giannakidis <
> ap.giannaki...@gmail.com> wrote:
> >
> > One thing to note here. Correct me if I am wrong, but the map should
> > be Map > Object> because not all attributes are Strings. From the top of my head,
> I
> > know that an attribute could also be a boolean.
> >
> > On Wed, Jan 27, 2016 at 12:06 AM, Gary Gregory 
> > wrote:
> >
> >> I could see AbstractAppender implementing a getAttributes() method like
> >> this:
> >>
> >>public Map getAttributes() {
> >>Map map = new HashMap<>();
> >>fillAttributeMap(map);
> >>// (1) should the map be read-only? why?
> >>// (2) if the map is cached in an ivar, the it must be updated by
> >> each appender when an attribute changes, so
> >>// I'd say no and follow the KISS principle for now.
> >>return map;
> >>}
> >>
> >>protected void fillAttributeMap(Map map) {
> >>// ...
> >>}
> >>
> >> The boilerplate of creating and/or managing the map can be in
> >> getAttributes().
> >> Actually filling in the map in is done in fillAttributeMap() which each
> >> appender can override.
> >>
> >> fillAttributeMap() could be abstract to force each appender to make sure
> >> developers pay attention to providing an implementation.
> >>
> >> Gary
> >>
> >>
> >> On Tue, Jan 26, 2016 at 3:46 PM, Apostolis Giannakidis <
> >> ap.giannaki...@gmail.com> wrote:
> >>
> >>> Well, since the idea is to add it to the Appender interface, it means
> >> that
> >>> all concrete Appenders need to be modified as well. So, yes, I can give
> >> it
> >>> a try to implement it for all the Appenders. One other simple way would
> >> be
> >>> to implement it once in the AbstractAppender so that all its subclasses
> >>> will inherit it.
> >>>
> >>> On Tue, Jan 26, 2016 at 9:15 PM, Gary Gregory 
> >>> wrote:
> >>>
>  On Tue, Jan 26, 2016 at 1:06 PM, Apostolis Giannakidis <
>  ap.giannaki...@gmail.com> wrote:
> 
> > Actually, since this seems to be a useful feature, I would love to do
> >>> the
> > patch myself and contribute it to the project, if you don't mind.
> >
> 
>  Do you plan on implementing this for all Appenders?
> 
>  Gary
> 
> >
> > On Tue, Jan 26, 2016 at 8:56 PM, Ralph Goers <
> >>> ralph.go...@dslextreme.com
> >
> > wrote:
> >
> >> Actually, I kind of like the idea of adding a getAttributes()
> >> method
> >>> to
> >> the Appender interface. Then each concrete Appender would do:
> >>
> >> public void getAttributes() {
> >>Map attributes = new HashMap<>();
> >>super.getAttributes(attributes):
> >>attributes.put(“myAttribute1”, “value1”);
> >>return Collections.unmodifiableMap(attributes);
> >> }
> >>
> >>
> >>
> >>> On Jan 26, 2016, at 1:28 PM, Gary Gregory <
> >> garydgreg...@gmail.com>
> >> wrote:
> >>>
> >>> How about adding getters for the fields
> >>> in org.apache.logging.log4j.core.net.AbstractSocketManager?
> >>>
> >>> Gary
> >>>
> >>> On Tue, Jan 26, 2016 at 12:20 PM, Matt Sicker 
> > wrote:
> >>>
>  You could always use reflection to access it for now.
> 
>  On 26 January 2016 at 14:17, Apostolis 

Re: Getter method for retrieving the attributes of an appender from the LoggerContext

[Ralph Goers]

Not exactly. You can do:

Appender appender = ctx.getConfiguration().getAppender(“syslogAppender”);

then you would have to do 

SyslogAppender syslogAppender = (SyslogAppender) appender;

normally you would probably use instanceof to verify it is actually a 
SyslogAppender.

Once you have that you can call whatever methods the SyslogAppender exposes for 
getting its attributes. They are not stored in a Map however, so you can’t just 
call a generic getAttribute method.

Ralph


> On Jan 26, 2016, at 11:58 AM, Apostolis Giannakidis 
>  wrote:
> 
> Hello team,
> 
> I have created a logger with an appender using the ConfigurationBuilder and
> the AppenderComponentBuilder.
> 
> Let's say that this is how I create my appender:
> 
> AppenderComponentBuilder appenderBuilder =
>builder.newAppender( "syslogAppender", "Syslog" )
>.addAttribute( "protocol", "TCP" )
>.addAttribute( "host", "localhost" )
>.addAttribute( "port", 514 )
>.addAttribute( "facility", "LOCAL2" )
>.addAttribute( "immediateFlush", true )
>.addAttribute( "newLine", true );
> 
> Then, after I finish creating the builder I use the
> Configurator.initialize( builder.build() ) to get the LoggerContext.
> 
> Is there any way I can access the attributes of the appender through the
> LoggerContext?
> 
> For example something like this:
> 
> LoggerContext ctx = Configurator.initialize( builder.build() );
> 
> String hostname =
> ctx.getConfiguration()..getAppenders().get("syslogAppender").getAttribute("host");
> 
> Thank you all very much for your help.
> 
> Apostolis



-
To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-user-h...@logging.apache.org

Re: Getter method for retrieving the attributes of an appender from the LoggerContext

[Apostolis Giannakidis]

Thank you very much for the prompt reply Ralph.

As far as I can see, the SyslogAppender class does not expose a way to
access these attributes. So, if there is no other way of accessing these
attributes, then I am not able to retrieve the attributes that I want from
the existing SyslogAppender implementation. If I understand correctly,
correct me if I am wrong, I might have to create my own that exposes these
attributes.

Apos

On Tue, Jan 26, 2016 at 8:03 PM, Ralph Goers 
wrote:

> Not exactly. You can do:
>
> Appender appender = ctx.getConfiguration().getAppender(“syslogAppender”);
>
> then you would have to do
>
> SyslogAppender syslogAppender = (SyslogAppender) appender;
>
> normally you would probably use instanceof to verify it is actually a
> SyslogAppender.
>
> Once you have that you can call whatever methods the SyslogAppender
> exposes for getting its attributes. They are not stored in a Map however,
> so you can’t just call a generic getAttribute method.
>
> Ralph
>
>
> > On Jan 26, 2016, at 11:58 AM, Apostolis Giannakidis <
> ap.giannaki...@gmail.com> wrote:
> >
> > Hello team,
> >
> > I have created a logger with an appender using the ConfigurationBuilder
> and
> > the AppenderComponentBuilder.
> >
> > Let's say that this is how I create my appender:
> >
> > AppenderComponentBuilder appenderBuilder =
> >builder.newAppender( "syslogAppender", "Syslog" )
> >.addAttribute( "protocol", "TCP" )
> >.addAttribute( "host", "localhost" )
> >.addAttribute( "port", 514 )
> >.addAttribute( "facility", "LOCAL2" )
> >.addAttribute( "immediateFlush", true )
> >.addAttribute( "newLine", true );
> >
> > Then, after I finish creating the builder I use the
> > Configurator.initialize( builder.build() ) to get the LoggerContext.
> >
> > Is there any way I can access the attributes of the appender through the
> > LoggerContext?
> >
> > For example something like this:
> >
> > LoggerContext ctx = Configurator.initialize( builder.build() );
> >
> > String hostname =
> >
> ctx.getConfiguration()..getAppenders().get("syslogAppender").getAttribute("host");
> >
> > Thank you all very much for your help.
> >
> > Apostolis
>
>
>
> -
> To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
> For additional commands, e-mail: log4j-user-h...@logging.apache.org
>
>

Re: Getter method for retrieving the attributes of an appender from the LoggerContext

[Matt Sicker]

You could always use reflection to access it for now.

On 26 January 2016 at 14:17, Apostolis Giannakidis  wrote:

> Thank you very much for the prompt reply Ralph.
>
> As far as I can see, the SyslogAppender class does not expose a way to
> access these attributes. So, if there is no other way of accessing these
> attributes, then I am not able to retrieve the attributes that I want from
> the existing SyslogAppender implementation. If I understand correctly,
> correct me if I am wrong, I might have to create my own that exposes these
> attributes.
>
> Apos
>
> On Tue, Jan 26, 2016 at 8:03 PM, Ralph Goers 
> wrote:
>
> > Not exactly. You can do:
> >
> > Appender appender = ctx.getConfiguration().getAppender(“syslogAppender”);
> >
> > then you would have to do
> >
> > SyslogAppender syslogAppender = (SyslogAppender) appender;
> >
> > normally you would probably use instanceof to verify it is actually a
> > SyslogAppender.
> >
> > Once you have that you can call whatever methods the SyslogAppender
> > exposes for getting its attributes. They are not stored in a Map however,
> > so you can’t just call a generic getAttribute method.
> >
> > Ralph
> >
> >
> > > On Jan 26, 2016, at 11:58 AM, Apostolis Giannakidis <
> > ap.giannaki...@gmail.com> wrote:
> > >
> > > Hello team,
> > >
> > > I have created a logger with an appender using the ConfigurationBuilder
> > and
> > > the AppenderComponentBuilder.
> > >
> > > Let's say that this is how I create my appender:
> > >
> > > AppenderComponentBuilder appenderBuilder =
> > >builder.newAppender( "syslogAppender", "Syslog" )
> > >.addAttribute( "protocol", "TCP" )
> > >.addAttribute( "host", "localhost" )
> > >.addAttribute( "port", 514 )
> > >.addAttribute( "facility", "LOCAL2" )
> > >.addAttribute( "immediateFlush", true )
> > >.addAttribute( "newLine", true );
> > >
> > > Then, after I finish creating the builder I use the
> > > Configurator.initialize( builder.build() ) to get the LoggerContext.
> > >
> > > Is there any way I can access the attributes of the appender through
> the
> > > LoggerContext?
> > >
> > > For example something like this:
> > >
> > > LoggerContext ctx = Configurator.initialize( builder.build() );
> > >
> > > String hostname =
> > >
> >
> ctx.getConfiguration()..getAppenders().get("syslogAppender").getAttribute("host");
> > >
> > > Thank you all very much for your help.
> > >
> > > Apostolis
> >
> >
> >
> > -
> > To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
> > For additional commands, e-mail: log4j-user-h...@logging.apache.org
> >
> >
>



-- 
Matt Sicker 

Re: Getter method for retrieving the attributes of an appender from the LoggerContext

[Gary Gregory]

How about adding getters for the fields
in org.apache.logging.log4j.core.net.AbstractSocketManager?

Gary

On Tue, Jan 26, 2016 at 12:20 PM, Matt Sicker  wrote:

> You could always use reflection to access it for now.
>
> On 26 January 2016 at 14:17, Apostolis Giannakidis <
> ap.giannaki...@gmail.com
> > wrote:
>
> > Thank you very much for the prompt reply Ralph.
> >
> > As far as I can see, the SyslogAppender class does not expose a way to
> > access these attributes. So, if there is no other way of accessing these
> > attributes, then I am not able to retrieve the attributes that I want
> from
> > the existing SyslogAppender implementation. If I understand correctly,
> > correct me if I am wrong, I might have to create my own that exposes
> these
> > attributes.
> >
> > Apos
> >
> > On Tue, Jan 26, 2016 at 8:03 PM, Ralph Goers  >
> > wrote:
> >
> > > Not exactly. You can do:
> > >
> > > Appender appender =
> ctx.getConfiguration().getAppender(“syslogAppender”);
> > >
> > > then you would have to do
> > >
> > > SyslogAppender syslogAppender = (SyslogAppender) appender;
> > >
> > > normally you would probably use instanceof to verify it is actually a
> > > SyslogAppender.
> > >
> > > Once you have that you can call whatever methods the SyslogAppender
> > > exposes for getting its attributes. They are not stored in a Map
> however,
> > > so you can’t just call a generic getAttribute method.
> > >
> > > Ralph
> > >
> > >
> > > > On Jan 26, 2016, at 11:58 AM, Apostolis Giannakidis <
> > > ap.giannaki...@gmail.com> wrote:
> > > >
> > > > Hello team,
> > > >
> > > > I have created a logger with an appender using the
> ConfigurationBuilder
> > > and
> > > > the AppenderComponentBuilder.
> > > >
> > > > Let's say that this is how I create my appender:
> > > >
> > > > AppenderComponentBuilder appenderBuilder =
> > > >builder.newAppender( "syslogAppender", "Syslog" )
> > > >.addAttribute( "protocol", "TCP" )
> > > >.addAttribute( "host", "localhost" )
> > > >.addAttribute( "port", 514 )
> > > >.addAttribute( "facility", "LOCAL2" )
> > > >.addAttribute( "immediateFlush", true )
> > > >.addAttribute( "newLine", true );
> > > >
> > > > Then, after I finish creating the builder I use the
> > > > Configurator.initialize( builder.build() ) to get the LoggerContext.
> > > >
> > > > Is there any way I can access the attributes of the appender through
> > the
> > > > LoggerContext?
> > > >
> > > > For example something like this:
> > > >
> > > > LoggerContext ctx = Configurator.initialize( builder.build() );
> > > >
> > > > String hostname =
> > > >
> > >
> >
> ctx.getConfiguration()..getAppenders().get("syslogAppender").getAttribute("host");
> > > >
> > > > Thank you all very much for your help.
> > > >
> > > > Apostolis
> > >
> > >
> > >
> > > -
> > > To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
> > > For additional commands, e-mail: log4j-user-h...@logging.apache.org
> > >
> > >
> >
>
>
>
> --
> Matt Sicker 
>



-- 
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
Java Persistence with Hibernate, Second Edition

JUnit in Action, Second Edition 
Spring Batch in Action 
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

Re: Getter method for retrieving the attributes of an appender from the LoggerContext

[Ralph Goers]

Actually, I kind of like the idea of adding a getAttributes() method to the 
Appender interface. Then each concrete Appender would do:

public void getAttributes() {
Map attributes = new HashMap<>();
super.getAttributes(attributes):
attributes.put(“myAttribute1”, “value1”);
return Collections.unmodifiableMap(attributes);
}



> On Jan 26, 2016, at 1:28 PM, Gary Gregory  wrote:
> 
> How about adding getters for the fields
> in org.apache.logging.log4j.core.net.AbstractSocketManager?
> 
> Gary
> 
> On Tue, Jan 26, 2016 at 12:20 PM, Matt Sicker  wrote:
> 
>> You could always use reflection to access it for now.
>> 
>> On 26 January 2016 at 14:17, Apostolis Giannakidis <
>> ap.giannaki...@gmail.com
>>> wrote:
>> 
>>> Thank you very much for the prompt reply Ralph.
>>> 
>>> As far as I can see, the SyslogAppender class does not expose a way to
>>> access these attributes. So, if there is no other way of accessing these
>>> attributes, then I am not able to retrieve the attributes that I want
>> from
>>> the existing SyslogAppender implementation. If I understand correctly,
>>> correct me if I am wrong, I might have to create my own that exposes
>> these
>>> attributes.
>>> 
>>> Apos
>>> 
>>> On Tue, Jan 26, 2016 at 8:03 PM, Ralph Goers >> 
>>> wrote:
>>> 
 Not exactly. You can do:
 
 Appender appender =
>> ctx.getConfiguration().getAppender(“syslogAppender”);
 
 then you would have to do
 
 SyslogAppender syslogAppender = (SyslogAppender) appender;
 
 normally you would probably use instanceof to verify it is actually a
 SyslogAppender.
 
 Once you have that you can call whatever methods the SyslogAppender
 exposes for getting its attributes. They are not stored in a Map
>> however,
 so you can’t just call a generic getAttribute method.
 
 Ralph
 
 
> On Jan 26, 2016, at 11:58 AM, Apostolis Giannakidis <
 ap.giannaki...@gmail.com> wrote:
> 
> Hello team,
> 
> I have created a logger with an appender using the
>> ConfigurationBuilder
 and
> the AppenderComponentBuilder.
> 
> Let's say that this is how I create my appender:
> 
> AppenderComponentBuilder appenderBuilder =
>   builder.newAppender( "syslogAppender", "Syslog" )
>   .addAttribute( "protocol", "TCP" )
>   .addAttribute( "host", "localhost" )
>   .addAttribute( "port", 514 )
>   .addAttribute( "facility", "LOCAL2" )
>   .addAttribute( "immediateFlush", true )
>   .addAttribute( "newLine", true );
> 
> Then, after I finish creating the builder I use the
> Configurator.initialize( builder.build() ) to get the LoggerContext.
> 
> Is there any way I can access the attributes of the appender through
>>> the
> LoggerContext?
> 
> For example something like this:
> 
> LoggerContext ctx = Configurator.initialize( builder.build() );
> 
> String hostname =
> 
 
>>> 
>> ctx.getConfiguration()..getAppenders().get("syslogAppender").getAttribute("host");
> 
> Thank you all very much for your help.
> 
> Apostolis
 
 
 
 -
 To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
 For additional commands, e-mail: log4j-user-h...@logging.apache.org
 
 
>>> 
>> 
>> 
>> 
>> --
>> Matt Sicker 
>> 
> 
> 
> 
> -- 
> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
> Java Persistence with Hibernate, Second Edition
> 
> JUnit in Action, Second Edition 
> Spring Batch in Action 
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory



-
To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-user-h...@logging.apache.org

Re: Getter method for retrieving the attributes of an appender from the LoggerContext

[Apostolis Giannakidis]

Actually, since this seems to be a useful feature, I would love to do the
patch myself and contribute it to the project, if you don't mind.

On Tue, Jan 26, 2016 at 8:56 PM, Ralph Goers 
wrote:

> Actually, I kind of like the idea of adding a getAttributes() method to
> the Appender interface. Then each concrete Appender would do:
>
> public void getAttributes() {
> Map attributes = new HashMap<>();
> super.getAttributes(attributes):
> attributes.put(“myAttribute1”, “value1”);
> return Collections.unmodifiableMap(attributes);
> }
>
>
>
> > On Jan 26, 2016, at 1:28 PM, Gary Gregory 
> wrote:
> >
> > How about adding getters for the fields
> > in org.apache.logging.log4j.core.net.AbstractSocketManager?
> >
> > Gary
> >
> > On Tue, Jan 26, 2016 at 12:20 PM, Matt Sicker  wrote:
> >
> >> You could always use reflection to access it for now.
> >>
> >> On 26 January 2016 at 14:17, Apostolis Giannakidis <
> >> ap.giannaki...@gmail.com
> >>> wrote:
> >>
> >>> Thank you very much for the prompt reply Ralph.
> >>>
> >>> As far as I can see, the SyslogAppender class does not expose a way to
> >>> access these attributes. So, if there is no other way of accessing
> these
> >>> attributes, then I am not able to retrieve the attributes that I want
> >> from
> >>> the existing SyslogAppender implementation. If I understand correctly,
> >>> correct me if I am wrong, I might have to create my own that exposes
> >> these
> >>> attributes.
> >>>
> >>> Apos
> >>>
> >>> On Tue, Jan 26, 2016 at 8:03 PM, Ralph Goers <
> ralph.go...@dslextreme.com
> >>>
> >>> wrote:
> >>>
>  Not exactly. You can do:
> 
>  Appender appender =
> >> ctx.getConfiguration().getAppender(“syslogAppender”);
> 
>  then you would have to do
> 
>  SyslogAppender syslogAppender = (SyslogAppender) appender;
> 
>  normally you would probably use instanceof to verify it is actually a
>  SyslogAppender.
> 
>  Once you have that you can call whatever methods the SyslogAppender
>  exposes for getting its attributes. They are not stored in a Map
> >> however,
>  so you can’t just call a generic getAttribute method.
> 
>  Ralph
> 
> 
> > On Jan 26, 2016, at 11:58 AM, Apostolis Giannakidis <
>  ap.giannaki...@gmail.com> wrote:
> >
> > Hello team,
> >
> > I have created a logger with an appender using the
> >> ConfigurationBuilder
>  and
> > the AppenderComponentBuilder.
> >
> > Let's say that this is how I create my appender:
> >
> > AppenderComponentBuilder appenderBuilder =
> >   builder.newAppender( "syslogAppender", "Syslog" )
> >   .addAttribute( "protocol", "TCP" )
> >   .addAttribute( "host", "localhost" )
> >   .addAttribute( "port", 514 )
> >   .addAttribute( "facility", "LOCAL2" )
> >   .addAttribute( "immediateFlush", true )
> >   .addAttribute( "newLine", true );
> >
> > Then, after I finish creating the builder I use the
> > Configurator.initialize( builder.build() ) to get the LoggerContext.
> >
> > Is there any way I can access the attributes of the appender through
> >>> the
> > LoggerContext?
> >
> > For example something like this:
> >
> > LoggerContext ctx = Configurator.initialize( builder.build() );
> >
> > String hostname =
> >
> 
> >>>
> >>
> ctx.getConfiguration()..getAppenders().get("syslogAppender").getAttribute("host");
> >
> > Thank you all very much for your help.
> >
> > Apostolis
> 
> 
> 
>  -
>  To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
>  For additional commands, e-mail: log4j-user-h...@logging.apache.org
> 
> 
> >>>
> >>
> >>
> >>
> >> --
> >> Matt Sicker 
> >>
> >
> >
> >
> > --
> > E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
> > Java Persistence with Hibernate, Second Edition
> > 
> > JUnit in Action, Second Edition 
> > Spring Batch in Action 
> > Blog: http://garygregory.wordpress.com
> > Home: http://garygregory.com/
> > Tweet! http://twitter.com/GaryGregory
>
>
>
> -
> To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
> For additional commands, e-mail: log4j-user-h...@logging.apache.org
>
>

Re: Getter method for retrieving the attributes of an appender from the LoggerContext

[Gary Gregory]

On Tue, Jan 26, 2016 at 1:06 PM, Apostolis Giannakidis <
ap.giannaki...@gmail.com> wrote:

> Actually, since this seems to be a useful feature, I would love to do the
> patch myself and contribute it to the project, if you don't mind.
>

Do you plan on implementing this for all Appenders?

Gary

>
> On Tue, Jan 26, 2016 at 8:56 PM, Ralph Goers 
> wrote:
>
> > Actually, I kind of like the idea of adding a getAttributes() method to
> > the Appender interface. Then each concrete Appender would do:
> >
> > public void getAttributes() {
> > Map attributes = new HashMap<>();
> > super.getAttributes(attributes):
> > attributes.put(“myAttribute1”, “value1”);
> > return Collections.unmodifiableMap(attributes);
> > }
> >
> >
> >
> > > On Jan 26, 2016, at 1:28 PM, Gary Gregory 
> > wrote:
> > >
> > > How about adding getters for the fields
> > > in org.apache.logging.log4j.core.net.AbstractSocketManager?
> > >
> > > Gary
> > >
> > > On Tue, Jan 26, 2016 at 12:20 PM, Matt Sicker 
> wrote:
> > >
> > >> You could always use reflection to access it for now.
> > >>
> > >> On 26 January 2016 at 14:17, Apostolis Giannakidis <
> > >> ap.giannaki...@gmail.com
> > >>> wrote:
> > >>
> > >>> Thank you very much for the prompt reply Ralph.
> > >>>
> > >>> As far as I can see, the SyslogAppender class does not expose a way
> to
> > >>> access these attributes. So, if there is no other way of accessing
> > these
> > >>> attributes, then I am not able to retrieve the attributes that I want
> > >> from
> > >>> the existing SyslogAppender implementation. If I understand
> correctly,
> > >>> correct me if I am wrong, I might have to create my own that exposes
> > >> these
> > >>> attributes.
> > >>>
> > >>> Apos
> > >>>
> > >>> On Tue, Jan 26, 2016 at 8:03 PM, Ralph Goers <
> > ralph.go...@dslextreme.com
> > >>>
> > >>> wrote:
> > >>>
> >  Not exactly. You can do:
> > 
> >  Appender appender =
> > >> ctx.getConfiguration().getAppender(“syslogAppender”);
> > 
> >  then you would have to do
> > 
> >  SyslogAppender syslogAppender = (SyslogAppender) appender;
> > 
> >  normally you would probably use instanceof to verify it is actually
> a
> >  SyslogAppender.
> > 
> >  Once you have that you can call whatever methods the SyslogAppender
> >  exposes for getting its attributes. They are not stored in a Map
> > >> however,
> >  so you can’t just call a generic getAttribute method.
> > 
> >  Ralph
> > 
> > 
> > > On Jan 26, 2016, at 11:58 AM, Apostolis Giannakidis <
> >  ap.giannaki...@gmail.com> wrote:
> > >
> > > Hello team,
> > >
> > > I have created a logger with an appender using the
> > >> ConfigurationBuilder
> >  and
> > > the AppenderComponentBuilder.
> > >
> > > Let's say that this is how I create my appender:
> > >
> > > AppenderComponentBuilder appenderBuilder =
> > >   builder.newAppender( "syslogAppender", "Syslog" )
> > >   .addAttribute( "protocol", "TCP" )
> > >   .addAttribute( "host", "localhost" )
> > >   .addAttribute( "port", 514 )
> > >   .addAttribute( "facility", "LOCAL2" )
> > >   .addAttribute( "immediateFlush", true )
> > >   .addAttribute( "newLine", true );
> > >
> > > Then, after I finish creating the builder I use the
> > > Configurator.initialize( builder.build() ) to get the
> LoggerContext.
> > >
> > > Is there any way I can access the attributes of the appender
> through
> > >>> the
> > > LoggerContext?
> > >
> > > For example something like this:
> > >
> > > LoggerContext ctx = Configurator.initialize( builder.build() );
> > >
> > > String hostname =
> > >
> > 
> > >>>
> > >>
> >
> ctx.getConfiguration()..getAppenders().get("syslogAppender").getAttribute("host");
> > >
> > > Thank you all very much for your help.
> > >
> > > Apostolis
> > 
> > 
> > 
> > 
> -
> >  To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
> >  For additional commands, e-mail: log4j-user-h...@logging.apache.org
> > 
> > 
> > >>>
> > >>
> > >>
> > >>
> > >> --
> > >> Matt Sicker 
> > >>
> > >
> > >
> > >
> > > --
> > > E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
> > > Java Persistence with Hibernate, Second Edition
> > > 
> > > JUnit in Action, Second Edition 
> > > Spring Batch in Action 
> > > Blog: http://garygregory.wordpress.com
> > > Home: http://garygregory.com/
> > > Tweet! http://twitter.com/GaryGregory
> >
> >
> >
> > -

Re: Getter method for retrieving the attributes of an appender from the LoggerContext

[Apostolis Giannakidis]

Well, since the idea is to add it to the Appender interface, it means that
all concrete Appenders need to be modified as well. So, yes, I can give it
a try to implement it for all the Appenders. One other simple way would be
to implement it once in the AbstractAppender so that all its subclasses
will inherit it.

On Tue, Jan 26, 2016 at 9:15 PM, Gary Gregory 
wrote:

> On Tue, Jan 26, 2016 at 1:06 PM, Apostolis Giannakidis <
> ap.giannaki...@gmail.com> wrote:
>
> > Actually, since this seems to be a useful feature, I would love to do the
> > patch myself and contribute it to the project, if you don't mind.
> >
>
> Do you plan on implementing this for all Appenders?
>
> Gary
>
> >
> > On Tue, Jan 26, 2016 at 8:56 PM, Ralph Goers  >
> > wrote:
> >
> > > Actually, I kind of like the idea of adding a getAttributes() method to
> > > the Appender interface. Then each concrete Appender would do:
> > >
> > > public void getAttributes() {
> > > Map attributes = new HashMap<>();
> > > super.getAttributes(attributes):
> > > attributes.put(“myAttribute1”, “value1”);
> > > return Collections.unmodifiableMap(attributes);
> > > }
> > >
> > >
> > >
> > > > On Jan 26, 2016, at 1:28 PM, Gary Gregory 
> > > wrote:
> > > >
> > > > How about adding getters for the fields
> > > > in org.apache.logging.log4j.core.net.AbstractSocketManager?
> > > >
> > > > Gary
> > > >
> > > > On Tue, Jan 26, 2016 at 12:20 PM, Matt Sicker 
> > wrote:
> > > >
> > > >> You could always use reflection to access it for now.
> > > >>
> > > >> On 26 January 2016 at 14:17, Apostolis Giannakidis <
> > > >> ap.giannaki...@gmail.com
> > > >>> wrote:
> > > >>
> > > >>> Thank you very much for the prompt reply Ralph.
> > > >>>
> > > >>> As far as I can see, the SyslogAppender class does not expose a way
> > to
> > > >>> access these attributes. So, if there is no other way of accessing
> > > these
> > > >>> attributes, then I am not able to retrieve the attributes that I
> want
> > > >> from
> > > >>> the existing SyslogAppender implementation. If I understand
> > correctly,
> > > >>> correct me if I am wrong, I might have to create my own that
> exposes
> > > >> these
> > > >>> attributes.
> > > >>>
> > > >>> Apos
> > > >>>
> > > >>> On Tue, Jan 26, 2016 at 8:03 PM, Ralph Goers <
> > > ralph.go...@dslextreme.com
> > > >>>
> > > >>> wrote:
> > > >>>
> > >  Not exactly. You can do:
> > > 
> > >  Appender appender =
> > > >> ctx.getConfiguration().getAppender(“syslogAppender”);
> > > 
> > >  then you would have to do
> > > 
> > >  SyslogAppender syslogAppender = (SyslogAppender) appender;
> > > 
> > >  normally you would probably use instanceof to verify it is
> actually
> > a
> > >  SyslogAppender.
> > > 
> > >  Once you have that you can call whatever methods the
> SyslogAppender
> > >  exposes for getting its attributes. They are not stored in a Map
> > > >> however,
> > >  so you can’t just call a generic getAttribute method.
> > > 
> > >  Ralph
> > > 
> > > 
> > > > On Jan 26, 2016, at 11:58 AM, Apostolis Giannakidis <
> > >  ap.giannaki...@gmail.com> wrote:
> > > >
> > > > Hello team,
> > > >
> > > > I have created a logger with an appender using the
> > > >> ConfigurationBuilder
> > >  and
> > > > the AppenderComponentBuilder.
> > > >
> > > > Let's say that this is how I create my appender:
> > > >
> > > > AppenderComponentBuilder appenderBuilder =
> > > >   builder.newAppender( "syslogAppender", "Syslog" )
> > > >   .addAttribute( "protocol", "TCP" )
> > > >   .addAttribute( "host", "localhost" )
> > > >   .addAttribute( "port", 514 )
> > > >   .addAttribute( "facility", "LOCAL2" )
> > > >   .addAttribute( "immediateFlush", true )
> > > >   .addAttribute( "newLine", true );
> > > >
> > > > Then, after I finish creating the builder I use the
> > > > Configurator.initialize( builder.build() ) to get the
> > LoggerContext.
> > > >
> > > > Is there any way I can access the attributes of the appender
> > through
> > > >>> the
> > > > LoggerContext?
> > > >
> > > > For example something like this:
> > > >
> > > > LoggerContext ctx = Configurator.initialize( builder.build() );
> > > >
> > > > String hostname =
> > > >
> > > 
> > > >>>
> > > >>
> > >
> >
> ctx.getConfiguration()..getAppenders().get("syslogAppender").getAttribute("host");
> > > >
> > > > Thank you all very much for your help.
> > > >
> > > > Apostolis
> > > 
> > > 
> > > 
> > > 
> > -
> > >  To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
> > >  For additional 

Re: Getter method for retrieving the attributes of an appender from the LoggerContext

[Gary Gregory]

I could see AbstractAppender implementing a getAttributes() method like
this:

public Map getAttributes() {
Map map = new HashMap<>();
fillAttributeMap(map);
// (1) should the map be read-only? why?
// (2) if the map is cached in an ivar, the it must be updated by
each appender when an attribute changes, so
// I'd say no and follow the KISS principle for now.
return map;
}

protected void fillAttributeMap(Map map) {
// ...
}

The boilerplate of creating and/or managing the map can be in getAttributes().
Actually filling in the map in is done in fillAttributeMap() which each
appender can override.

fillAttributeMap() could be abstract to force each appender to make sure
developers pay attention to providing an implementation.

Gary


On Tue, Jan 26, 2016 at 3:46 PM, Apostolis Giannakidis <
ap.giannaki...@gmail.com> wrote:

> Well, since the idea is to add it to the Appender interface, it means that
> all concrete Appenders need to be modified as well. So, yes, I can give it
> a try to implement it for all the Appenders. One other simple way would be
> to implement it once in the AbstractAppender so that all its subclasses
> will inherit it.
>
> On Tue, Jan 26, 2016 at 9:15 PM, Gary Gregory 
> wrote:
>
> > On Tue, Jan 26, 2016 at 1:06 PM, Apostolis Giannakidis <
> > ap.giannaki...@gmail.com> wrote:
> >
> > > Actually, since this seems to be a useful feature, I would love to do
> the
> > > patch myself and contribute it to the project, if you don't mind.
> > >
> >
> > Do you plan on implementing this for all Appenders?
> >
> > Gary
> >
> > >
> > > On Tue, Jan 26, 2016 at 8:56 PM, Ralph Goers <
> ralph.go...@dslextreme.com
> > >
> > > wrote:
> > >
> > > > Actually, I kind of like the idea of adding a getAttributes() method
> to
> > > > the Appender interface. Then each concrete Appender would do:
> > > >
> > > > public void getAttributes() {
> > > > Map attributes = new HashMap<>();
> > > > super.getAttributes(attributes):
> > > > attributes.put(“myAttribute1”, “value1”);
> > > > return Collections.unmodifiableMap(attributes);
> > > > }
> > > >
> > > >
> > > >
> > > > > On Jan 26, 2016, at 1:28 PM, Gary Gregory 
> > > > wrote:
> > > > >
> > > > > How about adding getters for the fields
> > > > > in org.apache.logging.log4j.core.net.AbstractSocketManager?
> > > > >
> > > > > Gary
> > > > >
> > > > > On Tue, Jan 26, 2016 at 12:20 PM, Matt Sicker 
> > > wrote:
> > > > >
> > > > >> You could always use reflection to access it for now.
> > > > >>
> > > > >> On 26 January 2016 at 14:17, Apostolis Giannakidis <
> > > > >> ap.giannaki...@gmail.com
> > > > >>> wrote:
> > > > >>
> > > > >>> Thank you very much for the prompt reply Ralph.
> > > > >>>
> > > > >>> As far as I can see, the SyslogAppender class does not expose a
> way
> > > to
> > > > >>> access these attributes. So, if there is no other way of
> accessing
> > > > these
> > > > >>> attributes, then I am not able to retrieve the attributes that I
> > want
> > > > >> from
> > > > >>> the existing SyslogAppender implementation. If I understand
> > > correctly,
> > > > >>> correct me if I am wrong, I might have to create my own that
> > exposes
> > > > >> these
> > > > >>> attributes.
> > > > >>>
> > > > >>> Apos
> > > > >>>
> > > > >>> On Tue, Jan 26, 2016 at 8:03 PM, Ralph Goers <
> > > > ralph.go...@dslextreme.com
> > > > >>>
> > > > >>> wrote:
> > > > >>>
> > > >  Not exactly. You can do:
> > > > 
> > > >  Appender appender =
> > > > >> ctx.getConfiguration().getAppender(“syslogAppender”);
> > > > 
> > > >  then you would have to do
> > > > 
> > > >  SyslogAppender syslogAppender = (SyslogAppender) appender;
> > > > 
> > > >  normally you would probably use instanceof to verify it is
> > actually
> > > a
> > > >  SyslogAppender.
> > > > 
> > > >  Once you have that you can call whatever methods the
> > SyslogAppender
> > > >  exposes for getting its attributes. They are not stored in a Map
> > > > >> however,
> > > >  so you can’t just call a generic getAttribute method.
> > > > 
> > > >  Ralph
> > > > 
> > > > 
> > > > > On Jan 26, 2016, at 11:58 AM, Apostolis Giannakidis <
> > > >  ap.giannaki...@gmail.com> wrote:
> > > > >
> > > > > Hello team,
> > > > >
> > > > > I have created a logger with an appender using the
> > > > >> ConfigurationBuilder
> > > >  and
> > > > > the AppenderComponentBuilder.
> > > > >
> > > > > Let's say that this is how I create my appender:
> > > > >
> > > > > AppenderComponentBuilder appenderBuilder =
> > > > >   builder.newAppender( "syslogAppender", "Syslog" )
> > > > >   .addAttribute( "protocol", "TCP" )
> > > > >   .addAttribute( "host", 

Re: Getter method for retrieving the attributes of an appender from the LoggerContext

[Apostolis Giannakidis]

One thing to note here. Correct me if I am wrong, but the map should
be Map because not all attributes are Strings. From the top of my head, I
know that an attribute could also be a boolean.

On Wed, Jan 27, 2016 at 12:06 AM, Gary Gregory 
wrote:

> I could see AbstractAppender implementing a getAttributes() method like
> this:
>
> public Map getAttributes() {
> Map map = new HashMap<>();
> fillAttributeMap(map);
> // (1) should the map be read-only? why?
> // (2) if the map is cached in an ivar, the it must be updated by
> each appender when an attribute changes, so
> // I'd say no and follow the KISS principle for now.
> return map;
> }
>
> protected void fillAttributeMap(Map map) {
> // ...
> }
>
> The boilerplate of creating and/or managing the map can be in
> getAttributes().
> Actually filling in the map in is done in fillAttributeMap() which each
> appender can override.
>
> fillAttributeMap() could be abstract to force each appender to make sure
> developers pay attention to providing an implementation.
>
> Gary
>
>
> On Tue, Jan 26, 2016 at 3:46 PM, Apostolis Giannakidis <
> ap.giannaki...@gmail.com> wrote:
>
> > Well, since the idea is to add it to the Appender interface, it means
> that
> > all concrete Appenders need to be modified as well. So, yes, I can give
> it
> > a try to implement it for all the Appenders. One other simple way would
> be
> > to implement it once in the AbstractAppender so that all its subclasses
> > will inherit it.
> >
> > On Tue, Jan 26, 2016 at 9:15 PM, Gary Gregory 
> > wrote:
> >
> > > On Tue, Jan 26, 2016 at 1:06 PM, Apostolis Giannakidis <
> > > ap.giannaki...@gmail.com> wrote:
> > >
> > > > Actually, since this seems to be a useful feature, I would love to do
> > the
> > > > patch myself and contribute it to the project, if you don't mind.
> > > >
> > >
> > > Do you plan on implementing this for all Appenders?
> > >
> > > Gary
> > >
> > > >
> > > > On Tue, Jan 26, 2016 at 8:56 PM, Ralph Goers <
> > ralph.go...@dslextreme.com
> > > >
> > > > wrote:
> > > >
> > > > > Actually, I kind of like the idea of adding a getAttributes()
> method
> > to
> > > > > the Appender interface. Then each concrete Appender would do:
> > > > >
> > > > > public void getAttributes() {
> > > > > Map attributes = new HashMap<>();
> > > > > super.getAttributes(attributes):
> > > > > attributes.put(“myAttribute1”, “value1”);
> > > > > return Collections.unmodifiableMap(attributes);
> > > > > }
> > > > >
> > > > >
> > > > >
> > > > > > On Jan 26, 2016, at 1:28 PM, Gary Gregory <
> garydgreg...@gmail.com>
> > > > > wrote:
> > > > > >
> > > > > > How about adding getters for the fields
> > > > > > in org.apache.logging.log4j.core.net.AbstractSocketManager?
> > > > > >
> > > > > > Gary
> > > > > >
> > > > > > On Tue, Jan 26, 2016 at 12:20 PM, Matt Sicker 
> > > > wrote:
> > > > > >
> > > > > >> You could always use reflection to access it for now.
> > > > > >>
> > > > > >> On 26 January 2016 at 14:17, Apostolis Giannakidis <
> > > > > >> ap.giannaki...@gmail.com
> > > > > >>> wrote:
> > > > > >>
> > > > > >>> Thank you very much for the prompt reply Ralph.
> > > > > >>>
> > > > > >>> As far as I can see, the SyslogAppender class does not expose a
> > way
> > > > to
> > > > > >>> access these attributes. So, if there is no other way of
> > accessing
> > > > > these
> > > > > >>> attributes, then I am not able to retrieve the attributes that
> I
> > > want
> > > > > >> from
> > > > > >>> the existing SyslogAppender implementation. If I understand
> > > > correctly,
> > > > > >>> correct me if I am wrong, I might have to create my own that
> > > exposes
> > > > > >> these
> > > > > >>> attributes.
> > > > > >>>
> > > > > >>> Apos
> > > > > >>>
> > > > > >>> On Tue, Jan 26, 2016 at 8:03 PM, Ralph Goers <
> > > > > ralph.go...@dslextreme.com
> > > > > >>>
> > > > > >>> wrote:
> > > > > >>>
> > > > >  Not exactly. You can do:
> > > > > 
> > > > >  Appender appender =
> > > > > >> ctx.getConfiguration().getAppender(“syslogAppender”);
> > > > > 
> > > > >  then you would have to do
> > > > > 
> > > > >  SyslogAppender syslogAppender = (SyslogAppender) appender;
> > > > > 
> > > > >  normally you would probably use instanceof to verify it is
> > > actually
> > > > a
> > > > >  SyslogAppender.
> > > > > 
> > > > >  Once you have that you can call whatever methods the
> > > SyslogAppender
> > > > >  exposes for getting its attributes. They are not stored in a
> Map
> > > > > >> however,
> > > > >  so you can’t just call a generic getAttribute method.
> > > > > 
> > > > >  Ralph
> > > > > 
> > > > > 
> > > > > > On Jan 26, 2016, at 11:58 AM, Apostolis Giannakidis <
> > > > >  

Re: Getter method for retrieving the attributes of an appender from the LoggerContext

[Gary Gregory]

Sure, Object makes sense.

Gary

On Tue, Jan 26, 2016 at 4:24 PM, Apostolis Giannakidis <
ap.giannaki...@gmail.com> wrote:

> One thing to note here. Correct me if I am wrong, but the map should
> be Map Object> because not all attributes are Strings. From the top of my head, I
> know that an attribute could also be a boolean.
>
> On Wed, Jan 27, 2016 at 12:06 AM, Gary Gregory 
> wrote:
>
> > I could see AbstractAppender implementing a getAttributes() method like
> > this:
> >
> > public Map getAttributes() {
> > Map map = new HashMap<>();
> > fillAttributeMap(map);
> > // (1) should the map be read-only? why?
> > // (2) if the map is cached in an ivar, the it must be updated by
> > each appender when an attribute changes, so
> > // I'd say no and follow the KISS principle for now.
> > return map;
> > }
> >
> > protected void fillAttributeMap(Map map) {
> > // ...
> > }
> >
> > The boilerplate of creating and/or managing the map can be in
> > getAttributes().
> > Actually filling in the map in is done in fillAttributeMap() which each
> > appender can override.
> >
> > fillAttributeMap() could be abstract to force each appender to make sure
> > developers pay attention to providing an implementation.
> >
> > Gary
> >
> >
> > On Tue, Jan 26, 2016 at 3:46 PM, Apostolis Giannakidis <
> > ap.giannaki...@gmail.com> wrote:
> >
> > > Well, since the idea is to add it to the Appender interface, it means
> > that
> > > all concrete Appenders need to be modified as well. So, yes, I can give
> > it
> > > a try to implement it for all the Appenders. One other simple way would
> > be
> > > to implement it once in the AbstractAppender so that all its subclasses
> > > will inherit it.
> > >
> > > On Tue, Jan 26, 2016 at 9:15 PM, Gary Gregory 
> > > wrote:
> > >
> > > > On Tue, Jan 26, 2016 at 1:06 PM, Apostolis Giannakidis <
> > > > ap.giannaki...@gmail.com> wrote:
> > > >
> > > > > Actually, since this seems to be a useful feature, I would love to
> do
> > > the
> > > > > patch myself and contribute it to the project, if you don't mind.
> > > > >
> > > >
> > > > Do you plan on implementing this for all Appenders?
> > > >
> > > > Gary
> > > >
> > > > >
> > > > > On Tue, Jan 26, 2016 at 8:56 PM, Ralph Goers <
> > > ralph.go...@dslextreme.com
> > > > >
> > > > > wrote:
> > > > >
> > > > > > Actually, I kind of like the idea of adding a getAttributes()
> > method
> > > to
> > > > > > the Appender interface. Then each concrete Appender would do:
> > > > > >
> > > > > > public void getAttributes() {
> > > > > > Map attributes = new HashMap<>();
> > > > > > super.getAttributes(attributes):
> > > > > > attributes.put(“myAttribute1”, “value1”);
> > > > > > return Collections.unmodifiableMap(attributes);
> > > > > > }
> > > > > >
> > > > > >
> > > > > >
> > > > > > > On Jan 26, 2016, at 1:28 PM, Gary Gregory <
> > garydgreg...@gmail.com>
> > > > > > wrote:
> > > > > > >
> > > > > > > How about adding getters for the fields
> > > > > > > in org.apache.logging.log4j.core.net.AbstractSocketManager?
> > > > > > >
> > > > > > > Gary
> > > > > > >
> > > > > > > On Tue, Jan 26, 2016 at 12:20 PM, Matt Sicker <
> boa...@gmail.com>
> > > > > wrote:
> > > > > > >
> > > > > > >> You could always use reflection to access it for now.
> > > > > > >>
> > > > > > >> On 26 January 2016 at 14:17, Apostolis Giannakidis <
> > > > > > >> ap.giannaki...@gmail.com
> > > > > > >>> wrote:
> > > > > > >>
> > > > > > >>> Thank you very much for the prompt reply Ralph.
> > > > > > >>>
> > > > > > >>> As far as I can see, the SyslogAppender class does not
> expose a
> > > way
> > > > > to
> > > > > > >>> access these attributes. So, if there is no other way of
> > > accessing
> > > > > > these
> > > > > > >>> attributes, then I am not able to retrieve the attributes
> that
> > I
> > > > want
> > > > > > >> from
> > > > > > >>> the existing SyslogAppender implementation. If I understand
> > > > > correctly,
> > > > > > >>> correct me if I am wrong, I might have to create my own that
> > > > exposes
> > > > > > >> these
> > > > > > >>> attributes.
> > > > > > >>>
> > > > > > >>> Apos
> > > > > > >>>
> > > > > > >>> On Tue, Jan 26, 2016 at 8:03 PM, Ralph Goers <
> > > > > > ralph.go...@dslextreme.com
> > > > > > >>>
> > > > > > >>> wrote:
> > > > > > >>>
> > > > > >  Not exactly. You can do:
> > > > > > 
> > > > > >  Appender appender =
> > > > > > >> ctx.getConfiguration().getAppender(“syslogAppender”);
> > > > > > 
> > > > > >  then you would have to do
> > > > > > 
> > > > > >  SyslogAppender syslogAppender = (SyslogAppender) appender;
> > > > > > 
> > > > > >  normally you would probably use instanceof to verify it is
> > > > actually
> > > > > a
> > > > > >  SyslogAppender.
> > > > > > 
> > > > > >  Once 

Re: Getter method for retrieving the attributes of an appender from the LoggerContext

[Ralph Goers]

All the attributes have to have String representations to be usable in the XML, 
JSON & Properties configurations. Yes, the Map could contain Objects but then 
every one of them has to be cast to its real object to be usable. 

The map should be read-only because modifying its contents would have no effect 
on the appender.

The map should not be stored in an ivar but constructed whenever the attributes 
are retrieved. Otherwise it will be temping to just keep them in a map and not 
as individual attributes, which would cause problems.

If you have nesting such as  MyAppender extends MyBaseAppender extends 
AbstractOutputStreamAppender extends AbstractAppender, I envision a 
fillAttributes method at each “level” that fills in the attributes it knows 
about, so fillAttributeMap(map) should always call super.fillAttributeMap(map) 
- except in AbstractAppender of course - and should call it before filling in 
its own attributes so that it can override any values provided by the base 
Appenders.  If the primary Appender does not implement fillAttributeMap then 
only the attributes of its super classes will be included, which is actually 
correct for the SyslogAppender.

Ralph

> On Jan 26, 2016, at 5:24 PM, Apostolis Giannakidis  
> wrote:
> 
> One thing to note here. Correct me if I am wrong, but the map should
> be Map Object> because not all attributes are Strings. From the top of my head, I
> know that an attribute could also be a boolean.
> 
> On Wed, Jan 27, 2016 at 12:06 AM, Gary Gregory 
> wrote:
> 
>> I could see AbstractAppender implementing a getAttributes() method like
>> this:
>> 
>>public Map getAttributes() {
>>Map map = new HashMap<>();
>>fillAttributeMap(map);
>>// (1) should the map be read-only? why?
>>// (2) if the map is cached in an ivar, the it must be updated by
>> each appender when an attribute changes, so
>>// I'd say no and follow the KISS principle for now.
>>return map;
>>}
>> 
>>protected void fillAttributeMap(Map map) {
>>// ...
>>}
>> 
>> The boilerplate of creating and/or managing the map can be in
>> getAttributes().
>> Actually filling in the map in is done in fillAttributeMap() which each
>> appender can override.
>> 
>> fillAttributeMap() could be abstract to force each appender to make sure
>> developers pay attention to providing an implementation.
>> 
>> Gary
>> 
>> 
>> On Tue, Jan 26, 2016 at 3:46 PM, Apostolis Giannakidis <
>> ap.giannaki...@gmail.com> wrote:
>> 
>>> Well, since the idea is to add it to the Appender interface, it means
>> that
>>> all concrete Appenders need to be modified as well. So, yes, I can give
>> it
>>> a try to implement it for all the Appenders. One other simple way would
>> be
>>> to implement it once in the AbstractAppender so that all its subclasses
>>> will inherit it.
>>> 
>>> On Tue, Jan 26, 2016 at 9:15 PM, Gary Gregory 
>>> wrote:
>>> 
 On Tue, Jan 26, 2016 at 1:06 PM, Apostolis Giannakidis <
 ap.giannaki...@gmail.com> wrote:
 
> Actually, since this seems to be a useful feature, I would love to do
>>> the
> patch myself and contribute it to the project, if you don't mind.
> 
 
 Do you plan on implementing this for all Appenders?
 
 Gary
 
> 
> On Tue, Jan 26, 2016 at 8:56 PM, Ralph Goers <
>>> ralph.go...@dslextreme.com
> 
> wrote:
> 
>> Actually, I kind of like the idea of adding a getAttributes()
>> method
>>> to
>> the Appender interface. Then each concrete Appender would do:
>> 
>> public void getAttributes() {
>>Map attributes = new HashMap<>();
>>super.getAttributes(attributes):
>>attributes.put(“myAttribute1”, “value1”);
>>return Collections.unmodifiableMap(attributes);
>> }
>> 
>> 
>> 
>>> On Jan 26, 2016, at 1:28 PM, Gary Gregory <
>> garydgreg...@gmail.com>
>> wrote:
>>> 
>>> How about adding getters for the fields
>>> in org.apache.logging.log4j.core.net.AbstractSocketManager?
>>> 
>>> Gary
>>> 
>>> On Tue, Jan 26, 2016 at 12:20 PM, Matt Sicker 
> wrote:
>>> 
 You could always use reflection to access it for now.
 
 On 26 January 2016 at 14:17, Apostolis Giannakidis <
 ap.giannaki...@gmail.com
> wrote:
 
> Thank you very much for the prompt reply Ralph.
> 
> As far as I can see, the SyslogAppender class does not expose a
>>> way
> to
> access these attributes. So, if there is no other way of
>>> accessing
>> these
> attributes, then I am not able to retrieve the attributes that
>> I
 want
 from
> the existing SyslogAppender implementation. If I understand
> correctly,
> correct me if I am