Re: Bundle-less Builds startup error

Kieran Kelleher <[email protected]> Sun, 12 Sep 2010 21:38:02 -0400
Newsgroups	gmane.comp.web.webobjects.woproject.devel
Message-ID	<[email protected]>
Send the classpath from the console which will tell the truth about where NSBundle is....

On Sep 10, 2010, at 5:09 PM, Tim Worman wrote:

> I'm still getting this error - "ERXExtensions have not been initialized" when I launch my app. However, I only get the issue if a particular framework project is open in my workspace. If I close the framework project and I run against the installed version of the framework the app runs fine. I have ordered the build path as described previously for both the framework project and the dependent app project.
> 
> Tim Worman
> UCLA GSE&IS
> 
> On Sep 3, 2010, at 11:43 AM, Mike Schrag wrote:
> 
>> ew.
>> oh wait.
>> ERJars has NSBundle in it now.
>> That's why. ... Foundation is winning in the NSBundle lookup with JavaFoundation first. Ain't that a bitch.
>> 
>> On Sep 3, 2010, at 2:40 PM, Kieran Kelleher wrote:
>> 
>>> I don't understand why either, I would have thought only ERX to matter too, but here is it narrowed down more:
>>> 
>>> This fails (same error as first email on thread today)
>>> 
>>> <?xml version="1.0" encoding="UTF-8"?>
>>> <classpath>
>>> 	<classpathentry kind="con" path="WOFramework/ERExtensions"/>
>>> 	<classpathentry kind="con" path="WOFramework/JavaFoundation"/>
>>> 	<classpathentry kind="con" path="WOFramework/ERJars"/>
>>> 	<classpathentry kind="src" path="Sources"/>
>>> 	....
>>> 
>>> 
>>> and this works!
>>> 
>>> 
>>> <?xml version="1.0" encoding="UTF-8"?>
>>> <classpath>
>>> 	<classpathentry kind="con" path="WOFramework/ERExtensions"/>
>>> 	<classpathentry kind="con" path="WOFramework/ERJars"/>
>>> 	<classpathentry kind="con" path="WOFramework/JavaFoundation"/>
>>> 	<classpathentry kind="src" path="Sources"/>
>>> 	....
>>> 
>>> 
>>> 
>>> On Sep 3, 2010, at 2:28 PM, Mike Schrag wrote:
>>> 
>>>> but why? that's weird ... i would expect only ERX to matter .......
>>>> 
>>>> On Sep 3, 2010, at 2:20 PM, Kieran Kelleher wrote:
>>>> 
>>>>> Again, you are correct. This is a case of changing two things at the same time.
>>>>> 
>>>>> The real fix was ERJars high up in the class path. If I push ERJars way down the classpath, I get the same error as in the first email in the thread.
>>>>> 
>>>>> I pushed it down and retired a few times until failure. Pushing it below JavaFoundation seems to trigger the error for me with this particular app.
>>>>> 
>>>>> 
>>>>> <?xml version="1.0" encoding="UTF-8"?>
>>>>> <classpath>
>>>>> 	<classpathentry kind="con" path="WOFramework/ERExtensions"/>
>>>>> 	<classpathentry kind="src" path="Sources"/>
>>>>> 	<classpathentry kind="con" path="WOFramework/WKMySql"/>
>>>>> 	<classpathentry kind="con" path="WOFramework/WKRemoteClient"/>
>>>>> 	<classpathentry kind="con" path="WOFramework/WKSatoriNcoaWebservice"/>
>>>>> 	<classpathentry kind="con" path="WOFramework/WKAxis"/>
>>>>> 	<classpathentry kind="con" path="WOFramework/ERJavaMail"/>
>>>>> 	<classpathentry kind="con" path="WOFramework/WKRemoteMailingServices"/>
>>>>> 	<classpathentry kind="con" path="WOFramework/WKWebObjects"/>
>>>>> 	<classpathentry kind="con" path="WOFramework/WKDemography"/>
>>>>> 	<classpathentry kind="con" path="WOFramework/WKEmailData"/>
>>>>> 	<classpathentry kind="con" path="WOFramework/Ajax"/>
>>>>> 	<classpathentry kind="con" path="WOFramework/ERSelenium"/>
>>>>> 	<classpathentry kind="con" path="WOFramework/ExcelGenerator"/>
>>>>> 	<classpathentry kind="con" path="WOFramework/WKTesting"/>
>>>>> 	<classpathentry kind="con" path="WOFramework/WOLips"/>
>>>>> 	<classpathentry kind="con" path="WOFramework/WOOgnl"/>
>>>>> 	<classpathentry kind="con" path="WOFramework/JavaWOExtensions"/>
>>>>> 	<classpathentry kind="con" path="WOFramework/JavaEOAccess"/>
>>>>> 	<classpathentry kind="con" path="WOFramework/JavaEOControl"/>
>>>>> 	<classpathentry kind="con" path="WOFramework/JavaFoundation"/>
>>>>> 		<classpathentry kind="con" path="WOFramework/ERJars"/>
>>>>> 	<classpathentry kind="con" path="WOFramework/JavaJDBCAdaptor"/>
>>>>> 	<classpathentry kind="con" path="WOFramework/JavaWebObjects"/>
>>>>> 	<classpathentry kind="con" path="org.eclipse.jdt.launching.JRE_CONTAINER"/>
>>>>> 	<classpathentry kind="con" path="WOFramework/JavaXML"/>
>>>>> 	<classpathentry kind="con" path="WOFramework/WKParse"/>
>>>>> 	<classpathentry kind="con" path="WOFramework/ERPrototypes"/>
>>>>> 	<classpathentry kind="con" path="WOFramework/ERAttachment"/>
>>>>> 	<classpathentry kind="con" path="WOFramework/ERProfiling"/>
>>>>> 	<classpathentry kind="con" path="WOFramework/WKListSource"/>
>>>>> 	<classpathentry kind="con" path="WOFramework/WKCheetahBusinessLogic"/>
>>>>> 	<classpathentry kind="con" path="WOFramework/GoogleChart"/>
>>>>> 	<classpathentry kind="con" path="WOFramework/WKCharts"/>
>>>>> 	<classpathentry kind="con" path="WOFramework/ERExtensionsSandbox"/>
>>>>> 	<classpathentry kind="con" path="WOFramework/ERJasperReports"/>
>>>>> 	<classpathentry kind="con" path="WOFramework/ERAjaxExtensions"/>
>>>>> 	<classpathentry kind="output" path="bin"/>
>>>>> </classpath>
>>>>> 
>>>>> 
>>>>> 
>>>>> On Sep 3, 2010, at 2:01 PM, Mike Schrag wrote:
>>>>> 
>>>>>> BTW, you no longer need that property -- if bundleless builds is checked, wolips will automagically insert the -D for you at launch time.
>>>>>> 
>>>>>> ms
>>>>>> 
>>>>>> On Sep 3, 2010, at 1:56 PM, Kieran Kelleher wrote:
>>>>>> 
>>>>>>> Mike,
>>>>>>> 
>>>>>>> as always *you* are right, and *I* am wrong! Sorry, I could swear that the -D version did not work when I first tried it, but sure enough, it does ... both ways work.
>>>>>>> 
>>>>>>> Thanks for clarifying, and thanks very much for super fast bundle-less builds. :-)
>>>>>>> 
>>>>>>> Kieran
>>>>>>> 
>>>>>>> On Sep 3, 2010, at 1:51 PM, Mike Schrag wrote:
>>>>>>> 
>>>>>>>>> It needs to be without the "D", like shown here for the launch configuration, *and* ERJars needs to be high up in the class path (I put it in 2nd place after ERExtensions). The -D prefix is for command line arg when using = for a java property.
>>>>>>>> both should work -- -D's become vm args and -'s become commandline args. I would actually expect this to only reliably work as a -D an NOT a commandline arg. I guess wonder trunk doesn't touch nsbundle too early, so maybe it works out. In general, though, -D is almost always going to be more reliable. if it's not working, it's a bug.
>>>>>>>> 
>>>>>>>> ms
>>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>>> 
>> 
>