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

Reply via email to