[jboss-cluster-dev] [Fwd: Re: Infinispan in JBoss AS]

[Jason T. Greene]

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.

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.

> 
>> Don't get me wrong; I don't *like* such an approach.
>>
>>>> I would much rather see us drop FIELD if Infinispan could not
>>>> handle that use-case.
>>>>
>>
>> That's an option too. I've been burned before pulling features for a 
>> while while waiting for the next technology to support them, so I'm 
>> cautious. But it's an option. I see very little evidence for much 
>> usage of FIELD.
>>
>>>> So, IMO we need to either wait for the JPA/delta framework, or drop
>>>> FIELD.
>>> If need be I can bump up prio on the JPA/fine grained API for 
>>> Infinispan (e.g., over the memcached/client-server module) which will 
>>> make it quite likely for the end of this (calendar) year.
>>
>> TBH, I'd much prefer that Infinispan focuses on what's right for 
>> standalone Infinispan and not on getting into the AS. AIUI, that was 
>> the strategy.
> 
> Well they both need to happen.  The reason why I prioritised the 
> client/server module over fine grained repl/JPA is simply that it was 
> designed earlier and has had more thought in it.

Also keep in mind that getting the fine-grained interface is only part 
of the puzzle. We also need to spend some time integrating it with EJB3, 
  JCDI (299), and HTTP repl.

-- 
Jason T. Greene
JBoss, a division of Red Hat