Send osgi-dev mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
https://mail.osgi.org/mailman/listinfo/osgi-dev
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of osgi-dev digest..."
Today's Topics:
1. Re: How to model hierarchically complex configuration for
components (Peter Kriens)
2. Re: How to model hierarchically complex configuration for
components (Raymond Auge)
3. Re: How to model hierarchically complex configuration for
components (Peter Kriens)
----------------------------------------------------------------------
Message: 1
Date: Wed, 2 Oct 2013 20:28:56 +0200
From: Peter Kriens <[email protected]>
To: OSGi Developer Mail List <[email protected]>
Subject: Re: [osgi-dev] How to model hierarchically complex
configuration for components
Message-ID: <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"
I think the config admin spec recommends (SHOULD) that a property key is a
symbolic name, this leaves out square brackets ...
Kind regards,
Peter Kriens
On 2 okt. 2013, at 15:35, Raymond Auge <[email protected]> wrote:
On Wed, Oct 2, 2013 at 4:48 AM, Peter Kriens <[email protected]> wrote:
Well, you can store the actual configuration somewhere else and use the current
mechanism to provide a pointer. Or just store it in XML/JSON in a string/byte[]
in the configuration?
Alternatively you can map the configuration of virtually an XML to properties
using nested property names and integers for elements
<a><b>3</b><b>1</b></a> -> a.1.b=1
Ok, that's actually close to how I have it modelled so far.
I'm also looking for a way to perhaps auto convert. So perhaps, as you imply,
something close to xml -> xpath -> property.
/a[1]/b[1]=3
/a[1]/b[2]=1
a.b[1]=3
a.b[2]=1
We consciously prevented the complexity of XML Schemas to allow things like
Metatype (see Webconsole's editor) since we expected the configuration data to
be relatively simple.
Right, in this case the properties here are static (i.e. it's not really
"configuration"), so no UI.
However, there are no limits to the byte[] length or String length so this allows you to encode more complex data. Although this will not give you the automatic UI.
Good to know.
Thank you,
- Ray
Kind regards,
Peter Kriens
On 1 okt. 2013, at 16:59, Raymond Auge <[email protected]> wrote:
Hello everyone,
I'm wondering the best approach for modelling hierarchically complex
configuration data in DS
For example, Portlets (JSR-168/286) have rather complex configuration
http://java.sun.com/xml/ns/portlet/portlet-app_2_0.xsd.
If I wanted to model a Portlet as a DS component, I have a hard time mapping
the complexity.
Any ideas how to model this?
I could ref an XML resource or some other weirdness, but is there perhaps a
more elegant approach?
--
Raymond Aug? (@rotty3000)
Senior Software Architect
Liferay, Inc. (@Liferay)
_______________________________________________
OSGi Developer Mail List
[email protected]
https://mail.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________
OSGi Developer Mail List
[email protected]
https://mail.osgi.org/mailman/listinfo/osgi-dev
--
Raymond Aug? (@rotty3000)
Senior Software Architect
Liferay, Inc. (@Liferay)
_______________________________________________
OSGi Developer Mail List
[email protected]
https://mail.osgi.org/mailman/listinfo/osgi-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://mail.osgi.org/pipermail/osgi-dev/attachments/20131002/74a50a26/attachment-0001.html>
------------------------------
Message: 2
Date: Wed, 2 Oct 2013 14:34:29 -0400
From: Raymond Auge <[email protected]>
To: OSGi Developer Mail List <[email protected]>
Subject: Re: [osgi-dev] How to model hierarchically complex
configuration for components
Message-ID:
<camm6hccahh7nczsecgbbndsm4skbvyzz+ws9n6kgdxxskit...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
hmm.. too bad.
On Wed, Oct 2, 2013 at 2:28 PM, Peter Kriens <[email protected]> wrote:
I think the config admin spec recommends (SHOULD) that a property key is a
symbolic name, this leaves out square brackets ...
Kind regards,
Peter Kriens
On 2 okt. 2013, at 15:35, Raymond Auge <[email protected]> wrote:
On Wed, Oct 2, 2013 at 4:48 AM, Peter Kriens <[email protected]>wrote:
Well, you can store the actual configuration somewhere else and use the
current mechanism to provide a pointer. Or just store it in XML/JSON in a
string/byte[] in the configuration?
Alternatively you can map the configuration of virtually an XML to
properties using nested property names and integers for elements
<a><b>3</b><b>1</b></a> -> a.1.b=1
Ok, that's actually close to how I have it modelled so far.
I'm also looking for a way to perhaps auto convert. So perhaps, as you
imply, something close to xml -> xpath -> property.
/a[1]/b[1]=3
/a[1]/b[2]=1
a.b[1]=3
a.b[2]=1
We consciously prevented the complexity of XML Schemas to allow things
like Metatype (see Webconsole's editor) since we expected the configuration
data to be relatively simple.
Right, in this case the properties here are static (i.e. it's not really
"configuration"), so no UI.
However, there are no limits to the byte[] length or String length so
this allows you to encode more complex data. Although this will not give
you the automatic UI.
Good to know.
Thank you,
- Ray
Kind regards,
Peter Kriens
On 1 okt. 2013, at 16:59, Raymond Auge <[email protected]> wrote:
Hello everyone,
I'm wondering the best approach for modelling hierarchically complex
configuration data in DS
For example, Portlets (JSR-168/286) have rather complex configuration
http://java.sun.com/xml/ns/portlet/portlet-app_2_0.xsd.
If I wanted to model a Portlet as a DS component, I have a hard time
mapping the complexity.
Any ideas how to model this?
I could ref an XML resource or some other weirdness, but is there perhaps
a more elegant approach?
--
*Raymond Aug?* <http://www.liferay.com/web/raymond.auge/profile>
(@rotty3000)
Senior Software Architect
*Liferay, Inc.* <http://www.liferay.com/> (@Liferay)
_______________________________________________
OSGi Developer Mail List
[email protected]
https://mail.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________
OSGi Developer Mail List
[email protected]
https://mail.osgi.org/mailman/listinfo/osgi-dev
--
*Raymond Aug?* <http://www.liferay.com/web/raymond.auge/profile>
(@rotty3000)
Senior Software Architect
*Liferay, Inc.* <http://www.liferay.com/> (@Liferay)
_______________________________________________
OSGi Developer Mail List
[email protected]
https://mail.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________
OSGi Developer Mail List
[email protected]
https://mail.osgi.org/mailman/listinfo/osgi-dev
