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

Document how Extensions are instantiated #293

Open
dmitry-timofeev opened this issue Mar 4, 2019 · 3 comments
Open

Document how Extensions are instantiated #293

dmitry-timofeev opened this issue Mar 4, 2019 · 3 comments

Comments

@dmitry-timofeev
Copy link
Contributor

It would be nice if org.pf4j.PluginManager#getExtensions had API documentation.

Some things that might be useful to know (or know that they are unspecified, or implementation defined):

  1. When extensions are instantiated (When the plugin is loaded/started? When explicitly requested)? (see How/When are extension classes instantiated? #232)
  2. In which plugin states is it OK to call this method? (In any? In loaded/started only? What happens in forbidden states?)
  3. If I call this method several times and get extensions, is it guaranteed that I will get the same instances?
  4. What will happen if I pass unknown pluginId or an absent extension type? (empty list/exception?)
@decebals
Copy link
Member

decebals commented Mar 5, 2019

  1. If I call this method several times and get extensions, is it guaranteed that I will get the same instances?

By default a new instance is created each time. See ExtensionFactory, DefaultExtensionFactory,
SingletonExtensionFactory and ExtensionFinder#find.

Any time, when someone understand a concept or a workflow from the source code, and he/she considers that the documentation is not good enough/clear, please submit a PR with clarifications, here (for javadoc) or on documentation project. Thanks!

@dmitry-timofeev
Copy link
Contributor Author

I see, thanks! The thing is

  1. Not everything could be easily inferred from the code, hence that many questions.
  2. Some things may be intentionally unspecified (implementation defined) — the code does not communicate that.

@decebals
Copy link
Member

decebals commented Mar 6, 2019

I have said many times, the weaknesses of this project (and probably most of the open source projects) are documentation and test coverage (number of unit tests). Anybody that can help in these directions is an hero for me. If something is not clear from code, please ask and I (and other people) will answer you.
I will always try to improve the javadoc and documentation.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants