XMLCatalog needs urgent refactoring

[Jose Alberto Fernandez <ja...@cellectivity.com>]

Hi,

I need to provide some ANT tasks (like XMLValidate) a different implementation (subclass) of XMLCatalog
that knows how to resolve DTDs and external entities using things other than the simple publicId->fixlocation
mapping provided by XMLCatalog.

I have defined the new calatog, but it turns out there is no way to plug it into the applications
because XMLCatalog.addConfiguredXMLCatalog() does not delegate the serach to the other catalog instances
but instead it scans the internal datastructure (Vectors) of XMLCatalog to combine the two.

This renders any attempts to override the behaviour of XMLCatalog completely useless. 
Matters are made worst by the fact that tasks like XMLValidate create their own internal
instance of XMLCatalog (hardcodded) and ten use addConfiguredXMLCatalog() to actually load
the indicated catalog.

The fact that every method in XMLCatalog is private, instead of protected mae things even more
dificult. I would like to propose a refactoring of this code so that befaviour can be redefined 
better. I see two ways of achieving this:

1) Make XMLCatalog have a Vector of referenced catalogs and invoke recursively on them.
This will require making resolveImpl() and resolveEntityImpl() protected.

2) Making DTDLocation have associated behavior DTDLocation.resolve(publicId, systemId) and allow to have
diferent implementations of this objects. This would allow for example having something like
DTDPrefixLocation which uses prefix for the matching and other such elements of full catalog implementations.

Maybe we need a mixture of the two.

Before I propose a patch, I would like to know what people think and what constraints there are for
such a refactoring so that the patch is not rejected or becomes part of some religious war.

Please let me know your opinion,

Jose Alberto

Re: XMLCatalog needs urgent refactoring

[Erik Hatcher <ja...@ehatchersolutions.com>]

I'm +1 on these refactorings.

As for things being private... thats the best way to start, in my 
opinion, and then open up when a need arises.

	Erik


Jose Alberto Fernandez wrote:
> Hi,
> 
> I need to provide some ANT tasks (like XMLValidate) a different implementation (subclass) of XMLCatalog
> that knows how to resolve DTDs and external entities using things other than the simple publicId->fixlocation
> mapping provided by XMLCatalog.
> 
> I have defined the new calatog, but it turns out there is no way to plug it into the applications
> because XMLCatalog.addConfiguredXMLCatalog() does not delegate the serach to the other catalog instances
> but instead it scans the internal datastructure (Vectors) of XMLCatalog to combine the two.
> 
> This renders any attempts to override the behaviour of XMLCatalog completely useless. 
> Matters are made worst by the fact that tasks like XMLValidate create their own internal
> instance of XMLCatalog (hardcodded) and ten use addConfiguredXMLCatalog() to actually load
> the indicated catalog.
> 
> The fact that every method in XMLCatalog is private, instead of protected mae things even more
> dificult. I would like to propose a refactoring of this code so that befaviour can be redefined 
> better. I see two ways of achieving this:
> 
> 1) Make XMLCatalog have a Vector of referenced catalogs and invoke recursively on them.
> This will require making resolveImpl() and resolveEntityImpl() protected.
> 
> 2) Making DTDLocation have associated behavior DTDLocation.resolve(publicId, systemId) and allow to have
> diferent implementations of this objects. This would allow for example having something like
> DTDPrefixLocation which uses prefix for the matching and other such elements of full catalog implementations.
> 
> Maybe we need a mixture of the two.
> 
> Before I propose a patch, I would like to know what people think and what constraints there are for
> such a refactoring so that the patch is not rejected or becomes part of some religious war.
> 
> Please let me know your opinion,
> 
> Jose Alberto
> 
> 
> 
> 
> 
> 
> ------------------------------------------------------------------------
> 
> --
> To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>