Hi,
Today we have a framework that user make java code calls to a java API.
Project, a monolith,consists of multiple maven modules but also numerous in-house made java libraries.
The problem today is that each module depends on specific versions of libraries. So when using any of the in-house libraries we cannot just upgrade a dependency since the same must be done for other libraries used in the project.
So what we wish for is a separate deplorable java components that can be managed independently.
I have read about micro-services but they only use rest calls (AFAIK) but we need to make java calls between the different components.
Is it possible? Any hints?
br,
//mike
[...]
So what we wish for is a separate deplorable java components that can be managed independently.
Today we have a framework that user make java code calls to a java
API.
Project, a monolith,consists of multiple maven modules but also
numerous in-house made java libraries.
The problem today is that each module depends on specific versions of libraries. So when using any of the in-house libraries we cannot just
upgrade a dependency since the same must be done for other libraries
used in the project.
So what we wish for is a separate deplorable java components that can
be managed independently.
I have read about micro-services but they only use rest calls (AFAIK)
but we need to make java calls between the different components.
Is it possible? Any hints?
You can only do what you can do.
You can switch to a model with multiple micro-services
that makes network calls to each other.
Or you can stay with a single application and Java
calls.
If you chose the latter then the way to support different versions
of libraries it to switch to a model where each module is loaded
by separate classloaders from separate classpaths.
There are a few options for that. You can go custom. There is
OSGi. Etc..
Arne
You can only do what you can do.
You can switch to a model with multiple micro-services that makes
network calls to each other.
Or you can stay with a single application and Java calls.
If you chose the latter then the way to support different versions
of libraries it to switch to a model where each module is loaded by
separate classloaders from separate classpaths.
There are a few options for that. You can go custom. There is OSGi.
Etc..
Deploy an app as multiple war files, each gets it's own classpath.
They can share code from a common module which packages a copy of a
jar into each war. If they need to share each other's code, it's http
calls, which is normal in the front end code.
On 3/24/2022 2:24 PM, e.d.pro...@gmail.com wrote:
You can only do what you can do.
You can switch to a model with multiple micro-services that makes
network calls to each other.
Or you can stay with a single application and Java calls.
If you chose the latter then the way to support different versions
of libraries it to switch to a model where each module is loaded by
separate classloaders from separate classpaths.
There are a few options for that. You can go custom. There is OSGi.
Etc..
Deploy an app as multiple war files, each gets it's own classpath.A servlet engine also provide the different classloaders, but if
They can share code from a common module which packages a copy of a
jar into each war. If they need to share each other's code, it's http calls, which is normal in the front end code.
a switch from Java calls to HTTP calls is warranted then SpringBoot micro-services is a bit more modern.
Arne
On 3/24/2022 10:46 AM, mike wrote:
[...]
So what we wish for is a separate deplorable java components that can be managed independently.Perhaps I can help: My Java has often been called "deplorable."
:)
--Hi Eric,
eso...@comcast-dot-net.invalid
Look on my code, ye Hackers, and guffaw!
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 300 |
Nodes: | 16 (2 / 14) |
Uptime: | 66:38:59 |
Calls: | 6,712 |
Files: | 12,244 |
Messages: | 5,356,315 |