Deepak,
Thanks a lot for your input. It's never too late, especially for
constructive feedback like the ones you mentioned.
Werner
On Sun, Sep 11, 2011 at 6:02 PM, Deepak Anupalli <deepak_at_pramati.com> 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.
>
> 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).
>
> 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.
>
> 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
> Thanks,
> Deepak
>
> ----- Original Message ----- From: "Jevgeni Kabanov" <
> jevgeni_at_zeroturnaround.com>
>
> To: <jsr342-experts_at_javaee-spec.**java.net<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<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>
>> >jgenender_at_savoirtech.com > > > > > > (mailto:jgenender_at_savoirtech.**com<jgenender_at_savoirtech.com>
>> )
>> > > > > > > <mailto:jgenender_at_savoirtech.**com <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>
>> >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/<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>
>> >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/>
>> >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)
>> > > > > > > <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><
>> 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>w**ww.eclipse.org/uomo<http://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/>bl**og.adam-bien.com<http://blog.adam-bien.com>> > > > > (
>> http://blog.adam-bien.com)
>> > > > > > <http://blog.adam-bien.com> press:
>> > > > > > <http://press.adam-bien.com/>p**ress.adam-bien.com<http://press.adam-bien.com>> > > > > (
>> http://press.adam-bien.com)
>> > > > > > <http://press.adam-bien.com> eMail:
>> > > > > > <mailto:abien_at_adam-bien.com>ab**ien_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>t**witter.com/AdamBien<http://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)
>> > > > > > <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>> > > <
>> http://www.avg.com>
>> > > > Version: 10.0.1392 / Virus Database: 1520/3885 - Release Date: > > >
>> 09/08/11
>>
>
>
>