-
1. Re: Calling CDI/EJBs with no interface.
cbrock Feb 29, 2012 10:01 PM (in response to cpuffalt)Well, the main problem is you need to have a shared interface between the client and server code for it to work. You can't just expose a server-side bean to the GWT compiler willy nilly -- you're bound to have object graphs that the GWT compiler cannot translate. Hence the need to create an interface in the client package which the server can implement.
If you have any technical suggestions of how you think this could be overcome, I definitely welcome them.
-
2. Re: Calling CDI/EJBs with no interface.
cpuffalt Mar 2, 2012 12:49 PM (in response to cbrock)My knowledge of the details are rather sketchy but I was thinking along the lines of using <super source=""> in conjunction with an annotation processor. The annotation processor(s) would generate appropriate, GWT-compatible classes into the appropriate <super source=..."> directory for no-interface beans/services. I don't see the need for a shared interface?
Is there any documentation describing at a technical level how the various pieces of Errai work together? I'm at a loss how to approach implementing this within the Errai framework assuming the approach above is feasible.
Corey
-
3. Re: Calling CDI/EJBs with no interface.
cbrock Mar 4, 2012 4:06 PM (in response to cpuffalt)I suppose that would be a good way to go about that. My only question would be how do you secure things? What are the security barriers? What if you get into the world of script injection attacks that will find clever ways to call exposed beans? A remote interface sort of makes you think about these things.
That said, I'd be curious to explore the problem.
Our RPC stuff currently sits atop ErraiBus and uses a message protocol built around it. We'd be more than happy to help you understand our code if you are interested in contributing. Join us on #errai on FreeNode. We are around generally during business hours Eastern time (and often a bit later).
-
4. Re: Calling CDI/EJBs with no interface.
cpuffalt Mar 4, 2012 11:13 PM (in response to cbrock)The security issue is a good point but I'd argue that Java developers have been so conditioned to write interfaces just to satisfy "enterprise" frameworks that security issues are not at the forefront of their mind when writing them. It's more like mindless boilerplate in many cases. I'd also say the "magic" in Errai already provides plenty of places for the unwary to be hacked via the seamless client <-> server messaging bridge. Not that I'm suggesting it's a bad thing. There should probably be a rather prominent section in the Errai documentation giving good guidence to users on how to prevent attacks.
There may be others ways that frameworks like Errai could help developers with the security aspects perhaps via a compile-time report that shows all the exposed entry points to server-side code that needs to treat incoming data as untrusted.
Anyways, good to know the approach I was thinking of doesn't sound completely rubbish. I have a full-time job (MST) so likely won't be able to chat about this further.
Regards,
Corey