vaadin / vaadin-connect

A Vaadin Labs experiment with a secure stateless communication framework
https://vaadin.com/labs/vaadin-connect
Apache License 2.0
18 stars 5 forks source link

OpenAPI generator exception: Can't get list of field from class PasswordEncoder #342

Closed vlukashov closed 5 years ago

vlukashov commented 5 years ago

When running the generator on the attached project, I get the following error in the maven logs. Despite of the scary error message and a stack trace, the project starts. There are several issues with that (lised below). Each of them needs to be investigated and addressed separately.

[INFO] --- vaadin-connect-maven-plugin:0.8.0:generate-openapi-spec (vaadin-connect-resources) @ polyglotdx ---
[INFO] Parsing java files from [/path/to/polyglot-dx/src/main/java, /path/to/polyglot-dx/target/generated-sources/annotations]
[INFO] Can't get list of field from class org.springframework.security.crypto.password.PasswordEncoder
java.lang.ClassNotFoundException: org.springframework.security.crypto.password.PasswordEncoder
    at org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy.loadClass (SelfFirstStrategy.java:50)
    at org.codehaus.plexus.classworlds.realm.ClassRealm.unsynchronizedLoadClass (ClassRealm.java:271)
    at org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass (ClassRealm.java:247)
    at org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass (ClassRealm.java:239)
    at java.lang.Class.forName0 (Native Method)
    at java.lang.Class.forName (Class.java:264)
    at com.vaadin.connect.plugin.generator.OpenApiObjectGenerator.getValidFields (OpenApiObjectGenerator.java:635)
    at com.vaadin.connect.plugin.generator.OpenApiObjectGenerator.parseReferencedTypeAsSchema (OpenApiObjectGenerator.java:614)
    at com.vaadin.connect.plugin.generator.OpenApiObjectGenerator.init (OpenApiObjectGenerator.java:202)
    at com.vaadin.connect.plugin.generator.OpenApiObjectGenerator.generateOpenApi (OpenApiObjectGenerator.java:177)
    at com.vaadin.connect.plugin.generator.OpenApiSpecGenerator.generateOpenApiSpec (OpenApiSpecGenerator.java:78)
    at com.vaadin.connect.plugin.generator.OpenApiSpecGenerator.generateOpenApiSpec (OpenApiSpecGenerator.java:97)
    at com.vaadin.connect.plugin.OpenApiSpecGeneratorMojo.execute (OpenApiSpecGeneratorMojo.java:59)
...

Issues with that:

vlukashov commented 5 years ago

Timebox 1d to investigate and create separate tickets for each of the bullet points. After that is done, this issue can be closed.

qtdzz commented 5 years ago

I do not see why does the generator try to parse the org.springframework.security.crypto.password.PasswordEncoder class. Is it the same issue as #339?

Yes, it's the same issue.

If there was a valid reason to parse the PasswordEncoder class, why is there a java.lang.ClassNotFoundException? Why cannot the parser find the class? It is in the class path (the project does compile and start OK). This can be extracted out as a separate issue.

Because JavaParser doesn't have the feature to get annotation and modifiers from a resolved field declaration (only available AccessSpecifier while we need to check against transient). I used reflection to get the information but didn't use the user project's ClassLoader, so apparently, the class is not found. This will be fixed in #378

If there is really an issue with the class path, and the error is real, the error message does not tell me which line in which of the project source files has caused it. The error message should be more specific and suggest an action I can take to fix it. This can be extracted out as a separate issue.

I think it shouldn't happen after the fix and "find the line" doesn't sound trivial to me, I am not sure if we should investigate it or not.

If the error is not critical for the TS generator, I do not expect to see a red text and a stack trace. If the error is indeed critical for TS generator, I expect the build to fail. This can be extracted out as a separate issue.

Removed the stacktrace and added more intuitive information in the log message. In any ways, if the error happens again, there is a possibility that user uses a class which is not in their compile classpath... that sounds weird but I included that information in the log.