Re: [jboss-cluster-dev] [Fwd: Re: Infinispan in JBoss AS]
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