[JERSEY-2843] InboundMessageContext.hasEntity() fails to catch IllegalStateException even though it tries to. Created: 17/Apr/15  Updated: 17/Apr/15

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

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


 Description   

InboundMessageContext.hasEntity() fails to catch IllegalStateException even though it tries to.

Example:

if (response.hasEntity())

{ Object object = response.readEntity(....) .... do stuff }

If the response stream has been closed then the response.hasEntity() will throw an exception due to an extra entityContent.ensureNotClosed() check inside hasEntity(), skipping the try catch that follows, and never return false. Under such conditions there is no safe way to check whether an entity exists.

The fix and updated unit test is included in:
https://github.com/jersey/jersey/pull/138






[JERSEY-2842] Improve error when http response is written Created: 17/Apr/15  Updated: 17/Apr/15

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

Type: Improvement Priority: Major
Reporter: sebadiaz Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

all



 Description   

need to return the response in sending the actual response.

java.lang.IllegalArgumentException: setContentLength(0) when already written 159
at org.eclipse.jetty.server.Response.setContentLength(Response.java:990)
at org.glassfish.jersey.servlet.internal.ResponseWriter.writeResponseStatusAndHeaders(ResponseWriter.java:142)
at org.glassfish.jersey.server.ServerRuntime$Responder$1.getOutputStream(ServerRuntime.java:611)
at org.glassfish.jersey.message.internal.CommittingOutputStream.commitStream(CommittingOutputStream.java:200)
at org.glassfish.jersey.message.internal.CommittingOutputStream.flushBuffer(CommittingOutputStream.java:305)
at org.glassfish.jersey.message.internal.CommittingOutputStream.commit(CommittingOutputStream.java:261)
at org.glassfish.jersey.message.internal.CommittingOutputStream.close(CommittingOutputStream.java:276)
at org.glassfish.jersey.message.internal.OutboundMessageContext.close(OutboundMessageContext.java:834)
at org.glassfish.jersey.server.ContainerResponse.close(ContainerResponse.java:411)
at org.glassfish.jersey.server.ServerRuntime$Responder.writeResponse(ServerRuntime.java:691)






[JERSEY-2837] GrizzlyConnector can cause Jersey to return premature end stream Created: 08/Apr/15  Updated: 17/Apr/15  Resolved: 17/Apr/15

Status: Resolved
Project: jersey
Component/s: core
Affects Version/s: 2.17
Fix Version/s: 2.18

Type: Bug Priority: Critical
Reporter: luengnat Assignee: Marek Potociar
Resolution: Fixed Votes: 0
Labels: pull-request
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

There is a bug in handling byte stream that contains 0xFF byte. When it does, it will treat the byte as EOF marker instead. This is due to mishandling of negative byte values



 Comments   
Comment by Libor Kramolis [ 08/Apr/15 ]

@luengnat May you provide us more information about the issue? Where the bug is and how to reproduce it. May you prepare reproducible test case? Thanks.

Comment by luengnat [ 08/Apr/15 ]

The test case is already there in the patch.
https://github.com/jersey/jersey/pull/155

Comment by luengnat [ 08/Apr/15 ]

It's a duplicate of JERSEY-2817, JERSEY-2498

Comment by luengnat [ 16/Apr/15 ]

Code is ready to be merged
https://github.com/jersey/jersey/pull/155





[JERSEY-2503] Unable to register custom JacksonJsonProvider - default one always gets registered Created: 03/May/14  Updated: 17/Apr/15  Resolved: 05/May/14

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

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

Java 7, Jersey 26 and 2.7


Tags: java, jersey, json, provider

 Description   

The JacksonJsonProvider is discovered even though I disabled all auto-discoveries. As a result I cannot register my own which provides a custom ObjectMapper. The default one is always used instead.

The issue is explained in details here:
http://stackoverflow.com/questions/23441095/how-to-disable-jerseys-jacksonjsonprovider-auto-registration-so-i-use-my-own



 Comments   
Comment by Michal Gajdos [ 05/May/14 ]

You don't need to create a custom Provider to use custom ObjectMapper. See [1] where you can find configuration of custom ObjectMapper. This way you don't need to worry about providing your own message body provider.

I assume you're using Jackson 2.x (which is registered automatically). Can you share with us how do you disable automatic discovery?

(I am closing this issue as won't fix for now, feel free to let me know whether you still have problems and the issue should be reopened)

[1] https://jersey.java.net/documentation/latest/media.html#json.jackson

Comment by tommcgee [ 17/Apr/15 ]

I have what looks like a fix/hack/kludge. Made a nop-JacksonJsonProvider that I register in the JerseyConfig.
You can see the nop JacksonJsonProvider builder code on the same stackoverflow link from above:
http://stackoverflow.com/questions/23441095/how-to-disable-jerseys-jacksonjsonprovider-auto-registration-so-i-use-my-own





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

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

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

Java 1.6, Grizzly 1.9.27, Jackson 1.7.8



 Description   

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

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

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

if(in.available() > 0) {

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



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

can you share testcase?

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

Comment by vguna [ 10/Apr/12 ]

Same here.

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

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

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

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

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

Comment by basalt79 [ 30/May/12 ]

Hi, I have the same problem like vguna.

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

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

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

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

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

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

Also tested with jetty and work fine.

Comment by increment1 [ 04/Feb/13 ]

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

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

Comment by increment1 [ 04/Feb/13 ]

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

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

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

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

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

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

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

The POST is now logged.

Regards.

Comment by Jakub Podlesak [ 23/Jul/13 ]

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

Comment by quilleashm [ 30/Aug/13 ]

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

Jersey 1.17
Jetty 8.1.9

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

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

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

Then the server would get

Incoming connection
Headers received
.. some time passes
Body received

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

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

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

Comment by jagathvijayan [ 16/May/14 ]

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

Comment by dennisgermany [ 27/Oct/14 ]

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

Comment by zeiss [ 20/Nov/14 ]

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

Comment by luisjotapepe [ 28/Mar/15 ]

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

Comment by smarni [ 17/Apr/15 ]

1.17 or 1.8 not able to log the request body





[JERSEY-2626] Glassfish / Jersey throws NPE on startup of versioned app Created: 24/Aug/14  Updated: 17/Apr/15

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

Type: Bug Priority: Critical
Reporter: lprimak Assignee: Unassigned
Resolution: Unresolved Votes: 1
Labels: None
Σ Remaining Estimate: Not Specified Remaining Estimate: Not Specified
Σ Time Spent: Not Specified Time Spent: Not Specified
Σ Original Estimate: Not Specified Original Estimate: Not Specified
Environment:

Initiating Jersey application, version Jersey: 2.10.4 2014-08-08 15:09:00…]]
Glassfish 4.1 promoted build downloaded August 20th, 2014


Issue Links:
Cloners
is cloned by JERSEY-2629 CLONE - Glassfish / Jersey throws NPE... Closed
Duplicate
is duplicated by JERSEY-2807 Glassfish / Jersey throws NPE on star... Resolved
Sub-Tasks:
Key
Summary
Type
Status
Assignee
JERSEY-2752 This critical issue still exists Sub-task Open  
Tags: jersey

 Description   

Application fails to start in a Availability-enabled clustered environment.
The application works in the same domain when not deployed in a cluster.

Here is the NPE:

[2014-08-24T05:28:38.406-0400] [glassfish 4.1] [INFO] [] [org.glassfish.jersey.server.ApplicationHandler] [tid: _ThreadID=18 _ThreadName=RunLevelControllerThread-1408872414218] [timeMillis: 1408872518406] [l
evelValue: 800] [[
Initiating Jersey application, version Jersey: 2.10.4 2014-08-08 15:09:00...]]

[2014-08-24T05:28:38.787-0400] [glassfish 4.1] [SEVERE] [] [javax.enterprise.web] [tid: _ThreadID=18 _ThreadName=RunLevelControllerThread-1408872414218] [timeMillis: 1408872518787] [levelValue: 1000] [[
WebModule[/stage]StandardWrapper.Throwable
java.lang.NullPointerException
at org.glassfish.jersey.gf.ejb.internal.EjbComponentProvider.registerEjbInterceptor(EjbComponentProvider.java:169)
at org.glassfish.jersey.gf.ejb.internal.EjbComponentProvider.bind(EjbComponentProvider.java:251)
at org.glassfish.jersey.server.ApplicationHandler.bindWithComponentProvider(ApplicationHandler.java:903)
at org.glassfish.jersey.server.ApplicationHandler.bindProvidersAndResources(ApplicationHandler.java:832)
at org.glassfish.jersey.server.ApplicationHandler.initialize(ApplicationHandler.java:435)
at org.glassfish.jersey.server.ApplicationHandler.access$500(ApplicationHandler.java:163)
at org.glassfish.jersey.server.ApplicationHandler$3.run(ApplicationHandler.java:323)
at org.glassfish.jersey.internal.Errors$2.call(Errors.java:289)
at org.glassfish.jersey.internal.Errors$2.call(Errors.java:286)
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.processWithException(Errors.java:286)
at org.glassfish.jersey.server.ApplicationHandler.<init>(ApplicationHandler.java:320)
at org.glassfish.jersey.server.ApplicationHandler.<init>(ApplicationHandler.java:285)
at org.glassfish.jersey.servlet.WebComponent.<init>(WebComponent.java:310)
at org.glassfish.jersey.servlet.ServletContainer.init(ServletContainer.java:170)
at org.glassfish.jersey.servlet.ServletContainer.init(ServletContainer.java:358)
at javax.servlet.GenericServlet.init(GenericServlet.java:244)
at org.apache.catalina.core.StandardWrapper.initServlet(StandardWrapper.java:1583)
at org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:1382)
at org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java:5704)
at org.apache.catalina.core.StandardContext.start(StandardContext.java:5946)
at com.sun.enterprise.web.WebModule.start(WebModule.java:691)
at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:1041)
at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:1024)
at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:747)
at com.sun.enterprise.web.WebContainer.loadWebModule(WebContainer.java:2286)
at com.sun.enterprise.web.WebContainer.loadWebModule(WebContainer.java:1932)
at com.sun.enterprise.web.WebApplication.start(WebApplication.java:139)
at org.glassfish.internal.data.EngineRef.start(EngineRef.java:122)
at org.glassfish.internal.data.ModuleInfo.start(ModuleInfo.java:291)
at org.glassfish.internal.data.ApplicationInfo.start(ApplicationInfo.java:352)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:500)
at com.sun.enterprise.v3.server.ApplicationLoaderService.processApplication(ApplicationLoaderService.java:406)
at com.sun.enterprise.v3.server.ApplicationLoaderService.postConstruct(ApplicationLoaderService.java:243)
at org.jvnet.hk2.internal.ClazzCreator.postConstructMe(ClazzCreator.java:329)
at org.jvnet.hk2.internal.ClazzCreator.create(ClazzCreator.java:377)
at org.jvnet.hk2.internal.SystemDescriptor.create(SystemDescriptor.java:461)
at org.glassfish.hk2.runlevel.internal.AsyncRunLevelContext.findOrCreate(AsyncRunLevelContext.java:227)
at org.glassfish.hk2.runlevel.RunLevelContext.findOrCreate(RunLevelContext.java:84)
at org.jvnet.hk2.internal.Utilities.createService(Utilities.java:2258)
at org.jvnet.hk2.internal.ServiceHandleImpl.getService(ServiceHandleImpl.java:105)
at org.jvnet.hk2.internal.ServiceHandleImpl.getService(ServiceHandleImpl.java:87)
at org.glassfish.hk2.runlevel.internal.CurrentTaskFuture$QueueRunner.oneJob(CurrentTaskFuture.java:1162)
at org.glassfish.hk2.runlevel.internal.CurrentTaskFuture$QueueRunner.run(CurrentTaskFuture.java:1147)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)



 Comments   
Comment by lprimak [ 24/Aug/14 ]

I believe (this is just a guess) this is due to my application named my_app:20140824
I think some parts of GF are broken with this naming convention now.
This is crucial for clusters as it supports hot-deployment.

I believe other parts of Glassfish are broken in regards to application versioning

Comment by lprimak [ 24/Aug/14 ]

Yup. This is confirmed. Same application runs fine when not versioned,
i.e. deployed as my_app as opposed to my_app:20140824
Application versioning is broken.

Comment by Jakub Podlesak [ 01/Sep/14 ]

This is probably related to how Jersey uses GF internal API to get EJB info. The issue should be reproducible
also in a standalone server deployment (no cluster needed IIUC).

            final EjbContainerUtil ejbUtil = EjbContainerUtilImpl.getInstance();
            final ApplicationInfo appInfo = ejbUtil.getDeployment().get((String)initialContext.lookup("java:app/AppName"));

Above we need to make sure the version suffix is trimmed out if present.

Comment by Jakub Podlesak [ 01/Sep/14 ]

Hmmm, new InitialContext().lookup("java:app/AppName") works fine, the problem is in getting application info, as there
apparently the version info is required.

Comment by Jakub Podlesak [ 02/Sep/14 ]

Here is a link to application versioning doc: http://docs.oracle.com/cd/E18930_01/html/821-2417/gihzx.html#gkhhv

Moving this issue to backlog.

Comment by lprimak [ 08/Jan/15 ]

This is still an issue. Any updates are appreciated.
This prevents deployment of version applications using jersey on glassfish.

Comment by lprimak [ 27/Feb/15 ]

I am very surprised by lack of activity on this issue.
I even have a private patch for it.
It's hard for me to believe that no one is using Jersey versioned applications on GlassFish.

Comment by Andybailey [ 17/Mar/15 ]

We need to use versioned deployment too, this is broken as described and is critical to our deployment scenario.

Comment by Michal Gajdos [ 17/Mar/15 ]

@lprimak - Can you provide your patch as a GitHub pull request?

Comment by lprimak [ 23/Mar/15 ]

I am not very well familiar with git / github (I use Mercurial)
but here is the patch pasted here, it's not very large.
The only need is to compile / replace jersey-gf-ejb directory with this patch

VersionBug.patch
diff --git a/containers/glassfish/jersey-gf-ejb/src/main/java/org/glassfish/jersey/gf/ejb/internal/EjbComponentProvider.java b/containers/glassfish/jersey-gf-ejb/src/main/java/org/glassfish/jersey/gf/ejb/internal/EjbComponentProvider.java
index f08c81a..7d429be 100644
--- a/containers/glassfish/jersey-gf-ejb/src/main/java/org/glassfish/jersey/gf/ejb/internal/EjbComponentProvider.java
+++ b/containers/glassfish/jersey-gf-ejb/src/main/java/org/glassfish/jersey/gf/ejb/internal/EjbComponentProvider.java
@@ -42,6 +42,8 @@
 import com.sun.ejb.containers.BaseContainer;
 import com.sun.ejb.containers.EjbContainerUtil;
 import com.sun.ejb.containers.EjbContainerUtilImpl;
+import com.sun.enterprise.config.serverbeans.Application;
+import com.sun.enterprise.config.serverbeans.Applications;
 
 import java.lang.annotation.Annotation;
 import java.lang.reflect.InvocationHandler;
@@ -56,9 +58,11 @@
 import java.util.Collection;
 import java.util.Collections;
 import java.util.HashSet;
+import java.util.Iterator;
 import java.util.LinkedList;
 import java.util.List;
 import java.util.Set;
+import java.util.TreeSet;
 import java.util.concurrent.CopyOnWriteArrayList;
 import java.util.logging.Level;
 import java.util.logging.Logger;
@@ -87,6 +91,7 @@
 import org.glassfish.hk2.utilities.binding.ServiceBindingBuilder;
 
 import org.glassfish.internal.data.ApplicationInfo;
+import org.glassfish.internal.data.ApplicationRegistry;
 import org.glassfish.internal.data.ModuleInfo;
 
 /**
@@ -106,7 +111,7 @@
     private final List<String> libNames = new CopyOnWriteArrayList<String>();
 
     private boolean ejbInterceptorRegistered = false;
-
+    
     /**
      * HK2 factory to provide EJB components obtained via JNDI lookup.
      */
@@ -158,13 +163,51 @@
         Injections.addBinding(Injections.newBinder(this).to(ResourceMethodInvocationHandlerProvider.class), configuration);
         configuration.commit();
     }
+    
+    private ApplicationInfo getApplicationInfo(EjbContainerUtil ejbUtil) throws NamingException
+    {
+        ApplicationRegistry appRegistry = ejbUtil.getServices().getService(ApplicationRegistry.class);
+        Applications applications = ejbUtil.getServices().getService(Applications.class);
+        String appNamePrefix = (String) initialContext.lookup("java:app/AppName");
+        Set<String> appNames = appRegistry.getAllApplicationNames();
+        Set<String> disabledApps = new TreeSet<>();
+        for (String appName : appNames) {
+            if (appName.startsWith(appNamePrefix)) {
+                Application appDesc = applications.getApplication(appName);
+                if (appDesc != null && !ejbUtil.getDeployment().isAppEnabled(appDesc)) {
+                    // skip disabled version of the app
+                    disabledApps.add(appName);
+                }
+                else
+                {
+                    return ejbUtil.getDeployment().get(appName);
+                }
+            }
+        }
+        
+        // grab the latest one, there is no way to make
+        // sure which one the user is actually enabling,
+        // so use the best case, i.e. upgrade
+        Iterator<String> it = disabledApps.iterator();
+        String lastDisabledApp = null;
+        while(it.hasNext())
+        {
+            lastDisabledApp = it.next();
+        }
+        if(lastDisabledApp != null) {
+            return ejbUtil.getDeployment().get(lastDisabledApp);
+        }
+        
+        throw new NamingException("Application Information Not Found");
+    }
 
     private void registerEjbInterceptor() {
         try {
             final Object interceptor = new EjbComponentInterceptor(locator);
             initialContext = getInitialContext();
             final EjbContainerUtil ejbUtil = EjbContainerUtilImpl.getInstance();
-            final ApplicationInfo appInfo = ejbUtil.getDeployment().get((String)initialContext.lookup("java:app/AppName"));
+            // FL Patch for https://java.net/jira/browse/GLASSFISH-21173
+            final ApplicationInfo appInfo = getApplicationInfo(ejbUtil);
             final List<String> tempLibNames = new LinkedList<String>();
             for (ModuleInfo moduleInfo : appInfo.getModuleInfos()) {
                 final String jarName = moduleInfo.getName();
Comment by lprimak [ 23/Mar/15 ]

I just figured out how to do pull requests:
https://github.com/jersey/jersey/pull/154

I did not test it against the current code, but it didn't change much so it should work just as well as with production GF 4.1 release

Comment by Jakub Podlesak [ 24/Mar/15 ]

Thanks for the patch! After you sign the OCA, we can proceed further. Please see my comment on your pull request for details.

Comment by lprimak [ 24/Mar/15 ]

Done

Comment by lprimak [ 17/Apr/15 ]

OCA has been approved





[JERSEY-2828] "Jersey bean validation" does not validate @PathParam on sub resource location Created: 20/Mar/15  Updated: 16/Apr/15

Status: Open
Project: jersey
Component/s: extensions
Affects Version/s: 2.14
Fix Version/s: backlog

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


 Description   

Thare is no validation on sub resource location.

For example:

@Path("{resourceId}/action")
public ActionResource actionController(@PathParam("resourceId") @PathId @Pattern(regexp = "\\d{1,10}") String resourceId) {
        ....
}

parameter "resourceId" will not be validated



 Comments   
Comment by Maxonchik [ 16/Apr/15 ]

Validation can be enabled by @ValidateOnExecution, but it could be enabled by default





[JERSEY-2841] @NameBinding is not working on method Created: 16/Apr/15  Updated: 16/Apr/15

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

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

jetty 8, java 7, mac os, jersey 2.17



 Description   

I have the following RootResource class

@Path(value = "/root")
@Produces(value = {MediaType.APPLICATION_XML + RestUtil.CHARSET_UTF8, MediaType.APPLICATION_JSON + RestUtil.CHARSET_UTF8})
public class RootResource implements Resource {
  public RootResource() {
  }

  @Path(value = "/mysubresource")
  @OAuth
  public SubresourceSubresource sub_Mysubresource() {
    return new SubresourceSubresource();
  }
}

There is a filter @OAuth on method sub_Mysubesource() but it's never called for some reason.

OAuth.java

@Retention(RetentionPolicy.RUNTIME)
@NameBinding
public @interface OAuth {
}

OAuthRequestFilter.java

@OAuth
public class OAuthRequestFilter implements ContainerRequestFilter, ContainerResponseFilter {

  public OAuthRequestFilter() {
  }

  public void filter(ContainerRequestContext request) {
    System.out.println("Start OAUTH!");
  }

  public void filter(ContainerRequestContext request, ContainerResponseContext response) {
    System.out.println("End OAUTH!");
  }
  
}

Documentation says that it's a valid case to attach @NameBinding to method. https://jersey.java.net/apidocs/2.17/jersey/javax/ws/rs/NameBinding.html






[JERSEY-2818] RolesAllowedDynamicFeature can return 401 or 403 errors. Created: 10/Mar/15  Updated: 15/Apr/15  Resolved: 19/Mar/15

Status: Resolved
Project: jersey
Component/s: core, security
Affects Version/s: 2.16
Fix Version/s: 2.18

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


 Description   

Currently, the RolesAllowedRequestFilter will always return HTTP 403 Forbidden. This is accurate in all cases where the security context is aware of the principal (securityContext.getUserPrincipal() is not null), however it is not strictly accurate in the case where a user has not been authenticated. In that case, returning HTTP 401 Unauthorized is more accurate, as the user has not provided the correct credentials.

The following code should suffice, if inserted before the role check loop.

if(requestContext.getSecurityContext().getUserPrincipal() == null && rolesAllowed.length > 0)

{ throw new NotAuthorizedException(); }

 Comments   
Comment by Adam Lindenthal [ 11/Mar/15 ]

Hi krotscheck,

thanks for reporting the improvement suggestion.
I will put it to backlog, so that someone can look at it in one of the future sprints.

Regards,
Adam

Comment by brunosimioni [ 18/Mar/15 ]

Guys,

Same problem over here. Since my API with RolesAllowedDynamicFeature is returning 403 instead of 401, Actually, I'm stucked in the same step and I'm currently integrating with others systems with this API. Returning then with forbidden 403 to a non-authenticated user just makes no sense.

Would you guys priorize this issue, or do you have a release date, or even can I make the fix and make a pull request under github repositories?

Best!

Comment by brunosimioni [ 19/Mar/15 ]

Guys,

I've forked the Jersey's github repository, patched up with krotscheck's fix and made a pull request to merge with master branch. Hope you guys accept it as soon as possible, since there is a scheduled build on April.

Please check this out: https://github.com/jersey/jersey/pull/150

Comment by Michal Gajdos [ 19/Mar/15 ]

I'll deliver fix for this internally - it'd be faster.

Comment by brunosimioni [ 19/Mar/15 ]

Thanks Michal!

Would it be available at April 8th?

I'll sign out the OCA too, for future collaborations.

Thank you very much.

Comment by Michal Gajdos [ 19/Mar/15 ]

It'll be in 2.18 (April 8th is approximate but 2.18 should be out that week).

Comment by Michal Gajdos [ 19/Mar/15 ]

Merged into master branch.

Comment by brunosimioni [ 19/Mar/15 ]

Michal, I've just saw you merge. Thank you for that!

Just a question: shouldn't NotAuthorizedException preceeds the ForbiddenException? Authorization should be evaluted before Permission rights, do you agree? Because to check wether the user can or cannot access the resource, it must be known.

In my patch (thanks to krotscheck) I've checked Authorization before DenyAll condition, but in your implementation, you did the inverse.

Best

Comment by andrewzimmer [ 15/Apr/15 ]

Glad to hear that this is going to be taken care of!





[JERSEY-1653] @BeanParam with proxy client does not work Created: 16/Jan/13  Updated: 14/Apr/15

Status: Open
Project: jersey
Component/s: core
Affects Version/s: 2.0-m11
Fix Version/s: backlog

Type: Bug Priority: Minor
Reporter: aaronjwhiteside Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Glassfish 4.0 b72



 Description   

@BeanParam with proxy client does not work

It does not send through the @HeaderParam's in the request... and the SmsResponse from the proxy method call is null.

For example...

@Path( "/" )
public interface ZengMessagingService
{
    @GET
    @Path( "/sms" )
    @BeanParam
    SmsResponse sendSms( @BeanParam SmsRequest request );

}

public class SmsRequest
extends OneTimePasswordRequest
{
    @HeaderParam( "delivery-mode" )
    private int deliveryMode;

    @HeaderParam( "categ" )
    private String subscriptionCategory;

...

public class SmsResponse
extends OneTimePasswordResponse
{
    @HeaderParam( "provisioning-code" )
    private String provisioningCode;

...

Client client = ClientFactory.newClient();
WebTarget target = client.target( "http://localhost:" + port + "/" );
ZengMessagingService zengMessagingService = WebResourceFactory.newResource( ZengMessagingService.class, target );
SmsResponse smsResponse = zengMessagingService.sendSms( smsRequest );


 Comments   
Comment by aaronjwhiteside [ 16/Jan/13 ]

Probably related to JERSEY-1654

Comment by aaronjwhiteside [ 16/Jan/13 ]

Even if I change the sendSms() method from @GET to @POST in my example, it still does not pass through the @HeaderParam's in SmsRequest.

Comment by walec51 [ 14/Apr/15 ]

@BeanParam support is simply not implemented yet in Jersey Proxy Client
https://github.com/jersey/jersey/blob/master/ext/proxy-client/src/main/java/org/glassfish/jersey/client/proxy/WebResourceFactory.java

generally Jersey Proxy Client seams pretty week compared to RESTEasy's Client framework and adding @BeanParam will require a big refactoring of that WebResourceFactory





[JERSEY-2546] wadl OPTIONS request returns 500 Internal Server Error if resource has no "direct" resource method Created: 12/Jun/14  Updated: 13/Apr/15

Status: Open
Project: jersey
Component/s: extensions
Affects Version/s: 2.9
Fix Version/s: backlog

Type: Bug Priority: Major
Reporter: Anthony Ve Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: 1221
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

The following class returns 500 Internal Server Error when doing an OPTIONS request on ".../users" because it doesn't have a "direct" resource method (or in other words, it has nothing but sub-resource methods). I don't know what the correct response should be here, but a status code of 500 seems wrong & e.g. the NetBeans "Test RESTful Web Services" functionality crashes on this.

@Stateless
@Path("/users")
public class UserService {

@Path("/current")
@GET
@Produces(TEXT_PLAIN)
public String getCurrentUser()

{ return "current user"; }

}

The body of the 500 response contains:

javax.ws.rs.NotFoundException: HTTP 404 Not Found
at org.glassfish.jersey.server.ServerRuntime$1.run(ServerRuntime.java:266)
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:297)
at org.glassfish.jersey.server.ServerRuntime.process(ServerRuntime.java:252)
at org.glassfish.jersey.server.ApplicationHandler.handle(ApplicationHandler.java:1025)
at org.glassfish.jersey.servlet.WebComponent.service(WebComponent.java:372)
at org.glassfish.jersey.servlet.ServletContainer.service(ServletContainer.java:382)
at org.glassfish.jersey.servlet.ServletContainer.service(ServletContainer.java:345)
at org.glassfish.jersey.servlet.ServletContainer.service(ServletContainer.java:220)
at org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1682)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:318)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:160)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:734)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:673)
at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:99)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:174)
at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:415)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:282)
at com.sun.enterprise.v3.services.impl.ContainerMapper$HttpHandlerCallable.call(ContainerMapper.java:459)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:167)
at org.glassfish.grizzly.http.server.HttpHandler.runService(HttpHandler.java:201)
at org.glassfish.grizzly.http.server.HttpHandler.doHandle(HttpHandler.java:175)
at org.glassfish.grizzly.http.server.HttpServerFilter.handleRead(HttpServerFilter.java:235)
at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:284)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:201)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:133)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:112)
at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77)
at org.glassfish.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(TCPNIOTransport.java:561)
at org.glassfish.grizzly.strategies.AbstractIOStrategy.fireIOEvent(AbstractIOStrategy.java:112)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.run0(WorkerThreadIOStrategy.java:117)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.access$100(WorkerThreadIOStrategy.java:56)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy$WorkerThreadRunnable.run(WorkerThreadIOStrategy.java:137)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:565)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:545)
at java.lang.Thread.run(Thread.java:744)



 Comments   
Comment by Miroslav Fuksa [ 12/Jun/14 ]

Hi,

thanks for finding a bug. I am moving the issue to the backlog.

the problem is that we currently support OPTIONS methods only for URIs where any resource method is available. In your case there is no resource method for "/users" and therefore we do not provide the OPTIONS method. This is probably incorrect, we should provide OPTIONS method for the resource too. JAXRS spec 3.3.5 says:

On receipt of an OPTIONS request an implementation MUST either:
1. Call a method annotated with a request method designator for OPTIONS or, if none present,
2. Generate an automatic response using the metadata provided by the JAX-RS annotations on the matching
class and its methods.

In this point the class is matched, so we should also provide OPTIONS method.

Anyway, returning 500 instead of 404 is a bug.

thanks
Mira





[JERSEY-2746] RuntimeExceptions thrown by request filters do not propagate when using submit() with Futures. Created: 02/Jan/15  Updated: 13/Apr/15

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

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


 Description   

The run() method in ClientRuntime.submit(...) invokes Stages.process(...) with no catch block for runtime exceptions. As a result, when a runtime exception is thrown in a filter, the submitted runnable dies. This throwable is never passed back to the response callback. This can leave to orphaned async processes, and wreaks havoc when attempting to troubleshoot bugs as the exceptions are swallowed.

Per 6.7.2 / 4.5.2 of the JAX-RS spec, the exception should be re-wrapped in a ProcessingException, and set as the failure in the corresponding response callback, which in turn will be re-wrapped in an ExecutionException per Invocation.submit()'s javadoc.






[JERSEY-2779] ServerSent Events not working when LoggingFilter is enabled with printEntity Created: 09/Feb/15  Updated: 13/Apr/15

Status: Open
Project: jersey
Component/s: core, media
Affects Version/s: 2.15
Fix Version/s: backlog

Type: Bug Priority: Major
Reporter: quixote_arg Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: 1221, sse
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

tomcat 7.0.53



 Description   

Some time ago I added a LoggingFilter to my application, like this on the "extends ResourceConfig" class:

register(new LoggingFilter(Logger.getLogger(LoggingFilter.class.getName()), true));

After some time I noticed that the server sent events stopped working.

I reproduced it with the sample from https://jersey.java.net/documentation/latest/sse.html (adding Thread.sleep(1000) to make it more asynchronous); when the LoggingFilter was enabled (with printEntity set to true) then it will wait the whole 30 seconds and output the entire response at once (instead of one per second, 30 times)

If I comment out the LoggingFilter registration or change it to:

register(LoggingFilter.class);

then the chunks arrive once per second, as expected.

Another side effect of the this bug is that when I close the client connection, no exception is thrown on the server, hence the server keeps sending events to the client, even if the connection was closed a long time ago.



 Comments   
Comment by quixote_arg [ 09/Feb/15 ]

I think that the problem is on LoggingFilter.filter(ContainerRequestContext requestContext, ContainerResponseContext responseContext) which tries to log the entire entity which the server responded, which in the case of SSE may never finish

LoggingFilter.java
        if (printEntity && responseContext.hasEntity()) {
            OutputStream stream = new LoggingStream(b, responseContext.getEntityStream());
            responseContext.setEntityStream(stream);
            requestContext.setProperty(ENTITY_LOGGER_PROPERTY, stream);
            // not calling log(b) here - it will be called by the interceptor
        } else {
            log(b);
        }




[JERSEY-1998] Refactor Jersey 2.x performance test-cases Created: 02/Aug/13  Updated: 13/Apr/15  Resolved: 13/Apr/15

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

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


 Description   

Performance test-case still use 2.0-SNAPSHOT version of Jersey (+ old version of moxy, guava, ...).



 Comments   
Comment by Jakub Podlesak [ 22/Aug/13 ]

No going to re-factor at the moment, just updated the moxy/guava version manually.

The original intention was (and it still needs to be done) to have the performance test cases use a common parent module that would include common settings/code.

Comment by Michal Gajdos [ 13/Apr/15 ]

Performance test-cases are now part of the build.





[JERSEY-2140] Update MOXy to 2.5.2 Created: 11/Oct/13  Updated: 13/Apr/15  Resolved: 13/Apr/15

Status: Resolved
Project: jersey
Component/s: media
Affects Version/s: 2.3.1
Fix Version/s: 2.18

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


 Description   

Update MOXy (2.5.0 -> 2.5.1) and un-ignore entity-filtering test-cases.



 Comments   
Comment by Michal Gajdos [ 16/Oct/13 ]

This issue depends on:

https://bugs.eclipse.org/bugs/show_bug.cgi?id=419352
https://bugs.eclipse.org/bugs/show_bug.cgi?id=419072

Comment by Michal Gajdos [ 13/Apr/15 ]

Updated to 2.6.0.





Generated at Sun Apr 19 00:20:39 UTC 2015 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.