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

[Galder Zamarreno]

On 07/10/2009 07:25 PM, 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)

Based on what I remember from my support days, I hardly remember 2/3 
cases on this, so I'd agree that it's hardly used out there.

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

-- 
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache