[EMAIL PROTECTED] wrote on 2008/05/30 03:45:12 PM: > [image removed] > > [osgi-dev] Declarative Services: ComponentFactory Question > > Felix Meschberger > > to: > > OSGi Developer Mail List > > 2008/05/30 03:59 PM > > Sent by: > > [EMAIL PROTECTED] > > Please respond to OSGi Developer Mail List <osgi-dev@mail.osgi.org> > > Hi all, > > Apache Sling is a web development framework implemented in OSGi bundles > which makes heavy use of Declarative Services. By default we use the > Apache Felix Declarative Services implementation. But lately I tried to > use the Equinox Declarative Services implementation and encountered the > following discrepancy with respect to Component Factories: > > > Equinox > ------- > If a component is declared as a component factory by way of the factory > attribute, the component _must_ be declared as a delayed component by > setting the immediate attribute to false.
This is not true (from a spec perspective). Factory components are not immediate by definition. > > This factually prevents using component factory components without > service elements because components without a service element _must_ set > the immediate attribute to true. Factory Components do not have to specify a service elements. See section 112.2.4: "If the component specifies a service, then the service is registered after the created component configuration is satis- fied with the component properties as service properties." This section also contains an example without a service element. No DS imlementation can require a factory component to have a service element. A factory component cannot be an immediate component since an instance of the component cannot be created until a call is made to the factory. From 112.2.2: "A component is an immediate component if it is not a factory compo- nent ..." I think the confusion may lay in the description of the immediate attribute in 112.4.3: "immediate - Controls whether component configurations must be immediately activated after becoming satisfied or whether activation should be delayed. The default value is false if the service element is specified and true otherwise. If this attribute is specified, its value must be true unless the service element is also specified." which does not take into account factory components. A better description would be: "immediate - Controls whether component configurations must be immediately activated after becoming satisfied or whether activation should be delayed. The default value is false if the factory attribute or if the service element is specified and true otherwise. If this attribute is specified, its value must be false if the factory attribute is also specified or must be true unless the service element is also specified." > > For Apache Sling, this is a problem, because one of our Component > Factory components in fact does _not_ have a service element and thus is > not usable with Equinox Declarative Services. > > > Apache Felix > ------------ > If a component is declared as a component factory by way of the factory > attribute, the component _must_ be declared as a delayed component by > setting the immediate attribute to true. > > This is consistent with the requirement of the immediate attribute with > respect to the service element: If the service element does _not_ exist, > the attribute _must_ be true, which is also enforced when having the > factory attribute set. If the service elements exist, the immediate > attribute may be true or false, hence the required value of true is > valid. > > > Knopflerfish > ------------ > > Knpflerfish Declarative Services does not seem to enforce a specific > value of the immediate attribute in conjunction with the factory > attribute. > > > My question is: Is there in fact a requirement to coordinate the > immediate attribute and the factory attribute ? I could not find any > concrete hints in the specification. > > My interest in this is two-fold: (1) I want to run my project with > Equinox Declarative Services and (2) I want the Apache Felix Declarative > Services implementation to be correct. > > Thanks for any thoughts on this. > > Regards > Felix > > _______________________________________________ > OSGi Developer Mail List > osgi-dev@mail.osgi.org > https://mail.osgi.org/mailman/listinfo/osgi-dev -- BJ Hargrave Senior Technical Staff Member, IBM OSGi Fellow and CTO of the OSGi Alliance [EMAIL PROTECTED] office: +1 386 848 1781 mobile: +1 386 848 3788
_______________________________________________ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
