Starting with 2.2 Doctrine now generates proxies in a way that generically allows to get the class name. See the code:
https://github.com/doctrine/common/blob/master/lib/Doctrine/Common/Util/ClassUtils.php This method of generating proxy names is very generic and allows to re-use the naming across different libraries. The way to go would be if Symfony copied this class (yes, not-reuse). And start using this instead of get_class(). Maybe we should prepare some kind of common document on how proxy name generation should work. On Sat, Oct 8, 2011 at 2:41 PM, Johannes <schmitt....@gmail.com> wrote: > 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 > -- 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
