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.

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


--

Brian Stansberry
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