I agree that Linda's proposal for resource configuration looks good - this
approach would allow applications to override configuration meta-data
defaults using code. But would applications be able to use such an API to
plug-in their individual configuration meta-data? I think there is a lot to
gain by managing server and application configuration the same way.
Consider the following hasty example (leaving out some classes for brevity)
- approaching the problem from a slightly different angle (notice the use of
JSR 303 annotations).
// Configuration Schema for DataSource
@Configuration(DataSource.class)
public class DataSourceConfiguration {
@Name
private String name;
@Property(desc = "User name to use for connection authentication.")
@Size(min = 6, max = 255)
private String user = ""; // default value - hence optional property
@Property(desc = "Password to use for connection authentication.")
@Size(min = 6, max = 255)
private String password = ""; // default value - hence optional property
@Property(desc = "Port number where a server is listening for requests.")
@Min(0)
@Max(65535)
private Integer portNumber = 1521; // default value - hence optional
property
// etc etc ...
}
@Stateless
public class SessionBean {
// @Qualifier ..
@MysqlDataSource
private DataSource qualifiedDatasource;
// .. or @Named.
@Named("jdbc/mysql-ds")
private DataSource namedDataSource;
@Produces @MysqlDataSource
public DataSourceConfiguration getApplicationDefaults() {
return new DataSourceConfiguration.Builder("jdbc/mysql-ds")
.username("test")
.password("test");
}
}
The configuration used to instantiate and inject the actual resource could
be resolved using a per-property "fall-back-merge" mechanism; where
administrator runtime configuration takes precedence, followed by
application defaults (the producer method) and lastly static configuration
meta-data.
Using REST for administration is a good idea but will on the other hand make
it difficult to use other protocols. If we use Java (for now) people can be
allowed to build their own endpoints; using any protocol they like.
I dont want too sound negative here, I care and want to explore this
further. Hence throwing some ideas and concerns on the table :-)
Cheers,
-Kristoffer
On Mon, Sep 12, 2011 at 5:28 PM, Adam Bien <abien_at_adam-bien.com> wrote:
> 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<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%29.>
>>> ..
>>> 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
>>>
>>
>>
>>
>
>
>