OroCRM Forums

Covering OroCRM topics, including community updates and company announcements.

Forums Forums OroCRM Migrations crash after adding FOSOAuthServerBundle

This topic contains 7 replies, has 2 voices, and was last updated by  Dylan 2 years, 11 months ago.

Starting from March 1, 2020 the forum has been switched to the read-only mode. Please head to StackOverflow for support.

  • Creator
  • #37938


    I’m experiencing a strange bug while trying to update my oro platform. I’m currently on version 1.8 and I decided the best way to update would be to just create a new clean oro installation and then add my source code and configs. I’m trying to update to version 3.1.0-beta in preparation for the 3.1 LTS version that is supposed to be released this month.
    I was in the process on adding additional configs and libraries and I ran into an issue that I don’t know how to resolve. I downloaded ‘FOSOAuthServerBundle’, added the bundle to the kernel

    and then added the follow lines to my config.yml

    However after doing this, whenever I run schematic migrations they crash with the following error:

    Process migrations…
    > Oro\Bundle\EntityExtendBundle\Migration\LoadEntityConfigStateMigration
    > Oro\Bundle\MigrationBundle\Migration\UpdateBundleVersionMigration
    > Oro\Bundle\EntityExtendBundle\Migration\RefreshExtendCacheMigration

    In RuntimeReflectionService.php line 63:

    Property Oro\Bundle\UserBundle\Entity\User::$avatar does not exist

    oro:entity-extend:cache:clear [–no-warmup] [-h|–help] [-q|–quiet] [-v|vv|vvv|–verbose] [-V|–version] [–ansi] [–no-ansi] [-n|–no-interaction] [-e|–env ENV] [–no-debug] [–disabled-listeners DISABLED-LISTENERS] [–current-user CURRENT-USER] [–current-organization CURRENT-ORGANIZATION] [–] <command>

    ERROR: The command terminated with an exit code: 1.
    > Oro\Bundle\EntityConfigBundle\Migration\UpdateEntityConfigMigration – skipped
    > Oro\Bundle\EntitySerializedFieldsBundle\Migration\SerializedDataMigration – skipped
    > Oro\Bundle\EntityExtendBundle\Migration\UpdateExtendConfigMigration – skipped
    > Oro\Bundle\ActivityContactBundle\Migration\ActivityContactMigration – skipped
    > Oro\Bundle\ActivityListBundle\Migration\ActivityListMigration – skipped
    > Oro\Bundle\EntityExtendBundle\Migration\UpdateExtendIndicesMigration – skipped
    > Oro\Bundle\EntityConfigBundle\Migration\WarmUpEntityConfigCacheMigration – skipped

    In MigrationExecutor.php line 116:

    Failed migrations: Oro\Bundle\EntityExtendBundle\Migration\RefreshExtendCacheMigration.

    and I’m very confused becuase I don’t understand how adding FOSOAuthServerBundle is related to generetating extend entities. I thougth that maybe the FOSOAuthServerBundle is overriding something important but I wasn’t able to find out anything useful.
    I know that I’m running a beta version but I’m at my wits end and don’t know how to solve this problem. I would appreciate any help.
    Thank you for your time

Viewing 7 replies - 1 through 7 (of 7 total)
  • Author
  • #37940

    Yevhen Shyshkin

    Hello Dylan.

    Such error usually indicated that some bundle tries to load extended entity before aliases for extended classes in fact were loaded in OroExtendEntityBundle. Need to debug further to understand why it happened.

    I’d recommend to register this bundle in the standard Oro way (i.e. using Resources/config/oro/bundles.yml, example https://github.com/oroinc/platform/blob/3.1.0-rc/src/Oro/Bundle/PlatformBundle/Resources/config/oro/bundles.yml) and set correct priority.



    Thank you for your quick response.
    I tried your suggestion, unforunately the problem still remains.
    I tried debugging the problem myself all the way to the class ‘\Doctrine\Common\Persistence\Mapping\RuntimeReflectionService’ where the exception is thrown in this line:
    $reflectionProperty = new ReflectionProperty($class, $property); with parameters ‘Oro\Bundle\UserBundle\Entity\User’ and ‘avatar’. I tried dumping a reflection of the user class and it seems that the class is extending ‘Oro\Bundle\UserBundle\Model\ExtendUser’ rather than ‘Extend\Entity\EX_OroUserBundle_User’ which has the avatar property. I don’t know if that helps at all. I tried debugging it further but inner workings of oro are just too complex to fur and I couldn’t understand them.
    I’m using 1.6.1 version of FOSOAuthServerBundle.
    I will gladly provide more information that you would need.
    thanks again for your time


    Yevhen Shyshkin

    > ‘Extend\Entity\EX_OroUserBundle_User’ which has the avatar property
    Yes, this is the expected behaviour. OroExtendEntityBundle creates class aliases from Oro\Bundle\UserBundle\Model\ExtendUser to ‘Extend\Entity\EX_OroUserBundle_User and lools like some code is requesting User class before these aliases were loaded.

    Btw, what priority did you set to FOSOAuthServerBundle in bundles.yml file?



    I initially tried setting the priority to 200 so it’s higher than all oro bundles. I then tried a few different priorities, higher and lower, but nothing seems to have worked.
    Is there any way I could identify what is requesting the class before the aliases were loaded?



    UPDATE: I think I might have found what causing the problem, allthougth I still don’t know how to fix it. The aformentioned entities ‘App\Bundle\UserBundle\Entity\AccessToken’, ‘App\Bundle\UserBundle\Entity\RefreshToken’ and ‘App\Bundle\UserBundle\Entity\AuthCode’ have a user property
    * @var \Oro\Bundle\UserBundle\Entity\User
    * @ORM\ManyToOne(targetEntity="Oro\Bundle\UserBundle\Entity\User")
    * @ORM\JoinColumn(name="user_id", referencedColumnName="id", onDelete="SET NULL")
    protected $user;
    Because I didn’t know what else to do I tried just commenting these properties, deleting the cache and then running the migrations again and this time the migrations didn’t crash. I still don’t understand how this could be causing a problem, I have plenty of other entities that have a user property.


    Yevhen Shyshkin

    Dylan, you may set a breakpoint in the autoloader and check when User class first time loaded – it has to happen after the OroEntityExtendBundle loaded class aliases.

    We’ve faced such issues when somebody used User::class or User::<CONSTANT> notations as they trigger class autoloading. Solution is simple – use values instead.



    I haven’t been able to solve the issue but in the end I decided to remove the ‘FOSOAuthServerBundle’ all together, I’ve been wanting to remove it for a while anyway.
    Thank you for all the support anyway


Viewing 7 replies - 1 through 7 (of 7 total)

The forum ‘OroCRM’ is closed to new topics and replies.

You will be redirected to [title]. Would you like to continue?

Yes No