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:13:52 GMT
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 <mikael.staldal@magine.com>
wrote:

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



-- 
Matt Sicker <boards@gmail.com>

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