On 10 Jul 2009, at 18:25, Jason T. Greene wrote:
Manik Surtani wrote:
> <SNIP />
>> :) It doesn't that much give me the creeps, other than long-term
>> maintainability and support issues. We're talking about different
>> implementations of an SPI; neither JBC nor Infinispan are first
>> class citizens in the AS. Re: maintainability and support, we're
>> talking community AS here. I'd have no problem w/ a JBC-based
>> FIELD in an AS 6.0 marked as a deprecated and replace with an
>> Infinispan based FINE or something in a 6.1/2.
> It was maintenance/backward compat that creeped me out. But yes, I
> suppose you are talking about the community version here. I'd hate
> to see a hybrid setup like this sneak its way in to EAP 6.
My preference is that we just drop HTTP field from AS6, for the
following reasons:
1. It's barely used today (main because the following point)
2. It's a hassle to enable (requires aop precompiling your code)
3. There are other options available (putting leaner objects/
primitives in the session)
4. The use-case is going to be less common with the modern EE6
frameworks (@SessionScoped 299 beans, and @StatefulSession ejb3 beans)
In any case, we probably definitely don't want it in EAP6 since we
then have to support it for 5 years.
Good point. With the AOP guys now shifting focus as well, I think
we'd be asking for trouble trying to support POJOCache for another 5
years on EAP 6.
IMO We should focus on getting Infinispan doing normal replication
for AS6, and we can always add it in a 6.x release. It's also fine
if that 6.x release becomes a EAP 6.1. So let's not rush this.
+1.
Cheers
--
Manik Surtani
manik(a)jboss.org
Lead, Infinispan
Lead, JBoss Cache
http://www.infinispan.org
http://www.jbosscache.org