JBossDeveloper

Clebert Suconic wrote:

 

Andy Taylor wrote:

 

I think Tims point is that if we ran in an app server that didnt plugin its transaction manager then the test would not pass making us non portable.

 

So we can either leave cleberts changes in until we have given the eap guys a release or remove them now and the eap guys can wait a while, i'm not sure how long these changes will take having not done them, clebert, Jeff, is this a quick job?

 

 

You can just *plug in* the TM used on GlassFish, and the test will pass the same way.

 

I don't think there's an issue here.

 

There are no JBoss specific hacks here.

LOL, that is ludicrous.

If that's was true that "plugin" would have to be part  of the JCA spec.

In order to implement a JCA adaptor and pass the TCK the knowledge in the JCA spec should be sufficient. What you are saying, is you also need an extra piece of knowledge (this plugin).

Another illustration - It should be possible to pass the TCK with JBoss AS using ActiveMQ and the ActiveMQ adaptor. Clearly they won't have your hack in their adaptor.

Is this getting any clearer now?

We've discussed this too much now. Let's roll back to how this was done before. I don't mind who does it, but that's what we need to do.

Clebert Suconic wrote:

 

Let me clear wo points:

 

I - If you remove the TM integration. The TCK will pass either way.

    TransactionActiveUnitTestCase would fail though.

 

II - To fix TransactionActiveUnitTestCase you would need access t othe TM (which is optional)

     And if done properly with GlassFish or any application server, TransactionActiveUnitTestCase would work the same way.

If TransactionActiveUnitTestCase requires special APIs that are not part of the JCA/JEE spec in order to pass then it's invalid. All the EJB / MDB tests should be able to pass with any compliant JMS provider that provides a valid JCA adaptor. No other APIs should be necessary to make it pass.

Clebert Suconic wrote:

 

There are only two ways to fixTransactionActiveUnitTestCase:

 

 

I - Change the TM to send us end(FAIL) before the rollback, when the rollback ocurred. We have no way to know there was a problem otherwise.

 

 

II - Verify if there's a TX activate on the TM, and use XASession on that case. (which is currently in place now)

You forgot:

III - roll back to the old way we used to do it before we did the caching of multiple sessions. The test used to work then.

In the time taken to discuss this, you could probably have already rolled back the code.

Clebert Suconic wrote:

 

Tim Fox wrote:

 

Clebert Suconic wrote:

 

There are only two ways to fixTransactionActiveUnitTestCase:

 

 

I - Change the TM to send us end(FAIL) before the rollback, when the rollback ocurred. We have no way to know there was a problem otherwise.

 

 

II - Verify if there's a TX activate on the TM, and use XASession on that case. (which is currently in place now)

You forgot:

 

III - roll back to the old way we used to do it before we did the caching of multiple sessions. The test used to work then.

 

In the time taken to discuss this, you could probably have already rolled back the code.

 

 

No, the test didn't pass. That test will fail if we rollback all this. We will be back at point 0.

What do you mean the test didn't pass?

We had all tests passing for the AS6 integration. At least that's what you should have done. Are you now saying that the AS6 integration was completed without getting the AS test suite to pass?

If so, it's not finished.

Are we going around in circles here?

You have just admitted that the test used to pass when the AS6 integration was complete. No tx mgr hack was necessary to make that test pass then. Therefore your hack is unnecessary.

So, we roll back to that time.

OK?

ok, to sum up: at no point we had both the TransactionActiveUnitTestCase and the TCK pass.

there is no time to rollback to have both correct, right?

We could rollback to "fix" TransactionActiveUnitTestCase but this will break the TCK.

However the current code pass both tests at the price of injecting the JTA TM into our RA (like JBoss generic RA is doing).

is that correct?