Date: Thu, 8 Sep 2011 15:56:53 +0200
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.
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[?]
On Thu, Sep 8, 2011 at 2:18 PM, Jeff Genender <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_eeThe 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
> >>>>> 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
> >>> Version: 10.0.1390 / Virus Database: 1518/3781 - Release Date: 07/22/11
> >>>
> >>>
> >>
> >
> >
>
>
-- Werner Keil | UOMo Lead | Eclipse.org Twitter @wernerkeil | Skype: werner.keil | www.eclipse.org/uomo | #EclipseUOMo * JavaOne: October 2-6 2011, San Francisco, USA. Werner Keil, Agile Coach, UOMo Lead will co-present "JSR 321: Trusted Java API"
(image/gif attachment: 322.gif)