The way how you (ab)use this feature makes me think that we need to remove the ability to configure it via yml/xml altogether. You really shouldn't use it to overcome API restrictions which are probably there for good reasons.
On Sun, Jun 26, 2011 at 6:19 PM, Christophe COEVOET <[email protected]> wrote: > Le 25/06/2011 13:41, Johannes Heinen a écrit : > >> Hi all, >> >> i recently tried to use property injection when defining services in >> one of my bundles (by using XML service configuration): >> >> <service id="autowiring.annotation_**reader" >> class="%autowiring.annotation_**reader.class%" public="false"> >> <property name="parser" type="service" >> id="autowiring.doc_parser" /> >> </service> >> >> This works fine so far. The service above is used as an argument to >> the service below: >> >> <service id="autowiring.annotation_**cached_reader" >> class="%autowiring.annotation_**cached_reader.class%" public="false"> >> <argument type="service" >> id="autowiring.annotation_**reader" /> >> ... >> </service> >> >> This works fine, too - the DIC is properly compiled down to PHP code >> (appDevDebugProjectContainer.**php) which works at all circumstances and >> environments. >> >> BUT - if i try to use the app/console container:debug command, it >> seems that the appDevDebugProjectContainer.**php is created AND >> additionalliy, the underlying appDevDebugProjectContainer.**xml is >> validated. And this validation fails because the above service >> definition is compiled down to the following xml chunk: >> >> <service id="autowiring.annotation_**cached_reader" class="Doctrine >> \Common\Annotations\**CachedReader" public="false"> >> <argument type="service"> >> <service class="Doctrine\Common\**Annotations >> \AnnotationReader" public="false"> >> <property name="parser" type="service"> >> <service class="Doctrine\Common\**Annotations >> \DocParser" public="false"> >> .... >> >> As you can see, the<property> element gains a<service> child >> element. This element is not allowed in the services-1.0.xsd schema >> file. >> >> Adding the service element to the schema, e.g. this way: >> >> <xsd:complexType name="property" mixed="true"> >> <xsd:choice minOccurs="0" maxOccurs="1"> >> <xsd:element name="service" type="service" /> >> </xsd:choice> >> <xsd:attribute name="type" type="argument_type" /> >> <xsd:attribute name="id" type="xsd:string" /> >> <xsd:attribute name="name" type="xsd:string" /> >> <xsd:attribute name="on-invalid" type="xsd:string" /> >> <xsd:attribute name="strict" type="boolean" /> >> </xsd:complexType> >> >> Simply solves the problem. Additionally, with this modification it is >> possible to inject anonymous services into properties in your bundle´s >> configuration files (this is forbidden due to the same schema >> validation rules). >> >> Is this behavour simply a bug in schema (from a pure functional point >> of view, property injection works fine at any circumstances) or a >> "feature" to prevent developers like me from defining bad-designed >> service definitions ;)) >> >> Thank you! >> >> This seems like a bug in the schema which has probably be forgotten when > adding this feature. You should probably do a pull request updating it. > > -- > Christophe | Stof > > -- > 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 > symfony-devs+unsubscribe@**googlegroups.com<symfony-devs%[email protected]> > For more options, visit this group at > http://groups.google.com/**group/symfony-devs?hl=en<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
