[jdom-interest] Re: static data needs to be thread data for multithreaded applications

[philip.nelson at omniresources.com]

> My use of JDOM is also in server-world and I'd prefer to see 
> a slightly
> different direction - JDOM is a utility API so I think it 
> should, as far as
> possible, avoid making resource-management decisions for the 
> API user and
> when it does, it should provide hooks for as much control as 
> feasible. In
> the case of namespaces - assuming JDOM can one day tell 
> between a namespace
> name and a namespace declaration - Namespace declarations (or 
> rather, their
> prefix mappings) will probably be bound to a particular 
> document so the
> static data issue goes away there.

Are you all thinking about using the getDocument to find locate the home for
the namespaces and or prefix mappings?  At the time NameSpace was written,
there was a lot of discussion about the static hashtables but because nobody
wanted to maintain parent relationships, there was no way to put namespace
information in the Document for any given element.  It seems this has
changed since then.

> Short'n'sweet - the static-data/sync problem is partially 
> exacerbated by the
> lack of separation between namespace name and namespace 
> declaration and the
> centralized storage of things that may not need centralized 
> management under
> a better model. 

I apologize in advance but I don't understand what you mean by "lack of
separation between namespace name and namespace declaration".  I think that
the static variables in Namespace can't work on a server, or at least that
it's more compromises that it's worth.  It does work in what I think would
have to be the more common use case of many similar xml documents processed
by a server app.  My use case is a problem.  I would think that
serialization would be complicated as well.