Our team builds and owns a webservices framework. Other teams which actually build the webservices use our framework for some common functionality. There are two options to package the EAR. Option 1 is to have all the framework jars built into the EAR. Option 2 is to configure a shared library in the application server and make all applications use the library. We have potential of upto 100 EARS being deployed, that will use this framework. What are some pros and cons off this approach in terms of build,manageability and development. We are using websphere.
Our team builds and owns a webservices framework. Other teams which actually build the
Share
The basic tradeoff is memory consumption versus version management.
If you package libraries in an EAR, then each application will create its own class instances, consuming some amount of permgen (or equivalent) as well as taking up heap space for static data.
If you store a library in the application lib directory, then there will only be one instance of each class. However, it means that each of the applications using that library must use the same version, and (unless backwards compatibility is ensured) must upgrade at the same time.
Given that you’re talking about 100 EARs, the version management issue is probably going to be big. Unless your library as absolutely huge (and I’m going to assume that you’re running on a 64 bit server with lots of memory, so make that HUGE), or is never going to change (unlikely), I’d suggest packaging with the EAR.