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
Related
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
I created a servlet for my GWT app made with eclipse. When I deploy it in TOMCAT works perfectly, but in Glassfish I have an 404 Error.
I have no deploy errors, the main html page loads well. But anything that use the RPC servlet gives me this error:
com.google.gwt.user.client.rpc.StatusCodeException: 404 Not Found
HTTP Status 404 - Not Found
type Status report
messageNot Found
descriptionThe requested resource is not available.
GlassFish Server Open Source Edition 4.1
My web.xml is like this:
<?xml version="1.0" encoding="UTF-8"?>
<web-app xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/javaee
http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd"
version="2.5" xmlns="http://java.sun.com/xml/ns/javaee">
<!-- Servlets -->
<servlet>
<servlet-name>testServlet</servlet-name>
<servlet-class>com.test.server.testServiceImpl</servlet-class>
</servlet>
<servlet-mapping>
<servlet-name>testServlet</servlet-name>
<url-pattern>/webclient/test</url-pattern>
</servlet-mapping>
<!-- Default page to serve -->
<welcome-file-list>
<welcome-file>Webclient.html</welcome-file>
</welcome-file-list>
</web-app>
In the stub for the RPC I have this com.test.client.testService :
#RemoteServiceRelativePath("test")
public interface testService extends RemoteService {
And the servlet:
public class testServiceImpl extends RemoteServiceServlet implements testService
Notes:
When the app runs in tomcat, if I write the servlet name in the URL it shows me this error:
localhost:8080/webclient/webclient/test
Status HTTP 405 - Method HTTP GET is not supported in this URL
It seems that in fact is loaded well. But when is in Glassfish:
HTTP Status 404 - Not Found
What i'm missing? Thanks!
The behaviour with the GET in TOMCAT is correct (405)..but the 404 is strange. Have u got more information in your Glassfish log?? . Check this items...
0). Check the pattern of the URL . The URL should be http://hostname/nameOfWAR/{urlPatter_into_web.xml}
1).Make a test just to deploy a HelloWord jsp on the root of the web apps..and check the app is well-deployed showing some result..
2). Assuming that "webclient" is your WAR application have u exported or included the gwt-user jar in your app on deploying to Glassfish: gwt-user-xxx.jar ? If you use Eclipse you can use the Deployment Assembly or just locate the jar into the lib location of the war.
3.) Check there is no problem with the serialization policy file on the compiled gwt classes . Its a .gwt.rpc file... This must be on classpath . If this is the problems it should be more info throug exceptions, , etc... [ Also is possible to overwrite the location of this file overwriting SerializationPolicy ]
Try to change #RemoteServiceRelativePath("test") to #RemoteServiceRelativePath("/webclient/test")
In generall, <servlet-mapping> element should be in the form of an absolute directory path your app. You can read this useful article http://www.gwtproject.org/doc/latest/tutorial/RPC.html
And please, classes should name with upper case. I understand that maybe it is a test project, but to quickly get used to bad.
Solved! I didn't check the server.log of glassfish. There was an error of casting of the RPC servlet:
rpc servlet cannot be cast to javax.servlet.Servlet
The problem was I messed up the libs and added javax* in the classpath, and Glassfish don't need this. I deleted all additional libs I left in domain/lib/ext, and worked perfectly.
Thanks for your support!
I am struggling for the past 6-7 hrs trying to figure out what went wrong with my Apache Tomcat Server. In all of my projects, the jdk version got switched to 1.6 from 1.8.
To solve the version conflict, I verified whether compiled version and JVM of Tomcat version are same by taking help from here.
For multiple contexts with the same path error, I know i need to remove duplicate Context tags in server.xml. So, first I check in Servers project (which gets created itself when you add Apache Tomcat Server in Eclipse) and find none there. So, I delve deep into the directory(Eclipse WorkSpace) metadata\.plugins\org.eclipse.wst.server.core\tmp3\conf and removed the duplicate Context tags over there, with help taken from here.
Now when i create a new Dynamic Web Project, everything works fine and I am able to see the web page. But if I try to access any of the HTML, XHTML files of those old project in which the jdk got changed, this org.apache.catalina.LifecycleException continues to pop up and the server fails to start, and consequently these duplicate Context tags continues to build up again and again every time i start the server.
None of my old Web application projects seems to work now.
java.util.concurrent.ExecutionException:
org.apache.catalina.LifecycleException: Failed to start component
[StandardEngine[Catalina].StandardHost[localhost].StandardContext
[/EdBurns_ChrisSchalk]].....
SEVERE: A child container failed during start
java.util.concurrent.ExecutionException:
org.apache.catalina.LifecycleException: Failed to start component
[StandardEngine[Catalina].StandardHost[localhost]]
....
Caused by: java.lang.RuntimeException: Unexpected element value kind in
annotation: 0
How to prevent these context tags being build up again and again in server.xml.
Secondly, how to get back those old web projects to working state again?
I had a similar error and fixed it by following steps:
1. Under Servers project (which gets created itself when you add Apache Tomcat Server in Eclipse), open server.xml
2. Comment out the line
<Context docBase=... />
This will prevent multiple context tags to be created upon each request
1) Stop the server
2) Clean Tomcat's work directory
If you are not using annotation based Servlet then please remove annotation #WebServlet("/YourServletName") from the starting of the servlet. This annotation confuses the mapping with web.xml, after removing this annotation Tomcat server will work properly.
This seems to be an issue with local Maven repository. (i.e. .m2 folder) may be due to some corrupt .jar file
For me, the following actions helped to overcome this issue.
On my local file system, I've deleted the directory .m2 (Maven local repository)
In Eclipse, updated the project (select Maven > Update Project)
Ran the app again on Tomcat server.
Went through the various resources on the net but none of them helped then i deleted the existing server and added the same server again and now it is working fine and the steps are
Window>>ShowView>>Servers>>RightClick>>Delete
and then add the server again as you have added previously.
If you are using the following stack:
Server Version: Apache Tomcat/9.0.21
Servlet Version: 4.0 JSP Version: 2.3
Then try adding <absolute-ordering /> to your web.xml file. So your file looks like this:
<?xml version="1.0" encoding="UTF-8"?>
<web-app xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://xmlns.jcp.org/xml/ns/javaee" xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee http://xmlns.jcp.org/xml/ns/javaee/web-app_3_1.xsd" id="WebApp_ID" version="3.1">
<display-name>spring-mvc-crud-demo</display-name>
<absolute-ordering />
<welcome-file-list>
<welcome-file>index.jsp</welcome-file>
<welcome-file>index.html</welcome-file>
</welcome-file-list>
......
In my case, the servlet-api.jar file in jre/lib/ext in the jdk directory conflicts with the servlet-api.jar file in tomcat, removing the servlet-api.jar in jre/lib/ext in the jdk directory can solve the problem.
Just make sure build with correct web.xml configuration.I have update web.xml with tomcat configuration and it worked for me.
Sample :-
<?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_2_5.xsd"
id="WebApp_ID" version="2.5">
<display-name>simulator</display-name>
<description>simulator app</description>
<!-- File upload -->
<welcome-file-list>
<welcome-file>index.html</welcome-file>
</welcome-file-list>
<!-- excel simulation -->
<display-name>simulator</display-name>
<description>simulator app</description>
<!-- File upload -->
<welcome-file-list>
<welcome-file>InsertPage.html</welcome-file>
</welcome-file-list>
<servlet>
<servlet-name>FileUploadServlet</servlet-name>
<servlet-class>clari5.excel.FileUploadServlet</servlet-class>
<load-on-startup>1</load-on-startup>
</servlet>
<servlet-mapping>
<servlet-name>FileUploadServlet</servlet-name>
<url-pattern>/excelSimulator/FileUploadServlet</url-pattern>
</servlet-mapping>
</web-app>
One of the problems that can cause this is when you forget to put the / character in the WebServlet annotation #WebServlet("/example") #WebServlet("example")
I hope it works, it worked for me.
Below solution worked for me:
Navigate to Project->Clean..
Clean all the projects referenced by Tomcat server
Refresh the project you're trying to run on Tomcat
Try to run the server afterwards
I think it is jar file version problem. I had the same issue and I fixed it by changing the commons-codec-1.6.jar file from the build path. Earlier I was using latest version 1.10. Gradually I decreased the versions and 1.6 version fixed my issue.
Go to the task manager, kill the java processes and turn the server back on.
should work fine.
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.
I have integrated within a JSF app a few webservices through Jersey. Everything works fine, even the OAuth identification is working. BUT! When starting my webserver, I ALWAYS get this error :
INFO: Scanning for root resource and provider classes in the packages:
com.mysite.webService
INFO: Root resource classes found:
class com.mysite.webService.Accounts
INFO: No provider classes found.
INFO: Initiating Jersey application, version 'Jersey: 1.17 01/17/2013 03:31 PM'
SEVERE: The provider class, class com.sun.jersey.oauth.server.OAuthProviderInjectionProvider, could not be instantiated. Processing will continue but the class will not be utilized
java.lang.RuntimeException: No OAuthProvider implementation found in the list of providers.
at com.sun.jersey.oauth.server.OAuthProviderInjectionProvider.<init>(OAuthProviderInjectionProvider.java:71)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
(edit2: above is now solved)
and this warning:
...
WARNING: Provider com.sun.xml.internal.bind.v2.ContextFactory not found
javax.xml.bind.JAXBException: Provider com.sun.xml.internal.bind.v2.ContextFactory not found
- with linked exception:
[java.lang.ClassNotFoundException: com.sun.xml.internal.bind.v2.ContextFactory not found by com.sun.jersey.glassfish.v3.osgi.jersey-gf-server [157]]
at javax.xml.bind.ContextFinder.newInstance(ContextFinder.java:148)
at javax.xml.bind.ContextFinder.find(ContextFinder.java:361)
at javax.xml.bind.JAXBContext.newInstance(JAXBContext.java:446)
at javax.xml.bind.JAXBContext.newInstance(JAXBContext.java:409)
at com.sun.jersey.server.impl.wadl.WadlApplicationContextImpl.<init>(WadlApplicationContextImpl.java:95)
Here is my web.xml relevant entries :
<servlet>
<servlet-name>Jersey Web Application</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.site.webService</param-value>
</init-param>
<load-on-startup>2</load-on-startup>
</servlet>
<servlet-mapping>
<servlet-name>Jersey Web Application</servlet-name>
<url-pattern>/rest/*</url-pattern>
</servlet-mapping>
My classes look as such :
#Path("/rest")
public class MyClass {
#GET
#Path("/{id}/results")
#Produces("application/json")
public String getResults(#Context HttpContext hc, #PathParam("id")) {
//...
}
}
I am using Majorra 2.1.20 on Glassfish 2.1.2.2 with PrimeFaces 3.4.1 and Jersey 1.17 as addons. Developping in Eclipse Juno if this affects anything.
Edit
This does not prevent me from having everything in working order with regards to webservices. But everytime I republish something on Glassfish, the error shows up.
As mentioned in an answer below, this should have been fixed in version 1.7 according to JIRA bug JERSEY-709. But I am very well on v. 1.17 and I'm still getting this.
I have also added a Warning I am getting within the stack trace. If this can help determine the issue!
Searching the web : I have found The same unresolved issue here
Edit 2
As answered below, updating my OAuthClient.jar did solve the first error. I am STILL getting the WARNING: Provider com.sun.xml.internal.bind.v2.ContextFactory not found.
Edit 3 - Attempted Solution
Tried updating JAXB after what I thought would be a lead on this question. This did not lead to anything successful. Same warning. When removing the Jersey bits in my web.xml this warning stops showing (just to confirm this is really initiating the issue).
In another context : standalone Java App, using Maven
In pom.xml, jaxb was defined using this lines :
<dependency>
<groupId>javax.xml.bind</groupId>
<artifactId>jaxb-api</artifactId>
<version>2.1</version>
</dependency>
Project compilation is successful, but when running, I received the same Exception
(java.lang.ClassNotFoundException: com.sun.xml.bind.v2.ContextFactory)
Issue was solved adding this lines before jaxb-api dependency
<dependency>
<groupId>com.sun.xml.bind</groupId>
<artifactId>jaxb-impl</artifactId>
<version>2.1.2</version>
</dependency>
This error has gone away when upgrading to Jersey 1.18.
See https://java.net/jira/browse/JERSEY-1932
To upgrade Glassfish to Jersey 1.18 see : https://jersey.java.net/nonav/documentation/1.18/glassfish.html
This should have been fixed in v1.7 as per JERSEY-709.
M8, I met this as well on:
NetBeans 7.2
Glassfish 3.1.2.2 which have jersey 1.11, and jersey-oauth 1.11.
But it could work with:
NetBeans 7.3
Glassfish 3.1.2.2 which have jersey 1.11 (I didn't modify jars in glassfish/module folder)
jersey 1.13 and jersey-oauth 1.13 (which is packed in war)
Then the exception no longer exist.
I'm still not quite sure how it is solved, but I hope this can help you.