Patching app server versus scoping messaging

[timfox]

As already mentioned in other threads, JBM needs to be deployed scoped in JBoss AS 4.x.

This proves to be a big headache for many of our users and is providing a big barrier to adoption IMHO.

A different approach would be to patch the AS during the JBM installation procedure.

I.e. we could overwrite the JBoss Remoting and JBoss AOP jars in server/lib with the later ones that we know to work.

This would prevent us having to scope messaging.

I exchanged some emails with Bill offline about this, and this is apparently what EJB3 does for 4.0.3.SP1 (see http://docs.jboss.org/ejb3/app-server/tutorial/installing.html), so I guess there is nothing in principle wrong with this approach.

For AS 4.2.1 and later we would make sure we align dependencies properly so no scoping or patching would be necessary.

Comments?

[mskonda]

I am not sure whether I should butt in, but oops, I already did!

Just want to let you know that we have ditched scoping logn ago by patching remoting AND aop libraries on the appserver.

We have been successfully running our servers since then and we have not encountered any issues.

I agree with Tim, it's quite a big headache scoping JBM.

I vote for 'get rid of scoping - go for patching' :)

[ovidiu.feodorov]

I know big shops that already did this and everything works fine.

However, EJB3 needs patching for this, Carlos already has the patch.

WebServices are a problem, though, your configuration won't support the latest ws releases, unless patched.

My suggestion would be to change release-admin.xml (or the graphic installer, if there is one) to offer the choice of going scoped (solid, but PITA), or unscoped (hacky, but easy to use and actually solid as well)

[timfox]

Hi Ovidiu-

Ok so we would have to do:

Overwrite jboss-remoting.jar in server/lib with the latest one

Overwrite the ejb3 jars in server/lib with the ones patched already Carlos (I wonder if the patch is in a GA of EJB3 yet?)

Overwrite jboss-aop.jar with the latest one.

You say web services will be a problem - do you have any more details? Would we need to patch web services, or patch remoting?

Cheers

[ovidiu.feodorov]

* Overwrite jboss-remoting.jar with whatever comes with our release
* Modify our jboss-service.xml to make it unscoped
* Replace significant ejb3 jars. Carlos has a patch procedure, and so Robb Greathouse, who applied it. I'll ping both of them, so they can comment on the thread. This part is a little hazy at this moment, we need to address it carefully. Overwriting aop dependencies is part of this procedure, as far as I remember, but messaging works fine with
* Web Services won't work, afaik, so we need to coordinate with them. I don't know specifics, I just deleted their artifact from the deployment directory.
* We need to modify our smoke test procedure to check this new configuration.

If you can wait until the end of the week, I can give it a try (create a JIRA issue and assign it to me, so I can manage this easily)

[timfox]

My suggestion would be to change release-admin.xml (or the graphic installer, if there is one) to offer the choice of going scoped (solid, but PITA), or unscoped (hacky, but easy to use and actually solid as well)

I suppose if we can make sure that everything (web services etc) works ok using the patching method, then this is just as "solid" as deploying scoped.

In which case I would prefer dropping scoping altogether - one less piece of complexity to maintain/support.

[ovidiu.feodorov]

"timfox" wrote:

In which case I would prefer dropping scoping altogether - one less piece of complexity to maintain/support.

Come on, scoping has so many elegant theoretical implications! :) Why getting rid of it? :)

Of course, I agree with you.

[clebert.suconic]

The release process at jboss/build.xml will repack those jars as jbossall-client.jar.

Whatever mechanism we choose to patch those jars will also require rebuild jbossall-client.jar.

[clebert.suconic]

I mean...

This worked in some places as those customers were probably avoiding that client jar. But if we choose to aways do that, this will probably require an extra step. But this would have implications.. as if a customer crossing jars (like talking to simultaneous application servers at the same time) will have compatibility problems. I don't know how to solve this equation though.

[heiko.braun]

The WS remoting dependency is well isolated. Plus we do currently support the following versions from a single code base:

# JBossAS-5.0
jboss-remoting-jboss50=2.2.0.GA

# JBossAS-4.2
jboss-remoting-jboss42=2.0.0.GA

# JBossAS-4.0
jboss-remoting-jboss40=1.4.3.GA

From what i can tell at the moment, you should be able to drop 2.2.0.GA into 4.x without causing JBossWS to break. What exact version are you looking at?

[timfox]

We would be looking at dropping the latest version of remoting into AS 4.0.x.

I just remember Thomas and Ovidiu having a discussion some time back about how this breaks stuff.

[heiko.braun]

With regard to JBossWS it shouldn't. As i said, the same WS code run with 2.2.0.GA and 1.4.3.

[timfox]

Thanks.

One less thing to worry about then :)