Hello,
Fran Varin wrote:
The beauty of our WAS solution is that we can hot deploy various pieces like
the jars without having to do anything with the WARs and since we do not
have the jars contained in each WAR it makes maintenance much simpler.
Depending on the application, this approach makes a lot of sense. We do use
ANT for our builds and such but, the point is to try and simplify the
implementation as much as possible.
There are two points: HotDeploy is something most useful in development
and test environments. For
a production environment it may make sense but is not so important.
Before you are looking for a solution to reduce the points of change for
jar consider:
- the shared code (jar) is made and tested for use in shared use
- there is no third party code used by the homegrown shared code were
you just consider it to be made for shared use,
but you do not know it, and it is not a feature guaranteed by the
producer of the third party lib.
- it is _really_ a headache for you to use ant for deployment in the
test environment and keep control of the jars used by more than
one application.
- you are _sure_ that the time saved by sharing one or more jar(s) by
all applications is not consumed by looking for errors caused by
sharing the jar(s)
Have a look at:
http://wiki.apache.org/jakarta-commons/Logging/UndeployMemoryLeak
Chapter: Keep component libs in components
Regards
Boris
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
