1

I am using Eclipse Neon and Maven for my development. There are 2 main projects. Project 1 contains all Web services including both SOAP and RESTful. It also has all the database accesses implemented. Project 2 contains the UI which is an Angular implementation. The Angular UI utilizes the RESTful services of project 1 for all data access. The application is packaged into an EAR file containing the WAR files from the two projects. (This is NOT my design!!!)

There are a few Servlet classes in the UI application that handles authorization issues. Up to now the classes in each WAR file were completely independent. Now I need to access data from the database tables from one of the servlet classes. Since that capability is already in Project 1 I should be able to simply utilize the classes in Project 2.

In Eclipse I have both projects in my workspace and have added Project 1 to the build path of Project 2 so I can add the proper objects as needed to Project 2. However, when I try to build Project 2 it can't find the classes from Project 1. I tried adding Project 1 to the export list of Project 2 but that made no difference.

I can provide pom files it necessary.

I just don't know what to try.

Rémi Bantos
  • 1,899
  • 14
  • 27
OldGuy
  • 109
  • 1
  • 2
  • 11
  • 1
    If Project 2 has dependencies on Project 1 you will need to [edit the pom files](http://stackoverflow.com/questions/22438304/intermodule-dependencies-in-maven) to add this dependency. If you need help doing this, I suggest you provide the pom files with superfluous content omitted. (That said, it will be odd for Project 2 to have a compile-time dependency on a project that hosts web services: a web service project should be accessed by its services, not its internal classes.) – DavidS Nov 17 '16 at 22:43
  • I was severely limited by my application's architecture. So I had to abandon what I was trying to do and utilize RESTful services and Servlet calls from Angular. I really appreciated the interest and the input. I would like to provide some feedback regarding some of the responses. Sometimes many of us work for companies that have architects and analysis who decide how things are going to work on that project. The developers can't come along and make changes because they think it would work better. We have to make our changes within the boundaries of that architecture. – OldGuy Dec 22 '16 at 18:24
  • What made it even more difficult in my case is I couldn't change any project configurations within Eclipse. Everything has to be done in the Maven configuration. Which makes it many times more difficult. If it couldn't be accomplished from Maven it wasn't allowed. – OldGuy Dec 22 '16 at 18:30
  • 1
    I had several comments on whether or not what I was working with was the appropriate solution. It didn't matter if it was appropriate or not. I had to make it work within the limitations put on me. It's OK if you can't provide suggestions within those limitations. It's counter productive and frustrating to be criticized for not accepting suggestions that I do not have the power to adapt. Again, I really appreciate the assistance from everyone. – OldGuy Dec 22 '16 at 18:31

1 Answers1

0

One way to share these DB access features in both applications would simply consist in packaging them as common libs within your EAR.

See this maven documentation

Just one remark, IMO it's not a good pattern to have multiple application accessing/modifying the same data model. See this answer on question "Multiple application using one database?" for details.

So perhaps you should consider keeping this data model access logic in the existing first war (which contain REST and SOAP services) and make your second app backend consume a new service from your first app for example?

Another option would be to package all these webapps into a single one (so a single war), providing both UI and backend features (your servlets and APIs together).

Edit: I cannot judge this application design as I could not take a look at it. As pointed out by @David, Generally it's not a bad pattern to have multiple webapps with different purposes, packaged as an EAR or not, even more if these APIs are made for different types of clients (UI, backends, etc...)

Community
  • 1
  • 1
Rémi Bantos
  • 1,899
  • 14
  • 27
  • I totally agree with you. However, this is just one application. Whoever put the project together decided to build it with 2 projects that resulted in 2 war files that are put in one ear file. I totally agree this is a fubar of a design. And I and those on the project at this point can't change that. So we have to work around it. If I could figure out how to tell Maven to include the classes from the services project in the build of the UI war file my problem would be solved. – OldGuy Nov 17 '16 at 18:30
  • You don't need to change the way your application is deployed with the first solution (EAR shared libs). However, I'm curious, what prevent you and your team to change a little bit the design of this application? (By the way I cannot judge its design as I could not take a look at it ;) ) – Rémi Bantos Nov 17 '16 at 19:55
  • 3
    You complain about the design, @OldGuy, but I'm wondering which part of it exactly you don't like. **It sounds like whoever designed this was actually following a good design principle**: your UI code interacts with the business logic through an interface: the web services. If anything, it sounds like you are planning on _breaking_ this good encapsulation by going around the web services to access the database code directly. I think Rémi is correct to suggest you just add a new REST/SOAP service for the servlets to use, but like he also says, we can't really judge the design at this distance. – DavidS Nov 17 '16 at 20:14
  • I don't disagree with the concept of separation of UI and business logic. I am trying to avoid duplication of code. We already have code that does what we want. I'm just trying to get to it. It is all running on the same server so all I should need to do is access the process that returns a specific value from a specific table on the database. That's all I need. Any other solution is 10 times the effort and duplication of code. – OldGuy Nov 17 '16 at 20:48
  • Well, @OldGuy, a new REST service is about [ten lines of code](http://www.adam-bien.com/roller/abien/entry/simplest_possible_rest_endpoint), so I look forward to your one line solution :-). Also, it's not "duplication of code" to provide a public interface to encapsulated functionality. Again though, I don't have your source code, so perhaps this suggestion isn't workable. Good luck. – DavidS Nov 17 '16 at 22:26
  • 1
    @OldGuy, DavidS is right: data access should be the responsibility of Project 1, and the entities you need to access in Project 2 should be exposed through Project 1's SOAP/REST API, rather than by reusing data access classes. I agree that it's a little strange that these two WARs are together in the same EAR, since I'd expect Project 1 to be deployed on your application server as an independent module. If you absolutely must use Project 1's data access classes directly in Project 2, you need to add Project 1 as a dependency in Project 2's POM. – Pablo Napolitano Nov 17 '16 at 22:50