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