Welcome to the JavaRanch, Rafafele! I suppose that you probably could do that. However, sharing classes between multiple webapps isn't a practice that is encouraged. There are major cost advantages in simply building the shared classes into a library (JAR) and including a copy of that jar into the WEB-INF/lib directory of each WAR that uses them. It's easier for junior developers to understand, easier to build and maintain, and you don't have to worry about cross-application memory corruption. The cost of the extra resources to duplicate the library is far less than the cost savings seen by using the simpler approach.
The next most-favored solution, where there is actual state sharing between apps is to put the shared code and resources into an independent webapp and have all the other webapps interact with it by making internal HTTP URL requests - making it a web service, in other words. This is only slightly harder for juniors to understand. There is additional overhead, since the interactions have to be coded into and out of HTTP and internal network channels are used, but it's not usually a serious problem and you can scale this solution to work in clustered servers or offload its load to a secondary server.
Before getting to the complications of meddling directly with classpaths and classloaders, there's a third option. You can put the common code into a JAR and put the JAR into the TOMCAT/lib directory. This is how the JDBC drivers work when using Connection Pools. It's not an ideal solution, because in theory, every webapp should be self-contained and not expect non-standard classes in its server classpath - by doing that you destroy the ability to easily port apps because the server has to be pre-configured. There are also other considerations in that these classes are truly common to all webapps in the server, so they need to be careful that they can be safely shared by multiple asynchronous threads.
I would seriously consider the above options before settling on something more complicated.
As far as the hostname goes, a truly evil person like myself could walk Tomcat's internals and extract the name of the Host configuration element, but I'd not do so if I could at all help it - it makes the code useless on any other server but Tomcat, and it can break if Tomcat's internals are restructured in a future release. And such things do happen at the worst possible times, I can assure you. If I want a hostname, it's far safer to obtain it on a per-request basis from incoming HTTPRequest objects. If I wanted to configure it into a webapp, I'd probably make it an Environment object. Aside from being less dependent on internal structures, not all Hosts have the same local hostname as the hostname they use on the open network - especially if there's a reverse proxy server fronting Tomcat.
When it comes to destroying a civilization, gas chambers cannot hold a candle to echo chambers.
posted 1 year ago
Thanks for your reply.
Unfortunatelly I can't change this choice and I'm finding a way "to save goat and cabbage".
Thank's in advance.