On 10.09.2011, at 01:11, Bill Shannon wrote:
> We have the ability to supply an "alternative" deployment descriptor
> when you deploy an application. Is that sufficient for configuring and
> overriding the things that you can specify in a deployment descriptor?
>
> If the application is handling other app-specific configuration by (e.g.)
> reading properties from a properties file, then having the ability to
> specify an overriding or augmenting property file at deployment time
> (packaged separately from the app) might be reasonable.
But it should not be required. IMHO: the additional configuration can be packaged with or without the application.
> Is that the
> sort of thing you're looking for?
>
> Would it help if we made it possible to specify JNDI environment entries
> in a property file instead of in XML in a deployment descriptor?
Yes. But why just property files? If we specify a simple API we could use any format we like.
>
>
> Jeff Genender wrote on 09/ 9/11 06:35 AM:
>>
>> On Sep 9, 2011, at 4:54 AM, Adam Bien wrote:
>>
>>> Hi Jeff,
>>>
>>> your client seems to be big. There are strange rules in bigger (european)
>>> companies regarding deployment as well. E.g.: sometimes the application does
>>> *not* have to be tested if "only" the XML changes. Sometimes I suggest to use
>>> Jelly (http://commons.apache.org/jelly/) in such cases, so we could get rid
>>> off testing completely :-)
>>> IMHO: XML can affect robustness and should be treated as code. There should be
>>> no difference between changing Java-based, or XML based configuration.
>>>
>>
>> Yeah, my clients are generally big (finance houses and public companies are the
>> ones who are stringent) ;-)
>>
>> Your last statement is spot on: "XML can affect robustness and treated as code".
>> In our world, that makes sense. In their world (ops), they don't want to learn
>> code. They don't want to go back and recompile so their app picks up the proper
>> resource pool. They want to edit a file. In theory, we want them to treat it as
>> code, but you know that world doesn't work that way ;-) Here is a really good
>> example….
>>
>> In many of the clients I do work for, their preference is to have 4
>> environments: Dev, QA, Staging, and Prod. Its hard enough to get passwords to
>> databases, etc in the dev environment, but the ops generals don't want us to
>> have any knowledge of any other environment, especially production level
>> passwords, locations of certain resources, etc. So they are very quick to want
>> external files (XML/Properties, etc) to edit the configurations. This goes for
>> resources stored in JNDI, etc. They actually ask for where they can configure
>> items. When I have told them we have "hard coded" a value, they get very upset.
>> ;-) This really happens all the time.
>>
>> I think if we support XML/JSON/Annotations with an override, this gives everyone
>> what they want. Devs can configure most with defaults and configuration items in
>> annotations that generally won't change. Ops have the ability to set what they
>> need in their different environments (XML/JSON). With JSON, the Ruby hipsters
>> get to embrace our wonderful technology since we speak their language. Then its
>> a win/win for everyone ;-)
>>
>> Jeff
>>
>>
>>> thanks!,
>>>
>>> adam
>>> On 09.09.2011, at 00:07, 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
>>>>>>
>>>>>
>>>>
>>>
>>> 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"
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>
>