[OPENPTK-330] Limit use of WebApplicationException Created: 14/Mar/12  Updated: 08/May/12  Resolved: 24/Mar/12

Status: Closed
Project: openptk
Component/s: Server
Affects Version/s: 2.0, 2.1
Fix Version/s: 2.1

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

Tags: jax-rs, jersey, server

 Description   

Enhance the Resource code to handle exceptions with appropriate HTTP 400/500 Response instead of throwing WebApplicationException, where possible.



 Comments   
Comment by Scott Fehrman [ 24/Mar/12 ]

Implemented solution. The use of WebApplicationException is limited to the constructor method for Resource.java. All other "run time" exceptions (EngineException) are caught and an Internal Server Error (500) is sent back to the client.

Comment by Terry Sigle [ 08/May/12 ]

Confirmed with a code review of the org.openptk.jaxrs.Resource.java and child classes to confirm that the WebApplicationException is being thrown properly and/or an INTERNAL_SERVER_ERROR is being used properly.





[MAVEN2_REPOSITORY-106] Jersey 2.x - create new staging profile org.glassfish.jersey for user jerseyrobot Created: 14/Feb/12  Updated: 15/Feb/12  Resolved: 15/Feb/12

Status: Resolved
Project: maven2-repository
Component/s: migration-cleanup
Affects Version/s: None
Fix Version/s: None

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

Tags: jersey, maven

 Description   

Please add a new staging profile for java.net user jerseyrobot to allow deployment of maven artefacts in org.glassfish.jersey group and sub-groups.

Project URL: http://jersey.java.net/
Group Id: org.glassfish.jersey
SCM URL:
git://java.net/jersey~code (read-only)
ssh://<user>@git.java.net/jersey~code



 Comments   
Comment by juven [ 15/Feb/12 ]

there is a already a staging profile com.sun.jersey mapped to project jersey, so I extended it by adding pattern org.glassfish.jersey, now all jersey dev/admin should be able to deploy.

thanks,
Juven





[JERSEY-2776] Regression -Multipart/form-data POST having a quoted boundary parameter in the Content-Type header fails. Created: 07/Feb/15  Updated: 24/Feb/15  Resolved: 24/Feb/15

Status: Resolved
Project: jersey
Component/s: media
Affects Version/s: 2.15
Fix Version/s: 2.17

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

Attachments: HTML File does_not_work_but_is_valid    
Issue Links:
Cloners
clones JERSEY-1420 CLONE -Multipart/form-data POST havin... Resolved
Tags: boundary, jersey, multipart, pull-request, 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 jontejj [ 07/Feb/15 ]

This affects version 2.15 (I don't have rights to edit fields).
My suggested fix is to:

mediaType = unquoteMediaTypeParameters(mediaType, "boundary");

protected static MediaType unquoteMediaTypeParameters(final MediaType mediaType, final String... parameters) {
if (parameters == null || parameters.length == 0)

{ return mediaType; }

final HashMap<String, String> unquotedParams = new HashMap<String, String>(mediaType.getParameters());

for (final String parameterName : parameters) {
String parameterValue = mediaType.getParameters().get(parameterName);

if (parameterValue.startsWith("\""))

{ parameterValue = parameterValue.substring(1, parameterValue.length() - 1); unquotedParams.put(parameterName, parameterValue); }

}

return new MediaType(mediaType.getType(), mediaType.getSubtype(), unquotedParams);
}

Like MultiPartReaderClientSide looks like in com.sun.jersey.contribs/jersey-multipart/1.15. I'll send a PR to github.

Comment by jontejj [ 09/Feb/15 ]

Pull request: https://github.com/jersey/jersey/pull/143





[JERSEY-2629] CLONE - Glassfish / Jersey throws NPE on startup Created: 25/Aug/14  Updated: 27/Aug/14  Resolved: 27/Aug/14

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

Type: Bug Priority: Critical
Reporter: lprimak Assignee: Unassigned
Resolution: Duplicate Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: 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
clones JERSEY-2626 Glassfish / Jersey throws NPE on star... 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 Miroslav Fuksa [ 27/Aug/14 ]

duplicates JERSEY-2626





[JERSEY-2626] Glassfish / Jersey throws NPE on startup of versioned app Created: 24/Aug/14  Updated: 24/Mar/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 used 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





[JERSEY-2618] Declarative linking for JSON produces incorrect result while working fine for XML. Created: 18/Aug/14  Updated: 15/Dec/14

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

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

Tomcat 7.52, Java 1.7


Tags: JSON,, jersey, moxy

 Description   

I was trying to follow the declarative linking example: http://search.maven.org/#search%7Cga%7C1%7Ca%3A%22declarative-linking%22

Here is my code:

@InjectLink(   
        resource = FolderResource.class,  
        method = "query",   
        style = Style.ABSOLUTE,   
        bindings = {@Binding(name = "requestCount", value="99")   
        },   
        rel = "${rel}"  
)   
@XmlJavaTypeAdapter(Link.JaxbAdapter.class)
@XmlAttribute 
private Link href;

When I run it, i am getting this:

.....
       "href": "javax.ws.rs.core.Link$JaxbLink@41a741a7",
.....

instead of the actual link.

If I use a String type instead of Link and don't use @XmlJavaTypeAdapter(Link.JaxbAdapter.class), I am getting a correct link but without query parameters.






[JERSEY-2553] Jersey 2 does not accept java.util.Date as query param Created: 18/Jun/14  Updated: 19/Dec/14  Resolved: 16/Jul/14

Status: Resolved
Project: jersey
Component/s: core
Affects Version/s: 2.10
Fix Version/s: 2.11

Type: Bug Priority: Major
Reporter: guyr Assignee: Michal Gajdos
Resolution: Works as designed Votes: 0
Labels: unplanned
Remaining Estimate: 1 day
Time Spent: Not Specified
Original Estimate: 1 day
Environment:

Tested with Windows 7 64-bit, Java 1.7.0_51


Tags: 2, date, jersey, parameter, query

 Description   

We have a webservice implemented with Jersey 1. Some of our resource methods take query params of type java.util.Date. Everything works fine.

We are now moving our webservices to Jersey 2. We find that any of the methods that take query params of type java.util.Date are reported to the client as 404 Not Found if the param value is non-null. If we invoke that same methods with null as the date value, then the resource method is properly executed.

I reported this issue on the Jersey Users mailing list; see thread "Proxy client Date query param works in Jersey 1, not Jersey 2" dated 6/10/2014. Since we use the proxy client for all our web services, I originally thought this was an issue with the proxy client. However, as you'll see in the attached test code, the same problem occurs without the proxy.

I have comparable samples written with both Jersey 1 and Jersey 2. I started with the helloworld-webapp sample, and added a method taking java.util.Date as a query param. See HelloWorldResource.echoDate(). To observe the failure, execute test HelloWorldTest.testGetDate(). As written, the test will fail with 404. Replace currentDate with null in the request invocation, and the call will be successfully processed by the server.



 Comments   
Comment by guyr [ 18/Jun/14 ]

I can't find anywhere to attach files, so I put the two samples on my Google Drive. Here are the links:

Jersey 1 sample:

https://drive.google.com/file/d/0B0hdB1olxgPjOURBc2R6SDNCbWM/edit?usp=sharing

Jersey 2 sample:

https://drive.google.com/file/d/0B0hdB1olxgPjX1lZQUJTRUpjQ3M/edit?usp=sharing

Comment by Marek Potociar [ 20/Jun/14 ]

Setting priority to MAJOR as requested by the filer.

Comment by guyr [ 14/Jul/14 ]

Is this being worked on for the next release? This bug is preventing us from moving from Jersey 1 to Jersey 2. Thanks.

Comment by Michal Gajdos [ 15/Jul/14 ]

The reason this works in Jersey 1 is because new Date(value) is being used to convert the query param to Date. This constructor is deprecated and we decided not to use it in this case in Jersey 2.
You should be able to achieve your goal with registering a custom ParamConverter:

public static class DateParamProvider implements ParamConverterProvider {

    @Override
    public <T> ParamConverter<T> getConverter(final Class<T> rawType, final Type genericType,
                                              final Annotation[] annotations) {
        if (rawType != Date.class) {
            return null;
        }

        final DateFormat format = new SimpleDateFormat("MM/dd/yyyy mm:ss");

        //noinspection unchecked
        return (ParamConverter<T>) new ParamConverter<Date>() {
            @Override
            public Date fromString(final String value) {
                try {
                    return format.parse(value);
                } catch (final ParseException e) {
                    throw new IllegalArgumentException(e);
                }
            }

            @Override
            public String toString(final Date value) {
                return format.format(value);
            }
        };
    }
}

If this is not sufficient for you we can introduce a custom property by which you can provide a date format to be used to convert the value. But I think that use of ParamConverter is better in this case.

Comment by guyr [ 16/Jul/14 ]

Michal, thank you for the DateParamProvider. This solution will be adequate for us. However, I am having trouble getting this provider to work on the client side. Here is what I've attempted:

   Date currentDate = dateFormat.parse("07/04/2014 03:04");
   Date returnedDate = target().register(DateParamProvider.class).path("/helloworld/echoDate").queryParam("inDate", currentDate)
          .request().get(DateWrapper.class).getMyDate();

I put System.out.println's in the provider class for both fromString() and toString(). I'm not seeing toString() getting invoked on the client side. If I change the above to the following:

   Date currentDate = dateFormat.parse("07/04/2014 03:04");
   Date returnedDate = target().register(DateParamProvider.class).path("/helloworld/echoDate")
          .queryParam("inDate", dateFormat.format(currentDate))
          .request().get(DateWrapper.class).getMyDate();

then the call to the server completes successfully. I see the fromString method being executed by the server, the server method then gets invoked, and finally I get the appropriate response back on the client side.

What more do I need to do on the client side so that the provider is properly invoked to translate Date to String?

Thank you.

Comment by Michal Gajdos [ 16/Jul/14 ]

Thanks for confirmation. Date.toString() method is invoked directly on the value in queryParam method. We'll talk about it to see what we can do here.

Comment by Michal Gajdos [ 16/Jul/14 ]

Hi, after a discussion we decided not to change behavior of queryParam method. The best solution would be to pass date as string in format you expect on the server.
Marking as resolved since we have a solution for the server-side. Feel free to comment.

Comment by guyr [ 16/Jul/14 ]

Michal, I don't understand how this can be working as designed. The ParamConverterProvider provides an explicit method ( toString() ) for serializing a class of interest:. The current implementation completely ignores this, and instead applies the toString() method of the value in QueryParam. How can that be considered to be working properly? If this is working properly, then what's the point of having a toString() method in ParamConverterProvider?

We are using the Jersey proxy client. So passing Date as a string is not an option.

Thanks.

Comment by minfrin [ 25/Aug/14 ]

This just bit me badly.

If jersey has decided to arbitrarily stop accepting java.util.Date() as a parameter, then return a 400 Bad Request with a clear and unambiguous error message telling the end user exactly what just happened, and that you've decided to ignore the jaxrs spec and break everyone's code. At least this way we won't spend hours trying to track down inexplicable 404 responses that make no sense.

Comment by shane907 [ 19/Dec/14 ]

I can appreciate the reasoning behind avoiding the Date(string) constructor in Jersey 2 (I do see that in 2.14 HttpDateFormat.readDate(value) is used in ParamConverters$DateProvider), and ParamConverter does provide an unambiguous way to parse any format. I have to agree with minfrin, though, that the current behavior is mysterious and not at all obvious. I just spent a long while trying to figure out why a method call was resulting in a 404, checking paths, moving sub-resources to root resources, etc, before finally finding this ticket and an unparsable param->404 mention in the manual.

It looks like the exception chain with a meaningful parsing error message ends at ParameterValueHelper.getParameterValues, where a WebApplicationException is thrown. After that, AbstractJavaResourceMethodDispatcher.dispatch seems to discard the exception. If there is a way to communicate what went wrong to the user/developer, it would be very helpful (even if this is just logging at the ERROR or WARN level).

It looks like this is a pretty common point of confusion with JAXRS implementations:
https://issues.apache.org/jira/browse/CXF-4976





[JERSEY-2503] Unable to register custom JacksonJsonProvider - default one always gets registered Created: 03/May/14  Updated: 05/May/14  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





[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
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Glassfish 4


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

 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 ]

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 ]

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 ]

updated test case





[JERSEY-2393] GLassfish failed to inject CDI managed beans in an ExceptionMapper Created: 10/Feb/14  Updated: 23/Apr/14

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

Type: Bug Priority: Major
Reporter: hazem Assignee: Jakub Podlesak
Resolution: Unresolved Votes: 2
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Glassfish 4


Issue Links:
Duplicate
is duplicated by JERSEY-2491 REOPEN -GLassfish failed to inject CD... Resolved
Tags: cdi, glassfish4, hk2, incomplete, jersey

 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 jwells [ 11/Feb/14 ]

I tend to think this is a Jersey issue rather than an hk2 issue, since the ServiceLocator here is Jersey's

Comment by Jakub Podlesak [ 12/Feb/14 ]

What if you make the exception mapper a CDI bean? E.g. if you go with:

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

Then your Manager instance should get injected all right.

Comment by Jakub Podlesak [ 12/Feb/14 ]

Please let me know how the above suggestion works for you.

Comment by hazem [ 12/Feb/14 ]

I tried the suggestion above and it did not help, I still get the same issue

Comment by adriaaaaan [ 12/Mar/14 ]

Are you sure? It works for me.

@Provider
@RequestScoped
public class SecurityExceptionMapper implements ExceptionMapper<AccessLocalException> {

@Inject @CurrentUser UserLogin currentUser;

@Override
public Response toResponse(AccessLocalException ex) {
if(currentUser!=null && !currentUser.getUserName().equals("ANONYMOUS"))

{ return Response.status(Response.Status.FORBIDDEN).entity(ex.getMessage()).build(); }

return Response.status(Response.Status.UNAUTHORIZED).entity(ex.getMessage()).build();
}
}

In this instance, adding requestscoped has injected the current user allowing this mapper to return forbidden.

Comment by hazem [ 12/Mar/14 ]

Is UserLogin your own class or is it part of JavaEE. If it is yours can you please elaborate on what kind of bean is it

Comment by Marek Potociar [ 26/Mar/14 ]

Please attach a simple web application that reproduces the problem on GF 4.x. (You can e.g. create a small project on github and then paste a link to the project here.)

Comment by Marek Potociar [ 26/Mar/14 ]

Marking as incomplete - waiting for a reproducer webapp to be provided by the issue filer.

Comment by hazem [ 26/Mar/14 ]

I created a sample project to reproduce this bug

https://github.com/hmashlah/glassfish4-test

Comment by Jakub Podlesak [ 22/Apr/14 ]

Just tried to update the exception mapper as suggested above:

...
/**
 * Created by mashlah on 26.03.14.
 */
@Provider
@javax.enterprise.context.ApplicationScoped
public class TestExceptionMapper implements ExceptionMapper<TestException> {


    // Using @Context does not help
    @Inject
    private TestService testService;
...

and the thing works for me just fine:

curl -i http://localhost:8080/glassfish4-test-master/sample/test/getEmpty
HTTP/1.1 200 OK
Server: GlassFish Server Open Source Edition  4.0.1
X-Powered-By: Servlet/3.1 JSP/2.3 (GlassFish Server Open Source Edition  4.0.1  Java/Oracle Corporation/1.7)
Date: Tue, 22 Apr 2014 14:07:06 GMT
Content-Length: 0

curl -i http://localhost:8080/glassfish4-test-master/sample/test/getException
HTTP/1.1 400 Bad Request
Server: GlassFish Server Open Source Edition  4.0.1
X-Powered-By: Servlet/3.1 JSP/2.3 (GlassFish Server Open Source Edition  4.0.1  Java/Oracle Corporation/1.7)
Content-Type: text/plain
Date: Tue, 22 Apr 2014 14:07:21 GMT
Connection: close
Content-Length: 16

Exception thrown
Comment by Jakub Podlesak [ 22/Apr/14 ]

Please feel free to re-open after updating the test case.

Comment by hazem [ 22/Apr/14 ]

The test case is updated

Comment by hazem [ 22/Apr/14 ]

I do not have permission to re-open this bug

Comment by Jakub Podlesak [ 23/Apr/14 ]

Re-opening so that the reporter has a chance to either: confirm the updated test case works for him or to clarify, why the update does not work for him.
Going to close this one as invalid if i do not hear any news as myself and one other user confirmed suggested test case update works just fine.

Comment by hazem [ 23/Apr/14 ]

The suggested solution works on glassfish 4.0.1 but does not work on glassfish 4.0





[JERSEY-2366] jersey-spring3 register SSeFeature Created: 28/Jan/14  Updated: 29/Jan/14  Resolved: 29/Jan/14

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

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

jetty 9.1 windows7 JDK6


Tags: jersey, spring, sse

 Description   

I'm trying to extend the spring example here:
https://github.com/jersey/jersey/tree/master/examples/helloworld-spring-webapp

with the SSEFeature

MyApplication file is :

MyApplication.java
public MyApplication() {
        register(RequestContextFilter.class, SseFeature.class);
        packages("com.example");
...

and my resource:

MyBroadcasterSSE.java
@Component
@Path("broadcast")
public class MyBroadcasterSSE {

    @Autowired
    SerialTest serialTest;

    @GET
    @Produces(SseFeature.SERVER_SENT_EVENTS)
    public EventOutput listenToBroadcast() {
        final EventOutput eventOutput = new EventOutput();
        serialTest.broadcaster.add(eventOutput);
        return eventOutput;
    }
}

I have the following error at startup:

WARNING: Contract class org.glassfish.jersey.media.sse.SseFeature can not be registered for component class org.glassfish.jersey.server.spring.scope.RequestContextFilter: Contract not assignable to component.


 Comments   
Comment by Michal Gajdos [ 29/Jan/14 ]

By line

register(RequestContextFilter.class, SseFeature.class);

See javadoc of #register method:

  /**
     * Register a class of a custom JAX-RS component (such as an extension provider or
     * a {@link javax.ws.rs.core.Feature feature} meta-provider) to be instantiated
     * and used in the scope of this configurable context.
     * <p>
     * This registration method provides the same functionality as {@link #register(Class)}
     * except the JAX-RS component class is only registered as a provider of the listed
     * extension provider or meta-provider {@code contracts}.
     * All explicitly enumerated contract types must represent a class or an interface
     * implemented or extended by the registered component. Contracts that are not
     * {@link Class#isAssignableFrom(Class) assignable from} the registered component class
     * MUST be ignored and implementations SHOULD raise a warning to inform users about the
     * ignored contract(s).
     * </p>
     *
     * @param componentClass JAX-RS component class to be configured in the scope of this
     *                       configurable context.
     * @param contracts      the specific extension provider or meta-provider contracts
     *                       implemented by the component for which the component should
     *                       be registered.
     *                       Implementations MUST ignore attempts to register a component
     *                       class for an empty or {@code null} collection of contracts via
     *                       this method and SHOULD raise a warning about such event.
     * @return the updated configurable context.
     */
    public C register(Class<?> componentClass, Class<?>... contracts);

In order to register both RequestContextFilter and SseFeature use:

register(RequestContextFilter.class);
register(SseFeature.class);




[JERSEY-2353] jersey cannot work with java8 lambda code Created: 21/Jan/14  Updated: 11/Feb/14  Resolved: 21/Jan/14

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

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

java8


Issue Links:
Duplicate
duplicates JERSEY-2274 Shadow ASM classes with jersey specif... Resolved
Tags: asm, hk2, java8, jersey, lambda

 Description   

I dont know where exactly this issue belongs, but I know the problem is in asm-all not supporting java8. I have opened an issue for hk2 which uses ASM and is in turn used by Jersey. I am hoping that this be addressed in Jersey via a new release or I am hoping to find a solid working work around for this.

Here is the hk2 issue I opened:
https://java.net/jira/browse/HK2-181

Thanks



 Comments   
Comment by Marek Potociar [ 21/Jan/14 ]

Closing as duplicate





[JERSEY-2338] org.glassfish.jersey.client.oauth1.OAuth1ClientFeature echoes out configuration using System.out.println() Created: 15/Jan/14  Updated: 11/Feb/14  Resolved: 20/Jan/14

Status: Resolved
Project: jersey
Component/s: security
Affects Version/s: 2.5.1
Fix Version/s: 2.6

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

Tags: jersey, oauth1

 Description   

The configure method for the OAuth1ClientFeature class contains a call to System.out.println:

    @Override
    public boolean configure(FeatureContext context) {
        System.out.println(config);

        context.register(OAuth1SignatureFeature.class);
        context.register(OAuth1ClientFilter.class);

        context.property(OAuth1ClientSupport.OAUTH_PROPERTY_OAUTH_PARAMETERS, parameters);
        context.property(OAuth1ClientSupport.OAUTH_PROPERTY_OAUTH_SECRETS, secrets);

        return true;
    }

These statements should, at the least, be delegated to a logger implementation so that consumers can remove them from their logs. I'd go so far as to say, though, in this case, that the statement should be removed (its value seems questionable).






[JERSEY-2327] NonceManager causes permanent memory leak if clients sends milliseconds for oauth_timestamp Created: 13/Jan/14  Updated: 11/Feb/14  Resolved: 05/Feb/14

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

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

Issue Links:
Related
is related to JERSEY-2398 Fix Nonce Manager for Jersey 1.x Open
Tags: jersey, memory-leak, nonce, noncemanager, oauth-server

 Description   

The NonceManager.verify() method implicitly assumes the oauth_timestamp is in seconds as it multiples the inputted value by 1,000 as soon as it comes in, but the JavaDoc does not reflect this. We discovered that if the client sends oauth_timestamps in milliseconds, the underlying SortedMap tsToKeyNoncePairs will grow without bound (for 44,000 years), with the gc() never finding any elements to evict because all values are in the future. This eventually leads to OutOfMemory heap error, causing our server to crash.

From Section 8 of the OAuth 1.0 specification: "Unless otherwise specified by the Service Provider, the timestamp is expressed in the number of seconds since January 1, 1970 00:00:00 GMT. The timestamp value MUST be a positive integer and MUST be equal or greater than the timestamp used in previous requests."

The specification suggests that, although oauth_timestamp is commonly expected to be in seconds, the Service Provider may choose a different time unit, such as milliseconds. There's no clear indication in the Jersey library, though, that using milliseconds will have a disastrous effect. At the very least, the documentation for Jersey should be updated to explicitly state that the timestamp must be in seconds.

Regardless of whether Jersey should support seconds or milliseconds for oauth_timestamp values, Jersey should be patched to prevent an incorrect or malicious client from causing the server to run out of memory. There should be a map based on System.currentTimeMillis(), rather than oauth_timestamp, that the gc() should use to evict elements from the tsToKeyNoncePairs map, so that it cannot trigger a memory leak, regardless of which clients connect to it.



 Comments   
Comment by Marek Potociar [ 15/Jan/14 ]

We need to evaluate the issue and check if the problem is only related to Jersey 1.x code or if it also applies to Jersey 2.x impl. If the problem is only in Jersey 1.x, then target for Jersey 1.19. If also in Jersey 2.x code, we should try to address the issue ASAP.

Comment by selikoff [ 15/Jan/14 ]

I reviewed the source code for 1.18 and 2.5.1 and the NonceManager is unchanged between the two, save a few JavaDoc notations:

https://jersey.java.net/project-info/2.5.1/jersey/project/oauth1-server/xref/org/glassfish/jersey/server/oauth1/NonceManager.html

Comment by selikoff [ 15/Jan/14 ]

Note that the issue is not limited to using milliseconds for oauth_timestamp only. If a client sends a series of requests with oauth_timestamps all in the future, the server will eventually run out of memory. For example, in our environment, having the timestamps one week in the future would have been enough to produce this issue, as the traffic was high enough that the server would crash after 5 days.

Comment by selikoff [ 11/Feb/14 ]

Will this be fixed in the upcoming 1.0 Jersey release, such as 1.19 or 1.20?

Comment by Miroslav Fuksa [ 11/Feb/14 ]

The issue was fixed for Jersey 2.6. The fix for Jersey 1.19 is planned in the issue JERSEY-2398.





[JERSEY-2243] Using Sse with Jersey in OSGi Created: 22/Nov/13  Updated: 25/Nov/13  Resolved: 25/Nov/13

Status: Resolved
Project: jersey
Component/s: media, osgi
Affects Version/s: 2.0
Fix Version/s: None

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

Windows 7, Eclipse Kepler


Tags: JAX-RS, Jersey, OSGi, SSe

 Description   

I'm trying to implement a simple Java Sse server using Jersey on OSGi.
I've followed the example described in the Jersey official guide:

https://jersey.java.net/documentation/latest/sse.html#d0e8183

but when I try to call the server, it says: "MessageBodyWriter not found for media type=text/event-stream, type=class org.glassfish.jersey.media.sse.OutboundEvent, genericType=class org.glassfish.jersey.media.sse.OutboundEvent."

I've found some other similar issues in which all say to register SSE feature, but in OSGi there is not a main in which I can register it, and, moreover, the SseFeature doesn't provide any service!
How can i register the sse feature? Or: what can I do to fix the problem?

PS. To work in OSGi, Jersey need the connector:
https://github.com/hstaudacher/osgi-jax-rs-connector

Here I will paste the code you should need to help me!

MANIFEST.MF

Manifest-Version: 1.0
Bundle-ManifestVersion: 2
Bundle-Name: RestServerSSE
Bundle-SymbolicName: it.prova.sse
Bundle-Version: 1.0.0.qualifier
Bundle-RequiredExecutionEnvironment: JavaSE-1.7
Import-Package: javax.ws.rs;version="2.0.0",
 javax.ws.rs.core;version="2.0.0",
 javax.ws.rs.ext;version="2.0.0",
 org.glassfish.jersey.media.sse;version="2.0.0",
 org.glassfish.jersey.message;version="2.0.0",
 org.glassfish.jersey.server;version="2.0.0",
 org.osgi.framework;version="1.7.0"
Service-Component: OSGI-INF/component.xml

component.xml

<?xml version="1.0" encoding="UTF-8"?>
<scr:component xmlns:scr="http://www.osgi.org/xmlns/scr/v1.1.0" name="it.prova.sse">
   <implementation class="it.prova.sse.Server"/>
   <service>
      <provide interface="it.prova.sse.Server"/>
   </service>
</scr:component>

Server.java

package it.polito.server.rest.sse;
import java.io.IOException;
import javax.ws.rs.GET;
import javax.ws.rs.Path;
import javax.ws.rs.Produces;
import org.glassfish.jersey.media.sse.EventOutput;
import org.glassfish.jersey.media.sse.OutboundEvent;
import org.glassfish.jersey.media.sse.SseFeature;
import org.glassfish.jersey.server.ResourceConfig;

@Path("/sse")
public class Server
{
public Server()
{
    final ResourceConfig resourceConfig = new ResourceConfig(Server.class,SseFeature.class);
}
	
  @GET
    @Produces(SseFeature.SERVER_SENT_EVENTS)
      public EventOutput getServerSentEvents() {
		
        final EventOutput eventOutput = new EventOutput();
        new Thread(new Runnable() {
          @Override
            public void run() {
               try {
               for (int i = 0; i < 10; i++) {
               // ... code that waits 1 second
               final OutboundEvent.Builder eventBuilder
               = new OutboundEvent.Builder();
               eventBuilder.name("message-to-client");
                  eventBuilder.data(String.class,
                      "Hello world " + i + "!");
                      final OutboundEvent event = eventBuilder.build();
                      eventOutput.write(event);
                  }
               } catch (IOException e) {
                  throw new RuntimeException(
                      "Error when writing the event.", e);
               } finally {
                  try {
                      eventOutput.close();
                  } catch (IOException ioClose) {
                      throw new RuntimeException(
                          "Error when closing the event output.", ioClose);
                  }
              }
           }
        }).start();
        return eventOutput;
    }
}


 Comments   
Comment by Michal Gajdos [ 25/Nov/13 ]

This is not a bug. You're configuring wrong ResourceConfig. You should configure the one that is used during deployment time and not the one that you create in a resource (please consult documentation to osgi connector how to do that).





[JERSEY-2075] Boundary never generated multipart/formdata Created: 02/Sep/13  Updated: 04/Dec/13  Resolved: 04/Dec/13

Status: Resolved
Project: jersey
Component/s: media
Affects Version/s: 2.2
Fix Version/s: 2.5

Type: Bug Priority: Major
Reporter: dynaheir Assignee: Michal Gajdos
Resolution: Cannot Reproduce Votes: 0
Labels: None
Remaining Estimate: 0 minutes
Time Spent: 1 minute
Original Estimate: 30 minutes

Tags: jersey, jersey-client, multipart/form-data

 Description   

FormDataMultiPart is never generating a boundary for me which is required for the below snippet form your user guide.

The below snippet from the user guide is incorrect and will not compile...
.bodyPart returns a MultiPart and would need to be cast back to a FormDataMultiPart

Jersey2.2
http://jersey.java.net/documentation/latest/user-guide.html

final FileDataBodyPart filePart = new FileDataBodyPart("my_pom", new File("pom.xml"));
final FormDataMultiPart multipart = new FormDataMultiPart()
.field("foo", "bar")
.bodyPart(filePart);

final WebTarget target = // Create WebTarget.
final Response response = target.request()
.post(Entity.entity(multipart, multipart.getMediaType()));

To work around this issue I had to take control of the media type
MultiPart form = new FormDataMultiPart()
.bodyPart(new FormDataBodyPart("asset", asset, MediaType.APPLICATION_XML_TYPE))
.bodyPart(new StreamDataBodyPart("file", fileStream))
.type(new MediaType("multipart", "form-data",
Collections.singletonMap(Boundary.BOUNDARY_PARAMETER, Boundary.createBoundary())));



 Comments   
Comment by Michal Gajdos [ 04/Dec/13 ]

Cannot reproduce with default client. If ApacheConnector is used then this issue should be solved with JERSEY-2123. If the issue persist feel free to reopen (please, provide stacktrace).

Comment by Michal Gajdos [ 04/Dec/13 ]

Closing as cannot reproduce. Test-case for the default client will be provided with a fix for JERSEY-2123.





[JERSEY-2002] Jersey 2.x has less than 10x performance compared to 1.7.1 Created: 06/Aug/13  Updated: 07/Jul/14  Resolved: 15/Oct/13

Status: Resolved
Project: jersey
Component/s: core
Affects Version/s: 2.1
Fix Version/s: 2.4

Type: Bug Priority: Critical
Reporter: kul Assignee: Jakub Podlesak
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: 0 minutes
Time Spent: 3 days, 22 hours
Original Estimate: Not Specified
Environment:

Ubuntu 12.04 java 1.70_25


Issue Links:
Related
is related to JERSEY-1991 Processing of most container requests... Resolved
is related to JERSEY-2578 Jersey2 spring integration is very slow Open
is related to JERSEY-2099 Upgrade HK2 dependency to the version... Resolved
Tags: benchmark, jersey, jersey-grizzly2

 Description   

Old configuration:
"com.sun.jersey" % "jersey-core" % "1.17.1",
"com.sun.jersey" % "jersey-server" % "1.17.1",
"com.sun.jersey" % "jersey-grizzly2" % "1.17.1"

New configuration:
"org.glassfish.jersey.containers" % "jersey-container-grizzly2-http" % "2.0",
"org.glassfish.jersey.media" % "jersey-media-multipart" % "2.0"

For following rest resource

package org.bench.rest                                                                                                                 
                                                                                                                                                
import javax.ws.rs.GET                                                                                                                          
import javax.ws.rs.Path                                                                                                                         
                                                                                                                                                
@Path("/ping")                                                                                                                                  
class PingPong {                                                                                                                                
                                                                                                                                                
  @GET                                                                                                                                          
  def pong = "pong"                                                                                                                             
                                                                                                                                                
}

Server is created using the usual ServerFactory method and benchmarked using wrk.
Benchmarked using two machines one serving resources other running wrk.
Processor i3, memory 4g

1.7.1 performance:

% ./wrk -t12 -c256 -d30s http://169.254.10.190:9999/ping
Running 30s test @ http://169.254.10.190:9999/ping
  12 threads and 256 connections
  Thread Stats   Avg      Stdev     Max   ± Stdev
    Latency     3.44ms    6.64ms 283.34ms   95.08%
    Req/Sec     6.62k     1.22k   15.00k    74.44%
  2253249 requests in 30.00s, 266.62MB read
Requests/sec:  75114.77
Transfer/sec:      8.89MB 

2.x performance:

% ./wrk -t12 -c256 -d30s http://169.254.10.190:9999/ping
Running 30s test @ http://169.254.10.190:9999/ping
  12 threads and 256 connections
  Thread Stats   Avg      Stdev     Max   ± Stdev
    Latency    45.09ms   14.37ms 153.63ms   78.27%
    Req/Sec   490.59     96.81   735.00     76.91%
  172721 requests in 30.00s, 17.30MB read
Requests/sec:   5757.37
Transfer/sec:    590.67KB 


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

We do continuous performance testing for Jersey 2 to make sure we do not introduce serious regressions in performance.
Last year we did compare Jersey 1 and Jersey 2 and the results were not that bad (about 30 % drop).
So i am surprised to see this. Anyway, I am going to re-run Jersey 1/Jersey 2 performance comparison tests of my own
and will get back.

Comment by Jakub Podlesak [ 06/Aug/13 ]

These might be related.

Comment by Jakub Podlesak [ 03/Sep/13 ]

Above results seem scary, however, the above numbers are IMHO impacted by insufficient warm-up time period.
The following is results from my measurement:

Jersey 2.3-SNAPSHOT:

jerseyrobot@japod-dell:~$ ./wrk -t16 -c256 -d180s http://10.163.76.25:8080/text
Running 3m test @ http://10.163.76.25:8080/text
  16 threads and 256 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency    27.06ms   13.85ms 228.29ms   93.72%
    Req/Sec   639.75    113.57   700.00     92.85%
  1837643 requests in 3.00m, 184.14MB read
  Socket errors: connect 0, read 0, write 0, timeout 106
Requests/sec:  10209.26
Transfer/sec:      1.02MB

Jersey 1.17.1:

jerseyrobot@japod-dell:~$ ./wrk -t16 -c256 -d180s http://10.163.76.25:8080/text
Running 3m test @ http://10.163.76.25:8080/text
  16 threads and 256 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency    10.82ms    9.06ms  83.61ms   90.01%
    Req/Sec     1.80k   434.70     2.16k    89.93%
  5157696 requests in 3.00m, 610.29MB read
  Socket errors: connect 0, read 0, write 0, timeout 91
Requests/sec:  28654.57
Transfer/sec:      3.39MB

After some hacking (improvements in HK2), i got (still Jersey 2.3-SNAPSHOT version, but updated HK2):

jerseyrobot@japod-dell:~$ ./wrk -t16 -c256 -d180s http://10.163.76.25:8080/text
Running 3m test @ http://10.163.76.25:8080/text
  16 threads and 256 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency    18.61ms    3.88ms  80.29ms   82.74%
    Req/Sec     0.88k   112.96     1.62k    79.39%
  2483412 requests in 3.00m, 248.85MB read
  Socket errors: connect 0, read 0, write 0, timeout 86
Requests/sec:  13796.77
Transfer/sec:      1.38MB

Which is still about 60 % drop, but not 10 times worse.

So far, we did testing internally with the Apache Benchmark tool, which now seem not to be generating enough load
in our test scenario. I am getting much higher numbers with the Google wrk tool.
Overall, the test setup was giving twisted results so far.
I need to re-work the tests to get more precise results and then focus on improving the numbers.

Comment by Jakub Podlesak [ 15/Oct/13 ]

Jersey versions from 2.0 up to version 2.3.2 suffer from over-synchronisation when running in multithreaded environment.
This causes the above mentioned Jersey 2.x versions not to be able to serve as many requests in parallel as previous Jersey 1.x versions
when running in the same environment. Latency of individual responses has not been impacted that much, so this problem should mainly
concern users who experience high volume of requests.

The major obstacles have been identified and fixed in HK2 and Jersey (on the server side), so that the above explained
"performance drop" is now less significant. Jersey 1.x could still serve about 1-3x more requests than Jersey 2.0-2.3.x
depending on concrete environment and use-case, but Jersey 2.x runtime should now scale up with the number of worker threads.

Closing this bug report as fixed as i have not seen 10x worse performance in Jersey 2.4-SNAPSHOT after the fix has been implemented.
When testing please bear in mind it could take JiT several minutes to make all necessary byte code optimisations, so be careful
when interpreting any numbers.

Another tasks will be likely filed to track further performance improvement efforts in Jersey 2.

Comment by Matt Hauck [ 03/Mar/14 ]

I am still seeing pretty bad performance numbers on jersey 2.6.

I have a simple "status" API that doesn't really do anything except return a java object with an "OK" status, which gets marshalled into JSON. Using an internal load tool, when I call this 1,000 times (w/ 5ms delay in between calls), I see an average time of 14ms, 90th percentile time of 26ms, and max time of 163ms. Running it against jersey 2, I am seeing 481ms average time, 862ms for 90th percentile, and max time of 1s 214ms. Both of these are results after the server is well-warmed up.

We are using jersey w/ spring integration. When I tried using the jersey-spring3 module, I was seeing horrendous results, at least double of what I listed above for jersey2 performance. So, I dropped that and wrote a simple integration to just pull beans from spring and skip any hk2 injection. This has improved the numbers some, but I'm still seeing a jump from 14ms to 481ms! That is more than 30x worse.

I will check with jersey 2.4 to see if a regression has happened since then, but I am very saddened by this. I was hoping to upgrade to jersey2 to get some of the newer async response features, but I'm not sure we'll be able to upgrade now...

(fwiw, I'm comparing with a rather old version of jersey: 1.3. Not sure how much changed in between 1.3 and 1.18 latest...)

Comment by Matt Hauck [ 03/Mar/14 ]

Okay, actually, I think most of the badness is in the spring3 module. I realized shortly after I commented here that I was running my tomcat server w/ jprofiler enabled. =P

However, the reason I turned on jprofiler was because the performance was really quite bad with the spring3 module in place. Using my own spring integration has helped out much actually, and on 2.6 I'm getting pretty good numbers down in the teens and low tens of milliseconds.

Good news. =)

Comment by message [ 03/Jul/14 ]

Jakub Podlesak can you please rerun benchmark once again with latest versions? 1.18.1 vs 2.10.1

Comment by Michael Osipov [ 04/Jul/14 ]

Matt Hauck, please share your Spring module improvements!

Comment by Jakub Podlesak [ 04/Jul/14 ]

Matt, i totally missed your earlier comments on Spring. Could you please file a separate issue to track this?
It would be great if you could share your code improvements. Would you be willing to contribute your fix to the Jersey project?

Comment by Matt Hauck [ 04/Jul/14 ]

ok. filed: https://java.net/jira/browse/JERSEY-2578





[JERSEY-1711] No request body recieved for @DELETE methods Created: 07/Feb/13  Updated: 26/Jun/14  Resolved: 07/Aug/13

Status: Resolved
Project: jersey
Component/s: core
Affects Version/s: 2.0-m12, 2.0
Fix Version/s: 2.2

Type: Bug Priority: Major
Reporter: kul Assignee: Marek Potociar
Resolution: Works as designed Votes: 0
Labels: None
Remaining Estimate: 0 minutes
Time Spent: 1 minute
Original Estimate: 3 hours
Environment:

Ubuntu, Embedded grizzly Server


Tags: delete, jersey, jersey-grizzly2

 Description   

For the given sample method in scala. I get no request body on server with

curl -XDELETE localhost:9090/top/delete/foo -d '{"aa": {"bb":"cc*"}}'

@Path("/top")
class DeleteRest{
@DELETE
@Path("/delete/

{foo}

")
def delete(body: String, @PathParam("foo") foo: String, @Suspended ar: AsyncResponse) =
{
println("got body: "+body)
......
//on some callback ar.resume()
}
}



 Comments   
Comment by Marek Potociar [ 07/Aug/13 ]

I have added a new E2E test into Jersey to verify the issue is no longer reproducible.

Comment by Marek Potociar [ 07/Aug/13 ]

The test was missing the body - reopening.

Comment by Marek Potociar [ 07/Aug/13 ]

Adding further investigation comments:

Apart from the fact that the whole use case seems flawed as request entity for HTTP DELETE is not defined and relying on it is highly interoperable as many frameworks do not support it, it seems that it will be difficult to fix this as the problem is not in Jersey layer.

FWIW, even if I override the client-side Jersey checks, the default Jersey connector implemented on top of HttpURLConnection from JDK fails on client side with

java.net.ProtocolException: HTTP method DELETE doesn't support output
   ...

when you try to get a request entity output stream for a HTTP DELETE method from an open HttpURLConnection instance. IOW, JDK default HTTP client connection implementation does not support request body on HTTP DELETE method.

And similarly, when I use curl to force sending body with DELETE, e.g.:

curl -d "body" -X DELETE  --trace-ascii /dev/stdout http://127.0.0.1:9998/injection/delete-path-param/test

Grizzly container on the server side completely ignores the input. IOW, Jersey does not even get any request entity data.

So, feel free to follow up with Grizzly folks and try to convince them that your use case is valid, but the issue is not in Jersey code. As such, I'm going to close the issue as "WORKS AS DESIGNED".

Comment by cowwoc [ 26/Jun/14 ]

FYI,

java.net.ProtocolException: HTTP method DELETE doesn't support output

was fixed in JDK 8: https://bugs.openjdk.java.net/browse/JDK-7157360





[JERSEY-1429] Unexpected 404 Created: 21/Sep/12  Updated: 09/Apr/13  Resolved: 08/Apr/13

Status: Resolved
Project: jersey
Component/s: None
Affects Version/s: 1.14, 2.0-m08
Fix Version/s: 2.0-rc2, 2.0

Type: Bug Priority: Major
Reporter: Mikhail Mazursky Assignee: Pavel Bucek
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: 0 minutes
Time Spent: 2 hours
Original Estimate: 3 hours
Environment:

Grizzly 2.2.18


Attachments: GZip Archive sample3.tar.gz    
Issue Links:
Duplicate
is duplicated by JERSEY-1771 @ApplicationPath does not work in Jer... Resolved
Tags: grizzly, guice, jersey

 Description   

A slightly modified version of JERSEY-1411, but fails in a different way. Please, see attachment.

Following resource, deployed to /hello1/hello2. Request to /hello1/hello2/anotherHello returns 404. If deployed to /hello, request to /hello/anotherHello works as expected.

HTTP/1.1 404 Not Found
Server: grizzly/2.2.18
Date: Fri, 21 Sep 2012 12:45:05 GMT
Content-Length: 0
@Path("")
@Singleton
public class HelloWorldResource {

	@GET
	@Path("anotherHello")
	@Produces(MediaType.TEXT_PLAIN)
	public String anotherHello() {
		return "anotherHello";
	}
}


 Comments   
Comment by Martin Matula [ 10/Oct/12 ]

I noticed a similar issue with Jersey 2.0 milestone builds in the past as well - seems when you use multiple path segments in the context path when deploying on grizzly it does not work for some reason. Pavel, please investigate.

Comment by Marek Potociar [ 06/Mar/13 ]

Moving to 2.0 unplanned (issues that should be fixed in the current sprint but which were not planned for the sprint), but with a lower priority.

Comment by Pavel Bucek [ 03/Apr/13 ]

looks like a issue in Grizzly container, filed http://java.net/jira/browse/GRIZZLY-1481

Comment by Pavel Bucek [ 04/Apr/13 ]

quick update.

when you are deploying/starting Grizzly container, you can specify full URI, BUT only first path segment is considered to be context path (which is most likely correct, seems like this is aligned with servlet specification document).

the other part of this issue is how is this state handled, I guess we need to at least describe what will happen when GrizzlyHttpServerFactory.createHttpServer(URI [,...]) is invoked.

Comment by Pavel Bucek [ 08/Apr/13 ]

updated container factory javadoc.

only first path segment is considered as context path, rest is ignored.

Comment by Mikhail Mazursky [ 08/Apr/13 ]

Will a warning with descripion of the issue be logged in that case?

Comment by Pavel Bucek [ 08/Apr/13 ]

no.

problem with this would be that we don't anyhow detect this case - this is just standard grizzly behavior, which may change in the future (see linked Grizzly issue) and then we should be able to remove this limitation. So, to produce this warning, we would need to parse path from given uri..





[JERSEY-1420] CLONE -Multipart/form-data POST having a quoted boundary parameter in the Content-Type header fails. Created: 11/Sep/12  Updated: 07/Feb/15  Resolved: 15/Nov/12

Status: Resolved
Project: jersey
Component/s: media
Affects Version/s: 1.12, 1.14
Fix Version/s: 1.16

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

Attachments: HTML File does_not_work_but_is_valid    
Issue Links:
Cloners
is cloned by JERSEY-2776 Regression -Multipart/form-data POST ... Resolved
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 voinescu_mihaela [ 11/Sep/12 ]

I'm using jersey version 1.X not 2.0 (which hasn't a stable version yet).
Tested issue with jersey 1.14 and the problem is still reproduced.

Is it possible for the issue to be fixed in a 1.X version?

Comment by Michal Gajdos [ 11/Sep/12 ]
  • setting fix version to 1.15
Comment by Michal Gajdos [ 12/Sep/12 ]

Can you, please, attach a simple reproducible test case? Somehow I am not able to simulate this in Jersey 1.14. Thanks.

Comment by Michal Gajdos [ 13/Sep/12 ]

Hm, this is weird. I created a simple test based on your case and it seems to be working. Do you have some other JAX-RS implementation on the classpath of your server (e.g. CXF, ..)? Can you try to run the client code I've posted below against your server?

xLightweb Client:

IHttpClientEndpoint httpClientConnection = new HttpClientConnection("localhost", 8080);
MultipartRequest req = new MultipartRequest("PUT",
        "http://localhost:8080/multipart-webapp/form/xlightweb",
        "multipart/form-data;boundary=\"MrmiiyyJEqRYcIJyun5tMVIz70NuQ_nfD\"");

Part part1 = new Part("message/rfc822", "To: z@web.de\n" +
        "\n" +
        "mailtext\n");
part1.addHeaderLine("Content-Disposition: form-data; name=\"mail\"; filename=\"mailBody.txt\"");
part1.addHeaderLine("Content-Transfer-Encoding: binary");
req.addPart(part1);

Part part2 = new Part("application/xml", "<?xml version=\"1.0\" encoding=\"UTF-8\" standalone=\"yes\"?>\n" +
        "<mailEventAdd>\n" +
        "    <mailboxName>mailbox-name</mailboxName>\n" +
        "</mailEventAdd>\n");
part2.addHeaderLine("Content-Disposition: form-data; name=\"metadata\"; filename=\"mailFolderMeta.xml\"");
part2.addHeaderLine("Content-Transfer-Encoding: binary");
req.addPart(part2);

httpClientConnection.call(req);

Server (just added a resource method to the MultipartResource in the multipart-webapp example:

@PUT
@Path("xlightweb")
@Consumes("multipart/form-data")
public void get(FormDataMultiPart formDataMultiPart) {
    // Do something.
}

Output:

[INFO] Started Jetty Server
Sep 13, 2012 12:16:51 PM com.sun.jersey.api.container.filter.LoggingFilter filter
INFO: 1 * Server in-bound request
1 > PUT http://localhost:8080/multipart-webapp/form/xlightweb
1 > Host: localhost:8080
1 > User-Agent: xLightweb/2.11-WSPreview2
1 > Content-Type: multipart/form-data;boundary="MrmiiyyJEqRYcIJyun5tMVIz70NuQ_nfD"
1 > Transfer-Encoding: chunked
1 > 
--MrmiiyyJEqRYcIJyun5tMVIz70NuQ_nfD
Content-Type: message/rfc822; charset=utf-8
Content-Disposition: form-data; name="mail"; filename="mailBody.txt"
Content-Transfer-Encoding: binary

To: z@web.de

mailtext

--MrmiiyyJEqRYcIJyun5tMVIz70NuQ_nfD
Content-Type: application/xml
Content-Disposition: form-data; name="metadata"; filename="mailFolderMeta.xml"
Content-Transfer-Encoding: binary

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<mailEventAdd>
    <mailboxName>mailbox-name</mailboxName>
</mailEventAdd>

--MrmiiyyJEqRYcIJyun5tMVIz70NuQ_nfD--


Sep 13, 2012 12:16:51 PM com.sun.jersey.api.container.filter.LoggingFilter$Adapter finish
INFO: 1 * Server out-bound response
1 < 204
1 <
Comment by voinescu_mihaela [ 14/Sep/12 ]

I have in my project some dependency on org.apache.cxf:cxf-rt-frontend-jaxrs:jar:2.3.1

Comment by Michal Gajdos [ 14/Sep/12 ]

Thanks. In this case it seems to be a similar issue to JERSEY-1377. When CXF is on the classpath then the RuntimeDelegate from CXF takes precedence over the one from Jersey (if not set otherwise). Unfortunately CXF classes are then parsing headers and creating a MediaType instance where boundary parameter is stored quoted. Jersey (particularly {{mimepull} library) does not assume this case could happen and eventually processing of the request fails with an exception you've seen.

Although I think this is a bug in CXF (created https://issues.apache.org/jira/browse/CXF-4504) I'll add a check in MultiPartReaderClientSide if the boundary parameter is quoted or not.

I the meantime you can use workaround described in JERSEY-1377:

In your WAR create a file called javax.ws.rs.ext.RuntimeDelegate in WEB-INF/classes/META-INF/services folder with the following contents:

com.sun.jersey.server.impl.provider.RuntimeDelegateImpl

I am here assuming that you also have jersey-server jar on your classpath. If you had a WAR that would only contain Jersey client jars on the classpath the contents of the mentioned file should look like:

com.sun.ws.rs.ext.RuntimeDelegateImpl
Comment by beryozkin_sergey [ 17/Sep/12 ]

As commented at https://issues.apache.org/jira/browse/CXF-4504:

Stripping the quotes from media type parameters will break the equality between the original value and the one obtained from MediaType.toString.

Comment by jontejj [ 07/Feb/15 ]

I tried the latest jersey-media-multipart 2.15 and I see that the line:
unquoteMediaTypeParameters(mediaType, "boundary");

from http://grepcode.com/file_/repo1.maven.org/maven2/com.sun.jersey.contribs/jersey-multipart/1.15/com/sun/jersey/multipart/impl/MultiPartReaderClientSide.java/?v=source

has not been applied to the jersey 2 code base.





[JERSEY-1377] Interaction of jersey server with multipart with cxf client fails Created: 16/Aug/12  Updated: 24/Feb/15  Resolved: 24/Feb/15

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

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

Windows 7 and tomcat 7


Tags: cxf, jersey, multipart

 Description   

When using a jersey client to retrieve multipart from a jersey server in a jersey-client/cxf mixed app reports that there is a missing start boundary.

After debugging I found that MediaType in jsr311-api-1.0.jar (used by cxf 2.2.2) is converting headers to lowercase. Since com.sun.jersey.multipart.Boundary.java is generating boundaries as
return new StringBuilder("Boundary_").
append(boundaryCounter.incrementAndGet()).
append('_').
append(new Object().hashCode()).
append('_').
append(System.currentTimeMillis()).
toString();
}

with an Upper case "Boundary", cxf would fail to find it in the body after the boundary case in the Content-Type is lowercased.

I am using jersey-client, yet javax.ws.rs is loaded from cxf given that the META-INF/services/javax.ws.rs.ext.RuntimeDelegate is found first in cxf and not in jersey-core.(I suspect that the web loader in tomcat finds "c" before "j")

Jersey's header and body are practically OK. It would be a cxf bug, except that it has to do with classpath conflicts between cxf and jersey-client. This could be easily fixed in Jersey by producing an all lowercase boundary.

The actual issue is that I have a legacy app that mixes both cfx and jersey-client. IMPORTANT: I am using the jersey client but cxf takes over. It would be OK for cfx to take over and it would do the right thing had it been lowercase.

The current workaround is to:
extract jersey's javax.ws.rs.ext.RuntimeDelegate
build the client WAR with the structure WEB-INF/classes/META-INF/services/javax.ws.rs.ext.RuntimeDelegate
start the app.

This is not entirely proper since the portions of the legacy application that use cxf would load jersey javax.ws.rs now.

The real fix is to force jersey-client to load its own classes, not going to the RuntimeDelegate et al to get the class names it requires. Going to get class names for RuntimeDelegate breaks jersey's encapsulation. It is an invitation for bugs.



 Comments   
Comment by Martin Matula [ 21/Aug/12 ]

OK, so the issue is that the Jersey uses RuntimeDelegate to get internal classes instead of just using them directly. And you are saying if we fix this, it will fix the issue, right?
Note that JAX-RS API itself uses RuntimeDelegate, so if it is in fact not the jersey client, but the jax-rs api that calls RuntimeDelegate, we can't fix it. Do you have any particular calls to RuntimeDelegate in mind?

Comment by Michal Gajdos [ 10/Sep/12 ]

Actually converting headers to lowercase is not done by javax.ws.rs.core.MediaType but the problem is in CXF (and because of the fact that RuntimeDelegate service class is picked up from CXF instead of Jersey).

org.apache.cxf.jaxrs.impl.MediaTypeHeaderProvider from CXF is responsible for parsing header lines and creating MediaType instance using the MediaType(String type, String subtype, Map<String, String> parameters) constructor. At this point the parameter names and values are already in lowercase (see [1] line 67-68).

Before touching anything in the Jersey code, can you change the version of CXF you're using? It seems that this problem has been fixed in CXF 2.2.5 (see [2], lines 67-68).

[1] http://grepcode.com/file/repo1.maven.org/maven2/org.apache.cxf/cxf-rt-frontend-jaxrs/2.2.2/org/apache/cxf/jaxrs/impl/MediaTypeHeaderProvider.java#67
[2] http://grepcode.com/file/repo1.maven.org/maven2/org.apache.cxf/cxf-rt-frontend-jaxrs/2.2.5/org/apache/cxf/jaxrs/impl/MediaTypeHeaderProvider.java#67

Comment by Michal Gajdos [ 12/Sep/12 ]

The issue with wrong RuntimeDelegate instance cannot be fixed in Jersey code in this case. As I mentioned the problem is in HeaderDelegate<MediaType> implementation present in CXF and an instance of this class is obtained and held in MediaType class itself (see [1], lines 44-45) which is in JAX-RS API.

One thing you can do is to set the RuntimeDelegate instance yourself (before any other Jersey code is invoked):

RuntimeDelegate.setInstance(new com.sun.ws.rs.ext.RuntimeDelegateImpl());

[1] http://grepcode.com/file/repo1.maven.org/maven2/javax.ws.rs/jsr311-api/1.1.1/javax/ws/rs/core/MediaType.java#44

Comment by jaimegarza61 [ 12/Sep/12 ]

I have realized that the only fix that could work for the Jersey team is for Jersey to produce headers in lower case.

I have set the runtime delegate with META-INF property files, which is similar to the last suggestion, and I am just waiting to find the shoe drop on the cxf side, with some kind of CXF client issue. I will be trying to upgrade my cxf across the company. Thanks for the comments.





[JERSEY-1279] Clear Resource State Between @Tests Created: 09/Jul/12  Updated: 04/Nov/13

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

Type: Improvement Priority: Minor
Reporter: timothy055 Assignee: Unassigned
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Java 1.7/Windows/32-bit


Tags: in-memory, jersey, test-framework

 Description   

The Jersey Test Framework does not currently reset Resources between tests. This does not allow each test case/method to be fully separable and can cause tests to be dependent on ordering and success for completion even when using in-memory objects.

Ideally, the test framework would re-instantiate the resources between tests.



 Comments   
Comment by timothy055 [ 09/Jul/12 ]

Original Discussion: http://java.net/projects/jersey/lists/users/archive/2012-07/message/6

Comment by Pavel Bucek [ 02/Aug/12 ]

will be handled in 2.0

Comment by hertzsprung [ 02/Jan/13 ]

This might be useful for us since we sometimes need to inject JMock proxies into Jersey resources, and these proxy objects are themselves stateful.





[JERSEY-1196] Apply Filters to Intercept Jersey Requests. Created: 01/Jun/12  Updated: 11/Jun/12  Resolved: 11/Jun/12

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

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

Linux, Windows 7 , JDK 1.6


Tags: filter, filterchain, jersey

 Description   

Need to hook & intercept request attributes of a particular URL pattern say /employee/* to the Jersey Framework.

Requirement :
The initialization of the filter class SHOULD NOT be done through web.xml entries. Rather it should be through implementing Filter interfaces and / or adding annotations to the filter classes.

Request to share working code snippets as there is less time to investigate.

Regards.



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

Please use the mailing list and/or stackoverflow.com to ask questions on how to do things in Jersey.

For this particular issue look at ContainerRequestFilter.





[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-1150] Jersey-Multipart: BodyPart and its subclasses don't implement equals or hashCode Created: 14/May/12  Updated: 08/Aug/13  Resolved: 24/May/12

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

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

Tags: equals, hashcode, jersey, multipart

 Description   

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



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

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

Comment by ttmrb [ 18/May/12 ]

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

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

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

This test fails with the following message:

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

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

Comment by Michal Gajdos [ 24/May/12 ]

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

Comment by ttmrb [ 25/May/12 ]

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

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

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

Thanks again.





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

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

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

Mac OSX, JDK 7, Glassfish 3.1.1


Tags: 405-response, jersey

 Description   

I have a WS class using Jersey annotations.

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

/filter/

{channel_id}

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

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

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

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

Any ideas

here is code examples to show you what all is happening

— Example of the GET

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

----- POST Example

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


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

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

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

Comment by jesmith17 [ 13/Mar/12 ]

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

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

The method in question had been defined as

@GET
@Path("/

{channelid}

/config ")

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

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

Comment by Pavel Bucek [ 13/Mar/12 ]

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

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

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

closing as works as designed.





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

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

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

windows 7; Apache Tomcat 7


Tags: expires, http, jersey

 Description   

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

I tried to edit the Response adding:

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

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



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

Pavel, please evaluate.

Comment by Pavel Bucek [ 16/Feb/12 ]

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

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





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

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

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

Doesn't matter


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

 Description   

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

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



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

thanks for submission and patch.

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

Comment by Pavel Bucek [ 24/May/12 ]

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





[JERSEY-801] Issue throwing WebApplicationException derived exception which include an entity value Created: 02/Nov/11  Updated: 06/Nov/13  Resolved: 06/Nov/13

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

Type: Bug Priority: Major
Reporter: gabrielkohen Assignee: Michal Gajdos
Resolution: Fixed Votes: 6
Labels: None
Remaining Estimate: 0 minutes
Time Spent: 1 hour, 30 minutes
Original Estimate: 6 hours
Environment:

Windows 7 Ultimate.


Attachments: Java Source File AuthenticationException.java    
Tags: jersey, jersey-server-linking

 Description   

The exception through is a pretty straight forward one. The message of the exception goes to the response entity member which is the common practice in the Jersey community. The code throwing my custom exception is:
if (authentication == null) {
throw new MappableContainerException(new AuthenticationException("Authentication credentials are required\r\n", "MyRealm"));

I get the following stack exception:
Nov 2, 2011 1:14:20 PM com.sun.jersey.server.impl.application.WebApplicationImpl _handleRequest
SEVERE: The RuntimeException could not be mapped to a response, re-throwing to the HTTP container
java.lang.IndexOutOfBoundsException: Index: 0, Size: 0
at java.util.LinkedList.entry(LinkedList.java:365)
at java.util.LinkedList.get(LinkedList.java:315)
at com.sun.jersey.server.linking.impl.LinkProcessor.getLinkHeaderValues(LinkProcessor.java:80)
at com.sun.jersey.server.linking.impl.LinkProcessor.processLinkHeaders(LinkProcessor.java:73)
at com.sun.jersey.server.linking.LinkFilter.filter(LinkFilter.java:95)
at com.sun.jersey.server.impl.application.WebApplicationImpl._handleRequest(WebApplicationImpl.java:1421)
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:708)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at com.sun.grizzly.http.servlet.FilterChainImpl.doFilter(FilterChainImpl.java:195)
at com.sun.grizzly.http.servlet.FilterChainImpl.invokeFilterChain(FilterChainImpl.java:139)
at com.sun.grizzly.http.servlet.ServletAdapter.doService(ServletAdapter.java:376)
at com.sun.grizzly.http.servlet.ServletAdapter.service(ServletAdapter.java:324)
at com.sun.grizzly.tcp.http11.GrizzlyAdapter.service(GrizzlyAdapter.java:166)
at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:791)
at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:693)
at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:954)
at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:170)
at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:135)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:102)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:88)
at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:76)
at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:53)
at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:57)
at com.sun.grizzly.ContextTask.run(ContextTask.java:69)
at com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:330)
at com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:309)
at java.lang.Thread.run(Thread.java:662)

It would seem that on getLinkHeaderValues we should check if we even have a valid resource. Instead:
Object resource = uriInfo.getMatchedResources().get(0);
Use:
if (uriInfo.getMatchedResources().isEmpty())
{
return new ArrayList<String>();
}

I'm not sure how to contribute the fix to the SVN. I've changed it locally.



 Comments   
Comment by gabrielkohen [ 02/Nov/11 ]

Sorry. The actual fix should be in the LinkFilter class on the filter method. We should probably check if there is a valid resource to work with:

 
    public ContainerResponse filter(ContainerRequest request, ContainerResponse response) {
        Object entity  = response.getEntity();
 
        if (entity != null&&!uriInfo.getMatchedResources().isEmpty()) {
            Class<?> entityClass = entity.getClass();
            LinkProcessor lhp = new LinkProcessor(entityClass);
            lhp.processLinkHeaders(entity, uriInfo, response.getHttpHeaders());
            RefProcessor lp = new RefProcessor(entityClass);
            lp.processLinks(entity, uriInfo);
        }
        return response;
    }
Comment by Andreas Klein [ 29/Feb/12 ]

Having the same issue in 1.12.

I wish to use com.sun.jersey.server.linking.LinkFilter by including it in my ContainerResponseFilters chain.

At the same time I use a custom ContainerRequestFilter to handle authentication and authorization.

Now if I try to throw Exceptions inside that request filter and have them handled by a registered ExceptionMapper, which shall include the exception's message String as entity (i.e. response body), then LinkFilter, or rather LinkProcessor's getLinkHeaderValues() method, throws the mentioned IndexOutOfBoundsException.

Handling exceptions thrown from inside resource methods works fine, the problem only comes up when an exception is to be processed earlier on, in the request filter chain. I guess gabrielkohen's proposed fix should do the trick.





[JERSEY-775] Unable to define WADL resources base in Jersey Created: 15/Sep/11  Updated: 10/Feb/12  Resolved: 15/Sep/11

Status: Closed
Project: jersey
Component/s: core
Affects Version/s: 1.9
Fix Version/s: 1.10

Type: Bug Priority: Major
Reporter: jckdnk111 Assignee: Marek Potociar
Resolution: Duplicate Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

RHEL 5.4 64bit / OpenJDK 1.6 / Jetty 7.5


Issue Links:
Duplicate
duplicates JERSEY-773 Regression: WADL resurces base URI cu... Resolved
Tags: jersey, rest, wadl

 Description   

Also found here - http://stackoverflow.com/questions/7404863/define-wadl-resources-base-in-jersey

I am using Jersey 1.9 and it is generating my WADL perfectly except I need to redefine the resources base URI.
I'm running Jetty 7 sitting behind Apache using mod_proxy as a reverse proxy to route REST requests back to Jetty / Jersey. So Jersey generates the resources base URI as

http://localhost:8080/testRestAPI/rest/

when I need something like

http://mydomain.com/rest/

I found this from Google but it is not working: http://jersey.576304.n2.nabble.com/Changing-baseURI-when-generating-WADL-td6169703.html



 Comments   
Comment by Pavel Bucek [ 15/Sep/11 ]

duplicate of 773; already fixed in the trunk





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

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

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

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


Tags: Client, Collection, Jersey, Set, SortedSet

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

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

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

    public OrderedAssembly() {
    }

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

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

    addAll(ss);
    }

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

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


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

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

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

Comment by abhi0123 [ 27/Jul/11 ]

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

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

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

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

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

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

I will keep this issue updated.

Comment by Pavel Bucek [ 14/Sep/11 ]

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

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

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

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

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

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

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

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





[JERSEY-618] Add a method getResourceConfigProperties in JerseyTest (Jersey Test Framework) Created: 06/Dec/10  Updated: 08/Aug/13  Resolved: 22/Feb/13

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

Type: Improvement Priority: Minor
Reporter: walec51 Assignee: Marek Potociar
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: jersey, testing

 Description   

It would be useful to have a getResourceConfigProperties in JerseyTest so that we can change properties in various tests. I personally needed it to test a MessabeBodyWriter which behaviour depends on some properties in the ResourceConfig. For now I had to do a workaround like this:

public class ResourceConfigSingelton {

private ResourceConfig config;

static protected ResourceConfigSingelton inst = null;

protected ResourceConfigSingelton(ResourceConfig config)

{ this.config = config; }

static public ResourceConfig createInstance(
ResourceConfig config)

{ inst = new ResourceConfigSingelton(config); return inst.config; }

static public ResourceConfig getInstance()

{ return inst.config; }

}

public class ThrowableWriterTest extends JerseyTest {

public ThrowableWriterTest()

{ super(new LowLevelAppDescriptor.Builder( ResourceConfigSingelton.createInstance( new DefaultResourceConfig(ThrowableWriterResource.class, ThrowableMapper.class, ThrowableWriter.class)) ).build()); }

@Test
public void testRuntimeExceptionToText() {
ResourceConfigSingelton.getInstance().getProperties().put(
"com.sun.jersey.config.property.exceptionOutput", "PLAIN_TEXT");
...



 Comments   
Comment by Marek Potociar [ 22/Feb/13 ]

Instead we need to look at supporting per-test configuration which is already filed as another issue.





[JAXB-989] Java's JAXB implementation does not handle underscores properly Created: 26/Nov/13  Updated: 26/Nov/13

Status: Open
Project: jaxb
Component/s: xjc
Affects Version/s: 2.2.7
Fix Version/s: None

Type: Bug Priority: Major
Reporter: prmatta Assignee: Iaroslav Savytskyi
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: 2 days
Time Spent: Not Specified
Original Estimate: 2 days

Tags: java, jaxb, jaxb-xjc, jersey

 Description   

The usecase to recreate the issue is to try and translate the following schema to java:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<xs:schema version="1.0" xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:complexType name="Foo_Bar">
<xs:sequence>
<xs:element name="name" type="xs:string" minOccurs="0"/>
<xs:element name="choices" type="TypeMyEnum" minOccurs="0"/>
</xs:sequence>
</xs:complexType>
<xs:simpleType name="TypeMyEnum">
<xs:restriction base="xs:string">
<xs:enumeration value="ALPHA_1_0_0"/>
<xs:enumeration value="BETA_2_0_0"/>
</xs:restriction>
</xs:simpleType>
</xs:schema>

By default, xjc will create a file called FooBar.java and a file called TypeMyEnum.java. Notice how xjc "ate" the underscore in Foo_Bar. Also, by default, the internals of TypeMyEnum look like this:

ALPHA_1_0_0,
BETA_2_0_0;

To get the underscore back in Foo_Bar, one has to use a bindings file as follows:

<jxb:bindings version="1.0"
xmlns:jxb="http://java.sun.com/xml/ns/jaxb">
<jxb:globalBindings underscoreBinding="asCharInWord"/>
</jxb:bindings>

Now, the code generates a Foo_Bar.java file as desired but horribly changes the internals of TypeMyEnum to look like:

@XmlEnumValue("ALPHA_1_0_0")
ALPHA__1_0__0("ALPHA_1_0_0"),

@XmlEnumValue("BETA_2_0_0")
BETA__2_0__0("BETA_2_0_0");
private final String value;

It seems every underscore in an enum value is changed to three underscores. This is the issue. This is easily reproducible and beyond me why xjc would do this.

There is no known way to get xjc to retain the underscore in the class name (i.e Foo_Bar.java) AND generate a sane enum file.






[HK2-249] Error whe undeploy on Tomca Created: 19/Mar/15  Updated: 24/Mar/15  Resolved: 24/Mar/15

Status: Resolved
Project: hk2
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: a.balduzzi Assignee: jwells
Resolution: Cannot Reproduce Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Tomcat 7


Tags: hk2, jersey

 Description   

I use hk2 2.4.0-b12 with Jersey 2.17 and Tomcat 7.0.56. When i stop and undeploy my application i have this error:

created a ThreadLocal with key of type [org.jvnet.hk2.internal.FactoryCreator$1] (value [org.jvnet.hk2.internal.FactoryCreator$1@11e7a26c]) and a value of type [java.util.HashSet] (value [[]]) but failed to remove it when the web application was stopped. Threads are going to be renewed over time to try and avoid a probable memory leak.



 Comments   
Comment by jwells [ 24/Mar/15 ]

I can't even figure out what FactoryCreator$1 would be. After I do a full build of HK2 I see:

$ find . -name "FactoryCreator*.class"
./hk2-locator/target/classes/org/jvnet/hk2/internal/FactoryCreator.class
$

I also don't see any ThreadLocal that takes a HashMap as a value in HK2.

Comment by jwells [ 24/Mar/15 ]

Also just inspecting the code of FactoryCreator I see no anonymous classes or other indications of where FactoryCreator$1 could be coming from

Comment by jwells [ 24/Mar/15 ]

Closing this as cannot reproduce since I think there must be some version mismatch here as there is no FactoryCreator$1.class in HK2





[HK2-181] jersey cannot work with java8 lambda code Created: 21/Jan/14  Updated: 21/Jan/14  Resolved: 21/Jan/14

Status: Closed
Project: hk2
Component/s: None
Affects Version/s: 2.1.*
Fix Version/s: None

Type: Bug Priority: Major
Reporter: doless Assignee: jwells
Resolution: Complete Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

java8


Issue Links:
Dependency
depends on JERSEY-2274 Shadow ASM classes with jersey specif... Resolved
Tags: asm, hk2, java8, jersey, lambda

 Description   

I upgraded a running jersey app from java7 to java8. Upon trying to use lambda syntax, i found that jersey fails because it uses hk2 which in turn uses a version of ASM that does not work with java8. Here are related issues:
https://java.net/jira/browse/HK2-140
https://java.net/jira/browse/HK2-138
https://java.net/jira/browse/HK2-136

I tried the work around of excluding asm-all from jersey and then including asm 5.0 beta (which fixes the issue), however, I got "java.lang.IncompatibleClassChangeError: Implementing class".

The goal of opening this bug is to not only have it addressed via a release, but also to find out if there is a solid, working work around for this issue in the time being.

Thank you!



 Comments   
Comment by jwells [ 21/Jan/14 ]

HK2 has already moved to asm 5.0_BETA in release 2.2.0. Jersey is working on integrating with it currently





[HK2-95] Provide HK2 injectable constructor selection algorithm that meets JSR299, JSR330 and JAX-RS requirements. Created: 01/Nov/12  Updated: 06/Dec/13  Resolved: 06/Dec/13

Status: Resolved
Project: hk2
Component/s: None
Affects Version/s: 2.1.*
Fix Version/s: 2.1.*

Type: New Feature Priority: Critical
Reporter: Marek Potociar Assignee: jwells
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: cdi, jax-rs, jersey

 Description   

JAX-RS spec says:

If more than one public constructor is suitable then an implementation MUST use the one with the most parameters. Choosing amongst suitable constructors with the same number of parameters is implementation specific, implementations SHOULD generate a warning about such ambiguity.

JSR330 says:

Injectable constructors are annotated with @Inject and accept zero or more dependencies as arguments. @Inject can apply to at most one constructor per class.

Proposed solution:

  • If @Inject-annotated constructor exists, use that one
    • if more @Inject-annotated constructors exist, fail
  • If there's no @Inject-annotated constructor, then:
    • find all other injectable constructors (including no-arg or default constructors) and select the one with most parameters
      • if there are more constructors with most parameters, select first one and log warning.


 Comments   
Comment by jwells [ 07/Jan/13 ]

Unfortunately section 3.1.3 of CDI specifies:

If the managed bean does not have a constructor that takes no parameters, it must have a constructor annotated @Inject.
No additional special annotations are required.

Unfortunately, the CDI specification (JSR 299) and the JAX-RS specification seem to be at odds on this issue.

I wonder if we need to make this about the constructor being public. Like, if there is a PUBLIC zero-arg constructor, we use it (which would satisfy 299) and if not then we use the PUBLIC constructor with the greatest number of arguments, which would kind of satisfy JAX-RS.

Of course, we will then run into the situation where a class has two constructors:

public class Foo {
public Foo() {
}

public Foo(Bar bar) {
}
}

The trouble is that now HK2 can't pick. It will either be CDI-style happy (pick the zero-arg constructor) or JAX-RS happy (pick the one-arg constructor). Do we need to add a field or something to the descriptor saying how it should resolve this conflict?

Comment by jwells [ 30/Jan/13 ]

This has been fixed by adding a new service called "ClassAnalyzer" that allows descriptors to choose how to analyze a class for its constructors, initializer methods, fields to be injected, post-construct method and pre-destroy method.

The default ClassAnalyzer chooses the 299 approach (prefers the zero-arg constructor). However, we have also supplied a "prefers the constructor with the most parameters" choice as well, which can be used by using the ServiceLocatorUtilities.addPreferLargestConstructorClassAnalyzer. To be clear, JAX-RS descriptors should therefor have a ClassAnalyzer name of ServiceLocatorUtilities.PREFER_LARGEST_CONSTRUCTOR. (The ClassAnalyzer name can be set on a Descriptor).

Among other parts of the solution:

The @Service annotation now also takes an "analyzer" field which allows descriptors to choose their analyzer with an annotation.

We will update GlassFish to call the addPreferLargestConstructorClassAnalyzer so that it can be used.





[HK2-69] Add support for @Unqualified annotation Created: 23/Jul/12  Updated: 06/Dec/13  Resolved: 06/Dec/13

Status: Resolved
Project: hk2
Component/s: None
Affects Version/s: 2.1.*
Fix Version/s: 2.1.*

Type: New Feature Priority: Critical
Reporter: Marek Potociar Assignee: jwells
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: api, jersey

 Description   

The annotation should work both with ServiceLocator.getAllServices(...) as well as with IterableProvider.



 Comments   
Comment by jwells [ 24/Sep/12 ]

Implemented





[HK2-66] Merge Descriptor and ActiveDescriptor in the public API Created: 16/Jul/12  Updated: 06/Dec/13  Resolved: 06/Dec/13

Status: Resolved
Project: hk2
Component/s: None
Affects Version/s: 2.1.*
Fix Version/s: 2.1.*

Type: Improvement Priority: Critical
Reporter: Marek Potociar Assignee: jwells
Resolution: Duplicate Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: api, jersey

 Description   

From the end-user perspective the two API classes make no difference and just cause confusion around which one should be used. The differentiation seems to be an internal implementation detail that should be dealt with inside the impl and not exposed to the end users.



 Comments   
Comment by jwells [ 17/Jul/12 ]

Dup of HK2-65





[HK2-65] Merge Descriptor and ActiveDescriptor in the public API Created: 16/Jul/12  Updated: 06/Dec/13  Resolved: 06/Dec/13

Status: Resolved
Project: hk2
Component/s: None
Affects Version/s: 2.1.*
Fix Version/s: 2.1.*

Type: Improvement Priority: Minor
Reporter: Marek Potociar Assignee: jwells
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: api, jersey

 Description   

From the end-user perspective the two API classes make no difference and just cause confusion around which one should be used. The differentiation seems to be an internal implementation detail that should be dealt with inside the impl and not exposed to the end users.



 Comments   
Comment by jwells [ 10/Jun/13 ]

The Descriptor is a representation of the service using only serializable (and simple) fields such as boolean, int an String. ActiveDescriptor is a more complete description of the service but has non-serializable fields such as Class and Annotation. These things are different enough that we will keep them separate.





[HK2-64] Add ServiceLocator.createDynamicConfiguration() convenience method Created: 16/Jul/12  Updated: 06/Dec/13  Resolved: 06/Dec/13

Status: Resolved
Project: hk2
Component/s: None
Affects Version/s: 2.1.*
Fix Version/s: 2.1.*

Type: New Feature Priority: Major
Reporter: Marek Potociar Assignee: jwells
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: api, jersey

 Description   

We have a lot of places where we just repeat the same code:

final DynamicConfigurationService dcs = serviceLocator.getService(DynamicConfigurationService.class);
final DynamicConfiguration dc = dcs.createDynamicConfiguration();

Seems the only use case for working with DCS is really just to create a new configuration. So I'd say the DCS could be hidden as an internal HK2 impl detail and the DC could be directly exposed via ServiceLocator interface:

final DynamicConfiguration dc = serviceLocator.createDynamicConfiguration();


 Comments   
Comment by jwells [ 22/Oct/12 ]

I added this method to ServiceLocatorUtilities





Modular binding & injection API (HK2-30)

[HK2-49] Change the default binding scope to "per lookup". Created: 24/Jan/12  Updated: 06/Dec/13  Resolved: 06/Dec/13

Status: Resolved
Project: hk2
Component/s: None
Affects Version/s: 2.1.*
Fix Version/s: 2.1.*

Type: Sub-task Priority: Critical
Reporter: Marek Potociar Assignee: jwells
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: jersey

 Description   

Currently it is "singleton", that goes against JSR 330.






Modular binding & injection API (HK2-30)

[HK2-48] Uptake Jersey AbstractBinder to the API (related to the uptaking Jersey fluent binding API task) Created: 24/Jan/12  Updated: 06/Dec/13  Resolved: 06/Dec/13

Status: Resolved
Project: hk2
Component/s: None
Affects Version/s: 2.1.*
Fix Version/s: 2.1.*

Type: Sub-task Priority: Major
Reporter: Marek Potociar Assignee: jwells
Resolution: Duplicate Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: jersey

 Description   

The module should make binding definition less verbose.

See e.g. http://google-guice.googlecode.com/svn/trunk/javadoc/com/google/inject/AbstractModule.html



 Comments   
Comment by jwells [ 22/Oct/12 ]

Dup of HK2-61





Modular binding & injection API (HK2-30)

[HK2-47] Ability to bind single class/factory/instance to multiple contracts. Created: 24/Jan/12  Updated: 06/Dec/13  Resolved: 06/Dec/13

Status: Resolved
Project: hk2
Component/s: None
Affects Version/s: 2.1.*
Fix Version/s: 2.1.*

Type: Sub-task Priority: Major
Reporter: Marek Potociar Assignee: jwells
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: jersey

 Description   

Currently the following code

  binderFactory.bind(ContractA.class).to(Service.class);
  binderFactory.bind(ContractB.class).to(Service.class);

or

  binderFactory.bind(ContractA.class).toFactory(ServiceFactory.class).in(SomeScope.class);
  binderFactory.bind(ContractB.class).toFactory(ServiceFactory.class).in(SomeScope.class);

results in 2 separate instances of Service/ServiceFactory class being constructed to resolve the injection of ContractA or ContractB respectively.

While sometimes this may be desired, more often the scenario requires that both ContractA as well as ContractB are resolved using just the same single instance of Service/ServiceFactory class in a given scope.

Resolving the problem with the current API is currently not intuitive and error prone.






[HK2-46] Multi-bindings (service provider bindings) Created: 24/Jan/12  Updated: 06/Dec/13  Resolved: 06/Dec/13

Status: Resolved
Project: hk2
Component/s: None
Affects Version/s: 2.1.*
Fix Version/s: 2.1.*

Type: New Feature Priority: Major
Reporter: Marek Potociar Assignee: jwells
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: jersey

 Description   

SPI/plugin support;

If multiple bindings for the same type T are defined, automatic injection of all bindings into @Inject Set<T> implementations should be possible. (See also: http://code.google.com/p/google-guice/wiki/Multibindings)



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

Use IterableProvider.





[HK2-45] Support for "assisted" injection Created: 24/Jan/12  Updated: 06/Dec/13  Resolved: 06/Dec/13

Status: Resolved
Project: hk2
Component/s: None
Affects Version/s: 2.1.*
Fix Version/s: 2.1.*

Type: New Feature Priority: Minor
Reporter: Marek Potociar Assignee: Unassigned
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: jersey

 Description   

See http://code.google.com/p/google-guice/wiki/AssistedInject



 Comments   
Comment by tlcksnyder [ 12/Oct/12 ]

completed





[HK2-44] Support for "just-in-time" bindings Created: 24/Jan/12  Updated: 06/Dec/13  Resolved: 06/Dec/13

Status: Resolved
Project: hk2
Component/s: None
Affects Version/s: 2.1.*
Fix Version/s: 2.1.*

Type: New Feature Priority: Minor
Reporter: Marek Potociar Assignee: Unassigned
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: jersey

 Description   

Just-in-time bindings via annotations (@ImplementedBy, @ProvidedBy), see http://code.google.com/p/google-guice/wiki/JustInTimeBindings

Similar concept to CDI provider methods.



 Comments   
Comment by tlcksnyder [ 12/Oct/12 ]

completed





[HK2-43] Support for private modules Created: 24/Jan/12  Updated: 06/Dec/13  Resolved: 06/Dec/13

Status: Resolved
Project: hk2
Component/s: None
Affects Version/s: 2.1.*
Fix Version/s: 2.1.*

Type: New Feature Priority: Minor
Reporter: Marek Potociar Assignee: Unassigned
Resolution: Duplicate Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Duplicate
duplicates HK2-88 Add the ability to have local services Resolved
Related
is related to HK2-61 Uptake the fluent binder API from Jer... Resolved
Tags: jersey

 Description   

Private module is a module that defines bindings that are available to the bindings defined in the direct parent module.

See http://google-guice.googlecode.com/svn/trunk/javadoc/com/google/inject/PrivateModule.html



 Comments   
Comment by Marek Potociar [ 01/Nov/12 ]

Is a partial duplicate of HK2-88.





[HK2-42] Integration with other GlassFish Containers & Modules (Servlet, EJB ...) Created: 24/Jan/12  Updated: 07/Aug/14

Status: Open
Project: hk2
Component/s: None
Affects Version/s: 2.1.*
Fix Version/s: 2.4.0

Type: New Feature Priority: Critical
Reporter: Marek Potociar Assignee: jwells
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: jersey

 Description   

HK2 needs to be able to use bindings from other GF containers & modules.






Integration with other DI providers (HK2-57)

[HK2-41] CDI (or at least CDI impl in GF) integration Created: 24/Jan/12  Updated: 06/Dec/13  Resolved: 06/Dec/13

Status: Resolved
Project: hk2
Component/s: None
Affects Version/s: 2.1.*
Fix Version/s: 2.1.*

Type: Sub-task Priority: Critical
Reporter: Marek Potociar Assignee: jwells
Resolution: Fixed Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Dependency
blocks JERSEY-1024 Integration with CDI Resolved
blocks JERSEY-1778 Make CDI integration Jersey code use ... Open
Tags: jersey

 Description   

HK2 needs to be able to delegate injection to CDI provider. Generic support is preferrable, but GlassFish specific support would be good enough.

The typical use case for CDI / JAX-RS (Jersey) integration is a CDI bean (whose life-cycle is managed by CDI container) but is at the same time a JAX-RS resource that needs Jersey to satisfy the JAX-RS specific injection points. E.g.:

@SessionScoped   // <-- CDI managed
@Path("foo/{id}")   // <-- JAX-RS resource
public class FooResource {
    @Inject MyEjb ejb;    // <-- injection point resolved by CDI
    @Context UriInfo uriInfo;    // <-- injection point resolved by Jersey (via HK2)

    ...
}

In the example above the FooResource needs to be managed by a CDI container and when Jersey tries to retrieve an instance of it via HK2 (e.g. via ServiceLocator.getService(FooResource.class)), the HK2 needs to recognize the bean is managed by an external container (CDI) and needs to retrieve it from that container.

Also, the HK2 needs to be able to register an CDI extension bean in the CDI container that will be able to resolve custom (in our case JAX-RS) injection points that were added to the HK2 ServiceLocator by Jersey.

In summary, the process of retrieval of an externally managed (CDI) component by Jersey via HK2 should look like:

  1. Jersey asks HK2 for a component instance
  2. HK2 does not have a descriptor so it consults the external provider(s) (in our case CDI) to provide the component instance
  3. External provider creates and injects the instance
    • During that phase external provider consults HK2 integration layer (in our case a CDI extension) to resolve the unsatisfied (JAX-RS/Jersey specific) injection points
  4. External provider returns the component to HK2
  5. HK2 passes the component to Jersey

Note that the above could be converted into a generic HK2 external component provider API that is not necessarily CDI specific, but could be reused to integrate other injection providers too (Spring, Guice, ...). Obviously I do not insist on this particular solution. The important part is the use case demonstrating the problem that we need to solve.



 Comments   
Comment by TangYong [ 12/Sep/12 ]

Good use case!

I want to know whether having a plan to implement the task because a test case from osgi-javaee is also blocked by the task.

Comment by mikael.karon [ 05/Apr/13 ]

We (Adrian.Gonzalez and Mikael.Karon) are working on getting a mixed stack of vertx (http://vertx.io) 2.0 and jersey 2.0 up and running and would really like this to.

We currently have guice integration for vertx working, and for a while (a few revisions ago) we had a working example with jersey 1.x, vertx 2.0 and guice working fine (via IoCComponentProviderFactory) but as that is all replaced with HK2...

Comment by jwells [ 05/Apr/13 ]

There is already hk2/CDI integration in GlassFish applications. This is not closed yet because we are not yet sure it meets all requirements, but the basics are there...

Comment by jwells [ 02/Jul/13 ]

HK2 and CDI have bi-directional injection capabilities. At this point, if there are any issues with it they should be tracked as separate bugs.





Integration with other DI providers (HK2-57)

[HK2-40] Spring integration. Created: 24/Jan/12  Updated: 06/Dec/13  Resolved: 06/Dec/13

Status: Resolved
Project: hk2
Component/s: None
Affects Version/s: 2.1.*
Fix Version/s: 2.1.*

Type: Sub-task Priority: Minor
Reporter: Marek Potociar Assignee: jwells
Resolution: Fixed Votes: 9
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Dependency
blocks JERSEY-750 Officially Support Spring 3.0.X Resolved
Tags: jersey

 Description   

HK2 needs to be able to delegate injection to Spring.



 Comments   
Comment by tlcksnyder [ 26/Jul/12 ]

reassign due to Tom leaving Oracle.

Comment by jwells [ 02/Jul/13 ]

A Spring bridge has been implemented that works in both directions. I will keep this bug open until it is documented.

Comment by jwells [ 11/Jul/13 ]

The basic work of the bridge is done and documented here:

https://hk2.java.net/spring-bridge/index.html

I will close this now. Any bugs with the Spring bridge should be entered as separate bugs.





Modular binding & injection API (HK2-30)

[HK2-38] It should be possible to retrieve Factory and JSR330 Provider instances from Services.forContract()/byType() Created: 24/Jan/12  Updated: 06/Dec/13  Resolved: 06/Dec/13

Status: Resolved
Project: hk2
Component/s: None
Affects Version/s: 2.1.*
Fix Version/s: 2.1.*

Type: Sub-task Priority: Major
Reporter: Marek Potociar Assignee: jwells
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: jersey

 Description   

Ideally, HK2 Provider should extend Factory that would extend JSR330 Provider.






Modular binding & injection API (HK2-30)

[HK2-35] Add API for custom injection point annotations. Created: 24/Jan/12  Updated: 06/Dec/13  Resolved: 06/Dec/13

Status: Resolved
Project: hk2
Component/s: None
Affects Version/s: 2.1.*
Fix Version/s: 2.1.*

Type: Sub-task Priority: Major
Reporter: Marek Potociar Assignee: jwells
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: jersey

 Description   

Currently to support custom injection point annotations (e.g. JAX-RS @Context, @PathParam ...) it is necessary to use non-public InjectionResolver API.
Proposed solution is to move the IR interface into a public API package and document it properly.



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

InjectionResolver was added.





Modular binding & injection API (HK2-30)

[HK2-34] Add/document custom scopes support Created: 24/Jan/12  Updated: 06/Dec/13  Resolved: 06/Dec/13

Status: Resolved
Project: hk2
Component/s: None
Affects Version/s: 2.1.*
Fix Version/s: 2.1.*

Type: Sub-task Priority: Major
Reporter: Marek Potociar Assignee: jwells
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: jersey

 Description   

It's not clear how to properly support scoping annotations (annotated with javax.inject.Scope) and how to link them with proper scope implementations. E.g. how to define a link between custom RequestScope scope class and @RequestScoped scoping annotation?



 Comments   
Comment by jwells [ 07/Feb/13 ]

http://hk2.java.net/hk2-api/extensibility.html#Adding_a_Scope_and_Context_to_the_system





Modular binding & injection API (HK2-30)

[HK2-33] Injector and Services APIs should be merged into one class containing functionality of both. Created: 24/Jan/12  Updated: 06/Dec/13  Resolved: 06/Dec/13

Status: Resolved
Project: hk2
Component/s: None
Affects Version/s: 2.1.*
Fix Version/s: 2.1.*

Type: Sub-task Priority: Major
Reporter: Marek Potociar Assignee: jwells
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: jersey

 Description   

The differences are quite cosmetic and not relevant for the API user.






Modular binding & injection API (HK2-30)

[HK2-32] Add API for generating strings 100% compatible with Services.forContract(String) and Services.byType(String). Created: 24/Jan/12  Updated: 06/Dec/13  Resolved: 17/Jul/12

Status: Resolved
Project: hk2
Component/s: None
Affects Version/s: 2.1.*
Fix Version/s: None

Type: Sub-task Priority: Major
Reporter: Marek Potociar Assignee: Unassigned
Resolution: Invalid Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: jersey

 Description   

E.g.:

    /**
     * Build a string definition for a generic contract.
     *
     * @param rawType raw generic type.
     * @param types actual generic type arguments.
     * @return string definition for a generic contract.
     */
    public static String contractStringFor(Class<?> rawType, Type... types);

It should be handled via the same logic as HK2 internal exploreType(...) method.



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

Not applicable anymore.





Modular binding & injection API (HK2-30)

[HK2-31] Merge Services.forContract and Services.byType functionality into a single method. Created: 24/Jan/12  Updated: 06/Dec/13  Resolved: 06/Dec/13

Status: Resolved
Project: hk2
Component/s: None
Affects Version/s: 2.1.*
Fix Version/s: 2.1.*

Type: Sub-task Priority: Major
Reporter: Marek Potociar Assignee: jwells
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: jersey

 Description   

Services.forContract and Services.byType should be merged into a single method; esp. with programatic bindings there is no easy way of knowing for sure if a class is registered as a contract or not.

The solution could be to either merge the existing methods or add a new one on top of them.






[HK2-30] Modular binding & injection API Created: 24/Jan/12  Updated: 06/Dec/13  Resolved: 06/Dec/13

Status: Resolved
Project: hk2
Component/s: None
Affects Version/s: 2.1.*
Fix Version/s: 2.1.*

Type: New Feature Priority: Critical
Reporter: Marek Potociar Assignee: Unassigned
Resolution: Fixed Votes: 0
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

Issue Links:
Related
is related to HK2-61 Uptake the fluent binder API from Jer... Resolved
Sub-Tasks:
Key
Summary
Type
Status
Assignee
HK2-31 Merge Services.forContract and Servic... Sub-task Resolved jwells  
HK2-32 Add API for generating strings 100% c... Sub-task Resolved  
HK2-33 Injector and Services APIs should be ... Sub-task Resolved jwells  
HK2-34 Add/document custom scopes support Sub-task Resolved jwells  
HK2-35 Add API for custom injection point an... Sub-task Resolved jwells  
HK2-36 Better documentation on the injection... Sub-task Resolved jwells  
HK2-38 It should be possible to retrieve Fac... Sub-task Resolved jwells  
HK2-47 Ability to bind single class/factory/... Sub-task Resolved jwells  
HK2-48 Uptake Jersey AbstractBinder to the A... Sub-task Resolved jwells  
HK2-49 Change the default binding scope to "... Sub-task Resolved jwells  
Tags: jersey

 Description   

This is an umbrella RFE for programmatic injection API. It covers e.g.

  • defining custom static injection bindings (grouped into modules)
  • defining custom injection bindings dynamically (to an existing Injector or Services)
  • defining custom injection providers (factories) that are (potentially) context-aware
  • defining custom injection point annotations (i.e. @Inject substitution)
  • defining custom injection scopes
  • performing class & instance-based injection
  • performing method parameter injection, i.e. return the injected values for parameters of a method


 Comments   
Comment by tlcksnyder [ 12/Oct/12 ]

completed





[GRIZZLY-1404] Servlet Mapping Issue when integrating Jersey and Spring Created: 15/Jan/13  Updated: 02/Apr/13  Resolved: 15/Jan/13

Status: Resolved
Project: grizzly
Component/s: http, http-servlet
Affects Version/s: 2.2.19
Fix Version/s: 2.2.20, 2.3, 3.0

Type: Bug Priority: Minor
Reporter: nennenpow Assignee: oleksiys
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: grizzly, jersey, servlet, spring

 Description   

Can follow this link
http://grizzly.1045725.n5.nabble.com/Integration-Grizzly2-2-X-with-Jersey-and-Spring-td5710024.html

I am trying to integrate Grizzly v2.2.19 with Jersey and Spring
Below is my code

HttpServer server = new HttpServer();
NetworkListener listener = new NetworkListener("grizzly2", "localhost",3388);
WebappContext ctx = new WebappContext("ctx","/");
final ServletRegistration reg = ctx.addServlet("spring", new SpringServlet());
reg.addMapping("/*");
ctx.addContextInitParameter("contextConfigLocation","classpath:spring-context.xml");
ctx.addListener("org.springframework.web.context.ContextLoaderListener");
ctx.addListener("org.springframework.web.context.request.RequestContextListener");
ctx.deploy(server);
server.start();

The code could be compiled and executed with no exception. However all urls which should be forwarded to different methods by Jersey are
now all forwarded to the default page "/".

Thanks to Oleksiy.
There is a workaround as below
Change
WebappContext ctx = new WebappContext("ctx","/");
to
WebappContext ctx = new WebappContext("ctx","");

I file this issue as it is still not an expected behavior.



 Comments   
Comment by oleksiys [ 15/Jan/13 ]

fixed

[2.2.x]
Revision: 8e17fef89bd289a629d4cfc36195de3556e41213
Date: 2013-01-15 16:00:51 UTC

[2.3.x]
Revision: 029e5a591d65a81ca808d111994a1d4b335cce80
Date: 2013-01-15 15:59:54 UTC

[master]
Revision: b98e11ceeb7cac4888024b6df045367a6f6ca73d
Date: 2013-01-15 15:59:54 UTC

Log Message:
------------
+ fix issue #1404
http://java.net/jira/browse/GRIZZLY-1404
"Servlet Mapping Issue when integrating Jersey and Spring"





[GLASSFISH-21284] test failures in admin devtests after last HK2 integration (2.4.0-b06) Created: 09/Jan/15  Updated: 09/Feb/15  Resolved: 09/Feb/15

Status: Resolved
Project: glassfish
Component/s: admin
Affects Version/s: None
Fix Version/s: future release

Type: Bug Priority: Critical
Reporter: Romain Grécourt Assignee: jwells
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: File GLASSFISH-21284.sh    
Tags: admin, glassfish, hk2, jersey

 Description   

list of failed tests:

lbconfig:

58.delete-http-lb-config FAILED!!!
59.create-http-lb-config FAILED!!!
62.disable-http-lb-server FAILED!!!
64.delete-http-lb-server-ref FAILED!!!
65.delete-http-lb-config FAILED!!!

getset:

issue-12172-delete-cl-no-ins

Note that it was integrated by jersey team at the time of the integration of jersey 2.14.

The issue itself seems to be in the HK2 config system. When a config ref is removed, the reference stays in memory but is persisted to the config file properly. A restart acts as a workaround.



 Comments   
Comment by Romain Grécourt [ 20/Jan/15 ]

attaching reproducer script.

Comment by Romain Grécourt [ 09/Feb/15 ]
Project:    glassfish
Repository: svn
Revision:   63761
Author:     jwells
Date:       2015-02-07 20:30:15 UTC
Link:       

Log Message:
------------
Fix asadmin tests that do negative transactions in hk2-config


Revisions:
----------
63761


Modified Paths:
---------------
trunk/main/nucleus/admin/config-api/src/test/java/com/sun/enterprise/configapi/tests/TransactionCallBackTest.java
trunk/main/nucleus/common/amx-core/src/main/java/org/glassfish/admin/amx/impl/config/AMXConfigImpl.java
trunk/main/nucleus/pom.xml
trunk/main/nucleus/admin/config-api/src/test/java/com/sun/enterprise/configapi/tests/DirectCreationTest.java


Diffs:
------
Index: trunk/main/nucleus/common/amx-core/src/main/java/org/glassfish/admin/amx/impl/config/AMXConfigImpl.java
===================================================================
--- trunk/main/nucleus/common/amx-core/src/main/java/org/glassfish/admin/amx/impl/config/AMXConfigImpl.java	(revision 63760)
+++ trunk/main/nucleus/common/amx-core/src/main/java/org/glassfish/admin/amx/impl/config/AMXConfigImpl.java	(revision 63761)
@@ -417,12 +417,12 @@
         /**
             Convert incoming attributes to HK2 requirements.
          */
-            List<ConfigSupport.AttributeChanges>
+            List<AttributeChanges>
         toAttributeChanges(final Map<String, Object> values)
         {
             if ( values == null ) return null;
             
-            final List<ConfigSupport.AttributeChanges> changes = ListUtil.newList();
+            final List<AttributeChanges> changes = ListUtil.newList();
             for (final String xmlName : mAttrs.keySet() )
             {
                 final Object value = mAttrs.get(xmlName);
@@ -728,7 +728,7 @@
     /**
     Callback to create sub-elements (recursively) on a newly created child element.
      */
-    private final class SubElementsCallback implements ConfigSupport.TransactionCallBack<WriteableView>
+    private final class SubElementsCallback implements TransactionCallBack<WriteableView>
     {
         private final List<CreateParams> mSubs;
 
Index: trunk/main/nucleus/admin/config-api/src/test/java/com/sun/enterprise/configapi/tests/DirectCreationTest.java
===================================================================
--- trunk/main/nucleus/admin/config-api/src/test/java/com/sun/enterprise/configapi/tests/DirectCreationTest.java	(revision 63760)
+++ trunk/main/nucleus/admin/config-api/src/test/java/com/sun/enterprise/configapi/tests/DirectCreationTest.java	(revision 63761)
@@ -49,6 +49,7 @@
 import org.glassfish.tests.utils.Utils;
 import static org.junit.Assert.*;
 import org.junit.Test;
+import org.jvnet.hk2.config.AttributeChanges;
 import org.jvnet.hk2.config.ConfigBean;
 import org.jvnet.hk2.config.ConfigBeanProxy;
 import org.jvnet.hk2.config.ConfigSupport;
@@ -120,7 +121,7 @@
 
         support.createAndSet(serviceBean, DasConfig.class, (List) null);
 
-        List<ConfigSupport.AttributeChanges> profilerChanges = new ArrayList<ConfigSupport.AttributeChanges>();
+        List<AttributeChanges> profilerChanges = new ArrayList<AttributeChanges>();
         String[] values = { "-Xmx512m", "-RFtrq", "-Xmw24" };
         ConfigSupport.MultipleAttributeChanges multipleChanges = new ConfigSupport.MultipleAttributeChanges("jvm-options", values );
         String[] values1 = { "profile" };
Index: trunk/main/nucleus/admin/config-api/src/test/java/com/sun/enterprise/configapi/tests/TransactionCallBackTest.java
===================================================================
--- trunk/main/nucleus/admin/config-api/src/test/java/com/sun/enterprise/configapi/tests/TransactionCallBackTest.java	(revision 63760)
+++ trunk/main/nucleus/admin/config-api/src/test/java/com/sun/enterprise/configapi/tests/TransactionCallBackTest.java	(revision 63761)
@@ -46,6 +46,7 @@
 import org.glassfish.tests.utils.Utils;
 import org.jvnet.hk2.config.ConfigBean;
 import org.jvnet.hk2.config.ConfigSupport;
+import org.jvnet.hk2.config.TransactionCallBack;
 import org.jvnet.hk2.config.TransactionFailure;
 import org.jvnet.hk2.config.WriteableView;
 
@@ -89,7 +90,7 @@
         configChanges.put("name", "funky-listener");
 
         ConfigSupport.createAndSet(serviceBean, NetworkListener.class, configChanges,
-                new ConfigSupport.TransactionCallBack<WriteableView>() {
+                new TransactionCallBack<WriteableView>() {
                     @SuppressWarnings({"unchecked"})
                     public void performOn(WriteableView param) throws TransactionFailure {
                         // if you know the type...
Index: trunk/main/nucleus/pom.xml
===================================================================
--- trunk/main/nucleus/pom.xml	(revision 63760)
+++ trunk/main/nucleus/pom.xml	(revision 63761)
@@ -147,8 +147,8 @@
         <servlet-api.version>3.1.0</servlet-api.version>
         <grizzly.version>2.3.15-gfa</grizzly.version>
         <saaj-api.version>1.3.4</saaj-api.version>
-        <hk2.version>2.4.0-b06</hk2.version>
-        <hk2.plugin.version>2.4.0-b06</hk2.plugin.version>
+        <hk2.version>2.4.0-b10</hk2.version>
+        <hk2.plugin.version>2.4.0-b10</hk2.plugin.version>
         <javax.el.version>3.0.1-b03</javax.el.version>
         <javax.el-api.version>3.0.1-b03</javax.el-api.version>
         <trilead-ssh2.version>build212-hudson-6</trilead-ssh2.version>




[GLASSFISH-21173] Glassfish / Jersey throws NPE on startup for versioned applications Created: 25/Aug/14  Updated: 23/Oct/14

Status: Open
Project: glassfish
Component/s: jax-rs
Affects Version/s: 4.1
Fix Version/s: None

Type: Bug Priority: Critical
Reporter: lprimak Assignee: Marek Potociar
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: 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


Tags: jersey

 Description   

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

The failure only happens when versioned, i.e. 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

Application versioning is as described here:
https://weblogs.java.net/blog/serli/archive/2010/08/30/how-use-glassfish-application-versioning?force=354

Related issues:
https://java.net/jira/browse/GLASSFISH-21171
https://java.net/jira/browse/JERSEY-2626

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 [ 26/Aug/14 ]

Looks like the code points to this:

final Object interceptor = new EjbComponentInterceptor(locator);
165 initialContext = getInitialContext();
166 final EjbContainerUtil ejbUtil = EjbContainerUtilImpl.getInstance();
167 final ApplicationInfo appInfo = ejbUtil.getDeployment().get((String)initialContext.lookup("java:app/AppName"));
168 final List<String> tempLibNames = new LinkedList<String>();
169 for (ModuleInfo moduleInfo : appInfo.getModuleInfos()) {
170 final String jarName = moduleInfo.getName();
171 if (jarName.endsWith(".jar")) {
172 final String moduleName = jarName.substring(0, jarName.length() - 4

Comment by lprimak [ 26/Aug/14 ]

Line 169, appInfo is null for versioned application.
Perhaps there needs to be a split / ignore everything from the colon,
i.e. when my_app:20140825, appName should be trimmed to just my_app

Comment by Hong Zhang [ 26/Aug/14 ]

Assign to jersey team to take a look

Comment by lprimak [ 26/Aug/14 ]

This issue is now "unassigned"
Hong,
Can you please assign it to Jersey (or appropriate) team?
It maybe Glassfish core, not Jersdy because
it's EJB Jersey deployer that's failing.

The failed bean is annotated @Stateless @Path("xxx")
thus both a stateless bean and a JAX-RS bean.

Thank you

Comment by lprimak [ 26/Aug/14 ]

I think this issue is a showstopper for GF 4.1 and needs to be fixed in this release.

Comment by Marek Potociar [ 27/Aug/14 ]

The exception is thrown on this code line and is related to line 167, where ApplicationInfo for the application is retrieved.

As noted in an earlier comment, the application does not seem to have an expected loader ApplicationInfo record in the application registry for the versioned applications, at least not under the versioned application name available in the JNDI tree under "java:app/AppName" binding key. It seems to me like a deployment issue - reassigning to deployment component for evaluation. From Jersey perspective, the primary questions to answer in the evaluation are following:

  1. Is Jersey code properly retrieving ApplicationInfo record?
  2. If not, what is the proper, bullet-proof way to retrieve the ApplicationInfo record?
Comment by lprimak [ 07/Sep/14 ]

Perhaps this should be assigned to Marina V so she could clarify how to make this part work correctly?
Thank you

Comment by lprimak [ 13/Sep/14 ]

Now I see it's too late for GF 4.1, can someone take a look so I can at least get a patch / nightly build or something?
Thank you

Comment by lprimak [ 14/Sep/14 ]

I have created a patch to Jersey 2.10.4 that fixes this problem
------------------

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))
    Unknown macro: {+ 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 [ 05/Oct/14 ]

Any updates on this issue?
Thanks

Comment by Hong Zhang [ 07/Oct/14 ]

Sorry, was not able to get to this due to other higher priority work. I will reassign to Marek to ask him to review the jersey patch to see what he thinks.

Comment by lprimak [ 07/Oct/14 ]

Thanks, Hong. Understand and appreciate it.

Comment by lprimak [ 23/Oct/14 ]

Any progress on this issue?
Thanks





[GLASSFISH-21030] CDI failures with 4.0.1-b05-SNAPSHOT Created: 03/Apr/14  Updated: 04/Jun/14  Resolved: 04/Jun/14

Status: Resolved
Project: glassfish
Component/s: jax-rs
Affects Version/s: None
Fix Version/s: 4.1_b06

Type: Bug Priority: Major
Reporter: Romain Grécourt Assignee: Romain Grécourt
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Dependency
depends on JERSEY-2461 Jersey CDI extension causes CDI deplo... Resolved
Tags: 4_0_1-mustfix, cdi, glassfish, jersey

 Description   

Here is what the error looks like:

org.glassfish.deployment.common.DeploymentException: CDI deployment failure:WELD-001409 Ambiguous dependencies for type [Logger] with qualifiers [@Default] at injection point [[BackedAnnotatedField] @Inject private transient TestServlet.log]. Possible dependencies:
 - org.glassfish.jersey.gf.cdi.internal.CdiComponentProvider$Hk2Bean@2cb100f,
 - Producer Method [Logger] with qualifiers [@Any @Default] declared as [[BackedAnnotatedMethod] @Produces public TestLoggerProducer.getLogger()]

We are investigating a workaround to use before the next jersey integration. (basically bundle org.glassfish.jersey.containers.glassfish:jersey-gf-cdi-ban-custom-hk2-binding:2.7).



 Comments   
Comment by Romain Grécourt [ 04/Jun/14 ]

fixed with jersey >= 2.7





[GLASSFISH-20794] GF4: Non-working injection of JAX-RS resoures into CDI interceptors Created: 04/Sep/13  Updated: 04/Apr/14

Status: Open
Project: glassfish
Component/s: jax-rs
Affects Version/s: 4.0_b89_RC5
Fix Version/s: None

Type: Bug Priority: Major
Reporter: replicant77 Assignee: Jakub Podlesak
Resolution: Unresolved Votes: 4
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Win 7 Pro 64Bit
GlassFish Server Open Source Edition 4.0 (build 89)
jdk1.7.0_21


Attachments: Zip Archive GLASSFISH-20794.zip    
Tags: cdi, glassfish4, interceptor, jax-rs, jersey

 Description   

We are currently evaluating glassfish 4 for migration of our enterprise projects from glassfish 3.1.2.2. We are making heavy use of interceptors for our jax-rs based rest services. In glassfish 3.1.2 injection of jax-rs based resources (e.g. @Context private HttpHeaders headers) into those interceptors worked fine. But with GF4 this doesn't work anymore.
Ways to reproduce:


@RequestScoped
@Path("test")
@Test
public class TestService {
@GET
@Produces(MediaType.TEXT_PLAIN)
public String greet()

{ return "Hello World"; }

}

@Test
@Interceptor
public class TestInterceptor {
@Context
private HttpHeaders headers;

@AroundInvoke
public Object intercept(InvocationContext ic) throws Exception

{ System.out.println("httpHeaders: " + headers); return ic.proceed(); }

}

@Inherited
@InterceptorBinding
@Target(

{ ElementType.METHOD, ElementType.TYPE }

)
@Retention(RetentionPolicy.RUNTIME)
public @interface Test {
}

beans.xml:
<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://java.sun.com/xml/ns/javaee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/javaee
http://java.sun.com/xml/ns/javaee/beans_1_0.xsd">
<interceptors>
<class>TestInterceptor</class>
</interceptors>
</beans>

On GF3.1.2 the output is something like:
INFO: httpHeaders: com.sun.jersey.spi.container.ContainerRequest@4e7cb67f

On GF4:
INFO: httpHeaders: null



 Comments   
Comment by obfischer [ 05/Sep/13 ]

Did you try to update to CDI 1.1? I also had CDI related issues when migrating my application to GF 4. It was needed to to update all beans.xml to CDI 1.1. At the end I ended with updating to GF 4.0.1-SNAPSHOT.

Comment by replicant77 [ 05/Sep/13 ]

I followed your advice and updated the beans.xml in the example (see below). But the problem stays the same: HttpHeaders stays null.


<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://xmlns.jcp.org/xml/ns/javaee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee http://xmlns.jcp.org/xml/ns/javaee/beans_1_1.xsd"
version="1.1" bean-discovery-mode="all">
<interceptors>
<class>TestInterceptor</class>
</interceptors>
</beans>

Comment by replicant77 [ 05/Sep/13 ]

Note: i was still using 4.0_b89_RC5 for the updated beans.xml

Comment by TangYong [ 10/Sep/13 ]

I made an attachment based on the issue's description, and the issue can be re-produced using 4.0.1-b02.

[Steps]
1 mvn install
2 asadmin deploy ...
3 accessing "http://localhost:8080/glassfish-20794/webapi/test/"

You can see the following in server.log,
...
[2013-09-10T16:16:04.140+0900] [glassfish 4.0] [INFO] [] [javax.enterprise.system.tools.deployment.common] [tid: _ThreadID=54 _ThreadName=admin-listener(4)] [timeMillis: 1378797364140] [levelValue: 800] [[
visiting unvisited references]]

[2013-09-10T16:16:04.140+0900] [glassfish 4.0] [INFO] [] [javax.enterprise.system.tools.deployment.common] [tid: _ThreadID=54 _ThreadName=admin-listener(4)] [timeMillis: 1378797364140] [levelValue: 800] [[
visiting unvisited references]]

[2013-09-10T16:16:04.155+0900] [glassfish 4.0] [INFO] [] [javax.enterprise.system.tools.deployment.common] [tid: _ThreadID=54 _ThreadName=admin-listener(4)] [timeMillis: 1378797364155] [levelValue: 800] [[
visiting unvisited references]]

[2013-09-10T16:16:04.718+0900] [glassfish 4.0] [INFO] [] [org.glassfish.jersey.servlet.init.JerseyServletContainerInitializer] [tid: _ThreadID=54 _ThreadName=admin-listener(4)] [timeMillis: 1378797364718] [levelValue: 800] [[
Registering the Jersey servlet application, named javax.ws.rs.core.Application, with the following root resource and provider classes: [class TestService]]]

[2013-09-10T16:16:04.968+0900] [glassfish 4.0] [INFO] [] [org.glassfish.jersey.server.ApplicationHandler] [tid: _ThreadID=54 _ThreadName=admin-listener(4)] [timeMillis: 1378797364968] [levelValue: 800] [[
Initiating Jersey application, version Jersey: 2.2 2013-08-14 08:51:58...]]

[2013-09-10T16:16:05.140+0900] [glassfish 4.0] [INFO] [AS-WEB-GLUE-00172] [javax.enterprise.web] [tid: _ThreadID=54 _ThreadName=admin-listener(4)] [timeMillis: 1378797365140] [levelValue: 800] [[
Loading application [glassfish-20794] at [/glassfish-20794]]]

[2013-09-10T16:16:05.155+0900] [glassfish 4.0] [INFO] [] [javax.enterprise.system.core] [tid: _ThreadID=54 _ThreadName=admin-listener(4)] [timeMillis: 1378797365155] [levelValue: 800] [[
glassfish-20794 was successfully deployed in 1,203 milliseconds.]]

[2013-09-10T16:16:26.749+0900] [glassfish 4.0] [INFO] [] [] [tid: _ThreadID=29 _ThreadName=Thread-7] [timeMillis: 1378797386749] [levelValue: 800] [[
httpHeaders: null]]
...

So,

1) pl. JJ firstly evaluates whether being a bug from CDI?
2) if not, forwarding to jax-rs comp to evaluate deeply.

Thanks
Tang

Comment by jjsnyder83 [ 10/Sep/13 ]

@Context is not an annotation processed by Weld nor the GF CDI integration. I looked at the call stack for when the interceptor is created and it is created by
org.jboss.weld.bean.ManagedBean#create

This create method calls the following code

T instance = getProducer().produce(creationalContext);

to create the interceptor and then

getProducer().inject(instance, creationalContext);

to do the injection. For this the getProducer() returns an instance of

org.glassfish.jersey.gf.cdi.CdiComponentProvider

I would expect this class to handle the injection of non-CDI annotations. I do not have this source code handy so I can't verify.

I think the Jersey folks should take a look and see if they're handling the @Context annotation correctly.

Comment by TangYong [ 10/Sep/13 ]

Thanks JJ's confirmation and forwards to JAX-RS Comp to evaluate deeply.

Comment by tcke83 [ 04/Apr/14 ]

Is there an easy work around to get the context? I have the same issue.





[GLASSFISH-20789] Failed to create cluster with jms option Created: 02/Sep/13  Updated: 19/Sep/14  Resolved: 09/Sep/13

Status: Resolved
Project: glassfish
Component/s: admin_gui
Affects Version/s: 4.1
Fix Version/s: 4.1

Type: Bug Priority: Major
Reporter: Jeremy_Lv Assignee: Anissa Lam
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

All


Attachments: PNG File error.png     Text File revision.patch    
Tags: 40-regression, admin-gui, jersey

 Description   

When I tried to create a cluster as the picture I have attached shows, It is failed because of the "java.lang.ClassCastException:".

Here's some of the failure exception in the server.log:
[2013-08-30T17:37:28.473+0800] [glassfish 4.0] [SEVERE] [] [org.glassfish.admingui] [tid: _ThreadID=47 _ThreadName=admin-listener(4)] [timeMillis: 1377855448473] [levelValue: 1000] [[
java.lang.Boolean cannot be cast to java.lang.String;
java.lang.ClassCastException: java.lang.Boolean cannot be cast to java.lang.String;
restRequest: endpoint=http://localhost:4848/management/domain/clusters/cluster/cluster1/configure-jms-cluster
attrs=

{availabilityEnabled=false, clustertype=conventional, messageStoreType=file, configStoreType=masterbroker, property=prop1=value1:prop2=value2\:with\:colons:prop3=value3}

method=post]]

BTW: I have also confirmed that the cluster with jms option can be created in the glassfish v3.1.2, but it is failed in the glassfish v4. So I regarded it as a rollback issue in the glassfish v4.



 Comments   
Comment by Jeremy_Lv [ 02/Sep/13 ]

Hi, Anissa:
After a few investigation about the glassfish, I found it is cause by the following code:

AbstractFormProvider.java
    public <M extends MultivaluedMap<String, String>> void writeTo(
            M t,
            MediaType mediaType,
            OutputStream entityStream) throws IOException {
        final String charsetName = ReaderWriter.getCharset(mediaType).name();

        final StringBuilder sb = new StringBuilder();
        for (Map.Entry<String, List<String>> e : t.entrySet()) {    
         ★  for (String value : e.getValue()) {  ★
                if (sb.length() > 0) {
                    sb.append('&');
                }
                sb.append(URLEncoder.encode(e.getKey(), charsetName));
                if (value != null) {
                    sb.append('=');
                    sb.append(URLEncoder.encode(value, charsetName));
                }
            }
        }

It is because some of the value's type in the Map.Entry is boolean, however, it is because the boolean can't be cast to the String here so that it is failed to create the cluster with jms options.

Thanks
Jeremy Lv

Comment by Jeremy_Lv [ 02/Sep/13 ]

I also confirmed the early version of jersey does't have the AbstractFormProvider.java, it seems the AbstractFormProvider.java has imported when it comes to the glassfish v4

Comment by Jeremy_Lv [ 03/Sep/13 ]

Hi, Anissa:

I have confirmed this issue is caused by the upgrade of the jersey. After I have ignore the value of availabilityEnabled the cluster with jms options can be created successfully.

I have also confirmed the value of availabilityEnabled can't be added to the formData when create cluster with jms options in glassfish v3. So IMHO, I have revised the source as follows:

RestUtil.java
Index: src/main/java/org/glassfish/admingui/common/util/RestUtil.java
===================================================================
--- src/main/java/org/glassfish/admingui/common/util/RestUtil.java	(revision 62446)
+++ src/main/java/org/glassfish/admingui/common/util/RestUtil.java	(working copy)
@@ -554,6 +554,9 @@
             } else {
                 //formData.putSingle(key, (value != null) ? value.toString() : value);
                 try {
+                    //ignore the value of availabilityEnabled as it is useless
+                    if (key.equals("availabilityEnabled"))
+                        continue;
                     formData.putSingle(key, value);
                 } catch (ClassCastException ex) {
                     Logger logger = GuiUtil.getLogger();

In the glassfish v3, the sentence of formData.putSingle(key, value); will only storage the value which type is String, So it will regardless the value of availabilityEnabled as the type is boolean. However, when it comes to the glassfish v4, as the jersey side code upgrade, the sentence of formData.putSingle(key, value); will storage the every type of value including the boolean type, but the element of availabilityEnabled is useless when it comes to create the cluster with jms options. After all, I just do some changes to exclude the element of availabilityEnabled and the cluster with jms options can be created successfully.

Could you help me to confirm about my changes? I have also attached my patch in the JIRA.

Thanks
Jeremy Lv

Comment by Jeremy_Lv [ 03/Sep/13 ]

I have also ran the QL tests after I have applied the changes and all of the tests have passed, please review my changes whether it is fine for me to check in?

Thanks a lot!

Comment by Anissa Lam [ 04/Sep/13 ]

Thanks for suggesting the fix.
I need to take a closer look about this availabilityEnabled option in creating the cluster.
Will get back to you in a day or 2.

Comment by Anissa Lam [ 05/Sep/13 ]

I have looked at the patch. This issue need to be solved in another way.
buildMultivalueMap() is called everytime before doing a POST. Making changes in this has to be very careful as it may affect other commands, it is a very high risk change.
In fact, deploying an application will also go through this method. Thus if the availabilityEnabled option is selected when deploying the application to a cluster or other standalone instance, this option will be 'removed' by the new change, and thus the application will NOT be deployed correctly as the user request.
Need to figure out another more localized changes to fix this issue.

thanks for the suggestion though.

Comment by Jeremy_Lv [ 06/Sep/13 ]

Hi, Anissa:

Thanks for confirmation, I have a question about this issue:
1). what the option of availabilityEnabled used for when create the cluster with jms options, if the option is useless(As I can't find out anywhere to use this options here), how about delete availabilityEnabled related setting in the jmsHandlers.inc like this:

jmsHandlers.inc
Index: jmsHandlers.inc
===================================================================
--- jmsHandlers.inc	(revision 61862)
+++ jmsHandlers.inc	(working copy)
@@ -45,11 +45,9 @@
     //println("***** #{pageSession}\n\n\n\n\n\n");
     mapPut(map="#{requestScope.jmsAttrs}" key="clustertype" value="$pageSession{clusterType}");
     mapPut(map="#{requestScope.jmsAttrs}" key="property" value="$pageSession{properties}");
-    mapPut(map="#{requestScope.jmsAttrs}" key="availabilityEnabled" value="#{true}");
     if ('$pageSession{clusterType}=conventional') {
         mapPut(map="#{requestScope.jmsAttrs}" key="configStoreType" value="$pageSession{configStoreType}");
         mapPut(map="#{requestScope.jmsAttrs}" key="messageStoreType" value="$pageSession{messageStoreType}");
-        mapPut(map="#{requestScope.jmsAttrs}" key="availabilityEnabled" value="#{false}");
     }
 
     // Save JMS integration type

However, I have also tried to convert the availabilityEnabled's value from boolean to String, However, it will throw out the exception that the availabilityEnabled is an invalid option:

2013-09-06T10:14:50.640+0800] [glassfish 4.0] [SEVERE] [NCLS-CORE-00003] [javax.enterprise.system.core] [tid: _ThreadID=45 _ThreadName=admin-listener(3)] [timeMillis: 1378433690640] [levelValue: 1000] [[
  Exception while running a command
MultiException stack 1 of 1
java.lang.IllegalArgumentException:  Invalid option: availabilityEnabled
	at com.sun.enterprise.v3.admin.CommandRunnerImpl.validateParameters(CommandRunnerImpl.java:1026)
	at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1192)
	at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1300(CommandRunnerImpl.java:109)
	at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1846)
	at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1722)
	at org.glassfish.admin.rest.utils.ResourceUtil.runCommand(ResourceUtil.java:253)
	at org.glassfish.admin.rest.utils.ResourceUtil.runCommand(ResourceUtil.java:231)
	at org.glassfish.admin.rest.resources.TemplateExecCommand.executeCommandLegacyFormat(TemplateExecCommand.java:157)
	at org.glassfish.admin.rest.resources.TemplateCommandPostResource.processPostLegacyFormat(TemplateCommandPostResource.java:97)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:601)
	at org.glassfish.jersey.server.model.internal.ResourceMethodInvocationHandlerFactory$1.invoke(ResourceMethodInvocationHandlerFactory.java:81)
	at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher$1.run(AbstractJavaResourceMethodDispatcher.java:140)
	at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.invoke(AbstractJavaResourceMethodDispatcher.java:158)
	at org.glassfish.jersey.server.model.internal.JavaResourceMethodDispatcherProvider$ResponseOutInvoker.doDispatch(JavaResourceMethodDispatcherProvider.java:152)
	at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.dispatch(AbstractJavaResourceMethodDispatcher.java:101)
	at org.glassfish.jersey.server.model.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:353)
	at org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:343)
	at org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:102)
	at org.glassfish.jersey.server.ServerRuntime$1.run(ServerRuntime.java:237)
	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:318)
	at org.glassfish.jersey.server.ServerRuntime.process(ServerRuntime.java:211)
	at org.glassfish.jersey.server.ApplicationHandler.handle(ApplicationHandler.java:982)
	at org.glassfish.jersey.grizzly2.httpserver.GrizzlyHttpContainer.service(GrizzlyHttpContainer.java:330)
	at org.glassfish.admin.rest.adapter.RestAdapter$2.service(RestAdapter.java:316)
	at org.glassfish.admin.rest.adapter.RestAdapter.service(RestAdapter.java:179)
	at com.sun.enterprise.v3.services.impl.ContainerMapper$HttpHandlerCallable.call(ContainerMapper.java:496)
	at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:175)
	at org.glassfish.grizzly.http.server.HttpHandler.runService(HttpHandler.java:191)
	at org.glassfish.grizzly.http.server.HttpHandler.doHandle(HttpHandler.java:168)
	at org.glassfish.grizzly.http.server.HttpServerFilter.handleRead(HttpServerFilter.java:187)
	at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119)
	at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:288)
	at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:206)
	at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:136)
	at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:114)
	at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77)
	at org.glassfish.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(TCPNIOTransport.java:837)
	at org.glassfish.grizzly.strategies.AbstractIOStrategy.fireIOEvent(AbstractIOStrategy.java:113)
	at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.run0(WorkerThreadIOStrategy.java:115)
	at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.access$100(WorkerThreadIOStrategy.java:55)
	at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy$WorkerThreadRunnable.run(WorkerThreadIOStrategy.java:135)
	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:722)
]]

[2013-09-06T10:14:50.666+0800] [glassfish 4.0] [SEVERE] [] [org.glassfish.admingui] [tid: _ThreadID=124 _ThreadName=admin-listener(6)] [timeMillis: 1378433690666] [levelValue: 1000] [[
  RestResponse.getResponse() gives FAILURE.  endpoint = 'http://localhost:4848/management/domain/clusters/cluster/c1/configure-jms-cluster'; attrs = '{availabilityEnabled=false, clustertype=conventional, messageStoreType=file, configStoreType=masterbroker, property=null}']]
Comment by Jeremy_Lv [ 06/Sep/13 ]

After checking about the jms side code, I have found the jms command doesn't support the option of availabilityEnabled, You can check about the ConfigureJMSCluster.java and you will found there's no defination about the option of availabilityEnabled.

Comment by Jeremy_Lv [ 06/Sep/13 ]

If we want the command support the option of availabilityEnabled, I think the changes would be like follows:

Index: admingui/common/src/main/java/org/glassfish/admingui/common/handlers/RestApiHandlers.java
===================================================================
--- admingui/common/src/main/java/org/glassfish/admingui/common/handlers/RestApiHandlers.java	(revision 62681)
+++ admingui/common/src/main/java/org/glassfish/admingui/common/handlers/RestApiHandlers.java	(working copy)
@@ -212,6 +212,10 @@
                     @HandlerOutput(name="result", type=Map.class)})
     public static void restRequest(HandlerContext handlerCtx) {
         Map<String, Object> attrs = (Map<String, Object>) handlerCtx.getInputValue("attrs");
+        if (attrs != null && attrs.containsKey(("availabilityEnabled"))){
+            String value = String.valueOf(attrs.get("availabilityEnabled"));
+            attrs.put("availabilityEnabled", value);
+        }
         String endpoint = (String) handlerCtx.getInputValue("endpoint");
         String method = (String) handlerCtx.getInputValue("method");
         boolean quiet = (Boolean) handlerCtx.getInputValue("quiet");
Index: jms/admin/src/main/java/org/glassfish/jms/admin/cli/ConfigureJMSCluster.java
===================================================================
--- jms/admin/src/main/java/org/glassfish/jms/admin/cli/ConfigureJMSCluster.java	(revision 62681)
+++ jms/admin/src/main/java/org/glassfish/jms/admin/cli/ConfigureJMSCluster.java	(working copy)
@@ -116,6 +116,9 @@
     @Param(name="configstoretype", optional=true, alias="cs")
     String configStoreType;
 
+    @Param(name="availabilityEnabled", optional=true, alias="ae")
+    String availabilityEnabled;
+
     @Param(name="messagestoretype", optional=true, alias="ms")
     String messageStoreType;

However, if we change like this, the option of availabilityEnabled will be avaiable when type as "configure-jms-cluster", As I can't find out any use of the availabilityEnabled option, I suggest to delete availabilityEnabled related setting in the jmsHandlers.inc.

Thanks
Jeremy Lv

Comment by Anissa Lam [ 06/Sep/13 ]

Let me check with the jms team about this availabilityEnabled option and get back to you.

Comment by Ed Bratt [ 06/Sep/13 ]

Clusters aren't fully tested in this GlassFish release as our focus was to deliver the content necessary for the Java EE RI. No doubt there will be issues (this appears to be one).
You may already know this, but you can manually configure a JMS cluster with ASAdmin commands. Here is an outline of the steps:
1. asadmin start-domain
2. asadmin create-cluster <cluster-name>
3. set jms-service type if necessary, e.g.
asadmin set <cluster-name>.jms-service.type=LOCAL
4. run configure-jms-cluster, e.g setup for enhanced cluster (where <gf-passfile> contains db password setting AS_ADMIN_JMSDBPASSWORD=<db-password>)
asadmin --passwordfile <gf-passfile> configure-jms-cluster --clustertype=enhanced --dbvendor=<vendor> --dbuser=<db-user-name> --dburl=<db-url> <cluster-name>
5. create instances, e.g. to creat a local instance
asadmin create-local-instance --cluster <cluster-name> <instance-name>
6. create any JMS resources
7. asadmin start-cluster

If you want to use high-availability DB for GlassFish MQ, e.g. --clustertype=enhanced copy the JDBC driver to
<glassfish-install-root>/glassfish4/mq/lib/ext/ before step 1 above.
(We tried this and it appears to work.)

Comment by Jeremy_Lv [ 07/Sep/13 ]

Hi, Ed Bratt:

I have tried about this too and it seems to work without availabilityEnabled options in the admin command. So is it no need to add the availabilityEnabled options in the command side?

Comment by Jeremy_Lv [ 09/Sep/13 ]

I have checked in the changes as the version 62705 to delete the availabilityEnabled options in the admin console.

Comment by amyk [ 09/Sep/13 ]

To clarify, 'availabilityEnabled' is not an option for 'asadmin configure-jms-cluster'

GlassFish 3.1.2

asadmin configure-jms-cluster --help
SYNOPSIS
configure-jms-cluster [--help]
[--clustertype=

{conventional|enhanced}]
[--configstoretype={masterbroker|shareddb}]
[--messagestoretype={file|jdbc}]
[--dbvendor database-vendor]
[--dbuser database-user]
[--dburl database-url]
[--property property-list]
cluster-name

GlassFish 4.0

asadmin configure-jms-cluster --help
SYNOPSIS
configure-jms-cluster [--help]
[--clustertype={conventional|enhanced}

]
[--configstoretype=

{masterbroker|shareddb}

]
[--messagestoretype=

{file|jdbc}

]
[--dbvendor database-vendor]
[--dbuser database-user]
[--dburl database-url]
[--property (name=value)[:name=value]*]
cluster-name

Comment by Jeremy_Lv [ 09/Sep/13 ]

Hi, Amyk:

Thanks for your clarification!

Comment by amyk [ 10/Sep/13 ]

From David Zhao:

The 'availabilityEnabled' was removed (no longer needed) for configuring JMS cluster, by the following revision for a long time:

Revision: 42142
Time: 10/26/2010 02:46 PM
Author: sats
Path: v3/jms/admin/src/main/java/org/glassfish/jms/admin/cli/ConfigureJMSCluster.java (trunk)
Message: changes to the configure-jms-cluster command as per ASARCH and MQ team suggestions

Comment by Jeremy_Lv [ 10/Sep/13 ]

amyk:

Your comments added here help me a lot! Thanks again!





[GLASSFISH-20576] Internal Server Error on JSON REST web service returning array Created: 23/May/13  Updated: 19/Sep/14

Status: In Progress
Project: glassfish
Component/s: jax-rs
Affects Version/s: 4.0_b89_RC5
Fix Version/s: 4.1

Type: Bug Priority: Major
Reporter: Peter Salomonsen Assignee: Michal Gajdos
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

glassfish-4.0-b90-05_22_2013, jdk1.7


Tags: glassfish4, jersey, json, rest

 Description   

The following REST web service causes internal server error (and no stack trace in server.log). Returning an empty array works, but as soon as there are elements in the array - it does not.

@GET
@Produces("application/json")
public Object[] getArray() {
return new Object[]

{"Test"}

;
}



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

Targeting for GF 4.0.1, Re-assigning to dev eng. for evaluation.

Comment by Michal Gajdos [ 11/Jun/13 ]

Which Json provider from Jersey are you using? Have you configured one? Thanks.

Comment by Peter Salomonsen [ 11/Jun/13 ]

I haven't configured anything - no web.xml at all. Just application config class like this:

@javax.ws.rs.ApplicationPath("webresources")
public class ApplicationConfig extends Application {

}

And the REST service class:

@Path("generic")
public class GenericResource {

@Context
private UriInfo context;

public GenericResource() {
}

@GET
@Produces("application/json")
public Object[] getArray() {
return new Object[]

{"Test"}

;
}
}

That's all.

Comment by Michal Gajdos [ 13/Jun/13 ]

The easiest way would be registering JacksonFeature (make sure you have jersey-media-json-jackson on your classpath) in your ApplicationConfig. Something like:

public Set<Class<?>> getClasses() {
    return new HashSet<Class<?>>() {{ add(GenericResource.class); add(JacksonFeature.class); }};
}
Comment by Peter Salomonsen [ 13/Jun/13 ]

org.glassfish.jersey.jackson.JacksonFeature works as you propose. MoxyJsonFeature gives the server error, and JettisonFeature says it cannot find a MessageBodyWriter. Is MoxyJsonFeature the default? Shouldn't this also be able to handle arrays?





[GLASSFISH-20534] @Inject not working within JAX-RS @Provider Created: 15/May/13  Updated: 19/Sep/14  Resolved: 14/Aug/13

Status: Resolved
Project: glassfish
Component/s: embedded
Affects Version/s: 4.0
Fix Version/s: 4.1

Type: Bug Priority: Major
Reporter: buddypine Assignee: Marek Potociar
Resolution: Invalid Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Glassfish embedded 4.0


Tags: embedded, glassfish4, jax-rs, jersey

 Description   

Using https://maven.java.net/content/groups/promoted/org/glassfish/main/extras/glassfish-embedded-all/4.0/
Injection of stateless EJB into JAX-RS @Provider fails, same EJB injected into regular servlet works fine within the same app.

@Stateless
public class AuthService {}

@Provider
public class HmacAuthFilter implements ContainerRequestFilter, ContainerResponseFilter {
@Inject
private AuthService authService;
...
}

monospaced
MultiException stack 1 of 3
org.glassfish.hk2.api.UnsatisfiedDependencyException: There was no object available for injection at Injectee(requiredType=AuthService,parent=HmacAuthFilter,qualifiers={}),position=-1,optional=false,self=false,unqualified=null,1462515663)
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.Providers.getAllRankedProviders(Providers.java:234)
at org.glassfish.jersey.server.ApplicationHandler.getProcessingProviders(ApplicationHandler.java:568)
at org.glassfish.jersey.server.ApplicationHandler.initialize(ApplicationHandler.java:393)
at org.glassfish.jersey.server.ApplicationHandler.access$500(ApplicationHandler.java:157)
at org.glassfish.jersey.server.ApplicationHandler$3.run(ApplicationHandler.java:280)
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:277)
at org.glassfish.jersey.servlet.WebComponent.<init>(WebComponent.java:262)
at org.glassfish.jersey.servlet.ServletContainer.init(ServletContainer.java:167)
at org.glassfish.jersey.servlet.ServletContainer.init(ServletContainer.java:349)
at javax.servlet.GenericServlet.init(GenericServlet.java:244)
at org.apache.catalina.core.StandardWrapper.initServlet(StandardWrapper.java:1583)
at org.apache.catalina.core.StandardWrapper.allocate(StandardWrapper.java:1225)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:237)
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:357)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:260)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:246)
at org.glassfish.grizzly.http.server.HttpHandler.runService(HttpHandler.java:191)
at org.glassfish.grizzly.http.server.HttpHandler.doHandle(HttpHandler.java:168)
at org.glassfish.grizzly.http.server.HttpServerFilter.handleRead(HttpServerFilter.java:189)
at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:288)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:206)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:136)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:114)
at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77)
at org.glassfish.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(TCPNIOTransport.java:838)
at org.glassfish.grizzly.strategies.AbstractIOStrategy.fireIOEvent(AbstractIOStrategy.java:113)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.run0(WorkerThreadIOStrategy.java:115)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.access$100(WorkerThreadIOStrategy.java:55)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy$WorkerThreadRunnable.run(WorkerThreadIOStrategy.java:135)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:564)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:544)
at java.lang.Thread.run(Thread.java:722)
MultiException stack 2 of 3
java.lang.IllegalArgumentException: While attempting to resolve the dependencies of io.scrub.http.HmacAuthFilter errors were found
at org.jvnet.hk2.internal.ClazzCreator.resolveAllDependencies(ClazzCreator.java:226)
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.Providers.getAllRankedProviders(Providers.java:234)
at org.glassfish.jersey.server.ApplicationHandler.getProcessingProviders(ApplicationHandler.java:568)
at org.glassfish.jersey.server.ApplicationHandler.initialize(ApplicationHandler.java:393)
at org.glassfish.jersey.server.ApplicationHandler.access$500(ApplicationHandler.java:157)
at org.glassfish.jersey.server.ApplicationHandler$3.run(ApplicationHandler.java:280)
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:277)
at org.glassfish.jersey.servlet.WebComponent.<init>(WebComponent.java:262)
at org.glassfish.jersey.servlet.ServletContainer.init(ServletContainer.java:167)
at org.glassfish.jersey.servlet.ServletContainer.init(ServletContainer.java:349)
at javax.servlet.GenericServlet.init(GenericServlet.java:244)
at org.apache.catalina.core.StandardWrapper.initServlet(StandardWrapper.java:1583)
at org.apache.catalina.core.StandardWrapper.allocate(StandardWrapper.java:1225)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:237)
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:357)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:260)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:246)
at org.glassfish.grizzly.http.server.HttpHandler.runService(HttpHandler.java:191)
at org.glassfish.grizzly.http.server.HttpHandler.doHandle(HttpHandler.java:168)
at org.glassfish.grizzly.http.server.HttpServerFilter.handleRead(HttpServerFilter.java:189)
at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:288)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:206)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:136)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:114)
at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77)
at org.glassfish.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(TCPNIOTransport.java:838)
at org.glassfish.grizzly.strategies.AbstractIOStrategy.fireIOEvent(AbstractIOStrategy.java:113)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.run0(WorkerThreadIOStrategy.java:115)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.access$100(WorkerThreadIOStrategy.java:55)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy$WorkerThreadRunnable.run(WorkerThreadIOStrategy.java:135)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:564)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:544)
at java.lang.Thread.run(Thread.java:722)
MultiException stack 3 of 3
java.lang.IllegalStateException: Unable to perform operation: resolve on io.scrub.http.HmacAuthFilter
at org.jvnet.hk2.internal.ClazzCreator.create(ClazzCreator.java:340)
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.Providers.getAllRankedProviders(Providers.java:234)
at org.glassfish.jersey.server.ApplicationHandler.getProcessingProviders(ApplicationHandler.java:568)
at org.glassfish.jersey.server.ApplicationHandler.initialize(ApplicationHandler.java:393)
at org.glassfish.jersey.server.ApplicationHandler.access$500(ApplicationHandler.java:157)
at org.glassfish.jersey.server.ApplicationHandler$3.run(ApplicationHandler.java:280)
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:277)
at org.glassfish.jersey.servlet.WebComponent.<init>(WebComponent.java:262)
at org.glassfish.jersey.servlet.ServletContainer.init(ServletContainer.java:167)
at org.glassfish.jersey.servlet.ServletContainer.init(ServletContainer.java:349)
at javax.servlet.GenericServlet.init(GenericServlet.java:244)
at org.apache.catalina.core.StandardWrapper.initServlet(StandardWrapper.java:1583)
at org.apache.catalina.core.StandardWrapper.allocate(StandardWrapper.java:1225)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:237)
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:357)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:260)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:246)
at org.glassfish.grizzly.http.server.HttpHandler.runService(HttpHandler.java:191)
at org.glassfish.grizzly.http.server.HttpHandler.doHandle(HttpHandler.java:168)
at org.glassfish.grizzly.http.server.HttpServerFilter.handleRead(HttpServerFilter.java:189)
at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:288)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:206)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:136)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:114)
at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77)
at org.glassfish.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(TCPNIOTransport.java:838)
at org.glassfish.grizzly.strategies.AbstractIOStrategy.fireIOEvent(AbstractIOStrategy.java:113)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.run0(WorkerThreadIOStrategy.java:115)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.access$100(WorkerThreadIOStrategy.java:55)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy$WorkerThreadRunnable.run(WorkerThreadIOStrategy.java:135)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:564)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:544)
at java.lang.Thread.run(Thread.java:722)
monospaced



 Comments   
Comment by Wasomumba [ 17/Jun/13 ]

This happens also in a "normal" (non-embedded) V4.0.1-b01 with @Singleton or @ApplicationScoped.

Comment by Marek Potociar [ 14/Aug/13 ]

JAX-RS 2.0 does not support injection of EJBs into JAX-RS components (providers, resources). As such, this is not a bug and I'm closing it as invalid. I have opened a RFE in Jersey to implement support for this instead: JERSEY-2040

At the moment, you can try to enable CDI and migrate your JAX-RS provider to a CDI-managed component. That way you may be able to get EJBs injected into the JAX-RS providers via CDI.





[GLASSFISH-19851] Nucleus admin dev tests do not do a proper cleanup. Created: 13/Mar/13  Updated: 13/Mar/13

Status: Open
Project: glassfish
Component/s: test
Affects Version/s: 4.0_b79
Fix Version/s: None

Type: Bug Priority: Critical
Reporter: Marek Potociar Assignee: Justin Lee
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: jersey, test-framework

 Description   

GF nucleus admin dev tests run before GF nucleus QL tests cause false negatives because GF nucleus admin dev tests do not clean-up GF test instance properly. This leads to observable false negatives behaviour on the same cleanly checked out sources, for example:

  1. run GF nucleus quick look - PASS
  2. run GF nucleus admin dev tests - PASS
  3. run GF nucleus quick look again - FAIL

Or:

  1. run GF nucleus admin dev tests - PASS
  2. run GF nucleus admin dev tests - FAIL

This issue complicates pre-integration testing required by Jersey and has cost us a lot of wasted effort on Jersey side.

From what we observed, a possible problem with admin dev tests AFAIK is that they leave a few GF instances running which may lead to port conflicts in the subsequently run test suites.






Generated at Wed Apr 01 11:34:29 UTC 2015 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.