On Oct 24, 2005, at 9:44 AM, Jeff Genender wrote:
Geir Magnusson Jr. wrote:
On Oct 23, 2005, at 6:00 PM, Jeff Genender wrote:
Sachin Patel wrote:
Jacek Laskowski wrote:
Am I right that the simplest solution is to develop a GBean that
would monitor a directory and hand over a deployable to a deployer?
This was my thinking as well. The directory would listen for
adds, modifications, and deletions.
I think this may be somewhat confusing. I think when dropping in
the directory, it should should deploy...then be immediately
removed from the directory.
Eeek. I think you'd want it to remain - helps you figure out what
exactly has been deployed. IOW you can always look in the dir to see
what is supposedly running...
Not necessarily...I think keeping the config store aligned with what
is in this directory will cause more headaches than not. What if the
deployment fails? Then what you have in config store will not match
this directory. This is the problem in having 2 deployment areas. I
really think this needs to be thought through.
Well, directory scanning hot deployment is a really bad idea and
suffers from innumerable problems of this sort and basically cannot be
made to work. I think we should implement something compatible with
other implementations of this bad idea and tell people not to use it.
This means not altering stuff in the hot deploy directory ourselves but
attempting to monitor it. The other major problem is that it is
completely incompatible with j2ee 1.4/jsr-88 separation of plans and
applications. I think we should restrict hot deploy to deploying
archaic applications with plans inside the application.
Just MNSHO :-)
thanks
david jencks
geir
IMHO, this dir should be for hot deploy only. Let the deployer
decide if it should be updated or added. I think the deletions
should not be done through this dir. We should use the normal
undeploy capabilities of the deployer.
Jacek
