Loading a partial Spring context - spring

I am not much of a Spring expert, but was given a legacy system with a huge context file (not separated into modules).
I want to add some unit tests - that validates different parts of the system, with the actual production configuration.
I started using the ClassPathXmlApplicationContext/FileSystemXmlApplicationContext classes to load the context, however - that takes forever.
Is it possible to load only parts of the context file (recursively) without the need to separate the original file into modules?
Update:
I'll just post here my implementation of Ralph's solution using maven:
my pom.xml:
<plugin>
<groupId>com.google.code.maven-config-processor-plugin</groupId>
<artifactId>maven-config-processor-plugin</artifactId>
<version>2.0</version>
<configuration>
<namespaceContexts>
<s>http://www.springframework.org/schema/beans</s>
</namespaceContexts>
<transformations>
<transformation>
<input>context.xml</input>
<output>context-test.xml</output>
<config>test-context-transformation.xml</config>
</transformation>
</transformations>
</configuration>
<executions>
<execution>
<goals>
<goal>process</goal>
</goals>
<phase>test</phase>
</execution>
</executions>
</plugin>
my test-context-transformation.xml:
<processor>
<add>
<name>/s:beans</name>
<value>
<![CDATA[
default-lazy-init="true"
]]>
</value>
</add>
</processor>

If you are trying to run "unit" tests, you will not require the full application context at all. Just instantiate the class you want to test (and maybe its collaborators, though mocking may be a better option) and off you go. Unit tests should concentrate on single components in isolation - otherwise they are not unit tests.
If you are trying to run a full integration test by creating the complete object hierarchy defined in your application context, then it may be easiest by first refactoring your context and splitting it into modules - as you were suggesting already.

I guess it does not work out of the box. But you can try this (it is just an idea, I don't know if it works)
Spring support so called lazy initialization the idea is to add this to all the beans.
I can imagine two ways.
A simple tool that create an copy of the orignal configuration xml file and add default-lazy-init="true" the container level beans (with s) declaration.
Try do do it programmatic. With a Bean Post Processor, or try to "inject" the default-lazy-init="true" configuration programmatic

Related

When should I use mapstruct or converters with java 8 to avoid error-prone?

At work, we use MapStruct in many SpringBoot projects with Java 8 REST Full applications and when we need to map Entity to DTO or DTO to Response or in similar cases. But today my friend showed me a great advantage of using a simple Converter instead of MapStruct.
This is a simple example using MapStrurct:
#Mapper(componentModel="spring", unmappedTargetPolicy = ReportingPolicy.IGNORE)
public interface AccountMapper {
#Mapping(source = "customerBank.customerId", target = "customerId")
AccountResponse toResponse(AccountBank accountBank);
}
It works perfectly but actually in the case of someone change the customerId attribute by another name and forgets to change this mapper we will have a Runtime error.
The pros for Converter is we will have a Compile time error and avoid Runtime error.
Please, let me know if someone managed to share how to avoid Runtime error, like my presented scenario, using MapStruct, due to Converter does not bring the same advantage.
My question is: Is it possible to use MapStruct with efficiency, I mean without Runtime error prone?
If I understand well, you would like to have a compile-time error for wrong property naming, using MapStruct custom mapping.
If so, you should add a necessary build plugin in your pom.xml (if you use maven).
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<version>3.5.1</version>
<configuration>
<source>1.8</source>
<target>1.8</target>
<annotationProcessorPaths>
<path>
<groupId>org.mapstruct</groupId>
<artifactId>mapstruct-processor</artifactId>
<version>${mapstruct.version}</version>
</path>
</annotationProcessorPaths>
</configuration>
</plugin>
And of course declare a property for MapStruct version:
<properties>
<mapstruct.version>1.4.1.Final</mapstruct.version>
</properties>
After compiling the project, with the added plugin, the annotation processor will generate full implementation:
public class AccountMapperImpl implements AccountMapper
In target\generated-sources\annotations folder.
You can check generated source of the implementation class, all is set and carefully checked.
In case of unexisting property names in #Mapping annotation, the compiler will throw an error.

Update code generated by Swagger code-gen

I have generated the code from swagger.yaml file using swagger code-gen in spring.
Now I have updated the swagger.yaml file for my API and added few more HTTP operations.
Will it be possible to update the existing code generated previously automatically without merging it manually?
I guess you are talking about the Controllers generated by codegen, that you have then implemented. They are overwritten after each generation, which means you will have to manually merge the code to add the changes every time... which is really annoying.
Well the best workflow I could find was to use the interfaceOnly option to generate only the model and interface classes in the target directory, and then manually create the controllers that implement those interfaces.
Lets say you update your API specification file with one more GET operation, the interface is regenerated with that new operation and you will just have to adjust your controller to implement that new method (super quick and easy with modern IDE), everything else remain the same and you have more control over your code (splitting controllers in different folders...etc...).
Here is config I used for the plugin:
<plugin>
<groupId>io.swagger</groupId>
<artifactId>swagger-codegen-maven-plugin</artifactId>
<version>2.2.3</version>
<executions>
<execution>
<goals>
<goal>generate</goal>
</goals>
<configuration>
<inputSpec>./api-contract/petstore.yml</inputSpec>
<language>spring</language>
<configOptions>
<sourceFolder>swagger</sourceFolder>
<java8>true</java8>
<interfaceOnly>true</interfaceOnly>
</configOptions>
</configuration>
</execution>
</executions>
</plugin>
You can check a complete example project using Spring Boot with swagger-codegen-maven-plugin here.
Cheers
Having the same issue, I found the solution to start with by applying git
commit the current status
run the generator
use git to stage the intended changes but do not stage reversal of your manual edits
commit and continue
I just start with this approach but it seems to work at least for php-slim where only one file (index.php) is changed when regenerating.

How to pass value to maven pom.xml at rum time from java file?

I have a java file where a variable taken value at run time.I search for a service using web service discovery and keep its url in a variable.
Now I need to pass this value to pom.xml.
abc.java has code with
String url= http://xx.xx.xx.xx:55939/ABCDevice?wsdl
Pom.xml is:
<wsdlOptions>
<wsdlOption>
<wsdl>url</wsdl> <!-- get urlvalue from java file -->
<wsdlLocation>classpath:com/admin/discovery/ABCService.wsdl
</wsdlLocation>
</wsdlOption>
</wsdlOptions>
In wsdl i want to pass string value "http://xx.xx.xx.xx:55939/ABCDevice?wsdl" which is determined only after run time.
How can i do so ?
I don't consider this as an Apache Maven specific issue, but a general Java issue (Maven probably made you aware of it).
During build-time you have no idea what the url should be. Depending on the type of application you have several options:
JNDI (in case of a webcontainer)
A properties file on a predefined location
System properties
As arguments (in case of executable jar)
Adjust web.xml before deploying (some webcontainers can help you with this)
...
In you use a framework like Spring there are easy ways to inject one the options above.

How to reuse Spring context when running Ant junit batchtest

I'm in the process of upgrading our application to JUnit4. I've managed to get our test cases up and running using the Spring annotations
#RunWith(SpringJUnit4ClassRunner.class)
#ContextConfiguration
We then execute all tests with Ant using
<junit ...>
<batchtest fork="yes" todir="tmp">
<fileset dir="${testsrc.dir}">
<include name="**/Test*.java"/>
</fileset>
</batchtest>
However, based on our logfiles it appears that the Spring context is re-created for every single test class. Thus, total execution time is way too high. What is the proper approach to have the Spring context only loaded once?
Thanks
Simon Niederberger
Maybe it's because of the fork parameter? Seems like ant is creating a fork for each single test.
I guess normally springs junit runner tries to reuse the context.

How do I control spring injections that vary between the test environment and the production environment?

I'm setting up a CI situation in which I will deploy my web app to a test environment. In this test environment, I want the business objects used by the app to be mocks of the real ones; the mocks will return static test data. I'm using this to run tests agains my ui. I'm controlling the injections of these business object dependencies with Spring; it's a struts 2 application, for what that's worth.
My question is Maven related, I think. What is the best way to have my Maven build determine whether or not to build the spring configuration out for injecting the mocks or injecting the real thing? Is this a good use for maven profiles? Other alternatives?
Spring itself has support for profiles (if you're using 3.1 or newer), for a web-application you can use context-parameter to set the active profile for different environments in the web.xml:
<context-param>
<param-name>spring.profiles.default</param-name>
<param-value>test</param-value>
</context-param>
Edit: For Maven & Jenkins, you should be able to set the parameter for a build job as follows:
First, let Maven filter your xml-resources (in this example, only files ending with xml are filtered, others are included without filtering) by adding the following into your pom.xml inside the <build> </build> -tags:
<resources>
<resource>
<directory>src/main/webapp</directory>
<filtering>true</filtering>
<includes>
<include>**/*xml</include>
</includes>
</resource>
<resource>
<directory>src/main/webapp</directory>
<filtering>false</filtering>
<excludes>
<exclude>**/*xml</exclude>
</excludes>
</resource>
</resources>
Then, parameterize the context-param in your web.xml:
<context-param>
<param-name>spring.profiles.default</param-name>
<param-value>${env.SPRINGPROFILE}</param-value>
</context-param>
Then parameterize the build job in Jenkins to set the desired string parameter for SPRINGPROFILE (for example test or prod): https://wiki.jenkins-ci.org/display/JENKINS/Parameterized+Build
It's probably a bad idea to do anything with the build of the web app artifact ( Maven best practice for generating artifacts for multiple environments [prod, test, dev] with CI/Hudson support? ). While you could use various mechanisms to produce a WAR file with different configurations of the Spring injections for different contexts, the WAR artifact should be the same every time it's built.
In order to extract the configuration out of the WAR, I have used Spring 3's ability to pull in override values from an external property file. I define default, i.e. produciton, values of my business objects. And I configure spring to check for the existence of a properties file, something I will deploy when the app is in a testing environment and requires mock injections. If that properties file exists, it's values are injected instead. Here's the relevent bit of the spring config file.
<!-- These are the default values -->
<util:properties id="defaultBeanClasses">
<prop key="myManagerA">com.myco.ManagerAImpl</prop>
<prop key="myManagerB">com.myco.ManagerBImpl</prop>
</util:properties>
<!-- Pull in the mock overrides if they exist. -->
<context:property-placeholder
location="file:///my/location/mockBeans.properties"
ignore-resource-not-found="true"
properties-ref="defaultBeanClasses"/>
<!-- The beans themselves. -->
<bean id="managerA" class="${myManagerA}"/>
<bean id="managerB" class="${myManagerB}"/>
And here is the contents of the external "mockBeans.properties" file:
#Define mock implementations for core managers
myManagerA=com.myco.ManagerAMockImpl
myManagerB=com.myco.ManagerBMockImpl
This works nicely. You can even include the mockBeans.properties file in the actual WAR, if you like, but not in the live location. Then the test environment task would be too move it to the location pointed at by the spring config. Alternatively, you could have the mock properties reside in a completely different project.

Resources