jsr342-experts@javaee-spec.java.net

[jsr342-experts] Re: [javaee-spec users] Re: Configuration

From: Adam Bien <abien_at_adam-bien.com>
Date: Mon, 12 Sep 2011 17:28:12 +0200

Hi Kristoffer + * ,

If we start with the minimum, we could probably go without any additional JSR.

Idea: Linda's proposal of resources looks already really good and matches closely with the configuration of already existing Java EE application servers. We could use that as a base for parameters and return values of the API. We will have to convert the Annotation to a class -> but this is an easy task

For a start we could offer merge and remove (with exactly the same semantics as JPA already has).

This would allow us to publish such an API directly via REST. Like: http://kenai.com/projects/suncloudapis/pages/HelloCloud and gives us XML and JSON formats for free.
REST gives as a clear direction and the semantics of PUT / POST / DELETE are clearly defined.

Any thoughts?

adam



On 11.09.2011, at 20:51, Kristoffer Sjögren wrote:

> Good point on the injection, I think its important to not burden applications with fetching their own configuration. A declarative annotation API similar to @Entity and @Column in JPA could be used by for this purpose I guess.
>
> Judging from the discussions, it seems as if we have touched on three different Java Configuration APIs - used by different actors and purposes I suppose.
>
> 1) User API.
> Used by applications to declare the configuration schema, properties, constraints etc. Read-only.
>
> 2) Administration API.
> Used by system administrator to manage configuration using CRUD-like operations. Dynamically discover application configuration schemas at runtime and validates that configuration changes are valid.
>
> 3) Storage SPI.
> To be implemented by storage providers such as db, file, jndi, mib etc. Each AS could provide a default.
>
> Werner: +1 for separate JSR, Configuration Management is such a huge topic and deserves a JSR in its own right.
>
> Cheers,
> -Kristoffer
>
>
> 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.
>
> 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
>
>
>