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. 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?
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"
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>