Hi Ray, I see what you mean now. I dug a little in the history and noticed that the code that populated the logService had been removed some time ago (the class used to have a LogServiceTracker). Ah well, at least that is fixed now with your changes writing to JUL...
Thanks! David On Thu, 19 Jul 2018 at 23:41, Raymond Auge <raymond.a...@liferay.com> wrote: > David, that's the logging side... But it does nothing because there are > never any log services. > > - Ray > > On Thu, Jul 19, 2018, 15:20 David Bosschaert, <david.bosscha...@gmail.com> > wrote: > > > Thanks Ray! > > > > Just for completeness, one file that uses this a few times is this one: > > > > > https://svn.apache.org/repos/asf/aries/trunk/spi-fly/spi-fly-core/src/main/java/org/apache/aries/spifly/Util.java > > > > Just search for 'BaseActivator.activator.log(' in there... > > > > Best regards, > > > > David > > > > On Thu, 19 Jul 2018 at 18:41, Raymond Auge <raymond.a...@liferay.com> > > wrote: > > > > > I've made a change as you've suggested. > > > > > > - Ray > > > > > > On Thu, Jul 19, 2018 at 12:58 PM, Raymond Auge < > raymond.a...@liferay.com > > > > > > wrote: > > > > > > > David, regarding the log change, I couldn't find any code that > > populated > > > > the log services anywhere, not through reflection, not through > > > inheritance, > > > > nothing. > > > > > > > > Maybe you could show me where that takes place. > > > > > > > > - Ray > > > > > > > > On Thu, Jul 19, 2018 at 9:35 AM, Raymond Auge < > > raymond.a...@liferay.com> > > > > wrote: > > > > > > > >> > > > >> > > > >> On Thu, Jul 19, 2018 at 9:28 AM, David Bosschaert < > > > >> david.bosscha...@gmail.com> wrote: > > > >> > > > >>> Thanks Ray! > > > >>> > > > >>> It looks good to me except for one thing. This commit > > > >>> https://svn.apache.org/r1836063 changes the log() method in the > base > > > >>> activator to do nothing. I understand that this is to ensure that > the > > > >>> framework extension has no external dependencies but that log() > > method > > > is > > > >>> actually used quite a lot. (Just run find . -name "*.java" | xargs > > grep > > > >>> 'log(' and you'll find 24 or so references). > > > >>> I think losing those log messages may not be ideal :) > > > >>> > > > >> > > > >> I'll double check, but I think the logging code was not even used, > > ever. > > > >> > > > >> > > > >> > > > >>> > > > >>> Being a framework extension you don't want to have any dependencies > > > going > > > >>> to the outside, but would it be an idea to replace those logging > > > message > > > >>> with java.util.logging ones? > > > >>> > > > >> > > > >> Perhaps. I'll check about this. > > > >> > > > >> Thanks for reviewing David. I'll keep you posted. > > > >> > > > >> - Ray > > > >> > > > >> > > > >>> > > > >>> Best regards, > > > >>> > > > >>> David > > > >>> > > > >>> On Mon, 16 Jul 2018 at 21:14, Raymond Auge < > raymond.a...@liferay.com > > > > > > >>> wrote: > > > >>> > > > >>> > @David Bosschaert, et al, > > > >>> > > > > >>> > Could you take a look at the changes I made for > > > >>> > https://issues.apache.org/jira/projects/ARIES/issues/ARIES-1814 > ? > > > >>> > > > > >>> > Basically, I changed the logic that correlated the woven imported > > > >>> package > > > >>> > back to the extender, which previously used package attributes. I > > > >>> replaced > > > >>> > it with "uses" constraints on the osgi.extender capability: > > > >>> > > > > >>> > e.g. > > > >>> > > > > > >>> > > > > >>> > osgi.extender;osgi.extender=osgi.serviceloader.processor;ver > > > >>> sion:Version=1.0;uses:="org.apache.aries.spifly" > > > >>> > > > > >>> > which assures the imported package `org.apache.aries.spifly` must > > > come > > > >>> from > > > >>> > the extender. Make sense? > > > >>> > > > > >>> > -- > > > >>> > *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile> > > > >>> > (@rotty3000) > > > >>> > Senior Software Architect *Liferay, Inc.* < > http://www.liferay.com> > > > >>> > (@Liferay) > > > >>> > Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org> > > > >>> > (@OSGiAlliance) > > > >>> > > > > >>> > > > >> > > > >> > > > >> > > > >> -- > > > >> *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile> > > > >> (@rotty3000) > > > >> Senior Software Architect *Liferay, Inc.* <http://www.liferay.com> > > > >> (@Liferay) > > > >> Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org> > > > >> (@OSGiAlliance) > > > >> > > > > > > > > > > > > > > > > -- > > > > *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile> > > > > (@rotty3000) > > > > Senior Software Architect *Liferay, Inc.* <http://www.liferay.com> > > > > (@Liferay) > > > > Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org> > > > > (@OSGiAlliance) > > > > > > > > > > > > > > > > -- > > > *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile> > > > (@rotty3000) > > > Senior Software Architect *Liferay, Inc.* <http://www.liferay.com> > > > (@Liferay) > > > Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org> > > > (@OSGiAlliance) > > > > > >
