4

On my WebSphere 8 app server the default class loading order is parent_first (attempt loading from the app server class loader, only then from the EAR class loader).
This generates a collision between my app's usage of Apache's HttpClient and WebSphere's internal usage.
I'm considering switching the loading order to parent_last (prefer-web-inf-classes in WebLogic).

What pitfalls to watch out for when flipping a Java EE app class loading order to parent_last?

Arjan Tijms
  • 37,782
  • 12
  • 108
  • 140
Gili Nachum
  • 5,288
  • 4
  • 31
  • 33

2 Answers2

2

There should be none.

The PARENT_LAST allows your application to distribute with classes and jars that would otherwise clash with WebSphere's. The setting is used whenever ClassClassException occurs when two different incompatible classloaders load a class that's in WebSphere AS and your application.

The classloader modes - PARENT_FIRST and PARENT_LAST - are described in Class loaders in the WebSphere Application Server 8.0 Information Center.

People tend to bundle jars within applications that makes the deployment longer, the memory consumption higher and (library) administration harder.

It's obviously easier for developers to keep everything within an application so they don't have to describe what administrator has to set up as far as shared libraries are concerned (or OSGi repositories).

I can't think of a case where PARENT_LAST is of help unless we assume distributing jars within an application is a good thing (I'd argue with the point).

The less jars is within an application, the better:

  1. application could benefit from upgrading its jars when an issue's fixed via shared libraries or OSGi repositories which would ease its maintenance
  2. applications could share libraries which lower memory expectations and promotes reusability (obviously deployment gets quicker)

There are likely more reasons to not bundle jars within an application that would further diminish the PARENT_LAST configuration setting.

Stick with PARENT_FIRST until they tell you they've got a reason to switch, and when it happens you show them the answer ;-)

Jacek Laskowski
  • 72,696
  • 27
  • 242
  • 420
  • 1
    Thanks Jacek, though I must disagree. IMO the heap space required for class loading is of no importance when your heap is measured in GBs. And that recent history has thought us that you better package exactly what you need, otherwise you'll get API breakage (DDL HELL), or unwanted behavior with un welcomed infra components upgrades that you never tested for. – Gili Nachum Jan 18 '13 at 23:05
  • That's why there's OSGi with its exact Import-Package/Export-Package versioning scheme. I strongly believe in OSGi's value, though it might not be as developer-friendly as many would want. The well-known jar hell is when you're out of control of your dependency versions. When you declare what you need from the environment as a set of pairs (name, version) you should never face issues with incompatibilities (unless the pair (name, version) is not "stable" meaning you depend on very shaky ground). – Jacek Laskowski Jan 19 '13 at 09:30
  • Oh, okay. Got you. So OSGI takes away the ambiguity in import /what ever version/ of x.y.z. Seems powerful indeed for those who are willing to pay the dev overhead. Thx! – Gili Nachum Jan 19 '13 at 20:05
  • 1
    I'm biased towards OSGi, so take it with a pinch of a salt - I don't think there's a need "to pay the dev overhead". Managing dependencies is so much complicated that with OSGi it won't change, but think it might ease it a lot. WebSphere supports [OSGi Applications](http://pic.dhe.ibm.com/infocenter/wasinfo/v8r0/topic/com.ibm.websphere.osgi.nd.doc/topics/ta_dev.html) and I highly recommend studying the concept. – Jacek Laskowski Jan 20 '13 at 10:38
1

From Understanding the IBM Software Developers Kit (SDK) for Java > Class loading :

[The delegation model] prevents code from less-trusted sources from replacing trusted core API classes by assuming the same name as part of the core API.

So, PARENT_LAST seems to exist for cases when an app must override a base class due to version incompatibilities, but doing this means it could also weaken security.

ewernli
  • 38,045
  • 5
  • 92
  • 123
  • Interesting, but I can't imagine how this form of security would be of importance as I package my EAR with Jars I trust. – Gili Nachum Jan 18 '13 at 22:52
  • 3
    @GiliNachum Sure, it makes sense only from the perspective of hosted environement, where the operators of the app. server do not necessary trust the developpers of applications deployed on the app. server. You trust your jars; but the operators might not trust *you*. – ewernli Jan 19 '13 at 14:50