logging-log4j-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mikael Ståldal <mikael.stal...@magine.com>
Subject Re: Getter method for retrieving the attributes of an appender from the LoggerContext
Date Wed, 27 Jan 2016 15:09:10 GMT
I don't quite understand what you mean.

On Wed, Jan 27, 2016 at 4:02 PM, Matt Sicker <boards@gmail.com> 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.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>
>



-- 
[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.

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