Specifying service name with @Service

[kcbabo]

I thought we had a way to specify the service name in addition to the interface using the @Service annotation, but it looks like you can only specify the interface right now:

public @interface Service {
    /**
     * Get the Service Interface for the Service.
     */
    Class<?> value();
}

I want to do this:

@Service(interface = Foo.class, name = "{urn:bleh}FooBar")

Seems like a reasonable requirement, but I may be forgetting a discussion/decision here.  Thoughts?

[kcbabo]

Actually, we can keep the default value element and just add the name element.  This keeps us backward compatible and also happens to be the way that the SCA Java spec defines it.*

public @interface Service {
    /**
     * Get the Service Interface for the Service.
     */
    Class<?> value();

    /**
     * Service name.
     */
    String name();
}

@Service(value = Foo.class, name = "{urn:bleh}FooBar")

* SCA actually allows an array to be specified, but we don't support that an implementation level at this point.  Once we do, this change will also be backward compatible as current uses of the annotation are essentially a one-element array.

[jpechanec]

Hi,

I was thinking about that idea too. But you are realying heavily on CDI too. How about using CDI's approach and allow to add qualifier annotation(s).

So you would define an annotation that will represent for example  a Gold service level

public @interface Gold {
    String name() default "{urn:foo}bar";
}

And  then define service using

@Gold @Service(...)

and reference using

@Inject @Gold @Reference AnotherService service;

And if @Service annotiation is going to be modified would not be nice to add a support for defining a composite name so service can be groupped together? Or maybe using qualifier annotation for this purpose?

[kcbabo]

I think the use of CDI annotations to describe behavior is an interesting one.  I would say that I find it most appropriate to describe behavior (declaring a service, defining policy, etc.) and since we already have an annotation for declaring a service, adding the service name as an element to that annotation seems natural.  Bean services always map to the composite defined in the current project's application, and there's only one composite per application, so I don't think we need to make that configurable via annotation.

Using your example of @Gold, it would be interesting to have a scenario where @Gold mapped to a policy where only gold customers had access to the service.  So perhaps we revisit this when we look at how policy declarations map to Bean services?

Thanks for your feedback.