You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Neeme Praks <ne...@inpoc.com> on 2001/11/01 04:59:55 UTC
getting configuration from ExcaliburTestCase
I need some configuration data in my TestCases.
What would be the best way to get this?
* First solution would be to write my own configuration loading code using
DefaultConfigurationBuilder. Not very re-usable...
* Second, and more preferable solution would be to add configure() method to
the ExcaliburTestCase class. The default implementation would be to do
nothing. That way we would achieve backward-compatibility and the people who
need to configure their TestCases can get their hands on some configuration
data by overriding the configure() method. Most probably the configuration
data that would be passed to the TestCase would be a separate element in
.xtest file.
Something like this:
<testcase>
.... all the usual stuff used by ExcaliburTestCase ....
<configuration>
.... all the stuff passed to the configure() method ....
</configuration>
</testcase>
Would this be ok, if I would implement this?
Neeme
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: getting configuration from ExcaliburTestCase
Posted by Neeme Praks <ne...@one.ee>.
> -----Original Message-----
> From: Berin Loritsch [mailto:bloritsch@apache.org]
> Sent: Friday, November 02, 2001 10:35 PM
> Subject: Re: getting configuration from ExcaliburTestCase
[...snipped some excellent explanations...]
Thanks for the explanations, that clarified a lot of things.
Going forward, in ExcaliburTestCase javadoc, there is an example
configuration given. Is there somewhere also a some documentation about the
meaning of this configuration markup? I can quess the meaning and use of
some of it, but I'm still in complete darkness about the use of some other
tags. For example:
* what is the use of <hint> element (child element of <role>)?
* how is the <context> element used?
* the whole <logkit> configuration element is quite complicated with the
notion of factories, targets and categories. I more-or-less understand all
of them, but some doc on configuring all of that would be good... but that
could be said about all the documentation, probably :-)
* as I understand, <components> element is used to configure different
instances of components, right?
Neeme
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: getting configuration from ExcaliburTestCase
Posted by Berin Loritsch <bl...@apache.org>.
Neeme Praks wrote:
>
> I just committed an example where this would be useful:
> org.apache.avalon.excalibur.i18n.test.DefaultBundleMatcherTestCase and the
> corresponding .xtest file.
> The issue here is that usually the lifecycle of BundleMatcher
> inplementations would be managed by BundleSelector. However, in the test, I
> don't want to go through BundleSelector, I want to bypass that and test only
> BundleMatcher implementation, not BundleSelector.
If BundleMatcher (or implementation) is a Component, then you should
be able to directly instantiate these. If you don't want to go through
the Selector, then make the roles like this:
BundleMatcher.ROLE + "/test1"
BundleMatcher.ROLE + "/test2"
etc.
You can directly grab them from the the ComponentManager in the ExcaliburTestCase.
> So, AFAISee, my testcase needs to manage the lifecycle and for that I need
> some configuration data...
> If this issue could be solved otherwise, I'm all ears. :-)
If you need to manage your own lifecycle, then you shouldn't be using ExcaliburTestCase.
It's not doing anything for you. Give each BundleMatcher component a unique
role for your test--that will allow the ComponentManager to manage their lifecycle
without having to go through a Selector layer.
> On a similar note, I saw some object factory implementations in excalibur.
> Are there any benefits in favor of using those instead of doing directly
> classForName() in my code (as I'm doing right now in some places)? Would
> they manage the lifecycle for me?
The ComponentHolder class will read your Component class and give you the
proper type of ComponentHolder to manage the lifecycle of your Components
directly.
> What will happen if I lookup a component through manager, would save it
> somewhere and would look up another one. It would return the same instance,
> as there is only one instance per component in manager, correct?
That depends on the LifeStyle interface you implemented. If your class is
ThreadSafe, the component instance is the same. If your class is Poolable,
Recycleable, or SingleThreaded (the default), then chances are you will
get a different instance each time you request. Please note that for
Poolable and Recycleable, if you return the instance you looked up, that
instance will be used again.
> Willing to learn better ways of doing things,
> Neeme
Willing to teach better ways of doing things,
Berin
PS I am also willing to learn...
--
"Those who would trade liberty for
temporary security deserve neither"
- Benjamin Franklin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: getting configuration from ExcaliburTestCase
Posted by Neeme Praks <ne...@apache.org>.
I just committed an example where this would be useful:
org.apache.avalon.excalibur.i18n.test.DefaultBundleMatcherTestCase and the
corresponding .xtest file.
The issue here is that usually the lifecycle of BundleMatcher
inplementations would be managed by BundleSelector. However, in the test, I
don't want to go through BundleSelector, I want to bypass that and test only
BundleMatcher implementation, not BundleSelector.
So, AFAISee, my testcase needs to manage the lifecycle and for that I need
some configuration data...
If this issue could be solved otherwise, I'm all ears. :-)
On a similar note, I saw some object factory implementations in excalibur.
Are there any benefits in favor of using those instead of doing directly
classForName() in my code (as I'm doing right now in some places)? Would
they manage the lifecycle for me?
What will happen if I lookup a component through manager, would save it
somewhere and would look up another one. It would return the same instance,
as there is only one instance per component in manager, correct?
Willing to learn better ways of doing things,
Neeme
PS It would work for everybody.
> -----Original Message-----
> From: Berin Loritsch [mailto:bloritsch@apache.org]
> Sent: Wednesday, October 31, 2001 8:54 PM
> To: Avalon Developers List
> Subject: Re: getting configuration from ExcaliburTestCase
>
>
> Neeme Praks wrote:
> >
> > :-)
> > I understand that the ComponentManager is configured automagically and I
> > don't want to configure that manually.
> > I just want to pass some configuration data into the TestCase itself.
>
> What kind of configuration data? I want to come up with something that
> works for everybody...
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: getting configuration from ExcaliburTestCase
Posted by Berin Loritsch <bl...@apache.org>.
Neeme Praks wrote:
>
> :-)
> I understand that the ComponentManager is configured automagically and I
> don't want to configure that manually.
> I just want to pass some configuration data into the TestCase itself.
What kind of configuration data? I want to come up with something that
works for everybody...
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: getting configuration from ExcaliburTestCase
Posted by Neeme Praks <ne...@one.ee>.
> -----Original Message-----
> From: Berin Loritsch [mailto:bloritsch@apache.org]
> Sent: Wednesday, October 31, 2001 10:10 AM
> To: Avalon Developers List
> Subject: Re: getting configuration from ExcaliburTestCase
>
> > Would this be ok, if I would implement this?
>
> Don't do anything! It is already taken care of.
> ExcaliburTestCase reads the
> configuration information and builds your ComponentManager
> heirarchy for you.
> All you have to do us use it to get your Component instances, and
> test them.
:-)
I understand that the ComponentManager is configured automagically and I
don't want to configure that manually.
I just want to pass some configuration data into the TestCase itself.
Neeme
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: getting configuration from ExcaliburTestCase
Posted by Berin Loritsch <bl...@apache.org>.
Neeme Praks wrote:
>
> I need some configuration data in my TestCases.
>
> What would be the best way to get this?
> * First solution would be to write my own configuration loading code using
> DefaultConfigurationBuilder. Not very re-usable...
> * Second, and more preferable solution would be to add configure() method to
> the ExcaliburTestCase class. The default implementation would be to do
> nothing. That way we would achieve backward-compatibility and the people who
> need to configure their TestCases can get their hands on some configuration
> data by overriding the configure() method. Most probably the configuration
> data that would be passed to the TestCase would be a separate element in
> .xtest file.
>
> Something like this:
> <testcase>
> .... all the usual stuff used by ExcaliburTestCase ....
> <configuration>
> .... all the stuff passed to the configure() method ....
> </configuration>
> </testcase>
>
> Would this be ok, if I would implement this?
Don't do anything! It is already taken care of. ExcaliburTestCase reads the
configuration information and builds your ComponentManager heirarchy for you.
All you have to do us use it to get your Component instances, and test them.
>
> Neeme
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
--
"Those who would trade liberty for
temporary security deserve neither"
- Benjamin Franklin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>