On Tue, 2012-09-25 at 05:05, Simon IJskes - QCG wrote:
> On 25-09-12 10: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?
>
> Or do we use the Class as an id?
I think you'd probably use the class name to identify which class the
overrides belong to. I kind of pictured the "@Service" annotation as
being the touchpoint that says "this class should be instantiated and
configured as a service", and then the other annotations simply adding
detail to that.
Another option would be nesting annotations, e.g.
@Service(attributes= {
@NameEntry(...), @ServiceInfo(...) } )
But I started thinking that the syntax starts getting too complicated.
Greg.
