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>> 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>> 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>
>>>>>>>>>>> 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>
>>>>>>
>>>>>> Twitter @wernerkeil |Skype: werner.keil |
>>>>>> <http://www.eclipse.org/uomo>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> press:
>>>>> <http://press.adam-bien.com/>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> twitter:
>>>>> <http://twitter.com/AdamBien>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> 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
>>>
>>