thanks for the pointers.I checked them but,
- do I need to tackle remoting, even if my primary objective is getting it to work inside the embedded web container in the same jboss instance as the EJB facade. I thought jboss optimizes calls within the same VM to avoid unnecessary serialisation. But I get the same error on my web client. Would strictly using @Local annotation on the facade bean help?
- My use case is even more dynamic than the examples provided: in theory, a class implementation is loaded from a database record on each call using a custom PAR file classloader provided by JBPM. I can't imagine being able to hook that classloader to some jboss exported classloading structure...
Maybe I'll just have to retrieve the class bytecode as a byte and do the classloading on the client...
How about creating a ClassLoader that delegates to an EJB (or Servlet) which loads up the correct byte code?
Then on the client it's just a matter of using that ClassLoader as your TCCL.
In fact, if you use a Servlet, you can probably just use URLClassLoader.
Thanks for this one!
I'm starting to think that this would actually be the most correct method to implement! Use the EJB only as the raw bytecode supplier, defining classes on the client (as they are not relevant inside the EJB layer) , possibly caching them locally to enable reuse...
I'll try to put together a prototype over the weekend!
Thanks for the pointers!
It took me a while longer than expected, but I'm glad to report that the suggested solution is implemented and looks OK. I now use the EJB layer as a bytecode supplier and then creating classes using a custom classloader on the web tier. Since I only need to create implementations of a single interface this way, it's a very narrow use case and so far it seems to work just fine.
Thanks again for the hint!