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

[Paul Ferraro]

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.

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