classes from jars located at ear/lib folder are visible to ejbs and wars by default you don't need to provide additional configuration
in your case you need to ensure that deltaspike modules at ear/lib folder have (at least empty) META-INF/beans.xml descriptor available and appropriate (ejbjar | war) archive has (META | WEB)-INF/beans.xml with desired alternative defined:
that can be. For my case, the artifact deltaspike-jpa-module-impl.jar (version 0.4) has a beans.xml which is shown below:
So the Interceptor is activated here. If I hack the alternative in this beans.xml then everything works fine. But I can't controll this from outside of the jar. Should I assume as a bug in deltaspike?
maybe I finally see the problem
if TransactionInterceptor is used inside deltaspike library and you need to change its injected field from the default to an anternative implementation then you should configure desired alternative inside deltaspike's beans.xml
in beans.xml application deployer may activate interceptors/alternatives so I don't thing it's a bug in deltaspike
yes you're right. I have tried this aproach before I start this thread. But I mean that's a hack if I must mdidify the beans.xml from a third party dependecy. Isn't that so ?
that's not a hack
you do the same for instance as an application deployer in case of ejbs when you are supposed to modify ejb referencies in ejb-jar.xml to fit at target environment
And how should I integrate this in my automated deployment structure? Has maven a plugin which can modify beans.xml of a dependency automatically ?
no idea I don't use maven as build tool
I can live with ant too. I can trigger it from maven :-)
I fell in love with gradle
these maven headaches can be easily solved by groovy scripts