Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix failing transaction recovery when OSGi applications are present. (Payara-659) #681

Merged
merged 1 commit into from Apr 8, 2016

Conversation

pdudits
Copy link
Contributor

@pdudits pdudits commented Feb 26, 2016

Fixes #679

OSGi applications do not have (EE) Application metadata, leading to NPE at line 267

…ixes payara#679

OSGi applications do not have Application metadata, leading to NPE.
@payara-ci
Copy link
Contributor

Can one of the admins verify this patch?

@smillidge
Copy link
Contributor

You can get OSGI apps with EJBs see issue #673. We need to ensure we test this scenario when merging.

@pdudits
Copy link
Contributor Author

pdudits commented Feb 26, 2016

Oh yes, OSGi hybrid apps is the only feature we don't use in my project (anymore :))

But as I remember the way it worked, it was OSGi extenders bridging to the containers, and EJB engine was not associated with the app. So I'd expect these will also have empty metadata and isJavaEE flag set to false, therefore preventing the bug. I'll try with to test with some hybrid module, the payarabug has an MDB, and we have OpenMQ switched off and use ActiveMQ instead here.

@chrjohn
Copy link
Contributor

chrjohn commented Feb 26, 2016

Hi @pdudits , if you tell me how to check the isJavaEE flag I'd be happy to do it here on my installation. Can I query that flag via some console or do I have to debug a running Payara? Can it maybe be seen when I turn up some logging?

Thanks,
Chris.

Edit: just checked a heap dump. For the hybrid OSGi apps the flag isJavaEEApp is set to false.

@pdudits
Copy link
Contributor Author

pdudits commented Feb 26, 2016

@chrjohn Exactly, I was looking at the heap dump. Can you please check if metadata map is empty, so I don't need to build my PoC to deploy into my environment?

@chrjohn
Copy link
Contributor

chrjohn commented Feb 26, 2016

@pdudits Yes, metadata map is empty for non-JavaEE apps.

When checking the deployed modules on my payara installation it seems that only hybrid bundles with MDBs are flagged as non-JavaEE apps. Hybrid bundles containing session beans are flagged as JavaEE app.
I don't know if that matters.

@pdudits
Copy link
Contributor Author

pdudits commented Feb 26, 2016

What matters is, that when the app isJavaEE, then it must have entry for com.sun.enterprise.deployment.Application in its metadata. This seems to hold with my single-ejb hybrid module, but please verify that in your environment as well.

@chrjohn
Copy link
Contributor

chrjohn commented Feb 26, 2016

Yes, I can confirm that JavaEE apps have the Application in their metadata hashmap.

@smillidge smillidge added the PR: CLA CLA submitted on PR by the contributor label Mar 9, 2016
@smillidge
Copy link
Contributor

Tagged as Payara-659 internally

@smillidge smillidge added this to the Payara Server 4.1.1.162 milestone Mar 9, 2016
@smillidge smillidge changed the title Fix failing transaction recovery when OSGi applications are present. … Fix failing transaction recovery when OSGi applications are present. (Payara-659) Mar 9, 2016
@Pandrex247
Copy link
Member

@pdudits Can you attach or link a test case please?

The change looks like it makes sense, but I'd like to see and run your tests on our end before merging the change.

Thanks

@pdudits
Copy link
Contributor Author

pdudits commented Apr 7, 2016

Hi,

The general test case is:

  1. Deploy any OSGi bundle with asadmin deploy --type osgi <bundle.jar>
  2. trigger transaction recovery - I think the general prerequisite is to start a cluster or standalone instance and require a transacation during startup.

As for actual test scenario, I was migrating a project from Glassfish 3.1.2 onto Payara, and I cannot share the application(s) involved here.

@Pandrex247
Copy link
Member

jenkins test please

@payara-ci
Copy link
Contributor

All tests have passed

@Pandrex247 Pandrex247 merged commit ad24c78 into payara:master Apr 8, 2016
@pdudits pdudits deleted the payara-679 branch May 20, 2019 06:46
arieki pushed a commit to arieki/Payara that referenced this pull request Nov 15, 2022
FISH-6495 : verifying if property was passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
PR: CLA CLA submitted on PR by the contributor
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants