jsr342-experts@javaee-spec.java.net

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

From: Reza Rahman <reza_rahman_at_lycos.com>
Date: Thu, 08 Sep 2011 21:20:23 -0400

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
>>>> <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)...
>>>> Examples are at 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
>>>> 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/.
>>>> 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 - 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 - www.avg.com <http://www.avg.com/>
>>>> >>> Version: 10.0.1390 / Virus Database: 1518/3781 - Release
>>>> Date: 07/22/11
>>>> >>>
>>>> >>>
>>>> >>
>>>> >
>>>> >
>>>>
>>>>
>>>>
>>>>
>>>> --
>>>>
>>>> Werner Keil | UOMo Lead | Eclipse.org <http://Eclipse.org/>
>>>>
>>>> Twitter @wernerkeil |Skype: werner.keil | 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: blog.adam-bien.com <http://blog.adam-bien.com/>
>>> press: press.adam-bien.com <http://press.adam-bien.com/>
>>> eMail: abien_at_adam-bien.com <mailto:abien_at_adam-bien.com>
>>> twitter: 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 - 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 - www.avg.com <http://www.avg.com>
> Version: 10.0.1392 / Virus Database: 1520/3885 - Release Date: 09/08/11
>