eclipse-ee4j / jersey Goto Github PK
View Code? Open in Web Editor NEWEclipse Jersey Project - Read our Wiki:
Home Page: https://github.com/eclipse-ee4j/jersey/wiki
License: Other
Eclipse Jersey Project - Read our Wiki:
Home Page: https://github.com/eclipse-ee4j/jersey/wiki
License: Other
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:
When the intermittent failure occurs, the service logs:
Foo: {}
It works something like 95% of the time.
Operating System: All
Platform: All
Classify the runtime-dependent jars into the following categories:
core, the required set of core runtime jars;
container, the jars dependent for a container;
entity, the jars dependent for entity providers; and
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.
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
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.
Operating System: All
Platform: All
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.
Operating System: All
Platform: All
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
Operating System: All
Platform: Sun
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.
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.
Operating System: All
Platform: All
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.
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.
Operating System: All
Platform: All
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).
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());
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. -->
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.
Operating System: All
Platform: PC
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.
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.
Operating System: All
Platform: Sun
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:
you can do that via providing your own a JAXBContextResolver.
For instance:
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; }
}
Operating System: All
Platform: Sun
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.
Operating System: All
Platform: Sun
It does not throw IllegalArgumentException as specified in API javadoc
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
Operating System: Windows XP
Platform: All
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:
it only supports types that are annotated with @XmlRootElement, in
this case the type is Object; and
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); }
...
}
Operating System: All
Platform: Sun
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.
Operating System: All
Platform: All
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.
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.
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.
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.
Operating System: All
Platform: Sun
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")
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.
Operating System: All
Platform: All
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
< HTTP/1.1 307GET /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: /
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/
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
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; }
{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; }
}
Operating System: All
Platform: All
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;
/**
*
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() );
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.
Operating System: All
Platform: Sun
See request:
https://jersey.dev.java.net/servlets/ReadMsg?list=users&msgNo=55
Operating System: All
Platform: All
java.io.Reader could be a recognised return type for @get methods, just like
InputStream is.
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; }
{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
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.
Operating System: Windows XP
Platform: All
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.
Operating System: All
Platform: Sun
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.
Operating System: All
Platform: Sun
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.
Operating System: All
Platform: All
Like JAX-WS, see:
http://blogs.sun.com/arungupta/entry/totd_1_soap_messaging_logging
Operating System: All
Platform: All
Change the directory name from "examples" to "samples".
Operating System: All
Platform: All
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/
Operating System: All
Platform: Sun
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.
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.
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.
Operating System: All
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.
Operating System: All
Platform: Sun
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);
}
}
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.
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.
Operating System: All
Platform: All
[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 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.
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)
...
Operating System: All
Platform: Macintosh
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.