Hi,Sorry for the delay in getting back to you all.In terms of what I've developed, I have uploaded the development branch here: https://github.com/spaulg/wildfly/tree/feature/redis-support.This includes all changes I've made, which I've recently merged in 10.0.0CR2. I know this won't be added to that release, but it means I can track against a stable and current branch.Regarding Tristan's comment and Tomaz's reply for having subextensions of extensions, what I have developed simply matches the existing approach used by the Remote store. I have created a StoreBuilder, BuilderFactory and ResourceDefinition for the Redis store and registered this in to the XML reader/writer for the Infinispan subsystem. This means when the configuration has a redis-store tag as a cache store that has its own configuration attributes.In terms of the cli/web and the changes that need to be made. I have made all the xsd changes and amending the xml reader/writer for the new store, however its failing unit tests with the error below. I'm not sure why.testDescribeHandler[8](org.jboss.as.clustering.infinispan.subsystem.SubsystemParsingTestCase) Time elapsed: 0.023 sec <<< ERROR!
java.lang.RuntimeException: "WFLYCTL0158: Operation handler failed: java.util.MissingResourceException: Can't find resource for bundle java.util.PropertyResourceBundle, key infinispan.local-cache.redis-store"
at org.jboss.as.subsystem.test.SubsystemTestDelegate.validateDescriptionProviders(SubsystemTestDelegate.java:581)
at org.jboss.as.subsystem.test.SubsystemTestDelegate.access$500(SubsystemTestDelegate.java:118)
at org.jboss.as.subsystem.test.SubsystemTestDelegate$KernelServicesBuilderImpl.build(SubsystemTestDelegate.java:669)
at org.jboss.as.clustering.infinispan.subsystem.SubsystemParsingTestCase.testDescribeHandler(SubsystemParsingTestCase.java:187)Kind regards,SimonOn 8 October 2015 at 16:26, Brian Stansberry <brian.stansberry@redhat.com> wrote:No, not really.
Notions like that have come up a time or two, but I wouldn't say they
are planned.
This seems like primarily a module loading issue. The parent extension
needs to be made aware of the presence of an external module so it can
load classes from it and use those to extend its own management API.
Those classes would implement an SPI provided by the parent extension.
That SPI would be a mix of kernel stuff and stuff specific to the parent
extension
1) specific stuff: things like where "child extension" resources can be
inserted into the parent tree
2) kernel stuff: various support classes / SPIs that all such cases can
use to make these things as consistent as possible.
Brian Stansberry
On 10/8/15 10:06 AM, Tristan Tarrant wrote:
> Actually, let me expand on Simon's request, since this is something I've
> wanted to have from WF: sub-extensions to extensions (or sub-subsystems).
> For this particular use-case, a way for an extension (an Infinispan
> Cache Store) to declare that it is a child of another extension
> (Infinispan). The child extension would be responsible for
> parsing/serializing its own section of the XML, service registration, etc.
> Is this planned ?
>
> Thanks
>
> Tristan
>
> On 08/10/2015 15:29, Tomaž Cerar wrote:
>>
>> On Sat, Sep 26, 2015 at 11:12 PM, Simon Paulger <spaulger@codezen.co.uk
>> <mailto:spaulger@codezen.co.uk>> wrote:
>>
>> I just want to re-iterate this to try and get it ready for the final
>> Wildfly 10 release. In order to make Redis integration, what changes
>> should I be making? In particular;
>>
>> You are too late to get any new feature to 10, CRx build are just
>> bugfixes of existing stuff and no new features are being added anymore.
>>
>>
>> 1. xml reader/writer - should I be adding redis-store as a concrete
>> xml tag?
>> 2. persistence pom updates to add the redis jar dependency
>> 3. xsd documentation updates
>> 4. module configurations
>> 5. jboss-cli - do I need to add a redis-store type to a cache
>> container?
>> 6. web management console - again redis-store type to a cache
>> container?
>>
>>
>> 1,3,5&6 are basically the same thing, you need to add support for
>> redis-store to infinispan subsystem.
>> When that is done correctly, cli is done as well.
>> And once CLI part is done, you can access same stuff via mgmt REST api
>> which console uses.
>> In most cases console doesn't need changes for extra fields / resources,
>> but if it does,
>> you can send change to HAL project once all of the previous points are
>> done and change is merged in WildFly master
>>
>> for general docs about extending WildFly itself look at
>> https://docs.jboss.org/author/display/WFLY10/Extending+WildFly
>>
>>
>>
>> 1 - 3 are done, 4 is in progress, however I am unclear on how to
>> make 5 and 6 (can't find the code locations), and I also want steer
>> on whether a concrete store type is needed or if the custom store
>> should be the way to go, in which case I think only pom updates and
>> module config is required.
>>
>>
>>
>>
>>
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev@lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>
--
Senior Principal Software Engineer
JBoss by Red Hat
_______________________________________________
wildfly-dev mailing list
wildfly-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev
_______________________________________________
wildfly-dev mailing list
wildfly-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev