RE: remote deployment, how?
A quicker fix for the deployment problem you are having (as in the error with the zip file), is to put a 'touch' task into your ant script. As far as I can assertain, the error is caused when the ear file gets fairly large. When you copy a new ear file over the old one, while the server is still running, it seems that the server detects the new version of the ear file before the file has fully copied. It tries to deploy the semi-copied ear file, and therefore thinks that the zip file is corrupt. If you then touch the ear file (as in update it's timestamp), then orion will then try unpacking it again, and since the ear file has now fully copied, will work correctly. Ant comes with an in-built touch task, and it's solved our deployment problems here. Cheers, Simon Knott -Original Message- From: Bill Winspur [mailto:[EMAIL PROTECTED]] Sent: 17 April 2001 08:15 To: Orion-Interest Subject: Re: remote deployment, how? 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 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. - Original Message - From: "Koster, K.J." [EMAIL PROTECTED] To: "Orion-Interest" [EMAIL PROTECTED] Sent: Friday, April 13, 2001 2:14 PM Subject: remote deployment, how? Dear All, I would like to be able to deploy an .ear remotely (the servers run FreeBSD, some of the development workstations use Windows). I found that admin.jar can do this, and that the new application is indeed uploaded to the server. It is not automatically deployed in place of the old one. What I do now (more or less) is this: java -jar admin.jar ormi://bladibla admin passwd \ -deploy -file doc.ear -deploymentName doc I see that the new file shows up in $ORION/applications, prefixed with an underscore. Repeatedly deploying the same file gives me lots of folders with ever more underscores (_doc, __doc, ___doc, etc), but changes to .jsp files in the .ear are not visible over the web. What I want to do is upload a new version of the application archive in place of the old one, auto-deploying the thing. Question is: how do I do that? Kees Jan You are only young once, but you can stay immature all your life.
RE: remote deployment, how?
A quicker fix for the deployment problem you are having (as in the error with the zip file), is to put a 'touch' task into your ant script. As far as I can assertain, the error is caused when the ear file gets fairly large. When you copy a new ear file over the old one, while the server is still running, it seems that the server detects the new version of the ear file before the file has fully copied. It tries to deploy the semi-copied ear file, and therefore thinks that the zip file is corrupt. If you then touch the ear file (as in update it's timestamp), then orion will then try unpacking it again, and since the ear file has now fully copied, will work correctly. Ant comes with an in-built touch task, and it's solved our deployment problems here. Cheers, Simon -Original Message- From: Bill Winspur [mailto:[EMAIL PROTECTED]] Sent: 17 April 2001 08:15 To: Orion-Interest Subject: Re: remote deployment, how? 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 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. - Original Message - From: "Koster, K.J." [EMAIL PROTECTED] To: "Orion-Interest" [EMAIL PROTECTED] Sent: Friday, April 13, 2001 2:14 PM Subject: remote deployment, how? Dear All, I would like to be able to deploy an .ear remotely (the servers run FreeBSD, some of the development workstations use Windows). I found that admin.jar can do this, and that the new application is indeed uploaded to the server. It is not automatically deployed in place of the old one. What I do now (more or less) is this: java -jar admin.jar ormi://bladibla admin passwd \ -deploy -file doc.ear -deploymentName doc I see that the new file shows up in $ORION/applications, prefixed with an underscore. Repeatedly deploying the same file gives me lots of folders with ever more underscores (_doc, __doc, ___doc, etc), but changes to .jsp files in the .ear are not visible over the web. What I want to do is upload a new version of the application archive in place of the old one, auto-deploying the thing. Question is: how do I do that? Kees Jan You are only young once, but you can stay immature all your life.
RE: remote deployment, how?
Dear Bill, I dont like the underscore prefixing either, particularly in my development environment. Not to mention the rate you go through diskspace on an average working day. :-) 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. Hmmm. I found that -deploy works only for non-root websites when I rebind the web context after -deploy. Root contexts require an Orion restart. This is annoying for our case (four root websites, no non-root ones, Murphy at work?). 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. The .ear auto deployment is very sensitive to clock synchronisation issues. NTP is your friend. I have not seen that "zip file format error", but I imagine that may be due to Orion starting to autodeploy the file before it is fully in place. Using mv instead of cp may help, as long as you're on the same filesystem. 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. I'll probably just stick with FTP instead. These are techs, they should know FTP. Thanks for the tips. I'll hack at amdin.jar a little more later today. Kees Jan You are only young once, but you can stay immature all your life.
RE: remote deployment, how?
Dear Daniele, 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. I like the idea of using rsync. So obvious that I missed it completely. Unfortunately I'm dealing with some non-UNIX development boxes, and rsync does not seem to be available for those. Kees Jan You are only young once, but you can stay immature all your life.
Re: remote deployment, how?
"Koster, K.J." wrote: I like the idea of using rsync. So obvious that I missed it completely. Unfortunately I'm dealing with some non-UNIX development boxes, and rsync does not seem to be available for those. rsync is available for win32 too! Patrick Hess | metazoa GmbH| fon +49-211-175447-15 | | Hohenzollernstr. 34 | fax +49-211-175447-27 | | 40211 Dsseldorf| mail [EMAIL PROTECTED] |
RE: remote deployment, how?
Title: RE: remote deployment, how? I am testing a setup where NT boxes have FTP servers running on them and I will use sitecopy (available for NT and Unix) to mirror the files up to the servers. This should trigger timestamp changes and have Orion do its magic. -Larry -Original Message- From: Koster, K.J. [mailto:[EMAIL PROTECTED]] Sent: Tuesday, April 17, 2001 11:31 AM To: Orion-Interest Subject: RE: remote deployment, how? Dear Daniele, 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. I like the idea of using rsync. So obvious that I missed it completely. Unfortunately I'm dealing with some non-UNIX development boxes, and rsync does not seem to be available for those. Kees Jan You are only young once, but you can stay immature all your life.
Re: remote deployment, how?
Yeah, it might be. Will do. - Original Message - From: "elephantwalker" [EMAIL PROTECTED] To: "Orion-Interest" [EMAIL PROTECTED] Sent: Tuesday, April 17, 2001 1:37 AM Subject: RE: remote deployment, how? Bill, This sounds like a bug. Could you log this in bug-zilla so Magnus et al can get this one fixed? This seems to work for us. Regards, The Elephantwalker -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Bill Winspur Sent: Tuesday, April 17, 2001 12:15 AM To: Orion-Interest Subject: Re: remote deployment, how? 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 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. - Original Message - From: "Koster, K.J." [EMAIL PROTECTED] To: "Orion-Interest" [EMAIL PROTECTED] Sent: Friday, April 13, 2001 2:14 PM Subject: remote deployment, how? Dear All, I would like to be able to deploy an .ear remotely (the servers run FreeBSD, some of the development workstations use Windows). I found that admin.jar can do this, and that the new application is indeed uploaded to the server. It is not automatically deployed in place of the old one. What I do now (more or less) is this: java -jar admin.jar ormi://bladibla admin passwd \ -deploy -file doc.ear -deploymentName doc I see that the new file shows up in $ORION/applications, prefixed with an underscore. Repeatedly deploying the same file gives me lots of folders with ever more underscores (_doc, __doc, ___doc, etc), but changes to .jsp files in the .ear are not visible over the web. What I want to do is upload a new version of the application archive in place of the old one, auto-deploying the thing. Question is: how do I do that? Kees Jan You are only young once, but you can stay immature all your life.
Re: remote deployment, how?
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
remote deployment, how?
Dear All, I would like to be able to deploy an .ear remotely (the servers run FreeBSD, some of the development workstations use Windows). I found that admin.jar can do this, and that the new application is indeed uploaded to the server. It is not automatically deployed in place of the old one. What I do now (more or less) is this: java -jar admin.jar ormi://bladibla admin passwd \ -deploy -file doc.ear -deploymentName doc I see that the new file shows up in $ORION/applications, prefixed with an underscore. Repeatedly deploying the same file gives me lots of folders with ever more underscores (_doc, __doc, ___doc, etc), but changes to .jsp files in the .ear are not visible over the web. What I want to do is upload a new version of the application archive in place of the old one, auto-deploying the thing. Question is: how do I do that? Kees Jan You are only young once, but you can stay immature all your life.
