"Ueberladen" von REST-Methoden in JAX-RS

[Christoph Schneegans]

Hallo allerseits!

Ich arbeite mit RESTEasy unter JBoss 7.1.1.

Ich hatte eigentlich gehofft, daß ich zwei REST-Methoden unter
demselben Pfad anlegen kann, die sich in den Query-Parametern
unterscheiden, so daß eine Art Überladung entsteht:

import javax.ws.rs.GET;
import javax.ws.rs.Path;
import javax.ws.rs.QueryParam;
import javax.ws.rs.core.Response;

@Path("/foo")
public class Resource
{
@GET
@Path("/bar")
public Response getA(@QueryParam("a") final String a)
{
return null;
}

@GET
@Path("/bar")
public Response getB(@QueryParam("b") final String b)
{
return null;
}
}

Das gelingt aber nicht zuverlässig. Bei der Anfrage /foo/bar?a=123
wird in etwa der Hälfte der Fälle getA() aufgerufen, ansonsten
getB(). In getA() wird dann der Parameter a auch korrekt gesetzt, in
getB() erhält b natürlich einen Null-Verweis.

Ist diese Situation in JAX-RS spezifiziert? Verhalten sich andere
Implementierungen vielleicht bess^Wanders?

--
<http://schneegans.de/computer/safer/> · SAFER mit Windows

[Lothar Kimmeringer]

Christoph Schneegans wrote:

> Ich hatte eigentlich gehofft, da� ich zwei REST-Methoden unter

> demselben Pfad anlegen kann, die sich in den Query-Parametern

> unterscheiden, so da� eine Art �berladung entsteht:

Hab die Spezifikation auch nicht 100%-ig im Kopf, aber ich
glaube nicht, dass Query-Parameter Bestandteil des URL-
Methoden-Mappings sind.

> @GET
> @Path("/bar")
> public Response getA(@QueryParam("a") final String a)
> {
> return null;
> }
>
> @GET
> @Path("/bar")
> public Response getB(@QueryParam("b") final String b)
> {
> return null;
> }
> }
>

> Das gelingt aber nicht zuverl�ssig. Bei der Anfrage /foo/bar?a=123
> wird in etwa der H�lfte der F�lle getA() aufgerufen, ansonsten

> getB(). In getA() wird dann der Parameter a auch korrekt gesetzt, in

> getB() erh�lt b nat�rlich einen Null-Verweis.

>
> Ist diese Situation in JAX-RS spezifiziert? Verhalten sich andere
> Implementierungen vielleicht bess^Wanders?

Ist IMHO nicht spezifiziert, je nach Implementierung des darunter-
liegenden HTTP-Servers kann es sogar sein, dass es unmoeglich ist,
bei der Servlet/Methoden-Ermittlung den QueryString in der Hand
zu haben.

Persoenlich wuerde ich das ueber eine Methode mit beiden Query-
Parametern in der Signatur zu loesen.


Gruesse, Lothar
--
Lothar Kimmeringer E-Mail: spam...@kimmeringer.de
PGP-encrypted mails preferred (Key-ID: 0x8BC3CD81)

Always remember: The answer is forty-two, there can only be wrong
questions!

[Christoph Schneegans]

Lothar Kimmeringer schrieb:

>> Ich hatte eigentlich gehofft, da� ich zwei REST-Methoden unter

>> demselben Pfad anlegen kann, die sich in den Query-Parametern

>> unterscheiden, so da� eine Art �berladung entsteht:

>
> Hab die Spezifikation auch nicht 100%-ig im Kopf, aber ich
> glaube nicht, dass Query-Parameter Bestandteil des URL-
> Methoden-Mappings sind.

Danke f�r deine Antwort!

Ich wollte interessehalber es mal mit Jersey (statt RESTEasy)
ausprobieren, aber ich kriege Jersey 1.16 (die neueste
Version) unter JBoss 7.1.1 nicht zum Laufen. Es wird empfohlen,
bspw. in der standalone.xml die Elemente

<extension module="org.jboss.as.jaxrs"/>
<subsystem xmlns="urn:jboss:domain:jaxrs:1.0"/>

auszukommentieren, um RESTEasy zu deaktivieren. Das klappt auch,
doch das Deployment einer Applikation, die Jersey verwendet,
scheitert nun stets mit dieser Ausnahme:

java.lang.UnsupportedOperationException: JBAS011859: Naming context is read-only
at org.jboss.as.naming.WritableServiceBasedNamingStore.requireOwner(WritableServiceBasedNamingStore.java:126)
at org.jboss.as.naming.WritableServiceBasedNamingStore.createSubcontext(WritableServiceBasedNamingStore.java:116)
at org.jboss.as.naming.NamingContext.createSubcontext(NamingContext.java:338)
at org.jboss.as.naming.InitialContext.createSubcontext(InitialContext.java:229)
at org.jboss.as.naming.NamingContext.createSubcontext(NamingContext.java:346)
at javax.naming.InitialContext.createSubcontext(InitialContext.java:483)
at com.sun.jersey.server.impl.cdi.CDIExtension$1.stepInto(CDIExtension.java:280)
at com.sun.jersey.server.impl.cdi.CDIExtension.diveIntoJNDIContext(CDIExtension.java:267)
at com.sun.jersey.server.impl.cdi.CDIExtension.createJerseyConfigJNDIContext(CDIExtension.java:273)
at com.sun.jersey.server.impl.cdi.CDIExtension.initialize(CDIExtension.java:192)
at com.sun.jersey.server.impl.cdi.CDIExtension.beforeBeanDiscovery(CDIExtension.java:297)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at org.jboss.weld.util.reflection.SecureReflections$13.work(SecureReflections.java:264)
at org.jboss.weld.util.reflection.SecureReflectionAccess.run(SecureReflectionAccess.java:52)
at org.jboss.weld.util.reflection.SecureReflectionAccess.runAsInvocation(SecureReflectionAccess.java:137)
at org.jboss.weld.util.reflection.SecureReflections.invoke(SecureReflections.java:260)
at org.jboss.weld.introspector.jlr.WeldMethodImpl.invokeOnInstance(WeldMethodImpl.java:170)
at org.jboss.weld.introspector.ForwardingWeldMethod.invokeOnInstance(ForwardingWeldMethod.java:51)
at org.jboss.weld.injection.MethodInjectionPoint.invokeOnInstanceWithSpecialValue(MethodInjectionPoint.java:154)
at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:241)
at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:229)
at org.jboss.weld.event.ObserverMethodImpl.notify(ObserverMethodImpl.java:207)
at org.jboss.weld.bootstrap.events.AbstractContainerEvent.fire(AbstractContainerEvent.java:75)
at org.jboss.weld.bootstrap.events.AbstractDefinitionContainerEvent.fire(AbstractDefinitionContainerEvent.java:46)
at org.jboss.weld.bootstrap.events.BeforeBeanDiscoveryImpl.fire(BeforeBeanDiscoveryImpl.java:46)
at org.jboss.weld.bootstrap.WeldBootstrap.startInitialization(WeldBootstrap.java:322)
at org.jboss.as.weld.WeldContainer.start(WeldContainer.java:81)
at org.jboss.as.weld.services.WeldService.start(WeldService.java:76)
at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1811)
at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1746)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
at java.lang.Thread.run(Thread.java:722)

Ich bin da ziemlich ratlos. Verwendet hier denn jemand Jersey unter
JBoss 7.x?

--
<http://schneegans.de/lv/> � Validator f�r BCP 47