[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-19395] Mapping HK2 annotations(@Service and @Inject) into OBR capability and requirement Created: 30/Nov/12  Updated: 30/Apr/13

Status: In Progress
Project: glassfish
Component/s: OSGi
Affects Version/s: future release
Fix Version/s: None

Type: Task Priority: Critical
Reporter: TangYong Assignee: TangYong
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

Sub-Tasks:
Key
Summary
Type
Status
Assignee
GLASSFISH-19397 using OBR to add mapped capability an... Sub-task Closed Sanjeeb Sahoo  
GLASSFISH-20486 missing a mapping scene where some cl... Sub-task Open TangYong  
GLASSFISH-20487 needing to consider constructor injec... Sub-task Open TangYong  
GLASSFISH-20488 needing to consider initializer metho... Sub-task Open TangYong  
GLASSFISH-20489 needing to consider IterableProvider ... Sub-task Open TangYong  
GLASSFISH-20490 needing to consider org.glassfish.hk2... Sub-task Open TangYong  

 Description   

While using on-demand provisioning of OSGi modules(glassfish.osgi.ondemand=true), we must discovery and install needed bundle and the bundle's dependencies rightly. In order to reach the goal, only using OBR to generate index file is not enough because HK2 world also defined some annotations which are used for service-level dependencies, called @Service and @Inject.

Because @Service and @Inject have an another very important task for implementing on-demand bundle's starting, for example, while deploying a WAB with CDI, WebContainer will be started and at the same time, because WebContainer has a @inject JCDIService, deploying phrase will also start Weld-Integration bundle in which a @Service which implements JCDIService will be registered into HK2 registry.

So, from the point to say, @Service and @Inject also correspond to OBR capability and requirement, if we can not map the annotations, while using OBR to provision, there is an possibility that we will miss some required bundles in felix cache and caused a failure of on-demand starting.



 Comments   
Comment by TangYong [ 04/Dec/12 ]

During several day's investigation, I have some results and solution as following:

Solution: using deprecated Import-Service and Export-Service [1][2]

Although Import-Service and Export-Service head have been deprecated, we
can still use the head to meet our demand because we can consider hk2 level's service dependency as some static service dependency.

I have confirmed that bnd or maven-bundle-plugin supports the two heads and felix obr aslo supports the two heads.

Then, we need to resolve a problem: how to generate Import-Service and Export-Service head?

Method1: manually adding Import-Service and Export-Service head into osgi.bundle file

[Analyse Advantage/Disadvantage]
Advantage: simple and fast
Disadvantage: needing to large scale edit osgi.bundle

Method2: extending some maven plugin(maybe hk2 maven plugin, maybe bnd...) to automaticlly scan bundle(@inject and @Service) and generate
the two heads

[Analyse Advantage/Disadvantage]
Advantage: not editing osgi.bundle manually
Disadvantage: a litter complex and needing to master maven or bnd, and also needing to invesigate how to extend

Method3: Not modifying current module's manifest.mf, after generating obr-modules.xml, adding Import-Service and Export-Service head into the repository file by scanning each bundle

[Analyse Advantage/Disadvantage]
Advantage: not editing osgi.bundle manually and not extending current build architecture
Disadvantage: (1) needing to how to add Import-Service and
Export-Service head into the repository file because felix obr Api has not published similar api. (Note: I have sent a email to felix to consult the thing)

(2) needing to how to scan (@inject and @Service) better and maybe needing to extend osgi-adapter module

As a demostrating, I have used Method1 to add the two heads for web-glue and weld-integration and currently, the two modules have not some direct
dependency(module layer dependency), however, web-glue has a hk2 service
dependency[3] on weld-integration. So, after I edited osgi.bundles of the two modules, obr-modules.xml has added the service related requirement/capability for the two modules.

<resource id='org.glassfish.main.web.glue/4.0.0.SNAPSHOT' symbolicname='org.glassfish.main.web.glue' ...'>
...
<require name='service' filter='(service=com.sun.enterprise.container.common.spi.JCDIService)' extend='false' multiple='true' optional='false'>Import Service com.sun.enterprise.container.common.spi.JCDIService</require>
...

<resource id='org.glassfish.main.web.weld-integration/4.0.0.SNAPSHOT' symbolicname='org.glassfish.main.web.weld-integration' ...>
...
<capability name='service'>
<p n='service' v='com.sun.enterprise.container.common.spi.JCDIService'/>
</capability>
<capability name='service'>
<p n='service' v='org.glassfish.api.naming.NamedNamingObjectProxy'/>
</capability>
<capability name='service'>
<p n='service' v='org.glassfish.weld.ResourceLoaderImpl'/>
</capability>
<capability name='service'>
<p n='service' v='com.sun.enterprise.web.WebComponentDecorator'/>
</capability>
<capability name='service'>
<p n='service' v='org.glassfish.api.container.Container'/>
</capability>
<capability name='service'>
<p n='service' v='org.glassfish.weld.WeldDeployer'/>

[1]: http://wiki.osgi.org/wiki/Import-Service
[2]: RFC-0112 Bundle Repository
[3]: in WebContainer.java, the following declares a service dependency
@Inject @Optional
private JCDIService jcdiService

Comment by TangYong [ 25/Jan/13 ]

Using [3]'s way to edit osgi.bundles , then generating an obr file.

Comment by Sanjeeb Sahoo [ 25/Jan/13 ]

Let's see if we can use method #3 to generate OBR capability/requirement metadata for HK2 service dependencies. I have checked in a framework for a standalone utility for generation of OBR metadata in [1]. Let's see if we can enhance it. Thanks.

[1] https://svn.java.net/svn/glassfish~svn/trunk/fighterfish/experimental/glassfish-obr-builder. Se

Comment by TangYong [ 26/Jan/13 ]

Hi Sahoo,

I have seen and ran glassfish-obr-builder and it is an interesting module, firstly , I want to make you confirm my understanding for the framework.

[My understanding]
1 glassfish-obr-builder's aim should be similar to felix obr to generate capability and requirement from bundle's Manifest.MF.

2 The framework should want to generate capability and requirement into a new obr xml file, although we can output repository info from a existed obr xml(for example, after setting glassfish.osgi.ondemand=true, however, because ondemand starting glassfish is still in incubated status, this should have no sense). But the logic of generating capability and requirement into a new obr xml file is not still finished.

Secondly, I have a question about the framework as following:

[Question about the framework]
Why we use felix obr to generate capability and requirement and instead, re-invent a wheel?
Whether because the framework's API is more easy and convenient than felix obr's API or not?

Thirdly, backing to GLASSFISH-19395, my thinking about whether can re-use the framework or not?

[My thinking]
Sure, no problem, can re-use the framework.And we only need to add the logic of generating capability and requirement from a directory containing OSGi bundles. A point to notice is that if using felix obr, we will directly use felix obr's api to finish such things.

Thanks.

Comment by Sanjeeb Sahoo [ 26/Jan/13 ]

It makes to reuse Felix OBR module instead of writing our own. I leave it to you to do whatever you find easier.

Thanks,
Sahoo

Comment by TangYong [ 28/Jan/13 ]

Hi sahoo,

I have finished the issue and put sources into the following url:

https://github.com/tangyong/glassfish-obr-builder

You can use and see the result according to https://github.com/tangyong/glassfish-obr-builder/blob/master/README.md .

I reused osgi-adapter's ObrHandler and packaged glassfish-obr-builder as an osgi bundle and put the bundle into autostart directory, once glassfish domain starting, glassfish-obr-builder will generate an obr-modules.xml in domains/domain1/osgi-cache/felix directory. This effect is very similar to set glassfish.osgi.ondemand=true. However,glassfish-obr-builder is more simple and can make us do more research on provisioning stories.

Thanks

Comment by TangYong [ 29/Jan/13 ]

Currently, the glassfish-obr-builder is being enhanced in the following fileds:

1 Provisioning Strategy
seeing: https://github.com/tangyong/glassfish-obr-builder/issues/11

2 Creating a client bundle to make an experiment to test 1 using glassfish-obr-builder
seeing: https://github.com/tangyong/glassfish-obr-builder/issues/13

3 Offering a way to populate obr resources from external maven repo
seeing: https://github.com/tangyong/glassfish-obr-builder/issues/8
However, 3's priority is low.

Comment by TangYong [ 29/Jan/13 ]

About the above 3, I have estimated Apache Karaf Cave, and it has such a capability to populate obr resources from an external maven repo and populate obr resources from an user local maven repo to enhance provisioning strategy.

In addition, about 1, once finishing it, I have an initial idea for making a gf kernel's evolution:

1 Defining a subsystems for glassfish according to the following rule
1)admin subsystem
The subsystem is defined by admin infra related bundles, and while starting glassfish domain, we must deploy the subsystem because it is a core bus of glassfish self.

2)javaee 7 spec related large subsystem
The large subsystem is constituted by many subsystems according to javaee 7 spec. For example, for EJB spec, we can define a ejb subsystem which is defined by ejb related bundles. Once we make such a partition, a user can deploy these subsystem in on-demand way according to his/her requirement.

3)osgi-javaee related subsystem
The subsystem is constituted by osgi-javaee related bundles which currently are put into autostart directory.

2 Generating System OBR using glassfish-obr-builder ahead of time
If having 1, while starting glassfish domain, we can firstly generate Glassfish System OBR using glassfish-obr-builder, and according to the Glassfish System OBR, we can deploy admin subsystem and lately also use the Glassfish System OBR to deploy other subsystems.

3 Integrating other the third part's frameworks
Integrating other the third part's frameworks can also use subsystem concept to do. We only need to offer a subsystem which is constituted by the third part's frameworks related bundles. In such a subsystem definition, an user can offer an user-defined obr repo url as provisioning repo. Then, while deploying such a subsystem, we firstly provision bundles from Glassfish System OBR because some bundles maybe have been offered by glassfish, if not finding proper resources, we will provision bundles from user-defined obr repo.

The above idea has the following advantages:
1) speeding up glassfish domain starting
2) saving more spaces rather than installing all bundles into felix cache.
3) making an user have more profiles, for example, if the user creates two domains, in domain1, he/she can deploy some javaee related bundles, in domain2, he/she can deploy some osgi-javaee related bundles.

Comment by TangYong [ 30/Jan/13 ]

>1 Provisioning Strategy
>seeing: https://github.com/tangyong/glassfish-obr-builder/issues/11

Done

>2 Creating a client bundle to make an experiment to test 1 using glassfish-obr-builder
>seeing: https://github.com/tangyong/glassfish-obr-builder/issues/13

Being enhancing...

Currently, a subsystem provioning sample can work normally.

>3 Offering a way to populate obr resources from external maven repo
>seeing: https://github.com/tangyong/glassfish-obr-builder/issues/8
>However, 3's priority is low.

Undo

4 start subsystem based on module start level defined in subsystem xml file
seeing https://github.com/tangyong/glassfish-obr-builder/issues/15

Basic done and a topic needs to be discussed with sahoo.

5 undeploying subsystem

Doing

Comment by Sanjeeb Sahoo [ 05/Feb/13 ]

Tang,

This is great progress. I have been able to build it and test as well. I think there is a slight misunderstanding about how I expected the processing to happen. I noticed you are expecting us to populate Export-Service and Import-Service metadata in osgi.bundle file. I thought approach #3 meant no changes to bundles. We would introspect bundles and generate Export-Service and Import-Service metadata from @Inject and @Service annotations.

Sahoo

Comment by TangYong [ 06/Feb/13 ]

>I thought approach #3 meant no changes to bundles. We would introspect bundles and generate Export-Service and >Import-Service metadata from @Inject and @Service annotations.

I see and I will consider it.

Thanks

Tang

Comment by Sanjeeb Sahoo [ 08/Feb/13 ]

Assigning to Tang

Comment by TangYong [ 29/Apr/13 ]

A new project source has sent into Sahoo and wait for his comment.

Comment by TangYong [ 30/Apr/13 ]

Have checked in sources.

revision: 61742

Comment by TangYong [ 30/Apr/13 ]

At revision: 61748(a litter issue's fix)





[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





Mapping HK2 annotations(@Service and @Inject) into OBR capability and requirement (GLASSFISH-19395)

[GLASSFISH-20488] needing to consider initializer method injection Created: 08/May/13  Updated: 08/May/13

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

Type: Sub-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   

needing to consider initializer method injection.

Eg.

@Service
public class FooImpl implements Foo {
private Book book;

@Inject
public void setBook(Book book)

{ // initializer method injected! this.book = book; }

}






Mapping HK2 annotations(@Service and @Inject) into OBR capability and requirement (GLASSFISH-19395)

[GLASSFISH-20490] needing to consider org.glassfish.hk2.api.Factory mapping Created: 08/May/13  Updated: 08/May/13

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

Type: Sub-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   

needing to consider org.glassfish.hk2.api.Factory mapping. This is a litter similar to jsr330 Provider injection.

Eg.

@Service
public class OsInterfaceFactory implements Factory<OsInterface> {
...
}

@Service(name="ubuntu")
public class Ubuntu implements OsInterface {
...
}

In this scene, we must analyze OsInterfaceFactory class and find the interface(OsInterface) from Factory, then, adding import-service capability of OsInterfaceFactory class for OsInterface.






Mapping HK2 annotations(@Service and @Inject) into OBR capability and requirement (GLASSFISH-19395)

[GLASSFISH-20487] needing to consider constructor injection Created: 08/May/13  Updated: 08/May/13

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

Type: Sub-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   

needing to consider constructor injection.

Eg.

@Service
public class FooImpl implements Foo {
private final Book book;

@Inject
public FooImpl(Book book)

{ // constructor injected! this.book = book; }

}






Mapping HK2 annotations(@Service and @Inject) into OBR capability and requirement (GLASSFISH-19395)

[GLASSFISH-20486] missing a mapping scene where some classes will be advertised as itself and by any interfaces that are marked with @Contract Created: 08/May/13  Updated: 08/May/13

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

Type: Sub-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   

currently, org.glassfish.main.glassfish-obr-builder experimental module missed a mapping scene where some classes will be advertised as itself and by any interfaces that are marked with @Contract.

Eg.

@Contract
public interface Foo {
}

@Service
public class FooImpl implements Foo {
}

The FooImpl class will be placed into the registry advertised under both FooImpl and Foo.

Also needing to consider interface apart from class itself.






[GLASSFISH-19979] OSGi Console Requests Basic Login even if Server is Running with No Password Created: 21/Mar/13  Updated: 26/Mar/13

Status: Open
Project: glassfish
Component/s: OSGi
Affects Version/s: 4.0_b79
Fix Version/s: future release

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

GlassFish Server Open Source Edition 4.0 (build 80)


Tags: fishcat

 Description   

Click on server(Admin Server)
Click on OSGi Console

Basic Auth Challenge:

"A username and password are being requested by http://localhost:8080. The site says: "GlassFish Server""

Server is running with no password.



 Comments   
Comment by TangYong [ 21/Mar/13 ]

Sahoo, Anissa,

In current trunk, OSGi Console has been removed from admin-gui, and that is to say, while clicking on server(Admin Server), "OSGi Console" does not exist.

So, for FishCat testing, whether the issue is valid or not?

If being invalid, whether needing to make an more clear description for FishCat testers about using which versions and which features needs to be tested?

Thanks
--Tang

Comment by Anissa Lam [ 25/Mar/13 ]

I am not aware of any plan of integrating OSGi console to admin console for GlassFish 4.0.
Transfer to Sahoo

Comment by Sanjeeb Sahoo [ 25/Mar/13 ]

Tang,

I don't understand what you mean by "In current trunk, OSGi Console has been removed from admin-gui." OSGi console extension was never part of default distribution in previous releases. It was always distributed via update centre as an extension.

The issue is valid, but I don't know how to fix. May be Anissa can tell us how they fix the login issue in admin console. Do they attempt to login without password when the first request is made?

Anyway, I am defering this issue to future release. It's not very important to be fixed in 4.0.

Sahoo

Comment by TangYong [ 26/Mar/13 ]

Sahoo

Maybe I have made a mistake that I saw the "OSGi Console" in my env because previously I downloaded OSGi Console from update center. So, I said "current ....".

Just as you said, the issue is not important for 4.0 release.

Tang

Comment by Sanjeeb Sahoo [ 26/Mar/13 ]

The behavior of the GlassFish when there is only one administrative user in the system is explained in [1] like this:

If the domain contains exactly one valid administrative account, then GlassFish considers that account to be the default admin account. If at any time there are at least two admin accounts, GlassFish treats no admin account as the default.

When you install GlassFish or create a new domain, GlassFish creates a default admin account, with default username "admin" and an empty default password. So suppose you have just installed GlassFish. If you send an admin request to the DAS with no username, the DAS will act as if your request had actually specified "admin" for the username. Specifying no password is equivalent to giving an empty password - which conveniently is the password for the out-of-the-box default admin account.

All this means that you can run asadmin commands – or use the admin console or submit REST requests – without having to specify an admin username or password. This is consistent with past releases of GlassFish.

So, we can try something like this in our Felix WebConsole Extension where we have implemented the security feature of OSGi console. We can try asking the system for default user name and use that along with an empty password. If we fail, we can prompt user with a password.

Anyway, we shall attempt it in a future release.

[1] https://blogs.oracle.com/quinn/entry/securing_adminstration_in_glassfish_server

Comment by TangYong [ 26/Mar/13 ]

Assigned to me to implement the issue in the future release.





[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-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-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-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-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





Mapping HK2 annotations(@Service and @Inject) into OBR capability and requirement (GLASSFISH-19395)

[GLASSFISH-20489] needing to consider IterableProvider injection Created: 08/May/13  Updated: 08/May/13

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

Type: Sub-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   

needing to consider IterableProvider injection.

Eg.

@Service
public class Library {
@Inject
private IterableProvider<Book> allBooks;

public LinkedList<Book> getAllBooks() {
LinkedList<Book> retVal = new LinkedList<Book>();

for (Book book : allBooks)

{ retVal.add(book); }

return retVal;
}
}

From semantic, IterableProvider should be same as obr's "multiple" attribute. Although "multiple" attribute has not any effect on deploying in current obr implementation. However, from OSGi r5 Resolver spec, "multiple" attribute should be implemented , so, we still need to consider it.

Currently, I will lower the priority of the sub-task.






[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





Generated at Mon Jul 06 22:37:19 UTC 2015 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.