I wouldn't limit its scope to before deployment, but the idea is good.
WLST scripts, based on JPython is a solution like that for WebLogic.
The fact alone, GlassFish either has something else or isn't yet so advanced
in this area. So Oracle can benefit from that like other vendors and of
course developers and admins being able to rely on a standard rather than
having to learn different methods of configuration with every other project.
Werner
On Sep 10, 2011 10:15 PM, "Jevgeni Kabanov" <jevgeni_at_zeroturnaround.com>
wrote:
> 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
>
>