logging-log4j-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Remko Popma <remko.po...@gmail.com>
Subject Re: Getter method for retrieving the attributes of an appender from the LoggerContext
Date Wed, 27 Jan 2016 22:07:09 GMT
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.staldal@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.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.

---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org


Mime
View raw message