[jdom-interest] Resolver announcement

[Rolf Lear]

Hi all.

way-back-when... about July last year, I ran in to a problem resolving 
documents against w3x resources. Essentially the problem is described here:

http://www.w3.org/blog/systeam/2008/02/08/w3c_s_excessive_dtd_traffic/

I thought JDOM was a good location for building a solution to this 
problem. I even created an 'issue' for it...
https://github.com/hunterhacker/jdom/issues/26

I later decided that JDOM was not necessarily the correct place to solve 
that problem, so I 'rejected' that issue.

But I have still been perplexed by this problem for a while now, and I 
have taken some time in the past few weeks to tackle the problem, and 
perhaps come up with a solution.

Thus, I invite anyone interested to have a look at:
https://github.com/rolfl/Resolver

This project has the 'simple' purpose of behaving very much like a 
caching proxy server for HTTP documents and exposing the cache as an 
EntityResolver useful for SAX and other parsing.

I decided to tackle the hard parts first - how do you build a file-based 
cache in a multithreaded system, with the added complexity that it needs 
to be accessible from multiple JVM's, not just threads within one JVM.

I figure that the code is too 'immature' to call 'stable', and it is not 
a great fit for JDOM (since the solution has no code shared with 
anything in JDOM, and it does not even process any XML...). So, 
releasing it as part of JDOM2 is not appropriate, but its usefulness is 
significant.

So, if anyone is interested, I am eager to get some input on it...

I think an attempt to make an 'easy to use' system for entity resolving 
would be a benefit for the entire Java community... A ssytem that allows 
you to plug in a combination of in-memory cached entities, combined with 
on-disk 'catalog' systems (perhaps leveraging the xerces 'Resolver' 
project, then this 'Resolver' for caching non-catalog resources, finally 
a fall through to more traditional URL-based resolvers would be ideal.

Thanks

Rolf