logging-log4j-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Sicker <boa...@gmail.com>
Subject Re: Getter method for retrieving the attributes of an appender from the LoggerContext
Date Wed, 27 Jan 2016 15:02:03 GMT
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.staldal@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<String, String> getAttributesForAppender(String appenderName);
>
>
>
> On Wed, Jan 27, 2016 at 1:27 PM, Ralph Goers <ralph.goers@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.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
> >
> >
>
>
> --
> [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.
>



-- 
Matt Sicker <boards@gmail.com>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message