webentwicklung-frage-antwort-db.com.de

Jersey REST Die ResourceConfig-Instanz enthält keine Stammressourcenklassen

Obwohl dies eine alte Frage ist, kann ich immer noch keine Antwort finden, um dies zu erreichen. Bitte korrigieren Sie, wenn Sie feststellen, dass eine meiner Aussagen nicht korrekt ist.

Ich habe eine Java Face-App und verwende REST für die Web Services. Ich glaube nicht, dass Face überhaupt etwas mit meinem Problem zu tun hat. Die web.xml ist:

<servlet>
    <servlet-name>NDREST</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>com.bi.nd.webservice</param-value>
    </init-param>
    <load-on-startup>1</load-on-startup>
</servlet>
<servlet-mapping>
    <servlet-name>NDREST</servlet-name>
    <url-pattern>/nd/*</url-pattern>
</servlet-mapping>

Ich habe einige weitere Servlets in der web.xml, da es sich um eine Face-App mit Trinidad usw. handelt.

Im Paket com.bi.nd.webservice lautet meine Ressourcenklasse:

import javax.xml.bind.JAXBContext;
import javax.xml.bind.JAXBElement;
import javax.xml.bind.Marshaller;

import javax.ws.rs.Consumes;
import javax.ws.rs.GET;
import javax.ws.rs.POST;
import javax.ws.rs.Path;
import javax.ws.rs.Produces;
import javax.ws.rs.core.MediaType;

@Produces(MediaType.APPLICATION_XML)
@Path("/hello")
public class TransactionResource 
{
public TransactionResource() 
{
}

@GET
@Produces(MediaType.TEXT_PLAIN)
public String itWorks()
{
    return "Get is OK";
}
}

Die Tatsache, dass meine Klasse ein @GET hat, reicht aus, um sich selbst als Ressourcenklasse zu identifizieren.
Abgesehen von allen anderen Komplexitäten habe ich meinen Quellcode mit Ant in Eclipse kompiliert und diese Fehlermeldung wurde in der Datei catalina.out angezeigt:

May 24, 2011 8:48:46 AM com.Sun.jersey.api.core.PackagesResourceConfig init
INFO: Scanning for root resource and provider classes in the packages:
     com.bi.nd.webservice
May 24, 2011 8:48:46 AM com.Sun.jersey.server.impl.application.WebApplicationImpl _initiate
INFO: Initiating Jersey application, version 'Jersey: 1.7 05/20/2011 11:04 AM'
May 24, 2011 8:48:46 AM com.Sun.jersey.server.impl.application.RootResourceUriRules <init>
SEVERE: The ResourceConfig instance does not contain any root resource classes.

Einige schlugen vor, dass die Dateien asm.jar, jsr-api.jar, jersey-server.jar und jersey-core.jar in die App WEB-INF/lib kopiert werden. Ich habe das gemacht und es hat immer noch nicht funktioniert. Ich fand den Vorschlag etwas seltsam, da WEB-INF/lib ein Ort ist, an dem Eclipse alle Abhängigkeitsbibliotheken vom Erstellungspfad aus installiert. Es ist kein Ort, an dem wir Bibliotheken manuell ablegen.

Einige erklärten, dass dieser Fehler etwas mit dem Java-Plug-In zu tun habe und wie Jersey geschrieben wurde. Das war aber schon vor Jahren.

Kann mir jemand erklären, warum ich dieses Problem weiterhin habe?

Folge: Obwohl von der REST - Website als Ressourcenklassen definierte Ressourcenklasse POJOs (Plain Old Java Objects) sind, die entweder mit @ Path kommentiert werden oder über mindestens eine mit @Path oder eine Anforderung annotierte Methode verfügen Methodenbezeichner wie @GET, @PUT, @POST oder @DELETE. Ressourcenmethoden sind Methoden einer Ressourcenklasse, die mit einem Anforderungsmethodenbezeichner versehen ist. In diesem Abschnitt wird beschrieben, wie Sie mit Jersey Java-Objekte zum Erstellen von RESTful-Webdiensten mit Anmerkungen versehen.

Ich muss @Path ("/ hello") zu meiner Klasse hinzufügen, und plötzlich kann Jersey meine Ressourcenklasse finden

Nun sieht die Datei catalina.out so aus:

May 24, 2011 3:13:02 PM com.Sun.jersey.api.core.PackagesResourceConfig init
INFO: Scanning for root resource and provider classes in the packages:
com.bi.nd.webservice
May 24, 2011 3:13:02 PM com.Sun.jersey.api.core.ScanningResourceConfig logClasses
INFO: Root resource classes found:
class com.bi.nd.webservice.TransactionResource
May 24, 2011 3:13:02 PM com.Sun.jersey.api.core.ScanningResourceConfig init
INFO: No provider classes found.
May 24, 2011 3:13:02 PM com.Sun.jersey.server.impl.application.WebApplicationImpl _initiate
INFO: Initiating Jersey application, version 'Jersey: 1.7 05/20/2011 11:04 AM'

Aber das Problem ist noch lange nicht vorbei. Ich versuche, auf die URL http://localhost:8080/nd/hello zuzugreifen, und ich bekomme immer noch die 404 NOT FOUND. Ist die Provider-Klasse NICHT eine wichtige Nachricht?

20
user759646

Ich hatte die gleiche Fehlermeldung und löste sie, indem ich meine web.xml-Datei modifizierte. Stellen Sie sicher, dass es Folgendes enthält:

<init-param>
   <param-name>com.Sun.jersey.config.property.packages</param-name>
   <param-value>your.package.name.here</param-value>
</init-param>
11
Conor Pender

Ich fand einen anderen Grund, warum Jersey keine Root-Ressource finden konnte. Die Fehlermeldung ist die gleiche, daher dachte ich, es wäre ein guter Grund, die Ursache hier zu dokumentieren, falls andere Leute darauf stoßen.

Ich habe eine Stammressourcenklasse mit den folgenden Anmerkungen:

@Singleton
@Path("/helloWorld")
@Service(...) // my own custom annotation
public class MyRootResource {
...
}

Dies führt dazu, dass die Überprüfung der Stammressourcen in Jersey fehlschlägt.

Das Update besteht darin, die Reihenfolge der Anmerkungen zu ändern:

@Service(...) // my own custom annotation
@Singleton
@Path("/helloWorld")
public class MyRootResource {
...
}

Das funktioniert.

7
Tero Paananen

Beachten Sie zunächst, dass die Verwendung von @GET für eine Klasse nicht ausreicht, um sie als Stammressourcenklasse zu identifizieren. Die Klasse muss einen @Path enthalten. Ihr tut, also ist das nicht das Problem.

Ich hatte das gleiche Problem wie Sie: Es funktionierte in Eclipse, funktionierte jedoch nicht, als ich es für den externen Gebrauch baute.

Ich verwende Embedded Jetty mit einem main (), das so aussieht:

public static void main(String argv[])
{
    try
    {
        // from http://wiki.Eclipse.org/Jetty/Tutorial/Embedding_Jetty
        Server server = new Server(8080);
        ServletContextHandler contextHandler = new ServletContextHandler(ServletContextHandler.SESSIONS);
        contextHandler.setContextPath("/");
        server.setHandler(contextHandler);

        // http://stackoverflow.com/questions/9670363/how-do-i-programmatically-configure-jersey-to-use-jackson-for-json-deserializa
        final PackagesResourceConfig prc = new PackagesResourceConfig("com.ultimatefoodfight.server.api");
        final Map<String, Object> prcProperties = prc.getProperties();
        prcProperties.put(JSONConfiguration.FEATURE_POJO_MAPPING, true);

        // from http://stackoverflow.com/questions/7421574/embedded-jetty-with-jersey-or-resteasy
        contextHandler.addServlet(new ServletHolder(new ServletContainer(prc)), "/*");

        server.start();
        server.join();
    }
    catch(Exception e)
    {
        System.out.println(e);
    }
}

(Beim Einbetten von Jetty ersetzt dies eine web.xml.) Com.Sun.jersey.api.core.PackagesResourceConfig durchsucht die benannten Klassen nach Root-Ressourcenanbieter-Klassen. Ich bin sicher, die web.xml zeigt nur auf das Gleiche. In Eclipse hat das gut funktioniert. Der Serverstart meldet dies in der Konsole korrekt:

INFO: Scanning for root resource and provider classes in the packages:
  com.ultimatefoodfight.server.api
Jul 29, 2012 7:31:28 AM com.Sun.jersey.api.core.ScanningResourceConfig logClasses
INFO: Root resource classes found:
  class com.ultimatefoodfight.server.api.Users
  class com.ultimatefoodfight.server.api.Contests

Wenn ich jedoch die Anwendung auf einem Server starte, werden nur die ersten beiden Zeilen angezeigt, und es werden keine Root-Ressourcenklassen gefunden.

Es stellt sich heraus, dass, wenn Sie ein Gefäß herstellen, es verschiedene Möglichkeiten gibt, wie es aufgebaut wird; Wenn Sie nur die Pfade zu den Klassen auflisten, erhalten Sie nur diese Einträge. Wenn Sie jedoch mit einem Platzhalter jar auf das Verzeichnis zeigen, erhalten Sie auch alle Zwischenpfade. Sehen Sie sich diese Nachricht an, um das Beispiel zu erfahren, das mich angesprochen hat: https://groups.google.com/d/msg/neo4j/0dNqGXvEbNg/xaNlRiU1cHMJ .

Die PackagesResourceConfig-Klasse hängt davon ab, dass ein Verzeichnis mit dem Namen des Pakets vorhanden ist, um die darin enthaltenen Klassen zu finden. Ich ging zurück zu Eclipse und fand am unteren Rand des Dialogfelds "Exportieren> Jar" eine Option für "Verzeichniseinträge hinzufügen" Ich habe das eingeschaltet, das Glas wieder exportiert und dann beim Scannen meine Ressourcenklassen gefunden. Sie müssen eine vergleichbare Option in Ihrer Build-Umgebung finden.

5
Chris Westin

Ich habe gerade gute 5 oder 6 Stunden damit verbracht, damit zu ringen und habe das Problem endlich behoben. Das kann vielleicht auch für Sie funktionieren.

Den Quellcode, den ich verwendet habe, finden Sie auf der Tutorial-Seite von Lars Vogel . Mit Apache Tomcat 6.0.20, asm-all-3.3.1.jar, Jersey-Bundle-1.17.1.jar und jsr311-api-1.1.1.jar erhielt ich dieselben Ergebnisse wie das OP, d. H. 

INFO: Root resource classes found:
  class com.mypackage.MyClass
13/03/2013 4:32:30 PM com.Sun.jersey.api.core.ScanningResourceConfig init
INFO: No provider classes found.

Ich hatte die folgenden Einstellungen für die verschiedenen Implementierungsdateien:

context root = rivets
<url-pattern>/rest</url-pattern>
@Path("/hello")

Beim Versuch, unter Verwendung der folgenden URL auf die Ressource zuzugreifen, wurde ein 404-Fehler ausgegeben

 http://localhost:8080/rivets/rest/hello

Ich war schließlich in der Lage, das Problem durch Ändern des URL-Musters zu beheben:

<url-pattern>/rest/*</url-pattern>

Ich bin mir jedoch nicht sicher, wie sich das halten wird, wenn ich anfange, komplexere Ressourcen einzuführen. Wie auch immer, hoffentlich kann dies jemandem helfen.

3
Dave Durbin

Ich habe festgestellt, dass die Meldung "Keine Anbieterklassen gefunden" beängstigend, aber nicht wichtig ist.

"Die ResourceConfig-Instanz enthält keine Stammressourcenklassen" ist ein viel größeres Problem.

Ich habe festgestellt, dass die Ressourcenklasse mit @Path kommentiert werden muss, und die Providerklasse (wenn Sie eine haben - wir verwenden eine für die Zuordnung von Ausnahmen zu HTTP-Antwortcodes) - muss mit @Provider kommentiert werden, und beide müssen vorhanden sein das richtige Paket, und Jersey wird sie finden.

2
metamatt

möglicherweise müssen Sie eine solche URL verwenden 

http://localhost:8080/<web_context_root>/nd/hello
1
Alex Curvers

Also las ich durch die Antworten und hatte immer noch das gleiche Problem. Ich habe es wie folgt gelöst.

"Jetty-web.xml" wurde dem Ordner "WEB-INF" hinzugefügt. Also: Src/main/webapp/WEB-INF/jetty-web.xml

Der Inhalt der jetty-web.xml ist: 

<?xml version="1.0"  encoding="ISO-8859-1"?>
<!DOCTYPE Configure PUBLIC "-" "http://www.Eclipse.org/jetty/configure.dtd">
<Configure class="org.Eclipse.jetty.webapp.WebAppContext">
    <Set name="contextPath">/YourEndpoint</Set>
</Configure>

Mein Rest ist jetzt verfügbar an:

http://localhost:8080/YourEndpoint/webresources/someMethod

Hoffe, das hilft jemandem da draußen.

1

Um dieses Problem zu beheben, überprüfen Sie Ihre Klasse MapperIn. Hier müssen Sie den Pfad angeben:

import javax.ws.rs.GET;
import javax.ws.rs.OPTIONS;
import javax.ws.rs.Path;
import javax.ws.rs.PathParam;
import javax.ws.rs.Produces;
import javax.ws.rs.core.MediaType;

import com.lot.account.api.doc.GetMemberAccountsIn;
import com.lot.common.doc.CommonApi;
import com.lot.common.doc.FlowData;
import com.lot.security.authorization.RequestData;


@Path("/account/member/")
public class MapperIn {

    @GET
    @Produces(MediaType.APPLICATION_JSON)
    @Path("/{memberId}")
    public GetAccountIn prepareGetAccount(@PathParam("memberId") String memberId) {

        // create apiInput
        GetAccountIn apiInput = new GetAccountIn ();

        // map values from url
            apiInput.setMemberId(memberId);


        return apiInput;
    }
//...
}
0
Sylwester Z

Ich hatte das gleiche Problem. Gelöst wurde es, indem in der web.xml der param-value unter init-param-Tag ..__ korrigiert wurde. Standardmäßig hatte Eclipse in der web.xml den Namen des Projekts in display-name festgelegt. Das darf nicht in den param-value kopiert werden, sondern in das Java-Paket.

  <init-param>
    <param-name>com.Sun.jersey.config.property.packages</param-name>
    <param-value>com.test.demo</param-value>
    </init-param> 

Hoffe das hilft.

0
sari