<< Back to previous view

[MAVEN2_REPOSITORY-154] allow java.net project gf-cdi-porting-tck to publish maven binaries Created: 09/Apr/13  Updated: 09/Apr/13  Resolved: 09/Apr/13

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

Type: New Feature Priority: Major
Reporter: mtaube Assignee: jorlina
Resolution: Fixed Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: jorlina and mtaube

 Description   

http://java.net/projects/gf-cdi-porting-tck
groupId = org.glassfish.cdi
artifactId = gf-porting-package-tck11
scm URL = https://svn.java.net/svn/gf-cdi-porting-tck~svn



 Comments   
Comment by jorlina [ 09/Apr/13 02:36 PM ]

– Nexus repository was prepared successfully. –

Configuration has been prepared, now you can:





[HK2-142] Replace cglib with javassist Created: 01/Nov/13  Updated: 13/Dec/13  Resolved: 13/Dec/13

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

Type: Improvement Priority: Major
Reporter: jwells Assignee: mtaube
Resolution: Fixed Votes: 3
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: jwells, mtaube and saden

 Description   

cglib is a dead library and javassist seems to be both modern and do the things we need it to do.



 Comments   
Comment by saden [ 12/Dec/13 11:19 PM ]

It looks like HK2 v2.2.0-b25 removed "org.glassfish.hk2.external:asm-all-repackaged" dependency and added javassist. Does this mean HK2 now uses javassist? Or is the work still ongoing?





[HK2-108] Pax tests have been disabled Created: 05/Apr/13  Updated: 06/Dec/13  Resolved: 06/Dec/13

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

Type: Bug Priority: Critical
Reporter: jwells Assignee: mtaube
Resolution: Fixed Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: jwells and mtaube

 Description   

The pax tests for hk2 have been disabled because the web-site the runner tries to go to is unavailable. I can't reach it from any browser wither inside or outside the Oracle network. Eventually the test runs, but it takes about 14 minutes to complete. This is what you see on the screen:

[org.ops4j.pax.url.mvn.internal.Connection] : Collecting versions from repository file:/scratch/jwells/maven/repository/,releases=true,snapshots=true
[org.ops4j.pax.url.mvn.internal.Connection] : Resolving metadata
[org.ops4j.pax.url.mvn.internal.Connection] : Skipping repository file:/scratch/jwells/maven/repository/,releases=true,snapshots=true, reason: Metadata not found in repository file:/scratch/jwells/maven/repository/
[org.ops4j.pax.url.mvn.internal.Connection] : Collecting versions from repository http://scm.ops4j.org/repos/ops4j/projects/pax/runner-repository/,releases=true,snapshots=false
[org.ops4j.pax.url.mvn.internal.Connection] : Resolving metadata

The file osgi/adapter-tests/osgi-adapter-test/pom.xml has been modified to have a <skipTests>true</skipTests> line added.



 Comments   
Comment by mtaube [ 25/Apr/13 02:32 PM ]

Committed revision 4531.





[HK2-104] Link to the javadocs on the hk2 landing page leads to a blank page. Created: 04/Feb/13  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: Bug Priority: Major
Reporter: Ryan Lubke Assignee: mtaube
Resolution: Fixed Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: jwells, mtaube and Ryan Lubke

 Description   

Per the summary.



 Comments   
Comment by Ryan Lubke [ 04/Feb/13 07:13 PM ]

By landing page, I mean hk2.java.net.

Comment by jwells [ 04/Feb/13 09:25 PM ]

Also, the name of the initial web-page appears to be index.html, which is wrong.

Comment by jwells [ 31/Oct/13 07:49 PM ]

Romain fixed this a while ago





[HK2-100] core populates service locator on installation, should populate on RESOLVED Created: 04/Dec/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: Bug Priority: Major
Reporter: jwells Assignee: mtaube
Resolution: Fixed Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: jwells and mtaube

 Description   

A bundle is only wired up to all of its required dependencies when it has achieved the state RESOLVED. However, the current code will add services into hk2 when a bundle achieves the INSTALLED state. This implies that a bundle that is installed, but which will not get resolved (perhaps because it is missing a required import) will still add its services to hk2, even though those services can not be accessed. This code should change to add services only when the bundle becomes RESOLVED.






[HK2-99] Build HK2 with JDK 1.7 Created: 12/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: Improvement Priority: Major
Reporter: jwells Assignee: mtaube
Resolution: Fixed Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: jwells and mtaube

 Description   

We should be building HK2 with 1.7 but with 1.6 source and 1.6 output. Eventually we can change those settings as well.



 Comments   
Comment by mtaube [ 07/Feb/13 09:04 PM ]

hk2-promote hudson job is configured to use JDK 1.6.0_34(Linux)

Comment by mtaube [ 07/Feb/13 09:06 PM ]

changed to JDK 1.7.0_09(Linux)

Comment by mtaube [ 08/Feb/13 06:33 PM ]

added enforcer to enforce JDK 1.7.0_09 plus Maven 3.0.3+





[HK2-97] Move the HK2 website to git Created: 05/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: Minor
Reporter: jwells Assignee: mtaube
Resolution: Fixed Votes: 1
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: jwells and mtaube

 Description   

The current mechanism for posting the maven sites to the hk2 web-site uses svn, which has some serious drawbacks (such as the problem that old API and sites are never deleted). Move the hk2 web-site to use git rather than svn.



 Comments   
Comment by jwells [ 31/Oct/13 07:51 PM ]

The HK2 website is now using a more reasonable framework thanks to Romain and Mason





[HK2-94] issues with PopulatorPostProcessor Created: 29/Oct/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: Bug Priority: Major
Reporter: mtaube Assignee: mtaube
Resolution: Fixed Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: hk2 bootstrap
Participants: mtaube

 Description   

a) Looks like HK2Populator.populate has to be synchronized. It adds one or more populator passed as argument which means if two or more threads call this method simultaneously, they are going to see effect of each others' populators.

b) Also, I didn't really understand why it is removing all populators at the end of the method:

config.addUnbindFilter(BuilderHelper.createContractFilter(PopulatorPostProcessor.class.getName()));

config.commit();

Should it not only remove the populators it had added in the beginning of the method?

c) Overall, I think PopulatorPostProcessor needs to be thoroughly thought through. We should not allow custom populators to be discovered, because their discovery depends on the order in which modules containing custom populators are installed in the system.






[HK2-85] Service locators modules are not updated Created: 11/Oct/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: Bug Priority: Major
Reporter: andriy.zhdanov Assignee: mtaube
Resolution: Fixed Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

File Attachments: Text File AbstractModulesRegistryImpl.patch    
Tags:
Participants: andriy.zhdanov and mtaube

 Description   

It relates to HK2-82 also. In OSGi environment when using multiple service locator's (consider ctm-example), some service locator's modules are not updated.
Because AbstractModulesRegistryImpl.populateServiceLocator wipes out previous serviceLocators when new is created with the same services descriptor name (e.g. default or tenant-scoped).
Proposed fix is to keep list of service locators per name, see attached.






[HK2-82] Fix support for @InhabitatntAnnotation Created: 27/Aug/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: Bug Priority: Major
Reporter: andriy.zhdanov Assignee: mtaube
Resolution: Fixed Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: andriy.zhdanov and mtaube

 Description   

It was possible to use @InhabitantAnnotation to isolate particular services into different universe, like this:

@InhabitantAnnotation("tenant-scoped")
public @interface TenantScoped {

}

So later classes marked with it are in diffent services descriptor file, META-INF/hk2-locator/tenant-scoped, but it is impossible to make HK2 2 make use it.

I think problem is that StaticModulesRegistry.createServiceLocator(String) ignores name passed and also at ClasspathDescriptorFileFinder.findDescriptorFiles() line: 19

Enumeration<URL> e = classLoader.getResources(RESOURCE_NAME); // ="META-INF/hk2-locator/default";

Also please please add and overload to take parent habitat also, it is currently used as follows:

ServiceLocatorFactory.getInstance().create(name, systemHabitat, GENERATOR);






[HK2-76] HK2 proxied injection does not seem to work in OSGi environment Created: 16/Aug/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: Bug Priority: Blocker
Reporter: Marek Potociar Assignee: mtaube
Resolution: Fixed Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Dependency
blocks JERSEY-1342 Introduce proxyable request scope Closed
Tags:
Participants: Marek Potociar and mtaube

 Description   

In Jersey OSGi example test I get following error:

net.sf.cglib.core.CodeGenerationException: java.lang.reflect.InvocationTargetException--&gt;null
	at net.sf.cglib.core.AbstractClassGenerator.create(AbstractClassGenerator.java:237)
	at net.sf.cglib.proxy.Enhancer.createHelper(Enhancer.java:377)
	at net.sf.cglib.proxy.Enhancer.create(Enhancer.java:285)
	at net.sf.cglib.proxy.Enhancer.create(Enhancer.java:679)
	at org.jvnet.hk2.internal.ServiceHandleImpl$1.run(ServiceHandleImpl.java:94)
	at java.security.AccessController.doPrivileged(Native Method)
	at org.jvnet.hk2.internal.ServiceHandleImpl.secureCreate(ServiceHandleImpl.java:90)
	at org.jvnet.hk2.internal.ServiceHandleImpl.getService(ServiceHandleImpl.java:121)
	at org.jvnet.hk2.internal.ServiceLocatorImpl.getService(ServiceLocatorImpl.java:389)
	at org.jvnet.hk2.internal.ThreeThirtyResolver.resolve(ThreeThirtyResolver.java:153)
	at org.jvnet.hk2.internal.Utilities.justInject(Utilities.java:590)
	at org.jvnet.hk2.internal.ServiceLocatorImpl.inject(ServiceLocatorImpl.java:542)
	at org.jvnet.hk2.internal.ServiceLocatorImpl.createAndInitialize(ServiceLocatorImpl.java:589)
	at org.glassfish.jersey.server.ApplicationHandler.initialize(ApplicationHandler.java:373)
	at org.glassfish.jersey.server.ApplicationHandler.&lt;init&gt;(ApplicationHandler.java:248)
	at org.glassfish.jersey.servlet.WebComponent.&lt;init&gt;(WebComponent.java:254)
	at org.glassfish.jersey.servlet.ServletContainer.init(ServletContainer.java:144)
	at org.glassfish.jersey.servlet.ServletContainer.init(ServletContainer.java:323)
	at javax.servlet.GenericServlet.init(GenericServlet.java:241)
	at org.mortbay.jetty.servlet.ServletHolder.initServlet(ServletHolder.java:431)
	at org.mortbay.jetty.servlet.ServletHolder.doStart(ServletHolder.java:263)
	at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50)
	at org.mortbay.jetty.servlet.ServletHandler.initialize(ServletHandler.java:676)
	at org.mortbay.jetty.servlet.ServletHandler.updateMappings(ServletHandler.java:1044)
	at org.mortbay.jetty.servlet.ServletHandler.setServletMappings(ServletHandler.java:1101)
	at org.mortbay.jetty.servlet.ServletHandler.addServletMapping(ServletHandler.java:800)
	at org.ops4j.pax.web.service.jetty.internal.JettyServerImpl$1.call(JettyServerImpl.java:149)
	at org.ops4j.pax.web.service.jetty.internal.JettyServerImpl$1.call(JettyServerImpl.java:144)
	at org.ops4j.pax.swissbox.core.ContextClassLoaderUtils.doWithClassLoader(ContextClassLoaderUtils.java:60)
	at org.ops4j.pax.web.service.jetty.internal.JettyServerImpl.addServlet(JettyServerImpl.java:143)
	at org.ops4j.pax.web.service.jetty.internal.ServerControllerImpl$Started.addServlet(ServerControllerImpl.java:248)
	at org.ops4j.pax.web.service.jetty.internal.ServerControllerImpl.addServlet(ServerControllerImpl.java:99)
	at org.ops4j.pax.web.service.internal.HttpServiceStarted.registerServlet(HttpServiceStarted.java:290)
	at org.ops4j.pax.web.service.internal.HttpServiceStarted.registerServlet(HttpServiceStarted.java:250)
	at org.ops4j.pax.web.service.internal.HttpServiceProxy.registerServlet(HttpServiceProxy.java:98)
	at org.ops4j.pax.web.extender.war.internal.RegisterWebAppVisitorWC.visit(RegisterWebAppVisitorWC.java:192)
	at org.ops4j.pax.web.extender.war.internal.model.WebApp.accept(WebApp.java:521)
	at org.ops4j.pax.web.extender.war.internal.WebAppPublisher$HttpServiceListener.register(WebAppPublisher.java:170)
	at org.ops4j.pax.web.extender.war.internal.WebAppPublisher$HttpServiceListener.serviceChanged(WebAppPublisher.java:155)
	at org.ops4j.pax.web.extender.war.internal.WebAppPublisher$HttpServiceListener.serviceChanged(WebAppPublisher.java:119)
	at org.ops4j.pax.swissbox.tracker.ReplaceableService.setService(ReplaceableService.java:114)
	at org.ops4j.pax.swissbox.tracker.ReplaceableService.access$100(ReplaceableService.java:28)
	at org.ops4j.pax.swissbox.tracker.ReplaceableService$CollectionListener.serviceAdded(ReplaceableService.java:183)
	at org.ops4j.pax.swissbox.tracker.ServiceCollection$Tracker.addingService(ServiceCollection.java:181)
	at org.osgi.util.tracker.ServiceTracker$Tracked.customizerAdding(ServiceTracker.java:896)
	at org.osgi.util.tracker.AbstractTracked.trackAdding(AbstractTracked.java:261)
	at org.osgi.util.tracker.AbstractTracked.trackInitial(AbstractTracked.java:184)
	at org.osgi.util.tracker.ServiceTracker.open(ServiceTracker.java:339)
	at org.osgi.util.tracker.ServiceTracker.open(ServiceTracker.java:273)
	at org.ops4j.pax.swissbox.tracker.ServiceCollection.onStart(ServiceCollection.java:139)
	at org.ops4j.pax.swissbox.lifecycle.AbstractLifecycle$Stopped.start(AbstractLifecycle.java:121)
	at org.ops4j.pax.swissbox.lifecycle.AbstractLifecycle.start(AbstractLifecycle.java:49)
	at org.ops4j.pax.swissbox.tracker.ReplaceableService.onStart(ReplaceableService.java:146)
	at org.ops4j.pax.swissbox.lifecycle.AbstractLifecycle$Stopped.start(AbstractLifecycle.java:121)
	at org.ops4j.pax.swissbox.lifecycle.AbstractLifecycle.start(AbstractLifecycle.java:49)
	at org.ops4j.pax.web.extender.war.internal.WebAppPublisher.publish(WebAppPublisher.java:81)
	at org.ops4j.pax.web.extender.war.internal.WebXmlObserver.addingEntries(WebXmlObserver.java:131)
	at org.ops4j.pax.swissbox.extender.BundleWatcher.register(BundleWatcher.java:186)
	at org.ops4j.pax.swissbox.extender.BundleWatcher.access$000(BundleWatcher.java:45)
	at org.ops4j.pax.swissbox.extender.BundleWatcher$1.bundleChanged(BundleWatcher.java:127)
	at org.apache.felix.framework.util.EventDispatcher.invokeBundleListenerCallback(EventDispatcher.java:800)
	at org.apache.felix.framework.util.EventDispatcher.fireEventImmediately(EventDispatcher.java:728)
	at org.apache.felix.framework.util.EventDispatcher.fireBundleEvent(EventDispatcher.java:610)
	at org.apache.felix.framework.Felix.fireBundleEvent(Felix.java:3734)
	at org.apache.felix.framework.Felix.startBundle(Felix.java:1807)
	at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:905)
	at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:892)
	at org.glassfish.jersey.examples.helloworld.test.AbstractWebAppTest.defaultWebAppTestMethod(AbstractWebAppTest.java:214)
	at org.glassfish.jersey.examples.helloworld.test.WebAppFelixTest.testWebResources(WebAppFelixTest.java:65)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:597)
	at org.ops4j.pax.exam.junit.extender.impl.internal.CallableTestMethodImpl.injectContextAndInvoke(CallableTestMethodImpl.java:143)
	at org.ops4j.pax.exam.junit.extender.impl.internal.CallableTestMethodImpl.call(CallableTestMethodImpl.java:105)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:597)
	at org.ops4j.pax.exam.rbc.internal.RemoteBundleContextImpl.remoteCall(RemoteBundleContextImpl.java:80)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:597)
	at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:303)
	at sun.rmi.transport.Transport$1.run(Transport.java:159)
	at java.security.AccessController.doPrivileged(Native Method)
	at sun.rmi.transport.Transport.serviceCall(Transport.java:155)
	at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:535)
	at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:790)
	at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:649)
	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
	at java.lang.Thread.run(Thread.java:680)
Caused by: java.lang.reflect.InvocationTargetException
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:597)
	at net.sf.cglib.core.ReflectUtils.defineClass(ReflectUtils.java:384)
	at net.sf.cglib.core.AbstractClassGenerator.create(AbstractClassGenerator.java:219)
	... 93 more
Caused by: java.lang.NoClassDefFoundError: net/sf/cglib/proxy/Factory
	at java.lang.ClassLoader.defineClass1(Native Method)
	at java.lang.ClassLoader.defineClassCond(ClassLoader.java:631)
	at java.lang.ClassLoader.defineClass(ClassLoader.java:615)
	... 99 more
Caused by: java.lang.ClassNotFoundException: net.sf.cglib.proxy.Factory
	at org.apache.felix.framework.ModuleImpl.findClassOrResourceByDelegation(ModuleImpl.java:772)
	at org.apache.felix.framework.ModuleImpl.access$200(ModuleImpl.java:73)
	at org.apache.felix.framework.ModuleImpl$ModuleClassLoader.loadClass(ModuleImpl.java:1685)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:247)
	... 102 more





[HK2-61] Uptake the fluent binder API from Jersey to HK2 2.1.x Created: 25/Jun/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: Task Priority: Critical
Reporter: Marek Potociar Assignee: mtaube
Resolution: Fixed Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
is related to HK2-30 Modular binding & injection API Resolved
is related to HK2-43 Support for private modules Resolved
Tags:
Participants: Marek Potociar and mtaube

 Description   

...the name of the Module class can be changed to e.g. Binder to avoid confusion with JDK or GF modularity.



 Comments   
Comment by mtaube [ 14/Nov/12 08:29 PM ]

Added to hk2-api, org.glassfish.hk2.utilities.binding





[HK2-56] Adapt hk2 run level service subsystem to use the new hk2 ServiceLocator Created: 26/Mar/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: Task Priority: Major
Reporter: tbeerbower Assignee: mtaube
Resolution: Fixed Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: mtaube, tbeerbower and tlcksnyder

 Description   

The current run level service system uses old artifacts like Habitat, Inhabitant, LazyInhabitant etc. We need to modify config subsystem to use the new artifacts like ServiceLocator, Descriptor etc.



 Comments   
Comment by tlcksnyder [ 26/Jul/12 05:06 PM ]

reassign due to Tom leaving Oracle.





[HK2-53] Create BaseServicesLocator to isolate changes to Habitat Created: 26/Mar/12  Updated: 06/Dec/13  Due: 26/Mar/12  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: mtaube Assignee: mtaube
Resolution: Fixed Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: mtaube

 Description   

Habitat needs to implement a base interface with only high level functionality such as getByType, getByContract, etc.

The interface must not leak any implementation specific information involving the inner working of hk2, such as Inhabitants.






HK2 2.0 (HK2-54)

[HK2-52] support for JSR 330 Provider in HK2 binding API (to use it interchangeably with Factory) Created: 16/Mar/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: mtaube Assignee: mtaube
Resolution: Fixed Votes: 0
Remaining Estimate: 3 days
Time Spent: Not Specified
Original Estimate: 3 days

Tags:
Participants: mtaube

 Description   

the programmatic binding api needs to allow a user to bind an instance of a jsr-330 provider, this provider will then be used to factory an instance when needed.

this work is currently being done in the trunk (hk2 2.0).






JSR-330 support (HK2-37)

[HK2-51] Support for injection using jsr-330 annotations - make hk2 compliant with jsr-330 tck Created: 16/Mar/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: mtaube Assignee: mtaube
Resolution: Fixed Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: mtaube

 Description   

Support for injection using jsr-330 annotations (javax.inject.Inject, support for qualifiers, providers, etc)



 Comments   
Comment by mtaube [ 16/Mar/12 02:44 PM ]

The (hk2-pre2.0) branch currently being consumed by glassfish and trunk are both jsr-330 compliant





[HK2-50] @Inject @Named("name") Provider<Foo> doesn't work Created: 14/Feb/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: Bug Priority: Major
Reporter: Mahesh Kannan Assignee: mtaube
Resolution: Fixed Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: Mahesh Kannan and mtaube

 Description   

When multiple implementations of a contract exist for a contract (say Foo), then

@Inject
@Named("some-name")
Provider<Foo> fooProvider;

doesn't work.

The injected provider is not null but fooProvider.get() returns an object that doesn't match the name. Seems like name specified in @Named is ignored






[HK2-37] JSR-330 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: New Feature Priority: Critical
Reporter: Marek Potociar Assignee: mtaube
Resolution: Fixed Votes: 0
Σ Remaining Estimate: Not Specified Remaining Estimate: Not Specified
Σ Time Spent: Not Specified Time Spent: Not Specified
Σ Original Estimate: Not Specified Original Estimate: Not Specified

Sub-Tasks:
Key
Summary
Type
Status
Assignee
HK2-51 Support for injection using jsr-330 a... Sub-task Resolved mtaube  
Tags:
Participants: Marek Potociar and mtaube

 Description   
  • support for JSR 330 annotations
  • support for JSR 330 Provider in HK2 binding API (to use it interchangeably with Factory)
  • support for JSR 330 Provider injection (to be able to inject it interchangeably with Factory)





[HK2-4] Installing metro when server is running does not resolve the dependencies Created: 23/Oct/08  Updated: 06/Dec/13  Resolved: 06/Dec/13

Status: Resolved
Project: hk2
Component/s: www
Affects Version/s: 1.*
Fix Version/s: 1.*

Type: Bug Priority: Critical
Reporter: Bhakti Mehta Assignee: mtaube
Resolution: Fixed Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 4
Tags:
Participants: Bhakti Mehta and mtaube

 Description   

Try starting the v3 server run admingui or UC and install metro you will get
unresolved bundle errors This needs server restart
This is evaluation from Sahoo
"I just checked the code and compared with the exception stack. I was wrong in
my earlier email. Even though UC does not call any OSGi API, when new modules
are copied to modules directory, one of the HK2 threads detects them immediately
and calls appropriate OSGi API to resolve them, but it does not take care of the
dependencies among newly added modules, so it is getting that exception. It is a
bug in HK2; too late to fix. Restarting the server is a work around. I should
also say that despite the log message, the rest of the functionality should
continue to work as usual, only the newly added modules won't be available until
server is restarted. "






[HK2-3] ModulesRegistry find module by package Created: 25/Jul/08  Updated: 06/Dec/13  Resolved: 06/Dec/13

Status: Resolved
Project: hk2
Component/s: www
Affects Version/s: 1.*
Fix Version/s: 1.*

Type: Improvement Priority: Major
Reporter: Ryan Lubke Assignee: mtaube
Resolution: Won't Fix Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 3
Tags:
Participants: mtaube and Ryan Lubke

 Description   

While working on the JSF OSGi bundle integration, I've noticed
a small problem with how the jsf-connector module interacts
with HK2.

The current version of the jsf-connector has the jsf implementation
classes inlined. This allows the TLD provider to call ModulesRegistry(Class)
passing in the TLD provider class itself to locate the Module to get the TLD
locations.

However, once the jsf implementation classes are no longer inlined, the
code falls apart (the TLDs are in a separate module now). I've resolved
the issue by calling ModulesRegistry.getModules() and searching the
Collection for the module that needs to be scanned using the osgi symbolic
bundle name - probably not the best choice as we don't want any hard dependencies
on bundle names.

I've looked at the ModulesRegistry API and haven't found anything else that
we might be able to leverage. So I thought I would throw out an idea.
Since OSGi bundles typically have a list of packages they export, it seems a
module could potentially be found using a package name as well. Something
like:

Module ModulesRegistry.find(String packageName)



 Comments   
Comment by mtaube [ 14/Nov/12 08:37 PM ]

Spoke with filer, no longer needs this feature





[GLASSFISH-20461] embedded glassfish bundles wrong version of CDI-api Created: 03/May/13  Updated: 06/May/13  Resolved: 06/May/13

Status: Closed
Project: glassfish
Component/s: embedded
Affects Version/s: None
Fix Version/s: 4.0_b88_RC4

Type: Bug Priority: Major
Reporter: mtaube Assignee: mtaube
Resolution: Fixed Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: 4_0-approved
Participants: mtaube and Tom Mueller

 Description   

An old version of the cdi-api is being included in embedded-glassfish causing java.lang.NoSuchMethodError at app deployment time.

What is the impact on the customer of the bug?

Without the fix users cannot deploy to embedded glassfish

What is the cost/risk of fixing the bug?

Very low, changing from cdi-api 1.1PRD to 1.1 in appserver/web

Is there an impact on documentation or message strings?

No.

Which tests should QA (re)run to verify the fix did not destabilize GlassFish?

quicklook, cdi tck

Which is the targeted build of 4.0 for this fix?

88.

If this an integration of a new version of a component from another project,
what are the changes that are being brought in? This might be list of
Jira issues from that project or a list of revision messages.

N/A.



 Comments   
Comment by Tom Mueller [ 03/May/13 02:47 PM ]

Approved for 4.0.

Comment by mtaube [ 06/May/13 05:47 PM ]

Committed to trunk and branch (61850).





[GLASSFISH-20450] Weld combination of API/implementation in single bundle slows down server startup Created: 01/May/13  Updated: 16/Apr/14  Resolved: 16/Apr/14

Status: Resolved
Project: glassfish
Component/s: cdi
Affects Version/s: 4.0_b86_RC2
Fix Version/s: 4.0.1

Type: Bug Priority: Major
Reporter: Tom Mueller Assignee: phil.zampino
Resolution: Duplicate Votes: 1
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: devx_web
Participants: jjsnyder83, mtaube, phil.zampino, Sanjeeb Sahoo, TangYong, tlcksnyder and Tom Mueller

 Description   

Currently, the weld-osgi-bundle.jar file contains the javax.enterprise.* (context, inject, event, etc.) classes (the API consisting of 108 classes) and 2716 implementation classes (org.jboss.weld, etc.).

Experiments have shown that if this bundle is split into two bundles, e.g., weld-osgi-api.jar and weld-osgi-impl.jar, then a 3% improvement can be achieved in the devx_web performance benchmark. After server startup, the weld-osgi-impl.jar stays in the installed state. It is resolved during application deployment.

This issue is for making this split.



 Comments   
Comment by Tom Mueller [ 01/May/13 04:50 PM ]

Here is an analysis of how the bundle status changes given this change:

After a server start (with no application), the following modules are no longer resolved after the split (they are in the installed state):

Deployment Related JavaEE Full Profile Classes
JavaServer Pages(TM) Standard Tag Library API
Mojarra JSF Implementation 2.2.0
Weld connector for glassfish
Weld integration for glassfish
org.glassfish.main.web.weld-integration-fragment

The state of all bundles after the deploy of an application is the same (except there is the new added bundle which is resolved).

Comment by jjsnyder83 [ 01/May/13 05:37 PM ]

The packages to move into an weld-osgi-api.jar include:
javax.enterprise.*
javax.decorator

Comment by Tom Mueller [ 02/May/13 04:46 PM ]

It would be nice to get this into 4.0, if possible. Please evaluate.

Comment by tlcksnyder [ 02/May/13 09:00 PM ]

Defer to 4.0.1.

Comment by Sanjeeb Sahoo [ 03/May/13 12:54 AM ]

I think we have a bad dependency issue here. We should not separate the api from implementation bundle.

Comment by mtaube [ 06/May/13 05:56 PM ]

weld-integration-fragment attaches to the weld osgi-bundle, and imports from the weld-integration bundle. This seems to be what is causing the transitive resolution of ejb-container.

Comment by Sanjeeb Sahoo [ 07/May/13 03:18 AM ]

Was weld-osgi bundle getting resolved in 3.1.2 as well? Or is this bad dependency a regression in 4.0?

Comment by Tom Mueller [ 07/May/13 02:48 PM ]

Here are the states of the Weld related bundles after starting 3.1.2:

Weld OSGi Bundle | 3.1.2 | Resolved
Weld integration for glassfish | 3.1.2 | Active
org.glassfish.main.web.weld-integration-fragment | 3.1.2 | Resolved

The problem in 4.0 is not so much that these bundles are getting resolved, but that in 4.0, the resolution of weld-osgi-bundle.jar causes ejb-container to be resolved as well where it didn't in 3.1.2. See issue GLASSFISH-20409.

Comment by Sanjeeb Sahoo [ 07/May/13 03:44 PM ]

My point is we should not separate APIs from implementations. They are against our preferred packaging approach as Bill described in maven/osgi/javaee packaging document. The APIs should only be needed if the corresponding implementation is also needed. It seems to me that some bundles are incorrectly packaged leading these kind of issues.

Comment by TangYong [ 17/Nov/13 02:45 PM ]

Just now, we(I and Jeremy) have done a hard test for the issue as following:

We are doing GlassFish on-demand starting experiments and we have decreased modules into mini-modules for meeting GlassFish Domain normal Starting.

In these mini-modules, some modules as API are necessary and this is reasonable. However,weld-osgi-bundle.jar can not be removed. We know that some modules depend on CDI and only depend on CDI API rather than Impl. We wish that API from weld-osgi-bundle.jar can be separated in order that in on-demand starting env, we can only preserve API and remove impl. Thus, this will improve GF Starting performance.

So, from this point, I agree with separating APIs from implementations.

Comment by TangYong [ 19/Nov/13 02:29 AM ]

Pl. allowing me explain the issue in detailed:

javax.transaction-api.jar imports javax.enterprise.context package, so it depends on cdi api 1.1. On minimizing GlassFish domain starting, javax.transaction-api.jar is necessary.

Well, because cdi api 1.1 is wrapped into weld-osgi-bundle.jar, we must include weld-osgi-bundle.jar even though it also wraps
cdi 1.1 implementation while minimizing GlassFish domain starting. So, from this point, we should separate cdi api from implementations.

On the other hand, I looked into the newest wildfly-8.0.0.Beta1, on its modules splitting, about CDI, it has the following modules,

1) cdi-api-1.1.jar

Its aim is only for cdi api 1.1

2) weld-api-2.1.CR1.jar

Its aim is for weld api, this is related to implementation.

3) weld-core-impl-2.1.0.CR1.jar

Its aim is for weld implementation, this is related to implementation.

4) weld-spi-2.1.CR1.jar

Its aim is for weld spi implementation, this is related to implementation.

Based on the above analyse, I think that current weld-osgi-bundle.jar is not good for modulation principle.

Best Regards!
Tang

Comment by TangYong [ 06/Dec/13 02:37 AM ]

in current GF modules, there are two modules which all exports 'javax.inject'.

1) weld-osgi-bundle.jar
2) javax.inject.jar

seperating Weld API from implementation is a solution for the issue.

Comment by TangYong [ 10/Dec/13 01:38 PM ]

The issues related to this jira will be resolved by GLASSFISH-20922.

Pl. confirming and closing this jira.

Comment by jjsnyder83 [ 16/Apr/14 07:29 PM ]

Duplicate of https://java.net/jira/browse/GLASSFISH-20922





[GLASSFISH-20442] restore BeanValidatorNamingProxy to nucleus Created: 30/Apr/13  Updated: 30/Apr/13  Resolved: 30/Apr/13

Status: Closed
Project: glassfish
Component/s: bean-validator
Affects Version/s: 4.0_b86_RC2
Fix Version/s: 4.0_b87_RC3

Type: Bug Priority: Major
Reporter: mtaube Assignee: mtaube
Resolution: Fixed Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: 4_0-approved
Participants: mtaube

 Description   

BeanValidatorNamingProxy was recently removed from nucleus, favoring an alternate implementation (in weld-integration) that integrates with CDI (since the Validator/ValidatorFactory needs to be retrieved from CDI when available). This is problematic in appclient distribution where the weld-integration module is not present.

The solution is to restore BeanValidatorNamingProxy and delegate to the weld-integration if available (implemented with @Inject @Optional @Named(...)).. This way, CDI will be interrogated for Validator objects if CDI is available, but the object will be returned either way.



 Comments   
Comment by mtaube [ 30/Apr/13 04:10 PM ]

This bug is causing the following CTS failure: com/sun/ts/tests/ejb30/misc/jndi/earjar/Client.java#beanValidator: Client_beanValidator

Comment by mtaube [ 30/Apr/13 04:13 PM ]

What is the impact on the customer of the bug?
appclients cannot look up Validator/ValidatorFactory from jndi

How likely is it that a customer will see the bug and how serious is the bug?
certain

Is it a regression?
Yes.

Does it meet other bug fix criteria (security, performance, etc.)?
no.

What CTS failures are caused by this bug?
com/sun/ts/tests/ejb30/misc/jndi/earjar/Client.java#beanValidator: Client_beanValidator

What is the cost/risk of fixing the bug?
Low

How risky is the fix? How much work is the fix? Is the fix complicated?
Low – restores previous behavior and adds a delegation model

Is there an impact on documentation or message strings?
no.

Which tests should QA (re)run to verify the fix did not destabilize GlassFish?
EJB, EJB cts, bean-validation CTS

Which is the targeted build of 4.0 for this fix?
rc3.

If this an integration of a new version of a component from another project,
what are the changes that are being brought in? This might be list of
Jira issues from that project or a list of revision messages.
No.

Comment by mtaube [ 30/Apr/13 04:27 PM ]

Sending appserver/web/weld-integration/src/main/java/org/glassfish/weld/ValidationNamingProxy.java
Adding nucleus/core/kernel/src/main/java/org/glassfish/kernel/bean_validator/BeanValidatorNamingProxy.java
Transmitting file data ..
Committed revision 61753.





[GLASSFISH-20438] Missing Bean Validator Provider in Embedded GlassFish Created: 30/Apr/13  Updated: 02/May/13

Status: Open
Project: glassfish
Component/s: bean-validator, embedded
Affects Version/s: 4.0_b86_RC2
Fix Version/s: 4.0.1

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

Embedded GlassFish


Tags: beanvalidation embedded glassfish_4_0-approved
Participants: Dhiru Pandey, mtaube and peter_pilgrim

 Description   

In Embedded GlassFish when deploying JAX-RS applications, there is an exception raised, which follows:

"C:\Program Files\Java\jdk1.7.0_17\bin\java" -Didea.launcher.port=7533 "-Didea.launcher.bin.path=C:\Program Files (x86)\JetBrains\IntelliJ IDEA 12.1\bin" -Dfile.encoding=UTF-8 -classpath "C:\Program Files (x86)\JetBrains\IntelliJ IDEA 12.1\lib\idea_rt.jar;C:\Program Files (x86)\JetBrains\IntelliJ IDEA 12.1\plugins\junit\lib\junit-rt.jar;C:\Program Files\Java\jdk1.7.0_17\jre\lib\charsets.jar;C:\Program Files\Java\jdk1.7.0_17\jre\lib\deploy.jar;C:\Program Files\Java\jdk1.7.0_17\jre\lib\javaws.jar;C:\Program Files\Java\jdk1.7.0_17\jre\lib\jce.jar;C:\Program Files\Java\jdk1.7.0_17\jre\lib\jfr.jar;C:\Program Files\Java\jdk1.7.0_17\jre\lib\jfxrt.jar;C:\Program Files\Java\jdk1.7.0_17\jre\lib\jsse.jar;C:\Program Files\Java\jdk1.7.0_17\jre\lib\management-agent.jar;C:\Program Files\Java\jdk1.7.0_17\jre\lib\plugin.jar;C:\Program Files\Java\jdk1.7.0_17\jre\lib\resources.jar;C:\Program Files\Java\jdk1.7.0_17\jre\lib\rt.jar;C:\Program Files\Java\jdk1.7.0_17\jre\lib\ext\access-bridge-64.jar;C:\Program Files\Java\jdk1.7.0_17\jre\lib\ext\dnsns.jar;C:\Program Files\Java\jdk1.7.0_17\jre\lib\ext\jaccess.jar;C:\Program Files\Java\jdk1.7.0_17\jre\lib\ext\localedata.jar;C:\Program Files\Java\jdk1.7.0_17\jre\lib\ext\sunec.jar;C:\Program Files\Java\jdk1.7.0_17\jre\lib\ext\sunjce_provider.jar;C:\Program Files\Java\jdk1.7.0_17\jre\lib\ext\sunmscapi.jar;C:\Program Files\Java\jdk1.7.0_17\jre\lib\ext\zipfs.jar;C:\Users\peter\Documents\IdeaProjects\javaee7-handbook\ch08\jaxrs-basic\out\test\jaxrs-basic;C:\Users\peter\Documents\IdeaProjects\javaee7-handbook\ch08\jaxrs-basic\out\production\jaxrs-basic;C:\Users\peter\.gradle\caches\artifacts-23\filestore\javax\javaee-api\7.0-bpeter-private\jar\9fa61bc3c788afba981ee07fa39e6b4c7e657546\javaee-api-7.0-bpeter-private.jar;C:\Users\peter\.m2\repository\com\javaeehandbook\book1\glassfish-embedded-runner\1.0\glassfish-embedded-runner-1.0.jar;C:\Users\peter\.gradle\caches\artifacts-23\filestore\org.jboss.shrinkwrap\shrinkwrap-api\1.0.1\jar\83ee2ca1702d79ceda73634e33b0fac8e73acced\shrinkwrap-api-1.0.1.jar;C:\Users\peter\.gradle\caches\artifacts-23\filestore\org.jboss.shrinkwrap\shrinkwrap-impl-base\1.0.1\jar\feb8c9e875222fae065b4c81937797b00c7ff347\shrinkwrap-impl-base-1.0.1.jar;C:\Users\peter\.gradle\caches\artifacts-23\filestore\javax\javaee-web-api\7.0-bpeter-private\jar\100d0af33717b582e057607811df66f1b4531d38\javaee-web-api-7.0-bpeter-private.jar;C:\Users\peter\.gradle\caches\artifacts-23\filestore\org.glassfish.main.extras\glassfish-embedded-all\4.0-b72\jar\942b982d5c005806a08843d2a1f411f278c04077\glassfish-embedded-all-4.0-b72.jar;C:\Users\peter\.gradle\caches\artifacts-23\filestore\javax.activation\activation\1.1\jar\e6cb541461c2834bdea3eb920f1884d1eb508b50\activation-1.1.jar;C:\Users\peter\.gradle\caches\artifacts-23\filestore\com.sun.mail\javax.mail\1.5.0-b01\jar\3f83e464cf9e42e31230d503e011d314755c02eb\javax.mail-1.5.0-b01.jar;C:\Users\peter\.gradle\caches\artifacts-23\filestore\org.jboss.shrinkwrap\shrinkwrap-spi\1.0.1\jar\4bcb163157366c0f690362594dfa4baed67a6152\shrinkwrap-spi-1.0.1.jar;C:\Users\peter\.gradle\caches\artifacts-23\filestore\junit\junit\4.11\jar\4e031bb61df09069aeb2bffb4019e7a5034a4ee0\junit-4.11.jar;C:\Users\peter\.gradle\caches\artifacts-23\filestore\org.hamcrest\hamcrest-core\1.3\jar\42a25dc3219429f0e5d060061f71acb49bf010a0\hamcrest-core-1.3.jar" com.intellij.rt.execution.application.AppMain com.intellij.rt.execution.junit.JUnitStarter -ideVersion5 je7hb.jaxrs.basic.RestfulBookAsyncServiceClientTest
classpath[0] = C:\Program Files (x86)\JetBrains\IntelliJ IDEA 12.1\lib\idea_rt.jar
classpath[1] = C:\Program Files (x86)\JetBrains\IntelliJ IDEA 12.1\plugins\junit\lib\junit-rt.jar
classpath[2] = C:\Program Files\Java\jdk1.7.0_17\jre\lib\charsets.jar
classpath[3] = C:\Program Files\Java\jdk1.7.0_17\jre\lib\deploy.jar
classpath[4] = C:\Program Files\Java\jdk1.7.0_17\jre\lib\javaws.jar
classpath[5] = C:\Program Files\Java\jdk1.7.0_17\jre\lib\jce.jar
classpath[6] = C:\Program Files\Java\jdk1.7.0_17\jre\lib\jfr.jar
classpath[7] = C:\Program Files\Java\jdk1.7.0_17\jre\lib\jfxrt.jar
classpath[8] = C:\Program Files\Java\jdk1.7.0_17\jre\lib\jsse.jar
classpath[9] = C:\Program Files\Java\jdk1.7.0_17\jre\lib\management-agent.jar
classpath[10] = C:\Program Files\Java\jdk1.7.0_17\jre\lib\plugin.jar
classpath[11] = C:\Program Files\Java\jdk1.7.0_17\jre\lib\resources.jar
classpath[12] = C:\Program Files\Java\jdk1.7.0_17\jre\lib\rt.jar
classpath[13] = C:\Program Files\Java\jdk1.7.0_17\jre\lib\ext\access-bridge-64.jar
classpath[14] = C:\Program Files\Java\jdk1.7.0_17\jre\lib\ext\dnsns.jar
classpath[15] = C:\Program Files\Java\jdk1.7.0_17\jre\lib\ext\jaccess.jar
classpath[16] = C:\Program Files\Java\jdk1.7.0_17\jre\lib\ext\localedata.jar
classpath[17] = C:\Program Files\Java\jdk1.7.0_17\jre\lib\ext\sunec.jar
classpath[18] = C:\Program Files\Java\jdk1.7.0_17\jre\lib\ext\sunjce_provider.jar
classpath[19] = C:\Program Files\Java\jdk1.7.0_17\jre\lib\ext\sunmscapi.jar
classpath[20] = C:\Program Files\Java\jdk1.7.0_17\jre\lib\ext\zipfs.jar
classpath[21] = C:\Users\peter\Documents\IdeaProjects\javaee7-handbook\ch08\jaxrs-basic\out\test\jaxrs-basic
classpath[22] = C:\Users\peter\Documents\IdeaProjects\javaee7-handbook\ch08\jaxrs-basic\out\production\jaxrs-basic
classpath[23] = C:\Users\peter\.gradle\caches\artifacts-23\filestore\javax\javaee-api\7.0-bpeter-private\jar\9fa61bc3c788afba981ee07fa39e6b4c7e657546\javaee-api-7.0-bpeter-private.jar
classpath[24] = C:\Users\peter\.m2\repository\com\javaeehandbook\book1\glassfish-embedded-runner\1.0\glassfish-embedded-runner-1.0.jar
classpath[25] = C:\Users\peter\.gradle\caches\artifacts-23\filestore\org.jboss.shrinkwrap\shrinkwrap-api\1.0.1\jar\83ee2ca1702d79ceda73634e33b0fac8e73acced\shrinkwrap-api-1.0.1.jar
classpath[26] = C:\Users\peter\.gradle\caches\artifacts-23\filestore\org.jboss.shrinkwrap\shrinkwrap-impl-base\1.0.1\jar\feb8c9e875222fae065b4c81937797b00c7ff347\shrinkwrap-impl-base-1.0.1.jar
classpath[27] = C:\Users\peter\.gradle\caches\artifacts-23\filestore\javax\javaee-web-api\7.0-bpeter-private\jar\100d0af33717b582e057607811df66f1b4531d38\javaee-web-api-7.0-bpeter-private.jar
classpath[28] = C:\Users\peter\.gradle\caches\artifacts-23\filestore\org.glassfish.main.extras\glassfish-embedded-all\4.0-b72\jar\942b982d5c005806a08843d2a1f411f278c04077\glassfish-embedded-all-4.0-b72.jar
classpath[29] = C:\Users\peter\.gradle\caches\artifacts-23\filestore\javax.activation\activation\1.1\jar\e6cb541461c2834bdea3eb920f1884d1eb508b50\activation-1.1.jar
classpath[30] = C:\Users\peter\.gradle\caches\artifacts-23\filestore\com.sun.mail\javax.mail\1.5.0-b01\jar\3f83e464cf9e42e31230d503e011d314755c02eb\javax.mail-1.5.0-b01.jar
classpath[31] = C:\Users\peter\.gradle\caches\artifacts-23\filestore\org.jboss.shrinkwrap\shrinkwrap-spi\1.0.1\jar\4bcb163157366c0f690362594dfa4baed67a6152\shrinkwrap-spi-1.0.1.jar
classpath[32] = C:\Users\peter\.gradle\caches\artifacts-23\filestore\junit\junit\4.11\jar\4e031bb61df09069aeb2bffb4019e7a5034a4ee0\junit-4.11.jar
classpath[33] = C:\Users\peter\.gradle\caches\artifacts-23\filestore\org.hamcrest\hamcrest-core\1.3\jar\42a25dc3219429f0e5d060061f71acb49bf010a0\hamcrest-core-1.3.jar
Found populator: org.glassfish.kernel.embedded.EmbeddedDomainXml
Apr 30, 2013 11:01:26 AM org.glassfish.security.services.impl.authorization.AuthorizationServiceImpl initialize
INFO: Authorization Service has successfully initialized.
Apr 30, 2013 11:01:26 AM com.sun.enterprise.v3.admin.CommandRunnerImpl doCommand
SEVERE: Exception while running a command
javax.validation.ValidationException: Unable to load Bean Validation provider
at javax.validation.Validation$GetValidationProviderList.run(Validation.java:346)
at javax.validation.Validation$GetValidationProviderList.getValidationProviderList(Validation.java:310)
at javax.validation.Validation$DefaultValidationProviderResolver.getValidationProviders(Validation.java:292)
at javax.validation.Validation$GenericBootstrapImpl.configure(Validation.java:252)
at javax.validation.Validation.buildDefaultValidatorFactory(Validation.java:107)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.initBeanValidator(CommandRunnerImpl.java:462)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.checkAgainstBeanConstraints(CommandRunnerImpl.java:472)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.injectParameters(CommandRunnerImpl.java:444)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1190)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1500(CommandRunnerImpl.java:109)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1760)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1676)
at com.sun.enterprise.admin.cli.embeddable.CommandExecutorImpl.executeCommand(CommandExecutorImpl.java:168)
at com.sun.enterprise.admin.cli.embeddable.CommandExecutorImpl.run(CommandExecutorImpl.java:93)
at com.sun.enterprise.glassfish.bootstrap.ConfiguratorImpl.configure(ConfiguratorImpl.java:68)
at com.sun.enterprise.glassfish.bootstrap.GlassFishImpl.configure(GlassFishImpl.java:71)
at com.sun.enterprise.glassfish.bootstrap.GlassFishImpl.<init>(GlassFishImpl.java:65)
at com.sun.enterprise.glassfish.bootstrap.StaticGlassFishRuntime$1.<init>(StaticGlassFishRuntime.java:115)
at com.sun.enterprise.glassfish.bootstrap.StaticGlassFishRuntime.newGlassFish(StaticGlassFishRuntime.java:115)
at je7hb.common.webcontainer.embedded.glassfish.AbstractEmbeddedRunner.init(AbstractEmbeddedRunner.java:46)
at je7hb.common.webcontainer.embedded.glassfish.SimpleEmbeddedRunner.launchDeployWarFile(SimpleEmbeddedRunner.java:58)
at je7hb.jaxrs.basic.RestfulBookAsyncServiceClientTest.assembleDeployAndStartServer(RestfulBookAsyncServiceClientTest.java:43)
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.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:24)
at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
at org.junit.runner.JUnitCore.run(JUnitCore.java:160)
at com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:77)
at com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:195)
at com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:63)
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 com.intellij.rt.execution.application.AppMain.main(AppMain.java:120)
Caused by: java.util.ServiceConfigurationError: javax.validation.spi.ValidationProvider: Provider org.hibernate.validator.HibernateValidator not found
at java.util.ServiceLoader.fail(ServiceLoader.java:231)
at java.util.ServiceLoader.access$300(ServiceLoader.java:181)
at java.util.ServiceLoader$LazyIterator.next(ServiceLoader.java:365)
at java.util.ServiceLoader$1.next(ServiceLoader.java:445)
at javax.validation.Validation$GetValidationProviderList.run(Validation.java:343)
... 40 more

org.glassfish.embeddable.GlassFishException: PlainTextActionReporterFAILUREjavax.validation.ValidationException: Unable to load Bean Validation providerDescription: set commandUnable to load Bean Validation provider
Usage: set [?|-help[=<help(default:false)>]]
(dotted-attribute-name=value)+

at com.sun.enterprise.glassfish.bootstrap.ConfiguratorImpl.configure(ConfiguratorImpl.java:71)
at com.sun.enterprise.glassfish.bootstrap.GlassFishImpl.configure(GlassFishImpl.java:71)
at com.sun.enterprise.glassfish.bootstrap.GlassFishImpl.<init>(GlassFishImpl.java:65)
at com.sun.enterprise.glassfish.bootstrap.StaticGlassFishRuntime$1.<init>(StaticGlassFishRuntime.java:115)
at com.sun.enterprise.glassfish.bootstrap.StaticGlassFishRuntime.newGlassFish(StaticGlassFishRuntime.java:115)
at je7hb.common.webcontainer.embedded.glassfish.AbstractEmbeddedRunner.init(AbstractEmbeddedRunner.java:46)
at je7hb.common.webcontainer.embedded.glassfish.SimpleEmbeddedRunner.launchDeployWarFile(SimpleEmbeddedRunner.java:58)
at je7hb.jaxrs.basic.RestfulBookAsyncServiceClientTest.assembleDeployAndStartServer(RestfulBookAsyncServiceClientTest.java:43)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:24)
at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
at org.junit.runner.JUnitCore.run(JUnitCore.java:160)
at com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:77)
at com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:195)
at com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:63)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at com.intellij.rt.execution.application.AppMain.main(AppMain.java:120)

java.lang.NullPointerException
at je7hb.jaxrs.basic.RestfulBookAsyncServiceClientTest.stopServer(RestfulBookAsyncServiceClientTest.java:49)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:33)
at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
at org.junit.runner.JUnitCore.run(JUnitCore.java:160)
at com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:77)
at com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:195)
at com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:63)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at com.intellij.rt.execution.application.AppMain.main(AppMain.java:120)

java.lang.NullPointerException
at je7hb.jaxrs.basic.RestfulBookAsyncServiceClientTest.stopServer(RestfulBookAsyncServiceClientTest.java:49)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:33)
at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
at org.junit.runner.JUnitCore.run(JUnitCore.java:160)
at com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:77)
at com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:195)
at com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:63)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at com.intellij.rt.execution.application.AppMain.main(AppMain.java:120)

Process finished with exit code -1

Embedded GlassFish does not have a default bean validator configured by default.
There is a work around for this error, which is to configure in the application.

Create an empty project file called `src/main/resources/META-INF/services/javax.validation.spi.ValidationProvider' and add this configuration line:

org.hibernate.validator.HibernateValidator

This should be part of the embedded GF itself though.



 Comments   
Comment by peter_pilgrim [ 30/Apr/13 11:13 AM ]

Oops! The work around does not work for GlassFish-b86 or my personal 4.0 SNAPSHOT.

Comment by Dhiru Pandey [ 30/Apr/13 06:02 PM ]

Assigning to JJ Snyder for investigation

Comment by mtaube [ 30/Apr/13 08:29 PM ]

I'm having a difficult time reproducing this, I have confirmed that the META-INF/services/javax.validation.spi.ValidationProvider file exists along with the hibernate-validator classes in glassfish-embedded-all.jar ..

Additionally, when I start via java -jar glassfish-embedded-all.jar I see that it is able to bootstrap hibernate-validator (which it clearly does not do in your output):

$ java -jar glassfish-embedded-all.jar
Found populator: org.glassfish.kernel.embedded.EmbeddedDomainXml
Apr 30, 2013 4:24:18 PM com.sun.enterprise.v3.services.impl.GrizzlyService createNetworkProxy
INFO: Network listener http-listener on port 0 disabled per domain.xml
Apr 30, 2013 4:24:18 PM com.sun.enterprise.v3.services.impl.GrizzlyService createNetworkProxy
INFO: Network listener https-listener on port 0 disabled per domain.xml

Apr 30, 2013 4:24:18 PM org.hibernate.validator.internal.util.Version <clinit>
INFO: HV000001: Hibernate Validator 5.0.0.Final
Apr 30, 2013 4:24:18 PM org.glassfish.security.services.impl.authorization.AuthorizationServiceImpl initialize
INFO: Authorization Service has successfully initialized.
Apr 30, 2013 4:24:18 PM org.glassfish.jersey.server.ApplicationHandler initialize
INFO: Initiating Jersey application, version Jersey: 2.0-rc2 2013-04-23 12:04:25...

Could you provide reproduction steps along with a test case?

Comment by peter_pilgrim [ 01/May/13 09:23 AM ]

Here is the code. You need to change the build setting in the gradle to point to the newest GlassFish snapshot (-b87), which fixes the missing JSONP bug

// RestfulBookService.java
package je7hb.jaxrs.basic;

import javax.annotation.PostConstruct;
import javax.annotation.PreDestroy;
import javax.ws.rs.GET;
import javax.ws.rs.Path;
import javax.ws.rs.Produces;
import javax.ws.rs.core.MediaType;
import java.util.Arrays;
import java.util.List;

/**

  • The type RestfulBookService
    *
  • @author Peter Pilgrim (peter)
    */
    @Path("/books")
    public class RestfulBookService {

private List<Book> products = Arrays.asList(
new Book("Sir Arthur Dolan Coyle", "Sherlock Holmes and the Hounds of the Baskerville"),
new Book("Dan Brown", "Da Vinci Code"),
new Book("Charles Dickens", "Great Expectations"),
new Book("Robert Louis Stevenson", "Treasure Island"));

@GET
@Produces(MediaType.TEXT_PLAIN)
public String getList() {
StringBuffer buf = new StringBuffer();
for (Book b: products) { buf.append(b.title); buf.append('\n'); }
return buf.toString();
}

@PostConstruct
public void acquireResource() { System.out.println( this.getClass().getSimpleName()+"#acquireResource()" ); }

@PreDestroy
public void releaseResource() { System.out.println( this.getClass().getSimpleName()+"#releaseResource()" ); }

static class Book {
public final String author;
public final String title;

Book(String author, String title) { this.author = author; this.title = title; }
}
}

// RestfulBookServiceTest.java
package je7hb.jaxrs.basic;

import je7hb.common.webcontainer.embedded.glassfish.SimpleEmbeddedRunner;
import org.jboss.shrinkwrap.api.ShrinkWrap;
import org.jboss.shrinkwrap.api.asset.EmptyAsset;
import org.jboss.shrinkwrap.api.spec.WebArchive;
import org.jboss.shrinkwrap.impl.base.exporter.zip.ZipExporterImpl;
import org.junit.Test;

import java.io.BufferedReader;
import java.io.File;
import java.io.InputStream;
import java.io.InputStreamReader;
import java.net.URL;
import java.util.ArrayList;
import java.util.List;

import static org.junit.Assert.*;

/**

  • Verifies the operation of the RestfulBookService
    *
  • @author Peter Pilgrim
    */
    public class RestfulBookServiceTest {

@Test
public void shouldAssembleAndRetrieveBookList() throws Exception {
WebArchive webArchive = ShrinkWrap.create(WebArchive.class, "test.war")
.addClasses(RestfulBookService.class)
.addAsWebInfResource(
EmptyAsset.INSTANCE, "beans.xml");

System.out.println(webArchive.toString(true));

File warFile = new File(webArchive.getName());
new ZipExporterImpl(webArchive).exportTo(warFile, true);
SimpleEmbeddedRunner runner =
SimpleEmbeddedRunner.launchDeployWarFile(
warFile, "mywebapp", 8080);
try {
URL url = new URL(
"http://localhost:8080/mywebapp/rest/books");
InputStream inputStream = url.openStream();
BufferedReader reader = new BufferedReader(
new InputStreamReader(inputStream));
List<String> lines = new ArrayList<>();
String text = null;
int count=0;
while ( ( text = reader.readLine()) != null ) { lines.add(text); ++count; System.out.printf("**** OUTPUT **** text[%d] = %s\n", count, text ); }
assertFalse( lines.isEmpty() );
assertEquals("Sherlock Holmes and the Hounds of the Baskerville", lines.get(0));
assertEquals("Da Vinci Code", lines.get(1));
assertEquals("Great Expectations", lines.get(2));
assertEquals( "Treasure Island", lines.get(3) );
}
finally { runner.stop(); }
}
}

// build.gradle
apply plugin: 'java'
apply plugin: 'war'
apply plugin: 'maven'
apply plugin: 'eclipse'
apply plugin: 'idea'

// Define equivalent Maven GAV coordinates.
group = 'com.javaeehandbook.book1'
archivesBaseName = 'ch08-jaxrs-basic'
version = '1.0'

repositories {
maven { url 'https://maven.java.net/content/groups/promoted' }
maven { url 'http://repository.jboss.org/nexus/content/groups/public' }
mavenCentral()
mavenLocal()
}

dependencies { providedCompile 'org.glassfish.main.extras:glassfish-embedded-all:4.0-b86' providedCompile 'javax:javaee-api:7.0-b86' providedCompile 'javax:javaee-web-api:7.0-b86' providedCompile 'com.javaeehandbook.book1:glassfish-embedded-runner:1.0' compile 'org.glassfish.main.extras:glassfish-embedded-all:4.0-b86' compile 'javax:javaee-api:7.0-b86' compile 'com.javaeehandbook.book1:glassfish-embedded-runner:1.0' compile 'org.jboss.shrinkwrap:shrinkwrap-api:1.0.1' compile 'org.jboss.shrinkwrap:shrinkwrap-impl-base:1.0.1' testCompile 'junit:junit:4.11' }

task wrapper(type: Wrapper) { gradleVersion = '1.5' }

// Override Gradle defaults - a force an exploded JAR view
sourceSets {
main { output.resourcesDir = 'build/classes/main' output.classesDir = 'build/classes/main' }
test { output.resourcesDir = 'build/classes/test' output.classesDir = 'build/classes/test' }
}

idea {
module { downloadSources = true }
}

Comment by mtaube [ 01/May/13 02:15 PM ]

I cannot resolve com.javaeehandbook.book1:glassfish-embedded-runner:1.0, could you pass along SimpleEmbeddedRunner.java as well?

Comment by peter_pilgrim [ 01/May/13 04:41 PM ]

Here are the Utility classes

// SimpleEmbeddedRunner.java
package je7hb.common.webcontainer.embedded.glassfish;

import java.io.File;
import java.util.Scanner;

/**

  • The type SimpleEmbeddedRunner
    *
  • @author Peter Pilgrim (peter)
    */
    public class SimpleEmbeddedRunner extends AbstractEmbeddedRunner {

/**

  • Default embedded server port number
    */
    public final static int DEFAULT_PORT=8080;

/**

  • Default pause time in milliseconds after deploying the war file
    */
    public static final long DEFAULT_PAUSE_TIME = 1000L;

public SimpleEmbeddedRunner(int port) { super(port); }

public static void launchDeployWarFileAndWait( String warFile, String webContext ) throws Exception { launchDeployWarFileAndWait(warFile, webContext, DEFAULT_PORT ); }

public static void launchDeployWarFileAndWait( String warFile, String webContext, int port ) throws Exception { launchDeployWarFileAndWait(new File(warFile), webContext, port, DEFAULT_PAUSE_TIME); }

public static void launchDeployWarFileAndWait( String warFile, String webContext, int port, long milliseconds ) throws Exception { launchDeployWarFileAndWait(new File(warFile), webContext, port, milliseconds); }

public static void launchDeployWarFileAndWait( File warFile, String webContext ) throws Exception { launchDeployWarFileAndWait(warFile, webContext, DEFAULT_PORT ); } }

public static void launchDeployWarFileAndWait( File warFile, String webContext, int port ) throws Exception { launchDeployWarFileAndWait(warFile, webContext, port, DEFAULT_PAUSE_TIME); }

public static void launchDeployWarFileAndWait( File warFile, String webContext, int port, long milliseconds ) throws Exception { SimpleEmbeddedRunner runner = (SimpleEmbeddedRunner)new SimpleEmbeddedRunner(port).init().start(); runner.deployWithRename(warFile, webContext); Thread.sleep(milliseconds); System.out.printf("**** Press the ENTER key to stop the server ****"); Scanner sc = new Scanner(System.in); while(!sc.nextLine().equals("")); runner.stop(); }

public static SimpleEmbeddedRunner launchDeployWarFile( File warFile, String webContext, int port ) throws Exception { SimpleEmbeddedRunner runner = (SimpleEmbeddedRunner)new SimpleEmbeddedRunner(port).init().start(); runner.deployWithRename(warFile, webContext); return runner; }
}

// AbstractEmbeddedRunner.java
package je7hb.common.webcontainer.embedded.glassfish;

import org.glassfish.embeddable.*;

import java.io.File;
import java.io.FileNotFoundException;
import java.io.IOException;
import java.util.ArrayList;
import java.util.Collection;
import java.util.List;
import java.util.Scanner;
import java.util.concurrent.atomic.AtomicBoolean;

/**

  • The type AbstractEmbeddedRunner
    *
  • @author Peter Pilgrim
    */
    public class AbstractEmbeddedRunner {

private int port;
private AtomicBoolean initialized = new AtomicBoolean();
private AtomicBoolean running = new AtomicBoolean();
private GlassFish glassfish;

public AbstractEmbeddedRunner(int port) { this.port = port; }

public AbstractEmbeddedRunner init() throws Exception{
if ( initialized.get() ) { throw new RuntimeException("runner was already initialized"); }

BootstrapProperties bootstrapProperties = new BootstrapProperties();
GlassFishRuntime glassfishRuntime = GlassFishRuntime.bootstrap(bootstrapProperties);

GlassFishProperties glassfishProperties = new GlassFishProperties();
glassfishProperties.setPort("http-listener", port);
// glassfishProperties.setPort("https-listener", port+1);
String [] paths = System.getProperty("java.class.path").split(File.pathSeparator);
for (int j=0; j<paths.length; ++j) { System.out.printf("classpath[%d] = %s\n", j, paths[j]); }

glassfish = glassfishRuntime.newGlassFish(glassfishProperties);
initialized.set(true);
return this;
}

private void check() {
if ( !initialized.get() ) { throw new RuntimeException("runner was not initialised"); }
}

public AbstractEmbeddedRunner start() throws Exception{ check(); glassfish.start(); running.set(true); return this; }

public AbstractEmbeddedRunner stop() throws Exception{ check(); glassfish.stop(); running.set(false); return this; }

public AbstractEmbeddedRunner deploy( String args[]) throws Exception{
Deployer deployer = glassfish.getDeployer();
for (String s: args) { File f = new File(s); sanityCheckFile(f); String application = deployer.deploy(f); System.out.printf("deploying "+application); }
return this;
}

/**

  • Deploy the WAR file and also override the web context name
  • @param warfile the war file path
  • @param newContext the web context name
  • @return embedded runner
  • @throws Exception
    */
    public AbstractEmbeddedRunner deployWithRename( String warfile, String newContext ) throws Exception{ return deployWithRename( new File(warfile), newContext ); }

/**

  • Deploy the WAR file and also override the web context name
  • @param warfile the war file
  • @param newContext the web context name
  • @return embedded runner
  • @throws Exception
    */
    public AbstractEmbeddedRunner deployWithRename( File warfile, String newContext ) throws Exception{ Deployer deployer = glassfish.getDeployer(); sanityCheckFile(warfile); deployer.deploy(warfile, "--name="+newContext, "--contextroot="+newContext, "--force=true"); return this; }

private void sanityCheckFile(File f) throws IOException {
if ( !f.exists() ) { throw new FileNotFoundException("The WAR file: ["+f.getPath()+"] does not exist."); }
if ( !f.canRead() ) { throw new IOException("The WAR file: ["+f.getPath()+"] is not readable."); }
if ( !f.isFile() ) { throw new IOException("The WAR file: ["+f.getPath()+"] is a regular file."); }
}

public AbstractEmbeddedRunner undeploy( String webContextName ) throws Exception {
Deployer deployer = glassfish.getDeployer();
Collection<String> deployedApplications = deployer.getDeployedApplications();
if ( deployedApplications.contains(webContextName)) { deployer.undeploy(webContextName); }
return this;
}

public AbstractEmbeddedRunner undeployAll() throws Exception {
Deployer deployer = glassfish.getDeployer();
for ( String s: deployer.getDeployedApplications()) { deployer.undeploy(s); }
return this;
}

public boolean isRunning() { return running.get(); }

public boolean isInitialized() { return initialized.get(); }

public List<String> getDeployments() throws GlassFishException {
List<String> deployments = new ArrayList<>();
Deployer deployer = glassfish.getDeployer();
for ( String s: deployer.getDeployedApplications()) { deployments.add(s); }
return deployments;
}
}

Comment by mtaube [ 01/May/13 08:25 PM ]

Running this against the latest trunk, I do not see any problems relating to javax.validation.

Here is the output of the test, from the validator initialization onward:

May 01, 2013 4:20:02 PM org.hibernate.validator.internal.util.Version <clinit>
INFO: HV000001: Hibernate Validator 5.0.0.Final
May 01, 2013 4:20:04 PM com.sun.enterprise.v3.services.impl.GrizzlyProxy start
INFO: Grizzly Framework 2.3.1 started in: 130ms - bound to [/0.0.0.0:8,085]
May 01, 2013 4:20:04 PM com.sun.enterprise.v3.services.impl.GrizzlyService createNetworkProxy
INFO: Network listener https-listener on port 0 disabled per domain.xml
May 01, 2013 4:20:04 PM com.sun.enterprise.v3.admin.adapter.AdminEndpointDecider setGuiContextRoot
INFO: Admin Console Adapter: context root: /admin
May 01, 2013 4:20:04 PM com.sun.enterprise.v3.admin.adapter.AdminEndpointDecider setGuiContextRoot
INFO: Admin Console Adapter: context root: /admin
May 01, 2013 4:20:04 PM com.sun.enterprise.v3.admin.adapter.AdminEndpointDecider setGuiContextRoot
INFO: Admin Console Adapter: context root: /admin
May 01, 2013 4:20:06 PM com.sun.enterprise.v3.server.AppServerStartup postStartupJob
INFO: Undefined Product Name - define product and version info in config/branding 0.0.0 (0) startup time : Embedded (9,427ms), startup services(3,624ms), total(13,051ms)
May 01, 2013 4:20:07 PM org.glassfish.jersey.server.ApplicationHandler initialize
INFO: Initiating Jersey application, version Jersey: 2.0-rc2 2013-04-23 12:04:25...
May 01, 2013 4:20:07 PM org.glassfish.admin.mbeanserver.JMXStartupService$JMXConnectorsStarterThread run
INFO: JMXStartupService has disabled JMXConnector system
May 01, 2013 4:20:08 PM com.sun.enterprise.connectors.jms.util.JmsRaUtil getInstalledMqVersion
WARNING: RAR7000 : Check for a new version of MQ installation failed : /var/folders/pl/fpwcfc_92dg7c5sgc5kgfhgc0000gn/T/gfembed4600368697654124458tmp/lib/install/applications/jmsra/../imqjmsra.rar (No such file or directory):/var/folders/pl/fpwcfc_92dg7c5sgc5kgfhgc0000gn/T/gfembed4600368697654124458tmp/lib/install/applications/jmsra/imqjmsra.rar
May 01, 2013 4:20:09 PM com.sun.enterprise.security.SecurityLifecycle <init>
INFO: security.secmgroff
May 01, 2013 4:20:09 PM com.sun.enterprise.security.SecurityLifecycle onInitialization
INFO: sec.service.startup.enter
May 01, 2013 4:20:09 PM com.sun.enterprise.security.PolicyLoader loadPolicy
INFO: policy.loading
May 01, 2013 4:20:10 PM com.sun.enterprise.security.auth.realm.Realm doInstantiate
INFO: realm.loaded.successfully
May 01, 2013 4:20:10 PM com.sun.enterprise.security.auth.realm.Realm doInstantiate
INFO: realm.loaded.successfully
May 01, 2013 4:20:10 PM com.sun.enterprise.security.auth.realm.Realm doInstantiate
INFO: realm.loaded.successfully
May 01, 2013 4:20:10 PM com.sun.enterprise.security.SecurityLifecycle onInitialization
INFO: sec.service.startup.exit
May 01, 2013 4:20:11 PM com.sun.enterprise.web.WebContainer createHttpListener
INFO: Created HTTP listener http-listener on host/port 0.0.0.0:8085
May 01, 2013 4:20:11 PM com.sun.enterprise.web.VirtualServer addProbes
SEVERE: Error adding HttpProbes. NetworkListener https-listeners GrizzlyProxy is NULL
May 01, 2013 4:20:11 PM com.sun.enterprise.web.WebContainer createHosts
INFO: Created virtual server server
May 01, 2013 4:20:12 PM org.apache.catalina.realm.JAASRealm setContainer
INFO: Setting JAAS app name glassfish-web
May 01, 2013 4:20:12 PM com.sun.enterprise.web.WebContainer loadSystemDefaultWebModules
INFO: Virtual server server loaded default web module
May 01, 2013 4:20:13 PM org.jboss.weld.bootstrap.WeldBootstrap <clinit>
INFO: WELD-000900 SNAPSHOT
May 01, 2013 4:20:15 PM com.sun.enterprise.v3.server.ApplicationLifecycle deploy
SEVERE: Exception during lifecycle processing
org.glassfish.deployment.common.DeploymentException: CDI definition failure:Exception List with 1 exceptions:
Exception 0 :
javax.enterprise.event.ObserverException
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:525)
at java.lang.Class.newInstance0(Class.java:372)
at java.lang.Class.newInstance(Class.java:325)
at org.jboss.weld.security.NewInstanceAction.run(NewInstanceAction.java:33)
at java.security.AccessController.doPrivileged(Native Method)
at org.jboss.weld.injection.Exceptions.rethrowException(Exceptions.java:37)
at org.jboss.weld.injection.Exceptions.rethrowException(Exceptions.java:75)
at org.jboss.weld.injection.MethodInjectionPoint.invokeOnInstanceWithSpecialValue(MethodInjectionPoint.java:101)
at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:274)
at org.jboss.weld.event.ExtensionObserverMethodImpl.sendEvent(ExtensionObserverMethodImpl.java:121)
at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:261)
at org.jboss.weld.event.ObserverMethodImpl.notify(ObserverMethodImpl.java:240)
at org.jboss.weld.event.ObserverNotifier.notifyObserver(ObserverNotifier.java:170)
at org.jboss.weld.event.ObserverNotifier.notifyObservers(ObserverNotifier.java:129)
at org.jboss.weld.event.ObserverNotifier.fireEvent(ObserverNotifier.java:103)
at org.jboss.weld.bootstrap.events.AbstractContainerEvent.fire(AbstractContainerEvent.java:63)
at org.jboss.weld.bootstrap.events.AbstractDefinitionContainerEvent.fire(AbstractDefinitionContainerEvent.java:35)
at org.jboss.weld.bootstrap.events.AfterBeanDiscoveryImpl.fire(AfterBeanDiscoveryImpl.java:53)
at org.jboss.weld.bootstrap.WeldBootstrap.deployBeans(WeldBootstrap.java:515)
at org.glassfish.weld.WeldDeployer.event(WeldDeployer.java:213)
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)
at org.glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java:491)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:527)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:523)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAs(Subject.java:356)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2.execute(CommandRunnerImpl.java:522)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:546)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1423)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1500(CommandRunnerImpl.java:108)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1762)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1674)
at com.sun.enterprise.admin.cli.embeddable.DeployerImpl.deploy(DeployerImpl.java:133)
at je7hb.common.webcontainer.embedded.glassfish.AbstractEmbeddedRunner.deployWithRename(AbstractEmbeddedRunner.java:104)
at je7hb.common.webcontainer.embedded.glassfish.SimpleEmbeddedRunner.launchDeployWarFile(SimpleEmbeddedRunner.java:59)
at je7hb.jaxrs.basic.RestfulBookServiceTest.shouldAssembleAndRetrieveBookList(RestfulBookServiceTest.java:39)
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.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
at org.junit.runner.JUnitCore.run(JUnitCore.java:160)
at com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:76)
at com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:195)
at com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:63)
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 com.intellij.rt.execution.application.AppMain.main(AppMain.java:120)
Caused by: java.lang.NoSuchMethodError: javax.enterprise.inject.spi.BeanManager.getInjectionTargetFactory(Ljavax/enterprise/inject/spi/AnnotatedType;)Ljavax/enterprise/inject/spi/InjectionTargetFactory;
at org.glassfish.jms.injection.JMSCDIExtension.createLocalBean(JMSCDIExtension.java:78)
at org.glassfish.jms.injection.JMSCDIExtension.afterBeanDiscovery(JMSCDIExtension.java:84)
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.jboss.weld.injection.MethodInjectionPoint.invokeOnInstanceWithSpecialValue(MethodInjectionPoint.java:93)
... 57 more

at org.glassfish.weld.WeldDeployer.event(WeldDeployer.java:225)
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)
at org.glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java:491)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:527)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:523)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAs(Subject.java:356)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2.execute(CommandRunnerImpl.java:522)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:546)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1423)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1500(CommandRunnerImpl.java:108)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1762)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1674)
at com.sun.enterprise.admin.cli.embeddable.DeployerImpl.deploy(DeployerImpl.java:133)
at je7hb.common.webcontainer.embedded.glassfish.AbstractEmbeddedRunner.deployWithRename(AbstractEmbeddedRunner.java:104)
at je7hb.common.webcontainer.embedded.glassfish.SimpleEmbeddedRunner.launchDeployWarFile(SimpleEmbeddedRunner.java:59)
at je7hb.jaxrs.basic.RestfulBookServiceTest.shouldAssembleAndRetrieveBookList(RestfulBookServiceTest.java:39)
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.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
at org.junit.runner.JUnitCore.run(JUnitCore.java:160)
at com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:76)
at com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:195)
at com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:63)
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 com.intellij.rt.execution.application.AppMain.main(AppMain.java:120)
Caused by: org.jboss.weld.exceptions.DefinitionException: Exception List with 1 exceptions:
Exception 0 :
javax.enterprise.event.ObserverException
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:525)
at java.lang.Class.newInstance0(Class.java:372)
at java.lang.Class.newInstance(Class.java:325)
at org.jboss.weld.security.NewInstanceAction.run(NewInstanceAction.java:33)
at java.security.AccessController.doPrivileged(Native Method)
at org.jboss.weld.injection.Exceptions.rethrowException(Exceptions.java:37)
at org.jboss.weld.injection.Exceptions.rethrowException(Exceptions.java:75)
at org.jboss.weld.injection.MethodInjectionPoint.invokeOnInstanceWithSpecialValue(MethodInjectionPoint.java:101)
at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:274)
at org.jboss.weld.event.ExtensionObserverMethodImpl.sendEvent(ExtensionObserverMethodImpl.java:121)
at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:261)
at org.jboss.weld.event.ObserverMethodImpl.notify(ObserverMethodImpl.java:240)
at org.jboss.weld.event.ObserverNotifier.notifyObserver(ObserverNotifier.java:170)
at org.jboss.weld.event.ObserverNotifier.notifyObservers(ObserverNotifier.java:129)
at org.jboss.weld.event.ObserverNotifier.fireEvent(ObserverNotifier.java:103)
at org.jboss.weld.bootstrap.events.AbstractContainerEvent.fire(AbstractContainerEvent.java:63)
at org.jboss.weld.bootstrap.events.AbstractDefinitionContainerEvent.fire(AbstractDefinitionContainerEvent.java:35)
at org.jboss.weld.bootstrap.events.AfterBeanDiscoveryImpl.fire(AfterBeanDiscoveryImpl.java:53)
at org.jboss.weld.bootstrap.WeldBootstrap.deployBeans(WeldBootstrap.java:515)
at org.glassfish.weld.WeldDeployer.event(WeldDeployer.java:213)
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)
at org.glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java:491)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:527)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:523)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAs(Subject.java:356)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2.execute(CommandRunnerImpl.java:522)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:546)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1423)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1500(CommandRunnerImpl.java:108)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1762)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1674)
at com.sun.enterprise.admin.cli.embeddable.DeployerImpl.deploy(DeployerImpl.java:133)
at je7hb.common.webcontainer.embedded.glassfish.AbstractEmbeddedRunner.deployWithRename(AbstractEmbeddedRunner.java:104)
at je7hb.common.webcontainer.embedded.glassfish.SimpleEmbeddedRunner.launchDeployWarFile(SimpleEmbeddedRunner.java:59)
at je7hb.jaxrs.basic.RestfulBookServiceTest.shouldAssembleAndRetrieveBookList(RestfulBookServiceTest.java:39)
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.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
at org.junit.runner.JUnitCore.run(JUnitCore.java:160)
at com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:76)
at com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:195)
at com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:63)
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 com.intellij.rt.execution.application.AppMain.main(AppMain.java:120)
Caused by: java.lang.NoSuchMethodError: javax.enterprise.inject.spi.BeanManager.getInjectionTargetFactory(Ljavax/enterprise/inject/spi/AnnotatedType;)Ljavax/enterprise/inject/spi/InjectionTargetFactory;
at org.glassfish.jms.injection.JMSCDIExtension.createLocalBean(JMSCDIExtension.java:78)
at org.glassfish.jms.injection.JMSCDIExtension.afterBeanDiscovery(JMSCDIExtension.java:84)
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.jboss.weld.injection.MethodInjectionPoint.invokeOnInstanceWithSpecialValue(MethodInjectionPoint.java:93)
... 57 more

at org.jboss.weld.bootstrap.events.AbstractDefinitionContainerEvent.fire(AbstractDefinitionContainerEvent.java:37)
at org.jboss.weld.bootstrap.events.AfterBeanDiscoveryImpl.fire(AfterBeanDiscoveryImpl.java:53)
at org.jboss.weld.bootstrap.WeldBootstrap.deployBeans(WeldBootstrap.java:515)
at org.glassfish.weld.WeldDeployer.event(WeldDeployer.java:213)
... 45 more

May 01, 2013 4:20:15 PM org.glassfish.api.ActionReport failure
SEVERE: Exception while loading the app
May 01, 2013 4:20:15 PM com.sun.enterprise.web.WebContainer unloadWebModule
SEVERE: Undeployment failed for context /mywebapp
May 01, 2013 4:20:15 PM org.glassfish.deployment.admin.DeployCommand execute
SEVERE: Exception while loading the app : CDI definition failure:Exception List with 1 exceptions:
Exception 0 :
javax.enterprise.event.ObserverException
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:525)
at java.lang.Class.newInstance0(Class.java:372)
at java.lang.Class.newInstance(Class.java:325)
at org.jboss.weld.security.NewInstanceAction.run(NewInstanceAction.java:33)
at java.security.AccessController.doPrivileged(Native Method)
at org.jboss.weld.injection.Exceptions.rethrowException(Exceptions.java:37)
at org.jboss.weld.injection.Exceptions.rethrowException(Exceptions.java:75)
at org.jboss.weld.injection.MethodInjectionPoint.invokeOnInstanceWithSpecialValue(MethodInjectionPoint.java:101)
at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:274)
at org.jboss.weld.event.ExtensionObserverMethodImpl.sendEvent(ExtensionObserverMethodImpl.java:121)
at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:261)
at org.jboss.weld.event.ObserverMethodImpl.notify(ObserverMethodImpl.java:240)
at org.jboss.weld.event.ObserverNotifier.notifyObserver(ObserverNotifier.java:170)
at org.jboss.weld.event.ObserverNotifier.notifyObservers(ObserverNotifier.java:129)
at org.jboss.weld.event.ObserverNotifier.fireEvent(ObserverNotifier.java:103)
at org.jboss.weld.bootstrap.events.AbstractContainerEvent.fire(AbstractContainerEvent.java:63)
at org.jboss.weld.bootstrap.events.AbstractDefinitionContainerEvent.fire(AbstractDefinitionContainerEvent.java:35)
at org.jboss.weld.bootstrap.events.AfterBeanDiscoveryImpl.fire(AfterBeanDiscoveryImpl.java:53)
at org.jboss.weld.bootstrap.WeldBootstrap.deployBeans(WeldBootstrap.java:515)
at org.glassfish.weld.WeldDeployer.event(WeldDeployer.java:213)
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)
at org.glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java:491)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:527)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:523)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAs(Subject.java:356)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2.execute(CommandRunnerImpl.java:522)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:546)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1423)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1500(CommandRunnerImpl.java:108)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1762)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1674)
at com.sun.enterprise.admin.cli.embeddable.DeployerImpl.deploy(DeployerImpl.java:133)
at je7hb.common.webcontainer.embedded.glassfish.AbstractEmbeddedRunner.deployWithRename(AbstractEmbeddedRunner.java:104)
at je7hb.common.webcontainer.embedded.glassfish.SimpleEmbeddedRunner.launchDeployWarFile(SimpleEmbeddedRunner.java:59)
at je7hb.jaxrs.basic.RestfulBookServiceTest.shouldAssembleAndRetrieveBookList(RestfulBookServiceTest.java:39)
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.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
at org.junit.runner.JUnitCore.run(JUnitCore.java:160)
at com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:76)
at com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:195)
at com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:63)
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 com.intellij.rt.execution.application.AppMain.main(AppMain.java:120)
Caused by: java.lang.NoSuchMethodError: javax.enterprise.inject.spi.BeanManager.getInjectionTargetFactory(Ljavax/enterprise/inject/spi/AnnotatedType;)Ljavax/enterprise/inject/spi/InjectionTargetFactory;
at org.glassfish.jms.injection.JMSCDIExtension.createLocalBean(JMSCDIExtension.java:78)
at org.glassfish.jms.injection.JMSCDIExtension.afterBeanDiscovery(JMSCDIExtension.java:84)
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.jboss.weld.injection.MethodInjectionPoint.invokeOnInstanceWithSpecialValue(MethodInjectionPoint.java:93)
... 57 more

org.jboss.weld.exceptions.DefinitionException: Exception List with 1 exceptions:
Exception 0 :
javax.enterprise.event.ObserverException
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:525)
at java.lang.Class.newInstance0(Class.java:372)
at java.lang.Class.newInstance(Class.java:325)
at org.jboss.weld.security.NewInstanceAction.run(NewInstanceAction.java:33)
at java.security.AccessController.doPrivileged(Native Method)
at org.jboss.weld.injection.Exceptions.rethrowException(Exceptions.java:37)
at org.jboss.weld.injection.Exceptions.rethrowException(Exceptions.java:75)
at org.jboss.weld.injection.MethodInjectionPoint.invokeOnInstanceWithSpecialValue(MethodInjectionPoint.java:101)
at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:274)
at org.jboss.weld.event.ExtensionObserverMethodImpl.sendEvent(ExtensionObserverMethodImpl.java:121)
at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:261)
at org.jboss.weld.event.ObserverMethodImpl.notify(ObserverMethodImpl.java:240)
at org.jboss.weld.event.ObserverNotifier.notifyObserver(ObserverNotifier.java:170)
at org.jboss.weld.event.ObserverNotifier.notifyObservers(ObserverNotifier.java:129)
at org.jboss.weld.event.ObserverNotifier.fireEvent(ObserverNotifier.java:103)
at org.jboss.weld.bootstrap.events.AbstractContainerEvent.fire(AbstractContainerEvent.java:63)
at org.jboss.weld.bootstrap.events.AbstractDefinitionContainerEvent.fire(AbstractDefinitionContainerEvent.java:35)
at org.jboss.weld.bootstrap.events.AfterBeanDiscoveryImpl.fire(AfterBeanDiscoveryImpl.java:53)
at org.jboss.weld.bootstrap.WeldBootstrap.deployBeans(WeldBootstrap.java:515)
at org.glassfish.weld.WeldDeployer.event(WeldDeployer.java:213)
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)
at org.glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java:491)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:527)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:523)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAs(Subject.java:356)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2.execute(CommandRunnerImpl.java:522)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:546)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1423)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1500(CommandRunnerImpl.java:108)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1762)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1674)
at com.sun.enterprise.admin.cli.embeddable.DeployerImpl.deploy(DeployerImpl.java:133)
at je7hb.common.webcontainer.embedded.glassfish.AbstractEmbeddedRunner.deployWithRename(AbstractEmbeddedRunner.java:104)
at je7hb.common.webcontainer.embedded.glassfish.SimpleEmbeddedRunner.launchDeployWarFile(SimpleEmbeddedRunner.java:59)
at je7hb.jaxrs.basic.RestfulBookServiceTest.shouldAssembleAndRetrieveBookList(RestfulBookServiceTest.java:39)
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.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
at org.junit.runner.JUnitCore.run(JUnitCore.java:160)
at com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:76)
at com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:195)
at com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:63)
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 com.intellij.rt.execution.application.AppMain.main(AppMain.java:120)
Caused by: java.lang.NoSuchMethodError: javax.enterprise.inject.spi.BeanManager.getInjectionTargetFactory(Ljavax/enterprise/inject/spi/AnnotatedType;)Ljavax/enterprise/inject/spi/InjectionTargetFactory;
at org.glassfish.jms.injection.JMSCDIExtension.createLocalBean(JMSCDIExtension.java:78)
at org.glassfish.jms.injection.JMSCDIExtension.afterBeanDiscovery(JMSCDIExtension.java:84)
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.jboss.weld.injection.MethodInjectionPoint.invokeOnInstanceWithSpecialValue(MethodInjectionPoint.java:93)
... 57 more

at org.jboss.weld.bootstrap.events.AbstractDefinitionContainerEvent.fire(AbstractDefinitionContainerEvent.java:37)
at org.jboss.weld.bootstrap.events.AfterBeanDiscoveryImpl.fire(AfterBeanDiscoveryImpl.java:53)
at org.jboss.weld.bootstrap.WeldBootstrap.deployBeans(WeldBootstrap.java:515)
at org.glassfish.weld.WeldDeployer.event(WeldDeployer.java:213)
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)
at org.glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java:491)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:527)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:523)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAs(Subject.java:356)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2.execute(CommandRunnerImpl.java:522)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:546)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1423)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1500(CommandRunnerImpl.java:108)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1762)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1674)
at com.sun.enterprise.admin.cli.embeddable.DeployerImpl.deploy(DeployerImpl.java:133)
at je7hb.common.webcontainer.embedded.glassfish.AbstractEmbeddedRunner.deployWithRename(AbstractEmbeddedRunner.java:104)
at je7hb.common.webcontainer.embedded.glassfish.SimpleEmbeddedRunner.launchDeployWarFile(SimpleEmbeddedRunner.java:59)
at je7hb.jaxrs.basic.RestfulBookServiceTest.shouldAssembleAndRetrieveBookList(RestfulBookServiceTest.java:39)
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.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
at org.junit.runner.JUnitCore.run(JUnitCore.java:160)
at com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:76)
at com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:195)
at com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:63)
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 com.intellij.rt.execution.application.AppMain.main(AppMain.java:120)

JdbcRuntimeExtension, getAllSystemRAResourcesAndPools = [GlassFishConfigBean.org.glassfish.jdbc.config.JdbcResource, GlassFishConfigBean.org.glassfish.jdbc.config.JdbcResource, GlassFishConfigBean.org.glassfish.jdbc.config.JdbcConnectionPool, GlassFishConfigBean.org.glassfish.jdbc.config.JdbcConnectionPool]

java.io.IOException: Server returned HTTP response code: 502 for URL: http://localhost:8085/mywebapp/rest/books
at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1612)
at java.net.URL.openStream(URL.java:1035)
at je7hb.jaxrs.basic.RestfulBookServiceTest.shouldAssembleAndRetrieveBookList(RestfulBookServiceTest.java:45)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
at org.junit.runner.JUnitCore.run(JUnitCore.java:160)
at com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:76)
at com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:195)
at com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:63)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at com.intellij.rt.execution.application.AppMain.main(AppMain.java:120)

May 01, 2013 4:20:16 PM org.glassfish.admin.mbeanserver.JMXStartupService shutdown
INFO: JMXStartupService and JMXConnectors have been shut down.
May 01, 2013 4:20:17 PM com.sun.enterprise.v3.server.AppServerStartup stop
INFO: Shutdown procedure finished

Comment by peter_pilgrim [ 01/May/13 10:57 PM ]

This is weird. Now the JAX-RS example will not deploy and therefore the unit test fails. There is no requirement on CDI 1.1 in these examples and yet that it is what is failing in the output above.

Are you running with Gradle 1.5? I saw this in the IntelliJ orginally and reproduced the error from the command line with gradle e.g

$ gradle -Dtest.single=RestfulBookServiceTest test --info

I have bad suspicion that this could be class path ordering thing.
And if you say that the Hibernate Validation JAR are already set up for Embedded Glassfish 4.0 b86 then I do not know what else it can be. Something could be wrong with class path?

// build.gradle
apply plugin: 'java'
apply plugin: 'war'
apply plugin: 'maven'
apply plugin: 'eclipse'
apply plugin: 'idea'

// Define equivalent Maven GAV coordinates.
group = 'com.javaeehandbook.book1'
archivesBaseName = 'ch08-jaxrs-basic'
version = '1.0'

repositories {
maven { url 'https://maven.java.net/content/groups/promoted' }
maven { url 'http://repository.jboss.org/nexus/content/groups/public' }
mavenCentral()
mavenLocal()
}

dependencies { providedCompile 'org.glassfish.main.extras:glassfish-embedded-all:4.0-b86' providedCompile 'javax:javaee-api:7.0-b86' providedCompile 'javax:javaee-web-api:7.0-b86' providedCompile 'com.javaeehandbook.book1:glassfish-embedded-runner:1.0' compile 'org.glassfish.main.extras:glassfish-embedded-all:4.0-b86' compile 'javax:javaee-api:7.0-b86' compile 'com.javaeehandbook.book1:glassfish-embedded-runner:1.0' compile 'org.jboss.shrinkwrap:shrinkwrap-api:1.0.1' compile 'org.jboss.shrinkwrap:shrinkwrap-impl-base:1.0.1' testCompile 'junit:junit:4.11' }

task wrapper(type: Wrapper) { gradleVersion = '1.5' }

// Override Gradle defaults - a force an exploded JAR view
sourceSets {
main { output.resourcesDir = 'build/classes/main' output.classesDir = 'build/classes/main' }
test { output.resourcesDir = 'build/classes/test' output.classesDir = 'build/classes/test' }
}

Here is the exact output from running the Gradle build against -b86.

C:\Users\peter\Documents\IdeaProjects\javaee7-handbook\ch08\jaxrs-basic>gradle -Dtest.single=RestfulBookServiceTest test --info
Starting Build
Settings evaluated using empty settings script.
Projects loaded. Root project using build file 'C:\Users\peter\Documents\IdeaProjects\javaee7-handbook\ch08\jaxrs-basic\build.gradle'.
Included projects: [root project 'jaxrs-basic']
Evaluating root project 'jaxrs-basic' using build file 'C:\Users\peter\Documents\IdeaProjects\javaee7-handbook\ch08\jaxrs-basic\build.gradle'.
All projects evaluated.
Selected primary task 'test'
Tasks to be executed: [task ':compileJava', task ':processResources', task ':classes', task ':compileTestJava', task ':processTestResources', task ':testClasses', task ':test']
:compileJava
:: loading settings :: url = jar:file:/C:/opt/gradle-1.5/lib/ivy-2.2.0.jar!/org/apache/ivy/core/settings/ivysettings.xml
Skipping task ':compileJava' as it is up-to-date.
Skipping task ':compileJava' as it is up-to-date
:compileJava UP-TO-DATE
:processResources
Skipping task ':processResources' as it is up-to-date.
Skipping task ':processResources' as it is up-to-date
:processResources UP-TO-DATE
:classes
Skipping task ':classes' as it has no actions.
:classes UP-TO-DATE
:compileTestJava
Skipping task ':compileTestJava' as it is up-to-date.
Skipping task ':compileTestJava' as it is up-to-date
:compileTestJava UP-TO-DATE
:processTestResources
Skipping task ':processTestResources' as it has no source files.
:processTestResources UP-TO-DATE
:testClasses
Skipping task ':testClasses' as it has no actions.
:testClasses UP-TO-DATE
:test
Executing task ':test' due to:
No history is available for task ':test'.
Running single tests with pattern: [**/RestfulBookServiceTest*.class]
Starting process 'Gradle Worker 1'. Working directory: C:\Users\peter\Documents\IdeaProjects\javaee7-handbook\ch08\jaxrs-basic Command: C:\Program Files\Java\jdk1.7.0_17\bin\java.exe -Djava.security.manager=jarjar.org.gradle.process.internal.child.Bootstra
pSecurityManager -Dfile.encoding=windows-1252 -ea -cp C:\Users\peter\.gradle\caches\1.5\workerMain\gradle-worker.jar jarjar.org.gradle.process.internal.launcher.GradleWorkerMain
An attempt to initialize for well behaving parent process finished.
Successfully started process 'Gradle Worker 1'
Gradle Worker 1 executing tests.

je7hb.jaxrs.basic.RestfulBookServiceTest > shouldAssembleAndRetrieveBookList STANDARD_OUT
test.war:
/WEB-INF/
/WEB-INF/beans.xml
/WEB-INF/web.xml
/WEB-INF/classes/
/WEB-INF/classes/je7hb/
/WEB-INF/classes/je7hb/jaxrs/
/WEB-INF/classes/je7hb/jaxrs/basic/
/WEB-INF/classes/je7hb/jaxrs/basic/SimpleServlet.class
/WEB-INF/classes/je7hb/jaxrs/basic/RestfulBookService.class
/WEB-INF/classes/je7hb/jaxrs/basic/RestfulBookService$Book.class
classpath[0] = C:\Users\peter\Documents\IdeaProjects\javaee7-handbook\ch08\jaxrs-basic\build\classes\test
classpath[1] = C:\Users\peter\Documents\IdeaProjects\javaee7-handbook\ch08\jaxrs-basic\build\classes\main
classpath[2] = C:\Users\peter\.gradle\caches\artifacts-23\filestore\org.glassfish.main.extras\glassfish-embedded-all\4.0-b86\jar\38b7a3ec6b8e4abd3a6ecaa6250db9a2275862da\glassfish-embedded-all-4.0-b86.jar
classpath[3] = C:\Users\peter\.gradle\caches\artifacts-23\filestore\javax\javaee-api\7.0-b86\jar\bac7671c884f183e8d2c174b1f1fecd746a2f514\javaee-api-7.0-b86.jar
classpath[4] = C:\Users\peter\.m2\repository\com\javaeehandbook\book1\glassfish-embedded-runner\1.0\glassfish-embedded-runner-1.0.jar
classpath[5] = C:\Users\peter\.gradle\caches\artifacts-23\filestore\org.jboss.shrinkwrap\shrinkwrap-api\1.0.1\jar\83ee2ca1702d79ceda73634e33b0fac8e73acced\shrinkwrap-api-1.0.1.jar
classpath[6] = C:\Users\peter\.gradle\caches\artifacts-23\filestore\org.jboss.shrinkwrap\shrinkwrap-impl-base\1.0.1\jar\feb8c9e875222fae065b4c81937797b00c7ff347\shrinkwrap-impl-base-1.0.1.jar
classpath[7] = C:\Users\peter\.gradle\caches\artifacts-23\filestore\javax\javaee-web-api\7.0-b86\jar\7fa02cd22bac4d0ec5be6211df9960dfcbae171a\javaee-web-api-7.0-b86.jar
classpath[8] = C:\Users\peter\.gradle\caches\artifacts-23\filestore\junit\junit\4.11\jar\4e031bb61df09069aeb2bffb4019e7a5034a4ee0\junit-4.11.jar
classpath[9] = C:\Users\peter\.gradle\caches\artifacts-23\filestore\javax.activation\activation\1.1\jar\e6cb541461c2834bdea3eb920f1884d1eb508b50\activation-1.1.jar
classpath[10] = C:\Users\peter\.gradle\caches\artifacts-23\filestore\com.sun.mail\javax.mail\1.5.0\jar\ec2410fdf7e0a3022e7c2a2e6241039d1abc1e98\javax.mail-1.5.0.jar
classpath[11] = C:\Users\peter\.gradle\caches\artifacts-23\filestore\org.jboss.shrinkwrap\shrinkwrap-spi\1.0.1\jar\4bcb163157366c0f690362594dfa4baed67a6152\shrinkwrap-spi-1.0.1.jar
classpath[12] = C:\Users\peter\.gradle\caches\artifacts-23\filestore\org.hamcrest\hamcrest-core\1.3\jar\42a25dc3219429f0e5d060061f71acb49bf010a0\hamcrest-core-1.3.jar
Found populator: org.glassfish.kernel.embedded.EmbeddedDomainXml

je7hb.jaxrs.basic.RestfulBookServiceTest > shouldAssembleAndRetrieveBookList STANDARD_ERROR
May 01, 2013 11:47:30 PM org.glassfish.security.services.impl.authorization.AuthorizationServiceImpl initialize
INFO: Authorization Service has successfully initialized.
May 01, 2013 11:47:30 PM org.hibernate.validator.internal.util.Version <clinit>
INFO: HV000001: Hibernate Validator 5.0.0.Final
May 01, 2013 11:47:30 PM com.sun.enterprise.v3.services.impl.GrizzlyProxy start
INFO: Grizzly Framework 2.3.1 started in: 13ms - bound to [/0.0.0.0:8,080]
May 01, 2013 11:47:30 PM com.sun.enterprise.v3.services.impl.GrizzlyService createNetworkProxy
INFO: Network listener https-listener on port 0 disabled per domain.xml
May 01, 2013 11:47:30 PM com.sun.enterprise.v3.admin.adapter.AdminEndpointDecider setGuiContextRoot
INFO: Admin Console Adapter: context root: /admin
May 01, 2013 11:47:30 PM com.sun.enterprise.v3.admin.adapter.AdminEndpointDecider setGuiContextRoot
INFO: Admin Console Adapter: context root: /admin
May 01, 2013 11:47:30 PM com.sun.enterprise.v3.admin.adapter.AdminEndpointDecider setGuiContextRoot
INFO: Admin Console Adapter: context root: /admin
May 01, 2013 11:47:31 PM com.sun.enterprise.v3.server.AppServerStartup postStartupJob
INFO: Undefined Product Name - define product and version info in config/branding 0.0.0 (0) startup time : Embedded (3,177ms), startup services(836ms), total(4,013ms)
May 01, 2013 11:47:31 PM org.glassfish.jersey.server.ApplicationHandler initialize
INFO: Initiating Jersey application, version Jersey: 2.0-rc2 2013-04-23 12:04:25...
May 01, 2013 11:47:31 PM org.glassfish.admin.mbeanserver.JMXStartupService$JMXConnectorsStarterThread run
INFO: JMXStartupService has disabled JMXConnector system
May 01, 2013 11:47:31 PM com.sun.enterprise.connectors.jms.util.JmsRaUtil getInstalledMqVersion
WARNING: RAR7000 : Check for a new version of MQ installation failed : C:\Users\peter\AppData\Local\Temp\gfembed9033409685331329967tmp\lib\install\applications\jmsra\..\imqjmsra.rar (The system cannot find the file specified):C:\Users\peter\AppData\Loc
al\Temp\gfembed9033409685331329967tmp\lib\install\applications\jmsra\imqjmsra.rar
May 01, 2013 11:47:31 PM com.sun.enterprise.security.SecurityLifecycle <init>
INFO: security.secmgroff
May 01, 2013 11:47:31 PM com.sun.enterprise.security.SecurityLifecycle onInitialization
INFO: sec.service.startup.enter
May 01, 2013 11:47:31 PM com.sun.enterprise.security.PolicyLoader loadPolicy
INFO: policy.loading
May 01, 2013 11:47:31 PM com.sun.enterprise.security.auth.realm.Realm doInstantiate
INFO: realm.loaded.successfully
May 01, 2013 11:47:31 PM com.sun.enterprise.security.auth.realm.Realm doInstantiate
INFO: realm.loaded.successfully
May 01, 2013 11:47:31 PM com.sun.enterprise.security.auth.realm.Realm doInstantiate
INFO: realm.loaded.successfully
May 01, 2013 11:47:31 PM com.sun.enterprise.security.SecurityLifecycle onInitialization
INFO: sec.service.startup.exit
May 01, 2013 11:47:32 PM com.sun.enterprise.web.WebContainer createHttpListener
INFO: Created HTTP listener http-listener on host/port 0.0.0.0:8080
May 01, 2013 11:47:32 PM com.sun.enterprise.web.VirtualServer addProbes
SEVERE: Error adding HttpProbes. NetworkListener https-listeners GrizzlyProxy is NULL
May 01, 2013 11:47:32 PM com.sun.enterprise.web.WebContainer createHosts
INFO: Created virtual server server
May 01, 2013 11:47:32 PM org.apache.catalina.realm.JAASRealm setContainer
INFO: Setting JAAS app name glassfish-web
May 01, 2013 11:47:32 PM com.sun.enterprise.web.WebContainer loadSystemDefaultWebModules
INFO: Virtual server server loaded default web module
May 01, 2013 11:47:32 PM org.jboss.weld.bootstrap.WeldBootstrap <clinit>
INFO: WELD-000900 SNAPSHOT
May 01, 2013 11:47:33 PM org.jboss.weld.bootstrap.Validator validateCustomBean
WARNING: WELD-001473 javax.enterprise.inject.spi.Bean implementation org.glassfish.jms.injection.JMSCDIExtension$LocalBean@4dac2b20 declared a normal scope but does not implement javax.enterprise.inject.spi.PassivationCapable. It won't be possible to i
nject this bean into a bean with passivating scope (@SessionScoped, @ConversationScoped). This can be fixed by assigning the Bean implementation a unique id by implementing the PassivationCapable interface.
May 01, 2013 11:47:33 PM org.glassfish.jersey.servlet.init.JerseyServletContainerInitializer addServletWithDefaultConfiguration
INFO: Registering the Jersey servlet application, named javax.ws.rs.core.Application, with the following root resource and provider classes: [class je7hb.jaxrs.basic.RestfulBookService]
May 01, 2013 11:47:33 PM org.glassfish.jersey.server.ApplicationHandler initialize
INFO: Initiating Jersey application, version Jersey: 2.0-rc2 2013-04-23 12:04:25...
May 01, 2013 11:47:33 PM org.apache.catalina.core.StandardContext log
SEVERE: WebModule[/mywebapp]StandardWrapper.Throwable
java.lang.NoClassDefFoundError: org/glassfish/json/jaxrs/JsonStructureBodyReader
at org.glassfish.jersey.jsonp.JsonProcessingFeature.configure(JsonProcessingFeature.java:66)
at org.glassfish.jersey.model.internal.CommonConfig.configureFeatures(CommonConfig.java:617)
at org.glassfish.jersey.model.internal.CommonConfig.configureMetaProviders(CommonConfig.java:558)
at org.glassfish.jersey.server.ResourceConfig.configureMetaProviders(ResourceConfig.java:768)
at org.glassfish.jersey.server.ApplicationHandler.initialize(ApplicationHandler.java:341)
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.load(StandardWrapper.java:1382)
at org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java:5670)
at org.apache.catalina.core.StandardContext.start(StandardContext.java:5912)
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:2278)
at com.sun.enterprise.web.WebContainer.loadWebModule(WebContainer.java:1924)
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:497)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:219)
at org.glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java:491)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:527)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:523)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAs(Subject.java:356)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2.execute(CommandRunnerImpl.java:522)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:546)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1423)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1500(CommandRunnerImpl.java:108)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1762)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1674)
at com.sun.enterprise.admin.cli.embeddable.DeployerImpl.deploy(DeployerImpl.java:133)
at je7hb.common.webcontainer.embedded.glassfish.AbstractEmbeddedRunner.deployWithRename(AbstractEmbeddedRunner.java:103)
at je7hb.common.webcontainer.embedded.glassfish.SimpleEmbeddedRunner.launchDeployWarFile(SimpleEmbeddedRunner.java:59)
at je7hb.jaxrs.basic.RestfulBookServiceTest.shouldAssembleAndRetrieveBookList(RestfulBookServiceTest.java:39)
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.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
Gradle Worker 1 finished executing tests.
at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
at org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.runTestClass(JUnitTestClassExecuter.java:55)
at org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.execute(JUnitTestClassExecuter.java:42)
at org.gradle.api.internal.tasks.testing.junit.JUnitTestClassProcessor.processTestClass(JUnitTestClassProcessor.java:71)
at org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:49)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
Process 'Gradle Worker 1' finished with exit value 0 (state: SUCCEEDED)
at java.lang.reflect.Method.invoke(Method.java:601)
at org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
at org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
at org.gradle.messaging.dispatch.ContextClassLoaderDispatch.dispatch(ContextClassLoaderDispatch.java:32)
at org.gradle.messaging.dispatch.ProxyDispatchAdapter$DispatchingInvocationHandler.invoke(ProxyDispatchAdapter.java:93)
at com.sun.proxy.$Proxy2.processTestClass(Unknown Source)
at org.gradle.api.internal.tasks.testing.worker.TestWorker.processTestClass(TestWorker.java:103)
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.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
at org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
at org.gradle.messaging.remote.internal.hub.MessageHub$Handler.run(MessageHub.java:355)
at org.gradle.internal.concurrent.DefaultExecutorFactory$StoppableExecutorImpl$1.run(DefaultExecutorFactory.java:66)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:722)

May 01, 2013 11:47:33 PM org.apache.catalina.core.StandardContext log
SEVERE: WebModule[/mywebapp]Servlet /mywebapp threw load() exception
java.lang.NoClassDefFoundError: org/glassfish/json/jaxrs/JsonStructureBodyReader
at org.glassfish.jersey.jsonp.JsonProcessingFeature.configure(JsonProcessingFeature.java:66)
at org.glassfish.jersey.model.internal.CommonConfig.configureFeatures(CommonConfig.java:617)
at org.glassfish.jersey.model.internal.CommonConfig.configureMetaProviders(CommonConfig.java:558)
at org.glassfish.jersey.server.ResourceConfig.configureMetaProviders(ResourceConfig.java:768)
at org.glassfish.jersey.server.ApplicationHandler.initialize(ApplicationHandler.java:341)
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.load(StandardWrapper.java:1382)
at org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java:5670)
at org.apache.catalina.core.StandardContext.start(StandardContext.java:5912)
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:2278)
at com.sun.enterprise.web.WebContainer.loadWebModule(WebContainer.java:1924)
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:497)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:219)
at org.glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java:491)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:527)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:523)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAs(Subject.java:356)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2.execute(CommandRunnerImpl.java:522)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:546)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1423)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1500(CommandRunnerImpl.java:108)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1762)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1674)
at com.sun.enterprise.admin.cli.embeddable.DeployerImpl.deploy(DeployerImpl.java:133)
at je7hb.common.webcontainer.embedded.glassfish.AbstractEmbeddedRunner.deployWithRename(AbstractEmbeddedRunner.java:103)
at je7hb.common.webcontainer.embedded.glassfish.SimpleEmbeddedRunner.launchDeployWarFile(SimpleEmbeddedRunner.java:59)
at je7hb.jaxrs.basic.RestfulBookServiceTest.shouldAssembleAndRetrieveBookList(RestfulBookServiceTest.java:39)
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.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
at org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.runTestClass(JUnitTestClassExecuter.java:55)
at org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.execute(JUnitTestClassExecuter.java:42)
at org.gradle.api.internal.tasks.testing.junit.JUnitTestClassProcessor.processTestClass(JUnitTestClassProcessor.java:71)
at org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:49)
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.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
at org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
at org.gradle.messaging.dispatch.ContextClassLoaderDispatch.dispatch(ContextClassLoaderDispatch.java:32)
at org.gradle.messaging.dispatch.ProxyDispatchAdapter$DispatchingInvocationHandler.invoke(ProxyDispatchAdapter.java:93)
at com.sun.proxy.$Proxy2.processTestClass(Unknown Source)
at org.gradle.api.internal.tasks.testing.worker.TestWorker.processTestClass(TestWorker.java:103)
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.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
at org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
at org.gradle.messaging.remote.internal.hub.MessageHub$Handler.run(MessageHub.java:355)
at org.gradle.internal.concurrent.DefaultExecutorFactory$StoppableExecutorImpl$1.run(DefaultExecutorFactory.java:66)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:722)

May 01, 2013 11:47:33 PM org.apache.catalina.core.StandardContext start
SEVERE: Startup of context /mywebapp failed due to previous errors
May 01, 2013 11:47:33 PM org.apache.catalina.core.ContainerBase addChildInternal
SEVERE: ContainerBase.addChild: start:
org.apache.catalina.LifecycleException: org.apache.catalina.LifecycleException: java.lang.NoClassDefFoundError: org/glassfish/json/jaxrs/JsonStructureBodyReader
at org.apache.catalina.core.StandardContext.start(StandardContext.java:5920)
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:2278)
at com.sun.enterprise.web.WebContainer.loadWebModule(WebContainer.java:1924)
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:497)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:219)
at org.glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java:491)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:527)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:523)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAs(Subject.java:356)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2.execute(CommandRunnerImpl.java:522)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:546)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1423)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1500(CommandRunnerImpl.java:108)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1762)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1674)
at com.sun.enterprise.admin.cli.embeddable.DeployerImpl.deploy(DeployerImpl.java:133)
at je7hb.common.webcontainer.embedded.glassfish.AbstractEmbeddedRunner.deployWithRename(AbstractEmbeddedRunner.java:103)
at je7hb.common.webcontainer.embedded.glassfish.SimpleEmbeddedRunner.launchDeployWarFile(SimpleEmbeddedRunner.java:59)
at je7hb.jaxrs.basic.RestfulBookServiceTest.shouldAssembleAndRetrieveBookList(RestfulBookServiceTest.java:39)
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.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
at org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.runTestClass(JUnitTestClassExecuter.java:55)
at org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.execute(JUnitTestClassExecuter.java:42)
at org.gradle.api.internal.tasks.testing.junit.JUnitTestClassProcessor.processTestClass(JUnitTestClassProcessor.java:71)
at org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:49)
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.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
at org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
at org.gradle.messaging.dispatch.ContextClassLoaderDispatch.dispatch(ContextClassLoaderDispatch.java:32)
at org.gradle.messaging.dispatch.ProxyDispatchAdapter$DispatchingInvocationHandler.invoke(ProxyDispatchAdapter.java:93)
at com.sun.proxy.$Proxy2.processTestClass(Unknown Source)
at org.gradle.api.internal.tasks.testing.worker.TestWorker.processTestClass(TestWorker.java:103)
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.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
at org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
at org.gradle.messaging.remote.internal.hub.MessageHub$Handler.run(MessageHub.java:355)
at org.gradle.internal.concurrent.DefaultExecutorFactory$StoppableExecutorImpl$1.run(DefaultExecutorFactory.java:66)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:722)
Caused by: org.apache.catalina.LifecycleException: java.lang.NoClassDefFoundError: org/glassfish/json/jaxrs/JsonStructureBodyReader
at org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java:5678)
at org.apache.catalina.core.StandardContext.start(StandardContext.java:5912)
... 69 more
Caused by: java.lang.NoClassDefFoundError: org/glassfish/json/jaxrs/JsonStructureBodyReader
at org.glassfish.jersey.jsonp.JsonProcessingFeature.configure(JsonProcessingFeature.java:66)
at org.glassfish.jersey.model.internal.CommonConfig.configureFeatures(CommonConfig.java:617)
at org.glassfish.jersey.model.internal.CommonConfig.configureMetaProviders(CommonConfig.java:558)
at org.glassfish.jersey.server.ResourceConfig.configureMetaProviders(ResourceConfig.java:768)
at org.glassfish.jersey.server.ApplicationHandler.initialize(ApplicationHandler.java:341)
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.load(StandardWrapper.java:1382)
at org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java:5670)
... 70 more

May 01, 2013 11:47:33 PM com.sun.enterprise.web.WebApplication start
WARNING: java.lang.IllegalStateException: ContainerBase.addChild: start: org.apache.catalina.LifecycleException: org.apache.catalina.LifecycleException: java.lang.NoClassDefFoundError: org/glassfish/json/jaxrs/JsonStructureBodyReader
java.lang.IllegalStateException: ContainerBase.addChild: start: org.apache.catalina.LifecycleException: org.apache.catalina.LifecycleException: java.lang.NoClassDefFoundError: org/glassfish/json/jaxrs/JsonStructureBodyReader
at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:1044)
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:2278)
at com.sun.enterprise.web.WebContainer.loadWebModule(WebContainer.java:1924)
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:497)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:219)
at org.glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java:491)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:527)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:523)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAs(Subject.java:356)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2.execute(CommandRunnerImpl.java:522)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:546)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1423)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1500(CommandRunnerImpl.java:108)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1762)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1674)
at com.sun.enterprise.admin.cli.embeddable.DeployerImpl.deploy(DeployerImpl.java:133)
at je7hb.common.webcontainer.embedded.glassfish.AbstractEmbeddedRunner.deployWithRename(AbstractEmbeddedRunner.java:103)
at je7hb.common.webcontainer.embedded.glassfish.SimpleEmbeddedRunner.launchDeployWarFile(SimpleEmbeddedRunner.java:59)
at je7hb.jaxrs.basic.RestfulBookServiceTest.shouldAssembleAndRetrieveBookList(RestfulBookServiceTest.java:39)
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.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
at org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.runTestClass(JUnitTestClassExecuter.java:55)
at org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.execute(JUnitTestClassExecuter.java:42)
at org.gradle.api.internal.tasks.testing.junit.JUnitTestClassProcessor.processTestClass(JUnitTestClassProcessor.java:71)
at org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:49)
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.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
at org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
at org.gradle.messaging.dispatch.ContextClassLoaderDispatch.dispatch(ContextClassLoaderDispatch.java:32)
at org.gradle.messaging.dispatch.ProxyDispatchAdapter$DispatchingInvocationHandler.invoke(ProxyDispatchAdapter.java:93)
at com.sun.proxy.$Proxy2.processTestClass(Unknown Source)
at org.gradle.api.internal.tasks.testing.worker.TestWorker.processTestClass(TestWorker.java:103)
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.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
at org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
at org.gradle.messaging.remote.internal.hub.MessageHub$Handler.run(MessageHub.java:355)
at org.gradle.internal.concurrent.DefaultExecutorFactory$StoppableExecutorImpl$1.run(DefaultExecutorFactory.java:66)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:722)

May 01, 2013 11:47:33 PM org.glassfish.internal.data.ModuleInfo start
SEVERE: Exception while invoking class com.sun.enterprise.web.WebApplication start method
java.lang.Exception: java.lang.IllegalStateException: ContainerBase.addChild: start: org.apache.catalina.LifecycleException: org.apache.catalina.LifecycleException: java.lang.NoClassDefFoundError: org/glassfish/json/jaxrs/JsonStructureBodyReader
at com.sun.enterprise.web.WebApplication.start(WebApplication.java:168)
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:497)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:219)
at org.glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java:491)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:527)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:523)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAs(Subject.java:356)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2.execute(CommandRunnerImpl.java:522)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:546)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1423)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1500(CommandRunnerImpl.java:108)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1762)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1674)
at com.sun.enterprise.admin.cli.embeddable.DeployerImpl.deploy(DeployerImpl.java:133)
at je7hb.common.webcontainer.embedded.glassfish.AbstractEmbeddedRunner.deployWithRename(AbstractEmbeddedRunner.java:103)
at je7hb.common.webcontainer.embedded.glassfish.SimpleEmbeddedRunner.launchDeployWarFile(SimpleEmbeddedRunner.java:59)
at je7hb.jaxrs.basic.RestfulBookServiceTest.shouldAssembleAndRetrieveBookList(RestfulBookServiceTest.java:39)
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.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
at org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.runTestClass(JUnitTestClassExecuter.java:55)
at org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.execute(JUnitTestClassExecuter.java:42)
at org.gradle.api.internal.tasks.testing.junit.JUnitTestClassProcessor.processTestClass(JUnitTestClassProcessor.java:71)
at org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:49)
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.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
at org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
at org.gradle.messaging.dispatch.ContextClassLoaderDispatch.dispatch(ContextClassLoaderDispatch.java:32)
at org.gradle.messaging.dispatch.ProxyDispatchAdapter$DispatchingInvocationHandler.invoke(ProxyDispatchAdapter.java:93)
at com.sun.proxy.$Proxy2.processTestClass(Unknown Source)
at org.gradle.api.internal.tasks.testing.worker.TestWorker.processTestClass(TestWorker.java:103)
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.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
at org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
at org.gradle.messaging.remote.internal.hub.MessageHub$Handler.run(MessageHub.java:355)
at org.gradle.internal.concurrent.DefaultExecutorFactory$StoppableExecutorImpl$1.run(DefaultExecutorFactory.java:66)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:722)

May 01, 2013 11:47:33 PM com.sun.enterprise.v3.server.ApplicationLifecycle deploy
SEVERE: Exception during lifecycle processing
java.lang.Exception: java.lang.IllegalStateException: ContainerBase.addChild: start: org.apache.catalina.LifecycleException: org.apache.catalina.LifecycleException: java.lang.NoClassDefFoundError: org/glassfish/json/jaxrs/JsonStructureBodyReader
at com.sun.enterprise.web.WebApplication.start(WebApplication.java:168)
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:497)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:219)
at org.glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java:491)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:527)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:523)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAs(Subject.java:356)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2.execute(CommandRunnerImpl.java:522)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:546)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1423)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1500(CommandRunnerImpl.java:108)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1762)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1674)
at com.sun.enterprise.admin.cli.embeddable.DeployerImpl.deploy(DeployerImpl.java:133)
at je7hb.common.webcontainer.embedded.glassfish.AbstractEmbeddedRunner.deployWithRename(AbstractEmbeddedRunner.java:103)
at je7hb.common.webcontainer.embedded.glassfish.SimpleEmbeddedRunner.launchDeployWarFile(SimpleEmbeddedRunner.java:59)
at je7hb.jaxrs.basic.RestfulBookServiceTest.shouldAssembleAndRetrieveBookList(RestfulBookServiceTest.java:39)
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.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
at org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.runTestClass(JUnitTestClassExecuter.java:55)
at org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.execute(JUnitTestClassExecuter.java:42)
at org.gradle.api.internal.tasks.testing.junit.JUnitTestClassProcessor.processTestClass(JUnitTestClassProcessor.java:71)
at org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:49)
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.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
at org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
at org.gradle.messaging.dispatch.ContextClassLoaderDispatch.dispatch(ContextClassLoaderDispatch.java:32)
at org.gradle.messaging.dispatch.ProxyDispatchAdapter$DispatchingInvocationHandler.invoke(ProxyDispatchAdapter.java:93)
at com.sun.proxy.$Proxy2.processTestClass(Unknown Source)
at org.gradle.api.internal.tasks.testing.worker.TestWorker.processTestClass(TestWorker.java:103)
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.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
at org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
at org.gradle.messaging.remote.internal.hub.MessageHub$Handler.run(MessageHub.java:355)
at org.gradle.internal.concurrent.DefaultExecutorFactory$StoppableExecutorImpl$1.run(DefaultExecutorFactory.java:66)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:722)

May 01, 2013 11:47:33 PM org.glassfish.api.ActionReport failure
SEVERE: Exception while loading the app
May 01, 2013 11:47:33 PM com.sun.enterprise.web.WebContainer unloadWebModule
SEVERE: Undeployment failed for context /mywebapp
May 01, 2013 11:47:33 PM org.glassfish.deployment.admin.DeployCommand execute
SEVERE: Exception while loading the app : java.lang.IllegalStateException: ContainerBase.addChild: start: org.apache.catalina.LifecycleException: org.apache.catalina.LifecycleException: java.lang.NoClassDefFoundError: org/glassfish/json/jaxrs/JsonStruc
tureBodyReader
May 01, 2013 11:47:33 PM org.glassfish.admin.mbeanserver.JMXStartupService shutdown
INFO: JMXStartupService and JMXConnectors have been shut down.

je7hb.jaxrs.basic.RestfulBookServiceTest > shouldAssembleAndRetrieveBookList STANDARD_OUT
JdbcRuntimeExtension, getAllSystemRAResourcesAndPools = [GlassFishConfigBean.org.glassfish.jdbc.config.JdbcResource, GlassFishConfigBean.org.glassfish.jdbc.config.JdbcResource, GlassFishConfigBean.org.glassfish.jdbc.config.JdbcConnectionPool, GlassFis
hConfigBean.org.glassfish.jdbc.config.JdbcConnectionPool]

je7hb.jaxrs.basic.RestfulBookServiceTest > shouldAssembleAndRetrieveBookList STANDARD_ERROR
May 01, 2013 11:47:33 PM com.sun.enterprise.v3.server.AppServerStartup stop
INFO: Shutdown procedure finished

je7hb.jaxrs.basic.RestfulBookServiceTest > shouldAssembleAndRetrieveBookList FAILED
java.io.FileNotFoundException: http://localhost:8080/mywebapp/rest/books
at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1623)
at java.net.URL.openStream(URL.java:1037)
at je7hb.jaxrs.basic.RestfulBookServiceTest.shouldAssembleAndRetrieveBookList(RestfulBookServiceTest.java:45)

1 test completed, 1 failed
Finished generating test XML results (0.047 secs)
Generating HTML test report...
Finished generating test html results (0.041 secs)
:test FAILED

FAILURE: Build failed with an exception.

  • Try:
    Run with --stacktrace option to get the stack trace. Run with --debug option to get more log output.

BUILD FAILED

Total time: 12.428 secs

C:\Users\peter\Documents\IdeaProjects\javaee7-handbook\ch08\jaxrs-basic>

This is the failure for the missing JSON-P library. Perhaps the Validation Configuration has been fixed against the trunk already and we are chasing shadows? Here is a suggestion, let's wait until B87 is released and then try again.

Comment by mtaube [ 02/May/13 03:28 PM ]

The CDI issue I've run into is due to the inclusion of cdi-api 1.1 PRD, which is a bug. I will check in a fix once checkins to the trunk are allowed again.





[GLASSFISH-20409] EJB container resolved during server startup Created: 25/Apr/13  Updated: 03/May/13  Resolved: 03/May/13

Status: Closed
Project: glassfish
Component/s: ejb_container
Affects Version/s: 4.0_b86_RC2
Fix Version/s: 4.0_b86_RC2

Type: Bug Priority: Major
Reporter: Tom Mueller Assignee: mtaube
Resolution: Duplicate Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: devx_web 4_0-approved
Participants: mtaube and Tom Mueller

 Description   

With BV 1.1 there is a new CDI portable extension that leads to the EJB container being resolved when bean validation is activated. Mason traced this down as follows:

I think I have chased this down as follows (not that I've trimmed this considerably.. there is quite a lot that is being brought in via web.glue):

org.glassfish.hk2.external.bean-validator [20] imports packages:
javax.enterprise.inject; version=1.0.0 -> org.jboss.weld.osgi-bundle [274]

org.jboss.weld.osgi-bundle [274] imports packages:
org.glassfish.weld; version=4.0.0 -> org.glassfish.main.web.weld-integration [273]

org.glassfish.main.web.weld-integration [273] imports packages:
org.glassfish.web.deployment.descriptor; version=4.0.0 -> org.glassfish.main.web.glue [262]

org.glassfish.main.web.glue [262] imports packages:
com.sun.ejb; version=4.0.0 -> org.glassfish.main.ejb.ejb-container [71]

This is due to a CDI portable extension (new in BV 1.1) that is now bundled in org.glassfish.hk2.external.bean-validator.

This issue for for fixing this so that EJB container is not resolved when bean validation is used, unless the portal extension is actually used.

To see this, just start an empty server and use the osgi lb command:

asadmin start-domain
asadmin osgi lb -l | grep ejb
   26|Installed  |    1|file:/Users/tomuell/test/glassfish/glassfish4/glassfish/modules/cmp-ejb-mapping.jar
   31|Installed  |    1|file:/Users/tomuell/test/glassfish/glassfish4/glassfish/modules/cmp-support-ejb.jar
   51|Installed  |    1|file:/Users/tomuell/test/glassfish/glassfish4/glassfish/modules/console-ejb-lite-plugin.jar
   52|Installed  |    1|file:/Users/tomuell/test/glassfish/glassfish4/glassfish/modules/console-ejb-plugin.jar
   71|Resolved   |    1|file:/Users/tomuell/test/glassfish/glassfish4/glassfish/modules/ejb-container.jar
   72|Installed  |    1|file:/Users/tomuell/test/glassfish/glassfish4/glassfish/modules/ejb-full-container.jar
   73|Resolved   |    1|file:/Users/tomuell/test/glassfish/glassfish4/glassfish/modules/ejb-internal-api.jar
   74|Installed  |    1|file:/Users/tomuell/test/glassfish/glassfish4/glassfish/modules/ejb.security.jar
   81|Active     |    1|file:/Users/tomuell/test/glassfish/glassfish4/glassfish/modules/gf-ejb-connector.jar
  130|Resolved   |    1|file:/Users/tomuell/test/glassfish/glassfish4/glassfish/modules/javax.ejb-api.jar
  168|Resolved   |    1|file:/Users/tomuell/test/glassfish/glassfish4/glassfish/modules/jersey-gf-ejb.jar
  286|Active     |    2|file:/Users/tomuell/test/glassfish/glassfish4/glassfish/modules/autostart/osgi-ejb-container.jar

Here, the ejb-container.jar bundle should be Installed rather than Resolved.

There may be other reasons why ejb-container.jar is getting resolved.

This issue is for making sure that ejb-container.jar is not resolved during server startup.



 Comments   
Comment by mtaube [ 26/Apr/13 01:40 PM ]

What is the impact on the customer of the bug?
Startup performance in certain cases is slower than it needs to be

How likely is it that a customer will see the bug and how serious is the bug?
Is it a regression? Does it meet other bug fix criteria (security, performance, etc.)?
What CTS failures are caused by this bug?
performance

What is the cost/risk of fixing the bug?
low

How risky is the fix? How much work is the fix? Is the fix complicated?
not risky, this change repackages the CDI portable extension so that the core bean-validator bundle does not resolve cdi/web/ejb components transitively.

Is there an impact on documentation or message strings?
No

Which tests should QA (re)run to verify the fix did not destabilize GlassFish?
quicklook, bean validation tck

Which is the targeted build of 4.0 for this fix?
4.0_b86_RC2

If this an integration of a new version of a component from another project,
what are the changes that are being brought in? This might be list of
Jira issues from that project or a list of revision messages.
N/A

Comment by Tom Mueller [ 29/Apr/13 02:22 PM ]

Built revision 61710 and ejb-container.jar is still resolved after starting the server.

When marking an issue as resolved, please include the revision number for the fix. Based on looking at the svn log, it appears that this was supposed to be fixed in 61661.

I'm reopening this since this isn't fixed.

Comment by mtaube [ 29/Apr/13 02:49 PM ]

This should no longer be happening due to bean-validator;

$ bin/asadmin osgi inspect package r 21
org.glassfish.hk2.external.bean-validator [21] imports packages:
----------------------------------------------------------------
javax.script; version=0.0.0 -> org.apache.felix.framework [0]
javax.xml.namespace; version=0.0.0 -> org.apache.felix.framework [0]
javax.xml.stream; version=0.0.0 -> org.apache.felix.framework [0]
javax.xml.stream.events; version=0.0.0 -> org.apache.felix.framework [0]
javax.xml.transform; version=0.0.0 -> org.apache.felix.framework [0]
javax.xml.transform.stream; version=0.0.0 -> org.apache.felix.framework [0]
javax.xml.validation; version=0.0.0 -> org.apache.felix.framework [0]
org.xml.sax; version=0.0.0 -> org.apache.felix.framework [0]
javax.xml.bind.annotation.adapters; version=2.2.7 -> jaxb-api [2]
javax.xml.bind.annotation; version=2.2.7 -> jaxb-api [2]
javax.xml.bind; version=2.2.7 -> jaxb-api [2]
javax.el; version=3.0.0 -> com.sun.el.javax.el [132]
javax.persistence; version=2.1.0 -> javax.persistence [143]

$ bin/asadmin osgi inspect package r 20
org.glassfish.hk2.external.bean-validator-cdi [20] imports packages:
--------------------------------------------------------------------
Nothing

Command osgi executed successfully.

Comment by Tom Mueller [ 29/Apr/13 02:57 PM ]

Note: I'm modifying this issue to be about making sure that ejb-container.jar is not resolved during server startup, not just for fixing the BV problem. (Yes, yes, I could have created another issue.)

Comment by Tom Mueller [ 29/Apr/13 04:13 PM ]

After Mason's changes to the BV module, the ejb-container.jar is now being resolved as a result of bringing in the <jdbc-resource> config bean during parsing of domain.xml.

Comment by Tom Mueller [ 30/Apr/13 05:31 PM ]

Assigning to Mason to provide information about the weld dependencies and how it is impacting this.

Comment by mtaube [ 30/Apr/13 05:54 PM ]

the weld-osgi bundle is importing org.glassfish.weld:

org.jboss.weld.osgi-bundle [275] exports packages:
--------------------------------------------------
javax.decorator; version=1.0.0 UNUSED
javax.enterprise.inject; version=1.0.0 imported by:
org.glassfish.fighterfish.osgi-cdi [285]
org.glassfish.main.web.weld-integration [274]
org.glassfish.javax.faces [136]
javax.enterprise.inject.spi; version=1.0.0 imported by:
org.glassfish.jersey.containers.glassfish.jersey-gf-cdi [168]
org.eclipse.persistence.core [211]
org.glassfish.main.web.sse [267]
org.glassfish.fighterfish.osgi-cdi [285]
org.glassfish.main.web.weld-integration [274]
org.glassfish.javax.faces [136]
javax.enterprise.context.spi; version=1.0.0 imported by:
org.glassfish.jersey.containers.glassfish.jersey-gf-cdi [168]
org.eclipse.persistence.core [211]
org.glassfish.fighterfish.osgi-cdi [285]
org.glassfish.main.web.sse [267]
org.glassfish.main.web.weld-integration [274]
org.glassfish.javax.faces [136]
javax.enterprise.context; version=1.0.0 imported by:
org.glassfish.main.web.gf-weld-connector [89]
org.glassfish.main.web.sse [267]
org.glassfish.fighterfish.osgi-cdi [285]
org.glassfish.main.web.weld-integration [274]
javax.transaction-api [152]
org.glassfish.javax.faces [136]
javax.enterprise.util; version=1.0.0 imported by:
org.glassfish.main.web.sse [267]
org.glassfish.fighterfish.osgi-cdi [285]
org.glassfish.main.web.weld-integration [274]
javax.transaction-api [152]
javax.enterprise.event; version=1.0.0 imported by:
org.glassfish.jersey.containers.glassfish.jersey-gf-cdi [168]
org.glassfish.fighterfish.osgi-cdi [285]
org.glassfish.main.web.sse [267]
org.glassfish.main.web.weld-integration [274]
org.glassfish.javax.faces [136]
org.jboss.weld.context; version=1.0.0 UNUSED
org.jboss.weld.ejb; version=1.0.0 imported by:
org.glassfish.main.web.weld-integration [274]
org.jboss.weld.bean; version=1.0.0 UNUSED
org.jboss.weld.bean.builtin; version=1.0.0 UNUSED
org.jboss.weld.bean.proxy; version=1.0.0 UNUSED
org.jboss.weld.servlet.api; version=1.0.0 UNUSED
org.jboss.weld.bootstrap.api; version=1.0.0 imported by:
org.glassfish.main.web.weld-integration [274]
org.jboss.weld.context.api; version=1.0.0 UNUSED
org.jboss.weld.servlet.api.helpers; version=1.0.0 UNUSED
org.jboss.weld.bootstrap.api.helpers; version=1.0.0 imported by:
org.glassfish.main.web.weld-integration [274]
org.jboss.weld.ejb.api; version=1.0.0 imported by:
org.glassfish.main.web.weld-integration [274]
org.jboss.weld.manager.api; version=1.0.0 imported by:
org.glassfish.main.web.weld-integration [274]
org.jboss.weld.interceptor.spi.model; version=1.0.0 UNUSED
org.jboss.weld.ejb.spi.helpers; version=1.0.0 UNUSED
org.jboss.weld.validation.spi; version=1.0.0 imported by:
org.glassfish.main.web.weld-integration [274]
org.jboss.weld.serialization.spi; version=1.0.0 imported by:
org.glassfish.main.web.weld-integration [274]
org.jboss.weld.interceptor.spi.context; version=1.0.0 UNUSED
org.jboss.weld.interceptor.spi.metadata; version=1.0.0 UNUSED
org.jboss.weld.transaction.spi; version=1.0.0 imported by:
org.glassfish.main.web.weld-integration [274]
org.jboss.weld.injection.spi.helpers; version=1.0.0 UNUSED
org.jboss.weld.serialization.spi.helpers; version=1.0.0 UNUSED
org.jboss.weld.bootstrap.spi; version=1.0.0 imported by:
org.glassfish.main.web.weld-integration [274]
org.jboss.weld.injection.spi; version=1.0.0 imported by:
org.glassfish.main.web.weld-integration [274]
org.jboss.weld.resources.spi; version=1.0.0 imported by:
org.glassfish.main.web.weld-integration [274]
org.jboss.weld.interceptor.spi.instance; version=1.0.0 UNUSED
org.jboss.weld.resources.spi.helpers; version=1.0.0 UNUSED
org.jboss.weld.bootstrap.spi.helpers; version=1.0.0 UNUSED
org.jboss.weld.ejb.spi; version=1.0.0 imported by:
org.glassfish.main.web.weld-integration [274]
org.jboss.weld.security.spi; version=1.0.0 imported by:
org.glassfish.main.web.weld-integration [274]
org.jboss.weld; version=1.0.0 imported by:
org.glassfish.main.web.weld-integration [274]
org.jboss.weld.bootstrap; version=1.0.0 imported by:
org.glassfish.main.web.weld-integration [274]
org.jboss.weld.event; version=1.0.0 UNUSED
org.jboss.weld.injection; version=1.0.0 UNUSED
org.jboss.weld.manager; version=1.0.0 imported by:
org.glassfish.main.web.weld-integration [274]
org.jboss.weld.servlet; version=1.0.0 UNUSED
org.jboss.weld.util; version=1.0.0 UNUSED
org.jboss.weld.el; version=1.0.0 imported by:
org.glassfish.main.web.weld-integration [274]
org.jboss.weld.jsf; version=1.0.0 UNUSED
org.jboss.weld.proxy.util; version=0.0.0 UNUSED
org.jboss.weld.bean.proxy.util; version=0.0.0 UNUSED
org.jboss.weld.context.http; version=0.0.0 UNUSED
org.jboss.weld.context.bound; version=0.0.0 UNUSED
org.jboss.weld.context.cache; version=0.0.0 UNUSED
org.jboss.weld.bean.builtin.ee; version=0.0.0 UNUSED
javassist.util.proxy; version=0.0.0 UNUSED
org.jboss.weld.interceptor.proxy; version=0.0.0 UNUSED
org.jboss.weld.interceptor.util.proxy; version=0.0.0 UNUSED
org.jboss.weld.util.bean; version=0.0.0 UNUSED
org.jboss.weld.serialization; version=0.0.0 UNUSED
org.jboss.weld.injection.attributes; version=0.0.0 UNUSED
org.jboss.weld.util.collections; version=0.0.0 UNUSED
org.jboss.weld.annotated.slim; version=0.0.0 UNUSED
org.jboss.weld.annotated.slim.backed; version=0.0.0 UNUSED

Command osgi executed successfully.

org.jboss.weld.osgi-bundle [275] imports packages:
--------------------------------------------------
javax.naming; version=0.0.0 -> org.apache.felix.framework [0]
javax.naming.spi; version=0.0.0 -> org.apache.felix.framework [0]
javax.xml.parsers; version=0.0.0 -> org.apache.felix.framework [0]
org.w3c.dom; version=0.0.0 -> org.apache.felix.framework [0]
org.xml.sax; version=0.0.0 -> org.apache.felix.framework [0]
org.xml.sax.helpers; version=0.0.0 -> org.apache.felix.framework [0]
sun.misc; version=0.0.0 -> org.apache.felix.framework [0]
javax.annotation; version=1.2.0 -> javax.annotation-api [1]
javax.validation; version=1.1.0 -> org.glassfish.hk2.external.bean-validator [21]
javax.el; version=3.0.0 -> com.sun.el.javax.el [132]
javax.faces.application; version=2.2.0 -> org.glassfish.javax.faces [136]
javax.faces.context; version=2.2.0 -> org.glassfish.javax.faces [136]
javax.inject; version=1.0.0 -> org.glassfish.hk2.external.javax.inject [137]
javax.interceptor; version=1.2.0 -> javax.interceptor-api [138]
javax.persistence; version=2.1.0 -> javax.persistence [143]
javax.servlet; version=3.1.0 -> javax.servlet-api [147]
javax.servlet.http; version=3.1.0 -> javax.servlet-api [147]
javax.transaction; version=1.2.0.b03 -> javax.transaction-api [152]
org.glassfish.weld; version=4.0.0 -> org.glassfish.main.web.weld-integration [274]

Command osgi executed successfully.

Comment by mtaube [ 03/May/13 04:01 PM ]

This is a dup of GLASSFISH-20450 - Weld combination of API/implementation in single bundle slows down server startup





Cannot get ValidationFactory if CDI is disabled. (GLASSFISH-20401)

[GLASSFISH-20404] bypass NamedNamingObjectManager when BeanManager not enabled Created: 24/Apr/13  Updated: 25/Apr/13  Resolved: 25/Apr/13

Status: Closed
Project: glassfish
Component/s: naming
Affects Version/s: None
Fix Version/s: 4.0_b86_RC2

Type: Sub-task Priority: Major
Reporter: mtaube Assignee: mtaube
Resolution: Fixed Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: 4_0-approved
Participants: mtaube

 Description   

currently, if the BeanManager is not available, a lookup of java:comp/Validator will fail with an IllegalStateException. This is due to the proxying of java:comp namespace. Instead of throwing an IllegalStateException, the registry in JavaURLContext should be consulted:

[2013-04-24T11:50:49.637-0400] [glassfish 4.0] [SEVERE] [] [javax.enterprise.web] [tid: _ThreadID=68 _ThreadName=AutoDeployer] [timeMillis: 1366818649637] [levelValue: 1000] [[
WebModule[/ejb3_assembly_appres_warejb_web]Servlet /ejb3_assembly_appres_warejb_web threw load() exception
java.lang.IllegalStateException: Cannot resolve bean manager
at org.glassfish.weld.BeanManagerNamingProxy.handle(BeanManagerNamingProxy.java:121)
at org.glassfish.weld.ValidationNamingProxy.obtainBeanManager(ValidationNamingProxy.java:191)
at org.glassfish.weld.ValidationNamingProxy.handle(ValidationNamingProxy.java:103)
at com.sun.enterprise.naming.impl.NamedNamingObjectManager.tryNamedProxies(NamedNamingObjectManager.java:134)
at com.sun.enterprise.naming.impl.JavaURLContext.lookup(JavaURLContext.java:166)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:471)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:438)
at javax.naming.InitialContext.lookup(Unknown Source)
at javax.naming.InitialContext.lookup(Unknown Source)
at com.sun.ts.tests.ejb30.common.helper.ServiceLocator.lookup(ServiceLocator.java:72)
at com.sun.ts.tests.ejb30.common.helper.ServiceLocator.lookupNoTry(ServiceLocator.java:28)
at com.sun.ts.tests.ejb30.assembly.appres.common.AppResTest.verifyValidatorAndFactory(AppResTest.java:79)
at com.sun.ts.tests.ejb30.assembly.appres.common.AppResTest.beanPostConstruct(AppResTest.java:118)
at com.sun.ts.tests.ejb30.assembly.appres.common.TestServletBase2.postConstruct(TestServletBase2.java:42)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at com.sun.enterprise.container.common.impl.util.InjectionManagerImpl$3.run(InjectionManagerImpl.java:743)
at java.security.AccessController.doPrivileged(Native Method)
at com.sun.enterprise.container.common.impl.util.InjectionManagerImpl.invokeLifecycleMethod(InjectionManagerImpl.java:737)
at com.sun.enterprise.container.common.impl.util.InjectionManagerImpl.inject(InjectionManagerImpl.java:508)
at com.sun.enterprise.container.common.impl.util.InjectionManagerImpl.injectInstance(InjectionManagerImpl.java:141)
at com.sun.enterprise.container.common.impl.util.InjectionManagerImpl.injectInstance(InjectionManagerImpl.java:127)
at com.sun.enterprise.container.common.impl.util.InjectionManagerImpl.createManagedObject(InjectionManagerImpl.java:324)
at com.sun.enterprise.web.WebContainer.createServletInstance(WebContainer.java:983)
at com.sun.enterprise.web.WebModule.createServletInstance(WebModule.java:2130)
at org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1404)
at org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:1381)
at org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java:5670)
at org.apache.catalina.core.StandardContext.start(StandardContext.java:5912)
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:2278)
at com.sun.enterprise.web.WebContainer.loadWebModule(WebContainer.java:1924)
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:497)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:219)
at org.glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java:491)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2.execute(CommandRunnerImpl.java:537)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:546)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1423)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1500(CommandRunnerImpl.java:108)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1762)
at org.glassfish.deployment.autodeploy.AutoOperation.run(AutoOperation.java:164)
at org.glassfish.deployment.autodeploy.AutoDeployer.deploy(AutoDeployer.java:595)
at org.glassfish.deployment.autodeploy.AutoDeployer.deployAll(AutoDeployer.java:482)
at org.glassfish.deployment.autodeploy.AutoDeployer.run(AutoDeployer.java:410)
at org.glassfish.deployment.autodeploy.AutoDeployer.run(AutoDeployer.java:401)
at org.glassfish.deployment.autodeploy.AutoDeployService$1.run(AutoDeployService.java:233)
at java.util.TimerThread.mainLoop(Unknown Source)
at java.util.TimerThread.run(Unknown Source)
]]



 Comments   
Comment by mtaube [ 24/Apr/13 08:28 PM ]

What is the impact on the customer of the bug?
While investigating GLASSFISH-20401 we found the weld integration code was masking an underlying problem by attempting to obtain the BeanManager (in some cases, when CDI is not available, the BeanManager is not available and an IllegalStateException is thrown)

How likely is it that a customer will see the bug and how serious is the bug?
Is it a regression? Does it meet other bug fix criteria (security, performance, etc.)?
What CTS failures are caused by this bug?
javaeetck/src/com/sun/ts/tests/ejb30/assembly/appres/warejb

What is the cost/risk of fixing the bug?
How risky is the fix? How much work is the fix? Is the fix complicated?
Low risk

Is there an impact on documentation or message strings?
No

Which tests should QA (re)run to verify the fix did not destabilize GlassFish?
EJB, Quicklook, EJB cts, Bean Validation cts

I have also verified that the following tests pass :
QL, bv-tck

Which is the targeted build of 4.0 for this fix?
Build-86

If this an integration of a new version of a component from another project,
what are the changes that are being brought in? This might be list of
Jira issues from that project or a list of revision messages.
No.

Comment by mtaube [ 25/Apr/13 12:49 PM ]

Committed revision 61643.





[GLASSFISH-20401] Cannot get ValidationFactory if CDI is disabled. Created: 24/Apr/13  Updated: 25/Apr/13  Resolved: 25/Apr/13

Status: Closed
Project: glassfish
Component/s: bean-validator
Affects Version/s: None
Fix Version/s: 4.0_b86_RC2

Type: Bug Priority: Major
Reporter: jjsnyder83 Assignee: mtaube
Resolution: Fixed Votes: 0
Σ Remaining Estimate: Not Specified Remaining Estimate: Not Specified
Σ Time Spent: Not Specified Time Spent: Not Specified
Σ Original Estimate: Not Specified Original Estimate: Not Specified

Sub-Tasks:
Key
Summary
Type
Status
Assignee
GLASSFISH-20404 bypass NamedNamingObjectManager when ... Sub-task Closed mtaube  
Tags:
Participants: jjsnyder83 and mtaube

 Description   

When CDI is not enabled for an application and it tries to lookup the Validator via "java:comp/Validator" or ValidatorFactory via "java:comp/ValidatorFactory" an exception is thrown because the ValidationNamingProxy assumes CDI is always enabled. The following cts test illustrates the error with the exception below:

javaeetck/src/com/sun/ts/tests/ejb30/assembly/appres/warejb

[2013-04-24T11:50:49.637-0400] [glassfish 4.0] [SEVERE] [] [javax.enterprise.web] [tid: _ThreadID=68 _ThreadName=AutoDeployer] [timeMillis: 1366818649637] [levelValue: 1000] [[
WebModule[/ejb3_assembly_appres_warejb_web]Servlet /ejb3_assembly_appres_warejb_web threw load() exception
java.lang.IllegalStateException: Cannot resolve bean manager
at org.glassfish.weld.BeanManagerNamingProxy.handle(BeanManagerNamingProxy.java:121)
at org.glassfish.weld.ValidationNamingProxy.obtainBeanManager(ValidationNamingProxy.java:191)
at org.glassfish.weld.ValidationNamingProxy.handle(ValidationNamingProxy.java:103)
at com.sun.enterprise.naming.impl.NamedNamingObjectManager.tryNamedProxies(NamedNamingObjectManager.java:134)
at com.sun.enterprise.naming.impl.JavaURLContext.lookup(JavaURLContext.java:166)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:471)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:438)
at javax.naming.InitialContext.lookup(Unknown Source)
at javax.naming.InitialContext.lookup(Unknown Source)
at com.sun.ts.tests.ejb30.common.helper.ServiceLocator.lookup(ServiceLocator.java:72)
at com.sun.ts.tests.ejb30.common.helper.ServiceLocator.lookupNoTry(ServiceLocator.java:28)
at com.sun.ts.tests.ejb30.assembly.appres.common.AppResTest.verifyValidatorAndFactory(AppResTest.java:79)
at com.sun.ts.tests.ejb30.assembly.appres.common.AppResTest.beanPostConstruct(AppResTest.java:118)
at com.sun.ts.tests.ejb30.assembly.appres.common.TestServletBase2.postConstruct(TestServletBase2.java:42)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at com.sun.enterprise.container.common.impl.util.InjectionManagerImpl$3.run(InjectionManagerImpl.java:743)
at java.security.AccessController.doPrivileged(Native Method)
at com.sun.enterprise.container.common.impl.util.InjectionManagerImpl.invokeLifecycleMethod(InjectionManagerImpl.java:737)
at com.sun.enterprise.container.common.impl.util.InjectionManagerImpl.inject(InjectionManagerImpl.java:508)
at com.sun.enterprise.container.common.impl.util.InjectionManagerImpl.injectInstance(InjectionManagerImpl.java:141)
at com.sun.enterprise.container.common.impl.util.InjectionManagerImpl.injectInstance(InjectionManagerImpl.java:127)
at com.sun.enterprise.container.common.impl.util.InjectionManagerImpl.createManagedObject(InjectionManagerImpl.java:324)
at com.sun.enterprise.web.WebContainer.createServletInstance(WebContainer.java:983)
at com.sun.enterprise.web.WebModule.createServletInstance(WebModule.java:2130)
at org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1404)
at org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:1381)
at org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java:5670)
at org.apache.catalina.core.StandardContext.start(StandardContext.java:5912)
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:2278)
at com.sun.enterprise.web.WebContainer.loadWebModule(WebContainer.java:1924)
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:497)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:219)
at org.glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java:491)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2.execute(CommandRunnerImpl.java:537)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:546)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1423)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1500(CommandRunnerImpl.java:108)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1762)
at org.glassfish.deployment.autodeploy.AutoOperation.run(AutoOperation.java:164)
at org.glassfish.deployment.autodeploy.AutoDeployer.deploy(AutoDeployer.java:595)
at org.glassfish.deployment.autodeploy.AutoDeployer.deployAll(AutoDeployer.java:482)
at org.glassfish.deployment.autodeploy.AutoDeployer.run(AutoDeployer.java:410)
at org.glassfish.deployment.autodeploy.AutoDeployer.run(AutoDeployer.java:401)
at org.glassfish.deployment.autodeploy.AutoDeployService$1.run(AutoDeployService.java:233)
at java.util.TimerThread.mainLoop(Unknown Source)
at java.util.TimerThread.run(Unknown Source)
]]






Loading of HK2 cache data slows down server initialization (GLASSFISH-20298)

[GLASSFISH-20350] Make DescriptorImpl Externalizable instead of Serializable Created: 19/Apr/13  Updated: 19/Apr/13  Resolved: 19/Apr/13

Status: Closed
Project: glassfish
Component/s: hk2
Affects Version/s: None
Fix Version/s: 4.0_b87_RC3

Type: Sub-task Priority: Major
Reporter: mtaube Assignee: mtaube
Resolution: Fixed Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: 4_0-approved
Participants: mtaube and Tom Mueller

 Description   

From parent task:

I've measured the time required for loadCachedData in both 4.0 and 3.1.2. This is for a subsequent restart, and is an average of 5 runs on a MBP:

4.0: 424 ms ("Felix" start time is 2726 ms), inhabitants size = 516415
3.1.2: 194 ms ("Felix start time is 1615 ms), inhabitants size = 371748

loadCachedData is approximately 20-25% faster if DescriptorImpl implements Externalizable (using the string-based representation of a Descriptor) instead of Serializable.

  • What is the impact on the customer of the bug?

Startup performance on a 'warm boot' is slowed down by serialization

  • What is the cost/risk of fixing the bug?

Low risk

  • Is there an impact on documentation or message strings?

no

  • Which tests should QA (re)run to verify the fix did not destabilize GlassFish?

quicklook

  • Which is the targeted build of 4.0 for this fix?

4.0_b87

  • If this an integration of a new version of a component from another project,
    what are the changes that are being brought in? This might be list of
    Jira issues from that project or a list of revision messages.


 Comments   
Comment by Tom Mueller [ 19/Apr/13 02:03 PM ]

Approved for 4.0

Comment by mtaube [ 19/Apr/13 02:12 PM ]

Committed revision 61562.





[GLASSFISH-20340] [regression] Make HK2 cache io buffer size is not configurable Created: 17/Apr/13  Updated: 18/Apr/13  Resolved: 18/Apr/13

Status: Closed
Project: glassfish
Component/s: hk2
Affects Version/s: 4.0_b84_RC1
Fix Version/s: 4.0_b87_RC3

Type: Bug Priority: Major
Reporter: Sanjeeb Sahoo Assignee: mtaube
Resolution: Fixed Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: 4_0-approved performance
Participants: mtaube, Sanjeeb Sahoo and Tom Mueller

 Description   

It used to be configurable earlier, but during hk2 2.x, it has been changed to become a fixed value. Fix it so that perf team can use it to tune the system.



 Comments   
Comment by mtaube [ 18/Apr/13 12:49 PM ]

What is the impact on the customer of the bug?

They will see a performance improvement during startup when io buffer size is optimized for the machine running glassfish

What is the cost/risk of fixing the bug?

This particular change is not risky, will only take effect if a property is specified in osgi.properties

Is there an impact on documentation or message strings?

No

Which tests should QA (re)run to verify the fix did not destabilize GlassFish?

quicklook

Which is the targeted build of 4.0 for this fix?

b88

If this an integration of a new version of a component from another project,
what are the changes that are being brought in? This might be list of
Jira issues from that project or a list of revision messages.

n/a

Comment by Tom Mueller [ 18/Apr/13 01:27 PM ]

I hesitate in approving this in that I don't completely agree that this should even be tunable (or should have ever been tunable). More knobs are not necessarily better, and there isn't any proof that different values are needed for different systems. And even if different values were beneficial, is there actually going to be documentation on how users could actually tune this value or is there a performance tuner that sets the value. IMHO, it would be better to just determine a single value that is reasonable for the systems that we target and put that value in the code.

Approved for 4.0.





[GLASSFISH-20316] Findbugs: IS2_INCONSISTENT_SYNC: Inconsistent synchronization Created: 15/Apr/13  Updated: 15/Apr/13  Resolved: 15/Apr/13

Status: Closed
Project: glassfish
Component/s: bean-validator
Affects Version/s: None
Fix Version/s: 4.0_b85

Type: Bug Priority: Major
Reporter: mtaube Assignee: mtaube
Resolution: Fixed Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: 4_0-approved findbugs
Participants: mtaube and Tom Mueller

 Description   

This is a fix of a Low Priority findbugs issue:

Errors:
================================================================================
mtaube: appserver/web/weld-integration/src/main/java/org/glassfish/weld/ValidationNamingProxy.java:105: IS2_INCONSISTENT_SYNC: Inconsistent synchronization of org.glassfish.weld.ValidationNamingProxy.beanManagerNamingProxy; locked 66% of time
mtaube: appserver/web/weld-integration/src/main/java/org/glassfish/weld/ValidationNamingProxy.java:150: IS2_INCONSISTENT_SYNC: Inconsistent synchronization of org.glassfish.weld.ValidationNamingProxy.beanManagerNamingProxy; locked 66% of time
mtaube: appserver/web/weld-integration/src/main/java/org/glassfish/weld/ValidationNamingProxy.java:181: IS2_INCONSISTENT_SYNC: Inconsistent synchronization of org.glassfish.weld.ValidationNamingPro

  • What is the impact on the customer of the bug?

How likely is it that a customer will see the bug and how serious is the bug?
Is it a regression? Does it meet other bug fix criteria (security, performance, etc.)?
What CTS failures are caused by this bug?

  • What is the cost/risk of fixing the bug?

very low risk, adds synchronization to a critical section

  • Is there an impact on documentation or message strings?

no

  • Which tests should QA (re)run to verify the fix did not destabilize GlassFish?

jsr-349 cts

  • Which is the targeted build of 4.0 for this fix?
  • If this an integration of a new version of a component from another project,
    what are the changes that are being brought in? This might be list of
    Jira issues from that project or a list of revision messages.


 Comments   
Comment by Tom Mueller [ 15/Apr/13 09:04 PM ]

Approved for 4.0.





[GLASSFISH-20298] Loading of HK2 cache data slows down server initialization Created: 12/Apr/13  Updated: 01/May/13

Status: Reopened
Project: glassfish
Component/s: hk2
Affects Version/s: 4.0_b84_RC1
Fix Version/s: 4.0.1

Type: Bug Priority: Major
Reporter: Tom Mueller Assignee: mtaube
Resolution: Unresolved Votes: 0
Σ Remaining Estimate: Not Specified Remaining Estimate: Not Specified
Σ Time Spent: Not Specified Time Spent: Not Specified
Σ Original Estimate: Not Specified Original Estimate: Not Specified

Sub-Tasks:
Key
Summary
Type
Status
Assignee
GLASSFISH-20350 Make DescriptorImpl Externalizable in... Sub-task Closed mtaube  
Tags: devx_web
Participants: mtaube and Tom Mueller

 Description   

During server startup, the HK2 OSGi adapter reads in a fairly large cache file in the ModuleDefinitionCacheSingleton.loadCachedData method. Typically this is about 400KB of serialized module definition data. This takes anywhere from 100-400 ms and while the server is doing this, it is doing nothing else. The code is started via the bundle start method of the osgi-adapter.jar file.

An idea for improving server start time is to move the reading of the cache file to another thread that runs in parallel with some other initialization work that the server is doing. For example, if it would be possible to initialize just the OSGi bundle(s) that are needed to read this cache first, start the cache-reading thread, and then start then have Felix initialize the rest of the bundles. Then, when the bundles are all initialized, the code that need the cache would already have it available.

Or, if the cache were constructed purely from Java SE objects, then the cache could be read into memory without having to initialize any OSGi bundle.



 Comments   
Comment by Tom Mueller [ 17/Apr/13 10:10 PM ]

I've measured the time required for loadCachedData in both 4.0 and 3.1.2. This is for a subsequent restart, and is an average of 5 runs on a MBP:

4.0: 424 ms ("Felix" start time is 2726 ms), inhabitants size = 516415
3.1.2: 194 ms ("Felix start time is 1615 ms), inhabitants size = 371748

Comment by Tom Mueller [ 30/Apr/13 05:36 PM ]

Note that the only thing fixed here is the GLASSFISH-20350 subtask which reduced the time to read the cache by about 100 ms. This change did not move the cache reading to a parallel thread. It also did not restore the cache reading time to what it was in 3.1.2.

Comment by Tom Mueller [ 01/May/13 06:02 PM ]

Retargeting for 4.0.1 because we have already done what we plan to do in this area for 4.0 via GLASSFISH-20350.





[GLASSFISH-20238] uptake hk2 2.1.80 Created: 09/Apr/13  Updated: 09/Apr/13  Resolved: 09/Apr/13

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

Type: Bug Priority: Major
Reporter: mtaube Assignee: mtaube
Resolution: Fixed Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: 4_0-approved
Participants: mtaube

 Description   

uptake the new hk2 2.1.80 binary which includes hibernate validator 5.0.0.CR5

This should be the only change:

Project: hk2
Repository: svn
Revision: 4459
Author: mtaube
Date: 2013-04-08 20:10:39 UTC
Link:

Log Message:
------------
uptake hibernate validator 5.0.0.CR5

Revisions:
----------
4459

Modified Paths:
---------------
trunk/hk2/pom.xml
trunk/hk2/external/bean-validator/pom.xml

Diffs:
------
Index: trunk/hk2/pom.xml
===================================================================
— trunk/hk2/pom.xml (revision 4458)
+++ trunk/hk2/pom.xml (revision 4459)
@@ -327,7 +327,7 @@
<asm.version>3.3</asm.version>
<cglib.version>2.2</cglib.version>
<javax.validation.version>1.1.0.CR3</javax.validation.version>

  • <hibernate-validator.version>5.0.0.CR4</hibernate-validator.version>
    + <hibernate-validator.version>5.0.0.CR5</hibernate-validator.version>
    <findbugs.exclude />
    <findbugs.threshold>High</findbugs.threshold>
    <site.url>file:../www/</site.url>
    Index: trunk/hk2/external/bean-validator/pom.xml
    ===================================================================
      • trunk/hk2/external/bean-validator/pom.xml (revision 4458)
        +++ trunk/hk2/external/bean-validator/pom.xml (revision 4459)
        @@ -69,7 +69,7 @@
        <Embed-Dependency>
        <!-- Only specify root artifacts that need to be embedded, everything else
        will be pulled in automatically based on Private-Package settings. -->
  • *; artifactId=hibernate-validator; inline=true
    + ; artifactId=hibernate-validator; inline=true,; artifactId=hibernate-validator-cdi; inline=true
    </Embed-Dependency>
    <Export-Package>
    javax.validation.*; version=${javax.validation.version},
    @@ -200,6 +200,13 @@
    <classifier>sources</classifier>
    <overWrite>false</overWrite>
    </artifactItem>
    + <artifactItem>
    + <groupId>org.hibernate</groupId>
    + <artifactId>hibernate-validator-cdi</artifactId>
    + <version>${hibernate-validator.version}</version>
    + <classifier>sources</classifier>
    + <overWrite>false</overWrite>
    + </artifactItem>
    </artifactItems>
    </configuration>
    </execution>
    @@ -220,6 +227,13 @@
    <classifier>javadoc</classifier>
    <overWrite>false</overWrite>
    </artifactItem>
    + <artifactItem>
    + <groupId>org.hibernate</groupId>
    + <artifactId>hibernate-validator-cdi</artifactId>
    + <version>${hibernate-validator.version}</version>
    + <classifier>javadoc</classifier>
    + <overWrite>false</overWrite>
    + </artifactItem>
    </artifactItems>
    </configuration>
    </execution>
    @@ -253,6 +267,13 @@
    </dependency>

<dependency>
+ <groupId>org.hibernate</groupId>
+ <artifactId>hibernate-validator-cdi</artifactId>
+ <version>${hibernate-validator.version}</version>
+ <optional>true</optional>
+ </dependency>
+
+ <dependency>
<!--
Although hibernate validator uses maven-shade-plugin to repackage com.googlecode.jtype classes
bu org.hibernate.validator.jtype classes, the shade plugin seems to leave behind some



 Comments   
Comment by mtaube [ 09/Apr/13 05:22 PM ]

Committed revision 61258.





[GLASSFISH-20079] Integration EE test failures in 1.1.0.CR4 TCK Created: 27/Mar/13  Updated: 09/Apr/13  Resolved: 09/Apr/13

Status: Closed
Project: glassfish
Component/s: bean-validator
Affects Version/s: None
Fix Version/s: 4.0_b86_RC2

Type: Bug Priority: Major
Reporter: mtaube Assignee: mtaube
Resolution: Fixed Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: mtaube

 Description   

testJndiBoundValidatorFactoryIsCdiEnabled(org.hibernate.beanvalidation.tck.tests.integration.ee.cdi.ConstraintValidatorInjectionTest) Time elapsed: 0.623 sec <<< FAILURE!
testDefaultValidatorCanBeRetrievedFromJndi(org.hibernate.beanvalidation.tck.tests.integration.ee.JndiRetrievalTest) Time elapsed: 0.645 sec <<< FAILURE!
testDefaultValidatorFactoryCanBeRetrievedFromJndi(org.hibernate.beanvalidation.tck.tests.integration.ee.JndiRetrievalTest) Time elapsed: 0.025 sec <<< FAILURE!






[GLASSFISH-20078] Integration CDI test failures in 1.1.0.CR4 TCK Created: 27/Mar/13  Updated: 09/Apr/13  Resolved: 09/Apr/13

Status: Closed
Project: glassfish
Component/s: bean-validator
Affects Version/s: None
Fix Version/s: 4.0_b86_RC2

Type: Bug Priority: Major
Reporter: mtaube Assignee: mtaube
Resolution: Fixed Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: mtaube

 Description   

testValidationInterceptorHasPriority4800(org.hibernate.beanvalidation.tck.tests.integration.cdi.executable.priority.ValidationInterceptorPriorityTest) Time elapsed: 0.501 sec <<< FAILURE!
testDependencyInjectionIntoConstraintValidator(org.hibernate.beanvalidation.tck.tests.integration.cdi.factory.ConstraintValidatorInjectionTest) Time elapsed: 0.586 sec <<< FAILURE!
testConstraintValidatorFactoryIsSubjectToDependencyInjection(org.hibernate.beanvalidation.tck.tests.integration.cdi.managedobjects.ManagedObjectsTest) Time elapsed: 0.498 sec <<< FAILURE!
testMessageInterpolatorIsSubjectToDependencyInjection(org.hibernate.beanvalidation.tck.tests.integration.cdi.managedobjects.ManagedObjectsTest) Time elapsed: 0.043 sec <<< FAILURE!
testParameterNameProviderIsSubjectToDependencyInjection(org.hibernate.beanvalidation.tck.tests.integration.cdi.managedobjects.ManagedObjectsTest) Time elapsed: 0.043 sec <<< FAILURE!
testTraversableResolverIsSubjectToDependencyInjection(org.hibernate.beanvalidation.tck.tests.integration.cdi.managedobjects.ManagedObjectsTest) Time elapsed: 0.037 sec <<< FAILURE!






[GLASSFISH-19940] Investigate modifying META-INF/services handling to reduce performance regression Created: 19/Mar/13  Updated: 22/Apr/13  Resolved: 22/Apr/13

Status: Closed
Project: glassfish
Component/s: hk2
Affects Version/s: 4.0_b79
Fix Version/s: 4.0

Type: Task Priority: Critical
Reporter: Tom Mueller Assignee: mtaube
Resolution: Won't Fix Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: devx_web
Participants: jwells, mtaube, Sanjeeb Sahoo and Tom Mueller

 Description   

Part of the startup time for GlassFish is to read in the META-INF/services/* files from the OSGi bundles (76 out of the 289 have these) and then to consult the content of these files during certain class loader operations. Since HK2 doesn't use these services files, it is not clear that we need to spend this time during startup. Eliminating this processing may help reduce the performance regression for GF 4.0.

Here is some data.

From the profile, the loadMetadata method spends about half of its time loading the service descriptors. This shows that there are 76 descriptors read from 289 bundles. Only 34 of the bundles have any descriptors at all.

3.0% - 962 ms - 289 inv. org.jvnet.hk2.osgiadapter.OSGiModuleDefinition$BundleJar.loadMetadata
-1.6% - 527 ms - 289 inv. org.jvnet.hk2.osgiadapter.OSGiModuleDefinition$BundleJar.parseServiceDescriptors
--1.0% - 308 ms - 34 inv. org.osgi.framework.Bundle.getEntryPaths
--0.6% - 196 ms - 76 inv. com.sun.enterprise.module.ModuleMetadata.load
--0.0% - 11,643 µs - 365 inv. org.osgi.framework.Bundle.getEntry
--0.0% - 9,557 µs - 76 inv. java.net.URL.openStream
--0.0% - 1,329 µs - 76 inv. java.util.Enumeration.nextElement
--0.0% - 51 µs - 76 inv. java.lang.String.substring
--0.0% - 4 µs - 110 inv. java.util.Enumeration.hasMoreElements
--0.0% - 1 µs - 76 inv. java.io.InputStream.close

The OSGiModuleDefinition$BundleJar.parseServiceDescriptors method reads these files into a ModuleMetadata class. The ModuleMetadata is also written by AbstractModulesRegistryImpl.add (via OSGIFactoryImpl.createModulesRegistry).

The ModuleMetadata services entries information is read during startup by APIClassLoaderServiceImpl$APIClassLoader to resolve JAR Service references for the following classes:

javax.xml.stream.XMLInputFactory (* this one is found in the woodstox-core-asl.jar file)
javax.ws.rs.ext.MessageBodyReader
javax.json.spi.JsonProvider
javax.xml.parsers.DocumentBuilderFactory
javax.xml.transform.TransformerFactory
com.sun.org.apache.xalan.internal.xsltc.dom.XSLTCDTMManager

Only the first one (as indicated) is actually found in any of the GlassFish OSGi bundles.

Maybe the annotation processor that generates the services entries for GlassFish could be modified so that entries are not generated for @Contract implementations. This would reduce the number of JARs that actually have services. Also, the APIClassLoader class could be improved so that can do a more efficient lookup for META-INF/services references (rather than looping through all 289 bundles).

The purpose of this issue to to investigate whether a performance improvement is possible. If it is possible, then this issue should be changed to a "bug" to reflect that changes actually need to be made to the system. The changes would be needed for 4.0 to meet the release criteria for this benchmark.



 Comments   
Comment by jwells [ 19/Mar/13 05:53 PM ]

So I don't think this comment is accurate:

Maybe the annotation processor that generates the services entries for GlassFish could be modified so that entries are not generated for @Contract implementations.

I do not believe any META-INF/services are being generated specifically for hk2 contracts. A list of files under META-INF/services (glassfish/modules directory) is below. There are a few things HK2 related (PopulatorPostProcessor etc) but those things are needed there as they have to be there before hk2 services are populated...

batch-config.properties
batch-services.properties
com.ibm.jbatch.tck.spi.BatchContainerServiceProvider
com.sun.enterprise.admin.util.cache.DataProvider
com.sun.enterprise.ee.cms.core.GroupManagementService
com.sun.enterprise.mgmt.transport.NetworkManager
com.sun.faces.spi.FacesConfigResourceProvider
com.sun.faces.spi.injectionprovider
com.sun.faces.spi.injectionprovider
com.sun.security.sasl.preview.SaslClientFactory
com.sun.tools.xjc.Plugin
com.sun.xml.ws.api.config.management.ManagedEndpointFactory
com.sun.xml.ws.api.pipe.TubelineAssemblerFactory
com.sun.xml.ws.api.policy.PolicyResolverFactory
com.sun.xml.ws.api.server.EndpointReferenceExtensionContributor
com.sun.xml.ws.api.wsdl.parser.MetadataResolverFactory
com.sun.xml.ws.policy.jaxws.spi.PolicyFeatureConfigurator
com.sun.xml.ws.policy.jaxws.spi.PolicyMapConfigurator
com.sun.xml.ws.policy.spi.PolicyAssertionCreator
com.sun.xml.ws.policy.spi.PolicyAssertionValidator
com.sun.xml.ws.policy.spi.PrefixMapper
com.sun.xml.ws.security.spi.AlternativeSelector
com.sun.xml.ws.spi.db.BindingContextFactory
faces-config.xml
javax.annotation.processing.Processor
javax.batch.operations.JobOperator
javax.ejb.spi.EJBContainerProvider
javax.enterprise.inject.spi.CDIProvider
javax.enterprise.inject.spi.Extension
javax.enterprise.inject.spi.Extension
javax.enterprise.inject.spi.Extension
javax.enterprise.inject.spi.Extension
javax.enterprise.inject.spi.Extension
javax.enterprise.inject.spi.Extension
javax.management.remote.JMXConnectorProvider
javax.management.remote.JMXConnectorServerProvider
javax.persistence.spi.PersistenceProvider
javax.servlet.ServletContainerInitializer
javax.servlet.ServletContainerInitializer
javax.servlet.ServletContainerInitializer
javax.servlet.ServletContainerInitializer
javax.servlet.ServletContainerInitializer
javax.servlet.ServletContainerInitializer
javax.validation.spi.ValidationProvider
javax.websocket.ContainerProvider
javax.websocket.server.ServerContainerProvider
javax.websocket.server.ServerEndpointConfig$Configurator
javax.ws.rs.ext.RuntimeDelegate
javax.xml.bind.JAXBContext
javax.xml.soap.MessageFactory
javax.xml.soap.MetaFactory
javax.xml.soap.SOAPConnectionFactory
javax.xml.soap.SOAPFactory
javax.xml.stream.XMLEventFactory
javax.xml.stream.XMLInputFactory
javax.xml.stream.XMLOutputFactory
javax.xml.ws.spi.Provider
org.codehaus.stax2.validation.XMLValidationSchemaFactory.dtd
org.codehaus.stax2.validation.XMLValidationSchemaFactory.relaxng
org.codehaus.stax2.validation.XMLValidationSchemaFactory.w3c
org.glassfish.embeddable.spi.RuntimeBuilder
org.glassfish.faces.integration.GlassFishInjectionProvider
org.glassfish.hk2.bootstrap.PopulatorPostProcessor
org.glassfish.hk2.bootstrap.PopulatorPostProcessor
org.glassfish.hk2.bootstrap.PopulatorPostProcessor
org.glassfish.hk2.extension.ServiceLocatorGenerator
org.glassfish.jersey.internal.spi.AutoDiscoverable
org.glassfish.jersey.internal.spi.AutoDiscoverable
org.glassfish.jersey.internal.spi.AutoDiscoverable
org.glassfish.jersey.server.spi.ComponentProvider
org.glassfish.jersey.server.spi.ContainerProvider
org.glassfish.jersey.servlet.spi.AsyncContextDelegateProvider
org.glassfish.tyrus.spi.ComponentProvider
org.iso_relax.verifier.VerifierFactoryLoader
org.relaxng.datatype.DatatypeLibraryFactory

Comment by Sanjeeb Sahoo [ 19/Mar/13 06:25 PM ]

Looks like a regression during HK2 2.x effort. The metadata should be coming from the cache as opposed to from bundles during subsequent restart.

Comment by mtaube [ 19/Mar/13 06:54 PM ]

After look at this I agree with Sahoo, if ModuleMetadata is present in the cache the call to loadMetadata should not be happening. I am investigating this.

Comment by Tom Mueller [ 19/Mar/13 09:15 PM ]

I added some timing statements within the APIClassLoader.getResource where it looks through all of the modules. Here are the results from a server startup:

getResource: META-INF/services/javax.xml.stream.XMLInputFactory 1120
getResource: META-INF/services/javax.xml.stream.XMLInputFactory 1285
getResource: META-INF/services/javax.xml.stream.XMLInputFactory 1006
getResource: META-INF/services/javax.xml.stream.XMLInputFactory 1240
getResource: META-INF/services/javax.xml.stream.XMLInputFactory 860
getResource: META-INF/services/javax.xml.stream.XMLInputFactory 825
getResource: META-INF/services/javax.xml.stream.XMLInputFactory 866
getResource: META-INF/services/javax.xml.stream.XMLInputFactory 868
getResource: META-INF/services/javax.xml.stream.XMLInputFactory 1393
getResource: META-INF/services/javax.xml.stream.XMLInputFactory 1059
getResource: META-INF/services/javax.xml.stream.XMLInputFactory 878
getResource: META-INF/services/javax.xml.stream.XMLInputFactory 1231
getResource: META-INF/services/javax.xml.stream.XMLInputFactory 1339
getResource: META-INF/services/javax.xml.parsers.DocumentBuilderFactory 1800
getResource: META-INF/services/javax.ws.rs.ext.RuntimeDelegate 1494
getResource: META-INF/services/javax.xml.transform.TransformerFactory 1682
getResource: META-INF/services/com.sun.org.apache.xalan.internal.xsltc.dom.XSLTCDTMManager 1172
getResource: META-INF/services/javax.xml.stream.XMLOutputFactory 875

The third column is the time taken in usec. The total time is 21 msec. Given that the total server startup time on the same system is almost 4000 ms, this is probably not work fixing.

Comment by Tom Mueller [ 19/Mar/13 09:31 PM ]

Question: some bundles include a services file manually. (Sorry for the mistake about the annotation process). For example, the nucleus/admin/util module has a services file here:

main/nucleus/admin/util/src/main/resources/META-INF/services/com.sun.enterprise.admin.util.cache.DataProvider:
com.sun.enterprise.admin.util.cache.StringDataProvider
com.sun.enterprise.admin.util.cache.ByteArrayDataProvider
com.sun.enterprise.admin.util.cache.CommandModelDataProvider

Is this file needed? Based on looking at the code that uses DataProvider, it appears that it isn't needed anymore.

Are any of the services files created by GlassFish needed?
If this is a case-by-case situation, I don't know if it is worth it to go through each and every JAR to see if these are needed.

Comment by mtaube [ 19/Mar/13 09:33 PM ]

WRT caching, Tom confirmed that the loadMetadata call happens on a cold boot of a domain but is avoided on subsequent starts (when there are cache hits).

Comment by Sanjeeb Sahoo [ 21/Mar/13 08:37 AM ]

Since cache is consulted during subsequent server startup even for META-INF/services file, why is this bug still open?

Comment by Tom Mueller [ 21/Mar/13 03:18 PM ]

One reason is that we still may have META-INF/services files being included in GlassFish JARs that are not necessary. For example, admin-util.jar had one, but Martin has recently removed it. At the time I created this issue, there were 34 JAR files that have 76 different META-INF/services files. John provided the list of the META-INF/services files above, but not the list of JAR files that contain them. Here's the list:

autostart/osgi-cdi.jar
bean-validator.jar
com.ibm.jbatch-runtime-all.jar
ejb-container.jar
gf-jms-injection.jar
glassfish.jar
hk2-locator.jar
javax.faces.jar
javax.servlet.jsp.jar
jaxb-extra-osgi.jar
jaxb-osgi.jar
jersey-bean-validation.jar
jersey-container-grizzly2-http.jar
jersey-container-servlet.jar
jersey-gf-ejb.jar
jersey-media-json-processing.jar
jersey-server.jar
jmxremote_optional-repackaged.jar
jsf-connector.jar
kernel.jar
ldapbp-repackaged.jar
org.eclipse.persistence.jpa.jar
rest-service.jar
shoal-gms-impl.jar
tyrus-client.jar
tyrus-container-glassfish-cdi.jar
tyrus-container-servlet.jar
tyrus-server.jar
web-sse.jar
webservices-osgi.jar
weld-integration-fragment.jar
weld-integration.jar
woodstox-core-asl.jar

Many of these come from other projects, so we may not be able to eliminate the services files there, but some such as glassfish.jar, kernel.jar and ejb-container.jar probably do not need them.

It is not clear that there is a significant performance gain by fixing this, but we may get to the point where every little bit counts.

Regarding kernel.jar, the source code doesn't have any META-INF/services file, but one is generated. The content is:

$ cat META-INF/services/org.glassfish.hk2.bootstrap.PopulatorPostProcessor
org.glassfish.kernel.embedded.EmbeddedInhabitantsParser

The EmbeddedInhabitantsParser class has the @MetaInfServices annotation which causes the services file to be generated. Does the HK2 PopulatorPostProcessor contract use the JAR service locator mechanism, or does it use hk2-locator information? If it is the latter, then these annotations are not necessary.

The @MetaInfServices annotation is used in three GF JAR files (kernel.jar, glassfish.jar, and rest-service.jar).

Comment by Sanjeeb Sahoo [ 21/Mar/13 03:41 PM ]

No of Java EE technologies still rely on META-INF/services mechanism for them to be plugged into the appserver runtime. e.g., ServletContainerInitializers, Various XML Parser factories, persistence providers, etc. So, it would be very difficult to change them.

glassfish.jar uses META-INF/services to look up GlassFishRuntimeBuilders. So that file will remain that way.

I am not sure about kernel.jar or rest-service.jar.





[GLASSFISH-19717] GlassFish startup makes excessive JAR related system calls Created: 22/Feb/13  Updated: 11/Apr/13  Resolved: 11/Apr/13

Status: Closed
Project: glassfish
Component/s: hk2
Affects Version/s: 4.0_b77
Fix Version/s: 4.0

Type: Bug Priority: Critical
Reporter: Tom Mueller Assignee: mtaube
Resolution: Fixed Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Solaris x86


Tags: devx_web
Participants: mtaube and Tom Mueller

 Description   

A comparison of the truss output from starting the GlassFish DAS shows that the number of JAR related system calls (calls where an argument is a ".jar" file) has increased from 2.9 calls/jar in 3.1.2 to 6.0 calls per/jar in 4.0. The test was run on an already "primed" domain, i.e., the osgi-cache was already populated. Some of the calls are opening the JAR files in the modules directory, which shouldn't be happening (at least it didn't happen in 3.1.2).

This issue is for fixing the JAR handling software (mainly in HK2 and Felix) so that the code is as efficient as 3.1.2 WRT JAR related system calls.

To collect the data, do the following on Solaris:

truss -f -o /tmp/tr.out asadmin start-domain -v

Then find the DAS process (it is the one with the most threads) and grep for output for that process that is accessing JAR files.

Coming up with the command to trace system calls on other operating systems is left as an exercise for the reader.

Contact me if you want the data files that I've already collected.

This issue must be fixed for the 4.0 release, as it is effecting the developer scenario benchmark.



 Comments   
Comment by Tom Mueller [ 22/Feb/13 05:23 PM ]

The following blog post may be useful in diagnosing where the extra system calls are coming from:

http://trmueller.wordpress.com/2011/01/12/using-dtrace-to-find-java-code-that-makes-a-system-call/

Comment by Tom Mueller [ 26/Feb/13 05:30 PM ]

Here's the stack trace for opening kernel.jar

0 2745 open64:entry 788327853983 1087 /home/trm/test/nucleus/nucleus/modules/kernel.jar
libc.so.1`__open64_syscall+0x15
libc.so.1`open64+0xd1
libhpi.so`sysOpen+0x3a
libjvm.so`JVM_Open+0x3d
libzip.so`Java_java_util_zip_ZipFile_open+0x95
java/util/zip/ZipFile.open(Ljava/lang/String;IJ)J
java/util/zip/ZipFile.<init>(Ljava/io/File;I)V
java/util/jar/JarFile.<init>(Ljava/io/File;ZI)V
java/util/jar/JarFile.<init>(Ljava/io/File;)V
org/jvnet/hk2/osgiadapter/OSGiDirectoryBasedRepository.loadJar(Ljava/io/File;)Lcom/sun/enterprise/module/ModuleDefinition;
com/sun/enterprise/module/common_impl/DirectoryBasedRepository.loadModuleDefs(Ljava/util/Map;Ljava/util/List;)V
com/sun/enterprise/module/common_impl/AbstractRepositoryImpl.initialize()V
org/jvnet/hk2/osgiadapter/OSGiDirectoryBasedRepository.initialize()V
org/jvnet/hk2/osgiadapter/HK2Main.createModulesRegistry()Lcom/sun/enterprise/module/ModulesRegistry;
org/jvnet/hk2/osgiadapter/HK2Main.start(Lorg/osgi/framework/BundleContext;)V
org/apache/felix/framework/util/SecureAction.startActivator(Lorg/osgi/framework/BundleActivator;Lorg/osgi/framework/BundleContext;)V
org/apache/felix/framework/Felix.activateBundle(Lorg/apache/felix/framework/BundleImpl;Z)V
org/apache/felix/framework/Felix.startBundle(Lorg/apache/felix/framework/BundleImpl;I)V
org/apache/felix/framework/Felix.setActiveStartLevel(I[Lorg/osgi/framework/FrameworkListener;)V
org/apache/felix/framework/FrameworkStartLevelImpl.run()V
java/lang/Thread.run()V
StubRoutines (1)
libjvm.so`_1cJJavaCallsLcall_helper6FpnJJavaValue_pnMmethodHandle_pnRJavaCallArguments_pnGThreadv+0x1c9
libjvm.so`_1cCosUos_exception_wrapper6FpFpnJJavaValue_pnMmethodHandle_pnRJavaCallArguments_pnGThreadv2468_v+0x27
libjvm.so`_1cJJavaCallsEcall6FpnJJavaValue_nMmethodHandle_pnRJavaCallArguments_pnGThreadv+0x2f
libjvm.so`_1cJJavaCallsMcall_virtual6FpnJJavaValue_nLKlassHandle_nMsymbolHandle_4pnRJavaCallArguments_pnGThreadv+0xc1
libjvm.so`_1cJJavaCallsMcall_virtual6FpnJJavaValue_nGHandle_nLKlassHandle_nMsymbolHandle_5pnGThreadv+0x7e
libjvm.so`_1cMthread_entry6FpnKJavaThread_pnGThreadv+0xd3
libjvm.so`_1cKJavaThreadRthread_main_inner6M_v+0x4c
libjvm.so`_1cKJavaThreadDrun6M_v+0x182
libjvm.so`java_start+0xf9
libc.so.1`_thrp_setup+0x9b
libc.so.1`_lwp_start

This trace was taken after nucleus has been started several times, so the osgi-cache is already populated. None of the files in the modules directory should be opened.

Comment by Tom Mueller [ 13/Mar/13 04:02 PM ]

After the checkin of hk2 2.1.71, I reran the system call test. The number of JAR related system calls has been reduced to 3.9 calls/jar. 626 JAR files are accessed and only 345 are opened (compared to 315 opened in 3.1.2). This is exactly the difference in the number of bundles. So it looks like 4.0 is now opening no more JAR files than are opened in 3.1.2. However, there are still more JAR related system calls: 2429 compared to 1637.

Looking at just one example, class-model.jar, there is 1 stat call in 3.1.2, but there are still 8 stat calls in 4.0 (compared to 13 before this fix).

Comment by Tom Mueller [ 13/Mar/13 09:39 PM ]

I ran some additional tests to compare 3.1.2 and 4.0 WRT JAR-related system calls. Looking specifically at common-util.jar, I see 3.1.2 making 3 stat calls while 4.0 makes 5 stat calls. The 2 extra calls come from HK2Main.createModulesRegistry. Here are the stack traces:

0 2725 stat64:entry 13476078456569 3289 /home/trm/test/nucleus/modules/common-util.jar
libc.so.1`stat64+0x15
java/io/UnixFileSystem.getBooleanAttributes0(Ljava/io/File;)I
java/io/UnixFileSystem.getBooleanAttributes(Ljava/io/File;)I
java/io/File.isDirectory()Z
com/sun/enterprise/module/common_impl/DirectoryBasedRepository$1.accept(Ljava/io/File;)Z
java/io/File.listFiles(Ljava/io/FileFilter[Ljava/io/File;
com/sun/enterprise/module/common_impl/DirectoryBasedRepository.<init>(Ljava/lang/String;Ljava/io/File;)V
com/sun/enterprise/module/common_impl/DirectoryBasedRepository.<init>(Ljava/lang/String;Ljava/io/File;Z)V
org/jvnet/hk2/osgiadapter/OSGiDirectoryBasedRepository.<init>(Ljava/lang/String;Ljava/io/File;Z)V
org/jvnet/hk2/osgiadapter/OSGiDirectoryBasedRepository.<init>(Ljava/lang/String;Ljava/io/File;)V
org/jvnet/hk2/osgiadapter/HK2Main.createModulesRegistry()Lcom/sun/enterprise/module/ModulesRegistry;
org/jvnet/hk2/osgiadapter/HK2Main.start(Lorg/osgi/framework/BundleContext;)V
org/apache/felix/framework/util/SecureAction.startActivator(Lorg/osgi/framework/BundleActivator;Lorg/osgi/framework/BundleContext;)V
org/apache/felix/framework/Felix.activateBundle(Lorg/apache/felix/framework/BundleImpl;Z)V
org/apache/felix/framework/Felix.startBundle(Lorg/apache/felix/framework/BundleImpl;I)V
org/apache/felix/framework/Felix.setActiveStartLevel(I[Lorg/osgi/framework/FrameworkListener;)V
org/apache/felix/framework/FrameworkStartLevelImpl.run()V
java/lang/Thread.run()V
StubRoutines (1)
libjvm.so`_1cJJavaCallsLcall_helper6FpnJJavaValue_pnMmethodHandle_pnRJavaCallArguments_pnGThreadv+0x1c9
libjvm.so`_1cCosUos_exception_wrapper6FpFpnJJavaValue_pnMmethodHandle_pnRJavaCallArguments_pnGThreadv2468_v+0x27
libjvm.so`_1cJJavaCallsEcall6FpnJJavaValue_nMmethodHandle_pnRJavaCallArguments_pnGThreadv+0x2f
libjvm.so`_1cJJavaCallsMcall_virtual6FpnJJavaValue_nLKlassHandle_nMsymbolHandle_4pnRJavaCallArguments_pnGThreadv+0xc1
libjvm.so`_1cJJavaCallsMcall_virtual6FpnJJavaValue_nGHandle_nLKlassHandle_nMsymbolHandle_5pnGThreadv+0x7e
libjvm.so`_1cMthread_entry6FpnKJavaThread_pnGThreadv+0xd3
libjvm.so`_1cKJavaThreadRthread_main_inner6M_v+0x4c
libjvm.so`_1cKJavaThreadDrun6M_v+0x182
libjvm.so`java_start+0xf9
libc.so.1`_thrp_setup+0x9b
libc.so.1`_lwp_start

0 2725 stat64:entry 13476082740315 3289 /home/trm/test/nucleus/modules/common-util.jar
libc.so.1`stat64+0x15
java/io/UnixFileSystem.getBooleanAttributes0(Ljava/io/File;)I
java/io/UnixFileSystem.getBooleanAttributes(Ljava/io/File;)I
java/io/File.isDirectory()Z
java/io/File.toURI()Ljava/net/URI;
org/jvnet/hk2/osgiadapter/OSGiDirectoryBasedRepository.loadJar(Ljava/io/File;)Lcom/sun/enterprise/module/ModuleDefinition;
com/sun/enterprise/module/common_impl/DirectoryBasedRepository.loadModuleDefs(Ljava/util/Map;Ljava/util/List;)V
com/sun/enterprise/module/common_impl/AbstractRepositoryImpl.initialize()V
org/jvnet/hk2/osgiadapter/OSGiDirectoryBasedRepository.initialize()V
org/jvnet/hk2/osgiadapter/HK2Main.createModulesRegistry()Lcom/sun/enterprise/module/ModulesRegistry;
org/jvnet/hk2/osgiadapter/HK2Main.start(Lorg/osgi/framework/BundleContext;)V
org/apache/felix/framework/util/SecureAction.startActivator(Lorg/osgi/framework/BundleActivator;Lorg/osgi/framework/BundleContext;)V
org/apache/felix/framework/Felix.activateBundle(Lorg/apache/felix/framework/BundleImpl;Z)V
org/apache/felix/framework/Felix.startBundle(Lorg/apache/felix/framework/BundleImpl;I)V
org/apache/felix/framework/Felix.setActiveStartLevel(I[Lorg/osgi/framework/FrameworkListener;)V
org/apache/felix/framework/FrameworkStartLevelImpl.run()V
java/lang/Thread.run()V
StubRoutines (1)
libjvm.so`_1cJJavaCallsLcall_helper6FpnJJavaValue_pnMmethodHandle_pnRJavaCallArguments_pnGThreadv+0x1c9
libjvm.so`_1cCosUos_exception_wrapper6FpFpnJJavaValue_pnMmethodHandle_pnRJavaCallArguments_pnGThreadv2468_v+0x27
libjvm.so`_1cJJavaCallsEcall6FpnJJavaValue_nMmethodHandle_pnRJavaCallArguments_pnGThreadv+0x2f
libjvm.so`_1cJJavaCallsMcall_virtual6FpnJJavaValue_nLKlassHandle_nMsymbolHandle_4pnRJavaCallArguments_pnGThreadv+0xc1
libjvm.so`_1cJJavaCallsMcall_virtual6FpnJJavaValue_nGHandle_nLKlassHandle_nMsymbolHandle_5pnGThreadv+0x7e
libjvm.so`_1cMthread_entry6FpnKJavaThread_pnGThreadv+0xd3
libjvm.so`_1cKJavaThreadRthread_main_inner6M_v+0x4c
libjvm.so`_1cKJavaThreadDrun6M_v+0x182
libjvm.so`java_start+0xf9
libc.so.1`_thrp_setup+0x9b
libc.so.1`_lwp_start

This might be related to issue GLASSFISH-19164.





[GLASSFISH-19420] BV bundles exports javax.validation package with wrong version Created: 10/Dec/12  Updated: 13/Dec/12  Resolved: 13/Dec/12

Status: Closed
Project: glassfish
Component/s: bean-validator
Affects Version/s: 4.0_b66
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Sanjeeb Sahoo Assignee: mtaube
Resolution: Fixed Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: mtaube and Sanjeeb Sahoo

 Description   

It is showing version as 1.1.0.Alpha2 which is not what bean-validator 5.0.0.Alpha2 uses. Who reviewed this pom?



 Comments   
Comment by mtaube [ 13/Dec/12 08:59 PM ]

This was rolled back in hk2, r4153





[GLASSFISH-19285] Validator and Validator Factory References Not injected due to bad JNDI name. Created: 05/Nov/12  Updated: 21/May/13

Status: Open
Project: glassfish
Component/s: bean-validator
Affects Version/s: 3.1.2
Fix Version/s: None

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

Linux ( Ubuntu-Server 12.04 LTS _Precise Pangolin )


File Attachments: File stack-trace    
Tags:
Participants: mtaube and ritzpar

 Description   

ValidatorFactory does not get injected due to bad JNDI name.

I've declared it in my EJB.

@Resource
private ValidatorFactory validatorFactory;

I've attached the stack trace. After reading the jee 1.6 whitepapers ( section EE.5.16 ), it is my understanding
that a declaration of the resource is enough to get a reference to it.






[GLASSFISH-19268] Exception during startup related to MultiMap Created: 31/Oct/12  Updated: 25/Feb/13  Resolved: 25/Feb/13

Status: Closed
Project: glassfish
Component/s: hk2
Affects Version/s: 4.0_b60
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Sanjeeb Sahoo Assignee: mtaube
Resolution: Fixed Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: mtaube and Sanjeeb Sahoo

 Description   

You need to start the server two times in identical fashion to reproduce this problem, as it is related to cache and cache is recreated if startup options are changed. So, do the following:

'asadmin start-domain -v'
Let the server start. Then stop or kill it.
Run 'asadmin start-domain -v' again to see the following exception in the console (it appears at the beginning):

31 Oct, 2012 4:11:20 PM OSGiDirectoryBasedRepository initialize
WARNING: Cache disabled because of exception:
java.lang.ClassNotFoundException: org.jvnet.hk2.component.MultiMap
at java.net.URLClassLoader$1.run(URLClassLoader.java:202)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
at java.lang.ClassLoader.loadClass(ClassLoader.java:247)
at org.apache.felix.framework.BundleWiringImpl.doImplicitBootDelegation(BundleWiringImpl.java:1666)
at org.apache.felix.framework.BundleWiringImpl.searchDynamicImports(BundleWiringImpl.java:1603)
at org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1439)
at org.apache.felix.framework.BundleWiringImpl.access$400(BundleWiringImpl.java:72)
at org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:1843)
at java.lang.ClassLoader.loadClass(ClassLoader.java:247)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:247)
at java.io.ObjectInputStream.resolveClass(ObjectInputStream.java:603)
at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1574)
at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1495)
at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1731)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1328)
at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1946)
at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1870)
at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1752)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1328)
at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1946)
at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1870)
at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1752)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1328)
at java.io.ObjectInputStream.readObject(ObjectInputStream.java:350)
at java.util.HashMap.readObject(HashMap.java:1030)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:969)
at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1848)
at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1752)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1328)
at java.io.ObjectInputStream.readObject(ObjectInputStream.java:350)
at org.jvnet.hk2.osgiadapter.OSGiDirectoryBasedRepository.loadCachedData(OSGiDirectoryBasedRepository.java:110)
at org.jvnet.hk2.osgiadapter.OSGiDirectoryBasedRepository.initialize(OSGiDirectoryBasedRepository.java:82)
at org.jvnet.hk2.osgiadapter.HK2Main.createModulesRegistry(HK2Main.java:222)
at org.jvnet.hk2.osgiadapter.HK2Main.start(HK2Main.java:170)
at org.apache.felix.framework.util.SecureAction.startActivator(SecureAction.java:641)
at org.apache.felix.framework.Felix.activateBundle(Felix.java:1977)
at org.apache.felix.framework.Felix.startBundle(Felix.java:1895)
at org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1191)
at org.apache.felix.framework.FrameworkStartLevelImpl.run(FrameworkStartLevelImpl.java:295)
at java.lang.Thread.run(Thread.java:662)






Bean Validation 1.1 (GLASSFISH-19196)

[GLASSFISH-19199] CDI support for Bean Validation 1.1 Created: 19/Oct/12  Updated: 27/Mar/13  Resolved: 27/Mar/13

Status: Closed
Project: glassfish
Component/s: bean-validator
Affects Version/s: None
Fix Version/s: None

Type: Sub-task Priority: Major
Reporter: tlcksnyder Assignee: mtaube
Resolution: Fixed Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: ee7beanval
Participants: mtaube and tlcksnyder




Bean Validation 1.1 (GLASSFISH-19196)

[GLASSFISH-19198] JPA support for Bean Validation 1.1 Created: 19/Oct/12  Updated: 23/Jan/13  Resolved: 23/Jan/13

Status: Closed
Project: glassfish
Component/s: bean-validator
Affects Version/s: None
Fix Version/s: None

Type: Sub-task Priority: Major
Reporter: tlcksnyder Assignee: mtaube
Resolution: Fixed Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: ee7beanval
Participants: mtaube and tlcksnyder




Bean Validation 1.1 (GLASSFISH-19196)

[GLASSFISH-19197] JSF support for Bean Validation 1.1 Created: 19/Oct/12  Updated: 23/Jan/13  Resolved: 23/Jan/13

Status: Closed
Project: glassfish
Component/s: bean-validator
Affects Version/s: None
Fix Version/s: None

Type: Sub-task Priority: Major
Reporter: tlcksnyder Assignee: mtaube
Resolution: Fixed Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: ee7beanval
Participants: mtaube and tlcksnyder




[GLASSFISH-19196] Bean Validation 1.1 Created: 19/Oct/12  Updated: 27/Mar/13  Resolved: 27/Mar/13

Status: Closed
Project: glassfish
Component/s: bean-validator
Affects Version/s: 4.0_b57
Fix Version/s: 4.0_b82_EE7MS7

Type: New Feature Priority: Major
Reporter: tlcksnyder Assignee: mtaube
Resolution: Fixed Votes: 0
Σ Remaining Estimate: Not Specified Remaining Estimate: Not Specified
Σ Time Spent: Not Specified Time Spent: Not Specified
Σ Original Estimate: Not Specified Original Estimate: Not Specified

Sub-Tasks:
Key
Summary
Type
Status
Assignee
GLASSFISH-19197 JSF support for Bean Validation 1.1 Sub-task Closed mtaube  
GLASSFISH-19198 JPA support for Bean Validation 1.1 Sub-task Closed mtaube  
GLASSFISH-19199 CDI support for Bean Validation 1.1 Sub-task Closed mtaube  
Tags: ee7beanval
Participants: mtaube and tlcksnyder

 Description   

Add support for Bean Validation 1.1. Uptake latest Hibernate validator jars.






[GLASSFISH-19164] [PERF] HK2Main.createModulesRegistry has large regression Created: 16/Oct/12  Updated: 19/Mar/13  Resolved: 19/Mar/13

Status: Resolved
Project: glassfish
Component/s: hk2
Affects Version/s: 4.0_b55
Fix Version/s: 4.0

Type: Bug Priority: Major
Reporter: Scott Oaks Assignee: mtaube
Resolution: Fixed Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: PSRBUG devx_web
Participants: jwells, mtaube, Sanjeeb Sahoo, Scott Oaks and Tom Mueller

 Description   

HK2Main.createModulesRegistry has regressed in performance, increasing start-up time by about 0.6 seconds for glassfish 4.0 compared to 3.1.2.

The regression comes entirely from the new call to OSGiDirectoryBasedRepository.initialize(). There are no similar calls in 3.1.2 – how as the module directory repository initialized in that case? Given that the module directory rarely changes, is there some way we could keep the initialization information elsehwhere and not re-initialize it each startup?



 Comments   
Comment by Scott Oaks [ 22/Oct/12 02:35 PM ]

Sahoo, you're listed as the author of the code in the comments, so I'm assigning to you first.

Comment by Sanjeeb Sahoo [ 22/Oct/12 08:32 PM ]

Which build did this regression get in? Is it possible that this is a caused by HK2 2.x integration? As part of that integration, they removed a caching that was happening earlier.

Comment by Sanjeeb Sahoo [ 22/Oct/12 08:33 PM ]

Assigning to Mason to bring back the caching.

Comment by jwells [ 11/Feb/13 09:42 PM ]

We have removed caching for now, so the initialize method should be nearly nothing. We removed it because it did not offer any improvement over simply re-reading the descriptor files with the new descriptor reading algorithm.

Please re-test, thanks!

Comment by Tom Mueller [ 22/Feb/13 04:07 PM ]

Automated testing is available via the following hudson job:
http://hudson-sca.us.oracle.com/job/as-dev-benchmark-trunk-win/

No need to reassign to Scott for testing.

Comment by mtaube [ 06/Mar/13 04:19 PM ]

we're hoping that the reintroduction of caching (of metadata) will help with this, I'm building a glassfish distribution with this change that john is going to test with the various developer benchmarks

Comment by Tom Mueller [ 18/Mar/13 09:51 PM ]

A profile of the current 4.0 trunk shows that the call to OSGiDirectoryBasedRepository.initialize() takes about 22 ms, compared to a total time for HK2Main.createModulesRegistry of 1406 ms. So it appears that the OSGiDirectoryBasedRepository.initialize call is no longer a significant factory in the createModulesRegistry call.

Comment by Sanjeeb Sahoo [ 19/Mar/13 03:31 AM ]

Tom,

I am now confused. The submitter attributed the regression entirely to OSGiDirectoryBasedRepository.initialize as I quote below:

The regression comes entirely from the new call to OSGiDirectoryBasedRepository.initialize(). There are no similar calls in 3.1.2 – how as the module directory repository initialized in that case? Given that the module directory rarely changes, is there some way we could keep the initialization information elsehwhere and not re-initialize it each startup?

I was not surprised by this finding as I knew a vital HK2 cache was removed during HK2 2.x effort. I am glad finally they have tried to bring it back although they have had difference in opinion about its effectiveness. Since Mason has not marked this bug fixed, nor has he provided actual svn revision details for his change, I am only assuming you tested with caching enabled and found that OSGiDirectoryBasedRepository.initialize was no longer taking significant time. If this is correct, could we close mark this bug as RESOLVED and open a new one to track the regression in other parts of createModulesRegistry call stack? This will also conclusively justify the need for that HK2 cache. Looking at the timing distribution, I think the submitter didn't notice this part of the regression during their initial analysis as they were driven off track by the big regression caused by OSGiDirectoryBasedRespoistory.initialize in the same code path. I sincerely think we should open a new bug for the second issue. Looking at the data you have posted, I still think caching is not taking effect in all code paths.

Sahoo

Comment by Tom Mueller [ 19/Mar/13 04:00 PM ]

A new issue, GLASSFISH-19940, has been created for further improvements that might effect createModulesRegistry (and other parts of the system).

Since the original goal of this issue has been met, it can be marked as resolved.





[GLASSFISH-19121] NoSuchFieldError in jpa 9539 se test Created: 03/Oct/12  Updated: 03/Oct/12  Resolved: 03/Oct/12

Status: Resolved
Project: glassfish
Component/s: entity-persistence
Affects Version/s: 4.0_b56_ms5
Fix Version/s: 4.0_b56_ms5

Type: Bug Priority: Major
Reporter: sherryshen Assignee: Mitesh Meswani
Resolution: Fixed Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

RHL 5.0 and JDK1.7.0_03-64


File Attachments: Zip Archive 9539.zip    
Tags:
Participants: Mitesh Meswani, mtaube and sherryshen

 Description   

NoSuchFieldError in jpa 9539 se test

glassfish-4.0-b56.zip

appserver-sqe/pe/ejb/ejb30/issue/9539
The test failed to insert data with image on se_j2db, b56
http://javaweb.us.oracle.com/net/asqe-logs/export1/4.0/Results/build56/core/das/output/ejb30_issue_se_j2db.output
[java] java.lang.NoSuchFieldError: TRACE



 Comments   
Comment by sherryshen [ 03/Oct/12 03:14 AM ]

Attached 9539.zip has test source.

The test is based on the issue in
http://java.net/jira/browse/GLASSFISH-9539
The test passed on b55
http://javaweb.us.oracle.com/net/asqe-logs/export1/4.0/Results/build55/core/das/output/ejb30_issue_se_j2db.output

To reproduce the issue in sqe core test env on das
$ cd appserver-sqe/pe/ejb/ejb30/issue/9539
$ ant all_se
Please reference core instruction for env
http://aseng-wiki.us.oracle.com/asengwiki/display/ASQA/4.0+Core+Test+Instructions

Comment by mtaube [ 03/Oct/12 04:00 PM ]

This target is picking up a log4j jar in the classpath. I don't know what's in db.root or SPS_HOME, but I suspect it is in one of those two places.

The new version of hibernate-validator requires log4j if it is present to be version 1.2.12 or newer.

<target name="run_se" depends="init-common">
<java classname="ejb30.issue.TestClient" fork="true">
<classpath>
<pathelement location="classes/META-INF"/>
<pathelement location="classes"/>
<fileset dir="${env.S1AS_HOME}/modules">
<include name="*/.jar"/>
</fileset>
<fileset dir="${db.root}/lib">
<include name="*/.jar"/>
</fileset>
<fileset dir="${env.SPS_HOME}/lib">
<include name="*/.jar"/>
</fileset>
</classpath>
<arg value="${testsuite.id}SE-J2DB:"/>
</java>
</target>

Comment by sherryshen [ 03/Oct/12 11:50 PM ]

Thank Mason and Mitesh for the analysis.
The offending log4j is coming from appserver-sqe/lib/jalopy/log4j-1.2.6.jar.
The test passed after build.xml is modified to exclude old version of log4j.

Index: build.xml
===================================================================
RCS file: /m/jws/appserver-sqe/pe/ejb/ejb30/issue/9539/build.xml,v
retrieving revision 1.7
retrieving revision 1.8
diff -c -r1.7 -r1.8

      • build.xml 2010/01/27 17:40:11 1.7
      • build.xml 2012/10/03 23:45:40 1.8
        ***************
      • 122,129 ****
        <fileset dir="${db.root}/lib">
        <include name="*/.jar"/>
        </fileset>
        ! <fileset dir="${env.SPS_HOME}/lib">
        <include name="*/.jar"/>
        </fileset>
        </classpath>
        <arg value="${testsuite.id}SE-J2DB:"/>
        — 122,132 ----
        <fileset dir="${db.root}/lib">
        <include name="*/.jar"/>
        </fileset>
        ! <fileset dir="${env.SPS_HOME}/lib/drivers">
        <include name="*/.jar"/>
        + </fileset>
        + <fileset dir="${env.SPS_HOME}/lib">
        + <include name="reporter.jar"/>
        </fileset>
        </classpath>
        <arg value="${testsuite.id}SE-J2DB:"/>




[GLASSFISH-19022] undeploying an osgi bundle having HK2 services result in stale service entries in the runtime Created: 20/Aug/12  Updated: 02/Oct/12  Resolved: 02/Oct/12

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

Type: Bug Priority: Major
Reporter: Jagadish Assignee: mtaube
Resolution: Fixed Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: hk2 osgi
Participants: Jagadish and mtaube

 Description   

We use "deploy --type osgi <osgi-enabled-hk2-bundle>.jar" which helps to install an osgi bundle as application in GlassFish
This also exposes the hk2 services in the bundle.
When uninstalling the bundle (or via "undeploy appName") that has hk2 services, these services are still listed in the runtime.
eg: habitat.getAllByContract(..) will also list the HK2 Service implementation that was actually removed as part of uninstalling the bundle.
Accessing such an entry results in class-not-found-exceptions.

This seems to be a bug. Once GlassFish is restarted, the stale entries are removed as expected.



 Comments   
Comment by mtaube [ 02/Oct/12 03:33 PM ]

This should be fixed at revision 56196, I've verified it on the hk2 side with a pax-based integration test.





[GLASSFISH-18989] Embedded Server cannot start Created: 09/Aug/12  Updated: 17/Dec/12  Resolved: 17/Dec/12

Status: Closed
Project: glassfish
Component/s: hk2
Affects Version/s: 4.0_b49
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Amy Roh Assignee: mtaube
Resolution: Fixed Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: Amy Roh and mtaube

 Description   

Embedded Server cannot be started using the glassfish-embedded-all.jar from the trunk. It seem to be related to recent hk2 update.

GlassFish glassfish = GlassFishRuntime.bootstrap().newGlassFish();
glassfish.start();

Exception in thread "main" org.glassfish.embeddable.GlassFishException: com.sun.enterprise.module.bootstrap.BootException: Cannot find null ModuleStartup
at com.sun.enterprise.glassfish.bootstrap.StaticGlassFishRuntime.newGlassFish(StaticGlassFishRuntime.java:149)
at SimpleTest.main(SimpleTest.java:60)
Caused by: com.sun.enterprise.module.bootstrap.BootException: Cannot find null ModuleStartup
at com.sun.enterprise.module.bootstrap.Main.findStartupService(Main.java:227)
at com.sun.enterprise.glassfish.bootstrap.StaticGlassFishRuntime.newGlassFish(StaticGlassFishRuntime.java:117)



 Comments   
Comment by mtaube [ 14/Aug/12 01:55 PM ]

when building the distribution, maven-antrun-extended-plugin is not concatenating hk2 descriptor files. maven-antrun-extended-plugin needs to be updated to account for this.





[GLASSFISH-18977] HK2 metadata caching has been disabled during HK2 integration Created: 05/Aug/12  Updated: 13/Mar/13  Resolved: 13/Mar/13

Status: Closed
Project: glassfish
Component/s: hk2
Affects Version/s: 4.0_b45
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Sanjeeb Sahoo Assignee: mtaube
Resolution: Fixed Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: mtaube and Sanjeeb Sahoo

 Description   

Pl. bring the caching back.






[GLASSFISH-18955] embedded web container does not shutdown properly Created: 27/Jul/12  Updated: 17/Sep/12  Resolved: 17/Sep/12

Status: Resolved
Project: glassfish
Component/s: web_container
Affects Version/s: 4.0
Fix Version/s: 4.0_b55

Type: Bug Priority: Critical
Reporter: Sanjeeb Sahoo Assignee: Amy Roh
Resolution: Fixed Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: Amy Roh, jwells, mtaube, Sanjeeb Sahoo and Shing Wai Chan

 Description   

During embedded testing I noticed that embedded web container is not shutting down properly. Basically WebContainer.preDestroy() needs to undo everything that happens in WebContainer.postConstruct().

If you want to experiment, the quickest way to try is to do the following:

Copy a web app to domain1/autodeploy/

java -DGlassFish_Interactive=true -jar glassfish.jar

You will see a prompt after sometime. Type:
start

It will start GlassFish and deploy the web app. Now you can access the web app.
Now type:
stop
It will stop GlassFish.
Then start again.
You will see an NPE like this:

[#|2012-07-27T23:35:25.988+0530|WARNING|44.0|javax.enterprise.system.container.web.com.sun.enterprise.web.connector|_ThreadID=10;_ThreadName=main;|Error registering contexts
java.lang.NullPointerException
at com.sun.enterprise.web.connector.MapperListener.init(MapperListener.java:193)
at com.sun.enterprise.web.connector.coyote.PECoyoteConnector.start(PECoyoteConnector.java:549)
at org.apache.catalina.startup.Embedded.start(Embedded.java:932)
at com.sun.enterprise.web.WebContainer.postConstruct(WebContainer.java:604)
at com.sun.hk2.component.AbstractCreatorImpl.inject(AbstractCreatorImpl.java:132)
at com.sun.hk2.component.ConstructorCreator.initialize(ConstructorCreator.java:117)
at com.sun.hk2.component.AbstractCreatorImpl.get(AbstractCreatorImpl.java:84)
at com.sun.hk2.component.SingletonInhabitant.get(SingletonInhabitant.java:67)
at com.sun.hk2.component.EventPublishingInhabitant.get(EventPublishingInhabitant.java:141)
at com.sun.hk2.component.AbstractInhabitantImpl.get(AbstractInhabitantImpl.java:135)
at org.glassfish.internal.data.EngineInfo.getContainer(EngineInfo.java:93)
at com.sun.enterprise.v3.server.ApplicationLifecycle.startContainers(ApplicationLifecycle.java:997)
at com.sun.enterprise.v3.server.ApplicationLifecycle.setupContainerInfos(ApplicationLifecycle.java:707)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:372)
at com.sun.enterprise.v3.server.ApplicationLoaderService.processApplication(ApplicationLoaderService.java:393)
at com.sun.enterprise.v3.server.ApplicationLoaderService.postConstruct(ApplicationLoaderService.java:229)
at com.sun.hk2.component.AbstractCreatorImpl.inject(AbstractCreatorImpl.java:132)
at com.sun.hk2.component.ConstructorCreator.initialize(ConstructorCreator.java:117)
at com.sun.hk2.component.AbstractCreatorImpl.get(AbstractCreatorImpl.java:84)
at com.sun.hk2.component.SingletonInhabitant.get(SingletonInhabitant.java:67)
at com.sun.hk2.component.EventPublishingInhabitant.get(EventPublishingInhabitant.java:141)
at com.sun.hk2.component.AbstractInhabitantImpl.get(AbstractInhabitantImpl.java:135)
at com.sun.enterprise.v3.server.StartupRunLevelBridge.activate(StartupRunLevelBridge.java:93)
at com.sun.enterprise.v3.server.RunLevelBridge.postConstruct(RunLevelBridge.java:110)
at com.sun.enterprise.v3.server.StartupRunLevelBridge.postConstruct(StartupRunLevelBridge.java:65)
at com.sun.hk2.component.AbstractCreatorImpl.inject(AbstractCreatorImpl.java:132)
at com.sun.hk2.component.ConstructorCreator.initialize(ConstructorCreator.java:117)
at com.sun.hk2.component.AbstractCreatorImpl.get(AbstractCreatorImpl.java:84)
at com.sun.hk2.component.SingletonInhabitant.get(SingletonInhabitant.java:67)
at com.sun.hk2.component.EventPublishingInhabitant.get(EventPublishingInhabitant.java:141)
at com.sun.hk2.component.EventPublishingInhabitant.get(EventPublishingInhabitant.java:141)
at com.sun.hk2.component.RunLevelInhabitant.get(RunLevelInhabitant.java:110)
at com.sun.hk2.component.AbstractInhabitantImpl.get(AbstractInhabitantImpl.java:135)
at com.sun.enterprise.v3.server.AppServerStartup$StartupInhabitantActivator.activate(AppServerStartup.java:526)
at org.jvnet.hk2.component.internal.runlevel.DefaultRunLevelService$Worker.activateRunLevel(DefaultRunLevelService.java:1106)
at org.jvnet.hk2.component.internal.runlevel.DefaultRunLevelService$Worker.upActiveRecorder(DefaultRunLevelService.java:1060)
at org.jvnet.hk2.component.internal.runlevel.DefaultRunLevelService$Worker.run(DefaultRunLevelService.java:1026)
at org.jvnet.hk2.component.internal.runlevel.DefaultRunLevelService$SyncProceedToOp.proceedTo(DefaultRunLevelService.java:1256)
at org.jvnet.hk2.component.internal.runlevel.DefaultRunLevelService.proceedTo(DefaultRunLevelService.java:797)
at org.jvnet.hk2.component.internal.runlevel.DefaultRunLevelService.proceedTo(DefaultRunLevelService.java:759)
at com.sun.enterprise.v3.server.AppServerStartup.proceedTo(AppServerStartup.java:360)
at com.sun.enterprise.v3.server.AppServerStartup.run(AppServerStartup.java:254)
at com.sun.enterprise.v3.server.AppServerStartup.doStart(AppServerStartup.java:172)
at com.sun.enterprise.v3.server.AppServerStartup.start(AppServerStartup.java:163)
at com.sun.enterprise.glassfish.bootstrap.GlassFishImpl.start(GlassFishImpl.java:79)
at com.sun.enterprise.glassfish.bootstrap.GlassFishDecorator.start(GlassFishDecorator.java:63)
at com.sun.enterprise.glassfish.bootstrap.osgi.EmbeddedOSGiGlassFishImpl.start(EmbeddedOSGiGlassFishImpl.java:73)
at com.sun.enterprise.glassfish.bootstrap.GlassFishDecorator.start(GlassFishDecorator.java:63)
at com.sun.enterprise.glassfish.bootstrap.osgi.OSGiGlassFishImpl.start(OSGiGlassFishImpl.java:71)
at com.sun.enterprise.glassfish.bootstrap.GlassFishMain$Launcher.startConsole(GlassFishMain.java:129)
at com.sun.enterprise.glassfish.bootstrap.GlassFishMain$Launcher.launch(GlassFishMain.java:115)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at com.sun.enterprise.glassfish.bootstrap.GlassFishMain.main(GlassFishMain.java:97)
at com.sun.enterprise.glassfish.bootstrap.ASMain.main(ASMain.java:55)

#]

Please treat this urgently.



 Comments   
Comment by Shing Wai Chan [ 27/Jul/12 10:01 PM ]

I have the latest workspace. I do not see the NPE mentioned above. Can you try with the latest workspace?

Comment by Sanjeeb Sahoo [ 30/Jul/12 04:10 AM ]

Good to know the NPE does not appear with latest code. Does the webapp actually work after embedded server is restarted?

Comment by Shing Wai Chan [ 30/Jul/12 10:55 PM ]

The connector is not working after running "stop" and "start" again.
Can you clarify what "-DGlassFish_Interactive=true", "stop" and "start" are doing?
Is it a new feature?
I do not see WebContainer.preDestroy is called from the debugger.

Comment by Sanjeeb Sahoo [ 31/Jul/12 01:16 AM ]

Shingwai,

That's what was my observation as well. Connectors are not working after embedded server is restarted. I do believe it's a problem with WebContainer.preDestroy() which is not undoing everything that has happened in postConstruct(). I applied the following patch in my local workspace to fix the connectors issue:

ss141213@Sahoo:/space/ss141213/WS/gf/trunk$ git diff appserver/web
diff --git a/appserver/web/web-glue/src/main/java/com/sun/enterprise/web/WebContainer.java b/appserver/web/web-glue/src/main/java/com/sun/enterprise/web/WebContainer.java
index 68f6c37..eed42ac 100644
— a/appserver/web/web-glue/src/main/java/com/sun/enterprise/web/WebContainer.java
+++ b/appserver/web/web-glue/src/main/java/com/sun/enterprise/web/WebContainer.java
@@ -634,7 +634,12 @@ public class WebContainer implements org.glassfish.api.container.Container, Post
}

public void preDestroy() {
+ // FIX ME: preDestroy should be just the ooposite of postConstruct, but I am not sure why it is not
try {
+ for (WebConnector c : new ArrayList<WebConnector>(connectorMap.values())) { + deleteConnector(c); + System.out.println("WebContainer.preDestroy " + c); + }
_embedded.stop();
} catch (LifecycleException le) {
_logger.log(Level.SEVERE,

But, even then something is broken. There after I decided to open this bug.

To answer your question about -DGlassFish_Interactive, start, stop, no, they have been there in the code base for a couple of years now. We internally use them to try out embedded features. It's so much simpler to use them rather than having to write a new program to describe a bug.

Comment by Shing Wai Chan [ 31/Jul/12 09:55 PM ]

Is it related to embedded restart. Assign to Amy for further investigation.

Comment by Amy Roh [ 06/Aug/12 09:47 PM ]

Sahoo,

Which embedded jar are you using? I can't start the embedded server using the latest trunk.

org.glassfish.embeddable.GlassFishException: com.sun.enterprise.module.bootstrap.BootException: Cannot find main module : no such module
at com.sun.enterprise.glassfish.bootstrap.StaticGlassFishRuntime.newGlassFish(StaticGlassFishRuntime.java:155)
....
Caused by: com.sun.enterprise.module.bootstrap.BootException: Cannot find main module : no such module
at com.sun.enterprise.module.bootstrap.Main.findStartupService(Main.java:234)
at com.sun.enterprise.glassfish.bootstrap.StaticGlassFishRuntime.newGlassFish(StaticGlassFishRuntime.java:123)

Comment by Sanjeeb Sahoo [ 08/Aug/12 08:33 AM ]

Amy,

As I mentioned in the bug notes, I am using the regular glassfish.jar that exists in glassfish/modules dir. Just follow the instruction provided in the bug description. Shingwai has already reproduced it.

Thanks,
Sahoo

Comment by Amy Roh [ 08/Aug/12 11:33 PM ]

I confirm that WebContainer#preDestroy/postConstruct are never invoked during GlassFish#stop/start. Shouldn't these be called from GlassFish? AppServerContext#serverStopping() is never invoked during server stop and the old WebContainer is used rather than a new WebContainer getting created via WebContainer#postConstruct.

Comment by Sanjeeb Sahoo [ 09/Aug/12 01:20 AM ]

Amy,

The behavior you have observed must be to do with recent HK2 2.1.x integration. But, when I filed the bug, I used a version of glassfish that used HK2 2.0.x and there I did notice preDestroy() getting called. Since you should not be worrying about these details, I recommend you using GlassFish 3.1.2 to reproduce the bug and fix it. Or, you can use 4weeks older trunk builds of GlassFish as well. Upto you. The fix will be equally applicable to most recent workspace.

Thanks much,
Sahoo

Comment by Amy Roh [ 09/Aug/12 08:54 PM ]

I've put in an incremental fix (55377) but this needs to be investigated further.

The trunk needs to be fixed so that WebContainer#preDestroy/postConstruct are invoked during GlassFish#stop/start.

Comment by Amy Roh [ 10/Aug/12 05:02 AM ]

If I manually invoke preDestroy/postConstruct during glassfish restart using EventListener, I can access 8080 after restart with the patch but I still get 404 for previously deployed webapps so something else is broken here. I'll investigate this further when I get back.

Assigning to hk2 so WebContainer is destroyed during shutdown so it can be started via postConstruct during restart. Embedded server start is also broken as described in GLASSFISH-18989. Please assign it back to me once AppServerContext is fixed to invoke serverStopping() -> WebContainer preDestroy.

Comment by jwells [ 10/Aug/12 12:00 PM ]

I have recently added the ability for @Singleton scoped objects to be shutdown on the shutdown of the ServiceLocator. I believe that this must therefore be happening because the shutdown of the embedded server isn't happening properly, which is is Mason's area of expertise.

Comment by mtaube [ 31/Aug/12 04:24 PM ]

After Revision 55766, WebContainer.preDestroy is being called on shutdown

Comment by Amy Roh [ 31/Aug/12 09:48 PM ]

I confirm that WebContainer.preDestroy gets invoked on shutdown as expected.

However, when restarting GrizzlyService.postConstruct is never called and the mappers are not starting.

GrizzlyService.postConstruct is called as expected when starting glassfish for the first time. Stopping is calling GrizzlyService.preDestroy as expected but restarting glassfish never invokes GrizzlyService.postConstruct.

Comment by mtaube [ 04/Sep/12 09:48 PM ]

After revision 55791, GrizzlyService.preDestroy/postConstruct will be called.

Comment by Amy Roh [ 17/Sep/12 07:52 PM ]

After Ryan's fix (svn 56001) in GlassfishNetworkListener.stop, restart is working as expected.





[GLASSFISH-18921] Allow configuration of Service Registry, e.g., dropping/replacing services Created: 19/Jul/12  Updated: 11/Feb/13

Status: Open
Project: glassfish
Component/s: hk2
Affects Version/s: None
Fix Version/s: 4.0.1

Type: Improvement Priority: Critical
Reporter: Sanjeeb Sahoo Assignee: mtaube
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: mtaube and Sanjeeb Sahoo

 Description   

We need a better way to configure the service registry without entering too far into the territory of "config driven services" model. I have not looked at the code post HK2 2.x integration, but earlier HK2 API exposed methods in InhabitantParser to customize the service registry. The customization supported replacing/removing of services. I don't think they are written carefully enough to take care of timing issues, but I would expect them to work if those methods are called before any service is actually active. As part of HK2 2.x effort, they may have been improved as well. We do have some code (which I don't actually like) that actually uses those methods to drop/replace services at system bootstrapping time. This is mostly done in the embedded code path. By now you must have come across those files as part of HK2 2.x integration. e.g., nucleus/core/kernel/src/main/java/org/glassfish/kernel/embedded/EmbeddedInhabitantsParser.java. There has to be a better way to do this. I don't like the system property based check that's going on in this file or the getName() based matching. What I am hoping for is a way to provide some service customization information as part of domain.xml so that we can get rid of InhabitantParserDecorators. We could have an entry like:

<hk2-service-registry-customization>
<dropped-service>
</dropped-service>
<replace-service></replace-service>
</hk2-service-registry-customization>

This can even be used to add ranks to services to control service selection when multiple ones are present.

Don't read too much into these XML descriptor, they are just a discussion starter. We could read this from a different file, but why invent another configuration source instead of using domain.xml?

Thanks,
Sahoo






[GLASSFISH-18910] OSGI Module Status Report Information on Startup Missing from server.log when log level enabled to FINE Created: 17/Jul/12  Updated: 29/Aug/12  Resolved: 29/Aug/12

Status: Closed
Project: glassfish
Component/s: hk2
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: vijay_oracle Assignee: jwells
Resolution: Fixed Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

javax.enterprise.system.core.level=FINE set in GF_HOME/domains/domain1/config/logging.properties


Tags: hk2 osgi
Participants: jwells, mtaube and vijay_oracle

 Description   

On startup the server log provides description on OSGI modules and their states. After the HK 2.0 integration the server log is not containing this info.

We use this output to collect OSGI Module statistics on start up.



 Comments   
Comment by mtaube [ 08/Aug/12 08:06 PM ]

Committed revision 55367.

Changed AppServerStartup to @Inject ModulesRegistry. Module status report now prints when javax.enterprise.system.core.level is FINE

+++ nucleus/core/kernel/src/main/java/com/sun/enterprise/v3/server/AppServerStartup.java (working copy)
@@ -115,6 +115,7 @@
@Inject
ServiceLocator locator;

+ @Inject
ModulesRegistry systemRegistry;

Comment by mtaube [ 28/Aug/12 08:01 PM ]

The server log earlier contained module state report once during start-up and once post start-up. Now i see post start-up the module states is being logged 10 times in the log file.

Comment by jwells [ 29/Aug/12 12:30 PM ]

The method is called for each completed level, so it was being called 10 times between level 10 and level 20. Now the code checks for that, and only does the printout when it reaches level 20.





[GLASSFISH-18868] dol-jar-scanner: NullPointerException while visiting com/sun/gjc/spi/JdbcObjectsFactory.class Created: 06/Jul/12  Updated: 17/Dec/12  Resolved: 17/Dec/12

Status: Closed
Project: glassfish
Component/s: hk2
Affects Version/s: 3.1.2
Fix Version/s: None

Type: Bug Priority: Major
Reporter: jthoennes Assignee: mtaube
Resolution: Fixed Votes: 2
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: g_weisselberg, gfuser9999, jthoennes, jwells, mtaube and shreedhar_ganapathy

 Description   

On Glassfish startup we see this exception in the logs:

[2012-07-06 15:26:33,030] [ERROR] [javax.enterprise.system.tools.deployment.org.glassfish.deployment.common] [dol-jar-scanner] [#1] Exception while visiting com/sun/gjc/spi/JdbcObjectsFactory.class of size 3630 
java.lang.NullPointerException
    at org.glassfish.hk2.classmodel.reflect.impl.TypesImpl.getType(TypesImpl.java:78)
    at org.glassfish.hk2.classmodel.reflect.impl.ModelClassVisitor.visit(ModelClassVisitor.java:119)
    at org.objectweb.asm.ClassReader.accept(Unknown Source)
    at org.objectweb.asm.ClassReader.accept(Unknown Source)
    at org.glassfish.hk2.classmodel.reflect.Parser$5.on(Parser.java:363)
    at org.glassfish.hk2.classmodel.reflect.util.JarArchive.onSelectedEntries(JarArchive.java:125)
    at org.glassfish.hk2.classmodel.reflect.Parser.doJob(Parser.java:348)
    at org.glassfish.hk2.classmodel.reflect.Parser.access$300(Parser.java:70)
    at org.glassfish.hk2.classmodel.reflect.Parser$3.call(Parser.java:307)
    at org.glassfish.hk2.classmodel.reflect.Parser$3.call(Parser.java:296)
    at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
    at java.util.concurrent.FutureTask.run(FutureTask.java:138)
    at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
    at java.lang.Thread.run(Thread.java:662)

Does it do any harm?



 Comments   
Comment by jthoennes [ 13/Jul/12 11:53 AM ]

Any update here?

Comment by g_weisselberg [ 17/Sep/12 02:34 PM ]

well, we have this problem also and would love it if it can become fixed soon!

Comment by gfuser9999 [ 20/Sep/12 12:30 PM ]
org/glassfish/hk2/classmodel/reflect/impl/TypesCtr.java
The code in TypesCtr.getHolder(String name, Class type)
return null when due to a conditional race.
See if this "diff" on hk2 helps but a HK2 1.x bug should be created.
(See: GLASSFISH-18513 also).

--- TypesCtr-orig.java	Sat Sep 15 21:36:00 2012
+++ TypesCtr.java	Sat Sep 15 21:40:02 2012
@@ -111,9 +111,13 @@
         TypeProxy<Type> typeProxy = typeStorage.get(name);
         if (typeProxy == null) {
             // in our unknown type pool ?
-            if (unknownTypesStorage.containsKey(name)) {
+            TypeProxy<Type> unkTypeProxy = unknownTypesStorage.get(name);
+            if (unkTypeProxy!=null) {
                 synchronized (unknownTypesStorage) {
                     typeProxy = unknownTypesStorage.remove(name);
+                    if (typeProxy == null) {
+                       typeProxy = unkTypeProxy;
+                    }
                 }
                 if (typeProxy!=null) {
                     TypeProxy<Type> old = typeStorage.putIfAbsent(name, typeProxy);
Comment by shreedhar_ganapathy [ 13/Dec/12 07:47 PM ]

->hk2
->jwells - please reassign if this is not appropriate

Comment by jwells [ 13/Dec/12 08:29 PM ]

This was fixed in the hk2 1.x line, but the fix needs to come to the 2.x line.





[GLASSFISH-18768] Memory leak with WS + CDI (empty beans.xml) Created: 30/May/12  Updated: 23/Apr/13  Resolved: 23/Apr/13

Status: Resolved
Project: glassfish
Component/s: cdi
Affects Version/s: 3.1.1, 3.1.2
Fix Version/s: 4.0

Type: Bug Priority: Blocker
Reporter: kabhal Assignee: mtaube
Resolution: Fixed Votes: 6
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

MacOSX
java version "1.6.0_31"
Java(TM) SE Runtime Environment (build 1.6.0_31-b04-415-11M3646)
Java HotSpot(TM) 64-Bit Server VM (build 20.6-b01-415, mixed mode

Version = GlassFish Server Open Source Edition 3.1.1 (build 12)

Version = GlassFish Server Open Source Edition 3.1.2 (build 23)


Tags: metro2_2_1-waived
Participants: frank_w, kabhal, mtaube and shreedhar_ganapathy

 Description   

A simple JAX-WS service with no implementation or injection + empty beans.xml in WEB-INF create a memory leak
if you call the WebService in a loop.

Without the empty beans.xml, no memory leak.



 Comments   
Comment by kabhal [ 30/May/12 02:22 PM ]

I used the project attached in GLASSFISH-16030 to reproduce the leak.

Comment by frank_w [ 14/Mar/13 11:00 AM ]

Workaround that worked for me was to annotate the Class with @Stateless
Additionally I used /WEB-INF/glassfish-ejb-jar.xml to configure the URL to the webservice and make https call possible

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE glassfish-ejb-jar PUBLIC "-//GlassFish.org//DTD GlassFish Application Server 3.1 EJB 3.1//EN" "http://glassfish.org/dtds/glassfish-ejb-jar_3_1-1.dtd">
<glassfish-ejb-jar>
<enterprise-beans>
<ejb>
<ejb-name>EJBName</ejb-name>
<webservice-endpoint>
<port-component-name>EJBName</port-component-name>
<endpoint-address-uri>/<appliction-context>/ServiceName</endpoint-address-uri>
<transport-guarantee>CONFIDENTIAL</transport-guarantee>
</webservice-endpoint>
</ejb>
</enterprise-beans>
</glassfish-ejb-jar>

Comment by shreedhar_ganapathy [ 19/Apr/13 03:46 PM ]

Is the memory leak root cause identified?

Any ETA on the fix?

Comment by mtaube [ 23/Apr/13 03:43 PM ]

Deploying the application from GLASSFISH-16030 to the latest build of glassfish and running the following loop several times:

#!/bin/bash
for i in {1..10000}
do
curl http://localhost:8080/boot-gateway/Boot_v1 > /dev/null
done

I do not see any evidence of a memory leak while connected to the process with JProfiler.

Can you confirm the reproduction steps?

Comment by mtaube [ 23/Apr/13 05:06 PM ]

Also with the following test driver I cannot see any memory leaks in JProfiler:

import com.example.boot_gateway.boot_v1.*;

public class Test {

public static void testBoot() throws Exception { BootV1 bootV1 = new BootV1(); ObjectFactory of = new ObjectFactory(); RequestType rt = of.createRequestType(); assert "approved".equals(bootV1.getTnsBootServicePortType().process(rt).getResponseDescription()); }

public static void main(String args[]) {
try {
for (int i = 0; i < 10000; i++) { testBoot(); }
} catch (Exception ex) { ex.printStackTrace(); }
}
}





[GLASSFISH-18655] Where possible, BaseServiceLocator should be injected instead of Habitat Created: 23/Apr/12  Updated: 15/Aug/12  Resolved: 15/Aug/12

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

Type: Improvement Priority: Major
Reporter: mtaube Assignee: mtaube
Resolution: Fixed Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: hk2
Participants: mtaube

 Description   

Throughout the codebase, Habitat (which is a concrete class) is @Injected or looked up. This makes refactoring the hk2 api problematic. In cases where the Habitat is merely used as a registry to lookup services (e.g. getComponent), we should instead inject BaseServiceLocator, which is an interface. In the long term these should change to jsr-330 Provider based injection.






[GLASSFISH-18650] Memory leak with tag-files and CDI enabled Created: 20/Apr/12  Updated: 07/May/13  Resolved: 07/May/13

Status: Resolved
Project: glassfish
Component/s: web_container
Affects Version/s: 3.1.2
Fix Version/s: 4.0_b88_RC4

Type: Bug Priority: Minor
Reporter: enrico_olivelli Assignee: kchung
Resolution: Fixed Votes: 2
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows7 64bit with jdk7_u3, linux with jdk6, Glassifish Open Source 3.1.2


File Attachments: Zip Archive StressTags.zip    
Tags:
Participants: aosama, enrico_olivelli, jjsnyder83, kchung, Martin Grebac, mtaube, pukkaone, Shing Wai Chan, shreedhar_ganapathy and Sivakumar Thyagarajan

 Description   

When CDI is enabled on a web application which uses JSP tag files instances of tag files remain inside com.sun.enterprise.container.common.impl.managedbean.ManagedBeanManagerImpl in jcdiManagedBeanInstanceMap.

Instances of tag files contains references to JspContext which contains a reference to JspWriterImpl, which contains a buffer which holds response data

This is a memory leak which leads to OutOfMemoryErrors very quickly



 Comments   
Comment by enrico_olivelli [ 20/Apr/12 07:41 AM ]

attaching a simple test case

Comment by enrico_olivelli [ 20/Apr/12 07:57 AM ]

Steps to reproduce:

  • run the sample project
  • run the test
  • take and heap dump of Glassfish
  • look for "mytag" instances
Comment by enrico_olivelli [ 14/Jul/12 06:59 PM ]

any news on this issue ?

Comment by pukkaone [ 07/Dec/12 07:17 PM ]

A custom tag implemented as a Simple Tag Handler by extending the SimpleTagSupport convenience class also exhibits exactly the same symptoms.

Comment by Sivakumar Thyagarajan [ 10/Dec/12 05:23 AM ]

Transferring this issue to JJ Snyder.

Comment by shreedhar_ganapathy [ 19/Apr/13 03:48 PM ]

Hi JJ
The issue is fairly old. Is this issue reproducible with latest builds?
Could you provide an update?

Comment by mtaube [ 23/Apr/13 01:58 PM ]

This is still happening on the latest build. WebContainer.createTagHandlerInstance is causing ManagedBeanManagerImpl.createManagedBean to be called to instantiate the tag, but the corresponding .destroyManagedBean is never called, hence the leak.

Comment by Martin Grebac [ 24/Apr/13 08:14 AM ]

Why was this assigned to me?

Comment by Shing Wai Chan [ 25/Apr/13 01:14 AM ]

The calling stack is as follows:

com.sun.enterprise.web.WebContainer.createTagHandlerInstance(WebContainer.java:1043)
	at com.sun.enterprise.web.jsp.ResourceInjectorImpl.createTagHandlerInstance(ResourceInjectorImpl.java:104)
	at org.apache.jsp.index_jsp._jspx_meth_my_mytag_0(index_jsp.java:86)
	at org.apache.jsp.index_jsp._jspService(index_jsp.java:63)
	at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:111)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
	at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:411)
	at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:473)
	at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:377)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
	at org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1682)

I see ResourceInjectorImpl#preDestroy which is not invoked.

Comment by Shing Wai Chan [ 25/Apr/13 05:22 PM ]

Assign to Kinman to further to investigate the jsp part.

Comment by kchung [ 29/Apr/13 11:28 PM ]

The JSP compiler is generating calls to the injection manager to process annotations when the tag file instance is created, without calling preDestroy after doTag, causing memory leaks. This is wrong, because annotations are not supported for JSP tag files. Removing the calls to the injection manager should fix this problem.

Comment by kchung [ 30/Apr/13 06:00 AM ]

Upon closer examination, I failed to see the reported memory leakage.

Running the test quickly lead to "error:java.net.NoRouteToHostException: Can't assign requested address", probably due too many open connections.

The memory usage when running the test did increase monotonically, but at a rate that is acceptable, due probably to unclosed open connections. The behavior is similar for plain JSP pages, not just for tag files.

As far as I can tell, the buffer is released after the request returns.

There is still the issue of calling the injection manager unnecessarily. This should be fixed in a future release.

Comment by mtaube [ 30/Apr/13 05:21 PM ]

I saw the java.net.NoRouteToHostException happen on MacOS, just add a Thread.sleep(500) to the loop in the test and that problem goes away.

Comment by jjsnyder83 [ 30/Apr/13 05:25 PM ]

Tag libraries are supported for cdi integration. There is a cdi tck test for this so disabling it will cause the cdi tck to fail. Please do not disable it! Also I think acustom tag implemented as a Simple Tag Handler by extending the SimpleTagSupport convenience class also exhibits exactly the same symptoms.

Comment by aosama [ 02/May/13 11:20 PM ]

guys i am facing the same issue , the tag handler is eating up the memory real quick

can we have a quick fix for this

Comment by kchung [ 03/May/13 06:15 PM ]

I am sending you a patch that may fix your issue. Can your give it a try and let me know?

Comment by kchung [ 03/May/13 06:19 PM ]

Oops! aosama, what's your email? You can send that info to kinman.chung@oracle.com. Thanks.

Comment by aosama [ 05/May/13 10:14 PM ]

hi kim, i dropped u a note hope u got my email its aosama [at] gmail [dot] com

Comment by kchung [ 07/May/13 05:00 PM ]

Fixed in 4.0 and trunk.

There are two parts to the fix.

1. ResourceInjector will not be invoked for tag files.
2. ResourceInjector.preDestroy is called for
a. tags that extend SimpleTagSupport, and
b. classic tag hanlder
1. with tag pooling on (default), when the app exits
2. with tag pooling off, at end tag

i





[GLASSFISH-18537] Validation Message Bundles don't get resolved in correct language Created: 21/Mar/12  Updated: 19/Feb/13  Resolved: 19/Feb/13

Status: Closed
Project: glassfish
Component/s: bean-validator
Affects Version/s: 3.1.2_b22
Fix Version/s: 3.1.2_b05

Type: Bug Priority: Major
Reporter: myfear Assignee: mtaube
Resolution: Fixed Votes: 2
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

GlassFish Server Open Source Edition 3.1.2 (build 22)
Name of the Operating System: Windows 7
Binary Architecture name of the Operating System: amd64, Version: 6.1
Java HotSpot(TM) 64-Bit Server VM Vendor: Sun Microsystems Inc. Version: 20.1-b02


File Attachments: Zip Archive constraints.zip    
Tags:
Participants: Aquillo, mtaube, myfear and shreedhar_ganapathy

 Description   

Using Bean Validation constraints like the following including providing a message property
@NotNull(message = "{Album.name.notNull}")

and having the default ValidationMessages.properties
packaged with only one language specific version (e.g. ValidationMessages_de.properties) leads to wrong locale being used for clients which use other than the language specific locale.

Example attached:
visit with a en/en_US browser setting
http://localhost:8080/constraints/
<= create album leads to a German message to be displayed.



 Comments   
Comment by Aquillo [ 22/Oct/12 10:41 AM ]

What is the status regarding this issue?
I would love to see this being fixed.

Comment by shreedhar_ganapathy [ 13/Dec/12 07:27 PM ]

-> JSnyder

Comment by mtaube [ 15/Feb/13 03:20 PM ]

This does not appear to reproduce for me using GlassFish 3.1.2.2 (build 5)





[GLASSFISH-18518] Use JSR 330 annotations in GlassFish Nucleus-Cluster Created: 16/Mar/12  Updated: 08/Aug/12  Resolved: 08/Aug/12

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

Type: Task Priority: Major
Reporter: mtaube Assignee: mtaube
Resolution: Fixed Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: mtaube

 Description   

GlassFish modules should move away from using non standard Classes like Habitat and use standards based annotations and classes as specified by jsr 330(javax.inject.Inject, javax.inject.Provider etc.). To quote Jerome: "Classes like Habitat exposes too many APIs available to the users that makes the hk2 evolution very difficult. " Also some of the APIs are unclear (when to use habitat.getComponent() versus habitat.getByType() /habitat.getByContract() ).

So, the first step is to move away from Habitat (where ever possible) and use jsr 330 interface and annotations.

In order to do this, the hk2 team will be making the following changes to the GlassFish modules as described here ...

http://aseng-wiki.us.oracle.com/asengwiki/display/GlassFish/Internal+Status+Page+for+HK2+API+Changes






[GLASSFISH-17847] [HK2] REGRESSION Static modules registry does not parse META-INF/services entries Created: 30/Nov/11  Updated: 11/Feb/13  Resolved: 11/Feb/13

Status: Closed
Project: glassfish
Component/s: hk2
Affects Version/s: 4.0
Fix Version/s: 4.0

Type: Bug Priority: Major
Reporter: Sanjeeb Sahoo Assignee: mtaube
Resolution: Fixed Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: jwells, marina vatkina, mtaube and Sanjeeb Sahoo

 Description   

While investigating some class loader issues in ACC and embedded, I noticed that when HK2 is initialized in static mode, the underlying code creates a single module definition of type ProxyModuleDefinition, but it is not containing any META-INF/services related metadata. ProxyModuleDefinition.getMatadata() only returns inhabitants information. This is clearly wrong.



 Comments   
Comment by marina vatkina [ 30/Nov/11 06:23 PM ]

Breaks most ejb devtests

Comment by Sanjeeb Sahoo [ 30/Nov/11 09:08 PM ]

Making it a Major instead of a Blocker as I checked in a work around. See rev 51212.

Comment by jwells [ 11/Feb/13 09:57 PM ]

HK2 no longer looks in META-INF/services for anything with the exception of PostProcessors inside of Java EE applications.





[GLASSFISH-17803] [Regression] Conflict of ORB ports not detected in GF 4.0 Created: 23/Nov/11  Updated: 29/May/13  Resolved: 29/May/13

Status: Closed
Project: glassfish
Component/s: hk2
Affects Version/s: 4.0
Fix Version/s: 4.0.1

Type: Bug Priority: Major
Reporter: Alex Pineda Assignee: mtaube
Resolution: Fixed Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

System is running GF 4.0 build 10 full distribution. System is running OEL6, JDK1.6.0_29.


File Attachments: Text File server.log     Text File server.log     File stateful-simple.ear    
Issue Links:
Duplicate
is duplicated by GLASSFISH-17892 [Regression] Conflict of instance por... Resolved
Tags: 3_1_x-exclude 3x_regression
Participants: Alex Pineda, Harshad Vilekar, mtaube, tbeerbower and Tom Mueller

 Description   

The following test case is part of the AdminCLI SQE test suite. The scenario is the creation of two domains with the same ORB port. A simple ear app is deployed on both domains and the test case expects, one domain to work, but not the second. In GF 3.1.x, this negative scenario works as expected. In GF 4.0 it does not. This is an incosistent functional behavior. The test case name is "TESTNAME=start_domain_port_conflict_orb".

Please note that the same port number is used for the ORB. The exact commands executed are:

machine$ asadmin create-domain --domaindir $TEST_HOME/domains --adminport 10000 --user admin1
--passwordfile $HOME/template/t_passwd1.txt --domainproperties orb.listener.port=57569 testdomain

machine$ asadmin create-domain --domaindir $TEST_HOME/domains --adminport 11000 --user admin1
--passwordfile $HOME/template/t_passwd1.txt --domainproperties orb.listener.port=57569 testdomain2

machine$ asadmin start-domain testdomain
Waiting for testdomain to start ....
Successfully started the domain : testdomain
machine$ asadmin --user admin1 --passwordfile $HOME/template/t_passwd1.txt
--port 10000 deploy $HOME/apps/stateful-simple.ear
Application deployed with name stateful-simple.
Command deploy executed successfully.
machine$ asadmin stop-domain testdomain

machine$ asadmin start-domain testdomain2
Waiting for testdomain2 to start ....
Successfully started the domain : testdomain2
machine$ asadmin --port 11000 --user admin1 --passwordfile $HOME/template/t_passwd1.txt
deploy $HOME/apps/stateful-simple.ear
Application deployed with name stateful-simple.
Command deploy executed successfully.

machine$ asadmin start-domain testdomain

The expectation is for the start-domain to fail. The test case looks for a failure message as noted in COM_MSG="Command start-domain failed", but what is returned by the server is:
Waiting for testdomain to start .......
Successfully started the domain : testdomain

As a result the test case fails. In GF 3.1.x, this scenario works as expected. Below is the output from GF 3.1.1 FCS build.

Error starting domain testdomain.
The server exited prematurely with exit code 0. Before it died, it produced the following output:
Launching GlassFish on Felix platform
Nov 22, 2011 4:21:06 PM com.sun.enterprise.server.logging.LogManagerService postConstruct
SEVERE|oracle-glassfish3.1.1|grizzly|_ThreadID=11;_ThreadName=Grizzly-kernel-thread(1);|doSelect IOException
java.net.BindException: No free port within range:
39654=com.sun.enterprise.v3.services.impl.ServiceInitializerHandler@fab5b1
at com.sun.grizzly.TCPSelectorHandler.initSelector(TCPSelectorHandler.java:432)
at com.sun.grizzly.TCPSelectorHandler.preSelect(TCPSelectorHandler.java:378)
at com.sun.grizzly.SelectorHandlerRunner.doSelect(SelectorHandlerRunner.java:188)
at com.sun.grizzly.SelectorHandlerRunner.run(SelectorHandlerRunner.java:132)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662

javax.enterprise.resource.corba.org.glassfish.enterprise.iiop.impl|_ThreadID=10;_ThreadName=main;|
java.net.BindException: Address already in use

Reference:
appserver-sqe/pe/admincli/tonga/testbase/serverlifecycle/start_domain/start_domain_port_03.cfg
appserver-sqe/pe/admincli/tonga/testbase/serverlifecycle/start_domain/start_domain_port_03terse.cfg



 Comments   
Comment by Tom Mueller [ 23/Nov/11 02:17 PM ]

Doesn't apply to 3.1.x.

Comment by Tom Mueller [ 19/Dec/11 09:24 PM ]

This is working in 4.0 (the trunk).

Since the HTTP listener ports are not set differently between the domains, the 2nd domain fails to start because port 8080 (and 8081) are already in use. The test case specified in the description doesn't really test that duplicate IIOP ports are detected because the failure to find to port 8080 (and 8081) is detected first.

Here is the output in the log file from 4.0 when the server fails to start:

[#|2011-12-19T13:19:10.518-0800|INFO|44.0|javax.enterprise.system.container.web.com.sun.enterprise.web|_ThreadID=10;_ThreadName=main;|WEB0671: Loading application sampleEA#sampleEA-war.war at [sampleEA-war]|#]

[#|2011-12-19T13:19:10.519-0800|INFO|44.0|javax.enterprise.system.core.com.sun.enterprise.v3.server|_ThreadID=10;_ThreadName=main;|CORE10010: Loading application sampleEA done in 2,805 ms|#]

[#|2011-12-19T13:19:10.520-0800|INFO|44.0|javax.enterprise.system.core.com.sun.enterprise.v3.server|_ThreadID=10;_ThreadName=main;|GlassFish Server Open Source Edition 4.0 (re-continuous) startup time : Felix (1,402ms), startup services(3,644ms), total(5,046ms)|#]

[#|2011-12-19T13:19:10.521-0800|SEVERE|44.0|javax.enterprise.system.core.com.sun.enterprise.v3.server|_ThreadID=10;_ThreadName=main;|Shutting down v3 due to startup exception : Address already in use|#]

[#|2011-12-19T13:19:10.535-0800|INFO|44.0|javax.enterprise.system.tools.admin.com.sun.enterprise.v3.admin|_ThreadID=11;_ThreadName=Thread-10;|Server shutdown initiated|#]

[#|2011-12-19T13:19:10.539-0800|INFO|44.0|javax.enterprise.system.core.com.sun.enterprise.v3.server|_ThreadID=11;_ThreadName=Thread-10;|Already stopped, so just returning|#]

Command start-domain failed.

Comment by Alex Pineda [ 01/May/12 11:58 PM ]

Modified the test case to specify http instance port to be unique for newly created domains, but the expected failure does not happen. To reiterate the test case, the steps are:

  • create testdomain (unique admin and http ports) with orb.listener.port=60868
  • create testdomain2 (unique admin and http ports) with orb.listener.port=60868
  • start-domain testdomain
  • deploy stateful-simple.ear on testdomain
  • stop-domain testdomain
  • start-domain testdomain2
  • deploy stateful-simple.ear on testdomain2
  • start-domain testdomain

The expectation of the test case is for the start-domain command to fail. In fact, the test case looks for string "Command start-domain failed", but the start-domain is successful. It seems there should br some functional conflict if two domains are assigned the same ORB port, deployed an application and are running. This is shat appears to be test case scenario that QA is trying to test. Since this appears to be an issue, I'm re-opening the bug.

Comment by Alex Pineda [ 02/May/12 12:39 AM ]

Unable to reproduce the problem manually, thus, I've added a 2 second delay between the deployment on testdomain2 and the starting of testdomain.

Comment by Tom Mueller [ 03/May/12 04:23 PM ]

Can you please attach the stateful-simple.ear file to the issue?

Comment by Tom Mueller [ 03/May/12 04:26 PM ]

Reassigning to the orb component. I tried recreating the problem with another EAR file, and the behavior that I saw is the following:

1. When testdomain is started by itself, the process listens on port 60868.
2. When testdomain2 is started by itself, the process listens on port 60868.
3. When both domains are started at the same time, the 2nd domain starts successfully and there is no log message saying that the 2nd process wasn't able to bind to port 60868.

Comment by Alex Pineda [ 03/May/12 10:01 PM ]

I will take back my previous statement. I'm able to reproduce the problem consistently and I have created a Hudson to show the issue. Please let me know if you want direct access to the Hudson job to understand the issue better. In addition, I'll attached the stateful-simple.ear file as requested.

Comment by Alex Pineda [ 03/May/12 10:03 PM ]

Attaching sample app used in this test case.

Comment by Harshad Vilekar [ 03/May/12 10:58 PM ]

ORB init is failing with expected "Java.net.BindException: Address already in use".

For some reason, this is not aborting domain startup.

=======================
[#|2012-05-02T14:09:37.055-0700|INFO|44.0|javax.enterprise.system.core.transaction.com.sun.jts.CosTransactions|_ThreadID=10;_ThreadName=Thread-2;|JTS5014: Recoverable JTS instance, serverId = [57569]|#]

[#|2012-05-02T14:09:37.246-0700|SEVERE|44.0|javax.enterprise.resource.corba.org.glassfish.enterprise.iiop.impl|_ThreadID=10;_ThreadName=Thread-2;|iiop.createsocket_exception|#]

[#|2012-05-02T14:09:37.246-0700|SEVERE|44.0|javax.enterprise.resource.corba.org.glassfish.enterprise.iiop.impl|_ThreadID=10;_ThreadName=Thread-2;|java.net.BindException: Address already in use
at java.net.PlainSocketImpl.socketBind(Native Method)
at java.net.PlainSocketImpl.bind(PlainSocketImpl.java:383)
at java.net.ServerSocket.bind(ServerSocket.java:328)
at java.net.ServerSocket.<init>(ServerSocket.java:194)
at javax.net.ssl.SSLServerSocket.<init>(SSLServerSocket.java:106)
at com.sun.net.ssl.internal.ssl.SSLServerSocketImpl.<init>(SSLServerSocketImpl.java:108)
at com.sun.net.ssl.internal.ssl.SSLServerSocketFactoryImpl.createServerSocket(SSLServerSocketFactoryImpl.java:72)
:
:
org.glassfish.enterprise.iiop.impl.GlassFishORBFactoryImpl.createORB(GlassFishORBFactoryImpl.java:93)
at org.glassfish.enterprise.iiop.api.GlassFishORBHelper.getORB(GlassFishORBHelper.java:163)
at org.glassfish.enterprise.iiop.api.GlassFishORBHelper.getProtocolManager(GlassFishORBHelper.java:231)
at com.sun.ejb.containers.BaseContainer.initializeProtocolManager(BaseContainer.java:810)
at com.sun.ejb.containers.BaseContainer.<init>(BaseContainer.java:555)
at com.sun.ejb.containers.StatefulSessionContainer.<init>(StatefulSessionContainer.java:209)
at com.sun.ejb.containers.StatefulSessionContainer.<init>(StatefulSessionContainer.java:204)
at com.sun.ejb.containers.builder.StatefulContainerBuilder.createContainer(StatefulContainerBuilder.java:156)
at com.sun.ejb.containers.builder.BaseContainerBuilder.buildContainer(BaseContainerBuilder.java:96)
at com.sun.ejb.containers.ContainerFactoryImpl.createContainer(ContainerFactoryImpl.java:102)
at org.glassfish.ejb.startup.EjbApplication.loadContainers(EjbApplication.java:228)
at org.glassfish.ejb.startup.EjbDeployer.load(EjbDeployer.java:294)
at org.glassfish.ejb.startup.EjbDeployer.load(EjbDeployer.java:103)
at org.glassfish.internal.data.ModuleInfo.load(ModuleInfo.java:186)
at org.glassfish.internal.data.ApplicationInfo.load(ApplicationInfo.java:264)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:482)
at com.sun.enterprise.v3.server.ApplicationLoaderService.processApplication(ApplicationLoaderService.java:390)
at com.sun.enterprise.v3.server.ApplicationLoaderService.postConstruct(ApplicationLoaderService.java:226)
at com.sun.hk2.component.AbstractCreatorImpl.inject(AbstractCreatorImpl.java:132)
at com.sun.hk2.component.ConstructorCreator.initialize(ConstructorCreator.java:117)
at com.sun.hk2.component.AbstractCreatorImpl.get(AbstractCreatorImpl.java:84)
at com.sun.hk2.component.SingletonInhabitant.get(SingletonInhabitant.java:67)
at com.sun.hk2.component.EventPublishingInhabitant.get(EventPublishingInhabitant.java:141)
at com.sun.hk2.component.AbstractInhabitantImpl.get(AbstractInhabitantImpl.java:135)
at com.sun.enterprise.v3.server.StartupRunLevelBridge.activate(StartupRunLevelBridge.java:93)
at com.sun.enterprise.v3.server.RunLevelBridge.postConstruct(RunLevelBridge.java:110)
at com.sun.enterprise.v3.server.StartupRunLevelBridge.postConstruct(StartupRunLevelBridge.java:65)
at com.sun.hk2.component.AbstractCreatorImpl.inject(AbstractCreatorImpl.java:132)
at com.sun.hk2.component.ConstructorCreator.initialize(ConstructorCreator.java:117)
at com.sun.hk2.component.AbstractCreatorImpl.get(AbstractCreatorImpl.java:84)
at com.sun.hk2.component.SingletonInhabitant.get(SingletonInhabitant.java:67)
at com.sun.hk2.component.EventPublishingInhabitant.get(EventPublishingInhabitant.java:141)
at com.sun.hk2.component.EventPublishingInhabitant.get(EventPublishingInhabitant.java:141)
at com.sun.hk2.component.RunLevelInhabitant.get(RunLevelInhabitant.java:110)
at com.sun.hk2.component.AbstractInhabitantImpl.get(AbstractInhabitantImpl.java:135)
at com.sun.enterprise.v3.server.AppServerStartup$StartupInhabitantActivator.activate(AppServerStartup.java:526)
at org.jvnet.hk2.component.internal.runlevel.DefaultRunLevelService$Worker.activateRunLevel(DefaultRunLevelService.java:1106)
at org.jvnet.hk2.component.internal.runlevel.DefaultRunLevelService$Worker.upActiveRecorder(DefaultRunLevelService.java:1060)
at org.jvnet.hk2.component.internal.runlevel.DefaultRunLevelService$Worker.run(DefaultRunLevelService.java:1026)
at org.jvnet.hk2.component.internal.runlevel.DefaultRunLevelService$SyncProceedToOp.proceedTo(DefaultRunLevelService.java:1256)
at org.jvnet.hk2.component.internal.runlevel.DefaultRunLevelService.proceedTo(DefaultRunLevelService.java:797)
at org.jvnet.hk2.component.internal.runlevel.DefaultRunLevelService.proceedTo(DefaultRunLevelService.java:759)
at com.sun.enterprise.v3.server.AppServerStartup.proceedTo(AppServerStartup.java:360)
at com.sun.enterprise.v3.server.AppServerStartup.run(AppServerStartup.java:254)
at com.sun.enterprise.v3.server.AppServerStartup.doStart(AppServerStartup.java:172)
at com.sun.enterprise.v3.server.AppServerStartup.start(AppServerStartup.java:163)
at com.sun.enterprise.glassfish.bootstrap.GlassFishImpl.start(GlassFishImpl.java:79)
at com.sun.enterprise.glassfish.bootstrap.GlassFishDecorator.start(GlassFishDecorator.java:63)
at com.sun.enterprise.glassfish.bootstrap.osgi.OSGiGlassFishImpl.start(OSGiGlassFishImpl.java:71)

at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at com.sun.enterprise.glassfish.bootstrap.GlassFishMain.main(GlassFishMain.java:97)
at com.sun.enterprise.glassfish.bootstrap.ASMain.main(ASMain.java:55)

#]
=================
Comment by Harshad Vilekar [ 03/May/12 10:59 PM ]

server log attached.

Comment by Alex Pineda [ 04/May/12 11:14 PM ]

Just to be clear. The test case looks at the start-domain status and message to determine if the ORB conflict is detected. So, from a QA perspective this is still an issue and needs to be resolved.

Comment by Harshad Vilekar [ 09/May/12 07:45 PM ]

In 3.1.2, core.kernel module, com.sun.enterprise.v3.server.AppServerStarup.run() is aborted, and shutdown() is initiated if bind to ORB port fails. That is not working is 4.0.

Comment by Harshad Vilekar [ 14/May/12 04:47 AM ]

Reassigning to review if this is can be handled by GlassFish Startup.

Comment by tbeerbower [ 22/May/12 08:22 PM ]

If I follow the steps to reproduce from above ...

create testdomain (unique admin and http ports) with orb.listener.port=60868
create testdomain2 (unique admin and http ports) with orb.listener.port=60868

start-domain testdomain
deploy stateful-simple.ear on testdomain
stop-domain testdomain

start-domain testdomain2
deploy stateful-simple.ear on testdomain2

start-domain testdomain

... the last start-domain succeeds even though there is an orb listener port conflict. The log contains the following ...

java.net.BindException: Address already in use

... as noted in the stack trace above.

Comment by tbeerbower [ 22/May/12 08:29 PM ]

In the above stack trace, the ORB creation is driven by the AppServerStartup and run level service code ...

at com.sun.enterprise.v3.server.StartupRunLevelBridge.activate(StartupRunLevelBridge.java:93)
at com.sun.enterprise.v3.server.RunLevelBridge.postConstruct(RunLevelBridge.java:110)
at com.sun.enterprise.v3.server.StartupRunLevelBridge.postConstruct(StartupRunLevelBridge.java:65)
at com.sun.hk2.component.AbstractCreatorImpl.inject(AbstractCreatorImpl.java:132)
at com.sun.hk2.component.ConstructorCreator.initialize(ConstructorCreator.java:117)
at com.sun.hk2.component.AbstractCreatorImpl.get(AbstractCreatorImpl.java:84)
at com.sun.hk2.component.SingletonInhabitant.get(SingletonInhabitant.java:67)
at com.sun.hk2.component.EventPublishingInhabitant.get(EventPublishingInhabitant.java:141)
at com.sun.hk2.component.EventPublishingInhabitant.get(EventPublishingInhabitant.java:141)
at com.sun.hk2.component.RunLevelInhabitant.get(RunLevelInhabitant.java:110)
at com.sun.hk2.component.AbstractInhabitantImpl.get(AbstractInhabitantImpl.java:135)
at com.sun.enterprise.v3.server.AppServerStartup$StartupInhabitantActivator.activate(AppServerStartup.java:526)
at org.jvnet.hk2.component.internal.runlevel.DefaultRunLevelService$Worker.activateRunLevel(DefaultRunLevelService.java:1106)
at org.jvnet.hk2.component.internal.runlevel.DefaultRunLevelService$Worker.upActiveRecorder(DefaultRunLevelService.java:1060)
at org.jvnet.hk2.component.internal.runlevel.DefaultRunLevelService$Worker.run(DefaultRunLevelService.java:1026)
at org.jvnet.hk2.component.internal.runlevel.DefaultRunLevelService$SyncProceedToOp.proceedTo(DefaultRunLevelService.java:1256)
at org.jvnet.hk2.component.internal.runlevel.DefaultRunLevelService.proceedTo(DefaultRunLevelService.java:797)
at org.jvnet.hk2.component.internal.runlevel.DefaultRunLevelService.proceedTo(DefaultRunLevelService.java:759)
at com.sun.enterprise.v3.server.AppServerStartup.proceedTo(AppServerStartup.java:360)
at com.sun.enterprise.v3.server.AppServerStartup.run(AppServerStartup.java:254)
at com.sun.enterprise.v3.server.AppServerStartup.doStart(AppServerStartup.java:172)
at com.sun.enterprise.v3.server.AppServerStartup.start(AppServerStartup.java:163)

The AppServerStartup code has changed in GF 4.0 and is suspected of causing the diff. The difference being that in GF 3.1.2 the port conflict supposedly causes a failure to start the server (not just a stack trace in the log).

Comment by tbeerbower [ 22/May/12 08:45 PM ]

The full stack trace from the log shows the following ...

at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:482)

The code in ApplicationLifecycle.deploy does the following ...

try {
    ...
    appInfo.load(context, tracker);
    ...
} catch(Throwable loadException) {
    ...
    tracker.actOn(logger);
    return null;
}

It looks like the exception is being logged and then discarded. In this case the exception is not being thrown out to the AppServerStartupCode. If the exception was rethrown then it should be handled in the AppServerStartupCode (line 536) and cause a server shutdown ...

} catch(RuntimeException e) {
    logger.log(level, e.getMessage(), e);
    ...
    events.send(new Event(EventTypes.SERVER_SHUTDOWN), false);
    forceShutdown();
    return;
}

The scenario where an exception is thrown out to the AppServerStartup code should be covered by the unit test AppServerStatupTest.testRunLevelServicesWithStartupException().

Comment by tbeerbower [ 22/May/12 09:01 PM ]

Following the above steps to reproduce using GF 3.1, I get the following...

./asadmin start-domain mydomain2
Waiting for mydomain2 to start ........
Successfully started the domain : mydomain2
domain  Location: /Users/tbeerbower/gf-old/glassfish3/glassfish/domains/mydomain2
Log File: /Users/tbeerbower/gf-old/glassfish3/glassfish/domains/mydomain2/logs/server.log
Admin Port: 5001
Command start-domain executed successfully.

... I can start the second domain and the log contains the following stack trace ...

java.net.BindException: Address already in use
	at java.net.PlainSocketImpl.socketBind(Native Method)
	at java.net.PlainSocketImpl.bind(PlainSocketImpl.java:383)
	at java.net.ServerSocket.bind(ServerSocket.java:328)
	at java.net.ServerSocket.<init>(ServerSocket.java:194)
	at javax.net.ssl.SSLServerSocket.<init>(SSLServerSocket.java:106)
	at com.sun.net.ssl.internal.ssl.SSLServerSocketImpl.<init>(SSLServerSocketImpl.java:108)
	at com.sun.net.ssl.internal.ssl.SSLServerSocketFactoryImpl.createServerSocket(SSLServerSocketFactoryImpl.java:72)
	at org.glassfish.enterprise.iiop.impl.IIOPSSLSocketFactory.createSSLServerSocket(IIOPSSLSocketFactory.java:402)
	at org.glassfish.enterprise.iiop.impl.IIOPSSLSocketFactory.createServerSocket(IIOPSSLSocketFactory.java:281)
	at com.sun.corba.ee.impl.transport.SocketOrChannelAcceptorImpl.initialize(SocketOrChannelAcceptorImpl.java:91)
	at com.sun.corba.ee.impl.transport.CorbaTransportManagerImpl.getAcceptors(CorbaTransportManagerImpl.java:243)
	at com.sun.corba.ee.impl.transport.CorbaTransportManagerImpl.addToIORTemplate(CorbaTransportManagerImpl.java:262)
	at com.sun.corba.ee.spi.oa.ObjectAdapterBase.initializeTemplate(ObjectAdapterBase.java:103)
	at com.sun.corba.ee.impl.oa.poa.POAImpl.initialize(POAImpl.java:553)
	at com.sun.corba.ee.impl.oa.poa.POAImpl.makeRootPOA(POAImpl.java:352)
	at com.sun.corba.ee.impl.oa.poa.POAFactory$1.evaluate(POAFactory.java:286)
	at com.sun.corba.ee.impl.orbutil.closure.Future.evaluate(Future.java:61)
	at com.sun.corba.ee.impl.resolver.LocalResolverImpl.resolve(LocalResolverImpl.java:55)
	at com.sun.corba.ee.impl.resolver.CompositeResolverImpl.resolve(CompositeResolverImpl.java:59)
	at com.sun.corba.ee.impl.orb.ORBImpl.resolve_initial_references(ORBImpl.java:1266)
	at com.sun.corba.ee.impl.naming.cosnaming.TransientNameService.initialize(TransientNameService.java:124)
	at com.sun.corba.ee.impl.naming.cosnaming.TransientNameService.<init>(TransientNameService.java:93)
	at org.glassfish.enterprise.iiop.impl.PEORBConfigurator.configure(PEORBConfigurator.java:161)
	at com.sun.corba.ee.impl.orb.ORBConfiguratorImpl.runUserConfigurators(ORBConfiguratorImpl.java:185)
	at com.sun.corba.ee.impl.orb.ORBConfiguratorImpl.configure(ORBConfiguratorImpl.java:170)
	at com.sun.corba.ee.impl.orb.ORBImpl.postInit(ORBImpl.java:625)
	at com.sun.corba.ee.impl.orb.ORBImpl.set_parameters(ORBImpl.java:704)
	at com.sun.corba.ee.impl.orb.ORBImpl.setParameters(ORBImpl.java:691)
	at com.sun.corba.ee.spi.osgi.ORBFactory.initialize(ORBFactory.java:107)
	at org.glassfish.enterprise.iiop.impl.GlassFishORBManager.initORB(GlassFishORBManager.java:581)
	at org.glassfish.enterprise.iiop.impl.GlassFishORBManager.getORB(GlassFishORBManager.java:263)
	at org.glassfish.enterprise.iiop.impl.GlassFishORBFactoryImpl.createORB(GlassFishORBFactoryImpl.java:93)
	at org.glassfish.enterprise.iiop.api.GlassFishORBHelper.getORB(GlassFishORBHelper.java:120)
	at org.glassfish.enterprise.iiop.api.GlassFishORBHelper.getProtocolManager(GlassFishORBHelper.java:187)
	at com.sun.ejb.containers.BaseContainer.initializeProtocolManager(BaseContainer.java:818)
	at com.sun.ejb.containers.BaseContainer.<init>(BaseContainer.java:566)
	at com.sun.ejb.containers.StatefulSessionContainer.<init>(StatefulSessionContainer.java:206)
	at com.sun.ejb.containers.StatefulSessionContainer.<init>(StatefulSessionContainer.java:201)
	at com.sun.ejb.containers.builder.StatefulContainerBuilder.createContainer(StatefulContainerBuilder.java:152)
	at com.sun.ejb.containers.builder.BaseContainerBuilder.buildContainer(BaseContainerBuilder.java:96)
	at com.sun.ejb.containers.ContainerFactoryImpl.createContainer(ContainerFactoryImpl.java:110)
	at org.glassfish.ejb.startup.EjbApplication.loadContainers(EjbApplication.java:234)
	at org.glassfish.ejb.startup.EjbDeployer.load(EjbDeployer.java:290)
	at org.glassfish.ejb.startup.EjbDeployer.load(EjbDeployer.java:101)
	at org.glassfish.internal.data.ModuleInfo.load(ModuleInfo.java:186)
	at org.glassfish.internal.data.ApplicationInfo.load(ApplicationInfo.java:249)
	at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:460)
	at com.sun.enterprise.v3.server.ApplicationLoaderService.processApplication(ApplicationLoaderService.java:364)
	at com.sun.enterprise.v3.server.ApplicationLoaderService.postConstruct(ApplicationLoaderService.java:208)
	at com.sun.hk2.component.AbstractCreatorImpl.inject(AbstractCreatorImpl.java:131)
	at com.sun.hk2.component.ConstructorCreator.initialize(ConstructorCreator.java:91)
	at com.sun.hk2.component.AbstractCreatorImpl.get(AbstractCreatorImpl.java:82)
	at com.sun.hk2.component.SingletonInhabitant.get(SingletonInhabitant.java:67)
	at com.sun.hk2.component.EventPublishingInhabitant.get(EventPublishingInhabitant.java:139)
	at com.sun.hk2.component.AbstractInhabitantImpl.get(AbstractInhabitantImpl.java:76)
	at com.sun.enterprise.v3.server.AppServerStartup.run(AppServerStartup.java:243)
	at com.sun.enterprise.v3.server.AppServerStartup.start(AppServerStartup.java:135)
	at com.sun.enterprise.glassfish.bootstrap.GlassFishImpl.start(GlassFishImpl.java:79)
	at com.sun.enterprise.glassfish.bootstrap.GlassFishMain$Launcher.launch(GlassFishMain.java:117)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:597)
	at com.sun.enterprise.glassfish.bootstrap.GlassFishMain.main(GlassFishMain.java:97)
	at com.sun.enterprise.glassfish.bootstrap.ASMain.main(ASMain.java:55)

This looks nearly identical to the GF 4.0 case, but with the older AppServerStartup code.

So, we can reproduce what is believed to be bad behavior in 4.0. However, it looks like the identical behavior exists in 3.1, given the above reproduction steps. At least I am unable to reproduce the failure case in 3.1.

Could you please provide the exact steps to reproduce the failure in 3.1 along with associated logs?

Comment by tbeerbower [ 22/May/12 09:02 PM ]

Reopen if you can provide exact failure steps in GF 3.1. See above comments...

Comment by Alex Pineda [ 22/May/12 11:45 PM ]

As noted in the bug, the test was done on GF 3.1.1 not GF 3.1. As mentioned, this test case comes from the GF v2.x test suite and according to the test case, the expected behavior (start-domain failure when port conflict is detected). In our test source workspace, it references a customer bug with it. I will try to dig it out and posted on this report.

I believe this is a real issue that needs to be resolved.

Comment by tbeerbower [ 23/May/12 02:24 AM ]

I think that I can reproduce in 3.1. Reopening.

Comment by tbeerbower [ 23/May/12 04:57 PM ]

svn commit -m "GLASSFISH-17803 : Use RunLevel annotation with GrizzlyService"
Sending nucleus/core/kernel/src/main/java/com/sun/enterprise/v3/server/RunLevelBridge.java
Sending nucleus/core/kernel/src/main/java/com/sun/enterprise/v3/services/impl/GrizzlyService.java
Transmitting file data ..
Committed revision 54221.

I now see the server abort in GF 4.0 for the scenario described above ...

[#|2012-05-23T12:15:29.741-0400|SEVERE|44.0|javax.enterprise.system.core.com.sun.enterprise.v3.server|_ThreadID=10;_ThreadName=main;|Shutting down v3 due to startup exception : Address already in use|#]

The issue was that the Grizzly service was already activated by the time the StartupRunLevelBridge picked it up for activation. Because of this, the Grizzly service Futures (the service is a FutureProvider) were not added to the list to be monitored for failure. The code in the StartupRunLevelBridge has been changed to not check the activation state of the service when adding to the Future list. Also, the Grizzly service has now been updated to use the newer RunLevel annotation.

Note that one of the stack traces above was a bit of a red herring in that the exception thrown from GlassFishORBFactoryImpl during the ApplicationLoaderService.postConstruct() is not thrown out to the AppServerStartup code. In other words, this exception is not the trigger for the server to abort (same in 3.1.x and 4.0). The BindException that actually causes the server abort occurs during the Grizzy initialization. You can see that in the stack trace in the original description.

Comment by Alex Pineda [ 22/May/13 10:35 PM ]

Re-opening the bug with the intent of understanding what the exact fix was and what is the expected behavior in this test scenario from the server on GF 4.0. From reviewing this issue again, I don't see any change. Both domains are started (testdomain1 and testdomain2) without any issues. The expectation is that one will fail because of the ORB port conflict.

My objective is to resolve the test scenario in our QA AdminCLI test suite (cleanup work for GF 4.0). Please advise.

Comment by Harshad Vilekar [ 28/May/13 07:06 PM ]

The issue could be duplicated with GF 4.0-b089. The ORB initialization is failing due to port conflict, resulting in following error:

================================
[2013-05-28T11:35:28.429-0700] [glassfish 4.0] [SEVERE] [] [javax.enterprise.system.tools.deployment.common] [tid: _ThreadID=1 _ThreadName=main] [timeMillis: 1369766128429] [levelValue: 1000] [[
Exception while invoking class org.glassfish.ejb.startup.EjbDeployer load method
java.lang.RuntimeException: EJB Container initialization error
================================

This should abort the domain startup. See attached GF4.0 server.log for full stack trace.

Comment by Alex Pineda [ 29/May/13 04:33 AM ]

Harshad,

Thanks for updating the bug with your analysis, however, in reviewing the test case further, there is one extra step that I did not document in the test scenario that is causing the Test case to continue to fail. The additional part is having the default domain (domain1) up and running. When you do so, the expected failure does not happen. So, the question is, should I file a new issue or can we use this JIRA report to resolve the second part of the problem. Please let me know.

The steps to reproduce the problem are:

start-domain domain1 (default domain)

create testdomain (unique admin and http ports) with orb.listener.port=60868
create testdomain2 (unique admin and http ports) with orb.listener.port=60868

start-domain testdomain
deploy stateful-simple.ear on testdomain
stop-domain testdomain

start-domain testdomain2
deploy stateful-simple.ear on testdomain2

start-domain testdomain

... the last start-domain succeeds even though there is an orb listener port conflict.

Comment by mtaube [ 29/May/13 03:08 PM ]

The RunLevelService was not being invoked to bring down the server completely because the kernel server state was "starting" in this scenario. This was an unexpected state for AppServerStartup.stop()

I am testing a fix for this now.

Comment by mtaube [ 29/May/13 04:18 PM ]

Sending nucleus/core/kernel/src/main/java/com/sun/enterprise/v3/server/AppServerStartup.java
Transmitting file data .
Committed revision 62124.





[GLASSFISH-15119] CDI Interceptor still not working in OSGi Created: 12/Dec/10  Updated: 25/Mar/13

Status: Open
Project: glassfish
Component/s: cdi, OSGi-JavaEE
Affects Version/s: 3.1_b31
Fix Version/s: future release

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

Tested with promoted b32


File Attachments: GZip Archive interceptor-osgi-test-2-fixed.tar.gz     GZip Archive interceptor-osgi-test-2.tar.gz     File interceptor-osgi-test.tar.bz2    
Issue Links:
Dependency
depends on GLASSFISH-15249 Support vanilla OSGi bundles as bean ... Open
Tags: 3_1-exclude 3_1-next 3_1_1-scrubbed
Participants: chaoslayer, mtaube, Sanjeeb Sahoo, Sivakumar Thyagarajan and TangYong

 Description   

I just revisited GLASSFISH-13513 and GLASSFISH-14831 to see if it is possible to plug in interceptors the CDI way around EJBs.

Indeed when deploying a prepared package as non-OSGi the interceptor gets invoked but not when using OSGi deployment.

Therefore I made up another test case which should be sufficient for a confirmation of this issue:

  • maven reactor build with 4 modules
  • build.sh script for test:
  • "mvn clean install"
  • copy resulting artifacts into .../autodeploy/bundles/ folder of a running glassfish domain
  • wait for (re-)deployment
  • using "curl" to call the web service
  • search for a fault inside the returned XML

So basically for a test I issue a command like this:

$ GF_DOMAIN_DIR=/srv/servers/gf-3.1-b32/glassfish/domains/domain1/ ./build.sh

Well, I also can say that with the old @Interceptors({SecurityInterceptor.class}) method the interceptor is being called so I suspect it is not injected at all.

This test throws a fault if the interceptor is being invoked. If no fault occurs and the response is valid there must be something wrong.



 Comments   
Comment by chaoslayer [ 12/Dec/10 10:37 PM ]

Thanks for reopening the issue, I was not allowed to.

Comment by Sanjeeb Sahoo [ 14/Dec/10 01:08 AM ]

Assigning this to cdi team after talking to Siva. It is a bug in their layer.

Comment by chaoslayer [ 14/Dec/10 04:25 AM ]

Fixed the project and enabled interceptor class in beans.xml for the user service [interceptor-osgi-test-2-fixed.tar.gz].

Just tested again with a completely clean b32:

INFO: Portable JNDI names for EJB UserServiceImpl : [java:global/org.glassfish.cditest.user.service_2.0.0.SNAPSHOT/UserServiceImpl!org.glassfish.cditest.user.api.UserService, java:global/org.glassfish.cditest.user.service_2.0.0.SNAPSHOT/UserServiceImpl]
INFO: WELD-000900 ${parsedVersion (osgiVersion})
INFO: Instantiated an instance of org.hibernate.validator.engine.resolver.JPATraversableResolver.
SEVERE: Exception while loading the app
INFO: Deleted /tmp/osgiapp5600363451663621402
SEVERE: Failed while deploying bundle org.glassfish.cditest.user.service [252]
WARNING: Failed to deploy bundle org.glassfish.cditest.user.service [252]
org.glassfish.osgijavaeebase.DeploymentException: Deployment of org.glassfish.cditest.user.service [252] failed because of following reason: Failed while deploying bundle org.glassfish.cditest.user.service [252] : java.lang.RuntimeException: Failed to deploy bundle [ org.glassfish.cditest.user.service [252] ], root cause: Exception while loading the app
at org.glassfish.osgijavaeebase.AbstractOSGiDeployer.deploy(AbstractOSGiDeployer.java:125)
at org.glassfish.osgijavaeebase.OSGiContainer.deploy(OSGiContainer.java:147)
at org.glassfish.osgijavaeebase.JavaEEExtender.deploy(JavaEEExtender.java:132)
at org.glassfish.osgijavaeebase.JavaEEExtender.handleEvent(JavaEEExtender.java:117)
at org.glassfish.osgijavaeebase.JavaEEExtender.access$000(JavaEEExtender.java:56)
at org.glassfish.osgijavaeebase.JavaEEExtender$1.run(JavaEEExtender.java:100)
Caused by: java.lang.RuntimeException: Failed to deploy bundle [ org.glassfish.cditest.user.service [252] ], root cause: Exception while loading the app
at org.glassfish.osgijavaeebase.OSGiDeploymentRequest.deploy(OSGiDeploymentRequest.java:196)
at org.glassfish.osgijavaeebase.OSGiDeploymentRequest.execute(OSGiDeploymentRequest.java:118)
at org.glassfish.osgijavaeebase.AbstractOSGiDeployer.deploy(AbstractOSGiDeployer.java:121)
... 5 more
Caused by: org.glassfish.deployment.common.DeploymentException: WELD-001417 Enabled interceptor class <class>org.glassfish.cditest.security.interceptor.SecurityInterceptor</class> in bundle://252.0:1/META-INF/beans.xml@8 is neither annotated @Interceptor nor registered through a portable extension
at org.glassfish.weld.WeldDeployer.event(WeldDeployer.java:187)
at org.glassfish.kernel.event.EventsImpl.send(EventsImpl.java:128)
at org.glassfish.internal.data.ApplicationInfo.start(ApplicationInfo.java:302)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:461)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:240)
at org.glassfish.osgijavaeebase.OSGiDeploymentRequest.deploy(OSGiDeploymentRequest.java:183)
... 7 more
Caused by: org.jboss.weld.exceptions.DeploymentException: WELD-001417 Enabled interceptor class <class>org.glassfish.cditest.security.interceptor.SecurityInterceptor</class> in bundle://252.0:1/META-INF/beans.xml@8 is neither annotated @Interceptor nor registered through a portable extension
at org.jboss.weld.bootstrap.Validator.validateEnabledInterceptorClasses(Validator.java:471)
at org.jboss.weld.bootstrap.Validator.validateDeployment(Validator.java:344)
at org.jboss.weld.bootstrap.WeldBootstrap.validateBeans(WeldBootstrap.java:383)
at org.glassfish.weld.WeldDeployer.event(WeldDeployer.java:184)
... 12 more

So I guess it has to do with class visibility here. Although all required classes are visible for the bundle it may once again be a deployment issue:

250|Active | 1|Apache Felix Bundle Repository (1.6.2)
251|Active | 1|OSGi/JTA implementation in GlassFish (3.1.0.b32)
252|Active | 1|User Service OSGi Bundle (2.0.0.SNAPSHOT)
253|Active | 1|User Web Service OSGi Web Service (2.0.0.SNAPSHOT)
254|Active | 1|security.impl OSGi Bundle (2.0.0.SNAPSHOT)
255|Active | 1|security.api OSGi Bundle (2.0.0.SNAPSHOT)
g! inspect p c 255
org.glassfish.cditest.security.api [255] exports packages:
----------------------------------------------------------
org.glassfish.cditest.security.api; version=0.0.0 imported by:
org.glassfish.cditest.user.service [252]
org.glassfish.cditest.security.impl [254]
g! inspect p c 254
org.glassfish.cditest.security.impl [254] exports packages:
-----------------------------------------------------------
org.glassfish.cditest.security.interceptor; version=0.0.0 imported by:
org.glassfish.cditest.user.service [252]
g! inspect p r 252
org.glassfish.cditest.user.service [252] imports packages:
----------------------------------------------------------
javax.ejb; version=3.1.0 -> org.glassfish.javax.ejb [171]
org.glassfish.cditest.security.interceptor; version=0.0.0 -> org.glassfish.cditest.security.impl [254]
org.glassfish.cditest.security.api; version=0.0.0 -> org.glassfish.cditest.security.api [255]

Comment by Sanjeeb Sahoo [ 14/Dec/10 04:56 AM ]

I discussed with our CDI engineer (sivakumar) and he thinks there is more to it than classloading. He thinks this can be reproduced without use of OSGi as well. He is looking into it.

Comment by chaoslayer [ 14/Dec/10 01:59 PM ]

OK, so do you need any additional data from my side?

Comment by Sanjeeb Sahoo [ 14/Dec/10 07:58 PM ]

No, not at this point. We have sufficient information to proceed. Thanks.

Comment by Sanjeeb Sahoo [ 15/Dec/10 12:28 PM ]

Needed for 3.1

Comment by Sivakumar Thyagarajan [ 17/Dec/10 02:02 AM ]

Modified testcase with the following changes:
1. brought the interceptor enablement to security.impl and 2. removed the interceptor enablement in user.impl

The interceptor class is defined in security.impl and must be enabled there.

Comment by Sivakumar Thyagarajan [ 17/Dec/10 02:12 AM ]

While debugging this issue, we noticed that the interceptor was enabled in the user.impl bundle. The interceptor is defined in the security.impl bundle and hence has to be enabled there. Attached the modified test-case that has these changes. With these changes, the 3 bundles deploy in GF3.1 latest trunk.

However there is an issue. GF3.1 considers the first two bundles (security.api and security.impl) as plain vanilla OSGi bundles (not EE archives) and hence are not considered as CDI archives. Furthermore, since there is no "explicit" relationship (apart from the usage of the CDI interceptor binding) between the user.impl and the other two bundles, when the user.impl WAB is deployed, the user.impl WAB "alone" is considered as a CDI archive. The CDI runtime does not have access to the Beans in security.api/security.impl and hence this usecase will not work. GF3.1 CDI-OSGi support should support scenarios where the Beans used by a bundle are in a different bundle and scenarios where Beans could exist in plain vanilla osgi bundles. I have raised a RFE, GLASSFISH-15249, for this and targetted this for 3.2 as it is more involved to be considered for 3.1.

Here are two possible workarounds:

  • One bundle: Bundling all the Beans together in user.impl (ie have one bundle and not 3 bundles) would work. I don't know if this works for you, though.
  • Fragment bundle approach: I had a discussion with Sahoo and he is investigating the use of security.api and security.impl as fragment bundles as a workaround, and he will update this thread with his finding.
Comment by Sivakumar Thyagarajan [ 17/Dec/10 02:14 AM ]

Raised a RFE GLASSFISH-15249 to fix the underlying usecase.

Comment by chaoslayer [ 17/Dec/10 03:12 AM ]

Well, not quite covering our use case scenario. Let me explain what we "want":

  • we have one Security API bundle that contains the @Secure interface
  • we have one or more Security implementation bundles that contain the implementation for @Secure
  • we have around 20 EJB bundles that have to be "secured" via the CDI interceptor binding

So workaround one effectively disables OSGi here completely and pulls in a lot of work todo for our setup, from building to integration testing to deployment.

Option two could be an option, although I think only the bundle that contains the interceptor should be made available as a fragment bundle attaching to all those EJB bundles.

But what happens if not all Fragement-Hosts are available for the interceptor fragment bundle? Is it still resolved for those that are available? The spec is somewhat unclear here. The use case here is of course modularity. As our developers are working in different areas of interest they only use the bundles that they need. Security is a very basic need but should support those scenarios without modification at build time.

Thanks for the RFE, btw.

Comment by Sanjeeb Sahoo [ 17/Dec/10 03:57 AM ]

Yes, I just tried by converting security.impl to be a fragment of user.impl and having the <interceptors> element defined in user.impl's beans.xml. With this, I am able to see the interceptors in action. I realize this is not an optimal solution, but looks like a work around to me.

Comment by Sanjeeb Sahoo [ 17/Dec/10 04:01 AM ]

A fragment can't be attached to more than one host, so there is a potential issue for your use case. Let us think more.

Comment by Sivakumar Thyagarajan [ 17/Dec/10 05:50 AM ]

Marking as "3_1-exclude" and targetting for 3.2

Comment by Sivakumar Thyagarajan [ 06/Jul/11 04:13 AM ]

Marking as 3_1-next as this was targetted for 3.1+ releases

Comment by Sivakumar Thyagarajan [ 08/Jul/11 08:14 AM ]

Marked issue as "Major"

Comment by Sivakumar Thyagarajan [ 15/Oct/12 05:07 PM ]

Moving a fix for this to a "future release" as the dependent issue GLASSFISH-15249 is also moved.

There is a workaround for this issue as Sahoo points out above.

Comment by TangYong [ 15/Oct/12 11:07 PM ]

siva, sahoo,

Please add a osgi-javaee component for the issue.

Comment by TangYong [ 25/Mar/13 01:36 PM ]

Because the bug depends on GLASSFISH-15249 which will be implemented in future release, fix version is adjusted into future release.





Generated at Thu Apr 24 06:24:57 UTC 2014 using JIRA 4.0.2#472.