> Good morning Rickard,
>
> I was playing around with that problem yesterday night. The -remove
> everything you dont need anymore- works fine, so the J2eeDeployer would
> be ready for that (not in cvs yet).
>
> There I found an other thing: when a MBean service is stopped and I call
> one of its business methods it behaves as if it would run. I didnt have
> a look at the spec but my feeling says this has to raise an exception?!
> Or happens that only (or at all) after service.destroy()?
Start/stop of service is only from a logical point of view. There are no
restrictions on calls before/after.
> Hmmm... you re right.
> The other stuff (deployed via the web interface) would work (and _does_
> as I tested yesterday).
>
> So it seems the AutoDeployer is the key...
>
> > Hm... maybe the AutoDeployer should store the list of deployments with
> > last modified timestamps. That would work! Then it could just read it
> > back up when it is restarted and see if the timestamp has changed or
> > not!
>
> but I m not a friend of saving state data that is always something that
> can break I like it more implizit ;-)
> I could imagine to save the timestamp on the J2eeDeployer side (where we
> save some metainfo anyway) and add a method like:
> Time/Date/long(?) deployedSince (URL) throws Excepiton
Hm...I prefer not... (and if you do it at least call it getLastModified()).
> We experienced such funny stuff at SMB where we had our home dirs on nfs
> and you changed something (on your maschine) and than you try to compile
> it on an other maschine with make and this maschines clock istnt set
> properly... bla bla)
>
> But the approach of saving only _one_ metadata I like more.
>
> What do you think (or anyone else)?
I think the only good way is to have the AD store metadata ;-)
/Rickard
