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
