At the start of this conversation I offered the following example of using a mock application context:
GeoServerResourceLoader resourceLoader = new GeoServerResourceLoader(baseDirectory);
ApplicationContext context = createNiceMock(ApplicationContext.class);
expect(context.getBean(“resourceLoader”)).andReturn( resourceLoader );
expect(context.getBeanNamesForType(GeoServerResourceLoader.class)).andReturn(new String{“resourceLoader”}).anyTimes();
expect(context.getBeanNamesForType((Class)anyObject())).andReturn(new String{}).anyTimes();
replay(context);
The only part that is hard to understand is the anyObject → new String entry, basically saying “no” to any unknown singleton lookups.
If you can name a good place to put this boiler plate code I am fine with that.
···
Jody Garnett
On Wed, Apr 23, 2014 at 6:51 AM, Justin Deoliveira <jdeolive@anonymised.com> wrote:
On Tue, Apr 22, 2014 at 2:22 PM, Jody Garnett <jody.garnett@anonymised.com> wrote:
Thanks for the background Kevin, wish I had put this one off (or at least not tied it to the work I am doing). Note this approach is not specific to accessing GeoServerResourceLoader as we have several singletons.
I will move the static init methods to a separate testing GeoServerExtensionsSupport class so we have a way to accomplish what you would like - that does not add to the public API.
Well if it’s easier to throw them on GeoServerExtensions i am ok with that… but cleaner imo would be a helper that makes it easy to mock up or hack the application context directly and then just set that on GeoServerExtensions. You’re call.
–
Justin Deoliveira
Vice President, Engineering | Boundless
jdeolive@anonymised.com
@j_deolive
Jody Garnett
On Wed, Apr 23, 2014 at 5:03 AM, Kevin Smith <ksmith@anonymised.com> wrote:
My suggestion on the pull request was just that the static calls to the GeoServerExtensions singleton might be a problem developing more unitary unit tests (I’d run into the same issue the day before) and it might be worth handling it in a way that made it easier to mock while we were changing things as long as it didn’t add to much work. I was thinking along the lines of just giving the classes protected/package getResourceLoader methods that could be overridden for the objects to be tested. A better way of doing this, or if there already is a way that hidden somewhere would be nice, but it’s not worth holding up the pull request for and I’ve no problem accepting it with the static calls in place.
On 22 April 2014 07:17, Jody Garnett <jody.garnett@anonymised.com> wrote:
Start Your Social Network Today - Download eXo Platform
Build your Enterprise Intranet with eXo Platform Software
Java Based Open Source Intranet - Social, Extensible, Cloud Ready
Get Started Now And Turn Your Intranet Into A Collaboration Platform
http://p.sf.net/sfu/ExoPlatform
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
–
Kevin Smith
Junior Software Engineer | Boundless
ksmith@anonymised.com
+1-778-785-7459
@boundlessgeo
In the current codebase look for any/all examples of GeoserverDataDirectory.setResourceLoader.
Here is an example use from PyCatalogModTest.java:
Previously:
GeoserverDataDirectory.setResourceLoader(scriptMgr.getDataDirectory().getResourceLoader());
The replacement would be:
GeoServerExtensions.init(“resourceLoader”, scriptMgr.getDataDirectory().getResourceLoader() );
This is due to code now using GeoServerExtensions (rather than GeoserverDataDirectory) to look things up.
You’re not being clear about the motivation here, or at least i can’t infer it from this conversation. Can you just point me at a specific test case that Kevin has written.