Domain discovery fails due to incorrectly generated output archive filename

[surskitt]

When running the discover domain util, I have noticed the output archive filename has been generated incorrectly. When the tool creates a temporary zip filename, the generated filename incorrectly includes the parent directories twice.

23790/2:        open("/home/shane/mydomain_archive.zip", O_RDONLY) = 460
23790/2:        open("/home/shane/home/shane/mydomain_archive3568716833221357580.zip", O_RDWR|O_CREAT|O_EXCL, 0666) Err#2 ENOENT

The above truss output was produced with the archive file argument as -archive_file /home/shane/mydomain_archive.zip.

It looks like nameComponents[0] contains the full path (minus file extension), but should only contain the filename. createTempFile takes the directory as a separate argument, so it is being prepended to the already full path.

weblogic-deploy-tooling/core/src/main/java/oracle/weblogic/deploy/util/WLSDeployZipFile.java

Line 787 in 1ff34b2

newOutputFile = File.createTempFile(nameComponents[0], DOT + nameComponents[1], directory);

The problem may be below with getFileName returning the full path.

weblogic-deploy-tooling/core/src/main/java/oracle/weblogic/deploy/util/WLSDeployZipFile.java

Line 778 in 1ff34b2

String[] nameComponents = FileUtils.parseFileName(getFileName());

weblogic-deploy-tooling/core/src/main/java/oracle/weblogic/deploy/util/WLSDeployZipFile.java

Lines 86 to 88 in 1ff34b2

	public String getFileName() {
	return getFile().getAbsolutePath();
	}

[jshum2479]

Can you describe the problem you are facing first ? The lines you quoted are for temporary files only. Are you not seeing the the archive file in your home directory after completion ?

[surskitt]

The problem we're facing is that domain discoveries fail when multiple artefacts need to be added to the output archive. The first artefact is added to the archive, but for subsequent artefacts the tool tries to create a temporary archive. The path of this temporary archive is being generated with the parent directories repeated (e.g. /home/shane/home/shane/mydomain_archive3568716833221357580.zip rather than /home/shane/mydomain_archive3568716833221357580.zip). We can see this from the truss output above. If we create the parent directory /home/shane/home/shane, the output artefacts are generated fine, but this is obviously undesirable.

The actual message is listed below, but doesn't provide as much context.

SEVERE Messages:

        1. WLSDPLY-06011: discoverDomain failed to discover domain domain at /home/shane/domains/mydomain : Unexpected exception attempting to add Server mydomain_admin keystore file /home/shane/keystores/trust.jks to the archive : The WLSDeployArchive /home/shane/mydomain_archive.zip encountered an error while trying to create a temporary zip file to use for saving changes: No such file or directory

[jshum2479]

Thanks for the information. Do you have the discoverDomain log ? It should be under the weblogic-deploy/logs directory. Also which version you are using ?

Based on the error you are seeing, directory value is pointing to /home/shane/home/shane for some reason. JDK createTempFile will strip the prefix and only use the base name, so it won't be the first parameter wrong.

File directory = getFile().getParentFile();
..
File.createTempFile(nameComponents[0], DOT + nameComponents[1], directory)

If you attach the discoverDomain.log should have more insight.

Thanks.

[surskitt]

Please find discoverDomain.log below:

https://gist.github.com/shanedonohoe/9c661491d54b334fb7617453a204d3d9

I've had to obfuscate some private data, so if anything doesn't add up, it's most likely due to the replacements I had to run.

[jshum2479]

Thanks Shane,

Are you using Solaris x86 ? Is you /home directory a auto mounted or across system ? (mount | grep home should tell ). I don't have a similar system to test with, so I suggest to help debug the issue:

1. Use a different location than /home/shane/mydomain_archive.zip (e.g. /tmp)
2. Launch wlst.sh form $oracle_home/oracle_common/common/bin/wlst.sh and paste the script as

from java.io import File
base_name = 'mydomain_archive'
ext = '.zip'
base_dir = '/home/shane'
new_file = File.createTempFile(base_name, ext, File(base_dir))
print new_file.getAbsolutePath()

3. modify the $wdt_home/etc/logging.properties and add
   wlsdeploy.archive.level=FINEST
   rerun the discovery, the entries from getNewOutputFile should give more information.

Thanks.

[surskitt]

Yes, I am on solaris x86 and yes, my home directory is under a mountpoint:

/home on rpool/export/home read/write/setuid/devices/rstchown/nonbmand/exec/xattr/atime/dev=44d0008 on Mon Mar 4 10:46:34 2019

Using a directory in /tmp causes the same issue:

5838/2: open("/tmp/domain_export/tmp/domain_export/mydomain_archive1612007449949114059.zip", O_RDWR|O_CREAT|O_EXCL, 0666) Err#2 ENOENT

Your code snippet prints a path with the expected (correct, no duplicates) name.

[jshum2479]

Thanks Shane,

We found the issue, prior to jdk 8, the createTemporaryFile implementation does not strip down the prefix to it's base name, so that explains the extra structure you are seeing. The fix will be in the next release or if you can build from master if you need it sooner.

[surskitt]

Great news, thanks Johnny.

[surskitt]

Should this issue be closed?

[rakillen]

Yep, this was fixed with #190 - didn't close automatically