I'm able to test mkyong example http://www.mkyong.com/webservices/jax-rs/restful-java-client-with-jersey-client/ of jersey using Get and Post methods in a separate project. But, when I try to integrate the same example in my project which is maven and using Struts framework too , it doesn't run. I've added all the dependencies in pom.xml and configured in web.xml
URL I'm passing is
http://localhost:8080/MyProject/restful/json/metallica/get
The error which I get is
java.lang.AbstractMethodError
at org.codehaus.jackson.map.AnnotationIntrospector$Pair.findSerializer(AnnotationIntrospector.java:1148)
at org.codehaus.jackson.map.ser.BasicSerializerFactory.findSerializerFromAnnotation(BasicSerializerFactory.java:367)
at org.codehaus.jackson.map.ser.BeanSerializerFactory.createSerializer(BeanSerializerFactory.java:252)
at org.codehaus.jackson.map.ser.StdSerializerProvider._createUntypedSerializer(StdSerializerProvider.java:782)
at org.codehaus.jackson.map.ser.StdSerializerProvider._createAndCacheUntypedSerializer(StdSerializerProvider.java:735)
at org.codehaus.jackson.map.ser.StdSerializerProvider.findValueSerializer(StdSerializerProvider.java:344)
at org.codehaus.jackson.map.ser.StdSerializerProvider.findTypedValueSerializer(StdSerializerProvider.java:420)
at org.codehaus.jackson.map.ser.StdSerializerProvider._serializeValue(StdSerializerProvider.java:601)
at org.codehaus.jackson.map.ser.StdSerializerProvider.serializeValue(StdSerializerProvider.java:256)
at org.codehaus.jackson.map.ObjectMapper.writeValue(ObjectMapper.java:1613)
at org.codehaus.jackson.jaxrs.JacksonJsonProvider.writeTo(JacksonJsonProvider.java:520)
at com.sun.jersey.json.impl.provider.entity.JacksonProviderProxy.writeTo(JacksonProviderProxy.java:160)
Any ideas what is going on wrong?
Related
We are trying to use spring-test's SpringExtension to write integration tests for our Spring and Hibernate-based Tomcat web application. Our sessionFactory bean configuration has the property configured mappingJarLocations with a sample value as /WEB-INF/lib/company-common*.jar which contains hibernate mapping files. In both actual deployment and Eclipse dev deployment, this works fine as the docBasePath (in Servlet environment) is appended to this pattern and the files are getting resolved. But this is not the case while running JUnit test cases either in a local or a CI environment.
We tried our best to use the provided support by having few overridden implementations of WebTestContextBootstraper, GenricXmlWebContextLoader, XmlWebApplicationContext, and WebDelegatingSmartContextLoader but had to finally give up as we cannot override the final method org.springframework.test.context.web.AbstractGenericWebContextLoader.loadContext(MergedContextConfiguration) to provide the custom implementation of XmlWebApplicationContext. Our current approach is to manually create the application context and use it in the tests.
Here is the project structure:
Project_WebApp
|--src/**
|--WebContent/**
|--pom.xml
When the app is packaged as Project_WebApp.war, the dependencies are inside WEB-INF/lib from the root of extracted war. When deployed as a webapp in Tomcat using Eclipse, the dependencies are copied to <Eclipse_Workspace_Dir>/.metadata/.plugins/org.eclipse.wst.server.core/tmp0/Project_WebApp/WEB-INF/lib. In both cases, the dependencies are available at <Resource_Base_Path>/WEB-INF/lib and Resource_Base_Path has no relation to Project_WebApp base directory.
Questions:
Did any one use SpringExtension in a scenario similar to above? If so can you suggest any alternative approaches?
Instead of /WEB-INF/lib/company-common*.jar, we tried a classpath-based pattern but didn't work as the obtained class path resources don't match the pattern. Is there anything else to try here?
I have Spring Boot (2.0.0 M5) application which provides some REST API. I'd like to implement this API using RouterFunctions.
While I'm running app using embedded Jetty everything works fine.
When I convert the app to WAR file (following documentation here) and deploy it to Tomcat 8.5 I always get 404 when trying to call any of the endpoints.
I can see in the log that endpoints are recognised:
[ost-startStop-1] s.w.r.r.m.a.RequestMappingHandlerMapping : Mapped "{[/say-hello],methods=[GET]}" onto java.lang.String com.example.demo.DemoController.test()
[ost-startStop-1] o.s.w.r.f.s.s.RouterFunctionMapping: Mapped /api => {
/v1 => {
/status ->
com.example.demo.DemoApplication$$Lambda$189/1904651750#5fdc83e
}
}
But when calling curl -v http://localhost:8080/demo/say-hello or curl -v http://localhost:8080/demo/api/v1/status I see default Tomcat 404 page. The path is correct, I rename .war to demo.war before deploying it.
Did anybody come across similar issue? You can find the code here.
I'm afraid the WAR deployment model is not supported in Spring Boot for WebFlux at the moment. Spring Framework does support that model (although I'm not sure it supports deploying an app to a non-root context).
You can always create an issue on the Spring Boot issue tracker, but I'm not sure this will be implemented, as deploying to a Servlet container is not the primary focus there (and you can't do that with Netty).
Quick note: adding #EnableWebFlux is a signal that you'd like to take the WebFlux configuration in your own hands and that Spring Boot should not auto-configure things for you in that space.
Answering it now just in case some one else is still facing this issue.
In the POM file, you need to exclude the netty and add tomcat separately.
compile ('org.springframework.boot:spring-boot-starter-webflux') {
exclude group: 'org.springframework.boot', module: 'spring-boot-starter-
reactor-netty'
}
compile 'org.springframework.boot:spring-boot-starter-tomcat'
Please check the link for full code : https://github.com/sushantkr16/Spring-boot2-webflux-annotation
I am trying a simple example of creating a RESTful API. I used the Maven jersey-quickstart-webapp archtype to create a Jersey web app. In a separate project I created a simple class: SimpleClass, which only has one method that returns "hello". I am trying to create an instance of that class in my method in the web app (I am using the default MyResource class) and call its method to get "Hello". I exported the project with the SimpleClass to a JAR file, and added that file to the build path for my Jersey project, and imported the relevant package.
When I run the web app on a local server, and call the MyResource method, I get an error with the root cause (just the top few rows):
java.lang.NoClassDefFoundError: Lorg/test/simple/SimpleClass;
java.lang.Class.getDeclaredFields0(Native Method)
java.lang.Class.privateGetDeclaredFields(Class.java:2583)
java.lang.Class.getDeclaredFields(Class.java:1916)
So, it can't find the SimpleClass class.
What am I doing wrong here? I'd really appreciate any help!
Thanks,
Yariv.
New info: I tried to create a RESTful web service without Maven. I successfully created the project with a simple "Hello World" example, and then I tried to add my own class from another project: I imported the .jar, added it to the build path, and created a class in the web service that creates an instance of my class when a GET is made to the server. My class happens to include (as members) instances of other classes, one of which connects to a MongoDB database, and when I run the service, I again get a HTTP 500 error as follows:
A MultiException has 2 exceptions. They are:
1. java.lang.NoClassDefFoundError: com/mongodb/DBObject
2. java.lang.IllegalStateException: Unable to perform operation: create on org.notes.server.NotesServer
Adding the MongoDB jar to the web project did not help. I must be missing something big here. What should I do to call code I created in another project (with a set of dependencies there) in my web service?
I'll appreciate any help I can get, I am getting nowhere with this...
I was able to resolve all these issues by adding all the relevant JARs to the deployment assembly (right-click on the project, click Properties, then select Deployment Assembly and add all the JARs that my class depends on, as well as its own JAR).
Thanks for your help, radai!
I need to integrate a REST client into an existing OSGi application implemented using Apache Felix. The REST service is based on RESTeasy implementation (version 2.3.2.Final) of JAX-RS. I created a separate bundle with clients' dependencies, exporting required RESTeasy packages and importing them in the bundle where the client is used, but unfortunately I cannot get it working inside of the OSGi context.
I tried two different approaches. First one using the generic ClientRequest:
ClientRequest request = new ClientRequest(MyService.URL_TEST+"/stats");
request.body(javax.ws.rs.core.MediaType.APPLICATION_XML, stats);
ClientResponse<String> response = request.post(String.class);
The error that I get in this case is pretty weird:
[java] java.lang.RuntimeException: java.lang.ClassCastException:
org.jboss.resteasy.client.core.executors.ApacheHttpClient4Executor cannot be cast to
org.jboss.resteasy.client.ClientExecutor
where I it is known for sure that ApacheHttpClient4Executor implements the ClientExecutor interface.
When I try to use my own REST client wrapper around RESTeasy like this:
MyService myService = MyServiceClient.getInstance();
myService.saveStatistics(stats);
I get a different exception:
[java] java.lang.LinkageError: ClassCastException: attempting to
castjar:file:/D:/Development/Eclipses/eclipse_4.2_j2ee_x64/lib/jaxrs-api-2.3.2.Final.jar
!/javax/ws/rs/ext/RuntimeDelegate.classtobundle:
//78.0:1/javax/ws/rs/ext/RuntimeDelegate.class
As far as I understand, the LinkageError most probably has to do with the way RESTeasy initializes the RuntimeDelegate using some classloader tricks, which probably fall under the restrictions of OSGi framework. I get the suspicion that the java.lang.ClassCastException mentioned first has the same source.
Is there any way to get RESTeasy working inside of OSGi?
PS: discussion about a similar issue with RESTeasy, but outside of OSGi: java.lang.LinkageError: ClassCastException
Update:
these are the libraries included into restclient bundle:
activation-1.1.jar commons-codec-1.2.jar commons-httpclient-3.1.jar commons-io-2.1.jar commons-logging-1.0.4.jar flexjson-2.1.jar httpclient-4.1.2.jar httpcore-4.1.2.jar javassist-3.12.1.GA.jar jaxb-api-2.2.3.jar jaxb-impl-2.2.4.jar jaxrs-api-2.3.2.Final.jar jcip-annotations-1.0.jar jettison-1.3.1.jar jsr250-api-1.0.jar junit-4.10.jar log4j-1.2.14.jar resteasy-jaxb-provider-2.3.2.Final.jar resteasy-jaxrs-2.3.2.Final.jar resteasy-jettison-provider-2.3.2.Final.jar scannotation-1.0.3.jar slf4j-api-1.6.4.jar slf4j-log4j12-1.6.4.jar myservice-common-0.1.0.3.jar my-service-client-0.1.0.3-SNAPSHOT.jar stax-api-1.0-2.jar xmlpull-1.1.3.1.jar xpp3_min-1.1.4c.jar xstream-1.4.2.jar
These are the exports from the restclient bundle: javax.ws.rs, javax.ws.rs.ext, javax.ws.rs.core, org.jboss.resteasy.client, org.jboss.resteasy.client.cache, org.jboss.resteasy.client.extractors, org.jboss.resteasy.client.marshallers, org.jboss.resteasy.client.core.executors, javax.xml.bind.annotation, org.jboss.resteasy.plugins.providers, org.jboss.resteasy.plugins.providers.jaxb, org.jboss.resteasy.spi
Have a look at the SpringSource Bundle Repo, it's got some very useful pre-built bundles of common libraries including the Apache HTTP Client which we are using (in conjunction with gson) to do our RESTful comms.
(unfortunately a legacy module of my project still uses OSGi, but using RESTeasy 3.0.16 now)
When I need to OSGify a dependency my preferred solution now is to wrap it using the excellent Apache Ops4j Pax Tipi project.
The project provides a preconfigured Maven setup (parent POM handles the bundling) and you just have to adapt the GAV coordinates of the original project in a Tipi sub module with a org.apache.ops4j.pax.tipi prefix and build the new bundle project which draws in the original dependency, unpacks and wraps it as OSGi bundle.
You can start from an existing Tipi sub project that best matches your project setup (dependencies, etc.) and adapt any OSGi imports/exports missing (most often, these are created automatically by the maven-bundle-plugin anyway).
This worked quite well for me as long as the original project did not contain too many exotic or malformed dependencies.
However you may run into snags like transitive dependencies using the root package, as I currently experience, which can be a real show stopper (finding out which library is a real nightmare).
Unfortunately, RESTeasy seems to be affected by this, as I get exactly the same error (default package , even after declaring non-test and non-provided dependencies as optional:
The default package '.' is not permitted by the Import-Package syntax.
Upgrading the maven-bundle-plugin to the latest release 3.0.1 yields a different error (even less helpful):
[ERROR] Bundle org.ops4j.pax.tipi:org.ops4j.pax.tipi.resteasy-jaxrs:bundle:3.0.16.Final.1 : Can not parse name from bundle native code header:
[ERROR] Error(s) found in bundle configuration
Update seems to be solved by upping Tipi version in POM to 1.4.0, testing...
Is RESTEasy mandatory ?
I personally use jersey in OSGi and it is working perfectly, both as client and server.
This problem isn't limited to RESTeasy. It also occurs with Jersey.
It is occurring because you have two copies of the JAX-RS classes on the classpath.
You can see this in the LinkageError:
[java] java.lang.LinkageError: ClassCastException: attempting to cast jar:file:/D:/Development/Eclipses/eclipse_4.2_j2ee_x64/lib/jaxrs-api-2.3.2.Final.jar!/javax/ws/rs/ext/RuntimeDelegate.class to bundle://78.0:1/javax/ws/rs/ext/RuntimeDelegate.class
i.e. one copy is coming from:
D:/Development/Eclipses/eclipse_4.2_j2ee_x64/lib/jaxrs-api-2.3.2.Final.jar
and the other from the OSGI bundle.
This causes problems for the RuntimeDelegate class, which by default uses the system class loader to create the RuntimeDelegate implementation (see javax.ws.rs.ext.FactoryFinder).
The problem can also occur if the same jar is loaded via two different class loaders.
There are a couple of workarounds:
remove the jaxrs-api-2.3.2.Final.jar from the system class path
set the thread context class loader to that of your bundle, prior to making any JAX-RS calls.
The FactoryFinder will use this to load the RuntimeDelegate.
To avoid polluting your code with calls to Thread.currentThread().setContextClassLoader(myBundleClassLoader), you can wrap your JAX-RS client using a Proxy. e.g. see the Thread context classloader section of https://puredanger.github.io/tech.puredanger.com/2007/06/15/classloaders/
I've a web-service that works fine when I access them from a J2SE (desktop) application. To access this service I do follow:
generate stub classes by wsdl link using java wsimport tool
then I create service using generated classes and run one of wsdl operations.It looks like this:
MyWebServiceService webService = new MyWebServiceService();
MyWebService port = webService.getMyWebServicePort();
webService.run("XYZ");
As I sad it work fine when I use it in a standalone application.
But...when I try to access web-service in the same way but from servlet-client, using generated stubs I get following error:
java.lang.ClassCastException: com.sun.xml.bind.v2.runtime.JAXBContextImpl cannot be cast to com.sun.xml.bind.api.JAXBRIContext
org.jboss.ws.metadata.umdm.EndpointMetaData.eagerInitializeAccessors(EndpointMetaData.java:686)
org.jboss.ws.metadata.umdm.EndpointMetaData.initializeInternal(EndpointMetaData.java:567)
org.jboss.ws.metadata.umdm.EndpointMetaData.eagerInitialize(EndpointMetaData.java:553)
org.jboss.ws.metadata.builder.jaxws.JAXWSClientMetaDataBuilder.rebuildEndpointMetaData(JAXWSClientMetaDataBuilder.java:314)
org.jboss.ws.core.jaxws.spi.ServiceDelegateImpl.getPortInternal(ServiceDelegateImpl.java:271)
org.jboss.ws.core.jaxws.spi.ServiceDelegateImpl.getPort(ServiceDelegateImpl.java:202)
javax.xml.ws.Service.getPort(Service.java:143...
I've searched google long time but found nothing helpful topics. Some topics show examples accessing web-services from servlet, but unfortunately I can't do this...( And don't know what is cause of trouble.
Application server: jboss 4.2.3GA
Is it possible to connect web-service from servlet? How?
I've tried use #WebServiceRef annotation, but it seem web-container can't inject web-service stub. And I think that container must not do this itself, because stub classes have already been generated by wsimport tool, and its enouph to use this classes for accessing of web-service.
Stub classes were generated using the following command:
wsimport -keep -p com.myhost.ws http://www.myhost.com/services/MyWebService?wsdl
Did you make sure your classpath does not contain multiple JAX-B Jars with differing versions ? The exception looks like a version conflict to me. Application servers usually have some kind of "endorsed" lib directory that holds JARS that are always added in front of web application classpaths. Maybe your app server has a conflicting JAX-B implementation there ?
If you use Maven to package your application, make sure transitive dependencies don't pull in unwanted JAX-B Jars (use 'mvn dependency:tree' to check this).
This definitely sounds like a JAXB conflict to me. Check out the jaxb versions that you have in your war and make sure that they are not conflicting with a jaxb jar that Jboss may have in its lib directory.
Addytionally if jbossws-native library was installed correctly the following packages should be deleted from jboss_home/lib/endorsed directory:
jboss-jaxrpc.jar
jboss-jaxws-ext.jar
jboss-jaxws.jar
jboss-saaj.jar
Otherwise you don't have ability to connect to web service through EJB or servlet.