struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Christian Grobmeier" <grobme...@gmail.com>
Subject Re: Less boilerplate in code
Date Sat, 24 May 2014 12:09:12 GMT
On 24 May 2014, at 0:43, Chris Pratt wrote:

>>
>> log.debug("Loading Student [{0.number}] {0.name} Enrolled:
>> {0.enrollmentDate,date,yyyy-MM-dd}",student);
>
> This makes logging complicated.
>
> I actually find it a lot less complicated than the equivalent:
>
> if(log.isDebugEnabled()) {
> log.debug("Loading Student [{}] {} Enrolled:
> {}",student.getNumber(),student.getName(),new
> SimpleDateFormat("yyyy-MM-dd").format(student.getEnrollmentDate()));
> }
>
> Also, what happens if there is no such property as number in the 
> student
>> object?
>
>
> The formatter is extremely tolerant and prints out nothing for that
> replacement parameter if it fails in any way.

Yes, I looked in its implementation:
https://code.google.com/p/anodyzed/source/browse/trunk/onyx/com/anodyzed/onyx/bean/BeanUtils.java

Maybe it is just me, but I prefer to have simple and concrete
calls to logging. The BeanUtils class alone lets me feel this
all is way to complicated. We have a similar component with
ONGL around, I also think this is way to complicated.

In regards to the message creation above, I expect people understand the
more verbose logging statement easier than the first one. In example,
I didn't know this: {0.enrollmentDate,date,yyyy-MM-dd} would call 
SimpleDateFormat.
Using Onyx would require users to learn about it.

This is maybe taste, i hope others will voice their opinion as well.
But I still would like to stick with a solution of wider market share.

However that being said, you may want to consider introducing this to 
the logging.apache.org
project. Personally I do not like the syntax very much, but maybe you 
would
find some interest there from others.	

>
> Whats a "log concentrator"?
>
> One of the awesome capabilities of SLF4j is concentrating logging from 
> 3rd
> party libraries.  If you decide you want to use Log4j2 as your logging
> engine, but your 3rd party libraries use a combination of Common's 
> Logging,
> Log4j 1.2.x, and/or java.util.logging you can use SLF4j modules to 
> funnel
> messages from those 3rd party libraries to your Log4j2 setup.  That 
> way you
> can control all your logging with your Log4j2 configuration.

Aha, then this can be done with the Log4j2 API as well.
In example: http://logging.apache.org/log4j/2.x/log4j-jcl/index.html

Regards,
Christian

> (*Chris*)
>
>
> On Fri, May 23, 2014 at 1:38 PM, Christian Grobmeier 
> <grobmeier@gmail.com>wrote:
>
>> On 23 May 2014, at 22:04, Chris Pratt wrote:
>>
>> Sorry, I should have included the link - https://code.google.com/p/
>>> anodyzed/
>>>
>>> It isn't a replacement for async loggers, it works on the other end 
>>> of the
>>> problem, building the log message when it isn't necessary.
>>>
>>
>> you can disable logging in other frameworks too?
>> Or do you mean, it just logs on exception?
>>
>> I see variable substitution in the modern frameworks as well.
>>
>> I am not sure if like that:
>> log.debug("Loading Student [{0.number}] {0.name} Enrolled:
>> {0.enrollmentDate,date,yyyy-MM-dd}",student);
>>
>> This makes logging complicated. Also, what happens if there is no 
>> such
>> property as number in the student object?
>>
>>
>> I would actually recommend SLF4j for two reasons.  One, it is the 
>> front
>>> runner, almost a de-facto standard at this point.
>>>
>>
>> But it's driven by another company and not in the same "safe waters" 
>> as
>> the ASF.
>> Maybe I am paranoid here, but I simply prefer community driven 
>> projects
>> were the
>> community i.e. the surrounding foundation has full rights on 
>> repositories.
>> This is not against QOS itself, its a general fright.
>> However I totally see that the facade is ways better than 
>> commons-logging
>> and
>> that the log4j2 api isn't as widely adopted.
>>
>>
>> And two, it supports Log4j2.
>>>
>>
>> Sure: http://logging.apache.org/log4j/2.x/log4j-slf4j-impl/index.html
>>
>> But the Log4j2 API also supports the Slf4j API:
>> http://logging.apache.org/log4j/2.x/log4j-to-slf4j/index.html
>>
>>
>> So there's no down side to picking SLF4j.  If you want to use
>>> Log4j2, great, it's an awesome engine, but SLF4j is an awesome API 
>>> and log
>>> concentrator.  That's what it's good at, and how we should use it 
>>> (IMHO).
>>>
>>
>> Please note Log4j2 is not only an engine, its also an API. It's two
>> separate packages.
>> The API does support slf4j and other things too. However, my argument
>> against it would
>> be the missing Logback support. Not that I like Logback very much, 
>> but it
>> has some fans.
>>
>> Whats a "log concentrator"?
>>
>> Thanks,
>> Christian
>>
>>
>>> Thanks.
>>> (*Chris*)
>>>
>>>
>>> On Fri, May 23, 2014 at 12:19 PM, Christian Grobmeier
>>> <grobmeier@gmail.com>wrote:
>>>
>>> On 23 May 2014, at 18:22, Chris Pratt wrote:
>>>>
>>>> I'm preparing to start working on the logging for Struts 3.0, so we 
>>>> need
>>>>
>>>>> to
>>>>> come to some consensus.  As I see it, the leading options are:
>>>>>
>>>>> 1. Don't do anything
>>>>> 2. Switch to SLF4j (or Log4j2)
>>>>> 3. Use Onyx as is
>>>>> 4. Use Onyx as an Object Aware Facade directly to SLF4j (or 
>>>>> Log4j2)
>>>>>
>>>>>
>>>> I am sure you have posted links before, but could you repost links 
>>>> to the
>>>> Onxy project.
>>>> I am unable to find the right page with google.
>>>>
>>>>
>>>> My preference would actually be #4.  Onyx has some nice readability 
>>>> and
>>>>
>>>>> performance benefits over using SLF4j/Log4j2 directly
>>>>>
>>>>>
>>>> I can't believe it has performance benefits compared to async 
>>>> loggers of
>>>> log4j2:
>>>> http://www.grobmeier.de/log4j-2-performance-close-to-insane-
>>>> 20072013.html
>>>>
>>>>
>>>> that I think are
>>>>
>>>>> worth the minimal effort.  Please weigh in with your opinion 
>>>>> before I
>>>>> get
>>>>> too deep into this.
>>>>>
>>>>>
>>>> Personally I would prefer Log4j2. I am biased as I am involved in 
>>>> that
>>>> project.
>>>> However this is not marketing, I really believe this is so far the 
>>>> best
>>>> logging framework you can have atm (I haven't checked Onyx).
>>>>
>>>> Also I like the ASF and believe we are developing here for a 
>>>> reason. For
>>>> the same
>>>> reason I always prefer other ASF projects.
>>>>
>>>> If we do not want Log4j2 for some reason (it's currently RC1 - I 
>>>> say its
>>>> stable
>>>> and until we get S3 out it will be GA, but others may think 
>>>> different)
>>>> then
>>>> I definitely prefer slf4j. It has quite a market share and is 
>>>> commonly
>>>> accepted
>>>> by people.
>>>>
>>>> We need to have good reasons to not use what anybody else use.
>>>>
>>>> As I find slf4j/log4j2 syntax nice to read too and I doubt about
>>>> performance
>>>> benefits I would love to hear more arguments pro-Onyx.
>>>>
>>>> In short, my current preference is #2 with Log4j2, but if necessary 
>>>> even
>>>> with slf4j.
>>>>
>>>> And I am willing to invest some time here too, esp if I could 
>>>> budget this
>>>> on my log4j2 budget :-)
>>>>
>>>> Cheers
>>>> Christian
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> (*Chris*)
>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Fri, May 23, 2014 at 7:17 AM, Dave Newton 
>>>>> <davelnewton@gmail.com>
>>>>> wrote:
>>>>>
>>>>> Just my $0.02:
>>>>>
>>>>>>
>>>>>> I'd prefer to see stuff that other people implement and have more

>>>>>> eyes
>>>>>> on
>>>>>> take precedence over framework code.
>>>>>>
>>>>>> Similar to how XW has/had string utils duped by commons, etc, it

>>>>>> just
>>>>>> doesn't make sense to maintain that kind of boilerplate when it's
>>>>>> already
>>>>>> implemented, and implemented pretty well.
>>>>>>
>>>>>> Dave
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Fri, May 23, 2014 at 9:37 AM, Christian Grobmeier <
>>>>>> grobmeier@gmail.com
>>>>>>
>>>>>> wrote:
>>>>>>>
>>>>>>>
>>>>>> On 23 May 2014, at 11:58, Lukasz Lenart wrote:
>>>>>>
>>>>>>>
>>>>>>> Yes, we can break everything in 3.x but ... do we want to start

>>>>>>> from
>>>>>>>
>>>>>>> scratch?
>>>>>>>>
>>>>>>>>
>>>>>>>> It's not from scratch, is removing something from our codebase

>>>>>>>> and
>>>>>>> use
>>>>>>> something which already exists.
>>>>>>>
>>>>>>> And what's wrong in tiny logging facade? I've said it already,
I 
>>>>>>> will
>>>>>>>
>>>>>>> say it again: not all ppl are using Log4j or SLF4j or jul - it's

>>>>>>> the
>>>>>>>> worst thing if you must handle configuration of two or three
>>>>>>>> different
>>>>>>>> logging libraries because each framework is using a different

>>>>>>>> one.
>>>>>>>>
>>>>>>>>
>>>>>>>> First, we are a tiny active team. Why do we re-implement
tiny
>>>>>>> facades
>>>>>>> when they exist? I think with the less man-power we have we can

>>>>>>> surely
>>>>>>> do better and more necessary things than reinventing the wheel.
>>>>>>>
>>>>>>> Surely, not all ppl use log4j or slf4j or jul. But most do. I

>>>>>>> can't
>>>>>>> help
>>>>>>> but believe that there are only a handful people who still write

>>>>>>> their
>>>>>>>
>>>>>>> own
>>>>>>
>>>>>> logging thing.
>>>>>>>
>>>>>>> Please see this non-representative survey from ZeroTurnaround:
>>>>>>> http://zeroturnaround.com/rebellabs/the-state-of-
>>>>>>> logging-in-java-2013/
>>>>>>>
>>>>>>> Looks like everybody is using *something*, except 7% of 
>>>>>>> participants
>>>>>>> who is doing their own thing. It also says slf4j and log4j are

>>>>>>> the
>>>>>>> most
>>>>>>> used
>>>>>>> logging frameworks.
>>>>>>>
>>>>>>> Sure, logging has something to do with configuration. If you

>>>>>>> want
>>>>>>> to get out of this, then use the simple logging implementation

>>>>>>> which
>>>>>>> comes with slf4j. If you need more, configure something in 
>>>>>>> addition.
>>>>>>>
>>>>>>> Maybe Java logging is a mess, but I believe it's not to Struts

>>>>>>> to
>>>>>>> solve
>>>>>>> it. Instead I would offer something which the most people use

>>>>>>> (maybe
>>>>>>> slf4j) or
>>>>>>> something which we believe in (maybe log4j2).
>>>>>>>
>>>>>>> Right now Struts2 doesn't force users to use given logging 
>>>>>>> library, it
>>>>>>>
>>>>>>> can be configured to use whatever user is using in his project
- 
>>>>>>> thus
>>>>>>>> is huge advantage and I don't want to loose it.
>>>>>>>>
>>>>>>>>
>>>>>>>> You have the same with slf4j. Why is having our own custom

>>>>>>>> thing
>>>>>>> better
>>>>>>> than something which is widely accepted and adopted?
>>>>>>>
>>>>>>> With slf4j you can:
>>>>>>>
>>>>>>> - do not configure anything, go with slf4j
>>>>>>> - do configure something, go with the framework you like
>>>>>>>
>>>>>>> The same is true for the new log4j2 facade.
>>>>>>>
>>>>>>> Thanks for the discussion!
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> 2014-05-22 18:28 GMT+02:00 Christian Grobmeier 
>>>>>>> <grobmeier@gmail.com
>>>>>>>>> :
>>>>>>>>
>>>>>>>> Hi all,
>>>>>>>>
>>>>>>>>>
>>>>>>>>> with Struts 3.x we are allowed to "break things" and
it is 
>>>>>>>>> expected
>>>>>>>>>
>>>>>>>>> that
>>>>>>>>
>>>>>>>
>>>>>> we
>>>>>>>
>>>>>>>> do major steps.
>>>>>>>>>
>>>>>>>>> Personally I would like to remove any custom made logging

>>>>>>>>> layer
>>>>>>>>> and move on to a more standard one. Performance is not
an 
>>>>>>>>> issue,
>>>>>>>>> when
>>>>>>>>> logging
>>>>>>>>> is done right:
>>>>>>>>> http://www.grobmeier.de/log4j-2-performance-close-to-insane-
>>>>>>>>> 20072013.html
>>>>>>>>>
>>>>>>>>> I consider commons-logging almost dead. It will not be

>>>>>>>>> developed
>>>>>>>>> much
>>>>>>>>> further, at least
>>>>>>>>> not when looking at recent activity of the past years.
>>>>>>>>>
>>>>>>>>> I think slf4j is stable and well maintained. You can
even use 
>>>>>>>>> log4j2
>>>>>>>>>
>>>>>>>>> with
>>>>>>>>
>>>>>>>
>>>>>> it.
>>>>>>>
>>>>>>>>
>>>>>>>>> Saying log4j2 I am pretty much biased and need to tell
you 
>>>>>>>>> that
>>>>>>>>> log4j2
>>>>>>>>> also
>>>>>>>>> provides a logging interface similar to slf4j with which
you 
>>>>>>>>> can
>>>>>>>>> switch
>>>>>>>>> implementations.
>>>>>>>>>
>>>>>>>>> In no case I would go to anything exotic or jul. The
latter 
>>>>>>>>> one
>>>>>>>>> often
>>>>>>>>> needs
>>>>>>>>> wrappers
>>>>>>>>> to work as wanted.
>>>>>>>>>
>>>>>>>>> That being said, I only see slf4j and log4j. If we want
to 
>>>>>>>>> stick in
>>>>>>>>> the
>>>>>>>>> ASF
>>>>>>>>> world
>>>>>>>>> we can use the log4j2 interfaces and explain how to integrate

>>>>>>>>> in
>>>>>>>>>
>>>>>>>>> example
>>>>>>>>
>>>>>>>
>>>>>> logback.
>>>>>>>
>>>>>>>> That would be my preferred choice. Also I think log4j2 provides

>>>>>>>> more
>>>>>>>>> features and
>>>>>>>>> is pretty much better maintained (my personal opinion)
>>>>>>>>>
>>>>>>>>> If we want to use something which is longer on the market,

>>>>>>>>> then
>>>>>>>>> slf4j.
>>>>>>>>>
>>>>>>>>> cheers
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 22 May 2014, at 9:19, Chris Pratt wrote:
>>>>>>>>>
>>>>>>>>> You are correct, it delegates the actual logging to a
logging
>>>>>>>>> engine,
>>>>>>>>>
>>>>>>>>> currently either Log4j, Logback, java.util.logging or
to 
>>>>>>>>> SLF4j.
>>>>>>>>>> (*Chris*)
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Wed, May 21, 2014 at 10:10 PM, Lukasz Lenart
>>>>>>>>>> <lukaszlenart@apache.org>wrote:
>>>>>>>>>>
>>>>>>>>>> @Chris
>>>>>>>>>>
>>>>>>>>>> Do I get it right - Onyx is just logging facade not
the 
>>>>>>>>>> full-blow
>>>>>>>>>>> logging library?
>>>>>>>>>>>
>>>>>>>>>>> 2014-05-17 8:52 GMT+02:00 Lukasz Lenart 
>>>>>>>>>>> <lukaszlenart@apache.org
>>>>>>>>>>>> :
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Some were already addressed, another thing is
that across 
>>>>>>>>>>> the
>>>>>>>>>>>> framework we are using different semantic
inside logging
>>>>>>>>>>>> messages,
>>>>>>>>>>>>
>>>>>>>>>>>> ie:
>>>>>>>>>>>
>>>>>>>>>>
>>>>>> "Value [#0] was excluded by pattern [#1]" and re-writing all 
>>>>>> these
>>>>>>>
>>>>>>>> doesn't make sense. Right now XWork logging facade is very
thin 
>>>>>>>> -
>>>>>>>>>>>>
>>>>>>>>>>>> one
>>>>>>>>>>>
>>>>>>>>>>
>>>>>> class implementing Logger interface and another implementing
>>>>>>>
>>>>>>>> LoggerFactory - the rest is delegated to given logging library.
>>>>>>>>>>>>
>>>>>>>>>>>> Besides that, users don't care what kind
of logging library
>>>>>>>>>>>>
>>>>>>>>>>>> framework
>>>>>>>>>>>
>>>>>>>>>>
>>>>>> is using - till it doesn't interfere with the one used in their 
>>>>>> apps
>>>>>>>
>>>>>>>> or clashes with logging layers from other frameworks. Switching
>>>>>>>>>>>> entirely to SLF4j can break few apps and
we'll get a lot of
>>>>>>>>>>>>
>>>>>>>>>>>> complains
>>>>>>>>>>>
>>>>>>>>>>
>>>>>> why (not the first time ;-)
>>>>>>>
>>>>>>>>
>>>>>>>>>>>> My plan looks like this:
>>>>>>>>>>>> - add checking if given log level is enabled
inside logging
>>>>>>>>>>>> methods
>>>>>>>>>>>> - start migrating code to the new semantic
(removing if
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> (LOG.isXxxEnabled())
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> - migrate the rest of logging calls to use parameter

>>>>>>>>>>> substitution
>>>>>>>>>>>> - (or start with this before previous step)
use Onyx 
>>>>>>>>>>>> instead of
>>>>>>>>>>>> current LoggerUtils
>>>>>>>>>>>> - change order of discovering logging libs
on the classpath 
>>>>>>>>>>>> and
>>>>>>>>>>>> put
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> SLF4j on top
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Regards
>>>>>>>>>>>> --
>>>>>>>>>>>> Łukasz
>>>>>>>>>>>> + 48 606 323 122 http://www.lenart.org.pl/
>>>>>>>>>>>>
>>>>>>>>>>>> 2014-05-15 23:14 GMT+02:00 Chris Pratt 
>>>>>>>>>>>> <thechrispratt@gmail.com
>>>>>>>>>>>>> :
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> What is your reluctance to using SLF4j. 
It seems like the 
>>>>>>>>>>>> right
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> technology
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> for the problem.
>>>>>>>>>>>>
>>>>>>>>>>>>> (*Chris*)
>>>>>>>>>>>>>
>>>>>>>>>>>>> P.S.  ICLA on the way
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Wed, May 14, 2014 at 11:16 PM, Lukasz
Lenart <
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> lukaszlenart@apache.org>wrote:
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> 2014-05-14 21:51 GMT+02:00 Chris Pratt 
>>>>>>>>>>>> <thechrispratt@gmail.com
>>>>>>>>>>>>>> :
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Yes, we could use Onyx's interface
mechanism, but I think
>>>>>>>>>>>>>>> SLF4j's
>>>>>>>>>>>>>>> is
>>>>>>>>>>>>>>> probably more stable and definitely
more supported.  So 
>>>>>>>>>>>>>>> I'd
>>>>>>>>>>>>>>> probably
>>>>>>>>>>>>>>> recommend that we extract the
SLF4j support object and 
>>>>>>>>>>>>>>> use it
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> directly
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> (or
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> at least make it the default).  If
it's something that 
>>>>>>>>>>>>>> you're
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> interested
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> in, I'd have to fill out the forms to become
a committer on
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Struts.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>
>>>>>>>
>>>>>>>>>>>>>>> Where
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> would I find that information?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I'm not sure if this the right move,
switching to SLF4j 
>>>>>>>>>>>>>> over
>>>>>>>>>>>>>> our
>>>>>>>>>>>>>> custom solution. Please can we explore
this topic a bit?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> The first step to become a committer
is to fill ICLA
>>>>>>>>>>>>>> http://www.apache.org/licenses/#clas
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Regards
>>>>>>>>>>>>>> --
>>>>>>>>>>>>>> Łukasz
>>>>>>>>>>>>>> + 48 606 323 122 http://www.lenart.org.pl/
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> ------------------------------------------------------------
>>>>>>>>>>>>>> ---------
>>>>>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>>>>>>>>>>>>>> For additional commands, e-mail:

>>>>>>>>>>>>>> dev-help@struts.apache.org
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> ------------------------------------------------------------
>>>>>>>>>>>>>>
>>>>>>>>>>>>> ---------
>>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>>>>>>>>>>> For additional commands, e-mail: dev-help@struts.apache.org
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> ---
>>>>>>>>> http://www.grobmeier.de
>>>>>>>>> The Zen Programmer: http://bit.ly/12lC6DL
>>>>>>>>> @grobmeier
>>>>>>>>> GPG: 0xA5CC90DB
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> ------------------------------------------------------------
>>>>>>>>> ---------
>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>>>>>>>>> For additional commands, e-mail: dev-help@struts.apache.org
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> ------------------------------------------------------------
>>>>>>>>>
>>>>>>>> ---------
>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>>>>>>>> For additional commands, e-mail: dev-help@struts.apache.org
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>> ---
>>>>>>> http://www.grobmeier.de
>>>>>>> The Zen Programmer: http://bit.ly/12lC6DL
>>>>>>> @grobmeier
>>>>>>> GPG: 0xA5CC90DB
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>>>>>>> For additional commands, e-mail: dev-help@struts.apache.org
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> --
>>>>>> e: davelnewton@gmail.com
>>>>>> m: 908-380-8699
>>>>>> s: davelnewton_skype
>>>>>> t: @dave_newton <https://twitter.com/dave_newton>
>>>>>> b: Bucky Bits <http://buckybits.blogspot.com/>
>>>>>> g: davelnewton <https://github.com/davelnewton>
>>>>>> so: Dave Newton 
>>>>>> <http://stackoverflow.com/users/438992/dave-newton>
>>>>>>
>>>>>>
>>>>>>
>>>> ---
>>>> http://www.grobmeier.de
>>>> The Zen Programmer: http://bit.ly/12lC6DL
>>>> @grobmeier
>>>> GPG: 0xA5CC90DB
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>>>> For additional commands, e-mail: dev-help@struts.apache.org
>>>>
>>>>
>>>>
>>
>> ---
>> http://www.grobmeier.de
>> The Zen Programmer: http://bit.ly/12lC6DL
>> @grobmeier
>> GPG: 0xA5CC90DB
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>> For additional commands, e-mail: dev-help@struts.apache.org
>>
>>


---
http://www.grobmeier.de
The Zen Programmer: http://bit.ly/12lC6DL
@grobmeier
GPG: 0xA5CC90DB

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org


Mime
View raw message