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

pass app-label info into factory when registering objects #12106

Closed
rwcarlsen opened this issue Sep 10, 2018 · 0 comments
Closed

pass app-label info into factory when registering objects #12106

rwcarlsen opened this issue Sep 10, 2018 · 0 comments
Assignees
Labels
C: Framework P: normal A defect affecting operation with a low possibility of significantly affects.

Comments

@rwcarlsen
Copy link
Contributor

Rationale

Currently, the moose object factory throws an error if you register an object of the same class name more than once. This is to prevent name-clash errors between an app and other apps it depends on (e.g. two apps compiled together that both have a FooBar user object).

In order to move to a system where an app only has to instigate object registration for its direct dependencies (i.e. not transitive ones), we need to allow for the case that multiple paths through the app/module dependency graph of an app may reach the same transitive dependency. When I create FooApp that depends on App1 and App2 and both App1 and App2 depend on BarModule - I only want to have to call App1::registerObjects(factory) and App2::registerObjects(factory) from my app's registerObjects function. But this would mean that both App1 and App2 would call BarModule::registerObjects(factory) - causing an error for duplicate registration.

We need to allow the same object to be registered (without causing an error) to a factory multiple times as long as that object comes from the same application every time.

Description

The information necessary to relax the factory duplicate registration error checking already exists in the global Registry - it is just never passed to the factory. We need to pass this information (which app label each object is associated with) into the factory along with the object name when calling Factory::reg. This will facilitate allowing duplicate registrations making it possible to do automatic transitive app dependency object registration (which will require updating apps' registerObjects functions to call their direct dependencies' registerObjects functions in addition to registering their own objects).

Impact

Should not require breaking any "external" APIs - only possibly modifying very internal Factory::reg function argument parameters. Mostly just enable more natural, robust objects registration for apps that depend on other apps/modules

@rwcarlsen rwcarlsen self-assigned this Sep 10, 2018
@rwcarlsen rwcarlsen added C: Framework P: normal A defect affecting operation with a low possibility of significantly affects. labels Sep 10, 2018
rwcarlsen added a commit to rwcarlsen/moose that referenced this issue Sep 14, 2018
sveerara pushed a commit to sveerara/moose that referenced this issue Sep 21, 2018
rwcarlsen added a commit to rwcarlsen/moose that referenced this issue Sep 26, 2018
for Moose and for the test app.  Deprecate the
Moose::register[Objects/Actions/etc.] functions.  Make ActionFactory
and Syntax classes be idempotent w.r.t. registering stuff - so they
correctly allow and don't incorrectly error for repeated/identical
registrations. Modify MooseTestApp to only use/call
registerAll and to not do anything else in its constructor.

fully fixes idaholab#12106. ref idaholab#12136
jwpeterson added a commit to idaholab/falcon that referenced this issue Nov 14, 2018
*** Warning, This code is deprecated and will be removed in future versions!
use registerAll instead of registerObjects

Refs idaholab/moose#12106
Refs idaholab/moose#12136
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C: Framework P: normal A defect affecting operation with a low possibility of significantly affects.
Projects
None yet
Development

No branches or pull requests

1 participant