[GLASSFISH-13518] asadmin deploy won't come back when mistakenly specifying dir name Created: 17/Sep/10  Updated: 02/May/11

Status: Open
Project: glassfish
Component/s: deployment
Affects Version/s: 3.1
Fix Version/s: future release

Type: Improvement Priority: Major
Reporter: Dies Koper Assignee: Hong Zhang
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Operating System: Windows XP
Platform: All

Issuezilla Id: 13,518


I accidentally passed a directory name instead of a file name to asadmin deploy.
The hard disk's been grinding for 10 minutes but the command is not coming back.
Also no messages in server.log. GF is being very unforgiving..

D:\GFv3.1\glassfish-3.1-b21-09_17_2010\glassfishv3>bin\asadmin deploy \

Comment by Hong Zhang [ 17/Sep/10 ]

Dies: it's not so much of archive vs directory which makes the disk grinding,
it's more of the directory got passed in is the root path "\"!. So it's trying
to scan the whole root directory to see if it finds a JavaEE component jar
through annotation scanning. If you package the whole root directory into a
giant jar file, it will take just as much time.

Try to pass a small sub directory with not many files in it, and see how much
time before it returns.

Comment by Dies Koper [ 17/Sep/10 ]

I've never accidentally packaged the whole root directory and tried deploying it
but I have confirmed that with an empty sub-directory it comes back quickly.

So I'm not sure what is the root issue here.
The man pages say the operand is a file, not a directory, so if the man pages
are correct it could just check whether a file or directory was specified and
return an error immediately.

If the man pages are wrong, and it is supposed to traverse all subdirectories
searching for applications, then that's an issue by itself. Most Unix but also
Windows commands don't recursively go into each subdirectory unless some
recursive option has been explicitly specified. GF should operate the same.

In my case I tried to specify an application by using tab completion (and who
doesn't) and it picked a directory instead (note that on Windows it picks the
first match and you can cycle through the candidates by pressing tab again).
When this happened to me I didn't actually deploy '\' but still the
sub-directory that was picked had enough files for asadmin to become unresponsive.

Comment by Hong Zhang [ 20/Sep/10 ]

If the man page says it can only take a file, it needs to be updated to say
take both file and directory. The deploydir command is deprecated and the
deploy command is the one that should be used for both file and directory.
About going into sub directories: yes, the logic does go to the sub directories
to scan for component annotations. For ear case, the sub modules are in the sub
directories. And the component jars could be come in the form of a library jar
too, for example in WEB-INF/lib for ejb in war case.

Comment by Hong Zhang [ 28/Sep/10 ]

dies: Are you ok for me to close this issue? As I said in my previous comments,
we do need to go to the sub directories to process sub modules and scan library
jars to scan for annotations.

Comment by Dies Koper [ 28/Sep/10 ]

Could you close it after addressing the issues I brought up?

1. The man page is wrong. Closing this issue won't fix it.

2. I understand you want to merge 'deploydir' into the 'deploy' command and
therefore need to scan library jars. But scanning all subdirectories without
warning can be very annoying. I think it's better to add a '--recursive' option
and let the user explicitly express their wish to go into all subdirectories
when they want it to. Default (no option) would be to only check the specified
dir (or relevant dirs, like ./WEB-INF/lib, etc.)

Comment by Hong Zhang [ 04/Oct/10 ]

scrubbing issues

Comment by Hong Zhang [ 07/Dec/10 ]

I have provided this feedback to the doc team and now the latest 3.1 man page (not published officially yet) has reflected this change.

I am not sure how easy it is to decide what directories and the depth that we should scan by default: libraries could be at random places and referenced through manifest, class files could be located in a deep directory layout. I am going to mark this issue as an enhancement now and see if there is anything we can do in the future release.

Generated at Mon Apr 24 17:37:01 UTC 2017 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.