Bug #37574

ReflectionData is not regenerated automatically

Added by Bastian Waidelich over 9 years ago. Updated about 9 years ago.

Status:
Resolved
Priority:
Won't have this time
Category:
Reflection
Start date:
2012-07-26
Due date:
% Done:

100%

Estimated time:
(Total: 0.00 h)
PHP Version:
5.3
Has patch:
No
Complexity:
nightmare

Description

If the signature of an action changes in a controller or I add a @FLOW3\Inject annotation I would expect the Controllers reflection data to be recreated in Development context. But that's not the case (even if the FLOW3 package and my custom package are not frozen).


Subtasks

Bug #39300: blocking ReflectionService: Call to a member function get() on a non-object Closed2012-07-26

Actions

Related issues

Related to TYPO3.Flow - Bug #37223: Packages can be frozen in Production ContextResolvedKarsten Dambekalns2012-05-16

Actions
Related to TYPO3.Flow - Task #37726: Packages should not be frozen by defaultResolvedKarsten Dambekalns2012-06-04

Actions
Related to TYPO3.Flow - Bug #37815: Object are not persistedClosedKarsten Dambekalns2012-06-07

Actions
#1

Updated by Robert Lemke over 9 years ago

  • Category set to Reflection
  • Priority changed from Should have to Must have
  • PHP Version set to 5.3
  • Complexity set to medium

This has some more severe consequences:

  • freshly clone a FLOW3 distribution
  • set file permissions and database settings
  • ./flow3 doctrine:migrate
  • ./flow3 kickstart:actioncontroller --generate-actions --generate-templates --generate-related Shop Book
  • create a new Book through the form
  • the message says that a new book was created but it's not persisted! No errors in log!
  • ./flow3 package:refreeze
  • now it works!

So, as a workaround - until this bug is fixed - make sure that all packages are unfrozen (./flow3 package:unfreeze all)

#2

Updated by Karsten Dambekalns over 9 years ago

Packages should not be frozen by default, that way you'd need to learn about them before you can fall into any traps.

#3

Updated by Bastian Waidelich over 9 years ago

Karsten Dambekalns wrote:

Packages should not be frozen by default

They are not, but the issue occurs even if the package is not frozen (see description above)

#4

Updated by Karsten Dambekalns over 9 years ago

  • Status changed from New to Accepted
  • Assignee set to Karsten Dambekalns
#5

Updated by Karsten Dambekalns over 9 years ago

Bastian Waidelich wrote:

Karsten Dambekalns wrote:

Packages should not be frozen by default

They are not, but the issue occurs even if the package is not frozen (see description above)

Yes. The note was more a braindump, see #37726 for the separate issue.

#6

Updated by Karsten Dambekalns over 9 years ago

Robert Lemke wrote:

  • the message says that a new book was created but it's not persisted! No errors in log!

With the current 1.1 codebase that works fine for me.

#7

Updated by Bastian Waidelich over 9 years ago

While playing around with this a bit further, I made following observation:
Adding a new property with @FLOW3\Inject annotation does work sometimes.
Sometimes it doesn't but then - after changing something else in the same class - it does work suddenly.
My theory is, that the ModificationTimeStrategy doesn't work correctly. Maybe it compares the modification times with the time after the proxy classes have been built last, not with the time before they have been built?
I didn't check this, just a theory ;)

#8

Updated by Bastian Waidelich over 9 years ago

Bastian Waidelich wrote:

Maybe it compares the modification times with the time after the
proxy classes have been built last, not with the time before they have been built?

It does not compare the modification times in fact. But the issue might be, that the modificationTimes are stored in the cache while the files are changed or something. If I wait long enough before and after I do one single change, it seems to work.

#9

Updated by Karsten Dambekalns over 9 years ago

No, looking at the logs the file is always detected as modified, just the effect of that varies. YMMV.

#10

Updated by Bastian Waidelich over 9 years ago

Karsten Dambekalns wrote:

No, looking at the logs the file is always detected as modified
just the effect of that varies. YMMV.

Mh, then it's probably some kind of race condition still.. I experience a related issue lately:
If I modify a controller and hit refresh too soon, I get following error:

Runtime Notice: Declaration of My\Package\Controller\Project\SomeController::initializeView() should be compatible with that of My\Package\Controller\Project\SomeController_Original::initializeView()

Somehow the site is not locked correctly or so!? (sorry for the wild guesses, but maybe it helps anyways)

#11

Updated by Karsten Dambekalns over 9 years ago

  • Complexity changed from medium to nightmare
#12

Updated by Karsten Dambekalns over 9 years ago

Ok, after adding some debugging instruments, a picture forms. The following is a log of what happens after a change to a controller. That change was the addition of FLOW3\Inject to the already existing property $objectManagerInstance.

The first run picks up the change to the file and triggers rebuilding the DI proxy:

12-06-26 17:33:05 17933 DEBUG FLOW3  runtime-typo3.flow3:errorhandling
12-06-26 17:33:05 17933 DEBUG FLOW3  runtime-typo3.flow3:cachemanagement
12-06-26 17:33:05 17933 DEBUG FLOW3  runtime-typo3.flow3:objectmanagement:proxyclasses

12-06-26 17:33:05 17934 DEBUG FLOW3  compiletime-typo3.flow3:errorhandling
12-06-26 17:33:05 17934 DEBUG FLOW3  compiletime-typo3.flow3:cachemanagement
12-06-26 17:33:05 17934 DEBUG FLOW3  compiletime-typo3.flow3:cachemanagement:forceflush
12-06-26 17:33:05 17934 DEBUG FLOW3  compiletime-typo3.flow3:objectmanagement:compiletime:create
12-06-26 17:33:05 17934 DEBUG FLOW3  compiletime-typo3.flow3:reflectionservice
12-06-26 17:33:05 17934 DEBUG FLOW3  compiletime-typo3.flow3:objectmanagement:compiletime:finalize
12-06-26 17:33:06 17934 DEBUG FLOW3  compiletime-typo3.flow3:systemfilemonitor
12-06-26 17:33:06 17934 INFO  FLOW3  File Monitor "FLOW3_ClassFiles" detected 1 changed files and 0 changed directories.
12-06-26 17:33:06 17934 INFO  FLOW3  Buidling DI proxy for "TYPO3\Welcome\Controller\StandardController".

12-06-26 17:33:06 17933 DEBUG FLOW3  runtime-typo3.flow3:classloader:cache
12-06-26 17:33:06 17933 DEBUG FLOW3  runtime-typo3.flow3:reflectionservice
12-06-26 17:33:06 17933 DEBUG FLOW3  runtime-typo3.flow3:objectmanagement:runtime
12-06-26 17:33:06 17933 DEBUG FLOW3  runtime-typo3.flow3:persistence
12-06-26 17:33:06 17933 DEBUG FLOW3  runtime-typo3.flow3:session
12-06-26 17:33:06 17933 DEBUG FLOW3  runtime-typo3.flow3:resources
12-06-26 17:33:06 17933 DEBUG FLOW3  runtime-typo3.flow3:i18n

At this point the rebuilt proxy does not include injector code for the $objectManagerInstance! This is because only during the second run the ReflectionService picks up the change and learns about the new annotation:

12-06-26 17:33:34 17971 DEBUG FLOW3  runtime-typo3.flow3:errorhandling
12-06-26 17:33:34 17971 DEBUG FLOW3  runtime-typo3.flow3:cachemanagement
12-06-26 17:33:34 17971 DEBUG FLOW3  runtime-typo3.flow3:objectmanagement:proxyclasses

12-06-26 17:33:34 17972 DEBUG FLOW3  compiletime-typo3.flow3:errorhandling
12-06-26 17:33:34 17972 DEBUG FLOW3  compiletime-typo3.flow3:cachemanagement
12-06-26 17:33:34 17972 DEBUG FLOW3  compiletime-typo3.flow3:cachemanagement:forceflush
12-06-26 17:33:34 17972 DEBUG FLOW3  compiletime-typo3.flow3:objectmanagement:compiletime:create
12-06-26 17:33:34 17972 DEBUG FLOW3  compiletime-typo3.flow3:reflectionservice
12-06-26 17:33:34 17972 DEBUG FLOW3  compiletime-typo3.flow3:objectmanagement:compiletime:finalize
12-06-26 17:33:34 17972 DEBUG FLOW3  Forget class TYPO3\Welcome\Controller\StandardController
12-06-26 17:33:34 17972 DEBUG FLOW3  Reflected class names did not match class names to reflect
12-06-26 17:33:34 17972 DEBUG FLOW3  Reflecting class TYPO3\Welcome\Controller\StandardController
12-06-26 17:33:34 17972 INFO  FLOW3  Reflected 1 emerged classes.
12-06-26 17:33:35 17972 DEBUG FLOW3  compiletime-typo3.flow3:systemfilemonitor
12-06-26 17:33:35 17972 DEBUG FLOW3  Found 1 classes whose reflection data was not cached previously.

12-06-26 17:33:35 17971 DEBUG FLOW3  runtime-typo3.flow3:classloader:cache
12-06-26 17:33:35 17971 DEBUG FLOW3  runtime-typo3.flow3:reflectionservice
12-06-26 17:33:35 17971 DEBUG FLOW3  runtime-typo3.flow3:objectmanagement:runtime
12-06-26 17:33:35 17971 DEBUG FLOW3  runtime-typo3.flow3:persistence
12-06-26 17:33:35 17971 DEBUG FLOW3  runtime-typo3.flow3:session
12-06-26 17:33:35 17971 DEBUG FLOW3  runtime-typo3.flow3:resources
12-06-26 17:33:35 17971 DEBUG FLOW3  runtime-typo3.flow3:i18n

At this point the proxy would be built correctly, but the system considers it up-to-date already.

If now something else is changed in that file, the proxy will be rebuilt with the new reflection data and will be correct. Depending on the nature of that second change, the proxy will still be out of date though…

#13

Updated by Karsten Dambekalns over 9 years ago

  • Target version changed from 1.1 RC1 to 1.1
#14

Updated by Gerrit Code Review about 9 years ago

  • Status changed from Accepted to Under Review

Patch set 1 for branch master has been pushed to the review server.
It is available at http://review.typo3.org/12575

#15

Updated by Gerrit Code Review about 9 years ago

Patch set 2 for branch master has been pushed to the review server.
It is available at http://review.typo3.org/12575

#16

Updated by Karsten Dambekalns about 9 years ago

  • Status changed from Under Review to Resolved
  • % Done changed from 0 to 100
#17

Updated by Gerrit Code Review about 9 years ago

  • Status changed from Resolved to Under Review

Patch set 1 for branch FLOW3-1.1 has been pushed to the review server.
It is available at http://review.typo3.org/12823

#18

Updated by Karsten Dambekalns about 9 years ago

  • Status changed from Under Review to Resolved
  • Target version changed from 1.1 to 1.1 RC2

Also available in: Atom PDF