[jbosscache-dev] Config files

Brian Stansberry brian.stansberry at redhat.com
Tue Feb 5 14:11:35 EST 2008


I have no appetite at all for this in 2.1.  Last thing I need is 
something breaking because of some change in parsing.

The simple solution seems fine to me; if someone deploys the 
jboss-cache-core-tests.jar in the AS... well, don't do that.

Manik Surtani wrote:
>  From the conf call yesterday:
> 
> Currently the XML config parser looks for a <mbean ../> element, under 
> which it pulls out more specific JBoss Cache elements.
> 
> I could easily change the parser to accept this, or on failing to do so, 
> to pick up a <jbosscache ... /> container element. Perhaps even log a 
> deprecation warning when using the old <mbean ... /> container tag.
> 
> This would affect a few things though:
> 
> 1) We ought to then update all sample configs and docs to reflect this 
> "new" element
> 2) Document how the configuration will still accept old <mbean ... /> tags
> 3) Document how the <mbean ... /> tag can cause problems with AS 5 
> (unintentional deployment), and how this can be done properly with the MC.
> 
> The question is, is this something we ought to defer for 3.0?  Or is 
> this critical enough to move to 2.1?  In terms of effort, this isn't 
> that great; in terms of risk, we already have a simple solution to 
> overcome unintentional deployment (don't package the sample configs with 
> jbosscache-core.jar, but package them in jbosscache-core-tests.jar for 
> PojoCache)
> 
> Thoughts?
> -- 
> Manik Surtani
> Lead, JBoss Cache
> manik at jboss.org
> 
> 
> 
> 
> 
> 
> _______________________________________________
> jbosscache-dev mailing list
> jbosscache-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jbosscache-dev

-- 
Brian Stansberry
Lead, AS Clustering
JBoss, a division of Red Hat
brian.stansberry at redhat.com



More information about the jbosscache-dev mailing list