[jbosscache-dev] Configuration Related Changes and Notes

[Manik Surtani]

On 15 Aug 2008, at 22:50, Jason T. Greene wrote:

> I committed the following changes:
> ---------------------------------
> - Switched to JBossEntityResolver to support automatic schema  
> discovery
> - Updated schema to use urn:jboss:jbosscache-core:config:3.0 namespace
> - Corrected simple type pattern for locking scheme
> - Modified parser and configs to use the namespace
> - Added root element checking to prevent NPEs

Thanks for sorting these!

> I ran these through the full testsuite with no failures, however a  
> recent commit I had to merge appears to have broken a number of  
> tests (with or without my changes).

I have a few changes around eviction configs, could have something to  
do with that.  I'll have a look anyway.

> Some outstanding issues:
> -----------------------
> - Schema validation failures just log errors. Shouldn't they abort  
> startup? The XML parsing code seems to assume validation was  
> performed and successful since it doesn't do much itself
> - XmlParsingConfigurationRegistry does not use a proper schema!
> - LegacyConfigurationTest is testing the new configuration format  
> instead of the legacy one
> - We need to decide on case sensitivity and correct either the  
> schema (as I did for locking scheme), or update the xslt to lower/ 
> upper case everything
> - Not sure what to do about the jgroups section. Right now the  
> configs put it in the cache namespace, which is not really correct.  
> However since we don't have a jgroups namespace, I didnt bother  
> qualifying. The only other option would be to add xmlns="" to the  
> outer jgroups element. In any case the parser accepts them in any  
> namespace

Will look into these as well.

> JAXB
> ----
> IMO, we should think about using JAXB for this in the future. It is  
> *much* more accurate than hand rolled parsing code, and it's a lot  
> easier to maintain. It also has very good error handling (you don't  
> even need to do full schema validation with it). While it does  
> require a jar under JDK5, it is part of JDK6, so if we added a  
> another dep it would only be temporary.

I'd leave this till we baseline on JDK6 at some stage in the future.   
In fact, create a JIRA for this so we have a record of it, target it  
to 4.0 or something.  Don't want another jar.  :-)

Cheers,
--
Manik Surtani
Lead, JBoss Cache
manik at jboss.org