• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: java.lang.NullPointerException at com.webobjects.woextensions.WOExceptionParser._ignoredPackages(WOExceptionParser.java:63)
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: java.lang.NullPointerException at com.webobjects.woextensions.WOExceptionParser._ignoredPackages(WOExceptionParser.java:63)


  • Subject: Re: java.lang.NullPointerException at com.webobjects.woextensions.WOExceptionParser._ignoredPackages(WOExceptionParser.java:63)
  • From: Ray Kiddy <email@hidden>
  • Date: Fri, 08 Jul 2011 22:53:19 -0700


I do not think you needed to go through this much effort. There is a replacement for this class in Project Wonder. The code there looked remarkably like your decompilation.

I just changed the _ignoredPackages method in the Project Wonder version to be quite a bit more resistant to exceptions. I guess that if you have a method looping through frameworks looking for plists and there is some exception reading the plist, someone might care. I cannot imagine who that would be, though.

cheers - ray

On Jul 8, 2011, at 10:51 AM, Lars Sonchocky-Helldorf wrote:

I regularly see the following stacktrace in our applications log:

[2011-7-8 10:4:1 CEST] <WorkerThread3> java.lang.NullPointerException
       at com.webobjects.woextensions.WOExceptionParser._ignoredPackages(WOExceptionParser.java:63)
       at com.webobjects.woextensions.WOExceptionParser._parseException(WOExceptionParser.java:105)
       at com.webobjects.woextensions.WOExceptionParser.<init>(WOExceptionParser.java:44)
       at com.webobjects.woextensions.WOExceptionPage.setException(WOExceptionPage.java:33)
       at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
       at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
       at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
       at java.lang.reflect.Method.invoke(Method.java:597)
       at com.webobjects.woextensions.KeyValueCodingProtectedAccessor.setMethodValue(KeyValueCodingProtectedAccessor.java:34)
       at com.webobjects.foundation.NSKeyValueCoding$_MethodBinding.setValueInObject(NSKeyValueCoding.java:1150)
       at com.webobjects.foundation.NSKeyValueCoding$DefaultImplementation.takeValueForKey(NSKeyValueCoding.java:1354)
       at com.webobjects.appserver.WOComponent.takeValueForKey(WOComponent.java:1748)
       at com.webobjects.appserver.WOApplication._handleError(WOApplication.java:3093)
       at com.webobjects.appserver.WOApplication.handleException(WOApplication.java:3245)
       at com.webobjects.appserver._private.WOComponentRequestHandler._handleRequest(WOComponentRequestHandler.java:389)
       at com.webobjects.appserver._private.WOComponentRequestHandler.handleRequest(WOComponentRequestHandler.java:445)
       at er.ajax.AjaxRequestHandler.handleRequest(AjaxRequestHandler.java:17)
       at com.webobjects.appserver.WOApplication.dispatchRequest(WOApplication.java:1687)
       at com.webobjects.appserver._private.WOWorkerThread.runOnce(WOWorkerThread.java:144)
       at com.webobjects.appserver._private.WOWorkerThread.run(WOWorkerThread.java:226)
       at java.lang.Thread.run(Thread.java:662)

Since there is none of our code involved it seems to be an issue with WO 5.4.3. Usually it seems to appear after another bug was triggered before. Looks like the Exception Page doesn't get filled in correctly in those cases. So I decompiled the Code in question (com.webobjects.woextensions.WOExceptionParser):

/*     */   protected NSArray _ignoredPackages()
/*     */   {
/*  53 */     NSMutableArray allBundles = new NSMutableArray(NSBundle.frameworkBundles());
/*  54 */     NSMutableArray ignored = new NSMutableArray();
/*     */ 
/*  56 */     Enumeration enumerator = allBundles.objectEnumerator();
/*  57 */     while (enumerator.hasMoreElements()) {
/*  58 */       NSBundle bundle = (NSBundle)enumerator.nextElement();
/*  59 */       String path = WOApplication.application().resourceManager().pathForResourceNamed("WOIgnoredPackage.plist", bundle.name(), null);
/*  60 */       if (path != null);
/*  61 */       String content = _stringFromFile(path);
/*  62 */       NSDictionary dic = (NSDictionary)NSPropertyListSerialization.propertyListFromString(content);
/*  63 */       NSArray tmpArray = (NSArray)dic.objectForKey("ignoredPackages");
/*  64 */       if ((tmpArray != null) && (tmpArray.count() > 0));
/*  65 */       ignored.addObjectsFromArray(tmpArray);
/*     */     }

Somehow that looks fishy to me. Note line 60 and line 64, the semicolon at the end of each. Either those are bugs or the decompiler (JD http://java.decompiler.free.fr/ ) has failed severely. 

Either way, how would I avoid such stacktraces? Providing an dummy WOIgnoredPackage.plist with dummy entries? 


cheers,

Lars

 _______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list      (email@hidden)
Help/Unsubscribe/Update your Subscription:

This email sent to email@hidden

References: 
 >java.lang.NullPointerException at com.webobjects.woextensions.WOExceptionParser._ignoredPackages(WOExceptionParser.java:63) (From: Lars Sonchocky-Helldorf <email@hidden>)

  • Prev by Date: Re: ERRest and Faulting control
  • Next by Date: Dealing with EOUtilities.localInstanceOfObject() in WOUnit
  • Previous by thread: java.lang.NullPointerException at com.webobjects.woextensions.WOExceptionParser._ignoredPackages(WOExceptionParser.java:63)
  • Next by thread: ERRest and Faulting control
  • Index(es):
    • Date
    • Thread