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.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<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 <
> garydgreg...@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.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 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 <
> >>>>> 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 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 <boa...@gmail.com>
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> --
> >>>>>>>>>> E-Mail: garydgreg...@gmail.com | ggreg...@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-unsubscr...@logging.apache.org
> >>>>>>>>> For additional commands, e-mail:
> >>>>> log4j-user-h...@logging.apache.org
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> --
> >>>>>>> E-Mail: garydgreg...@gmail.com | ggreg...@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: garydgreg...@gmail.com | ggreg...@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-unsubscr...@logging.apache.org
> >>> For additional commands, e-mail: log4j-user-h...@logging.apache.org
> >>>
> >>>
> >>
> >>
> >> --
> >> E-Mail: garydgreg...@gmail.com | ggreg...@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.stal...@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-unsubscr...@logging.apache.org
> For additional commands, e-mail: log4j-user-h...@logging.apache.org
>
>
--
[image: MagineTV]
*Mikael Ståldal*
Senior software developer
*Magine TV*
mikael.stal...@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.
