Martin Probst wrote:
>> Yes, this is exactly what I'm doing. I'll try the SNAPSHOT on my code.
>
> I'm happy to report that it does work.
Phew!
> However I'd like to suggest that
> the API might benefit from some simplification. It's probably nice to
> have access to the complex cases, but in most cases you probably just
> need two things: inject a global instance (singleton-style), or inject a
> per-request instance.
Right, i created two helper classes for that:
SingletonTypeInjectableProvider
PerRequestTypeInjectableProvider
But i think they could be improved just to work using Class instead of
Type then things a statically typed.
> In the first case, you probably already have the
> instance there, and in the second case you'd probably want to supply a
> nested class that will return the instance on every request.
>
> E.g.:
>
> @Override
> protected void initiate(ResourceConfig rc, WebApplication wa) {
> rc.addSingletonInstance(MyAnnotation.class, MyType.class, myInstance);
> rc.addPerRequestInjectable(MyAnnotation.class, MyOtherType.class,
> new Injectable<MyOtherType>() { get() { return myInstance2; } });
> }
>
What about the following:
rc.getProviderInstance().add(
new SingletonTypeInjectableProvider<MyAnnotation>(
MyType.class, myInstance));
rc.getProviderInstance().add(
new PerRequestTypeInjectableProvider<MyAnnotation>(
MyOtherType.class) {
Injectable<MyOtherType>() get(HttpContext c) { ... } });
I could simplify the names to: SingletonInjectable and PerRequestInjectable:
rc.getProviderInstance().add(
new SingletonInjectable<MyAnnotation>(
MyType.class, myTypeInstance));
rc.getProviderInstance().add(
new PerRequestInjectable<MyAnnotation>(
MyOtherType.class) {
Injectable<MyOtherType>() get(HttpContext c) { ... } });
> I agree that the method names suck, and you could probably make this
> even easier by just assuming that people will use the "Context"
> annotation, or the "Inject" annotation (where's the difference
> anyways?).
The Inject defers to the ComponentProvider to obtain an instance. It is
a way of supporting injection of say other Spring-based components for
parameters of constructors, resource method, and sub-resource locators.
Context was really meant for JAX-RS and implementation specific
injectable stuff. But i suppose it does not have to be.
> This reduces the number of classes needed by two or one,
> depending on use case, and I personally think it's a lot more
> straightforward.
>
I will have to think some more about the methods, the reason being is
the current infrastructure relies on the annotation being specified as
part of the generic declaration of the class. But, it should be possible
to support for @Context.
Paul.
--
| ? + ? = To question
----------------\
Paul Sandoz
x38109
+33-4-76188109