Saxon

Sorry for the slowness in responding: for some reason I haven't been getting notification of new forum messages for a couple of weeks.

It's a little bit difficult to work out what's happening with only the stack trace to go by, but it's obviously related to a series of reflexive extension function calls. It's calling an instance-level (non-static) method on a class as an extension function, and it's looking at the first argument in the XPath function call, which represents the instance that will be the target of the call. The way this gets converted depends on the type information available (which we can't see). As one might expect, the XDM value supplied as this argument is an "external object" (that is, a wrapper around the target Java instance) and the job of the converter is simply to do the unwrapping.

The problem now is that the XDM value isn't actually an external object, but a Closure, which is like a promise of an external object that hasn't yet been evaluated. In general, when you evaluate a variable, it isn't immediately materialized, rather the required information to evaluate it (the things it depends on) is saved, and the object in which it is saved is called a Closure. There are two kinds of Closure: memo closures and non-memo closures; this one is a non-memo closure. The difference is that when you eventually get around to evaluating a closure, a memo closure remembers that value for future use, whereas a non-memo closure assumes that the value is only needed once, and discards it. What has gone wrong here is that Saxon decided the value was only needed once, but it got it wrong.

I think we'll have trouble working out why that happened (let alone be confident in any fix) unless we can reproduce it in the lab. I would ask you therefore, please, to produce a repro that enables us to reproduce the bug, debug the causes, test a fix, and create a regression test. Please do this directly on the bug tracker.

Hi Michael--

Thank you for the reply. I, too, apologize for the delay, I've been on holiday since 31 March, and have just gotten back to the office today.

I think the problem was something to do with an incorrect configuration of my webapp. I cleaned and rebuilt the entire app, and I no longer got this error, so I think it was probably due to a stale class file somewhere in the app or something along those lines.

If I come across this issue again, I will make more detailed notes and try to develop a stripped down test case to reproduce the problem. But until then, you can probably file this away under "user error" and not worry about it. Sorry for the trouble.

--Clay