I agree.
It seems like we're preparing to do a lot of work to essentially enable users
to duplicate our unit tests...
Sent from my iPhone
> On 2016/01/28, at 0:44, Mikael Ståldal wrote:
>
> OK, then the keeping config nodes approach might not be a good idea.
>
> However, I still don't think
OK, then the keeping config nodes approach might not be a good idea.
However, I still don't think that the benefit of being able to inspect
appender's config justifies the cost of increasing the complexity of every
appender (including future ones and 3rd party plugins).
On Wed, Jan 27, 2016 at 4:
One use case that I have at hand at the moment is that I want to be able to
verify that my appenders have the expected configuration attributes. For
example, I would like to be able to verify that my syslog appender is
connecting to the expected host,port,protocol, etc.
On Wed, Jan 27, 2016 at 3:1
It would be useful if Apostolis Giannakidis can explain the use case behind
this request, now it is a bit abstract to me.
On Wed, Jan 27, 2016 at 4:13 PM, Matt Sicker wrote:
> I mean keeping the Node tree to get attributes. It would only work from
> config files (and the config builder classes).
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, Mik
I don't quite understand what you mean.
On Wed, Jan 27, 2016 at 4:02 PM, Matt Sicker 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
> wrote:
>
> > Then perhaps we s
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
wrote:
> Then perhaps we should keep the node tree and expose it for this kind of
> queries, something like this:
>
> String hostname
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:
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:
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
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,
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 n
Sure, Object makes sense.
Gary
On Tue, Jan 26, 2016 at 4: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 Object> because not all attributes are Strings. From the top of my head, I
> know that an attri
One thing to note here. Correct me if I am wrong, but the map should
be Map 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
wrote:
> I could see AbstractAppender implementing a getAt
I could see AbstractAppender implementing a getAttributes() method like
this:
public Map getAttributes() {
Map 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 b
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
wi
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
>
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.
On Tue, Jan 26, 2016 at 8:56 PM, Ralph Goers
wrote:
> Actually, I kind of like the idea of adding a getAttributes() method to
> the Appender interface. Then
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 attributes = new HashMap<>();
super.getAttributes(attributes):
attributes.put(“myAttribute1”, “value1”);
return C
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 wrote:
> You could always use reflection to access it for now.
>
> On 26 January 2016 at 14:17, Apostolis Giannakidis <
> ap.giannaki...@gmail.c
You could always use reflection to access it for now.
On 26 January 2016 at 14:17, Apostolis Giannakidis 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
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 imp
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
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" )
.add
24 matches
Mail list logo
