Could not denormalize object of type RouteCollection

[hmillet]

Hi,

Trying to use the Pre-release - 2.0.0-alpha1 with Symfony 3.2, I get the following exception

Could not denormalize object of type Symfony\Component\Routing\RouteCollection, no supporting normalizer found

when I call

/js/routing?callback=fos.Router.setData

I know, this is an alpha...

Does anyone know a quick workaround, or should I only have to be patient until next release ?

Will you consider upgrading this bundle in order it works with sf 3 ?

Thanks for your answer

[stof]

Can you give the stack trace of the exception too ?

[hmillet]

Here it is.

Now, I can be much more precise :

• It only fails when no route are exposed (so in fact this issue is not really critical ...)
• when I clear the symfony cache, it works... once

    Symfony\Component\Serializer\Exception\UnexpectedValueException: Could not denormalize object of type Symfony\Component\Routing\RouteCollection, no supporting normalizer found.
    at n/a
        in /home/hmillet/workspaces/wayatech/waya-backup-gui/vendor/symfony/symfony/src/Symfony/Component/Serializer/Serializer.php line 267

    at Symfony\Component\Serializer\Serializer->denormalizeObject(array(), 'Symfony\\Component\\Routing\\RouteCollection', 'json', array())
        in /home/hmillet/workspaces/wayatech/waya-backup-gui/vendor/symfony/symfony/src/Symfony/Component/Serializer/Serializer.php line 174

    at Symfony\Component\Serializer\Serializer->denormalize(array(), 'Symfony\\Component\\Routing\\RouteCollection', 'json', array())
        in /home/hmillet/workspaces/wayatech/waya-backup-gui/vendor/symfony/symfony/src/Symfony/Component/Serializer/Serializer.php line 132

    at Symfony\Component\Serializer\Serializer->deserialize('[]', 'Symfony\\Component\\Routing\\RouteCollection', 'json')
        in /home/hmillet/workspaces/wayatech/waya-backup-gui/vendor/friendsofsymfony/jsrouting-bundle/Controller/Controller.php line 91

    at FOS\JsRoutingBundle\Controller\Controller->indexAction(object(Request), 'js')
        in  line 

    at call_user_func_array(array(object(Controller), 'indexAction'), array(object(Request), 'js'))
        in /home/hmillet/workspaces/wayatech/waya-backup-gui/var/cache/dev/classes.php line 4898

    at Symfony\Component\HttpKernel\HttpKernel->handleRaw(object(Request), 1)
        in /home/hmillet/workspaces/wayatech/waya-backup-gui/var/cache/dev/classes.php line 4853

    at Symfony\Component\HttpKernel\HttpKernel->handle(object(Request), 1, true)
        in /home/hmillet/workspaces/wayatech/waya-backup-gui/vendor/symfony/symfony/src/Symfony/Component/HttpKernel/Kernel.php line 168

    at Symfony\Component\HttpKernel\Kernel->handle(object(Request))
        in /home/hmillet/workspaces/wayatech/waya-backup-gui/web/app_dev.php line 32

[stof]

If it only happens when there is no exposed routes, I know what the issue is and how to fix it. Thanks for this additional info.

[stof]

and regarding clearing the cache, this is logical, as this exception happens when loading the exposed routes from the cache (and so the first request after clearing the cache does not have this issue, as there is no cache to reload yet)

[tobias-93]

Is this issue still actual?

[jcrombez]

I just got it with a fresh install so yes.
Clearing the cache "fixed" the issue for one request, then the error came back.

[bilalyilmax]

Same error like jcrombez's, Any solution?

[tobias-93]

I have committed a fix in the master branch, could one of you check if the issue is fixed? If that is the case I'll tag a new release.

[zquintana]

@tobias-93, I tried your fix on master on a project I'm working on. It doesn't throw an exception, but the routes are empty:

/**/fos.Router.setData({"base_url":"\/app_dev.php","routes":[],"prefix":"","host":"localhost","scheme":"http"});

[zquintana]

Turns out the routes were empty because I forgot the options expose attribute in the route config. Thanks for the fix!

[tobias-93]

@zquintana thank you for confirming the fix works. The fix is specifically for the case that no routes are exposed, so that would be expected behaviour. Did you also check it worked without exposed routes after building the cache?