<< Back to previous view

[JERSEY-2495] jersey-spring3 fails to recognize Spring components with @Controller Created: 25/Apr/14  Updated: 25/Apr/14

Status: Open
Project: jersey
Component/s: extensions
Affects Version/s: 2.7
Fix Version/s: None

Type: Bug Priority: Major
Reporter: ojacobson Assignee: Unassigned
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: ojacobson

 Description   

The jersey-spring3 extension ignores Spring beans such as

package com.example.web;

import javax.ws.rs.GET;
import javax.ws.rs.Produces;
import org.springframework.stereotype.Controller;

@Controller
@Path("/")
public class Example {

    @GET
    @Produces("text/plain")
    public String message() {
        return "Hello, world!";
    }
}

Instead, resource classes with @Controller are created directly by Jersey. While this doesn't affect the example much, @Controller-bearing Spring beans may be relying on Spring features such as AOP transaction demarcation or spring-security access control expressions.

You can reproduce this in the Spring example project by replacing the @Component annotations on the example beans with @Controller, @Service, or any other Spring annotation, or by removing the annotations entirely.






[JERSEY-2494] AsyncResponse timeouts creates unncessary GC pressure Created: 24/Apr/14  Updated: 24/Apr/14

Status: Open
Project: jersey
Component/s: core
Affects Version/s: 2.7
Fix Version/s: None

Type: Bug Priority: Major
Reporter: schildmeijer Assignee: Unassigned
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: schildmeijer

 Description   

The timeoutTask (a ScheduledFuture representing the request timeout) in org.glassfish.jersey.server.internal.JerseyRequestTimeoutHandler is not canceled when the request is finished. This means that there will be unnecessary references to eg. the AsyncResponse object. This will promote (very likely) objects to "Old Gen" and increase the GC pressure.

We are currently using a workaround where we set a new timeout on the AsyncResponse (register a CompletionCallback on the AsyncResponse object).
The new timeout we set is 0 seconds and will cancel the existing timeoutTask.



 Comments   
Comment by schildmeijer [ 24/Apr/14 01:45 PM ]

patch available at https://github.com/jersey/jersey/pull/81





[JERSEY-2493] Clarify Javadoc for ServletDeploymentContext and ServletDeploymentContext.Builder Created: 22/Apr/14  Updated: 22/Apr/14

Status: Open
Project: jersey
Component/s: test-framework
Affects Version/s: 2.8
Fix Version/s: None

Type: Improvement Priority: Minor
Reporter: cowwoc Assignee: Unassigned
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: cowwoc

 Description   

While the Javadoc for these classes is technically correct, it is quite brief. Elaborating on the meaning of ServletDeploymentContext and ServletDeploymentContext.Builder's init and context parameters will help users understand what is going on.

To that end, please indicate that init parameters are bound to Jersey's servlet or filter, and will be returned by ServletConfig.getInitParameter() or FilterConfig.getInitParameter(), respectively.

For ServletDeploymentContext.getContextParams() please indicate that these are context-wide (not bound to the servlet/filter) and will be returned by ServletContext.getInitParameter().






[JERSEY-2492] Introduce JettyWebTestContainerFactory that supports ServletDeploymentContext Created: 22/Apr/14  Updated: 24/Apr/14

Status: Open
Project: jersey
Component/s: test-framework
Affects Version/s: 2.8
Fix Version/s: backlog

Type: New Feature Priority: Major
Reporter: cowwoc Assignee: Jakub Podlesak
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: cowwoc and Jakub Podlesak

 Description   

Shouldn't ServletDeploymentContext list JettyTestContainerFactory as a compatible test container? As far as I know, it supports servlets.



 Comments   
Comment by cowwoc [ 22/Apr/14 05:49 PM ]

(This issue is a follow-up to JERSEY-2259)

Comment by cowwoc [ 22/Apr/14 06:03 PM ]

To clarify, I am referring to the Javadoc, not the user manual.

I am expecting https://jersey.java.net/apidocs/snapshot/jersey/org/glassfish/jersey/test/ServletDeploymentContext.html to list JettyTestContainerFactory.

Comment by Jakub Podlesak [ 24/Apr/14 08:34 AM ]

Adjusted title to fit the real requirement. A new feature is needed because the existing JettyTestContainerFactory does not in fact support the ServletDeploymentContext.





[JERSEY-2491] REOPEN -GLassfish failed to inject CDI managed beans in an ExceptionMapper Created: 22/Apr/14  Updated: 23/Apr/14  Resolved: 23/Apr/14

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

Type: Bug Priority: Major
Reporter: hazem Assignee: Unassigned
Resolution: Duplicate Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Glassfish 4


File Attachments: Zip Archive glassfish4-test-master.zip    
Issue Links:
Duplicate
duplicates JERSEY-2393 GLassfish failed to inject CDI manage... Reopened
Tags: cdi glassfish4 hk2 incomplete jersey
Participants: hazem and Jakub Podlesak

 Description   

I created a custom ExceptionMapper and I want to inject a CDI managed bean (singleton) into it

@Provider
public class MyExceptionMapper implements ExceptionMapper<Throwable> {
@Inject
private Manager myManager;

@Override
public Response toResponse(Throwable exception) { // My implementation }
}

I get the following exception when I access the application
org.glassfish.hk2.api.UnsatisfiedDependencyException: There was no object available for injection at Injectee(requiredType=Manager,parent=MyExceptionMapper,qu
alifiers={}),position=-1,optional=false,self=false,unqualified=null,1954647854)
at org.jvnet.hk2.internal.ThreeThirtyResolver.resolve(ThreeThirtyResolver.java:74)
at org.jvnet.hk2.internal.ClazzCreator.resolve(ClazzCreator.java:191)
at org.jvnet.hk2.internal.ClazzCreator.resolveAllDependencies(ClazzCreator.java:214)
at org.jvnet.hk2.internal.ClazzCreator.create(ClazzCreator.java:311)
at org.jvnet.hk2.internal.SystemDescriptor.create(SystemDescriptor.java:448)
at org.jvnet.hk2.internal.SingletonContext.findOrCreate(SingletonContext.java:118)
at org.jvnet.hk2.internal.Utilities.createService(Utilities.java:2204)
at org.jvnet.hk2.internal.ServiceHandleImpl.getService(ServiceHandleImpl.java:93)
at org.glassfish.jersey.internal.inject.ProviderToService.apply(ProviderToService.java:57)
at org.glassfish.jersey.internal.inject.ProviderToService.apply(ProviderToService.java:53)
at com.google.common.collect.Iterators$8.transform(Iterators.java:860)
at com.google.common.collect.TransformedIterator.next(TransformedIterator.java:48)
at java.util.AbstractCollection.addAll(AbstractCollection.java:341)
at java.util.LinkedHashSet.<init>(LinkedHashSet.java:169)
at com.google.common.collect.Sets.newLinkedHashSet(Sets.java:292)
at org.glassfish.jersey.internal.inject.Providers.getClasses(Providers.java:336)
at org.glassfish.jersey.internal.inject.Providers.getAllProviders(Providers.java:323)
at org.glassfish.jersey.internal.inject.Providers.getAllProviders(Providers.java:213)
at org.glassfish.jersey.internal.ExceptionMapperFactory.<init>(ExceptionMapperFactory.java:158)
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:526)
at org.glassfish.hk2.utilities.reflection.ReflectionHelper.makeMe(ReflectionHelper.java:1091)
at org.jvnet.hk2.internal.ClazzCreator.createMe(ClazzCreator.java:244)
at org.jvnet.hk2.internal.ClazzCreator.create(ClazzCreator.java:319)
at org.jvnet.hk2.internal.SystemDescriptor.create(SystemDescriptor.java:448)



 Comments   
Comment by Jakub Podlesak [ 22/Apr/14 04:57 PM ]

I am sorry, but i do not see this file updated: https://github.com/hmashlah/glassfish4-test/blob/master/src/main/java/sample/gf4/exceptions/TestExceptionMapper.java

Comment by Jakub Podlesak [ 22/Apr/14 04:58 PM ]

The exception mapper itself must be made a CDI bean in order to have it CDI injected. I hope that clarifies.

Comment by Jakub Podlesak [ 22/Apr/14 05:01 PM ]

updated test case





[JERSEY-2490] Declarative linking recurses into too many things Created: 22/Apr/14  Updated: 25/Apr/14

Status: Open
Project: jersey
Component/s: None
Affects Version/s: 2.7
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: ojacobson Assignee: Unassigned
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: incomplete
Participants: Libor Kramolis and ojacobson

 Description   

There's no way to stop @InjectLink processing from descending into an object, making it impractical to use code like

@InjectLink(
	resource = Hex.class,
	method = "create",
	condition = "${instance.canCreateHex}")
private String createHex;
private SecurityContext securityContext; // trouble

@JsonInclude(Include.NON_NULL)
public String getCreateHex() {
	return createHex;
}

@JsonIgnore
public boolean isCanCreateHex() {
	return securityContext.isUserInRole("ROLE_CREATE_HEX");
}

Spring-security's SecurityContext is the specific case that bit me, since it contains a huge amount of data, including whole classloaders. Any large data structure would cause the same problem.

Having an @NoLink annotation, or stopping recursion at transient fields, would make it easier to use non-serialized information to decide whether to generate links.



 Comments   
Comment by Libor Kramolis [ 22/Apr/14 02:14 PM ]

I'm sorry I don't see your problem. Where is a recursion? What field should be transient? On which fields/methods could be @NoLink annotation used and what is meaning of that annotation? Thanks for more explanation.

Comment by ojacobson [ 25/Apr/14 01:01 AM ]

The SecurityContext field takes a very long time to scan for link injection, because it connects to a very large data structure including ClassLoaders and other large, "internal" objects. It's not technically part of the response, and won't be serialized by Jackson (note the lack of @JsonInclude), but @InjectLink processing doesn't know that, so inspects it "just in case" I send it back.

It turns out that having large contextual objects attached to responses can be useful. The example in the ticket uses a context object (the SecurityContext) to control the behaviour of other response processors (Jackson, InjectLink processing). Unfortunately, while Jackson is smart enough not to recurse through objects it's not serializing, there's no mechanism for InjectLink processing to do the same thing.

Rather than building a special-case thing that tries to recognize this kind of context object, it'd be nice (see ticket type) if there was a way to mark them explicitly, to stop InjectLink from considering them or recursing through them.





[JERSEY-2489] @Custom annotation for MessageBodyWriter and MessageBodyReader is not honored Created: 21/Apr/14  Updated: 24/Apr/14

Status: Open
Project: jersey
Component/s: media
Affects Version/s: 2.6
Fix Version/s: backlog

Type: Bug Priority: Major
Reporter: jasonzhang2002gmailcom Assignee: Unassigned
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Tomcat+Jersey


Tags: Entity Provider Custom Rank incomplete
Participants: jasonzhang2002gmailcom and Michal Gajdos

 Description   

Hi,
I have a custom MessageBodyWriter and MessageBodyReader. I want to let Jersey to add my provider at the beginning of provider Chain. I registered my Provider like this
X.register(myProvider.class, 1000).

I noticed that at client side (clientConfig.register), the provider is always Custom provider. It is always non-custom provider whether I annotate the provider with @org.glassfish.jersey.internal.inject.Custom or not. The same behavior applies to ConfigurableMoxyJsonProvider.

Also the bindingPriority (1000 here) is not honored since my provider is always behind ConfigurableMoxyJsonProvider. I want my provider before ConfigurableMoxyJsonProvider.

How can I make jerset at server-side to know my provider is custom?



 Comments   
Comment by jasonzhang2002gmailcom [ 21/Apr/14 06:21 PM ]

It is always non-custom provider at server side(resourceConfig.register)

Comment by Michal Gajdos [ 22/Apr/14 02:18 PM ]

Your provider is a custom one. Is your provider based on MOXy provider? Is it annotated with @Produces/@Consumes annotations or do you handle media types in isReadable/isWriteable methods?

Comment by jasonzhang2002gmailcom [ 22/Apr/14 03:47 PM ]

Here is how my provider looks like

@Provider
@Produces({MediaType.APPLICATION_JSON, MediaType.APPLICATION_XML} )
@Consumes({MediaType.APPLICATION_JSON, MediaType.APPLICATION_XML})
@Custom
@Priority(1000)
public class JaxbJsonProvider implements MessageBodyReader<Object>, MessageBodyWriter<Object>{
....
}

I add breakpoint in jerysey code so I can find out whether it is custom or not. At client side, it is. At server side, it is not.

-jason

Comment by jasonzhang2002gmailcom [ 24/Apr/14 10:41 PM ]

I worked around this by
1. make JaxbJsonProvider a generic class.

public class JaxbJsonProvider<T> implements MessageBodyReader<T>, MessageBodyWriter<T>{
....
}

2. Make a subclass for every type JaxbJsonProvider can handle.

public class Y extends JaxbJsonProvider<x> {
//no code
}

3. register all subclasses.
config.register(Y.class);





[JERSEY-2488] Declaring a dependency on jersey-client causes NoClassDefFoundError Created: 21/Apr/14  Updated: 23/Apr/14  Resolved: 23/Apr/14

Status: Resolved
Project: jersey
Component/s: core, docs
Affects Version/s: 2.7
Fix Version/s: 2.8

Type: Bug Priority: Minor
Reporter: cowwoc Assignee: Jakub Podlesak
Resolution: Fixed Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: cowwoc and Jakub Podlesak

 Description   

JERSEY-2104 shows that users (myself included) are trying to limit the use of jersey-client to test-only scope. It took me a couple of minutes to figure out why I was getting NoClassDefFoundError: org/glassfish/jersey/client/ClientConfig in non-test code when I didn't define an <exclusion>> for jersey-client. Upon more research I discovered that jersey-container-servlet depends on jersey-client and by adding an explicit dependency on it (but limiting it to test scope) I was effectively excluding the dependency.

I think we can correct this problem in one of two ways:

  1. Ideally, jersey-container-servlet should not depend on jersey-client.
  2. If that isn't possible, we should improve the documentation on the matter.

#1 was discussed on the mailing list: https://java.net/projects/jersey/lists/users/archive/2014-03/message/123

but I think we can still implement this if we move the provider-related code into its own module and have both the client and server modules depend on that.

As for #2, the documentation instructs users:

<!-- if you are using Jersey client specific features -->
<dependency>
    <groupId>org.glassfish.jersey.core</groupId>
    <artifactId>jersey-client</artifactId>
    <version>2.7</version>
</dependency>

This isn't strictly incorrect, but is unnecessary (since the dependency is still there). The only time the user will need to add an explicit dependency is if they are not already dependending on the server.

The danger of having the user include this dependency unnecessarily is that (in my particular case) I included it because the documentation said I should. Then a few days later I added <scope>test</scope> because I was only using the client in unit tests. Then all of a sudden I ran into the exception mentioned in JERSEY-2104.

I think we are better off if users don't add this dependency at all when it was unnecessary. To that end, I recommend changing the comment from "if you are using Jersey client specific features" to "if you are using Jersey client without a server".



 Comments   
Comment by Jakub Podlesak [ 22/Apr/14 02:32 PM ]

Updated user guide submitted for review.





[JERSEY-2487] Response with JSONP fails in exception mapper Created: 21/Apr/14  Updated: 22/Apr/14  Resolved: 22/Apr/14

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

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

Tags:
Participants: Libor Kramolis and vickl

 Description   

Due to JERSEY-2294, I updated Jersey from 2.5 to 2.7, then catch following exception:

org.glassfish.jersey.message.internal.MessageBodyProviderNotFoundException: MessageBodyWriter not found for media type=application/x-javascript, type=class com.ehm.application.validation.bean.ValidationErrorResponse, genericType=class com.ehm.application.validation.bean.ValidationErrorResponse.
	at org.glassfish.jersey.message.internal.WriterInterceptorExecutor$TerminalWriterInterceptor.aroundWriteTo(WriterInterceptorExecutor.java:247)
	at org.glassfish.jersey.message.internal.WriterInterceptorExecutor.proceed(WriterInterceptorExecutor.java:162)
	at org.glassfish.jersey.filter.LoggingFilter.aroundWriteTo(LoggingFilter.java:293)
	at org.glassfish.jersey.message.internal.WriterInterceptorExecutor.proceed(WriterInterceptorExecutor.java:162)
	at org.glassfish.jersey.server.internal.JsonWithPaddingInterceptor.aroundWriteTo(JsonWithPaddingInterceptor.java:103)
	at org.glassfish.jersey.message.internal.WriterInterceptorExecutor.proceed(WriterInterceptorExecutor.java:162)
	at org.glassfish.jersey.server.internal.MappableExceptionWrapperInterceptor.aroundWriteTo(MappableExceptionWrapperInterceptor.java:88)
	at org.glassfish.jersey.message.internal.WriterInterceptorExecutor.proceed(WriterInterceptorExecutor.java:162)
	at org.glassfish.jersey.message.internal.MessageBodyFactory.writeTo(MessageBodyFactory.java:1154)
	at org.glassfish.jersey.server.ServerRuntime$Responder.writeResponse(ServerRuntime.java:571)
	at org.glassfish.jersey.server.ServerRuntime$Responder.processResponse(ServerRuntime.java:378)
	at org.glassfish.jersey.server.ServerRuntime$Responder.process(ServerRuntime.java:418)
	at org.glassfish.jersey.server.ServerRuntime$1.run(ServerRuntime.java:265)
	at org.glassfish.jersey.internal.Errors$1.call(Errors.java:271)
	at org.glassfish.jersey.internal.Errors$1.call(Errors.java:267)
	at org.glassfish.jersey.internal.Errors.process(Errors.java:315)
	at org.glassfish.jersey.internal.Errors.process(Errors.java:297)
	at org.glassfish.jersey.internal.Errors.process(Errors.java:267)
	at org.glassfish.jersey.process.internal.RequestScope.runInScope(RequestScope.java:320)
	at org.glassfish.jersey.server.ServerRuntime.process(ServerRuntime.java:236)
	at org.glassfish.jersey.server.ApplicationHandler.handle(ApplicationHandler.java:1028)
	at org.glassfish.jersey.servlet.WebComponent.service(WebComponent.java:373)
	at org.glassfish.jersey.servlet.ServletContainer.service(ServletContainer.java:381)
	at org.glassfish.jersey.servlet.ServletContainer.service(ServletContainer.java:344)
	at org.glassfish.jersey.servlet.ServletContainer.service(ServletContainer.java:219)
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:305)
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
	at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:222)
	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:123)
	at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:502)
	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:171)
	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:99)
	at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:953)
	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118)
	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:408)
	at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1023)
	at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:589)
	at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:310)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
	at java.lang.Thread.run(Thread.java:722)

Here is my code:

@Provider
public class ValidationExceptionMapper implements ExceptionMapper<ValidationException> {
    
    Log log = LogFactory.getLog(getClass());
    
    @Context
    private UriInfo uriInfo;

    @Override
    @JSONP(queryParam = "callback")
    public Response toResponse(ValidationException exception) {
        if (exception instanceof ConstraintViolationException) {
            log.debug(String.format("Constraint Violation occurred at resource path: %s", uriInfo.getPath()));

            ConstraintViolationException cve = (ConstraintViolationException) exception;
            ValidationErrorResponse err = new ValidationErrorResponse();
            err.setErrors(ValidationAssistant.convertToValidationErrors(cve));
            
           
            return Response.status(Response.Status.BAD_REQUEST).entity(err).type("application/x-javascript").build();
        } else {
            return Response.serverError().entity(exception.getMessage()).build();
        }

    }

}

I debug the code and found it might be caused by @JSONP Annotation is not set into org.glassfish.jersey.server.ContainerResponse.messageContext, then skip the logic in JsonWithPaddingInterceptor:

if (wrapIntoCallback) {
            context.setMediaType(MediaType.APPLICATION_JSON_TYPE);

            context.getOutputStream().write(getCallbackName(jsonp).getBytes());
            context.getOutputStream().write('(');
        }


 Comments   
Comment by Libor Kramolis [ 22/Apr/14 03:29 PM ]

@JSONP as well as other annotations used on resource methods are not supported on ExceptionMapper.toResponse method.

But I have good news to you. There is a way how to send JSONP annotation instance with response entity, e.g.:

return Response.status(Response.Status.BAD_REQUEST).entity(err, new Annotation[] {JSONPFactory.get("callback")}).type("application/x-javascript").build();

And example of JSONPFactory is:

public static class JSONPFactory extends AnnotationLiteral<JSONP> implements JSONP {
   String queryParam;

   private Factory(String queryParam) {
       this.queryParam = queryParam;
   }

   public static JSONP get(String queryParam) {
       return new Factory(queryParam);
   }

   @Override
   public String callback() {
       return null;
   }

   @Override
   public String queryParam() {
       return queryParam;
   }
}




[JERSEY-2486] Clarify Javadoc of PatternWithGroups.getGroupIndexes() Created: 21/Apr/14  Updated: 24/Apr/14  Resolved: 24/Apr/14

Status: Resolved
Project: jersey
Component/s: core
Affects Version/s: 2.7
Fix Version/s: 2.8

Type: Improvement Priority: Minor
Reporter: cowwoc Assignee: Michal Gajdos
Resolution: Fixed Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: cowwoc and Michal Gajdos

 Description   

The Javadoc for PatternWithGroups.getGroupIndexes() reads Get the group indexes which doesn't actually explain why we need them (i.e. why not just use getGroupCount()?)

I walked backwards through the code and figured out that indexes come from UriTemplateParser which provides the following (useful) explanation:

/**
     * Get the group indexes to capturing groups.
     * <p>
     * Any nested capturing groups will be ignored and the
     * the group index will refer to the top-level capturing
     * groups associated with the templates variables.
     *
     * @return the group indexes to capturing groups.
     */
    public final int[] getGroupIndexes() {

Please copy this Javadoc into PatternWithGroups.getGroupIndexes()



 Comments   
Comment by cowwoc [ 21/Apr/14 04:47 PM ]

I just discovered that sometimes (always in my case) this method returns an empty list in spite of the fact that the template has multiple groups. The Javadoc should also clarify when we can depend on this list being populated or not.

Comment by cowwoc [ 24/Apr/14 12:31 PM ]

Michael,

Looking at https://github.com/jersey/jersey/commit/47266536bb588ce54e99875f1bcec63653317dda was the old implementation of getGroupIndexes() broken? Was that why I was receiving an empty array?

Comment by Michal Gajdos [ 24/Apr/14 12:56 PM ]

Yep. In Jersey < 2.8 you get an empty array in two cases:

  • there are no templates in provided Uri
  • templates don't contain nested groups (you'd get non-empty array just for templates like "/{a: (abc)+}"). In this case there'd be n groups (where n is number of templates) which you can refer to via 1..n but you need to find out the value of n.

    Now (Jersey > 2.8) you'll get an non-empty array in case there is at least one template in Uri:

    - in case of "/{a}/{b}" you'll get "identity": a[0] = 1, a[1] = 2, a[2] = 3
    - in case of "/{a: (abc)+}/{b}" you'll get: a[0] = 1, a[1] = 3, a[2] = 4
Comment by cowwoc [ 24/Apr/14 01:26 PM ]

Michal,

In the case of "/{a}/{b}" why would I get a[2] = 3? I am only expecting the first two entries (one for "a" and one for "b").

Comment by Michal Gajdos [ 24/Apr/14 04:38 PM ]

Hi Gili, good point, you're right. If I am not mistaken the intention (in Jersey 1.x) was that the first member of the array would represent a group for the whole Uri. But it doesn't work now. I'll file a new issue and fix it (unfortunately the fix wouldn't be part of 2.8).

Comment by cowwoc [ 24/Apr/14 05:04 PM ]

Michal,

Group for the whole URI: Why do we need this? Doesn't group(0) already provide that value?
New issue: Okay, please post the link here when it's ready.





[JERSEY-2485] ValueFactoryProvider implementations parse relative to ContainerRequest instead of the Resource Created: 20/Apr/14  Updated: 22/Apr/14

Status: Open
Project: jersey
Component/s: core
Affects Version/s: 2.7
Fix Version/s: backlog

Type: Bug Priority: Major
Reporter: cowwoc Assignee: Unassigned
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: unplanned
Participants: cowwoc

 Description   

ValueFactoryProvider implementations (MatrixParamValueFactoryProvider, PathParamValueFactoryProvider, QueryParamValueFactoryProvider and WebTargetValueFactoryProvider) look up the parameter values relative to getContainerRequest().getUriInfo() instead of relative to the associated Resource.

This blocks implementing JERSEY-2172.



 Comments   
Comment by cowwoc [ 20/Apr/14 09:40 PM ]

To clarify, I am invoking:

ExtendedResourceContext resourceContext = serviceLocator.getService(ExtendedResourceContext.class);
Resource rootResource = resourceContext.getResourceModel().getRootResources().get(0);
Resource childResource = rootResource.getChildResources().get(0);
Factory<?> valueProvider = childResource.getResourceLocator().getInvocable().getValueProviders(serviceLocator).get(0);

I expect the valueProvider to return the value of the first parameter of the resource locator of childResource, but instead it returns value for the resource that matched the current HTTP request.

I believe you will need to change getValueProviders() to take a URI parameter to be parsed. Otherwise, move Invocable.getValueProviders() to UriInfo.getValueProviders() because it is misleading in its current form (the method doesn't actually return values relative to the invocable but rather relative to UriInfo).





[JERSEY-2484] Memory leak in GrizzlyHttpServerFactory when HttpServer.start throw exception Created: 20/Apr/14  Updated: 22/Apr/14

Status: Open
Project: jersey
Component/s: containers
Affects Version/s: 2.6, 2.7, 2.8
Fix Version/s: backlog

Type: Bug Priority: Minor
Reporter: turbanoff Assignee: Unassigned
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: close grizzly memory-leak pull-request thread-pool
Participants: Libor Kramolis and turbanoff

 Description   

Java code to reproduce bug:

ServerSocket socket = new ServerSocket(9874); //make port busy

        URI uri = UriBuilder.fromUri("http://localhost:9874").build();
        while (true) {
            HttpServer server = null;
            try {
                server = GrizzlyHttpServerFactory.createHttpServer(uri); //try bind HttpServer to same port
            } catch (ProcessingException ignored) {
                //BindException will be thrown
            } finally {
                if (server != null) {
                    System.out.println("Shutdown server."); //never executed (server always == null)
                    server.shutdownNow();
                }
            }
        }

GrizzlyHttpServerFactory.createHttpServer does not shutdown org.glassfish.grizzly.http.server.HttpServer when server.start() method throw exception.



 Comments   
Comment by turbanoff [ 20/Apr/14 05:58 PM ]

Code to reproduce:

ServerSocket socket = new ServerSocket(9874); //bind port to other app

        URI uri = UriBuilder.fromUri("http://localhost:9874").build();
        while (true) {
            HttpServer server = null;
            try {
                server = GrizzlyHttpServerFactory.createHttpServer(uri); //try bind HttpServer to same port
            } catch (ProcessingException ignored) {
                //BindException will be thrown
            } finally {
                if (server != null) {
                    System.out.println("Shutdown server."); //never executed (server always == null)
                    server.shutdownNow();
                }
            }
        }
Comment by Libor Kramolis [ 22/Apr/14 08:43 AM ]

Thanks, @turbanoff has already submitted a pull request https://github.com/jersey/jersey/pull/79.





[JERSEY-2483] Jersey uses third-party dependencies not hosted on Maven Central Created: 18/Apr/14  Updated: 19/Apr/14

Status: Open
Project: jersey
Component/s: None
Affects Version/s: 2.7
Fix Version/s: backlog

Type: Bug Priority: Minor
Reporter: Michael Osipov Assignee: Unassigned
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: Michael Osipov

 Description   

Several POMs declare third-party repostories. When cloning from Git and building master, the build fails with:

[ERROR] Failed to execute goal on project html-json: Could not resolve dependencies for project org.glassfish.jersey.med
ia:html-json:jar:2.8-SNAPSHOT: Could not find artifact org.netbeans.api:org-openide-util-lookup:jar:RELEASE73 in ...

So several dependencies are not in Central. This contradicts the philosophy of Maven central and is highly discourated by the Apache Maven team and Sonatype OSS.

Require all third-party components to be available on Central. This is especially a problem if someone is behind a corporate proxy like me and relies on an intranet Nexus instance.

Moreover, released artifacts on Maven Central are broken, e.g. HTML JSON and may lead to silent build/runtime errors.






[JERSEY-2482] Jersey client should not require PUT to have an entity body Created: 18/Apr/14  Updated: 22/Apr/14

Status: Open
Project: jersey
Component/s: core
Affects Version/s: 2.7
Fix Version/s: backlog

Type: Bug Priority: Minor
Reporter: cowwoc Assignee: Unassigned
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: unplanned http-compliance
Participants: cowwoc and craigmcc

 Description   

JERSEY-2288 states that users who wish to PUT with a null entity should enable SUPPRESS_HTTP_COMPLIANCE_VALIDATION

I understand that you're trying to steer users in the right direction but, contrary to the property name, this isn't an HTTP compliance matter. As such, your usage of this property is misleading. I've reviewed the latest HTTP specification and there is no mention of this being a problem. If you've got some HTTP specification references that indicate otherwise, please provide them.

Please consider using a separate property for suppressing these kind of subjective validation rules, perhaps SUPPRESS_HTTP_RECOMMENDATIONS_VALIDATION.



 Comments   
Comment by cowwoc [ 18/Apr/14 04:38 AM ]

Relevant reading materials:

http://stackoverflow.com/q/14323716/14731
http://stackoverflow.com/a/5928241/14731

Comment by craigmcc [ 18/Apr/14 05:50 AM ]

Just out of curiousity, how does version 26 of an IETF draft proposal (in a process that has been going on for over six years) get elevated to be the "latest HTTP specification"?

Comment by cowwoc [ 18/Apr/14 06:01 AM ]

You're splitting hairs. The draft contains many clarifications on how the 1.1 specification was meant to be interpreted, and R. Fielding has led both specifications. And obviously, one day the draft will become the new standard.

My point still stands: where in the HTTP specification does it mandate that the PUT method MUST be passed an entity body?





Generated at Fri Apr 25 02:53:02 UTC 2014 using JIRA 4.0.2#472.