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

[Brian Stansberry]

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.

>> However, these modules would never
>> need to be loaded unless configured to do so, therefore this would only
>> bloat the distribution size, not the actual runtime.
>>
>> 4. Drop indexing from the supported infinispan subsystem configuration,
>> reject any such configuration from previous versions of the management
>> api, and force downstream projects to implement indexing support
>> themselves.  This may very well be the "correct" approach, but may not
>> be the most practical one at this stage.  Certainly, if multiple
>> downstream projects require the ability to configuring cache querying,
>> they would benefit from being able to inherit this functionality from a
>> common downstream project.
>>
>> What do people think?
>>
>> Paul
>>
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>
>


-- 
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat