• Bug
  • Status: Closed
  • 2 Major
  • Resolution: Fixed
  • DSO:L1
  • hhuynh
  • Reporter: ari
  • September 24, 2007
  • 0
  • Watchers: 1
  • October 15, 2007
  • October 08, 2007

Attachments

Description

When trying to get wars loaded in Websphere using the Websphere config module, I had everything setup correctly but ended up with a failed container startup when my included classes where set as “*..*”.

I tried leaving out include-classes and just defining my webapp name. That throws no errors but doesn’t work.

I then included “*..*” and Websphere writes a 24MB log file to nativeErr.log with what is seemingly the world’s longest stack trace. So I just eyeballed the stacktrace, and chose to exlude 2 things:

com.ibm..* and org.eclipse..*

Then everything worked perfectly.

I was sharing our Cart.war demo. And I have attached my tc-config (the one that works).

Comments

Tim Eck 2007-09-24

Not sure how many exceptions were happening, but one of them is a stackoverflow. The code that tries to create ClassInfo for isRoot() is getting an endless cycle of class loading with permissions.

It’s not clear why InstrumentEverythingInContainerTest isn’t failing – unless this specific only to 6.1.0.0 (We run 6.1.0.7 in the monkey)

Geert Bevin 2007-09-25

Following Tim’s comment, I’m just curious, you’re using WebSphere 6.1.0.7 (6.1 base version, fix pack 7), right? This includes the JDK fix pack.

Ari Zilka 2007-09-28

I could not find the fixpacks on ibm.com to go straight from 6.1.0.0 to 6.1.0.7. Their site is poorly organized. So, I was indeed running 6.1.0.7. If someone will help me find out how to patch, I will do so and see if the problem goes away. That’s the next step.

Ari Zilka 2007-09-29

Sorry. I WAS NOT running 6.1.0.7. I was running 6.1.0.0.

Tim Eck 2007-10-06

This stackoverflow does not happen in 6.1.0.7. I observed it broken and not-broken in two different contexts (1) Using clean standalone installs of WAS and deploying the Cart demo, (2) Running our InstrumentEverythingInContainerTest. In both contexts, 6.1.0.0 got the same stackoverflowerror, and 6.1.0.7 worked fine.

This particular type of cycle can be detected and avoided (leaving some set of classes un-instrumentable). The overhead involved is not worth it in my opinion, even though this can really happen in any application.

Geert Bevin 2007-10-08

I agree that the IBM site is very poorly organized and it always takes me a while to find what I need too.

This is a document with all fixpacks and cumulative fixes for Websphere and the IBM JDK:

http://www-1.ibm.com/support/docview.wss?rs=180&context=SSEQTP&uid=swg27004980#ver61

Geert Bevin 2007-10-08

Tim, can you comment more about why this endless cycle happens?

Tim Eck 2007-10-08

added a (non-overrideable) exclude for one class. 6.1.0.0 will start now with *..* include in user config