6:40 a.m.
Hi,
one of our efforts around EDG testing is to test whether all XML
elements/attributes being set in standalone.xml take effect, i.e.
whether org.infinispan.config.Configuration, which in turn is used to
create caches, is populated properly based on the xml config file.
(this test goal is mentioned in our testplan - second row -
https://docspace.corp.redhat.com/docs/DOC-79912)
I think one possible way to test this would be to start EDG with certain
config. defined in standalone.xml and look at how it was really
configured via JMX. There's a JIRA I reported last week which shows that
this is not working currently
(https://issues.jboss.org/browse/ISPN-1443). Would there be a chance to
make it work? Or has this ever been working?
If anyone has any thoughts how to test this in a different way, they can
tell me. The problem is that we're testing client-server mode where we
cannot access AdvancedCache and so on, so getting the real configuration
is hard (if possible at all).
Thanks for your thoughts
--
Martin Gencur
--
JBoss QE, Enterprise Data Grid
Desk phone: +420 532 294 192, ext. 62192
8:12 a.m.
On 13 Oct 2011, at 12:40, Martin Gencur wrote:
Hi,
one of our efforts around EDG testing is to test whether all XML
elements/attributes being set in standalone.xml take effect, i.e.
whether org.infinispan.config.Configuration, which in turn is used to
create caches, is populated properly based on the xml config file.
(this test goal is mentioned in our testplan - second row -
https://docspace.corp.redhat.com/docs/DOC-79912)
I think one possible way to test this would be to start EDG with certain
config. defined in standalone.xml and look at how it was really
configured via JMX. There's a JIRA I reported last week which shows that
this is not working currently
(https://issues.jboss.org/browse/ISPN-1443). Would there be a chance to
make it work? Or has this ever been working?
Looking at
CacheImpl.getConfigurationAsXmlString -> this *should* work based on some changes
introduced in 5.0.0 final: https://issues.jboss.org/browse/ISPN-948
Perhaps Pete can keep an eye on this as part of rewriting the configuration parsing?
If anyone has any thoughts how to test this in a different way, they can
tell me. The problem is that we're testing client-server mode where we
cannot access AdvancedCache and so on, so getting the real configuration
is hard (if possible at all).
11:40 a.m.
What is the use case for that method? I've never know anyone actually want to export a
running config as XML. So I was planning to loose it.
It would be far better to interrogate the cache state and behavior and check the config
has actually taken effect. Full integration testing is considerably more powerful than
anemic unit tests.
I know EDG doesn't officially support it, but there is no chance of installing a
servlet that can access the AdvancedCache and then using e.g. REST to interrogate it.
On 13 Oct 2011, at 14:12, Mircea Markus wrote:
On 13 Oct 2011, at 12:40, Martin Gencur wrote:
> Hi,
> one of our efforts around EDG testing is to test whether all XML
> elements/attributes being set in standalone.xml take effect, i.e.
> whether org.infinispan.config.Configuration, which in turn is used to
> create caches, is populated properly based on the xml config file.
> (this test goal is mentioned in our testplan - second row -
> https://docspace.corp.redhat.com/docs/DOC-79912)
>
> I think one possible way to test this would be to start EDG with certain
> config. defined in standalone.xml and look at how it was really
> configured via JMX. There's a JIRA I reported last week which shows that
> this is not working currently
> (https://issues.jboss.org/browse/ISPN-1443). Would there be a chance to
> make it work? Or has this ever been working?
Looking at CacheImpl.getConfigurationAsXmlString -> this *should* work based on some
changes introduced in 5.0.0 final: https://issues.jboss.org/browse/ISPN-948
Perhaps Pete can keep an eye on this as part of rewriting the configuration parsing?
>
> If anyone has any thoughts how to test this in a different way, they can
> tell me. The problem is that we're testing client-server mode where we
> cannot access AdvancedCache and so on, so getting the real configuration
> is hard (if possible at all).
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
12:06 p.m.
On 14 Oct 2011, at 17:40, Pete Muir wrote:
What is the use case for that method? I've never know anyone
actually want to export a running config as XML. So I was planning to loose it.
This
option originated was initially requested by a community member [1] who needed it.
There's also Martin's use case and I'm not sure how that can be tested
differently.
It would be far better to interrogate the cache state and behavior and check the config
has actually taken effect. Full integration testing is considerably more powerful than
anemic unit tests.
I know EDG doesn't officially support it, but there is no chance of installing a
servlet that can access the AdvancedCache and then using e.g. REST to interrogate it.
[1]https://issues.jboss.org/browse/ISPN-948
12:20 p.m.
As I said, for Martin, it's better to test the cache functionality (end-to-end
testing) vs unit testing this.
This is going to be a lot harder to support as we move away from JAXB. It would be better
to make an inspector or reporter for the cache config imo.
On 14 Oct 2011, at 18:06, Mircea Markus wrote:
On 14 Oct 2011, at 17:40, Pete Muir wrote:
> What is the use case for that method? I've never know anyone actually want to
export a running config as XML. So I was planning to loose it.
This option originated was initially requested by a community member [1] who needed it.
There's also Martin's use case and I'm not sure how that can be tested
differently.
>
> It would be far better to interrogate the cache state and behavior and check the
config has actually taken effect. Full integration testing is considerably more powerful
than anemic unit tests.
>
> I know EDG doesn't officially support it, but there is no chance of installing a
servlet that can access the AdvancedCache and then using e.g. REST to interrogate it.
[1]https://issues.jboss.org/browse/ISPN-948
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
3:06 a.m.
On Fri, Oct 14, 2011 at 7:40 PM, Pete Muir <pmuir(a)redhat.com> wrote:
What is the use case for that method? I've never know anyone
actually want to export a running config as XML. So I was planning to loose it.
It may be useful to take the configuration out of a cache configured
in AS' ISPN subsystem and run it in standalone mode to isolate bugs...
Cheers
Dan
7:12 a.m.
On 17 Oct 2011, at 09:06, Dan Berindei wrote:
On Fri, Oct 14, 2011 at 7:40 PM, Pete Muir <pmuir(a)redhat.com>
wrote:
> What is the use case for that method? I've never know anyone actually want to
export a running config as XML. So I was planning to loose it.
>
It may be useful to take the configuration out of a cache configured
in AS' ISPN subsystem and run it in standalone mode to isolate bugs...
I would have thought a xslt transform would be better here, especially as it can be run
without container being up.
3:37 a.m.
On Fri, 2011-10-14 at 17:40 +0100, Pete Muir wrote:
What is the use case for that method? I've never know anyone
actually want to export a running config as XML. So I was planning to loose it.
It would be far better to interrogate the cache state and behavior and check the config
has actually taken effect. Full integration testing is considerably more powerful than
anemic unit tests.
I know EDG doesn't officially support it, but there is no chance of installing a
servlet that can access the AdvancedCache and then using e.g. REST to interrogate it.
How do you mean this? EDG currently doesn't support deploying
applications into it. And even if I was able to do this I wouldn't get
to the advanced cache because I'm accessing the cache remotely - using
RemoteCache.
On 13 Oct 2011, at 14:12, Mircea Markus wrote:
>
> On 13 Oct 2011, at 12:40, Martin Gencur wrote:
>
>> Hi,
>> one of our efforts around EDG testing is to test whether all XML
>> elements/attributes being set in standalone.xml take effect, i.e.
>> whether org.infinispan.config.Configuration, which in turn is used to
>> create caches, is populated properly based on the xml config file.
>> (this test goal is mentioned in our testplan - second row -
>> https://docspace.corp.redhat.com/docs/DOC-79912)
>>
>> I think one possible way to test this would be to start EDG with certain
>> config. defined in standalone.xml and look at how it was really
>> configured via JMX. There's a JIRA I reported last week which shows that
>> this is not working currently
>> (https://issues.jboss.org/browse/ISPN-1443). Would there be a chance to
>> make it work? Or has this ever been working?
> Looking at CacheImpl.getConfigurationAsXmlString -> this *should* work based on
some changes introduced in 5.0.0 final: https://issues.jboss.org/browse/ISPN-948
> Perhaps Pete can keep an eye on this as part of rewriting the configuration parsing?
>
>>
>> If anyone has any thoughts how to test this in a different way, they can
>> tell me. The problem is that we're testing client-server mode where we
>> cannot access AdvancedCache and so on, so getting the real configuration
>> is hard (if possible at all).
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Martin Gencur
--
JBoss QE, Enterprise Data Grid
Desk phone: +420 532 294 192, ext. 62192
7:11 a.m.
On 17 Oct 2011, at 09:37, Martin Gencur wrote:
On Fri, 2011-10-14 at 17:40 +0100, Pete Muir wrote:
> What is the use case for that method? I've never know anyone actually want to
export a running config as XML. So I was planning to loose it.
>
> It would be far better to interrogate the cache state and behavior and check the
config has actually taken effect. Full integration testing is considerably more powerful
than anemic unit tests.
>
> I know EDG doesn't officially support it, but there is no chance of installing a
servlet that can access the AdvancedCache and then using e.g. REST to interrogate it.
>
How do you mean this? EDG currently doesn't support deploying
applications into it.
Understood, however I wasn't sure if this was actually prohibited or not...
And even if I was able to do this I wouldn't get
to the advanced cache because I'm accessing the cache remotely - using
RemoteCache.
I was talking about creating a second connection.
> On 13 Oct 2011, at 14:12, Mircea Markus wrote:
>
>>
>> On 13 Oct 2011, at 12:40, Martin Gencur wrote:
>>
>>> Hi,
>>> one of our efforts around EDG testing is to test whether all XML
>>> elements/attributes being set in standalone.xml take effect, i.e.
>>> whether org.infinispan.config.Configuration, which in turn is used to
>>> create caches, is populated properly based on the xml config file.
>>> (this test goal is mentioned in our testplan - second row -
>>> https://docspace.corp.redhat.com/docs/DOC-79912)
>>>
>>> I think one possible way to test this would be to start EDG with certain
>>> config. defined in standalone.xml and look at how it was really
>>> configured via JMX. There's a JIRA I reported last week which shows that
>>> this is not working currently
>>> (https://issues.jboss.org/browse/ISPN-1443). Would there be a chance to
>>> make it work? Or has this ever been working?
>> Looking at CacheImpl.getConfigurationAsXmlString -> this *should* work based
on some changes introduced in 5.0.0 final: https://issues.jboss.org/browse/ISPN-948
>> Perhaps Pete can keep an eye on this as part of rewriting the configuration
parsing?
>>
>>>
>>> If anyone has any thoughts how to test this in a different way, they can
>>> tell me. The problem is that we're testing client-server mode where we
>>> cannot access AdvancedCache and so on, so getting the real configuration
>>> is hard (if possible at all).
>>
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Martin Gencur
--
JBoss QE, Enterprise Data Grid
Desk phone: +420 532 294 192, ext. 62192
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
3:02 p.m.
Pete,
Although https://issues.jboss.org/browse/ISPN-791 task is for 5.2 can we
somehow ensure we are talking these requirements into account!
Thank you,
Vladimir
8:30 a.m.
Gotcha. We'll need to somehow mark those config elements which need to be consistent
(e.g. numOwners) vs that which needs to be different (e.g. rackId).
On 17 Oct 2011, at 21:02, Vladimir Blagojevic wrote:
Pete,
Although https://issues.jboss.org/browse/ISPN-791 task is for 5.2 can we
somehow ensure we are talking these requirements into account!
Thank you,
Vladimir
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
5196
days inactive
5201
days old
infinispan-dev@lists.jboss.org
11 comments
5 participants
participants (5)
-
Dan Berindei -
Martin Gencur -
Mircea Markus -
Pete Muir -
Vladimir Blagojevic