[JERSEY-2545] getParameter of @Context HttpServletRequest request always returns null Created: 11/Jun/14  Updated: 11/Jun/14  Resolved: 11/Jun/14

Status: Resolved
Project: jersey
Component/s: None
Affects Version/s: 1.8
Fix Version/s: 1.17

Type: Bug Priority: Major
Reporter: amrittiwana Assignee: Jakub Podlesak
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: 4 hours
Time Spent: Not Specified
Original Estimate: 4 hours


 Description   

Consider @POST @Produces( "text/html; charset=UTF-8" ) public StreamingOutput post( @Context HttpServletRequest request )

request.getParameterMap() is always empty and request.getParameter( ... ) therefore always returns null.

This was working correctly in Jersey 1.6 and is broken in Jersey 1.8. (I don't know about Jersey 1.7.)



 Comments   
Comment by amrittiwana [ 11/Jun/14 ]

Original issue JERSEY-766 marked as won't fix. But we need to have option to extract parameters from @Context HttpServletRequest request, as we want to use for Apache Oltu and its need request parameters everywhere internally. It would be great if this can be fixed. We are using jersey version 1.18.1.

Comment by amrittiwana [ 11/Jun/14 ]

NVMD found workaround by extending HttpServletRequestWrapper

Comment by Jakub Podlesak [ 11/Jun/14 ]

Resolving as "won't" fix as the reporter suggested there is a workaround for the affected use case.





[JERSEY-1907] Jersey Spring : Application instanciated twice in recent tomcat servers Created: 03/Jun/13  Updated: 08/Aug/13  Resolved: 25/Jul/13

Status: Resolved
Project: jersey
Component/s: extensions
Affects Version/s: 1.16, 1.17, 1.18
Fix Version/s: 1.17

Type: Bug Priority: Blocker
Reporter: baudryvincent Assignee: Unassigned
Resolution: Invalid Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Tomcat 7.0.32
Jersey 1.17 / 1.18
Jersey-spring 1.17 / 1.18



 Description   

I'm using jersey and jersey spring and was before using Tomcat 7.0.25 without issues. Due to a third-party bug induced by the bug I'll describe, I have noticed an odd problem when using Tomcat 7.0.32.

The issue is the following :

  • I'm using class extending PackagesResourceConfig to manage my app configuration
  • I'm using Spring ServletContainer
  • When the app launches in Tomcat 7.0.32 a first instance of my Config class is created
  • If I call directly an url corresponding to the REST servlet, it works fine
  • When I request any file outside the REST url-pattern on the same tomcat server, my app configuration is instanciated a second, which is not normal at all and did not happen before (and has side effects on my app)

I've done some debugging and it seems that in 7.0.32 tomcat instanciates two distinct servlets to honor those requests :

  • During the web app launch, the SpringServlet seems correctly instanciated
  • When making a classic web call outside of jersey url mapping, it seems Tomcat tries to use Jersey ServletContainer directly to answer the request, and that's when my app configuration is called a second time.

I thought it was only a tomcat issue at first, but it seems more than the relationship between SpringServlet and ServletContainer causes some misbehaviors.

Tomcat impacted classes seem to be around ContainerBase.java and its new subclass StartChild which seems to instanciate a "daughter" class where before only the "mother" SpringServlet class was instanciated. Moreover, it seems the daughter class path mapping is wrong which causes her to try to answer to requests which don't concern jersey.

Please help me or feel free to give me ideas of how to get around this problem which impacts many of my apps...



 Comments   
Comment by Jakub Podlesak [ 25/Jul/13 ]

From what you described it seems there is a bug in Tomcat, not in Jersey. Could you please explain some more, why you think this is caused by Jersey?

Comment by Jakub Podlesak [ 25/Jul/13 ]

Closing as invalid, as from what you wrote this is a Tomcat issue.
Namely it is weird why Tomcat instantiates another Jersey Spring Servlet for URL pattern, that does not match your Servlet configuration.
IFUC there is nothing Jersey could do about this.

Please provide some additional details on why you think this is a Jersey bug if you want to re-open the bug report. Thanks.





[JERSEY-1879] JAXB Based JSON support not working Created: 02/May/13  Updated: 08/Aug/13  Resolved: 25/Jul/13

Status: Resolved
Project: jersey
Component/s: None
Affects Version/s: 1.17
Fix Version/s: 1.17

Type: Bug Priority: Critical
Reporter: donald212k Assignee: Unassigned
Resolution: Invalid Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

tomcat 7.0.34, Linux opensuse 12.3



 Description   

JAXB based JSON support with the Jersey 1.17 Client API does not work while posting Parameter objects.
The code listed below delivers

{{
415
[text/html;charset=utf-8]
Mai 02, 2013 10:11:13 AM com.sun.jersey.api.client.ClientResponse getEntity
SEVERE: A message body reader for Java class common.Pair, and Java type class common.Pair, and MIME media type text/html; charset=utf-8 was not found
Mai 02, 2013 10:11:13 AM com.sun.jersey.api.client.ClientResponse getEntity
SEVERE: The registered message body readers compatible with the MIME media type are:
/ ->
com.sun.jersey.core.impl.provider.entity.FormProvider
com.sun.jersey.core.impl.provider.entity.StringProvider
com.sun.jersey.core.impl.provider.entity.ByteArrayProvider
com.sun.jersey.core.impl.provider.entity.FileProvider
com.sun.jersey.core.impl.provider.entity.InputStreamProvider
com.sun.jersey.core.impl.provider.entity.DataSourceProvider
com.sun.jersey.core.impl.provider.entity.XMLJAXBElementProvider$General
com.sun.jersey.core.impl.provider.entity.ReaderProvider
com.sun.jersey.core.impl.provider.entity.DocumentProvider
com.sun.jersey.core.impl.provider.entity.SourceProvider$StreamSourceReader
com.sun.jersey.core.impl.provider.entity.SourceProvider$SAXSourceReader
com.sun.jersey.core.impl.provider.entity.SourceProvider$DOMSourceReader
com.sun.jersey.json.impl.provider.entity.JSONJAXBElementProvider$General
com.sun.jersey.json.impl.provider.entity.JSONArrayProvider$General
com.sun.jersey.json.impl.provider.entity.JSONObjectProvider$General
com.sun.jersey.core.impl.provider.entity.XMLRootElementProvider$General
com.sun.jersey.core.impl.provider.entity.XMLListElementProvider$General
com.sun.jersey.core.impl.provider.entity.XMLRootObjectProvider$General
com.sun.jersey.core.impl.provider.entity.EntityHolderReader
com.sun.jersey.json.impl.provider.entity.JSONRootElementProvider$General
com.sun.jersey.json.impl.provider.entity.JSONListElementProvider$General
com.sun.jersey.json.impl.provider.entity.JacksonProviderProxy

Exception in thread "main" com.sun.jersey.api.client.ClientHandlerException: A message body reader for Java class common.Pair, and Java type class common.Pair, and MIME media type text/html; charset=utf-8 was not found
at com.sun.jersey.api.client.ClientResponse.getEntity(ClientResponse.java:561)
at com.sun.jersey.api.client.ClientResponse.getEntity(ClientResponse.java:517)
at client.ComputeConcat.main(ComputeConcat.java:41)

package server;

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

import common.Pair;

/**
*

  • calling with data as JSON serialization instead of JAXB
  • $ curl -X POST --data-binary " { \"first\":\"Hello, \", \"second\":\"World.\" }

    " \

  • -H "Content-Type: application/json" -H "Accept: application/json" \
  • http://localhost/JAXRSServer/rs/concatEngine/concat
  • delivers
  • { "first":"Hello, World." }

    */
    @Path("/concatEngine")
    public class ConcatEngine {
    @POST
    @Path("/concat")
    // MediaType.APPLICATION_XML,
    @Consumes(

    {MediaType.APPLICATION_JSON})
    @Produces({MediaType.APPLICATION_JSON}

    )
    public Pair concat(Pair data)

    { Pair res = new Pair(); res.setFirst(data.getFirst() + data.getSecond()); return res; }

    }

package common;

import javax.xml.bind.annotation.XmlAccessType;
import javax.xml.bind.annotation.XmlAccessorType;
import javax.xml.bind.annotation.XmlRootElement;

@XmlRootElement
@XmlAccessorType(XmlAccessType.PROPERTY)
public class Pair {
protected String first;
protected String second;

public Pair() {
}

public String getFirst()

{ return first; }

public void setFirst(String first)

{ this.first = first; }

public String getSecond()

{ return second; }

public void setSecond(String second)

{ this.second = second; }

}

package client;

import javax.ws.rs.core.MediaType;

import com.sun.jersey.api.client.Client;
import com.sun.jersey.api.client.ClientResponse;
import com.sun.jersey.api.client.WebResource;
import com.sun.jersey.api.client.config.ClientConfig;
import com.sun.jersey.api.client.config.DefaultClientConfig;
import com.sun.jersey.api.client.filter.HTTPBasicAuthFilter;

import common.Pair;

public class ComputeConcat {

private static WebResource getHttpResource()

{ ClientConfig config = new DefaultClientConfig(); // config.getFeatures().put(JSONConfiguration.FEATURE_POJO_MAPPING, Boolean.TRUE); // config.getClasses().add(JSONRootElementProvider.class); Client client = Client.create(config); return client.resource( "http://localhost/JAXRSServer/rs/concatEngine/concat"); }

public static void main(String[] args)

{ Pair pair = new Pair(); pair.setFirst("Hello, "); pair.setSecond("World!"); WebResource resource = getHttpResource(); resource.addFilter(new HTTPBasicAuthFilter("exampleuser", "changeit")); // resource.accept(MediaType.APPLICATION_XML); resource.accept(MediaType.APPLICATION_JSON); resource.type(MediaType.APPLICATION_JSON); // resource.header("content-type", MediaType.APPLICATION_JSON); ClientResponse response = resource.post(ClientResponse.class, pair); System.out.println(response.getStatus()); System.out.println(response.getHeaders().get("Content-Type")); Pair res = response.getEntity(Pair.class); System.out.println(res.getFirst()); }

}
}}

My web.xml (under Tomcat) if that should be of interest:

{{
<?xml version="1.0" encoding="UTF-8"?>
<web-app id="WebApp_ID" version="3.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://java.sun.com/xml/ns/javaee"
xmlns:web="http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd"
xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd">

<display-name>JAXRSServer</display-name>

<servlet>
<servlet-name>Jersey REST Service</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>server</param-value>
</init-param>
<!-- init-param>
<param-name>com.sun.jersey.api.json.POJOMappingFeature</param-name>
<param-value>true</param-value>
</init-param -->
<load-on-startup>1</load-on-startup>
</servlet>
<servlet-mapping>
<servlet-name>Jersey REST Service</servlet-name>
<url-pattern>/rs/*</url-pattern>
</servlet-mapping>
</web-app>
}}

If changing @Consumes(

{MediaType.APPLICATION_JSON}

) to @Consumes(

{MediaType.APPLICATION_XML}

) at for the concat method (and MediaTypes), then the code operates. However, then the input pair is sent as XML and not as JSON serialization. It seems like the Jersy Client does not automatically serialize the pair object to JSON but only to XML, although imho it should.

Changing every occurrance of MediaType.APPLICATION_JSON to MediaType.APPLICATION_XML delivers as it should.

{{
200
[application/xml]
Hello, World!
}}

Then the code operates. It also suffices to Change the @Consumes part of the server method. However, then the input pair is sent as XML and not as JSON serialization. It seems like the Jersy Client does not automatically serialize the pair object to JSON but only to XML, although imho it should.

Please note, while havin all to JSON the commented curl call operates as desired, sends JSON and receives JSON.



 Comments   
Comment by donald212k [ 02/May/13 ]

Unfortunately, the line breaks are corrupted in the above post. Sorry. Here again.

ComputeConcat.java
package client;

import javax.ws.rs.core.MediaType;

import com.sun.jersey.api.client.Client;
import com.sun.jersey.api.client.ClientResponse;
import com.sun.jersey.api.client.WebResource;
import com.sun.jersey.api.client.config.ClientConfig;
import com.sun.jersey.api.client.config.DefaultClientConfig;
import com.sun.jersey.api.client.filter.HTTPBasicAuthFilter;
import common.Pair;

public class ComputeConcat {
    
    private static WebResource getHttpResource() {
        ClientConfig config = new DefaultClientConfig();
        // config.getFeatures().put(JSONConfiguration.FEATURE_POJO_MAPPING, Boolean.TRUE);
        // config.getClasses().add(JSONRootElementProvider.class);
        Client client = Client.create(config);
        return client.resource(
            "http://localhost/JAXRSServer/rs/concatEngine/concat");
    }
    

    public static void main(String[] args) {
        Pair pair = new Pair();
        pair.setFirst("Hello, "); pair.setSecond("World!");
        
        WebResource resource = getHttpResource();

        resource.addFilter(new HTTPBasicAuthFilter("exampleuser", "changeit"));        
        // resource.accept(MediaType.APPLICATION_XML);
        resource.accept(MediaType.APPLICATION_JSON);
        resource.type(MediaType.APPLICATION_JSON);
        // resource.header("content-type", MediaType.APPLICATION_JSON);
        
        ClientResponse response = resource.post(ClientResponse.class, pair);
        System.out.println(response.getStatus());
        System.out.println(response.getHeaders().get("Content-Type"));
        Pair res = response.getEntity(Pair.class);
        System.out.println(res.getFirst());
    }

}
ConcatEngine.java
package server;

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

import common.Pair;

/**
 *
 * calling with data as JSON serialization instead of JAXB
 * $ curl -X POST --data-binary "{ \"first\":\"Hello, \", \"second\":\"World.\" }" \
 *     -H "Content-Type: application/json" -H "Accept: application/json" \
 *     http://localhost/JAXRSServer/rs/concatEngine/concat
 * delivers
 * { "first":"Hello, World." }
 */
@Path("/concatEngine")
public class ConcatEngine {
    @POST
    @Path("/concat")
    // MediaType.APPLICATION_XML,
    @Consumes({MediaType.APPLICATION_JSON})
    @Produces({MediaType.APPLICATION_JSON})
    public Pair concat(Pair data) {
        Pair res = new Pair();
        res.setFirst(data.getFirst() + data.getSecond());
        return res;
    }
}
Pair.java
package common;

import javax.xml.bind.annotation.XmlAccessType;
import javax.xml.bind.annotation.XmlAccessorType;
import javax.xml.bind.annotation.XmlRootElement;

@XmlRootElement
@XmlAccessorType(XmlAccessType.PROPERTY)
public class Pair {
    protected String first;
    protected String second;

    public Pair() {
    }

    public String getFirst() {
        return first;
    }

    public void setFirst(String first) {
        this.first = first;
    }

    public String getSecond() {
        return second;
    }

    public void setSecond(String second) {
        this.second = second;
    }
}
Comment by donald212k [ 07/May/13 ]

I found my error:

resource.type(MediaType.APPLICATION_JSON);
resource.accept(MediaType.APPLICATION_JSON);
ClientResponse response = resource.post(ClientResponse.class, pair);

The methods of WebResource (ie post) always create new WebResource.Builder objects. That is setting the type to MediaType.APPLICATION_JSON is done in an object for the garbage collector, and not the one which issues post. This uses them XML by Default.

The following code operates.

WebResource resource = getHttpResource();
WebResource.Builder builder = resource.getRequestBuilder();
builder.accept(MediaType.APPLICATION_JSON_TYPE);
builder.type(MediaType.APPLICATION_JSON_TYPE);
ClientResponse response = builder.post(ClientResponse.class, pair);

However, this behavior is poorly documented in the API and contrintuitive. For chaining/fluent API the passed objects better should be changed and a reference to them returned.

I seem not to have the rights to Close this issue, so please Close it or treat the issue as closed.

Comment by Jakub Podlesak [ 25/Jul/13 ]

You do not need to register the JSONRootElementProvider manually.
The following should just work:

        ClientConfig config = new DefaultClientConfig();
        config.getFeatures().put(JSONConfiguration.FEATURE_POJO_MAPPING, Boolean.TRUE);
        
        Client client = Client.create(config);
        client.addFilter(new LoggingFilter());
        
        final WebResource resource = client.resource(CONCAT_URL);

        Pair pair = new Pair(); pair.setFirst("Hello, "); pair.setSecond("World!");
        
        System.out.println(resource.accept(MediaType.APPLICATION_JSON).type(MediaType.APPLICATION_JSON).post(Pair.class, pair));

The logging filter above is registered so that you can see what is being sent/received on the client side.





[JERSEY-1665] maven-wadl-plugin build problem with maven-plugin-plugin 3.1 Created: 22/Jan/13  Updated: 08/Aug/13  Resolved: 28/Jan/13

Status: Resolved
Project: jersey
Component/s: None
Affects Version/s: 1.17
Fix Version/s: 1.17

Type: Bug Priority: Major
Reporter: puntogil Assignee: Unassigned
Resolution: Invalid Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

fedora all version
java version "1.7.0_09-icedtea"
OpenJDK Runtime Environment (fedora-2.3.4.fc18-i386)
OpenJDK Server VM (build 23.2-b09, mixed mode)



 Description   

hi @ all,
i have a problem with the maven-plugin-plugin (3.1) available in fedora. you have any idea on how to solve?
thanks regards

[INFO] — maven-plugin-plugin:3.1:descriptor (default-descriptor) @ maven-wadl-plugin —
[ERROR]

Artifact Ids of the format maven-___-plugin are reserved for
plugins in the Group Id org.apache.maven.plugins
Please change your artifactId to the format ___-maven-plugin
In the future this error will break the build.

[INFO] Using 'UTF-8' encoding to read mojo metadata.
[INFO] Applying mojo extractor for language: java-annotations
[INFO] Mojo extractor for language: java-annotations found 0 mojo descriptors.
[INFO] Applying mojo extractor for language: java
[ERROR] com.sun.jersey.wadl.GenerateWadlMojo#_wadlFile:
[ERROR] Cannot use both:
[ERROR] @parameter expression="$

{property}

"
[ERROR] and
[ERROR] @parameter property="property"
[ERROR] Second syntax is preferred.
[INFO]
[INFO] ------------------------------------------------------------------------
[INFO] Skipping jersey-project
[INFO] This project has been banned from the build due to previous failures.
[INFO] ------------------------------------------------------------------------
[INFO] ------------------------------------------------------------------------
[INFO] Reactor Summary:
[INFO]
[INFO] jersey-project .................................... SUCCESS [0.917s]
[INFO] jersey-core ....................................... SUCCESS [11.298s]
[INFO] jersey-server ..................................... SUCCESS [5.832s]
[INFO] Contributions to Jersey ........................... SUCCESS [0.027s]
[INFO] ant-wadl-task ..................................... SUCCESS [0.303s]
[INFO] jersey-servlet .................................... SUCCESS [1.141s]
[INFO] jersey-client ..................................... SUCCESS [2.092s]
[INFO] jersey-spring ..................................... SUCCESS [0.721s]
[INFO] maven-wadl-plugin Maven Mojo ...................... FAILURE [1.405s]
[INFO] wadl-resourcedoc-doclet ........................... SKIPPED
[INFO] Jersey Apache HTTP Client ......................... SKIPPED
[INFO] jersey-multipart .................................. SKIPPED
[INFO] Jersey Apache HTTP Client 4.x ..................... SKIPPED
[INFO] Jersey FreeMarker templating engine support ....... SKIPPED
[INFO] Jersey Eclipse MOXy support ....................... SKIPPED
[INFO] jersey-simple-server .............................. SKIPPED
[INFO] jersey-guice ...................................... SKIPPED
[INFO] jersey-json ....................................... SKIPPED
[INFO] jersey-wadl-json-schema ........................... SKIPPED
[INFO] jersey-oauth ...................................... SKIPPED
[INFO] oauth-signature ................................... SKIPPED
[INFO] oauth-client ...................................... SKIPPED
[INFO] oauth-server ...................................... SKIPPED
[INFO] jersey-atom ....................................... SKIPPED
[INFO] jersey-fastinfoset ................................ SKIPPED
[INFO] Jersey Declarative Hyperlinking ................... SKIPPED
[INFO] Jersey Test Framework ............................. SKIPPED
[INFO] Jersey Test Framework - Core ...................... SKIPPED
[INFO] Jersey Test Framework - Http Module ............... SKIPPED
[INFO] Jersey Test Framework - External Module ........... SKIPPED
[INFO] Jersey Test Framework - InMemory Module ........... SKIPPED
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 26.242s
[INFO] Finished at: Tue Jan 22 13:06:32 CET 2013
[INFO] Final Memory: 34M/300M
[INFO] ------------------------------------------------------------------------
[ERROR] Failed to execute goal org.apache.maven.plugins:maven-plugin-plugin:3.1:descriptor (default-descriptor) on project maven-wadl-plugin: Error extracting plugin descriptor: 'com.sun.jersey.wadl.GenerateWadlMojo#_wadlFile: cannot use both @parameter expression and property' -> [Help 1]



 Comments   
Comment by Marek Potociar [ 28/Jan/13 ]

This is not a bug. Please direct your questions on how to locally build Jersey to users forum.





[JERSEY-1642] ResponseListener#onError is never invoked Created: 08/Jan/13  Updated: 09/Jan/13  Resolved: 09/Jan/13

Status: Resolved
Project: jersey
Component/s: core
Affects Version/s: 1.16
Fix Version/s: 1.17

Type: Task Priority: Major
Reporter: Michal Gajdos Assignee: Michal Gajdos
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

ResponseListener#onError is never invoked so there is no way to monitor (count, details, count) un-mapped exceptions thrown from a Jersey app.



 Comments   
Comment by Michal Gajdos [ 09/Jan/13 ]
  • merged into trunk




[JERSEY-1641] Upgrade to Simple 5.0.4 in Jersey 1.x Created: 07/Jan/13  Updated: 08/Jan/13  Resolved: 08/Jan/13

Status: Resolved
Project: jersey
Component/s: containers
Affects Version/s: 1.16
Fix Version/s: 1.17

Type: Improvement Priority: Major
Reporter: Arul Dhesiaseelan Assignee: Pavel Bucek
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Simple 5.x is a recent and improved version of Simple 4.x. In my tests, Simple 5.x gives a performance boost over Simple 4.x. It would be useful to update the jersey-simple-server module to support the latest version. I have patched the jersey-simple-server module to support the changes in Simple 5.x.



 Comments   
Comment by Arul Dhesiaseelan [ 07/Jan/13 ]

I do not see a way to upload my patch to JIRA issue. How do I attach my patch?

Comment by Pavel Bucek [ 07/Jan/13 ]

Hi Arul,

thanks for your contribution! Attaching files is temporarily disabled, I'm not sure when its going to be back on. Anyway, you can send your patch to our mailing list, but please note - you need to sign OCA first (otherwise we won't be able to use your patch).

Thanks,
Pavel

[1] OCA: http://www.oracle.com/technetwork/community/oca-486395.html

Comment by Arul Dhesiaseelan [ 07/Jan/13 ]

Thanks Pavel for quick response!

I mailed my signed OCA on 12/30/12. I am not sure if that is good enough to submit my patch. Here is my patch: https://gist.github.com/4478148

Do you want me to mail the patch to users@jersey or dev@jersey?

Comment by Pavel Bucek [ 07/Jan/13 ]

Can you please send me copy of signed OCA directly - pavel.bucek (at) oracle.com? Ideally with your patch attached; then, if everything seems to be ok, it should be matter of hours to accept it to Jersey 1.x main trunk.

thanks!

Comment by Arul Dhesiaseelan [ 07/Jan/13 ]

Pavel, just mailed it to you. Thanks!

Comment by Pavel Bucek [ 08/Jan/13 ]

submitted to internal review process

Comment by Pavel Bucek [ 08/Jan/13 ]

fixed in the trunk.

Comment by Arul Dhesiaseelan [ 08/Jan/13 ]

Thanks Pavel.





[JERSEY-1622] jersey-client depends on jersey-core Created: 17/Dec/12  Updated: 08/Aug/13  Resolved: 17/Dec/12

Status: Resolved
Project: jersey
Component/s: None
Affects Version/s: 1.15
Fix Version/s: 1.17

Type: Bug Priority: Major
Reporter: Yegor Bugayenko Assignee: Unassigned
Resolution: Invalid Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Duplicate
is duplicated by JERSEY-1584 Add server-side support for response ... Resolved

 Description   

com.sun.jersey.api.client.config.ClientConfig extends com.sun.jersey.core.util.FeaturesAndProperties, which creates a compile-time dependency between jersey-client and jersey-core. Looks like a design flaw to me. jersey-core is an implementation of JAX-RS, which should be completely decoupled from specification (JAX-RS itself). When I'm using jersey-client in my project I'm expecting to have JAX-RS interface in "provided" scope and jersey-core in "runtime" scope.

It's impossible to so because of the dependency between mentioned classes.

<dependency>
  <groupId>javax.ws.rs</groupId>
  <artifactId>jsr311-api</artifactId>
  <version>1.1.1</version>
  <scope>provided</scope>
</dependency>
<dependency>
  <groupId>com.sun.jersey</groupId>
  <artifactId>jersey-client</artifactId>
  <version>${jersey.version}</version>
  <scope>compile</scope>
</dependency>
<dependency>
  <groupId>com.sun.jersey</groupId>
  <artifactId>jersey-core</artifactId>
  <version>${jersey.version}</version>
  <scope>runtime</scope>
</dependency>


 Comments   
Comment by Pavel Bucek [ 17/Dec/12 ]

not a bug - this is meant to be this way. Clients can run on non EE container / plain JDK and then you need to have JAX-RS API jar on classpath.

Solution might be to override this dependency thru standard maven facilities if declaring JAX-RS dependency as provided dependency does not work for you for some reason.

Comment by Yegor Bugayenko [ 17/Dec/12 ]

When it's necessary to have JAX-RS API jar in classpath we can change scope of that artifact to "compile". But in current situation it's not possible to manipulate these dependencies as it's expected in Maven. In other words, jersey-client depends on JAX-RS implementation, not on specification, which is an abuse of the "API/Implementation concept". Would be great if you re-consider this issue some time. It's not critical, but still...

Comment by Pavel Bucek [ 17/Dec/12 ]

well, it will be necessary for Jersey 2.0, because client api is now part of JAX-RS spec.

I think I can see your point, but there are ways (in maven) how to achieve what you need (overriding dependencies). Actually I don't think it is possible to do requested change if we still want to support these usecases:

1) running on plain JDK
2) running on container (where you can have client already included, like in glassfish/modules dir, so you have jersey-client itself marked as "provided").
3) running on container which does not include JAX-RS API/impl in any way (like tomcat if I'm not mistaken)





[JERSEY-1618] archetype fails out of the box; always uses "com.example" as package Created: 13/Dec/12  Updated: 18/Dec/12  Resolved: 18/Dec/12

Status: Resolved
Project: jersey
Component/s: None
Affects Version/s: 1.16
Fix Version/s: 1.17

Type: Bug Priority: Major
Reporter: the_alchemist Assignee: Pavel Bucek
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Java 1.7u9



 Description   

What

If you create a grizzly2 archetype, you'll actually get an error unless you happen to use com.example as your package:

Exception in thread "main" com.sun.jersey.api.container.ContainerException: The ResourceConfig instance does not contain any root resource classes.
	at com.sun.jersey.server.impl.application.RootResourceUriRules.<init>(RootResourceUriRules.java:99)
	at com.sun.jersey.server.impl.application.WebApplicationImpl._initiate(WebApplicationImpl.java:1331)
	at com.sun.jersey.server.impl.application.WebApplicationImpl.access$700(WebApplicationImpl.java:168)
	at com.sun.jersey.server.impl.application.WebApplicationImpl$13.f(WebApplicationImpl.java:774)
	at com.sun.jersey.server.impl.application.WebApplicationImpl$13.f(WebApplicationImpl.java:770)
	at com.sun.jersey.spi.inject.Errors.processWithErrors(Errors.java:193)

Why

The generate Main.java has:

protected static HttpServer startServer() throws IOException {
        ResourceConfig resourceConfig = new PackagesResourceConfig("com.example");

Notice that com.example is hardcoded. I'm guessing the template doesn't use the user-specified package.

Other

This is actually using 1.16, which is available on Maven Central but there's no entry for it in JIRA.



 Comments   
Comment by the_alchemist [ 13/Dec/12 ]

I forgot to mention which archetype:

  • GroupId: com.sun.jersey.archetypes
  • ArtifactId: jersey-quickstart-grizzly2
Comment by Pavel Bucek [ 18/Dec/12 ]

fixed in the trunk;

thanks!





[JERSEY-1605] Natural notation does not unmarshall attributes with bean properties Created: 30/Nov/12  Updated: 08/Aug/13  Resolved: 04/Feb/13

Status: Resolved
Project: jersey
Component/s: None
Affects Version/s: 1.15
Fix Version/s: 1.17

Type: Bug Priority: Major
Reporter: brian.chapman Assignee: Jakub Podlesak
Resolution: Cannot Reproduce Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

If a property that follows the JavaBean property standard is annotated with XmlAttribute (either on the field, getter or setter), Jersey will not unmarshal it. If the field does not follow the JavaBean standard, Jersey will unmarshall it.

The above is true when using the natural notation. The mapped and baderfish notations work correctly.

@XmlRootElement
@XmlAccessorType(XmlAccessType.NONE)
public class JsonExample {

//Does not Unmarshal
@XmlAttribute
private String exampleAttribute;

//Does Unmarshal
@XmlAttribute
public String thisWillUnMarshalCorrectly;

public String getExampleAttribute()

{ return exampleAttribute; }

public void setExampleAttribute(String attr)

{ exampleAttribute = attr; }

}

@Test
public void testJaxbToJson() throws JAXBException

{ JsonExample example = new JsonExample(); example.setExampleAttribute("myAttr1"); example.thisWillUnMarshalCorrectly = "myAttr2"; JSONJAXBContext jc = new JSONJAXBContext(JSONConfiguration.natural() .build(), JsonExample.class); JSONMarshaller jsonMarshaller = jc.createJSONMarshaller(); StringWriter out = new StringWriter(); jsonMarshaller.marshallToJSON(example, out); String json = out.toString(); System.out.println("json: " + json); JSONUnmarshaller unmarshaller = jc.createJSONUnmarshaller(); JsonExample result = unmarshaller.unmarshalFromJSON(new StringReader( json), JsonExample.class); assertNotNull(result); assertEquals(example.thisWillUnMarshalCorrectly, result.thisWillUnMarshalCorrectly); assertEquals(example.getExampleAttribute(), result.getExampleAttribute()); }

 Comments   
Comment by brian.chapman [ 30/Nov/12 ]

Sorry about the formatting above, I've attached the same code formatted below (I wasn't allowed to edit the issue).

        @XmlRootElement
        @XmlAccessorType(XmlAccessType.NONE)
        public class JsonExample {

		// Does not Unmarshal
		@XmlAttribute
		private String exampleAttribute;

		// Does Unmarshal
		@XmlAttribute
		public String thisWillUnMarshalCorrectly;

		public String getExampleAttribute() {
			return exampleAttribute;
		}

		public void setExampleAttribute(String attr) {
			exampleAttribute = attr;
		}
	}
    @Test
     public void testJaxbToJson() throws JAXBException {
        JsonExample example = new JsonExample();
        example.setExampleAttribute("myAttr1");
        example.thisWillUnMarshalCorrectly = "myAttr2";

        JSONJAXBContext jc = new JSONJAXBContext(JSONConfiguration.natural()
            .build(), JsonExample.class);

        JSONMarshaller jsonMarshaller = jc.createJSONMarshaller();
        StringWriter out = new StringWriter();
        jsonMarshaller.marshallToJSON(example, out);

        String json = out.toString();
        System.out.println("json: " + json);

        JSONUnmarshaller unmarshaller = jc.createJSONUnmarshaller();
        JsonExample result = unmarshaller.unmarshalFromJSON(new StringReader(
             json), JsonExample.class);

        assertNotNull(result);
        assertEquals(example.thisWillUnMarshalCorrectly,
            result.thisWillUnMarshalCorrectly);
        assertEquals(example.getExampleAttribute(),
            result.getExampleAttribute());
     }
Comment by Jakub Podlesak [ 04/Feb/13 ]

Should already be fixed, as the issue can not be reproduced in the main trunk.





[JERSEY-1451] jersey-core should not Export-Package javax.ws.rs.* in OSGi manifest, conflicts with other jsr311 bundle Created: 08/Oct/12  Updated: 08/Aug/13  Resolved: 12/Oct/12

Status: Resolved
Project: jersey
Component/s: core
Affects Version/s: 1.14
Fix Version/s: 1.17

Type: Bug Priority: Major
Reporter: ahmadfarsiado Assignee: Jakub Podlesak
Resolution: Won't Fix Votes: 2
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Karaf
Karaf version 2.2.9
Karaf home /home/rio/git/bippo-commerce5/karaf
Karaf base /home/rio/git/bippo-commerce5/karaf
OSGi Framework org.apache.felix.framework - 3.2.2

JVM
Java Virtual Machine OpenJDK 64-Bit Server VM version 22.0-b10
Version 1.7.0_03
Vendor Oracle Corporation
Uptime 8 minutes
Total compile time 23.360 seconds
Threads
Live threads 75
Daemon threads 61
Peak 106
Total started 117
Memory
Current heap size 71,386 kbytes
Maximum heap size 466,048 kbytes
Committed heap size 136,064 kbytes
Pending objects 0
Garbage collector Name = 'PS Scavenge', Collections = 99, Time = 0.560 seconds
Garbage collector Name = 'PS MarkSweep', Collections = 1, Time = 0.050 seconds
Classes
Current classes loaded 9,226
Total classes loaded 9,227
Total classes unloaded 1
Operating system
Name Linux version 3.2.0-27-generic
Architecture amd64
Processors 4


Issue Links:
Related
is related to JAX_RS_SPEC-110 Allow multiple JAX-RS implementations... Open

 Description   

I have a project which uses:

1. jersey-core & jersey-client 1.14
2. mvn:org.apache.servicemix.specs/org.apache.servicemix.specs.jsr311-api-1.1.1/2.0.0, which is installed by cxf
3. cxf-jaxrs which uses javax.ws.rs
4. neo4j-rest-graphdb 1.7 which uses jersey-client

Problem arises when neo4j imports javax.ws.rs from jsr311-api bundle, but also uses jersey-client and jersey-core. Since jersey-core ships with its own javax.ws.rs and exports it, it requires all depending bundles to use jersey's version of javax.ws.rs. Hence the conflict.

However, I can not uninstall jersey-core because it is required by jersey-client.

The proper way is to separate javax.ws.rs packages and jersey-core packages into separate bundles.
jersey-core can then import javax.ws.rs package, which may be provided by jersey project, or by other jsr311-api like provided by servicemix.specs, as long as the version is compatible (e.g. Import-Package: javax.ws.rs; version=1.1.1 )

So Jersey client can coexist with other JAX-RS providers.

Thank you.



 Comments   
Comment by ceefour [ 08/Oct/12 ]

Highly +1 for this improvement!

Comment by Martin Matula [ 10/Oct/12 ]

This won't solve the issue, since javax.ws.rs has RuntimeDelegate class that stores the pointer to the JAX-RS implementation in a static variable. So, once the runtime is initialized, the API will still point to one particular impl.

Comment by ceefour [ 10/Oct/12 ]

I think it still helps, to some extent.

The conflict that I mentioned is a OSGi resolution conflict, which happens before even the bundle is started properly. So with the jsr311-api packages separated from jersey-core, Jersey should be usable properly.

Also in my case, I'm using CXF as server, and Jersey as client.

I wonder if JAX-RS EG is aware of this issue for 2.0, "javax.ws.rs has RuntimeDelegate class that stores the pointer to the JAX-RS implementation in a static variable" sounds like a design flaw in the JAX-RS Spec to me, especially considering dynamic runtimes like OSGi and perhaps upcoming Jigsaw.

Comment by Martin Matula [ 10/Oct/12 ]

Assigning to Jakub for more thorough evaluation.

Comment by Jakub Podlesak [ 12/Oct/12 ]

JAX-RS EG should be aware of this, see [1].

Regarding jersey-core OSGi headers, we have the JAX-RS packages listed there as we are actually bundling the JAX-RS packages altogether with our Jersey core packages
in that jersey-core module. That way one should be able to run two separate Jersey versions within one JVM. When you ask to remove the javax.* export headers from our manifest, you also
ask to get the JAX-RS classes removed from jersey-core module. I am reluctant to do so, as that would break the above mentioned use case.

I think this issue should be solved at the JAX-RS level and so going to close this one as invalid. Please feel free to reopen.

[1]http://java.net/jira/browse/JAX_RS_SPEC-110

Comment by Jakub Podlesak [ 12/Oct/12 ]

won't fix suits better here than invalid, as i agree that proposed fix should work fine for the given use case.
I suggest you just go and re-package the Jersey's jersey-core module and either just tweak the export header
or tweak the export/import headers and remove jax-rs content from the jar.

Comment by ceefour [ 12/Oct/12 ]

Jakub,

I'm not sure why removing javax.ws.rs from jersey-core makes unable to run two versions of Jersey.

It should be possible with installed bundles like this: (and the dependency graph)

1. jsr311-api v1.1
2. jersey-core v1.14 -> jsr311-api v1.1
3. jersey-client v1.14 -> jersey-core v1.14
4. jsr311-api v2.0
5. jersey-core v2.0 -> jsr311-api v2.0
6. jersey-client v2.0 -> jersey-core v2.0

Comment by Jakub Podlesak [ 12/Oct/12 ]

For that one, sure, but what about:

Jersey 1.13 and 1.14 ?

Comment by ceefour [ 12/Oct/12 ]

Should be like this:

1. jsr311-api v1.1
2. jersey-core v1.13 -> jsr311-api v1.1
3. jersey-client v1.13 -> jersey-core v1.13
4. jersey-core v1.14 -> jsr311-api v1.1
5. jersey-client v1.14 -> jersey-core v1.14
6. jsr311-api v2.0
7. jersey-core v2.0 -> jsr311-api v2.0
8. jersey-client v2.0 -> jersey-core v2.0

This will at least resolve properly in OSGi.

However, regarding #JAX_RS_SPEC-110, I hope this actually gets resolved in 2.0.

For 1.1, I would suggest having jersey-core and jersey-core-osgi (new) packages, where jersey-core is basically a merger between jsr311-api and jersey-core-osgi. This is similar to what Groovy does with groovy and groovy-all package.

Is this good enough?

Comment by Jakub Podlesak [ 13/Oct/12 ]

O.K., so both 2 (jersey-core v 1.13) and 4 (jersey-core v 1.14) depends on 1 (jsr311-api v1.1)
Now the first one from 2, 4, which sets the RuntimeDelegate instance in 1 wins, and its RD instance
gets used even for calls coming from the other implementation.
That's exactly what JAX_RS_SPEC-110 should help resolve.

Comment by Jakub Podlesak [ 13/Oct/12 ]

"is related" better represents the relation here as even
if the linked issue gets resolved in JAX-RS 2.0, it would not help to resolve this 1.x specific issue





[JERSEY-1423] StringIndexOutOfBoundsException when evaluating path with values without a trailing slash Created: 12/Sep/12  Updated: 29/Jan/13  Resolved: 29/Jan/13

Status: Resolved
Project: jersey
Component/s: core
Affects Version/s: 1.14
Fix Version/s: 1.17

Type: Bug Priority: Major
Reporter: eelco12 Assignee: Miroslav Fuksa
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: 0 minutes
Time Spent: 4 hours
Original Estimate: Not Specified


 Description   

The following (3rd test) fails, but succeeded in previous version (1.12)

Assert.assertEquals("http://localhost:8080", UriBuilder.fromUri("http://localhost:8080").build().toString()); // succeeds
Assert.assertEquals("http://localhost:8080/", UriBuilder.fromUri("http://localhost:8080/").build("nothingreally").toString()); // succeeds
Assert.assertEquals("http://localhost:8080", UriBuilder.fromUri("http://localhost:8080").build("nothingreally").toString()); // fails

Line 766:

if (sb.length() > 0 && path.charAt(0) != '/') {

should probably be:

if (path.length() > 0 && path.charAt(0) != '/') {

(assuming path will never be null?)






[JERSEY-1366] Jersey Test Framework shall start and stop container only once for all tests Created: 13/Aug/12  Updated: 08/Aug/13  Resolved: 13/Aug/12

Status: Resolved
Project: jersey
Component/s: test-framework
Affects Version/s: 1.13
Fix Version/s: 1.17

Type: Improvement Priority: Minor
Reporter: mkarg Assignee: Unassigned
Resolution: Duplicate Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Duplicate
duplicates JERSEY-705 Ability to share a single web server ... Resolved

 Description   

The test framework currently starts and stops a container for each single test method of a unit test. This results in rather long execution time and console cluttering. It would be great if instead the container would start before the first test method, and stop after the last test method.






[JERSEY-1337] Boolean Matrix Parameters are interpreted differently from the WADL specification Created: 02/Aug/12  Updated: 08/Aug/13  Resolved: 23/Aug/12

Status: Resolved
Project: jersey
Component/s: None
Affects Version/s: 1.13
Fix Version/s: 1.17

Type: Bug Priority: Major
Reporter: gdavison Assignee: Pavel Bucek
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

As per section http://www.w3.org/Submission/wadl/#x3-130002.6.1 of the WADL specification a boolean matrix parameter is represented either by the presence of absence of the property rather than the =X notation.

Interestingly the original MatrixURI proposal doesn't have anything to say on the matter:

http://www.w3.org/DesignIssues/MatrixURIs.html

This could be a problem with the WADL specification; but if you invoke the following Jersey service:

package project1;

import javax.ws.rs.GET;
import javax.ws.rs.MatrixParam;
import javax.ws.rs.Path;

@Path("/matrix")
public class MatrixExample {

private String con;

public MatrixExample() {
}

@GET
public String matrixExample(@MatrixParam("param") String param, @MatrixParam("boolean") boolean flag)

{ return param + " " + con + " " + flag; }

@MatrixParam("con")
public void setCon(String con)

{ this.con = con; }

public String getCon()

{ return con; }

}

With the URI http://..../matrix;boolean;param=X;con=X then the result is "X X false" rather than the "X X true" as would be expected by the WADL specification.

I checked and the JSR311 spec doesn't say anything specific on the interpretation of this value.



 Comments   
Comment by gdavison [ 02/Aug/12 ]

Not that UriBuilder is consistent so that

UriBuilder.fromUri("http://...").matrixParam("boolean", true).build()

Returns "http://...;boolean=true" and not "http://...;boolean"

Comment by Pavel Bucek [ 23/Aug/12 ]

looks like WADL spec issue as you pointed out. I don't think there is anything we should change in Jersey. Closing as won't fix for now, feel free to add comment/reopen.





[JERSEY-1317] Tomcat 7 slow startup time with Jersey (1.13) deployed Created: 27/Jul/12  Updated: 08/Aug/13  Resolved: 03/Aug/12

Status: Resolved
Project: jersey
Component/s: containers
Affects Version/s: 1.13
Fix Version/s: 1.17

Type: Bug Priority: Major
Reporter: gamliela Assignee: Michal Gajdos
Resolution: Invalid Votes: 0
Labels: None
Remaining Estimate: 0 minutes
Time Spent: 5 hours
Original Estimate: Not Specified
Environment:

Windows 7, jdk1.6.0_30, apache-tomcat-7.0.29, jersey-archive-1.13, eclipselink-2.3.1


Tags: eclipselink, selenium, tomcat

 Description   

Time for launch Tomcat without Jersey is 1 second.
When I add the jars of Jersey to tomcat/lib directory, the time for launch goes for 30 seconds.
It doesn't matter which application I deploy - even if no application is deployed (no servlets) it takes that time. However the server already contains jars of Selenium and EclipseLink.

The jar that cause the problem is jersey-servlet-1.13. When I remove it from lib directory, launch time goes normal again. I suspect that the services defined in that jar (\META-INF\services*) cause the trouble but couldn't find the exact cause...

I'm not sure if it's a bug but it's definitively a problem.
My motivation for choosing Tomcat was performance, and if Jersey hurts that performance it's a problem.

Steps to reproduce:
1. download and extract apache-tomcat-7.0.29
2. copy to tomcat/lib directory the following jars from eclipselink-2.3.1 (JPA):
a) eclipselink.jar
b) javax.persistence_2.0.3.v201010191057.jar
3. copy to tomcat/lib directory the following jars from selenium-2.24.1:
a) selenium-java-2.24.1.jar
b) all jars from lib directory (36 jars)
4. run tomcat/bin/startup.bat and make sure (using logs) the startup time is few seconds at most.
On my machine it takes less than 1 second.
5. run shutdown.bat
6. copy to tomcat/lib directory the following jars from jersey-archive-1.12.zip:
a) asm-3.1.jar
b) jersey-core-1.12.jar
c) jersey-server-1.12.jar
d) jersey-servlet-1.12.jar
(As far as I know this is the minimum required to use Jersey)
7. run startup.bat again.
On my machine it takes now more than 30 seconds.



 Comments   
Comment by gamliela [ 27/Jul/12 ]

The same problem occurs on both versions of Jersey - 1.12 & 1.13.
Also please fix the download link for 1.13 (it still points to 1.12).

Comment by Marek Potociar [ 02/Aug/12 ]

Michal, can you please evaluate?

Comment by Michal Gajdos [ 03/Aug/12 ]

This is not a Jersey bug although the jersey-servlet.jar makes Tomcat to perform some additional classpath scanning. The jersey-servlet.jar adds a capability for Servlet3 initialization which Tomcat7 supports. Since you put Jersey jars into tomcat/lib directory then the Jersey implementation of ServletContainerInitializer is invoked for every webapp (present in tomcat\webapps) during it's deployment. Before the invocation of the JerseyServletContainerInitializer the Tomcat does classpath scanning to provide requested classes to this initializer (which slows down the startup).

There are two ways to solve this issue:

  • if you do not need/use Servlet3 capabilities, you can remove the META-INF/services/javax.servlet.ServletContainerInitializer file from jersey-servlet.jar so that the JerseyServletContainerInitializer is not recognized by Tomcat and hence no classpath scanning is performed for this initializer.
  • if you want to use Servlet3 then pack the Jersey jars with the webapp to ensure the JerseyServletContainerInitializer is invoked only for this webapp (Tomcat will do the classpath scanning only for webapps containing the jersey-servlet.jar)

Edit: Thanks for noticing the incorrect download link.





[JERSEY-1277] The web container Grizzly doesn't call anymore the ServletContextListener instances at shutdown Created: 05/Jul/12  Updated: 08/Aug/13  Resolved: 10/Sep/12

Status: Resolved
Project: jersey
Component/s: containers, test-framework
Affects Version/s: 1.13
Fix Version/s: 1.17

Type: Bug Priority: Major
Reporter: mimo Assignee: Jakub Podlesak
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

GNU/Linux, Windows, JEE, Spring 3.1, Jersey 1.13, Jersey-Spring 1.13, Jersey-Test 1.13, Grizzly Web container, Maven 3.0.4


Attachments: GZip Archive jersey-test.tar.gz     XML File pom.xml    
Issue Links:
Dependency
depends on GRIZZLY-1308 ServletContextListener.destroy is not... Resolved
depends on JERSEY-1384 Upgrade Jersey 1.x Grizzly 2 dependen... Resolved

 Description   

We have some beans managed by Spring 3.1 and having a method annotated with @PreDestroy. Theses beans are used by some of our REST WEB resources.
We use in our tests the default test container factory (thus the Grizzly 2 web container factory) and Spring is set up by passing to JerseyTest a well defined WebAppDescriptor instance.

In our tests, with Jersey 1.11.1, the @PreDestroy annotated methods were correctly called at container stopping and all worked fine.
But, with Jersey 1.13, we have regressions as these methods are not anymore invoked at container stopping. After debugging, it seams the Spring ContextLoaderListener isn't more called by the WEB container Grizzly when stopping.



 Comments   
Comment by Jakub Podlesak [ 19/Jul/12 ]

Could you please provide a simple reproducible test case?

Comment by mimo [ 24/Jul/12 ]

I've created a Maven project to illustrate the problem.
The issue is shown by the test:

  • a ResourcesAllocator object is instantiated by Spring at test runtime bootstrap and this object allocates some resources within a @PostConstruct annotated method (in the example a static boolean 'allocated' is set at true) and deallocates them within a @PreDestroy annotated method (in the example the boolean is set at false).
    In each of the above methods a message is printed out.
    If an attempt is done to allocate some already allocated resources, a RuntimeException is thrown.
  • two tests are ran in the MyWebResourceTest class that extends a WebResourceTest class that is in charge to bootstrap a web context with jersey and spring.
  • during the execution of the second test, the RuntimeException is thrown because the previous spring context weren't unloaded (the spring context listener wasn't called by the web container grizzly 2). And to confirm that, the message of the @PreDestroy annotated method of the ResourcesAllocator is never printed out as it was never called.

By changing the Jersey version from 1.13 to 1.11.1, all works fine.

Comment by Jakub Podlesak [ 02/Aug/12 ]

The @PreDestroy method was originally invoked by Grizzly:

	at org.silverpeas.jersey.ResourcesAllocator.deallocate(ResourcesAllocator.java:47)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:597)
	at org.springframework.beans.factory.annotation.InitDestroyAnnotationBeanPostProcessor$LifecycleElement.invoke(InitDestroyAnnotationBeanPostProcessor.java:346)
	at org.springframework.beans.factory.annotation.InitDestroyAnnotationBeanPostProcessor$LifecycleMetadata.invokeDestroyMethods(InitDestroyAnnotationBeanPostProcessor.java:311)
	at org.springframework.beans.factory.annotation.InitDestroyAnnotationBeanPostProcessor.postProcessBeforeDestruction(InitDestroyAnnotationBeanPostProcessor.java:150)
	at org.springframework.beans.factory.support.DisposableBeanAdapter.destroy(DisposableBeanAdapter.java:193)
	at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.destroyBean(DefaultSingletonBeanRegistry.java:498)
	at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.destroySingleton(DefaultSingletonBeanRegistry.java:474)
	at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.destroySingletons(DefaultSingletonBeanRegistry.java:442)
	at org.springframework.context.support.AbstractApplicationContext.destroyBeans(AbstractApplicationContext.java:1066)
	at org.springframework.context.support.AbstractApplicationContext.doClose(AbstractApplicationContext.java:1040)
	at org.springframework.context.support.AbstractApplicationContext.close(AbstractApplicationContext.java:988)
	at org.springframework.web.context.ContextLoader.closeWebApplicationContext(ContextLoader.java:556)
	at org.springframework.web.context.ContextLoaderListener.contextDestroyed(ContextLoaderListener.java:142)
	at org.glassfish.grizzly.servlet.ServletContextImpl.destroyListeners(ServletContextImpl.java:186)
	at org.glassfish.grizzly.servlet.ServletHandler.destroy(ServletHandler.java:768)
	at org.glassfish.grizzly.http.server.HttpHandlerChain.destroy(HttpHandlerChain.java:317)
	at org.glassfish.grizzly.http.server.HttpServer.tearDownHttpHandler(HttpServer.java:303)
	at org.glassfish.grizzly.http.server.HttpServer.stop(HttpServer.java:366)
	at com.sun.jersey.test.framework.spi.container.grizzly2.web.GrizzlyWebTestContainerFactory$GrizzlyWebTestContainer.stop(GrizzlyWebTestContainerFactory.java:154)

I have asked Oleksiy from Grizzly team to take a look at this.

Oleksiy: Grizzly version 2.1.2 invokes the contextDestroyed method all right.

Comment by oleksiys [ 03/Aug/12 ]

correspondent Grizzly issue
http://java.net/jira/browse/GRIZZLY-1308

we've fixed it, the fix will be available in Grizzly 2.2.14

Comment by oleksiys [ 17/Aug/12 ]

FYI:
Grizzly 2.2.14 has been released.

Comment by Jakub Podlesak [ 21/Aug/12 ]

Adjusted test case pom.xml, which pulls in fixed grizzly version to make the test case work.

Comment by mimo [ 27/Aug/12 ]

Ok, by specifying explicitly the version 2.2.14 and by excluding the dependency on Grizzly in jersey, the @PreDestroy annotated methods are now called within the tests.

Comment by mimo [ 27/Aug/12 ]

Sorry, I misspelled the version of Grizzly. Please read instead: by explicitly set the Grizzly version at 2.2.16 and by excluding the actual version of Grizzly used in the Jersey Test Framework.

Comment by Jakub Podlesak [ 27/Aug/12 ]

Thanks for verifying.





[JERSEY-1232] EAR with two CDI web archives will not deploy Created: 21/Jun/12  Updated: 08/Aug/13  Resolved: 10/Jul/12

Status: Resolved
Project: jersey
Component/s: containers, core
Affects Version/s: 1.11, 1.12
Fix Version/s: 1.17

Type: Bug Priority: Blocker
Reporter: Ramon Rockx Assignee: Michal Gajdos
Resolution: Invalid Votes: 1
Labels: None
Remaining Estimate: 0 minutes
Time Spent: 4 hours
Original Estimate: Not Specified
Environment:

GlassFish 3.1.2, Windows 7


Attachments: File TestEAR-0.0.1-SNAPSHOT.ear     Java Archive File TestWAR1-0.0.1-SNAPSHOT-sources.jar     Java Archive File TestWAR2-0.0.1-SNAPSHOT-sources.jar    
Tags: cdi

 Description   

We are experiencing the following issue with Jersey 1.12 in combination with Glassfish 3.1.2:
When using an EAR with two WAR's in it, the last WAR doesn't get deployed. Both WAR's are CDI enabled and contains a REST service. When deploying both WAR's without the EAR, they deploy just fine.
I will attach a test case.

This issue seems to be closely related to:

http://java.net/jira/browse/JERSEY-582
http://java.net/jira/browse/JERSEY-1115

Depending on the VM property
com.sun.jersey.server.impl.cdi.lookupExtensionInBeanManager we will get another Exception:

com.sun.jersey.server.impl.cdi.lookupExtensionInBeanManager=false:

java.lang.RuntimeException: javax.naming.NamingException: Lookup failed for 'com/sun/jersey/config/CDIExtension' in SerialContext[myEnv=java.naming.factory.initial=com.sun.enterprise.naming.impl.SerialInitContextFactory, java.naming.factory.state=com.sun.corba.ee.impl.presentation.rmi.JNDIStateFactoryImpl, java.naming.factory.url.pkgs=com.sun.enterprise.naming}
[Root exception is javax.naming.NameNotFoundException: CDIExtension not found]	
	at com.sun.jersey.server.impl.cdi.CDIExtension.getInitializedExtension(CDIExtension.java:177)
	at com.sun.jersey.server.impl.cdi.CDIComponentProviderFactory.<init>(CDIComponentProviderFactory.java:92)
	at com.sun.jersey.server.impl.cdi.CDIComponentProviderFactoryInitializer.initialize(CDIComponentProviderFactoryInitializer.java:75)
	at com.sun.jersey.spi.container.servlet.WebComponent.configure(WebComponent.java:574)
	at com.sun.jersey.spi.container.servlet.ServletContainer$InternalWebComponent.configure(ServletContainer.java:311)
	at com.sun.jersey.spi.container.servlet.WebComponent.load(WebComponent.java:606)
	at com.sun.jersey.spi.container.servlet.WebComponent.init(WebComponent.java:208)
	at com.sun.jersey.spi.container.servlet.ServletContainer.init(ServletContainer.java:373)
	at com.sun.jersey.spi.container.servlet.ServletContainer.init(ServletContainer.java:556)
	at javax.servlet.GenericServlet.init(GenericServlet.java:244)
	...

com.sun.jersey.server.impl.cdi.lookupExtensionInBeanManager=true

java.lang.NullPointerException
	at com.sun.jersey.server.impl.cdi.CDIComponentProviderFactory.<init>(CDIComponentProviderFactory.java:94)
	at com.sun.jersey.server.impl.cdi.CDIComponentProviderFactoryInitializer.initialize(CDIComponentProviderFactoryInitializer.java:75)
	at com.sun.jersey.spi.container.servlet.WebComponent.configure(WebComponent.java:574)
	at com.sun.jersey.spi.container.servlet.ServletContainer$InternalWebComponent.configure(ServletContainer.java:311)
	at com.sun.jersey.spi.container.servlet.WebComponent.load(WebComponent.java:606)
	at com.sun.jersey.spi.container.servlet.WebComponent.init(WebComponent.java:208)
	at com.sun.jersey.spi.container.servlet.ServletContainer.init(ServletContainer.java:373)
	at com.sun.jersey.spi.container.servlet.ServletContainer.init(ServletContainer.java:556)
	at javax.servlet.GenericServlet.init(GenericServlet.java:244)
	...


 Comments   
Comment by Michal Gajdos [ 10/Jul/12 ]

This issue seems to be related to WELD in GF and not Jersey - see https://community.jboss.org/thread/163085 and https://issues.jboss.org/browse/JBAS-9476

Comment by Ramon Rockx [ 26/Jul/12 ]

filed http://issues.jboss.org/browse/WELD-1175
filed http://java.net/jira/browse/GLASSFISH-18946





[JERSEY-1186] Client LoggingFilter Causes my application to hang Created: 29/May/12  Updated: 08/Aug/13  Resolved: 02/Aug/12

Status: Resolved
Project: jersey
Component/s: None
Affects Version/s: 1.11
Fix Version/s: 1.17

Type: Bug Priority: Major
Reporter: tad.e.smith Assignee: Pavel Bucek
Resolution: Cannot Reproduce Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

If I use the client LoggingFilter in conjunction with the GZIPContentEncodingFilter, my application hangs. Based upon the stacktrace, it looks like it's hanging getting a connection. Here is a sample stacktrace of my thread:
Thread [Thread-6] (Suspended)
Object.wait(long) line: not available [native method]
MultiThreadedHttpConnectionManager.doGetConnection(HostConfiguration, long) line: 518
MultiThreadedHttpConnectionManager.getConnectionWithTimeout(HostConfiguration, long) line: 416
HttpMethodDirector.executeMethod(HttpMethod) line: 153
HttpClient.executeMethod(HostConfiguration, HttpMethod, HttpState) line: 397
DefaultApacheHttpMethodExecutor.executeMethod(HttpMethod, ClientRequest) line: 210
ApacheHttpClientHandler.handle(ClientRequest) line: 175
GZIPContentEncodingFilter.handle(ClientRequest) line: 120
LoggingFilter.handle(ClientRequest) line: 183
ApacheHttpClient(Client).handle(ClientRequest) line: 648
WebResource.handle(Class<T>, ClientRequest) line: 670
WebResource.access$200(WebResource, Class, ClientRequest) line: 74
WebResource$Builder.method(String, Class<T>) line: 613
RequestBuilder.handle(Class<T>, String) line: 540
RequestBuilder.getNoThrow(Class<T>) line: 395
LoginManagerImpl.getServiceLocations() line: 74
NativeMethodAccessorImpl.invoke0(Method, Object, Object[]) line: not available [native method]
NativeMethodAccessorImpl.invoke(Object, Object[]) line: 39
DelegatingMethodAccessorImpl.invoke(Object, Object[]) line: 25
Method.invoke(Object, Object...) line: 597
ReflectiveMethodInvocation.invokeJoinpoint() line: 146
ReflectiveMethodInvocation.proceed() line: 128
TraceLoggingMethodInterceptor.invoke(MethodInvocation) line: 49
ReflectiveMethodInvocation.proceed() line: 132
JAMonMethodInterceptor.invoke(MethodInvocation) line: 100
ReflectiveMethodInvocation.proceed() line: 132
SwingEventThreadCheckInterceptor.invoke(MethodInvocation) line: 90
ReflectiveMethodInvocation.proceed() line: 132
AOPInvocationHandler.invoke(Object, Method, Object[]) line: 60
$Proxy8.getServiceLocations() line: not available
ETMSSession.<init>(ETMSSessionFactory, ETMSSessionKey, LoginManager, LoginInfo) line: 149
ETMSSessionGenerator.createETMSSession(ETMSSessionFactory, ETMSSessionKey, LoginManager, LoginInfo) line: 30
ETMSSessionFactory.registerToken(BasicLoginManager, ETMSSessionKey, LoginInfo, boolean, boolean, String, String) line: 511
ETMSSessionFactory.registerToken(BasicLoginManager, ETMSSessionKey, LoginInfo, boolean, boolean, String, String) line: 1
ETMSSessionFactory(AbstractETMSSessionFactory).loginViaVzId(String, String) line: 428
ETMSSessionFactory.loginViaVzId(String, String) line: 337
ETMSClientSession.loginViaVzId(BasicLoginDialog, String, String) line: 268
ETMSDesktop$Login.construct() line: 6221
SwingWorker$2.run() line: 129
Thread.run() line: 662

I've modified the logResponse() method in the LoggingFilter class. Here is my method:

    private void logResponse(long id, ClientResponse response) {
        StringBuilder b = new StringBuilder();

        printResponseLine(b, id, response);
        printResponseHeaders(b, id, response.getHeaders());

        if(response.hasEntity()) {
            ByteArrayOutputStream out = new ByteArrayOutputStream();
            InputStream in = response.getEntityInputStream();
            try {
                ReaderWriter.writeTo(in, out);
                in.close();
    
                byte[] requestEntity = out.toByteArray();
                printEntity(b, requestEntity);
                response.setEntityInputStream(new ByteArrayInputStream(requestEntity));
            } catch (IOException ex) {
                throw new ClientHandlerException(ex);
            }
        }
        
        log(b);
    }


 Comments   
Comment by Pavel Bucek [ 09/Jul/12 ]

seems legit, will run some tests and get back to you.

Comment by Pavel Bucek [ 09/Jul/12 ]

on the other hand..

I'm not able to reproduce. Have tried adding LogginFilter to our GZIPContentEncodingTest and looks like everything works well. Can you create some testcase which would demonstrate described behavior and share it? (or you can send it directly to me).

Comment by Pavel Bucek [ 02/Aug/12 ]

feel free to reopen with more info/testcase





[JERSEY-1183] Generated WADL missing @FormDataParam parameters Created: 25/May/12  Updated: 08/Aug/13  Resolved: 25/May/12

Status: Resolved
Project: jersey
Component/s: core
Affects Version/s: 1.12
Fix Version/s: 1.17

Type: Bug Priority: Minor
Reporter: Márcio Carmona Assignee: Unassigned
Resolution: Duplicate Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

The application.wadl generated file doesn't contain any of the @FormDataParam annotated parameters. It is not working even in 1.9 release, nor in newer releases like 1.12. Am I doing something wrong?

This is my method declaration:

@POST
@Path("/upload")
@Consumes(MediaType.MULTIPART_FORM_DATA)
@Produces(MediaType.TEXT_PLAIN)
public String uploadFile(
@QueryParam("test") String test,
@FormDataParam("file") InputStream file,
@FormDataParam("number") Long number,
@FormDataParam("text") String string)

This is the generated WADL snippet:
<resource path="/upload">
<method id="uploadFile" name="POST">
<request>
<param xmlns:xs="http://www.w3.org/2001/XMLSchema" name="test" style="query" type="xs:string"/>
<representation mediaType="multipart/form-data"/>
</request>
<response>
<representation mediaType="text/plain"/>
</response>
</method>
</resource>

Notice that there isn't any of the @FormDataParam's in the request.

Thanks,
Márcio Carmona



 Comments   
Comment by Márcio Carmona [ 25/May/12 ]

This issue is a duplicate of JERSEY-745. I've also commented there.





[JERSEY-1175] When using apache-http-client connect timeouts are not honoured for proxy connects Created: 22/May/12  Updated: 08/Aug/13  Resolved: 25/May/12

Status: Resolved
Project: jersey
Component/s: connectors
Affects Version/s: 1.11, 1.12
Fix Version/s: 1.17

Type: New Feature Priority: Major
Reporter: stickycode Assignee: Pavel Bucek
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Squid proxy that ran out of file handles and could not response to CONNECT requests


Tags: connect, proxy, timeout

 Description   

We ran into a scenario when a proxy would accept a connect request and not respond.

It turns out that the commons-httpclient library will not use the timeout

httpClientConfig.getProperties().put(ClientConfig.PROPERTY_CONNECT_TIMEOUT, connectTimeoutInMillis);

for the ConnectMethod used when doing the proxy connect

I found that I needed to do this to encourage the http client to actually timeout on the proxy connect
ApacheHttpClient client = ApacheHttpClient.create(httpClientConfig);
client.getClientHandler().getHttpClient().getHttpConnectionManager().getParams().setSoTimeout(connectTimeoutInMillis);

Although this is actually a read timeout on the connect request rather than a true connect timeout.

To simulate a hanging proxy I used netcat like so... but anything that can open a socket and do nothing will work as well
nc -l -p 5865

Which would receive the following request and not respond...
CONNECT xml.trn.secure-travel.net:443 HTTP/1.1
User-Agent: Jakarta Commons-HttpClient/3.1
Host: xml.trn.secure-travel.net
Proxy-Connection: Keep-Alive



 Comments   
Comment by Pavel Bucek [ 25/May/12 ]

closing as won't fix.

If I understood it correctly, you already found a working way how to set property you need, right? Additionally, PROPERTY_CONNECT_TIMEOUT is not declared as supported (see http://jersey.java.net/nonav/apidocs/latest/contribs/jersey-apache-client4/index.html), so this is more like enhancement request than bug report..

Client API is going to be changed in JAX-RS 2.0 (it contains Client API now and it's quite different).

feel free to comment or convince me that this should be addressed in future 1.x release.





[JERSEY-1150] Jersey-Multipart: BodyPart and its subclasses don't implement equals or hashCode Created: 14/May/12  Updated: 08/Aug/13  Resolved: 24/May/12

Status: Resolved
Project: jersey
Component/s: None
Affects Version/s: 1.12
Fix Version/s: 1.17

Type: Bug Priority: Major
Reporter: ttmrb Assignee: Michal Gajdos
Resolution: Invalid Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: equals, hashcode, jersey, multipart

 Description   

I am using the jersey-multipart module and went to unit test some of my work. I need to pass in some MultiPart objects for test data and the tests failed because it was comparing references rather than the values of the data in the object. I examined the code for BodyPart and its subclasses and noticed that equals and hashCode were not implemented. Seeing as how these objects are data containers/value objects, they should definitely implement these methods.



 Comments   
Comment by Michal Gajdos [ 15/May/12 ]

Hi, do you have a simple test-case that you can share with us?

Comment by ttmrb [ 18/May/12 ]

I can't give my actual unit tests as it tests proprietary code but I have created the simplest example to demonstrate the issue.

public class JerseyMultipartTest {
    @Test
    public void testEquals() {
        InputStream is1 = this.getClass().getResourceAsStream("test-image.jpg");
        MultiPart mp1 = new MultiPart();
        StreamDataBodyPart bodyPart1 = new StreamDataBodyPart("image", is1);
        mp1.bodyPart(bodyPart1);

        MultiPart mp2 = new MultiPart();
        InputStream is2 = this.getClass().getResourceAsStream("test-image.jpg");
        StreamDataBodyPart bodyPart2 = new StreamDataBodyPart("image", is2);
        mp1.bodyPart(bodyPart2);
        
        Assert.assertEquals(mp1, mp2);
    }
}

This test fails with the following message:

java.lang.AssertionError: expected:<com.sun.jersey.multipart.MultiPart@7854a328> but was:<com.sun.jersey.multipart.MultiPart@7ca3d4cf>
	at org.junit.Assert.fail(Assert.java:93)
	at org.junit.Assert.failNotEquals(Assert.java:647)
	at org.junit.Assert.assertEquals(Assert.java:128)
	at org.junit.Assert.assertEquals(Assert.java:147)
	at com.mattbertolini.scratch.JerseyMultipartTest.testEquals(JerseyMultipartTest.java:24)
        ...

Based on the assertion error, its clear that the MultiPart objects are being checked using Object.equals() and checking memory reference.

Comment by Michal Gajdos [ 24/May/12 ]

Hi, unfortunately I don't think there is much we can do in this case. It seems to me that if the methods equals and hashCode were implemented correctly they would be too expensive in the runtime in this case. MultiPart object can be rather complex structure and even if the BodyPart's lists of two of these objects were ordered in the same order then there is a case where BodyPart object can contain an entity that does not override equals and hashCode. This would make the MultiPart instances incomparable. Even in the use case you've posted the objects is1 and is2 are different (when is1.equals(is2) is called) and comparing them would mean to read both streams and compare them byte per byte. Considering this I am resolving this issue as 'Invalid'.

Comment by ttmrb [ 25/May/12 ]

First, thank you for taking a look at the issue. It is much appreciated.

While I am disappointed that this will not be able to be fixed, the explanation given raises some good points. Since I was only encountering the issue in my unit tests, I have coded an appropriate workaround (hooray for testable code! )

At the very least, we now have a well documented explanation that other developers can now find and understand.

Thanks again.





[JERSEY-1141] providing PDT value in If-Modified-Since header changes timezone for Last-Modified response header Created: 11/May/12  Updated: 08/Aug/13  Resolved: 23/May/12

Status: Resolved
Project: jersey
Component/s: core
Affects Version/s: 1.9.1
Fix Version/s: 1.17

Type: Bug Priority: Major
Reporter: jameskojo Assignee: Pavel Bucek
Resolution: Invalid Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

mac, centos



 Description   

when I send a conditional get command to jersey using a PDT timezone, it seems to change the internal state of the date formatter for the 'Last-Modified' response header in unexpected ways.

On my mac, the request seems to change the timezone, but the time is at least converted to the right timezone offset.
curl -v --request GET --header "If-Modified-Since:Tue, 08 May 2012 19:13:53 PDT" <MY resource URL>

> User-Agent: curl/7.19.7 (universal-apple-darwin10.0) libcurl/7.19.7 OpenSSL/0.9.8r zlib/1.2.3
> Accept: /
>
< Server: Apache-Coyote/1.1
< Last-Modified: Thu, 10 May 2012 16:08:44 PDT
< Content-Type: application/octet-stream
< Transfer-Encoding: chunked
< Date: Fri, 11 May 2012 05:22:16 GMT
<

In our centos environment, the timezone of the Last-Modifed header is specified as GMT, but the time offset is actually in PDT.

> User-Agent: curl/7.19.7 (universal-apple-darwin10.0) libcurl/7.19.7 OpenSSL/0.9.8r zlib/1.2.3> Accept: /
> < HTTP/1.1 200 OK
< Date: Fri, 11 May 2012 05:37:45 GMT
< Server: Apache-Coyote/1.1
< Last-Modified: Thu, 10 May 2012 16:08:44 GMT
< Content-Type: application/octet-stream
< Transfer-Encoding: chunked

Both changes are "sticky" in that all subsequent request exhibit the corresponding timezone behavior even if i don't specify a 'If-Modified-Since' header in the request.



 Comments   
Comment by jameskojo [ 11/May/12 ]

On the server side, I am consuming the header like this:

        // determine and validate the If-Modified-Since timestamp
        long ifModifiedSince = 0;
        if (ifModifiedSinceStr != null) {
            try {
                Date ifModifiedSinceDate = HttpDateFormat.readDate(ifModifiedSinceStr);
                ifModifiedSince = ifModifiedSinceDate.getTime();
            } catch (ParseException e) {
                logger.warn("If-Modified-Since value could not be parsed: " + ifModifiedSinceStr
                        + ", ignoring header");
            }
        }

so the bug appears to be in HttpDateFormat, not jersey server.

Comment by Pavel Bucek [ 23/May/12 ]

Last-Modified header is produced by Jersey only when accessing WADL.

Looks like this is being added by your container - Apache-Coyote in your case.





[JERSEY-1125] Jersey-Servlet release 1.12 maven artifact references non-existing artifact weld-osgi-bundle 1.1.4.Final Created: 30/Apr/12  Updated: 08/Aug/13  Resolved: 03/May/12

Status: Resolved
Project: jersey
Component/s: None
Affects Version/s: 1.12, 1.13
Fix Version/s: 1.17

Type: Bug Priority: Critical
Reporter: converginglight Assignee: Pavel Bucek
Resolution: Invalid Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: maven

 Description   

Well, well, well-d. Problems with removed maven artifacts again:

Weld 1.1.4-Final is NOT available anymore...
So, all newer Jetty versions which are using it, including the latest 1.13-b01, can NOT be resolved using a dependency manager.
More exactly, there is NOT a SINGLE Jetty version left, which can be resolved and used, because older Weld versions are also gone.

Perhaps someone could talk to Weld guys?



 Comments   
Comment by converginglight [ 30/Apr/12 ]

Related to: JERSEY-931

Comment by Pavel Bucek [ 02/May/12 ]

what about http://repo1.maven.org/maven2/org/jboss/weld/weld-core/1.1.4.Final/ ?

Comment by converginglight [ 02/May/12 ]

Oh, I'm sorry, it must have been something wrong with my Ivy installation. I reinstalled it now, and now Weld 1.1.4 get's resolved and downloaded. Getting Jersey 1.13-b01 also works now.

Next time I will double check possible errors of such kind.

Comment by Pavel Bucek [ 03/May/12 ]

no problem.

Closing as invalid.





[JERSEY-1115] CDIExtension Not found Created: 17/Apr/12  Updated: 08/Aug/13  Resolved: 04/May/12

Status: Resolved
Project: jersey
Component/s: None
Affects Version/s: 1.12
Fix Version/s: 1.17

Type: Bug Priority: Critical
Reporter: jsl123 Assignee: Jakub Podlesak
Resolution: Works as designed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

ubuntu 11.10 3.0.0-15-server x86_64
Glassfish 3.1.2 with Jersey 1.12


Attachments: Text File exception.txt    

 Description   

When you deploy multiple webapps using jersey and CDI you get the attached exception dump when you access in specific situations. Any jersey based webapp having a beans.xml seems to be affected. Initially I thought this was related to virtual servers, but works if not using virtual servers.

The problem occurs when you have multiple webapps deployed using CDI, the problem happens for the second and subsequent webapps accessed after deployment, the first one accessed works as expected.

The behaviour differs slightly depending upon your use of virtual servers.

If you have multiple virtual servers and place each webapp into its a different virtual server, then whichever is "run" first works, the others fail with the attached exception. Redeploying makes no difference once the issue has been encountered, Restarting glassfish resets things and again the first to be run works ok, all others fail.

If you use a single virtual machine the issue is slightly different. With a fresh glassfish setup, you can install multiple webapps into the same virtual server without problem and all work as expected. However once you restart glassfish, only the first to be accessed works without the exception. Again, redeploying the "failed" apps doesn't solve the problem, the only way to resolve the issue is to undeploy all webapps and redeploy one by one.



 Comments   
Comment by Jakub Podlesak [ 02/May/12 ]

Could you please try to re-test with the following Java system property set to true?:
com.sun.jersey.server.impl.cdi.lookupExtensionInBeanManager

Does the issue stil reproduce?

Comment by jsl123 [ 03/May/12 ]

Hi, having seen another similar issue online I think I tried that - well I added a
<system-property> element to my domain.xml file which is where I assume you put such properties...

Just rechecked it and I obviously did something wrong before - it now appears to work. I'll monitor it to make sure it survives restarts, which was the problem before.

Thanks

Comment by Jakub Podlesak [ 04/May/12 ]

Thanks for the update. Closing the bug.
Please let me know, if it turns out the option does not help.
I am ready to reopen then.





[JERSEY-1063] In Jersey SVN brower, provide a hyperlinking ability to specific line of source code Created: 02/Apr/12  Updated: 08/Aug/13  Resolved: 08/Aug/13

Status: Resolved
Project: jersey
Component/s: website
Affects Version/s: None
Fix Version/s: 1.17

Type: Improvement Priority: Minor
Reporter: gmazza Assignee: Pavel Bucek
Resolution: Invalid Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Hi, the Apache source code browser allows us to link to a specific line in the source code, for example "#l24" places you on Line #24:
http://svn.apache.org/viewvc/cxf/trunk/distribution/src/main/release/samples/java_first_jms/pom.xml?revision=1303532&view=markup#l24

GitHub and GrepCode provide the same functionality in their source code browsers.

It would be nice if the Jersey SVN browser (http://java.net/projects/jersey/sources/svn/show/trunk/jersey) offered the same ability, so we can easily point others to specific methods under discussion. I know I can use GrepCode, but the Jersey SVN is most up-to-date (it offers a view of trunk).



 Comments   
Comment by Pavel Bucek [ 02/Apr/12 ]

please see http://home.java.net/enhancements-list (feel free to file new enhancement there, there is nothing we can do about it in project jersey settings).

Comment by gmazza [ 03/Apr/12 ]

Added there, thanks for the link!





[JERSEY-1059] Nullpointer in CDIExtension class which any other servlet in container has an Annotation on Field Created: 31/Mar/12  Updated: 08/Aug/13  Resolved: 03/May/12

Status: Resolved
Project: jersey
Component/s: extensions
Affects Version/s: 1.10
Fix Version/s: 1.17

Type: Bug Priority: Major
Reporter: khurrum_a Assignee: Jakub Podlesak
Resolution: Cannot Reproduce Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Zip Archive 1059.zip    

 Description   

I am using jersey-servlet.jar version 1.10 in my webapp with resin4 server.

I have a servlet which has an annotation on its field.

@Deprecated
public static final String SERVLET_CONNECTOR_NAME_PROPERTY = "org.mule.servlet.connector.name";

<servlet>
<servlet-name>muleRESTServlet</servlet-name>
<servlet-class>org.mule.transport.servlet.MuleReceiverServlet</servlet-class>
.....
</servlet>

When i start the server i get Null pointer in CDIExtension. Here is the stacktrace

[2012-03-31 09:56:29.155] WEB-INF/web.xml:57: com.caucho.server.dispatch.ServletConfigImpl.setServletClass(): javax.enterprise.inj ect.InjectionException: com.sun.jersey.server.impl.cdi.CDIExtension@1833c9c.processAnnotatedType: null

55: <servlet>
56: <servlet-name>muleRESTServlet</servlet-name>
57: <servlet-class>org.mule.transport.servlet.MuleReceiverServlet</servlet-class>
58: <init-param>
59: <param-name>org.mule.servlet.timeout</param-name>

at com.caucho.config.xml.XmlConfigContext.error(XmlConfigContext.java:1231)
at com.caucho.config.xml.XmlConfigContext.configureChildNode(XmlConfigContext.java:470)
at com.caucho.config.xml.XmlConfigContext.configureNode(XmlConfigContext.java:370)
at com.caucho.config.xml.XmlConfigContext.configureChildBean(XmlConfigContext.java:697)
at com.caucho.config.xml.XmlConfigContext.configureBeanProperties(XmlConfigContext.java:683)
at com.caucho.config.xml.XmlConfigContext.configureChildNode(XmlConfigContext.java:463)
at com.caucho.config.xml.XmlConfigContext.configureNode(XmlConfigContext.java:370)
at com.caucho.config.xml.XmlConfigContext.configureBean(XmlConfigContext.java:284)
at com.caucho.config.Config.configureBean(Config.java:373)
at com.caucho.config.Config.configureBean(Config.java:339)
at com.caucho.config.core.ResinImport.init(ResinImport.java:136)
at sun.reflect.GeneratedMethodAccessor32.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at com.caucho.config.j2ee.PostConstructProgram.inject(PostConstructProgram.java:140)
at com.caucho.config.type.InlineBeanType.init(InlineBeanType.java:444)
at com.caucho.config.xml.XmlConfigContext.configureChildBean(XmlConfigContext.java:702)
at com.caucho.config.xml.XmlConfigContext.configureBeanProperties(XmlConfigContext.java:683)
at com.caucho.config.xml.XmlConfigContext.configureChildNode(XmlConfigContext.java:463)
at com.caucho.config.xml.XmlConfigContext.configureAttribute(XmlConfigContext.java:323)
at com.caucho.config.program.NodeBuilderChildProgram.inject(NodeBuilderChildProgram.java:82)
at com.caucho.config.program.ContainerProgram.inject(ContainerProgram.java:86)
at com.caucho.config.program.ConfigProgram.configure(ConfigProgram.java:107)
at com.caucho.env.deploy.EnvironmentDeployController.configureInstance(EnvironmentDeployController .java:472)
at com.caucho.env.deploy.EnvironmentDeployController.configureInstance(EnvironmentDeployController .java:58)
at com.caucho.env.deploy.DeployController.startImpl(DeployController.java:666)
at com.caucho.env.deploy.StartAutoRedeployAutoStrategy.startOnInit(StartAutoRedeployAutoStrategy.j ava:77)
at com.caucho.env.deploy.DeployController.startOnInit(DeployController.java:523)
at com.caucho.env.deploy.DeployContainer.start(DeployContainer.java:170)
at com.caucho.server.webapp.WebAppContainer.start(WebAppContainer.java:713)
at com.caucho.server.host.Host.start(Host.java:676)
at com.caucho.env.deploy.DeployController.startImpl(DeployController.java:670)
at com.caucho.env.deploy.StartAutoRedeployAutoStrategy.startOnInit(StartAutoRedeployAutoStrategy.j ava:77)
at com.caucho.env.deploy.DeployController.startOnInit(DeployController.java:523)
at com.caucho.env.deploy.DeployContainer.start(DeployContainer.java:170)
at com.caucho.server.host.HostContainer.start(HostContainer.java:542)
at com.caucho.server.cluster.Server.start(Server.java:1228)
at com.caucho.server.cluster.ServletService.start(ServletService.java:72)
at com.caucho.env.service.ResinSystem.startServices(ResinSystem.java:513)
at com.caucho.env.service.ResinSystem.start(ResinSystem.java:481)
at com.caucho.server.resin.Resin.start(Resin.java:999)
at com.caucho.server.resin.Resin.initMain(Resin.java:1127)
at com.caucho.server.resin.Resin.main(Resin.java:1426)
Caused by: com.caucho.config.ConfigException: com.caucho.server.dispatch.ServletConfigImpl.setServletClass(): javax.enterprise.inject.InjectionException: com.sun.jersey.server.impl.cdi.CDIExtension@1833c9c.processAnnotatedType: null
at com.caucho.config.ConfigException.create(ConfigException.java:99)
at com.caucho.config.ConfigException.create(ConfigException.java:130)
at com.caucho.config.attribute.SetterAttribute.setText(SetterAttribute.java:135)
at com.caucho.config.xml.XmlConfigContext.setText(XmlConfigContext.java:543)
at com.caucho.config.xml.XmlConfigContext.configureInlineText(XmlConfigContext.java:584)
at com.caucho.config.xml.XmlConfigContext.configureChildNode(XmlConfigContext.java:458)
... 41 more
Caused by: com.caucho.config.ConfigException: javax.enterprise.inject.InjectionException: com.sun.jersey.server.impl.cdi.CDIExtension@1833c9c.processAnnotatedType: null
at com.caucho.config.ConfigException.createConfig(ConfigException.java:148)
at com.caucho.config.inject.InjectManager.createInjectionTarget(InjectManager.java:1166)
at com.caucho.server.dispatch.ServletConfigImpl.setServletClass(ServletConfigImpl.java:452)
at sun.reflect.GeneratedMethodAccessor19.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at com.caucho.config.attribute.SetterAttribute.setText(SetterAttribute.java:133)
... 44 more
Caused by: javax.enterprise.inject.InjectionException: com.sun.jersey.server.impl.cdi.CDIExtension@1833c9c.processAnnotatedType: null
at com.caucho.config.extension.ExtensionManager$ExtensionObserver.notify(ExtensionManager.java:715)
at com.caucho.config.event.EventManager.fireLocalEvent(EventManager.java:300)
at com.caucho.config.event.EventManager.fireExtensionEvent(EventManager.java:281)
at com.caucho.config.extension.ExtensionManager.processAnnotatedType(ExtensionManager.java:547)
at com.caucho.config.inject.InjectManager.createInjectionTarget(InjectManager.java:1156)
... 49 more
Caused by: java.lang.NullPointerException
at com.sun.jersey.server.impl.cdi.CDIExtension.processAnnotatedField(CDIExtension.java:612)
at com.sun.jersey.server.impl.cdi.CDIExtension.processAnnotatedType(CDIExtension.java:382)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at com.caucho.config.extension.ExtensionManager$ExtensionObserver.notify(ExtensionManager.java:704)
... 53 more

----------------------------------------------------------

knownParameterQualifiers is null in CDIExtension and because of the annotation in mule servlet the code tries line 612 below.

private <T> boolean processAnnotatedField(AnnotatedField<? super T> field,
Class<T> token,
boolean classHasEncodedAnnotation,
Map<AnnotatedField<? super T>, PatchInformation> fieldToPatchInfoMap) {
boolean mustPatch = false;
line:611 for (Annotation annotation : field.getAnnotations()) {
line:612 if (knownParameterQualifiers.contains(annotation.annotationType())) {

-------------------



 Comments   
Comment by Jakub Podlesak [ 03/Apr/12 ]

It looks like you work with an uninitialized CDIExtension instance. Would it be possible to add some more information on the use case.
Also if you set log level to fine for "com.sun.jersey.server.impl.cdi" does it log "Handling BeforeBeanDiscovery event" message?

Comment by khurrum_a [ 04/Apr/12 ]

Unfortunately i wiped out the project and don't have the logs available. If you want you can reproduce it by creating a servlet with one annotated field (@Deprecated) and use it with this example http://www.mkyong.com/webservices/jax-rs/jersey-spring-integration-example/. This should produce the null pointer at startup.

Comment by Jakub Podlesak [ 03/May/12 ]

test case app

Comment by Jakub Podlesak [ 03/May/12 ]

Closing as can not reproduce.

Attached a test case application for you reference. The application works just fine for me in GlassFish 3.1.2 application server.
If you want to re-open the bug, please provide a reproducible test case application or exact steps how to reproduce with the current one.





[JERSEY-1056] Digest in client Created: 30/Mar/12  Updated: 08/Aug/13  Resolved: 30/Mar/12

Status: Resolved
Project: jersey
Component/s: None
Affects Version/s: None
Fix Version/s: 1.17

Type: Bug Priority: Major
Reporter: haris2you Assignee: Unassigned
Resolution: Invalid Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

client.addFilter(new HTTPDigestAuthFilter(IPS_USERNAME, IPS_PASSWORD));

i user above code for he user authentication but this is not working so please any one explain me why this is not working? and Is Jersey not supporting Digest Authentication?

who i can use Digest Authentication in Jersey ?



 Comments   
Comment by Pavel Bucek [ 30/Mar/12 ]

please use mailing list (users@jersey.java.net) for questions, this is intended to report bugs (with thorough description and ideally testcase).

you might be hitting http://java.net/jira/browse/JERSEY-642.

closing as invalid for now, please investigate what is broken (plug-in LoggingFilter to see what is returned and/or provide stacktraces).





[JERSEY-1046] Jersey passing queryparam to path param method Created: 23/Mar/12  Updated: 08/Aug/13  Resolved: 29/Mar/12

Status: Resolved
Project: jersey
Component/s: None
Affects Version/s: 1.12
Fix Version/s: 1.17

Type: Bug Priority: Major
Reporter: jesmith17 Assignee: Jakub Podlesak
Resolution: Cannot Reproduce Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Mac OSX, Glassfish V 3.1.1, java 7



 Description   

Given 2 methods

@Path("/filter")
@Component
@Scope("request")
public class FilterWS {


  
       @GET
       @Path("/{channelId}/ip/{ipAddress:.+}/")
       @Produces(MediaType.APPLICATION_JSON)
       public IPBlackList getByIp(
               @HeaderParam("authToken") String authToken,
               @PathParam("ipAddress") String ipAddress) {

           ac.checkAccess(authToken, uriInfo.getPath());

           return blackListService.getByIp(ipAddress);
       }

and

       @GET
       @Path("/{channelId}/ip")
       @Produces(MediaType.APPLICATION_JSON)
       public List<IPBlackList> getAllForChannel(
               @HeaderParam("authToken") String authToken,
               @PathParam("channelId") Integer channelId,
               @QueryParam("global") Boolean global ){
           

           
           ac.checkAccess(authToken,uriInfo.getPath());
           if (global ==  null){
               global = true;
           }
           return blackListService.getIPBlackListByChannel(channelId, global);

       }

And the following URL
http://localhost:8080/filter/config/ip?global=false

It appears based on the call stack, that jersey is passing the above URL to the first method. But the URL I am passing thorugh the jersey client, doesn't meet the format of the first as it doesn't have the additional path param. It seems that jersey should be recognizing the query string param I am passing and mapping the request to the second Method pasted.

Any ideas on why? I have tried this with and without the regex pattern on the

{ipAddress}

param in the first method, and it doesn't seem to make any difference.



 Comments   
Comment by Martin Matula [ 26/Mar/12 ]

Marek, please evaluate.

Comment by Jakub Podlesak [ 29/Mar/12 ]

Can not reproduce. The above test case has an apparent issue in the second, getAllForChannel, method.
The channelId parameter gets mapped to an Integer, but in the URL used by the client
a String value, config, is included. Otherwise, if a number was used, the method would get selected.
Bellow is a test, which passes for me all right and demonstrates that Jersey behaves correctly.

-8<-
public class Issue1046Test extends AbstractResourceTester {

public Issue1046Test(String testName)

{ super(testName); }

@Path("/filter")
static public class FilterWS {

@GET
@Path("/

{channelId}/ip/{ipAddress:.+}/")
public String getByIp(@PathParam("ipAddress") String ipAddress) { return ipAddress; }

@GET
@Path("/{channelId}

/ip")
public String getAll(@PathParam("channelId") Integer channelId, @QueryParam("global") Boolean global)

{ return channelId + "?" + global; }

}

public void testFilterWS()

{ initiateWebApplication(FilterWS.class); final boolean checkStatus = false; assertEquals(404, resource("/filter/config/ip?global=false", checkStatus).get(ClientResponse.class).getStatus()); assertEquals("101?false", resource("/filter/101/ip?global=false").get(String.class)); }

}
->8-

Comment by Jakub Podlesak [ 29/Mar/12 ]

I am resolving the bug as can not reproduce.

However, if you find out a better test case or if it is reproducible for you
in certain environment/container, please share the details, so that i can re-open.





[JERSEY-1016] CLONE -ContainerRequest is not an HttpServletRequest Created: 15/Mar/12  Updated: 08/Aug/13  Resolved: 21/Mar/12

Status: Resolved
Project: jersey
Component/s: release
Affects Version/s: 1.12
Fix Version/s: 1.17

Type: Bug Priority: Critical
Reporter: eldalai Assignee: Pavel Bucek
Resolution: Invalid Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

i found out that the in WebComponent class, the createRequest method do not create a request as HttpServletRequest.

http://jersey.java.net/nonav/apidocs/1.11/jersey/com/sun/jersey/spi/container/servlet/WebComponent.html#createRequest(com.sun.jersey.spi.container.WebApplication, javax.servlet.http.HttpServletRequest, java.net.URI, java.net.URI)

it is creating an ContainerRequest, that implements some intefaces but is not an HttpServletRequest.

http://jersey.java.net/nonav/apidocs/1.11/jersey/com/sun/jersey/spi/container/ContainerRequest.html

If jersey needs to re-create a request from a HttpServletRequest, why ContainerRequest couldn't just extend HttpServletRequest.

Weblogic doesn't like ContainerRequest, needs a HttpServletRequest



 Comments   
Comment by eldalai [ 15/Mar/12 ]

yes, i understand your position but WebComponent#createRequest recibe a HttpServletRequest... not just an Request.

Comment by Pavel Bucek [ 15/Mar/12 ]

So?

I still don't see any described usecase. Why are you even using WebComponent?

If you want to use Jersey in Servlet environment, register com.sun.jersey.spi.container.servlet.ServletContainer as Servlet or Filter.

Comment by Pavel Bucek [ 15/Mar/12 ]

Just technical note - You don't need to clone issues, you can just reopen them (don't reopen original now). I won't close this one before you provide further info.

Comment by eldalai [ 15/Mar/12 ]

ServletContainer use WebComponent to process the request.

In one of this steps WebComponent re-create a request, i think because the framework need to add some special things. For re-create the request, the createRequest method in WebComponent, recibe a HttpServletRequest and convert to a ContainerRequest, what is just a Request.

ServletContainer use WebComponent as an internal private class. May be you could override the createRequest method in this internal class, just for Servlet implementarions, for return a "WebContainerRequest" which shoud extend HttpServletRequest and implement the same interfaces in ContainerRequest.

ServletContainer
private class InternalWebComponent extends WebComponent {

What do you think?

Comment by Pavel Bucek [ 15/Mar/12 ]

Why would I want to do that?

ContainerRequest is not just a Request (are we talking about javax.ws.rs.core.Request, right?) its implementations of HttpRequestContext which "extends HttpHeaders, Request, SecurityContext, Traceable".

WebComponent#createRequest is used only for transforming HttpServletRequest into something Jersey runtime can handle. It can't implement/extend HttpServletRequest, because it would introduce javax.servlet API dependency for jersey-server, which is not acceptable for us.

You still can inject (via @Context) original HttpServletRequest into resource/provider class if you need it.

Please describe your usecase / scenario. I'm still not convinced you need change in Jersey SPI.

Comment by Pavel Bucek [ 21/Mar/12 ]

closing as invalid. feel free to add comments or reopen with valid usecase.





[JERSEY-1015] ContainerRequest is not an HttpServletRequest Created: 15/Mar/12  Updated: 08/Aug/13  Resolved: 15/Mar/12

Status: Resolved
Project: jersey
Component/s: release
Affects Version/s: 1.12
Fix Version/s: 1.17

Type: Bug Priority: Critical
Reporter: eldalai Assignee: Pavel Bucek
Resolution: Works as designed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

i found out that the in WebComponent class, the createRequest method do not create a request as HttpServletRequest.

http://jersey.java.net/nonav/apidocs/1.11/jersey/com/sun/jersey/spi/container/servlet/WebComponent.html#createRequest(com.sun.jersey.spi.container.WebApplication, javax.servlet.http.HttpServletRequest, java.net.URI, java.net.URI)

it is creating an ContainerRequest, that implements some intefaces but is not an HttpServletRequest.

http://jersey.java.net/nonav/apidocs/1.11/jersey/com/sun/jersey/spi/container/ContainerRequest.html

If jersey needs to re-create a request from a HttpServletRequest, why ContainerRequest couldn't just extend HttpServletRequest.

Weblogic doesn't like ContainerRequest, needs a HttpServletRequest



 Comments   
Comment by Pavel Bucek [ 15/Mar/12 ]

Jersey internally uses ContainerRequest/Response, because it does not require Servlet to run - so it wouldn't be very wise to depend on Servlet API.

feel free to reopen with valid issue/enhancement.

Comment by eldalai [ 15/Mar/12 ]

yes, i understand your position but WebComponent#createRequest recibe a HttpServletRequest... not just an Request.





[JERSEY-1011] Receiver 405 status response when a GET and POST both reside at same URL Created: 13/Mar/12  Updated: 08/Aug/13  Resolved: 13/Mar/12

Status: Resolved
Project: jersey
Component/s: core
Affects Version/s: 1.9.1, 1.12
Fix Version/s: 1.17

Type: Bug Priority: Major
Reporter: jesmith17 Assignee: Unassigned
Resolution: Works as designed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Mac OSX, JDK 7, Glassfish 3.1.1


Tags: 405-response, jersey

 Description   

I have a WS class using Jersey annotations.

2 different methods that are both bound to the same URL patter

/filter/

{channel_id}

/ip
One uses a GET, the other a POST.
Regardless of which method I call, I get back a 405 response.

Exception in thread "main" com.sun.jersey.api.client.UniformInterfaceException: GET http://localhost:8080/filter/1000/config/ returned a response status of 405 Method Not Allowed
at com.sun.jersey.api.client.WebResource.handle(WebResource.java:676)
at com.sun.jersey.api.client.WebResource.access$200(WebResource.java:74)
at com.sun.jersey.api.client.WebResource$Builder.get(WebResource.java:503)

I tried switching the POST to a PUT (as according to some information the POST is a hybrid of GET and PUT in terms of how jersey supports it).

I have found examples from Jersey that shows that I should be able to do this. In fact, it's a pretty fundamental part of REST services.

Any ideas

here is code examples to show you what all is happening

— Example of the GET

@GET
@Path("/{channelId}/ip/")
@Produces(MediaType.APPLICATION_JSON)
public List<IPBlackList> getAllForChannel(
        @HeaderParam("authToken") String authToken,
        @PathParam("channelId") Integer channelId){
     ac.checkAccess(authToken,uriInfo.getPath());
     return blackListService.getIPBlackListByChannel(channelId);
}

----- POST Example

@POST
@Consumes(MediaType.APPLICATION_JSON)
@Path("/{channelId}/ip/")
public void saveIPBlackList(@HeaderParam("authToken") String authToken,
                            @PathParam("channelId") Integer channelId,
                            List<IPBlackList> ipBlackLists){
    ac.checkAccess(authToken,uriInfo.getPath());
    for (IPBlackList ip : ipBlackLists){
        ip.setChannelId(channelId);
    }
    blackListService.saveIPBlackList(ipBlackLists);
}


 Comments   
Comment by Pavel Bucek [ 13/Mar/12 ]

there is no resource which would serve GET http://localhost:8080/filter/1000/config/ request in your code.

Did you mean GET http://localhost:8080/filter/1000/ip/ ?

Comment by jesmith17 [ 13/Mar/12 ]

Yes, I did mean localhost:8080/filter/1000/ip.

But after doing alot of other digging i found the problem, and it was a simply code error

The method in question had been defined as

@GET
@Path("/

{channelid}

/config ")

Notice the extra space at the end. When submitting the actual URL, everything was correctly stripping the space off of the end, so it legitimately did find a 405 as the only type supported by that URL was not a GET.

So I think this changes from a bug to a feature, that Jersey should auto-trim the URL's defined in the annotations, as the white space at the end of the URL isn't a legal URL string. Having jersey trim those for leading or trailing spaces would be a minor fix, but would prevent little issues like this one.

Comment by Pavel Bucek [ 13/Mar/12 ]

extra space was automatically percent encoded, see JAX-RS spec:

"The literal part of the supplied value (those characters that are not part of a template parameter) is automatically percent encoded"

(from javax.ws.rs.core.Path javadoc)

closing as works as designed.





[JERSEY-990] Simple Class derived from HelloWorld example throws java.lang.NoSucheMethodErr Created: 20/Feb/12  Updated: 08/Aug/13  Resolved: 01/Mar/12

Status: Resolved
Project: jersey
Component/s: examples
Affects Version/s: 1.11
Fix Version/s: 1.17

Type: Bug Priority: Minor
Reporter: wolfgang_fahl Assignee: Pavel Bucek
Resolution: Invalid Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Eclipse / Mac OS 10.6, Maven



 Description   

I get the following error from a simple class derived from the HelloWorld Example.

INFO: Scanning for root resource and provider classes in the packages:
com.bitplan.restgenerator
Exception in thread "main" java.lang.NoSuchMethodError: com.sun.jersey.api.core.ResourceConfig.getSingletons()Ljava/util/Set;
at com.sun.jersey.server.impl.container.grizzly2.GrizzlyContainer.<init>(GrizzlyContainer.java:149)
at com.sun.jersey.server.impl.container.grizzly2.GrizzlyContainerProvider.createContainer(GrizzlyContainerProvider.java:76)
at com.sun.jersey.server.impl.container.grizzly2.GrizzlyContainerProvider.createContainer(GrizzlyContainerProvider.java:53)
at com.sun.jersey.api.container.ContainerFactory.createContainer(ContainerFactory.java:133)
at com.sun.jersey.api.container.grizzly2.GrizzlyServerFactory.createHttpServer(GrizzlyServerFactory.java:242)
at com.sun.jersey.api.container.grizzly2.GrizzlyServerFactory.createHttpServer(GrizzlyServerFactory.java:136)
at com.bitplan.resthelper.RestServer.startWebServer(RestServer.java:115)
at com.bitplan.restgenerator.GeneratorServer.main(GeneratorServer.java:39)

this is my classpath:
<classpathentry exported="true" kind="var" path="M2_REPO/com/sun/jersey/jersey-grizzly2/1.11/jersey-grizzly2-1.11.jar"/>
<classpathentry exported="true" kind="var" path="M2_REPO/com/sun/jersey/jersey-bundle/1.11/jersey-bundle-1.11.jar"/>
<classpathentry exported="true" kind="var" path="M2_REPO/org/glassfish/grizzly/grizzly-http-server/2.1.2/grizzly-http-server-2.1.2.jar"/>
<classpathentry exported="true" kind="var" path="M2_REPO/javax/ws/rs/jsr311-api/1.1.1/jsr311-api-1.1.1.jar"/>
<classpathentry exported="true" kind="var" path="M2_REPO/asm/asm/3.1/asm-3.1.jar"/>
<classpathentry exported="true" kind="var" path="M2_REPO/org/glassfish/grizzly/grizzly-framework/2.1.2/grizzly-framework-2.1.2.jar"/>
<classpathentry exported="true" kind="var" path="M2_REPO/org/glassfish/grizzly/grizzly-http/2.1.2/grizzly-http-2.1.2.jar"/>
<classpathentry exported="true" kind="var" path="M2_REPO/com/sun/jersey/jersey-json/1.11/jersey-json-1.11.jar"/>
<classpathentry exported="true" kind="var" path="M2_REPO/com/sun/jersey/jersey-client/1.11/jersey-client-1.11.jar"/>
<classpathentry exported="true" kind="var" path="M2_REPO/com/sun/jersey/jersey-core/1.11/jersey-core-1.11.jar"/>
<classpathentry exported="true" kind="var" path="M2_REPO/com/sun/jersey/jersey-test-framework/jersey-test-framework-core/1.11/jersey-test-framework-core-1.11.jar"/>
<classpathentry exported="true" kind="var" path="M2_REPO/args4j/args4j/2.0.15/args4j-2.0.15.jar"/>
<classpathentry exported="true" kind="var" path="M2_REPO/com/google/inject/guice/3.0/guice-3.0.jar"/>
<classpathentry exported="true" kind="var" path="M2_REPO/aopalliance/aopalliance/1.0/aopalliance-1.0.jar"/>
<classpathentry exported="true" kind="var" path="M2_REPO/javax/inject/javax.inject/1/javax.inject-1.jar"/>
<classpathentry exported="true" kind="var" path="M2_REPO/org/simpleframework/simple-xml/2.6.2/simple-xml-2.6.2.jar"/>



 Comments   
Comment by wolfgang_fahl [ 21/Feb/12 ]

The classpath given above was not complete. There was also an older Jersey version on the CLASSPATH.
After fixing this problem I than ran into the follow-up problem that there were two different ASM versions on my classpath.

All in all this bugreport is more about having a better check for classpath problems. The HelloWorld example relies
on Maven for resolving these issues. In real world projects Jersey will not be the only set of jar files being used
and then things can get troublesome very quickly given the way Jersey's dependency class/jar dependency tree is set up.

Comment by Pavel Bucek [ 21/Feb/12 ]

so.. what exactly are you reporting? Or maybe better - what you think we should do?

Comment by wolfgang_fahl [ 23/Feb/12 ]

You might want to improve the errorhandling so that simple standard exceptions that are inexcplicable to
a common jersey user are explained:
e.g.

  • Nullpointer exception
  • Classnot found
  • No ClassDef
  • No such Method

and add an explanation how to check these problems
e.g. "you might want to check ..."
For these checks the proper tools might be offered e.g. a sanity check that looks that an installation
is properly configured. The late binding approach that seems to be going on here behind the scenes can be quite
troublesome at times if no further support for checks is offered.

I am not asking for strict backward compatibility here since that would partly worsen the situation in a mixed classpath situation - the need for a proper check of the setup would be even greater.

Comment by Pavel Bucek [ 23/Feb/12 ]

to be honest, I can't see how we can easily solve this - we can't really do something like classpath scanning when producing exceptions.

Apps/Jersey is not able to control classpath, it is users responsibility. If you are talking about some specific case (I am particularly interested in any NPEs), please share reproducible testcase (or maybe just stacktrace could be sufficient) from which I could extract some unit test and improve error reporting for it.

In other words - this report seems to be too generic and I don't know what I should fix.

Comment by Pavel Bucek [ 01/Mar/12 ]

closing as Invalid - configuration issue.

Please file a new one (enhancement request) for outlined request for improvement in error reporting, with clear description of what should be improved (which message / stacktrace).

Thanks!





[JERSEY-989] @JSONProperty annotation being ignored Created: 18/Feb/12  Updated: 08/Aug/13  Resolved: 22/Feb/12

Status: Resolved
Project: jersey
Component/s: None
Affects Version/s: 1.11
Fix Version/s: 1.17

Type: Bug Priority: Major
Reporter: gmazza Assignee: Jakub Podlesak
Resolution: Works as designed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

JDK 7 Ubuntu.



 Description   

In Jersey's "jacksonjsonprovider" sample, change the CombinedAnnotationBean class to the following:

@XmlRootElement(name = "account")
public class CombinedAnnotationBean {

@JsonProperty("value")
int x;

@JsonProperty("strOneAlias")
String string1;

@JsonProperty("strTwoAlias")
public String string2;

@JsonProperty("strThreeAlias")
protected String string3;

@JsonProperty("strFourAlias")
private String string4;

String string5;
public String string6;
protected String string7;
private String string8;

public CombinedAnnotationBean(int x)

{ this.x = x; string1 = "firstVal"; string2 = "secondVal"; string3 = "thirdVal"; string4 = "fourthVal"; string5 = "fifthVal"; string6 = "sixthVal"; string7 = "seventhVal"; string8 = "eighthVal"; }

public CombinedAnnotationBean()

{ this(15); }

}

Then activate the REST service as given in this sample's README.
Running cURL on the above for JSON and XML gives the following output:

gmazza$ curl -HAccept:application/json http://localhost:9998/jacksonjsonprovider/combinedAnnotations
{"account":{"string2":"secondVal","string6":"sixthVal","value":12,"strOneAlias":"firstVal","strThreeAlias":"thirdVal","strFourAlias":"fourthVal"}}

gmazza$ curl -HAccept:application/xml http://localhost:9998/jacksonjsonprovider/combinedAnnotations
<?xml version="1.0" encoding="UTF-8" standalone="yes"?><account><string2>secondVal</string2><string6>sixthVal</string6></account>

I see two problems:

1.) In the JSON output, "string2":"secondVal" should be "strTwoAlias":"secondVal" (i.e., the @JSONProperty annotation is being ignored)

2.) Is it required for there to be a @JsonProperty annotation added in order for the class variable to show up in the JSON output? If yes, then the "string6":"sixthVal" element should not appear in the JSON output. If no, then string5, string7, and string8 should presumably also appear in the JSON output.

Also, this sample's README is missing any explanation or reference to this particular bean & resource.



 Comments   
Comment by Jakub Podlesak [ 22/Feb/12 ]

ad 1) the annotation is ignored because the Jackson JAXB annotation introspector takes precedence here,
you may try to exchange the order of the introspectors in MyObjectMapperProvider:102 and you will get your desired behaviour
ad 2) the same thing: it is the JAXB introspector which picks up the string6 field, as it has the public access qualifier

Regarding the README doc: i have just updated the README file. Need to feed it to our internal review process before it gets propagated outside

Comment by Jakub Podlesak [ 22/Feb/12 ]

Resolving the bug as works as designed. Please notice, that Jersey only delegates to Jackson in this case
to do all the JSON processing work. Jersey just passes Jackson specific configuration options further
and it is in Jackson capable hands what will happen under the hood.
See Jackson project page http://jackson.codehaus.org/ to get more information on Jackson configuration options.

Comment by gmazza [ 24/Feb/12 ]

Re your updates to the README doc – Jersey-670 also has a patch giving additions to it (mostly but not all proofreading); you may wish to incorporate the two together before having your internal review process look at it.

Comment by Jakub Podlesak [ 24/Feb/12 ]

Thanks. My update is already out. Michal Gajdos is working on incorporating Jersey-670 patch.





[JERSEY-967] Jersey Expires Header not working Created: 08/Feb/12  Updated: 08/Aug/13  Resolved: 16/Feb/12

Status: Resolved
Project: jersey
Component/s: None
Affects Version/s: 1.11
Fix Version/s: 1.17

Type: Bug Priority: Minor
Reporter: francesco23u Assignee: Pavel Bucek
Resolution: Invalid Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

windows 7; Apache Tomcat 7


Tags: expires, http, jersey

 Description   

Each time I browse a REST resource with Chrome, I notice that there's an HTTP Header Expires set to Thu, 01 Jan 1970 01:00:00 CET.

I tried to edit the Response adding:

return Response.ok( myObject ).expires(new Date(System.currentTimeMillis() + 3000);

Unfortunately, this adds another HTTP Header Expires instead of replacing the old one.



 Comments   
Comment by Martin Matula [ 15/Feb/12 ]

Pavel, please evaluate.

Comment by Pavel Bucek [ 16/Feb/12 ]

Jersey does not return this header by default - looks like this is produced by your container and since its Tomcat, you should check its documentation.

Closing as invalid, feel free to reopen when you can provide more info/proof that issue is in Jersey workspace.





[JERSEY-956] When specify @Context HttpHeaders in a constructer parameter of MessageBodyWriter and refer to the parameter, java.lang.IllegalStateException occurs Created: 03/Feb/12  Updated: 08/Aug/13  Resolved: 22/Feb/12

Status: Resolved
Project: jersey
Component/s: core
Affects Version/s: 1.8
Fix Version/s: 1.17

Type: Bug Priority: Major
Reporter: hosamu Assignee: Jakub Podlesak
Resolution: Invalid Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: File hello.war    

 Description   

When specify @Context HttpHeaders in a constructer parameter of MessageBodyWriter and refer to the parameter, java.lang.IllegalStateException occurs.
Following, variable of headers is not null and java.lang.IllegalStateException occurs when refer to the variable of headers.

server.StringWriter
@Provider
@Produces("text/plain")
public class StringWriter implements MessageBodyWriter<String> {
    public StringWriter(@Context HttpHeaders headers, @Context UriInfo uriInfo) {
        if (headers != null) {
            System.out.println(getClass().getName() + ": headers=" + headers);
        }
        if (uriInfo != null) {
            System.out.println(getClass().getName() + ": uriInfo=" + uriInfo);
        }
    }
    ...
}

But, following variable of headers is null.

server.StringWriter
@Provider
@Produces("text/plain")
public class StringWriter implements MessageBodyWriter<String> {
    @Context
    private HttpHeaders headers;

    @Context
    private UriInfo uriInfo;

    public StringWriter(@Context HttpHeaders headers, @Context UriInfo uriInfo) {
        System.out.println(getClass().getName() + ": this.headers=" + this.headers);
        System.out.println(getClass().getName() + ": this.uriInfo=" + this.uriInfo);
    }
    ...
}


 Comments   
Comment by Jakub Podlesak [ 22/Feb/12 ]

Using request related information does not make sense in the context of an entity provider initialization.

In the second case, you get injected a proxy, which could be leveraged in the request scope context
(readFrom/writeTo/isReadable/isWriteable methods), but not in the entity provider constructor.

Comment by Jakub Podlesak [ 22/Feb/12 ]

Resolved as invalid. Please feel free to re-open, but then please provide
detailed information on what you think is broken here + a concrete use case.

Comment by hosamu [ 23/Feb/12 ]

Thank you for your reply.

I understand, timing of injection.
I was a worried about that both become a different result at an injection place.
Because I was able to hear that these were normal results, I consented this issue.





[JERSEY-929] MediaType is not used for ContextResolver picking Created: 26/Jan/12  Updated: 08/Aug/13  Resolved: 21/Mar/12

Status: Resolved
Project: jersey
Component/s: core
Affects Version/s: 1.12
Fix Version/s: 1.17

Type: Bug Priority: Major
Reporter: jan.supol Assignee: Jakub Podlesak
Resolution: Invalid Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Suppose a resource:

class MyResource(){
@Context
Providers providers;

private EnumProvider getEnumProvider(MediaType type)

{ ContextResolver<EnumProvider> scr = providers.getContextResolver( EnumProvider.class, type); EnumProvider ep = scr.getContext(EnumProvider.class); return ep; }

Response getResponseByEnumProvider(EnumProvider expected, EnumProvider given)

{ Status status = Status.NO_CONTENT; if (given != null) status = given != expected ? Status.NOT_ACCEPTABLE : Status.OK; return Response.status(status).build(); }

@GET
@Path("isRegisteredTextPlainContextResolver")
public Response isRegisteredTextPlainContextResolver()

{ EnumProvider ep = getEnumProvider(MediaType.TEXT_PLAIN_TYPE); return getResponseByEnumProvider(EnumProvider.CTS, ep); }

@GET
@Path("isRegisteredTextPlainContextResolver2")
@Consumes(MediaType.TEXT_PLAIN)
@Produces(MediaType.TEXT_PLAIN)
public Response isRegisteredTextPlainContextResolver2(
@Context ContextResolver<EnumProvider> cr)

{ EnumProvider ep = cr.getContext(EnumProvider.class); return getResponseByEnumProvider(EnumProvider.CTS, ep); }

}

@Provider
public class EnumContextResolver implements ContextResolver<EnumProvider> {

@Override
public EnumProvider getContext(Class<?> type)

{ return type == EnumProvider.class ? EnumProvider.JAXRS : null; }

}

@Provider
@Produces(MediaType.TEXT_PLAIN)
public class TextPlainEnumContextResolver implements ContextResolver<EnumProvider> {
@Override
public EnumProvider getContext(Class<?> type)

{ return type == EnumProvider.class ? EnumProvider.CTS : null; }

}

public enum EnumProvider {
TCK, CTS, JAXRS;
}

When calling isRegisteredTextPlainContextResolver2(), the Provider.getContextResolver(EnumProvider.class, mediaType) is called with incorrect media type, even though the request contains Accept: text/plain and Content-Type: text/plain headers and TextPlainEnumContextResolver is not chosen.



 Comments   
Comment by Jakub Podlesak [ 21/Mar/12 ]

The test case above is a bit artificial. JAX-RS specification does not talk about
injecting ContextResolvers based on resource method @Consumes/@Produces annotation,
as that would be non-deterministic. What if more than one media type is specified?
What if the input/output media types differ?

Selecting context provider via (also used in the test case as the "works for me" part) Providers.getContextResolver
works just fine and fully conforms with the specification.
Following is an excerpt from the specification, talking about context resolver media type capabilities:

-8<-
4.3.1 Declaring Media Type Capabilities
Context provider implementations MAY restrict the media types they support using the @Produces anno- tation. The absence of this annotation is equivalent to its inclusion with media type ("/"), i.e. absence implies that any media type is supported.
When choosing a context provider an implementation sorts the available providers according to the media types they declare support for. Sorting of media types follows the general rule: x/y < x/* < /, i.e. a provider that explicitly lists a media type is sorted before a provider that lists /.
->8-

Comment by jan.supol [ 21/Mar/12 ]

API says:

Get a context resolver for a particular type of context and media type. The set of resolvers is first filtered by comparing the supplied value of mediaType with the value of each resolver's Produces, ensuring the generic type of the context resolver is assignable to the supplied value of contextType, and eliminating those that do not match. If only one resolver matches the criteria then it is returned. If more than one resolver matches then the list of matching resolvers is ordered with those with the best matching values of Produces (x/y > x/* > /) sorted first. A proxy is returned that delegates calls to ContextResolver.getContext(java.lang.Class) to each matching context resolver in order and returns the first non-null value it obtains or null if all matching context resolvers return null.

Spec says:
Sorting of media types follows the general rule: x/y < x/* < /, i.e. a provider that explicitly lists a media type is sorted before a provider that lists

Spec does not say Sorting by Media type is optional, it is not.

Comment by Jakub Podlesak [ 21/Mar/12 ]

What media type shall the implementation take in your case? The one from @Produces or the one from @Consumes annotation on the resource method?
I insist the JAX-RS specification is pretty vague on this, so you should be directly calling the Providers.getContextResolver method to retrieve desired context resolver based on desired media type.

Comment by jan.supol [ 21/Mar/12 ]

>> The one from @Produces or the one from @Consumes annotation on the resource method?)
The spec says:
Context provider implementations MAY restrict the media types they support using the @Produces annotation.

Hence, the one from Produces, sorted by "matching resolvers is ordered with those with the best matching values of Produces".

Nothing vague.

Comment by Jakub Podlesak [ 21/Mar/12 ]

That one refers to the provider @Produces annotation, not to the resource method one

Comment by Jakub Podlesak [ 21/Mar/12 ]

btw. if things are not vague, why would you use the @Consumes annotation on the second get method? Not talking about why to use @Consumes annotation on a @GET annotated method at all

Comment by jan.supol [ 22/Mar/12 ]

>> That one refers to the provider @Produces annotation, not to the resource method one

>> JAX-RS specification does not talk about injecting ContextResolvers based on resource method @Consumes/@Produces annotation

Both is correct, wrong assumption on my side.





[JERSEY-927] Package name resource config does not work in OSGi environment Created: 26/Jan/12  Updated: 08/Aug/13  Resolved: 27/Jan/12

Status: Resolved
Project: jersey
Component/s: core
Affects Version/s: 1.8
Fix Version/s: 1.17

Type: Bug Priority: Major
Reporter: saikirandaripelli Assignee: Jakub Podlesak
Resolution: Duplicate Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Duplicate
duplicates JERSEY-881 Package name resource config does not... Resolved
Tags: osgi

 Description   

I am not able to run Jersey OSGI WAB with PackagenamesResourceConfig in Apache Felix or Equinox.
I tried in jersey 1.8, 1.9 and 1.10.

<init-param>
<param-name>com.sun.jersey.config.property.resourceConfigClass</param-name>
<param-value>com.sun.jersey.api.core.PackagesResourceConfig</param-value>
</init-param>
<init-param>
<param-name>com.sun.jersey.config.property.packages</param-name>
<param-value>com.sun.jersey.samples.helloworld</param-value>
</init-param>



 Comments   
Comment by saikirandaripelli [ 26/Jan/12 ]

Steps to Reproduce:

1. Download sample osgi app from https://maven.java.net/service/local/artifact/maven/redirect?r=releases&g=com.sun.jersey.samples&a=helloworld-osgi-webapp&v=1.11&c=project&e=zip

2. un-zip it.

3. open helloworld-osgi-webapp-1.11/war-bundle/src/main/webapp/WEB-INF/web.xml

4. replace the init-params of "Jersey Web Application" servlet with one specified n Jira description.

5. Follow /helloworld-osgi-webapp-1.11/README.html and deploy it to Felix or Equinox and try to access the resource.

Comment by Pavel Bucek [ 27/Jan/12 ]

duplicate of http://java.net/jira/browse/JERSEY-881

Comment by Pavel Bucek [ 27/Jan/12 ]

duplicate





[JERSEY-896] Response is missing Date header Created: 29/Dec/11  Updated: 08/Aug/13  Resolved: 23/Mar/12

Status: Resolved
Project: jersey
Component/s: core
Affects Version/s: 1.10
Fix Version/s: 1.17

Type: Bug Priority: Major
Reporter: cowwoc Assignee: Jakub Podlesak
Resolution: Cannot Reproduce Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

According to http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.18 responses MUST contain a Date header, but Jersey allows users to return malformed Responses missing this header.

Expected behavior: If the user neglects to supply a Date header, Jersey should simply supply one (or throw an exception if it cannot).



 Comments   
Comment by Jakub Podlesak [ 23/Mar/12 ]

Just tried to reproduce. Updated the helloworld example HelloWorldResource like follows:

-8<-
@Path("/helloworld")
public class HelloWorldResource {

// The Java method will process HTTP GET requests
@GET
// The Java method will produce content identified by the MIME Media
// type "text/plain"
@Produces("text/plain")
public String getClichedMessage()

{ // Return some cliched textual content return "Hello World"; }

@GET
@Path("gaga")
public Response gaga()

{ return Response.ok("gaga", MediaType.TEXT_PLAIN).build(); }

}
->8-

After mvn clean compile exec:java, i got the following responses from the above methods, both containing a Date header:

-8<-
%curl -i http://localhost:9998/helloworld
HTTP/1.1 200 OK
Content-Type: text/plain
Date: Fri, 23 Mar 2012 23:07:18 GMT
Transfer-Encoding: chunked

Hello World
%curl -i http://localhost:9998/helloworld/gaga
HTTP/1.1 200 OK
Content-Type: text/plain
Date: Fri, 23 Mar 2012 23:07:24 GMT
Transfer-Encoding: chunked

gaga
->8-

Comment by cowwoc [ 12/Apr/12 ]

Confirmed. I cannot reproduce this in Jersey 1.12. Thanks!





[JERSEY-891] jersey-grizzly2: HTTP custom response phrase is ignored Created: 16/Dec/11  Updated: 08/Aug/13  Resolved: 24/May/12

Status: Resolved
Project: jersey
Component/s: core
Affects Version/s: 1.10
Fix Version/s: 1.17

Type: Bug Priority: Major
Reporter: frozen_spider Assignee: Pavel Bucek
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: 10 minutes
Time Spent: Not Specified
Original Estimate: 10 minutes
Environment:

Doesn't matter


Attachments: Java Source File GrizzlyContainer.java    
Tags: jersey, jersey-grizzly2, response

 Description   

As stated, custom HTTP response phrases are skipped, and only response code is used.

The fix is simple and trivial, but I'm new and don't know how should I submit it. I've attached a changed file from jersey-grizzly2-1.10



 Comments   
Comment by Pavel Bucek [ 16/Dec/11 ]

thanks for submission and patch.

unfortunately it seems like there is another related issue in jersey-client, which effectively disallows its users to get this information and I'm not sure whether we will be able to fix that.

Comment by Pavel Bucek [ 24/May/12 ]

this issue won't be fixed since it is a change in Jersey 1.x proprietary API which will be deprecated soon.





[JERSEY-879] com.sun.jersey.api.container.ContainerException: [failed to localize] no.root.res.in.res.cfg() Created: 03/Sep/09  Updated: 08/Aug/13  Resolved: 30/Mar/12

Status: Resolved
Project: jersey
Component/s: None
Affects Version/s: None
Fix Version/s: 1.17

Type: Bug Priority: Minor
Reporter: yangjungis Assignee: Jakub Podlesak
Resolution: Incomplete Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 9,373
Status Whiteboard:

v2.1.1_exclude


 Description   

在 Glassfish v2.1 容器中部署一个 war åŒ...,在这个åŒ...中使ç"¨äº† jersey client
部署æ��示一些é"™è¯¯
java.lang.IllegalStateException: ContainerBase.addChild: start:
LifecycleException: com.sun.jersey.api.container.ContainerException: [failed to
localize] no.root.res.in.res.cfg()
但是在 tomcat6.0.18 环境部署正常�



 Comments   
Comment by Hong Zhang [ 03/Sep/09 ]

let web team take a look

Comment by jluehe [ 03/Sep/09 ]

yangjungis, can you please provide additional details on how to reproduce the issue?

Comment by sandoz [ 04/Sep/09 ]

Google translates as follows:

In the Glassfish v2.1 container to deploy a war package, in this package is
used jersey client Prompted the deployment of some errors

java.lang.IllegalStateException: ContainerBase.addChild: start:
LifecycleException: com.sun.jersey.api.container.ContainerException: [failed
to localize] no.root.res.in.res.cfg ()

However, the deployment of a normal tomcat6.0.18 environment!

Please, if you can, provide a reproducible test case.

Comment by Ed Bratt [ 15/Oct/09 ]

Will not fix in v2.1.1

Comment by Jakub Podlesak [ 30/Mar/12 ]

I am resolving this as incomplete. Please attach a reproducible test case, if you want me to re-open.





[JERSEY-878] Entity provider would be determined that Entity provider class by order of registration. Created: 09/Dec/11  Updated: 08/Aug/13  Resolved: 04/Feb/13

Status: Resolved
Project: jersey
Component/s: core
Affects Version/s: 1.8
Fix Version/s: 1.17

Type: Bug Priority: Major
Reporter: hosamu Assignee: Jakub Podlesak
Resolution: Invalid Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Zip Archive example.zip    

 Description   

Ignore Accept when following conditions.

  • Register the following Entity providers (MessageBodyWriter).
    @Produces("x/y") ... hello.server.StringWriter1
    @Produces("x/*") ... hello.server.StringWriter2
    @Produces("*/*") ... hello.server.StringWriter3
    
  • The request header "Accept: */*" specified and send request.

The result is indefinite, Entity provider is hello.server.StringWriter1 selected, or hello.server.StringWriter3 selected.

CASE1 - server.log

Instantiated the Application class hello.server.HelloApp. The following root resource and provider classes are registered: [class hello.server.StringWriter1, class hello.server.StringWriter3, class hello.server.Hello, class hello.server.StringWriter2]
sayHello: Called
hello.server.StringWriter1: Called isWriteable()
hello.server.StringWriter1: mediaType=/
hello.server.StringWriter1: Called isWriteable()
hello.server.StringWriter1: mediaType=x/y
hello.server.StringWriter1: Called getSize()
hello.server.StringWriter1: Called writeTo()

CASE2 - server.log

Instantiated the Application class hello.server.HelloApp. The following root resource and provider classes are registered: [class hello.server.Hello, class hello.server.StringWriter2, class hello.server.StringWriter3, class hello.server.StringWriter1]
sayHello: Called
hello.server.StringWriter2: Called isWriteable()
hello.server.StringWriter2: mediaType=/
hello.server.StringWriter3: Called isWriteable()
hello.server.StringWriter3: mediaType=application/octet-stream
hello.server.StringWriter3: Called getSize()
hello.server.StringWriter3: Called writeTo()

[exsample.zip]

set AS_HOME=c:/glassfish3/glassfish
cd example/providers_accept
ant all


 Comments   
Comment by Jakub Podlesak [ 04/Feb/13 ]

This is an edge case scenario, where the message body writer declares it's capability to produce any media type.
Please note that it is recommended by the JAX-RS spec (since version 1 already) that message body writer implementations
specify at least one concrete type via @Produces annotation.





[JERSEY-837] @PUT Application_XML and passing a JAXB object without XMLROOTELEMENT and just XMLTYPE Created: 18/Nov/11  Updated: 08/Aug/13  Resolved: 08/Feb/12

Status: Resolved
Project: jersey
Component/s: None
Affects Version/s: 1.9.1
Fix Version/s: 1.17

Type: Bug Priority: Major
Reporter: Thomas_Ricaud Assignee: Pavel Bucek
Resolution: Works as designed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Hi,

I created the following ressource

@PUT
@Consumes(MediaType.APPLICATION_XML)
public Response doRegistration(JAXBElement<HRMasterDataType> hrmaster)

{ ... .. }

My HRMasterDataType was created using JAXB and the HR-XML standard definition.
As it is a complex type there is no @Xmlrootelement annotation in HRMasterDataType
only @Xmltype

@XmlAccessorType(XmlAccessType.FIELD)
@XmlType(name = "HRMasterDataType", propOrder = {
"documentID",
"alternateDocumentID",
"documentSequence",
"employerIdentifiers",
"masterPersonDossier",
"userArea"
})
public class HRMasterDataType {

@XmlElement(name = "DocumentID", namespace = "http://www.hr-xml.org/3")
protected IdentifierType documentID;
...
..

My client code is as follow.

ClientConfig config = new DefaultClientConfig();
Client client = Client.create(config);
WebResource service = client.resource(getBaseURI());
HRMasterDataType masterdata = new HRMasterDataType();
ClientResponse response = service.path("rest").path("registration")
.accept(MediaType.APPLICATION_XML)
.put(ClientResponse.class, masterdata);
System.out.println(response.getClientResponseStatus());

When executing my client I get the following error. ( when i use another class that contains an @Xmlrootelement annotation it works fine)

Exception in thread "main" com.sun.jersey.api.client.ClientHandlerException: com.sun.jersey.api.client.ClientHandlerException: A message body writer for Java type, class org.hr_xml._3.HRMasterDataType, and MIME media type, application/octet-stream, was not found
at com.sun.jersey.client.urlconnection.URLConnectionClientHandler.handle(URLConnectionClientHandler.java:149)
at com.sun.jersey.api.client.Client.handle(Client.java:648)
at com.sun.jersey.api.client.WebResource.handle(WebResource.java:670)
at com.sun.jersey.api.client.WebResource.access$200(WebResource.java:74)
at com.sun.jersey.api.client.WebResource$Builder.put(WebResource.java:533)
at com.hraccess.pps.client.RegistrationClient.main(RegistrationClient.java:30)
Caused by: com.sun.jersey.api.client.ClientHandlerException: A message body writer for Java type, class org.hr_xml._3.HRMasterDataType, and MIME media type, application/octet-stream, was not found
at com.sun.jersey.api.client.RequestWriter.writeRequestEntity(RequestWriter.java:288)
at com.sun.jersey.client.urlconnection.URLConnectionClientHandler._invoke(URLConnectionClientHandler.java:204)
at com.sun.jersey.client.urlconnection.URLConnectionClientHandler.handle(URLConnectionClientHandler.java:147)
... 5 more

Let me know if i misunderstood anything.

Thanks



 Comments   
Comment by Pavel Bucek [ 08/Feb/12 ]

Hello,

this is expected. Try following:

"my @XmlType annotated class"
    @XmlType
    public static class MyType {
        public String string;

        public MyType(String string) {
            this.string = string;
        }

        // JAXB requires this
        public MyType() {
        }
    }
"resource method"
    @POST
    public JAXBElement<MyType> ping(JAXBElement<MyType> myTypeJAXBElement) {
        System.out.println("### resource ### -> " + myTypeJAXBElement.getValue().string);
        return myTypeJAXBElement;
    }
"client call"
    @Test
    public void testMyType() {
        WebResource webResource = resource();

        JAXBElement<MyType> myTypeJAXBElement = new JAXBElement<MyType>(
                new QName("test"),
                MyType.class,
                new MyType("myTypeString"));

        final JAXBElement<MyType> jaxbElement =
                webResource.path("helloworld").post(new GenericType<JAXBElement<MyType>>() {},
                        myTypeJAXBElement);

        System.out.println("### client ### -> " + jaxbElement.getValue().string);
    }

you should get this output: (I've cleaned other log messages)

      1. resource ### -> myTypeString
      2. client ### -> myTypeString

hope it helps.. feel free to reopen if not

Regards,
Pavel





[JERSEY-800] File descriptor leak under high concurrency Created: 28/Oct/11  Updated: 08/Aug/13  Resolved: 16/Mar/12

Status: Resolved
Project: jersey
Component/s: core
Affects Version/s: 1.9
Fix Version/s: 1.17

Type: Bug Priority: Critical
Reporter: eufeller Assignee: Jakub Podlesak
Resolution: Cannot Reproduce Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Debian stable, 2.6.38-2-amd64, Maven


Tags: maven

 Description   

After some days of debugging I seem to have discovered a critical file descriptor leak in all available jersey versions. The problem appears on the server side when multiple clients concurrently access any method of the defined resource and finally leads to leaked named pipes (i.e., FIFO pipes) which remain attached to the server process. As a consequence, the default system limit for open file descriptors (1024) is reached fast (depending on the amount of concurrent accesses) and parts of the service relying on streams (e.g., sockets) start failing. Note, that the problem does not appear if client access is delayed. For example, sending requests sequentially to the server every 5 seconds does not yield to leaked file descriptors.

The basic system setup to reproduce the bug looks as follows:

On the server side:
-------------------

0. Maven with jersey 1.9 or any other version from the repository
1. Simple @Singleton resource with one POST method. For example:
@POST
@Path("testFdLeak")
@Consumes(

{MediaType.TEXT_PLAIN}

)
public void testFdLeak(@FormParam("id") String test) ....
2. Lightweight HTTP server from JDK6 (HttpServer) to accept and forward the requests to the defined resource (same problem appears with Grizzly httpd as well)

On the client side:
-------------------

Any client capable of sending a POST request can be used. For example we can execute the "curl" command concurrently with a basic bash script:

#!/bin/bash
for i in $(seq 1 30);
do
curl -i -H "Content-Type: text/plain" -X POST -d "id=jersey" http://127.0.0.1/filedescriptor/testFdLeak
done

Result of the call on the server side:
--------------------------------------

When calling "lsof -p pid_of_the_server" or listing the file descriptors from the appropriate proc filesystem "ls -al /proc/PID/fd" directory and you will notice many named pipes starting and ending in the same process to remain open. For example:

java 13253 user 198r FIFO 0,8 0t0 267476 pipe
java 13253 user 199w FIFO 0,8 0t0 267476 pipe
java 13253 user 200u 0000 0,9 0 863 anon_inode
java 13253 user 201r FIFO 0,8 0t0 267477 pipe
java 13253 user 202w FIFO 0,8 0t0 267477 pipe
java 13253 user 203u 0000 0,9 0 863 anon_inode

Thank you very much in advance for a possible advice on how to work around this problem.



 Comments   
Comment by eufeller [ 29/Oct/11 ]

Sorry the "&" is required at the end of the curl command and got lost while writing

Comment by Jakub Podlesak [ 16/Mar/12 ]

Closing as can not reproduce. I even increased the number of concurrent clients and run the following sequentially:

while true; do
for i in `seq 1 600`;
do
http_proxy="" curl -i -Hcontent-type:text/plain -XPOST http://localhost:9998/helloworld/testFdLeak &
done
done

Here you can see number of open files varies in time, but after off-loading the app, it returns to the original value:

while true; do
lsof -p 19653 | wc -l
sleep 2
done
254
255
254
254
258
254
255
255
254
257
254
255
254
254
254
254
255
254
256
255
255
254
254
254
254
254
254

Tested with Grizzly 2 http server container





[JERSEY-798] Ability to differentiate between different sub-resources using @Consumes Created: 26/Oct/11  Updated: 08/Aug/13  Resolved: 08/Aug/13

Status: Resolved
Project: jersey
Component/s: core
Affects Version/s: 1.9.1
Fix Version/s: 1.17

Type: New Feature Priority: Major
Reporter: cowwoc Assignee: Jakub Podlesak
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Imagine the following class hierarchy:

Animal
-> Cat
-> Dog

I'd like users to be able to specify:

/animals/4

and get back an "Animal" or "Cat" depending on the Accept header. They issue request an "Animal" to find out the resource type. They then repeat the request using the Cat or Dog Accept header and get back more detailed state information.

I believe the following should work (but doesn't):

@Consumes("Dog")
public DogResource getDog()
{
  return new DogResource();
}

@Consumes("Cat")
public CatResource getCat(){
  return new CatResource();
}

[...]

DogResource
{
  @GET
  public String getDog() {}

  @PUT
  @Produces("Dog")
  public void setDog(String) {}
}

CatResource
{
  @GET
  public String getCat() {}

  @PUT
  @Produces("Cat")
  public void setCat(String) {}
}

notice how @Consumes is inherited by the sub-resource @GET/@PUT methods.

See http://jersey.576304.n2.nabble.com/Specifying-different-sub-resources-depending-on-the-Content-Type-td6487299.html for a related discussion.



 Comments   
Comment by cowwoc [ 26/Oct/11 ]

A slight correction to the above code.

@Consumes("Dog")
public DogResource getDog()
{
  return new DogResource();
}

@Consumes("Cat")
public CatResource getCat(){
  return new CatResource();
}

should have read:

@Path("{id}/")
@Consumes("Animal")
public AnimalResource getAnimal(@PathParam("id") long id)
{
  return new AnimalResource(id);
}

@Path("{id}/")
@Consumes("Dog")
public DogResource getDog(@PathParam("id") long id)
{
  return new DogResource(id);
}

@Path("{id}/")
@Consumes("Cat")
public CatResource getCat(@PathParam("id") long id)
{
  return new CatResource(id);
}

When I run the above code I get:

SEVERE: The following errors and warnings have been detected with resource and/or provider classes:
  SEVERE: Conflicting URI templates. The URI template /{id}/ for sub-resource locator public AnimalResource AnimalsResource.getAnimal(long) and the URI template /{id}/ transform to the same regular expression /([^/]+?)(/.*)?
  SEVERE: Conflicting URI templates. The URI template /{id}/ for sub-resource locator public CatResource AnimalsResource.getCat(long) and the URI template /{id}/ transform to the same regular expression /([^/]+?)(/.*)?
  SEVERE: Conflicting URI templates. The URI template /{id}/ for sub-resource locator public DogResource AnimalsResource.getDog(long) and the URI template /{id}/ transform to the same regular expression /([^/]+?)(/.*)?
Comment by cowwoc [ 26/Oct/11 ]

Nevermind. I no longer think this feature is needed. My design was problematic for the following reason:

Given:

  • /animals/5 maps to a CatResource that has a sub-resource NameResource
  • /animals/5/name maps to the Cat's NameResource

If @Consumes is added at the Animal level it will match /animals/5 but not /animals/5/name which has a different content-type (neither a cat nor a dog). Furthermore, it's not reasonable to expect AnimalResource to provide @Consumes for every transitive type consumes by its sub-resources.

I found a design that works and (fortunately) relies on features that Jersey already provides:

@Path("animals/")
class AnimalsResource
{
  @Path("{id}/")
  public AnimalResource getAnimal(@PathParam("id") long id)
  {
    return new AnimalResource(id);
  }
}

class AnimalResource
{
  private final long id;

  public AnimalResource(long id)
  {
    this.id = id;
  }

  @GET
  @Produces("animal")
  public Response getAnimal()
  {
    // Look up animal by its ID and return properties common to all animals.
  }

  @GET
  @Produces("cat")
  public CatResource getCat()
  {
    return new Cat(id);
  }

  @GET
  @Produces("dog")
  public CatResource getDog()
  {
    return new Dog(id);
  }
}

You can close this issue.

Comment by cowwoc [ 31/Oct/11 ]

Pavel,

Please reopen this issue. The above code won't work.

In the above code, you must remove @GET from getDog(), getCat(), otherwise getAnimal() will never get selected. Once you do that Jersey will never select getCat() or getDog(). So to summarize:

  1. If I use @Produces or @Consumes at the AnimalsResource level, Jersey complains about conflicting URI templates.
  2. If I use @Produces or @Consumes at the AnimalResource level, Jersey will not select the getCat() or getDog().
Comment by cowwoc [ 31/Oct/11 ]

For what it's worth, I prefer approach #1: declaring all sub-resources at the AnimalsResource level and differenting based on @Consumes and/or @Produces.

Comment by cowwoc [ 31/Oct/11 ]

I just realized that approach #1 will not work. @Path and @Produces/@Consumes are not sufficient for differentiating between resources (at that level). If:

/animals/

{id}

maps to a AnimalResource, CatResource or DogResource
/animals/

{cat-id}

/purr maps to CatPurrResource
/animals/

{dog-id}

/bark maps to DogBarkResource

There is no way for the AnimalsResource to differentiate between:

/animals/5/purr that maps to a Cat, versus
/animals/6/bark that maps to a Dog

without looking up the resource in the database at the AnimalsResource level. You could try taking the sub-resource paths into consideration (purr or bark) but if the two have a similar sub-path then it won't work. For example:

/animals/5/tail (maps to a Cat's tail)
/animals/6/tail (maps to a Dog's tail)
but not all animals have a tail.

Any other ideas or should we close this issue again?

Comment by Jakub Podlesak [ 03/Nov/11 ]

The thing with not all animals have a tail seems fine to me.
But maybe i just do not fully understand the use case.

Imagine:

public class DogResource {

@Path("tail")
@GET @Produces("text/plain")
public String getTail()

{ return "dog tail" }

}

public class SpiderResource {

@Path("8th-leg")
@GET @Produces("text/plain")
public String getLeg()

{ return "Spider 8th leg" }

}

@Path("animals")
public class AnimalsResource {

@Path("

{id}

")
public Object animalLocator(@PathParam("id") String id)

{ return animalMap.get(id); }

In the animalLocator method above, you probably do not want
the client to tell you what you have in the map already, do you?

then it is all right to get:

404 for /animals/0/tail given that /animals/0 links to a spider resource
200 for /animals/1/tail given that /animals/1 links to a dog resource

etc...

if the client knew up front what you have inside the map, why would he need to ask
the service?

Comment by cowwoc [ 04/Nov/11 ]

Jakub,

I see two ways of looking at this problem:

  1. From an optimization point of view
  2. From a design point of view

From an optimization point of view, the problem with the single URI approach is that it requires two database queries to read one property. First you must find out what kind of animal you've got (in animalLocator), then you need to query the database a second time to read the specific property being requested.

The benefit of specifying the animal type in the path is that you know the exact list of properties you must retrieve from the database. You issue one query and limit yourself to the subset of properties you must retrieve. If the query doesn't return any results, either the entry doesn't exist or the user specified the wrong animal type (A user who requests a Dog with id 0 will get HTTP 404 even though there is a Spider with id 0).

From a design point of view, it's nice that each animal is uniquely identified by one URI in the single URI approach. When you wish to view /animals/0 as a Dog you Accept the dog content-type. When you wish to view /animals/0 as an Animal you Accept the animal content-type. And so on... It's almost like type casting.

The benefit of the multi-URI approach is that you can list all dogs by querying /dogs or all spiders by querying /spiders. This isn't as clean for the single-URI approach (you end up using query variables).

Comment by Jakub Podlesak [ 04/Nov/11 ]

Hi Gili,

Ad 1) I disagree on "the two queries are needed to get one single property".
Just consider the animalMap.get(id) a db query and you see that it only happens once.
I.e. the resource locator object you return contains all data from the database
needed for the particular id and no other queries (map.get) would be needed
within the single request

Ad 2) I think the design as you describe it is sort of broken.
You write: "When you wish to view /animals/0 as a Dog you Accept the dog content-type"
All right, but the accept header was designed to tell the server what kind of representation
you want to get for a particular resource. So what if i wanted to get the dog tail?
I.e. i want to get /animals/0/tail. What am i supposed to send in the accept header?
The dog content-type? Even if i want to get a tail representation?

Ad querying all dogs, ...)
There is nothing to block you from introducing another, say /dogs, resource
serving such a list, you can also have /dogs/0 resource for the first dog
in the collection and so on (/dogs/0/tail/length, dogs/0/name, ...)

Comment by cowwoc [ 04/Nov/11 ]
  1. How can you retrieve all properties for a Dog or a Snake when you don't know ahead of time what kind of animal it is? You wouldn't know which query needs to be run (since dogs and snakes have different properties and possibly reside in different database tables).
  2. I'm no longer advocating using the Accept to tell the server what kind of animal it is. You're right this approach will fail for Dog tails. Instead, I'm saying that once the server looks up the animal type in the database, it examines the Accept header and figures out whether it can provide such a representation. In the case of /animals/0/ the representation can be Animal or Dog. In the case of /animals/0/tail the representation can only be DogTail.
Comment by cowwoc [ 09/Nov/12 ]

I think we can both agree this discussion has reached its end (I think what I was asking for no longer makes any sense) so the issue can be closed as WON'T FIX. Thanks for helping me figure out the design implications.

Comment by Jakub Podlesak [ 22/Nov/12 ]

Closing as "won't fix" as suggested by Gili.





[JERSEY-790] Unable to send user defined error message in the status line of the http response using java restful web services deployed in Websphere Application Server 8.0 Created: 17/Oct/11  Updated: 08/Aug/13  Resolved: 28/Mar/12

Status: Resolved
Project: jersey
Component/s: core
Affects Version/s: 1.9
Fix Version/s: 1.17

Type: Bug Priority: Major
Reporter: rkonkimalla Assignee: Michal Gajdos
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Websphere Application Server 8.0 installed in Redhat Linux.



 Description   

I have developed a restul web application (Jersey) using JAVA EE6 technologies and deployed in WAS 8.0. I have several custom user defined exceptions and interested in sending the mobile client the error code along with the custom defined error message. With the help of the forum, I could successfully do this when I deployed the application in Glassfish 3.1. Following forum thread gives the full information:

http://www.java.net/forum/topic/glassfish/glassfish/how-send-user-defined-error-message-status-line-http-response-using-java-restful-web-services-0?force=151

The problem came when app is deployed in the latest WAS 8.0. Now the client can only get the status code (what ever server sends) but not the error message, which always shows "Undefined". However, web client (browser) gives the correct information like
"Error 520: The EmailId or Password you entered is incorrect."

Following is the sample code that runs successfully in Glassfish 3.1 but fails in WAS 8.0

------EXCEPTION response------------

public class UserNotFoundResponse implements Response.StatusType{

@Override
public int getStatusCode()

{ return 520; }

@Override
public Response.Status.Family getFamily()

{ return Response.Status.Family.SERVER_ERROR; }

@Override
public String getReasonPhrase()

{ return "The EmailId or Password you entered is incorrect."; }

}

-----calling the exception from restful web service---------------
@GET
@Produces("text/xml")
public Advertisements getAdvertisements(.....) {
try

{ //business logic }

catch(UserNotFoundException ex)

{ throw new WebApplicationException(ex, Response.status(new UserNotFoundResponse()).build()); }

catch(Exception ex)

{ ... }

}

---------------



 Comments   
Comment by Jakub Podlesak [ 03/Nov/11 ]

You wrote the client does not see the custom message,
but a browser can display it all right. That would suggest
there is a client side issue rather than an issue on the server side.

What if you try to add container response logging filter (see [1])
to your configuration? Can you see the status message included in responses?

[1]http://jersey.java.net/nonav/apidocs/latest/jersey/com/sun/jersey/api/container/filter/LoggingFilter.html

Comment by rkonkimalla [ 09/Nov/11 ]

Well, the client code is just two lines. I get the proper error message when the url points to the application deployed in Glassfish 3.1.
_________________________________________________________________________________________________________
java.net.URL url = new java.net.URL("url with get parameters");
java.net.HttpURLConnection conn = (java.net.HttpURLConnection)url.openConnection();
System.out.println("response code:" + conn.getResponseCode());
System.out.println("response message:" + conn.getResponseMessage());
__________________________________________________________________________________________________________

The result in Glassfish is
response code:520
response message:The EmailId or Password you entered is incorrect.

The result in WAS 8.0 is
response code:520
response message:Undefined

I have followed your instructions and still I did not get response message and I saw the following message in the log file:
-------
LoggingFilter I 2 * Server out-bound response
2 < 520
2 <
------

When I run the url in browser for WAS 8.0, the following is displayed in the browser
Error 520: The EmailId or Password you entered is incorrect.

The reason may be I see the following exception in the log file:

[11/9/11 13:37:34:403 EST] 0000001d webapp E com.ibm.ws.webcontainer.webapp.WebApp logServletError SRVE0293E: [Servlet Error]-[ServletAdaptor]: com.ibm.ws.webcontainer.webapp.WebAppErrorReport: The EmailId or Password you entered is incorrect.
at com.ibm.ws.webcontainer.webapp.WebAppDispatcherContext.sendError(WebAppDispatcherContext.java:624)
at com.ibm.ws.webcontainer.webapp.WebAppDispatcherContext.sendError(WebAppDispatcherContext.java:642)
at com.ibm.ws.webcontainer.srt.SRTServletResponse.sendError(SRTServletResponse.java:1231)
at com.sun.jersey.spi.container.servlet.WebComponent$Writer.finish(WebComponent.java:282)
at com.sun.jersey.api.container.filter.LoggingFilter$Adapter.finish(LoggingFilter.java:250)
at com.sun.jersey.spi.container.ContainerResponse.write(ContainerResponse.java:241)
at com.sun.jersey.server.impl.application.WebApplicationImpl._handleRequest(WebApplicationImpl.java:1437)
at com.sun.jersey.server.impl.application.WebApplicationImpl.handleRequest(WebApplicationImpl.java:1349)
at com.sun.jersey.server.impl.application.WebApplicationImpl.handleRequest(WebApplicationImpl.java:1339)
at com.sun.jersey.spi.container.servlet.WebComponent.service(WebComponent.java:416)
at com.sun.jersey.spi.container.servlet.ServletContainer.service(ServletContainer.java:537)
at com.sun.jersey.spi.container.servlet.ServletContainer.service(ServletContainer.java:699)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:668)
at com.ibm.ws.webcontainer.servlet.ServletWrapper.service(ServletWrapper.java:1147)
at com.ibm.ws.webcontainer.servlet.ServletWrapper.handleRequest(ServletWrapper.java:722)
at com.ibm.ws.webcontainer.servlet.ServletWrapper.handleRequest(ServletWrapper.java:449)
at com.ibm.ws.webcontainer.servlet.ServletWrapperImpl.handleRequest(ServletWrapperImpl.java:178)
at com.ibm.ws.webcontainer.filter.WebAppFilterManager.invokeFilters(WebAppFilterManager.java:1020)
at com.ibm.ws.webcontainer.webapp.WebApp.handleRequest(WebApp.java:3639)
at com.ibm.ws.webcontainer.webapp.WebGroup.handleRequest(WebGroup.java:304)
at com.ibm.ws.webcontainer.WebContainer.handleRequest(WebContainer.java:950)
at com.ibm.ws.webcontainer.WSWebContainer.handleRequest(WSWebContainer.java:1659)
at com.ibm.ws.webcontainer.channel.WCChannelLink.ready(WCChannelLink.java:195)
at com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.handleDiscrimination(HttpInboundLink.java:452)
at com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.handleNewRequest(HttpInboundLink.java:511)
at com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.processRequest(HttpInboundLink.java:305)
at com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.ready(HttpInboundLink.java:276)
at com.ibm.ws.tcp.channel.impl.NewConnectionInitialReadCallback.sendToDiscriminators(NewConnectionInitialReadCallback.java:214)
at com.ibm.ws.tcp.channel.impl.NewConnectionInitialReadCallback.complete(NewConnectionInitialReadCallback.java:113)
at com.ibm.ws.tcp.channel.impl.AioReadCompletionListener.futureCompleted(AioReadCompletionListener.java:165)
at com.ibm.io.async.AbstractAsyncFuture.invokeCallback(AbstractAsyncFuture.java:217)
at com.ibm.io.async.AsyncChannelFuture.fireCompletionActions(AsyncChannelFuture.java:161)
at com.ibm.io.async.AsyncFuture.completed(AsyncFuture.java:138)
at com.ibm.io.async.ResultHandler.complete(ResultHandler.java:204)
at com.ibm.io.async.ResultHandler.runEventProcessingLoop(ResultHandler.java:775)
at com.ibm.io.async.ResultHandler$2.run(ResultHandler.java:905)
at com.ibm.ws.util.ThreadPool$Worker.run(ThreadPool.java:1648)

Comment by rkonkimalla [ 06/Dec/11 ]

I am just wondering whether I need to provide any other information regarding this issue.

Comment by rkonkimalla [ 27/Mar/12 ]

I am finding the same problem in Jersey 1.12 version. I am just curious to know whether this problem will be solved in subsequent releases.

Comment by Michal Gajdos [ 28/Mar/12 ]

This does not seem to be a Jersey problem but it looks like a specific behaviour of WebSphere.

When your application throws an WebApplicationException exception with a custom status, Jersey calls HttpServletResponse#sendError(<statusCode>, <message>) (in your case the status code is 502 and the message is The EmailId or Password you entered is incorrect.). This is interpreted as expected (status code: 520, response message: The EmailId or Password you entered is incorrect.) on the client side for the containers like Jetty, Tomcat. WebSphere on the other hand returns the response message as defined by the HTTP spec - it's based on the status code (520 - undefined, 400 - bad request, ..).

I tried to return status code and response message based on your example (520) and then my own one (400) - you can see the results bellow.

$ curl -v -X GET http://localhost:9080/helloworld/helloworld
* About to connect() to localhost port 9080 (#0)
*   Trying 127.0.0.1...
* connected
* Connected to localhost (127.0.0.1) port 9080 (#0)
> GET /helloworld/helloworld HTTP/1.1
> User-Agent: curl/7.24.0 (i686-pc-cygwin) libcurl/7.24.0 OpenSSL/0.9.8t zlib/1.2.5 libidn/1.22 libssh2/1.3.0
> Host: localhost:9080
> Accept: */*
>
< HTTP/1.1 520 Undefined
< X-Powered-By: Servlet/3.0
< Content-Type: text/html;charset=ISO-8859-1
< $WSEP:
< Content-Language: en-CZ
< Transfer-Encoding: chunked
< Date: Wed, 28 Mar 2012 12:37:19 GMT
< Server: WebSphere Application Server/8.0
<
Error 520: The EmailId or Password you entered is incorrect.
* Connection #0 to host localhost left intact
* Closing connection #0
$ curl -v -X GET http://localhost:9080/helloworld/helloworld
* About to connect() to localhost port 9080 (#0)
*   Trying 127.0.0.1...
* connected
* Connected to localhost (127.0.0.1) port 9080 (#0)
> GET /helloworld/helloworld HTTP/1.1
> User-Agent: curl/7.24.0 (i686-pc-cygwin) libcurl/7.24.0 OpenSSL/0.9.8t zlib/1.2.5 libidn/1.22 libssh2/1.3.0
> Host: localhost:9080
> Accept: */*
>
< HTTP/1.1 400 Bad Request
< X-Powered-By: Servlet/3.0
< Content-Type: text/html;charset=ISO-8859-1
< $WSEP:
< Content-Language: en-CZ
< Transfer-Encoding: chunked
< Connection: Close
< Date: Wed, 28 Mar 2012 12:57:22 GMT
< Server: WebSphere Application Server/8.0
<
Error 400: The EmailId or Password you entered is incorrect.
* Closing connection #0

In the first case the response message (obtained from HttpURLConnection) is Undefined, the second one returns Bad Request.

I am afraid that if you want to get your custom message from application deployed in WebSphere you need to parse the response body of the returned message yourself.





[JERSEY-786] Request.selectVariant chooses wrong variant when Accept header or included MediaType has wild card Created: 07/Oct/11  Updated: 08/Aug/13  Resolved: 25/Feb/13

Status: Resolved
Project: jersey
Component/s: None
Affects Version/s: 1.9
Fix Version/s: 1.17

Type: Bug Priority: Major
Reporter: bassmanitram Assignee: Jakub Podlesak
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Ubuntu 10.10, Jetty servlet container, web application



 Description   

Summary - by example, in a @GET resource method with the following code...

@GET
public Response get(@Context Request request) {
MediaType types[] =

{MediaType.APPLICATION_JSON_TYPE, MediaType.APPLICATION_XML_TYPE, MediaType.TEXT_XML_TYPE, MediaType.TEXT_HTML_TYPE}

;
List<Variant> vars = Variant.mediaTypes(types).add().build();
Variant var = request.selectVariant(vars);

System.out.println("CHOSEN VARIANT IS: " + var.getMediaType());

and a request where the Accept header has only "*/xml" in it, the print shows that "application/json" is selected.

This has all sorts of repercutions with respect to the processing of @Produces annotaions in both resources and message body providers:

Example 1)

@GET
@Produces("*/json")
public Response getJSON() {

@GET
@Produces("*/xml")
public Response getXML() {

@GET
@Produces("text/html")
public Response getHTML() {

Accept header is "text/xml"

getJSON gets invoked. BUT text/xml message body producer gets used

Example 2)

@GET
@Produces("application/json")
public Response getJSON() {

@GET
@Produces(

{"application/xml", "text/xml"}

) //or any other syntax for getting a list
public Response getXML() {

@GET
@Produces("text/html")
public Response getHTML() {

Accept header is "*/xml"

getJSON still gets invoked. and application/json message body producer gets used



 Comments   
Comment by Jakub Podlesak [ 25/Feb/13 ]

Resolving as won't fix, as this seems rather like a corner case for me. The client should be able to specify a concrete media type to accept.
Please feel free to re-open, if you think otherwise.





[JERSEY-766] getParameter of @Context HttpServletRequest request always returns null Created: 06/Sep/11  Updated: 08/Aug/13  Resolved: 25/Feb/13

Status: Resolved
Project: jersey
Component/s: None
Affects Version/s: 1.8
Fix Version/s: 1.17

Type: Bug Priority: Major
Reporter: inturico Assignee: Jakub Podlesak
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: 4 hours
Time Spent: Not Specified
Original Estimate: 4 hours


 Description   

Consider @POST @Produces( "text/html; charset=UTF-8" ) public StreamingOutput post( @Context HttpServletRequest request )

request.getParameterMap() is always empty and request.getParameter( ... ) therefore always returns null.

This was working correctly in Jersey 1.6 and is broken in Jersey 1.8. (I don't know about Jersey 1.7.)



 Comments   
Comment by Jakub Podlesak [ 25/Feb/13 ]

Resolving as won't fix. Query and form parameters should get accessed via JAX-RS means (see @QueryParam, @FormParam annotations)
rather then via injected HttpServletRequest instance. Please feel free to re-open, if there is a strong reason to make the parameters
accessible suggested way. But then please provide a more detailed test case.





[JERSEY-749] LoggingFilter does not log JSON entities Created: 09/Aug/11  Updated: 17/Apr/15  Resolved: 23/Jul/13

Status: Resolved
Project: jersey
Component/s: core
Affects Version/s: 1.8
Fix Version/s: 1.17

Type: Bug Priority: Major
Reporter: Francisco A. Lozano Assignee: Jakub Podlesak
Resolution: Won't Fix Votes: 4
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Java 1.6, Grizzly 1.9.27, Jackson 1.7.8



 Description   

I was using 1.5 and everything worked fine, I could see the JSON requests/responses going in and out.

Then I moved to 1.8 and it stopped working, the logger logs only the request and the headers but not the entities.

I've checked and it seems that it never passes from

if(in.available() > 0) {

I've copied the old Jersey 1.5 LoggingFilter to my source code tree (under a slightly different package name) and I can see again the JSON requests/responses perfectly logged.



 Comments   
Comment by Pavel Bucek [ 09/Aug/11 ]

can you share testcase?

That check was put there as a fix for another issue, so I'm a little reluctant to revert that change before I have a testcase which invalidates that change.

Comment by vguna [ 10/Apr/12 ]

Same here.

With Jersey 1.11, Tomcat 7 64bit, JDK 1.6.29 64bit. On my Windows7 PC, no logging for request entities work. just headers. Also debugged to the line mentioned in the initial post. For me it's always 0 - so no logging happens. If I read from the stream with a self-written MessageBodyReader after the LoggingFilter, I can output the request to the console without problems. So it has something todo with the available() implementation. It is the org.apache.catalina.connector.CoyoteInputStream and it returns 0. For sending requests I used soapUI 4.0.1 and the latest 4.5 version.

Funny thing: on my Ubuntu 10.04. Box (64bit, Tomcat 7 as well) for some requests it logs, for others not.

Hard to write a testcase for that. Maybe you can perform a quick check with the env specs given above.

For now I copy/pasted the 1.11'er LoggingFilter and reverted the changes of:

http://java.net/projects/jersey/sources/svn/diff/trunk/jersey/jersey-server/src/main/java/com/sun/jersey/api/container/filter/LoggingFilter.java?rev1=4834&rev2=4835

Comment by basalt79 [ 30/May/12 ]

Hi, I have the same problem like vguna.

The in.available() is called. if the application server is tomcat the InputStream is a org.apache.catalina.connector.CoyoteInputStream.

The org.apache.catalina.connector.InputBuffer available method will be called , but the state of this InputBuffer is still INITIAL_STATE and so the hock with ACTION_AVAILABLE will be called.
This action is not implemented in org.apache.coyote.http11.Http11Processor

So the only way to change the state is to call the realReadBytes method on InputBuffer.

I think the change has to be done in InputBuffer, because the available should also be set if the realReadBytes has not be called. because there is something to read and something to log.

So what was the issue you fixed with this in.available() if?

Tomcat Version Apache Tomcat/6.0.16
JVM Version 1.6.0_23-b05
JVM Vendor Sun Microsystems Inc.
OS Name Windows XP
OS Version 5.1
OS Architecture x86

Also tested with jetty and work fine.

Comment by increment1 [ 04/Feb/13 ]

I'm seeing this same issue with Jersey on Tomcat (but logs correctly on Jetty).

Pavel, can you comment on what issue that in.available() line was put in to fix, since I would like to create a filter without it but don't want to run into some unexpected issue.

Comment by increment1 [ 04/Feb/13 ]

For anyone else who is interested, I tracked down where/when/why the in.available() line was added to the LoggingFilter thus seemingly creating this particular issue with Tomcat (although I cannot comment on if this line is the actual cause and/or if the error is in Jersey or Tomcat):

summary: fixing container logging filter bug - timeout exception was produced when underlying connection was closed right after delivering entity-less response + re-enabling affected filter usages + fixed javadoc typo in ReaderWriter
revision: 4835
date: 2011-04-11 12:19:27 UTC (1 year)

http://java.net/projects/jersey/sources/svn/revision/4835

Comment by jose.cervera [ 12/Apr/13 ]

Also had this bug in Tomcat 7.0.35, JDK 1.7.0_07 Windows 32bits

For a quick workaround, and after seeing basalt79 comment, I changed the connector to HttpNioProtocol in Tomcat's server.xml:

<Connector port="80" protocol="org.apache.coyote.http11.Http11NioProtocol" ... />

The POST is now logged.

Regards.

Comment by Jakub Podlesak [ 23/Jul/13 ]

Resolving as won't fix as this seems to be only related to Tomcat and there is a known workaround.
I believe entity logging is needed for debug purpose only, and there the workaround should not hurt.
Please re-open, if you have strong objections.

Comment by quilleashm [ 30/Aug/13 ]

I would like to re-raise this please. We have observed using this setup

Jersey 1.17
Jetty 8.1.9

We always get the HTTP body for requests made within the same machine or machines within the same geographical area. However requests sent from a different country usually do not log the HTTP body. We have observed hitting the same server from two different locations where one logs correctly and the other does not, ruling out having the feature disabled.

My understanding of available() isn't perfect but I would imagine in any configuration it would be possible for the following to happen.

Client connects
Client renders HTTP headers
Client flushes
.. some time passes
Client renders HTTP body
Client flushes

Then the server would get

Incoming connection
Headers received
.. some time passes
Body received

If ContainerRequestFilters are fired once the headers are available but before the body has been received then available would return 0. Because of the available check the LoggingFilter does not wait for the body data and prints nothing. However if part/all of the body has been recieved (available returns > 0) then the filter reads until end-of-stream before logging.

I do not know the Jetty/Jersey internals but if neither of them ensure a complete request is available before filters are fired I could see this being possible.

Please let me know if you need any more information. Very difficult to provide a test case due to the intermittent nature of the problem.

Comment by jagathvijayan [ 16/May/14 ]

Using NIO connector as a workaround may not work for everyone. In some cases, we need to use BIO connector. So, please revert the change to in.available() > 0 and fix this issue.

Comment by dennisgermany [ 27/Oct/14 ]

We are using Tomcat 7 and Jersey 1.17 and cannot change the connector. We also vote for reopening. Thanks!

Comment by zeiss [ 20/Nov/14 ]

The same problem exists with com.sun.net.httpserver.HttpServer and Jersey 1.18.1, so it is not Tomcat-ony. Please reopen the issue.

Comment by luisjotapepe [ 28/Mar/15 ]

please open this. we are using 1.17 and even in 1.19 with Glassfish 3 and doesn't work! You can see that this is an important issue as many of us are looking for a legitimate solution. Thank you in advance.

Comment by smarni [ 17/Apr/15 ]

1.17 or 1.8 not able to log the request body





[JERSEY-747] Jersey client unable to unmarshal a custom type using SortedSet Created: 27/Jul/11  Updated: 08/Aug/13  Resolved: 14/Sep/11

Status: Resolved
Project: jersey
Component/s: core
Affects Version/s: 1.8
Fix Version/s: 1.17

Type: Bug Priority: Major
Reporter: abhi0123 Assignee: Pavel Bucek
Resolution: Invalid Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Jersey 1.9-SNAPSHOT, GlassFish 3.1, Sun JDK 6 update 26


Tags: Client, Collection, Jersey, Set, SortedSet

 Description   
Client
public void sendJerseyRequest() {
    ClientConfig cc = new DefaultClientConfig();
    cc.getSingletons().add(MovieSetMessageBodyReader.class);
    Client client = Client.create(cc);
    WebResource webResource = client.resource(GLASSFISH_ENDPOINT_URI);
    webResource.accept(MediaType.TEXT_XML);
    GenericType<OrderedAssembly<Movie>> assemblyType = new GenericType<OrderedAssembly<Movie>>() {
    };
    System.out.println("sendJerseyRequest: " + assemblyType.getRawClass());
    System.out.println("sendJerseyRequest: " + assemblyType.getType());
    OrderedAssembly<Movie> movies = webResource.queryParam("path", PATH)
        .get(assemblyType);

    System.out.println(movies);
    }
Log
Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.76 sec <<< FAILURE!
testSendJerseyRequest(name.app.abhi.movieservice.ejb.restful.client.MovieServiceEjbRestfulClientTest)  Time elapsed: 0.666 sec  <<< ERROR!
java.lang.IllegalArgumentException: Invalid type parameter e1: com.sun.org.apache.xerces.internal.dom.ElementNSImpl. Only name.app.abhi.moviemanager.domain.Movie accepted.
    at name.app.abhi.moviemanager.service.impl.MovieComparator.compare(MovieComparator.java:14)
    at java.util.TreeMap.put(TreeMap.java:530)
    at java.util.TreeSet.add(TreeSet.java:238)
    at com.sun.xml.internal.bind.v2.runtime.reflect.Lister$CollectionLister.addToPack(Lister.java:290)
    at com.sun.xml.internal.bind.v2.runtime.reflect.Lister$CollectionLister.addToPack(Lister.java:254)
    at com.sun.xml.internal.bind.v2.runtime.unmarshaller.Scope.add(Scope.java:106)
Movie.java
@XmlAccessorType(XmlAccessType.FIELD)
@XmlType(name = "movie", propOrder = { "name", "year", "genre", "filesize",
    "fileExtension", "parent" })
public class Movie implements Serializable {
    // fields, getters and setters
}
OrderedAssembly.java
@XmlRootElement(name = "movie-set", namespace = "http://name.app.abhi/movieservice")
@XmlType
@XmlAccessorType(XmlAccessType.FIELD)
public class OrderedAssembly<Movie> {

    @XmlElement(name = "movie")
    SortedSet<Movie> elements = new TreeSet<Movie>(new MovieComparator<Movie>());

    public OrderedAssembly() {
    }

    public OrderedAssembly(SortedSet<Movie> ss) {
    addAll(ss);
    }

    public OrderedAssembly(SortedSet<Movie> ss, Comparator<Movie> comparator) {
    elements = new TreeSet<Movie>(comparator);

    addAll(ss);
    }

    public SortedSet<Movie> getElements() {
    return elements;
    }

    private void addAll(SortedSet<Movie> ss) {
    if (ss != null) {
        elements.clear();
        elements.addAll(ss);
    }
    }
}


 Comments   
Comment by Pavel Bucek [ 27/Jul/11 ]

any thought why the exception is being thrown from MovieComparator class?

can you share complete (minimal) testcase (it would definitely speed things up..)?

Comment by abhi0123 [ 27/Jul/11 ]

Exception is thrown from MovieComparator because it (rightfully) does an instanceof check before proceeding to compare 2 movies.
The test case just calls the sendJerseyRequest() request (see below). If you are asking me to provide code that you can actually execute, I will have to create an entirely new one. The current project is a large one with some local dependencies and can't be easily exported.

Movie.java
@Override
    public int compare(E e1, E e2) {
	if (!(e1 instanceof Movie)) {
	    throw new IllegalArgumentException("Invalid type parameter e1: "
		    + e1.getClass().getName() + ". Only "
		    + Movie.class.getName() + " accepted.");
	}

	if (!(e2 instanceof Movie)) {
	    throw new IllegalArgumentException("Invalid type parameter e2: "
		    + e2.getClass().getName() + ". Only "
		    + Movie.class.getName() + " accepted.");
	}

	Movie m1 = (Movie) e1;
	Movie m2 = (Movie) e2;
        // comparison code
}
MovieServiceEjbRestfulClientTest
public class MovieServiceEjbRestfulClientTest {

    @Test
    public void testSendJerseyRequest() {
	new MovieServiceEjbRestfulClient().sendJerseyRequest();
    }
}
Comment by Pavel Bucek [ 27/Jul/11 ]

ok, thanks. I can recreate similar testcase by myself but it might take some time.

I will keep this issue updated.

Comment by Pavel Bucek [ 14/Sep/11 ]

Ok, I managed to recreate your sample in my environment.. and I got it working.

The key part and .. question I should have asked before is: "Why are you using your own MovieSetMessageBodyReader?". It does make sense, since it can't be unmarshalled without it. The problem here is that JAXBContext created for unmarshalling your type doesn't know about Movie.class, which can be easily fixed and you don't need to create your own message body reader (btw I still don't now what are you doing there).

CustomContextResolver
@Provider
public class CustomContextResolver implements ContextResolver<JAXBContext> {

    @Override
    public JAXBContext getContext(Class<?> type) {
        // if type != OrderedAssembly.class return null
        try {
            return JAXBContext.newInstance(OrderedAssembly.class, Movie.class);
        } catch(Exception e) {
            return null;
        }
    }

}
client code
        ClientConfig cc = new DefaultClientConfig();
        cc.getSingletons().add(new CustomContextResolver());
        Client c = Client.create(cc);
        webResource = c.resource(getURI());

        OrderedAssembly<Movie> set = webResource.path("helloworld/set").get(new GenericType<OrderedAssembly<Movie>>() {});
        ...

to be honest, I don't know how did you managed to produce this response (I can't see "service" code in your sample) without already having your custom JAXBContext resolver somewhere..

Anyway - closing as invalid. I can share my test if you want to see it. Feel free to reopen if you can share more info/testcase.





[JERSEY-740] LinkProcessor.getLinkHeaderValues triggering IndexOutOfBoundsException Created: 16/Jul/11  Updated: 08/Aug/13  Resolved: 25/Feb/13

Status: Resolved
Project: jersey
Component/s: None
Affects Version/s: 1.8
Fix Version/s: 1.17

Type: Bug Priority: Major
Reporter: ptomli Assignee: Jakub Podlesak
Resolution: Duplicate Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

J2SE 1.6, OS X 10.6.8, Jetty 7.4.2.v20110526



 Description   

If an exception is thrown when Jersey tries to create a @Resource to handle a request, and a @Provider ExceptionMapper catches the exception and produces a Response, the LinkProcessor creates a scenario where an IndexOutOfBoundsException is thrown.

The cause seems to be that getLinkHeaderValues assumes that there is (at least) one matching resource, as illustrated in the code

Object resource = uriInfo.getMatchedResources().get(0);

The problem is that there is no resource that matches, since it failed to be created.

The API documentation for UriInfo does not seem to indicate that there is a guarantee of there being a matched resource, though of course this would be the typical case.

My specific scenario, if it matters, is using jersey-spring, and an @Autowired dependency in the @Resource is not resolved. This results in a BeanCreationException, the bean which failed to be created is the @Resource.



 Comments   
Comment by Jakub Podlesak [ 25/Feb/13 ]

Resolving as duplicate of JERSEY-801, which has more thorough description and has a patch attached.





[JERSEY-738] Jersey does not conform to JAX-RS Specification - scanning for resources Created: 13/Jul/11  Updated: 08/Aug/13  Resolved: 08/Aug/13

Status: Resolved
Project: jersey
Component/s: None
Affects Version/s: None
Fix Version/s: 1.17

Type: Bug Priority: Blocker
Reporter: MarcinS Assignee: Jakub Podlesak
Resolution: Invalid Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Text File Testing_JAX-RS_conformance.patch    

 Description   

Jersey does not conform to JAX-RS Specification (latest version - 1.1). The way scanning is performed by ScanningResourceConfig class does not follow the specification to the letter.

The specification says:
"A resource class is a Java class that uses JAX-RS annotations to implement a corresponding Web resource.
Resource classes are POJOs that have at least one method annotated with @Path or a request method desig-
nator."

I've provided JUnit tests (failing) that check this, in a patch attached.

According to the specification, the following cases SHOULD NOT be detected as resources:

  • classes with @Path annotation on the TYPE level and no methods with @Path annotation (fails),
  • interfaces with @Path annotation on the TYPE level and no methods with @Path annotation (fails),
  • interfaces with @Path annotation on the METHOD level and no annotation on the TYPE level (passes),
  • interfaces with @HttpMethod designated annotation on the METHOD level (passes),

According to the specification, the following cases SHOULD be detected as resources:

  • classes with @Path annotation on the METHOD level and no annotation on the TYPE level (fails),
  • classes with @HttpMethod designated annotation on the METHOD level (fails).

Applying changes to Jersey now, so it conforms to the specification, might break any existing applications using it already, so probably a separate flag for JAX-RS conformance could be introduced.

In addition current behaviour for scanning in search of resources should be separately documented and clearly marked as not conforming to the specification.



 Comments   
Comment by Christopher Currie [ 17/Jul/11 ]

IIUC, this is not an issue with spec conformance. The purpose of ScanningResourceConfig (according to its JavaDoc) is to find root resource classes, not just any resource class. The specification says (on page 3, section 1.5):

"Root resource class A resource class annotated with @Path. Root resource classes provide the roots of the resource class tree and provide access to sub-resources"

The more general definition of resource is for identifying the return value of a resource method as a sub-resource, but only root resources are identified for the purposes for URL resolution.

Comment by MarcinS [ 18/Jul/11 ]

Indeed, it seems Jersey is working fine for identifying resources.

My confusion is a result of the fact, that the Maven WADL generation plugin (maven-wadl-plugin) from Jersey-contribs is using the ScanningResourceConfig (PackagesResourceConfig) for listing WADL resources and when run on a project with JAX-RS annotated interfaces, works fine and lists the interfaces as valid resources.

Comment by Jakub Podlesak [ 25/Jul/11 ]

The only JAX-RS mean of configuring a JAX-RS application is stated in section 2.1:

-8<-
The resources and providers that make up a JAX-RS application are configured via an application-supplied
subclass of Application. An implementation MAY provide alternate mechanisms for locating resource
classes and providers (e.g. runtime class scanning) but use of Application is the only portable means of
configuration.
->8-

Any other mean of locating (scanning) resource/provider classes is out of scope of JAX-RS specification.
Then anything Jersey provides out of JAX-RS scope can not be tested in terms of specification compliance.
Closing the bug as invalid.

If you face issues with the Jersey scanning mechanism, please feel free to file a new bug/enhancement request against this particular feature in Jersey.





[JERSEY-735] Client Respond not handling multivalued headers correctly Created: 30/Jun/11  Updated: 08/Aug/13  Resolved: 13/Jul/11

Status: Resolved
Project: jersey
Component/s: core
Affects Version/s: 1.8
Fix Version/s: 1.17

Type: Bug Priority: Major
Reporter: mkwhitacre Assignee: Pavel Bucek
Resolution: Works as designed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

When making a request for a resource, I noticed the behavior between the 1.2 and 1.8 versions of the jersey-client in how it handles multi valued http headers. Specifically the service I am calling returns the following:

X-Privileges: READ, WRITE, READ_ACCESS_CONTROL

The code calls I'm doing looks like the following:

WebResource.Builder resourceBuilder = resource.path(path).accept(acceptTypes);
ClientResponse response = resourceBuilder.head();
int status = response.getStatus();
if (status == Status.OK.getStatusCode() || status == Status.NO_CONTENT.getStatusCode()

status == Status.FORBIDDEN.getStatusCode()) {
MultivaluedMap<String, String> headers = response.getHeaders();
List<String> privileges = headers.get(PRIVILEGES);
Set<Privilege> privs = new HashSet<Privilege>();
if (privileges != null)
Unknown macro: { for (String string }

In the 1.2 client the "privileges" member would be populated with a List<String> with three elements in the list. However after upgrading to the 1.8 client I'm getting a List<String> with only one element equal to "[READ, WRITE, READ_ACCESS_CONTROL]". Was this change in behavior intentional or a regression?



 Comments   
Comment by mkwhitacre [ 30/Jun/11 ]

Correction the return value is simply a single string without the [ ] characters.

Comment by Pavel Bucek [ 13/Jul/11 ]

workaround (if you have control over server side code):

put your headers in returning message separately:

X-Privileges: READ
X-Privileges: WRITE
X-Privileges: READ_ACCESS_CONTROL

if you do this, headers.get("X-Privileges") returns correct List<String> (3 elements).

Comment by Pavel Bucek [ 13/Jul/11 ]

btw are you sure that you've changed only jersey version in your environment? I tracked down headers creation and looks like jersey is just providing what HttpURLConnection (JDK class) returns, I can't see any other additional parsing anywhere..

Comment by reschke [ 13/Jul/11 ]

How is the client supposed to know that "," is a delimiter? Or is X-Privileges somehow special for Jersey?

Comment by Pavel Bucek [ 13/Jul/11 ]

reschke: no, it is not.

I would say that mkwhitacre might be referring to http://www.w3.org/Protocols/rfc2616/rfc2616-sec4.html, section "4.2 Message Headers"

And.. I just verified that this is NOT a regression, jersey-client 1.2 behaves exactly as 1.8 and 1.9-SNAPSHOT.

Comment by reschke [ 13/Jul/11 ]

Ack.

Clarifying: there is no generic way to parse an HTTP header field; (almost) each comes with it's own parsing rules.

It would be cool to have parsers for things that are notoriously hard to get right, such as Content-Type, WWW-Authenticate, Content-Disposition, etc.

Comment by Pavel Bucek [ 13/Jul/11 ]

we do provide some utility methods in ClientResponse class, see http://jersey.java.net/nonav/apidocs/latest/jersey/com/sun/jersey/api/client/ClientResponse.html

for example Content-Type is covered (by MediaType.valueOf(<string representation>).

Comment by Pavel Bucek [ 13/Jul/11 ]

Closing as "works as designed".

As user reschke correctly pointed out, there might be infinit number of parsing schemes and we can't do much about user defined ones ("X-Privileges" is not part of HTTP 1.1 spec, see http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html). We might add some utility methods/class which will help with parsing most commonly used schemes, feel free to file new enhancement issue if you want.

To sum up ClientResponse.getHeaders() functionality: it returns List<String> and each element corresponds to one declaration in actual headers, no additional parsing is being done. (And no changes were made in this area for cca 2 years, so in reporters case it is most likely related to server side changes).

Comment by reschke [ 13/Jul/11 ]

BTW, I'm collecting test cases over here:

Content-Disposition: http://greenbytes.de/tech/tc2231/
Content-Type: http://greenbytes.de/tech/tc/httpcontenttype/
Link: http://greenbytes.de/tech/tc/httplink
WWW-Authenticate: http://greenbytes.de/tech/tc/httpauth





[JERSEY-734] when providing a custom OAuthProvider, the DefaultOAuthProvider still gets preference Created: 21/Jun/11  Updated: 08/Aug/13  Resolved: 23/Jun/11

Status: Resolved
Project: jersey
Component/s: security
Affects Version/s: 1.8
Fix Version/s: 1.17

Type: Bug Priority: Major
Reporter: Joeri Sykora Assignee: Martin Matula
Resolution: Works as designed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

A custom OAuthProvider has to be annotated with @Provider to be picked up by the jersey oauth-server framework. However, this framework also provides a default OAuthProvider (com.sun.jersey.oauth.server.api.providers.DefaultOAuthProvider) which also gets injected. When more than one OAuthProvider are detected, the first one that was detected will be assigned to the OAuthServerFilter. So, in some cases the custom provider gets assigned and in other cases it uses the default provider.

This can be fixed by also creating a custom OAuthServerFilter and use your custom provider there.



 Comments   
Comment by Joeri Sykora [ 21/Jun/11 ]

Having a custom server filter is not enough as a workaround, because the RequestTokenRequest and AccessTokenRequest classes also use DefaultOAuthProvider.

Comment by Martin Matula [ 23/Jun/11 ]

The thing is, you should never register both providers (I believe it logs a warning when 2 OAuth providers are present). Simply not include the default OAuthProvider in your ResourceConfig - e.g. if you are using package scanning, don't add com.sun.jersey.oauth.server.api.providers to the list of packages to be scanned - add only com.sun.jersey.oauth.server.api.resources.





[JERSEY-732] Projects using Jersey Created: 14/Jun/11  Updated: 08/Aug/13  Resolved: 15/Jun/11

Status: Resolved
Project: jersey
Component/s: website
Affects Version/s: None
Fix Version/s: 1.17

Type: Task Priority: Minor
Reporter: mkarg Assignee: Pavel Bucek
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Regarding the list of projects using Jersey I want to propose two changes:

  • The list should be named "Projects and Products" as it contains not only projects but also products.
  • The list contains "QUIPSY(R) RB" already, but should be appended by "QUIPSY(R) CPL" as we are happy to announce the immediate availability of this new commercial product. The CPL module enriches the existing QUIPSY(R) suite with the ability to deal with so-called "Product Quality Control Plans", a means utilized by (mostly) manufacturers to control overall product quality on a high level throughout the complete production process. The product's client and server are based on Jersey as their internal and external interface is RESTful (WebDAV based, including a WebDAV SEARCH (DASL)).


 Comments   
Comment by Pavel Bucek [ 15/Jun/11 ]

Hello Markus,

a) ok, why not.

b) do you have better link for this product (than http://quipsy.de)?

Comment by mkarg [ 15/Jun/11 ]

Pavel,

regarding the links, "http://www.quipsy.de" is just pointing to the company's front page. An alternative one pointing to the English front page would be "http://www.quipsy.de/en.html".

Here are the links for the two products using Jersey internally:

QUIPSY(R) RB – http://www.quipsy.de/en/caq-software/products/failure-management/quipsy-rb.html

QUIPSY(R) CPL – http://www.quipsy.de/en/caq-software/products/advanced-quality-planning/quipsy-cpl.html

Regards
Markus

Comment by Pavel Bucek [ 15/Jun/11 ]

fixed





[JERSEY-730] java.lang.IllegalStateException: Invalid use of SingleClientConnManager: connection still allocated -- ClientResponse never requested. Created: 10/Jun/11  Updated: 08/Aug/13  Resolved: 14/Jun/11

Status: Resolved
Project: jersey
Component/s: core
Affects Version/s: 1.7
Fix Version/s: 1.17

Type: Bug Priority: Major
Reporter: Artem Shnayder Assignee: Pavel Bucek
Resolution: Works as designed Votes: 0
Labels: None
Remaining Estimate: 4 hours
Time Spent: Not Specified
Original Estimate: 4 hours
Environment:

<dependency org="com.sun.jersey" name="jersey-client" rev="1.8-ea02" transitive="false"/>
<dependency org="com.sun.jersey" name="jersey-core" rev="1.8-ea02" transitive="false"/>
<dependency org="com.sun.jersey.contribs" name="jersey-apache-client4" rev="1.8-ea02" transitive="false"/>



 Description   

I'm receiving the following error:

Caused by: com.sun.jersey.api.client.ClientHandlerException: java.lang.IllegalStateException: Invalid use of SingleClientConnManager: connection still allocated.
Make sure to release the connection before allocating another one.
	at com.sun.jersey.client.apache4.ApacheHttpClient4Handler.handle(ApacheHttpClient4Handler.java:187)
	at com.sun.jersey.api.client.Client.handle(Client.java:648)
	at com.sun.jersey.api.client.WebResource.handle(WebResource.java:670)
	at com.sun.jersey.api.client.WebResource.get(WebResource.java:191)

The ApacheHttpClient4 documentation states

If a ClientResponse is obtained and an entity is not read from the response then ClientResponse.close() MUST be called after processing the response to release connection-based resources.

However, I never obtain a ClientResponse.

One point to note is that a single WebResource is used by multiple threads. Could that be the problem?



 Comments   
Comment by Artem Shnayder [ 10/Jun/11 ]

My code worked fine prior to switching to jersey-apache-client4. I never obtain a ClientResponse – instead I usually get a String from the WebResource.

Comment by Pavel Bucek [ 10/Jun/11 ]

can you please try ThreadSafeClientConnManager?

see http://hc.apache.org/httpcomponents-client-ga/httpclient/apidocs/org/apache/http/impl/conn/tsccm/ThreadSafeClientConnManager.html
and http://jersey.java.net/nonav/apidocs/latest/contribs/jersey-apache-client4/com/sun/jersey/client/apache4/config/ApacheHttpClient4Config.html#PROPERTY_CONNECTION_MANAGER

Comment by Pavel Bucek [ 10/Jun/11 ]

if you want to know more about this, see http://hc.apache.org/httpcomponents-client-ga/tutorial/html/connmgmt.html, especially chapter 2.8.3 and 2.9.

SingleConnectionManager is apaches default, but when I;m thinking about it.. we maybe could use something more robust, like mentioned TheadSafeClientConnManager.. well, let's see how it works for you..

Comment by Artem Shnayder [ 10/Jun/11 ]

Thank you, that was the problem. After using ThredSafeClientConnManager it seems fixed now.

Comment by Pavel Bucek [ 14/Jun/11 ]

Great, closing. I'll update javadoc to be more helpful when dealing with that and maybe consider making ThreadSafeConnManager default connection manager.

Thanks!





[JERSEY-727] NullPointerException during WADL generation Created: 01/Jun/11  Updated: 08/Aug/13  Resolved: 08/Feb/12

Status: Resolved
Project: jersey
Component/s: None
Affects Version/s: 1.7
Fix Version/s: 1.17

Type: Bug Priority: Minor
Reporter: jotel71 Assignee: Pavel Bucek
Resolution: Cannot Reproduce Votes: 2
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

It looks like that if you have resourcedoc.xml which does not covers all end points then WadlGeneratorResourceDocSupport throws a null pointer exceptions. This bug is very related to JERSEY-721 and the fix actually solved this NPE partially.

Here is a stack trace:

java.lang.NullPointerException
at com.sun.jersey.server.wadl.generators.resourcedoc.WadlGeneratorResourceDocSupport.createParam(WadlGeneratorResourceDocSupport.java:323)
at com.sun.jersey.server.wadl.generators.resourcedoc.WadlGeneratorResourceDocSupport.createParam(WadlGeneratorResourceDocSupport.java:322)
at com.sun.jersey.server.wadl.WadlBuilder.generateParam(WadlBuilder.java:264)
at com.sun.jersey.server.wadl.WadlBuilder.generateResource(WadlBuilder.java:298)
at com.sun.jersey.server.wadl.WadlBuilder.generateResource(WadlBuilder.java:269)
at com.sun.jersey.server.wadl.WadlBuilder.generate(WadlBuilder.java:105)
at com.sun.jersey.wadl.GenerateWadlMojo.createApplication(GenerateWadlMojo.java:285)
at com.sun.jersey.wadl.GenerateWadlMojo.executeWithClasspath(GenerateWadlMojo.java:146)
at com.sun.jersey.wadl.AbstractMojoProjectClasspathSupport.execute(AbstractMojoProjectClasspathSupport.java:101)
at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
at org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:319)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:141)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409)
at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352)



 Comments   
Comment by Pavel Bucek [ 15/Jun/11 ]

what exactly do you mean by "the fix actually solved this NPE partially."? Can you share simple testcase which will end throwing this exception?

Or do you know what variable is null in this case?

Thanks,
Pavel

Comment by jotel71 [ 15/Jun/11 ]

What I meant is that the fix for JERSEY-721 just solved the case described in there. But in my testing when you have a couple of maven modules in which REST resources are defined and then trying to combine them to one REST application and building WADL using maven-wadl-plugin and using WadlGeneratorResourceDocSupport pointing to resourcedoc.xml from each module. In this case in class loading scope there are all classes defining REST application but every resourcedoc.xml has only subset of it. AFAIR the the null value was either in 'm' or 'r' variable.

Comment by Pavel Bucek [ 12/Oct/11 ]

downgrading priority

it would help if you could provide testcase - I wasn't able to reproduce it yet.

Comment by Pavel Bucek [ 08/Feb/12 ]

closing as cannot reproduce - most likely this was fixed by some other fix in this area.

Feel free to reopen with a testcase.





[JERSEY-725] Run out of sockets on AIX Created: 27/May/11  Updated: 08/Aug/13  Resolved: 20/Jun/11

Status: Resolved
Project: jersey
Component/s: core
Affects Version/s: 1.5
Fix Version/s: 1.17

Type: Bug Priority: Major
Reporter: sirajg Assignee: Pavel Bucek
Resolution: Invalid Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

AIX, GlassFish


Issue Links:
Dependency
blocks GLASSFISH-16672 [BLOCKING] AIX: Too many open files e... Closed

 Description   

Refer to issue : http://java.net/jira/browse/GLASSFISH-16672

The GlassFish admin console gets a new WebResource on every request. This appears to create a new HttpURLConnection every time. On AIX the connection does not get closed properly, eventually resulting in system failure, as it runs of sockets. The problem is not observed on platforms other than AIX. Refer to the details in the above mentioned bug.

Also, does the WebResource create a new HttpURLConnection object every time? If so it might be better to use a pool.



 Comments   
Comment by Pavel Bucek [ 30/May/11 ]

JDK usually has some threadpool for HttpURLConnection, see javadoc (it says HttpURLConnections instances may share underlying connections to one host. Additinally it says calling close() might free some network resources but does not affect underlying connection. and for disconnect() it says that requests to same host are not loikely in near future). So we are calling close on streams obtained from HttpURLConnection instance but not disconnect - and I don't think we should do that.

I'm not sure what could we do to solve this issue (and original issue seems to be almost resolved without any fix from our side). Looks like AIX JDK implementation bug and the fact that it is observable only on that platform supports it..

Comment by sirajg [ 31/May/11 ]

The original issue has not been resolved. Is it possible to interact with Jersey in a different way, compared to the way it is being done now?

Comment by Pavel Bucek [ 31/May/11 ]

I don't really know how is "it" done now, but this issue is about limitation (wrong implementation) of HttpURLConnection on AIX platform, not jersey-client. Only solution which I see now is get rid of it and use jersey-client implemented on top of apache http client, but I'm not sure if that is acceptable option here.

Other option could be creating "special" implementation of jersey-client for that platform, which will be calling HttpURLConnection.disconnect() after each request. It will most likely result in performance loss, but connection should be closed after each request so it might be at least a workaround.

I don't know about any other alternative present in JDK which we could use instead of HttpURLConnection. There is some initiative in grizzly - grizzly-client, which would be a solution (it will be part of grizzly 2.0) but it is not ready yet and as far as I know grizzly 2.x won't be integrated into glassfish 3.1.1 branch.

To sum that up.. we have these options:

1) calling HttpURLConnection.disconnect() after each request

  • not sure if that resolves original issue
  • performance loss
  • needs to be implemented + tested (~2 days) + tested on AIX

2) getting rid of HttpURLConnection

  • not sure if that resolves original issue
  • ready to use in case of apache http client, can be replaced by jersey-client based on grizzly when ready
Comment by sirajg [ 01/Jun/11 ]

Can we try out option 1? Admin console team can test to see if it resolves the issue.

Comment by Pavel Bucek [ 01/Jun/11 ]

Sure.. it was actually pretty easy to fix - I have it already.

Now how you can test it..

svn co https://svn.java.net/svn/jersey~svn/branches/jersey-client-aix
cd jersey-client-aix/jersey
mvn clean install -Dmaven.test.skip=true

cd ../..
svn co https://svn.java.net/svn/glassfish~svn/branches/3.1.1
cd 3.1.1

change pom.xml:
$ svn diff ./pom.xml
Index: pom.xml
===================================================================
— pom.xml (revision 47251)
+++ pom.xml (working copy)
@@ -147,7 +147,7 @@
<javadb.version>10.6.2.1</javadb.version>
<jaxr.version>JAXR_RA_20091012</jaxr.version>
<weld.version>1.1.1.Final</weld.version>

  • <jersey.version>1.5</jersey.version>
    + <jersey.version>1.8-SNAPSHOT</jersey.version>
    <jbi.version>1.0</jbi.version>
    <wsdl4j.version>1.6.2</wsdl4j.version>
    <gmbal.version>3.1.0-b001</gmbal.version>

build glassfish, grab ./distributions/glassfish/target/glassfish.zip, test on AIX and let me know whether something changed/improved.

note: this is just for testing purposes, we will need to figure out how create AIX specific bundle (I don't want to have this workaround in jersey trunk).

Comment by sirajg [ 01/Jun/11 ]

Did this :
svn co https://svn.java.net/svn/jersey~svn/branches/jersey-client-aix
cd jersey-client-aix/jersey
mvn clean install -Dmaven.test.skip=true

Got the following error :

Missing:
----------
1) javax.transaction:jta:jar:1.0.1B

Try downloading the file manually from the project website.

Then, install it using the command:
mvn install:install-file -DgroupId=javax.transaction -DartifactId=jta -Dversion=1.0.1B -Dpackaging=jar -Dfile=/path/to/file

Alternatively, if you host your own repository you can deploy the file there:
mvn deploy:deploy-file -DgroupId=javax.transaction -DartifactId=jta -Dversion=1.0.1B -Dpackaging=jar -Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id]

Path to dependency:
1) com.sun.jersey.contribs.bill-burke-book:ex11_2:war:1.8-SNAPSHOT
2) javax.transaction:jta:jar:1.0.1B

----------
1 required artifact is missing.

for artifact:
com.sun.jersey.contribs.bill-burke-book:ex11_2:war:1.8-SNAPSHOT

Comment by Pavel Bucek [ 02/Jun/11 ]

which maven version are you using? You need at least 2.2.1, 3.x is better (but glassfish is not yet compatible with 3.x)

I'll try with clean local maven repo and let you know how it went.

Comment by Pavel Bucek [ 02/Jun/11 ]

I've just confirmed that project is buildable with clean maven local repo and maven 3.x

Previous instructions are still valid, but please use maven 3.x for building jersey (and you might need set MAVEN_OPTS:
export MAVEN_OPTS="-Xms512m -Xmx1024m -XX:PermSize=256m -XX:MaxPermSize=512m"
)

and maven 2.2.1 for building glassfish.

Sorry for not including this information earlier.

Comment by sirajg [ 03/Jun/11 ]

This doesn't solve the issue. netstat -a | grep appserv reports a number of connections in CLOSE_WAIT state after a few operations on the console.

Comment by sirajg [ 09/Jun/11 ]

Ran the following test on AIX :

for (int i = 0; i < 100; i++)

{ URL y = new URL("http://<someurl...>"); HttpURLConnection yc = (HttpURLConnection)y.openConnection(); BufferedReader in = new BufferedReader( new InputStreamReader( yc.getInputStream())); String inputLine; while ((inputLine = in.readLine()) != null) System.out.println(inputLine); in.close(); }

}

The number of connections in WAIT state did not change after running the above. To find the number of connections in *WAIT state, I executed the following :
netstat -a | grep WAIT | wc

Comment by sirajg [ 09/Jun/11 ]

Pavel, can you run a simple jersey test on AIX that opens connections a number of times. This will help us isolate the problem. I do not have the right build environment to easily run such a jersey test.

Comment by Pavel Bucek [ 10/Jun/11 ]

same testcase, just implemented using jersey-client:

public static void main (String args[]) {
Client c = Client.create();
WebResource r = c.resource(URL);

for(int i = 0; i < 100; i++)

{ System.out.println( r.get(String.class) ); }

}

left zero CLOSE_WAIT / FIN_WAIT connections as well.

Comment by Pavel Bucek [ 10/Jun/11 ]

btw, you should check for CLOSE_WAIT or FIN_WAIT_2

and use -n switch (netstat won't try resolve domain names for reported connections)

Comment by Pavel Bucek [ 10/Jun/11 ]

summing up my findings..

still can't reproduce with "standalone" testcase, tried mentioned sample, even when only http status is read, connections are closed properly.

Created client/server scenario testcase using grizzly 1.9.35 (same version is used in 3.1.1) and no connections were left after test ended (actually not even during that test). Note I'm using standard jersey-client, not patched one.

mentioned testcases are available on makati box in /makati1/java_re/pavel_bucek/test[1|2|3].

Comment by Pavel Bucek [ 15/Jun/11 ]

Siraj, do you have any update? Or at least some new indication which would indicate the bug is in jersey workspace?

Comment by Pavel Bucek [ 20/Jun/11 ]

closing as invalid. Evaluation and test scenarios imply that this behavior is not caused by jersey-client or jersey-server/core.





[JERSEY-687] GrizzlyWebTestContainer accepts all requests unless servletPath() is specified Created: 20/Mar/11  Updated: 08/Aug/13  Resolved: 08/Aug/13

Status: Resolved
Project: jersey
Component/s: test-framework
Affects Version/s: 1.5
Fix Version/s: 1.17

Type: Bug Priority: Major
Reporter: cowwoc Assignee: Michal Gajdos
Resolution: Cannot Reproduce Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

If the user does not specify WebAppDescriptor.Builder.servletPath(), the web container will return HTTP 200 for all requests.

Expected behavior: Throw an exception if servletPath() is missing, or specify what the default servletPath() is, or return HTTP 404 for all requests because no webapp was mounted. Either way, the behavior should be documented.



 Comments   
Comment by jbenoit [ 20/Jul/11 ]

fix below will be committed to trunk, pending code review. set servletPath param default value to "test" in WebAppDescriptor's Builder, so that if the user does not specify WebAppDescriptor.Builder.servletPath(), the web container will not return HTTP 200 for all requests like it currently does.

%pwd
jersey\jersey-test-framework\jersey-test-framework-core\src\main\java\com\sun\jersey\test\framework
%svn diff .
Index: WebAppDescriptor.java
===================================================================
— WebAppDescriptor.java (revision 5197)
+++ WebAppDescriptor.java (working copy)
@@ -114,7 +114,7 @@

protected String contextPath = "";

  • protected String servletPath = "";
    + protected String servletPath = "test";

/**

  • Create a builder.
    @@ -126,7 +126,7 @@
    /**
  • Create a builder with initialization parameters.
    *
  • * @param initParams a map of intialization parameters. The parameters
    + * @param initParams a map of initialization parameters. The parameters
  • will be copied.
  • @throws IllegalArgumentException if <code>initParams</code> is null.

*/
@@ -473,7 +473,7 @@
this.filters = null;
this.listeners = null;
this.contextPath = "";

  • this.servletPath = "";
    + this.servletPath = "test";
    }
    }

I had implemented fix to GrizzlyWebTestContainer to throw exception if servletPath() is missing, & changed corresponding test to set servletPath, but better we specify the default servletPath value instead, as it could simplify test configuration and is a convenience for users.

We should not return 404 for each request, as it's confusing - we need to let user know what is wrong, not just return 404 for each request.

Comment by cowwoc [ 20/Jul/11 ]

-1 for changing the default context path to /test. If anything it should be /.

I also think you're missing the point of my complaint: the default response for hitting non-existent paths should be 404, not 200. Even if /test is mounted, if I hit /test/nonExistentResource and no resource is mounted at that path I should get 404 but currently I am getting 200.

Comment by jbenoit [ 22/Jul/11 ]

I can't get a non-existent path to return 200, it returns 404 as expected. Do you have small test case that you could provide that produces this behavior. I've tried tweaking our samples to ensure not setting servletPath and then access non-existent path, but it doesn't return 200, but 404.

Comment by Michal Gajdos [ 05/Mar/12 ]

Can you, please, provide an example to this issue? I was following your description but I was not able to get the HTTP 200 response for any other request that was defined by my application.

Comment by cowwoc [ 05/Mar/12 ]

Michal,

I'm no longer working on this code and unfortunately I don't have time to look at it in the near future either. Let's close this issue as CAN'T REPRODUCE for now and if I run into it again we'll reopen.

Comment by Michal Gajdos [ 05/Mar/12 ]

OK, feel free to reopen.





[JERSEY-685] Clarify WebResource.type() vs WebResource.accept() Created: 20/Mar/11  Updated: 08/Aug/13  Resolved: 22/Feb/13

Status: Resolved
Project: jersey
Component/s: core
Affects Version/s: 1.5
Fix Version/s: 1.17

Type: Improvement Priority: Major
Reporter: cowwoc Assignee: Marek Potociar
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

It's not clear what the difference is between the type() and accept() method.

type() "sets the media type"
accept() "adds an acceptable media type"

In both cases, the method talks about media types but doesn't actually explain what the method does and what the media type is used for.



 Comments   
Comment by Marek Potociar [ 22/Feb/13 ]

Acceptable media type is set to Accept header via accept() method. OTOH type() sets the Content-type header. Since Jersey 2.x bring s a new JAX-RS 2.0 client API, we have no plans on making such minor changes in the old Jersey 1.x client code.





[JERSEY-677] OSGi Manifest imports incomplete in jersey-spring Created: 15/Mar/11  Updated: 08/Aug/13  Resolved: 18/Jul/12

Status: Resolved
Project: jersey
Component/s: extensions
Affects Version/s: 1.5, 1.6
Fix Version/s: 1.17

Type: Bug Priority: Major
Reporter: dd-xx1 Assignee: Jakub Podlesak
Resolution: Fixed Votes: 2
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Text File JERSEY-677.patch    

 Description   

I'm using the jersey-spring integration in an OSGi environment (Virgo 2.1.0) and there is a problem with the imports it declares in its MANIFEST.MF file.

Resources are discovered correctly within the spring context but whenever I try to access a resource, I get a ClassNotFoundException for javax.ws.rs.core.Context (full stack trace below).

I tried different things and finally found that by adding the following Import-Package entries to the MANIFEST.MF file (within the jar) solves everything.

  • javax.ws.rs
  • javax.ws.rs.core
  • javax.ws.rs.ext

I don't know how the MANIFEST.MF file is generated at build time but there is probably an issue in detecting dependencies that are annotations so those import should be explicitly added to whatever descriptor serves as a base to the manifest.

Stack trace:

java.lang.ClassNotFoundException: javax.ws.rs.core.Context
org.eclipse.osgi.internal.loader.BundleLoader.findClassInternal(BundleLoader.java:506)
org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:422)
org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:410)
org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.loadClass(DefaultClassLoader.java:107)
org.eclipse.virgo.kernel.userregion.internal.equinox.KernelBundleClassLoader.loadClass(KernelBundleClassLoader.java:135)
java.lang.ClassLoader.loadClass(ClassLoader.java:248)
java.lang.Class.forName0(Native Method)
java.lang.Class.forName(Class.java:247)
sun.reflect.generics.factory.CoreReflectionFactory.makeNamedType(CoreReflectionFactory.java:95)
sun.reflect.generics.visitor.Reifier.visitClassTypeSignature(Reifier.java:107)
sun.reflect.generics.tree.ClassTypeSignature.accept(ClassTypeSignature.java:31)
sun.reflect.generics.visitor.Reifier.reifyTypeArguments(Reifier.java:50)
sun.reflect.generics.visitor.Reifier.visitClassTypeSignature(Reifier.java:120)
sun.reflect.generics.tree.ClassTypeSignature.accept(ClassTypeSignature.java:31)
sun.reflect.generics.repository.ClassRepository.getSuperclass(ClassRepository.java:66)
java.lang.Class.getGenericSuperclass(Class.java:677)
com.sun.jersey.core.reflection.ReflectionHelper.resolveTypeVariable(ReflectionHelper.java:620)
com.sun.jersey.core.reflection.ReflectionHelper.resolveTypeVariable(ReflectionHelper.java:604)
com.sun.jersey.core.spi.factory.InjectableProviderFactory.getResolvedType(InjectableProviderFactory.java:160)
com.sun.jersey.core.spi.factory.InjectableProviderFactory.getMetaArguments(InjectableProviderFactory.java:142)
com.sun.jersey.core.spi.factory.InjectableProviderFactory.add(InjectableProviderFactory.java:93)
com.sun.jersey.core.spi.factory.InjectableProviderFactory$1.onAdd(InjectableProviderFactory.java:109)
com.sun.jersey.core.spi.factory.InjectableProviderFactory$1.onAdd(InjectableProviderFactory.java:107)
com.sun.jersey.core.spi.component.ProviderServices.getProvidersAndServices(ProviderServices.java:201)
com.sun.jersey.core.spi.factory.InjectableProviderFactory.configure(InjectableProviderFactory.java:106)
com.sun.jersey.server.impl.application.WebApplicationImpl._initiate(WebApplicationImpl.java:1017)
com.sun.jersey.server.impl.application.WebApplicationImpl.access$600(WebApplicationImpl.java:159)
com.sun.jersey.server.impl.application.WebApplicationImpl$12.f(WebApplicationImpl.java:693)
com.sun.jersey.server.impl.application.WebApplicationImpl$12.f(WebApplicationImpl.java:690)
com.sun.jersey.spi.inject.Errors.processWithErrors(Errors.java:193)
com.sun.jersey.server.impl.application.WebApplicationImpl.initiate(WebApplicationImpl.java:690)
com.sun.jersey.spi.spring.container.servlet.SpringServlet.initiate(SpringServlet.java:117)
com.sun.jersey.spi.container.servlet.ServletContainer$InternalWebComponent.initiate(ServletContainer.java:318)
com.sun.jersey.spi.container.servlet.WebComponent.load(WebComponent.java:601)
com.sun.jersey.spi.container.servlet.WebComponent.init(WebComponent.java:208)
com.sun.jersey.spi.container.servlet.ServletContainer.init(ServletContainer.java:373)
com.sun.jersey.spi.container.servlet.ServletContainer.init(ServletContainer.java:556)
javax.servlet.GenericServlet.init(GenericServlet.java:212)
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
org.eclipse.virgo.web.tomcat.ApplicationNameTrackingValve.invoke(ApplicationNameTrackingValve.java:29)
org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:555)
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:298)
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:857)
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:588)
org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:489)
java.lang.Thread.run(Thread.java:662)



 Comments   
Comment by dd-xx1 [ 11/Oct/11 ]

Since I haven't heard back from anyone about this, I'd like to propose a fix (patch included).

You only need to add a simple configuration item to the maven-bundle-plugin:

<plugin>
    <groupId>org.apache.felix</groupId>
    <artifactId>maven-bundle-plugin</artifactId>
    <configuration>
        <instructions>
            <Import-Package>*,javax.ws.rs,javax.ws.rs.core,javax.ws.rs.ext</Import-Package>
        </instructions>
    </configuration>
</plugin>
Comment by n0rad [ 11/Oct/11 ]

I have the same problem and patch it the same way as dd-xx1 did. Please include this patch, this bug is easy to fix and is open for a long time.

Comment by Jakub Podlesak [ 15/Mar/12 ]

I believe only javax.ws.rs.core is needed, namely in the SpringComponentProviderFactory class.
Could you please confirm the other javax.ws.rs.* packages are indeed required?

Comment by peter.garfjall [ 19/Jun/12 ]

Judging by the contents of the spring-jersey classes, only javax.ws.rs.core seems to be required.
However, given that all packages are part of the public API in JSR311, it seems safe to include them all.
But strictly speaking, it looks like only javax.ws.rs.core is needed.

Comment by urtzurd [ 20/Jun/12 ]

Hi,

We are also experiencing this issue and had to create a bundle fragment with the three packages to have it working in the Virgo container:

Fragment-Host: com.sun.jersey.contribs.jersey-spring
Import-Package: javax.ws.rs, javax.ws.rs.core, javax.ws.rs.ext

Comment by dd-xx1 [ 16/Jul/12 ]

Hi,

I have tested in my project with just "javax.ws.rs.core" and it worked fine.

It concerns me a little that this bug is still opened after 16 months given that the fix is so easy. Any chance we'll see it fixed in the next version?

Thanks!

Comment by Jakub Podlesak [ 18/Jul/12 ]

Fixed in the main trunk.





[JERSEY-676] improve providers registration configuration Created: 14/Mar/11  Updated: 08/Aug/13  Resolved: 20/Mar/13

Status: Resolved
Project: jersey
Component/s: core
Affects Version/s: 1.5
Fix Version/s: 1.17

Type: Improvement Priority: Major
Reporter: Pavel Bucek Assignee: Jakub Podlesak
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Current approach (META-INF/services and ServiceFinder discovery) is insufficient, users CAN'T specify which providers (i.e. MessageBodyReaders/Writers) should be ignored. This might cause complications when someone does not have direct control of classpath, etc. This might be solved by black/white lists or another explicit configuration option in runtime or deployment time (to be specified).

Comments/suggestions are welcomed.



 Comments   
Comment by Jakub Podlesak [ 20/Mar/13 ]

This is already addressed in Jersey 2, where provider registration could be done programatically.





[JERSEY-674] Extended WADL error after upgrading to 1.5 Created: 11/Mar/11  Updated: 08/Aug/13  Resolved: 21/Apr/11

Status: Resolved
Project: jersey
Component/s: None
Affects Version/s: 1.5
Fix Version/s: 1.17

Type: Bug Priority: Major
Reporter: danielrolson Assignee: Pavel Bucek
Resolution: Cannot Reproduce Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Eclipse project under 64 bit Windows 7


Attachments: Zip Archive jersey-674.zip     Zip Archive JerseyBug.zip     Zip Archive missing-files.ZIP     XML File resource-doc.xml    

 Description   

My project has been working with an extended WADL implementation. Today I upgraded to Jersey 1.5 and am receiving the following exception when requesting application.wadl. The WadlGeneratorConfig matches the samples (remember it worked before the upgrade).

Please help! I've attached a reproducible sample.

HTTP ERROR 503 when requesting: http://localhost:9999/application.wadl

Problem accessing /application.wadl. Reason:

java.lang.RuntimeException: Could not load WadlGeneratorConfiguration, check the configuration of com.sun.jersey.config.property.WadlGeneratorConfig

Caused by:

javax.servlet.UnavailableException: java.lang.RuntimeException: Could not load WadlGeneratorConfiguration, check the configuration of com.sun.jersey.config.property.WadlGeneratorConfig
at org.eclipse.jetty.servlet.ServletHolder.makeUnavailable(ServletHolder.java:394)
at org.eclipse.jetty.servlet.ServletHolder.initServlet(ServletHolder.java:439)
at org.eclipse.jetty.servlet.ServletHolder.getServlet(ServletHolder.java:316)
at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:507)
at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:427)
at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:119)
at org.eclipse.jetty.server.session.SessionHandler.handle(SessionHandler.java:182)
at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:933)
at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:362)
at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:867)
at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:117)
at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:113)
at org.eclipse.jetty.server.Server.handle(Server.java:334)
at org.eclipse.jetty.server.HttpConnection.handleRequest(HttpConnection.java:559)
at org.eclipse.jetty.server.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:992)
at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:541)
at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:203)
at org.eclipse.jetty.server.HttpConnection.handle(HttpConnection.java:406)
at org.eclipse.jetty.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:462)
at org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(QueuedThreadPool.java:436)
at java.lang.Thread.run(Unknown Source)

The following appears in the console:
Mar 11, 2011 2:07:38 PM com.sun.jersey.api.wadl.config.WadlGeneratorLoader loadWadlGenerator
INFO: Loading wadlGenerator com.sun.jersey.server.wadl.generators.WadlGeneratorApplicationDoc
2011-03-11 14:07:38.197:WARN:/:unavailable
java.lang.RuntimeException: Could not load WadlGeneratorConfiguration, check the configuration of com.sun.jersey.config.property.WadlGeneratorConfig
at com.sun.jersey.api.wadl.config.WadlGeneratorConfigLoader.loadWadlGeneratorsFromConfig(WadlGeneratorConfigLoader.java:112)
at com.sun.jersey.server.impl.wadl.WadlFactory.<init>(WadlFactory.java:77)
at com.sun.jersey.server.impl.application.WebApplicationImpl._initiate(WebApplicationImpl.java:1135)
at com.sun.jersey.server.impl.application.WebApplicationImpl.access$600(WebApplicationImpl.java:159)
at com.sun.jersey.server.impl.application.WebApplicationImpl$12.f(WebApplicationImpl.java:700)
at com.sun.jersey.server.impl.application.WebApplicationImpl$12.f(WebApplicationImpl.java:697)
at com.sun.jersey.spi.inject.Errors.processWithErrors(Errors.java:193)
at com.sun.jersey.server.impl.application.WebApplicationImpl.initiate(WebApplicationImpl.java:697)
at com.sun.jersey.server.impl.application.WebApplicationImpl.initiate(WebApplicationImpl.java:692)
at com.sun.jersey.spi.container.servlet.ServletContainer.initiate(ServletContainer.java:488)
at com.sun.jersey.spi.container.servlet.ServletContainer$InternalWebComponent.initiate(ServletContainer.java:318)
at com.sun.jersey.spi.container.servlet.WebComponent.load(WebComponent.java:606)
at com.sun.jersey.spi.container.servlet.WebComponent.init(WebComponent.java:213)
at com.sun.jersey.spi.container.servlet.ServletContainer.init(ServletContainer.java:373)
at com.sun.jersey.spi.container.servlet.ServletContainer.init(ServletContainer.java:556)
at javax.servlet.GenericServlet.init(GenericServlet.java:241)
at org.eclipse.jetty.servlet.ServletHolder.initServlet(ServletHolder.java:421)
at org.eclipse.jetty.servlet.ServletHolder.getServlet(ServletHolder.java:316)
at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:507)
at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:427)
at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:119)
at org.eclipse.jetty.server.session.SessionHandler.handle(SessionHandler.java:182)
at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:933)
at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:362)
at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:867)
at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:117)
at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:113)
at org.eclipse.jetty.server.Server.handle(Server.java:334)
at org.eclipse.jetty.server.HttpConnection.handleRequest(HttpConnection.java:559)
at org.eclipse.jetty.server.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:992)
at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:541)
at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:203)
at org.eclipse.jetty.server.HttpConnection.handle(HttpConnection.java:406)
at org.eclipse.jetty.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:462)
at org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(QueuedThreadPool.java:436)
at java.lang.Thread.run(Unknown Source)
2011-03-11 14:07:38.204:WARN::/
java.lang.RuntimeException: Could not load WadlGeneratorConfiguration, check the configuration of com.sun.jersey.config.property.WadlGeneratorConfig
at com.sun.jersey.api.wadl.config.WadlGeneratorConfigLoader.loadWadlGeneratorsFromConfig(WadlGeneratorConfigLoader.java:112)
at com.sun.jersey.server.impl.wadl.WadlFactory.<init>(WadlFactory.java:77)
at com.sun.jersey.server.impl.application.WebApplicationImpl._initiate(WebApplicationImpl.java:1135)
at com.sun.jersey.server.impl.application.WebApplicationImpl.access$600(WebApplicationImpl.java:159)
at com.sun.jersey.server.impl.application.WebApplicationImpl$12.f(WebApplicationImpl.java:700)
at com.sun.jersey.server.impl.application.WebApplicationImpl$12.f(WebApplicationImpl.java:697)
at com.sun.jersey.spi.inject.Errors.processWithErrors(Errors.java:193)
at com.sun.jersey.server.impl.application.WebApplicationImpl.initiate(WebApplicationImpl.java:697)
at com.sun.jersey.server.impl.application.WebApplicationImpl.initiate(WebApplicationImpl.java:692)
at com.sun.jersey.spi.container.servlet.ServletContainer.initiate(ServletContainer.java:488)
at com.sun.jersey.spi.container.servlet.ServletContainer$InternalWebComponent.initiate(ServletContainer.java:318)
at com.sun.jersey.spi.container.servlet.WebComponent.load(WebComponent.java:606)
at com.sun.jersey.spi.container.servlet.WebComponent.init(WebComponent.java:213)
at com.sun.jersey.spi.container.servlet.ServletContainer.init(ServletContainer.java:373)
at com.sun.jersey.spi.container.servlet.ServletContainer.init(ServletContainer.java:556)
at javax.servlet.GenericServlet.init(GenericServlet.java:241)
at org.eclipse.jetty.servlet.ServletHolder.initServlet(ServletHolder.java:421)
at org.eclipse.jetty.servlet.ServletHolder.getServlet(ServletHolder.java:316)
at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:507)
at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:427)
at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:119)
at org.eclipse.jetty.server.session.SessionHandler.handle(SessionHandler.java:182)
at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:933)
at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:362)
at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:867)
at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:117)
at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:113)
at org.eclipse.jetty.server.Server.handle(Server.java:334)
at org.eclipse.jetty.server.HttpConnection.handleRequest(HttpConnection.java:559)
at org.eclipse.jetty.server.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:992)
at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:541)
at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:203)
at org.eclipse.jetty.server.HttpConnection.handle(HttpConnection.java:406)
at org.eclipse.jetty.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:462)
at org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(QueuedThreadPool.java:436)
at java.lang.Thread.run(Unknown Source)
Mar 11, 2011 2:07:38 PM sun.net.www.protocol.http.HttpURLConnection getInputStream
FINE: sun.net.www.MessageHeader@651e67c5 pairs:

{null: HTTP/1.1 500 Could not load WadlGeneratorConfiguration, check the configuration of com.sun.jersey.config.property.WadlGeneratorConfig} {Content-Type: text/html;charset=ISO-8859-1} {Cache-Control: must-revalidate,no-cache,no-store} {Content-Length: 13210} {Server: Jetty(7.0.2-SNAPSHOT)}

Exception in thread "main" com.sun.jersey.api.client.UniformInterfaceException: GET http://localhost:9999/ returned a response status of 500
at com.sun.jersey.api.client.WebResource.handle(WebResource.java:607)
at com.sun.jersey.api.client.WebResource.get(WebResource.java:187)
at JavaBug.Main.main(Main.java:50)



 Comments   
Comment by Jakub Podlesak [ 21/Mar/11 ]

The xml files are mising in the JerseyBug project. Getting the following exception.
Could you please provide the missing files?

Here is the list:
application-doc.xml
application-grammars.xml

-8<-
INFO: Initiating Jersey application, version 'Jersey: 1.5 01/14/2011 12:36 PM'
Mar 20, 2011 2:23:58 PM com.sun.jersey.api.wadl.config.WadlGeneratorLoader loadWadlGenerator
INFO: Loading wadlGenerator com.sun.jersey.server.wadl.generators.WadlGeneratorApplicationDoc
2011-03-20 14:23:58.029:WARN:/:unavailable
java.lang.RuntimeException: Could not load WadlGeneratorConfiguration, check the configuration of com.sun.jersey.config.property.WadlGeneratorConfig
at com.sun.jersey.api.wadl.config.WadlGeneratorConfigLoader.loadWadlGeneratorsFromConfig(WadlGeneratorConfigLoader.java:112)
at com.sun.jersey.server.impl.wadl.WadlFactory.<init>(WadlFactory.java:77)
at com.sun.jersey.server.impl.application.WebApplicationImpl._initiate(WebApplicationImpl.java:1135)
at com.sun.jersey.server.impl.application.WebApplicationImpl.access$600(WebApplicationImpl.java:159)
at com.sun.jersey.server.impl.application.WebApplicationImpl$12.f(WebApplicationImpl.java:700)
at com.sun.jersey.server.impl.application.WebApplicationImpl$12.f(WebApplicationImpl.java:697)
at com.sun.jersey.spi.inject.Errors.processWithErrors(Errors.java:193)
at com.sun.jersey.server.impl.application.WebApplicationImpl.initiate(WebApplicationImpl.java:697)
at com.sun.jersey.server.impl.application.WebApplicationImpl.initiate(WebApplicationImpl.java:692)
at com.sun.jersey.spi.container.servlet.ServletContainer.initiate(ServletContainer.java:488)
at com.sun.jersey.spi.container.servlet.ServletContainer$InternalWebComponent.initiate(ServletContainer.java:318)
at com.sun.jersey.spi.container.servlet.WebComponent.load(WebComponent.java:606)
at com.sun.jersey.spi.container.servlet.WebComponent.init(WebComponent.java:213)
at com.sun.jersey.spi.container.servlet.ServletContainer.init(ServletContainer.java:373)
at com.sun.jersey.spi.container.servlet.ServletContainer.init(ServletContainer.java:556)
at javax.servlet.GenericServlet.init(GenericServlet.java:241)
at org.eclipse.jetty.servlet.ServletHolder.initServlet(ServletHolder.java:432)
at org.eclipse.jetty.servlet.ServletHolder.getServlet(ServletHolder.java:331)
at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:511)
at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:476)
at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:224)
at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:934)
at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:404)
at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:184)
at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:869)
at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:117)
at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:116)
at org.eclipse.jetty.server.Server.handle(Server.java:346)
at org.eclipse.jetty.server.HttpConnection.handleRequest(HttpConnection.java:581)
at org.eclipse.jetty.server.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:1040)
at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:592)
at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:214)
at org.eclipse.jetty.server.HttpConnection.handle(HttpConnection.java:411)
at org.eclipse.jetty.io.nio.SelectChannelEndPoint.handle(SelectChannelEndPoint.java:526)
at org.eclipse.jetty.io.nio.SelectChannelEndPoint$1.run(SelectChannelEndPoint.java:41)
at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:528)
at java.lang.Thread.run(Thread.java:662)
Caused by:
java.lang.RuntimeException: Could not load wadl generators from wadlGeneratorDescriptions.
at com.sun.jersey.api.wadl.config.WadlGeneratorConfig.getWadlGenerator(WadlGeneratorConfig.java:191)
at com.sun.jersey.api.wadl.config.WadlGeneratorConfigLoader.loadWadlGeneratorsFromConfig(WadlGeneratorConfigLoader.java:109)
at com.sun.jersey.server.impl.wadl.WadlFactory.<init>(WadlFactory.java:77)
at com.sun.jersey.server.impl.application.WebApplicationImpl._initiate(WebApplicationImpl.java:1135)
at com.sun.jersey.server.impl.application.WebApplicationImpl.access$600(WebApplicationImpl.java:159)
at com.sun.jersey.server.impl.application.WebApplicationImpl$12.f(WebApplicationImpl.java:700)
at com.sun.jersey.server.impl.application.WebApplicationImpl$12.f(WebApplicationImpl.java:697)
at com.sun.jersey.spi.inject.Errors.processWithErrors(Errors.java:193)
at com.sun.jersey.server.impl.application.WebApplicationImpl.initiate(WebApplicationImpl.java:697)
at com.sun.jersey.server.impl.application.WebApplicationImpl.initiate(WebApplicationImpl.java:692)
at com.sun.jersey.spi.container.servlet.ServletContainer.initiate(ServletContainer.java:488)
at com.sun.jersey.spi.container.servlet.ServletContainer$InternalWebComponent.initiate(ServletContainer.java:318)
at com.sun.jersey.spi.container.servlet.WebComponent.load(WebComponent.java:606)
at com.sun.jersey.spi.container.servlet.WebComponent.init(WebComponent.java:213)
at com.sun.jersey.spi.container.servlet.ServletContainer.init(ServletContainer.java:373)
at com.sun.jersey.spi.container.servlet.ServletContainer.init(ServletContainer.java:556)
at javax.servlet.GenericServlet.init(GenericServlet.java:241)
at org.eclipse.jetty.servlet.ServletHolder.initServlet(ServletHolder.java:432)
at org.eclipse.jetty.servlet.ServletHolder.getServlet(ServletHolder.java:331)
at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:511)
at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:476)
at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:224)
at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:934)
at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:404)
at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:184)
at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:869)
at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:117)
at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:116)
at org.eclipse.jetty.server.Server.handle(Server.java:346)
at org.eclipse.jetty.server.HttpConnection.handleRequest(HttpConnection.java:581)
at org.eclipse.jetty.server.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:1040)
at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:592)
at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:214)
at org.eclipse.jetty.server.HttpConnection.handle(HttpConnection.java:411)
at org.eclipse.jetty.io.nio.SelectChannelEndPoint.handle(SelectChannelEndPoint.java:526)
at org.eclipse.jetty.io.nio.SelectChannelEndPoint$1.run(SelectChannelEndPoint.java:41)
at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:528)
at java.lang.Thread.run(Thread.java:662)
Caused by:
java.lang.RuntimeException: The resource 'application-doc.xml' does not exist.
at com.sun.jersey.api.wadl.config.WadlGeneratorLoader.setProperty(WadlGeneratorLoader.java:203)
at com.sun.jersey.api.wadl.config.WadlGeneratorLoader.loadWadlGenerator(WadlGeneratorLoader.java:139)
at com.sun.jersey.api.wadl.config.WadlGeneratorLoader.loadWadlGeneratorDescriptions(WadlGeneratorLoader.java:114)
at com.sun.jersey.api.wadl.config.WadlGeneratorConfig.getWadlGenerator(WadlGeneratorConfig.java:189)
at com.sun.jersey.api.wadl.config.WadlGeneratorConfigLoader.loadWadlGeneratorsFromConfig(WadlGeneratorConfigLoader.java:109)
at com.sun.jersey.server.impl.wadl.WadlFactory.<init>(WadlFactory.java:77)
at com.sun.jersey.server.impl.application.WebApplicationImpl._initiate(WebApplicationImpl.java:1135)
at com.sun.jersey.server.impl.application.WebApplicationImpl.access$600(WebApplicationImpl.java:159)
at com.sun.jersey.server.impl.application.WebApplicationImpl$12.f(WebApplicationImpl.java:700)
at com.sun.jersey.server.impl.application.WebApplicationImpl$12.f(WebApplicationImpl.java:697)
at com.sun.jersey.spi.inject.Errors.processWithErrors(Errors.java:193)
at com.sun.jersey.server.impl.application.WebApplicationImpl.initiate(WebApplicationImpl.java:697)
at com.sun.jersey.server.impl.application.WebApplicationImpl.initiate(WebApplicationImpl.java:692)
at com.sun.jersey.spi.container.servlet.ServletContainer.initiate(ServletContainer.java:488)
at com.sun.jersey.spi.container.servlet.ServletContainer$InternalWebComponent.initiate(ServletContainer.java:318)
at com.sun.jersey.spi.container.servlet.WebComponent.load(WebComponent.java:606)
at com.sun.jersey.spi.container.servlet.WebComponent.init(WebComponent.java:213)
at com.sun.jersey.spi.container.servlet.ServletContainer.init(ServletContainer.java:373)
at com.sun.jersey.spi.container.servlet.ServletContainer.init(ServletContainer.java:556)
at javax.servlet.GenericServlet.init(GenericServlet.java:241)
at org.eclipse.jetty.servlet.ServletHolder.initServlet(ServletHolder.java:432)
at org.eclipse.jetty.servlet.ServletHolder.getServlet(ServletHolder.java:331)
at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:511)
at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:476)
at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:224)
at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:934)
at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:404)
at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:184)
at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:869)
at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:117)
at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:116)
at org.eclipse.jetty.server.Server.handle(Server.java:346)
at org.eclipse.jetty.server.HttpConnection.handleRequest(HttpConnection.java:581)
at org.eclipse.jetty.server.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:1040)
at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:592)
at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:214)
at org.eclipse.jetty.server.HttpConnection.handle(HttpConnection.java:411)
at org.eclipse.jetty.io.nio.SelectChannelEndPoint.handle(SelectChannelEndPoint.java:526)
at org.eclipse.jetty.io.nio.SelectChannelEndPoint$1.run(SelectChannelEndPoint.java:41)
at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:528)
at java.lang.Thread.run(Thread.java:662)
2011-03-20 14:23:58.031:WARN::/
java.lang.RuntimeException: Could not load WadlGeneratorConfiguration, check the configuration of com.sun.jersey.config.property.WadlGeneratorConfig
at com.sun.jersey.api.wadl.config.WadlGeneratorConfigLoader.loadWadlGeneratorsFromConfig(WadlGeneratorConfigLoader.java:112)
at com.sun.jersey.server.impl.wadl.WadlFactory.<init>(WadlFactory.java:77)
at com.sun.jersey.server.impl.application.WebApplicationImpl._initiate(WebApplicationImpl.java:1135)
at com.sun.jersey.server.impl.application.WebApplicationImpl.access$600(WebApplicationImpl.java:159)
at com.sun.jersey.server.impl.application.WebApplicationImpl$12.f(WebApplicationImpl.java:700)
at com.sun.jersey.server.impl.application.WebApplicationImpl$12.f(WebApplicationImpl.java:697)
at com.sun.jersey.spi.inject.Errors.processWithErrors(Errors.java:193)
at com.sun.jersey.server.impl.application.WebApplicationImpl.initiate(WebApplicationImpl.java:697)
at com.sun.jersey.server.impl.application.WebApplicationImpl.initiate(WebApplicationImpl.java:692)
at com.sun.jersey.spi.container.servlet.ServletContainer.initiate(ServletContainer.java:488)
at com.sun.jersey.spi.container.servlet.ServletContainer$InternalWebComponent.initiate(ServletContainer.java:318)
at com.sun.jersey.spi.container.servlet.WebComponent.load(WebComponent.java:606)
at com.sun.jersey.spi.container.servlet.WebComponent.init(WebComponent.java:213)
at com.sun.jersey.spi.container.servlet.ServletContainer.init(ServletContainer.java:373)
at com.sun.jersey.spi.container.servlet.ServletContainer.init(ServletContainer.java:556)
at javax.servlet.GenericServlet.init(GenericServlet.java:241)
at org.eclipse.jetty.servlet.ServletHolder.initServlet(ServletHolder.java:432)
at org.eclipse.jetty.servlet.ServletHolder.getServlet(ServletHolder.java:331)
at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:511)
at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:476)
at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:224)
at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:934)
at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:404)
at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:184)
at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:869)
at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:117)
at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:116)
at org.eclipse.jetty.server.Server.handle(Server.java:346)
at org.eclipse.jetty.server.HttpConnection.handleRequest(HttpConnection.java:581)
at org.eclipse.jetty.server.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:1040)
at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:592)
at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:214)
at org.eclipse.jetty.server.HttpConnection.handle(HttpConnection.java:411)
at org.eclipse.jetty.io.nio.SelectChannelEndPoint.handle(SelectChannelEndPoint.java:526)
at org.eclipse.jetty.io.nio.SelectChannelEndPoint$1.run(SelectChannelEndPoint.java:41)
at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:528)
at java.lang.Thread.run(Thread.java:662)
Caused by:
java.lang.RuntimeException: Could not load wadl generators from wadlGeneratorDescriptions.
at com.sun.jersey.api.wadl.config.WadlGeneratorConfig.getWadlGenerator(WadlGeneratorConfig.java:191)
at com.sun.jersey.api.wadl.config.WadlGeneratorConfigLoader.loadWadlGeneratorsFromConfig(WadlGeneratorConfigLoader.java:109)
at com.sun.jersey.server.impl.wadl.WadlFactory.<init>(WadlFactory.java:77)
at com.sun.jersey.server.impl.application.WebApplicationImpl._initiate(WebApplicationImpl.java:1135)
at com.sun.jersey.server.impl.application.WebApplicationImpl.access$600(WebApplicationImpl.java:159)
at com.sun.jersey.server.impl.application.WebApplicationImpl$12.f(WebApplicationImpl.java:700)
at com.sun.jersey.server.impl.application.WebApplicationImpl$12.f(WebApplicationImpl.java:697)
at com.sun.jersey.spi.inject.Errors.processWithErrors(Errors.java:193)
at com.sun.jersey.server.impl.application.WebApplicationImpl.initiate(WebApplicationImpl.java:697)
at com.sun.jersey.server.impl.application.WebApplicationImpl.initiate(WebApplicationImpl.java:692)
at com.sun.jersey.spi.container.servlet.ServletContainer.initiate(ServletContainer.java:488)
at com.sun.jersey.spi.container.servlet.ServletContainer$InternalWebComponent.initiate(ServletContainer.java:318)
at com.sun.jersey.spi.container.servlet.WebComponent.load(WebComponent.java:606)
at com.sun.jersey.spi.container.servlet.WebComponent.init(WebComponent.java:213)
at com.sun.jersey.spi.container.servlet.ServletContainer.init(ServletContainer.java:373)
at com.sun.jersey.spi.container.servlet.ServletContainer.init(ServletContainer.java:556)
at javax.servlet.GenericServlet.init(GenericServlet.java:241)
at org.eclipse.jetty.servlet.ServletHolder.initServlet(ServletHolder.java:432)
at org.eclipse.jetty.servlet.ServletHolder.getServlet(ServletHolder.java:331)
at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:511)
at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:476)
at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:224)
at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:934)
at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:404)
at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:184)
at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:869)
at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:117)
at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:116)
at org.eclipse.jetty.server.Server.handle(Server.java:346)
at org.eclipse.jetty.server.HttpConnection.handleRequest(HttpConnection.java:581)
at org.eclipse.jetty.server.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:1040)
at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:592)
at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:214)
at org.eclipse.jetty.server.HttpConnection.handle(HttpConnection.java:411)
at org.eclipse.jetty.io.nio.SelectChannelEndPoint.handle(SelectChannelEndPoint.java:526)
at org.eclipse.jetty.io.nio.SelectChannelEndPoint$1.run(SelectChannelEndPoint.java:41)
at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:528)
at java.lang.Thread.run(Thread.java:662)
Caused by:
java.lang.RuntimeException: The resource 'application-doc.xml' does not exist.
at com.sun.jersey.api.wadl.config.WadlGeneratorLoader.setProperty(WadlGeneratorLoader.java:203)
at com.sun.jersey.api.wadl.config.WadlGeneratorLoader.loadWadlGenerator(WadlGeneratorLoader.java:139)
at com.sun.jersey.api.wadl.config.WadlGeneratorLoader.loadWadlGeneratorDescriptions(WadlGeneratorLoader.java:114)
at com.sun.jersey.api.wadl.config.WadlGeneratorConfig.getWadlGenerator(WadlGeneratorConfig.java:189)
at com.sun.jersey.api.wadl.config.WadlGeneratorConfigLoader.loadWadlGeneratorsFromConfig(WadlGeneratorConfigLoader.java:109)
at com.sun.jersey.server.impl.wadl.WadlFactory.<init>(WadlFactory.java:77)
at com.sun.jersey.server.impl.application.WebApplicationImpl._initiate(WebApplicationImpl.java:1135)
at com.sun.jersey.server.impl.application.WebApplicationImpl.access$600(WebApplicationImpl.java:159)
at com.sun.jersey.server.impl.application.WebApplicationImpl$12.f(WebApplicationImpl.java:700)
at com.sun.jersey.server.impl.application.WebApplicationImpl$12.f(WebApplicationImpl.java:697)
at com.sun.jersey.spi.inject.Errors.processWithErrors(Errors.java:193)
at com.sun.jersey.server.impl.application.WebApplicationImpl.initiate(WebApplicationImpl.java:697)
at com.sun.jersey.server.impl.application.WebApplicationImpl.initiate(WebApplicationImpl.java:692)
at com.sun.jersey.spi.container.servlet.ServletContainer.initiate(ServletContainer.java:488)
at com.sun.jersey.spi.container.servlet.ServletContainer$InternalWebComponent.initiate(ServletContainer.java:318)
at com.sun.jersey.spi.container.servlet.WebComponent.load(WebComponent.java:606)
at com.sun.jersey.spi.container.servlet.WebComponent.init(WebComponent.java:213)
at com.sun.jersey.spi.container.servlet.ServletContainer.init(ServletContainer.java:373)
at com.sun.jersey.spi.container.servlet.ServletContainer.init(ServletContainer.java:556)
at javax.servlet.GenericServlet.init(GenericServlet.java:241)
at org.eclipse.jetty.servlet.ServletHolder.initServlet(ServletHolder.java:432)
at org.eclipse.jetty.servlet.ServletHolder.getServlet(ServletHolder.java:331)
at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:511)
at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:476)
at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:224)
at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:934)
at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:404)
at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:184)
at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:869)
at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:117)
at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:116)
at org.eclipse.jetty.server.Server.handle(Server.java:346)
at org.eclipse.jetty.server.HttpConnection.handleRequest(HttpConnection.java:581)
at org.eclipse.jetty.server.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:1040)
at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:592)
at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:214)
at org.eclipse.jetty.server.HttpConnection.handle(HttpConnection.java:411)
at org.eclipse.jetty.io.nio.SelectChannelEndPoint.handle(SelectChannelEndPoint.java:526)
at org.eclipse.jetty.io.nio.SelectChannelEndPoint$1.run(SelectChannelEndPoint.java:41)
at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:528)
at java.lang.Thread.run(Thread.java:662)
->8-

Comment by danielrolson [ 21/Mar/11 ]

Attaching zip containing the requested missing files.

You obviously traced further into the code than I was able without having built Jersey myself.

Looking forward to your direction. As it is now, I have to downgrade my Jersey to version 1.1.2.

Thanks for your help.

Comment by danielrolson [ 04/Apr/11 ]

This issue has been dormant for a couple weeks now. Any update?

Comment by danielrolson [ 18/Apr/11 ]

Hey guys. It's been another 2 weeks since my last inquiry. Is there any update for this issue. It is getting uncomfortably close to my release and having to roll back (3 versions in this case) to an old version of Jersey is not what I want to do.

Can I get some status update please?

Comment by Pavel Bucek [ 20/Apr/11 ]

resource-doc.xml is still missing, can you please provide it?

Comment by danielrolson [ 20/Apr/11 ]

Attached is the desired file. I recommend commenting out the reference to this file. As soon as the service initializes (for any kind of request) it crashes.

Comment by Pavel Bucek [ 20/Apr/11 ]

thanks.

I'm probably missing something.. I slightly modified your code (Thread.sleep instead of server.wait() - it produced some exception and I'm getting application.wadll, not that resource (but it works for both cases):

public static void main(String[] args) throws Exception

{ ServletHolder sh = new ServletHolder(ServletContainer.class); sh.setInitParameter("com.sun.jersey.config.property.resourceConfigClass", "com.sun.jersey.api.core.PackagesResourceConfig"); sh.setInitParameter("com.sun.jersey.config.property.packages", "JavaBug"); sh.setInitParameter( "com.sun.jersey.config.property.WadlGeneratorConfig", "JavaBug.wadlGeneratorConfig"); Server server = new Server(9999); ServletContextHandler context = new ServletContextHandler(server, "/", ServletContextHandler.SESSIONS); context.addServlet(sh, "/*"); server.start(); Client c = Client.create(); WebResource r = c.resource("http://localhost:9999/application.wadl"); System.out.println(r.get(String.class)); Thread.sleep(2000); server.stop(); }

and this is what I'm getting:

2011-04-20 17:03:14.160:INFO::jetty-7.4.0.v20110414
2011-04-20 17:03:14.385:INFO::started o.e.j.s.ServletContextHandler

{/,null}
2011-04-20 17:03:14.436:INFO::Started SelectChannelConnector@0.0.0.0:9999 STARTING
Apr 20, 2011 5:03:15 PM com.sun.jersey.api.core.PackagesResourceConfig init
INFO: Scanning for root resource and provider classes in the packages:
JavaBug
Apr 20, 2011 5:03:15 PM com.sun.jersey.api.core.ScanningResourceConfig logClasses
INFO: Root resource classes found:
class JavaBug.Main$HelloWorld
Apr 20, 2011 5:03:15 PM com.sun.jersey.api.core.ScanningResourceConfig init
INFO: No provider classes found.
Apr 20, 2011 5:03:15 PM com.sun.jersey.server.impl.application.WebApplicationImpl _initiate
INFO: Initiating Jersey application, version 'Jersey: 1.6 03/25/2011 01:14 PM'
Apr 20, 2011 5:03:15 PM com.sun.jersey.api.wadl.config.WadlGeneratorLoader loadWadlGenerator
INFO: Loading wadlGenerator com.sun.jersey.server.wadl.generators.WadlGeneratorApplicationDoc
Apr 20, 2011 5:03:15 PM com.sun.jersey.api.wadl.config.WadlGeneratorLoader loadWadlGenerator
INFO: Loading wadlGenerator com.sun.jersey.server.wadl.generators.WadlGeneratorGrammarsSupport
Apr 20, 2011 5:03:15 PM com.sun.jersey.api.wadl.config.WadlGeneratorLoader loadWadlGenerator
INFO: Loading wadlGenerator com.sun.jersey.server.wadl.generators.resourcedoc.WadlGeneratorResourceDocSupport
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ns2:application xmlns:ns2="http://research.sun.com/wadl/2006/10">
<ns2:doc xmlns:jersey="http://jersey.dev.java.net/" jersey:generatedBy="Jersey: 1.6 03/25/2011 01:14 PM"/>
<ns2:doc xml:lang="en" title="Service API">
The Service provides the capability create and manage
and delivers information according to the parameters specified
in the definition.
</ns2:doc>
<ns2:grammars>
<ns2:include href="SearchRequest.xsd"/>
<ns2:include href="AlertsService.xsd"/>
</ns2:grammars>
<ns2:resources base="http://localhost:9999/">
<ns2:resource path="/">
<ns2:method name="GET" id="getMessage">
<ns2:response>
<ns2:representation mediaType="text/plain"/>
</ns2:response>
</ns2:method>
</ns2:resource>
</ns2:resources>
</ns2:application>

2011-04-20 17:03:19.708:INFO::stopped o.e.j.s.ServletContextHandler{/,null}

Process finished with exit code 0

(no exceptions). Where is the problem? (I'm using Jersey 1.6).

Comment by Pavel Bucek [ 20/Apr/11 ]

It works for me with Jersey 1.5 as well.

Comment by Pavel Bucek [ 21/Apr/11 ]

maven testcase based on provided files

Comment by Pavel Bucek [ 21/Apr/11 ]

see attached file jersey-674.zip

it is maven based sample which tries to reproduce reported issue, but seems like everything is working as expected - I suspect some configuration issue. Dan and I agreed "offline" on closing this issue as "Cannot Repoduce" for now.





[JERSEY-649] @Path("{id}") not matched for paths containing %2F Created: 15/Feb/11  Updated: 08/Aug/13  Resolved: 10/Mar/11

Status: Resolved
Project: jersey
Component/s: core
Affects Version/s: 1.4
Fix Version/s: 1.17

Type: Bug Priority: Blocker
Reporter: mkarg Assignee: Jakub Podlesak
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

JDK 6u23 x64 Win7 on both Grizzly 1.9.18-e and GFv2ur2


Tags: bug, showstopper

 Description   

@Path("

{id}

") is not matched for paths containing %2F (i. e. encoding for forward slashes)

When running on Grizzly 1.9.18-e the result is 404 Not Found.

When running on GlassFish v2ur2 the result is 400 Invalid URI: noSlash.

This is a showstopper for us, as the software has to run on GFv2ur2 and we do not see anything we could do to work around it.

Maybe this is related to JERSEY-648 which deals with the reverse (UriBuilder unable to encode forward slash as %2F).



 Comments   
Comment by Jakub Podlesak [ 08/Mar/11 ]

For Grizzly 1: Jersey needs to explicitly allow encoded slashes
on the Grizzly adapter, otherwise (the default behavior) Grizzly even
does not pass the request to Jersey and returns 4** right away
There was also a bug in Grizzly, http://java.net/jira/browse/GRIZZLY-828,
which prevented the above to work.

I am adding a test for path parameter containing %2F to the Jersey workspace
and upgrading to a newer/fixed Grizzly version (need to resolve some OSGi related
issues to make this work). The requested behavior won't work by default,
a new feature needs to be added to Jersey to control the Grizzly adapter setting

GlassFish v3:
You should be able to allow encoded slashes with the "encoded-slash-enabled" parameter in the domain.xml, e.g.:
...
<protocol name="admin-listener">
<http default-virtual-server="__asadmin" max-connections="250" encoded-slash-enabled="true">
<file-cache></file-cache>
</http>
</protocol>

GlassFish v2: need to check after making sure there is no bug in Jersey,
i.e. %2F in path params works fine in Jersey/Grizzly (the first case above)

Comment by Jakub Podlesak [ 09/Mar/11 ]

Introduced a new ResourceConfig feature, "com.sun.jersey.api.container.grizzly.AllowEncodedSlashFeature".
The feature allows to configure Grizzly to enable encoded slashes in URIs.

Added a new test for both Grizzly 1 and 2. Both tests are passing, when the above feature is enabled.
Look for com.sun.jersey.impl.container.grizzly.EscapedURITest (in jersey-tests and tests/grizzly2 modules)

The feature above should work only in standalone Grizzly.
See previous comment on how to enable it in GlassFish v3.

For GlassFish v2, i have not tested, but if there is an issue,
you may try to set the system property "com.sun.grizzly.util.buf.UDecoder.ALLOW_ENCODED_SLASH" to true,
restart and try.

Comment by mkarg [ 10/Mar/11 ]

Grizzly:

Using -Dcom.sun.grizzly.util.buf.UDecoder.ALLOW_ENCODED_SLASH=TRUE the problem seems to be solved.

GlassFish v2ur2:

Using -Dcom.sun.grizzly.util.buf.UDecoder.ALLOW_ENCODED_SLASH=TRUE (and rebooting) the problem still is existing and produces "HTTP/1.1 400 Invalid URI: noSlash"

Do you have an idea what I can do?

Comment by mkarg [ 10/Mar/11 ]

Still being blocked since GFv2ur2 ignores the proposed setting.

Comment by Jakub Podlesak [ 10/Mar/11 ]

Need to talk to Oleksiy, the Grizzly guy.
Will get back to you then.

Comment by Jakub Podlesak [ 10/Mar/11 ]

./bin/asadmin create-jvm-options -Dorg.apache.tomcat.util.buf.UDecoder.ALLOW_ENCODED_SLASH=true

should make this work (as suggested by Oleksiy)
...just sucessfully tested with Sun GlassFish Enterprise Server v2.1.1

Comment by Jakub Podlesak [ 10/Mar/11 ]

The thing works fine with Jersey
Turns out to be a configuration issue of the underlaying container rather than an actual bug in Jersey

Please take into account the feature is disabled by default on Grizzly/GlassFish for security reasons

Comment by mkarg [ 20/Jul/11 ]

To enable this in GFv3 one must execute the following CLI command:

asadmin set configs.config.server-config.network-config.protocols.protocol.http-listener-1.http.encoded-slash-enabled=true

Just tried out on GFv3.1.1_b11 and it works very well.

(see http://www.java.net/forum/topic/glassfish/glassfish/how-enable-encoded-slash-enabledtrue-existing-listener-using-asadmin)





[JERSEY-638] Extend WADL to support JSON response representation Created: 29/Jan/11  Updated: 28/Aug/14  Resolved: 20/Feb/13

Status: Resolved
Project: jersey
Component/s: core
Affects Version/s: 1.5
Fix Version/s: 1.17

Type: New Feature Priority: Major
Reporter: Martin Matula Assignee: Jakub Podlesak
Resolution: Fixed Votes: 2
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Text File JERSEY-638.patch    

 Description   

http://java.net/projects/jersey/lists/users/archive/2010-12/message/189

The extended WADL of Jersey has a nice feature for XML documentation, where you can say:
@response.representation.200.example

{@link Examples#MY_SAMPLE_OBJECT}

The WADL generator will actually marshal the MY_SAMPLE_OBJECT to XML for the documentation. That way the documentation reflects the REAL way that object would be represented. Awesome!

Unfortunately, all of my services produce JSON. In JSON, the example is even more important because there is no equivalent of a schema for JSON. Is there anything similar available for JSON? Has anyone written anything custom that I could look at as an example?



 Comments   
Comment by anilgmaipady [ 05/Mar/11 ]

This patch will fix this bug. Example:

  • @response.representation.200.mediaType application/json
  • @response.representation.200.example {@link Examples#SAMPLE_ITEM}

    Will generate JSON of Examples#SAMPLE_ITEM

    * @response.representation.200.mediaType application/xml
    * @response.representation.200.example {@link Examples#SAMPLE_ITEM}

Will generate XML of Examples#SAMPLE_ITEM

Comment by berngp [ 16/Apr/12 ]

Are there any updates to support a WADL serialized to JSON?

Looking forward for this!
Cheers
Bernardo.

Comment by gdavison [ 20/Feb/13 ]

You can now request a JSON version of the WADL with the mime type "application/vnd.sun.wadl+json", if you want JSON-Schema to be generated you need to look at the jersey-wadl-json-schema contrib module which will generate them for you. (See http://kingsfleet.blogspot.co.uk/2012/11/json-schema-generation-in-jersey.html)

Comment by sbolton [ 28/Aug/14 ]

This issue does not seem to be fixed. Generating the wadl with json schema does not solve this specific problem they are two separate things. It is the media type of the "example" that is wrong here and not creating the wadl as json or providing a json schema description of the object.

The format of the example is already rendered as xml in the resourcedoc.xml file before the wadl is generated, if the response type is json, then the example should be json.

  • @response.representation.200.qname Root
  • @response.representation.200.mediaType application/json
  • @response.representation.200.example {@link Root#DOC_EXAMPLE}

This is what I see when requesting the json schema version of the wadl. I have the describedby tags and I can request the schema for root. Note the example that is also included here that is still xml. We are using xslt to process the wadl and we do currently need the json-schema version, just the correct text representation of the example.

 <ns2:response status="200">
 <ns2:representation xmlns:json="http://wadl.dev.java.net/2009/02/json-schema" element="Root" mediaType="application/json" json:describedby="application.wadl/root">
 <ns2:doc>
 <ns4:p xmlns:ns4="http://www.w3.org/1999/xhtml">
<ns4:h6>Example</ns4:h6>
 <ns4:pre>
<ns4:code><?xml version="1.0" encoding="UTF-8" standalone="yes"?> <root/> </ns4:code>
 </ns4:pre>
 </ns4:p>
 </ns2:doc>
 </ns2:representation>
 </ns2:response>




[JERSEY-636] POSTing a JSON string to a resource does not strip the quoting Created: 27/Jan/11  Updated: 08/Aug/13  Resolved: 04/Feb/13

Status: Resolved
Project: jersey
Component/s: media
Affects Version/s: 1.4
Fix Version/s: 1.17

Type: Bug Priority: Major
Reporter: sugis Assignee: Jakub Podlesak
Resolution: Works as designed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Jackson, Jersey



 Description   

Declare a Resource that accepts application/json as a POST, and declare the sole parameter of the handler method to be a String
e.g.

@Path("...")
@Consumes(MediaType.APPLICATION_JSON)
@POST
public void doSomething(String withAnArgument)

{ ... }

I wish to pass xyz in as an argument. To make this a valid JSON representation, it must be quoted to "xyz"

This string is not unquoted on the Jersey end. I see the "xyz" quoted version, even though that is the JSON encoded version of my unquoted String. I have confirmed that if you deserialize "xyz" with Jackson as a String.class, it correctly returns a non-quoted xyz. This indicates to me that Jersey is not utilizing Jackson to deserialize String parameters as it does domain object parameters.



 Comments   
Comment by Jakub Podlesak [ 04/Feb/13 ]

Jersey deals with two basic JSON data structures: JSON object, and JSON array as defined e.g. at http://json.org
A standalone JSON String literal does not constitute a valid JSON data expression. You would need to implement a container request filter
to handle such input correctly, if you insist on using JSON media type even in such cases.





[JERSEY-633] Cannot PUT to a WebResource after GETting it Created: 18/Jan/11  Updated: 08/Aug/13  Resolved: 23/Feb/11

Status: Resolved
Project: jersey
Component/s: None
Affects Version/s: 1.5
Fix Version/s: 1.17

Type: Bug Priority: Blocker
Reporter: joven Assignee: Pavel Bucek
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Version 1.5 of jersey-server, jersey-client, and jersey-test-framework-http


Attachments: Zip Archive jersey-test-case-v2.zip    
Tags: 3_1-exclude

 Description   

If I GET a WebResource and read from the entity input stream until the end and then try to POST or PUT to the same resource, the second operation immediately fails with the following exception stack. If I do not read the InputStream to the end, the PUT succeeds fine.

I wrote up and included a test case that is attached.

com.sun.jersey.api.client.ClientHandlerException: java.io.IOException: Error writing request body to server
at com.sun.jersey.client.urlconnection.URLConnectionClientHandler.handle(URLConnectionClientHandler.java:131)
at com.sun.jersey.api.client.Client.handle(Client.java:629)
at com.sun.jersey.api.client.WebResource.handle(WebResource.java:601)
at com.sun.jersey.api.client.WebResource.put(WebResource.java:211)
at jersey.GetPutTest.testGetFollowedByPut(GetPutTest.java:40)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44)
at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41)
at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:31)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:73)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:46)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:180)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:41)
at org.junit.runners.ParentRunner$1.evaluate(ParentRunner.java:173)
at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:31)
at org.junit.runners.ParentRunner.run(ParentRunner.java:220)
at org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:59)
at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:115)
at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:102)
at org.apache.maven.surefire.Surefire.run(Surefire.java:180)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:350)
at org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:1021)
Caused by: java.io.IOException: Error writing request body to server
at sun.net.www.protocol.http.HttpURLConnection$StreamingOutputStream.checkError(HttpURLConnection.java:2802)
at sun.net.www.protocol.http.HttpURLConnection$StreamingOutputStream.write(HttpURLConnection.java:2785)
at com.sun.jersey.api.client.CommittingOutputStream.write(CommittingOutputStream.java:90)
at com.sun.jersey.core.util.ReaderWriter.writeTo(ReaderWriter.java:115)
at com.sun.jersey.core.provider.AbstractMessageReaderWriterProvider.writeTo(AbstractMessageReaderWriterProvider.java:76)
at com.sun.jersey.core.impl.provider.entity.FileProvider.writeTo(FileProvider.java:103)
at com.sun.jersey.core.impl.provider.entity.FileProvider.writeTo(FileProvider.java:64)
at com.sun.jersey.api.client.RequestWriter.writeRequestEntity(RequestWriter.java:311)
at com.sun.jersey.client.urlconnection.URLConnectionClientHandler._invoke(URLConnectionClientHandler.java:181)
at com.sun.jersey.client.urlconnection.URLConnectionClientHandler.handle(URLConnectionClientHandler.java:129)
... 32 more



 Comments   
Comment by joven [ 18/Jan/11 ]

Sandoz,

I would have re-opened 631 except I apparently do not have permissions to do so. I switched to the Grizzly test framework as you suggested and the test case I submitted the first time did pass. However, the code in my real project was still failing. I have updated the test case and attached another version that includes both a GET, a PUT, and a GET followed by a PUT. Every time I run this test from either Eclipse or maven, the PUT test is run last and always fails with the same exception. Even with the Grizzly server.

Comment by sandoz [ 19/Jan/11 ]

OK, so now you are running into the issue with HttpURLConnection and the handling of keep-alive connections and chunked encoding.

I recommend using the Apache HTTP client integration instead:

http://jersey.java.net/nonav/apidocs/1.5/contribs/jersey-apache-client/index.html

you can override the JerseyTest.client method to return an instance of ApacheHttpClient.

Comment by joven [ 19/Jan/11 ]

Thanks I will give that a try.

Comment by joven [ 16/Feb/11 ]

Sandoz's recommendation worked well for me.

Comment by Pavel Bucek [ 23/Feb/11 ]

closing; not jersey issue and workaround is available.





[JERSEY-630] Jersey 1.5 on Google App Engine throws NullPointerException Created: 15/Jan/11  Updated: 08/Aug/13  Resolved: 08/Aug/13

Status: Resolved
Project: jersey
Component/s: core
Affects Version/s: 1.5
Fix Version/s: 1.17

Type: Bug Priority: Major
Reporter: peterknego Assignee: Pavel Bucek
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Google App Engine 1.4.0 production server (NOT local dev server)


Tags: appengine, gf3_1-exclude

 Description   

A simple REST service producing a list of simple JSON objects via @GET results in a NullPointerException.

@Path("/appservice")
public class AppServiceBase implements AppService {

@GET
@Produces("application/json")
@Override
public ArrayList<OmniApp> getApps()

{ return ... }

}

This code worked flawlessly in 1.4. It stopped working when updated to Jersey 1.5.

NOTE: This works on a local AppEngine development server, it only fails on production server.

java.lang.NullPointerException
at com.sun.jersey.spi.container.ContainerRequest.<init>(ContainerRequest.java:184)
at com.sun.jersey.spi.container.servlet.WebComponent.createRequest(WebComponent.java:449)
at com.sun.jersey.spi.container.servlet.WebComponent.service(WebComponent.java:383)
at com.sun.jersey.spi.container.servlet.ServletContainer.service(ServletContainer.java:537)
at com.sun.jersey.spi.container.servlet.ServletContainer.service(ServletContainer.java:699)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:511)
at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1166)
at com.google.apphosting.utils.servlet.ParseBlobUploadFilter.doFilter(ParseBlobUploadFilter.java:97)
at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1157)
at com.google.apphosting.runtime.jetty.SaveSessionFilter.doFilter(SaveSessionFilter.java:35)
at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1157)
at com.google.apphosting.utils.servlet.TransactionCleanupFilter.doFilter(TransactionCleanupFilter.java:43)
at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1157)
at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:388)
at org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216)
at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:182)
at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:765)
at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:418)
at com.google.apphosting.runtime.jetty.AppVersionHandlerMap.handle(AppVersionHandlerMap.java:238)
at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152)
at org.mortbay.jetty.Server.handle(Server.java:326)
at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:542)
at org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:923)
at com.google.apphosting.runtime.jetty.RpcRequestParser.parseAvailable(RpcRequestParser.java:76)
at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:404)
at com.google.apphosting.runtime.jetty.JettyServletEngineAdapter.serviceRequest(JettyServletEngineAdapter.java:135)
at com.google.apphosting.runtime.JavaRuntime.handleRequest(JavaRuntime.java:261)
at com.google.apphosting.base.RuntimePb$EvaluationRuntime$6.handleBlockingRequest(RuntimePb.java:8495)
at com.google.apphosting.base.RuntimePb$EvaluationRuntime$6.handleBlockingRequest(RuntimePb.java:8493)
at com.google.net.rpc.impl.BlockingApplicationHandler.handleRequest(BlockingApplicationHandler.java:24)
at com.google.net.rpc.impl.RpcUtil.runRpcInApplication(RpcUtil.java:435)
at com.google.net.rpc.impl.Server$RpcTask.runInContext(Server.java:572)
at com.google.tracing.TraceContext$TraceContextRunnable$1.run(TraceContext.java:448)
at com.google.tracing.TraceContext.runInContext(TraceContext.java:688)
at com.google.tracing.TraceContext$AbstractTraceContextCallback.runInInheritedContextNoUnref(TraceContext.java:326)
at com.google.tracing.TraceContext$AbstractTraceContextCallback.runInInheritedContext(TraceContext.java:318)
at com.google.tracing.TraceContext$TraceContextRunnable.run(TraceContext.java:446)
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:636)



 Comments   
Comment by sandoz [ 19/Jan/11 ]

Any more details in the logs on deployment?

The NPE indicates a fundamental issue on deployment potentially related to incorrect initialization of the Jersey servlet e.g. the initialization fails and yet the servlet is still deployed.

Comment by peterknego [ 19/Jan/11 ]

I tried it again and I get the same exception.

However, the reply to the first request was different (below), while all consecutive requests result in NPE (same as above).

#

com.sun.jersey.api.core.PackagesResourceConfig init: Scanning for root resource and provider classes in the packages:
com.omnispots.server.rpc.rest

#
I 01-19 05:37AM 46.700

com.sun.jersey.api.core.ScanningResourceConfig logClasses: Root resource classes found:
class com.omnispots.server.rpc.rest.LocServiceBase
class com.omnispots.server.rpc.rest.AppServiceBase

#
I 01-19 05:37AM 46.700

com.sun.jersey.api.core.ScanningResourceConfig init: No provider classes found.

#
I 01-19 05:37AM 47.025

com.sun.jersey.server.impl.application.WebApplicationImpl _initiate: Initiating Jersey application, version 'Jersey: 1.5 01/14/2011 12:36 PM'

#
W 01-19 05:37AM 49.661

Error for /rest/appservice
java.lang.ExceptionInInitializerError
at com.sun.xml.bind.v2.runtime.reflect.opt.AccessorInjector.prepare(AccessorInjector.java:83)
at com.sun.xml.bind.v2.runtime.reflect.opt.OptimizedAccessorFactory.get(OptimizedAccessorFactory.java:176)
at com.sun.xml.bind.v2.runtime.reflect.Accessor$FieldReflection.optimize(Accessor.java:282)
at com.sun.xml.bind.v2.runtime.property.ArrayProperty.<init>(ArrayProperty.java:69)
at com.sun.xml.bind.v2.runtime.property.ArrayERProperty.<init>(ArrayERProperty.java:88)
at com.sun.xml.bind.v2.runtime.property.ArrayElementProperty.<init>(ArrayElementProperty.java:100)
at com.sun.xml.bind.v2.runtime.property.ArrayElementNodeProperty.<init>(ArrayElementNodeProperty.java:62)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:33)
at com.sun.xml.bind.v2.runtime.property.PropertyFactory.create(PropertyFactory.java:128)
at com.sun.xml.bind.v2.runtime.ClassBeanInfoImpl.<init>(ClassBeanInfoImpl.java:183)
at com.sun.xml.bind.v2.runtime.JAXBContextImpl.getOrCreate(JAXBContextImpl.java:532)
at com.sun.xml.bind.v2.runtime.JAXBContextImpl.<init>(JAXBContextImpl.java:347)
at com.sun.xml.bind.v2.runtime.JAXBContextImpl$JAXBContextBuilder.build(JAXBContextImpl.java:1170)
at com.sun.xml.bind.v2.ContextFactory.createContext(ContextFactory.java:145)
at com.sun.xml.bind.v2.ContextFactory.createContext(ContextFactory.java:236)
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:616)
at javax.xml.bind.ContextFinder.newInstance(ContextFinder.java:159)
at javax.xml.bind.ContextFinder.find(ContextFinder.java:311)
at javax.xml.bind.JAXBContext.newInstance(Unknown Source)
at javax.xml.bind.JAXBContext.newInstance(Unknown Source)
at javax.xml.bind.JAXBContext.newInstance(Unknown Source)
at com.sun.jersey.server.impl.wadl.WadlApplicationContextImpl.<init>(WadlApplicationContextImpl.java:69)
at com.sun.jersey.server.impl.wadl.WadlFactory.init(WadlFactory.java:97)
at com.sun.jersey.server.impl.application.RootResourceUriRules.initWadl(RootResourceUriRules.java:200)
at com.sun.jersey.server.impl.application.RootResourceUriRules.<init>(RootResourceUriRules.java:136)
at com.sun.jersey.server.impl.application.WebApplicationImpl._initiate(WebApplicationImpl.java:1184)
at com.sun.jersey.server.impl.application.WebApplicationImpl.access$600(WebApplicationImpl.java:159)
at com.sun.jersey.server.impl.application.WebApplicationImpl$12.f(WebApplicationImpl.java:700)
at com.sun.jersey.server.impl.application.WebApplicationImpl$12.f(WebApplicationImpl.java:697)
at com.sun.jersey.spi.inject.Errors.processWithErrors(Errors.java:193)
at com.sun.jersey.server.impl.application.WebApplicationImpl.initiate(WebApplicationImpl.java:697)
at com.sun.jersey.server.impl.application.WebApplicationImpl.initiate(WebApplicationImpl.java:692)
at com.sun.jersey.spi.container.servlet.ServletContainer.initiate(ServletContainer.java:488)
at com.sun.jersey.spi.container.servlet.ServletContainer$InternalWebComponent.initiate(ServletContainer.java:318)
at com.sun.jersey.spi.container.servlet.WebComponent.load(WebComponent.java:606)
at com.sun.jersey.spi.container.servlet.WebComponent.init(WebComponent.java:213)
at com.sun.jersey.spi.container.servlet.ServletContainer.init(ServletContainer.java:373)
at com.sun.jersey.spi.container.servlet.ServletContainer.init(ServletContainer.java:556)
at javax.servlet.GenericServlet.init(GenericServlet.java:212)
at org.mortbay.jetty.servlet.ServletHolder.initServlet(ServletHolder.java:440)
at org.mortbay.jetty.servlet.ServletHolder.getServlet(ServletHolder.java:339)
at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:487)
at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1166)
at com.omnispots.server.DumpFilter.doFilter(DumpFilter.java:158)
at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1157)
at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1157)
at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1157)
at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1157)
at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:388)
at org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216)
at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:182)
at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:765)
at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:418)
at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152)
at org.mortbay.jetty.Server.handle(Server.java:326)
at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:542)
at org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:923)
at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:404)
at com.google.net.rpc.impl.BlockingApplicationHandler.handleRequest(BlockingApplicationHandler.java:24)
at com.google.net.rpc.impl.RpcUtil.runRpcInApplication(RpcUtil.java:435)
at com.google.net.rpc.impl.Server$RpcTask.runInContext(Server.java:572)
at com.google.tracing.TraceContext$TraceContextRunnable$1.run(TraceContext.java:448)
at com.google.tracing.TraceContext.runInContext(TraceContext.java:688)
at com.google.tracing.TraceContext$AbstractTraceContextCallback.runInInheritedContextNoUnref(TraceContext.java:326)
at com.google.tracing.TraceContext$AbstractTraceContextCallback.runInInheritedContext(TraceContext.java:318)
at com.google.tracing.TraceContext$TraceContextRunnable.run(TraceContext.java:446)
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:636)
Caused by: java.lang.SecurityException: java.lang.IllegalAccessException: Reflection is not allowed on protected final java.lang.Class java.lang.ClassLoader.findLoadedClass(java.lang.String)
at com.google.appengine.runtime.Request.process-30d9d1412b091741(Request.java)
at com.sun.xml.bind.v2.runtime.reflect.opt.Injector$1.run(Injector.java:179)
at com.sun.xml.bind.v2.runtime.reflect.opt.Injector$1.run(Injector.java:174)
at java.security.AccessController.doPrivileged(AccessController.java:34)
at com.sun.xml.bind.v2.runtime.reflect.opt.Injector.<clinit>(Injector.java:172)
... 75 more
Caused by: java.lang.IllegalAccessException: Reflection is not allowed on protected final java.lang.Class java.lang.ClassLoader.findLoadedClass(java.lang.String)
... 79 more

Comment by sandoz [ 25/Jan/11 ]

Can you try disabling WADL generation:

http://jersey.java.net/nonav/apidocs/latest/jersey/com/sun/jersey/api/core/ResourceConfig.html#FEATURE_DISABLE_WADL

by adding the following servlet init param:

<init-param>
<param-name>com.sun.jersey.config.feature.DisableWADL</param-name>
<param-value>true</param-value>
</init-param>

Comment by pace [ 28/Jan/11 ]

I was getting the exact same error. I followed the suggestion posted by sandoz and the error went away. I have now successfully deployed a simple Jersey 1.5 application to the GAE.

Comment by Pavel Bucek [ 24/Feb/11 ]

closing.

this error is caused by
java.lang.IllegalAccessException: Reflection is not allowed on protected final java.lang.Class java.lang.ClassLoader.findLoadedClass(java.lang.String)
which implies different security constraints in the GAE. It is JAXB issue, and it goes away by disabling WADL generation (so we have at least workaround for now). It might pop up again when Jersey processes xml in request/response entity, but again, this is caused by JAXB in the GAE.

Feel free to reopen if you have other opinion/additional facts.

Comment by arjunsatyapal [ 20/Apr/12 ]

If you use jaxb-impl 2.1.12, it works fine on AppEngine.

Another possibility is that you handle your owne serialization using Jackson but that will be more painful.

Comment by arjunsatyapal [ 20/Apr/12 ]

After looking for some more time, found this workaround posted by chrstia

http://code.google.com/p/googleappengine/issues/detail?id=1267#c49

For reference :
The problem has a workaround, in appengine-web.xml add:

<system-properties>
<property name="com.sun.xml.bind.v2.bytecode.ClassTailor.noOptimize" value="true" />
</system-properties>

Then, jaxb 2.2.5 works fine!





[JERSEY-629] Discuss automatic mapper/provider loading in the jersey-guice documentation Created: 14/Jan/11  Updated: 08/Aug/13  Resolved: 18/Jul/13

Status: Resolved
Project: jersey
Component/s: docs
Affects Version/s: 1.5
Fix Version/s: 1.17

Type: Improvement Priority: Major
Reporter: cowwoc Assignee: Marek Potociar
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Please update http://jersey.java.net/nonav/apidocs/latest/contribs/jersey-guice/com/sun/jersey/guice/spi/container/servlet/package-summary.html to include the following important lines of code:

params.put(ServletContainer.RESOURCE_CONFIG_CLASS, ClasspathResourceConfig.class.getName());

Jersey won't load the default mappers/providers without it. In fact, I'd suggest going a step further and have GuiceServletContextListener assume this default unless overriden by the end-user (as is the case for DefaultResourceConfig).



 Comments   
Comment by cowwoc [ 14/Jan/11 ]

I'm not sure how priority ended up as "blocker" but obviously this isn't that critical Feel free to update the value to something more reasonable.

Comment by Marek Potociar [ 23/Feb/11 ]

Downgrading priority

Comment by cowwoc [ 09/Nov/12 ]

Upon further review I'm proposing the following changes:

  1. Add a section to the "user guide" found at http://jersey.java.net/nonav/documentation/latest/user-guide.html that explains all ResourceConfig sub-classes and helps users pick which one they should use.
  2. This isn't specific to Guice. There is no need to have GuiceServletContextListener use ClasspathResourceConfig by default if users know their options.

Please update the issue title to reflect this change.

Comment by Marek Potociar [ 18/Jul/13 ]

We do not plan to fix documentation on Jersey 1.x unless there is a critical issue in it. Closing as wont fix.





[JERSEY-622] InMemoryTestContainer does not use ClientConfig provided by AppDescriptor Created: 15/Dec/10  Updated: 08/Aug/13  Resolved: 22/Feb/13

Status: Resolved
Project: jersey
Component/s: test-framework
Affects Version/s: 1.4
Fix Version/s: 1.17

Type: Bug Priority: Major
Reporter: ngriso Assignee: Marek Potociar
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Text File improve_LowLevelAppDescriptor_transform()_(take_into_account_of_the_clientConfig).patch     Text File Take_into_account_the_clientConfig_of_the_AppDescriptor_(if_provided).patch    
Tags: gf3_1-exclude

 Description   

Hello,

I'm trying to use InMemoryTestContainer to test my Resource instead of GrizzlyTestContainerFactory.
My test works with GrizzlyTestContainerFactory but not with InMemoryTestContainer.

I think the reason is because InMemoryTestContainer does not use the ClientConfig I gave to a WebAppDescriptor.Builder.

My use case which made me found thaht is that I set JSONConfiguration.FEATURE_POJO_MAPPING to true in my client to use jackson.
And the flag jacksonEntityProviderFeatureSet in JacksonProviderProxy is never set to true when I use InMemoryTestContainer (but when using GrizzlyTestContainerFactory, it is).

Thanks
Nicolas G



 Comments   
Comment by ngriso [ 02/Feb/11 ]

I attached 2 patches for LowLevelAppDescriptor and InMemoryTestContainerFactory to fix this issue.
I write these patched with the 1.6-SNAPSHOT version (i.e the trunk)

Regards,
Nicolas G

Comment by Marek Potociar [ 22/Feb/13 ]

We're not planning to do changes in Jersey 1.x test framework except for critical fixes. Please look at the Jersey 2.x test framework and see if it works for you.





[JERSEY-618] Add a method getResourceConfigProperties in JerseyTest (Jersey Test Framework) Created: 06/Dec/10  Updated: 08/Aug/13  Resolved: 22/Feb/13

Status: Resolved
Project: jersey
Component/s: tools
Affects Version/s: 1.4
Fix Version/s: 1.17

Type: Improvement Priority: Minor
Reporter: walec51 Assignee: Marek Potociar
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: jersey, testing

 Description   

It would be useful to have a getResourceConfigProperties in JerseyTest so that we can change properties in various tests. I personally needed it to test a MessabeBodyWriter which behaviour depends on some properties in the ResourceConfig. For now I had to do a workaround like this:

public class ResourceConfigSingelton {

private ResourceConfig config;

static protected ResourceConfigSingelton inst = null;

protected ResourceConfigSingelton(ResourceConfig config)

{ this.config = config; }

static public ResourceConfig createInstance(
ResourceConfig config)

{ inst = new ResourceConfigSingelton(config); return inst.config; }

static public ResourceConfig getInstance()

{ return inst.config; }

}

public class ThrowableWriterTest extends JerseyTest {

public ThrowableWriterTest()

{ super(new LowLevelAppDescriptor.Builder( ResourceConfigSingelton.createInstance( new DefaultResourceConfig(ThrowableWriterResource.class, ThrowableMapper.class, ThrowableWriter.class)) ).build()); }

@Test
public void testRuntimeExceptionToText() {
ResourceConfigSingelton.getInstance().getProperties().put(
"com.sun.jersey.config.property.exceptionOutput", "PLAIN_TEXT");
...



 Comments   
Comment by Marek Potociar [ 22/Feb/13 ]

Instead we need to look at supporting per-test configuration which is already filed as another issue.





[JERSEY-617] Jersey client returns a missleading error when server is offline Created: 03/Dec/10  Updated: 08/Aug/13  Resolved: 04/Dec/10

Status: Resolved
Project: jersey
Component/s: core
Affects Version/s: 1.0.3
Fix Version/s: 1.17

Type: Improvement Priority: Minor
Reporter: jni Assignee: Pavel Bucek
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

All OS, all platform, all hardware config


Tags: error_handling

 Description   

When using Jersey Client to do a post on a server that is down or offline, the returned error is a marshalling error, while it should be a ConnectException really.

In class MarshallerImpl :

  • postWrite()'s outputbuffer throws an IOException of type ConnectException on line 316
  • Throwing a new MarshalException(e) from this ConnectException on line 320

In class AbstractRootElementProvider :

  • Catches a JAXBException on line 144 caused by the writeTo() above it
  • The ThrowHelper utility transforms it into an "Unable to marshall object of type {0}

    " type of error, on line 145
    The previous ConnectException is passed as a linked exception in the JAXBException.

The ConnectException is kept as a linked error while it is the main error. This can lead to much confusion while debugging.

I think the catch of an IOException on like 320 in MarshallerImpl should be more specific to catch ConnectException alone, and not encapsulate it in a MarshalException, because it really isn't.



 Comments   
Comment by Pavel Bucek [ 04/Dec/10 ]

first of all - this is not valid Jersey issue. This could be filed on JAXB issue tracker (which is currently in read-only mode due to migration)..

MarshallerImpl is part of JAXB reference implementation and it implements javax.xml.bind.Marshaller (through AbstractMarshallerImpl) which defines that marshalling process can throw only JAXBException (MarshallerException is descendant of JAXBException).

What you propose here is modify javax.xml.bind.Marshaller API, thus changing JSR222. This is not easy process and currently, it can't be done in reasonable timeframe, and I'm still not saying anything about validity of this issue.. Actually, current API specifies that Marshaller, Unmarshaller and I'm almost sure that everything else from API will throw JAXBException which will encapsulate original one. This is not bad design. Similar case - Marshaller methods will throw MarshalException and original one is encapsulated in it - again, not bad design. Developers can catch only these and if they are interested in getting reason, they can do it.

I agree that it could take a while to figure out that you need to look at these linked exceptions when something is wrong and you are debugging it, but its the price for using "high level" framework like JAXB (in this case).

Closing as won't fix - this issue doesn't belong here.

What you can do is fill new issue on http://jaxb.java.net (when the site is up and ready) and set a scope to SPEC.. but to be honest, I don't think that this will be changed.

Comment by sandoz [ 06/Dec/10 ]

Pavel, do you think it would be possible for Jersey to attempt to deconstruct the cause of the underlying JAXB exception so the developers do not have to?

Note similar issues can apply to Unmarshalling too.

Comment by Pavel Bucek [ 06/Dec/10 ]

yes, I was thinking about that too - after I closed this issue.

I'll create another "Improvement" for it (just in case - I don't want to forgot about this); see http://java.net/jira/browse/JERSEY-619





[JERSEY-609] Resource classes unable to be found and registered using package scanning under Websphere 7 Created: 01/Dec/10  Updated: 04/Mar/15  Resolved: 16/May/12

Status: Resolved
Project: jersey
Component/s: None
Affects Version/s: 1.4
Fix Version/s: 1.17

Type: Bug Priority: Minor
Reporter: padolan Assignee: Michal Gajdos
Resolution: Cannot Reproduce Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

IBM Websphere 7.0.0.3, Windows XP, Unix


Tags: gf3_1-exclude

 Description   

Related to JERSEY-558...

The problem (unable to get the websphere runtime to pick up resource classes located in java projects using the jersey package scanning ResourceConfig) was reported fixed with JBoss, but appears to still exist for websphere. The project structure is straightforward:
EAR

-----WAR

-----JAR

My web.xml is as follows:

<?xml version="1.0" encoding="UTF-8"?>
<web-app id="WebApp_ID" version="2.5" xmlns="http://java.sun.com/xml/ns/javaee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd">
<display-name>
TestWeb</display-name>
<welcome-file-list>
<welcome-file>index.html</welcome-file>
<welcome-file>index.htm</welcome-file>
<welcome-file>index.jsp</welcome-file>
<welcome-file>default.html</welcome-file>
<welcome-file>default.htm</welcome-file>
<welcome-file>default.jsp</welcome-file>
</welcome-file-list>
<servlet>
<servlet-name>TransSystemAdminRestServlet</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.walmart.trans</param-value>
</init-param>
<load-on-startup>1</load-on-startup>
</servlet>
<servlet-mapping>
<servlet-name>TransSystemAdminRestServlet</servlet-name>
<url-pattern>/*</url-pattern>
</servlet-mapping>
</web-app>

The full stacktrace I get is:

[12/1/10 8:01:40:638 CST] 00000017 PackagesResou I Scanning for root resource and provider classes in the packages:
com.walmart.trans
[12/1/10 8:01:40:982 CST] 00000017 WebApplicatio I Initiating Jersey application, version 'Jersey: 1.4 09/11/2010 10:41 PM'
[12/1/10 8:01:41:794 CST] 00000017 RootResourceU E The ResourceConfig instance does not contain any root resource classes.
[12/1/10 8:01:41:794 CST] 00000017 servlet E com.ibm.ws.webcontainer.servlet.ServletWrapper init SRVE0100E: Uncaught init() exception created by servlet TransSystemAdminRestServlet in application TestEAR: com.sun.jersey.api.container.ContainerException: The ResourceConfig instance does not contain any root resource classes.
at com.sun.jersey.server.impl.application.RootResourceUriRules.<init>(RootResourceUriRules.java:103)
at com.sun.jersey.server.impl.application.WebApplicationImpl._initiate(WebApplicationImpl.java:1182)
at com.sun.jersey.server.impl.application.WebApplicationImpl.access$600(WebApplicationImpl.java:161)
at com.sun.jersey.server.impl.application.WebApplicationImpl$12.f(WebApplicationImpl.java:698)
at com.sun.jersey.server.impl.application.WebApplicationImpl$12.f(WebApplicationImpl.java:695)
at com.sun.jersey.spi.inject.Errors.processWithErrors(Errors.java:197)
at com.sun.jersey.server.impl.application.WebApplicationImpl.initiate(WebApplicationImpl.java:695)
at com.sun.jersey.server.impl.application.WebApplicationImpl.initiate(WebApplicationImpl.java:690)
at com.sun.jersey.spi.container.servlet.ServletContainer.initiate(ServletContainer.java:438)
at com.sun.jersey.spi.container.servlet.ServletContainer$InternalWebComponent.initiate(ServletContainer.java:287)
at com.sun.jersey.spi.container.servlet.WebComponent.load(WebComponent.java:587)
at com.sun.jersey.spi.container.servlet.WebComponent.init(WebComponent.java:213)
at com.sun.jersey.spi.container.servlet.ServletContainer.init(ServletContainer.java:342)
at com.sun.jersey.spi.container.servlet.ServletContainer.init(ServletContainer.java:516)
at javax.servlet.GenericServlet.init(GenericServlet.java:241)
at com.ibm.ws.webcontainer.servlet.ServletWrapper.init(ServletWrapper.java:326)
at com.ibm.ws.webcontainer.servlet.ServletWrapperImpl.init(ServletWrapperImpl.java:165)
at com.ibm.ws.webcontainer.servlet.ServletWrapper.initialize(ServletWrapper.java:1600)
at com.ibm.wsspi.webcontainer.extension.WebExtensionProcessor.createServletWrapper(WebExtensionProcessor.java:98)
at com.ibm.ws.webcontainer.webapp.WebApp.getServletWrapper(WebApp.java:939)
at com.ibm.ws.webcontainer.webapp.WebApp.getServletWrapper(WebApp.java:860)
at com.ibm.ws.webcontainer.webapp.WebApp.initializeTargetMappings(WebApp.java:541)
at com.ibm.ws.webcontainer.webapp.WebApp.commonInitializationFinish(WebApp.java:363)
at com.ibm.ws.webcontainer.webapp.WebAppImpl.initialize(WebAppImpl.java:293)
at com.ibm.ws.webcontainer.webapp.WebGroupImpl.addWebApplication(WebGroupImpl.java:100)
at com.ibm.ws.webcontainer.VirtualHostImpl.addWebApplication(VirtualHostImpl.java:166)
at com.ibm.ws.webcontainer.WSWebContainer.addWebApp(WSWebContainer.java:728)
at com.ibm.ws.webcontainer.WSWebContainer.addWebApplication(WSWebContainer.java:613)
at com.ibm.ws.webcontainer.component.WebContainerImpl.install(WebContainerImpl.java:376)
at com.ibm.ws.webcontainer.component.WebContainerImpl.start(WebContainerImpl.java:668)
at com.ibm.ws.runtime.component.ApplicationMgrImpl.start(ApplicationMgrImpl.java:1144)
at com.ibm.ws.runtime.component.DeployedApplicationImpl.fireDeployedObjectStart(DeployedApplicationImpl.java:1313)
at com.ibm.ws.runtime.component.DeployedModuleImpl.start(DeployedModuleImpl.java:611)
at com.ibm.ws.runtime.component.DeployedApplicationImpl.start(DeployedApplicationImpl.java:938)
at com.ibm.ws.runtime.component.ApplicationMgrImpl.startApplication(ApplicationMgrImpl.java:723)
at com.ibm.ws.runtime.component.ApplicationMgrImpl$1.run(ApplicationMgrImpl.java:1288)
at com.ibm.ws.security.auth.ContextManagerImpl.runAs(ContextManagerImpl.java:4388)
at com.ibm.ws.security.auth.ContextManagerImpl.runAsSystem(ContextManagerImpl.java:4566)
at com.ibm.ws.security.core.SecurityContext.runAsSystem(SecurityContext.java:255)
at com.ibm.ws.runtime.component.ApplicationMgrImpl.startApplicationDynamically(ApplicationMgrImpl.java:1293)
at com.ibm.ws.runtime.component.ApplicationMgrImpl.start(ApplicationMgrImpl.java:2065)
at com.ibm.ws.runtime.component.CompositionUnitMgrImpl.start(CompositionUnitMgrImpl.java:437)
at com.ibm.ws.runtime.component.CompositionUnitImpl.start(CompositionUnitImpl.java:122)
at com.ibm.ws.runtime.component.CompositionUnitMgrImpl.start(CompositionUnitMgrImpl.java:380)
at com.ibm.ws.runtime.component.CompositionUnitMgrImpl.startCompositionUnit(CompositionUnitMgrImpl.java:651)
at com.ibm.ws.runtime.component.CompositionUnitMgrImpl.startCompositionUnit(CompositionUnitMgrImpl.java:613)
at com.ibm.ws.runtime.component.ApplicationMgrImpl.startApplication(ApplicationMgrImpl.java:1199)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
at java.lang.reflect.Method.invoke(Method.java:599)
at sun.reflect.misc.Trampoline.invoke(MethodUtil.java:36)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
at java.lang.reflect.Method.invoke(Method.java:599)
at sun.reflect.misc.MethodUtil.invoke(MethodUtil.java:243)
at javax.management.modelmbean.RequiredModelMBean.invokeMethod(RequiredModelMBean.java:1085)
at javax.management.modelmbean.RequiredModelMBean.invoke(RequiredModelMBean.java:966)
at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:848)
at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:773)
at com.ibm.ws.management.AdminServiceImpl$1.run(AdminServiceImpl.java:1310)
at com.ibm.ws.security.util.AccessController.doPrivileged(AccessController.java:118)
at com.ibm.ws.management.AdminServiceImpl.invoke(AdminServiceImpl.java:1203)
at com.ibm.ws.management.connector.AdminServiceDelegator.invoke(AdminServiceDelegator.java:181)
at com.ibm.ws.management.connector.rmi.RMIConnectorService.invoke(RMIConnectorService.java:282)
at com.ibm.ws.management.connector.rmi._RMIConnectorService_Tie.invoke(_RMIConnectorService_Tie.java:395)
at com.ibm.ws.management.connector.rmi._RMIConnectorService_Tie._invoke(_RMIConnectorService_Tie.java:160)
at com.ibm.CORBA.iiop.ServerDelegate.dispatchInvokeHandler(ServerDelegate.java:622)
at com.ibm.CORBA.iiop.ServerDelegate.dispatch(ServerDelegate.java:475)
at com.ibm.rmi.iiop.ORB.process(ORB.java:504)
at com.ibm.CORBA.iiop.ORB.process(ORB.java:1573)
at com.ibm.rmi.iiop.Connection.respondTo(Connection.java:2845)
at com.ibm.rmi.iiop.Connection.doWork(Connection.java:2714)
at com.ibm.rmi.iiop.WorkUnitImpl.doWork(WorkUnitImpl.java:63)
at com.ibm.ejs.oa.pool.PooledThread.run(ThreadPool.java:118)
at com.ibm.ws.util.ThreadPool$Worker.run(ThreadPool.java:1527)

[12/1/10 8:01:41:794 CST] 00000017 extension E com.ibm.wsspi.webcontainer.extension.WebExtensionProcessor createServletWrapper Error occured while preparing the servlet for initialization.
javax.servlet.ServletException: SRVE0207E: Uncaught initialization exception created by servlet
at com.ibm.ws.webcontainer.servlet.ServletWrapper.init(ServletWrapper.java:378)
at com.ibm.ws.webcontainer.servlet.ServletWrapperImpl.init(ServletWrapperImpl.java:165)
at com.ibm.ws.webcontainer.servlet.ServletWrapper.initialize(ServletWrapper.java:1600)
at com.ibm.wsspi.webcontainer.extension.WebExtensionProcessor.createServletWrapper(WebExtensionProcessor.java:98)
at com.ibm.ws.webcontainer.webapp.WebApp.getServletWrapper(WebApp.java:939)
at com.ibm.ws.webcontainer.webapp.WebApp.getServletWrapper(WebApp.java:860)
at com.ibm.ws.webcontainer.webapp.WebApp.initializeTargetMappings(WebApp.java:541)
at com.ibm.ws.webcontainer.webapp.WebApp.commonInitializationFinish(WebApp.java:363)
at com.ibm.ws.webcontainer.webapp.WebAppImpl.initialize(WebAppImpl.java:293)
at com.ibm.ws.webcontainer.webapp.WebGroupImpl.addWebApplication(WebGroupImpl.java:100)
at com.ibm.ws.webcontainer.VirtualHostImpl.addWebApplication(VirtualHostImpl.java:166)
at com.ibm.ws.webcontainer.WSWebContainer.addWebApp(WSWebContainer.java:728)
at com.ibm.ws.webcontainer.WSWebContainer.addWebApplication(WSWebContainer.java:613)
at com.ibm.ws.webcontainer.component.WebContainerImpl.install(WebContainerImpl.java:376)
at com.ibm.ws.webcontainer.component.WebContainerImpl.start(WebContainerImpl.java:668)
at com.ibm.ws.runtime.component.ApplicationMgrImpl.start(ApplicationMgrImpl.java:1144)
at com.ibm.ws.runtime.component.DeployedApplicationImpl.fireDeployedObjectStart(DeployedApplicationImpl.java:1313)
at com.ibm.ws.runtime.component.DeployedModuleImpl.start(DeployedModuleImpl.java:611)
at com.ibm.ws.runtime.component.DeployedApplicationImpl.start(DeployedApplicationImpl.java:938)
at com.ibm.ws.runtime.component.ApplicationMgrImpl.startApplication(ApplicationMgrImpl.java:723)
at com.ibm.ws.runtime.component.ApplicationMgrImpl$1.run(ApplicationMgrImpl.java:1288)
at com.ibm.ws.security.auth.ContextManagerImpl.runAs(ContextManagerImpl.java:4388)
at com.ibm.ws.security.auth.ContextManagerImpl.runAsSystem(ContextManagerImpl.java:4566)
at com.ibm.ws.security.core.SecurityContext.runAsSystem(SecurityContext.java:255)
at com.ibm.ws.runtime.component.ApplicationMgrImpl.startApplicationDynamically(ApplicationMgrImpl.java:1293)
at com.ibm.ws.runtime.component.ApplicationMgrImpl.start(ApplicationMgrImpl.java:2065)
at com.ibm.ws.runtime.component.CompositionUnitMgrImpl.start(CompositionUnitMgrImpl.java:437)
at com.ibm.ws.runtime.component.CompositionUnitImpl.start(CompositionUnitImpl.java:122)
at com.ibm.ws.runtime.component.CompositionUnitMgrImpl.start(CompositionUnitMgrImpl.java:380)
at com.ibm.ws.runtime.component.CompositionUnitMgrImpl.startCompositionUnit(CompositionUnitMgrImpl.java:651)
at com.ibm.ws.runtime.component.CompositionUnitMgrImpl.startCompositionUnit(CompositionUnitMgrImpl.java:613)
at com.ibm.ws.runtime.component.ApplicationMgrImpl.startApplication(ApplicationMgrImpl.java:1199)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
at java.lang.reflect.Method.invoke(Method.java:599)
at sun.reflect.misc.Trampoline.invoke(MethodUtil.java:36)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
at java.lang.reflect.Method.invoke(Method.java:599)
at sun.reflect.misc.MethodUtil.invoke(MethodUtil.java:243)
at javax.management.modelmbean.RequiredModelMBean.invokeMethod(RequiredModelMBean.java:1085)
at javax.management.modelmbean.RequiredModelMBean.invoke(RequiredModelMBean.java:966)
at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:848)
at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:773)
at com.ibm.ws.management.AdminServiceImpl$1.run(AdminServiceImpl.java:1310)
at com.ibm.ws.security.util.AccessController.doPrivileged(AccessController.java:118)
at com.ibm.ws.management.AdminServiceImpl.invoke(AdminServiceImpl.java:1203)
at com.ibm.ws.management.connector.AdminServiceDelegator.invoke(AdminServiceDelegator.java:181)
at com.ibm.ws.management.connector.rmi.RMIConnectorService.invoke(RMIConnectorService.java:282)
at com.ibm.ws.management.connector.rmi._RMIConnectorService_Tie.invoke(_RMIConnectorService_Tie.java:395)
at com.ibm.ws.management.connector.rmi._RMIConnectorService_Tie._invoke(_RMIConnectorService_Tie.java:160)
at com.ibm.CORBA.iiop.ServerDelegate.dispatchInvokeHandler(ServerDelegate.java:622)
at com.ibm.CORBA.iiop.ServerDelegate.dispatch(ServerDelegate.java:475)
at com.ibm.rmi.iiop.ORB.process(ORB.java:504)
at com.ibm.CORBA.iiop.ORB.process(ORB.java:1573)
at com.ibm.rmi.iiop.Connection.respondTo(Connection.java:2845)
at com.ibm.rmi.iiop.Connection.doWork(Connection.java:2714)
at com.ibm.rmi.iiop.WorkUnitImpl.doWork(WorkUnitImpl.java:63)
at com.ibm.ejs.oa.pool.PooledThread.run(ThreadPool.java:118)
at com.ibm.ws.util.ThreadPool$Worker.run(ThreadPool.java:1527)
Caused by: com.sun.jersey.api.container.ContainerException: The ResourceConfig instance does not contain any root resource classes.
at com.sun.jersey.server.impl.application.RootResourceUriRules.<init>(RootResourceUriRules.java:103)
at com.sun.jersey.server.impl.application.WebApplicationImpl._initiate(WebApplicationImpl.java:1182)
at com.sun.jersey.server.impl.application.WebApplicationImpl.access$600(WebApplicationImpl.java:161)
at com.sun.jersey.server.impl.application.WebApplicationImpl$12.f(WebApplicationImpl.java:698)
at com.sun.jersey.server.impl.application.WebApplicationImpl$12.f(WebApplicationImpl.java:695)
at com.sun.jersey.spi.inject.Errors.processWithErrors(Errors.java:197)
at com.sun.jersey.server.impl.application.WebApplicationImpl.initiate(WebApplicationImpl.java:695)
at com.sun.jersey.server.impl.application.WebApplicationImpl.initiate(WebApplicationImpl.java:690)
at com.sun.jersey.spi.container.servlet.ServletContainer.initiate(ServletContainer.java:438)
at com.sun.jersey.spi.container.servlet.ServletContainer$InternalWebComponent.initiate(ServletContainer.java:287)
at com.sun.jersey.spi.container.servlet.WebComponent.load(WebComponent.java:587)
at com.sun.jersey.spi.container.servlet.WebComponent.init(WebComponent.java:213)
at com.sun.jersey.spi.container.servlet.ServletContainer.init(ServletContainer.java:342)
at com.sun.jersey.spi.container.servlet.ServletContainer.init(ServletContainer.java:516)
at javax.servlet.GenericServlet.init(GenericServlet.java:241)
at com.ibm.ws.webcontainer.servlet.ServletWrapper.init(ServletWrapper.java:326)
... 61 more

The workaround I have is to remove the servlet init parameter, and ensure my resource classes are in the WEB-INF/lib folder of the WAR project. I'd prefer to not have to do this if possible.

Thanks for any help.



 Comments   
Comment by Michal Gajdos [ 17/Feb/12 ]

Can you provide an example to this issue (e.g. by attaching a sample application that fails to start after the deployment), because unfortunately I am not able to reproduce the problem? Does this problem occur even with the Jersey samples (e.g. helloworld-webapp, extended-wadl-webapp) for you?

Comment by Michal Gajdos [ 16/May/12 ]

Resolving as 'Cannot Reproduce'. Feel free to reopen if the problem persist.

Comment by Ramasarma [ 04/Mar/15 ]

I am able to reproduce this issue in my local.

[3/4/15 6:07:58:454 EST] 00000019 WebApplicatio I Initiating Jersey application, version 'Jersey: 1.19 02/11/2015 03:25 AM'
[3/4/15 6:07:58:843 EST] 00000019 RootResourceU E The ResourceConfig instance does not contain any root resource classes.
[3/4/15 6:07:58:845 EST] 00000019 servlet E com.ibm.ws.webcontainer.servlet.ServletWrapper init Uncaught.init.exception.thrown.by.servlet
[3/4/15 6:07:58:845 EST] 00000019 webapp E com.ibm.ws.webcontainer.webapp.WebApp commonInitializationFinally SRVE0266E: Error occured while initializing servlets:

{0}

javax.servlet.ServletException: SRVE0207E: Uncaught initialization exception created by servlet
at com.ibm.ws.webcontainer.servlet.ServletWrapper.init(ServletWrapper.java:391)
at com.ibm.ws.webcontainer.servlet.ServletWrapperImpl.init(ServletWrapperImpl.java:168)
at com.ibm.ws.webcontainer.servlet.ServletWrapper.loadOnStartupCheck(ServletWrapper.java:1274)
at com.ibm.ws.webcontainer.webapp.WebApp.doLoadOnStartupActions(WebApp.java:586)
at com.ibm.ws.webcontainer.webapp.WebApp.commonInitializationFinally(WebApp.java:557)
at com.ibm.ws.webcontainer.webapp.WebAppImpl.initialize(WebAppImpl.java:421)
at com.ibm.ws.webcontainer.webapp.WebGroupImpl.addWebApplication(WebGroupImpl.java:88)
at com.ibm.ws.webcontainer.VirtualHostImpl.addWebApplication(VirtualHostImpl.java:169)
at com.ibm.ws.webcontainer.WSWebContainer.addWebApp(WSWebContainer.java:748)
at com.ibm.ws.webcontainer.WSWebContainer.addWebApplication(WSWebContainer.java:633)
at com.ibm.ws.webcontainer.component.WebContainerImpl.install(WebContainerImpl.java:422)
at com.ibm.ws.webcontainer.component.WebContainerImpl.start(WebContainerImpl.java:714)
at com.ibm.ws.runtime.component.ApplicationMgrImpl.start(ApplicationMgrImpl.java:1134)
at com.ibm.ws.runtime.component.DeployedApplicationImpl.fireDeployedObjectStart(DeployedApplicationImpl.java:1369)
at com.ibm.ws.runtime.component.DeployedModuleImpl.start(DeployedModuleImpl.java:638)
at com.ibm.ws.runtime.component.ApplicationMgrImpl.startModule(ApplicationMgrImpl.java:1632)
at com.ibm.ws.runtime.component.ApplicationMgrImpl.access$400(ApplicationMgrImpl.java:206)
at com.ibm.ws.runtime.component.ApplicationMgrImpl$3.run(ApplicationMgrImpl.java:1567)
at com.ibm.ws.security.auth.ContextManagerImpl.runAs(ContextManagerImpl.java:5277)
at com.ibm.ws.security.auth.ContextManagerImpl.runAsSystem(ContextManagerImpl.java:5493)
at com.ibm.ws.security.core.SecurityContext.runAsSystem(SecurityContext.java:255)
at com.ibm.ws.runtime.component.ApplicationMgrImpl._startModule(ApplicationMgrImpl.java:1596)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:60)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
at java.lang.reflect.Method.invoke(Method.java:611)
at sun.reflect.misc.Trampoline.invoke(MethodUtil.java:49)
at sun.reflect.GeneratedMethodAccessor10.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
at java.lang.reflect.Method.invoke(Method.java:611)
at sun.reflect.misc.MethodUtil.invoke(MethodUtil.java:256)
at javax.management.modelmbean.RequiredModelMBean.invokeMethod(RequiredModelMBean.java:1085)
at javax.management.modelmbean.RequiredModelMBean.invoke(RequiredModelMBean.java:966)
at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:848)
at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:773)
at com.ibm.ws.management.AdminServiceImpl$1.run(AdminServiceImpl.java:1334)
at com.ibm.ws.security.util.AccessController.doPrivileged(AccessController.java:118)
at com.ibm.ws.management.AdminServiceImpl.invoke(AdminServiceImpl.java:1227)
at com.ibm.ws.management.application.sync.StartDeploymentTask.startDeployment(StartDeploymentTask.java:236)
at com.ibm.ws.management.application.sync.StartDeploymentTask.fineGrainUpdate(StartDeploymentTask.java:187)
at com.ibm.ws.management.application.sync.StartDeploymentTask.performTask(StartDeploymentTask.java:99)
at com.ibm.ws.management.application.sync.AppBinaryProcessor$ExpandApp.expand(AppBinaryProcessor.java:1539)
at com.ibm.ws.management.application.sync.AppBinaryProcessor.postProcessSynchronousExt(AppBinaryProcessor.java:701)
at com.ibm.ws.management.bla.sync.BLABinaryProcessor.postProcess(BLABinaryProcessor.java:575)
at com.ibm.ws.management.bla.sync.BLABinaryProcessor.onChangeCompletion(BLABinaryProcessor.java:452)
at com.ibm.ws.management.repository.FileRepository.postNotify(FileRepository.java:1936)
at com.ibm.ws.management.repository.FileRepository.update(FileRepository.java:1445)
at com.ibm.ws.management.repository.client.LocalConfigRepositoryClient.update(LocalConfigRepositoryClient.java:189)
at com.ibm.ws.sm.workspace.impl.WorkSpaceMasterRepositoryAdapter.update(WorkSpaceMasterRepositoryAdapter.java:657)
at com.ibm.ws.sm.workspace.impl.RepositoryContextImpl.update(RepositoryContextImpl.java:1998)
at com.ibm.ws.sm.workspace.impl.RepositoryContextImpl.synch(RepositoryContextImpl.java:1946)
at com.ibm.ws.sm.workspace.impl.WorkSpaceImpl.synch(WorkSpaceImpl.java:549)
at com.ibm.ws.management.configservice.ConfigServiceImpl.save(ConfigServiceImpl.java:717)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:60)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
at java.lang.reflect.Method.invoke(Method.java:611)
at sun.reflect.misc.Trampoline.invoke(MethodUtil.java:49)
at sun.reflect.GeneratedMethodAccessor10.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
at java.lang.reflect.Method.invoke(Method.java:611)
at sun.reflect.misc.MethodUtil.invoke(MethodUtil.java:256)
at javax.management.modelmbean.RequiredModelMBean.invokeMethod(RequiredModelMBean.java:1085)
at javax.management.modelmbean.RequiredModelMBean.invoke(RequiredModelMBean.java:966)
at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:848)
at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:773)
at com.ibm.ws.management.AdminServiceImpl$1.run(AdminServiceImpl.java:1334)
at com.ibm.ws.security.util.AccessController.doPrivileged(AccessController.java:118)
at com.ibm.ws.management.AdminServiceImpl.invoke(AdminServiceImpl.java:1227)
at com.ibm.ws.management.remote.AdminServiceForwarder.invoke(AdminServiceForwarder.java:334)
at javax.management.remote.rmi.RMIConnectionImpl.doOperation(RMIConnectionImpl.java:1438)
at javax.management.remote.rmi.RMIConnectionImpl.access$200(RMIConnectionImpl.java:83)
at javax.management.remote.rmi.RMIConnectionImpl$PrivilegedOperation.run(RMIConnectionImpl.java:1276)
at javax.management.remote.rmi.RMIConnectionImpl.doPrivilegedOperation(RMIConnectionImpl.java:1371)
at javax.management.remote.rmi.RMIConnectionImpl.invoke(RMIConnectionImpl.java:799)
at javax.management.remote.rmi._RMIConnectionImpl_Tie.invoke(_RMIConnectionImpl_Tie.java:750)
at javax.management.remote.rmi._RMIConnectionImpl_Tie._invoke(_RMIConnectionImpl_Tie.java:158)
at com.ibm.CORBA.iiop.ServerDelegate.dispatchInvokeHandler(ServerDelegate.java:626)
at com.ibm.CORBA.iiop.ServerDelegate.dispatch(ServerDelegate.java:479)
at com.ibm.rmi.iiop.ORB.process(ORB.java:514)
at com.ibm.CORBA.iiop.ORB.process(ORB.java:1574)
at com.ibm.rmi.iiop.Connection.respondTo(Connection.java:2880)
at com.ibm.rmi.iiop.Connection.doWork(Connection.java:2753)
at com.ibm.rmi.iiop.WorkUnitImpl.doWork(WorkUnitImpl.java:63)
at com.ibm.ejs.oa.pool.PooledThread.run(ThreadPool.java:118)
at com.ibm.ws.util.ThreadPool$Worker.run(ThreadPool.java:1648)
Caused by: com.sun.jersey.api.container.ContainerException: The ResourceConfig instance does not contain any root resource classes.
at com.sun.jersey.server.impl.application.RootResourceUriRules.<init>(RootResourceUriRules.java:99)
at com.sun.jersey.server.impl.application.WebApplicationImpl._initiate(WebApplicationImpl.java:1359)
at com.sun.jersey.server.impl.application.WebApplicationImpl.access$700(WebApplicationImpl.java:180)
at com.sun.jersey.server.impl.application.WebApplicationImpl$13.f(WebApplicationImpl.java:799)
at com.sun.jersey.server.impl.application.WebApplicationImpl$13.f(WebApplicationImpl.java:795)
at com.sun.jersey.spi.inject.Errors.processWithErrors(Errors.java:193)
at com.sun.jersey.server.impl.application.WebApplicationImpl.initiate(WebApplicationImpl.java:795)
at com.sun.jersey.server.impl.application.WebApplicationImpl.initiate(WebApplicationImpl.java:790)
at com.sun.jersey.spi.container.servlet.ServletContainer.initiate(ServletContainer.java:509)
at com.sun.jersey.spi.container.servlet.ServletContainer$InternalWebComponent.initiate(ServletContainer.java:339)
at com.sun.jersey.spi.container.servlet.WebComponent.load(WebComponent.java:605)
at com.sun.jersey.spi.container.servlet.WebComponent.init(WebComponent.java:207)
at com.sun.jersey.spi.container.servlet.ServletContainer.init(ServletContainer.java:394)
at com.sun.jersey.spi.container.servlet.ServletContainer.init(ServletContainer.java:577)
at javax.servlet.GenericServlet.init(GenericServlet.java:161)
at com.ibm.ws.webcontainer.servlet.ServletWrapper.init(ServletWrapper.java:329)
... 85 more





[JERSEY-605] Extract some interfaces and create new extensions points for Jersey Created: 22/Nov/10  Updated: 08/Aug/13  Resolved: 08/Aug/13

Status: Resolved
Project: jersey
Component/s: core
Affects Version/s: None
Fix Version/s: 1.17

Type: Improvement Priority: Major
Reporter: guilhermesilveira Assignee: Pavel Bucek
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

all


Attachments: Text File internal_support.patch     File internal_support_with_dispatcher_factory.diff    
Tags: extension, framework, refactor

 Description   

Allows Jersey to be used as a component within other frameworks. By creating a few extra extensions points (extracing interfaces and changing a few method signatures from private to protected) allows someone to extend Jersey and provide its own components in a servlet enviroment.



 Comments   
Comment by sandoz [ 26/Nov/10 ]

Can you give an example of how VRaptor is using these extensions so i get a better understanding of how they are applied?

Comment by sandoz [ 26/Nov/10 ]

A bit more context to the above question. Some of the changes are in impl classes that should not be used by developers i.e. the class definitions can change at any time. So for the cases where you are depending on impl classes, e.g. ContextProvider or JerseyServletContainerInitializer, we should try and refactor things appropriately.

Comment by guilhermesilveira [ 26/Nov/10 ]

Hi Paul,

Here is the code that uses the extensions:

The extracted RequestUriParser is used here to use the same uri parsing patterns from Jersey:
https://github.com/caelum/vraptor/blob/jersey/vraptor-core/src/main/java/br/com/caelum/vraptor/jersey/DefaultJersey.java

The extracted DispatcherFactory interface is used here in order to create a new layer to delegate to Jersey:
https://github.com/caelum/vraptor/blob/jersey/vraptor-core/src/main/java/br/com/caelum/vraptor/jersey/VRaptorResourceConfig.java
I wasn't able to just register another DispatchProvider because the DispatcherProvider would need to delegate to the real dispatch provider whenever needed, so FakeMethodDispatchProvider will sometimes execute just part of the flow, while other parts it will delegate to the official DispatchProvider registered (returning that it cant handle it).

Comment by sandoz [ 26/Nov/10 ]

OK i understand a little better now.

The patch you added is missing the DispatcherFactory and modifications to WebApplicationImpl

Comment by guilhermesilveira [ 29/Nov/10 ]

Sorry, my bad. Now I've added those changes to the diff.

Comment by sandoz [ 29/Nov/10 ]

Thanks.

I think we can simplify things a little. I noticed that ResourceMethodDispatcherFactory.getDispatchers() is not used. Thus we do not require a new interface DispatcherFactory and instead can reuse ResourceMethodDispatchProvider (with appropriate changes to JavaDoc).

I think we may be able sort this out so that only SPI/API classes are used for the above.

Some more questions.

Are you using or plan to use the interface BasicComponent or the class JerseyServletContainerInitializer? Also are you using ContextProvider?

I do not see any of the above being used in the modified vraptor code you sent a link to, but i could of missed it.

Just trying to work out the set of minimum changes necessary.

Comment by guilhermesilveira [ 30/Nov/10 ]

Hi Paul! Great... there is just one of those 4 changes you mentioned it seems like I need.

You are right, the getDispatchers is not used anymore. But I use the interface so I can create my own dispatch provider:
https://github.com/caelum/vraptor/blob/jersey/vraptor-core/src/main/java/br/com/caelum/vraptor/jersey/VRaptorResourceConfig.java#L54

What do you think?

The ContextProvider and BasicComponent are not used anymore (as with the getDispatchers method)... they were used at some point in the implementation, but I refactored to try not to mess with it... forgetting to remove the contextprovider (although I did not realize getDispatchers was not used any more).

Comment by sandoz [ 01/Dec/10 ]

I am going to commit something where by you can register an instance or class implementation of:

public interface ResourceMethodDispatchAdapter

{ ResourceMethodDispatchProvider adapt( ResourceMethodDispatchProvider provider); }

with the resource config. That will provide you with a way to adapt appropriately.

Comment by sandoz [ 01/Dec/10 ]

Resource adaptation is committed.

I have not committed the code you had for the RequestUriParser as it resulted in a regression. We can fix that for the next commit.

Comment by guilhermesilveira [ 13/Dec/10 ]

Hi Paul,

Can you point me to the test suite? Is it the one within the jersey-server project itself?

Regards

Comment by sandoz [ 13/Dec/10 ]

See the top-level module jersey-tests.





[JERSEY-604] NPE with void methods Created: 19/Nov/10  Updated: 08/Aug/13  Resolved: 08/Aug/13

Status: Resolved
Project: jersey
Component/s: core
Affects Version/s: 1.4
Fix Version/s: 1.17

Type: Bug Priority: Minor
Reporter: jameskpublic Assignee: Unassigned
Resolution: Cannot Reproduce Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

I mistakenly created a method with a return type of "void" and exposed it via a @Delete annotation.
I got a a NullPointerException as the framework attempted to find the parent class of the return type "void" which, of course, doesn't exist. If void is truely not allowed, then a a nice error message should be emitted.

IntrospectionModeller.workOutFieldsList(AbstractResource, boolean) line: 200
IntrospectionModeller.createResource(Class<?>) line: 113
WadlBuilder.generateResource(AbstractResource, String, Set<Class<?>>) line: 325
WadlBuilder.generateResource(AbstractResource, String) line: 268
WadlBuilder.generate(Set<AbstractResource>) line: 104
WadlApplicationContextImpl.getApplication() line: 76
WadlResource.<init>(WadlApplicationContext) line: 76
NativeConstructorAccessorImpl.newInstance0(Constructor, Object[]) line: not available [native method]
NativeConstructorAccessorImpl.newInstance(Object[]) line: 39
DelegatingConstructorAccessorImpl.newInstance(Object[]) line: 27
Constructor<T>.newInstance(Object...) line: 513
ResourceComponentConstructor._construct(HttpContext) line: 197
ResourceComponentConstructor.construct(HttpContext) line: 179
SingletonFactory$Singleton.init(AbstractResource) line: 137
WebApplicationImpl$9.f() line: 542
WebApplicationImpl$9.f() line: 540
Errors.processWithErrors(Closure<T>) line: 197
WebApplicationImpl.getResourceComponentProvider(Class) line: 540
WebApplicationImpl.initiateResource(Class) line: 615
RootResourceUriRules.initWadlResource() line: 215
RootResourceUriRules.<init>(WebApplicationImpl, ResourceConfig, WadlFactory, InjectableProviderFactory) line: 193
WebApplicationImpl._initiate(ResourceConfig, IoCComponentProviderFactory) line: 1182
WebApplicationImpl.access$600(WebApplicationImpl, ResourceConfig, IoCComponentProviderFactory) line: 161
WebApplicationImpl$12.f() line: 698
WebApplicationImpl$12.f() line: 695
Errors.processWithErrors(Closure<T>) line: 197
WebApplicationImpl.initiate(ResourceConfig, IoCComponentProviderFactory) line: 695
GuiceContainer.initiate(ResourceConfig, WebApplication) line: 118
ServletContainer$InternalWebComponent.initiate(ResourceConfig, WebApplication) line: 287
ServletContainer$InternalWebComponent(WebComponent).load() line: 587
ServletContainer$InternalWebComponent(WebComponent).init(WebConfig) line: 213
GuiceContainer(ServletContainer).init(WebConfig) line: 342
GuiceContainer(ServletContainer).init() line: 516
GuiceContainer(GenericServlet).init(ServletConfig) line: 241
ServletDefinition.init(ServletContext, Injector, Set<HttpServlet>) line: 83
ManagedServletPipeline.init(ServletContext, Injector) line: 84
ManagedFilterPipeline.initPipeline(ServletContext) line: 106
GuiceFilter.init(FilterConfig) line: 168
FilterHolder.doStart() line: 74
FilterHolder(AbstractLifeCycle).start() line: 55
ServletHandler.initialize() line: 668
ServletContextHandler.startContext() line: 204



 Comments   
Comment by sandoz [ 24/Nov/10 ]

I cannot reproduce.

Can you describe more about your environment and/or attach a maven project that reproduces the error?

Comment by jameskpublic [ 24/Nov/10 ]

Actually, I can't reproduce it anymore either, as I've made a bunch of changes since i reported the bug. I gave it a couple of tries, but the framework seems to handle the void return type gracefully. OK with me to close. I will refile if I get it again.

Comment by Pavel Bucek [ 25/Nov/10 ]

closing as cannot reproduce, feel free to reopen with a testcase.





Generated at Tue Apr 21 06:46:12 UTC 2015 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.