|A shower and breakfast later
|
|Of course I am working across NFS, and the clock on my
|laptop is screwed.
|
|However this does make it look like JBoss is comparing
|file times against it's own clock, rather than against
|the time that the file was last seen modified at.
|
|In many environmen
OK, OK,
A shower and breakfast later
Of course I am working across NFS, and the clock on my
laptop is screwed.
However this does make it look like JBoss is comparing
file times against it's own clock, rather than against
the time that the file was last seen modified at.
In many environment
Something screwed here :
[jules@zeuglodon jetty]$ touch ~/deploy/jetty-plugin.sar
[jules@zeuglodon jetty]$ ls -l ~/deploy/jetty-plugin.sar
-rw-rw-r--1 julesjules 532190 Apr 11 07:07
/home/jules/deploy/jetty-plugin.sar
[jules@zeuglodon jetty]$ touch ~/deploy/jetty-plugin.sar
[jules@ze
Typical,
This was definitely not working for the jetty-service.xml that I was playing
with last night, but this morning everything sems fine
If I can nail it down I'll let you know.
Jules
David Jencks wrote:
> On 2002.04.10 17:32:35 -0400 Jules Gosnell wrote:
> >
> > I was under the i
On 2002.04.10 17:32:35 -0400 Jules Gosnell wrote:
>
> I was under the impression that the deploer was meant to redeploy files
> in ./deploy that changed.
>
> i.e. I could over a new version of a .sar, or edit and update e.g.
> jetty-service.xml and the service would be restarted with the new
> c
You should not have to removed, a simple touch should do... unless there is a
bug (either in the deployment system or your filsystem =)
--jason
Quoting Jules Gosnell <[EMAIL PROTECTED]>:
>
> I was under the impression that the deploer was meant to redeploy files
> in ./deploy that changed.
>
I was under the impression that the deploer was meant to redeploy files
in ./deploy that changed.
i.e. I could over a new version of a .sar, or edit and update e.g.
jetty-service.xml and the service would be restarted with the new
classes/configuration.
It seems that I have to remove the file a
