I merged the code for annotation registries now and released Doctrine 2.1 rc3. http://www.doctrine-project.org/blog/doctrine-2-1-rc3
I will try to make a PR to Symfony standard repo to adjust for this change today. The question is if we want to configure the annotation library inside the framework bundle or let developers do this in autoload.php The minimal config for autoload.php would only require two loc so its very simple. On the other hand, each bundle knows its own annotation needs and could register the relevant information in Bundle::boot() Thoughts? On Sat, 2 Jul 2011 07:32:28 -0700 Kris Wallsmith <[email protected]> wrote: > The ::registerLoader() method that you have there is what I was suggesting > earlier. I’m not sure what caching issues you were referring to. > > Thanks! > k > > On Saturday, July 2, 2011 at 1:31 AM, Benjamin Eberlei wrote: > > > Johannes, and me talked through the requirements and problems and the best > > solution we found really only is replacing the PHP autoloading with its own > > global autoloading mechanism inside the Annotation library. > > > > New gist can be found here: > > > > https://gist.github.com/1059486 > > > > The patch can be found here: > > > > https://github.com/doctrine/common/pull/40 > > > > Please discuss this with us and I merge this during the day if we find no > > more issues, then release another Doctrine 2.1 RC and move the final > > release date of Doctrine to Monday. > > > > On Sat, 2 Jul 2011 09:13:24 +0200 > > Benjamin Eberlei <[email protected] (mailto:[email protected])> wrote: > > > > > The problem with replicating the spl_autoload* fns as > > > doctrine_annotation_autoload* is the global state. > > > > > > Since parsing annotations is always sort of cached you can easily run > > > into problems here or need to throw an exception of the sort "changing > > > autoloading is prevented, a reader has already accessed this data, we > > > have to prevent caching issues". > > > > > > greetings, > > > Benjamin > > > > > > On Fri, 1 Jul 2011 17:43:47 -0700 > > > Kris Wallsmith <[email protected] > > > (mailto:[email protected])> wrote: > > > > > > > This binds the reader to PSR-0, right? I'm not sure you want to do > > > > that. Why not just expose a method to register autoload callables, > > > > similar to the spl_ function? Then you can register a special loader > > > > or just register spl_autoload_call. > > > > > > > > k > > > > > > > > On Jul 1, 2011, at 3:16 PM, Benjamin Eberlei <[email protected] > > > > (mailto:[email protected])> wrote: > > > > > > > > > Hello, > > > > > > > > > > implementing an autoloading mechanism just for annotations is really > > > > > simple: > > > > > > > > > > https://github.com/doctrine/common/compare/master...Autoloading > > > > > > > > > > The problem is how we design extension points. > > > > > > > > > > Just stuffing the universal loader namespaces map into the annotation > > > > > reader as shown here looks convenient, but it isnt. > > > > > See code: https://gist.github.com/1059486 > > > > > > > > > > 1. The universal loader is not necessarily a production loader, so > > > > > using this data is not a good idea. > > > > > 2. The loader looses scope very fast, there is no real way to get it > > > > > back. > > > > > > > > > > This sort of leaves us with registering annotation namespaces > > > > > explicitly at some other location, which is rather unconvenient and > > > > > probably complex to do. > > > > > > > > > > Other options would either be: > > > > > > > > > > 1. Go back to a 2.0.x approach, every component uses its own reader > > > > > and no validation is performed. > > > > > 2. Requiring all annotation classes to be require_once'd before using > > > > > them as annotations. > > > > > 3. Adding a global static dependency that knows about all the > > > > > annotations. > > > > > > > > > > All these are not really desirable. > > > > > > > > > > At that point it might even be better to just keep the current way > > > > > and just life with the downsides, i.e. requiring silent autoloaders. > > > > > > > > > > On Fri, 01 Jul 2011 10:34:14 +0200 > > > > > Benjamin Eberlei <[email protected] (mailto:[email protected])> > > > > > wrote: > > > > > > > > > > > Yes, registering all namespaces. This is how it works at the moment > > > > > > anyways, since the annotation reader with autoload = true is backed > > > > > > up > > > > > > by php autoloading. > > > > > > > > > > > > The benefits are that its easy to migrate to and it is essentially a > > > > > > no-additional-configuration solution, allowing users to add new > > > > > > validation constraints for example without having to bother about > > > > > > autoloading the annotations at all. > > > > > > > > > > > > On Fri, 01 Jul 2011 10:28:38 +0200, Christophe COEVOET wrote: > > > > > > > Le 01/07/2011 10:23, Benjamin Eberlei a écrit : > > > > > > > > On Fri, 01 Jul 2011 10:17:17 +0200, Christophe COEVOET wrote: > > > > > > > > > Le 01/07/2011 10:12, Benjamin Eberlei a écrit : > > > > > > > > > > Yes, I know this is a problem, but even in the case > > > > > > > > > > currently all > > > > > > > > > > the annotation classes have to be made available (through an > > > > > > > > > > autoloader). Registering all possible annotations either > > > > > > > > > > with their > > > > > > > > > > class name in a hashmap or already calling require_once on > > > > > > > > > > them is > > > > > > > > > > just another mechanism that is not as convenient but allows > > > > > > > > > > more > > > > > > > > > > robust docblock parsing. Also the "hack" to doctrine > > > > > > > > > > annotations > > > > > > > > > > loading is only necessary, because these classes are > > > > > > > > > > organized in a > > > > > > > > > > non psr-0 structure. So these classes are pre-loaded in a > > > > > > > > > > hackish > > > > > > > > > > way, because there is no other mechanism for the autoload = > > > > > > > > > > true > > > > > > > > > > case. > > > > > > > > > > > > > > > > > > > > We already set annotations: true for validators and > > > > > > > > > > registering > > > > > > > > > > the ExtraBundles is also a statement "pro annotation", so > > > > > > > > > > we do have > > > > > > > > > > simple ways in Symfony2 to collect the class-names of all > > > > > > > > > > possible > > > > > > > > > > annotations. I propose to change the following on > > > > > > > > > > AnnotationReader: > > > > > > > > > > > > > > > > > > > > 1. Add a method to register annotation classes: > > > > > > > > > > $reader->registerAnnotation("Symfony\Bridge\Doctrine\Validator\UniqueEntity"); > > > > > > > > > > and $reader->registerAnnotations(array(..)); > > > > > > > > > > 2. Add a method to register files that contain annotations: > > > > > > > > > > $reader->registerAnnotationFile(".."), directly loading > > > > > > > > > > them via > > > > > > > > > > require_once; > > > > > > > > > > 3. Add a method to register annotation namespaces: > > > > > > > > > > $reader->registerAnnotationNamespace("Symfony\Component\Validator\Constraint", > > > > > > > > > > $dir). This is used to create a silently failing PSR-0 > > > > > > > > > > "autoloader" > > > > > > > > > > for this path + directories. It can be automatically > > > > > > > > > > populated from > > > > > > > > > > data in the UniversalClassLoader. > > > > > > > > > > 4. Change the class_exists check to never use autoload = > > > > > > > > > > true. If > > > > > > > > > > a class is part of a registered annotation namespace (only > > > > > > > > > > directly > > > > > > > > > > in the exact namespace, no subnamspacing), try load the > > > > > > > > > > file based > > > > > > > > > > on a silent PSR-0 autoload for it using an autoloader impl. > > > > > > > > > > contained in the AnnotationReader (not the php autoloading > > > > > > > > > > mechanism), before triggering the class_exists($name, false) > > > > > > > > > > > > > > > > > > > > This way for symfony only the UniversalClassLoader data has > > > > > > > > > > to be > > > > > > > > > > used to populate the registered annotation namespaces. > > > > > > > > > This seems good. And in Symfony, we can implement it by > > > > > > > > > adding a > > > > > > > > > tag > > > > > > > > > on services in which the annotation reader is injected giving > > > > > > > > > the > > > > > > > > > needed data to register the annotations in the > > > > > > > > > annotation_reader > > > > > > > > > service. This will require a bit work for people writing an > > > > > > > > > annotation > > > > > > > > > driver but they still have to work. > > > > > > > > > This should probably be done before the Symfony2 release to > > > > > > > > > avoid > > > > > > > > > BC > > > > > > > > > issues after that. > > > > > > > > > > > > > > > > A tag is not necessary, the data from the universal class loader > > > > > > > > would suffice to register the new autoloader inside the > > > > > > > > annotation > > > > > > > > reader. Doctrine Bundle (and third party ones in need of special > > > > > > > > integration) could use a compiler pass to add the > > > > > > > > $reader->registerAnnotationFile() call. This would cover 99,9% > > > > > > > > of all > > > > > > > > use-cases. > > > > > > > But registering which namespaces ? You would register all > > > > > > > namespaces > > > > > > > of the autoloader instead of just the one containing annotations ? > > > > > > > > > > > > > > -- > > > > > > > Christophe | Stof > > > > > > > > > > > > -- > > > > > > If you want to report a vulnerability issue on symfony, please send > > > > > > it to security at symfony-project.com (http://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] > > > > > > (mailto:[email protected]) > > > > > > To unsubscribe from this group, send email to > > > > > > [email protected] > > > > > > (mailto:[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 (http://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] > > > > > (mailto:[email protected]) > > > > > To unsubscribe from this group, send email to > > > > > [email protected] > > > > > (mailto:[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 (http://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] > > > > (mailto:[email protected]) > > > > To unsubscribe from this group, send email to > > > > [email protected] > > > > (mailto:[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 (http://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] > > > (mailto:[email protected]) > > > To unsubscribe from this group, send email to > > > [email protected] > > > (mailto:[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 (http://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] > > (mailto:[email protected]) > > To unsubscribe from this group, send email to > > [email protected] > > (mailto:[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
