True, but still this doesn't justify (in my head) two of them for a single method invocation. If your method ( I know it's an unlikely example and bad style but bear with me) has 10 of them, that means 10 new objects..surely it would be better to instantiate and re-use one for as many XPath annotations in the method *per thread *and still retain thread safety.
On 13 August 2010 20:42, Ron Smith <ronsmit...@gmail.com> wrote: > Note that it is not just XPath. Pretty much all of the XML parsers in the > JDK are not thread safe. For instance, we were just having a related > discussion here in another thread and, at the moment, I am using ThreadLocal > to hold on instances of SAXParser for different threads. > > On Fri, Aug 13, 2010 at 9:35 AM, Claus Ibsen <claus.ib...@gmail.com> wrote: > >> On Fri, Aug 13, 2010 at 2:08 PM, Yiannis Mavroukakis >> <imavrouka...@gameaccount.com> wrote: >> > I have two XPath expressions on a @RoutingSlip bean, I've noticed in the >> > logs that I get this >> > >> > [ New I/O server worker #1-1] XPathBuilder DEBUG >> > Creating default XPathFactory >> > [ New I/O server worker #1-1] XPathBuilder DEBUG >> > Creating default XPathFactory >> > >> > Does this mean that there are two XPathBuilder instances ? >> > >> >> All the XPath stuff in the JDK is not thread safe and you gotta create >> new instances of the factory. >> >> The XPathFactory class is not thread-safe. In other words, it is the >> application's responsibility to ensure that at most one thread is >> using a XPathFactory object at any given moment. Implementations are >> encouraged to mark methods as synchronized to protect themselves from >> broken clients. >> >> >> > >> > Thanks, >> > Yiannis >> > >> >> >> >> -- >> Claus Ibsen >> Apache Camel Committer >> >> Author of Camel in Action: http://www.manning.com/ibsen/ >> Open Source Integration: http://fusesource.com >> Blog: http://davsclaus.blogspot.com/ >> Twitter: http://twitter.com/davsclaus >> >
