Hi Howard,
Thanks for the prompt answer. My understanding is that service markers are
meant to be used to distinguish between different implementations of the
same service interface and I'm not sure if it would be good idea to mix them
with meta information related directly to application logic. Moreover, there
are few issues with the approach based on service markers:
1. Markers usage is less elegant and user friendly than direct usage of
annotations because instead of this simple form:
@Destination
public class MyServiceImpl implements MyService {
...
}
we would have to use something like this:
@Marker(Destination.class)
public class MyServiceImpl implements MyService {
...
}
2. With markers we would loose possibility to use annotation attributes and
something like this would not be possible:
@Destination(channel="amf")
public class MyServiceImpl implements MyService {
...
}
3. Markers can be used on service classes only, but in some situations it
would be quite handy to be able to detect annotated methods. For instance
I've got in my mind tapestry-quartz integration based on simple declarative
principle where it would be possible to use something like this:
public class MyServiceImpl implements MyService {
@Scheduled(cronExpression="0/5 * * * * ?")
public void myMethod() {
...
}
}
and framework would be able automatically detect all methods annotated by
@Scheduled annotation and register them in scheduler.
Solution based on decorators is also not feasible because services are
decorated only when they are instantiated and I'm looking for some solution
that would allow us to detect annotations without service instantiation.
The only feasible solutions I can think of are:
1. Modify ServiceDef to hold information about service implementation class.
2. Service proxy could inherit all annotations from service implementation
class, then we would be able to check annotations directly on service proxy.
3. Use annotations on service interface instead of service implementation
(this is workaround I'm currently using).
Regards,
Lubor
On Tue, Nov 4, 2008 at 4:48 PM, Howard Lewis Ship <[EMAIL PROTECTED]> wrote:
> It would be nice if there was a method on Registry or ObjectLocator:
> List<Object> findServicesWithMarker(Class<? extends Annotation>
> annotationClass);
>
> Alternately, adding a way to expose the ServiceDefs for all services (they
> are immutable). You can collect service interface and marker information
> there.
>
> Also, some kind of post-construction callback would be nice; you could do
> this using a decorator method.
>
>
> On Tue, Nov 4, 2008 at 8:06 AM, Lubor Gajda <[EMAIL PROTECTED]> wrote:
>
> > Hi,
> >
> > I'm currently working on T5-IOC and BlazeDS integration and I'm looking
> for
> > some simple declarative way how to automatically register application
> > services as BlazeDS destinations.
> >
> > What I want to achieve is to be able to automatically detect all services
> > in
> > T5-IOC registry annotated by my custom @Destination annotation and
> register
> > them using BlazeDS API. To implement this logic I'm using following
> > algorithm:
> >
> > 1. First of all I need to get list of all service definitions available
> in
> > the T5-IOC registry. The only solution how to do this, I've found so far,
> > is
> > to use ServiceActivityScoreboard.getServiceActivity().
> >
> > Is ServiceActivityScoreboard really the only way how to list all services
> > available in T5-IOC registry or is there any better way how to do this?
> >
> > 2. Once I have the list of all available services I need to check
> > annotations on implementation class of each of them. The problem here is
> > that service definition provides information about service interface only
> > and not about service implementation class.
> >
> > Is there any way how to do this and detect if any of service
> > implementations
> > (or any of its methods) is annotated by some specific annotation
> (without
> > service instantiation)?
> >
> > Thanks,
> > Lubor
> >
>
>
>
> --
> Howard M. Lewis Ship
>
> Creator Apache Tapestry and Apache HiveMind
>
