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
>

Reply via email to