hi harald, some wildfly developers said that it doesn't work correctly/completely (and there isn't a lot we can do), but they are interested in this topic. -> you could try to push it once again (e.g. via a ticket in their jira).
regards, gerhard 2015-08-23 21:07 GMT+02:00 Harald Wellmann <[email protected]>: > Hi John, > > this is my jboss-deployment-structure.xml. > > <jboss-deployment-structure xmlns="urn:jboss:deployment-structure:1.2"> > > <deployment> > <dependencies> > <module name="org.apache.deltaspike.core.api" > services="import" /> > <module name="org.apache.deltaspike.core.impl" > services="import" /> > <module name="org.apache.deltaspike.jpa.impl" > services="import" /> > <module name="org.apache.deltaspike.data.impl" > services="import"/> > </dependencies> > </deployment> > > </jboss-deployment-structure> > > I also tried meta-inf="import", but that didn't solve the problem. So it > looks like having separate modules does make a difference. > > Turning on Weld DEBUG logging didn't give much insight either. The > @Specializes bean is listed, so it's really a mystery to me why it isn't > visible to my deployment. > > Regards, > Harald > > > > > Am 23.08.2015 um 19:40 schrieb John D. Ament: > >> 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 <[email protected]> >> 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 >>> >>> >> >
