+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
>