We use annotations in Gogo to provide metatype information for Gogo
commands and for the help system. I think the point is, if you want
this, you have to make it a feature of the service contract, you cannot
leave it up to the implementers.
-> richard
On 4/10/12 14:07 , Christian Schneider wrote:
I don´t think that this would be a good design. By using impl specific
annotations you would bind the executor and the GUI to each specific
impl.
What you could do though is define a meta model for the parameters.
And then each impl could publish a service that returns the model of
the impl.
So the GUI could check the services and provide a generic GUI for each
impl.
For example the config admin service has the metatype service to
describe the model of specific configs. Felix then provides a generic
Web Console that displays a nice Form for each
config PID.
See:
http://www.liquid-reality.de/display/liquid/2011/09/26/Karaf+Tutorial+Part+3+-+Improving+configuration+editing+using+the+OSGI+Metatype+Service+and+the+Felix+Webconsole
Perhaps something like this could make sense for you
Christian
Am 10.04.2012 19:26, schrieb Quecas:
Thanks for the input guys.
I have given this use case some thought, and yes there are a few ways of
accomplishing what's needed - annotations just seem like a natural
fit...
Suppose there's an interface called Task which defines one method - void
execute(Context ctx).
Task implementations may come and go and there may be many different
types
of Tasks.
An executing task can query ctx for specific inbound parameters which
were
defined AND HERE IT COMES... by annotations. These annotations would
have
been picked by for example, some GUI TOOL where a user would have
defined
values for specific parameters belonging to a specific TaskImpl
I could also add List<Parameter> getTaskParameters() to the Task
interface
making it part of the API, but annotations feel like a natural fit
here -
what you guys think?
Is it correct then to say that the bottom line with respect to OSGI and
making these annotations available in this use case, would require the
implementers of Task to make the pkgs public? An import package would
probably also be required somewhere else.
Thanks,
Jorge
Richard S. Hall wrote:
On 4/10/12 11:15 , Quecas wrote:
Hello everyone,
One of the big paradigms of OSGI is to define a public API/SPI as an
interface while keeping the implementation(s) private. Having said
that
and
if the various implementations of a specific service each define
meta-data
using annotations, how would one get to this information without
shifting
from the paradigm or "bending" the rules.
Are you talking about service properties, for example? For those types
of things you need to limit yourself to only using standard properties.
If you need stuff that is in non-standard properties, then you are
going
to be bound to implementations.
-> richard
Thanks,
Jorge
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
