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
_______________________________________________
OSGi Developer Mail List
[email protected]
https://mail.osgi.org/mailman/listinfo/osgi-dev
