8000 [3.4] container.dumper.inline_class_loader triggers access level exception · Issue #25353 · symfony/symfony · GitHub
[go: up one dir, main page]
Skip to content

[3.4] container.dumper.inline_class_loader triggers access level exception #25353

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.

Sign up for GitHub

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

Jump to bottom
Closed
stefandoorn opened this issue Dec 6, 2017 · 5 comments
Closed

[3.4] container.dumper.inline_class_loader triggers access level exception #25353

stefandoorn opened this issue Dec 6, 2017 · 5 comments

Comments

@stefandoorn
Copy link
Q A
Bug report? yes
Feature request? no
BC Break report? no
RFC? no
Symfony version 3.4.1

I just upgraded from 3.3.13 to 3.4.1, which goes correctly now (had some issues, solved now). I read somewhere that enabling the container.dumper.inline_class_loader could dramatically speed up development environments, which I can confirm. Load times for the first page tested on development was 50% faster.

The first request works after clearing cache, but my second request (doesn't matter which page in my system) runs into the following error. Without the parameter enabled, this error does not occur.

FatalErrorException:
Compile Error: Access level to Symfony\Cmf\Bundle\MediaBundle\Adapter\ElFinder\PhpcrDriver::$options must be protected (as in class FM\ElFinderPHP\Driver\ElFinderVolumeDriver) or weaker

class PhpcrDriver extends ElFinderVolumeDriver

$options in PhpcrDriver is private. In ElFinderVolumeDriver it is indeed protected. I understand that this is an issue anyway.

But I'm not sure why it only errors out when this parameter is enabled and not before..
@nicolas-grekas
Copy link
Member

With the parameter enabled, some classes on the hot path are now always loaded. Previously, this class would have been loaded lazily, and thus the error would been seen when actually using the service.

@stefandoorn
Copy link
Author

Ok, that sounds logic. I hot fixed it in vendor to temporary bypass it and the next error pops up, also probably from a wrong implementation but it's totally different so wanted to share it with you:

PHP Fatal error:  Uncaught Symfony\Component\Debug\Exception\ContextErrorException: Warning: Illegal offset type in isset or empty in /var/www/webshop/vendor/symfony/symfony/src/Symfony/Component/DependencyInjection/Dumper/PhpDumper.php:356
Stack trace:
#0 /var/www/webshop/vendor/symfony/symfony/src/Symfony/Component/DependencyInjection/Dumper/PhpDumper.php(417): Symfony\Component\DependencyInjection\Dumper\PhpDumper->collectLineage(Object(Symfony\Component\DependencyInjection\Parameter), Array)
#1 /var/www/webshop/vendor/symfony/symfony/src/Symfony/Component/DependencyInjection/Dumper/PhpDumper.php(801): Symfony\Component\DependencyInjection\Dumper\PhpDumper->addServiceInclude('lakion_cms.repo...', Object(Symfony\Component\DependencyInjection\Definition), Object(SplObjectStorage))
#2 /var/www/webshop/vendor/symfony/symfony/src/Symfony/Component/DependencyInjection/Dumper/PhpDumper.php(856): Symfony\Component\DependencyInjection\Dumper\PhpDumper->addService('lakion_cms.repo...', Object(Symfony\Component\DependencyInjection\Def in /var/www/webshop/vendor/symfony/symfony/src/Symfony/Component/DependencyInjection/Dumper/PhpDumper.php on line 356

Fatal error: Uncaught Symfony\Component\Debug\Exception\ContextErrorException: Warning: Illegal offset type in isset or empty in /var/www/webshop/vendor/symfony/symfony/src/Symfony/Component/DependencyInjection/Dumper/PhpDumper.php on line 356

Symfony\Component\Debug\Exception\ContextErrorException: Warning: Illegal offset type in isset or empty in /var/www/webshop/vendor/symfony/symfony/src/Symfony/Component/DependencyInjection/Dumper/PhpDumper.php on line 356

Call Stack:
   12.4243   61064960   1. Symfony\Component\Debug\ErrorHandler->handleException() /var/www/webshop/vendor/symfony/symfony/src/Symfony/Component/Debug/ErrorHandler.php:0

screen shot 2017-12-06 at 12 54 09

@sroze
Copy link
Contributor
sroze commented Dec 6, 2017

Did you clear your cache after "fixing within the vendors" ? 🤔

@nicolas-grekas nicolas-grekas mentioned this issue Dec 6, 2017
Merged
@nicolas-grekas
Copy link
Member
nicolas-grekas commented Dec 6, 2017 •
edited
Loading

You folks are doing too crazy things :)
Who is using new Parameter() to define the class of a service?
Anyway, fixed in #25354

@stefandoorn
Copy link
Author
903E stefandoorn commented Dec 6, 2017

Hahaha :) Never knew this vendor bundle was doing that.. :(

@sroze Yes I did, same error.

@nicolas-grekas Change works :-) Thanks!

fabpot added a commit that referenced this issue Dec 8, 2017
@fabpot
bug #25354 [DI] Fix non-string class handling in PhpDumper (nicolas-g…
ecf54d5 
…rekas, sroze)

This PR was merged into the 3.4 branch.

Discussion
----------

[DI] Fix non-string class handling in PhpDumper

| Q             | A
| ------------- | ---
| Branch?       | 3.4
| Bug fix?      | yes
| New feature?  | no
| BC breaks?    | no
| Deprecations? | no
| Tests pass?   | yes
| Fixed tickets | #25353
| License       | MIT
| Doc PR        | -

Commits
-------

28f0086 Ensure that inlined services with parameterized class name can be dumped
730b156 [DI] Fix non-string class handling in PhpDumper
@wuestkamp wuestkamp mentioned this issue Apr 25, 2018
Merged
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@nicolas-grekas @sroze @stefandoorn
0