javaee / jersey Goto Github PK

One of the features of Jersey 0.5 is to describe sub-resources when a GET is
issued on a sub-resource with "Accept: application/vnd.sun.wadl+xml".

Problem:
I think there is a bug in the jersey, when I issue GET on
/customers/

{customerId}

(ie say /customers/1 and with Accept:
application/vnd.sun.wadl+xml),
I get a 406 from server (the resource do not support the specified accept header
value), whereas this request for non-template sub-resources like
/customers/googlemap.

I need to use this function to display sub-resources on test client for NB6.1
RESTful Web Service tooling support.

Steps to reproduce:

Please follow instructions in http://www.netbeans.org/kb/60/websvc/rest.html to
create a CustomerDB RESTful Web Service (you need a daily build of NB6.1 +
latest RESTful Web Service plugin). Then using java client or XmlHttpRequest,
make a GET request on /customers/1 (with "Accept: application/vnd.sun.wadl+xml")

Environment

Operating System: All
Platform: All

[jersey lib in NB 6.1 dev - should be sth between 0.6 - 0.6.1]

I understand that WADL is not intended to be human readable document, but
sometimes it is useful to open it in the editor, so:

-download WADL produced by jersey
-open it in NetBeans IDE (or just use 'cat some.wadl' on *nix system)

Actual:
everything is written on one line - cat's output is only one very long line of
"some" characters

Expected:
formated WADL ("xml") is shown

BTW:
would be also good if there would be the a simple comment saying which jersey
version has been used to generate the WADL at the beginning. Ie. sth like what
JAX-WS has:

!-- Published by JAX-WS RI at http://jax-ws.dev.java.net. RI's version is JAX-WS
RI 2.1.3.1-hudson-417-SNAPSHOT. -><!- Generated by JAX-WS RI at
http://jax-ws.dev.java.net. RI's version is JAX-WS RI
2.1.3.1-hudson-417-SNAPSHOT. -->

Environment

Operating System: All
Platform: All

com.sun.ws.rest.impl.container.config.AnnotatedClassScanner fails whenresource
and provider classes are loaded via an URLClassLoader with whitespace characters
in the URLs.

Snipped trace:

java.lang.IllegalArgumentException
at java.net.URI.create(Unknown Source)
at
com.sun.ws.rest.impl.container.config.AnnotatedClassScanner.index(AnnotatedClassScanner.java:204)
at
com.sun.ws.rest.impl.container.config.AnnotatedClassScanner.scan(AnnotatedClassScanner.java:113)
at
com.sun.ws.rest.api.core.PackagesResourceConfig.init(PackagesResourceConfig.java:90)
Caused by: java.net.URISyntaxException: Illegal character in path at index 28:
file:/C:/work/workspace/Mule 1.4.3
eval/lib/mule-rest-demo.jar!/com/censored/mule/demo/rest
at java.net.URI$Parser.fail(Unknown Source)
at java.net.URI$Parser.checkChars(Unknown Source)
at java.net.URI$Parser.parseHierarchical(Unknown Source)
at java.net.URI$Parser.parse(Unknown Source)
at java.net.URI.(Unknown Source)

Line 205 of AnnotatedClassScanner (revision 867) reads:

URI jarUri = URI.create(u.getSchemeSpecificPart());

Which fails as escaped characters are decoded. Should probably be:

URI jarUri = URI.create(u.getRawSchemeSpecificPart());

Environment

Operating System: All
Platform: All

When the developer returns a response with an invalid media type, for example:

return Response.ok(e, "matrix").build();

The runtime will validate the response after the HTTP method as returned the
response value. This will result in an exception and error message but the
message is unclear on the precise cause and the exception could be thrown closer
to the location of the error.

Environment

Operating System: All
Platform: Sun

It does not throw IllegalArgumentException as specified in API javadoc

Environment

Operating System: All
Platform: All

Inside a ClassLoader, we have the need to deploy multiple Resources. Such
resources are sharing the same type of EntityProvider. In each resource context,
we could have the requirement to tune the marsh/unmarsh. For example, the
EntityProvider JAXBContext can be extended or not with some specific types.

Currently EntityProvider are statically shared. Passing a list of Provider
instances at Container construction time would solve this issue.

Environment

Operating System: All
Platform: Sun

Developers wishing to embed Jersey support into their application will likely
utilize the popular Servlet standard to manage HTTP requests and pass them on to
the Jersey runtime for processing. The existing ServletAdapter class would be
ideal for developers to extend accomplish this except:

1. It is in the Jersey implementation package and not in the SPI implying it is
not intended to be used directly by developers.

2. It's ResourceConfig and WebApplication instances are not exposed to
subclasses and cannot be modified.

If the Servlet Adaptor class were moved to the SPI package and a new abstact
method added to it with the following signature:

WebApplication setup(){

}

were added then developers could provide their own customized ResourceConfig
implementation along with modifying the WebApplication instance as needed (i.e.
adding injectables).

Environment

Operating System: All
Platform: All

When generating a response message using the Jersey API, when the message is
sent the "content-length" header field is not set automatically.

It would be nice if the Jersey API could do this rather than computing this and
setting it manually.

Environment

Operating System: All
Platform: PC

If you run the script after replacing one of the examples, the script will fail.
The output in such case will be something like:

-cuthere-
Buildfile: jersey-on-glassfish.xml

install:
[mkdir] Created dir:
/export/home/japod/NetBeansProjects/test/jersey-0.5-ea/gf-home/jersey
[mkdir] Created dir:
/export/home/japod/NetBeansProjects/test/jersey-0.5-ea/gf-home/jersey/lib
[copy] Copying 15 files to
/export/home/japod/NetBeansProjects/test/jersey-0.5-ea/gf-home/jersey/lib
[copy] Copying 358 files to
/export/home/japod/NetBeansProjects/test/jersey-0.5-ea/gf-home/jersey/docs
[mkdir] Created dir:
/export/home/japod/NetBeansProjects/test/jersey-0.5-ea/gf-home/jersey/examples
[copy] Copying 38 files to
/export/home/japod/NetBeansProjects/test/jersey-0.5-ea/gf-home/jersey/examples/Bookmark
[copy] Copied 33 empty directories to 3 empty directories under
/export/home/japod/NetBeansProjects/test/jersey-0.5-ea/gf-home/jersey/examples/Bookmark
[move] Moving 1 file to
/export/home/japod/NetBeansProjects/test/jersey-0.5-ea/gf-home/jersey/examples/Bookmark/nbproject
[copy] Copying 26 files to
/export/home/japod/NetBeansProjects/test/jersey-0.5-ea/gf-home/jersey/examples/Bookstore
[move] Moving 1 file to
/export/home/japod/NetBeansProjects/test/jersey-0.5-ea/gf-home/jersey/examples/Bookstore/nbproject
[copy] Copying 16 files to
/export/home/japod/NetBeansProjects/test/jersey-0.5-ea/gf-home/jersey/examples/EntityProvider
[move] Moving 1 file to
/export/home/japod/NetBeansProjects/test/jersey-0.5-ea/gf-home/jersey/examples/EntityProvider/nbproject

BUILD FAILED
/export/home/japod/NetBeansProjects/test/jersey-0.5-ea/jersey-on-glassfish.xml:103:
The following error occurred while executing this line:
/export/home/japod/NetBeansProjects/test/jersey-0.5-ea/jersey-on-glassfish.xml:43:
/export/home/japod/NetBeansProjects/test/jersey-0.5-ea/examples/GlassfishDB not
found.

Total time: 1 second
-cuthere-

We need to make the script "missing examples tolerant"

Available workaround for the moment is described at:
http://www.rekk.de/bloggy/?p=40

Environment

Operating System: All
Platform: Sun

java.io.Reader could be a recognised return type for @get methods, just like
InputStream is.

Environment

Operating System: All
Platform: All

The URI matching algorithm as implemented operates on the decoded (un-escaped)
URI path. It needs to operate on the encoded path (escaped) such that encoded
and decoded URI template values can be correctly returned.

Environment

Operating System: All
Platform: All

I have a resource class that takes a matrix parameter and the value is a URL
like 'http://www.yahoo.com'. Obviously the URL is URL encoded on the client
side before making a GET request.

This is what it looks like on the client side:
http://localhost:8080/myresource;url=http%3A%2F%2Fwww.yahoo.com>

When the above request URL gets to the server side, it will look something like
this:
http://localhost:8080/myresource;url=http://www.yahoo.com

The WebApplicationImpl.stripMatrixParams() method doesn't seem to parse the
above URL correctly.

For example if the input to the method stripMatrixParams() is
'/myresource;url=http://www.yahoo.com', the output is
'/myresource//www.yahoo.com'. Because of this the RootResourceClass.dispatch()
method will not able to find a UriTemplateDispatcher and ends up being a 404
response.

Environment

Operating System: All
Platform: All

Jersey lacks support of URIs containing contiguous slashes ("//").

Specifically it is not possible to use URIs like
http://any.net/bookmarks/1/http://any.other.net
for embedded URIs,
and URIs like http://any.net/A//customers//
for AJAX based applications.

Such URIs are correct and Jersey as a REST based
framework should enable them.

Environment

Operating System: All
Platform: Sun

In the context of a RestFull Adaptor for JMX, we can have a need to provide an
MBeanServer instance to the Resource. It is currently not doable.

Environment

Operating System: All
Platform: Sun

I am working on integrating Jersey with another open source project. The other
project will maintain multiple Jersey SPI WebApplication instances as well as
instantiate and manage the Resource instances. The ResourceProviderFactory does
exactly what I need except it functions globally instead of per web application.

Consider the following object graph:

WebApplicationFactory.getInstance()
-> WebApplicationImpl
-> RootResourceClass
-> ResourceProviderFactory
-> MyCustomResourceProvider

MyCustomResourceProvider is instantiated inside the Jersey RI and there is
currently now way to retrieve a reference to it to further modify it. How can it
know which context it is operating in? The resources injected in one
WebApplication instance may be different then the resources injected into the
same class in a different WebApplication instance.

I will submit a patch that I made locally to add the ResourceProviderFactory as
an additional property on the WebApplication interface. I made this change as
the most non-intrusive modification I could make yet still achieve the
functionality that I needed. Probably using the builder pattern would be more
appropriate than the factory pattern in this usage scenario.

Environment

Operating System: All
Platform: All

I created the context with
server.createContext("/ships", shipHandler);

If I send a query to http://localhost:9998/ships, and get a
StringIndexOutOfBoundsException in AbstractContainerRequest.getEncodedPath()
while executing completeUri.getRawPath().substring(baseUri.getRawPath().length())

The completeUri.getRawPath() is "/ships" (as in the HTTP-Request), and
baseUri.getRawPath() is "/ships/". The substring could not be loaded because
baseUri.getRawPath().length() ist 7, but the length of completeUri.getRawPath()
is only 6.

Environment

Operating System: Windows XP
Platform: All

Please see https://glassfish.dev.java.net/issues/show_bug.cgi?id=4387

Following is the original report from Juergen:

2008-03-05 11:41:07 WebModule[/labor]PWC1396: Servlet /labor threw load() exception
com.sun.ws.rest.api.container.ContainerException: The ResourceConfig instance
does not contain any root resource classes.
at
com.sun.ws.rest.impl.application.WebApplicationImpl.processRootResources(WebApplicationImpl.java:265)
at
com.sun.ws.rest.impl.application.WebApplicationImpl.initiate(WebApplicationImpl.java:215)
at
com.sun.ws.rest.spi.container.servlet.ServletContainer.initiate(ServletContainer.java:334)
at
com.sun.ws.rest.spi.container.servlet.ServletContainer.init(ServletContainer.java:109)
at
org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1178)
at org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:1007)
at
org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java:4800)
at org.apache.catalina.core.StandardContext.start(StandardContext.java:5188)
at com.sun.enterprise.web.WebModule.start(WebModule.java:327)
at com.sun.enterprise.web.LifecycleStarter.doRun(LifecycleStarter.java:58)
at
com.sun.appserv.management.util.misc.RunnableBase.runSync(RunnableBase.java:296)
at
com.sun.appserv.management.util.misc.RunnableBase.run(RunnableBase.java:330)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:885)
"server_2008-03-05.log" 48 lines, 3812 characters

Deploying a web application throws the above error message. I have no clue what
is going wrong.
The same applicatiion runs fine with tomcat5.5 and tomcat6. Tomacat 6 gotten
from sun together with glassfishv2.

Environment

Operating System: All
Platform: Sun

When using the WebApplicationException method to return a HTTP 500, Jersey
actually returns 200 (OK) as a response.

This was working for Jersey 0.4ea

Simple Example:

Server Side Resource Code

import javax.ws.rs.ConsumeMime;
import javax.ws.rs.GET;
import javax.ws.rs.Path;
import javax.ws.rs.ProduceMime;
import javax.ws.rs.WebApplicationException;
import javax.ws.rs.core.Response;

@path("/example")
@ConsumeMime("application/xml")
@ProduceMime(

{"application/xml", "application/json"}

)
public class ExampleResource {

@get
public Response get()

{ throw new WebApplicationException(500); }

}

Client Side Code:

import com.sun.ws.rest.impl.client.ResourceProxy;
import com.sun.ws.rest.impl.client.ResponseInBound;
import com.usharesoft.client.filters.CacheFilter;

/**
*

• @author jweir
  */
  public class ExampleTest {

public static void main(String[] args) {

try

{ // Adding the filters ResourceProxy r = ResourceProxy.create("http://127.0.0.1:9998/example"); r.addFilter(new CacheFilter()); // Treat the response ResponseInBound ri = r.get(ResponseInBound.class); System.out.println("Return code is: "+ri.getStatus()); }

catch (Exception ex)

{ System.out.println("Contacting the server"); ex.printStackTrace(); }

return;
}
}

When running: output from the client

Return code is: 200

There is currently a workaround proposed by Martin Grotzke

replace

throw new WebApplicationException(500);

with something like:

throw new WebApplicationException( Response.serverError()
.type( "application/xml" ).entity( createAPIError( e ) ).build() );

Environment

Operating System: All
Platform: All

If a resource class has 2 GET's with same media types but different parameter
lists, the deployment is OK and the generated WADL would have both method listed.

I think if the usage is wrong deployment should fail in the first place, also
any validations should catch it during design time. Specs/documentation should
also make it clear, if not already.

Environment

Operating System: All
Platform: All

It would be great if JSR 311 specs or some sample or documentation confirm the
support for packaging resources in jars to be included by web applications.

Environment

Operating System: All
Platform: Sun

Using Jersey 0.5-ea
In the test case
if i request a url http://localhost:10000/repository/test/ then it works as
expected and prints Directory however if I request
http://localhost:10000/repository/test then it gives a status 307:
curl -v http://localhost:10000/repository/test

• About to connect() to localhost port 10000
• Trying 127.0.0.1... connected
• Connected to localhost (127.0.0.1) port 10000

  GET /repository/test HTTP/1.1
  User-Agent: curl/7.15.5 (i686-redhat-linux-gnu) libcurl/7.15.5 OpenSSL/0.9.8b
  zlib/1.2.1 libidn/0.6.5
  Host: localhost:10000
  Accept: /

  < HTTP/1.1 307
  < Content-length: 0
  < Location: http://localhost:10000/repository/test/
• Connection #0 to host localhost left intact
• Closing connection #0

if I comment out the method 2 with the path "

{path}/"
then accessing the url with the trailing / gives a status 404

curl -v http://localhost:10000/repository/test/

• About to connect() to localhost port 10000
• Trying 127.0.0.1... connected
• Connected to localhost (127.0.0.1) port 10000

GET /repository/test/ HTTP/1.1
User-Agent: curl/7.15.5 (i686-redhat-linux-gnu) libcurl/7.15.5 OpenSSL/0.9.8b
zlib/1.2.1 libidn/0.6.5
Host: localhost:10000
Accept: /

< HTTP/1.1 404 Not Found
< Content-length: 0

• Connection #0 to host localhost left intact
• Closing connection #0

and without the trailing slash prints "Processing request" as expected

It seems to be an error in the url matching.
I would expect that with the trailing slash method 2 to be matched
without the slash method 1 to be matched, and if method 2 is commented out then
method 1 to be matched in both cases.

Test case:
@path("/repository")
public class FileSystemRepository
{
//Method1
@get
@path("{path}

")
@ProduceMime("/")
public Response getResource(@HttpContext
Request request,
@HttpContext UriInfo uriInfo,
@UriParam("path") String path)

{ Response response=Response.ok().build(); System.out.println("Processing request"); return response; }

//Method 2
@get
@path("

{path}

/")
@ProduceMime("/")
public Response getResourceDir(@HttpContext
Request request,
@HttpContext UriInfo uriInfo,
@UriParam("path") String path)

{ Response response=Response.ok().build(); System.out.println("Directory"); return response; }

}

Environment

Operating System: All
Platform: All

REST methods are encouraged to throw WebApplicationException when there are
problems handling a request. The various WebApplicationException constructors
allow you to provide a Response to describe the error. In my experience, REST
services usually return a HTTP 200 response with their own error content when
there is a problem. However, to build a Response for one's error messages to
put in your WebApplicationException with Jersey requires that you use
Response.type(mimeType), otherwise Jersey returns a default "application/octet"
one. This makes for messy REST methods, as the only way to return meaningful
error content with the proper content type is to either return it directly
(which goes against the Java contract of throwing an Exception), or negotiate
the content type one's self by inspecting the HttpHeaders. It seems like
Response.Builder should default to negotiating the content type based on the
request, just like normal returns of JAXB content do. Or if that is not
possible, Jersey should at least provide some method that does the negotiation
part for you.

Environment

Operating System: All
Platform: All

Make ComponentProviders support dependency injection of proxied resources.

Resources returned from a custom ComponentProvider may be proxied e.g using
cglib and Jersey will fail to inject dependencies on that object.

ComponentProvider instances either need access to a ResourceProviderContext to
do the DI on the target object, or the ComponentProvider interface needs to have
another method such as Object getInjectableInstance(Object resource) that Jersey
can call and perform injection on the returned instance.

Environment

Operating System: All
Platform: All

Support the Last-Modified header when returning dynamically generated WADL
documents.

The Last-Modified could be based on the time the WebApplication was initialized.
Some changes to the HttpContextAccess iface will be required to access a
property bag where the initialization date could be added to.

Environment

Operating System: All
Platform: All

Affected Versions

[1.0, 1.0.1, 1.0.2, 1.0.3, 1.1.0-ea, 1.1.1-ea, 1.1.2-ea, 1.1.3-ea, 1.1.4, 1.1.5, 1.2, 1.3, 1.4, 1.5, 1.6, 1.7, 1.8, 1.9, 1.9.1]

The currently service finding functionality used for finding a suitable entity
provider for a Java type will iterate through the classes in order as declared
in the META-INF/services/javax.ws.rs.ext.EntityProvider file.

If a class is not present in the class path then a ClassNotFoundException is
thrown. Currently this requires that for the use the JSONArray and JSONObject
types that all jars of other dependent entity providers are in the classpath
such as those for atom or JAXB.

The finding functionality requires modification to skip over classes in the
META-INF/services that are not found.

Environment

Operating System: All
Platform: All

See request:

https://jersey.dev.java.net/servlets/ReadMsg?list=users&msgNo=55

Environment

Operating System: All
Platform: All

Jersey get IllegalArgumentException with query param of JAX-B generated type like:

@XmlType(name = "casingEnum")
@XmlEnum
public enum CasingEnum {

@XmlEnumValue("Upper")
UPPER("Upper"), @XmlEnumValue("Lower")
LOWER("Lower"),
@XmlEnumValue("Proper")
PROPER("Proper");
private final String value;

CasingEnum(String v)

{ value = v; }

public String value()

{ return value; }

public static CasingEnum fromValue(String v) {
for (CasingEnum c: CasingEnum.values()) {
if (c.value.equals(v))

{ return c; }

}
throw new IllegalArgumentException(v);
}
}

Environment

Operating System: All
Platform: All

The task need to search for resource on classpath to support scenario of having
webapp referencing resources defined in its included jars.

Note that maybe WebResourceProcessor task need to look for resource declaration
in wadl files in jars to avoid performance problem with large class path.

Environment

Operating System: All
Platform: Sun

The Jersey 0.4 stable release does not implement Produce/ConsumeMime annotations
declared on entity providers.
Implement for the 0.5 stable release.

Environment

Operating System: All
Platform: All

Rename com.sun.ws.rest.api.client.ResourceProxy to
com.sun.ws.rest.api.client.WebResource as suggested by Stefan Tilkov. Also
rename corresponding methods to get access to a WebResource.

Environment

Operating System: All
Platform: Sun

I was using Jersey to expose my JPA/Hibernate-backed object model using the
built-in JAXBElementProvider. I came across a problem where Jersey kept
tripping on uninitialized persistent fields when trying to marshal the object to
XML, and throwing LazyInitializationExceptions. The good news is, I came across
this issue:
https://jaxb.dev.java.net/issues/show_bug.cgi?id=280
which has a fix for the problem within JAXB. However, in order to make it work,
you have to pass a custom property to the JAXBContext
(com.sun.xml.bind.XmlAccessorFactory=true). I couldn't find any way to do this
in Jersey with the built-in JAXBContext. Even worse, there's not really a way
to extend that class to get there. So I ended up writing my own class called
XMLAccessorFactorySupportJAXBElementProvider, which is just a copy of
JAXBElementProvider, but the call to JAXBContext.newInstance() passes along the
map of custom properties.

It would just be nice if Jersey provided a hook to let callers pass along
properties to the JAXBContext. It would also be nice if Jersey could enable all
of this out of the box, so that when you have a web service that returns an
object that came from Hibernate, marshalling it to XML, (probably a pretty
common use case,) it doesn't trigger LazyInitializationExceptions.

Environment

Operating System: All
Platform: All

Jersey does not support the serialization of a return type that is Collection
where T is a JAXB element. This means that developers have to create their own
JAXB collection class for each JAXB entry class or write something more generic
themselves.

See the following thread for more details:

https://jersey.dev.java.net/servlets/BrowseList?list=users&by=thread&from=943203

Environment

Operating System: All
Platform: All

Classify the runtime-dependent jars into the following categories:

1. core, the required set of core runtime jars;

2. container, the jars dependent for a container;

3. entity, the jars dependent for entity providers; and

4. tool, the jars dependent for tooling functionality.

This will enable developers to better pick and choose the required set of jars
for their choice of container, entity providers in deployment scenarios rather
than having to select all jars.

Suggest refactoring the current lib directory with sub-directories corresponding
to the categories. Container can further be classified into servlet, lwhttp,
grizzly and jax-ws.

Environment

Operating System: All
Platform: All

Calling

javax.ws.rs.core.Cookie.parse(cookie_toParse)
cookie_toParse = "Cookie: NAME_1=Value_1;";

Jersey wiil throw java.lang.UnsupportedOperationException:

java.lang.UnsupportedOperationException
at com.sun.ws.rest.impl.provider.header.CookieProvider.fromString(CookieProvider.java:40)
at com.sun.ws.rest.impl.provider.header.CookieProvider.fromString(CookieProvider.java:29)
at javax.ws.rs.core.Cookie.parse(Cookie.java:94)
...

Environment

Operating System: All
Platform: Macintosh

Consider an enhancement to support the following:

@post
@ConsumeMime("application/xml")
public Response post(Object request) throws JAXBException

{ ... }

where Object will be an instance created from JAXB unmarshalling using the JAXB
message body reader.

There are two issues with the current JAXB message body reader:

1. it only supports types that are annotated with @XmlRootElement, in
   this case the type is Object; and

2. it has know way of determining what JAXBContext to use.

A work around is to write the following instead:

@post
@ConsumeMime("application/xml")
public void post(InputStream is) throws JAXBException {
Unmarshaller u = context.createUnmarshaller();
try

{ Object o = u.unmarshal(is); }

catch (UnmarshalException e)

{ throw new WebApplicationException(400); }

...
}

Environment

Operating System: All
Platform: Sun

Develop an implementation of a UriPathResolver using the TRIE (Prefix Tree)
algorithm. The TRIE algorithm works in O time where n is the number of
characters in the URI being resolved against a set of URI templates. This
algorithm is more scalable that the linear algorithm currently used in Jersey.

The TRIE implementation needs to be performance tested to show that it improves
on the linear implementation both for small and large data sets.

Environment

Operating System: All
Platform: All

When using the UriBuilder to construct a URI based on other URI's the
concatination is not working properly, namely:

UriBuilder.fromUri().uri().build();

According to the JavaDoc:

"Copies the non-null components of the supplied URI to the UriBuilder
replacing any existing values for those components."

An example:

private void getDistributionUri(URI distribUri) {

System.out.println("Distribution URI: "+distribUri.toString());
URI uri = UriBuilder.fromUri(getServerUri()).uri(distribUri).build();
System.out.println("Distribution URI 1: "+ uri.toString());
URI uri2 =
UriBuilder.fromUri(getServerUri()).path(distribUri.toString()).build();
System.out.println("Distribution URI 2: "+ uri2.toString());

}

where serverUri is set to: http://localhost:9998

calling this method with an uri: distributions/60ad76323ad01538900e6b8c3e41210e

provides the following output:
Distribution URI: distributions/60ad76323ad01538900e6b8c3e41210e
Distribution URI 1: distributions/60ad76323ad01538900e6b8c3e41210e
Distribution URI 2:
http://127.0.0.1:9998/distributions/60ad76323ad01538900e6b8c3e41210e

I was expecting uri1 and uri2 to be identical

Environment

Operating System: Windows XP
Platform: All

The class MultivaluedDefaultListParameterProcessor will successfully return a
MultivaluedParameterExtractor for the following types: List, String, primitives, and any object with a
valueof(String) or constructor(String).

However, this makes it difficult to use for many classes - consider either java.util.Date or joda-time
DateTime class.

Environment

Operating System: All
Platform: All

Everywhere in the Grizzly support, it seems that org.apache.coyote.Adapter was
used in place of com.sun.grizzly.tcp.Adapter. That includes the
ContainerProvider and the GrizzlyContainer, at least.

Also, no attempt has been made to catch exceptions when a ContainerProvider
throws one (in the case of the jaxws ProviderContainerProvider, which throws a
ClassDefNotFound exception on the missing Coyote Adapter class, instead of
simply returning null, which is what the ContainerFactory expects).

So right now, only the Lightweight container works, and then only in certain
circumstances (it hangs on a simple Hello World resource when I run it in prod,
but it doesn't in Debug; a sure sign of deadlock). I haven't tried the jaxws
ContainerProvider, because I simply don't see the point. Grizzly, being a
Glassfish technology, should be supported sooned rather than later.

Environment

Operating System: All
Platform: All

Like JAX-WS, see:

http://blogs.sun.com/arungupta/entry/totd_1_soap_messaging_logging

Environment

Operating System: All
Platform: All

when you try to generate JSON out of JAXB bean using attributes, it fails with:

java.lang.UnsupportedOperationException: Not supported yet.

at

com.sun.ws.rest.impl.json.writer.JsonXmlStreamWriter.writeAttribute(JsonXmlStreamWriter.java:288)

at

com.sun.xml.bind.v2.runtime.output.XMLStreamWriterOutput.attribute(XMLStreamWriterOutput.java:131)

at

com.sun.xml.bind.v2.runtime.output.XmlOutputAbstractImpl.attribute(XmlOutputAbstractImpl.java:106)

at

com.sun.xml.bind.v2.runtime.XMLSerializer.attribute(XMLSerializer.java:442)

at

com.sun.xml.bind.v2.runtime.property.AttributeProperty.serializeAttributes(AttributeProperty.java:99)

at

com.sun.xml.bind.v2.runtime.ClassBeanInfoImpl.serializeAttributes(ClassBeanInfoImpl.java:331)

at

com.sun.xml.bind.v2.runtime.XMLSerializer.childAsSoleContent(XMLSerializer.java:587)

at

com.sun.xml.bind.v2.runtime.ClassBeanInfoImpl.serializeRoot(ClassBeanInfoImpl.java:312)

you need to switch back to the one of the following JSON notations to get the
attrs working:

• BADGERFISH
• MAPPED_JETTISON

you can do that via providing your own a JAXBContextResolver.
For instance:

@Provider

public final class JAXBContextResolver implements ContextResolver {

private final JAXBContext context;

private final Set types;

private final Class[] cTypes =

{}

;

public JAXBContextResolver() throws Exception

{ Map<String, Object> props = new HashMap<String, Object>(); props.put(JSONJAXBContext.JSON_NOTATION, "BADGERFISH"); this.types = new HashSet(Arrays.asList(cTypes)); this.context = new JSONJAXBContext(cTypes, props); }

public JAXBContext getContext(Class<?> objectType)

{ return (types.contains(objectType)) ? context : null; }

}

Environment

Operating System: All
Platform: Sun

It should be possible to generate a very simple Javadoc from the classes. For
template, look here:
http://www.megginson.com/blogs/quoderat/2007/11/03/first-looks-at-opensocial-part-1-urls/

Environment

Operating System: All
Platform: Sun

I have a method that looks like this:

@uritemplate("foo")
@HttpMethod("POST")
@ConsumeMime("application/x-www-form-urlencoded")
public void foo(FormURLEncodedProperties params) {
LOG.debug("Foo: " + params);
...

I'm seeing an intermittent problem where sometimes the parameter that gets
passed to this method is empty, even though values were posted to the web
service. I verified that the values do get posted by enabling the
RequestDumperValve in Tomcat. Here is a sample request:

===============================================================
REQUEST URI =/myapp/foo
authType=null
characterEncoding=null
contentLength=80
contentType=application/x-www-form-urlencoded
contextPath=/myapp
cookie=JSESSIONID=63803DF626D45FC6EC888C268AF1231D
header=host=myserver:8080
header=user-agent=Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.6)
Gecko/20070725 Firefox/2.0.0.6
header=accept=text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,/;q=0.5
header=accept-language=en-us,en;q=0.5
header=accept-encoding=gzip,deflate
header=accept-charset=ISO-8859-1,utf-8;q=0.7,*;q=0.7
header=keep-alive=300
header=connection=keep-alive
header=cookie=JSESSIONID=63803DF626D45FC6EC888C268AF1231D
header=content-type=application/x-www-form-urlencoded
header=content-length=80
locale=en_US
method=POST
parameter=phone=555-555-5555
parameter=queues=15
parameter=partySize=2
parameter=lzbc=1200461313945.94
pathInfo=/foo
protocol=HTTP/1.1
queryString=null
remoteAddr=10.9.0.3
remoteHost=10.9.0.3
remoteUser=null
requestedSessionId=63803DF626D45FC6EC888C268AF1231D
scheme=http
serverName=myserver
serverPort=8080
servletPath=/
isSecure=false

When the intermittent failure occurs, the service logs:
Foo: {}

It works something like 95% of the time.

Environment

Operating System: All
Platform: All

Please also see GlassFish issue 4417
(https://glassfish.dev.java.net/issues/show_bug.cgi?id=4417).

The user there describes a sequence of events that leaves a JAR file in his web
application locked. The culprit seems to be Jersey at this line

com.sun.ws.rest.impl.container.config.AnnotatedClassScanner.getClassReader(com\sun\ws\rest\impl\container\config\AnnotatedClassScanner.java:262)

where a stream is opened but never closed. (This output is from an "open file
detector" tool I built and have used on numerous occasions to find this sort of
problem.) On Windows this has the result of locking the file, preventing it
from being deleted when the user tries to undeploy the application from GlassFish.

I will attach the full stack trace although I suspect the above line is enough
to pinpoint where this particular problem originates. I suppose there could be
other places as well where this flaw has crept in.

Environment

Operating System: All
Platform: All

The default for WebResourcesProcessorTask is to create a new web.xml when run which overwrites an
existing web.xml silently. The noservlet option can be used to turn this off but its easy to miss and is a
source of errors. Suggest changing the default to not create a web.xml and changing all the examples to
not use this capability so people starting a new project or copying one of the existing ones won't hit this
problem. Also suggest adding a warning when the tool overwrites an existing web.xml so users will be
aware that it is happening.

Environment

Operating System: All
Platform: All

Change the directory name from "examples" to "samples".

Environment

Operating System: All
Platform: All

Given the following resource class:

@uritemplate("/")
static public class SubResourceMethodsWithDifferentTemplates {
@uritemplate("

{foo}

")
@HttpMethod
public String getFoo(@UriParam("foo") String foo)

{ return foo; }

@uritemplate("

{bar}")
@HttpMethod
public String postBar(@UriParam("bar") String bar) { return bar; }
}

The Java method postBar will not function correctly to a POST request that
matches the URI template "{bar}

".

See the unit test [1]:

SubResourceHttpMethodsTest.testSubResourceMethodsWithDifferentTemplates

and the email thread [2] on the users list.

[1]
https://jersey.dev.java.net/source/browse/checkout/jersey/trunk/jersey/test/com/sun/ws/rest/impl/subresources/SubResourceHttpMethodsTest.java?rev=170
[2] https://jersey.dev.java.net/servlets/BrowseList?list=users&by=thread&from=895080

Environment

Operating System: All
Platform: All

For each resource class Jersey creates a runtime model so that, for performance
reasons, it is only necessary to analyze annotations using Java reflection once
per-class.

When new resource classes are added, deleted or dynamically updated (for example
using the JavaRebel framework) there needs to be a away to tell Jersey that such
classes change changed.

Consider adding a reload feature on the WebApplication that inform Jersey it
needs to reload all resource classes. Additionally it may be appropriate to have
a more fine-grained approach where by an application could tell Jersey what
resource classes have been created, updated or deleted. This potentially needs
to extend to additional components like message body readers/writers.

Environment

Operating System: All
Platform: All

Some Web containers, like Weblogic, do not support ServletContext.getRealPath
for deployed web applications, null values are returned. So the default
configuration for scanning class files in /WEB-INF/classes and /WEB-INF/lib does
not work.

However, Servlet.getResource(), returns file-based URLs, at least for Weblogic,
from which the resolved paths for /WEB-INF/classes and /WEB-INF/lib can be obtained.

See the email here for more details:

https://jersey.dev.java.net/servlets/ReadMsg?list=users&msgNo=508

If the getRealPath("/WEB-INF/classes") returns null then try the
getResource("/WEB-INF/classes) and if it returns a file-based URL then extract
the path. Otherwise thrown an exception saying the the default servlet
configuration cannot be supported.

Environment

Operating System: All
Platform: Sun

The Jersey client allows to upload files to the server, however it must be
possible to attach a listener to this upload. This will make the monitoring of
the upload progress possible.

Environment

Operating System: All
Platform: All