logging-log4j-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mikael Ståldal <mikael.stal...@magine.com>
Subject Re: Getter method for retrieving the attributes of an appender from the LoggerContext
Date Wed, 27 Jan 2016 15:44:35 GMT
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.giannakidis@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.staldal@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 <boards@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.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>
>>>
>>
>>
>>
>> --
>> [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.
>>
>
>


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

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