[wildfly-dev] To bloat or not to bloat...

[David M. Lloyd]

On 11/14/2013 11:33 AM, Paul Ferraro wrote:
> On Thu, 2013-11-14 at 10:47 -0600, Brian Stansberry wrote:
>> On 11/14/13 10:34 AM, Brian Stansberry wrote:
>>> On 11/14/13 10:07 AM, Paul Ferraro wrote:
>>>> While attempting to validate Wildfly against Infinispan master, in
>>>> preparation for the imminent 6.0.0.Final component upgrade, I ran into a
>>>> bit of an issue, the resolution of which is not immediate clear, and,
>>>> while apparently insignificant at first glance, is perhaps more
>>>> appropriately made within the larger context of how we design layered
>>>> projects.
>>>>
>>>> Here the issue.
>>>>
>>>> Sometime in the AS7 release cycle, indexing support was added to the
>>>> Infinispan subsystem.  This was done in response to a request by the
>>>> capedwarf project - the idea being - that, while AS7 would not ship the
>>>> modules required to support querying an infinispan cache, it could at
>>>> least support the ability to configure such a cache.  I'm not sure if
>>>> there are other projects that rely on this functionality - so please
>>>> make yourself known if you are.
>>>>
>>>> In retrospect, this was probably not a good idea.  Indexing should
>>>> probably have been implemented as a separate subsystem, which could
>>>> reference configuration from the infinispan subsystem - but alas, that's
>>>> how it was originally implemented.
>>>>
>>>> The trouble begins with a seemingly innocent jira:
>>>> https://issues.jboss.org/browse/ISPN-3583
>>>> which adds validation within Infinispan itself, where a cache can no
>>>> longer be configured to use indexing unless the requisite module (i.e.
>>>> infinispan-query and its dependencies) is available.
>>>> The consequence of this, however, is that the unit tests that validate
>>>> the parsing and management of indexing configuration is now broken in
>>>> Wildfly, since Wildfly does not ship the requisite modules required to
>>>> validate such a configuration.
>>>>
>>>> So, as I see it, the way forward can take a number of different paths:
>>>>
>>>> 1. Restore the status quo, i.e. remove this validation from Infinispan
>>>> itself.  This still leaves us the the ability to configure an unusable
>>>> cache - since indexing is only useful if the modules required to utilize
>>>> it are available.
>>>>
>>>> 2. Remove the testing of indexing configuration from the Infinispan
>>>> subsystem's unit tests.  This retains all of he disadvantages of #1, and
>>>> additionally results in poorer test coverage, pushes the burden of
>>>> testing this functionality to downstream projects, and will likely
>>>> morally offend some of you.
>>>
>>> A 2.5 is the infinispan subsystem tests could be refactored to separate
>>> out the configs that specify indexing, and run those tests with the
>>> controller set up with AdditionalInitialization.MANAGEMENT. That will
>>> prevent the Stage.RUNTIME execution that is presumably causing the
>>> problem. The Stage.MODEL parts of the management handling will still be
>>> tested though.
>>>
>>> This has all of the disadvantages of your 2, just somewhat less so.
>>>
>>>>
>>>> 3. Add the requisite modules to Wildfly.  This would make downstream
>>>> projects (e.g. capedwarf) happy, but arguably bloats Wildfly
>>>> unnecessarily, given that Wildfly has no internal need for these
>>>> modules, nor this functionality.
>>
>> This opens up the question (aka can of worms) of what exactly is this
>> subsystem?
>>
>> If it's an "infinispan" subsystem, and it supports config of this
>> feature, then WildFly *needs* these modules. Just like we need the
>> modules for any other feature whose explicit config we expose.
>>
>> If it's an "ee-caching" subsystem that's only supposed to be usable as
>> an implementation detail for EJB/web session/JPA caching, then the whole
>> subsystem should probably be renamed, unrelated stuff ripped out, and
>> some separate add-on or something should be created for the "infinispan"
>> subsystem.
>
> My intention has always been the former.
>
> Clearly, such a need for an infinispan subsystem exists, not just to
> support current EE subsystems (i.e. web, ejb, jpa), but uses have
> cropped up in the security subsystem, and will certainly be demanded by
> future EE subsystems, including those to support JSR-107, JSR-347, and
> JSR-350.
>
> However, this doesn't rule out the possibility of option #4.  There are
> plenty of other knobs and switches supported by infinispan that are not
> exposed by the subsystem - simply because no internal requirement, nor
> any request from a downstream projects, has emerged.  The question
> becomes, I think, to what extent should Wildfly facilitate requests from
> downstream projects (e.g. capedwarf, JDG, etc.) to expose this
> functionality?

Another important (if slightly tangential) thing to consider is: how 
easy is it to create configurations which are broken?  Or if you prefer, 
how hard is it to create configurations that are completely correct? 
The more knobs and buttons we expose, the harder it is to ensure 
configuration correctness.

-- 
- DML