3:04 p.m.
Hi,
My company uses JBoss AS 7 (before Wildfly I know). We also use Redis cache
store for PHP stacks and I'd like to be able to do the same for Wildfly
(I'm considering upgrade paths).
I see there is an old JIRA enhancement issue raised here:
https://issues.jboss.org/browse/ISPN-3465
I was wondering what the appetite for creating a Redis cache store is. If
this were something I were to develop in both inifinispan and wildfly,
would it be well received by the JBoss community?
Regards,
Simon
3:22 p.m.
On Jul 28, 2015, at 3:04 PM, Simon Paulger
<spaulger(a)codezen.co.uk> wrote:
Hi,
My company uses JBoss AS 7 (before Wildfly I know). We also use Redis cache store for PHP
stacks and I'd like to be able to do the same for Wildfly (I'm considering upgrade
paths).
I see there is an old JIRA enhancement issue raised here:
https://issues.jboss.org/browse/ISPN-3465
<https://issues.jboss.org/browse/ISPN-3465>
I was wondering what the appetite for creating a Redis cache store is. If this were
something I were to develop in both inifinispan and wildfly, would it be well received by
the JBoss community?
Hi Simon,
Thanks for the interest, and it sounds great to me!
I would recommend starting by posting to infinispan-dev your interest in the feature (if
you haven’t already), and they can help you get started. I would imagine the infinispan
memcached code is a good starting point, and may in fact be adaptable to the Redis
protocol, perhaps by forking it.
One thats done there is some integration bits on the WildFly side, but I wouldn’t worry
about that until its shipped in an infinispan release.
Thanks,
--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat
8:38 a.m.
Hi Jason,
I have developed a redis cache store which has now been completed and released under the
infinispan org as part of version 8, available through central.
I had begun to look at what changes would be required under wildfly. I have made changes
to the xml reader and writer for config for a concrete redis-store type but haven't
worked out how to update the web ui and cli.
This got me thinking as to whether a concrete config tag is required at all since there is
always the custom store.
Therefore, I thought I'd check. What changes should I be developing to make my redis
integration in to wildfly 10?
Thanks
Simon
Sent from my iPhone
On 28 Jul 2015, at 21:22, Jason Greene
<jason.greene(a)redhat.com> wrote:
> On Jul 28, 2015, at 3:04 PM, Simon Paulger <spaulger(a)codezen.co.uk> wrote:
>
> Hi,
>
> My company uses JBoss AS 7 (before Wildfly I know). We also use Redis cache store for
PHP stacks and I'd like to be able to do the same for Wildfly (I'm considering
upgrade paths).
>
> I see there is an old JIRA enhancement issue raised here:
https://issues.jboss.org/browse/ISPN-3465
>
> I was wondering what the appetite for creating a Redis cache store is. If this were
something I were to develop in both inifinispan and wildfly, would it be well received by
the JBoss community?
Hi Simon,
Thanks for the interest, and it sounds great to me!
I would recommend starting by posting to infinispan-dev your interest in the feature (if
you haven’t already), and they can help you get started. I would imagine the infinispan
memcached code is a good starting point, and may in fact be adaptable to the Redis
protocol, perhaps by forking it.
One thats done there is some integration bits on the WildFly side, but I wouldn’t worry
about that until its shipped in an infinispan release.
Thanks,
--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat
4:12 p.m.
Hi,
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;
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 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.
Kind regards,
Simon
On 15 September 2015 at 14:38, Simon Paulger <spaulger(a)codezen.co.uk> wrote:
Hi Jason,
I have developed a redis cache store which has now been completed and
released under the infinispan org as part of version 8, available through
central.
I had begun to look at what changes would be required under wildfly. I
have made changes to the xml reader and writer for config for a concrete
redis-store type but haven't worked out how to update the web ui and cli.
This got me thinking as to whether a concrete config tag is required at
all since there is always the custom store.
Therefore, I thought I'd check. What changes should I be developing to
make my redis integration in to wildfly 10?
Thanks
Simon
Sent from my iPhone
On 28 Jul 2015, at 21:22, Jason Greene <jason.greene(a)redhat.com> wrote:
On Jul 28, 2015, at 3:04 PM, Simon Paulger <spaulger(a)codezen.co.uk> wrote:
Hi,
My company uses JBoss AS 7 (before Wildfly I know). We also use Redis
cache store for PHP stacks and I'd like to be able to do the same for
Wildfly (I'm considering upgrade paths).
I see there is an old JIRA enhancement issue raised here:
https://issues.jboss.org/browse/ISPN-3465
I was wondering what the appetite for creating a Redis cache store is. If
this were something I were to develop in both inifinispan and wildfly,
would it be well received by the JBoss community?
Hi Simon,
Thanks for the interest, and it sounds great to me!
I would recommend starting by posting to infinispan-dev your interest in
the feature (if you haven’t already), and they can help you get started. I
would imagine the infinispan memcached code is a good starting point, and
may in fact be adaptable to the Redis protocol, perhaps by forking it.
One thats done there is some integration bits on the WildFly side, but I
wouldn’t worry about that until its shipped in an infinispan release.
Thanks,
--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat
8:29 a.m.
On Sat, Sep 26, 2015 at 11:12 PM, Simon Paulger <spaulger(a)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.
10:06 a.m.
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(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev
--
Tristan Tarrant
Infinispan Lead
JBoss, a division of Red Hat
10:26 a.m.
On Thu, Oct 8, 2015 at 5:06 PM, Tristan Tarrant <ttarrant(a)redhat.com> wrote:
The child extension would be responsible for
parsing/serializing its own section of the XML, service registration, etc.
Is this planned ?
Why plan something that is already doable :-)
Well in a way at least, code that handles certain sub resource can be be
anywhere, even in external module/dependancy.
All infinispan subsystem would need to do is .registerChild(new
CacheStoreResourceDefinitionDefinedInDifferentModule())
well at least as long as you use new parser constructs, this would be
trivial.
otherwise extra wiring for parser would be needed.
We do have similar setup for including parts of threads subsystem in other
subsystems.
--
tomaz
10:26 a.m.
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(a)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(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
--
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat
3:04 p.m.
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,
Simon
On 8 October 2015 at 16:26, Brian Stansberry <brian.stansberry(a)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.
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(a)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(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev
4:23 a.m.
You are missing text description of the key you added.
They are usually stored in LocalDescriptions.properties of your module.
for infinispan subsystem that would probably be in
src/main/resources/org/jboss/as/clustering/infinispan/subsystem/LocalDescriptions.properties
On Sun, Oct 18, 2015 at 10:04 PM, Simon Paulger <spaulger(a)codezen.co.uk>
wrote:
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,
> Simon
On 8 October 2015 at 16:26, Brian Stansberry <brian.stansberry(a)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.
>
> 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(a)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(a)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(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev
3360
days inactive
3443
days old
9 comments
5 participants
participants (5)
-
Brian Stansberry -
Jason Greene -
Simon Paulger -
Tomaž Cerar -
Tristan Tarrant