[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-20576] Internal Server Error on JSON REST web service returning array Created: 23/May/13  Updated: 21/Dec/15

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

Type: Bug Priority: Major
Reporter: Peter Salomonsen Assignee: Marek Potociar
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-20655] 500 error in browser - nothing in server logs Created: 21/Jun/13  Updated: 21/Dec/15

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

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


 Description   

I have no idea whats wrong because there is no error message anywhere.

Try to run the attached project from the latest Netbeans with GF 4 and entering:
http://localhost:8080/PcRepairLocations/



 Comments   
Comment by walec51 [ 21/Jun/13 ]

Project: http://walczak.it/files/PcRepairLocations2.zip

Comment by walec51 [ 21/Jun/13 ]

In the browser I get:

HTTP Status 500 - Internal Server Error

type Status report

messageInternal Server Error

descriptionThe server encountered an internal error that prevented it from fulfilling this request.

GlassFish Server Open Source Edition 4.0

Comment by walec51 [ 21/Jun/13 ]

adding the produced annotation to:

@GET
    @Produces(MediaType.TEXT_HTML)
    public Viewable getIndex() {
        Map<String, Object> model = new HashMap<>();
        model.put("repairLocations", repairLocationRepository.getAll());
        return new Viewable("WEB-INF/index.jsp", model);
    }

stooped the strange 500 but still something should appear in the lost even without it

Comment by michael.y.chen [ 24/Jun/13 ]

please reassign if needed.

Comment by Shing Wai Chan [ 24/Jun/13 ]

The given application has JAX-RS, EJB and persistent. Assign to JAX-RS team for evaluation.





[GLASSFISH-21114] Failure to lookup EJB in ear/war Created: 01/Jul/14  Updated: 14/Apr/16

Status: Open
Project: glassfish
Component/s: web_services
Affects Version/s: 4.1_b05, 4.1_b06, 4.1_b07
Fix Version/s: None

Type: Bug Priority: Major
Reporter: dbcjbn Assignee: Marek Potociar
Resolution: Unresolved Votes: 18
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: 4_0_1-review, fishcat

 Description   

I have an ear which includes an EJB and a jax-rs WAR module, both listed in the application.xml file of the EAR.

The war contains jax-rs Application and resource bean classes, and the resource class injects stateless bean from the EJB module using @EJB annotation.

When I access the REST resource after deploy GlassFish is unable to locate the jax-rs resource bean, which lives inside the WAR. It looks like GlassFish assumes it is to be found in the EJB module (see Stacktrace below).

I have a small example application exhibiting this problem, that I will gladly upload if possible.

The problem does not appear to be in GlassFish versions 4.0 up to and including 4.0.1 b04.

We have done testing on both Java 7 and 8.

[2014-07-01T12:06:22.179+0200] [glassfish 4.0] [WARNING] [] [org.glassfish.jersey.gf.ejb.internal.EjbComponentProvider] [tid: _ThreadID=123 _ThreadName=http-listener-1(1)] [timeMillis: 1404209182179] [levelValue: 900] [[
An instance of EJB class, dk.dbc.gf.ejb.HelloWorldBean, could not be looked up using simple form name. Attempting to look up using the fully-qualified form name.
javax.naming.NamingException: Lookup failed for 'java:app/gf-4.0.1-fail-ejb-1.0-SNAPSHOT/HelloWorldBean' in SerialContext[myEnv=

{java.naming.factory.initial=com.sun.enterprise.naming.impl.SerialInitContextFactory, java.naming.factory.state=com.sun.corba.ee.impl.presentation.rmi.JNDIStateFactoryImpl, java.naming.factory.url.pkgs=com.sun.enterprise.naming}

[Root exception is javax.naming.NameNotFoundException: No object bound to name java:app/gf-4.0.1-fail-ejb-1.0-SNAPSHOT/HelloWorldBean]
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:491)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:438)
at javax.naming.InitialContext.lookup(InitialContext.java:417)
at javax.naming.InitialContext.lookup(InitialContext.java:417)
at org.glassfish.jersey.gf.ejb.internal.EjbComponentProvider.lookupSimpleForm(EjbComponentProvider.java:378)
at org.glassfish.jersey.gf.ejb.internal.EjbComponentProvider.lookup(EjbComponentProvider.java:360)
at org.glassfish.jersey.gf.ejb.internal.EjbComponentProvider.access$000(EjbComponentProvider.java:100)
at org.glassfish.jersey.gf.ejb.internal.EjbComponentProvider$EjbFactory.provide(EjbComponentProvider.java:123)
at org.jvnet.hk2.internal.FactoryCreator.create(FactoryCreator.java:96)
at org.jvnet.hk2.internal.SystemDescriptor.create(SystemDescriptor.java:456)
at org.jvnet.hk2.internal.PerLookupContext.findOrCreate(PerLookupContext.java:69)
at org.jvnet.hk2.internal.Utilities.createService(Utilities.java:2151)
at org.jvnet.hk2.internal.ServiceLocatorImpl.getService(ServiceLocatorImpl.java:641)
at org.jvnet.hk2.internal.ServiceLocatorImpl.getService(ServiceLocatorImpl.java:626)
at org.glassfish.jersey.internal.inject.Injections.getOrCreate(Injections.java:172)
at org.glassfish.jersey.server.model.MethodHandler$ClassBasedMethodHandler.getInstance(MethodHandler.java:185)
at org.glassfish.jersey.server.internal.routing.PushMethodHandlerRouter.apply(PushMethodHandlerRouter.java:74)
at org.glassfish.jersey.server.internal.routing.RoutingStage._apply(RoutingStage.java:112)
at org.glassfish.jersey.server.internal.routing.RoutingStage._apply(RoutingStage.java:115)
at org.glassfish.jersey.server.internal.routing.RoutingStage._apply(RoutingStage.java:115)
at org.glassfish.jersey.server.internal.routing.RoutingStage._apply(RoutingStage.java:115)
at org.glassfish.jersey.server.internal.routing.RoutingStage.apply(RoutingStage.java:94)
at org.glassfish.jersey.server.internal.routing.RoutingStage.apply(RoutingStage.java:63)
at org.glassfish.jersey.process.internal.Stages.process(Stages.java:197)
at org.glassfish.jersey.server.ServerRuntime$1.run(ServerRuntime.java:261)
at org.glassfish.jersey.internal.Errors$1.call(Errors.java:271)
at org.glassfish.jersey.internal.Errors$1.call(Errors.java:267)
at org.glassfish.jersey.internal.Errors.process(Errors.java:315)
at org.glassfish.jersey.internal.Errors.process(Errors.java:297)
at org.glassfish.jersey.internal.Errors.process(Errors.java:267)
at org.glassfish.jersey.process.internal.RequestScope.runInScope(RequestScope.java:297)
at org.glassfish.jersey.server.ServerRuntime.process(ServerRuntime.java:252)
at org.glassfish.jersey.server.ApplicationHandler.handle(ApplicationHandler.java:1025)
at org.glassfish.jersey.servlet.WebComponent.service(WebComponent.java:372)
at org.glassfish.jersey.servlet.ServletContainer.service(ServletContainer.java:382)
at org.glassfish.jersey.servlet.ServletContainer.service(ServletContainer.java:345)
at org.glassfish.jersey.servlet.ServletContainer.service(ServletContainer.java:220)
at org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1682)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:318)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:160)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:734)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:673)
at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:99)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:174)
at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:415)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:282)
at com.sun.enterprise.v3.services.impl.ContainerMapper$HttpHandlerCallable.call(ContainerMapper.java:459)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:167)
at org.glassfish.grizzly.http.server.HttpHandler.runService(HttpHandler.java:201)
at org.glassfish.grizzly.http.server.HttpHandler.doHandle(HttpHandler.java:175)
at org.glassfish.grizzly.http.server.HttpServerFilter.handleRead(HttpServerFilter.java:235)
at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:284)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:201)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:133)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:112)
at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77)
at org.glassfish.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(TCPNIOTransport.java:561)
at org.glassfish.grizzly.strategies.AbstractIOStrategy.fireIOEvent(AbstractIOStrategy.java:112)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.run0(WorkerThreadIOStrategy.java:117)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.access$100(WorkerThreadIOStrategy.java:56)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy$WorkerThreadRunnable.run(WorkerThreadIOStrategy.java:137)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:565)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:545)
at java.lang.Thread.run(Thread.java:745)
Caused by: javax.naming.NameNotFoundException: No object bound to name java:app/gf-4.0.1-fail-ejb-1.0-SNAPSHOT/HelloWorldBean
at com.sun.enterprise.naming.impl.GlassfishNamingManagerImpl.lookup(GlassfishNamingManagerImpl.java:741)
at com.sun.enterprise.naming.impl.GlassfishNamingManagerImpl.lookup(GlassfishNamingManagerImpl.java:715)
at com.sun.enterprise.naming.impl.JavaURLContext.lookup(JavaURLContext.java:167)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:471)
... 64 more
]]



 Comments   
Comment by Joe Di Pol [ 01/Jul/14 ]

There have been some recent Jersey integrations. Assigning to Jakub for initial evaluation.

Comment by dbcjbn [ 04/Aug/14 ]

Would you happen to have an estimate on when this issue will be addressed, please?

Comment by dbcjbn [ 10/Sep/14 ]

This bug has also been observed on GlassFish v4.1

Comment by sgerr [ 16/Sep/14 ]

Bug is reproduced at Glassfish 4.1. It seems it is related to https://java.net/jira/browse/JERSEY-2122, but Jersey bug is at fixed state (fix version is 2.6), whereas Glassfish 4.1 is packaged with jersey of version 2.10.4-0. Unfortunately, this bug still appears. Is it scheduled for resolution?

Comment by giates2000 [ 21/Sep/14 ]

Due to this issue all my working jee7 rest web services are now stopped on glassfish v. 4.1, is there any workaround ?

Comment by gray [ 20/Oct/14 ]

I've found what is causing this bug and added comment to https://java.net/jira/browse/JERSEY-2122.

Comment by gray [ 21/Oct/14 ]

https://java.net/jira/browse/JERSEY-2690

Comment by MarvinEmilBrach [ 08/Mar/15 ]

posssible workaround: replace @Stateless with:
@javax.enterprise.context.RequestScoped
@javax.enterprise.context.ApplicationScoped
@javax.enterprise.context.ConversationScoped // NOT tested
@javax.enterprise.context.SessionScoped // NOT tested

perhaps related to https://java.net/jira/browse/GLASSFISH-21199

Comment by dobromyslov [ 15/Mar/15 ]

@RequestScoped breaks transactions in Jersey and it requires to mark methods as @Transactional.

Also Weld does not work well with @RequestScoped and raises an exception sometimes:
https://issues.jboss.org/browse/WELD-1774

Comment by dobromyslov [ 22/Mar/15 ]

java.lang.IllegalStateException: WELD-000335: Context is already active
Raises when I redeploy with JRebel.
It's been fixed in WELD 2.2.8.Final.

Comment by Sparksis [ 16/May/15 ]

I've submitted a pull request which fixes the issue in Jersey: https://github.com/jersey/jersey/pull/162

Unfortunately the the pull request is still pending.

Comment by nabizamani [ 14/Apr/16 ]

Is this here still an open issue? I'm just wondering because there is no reaction from Oracle!

Comment by Jakub Podlesak [ 14/Apr/16 ]

I am no longer on Jersey team. IIUC, this has already been fixed in Jersey (as per https://github.com/jersey/jersey/commit/8636f65b992322008bb987409af0dd97dec3b95f ). So this bug should get fixed in GlassFish once the corresponding Jersey version gets integrated.





[GLASSFISH-21340] CDI scope annotation on @Provider makes @NameBinding ignored Created: 26/Mar/15  Updated: 29/Apr/16

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

Type: Bug Priority: Major
Reporter: m-radzikowski Assignee: Marek Potociar
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

1.8.0_40



 Description   

Using CDI scope annotation (e.g. @javax.enterprise.context.RequestScoped) makes annotations with @javax.ws.rs.NameBinding ignored in @javax.ws.rs.ext.Provider.

Sample code:

EnableScopedFilter
@Retention(RUNTIME)
@NameBinding
public @interface EnableScopedFilter {	
}
ScopedFilter
@Provider
@EnableScopedFilter
@RequestScoped
public class ScopedFilter implements ContainerRequestFilter {
	@Override
	public void filter(ContainerRequestContext requestContext) throws IOException {
		System.out.println("Scoped filter triggered on path: " + requestContext.getUriInfo().getPath());
	}
}

This filter is executed on every REST method, not only on these annotated with @EnableScopedFilter. If @RequestScoped is removed everything is ok.

CDI scope annotation is needed is bean-discovery-mode in beans.xml is set to "annotation" and filter needs to @Inject some resources.



 Comments   
Comment by jjsnyder83 [ 30/Mar/15 ]

I don't think this is a CDI issue. I think it is a jax-rs issue. Assigning to jax-rs.

Comment by HeinBloed [ 29/Apr/16 ]

Was this bug resolved in a newer Jersey version? I couldn't find any other information about it. Also facing it with GF 4.1.





[GLASSFISH-18946] EAR with two CDI Jersey web archives will not deploy Created: 26/Jul/12  Updated: 13/May/16

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

Type: Bug Priority: Minor
Reporter: Ramon Rockx Assignee: Marek Potociar
Resolution: Unresolved Votes: 16
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows 7


Attachments: Zip Archive JerseyCDITest2.zip     File TestEAR-0.0.1-SNAPSHOT.ear     Java Archive File TestWAR1-0.0.1-SNAPSHOT-sources.jar     Java Archive File TestWAR2-0.0.1-SNAPSHOT-sources.jar    
Tags: req-weld-fix

 Description   

I already filed this issue in the Jersey JIRA (http://java.net/jira/browse/JERSEY-1232), however, after some research by Michal Gajdos, the issue is closed as "invalid", since the problem would by caused by Weld/GlassFish Weld. I also filed an issue at the Weld JIRA (http://issues.jboss.org/browse/WELD-1175), but they think it should be investigated first by the GlassFish team... (from pillar to post).
Hopefully, the GlassFish team can help solving this problem.

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

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

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

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

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

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


 Comments   
Comment by jjsnyder83 [ 03/Oct/12 ]

There is a work-around...I removed the WEB-INF/lib/jersey-gf-servlet-1.12.jar from the wars and I was able to deploy the ear successfully and execute http://localhost:8080/rest1_war/service/rest/RestService1 with "Hello world" as the result. I was able to reproduce the NPE above so I'm still looking into it.

Comment by jjsnyder83 [ 05/Oct/12 ]

I have checked in a fix. The application now deploys. However this has uncovered what I believe to be a bug in Weld. See https://issues.jboss.org/browse/WELD-1175.

I have checked in the fix into 3.1.2 and trunk.

Comment by jjsnyder83 [ 05/Oct/12 ]

Reopening due to the bug in Weld

Comment by Ramon Rockx [ 08/Oct/12 ]

Great that this one is fixed!
I'm looking for a way to patch our GlassFish installation (version 3.1.2.2).
jjsnyder83, you mentioned that it is fixed on trunk and 3.1.2. I can only find commits on the trunk (GF 4.0 I assume). Can you help me out patching 3.1.2/3.1.2.2?

Comment by jjsnyder83 [ 08/Oct/12 ]

I made the change to the 3.1.2-SUSTAINING line as well as trunk (4.0).

I will get back to you on the patching.

Please note that even though the app will deploy a fix to Weld (https://issues.jboss.org/browse/WELD-1175) is still required for the app to work correctly. See the Weld issue for details.

Comment by jjsnyder83 [ 08/Oct/12 ]

The next patch due out is 3.1.2.4 (not sure of the date yet.) But until Weld fixes the issue there's no reason to include this in the patch.

Comment by Ramon Rockx [ 09/Oct/12 ]

Can we expect this fix will be included in 3.1.2.4 since WELD-1175 is fixed too?
(3.1.2.3 is skipped for release?)

Comment by jjsnyder83 [ 11/Oct/12 ]

Yes...I made the fix in the patch line and so it should be included in the next patch release. I have also requested that weld 1.1.10.Final be included as this relies on weld to work properly.

Comment by jjsnyder83 [ 22/Oct/12 ]

GlassFish integration with Weld was updated to Weld 1.1.10.Final with revision 56665.

Comment by jjsnyder83 [ 20/Dec/12 ]

I just tested this on trunk with weld 1.1.10.Final and it doesn't work.

Comment by jwells [ 27/Mar/13 ]

I get this error now when I deploy the above ear in GF 4.0:

Exception while loading the app : CDI deployment failure:Error loading class com.sun.jersey.server.impl.cdi.CDIExtension
org.jboss.weld.resources.spi.ResourceLoadingException: Error loading class com.sun.jersey.server.impl.cdi.CDIExtension
at org.jboss.weld.resources.ClassTransformer.getBackedAnnotatedType(ClassTransformer.java:179)
at org.jboss.weld.resources.ClassTransformer.getBackedAnnotatedType(ClassTransformer.java:190)
at org.jboss.weld.resources.ClassTransformer.getEnhancedAnnotatedType(ClassTransformer.java:224)
at org.jboss.weld.bootstrap.ExtensionBeanDeployer.deployBeans(ExtensionBeanDeployer.java:71)
at org.jboss.weld.bootstrap.WeldBootstrap.startInitialization(WeldBootstrap.java:464)
at org.glassfish.weld.WeldDeployer.event(WeldDeployer.java:192)
at org.glassfish.kernel.event.EventsImpl.send(EventsImpl.java:131)
at org.glassfish.internal.data.ApplicationInfo.load(ApplicationInfo.java:328)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:493)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:219)

I looked at this a little bit, the class com.sun.jersey.server.impl.cdi.CDIExtension is in the jersey-gf-servlet-1.12.jar included in the WAR files included in the EAR. My guess would be that the old CDIExtension (which no longer exists in the Jersey included in GF 4.0) cannot be loaded properly anymore...

So to me this seems like it is currently a Jersey issue, and may have to do with backwards compatibility...

Comment by Ramon Rockx [ 02/May/13 ]

I'm wondering if this bug will be fixed with the upcoming 4.0 release?
It really makes it impossible for us to use REST in a large modular EAR application properly.

Comment by dbenegiamo [ 03/May/13 ]

As the "double WARs in a EAR" is a common solution for applications that expose a FORM authentication for the web presentation and a BASIC authentication for restful web-services, priority of this bug should - in my opinion - raised.

Comment by Ramon Rockx [ 22/May/13 ]

Like jwells mentioned, the current test case results in ClassNotFoundExceptions.
I downloaded GlassFish 4.0 b88. Tweaked the test case:

  • no Jersey servlet configuration anymore (web.xml is empty)
  • no explicit dependency to Jersey 1.12 anymore (it now depends on Jersey 2.x)
  • used the javax.ws.rs.ApplicationPath annotation to configure the REST path prefix.

Now each REST service does work in both web modules.

However, GlassFish does log warnings like
"[WARNING|glassfish 4.0|javax.enterprise.web.util|_ThreadID=60;_ThreadName=AutoDeployer;_TimeMillis=1369210288543;_LevelValue=900; _MessageID=AS-WEB-UTIL-00035;| Unable to load class nl.asknow.sandbox.RestService1, reason: java.lang.ClassNotFoundException: nl.asknow.sandbox.RestService1|#]".
I'm not sure if this warning can be ignored.

I will attach my new test case.

Comment by Ramon Rockx [ 22/May/13 ]

It seems I cannot add an attachment anymore...

Comment by Jakub Podlesak [ 24/May/13 ]

Ramon, could you please send the test case to my e-mail address (jakub.podlesak at oracle.com)? I will attach it here as well once i get it. Thanks!

Comment by Jakub Podlesak [ 27/May/13 ]

Updated test case from Ramon.

Comment by sebastian2 [ 23/Jul/14 ]

Is there a plan to fix that issue? I am also struggeling with this bug....

Comment by lprimak [ 12/May/16 ]

Payara team is tracking this bug here:
https://github.com/payara/Payara/issues/374

Comment by Jakub Podlesak [ 13/May/16 ]

Re-assigning to Marek, as i am not sure who is in charge with Jersey in GF. I am no longer part of the team.





Generated at Mon Sep 26 01:56:20 UTC 2016 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.