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

[Brian Stansberry]

On 11/14/13 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.
>

In that case, and this is JMHO, we should just ship the jars. If you 
think the feature is wrong or not a proper fit for the subsystem, better 
off elsewhere, etc, that's one thing. But if the feature is valid and is 
a proper part of the subsystem, I think not having the jars in the first 
place qualifies as a bug.

> 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?
>
> To be clear, the modules to be added to satisfy #3 include,
> org.infinispan.query, org.hibernate.search and its dependencies,
> including org.apache.lucene and its many dependencies.
> ... hence, the subject line.
>
>>>> 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