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 <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