Thanks Daniele,
the problem was solved with a copy to a mangled name then move (rename), but
that was the clue,
Bill.
----- Original Message -----
From: "Daniele Arduini" <[EMAIL PROTECTED]>
To: "Orion-Interest" <[EMAIL PROTECTED]>
Sent: Tuesday, April 17, 2001 5:30 AM
Subject: Re: remote deployment, how?
> Hi Bill,
> please, see comments inline:
>
> Bill Winspur wrote:
> >
> > I dont like the underscore prefixing either, particularly in my
development
> > environment.
> >
> > At present, on my development wkstation, I manually replace the ear file
in
> > orion/applications while the server is running. This triggers
auto-unpack
> > and redeploy without underscore renaming. Previously, I used
the -deploy
> > option of the admin.jar utility which does result in underscore
renaming.
> >
> > Slamming an ear into the running server like this does avoid renaming
> > behavior, but I've found that it does not work on all our development
> > wkstations, for reasons I have not nailed down. In some cases,
auto-unpack
> > fails with a diagnostic like 'zip file format error', when the file is
> > flawless. The work-around in that case is to stop the server replace
the
> > ear file in orion/applications and then startup the server.
> >
>
> I guess the auto-unpack fails because the file isn't totally
> transferred when Orion try to use it.
> The simple work-around is to copy it to a temporary filename and
> then rename it to the real .ear.
> See below for a better (IMHO) solution for deploy an application.
>
> > I intend to put the work around into our ant deployment script (let it
stop
> > and startup orion) but have not done so yet. I've used admin.jar across
the
> > network ok, so given a shared file system, this klunky approach should
work
> > as a remote deployment technique for enterprise apps that does not
result in
> > underscore renaming.
> >
> > For our initial production application, the *shutdown, replace ear,
startup*
> > approach will probably be
> > an acceptable protocol that fits into our weekly change-management
process.
> > For subsequent, high availability applications we will probably be
looking
> > at another server for production, unless Orion has a more convenient
> > hot-deploy capability by then.
> >
>
> Thers is no need to use the Orion's "-admin" option to deploy an
> application. I usually rely on the auto-deploy feature of Orion
> which trigger timestamp changes on the .ear file.
> A remote deployment is easy if you use the "rsync" utility
> (http://rsync.samba.org) that provides fast incremental file transfer
> over the network.
> Rsync mangle the file name until the trasfer is complete so there is
> non need to perform an additional rename of the file or a restart
> of the server.
>
> For better security you can tunnel the rsync traffic over an encrypted
> channel with "ssh" (http://openssh.org).
>
> This is the ant target I use for remote (or local) deployment:
>
> <target name="deploy" depends="all">
> <exec failonerror="true" executable="rsync">
> <arg line="-azv -e ssh" />
> <arg value="${app-ear.file}" />
> <arg value="${deploy.app-ear.dir}" />
> </exec>
> </target>
>
> Hope this helps.
>
> Regards,
> Daniele Arduini
>
>
> --
> Daniele Arduini <[EMAIL PROTECTED]>
> CINETICA s.r.l.
> via III settembre, 11 - 47891 Dogana (Repubblica di San Marino)
> TEL: (+39) 0549 970848
> FAX: (+39) 0549 970849
> FAX: (+39) 02 700 443 884
>
>
