classnotfoundexception in multi project web application

Question

I'm working on a web application which is in the form of some war files for the JSF2 front end, some jar files for services, and some shared jars to call the services from the front end, eg

webLayer.war -> serviceUtilities.jar -> service.jar

My problem is that when I try to call a service from the front end using my service utilities (which use reflection to call a service class in a separate jar) I get a class not found exception.

I have worked around the problem by changing the scope of the dependencies in my web project pom.xml from provided to compile, but this is not ideal because I have to build all the relevant projects and then build them into my web layer as libraries.

What I want is to have my web layer wars and service layer jars completely separate so that if I change my service I only need to compile that project. But obviously I still want to be able to access the jars from my war.

Can this be done, and if so how?

Thanks in advance

Answer 1

I believe you are trying to achieve total decoupling between your projets but in an unorthodox way.

First of all, using provided , means that while the library is present at compile time, it will not be added to your deployable (the war in this case) because it is assumed to be present in the platform where you deploy. Think of a similar case when using the servlet api but you do not need it as an explicit dependency at runtime because your servlet container provides it. It does not give you decoupling but a way to prevent dependency duplication. So in your case, the web application and serviceUtilities.jar do not know anything about your service.jar at runtime, while they do at compile time.

It is very difficult to be able to access the jars directly as you say (even using reflection - it is still a binary dependency), while keeping the projects' lifecycle independent.

I think the best way to get total decoupling between layers is to use Rest + Json for communication. You may even be able to deploy your layers in separate nodes. As long as the services contract does not change (the rest urls in this case) you are safe to even switch between different implementations or expose multiple front ends
Your serviceUtilities in the web side will then be replaced by code that uses some rest client library and your service layer will also use some rest service provider to listen to your rest urls. Which technology you use depends on your preference and technology stack. Jersey is the reference implementation for JAX-RS, while you can also easily use spring controllers in the provider side.