WO451 on Jaguar/Panther/Tiger [was: Re: Side effect of OSX on Intel announcement]

On 9 Jun 2005, at 18:07, Pierce T. Wetter III wrote:

> ...
>  Yes. Doing it right now on Tiger!
>>
>> I would be very interested in knowing how did you achieve that, as we
>> are worried abount the current Apple hardware not beeing able to run
>> MacOS 10.2.
>
>   Well, we buy G5 XServes all the time, so here goes.
>
>   At this point, we have this all in a giant tgz file we just extract,  
> so this is off the top of my head.
>
>   Basically, starting from a working 10.x install of WO4.5.1P4, tar up  
> the following files/directories:
>
> Developer/Applications/EOModeler.app/
> Developer/Applications/WebObjects Builder.app/
> System/Library/Frameworks/EOAccess.framework/
> System/Library/Frameworks/EOControl.framework/
> System/Library/Frameworks/EOInterface.framework/
> System/Library/Frameworks/EOModeler.framework/
> System/Library/Frameworks/Plot.framework/
> System/Library/Frameworks/WebObjects.framework/
> System/Library/Frameworks/WOExtensions.framework/
> System/Library/PrivateFrameworks/MultiScript.framework/
> System/Library/PrivateFrameworks/XML.framework/
> System/Library/StartupItems/WebObjects/
> System/Library/StartupItems/WebObjects/StartupParameters.plist
> System/Library/StartupItems/WebObjects/WebObjects
> System/Library/WebObjects/Adaptors/
> System/Library/WebObjects/Applications/
> System/Library/WebObjects/Executables/
>
> Basically, you need to get the two PrivateFrameworks above, and there  
> are a couple of .plist files in WebObjects that were missing a  
> trailing ';'. The 10.0 .plist parser was more flexible, the 10.1+  
> complains. You can fix it by just opening it in a text editor and  
> adding a ; to the end of the file.
>
>  Though if you're running on 10.2, you've probably fixed all that  
> already.
>
>  Repeat for a deployment install instead of a developer install,  
> though in that case you don't need some of the above stuff.
>
>  That's pretty much it. WO is basically a command line process, so it  
> doesn't depend on stuff.
>
>  Then in your xcode projects (after upgrading them):
>
>    The new KVC stuff ends up overriding the old WO KVC stuff, so you  
> have to include Foundation.framework LAST, after all the WO EOF stuff  
> so that WO uses the old KVC stuff instead of the new KVC stuff. I  
> think that happened in Panther? so that may be your problem.
>
>
>  The newer operating systems are also more fussy about if  
> "application"includes framework1, but not framework2, but framework1  
> included framework2, it used to be ok. Now "application" has to  
> include framework2 as well if it uses it.

OK I'm interested.  Very interested.

The only plist I found that appeared to need tweaking is  
/System/Library/Frameworks/WebObjects.framework/Versions/A/Resources/ 
taginfo.plist, and rhat appears to be needed for development, not for  
deployment.  For me, deployment on current MacOSX (client, not server)  
with Apache is a must, development would be a bonus.  [So would the  
above reference to the stricter 10.1+ plist parser actually mean  
10.2+?]

Traditionally I have used the default 'host list' configuration method  
(see /System/Library/WebObjects/Adaptors/Apache/apache.conf ), and  
clearly I was using that when previously I tried to get our apps going  
on 10.3.x .  One of the problems is that because of Rendezvous (or  
Bonjour, or whatever the lawyers say it's called this week) and other  
changes in the OS, wotaskd on localhost thinks it's running on a  
machine called something like 'panther.local.' instead of 'localhost'.   
But if I use 'file' based configuration, I can bypass that, and I can  
see my app running, which is way more than I managed whenever I looked  
at this before.

But wotaskd and Monitor are misbehaving, and I think I still need  
those.  My /var/log/webobjects.log file is steadily filling with things  
like
'2005-06-10 12:02:14.163 wotaskd[1873] *** +[NSNotificationCenter  
setNotificationCenterSerializeRemoves:]: this method now does nothing,  
stop calling it'
which I think I can ignore, and
'2005-06-10 12:05:38.764 wotaskd[1873] Failed to save local site  
config. Is /Library/WebObjects/Configuration/SiteConfig.conf writeable  
?'
'2005-06-10 12:05:43.760 Monitor[1975] Failed to save local site  
config. Is /Library/WebObjects/Configuration/SiteConfig.conf writeable  
?'
that I can't;  and yes, the relevant directory and files have modes  
0777 or 0666.


In the past I have fixed this by building my own WOExtensions framework  
with some categories to restore the 'all collections are mutable'  
behaviour that was in 10.0.  If I do that, wotaskd and Monitor work,  
but -- as per an earlier post from me -- the EOAdaptor I'm using  
breaks.

Ideas please?  How do I fix wotaskd and Monitor?

-- Patrick