On 10/14/2010 11:04 AM, Greg Trasuk wrote:
On Thu, 2010-10-14 at 11:10, Gregg Wonderly wrote:
The same service can then be deployed into other containers if those containers
support the River standard mechanisms by looking at deployed service classes for
an interface/abstract class and then calling methods appropriately.
Any suggestions on what kind of API we need? I have some thoughts, but perhaps
others have already done this themselves?
Gregg Wonderly
The one thought I have is that we should probably favour a set of
annotations (a-la-EJB) rather than a service interface.
What I am trying to think about regarding annotations, is the static
"information" annotations provide vs some of the dynamic information that flows
between services and containers.
Maybe you (and others) can elaborate a bit on how you view annotations being
used in River?
Using it to mark methods for particular uses, as you might use an interface, can
work in many cases, but specific information returned from methods needs to
match the expectations of the receiver, and so I worry that some aspects of
annotations are not as concrete as might be necessary.
The other issue for me, is that sometimes people overuse annotations to try and
fit existing code into a new use, and end up with a layer of meta-control, that
would better be expressed in a proxy/delegate object to keep it out of view of
places where it doesn't matter.
But, please let me know your view and everyone else can jump in with their ideas
to help get something going.
Gregg Wonderly
