Firstly, because when I did this first time around, I built the .jar from inside WebSphere Studio, the wsif.properties file was missing. This meant that despite the WSIFProperties implementation only loading the first properties file it finds, the initial implementation worked. Because I used the .jar I built at home today, the wsif.properties file in my application wasn't loaded (wsif.jar is in my application server's 'lib' directory, and therefore the default properties are higher in the ClassLoader tree than the one in my application). I've made two changes as a result of this:
* I've modified the included wsif.properties to remove the wsif.servicefactory property, since it points to a factory which isn't in the core distribution.
* I've now made a change to WSIFProperties so that it merges the changes from all the wsif.properties files it finds in the classpath. For example, if you have a context ClassLoader with a wsif.properties file, any properties in this file which have the same key as one in the default file will replace the default value. Can anyone think of any security implications of this? I'm aware that this doesn't quite square with the Java2 ClassLoading pattern.
At the moment, the WSIFProperties implementation only has a single cache of properties values, which means that there is likely to be a problem if WSIF is used in multiple applications in the same server. I'm going to make an additional change to make WSIFProperties cache values per context ClassLoader, which should sort this out, and keep performance high.
I'm aware that these changes are rather more substantial than the one I originally proposed, so I totally understand if you'd rather stay away from this patch. Let me know what you think.
Paul
WSIFServiceFactorySupport.diff
Description: Binary data
On 27 Jan 2004, at 23:26, Paul Russell wrote:
Nirmal,
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>
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]
-- Paul Russell [EMAIL PROTECTED]
