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

Improve plugin loader #1427

Closed
wants to merge 2 commits into from

Conversation

Projects
None yet
4 participants
@nathanhourt
Copy link
Contributor

commented Nov 9, 2018

Replaces #1424

This PR adds the ability for client code of the application class to request plugins be loaded automatically when it registers them. I don't know if upstream bitshares will want this or not, but here's a PR just in case!

This PR is mostly a clean-up/correctness fix (the old conflict detection between the account_history and elasticsearch plugins was clumsy and would false-positive if either plugin showed up twice in the list), but it does add the ability to mark plugins to be loaded automatically when they are registered.

Please note that this PR does remove the hard-coded list of "wanted" plugins, as this shortcut is annoying to third party code, like that of Follow My Vote, which may not want to be cluttered up by having those plugins linked in. This may cause mild turbulence to existing environments which depend on this shortcut. #sorrynotsorry =) This turbulence can be avoided by calling register_plugin(true) for the desired auto-load plugins, however, doing so will prevent disabling these plugins from the config.

nathanhourt added some commits Nov 7, 2018

Allow required plugins
As far as I can tell, there was no way previously for an application
to register a plugin and ensure that plugin got loaded -- it would
be necessary to manually edit the config and specify the plugin be
loaded.

This is suboptimal; if third party code wishes to track third party
extensions on the blockchain, the correct way to do this is with a
plugin, and this third party build should be able to load these
required plugins regardless of whether the config lists them or not.

This commit adds a boolean parameter to application::register_plugin
which defaults to false for backwards compatibility; however, if
set to true, the plugin will automatically be enabled when the app
initializes.
Clean up plugin loader
That code was nasty and... kinda wrong. So fix it up all shiny-like.

But I also removed the super annoying default "wanted" plugins list,
which only causes problems for third parties like me, and in general is
just poor form. In my opinion, 5220425
provides a much cleaner way to do this, in a way that is friendly rather
than hostile to third parties.

Would Be Nice: A generalized plugin conflict system added at the
abstract_plugin level, so, for example, the elasticsearch plugin can
conflict account_history and we deal with this in a general fashion
rather than having this dirty special case check here.
@cogutvalera
Copy link
Member

left a comment

there is error in cli_test:

/home/travis/build/bitshares/bitshares-core/tests/cli/main.cpp(552): error in "account_history_pagination": check 201 == history.size() failed [201 != 0]

This error is caused by if (options.count("plugins")), why did you remove else branch ? what will be if there are no options.count("plugins") ? IMHO you should add in else branch next snippet of code as was before:

      plugins.emplace("witness");
      plugins.emplace("account_history");
      plugins.emplace("market_history");
      plugins.emplace("grouped_orders");

and after that (I mean if/else statement) we should use next snippet of code:

   FC_ASSERT(!(plugins.count("account_history") && plugins.count("elasticsearch")),
      "Plugin conflict: Cannot load both account_history plugin and elasticsearch plugin");
   std::for_each(plugins.begin(), plugins.end(), [this](const string& plug) mutable {
   if (!plug.empty())
      enable_plugin(plug);
   });

Now the problem is in cli_test that it cannot use account_history plugin because it wasn't loaded.

@cogutvalera

This comment has been minimized.

Copy link
Member

commented Nov 10, 2018

final code looks something like next (libraries/app/application.cpp):

   std::set<string> plugins;
   if (options.count("plugins")) {
      boost::split(plugins, options.at("plugins").as<std::string>(), [](char c){return c == ' ';});
   } else {
      plugins.emplace("witness");
      plugins.emplace("account_history");
      plugins.emplace("market_history");
      plugins.emplace("grouped_orders");
   }

   FC_ASSERT(!(plugins.count("account_history") && plugins.count("elasticsearch")),
      "Plugin conflict: Cannot load both account_history plugin and elasticsearch plugin");

   std::for_each(plugins.begin(), plugins.end(), [this](const string& plug) mutable {
      if (!plug.empty())
         enable_plugin(plug);
   });
@cogutvalera

This comment has been minimized.

Copy link
Member

commented Nov 10, 2018

with my final code cli_test will pass successfully without any errors detected

@pmconrad

This comment has been minimized.

Copy link
Contributor

commented Nov 10, 2018

Thanks!

IMO, with our current architecture, we don't need this functionality, as there are no mandatory plugins. All mandatory stuff is inside the core.

We should not remove the default selection of plugins, because we don't want to break existing installations that rely on defaults.

The conflict detection code looks better than before.

@oxarbitrage

This comment has been minimized.

Copy link
Member

commented Nov 27, 2018

closing this one as the best candidate is #1437

will be merged after getting 1 approval.

@nathanhourt nathanhourt deleted the nathanhourt:patch-2 branch Nov 29, 2018

oxarbitrage added a commit that referenced this pull request Jan 20, 2019

Merge pull request #1437 from oxarbitrage/pull1427_2
move --plugins from application to binary #1427
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.