Hi Syed, I would recommend using OSGi for a simple modularised task, or modularising an existing application - prompting more specific questions. Depending on what work you have in front of you, you could investigate some of the higher level abstractions, such as those in Spring, etc. Best, Dan.
On 3 Oct 2013, at 10:03, [email protected] wrote: > 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
