Cannot read field "result" because "fi" is null

[Gertone]

All,

I get a nullpointer exception generating a customized responsive webhelp from DITA (I do get the same exception when I just run the vanilla HTML 5 plugin)
So the issue is in my DITA, but I am not sure how to analyse this.
It happens when copying the images, I guess. There is plenty of options. Just too much data (it is a 800 pages manual with many high resolution images), not enough memory, not enough disk space, maybe the images are locked (windows 10 machine)? Plenty of stuff to look into.
It could help however if someone had suffered from the same and could hint towards what exactly the nullpointer exception means

Thanks a lot,
Geert

[code]copy-image:
BUILD FAILED
D:\XML\IDE\Oxygen XML Editor 23\frameworks\dita\DITA-OT3.x\plugins\org.dita.base\build.xml:29: The following error occurred while executing this line:
D:\XML\IDE\Oxygen XML Editor 23\frameworks\dita\DITA-OT3.x\plugins\org.dita.base\build_preprocess.xml:364: java.lang.NullPointerException: Cannot read field "result" because "fi" is null
at org.dita.dost.ant.types.JobMapper.mapFileName(JobMapper.java:79)
at org.apache.tools.ant.util.CompositeMapper.lambda$mapFileName$0(CompositeMapper.java:32)
[/code]

[Gertone]

Some additional info
- generating a PDF (using FO and PDF2) causes no problems at all
- I did discover that all images were "blocked" by windows1à because they came from a different computer. Unblocking all the images (thank you PowerShell did not resolve the issue

[Radu]

Hi,

I'm not sure what the problem is. Are you using Oxygen 23.0 or 23.1?
Can you try to reduce your DITA project to a smaller sample with which the problem can be reproduced?
Or at least try to copy the project along with the images to some folder location where the publishing engine has full read-write access and try to see if publishing works from there.

Regards,
Radu

[Gertone]

Thanks for looking into this Radu

I took the opportunity to upgrade to 23.1, the issue was discovered in 23.0, it also happens in 23.1.

Then interestingly, I tried with Oxygen 22.0 and I don't have the issue.
(DITA Open Toolkit bundled with Oxygen 22.0, build 2020030411)

So whatever happens, it started happening with the OT framework bundled in Oxygen 23.0

Not sure that helps

Next step, I will try to isolate the issue in a smaller sample

[Stacey]

We had the same error message come up.
The .ditamap file had a bunch of other .ditamaps in it.
I think the issue was with these errors:

erroroxygen.jpg

When I deleted the submaps I believe these images would have been pulled from, the Transformation ran okay.
We haven't sorted out how to fix the original map(s) yet, this is just what seemed to be stopping things from actually outputting.

[Radu]

Hi Stacey,

And what version of Oxygen do you have? I'm afraid I need information in order to debug such problems further. If you put together a small DITA Project exhibiting the problem and steps to reproduce the problem you can send them via our tech support form and we can try to take a look at this on our side: https://www.oxygenxml.com/techSupport.html

Regards,
Radu

[Stacey]

It was happening both from 23.1 and 24.1.
I'm not sure how feasible pulling together a short selection is and still have the error appearing, but I'll see what I can do.

[tgrantham]

I encountered this problem this week while troubleshooting HTML publishing for a client. I'm using oXygen Editor 24.1, but I don't think that's relevant, as I'm using an external copy of DITA OT 3.5.4 to publish, not the one that comes with oXygen Editor.

In my case, the exception gets thrown by JobMapper, a Java class in the OT that I believe interacts with the .job.xml file in the temp folder created by the OT. The exception occurs apparently at the line referencing fi.result:

Code: Select all

    @Override
    public String[] mapFileName(String sourceFileName) {
        final URI uri = toURI(sourceFileName);
        Job.FileInfo fi = job.getFileInfo(uri);
        if (fi == null) {
            fi = job.getFileInfo(job.getInputDir().resolve(uri));
        }
        final String res;
        switch (type) {
            case TEMP:
                res = fi.file.getPath();
                break;
            case RESULT:
                if (fi.result == null) {
                    res = sourceFileName;
                } else {
                    final URI base = job.getInputDir();
                    final URI rel = base.relativize(fi.result);
                    res = toFile(rel).getPath();
                }
                break;
            default:
                throw new IllegalArgumentException();
        }
        return new String[]{extension != null ? (FilenameUtils.removeExtension(res) + extension) : res};
    }

Examining this code didn't reveal an answer, but it got me checking the file names of the DITA content topics. Through a process of elimination, I discovered that file names containing both square brackets ('[', ']') AND apostrophes (char '0027': "'") triggered this exception. The file names could contain square brackets or apostrophes on their own, but if they contained BOTH, the exception was thrown.

At this point, I don't know what the root cause is: it could be JobMapper or Java or the Windows file system or something else. But making sure the file names did not contain both square brackets and apostrophes solved the issue for me.

[Radu]

Hi,

There was this problem logged here about using apostrophes in the file named:
https://github.com/dita-ot/dita-ot/issues/2844
The problem was fixed in DITA OT 3.7.1 and also the DITA OT 3.7 bundled with Oxygen 24.1 should have it fixed as well.

Regards,
Radu

[tgrantham]

Thanks, Radu.

[super-structure]

In the event that some other DITA user runs into this issue, I can confirm it appears to be around file names. I also observed the issue with file names which contained a "+" character. While a perfectly valid file name in Windows (and thus, in an old CHM file), when converted to DITA topic this caused the same Java error.

[Radu]

Hi Jason,

Right, this publishing issue is still not addressed:
https://github.com/dita-ot/dita-ot/issues/4012

Maybe you can add a custom Schematron validation check to warn writers that an opened file contains "+" in its name for now.

Regards,
Radu

[tgrantham]

The real root cause of this problem is that the file names are not complying with RFC 3986, which the DITA standard requires:

The value of a DITA @href attribute must be a valid URI reference [RFC 3986]. It is an error if the value is not a
valid URI reference. An implementation MAY generate an error message; it MAY recover from this error
condition by attempting to convert the value to a valid URI reference. Note that the path separator character in a
URI is the forward slash (“/”); the backward slash character (“\”) is not permitted unescaped within URIs.

[From the DITA 1.3 specification at http://docs.oasis-open.org/dita/dita/v1 ... fattribute]

All of the characters that have caused problems identified in this topic are "reserved characters", as defined in RFC 3986:

2.2. Reserved Characters
URIs include components and subcomponents that are delimited by
characters in the "reserved" set. These characters are called
"reserved" because they may (or may not) be defined as delimiters by
the generic syntax, by each scheme-specific syntax, or by the
implementation-specific syntax of a URI's dereferencing algorithm.
If data for a URI component would conflict with a reserved
character's purpose as a delimiter, then the conflicting data must be
percent-encoded before the URI is formed.
reserved = gen-delims / sub-delims
gen-delims = ":" / "/" / "?" / "#" / "[" / "]" / "@"
sub-delims = "!" / "$" / "&" / "'" / "(" / ")"
/ "*" / "+" / "," / ";" / "="

So the DITA OT is not at fault, here. The standards are clear: DITA content creators should not be using these reserved characters in file names.

However, we can't trust most content creators to follow the RFC 3986 standard, so the OT graciously tries to accommodate their errors. But IMHO it's never going to be able to cope with every instance of non-compliance and we shouldn't expect it to do so.

Tim

[Radu]

Hi Tim,
What the standard says is that if for example on disk the file is named "abc+def.dita", then in the topicref in the DITA Map, it would be a good idea to have this + character escaped to its hexadecimal value like:

Code: Select all

<topicref href="abc%2bdef.dita"/>

So the standard does not prohibit the use of certain characters in a file name, it just defines that certain characters in the "@href" attribute value should be escaped using "%" to their hexadecimal value.

Regards,
Radu