Hi Harald! Can you share your full jboss-deployment-structure.xml (or MANIFEST.MF)? I think you're missing meta-inf="import" but not sure.
I'm currently deployed the same way as you described and don't see this issue (though I doubt having distinct modules per JAR is a big difference here). John On Sun, Aug 23, 2015 at 11:59 AM Harald Wellmann <hwellmann...@gmail.com> wrote: > I'm currently experimenting with DeltaSpike installed as a WildFly > add-on, i.e. as a bunch of extra modules in > $WILDFLY_HOME/modules/system/add-ons/deltaspike. > > I'm using DS 1.5.1-SNAPSHOT and WildFly 8.2.0, and I've created one > module per DS JAR, deliberately not using the structure currently found > in org.apache.deltaspike.distribution:distribution-full which is not > really modular. > > There seems to be an issue with the visibility of specialized beans: > > The JPA Impl module has a DefaultEntityManagerHolder which is > specialized by ThreadLocalEntityManagerHolder in the Data Impl module. > > My deployment declares dependencies on all DS modules with > services="import". But even so, the ActiveEntityManagerHolder injection > point in ResourceLocalTransactionStrategy cannot be resolved. > > The only(?) way to make things work is to create MyEntityManagerHolder > in my deployment which extends and specializes > ThreadLocalEntityManagerHolder. > > Questions: > > 1) Is this the expected behaviour for specialized beans, or is there a > bug in Weld or in WildFly? > > 2) Should we really use @Specialized beans in this way? I would consider > anything in an Impl module as private, applications should not have to > depend on an Impl to override beans that are intended to be overridden. > Wouldn't @Alternative be more suitable? > > Regards, > Harald >