You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@felix.apache.org by Raymond Auge <ra...@liferay.com> on 2015/03/03 16:24:03 UTC
metatype extension
Hello everyone,
I've come to realize that while metatype is a brilliant spec, it has a
couple of shortcomings.
1) when the number of OCDs is large it becomes very difficult to organize
them into a UI logically. This is due to the lack of any classification
mechanism which could help in filtering.
2) there is no way to produce a foreign-key like field on which you could
filter for an exact instance. This field would be readOnly after creation
of a configuration. With such a foreign-key field one could easily lookup
specific instances produced from a factory.
3) no UI can accurately know how a field should be presented in the UI.
This is particularly true for string fields. There are many ways to present
a text field in the UI and currently it's impossible to even guess and so
everything is represented in a single way.
I propose adding a "hints" namespace (which would be a felix schema) in
which we could extend the metatype XML providing "hints" particularly to UI
implementations of how a specific OCD should be rendered.
These "hints" would be just that, they would not be enforced by the
metatype or by config admin at all. Simply they would guide the UI on the
presentation alone. Therefore no changes would be required in the
underlying logic of either implementations.
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:
org.osgi.service.metatype.ObjectClassDefinition ocd = ...
org.apache.felix.metatype.ObjectClassDefinitionExt ocdExt =
(org.apache.felix.metatype.ObjectClassDefinitionExt)ocd;
org.apache.felix.metatype.OCDHints hints = ecdExt.getHints();
AND
org.osgi.service.metatype.AttributeDefinition ad = ...
org.apache.felix.metatype.AttributeDefinitionExt adExt = (
org.apache.felix.metatype.AttributeDefinitionExt)ad;
org.apache.felix.metatype.ADHints hints = adExt.getHints();
The hints objects would contain the UI hints we specify.
--
*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)
Re: metatype extension
Posted by Raymond Auge <ra...@liferay.com>.
On Wed, Mar 4, 2015 at 3:37 AM, Jan Willem Janssen <
janwillem.janssen@luminis.eu> wrote:
>
> > On 03 Mar 2015, at 16:36, Raymond Auge <ra...@liferay.com> wrote:
> >
> >>
> >> 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.
>
> Not sure we are one the same line here: the current Felix MetaType
> implementation
> already provides access to all unknown attributes it reads from a MetaType
> XML
> Resource, see [1] and [2].
You are certainly right here. I found this out finally.
> This also can be used to create them programmatically
> for use in your MetaTypeProvider. As I see it, it should solve your 1st
> and 3rd
> requirement...
> 1.
> http://svn.apache.org/viewvc/felix/trunk/metatype/src/main/java/org/apache/felix/metatype/OptionalAttributes.java?revision=1399637
> 2.
> http://svn.apache.org/viewvc/felix/trunk/metatype/src/main/java/org/apache/felix/metatype/AD.java?revision=1653581
True!
However there is no way to access the information from the MetaTypeService
except through deep reflection as the implementations of OCD and AD
returned from felix don't give access to the OptionalAttributes even
through any of the interfaces implemented by the impls.
So while you could sure import the OptionalAttributes class and add the
data programmatically to your OCDs/ADs there's no "standard" (in terms of
felix metatype, not in terms of the spec) way of getting this back via the
service.
So, I propose an interface defined in felix metatype something like:
public interface OptionalAttributesProvider {
public OptionalAttributes getOptionalAttributes();
}
which felix would apply to the OCD/AD impls it provides from XML.
AND implementers of MetaTypeProvider can use the same interface on their
OCD/AD to pass along the same programmatically.
And considering the implication of the felix metatype impl ever wrapping
MetaTypeProvider output in some sort of proxy, since the interface is in
the felix project, it could just be assured to apply the interface on
proxies if it ever decided to create any.
Thoughts?
>
> --
> 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)
Re: metatype extension
Posted by Jan Willem Janssen <ja...@luminis.eu>.
> On 03 Mar 2015, at 16:36, Raymond Auge <ra...@liferay.com> wrote:
>
>>
>> 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.
Not sure we are one the same line here: the current Felix MetaType implementation
already provides access to all unknown attributes it reads from a MetaType XML
Resource, see [1] and [2]. This also can be used to create them programmatically
for use in your MetaTypeProvider. As I see it, it should solve your 1st and 3rd
requirement...
1. http://svn.apache.org/viewvc/felix/trunk/metatype/src/main/java/org/apache/felix/metatype/OptionalAttributes.java?revision=1399637
2. http://svn.apache.org/viewvc/felix/trunk/metatype/src/main/java/org/apache/felix/metatype/AD.java?revision=1653581
--
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
Re: metatype extension
Posted by Raymond Auge <ra...@liferay.com>.
On Tue, Mar 3, 2015 at 6:25 PM, David Jencks <david_jencks@yahoo.com.invalid
> wrote:
> I haven't looked in detail at what you are proposing.
>
> The eclipse metatype impl supports pretty much arbitrary extra attributes
> in extension namespaces. I'd start by implementing something like that in
> the felix metatype impl. It won't help much with metatype providers unless
> they happen to generate felix or equinox specific goo. I don't think
> there's any plausible way around this yet.
>
I'm pretty ok with having to use felix specific goo in any metatype
providers we might implement, if we chose to make metatype providers, that
is.
Therefore I was thinking of just a very simple runtime annotation one would
place on the OCDs and ADs returned from a metatype provider.
public @interface Attributes {
String[] attributes() default {};
}
where the same scheme as DS' @Component property (minus the types) is used.
These would get siphoned into the existing OptionalAttributes object.
I have an untested prototype with all these changes in place already just
to see what it would look like.
>
> I'm pushing for an extension annotation processor plugin-plugin thingy for
> bnd https://github.com/bndtools/bnd/pull/838 that would let you write
> some felix specific annotations and get the info into the metatype xml.
>
Cool, I was thinking of exactly something like this as well. I'll take a
closer look at the PR.
>
> The proprietary metatype framework I work with uses the pid of the
> "target" configuration for "foreign key" references.
I'd really just like to be able to mark some AD as readonly from the point
of view of the UI (that is, on updates). At least this way, when a
configuration is created programmatically (where the pKey value would be
set), there'd be _less_ chance that someone comes along later and borks it
up by messing with the value.
- Ray
>
> thanks
> david jencks
>
>
>
> On Mar 3, 2015, at 2:29 PM, Raymond Auge <ra...@liferay.com> wrote:
>
> > Some searching lead to another request for something like this at least
> > here:
> >
> >
> http://mail-archives.apache.org/mod_mbox/felix-dev/201301.mbox/%3C2B034BDA9437584AA6A714D3DFE23238CA6FC6@Eleos.SIDON.OLYMP%3E
> >
> > - Ray
> >
> > On Tue, Mar 3, 2015 at 10:36 AM, Raymond Auge <ra...@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 <ra...@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)
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
--
*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)
Re: metatype extension
Posted by David Jencks <da...@yahoo.com.INVALID>.
I haven't looked in detail at what you are proposing.
The eclipse metatype impl supports pretty much arbitrary extra attributes in extension namespaces. I'd start by implementing something like that in the felix metatype impl. It won't help much with metatype providers unless they happen to generate felix or equinox specific goo. I don't think there's any plausible way around this yet.
I'm pushing for an extension annotation processor plugin-plugin thingy for bnd https://github.com/bndtools/bnd/pull/838 that would let you write some felix specific annotations and get the info into the metatype xml.
The proprietary metatype framework I work with uses the pid of the "target" configuration for "foreign key" references.
thanks
david jencks
On Mar 3, 2015, at 2:29 PM, Raymond Auge <ra...@liferay.com> wrote:
> Some searching lead to another request for something like this at least
> here:
>
> http://mail-archives.apache.org/mod_mbox/felix-dev/201301.mbox/%3C2B034BDA9437584AA6A714D3DFE23238CA6FC6@Eleos.SIDON.OLYMP%3E
>
> - Ray
>
> On Tue, Mar 3, 2015 at 10:36 AM, Raymond Auge <ra...@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 <ra...@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)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: metatype extension
Posted by Raymond Auge <ra...@liferay.com>.
Some searching lead to another request for something like this at least
here:
http://mail-archives.apache.org/mod_mbox/felix-dev/201301.mbox/%3C2B034BDA9437584AA6A714D3DFE23238CA6FC6@Eleos.SIDON.OLYMP%3E
- Ray
On Tue, Mar 3, 2015 at 10:36 AM, Raymond Auge <ra...@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 <ra...@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)
Re: metatype extension
Posted by Raymond Auge <ra...@liferay.com>.
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 <ba...@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 <ra...@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)
Re: metatype extension
Posted by Balázs Zsoldos <ba...@everit.biz>.
>
> 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 <ra...@liferay.com>
wrote:
> On Wed, Mar 4, 2015 at 3:08 AM, Balázs Zsoldos <ba...@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 <ra...@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 <ra...@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)
>
Re: metatype extension
Posted by Raymond Auge <ra...@liferay.com>.
On Wed, Mar 4, 2015 at 3:08 AM, Balázs Zsoldos <ba...@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 <ra...@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 <ra...@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)
Re: metatype extension
Posted by Balázs Zsoldos <ba...@everit.biz>.
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*
On Tue, Mar 3, 2015 at 4:36 PM, Raymond Auge <ra...@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 <ra...@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)
>
Re: metatype extension
Posted by Raymond Auge <ra...@liferay.com>.
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 <ra...@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)
Re: metatype extension
Posted by Jan Willem Janssen <ja...@luminis.eu>.
Hi Raymond,
> On 03 Mar 2015, at 16:24, Raymond Auge <ra...@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?
--
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