I've tracked this down to the fact that the WAFileHandlerConfiguration instance 
was initialized during the load of Seaside3.0.3 and 
WAFileHandlerConfiguration>>descirbeOn: has been significantly changed in 
3.0.4...including the addition of the #resourceBaseUrl attribute which is the 
cause of the WAAttributeNotFound. 

It's not clear to me exactly how the instances get created in the first place 
nor is it clear what the best way to reset the instance is ... 

It appears that WASystemConfiguration class>>clearAllDescriptions does the 
trick, but I'm not sure whether it is _safe_ to clearAllDescriptions in a 
production system. 

The failure comes from search contexts that are not cleared correctly. When one 
adds a configuration option to an existing configuration description, the 
search contexts are not cleared. This is because a changed method doesn't 
affect the cached search contexts within the instances of the configurations.

First of all use the following as first-aid to the build process:
WAConfiguration allInstancesDo: [ :instance | instance clearSearchContexts ].
WAConfiguration allSubInstancesDo: [ :instance | instance clearSearchContexts ].

After that, we have two things to consider:
1) Clearing the search contexts is performed by:
WAConfiguration>>#clearSearchContexts
I think this should be added to the method: 
WASystemConfiguration>>#clearDescription
Any other places you think this should be added to?

2) Since adding a configuration setting means modifying a method 
(#describeOn:), the search contexts cannot be cleared without having a 
notification of some sort. Therefore, instead of trying to enforce each and 
every case of configuration "refresh", we can add to 
WAConfiguration>>#getSearchContextFor: a second lookup, which will not rely on 
the cache (in case there's a nil value on the cached search contexts). This 
way, we won't stumble upon a mismatch between configurations and their cache... 
Does this sound OK? 

If you changed a #describeOn: before the context cache you had to do 
WASystemConfiguration class >> #clearAllDescriptions  or WASystemConfiguration 
class >> #clearAllDescriptions. This was a known limitation. I would lean 
towards a solution that flushes the context cache then the configurations are 
cleared.

You mean adding the call to clearSearchContexts to 
WASystemConfiguration>>#clearDescription ?
Notice that WASystemConfiguration class>>#clearAllDescriptions uses 
WASystemConfiguration>>#clearDescription.

Yes, but it doesn't do #allInstancesDo: / #allSubInstancesDo: which causes 
problems on GemStone and we can easily add it in a class side initialize.

Never meant it to use #allInstancesDo: , I mentioned it because it is an 
immediate fix for clearing the search contexts.

Here's a proposed fix, including WASystemConfiguration>>#clearDescription

Looks OK. It's still like to see a class side #initialize in 
WASystemConfiguration or so that does a WASystemConfiguration >> 
#clearDescription for existing images.

OK, I merged this and added a class side #initialize in WASystemConfiguration 
that does a WASystemConfiguration >> #clearDescription for existing images.

I did the steps Dale wrote down and everything went fine.

I also took the 3.0.3 OneClick, ran the functional tests, then loaded the code 
and everything was still OK. This was not the case previously. I did the same 
thing again and before loading the updated code I changed some configuration 
settings on the default file handler.

Dale can you check again?

Philippe,

Will do ... I had a GemStone-Specific issue that I needed to address before 
proceeding with Seaside3.0.4 and I got through that today ...

I merged Avi's fix from Seaside-Core-as.700.mcz  into the latest Seaside-Core 
and it the tests pass in an upgraded image (failed before integration)...

So I would say that Avi's fix is good and will copy his package to the 
repository along with a checkin of my merged fix...I'll mark this issue fixed.

Ah...merged in Philippe's two mcz files with related chnages:

Seaside-Core-pmm.707
Seaside-Core-pmm.706

need to retest ...

Works like a champ ... let's put this one to bed.

Name: ConfigurationOfSeaside30-dkh.301
Author: dkh
Time: 28 February 2011, 3:48:37 pm
UUID: 4c881600-b6aa-49dc-b927-d838ed8b7d08
Ancestors: ConfigurationOfSeaside30-dkh.300

Name: Seaside-Core-dkh.710
Author: dkh
Time: 28 February 2011, 3:48:04 pm
UUID: 84619027-b248-4750-b290-ad05f51ecc3e
Ancestors: Seaside-Core-pmm.709, Seaside-Core-pmm.707