On 10/24/05, Jeff Genender <[EMAIL PROTECTED]> 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.
How about a deploy dir and if any deployments fail they get moved into
a dir inside the deploy dir named failed (deploy/failed)?
I agree this is very unsophisticated but it's also not our call on
*why* someone should or shouldn't do something. I have to believe that
there must be some way to accomplish this and simply bypass the
sophistication of the jsr-88 contracts (i.e., if you want jsr-88 style
of state tracking then use the deploy tool).
Bruce
--
perl -e 'print unpack("u30","D0G)[EMAIL
PROTECTED]&5R\"F)R=6-E+G-N>61E<D\!G;6%I;\"YC;VT*"
);'
The Castor Project
http://www.castor.org/
Apache Geronimo
http://geronimo.apache.org/
