Debugging Java Spring REST service | Segregation of project's business logic and web service implementation in diff jars

This would be a trivial aspect to discuss, but I've been missing out on some specific points related to this while working on a similar requirement.

I had earlier implemented a simple model project (read: P1)based on Spring, JPA API (with JPA repositories)
(Find the implementation details of Spring + JPA nature of P1 in the hyperlink above)
It was followed by implementing a Spring based REST web service (read: P2) on top of the project.

To achieve modularity, some system designs want to control different natures of an application differently. If we can efficiently pluck the web aspect of an application away from the core business logic, it might be a different take on managing RESTful web applications.

This post captures the challenges I faced while implementing the REST part in a separate project 'P2' while importing the model project 'P1' as a jar file in Eclipse IDE deployed on Tomcat server.

Placing P1.jar in the P2's classpath, requires some additional configuration to ensure that all pieces fall in place.


  • Along with the usual <import resource="classpath*:targetConfig.xml"/> , we need to add XML Config in the Spring -> Beans support tab. Also, check the option of 'Enable support for <import/> element in configuration files'




Doing this will have all the spring elements (Spring Beans, JpaRepositories, Service class, DataSource, EntityManagerFactory, TransactionManager) in the current project's context.
  • Ensure the import of beans from the P1's config xml in P2's spring element(which you can see by P2 -> Right click -> Spring Tools -> Add Spring Project Nature)

  • An important yet a very common setup requires providing a default persistence unit in P2's persistence.xml file. While running P2 without specifying the default persistence does capture the persistence unit from P1.jar, but strangely it doesn't capture the related properties of the persistence unit from P1, for example the managed classes listed in P1's persistence unit. Therefore, it becomes sort of a pre-requisite to register a default persistence-unit in P2 too (anybody among the readers, please correct me here if I am missing out on any points).CHECK: If we dont mention the default persistence unit in P2, it won't recognize the managed class from P1's persistence, and while running the Spring REST service, it gives the error: not a managed type.

  • Register spring controller with @RestController and method with @RequestMapping with appropriate RequestType (method=RequestMethod.POST/RequestMethod.GET)

  • Custom RequestBody: While running a POST request, create a custom class containing all the appropriate parameters to be provided as member variables in the class. Use this class as @RequestBody element in the POST request's method
With all these settings in place, fly away with your Spring REST web service!