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: [email protected]
>>>> For additional commands, e-mail: [email protected]
>>>>
>>>>
>>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [email protected]
>> For additional commands, e-mail: [email protected]
>>
>>
>>
>
>
--
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: [email protected]
For additional commands, e-mail: [email protected]
