What Versions of AS5 Will EJB3 Plugin Support?

[alrubinger]

The AS Integration move of the deployers will lead Beta4 with the EJB3 Plugin to now fail with the following errors listed below.

Worth fixing, or we push forward and Plugin will only be supported on AS5 CR1 and up?

EJBStage2Deployer -> java.lang.ClassNotFoundException: org.jboss.ejb3.deployers.EJBStage2Deployer

JBossClientParsingDeployer -> java.lang.ClassNotFoundException: org.jboss.ejb3.deployers.JBossClientParsingDeployer

Ejb3ClientDeployer -> java.lang.ClassNotFoundException: org.jboss.ejb3.deployers.Ejb3ClientDeployer

PersistenceUnitParsingDeployer -> java.lang.ClassNotFoundException: org.jboss.ejb3.deployers.PersistenceUnitParsingDeployer

AppClientScanningDeployer -> java.lang.ClassNotFoundException: org.jboss.ejb3.deployers.AppClientScanningDeployer

AppClientParsingDeployer -> java.lang.ClassNotFoundException: org.jboss.ejb3.deployers.AppClientParsingDeployer

Ejb3Deployer -> java.lang.ClassNotFoundException: org.jboss.ejb3.deployers.Ejb3Deployer

S,

[alrubinger]

I should mention that even though the EJB3 Codebase itself acts as a cumulative patch, because AS5 is a moving target there will have to be a separate Plugin Installer targeted at each AS5 Version we want to support.

ie:

* EJB3 Plugin RC13 AS5Beta4
* EJB3 Plugin RC13 AS5CR1
* EJB3 Plugin RC14 AS5Beta4
* EJB3 Plugin RC14 AS5CR1
* EJB3 Plugin RC14 AS5GA

...etc.

Not a pretty solution (exponential releases over time == (EJB3 Version * Supported AS5 Versions)).

S,
ALR

[anil.saldhana]

Why not have a plugin that works all the way from Beta4 to GA? Seriously, all this discussion about ejb3 plugin/installation is making me giddy.

Ok, hit me now with your justification. :)

[adrian.brock]

Why waste time on Beta4? Its gone. Once the GA is out nobody will use Beta4.
Just don't forget that potentially RC1 == GA

[alrubinger]

Why not have a plugin that works all the way from Beta4 to GA?

The EJB3 Plugin has to account for the diffs in what AS *has* and what AS *needs* for an updated EJB3 Installation. So to make a single Plugin that smart enough to match these diffs is an investment of effort==time==money and we need to make sure we can justify those expenses.

Why waste time on Beta4? Its gone. Once the GA is out nobody will use Beta4.

So here Adrian makes an argument that it's not worth it for Beta4. I happen to agree.

However, we still have the standing question creeping up post GA - how will the Plugin releases work? It'd be great to have only one Plugin version per EJB3 release, and let it intelligently patch any AS after a certain cutoff (say, CR1).

This way I can also tie the EJB3 Plugin into one of my Maven Plugins for AS Installation and make upgrades to the user completely transparent.

S,
ALR

[adrian.brock]

"ALRubinger" wrote:

However, we still have the standing question creeping up post GA - how will the Plugin releases work? It'd be great to have only one Plugin version per EJB3 release, and let it intelligently patch any AS after a certain cutoff (say, CR1).

This way I can also tie the EJB3 Plugin into one of my Maven Plugins for AS Installation and make upgrades to the user completely transparent.
ALR

We've been through this discussion many times before. See for example
my recent discussion with Thomas Diesler in the webservices forum.

The short answer to your question (on the errors above),
is that you shouldn't be writing the deployers
in the ejb3 plugin project(s).

Instead the deployers should be in JBossAS and they should delegate to
a stable spi within EJB3

In fact, that spi (the ejb3 integration api) should be in the jboss-integration project
where you can't change it on a whim. :-)

The deployers themselves should be doing little more than
manipulating metadata which then gets registered as a "service" in the Microcontainer.
Those services should then talk to an "EJB3 Service" from the deploy directory.

Again see recent discussion in Tomcat forum about how the Tomcat
deployers were wrong.

[anil.saldhana]

Added to that, IMO the interceptors (including the security interceptors) should not be in the externalized project. They should be sitting in the ejb3 module in the AS workspace. Only the EJB3 core code should exist in this external project. I have sought the same for messaging/ws projects and they have got it right probably to a large extent. See the messaging and webservice integration modules in AS5 workspace.

If you inculcate this, there is no need for any magical plugin that you envision and that has been a barrier to people like me, who have wasted a few man hours.

[alrubinger]

We've been through this discussion many times before.

I haven't, which is why I brought it up here. This *type* of discussion has been had before, in other projects, so thank you for those links. As far as I know, there's no Roadmap defined for what the Plugin will support, and I want that in place.

you shouldn't be writing the deployers
in the ejb3 plugin project(s). Instead the deployers should be in JBossAS and they should delegate to a stable spi within EJB3

I didn't have any intent of placing the deployers (AS integration points) back into the EJB3 codebase. It's because they *used* to be there (which was incorrect and therefore changed last week) that Beta4 is no longer a valid target for the Plugin.

So a multiversion plugin is dependent on a frozen SPI. Until that's written down somewhere, I can't deliver a single Installer to upgrade EJB3 releases across a variety of AS bases.

S,
ALR

[alrubinger]

Added to that, IMO the interceptors (including the security interceptors) should not be in the externalized project. They should be sitting in the ejb3 module in the AS workspace.

So what about EJB3 Standalone and Embedded? They don't need interceptors? This isn't an AS integration point.

Only the EJB3 core code should exist in this external project.

More accurately, only EJB3 Core code should live in the component jboss-ejb3-core. EJB3 has many subcomponents, and we're working to slim down "core" into other modules.

If you inculcate this, there is no need for any magical plugin that you envision and that has been a barrier to people like me, who have wasted a few man hours.

Though good, the Plugin isn't "magical". It's a mechanism to allow EJB3 upgrades without having to upgrade AS. When I was developing EJB3 apps the last thing I wasn't to do was upgrade all of AS to get a feature I needed from a new release of EJB3. Now that the AS default build brings in EJB3 code via thirdparty, you'll no longer need to run it.

S,
ALR

[adrian.brock]

"ALRubinger" wrote:

So a multiversion plugin is dependent on a frozen SPI. Until that's written down somewhere, I can't deliver a single Installer to upgrade EJB3 releases across a variety of AS bases.

Very few projects have defined such a thing.
http://viewvc.jboss.org/cgi-bin/viewvc.cgi/jbossas/projects/integration/trunk/
it will be more important once 5.0.0.GA is out.
If you're project is defined properly, the it should just be a case
of moving the interfaces/annotations/etc. to the integration project
and metadata to the metadata project
http://viewvc.jboss.org/cgi-bin/viewvc.cgi/jbossas/projects/metadata/trunk/
(already done for ejb3).

But of course, if you leave it until later and find a problem its going to bite you. ;-)

[adrian.brock]

"ALRubinger" wrote:

Added to that, IMO the interceptors (including the security interceptors) should not be in the externalized project. They should be sitting in the ejb3 module in the AS workspace.

So what about EJB3 Standalone and Embedded? They don't need interceptors? This isn't an AS integration point.

The security aspect (to give it its correct name ;-) is a product of the security
project. It's an implementation detail.
Only the runtime metadata it uses is "shared" and then only if it needs to be,
e.g. converting ejb3 metadata to jboss-security's internal model.

If you inculcate this, there is no need for any magical plugin that you envision and that has been a barrier to people like me, who have wasted a few man hours.

Though good, the Plugin isn't "magical". It's a mechanism to allow EJB3 upgrades without having to upgrade AS. When I was developing EJB3 apps the last thing I wasn't to do was upgrade all of AS to get a feature I needed from a new release of EJB3. Now that the AS default build brings in EJB3 code via thirdparty, you'll no longer need to run it.

Your plugin should just be the "EJB3 Service" I described earlier.
Just as "Tomcat" is upgraded by dropping new JBoss Web jars
into jbossweb.sar

[alrubinger]

Your plugin should just be the "EJB3 Service" I described earlier. Just as "Tomcat" is upgraded by dropping new JBoss Web jars into jbossweb.sar

I'll look into that approach, thank you. An EJB3 SAR and new JARs in "client" might do the trick.

S,
ALR

[anil.saldhana]

"ALRubinger" wrote:

Added to that, IMO the interceptors (including the security interceptors) should not be in the externalized project. They should be sitting in the ejb3 module in the AS workspace.

So what about EJB3 Standalone and Embedded? They don't need interceptors? This isn't an AS integration point.

The security aspect (to give it its correct name ;-) is a product of the security
project. It's an implementation detail.
Only the runtime metadata it uses is "shared" and then only if it needs to be,
e.g. converting ejb3 metadata to jboss-security's internal model.

The EJB2 security interceptors and Tomcat Security Integration code (tomcat realms) exist in the AS5 workspace in server and tomcat modules. Why should the ejb3 security interceptors exist in an external project?

[alrubinger]

Why should the ejb3 security interceptors exist in an external project?

Because EJB3 should not require the AS runtime.

S,
ALR

[adrian.brock]

"ALRubinger" wrote:

Why should the ejb3 security interceptors exist in an external project?

Because EJB3 should not require the AS runtime.

S,
ALR

So what? If you run in embedded you just drop the security interceptor.
If you run in Tomcat, you replace it with a version that uses Tomcat Realms.

That still doesn't mean that EJB3 should define how security works in JBossAS.

Make a sentence out the foillowing words:
"Before Put Horse Cart" :-)