interceptors
by Erik Jan de Wit
Hi Guys,
What I like in a lot of security frameworks is that one can secure method calls with a simple annotation. So my idea was that we could make something like @RequireAuthentication on the remote interface and that would not allow the call if nobody is logged in. We could develop something like this based on the InterceptedCall functionality, but because of the way InterceptedCall is setup there is no way to make another annotation behave like InterceptedCall. To make it a bit more clear i cannot define an annotation like this:
@Retention(RetentionPolicy.RUNTIME)
@Target({ElementType.TYPE, ElementType.METHOD})
@InterceptedCall(SecurityInterceptor.class)
public @interface RequireAuthentication {
}
and have the SecurityInterceptor invoked the only way I can do it is by annotating the methods with:
@InterceptedCall(SecurityInterceptor.class)
Why now have it more like the CDI interceptor api http://docs.oracle.com/javaee/6/api/javax/interceptor/InterceptorBinding....
This gives me the ability to lousily couple the annotation with the interceptor are there reasons for the model that is implemented now? Can we change it so that it will be more flexible? Or shall we stick with how it's is now and extend the functionality to make it work with my example annotation?
Cheers,
Erik Jan
11 years, 7 months
Errai vs. RequestFactory - where to go?
by Thomas Frühbeck
Hi,
I have been working on a CRUD-enabling plugin for Forge some time ago
and have been immersed in a real world project using it's outcome for
some time (Jonathan Fuerth has been discussing it already).
While trying to find a useful abstraction for the persistence bridging
code I totally overlooked GWT RequestFactory, which seems to provide an
interesting framework for CRUD applications.
IMHO the most important points:
- an EntityProxy interface and along with it an EntityProxyId
- client side RequestContext for instantiation and lookup
- an extensible server side instantiation and lookup framework
- a transportable/queuable abstraction for entity changes
These are IMHO indispensable to bridge to ORM because GWT imposes too
many restrictions on the classes/code it can handle.
I have had an intensive look at the code to find a reason for Errai
_not_ to support this part of GWT, and I think that Errai is nearly there.
- Interfaces: ObjectBuilder and ClassBuilderTest show, that an
implementation of new <Interface>() {} is prepared already to great extent
- server side lookup: would be implementable as kind of server side
"second pass" DefinitionsFactory.loadCustomMappings - I did it by
hooking statically into custom MappingDefinitions
It is yet unclear for me how a client side RequestContext could look
like, if it should work transparent and annotation driven.
Ditto for EntityChange events.
I read in a blog comment by Mike Brock, that you do not plan to support
RequestFactory.
Can you please provide some insight why you do not want to go that route
and what kind of alternative you are working on?
Best regards,
Thomas
11 years, 7 months