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.
> re: "demonstrate why more factory properties are necessary. " > > current spec is not "dynamic" enough: > > 1) for development/refactoring > * the @Component(factory = "factory") annotation takes only string > * this string has to be a compile-time constant in eclipse ide > * so you can not use construct like this @Component(factory = > SomeInterface.class) > * end result is that you must manually maintain parallel name space > for your factories > > solution: I would put bind filter information into a class-load-time constant > @Property(name = "c! > ustom-valu > e") > static final String VALUE = SomeInterface.class.getName(); > How is that any different than @Component(factory = "factory."+SomeInterface.class.getName()) ? 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.) > > 2) for flexible architecture > * ComponentFactory is not type safe, > * ComponentFactory does not carry underlying Component interfaces > information anywhere > * the work-around would be to go to low level api or reflection or etc. - why? > > 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. > > 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.219431 for a humorous look at how this gets weird fast. 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. > * in other words, you must somehow collect all the instances of > ComponentFactory into some third "factory manager" component > * the "factory manager" could get the ComponentFactory via bind like this: > @Reference( // > cardinality = ReferenceCardinality.MULTIPLE, // > policy = ReferencePolicy.DYNAMIC // > ) > protected void bind(final ComponentFactory s, final Map<String, Object< > /span>> props) { > * now "factory manager" must receive all appropriate factories injections, > * and should expose type-safe create(...) proxy calls to the > underlying ComponentFactory . newInstance(java.util.Dictionary properties) > > solution: I would use bind props as primary bind filter, not > "target=(...)" ldap filter; no need to dance around what you can > encode into "component.factory" > > * if I want to have different "factory managers" to produce > different overlapping sub-sets of ComponentFactory instances > then "component.factory" + "target=(...)" approach becomes unworkable > > 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. > please take a look on my factory project: > https://github.com/carrot-garden/carrot-osgi/tree/master/carrot- > osgi-scr-factory-ds > > required api > https://github.com/carrot-garden/carrot-osgi/tree/master/carrot- > osgi-scr-factory-ds/src/main/java/com/carrotgarden/osgi/factory/api > > implementation > https://github.com/carrot-garden/carrot-osgi/tree/master/carrot- > osgi-scr-factory-ds/src/main/java/com/carrotgarden/osgi/factory/impl > > test case > https://github.com/carrot-garden/carrot-osgi/tree/master/carrot- > osgi-scr-factory-ds/src/main/java/com/carrotgarden/osgi/factory/test > > unit test > https://github.com/carrot-garden/carrot-osgi/blob/master/carrot- > osgi-scr-factory-ds/src/test/java/com/carrotgarden/osgi/factory/ > TestFactory.java > > it basically shows 15 classes too many than should be there to > accomplish simple task: "type-safe DS ComponentFactory" > > thank you for your attention to this; > Please open the bug as I suggested above. > the basic difference between my questions and your answers is this > * 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. > > may be I should start asking for more! :-) > 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. > > cheers, > > Andrei. -- BJ Hargrave Senior Technical Staff Member, IBM OSGi Fellow and CTO of the OSGi Alliance 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
