For now I just changed the visibility of the Entry::$id property to protected, and now it works fine. Your suggestion should work too, but I think in this special case it's better to change the visibility instead of adding setters. A user shouldn't change directly a value of a property of an Entry instance. This is handled by the AclProvider. What do you think?
Thanks a lot for your comments and the useful info! 2011/4/4 Yader Hernandez <[email protected]> > Oh I see. > > There is in my opinion, a better way of handling this. > > Instead of accessing a private property which defeats the purpose of it > being private in the first place, a call to a setter method would work. > This would allow us to think more abstractly and less on implementation. > > But it looks like those were not put into place so maybe changing the scope > might work just as easily. > > Anyway, if the setters were in place, using ReflectionMethod::invoke() > would work for what you need. > > Check out the example that is already provided there: > http://us.php.net/manual/en/reflectionmethod.invoke.php > > > > On Mon, Apr 4, 2011 at 11:18 AM, Gustavo Adrian < > [email protected]> wrote: > >> It's a bug in PHP. As I said before... I'm having this problem when I try >> to update FieldEntry objects (Field ACEs). Lines 779, 780 and 781 of >> MutableAclProvider uses: >> >> $aceIdProperty = new \ReflectionProperty($ace, 'id'); >> $aceIdProperty->setAccessible(true); >> $aceIdProperty->setValue($ace, intval($aceId)); >> >> First line throws an exception saying "id" property doesn't exist. With >> your code, it's the same thing. It doesn't show any inherited private >> property. Read the second comment on the PHP bug. >> >> 2011/4/4 Yader Hernandez <[email protected]> >> >>> No need to change the visibility. You can flag what you need. >>> >>> class Foo { >>> public $foo = 1; >>> protected $bar = 2; >>> private $baz = 3; >>> } >>> $foo = new Foo(); >>> $reflect = new ReflectionClass($foo); >>> $props = $reflect->getProperties(ReflectionProperty::IS_PUBLIC | >>> ReflectionProperty::IS_PROTECTED | ReflectionProperty::IS_PRIVATE); >>> >>> foreach ($props as $prop) { >>> echo $prop->getName(); >>> } >>> >>> echo "\n"; >>> var_dump($props); >>> echo "\n"; >>> >>> >>> Output: >>> ------------ >>> >>> array(3) { >>> [0]=> >>> object(ReflectionProperty)#3 (2) { >>> ["name"]=> >>> string(3) "foo" >>> ["class"]=> >>> string(3) "Foo" >>> } >>> [1]=> >>> object(ReflectionProperty)#4 (2) { >>> ["name"]=> >>> string(3) "bar" >>> ["class"]=> >>> string(3) "Foo" >>> } >>> [2]=> >>> object(ReflectionProperty)#5 (2) { >>> ["name"]=> >>> string(3) "baz" >>> ["class"]=> >>> string(3) "Foo" >>> } >>> } >>> >>> >>> >>> >>> On Mon, Apr 4, 2011 at 9:26 AM, Gustavo Adrian < >>> [email protected]> wrote: >>> >>>> Hi, >>>> >>>> I've finally found the issue of this one. It seems to be a bug of PHP: >>>> >>>> >>>> http://stackoverflow.com/questions/1495600/reflectionclassgetproperty-for-a-private-property-in-an-inhertited-class >>>> >>>> http://bugs.php.net/bug.php?id=47808 >>>> >>>> >>>> I'm using Ubuntu with PHP 5.3.3. >>>> >>>> What should we do with this one? it's a very annoying bug while trying >>>> to update an ACL with Field ACEs. Changing the visibility of properties >>>> ("id" in this case) on the Entry class from private to protected fixes the >>>> issue. I don't know if there's another case like this one on other >>>> properties. >>>> >>>> >>>> 2011/3/30 Gustavo Adrian <[email protected]> >>>> >>>>> Hi all, >>>>> >>>>> I had random exceptions about serialization with the Entry class. I've >>>>> noticed all its properties are private. Also, FieldEntry extends from >>>>> Entry, >>>>> so when I want to do something like this to delete a FieldEntry: >>>>> >>>>> $classFieldACEs = $acl->getClassFieldACEs( $field ); >>>>> >>>>> // $classFieldACE is the ACE I want to delete >>>>> foreach ( $classFieldACEs as $index => $classFieldACE ) >>>>> { >>>>> if ( $ace->getId() === $classFieldACE->getId() ) >>>>> { >>>>> $acl->deleteClassACE( $index ); >>>>> >>>>> break; >>>>> } >>>>> } >>>>> >>>>> Here I get an "Property >>>>> Symfony\Component\Security\Acl\Domain\FieldEntry::$id does not exist" >>>>> exception. >>>>> >>>>> Should we change the visibility of these properties to protected? >>>>> >>>>> >>>>> >>>>> Thanks in advance! >>>>> >>>> >>>> -- >>>> If you want to report a vulnerability issue on symfony, please send it >>>> to security at symfony-project.com >>>> >>>> You received this message because you are subscribed to the Google >>>> Groups "symfony developers" group. >>>> To post to this group, send email to [email protected] >>>> To unsubscribe from this group, send email to >>>> [email protected] >>>> For more options, visit this group at >>>> http://groups.google.com/group/symfony-devs?hl=en >>>> >>> >>> -- >>> If you want to report a vulnerability issue on symfony, please send it to >>> security at symfony-project.com >>> >>> You received this message because you are subscribed to the Google >>> Groups "symfony developers" group. >>> To post to this group, send email to [email protected] >>> To unsubscribe from this group, send email to >>> [email protected] >>> For more options, visit this group at >>> http://groups.google.com/group/symfony-devs?hl=en >>> >> >> -- >> If you want to report a vulnerability issue on symfony, please send it to >> security at symfony-project.com >> >> You received this message because you are subscribed to the Google >> Groups "symfony developers" group. >> To post to this group, send email to [email protected] >> To unsubscribe from this group, send email to >> [email protected] >> For more options, visit this group at >> http://groups.google.com/group/symfony-devs?hl=en >> > > -- > If you want to report a vulnerability issue on symfony, please send it to > security at symfony-project.com > > You received this message because you are subscribed to the Google > Groups "symfony developers" group. > To post to this group, send email to [email protected] > To unsubscribe from this group, send email to > [email protected] > For more options, visit this group at > http://groups.google.com/group/symfony-devs?hl=en > -- If you want to report a vulnerability issue on symfony, please send it to security at symfony-project.com You received this message because you are subscribed to the Google Groups "symfony developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/symfony-devs?hl=en
