raj londonboy

I have got all this sorted now. I was sending mock response null which was leading to test failures. Its working for me now.

Working Context Loader:

package com.idna.dm.qa.controllers; import org.springframework.beans.factory.support.BeanDefinitionReader; import org.springframework.beans.factory.xml.XmlBeanDefinitionReader; import org.springframework.context.ConfigurableApplicationContext; import org.springframework.context.annotation.AnnotationConfigUtils; import org.springframework.context.support.GenericApplicationContext; import org.springframework.core.io.FileSystemResourceLoader; import org.springframework.mock.web.MockServletContext; import org.springframework.test.context.ContextLoader; import org.springframework.test.context.support.AbstractContextLoader; import org.springframework.web.context.WebApplicationContext; import org.springframework.web.context.support.GenericWebApplicationContext; /** * A Spring {@link ContextLoader} that establishes a mock Servlet environment and {@link WebApplicationContext} * so that Spring MVC stacks can be tested from within JUnit. */ public class MockWebApplicationContextLoader extends AbstractContextLoader { private final static GenericWebApplicationContext webApplicationContext = new GenericWebApplicationContext(); @Override public final ConfigurableApplicationContext loadContext(String... locations) throws Exception { // Establish the servlet context and config based on the test class's MockWebApplication annotation. final MockServletContext servletContext = new MockServletContext("/webapp", new FileSystemResourceLoader()); servletContext.setAttribute(WebApplicationContext.ROOT_WEB_APPLICATION_CONTEXT_ATTRIBUTE, webApplicationContext); // final MockServletConfig servletConfig = new MockServletConfig(servletContext, configuration.name()); webApplicationContext.setServletContext(servletContext); createBeanDefinitionReader(webApplicationContext).loadBeanDefinitions(locations); AnnotationConfigUtils.registerAnnotationConfigProcessors(webApplicationContext); // Prepare the context. webApplicationContext.refresh(); webApplicationContext.registerShutdownHook(); return webApplicationContext; } protected BeanDefinitionReader createBeanDefinitionReader(final GenericApplicationContext context) { return new XmlBeanDefinitionReader(context); } public static WebApplicationContext getInstance() { return webApplicationContext; } @Override protected String getResourceSuffix() { return "-context.xml"; } }

Hi Jignesh,

I am running in the same problem now. have you got any resolution for the same??

It will be great if you can share the solution if you got any?

Cheers,
Raj

Thanks Tommy and Javin.

I think I got sufficient arguments and will be able to take decision on that basis:

Most of IDE gives warning for not using * - Its a standard

Code loses expressiveness

The compilation process can take even more time with a wildcard import statement

For improved readability, wildcard import statements are bad practice for anything

Any standard Java library doesn't contain wildchars in java files. - Apache and Sun libraries

The inconvenient aspects of explicit imports are minimized with modern IDEs. Most IDEs allow you to collapse the import section so it's not in the way, automatically populate imports when needed, and automatically identify unused imports to help clean them up.

Another explanation :Example

Thanks everyone once again for your inputs.

Tommy Delson wrote:If you use more than 10 classes in the same package I'd use the Wildcard, otherwise, use specific class name as much as possible for clarity and readable codes.

The choice is yours...

So, you mean if you are using java.util package which is having more than 10 classes, you prefer using java.util.* in java files.

Thanks eveyone for their valuable input. I read very interesting excerpt from the book "clean code" by Martin C which mentions something like:

From Clean Code, p307:


" J1: Avoid Long Import Lists by Using Wildcards
If you use two or more classes from a package, then import the whole package with
import package.*;

Long lists of imports are daunting to the reader. We don’t want to clutter up the tops of our
modules with 80 lines of imports. Rather we want the imports to be a concise statement
about which packages we collaborate with.

Specific imports are hard dependencies, whereas wildcard imports are not. If you specifically
import a class, then that class must exist. But if you import a package with a wildcard,
no particular classes need to exist. The import statement simply adds the package to
the search path when hunting for names. So no true dependency is created by such
imports, and they therefore serve to keep our modules less coupled.

There are times when the long list of specific imports can be useful. For example, if
you are dealing with legacy code and you want to find out what classes you need to build
mocks and stubs for, you can walk down the list of specific imports to find out the true
qualified names of all those classes and then put the appropriate stubs in place. However,
this use for specific imports is very rare. Furthermore, most modern IDEs will allow you
to convert the wildcarded imports to a list of specific imports with a single command. So
even in the legacy case it’s better to import wildcards.

Wildcard imports can sometimes cause name conflicts and ambiguities. Two classes
with the same name, but in different packages, will need to be specifically imported, or at
least specifically qualified when used. This can be a nuisance but is rare enough that using
wildcard imports is still generally better than specific imports."


What is your recommendation after reading this??

Thanks Komal for the reply. With that said, it also doesn't make any sense to have 60-70 import statements in java file (Coding standard).

I was wondering if importing files using "*" make any difference on compile time when we have to build lot many projects on CI servers??

What is the disadvantage of using "*" in an import statements? Any perfect reply please!!!