> 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 :-)
Easy to fix
@ComponentFactory(factory = "factory." + MyComponent.className)
public class MyComponent {
static final String className = MyComponent.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.)
> 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.
Yes, but that has issues too. It requires the component xml to be created
at assembly time (when the bundle is packaged). It is can't be done at
runtime since all the annotations do is provide information to the
assembly tool to generate the xml component description. So the type
safety is still known in advance of runtime. So I don't think it has the
flexibility you think.
> > 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
ComponentFactoryinterface.
>
> 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
OK, but I don't see that in any of this discussion. Can you elaborate in
the bug?
> > 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.
> 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" :-)
Of course not since it is the point of the discussion: changing the spec.
--
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
