I wouldn't limit the stages or at least allow either "decoration" or
overriding it based on real world projects.
There are so many test forms or phases, so unit and integration is too
restrictive, JSF2 has that problem, too.
On Sep 11, 2011 10:15 PM, "Adam Bien" <abien_at_adam-bien.com> wrote:
>
> On 11.09.2011, at 18:02, Deepak Anupalli wrote:
>
>> (Sorry for jumping in too late)
>>
>> Providing Java based Configuration API with overrides specified through
XML/Annotation or Properties sounds good. Having the flexibility to fetch
from alternate sources, like Database, or through REST API from a
Configuration Server (esp helpful for cloud deployments) would be a plus
point. I happen to agree with Jevgeni Kabanov on this, as it gives the
ability for dynamic configuration with the Configurer approach.
> +1
>>
>> I have not seen many developers preferring Environment Entries/JNDI for
configuration, and they do not fit well to adress application or server wide
configuration (being more context based).
> +++1 (I never saw that in real world)
>>
>> I like the idea of having CDI XML which Reza had earlier proposed. But
instead of having XML as the canonical model, there should be provision for
alternate approaches. Having the ability to get the config bean injected
wherever a developer would want to, is an added advantage and that is where
we can look at the CDI approach.
>
> +1
>>
>> However, there is also a need to address stage specific configuration. We
had to tackle this problem in our cloud based products by pushing
Dev/Stage/Release specific configuration to DB.
> +1
>
> I wanted to propose a "debug" or "dev" property for the resources and
would expect servers to consider that as an encouragement to provide
additional logging / info.
>
> I already proposed staging in the past -> it would be even better. We
could also limit it to dev / integration / prod or dev / stage / release (it
is the case in 90% of all projects)
>
> thanks for your late jump-in :-)
>
>>
>> Thanks,
>> Deepak
>>
>> ----- Original Message ----- From: "Jevgeni Kabanov" <
jevgeni_at_zeroturnaround.com>
>> To: <jsr342-experts_at_javaee-spec.java.net>
>> Sent: Sunday, September 11, 2011 12:24 AM
>> Subject: [jsr342-experts] Re: [javaee-spec users] Re: Configuration
>>
>>
>> I meant exactly that the Java EE app uses the API to configure its
environment in the container. Just as an idea, why not add a "Configurer"
that runs before the app is deployed and sets up the environment (including
both the standard parts of environment and the container-specific parts)
against a standardized Java API with optional container-specific extensions.
Most containers already have some internal API representation anyway, so
this would not be too hard complicated to implement.
>>
>> This would allow multiple different scenarios, including dynamically
looking up configuration (e.g. when the app is deployed in a public or
private cloud), easier large-scale deployments (can configure app for
specific cluster/slice on deploy), dynamically configuring multiple
datasources/JMS connections/etc and so on. These are just some of the
scenarios I can come up with off-hand, but the beauty is that it would
enable all other scenarios as well at a very low implementation cost. I
think after standardizing this we would see all kinds of interesting ideas
from the community. In fact, I could probably put together a blog post when
I have a free minute and see what the response is like.
>>
>> --
>> Jevgeni Kabanov
>> Founder & CTO of ZeroTurnaround
>> @ekabanov | Skype: ekabanov | http://www.linkedin.com/in/ekabanov
>> +372 53 411 869
>>
>>
>> On Saturday, 10 September 2011 at 00:33, Bill Shannon wrote:
>>
>>> What does "configuring the app environment" mean? For example?
>>>
>>> Who would use the API? The app itself? Some other Java EE app
configuring
>>> this Java EE app? A non-Java EE app configuring a running Java EE app?
>>>
>>>
>>> Jevgeni Kabanov wrote on 09/ 8/11 08:11 PM:
>>> > Also, I actually see significantly more reason in providing a Java API
> for
>>> > configuring the app environment. The would enable dynamic
configuration
>>> > lookup in complex scenarios as well as to use any kind of
configuration > file
>>> > desired, be it JSON or Prolog.
>>> >
>>> > Sent from my iPhone
>>> >
>>> > On 09.09.2011, at 5:57, Reza Rahman <reza_rahman_at_lycos.com > (mailto:
reza_rahman_at_lycos.com)
>>> > <mailto:reza_rahman_at_lycos.com>> wrote:
>>> >
>>> > > Jeff,
>>> > >
>>> > > Just to be clear, whatever the actual merits of annotations+Java vs
>>> > > meta-data sources outside of Java, I do think it is important to > >
support
>>> > > both models well...
>>> > >
>>> > > Cheers, Reza
>>> > >
>>> > >
>>> > > On 9/8/2011 6:07 PM, Jeff Genender wrote:
>>> > > > I actually do not agree. At a large percentage of my clients, they
>>> > > > propagate jars through QA to production without a rebuild. QA > >
> certifies
>>> > > > a jar for movement to staging and production. Almost all ops guys
I > > > have
>>> > > > worked with want overrides through files.
>>> > > >
>>> > > > I think it would be poor form to not have overrides via config
files > > > and
>>> > > > it will most certainly get a lot of push back from ops folks.
>>> > > >
>>> > > > Jeff
>>> > > >
>>> > > > On Sep 8, 2011, at 2:23 PM, Reza Rahman wrote:
>>> > > >
>>> > > > > +1. I agree that redeploy is almost always bound to a rebuild >
> > > anyway.
>>> > > > >
>>> > > > > On 9/8/2011 11:55 AM, Adam Bien wrote:
>>> > > > > >
>>> > > > > > On 08.09.2011, at 15:56, Werner Keil wrote:
>>> > > > > >
>>> > > > > > > Jeff, that's a good point, one of the drawbacks of pure
>>> > > > > > > annotation-based approaches like JSR-330 and its likes.
>>> > > > > > >
>>> > > > > > > Although both were deployed in the same format (mostly XML
and
>>> > > > > > > Properties) what was used in an earlier EE5 generation app I
> > > > > > worked
>>> > > > > > > on in recent months, was pretty much having external
resources
>>> > > > > > > override defaults from compile-time, which in our case could
> > > > > > be
>>> > > > > > > annotation-based.
>>> > > > > >
>>> > > > > > Usually you are going to deploy the application on every
change
>>> > > > > > anyway. At least if you have a working CI environment in
place. > > > > > In
>>> > > > > > this case it really doesn't matter whether you are going to
edit > > > > > the
>>> > > > > > XML (usually without proper tooling), or change configuration
on
>>> > > > > > annotations.
>>> > > > > >
>>> > > > > > Further there should be a possibility to override the > > > >
> annotations by
>>> > > > > > e.g. XML or Java config.
>>> > > > > >
>>> > > > > >
>>> > > > > > >
>>> > > > > > > Another app with the same client followed a compile-time
only
>>> > > > > > > strategy, which caused the problem of having to rebuild > >
> > > > everything,
>>> > > > > > > at least the parts with changing resources for each target
>>> > > > > > > environment. For a large multi-tenant cloud that would be a
>>> > > > > > > nightmare<322.gif>
>>> > > > > > >
>>> > > > > > > On Thu, Sep 8, 2011 at 2:18 PM, Jeff Genender
>>> > > > > > > <<mailto:jgenender_at_savoirtech.com>jgenender_at_savoirtech.com >
> > > > > (mailto:jgenender_at_savoirtech.com)
>>> > > > > > > <mailto:jgenender_at_savoirtech.com>> wrote:
>>> > > > > > >
>>> > > > > > > The only problem with annotations for configuration is being
> > > > > > able
>>> > > > > > > to see it since its compiled. How would you know the values
in > > > > > > the
>>> > > > > > > event that needed changing? How would you override without a
>>> > > > > > > recompile? If we can have a "switch" that enables override,
> > > > > > that
>>> > > > > > > would be a possible option. I think Java configuration would
> > > > > > be
>>> > > > > > > neat, but we need the ability to override it on-the-fly. I >
> > > > > think
>>> > > > > > > ops guys would poop their pants if they didn't have that > >
> > > > ability
>>> > > > > > > ;-)
>>> > > > > > >
>>> > > > > > > Sorry for my long delay in response from 7/22… let me answer
>>> > > > > > > Bill's statement from before….
>>> > > > > > >
>>> > > > > > > I (like Adam) don't think XML should be the overall reaching
>>> > > > > > > source. We really should consider multiple ways to be able
to > > > > > > do
>>> > > > > > > configurations, yes, like a maven plugin. XML has been tried
> > > > > > and
>>> > > > > > > try for many years, but it is hated by many. I think
allowing > > > > > > for
>>> > > > > > > multiple ways to configure gives options to people for > > >
> > > preferences
>>> > > > > > > on configuration and it brings EE up to the 21st century ;-)
I > > > > > > do
>>> > > > > > > like XML/JSON/Java configurations with the caveat of having
>>> > > > > > > something that allows you to override the other (see my ops
> > > > > > comment
>>> > > > > > > above).
>>> > > > > > >
>>> > > > > > > As for JSON, there is an internet draft for this
>>> > > > > > > (<http://tools.ietf.org/html/draft-zyp-json-schema-03>
http://tools.ietf.org/html/draft-zyp-json-schema-03)...
>>> Examples are at <http://json-schema.org/>http://json-schema.org/.
>>> > > > > > >
>>> > > > > > > Jeff
>>> > > > > > >
>>> > > > > > >
>>> > > > > > > On Sep 8, 2011, at 5:39 AM, Adam Bien wrote:
>>> > > > > > >
>>> > > > > > > > Hi Reza + *,
>>> > > > > > > >
>>> > > > > > > > I only read the configuration-conversation without > > > >
> > > commenting
>>> > > > > > > > it,
>>> > > > > > > reason: I never configured any Java EE 5 / 6 application
with > > > > > > XML.
>>> > > > > > > Sometimes we had to configure the applications, but then we
>>> > > > > > > usually relied on a DB via JDBC / JPA (usually the latter).
>>> > > > > > > >
>>> > > > > > > > In latest project I used the following approach to
configure > > > > > > > my
>>> > > > > > > > Java
>>> > > > > > > EE 6 apps:
>>> > > > > > > <
http://www.adam-bien.com/roller/abien/entry/how_to_configure_java_ee>
http://www.adam-bien.com/roller/abien/entry/how_to_configure_java_ee
>>> The defaults were overridden with data from DB.
>>> > > > > > > >
>>> > > > > > > > But: it should be possible to configure application with
XML > > > > > > > out
>>> > > > > > > > of
>>> > > > > > > the box. I would, hovewer, not use XML as "master", rather
use
>>> > > > > > > Java object for this purpose. The Java objects could be
>>> > > > > > > instantiated from XML, JSON (with extended JAXB like it is
the > > > > > > case
>>> > > > > > > in Jersey) and directly from DB (with or without SQL), or >
> > > > > directly
>>> > > > > > > by the application.
>>> > > > > > > >
>>> > > > > > > > I would also like to use annotations as a configuration >
> > > > > > source.
>>> > > > > > > > We
>>> > > > > > > could put the annotations on top of the java classes
mentioned
>>> > > > > > > above.
>>> > > > > > > >
>>> > > > > > > > I like your XML-proposal but I do not like the fact that >
> > > > > > your
>>> > > > > > > > are
>>> > > > > > > using XML as the canonical model. As you mentioned
previously: > > > > > > I
>>> > > > > > > would use expressive Java classes as configuration source
and > > > > > > XML /
>>> > > > > > > JSON / JPA as a persistence mechanism.
>>> > > > > > > >
>>> > > > > > > > Any thoughts?
>>> > > > > > > >
>>> > > > > > > > thanks in advance!,
>>> > > > > > > >
>>> > > > > > > > adam
>>> > > > > > > >
>>> > > > > > > >
>>> > > > > > > >
>>> > > > > > > > On 23.07.2011, at 03:51, Reza Rahman wrote:
>>> > > > > > > >
>>> > > > > > > > > Bill,
>>> > > > > > > > >
>>> > > > > > > > > With all due respect, I think we are talking apples and
> > > > > > > > oranges
>>> > > > > > > > > here.
>>> > > > > > > > >
>>> > > > > > > > > If you look at Spring for example, their newest and most
>>> > > > > > > > > popular
>>> > > > > > > configuration styles is Java Config:
>>> > > > > > > <
http://static.springsource.org/spring-javaconfig/docs/1.0.0.M4/reference/html/
>
http://static.springsource.org/spring-javaconfig/docs/1.0.0.M4/reference/html/
.
>>> Similarly, the application configuration for the popular Wicket web
>>> > > > > > > framework is also Java based and is one of the most
well-liked
>>> > > > > > > features of the technology. Jetty also allows for
programmatic > > > > > > web
>>> > > > > > > application configuration that is currently one of their > >
> > > > unique
>>> > > > > > > features. None of theses examples suffer from the same > > >
> > > problems
>>> > > > > > > that EJB 1.0 did.
>>> > > > > > > > >
>>> > > > > > > > > At any rate, I do think I've said enough at this point.
I
>>> > > > > > > > > think
>>> > > > > > > it's time for others to voice their opinions if they believe
> > > > > > this
>>> > > > > > > is something that is valuable to the platform.
>>> > > > > > > > >
>>> > > > > > > > > Cheers, Reza
>>> > > > > > > > >
>>> > > > > > > > >
>>> > > > > > > > > On 7/22/2011 7:23 PM, Bill Shannon wrote:
>>> > > > > > > > > > We used to have deployment descriptors written in
Java.
>>> > > > > > > > > > Remember EJB 1.0? Everyone hated them.
>>> > > > > > > > > >
>>> > > > > > > > > > Reza Rahman wrote on 07/22/11 04:01 PM:
>>> > > > > > > > > > > Bill,
>>> > > > > > > > > > >
>>> > > > > > > > > > > I guess I'd like to discuss this more after we do
see > > > > > > > > > > some
>>> > > > > > > > > > > more
>>> > > > > > > tangible
>>> > > > > > > > > > > interest in the EG at least :-). Something as > > >
> > > > > > > pervasive as
>>> > > > > > > > > > > this
>>> > > > > > > should
>>> > > > > > > > > > > garner interest/input from a decent number of EG > >
> > > > > > > > members
>>> > > > > > > > > > > :-).
>>> > > > > > > > > > >
>>> > > > > > > > > > > By definition, decoupling from XML as the
"canonical"
>>> > > > > > > > > > > configuration format to something more Java centric
> > > > > > > > > > and
>>> > > > > > > > > > > more readily
>>> > > > > > > translatable to
>>> > > > > > > > > > > other formats allows for more choice/flexibility. I
> > > > > > > > > > also
>>> > > > > > > > > > > disagree
>>> > > > > > > with
>>> > > > > > > > > > > Pete in that I do think a Java/OO-centric format is
> > > > > > > > > > readily
>>> > > > > > > > > > > intuitive and compelling to Java developers. As you
>>> > > > > > > > > > > mentioned, a revamp
>>> > > > > > > would also
>>> > > > > > > > > > > be a good opportunity to remove some of the old
cruft > > > > > > > > > > and
>>> > > > > > > > > > > allow for things like namespace based flexibility, >
> > > > > > > > > better
>>> > > > > > > > > > > support for XML attributes, overlaying vendor
>>> > > > > > > > > > > extension/plug-in configuration and
>>> > > > > > > so on.
>>> > > > > > > > > > >
>>> > > > > > > > > > > For me personally, the option to write configuration
> > > > > > > > > > in
>>> > > > > > > > > > > pure Java is particularly tantalizing. It allows for
>>> > > > > > > > > > > possibilities like programmatically changing > > > >
> > > > > > configuration
>>> > > > > > > > > > > at deployment time (Servlet 3 does the very
beginning > > > > > > > > > > of
>>> > > > > > > > > > > this in a very ad-hoc fashion). Just
>>> > > > > > > like JPA
>>> > > > > > > > > > > 2 criteria queries vs. JPQL, it is also more
type-safe > > > > > > > > > > and
>>> > > > > > > arguably more
>>> > > > > > > > > > > readable/maintainable.
>>> > > > > > > > > > >
>>> > > > > > > > > > > Each alternative format similarly has it's own > > >
> > > > > > > strengths --
>>> > > > > > > > > > > JSON for simplicity/brevity, property files for
>>> > > > > > > familiarity/simplicity/brevity, etc.
>>> > > > > > > > > > >
>>> > > > > > > > > > > Cheers, Reza
>>> > > > > > > > > > >
>>> > > > > > > > > > >
>>> > > > > > > > > > > On 7/22/2011 5:31 PM, Bill Shannon wrote:
>>> > > > > > > > > > > > Ok, good, you're not *all* on vacation! :-)
>>> > > > > > > > > > > >
>>> > > > > > > > > > > > Converting from our existing XML to JSON doesn't >
> > > > > > > > > > seem
>>> > > > > > > > > > > > like a big improvement. Is there something like
XML
>>> > > > > > > > > > > > Schema for JSON?
>>> > > > > > > > > > > >
>>> > > > > > > > > > > > I assume the format of these files isn't a big
issue > > > > > > > > > > > for
>>> > > > > > > > > > > > anyone
>>> > > > > > > using
>>> > > > > > > > > > > > an IDE. Are you trying to address the people who >
> > > > > > > > > > *don't*
>>> > > > > > > > > > > > use an IDE?
>>> > > > > > > Would it be
>>> > > > > > > > > > > > enough to provide tools that convert JSON to XML?
>>> > > > > > > > > > > > Perhaps a maven plugin?
>>> > > > > > > > > > > >
>>> > > > > > > > > > > >
>>> > > > > > > > > > > > Jeff Genender wrote on 07/22/11 02:16 PM:
>>> > > > > > > > > > > > > Now now… there is interest ;-) Its July and lots
> > > > > > > > > > > > of
>>> > > > > > > > > > > > > holiday going on… so be nice and understanding
;-)
>>> > > > > > > > > > > > >
>>> > > > > > > > > > > > > Im pretty high on the JSON stuff. This is
gaining
>>> > > > > > > > > > > > > traction and becoming a much more readable
format. > > > > > > > > > > > > It
>>> > > > > > > > > > > > > would be nice to see a paradigm shift and begin
> > > > > > > > > > > > using
>>> > > > > > > > > > > > > some of the more friendlier data
>>> > > > > > > formats.
>>> > > > > > > > > > > > >
>>> > > > > > > > > > > > > There is some interest, see? ;-)
>>> > > > > > > > > > > > >
>>> > > > > > > > > > > > > Jeff
>>> > > > > > > > > > > > >
>>> > > > > > > > > > > > > On Jul 22, 2011, at 3:09 PM, Bill Shannon wrote:
>>> > > > > > > > > > > > >
>>> > > > > > > > > > > > > > Reza Rahman wrote on 07/22/11 01:59 PM:
>>> > > > > > > > > > > > > > > Bill,
>>> > > > > > > > > > > > > > >
>>> > > > > > > > > > > > > > > I guess it's a little disheartening that no
> > > > > > > > > > > > > > one
>>> > > > > > > > > > > > > > > else on the
>>> > > > > > > alias is
>>> > > > > > > > > > > > > > > chiming in on this - not sure if this is
just > > > > > > > > > > > > > > that
>>> > > > > > > > > > > > > > > boring or
>>> > > > > > > that they
>>> > > > > > > > > > > > > > > are judiciously biding their time :-).
>>> > > > > > > > > > > > > >
>>> > > > > > > > > > > > > > Ya, with this little interest here, it's not >
> > > > > > > > > > > > clear
>>> > > > > > > > > > > > > > that it's worth making any of the proposed > >
> > > > > > > > > > > changes.
>>> > > > > > > > > > > > > >
>>> > > > > > > > > > > > > > > Anyways, would it help much that this
approach
>>> > > > > > > > > > > > > > > might open the doorway to 100% XML free,
Java > > > > > > > > > > > > > > based
>>> > > > > > > > > > > > > > > configuration down the line or that it
greases > > > > > > > > > > > > > > the
>>> > > > > > > > > > > > > > > wheels for other possibilities like JSON or
>>> > > > > > > > > > > > > > > property file
>>> > > > > > > based
>>> > > > > > > > > > > > > > > DDs?
>>> > > > > > > > > > > > > >
>>> > > > > > > > > > > > > > I don't see why we need more ways of doing the
> > > > > > > > > > > > > same
>>> > > > > > > > > > > > > > thing.
>>> > > > > > > You need to
>>> > > > > > > > > > > > > > convince me that any of these is so much
better > > > > > > > > > > > > > than
>>> > > > > > > > > > > > > > what we
>>> > > > > > > already
>>> > > > > > > > > > > > > > have that it's worth doing.
>>> > > > > > > > > > > > > >
>>> > > > > > > > > > > > > > > It also helps make configuring CDI style DI
> > > > > > > > > > > > > > easier
>>> > > > > > > > > > > > > > > for any
>>> > > > > > > managed
>>> > > > > > > > > > > > > > > bean...
>>> > > > > > > > > > > > > >
>>> > > > > > > > > > > > > > And that seems good.
>>> > > > > > > > > > > > > >
>>> > > > > > > > > > > > > > > To be honest though, I think just getting
some > > > > > > > > > > > > > > kind
>>> > > > > > > > > > > > > > > of CDI
>>> > > > > > > XML in Java
>>> > > > > > > > > > > > > > > EE 7 would be a good accomplishment in the >
> > > > > > > > > > > > > scheme
>>> > > > > > > > > > > > > > > of things. I've never been a proponent of >
> > > > > > > > > > > > > making
>>> > > > > > > > > > > > > > > big changes in the standard
>>> > > > > > > without some
>>> > > > > > > > > > > > > > > implementation precedent. If we defer the >
> > > > > > > > > > > > > general
>>> > > > > > > > > > > > > > > overhaul of
>>> > > > > > > Java
>>> > > > > > > > > > > > > > > EE DD to Java EE 8, this does give us (and
>>> > > > > > > > > > > > > > > hopefully others) a
>>> > > > > > > little more
>>> > > > > > > > > > > > > > > room to do some "bleeding edge"
implementation > > > > > > > > > > > > > > work
>>> > > > > > > > > > > > > > > on our own terms. As far as you can see,
there > > > > > > > > > > > > > > is
>>> > > > > > > > > > > > > > > nothing in the standard that
>>> > > > > > > stops us
>>> > > > > > > > > > > > > > > from doing that, right?
>>> > > > > > > > > > > > > >
>>> > > > > > > > > > > > > > Right. I think it's fine for CDI to blaze the
> > > > > > > > > > > > > trail
>>> > > > > > > > > > > > > > here and
>>> > > > > > > we can
>>> > > > > > > > > > > > > > consider following their lead in EE 8.
>>> > > > > > > > > > > > > >
>>> > > > > > > > > > > > > > But only if I see more interest in this expert
> > > > > > > > > > > > > group!
>>> > > > > > > > > > > > > > :-)
>>> > > > > > > > > > > >
>>> > > > > > > > > > > >
>>> > > > > > > > > > > >
>>> > > > > > > > > > > > ----- No virus found in this message. Checked by >
> > > > > > > > > > AVG -
>>> > > > > > > > > > > > <http://www.avg.com/>www.avg.com > > > > > > > > >
> > (http://www.avg.com)
>>> > > > > > > <http://www.avg.com>
>>> > > > > > > > > > > > Version: 10.0.1390 / Virus Database: 1518/3781 - >
> > > > > > > > > > Release
>>> > > > > > > > > > > > Date:
>>> > > > > > > 07/22/11
>>> > > > > > > > > >
>>> > > > > > > > > >
>>> > > > > > > > > >
>>> > > > > > > > > > ----- No virus found in this message. Checked by AVG -
>>> > > > > > > > > > <http://www.avg.com/>www.avg.com <http://www.avg.com>
>>> > > > > > > > > > Version: 10.0.1390 / Virus Database: 1518/3781 -
Release
>>> > > > > > > > > > Date:
>>> > > > > > > 07/22/11
>>> > > > > > >
>>> > > > > > >
>>> > > > > > >
>>> > > > > > >
>>> > > > > > > --
>>> > > > > > >
>>> > > > > > > Werner Keil | UOMo Lead | <http://Eclipse.org/>Eclipse.org >
> > > > > (http://Eclipse.org)
>>> > > > > > > <http://Eclipse.org>
>>> > > > > > >
>>> > > > > > > Twitter @wernerkeil |Skype: werner.keil |
>>> > > > > > > <http://www.eclipse.org/uomo>www.eclipse.org/uomo > > > > >
> (http://www.eclipse.org/uomo)
>>> > > > > > > <http://www.eclipse.org/uomo> | #EclipseUOMo
>>> > > > > > >
>>> > > > > > > * JavaOne: October 2-6 2011, San Francisco, USA. Werner
Keil, > > > > > > Agile
>>> > > > > > > Coach, UOMo Leadwill co-present "JSR 321: Trusted Java API"
>>> > > > > >
>>> > > > > > Independent Consultant, Speaker, Java Champion Weblog:
>>> > > > > > <http://blog.adam-bien.com/>blog.adam-bien.com > > > > > (
http://blog.adam-bien.com)
>>> > > > > > <http://blog.adam-bien.com> press:
>>> > > > > > <http://press.adam-bien.com/>press.adam-bien.com > > > > > (
http://press.adam-bien.com)
>>> > > > > > <http://press.adam-bien.com> eMail:
>>> > > > > > <mailto:abien_at_adam-bien.com>abien_at_adam-bien.com > > > > >
(mailto:abien_at_adam-bien.com)
>>> > > > > > <mailto:abien_at_adam-bien.com> twitter:
>>> > > > > > <http://twitter.com/AdamBien>twitter.com/AdamBien > > > > > (
http://twitter.com/AdamBien)
>>> > > > > > <http://twitter.com/AdamBien> Mobile: 0049(0)170 280 3144
>>> > > > > >
>>> > > > > > Author of: "Real World Java EE Night Hacks", "Real World Java
EE
>>> > > > > > Patterns--Rethinking Best Practices"
>>> > > > > >
>>> > > > > >
>>> > > > > >
>>> > > > > >
>>> > > > > >
>>> > > > > >
>>> > > > > >
>>> > > > > >
>>> > > > > >
>>> > > > > >
>>> > > > > >
>>> > > > > >
--------------------------------------------------------------------------------
>>> No virus found in this message.
>>> > > > > > Checked by AVG - <http://www.avg.com/>www.avg.com > > > > > (
http://www.avg.com)
>>> > > > > > <http://www.avg.com> Version: 10.0.1392 / Virus Database: > >
> > > 1520/3884 -
>>> > > > > > Release Date: 09/08/11
>>> > > >
>>> > > >
--------------------------------------------------------------------------------
>>> No virus found in this message.
>>> > > > Checked by AVG - <http://www.avg.com>www.avg.com > > > <
http://www.avg.com>
>>> > > > Version: 10.0.1392 / Virus Database: 1520/3885 - Release Date: > >
> 09/08/11
>>
>>
>
>