@In with configurable component name - is it possible?

[asavitsky]

Is it possible to declare an @In property in an (abstract) superclass, but allow subclasses to configure the actual component name that gets injected? Currently, the only way I found was to declare an abstract String getComponentName() in superclass, and retrieve the query via Component.getInstance(getComponentName()) instead of @In declaration - but I consider this way to be rather ugly. Are there any alternatives, or maybe some planned enhancements?

Thanks,

Alex

[pmuir]

I'm not sure how we could improve on:

abstract superclass

potected abstract Foo getFoo();

private doSomething() {
 getFoo().doFooAction();
}

impl

@In Foo foo;

public Foo getFoo() {
 return foo;
}

[asavitsky]

My main concern with your approach is that the whole @In semantics gets lost from the parent class, even though it clearly belongs there. I was thinking of something like an @Override annotation that would look something like:

public class Parent {
 @In private Foo foo;
}

@Override (
 property = "foo",
 overrides = {
 @In ("specificFoo")
 })
public class Child {
}

I found that it's possible to do the overriding in XML, but that's static DI, not bijection. I'll try making foo a Seam's ValueBinding, maybe that would result in true bijected foo...

[pmuir]

"ASavitsky" wrote:
My main concern with your approach is that the whole @In semantics gets lost from the parent class, even though it clearly belongs there.

I'm not convinced of this, can you tell me why?

@Override (
 property = "foo",
 overrides = {
 @In ("specificFoo")
 })
public class Child {
}

I think this complicates the component and the syntax far more than any benefit it gives.

[asavitsky]

Well, if it's the parent class that (exclusively) makes the use of foo, then I guess it makes sense to contain the foo declaration in parent class as much as possible. The only thing that child class does is wiring - specifying what component gets injected into foo.

Regardign the second point - yes, it does look complicated in this particular case. Yet, the generic way of overriding annotations in class hierarchy (something that Java currently lacks on the language level, IMHO) might get useful in some situations, even if it's not going to be an often-used feature.

[pmuir]

Ok, I see your point. I suspect that Gavin looked at this when designing the EntityHome stuff... Anyway, feel free to file a feature reuqest in JIRA - at least that way the issue doesn't fall below the radar.