OSDir


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: spifly changes


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.auge@xxxxxxxxxxx> 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.bosschaert@xxxxxxxxx>
> 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.auge@xxxxxxxxxxx>
> > wrote:
> >
> > > I've made a change as you've suggested.
> > >
> > > - Ray
> > >
> > > On Thu, Jul 19, 2018 at 12:58 PM, Raymond Auge <
> raymond.auge@xxxxxxxxxxx
> > >
> > > 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.auge@xxxxxxxxxxx>
> > > > wrote:
> > > >
> > > >>
> > > >>
> > > >> On Thu, Jul 19, 2018 at 9:28 AM, David Bosschaert <
> > > >> david.bosschaert@xxxxxxxxx> 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.auge@xxxxxxxxxxx
> > >
> > > >>> 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)
> > >
> >
>