Raymond, I think you may have gone off on a tangent there. Why shouldn't a library like XStream depend on the OSGi LogService? It's only a couple of interfaces… far better than Log4J or Commons Logging or even SLF4J.
There is nothing in the "ideals of OSGi" that is opposed to modern Java language features, there are just some constraints in the very core because it has to be universal. For example, the Alliance just released a draft specification for Java 5 Annotations to be used with Declarative Services. (BTW: thanks to Chris for pointing out that I can't count, and for forcing me to get out my dictionary to look up "pleonastic") Rgds Neil On Tuesday, 11 October 2011 at 21:13, Raymond Auge wrote: > On Tue, Oct 11, 2011 at 3:36 PM, BJ Hargrave <hargr...@us.ibm.com > (mailto:hargr...@us.ibm.com)> wrote: > > > My point is simply that the LogService makes writing code free of OSGi > > > apis (as is commonly preached) difficult on top of the other concerns > > > above. > > > > Your logging code has to be written to some logging API. Why is some other > > logging API more attractive to bind to than the OSGi Log Service API? > > > > When we talk about avoiding OSGi API in your code, we mean the OSGi > > framework (the container) API. You should feel free to use OSGi Service API > > as needed to get the function you need. For example Event Admin, Log > > Services. > > > Understood! > > But about generic java libraries? What if we want them to work within and > without OSGi (which although I truthfully love OSGi and would love to see it > everywhere) I think really needs to still be supported if we are talking > about true modularity (i.e. OSGi or some other). > > Let's consider an example (off the top of my head): xStream! > > How should they write their library to both follow the ideals of OSGi yet > work outside the boundaries of OSGi? Do they have to maintain two code bases? > > > I think the only option is to actually tie themselves to some logging API > that is known to work outside of OSGi and within. The trap is again the risk > of seduction by all those bad paradigms. > > So where does this leave the library developer? > > > > > > > > > -- > > > > BJ Hargrave > > Senior Technical Staff Member, IBM > > OSGi Fellow and CTO of the OSGi Alliance (http://www.osgi.org/) > > hargr...@us.ibm.com (mailto:hargr...@us.ibm.com) > > > > office: +1 386 848 1781 (tel:%2B1%20386%20848%201781) > > mobile: +1 386 848 3788 (tel:%2B1%20386%20848%203788) > > > > _______________________________________________ > > OSGi Developer Mail List > > osgi-dev@mail.osgi.org (mailto:osgi-dev@mail.osgi.org) > > https://mail.osgi.org/mailman/listinfo/osgi-dev > > > > -- > Raymond Augé > Senior Software Architect > Liferay, Inc. (http://www.liferay.com) > > --- > > > Europe Symposium > > > October 18-19, 2011 > Register today: www.liferay.com/Europe2011 (http://www.liferay.com/Europe2011) > New! Add Portal Admin Training Express > (http://www.regonline.com/builder/site/Default.aspx?EventID=997653) > --- > Spain Symposium > October 26-27, 2011 > Register today: www.liferay.com/Spain2011 (http://www.liferay.com/Spain2011) > > > > > _______________________________________________ > OSGi Developer Mail List > osgi-dev@mail.osgi.org (mailto:osgi-dev@mail.osgi.org) > https://mail.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
