Config files

 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
manikjboss.org






_______________________________________________
jbosscache-dev mailing list
jbosscache-devlists.jboss.org
https://lists.jboss.org/mailman/listinfo/jbosscache-dev

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
> manikjboss.org
> 
> 
> 
> 
> 
> 
> _______________________________________________
> jbosscache-dev mailing list
> jbosscache-devlists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jbosscache-dev

-- 
Brian Stansberry
Lead, AS Clustering
JBoss, a division of Red Hat
brian.stansberryredhat.com
_______________________________________________
jbosscache-dev mailing list
jbosscache-devlists.jboss.org
https://lists.jboss.org/mailman/listinfo/jbosscache-dev

Great - precisely what I feel as well.

	http:/
/jira.jboss.org/jira/browse/JBCACHE-1283

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)
>> Thoughts?
>> -- 
>> Manik Surtani
>> Lead, JBoss Cache
>> manikjboss.org
>> _______________________________________________
>> jbosscache-dev mailing list
>> jbosscache-devlists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jbosscache-dev
>
> -- 
> Brian Stansberry
> Lead, AS Clustering
> JBoss, a division of Red Hat
> brian.stansberryredhat.com

--
Manik Surtani
Lead, JBoss Cache
manikjboss.org






_______________________________________________
jbosscache-dev mailing list
jbosscache-devlists.jboss.org
https://lists.jboss.org/mailman/listinfo/jbosscache-dev