You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@felix.apache.org by Quecas <jm...@gmail.com> on 2012/04/10 17:15:43 UTC
Annotation Decorated Service
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.
Thanks,
Jorge
--
View this message in context: http://old.nabble.com/Annotation-Decorated-Service-tp33662168p33662168.html
Sent from the Apache Felix - Users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Annotation Decorated Service
Posted by Quecas <jm...@gmail.com>.
Hi Christian,
Yip, for this use case and IMHO it seems better than coupling another method
like List<Paramters> getTaskParameters() to the Task interface.
Jorge
Christian Schneider wrote:
>
> Hi Jorge,
>
> that design looks good. As the annotations are part of the public
> interface you get nice separation from the impls.
>
> Christian
>
> Am 10.04.2012 22:52, schrieb Quecas:
>> Hi Guys,
>>
>> I've solved the problem...
>>
>> Since the Task implementations are dropins in an inner OSGI platform, the
>> bundle that launches this inner platform must also import pkg x. This is
>> a
>> separate requirement that makes pkg x available to the dropins through
>> FRAMEWORK_SYSTEMPACKAGES_EXTRA.
>>
>> Again, thanks to all - great to see such a vibrant community!!
>>
>>
>> Quecas wrote:
>>> Mark, in the POC I've set up, your suggestion was the exact scenario I
>>> had
>>> imagined...
>>>
>>> interface Task \
>>> @interface Parameters (Parameter[]) |__ pkg x (public API)
>>> @interface Parameter |
>>> /
>>>
>>> Task[] tasks = taskQueryService.getAllTasks();
>>> for(Task task: tasks) {
>>> if(task.getClass().isAnnotationPresent(Parameter(s).class)) {
>>> // do stuff required for GUI...
>>> }
>>> }
>>>
>>> However, isAnnotationPresent always returns false, which I think
>>> probably
>>> makes sense when I give it a little more thought (class loading)
>>>
>>> Is this what you had in mind Ricahrd?
>>>
>>> Thanks
>>> Jorge
>>>
>>>
>>> Richard S. Hall wrote:
>>>> 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
>>>>>
>>>>>
>
> --
> Christian Schneider
> http://www.liquid-reality.de
>
> Open Source Architect
> Talend Application Integration Division http://www.talend.com
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
>
--
View this message in context: http://old.nabble.com/Annotation-Decorated-Service-tp33662168p33669978.html
Sent from the Apache Felix - Users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Annotation Decorated Service
Posted by Christian Schneider <ch...@die-schneider.net>.
Hi Jorge,
that design looks good. As the annotations are part of the public
interface you get nice separation from the impls.
Christian
Am 10.04.2012 22:52, schrieb Quecas:
> Hi Guys,
>
> I've solved the problem...
>
> Since the Task implementations are dropins in an inner OSGI platform, the
> bundle that launches this inner platform must also import pkg x. This is a
> separate requirement that makes pkg x available to the dropins through
> FRAMEWORK_SYSTEMPACKAGES_EXTRA.
>
> Again, thanks to all - great to see such a vibrant community!!
>
>
> Quecas wrote:
>> Mark, in the POC I've set up, your suggestion was the exact scenario I had
>> imagined...
>>
>> interface Task \
>> @interface Parameters (Parameter[]) |__ pkg x (public API)
>> @interface Parameter |
>> /
>>
>> Task[] tasks = taskQueryService.getAllTasks();
>> for(Task task: tasks) {
>> if(task.getClass().isAnnotationPresent(Parameter(s).class)) {
>> // do stuff required for GUI...
>> }
>> }
>>
>> However, isAnnotationPresent always returns false, which I think probably
>> makes sense when I give it a little more thought (class loading)
>>
>> Is this what you had in mind Ricahrd?
>>
>> Thanks
>> Jorge
>>
>>
>> Richard S. Hall wrote:
>>> 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
>>>>
>>>>
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
Talend Application Integration Division http://www.talend.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Annotation Decorated Service
Posted by Quecas <jm...@gmail.com>.
Hi Guys,
I've solved the problem...
Since the Task implementations are dropins in an inner OSGI platform, the
bundle that launches this inner platform must also import pkg x. This is a
separate requirement that makes pkg x available to the dropins through
FRAMEWORK_SYSTEMPACKAGES_EXTRA.
Again, thanks to all - great to see such a vibrant community!!
Quecas wrote:
>
> Mark, in the POC I've set up, your suggestion was the exact scenario I had
> imagined...
>
> interface Task \
> @interface Parameters (Parameter[]) |__ pkg x (public API)
> @interface Parameter |
> /
>
> Task[] tasks = taskQueryService.getAllTasks();
> for(Task task: tasks) {
> if(task.getClass().isAnnotationPresent(Parameter(s).class)) {
> // do stuff required for GUI...
> }
> }
>
> However, isAnnotationPresent always returns false, which I think probably
> makes sense when I give it a little more thought (class loading)
>
> Is this what you had in mind Ricahrd?
>
> Thanks
> Jorge
>
>
> Richard S. Hall wrote:
>>
>> 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: users-unsubscribe@felix.apache.org
>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>
>>>>
>>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>>
>>
>
>
--
View this message in context: http://old.nabble.com/Annotation-Decorated-Service-tp33662168p33664296.html
Sent from the Apache Felix - Users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Annotation Decorated Service
Posted by Quecas <jm...@gmail.com>.
Mark, in the POC I've set up, your suggestion was the exact scenario I had
imagined...
interface Task \
@interface Parameters (Parameter[]) |__ pkg x (public API)
@interface Parameter |
/
Task[] tasks = taskQueryService.getAllTasks();
for(Task task: tasks) {
if(task.getClass().isAnnotationPresent(Parameter(s).class)) {
// do stuff required for GUI...
}
}
However, isAnnotationPresent always returns false, which I think probably
makes sense when I give it a little more thought (class loading)
Is this what you had in mind Ricahrd?
Thanks
Jorge
Richard S. Hall wrote:
>
> 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: users-unsubscribe@felix.apache.org
>>> For additional commands, e-mail: users-help@felix.apache.org
>>>
>>>
>>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
>
--
View this message in context: http://old.nabble.com/Annotation-Decorated-Service-tp33662168p33664111.html
Sent from the Apache Felix - Users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Annotation Decorated Service
Posted by "Richard S. Hall" <he...@ungoverned.org>.
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: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Annotation Decorated Service
Posted by Marcel Offermans <ma...@luminis.nl>.
Sounds to me like your Task services are configurable, and you should consider using Configuration Admin to provide them with their configuration. The services themselves can then propagate the configuration (or the relevant parts of it) as service properties. You can still convert your annotations to configuration, feed that to Configuration Admin and have it picked up.
Greetings, Marcel
On Apr 10, 2012, at 19:26 PM, 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: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>>
>>
>
> --
> View this message in context: http://old.nabble.com/Annotation-Decorated-Service-tp33662168p33663049.html
> Sent from the Apache Felix - Users mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Annotation Decorated Service
Posted by "Richard S. Hall" <he...@ungoverned.org>.
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: users-unsubscribe@felix.apache.org
>>> For additional commands, e-mail: users-help@felix.apache.org
>>>
>>>
>>>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Annotation Decorated Service
Posted by Christian Schneider <ch...@die-schneider.net>.
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: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>>
>>
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
Talend Application Integration Division http://www.talend.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Annotation Decorated Service
Posted by Quecas <jm...@gmail.com>.
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: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
>
--
View this message in context: http://old.nabble.com/Annotation-Decorated-Service-tp33662168p33663049.html
Sent from the Apache Felix - Users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Annotation Decorated Service
Posted by "Richard S. Hall" <he...@ungoverned.org>.
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: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Annotation Decorated Service
Posted by Marcel Offermans <ma...@luminis.nl>.
Hello Jorge,
On Apr 10, 2012, at 17:15 PM, Quecas wrote:
> 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.
You are talking about using annotations on a "POJO" that implements an interface but has no dependencies whatsoever on the OSGi framework?
If so, then annotations are sort-of-evil in my book.
I look at annotations as part of the API, so if these annotations link you to an OSGi (framework) specific API, they are bad if they appear in the POJO (which then no longer is a POJO).
There is one "but" here, and that is that annotations are optional. If you load a POJO that has annotations, and those annotations are not available on the classpath, they don't get loaded. In fact, some annotations don't even appear in the class at runtime and are just there for the compiler or some pre-processor. From that point of view, they are like optional imports and one could argue that it does not make the POJO depend on the API (only optionally). On the other hand, if, to reuse the POJO in different frameworks, each framework requires its own set of annotations, then compiling the POJO with all these different sets of annotations becomes difficult and it's not a direction I would want to go in (and having lots of annotations on all kinds of methods does not make the code more readable either).
About getting to such metadata at runtime, I would advise you to use service properties whenever this information can be used to select a service from a collection of ones with the same interface.
Hope this answers your question. :)
Greetings, Marcel
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Annotation Decorated Service
Posted by Christian Schneider <ch...@die-schneider.net>.
You should define as much of the metadata as possible in the public
interface. Then it can be used regardless of the implementation.
If an implementation defines additional annotations then these
annotations will bind you to that implementation.
In practice you will probably have a mix of that where most annotations
are defined in the interface and you will still have some exotic stuff
that is impl specific.
Quite like in jpa where most annotations are defined at the jpa level
but some special annotations are e.g. hibernate specific.
This is not really osgi specific btw. Having a separate interface is
already good practice outside of osgi. What really makes OSGi shine is
that a service impl can initialize itself using an Activator or a
blueprint. So the user of the service does not have to know how to
initialize the service. Outside of OSGi you always have the problem of
how to initialize the impl behind the interface and how the user of the
service finds the service ... most of these solutions are ugly.
Christian
Am 10.04.2012 17:15, schrieb Quecas:
> 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.
>
> Thanks,
> Jorge
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
Talend Application Integration Division http://www.talend.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org