Check out http://www.osgi.org/Technology/HowOSGi.
John
>
> [osgi-dev] What to do next
>
> Dear Osgi Members,
>
> I have gone through this below link. What should i do after this. Please
> help me out. I am new to OSGi.
> http://bndtools.org/tutorial.html
>
> Thanks & Regards
> Syed
> 8553043179
>
> On Thursday 03 October 2013 12:16 AM, [email protected]
wrote:
> > 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
> >>
> >
> >
>
> _______________________________________________
> 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
