-
1. Re: Calling CDI/EJBs with no interface.
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.
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.
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.
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