Hey Lukas, I can't really add more to this PR than I already did. In my opinion, we need a different solution.
While the proposed patch partially solves the problem, it also adds another service, could be implemented using the existing interfaces, and most importantly, it is more a workaround than a solution. Furthermore, It means that we need to review all usages of get_class in all components, as well as some bundles (mainly SensioFrameworkExtraBundle, JMSSecurityExtraBundle) and proxy all calls to get_class/ReflectionClass::getName() through a dedicated service whenever a proxy object can reasonably be expected. That includes proxies for controllers (because of AOP, or lazy-loading), proxies for services (because of AOP, or lazy-loading), proxies for entities (lazy-loading), proxies for documents (lazy-loading), and possibly more... So, since adding new services with no end and no real value doesn't seem like a good solution to me, I have reviewed Spring Framework's solution to this as they use similar technologies (Hibernate ORM generates proxy classes, AOP alliance uses proxies). They solve this problem by standardizing the proxy class name separator making it easy for tools to determine whether the class is a proxy or not (see org.springframework.util.ClassUtils.getUserClass for reference). This is similar to how we have a standard for auto-loading, and can transform a fully qualified class name to a file path; just that we instead can transform a fully qualified class name to the original user's class name when we need it. I have implemented this strategy in several of my bundles (JMSSecurityExtraBundle, JMSAopBundle and JMSDiExtraBundle) a few weeks ago, and so far, this has been working very well. So, my proposition is to agree on a common proxy class separator (currently I'm using __CG__), and possibly also propose it as a standard for the standards group (if that still exists?). regards, Johannes p.s. I'm aware that the PR contains another enhancement. While I'm not sure this enhancement is worthwhile, we should discuss it separately from the original problem that the PR tries to solve. On Sat, Oct 8, 2011 at 10:06 AM, Lukas Kahwe Smith <m...@pooteeweet.org>wrote: > Ahoi Johannes, > > It would be really great to finally resolve this topic: > https://github.com/symfony/symfony/pull/2056 > > People are kind of waiting for your blessing for some approach to get this > fixed. > > regards, > Lukas Kahwe Smith > m...@pooteeweet.org > > > > -- 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 symfony-devs@googlegroups.com To unsubscribe from this group, send email to symfony-devs+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/symfony-devs?hl=en
