[JERSEY-1414] Bugs in SSE OutboundEventWriter Created: 07/Sep/12  Updated: 07/Sep/12  Resolved: 07/Sep/12

Status: Resolved
Project: jersey
Component/s: None
Affects Version/s: 2.0-m07
Fix Version/s: 2.0-m07, 2.0

Type: Bug Priority: Major
Reporter: Martin Matula Assignee: Martin Matula
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

OutboundEvent allows specifying media type and Java type of individual data that are being sent. However, when the OutboundEventWriter writes the events, it ignores this information and uses the SSE media type and OutboundEvent.class as java type when writing the event data.



 Comments   
Comment by Martin Matula [ 07/Sep/12 ]

Fixed: https://github.com/jersey/jersey/commit/1d6e15c1b4a42c04c6fbc3d923599ae6610702a9





Provide equivalent of ResourceContext from Jersey 1.x so that I am able to create managed instances of sub-resources, and match URI's to resources and UriInfo. (JERSEY-1087)

[JERSEY-1396] Implement support for match URI methods. Created: 29/Aug/12  Updated: 04/Sep/12  Resolved: 04/Sep/12

Status: Resolved
Project: jersey
Component/s: None
Affects Version/s: None
Fix Version/s: 2.0-m07, 2.0

Type: Sub-task Priority: Blocker
Reporter: Marek Potociar Assignee: Marek Potociar
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: 0 minutes
Time Spent: 1 minute
Original Estimate: 6 hours





Provide equivalent of ResourceContext from Jersey 1.x so that I am able to create managed instances of sub-resources, and match URI's to resources and UriInfo. (JERSEY-1087)

[JERSEY-1395] Implement support for getResource() method. Created: 29/Aug/12  Updated: 03/Sep/12  Resolved: 03/Sep/12

Status: Resolved
Project: jersey
Component/s: None
Affects Version/s: None
Fix Version/s: 2.0-m07, 2.0

Type: Sub-task Priority: Blocker
Reporter: Marek Potociar Assignee: Marek Potociar
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: 0 minutes
Time Spent: 11 hours
Original Estimate: 6 hours





[JERSEY-1394] Update to new HK2 API, reimplement Injectee using new HK2 abstract class. Created: 29/Aug/12  Updated: 04/Sep/12  Resolved: 29/Aug/12

Status: Resolved
Project: jersey
Component/s: None
Affects Version/s: None
Fix Version/s: 2.0-m07, 2.0

Type: Task Priority: Blocker
Reporter: Marek Potociar Assignee: Marek Potociar
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: 0 minutes
Time Spent: 1 hour, 30 minutes
Original Estimate: 2 hours





[JERSEY-1393] Switch to the latest JAX-RS API milestone bits. Created: 28/Aug/12  Updated: 04/Sep/12  Resolved: 29/Aug/12

Status: Resolved
Project: jersey
Component/s: None
Affects Version/s: None
Fix Version/s: 2.0-m07, 2.0

Type: Task Priority: Blocker
Reporter: Marek Potociar Assignee: Marek Potociar
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: 0 minutes
Time Spent: 5 hours
Original Estimate: 6 hours





[JERSEY-1391] Add WADL support Created: 27/Aug/12  Updated: 04/Sep/12  Resolved: 04/Sep/12

Status: Resolved
Project: jersey
Component/s: None
Affects Version/s: None
Fix Version/s: 2.0-m07, 2.0

Type: New Feature Priority: Blocker
Reporter: Pavel Bucek Assignee: Pavel Bucek
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: 0 minutes
Time Spent: 1 day
Original Estimate: Not Specified





[JERSEY-1388] Broken API documentation links on Jersey web site. Created: 22/Aug/12  Updated: 04/Sep/12  Resolved: 24/Aug/12

Status: Resolved
Project: jersey
Component/s: None
Affects Version/s: None
Fix Version/s: 2.0-m07, 2.0

Type: Bug Priority: Critical
Reporter: Marek Potociar Assignee: Unassigned
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: 0 minutes
Time Spent: 1 hour
Original Estimate: Not Specified


 Description   

The links to latest API docs for various extension modules are broken.






[JERSEY-1387] Migration guide update Created: 22/Aug/12  Updated: 04/Sep/12  Resolved: 04/Sep/12

Status: Resolved
Project: jersey
Component/s: None
Affects Version/s: None
Fix Version/s: 2.0-m07, 2.0

Type: Task Priority: Minor
Reporter: Pavel Bucek Assignee: Pavel Bucek
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: 0 minutes
Time Spent: 1 hour
Original Estimate: Not Specified


 Description   

migration guide is deprecated (custom injection changes, Target -> WebTarget)






[JERSEY-1378] Link.Builder#uri(String) does not throw exception either Created: 10/Aug/12  Updated: 20/Aug/12  Resolved: 20/Aug/12

Status: Resolved
Project: jersey
Component/s: core
Affects Version/s: 2.0-m06
Fix Version/s: 2.0-m07, 2.0

Type: Bug Priority: Major
Reporter: jan.supol Assignee: Marek Potociar
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: 0 minutes
Time Spent: 3 hours
Original Estimate: 3 hours

Issue Links:
Related
is related to JERSEY-1324 UriBuilder#uri(String) does not throw... Resolved

 Description   
new Link.Builder().uri("aa bb");

does not throw any exception. The exception is called when build is called

new Link.Builder().uri("aa bb").build();

But javadoc to Link.Builder#uri says:

Throws:
IllegalArgumentException - if string representation of URI is invalid



 Comments   
Comment by Marek Potociar [ 17/Aug/12 ]

This is really a JAX-RS issue. Moving to proper project.

Comment by Marek Potociar [ 17/Aug/12 ]

After more investigation, this is actually a Jersey impl. issue. Moving back.





[JERSEY-1364] Investigate performance issues reported by GF monitoring team. Created: 13/Aug/12  Updated: 04/Sep/12  Resolved: 13/Aug/12

Status: Resolved
Project: jersey
Component/s: core
Affects Version/s: None
Fix Version/s: 2.0-m07, 2.0

Type: Task Priority: Blocker
Reporter: Marek Potociar Assignee: Marek Potociar
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: 0 minutes
Time Spent: 4 hours
Original Estimate: Not Specified





[JERSEY-1360] Make OSGi javax.annotation.security dependency in core-server optional. Created: 10/Aug/12  Updated: 04/Sep/12  Resolved: 10/Aug/12

Status: Resolved
Project: jersey
Component/s: None
Affects Version/s: None
Fix Version/s: 2.0-m07, 2.0

Type: Task Priority: Critical
Reporter: Marek Potociar Assignee: Marek Potociar
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: 0 minutes
Time Spent: 3 hours
Original Estimate: Not Specified





[JERSEY-1356] Client#invocation(Link, Entity) checks for Consumes, but throws "Incompatible with link produces" message Created: 10/Aug/12  Updated: 16/Aug/12  Resolved: 16/Aug/12

Status: Resolved
Project: jersey
Component/s: core
Affects Version/s: 2.0-m06
Fix Version/s: 2.0-m07, 2.0

Type: Bug Priority: Major
Reporter: jan.supol Assignee: Marek Potociar
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: 0 minutes
Time Spent: 1 minute
Original Estimate: 3 hours

Issue Links:
Related
is related to JERSEY-1192 Client#invocation(Link, (Entity)null)... Resolved

 Description   

invocation(Link, Entity) does

boolean isCompatible = false;
for (String mt : link.getConsumes())
  if (entity.getMediaType().isCompatible(MediaType.valueOf(mt))) {
    isCompatible = true;
    break;
  }
if (!isCompatible)
  throw new IllegalArgumentException("Entity type incompatible with link produces parameter");

which clashes getConsumes() and "produces"



 Comments   
Comment by Marek Potociar [ 16/Aug/12 ]

Updated JAX-RS Client API javadoc. Otherwise works as designed.





[JERSEY-1354] Release Jersey 2.0-m06 Created: 10/Aug/12  Updated: 10/Aug/12  Resolved: 10/Aug/12

Status: Resolved
Project: jersey
Component/s: None
Affects Version/s: None
Fix Version/s: 2.0-m07, 2.0

Type: Task Priority: Blocker
Reporter: Marek Potociar Assignee: Marek Potociar
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: 0 minutes
Time Spent: 3 hours
Original Estimate: 3 hours





[JERSEY-1353] Passing invocation callback to the Jersey client async API causes NPE. Created: 10/Aug/12  Updated: 04/Sep/12  Resolved: 10/Aug/12

Status: Resolved
Project: jersey
Component/s: None
Affects Version/s: None
Fix Version/s: 2.0-m07, 2.0

Type: Bug Priority: Blocker
Reporter: Marek Potociar Assignee: Marek Potociar
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: 0 minutes
Time Spent: 1 hour
Original Estimate: Not Specified





[JERSEY-1352] @PathParam("foo") injection doesn't work on a method parameter if the parameter has other annotations in the bytecode (and another annotation is after @PathParam) Created: 09/Aug/12  Updated: 04/Nov/13  Resolved: 15/Aug/12

Status: Resolved
Project: jersey
Component/s: core
Affects Version/s: 1.13, 2.0-m06
Fix Version/s: 1.14, 2.0-m07

Type: Bug Priority: Major
Reporter: jstrachan Assignee: Martin Matula
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Duplicate
duplicates JERSEY-787 Custom annotation retrieve the parame... Resolved
Related
is related to JERSEY-1334 javax.annotation.Nonnull annotation i... Resolved

 Description   

I've created a test case and a patch to fix it - here's the pull request:
https://github.com/jersey/jersey/pull/5

running the new test case without the patch demonstrates the issue.

Its a minor bug in a for loop really; despite finding @PathParam, because there is another unknown annotation, the code forgets that it ever found @PathParam. It should overwrite the found annotation variables.

We should back port the trivial fix to 1.x too really.

As an aside, I hit this bug when I started using Kotlin to compile JAXRS resources; since it generates an annotation on each parameter too (with the parameter name) which then breaks JAXRS @PathParam in Jersey on method parameter injection (though field injection works fine).



 Comments   
Comment by jstrachan [ 09/Aug/12 ]

I've just patched the 1.x code in svn using commit rev: 5760. Just need the pull request for the 2.x codebase

Comment by Martin Matula [ 09/Aug/12 ]

Looks like a duplicate of JERSEY-1334. Thanks for the patch!

Comment by Marek Potociar [ 10/Aug/12 ]

Martin - is this fixed then? Can the issue be closed?

Comment by jstrachan [ 14/Aug/12 ]

Marek - the issue can be closed once we've applied the pull request to the 2.x branch
https://github.com/jersey/jersey/pull/5

Comment by jstrachan [ 15/Aug/12 ]

fixed both in 1.x and 2.x branches now





[JERSEY-1349] Evaluation of GLASSFISH-18975 Created: 07/Aug/12  Updated: 04/Sep/12  Resolved: 04/Sep/12

Status: Resolved
Project: jersey
Component/s: osgi
Affects Version/s: 2.0-m06
Fix Version/s: 2.0-m07, 2.0

Type: Task Priority: Major
Reporter: Pavel Bucek Assignee: Jakub Podlesak
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: 0 minutes
Time Spent: 23 hours
Original Estimate: Not Specified


 Description   

Quicklook (running on equinox) failures after recent Jersey integration http://java.net/jira/browse/GLASSFISH-18975






[JERSEY-1347] QualitySourceMediaType.equals/hashCode is asymmetric wrt. JAX-RS MediaType Created: 06/Aug/12  Updated: 17/Aug/12  Resolved: 17/Aug/12

Status: Resolved
Project: jersey
Component/s: core
Affects Version/s: None
Fix Version/s: 2.0-m07, 2.0

Type: Bug Priority: Blocker
Reporter: Marek Potociar Assignee: Marek Potociar
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: 0 minutes
Time Spent: 2 hours
Original Estimate: 3 hours





[JERSEY-1344] Find all Jersey pre-matching filters and add @PreMatching annotation to them. Created: 06/Aug/12  Updated: 03/Sep/12  Resolved: 03/Sep/12

Status: Resolved
Project: jersey
Component/s: None
Affects Version/s: None
Fix Version/s: 2.0-m07, 2.0

Type: Task Priority: Blocker
Reporter: Marek Potociar Assignee: Marek Potociar
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: 0 minutes
Time Spent: 3 hours
Original Estimate: 3 hours





[JERSEY-1341] Problem using JerseyClient to sent a empty string parameter Created: 03/Aug/12  Updated: 10/Aug/12  Resolved: 10/Aug/12

Status: Resolved
Project: jersey
Component/s: core
Affects Version/s: 1.12
Fix Version/s: 2.0-m07, 2.0

Type: Bug Priority: Critical
Reporter: rblanco.cr Assignee: Martin Matula
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Jersey 1.12



 Description   

Hey guys,

I have an issue when I try to sent a empty string using jersey-client
lib, when jersey generate the request strip the = sign when the value
is an empty string.

For example:
Jersey generate something like (value is the empty string, the equals
is lost and I get a 500 error):
http://myservice.test.com/services/rest/setAttribute?id=555&value&test=test

If I go to the browser an enter (this one works!!!):
http://myservice.test.com/services/rest/setAttribute?id=555&value=&test=test

I did a quick research in your code and seems that I get the line that
is causing the bug. Also, I read something about this on
http://tools.ietf.org/html/rfc3986#section-3.4 the equals is not optional it should be there.

The bug is in jersey-core 1.13, line 480 (it should be >= instead of >)
if (stringValue.length() > 0)

{ query.append('=').append(encode(stringValue, UriComponent.Type.QUERY_PARAM)); }




[JERSEY-1334] javax.annotation.Nonnull annotation in a resource method leads to error on application startup Created: 02/Aug/12  Updated: 15/Aug/12  Resolved: 15/Aug/12

Status: Resolved
Project: jersey
Component/s: None
Affects Version/s: 1.12, 1.13
Fix Version/s: 1.14, 2.0-m07, 2.0

Type: Bug Priority: Major
Reporter: christof.doll Assignee: Martin Matula
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: 0 minutes
Time Spent: 1 minute
Original Estimate: 1 hour
Environment:

Win 7, Tomcat 7


Issue Links:
Related
is related to JERSEY-1352 @PathParam("foo") injection doesn't w... Resolved

 Description   

In my project I have the following resource:

@GET
@Path("

{id}")
@Nonnull
@Produces(value = "text/html;charset=UTF-8")
public Response renderKanbanBoard(@PathParam("id") @Nonnull Long projectId,
@NonNls @QueryParam("format") @Nonnull String format,
@QueryParam("filters") @Nonnull FilterItemsDto filterItems)


This method leads to the following error upon startup:

SEVERE: Missing dependency for method public javax.ws.rs.core.Response de.fortis.dagiweb.resources.KanbanBoardResource.renderKanbanBoard(java.lang.Long,java.lang.String,de.fortis.dagiweb.dtos.FilterItemsDto) at parameter at index 0
SEVERE: Missing dependency for method public javax.ws.rs.core.Response de.fortis.dagiweb.resources.KanbanBoardResource.renderKanbanBoard(java.lang.Long,java.lang.String,de.fortis.dagiweb.dtos.FilterItemsDto) at parameter at index 1
SEVERE: Missing dependency for method public javax.ws.rs.core.Response de.fortis.dagiweb.resources.KanbanBoardResource.renderKanbanBoard(java.lang.Long,java.lang.String,de.fortis.dagiweb.dtos.FilterItemsDto) at parameter at index 2
SEVERE: Method, public javax.ws.rs.core.Response de.fortis.dagiweb.resources.KanbanBoardResource.renderKanbanBoard(java.lang.Long,java.lang.String,de.fortis.dagiweb.dtos.FilterItemsDto), annotated with GET of resource, class de.fortis.dagiweb.resources.KanbanBoardResource, is not recognized as valid resource method.

However, changing the ordering of the parameter annotations such that Nonnull is before *Param solves the problem:

@GET
@Path("{id}

")
@Nonnull
@Produces(value = "text/html;charset=UTF-8")
public Response renderKanbanBoard(@Nonnull @PathParam("id") Long projectId,
@Nonnull @NonNls @QueryParam("format") String format,
@Nonnull @QueryParam("filters") FilterItemsDto filterItems)

The problem is in the for loop of IntrospectionModeller.createParameter:

for (Annotation annotation : annotations) {
if (ANOT_HELPER_MAP.containsKey(annotation.annotationType()))

{ ParamAnnotationHelper helper = ANOT_HELPER_MAP.get(annotation.annotationType()); paramAnnotation = annotation; paramSource = helper.getSource(); paramName = helper.getValueOf(annotation); }

else if (Encoded.class == annotation.annotationType())

{ paramEncoded = true; }

else if (DefaultValue.class == annotation.annotationType())

{ paramDefault = ((DefaultValue) annotation).value(); }

else

{ paramAnnotation = annotation; paramSource = Source.UNKNOWN; paramName = getValue(annotation); }

}

Instead of the last else it should be

} else if(paramSource == null || paramSource == Source.UNKNOWN) {



 Comments   
Comment by jstrachan [ 14/Aug/12 ]

I think JERSEY-1352 fixes this issue (so its fixed in 1.x and the pull request fixes it in 2.x too)

Comment by jstrachan [ 15/Aug/12 ]

fixed both in 1.x and 2.x branches now





[JERSEY-1333] Accept/produces does not work as expected Created: 02/Aug/12  Updated: 03/Sep/12  Resolved: 03/Sep/12

Status: Resolved
Project: jersey
Component/s: core
Affects Version/s: 2.0-m05
Fix Version/s: 2.0-m07, 2.0

Type: Bug Priority: Blocker
Reporter: jan.supol Assignee: Michal Gajdos
Resolution: Cannot Reproduce Votes: 0
Labels: None
Remaining Estimate: 0 minutes
Time Spent: 30 minutes
Original Estimate: 3 hours


 Description   

Suppose a resource:

@Path(value = "resource")
public class Resource {
	@GET
	public Response getPlain() {
		return Response.ok("text/plain")
				.header("HEAD", "text-plain").build();
	}

	@GET
	@Produces(value = "text/html")
	public Response getHtml() {
		return Response.ok("<html></html>).header("HEAD", "text-html")
				.build();
	}
}

and client request:

"GET http://localhost:8080/jaxrs_get/resource/ HTTP/1.1"
"Accept: text/plain"

the response is:

<html></html>






[JERSEY-1328] Link.Builder#param does not count spaces as delimiter Created: 01/Aug/12  Updated: 29/May/13  Resolved: 03/Sep/12

Status: Resolved
Project: jersey
Component/s: core
Affects Version/s: 2.0-m05
Fix Version/s: 2.0-m07, 2.0

Type: Bug Priority: Major
Reporter: jan.supol Assignee: Miroslav Fuksa
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: 0 minutes
Time Spent: 30 minutes
Original Estimate: 3 hours


 Description   

javadoc of Link.Builder#param says:

This method supports adding more than one value for each parameter using one or more whitespace delimiters.

But

Link.Builder builder = new Link.Builder().uri(url());
builder = builder.param("param1", "param1value1    param1value2");
Link link = builder.build();
MultivaluedMap<String, String> map = link.getParams();
System.out.println(map);

returns

{param2=[param1value1 param1value2]}



 Comments   
Comment by jan.supol [ 02/Aug/12 ]

The same for consumes/ produces

Comment by Miroslav Fuksa [ 03/Sep/12 ]

I have discussed that with Jan and we found out that the specification has changed. The method params is replaced by param which does not accept delimiters. produces and consumes are not there either and new method type does not accept delimiters. I have added small test checking that delimiters do not work.

Comment by Miroslav Fuksa [ 03/Sep/12 ]

I have discussed that with Jan and we found out that the specification has changed. The method params is replaced by param which does not accept delimiters. produces and consumes are not there either and new method type does not accept delimiters. I have added small test checking that delimiters do not work.





[JERSEY-1324] UriBuilder#uri(String) does not throw IllegalArgumentException Created: 01/Aug/12  Updated: 09/Oct/12  Resolved: 20/Aug/12

Status: Resolved
Project: jersey
Component/s: core
Affects Version/s: 2.0-m05
Fix Version/s: 2.0-m07, 2.0

Type: Bug Priority: Major
Reporter: jan.supol Assignee: Marek Potociar
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: 0 minutes
Time Spent: 3 hours
Original Estimate: 3 hours

Issue Links:
Related
is related to JERSEY-1378 Link.Builder#uri(String) does not thr... Resolved

 Description   

javadoc UriBuilder#uri says:

Throws:
IllegalArgumentException - if uriTemplate is not a valid URI template

but

String sUri = "http ftp xml//:888:888/1:8080:80";
UriBuilder.fromMethod(Resource.class, "sub").uri(sUri); //does not throw any exception
new URI(sUri); //throws URISyntaxException


 Comments   
Comment by jan.supol [ 09/Oct/12 ]

The fix is not working. It's still doing the same.





[JERSEY-1315] Path under OSGi is variable depending on context alias Created: 25/Jul/12  Updated: 21/Aug/12  Resolved: 21/Aug/12

Status: Closed
Project: jersey
Component/s: osgi
Affects Version/s: 1.13
Fix Version/s: 2.0-m07

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

Mac OSX 10.7 JDK 1.6 Karaf 3.x (Felix)



 Description   

When deploying under Karaf using the "http" feature, resources present themselves differently depending on whether the context is "/" or not.

For instance, with a resource referenced by @Path("status"), if the context registered in the activator is "/test", the resource is available as "http://localhost:8181/test/status". But if the context is changed to "/", the resource should be available as "http://localhost:8181/test/status", but it is not. It is only available as "http://localhost:8181/test/status/" (note the trailing slash).

There's something wrong in the path to AtomicMatchingPatterns.java, but I didn't dig deeply enough to figure out exactly what it was.

Here's my bundle set:

karaf@root()> list -s -t 0
START LEVEL 100 , List Threshold: 0
ID State Level Symbolic name
[ 0] [ Active] [ 0] org.apache.felix.framework (4.0.2)
[ 1] [ Active] [ 8] org.ops4j.pax.logging.pax-logging-service (1.6.9)
[ 2] [ Active] [ 30] org.apache.karaf.bundle.core (3.0.0.SNAPSHOT)
[ 3] [ Active] [ 26] org.apache.karaf.deployer.features (3.0.0.SNAPSHOT)
[ 4] [ Active] [ 30] org.apache.karaf.shell.commands (3.0.0.SNAPSHOT)
[ 5] [ Active] [ 24] org.apache.karaf.deployer.blueprint (3.0.0.SNAPSHOT)
[ 6] [ Active] [ 10] org.apache.felix.configadmin (1.4.0)
[ 7] [ Active] [ 30] org.apache.karaf.system.core (3.0.0.SNAPSHOT)
[ 8] [ Active] [ 25] org.apache.karaf.features.core (3.0.0.SNAPSHOT)
[ 9] [ Active] [ 20] org.apache.aries.blueprint.api (1.0.0.SNAPSHOT)
[ 10] [ Active] [ 30] org.apache.karaf.shell.table (3.0.0.SNAPSHOT)
[ 11] [ Active] [ 30] org.ops4j.pax.url.commons (1.4.3.SNAPSHOT)
[ 12] [ Active] [ 25] org.apache.karaf.region.core (3.0.0.SNAPSHOT)
[ 13] [ Active] [ 30] org.ops4j.base.util.collections (1.3.0)
[ 14] [ Active] [ 30] org.apache.karaf.jaas.boot (3.0.0.SNAPSHOT)
[ 15] [ Active] [ 30] org.ops4j.base.util.property (1.3.0)
[ 16] [ Active] [ 11] org.apache.felix.fileinstall (3.2.4)
[ 17] [ Active] [ 8] org.ops4j.pax.logging.pax-logging-api (1.6.9)
[ 18] [ Active] [ 30] org.apache.karaf.jaas.config (3.0.0.SNAPSHOT)
[ 19] [ Active] [ 5] org.ops4j.pax.url.maven.commons (1.4.3.SNAPSHOT)
[ 20] [ Active] [ 30] org.apache.karaf.bundle.command (3.0.0.SNAPSHOT)
[ 21] [ Active] [ 30] org.apache.karaf.features.command (3.0.0.SNAPSHOT)
[ 22] [ Active] [ 30] org.apache.mina.core (2.0.4)
[ 23] [ Active] [ 20] org.apache.aries.proxy.impl (1.0.0.SNAPSHOT)
[ 24] [ Active] [ 30] org.apache.sshd.core (0.7.0)
[ 25] [ Active] [ 30] org.ops4j.base.util.xml (1.3.0)
[ 26] [ Active] [ 24] org.apache.karaf.deployer.wrap (3.0.0.SNAPSHOT)
[ 27] [ Active] [ 20] org.apache.aries.util (1.0.0.SNAPSHOT)
[ 28] [ Active] [ 5] org.ops4j.pax.swissbox.pax-swissbox-bnd (1.5.1)
[ 29] [ Active] [ 5] biz.aQute.bndlib (1.50.0)
[ 30] [ Active] [ 5] org.ops4j.pax.url.wrap (1.4.3.SNAPSHOT)
[ 31] [ Active] [ 30] org.ops4j.base.net (1.3.0)
[ 32] [ Active] [ 5] org.apache.servicemix.bundles.junit (3.8.2.4)
[ 33] [ Active] [ 20] org.apache.aries.blueprint.core (1.0.0.SNAPSHOT), Fragments: 34
[ 34] [ Resolved] [ 20] org.apache.aries.blueprint.core.compatibility (1.0.0.SNAPSHOT), Hosts: 33
[ 35] [ Active] [ 20] org.apache.aries.proxy.api (1.0.0.SNAPSHOT)
[ 36] [ Active] [ 30] org.apache.karaf.jaas.modules (3.0.0.SNAPSHOT)
[ 37] [ Active] [ 30] org.apache.karaf.shell.console (3.0.0.SNAPSHOT)
[ 38] [ Active] [ 5] org.ops4j.pax.url.mvn (1.4.3.SNAPSHOT)
[ 39] [ Active] [ 30] org.ops4j.base.monitors (1.3.0)
[ 40] [ Active] [ 12] org.objectweb.asm.all (4.0)
[ 41] [ Active] [ 30] org.ops4j.pax.swissbox.property (1.5.0)
[ 42] [ Active] [ 30] org.apache.karaf.shell.help (3.0.0.SNAPSHOT)
[ 43] [ Active] [ 20] org.apache.aries.blueprint.cm (1.0.0.SNAPSHOT)
[ 44] [ Active] [ 5] org.ops4j.base.lang (1.3.0)
[ 45] [ Active] [ 30] org.apache.karaf.system.command (3.0.0.SNAPSHOT)
[ 46] [ Active] [ 24] org.apache.karaf.deployer.spring (3.0.0.SNAPSHOT)
[ 47] [ Active] [ 30] org.apache.aries.quiesce.api (1.0.1.SNAPSHOT)
[ 48] [ Active] [ 30] org.apache.karaf.config.core (3.0.0.SNAPSHOT)
[ 49] [ Active] [ 30] org.apache.karaf.config.command (3.0.0.SNAPSHOT)
[ 50] [ Active] [ 30] org.apache.karaf.instance.core (3.0.0.SNAPSHOT)
[ 51] [ Active] [ 30] org.apache.karaf.instance.command (3.0.0.SNAPSHOT)
[ 52] [ Active] [ 30] org.apache.karaf.jaas.command (3.0.0.SNAPSHOT)
[ 53] [ Active] [ 30] org.apache.karaf.diagnostic.core (3.0.0.SNAPSHOT)
[ 54] [ Active] [ 30] org.apache.karaf.diagnostic.command (3.0.0.SNAPSHOT)
[ 55] [ Active] [ 30] org.apache.karaf.log.core (3.0.0.SNAPSHOT)
[ 56] [ Active] [ 30] org.apache.karaf.log.command (3.0.0.SNAPSHOT)
[ 57] [ Active] [ 30] org.apache.karaf.service.core (3.0.0.SNAPSHOT)
[ 58] [ Active] [ 30] org.apache.karaf.service.command (3.0.0.SNAPSHOT)
[ 59] [ Active] [ 30] org.apache.karaf.dev.core (3.0.0.SNAPSHOT)
[ 60] [ Active] [ 30] org.apache.karaf.dev.command (3.0.0.SNAPSHOT)
[ 61] [ Active] [ 30] org.eclipse.equinox.region (1.0.0.v20110524)
[ 62] [ Active] [ 30] org.apache.karaf.region.persist (3.0.0.SNAPSHOT)
[ 63] [ Active] [ 30] org.apache.karaf.region.command (3.0.0.SNAPSHOT)
[ 64] [ Active] [ 30] org.apache.karaf.package.core (3.0.0.SNAPSHOT)
[ 65] [ Active] [ 30] org.apache.karaf.package.command (3.0.0.SNAPSHOT)
[ 66] [ Active] [ 30] org.apache.karaf.kar.core (3.0.0.SNAPSHOT)
[ 67] [ Active] [ 30] org.apache.karaf.kar.command (3.0.0.SNAPSHOT)
[ 68] [ Active] [ 30] org.apache.karaf.deployer.kar (3.0.0.SNAPSHOT)
[ 69] [ Active] [ 30] org.apache.karaf.shell.ssh (3.0.0.SNAPSHOT)
[ 70] [ Active] [ 30] org.apache.karaf.management.server (3.0.0.SNAPSHOT)
[ 71] [ Active] [ 30] org.apache.aries.jmx.api (1.0.0.SNAPSHOT)
[ 72] [ Active] [ 30] org.apache.aries.jmx.core (1.0.0.SNAPSHOT)
[ 73] [ Active] [ 30] org.apache.aries.jmx.blueprint.api (1.0.0.SNAPSHOT)
[ 74] [ Active] [ 30] org.apache.aries.jmx.blueprint.core (1.0.0.SNAPSHOT)
[ 75] [ Active] [ 30] org.apache.aries.jmx.whiteboard (1.0.0.SNAPSHOT)
[ 76] [ Active] [ 30] org.apache.felix.eventadmin (1.2.14)
[ 77] [ Active] [ 30] org.apache.servicemix.specs.activation-api-1.1 (2.0.0)
[ 78] [ Active] [ 30] org.apache.geronimo.specs.geronimo-servlet_3.0_spec (1.0)
[ 79] [ Active] [ 30] javax.mail (1.4.4)
[ 80] [ Active] [ 30] org.apache.geronimo.specs.geronimo-jta_1.1_spec (1.1.1)
[ 81] [ Active] [ 30] org.apache.geronimo.specs.geronimo-annotation_1.1_spec (1.0.1)
[ 82] [ Active] [ 30] org.apache.geronimo.specs.geronimo-jaspic_1.0_spec (1.1)
[ 83] [ Active] [ 30] org.eclipse.jetty.aggregate.jetty-all-server (8.1.4.v20120524)
[ 84] [ Active] [ 30] org.ops4j.pax.web.pax-web-api (2.0.0)
[ 85] [ Active] [ 30] org.ops4j.pax.web.pax-web-spi (2.0.0)
[ 86] [ Active] [ 30] org.ops4j.pax.web.pax-web-runtime (2.0.0)
[ 87] [ Active] [ 30] org.ops4j.pax.web.pax-web-jetty (2.0.0)
[ 88] [ Active] [ 30] org.apache.karaf.http.core (3.0.0.SNAPSHOT)
[ 89] [ Active] [ 30] org.apache.karaf.http.command (3.0.0.SNAPSHOT)
[ 90] [ Active] [ 80] net.mauswerks.extjs-trial.trial-web (1.0.0.SNAPSHOT)
[ 91] [ Active] [ 80] com.sun.jersey.core (1.13.0)
[ 92] [ Active] [ 80] com.sun.jersey.jersey-server (1.13.0)
[ 93] [ Active] [ 80] com.sun.jersey.json (1.13.0)
[ 94] [ Active] [ 80] com.sun.jersey.servlet (1.13.0)
[ 95] [ Active] [ 80] javax.ws.rs.jsr311-api (1.1.1)
[ 96] [ Active] [ 80] jackson-core-asl (1.9.5)
[ 97] [ Active] [ 80] jackson-jaxrs (1.9.5)
[ 98] [ Active] [ 80] jackson-mapper-asl (1.9.5)
[ 99] [ Active] [ 80] org.codehaus.jettison.jettison (1.1)



 Comments   
Comment by Brian Topping [ 25/Jul/12 ]

Meh, I botched the description and don't have edit rights on my own issues.

It should read as follows:

For instance, with a resource referenced by @Path("status"), if the context registered in the activator is "/test", the resource is available as "http://localhost:8181/test/status". But if the context is changed to "/", the resource should be available as "http://localhost:8181/status", but it is not. It is only available as "http://localhost:8181/status/" (note the trailing slash).

Comment by Jakub Podlesak [ 02/Aug/12 ]

I am not familiar with Karaf "http" feature, could you please provide a reproducible test application, or at least some steps to reproduce?

Comment by Jakub Podlesak [ 21/Aug/12 ]

I was able to reproduce the bug with vanilla OSGi HttpService feature on Jetty and Felix using the Jersey 1.13 osgi-http-service sample.
The same worked fine for me with Jersey 2 snapshot. So the problem seems fixed in Jersey 2. Going to close the bug as fixed in Jersey 2.
Please feel free to re-open if you have any objection.

Comment by Jakub Podlesak [ 21/Aug/12 ]

Can not reproduce with Jersey 2. See the above comment for details.

Comment by Brian Topping [ 21/Aug/12 ]

That's great Jason! Hope that it was worthwhile to check this out, thanks for all your work!





[JERSEY-1310] Migrate MVC support from Jersey 1.x Created: 25/Jul/12  Updated: 04/Sep/12  Resolved: 04/Sep/12

Status: Resolved
Project: jersey
Component/s: None
Affects Version/s: None
Fix Version/s: 2.0-m07, 2.0

Type: New Feature Priority: Blocker
Reporter: Martin Matula 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-1390 Add support for MVC pattern - port su... Resolved

 Comments   
Comment by Pavel Bucek [ 04/Sep/12 ]

JERSEY-1390





[JERSEY-1295] Response#bufferEntity does not throw MessageProcessingException - if there was an error while buffering the entity input stream. Created: 19/Jul/12  Updated: 03/Sep/12  Resolved: 03/Sep/12

Status: Resolved
Project: jersey
Component/s: core
Affects Version/s: 2.0-m06
Fix Version/s: 2.0-m07, 2.0

Type: Bug Priority: Major
Reporter: jan.supol Assignee: Michal Gajdos
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: 0 minutes
Time Spent: 1 hour
Original Estimate: 3 hours


 Description   

The Response#bufferEntity javadoc says:
throws
MessageProcessingException - if there was an error while buffering the entity input stream.
but having a resource

@Path("response")
public class Resource {
	public static final String ENTITY = "ENtiTy";
	@GET
	@Path("corrupted")
	public CorruptedInputStream corrupted(){
		return new CorruptedInputStream(ENTITY.getBytes());
	}
}

public class CorruptedInputStream extends ByteArrayInputStream {
	private boolean corrupted = false;
	public CorruptedInputStream(byte[] buf) {
		super(buf);
	}
	@Override
	public void close() throws IOException {
		if (corrupted)
			throw new IOException("CorruptedInputStream test IOException");
		else
			super.close();
	}
	public boolean isCorrupted() {
		return corrupted;
	}
	public void setCorrupted(boolean corrupted) {
		this.corrupted = corrupted;
	}
}

and client

		ClientResponseFilter filter = new ClientResponseFilter() {
			@Override
			public void filter(ClientRequestContext arg0,
					ClientResponseContext response) throws IOException {
				CorruptedInputStream cis = new CorruptedInputStream(Resource.ENTITY.getBytes());
				cis.setCorrupted(true);
				response.setEntityStream(cis);
			}
		};


Client client = ClientFactory.newClient();
client.configuration().register(filter);
WebTarget target = client.target(responseurl);
Response response = target.request().buildGet().invoke();
response.bufferEntity();

throws

19.7.2012 18:38:18 org.glassfish.jersey.message.internal.InboundMessageContext$ContentStream invalidateContentStream
SEVERE: Error closing message content input stream.
java.io.IOException: CorruptedInputStream test IOException
at CorruptedInputStream.close(CorruptedInputStream.java:23)
at org.glassfish.jersey.message.internal.InboundMessageContext$ContentStream.invalidateContentStream(InboundMessageContext.java:151)
at org.glassfish.jersey.message.internal.InboundMessageContext.bufferEntity(InboundMessageContext.java:934)
at org.glassfish.jersey.client.InboundJaxrsResponse.bufferEntity(InboundJaxrsResponse.java:128)

but no MessageProcessingException



 Comments   
Comment by jan.supol [ 19/Jul/12 ]

Actually, it doesn't throw it, it just writes it down. There would be something like catch (Exception e)

{e.printstackTrace();}

instead of throw new MessageprocessingException(e);





[JERSEY-1268] Implement support for resolution of JAX_RS_SPEC-195 issue. Created: 29/Jun/12  Updated: 04/Sep/12  Resolved: 04/Sep/12

Status: Resolved
Project: jersey
Component/s: None
Affects Version/s: None
Fix Version/s: 2.0-m07, 2.0

Type: Task Priority: Blocker
Reporter: Marek Potociar Assignee: Jakub Podlesak
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: 0 minutes
Time Spent: 10 hours
Original Estimate: 18 hours

Issue Links:
Related
is related to JAX_RS_SPEC-195 Introduce dedicated exception classes... Resolved




[JERSEY-1267] Implementation needs to be updated to accomodate spec changes based on JAX_RS_SPEC-187 resolution Created: 29/Jun/12  Updated: 04/Sep/12  Resolved: 04/Sep/12

Status: Resolved
Project: jersey
Component/s: None
Affects Version/s: None
Fix Version/s: 2.0-m07, 2.0

Type: Task Priority: Blocker
Reporter: Marek Potociar Assignee: Pavel Bucek
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: 0 minutes
Time Spent: 1 day, 1 hour
Original Estimate: 12 hours


 Comments   
Comment by Pavel Bucek [ 06/Aug/12 ]

including migration guide update

Comment by Pavel Bucek [ 07/Aug/12 ]

Section 4.2.2 of JAX-RS spec says that when choosing the right MessageBodyWriter to do the job, the runtime needs to order them with the supported media type being the primary key and the generic type being the secondary key. The spec also says app-provided providers take precedence over implementation-provided ones (the spec is ambiguous wrt. whether this is supposed to be the primary key or tertiary key).

Based on the use-cases we've run into with Jersey, seems the right ordering should instead be based on the following criteria:
primary) java type more specific
secondary) media type more specific
tertiary) app-provided vs. impl-provided

Representative example (many similar can be found):

Any POJO provider (e.g. Jackson writer that writes any pojo to application/json) vs. spec-dictated providers - e.g. writer for java.io.InputStream (registered with @Produces("/") according to the spec
In this scenario, the jackson writer always wins (even if my resource method returns InputStream) as it has more specific media type and is application-provided. Which is obviously wrong.

I could not find any counter-example that would support the ordering that is currently in the spec.

See Section 4.2.2. Implementations are REQUIRED to provide a backward compatible flag for those applications that rely on the previous ordering.





[JERSEY-1266] Default lifecycle for resource classes is RequestScoped (see JAX-RS spec.), not PerLookup as Singleton and PerLookup javadoc states. Created: 29/Jun/12  Updated: 22/Aug/12  Resolved: 22/Aug/12

Status: Resolved
Project: jersey
Component/s: None
Affects Version/s: None
Fix Version/s: 2.0-m07, 2.0

Type: Bug Priority: Critical
Reporter: Martin Matula Assignee: Miroslav Fuksa
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: 0 minutes
Time Spent: 4 hours
Original Estimate: 3 hours





Improve hudson infrastructure (JERSEY-1236)

[JERSEY-1239] Unify slaves config, create a group of the same-config nodes - assign most of the jobs to the group rather than a particular slave. Assign specific-config jobs to the rest of the slaves. Created: 21/Jun/12  Updated: 30/Aug/12  Resolved: 30/Aug/12

Status: Resolved
Project: jersey
Component/s: None
Affects Version/s: None
Fix Version/s: 2.0-m07, 2.0

Type: Sub-task Priority: Major
Reporter: Martin Matula Assignee: Miroslav Fuksa
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: 0 minutes
Time Spent: 5 hours
Original Estimate: 6 hours





Improve hudson infrastructure (JERSEY-1236)

[JERSEY-1238] Optional: identify referential slave, set up a cron job/hudson job on that slave to push config changes to other slaves in the group Created: 21/Jun/12  Updated: 29/May/13  Resolved: 30/Aug/12

Status: Resolved
Project: jersey
Component/s: None
Affects Version/s: None
Fix Version/s: 2.0-m07, 2.0

Type: Sub-task Priority: Minor
Reporter: Martin Matula Assignee: Miroslav Fuksa
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: 0 minutes
Time Spent: 5 hours, 30 minutes
Original Estimate: 6 hours


 Comments   
Comment by Miroslav Fuksa [ 30/Aug/12 ]

this is done currently only for configuration changes (ssh keys, maven settings, etc). Distribution of new software packages is not there (it will probably not be needed for some time). If you wish to distribute software changes, we can add support also for it (will be new task).





Improve hudson infrastructure (JERSEY-1236)

[JERSEY-1237] Identify and write up (on the internal wiki) the standard config required for most jobsOptional: prepare zip bundle that can be pushed/distributed to all slaves that has the standard config Created: 21/Jun/12  Updated: 30/Aug/12  Resolved: 30/Aug/12

Status: Resolved
Project: jersey
Component/s: None
Affects Version/s: None
Fix Version/s: 2.0-m07, 2.0

Type: Sub-task Priority: Major
Reporter: Martin Matula Assignee: Miroslav Fuksa
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: 0 minutes
Time Spent: 2 days, 6 hours
Original Estimate: 12 hours


 Description   
  • unify private keys
  • unify account names (jerseyrobot) by renaming but keeping the same UID
  • unify account password, add public keys of others to each slave
  • step-by-step instructions on how to configure





[JERSEY-1236] Improve hudson infrastructure Created: 21/Jun/12  Updated: 30/Aug/12  Resolved: 30/Aug/12

Status: Resolved
Project: jersey
Component/s: None
Affects Version/s: None
Fix Version/s: 2.0-m07, 2.0

Type: New Feature Priority: Major
Reporter: Martin Matula Assignee: Unassigned
Resolution: Fixed Votes: 0
Labels: None
Σ Remaining Estimate: 0 minutes Remaining Estimate: Not Specified
Σ Time Spent: 2 days, 16 hours, 30 minutes Time Spent: Not Specified
Σ Original Estimate: 1 day Original Estimate: Not Specified

Sub-Tasks:
Key
Summary
Type
Status
Assignee
JERSEY-1237 Identify and write up (on the interna... Sub-task Resolved Miroslav Fuksa  
JERSEY-1238 Optional: identify referential slave,... Sub-task Resolved Miroslav Fuksa  
JERSEY-1239 Unify slaves config, create a group o... Sub-task Resolved Miroslav Fuksa  

 Comments   
Comment by Miroslav Fuksa [ 30/Aug/12 ]

all issues are closed





[JERSEY-1224] Constructor parameter injection does not work Created: 15/Jun/12  Updated: 30/Aug/12  Resolved: 30/Aug/12

Status: Resolved
Project: jersey
Component/s: None
Affects Version/s: 2.0-m04
Fix Version/s: 2.0-m07, 2.0

Type: Bug Priority: Major
Reporter: Martin Matula Assignee: Miroslav Fuksa
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: 0 minutes
Time Spent: 14 hours
Original Estimate: 3 hours

Issue Links:
Dependency
depends on JERSEY-1233 Migrate to the new HK2 API Resolved
blocks JERSEY-1389 Encoding of parameters does not work ... Resolved
blocks JERSEY-986 @Encoded does not work with @FormParam Resolved

 Description   

This blocks all tests in org.glassfish.jersey.server.internal.inject.EncodedParamsTest






[JERSEY-1223] "500 Internal Server Error" for POST request with garbage instead of "Content-Type" Created: 15/Jun/12  Updated: 03/Mar/14  Resolved: 30/Jul/13

Status: Resolved
Project: jersey
Component/s: containers
Affects Version/s: 1.12, 2.1
Fix Version/s: 2.0-m07, 2.2

Type: Bug Priority: Major
Reporter: Dassburger Assignee: Michal Gajdos
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: 0 minutes
Time Spent: 3 hours, 1 minute
Original Estimate: 3 hours


 Description   

When Jersey ServletContainer processes POST request with garbage as value of "Content-Type" header, it responds with "500 Internal Server Error".

The reason is that WebComponent.filterFormParameters() throws WebApplicationException, which is never caught and unhandled. Thus, the web container under which Jersey application runs, catches it and responses with "500 Internal Server Error"



 Comments   
Comment by Michal Gajdos [ 29/Jun/12 ]

Also present in Jersey2 (tomcat + multipart-webapp example).

Comment by Michal Gajdos [ 03/Sep/12 ]

Fixed in Jersey2.

Comment by jannikolai [ 22/Jul/13 ]

We upgraded to Jersey 2, because we hoped to get this Problem ( https://java.net/jira/browse/JERSEY-1276 ) fixed in version 2, as this ticket states.
But unfortunately we are still getting a 500 response:

org.glassfish.jersey.message.internal.HeaderValueException: Unable to parse "Content-Type" header value: "application/json, app/json"
	at org.glassfish.jersey.message.internal.InboundMessageContext.exception(InboundMessageContext.java:318)
	at org.glassfish.jersey.message.internal.InboundMessageContext.singleHeader(InboundMessageContext.java:313)
	at org.glassfish.jersey.message.internal.InboundMessageContext.getMediaType(InboundMessageContext.java:427)
	at org.glassfish.jersey.servlet.WebComponent.filterFormParameters(WebComponent.java:482)
	at org.glassfish.jersey.servlet.WebComponent.service(WebComponent.java:303)
	at org.glassfish.jersey.servlet.ServletContainer.service(ServletContainer.java:372)
	at org.glassfish.jersey.servlet.ServletContainer.doFilter(ServletContainer.java:525)
	at org.glassfish.jersey.servlet.ServletContainer.doFilter(ServletContainer.java:473)
	at org.glassfish.jersey.servlet.ServletContainer.doFilter(ServletContainer.java:410)
	at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1148)
	at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:387)
	at org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216)
	at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:181)
	at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:765)
	at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:417)
	at org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:230)
	at org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:114)
	at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152)
	at org.mortbay.jetty.Server.handle(Server.java:324)
	at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:535)
	at org.mortbay.jetty.HttpConnection$RequestHandler.content(HttpConnection.java:880)
	at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:747)
	at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:218)
	at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:404)
	at org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:409)
	at org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.java:520)
Caused by: javax.ws.rs.ProcessingException: java.lang.IllegalArgumentException: Error parsing media type 'application/json, app/json'
	at org.glassfish.jersey.message.internal.InboundMessageContext$5.apply(InboundMessageContext.java:433)
	at org.glassfish.jersey.message.internal.InboundMessageContext$5.apply(InboundMessageContext.java:427)
	at org.glassfish.jersey.message.internal.InboundMessageContext.singleHeader(InboundMessageContext.java:311)
	... 24 more
Caused by: java.lang.IllegalArgumentException: Error parsing media type 'application/json, app/json'
	at org.glassfish.jersey.message.internal.MediaTypeProvider.fromString(MediaTypeProvider.java:89)
	at org.glassfish.jersey.message.internal.MediaTypeProvider.fromString(MediaTypeProvider.java:59)
	at javax.ws.rs.core.MediaType.valueOf(MediaType.java:179)
	at org.glassfish.jersey.message.internal.InboundMessageContext$5.apply(InboundMessageContext.java:431)
	... 26 more
Caused by: java.text.ParseException: Expected separator ';' instead of ','
	at org.glassfish.jersey.message.internal.HttpHeaderReader.nextSeparator(HttpHeaderReader.java:115)
	at org.glassfish.jersey.message.internal.HttpHeaderReader.readParameters(HttpHeaderReader.java:249)
	at org.glassfish.jersey.message.internal.HttpHeaderReader.readParameters(HttpHeaderReader.java:242)
	at org.glassfish.jersey.message.internal.MediaTypeProvider.valueOf(MediaTypeProvider.java:107)
	at org.glassfish.jersey.message.internal.MediaTypeProvider.fromString(MediaTypeProvider.java:87)
	... 29 more

The request we made is the following one:

curl -X POST http://your-host.com/resource -d '[{}]' -H"Content-Type: application/json, app/json" -v
Comment by Michal Gajdos [ 25/Jul/13 ]

Reopening - servlet container is not covered. Create an integration test.

Comment by Xorlev [ 03/Mar/14 ]

Would be nice to see a fix backported to Jersey 1.x for those unable to upgrade to Jersey 2.





[JERSEY-1203] InvocationCallback throws mysterious IllegalArgumentException Created: 08/Jun/12  Updated: 16/Aug/12  Resolved: 16/Aug/12

Status: Resolved
Project: jersey
Component/s: core
Affects Version/s: 2.0-m05
Fix Version/s: 2.0-m07, 2.0

Type: Bug Priority: Major
Reporter: jan.supol Assignee: Michal Gajdos
Resolution: Duplicate Votes: 0
Labels: None
Remaining Estimate: 0 minutes
Time Spent: 1 hour, 1 minute
Original Estimate: 3 hours


 Description   

Suppose a client:

Client client = ClientFactory.newClient();
Target target = client.target(url);
AsyncInvoker async = target.request().async();
InvocationCallback<Response> callback = new InvocationCallback<Response>() {
	@Override
	public void completed(Response arg0) {
		System.out.println("Completed");
	}
	@Override
	public void failed(InvocationException arg0) {
		System.out.println("failed");
	}
};
Future<Response> future = async.delete(callback);

it throws :

06-07-2012 18:14:12: ERROR: Exception at:
06-07-2012 18:14:12: ERROR: java.lang.IllegalArgumentException
at org.jvnet.tiger_types.Types.getTypeArgument(Types.java:368)
at org.glassfish.jersey.client.JerseyInvocation.submit(JerseyInvocation.java:655)
at org.glassfish.jersey.client.JerseyInvocation$AsyncInvoker.method(JerseyInvocation.java:515)
at org.glassfish.jersey.client.JerseyInvocation$AsyncInvoker.delete(JerseyInvocation.java:441)



 Comments   
Comment by Michal Gajdos [ 16/Aug/12 ]

This issue has been fixed as a part of JERSEY-1233 issue.

Please see changes in the following commit: https://github.com/jersey/jersey/commit/50ad12b6e4c2915ea66fb476e0e35b76d4e686da#L13L651





[JERSEY-1201] Jersey does not enable asynchronous processing by default Created: 08/Jun/12  Updated: 20/Aug/12  Resolved: 20/Aug/12

Status: Resolved
Project: jersey
Component/s: None
Affects Version/s: 2.0-m05
Fix Version/s: 2.0-m07, 2.0

Type: Bug Priority: Major
Reporter: jan.supol Assignee: Michal Gajdos
Resolution: Cannot Reproduce Votes: 0
Labels: None
Remaining Estimate: 0 minutes
Time Spent: 1 hour
Original Estimate: 6 hours


 Description   

When deploying war with servlet 3 descriptor, jersey searches for a class org.glassfish.jersey.servlet.async.AsyncContextDelegateProviderImpl.class.
But it cannot find it unless it is put to Application.getClasses() set.
As a result, asynchronous processing is not enabled and the error messages states that the asynchronous processing is not enabled in servlet 2.x container.



 Comments   
Comment by Michal Gajdos [ 20/Aug/12 ]

It seems that this test case describes a similar test case that is already present (and passing) in Jersey2 workspace: tests/integration/servlet-3-async.
Feel free to reopen if the mentioned test case is not sufficient to the one described in this issue (also, please, attach a sample app that would demonstrate the issue).





[JERSEY-1192] Client#invocation(Link, (Entity)null) does not throw NullPointerException Created: 01/Jun/12  Updated: 16/Aug/12  Resolved: 16/Aug/12

Status: Resolved
Project: jersey
Component/s: core
Affects Version/s: 2.0-m04
Fix Version/s: 2.0-m07, 2.0

Type: Bug Priority: Trivial
Reporter: jan.supol Assignee: Marek Potociar
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: 0 minutes
Time Spent: 2 hours
Original Estimate: 3 hours

Issue Links:
Related
is related to JERSEY-1356 Client#invocation(Link, Entity) check... Resolved

 Description   

The javadoc of Client#invocation(Link, Entity) says:

javax.ws.rs.client.Client.invocation( Link, Entity ) throws NullPointerException in case argument is null.

but calling:

Client client = ClientFactory.newClient();
URI uri = UriBuilder.fromPath("http://localhost:8080/").build();
Link link = Link.fromUri(uri).method("POST").build();
client.invocation(link, null);

throws:

java.lang.IllegalArgumentException: Entity type incompatible with link produces parameter






[JERSEY-1160] Initialize SecurityContext for client-authenticated SSL connection Created: 16/May/12  Updated: 21/Aug/12  Resolved: 21/Aug/12

Status: Resolved
Project: jersey
Component/s: containers
Affects Version/s: 1.12
Fix Version/s: 2.0-m07

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

Issue Links:
Related
is related to JERSEY-1282 SecurityContext injection does not work Resolved
Tags: container, grizzly, jax-rs, jersey, jersey-grizzly2, security, ssl

 Description   

Please modify GrizzlyContainer to initialize the ContainerRequest's SecurityContext with client identity from the SSL layer if available before handing it off to the WebApplication.

I am using jersey-grizzly2 to implement a RESTful interface for my service. Having configured the Grizzly layer to require client authentication, I find there's no straight-forward (or even round-about) way to access that information at the Jersey level.

Here's an example solution implemented in GrizzlyContainer._service():

            final ContainerRequest cRequest = new ContainerRequest(_application,
                    request.getMethod().getMethodString(), baseUri, requestUri,
                    getHeaders(request), request.getInputStream());
            
// === begin new code ===
            SSLEngine ssl = SSLUtils.getSSLEngine(request.getContext().getConnection());
            if (ssl != null) {
            	try {
            		final Principal p = ssl.getSession().getPeerPrincipal();
            		cRequest.setSecurityContext(new SecurityContext() {
            			@Override
            			public Principal getUserPrincipal() {
            				return p;
            			}
            			@Override
            			public boolean isUserInRole(String role) {
            				return false;
            			}
            			@Override
            			public boolean isSecure() {
            				return true;
            			}
            			@Override
            			public String getAuthenticationScheme() {
            				return SecurityContext.CLIENT_CERT_AUTH;
            			}
            		});
            	} 
            	catch(SSLPeerUnverifiedException ex) {
            		// no client certs
            	}
            }
// === end new code ===
 
            _application.handleRequest(cRequest, new Writer(response));


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

there should be a workaround (not tested):

you should be able to inject (into @Context annotated method param for example) Grizzly request and basically do what you are doing in proposed patch.

Comment by CLarrieu [ 02/Jul/12 ]

I developed a work-around that depends upon a single thread of execution from Grizzly filter chain up through the jersey level. Here's how I describe it in my code:

/**

  • This is part of a nasty hack that is needed to propagate the SSL-provided client
  • identity up from the Grizzly layer to the Jersey level.
  • The client identity is extracted from the Grizzly Request object and stored in a thread-local
  • variable for retrieval when filter() is run after the Jersey ContainerRequest has been
  • created but before the resource method has been invoked.
  • The only guarantee that both tasks will occur in the same thread is that the source code
  • for the current version (1.12) operates this way.
  • Hopefully the jersey-grizzly2 project will accept my patch (http://java.net/jira/browse/JERSEY-1160)
  • to make this hack unnecessary.
  • @author larrieu
    *
    */
Comment by Pavel Bucek [ 21/Aug/12 ]

already fixed in Jersey 2.x.





[JERSEY-1144] Handling primitive types (return value from resource method) Created: 11/May/12  Updated: 13/Aug/12  Resolved: 13/Aug/12

Status: Resolved
Project: jersey
Component/s: None
Affects Version/s: None
Fix Version/s: 2.0-m07, 2.0

Type: Bug Priority: Critical
Reporter: Pavel Bucek Assignee: Miroslav Fuksa
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: 0 minutes
Time Spent: 17 hours
Original Estimate: 12 hours


 Description   

Jersey2 doesn't support "int" nor "Integer" (and possibly others) as resource method return type

// including Boolean, boolean, Long, long, ...






[JERSEY-1110] UriInfo not resolved when manually injecting a filter instance Created: 14/Apr/12  Updated: 06/Aug/12  Resolved: 06/Aug/12

Status: Resolved
Project: jersey
Component/s: None
Affects Version/s: None
Fix Version/s: 2.0-m07, 2.0

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

Issue Links:
Dependency
depends on JERSEY-1164 Support for proxy-based injection of ... Resolved

 Description   

I have a test where I need to obtain an instance of my filter I registered using it's class into the ResourceConfig (i.e. rc.addClasses(UriConnegFilter.class)).

The filter has an instance variable:

@Context UriInfo uriInfo;

I am trying to obtain the instance using the following code:

UriConnegFilter f = handler.getServices().forContract(UriConnegFilter.class).get();

I get the following exception when running the test:

org.jvnet.hk2.component.ComponentException: injection failed on org.glassfish.jersey.server.filter.UriConnegFilter.uriInfo with interface javax.ws.rs.core.UriInfo
	at org.jvnet.hk2.component.InjectionManager.error_injectionException(InjectionManager.java:564)
	at org.jvnet.hk2.component.InjectionManager.syncDoInject(InjectionManager.java:206)
	at org.jvnet.hk2.component.InjectionManager.inject(InjectionManager.java:107)
	at com.sun.hk2.component.AbstractCreatorImpl.inject(AbstractCreatorImpl.java:127)
	at com.sun.hk2.component.ConstructorCreator.initialize(ConstructorCreator.java:117)
	at com.sun.hk2.component.AbstractCreatorImpl.get(AbstractCreatorImpl.java:84)
	at com.sun.hk2.component.AbstractInhabitantImpl.get(AbstractInhabitantImpl.java:135)
	at org.jvnet.hk2.component.ContractLocatorImpl.get(ContractLocatorImpl.java:137)
	at org.glassfish.jersey.server.filter.UriConnegFilterTest.testConfig(UriConnegFilterTest.java:98)
        ....


 Comments   
Comment by Marek Potociar [ 11/May/12 ]

This can be only resolved once we implement support for proxy-based injection. You are trying to inject the request-scoped information outside of the scope as the exception indicates.

A temporary work-around is to inject a Factory<UriInfo> instead.





Provide equivalent of ResourceContext from Jersey 1.x so that I am able to create managed instances of sub-resources, and match URI's to resources and UriInfo. (JERSEY-1087)

[JERSEY-1104] spike Created: 13/Apr/12  Updated: 29/Aug/12  Resolved: 29/Aug/12

Status: Resolved
Project: jersey
Component/s: None
Affects Version/s: None
Fix Version/s: 2.0-m07, 2.0

Type: Sub-task Priority: Blocker
Reporter: Pavel Bucek Assignee: Marek Potociar
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: 0 minutes
Time Spent: 3 hours
Original Estimate: 6 hours





[JERSEY-1087] Provide equivalent of ResourceContext from Jersey 1.x so that I am able to create managed instances of sub-resources, and match URI's to resources and UriInfo. Created: 12/Apr/12  Updated: 04/Sep/12  Resolved: 04/Sep/12

Status: Resolved
Project: jersey
Component/s: None
Affects Version/s: None
Fix Version/s: 2.0-m07, 2.0

Type: New Feature Priority: Blocker
Reporter: Martin Matula Assignee: Marek Potociar
Resolution: Fixed Votes: 0
Labels: None
Σ Remaining Estimate: 0 minutes Remaining Estimate: Not Specified
Σ Time Spent: 14 hours, 1 minute Time Spent: Not Specified
Σ Original Estimate: 18 hours Original Estimate: Not Specified

Issue Links:
Related
is related to JAX_RS_SPEC-72 Standardization of ResourceContext / ... Resolved
Sub-Tasks:
Key
Summary
Type
Status
Assignee
JERSEY-1104 spike Sub-task Resolved Marek Potociar  
JERSEY-1395 Implement support for getResource() m... Sub-task Resolved Marek Potociar  
JERSEY-1396 Implement support for match URI methods. Sub-task Resolved Marek Potociar  

 Description   

Demo: Application utilizing the above features (creating sub-resources in sub-resource locators with injected instance fields; matching URI passed in the message body to resource and uri info).






[JERSEY-1085] Multipart/form-data POST having a quoted boundary parameter in the Content-Type header fails. Created: 11/Apr/12  Updated: 03/Sep/12  Resolved: 03/Sep/12

Status: Resolved
Project: jersey
Component/s: media
Affects Version/s: 1.12
Fix Version/s: 2.0-m07, 2.0

Type: Bug Priority: Major
Reporter: voinescu_mihaela Assignee: Michal Gajdos
Resolution: Cannot Reproduce Votes: 0
Labels: None
Remaining Estimate: 0 minutes
Time Spent: 2 hours
Original Estimate: 3 hours

Tags: boundary, jersey, multipart, quoted

 Description   

Jersey returns HTTP status 400 when POST-ing a multipart/form-data having a quoted boundary parameter in the Content-Type header:
Content-Type: multipart/form-data;boundary="MrmiiyyJEqRYcIJyun5tMVIz70NuQ_nfD"
and use MrmiiyyJEqRYcIJyun5tMVIz70NuQ_nfD (without quotes) to separate the parts.

Use com.sun.jersey.spi.spring.container.servlet.SpringServlet.
Exception is thrown in jersey class com.sun.jersey.multipart.impl.MultiPartReaderClientSide, method readMultiPart. (org.jvnet.mimepull.MIMEParsingException: Missing start boundary).

RFC2046 states that quoted boundary values are permitted (http://www.ietf.org/rfc/rfc2046.txt):
"
WARNING TO IMPLEMENTORS: The grammar for parameters on the Content-
type field is such that it is often necessary to enclose the boundary
parameter values in quotes on the Content-type line. This is not
always necessary, but never hurts. Implementors should be sure to
study the grammar carefully in order to avoid producing invalid
Content-type fields. Thus, a typical "multipart" Content-Type header
field might look like this:
Content-Type: multipart/mixed; boundary=gc0p4Jq0M2Yt08j34c0p

But the following is not valid:
Content-Type: multipart/mixed; boundary=gc0pJq0M:08jU534c0p
(because of the colon) and must instead be represented as
Content-Type: multipart/mixed; boundary="gc0pJq0M:08jU534c0p"
".



 Comments   
Comment by Michal Gajdos [ 03/Sep/12 ]

This issue does not occur in Jersey2. Resolving as 'Cannot Reproduce'.





[JERSEY-1083] SourceProvider.SaxSourceReader and SourceProvider.DomSourceReader do not work in the client application. Created: 10/Apr/12  Updated: 17/Aug/12  Resolved: 17/Aug/12

Status: Resolved
Project: jersey
Component/s: media
Affects Version/s: backlog
Fix Version/s: 2.0-m07, 2.0

Type: Bug Priority: Minor
Reporter: Miroslav Fuksa Assignee: Marek Potociar
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: 0 minutes
Time Spent: 4 hours
Original Estimate: 12 hours


 Description   

Exception thrown when reading an entity as a SAXSource or DOMSource:
example: response.readEntity(SAXSource.class)

SourceProvider.SaxSourceReader uses the injection of the SAXParserFactory (per the thread scope) by the SaxParserFactoryInjectionProvider. This factory needs an injection of the FeaturesAndProperties which is injected in Request Scope. This causes the problem in readEntity in the client api which does not run in the request scope. The exception is thrown (java.lang.IllegalStateException: Not inside a request scope).

One of the solution is to extend request scope to cover also readEntity() calls.

The example test case which fails now is commented in SourceEntityProviderTest (getSaxSourceTest and getDomSourceTest).



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

This also affects the org.glassfish.jersey.osgi.test.basic.JsonMoxyTest (see TODO comments in AbstractJsonOsgiIntegrationTest).





[JERSEY-1078] ReaderProvider does not write into an output stream Created: 05/Apr/12  Updated: 13/Aug/12  Resolved: 13/Aug/12

Status: Resolved
Project: jersey
Component/s: core
Affects Version/s: 1.12
Fix Version/s: 2.0-m07, 2.0

Type: Bug Priority: Minor
Reporter: jan.supol Assignee: Miroslav Fuksa
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: 0 minutes
Time Spent: 4 hours
Original Estimate: 6 hours


 Description   

Suppose:

@Path("resource")
public class Resource {
	@Path("reader")
	@POST
	public Reader reader(Reader reader) {
		return reader;
	}
}

reader instance contains correct data, but when trying to write, everything seems to be ok even in com.sun.jersey.core.util.ReaderWriter#writeTo, but then
out.write(data, 0, read);
does not actually write anything



 Comments   
Comment by Martin Matula [ 11/Apr/12 ]

I don't understand the issue. Can you please attach the code that fails?

Comment by Martin Matula [ 11/Apr/12 ]

Jan provided some more explanation on this - the Reader he receives works well when accessing it from the resource method. But when you try to return it, somewhere in the response processing it fails and nothing gets written to the response output stream.

Comment by Martin Matula [ 11/Apr/12 ]

We should not target this for 1.x. Just for 2.0 as it is an edge case.

Comment by Marek Potociar [ 02/May/12 ]

What does it mean "return it, somewhere in the response processing"? Is there a better description or a reproducible unit test that could be attached to the issue?





[JERSEY-1066] JAF is not used for all java types when returning entity from resource Created: 03/Apr/12  Updated: 15/Aug/12  Resolved: 15/Aug/12

Status: Resolved
Project: jersey
Component/s: None
Affects Version/s: 2.0-m02
Fix Version/s: 2.0-m07, 2.0

Type: Bug Priority: Minor
Reporter: jan.supol Assignee: Marek Potociar
Resolution: Works as designed Votes: 0
Labels: None
Remaining Estimate: 0 minutes
Time Spent: 6 hours
Original Estimate: 12 hours

Attachments: Zip Archive jaf.zip    
Issue Links:
Related
is related to JAX_RS_SPEC-249 Remove sections involving JAF from en... Closed

 Description   

The spec., Sec. 4.2.1, item 6, says:

Else if a suitable data handler can be found using the JavaBeans Activation Framework[11] then use
it to map the entity body to the desired Java type.

From this, I assume, any Java type is a valid return type:

@Path("resource")
public class Resource {

	@POST
	@Path("jaf")
	public WeirdClass jaf() {
		String message = "";
		try {
			DataHandler
					.setDataContentHandlerFactory(new WeirdDataContentHandlerFactory());
		} catch (Error e) {
			message = "Factory already present: " + e;
		}
		return new WeirdClass(message + " JAF");
	}

	@POST
	@Path("jafds")
	public DataSource jafds() {
		return new WeirdDataSource(new WeirdClass("JAFDS"));
	}
}

the jafds works fine. But jaf does not work. The log contains:

javax.ws.rs.WebApplicationException: com.sun.jersey.api.MessageException: A message body writer for Java class WeirdClass, and Java type class WeirdClass, and MIME media type application/octet-stream was not found.

I assume Jersey should use JAF even for all Java classes, not only DataSource, and do something like:

DataHandler dr = new DataHandler(<the return WeirdClass instance>, <Content-type>);  
try {
   InputStream is = dr.getInputStream();
    } catch (UnsupportedDataTypeException e) {
//no JAF, return
   }
   //Use this input stream from DataContentHandler (from DataContentHandlerFactory) instead of the stream from DataSource


 Comments   
Comment by jan.supol [ 03/Apr/12 ]

Oops, this test was about writing not reading, hence the section 4.2.2. item 7) applies:

Else if a suitable data handler can be found using the JavaBeans Activation Framework[11] then use
it to map the object to the entity body.

Nevertheless, the DataHandler

DataHandler dr = new DataHandler(<the return WeirdClass instance>, <@Produces>); 

would be appropriate anyway.

Comment by Marek Potociar [ 11/Apr/12 ]

Moved to 2.0 backlog.

Comment by Marek Potociar [ 15/Aug/12 ]

The final decision is to update the spec to not include those steps in the entity marshalling/un-marshalling algorithms. See issue JAX_RS_SPEC-249.





[JERSEY-1054] Accept: text/*, @Produces text/* does not result in 406 Created: 29/Mar/12  Updated: 30/Aug/12  Resolved: 30/Aug/12

Status: Closed
Project: jersey
Component/s: None
Affects Version/s: 2.0
Fix Version/s: 2.0-m07, 2.0

Type: Bug Priority: Major
Reporter: jan.supol Assignee: Miroslav Fuksa
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: 0 minutes
Time Spent: 1 hour
Original Estimate: 3 hours


 Description   

in a resource:

@Path("error")
public class ErrorResource {
	@GET
	@Produces("text/*")
	public String test(){
		return getClass().getSimpleName();
	}
}

"GET /jaxrs_spec_resource_responsemediatype_web/error HTTP/1.1[\r][\n]"
"Accept: text/*[\r][\n]"

results in 200, text/plain



 Comments   
Comment by jan.supol [ 30/Mar/12 ]

See Section 3.8 of spec, item 10, in the algorithm.





[JERSEY-1021] I want to be able to see application WADL at <jersey_root>/application.wadl but also want to be able to disable wadl if needed. Created: 18/Mar/12  Updated: 04/Sep/12  Resolved: 04/Sep/12

Status: Resolved
Project: jersey
Component/s: None
Affects Version/s: None
Fix Version/s: 2.0-m07, 2.0

Type: New Feature Priority: Critical
Reporter: Martin Matula Assignee: Pavel Bucek
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: 0 minutes
Time Spent: Not Specified
Original Estimate: 0 minutes


 Description   

Demo: Add test to the existing samples.






[JERSEY-994] Jersey is case-sensitive for percent encoded URIs Created: 23/Feb/12  Updated: 28/Aug/12  Resolved: 28/Aug/12

Status: Resolved
Project: jersey
Component/s: None
Affects Version/s: 1.8
Fix Version/s: 2.0-m07, 2.0

Type: Bug Priority: Major
Reporter: hosamu Assignee: Miroslav Fuksa
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: 0 minutes
Time Spent: 11 hours
Original Estimate: 3 hours


 Description   

Sub resource methods below are recognized that they have same URI.

@GET
@Path("%5B%5D")

@GET
@Path("[]")

So this case causes conflict error at initialization time.

But sub resource methods below are recognized as different 2 resource paths.

@GET
@Path("%5B%5D")

@GET
@Path("%5d%5d")

This case, above two methods serve at their respective URIs.

RFC 3986 Section 2.1 says that ,
"The uppercase hexadecimal digits 'A' through 'F' are equivalent to
the lowercase digits 'a' through 'f', respectively. If two URIs
differ only in the case of hexadecimal digits used in percent-encoded
octets, they are equivalent."

I tried other platforms with some samples cases.
Apache(HTTP server),Tomcat,Subversion(via http access),
all of them are non case-sensitive for percent encoding.



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

Nice catch! Thanks!

Comment by Marek Potociar [ 23/Feb/12 ]

Targeting for fix in 2.0.





[JERSEY-986] @Encoded does not work with @FormParam Created: 16/Feb/12  Updated: 03/Sep/12  Resolved: 03/Sep/12

Status: Resolved
Project: jersey
Component/s: None
Affects Version/s: 1.12
Fix Version/s: 2.0-m07, 2.0

Type: Bug Priority: Major
Reporter: jan.supol Assignee: Miroslav Fuksa
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: 0 minutes
Time Spent: 11 hours
Original Estimate: 3 hours

Issue Links:
Dependency
depends on JERSEY-1224 Constructor parameter injection does ... Resolved
Duplicate
is duplicated by JERSEY-1389 Encoding of parameters does not work ... Resolved

 Description   

Suppose having

@Path(value = "/FormParamTest/")
public class FormParamTest {
	@Path(value = "/FromString")
	@POST
	@Consumes("application/x-www-form-urlencoded")
	public String fromString(
		@Encoded @DefaultValue("FromString") @FormParam("default_argument") String string) {
		return string;
	}
}

calling POST /jaxrs_ee_formparam_web/FormParamTest/FromString HTTP/1.1 With
{default_argument=text=%21}}
string is text=!



 Comments   
Comment by Marek Potociar [ 23/Feb/12 ]

Seems like an impl. bug. Assigned for fixing in 2.0

Comment by jan.supol [ 03/Aug/12 ]

The same issue it seems to be for QueryParam, as well.

Comment by Miroslav Fuksa [ 29/Aug/12 ]

this issue is blocked by JERSEY-1224





[JERSEY-974] RuntimeDelegate.HeaderDelegate<T>.toString(null) throws NullPointException Created: 10/Feb/12  Updated: 04/Sep/12  Resolved: 04/Sep/12

Status: Resolved
Project: jersey
Component/s: core
Affects Version/s: 1.12
Fix Version/s: 2.0-m07, 2.0

Type: Bug Priority: Major
Reporter: jan.supol Assignee: Jakub Podlesak
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: 0 minutes
Time Spent: 3 hours
Original Estimate: 3 hours

Attachments: Text File jersey-974.patch    

 Description   

Javadoc says:

RuntimeDelegate.HeaderDelegate<T>.toString
throws
java.lang.IllegalArgumentException - if the supplied object cannot be serialized or is null

But unlike fromString, it throws NullPointerException



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

There is number of HeaderDelegate implementations in the Jersey code base
and from the description above i am not able to tell which one is affected.

Could you please attach a reproducible test case to help me fix this?

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

RuntimeDelegate delegate;
delegate = RuntimeDelegate.getInstance();
HeaderDelegate<MediaType> hdmt = delegate
.createHeaderDelegate(MediaType.class);
hdmt.toString(null);

Comment by Jakub Podlesak [ 29/Feb/12 ]

Thanks! It seems all HeaderDelegateProvider implementations are affected,
not only the MediaTypeProvider implementation. We need to fix this.

Comment by Jakub Podlesak [ 02/Mar/12 ]

patch file





[JERSEY-924] When "*" accesses an included resource path, the java.lang.StringIndexOutOfBoundsException occurs Created: 26/Jan/12  Updated: 28/Aug/12  Resolved: 28/Aug/12

Status: Closed
Project: jersey
Component/s: core
Affects Version/s: 1.8
Fix Version/s: 2.0-m07, 2.0

Type: Bug Priority: Major
Reporter: hosamu Assignee: Miroslav Fuksa
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: 0 minutes
Time Spent: 1 hour
Original Estimate: 3 hours


 Description   

Following, "*" an included resource path,
When access to the http://localhost:8080/hello/* , the java.lang.StringIndexOutOfBoundsException occurs.

server.Hello
@Path("*")
public class Hello {
    @GET
    public String sayHello() {
        return "Hello, World!";
    }
}
java.lang.StringIndexOutOfBoundsException
java.lang.StringIndexOutOfBoundsException: String index out of range: -1
	at java.lang.String.substring(String.java:1937)
	at com.sun.jersey.server.impl.application.WebApplicationContext.pushRightHandPathLength(WebApplicationContext.java:282)
	at com.sun.jersey.server.impl.uri.rules.RightHandPathRule.accept(RightHandPathRule.java:130)
	at com.sun.jersey.server.impl.uri.rules.RootResourceClassesRule.accept(RootResourceClassesRule.java:84)
	at com.sun.jersey.server.impl.application.WebApplicationImpl._handleRequest(WebApplicationImpl.java:1469)
	at com.sun.jersey.server.impl.application.WebApplicationImpl._handleRequest(WebApplicationImpl.java:1400)
	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:847)
	at org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1539)
	at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:281)
	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
	at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:655)
	at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:595)
	at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:98)
	at com.sun.enterprise.web.PESessionLockingStandardPipeline.invoke(PESessionLockingStandardPipeline.java:91)
	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:162)
	at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:330)
	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:231)
	at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:174)
	at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:828)
	at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:725)
	at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1019)
	at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:225)
	at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:137)
	at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:104)
	at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:90)
	at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:79)
	at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:54)
	at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:59)
	at com.sun.grizzly.ContextTask.run(ContextTask.java:71)
	at com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:532)
	at com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:513)
	at java.lang.Thread.run(Thread.java:662)

The following sources are code escaping a string of URI template.
Why is not "*" included in RESERVED_REGEX_CHARACTERS ?

By the way, the java.lang.StringIndexOutOfBoundsException does not occur if "*" is included in RESERVED_REGEX_CHARACTERS.

com.sun.jersey.api.uri.UriTemplateParser
    private static final Set<Character> RESERVED_REGEX_CHARACTERS = initReserved();

    private static Set<Character> initReserved() {
        // TODO need to escape all regex characters present
        char[] reserved = {
            '.',
            '?',
            '(',
            ')'};

        Set<Character> s = new HashSet<Character>(reserved.length);
        for (char c : reserved) {
            s.add(c);
        }
        return s;
    }

    ...

    private void processLiteralCharacters() {
        if (literalCharactersBuffer.length() > 0) {
            literalCharacters += literalCharactersBuffer.length();

            String s = encodeLiteralCharacters(literalCharactersBuffer.toString());

            normalizedTemplate.append(s);

            // Escape if reserved regex character
            for (int i = 0; i < s.length(); i++) {
                char c = s.charAt(i);
                if (RESERVED_REGEX_CHARACTERS.contains(c)) {
                    regex.append("\\");
                }
                regex.append(c);
            }

            literalCharactersBuffer.setLength(0);
        }
    }


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

Setting fix verison to 2.0.





[JERSEY-921] NPE occurs when access to the resource path has resource or provider initialized failed. Created: 24/Jan/12  Updated: 27/Aug/12  Resolved: 27/Aug/12

Status: Resolved
Project: jersey
Component/s: core
Affects Version/s: 1.8
Fix Version/s: 2.0-m07, 2.0

Type: Bug Priority: Major
Reporter: hosamu Assignee: Michal Gajdos
Resolution: Cannot Reproduce Votes: 0
Labels: None
Remaining Estimate: 0 minutes
Time Spent: 30 minutes
Original Estimate: 3 hours


 Description   

NPE occurs when access to the resource path has resource or provider initialized failed.
Following stack trace when NPE occured.

java.lang.NullPointerException
java.lang.NullPointerException
        at com.sun.jersey.spi.container.ContainerRequest.<init>(ContainerRequest.java:187)
        at com.sun.jersey.spi.container.servlet.WebComponent.createRequest(WebComponent.java:450)
        at com.sun.jersey.spi.container.servlet.WebComponent.service(WebComponent.java:380)
        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:847)
        at org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1539)
        at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:281)
        at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
        at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:655)
        at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:595)
        at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:98)
        at com.sun.enterprise.web.PESessionLockingStandardPipeline.invoke(PESessionLockingStandardPipeline.java:91)
        at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:162)
        at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:330)
        at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:231)
        at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:174)
        at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:828)
        at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:725)
        at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1019)
        at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:225)
        at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:137)
        at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:104)
        at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:90)
        at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:79)
        at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:54)
        at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:59)
        at com.sun.grizzly.ContextTask.run(ContextTask.java:71)
        at com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:532)
        at com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:513)
        at java.lang.Thread.run(Thread.java:662)

Following sources is initialization code of Jersey.
When an exception occurs in the following sources *1, but not processed *2, consequently NPE occurs in *3.

com.sun.jersey.spi.container.servlet.WebComponent
    public void load() {
        WebApplication _application = create();
        configure(config, resourceConfig, _application);
*1      initiate(resourceConfig, _application);
*2      application = _application;
    }
com.sun.jersey.spi.container.ContainerRequest
    public ContainerRequest(
            WebApplication wa,
            String method,
            URI baseUri,
            URI requestUri,
            InBoundHeaders headers,
            InputStream entity) {
        this.wa = wa;
*3      this.isTraceEnabled = wa.isTracingEnabled();
        this.method = method;
        this.baseUri = baseUri;
        this.requestUri = requestUri;
        this.headers = headers;
        this.headersModCount = headers.getModCount();
        this.entity = entity;
    }


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

Could you please attach a reproducible test case, or at least provide some steps to reproduce?

Comment by Jakub Podlesak [ 27/Mar/12 ]

Reproduced with JERSEY-881 reproducible test case. Setting fixed version to 2.0 to align with that one.

Comment by Michal Gajdos [ 27/Aug/12 ]

This problem does not occur in Jersey2 so closing as 'Cannot Reproduce'.
If you need this fixed in Jersey1 feel free to reopen the issue.





[JERSEY-920] The ExceptionMapper is not handled in MessageBodyWriter Created: 24/Jan/12  Updated: 30/Aug/12  Resolved: 30/Aug/12

Status: Resolved
Project: jersey
Component/s: core
Affects Version/s: 1.8
Fix Version/s: 2.0-m07, 2.0

Type: Bug Priority: Major
Reporter: hosamu Assignee: Miroslav Fuksa
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: 0 minutes
Time Spent: 8 hours, 30 minutes
Original Estimate: 3 hours


 Description   

Registered ExceptionMapper<RuntimeException>,
the toResponse() is not invoked when occurs RuntimeException in MessageBodyWriter.
However, the toResponse() is invoked when occurs RuntimeException in MessageBodyReader.

Looking at the source below, the ExceptionMapper is handled when request processing.
However, the ExceptionMapper is not handled when response processing.
Why?

com.sun.jersey.server.impl.application.WebApplicationImpl
    private void _handleRequest(final WebApplicationContext localContext,
                                ContainerRequest request, ContainerResponse response) throws IOException {
        try {
             requestListener.onRequest(Thread.currentThread().getId(), request);
            _handleRequest(localContext, request);
        } catch (WebApplicationException e) {
            response.mapWebApplicationException(e);
        } catch (MappableContainerException e) {
            response.mapMappableContainerException(e);
        } catch (RuntimeException e) {
            if (!response.mapException(e)) {
                LOGGER.log(Level.SEVERE, "The RuntimeException could not be mapped to a response, " +
                        "re-throwing to the HTTP container", e);
                throw e;
            }
        }

        ...

        try {
            response.write();
            responseListener.onResponse(Thread.currentThread().getId(), response);
        } catch (WebApplicationException e) {
            if (response.isCommitted()) {
                LOGGER.log(Level.SEVERE, "The response of the WebApplicationException cannot be utilized " +
                        "as the response is already committed. Re-throwing to the HTTP container", e);
                throw e;
            } else {
                response.mapWebApplicationException(e);
                response.write();
            }
        }
    }


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

Setting fix version to 2.0, please let me know if you have any objections.





[JERSEY-895] UriBuilder.path(Class clazz, String method) and path templates with regex Created: 27/Dec/11  Updated: 20/Aug/12  Resolved: 20/Aug/12

Status: Resolved
Project: jersey
Component/s: None
Affects Version/s: 1.11
Fix Version/s: 2.0-m07, 2.0

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

Attachments: Zip Archive UriBuilderTest.zip    

 Description   

UriBuilder.path(Class clazz) and UriBuilder.path(Class clazz, String method) do not work with resources which paths contain regex templates. I.e., it fails to build URI for resource annotated with {{{@Path("resource/

{id : \\d+}

")}}}.

There is a sample project in the attachment which helps to reproduce the bug:
1. {{

{http://localhost:9998/numeric/3}

}} will return correct representation.
2. {{

{http://localhost:9998/any/blahblah}

}} will return "404" and print exception stack-trace in stderr. The exception indicates that UriBuilder did not succeed in building URI for resource with regex in @Path.



 Comments   
Comment by Marek Potociar [ 23/Feb/12 ]

The issue is confirmed.

Until it is resolved, the workaround is to not put the extra empty spaces into the Path template name before the ':' and the regexp. E.g. instead of:

@Path("resource/{id : \\d+}")

use:

@Path("resource/{id: \\d+}")
Comment by Miroslav Fuksa [ 20/Aug/12 ]

fixed and merged to master





[JERSEY-881] Package name resource config does not work in OSGi environment Created: 12/Dec/11  Updated: 08/Aug/13  Resolved: 03/Sep/12

Status: Resolved
Project: jersey
Component/s: core
Affects Version/s: None
Fix Version/s: 2.0-m07, 2.0

Type: Bug Priority: Major
Reporter: saikirandaripelli Assignee: Michal Gajdos
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: 0 minutes
Time Spent: 23 hours
Original Estimate: 3 hours
Environment:

Operating System: All
Platform: All


Issue Links:
Duplicate
is duplicated by JERSEY-927 Package name resource config does not... Resolved
Issuezilla Id: 527

 Description   

To make a Jersey application work in OSGi environment, the package name
resource configuration has to be replaced by the class name mechanism.
This is quite annoying and should be fixed.



 Comments   
Comment by saikirandaripelli [ 12/Dec/11 ]

Hi,
I am not able to run helloworld-osgi-webapp-1.10 by changing the classNamesResource config to PackagenamesResourceConfig in Apache Felix or Equinox. I tried in jersey 1.8, 1.9 and 1.10.
I just changed the web.xml init params to following, and followed the readme.
I am able to run it, if it is classNamesResourceConfig as provided by default.

<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>

Comment by Jakub Podlesak [ 20/Dec/11 ]

You should not need to change anything in the example configuration.
The example should run as is out of the box in Apache Felix (look at the readme doc enclosed
in the example root directory).

This gets also automatically tested when you do mvn clean install
using the pax-exam maven plugin.

Could you please re-try, and suggest what from the above does not work for you?

Comment by saikirandaripelli [ 21/Dec/11 ]

The example uses classNamesResourceConfig where we specify individual classnames in web.xml, but i want to use packageNamesResourceConfig where we specify package containing resources.
I went through the Readme, and using example as-is(classNamesResourceConfig) is working fine in felix, but when i change it to use packageNamesResourceConfig it is not working.

Comment by Pavel Bucek [ 27/Jan/12 ]

see http://java.net/jira/browse/JERSEY-927 for steps to reproduce

Comment by Jakub Podlesak [ 27/Mar/12 ]

Setting fix version to 2.0

Comment by Michal Gajdos [ 03/Sep/12 ]

Fixed in Jersey2. Will be migrated to Jersey1.

Comment by Michal Gajdos [ 04/Sep/12 ]

Migrated to Jersey 1.14.





[JERSEY-782] should enable central version management in Jersey POMs Created: 26/Sep/11  Updated: 04/Feb/13  Resolved: 04/Feb/13

Status: Resolved
Project: jersey
Component/s: None
Affects Version/s: 1.9
Fix Version/s: 2.0-m07

Type: Improvement Priority: Minor
Reporter: jbenoit Assignee: Jakub Podlesak
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Jersey should have central version management in it's maven pom.xml files and documentation source files. Jersey sources should be able to change dependency versions in a handful of locations - in the root project POMs. All the other poms inheriting from one of the root poms, as well as all the documentation source files should be then referencing the dependency versions via variable properties rather than as absolute numbers. The described approach would reduce the amount of work needed for any subsequent version updates as well as help ensure consistency of any such change.

For example, look for hard coded <version>1.9.36</version> used in:

<dependency>
<groupId>com.sun.grizzly</groupId>
<artifactId>grizzly-servlet-webserver</artifactId>
<version>1.9.36</version>
</dependency>

found in these files:

jersey/contribs/jersey-oauth/oauth-tests/pom.xml
jersey/archetypes/jersey-quickstart-grizzly/src/main/resources/archetype-resources/pom.xml
jersey/experimental/hypermedia-action/hypermedia-action-client/pom.xml
jersey/experimental/view-client/jersey-view-client-samples/hypermedia-action-sample/pom.xml
jersey/jersey-bundle/pom.xml
jersey/jersey-tests/pom.xml
jersey/osgi/functional-tests/pom.xml
jersey/osgi/runtime-delegate-tests/rd-tests/pom.xml
jersey/osgi/test-grizzly-bundle/grizzly-jersey-bundle/pom.xml
jersey/osgi/test-grizzly-bundle/grizzly-jersey-test/pom.xml
jersey/samples/osgi-http-service/functional-test/pom.xml

grizzly version "1.9.36" is also hard coded within these documentation files:
jersey/jersey-documentation/src/docbook/dependencies.xml
jersey/jersey-documentation/src/docbook/getting-started.xml

There are many other such instances throughout Jersey code that should be changed.



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

This should be fixed in Jersey 2.x codebase.





Generated at Wed May 27 18:47:46 UTC 2015 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.