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 <mikael.stal...@magine.com> wrote: > > 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:22 PM, Apostolis Giannakidis < > ap.giannaki...@gmail.com> wrote: > >> 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:19 PM, Mikael Ståldal <mikael.stal...@magine.com >>> wrote: >> >>> 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 <boa...@gmail.com> wrote: >>>> >>>> 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.stal...@magine.com> >>>> wrote: >>>> >>>>> I don't quite understand what you mean. >>>>> >>>>>> On Wed, Jan 27, 2016 at 4:02 PM, Matt Sicker <boa...@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.stal...@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.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. >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Matt Sicker <boa...@gmail.com> >>>>> >>>>> >>>>> >>>>> -- >>>>> [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. >>>> >>>> >>>> >>>> -- >>>> Matt Sicker <boa...@gmail.com> >>> >>> >>> >>> -- >>> [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. > > > -- > [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