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 Wed, 04 Mar 2015 15:04:20 GMT
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)

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