-1

I need your sage counsel on the following scenario that I would like to implement.

I have a class that interfaces with a persistence layer (an ERP system) with a JAR dependency (in fact JAR and a DLL :() let's call him DaButler. What I'd like to do is to put it into its own webapps directory in Tomcat and make its services available to any/all other projects (let's call them project Abuser1, Abuser2 etc) on that particular Tomcat (8.5 at the moment) instance. Can you please let me know

  1. If you have done this and have some code to share. :)
  2. What are my options and the pros and cons of each.
  3. Since the primary purpose of the persistence layer interface is to retrieve data and hand it over to the caller. Would each and every bean need to be defined in both projects? Meaning DaButler and Abuser1?

Here are the options that I considered and rejected. I don't want to explain why as it might confuse things too much. At least for the moment.

  1. Make DaButler a JAR and include it with every project.
  2. Turn DaButler into a REST Service.

Lastly here are a couple of options that I thought might work but I have never tried.

  1. Writing a custom class loader. If I do this and load DaButler in my Abuser1 project will the dependencies of DaButler get loaded also?

  2. Also thought about using Tomcats Shared classloader. However, I see that it is missing from Tomcat 8 documentation, which makes me very nervous. :O If it is still an option and will work would love some code examples

Thank you in advance.

LAC

Improve this question
3
  • This seems like a bad idea; the first suggestion of making it a JAR is the correct way to do this. If you actually share the same file between different projects, you (a) have to upgrade everything at the same time if make a breaking change to the API, and (b) if you end up moving one (or more) projects to a different server, or spin up more instances to handle higher load, you have extra work to do to set up the shared JAR. Why are you against this approach? Commented Feb 15, 2021 at 17:59
  • Thank you James. However, as I mentioned in my original post making it a JAR is not an option ;) as it will completely defeat the purpose of what I'm trying to accomplish. If you have more thoughts on why you think this is a bad idea, I'm listening. Commented Feb 15, 2021 at 19:53
  • 1
    This is starting to sound like a classic XY problem now. Commented Feb 16, 2021 at 12:04

2 Answers 2

Reset to default
0

In your description it sounds like, you are trying to interface with an external (and non-JavaEE) system. The ERP provides a JAR and a DLL.

Are these two different ERP client libraries or are both needed? And how exactly does the JAR (and/or DLL) connect to the ERP. For, example it is a CORBA/IIOP client, a proprietary TCP/IP client, etc.

The more text-book Java EE what to do this is that the connection to EIS (Enterprise Information System) and other non-javaee stuff should usually be done by a JCA adaptor (RAR file)

A JCA has the hooks to allow the application server to manage connections and transactions and user login and all that stuff. I've had several projects where we needed to build a JCA module around some proprietary interface.

you would need more than a tomcat, however, it only implements the web container. GF/Payara/Geronimo/Wildfly, etc.

However, i have also seen people build connections like this just by adding the JAR to the shared libs. Sometimes there are issues with cross-talk between instances, or stability problems if the client library doesn't play nice with your application server. but often its workable.

Improve this answer
4
  • Thank you Chris for your input. Here are the answers to your questions. 1. You are absolutely correct. The ERP system in a non Java entity and the library that allows Java to interface with the ERP system is called SAP JCO and it consists of the JAR file for the Java side and the DLL for the Windows side. (Linux is also supported although this is completely irrelevant :) 2. Both libraries are required, as they are essentially 2 halves of one. 3. Thank you I will check into this JCA Adapter idea to see if it will work for me. Commented Feb 21, 2021 at 18:42
  • The issues with my current architecture are not necessarily show stoppers but are annoying. 3.1 The JCO library does not allow me to manage the connections. So that makes it impossible for me to reboot just the Application in which I use the library. I have to Reboot Tomcat itself. Which as I said is annoying as it messes up sessions of people doing work. :( Commented Feb 21, 2021 at 18:44
  • 3.2 Currently I have to use the library individually for each project where I need it. Placing it centrally in the Tomcat libs directory created issues. It almost seems like this library was designed for the world of Applications and I shoehorned it into the world of Servlets etc. Commented Feb 21, 2021 at 18:45
  • 1
    3.3 Considering things stated above there is obviously code duplication. :( It's not obscene but it is there. 3.4 Having said all of the above I must confess that I'm starting to have cold feet about this whole idea of mine. Simply because even though I will gain everything above, whenever I make any change in my code I may be forced to test EVERY system that uses it, if I want to make sure that the change is good. I think that may be a bit too big of a bite for me to swallow. Commented Feb 21, 2021 at 18:45
1

A web container can only do this if you put it in the shared library folder for the container itself, that is outside the WAR deployment itself.

The advantages are small and in my opinion are outweighed by the disadvantages.

  • WAR files are no longer self-contained but require a suitably prepared web container for each and every usage, including the web container running with your IDE.
  • You are now restricted to a single version of DaButler on that web container (this is pretty much the scenario that web containers were created to handle properly). This might bite you badly when you reach production and you reach a situation where an update to one application breaks another.
  • You cannot update DaButler without restarting the whole web container and all its deployments, resulting in much longer downtime than otherwise necessary.

I would recommend against it. You may want to make DaButler a separate web deployment and speak rest to it as you suggest. You might also just treat DaButler as a traditional dependency and just include it in your deployment. If all the usages are collected together you might also consider an application server instead which can deploy EAR files which specifically can do this. Look for one that supports the Java EE Web Profile (https://en.wikipedia.org/wiki/Jakarta_EE#Web_profile).

If this is still a toy project, you can try working with it for a bit and see for yourself if this works out for you.

Improve this answer
4
  • Thank you Thorbjørn. What are the disadvantages that you were thinking of? Commented Feb 15, 2021 at 19:55
  • @LostAndConfused Added some thoughts to the answer. Commented Feb 16, 2021 at 10:39
  • I think the WEB Service like model would be the model I was going to follow anyway. Meaning Abuser1 and Abuser2 and so would interface with a corresponding servlet on the DaButler side, and not be connecting to the DaButler directly. However, what I was really looking to win was not have to convert the objects from JSON/XML to a bean and in reverse. I was hoping to just pass the Bean Classes back and forth without having to either Serialize them or convert them to JSON/XML. Commented Feb 16, 2021 at 17:48
  • This is really starting to sound like an X-Y problem. I would suggest you open a new question describing in more detail what problem you actually need to solve. Commented Feb 16, 2021 at 19:04

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.