Issue Details (XML | Word | Printable)

Key: GLASSFISH-13518
Type: Improvement Improvement
Status: Open Open
Priority: Major Major
Assignee: Hong Zhang
Reporter: Dies Koper
Votes: 0
Watchers: 0
Operations

If you were logged in you would be able to see more operations.
glassfish

asadmin deploy won't come back when mistakenly specifying dir name

Created: 17/Sep/10 06:45 AM   Updated: 02/May/11 02:00 PM
Component/s: deployment
Affects Version/s: 3.1
Fix Version/s: future release

Time Tracking:
Not Specified

Environment:

Operating System: Windows XP
Platform: All


Issuezilla Id: 13,518
Tags:
Participants: Dies Koper and Hong Zhang


 Description  « Hide

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 \



Hong Zhang added a comment - 17/Sep/10 08:26 AM

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.


Dies Koper added a comment - 17/Sep/10 08:56 PM

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.


Hong Zhang added a comment - 20/Sep/10 05:33 AM

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.


Hong Zhang added a comment - 28/Sep/10 12:21 PM

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.


Dies Koper added a comment - 28/Sep/10 09:57 PM

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.)


Hong Zhang added a comment - 04/Oct/10 09:12 AM

scrubbing issues


Hong Zhang added a comment - 07/Dec/10 07:24 AM

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.