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

Add ServiceUsage utility and OSGiServiceInjector test-rule #726

Closed
wants to merge 1 commit into from

Conversation

HannesWell
Copy link
Contributor

This PR is is intended to incubate/try out two utilities to simplify the correct usage of OSGi services:

  • ServiceUsage which is effectively an AutoClosable Wrapper around a service usage that can be used inside a try-with-resources block and ensures that the service object is unget after it has been used. It is currently located in M2EUtils and can be obtained via the useService(Class) respectively useService(Class, Function).
  • OSGiServiceInjector JUnit-4 rule which injects OSGi service implementation into correspondingly annotated Test-class fields.
    The implementation currently based on the E4's ContextInjectionFactory but it likely has to be implemented 'manually' by using a ServiceTracker per field that is closed after the evaluation because the EclipseContextOSGi ungets the service-reference immediately. Using custom annotations like @InjectService would also make it more clear what is happening and would allow parameters if necessary (to specify the element type of a collection?).
    The same functionality could be implemented for JUnit-5 using a corresponding Extension.

I already applied them to a few locations within the m2e-core code-base and in tesla/m2e-core-tests#155 but there are more possible.

I think similar functionality could also be useful for many Eclipse-Platform projects because Services are there often not used correctly.
Finally it could maybe even be considered for inclusion into OSGi itself respectively osgi-test (although useService() requires Java-9+).

@laeubi what do you think?

if(context == null) {
throw new IllegalStateException("Test bundle <" + bundle.getSymbolicName() + "> not started");
}
// TODO: BundleContextOSGi ungets services immediately!
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is something that should be addressed at E4 and not at m2e

@laeubi
Copy link
Member

laeubi commented May 20, 2022

If you want to only access a service once eclipse has "ServiceCaller" class already, but one should be aware that getting/ungetting a service might create noise, so I think this should really only be used in very rare cases.

@HannesWell
Copy link
Contributor Author

If you want to only access a service once eclipse has "ServiceCaller" class already, but one should be aware that getting/ungetting a service might create noise, so I think this should really only be used in very rare cases.

Thank you for the suggestion.
I just drafted a PR to add a corresponding method to it:
eclipse-equinox/equinox#146

I plan to create a corresponding PR to add something like the suggested Junit-Rule to inject OSGi-services for tests to org.eclipse.test and will then abandon this PR.

@laeubi
Copy link
Member

laeubi commented Oct 28, 2022

Finally it could maybe even be considered for inclusion into OSGi itself respectively osgi-test (although useService() requires Java-9+).

OSGi Test already has ways to fetch services by annotations:

https://github.com/osgi/osgi-test/blob/main/org.osgi.test.junit5/README.md#testing-with-osgi-services

I really like to see this getting used but currently it is a bit horrible to use inside PDE see:

and not very intuitive to include it in Tycho see:

so probably it would be much more better to improve the support here at PDE/Tycho than adding more "helpers" ...

@laeubi laeubi closed this Dec 14, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants