[GLASSFISH-21363] Deadlock in JavaEEExtender between deploy and undeploy Created: 26/May/15  Updated: 26/May/15

Status: Open
Project: glassfish
Component/s: OSGi-JavaEE
Affects Version/s: 3.1, 4.1
Fix Version/s: None

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


 Description   

We have a significant number of OSGi bundles with EJB content. When redeploying a bundle and a dependency of that bundle (simply touching the files) we get a deadlock between the deploy and undeploy in JavaEEExtender.

Here's the two threads, one has the Felix global bundle lock and one is trying to obtain it, while the other has a lock on the JavaEEExtender and one is trying to obtain that.

"pool-15-thread-1" #113 prio=5 os_prio=0 tid=0x00007f147c00e800 nid=0x8a4 in Object.wait() [0x00007f14563eb000]
   java.lang.Thread.State: WAITING (on object monitor)
	at java.lang.Object.wait(Native Method)
	at java.lang.Object.wait(Object.java:502)
	at org.apache.felix.framework.Felix.acquireBundleLock(Felix.java:5039)
	- locked <0x0000000721bfb720> (a [Ljava.lang.Object;)
	at org.apache.felix.framework.Felix.startBundle(Felix.java:1866)
	at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:955)
	at org.jvnet.hk2.osgiadapter.OSGiModuleImpl.start(OSGiModuleImpl.java:210)
	- locked <0x0000000721346de0> (a org.jvnet.hk2.osgiadapter.OSGiModuleImpl)
	at org.jvnet.hk2.osgiadapter.OsgiPopulatorPostProcessor$1.loadClass(OsgiPopulatorPostProcessor.java:77)
	at org.jvnet.hk2.internal.ServiceLocatorImpl.loadClass(ServiceLocatorImpl.java:2058)
	at org.jvnet.hk2.internal.ServiceLocatorImpl.reifyDescriptor(ServiceLocatorImpl.java:413)
	at org.jvnet.hk2.internal.ServiceLocatorImpl.narrow(ServiceLocatorImpl.java:2120)
	at org.jvnet.hk2.internal.ServiceLocatorImpl.access$900(ServiceLocatorImpl.java:119)
	at org.jvnet.hk2.internal.ServiceLocatorImpl$8.compute(ServiceLocatorImpl.java:1063)
	at org.jvnet.hk2.internal.ServiceLocatorImpl$8.compute(ServiceLocatorImpl.java:1058)
	at org.glassfish.hk2.utilities.cache.LRUHybridCache$OriginThreadAwareFuture$1.call(LRUHybridCache.java:115)
	at org.glassfish.hk2.utilities.cache.LRUHybridCache$OriginThreadAwareFuture$1.call(LRUHybridCache.java:111)
	at java.util.concurrent.FutureTask.run(FutureTask.java:266)
	at org.glassfish.hk2.utilities.cache.LRUHybridCache$OriginThreadAwareFuture.run(LRUHybridCache.java:173)
	at org.glassfish.hk2.utilities.cache.LRUHybridCache.compute(LRUHybridCache.java:292)
	at org.jvnet.hk2.internal.ServiceLocatorImpl.internalGetDescriptor(ServiceLocatorImpl.java:1147)
	at org.jvnet.hk2.internal.ServiceLocatorImpl.getServiceHandle(ServiceLocatorImpl.java:1395)
	at org.jvnet.hk2.internal.ServiceLocatorImpl.getServiceHandle(ServiceLocatorImpl.java:1384)
	at com.sun.enterprise.v3.server.ContainerStarter.startContainer(ContainerStarter.java:112)
	at com.sun.enterprise.v3.server.ApplicationLifecycle.setupContainer(ApplicationLifecycle.java:997)
	at com.sun.enterprise.v3.server.ApplicationLifecycle.setupContainerInfos(ApplicationLifecycle.java:702)
	- locked <0x000000072068a430> (a org.glassfish.internal.data.ContainerRegistry)
	at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:377)
	at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:219)
	at org.glassfish.osgijavaeebase.OSGiDeploymentRequest.deploy(OSGiDeploymentRequest.java:185)
	at org.glassfish.osgijavaeebase.OSGiDeploymentRequest.execute(OSGiDeploymentRequest.java:120)
	at org.glassfish.osgijavaeebase.AbstractOSGiDeployer.deploy(AbstractOSGiDeployer.java:123)
	at org.glassfish.osgijavaeebase.OSGiContainer.deploy(OSGiContainer.java:154)
	- locked <0x000000072ade0e90> (a org.glassfish.osgijavaeebase.OSGiContainer)
	at org.glassfish.osgijavaeebase.JavaEEExtender.deploy(JavaEEExtender.java:109)
	- locked <0x000000072ade0e70> (a org.glassfish.osgijavaeebase.JavaEEExtender)
	at org.glassfish.osgijavaeebase.JavaEEExtender.access$200(JavaEEExtender.java:61)
	at org.glassfish.osgijavaeebase.JavaEEExtender$HybridBundleTrackerCustomizer$1.call(JavaEEExtender.java:153)
	at org.glassfish.osgijavaeebase.JavaEEExtender$HybridBundleTrackerCustomizer$1.call(JavaEEExtender.java:150)
	at java.util.concurrent.FutureTask.run(FutureTask.java:266)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
	at java.lang.Thread.run(Thread.java:745)

And this one

"FelixFrameworkWiring" #369 daemon prio=5 os_prio=0 tid=0x00007f14682cb000 nid=0x1296 waiting for monitor entry [0x00007f1474a59000]
   java.lang.Thread.State: BLOCKED (on object monitor)
	at org.glassfish.osgijavaeebase.JavaEEExtender.undeploy(JavaEEExtender.java:122)
	- waiting to lock <0x000000072ade0e70> (a org.glassfish.osgijavaeebase.JavaEEExtender)
	at org.glassfish.osgijavaeebase.JavaEEExtender.access$600(JavaEEExtender.java:61)
	at org.glassfish.osgijavaeebase.JavaEEExtender$HybridBundleTrackerCustomizer.removedBundle(JavaEEExtender.java:206)
	at org.osgi.util.tracker.BundleTracker$Tracked.customizerRemoved(BundleTracker.java:491)
	at org.osgi.util.tracker.BundleTracker$Tracked.customizerRemoved(BundleTracker.java:414)
	at org.osgi.util.tracker.AbstractTracked.untrack(AbstractTracked.java:341)
	at org.osgi.util.tracker.BundleTracker$Tracked.bundleChanged(BundleTracker.java:449)
	at org.apache.felix.framework.util.EventDispatcher.invokeBundleListenerCallback(EventDispatcher.java:868)
	at org.apache.felix.framework.util.EventDispatcher.fireEventImmediately(EventDispatcher.java:789)
	at org.apache.felix.framework.util.EventDispatcher.fireBundleEvent(EventDispatcher.java:514)
	at org.apache.felix.framework.Felix.fireBundleEvent(Felix.java:4403)
	at org.apache.felix.framework.Felix.stopBundle(Felix.java:2520)
	at org.apache.felix.framework.Felix$RefreshHelper.stop(Felix.java:4792)
	at org.apache.felix.framework.Felix.refreshPackages(Felix.java:4104)
	at org.apache.felix.framework.FrameworkWiringImpl.run(FrameworkWiringImpl.java:178)
	at java.lang.Thread.run(Thread.java:745)

It seems like the JavaEEExtender class has two problems. 1) One is that deploy and undeploy are synchronized although comments indicate that synchronization is to prevent deploys and undeploys while the class is starting and stopping. A ReadWriteLock could be used to accomplish the goal without making deploy and undeploy mutually exclusive. 2) More importantly, undeploy isn't done in a separate thread like deploy so you can get into this deadlock situation because the felix global lock is held when undeploy is called. Moving undeploy into its own thread should solve that problem (and avoid kicking the deadlock problem down the road to the highly synchronized OSGiContainer).






[GLASSFISH-21216] Java Batch does not work properly in Hybrid wep and ejb Created: 26/Sep/14  Updated: 25/Feb/15

Status: Open
Project: glassfish
Component/s: batch, OSGi-JavaEE
Affects Version/s: 4.1
Fix Version/s: None

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

windows 8.1
jdk1.8.0_20



 Description   

If I deploy a wab or a hybrid ejb which is OSGi-Bundle the jbatch runtime does not work properly anymore. jbatch seems like it would start the job, but failes to execute the actual artifact, i.e. a batchlet.
If I deploy the archive as plain web app or ejb than everything works fine.
I traced the logs until the BatchWorkUnit should start but the logging stops there and no error messages get printed out in the console.

I created a post on the glassfish forum: https://www.java.net/forum/topic/glassfish/jsr-352-within-osgi-ejb-or-war-failes-execute-batch-job?force=286

There I attached a sample application, which demonstrate the issue. If you deploy the app as plain web app, the you will see the output:
Information: Starting batch...
Information: Batch with executionId: 14.780 started!
Information: SimpleBatchlet executed

If you deploy the package as OSGi bundle you only get to see:
Information: Starting batch...
Information: Batch with executionId: 14.780 started!

This means I can't use jbatch in the OSGi environment, which I need currently. And it seems like I'm not able to access the jbatch runtime with a plain OSGi bundle.



 Comments   
Comment by kewlmain [ 12/Oct/14 ]

After a few days of debugging I found out the problem lies somewhere in the ManagedExecuterServiceImpl, to be precise in the ContextSetupProviderImpl class on line 210:

private boolean isApplicationEnabled(String appId) {
if (appId != null)

{ Application app = applications.getApplication(appId); // return null if (app != null) return deployment.isAppEnabled(app); }

return false;
}

It seems like the hybrid bundles (doesn't matter whether WAB or EJB) are not recognised as enabled applications. I'm not sure why? The glassfish logs don't report any kind of exceptions, which could indicate whether the bundle was installed and started without any errors. The OSGi view of the admin web gui displays the bundle was started and is active successfully.

Do I miss something regarding how bundles are handled and this is the desired behaviour? I thought the point of the hybrid bundles was to have access to both the JavaEE and OSGi world. But in my case the bundles don't have access to the ManagedExecutorService implementations.

Maybe I missed some configuration entries in the pom file of the bundles, which could enabled this feature ?

Comment by smillidge-c2b2 [ 25/Feb/15 ]

I believe this is a simple race condition. The EJB startup class PostConstruct method is called before the application is fully deployed hence the failure in the code you have described above.

Comment by smillidge-c2b2 [ 25/Feb/15 ]

The EJB specification doesn't state that you can use JBatch or concurrency utility within a Singleton @Startup @Postconstruct method. I suppose this needs clarification from EJB spec leads.

The spec says you can only do;

SessionContext methods: getBusinessObject, getRollbackOnly, setRollbackOnly, getTimerService, lookup, getContextData
JNDI access to java:comp/env
Resource manager access
Enterprise bean access
EntityManagerFactory access
EntityManager access
TimerService and Timer methods





[GLASSFISH-11208] JSP compiler Erro whit OSGI imported class Created: 29/Nov/09  Updated: 05/Jan/15

Status: Open
Project: glassfish
Component/s: OSGi-JavaEE
Affects Version/s: V3
Fix Version/s: not determined

Type: Bug Priority: Major
Reporter: sebglon Assignee: Sanjeeb Sahoo
Resolution: Unresolved Votes: 5
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 11,208
Status Whiteboard:

v3_exclude

Tags: 3_1-exclude

 Description   

have 2 bundle:
Bundla A --> a WAB bundle with a JSP pages
and
Bundle B --> that export class with static fields

The JSP pages (in Bundle A) use the exported class (in Bundle B)
When I want to see my page, i have compilation
error "org.apache.jasper.JasperException: PWC6033: Error in Javac compilation
for JSP"

Current GlassFish JSP compiler can't
see classes imported from another WAB. This is because it expects all
the dependencies to be specified in a classpath which it can pass onto
the javac. I have always felt, JSP compiler should use a classloader
backed JavaFileManager.

Forum Thread
http://forums.java.net/jive/thread.jspa?messageID=373634



 Comments   
Comment by sebglon [ 30/Nov/09 ]
      • Issue 11208 has been confirmed by votes. ***
Comment by kumara [ 30/Nov/09 ]

This is an extensive change and too risky for the v3 release targeted for next week. It will be addressed in
the next release.

Comment by Sanjeeb Sahoo [ 12/Oct/10 ]

Unfortunately, because of time constraints, we have to exclude this from 3.1 rel.

Comment by ruans [ 27/Jan/12 ]

Is there any fix for this in 3.* I've tried 3.1.2 build 26-01-2012 and the problem persists. I am forced to run my sites in karaf with pax and jetty at the moment. Much rather be using glassfish.

org.apache.jasper.JasperException: PWC6033: Error in Javac compilation for JSP

PWC6199: Generated servlet error:
string:///index_jsp.java:9: package com.net1.core.commons.web does not exist

PWC6199: Generated servlet error:
string:///index_jsp.java:10: package com.net1.core.commons.web.tag does not exist

PWC6199: Generated servlet error:
string:///index_jsp.java:11: package com.net1.core.commons.web.util does not exist

at org.apache.jasper.compiler.DefaultErrorHandler.javacError(DefaultErrorHandler.java:129)
at org.apache.jasper.compiler.ErrorDispatcher.javacError(ErrorDispatcher.java:299)
at org.apache.jasper.compiler.Compiler.generateClass(Compiler.java:392)
at org.apache.jasper.compiler.Compiler.compile(Compiler.java:453)
at org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:625)
at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:374)
at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:473)
at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:377)

Comment by Tom Mueller [ 06/Mar/12 ]

Bulk update to change fix version to "not determined" for all issues still open but with a fix version for a released version.

Comment by Sanjeeb Sahoo [ 30/Sep/13 ]

This issue is difficult to fix until JSP compiler allows us to use class loaders to be used for searching classes. So deferring it for now. Recommended work around is to use offline JSP compiler to precompile JSPs and package them in the WAB.

Comment by ejroberts [ 18/Oct/13 ]

One workaround is to push the use of the OSGi provided classes out of the JSP pages and into a local class available from within the WAB.

I have found that this manages to defer the class loading until such a point where it is then the compiled Servlet class that loads the OSGi provided classes.

Comment by PashaTurok [ 27/Dec/14 ]

The same I have in GlassFish 4.1. Five years have passed since this bug was fired. Can you say if you are going to fix it?

Comment by PashaTurok [ 05/Jan/15 ]

Please, anyone, answer my question. It's impossible to use jsp with this bug as it makes duplicate code and all soft architecture becomes a nightmare.





[GLASSFISH-20782] [Fighterfish Test]test_GLASSFISH_12975() has some regression Created: 27/Aug/13  Updated: 19/Sep/14

Status: Open
Project: glassfish
Component/s: OSGi, OSGi-JavaEE
Affects Version/s: None
Fix Version/s: 4.1

Type: Bug Priority: Critical
Reporter: TangYong Assignee: Sanjeeb Sahoo
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows
4.0.1/nightly/ 26-Aug-2013 07:25



 Description   

test_GLASSFISH_12975() causes Fighterfish Test failed as following,

[#|2013-08-27T15:16:29.922+0900|SEVERE|glassfish 4.0|org.ops4j.pax.exam.junit.JUnit4TestRunner|_ThreadID=1;_ThreadName=main;_TimeMillis=1377584189922;_LevelValue=1000;ClassName=org.ops4j.pax.exam.junit.JUnit4TestRunner$3;MethodName=evaluate;|
Exception
org.ops4j.pax.exam.TestContainerException: [test_GLASSFISH_12975(org.glassfish.fighterfish.test.it.T2_Test): Aether Error.]
at org.ops4j.pax.exam.invoker.junit.internal.JUnitProbeInvoker.invokeViaJUnit(JUnitProbeInvoker.java:112)
at org.ops4j.pax.exam.invoker.junit.internal.JUnitProbeInvoker.findAndInvoke(JUnitProbeInvoker.java:89)
at org.ops4j.pax.exam.invoker.junit.internal.JUnitProbeInvoker.call(JUnitProbeInvoker.java:72)
at org.ops4j.pax.exam.nat.internal.NativeTestContainer.call(NativeTestContainer.java:86)
at org.ops4j.pax.exam.spi.reactors.EagerSingleStagedReactor.invoke(EagerSingleStagedReactor.java:85)
at org.ops4j.pax.exam.junit.JUnit4TestRunner$3.evaluate(JUnit4TestRunner.java:289)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:76)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:193)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:52)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:191)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:42)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:184)
at org.junit.runners.ParentRunner.run(ParentRunner.java:236)
at org.ops4j.pax.exam.junit.JUnit4TestRunner.run(JUnit4TestRunner.java:87)
at org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:53)
at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:119)
at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:101)
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.apache.maven.surefire.booter.ProviderFactory$ClassLoaderProxy.invoke(ProviderFactory.java:103)
at $Proxy0.invoke(Unknown Source)
at org.apache.maven.surefire.booter.SurefireStarter.invokeProvider(SurefireStarter.java:150)
at org.apache.maven.surefire.booter.SurefireStarter.runSuitesInProcess(SurefireStarter.java:91)
at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:69)
Caused by: java.io.IOException: Aether Error.
at org.ops4j.pax.url.mvn.internal.AetherBasedResolver.resolve(AetherBasedResolver.java:234)
at org.ops4j.pax.url.mvn.internal.AetherBasedResolver.resolve(AetherBasedResolver.java:221)
at org.ops4j.pax.url.mvn.internal.Connection.getInputStream(Connection.java:120)
at java.net.URL.openStream(URL.java:1037)
at org.glassfish.fighterfish.test.it.T2_Test.test_GLASSFISH_12975(T2_Test.java:742)
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:44)
at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41)
at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:69)
at org.ops4j.pax.exam.invoker.junit.internal.ContainerTestRunner.runChild(ContainerTestRunner.java:58)
at org.ops4j.pax.exam.invoker.junit.internal.ContainerTestRunner.runChild(ContainerTestRunner.java:32)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222)
at org.junit.runners.ParentRunner.run(ParentRunner.java:292)
at org.junit.runner.JUnitCore.run(JUnitCore.java:157)
at org.junit.runner.JUnitCore.run(JUnitCore.java:136)
at org.ops4j.pax.exam.invoker.junit.internal.JUnitProbeInvoker.invokeViaJUnit(JUnitProbeInvoker.java:108)
... 26 more
Caused by: org.sonatype.aether.resolution.ArtifactResolutionException: Could not transfer artifact org.glassfish.main.osgi-platforms:felix-webconsole-extension:jar:4.0.1-SNAPSHOT from/to maven-central (http://repo1.maven.org/maven2/): Error transferring file: repo1.maven.org
at org.sonatype.aether.impl.internal.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:541)
at org.sonatype.aether.impl.internal.DefaultArtifactResolver.resolveArtifacts(DefaultArtifactResolver.java:220)
at org.sonatype.aether.impl.internal.DefaultArtifactResolver.resolveArtifact(DefaultArtifactResolver.java:197)
at org.sonatype.aether.impl.internal.DefaultRepositorySystem.resolveArtifact(DefaultRepositorySystem.java:323)
at org.ops4j.pax.url.mvn.internal.AetherBasedResolver.resolve(AetherBasedResolver.java:232)
... 51 more
Caused by: org.sonatype.aether.transfer.ArtifactTransferException: Could not transfer artifact org.glassfish.main.osgi-platforms:felix-webconsole-extension:jar:4.0.1-SNAPSHOT from/to maven-central (http://repo1.maven.org/maven2/): Error transferring file: repo1.maven.org
at org.sonatype.aether.connector.wagon.WagonRepositoryConnector$4.wrap(WagonRepositoryConnector.java:949)
at org.sonatype.aether.connector.wagon.WagonRepositoryConnector$4.wrap(WagonRepositoryConnector.java:940)
at org.sonatype.aether.connector.wagon.WagonRepositoryConnector$GetTask.flush(WagonRepositoryConnector.java:695)
at org.sonatype.aether.connector.wagon.WagonRepositoryConnector$GetTask.flush(WagonRepositoryConnector.java:689)
at org.sonatype.aether.connector.wagon.WagonRepositoryConnector.get(WagonRepositoryConnector.java:445)
at org.sonatype.aether.impl.internal.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:460)
... 55 more
Caused by: org.apache.maven.wagon.TransferFailedException: Error transferring file: repo1.maven.org
at org.apache.maven.wagon.providers.http.LightweightHttpWagon.fillInputData(LightweightHttpWagon.java:143)
at org.apache.maven.wagon.StreamWagon.getInputStream(StreamWagon.java:116)
at org.apache.maven.wagon.StreamWagon.getIfNewer(StreamWagon.java:88)
at org.apache.maven.wagon.StreamWagon.get(StreamWagon.java:61)
at org.sonatype.aether.connector.wagon.WagonRepositoryConnector$GetTask.run(WagonRepositoryConnector.java:608)
at org.sonatype.aether.util.concurrency.RunnableErrorForwarder$1.run(RunnableErrorForwarder.java:64)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
at java.lang.Thread.run(Thread.java:722)
Caused by: java.net.UnknownHostException: repo1.maven.org
at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:178)
at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:157)
at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:391)
at java.net.Socket.connect(Socket.java:579)
at java.net.Socket.connect(Socket.java:528)
at sun.net.NetworkClient.doConnect(NetworkClient.java:180)
at sun.net.www.http.HttpClient.openServer(HttpClient.java:378)
at sun.net.www.http.HttpClient.openServer(HttpClient.java:473)
at sun.net.www.http.HttpClient.<init>(HttpClient.java:203)
at sun.net.www.http.HttpClient.New(HttpClient.java:290)
at sun.net.www.http.HttpClient.New(HttpClient.java:306)
at sun.net.www.protocol.http.HttpURLConnection.getNewHttpClient(HttpURLConnection.java:995)
at sun.net.www.protocol.http.HttpURLConnection.plainConnect(HttpURLConnection.java:931)
at sun.net.www.protocol.http.HttpURLConnection.connect(HttpURLConnection.java:849)
at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1299)
at java.net.HttpURLConnection.getResponseCode(HttpURLConnection.java:468)
at org.apache.maven.wagon.providers.http.LightweightHttpWagon.fillInputData(LightweightHttpWagon.java:115)
... 8 more

#]


 Comments   
Comment by TangYong [ 27/Aug/13 ]

Noting that in test_GLASSFISH_12975() , the following,

String location2 = "mvn:org.glassfish.main.osgi-platforms/felix-webconsole-extension/4.0.1-SNAPSHOT/jar";

I used 4.0.1/nightly/ 26-Aug-2013 07:25 rather than SNAPSHOT from trunk, and, my local maven repo can not have such bundle, and repo1 or other maven repos have not such bundle too. So, pl. Sahoo explains the reason using 4.0.1-SNAPSHOT here. I think that the test failure is caused by the issue.

Thanks
Tang

Comment by Sanjeeb Sahoo [ 27/Aug/13 ]

We should change the URL in test to use 4.0.1-b01 which is available in maven central.

Comment by TangYong [ 27/Aug/13 ]

Will change it and also noticing that 4.0.1-b01 is in https://maven.java.net/content/groups/promoted rather than other repos including repo1, so, whether glassfish osgi fighterfish wiki will be updated to add a description?

Comment by Sanjeeb Sahoo [ 27/Aug/13 ]

See if we can use 4.0 instead of 4.0.1?

Comment by TangYong [ 27/Aug/13 ]

Let us to see the result of using 4.0.1-b01,

[#|2013-08-27T15:55:13.871+0900|SEVERE|glassfish 4.0|org.ops4j.pax.exam.junit.JUnit4TestRunner|_ThreadID=1;_ThreadName=main;_TimeMillis=1377586513871;_LevelValue=1000;ClassName=org.ops4j.pax.exam.junit.JUnit4TestRunner$3;MethodName=evaluate;|
Exception
org.ops4j.pax.exam.TestContainerException: [test_GLASSFISH_12975(org.glassfish.fighterfish.test.it.T2_Test): Admin Console Not Available expected:<200> but was:<401>]
at org.ops4j.pax.exam.invoker.junit.internal.JUnitProbeInvoker.invokeViaJUnit(JUnitProbeInvoker.java:112)
at org.ops4j.pax.exam.invoker.junit.internal.JUnitProbeInvoker.findAndInvoke(JUnitProbeInvoker.java:89)
at org.ops4j.pax.exam.invoker.junit.internal.JUnitProbeInvoker.call(JUnitProbeInvoker.java:72)
at org.ops4j.pax.exam.nat.internal.NativeTestContainer.call(NativeTestContainer.java:86)
at org.ops4j.pax.exam.spi.reactors.EagerSingleStagedReactor.invoke(EagerSingleStagedReactor.java:85)
at org.ops4j.pax.exam.junit.JUnit4TestRunner$3.evaluate(JUnit4TestRunner.java:289)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:76)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:193)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:52)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:191)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:42)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:184)
at org.junit.runners.ParentRunner.run(ParentRunner.java:236)
at org.ops4j.pax.exam.junit.JUnit4TestRunner.run(JUnit4TestRunner.java:87)
at org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:53)
at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:119)
at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:101)
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.apache.maven.surefire.booter.ProviderFactory$ClassLoaderProxy.invoke(ProviderFactory.java:103)
at $Proxy0.invoke(Unknown Source)
at org.apache.maven.surefire.booter.SurefireStarter.invokeProvider(SurefireStarter.java:150)
at org.apache.maven.surefire.booter.SurefireStarter.runSuitesInProcess(SurefireStarter.java:91)
at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:69)
Caused by: java.lang.AssertionError: Admin Console Not Available expected:<200> but was:<401>
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.failNotEquals(Assert.java:647)
at org.junit.Assert.assertEquals(Assert.java:128)
at org.junit.Assert.assertEquals(Assert.java:472)
at org.glassfish.fighterfish.test.it.T2_Test.test_GLASSFISH_12975(T2_Test.java:780)
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:44)
at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41)
at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:69)
at org.ops4j.pax.exam.invoker.junit.internal.ContainerTestRunner.runChild(ContainerTestRunner.java:58)
at org.ops4j.pax.exam.invoker.junit.internal.ContainerTestRunner.runChild(ContainerTestRunner.java:32)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222)
at org.junit.runners.ParentRunner.run(ParentRunner.java:292)
at org.junit.runner.JUnitCore.run(JUnitCore.java:157)
at org.junit.runner.JUnitCore.run(JUnitCore.java:136)
at org.ops4j.pax.exam.invoker.junit.internal.JUnitProbeInvoker.invokeViaJUnit(JUnitProbeInvoker.java:108)
... 26 more

#]

The above means that accessing "http://localhost:8080/osgi/system/console/bundles" failed.

Comment by TangYong [ 27/Aug/13 ]

4.0 is the same as 4.0.1, and noticing that in console, the following,

[#|2013-08-27T16:06:31.647+0900|WARNING|glassfish 4.0|org.glassfish.security.services|_ThreadID=301;_ThreadName=http-listener-1(2);_TimeMillis=1377587191647;_LevelValue=900;ClassName=org.glassfish.security.services.common.SecurityAccessValidator;MethodName=checkPerm;|
Check Permission failed in lookup for permission = ("org.glassfish.security.services.common.SecureServiceAccessPermission" "security/service/authentication")|#]

[#|2013-08-27T16:06:31.662+0900|INFO|glassfish 4.0|javax.enterprise.system.core.security|_ThreadID=300;_ThreadName=http-listener-1(1);_TimeMillis=1377587191662;_LevelValue=800;ClassName=com.sun.enterprise.security.provider.BasePolicyWrapper$2;MethodName=run;|
JACC Policy Provider: Failed Permission Check, context(null)- permission(("org.glassfish.security.services.common.SecureServiceAccessPermission" "security/service/authentication"))|#]

[#|2013-08-27T16:06:31.662+0900|WARNING|glassfish 4.0|org.glassfish.security.services|_ThreadID=300;_ThreadName=http-listener-1(1);_TimeMillis=1377587191662;_LevelValue=900;ClassName=org.glassfish.security.services.common.SecurityAccessValidator;MethodName=checkPerm;|
Check Permission failed in lookup for permission = ("org.glassfish.security.services.common.SecureServiceAccessPermission" "security/service/authentication")|#]

[#|2013-08-27T16:06:31.662+0900|INFO|glassfish 4.0|javax.enterprise.system.core.security|_ThreadID=302;_ThreadName=http-listener-1(3);_TimeMillis=1377587191662;_LevelValue=800;ClassName=com.sun.enterprise.security.provider.BasePolicyWrapper$2;MethodName=run;|
JACC Policy Provider: Failed Permission Check, context(null)- permission(("org.glassfish.security.services.common.SecureServiceAccessPermission" "security/service/authentication"))|#]

[#|2013-08-27T16:06:31.662+0900|WARNING|glassfish 4.0|org.glassfish.security.services|_ThreadID=302;_ThreadName=http-listener-1(3);_TimeMillis=1377587191662;_LevelValue=900;ClassName=org.glassfish.security.services.common.SecurityAccessValidator;MethodName=checkPerm;|
Check Permission failed in lookup for permission = ("org.glassfish.security.services.common.SecureServiceAccessPermission" "security/service/authentication")|#]

[#|2013-08-27T16:06:31.662+0900|INFO|glassfish 4.0|javax.enterprise.system.core.security|_ThreadID=304;_ThreadName=http-listener-1(5);_TimeMillis=1377587191662;_LevelValue=800;ClassName=com.sun.enterprise.security.provider.BasePolicyWrapper$2;MethodName=run;|
JACC Policy Provider: Failed Permission Check, context(null)- permission(("org.glassfish.security.services.common.SecureServiceAccessPermission" "security/service/authentication"))|#]

[#|2013-08-27T16:06:31.662+0900|WARNING|glassfish 4.0|org.glassfish.security.services|_ThreadID=304;_ThreadName=http-listener-1(5);_TimeMillis=1377587191662;_LevelValue=900;ClassName=org.glassfish.security.services.common.SecurityAccessValidator;MethodName=checkPerm;|
Check Permission failed in lookup for permission = ("org.glassfish.security.services.common.SecureServiceAccessPermission" "security/service/authentication")|#]

[#|2013-08-27T16:06:31.662+0900|INFO|glassfish 4.0|org.glassfish.fighterfish.test.it|_ThreadID=1;_ThreadName=main;_TimeMillis=1377587191662;_LevelValue=800;ClassName=T2_Test;MethodName=test_GLASSFISH_12975;|
Sleeping for 5 Seconds on testurl = http://localhost:8080/osgi/system/console/bundles|#]

...

Comment by Sanjeeb Sahoo [ 27/Aug/13 ]

I know why you see that error. It's explained in GLASSFISH-20646. So, we can't use version 4.0. We need a build of webconsole which is later than svn #svn #62246. 4.0.1-b01 won't help as far as I see.

Comment by Sanjeeb Sahoo [ 27/Aug/13 ]

The problem is like this:

FighterFish test suite includes a test for felix-webconsole-extension which is built as part of glassfish, but not installed by default. So, the test is relying on 4.0.1-SNAPSHOT. If we move all our OSGi modules to fighterfish project, we can easily solve this issue via binary integration. Could you own the migration of such modules from glassfish to fighterfish?

Thanks,
Sahoo

Comment by TangYong [ 27/Aug/13 ]

>Could you own the migration of such modules from glassfish to fighterfish?

Apart from felix-webconsole-extension, pl. exactly telling me other modules belonging to us.

About here's "migration", could you please tell me how do you operate, then, I will confirm whether I have the same operation permission。

Thanks
Tang

Comment by TangYong [ 27/Aug/13 ]

Having another temp way:

Making the test case is @Ignore, and letting the jira open, then, once releasing a version later than #svn #62246, I will re-confirm the jira and remove @Ignore.

Agree with me?

Comment by TangYong [ 28/Aug/13 ]

fixing has been checked in.

Revisions:
----------
62668

Comment by Sanjeeb Sahoo [ 29/Aug/13 ]

After this checkin, I noticed a failure while running tests in an environment with clean local maven repository:

[#|2013-08-28T12:44:21.385-0700|SEVERE|glassfish 4.0|org.ops4j.pax.exam.junit.JUnit4TestRunner|_ThreadID=1;_ThreadName=main;_TimeMillis=1377719061385;_LevelValue=1000;ClassName=org.ops4j.pax.exam.junit.JUnit4TestRunner$3;MethodName=evaluate;|
Exception
org.ops4j.pax.exam.TestContainerException: [test_GLASSFISH_12975(org.glassfish.fighterfish.test.it.T2_Test): Aether Error.]
at org.ops4j.pax.exam.invoker.junit.internal.JUnitProbeInvoker.invokeViaJUnit(JUnitProbeInvoker.java:112)
at org.ops4j.pax.exam.invoker.junit.internal.JUnitProbeInvoker.findAndInvoke(JUnitProbeInvoker.java:89)
at org.ops4j.pax.exam.invoker.junit.internal.JUnitProbeInvoker.call(JUnitProbeInvoker.java:72)
at org.ops4j.pax.exam.nat.internal.NativeTestContainer.call(NativeTestContainer.java:86)
at org.ops4j.pax.exam.spi.reactors.EagerSingleStagedReactor.invoke(EagerSingleStagedReactor.java:85)
at org.ops4j.pax.exam.junit.JUnit4TestRunner$3.evaluate(JUnit4TestRunner.java:289)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:76)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:193)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:52)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:191)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:42)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:184)
at org.junit.runners.ParentRunner.run(ParentRunner.java:236)
at org.ops4j.pax.exam.junit.JUnit4TestRunner.run(JUnit4TestRunner.java:87)
at org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:53)
at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:119)
at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:101)
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.apache.maven.surefire.booter.ProviderFactory$ClassLoaderProxy.invoke(ProviderFactory.java:103)
at $Proxy0.invoke(Unknown Source)
at org.apache.maven.surefire.booter.SurefireStarter.invokeProvider(SurefireStarter.java:150)
at org.apache.maven.surefire.booter.SurefireStarter.runSuitesInProcess(SurefireStarter.java:91)
at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:69)
Caused by: java.io.IOException: Aether Error.
at org.ops4j.pax.url.mvn.internal.AetherBasedResolver.resolve(AetherBasedResolver.java:234)
at org.ops4j.pax.url.mvn.internal.AetherBasedResolver.resolve(AetherBasedResolver.java:221)
at org.ops4j.pax.url.mvn.internal.Connection.getInputStream(Connection.java:120)
at java.net.URL.openStream(URL.java:1037)
at org.glassfish.fighterfish.test.it.T2_Test.test_GLASSFISH_12975(T2_Test.java:742)
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:44)
at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41)
at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:69)
at org.ops4j.pax.exam.invoker.junit.internal.ContainerTestRunner.runChild(ContainerTestRunner.java:58)
at org.ops4j.pax.exam.invoker.junit.internal.ContainerTestRunner.runChild(ContainerTestRunner.java:32)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222)
at org.junit.runners.ParentRunner.run(ParentRunner.java:292)
at org.junit.runner.JUnitCore.run(JUnitCore.java:157)
at org.junit.runner.JUnitCore.run(JUnitCore.java:136)
at org.ops4j.pax.exam.invoker.junit.internal.JUnitProbeInvoker.invokeViaJUnit(JUnitProbeInvoker.java:108)
... 26 more
Caused by: org.sonatype.aether.resolution.ArtifactResolutionException: Could not find artifact org.glassfish.main.osgi-platforms:felix-webconsole-extension:jar:4.0.1-b02 in local (file:/scratch/java_re/BUILD_AREA/workspace/gf-trunk-fighterfish-it/.m2/repository/)
at org.sonatype.aether.impl.internal.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:541)
at org.sonatype.aether.impl.internal.DefaultArtifactResolver.resolveArtifacts(DefaultArtifactResolver.java:220)
at org.sonatype.aether.impl.internal.DefaultArtifactResolver.resolveArtifact(DefaultArtifactResolver.java:197)
at org.sonatype.aether.impl.internal.DefaultRepositorySystem.resolveArtifact(DefaultRepositorySystem.java:323)
at org.ops4j.pax.url.mvn.internal.AetherBasedResolver.resolve(AetherBasedResolver.java:232)
... 51 more
Caused by: org.sonatype.aether.transfer.ArtifactNotFoundException: Could not find artifact org.glassfish.main.osgi-platforms:felix-webconsole-extension:jar:4.0.1-b02 in local (file:/scratch/java_re/BUILD_AREA/workspace/gf-trunk-fighterfish-it/.m2/repository/)
at org.sonatype.aether.connector.wagon.WagonRepositoryConnector$4.wrap(WagonRepositoryConnector.java:945)
at org.sonatype.aether.connector.wagon.WagonRepositoryConnector$4.wrap(WagonRepositoryConnector.java:940)
at org.sonatype.aether.connector.wagon.WagonRepositoryConnector$GetTask.flush(WagonRepositoryConnector.java:695)
at org.sonatype.aether.connector.wagon.WagonRepositoryConnector$GetTask.flush(WagonRepositoryConnector.java:689)
at org.sonatype.aether.connector.wagon.WagonRepositoryConnector.get(WagonRepositoryConnector.java:445)
at org.sonatype.aether.impl.internal.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:460)
... 55 more

This is a known issue in the version of pax-url used by our tests. pax-url only searches in default maven repository (ie central repo), but this artifact is available in promoted jvnet repo, hence it is unable to find.

I made the following checkin to fix the issue:

Log Message:
------------
Clean up test classpath. Add felix-webconsole-extension
as a dependency so that test can provision it. Currently test is not able to download it from
remote repo because pax-url only searches in central repo and it's not available there.

Revisions:
----------
62676

After this checkin, our hudson job has run fine.

Comment by TangYong [ 30/Aug/13 ]

I think that while I was checking in previous patch, I made a mistake that I have not cleaned my local repo which still contained 4.0.1-b02 ever being downloaded in some way, after I looked at the new checking in, I see.

Thanks Sahoo's deep confirmation!





[GLASSFISH-19775] Upgrading fighterfish test framework to use pax exam 3.0 Created: 06/Mar/13  Updated: 19/Sep/14

Status: Open
Project: glassfish
Component/s: OSGi, OSGi-JavaEE
Affects Version/s: 4.1
Fix Version/s: None

Type: Task Priority: Major
Reporter: TangYong Assignee: TangYong
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Pax Exam has released 3.0.0 and in the release, Pax Exam has made a big change on API.

Currently fighterfish test framework uses pax exam 2.x and I think that it is time for fighterfish test framework to upgrade pax exam into 3.0, and at the same time, I found that there are some redundant setting and classes and maybe fighterfish test related classes need to be refactored properly.

In addition, maybe needing to create some sub-tasks to finish the task.



 Comments   
Comment by Sanjeeb Sahoo [ 11/Mar/13 ]

Deferring to 4.0.1





[GLASSFISH-20791] Creating a new maven archeType to generate a maven project template for supporting GlassFish OSGi EJB Created: 03/Sep/13  Updated: 19/Sep/14

Status: In Progress
Project: glassfish
Component/s: OSGi-JavaEE
Affects Version/s: None
Fix Version/s: 4.1

Type: New Feature Priority: Minor
Reporter: TangYong Assignee: TangYong
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Creating a new maven archeType to generate a maven project template for supporting GlassFish OSGi EJB.

The maven plugin should make an user can use GlassFish OSGi EJB more easy.






[GLASSFISH-20569] [osgi/javaee-test] Print jstack when requests time out Created: 22/May/13  Updated: 19/Sep/14

Status: In Progress
Project: glassfish
Component/s: OSGi-JavaEE
Affects Version/s: None
Fix Version/s: 4.1

Type: Improvement Priority: Major
Reporter: Sanjeeb Sahoo Assignee: TangYong
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

We are occasionally seeing server threads getting stuck during http request execution. This causes the client to close the socket after a predefined timeout. We should do the following in our code which will collect the entire stack trace that we can use to analyse the hang:

try {
// read from socket using http client library
} catch (java.net.SocketTimeoutException e) {
throw new TimeoutException(e);
} finally {
// close the socket...
}



 Comments   
Comment by TangYong [ 22/May/13 ]

Patch has been checked in.

At revision: 62062





[GLASSFISH-15225] [OSGi] CDI beans not accessible in web applications Created: 15/Dec/10  Updated: 19/Sep/14

Status: Open
Project: glassfish
Component/s: cdi, OSGi-JavaEE
Affects Version/s: 3.1_b33
Fix Version/s: 4.1

Type: Bug Priority: Major
Reporter: chaoslayer Assignee: Sanjeeb Sahoo
Resolution: Unresolved Votes: 2
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: GZip Archive dummy-cdi-web-test.tar.gz     File dummy-web.war     XML File weld.faces-config.xml    
Issue Links:
Dependency
depends on GLASSFISH-15353 component id is not unregistered from... Resolved
Status Whiteboard:

Workaround: Use attached faces-config.xml

Tags: 3_1-exclude, 3_1-next, 3_1_1-scrubbed

 Description   

This seems to be related to GLASSFISH-14842.

However as that bug seems to be fixed this could be introduced by the OSGi/CDI integration.

Attached a test project ( dummy-cdi-web-test.tar.gz ) which is a maven project building a WAB. To see the issue immediately try to access it like this:

http://localhost:8080/dummy-web/?name=John

The error I then get is:

/index.xhtml @12,69 value="#

{dummyBean.name}

": Target Unreachable, identifier 'dummyBean' resolved to null

The application worked fine at least with 3.1 promoted b06.



 Comments   
Comment by Sanjeeb Sahoo [ 16/Dec/10 ]

Yes, I can reproduce this issue with latest build. If I deploy the war as a regular war, it works as expected. Siva has to tell us why this is not working as a WAB.

Comment by Sivakumar Thyagarajan [ 17/Dec/10 ]

Analysis: A custom faces config provider org.glassfish.weld.jsf.WeldFacesConfigProvider is used to return the Weld related faces-config.xml to the JSF runtime and this is enabled for CDI applications.

While trying to search for faces config provider in:
ServiceFactoryUtils.getServiceEntries(String) line: 171
ConfigurationResourceProviderFactory.createProviders(ConfigurationResourceProviderFactory$ProviderType) line: 88
ConfigManager.getConfigurationResourceProviders(List<ConfigurationResourceProvider>, ProviderType) line: 467
ConfigManager.getFacesConfigResourceProviders() line: 450
ConfigManager.initialize(ServletContext) line: 321
ConfigureListener.contextInitialized(ServletContextEvent) line: 226
WebModule(StandardContext).contextListenerStart() line: 4683
WebModule.contextListenerStart() line: 531
WebModule(StandardContext).start() line: 5303
WebModule.start() line: 497
VirtualServer(ContainerBase).addChildInternal(Container) line: 917

for a WAR the web application classloader has visibility to urls from WebappClassLoader (delegate=true; repositories=WEB-INF/classes/) has
[org.glassfish.weld.jsf.WeldFacesConfigProvider] and hence the weld faces configuration is used.

For a WAB, OTOH, the OSGiWebDeploymentContext$WABClassLoader
only provides visiblity to [org.glassfish.osgiweb.OSGiFacesConfigResourceProvider], and this results in the weld JSF configuration not getting registered and hence injection fails.

Comment by Sivakumar Thyagarajan [ 17/Dec/10 ]

Transferring to Sahoo to investigate further.

Comment by Sanjeeb Sahoo [ 17/Dec/10 ]

Thanks Siva for telling what's really different. I am looking for a fix. In the meanwhile, I can suggest this simple work around which I have verified by modifying the attached test case:

Package the attached weld.faces-config.xml in META-INF/ directory of the WAB. You don't have to change the name to faces-config.xml. JSF allows custom faces-config to have arbitrary prefix.

I am lowering the priority of this issue because of this work around.

Comment by Sanjeeb Sahoo [ 22/Dec/10 ]

Will be addressed in 3.2 as 3.1 is close to release. Use the suggested work around in the meanwhile.

Comment by chaoslayer [ 23/Dec/10 ]

OK, the plan vanilla CDI works now.

Therefore I just got one step further and added the primefaces library to test some things ( attached "dummy-web.war" ) and here comes the next gotcha:

INFO: Updated /srv/servers/glassfish/v31-b34/glassfish/domains/domain1/autodeploy/bundles/dummy-web.war
INFO: Started bundle: file:/srv/servers/glassfish/v31-b34/glassfish/domains/domain1/autodeploy/bundles/dummy-web.war
INFO: Expanded at file:/tmp/osgiapp1741957746419399825/
INFO: Instantiated an instance of org.hibernate.validator.engine.resolver.JPATraversableResolver.
INFO: total number of classes with faces annotation = 0
SEVERE: ContainerBase.addChild: start:
org.apache.catalina.LifecycleException: java.lang.IllegalArgumentException: javax.servlet.ServletException: com.sun.enterprise.container.common.spi.util.InjectionException: Error creating managed object for class org.jboss.weld.servlet.WeldListener
at org.apache.catalina.core.StandardContext.start(StandardContext.java:5269)
at com.sun.enterprise.web.WebModule.start(WebModule.java:497)
at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:917)
at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:901)
at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:753)
at com.sun.enterprise.web.WebContainer.loadWebModule(WebContainer.java:1981)
at com.sun.enterprise.web.WebContainer.loadWebModule(WebContainer.java:1629)
at com.sun.enterprise.web.WebApplication.start(WebApplication.java:100)
at org.glassfish.internal.data.EngineRef.start(EngineRef.java:130)
at org.glassfish.internal.data.ModuleInfo.start(ModuleInfo.java:269)
at org.glassfish.internal.data.ApplicationInfo.start(ApplicationInfo.java:290)
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)
at org.glassfish.osgijavaeebase.OSGiDeploymentRequest.execute(OSGiDeploymentRequest.java:118)
at org.glassfish.osgijavaeebase.AbstractOSGiDeployer.deploy(AbstractOSGiDeployer.java:121)
at org.glassfish.osgijavaeebase.OSGiContainer.deploy(OSGiContainer.java:147)
at org.glassfish.osgijavaeebase.JavaEEExtender.deploy(JavaEEExtender.java:128)
at org.glassfish.osgijavaeebase.JavaEEExtender.access$100(JavaEEExtender.java:59)
at org.glassfish.osgijavaeebase.JavaEEExtender$HybridBundleTrackerCustomizer$1.run(JavaEEExtender.java:165)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
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)
Caused by: java.lang.IllegalArgumentException: javax.servlet.ServletException: com.sun.enterprise.container.common.spi.util.InjectionException: Error creating managed object for class org.jboss.weld.servlet.WeldListener
at org.apache.catalina.core.StandardContext.addListener(StandardContext.java:2683)
at org.apache.catalina.core.StandardContext.addApplicationListener(StandardContext.java:1927)
at com.sun.enterprise.web.TomcatDeploymentConfig.configureApplicationListener(TomcatDeploymentConfig.java:234)
at com.sun.enterprise.web.TomcatDeploymentConfig.configureWebModule(TomcatDeploymentConfig.java:93)
at com.sun.enterprise.web.WebModuleContextConfig.start(WebModuleContextConfig.java:272)
at com.sun.enterprise.web.WebModuleContextConfig.lifecycleEvent(WebModuleContextConfig.java:172)
at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:149)
at org.apache.catalina.core.StandardContext.start(StandardContext.java:5261)
... 25 more
Caused by: javax.servlet.ServletException: com.sun.enterprise.container.common.spi.util.InjectionException: Error creating managed object for class org.jboss.weld.servlet.WeldListener
at org.apache.catalina.core.StandardContext.createListener(StandardContext.java:2793)
at org.apache.catalina.core.StandardContext.loadListener(StandardContext.java:4738)
at com.sun.enterprise.web.WebModule.loadListener(WebModule.java:1588)
at org.apache.catalina.core.StandardContext.addListener(StandardContext.java:2680)
... 32 more
Caused by: com.sun.enterprise.container.common.spi.util.InjectionException: Error creating managed object for class org.jboss.weld.servlet.WeldListener
at com.sun.enterprise.container.common.impl.util.InjectionManagerImpl.createManagedObject(InjectionManagerImpl.java:317)
at com.sun.enterprise.web.WebContainer.createListenerInstance(WebContainer.java:733)
at com.sun.enterprise.web.WebModule.createListenerInstance(WebModule.java:1966)
at org.apache.catalina.core.StandardContext.createListener(StandardContext.java:2791)
... 35 more
Caused by: java.lang.NullPointerException
at com.sun.enterprise.container.common.impl.managedbean.ManagedBeanManagerImpl.createManagedBean(ManagedBeanManagerImpl.java:485)
at com.sun.enterprise.container.common.impl.managedbean.ManagedBeanManagerImpl.createManagedBean(ManagedBeanManagerImpl.java:428)
at com.sun.enterprise.container.common.impl.util.InjectionManagerImpl.createManagedObject(InjectionManagerImpl.java:300)
... 38 more

WARNING: java.lang.IllegalStateException: ContainerBase.addChild: start: org.apache.catalina.LifecycleException: java.lang.IllegalArgumentException: javax.servlet.ServletException: com.sun.enterprise.container.common.spi.util.InjectionException: Error creating managed object for class org.jboss.weld.servlet.WeldListener
java.lang.IllegalStateException: ContainerBase.addChild: start: org.apache.catalina.LifecycleException: java.lang.IllegalArgumentException: javax.servlet.ServletException: com.sun.enterprise.container.common.spi.util.InjectionException: Error creating managed object for class org.jboss.weld.servlet.WeldListener
at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:921)
at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:901)
at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:753)
at com.sun.enterprise.web.WebContainer.loadWebModule(WebContainer.java:1981)
at com.sun.enterprise.web.WebContainer.loadWebModule(WebContainer.java:1629)
at com.sun.enterprise.web.WebApplication.start(WebApplication.java:100)
at org.glassfish.internal.data.EngineRef.start(EngineRef.java:130)
at org.glassfish.internal.data.ModuleInfo.start(ModuleInfo.java:269)
at org.glassfish.internal.data.ApplicationInfo.start(ApplicationInfo.java:290)
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)
at org.glassfish.osgijavaeebase.OSGiDeploymentRequest.execute(OSGiDeploymentRequest.java:118)
at org.glassfish.osgijavaeebase.AbstractOSGiDeployer.deploy(AbstractOSGiDeployer.java:121)
at org.glassfish.osgijavaeebase.OSGiContainer.deploy(OSGiContainer.java:147)
at org.glassfish.osgijavaeebase.JavaEEExtender.deploy(JavaEEExtender.java:128)
at org.glassfish.osgijavaeebase.JavaEEExtender.access$100(JavaEEExtender.java:59)
at org.glassfish.osgijavaeebase.JavaEEExtender$HybridBundleTrackerCustomizer$1.run(JavaEEExtender.java:165)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
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)

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: java.lang.IllegalArgumentException: javax.servlet.ServletException: com.sun.enterprise.container.common.spi.util.InjectionException: Error creating managed object for class org.jboss.weld.servlet.WeldListener
at com.sun.enterprise.web.WebApplication.start(WebApplication.java:127)
at org.glassfish.internal.data.EngineRef.start(EngineRef.java:130)
at org.glassfish.internal.data.ModuleInfo.start(ModuleInfo.java:269)
at org.glassfish.internal.data.ApplicationInfo.start(ApplicationInfo.java:290)
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)
at org.glassfish.osgijavaeebase.OSGiDeploymentRequest.execute(OSGiDeploymentRequest.java:118)
at org.glassfish.osgijavaeebase.AbstractOSGiDeployer.deploy(AbstractOSGiDeployer.java:121)
at org.glassfish.osgijavaeebase.OSGiContainer.deploy(OSGiContainer.java:147)
at org.glassfish.osgijavaeebase.JavaEEExtender.deploy(JavaEEExtender.java:128)
at org.glassfish.osgijavaeebase.JavaEEExtender.access$100(JavaEEExtender.java:59)
at org.glassfish.osgijavaeebase.JavaEEExtender$HybridBundleTrackerCustomizer$1.run(JavaEEExtender.java:165)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
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)

SEVERE: Exception while loading the app
INFO: Deleted /tmp/osgiapp1741957746419399825
SEVERE: Failed while deploying bundle org.glassfish.osgi.dummy-web [298]
WARNING: Failed to deploy bundle org.glassfish.osgi.dummy-web [298]
org.glassfish.osgijavaeebase.DeploymentException: Deployment of org.glassfish.osgi.dummy-web [298] failed because of following reason: Failed while deploying bundle org.glassfish.osgi.dummy-web [298] : java.lang.RuntimeException: Failed to deploy bundle [ org.glassfish.osgi.dummy-web [298] ], 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:128)
at org.glassfish.osgijavaeebase.JavaEEExtender.access$100(JavaEEExtender.java:59)
at org.glassfish.osgijavaeebase.JavaEEExtender$HybridBundleTrackerCustomizer$1.run(JavaEEExtender.java:165)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
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)
Caused by: java.lang.RuntimeException: Failed to deploy bundle [ org.glassfish.osgi.dummy-web [298] ], 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)
... 10 more
Caused by: java.lang.Exception: java.lang.IllegalStateException: ContainerBase.addChild: start: org.apache.catalina.LifecycleException: java.lang.IllegalArgumentException: javax.servlet.ServletException: com.sun.enterprise.container.common.spi.util.InjectionException: Error creating managed object for class org.jboss.weld.servlet.WeldListener
at com.sun.enterprise.web.WebApplication.start(WebApplication.java:127)
at org.glassfish.internal.data.EngineRef.start(EngineRef.java:130)
at org.glassfish.internal.data.ModuleInfo.start(ModuleInfo.java:269)
at org.glassfish.internal.data.ApplicationInfo.start(ApplicationInfo.java:290)
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)
... 12 more

Comment by chaoslayer [ 23/Dec/10 ]

Well, the last error was introduced somehow because it seems that at least WAB's don't get updated properly.

If I shutdown GlassFish, remove any OSGi cache and startup again I see that it complains with NoClassDefFound which is totally correct on that bundle, but the same should be experienced using a bundle update.

Comment by Sanjeeb Sahoo [ 27/Dec/10 ]

After a lot of debugging, I can now explain why we are seeing a weired exception when we are trying to update the cdi enabled WAB. if we look at the stack, we see
Caused by: java.lang.NullPointerException
at com.sun.enterprise.container.common.impl.managedbean.ManagedBeanManagerImpl.createManagedBean(ManagedBeanManagerImpl.java:485)
at com.sun.enterprise.container.common.impl.managedbean.ManagedBeanManagerImpl.createManagedBean(ManagedBeanManagerImpl.java:428)
at com.sun.enterprise.container.common.impl.util.InjectionManagerImpl.createManagedObject(InjectionManagerImpl.java:300)
... 38 more

The root cause of this is GLASSFISH-15353

Comment by Sanjeeb Sahoo [ 05/Jul/11 ]

Completely missed this bug for 3.1.1. Will definitely do it in 3.2.

Comment by TangYong [ 27/Nov/12 ]

Because of triggering the issue again, consider to increase the priority and investigate how to fix it.

Comment by TangYong [ 26/Mar/13 ]

Updating into 3/26 trunk, and done a confirmation as following(Having a big regression for Workaround):

Scene1: applying Workaround for the first attachment(dummy-cdi-web-test.tar.gz)

After directly putting weld.faces-config.xml into META-INF/ directory of the WAB, deploying the WAB(asadmin deploy --type=osgi D:\20130125\GLASSFISH-15225\dummy-web\target\dummy-web.war) has fatal exception as following:

[2013-03-26T17:10:19.234+0900] [glassfish 4.0] [SEVERE] [] [javax.enterprise.resource.webcontainer.jsf.config] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364285419234] [levelValue: 1000] [[
Critical error during deployment:
com.sun.faces.config.ConfigurationException:
Source Document: bundle://297.0:0/META-INF/weld.faces-config.xml
Cause: Unable to create a new instance of 'org.jboss.weld.jsf.WeldPhaseListener': javax.faces.FacesException: org.jboss.weld.jsf.WeldPhaseListener
at com.sun.faces.config.processor.AbstractConfigProcessor.createInstance(AbstractConfigProcessor.java:353)
at com.sun.faces.config.processor.LifecycleConfigProcessor.addPhaseListeners(LifecycleConfigProcessor.java:132)
at com.sun.faces.config.processor.LifecycleConfigProcessor.process(LifecycleConfigProcessor.java:111)
at com.sun.faces.config.processor.AbstractConfigProcessor.invokeNext(AbstractConfigProcessor.java:152)
at com.sun.faces.config.processor.FactoryConfigProcessor.process(FactoryConfigProcessor.java:239)
at com.sun.faces.config.ConfigManager.initialize(ConfigManager.java:424)
at com.sun.faces.config.ConfigureListener.contextInitialized(ConfigureListener.java:214)
at org.apache.catalina.core.StandardContext.contextListenerStart(StandardContext.java:5362)
at com.sun.enterprise.web.WebModule.contextListenerStart(WebModule.java:743)
at org.apache.catalina.core.StandardContext.start(StandardContext.java:5898)
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:2279)
at com.sun.enterprise.web.WebContainer.loadWebModule(WebContainer.java:1925)
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.osgijavaeebase.OSGiDeploymentRequest.deploy(OSGiDeploymentRequest.java:185)
at org.glassfish.osgijavaeebase.OSGiDeploymentRequest.execute(OSGiDeploymentRequest.java:120)
at org.glassfish.osgijavaeebase.AbstractOSGiDeployer.deploy(AbstractOSGiDeployer.java:123)
at org.glassfish.osgijavaeebase.OSGiContainer.deploy(OSGiContainer.java:154)
at org.glassfish.osgijavaeebase.JavaEEExtender.deploy(JavaEEExtender.java:109)
at org.glassfish.osgijavaeebase.JavaEEExtender.access$200(JavaEEExtender.java:61)
at org.glassfish.osgijavaeebase.JavaEEExtender$HybridBundleTrackerCustomizer$1.call(JavaEEExtender.java:153)
at org.glassfish.osgijavaeebase.JavaEEExtender$HybridBundleTrackerCustomizer$1.call(JavaEEExtender.java:150)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
at java.util.concurrent.FutureTask.run(FutureTask.java:166)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
at java.lang.Thread.run(Thread.java:722)
Caused by: javax.faces.FacesException: org.jboss.weld.jsf.WeldPhaseListener
at com.sun.faces.config.processor.AbstractConfigProcessor.loadClass(AbstractConfigProcessor.java:384)
at com.sun.faces.config.processor.AbstractConfigProcessor.createInstance(AbstractConfigProcessor.java:278)
... 34 more
Caused by: java.lang.ClassNotFoundException: org.jboss.weld.jsf.WeldPhaseListener
at java.lang.ClassLoader.findClass(ClassLoader.java:522)
at java.lang.ClassLoader.loadClass(ClassLoader.java:423)
at com.sun.enterprise.v3.server.APIClassLoaderServiceImpl$APIClassLoader.loadClass(APIClassLoaderServiceImpl.java:257)
at com.sun.enterprise.v3.server.APIClassLoaderServiceImpl$APIClassLoader.loadClass(APIClassLoaderServiceImpl.java:222)
at org.glassfish.osgiweb.OSGiWebDeploymentContext$WABClassLoader.loadClass(OSGiWebDeploymentContext.java:170)
at org.glassfish.osgiweb.OSGiWebDeploymentContext$WABClassLoader.loadClass(OSGiWebDeploymentContext.java:153)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:264)
at com.sun.faces.util.Util.loadClass(Util.java:301)
at com.sun.faces.config.processor.AbstractConfigProcessor.loadClass(AbstractConfigProcessor.java:376)
... 35 more
]]

[2013-03-26T17:10:19.234+0900] [glassfish 4.0] [SEVERE] [AS-WEB-CORE-00174] [javax.enterprise.web.core] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364285419234] [levelValue: 1000] [[
Startup of context /dummy-web failed due to previous errors]]

[2013-03-26T17:10:19.234+0900] [glassfish 4.0] [SEVERE] [AS-WEB-CORE-00175] [javax.enterprise.web.core] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364285419234] [levelValue: 1000] [[
Exception during cleanup after start failed
org.apache.catalina.LifecycleException: Manager has not yet been started
at org.apache.catalina.session.StandardManager.stop(StandardManager.java:934)
at org.apache.catalina.core.StandardContext.stop(StandardContext.java:6099)
at com.sun.enterprise.web.WebModule.stop(WebModule.java:720)
at org.apache.catalina.core.StandardContext.start(StandardContext.java:5916)
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:2279)
at com.sun.enterprise.web.WebContainer.loadWebModule(WebContainer.java:1925)
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.osgijavaeebase.OSGiDeploymentRequest.deploy(OSGiDeploymentRequest.java:185)
at org.glassfish.osgijavaeebase.OSGiDeploymentRequest.execute(OSGiDeploymentRequest.java:120)
at org.glassfish.osgijavaeebase.AbstractOSGiDeployer.deploy(AbstractOSGiDeployer.java:123)
at org.glassfish.osgijavaeebase.OSGiContainer.deploy(OSGiContainer.java:154)
at org.glassfish.osgijavaeebase.JavaEEExtender.deploy(JavaEEExtender.java:109)
at org.glassfish.osgijavaeebase.JavaEEExtender.access$200(JavaEEExtender.java:61)
at org.glassfish.osgijavaeebase.JavaEEExtender$HybridBundleTrackerCustomizer$1.call(JavaEEExtender.java:153)
at org.glassfish.osgijavaeebase.JavaEEExtender$HybridBundleTrackerCustomizer$1.call(JavaEEExtender.java:150)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
at java.util.concurrent.FutureTask.run(FutureTask.java:166)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
at java.lang.Thread.run(Thread.java:722)
]]

[2013-03-26T17:10:19.234+0900] [glassfish 4.0] [SEVERE] [AS-WEB-CORE-00108] [javax.enterprise.web.core] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364285419234] [levelValue: 1000] [[
ContainerBase.addChild: start:
org.apache.catalina.LifecycleException: java.lang.RuntimeException: com.sun.faces.config.ConfigurationException:
Source Document: bundle://297.0:0/META-INF/weld.faces-config.xml
Cause: Unable to create a new instance of 'org.jboss.weld.jsf.WeldPhaseListener': javax.faces.FacesException: org.jboss.weld.jsf.WeldPhaseListener
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:2279)
at com.sun.enterprise.web.WebContainer.loadWebModule(WebContainer.java:1925)
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.osgijavaeebase.OSGiDeploymentRequest.deploy(OSGiDeploymentRequest.java:185)
at org.glassfish.osgijavaeebase.OSGiDeploymentRequest.execute(OSGiDeploymentRequest.java:120)
at org.glassfish.osgijavaeebase.AbstractOSGiDeployer.deploy(AbstractOSGiDeployer.java:123)
at org.glassfish.osgijavaeebase.OSGiContainer.deploy(OSGiContainer.java:154)
at org.glassfish.osgijavaeebase.JavaEEExtender.deploy(JavaEEExtender.java:109)
at org.glassfish.osgijavaeebase.JavaEEExtender.access$200(JavaEEExtender.java:61)
at org.glassfish.osgijavaeebase.JavaEEExtender$HybridBundleTrackerCustomizer$1.call(JavaEEExtender.java:153)
at org.glassfish.osgijavaeebase.JavaEEExtender$HybridBundleTrackerCustomizer$1.call(JavaEEExtender.java:150)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
at java.util.concurrent.FutureTask.run(FutureTask.java:166)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
at java.lang.Thread.run(Thread.java:722)
Caused by: java.lang.RuntimeException: com.sun.faces.config.ConfigurationException:
Source Document: bundle://297.0:0/META-INF/weld.faces-config.xml
Cause: Unable to create a new instance of 'org.jboss.weld.jsf.WeldPhaseListener': javax.faces.FacesException: org.jboss.weld.jsf.WeldPhaseListener
at com.sun.faces.config.ConfigureListener.contextInitialized(ConfigureListener.java:273)
at org.apache.catalina.core.StandardContext.contextListenerStart(StandardContext.java:5362)
at com.sun.enterprise.web.WebModule.contextListenerStart(WebModule.java:743)
at org.apache.catalina.core.StandardContext.start(StandardContext.java:5898)
... 25 more
Caused by: com.sun.faces.config.ConfigurationException:
Source Document: bundle://297.0:0/META-INF/weld.faces-config.xml
Cause: Unable to create a new instance of 'org.jboss.weld.jsf.WeldPhaseListener': javax.faces.FacesException: org.jboss.weld.jsf.WeldPhaseListener
at com.sun.faces.config.processor.AbstractConfigProcessor.createInstance(AbstractConfigProcessor.java:353)
at com.sun.faces.config.processor.LifecycleConfigProcessor.addPhaseListeners(LifecycleConfigProcessor.java:132)
at com.sun.faces.config.processor.LifecycleConfigProcessor.process(LifecycleConfigProcessor.java:111)
at com.sun.faces.config.processor.AbstractConfigProcessor.invokeNext(AbstractConfigProcessor.java:152)
at com.sun.faces.config.processor.FactoryConfigProcessor.process(FactoryConfigProcessor.java:239)
at com.sun.faces.config.ConfigManager.initialize(ConfigManager.java:424)
at com.sun.faces.config.ConfigureListener.contextInitialized(ConfigureListener.java:214)
... 28 more
Caused by: javax.faces.FacesException: org.jboss.weld.jsf.WeldPhaseListener
at com.sun.faces.config.processor.AbstractConfigProcessor.loadClass(AbstractConfigProcessor.java:384)
at com.sun.faces.config.processor.AbstractConfigProcessor.createInstance(AbstractConfigProcessor.java:278)
... 34 more
Caused by: java.lang.ClassNotFoundException: org.jboss.weld.jsf.WeldPhaseListener
at java.lang.ClassLoader.findClass(ClassLoader.java:522)
at java.lang.ClassLoader.loadClass(ClassLoader.java:423)
at com.sun.enterprise.v3.server.APIClassLoaderServiceImpl$APIClassLoader.loadClass(APIClassLoaderServiceImpl.java:257)
at com.sun.enterprise.v3.server.APIClassLoaderServiceImpl$APIClassLoader.loadClass(APIClassLoaderServiceImpl.java:222)
at org.glassfish.osgiweb.OSGiWebDeploymentContext$WABClassLoader.loadClass(OSGiWebDeploymentContext.java:170)
at org.glassfish.osgiweb.OSGiWebDeploymentContext$WABClassLoader.loadClass(OSGiWebDeploymentContext.java:153)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:264)
at com.sun.faces.util.Util.loadClass(Util.java:301)
at com.sun.faces.config.processor.AbstractConfigProcessor.loadClass(AbstractConfigProcessor.java:376)
... 35 more
]]

[2013-03-26T17:10:19.234+0900] [glassfish 4.0] [WARNING] [] [javax.enterprise.web] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364285419234] [levelValue: 900] [[
java.lang.IllegalStateException: ContainerBase.addChild: start: org.apache.catalina.LifecycleException: java.lang.RuntimeException: com.sun.faces.config.ConfigurationException:
Source Document: bundle://297.0:0/META-INF/weld.faces-config.xml
Cause: Unable to create a new instance of 'org.jboss.weld.jsf.WeldPhaseListener': javax.faces.FacesException: org.jboss.weld.jsf.WeldPhaseListener
java.lang.IllegalStateException: ContainerBase.addChild: start: org.apache.catalina.LifecycleException: java.lang.RuntimeException: com.sun.faces.config.ConfigurationException:
Source Document: bundle://297.0:0/META-INF/weld.faces-config.xml
Cause: Unable to create a new instance of 'org.jboss.weld.jsf.WeldPhaseListener': javax.faces.FacesException: org.jboss.weld.jsf.WeldPhaseListener
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:2279)
at com.sun.enterprise.web.WebContainer.loadWebModule(WebContainer.java:1925)
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.osgijavaeebase.OSGiDeploymentRequest.deploy(OSGiDeploymentRequest.java:185)
at org.glassfish.osgijavaeebase.OSGiDeploymentRequest.execute(OSGiDeploymentRequest.java:120)
at org.glassfish.osgijavaeebase.AbstractOSGiDeployer.deploy(AbstractOSGiDeployer.java:123)
at org.glassfish.osgijavaeebase.OSGiContainer.deploy(OSGiContainer.java:154)
at org.glassfish.osgijavaeebase.JavaEEExtender.deploy(JavaEEExtender.java:109)
at org.glassfish.osgijavaeebase.JavaEEExtender.access$200(JavaEEExtender.java:61)
at org.glassfish.osgijavaeebase.JavaEEExtender$HybridBundleTrackerCustomizer$1.call(JavaEEExtender.java:153)
at org.glassfish.osgijavaeebase.JavaEEExtender$HybridBundleTrackerCustomizer$1.call(JavaEEExtender.java:150)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
at java.util.concurrent.FutureTask.run(FutureTask.java:166)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
at java.lang.Thread.run(Thread.java:722)
]]

[2013-03-26T17:10:19.234+0900] [glassfish 4.0] [SEVERE] [] [javax.enterprise.system.tools.deployment.common] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364285419234] [levelValue: 1000] [[
Exception while invoking class com.sun.enterprise.web.WebApplication start method
java.lang.Exception: java.lang.IllegalStateException: ContainerBase.addChild: start: org.apache.catalina.LifecycleException: java.lang.RuntimeException: com.sun.faces.config.ConfigurationException:
Source Document: bundle://297.0:0/META-INF/weld.faces-config.xml
Cause: Unable to create a new instance of 'org.jboss.weld.jsf.WeldPhaseListener': javax.faces.FacesException: org.jboss.weld.jsf.WeldPhaseListener
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.osgijavaeebase.OSGiDeploymentRequest.deploy(OSGiDeploymentRequest.java:185)
at org.glassfish.osgijavaeebase.OSGiDeploymentRequest.execute(OSGiDeploymentRequest.java:120)
at org.glassfish.osgijavaeebase.AbstractOSGiDeployer.deploy(AbstractOSGiDeployer.java:123)
at org.glassfish.osgijavaeebase.OSGiContainer.deploy(OSGiContainer.java:154)
at org.glassfish.osgijavaeebase.JavaEEExtender.deploy(JavaEEExtender.java:109)
at org.glassfish.osgijavaeebase.JavaEEExtender.access$200(JavaEEExtender.java:61)
at org.glassfish.osgijavaeebase.JavaEEExtender$HybridBundleTrackerCustomizer$1.call(JavaEEExtender.java:153)
at org.glassfish.osgijavaeebase.JavaEEExtender$HybridBundleTrackerCustomizer$1.call(JavaEEExtender.java:150)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
at java.util.concurrent.FutureTask.run(FutureTask.java:166)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
at java.lang.Thread.run(Thread.java:722)
]]

[2013-03-26T17:10:19.234+0900] [glassfish 4.0] [SEVERE] [NCLS-CORE-00026] [javax.enterprise.system.core] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364285419234] [levelValue: 1000] [[
Exception during lifecycle processing
java.lang.Exception: java.lang.IllegalStateException: ContainerBase.addChild: start: org.apache.catalina.LifecycleException: java.lang.RuntimeException: com.sun.faces.config.ConfigurationException:
Source Document: bundle://297.0:0/META-INF/weld.faces-config.xml
Cause: Unable to create a new instance of 'org.jboss.weld.jsf.WeldPhaseListener': javax.faces.FacesException: org.jboss.weld.jsf.WeldPhaseListener
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.osgijavaeebase.OSGiDeploymentRequest.deploy(OSGiDeploymentRequest.java:185)
at org.glassfish.osgijavaeebase.OSGiDeploymentRequest.execute(OSGiDeploymentRequest.java:120)
at org.glassfish.osgijavaeebase.AbstractOSGiDeployer.deploy(AbstractOSGiDeployer.java:123)
at org.glassfish.osgijavaeebase.OSGiContainer.deploy(OSGiContainer.java:154)
at org.glassfish.osgijavaeebase.JavaEEExtender.deploy(JavaEEExtender.java:109)
at org.glassfish.osgijavaeebase.JavaEEExtender.access$200(JavaEEExtender.java:61)
at org.glassfish.osgijavaeebase.JavaEEExtender$HybridBundleTrackerCustomizer$1.call(JavaEEExtender.java:153)
at org.glassfish.osgijavaeebase.JavaEEExtender$HybridBundleTrackerCustomizer$1.call(JavaEEExtender.java:150)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
at java.util.concurrent.FutureTask.run(FutureTask.java:166)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
at java.lang.Thread.run(Thread.java:722)
]]

[2013-03-26T17:10:19.234+0900] [glassfish 4.0] [SEVERE] [] [javax.enterprise.system.core] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364285419234] [levelValue: 1000] [[
Exception while loading the app]]

[2013-03-26T17:10:19.234+0900] [glassfish 4.0] [SEVERE] [AS-WEB-GLUE-00192] [javax.enterprise.web] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364285419234] [levelValue: 1000] [[
Undeployment failed for context /dummy-web]]

[2013-03-26T17:10:19.343+0900] [glassfish 4.0] [INFO] [] [org.glassfish.osgijavaeebase] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364285419343] [levelValue: 800] [[
Deleted D:\20130125\glassfish9\glassfish4\glassfish\domains\domain1\osgi-cache\felix\bundle292\data\applications\bundle297-1364285417875]]

[2013-03-26T17:10:19.343+0900] [glassfish 4.0] [SEVERE] [] [org.glassfish.osgijavaeebase] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364285419343] [levelValue: 1000] [[
Failed while deploying bundle org.glassfish.osgi.dummy-web [297]]]

[2013-03-26T17:10:19.343+0900] [glassfish 4.0] [INFO] [] [org.glassfish.osgiweb] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364285419343] [levelValue: 800] [[
Removed bundle 297 against context path /dummy-web ]]

[2013-03-26T17:10:19.343+0900] [glassfish 4.0] [WARNING] [] [org.glassfish.osgijavaeebase] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364285419343] [levelValue: 900] [[
Failed to deploy bundle org.glassfish.osgi.dummy-web [297]
org.glassfish.osgijavaeebase.DeploymentException: Deployment of org.glassfish.osgi.dummy-web [297] failed because of following reason: Failed while deploying bundle org.glassfish.osgi.dummy-web [297] : java.lang.RuntimeException: Failed to deploy bundle [ org.glassfish.osgi.dummy-web [297] ], root cause: Exception while loading the app
at org.glassfish.osgijavaeebase.AbstractOSGiDeployer.deploy(AbstractOSGiDeployer.java:127)
at org.glassfish.osgijavaeebase.OSGiContainer.deploy(OSGiContainer.java:154)
at org.glassfish.osgijavaeebase.JavaEEExtender.deploy(JavaEEExtender.java:109)
at org.glassfish.osgijavaeebase.JavaEEExtender.access$200(JavaEEExtender.java:61)
at org.glassfish.osgijavaeebase.JavaEEExtender$HybridBundleTrackerCustomizer$1.call(JavaEEExtender.java:153)
at org.glassfish.osgijavaeebase.JavaEEExtender$HybridBundleTrackerCustomizer$1.call(JavaEEExtender.java:150)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
at java.util.concurrent.FutureTask.run(FutureTask.java:166)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
at java.lang.Thread.run(Thread.java:722)
Caused by: java.lang.RuntimeException: Failed to deploy bundle [ org.glassfish.osgi.dummy-web [297] ], root cause: Exception while loading the app
at org.glassfish.osgijavaeebase.OSGiDeploymentRequest.deploy(OSGiDeploymentRequest.java:198)
at org.glassfish.osgijavaeebase.OSGiDeploymentRequest.execute(OSGiDeploymentRequest.java:120)
at org.glassfish.osgijavaeebase.AbstractOSGiDeployer.deploy(AbstractOSGiDeployer.java:123)
... 10 more
Caused by: java.lang.Exception: java.lang.IllegalStateException: ContainerBase.addChild: start: org.apache.catalina.LifecycleException: java.lang.RuntimeException: com.sun.faces.config.ConfigurationException:
Source Document: bundle://297.0:0/META-INF/weld.faces-config.xml
Cause: Unable to create a new instance of 'org.jboss.weld.jsf.WeldPhaseListener': javax.faces.FacesException: org.jboss.weld.jsf.WeldPhaseListener
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.osgijavaeebase.OSGiDeploymentRequest.deploy(OSGiDeploymentRequest.java:185)
... 12 more
]]

Scene2: putting the second attachment(dummy-web.war) into "autodeploy\bundles"

More exceptions happened in the server.log as following:

[2013-03-26T16:57:59.890+0900] [glassfish 4.0] [INFO] [] [org.glassfish.osgiejb] [tid: _ThreadID=84 _ThreadName=fileinstall-D:\20130125\glassfish9\glassfish4\glassfish\domains\domain1/autodeploy/bundles/] [timeMillis: 1364284679890] [levelValue: 800] [[
removedService: Found 0 no. of EJBs]]

[2013-03-26T16:57:59.906+0900] [glassfish 4.0] [INFO] [] [] [tid: _ThreadID=178 _ThreadName=Thread-3] [timeMillis: 1364284679906] [levelValue: 800] [[

    • BatchRuntimeHelper:: App Undeployed: null]]

[2013-03-26T16:57:59.921+0900] [glassfish 4.0] [INFO] [] [org.glassfish.osgijavaeebase] [tid: _ThreadID=84 _ThreadName=fileinstall-D:\20130125\glassfish9\glassfish4\glassfish\domains\domain1/autodeploy/bundles/] [timeMillis: 1364284679921] [levelValue: 800] [[
Deleted D:\20130125\glassfish9\glassfish4\glassfish\domains\domain1\osgi-cache\felix\bundle292\data\applications\bundle296-1364284644890]]

[2013-03-26T16:57:59.921+0900] [glassfish 4.0] [INFO] [] [org.glassfish.osgijavaeebase] [tid: _ThreadID=84 _ThreadName=fileinstall-D:\20130125\glassfish9\glassfish4\glassfish\domains\domain1/autodeploy/bundles/] [timeMillis: 1364284679921] [levelValue: 800] [[
Undeployed bundle org.glassfish.osgi.dummy-web [296]]]

[2013-03-26T16:58:00.406+0900] [glassfish 4.0] [INFO] [] [] [tid: _ThreadID=84 _ThreadName=Thread-3] [timeMillis: 1364284680406] [levelValue: 800] [[
Updated D:\20130125\glassfish9\glassfish4\glassfish\domains\domain1\autodeploy\bundles\dummy-web.war]]

[2013-03-26T16:58:00.406+0900] [glassfish 4.0] [INFO] [] [] [tid: _ThreadID=84 _ThreadName=Thread-3] [timeMillis: 1364284680406] [levelValue: 800] [[
Started bundle: file:/D:/20130125/glassfish9/glassfish4/glassfish/domains/domain1/autodeploy/bundles/dummy-web.war]]

[2013-03-26T16:58:00.781+0900] [glassfish 4.0] [INFO] [] [org.glassfish.osgijavaeebase] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284680781] [levelValue: 800] [[
Expanded at file:/D:/20130125/glassfish9/glassfish4/glassfish/domains/domain1/osgi-cache/felix/bundle292/data/applications/bundle296-1364284680250/]]

[2013-03-26T16:58:00.937+0900] [glassfish 4.0] [INFO] [] [org.glassfish.osgiweb] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284680937] [levelValue: 800] [[
uris = file:/D:/20130125/glassfish9/glassfish4/glassfish/domains/domain1/osgi-cache/felix/bundle292/data/applications/bundle296-1364284680250/WEB-INF/classes/, file:/D:/20130125/glassfish9/glassfish4/glassfish/domains/domain1/osgi-cache/felix/bundle292/data/applications/bundle296-1364284680250/WEB-INF/lib/Bundle296.jar, file:/D:/20130125/glassfish9/glassfish4/glassfish/domains/domain1/osgi-cache/felix/bundle292/data/applications/bundle296-1364284680250/WEB-INF/lib/primefaces-2.1.jar]]

[2013-03-26T16:58:01.625+0900] [glassfish 4.0] [INFO] [] [org.glassfish.osgiweb] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681625] [levelValue: 800] [[
total number of classes with faces annotation = 0]]

[2013-03-26T16:58:01.656+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681656] [levelValue: 900] [[
Unable to load class org.primefaces.component.captcha.CaptchaValidator, reason: java.lang.NoClassDefFoundError: javax/faces/validator/Validator]]

[2013-03-26T16:58:01.656+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681656] [levelValue: 900] [[
Unable to load class org.primefaces.touch.component.view.View, reason: java.lang.NoClassDefFoundError: javax/faces/component/UIComponentBase]]

[2013-03-26T16:58:01.656+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681656] [levelValue: 900] [[
Unable to load class org.primefaces.component.imageswitch.ImageSwitch, reason: java.lang.NoClassDefFoundError: javax/faces/component/UIComponentBase]]

[2013-03-26T16:58:01.656+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681656] [levelValue: 900] [[
Unable to load class org.primefaces.component.growl.Growl, reason: java.lang.NoClassDefFoundError: javax/faces/component/UIComponentBase]]

[2013-03-26T16:58:01.656+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681656] [levelValue: 900] [[
Unable to load class org.primefaces.component.column.Column, reason: java.lang.NoClassDefFoundError: javax/faces/component/UIColumn]]

[2013-03-26T16:58:01.656+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681656] [levelValue: 900] [[
Unable to load class org.primefaces.touch.component.inputswitch.InputSwitch, reason: java.lang.NoClassDefFoundError: javax/faces/component/UIInput]]

[2013-03-26T16:58:01.656+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681656] [levelValue: 900] [[
Unable to load class org.primefaces.component.slider.Slider, reason: java.lang.NoClassDefFoundError: javax/faces/component/UIOutput]]

[2013-03-26T16:58:01.656+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681656] [levelValue: 900] [[
Unable to load class org.primefaces.component.focus.Focus, reason: java.lang.NoClassDefFoundError: javax/faces/component/UIComponentBase]]

[2013-03-26T16:58:01.656+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681656] [levelValue: 900] [[
Unable to load class org.primefaces.component.graphictext.GraphicText, reason: java.lang.NoClassDefFoundError: javax/faces/component/html/HtmlGraphicImage]]

[2013-03-26T16:58:01.656+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681656] [levelValue: 900] [[
Unable to load class org.primefaces.component.dnd.Draggable, reason: java.lang.NoClassDefFoundError: javax/faces/component/UIComponentBase]]

[2013-03-26T16:58:01.656+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681656] [levelValue: 900] [[
Unable to load class org.primefaces.component.spreadsheet.Spreadsheet, reason: java.lang.NoClassDefFoundError: javax/faces/component/UIComponentBase]]

[2013-03-26T16:58:01.656+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681656] [levelValue: 900] [[
Unable to load class org.primefaces.component.chart.stackedcolumn.StackedColumnChart, reason: java.lang.NoClassDefFoundError: javax/faces/component/UIComponentBase]]

[2013-03-26T16:58:01.656+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681656] [levelValue: 900] [[
Unable to load class org.primefaces.component.layout.Layout, reason: java.lang.NoClassDefFoundError: javax/faces/component/UIPanel]]

[2013-03-26T16:58:01.671+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681671] [levelValue: 900] [[
Unable to load class org.primefaces.touch.component.application.Application, reason: java.lang.NoClassDefFoundError: javax/faces/component/UIComponentBase]]

[2013-03-26T16:58:01.671+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681671] [levelValue: 900] [[
Unable to load class org.primefaces.component.layout.LayoutUnit, reason: java.lang.NoClassDefFoundError: javax/faces/component/UIComponentBase]]

[2013-03-26T16:58:01.671+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681671] [levelValue: 900] [[
Unable to load class org.primefaces.component.idlemonitor.IdleMonitor, reason: java.lang.NoClassDefFoundError: javax/faces/component/UIComponentBase]]

[2013-03-26T16:58:01.671+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681671] [levelValue: 900] [[
Unable to load class org.primefaces.component.panel.Panel, reason: java.lang.NoClassDefFoundError: javax/faces/component/UIPanel]]

[2013-03-26T16:58:01.671+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681671] [levelValue: 900] [[
Unable to load class org.primefaces.component.fileupload.FileUpload, reason: java.lang.NoClassDefFoundError: javax/faces/component/UIComponentBase]]

[2013-03-26T16:58:01.671+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681671] [levelValue: 900] [[
Unable to load class org.primefaces.component.dnd.Droppable, reason: java.lang.NoClassDefFoundError: javax/faces/component/UIComponentBase]]

[2013-03-26T16:58:01.671+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681671] [levelValue: 900] [[
Unable to load class org.primefaces.component.resource.Resource, reason: java.lang.NoClassDefFoundError: javax/faces/component/UIComponentBase]]

[2013-03-26T16:58:01.671+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681671] [levelValue: 900] [[
Unable to load class org.primefaces.touch.component.rowitem.RowItem, reason: java.lang.NoClassDefFoundError: javax/faces/component/UICommand]]

[2013-03-26T16:58:01.671+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681671] [levelValue: 900] [[
Unable to load class org.primefaces.component.menu.Menu, reason: java.lang.NoClassDefFoundError: javax/faces/component/UIComponentBase]]

[2013-03-26T16:58:01.671+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681671] [levelValue: 900] [[
Unable to load class org.primefaces.component.messages.Messages, reason: java.lang.NoClassDefFoundError: javax/faces/component/UIComponentBase]]

[2013-03-26T16:58:01.671+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681671] [levelValue: 900] [[
Unable to load class org.primefaces.component.chart.series.ChartSeries, reason: java.lang.NoClassDefFoundError: javax/faces/component/UIOutput]]

[2013-03-26T16:58:01.671+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681671] [levelValue: 900] [[
Unable to load class org.primefaces.component.themeswitcher.ThemeSwitcher, reason: java.lang.NoClassDefFoundError: javax/faces/component/UIComponentBase]]

[2013-03-26T16:58:01.671+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681671] [levelValue: 900] [[
Unable to load class org.primefaces.component.chart.column.ColumnChart, reason: java.lang.NoClassDefFoundError: javax/faces/component/UIComponentBase]]

[2013-03-26T16:58:01.671+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681671] [levelValue: 900] [[
Unable to load class org.primefaces.component.tree.UITreeNode, reason: java.lang.NoClassDefFoundError: javax/faces/component/UIComponentBase]]

[2013-03-26T16:58:01.671+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681671] [levelValue: 900] [[
Unable to load class org.primefaces.component.linkbutton.LinkButton, reason: java.lang.NoClassDefFoundError: javax/faces/component/UIOutput]]

[2013-03-26T16:58:01.671+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681671] [levelValue: 900] [[
Unable to load class org.primefaces.touch.component.rowgroup.RowGroup, reason: java.lang.NoClassDefFoundError: javax/faces/component/UIComponentBase]]

[2013-03-26T16:58:01.671+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681671] [levelValue: 900] [[
Unable to load class org.primefaces.component.notificationbar.NotificationBar, reason: java.lang.NoClassDefFoundError: javax/faces/component/UIComponentBase]]

[2013-03-26T16:58:01.687+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681687] [levelValue: 900] [[
Unable to load class org.primefaces.component.inplace.Inplace, reason: java.lang.NoClassDefFoundError: javax/faces/component/UIComponentBase]]

[2013-03-26T16:58:01.687+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681687] [levelValue: 900] [[
Unable to load class org.primefaces.component.picklist.PickList, reason: java.lang.NoClassDefFoundError: javax/faces/component/UIInput]]

[2013-03-26T16:58:01.687+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681687] [levelValue: 900] [[
Unable to load class org.primefaces.component.tabview.TabView, reason: java.lang.NoClassDefFoundError: javax/faces/component/UIComponentBase]]

[2013-03-26T16:58:01.687+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681687] [levelValue: 900] [[
Unable to load class org.primefaces.touch.component.tableview.TableView, reason: java.lang.NoClassDefFoundError: javax/faces/component/UIComponentBase]]

[2013-03-26T16:58:01.687+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681687] [levelValue: 900] [[
Unable to load class org.primefaces.component.contextmenu.ContextMenu, reason: java.lang.NoClassDefFoundError: javax/faces/component/UIComponentBase]]

[2013-03-26T16:58:01.687+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681687] [levelValue: 900] [[
Unable to load class org.primefaces.component.confirmdialog.ConfirmDialog, reason: java.lang.NoClassDefFoundError: javax/faces/component/UIPanel]]

[2013-03-26T16:58:01.687+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681687] [levelValue: 900] [[
Unable to load class org.primefaces.component.commandbutton.CommandButton, reason: java.lang.NoClassDefFoundError: javax/faces/component/html/HtmlCommandButton]]

[2013-03-26T16:58:01.687+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681687] [levelValue: 900] [[
Unable to load class org.primefaces.component.menubutton.MenuButton, reason: java.lang.NoClassDefFoundError: javax/faces/component/UIComponentBase]]

[2013-03-26T16:58:01.687+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681687] [levelValue: 900] [[
Unable to load class org.primefaces.component.keyboard.Keyboard, reason: java.lang.NoClassDefFoundError: javax/faces/component/html/HtmlInputText]]

[2013-03-26T16:58:01.687+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681687] [levelValue: 900] [[
Unable to load class org.primefaces.component.rating.Rating, reason: java.lang.NoClassDefFoundError: javax/faces/component/UIInput]]

[2013-03-26T16:58:01.687+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681687] [levelValue: 900] [[
Unable to load class org.primefaces.component.progressbar.ProgressBar, reason: java.lang.NoClassDefFoundError: javax/faces/component/UIComponentBase]]

[2013-03-26T16:58:01.687+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681687] [levelValue: 900] [[
Unable to load class org.primefaces.component.schedule.Schedule, reason: java.lang.NoClassDefFoundError: javax/faces/component/UIComponentBase]]

[2013-03-26T16:58:01.687+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681687] [levelValue: 900] [[
Unable to load class org.primefaces.component.remotecommand.RemoteCommand, reason: java.lang.NoClassDefFoundError: javax/faces/component/UICommand]]

[2013-03-26T16:58:01.687+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681687] [levelValue: 900] [[
Unable to load class org.primefaces.component.breadcrumb.BreadCrumb, reason: java.lang.NoClassDefFoundError: javax/faces/component/UIComponentBase]]

[2013-03-26T16:58:01.687+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681687] [levelValue: 900] [[
Unable to load class org.primefaces.component.terminal.Terminal, reason: java.lang.NoClassDefFoundError: javax/faces/component/UIComponentBase]]

[2013-03-26T16:58:01.687+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681687] [levelValue: 900] [[
Unable to load class org.primefaces.component.schedule.ScheduleEventDialog, reason: java.lang.NoClassDefFoundError: javax/faces/component/UIPanel]]

[2013-03-26T16:58:01.687+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681687] [levelValue: 900] [[
Unable to load class org.primefaces.touch.component.navbarcontrol.NavBarControl, reason: java.lang.NoClassDefFoundError: javax/faces/component/UIComponentBase]]

[2013-03-26T16:58:01.687+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681687] [levelValue: 900] [[
Unable to load class org.primefaces.component.tabslider.TabSlider, reason: java.lang.NoClassDefFoundError: javax/faces/component/UIComponentBase]]

[2013-03-26T16:58:01.703+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681703] [levelValue: 900] [[
Unable to load class org.primefaces.component.poll.Poll, reason: java.lang.NoClassDefFoundError: javax/faces/component/UICommand]]

[2013-03-26T16:58:01.703+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681703] [levelValue: 900] [[
Unable to load class org.primefaces.component.imagecropper.ImageCropper, reason: java.lang.NoClassDefFoundError: javax/faces/component/UIInput]]

[2013-03-26T16:58:01.703+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681703] [levelValue: 900] [[
Unable to load class org.primefaces.component.chart.bar.BarChart, reason: java.lang.NoClassDefFoundError: javax/faces/component/UIComponentBase]]

[2013-03-26T16:58:01.703+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681703] [levelValue: 900] [[
Unable to load class org.primefaces.component.menuitem.MenuItem, reason: java.lang.NoClassDefFoundError: javax/faces/component/UICommand]]

[2013-03-26T16:58:01.703+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681703] [levelValue: 900] [[
Unable to load class org.primefaces.component.chart.stackedbar.StackedBarChart, reason: java.lang.NoClassDefFoundError: javax/faces/component/UIComponentBase]]

[2013-03-26T16:58:01.703+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681703] [levelValue: 900] [[
Unable to load class org.primefaces.component.resizable.Resizable, reason: java.lang.NoClassDefFoundError: javax/faces/component/UIComponentBase]]

[2013-03-26T16:58:01.703+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681703] [levelValue: 900] [[
Unable to load class org.primefaces.component.menubar.Menubar, reason: java.lang.NoClassDefFoundError: javax/faces/component/UIComponentBase]]

[2013-03-26T16:58:01.703+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681703] [levelValue: 900] [[
Unable to load class org.primefaces.component.chart.line.LineChart, reason: java.lang.NoClassDefFoundError: javax/faces/component/UIComponentBase]]

[2013-03-26T16:58:01.703+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681703] [levelValue: 900] [[
Unable to load class org.primefaces.component.inputmask.InputMask, reason: java.lang.NoClassDefFoundError: javax/faces/component/html/HtmlInputText]]

[2013-03-26T16:58:01.703+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681703] [levelValue: 900] [[
Unable to load class org.primefaces.component.uiajax.UIAjax, reason: java.lang.NoClassDefFoundError: javax/faces/component/UICommand]]

[2013-03-26T16:58:01.703+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681703] [levelValue: 900] [[
Unable to load class org.primefaces.component.autocomplete.AutoComplete, reason: java.lang.NoClassDefFoundError: javax/faces/component/UIInput]]

[2013-03-26T16:58:01.703+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681703] [levelValue: 900] [[
Unable to load class org.primefaces.component.accordionpanel.AccordionPanel, reason: java.lang.NoClassDefFoundError: javax/faces/component/UIPanel]]

[2013-03-26T16:58:01.718+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681718] [levelValue: 900] [[
Unable to load class org.primefaces.component.lightbox.LightBox, reason: java.lang.NoClassDefFoundError: javax/faces/component/UIComponentBase]]

[2013-03-26T16:58:01.718+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681718] [levelValue: 900] [[
Unable to load class org.primefaces.component.spinner.Spinner, reason: java.lang.NoClassDefFoundError: javax/faces/component/UIInput]]

[2013-03-26T16:58:01.718+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681718] [levelValue: 900] [[
Unable to load class org.primefaces.component.watermark.Watermark, reason: java.lang.NoClassDefFoundError: javax/faces/component/UIComponentBase]]

[2013-03-26T16:58:01.718+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681718] [levelValue: 900] [[
Unable to load class org.primefaces.component.datalist.DataList, reason: java.lang.NoClassDefFoundError: javax/faces/component/UIData]]

[2013-03-26T16:58:01.718+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681718] [levelValue: 900] [[
Unable to load class org.primefaces.component.chart.pie.PieChart, reason: java.lang.NoClassDefFoundError: javax/faces/component/UIComponentBase]]

[2013-03-26T16:58:01.718+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681718] [levelValue: 900] [[
Unable to load class org.primefaces.component.treetable.TreeTable, reason: java.lang.NoClassDefFoundError: javax/faces/component/UIData]]

[2013-03-26T16:58:01.718+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681718] [levelValue: 900] [[
Unable to load class org.primefaces.component.ajaxstatus.AjaxStatus, reason: java.lang.NoClassDefFoundError: javax/faces/component/UIComponentBase]]

[2013-03-26T16:58:01.718+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681718] [levelValue: 900] [[
Unable to load class org.primefaces.component.captcha.Captcha, reason: java.lang.NoClassDefFoundError: javax/faces/component/UIInput]]

[2013-03-26T16:58:01.718+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681718] [levelValue: 900] [[
Unable to load class org.primefaces.component.commandlink.CommandLink, reason: java.lang.NoClassDefFoundError: javax/faces/component/html/HtmlCommandLink]]

[2013-03-26T16:58:01.718+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681718] [levelValue: 900] [[
Unable to load class org.primefaces.component.dashboard.Dashboard, reason: java.lang.NoClassDefFoundError: javax/faces/component/UIPanel]]

[2013-03-26T16:58:01.718+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681718] [levelValue: 900] [[
Unable to load class org.primefaces.component.gmap.GMapInfoWindow, reason: java.lang.NoClassDefFoundError: javax/faces/component/UIComponentBase]]

[2013-03-26T16:58:01.718+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681718] [levelValue: 900] [[
Unable to load class org.primefaces.component.stack.Stack, reason: java.lang.NoClassDefFoundError: javax/faces/component/UIComponentBase]]

[2013-03-26T16:58:01.718+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681718] [levelValue: 900] [[
Unable to load class org.primefaces.component.outputpanel.OutputPanel, reason: java.lang.NoClassDefFoundError: javax/faces/component/UIPanel]]

[2013-03-26T16:58:01.734+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681734] [levelValue: 900] [[
Unable to load class org.primefaces.component.dock.Dock, reason: java.lang.NoClassDefFoundError: javax/faces/component/UIComponentBase]]

[2013-03-26T16:58:01.734+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681734] [levelValue: 900] [[
Unable to load class org.primefaces.component.effect.Effect, reason: java.lang.NoClassDefFoundError: javax/faces/component/UIComponentBase]]

[2013-03-26T16:58:01.734+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681734] [levelValue: 900] [[
Unable to load class org.primefaces.component.datagrid.DataGrid, reason: java.lang.NoClassDefFoundError: javax/faces/component/UIData]]

[2013-03-26T16:58:01.734+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681734] [levelValue: 900] [[
Unable to load class org.primefaces.component.tabview.Tab, reason: java.lang.NoClassDefFoundError: javax/faces/component/UIComponentBase]]

[2013-03-26T16:58:01.734+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681734] [levelValue: 900] [[
Unable to load class org.primefaces.component.carousel.Carousel, reason: java.lang.NoClassDefFoundError: javax/faces/component/UIData]]

[2013-03-26T16:58:01.734+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681734] [levelValue: 900] [[
Unable to load class org.primefaces.component.editor.Editor, reason: java.lang.NoClassDefFoundError: javax/faces/component/UIInput]]

[2013-03-26T16:58:01.734+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681734] [levelValue: 900] [[
Unable to load class org.primefaces.component.calendar.Calendar, reason: java.lang.NoClassDefFoundError: javax/faces/component/UIInput]]

[2013-03-26T16:58:01.734+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681734] [levelValue: 900] [[
Unable to load class org.primefaces.component.password.Password, reason: java.lang.NoClassDefFoundError: javax/faces/component/html/HtmlInputText]]

[2013-03-26T16:58:01.734+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681734] [levelValue: 900] [[
Unable to load class org.primefaces.component.dialog.Dialog, reason: java.lang.NoClassDefFoundError: javax/faces/component/UIPanel]]

[2013-03-26T16:58:01.734+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681734] [levelValue: 900] [[
Unable to load class org.primefaces.component.resources.Resources, reason: java.lang.NoClassDefFoundError: javax/faces/component/UIComponentBase]]

[2013-03-26T16:58:01.734+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681734] [levelValue: 900] [[
Unable to load class org.primefaces.component.push.Push, reason: java.lang.NoClassDefFoundError: javax/faces/component/UIComponentBase]]

[2013-03-26T16:58:01.734+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681734] [levelValue: 900] [[
Unable to load class org.primefaces.component.wizard.Wizard, reason: java.lang.NoClassDefFoundError: javax/faces/component/NamingContainer]]

[2013-03-26T16:58:01.734+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681734] [levelValue: 900] [[
Unable to load class org.primefaces.component.message.Message, reason: java.lang.NoClassDefFoundError: javax/faces/component/UIComponentBase]]

[2013-03-26T16:58:01.734+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681734] [levelValue: 900] [[
Unable to load class org.primefaces.component.media.Media, reason: java.lang.NoClassDefFoundError: javax/faces/component/UIComponentBase]]

[2013-03-26T16:58:01.734+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681734] [levelValue: 900] [[
Unable to load class org.primefaces.component.graphicimage.GraphicImage, reason: java.lang.NoClassDefFoundError: javax/faces/component/html/HtmlGraphicImage]]

[2013-03-26T16:58:01.750+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681750] [levelValue: 900] [[
Unable to load class org.primefaces.component.tree.Tree, reason: java.lang.NoClassDefFoundError: javax/faces/component/UIComponentBase]]

[2013-03-26T16:58:01.750+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681750] [levelValue: 900] [[
Unable to load class org.primefaces.component.tooltip.Tooltip, reason: java.lang.NoClassDefFoundError: javax/faces/component/UIOutput]]

[2013-03-26T16:58:01.750+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681750] [levelValue: 900] [[
Unable to load class org.primefaces.component.colorpicker.ColorPicker, reason: java.lang.NoClassDefFoundError: javax/faces/component/UIInput]]

[2013-03-26T16:58:01.750+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681750] [levelValue: 900] [[
Unable to load class org.primefaces.component.hotkey.Hotkey, reason: java.lang.NoClassDefFoundError: javax/faces/component/UICommand]]

[2013-03-26T16:58:01.750+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681750] [levelValue: 900] [[
Unable to load class org.primefaces.component.datatable.DataTable, reason: java.lang.NoClassDefFoundError: javax/faces/component/UIData]]

[2013-03-26T16:58:01.750+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681750] [levelValue: 900] [[
Unable to load class org.primefaces.component.gmap.GMap, reason: java.lang.NoClassDefFoundError: javax/faces/component/UIComponentBase]]

[2013-03-26T16:58:01.750+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681750] [levelValue: 900] [[
Unable to load class org.primefaces.component.printer.Printer, reason: java.lang.NoClassDefFoundError: javax/faces/component/UIComponentBase]]

[2013-03-26T16:58:01.750+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681750] [levelValue: 900] [[
Unable to load class org.primefaces.component.submenu.Submenu, reason: java.lang.NoClassDefFoundError: javax/faces/component/UIComponentBase]]

[2013-03-26T16:58:01.750+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681750] [levelValue: 900] [[
Unable to load class org.primefaces.component.spreadsheet.Sheet, reason: java.lang.NoClassDefFoundError: javax/faces/component/UIData]]

[2013-03-26T16:58:01.750+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681750] [levelValue: 900] [[
Unable to load class org.primefaces.component.imagecompare.ImageCompare, reason: java.lang.NoClassDefFoundError: javax/faces/component/UIComponentBase]]

[2013-03-26T16:58:01.765+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681765] [levelValue: 900] [[
Unable to load class org.primefaces.renderkit.CoreRenderer, reason: java.lang.NoClassDefFoundError: javax/faces/render/Renderer]]

[2013-03-26T16:58:01.765+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681765] [levelValue: 900] [[
Unable to load class org.primefaces.renderkit.HeadRenderer, reason: java.lang.NoClassDefFoundError: javax/faces/render/Renderer]]

[2013-03-26T16:58:01.765+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681765] [levelValue: 900] [[
Unable to load class org.primefaces.component.accordionpanel.AccordionPanelRenderer, reason: java.lang.NoClassDefFoundError: javax/faces/render/Renderer]]

[2013-03-26T16:58:01.765+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681765] [levelValue: 900] [[
Unable to load class org.primefaces.component.ajaxstatus.AjaxStatusRenderer, reason: java.lang.NoClassDefFoundError: javax/faces/render/Renderer]]

[2013-03-26T16:58:01.765+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681765] [levelValue: 900] [[
Unable to load class org.primefaces.component.autocomplete.AutoCompleteRenderer, reason: java.lang.NoClassDefFoundError: javax/faces/render/Renderer]]

[2013-03-26T16:58:01.765+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681765] [levelValue: 900] [[
Unable to load class org.primefaces.component.breadcrumb.BreadCrumbRenderer, reason: java.lang.NoClassDefFoundError: javax/faces/render/Renderer]]

[2013-03-26T16:58:01.765+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681765] [levelValue: 900] [[
Unable to load class org.primefaces.component.calendar.CalendarRenderer, reason: java.lang.NoClassDefFoundError: javax/faces/render/Renderer]]

[2013-03-26T16:58:01.765+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681765] [levelValue: 900] [[
Unable to load class org.primefaces.component.captcha.CaptchaRenderer, reason: java.lang.NoClassDefFoundError: javax/faces/render/Renderer]]

[2013-03-26T16:58:01.765+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681765] [levelValue: 900] [[
Unable to load class org.primefaces.component.carousel.CarouselRenderer, reason: java.lang.NoClassDefFoundError: javax/faces/render/Renderer]]

[2013-03-26T16:58:01.765+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681765] [levelValue: 900] [[
Unable to load class org.primefaces.component.chart.BaseChartRenderer, reason: java.lang.NoClassDefFoundError: javax/faces/render/Renderer]]

[2013-03-26T16:58:01.765+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681765] [levelValue: 900] [[
Unable to load class org.primefaces.component.colorpicker.ColorPickerRenderer, reason: java.lang.NoClassDefFoundError: javax/faces/render/Renderer]]

[2013-03-26T16:58:01.765+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681765] [levelValue: 900] [[
Unable to load class org.primefaces.component.commandbutton.CommandButtonRenderer, reason: java.lang.NoClassDefFoundError: javax/faces/render/Renderer]]

[2013-03-26T16:58:01.765+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681765] [levelValue: 900] [[
Unable to load class org.primefaces.component.commandlink.CommandLinkRenderer, reason: java.lang.NoClassDefFoundError: javax/faces/render/Renderer]]

[2013-03-26T16:58:01.781+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681781] [levelValue: 900] [[
Unable to load class org.primefaces.component.confirmdialog.ConfirmDialogRenderer, reason: java.lang.NoClassDefFoundError: javax/faces/render/Renderer]]

[2013-03-26T16:58:01.781+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681781] [levelValue: 900] [[
Unable to load class org.primefaces.component.contextmenu.ContextMenuRenderer, reason: java.lang.NoClassDefFoundError: javax/faces/render/Renderer]]

[2013-03-26T16:58:01.781+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681781] [levelValue: 900] [[
Unable to load class org.primefaces.component.dashboard.DashboardRenderer, reason: java.lang.NoClassDefFoundError: javax/faces/render/Renderer]]

[2013-03-26T16:58:01.781+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681781] [levelValue: 900] [[
Unable to load class org.primefaces.component.datagrid.DataGridRenderer, reason: java.lang.NoClassDefFoundError: javax/faces/render/Renderer]]

[2013-03-26T16:58:01.781+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681781] [levelValue: 900] [[
Unable to load class org.primefaces.component.datalist.DataListRenderer, reason: java.lang.NoClassDefFoundError: javax/faces/render/Renderer]]

[2013-03-26T16:58:01.781+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681781] [levelValue: 900] [[
Unable to load class org.primefaces.component.datatable.DataTableRenderer, reason: java.lang.NoClassDefFoundError: javax/faces/render/Renderer]]

[2013-03-26T16:58:01.781+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681781] [levelValue: 900] [[
Unable to load class org.primefaces.component.dialog.DialogRenderer, reason: java.lang.NoClassDefFoundError: javax/faces/render/Renderer]]

[2013-03-26T16:58:01.781+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681781] [levelValue: 900] [[
Unable to load class org.primefaces.component.dnd.DraggableRenderer, reason: java.lang.NoClassDefFoundError: javax/faces/render/Renderer]]

[2013-03-26T16:58:01.781+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681781] [levelValue: 900] [[
Unable to load class org.primefaces.component.dnd.DroppableRenderer, reason: java.lang.NoClassDefFoundError: javax/faces/render/Renderer]]

[2013-03-26T16:58:01.781+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681781] [levelValue: 900] [[
Unable to load class org.primefaces.component.dock.DockRenderer, reason: java.lang.NoClassDefFoundError: javax/faces/render/Renderer]]

[2013-03-26T16:58:01.781+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681781] [levelValue: 900] [[
Unable to load class org.primefaces.component.editor.EditorRenderer, reason: java.lang.NoClassDefFoundError: javax/faces/render/Renderer]]

[2013-03-26T16:58:01.781+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681781] [levelValue: 900] [[
Unable to load class org.primefaces.component.effect.EffectRenderer, reason: java.lang.NoClassDefFoundError: javax/faces/render/Renderer]]

[2013-03-26T16:58:01.796+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681796] [levelValue: 900] [[
Unable to load class org.primefaces.component.fileupload.FileUploadRenderer, reason: java.lang.NoClassDefFoundError: javax/faces/render/Renderer]]

[2013-03-26T16:58:01.796+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681796] [levelValue: 900] [[
Unable to load class org.primefaces.component.focus.FocusRenderer, reason: java.lang.NoClassDefFoundError: javax/faces/render/Renderer]]

[2013-03-26T16:58:01.796+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681796] [levelValue: 900] [[
Unable to load class org.primefaces.component.gmap.GMapRenderer, reason: java.lang.NoClassDefFoundError: javax/faces/render/Renderer]]

[2013-03-26T16:58:01.796+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681796] [levelValue: 900] [[
Unable to load class org.primefaces.component.graphicimage.GraphicImageRenderer, reason: java.lang.NoClassDefFoundError: javax/faces/render/Renderer]]

[2013-03-26T16:58:01.812+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681812] [levelValue: 900] [[
Unable to load class org.primefaces.component.graphictext.GraphicTextRenderer, reason: java.lang.NoClassDefFoundError: javax/faces/render/Renderer]]

[2013-03-26T16:58:01.812+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681812] [levelValue: 900] [[
Unable to load class org.primefaces.component.growl.GrowlRenderer, reason: java.lang.NoClassDefFoundError: javax/faces/render/Renderer]]

[2013-03-26T16:58:01.812+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681812] [levelValue: 900] [[
Unable to load class org.primefaces.component.hotkey.HotkeyRenderer, reason: java.lang.NoClassDefFoundError: javax/faces/render/Renderer]]

[2013-03-26T16:58:01.812+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681812] [levelValue: 900] [[
Unable to load class org.primefaces.component.idlemonitor.IdleMonitorRenderer, reason: java.lang.NoClassDefFoundError: javax/faces/render/Renderer]]

[2013-03-26T16:58:01.812+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681812] [levelValue: 900] [[
Unable to load class org.primefaces.component.imagecompare.ImageCompareRenderer, reason: java.lang.NoClassDefFoundError: javax/faces/render/Renderer]]

[2013-03-26T16:58:01.812+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681812] [levelValue: 900] [[
Unable to load class org.primefaces.component.imagecropper.ImageCropperRenderer, reason: java.lang.NoClassDefFoundError: javax/faces/render/Renderer]]

[2013-03-26T16:58:01.812+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681812] [levelValue: 900] [[
Unable to load class org.primefaces.component.imageswitch.ImageSwitchRenderer, reason: java.lang.NoClassDefFoundError: javax/faces/render/Renderer]]

[2013-03-26T16:58:01.812+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681812] [levelValue: 900] [[
Unable to load class org.primefaces.component.inplace.InplaceRenderer, reason: java.lang.NoClassDefFoundError: javax/faces/render/Renderer]]

[2013-03-26T16:58:01.812+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681812] [levelValue: 900] [[
Unable to load class org.primefaces.component.inputmask.InputMaskRenderer, reason: java.lang.NoClassDefFoundError: javax/faces/render/Renderer]]

[2013-03-26T16:58:01.812+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681812] [levelValue: 900] [[
Unable to load class org.primefaces.component.keyboard.KeyboardRenderer, reason: java.lang.NoClassDefFoundError: javax/faces/render/Renderer]]

[2013-03-26T16:58:01.812+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681812] [levelValue: 900] [[
Unable to load class org.primefaces.component.layout.LayoutRenderer, reason: java.lang.NoClassDefFoundError: javax/faces/render/Renderer]]

[2013-03-26T16:58:01.812+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681812] [levelValue: 900] [[
Unable to load class org.primefaces.component.layout.LayoutUnitRenderer, reason: java.lang.NoClassDefFoundError: javax/faces/render/Renderer]]

[2013-03-26T16:58:01.812+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681812] [levelValue: 900] [[
Unable to load class org.primefaces.component.lightbox.LightBoxRenderer, reason: java.lang.NoClassDefFoundError: javax/faces/render/Renderer]]

[2013-03-26T16:58:01.828+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681828] [levelValue: 900] [[
Unable to load class org.primefaces.component.linkbutton.LinkButtonRenderer, reason: java.lang.NoClassDefFoundError: javax/faces/render/Renderer]]

[2013-03-26T16:58:01.828+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681828] [levelValue: 900] [[
Unable to load class org.primefaces.component.media.MediaRenderer, reason: java.lang.NoClassDefFoundError: javax/faces/render/Renderer]]

[2013-03-26T16:58:01.828+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681828] [levelValue: 900] [[
Unable to load class org.primefaces.component.menu.MenuRenderer, reason: java.lang.NoClassDefFoundError: javax/faces/render/Renderer]]

[2013-03-26T16:58:01.828+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681828] [levelValue: 900] [[
Unable to load class org.primefaces.component.menubar.MenubarRenderer, reason: java.lang.NoClassDefFoundError: javax/faces/render/Renderer]]

[2013-03-26T16:58:01.828+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681828] [levelValue: 900] [[
Unable to load class org.primefaces.component.menubutton.MenuButtonRenderer, reason: java.lang.NoClassDefFoundError: javax/faces/render/Renderer]]

[2013-03-26T16:58:01.828+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681828] [levelValue: 900] [[
Unable to load class org.primefaces.component.message.MessageRenderer, reason: java.lang.NoClassDefFoundError: javax/faces/render/Renderer]]

[2013-03-26T16:58:01.828+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681828] [levelValue: 900] [[
Unable to load class org.primefaces.component.messages.MessagesRenderer, reason: java.lang.NoClassDefFoundError: javax/faces/render/Renderer]]

[2013-03-26T16:58:01.828+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681828] [levelValue: 900] [[
Unable to load class org.primefaces.component.notificationbar.NotificationBarRenderer, reason: java.lang.NoClassDefFoundError: javax/faces/render/Renderer]]

[2013-03-26T16:58:01.828+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681828] [levelValue: 900] [[
Unable to load class org.primefaces.component.outputpanel.OutputPanelRenderer, reason: java.lang.NoClassDefFoundError: javax/faces/render/Renderer]]

[2013-03-26T16:58:01.828+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681828] [levelValue: 900] [[
Unable to load class org.primefaces.component.panel.PanelRenderer, reason: java.lang.NoClassDefFoundError: javax/faces/render/Renderer]]

[2013-03-26T16:58:01.828+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681828] [levelValue: 900] [[
Unable to load class org.primefaces.component.password.PasswordRenderer, reason: java.lang.NoClassDefFoundError: javax/faces/render/Renderer]]

[2013-03-26T16:58:01.843+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681843] [levelValue: 900] [[
Unable to load class org.primefaces.component.picklist.PickListRenderer, reason: java.lang.NoClassDefFoundError: javax/faces/render/Renderer]]

[2013-03-26T16:58:01.843+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681843] [levelValue: 900] [[
Unable to load class org.primefaces.component.poll.PollRenderer, reason: java.lang.NoClassDefFoundError: javax/faces/render/Renderer]]

[2013-03-26T16:58:01.843+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681843] [levelValue: 900] [[
Unable to load class org.primefaces.component.printer.PrinterRenderer, reason: java.lang.NoClassDefFoundError: javax/faces/render/Renderer]]

[2013-03-26T16:58:01.843+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681843] [levelValue: 900] [[
Unable to load class org.primefaces.component.progressbar.ProgressBarRenderer, reason: java.lang.NoClassDefFoundError: javax/faces/render/Renderer]]

[2013-03-26T16:58:01.843+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681843] [levelValue: 900] [[
Unable to load class org.primefaces.component.push.PushRenderer, reason: java.lang.NoClassDefFoundError: javax/faces/render/Renderer]]

[2013-03-26T16:58:01.843+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681843] [levelValue: 900] [[
Unable to load class org.primefaces.component.rating.RatingRenderer, reason: java.lang.NoClassDefFoundError: javax/faces/render/Renderer]]

[2013-03-26T16:58:01.843+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681843] [levelValue: 900] [[
Unable to load class org.primefaces.component.remotecommand.RemoteCommandRenderer, reason: java.lang.NoClassDefFoundError: javax/faces/render/Renderer]]

[2013-03-26T16:58:01.843+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681843] [levelValue: 900] [[
Unable to load class org.primefaces.component.resizable.ResizableRenderer, reason: java.lang.NoClassDefFoundError: javax/faces/render/Renderer]]

[2013-03-26T16:58:01.843+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681843] [levelValue: 900] [[
Unable to load class org.primefaces.component.resource.ResourceRenderer, reason: java.lang.NoClassDefFoundError: javax/faces/render/Renderer]]

[2013-03-26T16:58:01.843+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681843] [levelValue: 900] [[
Unable to load class org.primefaces.component.resources.ResourcesRenderer, reason: java.lang.NoClassDefFoundError: javax/faces/render/Renderer]]

[2013-03-26T16:58:01.843+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681843] [levelValue: 900] [[
Unable to load class org.primefaces.component.schedule.ScheduleEventDialogRenderer, reason: java.lang.NoClassDefFoundError: javax/faces/render/Renderer]]

[2013-03-26T16:58:01.843+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681843] [levelValue: 900] [[
Unable to load class org.primefaces.component.schedule.ScheduleRenderer, reason: java.lang.NoClassDefFoundError: javax/faces/render/Renderer]]

[2013-03-26T16:58:01.843+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681843] [levelValue: 900] [[
Unable to load class org.primefaces.component.slider.SliderRenderer, reason: java.lang.NoClassDefFoundError: javax/faces/render/Renderer]]

[2013-03-26T16:58:01.859+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681859] [levelValue: 900] [[
Unable to load class org.primefaces.component.spinner.SpinnerRenderer, reason: java.lang.NoClassDefFoundError: javax/faces/render/Renderer]]

[2013-03-26T16:58:01.859+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681859] [levelValue: 900] [[
Unable to load class org.primefaces.component.spreadsheet.SpreadsheetRenderer, reason: java.lang.NoClassDefFoundError: javax/faces/render/Renderer]]

[2013-03-26T16:58:01.859+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681859] [levelValue: 900] [[
Unable to load class org.primefaces.component.stack.StackRenderer, reason: java.lang.NoClassDefFoundError: javax/faces/render/Renderer]]

[2013-03-26T16:58:01.859+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681859] [levelValue: 900] [[
Unable to load class org.primefaces.component.tabslider.TabSliderRenderer, reason: java.lang.NoClassDefFoundError: javax/faces/render/Renderer]]

[2013-03-26T16:58:01.859+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681859] [levelValue: 900] [[
Unable to load class org.primefaces.component.tabview.TabViewRenderer, reason: java.lang.NoClassDefFoundError: javax/faces/render/Renderer]]

[2013-03-26T16:58:01.859+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681859] [levelValue: 900] [[
Unable to load class org.primefaces.component.terminal.TerminalRenderer, reason: java.lang.NoClassDefFoundError: javax/faces/render/Renderer]]

[2013-03-26T16:58:01.859+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681859] [levelValue: 900] [[
Unable to load class org.primefaces.component.themeswitcher.ThemeSwitcherRenderer, reason: java.lang.NoClassDefFoundError: javax/faces/render/Renderer]]

[2013-03-26T16:58:01.859+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681859] [levelValue: 900] [[
Unable to load class org.primefaces.component.tooltip.TooltipRenderer, reason: java.lang.NoClassDefFoundError: javax/faces/render/Renderer]]

[2013-03-26T16:58:01.859+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681859] [levelValue: 900] [[
Unable to load class org.primefaces.component.tree.TreeRenderer, reason: java.lang.NoClassDefFoundError: javax/faces/render/Renderer]]

[2013-03-26T16:58:01.859+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681859] [levelValue: 900] [[
Unable to load class org.primefaces.component.treetable.TreeTableRenderer, reason: java.lang.NoClassDefFoundError: javax/faces/render/Renderer]]

[2013-03-26T16:58:01.859+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681859] [levelValue: 900] [[
Unable to load class org.primefaces.component.uiajax.UIAjaxRenderer, reason: java.lang.NoClassDefFoundError: javax/faces/render/Renderer]]

[2013-03-26T16:58:01.859+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681859] [levelValue: 900] [[
Unable to load class org.primefaces.component.watermark.WatermarkRenderer, reason: java.lang.NoClassDefFoundError: javax/faces/render/Renderer]]

[2013-03-26T16:58:01.859+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681859] [levelValue: 900] [[
Unable to load class org.primefaces.component.wizard.WizardRenderer, reason: java.lang.NoClassDefFoundError: javax/faces/render/Renderer]]

[2013-03-26T16:58:01.875+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681875] [levelValue: 900] [[
Unable to load class org.primefaces.touch.component.application.ApplicationRenderer, reason: java.lang.NoClassDefFoundError: javax/faces/render/Renderer]]

[2013-03-26T16:58:01.875+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681875] [levelValue: 900] [[
Unable to load class org.primefaces.touch.component.inputswitch.InputSwitchRenderer, reason: java.lang.NoClassDefFoundError: javax/faces/render/Renderer]]

[2013-03-26T16:58:01.875+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681875] [levelValue: 900] [[
Unable to load class org.primefaces.touch.component.rowgroup.RowGroupRenderer, reason: java.lang.NoClassDefFoundError: javax/faces/render/Renderer]]

[2013-03-26T16:58:01.875+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681875] [levelValue: 900] [[
Unable to load class org.primefaces.touch.component.rowitem.RowItemRenderer, reason: java.lang.NoClassDefFoundError: javax/faces/render/Renderer]]

[2013-03-26T16:58:01.875+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681875] [levelValue: 900] [[
Unable to load class org.primefaces.touch.component.tableview.TableViewRenderer, reason: java.lang.NoClassDefFoundError: javax/faces/render/Renderer]]

[2013-03-26T16:58:01.875+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681875] [levelValue: 900] [[
Unable to load class org.primefaces.touch.component.view.ViewRenderer, reason: java.lang.NoClassDefFoundError: javax/faces/render/Renderer]]

[2013-03-26T16:58:01.875+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681875] [levelValue: 900] [[
Unable to load class org.primefaces.component.chart.bar.BarChartRenderer, reason: java.lang.NoClassDefFoundError: javax/faces/render/Renderer]]

[2013-03-26T16:58:01.875+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681875] [levelValue: 900] [[
Unable to load class org.primefaces.component.chart.column.ColumnChartRenderer, reason: java.lang.NoClassDefFoundError: javax/faces/render/Renderer]]

[2013-03-26T16:58:01.875+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681875] [levelValue: 900] [[
Unable to load class org.primefaces.component.chart.line.LineChartRenderer, reason: java.lang.NoClassDefFoundError: javax/faces/render/Renderer]]

[2013-03-26T16:58:01.875+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681875] [levelValue: 900] [[
Unable to load class org.primefaces.component.chart.pie.PieChartRenderer, reason: java.lang.NoClassDefFoundError: javax/faces/render/Renderer]]

[2013-03-26T16:58:01.890+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681890] [levelValue: 900] [[
Unable to load class org.primefaces.component.chart.stackedbar.StackedBarChartRenderer, reason: java.lang.NoClassDefFoundError: javax/faces/render/Renderer]]

[2013-03-26T16:58:01.890+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681890] [levelValue: 900] [[
Unable to load class org.primefaces.component.chart.stackedcolumn.StackedColumnChartRenderer, reason: java.lang.NoClassDefFoundError: javax/faces/render/Renderer]]

[2013-03-26T16:58:01.953+0900] [glassfish 4.0] [INFO] [jsf.config.listener.version] [javax.enterprise.resource.webcontainer.jsf.config] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681953] [levelValue: 800] [[
コンテキスト '/dummy-web' の Mojarra 2.2.0-m12 (-SNAPSHOT 20130320-0201 https://svn.java.net/svn/mojarra~svn/tags/2.2.0-m12@11773) を初期化します]]

[2013-03-26T16:58:01.953+0900] [glassfish 4.0] [INFO] [] [org.glassfish.osgiweb] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681953] [levelValue: 800] [[
Faces Config uris excluding the ones named as faces-config.xml = [bundle://296.1:0/META-INF/weld.faces-config.xml]]]

[2013-03-26T16:58:02.140+0900] [glassfish 4.0] [SEVERE] [] [javax.enterprise.resource.webcontainer.jsf.config] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284682140] [levelValue: 1000] [[
Critical error during deployment:
com.sun.faces.config.ConfigurationException: Factory 'javax.faces.context.ExternalContextFactory' was not configured properly.
at com.sun.faces.config.processor.FactoryConfigProcessor.verifyFactoriesExist(FactoryConfigProcessor.java:330)
at com.sun.faces.config.processor.FactoryConfigProcessor.process(FactoryConfigProcessor.java:236)
at com.sun.faces.config.ConfigManager.initialize(ConfigManager.java:424)
at com.sun.faces.config.ConfigureListener.contextInitialized(ConfigureListener.java:214)
at org.apache.catalina.core.StandardContext.contextListenerStart(StandardContext.java:5362)
at com.sun.enterprise.web.WebModule.contextListenerStart(WebModule.java:743)
at org.apache.catalina.core.StandardContext.start(StandardContext.java:5898)
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:2279)
at com.sun.enterprise.web.WebContainer.loadWebModule(WebContainer.java:1925)
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.osgijavaeebase.OSGiDeploymentRequest.deploy(OSGiDeploymentRequest.java:185)
at org.glassfish.osgijavaeebase.OSGiDeploymentRequest.execute(OSGiDeploymentRequest.java:120)
at org.glassfish.osgijavaeebase.AbstractOSGiDeployer.deploy(AbstractOSGiDeployer.java:123)
at org.glassfish.osgijavaeebase.OSGiContainer.deploy(OSGiContainer.java:154)
at org.glassfish.osgijavaeebase.JavaEEExtender.deploy(JavaEEExtender.java:109)
at org.glassfish.osgijavaeebase.JavaEEExtender.access$200(JavaEEExtender.java:61)
at org.glassfish.osgijavaeebase.JavaEEExtender$HybridBundleTrackerCustomizer$1.call(JavaEEExtender.java:153)
at org.glassfish.osgijavaeebase.JavaEEExtender$HybridBundleTrackerCustomizer$1.call(JavaEEExtender.java:150)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
at java.util.concurrent.FutureTask.run(FutureTask.java:166)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
at java.lang.Thread.run(Thread.java:722)
Caused by: javax.faces.FacesException: org.primefaces.context.PrimeExternalContextFactory
at javax.faces.FactoryFinder.getImplGivenPreviousImpl(FactoryFinder.java:710)
at javax.faces.FactoryFinder.getImplementationInstance(FactoryFinder.java:572)
at javax.faces.FactoryFinder.access$500(FactoryFinder.java:140)
at javax.faces.FactoryFinder$FactoryManager.getFactory(FactoryFinder.java:1120)
at javax.faces.FactoryFinder.getFactory(FactoryFinder.java:379)
at com.sun.faces.config.processor.FactoryConfigProcessor.verifyFactoriesExist(FactoryConfigProcessor.java:328)
... 31 more
Caused by: org.jboss.weld.exceptions.IllegalArgumentException: Exception message for key UNABLE_TO_FIND_CONSTRUCTOR not found due to String index out of range: -1
at org.jboss.weld.manager.InjectionTargetFactoryImpl.createInjectionTarget(InjectionTargetFactoryImpl.java:69)
at org.jboss.weld.manager.BeanManagerImpl.createInjectionTarget(BeanManagerImpl.java:1039)
at org.glassfish.weld.services.JCDIServiceImpl.injectManagedObject(JCDIServiceImpl.java:286)
at org.glassfish.faces.integration.GlassFishInjectionProvider.inject(GlassFishInjectionProvider.java:189)
at javax.faces.FactoryFinder.getImplGivenPreviousImpl(FactoryFinder.java:695)
... 36 more
Caused by: org.jboss.weld.exceptions.DefinitionException: Exception message for key UNABLE_TO_FIND_CONSTRUCTOR not found due to String index out of range: -1
at org.jboss.weld.util.Beans.getBeanConstructor(Beans.java:327)
at org.jboss.weld.injection.InjectionPointFactory.createConstructorInjectionPoint(InjectionPointFactory.java:161)
at org.jboss.weld.injection.producer.DefaultInstantiator.<init>(DefaultInstantiator.java:59)
at org.jboss.weld.injection.producer.BasicInjectionTarget.initInstantiator(BasicInjectionTarget.java:153)
at org.jboss.weld.injection.producer.BasicInjectionTarget.<init>(BasicInjectionTarget.java:70)
at org.jboss.weld.injection.producer.BeanInjectionTarget.<init>(BeanInjectionTarget.java:44)
at org.jboss.weld.manager.InjectionTargetFactoryImpl.createInjectionTarget(InjectionTargetFactoryImpl.java:80)
at org.jboss.weld.manager.InjectionTargetFactoryImpl.createInjectionTarget(InjectionTargetFactoryImpl.java:65)
... 40 more
]]

[2013-03-26T16:58:02.140+0900] [glassfish 4.0] [SEVERE] [AS-WEB-CORE-00174] [javax.enterprise.web.core] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284682140] [levelValue: 1000] [[
Startup of context /dummy-web failed due to previous errors]]

[2013-03-26T16:58:02.140+0900] [glassfish 4.0] [SEVERE] [AS-WEB-CORE-00175] [javax.enterprise.web.core] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284682140] [levelValue: 1000] [[
Exception during cleanup after start failed
org.apache.catalina.LifecycleException: Manager has not yet been started
at org.apache.catalina.session.StandardManager.stop(StandardManager.java:934)
at org.apache.catalina.core.StandardContext.stop(StandardContext.java:6099)
at com.sun.enterprise.web.WebModule.stop(WebModule.java:720)
at org.apache.catalina.core.StandardContext.start(StandardContext.java:5916)
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:2279)
at com.sun.enterprise.web.WebContainer.loadWebModule(WebContainer.java:1925)
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.osgijavaeebase.OSGiDeploymentRequest.deploy(OSGiDeploymentRequest.java:185)
at org.glassfish.osgijavaeebase.OSGiDeploymentRequest.execute(OSGiDeploymentRequest.java:120)
at org.glassfish.osgijavaeebase.AbstractOSGiDeployer.deploy(AbstractOSGiDeployer.java:123)
at org.glassfish.osgijavaeebase.OSGiContainer.deploy(OSGiContainer.java:154)
at org.glassfish.osgijavaeebase.JavaEEExtender.deploy(JavaEEExtender.java:109)
at org.glassfish.osgijavaeebase.JavaEEExtender.access$200(JavaEEExtender.java:61)
at org.glassfish.osgijavaeebase.JavaEEExtender$HybridBundleTrackerCustomizer$1.call(JavaEEExtender.java:153)
at org.glassfish.osgijavaeebase.JavaEEExtender$HybridBundleTrackerCustomizer$1.call(JavaEEExtender.java:150)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
at java.util.concurrent.FutureTask.run(FutureTask.java:166)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
at java.lang.Thread.run(Thread.java:722)
]]

[2013-03-26T16:58:02.140+0900] [glassfish 4.0] [SEVERE] [AS-WEB-CORE-00108] [javax.enterprise.web.core] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284682140] [levelValue: 1000] [[
ContainerBase.addChild: start:
org.apache.catalina.LifecycleException: java.lang.RuntimeException: com.sun.faces.config.ConfigurationException: Factory 'javax.faces.context.ExternalContextFactory' was not configured properly.
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:2279)
at com.sun.enterprise.web.WebContainer.loadWebModule(WebContainer.java:1925)
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.osgijavaeebase.OSGiDeploymentRequest.deploy(OSGiDeploymentRequest.java:185)
at org.glassfish.osgijavaeebase.OSGiDeploymentRequest.execute(OSGiDeploymentRequest.java:120)
at org.glassfish.osgijavaeebase.AbstractOSGiDeployer.deploy(AbstractOSGiDeployer.java:123)
at org.glassfish.osgijavaeebase.OSGiContainer.deploy(OSGiContainer.java:154)
at org.glassfish.osgijavaeebase.JavaEEExtender.deploy(JavaEEExtender.java:109)
at org.glassfish.osgijavaeebase.JavaEEExtender.access$200(JavaEEExtender.java:61)
at org.glassfish.osgijavaeebase.JavaEEExtender$HybridBundleTrackerCustomizer$1.call(JavaEEExtender.java:153)
at org.glassfish.osgijavaeebase.JavaEEExtender$HybridBundleTrackerCustomizer$1.call(JavaEEExtender.java:150)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
at java.util.concurrent.FutureTask.run(FutureTask.java:166)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
at java.lang.Thread.run(Thread.java:722)
Caused by: java.lang.RuntimeException: com.sun.faces.config.ConfigurationException: Factory 'javax.faces.context.ExternalContextFactory' was not configured properly.
at com.sun.faces.config.ConfigureListener.contextInitialized(ConfigureListener.java:273)
at org.apache.catalina.core.StandardContext.contextListenerStart(StandardContext.java:5362)
at com.sun.enterprise.web.WebModule.contextListenerStart(WebModule.java:743)
at org.apache.catalina.core.StandardContext.start(StandardContext.java:5898)
... 25 more
Caused by: com.sun.faces.config.ConfigurationException: Factory 'javax.faces.context.ExternalContextFactory' was not configured properly.
at com.sun.faces.config.processor.FactoryConfigProcessor.verifyFactoriesExist(FactoryConfigProcessor.java:330)
at com.sun.faces.config.processor.FactoryConfigProcessor.process(FactoryConfigProcessor.java:236)
at com.sun.faces.config.ConfigManager.initialize(ConfigManager.java:424)
at com.sun.faces.config.ConfigureListener.contextInitialized(ConfigureListener.java:214)
... 28 more
Caused by: javax.faces.FacesException: org.primefaces.context.PrimeExternalContextFactory
at javax.faces.FactoryFinder.getImplGivenPreviousImpl(FactoryFinder.java:710)
at javax.faces.FactoryFinder.getImplementationInstance(FactoryFinder.java:572)
at javax.faces.FactoryFinder.access$500(FactoryFinder.java:140)
at javax.faces.FactoryFinder$FactoryManager.getFactory(FactoryFinder.java:1120)
at javax.faces.FactoryFinder.getFactory(FactoryFinder.java:379)
at com.sun.faces.config.processor.FactoryConfigProcessor.verifyFactoriesExist(FactoryConfigProcessor.java:328)
... 31 more
Caused by: org.jboss.weld.exceptions.IllegalArgumentException: Exception message for key UNABLE_TO_FIND_CONSTRUCTOR not found due to String index out of range: -1
at org.jboss.weld.manager.InjectionTargetFactoryImpl.createInjectionTarget(InjectionTargetFactoryImpl.java:69)
at org.jboss.weld.manager.BeanManagerImpl.createInjectionTarget(BeanManagerImpl.java:1039)
at org.glassfish.weld.services.JCDIServiceImpl.injectManagedObject(JCDIServiceImpl.java:286)
at org.glassfish.faces.integration.GlassFishInjectionProvider.inject(GlassFishInjectionProvider.java:189)
at javax.faces.FactoryFinder.getImplGivenPreviousImpl(FactoryFinder.java:695)
... 36 more
Caused by: org.jboss.weld.exceptions.DefinitionException: Exception message for key UNABLE_TO_FIND_CONSTRUCTOR not found due to String index out of range: -1
at org.jboss.weld.util.Beans.getBeanConstructor(Beans.java:327)
at org.jboss.weld.injection.InjectionPointFactory.createConstructorInjectionPoint(InjectionPointFactory.java:161)
at org.jboss.weld.injection.producer.DefaultInstantiator.<init>(DefaultInstantiator.java:59)
at org.jboss.weld.injection.producer.BasicInjectionTarget.initInstantiator(BasicInjectionTarget.java:153)
at org.jboss.weld.injection.producer.BasicInjectionTarget.<init>(BasicInjectionTarget.java:70)
at org.jboss.weld.injection.producer.BeanInjectionTarget.<init>(BeanInjectionTarget.java:44)
at org.jboss.weld.manager.InjectionTargetFactoryImpl.createInjectionTarget(InjectionTargetFactoryImpl.java:80)
at org.jboss.weld.manager.InjectionTargetFactoryImpl.createInjectionTarget(InjectionTargetFactoryImpl.java:65)
... 40 more
]]

[2013-03-26T16:58:02.140+0900] [glassfish 4.0] [WARNING] [] [javax.enterprise.web] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284682140] [levelValue: 900] [[
java.lang.IllegalStateException: ContainerBase.addChild: start: org.apache.catalina.LifecycleException: java.lang.RuntimeException: com.sun.faces.config.ConfigurationException: Factory 'javax.faces.context.ExternalContextFactory' was not configured properly.
java.lang.IllegalStateException: ContainerBase.addChild: start: org.apache.catalina.LifecycleException: java.lang.RuntimeException: com.sun.faces.config.ConfigurationException: Factory 'javax.faces.context.ExternalContextFactory' was not configured properly.
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:2279)
at com.sun.enterprise.web.WebContainer.loadWebModule(WebContainer.java:1925)
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.osgijavaeebase.OSGiDeploymentRequest.deploy(OSGiDeploymentRequest.java:185)
at org.glassfish.osgijavaeebase.OSGiDeploymentRequest.execute(OSGiDeploymentRequest.java:120)
at org.glassfish.osgijavaeebase.AbstractOSGiDeployer.deploy(AbstractOSGiDeployer.java:123)
at org.glassfish.osgijavaeebase.OSGiContainer.deploy(OSGiContainer.java:154)
at org.glassfish.osgijavaeebase.JavaEEExtender.deploy(JavaEEExtender.java:109)
at org.glassfish.osgijavaeebase.JavaEEExtender.access$200(JavaEEExtender.java:61)
at org.glassfish.osgijavaeebase.JavaEEExtender$HybridBundleTrackerCustomizer$1.call(JavaEEExtender.java:153)
at org.glassfish.osgijavaeebase.JavaEEExtender$HybridBundleTrackerCustomizer$1.call(JavaEEExtender.java:150)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
at java.util.concurrent.FutureTask.run(FutureTask.java:166)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
at java.lang.Thread.run(Thread.java:722)
]]

[2013-03-26T16:58:02.140+0900] [glassfish 4.0] [SEVERE] [] [javax.enterprise.system.tools.deployment.common] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284682140] [levelValue: 1000] [[
Exception while invoking class com.sun.enterprise.web.WebApplication start method
java.lang.Exception: java.lang.IllegalStateException: ContainerBase.addChild: start: org.apache.catalina.LifecycleException: java.lang.RuntimeException: com.sun.faces.config.ConfigurationException: Factory 'javax.faces.context.ExternalContextFactory' was not configured properly.
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.osgijavaeebase.OSGiDeploymentRequest.deploy(OSGiDeploymentRequest.java:185)
at org.glassfish.osgijavaeebase.OSGiDeploymentRequest.execute(OSGiDeploymentRequest.java:120)
at org.glassfish.osgijavaeebase.AbstractOSGiDeployer.deploy(AbstractOSGiDeployer.java:123)
at org.glassfish.osgijavaeebase.OSGiContainer.deploy(OSGiContainer.java:154)
at org.glassfish.osgijavaeebase.JavaEEExtender.deploy(JavaEEExtender.java:109)
at org.glassfish.osgijavaeebase.JavaEEExtender.access$200(JavaEEExtender.java:61)
at org.glassfish.osgijavaeebase.JavaEEExtender$HybridBundleTrackerCustomizer$1.call(JavaEEExtender.java:153)
at org.glassfish.osgijavaeebase.JavaEEExtender$HybridBundleTrackerCustomizer$1.call(JavaEEExtender.java:150)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
at java.util.concurrent.FutureTask.run(FutureTask.java:166)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
at java.lang.Thread.run(Thread.java:722)
]]

[2013-03-26T16:58:02.156+0900] [glassfish 4.0] [SEVERE] [NCLS-CORE-00026] [javax.enterprise.system.core] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284682156] [levelValue: 1000] [[
Exception during lifecycle processing
java.lang.Exception: java.lang.IllegalStateException: ContainerBase.addChild: start: org.apache.catalina.LifecycleException: java.lang.RuntimeException: com.sun.faces.config.ConfigurationException: Factory 'javax.faces.context.ExternalContextFactory' was not configured properly.
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.osgijavaeebase.OSGiDeploymentRequest.deploy(OSGiDeploymentRequest.java:185)
at org.glassfish.osgijavaeebase.OSGiDeploymentRequest.execute(OSGiDeploymentRequest.java:120)
at org.glassfish.osgijavaeebase.AbstractOSGiDeployer.deploy(AbstractOSGiDeployer.java:123)
at org.glassfish.osgijavaeebase.OSGiContainer.deploy(OSGiContainer.java:154)
at org.glassfish.osgijavaeebase.JavaEEExtender.deploy(JavaEEExtender.java:109)
at org.glassfish.osgijavaeebase.JavaEEExtender.access$200(JavaEEExtender.java:61)
at org.glassfish.osgijavaeebase.JavaEEExtender$HybridBundleTrackerCustomizer$1.call(JavaEEExtender.java:153)
at org.glassfish.osgijavaeebase.JavaEEExtender$HybridBundleTrackerCustomizer$1.call(JavaEEExtender.java:150)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
at java.util.concurrent.FutureTask.run(FutureTask.java:166)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
at java.lang.Thread.run(Thread.java:722)
]]

[2013-03-26T16:58:02.156+0900] [glassfish 4.0] [SEVERE] [] [javax.enterprise.system.core] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284682156] [levelValue: 1000] [[
Exception while loading the app]]

[2013-03-26T16:58:02.156+0900] [glassfish 4.0] [SEVERE] [AS-WEB-GLUE-00192] [javax.enterprise.web] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284682156] [levelValue: 1000] [[
Undeployment failed for context /dummy-web]]

[2013-03-26T16:58:02.187+0900] [glassfish 4.0] [INFO] [] [org.glassfish.osgijavaeebase] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284682187] [levelValue: 800] [[
Deleted D:\20130125\glassfish9\glassfish4\glassfish\domains\domain1\osgi-cache\felix\bundle292\data\applications\bundle296-1364284680250]]

[2013-03-26T16:58:02.187+0900] [glassfish 4.0] [SEVERE] [] [org.glassfish.osgijavaeebase] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284682187] [levelValue: 1000] [[
Failed while deploying bundle org.glassfish.osgi.dummy-web [296]]]

[2013-03-26T16:58:02.187+0900] [glassfish 4.0] [INFO] [] [org.glassfish.osgiweb] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284682187] [levelValue: 800] [[
Removed bundle 296 against context path /dummy-web ]]

[2013-03-26T16:58:02.187+0900] [glassfish 4.0] [WARNING] [] [org.glassfish.osgijavaeebase] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284682187] [levelValue: 900] [[
Failed to deploy bundle org.glassfish.osgi.dummy-web [296]
org.glassfish.osgijavaeebase.DeploymentException: Deployment of org.glassfish.osgi.dummy-web [296] failed because of following reason: Failed while deploying bundle org.glassfish.osgi.dummy-web [296] : java.lang.RuntimeException: Failed to deploy bundle [ org.glassfish.osgi.dummy-web [296] ], root cause: Exception while loading the app
at org.glassfish.osgijavaeebase.AbstractOSGiDeployer.deploy(AbstractOSGiDeployer.java:127)
at org.glassfish.osgijavaeebase.OSGiContainer.deploy(OSGiContainer.java:154)
at org.glassfish.osgijavaeebase.JavaEEExtender.deploy(JavaEEExtender.java:109)
at org.glassfish.osgijavaeebase.JavaEEExtender.access$200(JavaEEExtender.java:61)
at org.glassfish.osgijavaeebase.JavaEEExtender$HybridBundleTrackerCustomizer$1.call(JavaEEExtender.java:153)
at org.glassfish.osgijavaeebase.JavaEEExtender$HybridBundleTrackerCustomizer$1.call(JavaEEExtender.java:150)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
at java.util.concurrent.FutureTask.run(FutureTask.java:166)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
at java.lang.Thread.run(Thread.java:722)
Caused by: java.lang.RuntimeException: Failed to deploy bundle [ org.glassfish.osgi.dummy-web [296] ], root cause: Exception while loading the app
at org.glassfish.osgijavaeebase.OSGiDeploymentRequest.deploy(OSGiDeploymentRequest.java:198)
at org.glassfish.osgijavaeebase.OSGiDeploymentRequest.execute(OSGiDeploymentRequest.java:120)
at org.glassfish.osgijavaeebase.AbstractOSGiDeployer.deploy(AbstractOSGiDeployer.java:123)
... 10 more
Caused by: java.lang.Exception: java.lang.IllegalStateException: ContainerBase.addChild: start: org.apache.catalina.LifecycleException: java.lang.RuntimeException: com.sun.faces.config.ConfigurationException: Factory 'javax.faces.context.ExternalContextFactory' was not configured properly.
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.osgijavaeebase.OSGiDeploymentRequest.deploy(OSGiDeploymentRequest.java:185)
... 12 more
]]

So, needing to investigate the reasons from scene1 and scene2 in depth.

Comment by TangYong [ 26/Mar/13 ]

About scene1, I have some interesting finding as following:

Noting the following exception info,

Caused by: java.lang.ClassNotFoundException: org.jboss.weld.jsf.WeldPhaseListener
at java.lang.ClassLoader.findClass(ClassLoader.java:522)
at java.lang.ClassLoader.loadClass(ClassLoader.java:423)
at com.sun.enterprise.v3.server.APIClassLoaderServiceImpl$APIClassLoader.loadClass(APIClassLoaderServiceImpl.java:257)
at com.sun.enterprise.v3.server.APIClassLoaderServiceImpl$APIClassLoader.loadClass(APIClassLoaderServiceImpl.java:222)
at org.glassfish.osgiweb.OSGiWebDeploymentContext$WABClassLoader.loadClass(OSGiWebDeploymentContext.java:170)
at org.glassfish.osgiweb.OSGiWebDeploymentContext$WABClassLoader.loadClass(OSGiWebDeploymentContext.java:153)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:264)
at com.sun.faces.util.Util.loadClass(Util.java:301)
at com.sun.faces.config.processor.AbstractConfigProcessor.loadClass(AbstractConfigProcessor.java:376)
... 35 more
]]

Noting an important change[1] from Weld 1.x --> Weld 2.x
[1]: https://community.jboss.org/wiki/WeldIntegratorGuide-ChangesForWeld20

"WeldPhaseListener has been removed. The listener served as a hook for activating / deactivating conversations. In CDI 1.1 (CDI-80) conversations are now available for pure Servlet requests and therefore conversation activation is handled in the WeldListener (which is a Servlet listener)."

The same issue can be found in [2],
[2]: https://community.jboss.org/thread/218292

I will confirm whether truly being caused by the change.

Comment by TangYong [ 26/Mar/13 ]

Adding priority into Major because the issue maybe related to Weld 2.x change.

Comment by TangYong [ 26/Mar/13 ]

From JBOSS guy(Jozef Hartinger)'s fixing[1], org.jboss.weld.jsf.WeldPhaseListener should be removed from faces-config.xml since weld 2.x.

[1]: https://source.jboss.org/browse/WeldCore/environments/servlet/core/src/main/resources/META-INF/faces-config.xml?r2=99d2f3568c5671a297319b8ef6d967b07b6279c7&r1=fb35e1d1b8106854b606c999ab634ab59b92045d

So, weld.faces-config.xml should be updated and remove the following

<lifecycle>
<phase-listener>org.jboss.weld.jsf.WeldPhaseListener</phase-listener>
</lifecycle>

Now, scene1 has OK! I will update the workaround.

Comment by Sanjeeb Sahoo [ 26/Mar/13 ]

Sorry, this didn't get due attention for 4.0.

Comment by TangYong [ 27/Mar/13 ]

Scene2 has been resolved and investigation result is as following,

While using primefaces 2.1 with CDI(Weld) in the sample(dummy-web.war), Scene2's exceptions will be caused by the following and caused the whole WAB's deployment failed.

Caused by: org.jboss.weld.exceptions.DefinitionException: Exception message for key UNABLE_TO_FIND_CONSTRUCTOR not found due to String index out of range: -1
at org.jboss.weld.util.Beans.getBeanConstructor(Beans.java:327)
....

[Analyze]
1 in primefaces 2.1, org.primefaces.context.PrimeExternalContextFactory does not offer a default or no-args constructor, so, in org.jboss.weld.util.Beans.getBeanConstructor method, "constructor" will be null, then, throwing a DefinitionException called "UNABLE_TO_FIND_CONSTRUCTOR" , thus, causing the above exception.

The exception also caused two bad results:
1) WebContainer.loadWebModule failed
2) WAB expanded failed

2 I investigated primefaces 2.x and 3.x and found an interesting thing as following:
In primefaces 3.x(eg. 3.5), org.primefaces.context.PrimeExternalContextFactory has not existed. So I made an experiment to replace primefaces-2.1.jar with primefaces-3.5.jar in the WAB's WEB-INF/lib. Then, after deploying the new WAB, the exceptions all did not happen. And can access "http://localhost:8080/dummy-web/" normally.

Only a issue is that while accessing "http://localhost:8080/dummy-web/", there are the following warning info:
"
Warning: This page calls for XML namespace http://primefaces.prime.com.tr/ui declared with prefix p but no taglibrary exists for that namespace.
Warning: This page calls for XML namespace http://primefaces.prime.com.tr/ui declared with prefix p but no taglibrary exists for that namespace. "

The warning info is caused by [1]:
[1]: http://stackoverflow.com/questions/7565431/warning-this-page-calls-for-xml-namespace-http-primefaces-prime-com-tr-ui-dec

While modifying the sample's index.xhtml from xmlns="http://primefaces.prime.com.tr/ui" to xmlns="http://primefaces.org/ui" , although the warning has not disappeared, primefaces's tree tag was not still displayed normally. However, I think that this should be primefaces's using problems rather than gf's problems.

So, in a word, the Scene2 should belong to user's sample problem rather than gf's problem.

Thanks
--Tang





[GLASSFISH-20760] Updating fighterfish uas's parent pom to use maven-war-plugin 2.4 version Created: 14/Aug/13  Updated: 19/Sep/14

Status: Open
Project: glassfish
Component/s: OSGi-JavaEE
Affects Version/s: 4.0_b89_RC5
Fix Version/s: 4.1

Type: Improvement Priority: Minor
Reporter: TangYong Assignee: Sanjeeb Sahoo
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows



 Description   

maven-war-plugin 2.1 version has a bug as following:

While building war or wab in windows platform using 2.1 version, there are two same web.xml in the final war.

So, I suggest updating maven-war-plugin into 2.4 version.

Sahoo, do you agree with me?



 Comments   
Comment by TangYong [ 14/Aug/13 ]

About the bug, pl. seeing the following:

http://jira.codehaus.org/browse/MWAR-235

Comment by TangYong [ 14/Aug/13 ]

BTW: although currently, simpleweb needs not web.xml, for other using scene(eg. jsf), we'd better update the plugin.

Comment by Sanjeeb Sahoo [ 14/Aug/13 ]

I see no issues in upgrading the plugin version as long as there is no regression. Just to be clear, you want this changed in sample.parent-pom, don't you?

Comment by TangYong [ 14/Aug/13 ]

Yes, I want to make a change in sample.parent-pom. Just as you said, before updating the pom, we must guarantee there is no any regression.

As an example or scene, you can see the issue by building https://github.com/tangyong/GlassFishOSGiJavaEESample/tree/master/glassfish.wab.sample

Thanks
Tang

Comment by TangYong [ 27/Aug/13 ]

Regression Test is OK except for GLASSFISH-20782 and GLASSFISH-20782 is not related to the jira.

So, I will commit the change.

Comment by TangYong [ 27/Aug/13 ]

Done.

Revisions:
----------
62656





[GLASSFISH-20463] DAS fails to stop with stop-domain --force=false due to a non-daemon thread Created: 03/May/13  Updated: 19/Sep/14

Status: Open
Project: glassfish
Component/s: OSGi-JavaEE
Affects Version/s: 4.0_b87_RC3
Fix Version/s: 4.1

Type: Bug Priority: Major
Reporter: Tom Mueller Assignee: Sanjeeb Sahoo
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

If you do:

asadmin start-domain
asadmin stop-domain --force=false

You get a timeout:

$ asadmin stop-domain --force=false
Waiting for the domain to stop ........................................................
Timed out (60 seconds) waiting for the domain to stop.
Command stop-domain failed.

This is due to a non-daemon thread in a thread pool. From the jstack output:

"pool-8-thread-1" prio=5 tid=0x00007fa321b71000 nid=0xa103 waiting on condition [0x00000001368d5000]
java.lang.Thread.State: WAITING (parking)
at sun.misc.Unsafe.park(Native Method)

  • parking to wait for <0x00000001292d9910> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
    at java.util.concurrent.locks.LockSupport.park(LockSupport.java:186)
    at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2043)
    at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
    at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1068)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1130)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
    at java.lang.Thread.run(Thread.java:722)


 Comments   
Comment by Tom Mueller [ 03/May/13 ]

This thread appears to be coming from the FighterFish ExtenderManager.GlassFishServerTracker class. This class calls Executors.newSingleThreadExecutor but never calls any shutdown method on the executor. The thread that is created by this executor is not a daemon thread.

Please evaluate whether this is a stopper for 4.0.

Comment by Sanjeeb Sahoo [ 06/May/13 ]

At this stage of 4.0 release, I am inclined to not fix this issue. We will fix it in 4.0.1.

Comment by TangYong [ 06/May/13 ]

Sahoo

I also agree with you not fixing the issue in 4.0 and put in 4.0.1. Just as fixing itself, I think that following seems to be reasonable,

1. raising up executorService into GlassFishServerTracker class instance member
2. shutdown logic should be put into removedService method, and once executorService is not null, we execute
executorService.shutdown() and assign executorService is null.

Tang





[GLASSFISH-15362] Improve design of OSGiContainer/BundleTracker interaction Created: 27/Dec/10  Updated: 19/Sep/14

Status: Open
Project: glassfish
Component/s: OSGi-JavaEE
Affects Version/s: 3.1_b33
Fix Version/s: 4.1

Type: Task Priority: Major
Reporter: Sanjeeb Sahoo Assignee: Sanjeeb Sahoo
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Currently the bundle tracker is owned by JavaEEExtender. It will probably make more sense to move it to OSGiContainer so that it can optimize tracking of bundles and make better use of Future API as well as ServiceTracker API to decide when to stop tracking bundles.






[GLASSFISH-19249] @OSGi causes ClassCastException when used from EJB deployed as EAR Created: 26/Oct/12  Updated: 19/Sep/14

Status: Open
Project: glassfish
Component/s: OSGi-JavaEE
Affects Version/s: 3.1.2.2
Fix Version/s: 4.1

Type: New Feature Priority: Critical
Reporter: cplaetzinger Assignee: Sanjeeb Sahoo
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

I have a stateless session bean packaged and deployed as OSGi hybrid bundle. I want to access this EJB from another EJB packaged in an EAR file. So I used the following annotations:

@Inject
@OSGiService( dynamic = true )
private QueueRegistryInterface queueRegistry;

Deployment works fine but on runtime I got the following exception:

[2012-10-26 11:30:13,695] [ERROR] [org.glassfish.osgicdi.impl] [p: thread-pool-1; w: 7] [#1] Expected annotated element java.lang.ClassCastException to be within an OSGi Bundle.
[2012-10-26 11:30:13,695] [ERROR] [com.macd.xconnect.messageprocessor.base.MessageProcessor-OmsReceiver] [p: thread-pool-1; w: 7] failed to return failure message back: routeMessage: Error routing message: null
com.macd.xconnect.messageprocessor.base.MessageRouterBeanException: routeMessage: Error routing message: null
        at com.macd.xconnect.ejbeans.implementation.messagerouter.MessageRouterBean.routeMessage(MessageRouterBean.java:132)
        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.glassfish.ejb.security.application.EJBSecurityManager.runMethod(EJBSecurityManager.java:1052)
        at org.glassfish.ejb.security.application.EJBSecurityManager.invoke(EJBSecurityManager.java:1124)
        at com.sun.ejb.containers.BaseContainer.invokeBeanMethod(BaseContainer.java:5388)
        at com.sun.ejb.EjbInvocation.invokeBeanMethod(EjbInvocation.java:619)
        at com.sun.ejb.containers.interceptors.AroundInvokeChainImpl.invokeNext(InterceptorManager.java:800)
        at com.sun.ejb.EjbInvocation.proceed(EjbInvocation.java:571)
        at org.jboss.weld.ejb.SessionBeanInterceptor.aroundInvoke(SessionBeanInterceptor.java:49)
        at sun.reflect.GeneratedMethodAccessor84.invoke(Unknown Source)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:597)
        at com.sun.ejb.containers.interceptors.AroundInvokeInterceptor.intercept(InterceptorManager.java:861)
        at com.sun.ejb.containers.interceptors.AroundInvokeChainImpl.invokeNext(InterceptorManager.java:800)
        at com.sun.ejb.EjbInvocation.proceed(EjbInvocation.java:571)
        at com.sun.ejb.containers.interceptors.SystemInterceptorProxy.doAround(SystemInterceptorProxy.java:162)
        at com.sun.ejb.containers.interceptors.SystemInterceptorProxy.aroundInvoke(SystemInterceptorProxy.java:144)
        at sun.reflect.GeneratedMethodAccessor77.invoke(Unknown Source)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:597)
        at com.sun.ejb.containers.interceptors.AroundInvokeInterceptor.intercept(InterceptorManager.java:861)
        at com.sun.ejb.containers.interceptors.AroundInvokeChainImpl.invokeNext(InterceptorManager.java:800)
        at com.sun.ejb.containers.interceptors.InterceptorManager.intercept(InterceptorManager.java:370)
        at com.sun.ejb.containers.BaseContainer.__intercept(BaseContainer.java:5360)
        at com.sun.ejb.containers.BaseContainer.intercept(BaseContainer.java:5348)
        at com.sun.ejb.containers.EJBLocalObjectInvocationHandler.invoke(EJBLocalObjectInvocationHandler.java:214)
        at com.sun.ejb.containers.EJBLocalObjectInvocationHandlerDelegate.invoke(EJBLocalObjectInvocationHandlerDelegate.java:89)
        at $Proxy207.routeMessage(Unknown Source)
        at com.macd.xconnect.messageprocessor.base.MessageProcessor.processAndRouteMessage(MessageProcessor.java:201)
        at com.macd.xconnect.messageprocessor.base.MessageProcessor.onMessage(MessageProcessor.java:126)
        at com.macd.xconnect.ejbeans.messageprocessor.MessageProcessorBean.onMessage(MessageProcessorBean.java:155)
        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.glassfish.ejb.security.application.EJBSecurityManager.runMethod(EJBSecurityManager.java:1052)
        at org.glassfish.ejb.security.application.EJBSecurityManager.invoke(EJBSecurityManager.java:1124)
        at com.sun.ejb.containers.BaseContainer.invokeTargetBeanMethod(BaseContainer.java:4180)
        at com.sun.ejb.containers.BaseContainer.__intercept(BaseContainer.java:5368)
        at com.sun.ejb.containers.BaseContainer.intercept(BaseContainer.java:5348)
        at com.sun.ejb.containers.MessageBeanContainer.deliverMessage(MessageBeanContainer.java:1099)
        at com.sun.ejb.containers.MessageBeanListenerImpl.deliverMessage(MessageBeanListenerImpl.java:81)
        at com.sun.enterprise.connectors.inbound.MessageEndpointInvocationHandler.invoke(MessageEndpointInvocationHandler.java:171)
        at $Proxy314.onMessage(Unknown Source)
        at com.sun.messaging.jms.ra.OnMessageRunner.run(OnMessageRunner.java:260)
        at com.sun.enterprise.connectors.work.OneWork.doWork(OneWork.java:114)
        at com.sun.corba.ee.impl.orbutil.threadpool.ThreadPoolImpl$WorkerThread.performWork(ThreadPoolImpl.java:497)
        at com.sun.corba.ee.impl.orbutil.threadpool.ThreadPoolImpl$WorkerThread.run(ThreadPoolImpl.java:540)
Caused by: java.lang.ClassCastException
        at java.lang.Class.cast(Class.java:2990)
        at org.glassfish.osgicdi.impl.OSGiServiceFactory.getBundleContext(OSGiServiceFactory.java:191)
        at org.glassfish.osgicdi.impl.OSGiServiceFactory.lookupService(OSGiServiceFactory.java:127)
        at org.glassfish.osgicdi.impl.OSGiServiceFactory.access$100(OSGiServiceFactory.java:72)
        at org.glassfish.osgicdi.impl.OSGiServiceFactory$DynamicInvocationHandler.invoke(OSGiServiceFactory.java:232)
        at $Proxy315.find(Unknown Source)
        at com.macd.xconnect.messageprocessor.base.MessageRouter.sendMessage(MessageRouter.java:113)
        at com.macd.xconnect.messageprocessor.base.MessageRouter.sendMessage(MessageRouter.java:178)
        at com.macd.xconnect.messageprocessor.base.MessageRouter.routeMessage(MessageRouter.java:96)
        at com.macd.xconnect.ejbeans.implementation.messagerouter.MessageRouterBean.routeMessage(MessageRouterBean.java:130)
        ... 50 more

Please let me know if any further information or examples are required.



 Comments   
Comment by TangYong [ 06/Mar/13 ]

The exception is right because in this case, the EJB packaged in an EAR file can not obtain osgi related classloader and casues

BundleReference.class.cast(annotatedElt.getClassLoader()) will throw ClassCastException.

About how to fix the problem has the following considerations

1. Considering Hybrid EAR deploying

AFAIA, Hybrid EAR deploying is not still supported. Please paying attention to GLASSFISH-6741

2. Considering not using @OSGiService in the EAR

Whether can using JNDI or @EJB although I have not tried, if you can offer further information?

3. Spliting the EAR into WAB and another EJB Bundle in order to use @OSGiService

Thanks
--Tang

Comment by cplaetzinger [ 06/Mar/13 ]

I would like to see hybrid EAR deploying too. We have a huge JEE application packaged and deployed as EAR. So we tried to split it up into several modules using the Glassfish hybrid bundle approach. Since we can not refactor the whole application at once it is necessary to access the beans deployed within a hybrid bundle from the beans deployed in the EAR.

I also tried to access the EJB via JNDI lookup and @EJB annotation but it ends up with other exceptions.

Comment by TangYong [ 06/Mar/13 ]

>I also tried to access the EJB via JNDI lookup and @EJB annotation but it ends up with other exceptions.
I suggest that you can create a more litter case to mock your real JEE application and thus, you can narrow the problems domain into more litter domain. Then, giving me your mocked sample and exception, I will help you analyse and debug it and see how to fix it. Then, once OK, you can apply it into your real case.

If you have more time, please do it and send sample to me(www.tangyong.gf@gmail.com).

Thanks
--Tang

Comment by cplaetzinger [ 06/Mar/13 ]

Hi Tang,

thanks for your help and effort so far. I will try to get an example running next week.

regards,
Christian

Comment by TangYong [ 11/Apr/13 ]

Christian,

Pl. whether can send me an example about the issue.
My email: tangyong@cn.fujitsu.com

Comment by Sanjeeb Sahoo [ 12/Apr/13 ]

I have made it a new feature, because we don't support osgi bundles as part of ear files.

Comment by jthoennes [ 12/Apr/13 ]

Thanks, Sanjeeb. Do you have any plans when you could implement this feature?

Comment by cplaetzinger [ 12/Apr/13 ]

@Sanjeeb: Do you require any input from me?

Comment by Sanjeeb Sahoo [ 12/Apr/13 ]

No, I don't need any further input now. I will get back when we try to implement this.

Comment by jthoennes [ 12/Apr/13 ]

@Sanjeeb: Is there any chance to expedite this implementation by filing a service request in order to increase the priority for your management?

Comment by TangYong [ 16/Apr/13 ]

Sahoo,

I am confirming whether or how to integrate only Apache Aries Application(EBA) into Glassfish?
About supporting for ear in OSGi, I have evaluated many vendors's solution as following,

1 JBOSS 7
Having such a support.
1)
After the discussion with JBOSS OSGi's leader, he gives a test sample[1](However, I have not still tried the sample).
[1]https://github.com/jbossas/jboss-as/blob/7.2.0.Final/testsuite/integration/osgi/src/test/java/org/jboss/as/test/integration/osgi/ear/EnterpriseArchiveTestCase.java

2)integrating Apache Aries Application(EBA) into JBOSS OSGi[2]
Having been available.
[2]: https://issues.jboss.org/browse/JBOSGI-529

3) integrating Apache Aries Subsystem into JBOSS[3]
Will be done on 8.0.0.Beta1
[3]: https://issues.jboss.org/browse/AS7-5921

2 Apache Geronimo 3
Having such a support.
Using Apache Aries Application(EBA).

3 Apache Aries
Having such a support.
1) Apache Aries Application(EBA)
Having been in available status.

2) Apache Aries Subsystem(ESA)
Being in develop status. However, this will become RI of OSGi R5 Subsystem in the future.

4 Spring Source
Having such a support.
1) using PAR file
2) Spring Plan
However, I have not tried Spring related supports.

5 Apache Karaf
Having such a support
1) using Karaf feature
2) integrating Apache Aries into karaf[4]
[4]: http://repo2.maven.org/maven2/org/apache/karaf/assemblies/features/enterprise/2.3.1/enterprise-2.3.1-features.xml

So, based on the above results, we should have three implementation ways:

  • Considering a private solution
    eg. asadmin deploy --type=osgi xxx.ear

ear's structure:
--EAR
├ application.xml
├ lib/... (share lib)
├ ejb bundle
├ war bundle
├ other bundles

  • Integrating Apache Aries Application into Glassfish
    I am doing
  • Integrating Apache Aries Subsystem into Glassfish
    Waiting Subsystem's release

In any way, in the future, Subsystem should replace current private solutions from each vendor.

Thanks
--Tang

Comment by jthoennes [ 16/Apr/13 ]

Hello Tang,

thanks for your detailed about comment about OSGi support for EARs.

As we are in transition from the classic JEE modules to OSGi modules we are looking
for the support of hybrid applications (i.e. mixed OSGi and non-OSGi modules).

Would this be also covered by the Apache Aries integration?

Many thanks, Jörg

Comment by TangYong [ 16/Apr/13 ]

jthoennes,

For mixing OSGi and non-OSGi modules, Sahoo has done much.

>Would this be also covered by the Apache Aries integration?
I am investigating it. Pl. give me some time,

There are some things needing to notice:

1) my consideration is that we only integrate apache aries application(eba)(including part of blueprint) rather than all aries functions, because glassfish
osgi-javaee has offered many features(eg. osgi jpa, osgi jta...), I must select minimized set while integrating eba.

2) we must not influence current gf starting performance while integrating eba

3) so far, I felt that we need to make a bridge between deployment and eba.

Thanks
--Tang

Comment by TangYong [ 16/Apr/13 ]

jthoennes
CC: Sahoo

Initial investigation has been ended. and I have an integration plan. However, can not check in the plan because having some issues.

OK, I fistly said the integration plan.

1) creating three new directories in glassfish\modules

  • third-party\aries\application
  • third-party\aries\blueprint
  • third-party\aries\pre-requisites

2) putting the following aries related bundles into the above three directories

  • third-party\aries\application
    org.apache.aries.application.api-1.0.0.jar
    org.apache.aries.application.default.local.platform-1.0.0.jar
    org.apache.aries.application.deployment.management-1.0.0.jar
    org.apache.aries.application.install-1.0.0.jar
    org.apache.aries.application.management-1.0.0.jar
    org.apache.aries.application.modeller-1.0.0.jar
    org.apache.aries.application.resolver.noop-1.0.0.jar
    org.apache.aries.application.resolver.obr-1.0.0.jar
    org.apache.aries.application.runtime-1.0.0.jar
    org.apache.aries.application.utils-1.0.0.jar
  • third-party\aries\blueprint
    org.apache.aries.blueprint.api-1.0.0.jar
    org.apache.aries.blueprint.core-1.0.0.jar
  • third-party\aries\pre-requisites
    org.apache.aries.proxy-1.0.0.jar
    org.apache.aries.util-1.0.0.jar
    org.apache.felix.bundlerepository.jar
    slf4j-api-1.5.11.jar
    slf4j-simple-1.5.11.jar

3) add/modify the following into config\osgi.properties
glassfish.osgi.auto.install=\
$

{com.sun.aas.installRootURI}modules/endorsed/ \
${com.sun.aas.installRootURI}

modules/osgi-resource-locator.jar \
$

{com.sun.aas.installRootURI}modules/ \
${com.sun.aas.installRootURI}

modules/autostart/ \
$

{com.sun.aas.installRootURI}modules/third-party/aries/pre-requisites/ \
${com.sun.aas.installRootURI}

modules/third-party/aries/blueprint/ \
$

{com.sun.aas.installRootURI}modules/third-party/aries/application/

aries.bundles=\
${com.sun.aas.installRootURI}

modules/third-party/aries/pre-requisites/ \
$

{com.sun.aas.installRootURI}modules/third-party/aries/blueprint/ \
${com.sun.aas.installRootURI}

modules/third-party/aries/application/

glassfish.osgi.auto.start=\
$

{core.bundles}

\
$

{autostart.bundles} \
${aries.bundles}

glassfish.osgi.auto.start.level.2=${autostart.bundles}

\
$

{aries.bundles}

4) start-domain

5) putting your eba into glassfish\domains\domain1\autodeploy\bundles

6) using asadmin osgi lb to see whether the bundles in your eba have been deployed.

I will give an detailed steps in my blog about how to play with it including an eba sample.

[Analise]
I said that I can not check in the above plan because,

1) influence gf starting performance

  • Sahoo has removed org.apache.felix.bundlerepository.jar, however, I must put it back because of aries.
  • should not start these third-party bundles while starting gf, more reasonable doing is to start them while deploying eba.

2) deployment can not recognize eba's deployment
Currently, only executing "asadmin deploy --type=osgi .../xx.eba" has not any effect and causes failed deployment.So, must investigate
how to make a bridge between deployment and aries eba deployment. Thus, we can resolve 1)'s issue.
However, I have more urgent things, so I said this is my initial result.

Thanks
--Tang

Comment by TangYong [ 18/Apr/13 ]

jthoennes
CC: Sahoo

>I will give an detailed steps in my blog about how to play with it including an eba sample.
You can see concrete steps and test sample in the following:

http://osgizone.typepad.com/tangyong/2013/04/glassfish-osgi-integration-part1-integrating-apache-aries-application-into-glassfish-v4.html

Thanks
--Tang

Comment by jthoennes [ 05/Sep/13 ]

Hello,

this issues is planned for release 4.0.1. Is anybody working on this right now? When is this release due?

Thanks, Jörg

Comment by TangYong [ 05/Sep/13 ]

If exactly speaking, EAR OSGi Deployment has not a uniform standard, although OSGi EE has published a SubSystem Spec.
For the feature, there are three ways:

1. let us wait SubSystem Spec Implementation
The Subsystem Spec Implementation is charged by Apache Aries.

2. Using Apache Aries Application Feature
Just as what I said in my blog, however, this way has a backback that we need to arrange right bundles related to the feature.
Indeedly, we need some function liking Apache Karaf Feature to provision such feature automaticlly. However, this will change
GlassFish Kernel. You knonw , this will need more effort and also need to discuss with Sahoo carefully.

3. Implmenting a new Hybrid Application Bundle related to EAR.
This also needed to be dicuss with Sahoo. Eg. whether needing to implement it currently?

So, for your scene, I suggest that you can do it based on my blog.

If having any problem,

giving me your sample (pl. adding your sample into github or others which I can acess)

In the future, we will implement OSGi/CDI Spec firstly, however, once we felt your scene is most important, we will change plan and maybe firstly
implement the feature you mentioned.

Of Course, also pl. listening Sahoo's suggestion.

Thanks
Tang





[GLASSFISH-20735] Creating a new maven archeType to generate a maven project template for supporting GlassFish OSGi Web Created: 01/Aug/13  Updated: 19/Sep/14

Status: In Progress
Project: glassfish
Component/s: OSGi-JavaEE
Affects Version/s: None
Fix Version/s: 4.1

Type: New Feature Priority: Minor
Reporter: TangYong Assignee: TangYong
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Zip Archive archetype-osgi-web.zip     Zip Archive sample-osgi-web.zip    

 Description   

Creating a new maven archeType to generate a maven project template for supporting GlassFish OSGi Web.

The maven plugin should make an user can use GlassFish OSGi Web more easy.

FighterFish's sample.parent-pom can be used as a template for the archeType.



 Comments   
Comment by TangYong [ 06/Aug/13 ]

Sahoo,

After creating a maven project using the new maven archeType, in the create maven project, its pom looks like the following:

<modelVersion>4.0.0</modelVersion>
<parent>
<artifactId>sample.parent-pom</artifactId>
<groupId>org.glassfish.fighterfish</groupId>
<version>1.0.1</version>
</parent>
<groupId>XXX</groupId>
<artifactId>YYY</artifactId>
<version>1.0.0-SNAPSHOT</version>
<name>ZZZ</name>
...

Here, I have a question needing to be discussed,

Currently, sample.parent-pom's version should be 1.0.3, however, in sample.uas.api's pom from fighterfish's trunk, sample.parent-pom's version is 1.0.1.

So, needing to confirm the sample.parent-pom's version in the created maven project. (I am assuming that sample.uas.api and other should be updated).

Comment by TangYong [ 03/Sep/13 ]

Updating the feature's summary. The reason is that while discussing with Sahoo,

[Sanjeeb]
I think we need different archetypes for different types of applications: one for war, one for ejb-osgi bundle.

So, I will create another feature for ejb-osgi bundle.

Comment by asst2003 [ 03/Sep/13 ]

After reviewing with Tang and Tang's confirmation, archetype-osgi-web has been finished. Because of file uploading's permission, I have requested Tang to upload the patch and final result.

Thanks
Cheng Xiao Ming

Comment by TangYong [ 03/Sep/13 ]

Sahoo,

archetype-osgi-web.zip contains source files and sample-osgi-web.zip contains the final result.

PL. Reviewing them, thanks.

Thanks Cheng Xiao Ming offering patch too!

Tang





[GLASSFISH-14317] faces configuration may not be discovered from WAB fragments attached as fragment bundles Created: 30/Oct/10  Updated: 19/Sep/14

Status: Open
Project: glassfish
Component/s: OSGi-JavaEE
Affects Version/s: 3.1
Fix Version/s: 4.1

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

Operating System: All
Platform: All


Issuezilla Id: 14,317
Status Whiteboard:

Workaround: Rename *-faces-config.xml to faces-config.xml in the fragment.

Tags: 3-1-next, 3_1-exclude, 3_1_1-scrubbed

 Description   

Need to write a test case to prove this, but given that OSGiWebModuleDecorator
uses OSGiBundleArchive as opposed to WAB to iterate over the entries, I doubt we
currently discover faces config resources from web fragments attached as bundle
fragments. Again, if GLASSFISH-14316 gets fixed, this will automatically get fixed.



 Comments   
Comment by Sanjeeb Sahoo [ 09/Nov/10 ]

3.1_ms7

Comment by Sanjeeb Sahoo [ 22/Dec/10 ]

When you see this issue, rename *.faces-config.xml to faces-config.xml in the fragment.





[GLASSFISH-19662] [osgi/javaee-base] wab fragment deployed using deploy command is not working Created: 11/Feb/13  Updated: 19/Sep/14

Status: Reopened
Project: glassfish
Component/s: OSGi-JavaEE
Affects Version/s: 4.0_b89_RC5
Fix Version/s: 4.1

Type: Bug Priority: Major
Reporter: Sanjeeb Sahoo Assignee: TangYong
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Text File T2_Test_19662.patch    
Issue Links:
Duplicate
is duplicated by GLASSFISH-16096 WARNINGs during deployment: Invalid z... Closed
is duplicated by GLASSFISH-16441 WAB fragments don't work for applicat... Closed

 Description   

asadmin deploy --type osgi sample.uas.simplewab-1.0.0.war
asadmin deploy --type osgi sample.uas.simplewabfragment-1.0.0.jar
http://localhost:8080/uas/report.jsp is not accessible.

Now undeploy sample.uas.simplewabfragment-1.0.0 and deploy using:
asadmin osgi install file:.../sample.uas.simplewabfragment-1.0.0.jar
asadmin update <samplewab>
Access the URL. It will work.



 Comments   
Comment by Sanjeeb Sahoo [ 11/Feb/13 ]

Tang,

See if you can fix it.

Sahoo

Comment by TangYong [ 16/Feb/13 ]

Sahoo,

firstly, the issue can be re-produced in my env. Slightly complementing the re-produce steps in "Description",

[Steps]
1 asadmin deploy --type=osgi sample.uas.api.jar

2 asadmin deploy --type=osgi sample.uas.simplewab.war

3 asadmin deploy --type=osgi simplewabfragment\target\sample.uas.simplewabfragment.jar

4 http://localhost:8080/uas/report.jsp is not accessible.

5 asadmin undeploy sample.uas.simplewabfragment

6 asadmin osgi install file:///.../sample.uas.simplewabfragment.jar

7 asadmin osgi update <sample.uas.simplewab's bundle Id>

8 http://localhost:8080/uas/report.jsp can be accessible.

Secondly, I noticed that the result of executing step 7 made simplewabfragment's state changed into "Resolved" from "Installed" , however, after step 3, simplewabfragment's state is still in "Installed" (in theory, it should be in "Resolved"). So, I start to make an experiment as following:

After step 3, I executed step 7 and found that although simplewabfragment's state changed into "Resolved" from "Installed", http://localhost:8080/uas/report.jsp is still not accessible and in server.log, I found the following exception(Bundle291 is simplewabfragment),

[#|2013-02-16T17:23:33.109+0900|INFO|glassfish 4.0|org.glassfish.osgijavaeebase|_ThreadID=101;_ThreadName=admin-listener(2);_TimeMillis=1361003013109;_LevelValue=800;|Deleted C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\osgiapp7602417806711521704|#]

[#|2013-02-16T17:23:33.109+0900|INFO|glassfish 4.0|org.glassfish.osgijavaeebase|_ThreadID=101;_ThreadName=admin-listener(2);_TimeMillis=1361003013109;_LevelValue=800;|Undeployed bundle org.glassfish.fighterfish.sample.uas.simplewab [290]|#]

[#|2013-02-16T17:23:33.468+0900|INFO|glassfish 4.0|org.glassfish.osgijavaeebase|_ThreadID=78;_ThreadName=pool-21-thread-1;_TimeMillis=1361003013468;_LevelValue=800;|Expanded at file:/C:/DOCUME~1/ADMINI~1/LOCALS~1/Temp/osgiapp8896161505402626238/|#]

[#|2013-02-16T17:23:33.484+0900|WARNING|glassfish 4.0|javax.enterprise.system.tools.deployment.common|_ThreadID=85;_ThreadName=deployment-jar-scanner;_TimeMillis=1361003013484;_LevelValue=900;_MessageID=NCLS-DEPLOYMENT-00019;|file open failure; file = file:/C:/DOCUME~1/ADMINI~1/LOCALS~1/Temp/osgiapp8896161505402626238/WEB-INF/lib/Bundle291.jar|#]

[#|2013-02-16T17:23:33.484+0900|WARNING|glassfish 4.0|javax.enterprise.system.tools.deployment.common|_ThreadID=85;_ThreadName=deployment-jar-scanner;_TimeMillis=1361003013484;_LevelValue=900;_MessageID=NCLS-DEPLOYMENT-00020;|exception message: error in opening zip file -- invalid zip file: invalid zip file: file:/C:/DOCUME~1/ADMINI~1/LOCALS~1/Temp/osgiapp8896161505402626238/WEB-INF/lib/Bundle291.jar|#]

[#|2013-02-16T17:23:33.500+0900|WARNING|glassfish 4.0|javax.enterprise.system.tools.deployment.common|_ThreadID=92;_ThreadName=deployment-jar-scanner;_TimeMillis=1361003013500;_LevelValue=900;_MessageID=NCLS-DEPLOYMENT-00019;|file open failure; file = file:/C:/DOCUME~1/ADMINI~1/LOCALS~1/Temp/osgiapp8896161505402626238/WEB-INF/lib/Bundle291.jar|#]

[#|2013-02-16T17:23:33.500+0900|WARNING|glassfish 4.0|javax.enterprise.system.tools.deployment.common|_ThreadID=92;_ThreadName=deployment-jar-scanner;_TimeMillis=1361003013500;_LevelValue=900;_MessageID=NCLS-DEPLOYMENT-00020;|exception message: error in opening zip file -- invalid zip file: invalid zip file: file:/C:/DOCUME~1/ADMINI~1/LOCALS~1/Temp/osgiapp8896161505402626238/WEB-INF/lib/Bundle291.jar|#]

[#|2013-02-16T17:23:33.500+0900|SEVERE|glassfish 4.0|javax.enterprise.system.tools.deployment.common|_ThreadID=92;_ThreadName=deployment-jar-scanner;_TimeMillis=1361003013500;_LevelValue=1000;|Exception while parsing file file:/C:/DOCUME~1/ADMINI~1/LOCALS~1/Temp/osgiapp8896161505402626238/WEB-INF/lib/Bundle291.jar
java.lang.NullPointerException
at com.sun.enterprise.deployment.deploy.shared.InputJarArchive$ArchiveJarEntrySource.<init>(InputJarArchive.java:581)
at com.sun.enterprise.deployment.deploy.shared.InputJarArchive$ArchiveJarEntrySource.<init>(InputJarArchive.java:573)
at com.sun.enterprise.deployment.deploy.shared.InputJarArchive.createEntryEnumeration(InputJarArchive.java:451)
at com.sun.enterprise.deployment.deploy.shared.InputJarArchive.entries(InputJarArchive.java:203)
at com.sun.enterprise.deployment.deploy.shared.InputJarArchive.entries(InputJarArchive.java:182)
at com.sun.enterprise.v3.server.ReadableArchiveScannerAdapter.onSelectedEntries(ReadableArchiveScannerAdapter.java:122)
at org.glassfish.hk2.classmodel.reflect.Parser.doJob(Parser.java:347)
at org.glassfish.hk2.classmodel.reflect.Parser.access$300(Parser.java:67)
at org.glassfish.hk2.classmodel.reflect.Parser$3.call(Parser.java:306)
at org.glassfish.hk2.classmodel.reflect.Parser$3.call(Parser.java:295)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
at java.util.concurrent.FutureTask.run(FutureTask.java:166)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
at java.lang.Thread.run(Thread.java:722)

#]

[#|2013-02-16T17:23:33.500+0900|WARNING|glassfish 4.0|javax.enterprise.system.tools.deployment.common|_ThreadID=78;_ThreadName=pool-21-thread-1;_TimeMillis=1361003013500;_LevelValue=900;|result fault org.glassfish.hk2.classmodel.reflect.Parser$Result@1cdcebc Result for /C:/DOCUME~1/ADMINI~1/LOCALS~1/Temp/osgiapp8896161505402626238/WEB-INF/lib/Bundle291.jar|#]

[#|2013-02-16T17:23:33.515+0900|INFO|glassfish 4.0|org.glassfish.osgiweb|_ThreadID=78;_ThreadName=pool-21-thread-1;_TimeMillis=1361003013515;_LevelValue=800;|uris = file:/C:/DOCUME~1/ADMINI~1/LOCALS~1/Temp/osgiapp8896161505402626238/WEB-INF/classes/, file:/C:/DOCUME~1/ADMINI~1/LOCALS~1/Temp/osgiapp8896161505402626238/WEB-INF/lib/Bundle291.jar|#]

[#|2013-02-16T17:23:33.515+0900|WARNING|glassfish 4.0|javax.enterprise.system.tools.deployment.common|_ThreadID=78;_ThreadName=pool-21-thread-1;_TimeMillis=1361003013515;_LevelValue=900;_MessageID=NCLS-DEPLOYMENT-00019;|file open failure; file = file:/C:/DOCUME~1/ADMINI~1/LOCALS~1/Temp/osgiapp8896161505402626238/WEB-INF/lib/Bundle291.jar|#]

[#|2013-02-16T17:23:33.515+0900|WARNING|glassfish 4.0|javax.enterprise.system.tools.deployment.common|_ThreadID=78;_ThreadName=pool-21-thread-1;_TimeMillis=1361003013515;_LevelValue=900;_MessageID=NCLS-DEPLOYMENT-00020;|exception message: error in opening zip file -- invalid zip file: invalid zip file: file:/C:/DOCUME~1/ADMINI~1/LOCALS~1/Temp/osgiapp8896161505402626238/WEB-INF/lib/Bundle291.jar|#]

[#|2013-02-16T17:23:33.531+0900|WARNING|glassfish 4.0|javax.enterprise.system.tools.deployment.common|_ThreadID=78;_ThreadName=pool-21-thread-1;_TimeMillis=1361003013531;_LevelValue=900;_MessageID=NCLS-DEPLOYMENT-00019;|file open failure; file = file:/C:/DOCUME~1/ADMINI~1/LOCALS~1/Temp/osgiapp8896161505402626238/WEB-INF/lib/Bundle291.jar|#]

[#|2013-02-16T17:23:33.531+0900|WARNING|glassfish 4.0|javax.enterprise.system.tools.deployment.common|_ThreadID=78;_ThreadName=pool-21-thread-1;_TimeMillis=1361003013531;_LevelValue=900;_MessageID=NCLS-DEPLOYMENT-00020;|exception message: error in opening zip file -- invalid zip file: invalid zip file: file:/C:/DOCUME~1/ADMINI~1/LOCALS~1/Temp/osgiapp8896161505402626238/WEB-INF/lib/Bundle291.jar|#]

[#|2013-02-16T17:23:33.578+0900|WARNING|glassfish 4.0|javax.enterprise.system.tools.deployment.common|_ThreadID=78;_ThreadName=pool-21-thread-1;_TimeMillis=1361003013578;_LevelValue=900;_MessageID=NCLS-DEPLOYMENT-00019;|file open failure; file = file:/C:/DOCUME~1/ADMINI~1/LOCALS~1/Temp/osgiapp8896161505402626238/WEB-INF/lib/Bundle291.jar|#]
...

Tomorrow, I will see the source in depth and continue to analyze the true reason.

Thanks(Happy new year!)
--Tang

Comment by TangYong [ 17/Feb/13 ]

Firstly, the true reason has been found, and simply saying as following:

While deploying or installing a wab with some fragments, osgi framework merges these fragments's metadata with the host’s and resolves the host bundle as normal. Sahoo has done it by expanding the wab(including the contents of fragment) into os's temp directory. While expanding, the fragment jar will be put into expanded directory's WEB-INF/lib), eg. on my env, liking C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\osgiapp3989882632779875557\WEB-INF\lib\Bundle290.jar. This also explained why we can see some log info liking "DOCUME~1/ADMINI~1/LOCALS~1/" in server.log.

However, Because "WEB-INF/lib/bundleXXX.jar" is not a valid jar, the issue happened.

The reason of not a valid jar is that in org.glassfish.osgijavaeebase.OSGiBundleArchive.getInputStream()(this method can be used while expanding), while using "asadmin deploying ..." to deploy a host bundle, the following code:

if (uri != null)

{ return uri.toURL().openStream(); }

else

{ ... }

uri specifies a domains/domain1/application/<fragment name>, and it is a directory form uri not jar form, so, in this case, openStream() can not return a valid inputstream.

Secondly, my fixing way is as following:

if (uri != null && !new File(uri).isDirectory()) { return uri.toURL().openStream(); }else{ ... }

Adding a judge and going "else" path.

The fixing way has passed my test and wish sahoo can confirm the fixing way(or whether having better way).

BTW: test steps have a slight change, and have two ways:

[Way1]
1 asadmin deploy --type=osgi sample.uas.api.jar

2 asadmin deploy --type=osgi sample.uas.simplewab.war

3 asadmin deploy --type=osgi simplewabfragment\target\sample.uas.simplewabfragment.jar

4 asadmin osgi update <sample.uas.simplewab's bundle Id>

5 access http://localhost:8080/uas/report.jsp

[Way2]
1 asadmin deploy --type=osgi sample.uas.api.jar

2 asadmin deploy --type=osgi simplewabfragment\target\sample.uas.simplewabfragment.jar

3 asadmin deploy --type=osgi sample.uas.simplewab.war

4 access http://localhost:8080/uas/report.jsp

--Tang

Comment by Sanjeeb Sahoo [ 18/Feb/13 ]

Tang,

Your analysis is spot on.

Can you post the diff in JIRA or email me the patch?

While I am reviewing your change, can you please run fighterfish tests (mvn clean test -f fighterfish/test/it/pom.xml) with your change?

Can you also add a test case in test/it/src/test/java/org/glassfish/fighterfish/test/it/T2_Test.java to capture this scenario? Call the test method test_GLASSFISH_19662().

Thanks,
Sahoo

Comment by TangYong [ 18/Feb/13 ]

Sahoo,

>Can you post the diff in JIRA or email me the patch?

Index: OSGiBundleArchive.java
===================================================================
— OSGiBundleArchive.java (revision 58798)
+++ OSGiBundleArchive.java (working copy)
@@ -334,8 +334,8 @@

  • @return a Jar format InputStream for this bundle's content
    */
    public InputStream getInputStream() throws IOException {
  • if (uri != null) {
  • return uri.toURL().openStream();
    + if (uri != null && !new File(uri).isDirectory()) { + return uri.toURL().openStream(); }

    else {
    // create a JarOutputStream on the fly from the bundle's content
    // Can we optimize by reading off Felix's cache? Investigate in future.

I will do other tasks.

Thanks
Tang

Comment by TangYong [ 19/Feb/13 ]

Task1:

>While I am reviewing your change, can you please run fighterfish tests (mvn clean test -f fighterfish/test
>/it/pom.xml) with your change?

This has been done.

...
Completed shutdown of GlassFish runtime
org.ops4j.pax.logging.pax-logging-api[org.ops4j.pax.logging.internal.Activator] : Disabling SLF4J API support.
org.ops4j.pax.logging.pax-logging-api[org.ops4j.pax.logging.internal.Activator] : Disabling Jakarta Commons Logging API support.
org.ops4j.pax.logging.pax-logging-api[org.ops4j.pax.logging.internal.Activator] : Disabling Log4J API support.
org.ops4j.pax.logging.pax-logging-api[org.ops4j.pax.logging.internal.Activator] : Disabling Avalon Logger API support.
org.ops4j.pax.logging.pax-logging-api[org.ops4j.pax.logging.internal.Activator] : Disabling JULI Logger API support.
Tests run: 25, Failures: 0, Errors: 0, Skipped: 4, Time elapsed: 152.312 sec

Results :

Tests run: 29, Failures: 0, Errors: 0, Skipped: 5

[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
...

Comment by TangYong [ 19/Feb/13 ]

A litter change needing to commit into trunk

Index: OSGiBundleArchive.java
===================================================================
— OSGiBundleArchive.java (revision 59590)
+++ OSGiBundleArchive.java (working copy)
@@ -1,7 +1,7 @@
/*

  • DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS HEADER.
    *
  • * Copyright (c) 2009-2012 Oracle and/or its affiliates. All rights reserved.
    + * Copyright (c) 2009-2013 Oracle and/or its affiliates. All rights reserved.
    *
  • The contents of this file are subject to the terms of either the GNU
  • General Public License Version 2 only ("GPL") or the Common Development
Comment by TangYong [ 19/Feb/13 ]

Task2:

>Can you also add a test case in test/it/src/test/java/org/glassfish/fighterfish/test/it/T2_Test.java to capture this
>scenario? Call the test method test_GLASSFISH_19662().

Done. The following is fighterfish's test result:

...
Completed shutdown of GlassFish runtime
org.ops4j.pax.logging.pax-logging-api[org.ops4j.pax.logging.internal.Activator] : Disabling SLF4J API support.
org.ops4j.pax.logging.pax-logging-api[org.ops4j.pax.logging.internal.Activator] : Disabling Jakarta Commons Logging API support.
org.ops4j.pax.logging.pax-logging-api[org.ops4j.pax.logging.internal.Activator] : Disabling Log4J API support.
org.ops4j.pax.logging.pax-logging-api[org.ops4j.pax.logging.internal.Activator] : Disabling Avalon Logger API support.
org.ops4j.pax.logging.pax-logging-api[org.ops4j.pax.logging.internal.Activator] : Disabling JULI Logger API support.
Tests run: 26, Failures: 0, Errors: 0, Skipped: 4, Time elapsed: 213 sec

Results :

Tests run: 30, Failures: 0, Errors: 0, Skipped: 5

[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 5:44.954s
...

However, according to sahoo's comments:

"when you add a test, mark it @Ignore. I will remove @Ignore when I integrate the new version of osgi-javaee-base.",

I will mark the test as @Ignore and commit into trunk.

Thanks
--Tang

Comment by TangYong [ 20/Feb/13 ]

[Sahoo's comments for current test]

Adding accessing /report.jsp as well to make sure that even resource processing is happening correctly.

Comment by TangYong [ 20/Feb/13 ]

This has been done and passed my fighterfish test.

Index: T2_Test.java
===================================================================
— T2_Test.java (revision 59589)
+++ T2_Test.java (working copy)
@@ -1,7 +1,7 @@
/*

  • DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS HEADER.
    *
  • * Copyright (c) 2011-2012 Oracle and/or its affiliates. All rights reserved.
    + * Copyright (c) 2011-2013 Oracle and/or its affiliates. All rights reserved.
    *
  • The contents of this file are subject to the terms of either the GNU
  • General Public License Version 2 only ("GPL") or the Common Development
    @@ -801,6 +801,51 @@
    tc.destroy();
    }
    }
    +
    + /**
    + * Regression test case for GLASSFISH_19662
    + *
    + * @throws GlassFishException
    + * @throws InterruptedException
    + * @throws BundleException
    + */
    + @Test
    + @Ignore //mark it @Ignore temply until when integrating the new version of osgi-javaee-base
    + public void test_GLASSFISH_19662() throws GlassFishException, InterruptedException, BundleException, IOException {
    + logger.logp(Level.INFO, "T2_Test", "test_GLASSFISH_19662", "ENTRY");
    + TestContext tc = TestContext.create(getClass());
    + try
    Unknown macro: {+ //firstly, we install sample.uas.api bundle+ String location = "mvn}

    finally

    { + tc.destroy(); + }

    + }

//////////////////////////////////////////////////////////////////
// Various utility methods used from test methods are found below.

Comment by Sanjeeb Sahoo [ 23/Feb/13 ]

svn commit details:
#59590: osgi-javaee-base module fixed
#59560: Test case added.
#59799: RELEASENOTE.txt updated.

Comment by Sanjeeb Sahoo [ 27/Mar/13 ]

Integrated osgi-javaee-base:1.0.6 with glassfish trunk in svn #60905, so marking the bug as resolved.

Comment by TangYong [ 28/May/13 ]

FighterFish Test Case should use "deploy command" rather than using OSGi API. So, reopening the issue and will fix test case.

Comment by TangYong [ 27/Aug/13 ]

A patch has been sent into Sahoo and will wait for his reviewing.

Comment by TangYong [ 28/Aug/13 ]

Based on Sahoo's reviewing and new confirmation for util class, a new patch has been attached, the patch has passed fighterfish regression test. In addition, URLHelper has offered a method to do simple get request.

Pl. confirming the patch, thanks.

Tang

Comment by Sanjeeb Sahoo [ 28/Aug/13 ]

looks good to be checked in.

Comment by TangYong [ 28/Aug/13 ]

Done.

Revisions:
----------
62665





[GLASSFISH-19854] [Fighterfish Test Framework]making this timeout (60000) configurable from test.util.WebAppBundle Created: 13/Mar/13  Updated: 19/Sep/14

Status: In Progress
Project: glassfish
Component/s: OSGi, OSGi-JavaEE
Affects Version/s: 3.1.2
Fix Version/s: 4.1

Type: Task Priority: Minor
Reporter: TangYong Assignee: TangYong
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Making this timeout (60000) is configurable from test.util.WebAppBundle.
[Sahoo]
The idea of test timeout is to kill a request after timeout and this fits in well. We can have a method in WebAppBundle.setReadTimeout() which a test can use to override if it likes to. The default value can be TestsConfiguration.getTimeout().



 Comments   
Comment by TangYong [ 14/Mar/13 ]

The task is in progress. Basically, based on the discuss between Sahoo and me, the following is detailed design,

(The overriding priority is 1>2>3)
1. allowing an user to override the Read Timeout property
creating a method called "setRequestReadTimeout" in WebAppBundle, and an user can call the method in T2_Test's some method.

2. if not calling setRequestReadTimeout in T2_Test, allowing an user to specify request.readtimeout system property while executing it tests.

eg. mvn clean test -Dglassfish.home=D:\20130125\glassfish2\glassfish4\glassfish -Drequest.readtimeout=30000

3. if not specifying -Drequest.readtimeout,

1) I have provided a default value in test.it/pom
<request.readtimeout>60000</request.readtimeout>

and the value will be set into RequestReadTimeout

2) if an user left the above empty, eg.
<request.readtimeout></request.readtimeout>, RequestReadTimeout will be TestsConfiguration.getTimeout()

Comment by TangYong [ 14/Mar/13 ]

Now, the above all cases have passed my it tests, and I will submit a patch and let sahoo review today.

Comment by TangYong [ 14/Mar/13 ]

Patch has been sent to Sahoo and waiting for review result.

Comment by Sanjeeb Sahoo [ 29/Mar/13 ]

Should we fix this after fixing GLASSFISH-20088?

Comment by TangYong [ 29/Mar/13 ]

Yes, I think so.

Comment by TangYong [ 22/May/13 ]

Ready to check in patch

Comment by TangYong [ 22/May/13 ]

Patch has been checked in.
At revision: 62061





[GLASSFISH-20986] URISyntaxException when bundle contains file with spaces in name Created: 14/Feb/14  Updated: 25/Feb/14

Status: Open
Project: glassfish
Component/s: OSGi, OSGi-JavaEE
Affects Version/s: 4.0
Fix Version/s: None

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


 Description   

When deploying an OSGi bundle containing files with spaces in the name I get the following error logged. In this case the bundle was an Apache FOP bundle.

2014-02-14T09:56:00.357+0100|INFO: ERROR: Bundle org.glassfish.fighterfish.osgi-jpa [296] EventDispatcher: Error during dispatch. (java.lang.RuntimeException: java.net.URISyntaxException: Illegal character in path at index 40: bundle://402.0:0/org/apache/fop/pdf/sRGB Color Space Profile.icm)
2014-02-14T09:56:00.358+0100|SEVERE: java.lang.RuntimeException: java.net.URISyntaxException: Illegal character in path at index 40: bundle://402.0:0/org/apache/fop/pdf/sRGB Color Space Profile.icm
at org.glassfish.osgijavaeebase.OSGiBundleArchive.getEntryURI(OSGiBundleArchive.java:320)
at org.glassfish.osgijavaeebase.OSGiBundleArchive$BundleResourceIterator.<init>(OSGiBundleArchive.java:718)
at org.glassfish.osgijavaeebase.OSGiBundleArchive$BundleResourceIterator.<init>(OSGiBundleArchive.java:681)
at org.glassfish.osgijavaeebase.OSGiBundleArchive.iterator(OSGiBundleArchive.java:329)
at org.glassfish.osgijpa.JPABundleProcessor.discoverPxmls(JPABundleProcessor.java:99)
at org.glassfish.osgijpa.JPABundleProcessor.isJPABundle(JPABundleProcessor.java:90)
at org.glassfish.osgijpa.JPAExtender.bundleChanged(JPAExtender.java:117)
at org.apache.felix.framework.util.EventDispatcher.invokeBundleListenerCallback(EventDispatcher.java:868)
at org.apache.felix.framework.util.EventDispatcher.fireEventImmediately(EventDispatcher.java:789)
at org.apache.felix.framework.util.EventDispatcher.fireBundleEvent(EventDispatcher.java:514)
at org.apache.felix.framework.Felix.fireBundleEvent(Felix.java:4408)
at org.apache.felix.framework.Felix.installBundle(Felix.java:3048)
at org.apache.felix.framework.BundleContextImpl.installBundle(BundleContextImpl.java:165)
at org.apache.felix.fileinstall.internal.DirectoryWatcher.installOrUpdateBundle(DirectoryWatcher.java:981)
at org.apache.felix.fileinstall.internal.DirectoryWatcher.install(DirectoryWatcher.java:895)
at org.apache.felix.fileinstall.internal.DirectoryWatcher.install(DirectoryWatcher.java:808)
at org.apache.felix.fileinstall.internal.DirectoryWatcher.process(DirectoryWatcher.java:446)
at org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:263)
Caused by: java.net.URISyntaxException: Illegal character in path at index 40: bundle://402.0:0/org/apache/fop/pdf/sRGB Color Space Profile.icm
at java.net.URI$Parser.fail(URI.java:2829)
at java.net.URI$Parser.checkChars(URI.java:3002)
at java.net.URI$Parser.parseHierarchical(URI.java:3086)
at java.net.URI$Parser.parse(URI.java:3034)
at java.net.URI.<init>(URI.java:595)
at java.net.URL.toURI(URL.java:938)
at org.glassfish.osgijavaeebase.OSGiBundleArchive.getEntryURI(OSGiBundleArchive.java:318)
... 17 more



 Comments   
Comment by Sanjeeb Sahoo [ 18/Feb/14 ]

Seems like a bug in Felix. Bundle.getEntry() is returning a URL with space char in it. Let me see if we can work around it in our code.

Comment by knut [ 18/Feb/14 ]

I was actually first going to file this as a Felix bug, but then based on the stack trace elements I decided that it was probably more a Glassfish issue.

Let me know if you want me to also report this as a Felix bug, so that it can also get fixed there.

Comment by Sanjeeb Sahoo [ 19/Feb/14 ]

Yes, try reporting the issue in Felix. If they fix it, well and good, else let me know so that we can think of a work around in our end.

Comment by knut [ 19/Feb/14 ]

Please note that i filed issue https://issues.apache.org/jira/browse/FELIX-4429 against Felix.

Meanwhile I am wondering what the exact impact is of this problem. AFAICT the bundle was still resolved. But will this mean that some entries won't be accessible or are you aware of any problems this might cause? If so it may make sense to create a temporary workaround in Glassfish until a Felix version is used which fixes this problem.

Comment by Sanjeeb Sahoo [ 25/Feb/14 ]

If the bundle contained any META-INF/persistence.xml files and if you wanted them to be processed by GlassFish OSGi/JPA module, then that won't happen due to this exception. Otherwise there is not any issue. Since you are not activating the bundle, I doubt you wanted its persistence.xml to be processed. So, I would say it's not a serious issue for now.

Comment by knut [ 25/Feb/14 ]

Thank you for the explanation. At least in my case this is not a problem.





[GLASSFISH-14620] Enable cluster support for hybrid apps Created: 11/Nov/10  Updated: 20/Oct/13

Status: Open
Project: glassfish
Component/s: OSGi-JavaEE
Affects Version/s: 3.1
Fix Version/s: None

Type: Task Priority: Critical
Reporter: Sanjeeb Sahoo Assignee: Sanjeeb Sahoo
Resolution: Unresolved Votes: 3
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 14,620

 Description   

We need to add entries in domain.xml for hybrid apps for hybrid apps to take
advantage of glassfish cluster.



 Comments   
Comment by ancoron [ 10/Sep/11 ]

Hi,

I'm really looking forward for the OSGi/Cluster support. However, I assumed that (at least) OSGi/EJB bundles deployed into a cluster should automatically benefit from the EJB-clustering.

I really should test that, but didn't manage to get some spare time in this area.

So exactly what does this issue mean?

Comment by TangYong [ 06/Sep/12 ]

I agree with Ancoron and firstly need to know what is the mean of deploying a osgi app into Cluster.

Wish sahoo can explain in details.

Comment by TangYong [ 13/Oct/12 ]

Sahoo, I forgot a point about the task, I want to ask the relation between the task and GLASSFISH-11700.
If GLASSFISH-11700 has not been implemented, I think that the task can not be implemented, in addition, what ancoron said ejb-clustering is not considered until implemeting GLASSFISH-11700 (that is to say, implementing osgi cluster deployment).

In addition, about osgi ejb-clustering self, on current osgi alliance ejb/osgi draft, it is not stated because the feature is not standardard and belongs to vendor behavior, (ejb3.x is not also stating the point), if needing to implement it, I think that we must consider current ejb container's implementing, then properly define osgi ejb clustering's behavior.

Comment by zhsc [ 20/Oct/13 ]

Any thoughts on feasibility / progress / likelihood of this functionality.

It seems the hold up is the behavior of these hybrid apps in a cluster environment is undefined in both osgi and javaee specs?

Is it possible today to deploy bundles to multiple managed servers in a domain (i.e. from autodeploy/bundles) at all? i.e. at least be managed together even if not fully "clustered"?





[GLASSFISH-20861] OSGi WAB Deployment breaks signature Created: 18/Oct/13  Updated: 18/Oct/13

Status: Open
Project: glassfish
Component/s: OSGi-JavaEE
Affects Version/s: 3.1.2.2
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Jochen Kraushaar Assignee: Sanjeeb Sahoo
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

When an OSGi Web Application Bundle with files in directory WEB-INF/classes is installed, the GlassFish installation process packages the Class files in a new JAR file. If the WAB is signed, the signature is broken by this process. Stacktrace:

[#|2013-10-17T14:15:49.380+0200|SEVERE|glassfish3.1.2|org.glassfish.osgijavaeebase|_ThreadID=112;_ThreadName=Thread-2;|Exception while processing WEB-INF/classes/de/doubleslash/xyz/Abc.class inside file:/tmp/osgiapp1347945572572955553/WEB-INF/lib/Bundle305.jar of size 3.952
java.lang.SecurityException: Invalid signature file digest for Manifest main attributes
	at sun.security.util.SignatureFileVerifier.processImpl(SignatureFileVerifier.java:240)
	at sun.security.util.SignatureFileVerifier.process(SignatureFileVerifier.java:193)
	at java.util.jar.JarVerifier.processEntry(JarVerifier.java:305)
	at java.util.jar.JarVerifier.update(JarVerifier.java:216)
	at java.util.jar.JarFile.initializeVerifier(JarFile.java:345)
	at java.util.jar.JarFile.getInputStream(JarFile.java:412)
	at com.sun.enterprise.deployment.deploy.shared.InputJarArchive.getEntry(InputJarArchive.java:244)
	at com.sun.enterprise.v3.server.ReadableArchiveScannerAdapter.handleEntry(ReadableArchiveScannerAdapter.java:166)
	at com.sun.enterprise.v3.server.ReadableArchiveScannerAdapter.onSelectedEntries(ReadableArchiveScannerAdapter.java:133)
	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.run(FutureTask.java:262)
	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:724)
|#]

Workaround: Package class files as JAR file by hand and store it under WEB-INF/lib. Add library to Bundle-ClassPath MANIFEST entry.






[GLASSFISH-20859] osgi-jpa component breaks JAR signature Created: 18/Oct/13  Updated: 18/Oct/13

Status: Open
Project: glassfish
Component/s: OSGi-JavaEE
Affects Version/s: 3.1.2.2
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Jochen Kraushaar Assignee: Sanjeeb Sahoo
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

I have an OSGi bundle containing JPA entities and a persistence.xml. The OSGi bundle is signed by maven-jarsigner-plugin for security reasons. When I am trying to install this bundle, I get the following Stacktrace:

[#|2013-10-17T10:32:09.854+0200|WARNING|glassfish3.1.2|org.glassfish.osgijpa|_ThreadID=61;_ThreadName=Thread-2;|Failed to enhance bundle having id 264
org.osgi.framework.BundleException: Update of bundle xyz [264] failed.
	at org.apache.felix.framework.Felix.updateBundle(Felix.java:2251)
	at org.apache.felix.framework.BundleImpl.update(BundleImpl.java:962)
	at org.glassfish.osgijpa.JPAExtender.updateBundle(JPAExtender.java:191)
	at org.glassfish.osgijpa.JPAExtender.enhance(JPAExtender.java:175)
	at org.glassfish.osgijpa.JPAExtender.access$100(JPAExtender.java:64)
	at org.glassfish.osgijpa.JPAExtender$1.run(JPAExtender.java:130)
	at org.glassfish.osgijpa.JPAExtender.executeTask(JPAExtender.java:203)
	at org.glassfish.osgijpa.JPAExtender.bundleChanged(JPAExtender.java:139)
	at org.apache.felix.framework.util.EventDispatcher$3.run(EventDispatcher.java:861)
	at java.security.AccessController.doPrivileged(Native Method)
	at org.apache.felix.framework.util.EventDispatcher.invokeBundleListenerCallback(EventDispatcher.java:858)
	at org.apache.felix.framework.util.EventDispatcher.fireEventImmediately(EventDispatcher.java:789)
	at org.apache.felix.framework.util.EventDispatcher.fireBundleEvent(EventDispatcher.java:514)
	at org.apache.felix.framework.Felix.fireBundleEvent(Felix.java:4249)
	at org.apache.felix.framework.Felix.installBundle(Felix.java:2881)
	at org.apache.felix.framework.BundleContextImpl.installBundle(BundleContextImpl.java:157)
	at org.apache.felix.framework.BundleContextImpl.installBundle(BundleContextImpl.java:138)
	at org.apache.felix.gogo.command.Basic.start(Basic.java:753)
	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:606)
	at org.apache.felix.gogo.runtime.Reflective.method(Reflective.java:136)
	at org.apache.felix.gogo.runtime.CommandProxy.execute(CommandProxy.java:82)
	at org.apache.felix.gogo.runtime.Closure.executeCmd(Closure.java:469)
	at org.apache.felix.gogo.runtime.Closure.executeStatement(Closure.java:395)
	at org.apache.felix.gogo.runtime.Pipe.run(Pipe.java:108)
	at org.apache.felix.gogo.runtime.Closure.execute(Closure.java:183)
	at org.apache.felix.gogo.runtime.Closure.execute(Closure.java:120)
	at org.apache.felix.gogo.runtime.CommandSessionImpl.execute(CommandSessionImpl.java:89)
	at org.apache.felix.gogo.shell.Console.run(Console.java:62)
	at org.apache.felix.gogo.shell.Shell.console(Shell.java:203)
	at org.apache.felix.gogo.shell.Shell.gosh(Shell.java:128)
	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:606)
	at org.apache.felix.gogo.runtime.Reflective.method(Reflective.java:136)
	at org.apache.felix.gogo.runtime.CommandProxy.execute(CommandProxy.java:82)
	at org.apache.felix.gogo.runtime.Closure.executeCmd(Closure.java:469)
	at org.apache.felix.gogo.runtime.Closure.executeStatement(Closure.java:395)
	at org.apache.felix.gogo.runtime.Pipe.run(Pipe.java:108)
	at org.apache.felix.gogo.runtime.Closure.execute(Closure.java:183)
	at org.apache.felix.gogo.runtime.Closure.execute(Closure.java:120)
	at org.apache.felix.gogo.runtime.CommandSessionImpl.execute(CommandSessionImpl.java:89)
	at org.apache.felix.shell.remote.Shell.startGogoShell(Shell.java:108)
	at org.apache.felix.shell.remote.Shell.run(Shell.java:81)
	at java.lang.Thread.run(Thread.java:724)
Caused by: java.lang.SecurityException: Invalid signature file digest for Manifest main attributes
	at sun.security.util.SignatureFileVerifier.processImpl(SignatureFileVerifier.java:240)
	at sun.security.util.SignatureFileVerifier.process(SignatureFileVerifier.java:193)
	at java.util.jar.JarVerifier.processEntry(JarVerifier.java:262)
	at java.util.jar.JarVerifier.update(JarVerifier.java:216)
	at java.util.jar.JarInputStream.read(JarInputStream.java:212)
	at java.util.zip.ZipInputStream.closeEntry(ZipInputStream.java:139)
	at java.util.zip.ZipInputStream.getNextEntry(ZipInputStream.java:117)
	at java.util.jar.JarInputStream.getNextEntry(JarInputStream.java:142)
	at java.util.jar.JarInputStream.getNextJarEntry(JarInputStream.java:179)
	at org.apache.felix.framework.security.verifier.BundleDNParser.getCertificates(BundleDNParser.java:292)
	at org.apache.felix.framework.security.verifier.BundleDNParser._getDNChains(BundleDNParser.java:240)
	at org.apache.felix.framework.security.verifier.BundleDNParser.checkDNChains(BundleDNParser.java:148)
	at org.apache.felix.framework.SecurityProviderImpl.checkBundle(SecurityProviderImpl.java:64)
	at org.apache.felix.framework.BundleImpl.addRevision(BundleImpl.java:1170)
	at org.apache.felix.framework.BundleImpl.revise(BundleImpl.java:1130)
	at org.apache.felix.framework.Felix.updateBundle(Felix.java:2113)
	... 47 more
|#]

I traced the problem back to the osgi-jpa component which scans the installed bundles for JPA information and trys to weave the JPA entities. Afterwards the MANIFEST is enhanced by the following to entries:

  • GlassFish-StaticallyWeaved: true
  • DynamicImport-Package: org.eclipse.persistence.*

This will break the JAR signature. As a result I am unable to install signed bundles.

Workaround: Weave the JPA entities during build and add the MANIFEST entries by hand before the bundle is signed.






[GLASSFISH-19837] java.lang.IllegalStateException( at org.jvnet.hk2.internal.SystemDescriptor.checkState(SystemDescriptor.java:464)) alway happened while executing fighterfish it tests Created: 12/Mar/13  Updated: 23/Apr/13

Status: In Progress
Project: glassfish
Component/s: OSGi, OSGi-JavaEE
Affects Version/s: 3.1.2
Fix Version/s: None

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


 Description   

While executing fighterfish it tests, the following exception always happened although not affecting test result.

java.lang.IllegalStateException
at org.jvnet.hk2.internal.SystemDescriptor.checkState(SystemDescriptor.java:464)
at org.jvnet.hk2.internal.SystemDescriptor.getScopeAnnotation(SystemDescriptor.java:351)
at org.jvnet.hk2.internal.ServiceHandleImpl.destroy(ServiceHandleImpl.java:144)
at com.sun.enterprise.server.logging.LogManagerService.preDestroy(LogManagerService.java:700)
at org.jvnet.hk2.internal.ClazzCreator.preDestroyMe(ClazzCreator.java:277)
at org.jvnet.hk2.internal.ClazzCreator.dispose(ClazzCreator.java:332)
at org.jvnet.hk2.internal.SystemDescriptor.dispose(SystemDescriptor.java:460)
at org.glassfish.hk2.runlevel.internal.RunLevelContext.deactivate(RunLevelContext.java:148)
at org.glassfish.hk2.runlevel.utilities.RunLevelControllerImpl$DefaultActivator.deactivate(RunLevelControllerImpl.java:365)
at org.glassfish.hk2.runlevel.utilities.RunLevelControllerImpl$Worker.deactivateRunLevel(RunLevelControllerImpl.java:812)
at org.glassfish.hk2.runlevel.utilities.RunLevelControllerImpl$Worker.downActiveRecorder(RunLevelControllerImpl.java:709)
at org.glassfish.hk2.runlevel.utilities.RunLevelControllerImpl$Worker.down(RunLevelControllerImpl.java:725)
at org.glassfish.hk2.runlevel.utilities.RunLevelControllerImpl$Worker.run(RunLevelControllerImpl.java:639)
Completed shutdown of GlassFish runtime
at org.glassfish.hk2.runlevel.utilities.RunLevelControllerImpl$SyncProceedToWorker.proceedTo(RunLevelControllerImpl.java:896)
at org.glassfish.hk2.runlevel.utilities.RunLevelControllerImpl.proceedTo(RunLevelControllerImpl.java:559)
at org.glassfish.hk2.runlevel.utilities.RunLevelControllerImpl.proceedTo(RunLevelControllerImpl.java:339)
at com.sun.enterprise.v3.server.AppServerStartup.stop(AppServerStartup.java:347)
at com.sun.enterprise.glassfish.bootstrap.GlassFishImpl.stop(GlassFishImpl.java:88)
at com.sun.enterprise.glassfish.bootstrap.GlassFishImpl.dispose(GlassFishImpl.java:97)
at com.sun.enterprise.glassfish.bootstrap.GlassFishDecorator.dispose(GlassFishDecorator.java:73)
at com.sun.enterprise.glassfish.bootstrap.osgi.GlassFishMainActivator.stop(GlassFishMainActivator.java:260)
at org.apache.felix.framework.util.SecureAction.stopActivator(SecureAction.java:667)
at org.apache.felix.framework.Felix.stopBundle(Felix.java:2518)
org.ops4j.pax.logging.pax-logging-api[org.ops4j.pax.logging.internal.Activator] : Disabling SLF4J API support.
org.ops4j.pax.logging.pax-logging-api[org.ops4j.pax.logging.internal.Activator] : Disabling Jakarta Commons Logging API support.
org.ops4j.pax.logging.pax-logging-api[org.ops4j.pax.logging.internal.Activator] : Disabling Log4J API support.
org.ops4j.pax.logging.pax-logging-api[org.ops4j.pax.logging.internal.Activator] : Disabling Avalon Logger API support.
org.ops4j.pax.logging.pax-logging-api[org.ops4j.pax.logging.internal.Activator] : Disabling JULI Logger API support.
at org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1297)
at org.apache.felix.framework.FrameworkStartLevelImpl.run(FrameworkStartLevelImpl.java:304)
at java.lang.Thread.run(Thread.java:722)
[#|2013-03-12T20:01:40.781+0900|INFO|glassfish 4.0|javax.enterprise.system.core|_ThreadID=241;_ThreadName=FelixStartLevel;_TimeMillis=1363086100781;_LevelValue=800;_MessageID=NCLS-CORE-0013;ClassName=com.sun.enterprise.v3.server.AppServerStartup;MethodName=stop;|Shutdown procedure finished|#]



 Comments   
Comment by TangYong [ 13/Mar/13 ]

Using the newest gf trunk, the exception has a litter change as following:

java.lang.IllegalStateException
at org.jvnet.hk2.internal.SystemDescriptor.checkState(SystemDescriptor.java:464)
at org.jvnet.hk2.internal.SystemDescriptor.getScopeAnnotation(SystemDescriptor.java:351)
at org.jvnet.hk2.internal.ServiceHandleImpl.destroy(ServiceHandleImpl.java:144)
Completed shutdown of GlassFish runtime
org.ops4j.pax.logging.pax-logging-api[org.ops4j.pax.logging.internal.Activator] : Disabling SLF4J API support.
at com.sun.enterprise.server.logging.LogManagerService.preDestroy(LogManagerService.java:700)
org.ops4j.pax.logging.pax-logging-api[org.ops4j.pax.logging.internal.Activator] : Disabling Jakarta Commons Logging API support.
org.ops4j.pax.logging.pax-logging-api[org.ops4j.pax.logging.internal.Activator] : Disabling Log4J API support.
at org.jvnet.hk2.internal.ClazzCreator.preDestroyMe(ClazzCreator.java:295)
org.ops4j.pax.logging.pax-logging-api[org.ops4j.pax.logging.internal.Activator] : Disabling Avalon Logger API support.
at org.jvnet.hk2.internal.ClazzCreator.dispose(ClazzCreator.java:350)
org.ops4j.pax.logging.pax-logging-api[org.ops4j.pax.logging.internal.Activator] : Disabling JULI Logger API support.
at org.jvnet.hk2.internal.SystemDescriptor.dispose(SystemDescriptor.java:460)
at org.glassfish.hk2.runlevel.internal.RunLevelContext.deactivate(RunLevelContext.java:148)
at org.glassfish.hk2.runlevel.utilities.RunLevelControllerImpl$DefaultActivator.deactivate(RunLevelControllerImpl.java:365)
at org.glassfish.hk2.runlevel.utilities.RunLevelControllerImpl$Worker.deactivateRunLevel(RunLevelControllerImpl.java:812)
at org.glassfish.hk2.runlevel.utilities.RunLevelControllerImpl$Worker.downActiveRecorder(RunLevelControllerImpl.java:709)
at org.glassfish.hk2.runlevel.utilities.RunLevelControllerImpl$Worker.down(RunLevelControllerImpl.java:725)
at org.glassfish.hk2.runlevel.utilities.RunLevelControllerImpl$Worker.run(RunLevelControllerImpl.java:639)
at org.glassfish.hk2.runlevel.utilities.RunLevelControllerImpl$SyncProceedToWorker.proceedTo(RunLevelControllerImpl.java:896)
at org.glassfish.hk2.runlevel.utilities.RunLevelControllerImpl.proceedTo(RunLevelControllerImpl.java:559)
at org.glassfish.hk2.runlevel.utilities.RunLevelControllerImpl.proceedTo(RunLevelControllerImpl.java:339)
at com.sun.enterprise.v3.server.AppServerStartup.stop(AppServerStartup.java:350)
at com.sun.enterprise.glassfish.bootstrap.GlassFishImpl.stop(GlassFishImpl.java:88)
at com.sun.enterprise.glassfish.bootstrap.GlassFishImpl.dispose(GlassFishImpl.java:97)
at com.sun.enterprise.glassfish.bootstrap.GlassFishDecorator.dispose(GlassFishDecorator.java:73)
at com.sun.enterprise.glassfish.bootstrap.osgi.GlassFishMainActivator.stop(GlassFishMainActivator.java:257)
at org.apache.felix.framework.util.SecureAction.stopActivator(SecureAction.java:667)
at org.apache.felix.framework.Felix.stopBundle(Felix.java:2518)
at org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1297)
at org.apache.felix.framework.FrameworkStartLevelImpl.run(FrameworkStartLevelImpl.java:304)
at java.lang.Thread.run(Thread.java:722)

Comment by TangYong [ 13/Mar/13 ]

By debugging, while disposing com.sun.enterprise.server.logging.LogManagerService, and running the following logic(locator.resolveContext(root.getScopeAnnotation())),

org.jvnet.hk2.internal.ServiceHandleImpl.java
@Override
    public boolean isActive() {
        // No lock needed, nothing changes state
        if (serviceDestroyed) return false;
        if (serviceSet) return true;
        
        try {
            Context<?> context = locator.resolveContext(root.getScopeAnnotation());
            return context.containsKey(root);
        }

I have found that root's status is as following:

SystemDescriptor(
implementation=com.sun.enterprise.server.logging.SyslogHandler
contracts=

{com.sun.enterprise.server.logging.SyslogHandler,java.util.logging.Handler}

scope=javax.inject.Singleton
qualifiers={}
descriptorType=CLASS
descriptorVisibility=NORMAL
metadata=Bundle-SymbolicName=

{org.glassfish.main.core.logging}

,Bundle-Version=

{4.0.0.SNAPSHOT}

rank=0
loader=OsgiPopulatorPostProcessor.HK2Loader(OSGiModuleImpl:: Bundle = [org.glassfish.main.core.logging [201]], State = [READY],32729594)
proxiable=null
analysisName=null
id=1135
locatorId=0
identityHashCode=1681041
reified=false)

Among them, reified is false, then, org.jvnet.hk2.internal.SystemDescriptor.checkState will throw IllegalStateException.

So, I doubted whether log configuration is not set rightly in pax exam?

Needing to confirm in depth.

Comment by Sanjeeb Sahoo [ 23/Apr/13 ]

Tang,

I don't recollect seeing this particular exception although I have seen some exception while server shuts down during fighterfish test execution. So, I would like to know if this is a new exception. If so, I would classify this as a regression and assign it to someone like John Wells to look into it instead of you investigating it. Clearly we have not changes anything in fighterfish for this exception to occur.

Thanks,
Sahoo

Comment by TangYong [ 23/Apr/13 ]

Sahoo

This is not a new exception and on my env, each time while server shuts down during fighterfish test execution's end,
I can always see the exception. In addition, while switching into httpclient lib, the exception is still there. However, the exception info has a litter different from the issue

java.lang.IllegalStateException
at org.jvnet.hk2.internal.SystemDescriptor.checkState(SystemDescriptor.java:480)
at org.jvnet.hk2.internal.SystemDescriptor.getScopeAnnotation(SystemDescriptor.java:361)
at org.jvnet.hk2.internal.ServiceHandleImpl.destroy(ServiceHandleImpl.java:144)
at com.sun.enterprise.server.logging.LogManagerService.preDestroy(LogManagerService.java:700)
at org.jvnet.hk2.internal.ClazzCreator.preDestroyMe(ClazzCreator.java:294)
at org.jvnet.hk2.internal.ClazzCreator.dispose(ClazzCreator.java:358)
at org.jvnet.hk2.internal.SystemDescriptor.dispose(SystemDescriptor.java:473)
at org.glassfish.hk2.runlevel.internal.AsyncRunLevelContext.destroyOne(AsyncRunLevelContext.java:191)
at org.jvnet.hk2.internal.ServiceHandleImpl.destroy(ServiceHandleImpl.java:159)
at org.glassfish.hk2.runlevel.internal.CurrentTaskFuture$DownAllTheWay.run(CurrentTaskFuture.java:583)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
at java.lang.Thread.run(Thread.java:722)
[#|2013-04-22T23:01:12.893+0900|INFO|glassfish 4.0|javax.enterprise.system.core|_ThreadID=287;_ThreadName=FelixStartLevel;_TimeMillis=1366639272893;_LevelValue=800;_MessageID=NCLS-CORE-00013;ClassName=com.sun.enterprise.v3.server.AppServerStartup;MethodName=stop;|
Shutdown procedure finished|#]

So, I also think that I am not a right person to investigate the exception. Please assign to jwells to investigate it.

Thanks
Tang





[GLASSFISH-18836] [osgi/cdi] Regression: An OSGi Service cannot be injected into a JAX-RS resource Created: 25/Jun/12  Updated: 29/Mar/13

Status: Open
Project: glassfish
Component/s: jax-rs, OSGi-JavaEE
Affects Version/s: 4.0_b41
Fix Version/s: None

Type: Bug Priority: Critical
Reporter: Sanjeeb Sahoo Assignee: Jakub Podlesak
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Java Archive File sample.uas.api.jar     File sample.uas.simplejaxrs.war     Java Archive File sample.uas.simpleservice.jar     Text File server.log    
Issue Links:
Dependency
depends on JERSEY-1024 Integration with CDI Resolved

 Description   

This is a regression caused by integration of Jersey 2.0. We have a test that injects an OSGi service into a JAX-RS resource and that's broken. It works fine with 4.0-b41. The steps to reproduce are:

  1. Start gf in foreground so that you can monitor the log messages
    0. asadmin start-domain -v

1. # Copy the attached 3 jars to autodpeloy/bundles/ & wait for a few seconds to deploy.
cp sample.uas.api.jar sample.uas.simpleservice.jar sample.uas.simplejaxrs.jar domain1/autodeploy/bundles/

2. Run the following command which requests the JAX-RS resource:
wget -O - "http://localhost:8080/simplejaxrs/register?name=admin&password=admin"

You will see the following exception in server.log:

[#|2012-06-25T07:37:25.772+0530|SEVERE|44.0|org.glassfish.jersey.server.ApplicationHandler|_ThreadID=14;_ThreadName=http-listener-1(1);|injection failed on org.glassfish.fighterfish.sample.uas.simplejaxrs.Register.uas with interface org.glassfish.fighterfish.sample.uas.api.UserAuthService
org.jvnet.hk2.component.UnsatisfiedDependencyException: injection failed on org.glassfish.fighterfish.sample.uas.simplejaxrs.Register.uas with interface org.glassfish.fighterfish.sample.uas.api.UserAuthService
at org.jvnet.hk2.component.InjectionManager.syncDoInject(InjectionManager.java:210)
at org.jvnet.hk2.component.InjectionManager.inject(InjectionManager.java:103)
at com.sun.hk2.component.AbstractCreatorImpl.inject(AbstractCreatorImpl.java:127)
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.AbstractInhabitantImpl.get(AbstractInhabitantImpl.java:135)
at org.jvnet.hk2.component.Habitat.getByType(Habitat.java:1390)
at org.jvnet.hk2.component.Habitat.inject(Habitat.java:1199)
at org.glassfish.jersey.server.model.MethodHandler$ClassBasedMethodHandler.getInstance(MethodHandler.java:170)
at org.glassfish.jersey.server.internal.routing.PushMethodHandlerRouter.apply(PushMethodHandlerRouter.java:101)
at org.glassfish.jersey.server.internal.routing.RoutingStage._apply(RoutingStage.java:116)
at org.glassfish.jersey.server.internal.routing.RoutingStage._apply(RoutingStage.java:119)
at org.glassfish.jersey.server.internal.routing.RoutingStage._apply(RoutingStage.java:119)
at org.glassfish.jersey.server.internal.routing.RoutingStage._apply(RoutingStage.java:119)
at org.glassfish.jersey.server.internal.routing.RoutingStage.apply(RoutingStage.java:105)
at org.glassfish.jersey.server.internal.routing.RoutingStage.apply(RoutingStage.java:65)
at org.glassfish.jersey.process.internal.RequestInvoker$AcceptingInvoker.apply(RequestInvoker.java:272)
at org.glassfish.jersey.process.internal.AsyncInflectorAdapter.apply(AsyncInflectorAdapter.java:150)
at org.glassfish.jersey.process.internal.RequestInvoker$2.run(RequestInvoker.java:234)
at org.glassfish.jersey.process.internal.RequestScope.runInScope(RequestScope.java:237)
at org.glassfish.jersey.process.internal.RequestInvoker$3.run(RequestInvoker.java:245)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at com.google.common.util.concurrent.MoreExecutors$SameThreadExecutorService.execute(MoreExecutors.java:253)
at com.google.common.util.concurrent.AbstractListeningExecutorService.submit(AbstractListeningExecutorService.java:44)
at com.google.common.util.concurrent.AbstractListeningExecutorService.submit(AbstractListeningExecutorService.java:41)
at org.glassfish.jersey.process.internal.RequestInvoker.apply(RequestInvoker.java:241)
at org.glassfish.jersey.server.ApplicationHandler$6.run(ApplicationHandler.java:618)
at org.glassfish.jersey.process.internal.RequestScope.runInScope(RequestScope.java:260)
at org.glassfish.jersey.server.ApplicationHandler.apply(ApplicationHandler.java:610)
at org.glassfish.jersey.server.ApplicationHandler.apply(ApplicationHandler.java:583)
at org.glassfish.jersey.servlet.WebComponent.service(WebComponent.java:261)
at org.glassfish.jersey.servlet.ServletContainer.service(ServletContainer.java:338)
at org.glassfish.jersey.servlet.ServletContainer.service(ServletContainer.java:304)
at org.glassfish.jersey.servlet.ServletContainer.service(ServletContainer.java:190)
at org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1593)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:285)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:660)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:600)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:161)
at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:337)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:240)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:172)
at org.glassfish.grizzly.http.server.HttpHandler.doHandle(HttpHandler.java:164)
at org.glassfish.grizzly.http.server.HttpServerFilter.handleRead(HttpServerFilter.java:169)
at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:265)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:200)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:134)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:112)
at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:78)
at org.glassfish.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(TCPNIOTransport.java:815)
at org.glassfish.grizzly.strategies.AbstractIOStrategy.fireIOEvent(AbstractIOStrategy.java:112)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.run0(WorkerThreadIOStrategy.java:115)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.access$100(WorkerThreadIOStrategy.java:55)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy$WorkerThreadRunnable.run(WorkerThreadIOStrategy.java:135)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:567)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:547)
at java.lang.Thread.run(Thread.java:662)

#]


 Comments   
Comment by Sanjeeb Sahoo [ 25/Jun/12 ]

Test jars. For source code, please check out:
https://svn.java.net/svn/glassfish~svn/trunk/fighterfish/sample/uas

Comment by TangYong [ 12/Sep/12 ]

Now, the problem is not still fixed. Based on current gf trunk snapshot, once running "http://localhost:8080/simplejaxrs/register?name=admin&password=admin", the sample can not work normally and the following exception[1] happened on server.log (similar to reporter). As a whole, It should result from "JERSEY Integration with CDI".

In addition, the bundles which I used contained the following bundles[2]

[1] pl. see the attachment(server.log)
[2] bundles on another test case
(1) sample.uas.entities.jar
(2) sample.uas.api.jar
(3) sample.uas.ejbservice2.jar
(4) sample.uas.simplejaxrs.war

I think that firstly we need to ask the status of JERSEY-1024.

Comment by Sanjeeb Sahoo [ 12/Sep/12 ]

No, the bug is not fixed and that's why it is still open. Jersey team will fix it before 4.0 gets released.

Comment by Sanjeeb Sahoo [ 23/Mar/13 ]

I stil see the issue using 4.0-b81

Comment by Sanjeeb Sahoo [ 24/Mar/13 ]

Jakub,

I tried using glassfish.zip from your area[1], but it still does not work for me. Here is how you can build the test cases whose binaries have been attached in this issue:

svn co https://svn.java.net/svn/glassfish~svn/trunk/fighterfish/sample/uas

mvn clean install

cp api/target/sample.uas.api.jar simplejaxrs/target/sample.uas.simplejaxrs.war simpleservice/target/sample.uas.simpleservice.jar .../domain1/autodeploy/bundles/

Start glassfish

Open http://localhost:8080/simplejaxrs/register?name=admin&password=admin in your browser. You will see following exception:

[#|2013-03-23T23:25:28.294-0700|SEVERE|glassfish 4.0|org.glassfish.jersey.server.ServerRuntime$Responder|_ThreadID=26;_ThreadName=http-listener-1(1);_TimeMillis=1364106328294;_LevelValue=1000;|
An exception mapping did not successfully produce and processed a response. Logging the original error.
org.glassfish.jersey.server.internal.process.MappableException: A MultiException has 1 exceptions. They are:
1. org.glassfish.hk2.api.UnsatisfiedDependencyException: There was no object available for injection at Injectee(requiredType=UserAuthService,parent=Register,qualifiers=

{@org.glassfish.osgicdi.OSGiService(dynamic=true, waitTimeout=-1, serviceCriteria=)}),position=-1,optional=false,self=false,unqualified=null,798083002)

at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.invoke(AbstractJavaResourceMethodDispatcher.java:138)
at org.glassfish.jersey.server.model.internal.JavaResourceMethodDispatcherProvider$TypeOutInvoker.doDispatch(JavaResourceMethodDispatcherProvider.java:195)
at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.dispatch(AbstractJavaResourceMethodDispatcher.java:91)
at org.glassfish.jersey.server.model.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:346)
at org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:341)
at org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:101)
at org.glassfish.jersey.server.ServerRuntime$1.run(ServerRuntime.java:217)
at org.glassfish.jersey.internal.Errors$1.call(Errors.java:231)
at org.glassfish.jersey.internal.Errors$1.call(Errors.java:227)
at org.glassfish.jersey.internal.Errors.process(Errors.java:275)
at org.glassfish.jersey.internal.Errors.process(Errors.java:257)
at org.glassfish.jersey.internal.Errors.process(Errors.java:227)
at org.glassfish.jersey.process.internal.RequestScope.runInScope(RequestScope.java:317)
at org.glassfish.jersey.server.ServerRuntime.process(ServerRuntime.java:191)
at org.glassfish.jersey.server.ApplicationHandler.handle(ApplicationHandler.java:819)
at org.glassfish.jersey.servlet.WebComponent.service(WebComponent.java:311)
at org.glassfish.jersey.servlet.ServletContainer.service(ServletContainer.java:372)
at org.glassfish.jersey.servlet.ServletContainer.service(ServletContainer.java:335)
at org.glassfish.jersey.servlet.ServletContainer.service(ServletContainer.java:218)
at org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1682)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:318)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:160)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:734)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:673)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:175)
at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:357)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:260)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:188)
at org.glassfish.grizzly.http.server.HttpHandler.runService(HttpHandler.java:191)
at org.glassfish.grizzly.http.server.HttpHandler.doHandle(HttpHandler.java:168)
at org.glassfish.grizzly.http.server.HttpServerFilter.handleRead(HttpServerFilter.java:189)
at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:288)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:206)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:136)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:114)
at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77)
at org.glassfish.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(TCPNIOTransport.java:838)
at org.glassfish.grizzly.strategies.AbstractIOStrategy.fireIOEvent(AbstractIOStrategy.java:113)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.run0(WorkerThreadIOStrategy.java:115)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.access$100(WorkerThreadIOStrategy.java:55)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy$WorkerThreadRunnable.run(WorkerThreadIOStrategy.java:135)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:564)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:544)
at java.lang.Thread.run(Thread.java:722)
Caused by: A MultiException has 1 exceptions. They are:
1. org.glassfish.hk2.api.UnsatisfiedDependencyException: There was no object available for injection at Injectee(requiredType=UserAuthService,parent=Register,qualifiers={@org.glassfish.osgicdi.OSGiService(dynamic=true, waitTimeout=-1, serviceCriteria=)}

),position=-1,optional=false,self=false,unqualified=null,798083002)

at org.jvnet.hk2.internal.ThreeThirtyResolver.resolve(ThreeThirtyResolver.java:74)
at org.jvnet.hk2.internal.Utilities.justInject(Utilities.java:771)
at org.jvnet.hk2.internal.ServiceLocatorImpl.inject(ServiceLocatorImpl.java:780)
at org.glassfish.jersey.gf.cdi.CdiComponentProvider$1.inject(CdiComponentProvider.java:256)
at org.jboss.weld.bean.ManagedBean.create(ManagedBean.java:158)
at org.jboss.weld.context.AbstractContext.get(AbstractContext.java:103)
at org.jboss.weld.bean.proxy.ContextBeanInstance.getInstance(ContextBeanInstance.java:93)
at org.jboss.weld.bean.proxy.ProxyMethodHandler.invoke(ProxyMethodHandler.java:82)
at org.glassfish.fighterfish.sample.uas.simplejaxrs.Register$Proxy$_$$_WeldClientProxy.getLogin(Unknown Source)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at org.glassfish.jersey.server.model.internal.ResourceMethodInvocationHandlerFactory$1.invoke(ResourceMethodInvocationHandlerFactory.java:81)
at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.invoke(AbstractJavaResourceMethodDispatcher.java:125)
... 44 more
Caused by: org.glassfish.hk2.api.UnsatisfiedDependencyException: There was no object available for injection at Injectee(requiredType=UserAuthService,parent=Register,qualifiers=

{@org.glassfish.osgicdi.OSGiService(dynamic=true, waitTimeout=-1, serviceCriteria=)}

),position=-1,optional=false,self=false,unqualified=null,798083002)
... 59 more

#]

Sahoo

[1] http://sysifos-sol.cz.oracle.com/hudson/view/Jersey%202/view/GF%20Integration/job/jersey2-gf4-integration/lastSuccessfulBuild/artifact/gf-main/appserver/distributions/glassfish/target/glassfish.zip

Comment by Jakub Podlesak [ 25/Mar/13 ]

Should be fixed in [1] now, will be integrated with jersey 2.0-rc1 into the gf main trunk

Comment by TangYong [ 29/Mar/13 ]

Sahoo,

The issue indeed has been fixed using recent trunk.





[GLASSFISH-19759] Support binding to OSGi services at deploy-time Created: 01/Mar/13  Updated: 25/Mar/13

Status: Open
Project: glassfish
Component/s: cdi, OSGi-JavaEE
Affects Version/s: None
Fix Version/s: future release

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

Tags: future-release, osgi-cdi, osgi-javaee

 Description   

Today the osgi-cdi portable extension supports the injection of OSGi Services into injection points marked with a custom OSGi Qualifier @OSGiService. Unfortunately this binds application components that reference these Services at deployment time to OSGi. There could be scenarios where the determination that a Service being injected is an OSGi Service, can be made at deployment-time based on the environment that the application component is part of. It would be good if we have the ability for a client of an OSGi Service to indicate that the Service is an OSGi Service at deploy-time.



 Comments   
Comment by Sivakumar Thyagarajan [ 01/Mar/13 ]

One approach to consider is providing a capability to a deployer (through a custom deployment-descriptor) to specify that a particular injection point is an OSGi Service injection point, and have the osgi-cdi portable extension read this descriptor and automatically add the @OSGiService qualifier at runtime.

Comment by TangYong [ 01/Mar/13 ]

Siva,

The capability is very important while combining PaaS model, and in PaaS, ServiceType can be extended into OSGi Service, then, an user can specify an OSGi Service as some PaaS Service in liking glassfish-services.xml.

Then, by discovering OSGi Service engine(to be implemented in the future), these OSGi Services meeting the user's requirements will be injected into client at runtime.

Tang

Comment by TangYong [ 25/Mar/13 ]

Seeing siva's said carefully, Siva's means should be following,

[Current OSGi/CDI portable extension]
Class A

{ @OSGiService B b ... }

The issue should wish to remove @OSGiService instead still using @Inject and adding some way to tell deployment to automatically determinate b is a OSGi Service.

Then, if using a custom deployment-descriptor, this is similar to Declarative Services, OK, let us to see this will bring what advantage?

Imaging a scene that some user has written a application which uses common cdi with well-designed interface, however, while he/she wants to switch another B's implementation and does not change any consumer's source, by this feature, he/she should implement.

Comment by Sivakumar Thyagarajan [ 25/Mar/13 ]

Yes, Tang.

The idea is to support the following:

  • Allow the development of POJOs and dependency injection not knowing during development time that a particular injection point would be satisfied through an OSGi Service. So in the above example, the application includes a POJO
    Class A { @Inject StockQuoteService b; }
  • At deployment time, we should allow the deployer to override the injection and indicate that the injection point A.b is an OSGi Service injection and provide the details through a custom deployment-descriptor. For instance here is a rough idea on how a deployer could state that the injectin point A.b is an OSGi Service.
    glassfish-osgi-cdi.xml:
    <osgi-service dynamic="true">
    <managed-bean name="A">
    <attribute name ="b"/>
    </managed-bean>
    </osgi-service>
  • The osgi-cdi portable extension must read this optional custom deployment-descriptor, and automatically at deployment time, make A.b have a qualified @OSGiService.

Does this help? All the above details are just ideas at this point in time. Let us evaluate how best to resolve this.





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

Tested with promoted b32


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

 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 ]

Thanks for reopening the issue, I was not allowed to.

Comment by Sanjeeb Sahoo [ 14/Dec/10 ]

Assigning this to cdi team after talking to Siva. It is a bug in their layer.

Comment by chaoslayer [ 14/Dec/10 ]

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 ]

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 ]

OK, so do you need any additional data from my side?

Comment by Sanjeeb Sahoo [ 14/Dec/10 ]

No, not at this point. We have sufficient information to proceed. Thanks.

Comment by Sanjeeb Sahoo [ 15/Dec/10 ]

Needed for 3.1

Comment by Sivakumar Thyagarajan [ 17/Dec/10 ]

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 ]

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 ]

Raised a RFE GLASSFISH-15249 to fix the underlying usecase.

Comment by chaoslayer [ 17/Dec/10 ]

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 ]

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 ]

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 ]

Marking as "3_1-exclude" and targetting for 3.2

Comment by Sivakumar Thyagarajan [ 06/Jul/11 ]

Marking as 3_1-next as this was targetted for 3.1+ releases

Comment by Sivakumar Thyagarajan [ 08/Jul/11 ]

Marked issue as "Major"

Comment by Sivakumar Thyagarajan [ 15/Oct/12 ]

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 ]

siva, sahoo,

Please add a osgi-javaee component for the issue.

Comment by TangYong [ 25/Mar/13 ]

Because the bug depends on GLASSFISH-15249 which will be implemented in future release, fix version is adjusted into future release.





[GLASSFISH-17155] CDI Events don't work when fired by a OSGi ServiceListener. Created: 06/Aug/11  Updated: 25/Mar/13

Status: Open
Project: glassfish
Component/s: OSGi-JavaEE
Affects Version/s: 3.1.1
Fix Version/s: future release

Type: Bug Priority: Major
Reporter: ranophoenix Assignee: Sanjeeb Sahoo
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows 7 (64 bits)
java version "1.6.0_25"
Java(TM) SE Runtime Environment (build 1.6.0_25-b06)
Java HotSpot(TM) 64-Bit Server VM (build 20.0-b11, mixed mode)


Attachments: Zip Archive osgijee.zip     Zip Archive osgijee_tangyong.zip    
Status Whiteboard:

Workaround: Set TCL before raising CDI event inside serviceChanged()

Tags: 3_1_x-exclude, osgi-javaee

 Description   

Steps to reproduce the problem:

1) Download Glassfish

http://download.java.net/glassfish/3.1.1/release/glassfish-3.1.1.zip

2) Unzip and enable remote shell (item 10.4.1 from GF-OSGI-Features.pdf)

3) Download and unzip the file in attachment

4) Open a shell (cmd in Windows)

$>cd osgijee
$>mvn package

5) Run Glassfish

asadmin start-database
asadmin start-domain -v

6) Start gogo shell

$>telnet localhost 6666
g! install file:/F:/tmp/osgijee/core/target/core.jar
Bundle ID: 253
g! start 253
g! install file:/F:/tmp/osgijee/webclient/target/webclient.war
Bundle ID: 254
g! start 254

7) Access in your browser: http://localhost:8080/webclient/faces/home.xhtml. You must see a page with text: "No modules available."

8) Go back to gogo shell
g! install file:/F:/Users/ranophoenix_2/Documents/Pos-ESAB/Experimentos/tmp/osgijee/module1/target/module1.war
Bundle ID: 255
g! start 255
ERROR: Bundle ranophoenix.osgijee.webclient [254]: EventDispatcher: Error during dispatch. (java.lang.IllegalStateExcept
ion: Singleton not set for sun.misc.Launcher$AppClassLoader@1f7182c1)
java.lang.IllegalStateException: Singleton not set for sun.misc.Launcher$AppClassLoader@1f7182c1
at org.glassfish.weld.ACLSingletonProvider$ACLSingleton.get(ACLSingletonProvider.java:110)
at org.jboss.weld.Container.instance(Container.java:58)
at org.jboss.weld.resolution.ResolvableBuilder.checkQualifier(ResolvableBuilder.java:209)
at org.jboss.weld.resolution.ResolvableBuilder.addQualifier(ResolvableBuilder.java:174)
at org.jboss.weld.resolution.ResolvableBuilder.addQualifiers(ResolvableBuilder.java:202)
at org.jboss.weld.manager.BeanManagerImpl.resolveObserverMethods(BeanManagerImpl.java:474)
at org.jboss.weld.manager.BeanManagerImpl.fireEvent(BeanManagerImpl.java:625)
at org.jboss.weld.event.EventImpl.fire(EventImpl.java:75)
at ranophoenix.osgijee.webclient.impl.cdi.ModuleExtensionListener.serviceChanged(ModuleExtensionListener.java:45
)
at org.apache.felix.framework.util.EventDispatcher.invokeServiceListenerCallback(EventDispatcher.java:871)
at org.apache.felix.framework.util.EventDispatcher.fireEventImmediately(EventDispatcher.java:733)
at org.apache.felix.framework.util.EventDispatcher.fireServiceEvent(EventDispatcher.java:662)
at org.apache.felix.framework.Felix.fireServiceEvent(Felix.java:3769)
at org.apache.felix.framework.Felix.access$000(Felix.java:80)
at org.apache.felix.framework.Felix$2.serviceChanged(Felix.java:722)
at org.apache.felix.framework.ServiceRegistry.registerService(ServiceRegistry.java:107)
at org.apache.felix.framework.Felix.registerService(Felix.java:2854)
at org.apache.felix.framework.BundleContextImpl.registerService(BundleContextImpl.java:251)
at org.apache.felix.framework.BundleContextImpl.registerService(BundleContextImpl.java:229)
at ranophoenix.osgijee.module1.impl.Activator.start(Activator.java:17)
at org.apache.felix.framework.util.SecureAction.startActivator(SecureAction.java:629)
at org.apache.felix.framework.Felix.activateBundle(Felix.java:1835)
at org.apache.felix.framework.Felix.startBundle(Felix.java:1752)
at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:922)
at org.apache.felix.gogo.command.Basic.start(Basic.java:758)
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.apache.felix.gogo.runtime.Reflective.method(Reflective.java:136)
at org.apache.felix.gogo.runtime.CommandProxy.execute(CommandProxy.java:82)
at org.apache.felix.gogo.runtime.Closure.executeCmd(Closure.java:469)
at org.apache.felix.gogo.runtime.Closure.executeStatement(Closure.java:395)
at org.apache.felix.gogo.runtime.Pipe.run(Pipe.java:108)
at org.apache.felix.gogo.runtime.Closure.execute(Closure.java:183)
at org.apache.felix.gogo.runtime.Closure.execute(Closure.java:120)
at org.apache.felix.gogo.runtime.CommandSessionImpl.execute(CommandSessionImpl.java:89)
at org.apache.felix.gogo.shell.Console.run(Console.java:62)
at org.apache.felix.gogo.shell.Shell.console(Shell.java:203)
at org.apache.felix.gogo.shell.Shell.gosh(Shell.java:128)
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.apache.felix.gogo.runtime.Reflective.method(Reflective.java:136)
at org.apache.felix.gogo.runtime.CommandProxy.execute(CommandProxy.java:82)
at org.apache.felix.gogo.runtime.Closure.executeCmd(Closure.java:469)
at org.apache.felix.gogo.runtime.Closure.executeStatement(Closure.java:395)
at org.apache.felix.gogo.runtime.Pipe.run(Pipe.java:108)
at org.apache.felix.gogo.runtime.Closure.execute(Closure.java:183)
at org.apache.felix.gogo.runtime.Closure.execute(Closure.java:120)
at org.apache.felix.gogo.runtime.CommandSessionImpl.execute(CommandSessionImpl.java:89)
at org.apache.felix.shell.remote.Shell.startGogoShell(Shell.java:108)
at org.apache.felix.shell.remote.Shell.run(Shell.java:81)
at java.lang.Thread.run(Thread.java:662)
Module1 started



 Comments   
Comment by ranophoenix [ 06/Aug/11 ]

Correcting the path in step 8:

8) Go back to gogo shell
g! install file:/F:/tmp/osgijee/module1/target/module1.war
...

Comment by ranophoenix [ 25/Aug/11 ]

The same problem occurs with Windows 7,JVM 1.6.0_27 64 bits and Glassfish 3.1.1 all of them installed from scratch.

Comment by Sanjeeb Sahoo [ 20/Oct/11 ]

I wish you had reminded me about this bug. I hope you didn't get stuck. As a simple work around, just set the context class loader inside the serviceChanged method like this:

public class ModuleExtensionListener implements ServiceListener {
...
public void serviceChanged(ServiceEvent event) {
ClassLoader origCl = Thread.currentThread().getContextClassLoader();
try

{ Thread.currentThread().setContextClassLoader(getClass().getClassLoader()); ... raise your CDI event here }

finally

{ Thread.currentThread().setContextClassLoader(origCl); }

}
}

Comment by Sanjeeb Sahoo [ 20/Oct/11 ]

Since there is a simple workaround available, we will defer fixing this bug till 4.0.

Comment by TangYong [ 10/Aug/12 ]

1) About ACLSingleton.getClassLoader()
If store hashtable does not contain Thread.currentThread().getContextClassLoader(),
the exception on GLASSFISH-17155 must happen. So, sahoo gave a solution. However, I have
confirmed that even if user set the current thread context classload on serviceChanged method,
the exception still existed. Why? Becasue the key put in store hashtable is WebappClassLoader
(for the WAB app) and the WebappClassLoader is set on WAB deploying, so, for the user, he/she can
not have chance to set the current thread context classload into the WebappClassLoader.

2) About CDI/OSGi Event
I have found that real problem on GLASSFISH-17155 is that currently,GF has not implemented the CDI/OSGi Event Integration.

I made a confirmation that even if I made the exception on GLASSFISH-17155 disappeared using a temp revise way, the sample can not still work. Why? When a new service is registered, although cdi event has been fired and WAB @observers method is also triggered, but on the WAB, there are two @Observes, one is to add the service and the other is to delete the service. When cdi event is fired, both the two @Observes are triggered.So, the service is not still added finally. That is to say, the @Observes can not judge the type of current OSGi Event.

Comment by TangYong [ 10/Aug/12 ]

Sahoo Said:

>1) About ACLSingleton.getClassLoader()
>...
So, are you saying that the suggested work around does not work any longer? I think your analysis is correct as well. I think a proper way to solve would be to set the class loader as an attribute in ServletContext during WAB deployment so that an application programmer can retrieve it inside serviceChanged() method and set it as the TCL
temporarily.

>2) About CDI/OSGi Event
>...
I think this is because the test application attached to the issue is not firing events correctly. It needs to fire events using BeanManager and use proper qualifiers such that methods will receive events they are interested in. See ServletContextBridgeListener.java in the test app for more details.

Comment by TangYong [ 10/Aug/12 ]

Yeah, I also think the way indeed can resolve the problem. However because the problem happened on cdi event case, I suggest that during resolving cdi/osgi event integration, finding a better way to resolve the problem. After all, I felt the problem is not simple.

Thanks your suggestion and I will see ServletContextBridgeListener.java. In addition, about how to firing events correctly(etc. when a osgi service has been registered...) and related using way, wishing siva can give some ideas, then we will launch another thread to discuss it.

Comment by TangYong [ 10/Aug/12 ]

Currently, a prototype is plan to implement the cdi/osgi event integraton.

https://github.com/tangyong/gf-cdi-osgi-integration

Comment by TangYong [ 19/Nov/12 ]

Waiting for GLASSFISH-15365 and I will modify the sample and make it available.

Comment by TangYong [ 22/Nov/12 ]

Waiting for finishing GLASSFISH-15365 test , then starting to resolve the bug.

Comment by TangYong [ 26/Nov/12 ]

Hi ranophoenix, sahoo, siva,

Based my event integration patch and ranophoenix's original sample, I re-made a new sample(osgijee_tangyong.zip) using osgi/cdi event annotation. Now, osgijee_tangyong.zip can work normally.

However, while executing the last step(module1's about.xhtml), there is a issue happening as following:

[#|2012-11-26T17:49:16.015+0900|WARNING|44.0|javax.enterprise.resource.webcontainer.jsf.lifecycle|_ThreadID=15;_ThreadName=http-listener-1(2);_TimeMillis=1353919756015;_LevelValue=900;|//about.xhtml @13,61 value="#

{aboutBean.message}": Target Unreachable, identifier 'aboutBean' resolved to null
javax.el.PropertyNotFoundException: //about.xhtml @13,61 value="#{aboutBean.message}

": Target Unreachable, identifier 'aboutBean' resolved to null
at com.sun.faces.facelets.el.TagValueExpression.getType(TagValueExpression.java:100)
at com.sun.faces.renderkit.html_basic.HtmlBasicInputRenderer.getConvertedValue(HtmlBasicInputRenderer.java:95)
at javax.faces.component.UIInput.getConvertedValue(UIInput.java:1031)
at javax.faces.component.UIInput.validate(UIInput.java:961)
at javax.faces.component.UIInput.executeValidate(UIInput.java:1234)
at javax.faces.component.UIInput.processValidators(UIInput.java:697)
at javax.faces.component.UIComponentBase.processValidators(UIComponentBase.java:1263)
at javax.faces.component.UIForm.processValidators(UIForm.java:253)
at javax.faces.component.UIComponentBase.processValidators(UIComponentBase.java:1263)
at javax.faces.component.UIViewRoot.processValidators(UIViewRoot.java:1169)
at com.sun.faces.lifecycle.ProcessValidationsPhase.execute(ProcessValidationsPhase.java:76)
at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101)
at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:181)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:641)
at org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1593)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:285)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:665)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:604)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:162)
at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:337)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:240)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:172)
at org.glassfish.grizzly.http.server.HttpHandler.doHandle(HttpHandler.java:164)
at org.glassfish.grizzly.http.server.HttpServerFilter.handleRead(HttpServerFilter.java:175)
at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:265)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:200)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:134)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:112)
at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77)
at org.glassfish.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(TCPNIOTransport.java:781)
at org.glassfish.grizzly.strategies.AbstractIOStrategy.fireIOEvent(AbstractIOStrategy.java:112)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.run0(WorkerThreadIOStrategy.java:115)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.access$100(WorkerThreadIOStrategy.java:55)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy$WorkerThreadRunnable.run(WorkerThreadIOStrategy.java:135)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:578)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:558)
at java.lang.Thread.run(Thread.java:662)
Caused by: javax.el.PropertyNotFoundException: Target Unreachable, identifier 'aboutBean' resolved to null
at com.sun.el.parser.AstValue.getTarget(AstValue.java:153)
at com.sun.el.parser.AstValue.getType(AstValue.java:84)
at com.sun.el.ValueExpressionImpl.getType(ValueExpressionImpl.java:200)
at org.jboss.weld.el.WeldValueExpression.getType(WeldValueExpression.java:93)
at com.sun.faces.facelets.el.TagValueExpression.getType(TagValueExpression.java:98)
... 38 more

#]

ranophoenix's mean is that he/she wants to make CDI Bean in module1's context root can work in webclient's context root. So, I wish that sahoo and siva can see the sample and confirm whether this behavior is right or not? And this is also related to register a cdi bean on runtime. On JBoss's JIRA, there is such a requirement[1]:
[1]: https://issues.jboss.org/browse/CDI-114

In addition, I think that combining cdi beans in two different context roots should be user's behavior, and osgi-cdi should not handle the scene because osgi-cdi's responsibility only triggers osgi events, as to how to handle these events, has been out of event integration's scope.

Thanks
--Tang

Comment by TangYong [ 25/Mar/13 ]

The bug is related to OSGi/CDI RFC 193. Currently, we have not enough time to implement it.So, we have a plan to fix the issue after v4 is released.





[GLASSFISH-18514] CDI does not get enabled on server start for a WAB bundle, the war has to be redeployed after the server starts for CDI to be enabled. Created: 15/Mar/12  Updated: 20/Mar/13

Status: Open
Project: glassfish
Component/s: cdi, OSGi-JavaEE
Affects Version/s: 3.1.2
Fix Version/s: future release

Type: Bug Priority: Critical
Reporter: aaronjwhiteside Assignee: Sivakumar Thyagarajan
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Text File server.log    

 Description   

CDI does not get enabled on server start for a WAB bundle, the war has to be redeployed after the server starts for CDI to be enabled.

Please see attached server.log

You can see after the server has started I manually redeployed the WAB and CDI was enabled that time.

If I do not redeploy the WAB CDI is not enabled and I get NPE when trying to access a JAX-RS resource that @Inject's a @OSGiService(dynamic=true).



 Comments   
Comment by aaronjwhiteside [ 16/Mar/12 ]

So I think I tracked down the issue.

The org.glassfish.fighterfish.osgi-cdi bundle which provides the cdi support for WAB's has a run level of 2. However any bundle that is deployed under <domain>autodeploy/bundles always has a run level of 1.

So when you start glassfish that already has bundles under autodeploy/bundles and no osgi-cache (to tell it the deploy order, if you deployed something after the server was already started) it'll start the osgi-cdi bundle after the WAB bundle. And thus CDI support is never enabled for WAB's.

I tried adding

felix.fileinstall.start.level=4 

to glassfish3/glassfish/config/osgi.properties

But the bundles deployed from <domain>/autodeploy/bundles still seem to start in runlevel 1.

Comment by aaronjwhiteside [ 16/Mar/12 ]

For reference:
http://felix.apache.org/site/apache-felix-file-install.html

Comment by aaronjwhiteside [ 16/Mar/12 ]

OK so it turns out that all the felix.fileinstall* properties in osgi.properties are totally ignored and should probably be removed.

The real file doing the configuration is:

glassfish3/glassfish/modules/autostart/org.apache.felix.fileinstall-autodeploy-bundles.cfg

However if I add the line:

felix.fileinstall.start.level=4

to this file, it still does not set the run level for bundles under autodeploy/bundles, they still start at run level one.

However I do get a log message printed out:

[#|2012-03-15T20:08:20.322-0400|INFO|glassfish3.1.2|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=12;_ThreadName=Thread-2;|felix.fileinstall.start.level set, but not a int: 4 |#]

Which is interesting, apparently 4 really isn't an int.. I guess this is an ERROR even though it says INFO.. or maybe a WARN as it seems to have ignored the config.

Without this fixed OSGi is pretty much useless.

Comment by aaronjwhiteside [ 16/Mar/12 ]

Fixing this issue will probably fix another bug I reported too.

http://java.net/jira/browse/GLASSFISH-18508

And a bunch of other random weird stuff I was pulling my hair out over..

Comment by aaronjwhiteside [ 16/Mar/12 ]

OK so after more investigation it turns out you have to set:

felix.fileinstall.start.level=4

in osgi.properties AND org.apache.felix.fileinstall-autodeploy-bundles.cfg or less it does not get picked up. This is probably a bug too.

(and obviously, even through I omitted it you must set glassfish.osgi.start.level.final=4 in osgi.properties too).

So now I can see that the start level of my WAB bundle is really 4, however CDI still does NOT get enabled. I have to remove the war and redeploy it again, after the server has started for CDI to kicked in.

So my assumption that the start level's were the issue seems to be moot, however having a start level of 1 for the bundles under autodeploy/bundles and a start level of 2 for most of glassfish's osgi to jee integration bundles is still a bug. The bundles under autodeploy/bundles should start in start level 4.

So the question is now, if not start levels, what is causing CDI to not load and required a redeploy of the war to be enabled???

Comment by Sanjeeb Sahoo [ 16/Mar/12 ]

No, I don't understand some of your observations. This is how things are supposed to work:

no osgi-cache:
fileinstall is started at start level 2 and it is configured to start after modules/autostart/,
which means first time (same as no osgi cache) the server starts, fileinstall will come into effect
after all bundles in modules/autostart/. Once fileinstall is started, it will then go onto deploy
autodeploy/bundles/. Now, let's say one such bundle is a WAB that uses CDI.
Since osgi-cdi is already installed,when the WAB is processed, osgi-cdi will process the WAB as well.

Let's stop the server and restart. Upon restart, the WAB is started at start level 1 which means it is
started before osgi-web-container and osgi-cdi are started. But, the WAB processing is deferred until
osgi-web-container is started. When server reaches start level 2, osgi-web-container is started and it
processes the WAB. It does not matter whether osgi-cdi is active or not. It only has to be in INSTALLED
state for it to be useful. So, when the WAB is processed by osgi-web-container, osgi-cdi will be used
as well.

So, I don't see a case why osgi-cdi is not used in your case. Could you supply a test case with instructions?
I tried a WAB+CDI test case and could not reproduce.

A note about fileinstall start level:
The bundles in autodeploy/bundles/ are started at start level 1. This seems like
a bad configuration. They should have start level matching that of fileinstall, which is 2. I will
open a separate issue to do this. But, I can't see it affecting any functionality now.

To change the start level of bundles in autodeploy/bundles, edit osgi.properties file.
modules/autostart/o.a.f.fileinstall-autodeploy-bundles.cfg is not used any more.
If you set a start level higher than 2, then you must also configure the server to change the
start level to that value. Currently, server sets final start level to 2 using the property:
glassfish.osgi.start.level.final=2
Change it to the higher value, else your bundles in autodeploy/bundles will never get activated.

Comment by aaronjwhiteside [ 16/Mar/12 ]

After clearing the osgi-cache (I keep forgetting) CDI now works, so changing the start level fixed the issue.

Can this please be fixed in the next release?

Comment by Sanjeeb Sahoo [ 17/Mar/12 ]

What you want to be fixed? start level of bundles/autodeploy/? Sure it can be (could you file an issue under osgi category?), but, as I mentioned earlier, I don't understand why you had to change start level. Are you really sure things didn't work for you as is? I would love to understand it better. Do you have a reproducible test case?

Comment by tlcksnyder [ 20/Mar/13 ]

not attempting to fix without a reproducible test case, or better description of reproduction steps.





[GLASSFISH-19542] Out of the box OSGi JPA support as per the 4.3 Compendium Specification Created: 16/Jan/13  Updated: 11/Mar/13

Status: Open
Project: glassfish
Component/s: entity-persistence, OSGi, OSGi-JavaEE
Affects Version/s: 4.0_b70
Fix Version/s: future release

Type: New Feature Priority: Major
Reporter: aaronjwhiteside Assignee: Sanjeeb Sahoo
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Out of the box OSGi JPA support as per the 4.3 Compendium Specification (http://www.osgi.org/download/r4v43/osgi.cmpn-4.3.0.pdf).

The upcoming release of JBoss 7.2 will have full native support for JPA in OSGi as per the 4.3 Compendium Specification.

Glassfish 4.0 should come with support out of the box.

I would recommend against using Gemini JPA as it's not really maintained (check the last release date) and does not provide support for JTA transactions or looking up JTA data sources.



 Comments   
Comment by Mitesh Meswani [ 16/Jan/13 ]

Assigning to Sahoo...

Comment by mkeith [ 17/Jan/13 ]

OSGi JPA support, as per the OSGi 4.3 Compendium Spec, does NOT include support for JTA transactions.

Many people have found Gemini JPA to be the best point OSGi JPA solution, in the spirit of what OSGi JPA tried to accomplish. In fact, there are very few actual bugs; the ones that are there are generally feature requests. The last 1.1 release included some advanced features that no other solution provides.

I also have to take issue with your incorrect statement that Gemini JPA is "not really maintained". 1.1 was released on Nov 15, 2012, only 2 months ago! The next one will be released in the June time frame.

Comment by aaronjwhiteside [ 17/Jan/13 ]

I understand the spec does not include support for JTA, I forgot to mention that this is an important feature for me.

I apologize for my incorrect statement, I swear I checked the release date and thought I saw that 1.1 was in 2010.

I think I am tainted by my previous experience with it, about a year ago with Glassfish 3.1.2, it just didn't work.

And if everyone thinks this is the best option, I still think it should be bundled with Glassfish 4.0.





[GLASSFISH-19726] reusing wab expanded directory until bundle is updated Created: 25/Feb/13  Updated: 25/Feb/13

Status: In Progress
Project: glassfish
Component/s: OSGi-JavaEE
Affects Version/s: 3.1.2.2
Fix Version/s: None

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

Windows
Linux/Unix



 Description   

[Sahoo]
reusing expanded directory until bundle is updated. i.e., instead of removing it when bundle is stopped, we should remove it when bundle is uninstalled or updated. This new bug may affect resolution of #19697.






[GLASSFISH-11373] [OSGi-JPA] Tables are not dropped during undeploy for drop-and-create-tables Created: 29/Dec/09  Updated: 09/Feb/13

Status: Open
Project: glassfish
Component/s: OSGi-JavaEE
Affects Version/s: V3
Fix Version/s: future release

Type: Bug Priority: Major
Reporter: Sanjeeb Sahoo Assignee: Mitesh Meswani
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Attachments: File hybridapp4.war    
Issue Links:
Related
is related to GLASSFISH-18074 [OSGi] glassfish-resources.xml not pi... Open
Issuezilla Id: 11,373
Tags: 3_1-exclude

 Description   

For hybrid applications that use JPA, drop-and-create-tables don't drop tables.
The attached application specifies drop-and-create-tables in persistence.xml as
shown below:

<persistence xmlns="http://java.sun.com/xml/ns/persistence" version="1.0">
<persistence-unit name ="em1">
<!-- This is needed for eclipselink static enhancer to be able to
discover persistence capable classes -->
<exclude-unlisted-classes>false</exclude-unlisted-classes>
<properties>
<property name="eclipselink.ddl-generation"
value="drop-and-create-tables"/>
</properties>
</persistence-unit>
</persistence>

To reproduce:
1. start glassfish
2. start the default JavaDB database
3. copy the attched hybridapp4.war to domain1/autodeploy/bundles/
4. see log messages that shows application deployed.
5. check database to see table called USERCREDENTIAL getting created.
5. now rm domain1/autodeploy/bundles/hybridapp4.war.
6. watch log to ensure that the app gets undeployed.
7. you will still see the table there in the database.

Mitesh,

Let me know if I need to do something in OSGi web container for this to work.
Assigning you for your input. Please look into it urgently.

Thanks,
Sahoo



 Comments   
Comment by Sanjeeb Sahoo [ 29/Dec/09 ]

Created an attachment (id=4134)
Test case

Comment by Sanjeeb Sahoo [ 29/Dec/09 ]

v3-> v3.1

Comment by Mitesh Meswani [ 05/Oct/10 ]

Targeting for MS07

Comment by Mitesh Meswani [ 09/Feb/13 ]

With JPA 2.1, we are switching to rely on JPA provider for schema generation. Currently, targeting this issue for future release. We might not require to fix this with JPA 2.1





[osgi-cdi]OSGi service automatic publishing with @Publish-liking annotation (GLASSFISH-18938)

[GLASSFISH-19440] getting out of the weld-integration logic knowing about hybrid bundles and OSGi Created: 14/Dec/12  Updated: 14/Dec/12

Status: Open
Project: glassfish
Component/s: OSGi-JavaEE
Affects Version/s: future release
Fix Version/s: None

Type: Sub-task Priority: Critical
Reporter: TangYong Assignee: Sanjeeb Sahoo
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

In current patch, weld-integration logic knows about hybrid bundles and OSGi because in order to get right Bean Manager and current bundle Id, I register Bean Manager as an OSGi Service and make bundle Id as service property.

For example,

BeanManager manager = bootstrap.getManager(archive);
Properties properties = new Properties();
properties.put("BundleID", bundleId);
ServiceRegistration sr = bundleContext.registerService(BeanManager.class.getName(), manager, properties);

However, from Siva's comment,

"However I would still like to try to see how we can get out of the weld-integration logic knowing about hybrid bundles and OSGi."

There is an import issue needing to investigate firstly:

"So, I understand this is the issue for which you bind the appropriate WeldBeanManager in the ServiceRegistry and use it later to get the @Public annotated classes. Can this be fixed? Why is only the BDA for OSGiServiceExtension and not osgiappXXXXX available in the extension? Is this a Weld issue? "






[GLASSFISH-15365] [OSGi/CDI] CDI + OSGi event admin Created: 27/Dec/10  Updated: 11/Dec/12

Status: Open
Project: glassfish
Component/s: OSGi-JavaEE
Affects Version/s: None
Fix Version/s: future release

Type: New Feature Priority: Major
Reporter: Sanjeeb Sahoo Assignee: Sanjeeb Sahoo
Resolution: Unresolved Votes: 1
Labels: None
Σ Remaining Estimate: Not Specified Remaining Estimate: Not Specified
Σ Time Spent: Not Specified Time Spent: Not Specified
Σ Original Estimate: Not Specified Original Estimate: Not Specified

Attachments: Zip Archive GLASSFISH-15365-patch-20121211.zip    
Sub-Tasks:
Key
Summary
Type
Status
Assignee
GLASSFISH-19358 Adding fighterfish test cases Sub-task Open Sanjeeb Sahoo  
Tags: 3_1_x-exclude

 Description   

We should explore use of CDI event mechanism for OSGi event admin



 Comments   
Comment by TangYong [ 19/Nov/12 ]

CDI/OSGi Event Integration is in progress. Now, desgin of the integration is as following:

1 CDI/OSGi Event API

1) defining three CDI/OSGi Events

・ServiceRegistered
・ServiceModified
・ServiceUnregistering

2) defining a @ServiceContract Qualifier used for qualifying CDI/OSGi event

@Target(

{ PARAMETER }

)
@Retention(RetentionPolicy.RUNTIME)
@Documented
@Qualifier
public @interface ServiceContract {
/**

  • The specification class filtering the received
  • {@link javax.enterprise.event.Event}

    .
    */
    Class<?> value();
    }

By 1) and 2), a user can write the following observer method:

public void postOnActivator(@Observes @ServiceContract(StockQuoteService.class) ServiceRegistered event)

{ System.out.println("postOnActivator() method is getting : " + event.getServiceContractNames()); Set<String> set = ((StockQuoteService)event.getService()).getSymbols(); ... }

2 OSGi Service Listening
Adding ServiceListener into OSGiCDIContainerActivator and wraping OSGi Service Event into CDI/OSGi Event

3 Firing CDI/OSGi Event using CDI Event Interface
Here, I use Instance<Object> to select Event<Object> and fire CDI/OSGi Event. In order to get Instance<Object>, I need to register Instance<Object> related each Weld Container Instance as OSGi Services while getting Instance<Object> from OSGiServiceExtension class.

Note: while using Instance<Object> to select Event<Object>, Weld will call ACLSingletonProvider.get() , so we must take care of set TCCL.

4 Handling Instance<Object>'s Unregistering
While a bundle is in process of stopping or uninstalled, we must unregister OSGi Service of Instance<Object> which belongs to current bundle.

[Current State Of Integration]
Prototype has been made and fixing some bugs.

Comment by TangYong [ 19/Nov/12 ]

Currently, event integration has been tested between multi plain osgi bundles successfully, the following displayed that event callback method(OnServiceRegistered) can be called many times once MyServiceInf's implementation is available.

[#|2012-11-19T22:44:35.656+0900|INFO|44.0|javax.enterprise.logging.stdout|_ThreadID=12;_ThreadName=admin-listener(1);_TimeMillis=1353332675656;_LevelValue=800;|MyService has been registered OSGi Service!|#]

[#|2012-11-19T22:44:35.656+0900|INFO|44.0|javax.enterprise.logging.stdout|_ThreadID=12;_ThreadName=admin-listener(1);_TimeMillis=1353332675656;_LevelValue=800;|SimpleStockQuoteServiceImpl::Initializing quotes|#]

[#|2012-11-19T22:44:35.656+0900|INFO|44.0|javax.enterprise.logging.stdout|_ThreadID=12;_ThreadName=admin-listener(1);_TimeMillis=1353332675656;_LevelValue=800;|SimpleStockQuoteServiceImpl::getSymbols|#]

[#|2012-11-19T22:44:35.656+0900|INFO|44.0|javax.enterprise.logging.stdout|_ThreadID=12;_ThreadName=admin-listener(1);_TimeMillis=1353332675656;_LevelValue=800;|Registered:[IBM, MSFT, HPQ, ORCL]|#]

[#|2012-11-19T22:44:35.656+0900|INFO|44.0|javax.enterprise.logging.stdout|_ThreadID=12;_ThreadName=admin-listener(1);_TimeMillis=1353332675656;_LevelValue=800;|OnServiceRegistered() method is getting : [org.acme.myservice.api.MyServiceInf]|#]

[#|2012-11-19T22:44:35.656+0900|INFO|44.0|javax.enterprise.logging.stdout|_ThreadID=12;_ThreadName=admin-listener(1);_TimeMillis=1353332675656;_LevelValue=800;|OnServiceRegistered(): MyService: Hello Word!|#]

[#|2012-11-19T22:44:35.656+0900|INFO|44.0|javax.enterprise.logging.stdout|_ThreadID=12;_ThreadName=admin-listener(1);_TimeMillis=1353332675656;_LevelValue=800;|Started sample.osgicdi.myservice [284]|#]

[#|2012-11-19T22:44:35.671+0900|INFO|44.0|javax.enterprise.system.tools.admin.org.glassfish.deployment.admin|_ThreadID=12;_ThreadName=admin-listener(1);_TimeMillis=1353332675671;_LevelValue=800;|myservice was successfully deployed in 109 milliseconds.|#]

[#|2012-11-19T22:45:09.906+0900|INFO|44.0|javax.enterprise.logging.stdout|_ThreadID=12;_ThreadName=admin-listener(1);_TimeMillis=1353332709906;_LevelValue=800;|Stopped sample.osgicdi.myservice [284]|#]

[#|2012-11-19T22:45:09.921+0900|INFO|44.0|javax.enterprise.logging.stdout|_ThreadID=12;_ThreadName=admin-listener(1);_TimeMillis=1353332709921;_LevelValue=800;|Uninstalled sample.osgicdi.myservice [284]|#]

[#|2012-11-19T22:45:19.250+0900|INFO|44.0|javax.enterprise.logging.stdout|_ThreadID=12;_ThreadName=admin-listener(1);_TimeMillis=1353332719250;_LevelValue=800;|Installed sample.osgicdi.myservice [285] from reference:file:/D:/gf/1102/glassfish3/glassfish/domains/domain1/applications/myservice/|#]

[#|2012-11-19T22:45:19.250+0900|INFO|44.0|javax.enterprise.logging.stdout|_ThreadID=12;_ThreadName=admin-listener(1);_TimeMillis=1353332719250;_LevelValue=800;|Hello!|#]

[#|2012-11-19T22:45:19.265+0900|INFO|44.0|org.jboss.weld.Bootstrap|_ThreadID=12;_ThreadName=admin-listener(1);_TimeMillis=1353332719265;_LevelValue=800;|WELD-000101 Transactional services not available. Injection of @Inject UserTransaction not available. Transactional observers will be invoked synchronously.|#]

[#|2012-11-19T22:45:19.281+0900|INFO|44.0|javax.enterprise.logging.stdout|_ThreadID=12;_ThreadName=admin-listener(1);_TimeMillis=1353332719281;_LevelValue=800;|MyService has been registered OSGi Service!|#]

[#|2012-11-19T22:45:19.281+0900|INFO|44.0|javax.enterprise.logging.stdout|_ThreadID=12;_ThreadName=admin-listener(1);_TimeMillis=1353332719281;_LevelValue=800;|SimpleStockQuoteServiceImpl::Initializing quotes|#]

[#|2012-11-19T22:45:19.281+0900|INFO|44.0|javax.enterprise.logging.stdout|_ThreadID=12;_ThreadName=admin-listener(1);_TimeMillis=1353332719281;_LevelValue=800;|SimpleStockQuoteServiceImpl::getSymbols|#]

[#|2012-11-19T22:45:19.281+0900|INFO|44.0|javax.enterprise.logging.stdout|_ThreadID=12;_ThreadName=admin-listener(1);_TimeMillis=1353332719281;_LevelValue=800;|Registered:[IBM, MSFT, HPQ, ORCL]|#]

[#|2012-11-19T22:45:19.281+0900|INFO|44.0|javax.enterprise.logging.stdout|_ThreadID=12;_ThreadName=admin-listener(1);_TimeMillis=1353332719281;_LevelValue=800;|OnServiceRegistered() method is getting : [org.acme.myservice.api.MyServiceInf]|#]

[#|2012-11-19T22:45:19.281+0900|INFO|44.0|javax.enterprise.logging.stdout|_ThreadID=12;_ThreadName=admin-listener(1);_TimeMillis=1353332719281;_LevelValue=800;|OnServiceRegistered(): MyService: Hello Word!|#]

[#|2012-11-19T22:45:19.281+0900|INFO|44.0|javax.enterprise.logging.stdout|_ThreadID=12;_ThreadName=admin-listener(1);_TimeMillis=1353332719281;_LevelValue=800;|Started sample.osgicdi.myservice [285]|#]

Comment by TangYong [ 19/Nov/12 ]

However, there is a bug which is in process of investigation.
Once the observer method is in a servlet of WAB, the observer has not been triggered.

Comment by TangYong [ 20/Nov/12 ]

Currently, WAB's OSGi/CDI event integration is blocked by GLASSFISH-19359 and waiting for siva and sahoo's confirmation.

Comment by TangYong [ 22/Nov/12 ]

Because GLASSFISH-19359 has been resolved, now, starting to enter into fighterfish test phrase.

Comment by TangYong [ 11/Dec/12 ]

Splited patch for GLASSFISH-15365 is uploaded, please seeing GLASSFISH-15365-patch-20121211.zip.





[GLASSFISH-18938] [osgi-cdi]OSGi service automatic publishing with @Publish-liking annotation Created: 25/Jul/12  Updated: 11/Dec/12

Status: Open
Project: glassfish
Component/s: OSGi-JavaEE
Affects Version/s: future release
Fix Version/s: None

Type: New Feature Priority: Critical
Reporter: TangYong Assignee: Sanjeeb Sahoo
Resolution: Unresolved Votes: 0
Labels: None
Σ Remaining Estimate: Not Specified Remaining Estimate: Not Specified
Σ Time Spent: Not Specified Time Spent: Not Specified
Σ Original Estimate: Not Specified Original Estimate: Not Specified

Attachments: Zip Archive GLASSFISH-18938-patch-20121211.zip    
Sub-Tasks:
Key
Summary
Type
Status
Assignee
GLASSFISH-18972 making @Publish to support filter pro... Sub-task Open Sanjeeb Sahoo  
GLASSFISH-19210 make @Publish support Service type re... Sub-task Open Sanjeeb Sahoo  
GLASSFISH-19440 getting out of the weld-integration l... Sub-task Open Sanjeeb Sahoo  

 Description   

Liking Weld-OSGi:

allows developers to automatically publish service implementation.There is nothing to do, just put the
annotation. OSGi framework is completely hidden. Then the service is accessible through CDI-OSGi service injection
and OSGi classic mechanisms.

In addition, on OSGi RFP-0146 Draft,

CDI002 - The specification MUST make it possible to publish CDI beans in the OSGi Service Registry.

So, this is a critical Requirement on CDI/OSGi Integration just as @OSGiService.



 Comments   
Comment by TangYong [ 01/Aug/12 ]

currently, a basic prototype has been implemented on https://github.com/tangyong/gf-cdi-osgi-integration.

Comment by TangYong [ 10/Aug/12 ]

Sahoo Said:

1. I think you should explore EJBTracker in osgi-ejb-container to see
how it registers EJBs as OSGi services.

2. The service properties look good to me to start with.

Comment by TangYong [ 23/Oct/12 ]

now, implementation is blocked by GLASSFISH-19215, and am fixing GLASSFISH-19215.

Comment by TangYong [ 11/Dec/12 ]

Splited patch for GLASSFISH-18938 is uploaded, please seeing GLASSFISH-18938-patch-20121211.zip.

Note: I have not updated BeanDeploymentArchiveImpl.java from weld-integration module(JJ fixed GLASSFISH-19406), and once having no problem on this patch, I will update BeanDeploymentArchiveImpl.java with trunk.





[GLASSFISH-19215] Add support CDI in plain OSGi bundles Created: 23/Oct/12  Updated: 11/Dec/12

Status: Open
Project: glassfish
Component/s: OSGi-JavaEE
Affects Version/s: future release
Fix Version/s: None

Type: Improvement Priority: Critical
Reporter: TangYong Assignee: Sivakumar Thyagarajan
Resolution: Unresolved Votes: 0
Labels: None
Σ Remaining Estimate: Not Specified Remaining Estimate: Not Specified
Σ Time Spent: Not Specified Time Spent: Not Specified
Σ Original Estimate: Not Specified Original Estimate: Not Specified

Attachments: Zip Archive GLASSFISH-19215-patch-20121211.zip     Zip Archive GLASSFISH-19215-patch.zip     Zip Archive GLASSFISH-19215-patch_20121029.zip     Zip Archive GLASSFISH-19215-patch_20121030.zip     Zip Archive GLASSFISH-19215-patch_20121109.zip     Zip Archive GLASSFISH-19215-patch_20121114.zip     Zip Archive GLASSFISH-19215_fighterfishtestcase_final_20121122.zip     Microsoft Excel reviewing_siva.xls     Microsoft Excel reviewing_siva_2012.12.10.xls     Microsoft Excel reviewing_siva_2012.12.11.xls     Zip Archive stockquote-cdi-osgi-sample.zip     Zip Archive stockquote_cdi_plainclient.zip    
Sub-Tasks:
Key
Summary
Type
Status
Assignee
GLASSFISH-19324 Instance.select(clazz).get() throw Il... Sub-task Open Sanjeeb Sahoo  
GLASSFISH-19325 moving the logics of publishing beans... Sub-task Open Sanjeeb Sahoo  
GLASSFISH-19326 invocating Weld-Integration bundle to... Sub-task Open Sanjeeb Sahoo  
GLASSFISH-19344 adding the handling logic of Weld Con... Sub-task Open Sanjeeb Sahoo  
GLASSFISH-19346 Adding fighterfish test cases Sub-task Open Sanjeeb Sahoo  
GLASSFISH-19421 Adding java doc for OSGiServicePublis... Sub-task Open Sanjeeb Sahoo  
GLASSFISH-19422 refactoring OSGiCDIExtender.startWeld... Sub-task Open Sanjeeb Sahoo  

 Description   

In order to implement RFC146(OSGi/CDI), there is prerequisite needed to be implemented.

If a plain vanilla osgi bundle included META-INF\beans.xml and wants to use @Publish and other OSGi/CDI annotation, on current glassfish, this is not supported.

The reason is that while deploying such a osgi bundle, because missing Weld Sniffer, OSGiServiceExtension can not be triggered by WELD Container.

So, this must be implemented.



 Comments   
Comment by TangYong [ 23/Oct/12 ]

My analyse result is that once deploying such a bundle using --type=osgi, while executing com.sun.enterprise.v3.server.SnifferManagerImpl.getApplicableSniffers method to get applicable sniffers, because archiveType is "osgi" , weld sniffer does not supports such a archiveType, weld sniffer was skipped.

I think that fixing way is that making weld sniffer can support such a case by checking beans.xml.

Comment by Sanjeeb Sahoo [ 23/Oct/12 ]

No sniffer should pick up an archive when --type osgi is used. The system is designed such that only OSGiContainer will be responsible for deploying such an archive. Once such a bundle is deployed as a vanilla OSGi bundle, it should be picked up by an appropriate extender. This is how OSGi/Web, OSGi/EJB features are implemented and it should be no different for OSGi/CDI as well.

Comment by TangYong [ 23/Oct/12 ]

Thanks sahoo's comment. Surely, for WAB and EJB bundle's deployment including beans.xml, real deployment is processed by OSGiWebDeployer and OSGiEJBDeployer respectively which are selected by OSGiContainer's OSGiDeployerTracker.

Then, while deploying process entered into ApplicationLifecycle, because of some magic handling(by setupClassLoader()?), getSniffers(handler, sniffers, context) can get WeldSniffer.

Backing to the problem, current deploying mode is a vanilla OSGi bundle which wants to be handled by WeldSniffer.

Just as sahoo said, it should be no different by creating a PlainOSGiDeployer. However, I have been not still clear for "some magic handling" and will continue to investigate.

Comment by TangYong [ 23/Oct/12 ]

Hi sahoo,

About the "some magic handling", I have found a place and for ejb bundle, OSGiEJBDeploymentContext has a method called getArchiveType() and returned the following:

return javax.enterprise.deploy.shared.ModuleType.EJB.toString();

Then, I have seen the WeldSniffer.supportsArchiveType method and found the following:

if (archiveType.toString().equals(ModuleType.WAR.toString()) ||
archiveType.toString().equals(ModuleType.EJB.toString()) ||
archiveType.toString().equals(ModuleType.RAR.toString()))

{ return true; }

So, for a vanilla OSGi bundle, it is not ejb and war and rar, so, if not modifying supportsArchiveType to add the supporting of a vanilla OSGi bundle, even if creating a PlainOSGiDeployer, WeldSniffer can be not still obtained.

Comment by TangYong [ 23/Oct/12 ]

For WAB, OSGiWebDeploymentContext returns the following:

@Override
public String getArchiveType()

{ // Since I am not able to reference GF 4.0 APIs as they are not yet staged in a maven repo, // I am accessing the value in a round about way. return javax.enterprise.deploy.shared.ModuleType.WAR.toString(); // WarType.ARCHIVE_TYPE; }

So, WAR is also supported by WeldSniffer.

Comment by TangYong [ 23/Oct/12 ]

In addition, there is a thing that I must say:

For a WAB or EJB Bundle, while deploying it using --type=osgi, ApplicationLifecycle.deploy method will be called twice and "sniffers = getSniffers(handler, sniffers, context)" will also be executed twice because on the second time, OSGiContainer's OSGiDeployerTracker will select right deployer to finish javaee related things.

Then, I have made a experiment by directly modifying WeldSniffer.supportsArchiveType(archiveType.toString().equals("osgi")) so that I want to see whether a plain osgi bundle with beans.xml can be scaned by OSGiServiceExtension.

The result is that, although beans.xml can be scaned by OSGiServiceExtension, the bean class with @Publish in the plain osgi bundle can not be recognized by weld container.

So, based this conclusion,

1) WeldSniffer still needs to be enhanced
2) maybe create a new module/container(for example, osgi-cdi-se-container) to do liking osgi-ejb-container under fighterfish sub-project.

Comment by Sanjeeb Sahoo [ 23/Oct/12 ]

Yes, I call it two-phase deployment. First phase involves osgi-container alone. It's the second phase where our Java EE specific extenders come into play their roles. I would expect new code to be part of osgi-cdi module itself.

Comment by TangYong [ 25/Oct/12 ]

Hi sahoo, siva,

The attachement is my fixing patch and I will explain sources in the patch in details:

1 osgi-cdi

1) Similar to osgi-ejb-container, the following java files are created to meet the second phrase deployment which will trigger Weld container's bootstrap

・OSGiCDIContainerActivator.java
used to register OSGiCDIExtender class

・OSGiCDIExtender.java
An extender that registers a OSGiCDIDeployer to deploy/undeploy a plain vanilla OSGi/CDI bundle

・OSGiCDIDeployer.java
On one hand, it is used to create OSGiCDIDeploymentRequest, on the other hand, it defined a method called isPlainOSGiCDIBundle used by handles method. The isPlainOSGiCDIBundle method is very important because by means of the method, OSGiContainer can select right OSGiCDIDeployer. Please see my comments on the method and in the future, I maybe will improve the method.

・OSGiCDIDeploymentRequest.java
A simple class extends OSGiDeploymentRequest and we must add the class in order to meet osgi-javaee-base design.

・OSGiCDIUndeploymentRequest.java
A simple class extends OSGiUndeploymentRequest and we must add the class in order to meet osgi-javaee-base design.

・Constants.java
A simple class used to define some constants to avoid magic string in sources

・OSGiCDIDeploymentContext.java
It is a very important class and specially returns a new ArchiveType(javax.enterprise.deploy.shared.ModuleType.PlainOSGiCDIBundle) used by WeldSniffer.

Defaultly, OSGiArchiveHandler's getArchiveType method returned "OSGiBundle", if directly making WeldSniffer to support "OSGiBundle" type and not adding the new type, for a plain osgi bundle without beans.xml, WeldSniffer will be also added, so, I created a new type to
differentiate a plain osgi bundle without beans.xml.

2)osgi.bundle.patch
Add Bundle-Activator: org.glassfish.osgicdi.impl.OSGiCDIContainerActivator

3)pom.xml.patch
Add the following dependency,
<dependency>
<groupId>org.glassfish.main</groupId>
<artifactId>javax.enterprise.deploy</artifactId>
<version>4.0-SNAPSHOT</version>
</dependency>

Pl. seeing my comments on the the file.

2 javax.enterprise.deploy
I added a new PlainOSGiCDIBundle Module Type used by WeldSniffer.

3 gf-weld-connector
WeldSniffer's supportsArchiveType method is modified to add the supporting of PlainOSGiCDIBundle Module Type.

4 osgi-container
PlainOSGiCDIArchiveType class needs to be created as a service of ArchiveType @Contract, if not creating the class, SnifferManagerImpl's getApplicableSniffers method can not add WeldSniffer successfully.

Please review these files.

Comment by Sanjeeb Sahoo [ 25/Oct/12 ]

From an initial look, they all look fine except the addition of a new module type and its use inside WeldSniffer. I think we should avoid using WeldSniffer. We should invoke Weld directly during deployment. I will let Siva comment on this.

Comment by TangYong [ 26/Oct/12 ]

>We should invoke Weld directly during deployment.
Indeed, invoking Weld directly is a good idea because I have found that using WeldSniffer is not a right solution because once using WeldSniffer, on the second phrase, deployment will trigger a org.glassfish.internal.deployment.Deployment.APPLICATION_LOADED event which will be listened by org.glassfish.weld.WeldDeployer, then WeldDeploy will start Weld Container. This looks very fine, but current gf weld integration only considers JavaEE related mode[1], rathen than pure OSGi or SE mode.

So, if invoking Weld directly on deploying, we should do the following-liking in order:

(1) WeldBootstrap bootstrap = new WeldBootstrap();
(2) DeploymentImpl deploymentImpl = new DeploymentImpl(archive, ejbs, deploymentContext);
(3) List<BeanDeploymentArchive> archives = deploymentImpl.getBeanDeploymentArchives();
(4) deploymentImpl.buildDeploymentGraph();
(5) bootstrap.startContainer(Environments.SE, deploymentImpl);
(6) bootstrap.startInitialization();
(7) fireProcessInjectionTargetEvents(bootstrap, deploymentImpl);
(8) bootstrap.deployBeans();

Let us see the above sequence:

1. about DeploymentImpl and BeanDeploymentArchive
I have not still made sure whether the two essential classes can be used in pure OSGi or SE mode because most of them are related to JavaEE.

2 about bootstrap.startContainer(Environments.SE, deploymentImpl);
Whether 1st Parameter is Environments.SE or others(including we create a implementation of Enviroment. Note: Weld-OSGi creates a implementation of Enviroment) or not needs to be investigated.

3 about fireProcessInjectionTargetEvents(bootstrap, deploymentImpl);
Whether needing the call or not needs to be investigated.

I will listen to Siva and Sahoo's comments.

[1]: I have found a exception on using WeldSniffer, and made sure that using WeldSniffer is not a good solution.

[#|2012-10-25T15:15:16.671+0900|WARNING|44.0|javax.enterprise.system.core.org.glassfish.kernel.event|_ThreadID=13;_ThreadName=pool-17-thread-1;_TimeMillis=1351145716671;_LevelValue=900;|Exception while dispatching an event
java.lang.RuntimeException: Error binding app-level env dependencies null
at com.sun.enterprise.container.common.impl.managedbean.ManagedBeanManagerImpl.registerAppLevelDependencies(ManagedBeanManagerImpl.java:176)
at com.sun.enterprise.container.common.impl.managedbean.ManagedBeanManagerImpl.event(ManagedBeanManagerImpl.java:136)
at org.glassfish.kernel.event.EventsImpl.send(EventsImpl.java:128)
at org.glassfish.internal.data.ApplicationInfo.load(ApplicationInfo.java:275)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:502)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:228)
at org.glassfish.osgijavaeebase.OSGiDeploymentRequest.deploy(OSGiDeploymentRequest.java:183)
at org.glassfish.osgijavaeebase.OSGiDeploymentRequest.execute(OSGiDeploymentRequest.java:118)
at org.glassfish.osgijavaeebase.AbstractOSGiDeployer.deploy(AbstractOSGiDeployer.java:123)
at org.glassfish.osgijavaeebase.OSGiContainer.deploy(OSGiContainer.java:154)
at org.glassfish.osgijavaeebase.JavaEEExtender.deploy(JavaEEExtender.java:109)
at org.glassfish.osgijavaeebase.JavaEEExtender.access$200(JavaEEExtender.java:61)
at org.glassfish.osgijavaeebase.JavaEEExtender$HybridBundleTrackerCustomizer$1.call(JavaEEExtender.java:153)
at org.glassfish.osgijavaeebase.JavaEEExtender$HybridBundleTrackerCustomizer$1.call(JavaEEExtender.java:150)
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)
Caused by: javax.naming.NamingException: Null appName
at com.sun.enterprise.naming.impl.GlassfishNamingManagerImpl.getAppNamespace(GlassfishNamingManagerImpl.java:432)
at com.sun.enterprise.naming.impl.GlassfishNamingManagerImpl.bindToAppNamespace(GlassfishNamingManagerImpl.java:595)
at com.sun.enterprise.container.common.impl.ComponentEnvManagerImpl.bindToComponentNamespace(ComponentEnvManagerImpl.java:208)
at com.sun.enterprise.container.common.impl.managedbean.ManagedBeanManagerImpl.registerAppLevelDependencies(ManagedBeanManagerImpl.java:174)
... 18 more

Comment by TangYong [ 26/Oct/12 ]

The improvement is very critical to implement the whole RFC146(OSGi/CDI) and I will postpone other OSGi/CDI features's implementation until the problem is resolved.

In addition, remembering siva's "Typesafe injection of dynamic OSGi services in hybrid Java EE applications"(https://blogs.oracle.com/sivakumart/entry/typesafe_injection_of_dynamic_osgi) , the sample used a servlet consumer,

public class StockQuoteServlet extends HttpServlet

{ @Inject @OSGiService(/\* wait for 1 min \*/ waitTimeout=60\*1000) StockQuoteService sqs; ... }

Servlet consumer is one of of consumers of OSGi/CDI @OSGiService, and plain OSGi bundle should be also another use case, if the improvement can not be resolved, @OSGiService can not be used in plain OSGi bundle's use case,let alone say @Publish ...

Comment by Sivakumar Thyagarajan [ 26/Oct/12 ]

Hi Tang

I agree with Sahoo and you that we should not use WeldSniffer. It unnecessarily ties the osgi-cdi implementation to the weld-integration module in GlassFish. We should see the work you are doing in OSGi-CDI as only meant to support OSGi bundles as CDI bean archives, and leave the support for Java EE CDI bean archives to the Weld integration. Directly using the Weld SPI to do deployment of bean archives is the right approach.

> 1. about DeploymentImpl and BeanDeploymentArchive
> I have not still made sure whether the two essential classes can be used in pure OSGi or SE mode
> because most of them are related to JavaEE.

Yes, these SPI implementations in the weld-integration module is very EE specific and may not be useful as is to you. Could you please look at implementing light-weight implementations of these to just support the "OSGi bundles as bean archives" scenario.

> 2 about bootstrap.startContainer(Environments.SE, deploymentImpl);
> Whether 1st Parameter is Environments.SE or others(including we create a implementation of
> Enviroment. Note: Weld-OSGi creates a implementation of Enviroment) or not needs to be
> investigated.

For now let us assume that the support for "OSGi bundles as bean archives" is just an SE style environment as we don't need to support EE style resource injection, transactions, Servlet, EJB etc. So let us start with reusing Environments.SE.

Firing ProcessInjectionTarget events was done in DeploymentImpl for handling non-contextual EE components such as Services. In this case, this may not be needed.

Thanks.

Comment by TangYong [ 28/Oct/12 ]

Thanks siva's confirmation and sahoo's change on the improvement's title.

>Yes, these SPI implementations in the weld-integration module is very EE specific and may not be useful as is to
>you. Could you please look at implementing light-weight implementations of these to just support the "OSGi bundles >as bean archives" scenario.
I am investigating this.

>For now let us assume that the support for "OSGi bundles as bean archives" is just an SE style environment as we >don't need to support EE style resource injection, transactions, Servlet, EJB etc. So let us start with reusing >Environments.SE.
On Weld-OSGi project and ops4j.pax.cdi project, they all create a new environment used for OSGi/CDI rather than using Environments.SE, so, I must investigate the reason that they do not use Environments.SE directly.

>Firing ProcessInjectionTarget events was done in DeploymentImpl for handling non-contextual EE components such as >Services. In this case, this may not be needed.
OK, I see.

In addition, I will add a topic as following:

Needing to investigate that ,by overriding which method, directly using the Weld SPI is to do deployment of bean archives.

Comment by TangYong [ 29/Oct/12 ]

Hi siva, sahoo,

I have implemented the improvement and have made a @Publish test(based my current @Publish implementation). Please review the patch(20121029). I want to make a description about essential classes of the patch.

1) OSGiBeanDeploymentArchiveImpl
>Yes, these SPI implementations in the weld-integration module is very EE specific and may >not be useful as is to you. Could you please look at implementing light-weight >implementations of these to just support the "OSGi bundles as bean archives" scenario.

the class is a OSGi bundles bean archives's implementation

2) OSGiBeanDeploymentArchiveFactory
its role is scanning current bundle and finding beans.xml and bean classes used by weld

3) OSGiBeanDeployment
used by WeldBootstrap to start weld container

4) OSGiCDIDeploymentRequest
>Needing to investigate that ,by overriding which method, directly using the Weld SPI is >to do deployment of bean archives.

Overriding postDeploy() method to trigger Weld SPI directly.

5) OSGiServicePublisher and Publish and ServiceProperties and Property
handling @Publish and registering current Bean into OSGi, I will discuss @Publish in Glassfish-18938

6) about Environments.SE
Currently, using Environments.SE looks fine.

Thanks

Comment by TangYong [ 29/Oct/12 ]

Hi sahoo,siva

On testing the improvement based my patch, I found two problem on stopping domain:

1) osgi-ejb-container

After I deployed a plain bundle with beans.xml, while I was executing "asadmin stop-domain", the following exception happened on server.log,

[#|2012-10-29T18:57:24.843+0900|SEVERE|44.0|javax.enterprise.logging.stderr|_ThreadID=14;_ThreadName=Thread-16;_TimeMillis=1351504644843;_LevelValue=1000;|java.lang.NullPointerException
at org.glassfish.osgiejb.OSGiEJBDeployer$EJBTracker.removedService(OSGiEJBDeployer.java:236)
at org.osgi.util.tracker.ServiceTracker$Tracked.customizerRemoved(ServiceTracker.java:1006)
at org.osgi.util.tracker.ServiceTracker$Tracked.customizerRemoved(ServiceTracker.java:906)
at org.osgi.util.tracker.AbstractTracked.untrack(AbstractTracked.java:352)
at org.osgi.util.tracker.ServiceTracker$Tracked.serviceChanged(ServiceTracker.java:949)
at org.apache.felix.framework.util.EventDispatcher.invokeServiceListenerCallback(EventDispatcher.java:932)
at org.apache.felix.framework.util.EventDispatcher.fireEventImmediately(EventDispatcher.java:793)
at org.apache.felix.framework.util.EventDispatcher.fireServiceEvent(EventDispatcher.java:543)
at org.apache.felix.framework.Felix.fireServiceEvent(Felix.java:4260)
at org.apache.felix.framework.Felix.access$000(Felix.java:74)
at org.apache.felix.framework.Felix$1.serviceChanged(Felix.java:390)
at org.apache.felix.framework.ServiceRegistry.unregisterService(ServiceRegistry.java:148)
at org.apache.felix.framework.ServiceRegistrationImpl.unregister(ServiceRegistrationImpl.java:127)
at org.glassfish.osgijavaeebase.OSGiContainer.undeploy(OSGiContainer.java:184)
at org.glassfish.osgijavaeebase.AbstractOSGiDeployer.undeployAll(AbstractOSGiDeployer.java:168)
at org.glassfish.osgijavaeebase.AbstractOSGiDeployer.unregister(AbstractOSGiDeployer.java:115)
at org.glassfish.osgicdi.impl.OSGiCDIExtender.stop(OSGiCDIExtender.java:72)
at org.glassfish.osgijavaeebase.ExtenderManager$ExtenderTracker.removedService(ExtenderManager.java:153)
at org.osgi.util.tracker.ServiceTracker$Tracked.customizerRemoved(ServiceTracker.java:1006)
at org.osgi.util.tracker.ServiceTracker$Tracked.customizerRemoved(ServiceTracker.java:906)
at org.osgi.util.tracker.AbstractTracked.untrack(AbstractTracked.java:352)
at org.osgi.util.tracker.ServiceTracker.close(ServiceTracker.java:412)
at org.glassfish.osgijavaeebase.ExtenderManager.stopExtenders(ExtenderManager.java:122)
at org.glassfish.osgijavaeebase.ExtenderManager.access$400(ExtenderManager.java:67)
at org.glassfish.osgijavaeebase.ExtenderManager$GlassFishServerTracker$1$1.event(ExtenderManager.java:197)
at org.glassfish.kernel.event.EventsImpl.send(EventsImpl.java:128)
at com.sun.enterprise.v3.server.AppServerStartup.stop(AppServerStartup.java:324)
at com.sun.enterprise.glassfish.bootstrap.GlassFishImpl.stop(GlassFishImpl.java:88)
at com.sun.enterprise.glassfish.bootstrap.GlassFishDecorator.stop(GlassFishDecorator.java:68)
at com.sun.enterprise.glassfish.bootstrap.osgi.EmbeddedOSGiGlassFishImpl.stop(EmbeddedOSGiGlassFishImpl.java:80)
at com.sun.enterprise.v3.admin.StopServer.doExecute(StopServer.java:78)
at com.sun.enterprise.v3.admin.StopDomainCommand.execute(StopDomainCommand.java:95)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2.execute(CommandRunnerImpl.java:549)
at org.glassfish.api.AsyncImpl$1$1.run(AsyncImpl.java:79)

#]

I analysed for a while and made a modification for EJBTracker.removedService method 236 line as following,

Application app = ai.getMetaData(Application.class);
if (app != null )

{ Collection<DolAdapter.EjbDescriptor> ejbs = DolAdapter.convert(app.getEjbDescriptors()); ... }

super.removedService(reference, service);

I found that while deploying a plain bundle with beans.xml, ApplicationInfo of the bundle has no metadata, so, NullPointerException happened. However, I also doubted whether the exception was caused by my patch or not?

2)AbstractOSGiDeployer.getGlassFish

After I made the above modification, the 1) exception did not happen, however, another exception happened on the server.log,

[#|2012-10-29T18:57:24.843+0900|WARNING|44.0|org.glassfish.osgijavaeebase|_ThreadID=14;_ThreadName=Thread-16;_TimeMillis=1351504644843;_LevelValue=900;|Failed to undeploy bundle sample.osgicdi.stockquote_service_usingcdi [280]
java.lang.NullPointerException: Specified service reference cannot be null.
at org.apache.felix.framework.BundleContextImpl.getService(BundleContextImpl.java:458)
at org.glassfish.osgijavaeebase.AbstractOSGiDeployer.getGlassFish(AbstractOSGiDeployer.java:197)
at org.glassfish.osgijavaeebase.AbstractOSGiDeployer.getReport(AbstractOSGiDeployer.java:149)
at org.glassfish.osgijavaeebase.AbstractOSGiDeployer.undeploy(AbstractOSGiDeployer.java:137)
at org.glassfish.osgijavaeebase.OSGiContainer.undeploy(OSGiContainer.java:193)
at org.glassfish.osgijavaeebase.AbstractOSGiDeployer.undeployAll(AbstractOSGiDeployer.java:168)
at org.glassfish.osgijavaeebase.AbstractOSGiDeployer.unregister(AbstractOSGiDeployer.java:115)
at org.glassfish.osgicdi.impl.OSGiCDIExtender.stop(OSGiCDIExtender.java:72)
at org.glassfish.osgijavaeebase.ExtenderManager$ExtenderTracker.removedService(ExtenderManager.java:153)
at org.osgi.util.tracker.ServiceTracker$Tracked.customizerRemoved(ServiceTracker.java:1006)
at org.osgi.util.tracker.ServiceTracker$Tracked.customizerRemoved(ServiceTracker.java:906)
at org.osgi.util.tracker.AbstractTracked.untrack(AbstractTracked.java:352)
at org.osgi.util.tracker.ServiceTracker.close(ServiceTracker.java:412)
at org.glassfish.osgijavaeebase.ExtenderManager.stopExtenders(ExtenderManager.java:122)
at org.glassfish.osgijavaeebase.ExtenderManager.access$400(ExtenderManager.java:67)
at org.glassfish.osgijavaeebase.ExtenderManager$GlassFishServerTracker$1$1.event(ExtenderManager.java:197)
at org.glassfish.kernel.event.EventsImpl.send(EventsImpl.java:128)
at com.sun.enterprise.v3.server.AppServerStartup.stop(AppServerStartup.java:324)
at com.sun.enterprise.glassfish.bootstrap.GlassFishImpl.stop(GlassFishImpl.java:88)
at com.sun.enterprise.glassfish.bootstrap.GlassFishDecorator.stop(GlassFishDecorator.java:68)
at com.sun.enterprise.glassfish.bootstrap.osgi.EmbeddedOSGiGlassFishImpl.stop(EmbeddedOSGiGlassFishImpl.java:80)
at com.sun.enterprise.v3.admin.StopServer.doExecute(StopServer.java:78)
at com.sun.enterprise.v3.admin.StopDomainCommand.execute(StopDomainCommand.java:95)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2.execute(CommandRunnerImpl.java:549)
at org.glassfish.api.AsyncImpl$1$1.run(AsyncImpl.java:79)

#]

While I was debugging the exception, the exception happened on AbstractOSGiDeployer.getGlassFish() method 197,
"getBundleContext().getServiceReference(GlassFish.class.getName())" is null, however, I felt very curious,

・Whether on EJB Bundle case or WAB case the exception also happened or not?
・From exception, It seemed that it should be not related to my patch.

I want to listen your comments.
Thanks.

Comment by TangYong [ 29/Oct/12 ]

I attached my test application and I used stockquote_service_usingcdi as deploying sample.

Comment by Sanjeeb Sahoo [ 29/Oct/12 ]

Tang,

1. I agree with your assessment of first exception. We may have to adopt a different strategy for OSGi/CDI instead of implementing them like OSGi/EJB or OSGi/Web. Can you please explore if we can just have an extender which registers a BundleTracker that does what you are doing in OSGiCDIDeploymentRequest?

2. The second exception sounds like a bug to me. Since GlassFish service is getting removed, it is likely that getBundleContext().getServiceReference(GlassFish.class.getName()) is returning null. Can you please try to reproduce it for an EJB bundle or WAB and file a bug?

Very good work, BTW.

Thanks,
Sahoo

Comment by TangYong [ 30/Oct/12 ]

Hi sahoo,

For 1, I will investigate it and at the same time I will also listen to siva's comments for other sources of my patch.

For 2, I will try EJB bundle and WAB and see whether the exception will happen again or not?

Thanks your suggestion.
Tang

Comment by TangYong [ 30/Oct/12 ]

Hi sahoo,

>For 2, I will try EJB bundle and WAB and see whether the exception will happen again or not?
I have confirmed that 2 can be reproduced and please see GLASSFISH-19261 .

Comment by TangYong [ 30/Oct/12 ]

Hi sahoo, siva,

I have attached my new patch according to sahoo's comment and I can deploy stockquote_service_usingcdi.jar successfully, In the patch, modified class is OSGiCDIExtender, and I add BeanBundleTrackerCustomizer to track deployed bundle, once finding the bundle is a plain bundle with beans.xml, I trigger Weld SPI directly.

In addition, after executing stop-domain, previous 1 and 2 exceptions all disappeared in server.log. The following is server.log's contents in my env. Currently, it looks fine.

[#|2012-10-30T21:54:08.531+0900|INFO|44.0|null|_ThreadID=10;_ThreadName=main;_TimeMillis=1351601648531;_LevelValue=800;|Snifer org.glassfish.extras.osgicontainer.OSGiSniffer@343329 set up following modules: []|#]

[#|2012-10-30T21:54:08.921+0900|INFO|44.0|javax.enterprise.logging.stdout|_ThreadID=10;_ThreadName=main;_TimeMillis=1351601648921;_LevelValue=800;|Started sample.osgicdi.stockquote_service_usingcdi [280]|#]

[#|2012-10-30T21:54:08.937+0900|INFO|44.0|javax.enterprise.system.core.com.sun.enterprise.v3.server|_ThreadID=10;_ThreadName=main;_TimeMillis=1351601648937;_LevelValue=800;_MessageID=loading.application.time;|CORE10010: Loading application stockquote_service_usingcdi done in 594 ms|#]

[#|2012-10-30T21:54:08.968+0900|INFO|44.0|org.glassfish.ha.store.spi.BackingStoreFactoryRegistry|_ThreadID=10;_ThreadName=main;_TimeMillis=1351601648968;_LevelValue=800;|Registered org.glassfish.ha.store.adapter.cache.ShoalBackingStoreProxy for persistence-type = replicated in BackingStoreFactoryRegistry|#]

[#|2012-10-30T21:54:08.968+0900|INFO|44.0|javax.enterprise.system.core.com.sun.enterprise.v3.server|_ThreadID=10;_ThreadName=main;_TimeMillis=1351601648968;_LevelValue=800;|GlassFish Server Open Source Edition 4.0 (Administrator-private) startup time : Felix (2,641ms), startup services(1,859ms), total(4,500ms)|#]

[#|2012-10-30T21:54:09.031+0900|INFO|44.0|javax.enterprise.system.core.com.sun.enterprise.v3.services.impl|_ThreadID=10;_ThreadName=main;_TimeMillis=1351601649031;_LevelValue=800;|Grizzly Framework 2.3 started in: 16ms - bound to [/0.0.0.0:7,676]|#]

[#|2012-10-30T21:54:09.109+0900|INFO|44.0|javax.enterprise.system.jmx|_ThreadID=11;_ThreadName=Thread-7;_TimeMillis=1351601649109;_LevelValue=800;_MessageID=AS-JMX-00005;|JMXStartupService has started JMXConnector on JMXService URL service:jmx:rmi://10.167.157.133:8686/jndi/rmi://10.167.157.133:8686/jmxrmi|#]

[#|2012-10-30T21:54:09.171+0900|INFO|44.0|com.sun.enterprise.glassfish.bootstrap.osgi|_ThreadID=10;_ThreadName=main;_TimeMillis=1351601649171;_LevelValue=800;|Registered com.sun.enterprise.glassfish.bootstrap.osgi.EmbeddedOSGiGlassFishImpl@1869971 as OSGi service registration: org.apache.felix.framework.ServiceRegistrationImpl@432685|#]

[#|2012-10-30T21:54:09.531+0900|INFO|44.0|org.jboss.weld.Version|_ThreadID=12;_ThreadName=pool-6-thread-1;_TimeMillis=1351601649531;_LevelValue=800;|WELD-000900 1.1.4 (Final)|#]

[#|2012-10-30T21:54:09.781+0900|INFO|44.0|org.jboss.weld.Bootstrap|_ThreadID=12;_ThreadName=pool-6-thread-1;_TimeMillis=1351601649781;_LevelValue=800;|WELD-000101 Transactional services not available. Injection of @Inject UserTransaction not available. Transactional observers will be invoked synchronously.|#]

[#|2012-10-30T21:54:09.921+0900|WARNING|44.0|org.jboss.interceptor.util.InterceptionTypeRegistry|_ThreadID=12;_ThreadName=pool-6-thread-1;_TimeMillis=1351601649921;_LevelValue=900;|Class 'javax.interceptor.AroundInvoke' not found, interception based on it is not enabled|#]

[#|2012-10-30T21:54:09.921+0900|WARNING|44.0|org.jboss.interceptor.util.InterceptionTypeRegistry|_ThreadID=12;_ThreadName=pool-6-thread-1;_TimeMillis=1351601649921;_LevelValue=900;|Class 'javax.interceptor.AroundTimeout' not found, interception based on it is not enabled|#]

[#|2012-10-30T21:54:09.921+0900|WARNING|44.0|org.jboss.interceptor.util.InterceptionTypeRegistry|_ThreadID=12;_ThreadName=pool-6-thread-1;_TimeMillis=1351601649921;_LevelValue=900;|Class 'javax.ejb.PostActivate' not found, interception based on it is not enabled|#]

[#|2012-10-30T21:54:09.937+0900|WARNING|44.0|org.jboss.interceptor.util.InterceptionTypeRegistry|_ThreadID=12;_ThreadName=pool-6-thread-1;_TimeMillis=1351601649937;_LevelValue=900;|Class 'javax.ejb.PrePassivate' not found, interception based on it is not enabled|#]

[#|2012-10-30T21:54:09.937+0900|INFO|44.0|javax.enterprise.logging.stdout|_ThreadID=12;_ThreadName=pool-6-thread-1;_TimeMillis=1351601649937;_LevelValue=800;|SimpleStockQuoteServiceImplUsingCDI::Initializing quotes|#]

[#|2012-10-30T21:54:09.937+0900|INFO|44.0|javax.enterprise.logging.stdout|_ThreadID=12;_ThreadName=pool-6-thread-1;_TimeMillis=1351601649937;_LevelValue=800;|SimpleStockQuoteServiceImplUsingCDI::getSymbols|#]

[#|2012-10-30T21:54:09.937+0900|INFO|44.0|javax.enterprise.logging.stdout|_ThreadID=12;_ThreadName=pool-6-thread-1;_TimeMillis=1351601649937;_LevelValue=800;|Registered:[IBM, Fujitsu, HPQ, ORCL]|#]

Please Sahoo and Siva review.

Comment by TangYong [ 30/Oct/12 ]

I made a improvement for BeanBundleTrackerCustomizer.addingBundle method,

public Object addingBundle(final Bundle bundle, BundleEvent event) {
if ( !isCDIBundle(bundle) )

{ return null; }

final int state = bundle.getState();

if ( isReady(event, state) )

{ ... }
Comment by TangYong [ 05/Nov/12 ]

There is a problem happened on my test app(Pl. seeing stockquote_cdi_plainclient.zip).

Test Case:

In activator of a plain osgi bundle, I add the following test logic,

public class OSGiPlainClientActivator implements BundleActivator{

@Inject
@OSGiService(/* dynamically bound */ dynamic = true,
/* wait for 1 min */ waitTimeout=1*1000)
StockQuoteService sqs;

public void start(BundleContext arg0) throws Exception

{ System.out.println("OSGiPlainClientActivator::start"); System.out.println("Obtained StockQuotes:" + sqs.getSymbols()); System.out.println("OSGiPlainClientActivator::getting Stock quote service successful"); }

On debugging, I found that sqs is NULL because before sqs is injected, Starting logic of the activator has ended.
So, here has a multi-thread problem and weld container's scanning must happen before the activator's start method.

I will investigate how to fix the problem and also listen to your comments.

The problem is very fatal.

Thanks
Tang

Comment by TangYong [ 05/Nov/12 ]

I forgot to say that while deploying the test bundle, when executing BeanBundleTrackerCustomizer.isReady method, current bundle's state is Starting, the method can not return true on this case, so, I modify the method as following,

private boolean isReady(BundleEvent event, int state)

{ return state == Bundle.ACTIVE || state == Bundle.STARTING; }

However,Modifying the method can not fix the problem, because main reason is multi-thread which I said in previous reply.

Comment by TangYong [ 05/Nov/12 ]

Hi siva, sahoo,

I made an experiment on WAB with beans.xml. I added a activator and @OSGiService on the activator's start method, the same problem happened. So, regardless of JAVAEE bundle or Plain OSGi bundle, the problem all happened.

Comment by TangYong [ 05/Nov/12 ]

I think that the problem is difficult to fix because if a user used OSGi Shell command to stop the test sample and start the sample again, then, on such a case, if using listener or tracker, because they are asynchronous, injection on activator's start method can be still null.

Comment by TangYong [ 05/Nov/12 ]

I have a fix way and use SynchronousBundleListener, I will try it.

Comment by TangYong [ 05/Nov/12 ]

In addition, because glassfish has updated Weld into 1.1.10.Final, I need to update some modified files.
Now, SynchronousBundleListener is a valid fixing solution, however, from testing, I have found another problem(Although abd.addBean(new OSGiServiceBean(svcInjectionPoint)) can be executed successfully, on injection point, sqs has been not injected a bean) and will resolve it, maybe my source has a problem related to classloader.

Comment by Sanjeeb Sahoo [ 05/Nov/12 ]

Tang,

It is perfectly understandable to get an NPE when a bundle activator tries to access an injected field. It happens for two reasons:
a) The bundle activator instance is likely to be not known to the injection manager,
b) The injection happens after a bundle is activated.

So, we should treat it as a user application error.

We should demonstrate the integration using some sort of service tracker as you have mentioned.

Thanks,
Sahoo

Comment by TangYong [ 06/Nov/12 ]

Hi sahoo,siva,

This problem is a litter complex and I want to make a detailed explanation.Firstly, let us see OSGi/CDI's using scene and injection process.

[OSGi/CDI's Using Scene and Injection process]
1 JavaEE Bundle's Injection
Taking a WAB as example, normally @OSGiService injection happens on a servlet as the following,

public class StockQuoteServlet extends HttpServlet

{ @Inject @OSGiService(dynamic = true, waitTimeout=1*1000) StockQuoteService sqs; ... }

in this case, while deploying the WAB, Weld SPI will be triggered and in "AfterBeanDiscovery" of Bean Deployment LifeCycle, a OSGiServiceBean for sqs injectionPoint will be created and added into Weld Bean Manager. Then, while a user accessed the StockQuoteServlet by browser, true injection started and the injection is triggered by WebContainer.

That is to say, in order to obtain a injected bean, there are two critical steps:
1) scanning injectionPoint and adding OSGiServiceBean
2) needing a medium or container to trigger injection

2 Plain Bundle's Injection
Taking my test sample(stockquote_cdi_plainclient.zip) as example, here I used the following test logic on a activator.

public class OSGiPlainClientActivator implements BundleActivator{

@Inject
@OSGiService(dynamic = false, waitTimeout=1*1000)
StockQuoteService sqs;

public void start(BundleContext arg0) throws Exception

{ System.out.println("Obtained StockQuotes:" + sqs.getSymbols()); }

Firstly, I want to express my comments on sahoo's saying "So, we should treat it as a user application error."
I think that BundleActivator is similar to "main" function in java se world, when a StockQuoteService has been available, a user is likely to use the StockQuoteService eagerly. However, just as sahoo's saying, putting @OSGiService into OSGiPlainClientActivator can not finish 2) of two critical steps because the activator has missing the chance of triggering true injection. The result is that you maybe only use OSGi related API to get StockQuoteService. This is true?

After I evaluated Weld-OSGi's a standalone example, I found that Weld-OSGi used a interesting using way to resolve the problem rather than using OSGi related API, please seeing the following.

public class StandaloneActivator implements BundleActivator {

private EmbeddedContainer embedded;
private EmbeddedCDIContainer container;
private MyService service;

@Override
public void start(BundleContext context) throws Exception

{ embedded = new EmbeddedContainer(context); container = embedded.initialize(); service = container.getInstance().select(MyService.class).get(); System.out.println(service.hello()); System.out.println(service.admin()); System.out.println(service.adminAvailable()); }


...
}

public class MyService

{ @Inject @OSGiService private PackageAdmin admin; ... }

In the StandaloneActivator's start method, MyService can be obtained by using Weld's Instance<Object> way. In order to make effect, you must use a medium(Weld-OSGi uses EmbeddedContainer) to trigger Weld SPI and save Bean Manager, then by this Bean Manager, you can obtain Instance<Object>.

However, for Glassfish, if we also offer such a medium, we must make a classification, and once a user uses the medium to trigger Weld SPI directly, because on gf's deploying phrase , Weld SPI will be also triggered, that is to say, there are two places which will trigger Weld SPI. For the problem, Weld-OSGi used a trick that if the bundle's meta-data includes "Embedded-CDIContainer: =true", Weld SPI will be only triggered in the bundle's activator, otherwise, Weld SPI will be triggered by Weld-OSGi related bundles.

I wish that I can express more clear, and maybe we will create another feature for stating the problem.

Thanks
Tang

Comment by TangYong [ 06/Nov/12 ]

>However, for Glassfish, if we also offer such a medium, we must make a classification, and once a user uses the >medium to trigger Weld SPI directly, because on gf's deploying phrase , Weld SPI will be also triggered, that is to
Maybe there is another way other than using a medium to resolve the problem, and we maybe use Event integration. For example, for OSGiPlainClientActivator, the user can write the following,

public class OSGiPlainClientActivator implements BundleActivator{

private StockQuoteService sqs;

public void start(BundleContext arg0) throws Exception

{...}

public void bindService(@Observes @Contracts(StockQuoteService.class) ServiceEvents.ServiceArrival event)

{ System.out.println("bind : " + event.getServiceClassNames()); sqs = event.getService(ShapeProvider.class); System.out.println("Obtained StockQuotes:" + sqs.getSymbols()); }

by this way, while StockQuoteService is available, bindService as a Observer can be called back to inject StockQuoteService into sqs.

Comment by Sanjeeb Sahoo [ 06/Nov/12 ]

Even the event integration approach won't ensure that injection happens before BundleActivator.start().

As I said earlier, I would keep it simple as we have done for OSGi/EJB and OSGi/Web. Once a bundle is ready (either ACTIVE or STARTING if activation-policy is lazy), we should scan the bundle and add the beans to the underlying CDI bean archive.

I don't like the approach of bootstrapping a CDI runtime inside BundleActivator.start(). If someone does that, then they are not leveraging OSGi/CDI integration and we should not care about those bundles.

BTW, can you add a marker header which must be present in a bundle to tell us that we should introspect the bundle as a CDI enabled bundle? Something like Meta-CDI header whose semantics can be same as Meta-Persistence header of OSGi/JPA spec. Only bundles having this header should be considered by OSGi/CDI layer.

Comment by TangYong [ 06/Nov/12 ]

>Even the event integration approach won't ensure that injection happens before BundleActivator.start().
My means is that event integration should happen after BundleActivator.start() and similar to postConstruct function, and such a way, we recommend a user does not add logic related injection in BundleActivator.start().

>BTW, can you add a marker header which must be present in a bundle to tell us that we should introspect the bundle >as a CDI enabled bundle? Something like Meta-CDI header whose semantics can be same as Meta-Persistence header of >OSGi/JPA spec. Only bundles having this header should be considered by OSGi/CDI layer.
Hi sahoo, I think that this is not required because beans.xml has been a enabled flag that will be considered by OSGi/CDI layer.If the bundle does not contain beans.xml, it should be considered by OSGi/CDI layer and this also meets general rule of JSR 299.

>I don't like the approach of bootstrapping a CDI runtime inside BundleActivator.start(). If someone does that, then >they are not leveraging OSGi/CDI integration and we should not care about those bundles.
I want to say that you can not understand my means, when the user bootstrapps a CDI runtime inside BundleActivator.start(), in reality, he/she should use a medium to bootstrap and the medium is offered by OSGi/CDI layer. If he/she bootstrapps a CDI runtime using himself/herself medium, we should not care about these bundles.

>As I said earlier, I would keep it simple as we have done for OSGi/EJB and OSGi/Web. Once a bundle is ready >(either ACTIVE or STARTING if activation-policy is lazy), we should scan the bundle and add the beans to the >underlying CDI bean archive.
I can understand the point and activator's scene is a special use case, on such a use case, beans has been added, however, the use case cares about how to obtain these added beans. Of course, I maybe considered too much.

OK, let me leave the problem and do @publish related tests.

Comment by Sanjeeb Sahoo [ 06/Nov/12 ]

1. As long as user does not use the injected field in activator.start(), it's fine.

2. Scanning every bundle for existence of META-INF/beans.xml is not correct. OSGi/JPA could have done the same for META-INF/persistence.xml. The issue here is before we scan a bundle, we need an explicit approval from the bundle whether it wants to be scanned or not. The presence of the header is considered as an approval. There is another reason for having the header. Imagine a scenario where the bundle wants to bootstrap CDI runtime itself bypassing OSGi/CDI integration facility. We can't support it unless we have such a header.

3. No, we can't provide an API to bootstrap CDI runtime. If user bootstraps themselves, we don't come into picture.

Comment by TangYong [ 06/Nov/12 ]

OK, I will investigate and add such a head.
Thanks.

Tang

Comment by Sanjeeb Sahoo [ 06/Nov/12 ]

Here are some basic requirements:
a) A CDI bean that's published as OSGi service must be using Singleton scope to match with lifecycle of OSGi services. e.g.,

@Publish
@Singleton
public class FooBean {}

In other words, following example must be treated as an error:
@Publish
public class FooBean {}

a) A CDI bean that's published as OSGi service must always consumed as an OSGi Service. In other words, following sample should fail as BarBean is trying to reference FooBean as a regular bean:

@Publish
@Singleton
public class FooBean {}

public class BarBean

{ @Inject FooBean foo; }

For it to work, it should look like this:
public class BarBean

{ @Inject @OSGiService FooBean foo; }

or
public class BarBean {
public void somemethod()

{ BundleContext bundleContext = // somehow obtain BundleContext bundleContext.getServiceReference(FooBean.class.getname(),...); }

}

Thanks,
Sahoo

Comment by TangYong [ 06/Nov/12 ]

Thanks for clarifying test case's requirements.

Tang

Comment by Sivakumar Thyagarajan [ 09/Nov/12 ]

It appears that in the patch you are resetting the SingletonProvider after a plain cdi osgi bundle deployment is complete. What happens if:
1. a CDI-enabled EAR was first depoyed (which would have setup the SingletonProvider in Weld to ACLSingletonProvider
2. A plain cdi osgi bundle is deployed, which would have reset the SingletonProvider to null.
3. Another CDI-enabled EAR is deployed. Since the ACLSingletonProvider was set only on the WeldActivator, the SingletonProvider would not be set to ACLSingletonProvider and hence this CDI-enabled EAR would use the default TCCLSingletonProvider. Isn't this wrong? Shouldn't we reset in step #2 to the earlier used SingletonProvider?

Comment by TangYong [ 09/Nov/12 ]

Thanks siva's comments very much!

Yes, you are right, and I add a comment about SingletonProvider. When defaultly triggering bootstrap.startInitialization() using Weld SPI, SingletonProvider's instance is IsolatedStaticSingletonProvider. So, I made the following fix, and lately, I will attch my newest patch.

if (SingletonProvider.instance() instanceof IsolatedStaticSingletonProvider)

{ SingletonProvider.reset(); }

Thanks.
Tang

Comment by TangYong [ 09/Nov/12 ]

The attachment(GLASSFISH-19215-patch_20121109.zip) is my newest patch for this feature.

In addition, I added a GlassFish-CDIEnabled metadata handling logic according to sahoo's suggestion.

Comment by TangYong [ 09/Nov/12 ]

Combined with sahoo and siva's comments and some issues found in integration tests, the newest patch has the following problems:

1 About SingletonProvider's initialize

Needs to consider multi-thread scene. I tried to directly start Weld-Integration bundle before triggering Weld-SPI , anything seemed to be fine. However, when combining with Weld Bootstrap's shutdown(now, handling logic is my local patch rather than appearing on my patch), because Weld-Integration's activate has a stop method which will reset SingletonProvider, we must take care of the point while managing Weld Bootstrap's shutdown in osgi-cdi module.

2 About position of publishing the beans

Better design is to make OSGiServiceExtension to publish beans in order that publish feature can work in hybrid javaee bundle.

The reason that I put the logic of publishing beans in OSGiCDIExtender is that I need to use Instance<object> to get bean service instance object, so we must get WeldManager, however, OSGiServiceExtension can not help me get Instance<object>.

3 About a exception called "WELD-001408 Unsatisfied dependencies "
After I deployed CDI OSGi Bundles, if I stop domain, and again start domain, deployed bundles should work normally, however, a exception happened in server.log,

org.glassfish.deployment.common.DeploymentException: WELD-001408 Unsatisfied dependencies for type [StockQuoteService] with qualifiers [@OSGiService] at injection point [[field] @Inject @OSGiService org.acme.cdiwab.impl.StockQuoteServlet.sqs]

4 About Weld Bootstrap's shutdown related handling
Doing.

Please siva and sahoo review in depth.

Thanks
Tang

Comment by TangYong [ 12/Nov/12 ]

>2 About position of publishing the beans
>Better design is to make OSGiServiceExtension to publish beans in order that publish feature can work in hybrid >javaee bundle.
>The reason that I put the logic of publishing beans in OSGiCDIExtender is that I need to use Instance<object> to get >bean service instance object, so we must get WeldManager, however, OSGiServiceExtension can not help me get >Instance<object>.

I have confirmed that in OSGiServiceExtension.beforeBeanDiscovery method, adding the second parameter BeanManager manager can get SPI Manager(WeldManager), seeing following:

void beforeBeanDiscovery(@Observes BeforeBeanDiscovery bdd, BeanManager manager){
debug("beforeBeanDiscovery" + bdd);
bdd.addQualifier(OSGiService.class); //XXX:needed?

if (manager instanceof WeldManager)

{ this.manager = (WeldManager)manager; }

}

Then, in afterBeanDiscovery method, executing publishOSGiService should be good and can work for hybrid javaee bundle.

However, once using the above way, in OSGiServiceExtension, we just put a cdi implementation's dependency called org.jboss.weld.manager.api, if not minding this, I think that the way should be good.

In addition, please seeing https://issues.jboss.org/browse/CDI-14, and maybe in the future, CDI Specification will add a portable method called "Instance<Object> instance()", so, I suggest that firstly we use the above way, then, once new api published, we can modify and use that new api.

Thanks.
-Tang

Comment by TangYong [ 12/Nov/12 ]

>3 About a exception called "WELD-001408 Unsatisfied dependencies "
>After I deployed CDI OSGi Bundles, if I stop domain, and again start domain, deployed bundles should work normally, >however, a exception happened in server.log,

>org.glassfish.deployment.common.DeploymentException: WELD-001408 Unsatisfied dependencies for type >[StockQuoteService] with qualifiers [@OSGiService] at injection point [[field] @Inject @OSGiService >org.acme.cdiwab.impl.StockQuoteServlet.sqs]

I have sent two problems to you and siva and hong related the issue.

Tang

Comment by TangYong [ 12/Nov/12 ]

>4 About Weld Bootstrap's shutdown related handling
>Doing.

I consider that the issue's priority should be lower than 1,2, and 3 and fighterfish related test cases.

I think that let me implement 1,2,3 and fighterfish test cases firstly.

Thanks.
Tang

Comment by TangYong [ 14/Nov/12 ]

The attachment(GLASSFISH-19215-patch_20121114.zip) is the newest patch which has resolved 4 subtasks and passed my local integration test case.

Please sahoo and siva review it, and I will write fighterfish test cases(the fifth subtask).

Thanks.
Tang

Comment by TangYong [ 22/Nov/12 ]

Combined with GLASSFISH-15365 and GLASSFISH-19359, I have added into fixing for them and made some adjustment of 19215.

Now, the attachment(GLASSFISH-19215_fighterfishtestcase_final_20121122.zip) has passed the fighterfish tests which I have uploaded in my local env.

Please sahoo and siva review and confirm the version.

Comment by TangYong [ 05/Dec/12 ]

Yesterday, Siva has spent a lot of time to review my patch(GLASSFISH-19215_fighterfishtestcase_final_20121122.zip) and I arranged review contents in excel form in order to see and discuss them better. Please seeing attachment(reviewing_siva.xls).

Comment by TangYong [ 10/Dec/12 ]

Current fixing state has been uploaded, please seeing reviewing_siva_2012.12.10.xls

Comment by TangYong [ 11/Dec/12 ]

Currently, all problems from review other than splitting patch and needing to discuss have been fixed, about status, please seeing reviewing_siva_2012.12.11.xls.

Tomorrow, I will finish the working of splitting patch.

Comment by TangYong [ 11/Dec/12 ]

Splited patch for Glassfish-19215 is uploaded, please seeing GLASSFISH-19215-patch-20121211.zip





[GLASSFISH-19423] Using custom Qualifier on a @Publish class failed Created: 10/Dec/12  Updated: 11/Dec/12

Status: Open
Project: glassfish
Component/s: OSGi-JavaEE
Affects Version/s: future release
Fix Version/s: None

Type: Bug Priority: Critical
Reporter: TangYong Assignee: Sanjeeb Sahoo
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

[Problem Description]
While using the following custom Qualifier(@Blue) on a @Publish class to register OSGi service,

@Publish(contracts =

{MyServiceInf.class}

)
@Blue
public class MyService implements MyServiceInf{
...
}

The following exception will happen,

[#|2012-12-10T19:32:50.421+0900|SEVERE|44.0|javax.enterprise.logging.stderr|_ThreadID=12;_ThreadName=admin-listener(1);_TimeMillis=1355135570421;_LevelValue=1000;|org.jboss.weld.exceptions.UnsatisfiedResolutionException: WELD-001308 Unable to resolve any beans for Types: [class org.acme.myservice.MyService]; Bindings: [QualifierInstance{annotationClass=interface javax.enterprise.inject.Default, values={}, hashCode=477945538}, QualifierInstance{annotationClass=interface javax.enterprise.inject.Any, values={}, hashCode=249261545}, QualifierInstance{annotationClass=interface org.acme.myservice.api.Blue, values={}, hashCode=668150471}]
at org.jboss.weld.manager.BeanManagerImpl.getBean(BeanManagerImpl.java:699)
at org.jboss.weld.bean.builtin.InstanceImpl.get(InstanceImpl.java:102)
at org.glassfish.osgicdi.impl.OSGiServicePublisher.registerOSGiService(OSGiServicePublisher.java:86)
at org.glassfish.osgicdi.impl.OSGiServiceExtension.publishOSGiService(OSGiServiceExtension.java:332)
at org.glassfish.osgicdi.impl.OSGiServiceExtension.afterDeploymentValidation(OSGiServiceExtension.java:264)
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.jboss.weld.util.reflection.SecureReflections$13.work(SecureReflections.java:267)
at org.jboss.weld.util.reflection.SecureReflectionAccess.run(SecureReflectionAccess.java:52)
at org.jboss.weld.util.reflection.SecureReflectionAccess.runAsInvocation(SecureReflectionAccess.java:137)
at org.jboss.weld.util.reflection.SecureReflections.invoke(SecureReflections.java:263)
at org.jboss.weld.introspector.jlr.WeldMethodImpl.invokeOnInstance(WeldMethodImpl.java:170)
at org.jboss.weld.introspector.ForwardingWeldMethod.invokeOnInstance(ForwardingWeldMethod.java:51)
at org.jboss.weld.injection.MethodInjectionPoint.invokeOnInstanceWithSpecialValue(MethodInjectionPoint.java:154)
at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:245)
at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:233)
at org.jboss.weld.event.ObserverMethodImpl.notify(ObserverMethodImpl.java:213)
at org.jboss.weld.bootstrap.events.AbstractContainerEvent.fire(AbstractContainerEvent.java:75)
at org.jboss.weld.bootstrap.events.AbstractDeploymentContainerEvent.fire(AbstractDeploymentContainerEvent.java:46)
at org.jboss.weld.bootstrap.events.AfterDeploymentValidationImpl.fire(AfterDeploymentValidationImpl.java:31)
at org.jboss.weld.bootstrap.WeldBootstrap.validateBeans(WeldBootstrap.java:382)
at org.glassfish.osgicdi.impl.OSGiCDIExtender$BeanBundleTrackerCustomizer.addingBundle(OSGiCDIExtender.java:235)
at org.osgi.util.tracker.BundleTracker$Tracked.customizerAdding(BundleTracker.java:482)
at org.osgi.util.tracker.BundleTracker$Tracked.customizerAdding(BundleTracker.java:424)
at org.osgi.util.tracker.AbstractTracked.trackAdding(AbstractTracked.java:262)
at org.osgi.util.tracker.AbstractTracked.track(AbstractTracked.java:234)
at org.osgi.util.tracker.BundleTracker$Tracked.bundleChanged(BundleTracker.java:457)
at org.apache.felix.framework.util.EventDispatcher.invokeBundleListenerCallback(EventDispatcher.java:868)
at org.apache.felix.framework.util.EventDispatcher.fireEventImmediately(EventDispatcher.java:789)
at org.apache.felix.framework.util.EventDispatcher.fireBundleEvent(EventDispatcher.java:514)
at org.apache.felix.framework.Felix.fireBundleEvent(Felix.java:4244)
at org.apache.felix.framework.Felix.startBundle(Felix.java:1923)
at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:944)
at org.glassfish.extras.osgicontainer.OSGiDeployedBundle.startBundle(OSGiDeployedBundle.java:107)
at org.glassfish.extras.osgicontainer.OSGiDeployedBundle.resume(OSGiDeployedBundle.java:83)
at org.glassfish.extras.osgicontainer.OSGiDeployedBundle.start(OSGiDeployedBundle.java:67)
at org.glassfish.internal.data.EngineRef.start(EngineRef.java:122)
at org.glassfish.internal.data.ModuleInfo.start(ModuleInfo.java:278)
at org.glassfish.internal.data.ApplicationInfo.start(ApplicationInfo.java:299)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:507)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:229)
at org.glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java:489)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:539)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:535)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAs(Subject.java:337)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2.execute(CommandRunnerImpl.java:534)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:565)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1449)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1500(CommandRunnerImpl.java:119)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1759)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1709)
at org.glassfish.admin.rest.resources.admin.CommandResource.executeCommand(CommandResource.java:487)
at org.glassfish.admin.rest.resources.admin.CommandResource.execCommandSimpInMultOut(CommandResource.java:255)
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.glassfish.jersey.server.model.ResourceMethodInvocationHandlerFactory$1.invoke(ResourceMethodInvocationHandlerFactory.java:80)
at org.glassfish.jersey.server.model.AbstractJavaResourceMethodDispatcher.invoke(AbstractJavaResourceMethodDispatcher.java:107)
at org.glassfish.jersey.server.model.JavaResourceMethodDispatcherProvider$ResponseOutInvoker.doDispatch(JavaResourceMethodDispatcherProvider.java:146)
at org.glassfish.jersey.server.model.AbstractJavaResourceMethodDispatcher.dispatch(AbstractJavaResourceMethodDispatcher.java:80)
at org.glassfish.jersey.server.model.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:354)
at org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:349)
at org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:97)
at org.glassfish.jersey.server.ServerRuntime$1.run(ServerRuntime.java:204)
at org.glassfish.jersey.process.internal.RequestScope.runInScope(RequestScope.java:316)
at org.glassfish.jersey.server.ServerRuntime.process(ServerRuntime.java:180)
at org.glassfish.jersey.server.ApplicationHandler.handle(ApplicationHandler.java:796)
at org.glassfish.jersey.grizzly2.httpserver.GrizzlyHttpContainer.service(GrizzlyHttpContainer.java:306)
at org.glassfish.admin.rest.adapter.RestAdapter$1.service(RestAdapter.java:327)
at org.glassfish.admin.rest.adapter.RestAdapter.service(RestAdapter.java:189)
at com.sun.enterprise.v3.server.HK2Dispatcher.dispatch(HK2Dispatcher.java:113)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:236)
at org.glassfish.grizzly.http.server.HttpHandler.doHandle(HttpHandler.java:164)
at org.glassfish.grizzly.http.server.HttpServerFilter.handleRead(HttpServerFilter.java:175)
at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:265)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:200)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:134)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:112)
at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77)
at org.glassfish.grizzly.nio.transport.TCPNI|#]



 Comments   
Comment by TangYong [ 10/Dec/12 ]

The feature is very important and once implementing the feature, an user can use custom qualifier to register a OSGi Service, and the qualifier plays a role of Service Property.

Currently, because of some problem, the custom qualifier can not be resolved by cdi container.

Needing to investigate the reason in depth.

In addition, the feature is related to OSGiServicePublisher.getServiceProperties().

Comment by TangYong [ 11/Dec/12 ]

While testing in hybrid javaee bundle scene, the same problem happened.

[Direct Reason]
TypeSafeBeanResolver's resolved field is empty and this caused that while calling "resolve(R resolvable, boolean cache)" method, "resolved.get(wrappedResolvable)" returned null.

[Initial Analyze]
While registering a @Publish class, I used Instance<Object> to select bean instance with qualify and try to get the object. However, The WeldContainer.instance() method returns an instance with the @Default and @Any qualifiers[1], and maybe can not get @Blue bean instance.

So, according to [2], I need to confirm the point.
[1]:https://community.jboss.org/thread/179988
[2]:https://github.com/seam/persistence/blob/master/impl/src/main/java/org/jboss/seam/persistence/util/InstanceResolver.java

Comment by TangYong [ 11/Dec/12 ]

This problem has been fixed and fixing way is to use the following way to resolve bean and get bean instance object,

private <T> T getContextualInstance(BeanManager manager, Class<T> type, Annotation... qualifiers) {
T result = null;
Bean<T> bean = null;
if (qualifiers.length == 0)

{ bean = (Bean<T>) manager.resolve(manager.getBeans(type)); }

else

{ bean = (Bean<T>) manager.resolve(manager.getBeans(type, qualifiers)); }

if (bean != null) {
CreationalContext<T> context = manager.createCreationalContext(bean);
if (context != null)

{ result = (T) manager.getReference(bean, type, context); }

}
return result;
}

1 the above method applies in OSGiServicePublisher class
2 in order to use the above method, needing to use Bean Manager rather than Instance<Object>, So,current patch needing to be modified. Fixed patch will be placed in Glassfish-19215.
3 using the above way rather than Instance<Object> will bring a big advantage for patch: not using Weld Implementation related features, and only using CDI SPI Spec.





Add support CDI in plain OSGi bundles (GLASSFISH-19215)

[GLASSFISH-19346] Adding fighterfish test cases Created: 14/Nov/12  Updated: 10/Dec/12

Status: Open
Project: glassfish
Component/s: OSGi-JavaEE
Affects Version/s: future release
Fix Version/s: None

Type: Sub-task Priority: Critical
Reporter: TangYong Assignee: Sanjeeb Sahoo
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Zip Archive GLASSFISH-19215_fighterfishtestcase_20121114.zip     Zip Archive GLASSFISH-19215_fighterfishtestcase_final.zip     Zip Archive GLASSFISH-19215_fighterfishtestcase_multi-interfaces.zip    

 Description   

According to sahoo's test requirements , adding fighterfish test cases. In addition,

1) also needing to add negative test like failing to inject myservice as a regular cdi bean.
2) test cases must separate from stock quote sample, using common test cases liking foo/bar...



 Comments   
Comment by TangYong [ 14/Nov/12 ]

Hi sahoo, siva,

I have created a fighterfish test case for GLASSFISH-19215 and passed on my env successfully.
Please use my 20121114's patch and run the attachment(GLASSFISH-19215_fighterfishtestcase_20121114.zip).

Thanks.
--Tang

Comment by TangYong [ 15/Nov/12 ]

The attachment(GLASSFISH-19215_fighterfishtestcase_final.zip) is the final fighterfish test cases(Totoally two test cases) , and I have added a negative test case for GLASSFISH-19215.

Please try the attachment.

Thanks
--Tang

Comment by Sivakumar Thyagarajan [ 23/Nov/12 ]

The test cases looks good. I will try it out once I have your patch integrated locally into my workspace. The only enhancement I would like to see is that both the tests uses the "contracts" annotations attribute in @OSGiService, but do not use to add any new meaning, and just set the only interface that the Bean is implementing as the "contracts" value. It would be nice if we have another test or just reuse the 2 new test you have added, where the test tries to choose from one interface from a set of interfaces a Bean implements, and then testing to make sure that BarBean is available as an OSGiService only through Bar.class and not through Baz.class

@Publish(contracts =

{Bar.class}

)
public class BarBean implements Bar, Baz{}

In the test Servlet:
@Inject @OSGiService Bar bar; //must succeed
and
@Inject @OSGiService Baz baz; //must fail

Comment by TangYong [ 24/Nov/12 ]

Hi siva,

Thanks your suggestion very much. I have understood your means and I will add test for multi-interface scene.

Tang

Comment by TangYong [ 27/Nov/12 ]

Hi siva,

I have attached a new test case(GLASSFISH-19215_fighterfishtestcase_multi-interfaces.zip) for testing multi interfaces, and please seeing it.

Thanks.
--Tang

Comment by TangYong [ 10/Dec/12 ]

Because osgi-cdi-api will have some changes which are from Siva's suggestions, fighterfish tests will also make some changes. Waiting for final API Release.





Add support CDI in plain OSGi bundles (GLASSFISH-19215)

[GLASSFISH-19422] refactoring OSGiCDIExtender.startWeldIntegration() to use PackageAdmin service Created: 10/Dec/12  Updated: 10/Dec/12

Status: Open
Project: glassfish
Component/s: OSGi-JavaEE
Affects Version/s: future release
Fix Version/s: None

Type: Sub-task Priority: Minor
Reporter: TangYong Assignee: Sanjeeb Sahoo
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Rather than using for loop(bad programming form) to locate weld-integration bundle, instead using PackageAdmin Service to locate weld-integration bundle and start it.



 Comments   
Comment by TangYong [ 10/Dec/12 ]

The refactoring has been finished.





Add support CDI in plain OSGi bundles (GLASSFISH-19215)

[GLASSFISH-19421] Adding java doc for OSGiServicePublisher.getServiceProperties and adding test logic for getServiceProperties while using qualifier for @Publish classes Created: 10/Dec/12  Updated: 10/Dec/12

Status: Open
Project: glassfish
Component/s: OSGi-JavaEE
Affects Version/s: future release
Fix Version/s: None

Type: Sub-task Priority: Major
Reporter: TangYong Assignee: Sanjeeb Sahoo
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Because OSGiServicePublisher.getServiceProperties is critical handling logic for @Publish and has been turned a litter complex, needing to add detailed java doc and add test logic while using qualifier for @Publish classes.

Siva also has the same suggestion and I found that current test cases are not enough for @Publish especially for OSGiServicePublisher.getServiceProperties.






[GLASSFISH-12275] Support Hibernate in OSGI EJB bundle Created: 16/Jun/10  Updated: 29/Nov/12

Status: Open
Project: glassfish
Component/s: OSGi-JavaEE
Affects Version/s: 3.1
Fix Version/s: not determined

Type: Improvement Priority: Major
Reporter: cameronr Assignee: Sanjeeb Sahoo
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All
URL: http://forums.java.net/jive/thread.jspa?threadID=150224


Issuezilla Id: 12,275

 Description   

As discussed on the forums
(http://forums.java.net/jive/thread.jspa?threadID=150224) the OSGI-JPA extension
for glassfish should provide support for Hibernate.



 Comments   
Comment by Tom Mueller [ 06/Mar/12 ]

Bulk update to change fix version to "not determined" for all issues still open but with a fix version for a released version.

Comment by TangYong [ 13/Oct/12 ]

above link seemed to have been invalid, should be:

http://www.java.net/node/704186?force=952, sahoo has made an important reply at that time:

" think I know why it is not working. The osgi/jpa module is making a strong assumption about eclipselink. I need to make it extensible to support other persistence providers. "

Comment by TangYong [ 29/Nov/12 ]

Sahoo ever discussed hibernate enhance way[1] with Hibernate team, and it seemed that hibernate enhance has a litter complex and needs to investigate in depth.

[1]: https://forum.hibernate.org/viewtopic.php?f=1&t=1003355&start=0





[GLASSFISH-19284] [osgi/jpa]supporting OpenJPA in osgi/jpa module Created: 05/Nov/12  Updated: 29/Nov/12

Status: Open
Project: glassfish
Component/s: OSGi-JavaEE
Affects Version/s: future release
Fix Version/s: None

Type: New Feature Priority: Major
Reporter: TangYong Assignee: Sanjeeb Sahoo
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

[Sahoo]Use OpenJPA in osgi/jpa module. Today osgi-jpa has integration for eclipselink.



 Comments   
Comment by TangYong [ 29/Nov/12 ]

There are three tasks related the feature:

1 investigating enhancement way of OpenJPA
Status: in doing

Initial result:
1)using byte-code weaving enhancement
2)using org.apache.openjpa.enhance.PCEnhancer class [1][2]
[1]: openjpa-kernel\src\main\java\org\apache\openjpa\enhance\PCEnhancer.java
[2]: http://openjpa.apache.org/docs/latest/ref_guide_pc_enhance.html#ref_guide_pc_enhance_runtime

2 integrating OpenJPA related bundles into Glassfish
Status: in doing

Current OpenJPA's newest version is 2.2.1.

[Discuss]
Where putting OpenJPA related bundles into? (modules or autostart or creating a new directory)

3 modifying JPABundleProcessor's enhance method to support OpenJPA





[GLASSFISH-19394] support using OSGi/CDI to import/export OSGi Service from distribute OSGi runtime Created: 29/Nov/12  Updated: 29/Nov/12

Status: Open
Project: glassfish
Component/s: OSGi-JavaEE
Affects Version/s: future release
Fix Version/s: None

Type: New Feature Priority: Major
Reporter: TangYong Assignee: Sanjeeb Sahoo
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: OSGi/CDI, distributed

 Description   

Once we integrated DOSGi into glassfish, we wish using OSGi/CDI to import OSGi Service from distribute OSGi runtime, and this is a interesting feature. Imagining the following scene:

1 User built a cluster system using glassfish
2 Some applications in some instances exported distribute OSGi service OSGi/CDI(or other service framewrok)
3 Clients in other instances can import the exported distribute OSGi service using OSGi/CDI.

This will apply into OSGi/SOA/Cloud solutions.

Firstly, we need to finish GLASSFISH-18973.






[GLASSFISH-19374] Migrating OSGi in action's painting sample using CDI/OSGi Created: 27/Nov/12  Updated: 27/Nov/12

Status: Open
Project: glassfish
Component/s: OSGi-JavaEE
Affects Version/s: future release
Fix Version/s: None

Type: Task Priority: Major
Reporter: TangYong Assignee: Sanjeeb Sahoo
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

As a demonstration of CDI/OSGi, I will migrating OSGi in action's painting sample using CDI/OSGi API.






[GLASSFISH-19359] @Observes method defined in a servlet of WAB can not be captured while loading OSGiServiceExtension Created: 20/Nov/12  Updated: 26/Nov/12

Status: Open
Project: glassfish
Component/s: OSGi-JavaEE
Affects Version/s: future release
Fix Version/s: None

Type: Bug Priority: Critical
Reporter: TangYong Assignee: Sanjeeb Sahoo
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

[Problem]
@Observes method defined in a servlet of WAB can not be captured while loading OSGiServiceExtension

[Background]
I defined a @Observes method in a servlet of WAB as following,

public void OnServiceRegistered(@Observes @ServiceContract(StockQuoteService.class) ServiceRegistered event){
...
}

While implementing CDI/OSGi event integration, OSGiServiceExtension will be loaded. By adding the second parameter into beforeBeanDiscovery method liking the following, I can get current BeanManager.

void beforeBeanDiscovery(@Observes BeforeBeanDiscovery bdd, BeanManager manager){
...

if (manager instanceof WeldManager)

{ this.manager = (WeldManager)manager; }

}

According to Weld Container LifeCycle Events's triggering process, while triggering afterBeanDiscovery event, the OnServiceRegistered @Observes method should be added into current BeanManager, however, by debugging and confirming, OnServiceRegistered @Observes method has not been found in current BeanManager. This will cause CDI/OSGi event integration can not work for WAB.

So, please siva and sahoo confirm whether this is a bug or not?



 Comments   
Comment by TangYong [ 20/Nov/12 ]

By debugging, I can confirm that while executing org.jboss.weld.bootstrap.AbstractBeanDeployer.deploy()[1], OnServiceRegistered @Observes method has been found and added into manager, however, the @Observes method has not been found in BeanManager which is obtained from OSGiServiceExtension.

[1]:
for (ObserverMethodImpl<?, ?> observer : getEnvironment().getObservers()) {
if (Observers.isObserverMethodEnabled(observer, manager))

{ log.debug(FOUND_OBSERVER_METHOD, observer); observer.initialize(); ProcessObserverMethodImpl.fire(manager, observer); manager.addObserver(observer); }

}

Comment by TangYong [ 20/Nov/12 ]

For javaee bundle(WAB) scene, I have understood the reason why @Observes method has not been found in BeanManager which is obtained from OSGiServiceExtension. The reason is as following:

Mainly reason is that multi BeanDeploymentArchives and BeanDeployments which relate to javax.enterprise.inject.spi.Extension exist while WeldBootstrap starts to execute startInitialization(), such as,

・org.glassfish.osgicdi.impl.OSGiServiceExtension bdaType= UNKNOWN
・com.acme.FlowCDIExtension bdaType= UNKNOWN
・org.glassfish.jms.injection.JMSCDIExtension bdaType= UNKNOWN
・org.glassfish.sse.impl.ServerSentEventCdiExtension bdaType= UNKNOWN
・osgiapp3256168712323466773 bdaType= WAR
...

While beforeBeanDiscovery method(other lifecycle methods are also same ) is called, obtained BeanManager is related to org.glassfish.osgicdi.impl.OSGiServiceExtension rather than osgiapp3256168712323466773 because lifecycle oberser methods are only added into org.glassfish.osgicdi.impl.OSGiServiceExtension's BeanManager, so, @Observes method has not been found in the BeanManager.

If we want to obtain right BeanManager related to osgiapp3256168712323466773, I think that we only get the BeanManager from org.glassfish.weld.WeldDeployer.event() method, than register the Instance<Object> as OSGi Service in order that OSGiCDIContainerActivator can use the Instance<Object>.

Then, the reason that the issue does not happen on plain cdi osgi scene is that I directly trigger WELD SPI using only a BeanDeploymentArchive.

Comment by TangYong [ 22/Nov/12 ]

Now, the problem has been resolved and put into my newest patch which has been uploaded into GLASSFISH-19215.

Next, I will start to write fighterfish test case for the issue.

Comment by TangYong [ 23/Nov/12 ]

Today, two bugs has been fixed,

1) NPE happened on OSGiServiceExtension.findCurrentBundleId method

[Reason]
While deploying a javaee war with beans.xml(not hybrid app bundle), Instance will be not registered into OSGi registery, so needing to judge whether references is null, otherwise, the following NPE will happen.

Exception 0 :
java.lang.NullPointerException
at org.glassfish.osgicdi.impl.OSGiServiceExtension.findCurrentBundleId(OSGiServiceExtension.java:260)
at org.glassfish.osgicdi.impl.OSGiServiceExtension.afterDeploymentValidation(OSGiServiceExtension.java:230)
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.jboss.weld.util.reflection.SecureReflections$13.work(SecureReflections.java:267)
at org.jboss.weld.util.reflection.SecureReflectionAccess.run(SecureReflectionAccess.java:52)
at org.jboss.weld.util.reflection.SecureReflectionAccess.runAsInvocation(SecureReflectionAccess.java:137)
at org.jboss.weld.util.reflection.SecureReflections.invoke(SecureReflections.java:263)
at org.jboss.weld.introspector.jlr.WeldMethodImpl.invokeOnInstance(WeldMethodImpl.java:170)
at org.jboss.weld.introspector.ForwardingWeldMethod.invokeOnInstance(ForwardingWeldMethod.java:51)
at org.jboss.weld.injection.MethodInjectionPoint.invokeOnInstanceWithSpecialValue(MethodInjectionPoint.java:154)
at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:245)
at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:233)
at org.jboss.weld.event.ObserverMethodImpl.notify(ObserverMethodImpl.java:213)
at org.jboss.weld.bootstrap.events.AbstractContainerEvent.fire(AbstractContainerEvent.java:75)
at org.jboss.weld.bootstrap.events.AbstractDeploymentContainerEvent.fire(AbstractDeploymentContainerEvent.java:46)
at org.jboss.weld.bootstrap.events.AfterDeploymentValidationImpl.fire(AfterDeploymentValidationImpl.java:31)
at org.jboss.weld.bootstrap.WeldBootstrap.validateBeans(WeldBootstrap.java:382)
at org.glassfish.weld.WeldDeployer.event(WeldDeployer.java:246)
at org.glassfish.kernel.event.EventsImpl.send(EventsImpl.java:128)
at org.glassfish.internal.data.ApplicationInfo.start(ApplicationInfo.java:311)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:507)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:229)
at org.glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java:489)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:539)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:535)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAs(Subject.java:337)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2.execute(CommandRunnerImpl.java:534)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:565)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1449)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1500(CommandRunnerImpl.java:119)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1759)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1709)
at org.glassfish.admin.rest.resources.admin.CommandResource.executeCommand(CommandResource.java:487)
at org.glassfish.admin.rest.resources.admin.CommandResource.execCommandSimpInMultOut(CommandResource.java:255)
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.glassfish.jersey.server.model.ResourceMethodInvocationHandlerFactory$1.invoke(ResourceMethodInvocationHandlerFactory.java:80)
at org.glassfish.jersey.server.model.AbstractJavaResourceMethodDispatcher.invoke(AbstractJavaResourceMethodDispatcher.java:107)
at org.glassfish.jersey.server.model.JavaResourceMethodDispatcherProvider$ResponseOutInvoker.doDispatch(JavaResourceMethodDispatcherProvider.java:146)
at org.glassfish.jersey.server.model.AbstractJavaResourceMethodDispatcher.dispatch(AbstractJavaResourceMethodDispatcher.java:80)
at org.glassfish.jersey.server.model.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:354)
at org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:349)
at org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:97)
at org.glassfish.jersey.server.ServerRuntime$1.run(ServerRuntime.java:204)
at org.glassfish.jersey.process.internal.RequestScope.runInScope(RequestScope.java:316)
at org.glassfish.jersey.server.ServerRuntime.process(ServerRuntime.java:180)
at org.glassfish.jersey.server.ApplicationHandler.handle(ApplicationHandler.java:796)
at org.glassfish.jersey.grizzly2.httpserver.GrizzlyHttpContainer.service(GrizzlyHttpContainer.java:306)
at org.glassfish.admin.rest.adapter.RestAdapter$1.service(RestAdapter.java:327)
at org.glassfish.admin.rest.adapter.RestAdapter.service(RestAdapter.java:189)
at com.sun.enterprise.v3.server.HK2Dispatcher.dispatch(HK2Dispatcher.java:113)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:236)
at org.glassfish.grizzly.http.server.HttpHandler.doHandle(HttpHandler.java:164)
at org.glassfish.grizzly.http.server.HttpServerFilter.handleRead(HttpServerFilter.java:175)
at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:265)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:200)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:134)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:112)
at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77)
at org.glassfish.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(TCPNIOTransport.java:781)
at org.glassfish.grizzly.strategies.AbstractIOStrategy.fireIOEvent(AbstractIOStrategy.java:112)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.run0(WorkerThreadIOStrategy.java:115)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.access$100(WorkerThreadIOStrategy.java:55)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy$WorkerThreadRunnable.run(WorkerThreadIOStrategy.java:135)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:578)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:558)
at java.lang.Thread.run(Thread.java:662)
. Please see server.log for more details.

Comment by TangYong [ 23/Nov/12 ]

2) NPE happened on OSGiServiceExtension.afterDeploymentValidation

[Reason]
While deploying a javaee war with beans.xml(not hybrid app bundle), because of deploying mode(for hybrid app bundle, there are two phrases, on the second phrase, cdi-osgi has been activated), cdi-osgi has been still in resolved state,
so, "BundleContext context = FrameworkUtil.getBundle(this.getClass()).getBundleContext()" will return null.

We must judge whether context is null. If null, the method will return directly. Otherwise, the exception will happen.

[#|2012-11-23T15:16:36.187+0900|SEVERE|44.0|javax.enterprise.system.core.com.sun.enterprise.v3.server|_ThreadID=10;_ThreadName=main;_TimeMillis=1353651396187;_LevelValue=1000;|Exception List with 1 exceptions:
Exception 0 :
java.lang.NullPointerException
at org.glassfish.osgicdi.impl.OSGiServiceExtension.afterDeploymentValidation(OSGiServiceExtension.java:229)
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.jboss.weld.util.reflection.SecureReflections$13.work(SecureReflections.java:267)
at org.jboss.weld.util.reflection.SecureReflectionAccess.run(SecureReflectionAccess.java:52)
at org.jboss.weld.util.reflection.SecureReflectionAccess.runAsInvocation(SecureReflectionAccess.java:137)
at org.jboss.weld.util.reflection.SecureReflections.invoke(SecureReflections.java:263)
at org.jboss.weld.introspector.jlr.WeldMethodImpl.invokeOnInstance(WeldMethodImpl.java:170)
at org.jboss.weld.introspector.ForwardingWeldMethod.invokeOnInstance(ForwardingWeldMethod.java:51)
at org.jboss.weld.injection.MethodInjectionPoint.invokeOnInstanceWithSpecialValue(MethodInjectionPoint.java:154)
at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:245)
at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:233)
at org.jboss.weld.event.ObserverMethodImpl.notify(ObserverMethodImpl.java:213)
at org.jboss.weld.bootstrap.events.AbstractContainerEvent.fire(AbstractContainerEvent.java:75)
at org.jboss.weld.bootstrap.events.AbstractDeploymentContainerEvent.fire(AbstractDeploymentContainerEvent.java:46)
at org.jboss.weld.bootstrap.events.AfterDeploymentValidationImpl.fire(AfterDeploymentValidationImpl.java:31)
at org.jboss.weld.bootstrap.WeldBootstrap.validateBeans(WeldBootstrap.java:382)
at org.glassfish.weld.WeldDeployer.event(WeldDeployer.java:246)
at org.glassfish.kernel.event.EventsImpl.send(EventsImpl.java:128)
at org.glassfish.internal.data.ApplicationInfo.start(ApplicationInfo.java:311)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:507)
at com.sun.enterprise.v3.server.ApplicationLoaderService.processApplication(ApplicationLoaderService.java:387)
at com.sun.enterprise.v3.server.ApplicationLoaderService.postConstruct(ApplicationLoaderService.java:223)
at org.jvnet.hk2.internal.ClazzCreator.postConstructMe(ClazzCreator.java:249)
at org.jvnet.hk2.internal.ClazzCreator.create(ClazzCreator.java:288)
at org.jvnet.hk2.internal.SystemDescriptor.create(SystemDescriptor.java:420)
at org.glassfish.hk2.runlevel.internal.RunLevelContext.findOrCreate(RunLevelContext.java:119)
at org.jvnet.hk2.internal.Utilities.createService(Utilities.java:1894)
at org.jvnet.hk2.internal.ServiceHandleImpl.getService(ServiceHandleImpl.java:90)
at com.sun.enterprise.v3.server.AppServerStartup$StartupActivator.activate(AppServerStartup.java:527)
at org.glassfish.hk2.runlevel.utilities.RunLevelControllerImpl$Worker.activateRunLevel(RunLevelControllerImpl.java:828)
at org.glassfish.hk2.runlevel.utilities.RunLevelControllerImpl$Worker.upActiveRecorder(RunLevelControllerImpl.java:782)
at org.glassfish.hk2.runlevel.utilities.RunLevelControllerImpl$Worker.run(RunLevelControllerImpl.java:677)
at org.glassfish.hk2.runlevel.utilities.RunLevelControllerImpl$SyncProceedToWorker.proceedTo(RunLevelControllerImpl.java:948)
at org.glassfish.hk2.runlevel.utilities.RunLevelControllerImpl.proceedTo(RunLevelControllerImpl.java:565)
at org.glassfish.hk2.runlevel.utilities.RunLevelControllerImpl.proceedTo(RunLevelControllerImpl.java:349)
at com.sun.enterprise.v3.server.AppServerStartup.proceedTo(AppServerStartup.java:370)
at com.sun.enterprise.v3.server.AppServerStartup.run(AppServerStartup.java:256)
at com.sun.enterprise.v3.server.AppServerStartup.doStart(AppServerStartup.java:174)
at com.sun.enterprise.v3.server.AppServerStartup.start(AppServerStartup.java:165)
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.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)

Comment by TangYong [ 26/Nov/12 ]

Today, on testing a common WAR(not WAB, however, in Manifest.MF, "Bundle-SymbolicName" exists), the following exception happened while deploying the common WAR,

[#|2012-11-26T11:48:28.578+0900|SEVERE|44.0|javax.enterprise.system.tools.deployment.common|_ThreadID=12;_ThreadName=admin-listener(1);_TimeMillis=1353898108578;_LevelValue=1000;|Exception while invoking class org.glassfish.weld.WeldDeployer load method
java.lang.NullPointerException
at org.glassfish.weld.BeanDeploymentArchiveImpl.getBundleForCurrentBeanArchive(BeanDeploymentArchiveImpl.java:187)
at org.glassfish.weld.BeanDeploymentArchiveImpl.<init>(BeanDeploymentArchiveImpl.java:154)
at org.glassfish.weld.BeanDeploymentArchiveImpl.<init>(BeanDeploymentArchiveImpl.java:136)
at org.glassfish.weld.DeploymentImpl.<init>(DeploymentImpl.java:110)
at org.glassfish.weld.WeldDeployer.load(WeldDeployer.java:442)
at org.glassfish.weld.WeldDeployer.load(WeldDeployer.java:108)
at org.glassfish.internal.data.ModuleInfo.load(ModuleInfo.java:195)
at org.glassfish.internal.data.ApplicationInfo.load(ApplicationInfo.java:262)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:503)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:229)
at org.glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java:489)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:539)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:535)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAs(Subject.java:337)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2.execute(CommandRunnerImpl.java:534)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:565)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1449)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1500(CommandRunnerImpl.java:119)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1759)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1709)
at org.glassfish.admin.rest.resources.admin.CommandResource.executeCommand(CommandResource.java:487)
at org.glassfish.admin.rest.resources.admin.CommandResource.execCommandSimpInMultOut(CommandResource.java:255)
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.glassfish.jersey.server.model.ResourceMethodInvocationHandlerFactory$1.invoke(ResourceMethodInvocationHandlerFactory.java:80)
at org.glassfish.jersey.server.model.AbstractJavaResourceMethodDispatcher.invoke(AbstractJavaResourceMethodDispatcher.java:107)
at org.glassfish.jersey.server.model.JavaResourceMethodDispatcherProvider$ResponseOutInvoker.doDispatch(JavaResourceMethodDispatcherProvider.java:146)
at org.glassfish.jersey.server.model.AbstractJavaResourceMethodDispatcher.dispatch(AbstractJavaResourceMethodDispatcher.java:80)
at org.glassfish.jersey.server.model.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:354)
at org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:349)
at org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:97)
at org.glassfish.jersey.server.ServerRuntime$1.run(ServerRuntime.java:204)
at org.glassfish.jersey.process.internal.RequestScope.runInScope(RequestScope.java:316)
at org.glassfish.jersey.server.ServerRuntime.process(ServerRuntime.java:180)
at org.glassfish.jersey.server.ApplicationHandler.handle(ApplicationHandler.java:796)
at org.glassfish.jersey.grizzly2.httpserver.GrizzlyHttpContainer.service(GrizzlyHttpContainer.java:306)
at org.glassfish.admin.rest.adapter.RestAdapter$1.service(RestAdapter.java:327)
at org.glassfish.admin.rest.adapter.RestAdapter.service(RestAdapter.java:189)
at com.sun.enterprise.v3.server.HK2Dispatcher.dispatch(HK2Dispatcher.java:113)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:236)
at org.glassfish.grizzly.http.server.HttpHandler.doHandle(HttpHandler.java:164)
at org.glassfish.grizzly.http.server.HttpServerFilter.handleRead(HttpServerFilter.java:175)
at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:265)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:200)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:134)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:112)
at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77)
at org.glassfish.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(TCPNIOTransport.java:781)
at org.glassfish.grizzly.strategies.AbstractIOStrategy.fireIOEvent(AbstractIOStrategy.java:112)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.run0(WorkerThreadIOStrategy.java:115)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.access$100(WorkerThreadIOStrategy.java:55)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy$WorkerThreadRunnable.run(WorkerThreadIOStrategy.java:135)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:578)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:558)
at java.lang.Thread.run(Thread.java:662)

#]

So, the reason is that I have not checked whether pa.getBundles(symbolicName, version) is null or not, so, the fixing way is adding result's checking.

private Bundle getBundleForCurrentBeanArchive(BundleContext context, String symbolicName, String version) {
PackageAdmin pa = (PackageAdmin) context.getService(context.getServiceReference(PackageAdmin.class.getName()));
Bundle[] bundles = pa.getBundles(symbolicName, version);
if (bundles != null)

{ return bundles[0]; }

return null;
}





[GLASSFISH-16805] [osgi-cdi] support @Inject @OSGiService Instance<T> Created: 06/Jun/11  Updated: 22/Nov/12

Status: Open
Project: glassfish
Component/s: OSGi-JavaEE
Affects Version/s: 3.1
Fix Version/s: not determined

Type: Improvement Priority: Major
Reporter: Sanjeeb Sahoo Assignee: Sivakumar Thyagarajan
Resolution: Unresolved Votes: 1
Labels: None
Σ Remaining Estimate: Not Specified Remaining Estimate: Not Specified
Σ Time Spent: Not Specified Time Spent: Not Specified
Σ Original Estimate: Not Specified Original Estimate: Not Specified

Sub-Tasks:
Key
Summary
Type
Status
Assignee
GLASSFISH-18978 select OSGi services used in CDI bean... Sub-task Open Sanjeeb Sahoo  
Tags: 3_1-next

 Description   

Currently having something like
@Inject @OSGiService(dynamic=true)
private Instance<AdminService> adminService;

cause following exception:

java.lang.UnsupportedOperationException: Injection target type javax.enterprise.inject.Instance<org.glassfish.fighterfish.test.app18.AdminService>not supported
at org.glassfish.osgicdi.impl.OSGiServiceExtension.afterBeanDiscovery(OSGiServiceExtension.java:185)
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.jboss.weld.util.reflection.SecureReflections$13.work(SecureReflections.java:305)
at org.jboss.weld.util.reflection.SecureReflectionAccess.run(SecureReflectionAccess.java:54)
at org.jboss.weld.util.reflection.SecureReflectionAccess.runAsInvocation(SecureReflectionAccess.java:163)
at org.jboss.weld.util.reflection.SecureReflections.invoke(SecureReflections.java:299)
at org.jboss.weld.introspector.jlr.WeldMethodImpl.invokeOnInstance(WeldMethodImpl.java:188)
at org.jboss.weld.introspector.ForwardingWeldMethod.invokeOnInstance(ForwardingWeldMethod.java:59)
at org.jboss.weld.injection.MethodInjectionPoint.invokeOnInstanceWithSpecialValue(MethodInjectionPoint.java:198)
at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:282)
at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:265)
at org.jboss.weld.event.ObserverMethodImpl.notify(ObserverMethodImpl.java:234)
at org.jboss.weld.bootstrap.events.AbstractContainerEvent.fire(AbstractContainerEvent.java:88)
at org.jboss.weld.bootstrap.events.AbstractDefinitionContainerEvent.fire(AbstractDefinitionContainerEvent.java:52)
at org.jboss.weld.bootstrap.events.AfterBeanDiscoveryImpl.fire(AfterBeanDiscoveryImpl.java:43)
at org.jboss.weld.bootstrap.WeldBootstrap.deployBeans(WeldBootstrap.java:372)
at org.glassfish.weld.WeldDeployer.event(WeldDeployer.java:170)
at org.glassfish.kernel.event.EventsImpl.send(EventsImpl.java:128)
at org.glassfish.internal.data.ApplicationInfo.load(ApplicationInfo.java:270)
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)
at org.glassfish.osgijavaeebase.OSGiDeploymentRequest.execute(OSGiDeploymentRequest.java:118)
at org.glassfish.osgijavaeebase.AbstractOSGiDeployer.deploy(AbstractOSGiDeployer.java:121)
at org.glassfish.osgijavaeebase.OSGiContainer.deploy(OSGiContainer.java:154)
at org.glassfish.osgijavaeebase.JavaEEExtender.deploy(JavaEEExtender.java:107)
at org.glassfish.osgijavaeebase.JavaEEExtender.access$200(JavaEEExtender.java:61)
at org.glassfish.osgijavaeebase.JavaEEExtender$HybridBundleTrackerCustomizer$1.call(JavaEEExtender.java:151)
at org.glassfish.osgijavaeebase.JavaEEExtender$HybridBundleTrackerCustomizer$1.call(JavaEEExtender.java:148)
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:619)

at org.jboss.weld.bootstrap.events.AbstractDefinitionContainerEvent.fire(AbstractDefinitionContainerEvent.java:55)
at org.jboss.weld.bootstrap.events.AfterBeanDiscoveryImpl.fire(AfterBeanDiscoveryImpl.java:43)
at org.jboss.weld.bootstrap.WeldBootstrap.deployBeans(WeldBootstrap.java:372)
at org.glassfish.weld.WeldDeployer.event(WeldDeployer.java:170)
... 17 more

#]


 Comments   
Comment by Sanjeeb Sahoo [ 06/Jun/11 ]

assigning to Siva for evaluation.

Comment by Sivakumar Thyagarajan [ 07/Jun/11 ]

Tagging this as 3_1-next, as this is not critical for the 3.1.1 release.

Comment by Sanjeeb Sahoo [ 07/Jun/11 ]

Do you know why it is not working? Can you at least mention the reason?

Comment by Sivakumar Thyagarajan [ 13/Jun/11 ]

Marked it as an improvement(RFE)

Comment by Tom Mueller [ 06/Mar/12 ]

Bulk update to change fix version to "not determined" for all issues still open but with a fix version for a released version.

Comment by TangYong [ 06/Aug/12 ]

Now, the feature has been supported combined with subTask(GLASSFISH-18978). Please see.

https://github.com/tangyong/gf-cdi-osgi-integration

DEMO1: https://github.com/tangyong/gf-cdi-osgi-integration/tree/master/samples/[RFP146]CDI018
DEMO2: https://github.com/tangyong/gf-cdi-osgi-integration/tree/master/samples/[RFP146]CDI004

Using Way:

1 get all osgi services
@Inject Service<StockQuoteService> sqses;
....

2 get osgi services qualified @ServiceFilter
@Inject @ServiceFilter("(country=CN)") Service<StockQuoteService> sqses;
...

Comment by TangYong [ 22/Nov/12 ]

After event integration was finished, the feature will start because compared with other features, it has been turned more important.





[OSGi/CDI] CDI + OSGi event admin (GLASSFISH-15365)

[GLASSFISH-19358] Adding fighterfish test cases Created: 19/Nov/12  Updated: 22/Nov/12

Status: Open
Project: glassfish
Component/s: OSGi-JavaEE
Affects Version/s: future release
Fix Version/s: future release

Type: Sub-task Priority: Critical
Reporter: TangYong Assignee: Sanjeeb Sahoo
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Currently, An implementation has been finished, and Needing to add fighterfish test cases:

[Test Requirements]
Adding 4 bundles, called FooInf, FooBean1,
FooBean2, BarInf, BarBean, the dependency relationships are as following:

1) FooInf and BarInf are pure OSGi bundles
2) FooBean1 is an implementation of FooInf, and FooBean2 is another implementation of FooInf.
3) BarBean is an implementation of BarInf.
4) FooBean1 and FooBean2 are registered as OSGi Services using @Publish
5) BarBean uses FooInf as @OSGiService.
6) BarBean has a OnServiceRegistered event callback method liking the following:
public void OnServiceRegistered(@Observes @ServiceContract(FooInf.class) ServiceRegistered event){
.... //Call FooBean2's method
}

Firstly, we deploy FooInf and BarInf, then deploy FooBean1, deploy BarBean, finally we deploy FooBean2, if anything is ok, we should see that OnServiceRegistered can be called successfully and CDI/OSGi integration can notify BarBean that FooBean2 has been registered.

Of course, we can also deploy FooBean1 only and undeploy FooBean1, then deploy FooBean1 again, in this way, BarBean can be notified that an implementation of FooInf has been available.



 Comments   
Comment by TangYong [ 22/Nov/12 ]

Test cases need to add WAB scene(seeing GLASSFISH-19359)





Add support CDI in plain OSGi bundles (GLASSFISH-19215)

[GLASSFISH-19344] adding the handling logic of Weld Container Shutting Down in OSGiCDIExtender class Created: 14/Nov/12  Updated: 14/Nov/12

Status: Open
Project: glassfish
Component/s: OSGi-JavaEE
Affects Version/s: future release
Fix Version/s: None

Type: Sub-task Priority: Major
Reporter: TangYong Assignee: Sanjeeb Sahoo
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Needing to adding the handling logic of Weld Container Shutting Down in OSGiCDIExtender class.



 Comments   
Comment by TangYong [ 14/Nov/12 ]

1 Adding WeldBootstrap.shutdown handling logic while using asadmin osgi stop "bundleID"

1) make OSGiCDIExtender's BundleTracker add Bundle.STOPPING to track bundles in the state of STOPPING
2) add handling logic in BeanBundleTrackerCustomizer's modifiedBundle method

Comment by TangYong [ 14/Nov/12 ]

2 Adding WeldBootstrap.shutdown handling logic while executing stop-domain

In OSGiCDIExtender.stop(), adding WeldBootstrap.shutdown handling logic as following,

public synchronized void stop() {

if (tracker != null) tracker.close();
tracker = null;

for(Long bundleId : managedBootstraps.keySet()){
WeldBootstrap bootstrap = managedBootstraps.get(bundleId).getBootstrap();
if (bootstrap != null){
ClassLoader oldTCC = Thread.currentThread().getContextClassLoader();
try

{ ClassLoader newTCC = managedBootstraps.get(bundleId).getClassLoader(); Thread.currentThread().setContextClassLoader(newTCC); bootstrap.shutdown(); }

catch(RuntimeException e)

{ e.printStackTrace(); }

finally

{ Thread.currentThread().setContextClassLoader(oldTCC); }


}
}

managedBootstraps.clear();
managedBootstraps = null;
}





Add support CDI in plain OSGi bundles (GLASSFISH-19215)

[GLASSFISH-19325] moving the logics of publishing beans into OSGiServiceExtension class Created: 13/Nov/12  Updated: 14/Nov/12

Status: Open
Project: glassfish
Component/s: OSGi-JavaEE
Affects Version/s: future release
Fix Version/s: None

Type: Sub-task Priority: Critical
Reporter: TangYong Assignee: Sanjeeb Sahoo
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Needing to move the logics of publishing beans into OSGiServiceExtension class in order to make @Publish to work in hybrid javaee bundle.



 Comments   
Comment by TangYong [ 14/Nov/12 ]

Currently, this moving has been finished, and triggering publish services has been put into AfterDeploymentValidation Observer method as following:

void afterDeploymentValidation(@Observes AfterDeploymentValidation adv)

{ //Publish @Publish Classes into OSGi Registry Instance<Object> instance = this.manager.instance(); publishOSGiService(instance); }

And, beforeBeanDiscovery method adds the second parameter as following,

void beforeBeanDiscovery(@Observes BeforeBeanDiscovery bdd, BeanManager manager){
debug("beforeBeanDiscovery" + bdd);
bdd.addQualifier(OSGiService.class); //XXX:needed?

if (manager instanceof WeldManager)

{ this.manager = (WeldManager)manager; }

}

In the future, once CDI Specification adds a portable method called "Instance<Object> instance()", the strong type cast(WeldManager) will be deleted and make a improvement. Now, the above is enough.





Add support CDI in plain OSGi bundles (GLASSFISH-19215)

[GLASSFISH-19326] invocating Weld-Integration bundle to use ACLSingletonProvider Created: 13/Nov/12  Updated: 14/Nov/12

Status: Open
Project: glassfish
Component/s: OSGi-JavaEE
Affects Version/s: future release
Fix Version/s: None

Type: Sub-task Priority: Critical
Reporter: TangYong Assignee: Sanjeeb Sahoo
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Needing to invocating Weld-Integration bundle in OSGiCDIExtender class to use ACLSingletonProvider



 Comments   
Comment by TangYong [ 13/Nov/12 ]

Adding the following logic into OSGiCDIExtender class,

if ( isPlainOSGiBundle(bundle) ){
if ( isGlassfishCDIEnabled(bundle) && isCDIBundle(bundle) ){
final int state = bundle.getState();
if ( isReady(event, state) ) {
startWeldIntegration();
currentBootstrap = new WeldBootstrap();
...

startWeldIntegration()'s definition is as following,

private void startWeldIntegration(){
Bundle[] installedBundles = context.getBundles();

for(Bundle bundle : installedBundles){
if (Constants.WEDINTEGRATION_SYMNAME.equals(bundle.getSymbolicName())){
if (bundle.getState() != Bundle.ACTIVE){
try

{ bundle.start(Bundle.START_TRANSIENT); }

catch (BundleException e)

{ throw new RuntimeException(e); }

However, sometimes, the following exception happened and weld-integration bundle was not started,

[#|2012-11-13T21:26:31.890+0900|SEVERE|44.0|javax.enterprise.logging.stderr|_ThreadID=14;_ThreadName=Thread-13;_TimeMillis=1352809591890;_LevelValue=1000;|com.sun.enterprise.module.ResolveError:
Failed to start OSGiModuleImpl:: Bundle =
[org.glassfish.main.web.weld-integration [260]], State = [RESOLVED]
at org.jvnet.hk2.osgiadapter.OSGiModuleImpl.start(OSGiModuleImpl.java:227)
at
org.jvnet.hk2.osgiadapter.OsgiPopulatorPostProcessor$1.loadClass(OsgiPopulatorPostProcessor.java:78)
at
org.jvnet.hk2.internal.ServiceLocatorImpl.loadClass(ServiceLocatorImpl.java:1355)
at
org.jvnet.hk2.internal.ServiceLocatorImpl.reifyDescriptor(ServiceLocatorImpl.java:346)
at
org.jvnet.hk2.internal.ServiceLocatorImpl.narrow(ServiceLocatorImpl.java:1382)
at
org.jvnet.hk2.internal.ServiceLocatorImpl.internalGetDescriptor(ServiceLocatorImpl.java:709)
at
org.jvnet.hk2.internal.ServiceLocatorImpl.getInjecteeDescriptor(ServiceLocatorImpl.java:397)
at
org.jvnet.hk2.internal.ThreeThirtyResolver.resolve(ThreeThirtyResolver.java:148)
at org.jvnet.hk2.internal.ClazzCreator.resolve(ClazzCreator.java:153)
at
org.jvnet.hk2.internal.ClazzCreator.resolveAllDependencies(ClazzCreator.java:176)
at org.jvnet.hk2.internal.ClazzCreator.create(ClazzCreator.java:280)
at
org.jvnet.hk2.internal.SystemDescriptor.create(SystemDescriptor.java:420)
at
org.jvnet.hk2.internal.SingletonContext.findOrCreate(SingletonContext.java:87)
at org.jvnet.hk2.internal.Utilities.createService(Utilities.java:1894)
at
org.jvnet.hk2.internal.ServiceHandleImpl.getService(ServiceHandleImpl.java:90)
at org.glassfish.internal.data.EngineInfo.getContainer(EngineInfo.java:86)
at
com.sun.enterprise.v3.server.ApplicationLifecycle.startContainers(ApplicationLifecycle.java:1018)
at
com.sun.enterprise.v3.server.ApplicationLifecycle.setupContainerInfos(ApplicationLifecycle.java:724)
at
com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:384)
at
com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:229)
at
org.glassfish.osgijavaeebase.OSGiDeploymentRequest.deploy(OSGiDeploymentRequest.java:183)
at
org.glassfish.osgijavaeebase.OSGiDeploymentRequest.execute(OSGiDeploymentRequest.java:118)
at
org.glassfish.osgijavaeebase.AbstractOSGiDeployer.deploy(AbstractOSGiDeployer.java:123)
at
org.glassfish.osgijavaeebase.OSGiContainer.deploy(OSGiContainer.java:154)
at
org.glassfish.osgijavaeebase.OSGiContainer.redeploy(OSGiContainer.java:113)
at
org.glassfish.osgijavaeebase.OSGiContainer.access$500(OSGiContainer.java:61)
at
org.glassfish.osgijavaeebase.OSGiContainer$DeployerAddedThread.run(OSGiContainer.java:305)
Caused by: org.osgi.framework.BundleException: Activator start error in
bundle org.glassfish.main.web.weld-integration [260].
at org.apache.felix.framework.Felix.activateBundle(Felix.java:2027)
at org.apache.felix.framework.Felix.startBundle(Felix.java:1895)
at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:944)
at org.jvnet.hk2.osgiadapter.OSGiModuleImpl.start(OSGiModuleImpl.java:219)
... 26 more
Caused by: java.lang.RuntimeException: SingletonProvider is already
initialized with
org.jboss.weld.bootstrap.api.helpers.IsolatedStaticSingletonProvider@dd4f00
at
org.jboss.weld.bootstrap.api.SingletonProvider.initialize(SingletonProvider.java:113)
at org.glassfish.weld.WeldActivator.start(WeldActivator.java:79)
at
org.apache.felix.framework.util.SecureAction.startActivator(SecureAction.java:641)
at org.apache.felix.framework.Felix.activateBundle(Felix.java:1977)
... 29 more

#]
Comment by TangYong [ 14/Nov/12 ]

The steps will trigger the above problem,

1) deploy a plain cdi bundle
2) asadmin stop-domain
3) asadmin start-domain

On 3) step, the problem will be triggered. After debugging, I can confirm that the problem is related to https://issues.apache.org/jira/browse/FELIX-3713 again.

That is to say, while trying to execute bundle.start(Bundle.START_TRANSIENT), because at the time point, there is a StartLevel thread in gf starting, so bundle.start returned immediately rather than executing Activate.start method.

Comment by TangYong [ 14/Nov/12 ]

I have a temp fixing way, and used bundle.start() rather than bundle.start(Bundle.START_TRANSIENT). After several tests, the problem did not happen. However, the fixing way has a shortcoming as following,

because not using Bundle.START_TRANSIENT, if I uninstall deployed plain cdi bundles, after I restarted domain, Weld-Integration Bundle's state will be active rather than installed, so Weld-Integration Bundle will be not ondemand starting any more.





Add support CDI in plain OSGi bundles (GLASSFISH-19215)

[GLASSFISH-19324] Instance.select(clazz).get() throw IllegalArgumentException: Created: 13/Nov/12  Updated: 13/Nov/12

Status: Open
Project: glassfish
Component/s: OSGi-JavaEE
Affects Version/s: future release
Fix Version/s: None

Type: Sub-task Priority: Major
Reporter: TangYong Assignee: Sanjeeb Sahoo
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Based current patch, while testing(firstly deploying , then stop-domain, again start-domain), IllegalArgumentException is thrown and happens on OSGiServicePublisher.RegisterOSGiService() method as following:

[#|2012-11-13T17:26:53.937+0900|SEVERE|44.0|javax.enterprise.logging.stderr|_ThreadID=12;_ThreadName=pool-8-thread-1;_TimeMillis=1352795213937;_LevelValue=1000;|java.lang.IllegalArgumentException: interface org.acme.myservice.MyServiceInf is not visible from class loader
at java.lang.reflect.Proxy.getProxyClass(Proxy.java:353)
at java.lang.reflect.Proxy.newProxyInstance(Proxy.java:581)
at org.glassfish.osgicdi.impl.OSGiServiceFactory.createServiceProxy(OSGiServiceFactory.java:111)
at org.glassfish.osgicdi.impl.OSGiServiceFactory.getService(OSGiServiceFactory.java:86)
at org.glassfish.osgicdi.impl.OSGiServiceExtension$OSGiServiceBean.create(OSGiServiceExtension.java:295)
at org.jboss.weld.context.unbound.DependentContextImpl.get(DependentContextImpl.java:68)
at org.jboss.weld.manager.BeanManagerImpl.getReference(BeanManagerImpl.java:608)
at org.jboss.weld.manager.BeanManagerImpl.getReference(BeanManagerImpl.java:674)
at org.jboss.weld.injection.FieldInjectionPoint.inject(FieldInjectionPoint.java:136)
at org.jboss.weld.util.Beans.injectBoundFields(Beans.java:763)
at org.jboss.weld.util.Beans.injectFieldsAndInitializers(Beans.java:772)
at org.jboss.weld.bean.ManagedBean$ManagedBeanInjectionTarget$1$1.proceed(ManagedBean.java:161)
at org.jboss.weld.injection.InjectionContextImpl.run(InjectionContextImpl.java:48)
at org.jboss.weld.bean.ManagedBean$ManagedBeanInjectionTarget$1.work(ManagedBean.java:157)
at org.jboss.weld.bean.ManagedBean$FixInjectionPoint.run(ManagedBean.java:131)
at org.jboss.weld.bean.ManagedBean$ManagedBeanInjectionTarget.inject(ManagedBean.java:153)
at org.jboss.weld.bean.ManagedBean.create(ManagedBean.java:293)
at org.jboss.weld.context.unbound.DependentContextImpl.get(DependentContextImpl.java:68)
at org.jboss.weld.manager.BeanManagerImpl.getReference(BeanManagerImpl.java:608)
at org.jboss.weld.manager.BeanManagerImpl.getReference(BeanManagerImpl.java:635)
at org.jboss.weld.bean.builtin.InstanceImpl.get(InstanceImpl.java:108)
at org.glassfish.osgicdi.impl.OSGiServicePublisher.RegisterOSGiService(OSGiServicePublisher.java:89)
at org.glassfish.osgicdi.impl.OSGiServiceExtension.publishOSGiService(OSGiServiceExtension.java:272)
at org.glassfish.osgicdi.impl.OSGiCDIExtender$BeanBundleTrackerCustomizer.addingBundle(OSGiCDIExtender.java:151)
at org.osgi.util.tracker.BundleTracker$Tracked.customizerAdding(BundleTracker.java:482)
at org.osgi.util.tracker.BundleTracker$Tracked.customizerAdding(BundleTracker.java:424)
at org.osgi.util.tracker.AbstractTracked.trackAdding(AbstractTracked.java:262)
at org.osgi.util.tracker.AbstractTracked.trackInitial(AbstractTracked.java:185)
at org.osgi.util.tracker.BundleTracker.open(BundleTracker.java:163)
at org.glassfish.osgicdi.impl.OSGiCDIExtender.start(OSGiCDIExtender.java:92)
at org.glassfish.osgijavaeebase.ExtenderManager$ExtenderTracker.addingService(ExtenderManager.java:144)
at org.osgi.util.tracker.ServiceTracker$Tracked.customizerAdding(ServiceTracker.java:980)
at org.osgi.util.tracker.ServiceTracker$Tracked.customizerAdding(ServiceTracker.java:906)
at org.osgi.util.tracker.AbstractTracked.trackAdding(AbstractTracked.java:262)
at org.osgi.util.tracker.AbstractTracked.trackInitial(AbstractTracked.java:185)
at org.osgi.util.tracker.ServiceTracker.open(ServiceTracker.java:348)
at org.osgi.util.tracker.ServiceTracker.open(ServiceTracker.java:283)
at org.glassfish.osgijavaeebase.ExtenderManager.startExtenders(ExtenderManager.java:109)
at org.glassfish.osgijavaeebase.ExtenderManager.access$100(ExtenderManager.java:67)
at org.glassfish.osgijavaeebase.ExtenderManager$GlassFishServerTracker$1.run(ExtenderManager.java:192)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
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)

#]


 Comments   
Comment by TangYong [ 13/Nov/12 ]

A fixing way is that setting current thread's ContextClassLoader into Bundle's Classloader as following:

ClassLoader oldTCC = Thread.currentThread().getContextClassLoader();

try

{ ClassLoader newTCC = clazz.getClassLoader(); Thread.currentThread().setContextClassLoader(newTCC); service = instance.select(clazz).get(); }

finally

{ Thread.currentThread().setContextClassLoader(oldTCC); }

If having more time, I will investigate whether should fix the problem on earlier time or not.

Comment by TangYong [ 13/Nov/12 ]

The following fix way is not right while using ACLSingletonProvider, and right way is to set Thread current context classloader on earlier time and need to set scanned bundle's classloader. So, the following is the right fixing way:

1 define a new private TCCLClassLoader in OSGiCDIExtender

private static class TCCLClassLoader extends ClassLoader {
private final Bundle bundle;

private final ClassLoader infra;

public TCCLClassLoader(Bundle bundle, ClassLoader infraClassLoader)

{ this.bundle = bundle; this.infra = infraClassLoader; }

@Override
public Class<?> loadClass(String name) throws ClassNotFoundException {
Class<?> loadedClass = null;
try

{ loadedClass = bundle.loadClass(name); }

catch (ClassNotFoundException cnfe)

{ // todo : filter on utils class only loadedClass = infra.loadClass(name); }

return loadedClass;
}

@Override
public Enumeration<URL> getResources(String s) throws IOException {
Set<URL> urls = new HashSet<URL>();
Enumeration enumBundle = bundle.getResources(s);
Enumeration enumInfra = infra.getResources(s);
if (enumBundle != null)

{ urls.addAll(Collections.list(enumBundle)); }

if (enumInfra != null)

{ urls.addAll(Collections.list(enumInfra)); }

return Collections.enumeration(urls);
}
}

2 setting current thread's ContextClassLoader into the TCCLClassLoader before starting Weld Container

ClassLoader oldTCC = Thread.currentThread().getContextClassLoader();

try{
ClassLoader newTCC = new TCCLClassLoader(bundle, this.getClass().getClassLoader());
Thread.currentThread().setContextClassLoader(newTCC);
...





[GLASSFISH-19292] [osgi/cdi] implement BundleScope Created: 06/Nov/12  Updated: 12/Nov/12

Status: Open
Project: glassfish
Component/s: OSGi-JavaEE
Affects Version/s: 4.0_b61
Fix Version/s: None

Type: New Feature Priority: Major
Reporter: Sanjeeb Sahoo Assignee: Sanjeeb Sahoo
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

OSGi services have two scopes:
singleton and per bundle.

We should create a CDI scope called BundleScope to match the later type.



 Comments   
Comment by TangYong [ 07/Nov/12 ]

Hi Sahoo,

I want to make a discussion of concrete means for the feature.

1 About the scopes of "singleton and per bundle"

My understanding is, for OSGi Service Spec, there are two ways to register service.

1) using service implementation directly
eg. registration = bundleContext.registerService(Interface.class.getName(),Implementation Class Object,properties);

In this case, service consumer will get the same service implementation object instance, called "singleton pattern for object creation"

2) using service factory
eg. registration = bundleContext.registerService(Interface.class.getName(),Service Factory Object, properties);

In this case, service consumer will get multi service implementation object instance, called "prototype pattern for object creation"

So, backing the feature,
Question: whether "singleton and per bundle." is the above two patterns or not?

2 About "create a CDI scope called BundleScope"

1) Creating/Design way
My way is to create a Qualifier to decorate @Publish, once Weld Container scans a class with Qualifier and @Publish, I will judge whether the class implements service factory, if not implementing, a exception will be thrown; otherwise, I will register the class using service factory way as OSGi Service.

Question: whether you agree with me or not?

2) Question: whether not needing to create singleton scope and defaultly, if not specifying BundleScope, the scope is singleton scope?

3 About singleton service object
This should be discussed in GLASSFISH-18938, however, discussion here is also good.
While Weld Container scans a class with @Publish and singleton scope, we will register the class as OSGi Service. Now, there are three ways to obtain the implementation class's instance.

・using java reflection
eg. Class.newInstance() or Class.forName()

・using CDI's Instance<T>.select().get()
This way, bean instance object is managed by CDI container.

・using CDI's contextual instance
eg. Bundle bundle = BundleReference.class.cast(clazz.getClassLoader()).getBundle();
Object instance = null ;
CreationalContext<? extends Object> context = beanManager.createCreationalContext(pb.getBean());
if (context != null)

{ instance = beanManager.getReference(pb.getBean(), clazz, context); }

Question: Which one can be better?

4 about a user's using way
If we have four bundles, the first uses @Publish with singleton scope to register a class(eg. interface name is A) as OSGi Service, the second uses @Publish with BundleScope to register the same interface name A as OSGi Service, the third and the fourth use @OSGiService to try to obtain different service objects, then, maybe the third and the fourth maybe obtain the same service objects.

Question: whether we should consider the case as user's error or not?

Thanks.
Tang

Comment by Sanjeeb Sahoo [ 07/Nov/12 ]

When service is directly bound, its singleton scope. When factory is bound, then it's scope is bundle scope. I hope this answers your first question.

I have not thought about the design yet. I think we need to first implement GLASSFISH-19215 before embarking upon this feature.

Comment by TangYong [ 12/Nov/12 ]

>When service is directly bound, its singleton scope. When factory is bound, then it's scope is bundle scope. I hope >this answers your first question.

>I have not thought about the design yet. I think we need to first implement GLASSFISH-19215 before embarking upon >this feature.

OK. I see.

In addition,

>3 About singleton service object
I have confirmed that we should use the way of CDI's Instance<T>.select().get(). Please seeing my comment on GLASSFISH-19215, because while a bean(@Publish) has a dependent bean(@OSGiService), we can not simply create a instance using java reflection, and considering portable api, we should also use CDI's contextual instance.

Tang





[GLASSFISH-18896] [osgi/cdi] Allow criteria to be configurable in OSGiService Created: 13/Jul/12  Updated: 01/Nov/12

Status: Open
Project: glassfish
Component/s: OSGi-JavaEE
Affects Version/s: None
Fix Version/s: None

Type: New Feature Priority: Major
Reporter: Sanjeeb Sahoo Assignee: Sanjeeb Sahoo
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

We should allow some kind of property substitution in filter criteria attribute of @OSGiService.



 Comments   
Comment by TangYong [ 10/Aug/12 ]

I wish that sahoo can explain GLASSFISH-18896 in detail and what is mean of "Allow criteria to be configurable".

Comment by TangYong [ 10/Aug/12 ]

Sahoo Said:

What I meant by configurable service property in GLASSFISH-18896 is
that instead of hard coding the serviceCriteria if developer can use
tokens which can get replaced by values set during deployment, that will
be more flexible.

Comment by TangYong [ 31/Oct/12 ]

Now, the feature should be considered ahead of time because design for the feature seemed to have a relationship with some issues(for example, Glassfish-19215).

If implementing the feature, a user maybe use the following deploying command to specify serviceCriteria,

asadmin deploy --type=osgi --properties serviceprops=(name=lang,value=__CH) e:\test_sample1.jar

There is a important topic that we should make OSGiServiceExtension can obtain current deployed bundle's serviceprops which is from "--properties". However, OSGiServiceExtension is not related to DeploymentContext at all.

So, I consider a solution which is similar to how OSGiEJBDeployer obtains OSGiApplicationInfo, that is to say, on the first deploying phrase, we register serviceprops as a OSGi service once finding serviceprops, then, in OSGiServiceExtension, getting current bundle's serviceprops by OSGi service.

Then, the reason that I say the feature maybe have a relationship with Glassfish-19215 is that whether having some design possibility rather than registering serviceprops as a OSGi service.

Thanks.
Tang

Comment by TangYong [ 31/Oct/12 ]

Apart from the above problem, there is another problem needed to be discussed:

if the user used the following command with service property:

asadmin deploy --type=osgi --properties serviceprops=(name=lang,value=__CH) e:\test_sample1.jar

For OSGi/CDI, there are two places that can use the serviceprops:

1) @Publish
using the serviceprops to register OSGi service

2) @OSGiService
using the serviceprops to get OSGi service

Then,

One problem is that once specifying the serviceprops, whether bean classes with @Publish in current bundle all register OSGi Service using * the same serviceprops * or not?

Another problem is that once bean classes with @Publish in current bundle * all or part of them * register OSGi Service using the serviceprops, whether bean classes with @OSGiService all get OSGi Service using * the same serviceprops * or not?

Thanks
Tang

Comment by TangYong [ 31/Oct/12 ]

Apart from the above problems, there is a more important problem needed to be discussed too,

After a user stopped gf's domain, and then is ready to re-start gf's domain, the bundle's deploying on re-starting phrase should keep the bundles's properties or states(serviceprops) the same with previous deploying. That is to say, "serviceprops" must have effect.

In order to resolve the problem, I think that after deploying a bundle with "--properties serviceprops", the service properties should be written into domain.xml liking the following:

<application location="$

{com.sun.aas.instanceRootURI}

/applications/stockquote_service_usingcdi/" name="stockquote_service_usingcdi" object-type="user">
...
<property name="defaultAppName" value="stockquote_service_usingcdi"></property>
<module name="stockquote_service_usingcdi">
...
<property name="archiveType" value="osgi"></property>
...
<!--★Adding Service Properties★ -->
<property name="serviceprops" value="name=lang,value=__CH"></property>

<engine sniffer="osgi"></engine>
</module>
</application>

In such way, when restarting domain, gf can deploy the plain cdi bundle and register/get OSGi Service with previous service properties.

Tang

Comment by Sanjeeb Sahoo [ 01/Nov/12 ]

I don't think we should use --properties option of deployment which is available only if user is using deploy CLI. We need something that's applicable to other modes of deployment. The two choices that come to mind are:

a) Using config admin to configure service criterias
b) Using some sort of deployment plan or runtime descriptors as used by Java EE.





[GLASSFISH-19211] Make @OSGiService support Service Filter Created: 23/Oct/12  Updated: 23/Oct/12

Status: Open
Project: glassfish
Component/s: OSGi-JavaEE
Affects Version/s: future release
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: TangYong Assignee: Sanjeeb Sahoo
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Implementating CDI004 - The specification MUST make it possible to select OSGi services used in CDI beans based on OSGi
filters. Liking the following:

@Inject @OSGiService @ServiceFilter("&(lang=EN)(country=US)") MyService service;






[osgi-cdi]OSGi service automatic publishing with @Publish-liking annotation (GLASSFISH-18938)

[GLASSFISH-19210] make @Publish support Service type resolution Created: 23/Oct/12  Updated: 23/Oct/12

Status: Open
Project: glassfish
Component/s: OSGi-JavaEE
Affects Version/s: future release
Fix Version/s: None

Type: Sub-task Priority: Major
Reporter: TangYong Assignee: Sanjeeb Sahoo
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Pl. see Design Specification[1]-3.4.1. Service type resolution of Weld-OSGi, I have evaluated the feature and found this should be better for a user.