Mailing List webobjects-dev@wocommunity.org Message #380
From: Paul L. Merchant Jr. <Paul.L.Merchant.Jr@dartmouth.edu>
Subject: Problem Integrating Wonder....
Date: Tue, 19 Jul 2022 17:57:29 +0000
To: webobjects-dev@wocommunity.org <webobjects-dev@wocommunity.org>
Hi everyone, I maintain a collection of WebObjects frameworks and applications that have been happily running for well over a decade without the benefit of Project Wonder, but it seems my luck ran out recently after a seemingly minor update.  I started encountering stack overflow errors apparently during connection cleanup:

2022-06-08 15:07:10,234 [WorkerThread5] ERROR (LoggingOutputStream.java [flush]:205) - Caused by: java.lang.StackOverflowError

2022-06-08 15:07:10,234 [WorkerThread5] ERROR (LoggingOutputStream.java [flush]:205) -  at com.webobjects.foundation._NSWeakMutableCollection.processQueue(_NSWeakMutableCollection.java:176)

2022-06-08 15:07:10,234 [WorkerThread5] ERROR (LoggingOutputStream.java [flush]:205) -  at com.webobjects.foundation._NSWeakMutableArray.__removeReference(_NSWeakMutableArray.java:124)

[....]

From the mailing list archives I see that this is a long known issue and that Wonder has a fix for this problem, so I thought I'd try to integrate Wonder into my applications.  This turned up a number of issues, such as Wonder using log4j 1.x whereas my application had already incorporated log4j2.  It wasn't a major effort to upgrade Wonder to log4j2, but I ran into a show stopper when it came to some of the code in the ERFoundation.jar in the ERJars framework.  It seems this installs a custom(?) NSBundleFactory and NSBundle related classes that absolutely do not work with my WOLips/Eclipse project.  The way those classes deduce the root of the application bundle (traversing the directory tree upward from the Jar file until a directory containing a build.xml file is found) when running under the Eclipse debugger completely breaks resource lookups, unless possibly the source directory is very carefully organized in the same manner as assembled application.  This is significantly different than the behavior of the stock NSBundle clases, and I'm not sure it's correct or intentional given that I don't know the provenance of the ERFoundation.jar library.  At any rate, I'm not willing to give up my source organization to satisfy this behavior unless it's the only solution, nor do I know that's all the challenges I face if I did.

So I wondering if anyone else knows of a solution to this stack overflow problem that doesn't involve wholesale incorporation of Wonder, or if there's some work around to the ERFoundation resource lookup issue?  

I appreciate any advice you can give me!
Subscribe (FEED) Subscribe (DIGEST) Subscribe (INDEX) Unsubscribe Mail to Listmaster