logging-log4j-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ralph Goers <ralph.go...@dslextreme.com>
Subject Re: Getter method for retrieving the attributes of an appender from the LoggerContext
Date Wed, 27 Jan 2016 12:27:52 GMT
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.staldal@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 <garydgregory@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.goers@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.giannakidis@gmail.com> wrote:
>>>> 
>>>> One thing to note here. Correct me if I am wrong, but the map should
>>>> be Map<String,
>>>> 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 <garydgregory@gmail.com
>>> 
>>>> wrote:
>>>> 
>>>>> I could see AbstractAppender implementing a getAttributes() method
>> like
>>>>> this:
>>>>> 
>>>>>   public Map<String, String> getAttributes() {
>>>>>       Map<String, String> 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<String, String> 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.giannakidis@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 <
>> garydgregory@gmail.com>
>>>>>> wrote:
>>>>>> 
>>>>>>> On Tue, Jan 26, 2016 at 1:06 PM, Apostolis Giannakidis <
>>>>>>> ap.giannakidis@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.goers@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<String, String> attributes = new HashMap<>();
>>>>>>>>>   super.getAttributes(attributes):
>>>>>>>>>   attributes.put(“myAttribute1”, “value1”);
>>>>>>>>>   return Collections.unmodifiableMap(attributes);
>>>>>>>>> }
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>>> On Jan 26, 2016, at 1:28 PM, Gary Gregory <
>>>>> garydgregory@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 <boards@gmail.com>
>>>>>>>> wrote:
>>>>>>>>>> 
>>>>>>>>>>> You could always use reflection to access it
for now.
>>>>>>>>>>> 
>>>>>>>>>>> On 26 January 2016 at 14:17, Apostolis Giannakidis
<
>>>>>>>>>>> ap.giannakidis@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.goers@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.giannakidis@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-unsubscribe@logging.apache.org
>>>>>>>>>>>>> For additional commands, e-mail:
>>>>>>> log4j-user-help@logging.apache.org
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> --
>>>>>>>>>>> Matt Sicker <boards@gmail.com>
>>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> --
>>>>>>>>>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>>>>>>>>>> Java Persistence with Hibernate, Second Edition
>>>>>>>>>> <http://www.manning.com/bauer3/>
>>>>>>>>>> JUnit in Action, Second Edition <
>>>>> http://www.manning.com/tahchiev/>
>>>>>>>>>> Spring Batch in Action <http://www.manning.com/templier/>
>>>>>>>>>> Blog: http://garygregory.wordpress.com
>>>>>>>>>> Home: http://garygregory.com/
>>>>>>>>>> Tweet! http://twitter.com/GaryGregory
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>> ---------------------------------------------------------------------
>>>>>>>>> To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
>>>>>>>>> For additional commands, e-mail:
>>>>> log4j-user-help@logging.apache.org
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> --
>>>>>>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>>>>>>> Java Persistence with Hibernate, Second Edition
>>>>>>> <http://www.manning.com/bauer3/>
>>>>>>> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
>>>>>>> Spring Batch in Action <http://www.manning.com/templier/>
>>>>>>> Blog: http://garygregory.wordpress.com
>>>>>>> Home: http://garygregory.com/
>>>>>>> Tweet! http://twitter.com/GaryGregory
>>>>>>> 
>>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> --
>>>>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>>>>> Java Persistence with Hibernate, Second Edition
>>>>> <http://www.manning.com/bauer3/>
>>>>> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
>>>>> Spring Batch in Action <http://www.manning.com/templier/>
>>>>> Blog: http://garygregory.wordpress.com
>>>>> Home: http://garygregory.com/
>>>>> Tweet! http://twitter.com/GaryGregory
>>>>> 
>>> 
>>> 
>>> 
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
>>> For additional commands, e-mail: log4j-user-help@logging.apache.org
>>> 
>>> 
>> 
>> 
>> --
>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>> Java Persistence with Hibernate, Second Edition
>> <http://www.manning.com/bauer3/>
>> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
>> Spring Batch in Action <http://www.manning.com/templier/>
>> Blog: http://garygregory.wordpress.com
>> Home: http://garygregory.com/
>> Tweet! http://twitter.com/GaryGregory
>> 
> 
> 
> 
> -- 
> [image: MagineTV]
> 
> *Mikael Ståldal*
> Senior software developer
> 
> *Magine TV*
> mikael.staldal@magine.com
> Grev Turegatan 3  | 114 46 Stockholm, Sweden  |   www.magine.com
> 
> Privileged and/or Confidential Information may be contained in this
> message. If you are not the addressee indicated in this message
> (or responsible for delivery of the message to such a person), you may not
> copy or deliver this message to anyone. In such case,
> you should destroy this message and kindly notify the sender by reply
> email.


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


Mime
View raw message