*BJ:** * -------- Original Message -------- Subject: Re: [osgi-dev] custom properties for a DS / ComponentFactory? (was : 112.2.4 Factory Component: "The service properties of the Component Factory service must not include the component properties") From: BJ Hargrave <hargr...@us.ibm.com> To: OSGi Developer Mail List <osgi-dev@mail.osgi.org> Date: Sun 16 Sep 2012 08:03:36 AM CDT > First, you should put your detailed request in a bug at > https://www.osgi.org/bugzilla. This was we can capture all the > discussion and ideas in one place. got it; done: https://www.osgi.org/bugzilla/show_bug.cgi?id=151
> How is that any different than > @Component(factory = "factory."+SomeInterface.class.getName()) > ok, difference: your example is a compile error in eclipse : "The value for annotation attribute Component.name must be a constant expression" and mine compiles just fine :-) > You get your type safety in the string value of the factory property > by using the compiler to supply part of the string. (A class name is a > constant and a constant needs to be the same at compiler-time and > class-load-time. Otherwise it is not really a constant.) > academically speaking, you are right, however, https://www.osgi.org/bugzilla/show_bug.cgi?id=147 3.4 Support inheritance in the DS Annotations (Bug 2138) allows for a more relaxed approach, which would come handy in my case also. > > solution: I would put interfaces information into the custom properties > > ComponentFactory is a service and is type safe using normal service > registry practices as a service that implements the ComponentFactory > interface. > > There is no way in the service registry (today) for this factory, or > any other factory type service, to get type safety on the type > returned by the factory method (newInstance in the case of > ComponentFactory). This would be a rather major change to the service > registry to support this additional level of type safety since the > return type of the factory method would need to be parameterized in > some way for each service instance of the factory service type. This > would be a pretty big change to the service model. I am merely asking for a change only within / on top of the DS/SCR paradigm, where all kind of special semantics can be introduced on top of basic api w/o intruding onto depths > > 3) for flexible architecture > > * currently, there is no DS / osgi framework-provided "factory > manager" facility; > > True. Perhaps we would then want to extend to a factory manager > factory and then a factory manager factory manager? See > http://discuss.joelonsoftware.com/default.asp?joel.3.219431for a > humorous look at how this gets weird fast. yes, this is funny, but: > > I personally think that anything above a simple factory for components > is beyond the scope of DS and should be built on top of it with > another layer. for me it feels like there is a hole in current spec, so I re-worded my request, made it more abstract: https://www.osgi.org/bugzilla/show_bug.cgi?id=151 " declarative services component factories patterns guidelines and/or implementations" > > > bottom line: > > > I really don't want to confuse requirements and use case discussion > with implementation details. So I am going to avoid your code. ok! well, I can not say "I am going to avoid your specs" :-) > > Please open the bug as I suggested above. > > > * I am asking for a minor change that I think would make > ComponentFactory more flexible/usable; > > You listed 3 things above. Two of which are far from minor. The first > is asking for more factory properties which I still don't see the need > for. > > > * you are answering that every specific example I produced so far > > could be forced into existing bed of Procrustes; > > That is sort of the point of standards and conventions. You attempt to > map your problems onto them and use them where practical. If your > problem can not be practically addresses by that standard or > convention, then do something different. > > A standard should not change lightly. The gain must be worth the change. > > > how about if ComponentFactory is to expose underlying component > interfaces directly? > > Open another bug. But please discuss the issue in concrete > requirements and use cases including why you cannot do what you want > with the current spec. Also remember this has to fit into the existing > service model or we will have to make changes to the service model > which requires the net gain from the solution to be worth the work. > > ok, got it; all clear; thanks again for your time; Andrei -- > > *BJ Hargrave* > Senior Technical Staff Member, IBM > OSGi Fellow and CTO of the _OSGi Alliance_ <http://www.osgi.org/>_ > __hargr...@us.ibm.com_ <mailto:hargr...@us.ibm.com> > > 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
_______________________________________________ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
