Sorry, I did not mean to imply that this should be specified. I was rather asking about something more on the "defacto" front.
I'm going to take a look a Converter. It sounds pretty much for the type of thing I'm looking for (plus BND is already in our stack). Thanks again Peter, - Ray On Sat, Feb 8, 2014 at 8:28 AM, Peter Kriens <[email protected]> wrote: > We've had this discussion many times. The first task of a specification is > to specify to enable interoperability. That is, it is not about > convenience. Once you have the interoperability, anybody can create > convenience functions; it is then up to the users to standardize on a few > libraries. > > The reason is that > > - One man's convenience is another man's bloat. An > - Specifying costs a lot of effort, a lot easier to do this stuff in an > open source project > > Then I was wondering why I did not have this issue lately? I realized that > I always use DS and get a Map that I convert to an interface: > > interface Props { > int port(); > List<String> hosts(); > } > > void setFoo(Foo foo, Map<String,Object> props) { > Props props = Converter.cnv(Props.class,props); > ... > } > > The Converter I used is quite powerful, it really converts anything to > anything it could make sense. This converter is in bnd (aQute.libg). I even > catch myself converting e.g. List<String> to List<Long> because it beats > looping. It makes extensive use of the generic type information. So I > rarely care what the actual types are in the properties. > > Kind regards, > > Peter Kriens > > > > > > > > On 7 feb. 2014, at 17:00, Raymond Auge <[email protected]> wrote: > > Hello All, > > I was wondering if there were provided utilities for handling the property > types. > > For instance, string+, arrays of primitives, etc? > > I hate rewriting things if they already exist. However, I don't see > anything either in the core or compendium, but it seems rather sad if we > all have to reproduce such handler code. > > -- > *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
