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 _______________________________________________ wildfly-dev mailing list wildfly-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/wildfly-dev

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(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev >> > >

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?