Great - precisely what I feel as well.
For now, to solve Jason's PojoCache issue, I'll make sure the config
files are packaged in the test jar.
On 5 Feb 2008, at 19:11, Brian Stansberry wrote:
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)
> Manik Surtani
> Lead, JBoss Cache
> jbosscache-dev mailing list
Lead, AS Clustering
JBoss, a division of Red Hat
Lead, JBoss Cache