Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ignoreJspFragmentErrors Does not seem to work #41

Open
kouros51 opened this issue Feb 3, 2020 · 3 comments · May be fixed by #44
Open

ignoreJspFragmentErrors Does not seem to work #41

kouros51 opened this issue Feb 3, 2020 · 3 comments · May be fixed by #44

Comments

@kouros51
Copy link

kouros51 commented Feb 3, 2020

First of all thank you for this updated version.

We are having a legacy stack with a web-app that is based on JSPs and, using this plugin, we want to validate the JSPs pages compilation before going to production.

The problem is that we found that setting ignoreJspFragmentErrors to true and using jspf as fragment file doe not work and the plugin is scanning them anyway.

We found in the code of the plugin that the variable ignoreJspFragmentErrors is used only in the logger and never passed along to the JSP compiler as shown in the snippet

// We are logging the config if we are in debug (ignoreJspFragmentErrors is there)
      getLog().info("verbose=" + verbose);
      getLog().info("webAppSourceDirectory=" + webAppSourceDirectory);
      getLog().info("generatedClasses=" + generatedClasses);
      getLog().info("webXmlFragment=" + webXmlFragment);
      getLog().info("webXml=" + webXml);
      getLog().info("validateXml=" + validateXml);
      getLog().info("packageRoot=" + packageRoot);
      getLog().info("javaEncoding=" + javaEncoding);
      getLog().info("insertionMarker="
          + (insertionMarker == null || insertionMarker.equals("") ? END_OF_WEBAPP : insertionMarker));
      getLog().info("keepSources=" + keepSources);
      getLog().info("mergeFragment=" + mergeFragment);
      getLog().info("suppressSmap=" + suppressSmap);
      getLog().info("ignoreJspFragmentErrors=" + ignoreJspFragmentErrors);
      getLog().info("webXmlXsdSchema=" + webXmlXsdSchema);
      getLog().info("stopAtFirstError=" + stopAtFirstError);
      getLog().info("threads=" + threads);
      getLog().info("enableJspTagPooling=" + enableJspTagPooling);
      getLog().info("trimSpaces=" + trimSpaces);
      getLog().info("genStringAsCharArray=" + genStringAsCharArray);
      getLog().info("compilerVersion=" + compilerVersion);
      getLog().info("compilerClass=" + compilerClass);
// But when setting the context of the JSPC used underneath there is no indication of usage of that variable (ignoreJspFragmentErrors)
    JspCContextAccessor jspc = new JspCContextAccessor();
    jspc.setWebXmlInclude(getwebXmlFragmentFilename(threadIndex));
    jspc.setUriroot(webAppSourceDirectory);
    jspc.setPackage(packageRoot);
    jspc.setOutputDir(generatedClasses);
    jspc.setValidateXml(validateXml);
    jspc.setClassPath(classpathStr.toString());
    jspc.setCompile(true);
    jspc.setSmapSuppressed(suppressSmap);
    jspc.setSmapDumped(!suppressSmap);
    jspc.setJavaEncoding(javaEncoding);
    jspc.setFailOnError(stopAtFirstError);
    jspc.setPoolingEnabled(enableJspTagPooling);
    jspc.setTrimSpaces(trimSpaces ? TrimSpacesOption.TRUE : TrimSpacesOption.FALSE);
    jspc.setGenStringAsCharArray(genStringAsCharArray);
    jspc.setCompilerSourceVM(compilerVersion);
    jspc.setCompilerTargetVM(compilerVersion);
    jspc.setcompilerClass(compilerClass);
    jspc.setResourcesCache(resourcesCache);

furthermore, that flag is not used in any of the underlining validation in the code. The only alternative solution, that we found, is to exclude those files from the scan.

We were wondering if our analysis is valid and raise this bug if it's the case.
If it's not valid can you please provide us an example on how to use that flag with JSP fragment files.

Thanks.

@tcollignon
Copy link
Collaborator

Hi @kouros51 ,

You might be right. Some options have never been tested afaik, and it could just send it to /dev/null. I will try to look at this if I can to fix it but no guarantee Im sorry. If you have already the fix ou if you can make it, do the PR I will be happy to take a look at this

@tcollignon tcollignon linked a pull request Feb 26, 2020 that will close this issue
@tcollignon
Copy link
Collaborator

Hi @kouros51

I have made a PR to fix this => #44

It's a hack, it add automatically an exclude to **/*.jspf
=> I use it in my project too

let me know if it's ok for you

@tcollignon
Copy link
Collaborator

Note : I think it's the same kind of problem of #17

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants