ClassLoader and design philosophy questions

[RandomCoder]

We are building a new Spring supported application, and our product team is having a little debate about how to implement a certain aspect of our design, and I wondered if anybody here could offer any advice, insight, or anecdotes.

The project is basically a hub with multiple interconnected components. The hub is deployed as a WAR, with each component added (at runtime or during install) as a JAR loaded in its own ClassLoader. These JARs will not all be written by us.

Plan A:
All the common functions of the components are abstracted out and built in the WAR, leaving only component specific code in the component JARs. Cleaner code IMHO, but upgrades require a new WAR deployment.

Plan B:
Some or all of the common functions of the components are reimplemented in every JAR. Fugly code IMHO, but allows some functional upgrades without downing the entire application.

So two questions:
1. Which Plan would you choose, and why?
2. Any gotchas when using custom ClassLoaders under Spring?

Thanks in advance

[manifoldronin]

I would go with A. The service interruption issue, if it's so critical, can be remedied by employing a fail-over architecture, e.g., a load balancer that allows some of the servers to go down for maintenance. On the other hand, the hassle of having to maintain multiple implementations of the same functionality is not going to be so easy to deal with.

[Rod Johnson]

1. B does not sound at all attractive.

2. Custom class loaders are very powerful but are prone to subtle problems. However, I don't think using Spring is going to make those problems worse.

[Vikas Kumar]

1 - A sounds reasonable.
2 – It would help if you can mention the App server for this application. Class loader might behave different for each App server(WAS,Web Logic etc...)

[gmatthews]

The 'interconnected components' sound like they're non-visual, e.g. business logic?

I'd at least put Option C on your shortlist which is to use JBoss and (hot) deploy additional modules as JMX components.

Then you can avoid faffing about with classloaders.

If you didn't use JBoss you could probably still use MX4J + Tomcat to get roughly the same effect.

It would help however if you could shed a little more light on the project.

[Bosmon]

As a compromise, you may wish to structure the WAR so that it contains only interfaces and non-stateful definitions from the components, and acts as a broker between the implementations in the JARs. This would in theory allow you to redeploy the JARs individually, assuming a non-API change. You mention not writing the JARs yourselves, but perhaps you could either impose a model whereby they provide separately packaged interface + implementation, or retrofit implementation after the fact.

Yes, more details would help :P