There's no integration module for OpenWebBeans. This is also the first time we heard someone try using Errai and OpenWebBeans. If you're willing and have the time to investigate this further it would be great!
we have the same Issue on IBM WebSphere 8.5 which also uses OpenWebBeans as its CDI Implementation.
Currently this is one of our biggest limitations using Errai.
We introduced a workaround by using the fallback guice container and lookup CDI and EJB beans via JNDI within the @Service guice beans but this is rather awkward.
In later applications we also tried to just stick with the JAX-RS client.
cbrock already mentioned that most of the issues might be resolved with the updated SPI in CDI 1.1.
Since then the Java EE 7 and CDI 1.1 specs became final.
Can you guys already give an estimation if our pain will go away after OpenWebBeans will properly implement CDI 1.1 and WebSphere 9 hopefully will bring Java EE 7 anytime soon?
And if not, would you offer to finally adapt the CDI-Integration module to support all standard CDI-1.1 containers (not just Weld)?
We really need to know if it's worth waiting for things to get better with Errai under non-Weld application servers or if we should look for alternatives instead.
In the latest 3.0-SNAPSHOTs (from errai/master), there's only one direct reference to Weld left. Everything else is using standardized APIs. This one reference deals with the dynamic registration of observer methods on the client which forces us to clear the server-side observer cache. (see https://github.com/errai/errai/blob/master/errai-cdi/weld-integration/src/main/java/org/jboss/errai/cdi/server/events/Ev…). This was really just an optimization to avoid unnecessary subscriptions in case beans have not yet been created on the client. There are alternative (better) approaches we can take here and we definitely aim to do this in Errai 3.
So, going forward, this should not be a blocking issue for deployments using OpenWebBeans. What other issues do you encounter with Errai 3?
<We really need to know if it's worth waiting for things to get better with Errai under non-Weld application servers or if we should look for alternatives instead.>
No, waiting is not a good idea. Help us make it happen ! Our bandwidth is limited and we do our best to keep up with all requests. As Mike pointed out, contributions are always welcome!
I have deployed new 3.0-SNAPSHOTs now with the last direct reference to Weld removed (see comment above). Although the jar is still called errai-weld-integration (at least for now) it no longer relies on any weld internals to work. It only uses standardized APIs.
Please try the latest version and let us know if you still experience issues with OpenWebBeans. The easiest way to try is to use our tutorial project and update the Errai version to 3.0-SNAPSHOT:
this is actually working for our own demo application. I can now simply skip the delegation via JNDI and just use everything the way it was meant to be used.
Might not sound like much but this is completely awesome stuff! Thank you very much!
With the Errai tutorial application I still have a very strange OpenJPA issue under WebSphere. It complains that for automatic id generation there shouldn't be an id or a version set for a detached object.
I debugged into the SessionBean and both values where actually null so I guess it's some WebSphere specific thing. Since we are currently not making use of the client-side EntityManager, I gave up on that for now since our own demo app seems to work fine.
There were also some issues with Reflections under WebSphere Liberty Profile V8.5.5 (I remember having the same issue with Enterprise OSGI .eba and .wba applications using Errai under WebSphere V8.5) because Reflections isn't currently able to handle the wsjar:/ protocol.
The problem is that IBM doesn't explode the enterprise archives in all cases by default so you can end up with URLs like "wsjar:/pathToApp/yourApp.ear!/yourApp.war!/WEB-INF/lib/yourLib.jar!/com.yourcompany" in your scanning path which doesn't seem to be handled currently.
I ended up writing my own rather naive handler similar to errai-jboss-as-support that manually unzips the archive into temporary files. Would you be interested in adding something like this to an official module?
Great news! Yes, can you send us a pull request with your handler? We'll definitely merge that.
If your handler depends on some websphere specific classes we need to create a separate module (errai-websphere-support). If it doesn't we can just put it into errai-common.