+1 to this, great work! I must try out once I move to 2.0 branch! :)
Quoting Rickard Öberg <[email protected]>:
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
_______________________________________________
qi4j-dev mailing list
[email protected]
http://lists.ops4j.org/mailman/listinfo/qi4j-dev
