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(a)jboss.org
_______________________________________________
jbosscache-dev mailing list
jbosscache-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jbosscache-dev
--
Brian Stansberry
Lead, AS Clustering
JBoss, a division of Red Hat
brian.stansberry(a)redhat.com