For me, the question is whether there is something to get out of annotation processing. Like, for example, generating a "text" config file that matches/extracts all the data that the annotations represent. That would allow ops teams to have "everything" in hand to "tweak". They'd know everything that the developer had allowed them to tweak, and what the defaults were.
Gregg Wonderly On Sep 25, 2012, at 7:11 AM, Simon IJskes - QCG <[email protected]> wrote: > On 25-09-12 11:26, Greg Trasuk wrote: >> >> On Tue, 2012-09-25 at 04:32, Simon IJskes - QCG wrote: >>> On 25-09-12 09:59, Dan Creswell wrote: >>>>> Glad you introduced ops teams. Would a middle ground be possible? Two >>>>> options: A annotation refering to a part in a deployment configuration >>>>> file, or using the annotations as defaults, and provide ops team with a >>>>> overriding option? >>>> I was edging towards the latter whilst scribbling the above... >>> >>> We need an id to hang overrides onto, so i've created the ServiceClass >>> annotation. Greg, are you ok with this? >> >> Sure. I suspect we need to flesh out some samples and see how they >> look, then edit the "annotation vocabulary". > > I've created > <http://svn.apache.org/viewvc/river/jtsk/trunk/netbeans/federation/src/org/apache/river/federation/IntrospectionConfiguration.java?view=markup>. > > Would this be too much encapsulation? It would be nice if we had some kind of > introspection information collector where we can put all annotation parsing. > > > -- > QCG, Software voor het MKB, 071-5890970, http://www.qcg.nl > Quality Consultancy Group b.v., Leiderdorp, Kvk Den Haag: 28088397
