Issue Details (XML | Word | Printable)

Key: GLASSFISH-19068
Type: Bug Bug
Status: Resolved Resolved
Resolution: Fixed
Priority: Major Major
Assignee: Hong Zhang
Reporter: TangYong
Votes: 0
Watchers: 1
Operations

If you were logged in you would be able to see more operations.
glassfish

deploying hybrid osgi app with ejb bundle failed based on recent gf trunk

Created: 11/Sep/12 07:28 AM   Updated: 11/Sep/12 03:34 PM   Resolved: 11/Sep/12 03:34 PM
Component/s: deployment, OSGi-JavaEE
Affects Version/s: None
Fix Version/s: 4.0_b54

Time Tracking:
Not Specified

File Attachments: 1. Java Archive File sample.uas.api.jar (4 kB) 11/Sep/12 07:37 AM - TangYong
2. Java Archive File sample.uas.ejbservice2.jar (6 kB) 11/Sep/12 07:28 AM - TangYong
3. Java Archive File sample.uas.entities.jar (9 kB) 11/Sep/12 07:37 AM - TangYong
4. Text File server.log (213 kB) 11/Sep/12 07:28 AM - TangYong

Environment:

1 Windows XP
2 Maven 3.0.4
3 JDK 1.6.0_34
4 GF Trunk 2012/09/11


Tags:
Participants: Hong Zhang and TangYong


 Description  « Hide

[Problem]
deploying hybrid osgi app with ejb bundle failed based on recent gf trunk(2012/09/11)

When using the following command to deploy a hybrid osgi app with ejb bundle, deploying failed.

> asadmin deploy --type=osgi E:\gfv4\gftrunk\fighterfish\sample\uas\ejbservice2\target\sample.uas.ejbservice2.jar

[Failed Info]
1 Cmd's Failed Info

remote failure: Error occurred during deployment: Exception while preparing the app : Unable to load the EJB module. DeploymentContext does not contain any EJB. Check the archive to ensure correct packaging for E:\gf0911\glassfish3\glassfish\domains\domain1\applications\sample.uas.ejbservice2.
If you use EJB component annotations to define the EJB, and an ejb or web deployment descriptor is also used, please make sure that the deployment descriptor references a Java EE 5 or higher version schema, and that the metadata-complete attribute is not set to true, so the component annotations can be processed as expected. Please see server.log for more details.

Command deploy failed.

2 StackTrace on server.log
Pl. see attachment(server.log)

[Deployed Bundle]
Pl. see attachment(sample.uas.ejbservice2.jar)



TangYong added a comment - 11/Sep/12 07:28 AM

Sahoo Said:

Hi Tang,

That looks like a bug in deployment code. I know deployment team was
making some change to make deployment not about "OSGi" type deployment
and I suspect this regression has been introduced during that. Could you
kindly file a bug and assign it to deployment team?

Hong,
The issue here is that an OSGi bundle containing EJBs is being deployed
with --type=osgi option, yet deployment backend is trying to deploy it
as an "ejb" archive as you can see from the exception stack.


TangYong added a comment - 11/Sep/12 07:29 AM

Hong Said,

Sahoo: I just tried a simple EJB OSGi jar test case you gave me before
and I was able to deploy it as an OSGi bundle with --type osgi with no
issues.

Tang: If you have a reproducible test case, please file an issue and I
will take a look to see what I can find..


TangYong added a comment - 11/Sep/12 07:30 AM

Sahoo Said,

> Sahoo: I just tried a simple EJB OSGi jar test case you gave me before
> > and I was able to deploy it as an OSGi bundle with --type osgi with no
> > issues.
Thanks much. Could you please add this to your deployment dev test suite?


TangYong added a comment - 11/Sep/12 07:33 AM - edited

I have reprodued the problem on my gf 09/11 built-snapshot and added the bundles resulting in the problem.


TangYong added a comment - 11/Sep/12 07:37 AM

The complete deploying process is as following:

1 modify the property on config\osgi.properties

org.glassfish.osgjpa.extension.useHybridPersistenceProviderResolver=true

2 asadmin start-domain

3 asadmin start-database

4 asadmin deploy --type=osgi sample.uas.entities.jar

5 asadmin deploy --type=osgi sample.uas.api.jar

6 asadmin deploy --type=osgi sample.uas.ejbservice2.jar

The 6's deployment will failed.


TangYong added a comment - 11/Sep/12 09:25 AM

I have investigated the problem and the results are as following:

1 sortedEngineInfos object contained Deploy Info in the following order.

1) EJB Deploy
2) OSGi Deploy

Pl. see com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:427)

So, EJB Deploying happened before OSGi Deploying.

2 tracing how to get sortedEngineInfos object

On setupContainerInfos(handler, sniffers, context), if sniffers contained EJB Sniffer, sortedEngineInfos will container EJB Deploy Info.

So, continue to trace sniffers object.

Pl. see com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:373)

3 tracing how to get sniffers object

sniffers = getSniffers(handler, sniffers, context);

So, investigated getSniffers method, and found on getSniffers method, sniffers object was get by snifferManager.getSniffers(context) method.
Pl. see
[1] com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:356)
[2] com.sun.enterprise.v3.server.ApplicationLifecycle.getSniffers(ApplicationLifecycle.java:648)

4 about snifferManager.getSniffers(context) method

the method called com.sun.enterprise.v3.server.SnifferManagerImpl.getApplicableSniffers method to get sniffers object, and because regularSniffers collection contained Connector sniffer, EJB sniffer,...OSGi sniffer,.. in such an order. And sample.uas.ejbservice2.jar has javax.ejb.Stateless annotation, so EJB sniffer can match with sniffer search rule on getApplicableSniffers method, and first added into sniffers.

Pl.see com.sun.enterprise.v3.server.SnifferManagerImpl.getApplicableSniffers(SnifferManagerImpl.java:150)

So, I think that "--type=osgi" did not take effect on getting sniffers, and wish hong and shoo confirmed what I said.


TangYong added a comment - 11/Sep/12 09:56 AM

In addition, The problem happened on at org.glassfish.ejb.startup.EjbDeployer.prepare(EjbDeployer.java:191), and I found that when executing ApplicationLifecycle.java:828, the return value of deployer.loadMetaData(provide, context) is null, so the problem happened. However, now, I have not know the reason.


Hong Zhang added a comment - 11/Sep/12 01:48 PM

Thanks for attaching the test case and the initial analysis!

I was able to reproduce the issue and identify the cause and I have a fix in my local workspace now.

Only OSGi sniffer should be returned back and not the ejb sniffer in sniffer retrieval. Previous changes to clean up special handling for OSGi only takes care of the cases where the Sniffer.handles method is used to retrieve sniffer, but not the part where the sniffers were retrieved through annotation scanning. Updated that code path to take the archive type into consideration as well (so any sniffer type other than OSGi will be filtered out). Will check in the change after running the usual set of the tests.


Hong Zhang added a comment - 11/Sep/12 03:34 PM

Fix checked in, svn 55899.