Hey,
I just finished a very interesting test: using a class (instead of an
interface) as a TransientComposite. Example:
public static class CapitalizeConcern
extends GenericConcern
{
@Override
public Object invoke( Object proxy, Method method, Object[]
args ) throws Throwable
{
if (args != null)
{
args[0] = ((String)args[0]).toUpperCase();
return next.invoke( proxy, method, args );
} else
return next.invoke( proxy, method, args );
}
}
@Concerns(CapitalizeConcern.class)
public static class AnyTransient
implements TransientComposite
{
@Structure
Module module;
public String hello(@MaxLength(5) String name)
{
return "Hello "+name+" from "+module.name();
}
}
---
As this shows you can use both constraints/sideeffects/concerns. What
happens is that Qi4j creates two subclasses of AnyTransient, one for the
proxy and one for the mixin. The proxy subclass delegates to
CompositeInstance for all invocations, which goes through the usual
invocation chain, and ends up on an instance of the mixin.
Because of this, in effect there will be TWO instances of AnyTransient
for any Qi4j instance: one for the proxy (which just delegates) and one
for the actual "mixin" (even though there is no interface).
To me, the most important of this is that I can now use constraint
annotations on regular classes without having to make them interfaces.
This is a major advantage!
Since the whole thing is a composite, technically, concerns and even the
class itself can use @This injections to private mixins.
This is available in the v2.0 branch, look in
TransientBuilderFactoryTest for the example code.
/Rickard
_______________________________________________
qi4j-dev mailing list
[email protected]
http://lists.ops4j.org/mailman/listinfo/qi4j-dev
