MixIn dependency management

[igarashitm]

On my way to rebase my JCAMixIn onto new NamingMixIn, I have noticed the NamingMixIn#(un)initialize() would be invoked twice when using HornetQMixIn and JCAMixIn together(both of them extends NamingMixIn). As Keith suggested to me on IRC, it's time to bring some kind of dependency management into MixIns, instead of inheritance.

One idea came to my mind is, injecting MixIn into MixIn. TestKit instantiates the MixIn instance only once, and inject them by the @DependOnMixIns annotation(or reuse SwitchYardTestCaseConfig?). TestKit should also take care of initalize/uninitialize invoking sequence - MixIns which is dependency of other MixIns sould be initialized first, and uninitialized last. In this way, application programmer don't have to know that HornetQMixIn depends on NamingMixIn, but still can specify NamingMixIn in the test case as well.

One another thing I'm just thinking is the conditional dependency - for example, JCAMixIn doesn't always need HornetQMixIn, but when we use them together, HornetQMixIn should be initialized first, and uninitialized last. SwitchYardTestKit always initializes the mixins in order of the list specified in @SwitchYardTestCaseConfig annotation, and uninitializes in reverse order of it, so if we put the HornetQMixIn before JCAMixIn then it works fine though. Explicit dependency would be better to avoid user confusion.

What do you think guys? Any advice would be appreciated!

Thanks,

Tomo

[kcbabo]

Hey Tomo - these are good ideas.  One thing I should have mentioned the other day is that we should shoot for the most straightforward solution for 0.5.0.Final and the most elegant solution for 0.6.0.  :-)  My concern with a major change here is that we are going to break the test stuff between Beta and Final.  One possible solution in the short term is to simply use static fields in NamingMixIn along with a flag which indicates whether it's been initialized or not.  Set/check this in a thread-safe way and use it to guard against repeated initializations and unitializations.  This has a side effect of sharing the naming context across tests, so it's not ideal.  The only other 'easy' option is to simply back out the change that introduced the inheritance - which may be the way to go.

@Lukasz - I'll be out tomorrow, but if you can chime in with your thoughts, that would be great.

[igarashitm]

got you - here is the long term fix like I mentioned above

https://github.com/igarashitm/core/tree/SWITCHYARD-906

https://github.com/igarashitm/quickstarts/tree/SWITCHYARD-906

and I will push the short term fix onto my JCA outbound pull requests.