Syed,
I am also a newcomer to OSGi. I've been working with it for about 6-8
months converting an existing application to OSGi. I strongly recommend
Dan's suggestion of investigating higher level abstractions like DS,
Spring, iPOJO and Blueprint. A higher level API will be very helpful if
you understand which one best suits your needs, why you need it, and how
to use it. It took me a long time to understand what people meant by
"not creating dependency on the OSGi framework" (am I'm still struggling
to strictly follow that advice) but the answer begins with these tools.
Regards,
Shawn
On 10/03/2013 04:26 AM, Daniel McGreal wrote:
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
--
Shawn Ericson
Sr. Principal Engineer, Defense Applications Branch
Aerospace and Defense Solutions Division
CFD Research Corporation Phone: (256) 726-4821
5th Floor, Suite 501
215 Wynn Dr. Fax: (256) 726-4806
Huntsville, AL 35805 http://www.cfdrc.com
New address as of 9/30/2013,
701 McMillian Way NW, Suite D
Huntsville, AL 35806
The information contained in this communication and its attachments is intended
only for the use of the individual to whom it is addressed and may contain
information that is legally privileged, confidential, or exempt from
disclosure. If the reader of this message is not the intended recipient, you
are hereby notified that any dissemination, distribution, copying, or reliance
on this communication is strictly prohibited. If you have received this
communication in error, please notify [email protected] (256-726-4800)
and delete the communication without retaining any copies.
_______________________________________________
OSGi Developer Mail List
[email protected]
https://mail.osgi.org/mailman/listinfo/osgi-dev
