Thanks for your reply. Attached is a patch for this. I'm quite new to WSIF, so I'm not clear how you deal with patches (I know that other projects use Jira or similar). I couldn't find anywhere other than this mailing lists to put this patch, so I've attached it here; apologies if this isn't the right forum!
WSIFServiceFactorySupport.diff
Description: Binary data
Couple of things to bear in mind about this:
* I've made minor modifications (mainly around logging etc) since I made the initial change. I'm working on this from home (can't get to CVS to do a diff at work), and the only place I can test this properly is at work. I'll make sure this happens tomorrow, and will e-mail to confirm this passed okay. Probably best not to commit the change until this is complete.
* I tried to run the automated unit tests, but they failed to compile. Is this expected, or have I broken something?
* I noticed while I was making this change that the WSIFProperties class caches the Properties instance once it has been built. While I can totally see why this a good thing from a performance point of view, I can see this causing problems if you try and use WSIF in an environment where there are multiple context class loaders, all of which could potentially want to call WSIF. I think this may apply to the work I'm doing, although I'm not far enough down the line to be sure yet. I'll let you know if this turns out to be a problem. If it does turn out to be a problem, I can't see any reason why we can't cache the properties instance in a Map keyed against the context classloader instance.
Thanks, let me know if the patch is any use or not...
Paul
On 27 Jan 2004, at 15:23, Nirmal Mukhi wrote:
Hi,
Introduction of custom service factories was taken out for efficiency reasons at one point, but I support it as being a good thing, since I think the use far outweighs the reduction in performance. Why don't you submit the patch so the committers can vote on it? Hopefully it will pass that vote and if so I'll commit it to the codebase.
Thanks, Nirmal.
-- Paul Russell [EMAIL PROTECTED]
