You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@aries.apache.org by Raymond Auge <ra...@liferay.com> on 2018/07/16 20:14:48 UTC
spifly changes
@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;version: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)
Re: spifly changes
Posted by David Bosschaert <da...@gmail.com>.
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 <ra...@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, <da...@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 <ra...@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.auge@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.auge@liferay.com>
> > > > wrote:
> > > >
> > > >>
> > > >>
> > > >> On Thu, Jul 19, 2018 at 9:28 AM, David Bosschaert <
> > > >> david.bosschaert@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.auge@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)
> > >
> >
>
Re: spifly changes
Posted by Raymond Auge <ra...@liferay.com>.
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, <da...@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 <ra...@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.auge@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.auge@liferay.com>
> > > wrote:
> > >
> > >>
> > >>
> > >> On Thu, Jul 19, 2018 at 9:28 AM, David Bosschaert <
> > >> david.bosschaert@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.auge@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)
> >
>
Re: spifly changes
Posted by David Bosschaert <da...@gmail.com>.
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 <ra...@liferay.com> wrote:
> I've made a change as you've suggested.
>
> - Ray
>
> On Thu, Jul 19, 2018 at 12:58 PM, Raymond Auge <ra...@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 <ra...@liferay.com>
> > wrote:
> >
> >>
> >>
> >> On Thu, Jul 19, 2018 at 9:28 AM, David Bosschaert <
> >> david.bosschaert@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 <ra...@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)
>
Re: spifly changes
Posted by Raymond Auge <ra...@liferay.com>.
I've made a change as you've suggested.
- Ray
On Thu, Jul 19, 2018 at 12:58 PM, Raymond Auge <ra...@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 <ra...@liferay.com>
> wrote:
>
>>
>>
>> On Thu, Jul 19, 2018 at 9:28 AM, David Bosschaert <
>> david.bosschaert@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 <ra...@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)
Re: spifly changes
Posted by Raymond Auge <ra...@liferay.com>.
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 <ra...@liferay.com>
wrote:
>
>
> On Thu, Jul 19, 2018 at 9:28 AM, David Bosschaert <
> david.bosschaert@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 <ra...@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)
Re: spifly changes
Posted by Raymond Auge <ra...@liferay.com>.
On Thu, Jul 19, 2018 at 9:28 AM, David Bosschaert <
david.bosschaert@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 <ra...@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;
> version: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)
Re: spifly changes
Posted by David Bosschaert <da...@gmail.com>.
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 :)
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?
Best regards,
David
On Mon, 16 Jul 2018 at 21:14, Raymond Auge <ra...@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;version: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)
>