> > 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) >
