[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