[JIRA] Commented: (OSJ-15) InitializationService.initialize() should take close to zero time for mutiple callers (shouldn't it?)

[Brent Putman (JIRA)]

    [ https://issues.shibboleth.net/jira/browse/OSJ-15?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14016#comment-14016 ] 

Brent Putman commented on OSJ-15:
---------------------------------

I think this is (mostly) PEBKAC. :-)  Although there is a larger, more fundamental question...

Ideally, you really only want to init OpenSAML once, for a given suite of tests that you are going to run.  The easiest way to do this is: rather than having each test class do the init in its own annotated method, just inherit from the abstract class org.opensaml.core.OpenSAMLInitBaseTestCase.  That is its whole reason for existence. This works because TestNG optimizes a method annotated with @BeforeSuite so that it is only invoked once, even if it is located within a class which is the superclass of multiple classes being tested.

Note that this is *vastly* different than what we did in 2.x with JUnit.  In JUnit, the superclass's setUp() called DefaultBootstrap.  setUp() is called before *every* test* method.  So we were literally completely bootstrapping OpenSAML thousands of times in the course of running our tests.  I think the "scoping" on the TestNG optimization above is actually going to be on a per-Maven-module basis, but still... we are now just a wee bit more efficient. :-)

You don't strictly speaking *have* to inherit from this class.  As long as the test with the @BeforeSuite is in the set of classes in the test suite, it will execute.  But unless you want to be constantly writing testng.xml files to run individual tests - like running individual tests within Eclipse - the easiest thing to do is just inherit either directly or indirectly from the above class.

There are a couple of other abstract test superclasses, which can be used for more specialized kind of tests:

org.opensaml.core.xml.XMLObjectBaseTestCase - Provides some prepopulated variables and some utility methods for working with XMLObjects.

org.opensaml.core.xml.XMLObjectProviderBaseTestCase - Framework for testing actual XMLObject provider implementation sets.

(I did just discover that one of these was redundantly calling the OpenSAML init, which I forgot to take out during the TestNG conversion. This is unrelated to your issue, just noting in case you saw that check-in).

The larger fundamental question is: should we prevent people from shooting themselves if they call the init more than once; that is, try and make second and subsequent calls essentially no-ops?  I have actually thought about this a bit in the past.  It's possible, but a little tricky b/c of the way the configuration stuff works.  We didn't attempt to prevent this in 2.x, so I have not worried about it so far.  However, I will leave this open for now as a vehicle for officially documenting that we may or may not do.  Unless Chad wants to declare "we are not going to worry about that case".  In which case, we can close... 





> InitializationService.initialize() should take close to zero time for mutiple callers (shouldn't it?)
> -----------------------------------------------------------------------------------------------------
>
>                 Key: OSJ-15
>                 URL: https://issues.shibboleth.net/jira/browse/OSJ-15
>             Project: OpenSAML - Java
>          Issue Type: Improvement
>         Environment: Windoze 7 x64 running from an SSD drive. Eclipse, Java6.22 (64 bit).
>            Reporter: Rod Widdowson
>            Assignee: Brent Putman
>            Priority: Trivial
>
> This is a nice to have, no more, but I think will help the whole project going forward.  If it's PEBKAC or not fixable, then that's fine too.
> I have been doing some IDP testing which depends on OpenSAML and the general mechanism used is to say:
>     @BeforeSuite() public void initOpenSAML() throws InitializationException {
>         InitializationService.initialize();
>         // Other per module set up
>     }
> In each test module.  This means that running an individual test module can take a bit of time but 10 seconds isn't the end of the world.
> I was however surprised that the amount of time taken during initialization goes up as I do more tests since I had expected that the Initialize bit would take zero time the second and third time through.
> So I did a pretty non scientific experiment and called InitializationService.initialize() 11 times in a loop.  
> The first call takes around 12 seconds
> The second and third about 1 second
> And form then on each call takes about 0.4 to 0.6 seconds.
> Like I say this is no big deal, but by the time we are running a thousand tests it is going to suck up a lot of cycles...

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira