You are viewing a plain text version of this content. The canonical link for it is here.
Posted to imperius-dev@incubator.apache.org by Erik Bengtson <er...@jpox.org> on 2008/01/09 15:57:13 UTC
Usage of InstanceInfo in Decision blocks does not work
I have this code:
Import Class org.eclipse.hyades.logging.events.cbe.CommonBaseEvent:event;
...
Policy
{
...
Decision
{
RaiseAlarm(event,"alarmname",...)
}
When the Policy is evaluated, the RaiseAlarm action is created with a
[null,"alarmname",...].
An initial analysis demonstrates that Import variables (event) are not
considered by the PrimaryExpression, so it throws
an SPLException and when the compilation/evaluation of the Decision Block
occurs, the expression is actually null.
To change this situation, I've changed the PrimaryExpression.validate and
PrimaryExpression.evaluate methods.
In the changed PrimaryExpression validate and evaluate method, I first check for
an existing symbol, via symbolExists
and if it does, work with it, otherwise try getInstance, and if none of these
exists throw symbol does not exist
Please comment, and I provide a patch if desired
Re: test cases
Posted by Filip at Apache <fh...@apache.org>.
don't sweat it :)
as with everything the ASF does, it does in public, takes a while to get
used to,
Filip
Neeraj Joshi wrote:
> Hey All,
> Sorry for my ignorance I wasn't aware that this is highly discouraged!
> I'll stick to posting on the list.
> Thanks
> Neeraj
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> "Those are my principles. If you don't like them I have others."
>
> http://incubator.apache.org/imperius
>
> Neeraj Joshi
> Autonomic Computing Policy Development
> Tivoli, IBM
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
>
>
> Filip at Apache <fh...@apache.org>
> 01/10/2008 11:45 AM
> Please respond to
> imperius-dev@incubator.apache.org
>
>
> To
> imperius-dev@incubator.apache.org
> cc
>
> Subject
> Re: test cases
>
>
>
>
>
>
> Neeraj Joshi wrote:
>
>> Hi Erik,
>> So the sample policies were designed as test cases to test the major
>> features of SPL.
>> That was one of the reasons why they were part of the JavaSPL module
>> initially (shipping them as samples was an after thought).
>> We have a couple of 'ComputerSystem' related polices those are more
>>
> like
>
>> samples (and there are no junit tests associated with them)
>>
>> I agree that pure unit tests that don't require visual inspection would
>>
> be
>
>> ideal but IMO its a non-trivial task. If you like we can setup
>>
> conference
>
>> calls to discuss this in more detail?
>>
>>
> you don't wanna do that, not good for the community. even IRC is
> questionable, but more acceptable as you can post the log here.
> the thing with both calls and IRC, you can't make any decisions (none
> that are valid), so what ever you discuss, you need to bring back here,
> if there needs to be a decision made
> try to do as much as you can over the mailing lists
>
> Filip
>
>> Thanks
>> Neeraj
>>
>>
>>
>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>> "Those are my principles. If you don't like them I have others."
>>
>> http://incubator.apache.org/imperius
>>
>> Neeraj Joshi
>> Autonomic Computing Policy Development
>> Tivoli, IBM
>>
>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>
>>
>>
>> "Erik Bengtson" <er...@jpox.org>
>> 01/09/2008 03:25 PM
>> Please respond to
>> imperius-dev@incubator.apache.org
>>
>>
>> To
>> <im...@incubator.apache.org>
>> cc
>>
>> Subject
>> test cases
>>
>>
>>
>>
>>
>>
>> Hi,
>>
>> I'm promised to provide some test cases, but in the form the tests are
>> coded
>> now, you can only recognize failures by visual means. Secondly, the
>>
> tests
>
>> are not appropriately structured. See:
>>
>> Splcore has main classes and unit tests. OK
>> Javaspl has main classes. OK
>> JavaSPL-Samples has sample policies and sample API usage. It also has
>>
> unit
>
>> tests, but these can only be validated visually.
>>
>> I propose moving the tests from JavaSPL-Samples to JavaSPL, since
>>
> samples
>
>> should only contain samples, and rewrite these tests using junit
>> assertions.
>>
>> I can patch those, but if beforehand you can review/apply the patches in
>> JIRA it's great.
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> ------------------------------------------------------------------------
>>
>> No virus found in this incoming message.
>> Checked by AVG Free Edition.
>> Version: 7.5.516 / Virus Database: 269.17.13/1214 - Release Date:
>>
> 1/8/2008 1:38 PM
>
>
>
>
>
> ------------------------------------------------------------------------
>
> No virus found in this incoming message.
> Checked by AVG Free Edition.
> Version: 7.5.516 / Virus Database: 269.19.0/1216 - Release Date: 1/9/2008 10:16 AM
>
Re: test cases
Posted by Neeraj Joshi <jn...@us.ibm.com>.
Hey All,
Sorry for my ignorance I wasn't aware that this is highly discouraged!
I'll stick to posting on the list.
Thanks
Neeraj
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"Those are my principles. If you don't like them I have others."
http://incubator.apache.org/imperius
Neeraj Joshi
Autonomic Computing Policy Development
Tivoli, IBM
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Filip at Apache <fh...@apache.org>
01/10/2008 11:45 AM
Please respond to
imperius-dev@incubator.apache.org
To
imperius-dev@incubator.apache.org
cc
Subject
Re: test cases
Neeraj Joshi wrote:
> Hi Erik,
> So the sample policies were designed as test cases to test the major
> features of SPL.
> That was one of the reasons why they were part of the JavaSPL module
> initially (shipping them as samples was an after thought).
> We have a couple of 'ComputerSystem' related polices those are more
like
> samples (and there are no junit tests associated with them)
>
> I agree that pure unit tests that don't require visual inspection would
be
> ideal but IMO its a non-trivial task. If you like we can setup
conference
> calls to discuss this in more detail?
>
you don't wanna do that, not good for the community. even IRC is
questionable, but more acceptable as you can post the log here.
the thing with both calls and IRC, you can't make any decisions (none
that are valid), so what ever you discuss, you need to bring back here,
if there needs to be a decision made
try to do as much as you can over the mailing lists
Filip
> Thanks
> Neeraj
>
>
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> "Those are my principles. If you don't like them I have others."
>
> http://incubator.apache.org/imperius
>
> Neeraj Joshi
> Autonomic Computing Policy Development
> Tivoli, IBM
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
>
>
> "Erik Bengtson" <er...@jpox.org>
> 01/09/2008 03:25 PM
> Please respond to
> imperius-dev@incubator.apache.org
>
>
> To
> <im...@incubator.apache.org>
> cc
>
> Subject
> test cases
>
>
>
>
>
>
> Hi,
>
> I'm promised to provide some test cases, but in the form the tests are
> coded
> now, you can only recognize failures by visual means. Secondly, the
tests
> are not appropriately structured. See:
>
> Splcore has main classes and unit tests. OK
> Javaspl has main classes. OK
> JavaSPL-Samples has sample policies and sample API usage. It also has
unit
> tests, but these can only be validated visually.
>
> I propose moving the tests from JavaSPL-Samples to JavaSPL, since
samples
> should only contain samples, and rewrite these tests using junit
> assertions.
>
> I can patch those, but if beforehand you can review/apply the patches in
> JIRA it's great.
>
>
>
>
>
>
>
>
>
>
> ------------------------------------------------------------------------
>
> No virus found in this incoming message.
> Checked by AVG Free Edition.
> Version: 7.5.516 / Virus Database: 269.17.13/1214 - Release Date:
1/8/2008 1:38 PM
>
Re: test cases
Posted by Filip at Apache <fh...@apache.org>.
Neeraj Joshi wrote:
> Hi Erik,
> So the sample policies were designed as test cases to test the major
> features of SPL.
> That was one of the reasons why they were part of the JavaSPL module
> initially (shipping them as samples was an after thought).
> We have a couple of 'ComputerSystem' related polices those are more like
> samples (and there are no junit tests associated with them)
>
> I agree that pure unit tests that don't require visual inspection would be
> ideal but IMO its a non-trivial task. If you like we can setup conference
> calls to discuss this in more detail?
>
you don't wanna do that, not good for the community. even IRC is
questionable, but more acceptable as you can post the log here.
the thing with both calls and IRC, you can't make any decisions (none
that are valid), so what ever you discuss, you need to bring back here,
if there needs to be a decision made
try to do as much as you can over the mailing lists
Filip
> Thanks
> Neeraj
>
>
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> "Those are my principles. If you don't like them I have others."
>
> http://incubator.apache.org/imperius
>
> Neeraj Joshi
> Autonomic Computing Policy Development
> Tivoli, IBM
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
>
>
> "Erik Bengtson" <er...@jpox.org>
> 01/09/2008 03:25 PM
> Please respond to
> imperius-dev@incubator.apache.org
>
>
> To
> <im...@incubator.apache.org>
> cc
>
> Subject
> test cases
>
>
>
>
>
>
> Hi,
>
> I'm promised to provide some test cases, but in the form the tests are
> coded
> now, you can only recognize failures by visual means. Secondly, the tests
> are not appropriately structured. See:
>
> Splcore has main classes and unit tests. OK
> Javaspl has main classes. OK
> JavaSPL-Samples has sample policies and sample API usage. It also has unit
> tests, but these can only be validated visually.
>
> I propose moving the tests from JavaSPL-Samples to JavaSPL, since samples
> should only contain samples, and rewrite these tests using junit
> assertions.
>
> I can patch those, but if beforehand you can review/apply the patches in
> JIRA it's great.
>
>
>
>
>
>
>
>
>
>
> ------------------------------------------------------------------------
>
> No virus found in this incoming message.
> Checked by AVG Free Edition.
> Version: 7.5.516 / Virus Database: 269.17.13/1214 - Release Date: 1/8/2008 1:38 PM
>
RE: test cases
Posted by Erik Bengtson <er...@jpox.org>.
Test cases implemented using junit tests running policies with assertions on
return values.
I will try to reproduce all scenario that failed with null pointers etc. I
think most of them were solved with PrimaryExpression fix.
Secondly, I want to ensure enough coverage before the custom expressions XML
patch.
-----Message d'origine-----
De : Neeraj Joshi [mailto:jneeraj@us.ibm.com]
Envoyé : jeudi 10 janvier 2008 19:41
À : imperius-dev@incubator.apache.org
Objet : Re: test cases
Hey Erik,
Can you give a brief overview of what you plan to contribute in terms of
the test cases. I am not very clear. Are you referring to Apache
guidelines for testing?
Thanks
Neeraj
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"Those are my principles. If you don't like them I have others."
http://incubator.apache.org/imperius
Neeraj Joshi
Autonomic Computing Policy Development
Tivoli, IBM
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"Erik Bengtson" <er...@jpox.org>
01/10/2008 02:27 AM
Please respond to
imperius-dev@incubator.apache.org
To
"Imperius" <im...@incubator.apache.org>
cc
Subject
Re: test cases
Neeraj,
As you said It might be a good idea to keep samples and policy files based
test cases in the samples project.
Let me know if this is aligned to the testing guidelines so I go ahead
with tests changes.
Erik
-- BlackBerry® from Mobistar ---
-----Original Message-----
From: Kevan Miller <ke...@gmail.com>
Date: Thu, 10 Jan 2008 00:00:17
To:imperius-dev@incubator.apache.org
Subject: Re: test cases
On Jan 9, 2008, at 5:54 PM, Craig L Russell wrote:
> Hi Neeraj,
>
> On Jan 9, 2008, at 2:44 PM, Neeraj Joshi wrote:
>
>> Hi Erik,
>> So the sample policies were designed as test cases to test the major
>> features of SPL.
>> That was one of the reasons why they were part of the JavaSPL module
>> initially (shipping them as samples was an after thought).
>> We have a couple of 'ComputerSystem' related polices those are more
>> like
>> samples (and there are no junit tests associated with them)
>>
>> I agree that pure unit tests that don't require visual inspection
>> would be
>> ideal but IMO its a non-trivial task. If you like we can setup
>> conference
>> calls to discuss this in more detail?
>
> Conference calls tend to be problematic with Apache projects. They
> are difficult to set up due to time zone issues; no decisions can be
> made; anything discussed has to be published on the dev alias so
> everyone can participate.
>
> Basically, it's best just to use this dev alias for discussions...
Seconding Craig's advice...
--kevan
Re: test cases
Posted by Neeraj Joshi <jn...@us.ibm.com>.
Hey Erik,
Can you give a brief overview of what you plan to contribute in terms of
the test cases. I am not very clear. Are you referring to Apache
guidelines for testing?
Thanks
Neeraj
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"Those are my principles. If you don't like them I have others."
http://incubator.apache.org/imperius
Neeraj Joshi
Autonomic Computing Policy Development
Tivoli, IBM
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"Erik Bengtson" <er...@jpox.org>
01/10/2008 02:27 AM
Please respond to
imperius-dev@incubator.apache.org
To
"Imperius" <im...@incubator.apache.org>
cc
Subject
Re: test cases
Neeraj,
As you said It might be a good idea to keep samples and policy files based
test cases in the samples project.
Let me know if this is aligned to the testing guidelines so I go ahead
with tests changes.
Erik
-- BlackBerry® from Mobistar ---
-----Original Message-----
From: Kevan Miller <ke...@gmail.com>
Date: Thu, 10 Jan 2008 00:00:17
To:imperius-dev@incubator.apache.org
Subject: Re: test cases
On Jan 9, 2008, at 5:54 PM, Craig L Russell wrote:
> Hi Neeraj,
>
> On Jan 9, 2008, at 2:44 PM, Neeraj Joshi wrote:
>
>> Hi Erik,
>> So the sample policies were designed as test cases to test the major
>> features of SPL.
>> That was one of the reasons why they were part of the JavaSPL module
>> initially (shipping them as samples was an after thought).
>> We have a couple of 'ComputerSystem' related polices those are more
>> like
>> samples (and there are no junit tests associated with them)
>>
>> I agree that pure unit tests that don't require visual inspection
>> would be
>> ideal but IMO its a non-trivial task. If you like we can setup
>> conference
>> calls to discuss this in more detail?
>
> Conference calls tend to be problematic with Apache projects. They
> are difficult to set up due to time zone issues; no decisions can be
> made; anything discussed has to be published on the dev alias so
> everyone can participate.
>
> Basically, it's best just to use this dev alias for discussions...
Seconding Craig's advice...
--kevan
Re: test cases
Posted by Erik Bengtson <er...@jpox.org>.
Neeraj,
As you said It might be a good idea to keep samples and policy files based test cases in the samples project.
Let me know if this is aligned to the testing guidelines so I go ahead with tests changes.
Erik
-- BlackBerry® from Mobistar ---
-----Original Message-----
From: Kevan Miller <ke...@gmail.com>
Date: Thu, 10 Jan 2008 00:00:17
To:imperius-dev@incubator.apache.org
Subject: Re: test cases
On Jan 9, 2008, at 5:54 PM, Craig L Russell wrote:
> Hi Neeraj,
>
> On Jan 9, 2008, at 2:44 PM, Neeraj Joshi wrote:
>
>> Hi Erik,
>> So the sample policies were designed as test cases to test the major
>> features of SPL.
>> That was one of the reasons why they were part of the JavaSPL module
>> initially (shipping them as samples was an after thought).
>> We have a couple of 'ComputerSystem' related polices those are more
>> like
>> samples (and there are no junit tests associated with them)
>>
>> I agree that pure unit tests that don't require visual inspection
>> would be
>> ideal but IMO its a non-trivial task. If you like we can setup
>> conference
>> calls to discuss this in more detail?
>
> Conference calls tend to be problematic with Apache projects. They
> are difficult to set up due to time zone issues; no decisions can be
> made; anything discussed has to be published on the dev alias so
> everyone can participate.
>
> Basically, it's best just to use this dev alias for discussions...
Seconding Craig's advice...
--kevan
Re: test cases
Posted by Kevan Miller <ke...@gmail.com>.
On Jan 9, 2008, at 5:54 PM, Craig L Russell wrote:
> Hi Neeraj,
>
> On Jan 9, 2008, at 2:44 PM, Neeraj Joshi wrote:
>
>> Hi Erik,
>> So the sample policies were designed as test cases to test the major
>> features of SPL.
>> That was one of the reasons why they were part of the JavaSPL module
>> initially (shipping them as samples was an after thought).
>> We have a couple of 'ComputerSystem' related polices those are more
>> like
>> samples (and there are no junit tests associated with them)
>>
>> I agree that pure unit tests that don't require visual inspection
>> would be
>> ideal but IMO its a non-trivial task. If you like we can setup
>> conference
>> calls to discuss this in more detail?
>
> Conference calls tend to be problematic with Apache projects. They
> are difficult to set up due to time zone issues; no decisions can be
> made; anything discussed has to be published on the dev alias so
> everyone can participate.
>
> Basically, it's best just to use this dev alias for discussions...
Seconding Craig's advice...
--kevan
Re: test cases
Posted by Craig L Russell <Cr...@Sun.COM>.
Hi Neeraj,
On Jan 9, 2008, at 2:44 PM, Neeraj Joshi wrote:
> Hi Erik,
> So the sample policies were designed as test cases to test the major
> features of SPL.
> That was one of the reasons why they were part of the JavaSPL module
> initially (shipping them as samples was an after thought).
> We have a couple of 'ComputerSystem' related polices those are
> more like
> samples (and there are no junit tests associated with them)
>
> I agree that pure unit tests that don't require visual inspection
> would be
> ideal but IMO its a non-trivial task. If you like we can setup
> conference
> calls to discuss this in more detail?
Conference calls tend to be problematic with Apache projects. They
are difficult to set up due to time zone issues; no decisions can be
made; anything discussed has to be published on the dev alias so
everyone can participate.
Basically, it's best just to use this dev alias for discussions...
Craig
>
> Thanks
> Neeraj
>
>
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> "Those are my principles. If you don't like them I have others."
>
> http://incubator.apache.org/imperius
>
> Neeraj Joshi
> Autonomic Computing Policy Development
> Tivoli, IBM
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
>
>
> "Erik Bengtson" <er...@jpox.org>
> 01/09/2008 03:25 PM
> Please respond to
> imperius-dev@incubator.apache.org
>
>
> To
> <im...@incubator.apache.org>
> cc
>
> Subject
> test cases
>
>
>
>
>
>
> Hi,
>
> I'm promised to provide some test cases, but in the form the tests are
> coded
> now, you can only recognize failures by visual means. Secondly, the
> tests
> are not appropriately structured. See:
>
> Splcore has main classes and unit tests. OK
> Javaspl has main classes. OK
> JavaSPL-Samples has sample policies and sample API usage. It also
> has unit
> tests, but these can only be validated visually.
>
> I propose moving the tests from JavaSPL-Samples to JavaSPL, since
> samples
> should only contain samples, and rewrite these tests using junit
> assertions.
>
> I can patch those, but if beforehand you can review/apply the
> patches in
> JIRA it's great.
>
>
>
>
>
>
>
>
Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!
Re: test cases
Posted by Neeraj Joshi <jn...@us.ibm.com>.
Hi Erik,
So the sample policies were designed as test cases to test the major
features of SPL.
That was one of the reasons why they were part of the JavaSPL module
initially (shipping them as samples was an after thought).
We have a couple of 'ComputerSystem' related polices those are more like
samples (and there are no junit tests associated with them)
I agree that pure unit tests that don't require visual inspection would be
ideal but IMO its a non-trivial task. If you like we can setup conference
calls to discuss this in more detail?
Thanks
Neeraj
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"Those are my principles. If you don't like them I have others."
http://incubator.apache.org/imperius
Neeraj Joshi
Autonomic Computing Policy Development
Tivoli, IBM
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"Erik Bengtson" <er...@jpox.org>
01/09/2008 03:25 PM
Please respond to
imperius-dev@incubator.apache.org
To
<im...@incubator.apache.org>
cc
Subject
test cases
Hi,
I'm promised to provide some test cases, but in the form the tests are
coded
now, you can only recognize failures by visual means. Secondly, the tests
are not appropriately structured. See:
Splcore has main classes and unit tests. OK
Javaspl has main classes. OK
JavaSPL-Samples has sample policies and sample API usage. It also has unit
tests, but these can only be validated visually.
I propose moving the tests from JavaSPL-Samples to JavaSPL, since samples
should only contain samples, and rewrite these tests using junit
assertions.
I can patch those, but if beforehand you can review/apply the patches in
JIRA it's great.
test cases
Posted by Erik Bengtson <er...@jpox.org>.
Hi,
I'm promised to provide some test cases, but in the form the tests are coded
now, you can only recognize failures by visual means. Secondly, the tests
are not appropriately structured. See:
Splcore has main classes and unit tests. OK
Javaspl has main classes. OK
JavaSPL-Samples has sample policies and sample API usage. It also has unit
tests, but these can only be validated visually.
I propose moving the tests from JavaSPL-Samples to JavaSPL, since samples
should only contain samples, and rewrite these tests using junit assertions.
I can patch those, but if beforehand you can review/apply the patches in
JIRA it's great.
Re: Usage of InstanceInfo in Decision blocks does not work
Posted by Neeraj Joshi <jn...@us.ibm.com>.
Hi Erik,
You are right about the imported variables not being considered by the
primary expression. Looking forward to your patch
Thanks
Neeraj
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"Those are my principles. If you don't like them I have others."
http://incubator.apache.org/imperius
Neeraj Joshi
Autonomic Computing Policy Development
Tivoli, IBM
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Erik Bengtson <er...@jpox.org>
01/09/2008 10:57 AM
Please respond to
imperius-dev@incubator.apache.org
To
imperius-dev@incubator.apache.org
cc
Subject
Usage of InstanceInfo in Decision blocks does not work
I have this code:
Import Class org.eclipse.hyades.logging.events.cbe.CommonBaseEvent:event;
...
Policy
{
...
Decision
{
RaiseAlarm(event,"alarmname",...)
}
When the Policy is evaluated, the RaiseAlarm action is created with a
[null,"alarmname",...].
An initial analysis demonstrates that Import variables (event) are not
considered by the PrimaryExpression, so it throws
an SPLException and when the compilation/evaluation of the Decision Block
occurs, the expression is actually null.
To change this situation, I've changed the PrimaryExpression.validate and
PrimaryExpression.evaluate methods.
In the changed PrimaryExpression validate and evaluate method, I first
check for
an existing symbol, via symbolExists
and if it does, work with it, otherwise try getInstance, and if none of
these
exists throw symbol does not exist
Please comment, and I provide a patch if desired