On 7/01/2003 8:50 AM, "Jordi Salvat i Alabart" <[EMAIL PROTECTED]> wrote:
> It works for me. Not really remote: against 127.0.0.1 -- but I guess > this shouldn't matter. > > Shouldn't the "pattern" member variable be populated when the object is > instantiated at deserialization? The only "pattern" member I see is the one local to evaluateResponse() which is not part of the serialization. > > Sorry I'm not that familiar with serialization as I should be... Me neither, but I do know that there is no point in marking static variables as transient ;-) > > Anyway, I'm thinking the "pattern" should be static: if we have several > assertions using the same pattern, we don't want to recompile it... I think you mean the patternCache - and I agree that making this static is a good idea. > > Something else: I just learned that to use a compiled pattern from > different concurrent threads you need to compile it with a "READ_ONLY" > flag (or similar). Good call. > > I guess we'll need to have a deeper look at this, but first of all, I'd > need to reproduce your problem. What O.S., JDK, etc. are you using? The problem *was* happening on remote servers running win2k with j2sdk1.4.1_01 (not sure about other platforms). I have a local change that fixes the problem (using the static patternCache with READ_ONLY does the trick) - I will commit this shortly. Cheers, Scott -- Scott Eade Backstage Technologies Pty. Ltd. http://www.backstagetech.com.au .Mac Chat/AIM: seade at mac dot com -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
