0

The client I work for has about 150 web apps that run on WebSphere, which has been a mashup of various Java patterns, frameworks, etc. (Spring, JSF, GWT, WebServices, RESTful, etc.) It is to the point where something must be done to reduce the jar versions and duplicity of features in order to improve our environment and development life-cycle.

For example, we need WebApp_A to utilize CompanyJar_v1.1.jar and we need WebApp_B to use CompanyJar_v1.5.jar.

I know that OSGi is an option, but I have heard there may be some issues with Spring and OSGi, and our apps rely heavily on Spring. This may or may not be an issue. The other concern is the amount of effort to upgrade our apps to utilize OSGi. We understand whatever the approach, time and effort will be needed to update our apps, but we want to keep this to a minimum. However, if the best long-term solution requires more effort to update the apps, then so be it.

We could also utilize WebSphere's Shared Libraries capabilities, but we do not like to use WebSphere specific solutions. This would also be very cumbersome to manage from a server standpoint since we have so many versioned jars that would need to be managed.

Has anyone had any experience with moving their convoluted environment to a more modular environment? If so, what questions should the team be asking ourselves? What technologies should we consider?

Thanks, Sean

Sean Charles
  • 267
  • 3
  • 18
  • 3
    But what do you expect from OSGI -- if a new version of jar is released all downstream webapp automatically pick it up and redeploys? In my opinion an internal maven repository plus standardised versioning & release strategy is more helpful. Not all downstream always want the latest version of a jar – gerrytan Apr 10 '13 at 02:28
  • I am not sure I understand your point. If we were to use OSGi, then each app would need to declare which version of jar it needs, so if an OSGi bundle (with the new jar) is updated, there is no conflict in the apps because they declare which ones they need. Also, we have no jar repository strategy. Maven would be preferred, but that would require a great deal of effort to update the project structures. The easier approach would probably be to utilize Ivy since our projects could more easily adopt Ant (they are currently built using RAD, which is a horrible product). – Sean Charles Apr 10 '13 at 12:43
  • It almost sounds like you're not looking for OSGI, but rather for a new dependency management solution. It's true that in OSGI you declare a bundles dependencies, however, you'd end up with the same problem you have right now. OSGI doesn't magically fix dependency problems; it offers versioned and well defined class loading to your apps. If you're having trouble with managing project dependencies, look into Maven and a company wide artifact repository. – ilikeorangutans Apr 10 '13 at 17:41
  • 1
    I'm also not clear what you're asking for. You said that you want webapp A to use jar v1.1 and webapp B to use java v.1.5... well that's already possible with WAR files, by embedding the relevant versions of the library under WEB-INF/lib. So, what exactly are you trying to achieve? Smaller WARs? I know a lot about OSGi (it works well with Spring BTW) but I couldn't recommend it without understanding what problem you're trying to solve. – Neil Bartlett Apr 10 '13 at 19:40

0 Answers0