I've an AppEngine (Java) project with cloud endpoints. It has Groovy support through:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<version>3.1</version>
<configuration>
<source>1.7</source>
<target>1.7</target>
<compilerId>groovy-eclipse-compiler</compilerId>
</configuration>
<dependencies>
<dependency>
<groupId>org.codehaus.groovy</groupId>
<artifactId>groovy-eclipse-compiler</artifactId>
<version>2.8.0-01</version>
</dependency>
<dependency>
<groupId>org.codehaus.groovy</groupId>
<artifactId>groovy-eclipse-batch</artifactId>
<version>2.1.8-01</version>
</dependency>
</dependencies>
</plugin>
Everything seems to work except endpoints_get_discovery_doc that gives me this error during mvn install:
Error: xxx.XxxEndpoint.XxxEndpoint.super$1$finalize: Invalid method name 'XxxEndpoint.super$1$finalize'. The method name must match '\w+(\.\w+)*'
[INFO] Endpoints discovery doc generation done.
When I change XxxEndpoint.groovy to a plain XxxEndpoint.java, it generates successfully and the API can be discovered through the API explorer.
Any idea how to fix this or Groovy (I tried with #CompileStatic also) based #Api class endpoints are not (yet?) a supported feature?
UPDATE: I think it is because all methods in an #Api class will be exposed as API methods and Groovy's generated methods are not welcomed in this case. The docs say: "...all public, non static, non bridge methods in a class with an #Api annotation are exposed in the API, whether they have an #ApiMethod annotation or not."
If this is true, then it is possible to exclude methods in an #Api class from being exposed as an #ApiMethod?
It seems like you've traced down the answer to your own question here. Groovy is working in such a way that it's adding these methods, which aren't enjoyed by the endpoints discovery doc/client lib generation tools. You could try playing around with the order in which the plugins are run so that groovy adds its methods after the discovery doc is generated?
Related
I'm using Open API code generator Maven plugin to generate Open API 3.0 from a file. I'm using this plugin in in my pom.xml:
<groupId>org.openapitools</groupId>
<artifactId>openapi-generator-maven-plugin</artifactId>
<version>4.3.0</version>
The plugin generates the API without any issues but instead of using Swagger v3 annotations it uses old Swagger annotations. For example parameters are annotated using #ApiParam, instead #Parameter annotation should be used from io.swagger.v3.oas.annotations package:
default ResponseEntity<Fault> getFault(#ApiParam(value = "",required=true) #PathVariable("jobId") String jobId) {
Because of it the latest Swagger UI isn't showing the documentation correctly. When I create an endpoint using swagger.v3 annotations then Swagger UI is working properly.
According to the official website https://openapi-generator.tech/docs/plugins/ , I should include this dependency:
<dependency>
<groupId>io.swagger.parser.v3</groupId>
<artifactId>swagger-parser</artifactId>
</dependency>
But even with this dependency the plugin still generates sources with the old annotations.
How can I force Open API code generator to use Swagger v3 annotations?
V3 annotations are not supported at this moment.
You need to override mustache templates.
Check these PRs:
https://github.com/OpenAPITools/openapi-generator/pull/4779
https://github.com/OpenAPITools/openapi-generator/pull/6306
more info:
https://github.com/OpenAPITools/openapi-generator/issues/6108
https://github.com/OpenAPITools/openapi-generator/issues/5803
You can use upgraded templates from PRs above or wait when merged.
Now that version 5.3.1 of the plugin is released, I used the information from https://github.com/OpenAPITools/openapi-generator/pull/9775 and https://github.com/OpenAPITools/openapi-generator/issues/6108 to make it work for me.
I added the three configOptions in the pom.xml:
<plugin>
<groupId>org.openapitools</groupId>
<artifactId>openapi-generator-maven-plugin</artifactId>
<version>5.3.1</version>
<configuration>
<!-- other config omitted -->
<configOptions>
<oas3>true</oas3>
<useSpringController>true</useSpringController>
<useSpringfox>false</useSpringfox>
</configOptions>
</configuration>
</plugin>
After that, it may be necessary to add another dependency as a workaround, because the plugin adds unused imports into the generated code.
<dependency>
<!-- try to remove this dependency when a new version (5.3.1+) of the openapi-generator plugin is available -->
<groupId>io.swagger</groupId>
<artifactId>swagger-annotations</artifactId>
<version>1.6.3</version>
</dependency>
I am using the springdoc-openapi-ui dependency.
<dependency>
<groupId>org.springdoc</groupId>
<artifactId>springdoc-openapi-ui</artifactId>
<version>1.6.3</version>
</dependency>
Mocking of external concrete class fails with the below mentioned error.
java.lang.AbstractMethodError: Receiver class me.spike.LibraryTest does not define or inherit an implementation of the resolved method 'abstract java.lang.Object getProperty(java.lang.String)' of interface groovy.lang.GroovyObject.
I've tried adding cglibs-nodep and objenesis but was not successful in getting to mock the concrete class.
The repository mentioned here has a failing test. The test itself nonsensical. The intent is to get the mock working.
MCVE - https://github.com/ajaydivakaran/spock_spike
Like I said in the other question, you should get rid of the Build Helper plugin because Maven will recognise your src/test/groovy automatically - at least, as long as your src/test/java is not completely empty. Moreover, the Surefire plugin is over-specified, like I also told you before. You should keep your build files small and only include what is needed.
But the real problem is that your Groovy Eclipse batch compiler is version 3.0.3 while you use Groovy version 2.5.11. Just downgrade that one dependency to fit your Groovy version, and your test runs normally. Or go the other way, upgrade Groovy and Spock to 3.0. Anyway, changing this line fixes your build:
<groovy-eclipse-batch.version>2.5.11-01</groovy-eclipse-batch.version>
While this is just a workaround, you may switch to gmavenplus to handle Groovy compilation instead of groovy-eclipse-compiler and then that test passes:
<plugin>
<groupId>org.codehaus.gmavenplus</groupId>
<artifactId>gmavenplus-plugin</artifactId>
<version>1.8.1</version>
<executions>
<execution>
<goals>
<goal>compile</goal>
<goal>compileTests</goal>
</goals>
</execution>
</executions>
<dependencies>
<dependency>
<groupId>org.codehaus.groovy</groupId>
<artifactId>groovy-all</artifactId>
<version>2.5.11</version>
<scope>runtime</scope>
<type>pom</type>
</dependency>
</dependencies>
</plugin>
It definitely seems to be Groovy Eclipse Compiler related. We don't test Spock with GEC, nor it is officially supported. That test fails also with Spock 1.3-groovy-2.5 (and GEC), so it is not a regression in 2.0. However, may be related to the "hacks" in JavaMockInterceptor and some issues with Groovy 3 - #1076.
You may report it in the Spock issue tracker, however, I don't know if it will be properly handled.
Code for detecting pattern in Flink-CEP is shown below
// Generate temperature warnings for each matched warning pattern
DataStream<TemperatureEvent> warnings = tempPatternStream.select(
(Map<String, MonitoringEvent> pattern) -> {
TemperatureEvent first = (TemperatureEvent) pattern.get("first");
return new TemperatureEvent(first.getRackID(), first.getTemperature()) ;
}
);
if build using command + F9 in Mac, following error is shown
Exception in thread "main" org.apache.flink.api.common.functions.InvalidTypesException: The generic type parameters of 'Map' are missing.
It seems that your compiler has not stored them into the .class file.
Currently, only the Eclipse JDT compiler preserves the type information necessary to use the lambdas feature type-safely.
See the documentation for more information about how to compile jobs containing lambda expressions.
at org.apache.flink.api.java.typeutils.TypeExtractor.validateLambdaGenericParameter(TypeExtractor.java:1316)
at org.apache.flink.api.java.typeutils.TypeExtractor.validateLambdaGenericParameters(TypeExtractor.java:1302)
at org.apache.flink.api.java.typeutils.TypeExtractor.getUnaryOperatorReturnType(TypeExtractor.java:346)
at org.apache.flink.cep.PatternStream.select(PatternStream.java:64)
at org.stsffap.cep.monitoring.CEPMonitoring.main(CEPMonitoring.java:85
However building usign mvn clean install and then running via Control + R shows output,
I am wondering why this is happening all the time ?
Is there any way around to do it?
PS : however I am using eclipse JDT Plugin , even then it is showing error in log . Contents of POM.XML are
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<version>3.1</version>
<configuration>
<source>1.8</source>
<target>1.8</target>
<compilerId>jdt</compilerId>
</configuration>
<dependencies>
<dependency>
<groupId>org.eclipse.tycho</groupId>
<artifactId>tycho-compiler-jdt</artifactId>
<version>0.21.0</version>
</dependency>
</dependencies>
</plugin>
Suggestions are most welcome.Thanks in advance
I know that Java 8 Lambdas are very convenient. However, they provide almost no type information via reflection, which is why Flink has problems with generating the underlying serializers. In order to also run your Flink programs in the IDE, I would recommend to use Java anonymous classes instead of lambdas, whenever generic types are involved.
first, check your jdk version, is 1.8? and also upgrade the version of tycho-compiler-jdt to 1.0.0 your san refer below plugin :
<plugin>
<!-- Use compiler plugin with tycho as the adapter to the JDT compiler. -->
<artifactId>maven-compiler-plugin</artifactId>
<configuration>
<source>1.8</source>
<target>1.8</target>
<compilerId>jdt</compilerId>
</configuration>
<dependencies>
<!-- This dependency provides the implementation of compiler "jdt": -->
<dependency>
<groupId>org.eclipse.tycho</groupId>
<artifactId>tycho-compiler-jdt</artifactId>
<version>1.0.0</version>
</dependency>
</dependencies>
</plugin>
you can refer source : https://ci.apache.org/projects/flink/flink-docs-release-1.4/dev/java8.html
after this you have to do is to build the project on the cli using maven. Once the program has been built via maven, you can also run it from within IntelliJ.
I have an application that needs to integrate with one of SharePoint's web services. This web service cannot be accessed freely and needs authentication.
As such, the standard wsdl2java Maven plugin in my application gives an HTTP 401 error when the generate-sources phase is executed.
Is there a way to setup Maven/POM so that I can provide a user/password that will generate the stubs?
I have come across some answers saying this is not possible but all answers are older than 1 year. I haven't found if Maven have issued an update on this. One option is to save a local copy of the WSDL (as suggested here) but I would like to avoid having local copies.
Because you mentioned CXF then I suppose you meant cxf-codegen-plugin. It's a bit of a hack but it works.
HTTP authentication credentials can be provided using java.net.Authenticator. One need to just define his own Authenticator class which overrides getPasswordAuthentication(..) method. Then it has to be set as default Authenticator. As far as I know it can't be done declaratively (for instance using environment properties) only programatically using Authenticator.setDefault(..).
In order to call Authenticator.setDefault(..) I would use CXF extension mechanism. Create separate maven project with similar class:
public class AuthenticatorReplacer {
public AuthenticatorReplacer(Bus bus) {
java.net.Authenticator.setDefault(new java.net.Authenticator() {
#Override
protected PasswordAuthentication getPasswordAuthentication() {
return new PasswordAuthentication("test", "test123"
.toCharArray());
}
});
}
}
and file src\main\resources\META-INF\cxf\bus-extensions.txt with contents:
org.example.AuthenticatorReplacer::false
Then add newly created project as a dependency to cxf-codegen-plugin:
<plugin>
<groupId>org.apache.cxf</groupId>
<artifactId>cxf-codegen-plugin</artifactId>
<version>${project.version}</version>
<dependencies>
<dependency>
<groupId>org.example</groupId>
<artifactId>cxf-authenticator-replacer</artifactId>
<version>0.0.1-SNAPSHOT</version>
</dependency>
</dependencies>
...
</plugin>
This way AuthenticatorReplacer is initialized by CXF extension mechanism and replaces default Authenticator with ours.
An clean alternative to #Dawid Pytel's solution would be to run this class during lifecycle of wsdl class auto generation:
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>exec-maven-plugin</artifactId>
<version>1.4.0</version>
<executions>
<execution>
<phase>generate-sources</phase>
<goals>
<goal>java</goal>
</goals>
</execution>
</executions>
<configuration>
<mainClass>path.to.AuthenticatorReplacer</mainClass>
</configuration>
</plugin>
Important: your AuthenticatorReplacer has to be a main(String[] args) class and running the code inside.
I verified that Dawid's solution works. Alternatively, you can use SoapUI to pull down and cache the wsdl and then use SoapUi code generation support to use cxf to generate the code.
http://java.dzone.com/tips/generating-client-java-code
Dawid's solution works for me too. It is a little tricky though. In Eclipse, the pom.xml keeps complaining that "wsdl2java failed: Could not load extension class AuthenticatorReplacer". You have to ignore this error message and use the command line:
mvn generate-sources
The Java classes will then be generated successfully.
I am using Netbeans 7 with Maven 2.2.1 and jaxws-maven-plugin 1.12. Code is deployed on Glassfish 3.1 - or will be when I get it to compile :)
When I build the project, the wsimport runs as expected and generates the source files from the WSDL provided. The problem is that the build fails during the compile phase with the following three exceptions. From researching this, I see that these constructors were added from JAX-WS 2.1 to JAX-WS 2.2. My belief is that the wsimport is using JAX-WS 2.1 and the compile is using JAX-WS 2.2.
Can someone confirm my suspicion? Or, if I'm wrong, might you have an idea what may be causing this?
Thank you.
UPDATED/CLARIFICATION OF PROBLEM
The Web service client extends javax.xml.ws.Service and the error is thrown when the client tries to call the super class constructor with three arguments. Since the super class doesn't have any constructor with three arguments, it fails.
javax.xml.ws.Service is found in JDK SE 1.6 and JAX-WS 2.1 as the wrong version.
javax.xml.ws.Service is found in JAX-WS 2.2 as the correct version.
The error occurs three times since it is in three overridden constructors but it's the same error so I've included it only once.
cannot find symbol
symbol : constructor Service(java.net.URL,javax.xml.namespace.QName,javax.xml.ws.WebServiceFeature[])
location: class javax.xml.ws.Service
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>jaxws-maven-plugin</artifactId>
<version>1.12</version>
<executions>
<execution>
<goals>
<goal>wsimport</goal>
</goals>
<configuration>
<wsdlFiles>
<wsdlFile>*path to WSDL*</wsdlFile>
</wsdlFiles>
<wsdlLocation>*url to WSDL*</wsdlLocation>
<staleFile>${project.build.directory}/jaxws/stale/BudgetCheckingServiceService.stale</staleFile>
</configuration>
<id>wsimport-generate-BudgetCheckingServiceService</id>
<phase>generate-sources</phase>
</execution>
</executions>
<dependencies>
<dependency>
<groupId>com.sun.xml.ws</groupId>
<artifactId>jaxws-tools</artifactId>
<version>2.2.6-SNAPSHOT</version>
</dependency>
<dependency>
<groupId>javax.xml</groupId>
<artifactId>webservices-api</artifactId>
<version>1.4</version>
</dependency>
</dependencies>
<configuration>
<sourceDestDir>${project.build.directory}/generated-sources/jaxws-wsimport</sourceDestDir>
<xnocompile>true</xnocompile>
<verbose>true</verbose>
<extension>true</extension>
<catalog>${basedir}/src/jax-ws-catalog.xml</catalog>
</configuration>
</plugin>
As you can see in the jaxws-maven-plugin-1.12's pom, it has the dependency jaxws-tools-2.1.7. Well, you have over-ridden it via the pom. But, this over-riding works as long as the over-rode version (2.2.6-SNAPSHOT) is api-compatible with the plugin's default version (2.1.7).
Clearly, based on your remarks, they are not api-compatible. So, as I see this won't work. Here's a reference to follow.
Run mvn install with -X flag to determine the exact version of the jaxws-tools is used by this plugin. Do a pastebin if you don't mind, then we can have a look too!
EDIT: One thing you can do is; upgrade the maven-jaxws-plugin's jaxws-tools dep to the needed version of yours. And, then fix the issues occur due to api-incompatibility (such as constructor problems.) Then send a patch to the upstream.
I had a similar problem and it was solved by putting the file webservices-api.jar in my %JDK_HOME%/jre/lib/endorsed folder.