felix-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Raymond Auge <raymond.a...@liferay.com>
Subject Re: metatype extension
Date Sun, 08 Mar 2015 21:00:05 GMT
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 <balazs.zsoldos@everit.biz>
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 <raymond.auge@liferay.com>
> wrote:
>
> > On Wed, Mar 4, 2015 at 3:08 AM, Balázs Zsoldos <
> balazs.zsoldos@everit.biz>
> > 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 <raymond.auge@liferay.com
> >
> > > wrote:
> > >
> > > > On Tue, Mar 3, 2015 at 10:32 AM, Jan Willem Janssen <
> > > > janwillem.janssen@luminis.eu> wrote:
> > > >
> > > > > Hi Raymond,
> > > > >
> > > > > > On 03 Mar 2015, at 16:24, Raymond Auge <raymond.auge@liferay.com
> >
> > > > 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)

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message