status on modularization of test mixins

[kcbabo]

I have this pretty close now, but running into some issues with the optional/required dependencies between a few MixIns.  Before I get to that, my changes can be found here:

https://github.com/kcbabo/parent/tree/SWITCHYARD-1184

https://github.com/kcbabo/core/tree/SWITCHYARD-1184

https://github.com/kcbabo/components/tree/SWITCHYARD-1184

Everythign builds except for the JCA gateway in components.  One change that may be impacting this is CDIMixIn no longer has an optional dependency on TransactionMixIn.  This actually produces a circular dependency between the two modules as the Transaction MixIn depennds on an interface in CDIMixIn as well.  The same issue exists between JCA and Transaction MixIns, but I've left those together for the moment.

I get loads of these in the JCA gateway tests:

com.github.fungal.spi.deployers.DeployException: Deployment jar:file:/Users/kbabo/.m2/repository/org/jboss/ironjacamar/ironjacamar-embedded/1.0.9.Final/ironjacamar-embedded-1.0.9.Final.jar!/naming.xml failed

Caused by: com.github.fungal.spi.deployers.DeployException: Installing bean NamingBeanImpl

Caused by: java.lang.ClassNotFoundException: org.jnp.server.NamingBeanImpl

Thoughts?

[igarashitm]

Hi Keith,

test/mixins/naming/src/main/resources/naming.xml

should be moved to

test/mixins/jca/src/main/resources/naming.xml

This file is used by IronJacamar embedded (fungal deployment def)

Thanks,

Tomo

[kcbabo]

Thanks Tomo!

[kcbabo]

I'm now hitting this:

testUnmanagedOutboundJMS(org.switchyard.component.jca.deploy.JCAJMSReferenceBindingTest)  Time elapsed: 0 sec  <<< FAILURE!
junit.framework.AssertionFailedError: Failed to start IronJacamar Embedded: Deployment jar:file:/Users/kbabo/.m2/repository/org/jboss/ironjacamar/ironjacamar-embedded/1.0.9.Final/ironjacamar-embedded-1.0.9.Final.jar!/stdio.xml failed

BTW, I pushed a new rev of my components code, so you will want to re-pull to see the above error.

[mageshbk]

Hi Keith, What is the logical conclusion for the FAILURE above? I am hitting the same issue on a different note.

[kcbabo]

I don't remember what the resolution to the above was, but it definitely was fixed.  It might have been dependency related, but I can't say for sure.  Where are you hitting this now?  If you have some code which Tomo can pull to reproduce then he can probably sort it out.

[mageshbk]

According to Tomo, the issue can appear when one of the primordial JCA test failed for some other reason! All subsequent tests would fail with this message. Now, although we need to find a way to get that fixed, right now manual digging is necessary to find the first test that failed.

[igarashitm]

Yep, it hides the root cause, so kind of annoying... but if we elliminate the IronJacamar embedded itself from the JCAMixIn then it should go away together. We need to do that at some point because the embedded one is not supported officially. Arquillian integration may be the successor. Can we have a plan to have this surgery before 1.0?

[kcbabo]

If we go with Arquillian instead, woiuld the JCAMixIn go away entirely?  I'm OK with using Arquillian for in-container testing relative to JCA.  Lukasz had mentioned at one point he was going to look at moving our test kit to an embedded container in Arquillian, which would smooth things out from a user perspective.  We do a lot of custom lifecycle and injection stuff in our test kit though, so we need to make sure the same hooks are available via Arquillian.

[mageshbk]

I totally agree! Tomo, my intention is to move the build towards AS 7.2 and I see these failures. If you have time and look at it real quick, it would help, else, we need your guidance.

cheers,

.Magesh

[igarashitm]

JCAMixIn should be a thin utility to help deploying thirdparty resource adapter or create&deploy the mock resource adapter, once we succeed to integrate with arquillian-as7.

I just noticed there is embedded version of arquillian as7 plugin. We may want to create SwitchYard plugin on top of it though. That's worh investigating.