It seems like you should just be creating a set of annotations that are
part of the service package, then all implementations and clients can
use them, no?
-> richard
On 4/10/12 13:26 , Quecas wrote:
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]
