On Tue, 2012-09-25 at 03:43, Simon IJskes - QCG wrote:
> > For service definition, I'm thinking something like this (starting from
> > your DemoServiceImpl class):
> >
> > @Service(exporter="defaultExport", join="defaultJoin")
> > @NameEntry("DemoService")
> > @ServiceInfo(name="DemoService", manufacturer="Apache Software
> > Foundation",
> > model="demo-101", version="1.0")
> > public class DemoServiceImpl
> > implements DemoService
>
> I like annotations, but feel that using this much will cause friction by
> the configuration file users (by choice of by conviction). You probably
> read Dan's reply in the mean time.
>
Also keep in mind that the annotations can refer to the config file. In
the sample above, I pictured the 'defaultExport' exporter and
'defaultJoin' JoinAdmin being setup in a configuration file, as per
current practise.
I agree that putting the registration attributes (e.g. @NameEntry) in
the code is a slightly questionable. Just thinking out loud here - it
seems like the developer might want to state "there needs to be a name
attribute", but leave the name up to the ops team. How about an
expression language in the annotation attributes that can refer to the
configuration object?
For instance,
@NameEntry(name='#{config.serviceName}')
Actually, I kind of like that... the container could probably even
deduce that the configuration needs an entry called 'serviceName', and
auto-gen a deployment config file that ops can then edit.
Greg.
> > My thought is that you'd package one or more of these classes in a jar
> > file (service archive, or ".sar"?) and deploy it to the service
> > container. Much like in EJB3, the container would scan the jar file for
> > deployable services, and export, then register them in the appropriate
>
> I like the idea of 'dropping them into a container', but would like a
> separation between the dropping/scanning part and the actual service
> startup, in such a way that programmed configuration/embedding is still
> possible.
>
That seems like a question of run-time behaviour options on the
container. During development, you probably want to just auto-deploy
whenever you compile. For a production container, I don't see any
reason you couldn't configure the container to scan and stage the
deployment, then give 'ops' a chance to review and edit the deployment
plan before hitting the "start" button.
> Gr. SImon
