Ok this is now in trunk.
Galder, I don't know if you want to do further tests?
As part of this, I introduced an
Currently this only provides an instance of EJB2's
UserTransaction this is to avoid hardwiring within
the CCM of what UTs exist.
But in future, this would be a better place
to put an "EJB2 service/config bean" with direct
injection of EJB2 dependencies.
Currently a lot of this is configured on the
EJB2xDeployer such that each ejb gets multiple
dependencies and each has to resolve them repeatedly.
Instead, it would be better to just have a single
reference/dependency to the config bean
that gets things directly injected once.
It also gives you a single place to say
something like "stop all ejbs" by stopping that service.
On Wed, 2008-11-05 at 00:09 +0100, Galder Zamarreno wrote:
Fix tidied up. I tested a snapshot of jboss-integration with AS trunk
and previously introduced regressions are not there any more.
Adrian Brock wrote:
> I've committed my stuff so it just needs to tidyup your fix
> before we do a release of the integration project.
> On Mon, 2008-11-03 at 13:19 +0100, Adrian Brock wrote:
>> On Fri, 2008-10-31 at 16:43 +0100, Galder Zamarreno wrote:
>>> I've just realised that I needed to add something else to
>>> ServerVMClientUserTransaction in jboss-integration to fix this
>>> inefficiency (https://jira.jboss.org/jira/browse/JBAS-5908
) compared to
>>> the solution for EAP.
>>> jboss-integration 5.0.0.GA has been tagged already but I have no problem
>>> in fixing JBAS-5908 for 5.0.1, so can I commit the remaining code in
>>> that I don't need to remove anything from the existing (partial) fix, so
>>> no need to retag jboss-integration right now.
>> Argh! I said not to release it since I might have to do some
>> changes for EJB3 to use UserTransactions correctly.
>> Although I thought I could get away with not making changes
>> in fact I have to. EJB3 can't use some of the necessary api that
>> is in the appserver.
JBoss, a division of Red Hat