When you add the org.jboss.jts dependency are you setting the 'services' flag to true?

Weld relies on its environment to pass in information about portable extensions, which is where that DUP comes in. As you can see it just loads it from the current classloader, with some extra code to make sure that nothing is duplicated, as the same PE will often be available to every sub-deployment.

Stuart

Paul Robinson wrote:

Stuart,

Let me check if I understand you correctly...

I have a module "org.jboss.jts" that applications using my portable
extension depend upon.

I've put the PE file in the module jar. See here:

unzip -l
modules/system/layers/base/org/jboss/jts/main/narayana-jts-jacorb-5.0.0.M3-SNAPSHOT.jar
| grep META-INF | grep -v maven
0 05-24-13 15:01 META-INF/
656 05-24-13 15:01 META-INF/MANIFEST.MF
49 05-24-13 15:24 META-INF/services/javax.enterprise.inject.spi.Extension
0 05-24-13 16:02 META-INF/beans.xml

The contents of META-INF/services/javax.enterprise.inject.spi.Extension,
contains just "com.arjuna.ats.jta.cdi.TransactionScopedExtension".

I've put breakpoints on the methods in
"com.arjuna.ats.jta.cdi.TransactionScopedExtension" and they are never
invoked.

I also wonder why we still need CDIExtensionProcessors like this:
https://github.com/wildfly/wildfly/pull/4535/files#diff-7, if "you
should just need to add the module with the META-INF/services entry as a
dependency".

Are you able to correct my understanding?

Much appreciated,

Paul.


On 22 May 2013, at 12:34, Stuart Douglas <sdouglas@redhat.com
<mailto:sdouglas@redhat.com>> wrote:

No, you should just need to add the module with the META-INF/services
entry as a dependency. If it is a Weld deployment then it will pick it up.

Stuart

Paul Robinson wrote:

Stuart,

That's great, thanks a lot. I'll keep an eye on the PR.

Also, won't I still need to use the WeldDeploymentMarker?

Paul.

On 22 May 2013, at 01:38, Stuart Douglas <stuart.w.douglas@gmail.com
<mailto:stuart.w.douglas@gmail.com>
<mailto:stuart.w.douglas@gmail.com>> wrote:

I have been meaning to change the way these are registered for some
time:

https://github.com/wildfly/wildfly/pull/4535

Now it should just be a matter of adding a dependency with a services
import on the relevant module.

Stuart

Paul Robinson wrote:

Stuart,

The problem with this approach is that I need to introduce a dependency
on org.jboss.as:jboss-as-weld, which depends on
org.jboss.as:jboss-as-transactions. This introduces a cyclic
dependency.
org.jboss.as:jboss-as-weld is needed for the WeldDeploymentMarker
and to
use WeldAttachments.PORTABLE_EXTENSIONS.

You can do this for every deployment, if beans.xml is not present it
won't do anything

I assume this is done by the three tests at the top of the deploy
method? Therefore, I would need to use WeldDeploymentMarker.

you basically just need to attach it under
org.jboss.as.weld.deployment.WeldAttachments#PORTABLE_EXTENSIONS for
the top level deployment.

Again, I can't do this without access to
WeldAttachments.PORTABLE_EXTENSIONS.

To break this cycle, I think I would need to create a new maven module
and subsytem called, for example, transactions-cdi. This seems a bit
over-kill. Is there an alternative you can think of?

Thanks,

Paul.


On 14 May 2013, at 10:15, Stuart Douglas <sdouglas@redhat.com
<mailto:sdouglas@redhat.com>> wrote:

Registering it in a DUP in the transactions subsystem is fine.

Have a look in
org.jboss.as.weld.deployment.processors.WeldPortableExtensionProcessor#loadAttachments
for an example of what you need to do, you basically just need to
attach it under
org.jboss.as.weld.deployment.WeldAttachments#PORTABLE_EXTENSIONS for
the top level deployment.

You can do this for every deployment, if beans.xml is not present it
won't do anything.

Stuart

Paul Robinson wrote:

Stuart (wildfly-dev in CC too)

I'm implementing JTA 1.2, and part of it is to develop a new CDI
context. I'm currently registering that via an Extension in the
javax.enterprise.inject.spi.Extension file. The problem with this is
that this is a burden on the application developer. Alternatively, I
could register it in a DUP in the transactions subsytem. I'd probably
have to register it for every deployment, as I don't think I can
detect
if it's needed.

@pmuir said that you would probably know what I should do.

Thanks,

Paul.
--
Paul Robinson
Web Service Transactions Lead
paul.robinson@redhat.com <mailto:paul.robinson@redhat.com>
<mailto:paul.robinson@redhat.com>

JBoss, a Division of Red Hat
Registered in England and Wales under Company Registration No.
03798903
Directors: Michael Cunningham (USA), Brendan Lane (Ireland), Matt
Parson
(USA), Charlie Peters (USA)

--
Paul Robinson
Web Service Transactions Lead
paul.robinson@redhat.com <mailto:paul.robinson@redhat.com>

JBoss, a Division of Red Hat
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham (USA), Brendan Lane (Ireland), Matt
Parson
(USA), Charlie Peters (USA)

_______________________________________________
wildfly-dev mailing list
wildfly-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev

--
Paul Robinson
Web Service Transactions Lead
paul.robinson@redhat.com <mailto:paul.robinson@redhat.com>
<mailto:paul.robinson@redhat.com>

JBoss, a Division of Red Hat
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham (USA), Brendan Lane (Ireland), Matt Parson
(USA), Charlie Peters (USA)

--
Paul Robinson
Web Service Transactions Lead
paul.robinson@redhat.com <mailto:paul.robinson@redhat.com>

JBoss, a Division of Red Hat
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham (USA), Brendan Lane (Ireland), Matt Parson
(USA), Charlie Peters (USA)