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
