I've created an issue and submitted a patch for review here https://issues.apache.org/jira/browse/FELIX-4826
On Wed, Mar 4, 2015 at 3:24 PM, Balázs Zsoldos <[email protected]> wrote: > > > > A) It's not that I like XML, it's that I like the simplicity of our > > developers using the BND metatype (and upcoming OSGi metatype) > annotations > > with java interfaces. > > > If I understood right at OSGiCon, XML was used for Declarative Services as > a workaround for an Eclispe related issue, not as a feature. I guess it is > the same with Metatype XMLs. Probably future solutions should be designed > in the way that MetatypeProvider services are registered based on > annotations and XML availability should be there only for compatibility. > > assuming that the metatype > > implementation will not do any wrapping/proxying of the output of > > MetaTypeProvider making your information no longer visible. Isn't there > > danger of this? > > > > It depends. We managed to get rid of all of the technologies that used > proxies, interceptors, runtime class inheritance, weaving and other tricks > (Blueprint, JPA, etc.) and since that we got rid of many frustrating > issues. > > I can imagine that a technology can help with such tricks (although I have > not met one, especially since Java 8 with functional interfaces and lambda > expressions arrived). In that case the generated proxy classes should > implement all interfaces the original object implemented. > > In short: The question about the danger would not even be asked if > technologies did not want to use dangerous tricks. > > On Wed, Mar 4, 2015 at 4:04 PM, Raymond Auge <[email protected]> > wrote: > > > On Wed, Mar 4, 2015 at 3:08 AM, Balázs Zsoldos < > [email protected]> > > wrote: > > > > > Hi Raymond, > > > > > > I had similar requirements before and we came up with the following > > > solution: > > > > > > - I did not care about the XML stuff at all as I think offering > > > MetatypeProvider service is a much better approach than generating XML > > > - my classes that implement ObjectClassDefinition and > > AttributeDefinition, > > > implement other interface(s) as well that contains more information in > a > > > typesafe way > > > > > > By doing this, the one who processes Metatype can decide with a simple > > > *instanceof* if the extra information can be used. E.g.: > > > > > > ObjectClassDefinition od = > > metatypeProvider.getObjectClassDefinition(...); > > > if (od instanceof MyExtraInfo) { > > > ... > > > } > > > > > > My implementation class for my Component Model technology is at > > > > > > > > > https://github.com/everit-org/ecm-component/blob/master/core/src/main/java/org/everit/osgi/ecm/component/ri/internal/metatype/AttributeDefinitionImpl.java > > > As you can see, the class also implements AttributeMetadataHolder > > > interface. That can contain a > > > > > > - StringAttributeMetadata that has properties like *multiline* > > > - ReferenceAttributeMetadata that has information to be able to show a > > > popup selector window for service references on our > > > webconsole-configuration plugin > > > > > > With this technique Metatype spec. does not have to be extended at all. > > > Everything is typesafe. There is no difference between knowing a hint > > (that > > > is a String) or an extra interface (that can have typesafe information) > > > when we write plugins to tools the programmer creating configuration. > > > > > > Regards, > > > > > > *Balázs **Zsoldos* > > > > > > > Interesting! I did something like this, except within felix metatype so > > that it worked for both XML and MetaTypeProviders. > > > > Caveats: > > > > A) It's not that I like XML, it's that I like the simplicity of our > > developers using the BND metatype (and upcoming OSGi metatype) > annotations > > with java interfaces. > > > > B) I'm noting with your solution of adding interfaces to OCD and AD > > returned from your MetaTypeProvider that it's assuming that the metatype > > implementation will not do any wrapping/proxying of the output of > > MetaTypeProvider making your information no longer visible. Isn't there > > danger of this? > > > > I do like the idea though! I will strongly consider it. > > > > - Ray > > > > > > > > > > > > > > > On Tue, Mar 3, 2015 at 4:36 PM, Raymond Auge <[email protected] > > > > > wrote: > > > > > > > On Tue, Mar 3, 2015 at 10:32 AM, Jan Willem Janssen < > > > > [email protected]> wrote: > > > > > > > > > Hi Raymond, > > > > > > > > > > > On 03 Mar 2015, at 16:24, Raymond Auge <[email protected] > > > > > > wrote: > > > > > > […] > > > > > > However, a metatype implementation change would be required but > > ONLY > > > > for > > > > > > access to said new "hints" information. This would require: > > > > > > > > > > > > 1) reading the extra schema info while parsing the metatype xml > > > > > > 2) providing API access to the information > > > > > > > > > > > > Implementing > > > > > > 1) is simple, just need to enhance the parser with the fields we > > > decide > > > > > > 2) I was thinking of something like the following: > > > > > > […] > > > > > > > > > > IIRC, the MetaType spec already allows for optional attributes to > be > > > > > defined > > > > > on ADs, Attributes, OCDs and Objects. I believe that this would > > already > > > > > cover > > > > > most of these requirements, not? > > > > > > > > > > > > > Sure! However, the need to read the metatype again is painful when > > > metatype > > > > is already reading it. Furthermore, this doesn't work for > > > > MetatypeProviders. > > > > > > > > - Ray > > > > > > > > > > > > > > > > > > -- > > > > > Met vriendelijke groeten | Kind regards > > > > > > > > > > Jan Willem Janssen | Software Architect > > > > > +31 631 765 814 > > > > > > > > > > My world is revolving around INAETICS and Amdatu > > > > > > > > > > Luminis Technologies B.V. > > > > > Churchillplein 1 > > > > > 7314 BZ Apeldoorn > > > > > +31 88 586 46 00 > > > > > > > > > > http://www.luminis-technologies.com > > > > > http://www.luminis.eu > > > > > > > > > > KvK (CoC) 09 16 28 93 > > > > > BTW (VAT) NL8169.78.566.B.01 > > > > > > > > > > > > > > > > > > > > > > -- > > > > *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile> > > > > (@rotty3000) > > > > Senior Software Architect *Liferay, Inc.* <http://www.liferay.com> > > > > (@Liferay) > > > > Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org> > > > > (@OSGiAlliance) > > > > > > > > > > > > > > > -- > > *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile> > > (@rotty3000) > > Senior Software Architect *Liferay, Inc.* <http://www.liferay.com> > > (@Liferay) > > Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org> > > (@OSGiAlliance) > > > -- *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile> (@rotty3000) Senior Software Architect *Liferay, Inc.* <http://www.liferay.com> (@Liferay) Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org> (@OSGiAlliance)
