On 09.09.2011, at 23:33, Bill Shannon wrote:
> What does "configuring the app environment" mean? For example?
>
> Who would use the API?
Application server plugin (like it is already the case in JACC)
The application itself. It could be injectable.
> The app itself? Some other Java EE app configuring
> this Java EE app?
Yes. The configuration API should be injectable. The app itself could be also configure itself. E.g. Servlets 3.0 are doing this already (without an API)
> A non-Java EE app configuring a running Java EE app?
Also important. E.g. You can configure GlassFish right now via REST / JSON
>
>
> 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
>>>>
>>>
>