Plugin is Broken

[alrubinger]

@see https://jira.jboss.org/jira/browse/EJBTHREE-1767

I've separated out jboss-ejb3-proxy into:

* jboss-ejb3-proxy-spi
* jboss-ejb3-proxy-impl

Each project has its own client assembly. However, the Plugin currently can't patch up the jbossall-client.jar to change the references in the manifest, so the TestSuite runs are failing with, for instance:

Testcase: testXml1 took 0.005 sec
 Caused an ERROR
javax.naming.Reference
java.lang.ClassCastException: javax.naming.Reference
 at org.jboss.ejb3.test.ejbthree1060.unit.InvokedBusinessInterfaceUnitTestCase.testXml1(InvokedBusinessInterfaceUnitTestCase.java:76)

This is because the client CP doesn't have the ObjectFactory on it, so we get CCE from the JNDI Reference.

Any hot ideas for patching jbossall-client?

S,
ALR

[alrubinger]

"ALRubinger" wrote:
Any hot ideas for patching jbossall-client?

I've got https://jira.jboss.org/jira/browse/EJBTHREE-1768 to do this for us.

S,
ALR

[alrubinger]

"ALRubinger" wrote:
I've got https://jira.jboss.org/jira/browse/EJBTHREE-1768 to do this for us.

All's copacetic.

S,
ALR

[wolfc]

No, it's not. :-)

Can't build AS 5.x anymore with the latest snapshot:

BUILD FAILED
/home/carlo/work/jboss-5.x/build/build.xml:393: The following error occurred while executing this line:
/home/carlo/work/jboss-5.x/build/build-distr.xml:152: /home/carlo/work/jboss-5.x/build/${jboss.jboss.ejb3.proxy.lib} not found.

I shall create a transition component.

[alrubinger]

We shouldn't be building 5.x w/ a SNAPSHOT, if you want the latest EJB3 stuff w/out using Plugin, we should get together a proper patch for the AS build. Which we need anyway for the next release.

So why the transition component? Where does it say that we always have to be able to build AS against EJB3 SNAPSHOTs?

S,
ALR

[wolfc]

It doesn't say that we need to be able to build AS against snapshots. It says that we need to be backwards compatible all the time. The reason for this is that you can't patch everything (or even anything) in AS, because that's outside of our control.

Let's reiterate the (informal) procedure:
I wanted to make an SPI with persistence unit resolving (Jan 13th) http://viewvc.jboss.org/cgi-bin/viewvc.cgi/jbossas/projects/ejb3/trunk/core/src/main/java/org/jboss/injection/InjectionContainer.java?r1=75613&r2=75612&pathrev=75613 which involved AS, EJB3 and JPA.

Step one: deprecate InjectionContainer.getPersistenceUnitDeployment and add ExtendedInjectionContainer (the true SPI)
Step two: release the SPI
Step three: change all components to match
Step four: release all
Then step five: remove said method
Especially step four is tricky, because we don't control most bits.
I should add step seven: clean up the residual mess

Now the true problem, as you already spotted, is that ejb3 module has a bean definition which relies on proxy internals.

I pointed at with EAR code needing a patch (or MC) as another example, I just hadn't expected the problem to appear from this angle.

Now the passing of the TCK tests again proves the need for this transition component, because no TCK means no release and that would have deadlocked the situation.

So work on the assumption that you'll not get a patch in AS.