Migrate application from jetty server to wildfly 10 server - java

I have to deploy Jetty based application into Wildfly server10. Since, Jetty application has inbuilt Jetty server configurations in java class and when I execute pom.xml, will get Jar file. So, now I need to move Jetty application to wildfly. Could someone help to how to migrate Jetty to Wildfly? I did google but I couldn't able to find the exact answers.

If you want to migrate your application firstly you have to change the packaging of your Maven project, from JAR to WAR. Then you can migrate the configuration to a web.xml, but it depends on what you have written in your Jetty conf. For example the Servlet mapping in Jetty
ServletContextHandler context = new ServletContextHandler();
context.addServlet(mypackage.HelloServlet.class, "/hello");
must be translated to a configuration in web.xml
<servlet>
<servlet-name>HelloServlet</servlet-name>
<servlet-class>mypackage.HelloServlet</servlet-class>
</servlet>
<servlet-mapping>
<servlet-name>HelloServlet</servlet-name>
<url-pattern>/hello</url-pattern>
</servlet-mapping>
or with an annotation in your servlet class
#WebServlet("/hello")
public class HelloServlet extends HttpServlet {
...
}

Related

Deploying WAR to AWS Tomcat 404 Error

I am trying to deploy a WAR file compiled in JDK 1.8 to an AWS Tomcat Elastic Beanstalk instance. the elastic beanstalk instance uses JDK 8 and Tomcat 8, so I don't understand why I'm getting 404 errors when deploying my WAR file. I'm using gradle to build and WAR the application if that is of any help.
the logs are too big to paste in, and I don't know what is significant, so I uploaded the bundled zip to my dropbox that you can find here:
https://www.dropbox.com/s/d1ssmz76pbqkn20/BundleLogs-1487348401257.zip?dl=0
my web.xml is also too long to paste in the question, so I will link to it here: https://www.dropbox.com/s/4m7v3fhcczs0ina/web.xml?dl=0
I know it's bad practice to give links on Stack Overflow because of their mutability, so once the solution is found I will edit the question to directly include the pertinent segments of code.
I am not too sure if this solved your issue. I had a similar issue and it was fixed after extending SpringBootServletInitializer. This is deone because my application runs using Tomcat 8, Java 8 platform, which is like a container. Generally you need to extends SpringBootServletInitializer when deploying a war in a container.
Here is a sample Application.java
#SpringBootApplication
public class Application extends SpringBootServletInitializer {
public static void main(String[] args) {
SpringApplication.run(Application.class, args);
}
}
Your error is pretty straight forward:
org.xml.sax.SAXParseException; systemId: file:/var/lib/tomcat8/webapps/ROOT/WEB-INF/web.xml; lineNumber: 477; columnNumber: 23; Error at (477, 23) : The servlets named [TextHistoryServlet] and [TextHistoryServlet] are both mapped to the url-pattern [/TextHistoryServlet] which is not permitted
Around that line you'll see:
<servlet-mapping>
<servlet-name>CsvParseServlet</servlet-name>
<url-pattern>/CsvParseServlet</url-pattern>
</servlet-mapping>
<servlet-mapping>
<servlet-name>TextHistoryServlet</servlet-name>
<url-pattern>/TextHistoryServlet</url-pattern>
</servlet-mapping>
<servlet-mapping>
<servlet-name>TextHistoryServlet</servlet-name>
<url-pattern>/TextHistoryServlet</url-pattern>
</servlet-mapping>
<servlet-mapping>
<servlet-name>SurveyServlet</servlet-name>
<url-pattern>/SurveyServlet</url-pattern>
</servlet-mapping>
Remove the second mapping for TextHistoryServlet

Deploy of JAX-RS app with Tomcat, but required resource always not found

I've developed a RESTful service with JAX-RS, using Jersey libraries. I've builded and compiled it (with no errors) and I've deployed it with Tomcat 8.0.
But when I access to the service through the browser, always the same error:
Status HTTP 404 - Not Found
type Informe de estado
message Not Found
description The requested resource is not available
Apache Tomcat/8.0.21
I've already past several days struggling with this, and I can't find a solution. I've followed multiples tutorials, some of them very easy ones, but none of them got my service working.
I've tried using IntellJ Idea and Eclipse. You can download the project and try the service from my Github:
https://github.com/daniegarcia254/SmartCULM.git
There are two branches apart from the master, one for the Eclipse project and the another one for the IntellJ Idea project.
Both projects use Maven repositories for the needed libraries that are in the respectives pom.xml.
I think my final mistake is that I don't nail the service URL, but I've tried in a thousand different ways. Maybe I have the wrong structure of project or the wrong web.xml config, don't sure anymore about anythin!
For extra info, here the URL I'think should be the one valid to access the RESTful service once it's deployed:
http://localhost:8080/smartculm/api/service/noticias
I'm not positive, but I think that you might be missing some data in your web.xml file. In the projects that I've worked on, I had to specify the class of my servlet and the location of my resource and application files.
<display-name> display-name </display-name>
<servlet>
<servlet-name>Some_Service_Name</servlet-name>
<servlet-class>org.glassfish.jersey.servlet.ServletContainer</servlet-class>
<init-param>
<param-name>jersey.config.server.provider.packages</param-name>
<param-value>com.resource.package.name</param-value>
</init-param>
<init-param>
<param-name>javax.ws.rs.Application</param-name>
<param-value>com.application.package.ApplicationClassName</param-value>
</init-param>
<load-on-startup>1</load-on-startup>
</servlet>
<servlet-mapping>
<servlet-name>Some_Service_Name</servlet-name>
<url-pattern>/api/*</url-pattern>
</servlet-mapping>
I believe that instead of "com.resource.package.name", you would probably use "main.java.rest.smartculm". I don't see an application in your project, so I'm not sure what you would use. I usually define my own application class by extending javax.ws.rs.core.Application. I also put all of the files that you have in your webapp directory in the WebContent directory at the root of my project, instead of being in the src directory.
A reference that I used to get started was:
http://www.vogella.com/tutorials/REST/article.html
Important:
The complete path to a resource is based on the base URL and:
display-name -> configured in the <display-name> tag in the web.xml
url-pattern --> configured in the <url-pattern> tag in the web.xml
path_from_rest_class --> defined by the #Path annotations in your classes
http://your_domain:port/display-name/url-pattern/path_from_rest_class

No Idea why : The ResourceConfig instance does not contain any root resource classes [duplicate]

This question already has answers here:
The ResourceConfig instance does not contain any root resource classes
(25 answers)
Closed 4 years ago.
I'm new to jersey and web services and I'm try to run a simple RESTful web service. I followed http://www.mkyong.com/webservices/jax-rs/jersey-hello-world-example/ but my project doesn't use maven and I download the jersey.1.17.1.jar and include it to my project path.
When I want to call the service on http://localhost:8080/sycotext/rest/service/SOMETEXT I get this error :
HTTP Status 500 - Servlet.init() for servlet sycoText-servlet threw exception
this is the stack trace :
javax.servlet.ServletException: Servlet.init() for servlet sycoText-servlet threw exception
org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:504)
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:76)
org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:934)
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:515)
org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1010)
org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:640)
org.apache.coyote.http11.Http11NioProtocol$Http11ConnectionHandler.process(Http11NioProtocol.java:223)
org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1618)
org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.run(NioEndpoint.java:1576)
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
java.lang.Thread.run(Thread.java:724)
root cause
com.sun.jersey.api.container.ContainerException: The ResourceConfig instance does not contain any root resource classes.
com.sun.jersey.server.impl.application.RootResourceUriRules.<init>(RootResourceUriRules.java:99)
com.sun.jersey.server.impl.application.WebApplicationImpl._initiate(WebApplicationImpl.java:1331)
com.sun.jersey.server.impl.application.WebApplicationImpl.access$700(WebApplicationImpl.java:168)
com.sun.jersey.server.impl.application.WebApplicationImpl$13.f(WebApplicationImpl.java:774)
com.sun.jersey.server.impl.application.WebApplicationImpl$13.f(WebApplicationImpl.java:770)
com.sun.jersey.spi.inject.Errors.processWithErrors(Errors.java:193)
com.sun.jersey.server.impl.application.WebApplicationImpl.initiate(WebApplicationImpl.java:770)
com.sun.jersey.server.impl.application.WebApplicationImpl.initiate(WebApplicationImpl.java:765)
com.sun.jersey.spi.container.servlet.ServletContainer.initiate(ServletContainer.java:489)
com.sun.jersey.spi.container.servlet.ServletContainer$InternalWebComponent.initiate(ServletContainer.java:319)
com.sun.jersey.spi.container.servlet.WebComponent.load(WebComponent.java:605)
com.sun.jersey.spi.container.servlet.WebComponent.init(WebComponent.java:210)
com.sun.jersey.spi.container.servlet.ServletContainer.init(ServletContainer.java:374)
com.sun.jersey.spi.container.servlet.ServletContainer.init(ServletContainer.java:557)
javax.servlet.GenericServlet.init(GenericServlet.java:160)
org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:504)
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:76)
org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:934)
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:515)
org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1010)
org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:640)
org.apache.coyote.http11.Http11NioProtocol$Http11ConnectionHandler.process(Http11NioProtocol.java:223)
org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1618)
org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.run(NioEndpoint.java:1576)
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
java.lang.Thread.run(Thread.java:724)
here is my code :
package ir.sycotech.text.server.service;
import javax.ws.rs.*;
import javax.ws.rs.core.Response;
#Path("/service")
public class SycoTextService {
#GET
#Path("/{param}")
public Response getMsg(#PathParam("param") String msg) {
String output = "Jersey say : " + msg;
return Response.status(200).entity(output).build();
}
and here is my web.xml :
<?xml version="1.0" encoding="UTF-8"?>
<web-app id="WebApp_ID" version="2.4"
xmlns="http://java.sun.com/xml/ns/j2ee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee
http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd">
<display-name>Restful Web Application</display-name>
<servlet>
<servlet-name>sycoText-servlet</servlet-name>
<servlet-class>
com.sun.jersey.spi.container.servlet.ServletContainer
</servlet-class>
<init-param>
<param-name>com.sun.jersey.config.property.packages</param-name>
<param-value>ir.sycotech.text.server.service</param-value>
</init-param>
<load-on-startup>1</load-on-startup>
</servlet>
<servlet-mapping>
<servlet-name>sycoText-servlet</servlet-name>
<url-pattern>/rest/*</url-pattern>
</servlet-mapping>
</web-app>
I have specified my packagename correctly in the web.xml file and I don't know why I got this error, I will be really appreciate if anyone knows what is the problem
The error:
com.sun.jersey.api.container.ContainerException: The ResourceConfig instance does not contain any root resource classes.
means that Jersey can't find service classes. That can be caused by a wrongly named package for the com.sun.jersey.config.property.packages parameter or if the package name is correct but it does not contain resource classes (people sometimes forget to add the #Path annotation on the class).
But I can't find anything wrong with your setup. So this should work!
Check that your application deployed correctly and that your WEB-INF/classes folder actually contains your class with the proper folder path for the package.
Do a full clean and rebuild then try again.
I do not no the actual problem you are facing.
You can dwonload an example https://github.com/kdmalviyan/RestWithJerseyExample.git
you have to take following actions after downloading:
1. mvn clean install
2. deploy war to your server
3. access "JerseyExample-0.0.1-SNAPSHOT/rest/hello/hello Kuldeep Singh" on your server
You will get Output like: Jersey say : hello Kuldeep Singh
I suggest you to follow exact steps without any change anything first. If you get correct result then you can modify according to your need. Please make sure if you are renaming package, rename package in web.xml too.
I just ran into this problem using Grizzly with jersey.
When you fire up a a Grizzly container you have to pass in a map telling Grizzly where to find your resources. If you created your project from an archetype like I did or just moved some things around you also have to update this value which is easy to overlook.
final static String YOUR_PACKAGE_NAME_GOES_HERE = "where.ever.your.resource.package.happens.to.be"
final Map<String, String> initParams = new HashMap<String, String>();
initParams.put("com.sun.jersey.config.property.packages",
YOUR_PACKAGE_NAME_GOES_HERE);
System.out.println("Starting grizzly...");
SelectorThread threadSelector = GrizzlyWebContainerFactory.create(BASE_URI, initParams);
I ran into this issue, as well. There were two things that I did to get it to work, with the first being unrelated to this problem.
First, I'm using jersey 1.19. However, I didn't realize there was a file named
javax.ws.rs-api-2.0.jar in the WEB-INF/lib on the server. This file was added two years ago and, IIRC, works in conjunction with jersey 2.x but not 1.x. I effectively removed the file (renamed it with .bak as its extension).
Second, I created a JAR file in Eclipse for the web service. I did not use Maven or Ant or anything like that. Just a simple export. Now, the error can mean there is nothing in your code that references jersey. But I wrote a simple test class and everything should be working, I thought. Turns out the export wasn't creating the JAR file properly. I opened the JAR and the class was empty. No wonder it was generating this error! I exported once more and instead of checkmarking Export generated class files and resources, I checkmarked Export all output folders for checked projects. I also have multiple packages in this one project so that could be related to why the export wasn't functioning properly. Once I did that, it worked!
I tried the export again but, this time, I checkmarked Export generated class files and resources and selected every resource in the project. What was different from last time was I selected .settings. Last time, .settings wasn't selected. Again, this worked, too!
I hope this helps someone out there with a similar problem. Sometimes, it's just something as stupid as confirming your JAR file is correct. I use java decompiler to inspect the JAR file.
I encounter similar problem. Please check your initialization process whether you have registered the api class properly.
In your case, the initialization class is ir.sycotech.text.server.service
You need to register all api class in service.
Here is my example:
I will hit the error if the following classes are not registered, ( register(CtoFService.class);
register(FtoCService.class);
register(TriggerCmd.class);)
*<init-param>
<param-name>javax.ws.rs.Application</param-name>
<param-value>my.mimos.hcserver.init.MyApplication</param-value>
</init-param>*
#ApplicationPath("/HCRestServer/")
public class MyApplication extends ResourceConfig{
public MyApplication() {
System.out.println("******Started!*****");
register(CtoFService.class);
register(FtoCService.class);
register(TriggerCmd.class);
register(CORSResponseFilter.class);
System.out.println("******Done registration!*****");
}
}
Please ensure that your package "com.sun.jersey.config.property.packages" is registered correctly in Web.xml ... Good Luck !!
<servlet>
<servlet-name>Jersey REST Service</servlet-name>
<servletclass>com.sun.jersey.spi.container.servlet.ServletContainer</servlet-class>
<init-param>
<param-name>com.sun.jersey.config.property.packages</param-name>
<param-value>com.rest.service</param-value>
</init-param>
<init-param>
<param-name>com.sun.jersey.api.json.POJOMappingFeature</param-name>
<param-value>true</param-value>
</init-param>
<load-on-startup>1</load-on-startup>
</servlet>
If you trying to use HttpServerFactory, you must pass a PackagesResourceConfig.
Example:
ResourceConfig rc = new PackagesResourceConfig("com.package");
HttpServerFactory.create(getBaseURI(), rc);
I had the same problem, which I solved by specifying BOTH the classes package AND removing load-on-startup altogether, i.e.:
<servlet>
<servlet-name>my-servlet-name</servlet-name>
<servlet-class>
com.sun.jersey.spi.container.servlet.ServletContainer
</servlet-class>
<init-param>
<param-name>com.sun.jersey.config.property.packages</param-name>
<param-value>my.package.name</param-value>
</init-param>
<!-- <load-on-startup>1</load-on-startup> -->
</servlet>
I guess because I had more than one servlet under the same package and Jersey coudn't pick the "root" one to be loaded on startup.
Well, none of the above answers worked for me. They made me double check every step and package name, though. As Bogdan said, there were no compiled classes inside the target/classes/ folder.
Check that your application deployed correctly and that your WEB-INF/classes folder actually contains your class with the proper folder path for the package.
My solution was just cleaning the project and compiling different. Instead of just going for mvn war:war I did:
$ mvn clean:clean
$ mvn compile
$ mvn war:war
Then it compiled fine and the OP error disappeared.

How can I integrate Jersey with TomEE / openEJB

I am upgrading a code that uses Jersey JAX-RS to run on an Apache TomEE server. Unfortunately it throws errors when I try to use Jersey with TomEE.
I am using eclipse and have the JAX-RS project facet turned on. It points to the Jersey library. I have also moved the Jersey libraries into the /lib/ directory to try to solve the problem to no avail. The server throws the following error:
May 14, 2012 6:26:44 AM com.sun.jersey.api.core.ScanningResourceConfig logClasses
INFO: Provider classes found:
class org.codehaus.jackson.jaxrs.JsonParseExceptionMapper
class org.codehaus.jackson.jaxrs.JacksonJaxbJsonProvider
class org.codehaus.jackson.jaxrs.JsonMappingExceptionMapper
class org.codehaus.jackson.jaxrs.JacksonJsonProvider
May 14, 2012 6:26:44 AM org.apache.catalina.core.ApplicationContext log
SEVERE: StandardWrapper.Throwable
java.lang.RuntimeException: javax.naming.NameNotFoundException: Name [com] is not bound in this Context. Unable to find [com].
at com.sun.jersey.server.impl.cdi.CDIExtension.getInitializedExtension(CDIExtension.java:177)
at com.sun.jersey.server.impl.cdi.CDIComponentProviderFactory.<init>(CDIComponentProviderFactory.java:92)
at com.sun.jersey.server.impl.cdi.CDIComponentProviderFactoryInitializer.initialize(CDIComponentProviderFactoryInitializer.java:75)
at com.sun.jersey.spi.container.servlet.WebComponent.configure(WebComponent.java:576)
at com.sun.jersey.spi.container.servlet.ServletContainer$InternalWebComponent.configure(ServletContainer.java:311)
at com.sun.jersey.spi.container.servlet.WebComponent.load(WebComponent.java:608)
at com.sun.jersey.spi.container.servlet.WebComponent.init(WebComponent.java:210)
at com.sun.jersey.spi.container.servlet.ServletContainer.init(ServletContainer.java:373)
at com.sun.jersey.spi.container.servlet.ServletContainer.init(ServletContainer.java:556)
at javax.servlet.GenericServlet.init(GenericServlet.java:160)
at org.apache.catalina.core.StandardWrapper.initServlet(StandardWrapper.java:1266)
at org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1185)
at org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:1080)
at org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java:5015)
at org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5302)
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
at org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1566)
at org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1556)
at java.util.concurrent.FutureTask$Sync.innerRun(Unknown Source)
at java.util.concurrent.FutureTask.run(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
Caused by: javax.naming.NameNotFoundException: Name [com] is not bound in this Context. Unable to find [com].
at org.apache.naming.NamingContext.lookup(NamingContext.java:820)
at org.apache.naming.NamingContext.lookup(NamingContext.java:168)
at org.apache.naming.SelectorContext.lookup(SelectorContext.java:158)
at javax.naming.InitialContext.lookup(Unknown Source)
at com.sun.jersey.server.impl.cdi.CDIExtension$2.stepInto(CDIExtension.java:290)
at com.sun.jersey.server.impl.cdi.CDIExtension.diveIntoJNDIContext(CDIExtension.java:267)
at com.sun.jersey.server.impl.cdi.CDIExtension.lookupJerseyConfigJNDIContext(CDIExtension.java:287)
at com.sun.jersey.server.impl.cdi.CDIExtension.getInitializedExtension(CDIExtension.java:175)
... 22 more
web.xml:
<?xml version="1.0" encoding="UTF-8"?>
<web-app xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://java.sun.com/xml/ns/javaee" xmlns:web="http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd" xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd" version="3.0">
<display-name>tomeeTest3</display-name>
<servlet>
<description>JAX-RS Tools Generated - Do not modify</description>
<servlet-name>JAX-RS Servlet</servlet-name>
<servlet-class>com.sun.jersey.spi.container.servlet.ServletContainer</servlet-class>
<load-on-startup>1</load-on-startup>
</servlet>
<servlet-mapping>
<servlet-name>JAX-RS Servlet</servlet-name>
<url-pattern>/jaxrs/*</url-pattern>
</servlet-mapping>
</web-app>
Does anyone know how I might make this work? I'd also consider using the tomEE+ Jax-rs server, but it doesn't seem to recognize the Jackson annotations.
EDIT: I think the issue is that the openEJB CDI is conflicting with the CDI that comes with Jersey. I have no idea how to fix this.
RESURRECTION! Just in case anyone is still running into this problem.
I had a Jersey application that was running in Tomcat peachy keen and exploded in exactly this manner when I moved it it TomEE. The problem is that TomEE already has its own JAX-RS implementation (tomee-jaxrs-1.5.0 at the time of this writing), which conflicts with the jersey-bundle jars.
All I had to do to get rid of this problem was remove the jersey jars and comment out the servlet declaration and mapping in the web.xml
Give it a restart, and viola! Just remember that the URLs will be slightly different. For example, on a default jersey install you might have http://localhost/rest/represent/me and when you move that same app to TomEE it will be http://localhost/represent/me
If you're using an IDE like eclipse it might bark at you for not being able to find the jars, just go into the project properties and set the target runtime to TomEE (you will have to add a server instance) and you should be good to go.
Share and enjoy.
I too have run into this problem with that exact exception, and unfortunately grauwulf's answer did not work for me.
In my case, I have Tomee+ 1.5.2, Jersey 1.1x, and I am also using Spring 3.x.
The fix was actually quite simple:
Find the Tomee system.properties file ({tomee}/conf/system.properties by default).
Add com.sun.jersey.server.impl.cdi.lookupExtensionInBeanManager=true
From there, it just worked for me. To give the credit where it's due, I found it on this blog post.
Of interest, I also prefer to avoid cluttering my {tomee}/lib folder with my war's dependencies, so I have also found that you can easily add an extra lib by modifying {tomee}/conf/tomee.xml, and adding the following node (inside the root <tomee /> node):
<tomee>
<Service
id="extra-libs-enricher"
class-name="org.apache.openejb.assembler.classic.enricher.AdditionalLibClassLoaderEnricherObserver">
path = /path/to/your/libs
</Service>
</tomee>
With that Service, whose name is arbitrary, you can not pass a path, at which point it defaults to "additional-lib". The passed in path will be used by default, but if it is not a directory, then it will fall back to a system property, which can be added to the system.properties file. The system property is: openejb.enricher.additional-lib.
openejb.enricher.additional-lib=/fallback/path/to/your/libs
This system property is only checked if the path passed to Service, or its default value, does not work and only if a Service is placed in the tomee.xml file. Its id is irrelevant.
Just came across with this problem: TomEE + Jersey... the problem was that I was using TomEE in Eclipse "Use workspace metadata"... and somehow when configured like this the server configurations misses several details of the TomEE configs (namely the conf/system.properties - where we declare: "com.sun.jersey.server.impl.cdi.lookupExtensionInBeanManager=true"). When I changed it to "Use Tomcat installation", the problem went away. You can configure this by double-clicking the TomEE server in Eclipse and select "Use Tomcat installation", as seen in the following image:
You should add the package of the Provider classes as a parameter to the servlet:
<servlet>
<servlet-name>ServletAdaptor</servlet-name>
<servlet-class>com.sun.jersey.spi.container.servlet.ServletContainer</servlet-class>
<init-param>
<param-name>com.sun.jersey.config.property.packages</param-name>
<param-value>your.package.name</param-value>
</init-param>
<load-on-startup>1</load-on-startup>
</servlet>
<servlet-mapping>
<servlet-name>ServletAdaptor</servlet-name>
<url-pattern>/jaxrs/*</url-pattern>
</servlet-mapping>
Your provider classes should look like this:
package your.package.name;
#Path("/test")
public class StatsServlet {
#PUT
#Produces(MediaType.TEXT_HTML)
public String doPutHtml() {
return "Hello!";
}
}
I traced it down and pickypg is correct. I was able to get this to work with TomEE 1.5.2 using the tomee-maven-plugin. I haven't figured out exactly, but this problem occurs after the jersey figures out there is a bean manager at java:comp/BeanManager and tries to lookup the context.
<plugin>
<groupId>org.apache.openejb.maven</groupId>
<artifactId>tomee-maven-plugin</artifactId>
<version>1.0.1</version>
<configuration>
<tomeeHttpPort>${http.port}</tomeeHttpPort>
<tomeeVersion>1.5.2</tomeeVersion>
<args>-Dcom.sun.jersey.server.impl.cdi.lookupExtensionInBeanManager=true</args>
</configuration>
</plugin>
Here are the excerts of jersey where it is running into the issue.
public CDIComponentProviderFactory(Object bm, ResourceConfig rc, WebApplication wa) {
beanManager = (BeanManager)bm;
// work around proxying bug in Weld
if (CDIExtension.lookupExtensionInBeanManager) {
extension = Utils.getInstance(beanManager, CDIExtension.class);
}
else {
// NOTE THIS IS WHAT IS BEING EXECUTED WHEN FLAG IS SET TO FALSE
extension = CDIExtension.getInitializedExtension();
}
extension.setWebApplication(wa);
extension.setResourceConfig(rc);
}
/*
* Returns the instance of CDIExtension that was initialized previously in this same thread, if any.
*/
public static CDIExtension getInitializedExtension() {
try {
InitialContext ic = InitialContextHelper.getInitialContext();
if (ic == null) {
throw new RuntimeException();
}
return (CDIExtension)lookupJerseyConfigJNDIContext(ic).lookup(JNDI_CDIEXTENSION_NAME);
} catch (NamingException ex) {
throw new RuntimeException(ex);
}
}
...
/*
* Setting this system property to "true" will force use of the BeanManager to look up the bean for the active CDIExtension,
* rather than going through a thread local.
*/
private static final String LOOKUP_EXTENSION_IN_BEAN_MANAGER_SYSTEM_PROPERTY = "com.sun.jersey.server.impl.cdi.lookupExtensionInBeanManager";
public static final boolean lookupExtensionInBeanManager = getLookupExtensionInBeanManager();
private static boolean getLookupExtensionInBeanManager() {
return Boolean.parseBoolean(System.getProperty(LOOKUP_EXTENSION_IN_BEAN_MANAGER_SYSTEM_PROPERTY, "false"));
}
I was able to do that and if someone is looking for the solution that's what i did
This what i did:
* i’m using NetBeans 7.3.1
* I added the following lines in Tomee\conf\system.properties
–>com.sun.jersey.server.impl.cdi.lookupExtensionInBeanManager= true
* I added jersey libraries from NetBeans that’s all
* Note that the libraries are in WEB-INF\lib of my apps
* Additional information i was even able to use Mojarra for JSF if someone is interested i can tell you how

Java Jersey Rest : No provider classes found. (404 error when accessing URL)

Edit: I hadn't realized that all request were first going into "Apache" and then were redirected to Tomcat. I added a new redirection in the apache2.conf file. See the accepted answer for details.
I am having the exact same problem as this question.
Jersey REST The ResourceConfig instance does not contain any root resource classes
However the user never answered the question.
I am using Tomcat, without maven. I followed this tutorial.
http://www.ibm.com/developerworks/web/library/wa-aj-tomcat/index.html
I made changes to web.xml as per the article
i.e the new servlet and servlet mapping was created with the correct package name.
<servlet>
<servlet-name>Jersey REST Service</servlet-name>
<servlet-class>
com.sun.jersey.spi.container.servlet.ServletContainer
</servlet-class>
<init-param>
<param-name>com.sun.jersey.config.property.packages</param-name>
<param-value>sample.hello.resources</param-value>
</init-param>
<load-on-startup>1</load-on-startup>
</servlet>
<servlet-mapping>
<servlet-name>Jersey REST Service</servlet-name>
<url-pattern>/rest/*</url-pattern>
</servlet-mapping>
I have deployed the following jars to tomcat
asm.jar
jersey-server.jar
jersey-core.jar
jsr311.jar
The tomcat startup log has the following exceptions.
com.sun.jersey.api.core.PackagesResourceConfig init
INFO: Scanning for root resource and provider classes in the packages:
sample.hello.resources
com.sun.jersey.api.core.ScanningResourceConfig logClasses
INFO: Root resource classes found:
class sample.hello.resources.HelloResource
com.sun.jersey.api.core.ScanningResourceConfig init
INFO: No provider classes found.
com.sun.jersey.server.impl.application.WebApplicationImpl _initiate
INFO: Initiating Jersey application, version 'Jersey: 1.8 06/24/2011 12:17 PM'
When I access the URL I get a 404.
http://localhost:8080/Jersey/rest/hello
The code:
import javax.ws.rs.GET;
import javax.ws.rs.Path;
import javax.ws.rs.Produces;
import javax.ws.rs.core.MediaType;
#Path("/hello")
public class HelloResource {
#GET
#Produces(MediaType.TEXT_PLAIN)
public String sayHello() {
return "Hello Jersey";
}
}
I do not see any other exceptions in the logs
Verify you have the right URL:
The tomcat manager application is happy to direct you to the root URL of the servlet. (you are assuming this is "Jersey" with capital J.)
http://localhost:8080/manager/html/list
Then you can skip the "rest" part by setting the URL pattern in the servlet mapping of the web.xml to "/*" (yes, there was a bug in Jersey related to that once, but that's ancient history)
Then you can append "application.wadl" to get a description of available resources. Theoretically:
http://localhost:8080/Jersey/application.wadl
This issue was resolved as follows. My localhost has been setup with "Apache" webserver which redirects all requests to Tomcat. Since "Jersey" is using a new servlet, I had to create a separate redirect for this servlet specifically.
In Linux
/etc/apache2/apache2.conf
add:
JkMount /rest/* ajp13_worker
By default, Tomcat uses war file name or name of the top most directory of the exploded war as root context unless defined in catalina_home/conf/server.xml, catalina_home/conf/context.xml or in application's META-INF/context.xml file.
To access http://localhost:8080/Jersey/rest/hello, the context entry should be <Context path="/Jersey" docBase="myapp"/> and your resource should have #Path("/rest/hello").

Categories

Resources